idnits 2.17.1 draft-irtf-rrg-ilnp-icmpv6-06.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 256 has weird spacing: '...of Locs vali...' == Line 259 has weird spacing: '...of Locs rela...' == Line 266 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 (10 July 2012) is 4307 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC4984' is mentioned on line 108, but not defined -- Looks like a reference, but probably isn't: '1' on line 330 -- Looks like a reference, but probably isn't: '2' on line 334 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 6 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-06.txt Consultant 4 Category: Experimental SN Bhatti 5 Expires: 10 JAN 2013 U. St Andrews 6 10 July 2012 8 ICMP Locator Update message for ILNPv6 9 draft-irtf-rrg-ilnp-icmpv6-06.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 Internet research and development community are 106 exploring various approaches to evolving the Internet Architecture to 107 solve a variety of issues including, but not limited to, scalability 108 of inter-domain routing [RFC4984]. A wide range of other issues (e.g. 109 site multi-homing, node multi-homing, site/subnet mobility, node 110 mobility) are also active concerns at present. Several different 111 classes of evolution are being considered by the Internet research & 112 development community. One class is often called "Map and 113 Encapsulate", where traffic would be mapped and then tunnelled 114 through the inter-domain core of the Internet. Another class being 115 considered is sometimes known as "Identifier/Locator Split". This 116 document relates to a proposal that is in the latter class of 117 evolutionary approaches. 119 1.1 Document Roadmap 121 This document describes a new IPv6 Nonce Destination Option used by 122 ILNPv6 nodes (1) to indicate to ILNP correspondent nodes (by 123 inclusion within the initial packets of an ILNP session) that the 124 node is operating in the ILNP mode and (2) to prevent off-path 125 attacks against ILNP ICMP messages. This Nonce is used, for example, 126 with all ILNP ICMPv6 Locator Update messages that are exchanged among 127 ILNP correspondent nodes. 129 The ILNP architecture can have more than one engineering 130 instantiation. For example, one can imagine a "clean-slate" 131 engineering design based on the ILNP architecture. In separate 132 documents, we describe two specific engineering instances of ILNP. 133 The term ILNPv6 refers precisely to an instance of ILNP that is based 134 upon, and backwards compatible with, IPv6. The term ILNPv4 refers 135 precisely to an instance of ILNP that is based upon, and backwards 136 compatible with, IPv4. 138 Many engineering aspects common to both ILNPv4 and ILNPv6 are 139 described in [ILNP-ENG]. A full engineering specification for either 140 ILNPv6 or ILNPv4 is beyond the scope of this document. 142 Readers are referred to other related ILNP documents for details not 143 described here: 145 a) [ILNP-ARCH] is the main architectural description of ILNP, 146 including the concept of operations. 148 b) [ILNP-ENG] describes engineering and implementation 149 considerations that are common to both ILNPv4 and ILNPv6. 151 c) [ILNP-DNS] defines additional DNS resource records that 152 support ILNP. 154 d) [ILNP-ICMPv6] defines a new ICMPv6 Locator Update message 155 used by an ILNP node to inform its correspondent nodes 156 of any changes to its set of valid Locators. 158 e) [ILNP-ICMPv4] defines a new ICMPv4 Locator Update message 159 used by an ILNP node to inform its correspondent nodes 160 of any changes to its set of valid Locators. 162 f) [ILNP-v4OPTS] defines a new IPv4 Nonce Option used by ILNPv4 163 nodes to carry a security nonce to prevent off-path attacks 164 against ILNP ICMP messages and also defines a new IPv4 165 Identifier Option used by ILNPv4 nodes. 167 g) [ILNP-ARP] describes extensions to ARP for use with ILNPv4. 169 h) [ILNP-ADV] describes optional engineering and deployment 170 functions for ILNP. These are not required for the operation 171 or use of ILNP and are provided as additional options. 173 1.2 ICMPv6 Locator Update 175 As described in [ILNP-ARCH] and [ILNP-ENG], an ILNP for IPv6 (ILNPv6) 176 node might need to inform correspondent ILNPv6 nodes of changes to 177 the set of valid Locator values. The new ICMPv6 Locator Update 178 message described in this document enables an ILNP-capable node to 179 update its correspondents about the currently valid set of Locators 180 valid to use in reaching the node sending this message [RFC2460] 181 [RFC4443]. 183 This new ICMPv6 message MUST ONLY be used for ILNPv6 sessions. 184 Authentication is always required, as described in the Security 185 Considerations section later in this note. 187 Some might consider any and all use of ICMP to be undesirable. In 188 that context, please note that while this specification uses ICMP, on 189 grounds that this is a control message, there is no architectural 190 difference between using ICMP and using some different framing, for 191 example UDP. 193 1.3 Terminology 195 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 196 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 197 document are to be interpreted as described in RFC 2119 [RFC2119]. 199 2. Syntax 201 The ICMP for IPv6 message described in this section has ICMP Type XXX 202 and is used ONLY with a current ILNPv6 session. This message enables 203 an ILNPv6 node to inform ILNPv6 correspondent nodes of changes to the 204 active Locator set for the ILNPv6 node that originates this message. 205 This particular ICMP for IPv6 message MUST ONLY be used with ILNPv6 206 sessions. 208 The ICMP for IPv6 message described in this section has ICMP Type XXX 209 and is used ONLY with a current ILNPv4 session. This message enables 210 an ILNPv6 node to advertise changes to the active Locator set for the 211 ILNPv6 node that originates this message to its unicast ILNP 212 correspondent nodes. It also enables those correspondents to 213 acknowledge receipt of the advertisement. 215 This particular ICMP for IPv6 message MUST ONLY be used with ILNPv6 216 sessions. The Checksum field for this message is calculated 217 identically as for any other IPv6 ICMP message. 219 ICMPv6 Locator Update message 221 0 1 2 3 222 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 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Type | Code | Checksum | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Num of Locs | Operation | RESERVED | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 / Locator [1] / 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Preference [1] | Lifetime [1] | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 / Locator [2] / 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Preference [2] | Lifetime [2] | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | . | 237 | . | 238 | . | 239 ICMPv6 Locator Update fields: 241 Type XXX 243 Code 0 245 Checksum The 16-bit one's complement of the one's 246 complement sum of the ICMP message, 247 starting with the ICMP Type. For 248 computing the checksum, the Checksum 249 field is set to 0. 251 Num of Locs The number of 64-bit Locator values 252 that are advertised in this message. 253 This field MUST NOT be zero. 255 Locator[i], The 64-bit Locator values currently 256 i = 1..Num of Locs valid for the sending ILNPv6 node. 258 Preference[i], The preferability of each Locator[i], 259 i = 1..Num of Locs relative to other valid Locator[i] 260 values. The Preference numbers here are 261 identical, both in syntax and semantics, 262 to the Preference values for L64 records 263 as specified by [ILNP-DNS]. 265 Lifetime[i] The maximum number of seconds that this 266 i = 1..Num of Locs particular Locator may be considered 267 valid. Normally, this is identical 268 to the DNS lifetime of the 269 corresponding L64 record, if one 270 exists. 272 Operation The value in this field indicates 273 whether this is a Locator Update 274 Advertisement (0x01) or a Locator 275 Update Acknowledgement (0x02). 277 RESERVED A field reserved for possible future 278 use. At present, the sender MUST 279 initialise this field to zero. 280 Receivers should ignore this field at 281 present. The field might be used for 282 some protocol function in future. 284 The Operation field has value 1 (hexadecimal 0x01) for a Locator 285 Update Advertisement. The Operation field has value 2 (hexadecimal 286 0x02) for a Locator Update Acknowledgement. All other values of the 287 Operation field are reserved for future use by future revisions of 288 this specification. 290 A node whose set of valid Locators has changed MUST send Locator 291 Update Advertisement messages to each correspondent node for each 292 active unicast ILNP session. For unicast ILNP sessions, the receiver 293 of a valid (e.g. authentication checks all passed, advertisement is 294 received from a current correspondent node) Locator Update 295 Advertisement addressed to the receiver MUST send a Locator Update 296 Acknowledgement back to the sender of the Locator Update 297 Advertisement. The Acknowledgement message body is identical to the 298 received Advertisement message body, except for the Operation value. 300 All ILNPv6 ICMP Locator Update messages MUST contain a valid ILNPv6 301 Identifier option and MUST contain an ILNPv6 Nonce Option. 303 ILNPv6 ICMP Locator Update messages also MAY be protected using IP 304 Security for ILNP [ILNP-ENG] [RFC4301]. Deployments in high-threat 305 environments SHOULD also protect ILNPv6 ICMP Locator Update messages 306 using IP Security. While IPsec ESP can protect a payload, no form of 307 IPsec ESP is able to protect an IPv6 option that appears prior to the 308 ESP header. 310 Note that even when IP Security for ILNP is in use, the ILNP Nonce 311 Option still MUST be present. This simplifies protocol processing, 312 and it also means that a receiver can perform the inexpensive check 313 of the Nonce value before performing any (potentially expensive) 314 cryptographic calculation. 316 2.1 Example ICMPv6 Locator Update message 318 This example shows the ICMPv6 syntax for the case where 2 Locator values 319 are being indicated. 321 0 1 2 3 322 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 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Type | Code | Checksum | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Num of Locs | RESERVED | RESERVED | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 / Locator [1] / 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Preference [1] | Lifetime [1] | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 / Locator [2] / 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Preference [2] | Lifetime [2] | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 3. Transport Protocol Effects 339 This message has no impact on any transport protocol. 341 The message may affect where packets for a given transport-layer 342 session are sent, but an ILNP design objective is to decouple 343 transport-layer protocols and transport-layer session information 344 from network-layer changes. 346 4. Implementation Considerations 348 Implementers may use any internal implementation they wish, 349 provided that the external appearance is the same as this 350 implementation approach. 352 To support ILNPv6, and to retain the incremental deployability 353 and backwards compatibility needed, the network layer needs a 354 mode bit in the Transport Control Block (or its equivalent) to 355 track which IP sessions are using the classic IPv6 mode and which 356 IP sessions are using the Identifier/Locator Split mode. 358 Further, when supporting ILNPv4, nodes will need to support an 359 Identifier Locator Communication Cache (ILCC) in the network 360 layer as described in [ILNP-ENG]. 362 A node sending an ICMP Locator Update message MUST include all 363 currently valid Locator values in that message. A node receiving 364 a valid ICMP Locator Update message MUST replace the previously 365 current set of Locator values for that correspondent node in its 366 own ILCC with the newly received set of Locator values. 368 Every implementation needs to support a large number of Locator 369 values being sent or received in a single ICMP Locator Update 370 message, because a multi-homed node or multi-homed site might 371 have a large number of upstream links to different service 372 providers, each with its own Locator value. 374 5. Backwards Compatibility 376 This IPv6 ICMP message uses the same checksum calculations as any 377 other IPv6 ICMP message. 379 When ILNPv6 is not in use, the receiving IPv6 mode MUST discard 380 the ICMP Locator Update packet without processing the packet. 381 This is standard behaviour for a non-ILNPv6 node when receiving 382 an ICMPv6 message with an unknown header field value. 384 6. Security Considerations 386 Security considerations for the overall ILNP Architecture 387 are described in [ILNP-ARCH]. Additional common security 388 considerations are described in [ILNP-ENG]. This section 389 describes security considerations specific to ILNPv6 topics 390 discussed in this document. 392 The ICMPv6 Locator Update message MUST ONLY be used for 393 ILNPv6 sessions. 395 The ILNP Nonce Destination Option [ILNP-NONCEv6] MUST be present 396 in packets containing an ICMPv6 Locator Update message. Further, 397 the received Nonce Destination Option MUST contain the correct 398 nonce value for the packet to be accepted by the recipient and 399 then passed to the ICMPv6 protocol for processing. If either of 400 these requirements are not met, the received packet MUST be 401 discarded as a forgery, and a security event SHOULD be logged 402 by the system receiving the non-authentic packet. 404 ILNP sessions operating in higher risk environments SHOULD use 405 IP Security for ILNP [ILNP-ENG] [RFC4301] *in addition* to the 406 ILNPv6 Nonce Destination Option. Use of IP Security for ILNP 407 to protect a packet does NOT permit the packet to be sent 408 without the Nonce Destination Option. 410 Implementations need to support the case where a single ICMP 411 Locator Update message contains a large number of Locator and 412 Preference values and ought not develop a security fault 413 (e.g. stack overflow) due to a received message containing more 414 Locator values than expected. 416 If the ILNP Nonce value is predictable, then an off-path attacker 417 might be able to forge data or control packets. This risk also 418 is mitigated by the existing common practice of IP Source Address 419 filtering [RFC2827] [RFC3704]. 421 7. IANA Considerations 423 Subject to IESG Approval, consistent with the procedures of 424 [RFC4443], IANA is requested to assign a value, replacing the 425 XXX, to the ICMP Type listed in Section 2. 427 There are no other IANA actions for this document. 429 8. References 431 This document contains both normative and informative references. 433 8.1. Normative References 435 [ILNP-ARCH] R.J. Atkinson & S.N. Bhatti, "ILNP Architecture", 436 draft-irtf-rrg-ilnp-arch, May 2012. 438 [ILNP-DNS] R.J. Atkinson & S.N. Bhatti, "DNS Resource Records 439 for ILNP", draft-irtf-rrg-ilnp-dns, May 2012. 441 [ILNP-ENG] R.J. Atkinson & S.N. Bhatti, "ILNP Engineering 442 Considerations", draft-irtf-rrg-ilnp-eng, 443 May 2012. 445 [ILNP-NONCEv6] R.J. Atkinson & S.N. Bhatti, "Nonce Destination 446 Option", draft-irtf-rrg-ilnp-noncev6, 447 May 2012. 449 [RFC2119] Bradner, S., "Key words for use in RFCs to 450 Indicate Requirement Levels", BCP 14, RFC 2119, 451 March 1997. 453 [RFC2460] S. Deering & R. Hinden, "Internet Protocol 454 Version 6 Specification", RFC 2460, 455 December 1998. 457 [RFC3704] F. Baker, P. Savola, "Ingress Filtering for 458 Multihomed Networks", RFC 3704, March 2004. 460 [RFC4301] S. Kent & K. Seo, "Security Architecture for 461 the Internet Protocol", RFC 4301, December 2005. 463 [RFC4443] A. Conta, S. Deering, and M. Gupta (Ed.), 464 "Internet Control Message Protocol (ICMPv6) 465 for the Internet Protocol Version 6 (IPv6) 466 Specification", RFC 4443, March 2006. 468 [ILNP-ARCH] R.J. Atkinson & S.N. Bhatti, 469 "ILNP Architectural Description", 470 draft-irtf-rrg-ilnp-arch, 10 July 2012. 472 [ILNP-ENG] R.J. Atkinson & S.N. Bhatti, 473 "ILNP Engineering and Implementation Considerations", 474 draft-irtf-rrg-ilnp-eng, 10 July 2012. 476 [ILNP-ICMPv6] R.J. Atkinson & S.N. Bhatti, 477 "ICMPv6 Locator Update message" 478 draft-irtf-rrg-ilnp-icmpv6, 10 July 2012. 480 [ILNP-NONCEv6] R.J. Atkinson & S.N. Bhatti, 481 "IPv6 Nonce Destination Option for ILNPv6", 482 draft-irtf-rrg-ilnp-noncev6, 10 July 2012. 484 8.2. Informative References 486 [RFC2827] P. Ferguson and D. Senie, "Network Ingress 487 Filtering: Defeating Denial of Service Attacks 488 which employ IP Source Address Spoofing", 489 RFC 2827, May 2000. 491 [ILNP-ADV] R.J. Atkinson & S.N. Bhatti, 492 "Optional Advanced Deployment Scenarios for ILNP", 493 draft-irtf-rrg-ilnp-adv, 10 July 2012. 495 [ILNP-ARP] R.J. Atkinson & S.N. Bhatti, "ARP Extension for 496 ILNPv4", draft-irtf-rrg-ilnp-arp, 10 July 2012. 498 [ILNP-DNS] R.J. Atkinson, S.N. Bhatti, & S Rose, 499 "DNS Resource Records for ILNP", 500 draft-irtf-rrg-ilnp-dns, 10 July 2012. 502 [ILNP-ICMPv4] R.J. Atkinson & S.N. Bhatti, 503 "ICMPv4 Locator Update message" 504 draft-irtf-rrg-ilnp-icmpv4, 10 July 2012. 506 [ILNP-v4OPTS] R.J. Atkinson & S.N. Bhatti, 507 "IPv4 Options for ILNP", 508 draft-irtf-rrg-ilnp-v4opts, 10 July 2012. 510 ACKNOWLEDGEMENTS 512 Steve Blake, Stephane Bortzmeyer, Mohamed Boucadair, Noel 513 Chiappa, Wes George, Steve Hailes, Joel Halpern, Mark Handley, 514 Volker Hilt, Paul Jakma, Dae-Young Kim, Tony Li, Yakov Rehkter, 515 Bruce Simpson, Robin Whittle and John Wroclawski (in alphabetical 516 order) provided review and feedback on earlier versions of this 517 document. Steve Blake provided an especially thorough review of 518 an early version of the entire ILNP document set, which was 519 extremely helpful. We also wish to thank the anonymous reviewers 520 of the various ILNP papers for their feedback. 522 Roy Arends provided expert guidance on technical and procedural 523 aspects of DNS issues. 525 RFC EDITOR NOTE 527 This section is to be removed prior to publication. 529 Please note that this document is written in British English, so 530 British English spelling is used throughout. This is consistent 531 with existing practice in several other RFCs, for example 532 RFC-5887. 534 This document tries to be very careful with history, in the 535 interest of correctly crediting ideas to their earliest 536 identifiable author(s). So in several places the first published 537 RFC about a topic is cited rather than the most recent published 538 RFC about that topic. 540 Author's Address 542 RJ Atkinson 543 Consultant 544 San Jose, CA 545 95125 USA 547 Email: rja.lists@gmail.com 549 SN Bhatti 550 School of Computer Science 551 University of St Andrews 552 North Haugh, St Andrews, 553 Fife, Scotland, UK 554 KY16 9SX 556 Email: saleem@cs.st-andrews.ac.uk 558 Expires: 10 JAN 2013