The IPv6-Only Network

Welcome To The IPv6-Only Network Tutorial
● In a few moments we will join the "IPv6 Solutions" SSID
○ It's fine if you already did. (It only has IPv6 connectivity.)
● Please configure your devices for:
○ DHCP for IPv4 (no static IP, no static DNS)
○ SLAAC or DHCP6 or both for IPv6 (no static IPv6, no static v6 DNS)
● If you use Docker or Microsoft Hyper-V virtualization:
○ It MAY be necessary to disable Docker NAT
○ It MAY be necessary to disable virtual switch interfaces
○ Or it MAY NOT, I don't completely understand this, it's just what worked for me.
○ For the vSwitch interfaces in Windows 10, I right-clicked and selected "disable"
● If you join the "IPv6 Solutions" SSID in its current state, it will only provide
IPv6 connectivity, including dynamic DNS (via DHCP and RDNSS)

The IPv6-Only Network
APRICOT 2019 Daejeon
Alan Whinery
University of Hawaii System
Internet2 IPv6 Working Group

Resources That I May Refer To
● Internet2 IPv6 Working Group
○ URL-Shortened: http://go.hawaii.edu/GFw
○ Full:
https://m.box.com/shared_item/https%3A%2F%2Finternet2.box.com%2Fs%2F3qf7rtet24swd7
fjc26mmi08nui4oyhl
○ Video, slides, notes, etc
● Hawaii IPv6 Task Force
○ http://ipv6hawaii.org/
○ Has links to a video of the 2017 Tutorial, paired with Jeff Harrington's talk on IPv6 Security
○ Etc.

Definition of “IPv6-only Network”
● local gateway routes only IPv6, no IPv4
● Most routers and infrastructure have only IPv6 addresses
● IPv4 is offered to users as a service, over IPv6.
○ This tutorial effects v4 AAS with NAT64/464XLAT
● Although we may offer IPv4 addresses to users, any IPv4 on the local wire is
translated to IPv6 before it reaches the local IP(v6) gateway

Why A Talk On IPv6-only networks?
● When I started this in April 2017, there was a lot of:
○ Small scale DNS64/NAT64 how-tos for openWRT et al, with inappropriate assumptions to
inform the building of larger-scale, production networks
○ Conference and meeting network lessons-learned without repeatable implementation details
● And there was almost no:
○ Coherent documentation about how to get NAT64 working on, for example: Cisco IOS-XE or
JunOS
○ Philosophy and vision groundwork for building and operating an IPv6-only production network
● Because we are now entering a time when IPv6 can stop being an adjunct L3
protocol, and start delivering on its promises
● There is more and more focus on this every day. Other talks at APRICOT 2019
● The purpose of this tutorial is to show you how things work together, and
enable you to go home and do it yourself

The Value Of IPv4/IPv6 Dual Stack
● 15 years of operational IPv6 networking experience
○ Which represents a path to understanding that cannot be obtained by discussing in a working
group.
● Adds IPv6 as an alternative to making things work with NAT.
● It's time to build experience with IPv6 deployments that deliver the promise
○ Shift existing IPv4 address space into an IPv4 as-a-service role
○ Let the solution to IPv4 problems be clearly "enable IPv6"

But Metrics Show Deployment Is Scarce
● The canonical metrics from Google, Akamai, World IPv6 Launch tend to show
low numbers, numbers rounded to zero, and it's not even readily clear what
those numbers represent
● one thing that they don't show is the proportion of requested content that
v6-connected clients receive over IPv6
● if you only see "% of world traffic" or "penetration per country", you would
never suspect that that proportion is, in fact, about half

U. Hawaii Manoa Wireless
(dual stack)
IPv6 traffic:
● Flows: v6 ~ 34%
● Packets: v6 ~ 59%
● Bits: v6 ~ 53%
This zone uses a /19 of global IPv4
space
We are currently committing the
equivalent of 100 /24s to 6 wireless
zones on our largest campus

