An extended write-up of a talk given to the QUESTnet 2001 Conference on July 6th, 2001. At some point I need to revise this, both in terms of content and fixing/removing stale links, some starting points:

• Have updated RFC links to go to rfc-editor.org after the previous references to mirror.aarnet now fail
• Should update to current IPv6 RFCs
• Wider OS support in MacOS X, Vista
• Geoff Huston's IPv4 - How long have we got? (Aug-2003) and IPv6 – Extinction, Evolution or Revolution? (Jan-2006)

Background

There has been talk of an Internet protocol to succeed IPv4 for quite a while. Initially it was called "IPng" and then "IPv6". What's happened to it? Is it a technology like OSI or ATM which generated of lots of stories in the press about how they'd replace IP/ethernet, for a while had moderate acceptance before ultimately losing out in the marketplace?

So what is IPv6? Is it available today? Will it garner any acceptance?

Outline

• IPv4 Background
• IPv6
  • Development of IPv6
  • What is IPv6 ?
  • IPv6 Addressing
  • Coexistence with IPv4
  • Example use in web browser
• IPv6 Availability & Deployment
  • IPv6-enabling software
  • IPv6-enabled software
  • Operating-Systems shipping with IPv6
  • IPv6 support in other Operating-Systems
  • Routers / Backbones
• Conclusions
  • Will IPv6 be a success ?
  • Summary
• Links

IPv4 Background

For nearly 20 years, IPv4 has underpinned development of the Internet ...

• By scaling in speed from 56K -> multi-gigabit backbone
  NB during the mid-80's, some people suggested TCP had a fundamental limit of just a few megabits-per-second
• By scaling from a few hundred hosts -> tens or hundreds of millions
• By being a platform for protocol development
  when IPv4 appeared, there was smtp, telnet & ftp, but no dns, http, ssl, pop, kerberos, BGP, multicast, napster etc

but IPv4 does have problems ...

• Limited address space; 4 billion addresses
  significant organizations joining the Internet in the early days were granted A class address-space. Which means Apple, HP, MIT, Stanford etc each have more address space than China!
• Compounded by 'inefficient' allocation. I don't mean that in a negative fashion, but routing is only practical by separating large blocks of address space into networks. So the practical limit is a few hundred million addresses
• Even so, core routing table size has always been a problem (graph); in general the network speed has been increasing faster than router hardware, so extra performance goes into shovelling packets faster rather than handling bigger routing tables. This is an issue less obvious to end-users. It's not only an issue of routing table size, but also the dynamic nature of routing updates (eg during Code Red, or the assymetry seen in an earlier study (488K PS) with implications for stability or NTP)
• Important capabilities are optional

We've been extending lifetime of IPv4 address space by ...

• Reclaiming address space
  Several A-class spaces have already been reclaimed (eg ARIN msg), but even grabbing them all will only double the available space
• CIDR
  • allows more flexible allocation of address blocks, ie not just /8, /16 & /24. Significantly improves efficiency of allocation
  • aggregation reduces growth of routing tables
• NAT
  • destroys end-to-end connectivity
    which many people claim is fundamental to the Internet
  • problems for encryption, peer-to-peer networks, etc (RFC 3027 looks at IPSec, IKE, kerberos, X, rsh, ftp, rsvp, dns, smtp, SIP, Real Audio, H.323 & SNMP)
  • I'll mention a promising new form of NAT - RSIP (details below)

We shouldn't be blinded into thinking IPv4 is perfect, eg both IPX and OSI had much larger address-spaces 10-15 years ago. In fact in the early 90's, there were more hosts running IPX than IP, they just weren't combined into a global internet.

Rather than anything about IPv4, it's arguable that a major unsung contributor behind the success of the Internet was the RFC system:

• Which allows anyone to author one, so they include jokes, heroic failures, silly experiments as well as successful ones
• But to move onto standards-track, there needed to be several independent, interoperable implementations of an RFC. This constrains people to design systems which can be coded; by itself, it doesn't assure a great result. But at least focuses the attention of standards-writers onto what is practical.
  By contrast, OSI was developed by committees, with the resultant standards given to other people to implement. Breaking the nexus between design and implementation lead to unnecessarily-complex protocols which were difficult to implement.

So is it time to look at an update to IPv4 ?

• Opportunities to address weaknesses with IPv4 and also be better positioned for the coming decades - you know, like we're thinking ahead
• A huge job because it involves designing a whole suite of standards, getting OS & router people implementing them, updating applications to use them, and deploying on a large-scale across backbones & hosts
• Must offer means of smoothly and gradually transitioning since there would not be a flag-day when the whole Internet changed (see coexistence)

IPv6

I guess an obvious question is why the successor to IPv4 is called IPv6. NB the "version" field in the IP header field perhaps should perhaps be called "protocol", eg 5 was assigned to ST Datagram Mode (RFC 1190) which is a streaming multimedia protocol never intended as a successor to IPv4. NB numbers 7-9 were allocated to three other IPng contenders

Development of IPv6

• 1992 IETF begin work on "IPng" to look at future of Internet. CIDR was an early outcome to extend the life of the address-space
• 1994 3 contenders survive initial evaluation
• 1995 SIPP chosen
  Simple IP Plus: focussed on extension of IPv4 to longer addresses (initially 64bit) and minor cleanups. The other contenders (PIP & TUBA) represented more radical changes from IPv4
• 1997 RFCs start appearing
• 2000 Quake supports IPv6
• 2001 millions of systems are IPv6-capable

There are now about a hundred IPv6 RFCs, mostly Standard or Standards-Track. These cover: transport (ethernet, FDDI, ATM, PPP, TokenRing, ARCNet); routing (BGP, OSPF, RIPng); addressing; multicast; ICMP; PMTU; DHCP; SNMP; SNMP MIBs; DNS; socket/STREAM APIs; security; mobile-IP; URLs; etc.

What is IPv6 ?

• Evolutionary, not revolutionary
• Addresses still bound to interfaces (not hosts or processes)
• Uses same UDP & TCP mechanisms
• Uses same 16bit port numbers; eg port 80 is still http
• Generally TCP-based protocols require no change
  while UDP-based ones do need changing. NFS was revised a while ago. NTP will be revised during the finalisation of NTPv4 (straightforward: see RFC 2030)
• Same routing protocols used, OSPF, BGP4, RIPng; though these have been trivially modified to support the longer IPv6 addresses
• Routers don't fragment; it's left for hosts to determine path-MTU and do any fragmentation. Will help QoS.
• Multicast used instead of broadcast
• Opportunity taken with DHCPv6 to replace the use of options with the more flexible SLP service-directory system. No doubt this will flow to DHCPv4
• Fixed-size header;
• The "time to live" header field renamed to "hops remaining", which was how it was used in IPv4. The idea of using times with one second granularity across an Internet with no guarantee of time synchronization, was just silly
• The header checksum removed; it didn't really improve integrity and required recalculating by every router hop as the TTL field was decremented
• The header includes a 20bit "flow label", possibly useful for QoS. RFC 1809 discusses possible uses. NB this was the first RFC published about IPv6 and refers to the draft standard at the time (which had a 24bit flow label). I'd like to know what current thinking is, particularly wrt security.
• Raises the bar
  IPv6 implementations must support multicast, PMTU, IPSec, mobileIP, QoS, etc. These features are optional with IPv4, which makes them harder to deploy & use.

IPv6 Addressing

The IPv6 address space:

• Will be used less efficiently than with IPv4, but will be sufficient for decades
• Is 128 bits in size
  that's four times bigger than IPv4 addresses. May not sound much bigger, but:
  • there's roughly one IPv4 address for everyone on earth
  • there's 1,000 IPv6 addresses for every atom in the body of everyone on earth
  (also see)
