2460

IPv6 and DNSSEC Are Respectively 20 and 19 Years Old. Same Fight and Challenges?

IPv6 and DNSSEC are respectively 20 and 19 years old. Their backgrounds, obstacles and outlooks make them close in many ways… This post is dedicated to them.

A few weeks ago I came across an old interview of me by ITespresso.fr from 10 years back entitled “IPv6 frees human imagination”. At the time, I was talking about the contributions IPv6 was expected to make and the challenges it had to face. After reading the article again, I realized that it has become a little dusty (plus a blurred photo of the interviewee :-)).

But what caught my attention the most in the interview was my assertion: “If IPv6 does not prevail in 2006, it’s a safe bet that it will happen in 2007”. Wow! Is that precise or is that precise? Since then, although things have changed, we are still far from that goal.

In the interview and in its totally inaccurate prediction I nonetheless found the initial motivation for sharing my current thoughts and analyses ten years on, with the promise not to try to make that kind of prediction again :-). That motivation, however, was insufficient to put pen to paper until chance opened a “window of opportunity” for a few weeks when IPv6 celebrated its 20th anniversary in December 2015. Another coincidental event was the 19th anniversary of DNSSEC in January 2016. Prompted by these various motivators I decided to broaden the scope of this post beyond the subject of IPv6 alone, and incorporate thoughts on the past and future of DNSSEC, a technology that has known a similar fate to date, in addition to having a similar age.

Here I am at last, keyboard pen in hand, ready to face the blank page. To work!

The purpose of this post is to share feedback, in the form of an analogical exercise, on the respective careers of IPv6 and DNSSEC and the challenges facing both technologies. I have decided to focus on the similitudes between IPv6 and DNSSEC rather than dwell on what separates them, especially as both technologies are derived from functional / protocol layers that are fundamentally different.

An analogical exercise of this type can be seriously tackled only after sufficient hindsight and distance from the subject, while capitalizing on so many years of observation. I hope this post will live up to that requirement.

* * *

Several years of gestation, 20 years of maturation

In the context of the development of Internet standards, par excellence in the Internet Engineering Task Force (IETF), the birth of a concept / protocol / technology is materialized by publishing a “Request For Comments” (RFC). In this case, the first specification for IPv6 [RFC 1883] was published in December 1995, while the first specification for DNSSEC [RFC 2065] was published[1] in January 1971 (those who wish to know more about the genesis of IPv6 or DNSSEC can visit this page for IPv6 or this page for DNSSEC, where one can note that the first initiatives took place much earlier).

With hindsight, and regardless of the status of the deployment of IPv6 and DNSSEC today, I am fortunate to have seen both technologies grow, to have been involved in both their careers, and above all to have witnessed, for the past 18 years, the first tests, the first go-live deployments (in particular by Afnic in 2003), outreach efforts, even the multiple barriers and challenges in their deployment faced by their respective communities. I wrote “respective communities”, when in fact they substantially overlap, since many of the pioneers in these technologies have worked on both fronts at the same time.

Use of the term “new” technologies

The first thing that needs to be put into perspective is the terminology used. I find it rather amusing that we (including me, don’t worry!) continue to use “new protocol”, “new technology”, “new extension” or “new version” when talking about IPv6 and / or DNSSEC, when their age is significantly long compared with the timescale of the digital age in which we live. No doubt our use of the term “new” is abusive, given the (still) low level of deployment of both technologies on the global scale. But its use still seems perfectly acceptable, and I personally intend to continue to refer to them as new, as long as the balance of power has not been reversed.

IPv6 and DNSSEC: close careers

Developments and extensions of standardized technologies within the IETF community are rarely disruptive, often for reasons of interoperability / backward compatibility. Indeed, in the “IETF standardization culture”, in case of tension, arbitration is often to the advantage of the objective/principle of stability and continuity of service (that of the Internet globally) to the detriment of introducing any significant leap in features and/or performance. This IETF culture is often translated into architectural principles, as can be seen in section 3 of [RFC 6709] for example.

