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

 = *  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)   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 2 64 potential hosts on each

 Multicast  Start with ff00::/8  Scoping rules used to limit propagation  Anycast  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  Still there  OSPF  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