The Internet Protocol Journal - Volume 2, No. 1

IPv6—What and Where It Is

IPv6-What and Where It Is
by Robert L. Fink, Energy Sciences Network

The current Internet Protocol, known as IPv4 (for version 4), has served the Internet well for over 20 years, but is reaching the limits of its design. It is difficult to configure, it is running out of addressing space, and it provides no features for site renumbering to allow for an easy change of Internet Service Provider (ISP), among other limitations. Various mechanisms have been developed to alleviate these problems (for example, Dynamic Host Configuration Protocol [DHCP] and Network Address Translation [NAT]), but each has its own set of limitations.

The Internet Engineering Task Force (IETF) took on this problem in the early 1990s by starting an IPng (Internet Protocol next generation) project. After an over two-year-long process of defining goals and features, getting the best possible advice from industry and user experts, and sponsoring a protocol design competition, a new Internet Protocol was selected. Many proposed protocols were reviewed, analyzed, and evaluated. An evolved combination of several of them (Simple Internet Protocol [SIP], the "P" Internet Protocol [PIP], and Simple Internet Protocol Plus [SIPP]), each using fixed-length addressing, resulted in a final variation, called IPv6, which was selected over a version of the ISO OSI Connectionless Network Protocol (CLNP) (known as the TCP and UDP with Bigger Addresses (TUBA) IPng proposal).

Much work has been done since the selection of IPv6 in 1994. Over 50 implementations of IPv6 are believed to be under way or completed. A constantly growing international IPv6 testbed, called the 6bone, now spans 260 sites in 39 countries, with over 25 different IPv6 implementations in use. Most router companies, including 3Com, Bay, Cisco Systems, Digital, Nokia, and Telebit support IPv6. IPv6 is also available for Digital, HP, IBM, Sun, WinTel, and many other end-user host systems.

IPv6 Addresses-Larger and Different

The larger 128-bit IPv6 address (versus the 32-bit IPv4 address) allows more flexibility in designing newer addressing architectures, as well as providing large enough address spaces for predicted future growth of the Internet and Internet related technologies. A new addressing format, called the Aggregatable Global Unicast Address Format, has been developed to help solve route complexity scaling problems with the current IPv4 Internet. The current IPv4 provider-based addressing used in the Internet relies on separate IPv4 addresses being assigned to ISPs in contiguously numbered blocks for routing efficiency; that is, the routers need to carry fewer routes.

However, there is currently much fragmentation in the IPv4 address space. This situation, aggravated by sites not being able to easily renumber, causes many more separate routes than necessary, in turn leading to route computation complexity (too many routes, too many dynamic changes, too much computation in routers).

Public Routing Topology Prefixes

With the new aggregatable style addressing (see Figure 1), the leftmost 48 bits of the address are defined as a Public Routing Topology (PRT) prefix. The first 3-bit field of this prefix specifies that the addressing format is aggregatable. The next 13-bit portion specifies the Top Level Aggregator (TLA) ID that constrains the top level of Internet routing to 8,192 major transit providers and a new concept of routing exchanges. Each TLA (top level transit ISP) is then responsible for all the remaining public routing topology assignment below it; that is, the Next Level Aggregator (NLA) ID. As shown in Figure 1, the NLA may have a tiered hierarchy to allow multiple levels (NLA1, NLA2, and so on) of other ISPs, each of which would then have control of the assignment of the space below it. The right most portion of the NLA field, at whatever level it may be, would identify the end-user "leaf" site. An 8-bit reserved field has been defined to allow the growth of either the TLA or the NLA fields.

Figure 1: Aggregatable Global Unicast Address Format


*Note:Click above for larger view

The advantage of this style of addressing is that it allows automatic address clustering, or aggregation, into a constrained set of routes, which are represented through the TLA field. If the initial assignment of 13 bits (8,192 TLAs) is insufficient in the future, either the reserved field or another piece of the IPv6 128-bit address space could be utilized. Note that only one-eighth of the current IPv6 address space has been assigned to aggregatable addressing.