Value of an IPv4 Address Registration
● From https://www.ipv4auctions.com/:
○ Our 100 /24 equivalent = US $500,000
○ Let's call it US $20 per address
● End-user assignment value
○ If you assign IPv4 addresses to end-users, the address can be used for 5-20 flows at a time
○ If you assign IPv4 addresses to NAT, the address can be used in up to 50 thousand flows at a
time
○ If you assign IPv4 addresses to a router interface or device management, you're encumbering
a US $20 resource which could be serving 50 thousand user flows in a NAT.
● You still can't deal with 0 IPv4 addresses
○ Unless you outsource
■ www.retevia.net
● Salient points:
○ We are using IPv4 addresses at a growing, alarming rate
○ IPv4 addresses are valuable

Experiences - U. Hawaii
● At U. Hawaii ITS, we’ve been dabbling in the art of NAT64/DNS64 since July
2017.
● Several of us have done our work through such a setup on various days,
noting some issues, but by and large getting work done without serious
problems.
● We have provided a IPv6-Only (DNS64/NAT64/464XLAT) SSIDs to the
various groups at various events over the last 19 months. No known problems
were encountered, feedback was positive
● I personally have been using IPv6-only with IPv4AAS as
[DNS64/NAT64/464XLAT] in my office for about 19 months. It is
indistinguishable from our normal dual stack network.

University Of Michigan (UMNet)
● F5 BIG-IP 10250v
○ Running in several places as a general load balancing solution
● Running a virtual machine specifically for NAT64
● In use by Network Operations Staff
● Uses Google DNS64
● prefix 64:ff9b::/96
● A /29 of IPv4 on the front
● "NAT64 was very easy to get running on the F5 hardware and seems to be
quite reliable.
● Hot-Standby failover with capability for connection mirroring to avoid dropped
sessions after a fault (currently turned off)

University Of Michigan (UMNet) Notes
● High-speed logging into Splunk
○ Custom translation dashboard shows flow-tuple-style connection list
● Training would be required to get Help Desk conversant with dashboard
● The host appliances are connected to a pair of data center routers (EX9214s)
at 10G, with the ability to connect at 40G should we require it. If we ever
wanted to run above 5-10G of NAT64 throughput, we would likely need to
consider dedicated hardware.
● We are currently in the discussion/planning stage re: running dual stack on
our main campus SSID. At one point we had hoped to move the SSID to v6
only, but dialed that back a bit. We are not currently running the NAT64
service at a large scale. A handful of us on the Network Team use it, along
with interested parties on campus.

UC Santa Cruz
● We deployed an IPv6-only SSID earlier this year using NAT64/DNS64.
● Although I built a 464-CLAT instance, I never got around to deploying it, but
that hasn't been an issue, at least not one I've heard about, for the small user
population that has been using the v6 only SSID.
● DNS64 is being done in the existing campus BIND servers. This was very
easy.
● NAT64 is being performed by an A10 1030S we had available.
● using SLAAC and serving rDNS server addresses via both SLAAC and
DHCPv6. No reverse DNS.
● A10/Infoblox devices can do DNS64 load balancing, which presumably
means one could deploy an array of NAT64 for availability and performance
(added by Alan)

Virginia Tech Transportation Institute
● Examining Palo-Alto based NAT64 for the lab network
● Examining IPv6-only HPC Clusters
● Quoting Clark:
○ Consider the “headless” (no NAT) HPC system design
■ Compute nodes are accessible based on host ACLs or “real” network ACL, not the
accident of a head node that (usually poorly) provides NAT
■ Workers could provide compute services to multiple schedulers
■ Decouple scheduler from topology!
○ Our current generation clusters are single stack IPv6
■ We want to use kubernetes -- not sure how that will play without legacy IP
■ But traditional HPC “just works”
■ Job scheduling, ssh, access to DB/2, Isilon/Qumulo/web service -- all this works
● Cloud/HPC/etc are, to some extent, currently prisoners of NAT-thinking
● Presentation from 2018 I2 Tech Exchange WG meeting in the Box Folder

