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

    2 128 = 3.40282367 * 10 38 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 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