draft-ietf-6man-ug-05.txt   draft-ietf-6man-ug-06.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: May 18, 2014 November 14, 2013 Expires: June 5, 2014 December 2, 2013
Significance of IPv6 Interface Identifiers Significance of IPv6 Interface Identifiers
draft-ietf-6man-ug-05 draft-ietf-6man-ug-06
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
meaning and that the entire identifier should be treated as an opaque meaning and that the entire identifier should be treated as an 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
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 May 18, 2014. This Internet-Draft will expire on June 5, 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 20 skipping to change at page 2, line 20
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 . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
skipping to change at page 3, line 41 skipping to change at page 3, line 41
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Problem statement 2. Problem statement
In addition to IIDs formed from IEEE EUI-64 addresses, various new In addition to IIDs formed from IEEE EUI-64 addresses, various new
forms of IID have been defined, including temporary addresses forms of IID have been defined, including temporary addresses
[RFC4941], Cryptographically Generated Addresses (CGAs) [RFC3972], [RFC4941], Cryptographically Generated Addresses (CGAs) [RFC3972]
Hash-Based Addresses (HBAs) [RFC5535], and ISATAP addresses [RFC4982], Hash-Based Addresses (HBAs) [RFC5535], and ISATAP
[RFC5214]. Other methods have been proposed, such as stable privacy addresses [RFC5214]. Other methods have been proposed, such as
addresses [I-D.ietf-6man-stable-privacy-addresses], and mapped stable privacy addresses [I-D.ietf-6man-stable-privacy-addresses],
addresses for 4rd [I-D.ietf-softwire-4rd]. In each case, the and mapped addresses for 4rd [I-D.ietf-softwire-4rd]. In each case,
question of how to set the "u" and "g" bits has to be decided. For the question of how to set the "u" and "g" bits has to be decided.
example, RFC 3972 specifies that they are both zero in CGAs, and the For example, RFC 3972 specifies that they are both zero in CGAs, and
same applies to HBAs. On the other hand, RFC 4941 specifies that "u" RFC 4982 describes them as if they were reserved bits. The same
must be zero but leaves "g" variable. The NAT64 addressing format applies to HBAs. On the other hand, RFC 4941 specifies that "u" must
be zero but leaves "g" variable. The NAT64 addressing format
[RFC6052] sets the whole byte containing "u" and "g" to zero. [RFC6052] sets the whole byte containing "u" and "g" to zero.
Another case where the "u" and "g" bits are specified is in the Another case where the "u" and "g" bits are specified is in the
Reserved IPv6 Subnet Anycast Address format [RFC2526], which states Reserved IPv6 Subnet Anycast Address format [RFC2526], which states
that "for interface identifiers in EUI-64 format, the universal/local that "for interface identifiers in EUI-64 format, the universal/local
bit in the interface identifier MUST be set to 0" (i.e., local) and bit in the interface identifier MUST be set to 0" (i.e., local) and
requires that "g" bit to be set to 1. However, the text neither requires that "g" bit to be set to 1. However, the text neither
states nor implies any semantics for these bits in anycast addresses. states nor implies any semantics for these bits in anycast addresses.
A common operational practice for well-known servers is to manually A common operational practice for well-known servers is to manually
skipping to change at page 8, line 27 skipping to change at page 8, line 19
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.
The preceding sentence and a reference to this document should be
added to the Reserved IPv6 Interface Identifiers registry.
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, Eric Gray, Brian Haberman, Joel Halpern, Ralph Droms, Fernando Gont, Eric Gray, Brian Haberman, Joel Halpern,
Bob Hinden, Christian Huitema, Ray Hunter, Tatuya Jinmei, Mark Smith, Bob Hinden, Christian Huitema, Ray Hunter, Tatuya Jinmei, Roger
Bernie Volz and other participants in the 6MAN working group. Jorgensen, Mark Smith, 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-06: IETF Last Call comments - clarifications,
2013-12-02.
draft-ietf-6man-ug-05: AD comments - clarifications, 2013-11-14. 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
skipping to change at page 10, line 28 skipping to change at page 10, line 28
[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast
Addresses", RFC 3307, August 2002. Addresses", RFC 3307, August 2002.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005. RFC 3972, March 2005.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007. IPv6", RFC 4941, September 2007.
[RFC4982] Bagnulo, M. and J. Arkko, "Support for Multiple Hash
Algorithms in Cryptographically Generated Addresses
(CGAs)", RFC 4982, July 2007.
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
March 2008. March 2008.
[RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, June [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, June
2009. 2009.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010. October 2010.
 End of changes. 9 change blocks. 
15 lines changed or deleted 27 lines changed or added

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