< draft-ietf-6man-ug-03.txt   draft-ietf-6man-ug-04.txt >
6MAN B. Carpenter 6MAN B. Carpenter
Internet-Draft Univ. of Auckland Internet-Draft Univ. of Auckland
Updates: 4291 (if approved) S. Jiang Updates: 4291 (if approved) S. Jiang
Intended status: Standards Track Huawei Technologies Co., Ltd Intended status: Standards Track Huawei Technologies Co., Ltd
Expires: February 27, 2014 August 26, 2013 Expires: April 04, 2014 October 01, 2013
Significance of IPv6 Interface Identifiers Significance of IPv6 Interface Identifiers
draft-ietf-6man-ug-03 draft-ietf-6man-ug-04
Abstract Abstract
The IPv6 addressing architecture includes a unicast interface The IPv6 addressing architecture includes a unicast interface
identifier that is used in the creation of many IPv6 addresses. identifier that is used in the creation of many IPv6 addresses.
Interface identifiers are formed by a variety of methods. This Interface identifiers are formed by a variety of methods. This
document clarifies that the bits in an interface identifier have no document clarifies that the bits in an interface identifier have no
generic meaning and that the identifier should be treated as an generic meaning and that the identifier should be treated as an
opaque value. In particular, RFC 4291 defines a method by which the opaque value. In particular, RFC 4291 defines a method by which the
Universal and Group bits of an IEEE link-layer address are mapped Universal and Group bits of an IEEE link-layer address are mapped
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 27, 2014. This Internet-Draft will expire on April 04, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 17
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem statement . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem statement . . . . . . . . . . . . . . . . . . . . . . 3
3. Usefulness of the U and G Bits . . . . . . . . . . . . . . . 6 3. Usefulness of the U and G Bits . . . . . . . . . . . . . . . 5
4. The Role of Duplicate Address Detection . . . . . . . . . . . 6 4. The Role of Duplicate Address Detection . . . . . . . . . . . 6
5. Clarification of Specifications . . . . . . . . . . . . . . . 7 5. Clarification of Specifications . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
9. Change log [RFC Editor: Please remove] . . . . . . . . . . . 9 9. Change log [RFC Editor: Please remove] . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
IPv6 unicast addresses consist of a prefix followed by an Interface IPv6 unicast addresses consist of a prefix followed by an Interface
Identifier (IID). The IID is supposed to be unique on the links Identifier (IID). The IID is supposed to be unique on the links
reached by routing to that prefix, giving a globally unique address. reached by routing to that prefix, giving an IPv6 address that is
According to the IPv6 addressing architecture [RFC4291], when a unique within the applicable scope (link local or global). According
64-bit IPv6 unicast IID is formed on the basis of an IEEE EUI-64 to the IPv6 addressing architecture [RFC4291], when a 64-bit IPv6
address, usually itself expanded from a 48-bit MAC address, a unicast IID is formed on the basis of an IEEE EUI-64 address, usually
particular format must be used: itself expanded from a 48-bit MAC address, a particular format must
be used:
"For all unicast addresses, except those that start with the binary "For all unicast addresses, except those that start with the binary
value 000, Interface IDs are required to be 64 bits long and to be value 000, Interface IDs are required to be 64 bits long and to be
constructed in Modified EUI-64 format." constructed in Modified EUI-64 format."
Thus the specification assumes that the normal case is to transform Thus the specification assumes that the normal case is to transform
an Ethernet-style address into an IID, but in practice, there are an Ethernet-style address into an IID, but in practice, there are
various methods of forming such an interface identifier. various methods of forming such an interface identifier.
The Modified EUI-64 format preserves the information provided by two The Modified EUI-64 format preserves the information provided by two
skipping to change at page 4, line 46 skipping to change at page 4, line 46
There was a presumption when IPv6 was designed and the IID format was There was a presumption when IPv6 was designed and the IID format was
first specified that a universally unique IID might prove to be very first specified that a universally unique IID might prove to be very
useful, for example to contribute to solving the multihoming problem. useful, for example to contribute to solving the multihoming problem.
Indeed, the addressing architecture [RFC4291] states this explicitly: Indeed, the addressing architecture [RFC4291] states this explicitly:
"The use of the universal/local bit in the Modified EUI-64 format "The use of the universal/local bit in the Modified EUI-64 format
identifier is to allow development of future technology that can take identifier is to allow development of future technology that can take
advantage of interface identifiers with universal scope." advantage of interface identifiers with universal scope."
However, this has not so far proved to be the case. Also, there is However, this has not so far proved to be the case. Also, there is
evidence from the field that despite the IEEE standard [IEEE802], MAC evidence from the field that MAC addresses with universal scope are
addresses with universal scope are sometime incorrectly assigned to sometimes assigned to multiple MAC interfaces. There are recurrent
multiple MAC interfaces. Firstly, there are recurrent reports of reports of manufacturers assigning the same MAC address to multiple
manufacturers assigning the same MAC address to multiple devices. devices, and significant re-use of the same virtual MAC address is
Secondly, significant re-use of the same virtual MAC address is
reported in virtual machine environments. Once transformed into IID reported in virtual machine environments. Once transformed into IID
format (with "u" = 1) these identifiers would purport to be format (with "u" = 1) these identifiers would purport to be
universally unique but would in fact be ambiguous. This has no known universally unique but would in fact be ambiguous. This has no known
harmful effect as long as the replicated MAC addresses and IIDs are harmful effect as long as the replicated MAC addresses and IIDs are
used on different layer 2 links. If they are used on the same link, used on different layer 2 links. If they are used on the same link,
of course there will be a problem, very likely interfering with link- of course there will be a problem, very likely interfering with link-
layer transmission. If not, the problem will be detected by layer transmission. If not, the problem will be detected by
duplicate address detection [RFC4862] [RFC6775], but such an error duplicate address detection [RFC4862] [RFC6775], but such an error
can usually only be resolved by human intervention. can usually only be resolved by human intervention.
skipping to change at page 8, line 32 skipping to change at page 8, line 27
This document requests no immediate action by IANA. However, the This document requests no immediate action by IANA. However, the
following should be noted when considering any future proposed following should be noted when considering any future proposed
addition to the registry of reserved IID values, which requires addition to the registry of reserved IID values, which requires
Standards Action according to [RFC5453]. Standards Action according to [RFC5453].
Full deployment of a new reserved IID value would require updates to Full deployment of a new reserved IID value would require updates to
IID generation code in every deployed IPv6 stack, so the technical IID generation code in every deployed IPv6 stack, so the technical
justification for such a Standards Action would need to be extremely justification for such a Standards Action would need to be extremely
strong. strong.
A reserved IID, or a range of reserved IIDs, will most likely specify
values for both "u" and "g", since they are among the high-order
bits. At the present time, none of the standard methods of
generating IIDs will generate "u" = "g" = 1. Reserved IIDs with "u"
= "g" = 1 are therefore unlikely to collide with automatically
generated IIDs.
8. Acknowledgements 8. Acknowledgements
Valuable comments were received from Ran Atkinson, Remi Despres, Valuable comments were received from Ran Atkinson, Remi Despres,
Ralph Droms, Fernando Gont, Brian Haberman, Joel Halpern, Bob Hinden, Ralph Droms, Fernando Gont, Eric Gray, Brian Haberman, Joel Halpern,
Christian Huitema, Ray Hunter, Tatuya Jinmei, Mark Smith, Bernie Volz Bob Hinden, Christian Huitema, Ray Hunter, Tatuya Jinmei, Mark Smith,
and other participants in the 6MAN working group. Bernie Volz and other participants in the 6MAN working group.
Brian Carpenter was a visitor at the Computer Laboratory, Cambridge Brian Carpenter was a visitor at the Computer Laboratory, Cambridge
University during part of this work. University during part of this work.
This document was produced using the xml2rfc tool [RFC2629]. This document was produced using the xml2rfc tool [RFC2629].
9. Change log [RFC Editor: Please remove] 9. Change log [RFC Editor: Please remove]
draft-ietf-6man-ug-04: corrected interpretation of 802.1, removed a
content-free paragraph, minor fixes, 2013-10-02.
draft-ietf-6man-ug-03: some clarifications, text on unpredictable draft-ietf-6man-ug-03: some clarifications, text on unpredictable
IIDs, minor corrections, 2013-08-26. IIDs, minor corrections, 2013-08-26.
draft-ietf-6man-ug-02: incorporated WG Last Call comments: removed draft-ietf-6man-ug-02: incorporated WG Last Call comments: removed
open issue, clarified IEEE bit names, clarified DAD text, updated open issue, clarified IEEE bit names, clarified DAD text, updated
references, minor editorial corrections, 2013-08-06. references, minor editorial corrections, 2013-08-06.
draft-ietf-6man-ug-01: emphasised "opaque" nature of IID, added text draft-ietf-6man-ug-01: emphasised "opaque" nature of IID, added text
about DAD failures, expanded IANA considerations, 2013-05-25. about DAD failures, expanded IANA considerations, 2013-05-25.
skipping to change at page 10, line 7 skipping to change at page 9, line 41
[RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", RFC [RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", RFC
5453, February 2009. 5453, February 2009.
10.2. Informative References 10.2. Informative References
[I-D.ietf-6man-stable-privacy-addresses] [I-D.ietf-6man-stable-privacy-addresses]
Gont, F., "A Method for Generating Semantically Opaque Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", draft-ietf-6man-stable- Autoconfiguration (SLAAC)", draft-ietf-6man-stable-
privacy-addresses-12 (work in progress), August 2013. privacy-addresses-13 (work in progress), September 2013.
[I-D.ietf-softwire-4rd] [I-D.ietf-softwire-4rd]
Despres, R., Jiang, S., Penno, R., Lee, Y., Chen, G., and Despres, R., Jiang, S., Penno, R., Lee, Y., Chen, G., and
M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless
Solution (4rd)", draft-ietf-softwire-4rd-06 (work in Solution (4rd)", draft-ietf-softwire-4rd-06 (work in
progress), July 2013. progress), July 2013.
[IEEE802] , "IEEE Standard for Local and Metropolitan Area Networks: [IEEE802] , "IEEE Standard for Local and Metropolitan Area Networks:
Overview and Architecture", IEEE Std 802-2001 (R2007) , Overview and Architecture", IEEE Std 802-2001 (R2007),
2007. 2007.
[RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast [RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast
Addresses", RFC 2526, March 1999. Addresses", RFC 2526, March 1999.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999. June 1999.
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
Multicast Addresses", RFC 3306, August 2002. Multicast Addresses", RFC 3306, August 2002.
 End of changes. 14 change blocks. 
29 lines changed or deleted 25 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/