The Things You Have At Home
● We had a Cisco ASR1001, not-in-service, with NAT64-capable software
● Other U's have used existing Palo Alto, F5, A10 boxes
● Had to upgrade IOS-XE on a Cisco 4500 to get RDNSS on user segment
● Built VMs on ProxMox NAT64, 464CLAT, DNS64, DHCP6, DHCP4
● Put a “ipv6-only” SSID on the IT building Aruba WiFi
● Built "NAT64-on-a-stick" on a Raspberry Pi
● Could have done DNS64/NAT64 with the ASR1001 and Google’s DNS64
○ Or with Jool NAT64 and Google’s DNS64

The Value Of IPv6 Only
● Operational simplicity
○ Single stack support.
● Only need resources for 1 route table and one address translation table
○ + caches, buffers, etc
○ Lower carbon emissions
● Security
○ Reduce configuration complexity to a single IP stack
○ You only have to do things once, all IPv4 policy is concentrated on the NAT
● Limits deployment of “real” IPv4 addresses, so that they may be used
efficiently
○ IPv4 addresses can only become more costly until IPv6 is the norm
● Provides direct, non-NAT connectivity to IPv6 connected resources
○ Which is a larger proportion of your traffic than you might think
● Your commitment to IPv4 deployment gets shallower, rather than deeper.

IPv4-As-A-Service
● Refers to providing IPv4 content access to IPv6-only hosts
● Generally treated as a futuristic concept
● When should we declare that it’s time for IPv4 As A Service?
○ How about now?
● www.retevia.net
○ IPv4 AAS provider - Lee Howard former Ops Manager of Time-Warner Cable
○ Service market is right around one provider presently
○ I2 IPv6 Working Group had a presentation from Mr. Howard, December 2018
○ Check out the presentation archive:
■ Video and slides in the I2 WG Box Folder -- http://go.hawaii.edu/GFw

Today's Game: Next Friday, Close Of Business
● Pretend we’re doing a general purpose end-user-device WiFi network for 500
devices, to be working next Friday, 5 PM.
● Rules of today’s game
○ We’re talking about solutions that are available to us to deploy in the space of the next week.
○ Perhaps assuming vendor equipment donations (or stuff we already own)
○ Perhaps assuming open source Linux-based routers and stuff
○ Positive user experience is a primary goal
○ Elegance is a very low priority
○ The “morally-right” way to assign addresses or DNS servers or etc is a distant conversation
○ We admit that breaking DNSSEC is something we’d rather not do, but also that nobody would
notice, when we deploy, next week
○ Interesting-new-internet-drafts, or even RFCs are irrelevant, unless they already have
production-ready, supported implementations