Comparing these principles with the criteria that make a protocol a “wild success” [RFC 5218], given the difficulty of IPv6 and DNSSEC in becoming firmly established in their respective environments, the conclusion is severe for both technologies. While IPv4 and DNS (without security extensions) are considered a success, and may even be considered to some extent a “wild success”, IPv6 and the DNS Security Extensions (DNSSEC) are still far from being entitled to the (simple) rank of a “success”.

It is worth recalling that the initial goal for IPv6 and DNSSEC was simply to be successful, and not necessarily to be a “wild success”. But we should also recall that even “simply” being successful has often been the result of perseverance, rarely that of chance or a long and passive (mutual) wait. It is difficult to predict and achieve success for any new technology whose benefits are a priori collective, as is the case for IPv6 and DNSSEC. This collective benefit is above all the result of the network effect, often explained by “Metcalfe’s Law”.

What makes them so close?

First of all, they were invented at a time when the technology to be (ultimately) “replaced” or “spread” was already widely deployed, and this clearly represented a first brake. As a result, any deployment strategy of either of the two “new” technologies had to be gradual (no D-day) and preserve the interoperability and continuity of the overall operation of the Internet. Regarding IPv6, one thing to be avoided at all costs was a certain partitioning (“balkanization”) of the Internet into one set of networks that can only communicate via IPv4 and others that can only communicate via IPv6. For DNSSEC, the objective was mainly to ensure that the content of DNSSEC signed zones continued to be provided as “regular” (non-DNSSEC) content for resolvers that do not announce DNSSEC compatibility (“DNSSEC OK”).

Secondly, IPv6 and DNSSEC each experienced a long period of testing at the local, national and global level, with more or less close cooperation between stakeholders and more or less rigorous assessment of the results. Thus for IPv6, the 6bone network, launched in 1996 by three players [Uni-C (Denmark), G6 (France) and WIDE (Japan)] based on tunnels (encapsulation of IPv6 in IPv4), quickly evolved to provide a global experimentation platform for the basic features of the new protocol (with 2 IPv6 addressing plans tested at its peak, the 6bone had more than 1,000 sites in more than 50 participating countries). Thanks to the conclusive results obtained, the IPv6 pioneers deployed pilot networks and then real live networks late in the 90’s and the first decade of the 21st century. Several players followed the model to the point where the 6bone network, interconnected with the live networks, had become the “weak link” in terms of stability and performance and caused increasing degradation at the global level. It therefore became necessary to dismantle the network, and the phase-out was announced on 6/6/6 (note the symbol!).

For DNSSEC, the pioneers first of all fought to obtain or develop each the tools necessary to sign their zones, before collectively putting pressure on ICANN to sign the root zone, like the RIPE community in 2007 or the workshop organized by the .se in 2008, which was the first ccTLD to deploy DNSSEC. Meanwhile, a bypass technique was adopted by the IETF, with the DNSSEC Lookaside Validation (DLV) [RFC 5074], and widely deployed based on the registry made available by the ISC. The root zone having been DNSSEC signed in 2010, the managers of signed top-level domains (TLD) gradually withdrew their keys from the DLV registry after creating the link connecting them to the root in the DNSSEC chain of trust. As a result, the ISC’s DLV registry began to lose its interest and the ISC therefore announced the gradual turndown of the registry by 2017.

Each of these experimental devices (6bone and DLV) therefore lasted nearly 10 years and it is fairly symptomatic of the very low level of initiative and involvement among the stakeholders conducting the experiments, and this “growth retardation” partly explains that of the maturity of two technologies.

Furthermore, during these long test periods, the IPv6 and DNSSEC communities were both obsessed about finding one or more (cumulative) factors that might significantly accelerate the adoption and deployment of these technologies. The most recurrent possibilities included the following:

  1. a “killer app” is found, i.e. a use that is indispensable but requires deployment of the technology;
  2. one or more major players decide to massively deploy and pull the others;
  3. one or more governments start to impose deployment by decree and/or establish financial/fiscal incentives/deterrents (bonus/malus) to incite the stakeholders to adopt these technologies;
  4. a significant threat occurs, causes a major risk of discontinuity/disruption of the existing services thus forcing the players into a corner, leaving them with no choice other than to deploy the technology in question, given the emergency.