Even with this new concept of addressing, sites will still occasionally want to change their ISP (as in the current IPv4-based Internet) and thus will need to readdress to keep the addressing structure constrained. This is where Site Renumbering, which will be discussed later, comes in.

IPv6 TLA Assignment

To begin the production use of IPv6, ISPs providing IPv6 service need to be assigned TLAs so they may assign NLAs to transits and sites they are serving. Until recently, this was not possible. Recent discussions between the IETF, the IANA (Internet Assigned Numbers Authority), and the major address registries (APNIC, ARIN, and RIPE-NCC), have resulted in agreements that will provide a way to request and assign TLAs by early 2nd quarter 1999.

The process agreed upon is based on the above discussions that have been published as a recommendation in an Informational RFC on TLA assignments. The basic idea is to provide a slow start mechanism for TLAs by assigning one TLA ID to be used for defining a Sub-TLA field of 13 bits out of the reserved and NLA fields (see Figure 2). This will allow transits to demonstrate their need for a full TLA based on usage of the assigned Sub-TLA. These rules, based on much current practice with IPv4, are necessary to keep aggregatable addressing functional and effective for hierarchical routing as IPv6 comes into use.

Figure 2: Sub-TLA Format for IPV6 Address Assignment


*Note:Click above for larger view

Rules for assigning these Sub-TLAs include:

  • Must have a plan to offer native IPv6 service within three months from assignment; must have a verifiable track record providing Internet transit to other organizations
  • Must make payment of a registration fee to the IANA and reasonable fees for services rendered by the address registry
  • Must maintain registries of sites and next-level providers and make them available publicly and to the registries; must provide utilization statistics of NLA space below the assigned TLA (or Sub-TLA) and also show evidence of carrying TLA routing and transit traffic
These rules are intended to minimize route explosion and address assignment misuse to aid in the stability of the IPv6-based Internet.

Site Topology Prefixes

In addition to identifying the address of the site with the PRT prefix, aggregatable addressing provides for a site to have aggregation as well using a 16-bit Site Level Aggregator (SLA). The SLA might be as simple as a subnet number (more than 64,000 of them!), or a tiered hierarchy such as the NLA provides. However it is structured, the SLA is under the control of the site, and identifies the subnet that a host interface is attached to (IPv6's addressing, as IPv4's, specifies interfaces on systems, not the entire system).

It is very unlikely that an organization will ever need more than one PRT prefix, given the size and flexibility of the SLA and the System Interface Identifier field (described below).

System Interface Identifiers

Now that we have identified how to reach the site and the subnet a system is attached to, an interface identifier (ID) specifies the local logical address of the interface on the local subnet (or link as it is often called). The interface ID is formed and derived from the new IEEE EUI-64 media- level address that is an expansion of the well-known Ethernet 48-bit address format that allows for more device identifiers to be assigned by each manufacturer. The global/local bit is also inverted to make manually assigned (that is, local) addresses easy to form with only leading zeros.

If the IPv6 node is attached to an Ethernet "link", then the 48-bit address is turned into 64 bits by a filler field inserted in the middle (see Figure 1). This enlarged Interface ID will allow newer technologies, such as FireWire, and newer applications, such as traffic lights and PCS/PDA telephones, to have unique interface identifiers assigned to them from a global address space.

The use of a media-level address for a network-level Interface ID allows the very important IPv6 Stateless Address Autoconfiguration Protocol to work.

Stateless Address Autoconfiguration

Automatic configuration of IPv6 end systems (hosts) is one of the most important features of IPv6. In the current IPv4 Internet, you must either manually configure IP address, network mask, and default gateway, or rely on having a DHCP server. With IPv6, this process can take place automatically, with no reliance on outside systems, using the IPv6 Stateless Address Autoconfiguration Protocol.

