summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6743.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6743.txt')
-rw-r--r--doc/rfc/rfc6743.txt675
1 files changed, 675 insertions, 0 deletions
diff --git a/doc/rfc/rfc6743.txt b/doc/rfc/rfc6743.txt
new file mode 100644
index 0000000..8d2fe36
--- /dev/null
+++ b/doc/rfc/rfc6743.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Internet Research Task Force (IRTF) RJ Atkinson
+Request for Comments: 6743 Consultant
+Category: Experimental SN Bhatti
+ISSN: 2070-1721 U. St Andrews
+ November 2012
+
+
+ ICMP Locator Update Message for
+ the Identifier-Locator Network Protocol for IPv6 (ILNPv6)
+
+Abstract
+
+ This note specifies an experimental ICMPv6 message type used with the
+ Identifier-Locator Network Protocol (ILNP). The Identifier-Locator
+ Network Protocol (ILNP) is an experimental, evolutionary enhancement
+ to IP. This message 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/rfc6743.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Atkinson & Bhatti Experimental [Page 1]
+
+RFC 6743 ILNPv6 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 ....................................................3
+ 1.1. Document Roadmap ...........................................3
+ 1.2. ICMPv6 Locator Update ......................................4
+ 1.3. Terminology ................................................5
+ 2. Syntax ..........................................................5
+ 2.1. Example ICMPv6 Locator Update Message ......................7
+ 3. Transport Protocol Effects ......................................8
+ 4. Implementation Considerations ...................................8
+ 5. Backwards Compatibility .........................................8
+ 6. Security Considerations .........................................9
+ 7. IANA Considerations .............................................9
+ 8. References .....................................................10
+ 8.1. Normative References ......................................10
+ 8.2. Informative References ....................................10
+ 9. Acknowledgements ...............................................11
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Atkinson & Bhatti Experimental [Page 2]
+
+RFC 6743 ILNPv6 ICMP November 2012
+
+
+1. Introduction
+
+ This document is part of the ILNP document set, which has had
+ extensive review within the IRTF Routing RG. ILNP is one of the
+ recommendations made by the RG Chairs. Separately, various refereed
+ research papers on ILNP have also been published during this decade.
+ So, the ideas contained herein have had much broader review than the
+ IRTF Routing RG. The views in this document were considered
+ controversial by the Routing RG, but the RG reached a consensus that
+ the document still should be published. The Routing RG has had
+ remarkably little consensus on anything, so virtually all Routing RG
+ outputs are considered controversial.
+
+ At present, the Internet research and development community are
+ exploring various approaches to evolving the Internet Architecture to
+ solve a variety of issues including, but not limited to, scalability
+ of inter-domain routing [RFC4984]. A wide range of other issues
+ (e.g., site multihoming, node multihoming, site/subnet mobility, node
+ mobility) are also active concerns at present. Several different
+ classes of evolution are being considered by the Internet research
+ and development community. One class is often called "Map and
+ Encapsulate", where traffic would be mapped and then tunnelled
+ through the inter-domain core of the Internet. Another class being
+ considered is sometimes known as "Identifier/Locator Split". This
+ document relates to a proposal that is in the latter class of
+ evolutionary approaches.
+
+1.1. Document Roadmap
+
+ This document 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.
+
+ 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 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:
+
+
+
+Atkinson & Bhatti Experimental [Page 3]
+
+RFC 6743 ILNPv6 ICMP November 2012
+
+
+ a) [RFC6740] is the main architectural description of ILNP, including
+ the concept of operations.
+
+ b) [RFC6741] describes engineering and implementation considerations
+ that are common to both ILNPv4 and ILNPv6.
+
+ c) [RFC6742] defines additional DNS resource records that support
+ ILNP.
+
+ d) [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.
+
+ e) [RFC6745] defines a new ICMPv4 Locator Update message used by an
+ ILNP node to inform its correspondent nodes of any changes to its
+ set of valid Locators.
+
+ 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 also defines a new IPv4 Identifier Option used
+ by ILNPv4 nodes.
+
+ g) [RFC6747] describes extensions to the 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. ICMPv6 Locator Update
+
+ As described in [RFC6740] and [RFC6741], an ILNP for IPv6 (ILNPv6)
+ node might need to inform correspondent ILNPv6 nodes of changes to
+ the set of valid Locator values. The new ICMPv6 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 ICMPv6 message MUST ONLY be used for ILNPv6 sessions.
+ Authentication is always required, as described in the Security
+ Considerations section later in this note.
+
+
+
+
+
+Atkinson & Bhatti Experimental [Page 4]
+
+RFC 6743 ILNPv6 ICMP November 2012
+
+
+ Some might consider any and all use of ICMP to be undesirable. 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 other 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. Syntax
+
+ The ICMPv6 message described in this section has ICMP Type 156 and is
+ used ONLY with a current ILNPv6 session. This message enables an
+ ILNPv6 node to inform ILNPv6 correspondent nodes of changes to the
+ active Locator set for the ILNPv6 node that originates this message.
+ This particular ICMPv6 message MUST ONLY be used with ILNPv6
+ sessions.
+
+ This particular ICMPv6 message MUST ONLY be used with ILNPv6
+ sessions. The Checksum field for this message is calculated
+ identically as for any other ICMPv6 message.
+
+ ICMPv6 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 6743 ILNPv6 ICMP November 2012
+
+
+ ICMPv6 Locator Update fields:
+
+ Type 156
+
+ 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 64-bit Locator values that are
+ advertised in this message. This field MUST
+ NOT be zero.
+
+ Locator[i], The 64-bit Locator values currently
+ i = 1..Num of Locs valid for the sending ILNPv6 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 L64 records as
+ 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 L64 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.
+
+ 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.
+
+
+
+
+Atkinson & Bhatti Experimental [Page 6]
+
+RFC 6743 ILNPv6 ICMP November 2012
+
+
+ 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 Locator Update Advertisement (e.g., authentication checks
+ all passed; advertisement is received from a current correspondent
+ node) 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 ILNPv6 ICMP Locator Update messages MUST contain a valid ILNPv6
+ Identifier option and MUST contain an ILNPv6 Nonce Option.
+
+ ILNPv6 ICMP Locator Update messages also MAY be protected using IP
+ Security for ILNP [RFC6741] [RFC4301]. Deployments in high-threat
+ environments SHOULD also protect ILNPv6 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 IPv6
+ option that appears prior to the ESP header.
+
+ Note that even when IP Security for ILNP is in use, the ILNP 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.
+
+2.1. Example ICMPv6 Locator Update Message
+
+ This example shows the ICMPv6 syntax for the case where 2 Locator
+ values are being indicated.
+
+ 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 | RESERVED | RESERVED |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ / Locator [1] /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Preference [1] | Lifetime [1] |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ / Locator [2] /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Preference [2] | Lifetime [2] |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+Atkinson & Bhatti Experimental [Page 7]
+
+RFC 6743 ILNPv6 ICMP November 2012
+
+
+3. Transport Protocol Effects
+
+ This message has no impact on any transport protocol.
+
+ The message may affect where packets for a given transport-layer
+ session are sent, but an ILNP design objective is to decouple
+ transport-layer protocols and transport-layer session information
+ from 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 ILNPv6, 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 IPv6 mode and which IP sessions are
+ using the Identifier/Locator Split mode.
+
+ Further, when supporting ILNPv4, nodes will need to support an
+ 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.
+
+5. Backwards Compatibility
+
+ This ICMPv6 message uses the same checksum calculations as any other
+ ICMPv6 message.
+
+ When ILNPv6 is not in use, the receiving IPv6 mode MUST discard the
+ ICMP Locator Update packet without processing the packet. This is
+ standard behaviour for a non-ILNPv6 node when receiving an ICMPv6
+ message with an unknown header field value.
+
+
+
+
+
+Atkinson & Bhatti Experimental [Page 8]
+
+RFC 6743 ILNPv6 ICMP November 2012
+
+
+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 ILNPv6 topics discussed in this document.
+
+ The ICMPv6 Locator Update message MUST ONLY be used for ILNPv6
+ sessions.
+
+ The ILNP Nonce Destination Option [RFC6744] MUST be present in
+ packets containing an ICMPv6 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 ICMPv6 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 ILNPv6
+ Nonce Destination Option. Use of IP Security for ILNP to protect a
+ packet does NOT permit the packet to be sent without the Nonce
+ Destination 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].
+
+7. IANA Considerations
+
+ Consistent with the procedures of [RFC4443], IANA has assigned the
+ value 156 to the ICMP Type listed in Section 2.
+
+
+
+
+
+
+
+
+
+
+
+Atkinson & Bhatti Experimental [Page 9]
+
+RFC 6743 ILNPv6 ICMP November 2012
+
+
+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.
+
+ [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for
+ Multihomed Networks", BCP 84, RFC 3704, March 2004.
+
+ [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
+ Internet Protocol", RFC 4301, December 2005.
+
+ [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.
+
+ [RFC6740] Atkinson, R. and S. Bhatti, "Identifier-Locator Network
+ Protocol (ILNP) Architectural Description", RFC 6740,
+ November 2012.
+
+ [RFC6741] Atkinson, R. and S. Bhatti, "Identifier-Locator Network
+ Protocol (ILNP) Engineering and Implementation
+ Considerations", RFC 6741, November 2012.
+
+ [RFC6744] Atkinson, R. and S. Bhatti, "IPv6 Nonce Destination
+ Option for the Identifier-Locator Network Protocol for
+ IPv6 (ILNPv6)", RFC 6744, 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.
+
+ [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.
+
+
+
+
+
+Atkinson & Bhatti Experimental [Page 10]
+
+RFC 6743 ILNPv6 ICMP November 2012
+
+
+ [RFC6745] Atkinson, R. and S. Bhatti, "ICMP Locator Update Message
+ for the Identifier-Locator Network Protocol for IPv4
+ (ILNPv4)", RFC 6745, November 2012.
+
+ [RFC6746] Atkinson, R. and S.Bhatti, "IPv4 Options for the
+ Identifier Locator Network Protocol (ILNP)", RFC 6746,
+ November 2012.
+
+ [RFC6747] Atkinson, R. and S. Bhatti, "Address Resolution Protocol
+ (ARP) Extension for the Identifier-Locator Network
+ Protocol for IPv4 (ILNPv4)", RFC 6747, November 2012.
+
+ [RFC6748] Atkinson, R. and S. Bhatti, "Optional Advanced Deployment
+ Scenarios for the Identifier-Locator Network Protocol
+ (ILNP)", RFC 6748, 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 6743 ILNPv6 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]
+