Without reviewing one by one the items in the list above, today we can safely say that for both IPv6 and DNSSEC, the idea of a “killer app” ended up by being killed! There was little hope of finding one, and the collective energy could be better invested elsewhere… In particular, everything was tried to (over)sell the potential of IPv6, without ever succeeding in demonstrating the reality of its superiority over IPv4 to the more “resistant” users. For DNSSEC, the search by some of a “killer application” ended up by being caricatured by the others in a single sentence: “DNSSEC is a solution looking for a problem” 🙂

Moreover, the “major” players had made announcements for nearly 10 years on their intention to implement/deploy IPv6 and/or DNSSEC, announcements that were publicized widely enough but with mixed results. This was the case for example of the release of Microsoft’s Windows Vista with its “native support” for IPv6, or the US government’s decision to integrate, in turn, IPv6 and DNSSEC, in the networks of all the federal agencies, with updates, regular reviews of the degree to which the objectives had been met, or Comcast’s announcement to deploy DNSSEC for their millions of customers. Finally, in Europe, let us remember the press release of the European Commission in 2008 announcing a target set by the EC: “[…] in 2010, 25% of companies, governments and European individuals use IPv6”. But the EC had failed to define the indicators and measurement parameters used to assess / monitor the level of deployment / use of IPv6 to maturity, and monitoring beyond. It was in April 2010 that the OECD has filled this gap. Its report “INTERNET ADDRESSING: MEASURING DEPLOYMENT OF IPv6” remains to date a known reference for the diversity of IPv6 indicators and metrics dealt with, as well as for the rigor of their definition.

In addition to these announcements, a sense of urgency was created on several occasions, involving many players worldwide. As can be read in an issue paper published by Afnic in 2011 (“IPv6, A Passport For The Future Internet”), some of the most significant occasions for IPv6 including the alarming (alarmist?) predictions by Geoff Huston announced in 2007 for an end of the IPv4 world in 2011, and then the effective exhaustion of the IANA IPv4 stock in 2011, in its wake causing a large number of players to get involved in the “World IPv6 Day” (2011/06/08), before seeing even more of them a year later (from 2012/6/6) with a permanent deployment target, the “World IPv6 Launch”. For DNSSEC, it was mainly the discovery of the “Kaminsky DNS flaw” which forced the world DNS community to rally around DNSSEC as the only long-term solution to mitigate cache-poisoning attacks.

Of course, many were betting on the fact that the adoption of IPv6 and/or DNSSEC by the “Internet giants” and the sense of urgency created globally would result in a massive push to deploy these technologies, and thereby make up for lost time. If these events did help the deployment of IPv6 / DNSSEC to take off, it is clear that we are far from the hoped-for tidal wave, even many years later.

Obstacles and Outlooks

IPv6 and DNSSEC face challenges of a similar nature to their widespread adoption. Sometimes presented as “new standards” with which “we must comply anyway sooner or later”, they leave the choice up to the players directly concerned and especially those who are not directly concerned to postpone the decision to deploy as long as possible.

The network’s players seem to have been in midstream for a long time. On the one hand, those who have deployed are struggling/slow to reap the expected return on investment and are experiencing growing frustration in not always being able to fully benefit from these “new technologies” and on the other hand, those who have still not deployed them, can still buy time and only “jump on the bandwagon” when it becomes imperative and urgent for everyone to do so.