• Over half the space not yet allocated
• Segments to support IPX & OSI-NSAP addresses
• 1/8th used for global aggregatable unicast, ie the equivalent of normal IPv4 addresses
• This unicast portion is
  • hierarchically structured
  • ... and allocated
• This unicast portion is fully-aggregated
  • ... max 8K core routes
  • ... but addresses are "not portable"
  • ... therefore design of IPv6 includes ways to ease renumbering
• Supports site-local (ie private) and link-local forms
• Fixed 64bit subnet size. This host part can be:
  
  • Statically assigned
  • Assigned via DHCPv6 (either static or dynamic)
  • Assigned through IPv6 auto-configuration (see RFC 2373 & see RFC 2462) which expands current EUI-48 addresses into EUI-64, eg starting from MAC address
        0:0:e8:4e:47:78
    insert ff:fe into the middle
        0:0:e8:ff:fe:4e:47:78
    toggle the EUI-64 universal/local bit (MSB 02)
        02:0:e8:ff:fe:4e:47:78
    and combining into 16bit hex values
        0200:e8ff:fe4e:4778
    An extension of this mechanism (RFC 3041) allows for a pseudo-random address to be derived, partly to address privacy issues (EPIC Alert, several threads on Slashdot with typically low S/N 1, 2).

IPv6 uses 128 bit addresses which are written as:

• eight colon-separated 16bit hex values, eg
      fe80:0000:0000:0000:0200:e8ff:fe4e:0000
• leading zeroes can be omitted from each 16bit value,
      fe80:0:0:0:200:e8ff:fe4e:0
• contiguous zero values can be replaced by '::',
      fe80::200:e8ff:fe4e:0
• to prevent ambiguity, there can only be one use of '::', which normally will be chosen to replace the longest sequence of zero values, so
      fe80::200:e8ff:fe4e:0
  rather than
      fe80:0:0:0:200:e8ff:fe4e::

Some example addresses:

• fe80:1234:4567:8900:200:e8ff:fe4e:0 is a site-local (aka private) address because it begins fe8
• fec0:1234:4567:8900:200:e8ff:fe4e:0 is a link-local (aka private) address because it begins fec
• ff05::101 is a multicast address because it begins ff
  this example refers to all the NTP servers on the site
• fe80:1234:4567:8900::0 is any anycast address, because the host address is 0:0:0:0
  in this case, packets sent to this anycast address will be delivered to one router on the subnet
• fe80::200:e8ff:fe4e:0 is a site-local (aka private) address because it begins fe8
• ::, the all-zeroes address represents an unspecified address. One use is as source address for a host during the process of determining it's address via DHCP
• ::1, represents localhost
• ::130.102.2.15, represents an IPv4 compatible address. NB the use of dotted decimal for the lowest 32bits instead of two 16bit hex values

Coexistence with IPv4

• No flag-day
  the Internet changed to IPv4 on January 1, 1983, a flag-day. Took two years of planning and was a painful experience - yet ARPANET only had 230 hosts at the time!
• So coexistence is fundamental
• Dual-stacks in short-medium term
  that means a host has both an IPv4 and an IPv6 address. Won't help as we run out of IPv4 addresses
