Jeff Schwab
Don’t
Panic!

February 3, 2011



IANA (Internet Assigned Numbers Authority)
hands out the last 5 available /8 address pools to
ARIN, LACNIC, AFRINIC, RIPE, and APNIC
Over the next several months these pools will be
exhausted
After that, requests will be queued until addresses
are returned to the pool


Address space exhaustion first discussed in the
early 1990s!
Three competing proposals:
64 bit SIPP (Simple Internet Protocol Plus)
 128 bit SIPP
 Variable length address “TUBA” (ISO based)


In 1994, at Toronto meeting IETF announced
plans to use 128 bit SIPP




2128 = 3.40282367 * 1038
Assuming one address per cubic meter, this
gives us a sphere just short of the orbit of
Neptune
Certainly, this will be enough
After all, a PC only needs 64K of memory

IPv4 addresses are usually represented as:




Four period separated decimals (0-255)
128.210.11.1
Stored in DNS “A” records
IPv6 addresses are usually represented as:
Eight colon separated hex numbers (0-FFFF)
 2001:18E8:0800:F4FF:0000:0000:0000:0001
 Stored in DNS “AAAA” records
 Any one group of consecutive zeros can be replaced
by ::
 2001:18E8:800:F4FF::1


Basic Format

Host Part
Manually configured
 Mapped from EUI-48 (MAC address)
 Mapped rom EUI-64 (Infiniband/Firewire)
 Concerns about privacy/tracking if MAC address is
used




Many different proposals floated
Two early favorites
1) Provider based addressing




13 bits at top level (8192 top level “routes”)
Severely limits number of “Tier-1” providers
Good for routing table
2) Geographic addressing


Good for routing and aggregation
Requires more cooperation among providers than
we can ever expect




Provider/entity based addressing
Provider part comes from regional registry
(ARIN, etc.)
End sites customarily receive a /48
Residential users will get less

But we still may be able to get rid of NAT



Providers can actually get more than a /32
Almost any large enterprise can receive a /32
The current definition of enterprise is rather
loosely interpreted




ARIN allocated 2001:18E8::/32 to the Indiana
Gigapop
Indiana Gigapop allocated 2001:18E8:0800/44 to
Purdue University
Purdue University allocated 2001:18E8:0800/48 to
the West Lafayette campus
Initially, West Lafayette campus can allocate 65,536
subnets with 264 potential hosts on each

Multicast



Anycast


Start with ff00::/8
Scoping rules used to limit propagation
Highest 128 interface addresses on a subnet
Broadcast

Gone. Can use scoped multicast instead

IPv6 Packet Headers


Fixed length header to simplify processing
IPv4 headers had variable length due to options



Hop Limit – Analogous to IPv4 TTL
Next Header – Type of Extension header
(Layer 3 or Layer 4) – can be chained
Payload Length – Number of octets (unless
jumbo extension header follows)

Replace (and augment) IPv4 options




Source routing
Authentication
Encryption
Layer-4 protocols

TCP, UDP, ICMP

TCP and UDP


Bit for bit the same as with IPv4
ICMP
Slightly modified, all IPv4 functionality is there
 Includes some old IGMP (multicast) functionality
 Adds functions for neighbor/router discovery


ARP


Gone!
Functionality merged into ICMP

RIP


OSPF


Still there
Parallel to IPv4, but two do not interact
BGP

Can support both IPv4 and IPv6 in same session

Static Manual Configuration


Router gateway, network address/mask, DNS
Just like today only numbers are larger
 More typing

Two Network based options


SLAAC
DHCPv6




StateLess Automatic Address Configuration
IPv6 “Plug and Play”
Uses ICMP to find router and local network
Host part of address comes from MAC address



Some OS’s (Windows) randomize this for privacy
But “Privacy addresses” may break firewalls
But… No DNS info

No generally accepted extensions for DNS



Works similarly to DHCP for IPv4
DHCPv6 servers now available
But… Currently not implemented by Apple






Routers and switches will need to support IPv6
Most current generation hardware does IPv6 to
some extent.
Routing protocols are available for IPv6
Older hardware will need to be updated
May have enough time to work into LCR plan
Wireless is usually easy if just bridging

Firewalls and Load Balancers
Support for IPv6 mostly just starting
 Some upgraded code for existing hardware
 May require a forklift upgrade
 Beating up vendors can help


IPv6 is supported in most modern OS’s




Generally enabled by default
Windows XP does not support DNS over IPv6
“Privacy addresses” on by default in Windows
Apple does not support DHCPv6

Server side



Many critical pieces already have IPv6 aware
versions
Apache, Sendmail, Bind, MySQL
Client side


Most services just rely on underlying OS support
Major browsers are IPv6 aware
 Firefox, Opera, Safari

Many sites are enabling IPv6


Industry does not want to lose IPv6 clientelle
Facebook, Netflix, and Google are IPv6 ready

Google requires whitelisting currently



Eventually, IPv6 will be the only protocol
Probably after most of us are retired
Meanwhile, we need to work in both worlds




We will start with islands of IPv6 in an IPv4 world
Will transition to islands of IPv4 in an IPv6 world
Tunnels will evolve to carry traffic between the
islands
Will need to support both protocols and forms
of tunneling and NAT servers to support access






Host supports and talks to both IPv6 and IPv4
Cleanest answer
Future-proof
Generally transparent to end user
As long as everything is “working correctly”
Difficult to debug when things go wrong


Not enough address bits to be easy
“DS-Lite” – Dual Stack Light
NAT based solution
 Needs to play DNS tricks
 Rumored Comcast trial


DNS Alg (DNS64)
Special resolver on IPv6-only network
If a AAAA record, use it
Else put address from A record into bottom 32 bits of
special IPv6 prefix
 May not work well with DNSSEC




NAT64





Relay router
Dual stack on outside, IPv6 only on inside
State table to maintain IPv4 pool
“Real” IPv6 addresses used unchanged
Special addresses from DNS64 mapped back to IPv4
addresses





NATs
Lots of NATs
Lots and lots and lots of NATs
Performance suffers
End to end applications fail




Lose access to overseas markets/clients
Lose access when travelling
New remote sites may not be able to get IPv4
space
Eventually lose access to domestic
markets/clients



“Unfunded Mandate”
Replace as much hardware as possible in LCR
DO NOT buy any new hardware that isn’t IPv6
ready
Routers
 Firewalls
 Network Appliances




Pressure your vendors for software upgrades, etc.
Engineering costs to set up new address scheme
Cost of running transitional appliances




Work IPv6 into hardware LCR
Prepare your networking infrastructure for
IPv6
Your “Internet presence” (servers) will be most
painful conversion
Printers and other internal only appliances are
lowest priority





It’s the End of the World as We Know it
We can’t ignore the problem
We have some time
Start experimenting!
World IPv6 Day – June 8, 2011




Questions?
Comments?
Live Poultry?
Acknowledgements:


Michael Lambert, Pittsburg Supercomputing Center
Internet2 IPv6 Working Group