burton 2007 ipv6 technology overview

8/13/2019 Burton 2007 IPv6 Technology Overview

http://slidepdf.com/reader/full/burton-2007-ipv6-technology-overview 1/71

IPv6 Technology OverviewVersion: 2.0, Feb 07, 2007

AUTHOR(S):Jeff Young( [email protected])

TECHNOLOGY THREAD:

WANs and Provider Network Services

ConclusionInternet Protocol version 6 (IPv6) has a number of appealing features and benefits, including itslarge, hierarchical address space, auto-configuration capabilities, and advanced support for Mobile IP. Enterprises and service providers should evaluate IPv6 in light of its capabilities anddecide if they are missing an opportunity to gain a competitive advantage by using IPv6. Giventhe number of changes in IPv6, information technology staffs would be well advised to begin

educating themselves about IPv6 sooner rather than later. Likewise, those organizationsinterested in or expecting to support IPv6 over the next few years should begin their planning process soon.

: 1

Network and Telecom Strategies

In-Depth Research Overview

3

http://%20%20%20%20%20%20%20%20%20%20%20mailto:[email protected]/



Publishing Information

Burton Group is a research and consulting firm specializing in network and applications infrastructure technologies.

Burton works to catalyze change and progress in the network computing industry through interaction with leadingvendors and users. Publication headquarters, marketing, and sales offices are located at:

Burton Group7090 Union Park Center, Suite 200Midvale, Utah USA 84047-4169Phone: +1.801.566.2880Fax: +1.801.566.3611Toll free in the USA: 800.824.9924Internet: [email protected]; www.burtongroup.com

Copyright 2006 Burton Group. ISSN 1048-4620. All rights reserved. All product, technology and service names aretrademarks or service marks of their respective owners.

Terms of Use: Burton customers can freely copy and print this document for their internal use. Customers can alsoexcerpt material from this document provided that they label the document as Proprietary and Confidential and addthe following notice in the document: Copyright © 2006 Burton Group. Used with the permission of the copyrightholder. Contains previously developed intellectual property and methodologies to which Burton Group retainsrights. For internal customer use only.

Requests from non-clients of Burton for permission to reprint or distribute should be addressed to the ClientServices Department at +1.801.304.8174.

Burton Group's Network and Telecom Strategies service provides objective analysis of networking technology,market trends, vendor strategies, and related products. The information in Burton Group's Network and TelecomStrategies service is gathered from reliable sources and is prepared by experienced analysts, but it cannot be

considered infallible. The opinions expressed are based on judgments made at the time, and are subject to change.Burton offers no warranty, either expressed or implied, on the information in Burton Group's Network and TelecomStrategies service, and accepts no responsibility for errors resulting from its use.

If you do not have a license to Burton Group's Network and Telecom Strategies service and are interested inreceiving information about becoming a subscriber, please contact Burton Group.



Table Of Contents

Synopsis.......................................................................................................................................................................... 5Analysis...........................................................................................................................................................................6

Who's Running the Internet Anyway?........................................................................................................................ 6Myths Surrounding IPv6.............................................................................................................................................8

IPv4 Address Space Will Run Out . . .....................................................................................................................8IPv6 Is More Secure than IPv4............................................................................................................................. 10IPv6 Has Better Quality of Service than IPv4...................................................................................................... 10IPv6 Will Alleviate the Need for NAT................................................................................................................. 10

The Problem..............................................................................................................................................................10History...................................................................................................................................................................11Influencers.............................................................................................................................................................11IPv6 Protocol.........................................................................................................................................................11Looking at IPv6 Differently..................................................................................................................................11General Enhancements to Networking................................................................................................................. 12

Examples of IPv6 Deployments........................................................................................................................13Innovative Experimental Work.............................................................................................................................14

The End-to-End Principle................................................................................................................................. 14Multicast: New and Improved...........................................................................................................................15Provider Independence......................................................................................................................................16Innovation Solves Problems..............................................................................................................................18

Flow Labeling....................................................................................................................................................... 18Authentication and Privacy...................................................................................................................................19Improved Support for Extensions and Options.....................................................................................................21Header Format Simplification...............................................................................................................................22Expanded Addressing Capabilities....................................................................................................................... 23Other Areas of Note.............................................................................................................................................. 23

Domain Naming System................................................................................................................................... 23Layer 2.................................................................................................................................................................. 23

IPv6 Routing..................................................................................................................................................... 23Recommendations.....................................................................................................................................................24

Education.............................................................................................................................................................. 24Innovative Thinking..............................................................................................................................................25Self-Awareness..................................................................................................................................................... 25Acceptance of Risk............................................................................................................................................... 25

The Details.................................................................................................................................................................... 26Simple Network Example......................................................................................................................................... 26The IPv6 Address Format......................................................................................................................................... 26

Representation in Text.......................................................................................................................................... 27Representation in a URL.......................................................................................................................................27

Types of Address...................................................................................................................................................... 28Link Local............................................................................................................................................................. 28Unique Local.........................................................................................................................................................28Global Unicast.......................................................................................................................................................29Anycast..................................................................................................................................................................29Special Case Unicast Addresses........................................................................................................................... 30Transition Addresses.............................................................................................................................................31

6to4....................................................................................................................................................................31IPv4 Mapped IPv6............................................................................................................................................ 31Teredo............................................................................................................................................................... 32

Multicast................................................................................................................................................................32Unicast Prefix-Based IPv6 Multicast................................................................................................................32Special Case Multicast Addresses.....................................................................................................................33

3

BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com



Solicited-Node Multicast Address.................................................................................................................... 33Link-Scoped Multicast Address........................................................................................................................34

Configuration of a Node........................................................................................................................................... 35Link Local............................................................................................................................................................. 35 Neighbor Discovery Protocol................................................................................................................................36Router Advertisement........................................................................................................................................... 37Router Solicitation................................................................................................................................................ 37Stateful and Stateless Configuration..................................................................................................................... 38

Address Auto-Configuration.............................................................................................................................38DHCPv6............................................................................................................................................................ 39

Duplicate Address Detection................................................................................................................................ 39Required Addresses...............................................................................................................................................40Link Layers........................................................................................................................................................... 41

IPv6 in Wide Area Networking................................................................................................................................ 41ICMPv6.................................................................................................................................................................44Fragmentation and Path MTU...............................................................................................................................44Domain Name System.......................................................................................................................................... 45Routing..................................................................................................................................................................46

Multihoming in IPv6.........................................................................................................................................47Mobility.................................................................................................................................................................48

Management and Application Support..................................................................................................................... 49Management Support............................................................................................................................................ 50Application Support.............................................................................................................................................. 50

Deployment...............................................................................................................................................................50The Transition to IPv6.......................................................................................................................................... 50Dual IP Stacks.......................................................................................................................................................52Bump-in-the-Stack................................................................................................................................................ 53Tunneling IPv6 over IPv4 Infrastructure.............................................................................................................. 54

6to4 Dynamic Tunneling.................................................................................................................................. 56The 6over4 Mechanism.....................................................................................................................................56Teredo............................................................................................................................................................... 57Tunnel Setup Protocol.......................................................................................................................................57

Gateways and Translators..................................................................................................................................... 58The SOCKS Gateway....................................................................................................................................... 58Stateless IP/ICMP Translation.......................................................................................................................... 59 Network Address Translation-Protocol Translation (NAT-PT)....................................................................... 59

Conclusion.................................................................................................................................................................... 61Appendix A: IPv6-Specific RFCs.................................................................................................................................62Author Bio ....................................................................................................................................................................71

4




Synopsis

Internet Protocol version 6 (IPv6), or the Internet Protocol Next Generation (IPng), was developed to solve anumber of problems (size of address space, security, and others) that the creators of the IPv4 protocol could nothave foreseen, but after more than 10 years of IPv4 and IPv6 development, where are the problems IPv6 wasoriginally designed to handle? Contrary to predictions, there are no IPv4 address shortages plaguing theindustrialized world and inhibiting growth of mobile communications. Network Address Translation (NAT) andClassless Inter-Domain Routing (CIDR) have extended IPv4's life span and have moved what seemed to be a pressing need for more IP address space into at least the next decade.

IPv6's 128-bit hierarchical address space allows for unbridled growth of the Internet-based and “always on” IPdevices throughout the world, but they don't seem to be “on” just yet. Consequently, enterprises and service providers may be able to postpone IPv6 deployment almost indefinitely.

So why would an enterprise consider the deployment of IPv6 technology? The IPv6 effort embodies more than 10years of collective research and development (R&D) by the Internet Engineering Task Force (IETF) and others.This R&D is based on the following principles, which may not always be practical, but can fundamentally change

the nature of internetworking:• End-to-end principle

• Security present in every node

• Header simplification

Some of this technology can benefit enterprises if carefully explored, planned and exploited.

Adoption of IPv6 is a long-term process. However, enterprises and service providers—particularly multinationalorganizations—should begin the IPv6 education process sooner rather than later. A change to IP affects a widerange of related technologies and protocols, including routing protocols, management protocols, Domain NameSystem (DNS) and Dynamic Host Configuration Protocol (DHCP). Enterprises should begin educating their information technology (IT) staff now about IPv6's features and capabilities, as well as related technologies, inorder to understand the impact these changes may have on their networks.

5




Analysis

In December 2005, Internet Protocol Next Generation (IPng), or Internet Protocol version 6 (IPv6), marked itstenth year of development in the Internet Engineering Task Force (IETF). The original specification, Request for Comments (RFC) 1883, written by Steve Deering and Robert Hinden in 1995 is now Obsolete. It has beenreplaced by a more recent version (RFC 2460) but still contains the original set of attributes, put forth by theauthors, of the protocol:

RFC 2460, “IPv6 Specification.” December 1998.

Expanded Addressing Capabilities

IPv6 increases the IP address size from 32 bits to 128 bits, to support more levels of addressing hierarchy, amuch greater number of addressable nodes, and simpler auto-configuration of addresses. The scalability of multicast routing is improved by adding a “scope” field to multicast addresses. And a new type of address calledan “anycast address” is defined, used to send a packet to any one of a group of nodes.

Header Format Simplification

Some IPv4 header fields have been dropped or made optional, to reduce the common-case processing cost of packet handling and to limit the bandwidth cost of the IPv6 header.

Improved Support for Extensions and Options

Changes in the way IP header options are encoded allows for more efficient forwarding, less stringent limits onthe length of options, and greater flexibility for introducing new options in the future.

Flow Labeling Capability

A new capability is added to enable the labeling of packets belonging to particular traffic “flows” for which thesender requests special handling, such as non-default quality of service or “real-time” service.

Authentication and Privacy Capabilities

Extensions to support authentication, data integrity, and (optional) data confidentiality are specified for IPv6.

Deering and Hinden Standards Track (page 2)

For the complete RFC, seeAppendix A of this overview.

Taken at face value, the IPv6 effort has achieved more than its authors intended, yet the protocol has seenrelatively few deployments. Some even doubt that IPv6 will ever be deployed on as wide a scale as its predecessor, IPv4 (see the Network and Telecom Strategies overview, “IPv6: Unmasked”).

Who's Running the Internet Anyway?

If the IETF specified a change to the most basic of Internet protocols, why was it ignored? Why doesn't the IETF

simply mandate the use of IPv6 on the Internet? How can there be so much misinformation and politics regardinga set of specifications for a new networking protocol? To answer these questions, one must have a clear understanding of the IETF.

The most apparent way that the IETF interacts with the Internet community is through the RFC process. As of January 2007, the IETF has produced over 4,500 documents labeled as RFCs, beginning with RFC 1, published inApril 1969, and extending to RFC 4693, published in October 2006. Once published, RFC documents have a lifeof their own; they can change status to Informational , Historic, Standards Track , Internet Standard , or Obsolete.

6


http://www.burtongroup.com/content/doc.aspx?cid=822



Below the surface, the IETF is unlike any other standards body; at the time of their publication, very few RFCsare more than ideas or suggestions to the Internet community. Each idea is moves through various reviews on itsway to becoming an IETF standard document. If it is widely accepted and deployed, it continues the journey; if not, it will become Obsolete or Informational .

The best way to begin to understand the IETF and its work is through one of the RFCs: RFC 4677 “The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force.” An excerpt from that document is included below.

RFC 4677, “The Tao of IETF.” September 2006.

The Internet Engineering Task Force is a loosely self-organized group of people who contribute to theengineering and evolution of Internet technologies. It is the principal body engaged in the development of newInternet standard specifications. The IETF is unusual in that it exists as a collection of happenings, but is not acorporation and has no board of directors, no members, and no dues; see [BCP95], “A Mission Statement for theIETF,” for more detail.

Its mission includes the following:

• Identifying, and proposing solutions to, pressing operational and technical problems in the Internet

• Specifying the development or usage of protocols and the near-term architecture to solve such technical problems for the Internet

• Making recommendations to the Internet Engineering Steering Group (IESG) regarding the standardization of protocols and protocol usage in the Internet

• Facilitating technology transfer from the Internet Research Task Force (IRTF) to the wider Internetcommunity

• Providing a forum for the exchange of information within the Internet community between vendors, users,researchers, agency contractors, and network managers

The IETF meeting is not a conference, although there are technical presentations. The IETF is not a traditionalstandards organization, although many specifications are produced that become standards. The IETF is made upof volunteers, many of whom meet three times a year to fulfill the IETF mission.

There is no membership in the IETF. Anyone may register for and attend any meeting. The closest thing there isto being an IETF member is being on the IETF or Working Group mailing lists (see Section 3.3). This is wherethe best information about current IETF activities and focus can be found.

Of course, no organization can be as successful as the IETF is without having some sort of structure. In theIETF's case, that structure is provided by other organizations, as described in [BCP11], “The OrganizationsInvolved in the IETF Standards Process.” If you participate in the IETF and read only one BCP, this is the oneyou should read.

In many ways, the IETF runs on the beliefs of its members. One of the “founding beliefs” is embodied in anearly quote about the IETF from David Clark: “We reject kings, presidents and voting. We believe in roughconsensus and running code.” Another early quote that has become a commonly-held belief in the IETF comesfrom Jon Postel: “Be conservative in what you send and liberal in what you accept.”

The IETF is really about its members. Because of the unrestrictive membership policies, IETF members comefrom all over the world and from many different parts of the Internet industry. See Section 4.11 for informationabout the ways that many people fit into the IETF. One more thing that is important for newcomers: the IETF inno way “runs the Internet,” despite what some people mistakenly might say. The IETF makes standards that areoften adopted by Internet users, but it does not control, or even patrol, the Internet. If your interest in the IETF is because you want to be part of the overseers, you may be badly disappointed by the IETF.

Hoffman and Harris Informational (page 6)

For the complete RFC, seeAppendix A of this overview.

7


http://www.ietf.org/rfc/rfc4677.txt




One could contrast the IETF with a standards body like the Institute of Electrical and Electronics Engineers(IEEE). The IEEE has a paid membership, elected officials, and produces engineering standards that are closelyfollowed by vendors. When a vendor produces a device that claims to be IEEE 802.xx-compliant, one can berelatively certain that it will operate with other devices claiming similar compliance. IEEE documents are usuallythought of as industry standards at the time of their first publication.

For IETF documents that seek Standard status, wide operational deployment is vital to their acceptance. Thus, thesuccess of any standard produced by the IETF is measured by its use, and in these terms, after 10 years of development, IPv6 would be considered a failure; however, perhaps ”failure” is too strong a term. IPv6 is an”under-achiever” who will one day get things right, but, is still living in the shadow of an older, very successfulsibling. One of the main reasons for the failing of IPng is that its predecessor, IPv4, simply refuses to die. In fact,almost every advance made by the IPv6 community has been mimicked in IPv4. Of course, this cannot go onforever; we all understand that IPv4 has a limited lifetime because there is a limit to the size of the IPv4 addressspace. But as Mark Twain might say, rumors of its death have been greatly exaggerated.

Myths Surrounding IPv6

There are a number of myths that surround IPv6. As with all such fabrications, they are somewhat rooted in thetruth, though perhaps an optimistic or pessimistic stretch of the truth.

IPv4 Address Space Will Run Out . . .

Based on the rate of IP address allocation and the growth of IP routes announced in the global Internet, the bestestimations don't show IPv4 allocations running out any time soon, but that doesn't stop people from making wildguesses. One of the most well-known, either because it's obviously wrong, or because it's still on the web for thewhole world to see, comes from BBC journalist Ian Hardy: “BBC ClickOnline's Ian Hardy investigates what isgoing to happen when the number of net addresses—Internet Protocol numbers—runs out sometime in 2005.”The full article is almost as ill-informed as the catch line: http://news.bbc.co.uk/2/hi/technology/3211035.stm.

Today, we are in no immediate danger of exhausting the IPv4 address space. By conservative estimates, we havemore than 10 more years of deployment before drastic measures like the reclamation of unused or unadvertisedIPv4 space must be considered. An Australian member of the Internet Architecture Board (IAB), Geoff Huston, produced one of the best-known studies of the IPv4 address space. In July 2003, Huston predicted that thecurrently available IPv4 address space would run out in the year 2019. By comparison, in the days leading up tothe decision to create a new Internet protocol, predictions for the total exhaustion of address space hovered aroundthe year 2000. The Huston study is available on the Internet, as is Huston's current prediction:http://www.potaroo.net/tools/ipv4.

The main reason that IPv6 is not widely deployed in much of the world is that, in the view of network administrators, it just isn't necessary at this time. In the places where IPv6 is seeing active deployment, network administrators and policy makers are motivated by the impression that the IPv4 address allocation process is biased. Large population centers in the world, such as Asia, have a disproportionately small share of the allocatedaddress space. This statistic may seem unfair, but has more to do with the fact that much of that address space wasallocated when the Internet was a North American phenomenon than it has to do with unfairness of the totalallocation or the allocation process. More importantly, much of the address space was allocated before advances

like Network Address Translation (NAT) and Classless Inter-Domain Routing (CIDR). According to Huston'sresearch, politics and geography have nothing to do with current allocation rates.

8


http://www.potaroo.net/tools/ipv4

http://news.bbc.co.uk/2/hi/technology/3211035.stm



9




Figure 1: IPv6 Address Space

IPv6 Is More Secure than IPv4

One has to wonder how a protocol that has yet to see widespread deployment can be more secure than anestablished protocol. Truth be told, IPv4 and IPv6 contain almost identical security mechanisms. While IPv6mandates that each network stack “support” IP security (IPsec), there is no mandate that it be turned on and usedin a node. IPsec is already freely available in most IPv4 stacks and is used sparingly. There is no guarantee thatthe IPv6 networking community will use encrypted communication to any greater degree than the IPv4community does now.

Security on such a grand scale in networking is much more of an iterative prospect. Publish a standard, deploy anetwork and wait to see who breaks in. Clean up the mess, fix the holes, wash, rinse, repeat. It will be years before the security implications of things like the stateless auto-configuration of a globally routable interfaceaddress, or whether IPv6 will truly become more secure than IPv4, are understood.

IPv6 Has Better Quality of Service than IPv4Though it is true that the IPv6 header has been amended with a field called a Flow Identifier, the practical usageof this field is still under investigation and may someday produce results that are better than those we have today.Today, the IPv4 and IPv6 type of service (TOS) fields (usage defined by Differentiated Services [diffserv]) areidentically defined.

IPv6 Will Alleviate the Need for NAT