• Pure IPv6 networks can use "6/4 gateways" to translate data streams between IPv4 & IPv6 (eg KAME's faithd, RFC 3142), but this won't work for NAT-unfriendly protocols
• Tunnelling across IPv4 links
  useful to link IPv6 islands, but not a great approach because it's difficult to do accounting of tunnelled traffic, and impossible to achieve QoS

Example use in web browser

• For each element on the page (image, frame, etc)
• Does DNS lookup of host-part via getipnodebyname instead of gethostbyname
• Can return IPv4 address, IPv6 address, or both
• If both, browser decides which to use (often IPv6 first)
• TCP connection created ...
• So, just like a web-page can include elements from several IPv4 hosts, it could include elements from a mixture of IPv4 & IPv6 hosts. The end result is:
  • Transparent to user
  • Transparent to author of web-page
  • But the web-server admin will see IPv6 addresses in the logs, and may also need to include them in ACLs

IPv6 Availability & Deployment

IPv6-enabling software

• IPv6 should be considered by anyone writing significant new software
  eg apache2, or with bind9 that means not only supporting the IPv6 DNS stuff (AAAA, A6, DNAME) but also IPv6 as a transport
• Want existing software to support both IPv4 & IPv6
  so only a single binary gets distributed. That way, IPv6 (or IPv4) starts being used as soon as it's turned-on in the host (maybe as soon as a local router is configured for IPv6)
• IPv6-enabling must be simple (in most cases)
• Most network software written to socket or STREAMS APIs
• Usually straightforward, maybe just a few dozen lines
  see patches needed for qpopper
• Some cases will require extensive rewrite, eg squid
  in this case it's partly because squid makes extensive use of IP addresses throughout the code, but adding IPv6 support would have been much easier had the code been based on a suitable IP address abstraction. Such is claimed to be the case for the CommunigatePro email server

IPv6-enabled software

• IPv6-enabled OS' should come with a comprehensive suite of IPv6 enabled software - netstat, ping, traceroute, telnet, ftp, dns, mail, pop, nfs, ldap, etc. It's not clear whether this is the case with all OS' listed in the following table, eg UnixWare 7 says "with IPv6 API support" which could just mean an IPv6 stack & socket API
• Not sure about the others, but the KAME-derived *BSDs essentially have all software in the base system IPv6 enabled, as well as many in their ports/packages
• Many significant infrastructural packages have been updated for IPv6:
  • bind9 (KAME had patches for some bind8 versions to make it use IPv6 transport)
  • sendmail, postfix, qmail
  • apache2 (KAME had patches for some apache1 versions, but usually may not have worked with other modules, eg mod_perl)
  • also see list in ip6forum
• Many hundreds of open-source packages either have native IPv6 support (eg Mozilla), or have patches available
• Some important software is not yet IPv6 enabled:
  • X11
  • squid
  • perl5: no IPv6 support in base distribution (more details).
    NB I'm not specifically picking on perl, but it's one I'm reasonably familiar with. Probably many other scripting systems also don't support IPv6 (well)
  • djbdns will not implement A6 records (there's a patch for IPv6 transport)

Operating-Systems shipping with IPv6

The version is when IPv6 support first appeared:

• IBM AIX 4.3
• Starting with version 4.2, BSD/OS ships with the KAME stack integrated (previously they'd used their own IPv6 stack). NB BSDi was recently acquired by WindRiver.
• Compaq Tru64 5.1
• Compaq OpenVMS - for v7.1 or v7.2
• FreeBSD 4.1
• Linux 2.2 NB IPv6 is a little broken, but the USAGI project is working on this
• Microsoft WindowsXP
• NetBSD 1.5
• OpenBSD 2.7
• SCO UnixWare 7 - with IPv6 API support (SCO now part of Caldera)
• Sun Solaris 8 - ships with IPv6 support
• Several vendors offer IPv6-enabled WinSock packages:
  • Hitachi Toolnet6 - provides IPv6 connectivity for your Windows PC
  • Trumpet Winsock 5.0 - an IPv6 stack for Win 9x/NT

Although it somewhat depends on the takeup of WindowsXP, there are likely to be several million IPv6 capable systems by the end of this year - just counting the free unix systems.

IPv6 support in other Operating-Systems

• Apple released a developer patch to add IPv6 support to the public-beta of MacOS X. The initial release of MacOS X doesn't have either native IPv6 support, nor is a corresponding patch (yet?) available
• HP HP/UX 11.0 - developer kit v1.1 (March 2000)
• IBM OS/390 - a working prototype
• Integrated Systems Inc (ISI) IPv6 in embedded systems
• Mentat Streams, as used in several commercial UNIXes such as Solaris.
• Microsoft had an experimental patch to add IPv6 to WindowsNT
• Novell 6 (?)

Routers / Backbones

• See router list from ip6forum
• Cisco have started releasing IPv6 support in some early deployment IOS streams
• In terms of address block allocations, currently we're in a bootstrap phase and by June 2001 there have been 87 /35 blocks assigned (see list) to entities like NTT, UUNet, Sprint, Qwest, EUNet, JANET. Note that there have been relatively fewer for the US, partly because it has a disproportionate amount of IPv4 address-space (also see all apnic)
  • apnic: 31
  • arin: 19
  • ripe: 37
• 6Bone has been operational for several years; not a production network but one to gain experience with (like MBone was for multicast)
• IPv6 enabled on Internet2 backbone in May 2000
  NB the focus with Internet2 has been on deployment of high-speed links to the desktop, the pervasive deployment of multicast, and development of new applications (review)
• AARNet had planned to deploy IPv6 on it's backbone around mid-2000, but Cisco's release date for IPv6 support in the necessary IOS stream has slipped
• Some ISPs have IPv6 capable backbones: IIJ (Japan), Uecomm (Australia), SURFnet (Holland)
  July 2001 press release: Telia to build New Generation Internet - first in Europe with IPv6 in commercial network
• In terms of deploying pure IPv6 networks, Realm-Specific IP (RSIP) represents a promising refinement to NAT. (details below)

Conclusions

Will IPv6 be a success ?

Depends how you rate it

• Success isn't necessarily a measure of technological quality because many somewhat better technologies have lost out to competitors with a bigger marketing clout, eg see real-world 9-layer protocol stack (although this omits 'inertia')
• One measure is that most new systems come IPv6-capable. If there's a low barrier to entry, it means people are more willing to try a new system, particularly if it might address some of the existing problems
• Even in an optimistic transition to IPv6 scenario, the majority of existing systems will stay with IPv4 until they're replaced
• So need to take a long-term view
• What's going to happen to the Internet if there's no significant transition to IPv6 ?
• IPv6 will allow new classes on network systems to be deployed

Summary

• While there's been talk of IPng/IPv6 for nearly ten years, the standards only started appearing in 1998. So it's not surprising deployment is still in a very early phase
• IPv6 represents a straightforward evolution of IPv4
• Biggest improvement will be much larger address space
• Major OS' already support IPv6
• Much important software already supports IPv6
• Lack of router and backbone support is hindering deployment
• "non-portable" addresses might be a real issue
  I don't understand routing, but changing ISP might require changing network addresses. Or can everyone use exchanges?
  while IPv6 tries to make renumbering easier, I think it's still unpleasant for most networks
• Even the issue of multi-homing IPv6 is still under active development
• I haven't seen much discussion about this, but many organizations use scripts to help run & manage their networks. Are they going to be trivial to convert to IPv6 ?
• The time to develop & deploy a new protocol means either the current Internet moves to significant deployment of NAT, or a gradual but significant deployment of IPv6 must occur (perhaps into new areas such as mobile phones)
• It's a big job to update network infrastructure to a new protocol, whatever that might be because it includes:
  • people skill sets
  • network design
  • network management tools
  • traffic accounting
  • security: firewalls, IDS, etc
    mind you, port scanning a 64bit IPv6 subnet address-space by crackers will be ... time-consuming
• The future will include significant NAT/ALG
  whether to stretch the IPv4 address space or to translate between IPv4 & IPv6. RSIP (draft-framework, draft-protocol) looks promising. It restores end-to-end transparency because it's up to the host's IP stack to do the 'NAT'. Basically there's a broker on the network which receives requests from clients and sends them an IP address/port to use for each outgoing connection. There's a tunnelling mechanism .
  Conversely for this to happen, it will require updates to applications and the IP stack. Yes these changes are much smaller in scope than transitioning to a new protocol like IPv6, but RSIP has yet made it to RFC status, let alone Standards-Track or Proposed-Standard. By itself, RSIP doesn't enable P2P networking, at least when based on reserved ports. such protocols will require a dynamic registration mechanism.

Let's finish with a quote one of the main people behind IPv6. Steve Deering co-author of numerous IPv6 & multicast (PIM etc) RFCs had this to say in May 2000:

I have indeed often publicly expressed my worry that IPv6 won't succeed in taking over from IPv4, due to the inertia of the installed base and the apparent preference by many for short-term hacks and loss of IP functionality, rather than doing what needs to be done to really fix the problems. But whenever I say that, I am also quick to point out that I am pessimistic by nature (that way, I am never disappointed, and often pleasantly surprised) and that, nonetheless, the chances of success are high enough, and the alternative of just letting the Internet decay is irresponsible enough, that I continue to put my own time and effort into making IPv6 succeed.
...
(that line of argument argument) is untenable on any technical grounds, and though nothing is obvious about the future, the chances of deployment look pretty damn good right now, given the status of the numerous implementations and the pull from major new markets like China and new classes of devices like cell phones.

Links

• Robert Zakon has an extensive Internet timeline which is useful for historical context
• It's also interesting to hear about the input Xerox researchers had on the design of IP
• Tom Lohdan has an excellent site of links and news. It is part of Yahoo's IPv6 webring
• IPv6 Users Group
• IPv6 Forum
• Carl's Australian IPv6 pages
• the IPv6 channel on Stardust.Com
  in particular look at the news section
• 6bone
  in particular look at the page o' links
• Freenet6 is a popular way to connect to 6bone, particularly for portables or machines without a fixed IPv4 address. They'll now supply /48 (80bit, 64K subnets) address-blocks on request.
• Trumpet Software in Tasmania offers free long-term connections, and will allocate you an address block. Contact Peter Tattum for details
• Several ISPs offer IPv6 - IIJ, NTT, SURFnet, Trumpet, Uecomm
• KAME provides the implementation integrated into the various *BSD. KAME is affiliated with the WIDE project.
  At one point, there were alternative IPv6 stacks from INRIA (FR) and NSL (US) but a unified ip6 project saw the best features integrated into KAME
• USAGI Project - Linux IPv6 Development Project is to update the existing but buggy IPv6 in Linux. Like KAME and WIDE, this project is Japanese. NB I found their comparison between linux's current IPv6 support vs KAME's to not be totally convincing. Sure you'd say KAME does better at auto-configuration, PMTU & IPSec but loses out fr IPv6-over-IPv4 tunnel
• The main focus of the Internet2 project is focussed on increasing bandwidth to the desktop & multicast support - though IPv6 was enabled in May 2000.
• Nokia's proposal for IPv6 as the basis for multimedia in 3G mobile networks has been accepted by an industry consortium (the success of 3G itself is an open question)
• Sun's guide to porting Solaris applications to IPv6 (PDF)
• Cisco Systems Statement of Direction: IP Version 6, 443K PDF. This site also has a slide presentation from Steve Deering, 256K PDF
• Sun has a useful site including a list of IPv6 RFCs
• NetBSD IPv6 Networking FAQ covers typical ways of setting up IPv6. Host autoconfiguration, connecting to upstream link, configuring routers, IPv6/IPv4 translation, etc
• IPv6/IPsec Implementation section of FreeBSD Developer's Handbook.
• O'Reilly's OnLamp recently had two articles on IPv6 - Introduction & Setup
• Currently allocated IPv6 address-blocks, (see proposal to extend IPv6 bootstrap period)
• There's an internet draft discussing the two DNS RR types defined for IPv6
• There's an internet draft: Survey of IPv4 Addresses in Currently Deployed IETF Standards" (320K)