Special diagnostic sites for this tutorial
● v4o.tut.uhnet.net -
○ v4o has only an IPv4 address
● v6o.tut.uhnet.net -
○ v6o has only an IPv6 address
Both are using public addresses
Sometimes, you just need to be sure you’re getting v4 only or v6 only content.
Browser plugins:
● Chrome: IPvFoo
(https://chrome.google.com/webstore/detail/ipvfoo/ecanpcehffngcegjmadlcijfolapggal?hl=en)
● Firefox: IPvFox (https://addons.mozilla.org/en-US/firefox/addon/ipvfox/)

Experiment 1: The IPv6-only (only) Network
● Offers IPv6 connectivity
● No IPv4
● Offers DHCP6 and RA-RDNSS
to supply DNS server
● Offers SLAAC and DHCP6
end-user addressing
● Content is sparse, but
surprising, if you know where to
look.

Take A Few Minutes And Explore
● Connect to the "IPv6 Solutions" WiFi network and try
○ http://v6o.tut.uhnet.net (which should work)
○ http://v4o.tut.uhnet.net (which should not work)
○ ping6 www.google.com (MS-Windows: “ping www.google.com”)
○ If no luck, check IPv6 address, DNS server assignment, etc.
CNN.com*, Netflix.com*, YouTube.com*, FoxNews.com, Aljazeera.com
Google.com (perhaps not with external auth), Yahoo.com (incl email)
Wikipedia.org. Xkcd.com, www.acm.org (although not ‘acm.org’),www.apricot.net
arin.net, ripe.net, apnic.net, lacnic.net, internet2.edu, aarnet.edu.au, nsf.gov,
isoc.org, csiro.au, es.net, ietf.org, nanog.org,
apple.com, microsoft.com, cleveland.com
applebees.com (but not locator map)
Juniper.com (with search), Cisco.com (no search), Brocade.com (no search),
www.a10networks.com, paloaltonetworks.com, jool.mx
(* includes streaming)

One Last thing before we leave experiment 1
● Try using the NAT64, which is running, even though we're
not using it --
○ ping6 64:ff9b::128.171.6.64 (unices, mac os x)
○ ping 64:ff9b::128.171.6.64 (ms windows)
● You can actually exploit this, treating “64:ff9b::128.171.6.64” as an ipv6
address, as in:
○ http://[64:ff9b::128.171.6.64]
○ Which uses the ipv4 address for v4o.tut.uhnet.net
● As long as you can reach a NAT64, and know the prefix you
can use this
○ There are several public NAT64 trials

Why we choose DNS64/NAT64
● It’s the most implemented, mature, relevant scheme
● It does not require you to alter end-user devices
● It uses regular, commodity hardware
● There are implementations of each piece available from multiple sources
● It collects globally routable IPv4 addresses in one place (or more for
redundancy/load-sharing).
● Record of success (T-Mobile, others)
● Although the NAT64 holds state, it doesn’t affect network topology
● To exclude it, you stop driving traffic to it.

NAT64 Is Not An In-Line Thing
● There’s a tendency for
documentation and how-to
content for NAT64 to depict it
as a box through which all
traffic flows.
● BUT the IPv4AAS construct is
really the way to picture it --
it’s a service that your network
routes to, like it routes to
anything else, and you drive
traffic to it with DNS64

DNS64 (RFC6147)
● Comes as a feature in BIND, as well as other software
● Assumes the existence of a compatible IPv6<>IPv4 translator
● When it gets a request to resolve a name that has no AAAA=IPv6 response
○ It responds by synthesizing an AAAA response, encapsulating the A record response’s IPv4
address into an IPv6 prefix, per RFC6052
○ Synthesis MUST be reversible
● MAY do reverse (PTR) answers for its own synthesized addresses
● Theoretically “breaks” DNSSEC, even though it doesn’t “lie”
○ The number of end-host resolvers that ask for validation is very small
○ DNS64 clients are not currently designed to understand synthesis nor act on it
■ If they were, it’s reversible, so the validation could be performed

DNS64 in practice
● Pretty simple to set up, if you’ve any BIND experience
options {
directory "/var/cache/bind";
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
allow-query { uhnet; };
recursion yes;
dns64 64:ff9b::/96 {
clients {any;};
mapped {!10/8; !172.16/12; any;};
};
};

BIND9 DNS64 config
dns64 64:ff9b::/96 {
clients {any;};
mapped {!10/8; !172.16/12; any;};
#recursive-only yes;
#break-dnssec yes;
};
● Clients - acl identifying clients to get DNS64 behavior from this server
● Mapped - acl specifying IPv4 range of A responses not to synthesize for
● Recursive-only - if this server has Authoritative zones, don’t synthesize for
those
● Break-dnssec - if a client requests DNS validation, ignore it and send
responses regardless

DNS notes in general (BIND9 perspective)
● DNS64 can live on your main recursive server, or on a caching/forwarding
server near your IPv6 only network
○ You can specify which clients get DNS64, others just get DNS
● DNS64 can serve from both IPv6 and IPv4 addresses (More about that later)
● You can put a DNS server on an IPv6-only network, but if it has no IPv4
connectivity, it needs to forward to a v4-connected server, because many
domains don’t have IPv6-connected name servers.
forwarders {
2001:0DB8::5353;
2001:0DB8::5:353;
};
forward only;

DNS64 And A Records
● DNS64 will still answer queries for A -- it only offers synthesized AAAA when
it’s asked for AAAA
● Resolver behavior of happiness-oriented-browsers, legacy-yet-popular (Win7)
OSes, etc may still choose A records if presented with both.
● If the goal is to promote IPv6 use, and preserve IPv4-translation-address
space, then it may be useful to deny the existence of the A record.
● A record suppression has come up in previous test network scenarios, but
usually to address user experience issues with Happy Eyeballs, etc, not to
maximize IPv4 address use
● I am not suppressing A record responses today

NAT64: NAT That Shrinks, Rather Than NAT That
Grows
● Better than NAT44 for various reasons:
○ Begins as an enhancement to a v6 network
○ The more IPv6 grows, the less NAT you have to do.
○ Promoting Native IPv6 reduces use of NAT v4 address/port space
● Better than dual-stack because the more you shift to IPv6 only networking,
the less you spend precious IPv4 addresses on building an IPv4 network
● As IPv4 addresses become more expensive and more scarce, providing
native IPv4 addresses on per-interface assignments becomes unthinkable.
○ Even if most people no longer give global addresses to user devices, there are still a lot of
IPv4 addresses on routers.

NAT64
● Accepts packets destined for translation-prefixed destinations, translates
them to IPv4
○ e.g. 64:ff9b::
● Accepts response packets from IPv4 destinations, sends them to initiator, with
translation-prefix source addresses

Stateless NAT64 (SIIT)
● Stateless: 1:1 address mapping, appropriate for making your IPv4 servers
look like they’re doing IPv6
○ Probably most often superseded by simply turning on IPv6 on servers.
○ May prevail as a glue-technology for long-life IoT, like power, HVAC, telecom management

Stateful NAT64
● Stateful: N:1 NAT providing IPv4 As A Service to an IPv6-only network
● Uses address mappings in the form of:
○ IPv4: 198.51.100.18
○ Synthesized IPv6: 64:ff9b::198.51.100.18
○ a.k.a. 64:ff9b::c633:6412

Purpose-built Routers vs. Linux Routers
● We have (had) 2 active NAT64 running at U. Hawaii
● Cisco ASR1001, running IOS-XE
○ Version 15.3(2)S2, RELEASE SOFTWARE (fc1) - IOS XE Version: 03.09.02.S
○ Documentation isn’t really plentiful, as far as I can see.
○ Probably more scalable than a Linux router, just a guess
● Ubuntu 16.04 with Jool NAT64
○ Jool 3.5.4 (http://jool.mx )
○ There is a later version of Jool, but I have not had time to upgrade
○ Exhaustively documented, more knobs, easier to monitor and tweak

IOS-XE
interface GigabitEthernet0/0/1
description nat64 v4 side
ip address 203.0.113.190 255.255.255.252
ip ospf authentication-key 7 283947219834821734
ipv6 nd ra suppress all
nat64 enable
!
interface GigabitEthernet0/0/2
description nat64 v6 side
no ip address
ipv6 address 2001:0DB8:4101:FF::1/64
ipv6 enable
nat64 enable
ipv6 ospf 1 area 0

IOS-XE
ipv6 router ospf 1
redistribute static << NAT64 inserts routes as statics
ipv6 access-list nat64-acl
permit ipv6 2001:0DB8::/32 any
nat64 logging translation flow-export v9 udp destination 198.51.100.105 10001
nat64 v4 pool pool1 203.0.113.240 203.0.113.255
nat64 v6v4 list nat64-acl pool pool1 overload
# ^^ logging occurs as flow export - nfdump reads it like:
1969-12-31 14:00:00.000 0.000 ICMP 2607:f278:0:2::14.0 -> ::.0.0 ...... 0 0 0 1

IOS-XE
NAT64#sho ipv6 route stat
IPv6 Routing Table - default - 683 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, R - RIP, H - NHRP, I1 - ISIS L1
I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
EX - EIGRP external, ND - ND Default, NDp - ND Prefix, DCE - Destination
NDr - Redirect, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1
OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
ls - LISP site, ld - LISP dyn-EID, a - Application
S 64:FF9B::/96 [1/0] << I did not type this in as a static route
via ::100.0.0.2, NVI0 (or even as a NAT64 prefix, apparently it’s default/implicit)
S 2001:0DB8:F0:0:1::/96 [1/0] << nor did I enter this static (but it I did enter nat64 prefix)
via ::100.0.0.1, NVI0

IOS-XE
NAT64#sho nat64 statistics global
NAT64 Statistics
Total active translations: 22 (0 static, 22 dynamic; 22 extended)
Sessions found: 117305872
Sessions created: 594195
Expired translations: 594291
Global Stats:
Packets translated (IPv4 -> IPv6)
Stateless: 0
Stateful: 81459865
MAP-T: 0
Packets translated (IPv6 -> IPv4)
Stateless: 0
Stateful: 36440237
MAP-T: 0

Stateful NAT64 on Linux: Jool 3.5X (4.0.0 current)
● http://jool.mx
● Pronounced like English “jewel”, it is a Mayan word, not a Spanish word
● I have set up Jool in Ubuntu 16 & Raspian 8, to good effect
● It is the only Linux based SIIT/NAT64 solution I have tried
○ It is currently actively developed, with attention on functionality and performance, and seems
to be best-of-breed
● 3.5 Has undergone Cisco T-Rex testing with good results

NAT64 on Linux: Jool 3.54
● One needs to prep Ubuntu like a router/translator
● You can do one-armed NAT64 pretty easily
● Following assumes separate v6 interface and v4 interface

rc.local
#This is required once you enable ipv6 forwarding
# it probably belongs in /etc/network/interfaces
# sets up the default gateway for this host
/bin/ip -6 route add default via 2001:0DB8:F101:6001::1
# per http://jool.mx/en/run-nat64.html
# and http://jool.mx/en/offloads.html
/sbin/ethtool --offload ens18 gro off
/sbin/ethtool --offload ens18 lro off
/sbin/ethtool --offload ens18 gso off
/sbin/ethtool --offload ens18 tso off
/sbin/ethtool --offload ens18 tx off
/sbin/ethtool --offload ens18 rx off
#( and again for ens19 )
/sbin/modprobe jool pool6=2001:0db8:f0:0:2::/96
/usr/local/bin/jool --pool4 --add 203.0.113.147 1126-65535
(...)

Sysctl.conf
(...)
net.ipv4.conf.all.forwarding=1
# limit ephemeral ranges to add more ports to translation range
net.ipv4.ip_local_port_range = 1025 1125

interfaces
auto ens19
iface ens19 inet6 static
address 2001:0db8:F101:6001::64
netmask 64
accept_ra 1
autoconf 0
privext 0
auto ens18
iface ens18 inet static
address 203.0.213.146
netmask 255.255.255.240
gateway 203.0.213.81
auto ens18:147
iface ens18:147 inet static
address 203.0.213.147
netmask 255.255.255.240
auto ens18:148
iface ens18:148 inet static
address 203.0.213.148
netmask 255.255.255.240
#(...)

Skip the broadcast
DON’T configure the IP broadcast addr as a pool address.
Jool will happily use the segment broadcast as a source address, which
works, unfortunately, but as a destination address, the router refuses to
deliver to broadcast

Userspace jool command to monitor
/usr/local/bin/jool --pool4 --display
0 TCP 203.0.213.147 1126-65535
0 TCP 203.0.213.148 1126-65535
0 TCP 203.0.213.149 1126-65535
(...)
0 UDP 203.0.213.147 1126-65535
0 UDP 203.0.213.148 1126-65535
0 UDP 203.0.213.149 1126-65535
(...)
0 ICMP 203.0.213.147 1126-65535
0 ICMP 203.0.213.148 1126-65535
0 ICMP 203.0.213.149 1126-65535
(...)
(Fetched 36 samples.)

NAT64 is a service on the network
● I export the routes into our OSPF and then any IPv6-connected host can use
it
○ Pinging an IPv4 address by hand-mapping it into a NAT64 prefix:
[root@robespierre ipv6]# ping6 -c 5 64:ff9b::203.0.213.116
PING 64:ff9b::203.0.213.116(64:ff9b::cb00:d574) 56 data bytes
64 bytes from 64:ff9b::cb00:d574: icmp_seq=1 ttl=56 time=1.64 ms
--- 64:ff9b::203.0.213.116 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4008ms
rtt min/avg/max/mdev = 1.201/1.574/2.124/0.310 ms
● Of course, one might need to think about limiting access

Neither NAT64 Can Reach Its Own Translator
● From the command line on either the Cisco ASR 1001 OR on the Ubuntu/Jool
NAT64
○ Pinging 64:ff9b::203.0.213.13 results in no responses.

Experiment 2: IPv6-only with DNS64/NAT64
Taking v6-only from experiment 1
Adding NAT64 translator
Turning on DNS64 on the DNS server
Confirming a static route to NAT64 for
the translation prefix
This network will be much more
versatile than experiment 1, but
eventually you will find something that
does not work.

● Try (mac/linux/android)
○ “ping6 v4o.tut.uhnet.net”
● Try (windows)
○ “ping v4o.tut.uhnet.net”
● Try (mac/linux/android)
○ “ping v4o.tut.uhnet.net”
● Try (windows)
○ “ping -4 v4o.tut.uhnet.net”

● Load web page:
○ http://v4o.tut.uhnet.net
● If the left-hand picture fails to load,
then IPv4 literals are not working.
*Several modern oses should be able to reach v4
literals because they have built-in IPv4
literal-catchers (aka CLAT, of 464XLAT)

● Note that there are still no IPv4 addresses at the clients
● If you encounter failures, they are most likely caused by “IPv4
Literals”, which are numeric IPv4 addresses embedded in HTML, or
software code. Since numeric addresses do not require an address
lookup, they’re not re-synthesized by DNS64.

Devices That Get The Apple
● Why?
● Because they have built-in 464XLAT CLAT.
● When such a device joins a v4-only network, it
queries the AAAA record for “v4only.arpa”
● Since it knows the expected response, and can
deduce the prefix from the AAAA response, it
knows about DNS64 and NAT64, including the
synth/translation prefix

464XLAT (RFC6877)
● 464XLAT is a superset of NAT64, and it can be a transition strategy in itself.
● Uses a simple form of SIIT NAT46 to clean up residual IPv4 requests from
software, such as hard-coded IPv4 literals, and send them to NAT64
○ Employs 2 pieces:
■ CLAT (at the client)
■ PLAT (at the provider, usually will be the NAT64)
● Takes stray IPv4 packets, translates them, sends them to NAT64
● Has 3 styles:
○ Bump-in-the-wire
■ Meaning there’s a local-wire device that does the duty
○ Bump-in-the-host
■ Meaning that there’s a feature in the end host that translates stray packets before they
hit the wire
○ Bump-in-the-browser
■ Handled by the web browser (Safari)

People don’t say “464CLAT”
● 464XLAT is a superset of NAT64
● It involves a CLAT (NAT46 at the client)
● And a PLAT (NAT64 at the “provider”)
● But since we just got done talking about NAT64 and we’re moving to
464XLAT talk, I hereby coin “464CLAT” use it in good health, no need to
thank me...

464XLAT (AKA 464CLAT) with Jool_SIIT
/etc/sysctl.conf
#(...) append the following to the end of existing /etc/sysctl.conf
# per http://jool.mx/en/run-nat64.html
/etc/rc.local
#(...)
ip route add default via 2607:f278:4101:6002::1
ethtool --offload ens18 gro off
ethtool --offload ens18 lro off
# pool6 is the dest of the NAT64 translation pool
modprobe jool_siit pool6=64:ff9b::/96
# EAMT shows the fake v4 sources, and maps to v6 sources to reach the NAT64 pool6 destinations.
jool_siit --eamt --add 172.31.240.0/20 2001:0db8:f0:0:3::/96
exit 0

464XLAT (AKA 464CLAT) with Jool_SIIT
/etc/dhcp/dhcpd.conf
# this file is for a DHCP4 running on a 464XLAT CLAT, which acts as a
# NAT64 to relay ipv4 packets to NAT64
default-lease-time 600;
max-lease-time 7200;
# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;
subnet 172.31.240.0 netmask 255.255.240.0 {
range 172.31.240.20 172.31.255.254;
# No DNS server entries here.
##### option domain-name-servers ns1.internal.example.org;
##### option domain-name "internal.example.org";
option subnet-mask 255.255.255.224;
option routers 172.31.240.1;
option broadcast-address 172.31.255.255;
default-lease-time 600;
option interface-mtu 1460;
max-lease-time 7200;
}

Experiment 3: Adding 464CLAT
● Using the jool_siit module, we put a NAT46 on a new VM on the IPv6-only
wire
● The NAT46 offers RFC1918 addresses in DHCP4 to the hosts on the wire,
and poses as the local v4 gateway
● Clients send packets to the specified CLAT, which takes the packets and
translates them to IPv6 to sent to PLAT (NAT64)
● Manifests as a device per network segment, or a device per edge L3
switch with a trunk to touch all VLANs

Experiment 3: Adding 464CLAT
● You should un-join/re-join the SSID, so that your client retries DHCP4
● You will probably not find things that don’t work with this network
○ To the extent that I wonder whether it isn’t at least equivalent, probably better in terms of
percent functionality, than NAT44 CGN
● http://v4o.tut.uhnet.net should now have both apple and orange for all
devices

Implications Of 464CLAT
● IPv4-only devices work
● IPv4 literals and v4-preferring resolvers work
● While we have left IPv6 DNS adverts from the router active for experiment
3, it’s no longer needed to support Android
○ If you provide an IPv4 address for the DNS64 on the 464CLAT DHCP, it works
○ If the DNS is not on the wire, you will use translation space on DNS queries
○ If running SLAAC is a problem for you, you can turn it off and let Android devices just use
NATted v4.
■ Using DHCP6 in lieu of SLAAC is a very common

Implications Of 464CLAT
● Support for RDNSS on current routers is somewhat limited.
○ Cisco supports half of RFC6106 - RNDSS, but no DNSSL
○ You need to have devices that run relevant IOS-XE
○ “Regular” IOS is left out
○ Juniper appears to have similar product line constraints
○ So the answer for many to have RDNSS is currently “buy a new router”
● So if you’re in the CLAT for stray-IPv4-literal business anyways, you may
as well put a forwarding resolver to DNS64 on the CLAT

CLAT Implementataions
● Bump-In-The-Wire
○ Linux with Jool (as module jool_siit )
■ Runs on big, powerful hardware
○ OpenWRT with the 464XLAT plug-in - (uses TAYGA http://www.litech.org/tayga/)
■ Runs on small cheap hardware
● Bump in the host
○ MS Windows 10 (limited to mobile NICs)
○ Android OS
○ Linux with 464XLAT clatd (uses TAYGA http://www.litech.org/tayga/ )
● Bump In The Browser
○ Safari (MacOS)
● Really need to do periodic regressions for this…
● Others?

The NAT64 Lifestyle
● DNS64 will make most things reachable by NAT64
● You can reach IPv4 numeric addresses in many programs by prepending the
NAT64 prefix
■ Today's net has the well-known NAT64 prefix: 64:ff9b::/96

Example: v4-only Security DVR Browser App
● If you use the v4 address it hammers the 464XLAT
○ The in browser app receives the numeric IPv4 address from the browser
○ DNS64 Synthesis does not work, because the name has a AAAA response which is not
port-mapped to the IPv4-only DVR
● If you synthesize a NAT64 address, the browser app sees the NAT64 IPv4
block
○ Which means that it interacts with the NAT64 instead of the 464XLAT

Stateful NAT64 Manufacturer Support
● Cisco In IOS-XE on certain router platforms
● Cisco ASA (incl DNS64)
● Juniper routers (MX,SRX,?)
● Microsoft Forefront Unified Access Gateway (incl DNS64)
● Palo Alto
● A10 Networks (incl DNS64)
● F5

Acknowledgements
● U. Michigan - Brady Farver - deploying NAT64, and writing up experiences
● Virginia Tech Transportation Institute - Clark Gaylord - commentary,
deploying NAT64, writing up experiences
● UC Santa Cruz - Mark Boolootian - commentary, deploying NAT64, writing up
experiences
● Craig Miller - commentary, research, contributing to the development of my
slides
● Jeff Handal - commentary, research, contributing to the development of my
slides
● University Of Hawaii - Chris Zane, Matt Teshima, Ward Takamiya

The IPv6-Only Network

More Related Content

What's hot (20)

Similar to The IPv6-Only Network (20)

More from APNIC (20)

Recently uploaded (20)

The IPv6-Only Network