idnits 2.17.1 draft-irtf-rrg-ilnp-v4opts-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 == 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 96, but not defined == Missing Reference: 'ILNP-NONCE6' is mentioned on line 237, but not defined == Unused Reference: 'RFC2780' is defined on line 453, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft RJ Atkinson 3 draft-irtf-rrg-ilnp-v4opts-06.txt Consultant 4 Expires: 10 JAN 2013 SN Bhatti 5 Category: Experimental U. St Andrews 6 10 July 2012 8 IPv4 Options for ILNPv4 9 draft-irtf-rrg-ilnp-v4opts-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 (http://trustee.ietf.org 20 /license-info) in effect on the date of publication of this 21 document. Please review these documents carefully, as they 22 describe your rights and restrictions with respect to this 23 document. Code Components extracted from this document must 24 include Simplified BSD License text as described in Section 4.e 25 of the Trust Legal Provisions and are provided without warranty 26 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 copyright 34 in some of this material may not have granted the IETF Trust the 35 right to allow modifications of such material outside the IETF 36 Standards Process. Without obtaining an adequate license from the 37 person(s) controlling the copyright in such materials, this 38 document may not be modified outside the IETF Standards Process, 39 and derivative works of it may not be created outside the IETF 40 Standards Process, except to format it for publication as an RFC 41 or to translate it into languages other than English. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF), its areas, and its working groups. Note that 45 other groups may also distribute working documents as 46 Internet-Drafts. 48 Internet-Drafts are draft documents valid for a maximum of six 49 months and may be updated, replaced, or obsoleted by other 50 documents at any time. It is inappropriate to use Internet-Drafts 51 as reference material or to cite them other than as "work in 52 progress." 54 The list of current Internet-Drafts can be accessed at 55 http://www.ietf.org/1id-abstracts.html 57 The list of Internet-Draft Shadow Directories can be accessed at 58 http://www.ietf.org/shadow.html 60 This document is not on the IETF standards-track and does not 61 specify any level of standard. This document merely provides 62 information for the Internet community. 64 This document is part of the ILNP document set, and has had 65 extensive review within the IRTF Routing Research Group. ILNP is 66 one of the recommendations made by the RG Chairs. Separately, 67 various refereed research papers on ILNP have also been published 68 during this decade. So the ideas contained herein have had much 69 broader review than the IRTF Routing RG. The views in this 70 document were considered controversial by the Routing RG, but the 71 RG reached a consensus that the document still should be 72 published. The Routing RG has had remarkably little consensus on 73 anything, so virtually all Routing RG outputs are considered 74 controversial. 76 Abstract 78 This document defines two new IPv4 options that are used only with 79 ILNP for IPv4 (ILNPv4). ILNP is is an experimental, evolutionary 80 enhancement to IP. This document is a product of the IRTF Routing 81 RG. 83 Table of Contents - ### to be updated 85 1. Introduction.............................2 86 2. IPv4 Options for ILNPv4..................3 87 3. Security Considerations..................7 88 4. IANA Considerations......................7 89 5. References...............................8 91 1. INTRODUCTION 93 At present, the Internet research and development community are 94 exploring various approaches to evolving the Internet 95 Architecture to solve a variety of issues including, but not 96 limited to, scalability of inter-domain routing [RFC4984]. A wide 97 range of other issues (e.g. site multi-homing, node multi-homing, 98 site/subnet mobility, node mobility) are also active concerns at 99 present. Several different classes of evolution are being 100 considered by the Internet research & development community. One 101 class is often called "Map and Encapsulate", where traffic would 102 be mapped and then tunnelled through the inter-domain core of the 103 Internet. Another class being considered is sometimes known as 104 "Identifier/Locator Split". This document relates to a proposal 105 that is in the latter class of evolutionary approaches. 107 The Identifier Locator Network Protocol (ILNP) is an proposal for 108 evolving the Internet Architecture. It differs from the current 109 Internet Architecture primarily by deprecating the concept of an 110 IP Address, and instead defining two new objects, each having 111 crisp syntax and semantics. The first new object is the Locator, 112 a topology-dependent name for a subnetwork. The other new object 113 is the Identifier, which provides a topology-independent name for 114 a node. 116 1.1 Document Roadmap 118 This document describes a new IPv4 Nonce Option used by ILNPv4 119 nodes to carry a security nonce to prevent off-path attacks 120 against ILNP ICMP messages and also defines a new IPv4 121 Identifier Option used by ILNPv4 nodes. 123 The ILNP architecture can have more than one engineering 124 instantiation. For example, one can imagine a "clean-slate" 125 engineering design based on the ILNP architecture. In separate 126 documents, we describe two specific engineering instances of 127 ILNP. The term ILNPv6 refers precisely to an instance of ILNP that 128 is based upon, and backwards compatible with, IPv6. The term ILNPv4 129 refers precisely to an instance of ILNP that is based upon, and 130 backwards compatible with, IPv4. 132 Many engineering aspects common to both ILNPv4 and ILNPv6 are 133 described in [ILNP-ENG]. A full engineering specification for 134 either ILNPv6 or ILNPv4 is beyond the scope of this document. 136 Readers are referred to other related ILNP documents for details 137 not described here: 139 a) [ILNP-ARCH] is the main architectural description of ILNP, 140 including the concept of operations. 142 b) [ILNP-ENG] describes engineering and implementation 143 considerations that are common to both ILNPv4 and ILNPv6. 145 c) [ILNP-DNS] defines additional DNS resource records that 146 support ILNP. 148 d) [ILNP-ICMPv6] defines a new ICMPv6 Locator Update message 149 used by an ILNP node to inform its correspondent nodes 150 of any changes to its set of valid Locators. 152 e) [ILNP-NONCEv6] defines a new IPv6 Nonce Destination Option 153 used by ILNPv6 nodes (1) to indicate to ILNP correspondent 154 nodes (by inclusion within the initial packets of an ILNP 155 session) that the node is operating in the ILNP mode and 156 (2) to prevent off-path attacks against ILNP ICMP messages. 157 This Nonce is used, for example, with all ILNP ICMPv6 158 Locator Update messages that are exchanged among ILNP 159 correspondent nodes. 161 f) [ILNP-ICMPv4] defines a new ICMPv4 Locator Update message 162 used by an ILNP node to inform its correspondent nodes 163 of any changes to its set of valid Locators. 165 g) [ILNP-ARP] describes extensions to ARP for use with ILNPv4. 167 h) [ILNP-ADV] describes optional engineering and deployment 168 functions for ILNP. These are not required for the operation 169 or use of ILNP and are provided as additional options. 171 1.2 Terminology 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 174 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 175 "OPTIONAL" in this document are to be interpreted as described 176 in RFC2119. [RFC2119] 178 2. IPv4 Options for ILNPv4 180 ILNP for IPv4 (ILNPv4) is merely a different instantiation of the 181 ILNP architecture, so it retains the crisp distinction between 182 the Locator and the Identifier. As with ILNP for IPv6 (ILNPv6), 183 when ILNPv4 is used for a network-layer session, the upper-layer 184 protocols (e.g. TCP/UDP pseudo-header checksum, IPsec Security 185 Association) bind only to the Identifiers, never to the Locators. 186 As with ILNPv6, only the Locator values are used for routing and 187 forwarding ILNPv4 packets. 189 However, just as the packet format for IPv4 is different to IPv6, 190 so the engineering details for ILNPv4 are different also. Just as 191 ILNPv6 is carefully engineered to be backwards-compatible with 192 IPv6, ILNPv4 is carefully engineered to be backwards-compatible 193 with IPv4. 195 Each of these options MUST be copied upon fragmentation. Each of 196 these options is used for control, so uses Option Class 0. 198 Originally, these two options were specified to use separate IP 199 option numbers. However, only 1 IP option (decimal 158) has been 200 defined for experimental use with properties of MUST COPY and 201 CONTROL.[RFC4727] So these two options have been re-worked to share 202 that same IP option number (158). To distinguish between 203 the two actual options, the unsigned 8-bit field ILNPv4_OPT 204 inside this option is examined. 206 It is important for implementers to understand that IP Option 158 207 is not uniquely allocated to ILNPv4. Other IPv4-related 208 experiments might be using that IP option value for different IP 209 options having different IP option formats. 211 2.1 ILNPv4 Packet Format 213 The Source IP Address in the IPv4 header becomes the Source 214 ILNPv4 Locator value, while the Destination IP Address of the 215 IPv4 header becomes the Destination ILNPv4 Locator value. Of 216 course, backwards compatibility requirements mean that ILNPv4 217 Locators use the same number space as IPv4 routing prefixes. 219 ILNPv4 uses the same 64-bit Identifier, with the same modified 220 EUI-64 syntax, as ILNPv6. Because the IPv4 address fields are 221 much smaller than the IPv6 address fields, ILNPv4 cannot carry 222 the Identifier values in the fixed portion of the IPv4 header. 223 The obvious two ways to carry the ILNP Identifier with ILNPv4 224 are either as an IPv4 Option or as an IPv6-style Extension Header 225 placed after the IPv4 header and before the upper-layer protocol 226 (e.g. OSPF, TCP, UDP, SCTP). 228 Currently deployed IPv4 routers from multiple router vendors use 229 packet forwarding silicon that is able to parse past IPv4 options 230 to examine the upper-layer protocol header at wire-speed on 231 reasonably fast (e.g. 1 Gbps or better) network interfaces. By 232 contrast, no existing IPv4-capable packet forwarding silicon is 233 able to parse past a new Extension Header for IPv4. Hence, for 234 engineering reasons, ILNPv4 uses a new IPv4 Option to carry the 235 Identifier values. Another new IPv4 option also carries a nonce 236 value, performing the same function for ILNPv4 as the IPv6 Nonce 237 Destination Option [ILNP-NONCE6] performs for ILNPv6. 239 0 1 2 3 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 |Version| IHL |Type of Service| Total Length | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Identification |Flags| Fragment Offset | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Time to Live | Protocol | Header Checksum | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Source Locator (32 bits) | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Destination Locator (32 bits) | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | OT=158 | OL=5 | 0x00 |ILNPv4_OPT=0x01| 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | | 255 + Source Identifier + 256 | | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | | 259 + Destination Identifier + 260 | | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | OT=158 | OL=2 | 0x00 |ILNPv4_OPT=0x02| 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | top 32 bits of nonce | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | lower 32 bits of nonce | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 Figure 1: ILNPv4 header with ILNP ID option 270 and ILNP Nonce option. 272 Notation for Figure 1: 273 IHL: Internet Header Length 274 OT: Option Type 275 OL: Option Length 277 2.2 ILNP Identifier Option for IPv4 279 0 1 2 3 280 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 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | OT=158 | OL=20 | 0x00 |ILNPv4_OPT=0x01| 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Source Identifier | 285 | | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Destination Identifier | 288 | | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 Figure 2: ILNP Identifier Option for IPv4 293 Notation for Figure 2: 294 OT: Option Type 295 OL: Option Length 297 RFC-791, Page 15 specifies that the Option Length is measured in 298 words and includes the Option Type octet, the Option Length 299 octet, and the option data octets. 301 The Source Identifier and Destination Identifier are unsigned 302 64-bit integers. [ILNP-ENG] specifies the syntax, semantics, and 303 generation of ILNP Identifier values. Using the same syntax and 304 semantics for all instantiations of ILNP Identifiers simplifies 305 specification and implementation, while also facilitating 306 translation or transition between ILNPv4 and ILNPv6 should that 307 be desirable in future. 309 This IP option MUST NOT be present in an IPv4 packet unless the 310 packet is part of an ILNPv4 session. ILNPv4 sessions MUST 311 include this option in the first few packets of each ILNPv4 312 session, and MAY include this option in all packets of the ILNPv4 313 session. It is RECOMMENDED to include this option in all packets 314 of the ILNPv4 session if packet loss is higher than normal. 316 2.3 ILNP Nonce Option for IPv4 318 0 1 2 3 319 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 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | OT=158 | OL=2 | 0x00 |ILNPv4_OPT=0x02| 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | top 32 bits of nonce | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | lower 32 bits of nonce | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 Figure 3: ILNP Nonce Option for IPv4 330 Notation for Figure 3: 331 OT: Option Type 332 OL: Option Length 334 This option contains a 64-bit ILNP Nonce. As noted in [ILNP- 335 ARCH] and [ILNP-ENG], all ILNP Nonce values are unidirectional. 336 This means, for example, that when TCP is in use the underlying 337 ILNPv4 session will have two different NONCE values: one from 338 Initiator to Responder and another from Responder to 339 Initiator. The ILNP Nonce is used to provide non-cryptographic 340 protection against off-path attacks (e.g. forged ICMP messages 341 from the remote end of a TCP session). 343 Each NONCE value MUST be unpredictable (i.e. cryptographically 344 random). Guidance to implementers on generating 345 cryptographically random values is provided in [RFC4086]. 347 This IP option MUST NOT be present in an IPv4 packet unless the 348 packet is part of an ILNPv4 session. ILNPv4 nodes MUST include 349 this option in the first few packets of each ILNP session, MUST 350 include this option in all ICMP messages generated by endpoints 351 participating in an ILNP session, and MAY include this option in 352 all packets of an ILNPv4 session. 354 3. SECURITY CONSIDERATIONS 356 Security considerations for the overall ILNP Architecture are 357 described in [ILNP-ARCH]. Additional common security 358 considerations are described in [ILNP-ENG]. This section 359 describes security considerations specific to ILNPv4 topics 360 discussed in this document. 362 If the ILNP Nonce value is predictable, then an off-path attacker 363 might be able to forge data or control packets. This risk also 364 is mitigated by the existing common practice of IP Source Address 365 filtering [RFC2827] [RFC3704]. 367 IP Security for ILNP [ILNP-ENG] [RFC4301] provides cryptographic 368 protection for ILNP data and control packets. The ILNP Nonce 369 option is required in the circumstances described in Section 3, 370 even if IP Security is also in use. Deployments of ILNPv4 in 371 high-threat environments SHOULD use IP Security for additional 372 risk reduction. 374 This option is intended to be used primarily end-to-end between a 375 source node and a destination node. However, unlike IPv6, IPv4 376 does not specify a method to distinguish between options with 377 hop-by-hop behaviour versus end-to-end behaviour. 379 [ID-IPv4-OPT-FILTERING] provides general discussion of potential 380 operational issues with IPv4 options, along with specific advice 381 for handling several specific IPv4 options. Further, many 382 deployed modern IP routers (both IPv4 and IPv6) have been 383 explicitly configured to ignore all IP options, even including 384 the "Router Alert" option, when forwarding packets not addressed 385 to the router itself. Reports indicate this has been done to 386 preclude use of IP options as a (Distributed) Denial-of-Service 387 (D)DoS attack vector on backbone routers. 389 4. IANA CONSIDERATIONS 391 This document makes no request of IANA. 393 If in future the IETF decided to standardise ILNPv4, then 394 allocation of two unique Header Option values to ILNPv4, one for 395 the Identifier option and one for the Nonce option, would be 396 sensible. 398 5. REFERENCES 400 This document has both Normative and Informational References. 402 5.1 Normative References 404 [ILNP-ARCH] R.J. Atkinson & S.N. Bhatti, "ILNP Architecture", 405 draft-irtf-rrg-ilnp-arch, May 2012. 407 [ILNP-ENG] R.J. Atkinson & S.N. Bhatti, "ILNP Engineering 408 Considerations", draft-irtf-rrg-ilnp-eng, May 2012. 410 [ILNP-DNS] R.J. Atkinson & S.N. Bhatti, "DNS Resource Records 411 for ILNP", draft-irtf-rrg-ilnp-dns, May 2012. 413 [ILNP-ICMPv4] R.J. Atkinson & S.N. Bhatti, "ICMP Locator Update 414 message for ILNPv4", draft-irtf-rrg-ilnp-icmpv4, 415 May 2012. 417 [RFC2119] Bradner, S., "Key words for use in RFCs to 418 Indicate Requirement Levels", BCP 14, RFC 2119, 419 March 1997. 421 [RFC4301] S. Kent and K. Seo, "Security Architecture for 422 the Internet Protocol", RFC-4301, December 2005. 424 [RFC4727] B. Fenner, "Experimental Values in IPv4, IPv6, ICMPv4, 425 ICMPv6, UDP, and TCP Headers", RFC 4727, Nov 2006. 427 [ILNP-ARCH] R.J. Atkinson & S.N. Bhatti, 428 "ILNP Architectural Description", 429 draft-irtf-rrg-ilnp-arch, 10 July 2012. 431 [ILNP-ARP] R.J. Atkinson & S.N. Bhatti, "ARP Extension for 432 ILNPv4", draft-irtf-rrg-ilnp-arp, 10 July 2012. 434 [ILNP-DNS] R.J. Atkinson, S.N. Bhatti, & S Rose, 435 "DNS Resource Records for ILNP", 436 draft-irtf-rrg-ilnp-dns, 10 July 2012. 438 [ILNP-ENG] R.J. Atkinson & S.N. Bhatti, 439 "ILNP Engineering and Implementation Considerations", 440 draft-irtf-rrg-ilnp-eng, 10 July 2012. 442 [ILNP-ICMPv4] R.J. Atkinson & S.N. Bhatti, 443 "ICMPv4 Locator Update message" 444 draft-irtf-rrg-ilnp-icmpv4, 10 July 2012. 446 5.2 Informative References 448 [ID-IPv4-OPT-FILTERING] F. Gont, R. Atkinson, and C. Pignatero, 449 "Recommendations on Filtering of IPv4 Packets with 450 IPv4 options", draft-gont-opsec-ip-options-filtering, 451 March 2012. 453 [RFC2780] S. Bradner & V. Paxson, "IANA Allocation Guidelines 454 for Values in the Internet Protocol and Related 455 Headers", RFC 2780, March 2000. 457 [RFC2827] P. Ferguson and D. Senie, "Network Ingress 458 Filtering: Defeating Denial of Service Attacks 459 which employ IP Source Address Spoofing", 460 RFC-2827, May 2000. 462 [RFC3704] F. Baker and P. Savola, "Ingress Filtering for 463 Multihomed Networks", RFC-3704, March 2004. 465 [RFC4086] D. Eastlake 3rd, J. Schiller, and S. Crocker, 466 "Randomness Requirements for Security", RFC-4086, 467 June 2005. 469 [ILNP-ADV] R.J. Atkinson & S.N. Bhatti, 470 "Optional Advanced Deployment Scenarios for ILNP", 471 draft-irtf-rrg-ilnp-adv, 10 July 2012. 473 [ILNP-ICMPv6] R.J. Atkinson & S.N. Bhatti, 474 "ICMPv6 Locator Update message" 475 draft-irtf-rrg-ilnp-icmpv6, 10 July 2012. 477 [ILNP-NONCEv6] R.J. Atkinson & S.N. Bhatti, 478 "IPv6 Nonce Destination Option for ILNPv6", 479 draft-irtf-rrg-ilnp-noncev6, 10 July 2012. 481 ACKNOWLEDGEMENTS 483 Steve Blake, Stephane Bortzmeyer, Mohamed Boucadair, Noel 484 Chiappa, Wes George, Steve Hailes, Joel Halpern, Mark Handley, 485 Volker Hilt, Paul Jakma, Dae-Young Kim, Tony Li, Yakov Rehkter, 486 Bruce Simpson, Robin Whittle and John Wroclawski (in alphabetical 487 order) provided review and feedback on earlier versions of this 488 document. Steve Blake provided an especially thorough review of 489 an early version of the entire ILNP document set, which was 490 extremely helpful. We also wish to thank the anonymous reviewers 491 of the various ILNP papers for their feedback. 493 Roy Arends provided expert guidance on technical and procedural 494 aspects of DNS issues. 496 RFC EDITOR NOTE 498 This section is to be removed prior to publication. 500 Please note that this document is written in British English, so 501 British English spelling is used throughout. This is consistent 502 with existing practice in several other RFCs, for example 503 RFC-5887. 505 This document tries to be very careful with history, in the 506 interest of correctly crediting ideas to their earliest 507 identifiable author(s). So in several places the first published 508 RFC about a topic is cited rather than the most recent published 509 RFC about that topic. 511 AUTHOR'S ADDRESS 513 RJ Atkinson 514 Consultant 515 San Jose, CA, 516 95125 USA 518 Email: rja.lists@gmail.com 520 SN Bhatti 521 School of Computer Science 522 University of St Andrews 523 North Haugh, St Andrews 524 Fife, Scotland 525 KY16 9SX, UK 527 Email: saleem@cs.st-andrews.ac.uk 529 Expires: 10 JAN 2013