This can be done because the Media Access Control (MAC) address is used to form the host's interface ID. For example, if a host has an Ethernet interface that it is trying to configure for use with IPv6, the 48-bit Ethernet MAC address is formed into a 64-bit interface ID, which is the right-most 64 bits of the IPv6 address (see Figure 1). Then, using the Neighbor Discovery (ND) protocol, which is unique to IPv6, this formed interface ID is checked to see that it does not have a duplicate on this link (that is, subnet). If it does, a randomly generated token can be used (though a rare occurrence, it is a necessary protection against illegal Ethernet address usage and situations where the same address may be used on multiple interfaces for legitimate reasons).

At this point, an ND Router Solicitation multicast message is sent out to discover if there is a local IPv6 capable router, what the local site's topology ID for the host's subnet is, and what the site's public topology routing prefix is. Neighbor Discovery can also be used to control whether the site then wishes to continue with further configuration using Stateful Autoconfiguration with DHCPv6.

IPv6 Autoconfiguration thus provides for standalone operation of two or more hosts on a local LAN link with no router present, provides for operation within a site with no outside Internet connectivity present, and allows for easy changing of the site's public topology routing prefix, either when external connectivity comes on line, or when the external connectivity is changed, such as when a different ISP is chosen.

Domain Name System-Forward and Reverse

The Domain Name System (DNS) is an essential component of the Internet. To provide a mapping from a domain name to an IPv6 address, as well as an IPv4 address, a new DNS record type of "AAAA," or "quad A," is defined. This is a clever word play on the "A" record type that the original DNS specification defines for 32-bit IPv4 addresses, because IPv6 addresses are four times larger (128-bits), hence "AAAA"! Most existing implementations of DNS already support AAAA records and existing IPv4 queries of DNS can access these records; that is, you don't need a DNS operating over IPv6 to retrieve these new AAAA records. This support also includes reverse lookups, similar to IPv4s, although a new reverse lookup proposal that will allow automatic partitioning of the delegation information on arbitrary bit boundaries is under consideration. This new capability should make for more reliable reverse registry than exists with IPv4, and easier maintenance when sites change their PRT prefix.

When a host with both IPv4 and IPv6 operating on it ("dual stack") queries the DNS for the address of a remote host, the A and AAAA records returned are used to indicate what protocol to use in communicating with that remote host. If no AAAA record is returned, IPv4 must be used. If only a AAAA record is returned, IPv6 must be used. If both A and AAAA are returned, either IPv4 or IPv6 may be used.

A new modification of the IPv6 DNS extensions is nearing completion that allows the automatic joining of the routing prefixes and Interface IDs when a host's IPv6 address is returned, thus making it easier to renumber a site. This new IPv6 DNS feature makes changing a site's PRT prefix (renumbering) very easy as only one entry, the PRT prefix, needs to be changed. This setup also facilitates easy support of multiple addresses for each host. These enhancements are very useful; IPv4 does not have this feature.

Renumbering Sites When ISPs Change

Because IPv6 addressing is based on the PRT prefix assigned by its ISP, it is essential that it be easy for a site to renumber itself when its choice of ISP changes. To aid in this, a new Router Renumbering (RR) protocol, in conjunction with Autoconfiguration, Neighbor Discovery and the new Aggregatable Unicast addressing PRT prefix are used. RR allows a site's network administrator to set new PRT prefixes into the site's routers, as well as lower the lifetime of existing ISP PRT prefixes to specify an overlap interval, after which the old ISP's service is discontinued.

Hosts learn their new routing prefixes either when they restart, and thus are automatically configured with Autoconfiguration, or when they are informed by their local router that a new prefix is to be used during periodic router notification updates using ND.

For example, a new ISP service is readied for service while the old ISP is notified that it will provide service for just 60 more days. After the new PRT prefix is announced to the site's routers by RR, hosts will use the new prefix (that is, new ISP) for all new connections, while existing connections continue to work until the old prefix is withdrawn (that is, after 60 days in this example).

The easy renumbering of an IPv6 site will make easy a task that is currently very painful for an IPv4 site because hosts are often manually configured in many networks.

The 6bone-An IPv6 Testbed