Meanwhile, in no case must the former’s frustration be seen as a loss of motivation or despair. In other situations, when the objectives are not met, it is legitimate to consider “pausing a while”, “cutting losses” and/or “activating a (hypothetical) plan B”. But in the case of IPv6 and DNSSEC, the Internet community is unanimous: “we’ve got to do it!” Even if global deployment is taking much more time than expected, given the continued growth of the penetration rate of these technologies worldwide, it is clear that perseverance pays. To be convinced one need only visit some of the many websites that offer global or country-specific statistics that show the development over time of the level of deployment. For IPv6, the portal of the ISOC “Deploy360” program lists the Google site that shows the development of IPv6 penetration in users’ browsers querying the search engine, or the 6lab (Cisco) site, which integrates infrastructure indicators [prefixes, transit, autonomous systems (AS)]2 and content, or the site of the Internet Resilience Observatory in France, where the development of IPv6 indicators (routing and DNS) has been monitored since 2011. In addition, the same Deploy 360 program (ISOC) compiles several benchmarks for global or country-specific DNSSEC statistics.

The outlooks for IPv6 are increasingly promising despite the delay, even though the technology is no longer listed among the trends of the moment (as shown in the recent editions of the “Gartner Hype Cycle for Emerging Technologies”, when IPv6 was at the top in 2006). Indeed, now that everyone has understood that IPv6 is neither a product nor a use in itself, attention is being focused on its power to enable new uses, once deployed.

When speaking for example about the Internet of Things, which now has its own “Gartner Hype Cycle”, IPv6 is often mentioned as a logical ally of IoT or even a prerequisite. But beware of confusion and quite common shortcuts! First, if the huge IPv6 address space can indeed assign an address to each object in the world, including the tens of billions of connected objects (from 20 to 50 billion according to forecasts) that may “invade us” over the next 5 years, only those who have the ability to “speak IP” to “deserve” one! I can already see coming the question: “Yes, okay, but still billions of objects will need to be connected with IP, right? And in this case, IPv4 space residue will not make it, unlike IPv6, isn’t it?” In fact, the answer is not so simple. Just observe the current deployments that are almost only in IPv4. At the risk of disappointing the reader, the private address of IPv4 can (continue to) meet the addressing operators’ needs for the next 20 years if those continue to make choices for closed network architectures with centralized control and management (à la “Minitel”). However, IPv4 is clearly not a sustainable solution when we think of the need for making possible end-to-end communications between connected objects, typically through open and interoperable architectures. As a matter of fact, from this perspective of IPv6 that fosters innovation, notably “permissionless innovation”, the qualifier of enabler, takes on its full meaning.

Similarly, if 3G deployments are almost exclusively made in IPv4 (the botched “IPv6-UMTS” meet-up has never been caught up), for the more recent 4G deployments, certain mobile operators will increasingly “inject v6” (subject to a few transition mechanisms in terms of access), such as T-Mobile (USA) and Orange Poland. Geoff Huston said as much in fairly striking fashion at a recent presentation at the RIPE meeting 71, “An Update on Mobility in Today’s Internet” (cf. transparent #15 and video at [15:00 – 15:20]): “[…] If the mobile industry doesn’t do v6, it’s not going to happen… That’s simple. Because, the mobile industry IS the Internet […]”.

For DNSEC, several factors will determine whether its deployment accelerates in the coming years, or its overall slow pace is maintained worldwide, especially on the part of operators of recursive servers (resolvers). These cumulative factors include a possible increase in the level of the risk of attacks against which only this technology can help fight (such as by cache poisoning) or the maturity of application software services such as DANE (DNS-based Authentication of Named Entities), which uses DNSSEC as a PKI and is therefore vital for their operation.

No doubt when preparing to launch a new technology fully based on network effects, provision is necessarily made for interdependencies between the stakeholders concerned, often causing deadlocks, vicious circles and other chicken-and-egg types of problems. However, the most difficult task remains that of collectively developing a global strategy (by the “pioneers”) or individually (by the “followers”) and to implement it. As prerequisites (but which are unfortunately insufficient on their own), that strategy must:

  • identify in advance the most significant obstacles that need to be overcome, preferably with a prior idea of their intensity and duration over time;
  • propose multiple action levers (outreach, incentives, capacity building, etc.) depending on the stakeholders and obstacles to be overcome (or bypassed);
  • convert the strategic levers into practical actions and schedule them according to a multi-year action plan;
  • provide for regular assessment of the results and the feedback loop to revise the strategy if necessary (and that is often the case!).

In conclusion, until IPv6 and DNSSEC establish themselves (as I still hope they will, but as promised, I am making no more predictions about dates :-)), we not only need to continue our efforts in terms of outreach and instruction, but must also remember that all of the players must first of all “put their own house in order,” before asking others (legitimately or not) to fulfill their role. Better still, according to the well-known expression “Eat your own dog food”, even when you think you’ve done your job well, it is important to check its quality, in order to set the example.

