< draft-ietf-6man-ug-04.txt   draft-ietf-6man-ug-05.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: April 04, 2014 October 01, 2013 Expires: May 18, 2014 November 14, 2013
Significance of IPv6 Interface Identifiers Significance of IPv6 Interface Identifiers
draft-ietf-6man-ug-04 draft-ietf-6man-ug-05
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 meaning and that the entire identifier should be treated as an opaque
opaque value. In particular, RFC 4291 defines a method by which the 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
into an IPv6 unicast interface identifier. This document clarifies into an IPv6 unicast interface identifier. This document clarifies
that those two bits are significant only in interface identifiers that those two bits are significant only in the process of deriving
that are derived from an IEEE link-layer address, and updates RFC interface identifiers from an IEEE link-layer address, and updates
4291 accordingly. RFC 4291 accordingly.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 April 04, 2014. This Internet-Draft will expire on May 18, 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 27 skipping to change at page 2, line 27
3. Usefulness of the U and G Bits . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . 6 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] . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
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 an IPv6 address that is reached by routing to that prefix, giving an IPv6 address that is
unique within the applicable scope (link local or global). According unique within the applicable scope (link local or global). According
to the IPv6 addressing architecture [RFC4291], when a 64-bit IPv6 to the IPv6 addressing architecture [RFC4291], when a 64-bit IPv6
unicast IID is formed on the basis of an IEEE EUI-64 address, usually unicast IID is formed on the basis of an IEEE EUI-64 address, usually
itself expanded from a 48-bit MAC address, a particular format must itself expanded from a 48-bit MAC address, a particular format must
skipping to change at page 3, line 10 skipping to change at page 3, line 10
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
particular bits in the MAC address: particular bits in the MAC address:
o The "u/l" bit in a MAC address [IEEE802] is set to 0 to indicate o The "u/l" bit in a MAC address [IEEE802] is set to 0 to indicate
universal scope (implying uniqueness) or to 1 to indicate local universal scope (implying uniqueness) or to 1 to indicate local
scope (without implying uniqueness). In an IID formed from a MAC scope (without implying uniqueness). In an IID formed from a MAC
address, this bit is simply known as the "u" bit and its value is address, this bit is simply known as the "u" bit and its value is
inverted, i.e., 1 for universal scope and 0 for local scope. inverted, i.e., 1 for universal scope and 0 for local scope.
According to RFC 4291 and [RFC5342], the reason for this was to According to RFC 4291 and [RFC7042], the reason for this was to
make it easier for network operators to manually configure local- make it easier for network operators to manually configure local-
scope IIDs. scope IIDs.
In an IID, this bit is in position 6, i.e., position 70 in the In an IID, this bit is in position 6, i.e., position 70 in the
complete IPv6 address. complete IPv6 address.
o The "i/g" bit in a MAC address is set to 1 to indicate group o The "i/g" bit in a MAC address is set to 1 to indicate group
addressing (link-layer multicast). The value of this bit is addressing (link-layer multicast). The value of this bit is
preserved in an IID, where it is known as the "g" bit. preserved in an IID, where it is known as the "g" bit.
skipping to change at page 4, line 30 skipping to change at page 4, line 30
that have nothing to do with EUI-64. that have nothing to do with EUI-64.
A particular case is that of /127 prefixes for point-to-point links A particular case is that of /127 prefixes for point-to-point links
between routers, as standardised by [RFC6164]. The addresses on between routers, as standardised by [RFC6164]. The addresses on
these links are undoubtedly global unicast addresses, but they do not these links are undoubtedly global unicast addresses, but they do not
have a 64-bit IID. The bits in the positions named "u" and "g" in have a 64-bit IID. The bits in the positions named "u" and "g" in
such an IID have no special significance and their values are not such an IID have no special significance and their values are not
specified. specified.
Each time a new IID format is proposed, the question arises whether Each time a new IID format is proposed, the question arises whether
these bits have any meaning. Section 2.2.1 of RFC 5342 discusses the these bits have any meaning. Section 2.2.1 of RFC 7042 discusses the
mechanics of the bit allocations but does not explain the purpose or mechanics of the bit allocations but does not explain the purpose or
usefulness of these bits in an IID. There is an IANA registry for usefulness of these bits in an IID. There is an IANA registry for
reserved IID values [RFC5453] but again there is no explanation of reserved IID values [RFC5453] but again there is no explanation of
the purpose of the "u" and "g" bits. the purpose of the "u" and "g" bits.
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:
skipping to change at page 7, line 14 skipping to change at page 7, line 14
This section describes clarifications to the IPv6 specifications that This section describes clarifications to the IPv6 specifications that
result from the above discussion. Their aim is to reduce confusion result from the above discussion. Their aim is to reduce confusion
while retaining the useful aspects of the "u" and "g" bits in IIDs. while retaining the useful aspects of the "u" and "g" bits in IIDs.
The EUI-64 to IID transformation defined in the IPv6 addressing The EUI-64 to IID transformation defined in the IPv6 addressing
architecture [RFC4291] MUST be used for all cases where an IPv6 IID architecture [RFC4291] MUST be used for all cases where an IPv6 IID
is derived from an IEEE MAC or EUI-64 address. With any other form is derived from an IEEE MAC or EUI-64 address. With any other form
of link layer address, an equivalent transformation SHOULD be used. of link layer address, an equivalent transformation SHOULD be used.
Specifications of other forms of 64-bit IID MUST specify how all 64 Specifications of other forms of 64-bit IID MUST specify how all 64
bits are set, but need not treat the "u" and "g" bits in any special bits are set, but a generic semantic meaning for the "u" and "g" bits
way. A generic semantic meaning for these bits MUST NOT be defined. MUST NOT be defined. However, the method of generating IIDs for
However, the method of generating IIDs for specific link types MAY specific link types MAY define some local significance for certain
define some local significance for certain bits. bits.
In all cases, the bits in an IID have no generic semantics; in other In all cases, the bits in an IID have no generic semantics; in other
words, they have opaque values. In fact, the whole IID value MUST be words, they have opaque values. In fact, the whole IID value MUST be
viewed as an opaque bit string by third parties, except possibly in viewed as an opaque bit string by third parties, except possibly in
the local context. the local context.
The following statement in section 2.5.1 of the IPv6 addressing The following statement in section 2.5.1 of the IPv6 addressing
architecture [RFC4291]: architecture [RFC4291]:
"For all unicast addresses, except those that start with the binary "For all unicast addresses, except those that start with the binary
skipping to change at page 8, line 41 skipping to change at page 8, line 41
Bob Hinden, Christian Huitema, Ray Hunter, Tatuya Jinmei, Mark Smith, Bob Hinden, Christian Huitema, Ray Hunter, Tatuya Jinmei, Mark Smith,
Bernie Volz 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-05: AD comments - clarifications, 2013-11-14.
draft-ietf-6man-ug-04: corrected interpretation of 802.1, removed a draft-ietf-6man-ug-04: corrected interpretation of 802.1, removed a
content-free paragraph, minor fixes, 2013-10-02. 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.
skipping to change at page 9, line 28 skipping to change at page 9, line 31
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
[RFC5342] Eastlake, D., "IANA Considerations and IETF Protocol Usage
for IEEE 802 Parameters", BCP 141, RFC 5342, September
2008.
[RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", RFC [RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", RFC
5453, February 2009. 5453, February 2009.
[RFC7042] Eastlake, D. and J. Abley, "IANA Considerations and IETF
Protocol and Documentation Usage for IEEE 802 Parameters",
BCP 141, RFC 7042, October 2013.
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-13 (work in progress), September 2013. privacy-addresses-14 (work in progress), October 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-07 (work in
progress), July 2013. progress), October 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.
 End of changes. 14 change blocks. 
22 lines changed or deleted 24 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/