The 6bone is an international IPv6 testbed network that is overseen and directed through the IETF IPng Transition Working Group (ngtrans) that provides:

  • Testing of IPv6 implementations and standards
  • Testing of IPv6 transition strategies
  • A place to gain early applications and operations experience
  • Motivation and a place for implementers, users, and ISPs to try IPv6
  • An experimental first step toward transition
In the early phases of IPv6 deployment, most native IPv6 transport is restricted to site LANs with the ability to experiment with it locally. Some sites in Great Britain, The Netherlands, and Japan are using native IPv6 over WAN links.

ISPs and various other private IPv4 transit providers may not place IPv6 in their production routers in this early phase of IPv6 deployment, leaving early IPv6 testers with the need to use the existing IPv4 Internet infrastructure to deliver IPv6 packets among themselves when remotely located. Thus an IPv6 transition feature, IPv6 encapsulation (that is, tunneling) over IPv4, is used for parts of the 6bone where native IPv6 may not be available. In this way, the 6bone is also thoroughly testing out its own transition technology as well as providing IPv6 service.

The 6bone is a diverse community of users, ISPs, and developer organizations, many of whom provide transit on the public spirited basis of promoting and gaining early experience with IPv6. It is expected that production variations of the 6bone will also be created to more formally carry production IPv6 traffic.

Components of the 6bone

The 6bone provides this needed IPv6 transport over the public Internet infrastructure, relying on:

  • Dual IPv4/IPv6 stacks in the client host
  • IPv6 packets encapsulated (tunneled) in IPv4 packets
  • Dual IPv4/IPv6 stack backbone routers that know IPv6 routes of 6bone participants
  • DNS that supports IPv6 AAAA records
  • A 6bone Routing Registry to keep track of sites and their tunnels
  • A mailing list, various IPv6 tools, and a 6bone Web site at: www.6bone.net

with the pseudo TLA site-to-site peering indicated by various colored links.

To date, the 6bone has spread to 260 organizations in 39 countries (see Table 1 on page 25).

Figure 3: 6bone Conceptual Architecture


*Note:Click above for larger view

6bone History

Serious work to evolve and refine the IPv6 protocols sufficient to allow the start of various implementations of IPv6 began in 1994. By early 1996, it was obvious that a testing environment was needed, so in March 1996, several implementers and users met and agreed to start an international testbed called the 6bone.

By June 1996, two groups raced to provide the first IPv6 connectivity: the University of Lisbon (Portugal), the Naval Research Laboratory (U.S.), and Cisco Systems (U.S.); a Danish universities consortium (UNI-C), a French universities consortium (G6), and a Japanese universities consortium (WIDE).

Table 1: Countries with Sites Participating in the 6bone

AT-Austria FI-Finland NL-The Netherlands
AU-Australia FR-France NO-Norway
BE-Belgium GB-United Kingdom PL-Poland
BG-Bulgaria GR-Greece PT-Portugal
BR-Brazil HK-Hong Kong RO-Romania
CA-Canada HU-Hungary RU-Russian Federation
CH-Switzerland IE-Ireland SE-Sweden
CM-Cameroon IT-Italy SG-Singapore
CN-China JP-Japan SI-Slovenia
CZ-Czech Republic KR-Korea SK-Slovakia
DE-Germany KZ-Kazakhstan TW-Taiwan
DK-Denmark LT-Lithuania US-United States
ES-Spain MX-Mexico ZA-Zaire

6bone Backbone and Addressing

By the end of 1997, the 6bone converted to the new aggregatable addressing format, a change necessitated by having originally adopted an early prototype provider-based addressing format discussed during early IPv6 design efforts.

Along with the change to a new addressing format was the need to clean up the routing used among the 6bone backbone transit sites. It was originally thought that IDRPv6 (a new Internet Domain Routing Protocol based on earlier IPv4 work) would be the prevailing Exterior Gateway Protocol (EGP) used for IPv6 Internet peering.

