Internet Draft RJ Atkinson draft-rja-ilnp-intro-08.txt Consultant Expires: 7 JUN 2011 7 December 2010 Category: Experimental ILNP Concept of Operations draft-rja-ilnp-intro-08.txt Status of this Memo Distribution of this memo is unlimited. Copyright (c) 2010 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 documents at any time. It is inappropriate to use Atkinson Expires in 6 months [Page 1] Internet Draft ILNP Intro 7 JUN 2011 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. This document has had extensive review within the IRTF Routing Research Group, and is part of the ILNP document set. 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. Abstract This document describes the Concept of Operations for the Identifier Locator Network Protocol (ILNP), which is an experimental extension to IP. This is a product of the IRTF Routing RG. Table of Contents 1. Introduction ...............................................2 2. Locators & Identifiers......................................4 3. Transport Protocols.........................................8 4. Mobility....................................................9 5. Multi-Homing...............................................12 6. Localised Addressing.......................................13 7. IP Security Enhancements...................................14 8. DNS Enhancements...........................................15 9. Referrals & Application Programming Interfaces.............17 10. Backwards Compatibility....................................18 11. Incremental Deployment.....................................19 12. Implementation Considerations..............................20 13. Security Considerations ...................................21 Atkinson Expires in 6 months [Page 2] Internet Draft ILNP Intro 7 JUN 2011 14. IANA Considerations .......................................26 15. References ................................................26 1. INTRODUCTION 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 inter-domain routing. A wide range of other issues (e.g. site multi-homing, node multi-homing, site/subnet mobility, node mobility) are also active concerns at present. Several different classes of evolution are being considered by the Internet research & 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. There has been substantial research relating to naming in the Internet through the years. [IEN 1] [IEN 19] [IEN 23] [IEN 31] [RFC 814] [RFC 1498] More recently, mindful of that important prior work, and starting well before the Routing RG was re-chartered to focus on inter-domain routing scalability, the author has been examining enhancements to certain naming aspects of the Internet Architecture. [MobiArch07] [MobiWAC07] [MobiArch08] [MILCOM08] [MILCOM09] [TeleSys] The architectural concept behind ILNP derives originally from a June 1994 note by Bob Smart to the IETF SIPP WG mailing list. [SIPP94] In January 1995, Dave Clark sent a note to the IETF IPng WG mailing list suggesting that the IPv6 address be split into separate Identifier and Locator fields. [IPng95] Afterwards, Mike O'Dell pursued this concept in Internet-Drafts describing "8+8" or "GSE".[8+8] [GSE] More recently, the IRTF Namespace Research Group (NSRG) studied this matter. Unusually for an IRTF RG, the NSRG operated on the principle that unanimity was required for the NSRG to make a recommendation. The author was a member of the IRTF NSRG. At least one other proposal, the Host Identity Protocol (HIP), also derives in part from the IRTF NSRG studies (and related antecedent work). This current proposal differs from O'Dell's work in various ways. The crux of this proposal is to have different names for the identity of a node and the location of its subnet, with crisp semantics for each. This enhances the Internet Architecture by adding crisp and clear semantics for the Identifier and Atkinson Expires in 6 months [Page 3] Internet Draft ILNP Intro 7 JUN 2011 for the Locator, removing the semantically-muddled concept of the IP address, and updating end system protocols slightly, without requiring router changes. With these naming enhancements, we have improved the Internet Architecture by adding explicit support not only for multi-homing, but also for mobility, localised addressing (e.g. NAT/NAPT), and IP Security. ILNP is an architecture, and can have more than one engineering instantiation. The term ILNPv4 refers precisely to an instance of ILNP that is based upon and backwards compatible with IPv4. The term ILNPv6 refers precisely to an instance of ILNP that is based upon and backwards compatible with IPv6. The following two subsections provide brief overview of ILNPv6 and ILNPv4, respectively. A full specification for either ILNPv4 or ILNPv6 is beyond the scope of this document. Readers are referred to other related ILNP documents for details not described here. [ILNP-DNS] describes additional DNS resource records that support the Identifier/Locator split mode of operation. [ILNP-ICMP] describes a new ICMPv6 Locator Update message used by an ILNP node to inform its correspondent nodes or any changes to its set of valid Locators. [ILNP-Nonce] describes a new IPv6 Nonce Destination Option used by ILNP 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 Identifier/Locator split mode and (2) to authenticate ICMP messages, for example the ICMPv6 Locator Update message, that are exchanged with ILNP correspondent nodes. ILNP improves routing scalability by helping multi-homed sites operate effectively with provider-aggregatable addresses. Many multi-homed sites today request provider-independent addresses so they can provide session survivability despite the failure of one or more access links or ISPs. ILNP provides this session scalability by allowing correspondents to change arbitrarily among multiple provider-aggregatable Locator values without dirrupting the transport session. In turn, this allows the multi-homed site to have the full session resilience offered by provider-independent addressing while using provider-aggregatable addressing, and to eliminate the current need to use globally visible provider-independent routing prefixes for each multi-homed site. 1.1 Overview Atkinson Expires in 6 months [Page 4] Internet Draft ILNP Intro 7 JUN 2011 ILNP places an explicit Locator and Identifier in the IP packet header, replacing the usual IP address. Locators are tied to the topology of the network. They may change frequently, as the host or site changes its network connectivity. The node Identifier is normally much more static, and remains constant throughout the life of a given Transport-layer session, and frequently much longer. Identifiers and Locators for hosts are advertised explicitly in DNS, through the use of new Resource Records. This is a logical and reasonable use of DNS, completely analogous to the functionality that DNS provides today. At present, among other current uses, the DNS is used to map from a FQDN to a set of addresses. As ILNP replaces addresses with Identifiers and Locators, it is then clearly rational to use the DNS to map an FQDN to a set of Identifiers and a set of Locators for the host. The presence of ILNP Locators and Identifiers in the DNS for a DNS owner name is an indicator to correspondents that the correspondents can try to establish an ILNP enhanced transport session with that DNS owner name. The use of ILNP for a specific session is indicated by the inclusion of an ILNP Nonce as an IPv4/IPv6 option when the connection is initated. Once both parties have sent an ILNP Nonce, then ILNP can be freely used for that connection. When a node changes Locator(s), it can send an ICMP message to its current correspondents and also undertake a Secure DNS Dynamic Update (RFC-3007) transaction with its DNS server. The ICMP message is always protected through the use of the Nonce within the ICMP message and also may optionally be protected by use of the IP Authentication Header. Nonce values are unidirectional. The Nonce for a given session must, for the lifetime of that session, correspond with the Nonce initially sent at the start of that session. 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 RFC 2119. [RFC 2119] 2. LOCATORS & IDENTIFIERS ILNP deprecates the semantically muddled concept of an "IP Address" and replaces it with 2 new concepts, the "Locator" Atkinson Expires in 6 months [Page 5] Internet Draft ILNP Intro 7 JUN 2011 and the "Identifier". The Locator is used only to name the subnetwork a node is connected to, while the Identifier is used only for node identity. So the routing system uses Locators, while upper-layer protocols (e.g. TCP/UDP pseudo-header checksum, IPsec Security Association) use only the Identifier. The same Identifier definition is used for both ILNPv4 and ILNPv6. This is described in the next sub-section. Following that is a description of ILNPv6, including a description of the 64-bit Locator value used with ILNPv6. Then, there is a description of ILNPv4, including a description of the 32-bit Locator value used with ILNPv4. 2.1 Identifiers With ILNP, the Identifier is an unsigned 64-bit number. This provides a fixed-length non-topological name for a node. Identifiers are bound to nodes, not to interfaces of a node. All ILNP Identifiers MUST comply with the modified EUI-64 syntax already specified for IPv6's "Interface Identifier" values. [RFC 2460][RFC 4219][IEEE-EUI] Identifiers have either global-scope or local-scope. A reserved bit in the modified EUI-64 syntax clearly indicates whether a given Identifier has global-scope or local-scope.[RFC 4219][IEEE-EUI] A node is not required to use a global-scope Identifier, although that is the recommended practice. Most commonly, Identifiers have global-scope and are derived from one or more IEEE 802 or IEEE 1394 'MAC Addresses' (sic) already associated with the node, following the procedure already defined for IPv6.[RFC 4219] Global-scope identifiers have a high probability of being globally unique. This approach eliminates the need to manage Identifiers, among other benefits. Local-scope Identifiers MUST be unique within the context of their Locators. The existing mechanisms of the IPv4 Address Resolution Protocol [RFC 826] and IPv6 Neighbour Discovery Protocol [RFC 4861] automatically enforce this constraint. For example, on an Ethernet-based IPv4 subnetwork the ARP Reply message is sent via link-layer broadcast, thereby advertising the current binding between an IPv4 address and a MAC address to all nodes on that IPv4 subnetwork. (Note also that a Atkinson Expires in 6 months [Page 6] Internet Draft ILNP Intro 7 JUN 2011 well-known, long standing, issue with ARP is that it cannot be authenticated.) Local-scope Identifiers MUST NOT be used with other Locators without first ensuring uniqueness in the context of those other Locators (e.g. by using IPv6 Neighbour Discovery's Duplicate Address Detection mechanism when using ILNPv6 or by sending an ARP Request when using ILNPv4). Other methods might be used to generate local-scope Identifiers. For example, one might derive Identifiers using some form of cryptographic generation or using the methods specified in the IPv6 Privacy Extensions to State-Less Address Auto-Configuration (SLAAC). [RFC 3972, RFC 4941] When cryptographic generation of Identifiers using methods described in RFC-3972 is in use, only the Identifier is included, never the Locator, thereby preserving roaming capability. [RFC 3972] One could also imagine creating a local-scope Identifier by taking a cryptographic hash of a node's public key. Of course, in the very unlikely event of a Identifier collision, for example when a node has chosen to use a local-scope Identifier value, the node remains free to use some other local-scope Identifier value(s). 2.2 ILNPv6 It is worth remembering here that an IPv6 address names a specific network interface on a specific node, but an ILNP Identifier names the node itself, not a specific interface on the node. This difference in definition is essential to providing seamless support for mobility and multi-homing, which are discussed in more detail later in this note. 1 1 2 3 0 4 8 2 6 4 1 +---------------+-----------------+----------------+---------------+ | Version| Traffic Class | Flow Label | +---------------+-----------------+----------------+---------------+ | Payload Length | Next Header | Hop Limit | +---------------+-----------------+--------------------------------+ | Source Address | + + | | + + | | + + | | +---------------+-----------------+----------------+---------------+ | Destination Address | + + Atkinson Expires in 6 months [Page 7] Internet Draft ILNP Intro 7 JUN 2011 | | + + | | + + | | +---------------+-----------------+----------------+---------------+ Figure 1: Existing ("Classic") IPv6 Header The high-order 64-bits of the IPv6 address become the Locator. The Locator indicates the subnetwork point of attachment for a node. In essence, the Locator names a subnetwork. Locators are also known as Routing Prefixes. Of course, backwards compatibility requirements mean that ILNPv6 Locators use the same number space as IPv6 routing prefixes. This ensures that no changes are needed to deployed IPv6 routers when deploying ILNPv6. The low-order 64-bits of the IPv6 address become the Identifier. Details of the Identifier were discussed just above. 1 1 2 3 0 4 8 2 6 4 1 +---------------+-----------------+----------------+---------------+ | Version| Traffic Class | Flow Label | +---------------+-----------------+----------------+---------------+ | Payload Length | Next Header | Hop Limit | +---------------+-----------------+----------------+---------------+ | Source Locator | + + | | +---------------+-----------------+----------------+---------------+ | Source Identifier | + + | | +---------------+-----------------+----------------+---------------+ | Destination Locator | + + | | +---------------+-----------------+----------------+---------------+ | Destination Identifier | + + | | +---------------+-----------------+----------------+---------------+ Figure 2: ILNPv6 Header Atkinson Expires in 6 months [Page 8] Internet Draft ILNP Intro 7 JUN 2011 2.3 ILNPv4 ILNPv4 is merely a different instantiation of the ILNP Architecture, so it retains the crisp distinction between the Locator and the Identifier. Also, as with 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. As with ILNPv6, only the Locator values are used for routing ILNPv4 packets. Just as ILNPv6 is carefully engineered to be backwards- compatible with IPv6, ILNPv4 is carefully engineered to be backwards-compatible with IPv4. The Source IP Address in the IPv4 header becomes the Source ILNPv4 Locator value, while the Destination IP Address of the IPv4 header becomes the Destination ILNPv4 Locator value. Of course, backwards compatibility requirements mean that ILNPv4 Locators use the same number space as IPv4 routing prefixes. ILNPv4 uses the same 64-bit Identifier, with the same modified EUI-64 syntax, as ILNPv6. Because the IPv4 address is much smaller than the IPv6 address, ILNPv4 cannot carry the Identifier values in the fixed portion of the IPv4 header. The obvious two ways to carry the ILNP Identifier with ILNPv4 are either as an IPv4 Option or as an IPv6-style Extension Header placed after the IPv4 header and before the upper-layer protocol (e.g. OSPF, TCP, UDP, SCTP). At least some currently available IPv4 forwarding silicon is able to parse past IPv4 options to examine the upper-layer protocol header at wire-speed on reasonably fast (e.g. 1 Gbps or better) network interfaces. By contrast, no existing silicon is able to parse past a new Extension Header at all. So, for engineering reasons, ILNPv4 uses a new IPv4 Option to carry the Identifier values. The new IPv4 option also carries a nonce value, performing the same function for ILNPv4 as the IPv6 Nonce Destination Option [ILNP-Nonce] performs for ILNPv6. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version|IHL=12 |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Atkinson Expires in 6 months [Page 9] Internet Draft ILNP Intro 7 JUN 2011 | Source Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OT=ILNPv4_ID | OL=5 | Padding=0x0000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Source Identifier + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Destination Identifier + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |OT=ILNPv4_NONCE| OL=2 | top 16 bits of nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | lower 32 bits of nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: ILNPv4 header with ILNP ID option and ILNP Nonce option. Notation for Figure 3: IHL: Internet Header Length OT: Option Type OL: Option Length The remainder of this note focuses on ILNP for IPv6, in the interest of both clarity and brevity, however the same architectural concepts and principles also apply to ILNP for IPv4, albeit with slightly different engineering. 3. TRANSPORT PROTOCOLS At present, commonly deployed transport protocols include a pseudo-header checksum that includes certain network-layer fields, the IP addresses used for the session, in its calculation. This inclusion of network-layer information within the transport-layer session state creates issues for multi-homing, mobility, IP Security, and localised addressing (e.g. using Network Address Translation). [RFC 1631][RFC 3022] This unfortunate aspect of the TCP pseudo-header checksum has been understood to be an architectural problem at least since 1977, well before the transition from NCP to IPv4.[IEN 1][IEN 19][IEN 23][IEN 31][RFC 1498] Atkinson Expires in 6 months [Page 10] Internet Draft ILNP Intro 7 JUN 2011 With this proposal, transport protocols include only the Identifier in their pseudo-header calculations, but do not include the Locator in their pseudo-header calculations. To minimise the changes required within transport protocol implementations, when this proposal is in use for a communications session, the Locator fields are zeroed for the purpose of transport-layer pseudo-header calculations. Later in this document, methods for incremental deployment of this change and backwards compatibility with non-upgraded nodes are described. 4. MOBILITY First, please recall that mobility and multi-homing actually present the same set of issues. In each case, the set of Locators associated with a node or site changes. The reason for the change might be different, but the effects on the network and on correspondents is identical. There are no standardised mechanisms to update most transport protocols with new IP addresses in use for the session. Exceptionally, the Stream Control Transport Protocol (SCTP) recently added this capability.[RFC 5061] In July 2008, Mark Handley at UCL proposed adding such a capability to TCP during a presentation at the IRTF Routing RG in Dublin, Ireland. His Multi-Path TCP concept is being considered in the IETF as of this writing. This creates various issues for mobility. For example, there is no method at present to update the IP addresses associated with a transport layer session when one of the nodes in that session moves (i.e. changes one of its points of network attachment). So, the several approaches to IP mobility seek to hide the change in location (and corresponding change in IP addresses) via tunnelling, home agents, foreign agents, and so forth. [RFC 3775] All of this can add substantial complexity to IP mobility approaches, both in the initial deployment and also in ongoing operation. By contrast, this ILNP proposal hides each node's location information from the transport layer protocols at all times, by removing location information from the transport session state (e.g. pseudo-header checksum calculations). Atkinson Expires in 6 months [Page 11] Internet Draft ILNP Intro 7 JUN 2011 In this proposal, mobility and multi-homing are supported using a common set of mechanisms. In both cases, different Locator values are used to identify different IP subnetworks. Also, ILNP nodes are assumed to have a Fully Qualified Domain Name (FQDN) stored in the Domain Name System (DNS), as is already done within the deployed Internet. To handle the move of a node, we add a new ICMP control message. The ICMP Locator Update message is used by a node to inform its existing correspondents that the set of valid Locators for the node has changed. This mechanism can be used to add newly valid Locators, to remove no longer valid Locators, or to do both at the same time. Further, the node uses Secure Dynamic DNS Update [RFC 3007] to correct the set of Locator (i.e. L32, L64) records in the DNS for that node.[ILNP-DNS] This enables any new correspondents to correctly initiate a new session with the node at its new location. This use of DNS for initial rendezvous with mobile node was independently proposed by others [PHG02] and then separately re-invented by the current author later on. (The Locator Update control message could be an entirely new protocol running over UDP, for example, but there is no obvious advantage to creating a new protocol rather than using a new ICMP message.) With ILNP, network mobility (as well as node mobility) is considered a special case of multihoming. That is, when a network moves, it uses a new Locator value for all of its communications sessions. So, the same mechanism, using a new or additional Locator value, also supports network mobility. Similarly, when a multi-homed site or multi-homed node changes its set of upstream links, the Locators associated with that site or node change. So in ILNP, when a connectivity change affects the set of valid Locators, the affected node(s) actively: (1) use the ICMP Locator Update message to inform their existing correspondents with the updated information about their currently valid Locator(s). [ILNP-ICMP] AND also (2) update their DNS entries, most commonly by using the Secure Dynamic DNS Update mechanism. [RFC 3007] Atkinson Expires in 6 months [Page 12] Internet Draft ILNP Intro 7 JUN 2011 In the unlikely event of simultaneous motion which changes both nodes' Locators within a very small time period, a node can use the DNS to discover the new Locator value(s) for the other node. As a DNS performance optimisation, the "LP" DNS resource record MAY be used to avoid requiring each node on a subnetwork to update its DNS L64 record entries when that subnetwork's location (e.g. upstream connectivity) changes. In this case, the nodes on the subnetwork each would have an "LP" record pointing to a common domain-name used to name that subnetwork. In turn, that subnetwork's domain name would have one or more L64 record(s) in the DNS. Since the contents of an "LP" record are stable, relatively long DNS TTL values can be associated with these records facilitating DNS caching. By contrast, the DNS TTL of an L32 or L64 record for a mobile or multi-homed node should be small. Experimental work at the University of St Andrews indicates that the DNS continues to work well even with very low DNS TTL values. [Bhatti10] Correspondents of a node on that subnetwork would perform a "L64" record query for that target node (or an "ID" query for that target node) and receive the "LP" records as additional data in the DNS reply. Then the correspondent would perform an L64 record lookup on the domain-name pointed to by that LP record, in order to learn the Locator value to use to reach that target node. For bi-directional flows, such as a TCP session, each node knows whether the current path in use is working by the reception of data packets, acknowledgements, or both. As with TCP/IP, TCP/ILNP does not need special path probes. UDP/ILNP sessions with acknowledgements work similarly, and also don't need special path probes. In the deployed Internet, the sending node for a UDP/IP session without acknowledgements does not know for certain that all packets are received by the intended receiving node. Such UDP/ILNP sessions fare no worse than UDP/IP sessions. The receiver(s) of such a UDP session SHOULD send a gratuitous IP packet containing an ILNP Nonce option to the sender, in order to enable the receiver to subsequently send ICMP Locator Updates if appropriate. [ILNP-Nonce] In this case, UDP/ILNP sessions fare better than UDP/IP sessions, still without using network path probes. One might wonder what happens if a mobile node is moving more quickly than DNS can be updated. This situation is unlikely, Atkinson Expires in 6 months [Page 13] Internet Draft ILNP Intro 7 JUN 2011 particularly given the widespread use of link-layer mobility mechanisms (e.g. GSM, IEEE 802 bridging) in combination with network-layer mobility. However, the situation is functionally equivalent to the situation where a traditional IP node is moving faster than the Mobile IPv4 or Mobile IPv6 agents/servers can be updated with the mobile node's new location. So the issue is not new in any way. In all cases, Mobile IPv4 and Mobile IPv6 and ILNP, a node moving that quickly might be temporarily unreachable until it remains at a given network-layer location (e.g. IP subnetwork) long enough for the location update mechanisms (for Mobile IPv4, for Mobile IPv6, or ILNP) to catch up. ILNP is prospectively better than either form of Mobile IP with respect to key management, given that ILNP is using Secure Dynamic DNS Update -- which capability is much more widely available today in deployed desktop and server environments (e.g. Microsoft Windows, MacOS X, Linux, other UNIX), [Liu-DNS] as well as being widely available today in deployed DNS server software (e.g. Microsoft and the freely available BIND) and appliances [Liu-DNS], than the Security enhancements needed for either Mobile IPv4 or Mobile IPv6 5. MULTI-HOMING Conceptually, there are two kinds of multi-homing. Site multi-homing is when all nodes at a site are multi-homed at the same time. This is what most people mean when they talk about multi-homing. However, there is also a separate concept of node multi-homing, where only a single node is multi-homed. Kindly recall, that multiple transport-layer sessions might currently share a single current network-layer (e.g. IP or ILNP) session. 5.2 Node Multi-Homing At present, node multi-homing is not common in the deployed Internet. When TCP or UDP are in use for an IP session, node multi-homing cannot provide session resilience, because the transport pseudo-header checksum binds the session to a single address of the multi-homed node, and hence to a single interface. SCTP has a protocol-specific mechanism to support node multi-homing; SCTP can support session resilience both at present and also without change in the proposed approach. [RFC 5061] In the new scheme, when a node is multi-homed, then the node typically has more than one valid Locator value. When one upstream connection fails, the node sends an ICMP Locator Update message to each existing correspondent node to remove the no-longer-valid Locator from the set of valid Locators. Atkinson Expires in 6 months [Page 14] Internet Draft ILNP Intro 7 JUN 2011 [ILNP-ICMP] Also, the node can use Secure Dynamic DNS Update to alter the set of currently valid L64 records associated with that node. [RFC 3007] This second step ensures that any new correspondents can reach the node. 5.2 Site Multi-Homing At present, site multi-homing is common in the deployed Internet. This is primarily achieved by advertising the site's routing prefix(es) to more than one upstream Internet service provider at a given time. In turn, this requires de-aggregation of routing prefixes within the inter-domain routing system. In turn, this increases the entropy of the inter-domain routing system (e.g. RIB/FIB size increases beyond the minimal RIB/FIB size that would be required to reach all sites). In the new scheme, site multi-homing is similar to node multi-homing, but with nodes within the site having one Locator for each upstream connection to the Internet. To avoid a DNS Update burst when a site or (sub)network moves location, a DNS record optimisation is possible. This would change the number of DNS Updates required from Order(number of nodes at the site/subnetwork that moved) to Order(1). [ILNP-DNS] Additionally, since the transport-protocol session state no longer includes the Locators, a site could choose to perform Locator rewriting at its site border routers, possibly in combination with applying site traffic engineering policy on which upstream link to use for which packets. Since the site border router(s) are in the middle of any exterior packet flow, they also can send proxy Locator Update messages on behalf of nodes inside that site, and can even include the appropriate Nonce value in such proxy Locator Updates, if desired by that site's administration. 5.3 Multi-Path Support Because ILNP decouples the transport-layer information from the Locator values being used for a given session (e.g. TCP pseudo-header checksum includes Identifier values, but not Locator values, when ILNP is in use), ILNP can enable multi-path transport-layer sessions without requiring any changes to existing transport-layer protocols (e.g. TCP, UDP). Note that this approach also does not interfere with SCTP's existing support for multi-path transport nor with the proposed TCP multi-path extensions. With ILNP, any transport-layer session can use multiple paths Atkinson Expires in 6 months [Page 15] Internet Draft ILNP Intro 7 JUN 2011 concurrently, simply by using multiple (valid) Locator values in that session's ILNP packets. Obviously for any given ILNP packet a single Source Locator and a single Destination Locator is in use. As an example, if one considers TCP with an originator using Locators (A, B, C) and a responder using Locators (W, X, Y), then the originator can choose which Source Locators to use and also which Destination Locators on a packet-by-packet basis. So different TCP segments (or TCP ACKs, or other TCP information) within a single TCP session can use different Locator pairs. Again, purely as an example, the originator could send packets using these Locator values in this simple sequence: (A, W) (B, X) (C, Y) or any other sequence that it wishes to. The choice of Locator value to use for a given packet is made by the sending node, selected from the current set of valid Locator values for the receiving node. Similarly, the responder can use any valid combination of Locators that it wishes to use. The ILNP-related DNS resource records specified in [ILNP-DNS] contain relative preference values. The simplest approach to Locator selection probably is to use the most preferred Locator value advertised by the receiving node as the Destination Locator, and the local node's own most preferred Locator value as the Source Locator. However, an ILNP node MAY also consider local policy and other locally-available information in deciding which Locator value(s) to use for a given ILNP packet being sent by that node. In any case, the TCP implementations at either end are unaware that multiple Locators are being used (i.e. because the transport-layer pseudo-header checksum only includes Identifiers, never Locators). In turn, this is why not special multi-path TCP (or UDP or SCTP or other) transport-layer modifications are required. (Caveat: Of course, the ILNP stack upgrade is needed in the first place.) The same concepts and general approach also apply to UDP and/or SCTP. 6. LOCALISED ADDRESSING As the Locator value no longer forms part of the node session state (e.g. TCP pseudo-header), it is easier to support localised addressing, which is sometimes also called "Private Addressing", based on the use of local values of the Locator. Atkinson Expires in 6 months [Page 16] Internet Draft ILNP Intro 7 JUN 2011 This would be either in place of, or to supplement, existing NAT-based schemes. [RFC 1631] [RFC 3022] For example, a site that desires to use private addresses internally might deploy IPv6 Unique Local Addressing (ULA) for localised addressing, along with some form of ILNP/ IPv6 Network Address Translation at a site border gateway. [ID-ULA] [RFC 4193] This example is described in detail in [MILCOM09], both as a mechanism for site multi-homing and also as a mechanism to support site-controlled traffic engineering. In the simplest case, an ILNP capable NAT only would need to change the value of the Source Locator in an outbound packet, and the value of the Destination Locator for an inbound packet. Identifier values would not need to change, nor would transport-layer checksums, so a true end-to-end session could be maintained. If a site using localised addressing chooses to deploy a split-horizon DNS server, then the DNS server would advertise the global-scope Locator(s) of the site border routers outside the site to DNS clients outside the site, and would advertise the local-scope Locator(s) specific to that internal node to DNS clients inside the site. Such deployments of split-horizon DNS servers are not unusual in the IPv4 Internet today. If an internal node (e.g. portable computer) moves outside the site, it would follow the normal ILNP methods to update its authoritative DNS server with its current Locator set. In this deployment model, the authoritative DNS server for that mobile device will be either the split-horizon DNS server itself or the master DNS server providing data to the split-horizon DNS server. If a site using localised addressing chooses not to deploy a split-horizon DNS server, then all internal nodes would advertise the global-scope Locator(s) of the site border routers. To deliver packets from one internal node to another internal node, the site would either choose to use layer-2 bridging (e.g. IEEE Spanning Tree, IEEE Rapid Spanning Tree, or a link-state layer-2 algorithm such as the IETF TRILL group or IEEE 802.1 are developing), or the interior routers would forward packets up to the nearest site border router, which in turn would then rewrite the Locators to appropriate local-scope values, and forward the packet towards the interior destination node. Alternately, for sites using localised addressing but not deploying a split-horizon DNS server, the DNS server could Atkinson Expires in 6 months [Page 17] Internet Draft ILNP Intro 7 JUN 2011 return all global-scope and local-scope Locators to all queriers, and to assume that correspondent hosts would use address selection to choose the best Locator to use to reach a given correspondent. [RFC 3484] Hosts within the same site as the correspondent node would only have a ULA configured, and hence would select the ULA destination Locator for the correspondent. Hosts outside the site would not have the same ULA configured. Note that RFC 3484 probably needs to be updated to indicate that the longest-prefix matching rule is inadequate when comparing ULA-based Locators with global-scope Locators: to choose a ULA for a correspondent, a node must have a Locator that matches all 48 ULA bits of the target Locator value. We note that a deployment using private/local addressing can also provide site multi-homing by deploying site border routers in this manner. Please note that with this proposal, localised addressing (e.g. using Network Address Translation on the Locator bits) would work in harmony with multihoming, mobility, and IP Security.[MobiWAC07][MILCOM08][MILCOM09] 7. IP SECURITY ENHANCEMENTS A current issue is that the IP Security protocols, AH and ESP, have Security Associations that include the IP addresses of the secure session endpoints. This was understood to be a problem when AH and ESP were originally defined, however the limited set of namespaces in the Internet Architecture did not provide any better choices at that time. Operationally, this binding causes problems for the use of the IPsec protocols through Network Address Translation devices, with mobile nodes (because the mobile node's IP address changes at each network-layer handoff), and with multi-homed nodes (because the session is bound to a particular interface of the multi-homed node, rather than being bound to the node itself).[RFC 3027][RFC 3715] To resolve the issue of IPsec interoperability through a NAT deployment, UDP encapsulation of IPsec is commonly used today.[RFC 3948] With this proposal, the IP Security protocols, AH and ESP, are enhanced to bind Security Associations only to Identifier values and never to Locator values (and also Atkinson Expires in 6 months [Page 18] Internet Draft ILNP Intro 7 JUN 2011 not to an entire 128-bit IPv6 address). Similarly, key management protocols used with IPsec would be enhanced to deprecate use of IP addresses as identifiers and to substitute the use of the new Identifier for that purpose. This small change enables IPsec to work in harmony with multihoming, mobility, and localised addressing. [MILCOM08] [MILCOM09] Further, it would obviate the need for specialised IPsec NAT Traversal mechanisms, thus simplifying IPsec implementations while enhancing deployability and interoperability. [RFC 3948] This change does not reduce the security provided by the IP Security protocols. 8. DNS ENHANCEMENTS As part of this proposal, additional DNS Resource Records have been proposed in a separate document. [ILNP-DNS] These new records store the Identifier and Locator values for nodes that have been upgraded to support the Identifier-Locator Split Mode. With this proposal, mobile or multi-homed nodes and sites are expected to use the existing "Secure Dynamic DNS Update" protocol to keep their Identifier and Locator records correct in its authoritative DNS server(s). [RFC 3007] While some might be surprised, Secure Dynamic DNS Update is available now in a very wide range of existing deployed systems. For example, Microsoft Windows XP (and later versions), the freely distributable BIND DNS software package (used in Apple MacOS X and in most UNIX systems), and the commercial Nominum DNS server all implement support for Secure Dynamic DNS Update and are known to interoperate. [Liu-DNS] There are credible reports that when a site deploys Microsoft's Active Directory, the site (silently) automatically deploys Secure Dynamic DNS Update. [Liu-DNS] So it appears that many sites have already deployed Secure Dynamic DNS Update even though they might not be aware they have already deployed that protocol. [Liu-DNS] Reverse DNS lookups, to find a node's Fully Qualified Domain Name from the combination of a Locator and related Identifier value, can be performed as at present. Previous research by others indicates that DNS caching is largely ineffective, with the exception of NS records and the addresses Atkinson Expires in 6 months [Page 19] Internet Draft ILNP Intro 7 JUN 2011 of DNS servers referred to by NS records.[SBK2002] This means DNS caching performance will not be adversely affected by assigning very short time-to-live (TTL) values to the Locator records of typical nodes.[Bhatti10] It also means that it is preferable to deploy the DNS server function on nodes that have longer DNS TTL values, rather than on nodes that have shorter DNS TTL values. As discussed previously, LP records normally are stable, even if the L32 or L64 records they point to aren't stable, so LP records normally can be given very long DNS TTL values. Identifier values might be very long-lived (e.g. days) when they have been generated from an IEEE MAC Address on the system. Identifier values might have a shorter lifetime (e.g. hours) if they have been cryptographically-generated [RFC 3972], or have been created by the IPv6 Privacy Extensions [RFC 4941], or otherwise have the EUI-64 scope bit at the "local-scope" value. Note that when ILNP is used, the cryptographic generation method described in RFC-3972 is used only for the Identifier, omitting the Locator, thereby preserving roaming capability. Note that a given ILNP session normally will use a single Identifier value for the life of that session. Existing DNS specifications require that DNS clients and DNS resolvers obey the TTL values provided by the DNS servers. In the context of this proposal, short DNS TTL values are assigned to particular DNS records to ensure that the ubiquitous DNS caching resolvers do not cache volatile values (e.g. Locator records of a mobile node) and consequently return stale information to new requestors. As a practical matter, it is not sensible to flush all Locator values associated with an existing session's correspondent node. Instead, Locator values cached for a correspondent node (in the ILNP Correspondent Cache, described in Section 12.1) SHOULD be marked as "aged" when their TTL has expired until either the next Locator Update message is received or there is other indication that a given Locator is not working any longer. During a long transition period, a node that is I/L-enabled SHOULD have not only ID and L64 (or ID and LP) records present in its authoritative DNS server, but also SHOULD have AAAA records in the DNS for the benefit of non-upgraded nodes. This capability might be implemented strictly inside a DNS server, whereby the DNS server synthesised a set of AAAA records to advertise from the ID and Locator (i.e., L32, L64, or LP) values that the node has kept updated in that DNS server. Atkinson Expires in 6 months [Page 20] Internet Draft ILNP Intro 7 JUN 2011 Existing DNS specifications require that a DNS resolver or DNS client ignore unrecognised DNS record types. So gratuitously appending ID and Locator (i.e., L32, L64, or LP) records as "additional data" in DNS responses to AAAA queries ought not create any operational issues. 9. REFERRALS & APPLICATION PROGRAMMING INTERFACES This section is concerned with support for using existing ("legacy") applications over ILNP, including both referrals and APIs. 9.1 BSD Sockets APIs The existing BSD Sockets API can continue to be used with ILNP underneath the API. That API can be implemented in a manner that hides the underlying protocol changes from the applications. For example, the combination of a Locator and an Identifier can be used with the API in the place of an IPv6 address. So it is believed that existing IP address referrals can continue to work properly in most cases. For a rapidly moving target node, referrals might break in at least some cases. The potential for referral breakage is necessarily dependent upon the specific application and implementation being considered. It is suggested, however, that a new, optional, more abstract, C language API be created so that new applications may avoid delving into low-level details of the underlying network protocols. Such an API would be useful today, even with the existing IPv4 and IPv6 Internet, whether or not ILNP were ever widely deployed. 9.2 Java APIs Most existing Java APIs already use abstracted network programming interfaces, for example in the java.Net.URL class. Because these APIs already hide the low-level network-protocol details from the applications, the applications using these APIs (and the APIs themselves) don't need any modification to work equally well with IPv4, IPv6, ILNP, and probably also HIP. 9.3 Referrals in the Future Atkinson Expires in 6 months [Page 21] Internet Draft ILNP Intro 7 JUN 2011 The approach proposed in [ID-Referral] appears to be very suitable for use with ILNP, in addition to being suitable for use with the deployed Internet. Protocols using that approach would not need modification to have their referrals work well with IPv4, IPv6, ILNP, and probably also other network protocols (e.g. HIP). A more sensible approach to referrals would be to use Fully-Qualified Domain Names (FQDNs), as is commonly done today with web URLs. This is approach is highly portable across different network protocols, even with both the IPv4 Internet or the IPv6 Internet. 10. BACKWARDS COMPATIBILITY First, if one compares Figure 1 and Figure 2, one can see that IPv6 with the Identifier/Locator Split enhancement is fully backwards compatible with existing IPv6. This means that no router software or silicon changes are necessary to support the proposed enhancements. A router would be unaware whether the packet being forwarded were classic IPv6 or the proposed enhanced version of IPv6. So no changes to IPv6 routers is required to deploy this proposal. Further, IPv6 Neighbour Discovery should work fine as is. If a node that has been enhanced to support the Identifier/ Locator Split mode initiates an IP session with another node, normally it will first perform a DNS lookup on the responding node's DNS name. If the initiator node does not find any ID or L64 DNS resource records for the responder node, then the initiator uses the Classical IPv6 mode of operation for the new session with the responder, rather than trying to use the I/L Split mode for that session. Of course, multiple transport-layer sessions can concurrently share a single network-layer (e.g. IP or ILNP) session. If the responder node for a new IP session has not been enhanced to support the I/L Split mode and receives initial packet(s) containing the Nonce Destination Option, the responder will drop the packet and send an ICMP Parameter Problem error message back to the initiator. A responder node that has been upgraded to support the I/L Split mode that receives initial packet(s) containing the Nonce Destination Option knows those packets are ILNP packets by the presence of that Nonce Destination Option. If the initiator node does not receive a response from the Atkinson Expires in 6 months [Page 22] Internet Draft ILNP Intro 7 JUN 2011 responder in a timely manner (e.g. within TCP timeout for a TCP session) and also does not receive an ICMP Unreachable error message for that packet, OR if the initiator receives an ICMP Parameter Problem error message for that packet, then the initiator knows that the responder is not able to support the I/L Split Operating mode. In this case, the initiator node SHOULD try again to create the new IP session but this time OMITTING the Nonce Destination Option, and this time operating in Classic IPv6 mode, rather than I/L Split mode. Finally, since an ILNP node is also a fully-capable IPv6 node, then the upgraded node can use any standardised IPv6 mechanisms for communicating with a legacy IPv6 node (i.e. an IPv6 node without ILNP capability enhancements). So ILNP will in no case be worse than existing IPv6, and in many cases ILNP will out perform existing IPv6. 11. INCREMENTAL DEPLOYMENT If a node has been enhanced to support the Identifier/ Locator Split operating mode, that node's fully-qualified domain name will normally have one or more ID records and one or more Locator (i.e. L32, L64, and LP) records associated with the node within the DNS. When a host ("initiator") initiates a new IP session with a correspondent ("responder"), it normally will perform a DNS lookup to determine the address(es) of the responder. A host that has been enhanced to support the Identifier/ Locator Split operating mode normally will look for Identifier ("ID") and Locator (i.e. L32, L64, and LP) records in any received DNS replies. DNS servers that support ID and Locator (i.e. L32, L64, and LP) records SHOULD include them (when they exist) as additional data in all DNS replies to queries for DNS AAAA records.[ILNP-DNS] If the initiator supports the I/L Split mode and from DNS information learns that the responder also supports the I/L Split mode, then the initiator will generate an unpredictable nonce value, store that value in a local Correspondent Cache, which is described in more detail below, and will include the Nonce Destination Option in its initial packet(s) to the responder.[ILNP-Nonce] If the responder supports the I/L Split mode and receives initial packet(s) containing the Nonce Destination Option, the responder will thereby know that the initiator supports the I/L Split mode and the responder will also operate in Atkinson Expires in 6 months [Page 23] Internet Draft ILNP Intro 7 JUN 2011 I/L Split mode for this new IP session. If the responder supports the I/L Split mode and receives initial packet(s) NOT containing the Nonce Destination Option, the responder will thereby know that the initiator does NOT support the I/L Split mode and the responder will operate in classic IPv6 mode for this new IP session. The previous section described how interoperability between enhanced nodes and non-enhanced nodes is retained even if a non-enhanced node erroneously has ID and/or L64 DNS resource records in place (e.g. due to some accident). The mobility capabilities of ILNP might be the most applicable to the deployment world. Despite substantial good efforts by many, neither Mobile IPv4 nor Mobile IPv6 are widely used at present. There are credible reports of specialised deployments of Mobile IPv4 and/or Mobile IPv6 within some wireless networks built using some mobile telephony standards (e.g. CDMA2000). However, much of the recent work in operating systems has focused on support for mobile devices (e.g. mobile telephone handsets, hand-held music players, hand-held organisers). Those devices probably represent the fastest growth segment of the Internet at present. Moreover, many vendors of such devices have included significant networking protocol improvements in incremental operating system updates, rather than always waiting for a new major release to add networking facilities. Data center operators might be interested in using ILNP to facilitate virtual machine mobility between VLANs within a data centre site or to a separate disaster recovery site. However, other users or vendors might be more interested by the new security models enabled by having Identifiers different from Locators, or they might be more interested in the ability to provide node-specific multi-homing, rather than always multi-homing an entire site. In the end, the marketplace has myriad users with various functional needs. The set of improvements offered by ILNP is broad, and should appeal to a wide range of vendors and users. 12. IMPLEMENTATION CONSIDERATIONS This section discusses implementation considerations that are not otherwise discussed in the ILNP Internet-Drafts. 12.1 ILNP Correspondent Cache Atkinson Expires in 6 months [Page 24] Internet Draft ILNP Intro 7 JUN 2011 An ILNP-capable node will need to modify its network protocol implementation to add an ILNP Correspondent Cache. In theory, this cache is within the ILNP network-layer. However, many network protocol implementations do not have strict protocol separation or layering. In the interest of efficient implementation, and to avoid unduly restricting implementers, an ILNP implementation is not required to limit the accessibility of ILNP Correspondent Cache to the network-layer. The ILNP Correspondent Cache contains at least the following inter-related data elements for the node itself: Set of Local Locator(s) & Preference value for each Locator Set of Local Identifier(s) and also the following per-correspondent data elements: Set of Correspondent's Locator(s) & Preference value for each Locator Set of Correspondent's Identifier(s) Nonce used from the local node to that correspondent Nonce used from that correspondent to the local node Valid Time For received packets containing an ILNP Nonce Destination Option, lookups in the ILNP Correspondent Cache MUST use the (Correspondent Identifier, Nonce) 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 (Correspondent Locator, Correspondent Identifier) 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. The Valid Time field indicates the remaining lifetime for which this ILNP session information is valid. 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). A table entry is current if the node's current time is less than or equal to the time in the Valid Time field, while a table entry is aged if the node's current time is greater than the time in the Valid Time field. While Locators are omitted from the transport-layer checksum, an implementation SHOULD use Locator values to distinguish Atkinson Expires in 6 months [Page 25] Internet Draft ILNP Intro 7 JUN 2011 between correspondents coincidentally using the same ID value (e.g. due to deployment of Local-scope Identifier values) when demultiplexing to determine which application(s) should receive the user data delivered by the transport-layer protocol. 12.2 ICMP Locator Updates While ILNP's ICMP Locator Update message is defined in a separate document [ILNP-ICMP], it is worth mentioning that received authenticated Locator Update messages cause the ILNP Correspondent Cache described just above to be updated. 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. 13. SECURITY CONSIDERATIONS This proposal outlines a proposed evolution for the Internet Architecture to provide improved capabilities. This section discusses security considerations for this proposal. Note that ILNP provides security equivalent to IP for similar threats when similar mitigations (e.g. IPsec or not) are in use. In some cases, but not all, ILNP exceeds that objective and has less security risk than IP. 13.1 Authentication of Locator Updates A separate document [ILNP-Nonce] proposes a new IPv6 Destination Option that can be used to carry a session nonce end-to-end between communicating nodes. That nonce provides protection against off-path attacks on an Identifier/Locator session. The Nonce Destination Option is used ONLY for IP sessions in the Identifier/Locator Split mode. The nonce values are exchanged in the initial packets of an ILNP session. Ordinary IPv6 is vulnerable to on-path attacks unless the IP Authentication Header or IP Encapsulating Security Payload is in use. So the Nonce Destination Option only seeks to provide protection against off-path attacks on an IP session -- equivalent to ordinary IPv6 when not using IP Security. When the Identifier/Locator split mode is in use for an existing IP session, the Nonce Destination Option MUST be Atkinson Expires in 6 months [Page 26] Internet Draft ILNP Intro 7 JUN 2011 included in any ICMP control messages (e.g. ICMP Unreachable, ICMP Locator Update) sent with regard to that IP session. It is common to have non-symmetric paths between two nodes on the Internet. To reduce the number of on-path nodes that know the Nonce value for a given session when the I/L split mode is in use, a nonce value is unidirectional, not bidirectional. For example, for a session between two nodes A and B, one nonce value is used from A to B and a different nonce value is used from B to A. When in the I/L Split operating mode for an existing IP session, ICMP control messages received without a Nonce Destination Option MUST be discarded as forgeries. This security event SHOULD be logged. When in the I/L Split operating mode for an existing IP session, ICMP control messages received without a correct nonce value inside the Nonce Destination Option MUST be discarded as forgeries. This security event SHOULD be logged. When in the I/L Split operating mode for an existing IP session, and a node changes its Locator set, it should include the Nonce Destination Option in the first few data packets sent using a new Locator value, so that the recipient can validate the received data packets as valid (despite having an unexpected Source Locator value). For ID/Locator Split mode sessions operating in higher risk environments, the use of the cryptographic authentication provided by IP Authentication Header is recommended *in addition* to concurrent use of the Nonce Destination Option. It is important to note that at present an IPv6 session is entirely vulnerable to on-path attacks unless IPsec is in use for that particular IPv6 session, so the security properties of the new proposal are never worse than for existing IPv6. 13.2 Forged Identifier Attacks In the deployed Internet, active attacks using packets with a forged Source IP Address have been publicly known at least since early 1995.[CA-1995-01] While these exist in the deployed Internet, they have not been widespread. This is equivalent to the issue of a forged Identifier value and demonstrates that this is not a new threat created by the Identifier/Locator-split mode Atkinson Expires in 6 months [Page 27] Internet Draft ILNP Intro 7 JUN 2011 of operation. One mitigation for these attacks has been to deploy Source IP Address Filtering.[RFC 2827] [RFC 3704] Jun Bi at U. Tsinghua cites Arbor Networks as reporting that this mechanism has less than 50% deployment and cites an MIT analysis indicating that at least 25% of the deployed Internet permits forged source IP addresses. Other parts of this document discuss the probability of an accidental duplicate Identifier being used on the Internet. However, this sub-section instead focuses on methods for mitigating attacks based on packets containing deliberately forged Source Identifier values. First, the recommendations of [RFC 2827] & [RFC 3704] remain. So any packets that have a forged Locator value can be easily filtered using existing widely available mechanisms. Second, the receiving node does not blindly accept any packet with the proper Source Identifier and proper Destination Identifier as an authentic packet. Instead, each node operating the I/L-split mode maintains an ILNP Correspondent Cache for each of its correspondents, as described above. This cache contains two unidirectional nonce values (one used in control messages sent by this node, a different one used to authenticate messages from the other node). The correspondent cache also contains the currently valid set of Locators and set of Identifiers for each correspondent node. If a received packet contains valid Identifier values and a valid Destination Locator, but contains a Source Locator value that is not present in the correspondent cache, the packet is dropped without further processing as an invalid packet, unless the packet also contains a Nonce Destination Option with the correct value used for packets from the node with that Source Identifier to this node. This prevents an off-path attacker from stealing an existing session. Third, any node can distinguish different nodes using the same Identifier value by other properties of their sessions. For example, IPv6 Neighbour Discovery prevents more than one node from using the same source (Locator + Identifier) pair at the same time on the same link. So cases of different nodes using the same Identifier value will involve nodes that have different sets of valid Locator values. A node can thus demux based on the combination of Source Locator and Source Identifier if necessary. If IP Security is in use, the combination of the Source Identifier and the SPI value would be sufficient to demux two different sessions. Atkinson Expires in 6 months [Page 28] Internet Draft ILNP Intro 7 JUN 2011 Fourth, deployments in high threat environments also SHOULD use the IP Authentication Header to authenticate control traffic and data traffic. Because in the I/L-split mode, IP Security binds only to the Identifier values, and never to the Locator values, this enables a mobile or multi-homed node to use IPsec even when its Locator value(s) have just changed. Last, note well that ordinary IPv4, ordinary IPv6, Mobile IPv4, and also Mobile IPv6 already are vulnerable to forged Identifier and/or forged IP address attacks. An attacker on the same link as the intended victim simply forges the victims MAC address and the victim's IP address. With IPv6, when SEND and CGAs are in use, the victim node can defend its use of its IPv6 address using SEND. With ILNP, when SEND and CGIs are in use, the victim node also can defend its use of its IPv6 address using SEND. There are no standard mechanisms to authenticate ARP messages, so IPv4 is especially vulnerable to this sort of attack. These attacks also work against Mobile IPv4 and Mobile IPv6. In fact, when either form of Mobile IP is in use, there are additional risks, because the attacks work not only when the attacker has access to the victim's current IP subnetwork but also when the attacker has access to the victim's home IP subnetwork. So the risks of using ILNP are not greater than exist today with IP or Mobile IP. 13.3 IP Security Enhancements The IP Security standards are enhanced here by binding IPsec Security Associations to the Identifiers of the session endpoints, rather than binding IPsec Security Associations to the IP Addresses as at present. This change enhances the deployability and interoperability of the IP Security standards, but does not decrease the security provided by those protocols. Also, the IP Authentication Header omits the Source Locator and Destination Locator fields from its authentication calculations when ILNP is in use. This enables IP AH to work well even through a NAT or other situation where a Locator value might change during transit. 13.4 DNS Security The DNS enhancements proposed here are entirely compatible with, and can be protected using, the existing IETF standards for DNS Security.[RFC 4033] The Secure DNS Dynamic Update mechanism used here is also used unchanged.[RFC 3007] So there is no change to the security properties of the Domain Name System or of DNS servers due to ILNP. Atkinson Expires in 6 months [Page 29] Internet Draft ILNP Intro 7 JUN 2011 13.5 Firewall Considerations In the proposed new scheme, stateful firewalls are able to authenticate ICMP control messages arriving on the external interface. This enables more thoughtful handling of ICMP messages by firewalls than is commonly the case at present. As the firewall is along the path between the communicating nodes, the firewall can snoop on the Session Nonce being carried in the initial packets of an I/L Split mode session. The firewall can verify the correct nonce is present on incoming control packets, dropping any control packets that lack the correct nonce value. By always including the nonce in ILNP control messages, even when IP Security is also in use, the firewall can filter out off-path attacks against those ILNP messages. In any event, a forged packet from an on-path attacker will still be detected when the IPsec input processing occurs in the receiving node; this will cause that forged packet to be dropped rather than acted upon. 13.6 Neighbour Discovery Authentication Nothing in this proposal prevents sites from using the Secure Neighbour Discovery (SEND) proposal for authenticating IPv6 Neighbour Discovery. [RFC 3971] 13.7 Site Topology Obfuscation A site that wishes to obscure its internal topology information MAY do so by deploying site border routers that rewrite the Locator values for the site as packets enter or leave the site. For example, a site might choose to use a ULA prefix internally for this reason.[RFC 4193] [ID-ULA] In this case, the site border routers would rewrite the Source Locator of ILNP packets leaving the site to a global-scope Locator associated with the site. Also, those site border routers would rewrite the Destination Locator of packets entering the site from the global-scope Locator to an appropriate interior ULA Locator for the destination node.[MILCOM08] 13.8 Path Liveness Some perceive that an Identifier-Locator Split architecture creates a new issue that is sometimes called "Locator Liveness" or "Path Liveness". This refers to the question of whether an IP packet with a particular destination Locator value will be able to reach the intended destination or not, given that some otherwise valid paths might be unusable by the sending node Atkinson Expires in 6 months [Page 30] Internet Draft ILNP Intro 7 JUN 2011 (e.g. due to security policy or other administrative choice). In fact, this issue has existed in the IPv4 Internet for decades. For example, an IPv4 server might have multiple valid IP addresses, each advertised to the world via an DNS "A" record. However, at a given moment in time, it is possible that a given sending node might not be able to use a given (otherwise valid) destination IPv4 address in an IP packet to reach that IPv4 server. So we see that using an Identifier/Locator Split architecture does not create this issue, nor does it make this issue worse than it is with the deployed IPv4 Internet. In ILNP, the same conceptual approach described in [RFC 5534] can be reused. Alternatively, an ILNP node can reuse the existing IPv4 methods for determining whether a given path to the target destination is currently usable, which existing methods leverage transport-layer session state information that the communicating end systems are already keeping for transport-layer protocol reasons. Last, it is important for the reader to understand that the mechanism described in [ILNP-ICMP] is a performance optimisation, significantly shortening the layer-3 handoff time if/when a correspondent changes location. Architecturally, using ICMP is no different from using UDP, of course. 14. IANA CONSIDERATIONS This document has no IANA considerations. 15. REFERENCES This section provides both normative and informative references relating to this note. 15.1. Normative References [RFC 826] D. Plummer, "Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48 bit Ethernet Address for Transmission on Ethernet Hardware", RFC 826, November 1982. [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Atkinson Expires in 6 months [Page 31] Internet Draft ILNP Intro 7 JUN 2011 [RFC 2460] S. Deering & R. Hinden, "Internet Protocol Version 6 Specification", RFC-2460, December 1998. [RFC 3007] B. Wellington, "Secure Domain Name System Dynamic Update", RFC-3007, November 2000. [RFC 3484] R. Draves, "Derfault Address Selection for IPv6", RFC 3484, February 2003. [RFC 4033] R. Arends, et alia, "DNS Security Introduction and Requirements", RFC-4033, March 2005. [RFC 4219] R. Hinden & S. Deering, "IP Version 6 Addressing Architecture", RFC-4219, February 2006. [RFC 4861] T. Narten, E. Nordmark, W. Simpson, & H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. 15.2. Informative References [8+8] M. O'Dell, "8+8 - An Alternate Addressing Architecture for IPv6", Internet-Draft, October 1996. [Bhatti10] S. Bhatti, "Reducing DNS Caching (or 'How low can we go ?')", Presentation to 38th JANET Networkshop, 31st March 2010, UK Joint Academic Network (JANET), University of Manchester, Manchester, England, UK. [CA-1995-01] US CERT, "IP Spoofing Attacks and Hijacked Terminal Connections", CERT Advisory 1995-01, Issued 23 JAN 1995, Revised 23 SEP 1997. [GSE] M. O'Dell, "GSE - An Alternate Addressing Architecture for IPv6", Internet-Draft, February 1997. [ID-ULA] R. Hinden, G. Huston, & T. Narten, "Centrally Assigned Unique Local IPv6 Unicast Addresses", draft-ietf-ipv6-ula-central-02.txt, 15 June 2007. [ID-Referral] B. Carpenter and others, "A Generic Referral Object for Internet Entities", draft-carpenter-behave-referral-object-01, Atkinson Expires in 6 months [Page 32] Internet Draft ILNP Intro 7 JUN 2011 20 October 2009. [IEEE-EUI] IEEE Standards Association, "Guidelines for 64-bit Global Identifier (EUI-64)", IEEE, 2007. [IEN 1] C.J. Bennett, S.W. Edge, & A.J. Hinchley, "Issues in the Interconnection of Datagram Networks", Internet Experiment Note (IEN) 1, INDRA Note 637, PSPWN 76, University College London, London, England, UK, WC1E 6BT, 29 July 1977. http://www.postel.org/ien/ien001.pdf [IEN 19] J. F. Shoch, "Inter-Network Naming, Addressing, and Routing", IEN-19, January 1978. [IEN 23] J. F. Shoch, "On Names, Addresses, and Routings", IEN-23, January 1978. [IEN 31] D. Cohen, "On Names, Addresses, and Routings (II)", IEN-31, April 1978. [ILNP-Nonce] R. Atkinson, "Nonce Destination Option", draft-rja-ilnp-nonce-05.txt, August 2010. [ILNP-DNS] R. Atkinson, "DNS Resource Records for ILNP", draft-rja-ilnp-dns-06.txt, August 2010. [ILNP-ICMP] R. Atkinson, "ICMP Locator Update message" draft-rja-ilnp-icmp-04.txt, August 2010. [IPng95] D. Clark, "A thought on addressing", electronic mail message to IETF IPng WG, Message-ID: 9501111901.AA28426@caraway.lcs.mit.edu, Laboratory for Computer Science, MIT, Cambridge, MA, USA, 11 January 1995. [Liu-DNS] C. Liu & P. Albitz, "DNS & Bind", 5th Edition, O'Reilly & Associates, Sebastopol, CA, USA, May 2006. ISBN 0-596-10057-4 [MobiArch07] R. Atkinson, S. Bhatti, & S. Hailes, "Mobility as an Integrated Service Through the Use of Naming", Proceedings of ACM MobiArch 2007, August 2007, Kyoto, Japan. Atkinson Expires in 6 months [Page 33] Internet Draft ILNP Intro 7 JUN 2011 [MobiArch08] R. Atkinson, S. Bhatti, & S. Hailes, "Mobility Through Naming: Impact on DNS", Proceedings of ACM MobiArch 2008, August 2008, Seattle, WA, USA. [MobiWAC07] R. Atkinson, S. Bhatti, & S. Hailes, "A Proposal for Unifying Mobility with Multi-Homing, NAT, & Security", Proceedings of ACM MobiWAC 2007, Chania, Crete. ACM, October 2007. [MILCOM08] R. Atkinson, S. Bhatti, & S. Hailes, "Harmonised Resilience, Security, and Mobility Capability for IP", Proceedings of IEEE Military Communications (MILCOM) Conference, San Diego, CA, USA, November 2008. [MILCOM09] R. Atkinson, S. Bhatti, & S. Hailes, "Site-Controlled Secure Multi-Homing and Traffic Engineering For IP", Proceedings of IEEE Military Communications (MILCOM) Conference, Boston, MA, USA, October 2009. [PHG02] Pappas, A, S. Hailes, & R. Giaffreda, "Mobile Host Location Tracking through DNS", Proceedings of IEEE London Communications Symposium, IEEE, September 2002, London, England, UK. [SBK2002] Alex C. Snoeren, Hari Balakrishnan, & M. Frans Kaashoek, "Reconsidering Internet Mobility", Proceedings of 8th Workshop on Hot Topics in Operating Systems, 2002. [SIPP94] Bob Smart, "Re: IPng Directorate meeting in Chicago; possible SIPP changes", electronic mail to the IETF SIPP WG mailing list, Message-ID: 199406020647.AA09887@shark.mel.dit.csiro.au, Commonwealth Scientific & Industrial Research Organisation (CSIRO), Melbourne, VIC, 3001, Australia, 2 June 1994. [RFC 814] D.D. Clark, "Names, Addresses, Ports, and Routes", RFC-814, July 1982. [RFC 1498] J.H. Saltzer, "On the Naming and Binding of Network Destinations", RFC-1498, August 1993. Atkinson Expires in 6 months [Page 34] Internet Draft ILNP Intro 7 JUN 2011 [RFC 1631] K. Egevang & P. Francis, "The IP Network Address Translator (NAT)", RFC-1631, May 1994. [RFC 2827] P. Ferguson & D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", RFC-2827, May 2000. [RFC 3022] P. Srisuresh & K. Egevang, "Traditional IP Network Address Translator", RFC-3022, January 2001. [RFC 3027] M. Holdrege and P Srisuresh, "Protocol Complications of the IP Network Address Translator", RFC-3027, January 2001. [RFC 3704] F. Baker & P. Savola, "Ingress Filtering for Multihomed Networks, RFC-3704, March 2004. [RFC 3715] B. Aboba and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC-3715, March 2004. [RFC 3775] D. Johnson, C. Perkins, and J. Arkko, "Mobility Support in IPv6", RFC-3775, June 2004. [RFC 3948] A. Huttunen, et alia, "UDP Encapsulation of IPsec ESP Packets", RFC-3948, January 2005. [RFC 3971] J. Arkko, J. Kempf, B. Zill, & P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC-3971 March 2005. [RFC 3972] T. Aura, "Cryptographically Generated Addresses (CGAs)", RFC-3972, March 2005. [RFC 4193] R. Hinden & B. Haberman, "Unique Local IPv6 Unicast Addresses, RFC-4193, October 2005. [RFC 4941] T. Narten, R. Draves, & S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC-4941, September 2007. [RFC 5061] R. Stewart, Q. Xie, M. Tuexen, S. Maruyama, & M. Kozuka, "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", RFC-5061, September 2007. [RFC 5534] J. Arkko & I. van Beijnum, "Failure Detection and Atkinson Expires in 6 months [Page 35] Internet Draft ILNP Intro 7 JUN 2011 Locator Pair Exploration Protocol for IPv6 Multihoming", RFC-5534, June 2009. [TeleSys] R. Atkinson, S. Bhatti, & S. Hailes, "ILNP: Mobility, Multi-Homing, Localised Addressing and Security Through Naming", Telecommunications Systems, Volume 42, Number 3-4, pp 273-291, Springer-Verlag, December 2009, ISSN 1018-4864. ACKNOWLEDGEMENTS Steve Blake, Mohamed Boucadair, Saleem Bhatti, Noel Chiappa, Steve Hailes, Joel Halpern, Mark Handley, Volker Hilt, Paul Jakma, Dae-Young Kim, Tony Li, Yakov Rehkter and Robin Whittle (in alphabetical order) provided review and feedback on earlier versions of this document. Steve Blake provided an especially thorough review of the entire ILNP document set, which was extremely helpful. Noel Chiappa graciously provided the author with copies of the original email messages cited here as [SIPP94] and [IPng95], which enabled the precise citation of those messages herein. Author's Address RJ Atkinson Consultant McLean, VA 22103 USA Email: rja.lists@gmail.com Expires: 7 JUN 2011 Atkinson Expires in 6 months [Page 36]