1 After many iterations, these specifications have undergone significant improvements, leading to stable standards for several years ([RFC 2460] for IPv6, in force since 1998 although some updates have been made to it over time, and [RFC 4033] [RFC 4034] [RFC 4035] for DNSSEC in force for over 10 years now, after a temporary switch to [RFC 2535] and related RFCs).

^ Back to the reference of the footnote

2 It is noteworthy that Belgium, which was far behind other European countries barely 5 years ago, now occupies first place worldwide, with a combined penetration rate of 56% (as at January 3, 2016, with 44% on the user side, according to 6lab – Cisco). Conversely, France, which led the pack at the time (and became “famous for IPv6 in addition to its fine wine and cheese”), is now far behind (32% of deployment as at January 3, 2016, with only 6.5% on the user side).

^ Back to the reference of the footnote

Written by Mohsen Souissi, Head of R&D at Afnic

Read more here:: www.circleid.com/rss/topics/ipv6

RFC 3232 – Assigned Numbers: RFC 1700 is Replaced by an On-line Database

Network Working Group                                J. Reynolds, Editor
Request for Comments: 3232                                    RFC Editor
Obsoletes: 1700                                             January 2002
Category: Informational


Assigned Numbers: RFC 1700 is Replaced by an On-line Database


Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This memo obsoletes RFC 1700 (STD 2) "Assigned Numbers", which
   contained an October 1994 snapshot of assigned Internet protocol
   parameters.

Description

   From November 1977 through October 1994, the Internet Assigned
   Numbers Authority (IANA) periodically published tables of the
   Internet protocol parameter assignments in RFCs entitled, "Assigned
   Numbers".  The most current of these Assigned Numbers RFCs had
   Standard status and carried the designation: STD 2.  At this time,
   the latest STD 2 is RFC 1700.

   Since 1994, this sequence of RFCs have been replaced by an online
   database accessible through a web page (currently, www.iana.org).
   The purpose of the present RFC is to note this fact and to officially
   obsolete RFC 1700, whose status changes to Historic.  RFC 1700 is
   obsolete, and its values are incomplete and in some cases may be
   wrong.

   We expect this series to be revived in the future by the new IANA
   organization.

Security Considerations

   This memo does not affect the technical security of the Internet.





Reynolds                     Informational                      [Page 1]

RFC 3232         RFC 1700 Replaced by On-line Database      January 2002


Author's Address

   Joyce K. Reynolds
   RFC Editor
   4676 Admiralty Way
   Marina del Rey, CA  90292
   USA

   EMail: rfc-editor@rfc-editor.org

The beginning of the end

IPv6 flip clock

Today is 6/6/2012, World IPv6 Launch Day. The day the Internet community permanently enables the IPv6 Internet protocol on their infrastructure. Some refer to this protocol as ‘The New Internet Protocol’. But is it new? No. Not at all.

To deal with the anticipated IPv4 address exhaustion, the Internet Engineering Task Force (IETF) developed IPv6 and described it in Internet standard document RFC 2460. This was published in December 1998. Due to the incompatibilty with the current IPv4 protocol, it was never widely adopted. Now that address exhaustion is imminent, the world is in a hurry to set things straight.