By mid 1996, various ISPs made it known that a new EGP for IPv6 was not a practical alternative, given the explosive growth of the Internet and the current evolution and widespread use of the Border Gateway Protocol 4 (BGP4) by ISPs. There was a need to allow for multiprotocol extensions to BGP4, allowing ISPs to more easily adapt their operations to IPv6. This situation led to the rapid evolution of BGP4+, an extension of BGP4 to include IPv6 and IPv4 multiprotocol routing.

6bone Future Plans

To date, most 6bone efforts have been to prove out basic IPv6 interoperability among the many implementations, and to create a reliable international testbed infrastructure. This has included making its backbone operationally ready with the new aggregatable addressing format and use of BGP4+ for high-reliability routing and transit. Now that the 6bone has completed these conversions, serious work can begin on testing site renumbering, security, applications, and transition mechanisms.

Other IPv6 Trials and Testing

Other testing venues have also been very important to the evolution of IPv6: the University of New Hampshire Inter Operability Laboratory (IOL), various trade show demonstration networks, for example, NetWorld+ Interop, and various vendor-sponsored interoperability testing. By early 1998, the UNH IOL had hosted five IPv6 test sessions, though specific details about participating vendors are not released. In a positive sign of industry response to evolving IPv6 specifications, the late July 1997 UNH testing resulted in the successful interoperability of all participants using the new aggregatable addressing format, no more than two months from its first Internet Draft.

Implementations

To date, over 50 different IPv6 host and router implementations are either completed or under way. More than 30 implementations have been tested and used on the 6bone.

Router implementations to date include: 3Com, Bay, Cisco Systems, Digital, Fujitsu LR550, Hitachi NR60, Inria BSD, Linux, Merit MRT, Nokia, NRL for BSD, Telebit, WIDE KAME and ZETA for BSD, and WIDE v6d.

Host implementations to date include: Apple MacOS OpenTransport demo version, Digital OpenVMS, Digital UNIX, FTP Software Windows95, Fujitsu LR450, 460, and 550, Hitachi NR60, IBM AIX, Inria BSD, Linux, HP-UX (SICS), Microsoft Research WindowsNT versions 4 and 5, Sony CSL Apertos IPv4/v6 stack, Sun Solaris, Trumpet Winsock for IPv6, UNH for BSD, NRL for BSD, WIDE KAME and ZETA for BSD, and WIDE v6d.

Several new Windows implementations that will operate under Windows95/98/NT are under way.

Transition from IPv4 to IPv6-A Seamless Approach

IPv6 is unlikely to become the Internet network-layer protocol of choice unless there is literally no choice to be made by the end user, little effort by network and system administrators, and it can operate alongside IPv4 for the indefinite future. Therefore, it must be very easy for the private network (your corporate net) and public network (your ISP) operators to equip, enable, and operate IPv6, while operating IPv4, in such a way that the user doesn't notice that IPv6 is there at all. A system administrator, but not the user, must be conscious of IPv6 in a minimal sense. It is just another protocol stack that any Internet-based applications will operate over if the system is configured and distributed to do so by the system administrator.

At the network operator level, IPv6 is just another routing stack that can easily be turned on in the site's and ISP's routers (many sites certainly support IPX, AppleTalk, DECnet,...). IPv6 interdomain routing can be operated just like IPv4s because it uses BGP4+.

With the aid of the new Dynamic DNS Registration Protocol and IPv6's Stateless Autoconfiguration, users can boot up their system after it has been enabled with an IPv6 stack, in addition to its IPv4 stack, and become IPv6-ready without being aware of it at all. The system would automatically be configured with an IPv6 address, have itself registered automatically in the DNS with the host's existing name alongside its new IPv6 address (in addition to its DNS IPv4 address registration), and when finding a remote host with IPv6, start talking IPv6 all this without the user being required to consciously take action.

Early Production IPv6 Networks

In October of 1998, the 6REN initiative, was established by the U.S. Energy Sciences Network (ESnet). The 6REN is a voluntary coordination initiative of Research and Education Networks (RENs) that provide production IPv6 transit service to facilitiate high quality, high performance, and operationally robust IPv6 networks.

