summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6745.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6745.txt')
-rw-r--r--doc/rfc/rfc6745.txt675
1 files changed, 675 insertions, 0 deletions
diff --git a/doc/rfc/rfc6745.txt b/doc/rfc/rfc6745.txt
new file mode 100644
index 0000000..933d342
--- /dev/null
+++ b/doc/rfc/rfc6745.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Internet Research Task Force (IRTF) RJ Atkinson
+Request for Comments: 6745 Consultant
+Category: Experimental SN Bhatti
+ISSN: 2070-1721 U. St Andrews
+ November 2012
+
+
+ ICMP Locator Update Message for the
+ Identifier-Locator Network Protocol for IPv4 (ILNPv4)
+
+Abstract
+
+ This note defines an experimental ICMP message type for IPv4 used
+ with the Identifier-Locator Network Protocol (ILNP). ILNP is an
+ experimental, evolutionary enhancement to IP. The ICMP message
+ defined herein is used to dynamically update Identifier/Locator
+ bindings for an existing ILNP session. This is a product of the IRTF
+ Routing Research Group.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for examination, experimental implementation, and
+ evaluation.
+
+ This document defines an Experimental Protocol for the Internet
+ community. This document is a product of the Internet Research Task
+ Force (IRTF). The IRTF publishes the results of Internet-related
+ research and development activities. These results might not be
+ suitable for deployment. This RFC represents the individual
+ opinion(s) of one or more members of the Routing Research Group of
+ the Internet Research Task Force (IRTF). Documents approved for
+ publication by the IRSG are not a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6745.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Atkinson & Bhatti Experimental [Page 1]
+
+RFC 6745 ILNPv4 ICMP November 2012
+
+
+Copyright Notice
+
+ Copyright (c) 2012 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document.
+
+ This document may not be modified, and derivative works of it may not
+ be created, except to format it for publication as an RFC or to
+ translate it into languages other than English.
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 1.1. Document Roadmap ...........................................3
+ 1.2. ICMPv4 Locator Update ......................................4
+ 1.3. Terminology ................................................5
+ 2. ICMP Locator Update Message for ILNPv4 ..........................5
+ 3. Transport Protocol Effects ......................................8
+ 4. Implementation Considerations ...................................8
+ 5. Backwards Compatibility .........................................9
+ 6. Security Considerations .........................................9
+ 7. IANA Considerations ............................................10
+ 8. References .....................................................10
+ 8.1. Normative References ......................................10
+ 8.2. Informative References ....................................11
+ 9. Acknowledgements ...............................................11
+
+1. Introduction
+
+ This document is part of the ILNP document set, which has had
+ extensive review within the IRTF Routing RG. ILNP is one of the
+ recommendations made by the RG Chairs. Separately, various refereed
+ research papers on ILNP have also been published during this decade.
+ So the ideas contained herein have had much broader review than the
+ IRTF Routing RG. The views in this document were considered
+ controversial by the Routing RG, but the RG reached a consensus that
+ the document still should be published. The Routing RG has had
+ remarkably little consensus on anything, so virtually all Routing RG
+ outputs are considered controversial.
+
+
+
+
+
+
+Atkinson & Bhatti Experimental [Page 2]
+
+RFC 6745 ILNPv4 ICMP November 2012
+
+
+ At present, the Internet research and development community is
+ exploring various approaches to evolving the Internet Architecture to
+ solve a variety of issues including, but not limited to, scalability
+ of inter-domain routing [RFC4984]. A wide range of other issues
+ (e.g., site multihoming, node multihoming, site/subnet mobility, node
+ mobility) are also active concerns at present. Several different
+ classes of evolution are being considered by the Internet research
+ and development community. One class is often called "Map and
+ Encapsulate", where traffic would be mapped and then tunnelled
+ through the inter-domain core of the Internet. Another class being
+ considered is sometimes known as "Identifier/Locator Split". This
+ document relates to a proposal that is in the latter class of
+ evolutionary approaches.
+
+ The Identifier-Locator Network Protocol (ILNP) is a proposal for
+ evolving the Internet Architecture. It differs from the current
+ Internet Architecture primarily by deprecating the concept of an IP
+ Address and instead defining two new objects, each having crisp
+ syntax and semantics. The first new object is the Locator, a
+ topology-dependent name for a subnetwork. The other new object is
+ the Identifier, which provides a topology-independent name for a
+ node.
+
+1.1. Document Roadmap
+
+ This document describes a new ICMPv4 Locator Update message used by
+ an ILNP node to inform its correspondent nodes of any changes to its
+ set of valid Locators.
+
+ The ILNP architecture can have more than one engineering
+ instantiation. For example, one can imagine a "clean-slate"
+ engineering design based on the ILNP architecture. In separate
+ documents, we describe two specific engineering instances of ILNP.
+ The term "ILNPv6" refers precisely to an instance of ILNP that is
+ based upon, and is backwards compatible with, IPv6. The term
+ "ILNPv4" refers precisely to an instance of ILNP that is based upon,
+ and backwards compatible with, IPv4.
+
+ Many engineering aspects common to both ILNPv4 and ILNPv6 are
+ described in [RFC6741]. A full engineering specification for either
+ ILNPv6 or ILNPv4 is beyond the scope of this document.
+
+ Readers are referred to other related ILNP documents for details not
+ described here:
+
+ a) [RFC6740] is the main architectural description of ILNP, including
+ the concept of operations.
+
+
+
+
+Atkinson & Bhatti Experimental [Page 3]
+
+RFC 6745 ILNPv4 ICMP November 2012
+
+
+ b) [RFC6741] describes engineering and implementation considerations
+ that are common to both ILNPv4 and ILNPv6.
+
+ c) [RFC6742] defines additional DNS resource records that support
+ ILNP.
+
+ d) [RFC6743] defines a new ICMPv6 Locator Update message used by an
+ ILNP node to inform its correspondent nodes of any changes to its
+ set of valid Locators.
+
+ e) [RFC6744] defines a new IPv6 Nonce Destination Option used by
+ ILNPv6 nodes (1) to indicate to ILNP correspondent nodes (by
+ inclusion within the initial packets of an ILNP session) that the
+ node is operating in the ILNP mode and (2) to prevent off-path
+ attacks against ILNP ICMP messages. This Nonce is used, for
+ example, with all ILNP ICMPv6 Locator Update messages that are
+ exchanged among ILNP correspondent nodes.
+
+ f) [RFC6746] defines a new IPv4 Nonce Option used by ILNPv4 nodes to
+ carry a security nonce to prevent off-path attacks against ILNP
+ ICMP messages, and it also defines a new IPv4 Identifier Option
+ used by ILNPv4 nodes.
+
+ g) [RFC6747] describes extensions to Address Resolution Protocol
+ (ARP) for use with ILNPv4.
+
+ h) [RFC6748] describes optional engineering and deployment functions
+ for ILNP. These are not required for the operation or use of ILNP
+ and are provided as additional options.
+
+1.2. ICMPv4 Locator Update
+
+ As described in [RFC6740] and [RFC6741], an ILNP for IPv4 (ILNPv4)
+ node might need to inform correspondent ILNPv4 nodes of changes to
+ the set of valid Locator values. The new ICMPv4 Locator Update
+ message described in this document enables an ILNP-capable node to
+ update its correspondents about the currently valid set of Locators
+ valid to use in reaching the node sending this message [RFC2460]
+ [RFC4443].
+
+ This new ICMPv4 message MUST ONLY be used for ILNPv4 sessions.
+ Authentication is always required, as described in the Security
+ Considerations section later in this document.
+
+ Some might consider any and all use of ICMP to be undesirable.
+
+
+
+
+
+
+Atkinson & Bhatti Experimental [Page 4]
+
+RFC 6745 ILNPv4 ICMP November 2012
+
+
+ In that context, please note that while this specification uses ICMP,
+ on grounds that this is a control message, there is no architectural
+ difference between using ICMP and using some different framing, for
+ example UDP.
+
+1.3. Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+2. ICMP Locator Update Message for ILNPv4
+
+ The ICMP for IPv4 message described in this section has ICMP Type 253
+ (as defined for experimental use in Section 8 of [RFC4727]) and is
+ used ONLY with a current ILNPv4 session. This message enables an
+ ILNPv4 node to advertise changes to the active Locator set for the
+ ILNPv4 node that originates this message to its unicast ILNP
+ correspondent nodes. It also enables those correspondents to
+ acknowledge receipt of the advertisement.
+
+ This particular ICMP for IPv4 message MUST ONLY be used with ILNPv4
+ sessions. The Checksum field for this message is calculated
+ identically as for any other IPv4 ICMP message.
+
+ ICMP Locator Update message
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Code | Checksum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Num of Locs | Operation | RESERVED |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ / Locator [1] /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Preference [1] | Lifetime [1] |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ / Locator [2] /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Preference [2] | Lifetime [2] |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+Atkinson & Bhatti Experimental [Page 5]
+
+RFC 6745 ILNPv4 ICMP November 2012
+
+
+ ICMP Fields:
+
+ Type 253
+ This type value is taken from Section 8
+ of [RFC4727] and is allocated for
+ experimental use.
+
+ Code 0
+
+ Checksum The 16-bit one's complement of the
+ one's complement sum of the ICMP
+ message, starting with the ICMP Type.
+ For computing the checksum, the
+ Checksum field is set to 0.
+
+ Num of Locs The number of 32-bit Locator values
+ that are advertised in this message.
+
+ Locator[i], The 32-bit Locator values currently
+ i = 1..Num of Locs valid for the sending ILNPv4 node.
+
+ Preference[i], The preferability of each Locator[i],
+ i = 1..Num of Locs relative to other valid Locator[i]
+ values. The Preference numbers here
+ are identical, both in syntax and
+ semantics, to the Preference values
+ for L32 records that are specified by
+ [RFC6742].
+
+ Lifetime[i] The maximum number of seconds that this
+ i = 1..Num of Locs particular Locator may be considered
+ valid. Normally, this is identical
+ to the DNS lifetime of the
+ corresponding L32 record, if one
+ exists.
+
+ Operation The value in this field indicates
+ whether this is a Locator Update
+ Advertisement (0x01) or a Locator
+ Update Acknowledgement (0x02).
+
+ RESERVED A field reserved for possible future
+ use. At present, the sender MUST
+ initialise this field to zero.
+ Receivers should ignore this field at
+ present. The field might be used for
+ some protocol function in future.
+
+
+
+
+Atkinson & Bhatti Experimental [Page 6]
+
+RFC 6745 ILNPv4 ICMP November 2012
+
+
+ NOTE WELL: The ICMP Type value is allocated for shared
+ experimental use in Section 8 of [RFC4727].
+ It is not uniquely assigned to ILNPv4. So,
+ implementations need to code particularly
+ defensively as other IPv4 experiments might be
+ using this same ICMP Type value for an
+ entirely different purpose with a different
+ ICMP packet format.
+
+ The Operation field has value 1 (hexadecimal 0x01) for a Locator
+ Update Advertisement. The Operation field has value 2 (hexadecimal
+ 0x02) for a Locator Update Acknowledgement. All other values of the
+ Operation field are reserved for future use by future revisions of
+ this specification.
+
+ A node whose set of valid Locators has changed MUST send Locator
+ Update Advertisement messages to each correspondent node for each
+ active unicast ILNP session. For unicast ILNP sessions, the receiver
+ of a valid (i.e., authentication checks all passed, advertisement is
+ received from a current correspondent node) Locator Update
+ Advertisement addressed to the receiver MUST send a Locator Update
+ Acknowledgement back to the sender of the Locator Update
+ Advertisement. The Acknowledgement message body is identical to the
+ received Advertisement message body, except for the Operation value.
+
+ All ILNPv4 ICMP Locator Update messages MUST contain a valid ILNPv4
+ Identifier Option and MUST contain an ILNPv4 Nonce Option.
+
+ ILNPv4 ICMP Locator Update messages also MAY be protected using IP
+ Security for ILNP [RFC6741] [RFC4301]. Deployments in high-threat
+ environments SHOULD also protect ILNPv4 ICMP Locator Update messages
+ using IPsec. While IPsec Encapsulating Security Payload (ESP) can
+ protect a payload, no form of IPsec ESP is able to protect an IPv4
+ Option that appears prior to the ESP header. Note that even when IP
+ Security for ILNP is in use, the ILNPv4 Nonce Option still MUST be
+ present. This simplifies protocol processing, and it also means that
+ a receiver can perform the inexpensive check of the Nonce value
+ before performing any (potentially expensive) cryptographic
+ calculation.
+
+
+
+
+
+
+
+
+
+
+
+
+Atkinson & Bhatti Experimental [Page 7]
+
+RFC 6745 ILNPv4 ICMP November 2012
+
+
+3. Transport Protocol Effects
+
+ The ICMP Locator Update message has no impact on any transport
+ protocol.
+
+ The ICMP Locator Update message might affect where packets for a
+ given transport-layer session are sent, but an ILNP design objective
+ is to decouple transport protocols (e.g., TCP, UDP, SCTP) and
+ transport-layer sessions network-layer changes.
+
+4. Implementation Considerations
+
+ Implementers may use any internal implementation they wish, provided
+ that the external appearance is the same as this implementation
+ approach.
+
+ To support ILNPv4, and to retain the incremental deployability and
+ backwards compatibility needed, the network layer needs a mode bit in
+ the Transport Control Block (or its equivalent) to track which IP
+ sessions are using the classic IPv4 mode and which IP sessions are
+ using ILNPv4 mode.
+
+ Further, when supporting ILNPv4, nodes will need to support a
+ Identifier Locator Communication Cache (ILCC) in the network layer as
+ described in [RFC6741].
+
+ A node sending an ICMP Locator Update message MUST include all
+ currently valid Locator values in that message. A node receiving a
+ valid ICMP Locator Update message MUST replace the previously current
+ set of Locator values for that correspondent node in its own ILCC
+ with the newly received set of Locator values.
+
+ Every implementation needs to support a large number of Locator
+ values being sent or received in a single ICMP Locator Update
+ message, because a multihomed node or multihomed site might have a
+ large number of upstream links to different service providers, each
+ with its own Locator value.
+
+ It should be noted that as the ICMP Type uses an experimental value
+ from [RFC4727], care should be taken when using with other protocols
+ also using experimental values.
+
+
+
+
+
+
+
+
+
+
+Atkinson & Bhatti Experimental [Page 8]
+
+RFC 6745 ILNPv4 ICMP November 2012
+
+
+5. Backwards Compatibility
+
+ This IPv4 ICMP message uses the same checksum calculations as any
+ other IPv4 ICMP message.
+
+ When ILNPv4 is not in use, the receiving IPv4 mode MUST discard the
+ ICMP Locator Update packet without processing the packet.
+
+6. Security Considerations
+
+ Security considerations for the overall ILNP Architecture are
+ described in [RFC6740]. Additional common security considerations
+ are described in [RFC6741]. This section describes security
+ considerations specific to ILNPv4 topics discussed in this document.
+
+ The ICMPv4 Locator Update message MUST ONLY be used for ILNPv4
+ sessions.
+
+ The ILNPv4 Nonce Option [RFC6746] MUST be present in packets
+ containing an ICMPv4 Locator Update message. Further, the received
+ Nonce Destination Option must contain the correct nonce value for the
+ packet to be accepted by the recipient and then passed to the ICMPv4
+ protocol for processing. If either of these requirements are not
+ met, the received packet MUST be discarded as a forgery, and a
+ security event SHOULD be logged by the system receiving the non-
+ authentic packet.
+
+ ILNP sessions operating in higher risk environments SHOULD use IP
+ Security for ILNP [RFC6741] [RFC4301] *in addition* to the ILNPv4
+ Nonce Option. Use of IP Security for ILNP to protect a packet does
+ NOT permit the packet to be sent without the Nonce Option.
+
+ Implementations need to support the case where a single ICMP Locator
+ Update message contains a large number of Locator and Preference
+ values and ought not develop a security fault (e.g., stack overflow)
+ due to a received message containing more Locator values than
+ expected.
+
+ If the ILNP Nonce value is predictable, then an off-path attacker
+ might be able to forge data or control packets. This risk also is
+ mitigated by the existing common practice of IP Source Address
+ filtering [RFC2827] [RFC3704].
+
+
+
+
+
+
+
+
+
+Atkinson & Bhatti Experimental [Page 9]
+
+RFC 6745 ILNPv4 ICMP November 2012
+
+
+7. IANA Considerations
+
+ This document makes no request of IANA.
+
+ If in the future the IETF decided to standardise ILNPv4, then
+ allocation of a unique ICMP Type for the Locator Update as part of
+ the IETF standardisation process would be sensible.
+
+8. References
+
+8.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
+ (IPv6) Specification", RFC 2460, December 1998.
+
+ [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
+ Control Message Protocol (ICMPv6) for the Internet
+ Protocol Version 6 (IPv6) Specification", RFC 4443, March
+ 2006.
+
+ [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
+ Internet Protocol", RFC 4301, December 2005.
+
+ [RFC4727] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC
+ 4272, January 2006.
+
+ [RFC6740] Atkinson, R. and S. Bhatti, "Identifier-Locator Network
+ Protocol (ILNP) Architectural Description", RFC 6740,
+ November 2012.
+
+ [RFC6747] Atkinson, R. and S. Bhatti, "Address Resolution Protocol
+ (ARP) Extension for the Identifier-Locator Network
+ Protocol for IPv4 (ILNPv4)", RFC 6747, November 2012.
+
+ [RFC6741] Atkinson, R. and S. Bhatti, "Identifier-Locator Network
+ Protocol (ILNP) Engineering and Implementation
+ Considerations", RFC 6741, November 2012.
+
+ [RFC6746] Atkinson, R. and S.Bhatti, "IPv4 Options for the
+ Identifier-Locator Network Protocol (ILNP)", RFC 6746,
+ November 2012.
+
+
+
+
+
+
+
+Atkinson & Bhatti Experimental [Page 10]
+
+RFC 6745 ILNPv4 ICMP November 2012
+
+
+8.2. Informative References
+
+ [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
+ Defeating Denial of Service Attacks which employ IP
+ Source Address Spoofing", BCP 38, RFC 2827, May 2000.
+
+ [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for
+ Multihomed Networks", BCP 84, RFC 3704, March 2004.
+
+ [RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report
+ from the IAB Workshop on Routing and Addressing", RFC
+ 4984, September 2007.
+
+ [RFC6742] Atkinson, R., Bhatti, S. and S. Rose, "DNS Resource
+ Records for the Identifier-Locator Network Protocol
+ (ILNP)", RFC 6742, November 2012.
+
+ [RFC6748] Atkinson, R. and S. Bhatti, "Optional Advanced Deployment
+ Scenarios for the Identifier-Locator Network Protocol
+ (ILNP)", RFC 6748, November 2012.
+
+ [RFC6743] Atkinson, R. and S. Bhatti, "ICMPv6 Locator Update
+ Message", RFC 6743, November 2012.
+
+ [RFC6744] Atkinson, R. and S. Bhatti, "IPv6 Nonce Destination
+ Option for the Identifier-Locator Network Protocol for
+ IPv6 (ILNPv6)", RFC 6744, November 2012.
+
+9. Acknowledgements
+
+ Steve Blake, Stephane Bortzmeyer, Mohamed Boucadair, Noel Chiappa,
+ Wes George, Steve Hailes, Joel Halpern, Mark Handley, Volker Hilt,
+ Paul Jakma, Dae-Young Kim, Tony Li, Yakov Rehkter, Bruce Simpson,
+ Robin Whittle, and John Wroclawski (in alphabetical order) provided
+ review and feedback on earlier versions of this document. Steve
+ Blake provided an especially thorough review of an early version of
+ the entire ILNP document set, which was extremely helpful. We also
+ wish to thank the anonymous reviewers of the various ILNP papers for
+ their feedback.
+
+ Roy Arends provided expert guidance on technical and procedural
+ aspects of DNS issues.
+
+
+
+
+
+
+
+
+
+Atkinson & Bhatti Experimental [Page 11]
+
+RFC 6745 ILNPv4 ICMP November 2012
+
+
+Authors' Addresses
+
+ RJ Atkinson
+ Consultant
+ San Jose, CA 95125
+ USA
+
+ EMail: rja.lists@gmail.com
+
+
+ SN Bhatti
+ School of Computer Science
+ University of St Andrews
+ North Haugh, St Andrews
+ Fife KY16 9SX
+ Scotland, UK
+
+ EMail: saleem@cs.st-andrews.ac.uk
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Atkinson & Bhatti Experimental [Page 12]
+