idnits 2.17.1 draft-irtf-rrg-ilnp-icmpv6-03.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 == Line 208 has weird spacing: '...of Locs vali...' == Line 211 has weird spacing: '...of Locs rela...' == Line 218 has weird spacing: '...of Locs part...' == 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 (17 May 2012) is 4362 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 280 -- Looks like a reference, but probably isn't: '2' on line 284 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 3 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-03.txt Consultant 4 Category: Experimental SN Bhatti 5 Expires: 17 NOV 2012 U. St Andrews 6 17 May 2012 8 ICMP Locator Update message for ILNPv6 9 draft-irtf-rrg-ilnp-icmpv6-03.txt 11 Status of this Memo 13 Distribution of this memo is unlimited. 15 Copyright (c) 2012 IETF Trust and the persons identified as the 16 document authors. All rights reserved. 18 This document is subject to BCP 78 and the IETF Trust's Legal 19 Provisions Relating to IETF Documents 20 (http://trustee.ietf.org/license-info) in effect on the date of 21 publication of this document. Please review these documents 22 carefully, as they describe your rights and restrictions with 23 respect to this document. Code Components extracted from this 24 document must include Simplified BSD License text as described in 25 Section 4.e of the Trust Legal Provisions and are provided 26 without warranty as described in the Simplified BSD License. 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 This document may contain material from IETF Documents or 32 IETF Contributions published or made publicly available 33 before November 10, 2008. The person(s) controlling the 34 copyright in some of this material may not have granted the IETF 35 Trust the right to allow modifications of such material outside 36 the IETF Standards Process. Without obtaining an adequate 37 license from the person(s) controlling the copyright in such 38 materials, this document may not be modified outside the IETF 39 Standards Process, and derivative works of it may not be created 40 outside the IETF Standards Process, except to format it for 41 publication as an RFC or to translate it into languages other 42 than English. This document may not be modified, and derivative 43 works of it may not be created, except to publish it as an RFC or 44 to translate it into languages other than English. 46 Internet-Drafts are working documents of the Internet 47 Engineering Task Force (IETF), its areas, and its working 48 groups. Note that other groups may also distribute working 49 documents as Internet-Drafts. 51 Internet-Drafts are draft documents valid for a maximum of six 52 months and may be updated, replaced, or obsoleted by other 53 documents at any time. It is inappropriate to use Internet-Drafts 54 as reference material or to cite them other than as "work in 55 progress." 57 The list of current Internet-Drafts can be accessed at 58 http://www.ietf.org/1id-abstracts.html 60 The list of Internet-Draft Shadow Directories can be accessed at 61 http://www.ietf.org/shadow.html 63 This document is not on the IETF standards-track and does not 64 specify any level of standard. This document merely provides 65 information for the Internet community. 67 This document is part of the ILNP document set, which has had 68 extensive review within the IRTF Routing Research Group. ILNP 69 is one of the recommendations made by the RG Chairs. Separately, 70 various refereed research papers on ILNP have also been published 71 during this decade. So the ideas contained herein have had much 72 broader review than the IRTF Routing RG. The views in this 73 document were considered controversial by the Routing RG, 74 but the RG reached a consensus that the document still should be 75 published. The Routing RG has had remarkably little consensus 76 on anything, so virtually all Routing RG outputs are considered 77 controversial. 79 Abstract 81 This note specifies an experimental ICMPv6 message type used with 82 the Identifier-Locator Network Protocol (ILNP). The 83 Identifier-Locator Network Protocol (ILNP) is an experimental, 84 evolutionary enhancement to IP. This message is used to 85 dynamically update Identifier/Locator bindings for an existing 86 ILNP session. This is a product of the IRTF Routing RG. 88 Table of Contents 90 1. Introduction ...........................................3 91 1.1 ILNP Document Roadmap.................................3 92 1.2 ICMPv6 Locator Update.................................3 93 1.3 Terminology...........................................3 94 2. Syntax..................................................4 95 2.1 Example ICMPv6 Locator Update message.................5 96 3. Transport Protocol Effects..............................6 97 4. Implementation Considerations...........................6 98 5. Backwards Compatibility.................................7 99 6. Security Considerations ................................7 100 7. IANA Considerations ....................................8 101 8. References .............................................8 103 1. Introduction 105 At present, the research and development community are examining 106 various alternatives for evolving the Internet Architecture. Several 107 different classes of evolution are being considered. One class is 108 often called "Map and Encapsulate", where traffic would be mapped and 109 then tunnelled through the inter-domain core of the Internet. 110 Another class being considered is sometimes known as 111 "Identifier/Locator Split". This document relates to a proposal that 112 is in the latter class of evolutionary approaches. 114 1.1 ILNP Document Roadmap 116 The ILNP Architecture document [ILNP-ARCH] is the best place to start 117 reading about ILNP. ILNP has multiple possible instantiations. 118 [ILNP-ENG] discusses engineering and implementation aspects common to 119 all instances of ILNP. A new IPv6 Destination Option used with 120 ILNPv6 is defined in [ILNP-NONCEv6]. This document discusses a new 121 ICMP for IPv6 message. [ILNP-DNS] describes new Domain Name System 122 (DNS) resource records used with ILNP. Other documents describe ILNP 123 for IPv4 (ILNPv4). 125 1.2 ICMPv6 Locator Update 127 As described in [ILNP-ARCH] and [ILNP-ENG], an ILNP for IPv6 (ILNPv6) 128 node might need to inform correspondent ILNPv6 nodes of changes to 129 the set of valid Locator values. The new ICMPv6 Locator Update 130 message described in this document enables an ILNP-capable node to 131 update its correspondents about the currently valid set of Locators 132 valid to use in reaching the node sending this message.[RFC2460] 133 [RFC4443] 135 This new ICMPv6 message MUST ONLY be used for ILNPv6 sessions. 136 Authentication is always required, as described in the Security 137 Considerations section later in this note. 139 Some might consider any and all use of ICMP to be undesirable. In 140 that context, please note that while this specification uses ICMP, on 141 grounds that this is a control message, there is no architectural 142 difference between using ICMP and using some different framing, for 143 example UDP. 145 1.3 Terminology 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in RFC 2119 [RFC2119]. 150 2. Syntax 152 The ICMP for IPv6 message described in this section has ICMP Type XXX 153 and is used ONLY with a current ILNPv6 session. This message enables 154 an ILNPv6 node to inform ILNPv6 correspondent nodes of changes to the 155 active Locator set for the ILNPv6 node that originates this message. 156 This particular ICMP for IPv6 message MUST ONLY be used with ILNPv6 157 communications sessions. 159 The ICMP for IPv6 message described in this section has ICMP Type XXX 160 and is used ONLY with a current ILNPv4 session. This message enables 161 an ILNPv6 node to advertise changes to the active Locator set for the 162 ILNPv6 node that originates this message to its unicast ILNP 163 correspondent nodes. It also enables those correspondents to 164 acknowledge receipt of the advertisement. 166 This particular ICMP for IPv6 message MUST ONLY be used with ILNPv6 167 communications sessions. The Checksum field for this message is 168 calculated identically as for any other IPv6 ICMP message. 170 ICMPv6 Locator Update message 172 0 1 2 3 173 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 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Type | Code | Checksum | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Num of Locs | Operation | RESERVED | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 / Locator [1] / 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Preference [1] | Lifetime [1] | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 / Locator [2] / 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Preference [2] | Lifetime [2] | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | . | 188 | . | 189 | . | 191 ICMPv6 Locator Update fields: 193 Type XXX 195 Code 0 197 Checksum The 16-bit one's complement of the one's 198 complement sum of the ICMP message, 199 starting with the ICMP Type. For 200 computing the checksum, the Checksum 201 field is set to 0. 203 Num of Locs The number of 64-bit Locator values 204 that are advertised in this message. 205 This field MUST NOT be zero. 207 Locator[i], The 64-bit Locator values currently 208 i = 1..Num of Locs valid for the sending ILNPv6 node. 210 Preference[i], The preferability of each Locator[i], 211 i = 1..Num of Locs relative to other valid Locator[i] 212 values. The Preference numbers here are 213 identical, both in syntax and semantics, 214 to the Preference values for L64 records 215 as specified by [ILNP-DNS]. 217 Lifetime[i] The maximum number of seconds that this 218 i = 1..Num of Locs particular Locator may be considered 219 valid. Normally, this is identical 220 to the DNS lifetime of the 221 corresponding L64 record, if one 222 exists. 224 Operation The value in this field indicates 225 whether this is a Locator Update 226 Advertisement (0x01) or a Locator 227 Update Acknowledgement (0x02). 229 RESERVED A field reserved for possible future 230 use. At present, the sender MUST 231 initialise this field to zero. 232 Receivers should ignore this field at 233 present. The field might be used for 234 some protocol function in future. 236 The Operation field has value 1 (hexadecimal 0x01) for a Locator 237 Update Advertisement. The Operation field has value 2 (hexadecimal 238 0x02) for a Locator Update Acknowledgement. All other values of the 239 Operation field are reserved for future use by future revisions of 240 this specification. 242 A node whose set of valid Locators has changed MUST send Locator 243 Update Advertisement messages to each correspondent node for each 244 active unicast ILNP session. For unicast ILNP sessions, the receiver 245 of a valid (e.g. authentication checks all passed, advertisement is 246 received from a current correspondent node) Locator Update 247 Advertisement addressed to the receiver MUST send a Locator Update 248 Acknowledgement back to the sender of the Locator Update 249 Advertisement. The Acknowledgement message body is identical to the 250 received Advertisement message body, except for the Operation value. 252 All ILNPv6 ICMP Locator Update messages MUST contain a valid ILNPv6 253 Identifier option and MUST contain an ILNPv6 Nonce Option. 255 ILNPv6 ICMP Locator Update messages also MAY be protected using IP 256 Security for ILNP [ILNP-ENG] [RFC4301]. Deployments in high-threat 257 environments SHOULD also protect ILNPv6 ICMP Locator Update messages 258 using IP Security. While IPsec ESP can protect a payload, no form of 259 IPsec ESP is able to protect an IPv6 option that appears prior to the 260 ESP header. 262 Note that even when IP Security for ILNP is in use, the ILNP Nonce 263 Option still MUST be present. This simplifies protocol processing, 264 and it also means that a receiver can perform the inexpensive check 265 of the Nonce value before performing any (potentially expensive) 266 cryptographic calculation. 268 2.1 Example ICMPv6 Locator Update message 270 This example shows the ICMPv6 syntax for the case where 2 Locator values 271 are being indicated. 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Type | Code | Checksum | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Num of Locs | RESERVED | RESERVED | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 / Locator [1] / 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Preference [1] | Lifetime [1] | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 / Locator [2] / 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Preference [2] | Lifetime [2] | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 3. Transport Protocol Effects 289 This message has no impact on any transport protocol. 291 The message may affect where packets for a given transport 292 session are sent, but an ILNP design objective is to decouple 293 transport-protocols from network-layer changes. 295 4. Implementation Considerations 297 Implementers may use any internal implementation they wish, 298 provided that the external appearance is the same as this 299 implementation approach. 301 To support ILNPv6, and to retain the incremental deployability 302 and backwards compatibility needed, the network layer needs a 303 mode bit in the Transport Control Block (or its equivalent) to 304 track which IP sessions are using the classic IPv6 mode and which 305 IP sessions are using the Identifier/Locator Split mode. 307 Further, when supporting ILNPv4, nodes will need to support a 308 Identifier Locator Communication Cache (ILCC) in the network 309 layer as described in [ILNP-ENG]. 311 A node sending an ICMP Locator Update message MUST include all 312 currently valid Locator values in that message. A node receiving 313 a valid ICMP Locator Update message MUST replace the previously 314 current set of Locator values for that correspondent node in its 315 own ILCC with the newly received set of Locator values. 317 Every implementation needs to support a large number of Locator 318 values being sent or received in a single ICMP Locator Update 319 message, because a multi-homed node or multi-homed site might 320 have a large number of upstream links to different service 321 providers, each with its own Locator value. 323 5. Backwards Compatibility 325 This IPv6 ICMP message uses the same checksum calculations as any 326 other IPv6 ICMP message. 328 When ILNPv6 is not in use, the receiving IPv6 mode MUST discard 329 the ICMP Locator Update packet without processing the packet. 330 This is standard behaviour for a non-ILNPv6 node when receiving 331 an ICMPv6 message with an unknown header field value. 333 6. Security Considerations 335 Security considerations for the overall ILNP Architecture 336 are described in [ILNP-ARCH]. Additional common security 337 considerations are described in [ILNP-ENG]. This section 338 describes security considerations specific to ILNPv6 topics 339 discussed in this document. 341 The ICMPv6 Locator Update message MUST ONLY be used for ILNPv6 342 sessions. 344 The ILNP Nonce Destination Option [ILNP-NONCEv6] MUST be present 345 in packets containing an ICMPv6 Locator Update message. Further, 346 the received Nonce Destination Option MUST contain the correct 347 nonce value for the packet to be accepted by the recipient and 348 then passed to the ICMPv6 protocol for processing. If either of 349 these requirements are not met, the received packet MUST be 350 discarded as a forgery, and a security event SHOULD be logged 351 by the system receiving the non-authentic packet. 353 Sessions operating in higher risk environments SHOULD use IP 354 Security for ILNP [ILNP-ENG] [RFC4301] *in addition* to the 355 ILNPv6 Nonce Destination Option. Use of IP Security for ILNP to 356 protect a packet does NOT permit the packet to be sent without 357 the Nonce Destination Option. 359 Implementations need to support the case where a single ICMP 360 Locator Update message contains a large number of Locator and 361 Preference values and ought not develop a security fault 362 (e.g. stack overflow) due to a received message containing more 363 Locator values than expected. 365 If the ILNP Nonce value is predictable, then an off-path attacker 366 might be able to forge data or control packets. This risk also 367 is mitigated by the existing common practice of IP Source Address 368 filtering [RFC2827] [RFC3704]. 370 7. IANA Considerations 372 Subjecto to IESG Approval, consistent with the procedures of 373 [RFC4443], IANA is requested to assign a value, replacing the 374 XXX, to the ICMP Type listed in Section 2. 376 There are no other IANA actions for this document. 378 8. References 380 This document contains both normative and informative references. 382 8.1. Normative References 384 [ILNP-ARCH] R.J. Atkinson & S.N. Bhatti, "ILNP Architecture", 385 draft-irtf-rrg-ilnp-arch, May 2012. 387 [ILNP-DNS] R.J. Atkinson & S.N. Bhatti, "DNS Resource Records 388 for ILNP", draft-irtf-rrg-ilnp-dns, May 2012. 390 [ILNP-ENG] R.J. Atkinson & S.N. Bhatti, "ILNP Engineering 391 Considerations", draft-irtf-rrg-ilnp-eng, 392 May 2012. 394 [ILNP-NONCEv6] R.J. Atkinson & S.N. Bhatti, "Nonce Destination 395 Option", draft-irtf-rrg-ilnp-noncev6, 396 May 2012. 398 [RFC2119] Bradner, S., "Key words for use in RFCs to 399 Indicate Requirement Levels", BCP 14, RFC 2119, 400 March 1997. 402 [RFC2460] S. Deering & R. Hinden, "Internet Protocol 403 Version 6 Specification", RFC 2460, 404 December 1998. 406 [RFC3704] F. Baker, P. Savola, "Ingress Filtering for 407 Multihomed Networks", RFC 3704, March 2004. 409 [RFC4301] S. Kent & K. Seo, "Security Architecture for 410 the Internet Protocol", RFC 4301, December 2005. 412 [RFC4443] A. Conta, S. Deering, and M. Gupta (Ed.), 413 "Internet Control Message Protocol (ICMPv6) 414 for the Internet Protocol Version 6 (IPv6) 415 Specification", RFC 4443, March 2006. 417 8.2. Informative References 419 [RFC2827] P. Ferguson and D. Senie, "Network Ingress 420 Filtering: Defeating Denial of Service Attacks 421 which employ IP Source Address Spoofing", 422 RFC 2827, May 2000. 424 ACKNOWLEDGEMENTS 426 Steve Blake, Stephane Bortzmeyer, Mohamed Boucadair, Noel 427 Chiappa, Wes George, Steve Hailes, Joel Halpern, Mark Handley, 428 Volker Hilt, Paul Jakma, Dae-Young Kim, Tony Li, Yakov Rehkter, 429 Bruce Simpson, Robin Whittle and John Wroclawski (in alphabetical 430 order) provided review and feedback on earlier versions of this 431 document. Steve Blake provided an especially thorough review of 432 an early version of the entire ILNP document set, which was 433 extremely helpful. We also wish to thank the anonymous reviewers 434 of the various ILNP papers for their feedback. 436 Roy Arends provided expert guidance on technical and procedural 437 aspects of DNS issues. 439 RFC EDITOR NOTE 441 This section is to be removed prior to publication. 443 This document is written in English, not American. So English 444 spelling is used throughout, rather than American spelling. 445 This is consistent with existing practice in several other RFCs, 446 for example RFC-5887. 448 This document tries to be very careful with history, in the 449 interest of correctly crediting ideas to their earliest 450 identifiable author(s). So in several places the first published 451 RFC about a topic is cited rather than the most recent published 452 RFC about that topic. 454 Author's Address 456 RJ Atkinson 457 Consultant 458 San Jose, CA 459 95125 USA 461 Email: rja.lists@gmail.com 463 SN Bhatti 464 School of Computer Science 465 University of St Andrews 466 North Haugh, St Andrews, 467 Fife, Scotland, UK 468 KY16 9SX 470 Email: saleem@cs.st-andrews.ac.uk 472 Expires: 17 NOV 2012