Some very influential people in networking have said things like “NAT is evil,” and in their defense, NAT standsin the way of the creation and adoption of new applications and services on the Internet. NAT is in directopposition to the end-to-end principle mentioned above. However, looking pragmatically, NAT has providedsignificant benefits. NAT helped to slow the consumption of IPv4 addresses. It has inadvertently kept countlesssmall networks from falling into utter chaos. For instance, several knowledgeable sources (see http://isc.sans.org,http://www.sophos.com or www.cymru.com) estimate that the average life (before infection) of a new andunpatched computer running Microsoft Windows 2000 on the open Internet is between eight and forty minutes. NAT creates an “outgoing connections only” style of network that's somewhat effective at keeping truly evilthings like infection from happening on unmanaged networks. Most NAT boxes are deployed in small home or office networks, where they protect users and enable Internet service providers (ISPs) to use their address spaceefficiently (one address per household). NAT isn't going away because too many people benefit from it.

IPv6 doesn't drive the evil things from the Internet; in fact, it may be attracting them. Several presentations to the2005 North American IPv6 Technology Conference outlined how hackers are taking advantage of poorly protected IPv6 tunnels and other IPv6 host features. It would seem, for now, that IPv6 has made the Internet a bitless secure.

The Problem

The day may come when IPv6 is necessary—when IPv4's useful life is over. By most estimations, that day is far enough in the future to cause one to ask if IPv6 is really worth the effort. Organizations are asking their ITdepartments:

“Why should we invest the time, money, and effort to learn and deploy IPv6 when this new protocol won't benecessary before most of us retire?”

10


http://www.cymru.com/

http://www.sophos.com/

http://isc.sans.org/



To answer that question, one must consider the history of the IPv6 effort, the motivation of those who seek toinfluence the decision by an enterprise to deploy IPv6, and the attributes of the IPv6 protocol itself. Eachorganization should examine IPv6 in light of the problems that the organization must solve and without regard for the popularity of IPv6 in the Internet or elsewhere.

History

In 1990, long before the IPng project began, what seemed like an imminent failure of the basic workings of theInternet (i.e., without CIDR, IPv4 address space would have run out in 2000) caused a “call to action” in the IETFcommunity. Some in the community chose to rally around the existing IPv4 protocol, while others chose to rallyaround IPng.

Few organizations would argue that the post-year 2000 work to extend the life of IPv4 was in vain. Given thatmany of the advances that first came about in IPv6 (e.g., enhanced security and auto-configuration) have beenextended into IPv4, one can make the case that the time invested in IPv6 was valuable regardless of whether IPv6sees wide-scale deployment. But more importantly, IPv6 is relevant today because it comprises 10 years worth of research and development (R&D) effort. The IPng project was not only a project to provide the Internet

community with a bigger address space, it was also a chance to optimize some of the shortcomings of IPv4. A fewsavvy enterprises are putting this R&D to work by solving problems with IPv6 that would be either too complexor too costly to achieve with IPv4. It is in these small pilot projects and experiments, not in the large government-mandated deployments, that IPv6 will find its way.

Influencers

A long line of IPv6 proponents has assembled to influence the organizations that will ultimately decide the fate of IPv6:

• The IPv6 community has long made the case for a “transition” to IPv6 as the predominant protocol spoken onthe Internet. The community may be motivated by genuine concern for the Internet, by the pride of creation, or by a desire for a return to the end-to-end principle of the Internet, but the case has gone unheard as feworganizations can see a real need for IPv6 right now.

• Commercial self-interest is driving many vendors, systems integrators, conference promoters, and consultantsto advocate IPv6 deployments. IPv6 means a new generation of improvements in routers and switches. It meansnew consulting contracts and a host of new industry conferences.

• All forms of government (national and local) have either endorsed or have mandated the use of IPv6. Some citethe ability of IPv6 to “level” the playing field when compared to the North American-centric IPv4. Others seeIPv6 as the future of the Internet and cite the economic impact of the current Internet as a reason to invest inIPv6.

IPv6 Protocol

Outside of the group of influencers listed, very few people have taken the time to learn about the IPv6 protocol.As such, it is hard to tell myth from reality and make good decisions about a potential use of IPv6. It's easy to see

how many people in information technology (IT) could insinuate the debate over IPv6 as a potential successor toIPv4 in the Internet into their internal debates on the use of IPv6 technology. Because most of this Internet debatefocuses on the original mandate of IPv6 (for larger address space) and on the eventual “transition” from IPv4 toIPv6, it overshadows the attributes IPv6 has to offer enterprises today. The only remedy is to educate decisionmakers within an enterprise about IPv6.

Looking at IPv6 Differently

11




This section deals with the attributes of IPv6 as they are being applied today. The original mandate of the IPngWorking Group is listed on the left side of Figure 2. The rightmost column in Figure 2 lists the same topics, butconsidered in decreasing order of their benefit to the business community.

Figure 2: Rearranging the Attributes of IPv6

After so much IPv6 development, two new attributes can be added to the original five. One could say that theseattributes were implied in the decision made by the IETF to pursue IPng. At the time of the decision to form theIPng Working Group, viable alternatives were put forth to simply plug a bigger address space into the IPv4 protocol. Instead, the IETF chose to tinker with the basics of the IPv4 protocol and improve on many of itsshortcomings.

For instance, IPv6 has provided “general enhancements to networking” and enterprises are currently benefitingfrom these enhancements. In the middle of the list, IPv6's “authentication and privacy capabilities” are similar towhat an enterprise can realize with IPv4 today, so are of little benefit. At the end of the list, “expanded addressingcapabilities” were the initial reason to begin work on IPv6 and currently provide the least benefit to enterprises,service providers and the Internet community.

General Enhancements to Networking

The networking protocols used by computers and devices to communicate are in some ways like spoken language.It would take more than a few transition methods and hand-held translators to get the English-speaking world toswitch to French. Transitions in language don't happen on such a grand scale, so the expectation should be thesame for Internet language (thankfully, because of extensions to IPv4, a grand scale transition was not needed).Languages evolve slowly over time: A phrase from French is incorporated into English when there is noacceptable translation. The phrase is then incorporated into popular speech, which may cause English-speakers tolearn more about it, to modify it, or add to it in French.

This is similar to the ways in which the new Internet language is being used today. Businesses are discoveringsome real benefits in the body of work behind IPv6, and they are picking and choosing “phrases” from IPv6 andapplying them to their business problems; however, not all Internet phrases translate smoothly.

As an example, one of the first attributes of IPv6 mentioned in the RFC specification (RFC 2460) was “a muchgreater number of addressable nodes and simpler auto-configuration of addresses.” Many of the attributes of IPv6have translated well and have been incorporated in IPv4. However, IPv4 is not getting a bigger address space anytime soon and although IPv4 and IPv6 both have auto-configuration mechanisms, the two have very differentmeanings.

12


http://tools.ietf.org/rfc/rfc2460.txt



Automatic address configuration in IPv4 was proposed and has been implemented, but its purpose is differentfrom IPv6 auto-configuration. IPv4 auto-configuration is intended to provide a working dynamic address,dynamic naming, and browsing for resources on a local area network (LAN) when normal means of configuration(i.e., Dynamic Host Configuration Protocol [DHCP]) aren't available. There are implementations of IPv4 auto-configuration in several major operating systems (Bonjour for Windows, Apple Mac OS X, and Linux), but because not many IT users are aware of the IPv4 auto-configuration standard, seeing an auto-configured interface(which uses the 169.254/16 address space) often just reminds the user to plug in his or her Ethernet cable. Usefulauto-configuration for the wide area in IPv4 requires some type of server-based mechanism.

The simplest way to accomplish this server-based automatic address configuration is with DHCP. DHCP, when itfirst appeared, was a boon for system administrators. DHCP freed system administrators from the chore of teaching users how to configure the IP address, default routers, Domain Name System (DNS) servers, and other configured parameters of their own machines. DHCP could configure machines from a pool of addresses or doleout addresses based on (typically) an Ethernet address. DHCP is widely deployed in all types of networks. It runson large IP address management systems for the enterprise as well as small office/home office (SOHO) routers.However it is deployed, DHCP requires some type of existing infrastructure (a local server or a router to relayDHCP messages), how can we deploy networks where there is none?

When the concept of auto-configuration of network nodes was introduced in IPv6, many in the networking fieldscoffed at the idea. Some even shuddered at the notion of a host, possibly an unpatched Microsoft Windows 2000workstation (see the “IPv6 Will Alleviate the Need for NAT” section of this overview), that when turned onwould configure itself with a globally reachable IP address and begin to communicate with the Internet at large.IPv6 auto-configuration (see the “Address Auto-Configuration” section of this overview) can work without theneed for DHCP servers or any intervention or oversight from network managers.

Examples of IPv6 Deployments

Imagine a sensor network that must be deployed in a warehouse in some far corner of the world. Perhaps it isexpensive or dangerous to send personnel to this location to configure a network. With the inherent capabilities of IPv6, devices can boot, configure themselves, learn about routers, other nodes, and connect via secure means tosome pre-established resource that may be monitoring the location halfway around the world. The real advantage,in these applications is that enterprises don't need to send non-essential personnel to a site in order to get their

network to function This is a compelling application, and there are others.

Enterprises aren't doing all of this alone. Some firms specialize in IPv6 training and deployment, includingconsultants, system integrators, and some early adopters who make their living teaching enterprises about IPv6.One such company, located in Herndon, Virginia, is Command Information (CI). CI would best be described as anew breed of professional service firm specializing solely in IPv6 education, lab testing, trial deployments andapplication development for large enterprise.

A simple IPv6 pilot deployment (described in the previous paragraph) might go like this: bring sensors into the CIlab, strip out the IPv4 over ZigBee stack, put in a new IPv6 stack, and configure the sensors for the environmentin which they can automatically attach to the network in real time. Next it's on to deployment. CI is doing anumber of these pilots for large enterprise and the U.S. federal government.

San Diego State University's (SDSU) Center for Information Technology and Infrastructure (CITI) is working totest and deploy IPv6 technology for the Department of Homeland Security (DHS). Using self-configuring IPv6

networks, SDSU will combine sensor information with location and imagery data to give first responders anddecision-makers better situation awareness as they arrive on a scene. Such information could be invaluable in afire, HAZMAT spill, building collapse or other disaster. Sensors that detect pressure, fire, heat, chemical gasses,and other potential hazards could be permanently installed or spread about the scene soon after a disturbance.

13


http://www.answers.com/topic/zigbee



In Japan, where IPv6 deployment may be a bit ahead of the rest of the world, facility-management equipmentvendors and construction companies are moving to IPv6 for building management. At Interop Tokyo 2005, theIPv6 Promotion Council of Japan held an interoperability demo of IPv6-based equipment, where the groupoutlined three advantages to IPv6 over proprietary systems. First, IPv6 allows facility engineers to address andmanage the thousands of devices within a building or facility. Second, IPsec comes standard with anyimplementation of IPv6, and facility management vendors require secure connectivity to critical infrastructure.Configuring IPsec in an IPv6 node is no different than it is in an IPv4 node and may require shared keys and or public key infrastructure (PKI). For more information on PKI, see the Identity and Privacy Strategies ReferenceArchitecture Technical Position, “Public Key Infrastructure.” Finally, auto-configuration allows for simple plug-and-play network configurations.

Home security is an industry that could be revolutionized by sensors, auto-configuration, and inexpensive broadband. Tom Patterson, chief executive officer (CEO) of CI, states, “Home security is a multi-billion dollar industry in this country alone.” Established companies in this industry are charging upward of $300 to install $20worth of sensors, a controller and a phone line, then charging $20 to $30 per month for home monitoring.Patterson envisions a day when homeowners will buy that $20 worth of sensors in a kit from a retailer, bring ithome, install it, whereupon it self-configures and attaches to a call center that offers home monitoring for $2 to $3 per month.

When it's up and running, IPv6 may be a boon to a number of other business applications. Beyond homeautomation, IPv6 will be integral to inventory systems, telepresence applications, peer-to-peer applications thatenhance collaboration in the enterprise, and building management, to name a few. Technologies like auto-configuration may not be right for typical enterprise workstations and laptops but may enable a whole new worldfor networking dedicated devices.

Innovative Experimental Work

With the threat of a critical shortage in IP addresses, the Internet next-generation effort sparked a flurry of R&Din pursuit of advances in networking. Much of the development was undertaken to further the body of work thatmakes up the IETF IP Next Generation or IPng. There are some 740+ current RFCs that mention the term IPv6and some 152 individual RFCs that deal with the topic directly (seeAppendix A of this overview). Throughoutthis overview, as we examine this work and learn from some of the early adopters of IPv6 technology, it becomesclear that there are attributes of IPv6 technology that do not exist and cannot be duplicated in IPv4.

The End-to-End Principle

If there were a main theme in much of the work that the IPv6 community has accomplished, it would be the returnof the end-to-end connectivity principle to the Internet. This principle is not self-explanatory and it concernswhere best to put the functions of a communication system. More specifically, the end-to-end principle seeks tokeep functions and requirements to maintain the state of connections between hosts in intermediate nodes to aminimum. It also encourages the notion that Internet hosts should be visible and globally reachable by other Internet hosts. Moving the IPv6 fragmentation function out of the intermediate nodes and into requirements for hosts is one example of the principle. IPv6's larger address space, which “removes” the need for network addresstranslation (NAT), is another good example of how the end-to-end principle has influenced IPv6 development.

But the notion of end-to-end goes much deeper than removing a few features from Internet routers. The end-to-end principle is at the heart of David Isenberg's famous essay “Rise of the Stupid Network” (available athttp://www.hyperorg.com/misc/stupidnet.html). In his essay, which is now almost 10 years old, Isenbergcompares two philosophies of network architecture—one being the Internet and the other the telephone network.In the IETF, the end-to-end principle has been the subject of a number of RFC contributions by the IAB,especially in RFCs 3724, 2956, and 2775.

14





http://www.hyperorg.com/misc/stupidnet.html

http://en.wikipedia.org/wiki/End-to-end_principle




As these documents mention, the end-to-end principle can be at odds with accepted practices of network architecture, enterprise networking and security. Technologies that are widely deployed in enterprise networkslike intranets, split DNS, firewalls, virtual private networks (VPNs), and NAT all remove a sense of transparencyfrom the Internet and, therefore, reduce the ability of hosts to operate in an end-to-end fashion. Some of thesetechnologies are necessary (VPNs and firewalls), some of them are convenient (NAT, intranets), and some give afalse sense of security (split DNS).

But what is truly at odds with the notion of end-to-end connectivity is the trust model of connectivity in theInternet. The Internet cannot return to the days of its beginning where the trust model was implicit. The Internetwas run by the National Science Foundation, and it connected networks from research centers and universities.The Internet's acceptable use policy (AUP) prevented any traffic from “for profit” enterprises on the network. Inthe Internet today, trust is never implicit, and “for profit” enterprises actually run the infrastructure. None of thesetechnologies would be necessary if the model of trust in the Internet hadn't changed so drastically.

In IPv6, the principle of end-to-end connectivity and the Internet trust model are in a constant push and pullrelationship. The end-to-end principle is behind technologies like the Session Initiation Protocol (SIP). Adherenceto the end-to-end principle simplifies routers by moving the responsibility for fragmentation into hosts. The principle is behind the simplification of IPv6 headers and greater support for options within those headers. All of

these advances happened because of the end-to-end principle, but may never be realized because strict adherenceto the end-to-end principle just isn't realistic in today's Internet. In the best case, the Internet community andothers will rise to the occasion and solve the conflict between trust and openness. In the worst case, the conflictwill be one of the forces that influence enterprises and others to reject IPv6.

Multicast: New and Improved

One of the most promising Internet technologies to come about in the many years of IPv4 development wasmulticast. Multicast is a one-to-many technology that allows many hosts (receivers) to participate in the trafficflowing from one or more other hosts (sources). It allows Internet networks to simulate the performance and theefficiency of a broadcast service, like a satellite television network. In the early IPv4 experiments with MulticastBackbone (MBONE), the IETF and others were able to broadcast important meetings, enable impromptuvideoconferences, and even distribute (albeit limited by the processing power of the computers of the day) generalinterest sporting events, concerts, movies, and other events in real-time audio and or video feeds over the Internet.

Interest in multicast never lived up to these early experiments largely because ISPs and enterprises either didn'tquite understand the technology or couldn't come to grips with the economics of multicast on an Internet scale. In particular, ISPs and enterprises were wary of a packet stream that, upon entering their networks, could multiplyinto thousands or hundreds of thousands of packets ending up on as many different end stations. Of course theconsequence of this decision is that the IPv4 world simply passed on multicast and adopted unicast to send videoand audio from web servers. As bandwidth and computing power grew in end stations the video was simplyunicast directly (witness the growth of YouTube and Yahoo! Video) to the end station.

Multicast has come back into the light for a number of reasons. First, ISPs are launching commercial televisionservices, and using multicast to do so. Cable TV networks now offer telephone services, video, and Internetconnections, which poses a great threat to traditional phone companies. The phone companies are responding by buying traditional ISPs, and companies like AT&T and Swisscom are launching commercial television servicesover Internet technology. Second, multicast is one technology that is at the very heart of IPv6.

In IPv6, multicast replaces broadcast technology on broadcast-capable networks, but that doesn't mean that eachrouter must turn on or even support multicast routing. Every router that claims to be IPv6 capable must supportmulticast in some way. This is not to say that ISPs will suddenly embrace multicast on the wide area and that theeconomics of sending multicast packets from a video provider into an ISP network will miraculously be solved. Itdoes mean that there will be interest and funding available to further multicast technology, especially as a tool for service providers to provide services like Internet Protocol Television (IPTV) in their own networks. This willtranslate into advances in technology that will ultimately benefit the enterprise community.

15




Provider Independence

At present there is no such thing as a provider-independent IPv6 address assignment. All address space isallocated to IPv6 network providers and providers in turn allocate address space to enterprise customers and

others. This would seem to be a major detractor for many enterprises, especially those that are multihomed to theInternet in some way. If there is no provider-independent space, how can the enterprise be free to change providers without a massive renumbering effort in their network?

In fact, this may be one of the biggest stumbling blocks that IPv6 put in the way of its own deployment. There isno technical reason that IPv6 addresses must depend on ISPs. The IETF (in recommendations to Internetregistries) and Internet address space registries have imposed provider-dependent address space on the Internet asa way to slow the growth of the global Internet routing table. This wasn't so much a problem that could not beovercome, as it was a shock to the status quo in IPv4, where larger enterprises routinely have their own, provider-independent IP address space.

In the Internet, when an enterprise is multihomed to independent ISPs, it usually is so to ensure that the enterprisealways has a valid connection to the Internet. Multihoming ensures that the enterprise's address space will always be advertised on the Internet. It also limits the enterprise's exposure to a backbone outage on a single provider.

In a multihoming scenario, the enterprise advertises its provider-independent address space to both providers. Theenterprise would typically arrange for one provider to advertise that space to the rest of the Internet (the orange provider in Figure 3) on a regular basis. The second provider (the blue provider in Figure 3) might only advertisethe space when it no longer hears the advertisement from the primary provider. Routing advertisements in theopposite direction (from provider to enterprise) are also split. An enterprise might receive only the routes to thecustomers attached to Provider 1 and receive a full Internet routing table from Provider 2. Multihoming in today'sInternet is a bit of an art form.

Figure 3: IPv4 Multihomed Enterprise

This scenario will only work with provider-independent address space because one provider cannot advertise thespace of another provider.

16




For IPv6, perhaps the answer is not in following accepted methods of multihoming IPv4 connections but in a newway to address the problem. There is so much IPv6 space available that the enterprise is free to get space frommore than one provider. Mechanisms are also in place to allow enterprise networks to move seamlessly from one provider to the next and face no disruption of service (seamless renumbering technology is one major benefit of IPv6 to the enterprise community and is covered in the “Address Auto-Configuration” section of this overview).In the IPv4 world, enterprises and carriers are linked by their direct connections and by the advertisement of address space that carriers make to the Internet on behalf of the enterprise.

Because there is an abundance of space, and because it is seamless to move between global address prefixes, withIPv6, we may in fact be moving to a world where the multihoming concept is broken in two, where a physicalconnection to the Internet is separate from the advertisement of a globally reachable prefix, and where enterprisesare free to move as often as they would like between ISPs without having to switch their local connectivity.

Figure 4: Potential IPv6-Connected Enterprise

In Figure 4, an IPv6-enabled enterprise is connected to a provider-neutral meeting point. Providers like Equinix,as well as Switch and Data, offer connections to such IPv4 meeting points today. The enterprise would procureIPv6 prefixes from both providers and connect to them over some type of Layer 2 network. The notion here is thatthe enterprise would be in control of which of these two providers it uses at any one time. IPv6 hosts themselvescan load share across the two connections. Hosts that provide services to the Internet, like enterprise web servers,would likely be permanently multihomed because of DNS issues. A network manager could switch from one provider to another by renumbering. The benefits of such an arrangement for the enterprise are similar to that of IPv4 multihoming above. If the enterprise maintains two or more connections across the Layer 2 fabric, it hasability to multihome hosts inside its network or move sites or entire networks between the providers with whom itmaintains a relationship.

17




The problem of multihoming is an active area of research and debate in the IPv6 community. The latest proposalwould allow organizations that already have an Autonomous System (AS) number (required for multihoming) tohave provider-independent IPv6 address space.

Innovation Solves Problems

This discussion of innovative and experimental work closes by examining one problem area for the IETF and howthe IETF has responded. The first problem that was posed to the IPv6 community after it produced initialspecifications was the problem of transition. The community responded by creating any number of ways that anIPv4 network, application, or protocol stack could be transitioned from IPv4 to IPv6/IPv4 (supporting both protocols). Some of the active tunneling technologies are outlined in Table 1 and a discussion of IPv6 tunnelingtechnologies begins below.

Because of IPv6, the Internet community has a number of new tunneling technologies. Some of these techniquesmay end up being applied to IPv4 networks, perhaps giving enterprises a new way to tunnel through the Internet.Each technology is tailored to a particular topic in networking. There are even technologies that claim tocircumvent NAT (one even claims to “bore holes through it”).

Name Use Required

6to4 Connects IPv6 through IPv4 network 6to4 capable border routers

Intra-Site AutomaticTunnel Addressing Protocol(ISATAP)

(Experimental)—automates the creation of tunnels

ISATAP software on tunnelendpoints

Teredo Bores holes in NAT devices to tunnel IPv6over UDP-4

Teredo client software, ability toconnect to Teredo servers andrelays

Tunnel Setup Protocol(TSP)

TSP automates the setup and teardown of IPv6 over IPv4 tunnels even in NAT-ednetworks

TSP client software and TSP broker/server

Table 1: IPv6 Tunneling Mechanisms

Aside from tunneling, much of the focus within IPv6 has been on IP mobility. Mobile IP is a technology thatallows a mobile node (MN) to remain connected to an Internet through a host agent. The key to Mobile IP is theability of a node to change its whereabouts (IP address) yet still remain connected to important resources as if itwere in its home environment. As discussed in the “Mobility” section of this overview, problems in Mobile IPhave fostered innovative uses of IPv6 extension headers and other technology. Enterprises that employ a mobileworkforce will certainly benefit from the capabilities of Mobile IP in IPv6.

Flow Labeling

It's easy to see how the first attribute of IPv6 (see the “General Enhancements to Networking” section of thisoverview) benefits the Internet, and the enterprise community. The benefits of the second attribute (see the “Innovative Experimental Work” section of this overview) were less obvious, and in fact the benefit of flowlabeling is a bit less obvious still.

18




A flow is a conversation between two computers: It might be as simple as a web request and response or ascomplex as a videoconferencing stream. In either case, today a flow is characterized by the 5-tuple of a source,destination, protocol type, source port and destination port. In IPv4, flows are typically detected and used byfirewalls, bandwidth accelerators, routers and other devices responsible for the transit of traffic. However, withthe focus on security—namely, encryption in IPv6—most of this information will be lost to intermediate nodes. Inorder to compensate, the developers of IPv6 put a flow label into the protocol header. Rules for using the IPv6flow label field are described in RFC 3697, “IPv6 Flow Label Specification.”

At IPv6 conferences, it is common to hear that the flow label gives IPv6 an advantage over IPv4, or that IPv6 hasa far better quality of service (QoS) mechanism than IPv4 (“just look at the flow label”). There could be sometruth to this claim, but again, the advantage isn't here today—it's just a possibility.

Enterprise network architects are familiar with the use of firewalls, and increasingly, enterprises are turning totechnologies like wide area network (WAN) performance accelerators to enhance the performance of long-haullinks (see the Reference Architecture Technical Position, “WAN Performance Optimization”). Enterprise network architects have had to be very careful in mixing these technologies. In an IPv4 network, packets must go throughthe firewall, then the bandwidth accelerator, and finally through the encryption device on their way to the router.The bandwidth accelerator confuses the firewall so the accelerator can't go first or the firewall loses track of

which flow goes where. The encryption device blinds both the firewall and the bandwidth accelerator; if theencryption device is first, no other device can see what it needs inside the packet. In this situation, the unfortunaterouter is simply out of luck, because the router can't act on what is inside each packet (i.e., the packets have beenencrypted), although a previous device may have preserved a TOS field for QoS marking inside the router.

In this sense, IPv6 is somewhat superior to IPv4 in that IPv6 makes it possible to have both integrity andauthenticity of a packet, and to preserve the ability to treat a group of packets as a flow in intermediate nodes.IPsec does not include the IPv6 flow label in its calculations, and in tunnel mode, IPsec does not alter the originalflow label of the packet. In IPv6, a flow is defined as a series of packets with the same source, destination andflow ID.

The flow label may also be an advantage for router and switch vendors. IPv4 devices that characterize packets based on flows need to look deep inside the packet. That is, they need to look past the basic packet header into theTransmission Control Protocol (TCP) header to find source and destination port information. Once found, thedevice would assemble a 5-tuple and compare it to known flows. In IPv6, all of the information required to

identify a flow is in the first 40 bytes of the packet. One final optimization: a packet with all zeros inside its flowlabel is not part of a flow and need not be compared to the devices known flows or treated as a part of any flow.

For QoS, the traffic class field distinguishes between different classes or priorities of IPv6 packets the same way itdoes in IPv4. To provide a consistent prioritization mechanism, the IETF defines the use of Differentiated Service(diffserv) bits in both IPv4 and IPv6 headers in RFC 2474, “Definition of the Differentiated Services Field (DSField) in the IPv4 and IPv6 Headers.” This support for diffserv in IPv6 essentially supersedes earlier definitions of the IPv6 traffic class octet. For its part, the design of the flow label enables the labeling of packets that belong to a particular flow and for which special handling may be required.

Authentication and Privacy

In terms of security, support for IPsec in IPv6 is equivalent to IPv4. Both networking protocols rely on the work within the Security Area of the IETF. Security is a hot topic in Internet community because the Internet didn'tstart out as a public infrastructure but it has grown into one. IPv6 does mandate the ability of a node to use IPsectechnology, which may benefit the Internet in the long run if users choose to deploy IPsec security measures.

19





To speak about security in terms of a network protocol is to speak about authentication, privacy, and integrity.There are certainly many more aspects to computer security, but they don't involve the networking protocol andare typically at the transport layer and above. In terms of authentication, it's important to know where a packetcame from and that a third party didn't tamper with it along the way (integrity). This is the equivalent of knowingthe voice of the person with whom you're speaking or being able to recognize a manufactured sound byte ontelevision by the sudden changes in background noise. Privacy of communication involves encryption techniquesto keep the payload of communication confidential. To continue the analogy, communication privacy is like awhisper between two parties that no one else can hear.

To ensure authentication, privacy, and integrity, the IETF has defined an IPsec Authentication Header (IPsec AH)and an IPsec Encapsulating Security Payload (IPsec ESP) to work inside IPv6 (and IPv4). IPsec AH uses analgorithm to ensure that an IPv6 packet has not been altered along its path and has arrived from the source listedin the IP header. IPsec ESP is used to encrypt the IP packet data using a key known only to the sending andreceiving hosts. IPsec ESP guarantees that only receivers who have the key are able to read the content of the packet. An AH may be used alone or in conjunction with an ESP header. The use of both IPsec AH and ESP aredefined in RFC 4035, “Cryptographic Algorithm Implementation Requirements for Encapsulating SecurityPayload (ESP) and Authentication Header (AH).”

So it's important to understand just what IPsec can provide, and equally as important to understand what'srequired for IPsec to function. IPv4 and IPv6 security may rely on the network layer protocol for authentication, privacy, and integrity, but real security depends on more than what an Internet protocol can realistically provide.This is why it's hard to say that an IPv6 Internet will be any more secure than today's Internet with IPv4.

In IPv6 as with IPv4, network managers will need to have a key distribution infrastructure in place to effectivelyexploit IPv6's IPsec support. It is possible to manually program each new device with security credentials but noton the scale of networking proposed for the future of the Internet.

Key distribution is hard because keys must be distributed before a secure communication happens, and gettingkeys to their destination safely requires a secure communication. Protocols like Kerberos accomplish keydistribution. One way to allow keys to be distributed without worrying that they might fall into the wrong hands isto use public key encryption and to distribute keys with PKI.

Making PKI or another method of securing Internet communication easier for an enterprise to implement andmanage is an area of intense interest and research by the IETF and others. It's a big problem because without aneasily deployed method to make communication secure and tamper-proof, an enterprise won't be able to rely onthe Internet the same way it relies on other public utilities like traditional voice phone service.

IPv6 advocates are fond of saying that another way that IPv6 will make security easier to deploy is by removingthe need for NAT, because IPv6 has a bigger address space. But there is no lightweight, automatically configuredIPv6 technology to take NAT's place. There is, however, an IPv6 version of NAT. What many in the IPv6 crowdfail to realize is that not only does NAT obscure the address space used by a network from the global routingtable, it also (advantageously) obscures the address space used from unwanted connections and unscrupulousindividuals.

The real problem with NAT and IPsec is that NAT also obscures the IP address that a host eventually uses as anInternet source address. NAT can cause a number of difficulties with IPsec. Essentially, NAT tampers with theintegrity and authenticity of every packet sent; therefore, NAT prevents certain parts of the IPsec suite (IPsec AHand IPsec ESP in transport mode) from working at all. NAT can work with IPsec ESP in tunnel mode, but with

restrictions. NAT Traversal (NAT-T) technology allows secure VPN traffic to move through a NAT device. NAT-T works by tunneling IPsec traffic through a NAT device using User Datagram Protocol (UDP). A fulldescription of NAT and NAT-T is in the Network and Telecom Strategies overview, “ NAT Traversal by Peer-to-Peer Applications: Addressing Variable Behaviors.”

IPsec aside, some IPv6 supporters believe its large address space will allow for other innovative securityapproaches, such as hosts frequently picking new addresses. Perhaps becoming a needle in a haystack (hidinghosts in a very large address space), will be equivalent to NAT, but in order to employ this as a strategy a hostwould need to change its address each time it concludes a flow. There will certainly be more innovation to comein this area.

20







What we can say about IPv6 and security is that IPv6 is an opportunity to change the inherent security of datacommunication on the Internet and elsewhere. Because IPv6 nodes require IPsec support, there is the potentialthat it will be used to provide end-to-end security in all Internet communications. It is much too early to tell if this potential to change means that overall network security will improve because of IPv6.

Improved Support for Extensions and Options

Many subtle changes in IPv6 may not be apparent except to those for whom the changes were made; for instance,the support for header extensions in IPv6 benefits equipment manufacturers by making the task of processing packets easier for routers and switches. Extension headers fall between the normal packet header and the protocolheader in IPv6. Options are variable length parameters that further define an extension header. Table 2 illustratesthe fact that most of the extension headers are processed by end nodes and not by intermediate nodes (routers).

Name Number

Use Processedby

Hop-by-HopOption

0 Explicitly source route packets

Routers

IPv6 Header 41 IPv6 in IPv6 encapsulation Optional

IPv6 Routing 43 Routing Header Nodes

IPv6 Fragment 44 Fragmentation Header Nodes

ESP 50 Encapsulating SecurityPayload

Nodes

AH 51 Authentication Header Nodes

ICMP 58 ICMPv6 Nodes

NO NXT 59 No next header Nodes

Options 60 Destination options for IPv6 Nodes

Table 2: Defined IPv6 Header Extensions

One case in point—in IPv6, intermediate nodes no longer fragment packets; the originating and terminating nodesin the packet flow perform that task. In fact, routers must process only one extension header in IPv6, the hop-by-hop option header, which is like a loose source route packet in IPv4. In terms of the Fragmentation Header, IPv6restricts packet fragmentation to IPv6 source and destination nodes, and does not permit intermediate IPv6 nodesto fragment packets. This contrasts with IPv4, in which packets can be fragmented anywhere in the path,depending on the capabilities of the transmission links. For its part, the Internet Control Message Protocol version6 (ICMPv6) header allows IPv6 nodes to communicate errors and perform diagnostic functions.

21




An IPv6 router must certainly process ICMPv6 headers, but this occurs in routers that are party to theconversations, not in intermediate nodes. For instance, routers that receive packets that are too big for the nextlink's maximum transmission unit (MTU) originate ICMP “packet-too-big” messages, which are sent back to thesource of the transmission. In this case, the router is the originator of the extension header.

The destination options header for IPv6 has been used in interesting ways. In the Mobile IP specification (see the“Mobility” section of this overview), destination options are used to carry the home address of the mobile node(MN). When a correspondent node (CN), or the destination of a flow from an MN, receives such a packet, it places the home address of the MN in the header of the packet that it passes to the upper layer protocols. In thisway, applications are fooled into thinking that they are communicating with the MN at its home location. Thecomplexity of Mobile IP is thereby hidden from applications, and those applications behave as if the MN weresimply at home.

Extension headers will likely be added to the list provided in Table 2 over time. One of the benefits of IPv6 is thatthe extension header is a flexible mechanism that can be used over and over as the IPv6 protocol matures. Rightnow, the design of many of the extension headers and options decrease the load on intermediate nodes so that theycan become faster and easier to build, but the advantage to this optimization may not be apparent until thoserouters no longer have to support IPv4. For instance, IPv6/IPv4 routers will continue to support fragmentation and

other options in IPv4.

Header Format Simplification

When compared side by side (seefigure 20), the IPv4 and IPv6 headers don't seem all that different. Allowing for the expanded address space in IPv6, they are similar in size; the basic IPv4 header is 20 bytes in length (withoutthe options field) while the IPv6 header is 40 bytes. On the other hand, there are 14 fields in the IPv4 header (plus padding), while there are only 8 fields in the IPv6 header. Consider that the IPv6 addresses consume 80% of thespace in a header, whereas in IPv4 they consume only 40%. With source and destination address removed, theIPv4 header is 1.5 times the size of the IPv6 header.

Some fields from the IPv4 header are no longer required in IPv6. For instance, the identification, flags, andfragment offset fields are not required in IPv6 because intermediate nodes (routers) cannot fragment packets (seea discussion in the “IPv6 in Wide Area Networking” section of this overview). Fragmentation, if required, is

handled end-to-end by hosts. The header checksum is not included, given that other protocols embed a checksum,and link layers compute and verify a checksum before the packet reaches the IP layer. The IPv4 and IPv6 versionfields are identical in meaning. In IPv6, some fields have simply been renamed. The IPv6 traffic class field isidentical to IPv4's type of service (TOS) field (as defined by RFC 2474), IPv4's time to live (TTL) field is IPv6'shop limit field, and the IPv4 protocol field and IPv6 next header field are coincident—although the use of the nextheader field has been expanded to indicate the presence of the options field. The content of the options field (seefigure 20) has moved to an IPv6 extension header.

Many texts, including IETF RFCs, state that relative to IPv4, the IPv6 header has been simplified. While this istechnically true, because removing fragmentation and the checksum in the header has reduced its extent, it is notentirely accurate. A more accurate description might be that the IP header has been redefined in IPv6 andoptimized for packet processing. This new header definition greatly benefits intermediate nodes (routers) in anetwork and will make it much easier to produce wire-speed devices in the future. In IPv6, routers benefit fromthe definition of a 40-byte, fixed-length header. In IPv4, the header can be of variable length.

This is an important improvement, given that many modern router designs utilize very complex hardwareapplication-specific integrated circuits (ASICs) that copy and process only the header of a packet. Having a fixed-length header simplifies the design of an ASIC. Headers that are complex, full of options or not defined at thetime that an ASIC was designed might be required to travel a slower path through the router. Those “slow-path” packets would also consume more resources on their trip through a router. The situation for routers is further improved in that IPv6 routers must process only one type of next header field (IPv6 Hop-by-Hop Option, seeTable 9) and are no longer required to fragment packets.

22




Allowing IPv6 headers to daisy chain within a packet has simply relocated most of the complexity that the authorsclaim to have removed from the IP header. RFC 2460, “Internet Protocol, Version 6 (IPv6) Specification,” definesthe next header field—how headers should be handled by intermediate nodes and in what order they shouldappear. Next header field values are registered numbers with the Internet Assigned Numbers Authority, or IANA(see http://www.iana.org/numbers.html), and appear in RFC 3542.

Expanded Addressing Capabilities

The original goal for the IPng protocol was based on the urgent need for more address space. With 128-bitaddresses, (the IPv6 number space contains enough addresses to configure 6.65 x 10^23 unique devices per square meter of the earth's surface), IPv6 has achieved this goal for our planet and perhaps all future colonies inspace.

In a parallel effort, the IETF changed the address usage, routing, and allocation policies for IPv4 from “classful”to “classless.” Removing the notion of Class A, B, and C networks from IPv4 with CIDR, for example,significantly slowed consumption of IPv4 address space. Consumption slowed further as IPv4 introduced NAT.

At this point the pessimists in the IPv6 community will begin to mutter under their breath about the sinister natureof NAT, and the optimists will begin a wild-eyed dissertation on the usefulness of IPv6-enabled wall sockets. Theanswer lies somewhere in the middle. Having a bigger address space will bring about benefits to the Internetcommunity. We simply do not know if or where or when those benefits will appear.

Other Areas of Note

The Internet relies on a number of other systems that are affected in some way by the introduction of IPv6.

Domain Naming System

DNS is one operational area in the Internet that continues to struggle with IPv6. Some of the current issuessurrounding IPv6 and DNS are documented in RFC 4472, “Operational Considerations and Issues with IPv6

DNS.”

Layer 2

IPv6 has been shown to work over a number of link-layer or Layer 2 technologies. For the convenience of thereader, some of the more popular technologies are listed in the “Link Layers” section of this overview together with the RFCs that specify IPv6 over that particular Layer 2 technology. Some of the link layers operate quitedifferently with IPv6. The Point-to-Point Protocol (PPP), for instance, derives great advantage from running IPv6when compared to IPv4.

IPv6 Routing

For the most part, the fundamental mechanism of each routing protocol remains unchanged. The modificationsgenerally are needed to accommodate IPv6's larger address size and its addressing structure. For example, under IPv6, Open Shortest Path First (OSPF) runs on a per-link basis rather than per IP subnet, as is the case with IPv4.Support for IPv6 has also been added to proprietary protocols, like Cisco Systems' Enhanced Interior GatewayRouting Protocol (EIGRP), although any move to IPv6 may provide a good time for an enterprise to discontinuethe use of a proprietary protocol.

23




http://www.iana.org/numbers.html




But more than this, while all of the major routing protocols are equipped to deal with IPv6, some of them (namelyIntermediate System-to-Intermediate System [IS-IS]) have only one notion of a topology database. This meansthat if the IPv4 network and IPv6 network don't share the exact topology (IPv4 and IPv6 on all links andinterfaces), the protocol must be run once for the IPv4 topology and once for the IPv6 topology.

Recommendations

The “Analysis” section of this overview does not advocate a transition to IPv6. Instead, it points out areas in theIPv6 specifications from which a number of large enterprises are currently deriving some benefit. There areexamples of real benefits to be realized from the work of the IPv6 effort.

In enterprise networks, if there is a likely scenario for an IPv6 deployment, it will be a niche deployment of IPv6.Someone will discover a facet of IPv6 networking that allows the enterprise to accomplish a particular goalquickly or cost effectively when compared to the corresponding methods in IPv4. From there, the nichedeployment will expand, requiring enterprise-wide connectivity and perhaps even global connectivity.

Today most of the niche deployments occur in large enterprises and government organizations with the

deployment of sensor technology, security, building management, and warehousing. The potential benefit of IPv6for each enterprise cannot be known until someone, who is familiar with the IT problems that plague that specificenterprise, receives an education in the technology. For each and every enterprise, taking full advantage of those benefits will depend on a number of common factors:

• Education

• Innovative thinking

• Enterprise self-awareness

• Acceptance of risk

Education

The first step in any project involving IPv6 is education. Returning to the analogy of IPv6 as a foreign language,

every language teacher knows that the only way to “help stamp out foreign languages” is to learn one. The“Analysis” section of this overview has shown that there is sufficient reason for a large enterprise to be interestedin IPv6, regardless of how the politics of IPv6 play out on the Internet. IPv6 deployment will happen in the user community and migrate to the Internet rather than the other way around. There won't be a transition or a migrationuntil the enterprise community, after a series of niche deployments, pushes service providers to adopt IPv6.Regardless of what the press, analysts, or any rabid promoter of IPv6 may believe, ISPs will not deploy IPv6without a demonstrated need.

A number of training and consulting organizations offer help in this area. Some offer simple training while othersoffer training, consulting, and deployment services. Selecting an organization should be based on what theenterprise is willing or able to accomplish with IPv6. There are even programs to “train the trainers,” where anorganization allows one or more employees to shadow a group of developers for some period after initial training.In this way, an enterprise might gain a qualified IPv6 application programmer who is able to train other staff on-site.

Learning a new networking protocol isn't all that difficult. IPv6 has a different way of looking at the world butmany of the basic concepts are similar to that of IPv4 (or Internetwork Packet Exchange [IPX], AppleTalk,Digital Equipment Corporation Network [DECnet], or Connectionless Network Protocol [CLNP] for that matter).Once members of staff, especially network architects and application architects have been trained in the basics of IPv6, they should be encouraged to begin thinking about ways they might use the protocol to solve everyday problems. The “Analysis” section of this overview points out some of the more fruitful areas of networking(sensor technology, auto-configuration, Mobile IP, etc.) that large enterprises are investigating and benefitingfrom today.

24




Innovative Thinking

Once employees are trained in the basics of the IPv6 protocol they should begin to think of ways to use thetechnology to the benefit of the enterprise. For this reason, network architects and application architects should besome of the first employees to receive the training. The early adopter in the company should be an employee whohas a grasp of the needs of the enterprise and is presented with real-life problems in the enterprise as a matter of routine in his or her work.

Architects tend to be accomplished members of the IT staff with a broad understanding of the enterprise and of their area of technology. Innovative thinking, however, isn't something that can be taught or demanded of anemployee and there may be instances where a more junior (or senior) employee is a better choice for initialtraining. To get the most from any IPv6 effort, choose early adopters who are not afraid to propose new ideas or think outside the box.

Self-Awareness

Early adopters should also be familiar with a broad scope of IT issues within the enterprise. Educating IT staff

with a broad knowledge of the enterprise, its current best practices, its goals, and the goals of separate divisions(if applicable) will give the early adopter more problems to choose from when looking for potential applicationsfor IPv6 technology.

The early adopter should have some knowledge of the enterprise's appetite for risk. Any discussion of thedeployment of a new IPv6 technology should go through some type of peer review, but even so an early adopter should be mature enough to understand which applications are likely to fly and which are not. The next step after the early adopter identifies an area in which IPv6 will benefit the enterprise is a technology trial. To make such athing happen within a large enterprise, an executive champion for the potential project may benefit from an IPv6education.

Acceptance of Risk

Some enterprises have a large appetite for risk and some do not (see the Reference Architecture Principlesdocument, “ Network and Telecom Principles,” for further discussion). Some believe that any opportunity to getahead must be taken regardless of the likelihood of success. Some believe that no risk is acceptable: They stick with a technology until it is no longer available and only then consider a change. Many in the business world aremore moderate and believe that any technology that gives the enterprise a competitive advantage is worth a risk.Technologies that cannot bring competitive advantage to a business are purchased at lowest cost or best businessfit.

No matter how the enterprise views technology and technology risk, any early adopter should be aware of theseguiding principles before he or she journeys into the world of IPv6. As a new technology IPv6 presents someinherent risk. At the outside, the Internet community may abandon IPv6 altogether, it may just be too big a leapand rely on too many lofty goals put forth by researchers and academics without regard for the networkingenvironment we have today. Of course it may be just as likely that IPv6 will take off at an exponential rate in Asiaor in Europe and force global enterprises to rush to deploy the technology in catch-up mode.

The truth will likely be somewhere in the middle. In enterprise networks, the most likely scenario in the next twoto three years will be a niche deployment of IPv6. An early adopter may discover a facet of IPv6 networking thatallows the enterprise to accomplish some goal quickly or cost effectively when compared to the correspondingmethods in IPv4. From there, the niche deployment might expand, requiring enterprise-wide connectivity and perhaps even global connectivity. After all, that's the way that IPv4 took over the world from IPX, Systems Network Architecture (SNA), Extensible Name Service (XNS), Open Systems Interconnect (OSI), and others.

25





The Details

The basics of Internet Protocol version 6 (IPv6) have changed greatly in its 10 years of development. Many thingshave been added and expanded. Others have been deprecated. A number of excellent texts cover this information(some of them are listed inAppendix A of this overview). By following this overview with one or more of thesetexts as a guide the reader can gain a much more in-depth understanding of IPv6. Note that all current Requestsfor Comments (RFCs) and drafts are available through the Internet Engineering Task Force (IETF) website. A listof the most pertinent RFCs is inAppendix A of this overview. To search for particular topics, direct a browser tohttp://tools.ietf.org or to http://www/ietf/org/rfc/rfc<number>.txt (where <number> corresponds to the RFC inquestion).

One way to learn a networking protocol is to follow a host or node as it moves through the various steps to enable basic connectivity. This section of the overview begins with a discussion of basic address formats and how nodesuse those addresses. In this text, the term “host” refers to a computing device that participates in an IPv6 (or IPv4)network. The term “router” refers to a device that enables connectivity between networks of hosts. The term“node” is a generic term that includes both hosts and routers.

“The Details” section continues through the stateless or stateful configuration of an IPv6 node with one or moreinterfaces and addresses. The topics then branch into specific treatment of IPv6 requirements for hosts androuters, required communication between nodes (e.g., Duplicate Address Detection [DAD], or Neighbor Discovery) and communication particular to certain network types (Ethernet or Point-to-Point Protocol [PPP]). Next, the text examines topics in wide area networking; for example, IPv6 routing and Domain Name System(DNS). The reader should be familiar with many of these topics as they are similar to the requirements of hostsand routers in an IPv4 Internet. Finally, some items are peculiar only to IPv6, such as the treatment of MobileIPv6 and strategies for “transition” from IPv4 to IPv6. Other than the IPv6 flow label, which is treated inTable 8,note that neither security nor quality of service (QoS) deserve any special treatment in an overview of IPv6 because they do not differ appreciably from that of IPv4.

Simple Network Example

It is useful to have this simple network example of a host and a router attached to an Ethernet to illustrate some of the IPv6 concepts.

Figure 5: Simple Network Example

The IPv6 Address Format

IPv6 addresses are 128-bit identifiers assigned to device interfaces and sets of interfaces, not to nodes. A nodemust have at least one but also may have many more IPv6 addresses. The basic structure of an IPv6 address isshown in Figure 6. An IPv6 address is a 128-bit identifier that is split into fixed portions to identify the network,subnet and interface of a node.

26


http://tools.ietf.org/



Figure 6: IPv6 Addressing

Representation in Text

As we all know, an IPv4 address is written as a series of four decimal numbers, each representing eight bits,separated by period (.). This ‘dotted-decimal' notation has become a staple of life for the network administrator.The human readable form of the IPv6 address may be a poor substitute as it is difficult to commit to memory. In atext, IPv6 addresses are written as a series of eight hexadecimal fields, each representing sixteen bits, separated bycolons (:). A typical IPv6 address can be written as:

2001:1234:0000:0000:06C0:ABFF:FECD:1234

To make the notation simpler, the address can be reduced by the following rules:

• Leading zeroes within a field may be suppressed.

• Contiguous fields containing all zeroes may be represented as “::” (to prevent ambiguity, this may happen onlyonce in an address).

Applying these rules to the address above yields:

2001:1234::6C0:ABFF:FECD:1234

Address prefixes may also be represented in this way with the addition of a Classless Inter-Domain Routing(CIDR)-like notation for the size of the address (recall that IPv4 CIDR prefixes are represented asADDRESS/LENGTH as in 192.168.0/24). For instance, in the example above, the site network portion of theIPv6 address is:

2001:1234:0000/48This would represent the range of IPv6 addresses available to networks and hosts in this particular site. If thisnetwork were attached to a global IPv6 Internet, this might also represent the routing entry for the site. The fullhost address might also be used to show a network number and host ID split as:

2001:1234:0000:0000:06C0:ABFF:FECD:1234/64 or 2001:1234::6C0:ABFF:FECD:1234/64

This identifies the network portion [2001:1234:0000:0000] and host portion [06C0:ABFF:FECD:1234] of theaddress.

Representation in a URL

One of the difficulties encountered with this notation occurs when trying to type an IPv6 address into a web browser as part of a Uniform Resource Locator (URL). The colon character at the end of a URL is used to denote

a port number; therefore, to avoid confusion, the IPv6 addresses must be typed into a browser in brackets, as in:

http://[2001:200::8002:203:47ff:fea5:3085]

Or in expanded form (with port number):

http://[2001:0200:0000:8002:0203:47FF:FEA5:3085]:80/index.html

Which, by the way, is a working IPv6 website.

27




Types of Address

IPv6 supports three address types—unicast, anycast, and multicast. There is no concept of a broadcast address in

IPv6; multicast addresses in IPv6 have superseded the broadcast address in IPv4. The use of multicast has beengreatly expanded with the IPv6 specifications, so it is worthwhile to spend the time to understand the specifics of multicast and multicast routing.

An important aspect of the IPv6 addressing structure is that it allows for a flexible global routing hierarchy. Ineffect, IPv6 addressing separates the public network topology from a local site's network topology. Thisseparation becomes clear when we examine the structure of unicast addresses. A unicast address is an identifier for a single interface on a node. Anycast addresses are a special case of the unicast address that identifies multipleinterfaces on one or more nodes. The IETF has defined several forms of unicast address, including aggregatableglobal unicast addresses, local use addresses, and anycast addresses.

The IETF has also defined and deprecated the use of IPv4-compatible host addresses, Internetwork PacketExchange (IPX) addresses, and Network Service Access Point (NSAP) addresses. They may define (or deprecate)other types in the future.

Link Local

Any of the unicast addresses associated with any of a node's interfaces may be used as an identifier for that node.Each interface on an IPv6 node is required to have at least one link-local unicast address.

The link-local address is for use on a single link. With it, the node can communicate locally for auto-addressconfiguration, Neighbor Discovery, or with local resources like printers. All hosts must have at least one link-local address. Once an interface determines its link-local address, it can communicate with other resources on thelink including routers and Dynamic Host Configuration Protocol (DHCP) servers. Link-local addresses enablelocal functions when no routers are present on a link. Routers must not forward packets with link-local source or destination addresses to other links. Figure 7 illustrates the format of the link-local address.

Figure 7: Link-Local Address

Unique Local

In the early IPv6 specifications, developers wanted to mimic the facility of private address space (see RFC 1918).They did so first in RFC 2373 (which is Obsolete and replaced by RFC 4291) with the concept of a site-localaddress. What the developers found, through experience, was not that the site-local concept was essentiallyflawed, but that it was very hard to explicitly define the concept of a “site.” Given this difficulty, site-localaddresses were often ambiguous in scope. Site-local addresses were intended for use by organizations in wayssimilar to the way in which private address space (i.e., 10/8) is used today in IPv4. Unfortunately, an enterprisemay use addresses from private space in one or many sites, across virtual private networks (VPNs) or just within a backbone. In RFC 3879, the IETF deprecated the use of site-local addressing without any replacementtechnology. Most recently, a new RFC 4193 suggests a replacement in unique-local addresses.

Unique-local IPv6 addresses are intended to be a globally unique identifier that is for use only within a site. Giventhat they are globally unique, the fuzzy definition of “site” can no longer cause them to be ambiguous. In addition,as enterprises merge or decide to connect in some way there will not be collisions of IPv6 local address space.Applications may treat unique-local addresses as if they were globally unique, although packets with unique-localsource or destination addresses will not cross the boundaries of a site.

28




The unique-local address contains a 7-bit prefix that begins with FC00::/7 (FC00 through FDFF...). The next bitidentifies local assignment and is set to “1” (0 is reserved for future use). Generating a unique identifier asdescribed in RFC 4193 forms the 40-bit global ID. The unique identifier can be generated once for a site and is acomputation based on a local machine's 64-bit Extended Unique Identifier (EUI-64) address and the current timeof day as reported by the Network Time Protocol in 64-bit format. The format of the address is listed in Figure 8.

Figure 8: Unique-Local Address

Global Unicast

The global unicast address is how users will connect to the IPv6 Internet. Global unicast addresses represent thelargest portion of IPv6 address space yet assigned. This type of address can be identified as having 001 as the firstthree bits (3 leftmost bits) in the 128-bit address. Any address that lies between 2000:: and3FFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF is an IPv6 global unicast address. The entire address space may be represented as 2000::/3, which constitutes 13% of the total available address space. The remaining 86% of IPv6 address space is as yet unassigned and undefined. Figure 9 illustrates the global unicast address format.

Figure 9: Global Unicast Address

AnycastAn anycast address is an identifier for a set of interfaces, each typically belonging to different nodes. Whenconnecting to an anycast address, the connection is directed to the closest node advertising the address (by virtueof network topology and as decided by IP routing). Anycast addresses allocated from the unicast address spacemay use any of the defined unicast address formats. Reserved anycast addresses may identify the set of routersattached to a particular subnet or the set of routers providing entry into a particular routing domain.

Anycast addressing is an informal networking concept in IPv4 that has been made more formal in specificationsof IPv6. One of the first uses of the anycast address concept was to advertise a set of redundant DNS resolvers tohosts. Because resolvers were inherently kept in sync, it didn't matter to which resolver a user would connect inorder to resolve a host name. Using anycast, the user machine would automatically connect to the nearestresolver; if that resolver became unavailable, the user would use the next-nearest resolver, and so forth.

Packets that are delivered to anycast hosts rely on host routes for delivery. Because the routing in a network may

change from time to time, each router's notion of the closest anycast host to one node's location is also prone tochange. A client of a service that is anycasted may connect to different nodes on different occasions depending onthe state of routing in the underlying network. If routing were to change while a node were connected to ananycast host address, the conversation would be redirected to the next nearest node. The new node (with the sameanycast address) would have no context for the previous connection and the connection would likely be reset. For this reason, the IPv6 documents recommend that anycast only be used as a mechanism to locate the closest node,and persistent connections only be established through that node's regular unicast address. In IPv6, unlike IPv4,an anycast address must be explicitly configured in a node. In practical terms, anycast works well with User Datagram Protocol (UDP) connections (such as DNS query), which are short-lived.

29




In IPv6, an anycast address (other than a well-known anycast subnet address) is indistinguishable from a unicastaddress. By simply allowing two nodes to be configured with the same unicast address, that address becomes ananycast address. Anycast addresses only operate in one region of a network. That region is defined by the longestaddress prefix in IP routing tables where all of the nodes configured with the anycast address are reachable. If theanycast address has unique-local scope, the anycast will only work within that scope. Routes for anycast hosts aretypically host routes or /128 routes (a /128 route defines reachability to one host in a network). Care must be takento balance the number of host routes against the need for anycast hosts to operate within a region of the network.

There are two well-defined anycast addresses defined in IPv6. The first is the all-subnet-router anycast address. A packet sent to this address will be delivered to the closest of the routers that is active for that subnet. The addresshas the format:

Figure 10: Anycast Address

In Figure 10, “n” indicates that the size of the routing prefix is variable in length and the interface ID is set to zerofor the address. Given the IPv6 address used in previous examples:

2001:1234:0000:0000:06C0:ABFF:FECD:1234

The all-subnet-router anycast address would be:

2001:1234:0000:0000:0000:0000:0000:0000 or 2001:1234::

The other well-defined anycast address is defined in RFC 2526. This address is defined as a well-known anycastaddress to facilitate Mobile IPv6. The generalized form of “Reserved IPv6 Subnet Anycast Addresses” is shownin Figure 11; the current assignments are shown in Table 3.

Figure 11: Reserved IPv6 Subnet Anycast Addresses

Decimal

Hexadecimal

Description

127 7F Reserved

126 7E Mobile IPv6 Home AgentsAnycast

0–125 00–7C Reserved

Table 3: ID Values for IPv6 Anycast

Special Case Unicast Addresses

30




A few special case IPv6 addresses have been defined by the IETF. The first is the local host or loopback address.This address is used by processes to communicate internally or by the Internet protocol to verify connectivitywithout using a physical interface. The behavior and use of this address is the same as the IPv4 127.0.0.1 address.The IPv6 loopback address is 0:0:0:0:0:0:0:1 or ::1. As a first IPv6 experiment, type the following into an IPv6-enabled workstation:

Server:~/Desktop young$ ping6 ::1

PING6(56=40+8+8 bytes) ::1 --> ::1

16 bytes from ::1, icmp_seq=0 hlim=64 time=1.612 ms





--- localhost ping6 statistics ---

5 packets transmitted, 5 packets received, 0% packet loss

round-trip min/avg/max = 0.109/0.447/1.612 ms

If IPv6 is active on the machine, ping or ping6 should produce the results above.

The next address is the unspecified address. In IPv4 it is called the default or null address. This address is oftenused within routing protocols to signify the gateway of last resort or default route. In IPv4 this address is 0.0.0.0/0and is similar in IPv6: 0:0:0:0:0:0:0:0, :: or ::/0.

Transition Addresses

These addresses are used in various transition schemes between IPv4 and IPv6 networks.

6to4

The 6to4 address is a special case global unicast address intended to be used as part of a transition mechanism.The mechanism of 6to4 is discussed in the “6to4 Dynamic Tunneling” section of this overview. As defined inRFC 3056, 6to4 essentially treats the IPv4 Internet as a point-to-point infrastructure and enables IPv6 in IPv4tunnels without explicit setup. 6to4 addresses are implemented in border routers that connect to both an IPv6network and to the IPv4 Internet. The format of a 6to4 address is shown in Figure 12.

Figure 12: 6to4 Address

IPv4 Mapped IPv6

The Internet Protocol Next Generation (IPng) Working Group defined a second type of IPv6 address that holds anembedded IPv4 address. Termed “IPv4 mapped IPv6 addresses,” this type of address is used to represent theaddresses of IPv4 nodes as IPv6 addresses. The format of this type of address is illustrated in Figure 13.

31




Figure 13: IPv4 Mapped IPv6 Address

This address has been used in a number of transitions mechanisms, including mechanisms to alter applicationssuch that they will work with IPv4 and IPv6.

Teredo

Very recently, the IETF published the Teredo mechanism, which has another address format shown here. Teredois a tunneling mechanism intended to work across Network Address Translation (NAT) devices. It is supported ina number of operating systems including Windows 2003 Server, Linux, and Mac OS X.

Figure 14: Teredo Address

Multicast

A multicast address is an identifier for a set of interfaces, typically belonging to different nodes. A packet sent toa multicast address is delivered to all interfaces identified by that address. Multicast addresses include a 4-bitscope field that's used to limit the scope of a multicast group. In general, the higher the value in the scope field,the wider the scope.

As with the anycast address, the IPng Working Group has placed some restrictions on the use of multicastaddresses. Multicast addresses may not be source addresses in IPv6 packets or appear in any Routing Header, androuters must not forward multicast packets outside the scope indicated by the scope field. A number of multicastaddresses are reserved in IPv6 for particular applications. A few examples are the all-nodes, all-routers, and all-ntp-servers. (For a list of well-defined IPv6 multicast addresses, see http://www.iana.org/assignments/ipv6-multicast-addresses.)

Figure 15: Multicast Address

Unicast Prefix-Based IPv6 Multicast

Multicast interfaces are configured when a node expects to receive packets on that interface from a multicastgroup ID. In RFC 3306, the IETF specifies a way to derive multicast addresses dynamically, based on a unicastaddress. This type of interface might be used for listening or for source-specific multicast.

32


http://www.iana.org/assignments/ipv6-multicast-addresses

http://www.iana.org/assignments/ipv6-multicast-addresses



Figure 16: Source-Specific Multicast Address

In a source-specific multicast address, the P bit is set to “1,” the prefix-length (PLEN) field is set to “0,” and thenetwork prefix is also set to “0.” During the source-specific multicast, the source address field of the IPv6 header specifies the owner of the multicast session.

If our previous example node wished to broadcast an audio session as a source-specific multicast to the globalInternet, it would use the address:

FF38:000:0000:0000:0000:0000:<Group ID>

The Group ID may be selected by the host or by an administrator.

Special Case Multicast Addresses

The Internet Assigned Numbers Authority (IANA) maintains the list of permanently assigned numbers for theInternet. As mentioned, the IANA has a list of permanently assigned IPv6 multicast addresses but there are a fewaddresses to mention specifically as they will aid in the understanding of future topics in IPv6. The first is the all-nodes address:

FF01::1—All nodes with interface-local scope

FF02::1—All nodes with link-local scope

The next set of addresses specifically concern routers:

FF01::2—All routers with interface-local scope

FF02::2—All routers with link-local scopeFF05::2—All routers with site-local scope

Solicited-Node Multicast Address

Since there are no broadcast addresses in IPv6 networks, there must be ways to communicate with nodes whentheir addresses are unknown to the sending party. The all-nodes multicast address is one way to do this but thereis a more elegant way to communicate with a host whose IPv6 address is unknown.

Figure 17: Solicited-Node Multicast Address

All nodes must compute and join the solicited-node multicast address for each of their configured unicast andanycast addresses. A node computes this address by taking the low order 24 bits of the corresponding address andappending those bits to the address format listed in Figure 17. In the previous example of an IPv6 aware host, thehost had an interface address defined as:

2001:1234:0000:0000:06C0:ABFF:FECD:1234

33




This host is required to listen to the multicast address:

FF02:0:0:0:0:1:FFCD:1234

Link-Scoped Multicast Address

The goal of link-scoped multicast addressing is to provide an easy way for hosts to derive a link-local multicastaddress. This method is considered superior to the method above but is only valid for scope of less than or equalto a value of “2.”

Figure 18: Link-Scoped Multicast Address

The scope of this type of address must be less than or equal to “2” for link-local. The PLEN field is set to all one's(FF) and the Group ID may be assigned in various ways so that there are no collisions on the host. Self-assignedGroup IDs must be between 0x80000000 and 0xFFFFFFFF.

Table 4 is an attempt to list allowed values for the fields in a multicast address. It is compiled from a number of RFC sources to serve as a guide. Application programmers should rely on the original texts for an authoritativesource of this information.

Field Content Values

Meaning

Flags (F) 0 (must be zero)

R (rendezvous point) (see RFC

3956)P (prefix) (see RFC 3306)

T (transient) (see RFC 4291)

0

0

1

0

1

0

1

Required

No rendezvous point

Rendezvous point embedded inaddress

Not derived from address prefix

Derived from address prefix

Temporary assignment

Permanent assignment from IANA

Scope (S) Binary values 0000

0001

0010

0100

0101

1000

1110

Reserved

Interface-local scope

Link-local scope

Admin-local scope

Site-local scope

Organization-local scope

Global scope

Reserved 0 (must be zero) 0000(h)

Required

34




PLEN Prefix-length value 0000(h)

Length of network prefix

Prefix Assigned IPv6 prefix 2000::/3

Prefix of enterprise owning address

InterfaceID

EUI-64 or ? Interface ID as assigned

Table 4: Multicast Address Fields

Configuration of a Node

IPv6 nodes have multiple addresses on each interface. They are configured in order such that the node comes up

on the local link, discovers resources on the local link like peers and routers, and then, based on information fromits peers and local routers, is able to configure globally routable addresses.

Link Local

One of the first things that a node does when its network interfaces are activated is create its link-local address.Link-local addresses are typically configured using a defined procedure. The result of this procedure is called a64-bit Extended Unique Identifier (EUI-64) address (seehttp://standards.ieee.org/regauth/oui/tutorials/EUI64.html). To create an EUI-64 address from an Ethernet mediaaccess control (MAC) address (EUI-48) first split the 48-bit address into equal parts. Insert the 16-bit string“FFEE” into the address in the middle, and insert a “1” in the seventh bit of the leftmost byte to signify that thisaddress is globally unique:

Operation Intermediate Result

MAC address 04:C0:AB:CD:12:34

04C0:ABCD:1234

Split into parts insert“FFEE”

04CO:ABCD:1234

04C0:ABFF:FECD:1234

Leftmost byte expanded 04 (h) =00000100

Flip bit 7 00000110 = 06(h) 06C0:ABFF:FECD:1234

Resulting EUI-64 06C0:ABFF:FECD:1234

IPv6 link local FE80::6C0:ABFF:FECD:1234

35


http://standards.ieee.org/regauth/oui/tutorials/EUI64.html



Table 5: EUI-64 Address Configuration

IPv4 link-local address configuration is described in RFC 3927. Unlike IPv6 link-local addresses, this facility isnot a mandatory configuration on the IPv4 interface. Automatic address configuration in IPv4 has been

implemented but its purpose is different from IPv6 auto-configuration. IPv4 auto-configuration is intended to provide a working dynamic address, dynamic naming, and browsing for resources on a local area network (LAN)when normal means of configuration like DHCP aren't available. There are implementations of IPv4 auto-configuration in major operating systems (Bonjour for Windows, Apple Mac OS X, and Linux). Because notmany information technology (IT) users are aware of the IPv4 auto-configuration standard, seeing an auto-configured interface (it uses the 169.254/16 address space) often only reminds the user to plug in his or her Ethernet cable. Useful auto-configuration for the wide area in IPv4 requires some type of server-basedmechanism.

The IETF has also formally defined the notion of IPv6 Address Scope in RFC 4007. The scope of an IP address(IPv4 or IPv6) is the sum total of networks for which the IP address is valid. The scope of an address is crucial tothe concept of a multicast address. But for link-local unicast addresses, the scope is limited to the interface onwhich the address is defined. For instance, in the example infigure 5, the address FE80::6C0:ABFF:FECD:1234would be valid only on the local Ethernet to which our example machine is attached.

Machines such as routers with multiple interfaces require special thought with regard to scope and link-localaddressing. A router will likely have multiple link-local IPv6 addresses, one for each of its interfaces. Tocommunicate with other nodes on a network of link-local scope, the user must specify the interface on which tosend the packet. For instance, from the router attached to the example Ethernet segment above:

router>ping6 fe80::6C0:ABFF:FECD:1234

This address is ambiguous, even though the host portion of the address is globally unique. However, adding aninterface ID to the end of the command produces the desired result (in FreeBSD syntax):

router>ping6 fe80::6C0:ABFF:FECD:1234%fxp0

Neighbor Discovery Protocol

The Neighbor Discovery protocol, defined in RFC 2461, corresponds to a combination of IPv4 protocols,including the Address Resolution Protocol (ARP), Internet Control Message Protocol (ICMP) Router Discovery,and ICMP Redirect. IPv6 Neighbor Discovery defines five different ICMP packet types: a pair of Router Solicitation (RS) and Router Advertisement (RA) messages, a pair of Neighbor Solicitation and Neighbor Advertisement messages, and a Redirect message.

Neighbor Discovery is required by all types of address configuration and is vital to auto-configuration. In essence,a network device connecting to a network for the first time can use the Neighbor Discovery protocol to learn allthe parameters necessary to function on a subnet.

For example, hosts and routers use the Neighbor Discovery protocol to determine link-layer addresses for neighbors known to reside on attached links, and to quickly purge cached values that become invalid. Hosts alsouse Neighbor Discovery to find neighboring routers that are willing to forward packets on their behalf.

Since router discovery is part of the base Neighbor Discovery protocol, there's no need for hosts to “snoop” on the

routing protocols. (Some router and operating system vendors do support the Router Discovery Protocol, whichallows for the discovery of routers on an IPv4 network, but support is not widespread.) RAs carry link-layer addresses, so no additional packet exchange is needed to resolve a router's link-layer address. RAs also enableaddress auto-configuration, which we discussed earlier.

Finally, nodes use the protocol to actively keep track of which neighbors are reachable and which are not, and todetect changed link-layer addresses. When a router or the path to a router fails, a host actively searches for functioning alternatives. With the Neighbor Unreachability Detection part of the base protocol, for example, packet delivery is more robust in IPv6 than in IPv4, as IPv6 nodes can quickly respond to failures and to changesin link-layer addresses.

36




Router Advertisement

IPv6 routers have a number of additional tasks to perform when compared to IPv4 routers. When an IPv6 router interface is enabled on a network, the router begins to send periodic (5-minute) Router Advertisements (RAs)onto each network segment to which it is attached. In order to mimic this facility in an IPv4 network, a host wouldtypically have to run a routing protocol such as Routing Information Protocol version 2 (RIPv2) with the localrouter. An RA is a message intended for hosts on the network and contains information about the link. (The parameters inside the RA are listed in Table 6.) Hosts that receive the RA, after configuring a link-local address,continue configuring their interfaces. An RA is an ICMPv6 packet with source address as the link-local address of the router interface and destination address of the all-nodes multicast (FF02::1) address.

Field Meaning

Type This is the ICMP packet type = 134

Code 0

Checksum ICMPv6 checksum

Current Hop Limit Default value used by hosts to send packets

M Managed address flag, 1= use stateful configuration, 0 = auto-configuration

O Other stateful configuration, 1 = use stateful for non-address configuration

Router Lifetime (RL) 16-bit value in seconds, this router is default for <RL>

Reachable Time (RT) 32-bit value in ms, Neighbor node reachable for <RT> after Neighbor Discovery

Retransmit Timer (RTT)

32-bit value in ms, Neighbor Discovery packets sent at intervals of <RTT>

Options Router may include its link-layer address

Router may specify MTU for link layer

Router may include routing prefix for auto-configuration

Prefixes may contain valid lifetime and preferred lifetime information.

Table 6: Router Advertisement

Router Solicitation

The five minutes between RA messages may be a long time to wait as a new node boots up and wishes toconfigure its own interface for IPv6. RFC 2461 also defines a Router Solicitation (RS) message that can be sent tothe all-routers multicast address by a node. The format for this message is shown in Table 7.

37




Field Meaning

Type This is the ICMP packet type = 133

Code 0

Checksum

ICMPv6 checksum

Options Node may include its link-layer address

Must not include link-layer address if sent to::/0

Table 7: Router Solicitation Message

Routers answer a solicitation with an immediate RA.

Stateful and Stateless Configuration

Once a host has enabled its interface(s), derived a link-local address for each, and has received (or solicited andreceived) an RA, it is able to configure an Internet address. Nodes may configure their global unicast addresses ina stateless (auto-configuration) or stateful manner. At this time stateful configuration is accomplished by theDHCP version 6 (DHCPv6). Administrators may decide to override the nodes configuration and configureinterfaces manually. Router interfaces should always be configured manually.

Administrators may control this process by configuring the routers on a link to require the use of statefulconfiguration for an IPv6 address, stateful configuration of other DHCPv6 parameters, or both. Administrators

also have the option to include routing prefixes in an RA, which are then used for auto-configuration of a globalunicast address.

Address Auto-Configuration

Stateless auto-configuration, as specified in RFC 2462, is particularly well suited to network clients. It requires nomanual configuration, minimal (if any) configuration of routers, and no additional servers. It allows a host togenerate its own global, unique addresses by combining its own interface ID, and network prefix informationadvertised by routers in RAs.

In the absence of routers, a host can only generate link-local addresses. Stateless auto-configuration relies on anew IPv6-related protocol, Neighbor Discovery, described in more detail later in this overview. Hosts use the Neighbor Discovery protocol to learn their subnet prefix from routers, among other things.

Stateless auto-configuration has several benefits, including ease of renumbering. For example, if an enterprisechanges service providers, the prefix information from the old service provider can be slowly deprecated in RAs.Using preferred-lifetime information a new prefix can be slowly introduced for the new provider. Similarly, anorganization with many adds, moves, and changes can use stateless auto-configuration to ensure that hosts receivea valid IP address each time they reconnect to the network.

38




Despite these advantages, concern over privacy issues has prompted several members of the IPng Working Groupto propose extensions to stateless address auto-configuration (see RFC 3041). Using a non-changing identifier as part of an Internet address may allow others to track the activities of a user as that user moves from network tonetwork. Privacy extensions cause the interface ID portion of the IPv6 address to change over time. In this way, itwould be more difficult for eavesdroppers and other information collectors to determine which addressescorrespond to a given node.

DHCPv6

In stateful auto-configuration, hosts obtain interface addresses and/or configuration information and parametersfrom a DHCPv6 server. Through changes to the DHCP architecture and model, DHCPv6 is able to support newfeatures, including configuration of dynamic updates to DNS, address deprecation for dynamic renumbering,assignment of multiple addresses to a single client, and location of relays to off-link servers.

IPv6 clients are able to reach DHCPv6 servers and relays through well-known multicast addresses:

FF02::1:2—All_DHCP_Relay_Agents_and_Servers with link-local scope

FF05::1:3—All_DHCP_Servers with site-local scope (used by DHCP Relay)

The DHCP process is similar to the process in IPv4 in that a client must solicit the location of a server, the server must advertise that it is available, the client must make a request of the server and confirm periodically thatassigned addresses are valid. DHCPv6 makes many improvements over the IPv4 version. Some of these, such asthe reconfiguration message, have been extended into IPv4; others, like the use of multicast to locate DHCPservers, have not.

As we have seen, administrators can require that IPv6 hosts use DHCPv6 through Route Advertisements. If anadministrator specifies the use of DHCPv6 for a host, that host must negotiate an IPv6 address with a local DHCPserver. Hosts may be required to use DHCPv6 to acquire an address, or to acquire other information about thenetwork [see RFC 3736], or both. In a situation where a network chooses to run IPv6 in a dual-stack (both IPv4and IPv6 active on a single machine), DHCP messages are sent independently for each protocol, even though theDHCP server may support both protocols.

Stateless and stateful auto-configuration are intended to complement each other. For example, a host can usestateless auto-configuration to configure its own addresses and use stateful auto-configuration to obtain other information, such as the address of a DNS server. Network administrators may choose to use stateless auto-configuration when they're not particularly concerned about the exact addresses hosts use to connect to theInternet, so long as they're unique and routable. On the other hand, they may opt for stateful auto-configuration if they want tighter control over exact address assignments and to ensure that hosts receive specific configurationinformation. It may be quite difficult to chase down a misbehaving laptop with a self-configured global IPv6address. An administrator who wants to use both mechanisms can do so by setting the appropriate fields in RAmessages.

Duplicate Address Detection

Before any IPv6 address can be used, Duplicate Address Detection (DAD) must be performed on that address.

This requirement is for all addresses, either assigned via auto-configuration or DHCPv6, and has only oneexception. DAD must not be performed on anycast addresses (for obvious reasons). In a DAD procedure (seeRFC 2462) the node must join the all-nodes multicast address (FF02::1) so that it may hear other nodes that may be using the same address. The node must also join the solicited-node multicast for the address it is trying tovalidate so that it can hear other nodes that may be trying to validate the same address.

The node may now check the address in question by sending a neighbor solicitation message (part of the Neighbor Discovery protocol) to the target address. The IPv6 source address of the solicitation is unspecified (::)and the destination is the solicited-node multicast of the target.

39




Required Addresses

With DAD complete, our candidate address is now available for use and our example machine can communicateusing IPv6. As a check, an IPv6 node is required to configure addresses of the following types and recognize thatthese addresses pertain to itself:

• A link-local address for each interface

• Any manually configured interface

• Any auto-configured interface

• It's loopback address (::1)

• The all-nodes multicast address (FF02::1)

• The solicited-node multicast address for each unicast and anycast address

• Any other multicast address to which the node may belong

Figure 19: Simple Network Example Addressed

In addition to these addresses, the router in our example would be required to configure and understand:

• All addresses that a node must understand

• Subnet-router anycast address on any local interface which routes packets

• All-routers multicast addresses

• FF01::2—All routers with interface-local scope

• FF02::2—All routers with link-local scope• FF05::2—All routers with site-local scope

• All other anycast addresses configured

The local IPv6 configuration of any node should be readily available at the command line. On Windows XP withIPv6 installed, the IPv6 configuration is accessible through the “netsh” command, and on many flavors of UNIX(FreeBSD, Linux, Mac OS X), a simple “ifconfig” will show how the interfaces are configured:

Server:~/Desktop young$ ifconfig en0

40




en0:flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500

inet6 fe80::6C0:ABFF:FECD:1234%en0 prefixlen 64 scopeid 0x4

inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255ether 04:C0:AB:CD:12:34

media: autoselect (100baseTX <full-duplex,flow-control>) status: active

Link Layers

IPv6 has been shown to work over a number of link-layer or Layer 2 technologies. For the convenience of thereader some of the more popular technologies are listed in Table 8 together with the RFCs that specify IPv6 over that particular Layer 2 technology. Some of the link layers operate quite differently with IPv6. PPP for instancederives great advantage from running IPv6 when compared to IPv4.

Link layer RFC See also

Ethernet RFC2464

RFC 4554, “Use of VLANs”

PPP RFC2472

Non-Broadcast Multiple Access RFC2491

Frame Relay RFC

2590

RFC 3122, “Inverse Neighbor

Disc.”

Asynchronous Transfer Mode(ATM)

RFC2492

Fiber Channel RFC3831

Table 8: IPv6 Link-Layer Definitions

IPv6 in Wide Area Networking

Up to this point, we have been dealing mostly with IPv6 topics related to local networking. Although localnetworking relies on the formation of IPv6 packets, a treatment of IPv6 packets and headers has been delayeduntil now. The benefits to be realized by IPv6's redesigned header and option processing are much more apparentwhen discussing IPv6 in wide area networking.

41




When compared side by side, the IPv4 and IPv6 headers don't seem all that different. Allowing for the expandedaddress space in IPv6, they are similar in size; the basic IPv4 header is 20 bytes in length (without the optionsfield) while the IPv6 header is 40 bytes. On the other hand, there are 14 fields in the IPv4 header (plus padding)while there are only 8 fields in the IPv6 header. Consider that the IPv6 addresses consume 80% of the space in aheader; in IPv4 they consume only 40%. With source and destination address removed, the IPv4 header is 1.5times the size of the IPv6 header.

Figure 20: Comparison of IPv4 and IPv6 Header

Some fields from the IPv4 header are no longer required in IPv6. For instance, the identification, flags, andfragment offset fields are not required in IPv6 because intermediate nodes (routers) cannot fragment packets.

Fragmentation, if required, is handled end-to-end by hosts. Information about fragmentation is built into anextension header. The header checksum is not included, given that other protocols embed a checksum and link layers compute and verify a checksum before the packet reaches the IP layer. The IPv4 and IPv6 version fields areidentical in meaning. In IPv6, some fields have simply been renamed. The IPv6 traffic class field is identical toIPv4's TOS field (as defined by RFC 2474), IPv4's time to live (TTL) field is IPv6's hop limit field, and the IPv4 protocol field and IPv6 next header field are coincident, although the use of the next header field has beenexpanded to indicate the presence of the options field. The content of the options field has moved to an IPv6extension header.

Many texts, including IETF RFCs, state that relative to IPv4, the IPv6 header has been simplified. While this istechnically true, removing fragmentation and the checksum in the header has reduced its extent, it is not entirelyaccurate. Allowing IPv6 extension headers to daisy chain within a packet has simply relocated most of thecomplexity that was removed from the IP header. A more accurate description might be that the IP header has been redefined in IPv6 and optimized for packet processing. This new header definition greatly benefits

intermediate nodes (routers) in a network and will make it much easier to produce wire-speed devices in thefuture.

42




In IPv6, routers benefit from the definition of a 40-byte, fixed-length header. In IPv4, the header can be of variable length. This is an important improvement given that many modern router designs utilize very complexhardware application-specific integrated circuits (ASICs) that copy and process only the header of a packet.Having a fixed-length header simplifies the design of an ASIC. Headers that are complex, full of options, or werenot defined at the time that an ASIC was designed, might be required to travel a slower path through the router.Those “slow-path” packets would also consume more resources on their trip through a router. The situation for routers is further improved in that IPv6 routers must process only one type of next header field (IPv6 Hop-by-HopOption, see Table 9) and are no longer required to fragment packets.

Name Number

Use Processedby

Hop-by-HopOption

0 Explicitly source route packets Routers

IPv6 Header 41 IPv6 in IPv6 encapsulation Optional

IPv6 Routing 43 IPv6 Routing Header Nodes

IPv6 Fragment 44 Fragmentation Header Nodes

ESP 50 Encapsulating Security Payload Nodes

AH 51 Authentication Header Nodes

ICMP 58 Internet Control Message Protocol

v6

Nodes

NO NXT 59 No next header Nodes

Options 60 Destination options for IPv6 Nodes

Table 9: IPv6 Option Headers

Each intermediate node along the forwarding path must examine the hop-by-hop options header, as it containsinformation about the next hop for the packet. The routing extension headers are intended to be used by a sourceto control the routing of a packet, and may be used to explicitly dictate the route from a source to a destination,for example. Similarly, routing extensions can request that the destination use the same path for its reply. In thisway, a destination node could use the path to locate a mobile user, since no matter where the mobile user travels,the routing sequence inside the routing extension header could track the user's position. (This is an optionalfeature; mobile nodes [MNs] still have the option of hiding their position and using triangular routing.)

IPv6 extension headers are located between the IPv6 header and the transport-layer header. The design of extension headers facilitates routing and simplifies implementing additional options. Because of the placement of extension headers, a node can stop reading the next header field once it reaches the last value or extension header that pertains to it. Consequently, routers do not have to process all the extension options in each packet thattraverses them. In fact, all IPv6 extension headers except one are processed when they reach the destination node.

43




RFC 2460, “Internet Protocol, Version 6 (IPv6) Specification,” defines the next header field, how headers should be handled by intermediate nodes, and in what order they should appear. IPv6 extension header values areregistered numbers with IANA (see http://www.iana.org/numbers.html). The current list of defined extensionheaders is listed in Table 9.

ICMPv6

Like the DNS, the ICMP is a critical piece of behind-the-scenes Internet infrastructure. Almost everyone using theInternet uses ICMP, often in ways that they are not aware. In IPv4, ICMP is used by routers to inform hosts of difficulties in the delivery of packets. It is also widely used for diagnostic purposes, utilities like “ping” and“traceroute” (or “tracert” for those of Microsoft persuasion) depend on ICMP messages.

In IPv6 networks, we have seen that ICMP (in terms of Neighbor Discovery and DAD) is critical to the functionof every IPv6 node on a local network.

RAs, RSs, and Router Renumbering are part of the ICMPv6 family of messages as are the messages that deal withmulticast group membership (query, report and termination). ICMPv6 now has a much larger role to play in the basic transmission of packets across a network like the Internet.

Fragmentation and Path MTU

IPv6 does not allow intermediate nodes to fragment packets and this lessens the processing burden onintermediate nodes. In IPv6, routers no longer have the option to fragment packets that are too large for a link andtherefore, must send an ICMPv6 error message back to the sending host. This optimization for routers does makethe notion of maximum transmission unit (MTU) very important to the flow of traffic. MTUs are defined based ona path through a network. The MTU is the largest allowable packet length that can successfully traverse a path,and for our purposes a path is the collection of networks and routers that move a packet from one host to another host on an Internet. Path MTU discovery is discussed in RFC 1981, “Path MTU Discovery for IP Version 6.”

Discovery of the path MTU relies on ICMP error messages that are often blocked in enterprise firewalls. Inabilityto detect Path MTU will cause hosts difficulty in the transport of data. At best, a host could limit the sending

packet size to the lowest allowable MTU in an IPv6 network (1,280 bytes) or it could fragment larger packets.

In order to make it easier for administrators to identify, locate, and solve such problems, the ICMPv6specification expands on the notion of ICMP errors. The ICMPv6 destination unreachable message has an 8-bitcode field that indicates the probable cause for the failure.

Code

IPv6 usage IPv4 usage

0 No route to destination Net unreachable

1 Communication administratively prohibited

Host unreachable

2 Beyond scope of source address Protocolunreachable

3 Address unreachable Port unreachable

44


http://www.iana.org/numbers.html



4 Port unreachable Fragmentationneeded

5 Source address failed ingress/egress policy

Source route failed

6 Reject route to destination

Table 10: ICMPv6 and ICMPv4 Messages

The IPv4 specification for ICMP destination unreachable has no good way to specify that packet delivery failed because of an administrative policy (usually implemented in a firewall). ICMPv6 has two error notifications, onefor outgoing packets (packet filtered based on source address) and one for incoming packets (packet filtered at anetwork boundary).

Domain Name System

In the mid-1990's, members of the IETF defined the initial extensions to Domain Name System (DNS) necessaryto support IPv6, and additional changes have been proposed since the mid-1990's. DNS works very much thesame way in IPv6 as it does in IPv4 to resolve host names to IP addresses. Host names won't necessarily changeunder IPv6, since the current system of domain names and subdomains doesn't really change. However, the IETFhas defined a new resource record type. Initially, in RFC 1886, the IETF defined the AAAA record, which closelymimics the IPv4 “A” record. In July 2000, members of the IETF issued RFC 2874, “DNS Extensions to SupportIPv6 Address Aggregation and Renumbering” which defines the “A6” resource record and is intended tosupersede RFC 1886. Both the AAAA and A6 resource records map a domain name to a resource record.However, whereas the AAAA record stores a single IPv6 address, the A6 resource record can represent one or more IPv6 addresses.

The A6 record may include a complete IPv6 address, or a contiguous portion of an address and information

leading to one or more address prefixes. In this way, the IPv6 DNS can be hierarchical. Prefix information iscomposed of a prefix length and a DNS name. The DNS name, in turn, points to the owner of one or more A6records defining the prefix(es) needed to form one or more complete IPv6 addresses. One use for this type of indirection in the DNS is rapid renumbering. The higher order portion of the address or address range could bechanged while the lower order portion—the portion that contains host information—could stay the same.Consequently, there may be several A6 records, linked in a “chain,” that identify a number of addresses for adevice. A host that has more than one IPv6 address must have more than one such record. RFC 2874 also includessupport for AAAA records to ease transition.

In addition to supporting a new record type, RFC 2874 defines changes to DNS to support renumbering andaggregating IPv6 addresses, as well as multihoming. Specifically, RFC 2874 defines a new zone structure for reverse DNS lookups (those keyed on IPv6 addresses) that allows a zone to be used without modification for parallel copies of an address space (as for a multihomed provider or site) and across network renumbering events.This RFC also updates definitions of existing DNS query types.

In RFC 3364, “Tradeoffs in DNS Support for IPv6,” the authors identified the issues surrounding each DNSrecord. To end the saga, in RFC 3363, “Representation of IPv6 Addresses in DNS,” the IETF changed the statusof RFC 2474 and 2673 to experimental and thereby discouraged the use of the A6 record. As operationalexperience is gained with these experimental RFCs, the more advanced A6 record may be used. Today, theAAAA record is used to locate IPv6 DNS records.

45




One of the more pressing current issues for the DNS in IPv6 networks has to do with the notion that nomechanism is in place to auto-configure a DNS resolver. Name to number resolution is one of the most basicInternet services required by hosts. At present, IPv6 hosts can auto-configure a globally reachable interface butrequire a server or manual configuration to learn about a preferred resolver.

RFC 4339, “IPv6 Host Configuration of DNS Server,” lists three possible solutions to this problem. The firstoption, already in place, is to utilize DHCPv6 to provide a list of preferred resolvers to local hosts. Although a proposed DHCP-lite server would be less difficult to maintain than a full DHCPv6 implementation, a server isstill required for a mechanism that should be automatically configured. The second option is to send a list of preferred DNS resolvers as an option field in Route Advertisements. This solution has some security concerns(the ability of rogue nodes to send bogus resolver information) but it is a simple mechanism already in place. Thefinal option is to develop a well-known anycast address for DNS resolvers. Many Internet service providers (ISPs)already run their DNS resolvers with IPv4 anycast addresses so this option is also appealing on the surface. ISPstightly control what routing announcements can be made, so this solution may be less prone to tampering. Thissolution does require the definition of a globally routable anycast address or addresses, a decision that should betaken only after much thoughtful consideration.

The DNS is one area where existing IPv4 tools can actively probe the IPv6 Internet. The more popular forms of

DNS servers from IP address management vendors, as well as the most popular DNS server software, BerkeleyInternet Name Domain (BIND), all support IPv6. Some versions (BIND 9.3) even support experimental A6records. Those who are handy with DNS tools will find it is possible to query IPv6 DNS records on the Internet.One may wish to check that a chosen IPv6 consulting firm or education facility answers IPv6 DNS queries. Thefollowing websites can be reached with IPv6:

Server:~/Desktop young$ host -t aaaa www.kame.net.

Server:~/Desktop young$ host -t aaaa www.commandinformation.com

www.commandinformation.com has AAAA address 2001:418:c34:1444::10

www.commandinformation.com has AAAA address 2002:81fa:cf6:1444::10

Alternatively, there are IPv6-specific tools available at http://www.ipv6tools.com.

DNS is one operational area in the Internet that continues to struggle with IPv6. Some of the current issuessurrounding IPv6 and DNS are documented in RFC 4472, “Operational Considerations and Issues with IPv6DNS.”

Routing

The IETF has defined the necessary modifications to various routing protocols, including Open Shortest Path First(OSPF), RIPv2, Intermediate System-to-Intermediate System (IS-IS), and Border Gateway Protocol version 4(BGP-4), to accommodate IPv6. For the most part, the fundamental mechanism of each routing protocol remainsunchanged. The modifications generally are needed to accommodate IPv6's larger address size and its addressingstructure. For example, under IPv6, OSPF runs on a per-link basis rather than per IP subnet, as is the case withIPv4.

Support for IPv6 has also been added to proprietary protocols like Cisco Systems' Enhanced Interior Gateway

Routing Protocol (EIGRP), although a move to IPv6 may provide an opportune moment to discontinue the use of any proprietary protocol by an enterprise.

The IETF has specifically tackled IPv6 support within BGP-4, and with RFC 4659 (“BGP-MPLS IP VirtualPrivate Network [VPN] Extension for IPv6 VPN”) the IETF has extended that support to provider VPNs. Asvendors and providers begin to support this RFC, enterprises should be able to run native IPv6 VPN networksalongside IPv4 VPNs.

46


http://www.ipv6tools.com/

http://www.kame.net/



Multiprotocol Label Switching (MPLS), in essence, supports IPv6, although running an MPLS network based onIPv6 would require the setup of Label Switched Paths (LSPs) with an IPv6 routing protocol. Both the LabelDistribution Protocol (LDP) and Resource reSerVation Protocol (RSVP) are capable of this task. Support byrouter vendors and service providers may be forthcoming.

Multihoming in IPv6

If there is one area in which the IETF has missed the mark in serving the Internet community, it is inmultihoming. Multihoming is the practice of connecting an enterprise network to two or more ISPs to ensure thefollowing qualities:

• Redundancy

• Traffic balance

• Performance

• Policy

The redundancy provided by multiple connections to the Internet is an obvious advantage for many enterprises.

Redundancy is often the main driver behind maintaining multiple connections to the Internet. Once redundantconnections are in place, an enterprise will typically tune those connections such that traffic flow, both incomingand outgoing, is shared among those connections. Balancing traffic can be a bit of an art form. Multihoming oftencomes with an unintended consequence in that it can work against the aggregation of routes in the Internet andcan hamper the stability of the global routing infrastructure.

Figure 21: Multihomed IPv4 EnterpriseIn the example shown in Figure 21, an enterprise is attached to two ISPs; each provides a connection to the globalInternet. By making sure that each connection occupies a separate building exit, separate physical infrastructure,and separate link-layer carrier, the enterprise is confident that they have a redundant connection to the Internet.Because of the expense involved in maintaining two connections to the Internet, the enterprise decides to balancethe traffic on the outgoing and incoming links. Balancing the traffic is beyond the scope of this overview but thereare excellent texts that describe a number of techniques that deal with this subject:

• “BGP 4, Inter-Domain Routing in the Internet” by John W. Stewart III

• RFC 4116 (“IPv4 Multihoming Practices and Limitations”)

47




• RFC 2260 (“Multihoming”)

There isn't a technical reason that would make the scenario above more or less difficult for an IPv6 Internet. Atthis time, however, the allocation policy for IPv6 address does not assign provider-independent address space to

enterprises. Thus an enterprise, if it is attached to two or more IPv6 ISPs, receives as many IPv6 global routing prefixes.

The proposed methods for site multihoming in an IPv6 Internet are:

• Allow IPv6 hosts to multihome by maintaining multiple global addresses

• Utilize tunneling to make multiple provider routes available at all exits

• Make changes to the address allocation policies and allow provider-independent address space

The IETF Multi6 (see http://www.ietf.org/html.charters/multi6-charter.html) Working Group contains much moreinformation on this developing topic.

Mobility

Mobility in IPv6 networks is one area where the IETF has done very interesting and at times pioneering work.Mobility in an IP network concerns the behavior of connections to and from an IP host when that host's IP addresshas changed. Mobile IP works in both IPv4 and IPv6 networks. The notion of mobility in the Internet dates back to RFC 33, published in February 1973. Of course at that time the hosts were stationary and the users weremobile, but the notion is pervasive in much of the IETF work. Early mobile data communication networks likeCellular Digital Packet Data (CDPD) were loosely based on IP mobility concepts.

The current concept of IP mobility follows the notion of a traveler who stays in contact with a home location. Thetraveler advertises his home location as a place where he can be contacted; when he moves, he notifies that homelocation of his whereabouts. It may be helpful to imagine a postal system that forwards mail, or a local private branch exchange (PBX) system that forwards phone calls.

In the context of Mobile IP, the traveler's home address is called his “home IP address,” the post office is calledthe “home agent” (HA). When the traveler moves, the new location is called (conveniently for this analogy) a

“care-of address” (CoA). The means by which the traveler notifies the post office of his new location is called a“binding update” (BU). The traveler is simply called a mobile node (MN) and the sites with which the traveler communicates are called “correspondent nodes” (CNs).

Basic connectivity of the MN follows this analogy: When the traveler (MN) is at home, he makes his post officeaware of his location, and the post office (HA) assumes normal delivery. When the traveler is away, he registers(BU) his new location with the post office by some secure means, perhaps a shared secret. He also lets the postoffice know the length of time during which he'll be traveling. In some cases, the traveler knows of a pending package that must reach him while he is traveling. This package cannot make the journey from the correspondent(CN) to the post office to be forwarded to his location in time for him to receive it, so he informs the CN of hisCoA. The CN then forwards the package directly to MN's CoA. In Mobile IP, this direct forwarding is called“route optimization.”

Invariably, some of the letters and packages that are sent to the traveler may be lost forever as he moves from place to place, but IPv6 mobility will work well and keep him in touch.

48


http://www.ietf.org/html.charters/multi6-charter.html



Figure 22: IPv6 Mobility Example

Getting back to Mobile IP, when an MN configures its interfaces, it inspects the environment and compares thisnew address to a stored parameter of “home IP address.” If the MN realizes that it is home, it sends a BU to itsHA and the HA allows normal delivery. When the MN configures interfaces that do not compare to its concept of “home address” it sends a BU to its HA with a new network location. The MN communicates with the HA usingthe IP security (IPsec) protocol to ensure that a rogue MN could not hijack the connection.

When a CN initiates a connection to the MN, the request is sent to the home address and it is intercepted on thelocal link by the HA. The HA encapsulates the request in IPv6 and forwards it to the MN. When the MNcommunicates with the CN, the MN addresses the packet with its CoA as source. In this way the packet will passthrough any source-based filtering at the remote location. The MN also includes its home address as a destinationoption in an extension Routing Header. The packet takes normal delivery from the MN directly to the CN. Uponreceipt, the CN substitutes the MN home address for the CoA source address before delivering the packet tohigher layer protocols. Higher layer protocols and applications know nothing about Mobile IP or the true locationof the MN.

When an MN optimizes the routing to a CN, it does so through the security association with its HA in alightweight process between HA and CN. If the process fails the MN reverts to non-optimal routing. By keepingthe process lightweight a CN is not overwhelmed by security associations with MNs. Once the CN receives a BUfrom the MN, it is free to send packets directly to the CoA. It does so by using its own source address and the

CoA of the MN as destination address. It also adds a Routing Header to the packet and places the home address of the MN as a next hop. Upon receipt of the packet the MN substitutes the next hop header (its own home address)for the CoA destination before delivering to upper layer protocols.

The work in Mobile IP continues in the IETF and although the basic concepts have been presented here, thereader is encouraged to consult a text on this topic or the 165-page IETF RFC 3775, “Mobility support in IPv6.”

Management and Application Support

49




Many of the management and application support documents are similar in functionality to those that were writtenfor IPv4.

Management SupportTo date, the IETF has created a series of documents that provide management information base (MIB) definitionsfor IPv6. For example, RFC 2465, titled “Management Information Base for IPv6, Textual Conventions andGeneral Group,” provides for basic management of IPv6 entities and serves as the foundation for other IPv6 MIBdefinitions. In addition, the IETF has defined IPv6 MIBs for UDP, TCP, and ICMPv6. See the following RFCsfor specific details:

• RFC 4113, “Management Information Base for the User Datagram Protocol (UDP)”

• RFC 4022, “Management Information Base for the Transmission Control Protocol”

• RFC 4293, “Management Information Base for the Internet Protocol”

Other MIB object groups are being defined as well.

Application Support

The IETF has made progress spelling out the changes needed at the application programming interface (API)level to ensure applications operate properly over IPv6 networks. The de facto standard API for TransmissionControl Protocol/Internet Protocol (TCP/IP) applications is the “sockets” interface: Originally developed for UNIX, it is now widely implemented on non-UNIX systems as well. The current specification of this API iscontained in RFC 3542.

In general, most applications work the same way under IPv4 and IPv6. However, the IETF has defined IPv6-related extensions to the basic sockets interface to ensure a high degree of portability with IPv6 applications.Among the changes required to the sockets API to support IPv6 are a new socket address structure to carry IPv6addresses, new address conversion functions, and some new socket options. These extensions provide access tothe basic IPv6 features, including multicasting, required by TCP and UDP applications (such as Telnet, FileTransfer Protocol [FTP], and Hypertext Transfer Protocol [HTTP] clients and servers), while providingcompatibility for existing IPv4 applications.

The IETF has also defined other IPv6-related API extensions for so-called “advanced” applications that may needaccess to raw sockets or the IPv6 extension headers, such as the routing and hop-by-hop headers. Such advancedapplications include Ping, Traceroute, routing daemons, and multicast routing daemons. Most recently (March2005), the IETF published “Application Aspects of IPv6 Transition” in RFC 4038 that may aid the developer whois considering a migration to IPv6.

Deployment

The transition mechanisms for IPv6 may in fact outnumber the actual deployments but nearly every scenario for transition has been standardized.

The Transition to IPv6

50




Since the introduction of IPv6, the IETF's goal has been to make the transition to the next generation of IP as painless as possible. After 10 years of development and very little deployment, perhaps transition is too strong aword. It's well understood that IPv6 will co-exist with the installed base of IPv4 for the foreseeable future(forever, in many people's opinion). There will not be—nor could there be—a “flag day” or need for a site-wideshutdown to roll out IPv6. In enterprise networks, the more likely scenario will be a niche deployment of IPv6.Someone will discover a facet of IPv6 networking that allows the enterprise to accomplish a particular goalquickly or cost effectively when compared to the corresponding methods in IPv4. From there, the nichedeployment will expand, requiring enterprise-wide connectivity and perhaps even global connectivity. After all,that's the way that IPv4 took over the world from IPX, Systems Network Architecture (SNA), Extensible NameService (XNS), Open Systems Interconnect (OSI), and others.

The IETF has defined a number of IPv6 “transition” mechanisms so that enterprises and service providers canupgrade their hosts and routers to IPv6 with very little coordination between the two. Of particular interest toenterprises is RFC 4057 (“IPv6 Enterprise Network Scenarios”). Service providers may wish to view this and acorresponding document in RFC 4029 (“Scenarios and Analysis for Introducing IPv6 into ISP Networks”).

The “transition” mechanisms that the IETF has defined to date address two broad integration scenarios:

• The need for communications between IPv6 islands across an IPv4 infrastructure

• The need for communications between IPv4 and IPv6-based devices and networks

The solutions defined for the first scenario involve hosts and routers running dual IPv4 and IPv6 protocol stacksand tunneling packets through an IPv4 infrastructure. The solutions to the second scenario involve a range of mechanisms, including dual protocol stack techniques, translators, and application-layer gateways.

The remainder of this overview highlights the variety of mechanisms and approaches that enterprise IT managersand service providers can use to deploy IPv6. The ngtrans Working Group of the IETF provided a good overviewof this topic in RFC 2893 (“Transition Mechanisms for IPv6 Hosts and Routers”). With the work of the ngtransgroup complete, that group concluded in 2003. Individual RFCs and Internet Drafts provide more detail on other mechanisms, and much work is still being done in IETF working groups like v6ops.

The key to a successful deployment of IPv6 technology at this point is the compatibility of that deployment withan enterprise's installed base of IPv4 networks and applications.

The most direct way for an IPv6 node to be compatible with that installed base is to also provide a completeimplementation of IPv4. The rest of this section looks at various dual-stack techniques and issues, highlightsvarious means for tunneling IPv6 packets through an IPv4 infrastructure, and wraps up with an overview of translation-oriented mechanisms—including application-level gateways and the use of NAT technology.

Enterprises that are interested in IPv6 will need to be familiar with the different deployment methods available.The mechanism(s) utilized by an organization will depend on the types of communication required, and on thehosts and routers (nodes) involved:

• IPv4-only nodes are unaware of IPv6

• IPv6-only nodes are unaware of IPv4

• IPv6/IPv4 nodes are conversant with both

51




Figure 23: Nomenclature for IPv6 and IPv4 Nodes

Each mechanism was created to solve a set of issues regarding a particular deployment situation.

Dual IP StacksIn nearly every deployment of IPv6, IPv4 and IPv6 nodes will need to co-exist and, in many cases, communicate.The simplest way to accomplish this in hosts and routers is to run both IPv4 and IPv6 protocols, or to run a dualIP stack.

52




Figure 24: Dual IP Stack Node

Major operating systems and most router vendors, including IBM, Sun Microsystems, Apple Computer,Microsoft, Juniper Networks, Alcatel, Linux, FreeBSD and Cisco Systems, have developed dual stack implementations in which most of the code is shared between the two protocol suites, rather than there being twodistinct TCP/IP stacks.

The purpose of IPv6/IPv4 nodes is to enable interoperability between those nodes and each type of network. The purpose of a dual stack in routers is to enable both networking technologies and in some cases interoperability.

Although running an IPv6/IPv4 node is straightforward, there are disadvantages. For example, addressadministration increases due to the need to associate two or more IP addresses with each node that mustcommunicate with the IPv4 and IPv6 infrastructure. DNS can become a stumbling block to these hosts; DNSresolvers return both A and AAAA records for a queried node regardless of the transit protocol doing the asking.In an IPv4-only node, the application will certainly use the A record, but what of an application running on anIPv6/IPv4 node? On routers, routing tables will increase in size, and administrators will have their hands full justlearning about the different demands that IPv6 places on routers. But more than this, while all of the major routing protocols are equipped to deal with IPv6, some of them (namely IS-IS) have only one notion of a topologydatabase. This means that if the IPv4 network and IPv6 network don't share the exact topology (IPv4 and IPv6 onall links and interfaces) the protocol must be run once for the IPv4 topology and once for the IPv6 topology.

Bump-in-the-Stack

The bump-in-the-stack (BIS) model, defined in RFC 2767, “Dual Stack Hosts Using the ‘Bump-in-the-Stack'Technique (BIS),” is definitely the oddest mechanism available for IPv6 deployments. BIS was invented to alter IPv4-only hosts so that they might use IPv4-only applications on an IPv6/IPv4 network. Essentially themechanism builds a tiny NAT Protocol Translation (NAT-PT) engine within a network interface card. IPv6 packets enter the BIS host and are translated into IPv4 packets complete with internally mapped IPv4 addresses.In essence, the BIS method snoops data flowing between a TCP/IPv4 module and the network card driver andtranslates IPv4 into IPv6 and vice versa. Those translated packets are then delivered to the IPv4 applications.

53




By adding three modules to a host's IPv4 stack—a translator, an extension name resolver, and an addressmapper—a BIS-modified-IPv4 host can communicate with an IPv6 host as if they were both IPv6 hosts runningapplications for both IPv4 and IPv6. The translator translates IPv4 into IPv6. The extension name resolver functions similarly to a DNS application-level gateway, returning a valid A record response to the IPv4application's request for the target host name. The address-mapper maintains a pool of IPv4 addresses and a tableconsisting of pairs of IPv4 and IPv6 addresses.

RFC 4038 (“Application Aspects of IPv6 Transition”) does mention the BIS method briefly as a valid way toextend the life of IPv4 applications in an IPv6 environment. It should only be used when alteration of thoseapplications is not feasible or source code is not available. This method does suffer from the DNS resolver issuementioned previously, in that a resolver may send A and AAAA records for a queried host. The BIS methodshould be able to cycle through the DNS answers.

Tunneling IPv6 over IPv4 Infrastructure

At every IETF meeting there is a birds-of-a-feather (BoF) meeting informally called the Scotch BoF (it isn't reallya BoF, which is the method used to solicit interest in a new IETF working group, but more of a social gathering of

the IPv6 like-minded). It is customary to bring to this BoF a decent bottle of single malt or Scotch whiskey, and perhaps a friend or two. The toasts are not quite so lengthy but as each member of the Scotch BoF offers his or her toast, all others refrain:

“And to the ubiquitous deployment of IPv6!”

Many in that room may wish otherwise, but the path to the ubiquitous deployment of IPv6 still lies on the other side of an IPv6 over IPv4 tunnel.

There are various ways to tunnel IPv6 packets over an IPv4 infrastructure, but the basic operations are essentiallythe same. IPv6 packets going to another IPv6 domain are encapsulated in the payload portion of IPv4 packets.The entry node of the tunnel, which can be a host or a router, creates an encapsulating IPv4 header and transmitsthe encapsulated packet. Intermediate IPv4 nodes do not examine the IPv6 payload, but simply pass on the packet.The exit node of the tunnel receives the encapsulated packet, removes the IPv4 header, and processes the IPv6 packet. If a router is the tunnel endpoint, it must remove the IPv4 header and forward the IPv6 packet to its final

destination. The basic tunneling of IPv6 traffic over an IPv4 infrastructure is illustrated in Figure 25.

54




Figure 25: IPv6 over IPv4 Tunnel

The various methods for tunneling IPv6 packets over IPv4 networks have been described in RFC 2873 (“GenericPacket Tunneling in IPv6 Specification”). RFC 4213 (“Basic Transition Mechanisms for IPv6 Hosts andRouters”) lists a number of important concepts for all tunneling mechanisms.

Figure 25 shows a statically configured tunnel running between two IPv6/IPv4 routers over an IPv4 Internet.Other possible configurations of a static tunnel are host to router and router to host. Configured tunnels, as their name implies, are manually set up and will typically be used point-to-point between sites that regularly exchangetraffic. Configured tunneling does not rely on IPv4-compatible IPv6 addressing. Rather, configuration informationon the encapsulating node determines the IPv4 tunnel endpoint. The 6bone, for example, was an experiment in

IPv6 networking that was decommissioned this past year. It was built primarily of manually configured tunnels.

55




Unless great care is taken in checking the source and destination of payloads and tunnel endpoints, tunnels canopen a number of vulnerabilities in a network. Tunnels should either operate with an encrypted payload or employfirewall mechanisms to detect and discard packets that do not come from a corresponding tunnel endpoint.Because tunnels work by encapsulating the payload of one protocol inside another, special consideration should be given to the ultimate MTU of the tunnel. Keep in mind that the minimum MTU for an IPv6 network is 1,280 bytes. Also, plan the use of fragmentation, if required, in the tunnel network carefully. Fragmentation consumesrouting resources and can degrade throughput severely with the loss of very few packets. Bear in mind that if theendpoints of a tunnel are IPv4 addresses, these tunneling techniques cannot work if an IPv4 address translationoccurs between the two endpoints of the tunnel.

There are also dynamic tunneling mechanisms in place that, once configured, automatically enable tunnels ondemand. An IPv6/IPv4 node may support configured tunneling or both configured and automatic tunneling.

6to4 Dynamic Tunneling

To avoid the overhead of manually configuring tunnels, the IETF has defined a dynamic tunneling method for connecting IPv6 domains over IPv4 clouds. Dubbed 6to4 and defined in RFC 3056, “Connection of IPv6

Domains via IPv4 Clouds,” this tunneling technique allows organizations to easily connect isolated IPv6 sites,without having to wait for their ISPs to deliver native IPv6 services. The 6to4 mechanism can be used to supportextranets and VPNs.

6to4 relies on the assignment of a unique IPv6 address prefix (seeFigure 12), which is used in encapsulating IPv6 packets for transmission over an IPv4 network. For 6to4 to work properly, a site needs at least one globallyunique IPv4 address. In essence the IPv4 address acts as the next-level aggregation (NLA) portion of the IPv6address.

The 6to4 mechanism is typically implemented in routers that border an IPv4 wide area network. These “6to4routers” require a modest amount of configuration. The IETF has also specified the role of so-called relay routers,which are 6to4 routers configured to support transit routing between 6to4 addresses and native IPv6 addresses.6to4 routers may be configured with anycast addresses using a well-known IPv4 anycast address(192.88.99.0/24). This configuration is defined in RFC 3068. Using 6to4 relays, enterprises can reach sites on theIPv6 Internet.

When a 6to4 router receives an IPv6 packet whose next hop destination prefix is the special 6to4 prefix, the IPv6 packet is encapsulated in an IPv4 packet and forwarded to the IPv4 network. The encapsulated IPv4 packetcontains destination and source IPv4 addresses, one or both of which is identical to the 32-bit IPv4 address for thetunnel endpoint (that is, the v4 portion of the special IPv6 prefix we described above). By embedding IPv4 tunneladdresses in this fashion and using Neighbor Discovery, it 's possible for border routers to automatically discover tunnel endpoints for outbound IPv6 traffic. When the destination site's 6to4 router receives the packet, it removesthe IPv4 header and forwards the IPv6 packet.

As mentioned, NAT will prevent 6to4 from working, but it is possible to co-locate a 6to4 router with a NAT box.This combination would provide the site with a globally unique IPv6 prefix behind the IPv4 address of the NAT,enabling every host behind the NAT to become an IPv6 host with no additional address space allocation and nointervention by an ISP. In addition to these considerations, when implementing 6to4, it's also necessary to create aDNS AAAA record that reflects the 6to4 prefix.

The 6over4 Mechanism

The IETF has defined another mechanism for IPv6 hosts to operate over an IPv4 infrastructure, in which a siterunning IPv4 multicast can use its IPv4 network like a single LAN to interconnect isolated IPv6 hosts. 6over4 or “virtual Ethernet” is specified in RFC 2529, “Transmission of IPv6 over IPv4 Domains without Explicit Tunnels”(this mechanism is designed for use by organizations running only a few IPv6 hosts and one or more IPv6routers).

56




Using the 6over4 mechanism, IPv6 hosts located on a physical link that has no directly connected IPv6 router can become fully functional IPv6 hosts by using an IPv4 multicast domain as their virtual local link. Also referred toas a type of multicast tunneling, the 6over4 mechanism enables IPv4 tunnel endpoints to be determined using Neighbor Discovery.

As with other forms of tunneling, IPv6 packets are transmitted in IPv4 packets. The main benefit of 6over4 is thatit enables an organization to run both IPv4 and IPv6 without having to configure IPv6 hosts with IPv4-compatibleaddresses or with tunnels. Interfaces on IPv6 hosts and routers will need to support the 6over4 mechanism. Inaddition, to connect IPv6 hosts on different physical links, IPv4 multicast routing must be enabled on the routersconnecting the links, and IPv4 multicast must be supported on the hosts themselves.

Teredo

Teredo Navalis is the scientific name for a species of shipworm. Shipworms bore in to the hulls of wooden ships,eventually destroying them. Besides winning the prize for the most vivid imagery evoked by a name for anetworking protocol, the Teredo tunneling method is intended to bore through NAT devices, or at least, enabletunneling of IPv6 packets through them over UDP. Teredo works with most types of NAT except symmetric NAT

(see the Network and Telecom Strategies overview, “ NAT Traversal by Peer-to-Peer Applications: AddressingVariable Behaviors”).

As one might expect for a protocol that claims to work with all types of NAT, the Teredo mechanism is verycomplex. There are Teredo clients behind the NAT device, Teredo servers that act as helpers to bridge Teredoclients to each other and the IPv6 Internet, and Teredo relays that receive and forward IPv6 traffic to Teredoclients using the Teredo service.

The protocol begins with configuration on the client machine. The client must be configured with the two globallyroutable IPv4 addresses of the Teredo server. At this point, a series of packet are exchanged between client andserver. The object of this exchange is to classify the type of NAT behind which the client sits and to deliver anIPv6 address to the client. Much of this information is stored in the flags field of the Teredo address as shown inTeredo.

To exchange packets with the outside world, Teredo clients must open ports in their respective NAT devices.Teredo clients and servers do this with what are called “bubbles,” or test packets that open connection mappingsin their NAT devices. Procedures for sending and receiving packets with Teredo are well beyond the intendedscope of this overview. The interested reader should refer to some of the IPv6 texts inAppendix A of thisoverview or to the RFC.

Teredo is intended as a last resort for those who want IPv6 connectivity but are connected to the IPv4 Internet behind a NAT device.

Tunnel Setup Protocol

While the tunneling techniques described above have their roles to play in the deployment of IPv6, they posevarious drawbacks, ranging from the overhead of configuring and managing tunnels to scaling issues. As a result,several IETF members have proposed the use of tunnel brokers as a means for early IPv6 adopters to connect toan existing IPv6 network, and to get permanent IPv6 addresses and DNS names. The model for tunnel brokers is

outlined in RFC 3053, “IPv6 Tunnel Broker,” as an Informational RFC.A tunnel broker can be viewed as an IPv6 ISP that offers connectivity through IPv6 over IPv4 tunnels. The tunnel broker is the place where a user connects to register and activate tunnels, while the tunnel broker itself managestunnel creation, modification, and deletion on behalf of the user. A tunnel broker would be responsible for allocating IPv6 address space to a client, choosing the nearest tunnel server to service the client, configuring theserver tunnel endpoint, downloading scripts to clients to configure client tunnel endpoints, and potentiallyregistering client names in the IPv6 network DNS.

57






Gateways and Translators

The tunneling techniques described above allow for communications primarily between IPv6 nodes across IPv4networks. However, enterprises and service providers will likely also find it necessary to enable communications between IPv6 and IPv4 nodes, sometimes on the same network. While dual-stack implementations can be used inmany cases, the IETF has also defined gateways and translators, which may be used alone or in conjunction withother mechanisms to enable communication between IPv4 and IPv6 nodes and vice versa.

Typically, a protocol translator maps the fields in the packet headers of one protocol to semantically similar fieldsin the packet headers of another protocol. In IPv4 applications, it's not uncommon for an application to haveknowledge of information from the network layer, such as the address length or the address itself. Such is the casewith FTP, for example. This makes it necessary to translate packets at both the network layer and the applicationlayer. Another issue with translation between IPv4 and IPv6 headers is that IPv4 options and IPv6 extensionheaders, including routing and hop-by-hop extension headers, are not easily translatable.

The following sections highlight some of the proposed gateway and translation mechanisms under considerationwithin the IETF.

The SOCKS Gateway

SOCKS is a proxying protocol that allows client-server TCP and UDP applications to encrypt session traffic withSecure Shell (SSH) connections or traverse firewall boundaries. SOCKS is conceptually a “shim layer” betweenthe application layer and the transport layer; it does not provide network-layer gateway services, such asforwarding of ICMP messages. Members of the ngtrans Working Group have proposed a SOCKS-basedIPv6/IPv4 gateway mechanism that allows for communications between IPv6 and IPv4 nodes. RFC 3089 (“ASOCKS-based IPv6/IPv4 Gateway Mechanism”) outlines this mechanism.

The SOCKS gateway is implemented via new code on clients, dubbed “SOCKS Lib,” and “gateway” code on adual-stack node acting as the gateway. The SOCKS gateway essentially terminates the connection between thetwo clients that want to communicate and relays two “terminated” IPv4 and IPv6 connections at the applicationlayer.

As Figure 26 illustrates, the “SOCKS Lib” on Client A communicates with the gateway using the SOCKS protocol, creating a special connection that can transfer data as well as control information, such as the destinationof Client B. The connection between the gateway and Client B is a normal data-only connection, and the gatewayappears as a peer node to Client B. In this way, Clients A and B can communicate. The gateway also handlesDNS name resolving on behalf of the source node (Client A).

Figure 26: SOCKS Gateway

58




Two pluses of the SOCKS gateway are that neither applications nor DNS need to be modified. However, theSOCKS gateway may not support all applications. There are a number of SOCKS gateway implementations thatsupport IPv6; some of them are in the public domain.

Stateless IP/ICMP Translation

Stateless IP/ICMP Translation (SIIT), defined in RFC 2765, “Stateless IP/ICMP Translation Algorithm (SIIT),” isa set of rules for translating between IPv4 and IPv6 headers, including ICMP headers. SIIT allows for communication between IPv4-only nodes and IPv6-only nodes that do not have permanently assigned IPv4addresses. SIIT should be used with other deployment mechanisms, and assumes that mechanisms are in place for an IPv6 node to acquire a temporary IPv4 address and for routing (perhaps using tunneling) to and from the IPv4address assigned to the node.

The temporary IPv4 address is used as an IPv4-translated IPv6 address, and packets travel through a statelessIP/ICMP translator that translates the packet headers between IPv4 and IPv6, as well as translates the addresses inthose headers between IPv4 addresses on one side and IPv4-translated or IPv4-mapped IPv6 addresses on theother. The translator defined in SIIT modifies headers at the logical IP layer, including IP headers, IPv6 fragment

headers, and ICMP headers.The translator does not modify any headers above the IP layer. Nor does it translate any IPv4 options or IPv6Routing Headers, hop-by-hop extension headers, or destination options. In addition, it's not possible to use end-to-end AHs through the translator, although packets encrypted using the ESP header in transport mode can be carriedthrough the translator.

All of the translator operations are stateless. That is, the translator operates independently on each packet and doesnot retain state from one packet to another. Consequently, a network operator could deploy redundant translator boxes without any coordination, and a given TCP connection, for example, can have packets go through differenttranslator boxes.

Network Address Translation-Protocol Translation (NAT-PT)

RFC 2766, “Network Address Translation-Protocol Translation (NAT-PT),” combines address translation withthe IPv6/IPv4 protocol translation described in SIIT. (For more information about NAT and how to overcome itseffects, see the Network and Telecom Strategies overview, “ NAT Traversal by Peer-to-Peer Applications:Addressing Variable Behaviors.”) Like SIIT, NAT-PT addresses the problem of communication between IPv6and IPv4 nodes. However, it goes further by handling address assignment and routing, and also addresses theissue of IPv4 address exhaustion that's associated with assigning IPv4 addresses to IPv6 nodes.

A dedicated device handles NAT-PT functions. This device uses a pool of globally unique IPv4 addresses for dynamic assignment to IPv6 nodes as sessions are initiated across IPv4/IPv6 boundaries. (NAT-PT with privateIPv4 addresses is a topic for future study.) NAT-PT binds addresses in an IPv6 network with addresses in an IPv4network and vice versa to provide routing between the two environments.

NAT-PT translates between IPv4 and IPv6 addresses and also includes an application-layer gateway thattranslates between IPv4 and IPv6 DNS requests and answers. NAT-PT extends SIIT by also translating transportidentifiers including TCP and UDP port numbers and ICMP query identifiers. Furthermore, NAT-PT supports the

multiplexing of the transport identifiers of a number of IPv6 hosts into the transport identifiers of a singleassigned IPv4 address, thus making it possible for IPv6 nodes to communicate with IPv4 nodes using a singleIPv4 address. In fact, NAT-PT allows for a maximum of 63,000 TCP and 63,000 UDP sessions per IPv4 address.Because NAT-PT is session-oriented, the NAT-PT device maintains state during the time of the session.

59






NAT-PT can be useful when native IPv6 or IPv6-over-IPv4 tunneling isn't possible. NAT-PT does not mandatedual IP stacks, or require tunneling. When deployed without a DNS application gateway, NAT-PT can provideone-way connectivity to an IPv6 “stub” network and the broader IPv4 world. In this scenario, only sessionsinitiated by IPv6 nodes on the IPv6 stub network are translated, while sessions initiated by IPv4 nodes aredropped. In this way, an organization's IPv6 nodes can have connectivity with the IPv4 world without the need todeploy servers visible to the IPv4 world.

When combined with a DNS application gateway, NAT-PT provides bidirectional connectivity between an IPv6stub network and the IPv4 world, allowing sessions to be initiated by IPv4 nodes outside the IPv6 network. Thismakes NAT-PT useful for IPv6-only networks that need to deploy servers visible to the IPv4 world.

Among the benefits of the NAT-PT approach are that it does not require any changes to end nodes, and packetrouting is transparent to end nodes. However, NAT-PT must track the sessions it supports, and inbound andoutbound datagrams pertaining to a session must traverse the same NAT-PT router. And since NAT-PT performsaddress translation, applications that carry the IP address in the higher layers will not work. In this case,application layer gateways are needed to support those applications. Likewise, end-to-end network-layer securityis not possible. In addition, some applications need address stability to operate properly, so may not function wellin light of NAT-PT's dynamic address reuse. For hosts running such address-critical applications, NAT-PT can be

configured to provide static address mapping between the host's IPv6 address and a specific IPv4 address.

60




Conclusion

Internet Protocol version 6 (IPv6) has a number of appealing features and benefits, including its large, hierarchicaladdress space, auto-configuration capabilities, and advanced support for Mobile IP. Enterprises and service providers should evaluate IPv6 in light of its capabilities and decide if they are missing an opportunity to gain acompetitive advantage by using IPv6. Given the number of changes in IPv6, information technology staffs would be well advised to begin educating themselves about IPv6 sooner rather than later. Likewise, those organizationsinterested in or expecting to support IPv6 over the next few years should begin their planning process soon.

61




Appendix A: IPv6-Specific RFCs

RFC 1809 Using the Flow Label Field in IPv6. C. Partridge. June 1995. (Format: TXT=13,591 bytes) (Status:INFORMATIONAL)

RFC 1881 IPv6 Address Allocation Management. IAB, IESG. December 1995. (Format: TXT=3,215 bytes)(Status: INFORMATIONAL)

RFC 1883 Internet Protocol, Version 6 (IPv6) Specification. S. Deering, R. Hinden. December 1995. (Format:TXT=82,089 bytes) (Obsoleted by RFC 2460) (Status: PROPOSED STANDARD)

RFC 1884 IP Version 6 Addressing Architecture. R. Hinden, S. Deering, Eds. December 1995. (Format:TXT=37,860 bytes) (Obsoleted by RFC 2373) (Status: HISTORIC)

RFC 1885 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6). A. Conta, S.Deering. December 1995. (Format: TXT=32,214 bytes) (Obsoleted by RFC 2463) (Status: PROPOSEDSTANDARD)

RFC 1886 DNS Extensions to support IP version 6. S. Thomson, C. Huitema. December 1995. (Format:TXT=6,424 bytes) (Obsoleted by RFC 3596) (Updated by RFC 2874, RFC 3152) (Status: PROPOSEDSTANDARD)

RFC 1887 An Architecture for IPv6 Unicast Address Allocation. Y. Rekhter, T. Li, Eds. December 1995.(Format: TXT=66,066 bytes) (Status: INFORMATIONAL)

RFC 1888 OSI NSAPs and IPv6. J. Bound, B. Carpenter, D. Harrington, J. Houldsworth, A. Lloyd. August 1996.(Format: TXT=36,469 bytes) (Obsoleted by RFC 4048) (Updated by RFC 4548) (Status: HISTORIC)

RFC 1897 IPv6 Testing Address Allocation. R. Hinden, J. Postel. January 1996. (Format: TXT=6,643 bytes)(Obsoleted by RFC 2471) (Status: EXPERIMENTAL)

RFC 1924 A Compact Representation of IPv6 Addresses. R. Elz. April 1 1996. (Format: TXT=10,409 bytes)(Status: INFORMATIONAL)

RFC 1933 Transition Mechanisms for IPv6 Hosts and Routers. R. Gilligan, E. Nordmark. April 1996. (Format:TXT=47,005 bytes) (Obsoleted by RFC 2893) (Status: PROPOSED STANDARD)

RFC 1970 Neighbor Discovery for IP Version 6 (IPv6). T. Narten, E. Nordmark, W. Simpson. August 1996.(Format: TXT=197,632 bytes) (Obsoleted by RFC 2461) (Status: PROPOSED STANDARD)

RFC 1971 IPv6 Stateless Address Autoconfiguration. S. Thomson, T. Narten. August 1996. (Format:TXT=56,890 bytes) (Obsoleted by RFC 2462) (Status: PROPOSED STANDARD)

RFC 1972 A Method for the Transmission of IPv6 Packets over Ethernet Networks. M. Crawford. August 1996.(Format: TXT=6,353 bytes) (Obsoleted by RFC 2464) (Status: PROPOSED STANDARD)

RFC 1981 Path MTU Discovery for IP version 6. J. McCann, S. Deering, J. Mogul. August 1996. (Format:TXT=34,088 bytes) (Status: DRAFT STANDARD)

RFC 2019 Transmission of IPv6 Packets Over FDDI. M. Crawford. October 1996. (Format: TXT=12,344 bytes)

(Obsoleted by RFC 2467) (Status: PROPOSED STANDARD)

RFC 2023 IP Version 6 over PPP. D. Haskin, E. Allen. October 1996. (Format: TXT=20,275 bytes) (Obsoleted by RFC 2472) (Status: PROPOSED STANDARD)

RFC 2030 Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI. D. Mills. October 1996.(Format: TXT=48,620 bytes) (Obsoletes RFC 1769) (Obsoleted by RFC 4330) (Status: INFORMATIONAL)

62


http://tools.ietf.org/html/4330





































RFC 2073 An IPv6 Provider-Based Unicast Address Format. Y. Rekhter, P. Lothberg, R. Hinden, S. Deering, J.Postel. January 1997. (Format: TXT=15,549 bytes) (Obsoleted by RFC 2374) (Status: PROPOSEDSTANDARD)

RFC 2080 RIPng for IPv6. G. Malkin, R. Minnear. January 1997. (Format: TXT=47,534 bytes) (Status:PROPOSED STANDARD)

RFC 2081 RIPng Protocol Applicability Statement. G. Malkin. January 1997. (Format: TXT=6,821 bytes)(Status: INFORMATIONAL)

RFC 2133 Basic Socket Interface Extensions for IPv6. R. Gilligan, S. Thomson, J. Bound, W. Stevens. April1997. (Format: TXT=69,737 bytes) (Obsoleted by RFC 2553) (Status: INFORMATIONAL)

RFC 2147 TCP and UDP over IPv6 Jumbograms. D. Borman. May 1997. (Format: TXT=1,883 bytes) (Obsoleted by RFC 2675) (Status: PROPOSED STANDARD)

RFC 2185 Routing Aspects of IPv6 Transition. R. Callon, D. Haskin. September 1997. (Format: TXT=31,281 bytes) (Status: INFORMATIONAL)

RFC 2292 Advanced Sockets API for IPv6. W. Stevens, M. Thomas. February 1998. (Format: TXT=152,077

bytes) (Obsoleted by RFC 3542) (Status: INFORMATIONAL)

RFC 2373 IP Version 6 Addressing Architecture. R. Hinden, S. Deering. July 1998. (Format: TXT=52,526 bytes)(Obsoletes RFC 1884) (Obsoleted by RFC 3513) (Status: PROPOSED STANDARD)

RFC 2374 An IPv6 Aggregatable Global Unicast Address Format. R. Hinden, M. O'Dell, S. Deering. July 1998.(Format: TXT=25,068 bytes) (Obsoletes RFC 2073) (Obsoleted by RFC 3587) (Status: HISTORIC)

RFC 2375 IPv6 Multicast Address Assignments. R. Hinden, S. Deering. July 1998. (Format: TXT=14,356 bytes)(Status: INFORMATIONAL)

RFC 2376 XML Media Types. E. Whitehead, M. Murata. July 1998. (Format: TXT=32,143 bytes) (Obsoleted byRFC 3023) (Status: INFORMATIONAL)

RFC 2428 FTP Extensions for IPv6 and NATs. M. Allman, S. Ostermann, C. Metz. September 1998. (Format:TXT=16,028 bytes) (Status: PROPOSED STANDARD)

RFC 2452 IP Version 6 Management Information Base for the Transmission Control Protocol. M. Daniele.December 1998. (Format: TXT=19,066 bytes) (Obsoleted by RFC 4022) (Status: PROPOSED STANDARD)

RFC 2454 IP Version 6 Management Information Base for the User Datagram Protocol. M. Daniele. December 1998. (Format: TXT=15,862 bytes) (Obsoleted by RFC 4113) (Status: HISTORIC)

RFC 2460 Internet Protocol, Version 6 (IPv6) Specification. S. Deering, R. Hinden. December 1998. (Format:TXT=85,490 bytes) (Obsoletes RFC 1883) (Status: DRAFT STANDARD)

RFC 2461 Neighbor Discovery for IP Version 6 (IPv6). T. Narten, E. Nordmark, W. Simpson. December 1998.(Format: TXT=222,516 bytes) (Obsoletes RFC 1970) (Updated by RFC 4311) (Status: DRAFT STANDARD)

RFC 2462 IPv6 Stateless Address Autoconfiguration. S. Thomson, T. Narten. December 1998. (Format:TXT=61,210 bytes) (Obsoletes RFC 1971) (Status: DRAFT STANDARD)

RFC 2463 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification.A. Conta, S. Deering. December 1998. (Format: TXT=34,190 bytes) (Obsoletes RFC 1885) (Obsoleted by RFC4443) (Status: DRAFT STANDARD)

RFC 2464 Transmission of IPv6 Packets over Ethernet Networks. M. Crawford. December 1998. (Format:TXT=12,725 bytes) (Obsoletes RFC 1972) (Status: PROPOSED STANDARD)

RFC 2465 Management Information Base for IP Version 6: Textual Conventions and General Group. D. Haskin,S. Onishi. December 1998. (Format: TXT=77,339 bytes) (Obsoleted by RFC 4293) (Status: PROPOSEDSTANDARD)

63














































RFC 2466 Management Information Base for IP Version 6: ICMPv6 Group. D. Haskin, S. Onishi. December 1998. (Format: TXT=27,547 bytes) (Obsoleted by RFC 4293) (Status: PROPOSED STANDARD)

RFC 2467 Transmission of IPv6 Packets over FDDI Networks. M. Crawford. December 1998. (Format:

TXT=16,028 bytes) (Obsoletes RFC 2019) (Status: PROPOSED STANDARD)

RFC 2470 Transmission of IPv6 Packets over Token Ring Networks. M. Crawford, T. Narten, S. Thomas.December 1998. (Format: TXT=21,677 bytes) (Status: PROPOSED STANDARD)

RFC 2471 IPv6 Testing Address Allocation. R. Hinden, R. Fink, J. Postel (deceased). December 1998. (Format:TXT=8,031 bytes) (Obsoletes RFC 1897) (Obsoleted by RFC 3701) (Status: HISTORIC)

RFC 2472 IP Version 6 over PPP. D. Haskin, E. Allen. December 1998. (Format: TXT=29,696 bytes) (ObsoletesRFC 2023) (Status: PROPOSED STANDARD)

RFC 2473 Generic Packet Tunneling in IPv6 Specification. A. Conta, S. Deering. December 1998. (Format:TXT=77,956 bytes) (Status: PROPOSED STANDARD)

RFC 2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers. K. Nichols, S.Blake, F. Baker, D. Black. December 1998. (Format: TXT=50,576 bytes) (Obsoletes RFC 1455, RFC 1349)

(Updated by RFC 3168, RFC 3260) (Status: PROPOSED STANDARD)

RFC 2491 IPv6 over Non-Broadcast Multiple Access (NBMA) networks. G. Armitage, P. Schulter, M. Jork, G.Harter. January 1999. (Format: TXT=100,782 bytes) (Status: PROPOSED STANDARD)

RFC 2492 IPv6 over ATM Networks. G. Armitage, P. Schulter, M. Jork. January 1999. (Format: TXT=21,199 bytes) (Status: PROPOSED STANDARD)

RFC 2497 Transmission of IPv6 Packets over ARCnet Networks. I. Souvatzis. January 1999. (Format:TXT=10,304 bytes) (Also RFC 1201) (Status: PROPOSED STANDARD)

RFC 2526 Reserved IPv6 Subnet Anycast Addresses. D. Johnson, S. Deering. March 1999. (Format:TXT=14,555 bytes) (Status: PROPOSED STANDARD)

RFC 2529 Transmission of IPv6 over IPv4 Domains without Explicit Tunnels. B. Carpenter, C. Jung. March1999. (Format: TXT=21,049 bytes) (Status: PROPOSED STANDARD)

RFC 2545 Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing. P. Marques, F. Dupont.March 1999. (Format: TXT=10,209 bytes) (Status: PROPOSED STANDARD)

RFC 2546 6Bone Routing Practice. A. Durand, B. Buclin. March 1999. (Format: TXT=17,844 bytes) (Obsoleted by RFC 2772) (Status: INFORMATIONAL)

RFC 2553 Basic Socket Interface Extensions for IPv6. R. Gilligan, S. Thomson, J. Bound, W. Stevens. March1999. (Format: TXT=89,215 bytes) (Obsoletes RFC 2133) (Obsoleted by RFC 3493) (Updated by RFC 3152)(Status: INFORMATIONAL)

RFC 2590 Transmission of IPv6 Packets over Frame Relay Networks Specification. A. Conta, A. Malis, M.Mueller. May 1999. (Format: TXT=41,817 bytes) (Status: PROPOSED STANDARD)

RFC 2675 IPv6 Jumbograms. D. Borman, S. Deering, R. Hinden. August 1999. (Format: TXT=17,320 bytes)

(Obsoletes RFC 2147) (Status: PROPOSED STANDARD)RFC 2710 Multicast Listener Discovery (MLD) for IPv6. S. Deering, W. Fenner, B. Haberman. October 1999.(Format: TXT=46,838 bytes) (Updated by RFC 3590, RFC 3810) (Status: PROPOSED STANDARD)

RFC 2711 IPv6 Router Alert Option. C. Partridge, A. Jackson. October 1999. (Format: TXT=11,973 bytes)(Status: PROPOSED STANDARD)

RFC 2732 Format for Literal IPv6 Addresses in URL's. R. Hinden, B. Carpenter, L. Masinter. December 1999.(Format: TXT=7,984 bytes) (Obsoleted by RFC 3986) (Updates RFC 2396) (Status: PROPOSED STANDARD)

64











































RFC 2740 OSPF for IPv6. R. Coltun, D. Ferguson, J. Moy. December 1999. (Format: TXT=18,9810 bytes)(Status: PROPOSED STANDARD)

RFC 2772 6Bone Backbone Routing Guidelines. R. Rockell, R. Fink. February 2000. (Format: TXT=28,565

bytes) (Obsoletes RFC 2546) (Updated by RFC 3152) (Status: INFORMATIONAL)

RFC 2874 DNS Extensions to Support IPv6 Address Aggregation and Renumbering. M. Crawford, C. Huitema.July 2000. (Format: TXT=44,204 bytes) (Updates RFC 1886) (Updated by RFC 3152, RFC 3226, RFC 3363,RFC 3364) (Status: EXPERIMENTAL)

RFC 2893 Transition Mechanisms for IPv6 Hosts and Routers. R. Gilligan, E. Nordmark. August 2000. (Format:TXT=62,731 bytes) (Obsoletes RFC 1933) (Obsoleted by RFC 4213) (Status: PROPOSED STANDARD)

RFC 2894 Router Renumbering for IPv6. M. Crawford. August 2000. (Format: TXT=69,135 bytes) (Status:PROPOSED STANDARD)

RFC 2921 6BONE pTLA and pNLA Formats (pTLA). B. Fink. September 2000. (Format: TXT=14,218 bytes)(Status: INFORMATIONAL)

RFC 2928 Initial IPv6 Sub-TLA ID Assignments. R. Hinden, S. Deering, R. Fink, T. Hain. September 2000.

(Format: TXT=11,882 bytes) (Status: INFORMATIONAL)

RFC 3019 IP Version 6 Management Information Base for The Multicast Listener Discovery Protocol. B.Haberman, R. Worzella. January 2001. (Format: TXT=28,293 bytes) (Status: PROPOSED STANDARD)

RFC 3041 Privacy Extensions for Stateless Address Autoconfiguration in IPv6. T. Narten, R. Draves. January2001. (Format: TXT=44,446 bytes) (Status: PROPOSED STANDARD)

RFC 3053 IPv6 Tunnel Broker. A. Durand, P. Fasano, I. Guardini, D. Lento. January 2001. (Format:TXT=27,336 bytes) (Status: INFORMATIONAL)

RFC 3056 Connection of IPv6 Domains via IPv4 Clouds. B. Carpenter, K. Moore. February 2001. (Format:TXT=54,902 bytes) (Status: PROPOSED STANDARD)

RFC 3089 A SOCKS-based IPv6/IPv4 Gateway Mechanism. H. Kitamura. April 2001. (Format: TXT=25,193 bytes) (Status: INFORMATIONAL)

RFC 3111 Service Location Protocol Modifications for IPv6. E. Guttman. May 2001. (Format: TXT=25,543 bytes) (Status: PROPOSED STANDARD)

RFC 3122 Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification. A. Conta. June 2001.(Format: TXT=40,416 bytes) (Status: PROPOSED STANDARD)

RFC 3142 An IPv6-to-IPv4 Transport Relay Translator. J. Hagino, K. Yamamoto. June 2001. (Format:TXT=20,864 bytes) (Status: INFORMATIONAL)

RFC 3146 Transmission of IPv6 Packets over IEEE 1394 Networks. K. Fujisawa, A. Onoe. October 2001.(Format: TXT=16,569 bytes) (Status: PROPOSED STANDARD)

RFC 3162 RADIUS and IPv6. B. Aboba, G. Zorn, D. Mitton. August 2001. (Format: TXT=20,492 bytes) (Status:PROPOSED STANDARD)

RFC 3175 Aggregation of RSVP for IPv4 and IPv6 Reservations. F. Baker, C. Iturralde, F. Le Faucheur, B.Davie. September 2001. (Format: TXT=88,681 bytes) (Status: PROPOSED STANDARD)

RFC 3177 IAB/IESG Recommendations on IPv6 Address Allocations to Sites. IAB, IESG. September 2001.(Format: TXT=23,178 bytes) (Status: INFORMATIONAL)

RFC 3178 IPv6 Multihoming Support at Site Exit Routers. J. Hagino, H. Snyder. October 2001. (Format:TXT=24,453 bytes) (Status: INFORMATIONAL)

65


































RFC 3226 DNSSEC and IPv6 A6 aware server/resolver message size requirements. O. Gudmundsson. December 2001. (Format: TXT=12,078 bytes) (Updates RFC 2535, RFC 2874) (Updated by RFC 4033, RFC 4034, RFC4035) (Status: PROPOSED STANDARD)

RFC 3266 Support for IPv6 in Session Description Protocol (SDP). S. Olson, G. Camarillo, A. B. Roach. June2002. (Format: TXT=8,693 bytes) (Obsoleted by RFC 4566) (Updates RFC 2327) (Status: PROPOSEDSTANDARD)

RFC 3306 Unicast-Prefix-based IPv6 Multicast Addresses. B. Haberman, D. Thaler. August 2002. (Format:TXT=12,713 bytes) (Updated by RFC 3956, RFC 4489) (Status: PROPOSED STANDARD)

RFC 3307 Allocation Guidelines for IPv6 Multicast Addresses. B. Haberman. August 2002. (Format:TXT=15,742 bytes) (Status: PROPOSED STANDARD)

RFC 3314 Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards. M. Wasserman,Ed. September 2002. (Format: TXT=48,168 bytes) (Status: INFORMATIONAL)

RFC 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6). R. Droms, Ed., J. Bound, B. Volz, T.Lemon, C. Perkins, M. Carney. July 2003. (Format: TXT=231,402 bytes) (Updated by RFC 4361) (Status:

PROPOSED STANDARD)RFC 3316 Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts. J. Arkko, G.Kuijpers, H. Soliman, J. Loughney, J. Wiljakka. April 2003. (Format: TXT=48,741 bytes) (Status:INFORMATIONAL)

RFC 3319 Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP)Servers. H. Schulzrinne, B. Volz. July 2003. (Format: TXT=14,444 bytes) (Status: PROPOSED STANDARD)

RFC 3363 Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS). R.Bush, A. Durand, B. Fink, O. Gudmundsson, T. Hain. August 2002. (Format: TXT=11,055 bytes) (Updates RFC2673, RFC 2874) (Status: INFORMATIONAL)

RFC 3364 Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6). R. Austein.August 2002. (Format: TXT=26,544 bytes) (Updates RFC 2673, RFC 2874) (Status: INFORMATIONAL)

RFC 3484 Default Address Selection for Internet Protocol version 6 (IPv6). R. Draves. February 2003. (Format:TXT=55,076 bytes) (Status: PROPOSED STANDARD)

RFC 3493 Basic Socket Interface Extensions for IPv6. R. Gilligan, S. Thomson, J. Bound, J. McCann, W.Stevens. February 2003. (Format: TXT=82,570 bytes) (Obsoletes RFC 2553) (Status: INFORMATIONAL)

RFC 3513 Internet Protocol Version 6 (IPv6) Addressing Architecture. R. Hinden, S. Deering. April 2003.(Format: TXT=53,920 bytes) (Obsoletes RFC 2373) (Obsoleted by RFC 4291) (Status: PROPOSEDSTANDARD)

RFC 3531 A Flexible Method for Managing the Assignment of Bits of an IPv6 Address Block. M. Blanchet.April 2003. (Format: TXT=11,314 bytes) (Status: INFORMATIONAL)

RFC 3542 Advanced Sockets Application Program Interface (API) for IPv6. W. Stevens, M. Thomas, E. Nordmark, T. Jinmei. May 2003. (Format: TXT=173,028 bytes) (Obsoletes RFC 2292) (Status:INFORMATIONAL)

RFC 3582 Goals for IPv6 Site-Multihoming Architectures. J. Abley, B. Black, V. Gill. August 2003. (Format:TXT=17,045 bytes) (Status: INFORMATIONAL)

RFC 3587 IPv6 Global Unicast Address Format. R. Hinden, S. Deering, E. Nordmark. August 2003. (Format:TXT=8,783 bytes) (Obsoletes RFC 2374) (Status: INFORMATIONAL)

RFC 3595 Textual Conventions for IPv6 Flow Label. B. Wijnen. September 2003. (Format: TXT=11,746 bytes)(Status: PROPOSED STANDARD)

66












































RFC 3596 DNS Extensions to Support IP Version 6. S. Thomson, C. Huitema, V. Ksinant, M. Souissi. October 2003. (Format: TXT=14,093 bytes) (Obsoletes RFC 3152, RFC 1886) (Status: DRAFT STANDARD)

RFC 3633 IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6. O. Troan, R. Droms.

December 2003. (Format: TXT=45,308 bytes) (Status: PROPOSED STANDARD)

RFC 3646 DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6). R. Droms,Ed. December 2003. (Format: TXT=13,312 bytes) (Status: PROPOSED STANDARD)

RFC 3697 IPv6 Flow Label Specification. J. Rajahalme, A. Conta, B. Carpenter, S. Deering. March 2004.(Format: TXT=21,296 bytes) (Status: PROPOSED STANDARD)

RFC 3701 6bone (IPv6 Testing Address Allocation) Phaseout. R. Fink, R. Hinden. March 2004. (Format:TXT=12,019 bytes) (Obsoletes RFC 2471) (Status: INFORMATIONAL)

RFC 3736 Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6. R. Droms. April 2004.(Format: TXT=18,510 bytes) (Status: PROPOSED STANDARD)

RFC 3750 Unmanaged Networks IPv6 Transition Scenarios. C. Huitema, R. Austein, S. Satapati, R. van der Pol.April 2004. (Format: TXT=48,153 bytes) (Status: INFORMATIONAL)

RFC 3756 IPv6 Neighbor Discovery (ND) Trust Models and Threats. P. Nikander, Ed., J. Kempf, E. Nordmark.May 2004. (Format: TXT=56,674 bytes) (Status: INFORMATIONAL)

RFC 3769 Requirements for IPv6 Prefix Delegation. S. Miyakawa, R. Droms. June 2004. (Format: TXT=10,287 bytes) (Status: INFORMATIONAL)

RFC 3775 Mobility Support in IPv6. D. Johnson, C. Perkins, J. Arkko. June 2004. (Format: TXT=393,514 bytes)(Status: PROPOSED STANDARD)

RFC 3776 Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents. J. Arkko, V.Devarapalli, F. Dupont. June 2004. (Format: TXT=87,076 bytes) (Status: PROPOSED STANDARD)

RFC 3810 Multicast Listener Discovery Version 2 (MLDv2) for IPv6. R. Vida, Ed., L. Costa, Ed. June 2004.(Format: TXT=153,579 bytes) (Updates RFC 2710) (Updated by RFC 4604) (Status: PROPOSED STANDARD)

RFC 3831 Transmission of IPv6 Packets over Fibre Channel. C. DeSanti. July 2004. (Format: TXT=53,328 bytes)(Obsoleted by RFC 4338) (Status: PROPOSED STANDARD)

RFC 3849 IPv6 Address Prefix Reserved for Documentation. G. Huston, A. Lord, P. Smith. July 2004. (Format:TXT=7,872 bytes) (Status: INFORMATIONAL)

RFC 3898 Network Information Service (NIS) Configuration Options for Dynamic Host Configuration Protocolfor IPv6 (DHCPv6). V. Kalusivalingam. October 2004. (Format: TXT=13,955 bytes) (Status: PROPOSEDSTANDARD)

RFC 3901 DNS IPv6 Transport Operational Guidelines. A. Durand, J. Ihren. September 2004. (Format:TXT=10,025 bytes) (Also BCP0091) (Status: BEST CURRENT PRACTICE)

RFC 3904 Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks. C. Huitema, R. Austein, S.Satapati, R. van der Pol. September 2004. (Format: TXT=46,844 bytes) (Status: INFORMATIONAL)

RFC 3919 Remote Network Monitoring (RMON) Protocol Identifiers for IPv6 and Multi Protocol LabelSwitching (MPLS). E. Stephan, J. Palet. October 2004. (Format: TXT=14,228 bytes) (Status:INFORMATIONAL)

RFC 3956 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address. P. Savola, B.Haberman. November 2004. (Format: TXT=40,136 bytes) (Updates RFC 3306) (Status: PROPOSEDSTANDARD)

RFC 3974 SMTP Operational Experience in Mixed IPv4/v6 Environments. M. Nakamura, J. Hagino. January2005. (Format: TXT=22,729 bytes) (Status: INFORMATIONAL)

67

































RFC 4260 Mobile IPv6 Fast Handovers for 802.11 Networks. P. McCann. November 2005. (Format:TXT=35,276 bytes) (Status: INFORMATIONAL)

RFC 4283 Mobile Node Identifier Option for Mobile IPv6 (MIPv6). A. Patel, K. Leung, M. Khalil, H. Akhtar, K.

Chowdhury. November 2005. (Format: TXT=14,653 bytes) (Status: PROPOSED STANDARD)

RFC 4285 Authentication Protocol for Mobile IPv6. A. Patel, K. Leung, M. Khalil, H. Akhtar, K. Chowdhury.January 2006. (Format: TXT=40,874 bytes) (Status: INFORMATIONAL)

RFC 4291 IP Version 6 Addressing Architecture. R. Hinden, S. Deering. February 2006. (Format: TXT=52,897 bytes) (Obsoletes RFC 3513) (Status: DRAFT STANDARD)

RFC 4294 IPv6 Node Requirements. J. Loughney, Ed. April 2006. (Format: TXT=39,125 bytes) (Status:INFORMATIONAL)

RFC 4295 Mobile IPv6 Management Information Base. G. Keeni, K. Koide, K. Nagami, S. Gundavelli. April2006. (Format: TXT=209,038 bytes) (Status: PROPOSED STANDARD)

RFC 4311 IPv6 Host-to-Router Load Sharing. R. Hinden, D. Thaler. November 2005. (Format: TXT=10,156 bytes) (Updates RFC 2461) (Status: PROPOSED STANDARD)

RFC 4330 Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI. D. Mills. January 2006.(Format: TXT=67,930 bytes) (Obsoletes RFC 2030, RFC 1769) (Status: INFORMATIONAL)

RFC 4338 Transmission of IPv6, IPv4, and Address Resolution Protocol (ARP) Packets over Fibre Channel. C.DeSanti, C. Carlson, R. Nixon. January 2006. (Format: TXT=75,541 bytes) (Obsoletes RFC 3831, RFC 2625)(Status: PROPOSED STANDARD)

RFC 4339 IPv6 Host Configuration of DNS Server Information Approaches. J. Jeong, Ed. February 2006.(Format: TXT=60,803 bytes) (Status: INFORMATIONAL)

RFC 4380 Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs). C. Huitema.February 2006. (Format: TXT=132,607 bytes) (Status: PROPOSED STANDARD)

RFC 4429 Optimistic Duplicate Address Detection (DAD) for IPv6. N. Moore. April 2006. (Format:TXT=33,123 bytes) (Status: PROPOSED STANDARD)

RFC 4443 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification.A. Conta, S. Deering, M. Gupta, Ed. March 2006. (Format: TXT=48,969 bytes) (Obsoletes RFC 2463) (UpdatesRFC 2780) (Status: DRAFT STANDARD)

RFC 4449 Securing Mobile IPv6 Route Optimization Using a Static Shared Key. C. Perkins. June 2006. (Format:TXT=15,080 bytes) (Status: PROPOSED STANDARD)

RFC 4472 Operational Considerations and Issues with IPv6 DNS. A. Durand, J. Ihren, P. Savola. April 2006.(Format: TXT=68,882 bytes) (Status: INFORMATIONAL)

RFC 4477 Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues. T. Chown, S.Venaas, C. Strauf. May 2006. (Format: TXT=30,440 bytes) (Status: INFORMATIONAL)

RFC 4487 Mobile IPv6 and Firewalls: Problem Statement. F. Le, S. Faccin, B. Patil, H. Tschofenig. May 2006.

(Format: TXT=32,022 bytes) (Status: INFORMATIONAL)RFC 4489 A Method for Generating Link-Scoped IPv6 Multicast Addresses. J-S. Park, M-K. Shin, H-J. Kim.April 2006. (Format: TXT=12,224 bytes) (Updates RFC 3306) (Status: PROPOSED STANDARD)

RFC 4554 Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks. T. Chown. June 2006. (Format:TXT=23,355 bytes) (Status: INFORMATIONAL)

RFC 4580 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Subscriber-ID Option. B.Volz. June 2006. (Format: TXT=10,937 bytes) (Status: PROPOSED STANDARD)

69

































RFC 4584 Extension to Sockets API for Mobile IPv6. S. Chakrabarti, E. Nordmark. July 2006. (Format:TXT=53,995 bytes) (Status: INFORMATIONAL)

RFC 4620 IPv6 Node Information Queries. M. Crawford, B. Haberman, Ed. August 2006. (Format: TXT=31,134

bytes) (Status: EXPERIMENTAL)

RFC 4640 Problem Statement for bootstrapping Mobile IPv6 (MIPv6). A. Patel, Ed., G. Giaretta, Ed. September 2006. (Format: TXT=49,926 bytes) (Status: INFORMATIONAL)

RFC 4649 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option. B. Volz.August 2006. (Format: TXT=10,940 bytes) (Status: PROPOSED STANDARD)

RFC 4659 BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN. J. De Clercq, D. Ooms, M.Carugi, F. Le Faucheur. September 2006. (Format: TXT=42,090 bytes) (Status: PROPOSED STANDARD)

RFC 4668 RADIUS Authentication Client MIB for IPv6. D. Nelson. August 2006. (Format: TXT=48,252 bytes)(Obsoletes RFC 2618) (Status: PROPOSED STANDARD)

RFC 4669 RADIUS Authentication Server MIB for IPv6. D. Nelson. August 2006. (Format: TXT=50,525 bytes)(Obsoletes RFC 2619) (Status: PROPOSED STANDARD)

RFC 4670 RADIUS Accounting Client MIB for IPv6. D. Nelson. August 2006. (Format: TXT=44,667 bytes)(Obsoletes RFC 2620) (Status: INFORMATIONAL)

RFC 4671 RADIUS Accounting Server MIB for IPv6. D. Nelson. August 2006. (Format: TXT=47,694 bytes)(Obsoletes RFC 2621) (Status: INFORMATIONAL)

RFC 4692 Considerations on the IPv6 Host Density Metric. G. Huston. October 2006. (Format: TXT=41,357 bytes) (Status: INFORMATIONAL)

70



















Author Bio

Jeff YoungSenior Analyst

Emphasis: Network architecture, Internet networks and backbones, telecommunication service providers

Background: 20 years of experience working in IT and telecommunications industry. VP Architecture for Alcatelsupporting Triple Play networks (including AT&T project Lightspeed). CTO of Alcatel’s IP Division. VP of Engineering for Cable & Wireless and Chief Architect of the C&W Global Internet. Infrastructure Engineer for The National Institute of Health.

Primary Distinctions: Frequent speaker in industry conferences and panels. Appeared before members of congresson issues of rural telecommunications and net neutrality. Led the group of engineers who moved from InternetMCIto C&W during acquisition. Designed later versions of InternetMCI and created content delivery networks and earlyvideo distribution networks in cooperation with Real Networks.

burton 2007 ipv6 technology overview

Documents