idnits 2.17.1 draft-irtf-rrg-ilnp-icmpv6-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 9, 2012) is 4491 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft RJ Atkinson 3 draft-irtf-rrg-ilnp-icmpv6-00.txt Consultant 4 Category: Experimental S Bhatti 5 Expires: 09 JUL 2012 U. St Andrews 6 January 9, 2012 7 ICMP Locator Update message for ILNPv6 8 draft-irtf-rrg-ilnp-icmpv6-00.txt 10 Status of this Memo 12 Distribution of this memo is unlimited. 14 Copyright (c) 2012 IETF Trust and the persons identified as the 15 document authors. All rights reserved. 17 This document is subject to BCP 78 and the IETF Trust's Legal 18 Provisions Relating to IETF Documents 19 (http://trustee.ietf.org/license-info) in effect on the date of 20 publication of this document. Please review these documents 21 carefully, as they describe your rights and restrictions with 22 respect to this document. Code Components extracted from this 23 document must include Simplified BSD License text as described in 24 Section 4.e of the Trust Legal Provisions and are provided 25 without warranty as described in the Simplified BSD License. 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 This document may contain material from IETF Documents or IETF 31 Contributions published or made publicly available before 32 November 10, 2008. The person(s) controlling the copyright in 33 some of this material may not have granted the IETF Trust the 34 right to allow modifications of such material outside the IETF 35 Standards Process. Without obtaining an adequate license from 36 the person(s) controlling the copyright in such materials, this 37 document may not be modified outside the IETF Standards Process, 38 and derivative works of it may not be created outside the IETF 39 Standards Process, except to format it for publication as an RFC 40 or to translate it into languages other than English. This 41 document may not be modified, and derivative works of it may not 42 be created, except to publish it as an RFC or to translate it 43 into languages other than English. 45 Internet-Drafts are working documents of the Internet 46 Engineering Task Force (IETF), its areas, and its working 47 groups. Note that other groups may also distribute working 48 documents as Internet-Drafts. 50 Internet-Drafts are draft documents valid for a maximum of six 51 months and may be updated, replaced, or obsoleted by other 52 documents at any time. It is inappropriate to use Internet-Drafts 53 as reference material or to cite them other than as "work in 54 progress." 56 The list of current Internet-Drafts can be accessed at 57 http://www.ietf.org/1id-abstracts.html 59 The list of Internet-Draft Shadow Directories can be accessed at 60 http://www.ietf.org/shadow.html 62 This document is not on the IETF standards-track and does not 63 specify any level of standard. This document merely provides 64 information for the Internet community. 66 This document is part of the ILNP document set, which has had 67 extensive review within the IRTF Routing Research Group. ILNP 68 is one of the recommendations made by the RG Chairs. Separately, 69 various refereed research papers on ILNP have also been published 70 during this decade. So the ideas contained herein have had much 71 broader review than the IRTF Routing RG. The views in this 72 document were considered controversial by the Routing RG, 73 but the RG reached a consensus that the document still should be 74 published. The Routing RG has had remarkably little consensus 75 on anything, so virtually all Routing RG outputs are considered 76 controversial. 78 Abstract 80 This note specifies an experimental ICMPv6 message type used 81 with the Identifier-Locator Network Protocol (ILNP). This 82 message is used to dynamically update Identifier/Locator 83 bindings for an existing ILNP session. This is a product 84 of the IRTF Routing RG. 86 Table of Contents 88 1. Introduction ...........................................2 89 2. Syntax..................................................3 90 3. Transport Protocol Effects..............................5 91 4. Implementation Considerations...........................5 92 5. Backwards Compatibility.................................6 93 6. Security Considerations ................................6 94 7. IANA Considerations ....................................7 95 8. References .............................................7 97 1. Introduction 99 At present, the research and development community are examining 100 various alternatives for evolving the Internet Architecture. Several 101 different classes of evolution are being considered. One class is 102 often called "Map and Encapsulate", where traffic would be mapped and 103 then tunnelled through the inter-domain core of the Internet. 104 Another class being considered is sometimes known as 105 "Identifier/Locator Split". This document relates to a proposal that 106 is in the latter class of evolutionary approaches. 108 The Identifier Locator Network Protocol evolves the current Internet 109 Architecture by deprecating the concept of the IP Address, and 110 substituting separate Locator and Identifier objects, each with crisp 111 syntax and semantics [ILNP-ARCH]. 113 ILNP has multiple instantiations. [ILNP-ENG] discusses ILNP 114 engineering and implementation aspects common to all instantiations 115 of ILNP. This document focuses on ILNP for IPv6 (ILNPv6). [ILNP- 116 DNS] covers new Domain Name System (DNS) resource records used with 117 ILNP. [ILNP-Nonce] describes a Nonce Destination Option used with 118 ILNPv6. 120 The new ICMPv6 Locator Update message described in this document 121 enables an ILNP-capable node to update its correspondents about the 122 currently valid set of Locators valid to use in reaching the node 123 sending this message.[RFC 2460] [RFC 4443] 125 This new ICMPv6 message MUST ONLY be used for ILNPv6 sessions. 126 Authentication is always required, as described in the Security 127 Considerations section later in this note. 129 Some might consider any and all use of ICMP to be undesirable. In 130 that context, please note that while this specification uses ICMP, on 131 grounds that this is a control message, there is no architectural 132 difference between using ICMP and using some different framing, for 133 example UDP. 135 1.1 Terminology 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in RFC 2119. [RFC 2119] 141 2. Syntax 143 Example ICMP message body for case where only 1 Locator value is 144 being indicated: 146 ------------------------------------------------------------ 147 | ICMP Type | ICMP Code | Checksum | 148 +-------------+---------------+-------------+--------------+ 149 | Num of Locs | RESERVED | Preference | 150 +-------------+---------------+-------------+--------------+ 151 / Locator / 152 +-------------+---------------+-------------+--------------+ 154 Example ICMP message body for case where 2 Locator 155 values are being indicated: 157 ------------------------------------------------------------ 158 | ICMP Type | ICMP Code | Checksum | 159 +-------------+---------------+-------------+--------------+ 160 | Num of Locs | RESERVED | Preference | 161 +-------------+---------------+-------------+--------------+ 162 / Locator / 163 +-------------+---------------+-------------+--------------+ 164 | RESERVED | Preference | 165 +-------------+---------------+-------------+--------------+ 166 / Locator / 167 +-------------+---------------+-------------+--------------+ 169 For cases where more than 2 Locator values are being indicated, 170 the "RESERVED", "Preference", and "Locator" fields are appended 171 as appropriate to carry the intended number of Locator fields. 173 ICMP Type: This 8-bit field is set to the value XXX 174 to indicate that this is a Locator Update 175 message. 177 ICMP Code: This 8-bit field indicates which kind of 178 ICMP Locator Update this is. At present, 179 the only valid value is 0, which means 180 that this message contains all currently 181 valid Locator values for the sending node. 183 Checksum: This contains the ICMPv6 Checksum value 184 for this packet. 186 Num of Locs: This field contains the number of 64-bit 187 Locators that follow the RESERVED field. 188 This field must not contain the number zero, 189 as each ILNP node needs to be reachable via 190 at least 1 Locator value. Multi-homed nodes 191 will have at least 2 Locator values. 193 Reserved: These fields MUST be sent as zero. 194 At this time, recipients should ignore the 195 contents of these field, as these bits are 196 reserved for future use. (Implementers 197 should understand that these fields might 198 be used in the future.) 200 Locator: This 64-bit field contains a valid Locator 201 that can be used to reach the sending node. 202 A variable number of Locator fields are 203 concatenated one after another. These are 204 listed in priority order, with the first 205 Locator field containing the most preferred 206 Locator value. 208 Preference: A 16-bit unsigned integer which specifies 209 the preference given to this Locator among 210 other Locators in the same ICMP message. 211 Lower Preference values are preferred 212 over higher Preference values. 214 NOTE: In order to prevent session stealing by an off-path 215 adversary, all ICMP Locator Update packets MUST also contain an 216 ILNP Nonce Destination Option with valid authentication 217 information for the session associated with the ICMP Locator 218 Update packet. The ILNP Nonce Destination Option is required in 219 all cases, even if some other authentication mechanism, such as 220 Security for ILNP [ILNP-ENG] [RFC 4301], is also in use. 222 3. Transport Protocol Effects 224 This message has no impact on any transport protocol. 226 The message may affect where packets for a given transport 227 session are sent, but an ILNP design objective is to decouple 228 transport-protocols from network-layer changes. 230 4. Implementation Considerations 232 Implementers may use any internal implementation they wish, 233 provided that the external appearance is the same as this 234 implementation approach. 236 To support ILNPv6, and to retain the incremental deployability 237 and backwards compatibility needed, the network layer needs a 238 mode bit in the Transport Control Block (or its equivalent) to 239 track which IP sessions are using the classic IPv6 mode and which 240 IP sessions are using the Identifier/Locator Split mode. 242 Further, when supporting ILNPv6, nodes will need to retain a 243 Correspondent Cache in the network layer as described in 244 [ILNP-ENG]. 246 A node sending an ICMP Locator Update message MUST include all 247 currently valid Locator values in that message. A node receiving 248 a valid ICMP Locator Update message MUST replace the previously 249 current set of Locator values for that correspondent node in the 250 ILNP Correspondent Cache with the newly received set of Locator 251 values. 253 Every implementation needs to support a large number of Locator 254 values being sent or received in a single ICMP Locator Update 255 message, because a multi-homed node or multi-homed site might 256 have a large number of upstream links to different service 257 providers, each with its own Locator value. 259 5. Backwards Compatibility 261 For all sessions operating in Identifier/Locator Split mode, 262 inside each node the high-order 64-bits ("Locator") MUST be set 263 to zero before calculating TCP or UDP checksums. So, any changes 264 in Locator values used on the wire will be invisible to the 265 transport protocol. In this mode, transport-layer checksums 266 (e.g. TCP pseudo-header checksum) will be calculated with both 267 Source Locator and Destination Locator fields set to all zero. 269 When ILNPv6 is not in use, the receiving IPv6 mode MUST discard 270 the ICMP Locator Update packet without processing the packet. 272 6. Security Considerations 274 A broader discussion of ILNP Security Considerations is 275 found in [ILNP-ARCH], and is incorporated here by reference. 277 The ICMP Locator Update message MUST ONLY be used for ILNPv6 278 sessions. 280 The ILNP Nonce Destination Option [ILNP-Nonce] MUST be present in 281 packets containing an ICMPv6 Locator Update message. Further, 282 the received Nonce Destination Option must contain the correct 283 nonce value for the packet to be accepted by the recipient and 284 then passed to the ICMPv6 protocol for processing. If either of 285 these requirements are not met, the received packet MUST be 286 discarded as not authentic, and a security event SHOULD be logged 287 by the system receiving the non-authentic packet. 289 Sessions operating in higher risk environments SHOULD use IP 290 Security for ILNP [ILNP-ENG] [RFC 4301] *in addition* to the 291 ILNPv6 Nonce Destination Option. Use of IP Security for ILNP to 292 protect a packet does NOT permit the packet to be sent without 293 the Nonce Destination Option. 295 Implementations need to support the case where a single ICMP 296 Locator Update message contains a large number of Locator and 297 Preference values and ought not develop a security fault 298 (e.g. stack overflow) due to a received message containing more 299 Locator values than expected. 301 7. IANA Considerations 303 IANA is requested to assign a value, replacing the XXX, to the 304 ICMP Type listed in Section 2, following the procedures in [RFC 305 4443]. 307 There are no other IANA actions for this document. 309 8. References 311 8.1. Normative References 313 [ILNP-ARCH] R. Atkinson and S. Bhatti, "ILNP Architecture", 314 draft-irtf-rrg-ilnp-arch, January 2012. 316 [ILNP-DNS] R. Atkinson and S. Bhatti, "DNS Resource Records 317 for ILNP", draft-irtf-rrg-ilnp-dns, January 2012. 319 [ILNP-ENG] R. Atkinson and S. Bhatti, "ILNP Engineering 320 Considerations", draft-irtf-rrg-ilnp-eng, January 2012. 322 [ILNP-Nonce] R. Atkinson and S. Bhatti, "Nonce Destination Option", 323 draft-irtf-rrg-ilnp-noncev6, January 2012. 325 [RFC 2119] Bradner, S., "Key words for use in RFCs to 326 Indicate Requirement Levels", BCP 14, RFC 2119, 327 March 1997. 329 [RFC 2460] S. Deering & R. Hinden, "Internet Protocol 330 Version 6 Specification", RFC-2460, 331 December 1998. 333 [RFC 4301] S. Kent & K. Seo, "Security Architecture for 334 the Internet Protocol", RFC 4301, December 2005. 336 [RFC 4443] A. Conta, S. Deering, and M. Gupta (Ed.), 337 "Internet Control Message Protocol (ICMPv6) 338 for the Internet Protocol Version 6 (IPv6) 339 Specification", RFC 4443, March 2006. 341 8.2. Informative References 343 ### tbd 345 7. ACKNOWLEDGEMENTS 347 Steve Blake, Mohamed Boucadair, Steve Hailes, Joel Halpern, Mark 348 Handley, Volker Hilt, Tony Li, and Yakov Rehkter (in alphabetical 349 order) provided review and feedback on earlier versions of the 350 ILNP documents. Steve Blake provided an especially thorough 351 review of the ILNP document set. 353 Author's Address 355 RJ Atkinson 356 Consultant 357 San Jose, CA 358 95125 USA 360 Email: rja.lists@gmail.com 362 S Bhatti 363 School of Computer Science 364 University of St Andrews 365 North Haugh, St Andrews, 366 Fife, Scotland, UK 367 KY 16 9SX 369 Email: saleem@cs.st-andrews.ac.uk 371 Expires: 09 JUL 2012