summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5453.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5453.txt')
-rw-r--r--doc/rfc/rfc5453.txt339
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc5453.txt b/doc/rfc/rfc5453.txt
new file mode 100644
index 0000000..4c44e13
--- /dev/null
+++ b/doc/rfc/rfc5453.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group S. Krishnan
+Request for Comments: 5453 Ericsson
+Category: Standards Track February 2009
+
+
+ Reserved IPv6 Interface Identifiers
+
+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) 2009 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents (http://trustee.ietf.org/
+ license-info) in effect on the date of publication of this document.
+ Please review these documents carefully, as they describe your rights
+ and restrictions with respect to this document.
+
+Abstract
+
+ Interface identifiers in IPv6 unicast addresses are used to identify
+ interfaces on a link. They are required to be unique within a
+ subnet. Several RFCs have specified interface identifiers or
+ identifier ranges that have a special meaning attached to them. An
+ IPv6 node autoconfiguring an interface identifier in these ranges
+ will encounter unexpected consequences. Since there is no
+ centralized repository for such reserved identifiers, this document
+ aims to create one.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Krishnan Standards Track [Page 1]
+
+RFC 5453 Reserved IPv6 Interface Identifiers February 2009
+
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 1.1. Applicability ..............................................2
+ 1.2. Requirements Notation ......................................3
+ 2. Issues with Reusing Reserved Interface Identifiers ..............3
+ 2.1. Possible Solutions .........................................3
+ 3. IANA Considerations .............................................3
+ 4. Acknowledgements ................................................4
+ 5. Security Considerations .........................................4
+ 6. References ......................................................5
+ 6.1. Normative References .......................................5
+ 6.2. Informative References .....................................5
+ Appendix A. List of Potentially Affected RFCs ......................6
+
+1. Introduction
+
+ An IPv6 unicast address is composed of two parts: a subnet prefix and
+ an interface identifier (IID) that identifies a unique interface
+ within the subnet prefix. The structure of an IPv6 unicast address
+ is depicted in "IPv6 Addressing Architecture" [RFC4291] and is
+ replicated here for clarity.
+
+ | n bits | 128-n bits |
+ +-------------------------------+---------------------------------+
+ | subnet prefix | interface ID |
+ +-------------------------------+---------------------------------+
+
+ Figure 1: IPv6 Unicast Address Format
+
+ 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
+ constructed in Modified EUI-64 format [RFC4291]. Examples of
+ mechanisms that generate interface identifiers without a unique token
+ include Cryptographically Generated Addresses [RFC3972], Privacy
+ Addresses [RFC4941], Hash-Based Addresses [HBA], etc. Non-unique
+ interface identifiers can also be allocated using managed address
+ assignment mechanisms like DHCPv6 (Dynamic Host Configuration
+ Protocol for IPv6) [RFC3315].
+
+1.1. Applicability
+
+ This document applies only to interface identifiers that are formed
+ in the modified EUI-64 format as defined in Appendix A of [RFC4291].
+ All other types of interface identifiers are out of its scope.
+
+
+
+
+
+
+Krishnan Standards Track [Page 2]
+
+RFC 5453 Reserved IPv6 Interface Identifiers February 2009
+
+
+1.2. Requirements Notation
+
+ 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 [RFC2119].
+
+2. Issues with Reusing Reserved Interface Identifiers
+
+ Let us assume a node comes up with an interface identifier that has
+ been reserved for use in some other capacity, e.g., an IPv6 node that
+ uses temporary IPv6 addresses [RFC4941] comes up with an IID of
+ fdff:ffff:ffff:ffff. This node will receive requests from all nodes
+ that are requesting a service from a Mobile IPv6 home agent since the
+ above-mentioned interface identifier has been reserved in [RFC2526]
+ to serve as a MIPv6 home agent's anycast address. At best, this is
+ an annoyance to the node that came up with this address. At worst,
+ another node on the link would be denied service and may not look for
+ other methods of acquiring a home agent. Thus, such reserved
+ interface identifiers MUST NOT be used for autonomous
+ autoconfiguration or for managed address configuration.
+
+2.1. Possible Solutions
+
+ There are two possible ways to go about avoiding usage of these
+ reserved interface identifiers. One of them would be to add a
+ normative reference to each specification that reserves an interface
+ identifier. The other would be to create an IANA registry for such
+ interface identifiers. There are two disadvantages to the normative
+ reference approach. Firstly, this approach does not scale well
+ because the number of such specifications that would need to be
+ updated is large. Secondly, the maturity level of the document
+ reserving the IID might be lower than the one prohibited from using
+ it; this will cause a downward reference problem. Therefore, the
+ better solution is to create an IANA registry for this purpose.
+
+3. IANA Considerations
+
+ This document creates an IANA registry for reserved IPv6 interface
+ identifiers. Initial values for the reserved IPv6 interface
+ identifiers are given below.
+
+
+
+
+
+
+
+
+
+
+
+Krishnan Standards Track [Page 3]
+
+RFC 5453 Reserved IPv6 Interface Identifiers February 2009
+
+
+ +-----------------------------------------+-------------------------+
+ | Interface Identifier Range | Description |
+ +-----------------------------------------+-------------------------+
+ | 0000:0000:0000:0000 | Subnet-Router Anycast |
+ | | [RFC4291] |
+ | | |
+ | FDFF:FFFF:FFFF:FF80-FDFF:FFFF:FFFF:FFFF | Reserved Subnet Anycast |
+ | | Addresses[RFC2526] |
+ +-----------------------------------------+-------------------------+
+
+ Table 1: Current Assignments
+
+ It is possible that implementations might predate a specific
+ assignment from this registry and hence not be cognizant of the
+ reserved nature of the interface identifier. Hence, future
+ assignments from this registry are discouraged. Future assignments,
+ if any, are to be made through Standards Action [RFC5226].
+ Assignments consist of a single interface identifier or a range of
+ interface identifiers.
+
+ NOTE: The address :: (all zeros in the interface identifier field) is
+ used as the unspecified address and ::/0 is used as a default route
+ indicator, as specified in [RFC5156]. These uses do not conflict
+ with the reserved interface identifiers defined here, since the
+ reserved identifiers defined in this document are used for avoiding
+ conflicts with stateless address autoconfiguration that utilizes a
+ 64-bit prefix length.
+
+4. Acknowledgements
+
+ The author would like to thank Alain Durand, Alex Petrescu, Bernie
+ Volz, Bob Hinden, Christian Huitema, Fred Templin, Jordi Palet
+ Martinez, Pekka Savola, Remi Denis-Courmount, Tim Enos, Ed
+ Jankiewicz, Brian Carpenter, Alfred Hoenes, Jari Arkko, Pasi Eronen,
+ Tim Polk, Lars Eggert, Derek Atkins, and Robert Sparks for reviewing
+ this document and suggesting changes.
+
+5. Security Considerations
+
+ By utilizing one of the reserved interface identifiers, an IPv6 node
+ might receive requests that it is not authorized to receive.
+ Information that creates or updates a registration in this registry
+ needs to be authenticated and authorized by the IANA based on the
+ instructions set forth by [RFC5226].
+
+
+
+
+
+
+
+Krishnan Standards Track [Page 4]
+
+RFC 5453 Reserved IPv6 Interface Identifiers February 2009
+
+
+6. References
+
+6.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast
+ Addresses", RFC 2526, March 1999.
+
+ [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
+ Architecture", RFC 4291, February 2006.
+
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+ May 2008.
+
+6.2. Informative References
+
+ [HBA] Bagnulo, M., "Hash Based Addresses (HBA)", Work in
+ Progress, October 2006.
+
+ [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
+ C., and M. Carney, "Dynamic Host Configuration Protocol
+ for IPv6 (DHCPv6)", RFC 3315, July 2003.
+
+ [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
+ RFC 3972, March 2005.
+
+ [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
+ Extensions for Stateless Address Autoconfiguration in
+ IPv6", RFC 4941, September 2007.
+
+ [RFC5156] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156,
+ April 2008.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Krishnan Standards Track [Page 5]
+
+RFC 5453 Reserved IPv6 Interface Identifiers February 2009
+
+
+Appendix A. List of Potentially Affected RFCs
+
+ Implementations of the following RFCs need to be aware of the
+ reserved interface identifier ranges when they allocate new
+ addresses. Future revisions of these RFCs should ensure that this is
+ either already sufficiently clear or that the text is amended to take
+ this into account.
+
+ o RFC 2590 - Transmission of IPv6 Packets over Frame Relay Networks
+ Specification
+
+ o RFC 3315 - Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
+
+ o RFC 3972 - Cryptographically Generated Addresses (CGA)
+
+ o RFC 4489 - A Method for Generating Link-Scoped IPv6 Multicast
+ Addresses
+
+ o RFC 4862 - IPv6 Stateless Address Autoconfiguration
+
+ o RFC 4941 - Privacy Extensions for Stateless Address
+ Autoconfiguration in IPv6
+
+ o RFC 4982 - Support for Multiple Hash Algorithms in
+ Cryptographically Generated Addresses (CGAs)
+
+ o RFC 5072 - IP Version 6 over PPP
+
+Author's Address
+
+ Suresh Krishnan
+ Ericsson
+ 8400 Decarie Blvd.
+ Town of Mount Royal, QC
+ Canada
+
+ Phone: +1 514 345 7900 x42871
+ EMail: suresh.krishnan@ericsson.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+Krishnan Standards Track [Page 6]
+