Jeff Schwab

Dont
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 OSs (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 OSs

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 isnt 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

Its the End of the World as We Know it

We cant 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