doc: Add RFC documents

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]
+