The first participants were ESnet (the U.S. Dept. of Energy's Energy Sciences Network), Internet2 (the advanced Internetworking development collaboration comprised of many large U.S. research universities), CANARIE (the Canadian joint government and industry initiative for advanced networking), vBNS (the MCI network for NSF advanced networking) and WIDE (the Japanese research effort to establish a "Widely Integrated Distributed Environment").

Other profit and not-for-profit networks worldwide have been invited to join the 6REN. It is expected that during 1999 a sizable production environment capable of advanced demonstrations and deployment of Internet applications over IPv6 networks will be in place.

The Future for IPv6

It is too early to predict with total certainty that the Internet will adapt to the use of the IPv6 protocol. However, it should be obvious that IPv6 offers many important features for a next generation Internet: automatic configuration, greatly expanded addressing, easy site renumbering, built in security, and more.

One possible scenario for IPv6 is where it becomes the protocol of choice for newer applications not currently using Internet technology; for example, controlling traffic lights, reading electric meters, and so on. In these uses, IPv6 does not require coexistence with IPv4 because some form of gateway function would provide interconnection to the current Internet.

Another scenario (which doesn't exclude the previous one) is that Microsoft provides IPv6 support for a future version of Windows Networking on Windows OS, and promotes it within corporate Amer-ica for its better features in supporting advanced corporate application/ networking needs. In this scenario, the Internet will learn to carry IPv6 somehow, even if it is via automatically created tunnels that operate over IPv4 (somewhat similar to the 6bone's tunneling, but with dy-namic creation of the tunnels as needed). It is expected that after Microsoft ships IPv6 and large corporations begin using it, ISPs will deploy IPv6 to get their business.

Yet another possibility is that the Internet telephony revolution will come to the conclusion that only IPv6 can provide cost-effective, scalable, end-to-end worldwide telephony implementations. This may be even more important as new classes of wireless networked devices, for example, PDAs and PCS phones, are integrated and built in very large volume.

Also, in parts of Asia and China, where there is little Internet connectivity at present, and very few IPv4 addresses assigned, IPv6 may become very popular because it will allow rapid growth without concerns about address space.

The probability is high that not just one of the above scenarios will happen, but that all will occur, in addition to others not yet imagined. Whatever the implementation scenario, the probability that IPv6 will augment IPv4 as a part of the Internet of the future is very high!

References

  1. 6bone information, including diagrams, hookup info, and registry access is at: http://www.6bone.net
  2. "Internet Protocol, Version 6 (IPv6) Specification," RFC 2460, December 1998.
  3. "Neighbor Discovery for IP Version 6 (IPv6)," RFC 2461, December 1998.
  4. "IPv6 Stateless Address Autoconfiguration," RFC 2462, December 1998.
  5. "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)," RFC 2463, December 1998.
  6. "IP Version 6 Addressing Architecture," RFC 2373, July 1998.
  7. "An IPv6 Aggregatable Global Unicast Address Format," RFC 2374, July 1998.
  8. "DNS Extensions to support IP version 6," RFC 1886, December 1995.
  9. "Proposed TLA and NLA Assignment Rules," RFC 2374, December 1998.
  10. "Transition Mechanisms for IPv6 Hosts and Routers," RFC 1933, April 1996.
  11. "Router Renumbering for IPv6," Internet Draft, Work in Progress, draft-ietf-ipngwg-router-renum-06.txt, November 1998.
  12. IPv6: The New Internet Protocol, Christian Huitema, ISBN 0-13- 850505-5, Prentice Hall, 1998.
  13. IPng: Internet Protocol Next Generation, Edited by Scott O. Bradner and Allison Mankin, ISBN 0-201-63395-7, Addison-Wesley, 1996.

ROBERT FINK is a network researcher with ESnet (the U.S. Dept. of Energy's Energy Sciences Network) at the Berkeley Lab (the Ernest Orlando Lawrence Berkeley National Laboratory). He is cochair of the IETF ngtrans (IPng Transition) Working Group, and leads the 6bone project. You can reach him at: fink@es.net