I am the proud owner of what is arguably the coolest IPv6 Internet domain name in the world: ipv6.net. I have owned it for a long time. Not too long ago I realized that 6 days after 6/6/2012, it has been exactly 15 years since the domain name was registered. Apparently, back in 1997, I envisioned that IPv6 was going to be big. I just didn’t know it would take such a long time. But are we there yet? No. Not even close.

Back then the community thought we would run out of IP addresses in just a couple of years. With some tricks we managed to stretch things out until now. We even back-ported some cool stuff from the new protocol into the old. It wasn’t until mid 2011 that we saw some serious global industry initiatives to promote adoption of IPv6: World IPv6 Day on June 8th. On that day some of the smaller as well as larger members of the global Internet community temporarily enabled IPv6 on their infrastructure. For some, just to see what would happen. For others a good test of their transition plan or chosen technology. Some ‘forgot’ to switch it off again. For most it was a big success; a final rehearsal for the big step: a global transition from IPv4 towards IPv6.

Today is the start of that transition. Content providers around the globe will provide access to their services over IPv6. Access providers will provide IPv6 access to their end-users. Hard- and software manufacturers will bring out IPv6 support for their products. This broad involvement will certainly help to solve the chicken and egg, content versus access, problem.

So what will happen after today? If all goes well, and I certainly expect so, we will have marked the beginning of the end of IPv4. It will take many years before IPv6 has become the dominant protocol and IPv4 is marked ‘legacy’. But I expect that after today more and more companies will make a start with their transition. For many it will be hard to make a good business case for it as there is not always a clear added business value. Just don’t wait too long as the landscape is rapidly changing.

Some advice for those about to take the plunge: take ample time to gather knowledge, create awareness among those involved, decide on a sound transition scenario, test and start planning.

And for me? Well, as an IT professional I will be helping out customers doing just that. Personally, I will continue to blog and tweet about IPv6 for a long time to come…

Cheers,

Erwin

RFC 2464 – Transmission of IPv6 Packets over Ethernet Networks

Network Working Group M. Crawford
Request for Comments: 2464 Fermilab
Obsoletes: 1972 December 1998
Category: Standards Track

Transmission of IPv6 Packets over Ethernet Networks

Status of this Memo

This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (1998). All Rights Reserved.

1. Introduction

This document specifies the frame format for transmission of IPv6
packets and the method of forming IPv6 link-local addresses and
statelessly autoconfigured addresses on Ethernet networks. It also
specifies the content of the Source/Target Link-layer Address option
used in Router Solicitation, Router Advertisement, Neighbor
Solicitation, Neighbor Advertisement and Redirect messages when those
messages are transmitted on an Ethernet.

This document replaces RFC 1972, "A Method for the Transmission of
IPv6 Packets over Ethernet Networks", which will become historic.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119].

2. Maximum Transmission Unit

The default MTU size for IPv6 [IPV6] packets on an Ethernet is 1500
octets. This size may be reduced by a Router Advertisement [DISC]
containing an MTU option which specifies a smaller MTU, or by manual
configuration of each node. If a Router Advertisement received on an
Ethernet interface has an MTU option specifying an MTU larger than
1500, or larger than a manually configured value, that MTU option may
be logged to system management but must be otherwise ignored.

For purposes of this document, information received from DHCP is
considered "manually configured" and the term Ethernet includes
CSMA/CD and full-duplex subnetworks based on ISO/IEC 8802-3, with
various data rates.

3. Frame Format

IPv6 packets are transmitted in standard Ethernet frames. The
Ethernet header contains the Destination and Source Ethernet
addresses and the Ethernet type code, which must contain the value
86DD hexadecimal. The data field contains the IPv6 header followed
immediately by the payload, and possibly padding octets to meet the
minimum frame size for the Ethernet link.

0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination |
+- -+
| Ethernet |
+- -+
| Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source |
+- -+
| Ethernet |
+- -+
| Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0 0 0 1 1 0 1 1 0 1 1 1 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 |
+- -+
| header |
+- -+
| and |
+- -+
/ payload ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

(Each tic mark represents one bit.)

4. Stateless Autoconfiguration

