Lessons from IPv6

Steven M. Bellovin

smb@cs.columbia.edu

History

Effort started in 1992-1993

Original primary purpose: more IP addresses

Several competing proposals

Context

Internet security starting to be noticed

Note: security ≠ cryptography!

No deployed autoconfiguration – DHCP dates to 1993

No NAT; first RFC was 1994

OSI vs TCP/IP wars

Routing table size an issue

Basic Decisions

Do not change basic semantic model of IP; keep it simple

Slightly modified over time...

Support other things seen as necessary

Mobility

Renumbering

Multicast

Add security: IPsec

Do not change TCP

What Happened

Near-stalemate in the IETF among different proposals

IPng area and directorate formed

Arguments over cryptography (vs. U.S. export laws)

Routing table size was seen as not a primary issue

Use CIDR and easy renumbering

Engineering took a lot longer than expected

Second System Effect

Many features were added to IPv6

Scoped addresses

Required changes to the socket API

Neighbor Discovery replaced ARP

Includes basic autoconfiguration

Flow labels (but usage wasn't specified)

Early decision on stateless autoconfiguration froze part of the address format

The Claims for V6

Bigger addresses

True, but doesn't attract end users

Autoconfiguration

We now have DHCP for client configuration

More secure

IPsec exists for IPv4, too

Engineering is Hard

Some features were much more complex than people thought

Neighbor Discovery couldn't be secured with IPsec

Site-local addresses interacted poorly with the DNS

Finishing the design took a lot longer than expected

Renumbering is easier, but still not easy; there are too many addresses in configuration files, access control lists, etc.

Multihoming is still unsolved

What Happened?

The opportunity attracted too many feature creatures

During that time, IPv4 didn't stop evolving

Many of the putative advantages of IPv6 became part of IPv4

Tighter allocation controls by the RIRs helped

NATs solved a large part of the address space crunch

The World Changed under IPv6

Mobility hasn't been that important at the IP layer

Layer 2 mobility often works well: 802.11 access points, cell phones, etc

Firewalls and VPNs have eroded much of the application base for mobility

ISP-based multihoming has become increasingly important – and it was explicitly ignored in the IPv6 design

What are the Lessons?

The devil is in the details – you generally don't know what will work, or how well it will work, until you've built it

Understand what the real issues are

IPv6 got big addresses right; it didn't understand multihoming and looked too much at mobility

Understand what will motivate users to adopt it

NAT made big addresses irrelevant for most end users

2005-07-12T07:37:05