Internet Draft R. Atkinson draft-rja-ilnp-intro-00.txt Extreme Networks Category: Experimental Expires April 2007 16 February 2008 ILNP Concept of Operations draft-rja-ilnp-intro-00.txt Status of this Memo Distribution of this memo is unlimited. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 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. Abstract This document is a contribution to the IRTF Routing Research Group. It is NOT a contribution to the IETF or to any IETF Working Group or to any IETF Area. This documents the Concept of Operations for an experimental extension to IPv6 which is known as the Identifier Locator network protocol. Atkinson Expires August 2008 [Page 1]
Internet Draft ILNP Intro 16 February 2008 Table of Contents 1. Introduction ....................................................2 2. Transport Protocols..............................................4 3. Multi-Homing.....................................................5 4. Mobility.........................................................5 5. Localised Addressing.............................................6 6. IP Security Enhancements.........................................6 7. Backwards Compatibility & Incremental Deployment.................7 8. Security Considerations .........................................8 9. IANA Considerations .............................................9 10. References ......................................................9 1. Introduction At present, the IRTF Routing Research Group is studying different approaches to evolving the Internet Architecture. Several different classes of evolution are being considered. 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 evoluationary approaches. This architectural concept derives originally from a note by Dave Clark to the IETF mailing list suggesting that the IPv6 address be split into separate Identifier and Locator fields. Afterwards, Mike O'Dell persued this concept in Internet-Drafts describing "GSE" or "8+8".[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 antecedant work). This current proposal differs from O'Dell's work in various ways. The crux of this proposal is to split each 128-bit IPv6 address into two separate fields, with crisp semantics for each. It is worth remembering here that an IPv6 address names a specific interface on a node, since the new scheme will be different in that regard. Atkinson Expires August 2008 [Page 2]
Internet Draft ILNP Intro 16 February 2008 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 | + + | | + + | | + + | | +---------------+-----------------+----------------+---------------+ 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. The low-order 64-bits of the IPv6 address become the Identifier. The Identifier provides a fixed-length identity for a node, rather than an identity for a specific interface of a node. Identifiers are bound to nodes, not to interfaces, and are in the same modified EUI-64 syntax already specified for IPv6. Identifiers are unique within the context of a given Locator; in many cases, Identifiers might happen to be globally unique, but that is not a functional requirement for this proposal. 1 1 2 3 0 4 8 2 6 4 1 +---------------+-----------------+----------------+---------------+ | Version| Traffic Class | Flow Label | +---------------+-----------------+----------------+---------------+ | Payload Length | Next Header | Hop Limit | +---------------+-----------------+----------------+---------------+ Atkinson Expires August 2008 [Page 3]
Internet Draft ILNP Intro 16 February 2008 | Source Locator | + + | | +---------------+-----------------+----------------+---------------+ | Source Identifier | + + | | +---------------+-----------------+----------------+---------------+ | Destination Locator | + + | | +---------------+-----------------+----------------+---------------+ | Destination Identifier | + + | | +---------------+-----------------+----------------+---------------+ Figure 2: Enhanced IPv6 Header Most commonly, a node's set of Identifiers are derived from the IEEE 802 or IEEE 1394 MAC addresses associated with that node. This use of MAC addresses to generate Identifiers is convenient and is not required. Other methods also might be used to generate Identifiers. So this proposal enhances the architecture by adding crisp clear semantics for the Identifier and for the Locator, removing the semantically muddled IP address, and updating end system protocols slightly, without requiring router changes. With these enhancements, we have improved architectural support not only for multi-homing, but also for mobility, localised addressing, and IP Security. 2. Transport Protocols At present, transport protocols include a pseudo-header that includes certain network-layer fields, the IP addresses for the session, in its calculation. With this proposal, transport protocols include 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 an IP session, the network layer zeros the Locator fields before passing the information up to the transport protocol in use. Atkinson Expires August 2008 [Page 4]
Internet Draft ILNP Intro 16 February 2008 3. 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. 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 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-omain routing system (e.g. RIB/FIB size increases beyond the minimal RIB/FIB size that would be required to reach all sites). When a node is multi-homed, it 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. The node also will use Secure Dynamic DNS Update to alter the set of currently valid L records associated with that node. This second step ensures that any new correspondents can reach the node.[ILNP-ICMP] Site multi-homing works in a similar manner, with nodes having one Locator for each upstream connection to the Internet. To avoid a DNS Update burst when a site or subnetwork moves location, a DNS record optimisation is possible. This would change the number of DNS Updates required from O(number of nodes at the site/subnetwork that moved) to O(1). 4. Mobility There are no standardised mechanisms to update transport protocols with new IP addresses in use for the session (SCTP might be an exception, depending on the progress of a current Internet-Draft). 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. So, the several approaches Atkinson Expires August 2008 [Page 5]
Internet Draft ILNP Intro 16 February 2008 to Mobile IP seek to hide the change in location (and corresponding change in IP addresses) via tunnelling, home agents, foreign agents, and so forth. All of this can add substantial complexity to IP mobility approaches. By contrast, this new proposal hides the nodes location information from the transport layer protocols at all times. In this proposal, mobility is supported using the same mechanisms as multihoming. That is, the us of Locator values to identify different IP subnetworks. 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 to correct the set of L records in the DNS for that node. This enables any new correspondents to correctly initiate a new session with the node at its new location. Note that we can (and do) treat network mobility (as well as node mobility) as 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. 5. Localised Addressing As the Locator value no longer forms part of the node session state (e.g. TCP pseudo-header), it is easier to implement localised addressing based on the use of local values of the Locator. This would be either in place of, or to supplement, existing NAT-based schemes. 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 so a true end-to-end session can be maintained. Note that localised addressing would work in harmony with multihoming, mobility, and IP Security. 6. IP Security Enhancements The IP Security protocols, AH and ESP, should be enhanced to bind Security Associations only to Identifier values and never to Locator values Atkinson Expires August 2008 [Page 6]
Internet Draft ILNP Intro 16 February 2008 (and not to an entire 128 bit IPv6 address). This small change enables IPsec to work in harmony with multihoming, mobility, and localised addressing. Further, it would obviate the need for specialised IPsec NAT Traversal mechanisms, thus simplifying IPsec implementations while enhancing deployability and interoperability. 7. Backwards Compatibility & Incremental Deployment First, if one comapres 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. Further, IPv6 Neighbour Discovery should work fine without any significant protocol changes. 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 I records and one or more L records associated with it in 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 ("I") and Locator ("L") records in any received DNS replies. DNS servers that support I and L 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 session cache, 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 August 2008 [Page 7]
Internet Draft ILNP Intro 16 February 2008 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. If the responder does not 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. If the initiator does not receive a response from the 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 should try again to create the new IP session but this time OMITTING the Nonce Destination Option. 8. Security Considerations This proposal defines a new non-cryptographic Nonce Destination Option. 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. 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 included in any ICMP control messages (e.g. ICMP Unreachable, ICMP Locator Update) sent with regard to that IP session. 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. Atkinson Expires August 2008 [Page 8]
Internet Draft ILNP Intro 16 February 2008 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. 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. 9. IANA Considerations This document has no IANA considerations. 10. References This section provides both normative and informative references relating to this note. 10.1. Normative References None at this time. 10.2. Informative References [8+8] M. O'Dell, "8+8 - An Alternate Addressing Architecture for IPv6", Internet-Draft, October 1996. [ABH07] 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. [Clark82] D.D. Clark, "Names, Addresses, Ports, and Routes", RFC-814, July 1982. [GSE] M. O'Dell, "GSE - An Alternate Addressing Architecture for IPv6", Internet-Draft, February 1997. [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", February 2008. [ILNP-DNS] R. Atkinson, "DNS Resource Records for Identifier/Locator Use", February 2008. [ILNP-ICMP] R. Atkinson, "ICMP Locator Update message" Atkinson Expires August 2008 [Page 9]
Internet Draft ILNP Intro 16 February 2008 February 2008. [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. [Saltzer93] Saltzer, J, "On the Naming and Binding of Network Destinations", RFC-1498, August 1993. (Additional references to be added later.) Author's Address R. Atkinson Extreme Networks 3585 Monroe Street Santa Clara, CA 95051 USA Telephone: +1 (408)579-2800 Email: rja@extremenetworks.com Atkinson Expires August 2008 [Page 10]
Internet Draft ILNP Intro 16 February 2008 Full Copyright Statement "Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights." "This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. This document may not be modified, and derivative works of it may not be created. This document may only be posted in an Internet-Draft. Atkinson Expires August 2008 [Page 11]