Internet Draft RJ Atkinson draft-irtf-rrg-ilnp-eng-00.txt Consultant Expires: 09 JUL 2012 SN Bhatti Category: Experimental U. St Andrews 9 January 2012 ILNP Engineering Considerations draft-irtf-rrg-ilnp-eng-00.txt Status of this Memo Distribution of this memo is unlimited. 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other Atkinson & Bhatti Expires in 6 months [Page 1] Internet Draft ILNP Eng 09 JUL 2012 documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This document is not on the IETF standards-track and does not specify any level of standard. This document merely provides information for the Internet community. The ILNP document set has had extensive review within the IRTF Routing Research Group. 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 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. Abstract This document describes common (i.e. version independent) engineering details for the Identifier-Locator Network Protocol (ILNP), which is an experimental, evolutionary enhancement to IP. This document is a product of the IRTF Routing RG. Table of Contents 1. Introduction ..........................................2 2. Generating Identifiers.................................3 3. Transport-Layer Changes................................? 4. ILNP Correspondent Cache...............................? 5. Handling Location/Connectivity Changes.................? 6. Secure Dynamic DNS Update..............................? 7. Backwards Compatibility................................? 8. Incremental Deployment.................................? 9. Security Considerations ..............................21 10. IANA Considerations...................................28 11. References ...........................................28 1. INTRODUCTION Atkinson & Bhatti Expires in 6 months [Page 2] Internet Draft ILNP Eng 09 JUL 2012 The Identifier Locator Network Protocol (ILNP) is an experimental network protocol that provides evolutionary enhancements to IP. ILNP is backwards-compatible with IP and also is incrementally deployable. The best starting point for learning about ILNP is the ILNP Architectural Description, which includes a document roadmap [ILNP-ARCH]. ILNP is a single architecture that can have multiple instantiations. Engineering considerations common to all instantiations of ILNP are described in this document. Packet formats and certain other IPv4-centric details of ILNP for IPv4 (ILNPv4) are specified in separate documents [ILNP-v4opts] [ILNP-ICMPv4]. Packet formats and certain other IPv6-centric details of ILNP for IPv6 (ILNPv6) are specified in separate documents [ILNP-NONCE6] [ILNP-ICMPv6]. 1.1 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 RFC 2119 [RFC2119]. 2. ILNP IDENTIFIERS All ILNP nodes must have at least one Identifier value. However, there are various options for generating those Identifier values. We describe in this section the relevant engineering issues related to Identifier generation and usage. Note well that ILNP Identifiers name an ILNP-capable node, and are NOT bound to a specific interface of that node. So a given ILNP Identifier is valid on all active interfaces of the node to which that ILNP Identifier is bound. This is true even if the bits used to form the Identifier value happened to be taken from a specific interface as an engineering convenience. 2.1 Syntax ILNP Identifiers are always unsigned 64-bit strings, and may be realised as 64-bit unsigned integers. Both ILNPv4 and ILNPv6 use the Modified EUI-64 syntax that is used by IPv6 Interface Identifiers, as shown in Figure 1. +--------------------------------------------------+ | 6 id bits | U bit | G bit | 24 id bits | +--------------------------------------------------+ | 32 id bits | +--------------------------------------------------+ Atkinson & Bhatti Expires in 6 months [Page 3] Internet Draft ILNP Eng 09 JUL 2012 Figure 1. IEEE EUI-64 format as used for IPv6 [RFC4291, Sec 2.5.1]. That syntax contains two special reserved bit flags. One flag (the U bit) indicates whether the value has "universal" (i.e. global) scope (1) or "local" (0) scope. The other flag (the G bit) indicates whether the value is an "individual" address (1) or "group" (i.e multicast) (0) address. However, this format does allow other values to be set, by use of administrative or other policy control, as required, by setting the U bit to "local". 2.1 Default values for an Identifier By default, this value, including the U bit and G bit, are set as described in Appendix A of RFC4291 [RFC4291]. Where no other value of Identifier is available for an ILNP node, this is the value that MUST be used. Because ILNP Identifiers might have local scope, and also to handle the case where two nodes at different locations happen to be using the same global scope Identifier (e.g. due to a manufacturing fault in a network chipset or card), implementers must be careful in how ILNP Identifiers are handled within an end system's networking implementation. Some details are discussed in Section 4 below. 2.2 Local-scoped Identifier values ILNP Identifiers for a node also MAY have the Scope bit of the Modified EUI-64 set to "local"" scope. Locally unique identifiers MAY be Cryptographically Generated, created following the procedures used for IPv6 Cryptographically Generated Addresses (CGAs) [RFC3972] [RFC4581] [RFC4982]. Also, locally unique identifiers MAY be used to create the ILNP equivalent to the "Privacy Extensions for IPv6", generating ILNP Identifiers following the procedures used for IPv6 [RFC4941]. 2.3 Multicast Identifiers An ILNP Identifier with the G bit set to "group" names an ILNP multicast group, while an ILNP Identifier with the G bit set to "individual" names an individual ILNP node. However, this usage of multicast for Identifiers for ILNP is currently undefined: Atkinson & Bhatti Expires in 6 months [Page 4] Internet Draft ILNP Eng 09 JUL 2012 ILNP uses IPv6 multicast for ILNPv6 and IPv4 multicast for ILNPv4 and uses the multicast address formats defined as appropriate. The use of multicast Identifiers and design of an enhanced multicast capability for ILNPv6 and ILNPv4 is currently work in progress. 3. TRANSPORT-LAYER CHANGES ILNP uses an Identifier value in order to form the invariant end-system state for end-to-end protocols. Currently, transport protocols such as TCP and UDP use all the bits of an IP address to form such state. So, transport protocol implementations MUST be modified in order to operate over ILNP. 3.1 End-system state Currently, TCP and UDP, for example, use the 4-tuple: for the end-system state for a transport layer end-point. For ILNP, implementations must be modified to instead use: 3.2 Pseudo-header checksum In IP-based implementations, the TCP or UDP pseudo-header checksum calculations include all the bits of the IP address. By contrast, when calculating the TCP or UDP pseudo-header checksums for use with ILNP, only the Identifier values are included in the TCP or UDP pseudo-header checksum calculations. To minimise the changes required within transport protocol implementations, and to maximise interoperability, current implementations are modified to zero the Locator fields (only for the purpose of TCP or UDP checksum calculations). For example, for ILNPv6, this means that the existing code for IPv6 can be used, with the ILNPv6 Identifier bits occupying the lower 64 bits of the IPv6 address field, and the upper 64 bits of the IPv6 address filed being set to zero. For ILNPv4, the Identifier fields are carried in an IPv4 Option [ILNP-v4opts]. Section 7 describes methods for incremental deployment of this ILNP-specific change and backwards compatibility with non- upgraded nodes (e.g. classic IPv4 or IPv6 nodes) in more detail. Atkinson & Bhatti Expires in 6 months [Page 5] Internet Draft ILNP Eng 09 JUL 2012 4. ILNP CORRESPONDENT CACHE (ILCC) For operational purposes, implementations need to have a local cache of state information that allow communication end-points to be constructed and for communication protocols to operate. Such cache information is common today, e.g. IPv4 nodes commonly maintain an Address Resolution Protocol (ARP) cache with information relating to current and recent Correspondent Nodes; IPv6 nodes maintain a Neighbor Discovery (ND) table with information relating to current and CNs. Likewise, ILNP maintains an Identifier-Locator Correspondent Cache (ILCC) with information relating to the operation of ILNP. The ILCC is a (logical) set of data values required for ILNP to operate. These values are maintained by the endpoints of each ILNP communications session. From an engineering viewpoint, the ILCC could be implemented by extending or enhancing existing data structures within existing implementations. For example, by adding appropriate flags to the data structures in existing implementations. In theory, this cache is within the ILNP network-layer. However, many network protocol implementations do not have strict protocol separation or layering. So there is no requirement that the ILCC be kept partitioned from transport-layer protocols. 4.1 Formal Definition The ILCC contains information about both the local node and also about current or recent correspondent nodes, as follows. Information about the local node: - Each currently valid Identifier value, including its Identifier Precedence and whether it is active at present. - Each currently valid Locator value, including its associated local interface(s), its Locator Precedence, and whether it is active at present. - Each currently valid IL Vector (IL-V), including whether it is active at present. Information about each correspondent node: - Most recent set of Identifiers, Atkinson & Bhatti Expires in 6 months [Page 6] Internet Draft ILNP Eng 09 JUL 2012 including lifetime and validity for each. - Most recent set of Locators, including lifetime and validity for each. - Nonce value for packets from the local host to the correspondent. - Nonce value for packets from the correspondent to the local host. In the above list for the ILNP Correspondent Cache: - A "valid" item is useable, from an administrative point of view, but might or might not be in use at present. - The "validity" parameter for the correspondent node indicates one of several different states for a datum. These include at least the following: - "valid" : data is useable and has not expired. - "active" : data is useable, has not expired, and is in active use at present. - "expired" : data is still in use at present, but is beyond its expiration (i.e. without a replacement value). - "aged" : data was recently in use, but is not in active use at present, and is beyond its expiration. - The "lifetime" parameter is an implementation-specific representation of the validity lifetime for the associated data element. In normal operation, the Lifetime for a correspondent node's Locator(s) are learned from the DNS Time-To-Live (DNS TTL) value associated with DNS records (ID, L32, L64 etc) of the FQDN owner name of the correspondent node. For time, a node might use UTC (e.g. via Network Time Protocol) or perhaps some node-specific time (e.g. seconds since node boot). 4.2 Aging ILCC Entries As a practical matter, it is not sensible to flush all Locator values associated with an existing session's correspondent node Atkinson & Bhatti Expires in 6 months [Page 7] Internet Draft ILNP Eng 09 JUL 2012 even if the DNS TTL associated with those Locator values expires. In some situations, a CN might be disconnected briefly when moving location (e.g. immediate handover). If this happens, there might be a brief pause before the Correspondent Node can (a) update its own L values in the DNS and (b) send an ICMP Locator Update message to the local node with information about its new location. Implementers ought to try to maintain ILNP sessions even when such events occur. Instead, Locator values cached for a correspondent node SHOULD be marked as "aged" when their TTL has expired, but retained until either the next Locator Update message is received, there is other indication that a given Locator is not working any longer, there is positive indication that the Correspondent Node has terminated the session (e.g. TCP RST), until some appropriate timeout (e.g. 2*MSL for TCP), or the session has been inactive for several minutes and the storage space associated with the aged entry needs to be reclaimed. Separately, received authenticated Locator Update messages cause the ILCC entries listed above to be updated. Similarly, if there is indication that a session with a Correspondent Node remains active and the DNS TTL associated with that Correspondent Node's active Identifier value(s) has expired, those remote Identifier value(s) ought to be marked as "aged" but retained since they are in active use. 4.3 Large Numbers of Locators Implementers should keep in mind that a node or site might have a large number of concurrent Locators, and should ensure that a system fault does not arise if the system receives an authentic ICMP Locator Update containing a large number of Locator values. 4.4 Lookups into the ILCC For received packets containing an ILNP Nonce Option, lookups in the ILCC MUST use the tuple as the lookup key. This facilitates situations where, perhaps due to deployment of Local-scope Identifiers, more than one Correspondent Node is using the same Identifier value. For all other ILNP packets, lookups in the ILNP Correspondent Cache MUST use the