The Interface Identifier [AARCH] for an Ethernet interface is based
on the EUI-64 identifier [EUI64] derived from the interface's built-
in 48-bit IEEE 802 address. The EUI-64 is formed as follows.
(Canonical bit order is assumed throughout.)

The OUI of the Ethernet address (the first three octets) becomes the
company_id of the EUI-64 (the first three octets). The fourth and
fifth octets of the EUI are set to the fixed value FFFE hexadecimal.
The last three octets of the Ethernet address become the last three
octets of the EUI-64.

The Interface Identifier is then formed from the EUI-64 by
complementing the "Universal/Local" (U/L) bit, which is the next-to-
lowest order bit of the first octet of the EUI-64. Complementing
this bit will generally change a 0 value to a 1, since an interface's
built-in address is expected to be from a universally administered
address space and hence have a globally unique value. A universally
administered IEEE 802 address or an EUI-64 is signified by a 0 in the
U/L bit position, while a globally unique IPv6 Interface Identifier
is signified by a 1 in the corresponding position. For further
discussion on this point, see [AARCH].

For example, the Interface Identifier for an Ethernet interface whose
built-in address is, in hexadecimal,

34-56-78-9A-BC-DE

would be

36-56-78-FF-FE-9A-BC-DE.

A different MAC address set manually or by software should not be
used to derive the Interface Identifier. If such a MAC address must
be used, its global uniqueness property should be reflected in the
value of the U/L bit.

An IPv6 address prefix used for stateless autoconfiguration [ACONF]
of an Ethernet interface must have a length of 64 bits.

5. Link-Local Addresses

The IPv6 link-local address [AARCH] for an Ethernet interface is
formed by appending the Interface Identifier, as defined above, to
the prefix FE80::/64.

10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Identifier |
+----------+-----------------------+----------------------------+

6. Address Mapping -- Unicast

The procedure for mapping IPv6 unicast addresses into Ethernet link-
layer addresses is described in [DISC]. The Source/Target Link-layer
Address option has the following form when the link layer is
Ethernet.

0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- Ethernet -+
| |
+- Address -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Option fields:

Type 1 for Source Link-layer address.
2 for Target Link-layer address.

Length 1 (in units of 8 octets).

Ethernet Address
The 48 bit Ethernet IEEE 802 address, in canonical bit
order. This is the address the interface currently
responds to, and may be different from the built-in
address used to derive the Interface Identifier.

7. Address Mapping -- Multicast

An IPv6 packet with a multicast destination address DST, consisting
of the sixteen octets DST[1] through DST[16], is transmitted to the
Ethernet multicast address whose first two octets are the value 3333
hexadecimal and whose last four octets are the last four octets of
DST.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 1 0 0 1 1|0 0 1 1 0 0 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DST[13] | DST[14] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DST[15] | DST[16] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

8. Differences From RFC 1972

The following are the functional differences between this
specification and RFC 1972.

The Address Token, which was a node's 48-bit MAC address, is
replaced with the Interface Identifier, which is 64 bits in
length and based on the EUI-64 format [EUI64]. An IEEE-defined
mapping exists from 48-bit MAC addresses to EUI-64 form.

A prefix used for stateless autoconfiguration must now be 64 bits
long rather than 80. The link-local prefix is also shortened to
64 bits.

9. Security Considerations

The method of derivation of Interface Identifiers from MAC addresses
is intended to preserve global uniqueness when possible. However,
there is no protection from duplication through accident or forgery.

10. References

[AARCH] Hinden, R. and S. Deering "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.

[ACONF] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.

[DISC] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.

[EUI64] "Guidelines For 64-bit Global Identifier (EUI-64)",
http://standards.ieee.org/db/oui/tutorials/EUI64.html

[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.

[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

11. Author's Address

Matt Crawford
Fermilab MS 368
PO Box 500
Batavia, IL 60510
USA

Phone: +1 630 840-3461
EMail: crawdad@fnal.gov

12. Full Copyright Statement

Copyright (C) The Internet Society (1998). All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.