doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

diff --git a/doc/rfc/rfc6747.txt b/doc/rfc/rfc6747.txt
new file mode 100644
index 0000000..1f43232
--- /dev/null
+++ b/doc/rfc/rfc6747.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Internet Research Task Force (IRTF)                          RJ Atkinson
+Request for Comments: 6747                                    Consultant
+Category: Experimental                                         SN Bhatti
+ISSN: 2070-1721                                            U. St Andrews
+                                                           November 2012
+
+
+                   Address Resolution Protocol (ARP)
+     for the Identifier-Locator Network Protocol for IPv4 (ILNPv4)
+
+Abstract
+
+   This document defines an Address Resolution Protocol (ARP) extension
+   to support the Identifier-Locator Network Protocol for IPv4 (ILNPv4).
+   ILNP is an experimental, evolutionary enhancement to IP.  This
+   document is a product of the IRTF Routing Research Group.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for examination, experimental implementation, and
+   evaluation.
+
+   This document defines an Experimental Protocol for the Internet
+   community.  This document is a product of the Internet Research Task
+   Force (IRTF).  The IRTF publishes the results of Internet-related
+   research and development activities.  These results might not be
+   suitable for deployment.  This RFC represents the individual
+   opinion(s) of one or more members of the Routing Research Group of
+   the Internet Research Task Force (IRTF).  Documents approved for
+   publication by the IRSG are not a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6747.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Atkinson & Bhatti             Experimental                      [Page 1]
+
+RFC 6747                       ILNPv4 ARP                  November 2012
+
+
+Copyright Notice
+
+   Copyright (c) 2012 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.
+
+   This document may not be modified, and derivative works of it may not
+   be created, except to format it for publication as an RFC or to
+   translate it into languages other than English.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. ILNP Document Roadmap ......................................3
+      1.2. Terminology ................................................5
+   2. ARP Extensions for ILNPv4 .......................................5
+      2.1. ILNPv4 ARP Request Packet Format ...........................5
+      2.2. ILNPv4 ARP Reply Packet Format .............................7
+      2.3. Operation and Implementation of ARP for ILNPv4 .............8
+   3. Security Considerations .........................................9
+   4. IANA Considerations .............................................9
+   5. References .....................................................10
+      5.1. Normative References ......................................10
+      5.2. Informative References ....................................11
+   6. Acknowledgements ...............................................11
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Atkinson & Bhatti             Experimental                      [Page 2]
+
+RFC 6747                       ILNPv4 ARP                  November 2012
+
+
+1.  Introduction
+
+   This document is part of the ILNP document set, which has had
+   extensive review within the IRTF Routing RG.  ILNP
+   is one of the recommendations made by the RG Chairs.  Separately,
+   various refereed research papers on ILNP have also been published
+   during this decade.  So, the ideas contained herein have had much
+   broader review than the IRTF Routing RG.  The views in this
+   document were considered controversial by the Routing RG, but the
+   RG reached a consensus that the document still should be
+   published.  The Routing RG has had remarkably little consensus on
+   anything, so virtually all Routing RG outputs are considered
+   controversial.
+
+   At present, the Internet research and development community are
+   exploring various approaches to evolving the Internet
+   Architecture to solve a variety of issues including, but not
+   limited to, scalability of inter-domain routing [RFC4984].  A wide
+   range of other issues (e.g., site multihoming, node multihoming,
+   site/subnet mobility, node mobility) are also active concerns at
+   present.  Several different classes of evolution are being
+   considered by the Internet research and development community.  One
+   class is often called "Map and Encapsulate", where traffic would
+   be mapped and then tunnelled through the inter-domain core of the
+   Internet.  Another class being considered is sometimes known as
+   "Identifier/Locator Split".  This document relates to a proposal
+   that is in the latter class of evolutionary approaches.
+
+   The Identifier Locator Network Protocol (ILNP) is a proposal for
+   evolving the Internet Architecture.  It differs from the current
+   Internet Architecture primarily by deprecating the concept of an
+   IP Address, and instead defining two new objects, each having
+   crisp syntax and semantics.  The first new object is the Locator, a
+   topology-dependent name for a subnetwork.  The other new object is
+   the Identifier, which provides a topology-independent name for a
+   node.
+
+1.1.  ILNP Document Roadmap
+
+   This document describes extensions to ARP for use with
+   ILNPv4.
+
+   The ILNP architecture can have more than one engineering
+   instantiation.  For example, one can imagine a "clean-slate"
+   engineering design based on the ILNP architecture.  In separate
+   documents, we describe two specific engineering instances of
+   ILNP.  The term ILNPv6 refers precisely to an instance of ILNP that
+
+
+
+
+Atkinson & Bhatti             Experimental                      [Page 3]
+
+RFC 6747                       ILNPv4 ARP                  November 2012
+
+
+   is based upon, and backwards compatible with, IPv6.  The term ILNPv4
+   refers precisely to an instance of ILNP that is based upon, and
+   backwards compatible with, IPv4.
+
+   Many engineering aspects common to both ILNPv4 and ILNPv6 are
+   described in [RFC6741].  A full engineering specification for
+   either ILNPv6 or ILNPv4 is beyond the scope of this document.
+
+   Readers are referred to other related ILNP documents for details
+   not described here:
+
+      a) [RFC6740] is the main architectural description of ILNP,
+         including the concept of operations.
+
+      b) [RFC6741] describes engineering and implementation
+         considerations that are common to both ILNPv4 and ILNPv6.
+
+      c) [RFC6742] defines additional DNS resource records that
+         support ILNP.
+
+      d) [RFC6743] defines a new ICMPv6 Locator Update message
+         used by an ILNP node to inform its correspondent nodes
+         of any changes to its set of valid Locators.
+
+      e) [RFC6744] defines a new IPv6 Nonce Destination Option
+         used by ILNPv6 nodes (1) to indicate to ILNP correspondent
+         nodes (by inclusion within the initial packets of an ILNP
+         session) that the node is operating in the ILNP mode and
+         (2) to prevent off-path attacks against ILNP ICMP messages.
+         This Nonce is used, for example, with all ILNP ICMPv6
+         Locator Update messages that are exchanged among ILNP
+         correspondent nodes.
+
+      f) [RFC6745] defines a new ICMPv4 Locator Update message
+         used by an ILNP node to inform its correspondent nodes
+         of any changes to its set of valid Locators.
+
+      g) [RFC6746] defines a new IPv4 Nonce Option used by ILNPv4
+         nodes to carry a security nonce to prevent off-path attacks
+         against ILNP ICMP messages and also defines a new IPv4
+         Identifier Option used by ILNPv4 nodes.
+
+      h) [RFC6748] describes optional engineering and deployment
+         functions for ILNP.  These are not required for the operation
+         or use of ILNP and are provided as additional options.
+
+
+
+
+
+
+Atkinson & Bhatti             Experimental                      [Page 4]
+
+RFC 6747                       ILNPv4 ARP                  November 2012
+
+
+1.2.  Terminology
+
+   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.  ARP Extensions for ILNPv4
+
+   ILNP for IPv4 (ILNPv4) is merely a different instantiation of the
+   ILNP architecture, so it retains the crisp distinction between the
+   Locator and the Identifier.  As with ILNPv6, only the Locator
+   values are used for routing and forwarding ILNPv4 packets
+   [RFC6740].  As with ILNP for IPv6 (ILNPv6), when ILNPv4 is used
+   for a network-layer session, the upper-layer protocols (e.g.,
+   TCP/UDP pseudo-header checksum, IPsec Security Association) bind
+   only to the Identifiers, never to the Locators [RFC6741].
+
+   However, just as the packet format for IPv4 is different to IPv6,
+   so the engineering details for ILNPv4 are different also.  While
+   ILNPv6 is carefully engineered to be fully backwards-compatible
+   with IPv6 Neighbor Discovery, ILNPv4 relies upon an extended
+   version of the Address Resolution Protocol (ARP) [RFC826], which
+   is defined here.  While ILNPv4 could have been engineered to avoid
+   changes in ARP, that would have required that the ILNPv4 Locator
+   (i.e., L32) have slightly different semantics, which was
+   architecturally undesirable.
+
+   The packet formats used are direct extensions of the existing
+   widely deployed ARP Request (OP code 1) and ARP Reply (OP code 2)
+   packet formats.  This design was chosen for practical engineering
+   reasons (i.e., to maximise code reuse), rather than for maximum
+   protocol design purity.
+
+   We anticipate that ILNPv6 is much more likely to be widely
+   implemented and deployed than ILNPv4.  However, having a clear
+   definition of ILNPv4 helps demonstrate the difference between
+   architecture and engineering, and also demonstrates that the
+   common ILNP architecture can be instantiated in different ways
+   with different existing network-layer protocols.
+
+2.1.  ILNPv4 ARP Request Packet Format
+
+   The ILNPv4 ARP Request is an extended version of the widely
+   deployed ARP Request (OP code 1).  For experimentation purposes,
+   the ILNPv4 ARP Request OP code uses decimal value 24.  It is
+   important to note that decimal value 24 is a pre-defined,
+   shared-use experimental OP code for ARP [RFC5494], and is not
+
+
+
+Atkinson & Bhatti             Experimental                      [Page 5]
+
+RFC 6747                       ILNPv4 ARP                  November 2012
+
+
+   uniquely assigned to ILNPv4 ARP Requests.  The ILNPv4 ARP Request
+   extension permits the Node Identifier (NID) values to be carried
+   in the ARP message, in addition to the node's 32-bit Locator
+   (L32) values [RFC6742].
+
+        0        7        15       23       31
+        +--------+--------+--------+--------+
+        |       HT        |        PT       |
+        +--------+--------+--------+--------+
+        |  HAL   |  PAL   |        OP       |
+        +--------+--------+--------+--------+
+        |         S_HA (bytes 0-3)          |
+        +--------+--------+--------+--------+
+        | S_HA (bytes 4-5)|S_L32 (bytes 0-1)|
+        +--------+--------+--------+--------+
+        |S_L32 (bytes 2-3)|S_NID (bytes 0-1)|
+        +--------+--------+--------+--------+
+        |         S_NID (bytes 2-5)         |
+        +--------+--------+--------+--------+
+        |S_NID (bytes 6-7)| T_HA (bytes 0-1)|
+        +--------+--------+--------+--------+
+        |         T_HA (bytes 3-5)          |
+        +--------+--------+--------+--------+
+        |         T_L32 (bytes 0-3)         |
+        +--------+--------+--------+--------+
+        |         T_NID (bytes 0-3)         |
+        +--------+--------+--------+--------+
+        |         T_NID (bytes 4-7)         |
+        +--------+--------+--------+--------+
+
+    Figure 2.1: ILNPv4 ARP Request packet format
+
+   In Figure 2.1, the fields are as follows:
+
+     HT      Hardware Type (*)
+     PT      Protocol Type (*)
+     HAL     Hardware Address Length (*)
+     PAL     Protocol Address Length (uses new value 12)
+     OP      Operation Code (uses experimental value OP_EXP1=24)
+     S_HA    Sender Hardware Address (*)
+     S_L32   Sender L32  (* same as Sender IPv4 address for ARP)
+     S_NID   Sender Node Identifier (8 bytes)
+     T_HA    Target Hardware Address (*)
+     T_L32   Target L32  (* same as Target IPv4 address for ARP)
+     T_NID   Target Node Identifier (8 bytes)
+
+
+
+
+
+
+Atkinson & Bhatti             Experimental                      [Page 6]
+
+RFC 6747                       ILNPv4 ARP                  November 2012
+
+
+   The changed OP code indicates that this is ILNPv4 and not IPv4.  The
+   semantics and usage of the ILNPv4 ARP Request are identical to the
+   existing ARP Request (OP code 2), except that the ILNPv4 ARP Request
+   is sent only by nodes that support ILNPv4.
+
+   The field descriptions marked with "*" should have the same values as
+   for ARP as used for IPv4.
+
+2.2.  ILNPv4 ARP Reply Packet Format
+
+   The ILNPv4 ARP Reply is an extended version of the widely deployed
+   ARP Reply (OP code 2).  For experimentation purposes, the ILNPv4 ARP
+   Request OP code uses decimal value 25.  It is important to note that
+   decimal value 25 is a pre-defined, shared-use experimental OP code
+   for ARP [RFC5494], and is not uniquely assigned to ILNPv4 ARP
+   Requests.  The ILNPv4 ARP Reply extension permits the Node Identifier
+   (NID) values to be carried in the ARP message, in addition to the
+   node's 32-bit Locator (L32) values [RFC6742].
+
+        0        7        15       23       31
+        +--------+--------+--------+--------+
+        |       HT        |        PT       |
+        +--------+--------+--------+--------+
+        |  HAL   |  PAL   |        OP       |
+        +--------+--------+--------+--------+
+        |         S_HA (bytes 0-3)          |
+        +--------+--------+--------+--------+
+        | S_HA (bytes 4-5)|S_L32 (bytes 0-1)|
+        +--------+--------+--------+--------+
+        |S_L32 (bytes 2-3)|S_NID (bytes 0-1)|
+        +--------+--------+--------+--------+
+        |         S_NID (bytes 2-5)         |
+        +--------+--------+--------+--------+
+        |S_NID (bytes 6-7)| T_HA (bytes 0-1)|
+        +--------+--------+--------+--------+
+        |         T_HA (bytes 3-5)          |
+        +--------+--------+--------+--------+
+        |         T_L32 (bytes 0-3)         |
+        +--------+--------+--------+--------+
+        |         T_NID (bytes 0-3)         |
+        +--------+--------+--------+--------+
+        |         T_NID (bytes 4-7)         |
+        +--------+--------+--------+--------+
+
+    Figure 2.2: ILNPv4 ARP Reply packet format
+
+
+
+
+
+
+Atkinson & Bhatti             Experimental                      [Page 7]
+
+RFC 6747                       ILNPv4 ARP                  November 2012
+
+
+   In Figure 2.2, the fields are as follows:
+
+     HT      Hardware Type (*)
+     PT      Protocol Type (*)
+     HAL     Hardware Address Length (*)
+     PAL     Protocol Address Length (uses new value 12)
+     OP      Operation Code (uses experimental value OP_EXP2=25)
+     S_HA    Sender Hardware Address (*)
+     S_L32   Sender L32  (* same as Sender IPv4 address for ARP)
+     S_NID   Sender Node Identifier (8 bytes)
+     T_HA    Target Hardware Address (*)
+     T_L32   Target L32  (* same as Target IPv4 address for ARP)
+     T_NID   Target Node Identifier (8 bytes)
+
+   The changed OP code indicates that this is ILNPv4 and not IPv4.  The
+   semantics and usage of the ILNPv4 ARP Reply are identical to the
+   existing ARP Reply (OP code 2), except that the ILNPv4 ARP Reply is
+   sent only by nodes that support ILNPv4.
+
+   The field descriptions marked with "*" should have the same values as
+   for ARP as used for IPv4.
+
+2.3.  Operation and Implementation of ARP for ILNPv4
+
+   The operation of ARP for ILNPv4 is almost identical to that for IPv4.
+   Essentially, the key differences are:
+
+      a) where an IPv4 ARP Request would use IPv4 addresses, an ILNPv4
+         ARP Request MUST use:
+         1. a 32-bit L32 value (_L32 suffixes in Figures 2.1 and 2.2)
+         2. a 64-bit NID value (_NID suffixes in Figures 2.1 and 2.2)
+
+      b) where an IPv4 ARP Reply would use IPv4 addresses, an ILNPv4 ARP
+         Reply MUST use:
+         1. a 32-bit L32 value (_L32 suffixes in Figures 2.1 and 2.2)
+         2. a 64-bit NID value (_NID suffixes in Figures 2.1 and 2.2)
+
+   As the OP codes 24 and 25 are distinct from ARP for IPv4, but the
+   packet formats in Figures 2.1 and 2.2 are, effectively, extended
+   versions of the corresponding ARP packets.  It should be possible to
+   implement this extension of ARP by extending existing ARP
+   implementations rather than having to write an entirely new
+   implementation for ILNPv4.  It should be emphasised, however, that OP
+   codes 24 and 25 are for experimental use as defined in [RFC5494], and
+   so it is possible that other experimental protocols could be using
+   these OP codes concurrently.
+
+
+
+
+
+Atkinson & Bhatti             Experimental                      [Page 8]
+
+RFC 6747                       ILNPv4 ARP                  November 2012
+
+
+3.  Security Considerations
+
+   Security considerations for the overall ILNP architecture are
+   described in [RFC6740].  Additional common security considerations
+   applicable to ILNP are described in [RFC6741].  This section
+   describes security considerations specific to the specific ILNPv4
+   topics discussed in this document.
+
+   The existing widely deployed Address Resolution Protocol (ARP) for
+   IPv4 is a link-layer protocol, so it is not vulnerable to off-link
+   attackers.  In this way, it is a bit different than IPv6 Neighbor
+   Discovery (ND); IPv6 ND is a subset of the Internet Control Message
+   Protocol (ICMP), which runs over IPv6.
+
+   However, ARP does not include any form of authentication, so current
+   ARP deployments are vulnerable to a range of attacks from on-link
+   nodes.  For example, it is possible for one node on a link to forge
+   an ARP packet claiming to be from another node, thereby "stealing"
+   the other node's IPv4 address.  [RFC5227] describes several of these
+   risks and some measures that an ARP implementation can use to reduce
+   the chance of accidental IPv4 address misconfiguration and also to
+   detect such misconfiguration if it should occur.
+
+   This extension does not change the security risks that are inherent
+   in using ARP.
+
+   In situations where additional protection against on-link attackers
+   is needed (for example, within high-risk operational environments),
+   the IEEE standards for link-layer security [IEEE-802.1-AE] SHOULD be
+   implemented and deployed.
+
+   Implementers of this specification need to understand that the two OP
+   code values used for these 2 extensions are not uniquely assigned to
+   ILNPv4.  Other experimenters might be using the same two OP code
+   values at the same time for different ARP-related experiments.
+   Absent prior coordination among all users of a particular IP
+   subnetwork, different experiments might be occurring on the same IP
+   subnetwork.  So, implementations of these two ARP extensions ought to
+   be especially defensively coded.
+
+4.  IANA Considerations
+
+   This document makes no request of IANA.
+
+   If in the future the IETF decided to standardise ILNPv4, then
+   allocation of unique ARP OP codes for the two extensions above would
+   be sensible as part of the IETF standardisation process.
+
+
+
+
+Atkinson & Bhatti             Experimental                      [Page 9]
+
+RFC 6747                       ILNPv4 ARP                  November 2012
+
+
+5.  References
+
+5.1.  Normative References
+
+   [IEEE-802.1-AE] IEEE, "Media Access Control (MAC) Security", IEEE
+                   Standard 802.1 AE, 18 August 2006, IEEE, New York,
+                   NY, 10016, USA.
+
+   [RFC826]        Plummer, D., "Ethernet Address Resolution Protocol:
+                   Or Converting Network Protocol Addresses to 48.bit
+                   Ethernet Address for Transmission on Ethernet
+                   Hardware", STD 37, RFC 826, November 1982.
+
+   [RFC2119]       Bradner, S., "Key words for use in RFCs to Indicate
+                   Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC5227]       Cheshire, S., "IPv4 Address Conflict Detection", RFC
+                   5227, July 2008.
+
+   [RFC5494]       Arkko, J. and C. Pignataro, "IANA Allocation
+                   Guidelines for the Address Resolution Protocol
+                   (ARP)", RFC 5494, April 2009.
+
+   [RFC6740]       Atkinson, R. and S. Bhatti, "Identifier Locator
+                   Network Protocol (ILNP) Architectural Description",
+                   RFC 6740, November 2012.
+
+   [RFC6741]       Atkinson, R. and S. Bhatti, "Identifier-Locator
+                   Network Protocol (ILNP) Engineering and
+                   Implementation Considerations", RFC 6741, November
+                   2012.
+
+   [RFC6742]       Atkinson, R., Bhatti, S., and S. Rose, "DNS Resource
+                   Records for the Identifier-Locator Network Protocol
+                   (ILNP)", RFC 6742, November 2012.
+
+   [RFC6745]       Atkinson, R. and S. Bhatti,  "ICMP Locator Update
+                   Message for the Identifier-Locator Network Protocol
+                   for IPv4 (ILNPv4)", RFC 6745, November 2012.
+
+   [RFC6746]       Atkinson, R. and S.Bhatti, "IPv4 Options for the
+                   Identifier-Locator Network Protocol (ILNP)", RFC
+                   6746, November 2012.
+
+
+
+
+
+
+
+
+Atkinson & Bhatti             Experimental                     [Page 10]
+
+RFC 6747                       ILNPv4 ARP                  November 2012
+
+
+5.2.  Informative References
+
+   [RFC4984]       Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed.,
+                   "Report from the IAB Workshop on Routing and
+                   Addressing", RFC 4984, September 2007.
+
+   [RFC6743]       Atkinson, R. and S. Bhatti, "ICMPv6 Locator Update
+                   Message", RFC 6743, November 2012.
+
+   [RFC6744]       Atkinson, R. and S. Bhatti, "IPv6 Nonce Destination
+                   Option for the Identifier-Locator Network Protocol
+                   for IPv6 (ILNPv6)", RFC 6744, November 2012.
+
+   [RFC6748]       Atkinson, R. and S. Bhatti, "Optional Advanced
+                   Deployment Scenarios for the Identifier-Locator
+                   Network Protocol (ILNP)", RFC 6748, November 2012.
+
+6.  Acknowledgements
+
+   Steve Blake, Stephane Bortzmeyer, Mohamed Boucadair, Noel Chiappa,
+   Wes George, Steve Hailes, Joel Halpern, Mark Handley, Volker Hilt,
+   Paul Jakma, Dae-Young Kim, Tony Li, Yakov Rehkter, Bruce Simpson,
+   Robin Whittle, and John Wroclawski (in alphabetical order) provided
+   review and feedback on earlier versions of this document.  Steve
+   Blake provided an especially thorough review of an early version of
+   the entire ILNP document set, which was extremely helpful.  We also
+   wish to thank the anonymous reviewers of the various ILNP papers for
+   their feedback.
+
+   Roy Arends provided expert guidance on technical and procedural
+   aspects of DNS issues.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Atkinson & Bhatti             Experimental                     [Page 11]
+
+RFC 6747                       ILNPv4 ARP                  November 2012
+
+
+Authors' Addresses
+
+   RJ Atkinson
+   Consultant
+   San Jose, CA,
+   95125 USA
+
+   EMail: rja.lists@gmail.com
+
+
+   SN Bhatti
+   School of Computer Science
+   University of St Andrews
+   North Haugh, St Andrews,
+   Fife  KY16 9SX
+   Scotland, UK
+
+   EMail: saleem@cs.st-andrews.ac.uk
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Atkinson & Bhatti             Experimental                     [Page 12]
+