idnits 2.17.1 draft-irtf-rrg-ilnp-eng-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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 275 has weird spacing: '...trative manag...' == 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? -- 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 ---------------------------------------------------------------------------- == Missing Reference: 'RFC4984' is mentioned on line 106, but not defined == Missing Reference: 'ILNP-ENG' is mentioned on line 139, but not defined == Missing Reference: 'RFC826' is mentioned on line 362, but not defined == Missing Reference: 'RFC3587' is mentioned on line 823, but not defined == Unused Reference: 'RFC4219' is defined on line 1650, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3177 (Obsoleted by RFC 6177) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 2 errors (**), 0 flaws (~~), 8 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-eng-06.txt Consultant 4 Expires: 10 JAN 2013 SN Bhatti 5 Category: Experimental U. St Andrews 6 10 July 2012 8 ILNP Engineering Considerations 9 draft-irtf-rrg-ilnp-eng-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 21 of 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 25 in 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 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 The ILNP document set has had extensive review within the IRTF 65 Routing Research Group. ILNP is one of the recommendations made 66 by the RG Chairs. Separately, various refereed research papers 67 on ILNP have also been published during this decade. So the 68 ideas contained herein have had much broader review than 69 IRTF Routing RG. The views in this document were considered 70 controversial by the Routing RG, but the RG reached a consensus 71 that the document still should be published. The Routing RG has 72 had remarkably little consensus on anything, so virtually all 73 Routing RG outputs are considered controversial. 75 Abstract 77 This document describes common (i.e. version independent) 78 engineering details for the Identifier-Locator Network Protocol 79 (ILNP), which is an experimental, evolutionary enhancement to IP. 80 This document is a product of the IRTF Routing RG. 82 Table of Contents 84 1. Introduction .........................................? 85 2. ILNP Identifiers......................................? 86 3. Encoding of Identifiers and Locators for ILNPv6.......? 87 4. Transport Layer Changes...............................? 88 5. ILNP Communication Cache (ILCC).......................? 89 6. Handling Location/Connectivity Changes................? 90 7. Subnetting............................................? 91 8. DNS Considerations....................................? 92 9. IP Security for ILNP..................................? 93 10. Backwards Compatibility Incremental Deployment........? 94 11. Security Considerations...............................? 95 12. Privacy Considerations................................? 96 13. Operational Considerations............................? 97 14. Referrals and Application Programming Interfaces......? 98 15. IANA Considerations...................................? 99 16. References............................................? 101 1. INTRODUCTION 103 At present, the Internet research and development community are 104 exploring various approaches to evolving the Internet 105 Architecture to solve a variety of issues including, but not 106 limited to, scalability of inter-domain routing [RFC4984]. A wide 107 range of other issues (e.g. site multi-homing, node multi-homing, 108 site/subnet mobility, node mobility) are also active concerns at 109 present. Several different classes of evolution are being 110 considered by the Internet research & development community. One 111 class is often called "Map and Encapsulate", where traffic would 112 be mapped and then tunnelled through the inter-domain core of the 113 Internet. Another class being considered is sometimes known as 114 "Identifier/Locator Split". This document relates to a proposal 115 that is in the latter class of evolutionary approaches. 117 The Identifier Locator Network Protocol (ILNP) is an experimental 118 network protocol that provides evolutionary enhancements to IP. 119 ILNP is backwards-compatible with IP and also is incrementally 120 deployable. The best starting point for learning about ILNP is 121 the ILNP Architectural Description, which includes a document 122 roadmap [ILNP-ARCH]. 124 1.1 Document roadmap 126 This document describes engineering and implementation 127 considerations that are common to both ILNPv4 and ILNPv6. 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 133 ILNP. The term ILNPv6 refers precisely to an instance of ILNP that 134 is based upon, and backwards compatible with, IPv6. The term ILNPv4 135 refers precisely to an instance of ILNP that is based upon, and 136 backwards compatible with, IPv4. 138 Many engineering aspects common to both ILNPv4 and ILNPv6 are 139 described in [ILNP-ENG]. A full engineering specification for 140 either ILNPv6 or ILNPv4 is beyond the scope of this document. 142 Readers are referred to other related ILNP documents for details 143 not described here: 145 a) [ILNP-ARCH] is the main architectural description of ILNP, 146 including the concept of operations. 148 b) [ILNP-DNS] defines additional DNS resource records that 149 support ILNP. 151 c) [ILNP-ICMPv6] defines a new ICMPv6 Locator Update message 152 used by an ILNP node to inform its correspondent nodes 153 of any changes to its set of valid Locators. 155 d) [ILNP-NONCEv6] defines a new IPv6 Nonce Destination Option 156 used by ILNPv6 nodes (1) to indicate to ILNP correspondent 157 nodes (by inclusion within the initial packets of an ILNP 158 session) that the node is operating in the ILNP mode and 159 (2) to prevent off-path attacks against ILNP ICMP messages. 160 This Nonce is used, for example, with all ILNP ICMPv6 161 Locator Update messages that are exchanged among ILNP 162 correspondent nodes. 164 e) [ILNP-ICMPv4] defines a new ICMPv4 Locator Update message 165 used by an ILNP node to inform its correspondent nodes 166 of any changes to its set of valid Locators. 168 f) [ILNP-v4OPTS] defines a new IPv4 Nonce Option used by ILNPv4 169 nodes to carry a security nonce to prevent off-path attacks 170 against ILNP ICMP messages and also defines a new IPv4 171 Identifier Option used by ILNPv4 nodes. 173 g) [ILNP-ARP] describes extensions to ARP for use with ILNPv4. 175 h) [ILNP-ADV] describes optional engineering and deployment 176 functions for ILNP. These are not required for the operation 177 or use of ILNP and are provided as additional options. 179 1.2 Terminology 181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 182 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 183 "OPTIONAL" in this document are to be interpreted as described in 184 RFC 2119 [RFC2119]. 186 Several technical terms (e.g., "ILNP session") that are used by 187 this document are defined in [ILNP-ARCH]. It is strongly 188 recommended that one read [ILNP-ARCH] before reading this 189 document. 191 2. ILNP IDENTIFIERS 192 All ILNP nodes must have at least one Node Identifier (or just 193 "Identifier") value. However, there are various options for 194 generating those Identifier values. We describe in this section 195 the relevant engineering issues related to Identifier generation 196 and usage. 198 Note well that ILNP Node Identifiers name an ILNP-capable node, 199 and are NOT bound to a specific interface of that node. So a 200 given ILNP Node Identifier is valid on all active interfaces of the 201 node to which that ILNP Identifier is bound. This is true even if 202 the bits used to form the Identifier value happened to be taken 203 from a specific interface as an engineering convenience. 205 2.1 Syntax 207 ILNP Identifiers are always unsigned 64-bit strings, and may be 208 realised as 64-bit unsigned integers. Both ILNPv4 and ILNPv6 use 209 the Modified EUI-64 [IEEE-EUI] syntax that is used by IPv6 210 Interface Identifiers [RFC4291, Sec 2.5.1], as shown in Figure 2.1. 212 +--------------------------------------------------+ 213 | 6 id bits | U bit | G bit | 24 id bits | 214 +--------------------------------------------------+ 215 | 32 id bits | 216 +--------------------------------------------------+ 218 Figure 2.1. Node Identifier format as used for IPv6, using the 219 same syntax as in RFC4291 Sec 2.5.1. 221 That syntax contains two special reserved bit flags. One flag 222 (the U bit) indicates whether the value has "universal" (i.e. 223 global) scope (1) or "local" (0) scope. The other flag (the G 224 bit) indicates whether the value is an "individual" address (1) 225 or "group" (i.e multicast) (0) address. 227 However, this format does allow other values to be set, by use of 228 administrative or other policy control, as required, by setting 229 the U bit to "local". 231 2.1 Default values for an Identifier 233 By default, this value, including the U bit and G bit, are set as 234 described in Sec 2.5.1 of RFC4291 [RFC4291]. Where no other 235 value of Identifier is available for an ILNP node, this is the 236 value that MUST be used. 238 Because ILNP Identifiers might have local scope, and also to 239 handle the case where two nodes at different locations happen to 240 be using the same global scope Identifier (e.g. due to a 241 manufacturing fault in a network chipset or card), implementers 242 must be careful in how ILNP Identifiers are handled within an end 243 system's networking implementation. Some details are discussed in 244 Section 4 below. 246 2.2 Local-scoped Identifier values 248 ILNP Identifiers for a node also MAY have the Scope bit of the 249 Node Identifier set to "local"" scope. Locally unique identifiers 250 MAY be Cryptographically Generated, created following the 251 procedures used for IPv6 Cryptographically Generated Addresses 252 (CGAs) [RFC3972] [RFC4581] [RFC4982]. 254 Also, locally unique identifiers MAY be used to create the ILNP 255 equivalent to the Privacy Extensions for IPv6, generating ILNP 256 Identifiers following the procedures used for IPv6 [RFC4941]. 258 2.3 Multicast Identifiers 260 An ILNP Identifier with the G bit set to "group" names an ILNP 261 multicast group, while an ILNP Identifier with the G bit set to 262 "individual" names an individual ILNP node. However, this usage 263 of multicast for Identifiers for ILNP is currently undefined: 264 ILNP uses IPv6 multicast for ILNPv6 and IPv4 multicast for ILNPv4 265 and uses the multicast address formats defined as appropriate. 267 The use of multicast Identifiers and design of an enhanced 268 multicast capability for ILNPv6 and ILNPv4 is currently work 269 in progress. 271 2.4 Administration of Identifier values 273 Note that just as IPv6 does not need global, centralised 274 administrative management of its interface identifiers, so ILNPv6 275 does not need global, centralised administrative management of 276 the NID values. 278 3.0 ENCODING OF IDENTIFIERS AND LOCATORS FOR ILNPv6 280 3.1 Encoding of I and L values 282 With ILNPv6, the Identifier and Locator values within a packet 283 are encoded in the the existing space for the IPv6 address. In general, 284 the ILNPv6 Locator has the same syntax and semantics as the current 285 IPv6 unicast routing prefix, as shown in Figure 3.1: 287 /* IPv6 */ 288 | 64 bits | 64 bits | 289 +-------------------------------------+-------------------------+ 290 | IPv6 Unicast Routing Prefix | Interface Identifier | 291 +-------------------------------------+-------------------------+ 293 /* ILNPv6 */ 294 | 64 bits | 64 bits | 295 +-------------------------------------+-------------------------+ 296 | Locator | Node Identifier (NID) | 297 +-------------------------------------+-------------------------+ 299 Figure 3.1 The general format of encoding of I/NID and L values 300 for ILNPv6 into theIPv6 address bits. 302 The syntactical structure of the IPv6 address spaces remains as given 303 in section 2.5.4 of [RFC4291], and an example is shown in Figure 3.2, 304 which is based in part on [RFC3177]. 306 /* IPv6 */ 307 | 3 | 45 bits | 16 bits | 64 bits | 308 +---+---------------------+-----------+-------------------------+ 309 |001|global routing prefix| subnet ID | Interface Identifier | 310 +---+---------------------+-----------+-------------------------+ 312 /* ILNPv6 */ 313 | 64 bits | 64 bits | 314 +---+---------------------+-----------+-------------------------+ 315 | Locator (L64) | Node Identifier (NID) | 316 +---+---------------------+-----------+-------------------------+ 318 Figure 3.2: Example of IPv6 address format as used in ILNPv6. 319 The global routing prefix bits and subnet ID bits above are 320 as for [RFC3177], but could be different, e.g. as for [RFC6177]. 322 The ILNPv6 Locator uses the upper 64-bits of the 128-bit IPv6 323 address space. It has the same syntax and semantics as today's 324 IPv6 routing prefix. So, an ILNPv6 packet carrying a Locator 325 value can be used just like an IPv6 packet today as far as core 326 routers are concerned. 328 The example in Figure 3.2 happens to use a /48 prefix, 329 as was recommended by [RFC3177]. However, more recent advice 330 is that prefixes need not be fixed at /48 and could be up 331 to /64 [RFC6177]. This change, however, does not impact 332 the syntax or semantics of the Locator value. 334 The ILNPv6 Identifier value uses the lower 64-bits of the 128-bit 335 IPv6 address. It has the same syntax as an IPv6 identifier, but 336 different semantics. This provides a fixed-length non-topological 337 name for a node. Identifiers are bound to nodes, not to 338 interfaces of a node. All ILNP Identifiers MUST comply with the 339 modified EUI-64 syntax already specified for IPv6's "Interface 340 Identifier" values, as described in Section 2.1. 342 IEEE EUI-64 Identifiers can have either global-scope or 343 local-scope. So ILNP Identifiers also can have either 344 global-scope or local-scope. A reserved bit in the modified 345 EUI-64 syntax clearly indicates whether a given Identifier has 346 global-scope or local-scope. A node is not required to 347 use a global-scope Identifier, although that is the recommended 348 practice. Note that the syntax of the Node Identifier field has 349 exactly the same syntax as that defined for IPv6 address in 350 Section 2.5.1 of RFC 4291 [RFC4291]. (This is based on the IEEE 351 EUI-64 syntax [IEEE-EUI], but is not the same.) 353 Most commonly, Identifiers have global-scope and are derived 354 from one or more IEEE 802 or IEEE 1394 'MAC Addresses' (sic) 355 already associated with the node, following the procedure 356 already defined for IPv6 [RFC4291]. Global-scope identifiers 357 have a high probability of being globally unique. This approach 358 eliminates the need to manage Identifiers, among other benefits. 360 Local-scope Identifiers MUST be unique within the context of 361 their Locators. The existing mechanisms of the IPv4 Address 362 Resolution Protocol [RFC826] and IPv6 State-Less Address 363 Auto-Configuration (SLAAC) [RFC4862] automatically enforce this 364 constraint. 366 For example, on an Ethernet-based IPv4 subnetwork the ARP Reply 367 message is sent via link-layer broadcast, thereby advertising the 368 current binding between an IPv4 address and a MAC address to all 369 nodes on that IPv4 subnetwork. (Note also that a well-known, 370 long standing, issue with ARP is that it cannot be 371 authenticated.) Local-scope Identifiers MUST NOT be used with 372 other Locators without first ensuring uniqueness in the context 373 of those other Locators e.g. by using IPv6 Neighbour Discovery's 374 Duplicate Address Detection mechanism when using ILNPv6 or by 375 sending an ARP Request when using ILNPv4. 377 Other methods might be used to generate local-scope Identifiers. 378 For example, one might derive Identifiers using some form of 379 cryptographic generation or using the methods specified in the 380 IPv6 Privacy Extensions [RFC4941] to State-Less Address Auto- 381 Configuration (SLAAC) [RFC4862]. When cryptographic generation of 382 Identifiers using methods described in RFC3972 is in use, only 383 the Identifier is included, never the Locator, thereby preserving 384 roaming capability. One could also imagine creating a local-scope 385 Identifier by taking a cryptographic hash of a node's public key. 386 Of course, in the unlikely event of a Identifier collision, for 387 example when a node has chosen to use a local- scope Identifier 388 value, the node remains free to use some other local-scope 389 Identifier value(s). 391 It is worth remembering here that an IPv6 address names a 392 specific network interface on a specific node, but an ILNPv6 393 Identifier names the node itself, not a specific interface on the 394 node. This difference in definition is essential to providing 395 seamless support for mobility and multi-homing, which are 396 discussed in more detail later in this note. 398 3.2 Network-level packet formats 400 ILNPv6 Locator and Identifier values are encoded into IPv6 401 address space and ILNPv6 uses directly the Classic IPv6 packet 402 format, as shown in Figure 3.3. This is also the view of an 403 ILNPv6 packet as seen by core routers - they simply use the 404 Locator value (top 64-bits of the address field) just as they 405 would use an IPv6 prefix today (e.g. either as /48 or as /64 406 when using sub-network routing). 408 0 1 2 3 409 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 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 |Version| Traffic Class | Flow Label | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Payload Length | Next Header | Hop Limit | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Source Address | 416 + + 417 | | 418 + + 419 | | 420 + + 421 | | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Destination Address | 424 + + 425 | | 426 + + 427 | | 428 + + 429 | | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 Figure 3.3: Existing ("Classic") IPv6 Header 434 In essence, the Locator names a subnetwork. (Locators can also be 435 referred to as Routing Prefixes if discussing Classic IPv6). Of 436 course, backwards compatibility requirements mean that ILNPv6 437 Locators use the same number space as IPv6 routing prefixes. 438 This ensures that no changes are needed to deployed IPv6 routers 439 when deploying ILNPv6. 441 The low-order 64-bits of the IPv6 address become the Identifier. 442 Details of the Identifier were discussed above. The Identifier is 443 only used by end-systems, so Figure 3.4 shows the view of the 444 same packet format, but as viewed by an ILNPv6 node. As this 445 only needs to be parsed in this way by the end-system, so ILNPv6 446 deployment is enabled incrementally by updating end-systems 447 as required. 449 0 1 2 3 450 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 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 |Version| Traffic Class | Flow Label | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Payload Length | Next Header | Hop Limit | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Source Locator | 457 + + 458 | | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Source Identifier | 461 | | 462 + + 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Destination Locator | 465 + + 466 | | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | Destination Identifier | 469 + + 470 | | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 Figure 3.4: ILNPv6 Header as seen by ILNPv6-enabled end-systems 475 3.3 Encoding of identifiers and locators for ILNPv4 477 Encoding of Identifier and Locator values for ILNPv4 is not as 478 straight-forward as for ILNPv6. In analogy to ILNPv6, in ILNPv4, 479 the Locator value is a routing prefix for IPv4, but is at most 30 480 bits. Source Locator values are carried in the source address 481 field of the IPv4 header, and destination Locator values in the 482 destination address field. So, just like for ILNPv6, for ILNPv4, 483 packet routing can be performed by routers examining existing 484 prefix values in the IPv4 header. 486 However, for ILNPv4, additional option headers have to be used to 487 carry the Identifier value as there is not enough room in the 488 normal IPv4 header fields. A 64-bit Identifier value is carried 489 in an option header. So, the detailed explanation of the ILNPv4 490 packet header is to be found in [ILNP-v4OPTS]. 492 4. TRANSPORT-LAYER CHANGES 494 ILNP uses an Identifier value in order to form the invariant 495 end-system state for end-to-end protocols. Currently, transport 496 protocols such as TCP and UDP use all the bits of an IP address 497 to form such state. So, transport protocol implementations MUST 498 be modified in order to operate over ILNP. 500 4.1 End-system state 502 Currently, TCP and UDP, for example, use the 4-tuple: 504 506 for the end-system state for a transport layer end-point. For 507 ILNP, implementations must be modified to instead use: 509 511 4.2 TCP/UDP Checksum Handling 513 In IP-based implementations, the TCP or UDP pseudo-header 514 checksum calculations include all the bits of the IP address. 515 By contrast, when calculating the TCP or UDP pseudo-header 516 checksums for use with ILNP, only the Identifier values are 517 included in the TCP or UDP pseudo-header checksum calculations. 519 To minimise the changes required within transport protocol 520 implementations, and to maximise interoperability, current 521 implementations are modified to zero the Locator fields (only for 522 the purpose of TCP or UDP checksum calculations). For example, 523 for ILNPv6, this means that the existing code for IPv6 can be 524 used, with the ILNPv6 Identifier bits occupying the lower 64 bits 525 of the IPv6 address field, and the upper 64 bits of the IPv6 526 address filed being set to zero. For ILNPv4, the Identifier 527 fields are carried in an IPv4 Option [ILNP-v4OPTS]. 529 Section 7 describes methods for incremental deployment of this 530 ILNP-specific change and backwards compatibility with non- 531 upgraded nodes (e.g. classic IPv4 or IPv6 nodes) in more detail. 533 4.3 ICMP Checksum Handling 535 To maximise backwards compatibility, the ILNPv6 ICMP checksum is 536 always calculated in the same way as for IPv6 ICMP. Similarly, 537 the ILNPv4 ICMP checksum is always calculated in the same way as 538 for IPv4 ICMP. 540 5. ILNP COMMUNICATION CACHE (ILCC) 542 For operational purposes, implementations need to have a local 543 cache of state information that allow communication end-points to 544 be constructed and for communication protocols to operate. Such 545 cache information is common today, e.g. IPv4 nodes commonly 546 maintain an Address Resolution Protocol (ARP) cache with 547 information relating to current and recent Correspondent Nodes; 548 IPv6 nodes maintain a Neighbor Discovery (ND) table with 549 information relating to current and CNs. Likewise, ILNP maintains 550 an Identifier-Locator Communication Cache (ILCC) with information 551 relating to the operation of ILNP. 553 The ILCC is a (logical) set of data values required for ILNP to 554 operate. These values are maintained by the endpoints of each 555 ILNP session. 557 In theory, this cache is within the ILNP network-layer. However, 558 many network protocol implementations do not have strict protocol 559 separation or layering. So there is no requirement that the ILCC 560 be kept partitioned from transport-layer protocols. 562 Note that in many implementations, much of the information 563 required for the ILCC may already be present. Where some 564 additional information is required for ILNP, from an engineering 565 viewpoint, the ILCC could be implemented by extending or 566 enhancing existing data structures within existing 567 implementations. For example, by adding appropriate flags to the 568 data structures in existing implementations. 570 Note that the ILCC does not impose any extra state maintenance 571 requirements for applications or applications servers. For 572 example, in the case of, say, HTTP, there will be no additional 573 state for a server to maintain, and any TCP state will be handled 574 by the ILNP code in the OS just as for IP. 576 5.1 Formal Definition 578 The ILCC contains information about both the local node and also 579 about current or recent correspondent nodes, as follows. 581 Information about the local node: 583 - Each currently valid Identifier value, 584 including its Identifier Precedence 585 and whether it is active at present. 587 - Each currently valid Locator value, including 588 its associated local interface(s), 589 its Locator Precedence, and 590 whether it is active at present. 592 - Each currently valid IL Vector (I-LV), including 593 whether it is active at present. 595 Information about each correspondent node: 597 - Most recent set of Identifiers, 598 including lifetime and validity for each. 600 - Most recent set of Locators, 601 including lifetime and validity for each. 603 - Nonce value for packets from the local host 604 to the correspondent. 606 - Nonce value for packets from the correspondent 607 to the local host. 609 In the above list for the ILNP Communication Cache: 611 - A "valid" item is usable, from an administrative point of 612 view, but might or might not be in use at present. 614 - The "validity" parameter for the correspondent node indicates 615 one of several different states for a datum. These include at 616 least the following: 618 - "valid" : data is usable and has not expired. 620 - "active" : data is usable, has not expired, 621 and is in active use at present. 623 - "expired" : data is still in use at present, 624 but is beyond its expiration (i.e. 625 without a replacement value). 627 - "aged" : data was recently in use, but is not 628 in active use at present, and is 629 beyond its expiration. 631 - The "lifetime" parameter is an implementation-specific 632 representation of the validity lifetime for the associated 633 data element. In normal operation, the Lifetime for a 634 correspondent node's Locator(s) are learned from the DNS 635 Time-To-Live (DNS TTL) value associated with DNS records 636 (NID, L32, L64 etc) of the FQDN owner name of the 637 correspondent node. For time, a node might use UTC 638 (e.g. via Network Time Protocol) or perhaps some 639 node-specific time (e.g. seconds since node boot). 641 5.2 Ageing ILCC Entries 643 As a practical engineering matter, it is not sensible to flush 644 all Locator values associated with an existing ILNP session's 645 correspondent node even if the DNS TTL associated with those 646 Locator values expires. 648 In some situations, a CN might be disconnected briefly when 649 moving location (e.g. immediate handover, which sometimes is 650 called "break before make"). If this happens, there might be a 651 brief pause before the Correspondent Node can (a) update its own 652 L values in the DNS, and (b) send an ICMP Locator Update message 653 to the local node with information about its new 654 location. Implementers ought to try to maintain ILNP sessions 655 even when such events occur. 657 Instead, Locator values cached for a correspondent node SHOULD be 658 marked as "aged" when their TTL has expired, but retained until 659 either the next Locator Update message is received, there is 660 other indication that a given Locator is not working any longer, 661 there is positive indication that the Correspondent Node has 662 terminated the ILNP session (e.g. TCP RST if the only 663 transport-layer session for this ILNP session is a TCP session), 664 until some appropriate timeout (e.g. 2*MSL for TCP if the only 665 transport-layer session for this ILNP session is a TCP session), 666 or the ILNP session has been inactive for several minutes 667 (e.g. no transport-layer session exists for this ILNP session) 668 and the storage space associated with the aged entry needs to be 669 reclaimed. 671 Separately, received authenticated Locator Update messages cause 672 the ILCC entries listed above to be updated. 674 Similarly, if there is indication that an ILNP session with a 675 Correspondent Node remains active and the DNS TTL associated with 676 that Correspondent Node's active Identifier value(s) has expired, 677 those remote Identifier value(s) ought to be marked as "expired", 678 but retained since they are in active use. 680 5.3 Large Numbers of Locators 682 Implementers should keep in mind that a node or site might have a 683 large number of concurrent Locators, and should ensure that a 684 system fault does not arise if the system receives an authentic 685 ICMP Locator Update containing a large number of Locator values. 687 5.4 Lookups into the ILCC 689 For received packets containing an ILNP Nonce Option, lookups in 690 the ILCC MUST use the tuple as the 691 lookup key. 693 For all other ILNP packets, lookups in the ILNP Correspondent 694 Cache MUST use the tuple, 695 i.e. the remote I-LV, as the lookup key. 697 These two checks between them facilitate situations where, 698 perhaps due to deployment of Local-scope Identifiers, more than 699 one correspondent node is using the same Identifier value. 701 (NOTE: Other mechanisms, such as IPv6 Neighbor Discovery, ensure 702 that 2 different nodes are incapable of using a given IL-V 703 at the same location i.e., on the same link.) 705 While Locators are omitted from the transport-layer checksum, an 706 implementation SHOULD use Locator values to distinguish between 707 correspondents coincidentally using the same Identifier value 708 (e.g. due to deployment of Local-scope Identifier values) when 709 demultiplexing to determine which application(s) should receive 710 the user data delivered by the transport-layer protocol. 712 6. HANDLING LOCATION/CONNECTIVITY CHANGES 714 In normal operation, an ILNP node uses the DNS for initial 715 rendezvous in setting up ILNP sessions. The use of DNS for 716 initial rendezvous with mobile nodes was earlier proposed by 717 others [PHG02] and then separately re-invented by the current 718 authors later on. 720 6.1 Node Location/Connectivity Changes 722 To handle the move of a node or a change to the upstream 723 connectivity of a multi-homed node, we add a new ICMP control 724 message [ILNP-ICMPv4] [ILNP-ICMPv6]. The ICMP Locator Update (LU) 725 message is used by a node to inform its existing CNs that the set 726 of valid Locators for the node has changed. This mechanism can 727 be used to add newly valid Locators, to remove no longer valid 728 Locators, or to do both at the same time. The LU mechanisms is 729 analogous to the Binding Update mechanism in Mobile IPv6, but in 730 ILNP, such messages are used any time Locator value changes need 731 to be notified to CNs, e.g. for multi-homed hosts as well as for 732 mobile hosts. 734 Further, if the node wishes to be able to receive new incoming 735 ILNP sessions, the node normally uses Secure Dynamic DNS Update 736 [RFC3007] to ensure that a correct set of Locator values are 737 present in the appropriate DNS records (i.e. L32, L64) in the DNS 738 for that node [ILNP-DNS]. This enables any new correspondents to 739 correctly initiate a new ILNP session with the node at its new 740 location. 742 While the Locator Update control message could be an entirely new 743 protocol running over UDP, for example, there is no obvious 744 advantage to creating a new protocol rather than using a new ICMP 745 message. So ILNP defines a new ICMP Locator Update message 746 for both IPv4 and IPv6. 748 6.2 Network Connectivity/Locator Changes 750 As a DNS performance optimisation, the LP DNS resource record MAY 751 be used to avoid requiring each node on a subnetwork to update 752 its DNS L64 record entries when that subnetwork's location 753 (e.g. upstream connectivity) changes [ILNP-DNS]. This can reduce 754 the number of DNS updates required when a subnetwork moves from 755 Order(number of nodes on subnetwork) to Order(1). 757 In this case, the nodes on the subnetwork each would have an LP 758 record pointing to a common Fully-Qualified Domain Name (FQDN) 759 used to name that subnetwork. In turn, that subnetwork's domain 760 name would have one or more L64 record(s) in the DNS. Since the 761 contents of an LP record are stable, relatively long DNS TTL 762 values can be associated with these records facilitating DNS 763 caching. By contrast, the DNS TTL of an L32 or L64 record for a 764 mobile or multi-homed node should be small. Experimental work at 765 the University of St Andrews indicates that the DNS continues to 766 work well even with very low (e.g. zero) DNS TTL values [BA11]. 768 Correspondents of a node on a mobile subnetwork using this DNS 769 performance optimisation would initially perform a normal FQDN 770 lookup for a node. If that lookup returned another FQDN in an LP 771 record as additional data, then the correspondent would perform a 772 lookup on that FQDN and expect an L32 or L64 record returned as 773 additional data, in order to learn the Locator value to use to 774 reach that target node. (Of course, a lookup that did not return 775 any ILNP-related DNS records would result in an ordinary IPv4 776 session or ordinary IPv6 session being initiated, instead.) 778 7. SUBNETTING 780 For ILNPv4 and ILNPv6, the Locator value includes the subnetting 781 information, as that also is topological information. As well as 782 being architecturally correct, the placement of subnetting as 783 part of the Locator is also convenient from an engineering point 784 of view in both IPv4 and IPv6. 786 We consider that a Locator value, L consists of two parts: 788 - L_pp: the Locator prefix part, which occupies the most 789 significant bits in the address (for both ILNPv4 and ILNPv6). 791 - L_ss: Locator subnetwork selector, which occupies bits just 792 after the L_pp. 794 For each of ILNPv4 and ILNPv6, L_pp gets its value from the 795 provider-assigned routing prefix for IPv4 and IPv6, respectively. 796 For L_ss, in each case of ILNPv4 and ILNPv6, the L_ss bits are 797 located in the part of the address space which you might expect 798 them to be located if IPv4 or IPv6 addresses were being used, 799 respectively. 801 7.1 Subnetting for ILNPv6 803 For ILNPv6, recall that the Locator value is encoded to be 804 syntactically similar to an IPv6 address prefix, as shown in 805 Figure 7.1. 807 /* IPv6 */ 808 | 3 | 45 bits | 16 bits | 64 bits | 809 +---+---------------------+-----------+-------------------------+ 810 |001|global routing prefix| subnet ID | Interface Identifier | 811 +---+---------------------+-----------+-------------------------+ 813 /* ILNPv6 */ 814 | 64 bits | 64 bits | 815 +---+---------------------+-----------+-------------------------+ 816 | Locator (L64) | Node Identifier (NID) | 817 +---+---------------------+-----------+-------------------------+ 818 +<-------- L_pp --------->+<- L_ss -->+ 820 L_pp = Locator prefix part (assigned IPv6 prefix) 821 L_ss = Locator subnet selector (locally managed subnet ID) 823 Figure 7.1: IPv6 address format [RFC3587] as used in ILNPv6, 824 showing how subnets can be identified. 826 Note that the subnet ID forms part of the Locator value. Note 827 also that [RFC6177] allows the global routing prefix to be more 828 than 45 bits, and for the subnet ID to be smaller, but still 829 preserving the 64-bit size of the Locator. 831 7.2 Subnetting for ILNPv4 833 For ILNPv4, the L_pp value is an IPv4 routing prefix as used 834 today, which is typically less than 32 bits. However, the ILNPv4 835 Locator value is carried in the 32-bit IP address space, so the 836 bits not used for the routing prefix could be used for L_ss, e.g. 837 for a /24 IPv4 prefix, the situation would be as shown in Fig 838 7.2. 840 24 bits 8 bits 841 +------------------------+----------+ 842 | Locator (L32) | 843 +------------------------+----------+ 844 +<------- L_pp --------->+<- L_ss ->+ 846 L_pp = Locator prefix part (assigned IPv4 prefix) 847 L_ss = Locator subnet selector (locally managed subnet ID) 849 Figure 7.2: IPv4 address format for /24 IPv4 prefix, as used in 850 ILNPv4, showing how subnets can be identified. 852 Note that the L_ss occupies bits that in an IPv4 address would 853 normally be the host part of the address, which the site network 854 could use for sub-netting in any case. 856 7.3 Subnetting for router-router links in IPv6/ILNPv6 858 There is a special case of /127 prefixes used in router-router, 859 point-to-point links links for IPv6 [RFC6164]. ILNPv6 does not 860 preclude such use. 862 8. DNS CONSIDERATIONS 864 ILNP makes use of DNS for name resolution, as does IP. Unlike 865 IP, ILNP also uses DNS to support features such as mobility and 866 multi-homing. While such usage is appropriate use of the DNS, it 867 is important to discuss operational and engineering issues that 868 may impact DNS usage. 870 8.1 Secure Dynamic DNS Update 872 When a host that expects incoming connections changes one or more 873 of its Locator values, the host normally uses the IETF Secure 874 Dynamic DNS Update protocol [RFC3007] to update the set of 875 currently valid Locator values associated with its Fully 876 Qualified Domain Name (FQDN). This ensures that the authoritative 877 DNS server for its FQDN will be able to generate an accurate set 878 of Locator values if the DNS server receives DNS name resolution 879 request for its FQDN. 881 Liu & Albitz [LA06] report that Secure Dynamic DNS Update has 882 been supported on the client-side for several years now in widely 883 deployed operating systems (e.g. MS Windows, Apple MacOS X, UNIX, 884 and Linux) and also in DNS server software (e.g. BIND). Publicly 885 available product data sheets indicate that some other DNS server 886 software packages, such as that from Nominum, also support this 887 capability. 889 For example, Microsoft Windows XP (and later versions), the 890 freely distributable BIND DNS software package (used in Apple 891 MacOS X and in most UNIX systems), and the commercial Nominum DNS 892 server all implement support for Secure Dynamic DNS Update and 893 are known to interoperate [LA06]. There are credible reports 894 that when a site deploys Microsoft's Active Directory, the site 895 (silently) automatically deploys Secure Dynamic DNS Update 896 [LA06]. So, many sites have already deployed Secure Dynamic DNS 897 Update even though they are not actively using it (and might not 898 be aware they have already deployed that protocol) [LA06]. 900 So DNS update via Secure Dynamic DNS Update is not only 901 standards-based, but also readily available in widely deployed 902 systems today. 904 8.3 New DNS RR types 906 As part of this proposal, additional DNS Resource Records have 907 been proposed in a separate document [ILNP-DNS]. These new 908 records are summarised in Table 6.1. 910 new DNS RR type | Purpose 911 -----------------+------------------------------------------------ 912 NID | store the value of a Node Identifier 913 L32 | store the value of a 32-bit Locator for ILNPv4 914 L64 | store the value of a 64-bit Locator for ILNPv6 915 LP | points to a (several) L32 and/or L64 record(s) 916 -----------------+------------------------------------------------ 918 Table 6.1: Summary of new DNS RR types for ILNP 920 With this proposal, mobile or multi-homed nodes and sites are 921 expected to use the existing "Secure Dynamic DNS Update" protocol 922 to keep their Node Identifier (NID) and Locator (L32 and/or L43) 923 records correct in their authoritative DNS server(s) [RFC3007] 924 [ILNP-DNS]. 926 Reverse DNS lookups, to find a node's Fully Qualified Domain Name 927 from the combination of a Locator and related Identifier value, 928 can be performed as at present. 930 8.4 DNS TTL values for ILNP RRS types 932 Existing DNS specifications require that DNS clients and DNS 933 resolvers honour the TTL values provided by the DNS servers. In 934 the context of this proposal, short DNS TTL values are assigned 935 to particular DNS records to ensure that the ubiquitous DNS 936 caching resolvers do not cache volatile values (e.g. Locator 937 records of a mobile node) and consequently return stale 938 information to new requestors. 940 The time-to-live (TTL) values for L32 and L64 records may have to 941 be relatively low (perhaps a few seconds) in order to support 942 mobility and multi-homing. Low TTL values may be of concern to 943 administrators who might think that this would reduce efficacy of 944 DNS caching increase DNS load significantly. 946 Previous research by others indicates that DNS caching is largely 947 ineffective, with the exception of NS records and the addresses 948 of DNS servers referred to by NS records [SBK02]. This means 949 DNS caching performance and DNS load will not be adversely 950 affected by assigning very short TTL values (down to zero) to the 951 Locator records of typical nodes for a edge site [BA11]. It 952 also means that it is preferable to deploy the DNS server 953 function on nodes that have longer DNS TTL values, rather than on 954 nodes that have shorter DNS TTL values. 956 LP records normally are stable and will have relatively long TTL 957 values, even if the L32 or L64 records they point to have values 958 that have relatively low TTL values. 960 Identifier values might be very long-lived (e.g. days) when they 961 have been generated from an IEEE MAC address on the 962 system. Identifier values might have a shorter lifetime 963 (e.g. hours or minutes) if they have been cryptographically- 964 generated [RFC3972], or have been created by the IPv6 Privacy 965 Extensions [RFC4941], or otherwise have the EUI-64 scope bit set 966 to "local-scope". Note that when ILNP is used, the cryptographic 967 generation method described in RFC 3972 is used only for the 968 Identifier, omitting the Locator, thereby preserving roaming 969 capability. Note that a given ILNP session normally will use a 970 single Identifier value for the lifetime of that ILNP session. 972 8.5 IP/ILNP dual operation and transition 974 During a long transition period, a node that is ILNP-capable 975 SHOULD have not only have NID and L32/L64 (or NID and LP) records 976 present in its authoritative DNS server, but also SHOULD have 977 A/AAAA records in the DNS for the benefit of non-upgraded 978 nodes. Then, when any CN performs an FQDN lookup for that node, 979 it will receive the A/AAAA with the appropriate NID, L32/L64 980 and/or LP records as "additional data". 982 Existing DNS specifications require that a DNS resolver or DNS 983 client ignore unrecognised DNS record types. So gratuitously 984 appending NID and Locator (i.e., L32, L64, or LP) records as 985 "additional data" in DNS responses to A/AAAA queries ought not to 986 create any operational issues. So, IP only nodes would use the 987 A/AAAA RRs, but ILNP-capable nodes would be able to use the NID, 988 L32/L64 and/or LP records are required. 990 There is nothing to prevent this capability being implemented 991 strictly inside a DNS server, whereby the DNS server synthesises 992 a set of A/AAAA records to advertise from the NID and Locator 993 (i.e., L32, L64, or LP) values that the node has kept updated in 994 that DNS server. Indeed, such a capability may be desirable, 995 reducing the amount of manual configuration required for a site, 996 and reducing the potential for errors as the A/AAAA records would 997 be automatically generated. 999 9. IP Security for ILNP 1000 The primary conceptual difference from ordinary IP Security 1001 (IPsec) is that ILNP IP Security omits all use of, and all 1002 reference to, Locator values. This leads to several small, 1003 but important, changes to IP Security when it is used with 1004 ILNP sessions. 1006 9.1 IPsec Security Associations enhancements for ILNP 1008 IPsec Security Associations for ILNP only include the Identifier 1009 values for the endpoints, and omit the Locator values. As an 1010 implementation detail, ILNP implementations MUST be able to 1011 distinguish between different Security Associations with ILNP 1012 correspondents (at different locations, with different ILNP Nonce 1013 values in use) that happen to use the same Identifier values 1014 (e.g. due to an inadvertent Identifier collision when using 1015 identifier values generated by using the IPv6 Privacy Addressing 1016 extension). One possible way to distinguish between such 1017 different ILNP sessions is to maintain a mapping between the IPsec 1018 Security Association Database (SAD) entry and the corresponding 1019 ILCC entry. 1021 Consistent with this enhancement to the definition of an IPsec 1022 Security Association, when processing received IPsec packets 1023 associated with an ILNP session, ILNP implementations ignore the 1024 Locator bits of the received packet and only consider the 1025 Identifier bits. This means, for example, that if an ILNP 1026 correspondent node moves to a different subnetwork, and thus is 1027 using a different Source Locator in the header of its ILNP IPsec 1028 packets, the ILNP session will continue to work and will continue 1029 to be secure. 1031 Since implementations of ILNP are also required to support IP, 1032 implementers need to ensure that ILNP IPsec Security Associations 1033 can be distinguished from ordinary IPsec Security Associations. 1034 The details of this are left to the implementer. As an example, 1035 one possible implementation strategy would be to retain a single 1036 IPsec Security Association Database (SAD), but add an internal 1037 flag bit to each entry of that IPsec Security Association 1038 Database (SAD) to indicate whether ILNP is in use for that 1039 particular IPsec Security Association. 1041 9.2 IP Authentication Header enhancements for ILNP 1043 Similarly, for an ILNP session using IPsec, the IPsec 1044 Authentication Header (AH) only includes the Identifier values 1045 for the endpoints in its authentication calculations, and omits 1046 the Source Locator and Destination Locator fields from its 1047 authentication calculations. This enables IPsec AH to work well 1048 even when used with ILNP localised numbering [ILNP-ADV] or other 1049 situations where a Locator value might change while the packet 1050 travels from origin to destination. 1052 9.3 Key Management Considerations 1054 In order to distinguish at the network-layer between multiple 1055 ILNP nodes that happen to be using the same Node Identifier 1056 values (e.g. because the identifier values were generated using 1057 the IPv6 Privacy Addressing method), key management packets being 1058 used to setup an ILNP IPsec session MUST include the ILNP Nonce 1059 option. 1061 Similarly, key management protocols used with IPsec are enhanced 1062 to deprecate use of IP addresses as identifiers and to substitute 1063 the use of the new Node Identifier values for that purpose. This 1064 results in an ILNP IPsec Security Association that is independent 1065 of the Locator values that might be used. 1067 For ILNPv6 implementations, the ILNP Node Identifier (64-bits) is 1068 smaller than the IPv6 Address (128-bits). So support for ILNPv6 1069 IPsec is accomplished by zeroing the upper-64 bits of the IPv6 1070 Address fields in the application-layer key management protocol, 1071 while retaining the Node Identifier value in the lower-64 bits of 1072 the application-layer key management protocol. 1074 For ILNPv4 implementations, enhancements to the key management 1075 protocol likely will be needed, because existing key management 1076 protocols rely on 32-bit IPv4 addresses, while ILNP Node 1077 Identifiers are 64-bits. Such enhancements are beyond the scope 1078 of this specification. 1080 10. BACKWARDS COMPATIBILITY & INCREMENTAL DEPLOYMENT 1082 Experience with IPv6 deployment over the past many years has 1083 shown that it is important for any new network protocol to 1084 provide backwards compatibility with the deployed IP base and 1085 should be incrementally deployable, ideally requiring 1086 modification of only those nodes that wish to use ILNP and not 1087 requiring the modification of nodes that do not intend to use 1088 ILNP. The two instances of ILNP, ILNPv4 and ILNPv6, are intended 1089 to be, respectively, backwards compatible with, and incrementally 1090 deployable on, the existing IPv4 and IPv6 installed bases. 1091 Indeed, ILNPv4 and ILNPv6 can each be seen, from an engineering 1092 viewpoint, as supersets of the IPv4 and IPv6, respectively. 1094 However, in some cases, ILNP introduces functions that supersede 1095 equivalent functions available in IP. For example, ILNP has a 1096 mobility model, and so does not need to use the models for Mobile 1097 IPv4 or Mobile IPv6. 1099 As ILNP changes the use of end-to-end namespaces, for the most 1100 part, it is only end-systems that need to be modified. However, 1101 in order to leverage existing engineering (e.g. existing 1102 protocols), in some cases, there is a compromise, and these are 1103 highlighted in this section. 1105 10.1 Priorities in the design of ILNPv6 and ILNPv4 1107 In the engineering design of ILNPv6 and ILNPv4, we have used the 1108 following priorities. In some ways, this choice is arbitrary, and 1109 it may be equally valid to "invert" these priorities for a 1110 different architectural and engineering design. 1112 1. Infrastructure 1114 As much of the deployed IP network infrastructure should be 1115 used without change. That is, routers and switches should 1116 require minimal or zero modifications in order to run 1117 ILNP. As much as possible of the existing installed base of 1118 core protocols should be re-used. 1120 2. Core protocols 1122 As much of the deployed network control protocols, such as 1123 routing, should be used without change. That is, existing 1124 routing protocols and switch configuration should require 1125 minimal or zero modifications in order to run ILNP. 1127 3. Scope of end-system changes 1129 Any nodes that do not need to run ILNP should not need to be 1130 upgraded. It should be possible to have a site network that 1131 has a mix of IP-only and ILNP-capable nodes without any 1132 changes required to the IP-only nodes. 1134 4. Applications 1136 There should be minimal impact on applications, even though 1137 ILNP requires end-to-end protocols to be upgraded. Indeed, 1138 for those applications that are "well-behaved" (e.g. do not 1139 use IP address values directly for application state or 1140 application configuration), there should be little or no 1141 effort required in enabling them to operate over ILNP. 1143 Each of these items is discussed in its own section below. 1145 10.2 Infrastructure 1147 ILNP is designed to be deployed on existing infrastructure. No 1148 new infrastructure is required to run ILNP as it will be 1149 implemented as a software upgrade impacting only end-to-end 1150 protocols. Existing routing protocols can be re-used: no new 1151 routing protocols are required. This means that network operators 1152 and service providers do not need to learn about, test, and 1153 deploy new protocols, or change the structure of their network in 1154 order for ILNP to be deployed. Exceptionally, edge routers 1155 supporting ILNPv4 hosts will need to support an enhanced version 1156 of ARP. 1158 10.3 Core protocols 1160 Existing routing and other control protocols should not need to 1161 change in devices such as switches and routers. We believe this 1162 to be true for ILNPv6. However, for ILNPv4, we believe that ARP 1163 will need to be enhanced in edge routers (or layer-3 switches) 1164 that support ILNPv4 hosts. Backbone and transit routers still 1165 ought not require changes for either ILNPv4 or ILNPv6. 1167 For both ILNPv4 and ILNPv6, the basic packet format for packets 1168 re-uses that format that is seen by routers for IPv4 and IPv6 1169 respectively. Specifically, as the ILNP Locator value is always a 1170 routing prefix (either IPv4 or IPv6), routing protocols should 1171 work unchanged. 1173 Both ILNPv4 and ILNPv6 introduce new header options (e.g Nonce 1174 Option messages) and ICMP messages (e.g. Locator Update messages) 1175 which are used to enable end-to-end signalling. For packet 1176 forwarding, depending on the forwarding policies used by some 1177 providers or site border routers, there may need to be 1178 modifications to those policies to allow the new header options 1179 and new ICMP messages to be forwarded. However, as the header 1180 options and new ICMP messages are end-to-end, such modifications 1181 are likely to be in configuration files (or firewall policy on 1182 edge routers), as core routers do NOT need to parse and act upon 1183 the information contained in the header options or ICMP messages. 1185 10.4 Scope of end-system changes 1187 Only end-systems that need to use ILNP need to be updated in 1188 order for ILNP to be used at a site. 1190 There are three exceptions to this statement as follows: 1192 a) ILNPv4 ARP: as the Identifier value for IPv4 cannot fit into 1193 the normal 20-byte IPv4 packet header (a header extension is 1194 used), ARP must be modified. This only impacts end-systems 1195 that use ILNPv4 and those switches or site-border routers 1196 that are the first hop from an ILNPv4 node. For ILNPv6, as 1197 the I and L values fit into the existing basic IPv6 packet, 1198 IPv6 Neighbour Discovery can operate without modification 1200 b) Use of IP NAT: Where IP NAT or NAPT is in use for a site, 1201 existing NAT/NAPT device will re-write address fields in 1202 ILNPv4 packets or ILNPv6 packets. To avoid this, the NAT 1203 should either (i) be configured to allow the pass-through of 1204 packets originating from ILNP-capable nodes (e.g. by 1205 filtering on source address fields in the IP header); 1206 or (ii) should be enhanced to recognise ILNPv4 or ILNPv6 1207 packets (e.g. by looking for the ILNP Nonce option). 1209 c) Site border routers (SBRs) in ILNP Advanced Deployment 1210 scenarios: There are options to use an ILNP-capable site 1211 border router (SBR) as described in another document 1212 [ILNP-ADV]. In such scenarios, the SBR(s) need to be 1213 ILNP-capable. 1215 Other than these exceptions, it is entirely possible to have a 1216 site that uses a mix of IP and ILNP nodes and requires no changes 1217 to nodes other than the nodes that wish to use ILNP. For example, 1218 if a user on a site wishes to have his laptop use ILNPv6, only 1219 that laptop would need to have an upgraded stack: no other 1220 devices (end-systems, layer-2 switches or routers) at that site 1221 would need to be upgraded. 1223 10.5 Applications 1225 As noted, in the Architecture Description [ILNP-ARCH], those 1226 applications that do not use IP address values in application 1227 state or configuration data are considered to be "well-behaved". 1228 Applications that work today through a NAT or NAPT device without 1229 application-specific support are also considered "well behaved". 1230 Such applications might use DNS FQDNs or application-specific 1231 name spaces. (Note Well: application-specific name spaces should 1232 not be derived from IP address values). 1234 For well-behaved applications, replacing IP with ILNP should have 1235 no impact. That is, well-behaved applications should work 1236 unmodified over ILNP. 1238 Those applications that use directly IP address values in 1239 application state or configuration will need to be modified for 1240 operation over ILNP. Examples of such applications include: 1242 - FTP: which uses IP address values in the application layer 1243 protocol. In practice, use of Secure Copy (SCP) is growing, 1244 while use of FTP is either flat or declining, in part due 1245 to the improved security provided by SCP. 1247 - SNMP: which uses IP address values in MIB definitions, and 1248 values derived from IP address values in SNMP object names. 1250 Further experimentation in this area is planned to validate 1251 these details. 1253 10.6 Interworking between IP and ILNP 1255 A related topic is interworking: for example, how would an IPv6 1256 node communicate with an ILNPv6 node? Currently, we make the 1257 assumption that ILNP nodes "drop down" to using IP when 1258 communicating with a non-ILNP capable node, i.e. there is no 1259 interworking as such. In the future, it may be beneficial to 1260 define interworking scenarios that do not rely on having ILNP 1261 nodes fall back to IP, for example by the use of suitable 1262 protocol translation gateways or middleboxes. 1264 For now, a simplified summary of the process for interaction 1265 between ILNP hosts and non-ILNP hosts is as follows: 1267 a) For a host initiating communication using DNS, the resolution 1268 of the FQDN for the remote host will return at least one NID 1269 record and at least one of an L32 record (for ILNPv4) or an 1270 L64 record (for ILNPv6). Then the host knows that the remote 1271 host supports ILNP. 1273 b) When a host has I and L values for a remote host, the initial 1274 packet to initiate communication MUST contain a Nonce Header 1275 [ILNP-v4OPTS] [ILNP-NONCEv6] which indicates to the remote 1276 host that this packet is attempting to set-up an ILNP session. 1278 c) When a receiving host sees a Nonce Header, if it DOES support 1279 ILNP it will proceed to set-up an ILNP session. 1281 d) When a receiving host sees a Nonce Header, if it DOES NOT 1282 support ILNP it will reject the packet and this will be 1283 indicated to the sender through an ICMP message [ILNP-ICMPv6] 1284 [ILNP-ICMPv4]. Upon receiving the ICMP messages, the sender 1285 will re-initiate communication using standard IPv4 or IPv6. 1287 Many observers in the community expect IPv4 to remain in place 1288 for a long time even though IPv6 has been available for over a 1289 decade. With a similar anticipation, it is likely that in the 1290 future there will be a mixed environment of both IP and ILNP 1291 hosts. Until there is a better understanding of the deployment 1292 and usage scenarios that will develop, it is not clear what 1293 interworking scenarios would be useful to define and focus on 1294 between IP and ILNP. 1296 11. SECURITY CONSIDERATIONS 1298 There are numerous security considerations for ILNP from an 1299 engineering viewpoint. Overall, ILNP and its capabilities are no 1300 less secure than IP and equivalent IP capabilities. In some 1301 cases, ILNP has the potential to be more secure, or offer 1302 security capability in a more harmonised manner, for example with 1303 ILNP's use of IPsec in conjunction with multi-homing and mobility. 1304 [ILNP-ARCH] describes several security considerations that apply 1305 to ILNP and is included here by reference. 1307 ILNP offers an enhanced version of IP Security (IPsec). The 1308 details of IP Security for ILNP were described separately above. 1309 All ILNP implementations MUST support the use of the IP 1310 Authentication Header (AH) for ILNP and also the IP Encapsulating 1311 Security Payload (ESP) for ILNP, but deployment and use of IPsec 1312 for ILNP remains a matter for local operational security policy. 1314 11.1 Authenticating ICMP Messages 1316 Separate documents propose a new IPv4 Option [ILNP-v4OPTS] and 1317 a new IPv6 Destination Option [ILNP-NONCEv6]. Each of these 1318 options can be used to carry a ILNP Nonce value end-to-end 1319 between communicating nodes. That nonce provides protection 1320 against off-path attacks on an ILNP session. These ILNP Nonce 1321 options are used ONLY for ILNP and not for IP. The nonce values 1322 are exchanged in the initial packets of an ILNP session by 1323 including them in those initial/handshake packets. 1325 ALL ICMP Locator Update messages MUST include an ILNP Nonce 1326 option and also MUST include the correct ILNP Nonce value for the 1327 claimed sender and intended recipient of that ICMP Locator Update 1328 message. There are no exceptions to this rule. ICMP Locator 1329 Update messages MAY be protected by IP Security (IPsec), but 1330 still MUST include an ILNP Nonce option and the ILNP Nonce 1331 option still MUST include the correct ILNP Nonce value. 1333 When a node has an active ILNP session, and that node changes its 1334 Locator set, it SHOULD include the apropriate ILNP Nonce Option 1335 in the first few data packets sent using a new Locator value, 1336 so that the recipient can validate the received data packets 1337 as valid (despite having an unexpected Source Locator value). 1339 Any ILNP Locator Update messages received without an ILNP Nonce 1340 option MUST be discarded as forgeries. 1342 Any ILNP Locator Update messages received with an ILNP Nonce 1343 option, but do NOT have the correct ILNP Nonce value inside the 1344 ILNP Nonce option, MUST be discarded as forgeries. 1346 When the claimed sender of an ICMP message is known to be a 1347 current ILNP correspondent of the recipient (e.g. has a valid, 1348 non-expired, ILCC entry), then any ICMP error messages from that 1349 claimed sender MUST include the ILNP Nonce option and MUST 1350 include the correct ILNP Nonce value (i.e. correct for that 1351 sender recipient pair) in that ILNP Nonce option. 1353 When the claimed sender of an ICMP error message is known to be 1354 a current ILNP correspondent of the recipient (e.g. has a valid, 1355 non-expired, ILCC entry), then any ICMP error messages from that 1356 claimed sender that are received without an ILNP Nonce option 1357 MUST be discarded as forgeries. 1359 When the claimed sender of an ICMP error message is known to be 1360 a current ILNP correspondent of the recipient (e.g. has a valid, 1361 non-expired, ILCC entry), then any ICMP error messages from that 1362 claimed sender that contain an ILNP Nonce option, but do NOT 1363 have the correct ILNP Nonce value inside the ILNP Nonce option, 1364 MUST be discarded as forgeries. 1366 ICMP messages (not including ICMP Locator Update messages) with 1367 a claimed sender that is NOT known to be a current ILNP 1368 correspondent of the recipient (e.g. does not have a valid, 1369 non-expired, ILCC entry) MAY include the ILNP Nonce option, 1370 but in this case the ILNP Nonce option is ignored by the 1371 recipient upon receipt, since the recipient has no way to 1372 authenticated the received ILNP Nonce value. 1374 Received ICMP messages (not including ICMP Locator Update 1375 messages) with a claimed sender that is NOT known to be a current 1376 ILNP correspondent of the recipient (e.g. does not have a valid, 1377 non-expired, ILCC entry) do NOT require the ILNP Nonce option, 1378 because the security risks are no different than for deployed 1379 IPv4 and IPv6 -- provided that the received ICMP message is not 1380 an ICMP Locator Update message. Such ICMP messages 1381 (e.g. Destination Unreachable, Packet Too Big) might legitimately 1382 originate in an intermediate system along the path of an ILNP 1383 session. That intermediate system might not be ILNP capable. 1384 Even if ILNP capable itself, that intermediate system might not 1385 know which packets it forwards are part of ILNP sessions. 1387 When ILNP is in use, IP Security for ILNP also MAY be used to 1388 protect stronger protections for ICMP packets associated with an 1389 ILNP session. Even in this case, the ILNP Nonce option also MUST 1390 be present and MUST contain the correct ILNP Nonce value. This 1391 simplifies packet processing, and also enables rapid discard of 1392 any forged packets from an off-path attacker that lack either the 1393 ILNP Nonce option or the correct ILNP Nonce value -- without 1394 requiring computationally-expensive IPsec processing. Received 1395 ICMP messages that are protected by ILNP IP Security, but fail 1396 the recipient's IP Security checks, MUST be dropped as forgeries. 1397 If a deployment chooses to use ILNP IPsec ESP to protect its ICMP 1398 messages and is NOT also using ILNP IPsec AH with those messages, 1399 then the ILNP Nonce option MUST be placed in the ILNP packet 1400 after the ILNP IPsec ESP header, rather than before the ILNP 1401 IPsec ESP header, to ensure that the Nonce option is protected in 1402 transit. 1404 Receipt of any ICMP message that is dropped or discarded as a 1405 forgery SHOULD cause the details of the received forged ICMP 1406 packet (e.g. Source and Destination Locators / Source and 1407 Destination Identifiers / Source and Destination IP addresses, 1408 ICMP message type, receiving interface, receive date, receive 1409 time) to be logged in the receiving system's security logs. 1410 Implementations MAY rate-limit such logging in order to reduce 1411 operational risk of denial-of-service attacks on the system 1412 logging functions. The details of system logging are 1413 implementation-specific. 1415 11.2 Forged Identifier Attacks 1417 The ILNP Communication Cache (ILCC) contains two unidirectional 1418 nonce values (one used in control messages sent by this node, a 1419 different one used to authenticate messages from the other node) 1420 for each active or recent ILNP session. The ILCC also contains 1421 the currently valid set of Locators and set of Identifiers for 1422 each correspondent node. 1424 If a received ILNP packet contains valid Identifier values and a 1425 valid Destination Locator, but contains a Source Locator value 1426 that is not present in the ILCC, the packet MUST be dropped as an 1427 invalid packet and a security event SHOULD be logged, UNLESS the 1428 packet also contains a Nonce Destination Option with the correct 1429 value used for packets from the node with that Source Identifier 1430 to this node. This prevents an off-path attacker from stealing an 1431 existing ILNP session. 1433 12. PRIVACY CONSIDERATIONS 1435 There are no additional privacy issues created by ILNP compared 1436 to IP. Please see Section 10 of [ILNP-ARCH] for more detailed 1437 discussion of Privacy Considerations. 1439 ILNPv6 supports use of the IPv6 Privacy Extensions for Stateless 1440 Address Auto-configuration in IPv6 [RFC4941] to enable identity 1441 privacy (see also Section 2). 1443 Location Privacy can be provided by locator re-writing techniques 1444 as described in Section 7 of [ILNP-ADV]. 1446 A description of various possibilities for obtaining both identity 1447 privacy and location privacy with ILNP can be found in [BAK11]. 1449 13. OPERATIONAL CONSIDERATIONS 1451 This section covers various operational considerations relating 1452 to ILNP, including potential session liveness and reachability 1453 considerations and Key Management considerations. Again, the 1454 situation is similar to IP, but it is useful to explain the 1455 issues in relation to ILNP nevertheless. 1457 13.1 Session Liveness and Reachability 1459 For bi-directional flows, such as a TCP/ILNP session, each node 1460 knows whether the current path in use is working by the reception 1461 of data packets, acknowledgements, or both. Therefore, as with 1462 TCP/IP, TCP/ILNP does not need special path probes. UDP/ILNP 1463 sessions with acknowledgements work similarly, and also do not 1464 need special path probes. 1466 In the deployed Internet, the sending node for a UDP/IP session 1467 without acknowledgements does not know for certain that all 1468 packets are received by the intended receiving node. Such 1469 UDP/ILNP sessions have the same properties as UDP/IP sessions in 1470 this respect. The receiver(s) of such an UDP/ILNP session SHOULD 1471 send a gratuitous IP packet containing an ILNP Nonce option to 1472 the sender, in order to enable the receiver to subsequently send 1473 ICMP Locator Updates if appropriate [ILNP-NONCEv6]. In this case, 1474 UDP/ILNP sessions fare better than UDP/IP sessions, still without 1475 using network path probes. 1477 A mobile (or multi-homed) node may change its connectivity more 1478 quickly than DNS can be updated. This situation is unlikely, 1479 particularly given the widespread use of link-layer mobility 1480 mechanisms (e.g. GSM, IEEE 802 bridging) in combination with 1481 network-layer mobility. However, the situation is equivalent to 1482 the situation where a traditional IP node is moving faster than 1483 the Mobile IPv4 or Mobile IPv6 agents/servers can be updated with 1484 the mobile node's new location. So the issue is not new in any 1485 way to ILNP. In all cases, Mobile IPv4 and Mobile IPv6 and ILNP, 1486 a node moving that quickly might be temporarily unreachable until 1487 it remains at a given network-layer location (e.g. IP subnetwork, 1488 ILNP Locator value) long enough for the location update 1489 mechanisms (for Mobile IPv4, for Mobile IPv6, or ILNP) to catch 1490 up. 1492 Another potential issue for IP is what is sometimes called "Path 1493 Liveness" or, in the case of ILNP, "Locator Liveness". This 1494 refers to the question of whether an IP packet with a particular 1495 destination Locator value will be able to reach the intended 1496 destination network or not, given that some otherwise valid paths 1497 might be unusable by the sending node (e.g. due to security 1498 policy or other administrative choice). In fact, this issue has 1499 existed in the IPv4 Internet for decades. 1501 For example, an IPv4 server might have multiple valid IP 1502 addresses, each advertised to the world via an DNS A 1503 record. However, at a given moment in time, it is possible that a 1504 given sending node might not be able to use a given (otherwise 1505 valid) destination IPv4 address in an IP packet to reach that 1506 IPv4 server. 1508 Indeed, for ILNPv6, as the ILNP packet reuses the IPv6 packet 1509 header and uses IPv6 routing prefixes as Locator values, such 1510 liveness considerations are no worse than they are for IPv6 1511 today. For example, for IPv6, if a host, H, performs a DNS lookup 1512 for an FQDN for remote host F, and receives a AAAA RR with IPv6 1513 address F_A, this does not mean necessarily that H can reach F on 1514 its F_A using its current connectivity, i.e. an IPv6 path may not 1515 be available from H to F at that point in time. 1517 So we see that using an Identifier/Locator Split architecture 1518 does not create this issue, nor does it make this issue worse 1519 than it is with the deployed IPv4 Internet. 1521 In ILNP, the same conceptual approach described in [RFC5534] 1522 (Locator Pair Exploration for SHIM6) can be reused. 1523 Alternatively, an ILNP node can reuse the existing IPv4 methods 1524 for determining whether a given path to the target destination is 1525 currently usable, for which existing methods leverage 1526 transport-layer session state information that the communicating 1527 end systems are already keeping for transport-layer protocol 1528 reasons. 1530 Lastly, it is important to note that the ICMP Locator Update 1531 mechanism described in [ILNP-ICMPv6] [ILNP-ICMPv4] is a 1532 performance optimisation, significantly shortening the 1533 network-layer handoff time if/when a correspondent changes 1534 location. Architecturally, using ICMP is no different from 1535 using UDP, of course. 1537 13.2 Key Management Considerations 1539 ILNP potentially has advantages over either form of Mobile IP 1540 with respect to key management, given that ILNP is using Secure 1541 Dynamic DNS Update -- which capability is much more widely 1542 available today in deployed desktop and server environments 1543 (e.g. Microsoft Windows, MacOS X, Linux, other UNIX), as well as 1544 being widely available today in deployed DNS server software 1545 (e.g. Microsoft and the freely available BIND) and appliances 1546 [LA06], than the Security enhancements needed by either Mobile 1547 IPv4 or Mobile IPv6. 1549 IETF work in progress is addressing use of DNS to support key 1550 management for entities having DNS Fully-Qualified Domain Names. 1552 13.3 Point-to-Point Router Links 1554 As a special case, for the operational reasons described in 1555 [RFC6164], ILNPv6 deployments MAY continue to use classic IPv6 1556 with a /127 routing prefix on router to router point-to-point 1557 links (e.g. SONET/SDH). Because an ILNPv6 packet and an IPv6 1558 packet are indistinguishable for forwarding purposes to a transit 1559 router, this should not create any operational difficulty for 1560 ILNPv6 traffic travelling over such links. 1562 14. REFERRALS & APPLICATION PROGRAMMING INTERFACES 1564 This section is concerned with support for using existing 1565 ("legacy") applications over ILNP, including both referrals and 1566 Application Programming Interfaces (APIs). 1568 ILNP does NOT require well-behaved applications be modified to 1569 use a new networking API, nor does it require applications be 1570 modified to use extensions to an existing API. Existing 1571 well-behaved IP applications should work over ILNP without 1572 modification using existing networking APIs. 1574 14.1 BSD Sockets APIs 1576 The existing BSD Sockets API can continue to be used with ILNP 1577 underneath the API. That API can be implemented in a manner that 1578 hides the underlying protocol changes from the applications. For 1579 example, the combination of a Locator and an Identifier can be 1580 used with the API in the place of an IPv6 address. 1582 So it is believed that existing IP address referrals can continue 1583 to work properly in most cases. For a rapidly moving target node, 1584 referrals might break in at least some cases. The potential for 1585 referral breakage is necessarily dependent upon the specific 1586 application and implementation being considered. 1588 It is suggested, however, that a new, optional, more abstract, C 1589 language API be created so that new applications may avoid 1590 delving into low-level details of the underlying network 1591 protocols. Such an API would be useful today, even with the 1592 existing IPv4 and IPv6 Internet, whether or not ILNP were ever 1593 widely deployed. 1595 14.2 Java (and other) APIs 1597 Most existing Java APIs already use abstracted network 1598 programming interfaces, for example in the java.Net.URL 1599 class. Because these APIs already hide the low-level 1600 network-protocol details from the applications, the applications 1601 using these APIs (and the APIs themselves) don't need any 1602 modification to work equally well with IPv4, IPv6, ILNP, and 1603 probably also HIP. 1605 Other programming languages, such as C++, python and ruby, also 1606 provide higher-level APIs that abstract away from sockets, even 1607 though sockets may be used beneath those APIs. 1609 14.3 Referrals in the Future 1611 The approach proposed in [ID-Referral] appears to be very 1612 suitable for use with ILNP, in addition to being suitable for use 1613 with the deployed Internet. Protocols using that approach would 1614 not need modification to have their referrals work well with 1615 IPv4, IPv6, ILNP, and probably also other network protocols 1616 (e.g. HIP). 1618 A sensible approach to referrals is to use Fully-Qualified Domain 1619 Names (FQDNs), as is commonly done today with web URLs. This 1620 approach is highly portable across different network protocols, 1621 even with both the IPv4 Internet or the IPv6 Internet. 1623 15. IANA CONSIDERATIONS 1625 There are no IANA considerations. 1627 (The RFC Editor is requested to remove this section prior to 1628 publication.) 1630 16. REFERENCES 1632 16.1 Normative References 1634 [IEEE-EUI] IEEE, "Guidelines for 64-bit Global Identifier 1635 (EUI-64) Registration Authority", 1636 http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, 1637 IEEE, Piscataway, NJ, USA, March 1997. 1639 [RFC2119] Bradner, S., "Key words for use in RFCs to 1640 Indicate Requirement Levels", BCP 14, RFC 2119, 1641 March 1997. 1643 [RFC3007] B. Wellington, "Secure Domain Name System 1644 Dynamic Update", RFC3007, November 2000. 1646 [RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 1647 Address Allocations to Sites", RFC3177, 1648 September 2001. 1650 [RFC4219] R. Hinden & S. Deering, "IP Version 6 1651 Addressing Architecture", RFC4219, 1652 February 2006. 1654 [RFC4862] S. Thomson, T. Narten & T. Jimnei, "IPv6 Stateless 1655 Address Autoconfiguration", RFC4862, Sep 2007 1657 [RFC6177] T. Narten, G. Huston, & L. Roberts, "IPv6 Address 1658 Assignment to End Sites", RFC6177, March 2011. 1660 [ILNP-ARCH] R.J. Atkinson & S.N. Bhatti, 1661 "ILNP Architectural Description", 1662 draft-irtf-rrg-ilnp-arch, 10 July 2012. 1664 [ILNP-ARP] R.J. Atkinson & S.N. Bhatti, "ARP Extension for 1665 ILNPv4", draft-irtf-rrg-ilnp-arp, 10 July 2012. 1667 [ILNP-DNS] R.J. Atkinson, S.N. Bhatti, & S Rose, 1668 "DNS Resource Records for ILNP", 1669 draft-irtf-rrg-ilnp-dns, 10 July 2012. 1671 [ILNP-ICMPv4] R.J. Atkinson & S.N. Bhatti, 1672 "ICMPv4 Locator Update message" 1673 draft-irtf-rrg-ilnp-icmpv4, 10 July 2012. 1675 [ILNP-ICMPv6] R.J. Atkinson & S.N. Bhatti, 1676 "ICMPv6 Locator Update message" 1677 draft-irtf-rrg-ilnp-icmpv6, 10 July 2012. 1679 [ILNP-NONCEv6] R.J. Atkinson & S.N. Bhatti, 1680 "IPv6 Nonce Destination Option for ILNPv6", 1681 draft-irtf-rrg-ilnp-noncev6, 10 July 2012. 1683 [ILNP-v4OPTS] R.J. Atkinson & S.N. Bhatti, 1684 "IPv4 Options for ILNP", 1685 draft-irtf-rrg-ilnp-v4opts, 10 July 2012. 1687 16.2 Informative References 1689 [BA11] S. Bhatti & R. Atkinson, "Reducing DNS Caching", 1690 Proceedings of IEEE Global Internet Symposium (GI2011), 1691 Shanghai, P.R. China. 15 April 2011. 1693 [BAK11] S.N. Bhatti, R. Atkinson, J. Klemets, 1694 "Integrating Challenged Networks", Proceedings of 1695 IEEE Military Communications Conference (MILCOM), 1696 IEEE, Baltimore, MD, USA. Nov 2011. 1698 [LA06] Cricket Liu and Paul Albitz, "DNS and Bind", 1699 5th Edition, O'Reilly & Associates, Sebastopol, 1700 CA, USA. 2006. ISBN 0-596-10057-4. 1702 [PHG02] A. Pappas, S. Hailes, & R. Giaffreda, 1703 "Mobile Host Location Tracking through DNS", 1704 Proceedings of IEEE London Communications 1705 Symposium, IEEE, September 2002, London, 1706 England, UK. 1708 [SBK02] Alex C. Snoeren, Hari Balakrishnan, & M. Frans 1709 Kaashoek, "Reconsidering Internet Mobility", 1710 Proceedings of 8th Workshop on Hot Topics in 1711 Operating Systems, IEEE, Elmau, Germany, May 2001. 1713 [ID-Referral] B. Carpenter and others, "A Generic Referral 1714 Object for Internet Entities", 1715 draft-carpenter-behave-referral-object-01, 1716 20 October 2009. 1718 [RFC3972] T. Aura, "Cryptographically Generated Addresses 1719 (CGAs)", RFC3972, March 2005. 1721 [RFC4291] R. Hinden & S. Deering, "IP version 6 Addressing 1722 Architecture", RFC4291, February 2006. 1724 [RFC4581] M. Bagnulo & J. Arkko, "Cryptographically Generated 1725 Addresses Extension Field Format", RFC4581, 1726 October 2006. 1728 [RFC4941] T. Narten, R. Draves, & S. Krishnan, "Privacy 1729 Extensions for Stateless Address Autoconfiguration 1730 in IPv6", RFC4941, Sep 2007. 1732 [RFC4982] M. Bagnulo & J. Arkko, "Support for Multiple Hash 1733 Algorithms in Cryptographically Generated 1734 Addresses", RFC4982, July 2007. 1736 [RFC5534] J. Arkko & I. van Beijnum, "Failure Detection 1737 and Locator Pair Exploration Protocol for IPv6 1738 Multihoming", RFC5534, June 2009. 1740 [RFC6164] M. Kohno and others, "Using 127-bit IPv6 Prefixes 1741 on Inter-Router Links", RFC6164, April 2011. 1743 [ILNP-ADV] R. Atkinson & S. N. Bhatti, 1744 "Optional Advanced Deployment Scenarios for ILNP", 1745 draft-irtf-rrg-ilnp-adv, July 2012. 1747 ACKNOWLEDGEMENTS 1749 Steve Blake, Stephane Bortzmeyer, Mohamed Boucadair, Noel 1750 Chiappa, Wes George, Steve Hailes, Joel Halpern, Mark Handley, 1751 Volker Hilt, Paul Jakma, Dae-Young Kim, Tony Li, Yakov Rehkter, 1752 Bruce Simpson, Robin Whittle and John Wroclawski (in alphabetical 1753 order) provided review and feedback on earlier versions of this 1754 document. Steve Blake provided an especially thorough review of 1755 an early version of the entire ILNP document set, which was 1756 extremely helpful. We also wish to thank the anonymous reviewers 1757 of the various ILNP papers for their feedback. 1759 Roy Arends provided expert guidance on technical and procedural 1760 aspects of DNS issues. 1762 RFC EDITOR NOTE 1764 This section is to be removed prior to publication. 1766 Please note that this document is written in British English, so 1767 British English spelling is used throughout. This is consistent 1768 with existing practice in several other RFCs, for example 1769 RFC-5887. 1771 This document tries to be very careful with history, in the 1772 interest of correctly crediting ideas to their earliest 1773 identifiable author(s). So in several places the first published 1774 RFC about a topic is cited rather than the most recent published 1775 RFC about that topic. 1777 Author's Address 1779 RJ Atkinson 1780 Consultant 1781 San Jose, CA 1782 95125 USA 1784 Email: rja.lists@gmail.com 1786 SN Bhatti 1787 School of Computer Science 1788 University of St Andrews 1789 North Haugh, St Andrews 1790 Fife, Scotland 1791 KY16 9SX, UK 1793 Email: saleem@cs.st-andrews.ac.uk 1795 Expires: 10 JAN 2013