idnits 2.17.1 draft-rja-ilnp-intro-08.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, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, 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 (7 December 2010) is 4882 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) == Outdated reference: A later version (-11) exists of draft-rja-ilnp-nonce-05 == Outdated reference: A later version (-11) exists of draft-rja-ilnp-dns-06 == Outdated reference: A later version (-11) exists of draft-rja-ilnp-icmp-04 -- Obsolete informational reference (is this intentional?): RFC 1631 (Obsoleted by RFC 3022) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft RJ Atkinson 3 draft-rja-ilnp-intro-08.txt Consultant 4 Expires: 7 JUN 2011 7 December 2010 5 Category: Experimental 7 ILNP Concept of Operations 8 draft-rja-ilnp-intro-08.txt 10 Status of this Memo 12 Distribution of this memo is unlimited. 14 Copyright (c) 2010 IETF Trust and the persons identified as the 15 document authors. All rights reserved. 17 This document is subject to BCP 78 and the IETF Trust's Legal 18 Provisions Relating to IETF Documents 19 (http://trustee.ietf.org/license-info) in effect on the date of 20 publication of this document. Please review these documents 21 carefully, as they describe your rights and restrictions with 22 respect to this document. Code Components extracted from this 23 document must include Simplified BSD License text as described in 24 Section 4.e of the Trust Legal Provisions and are provided 25 without warranty as described in the Simplified BSD License. 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 This document may contain material from IETF Documents or IETF 31 Contributions published or made publicly available before 32 November 10, 2008. The person(s) controlling the copyright in 33 some of this material may not have granted the IETF Trust the 34 right to allow modifications of such material outside the IETF 35 Standards Process. Without obtaining an adequate license from 36 the person(s) controlling the copyright in such materials, this 37 document may not be modified outside the IETF Standards Process, 38 and derivative works of it may not be created outside the IETF 39 Standards Process, except to format it for publication as an 40 RFC or to translate it into languages other than English. 42 Internet-Drafts are working documents of the Internet 43 Engineering Task Force (IETF), its areas, and its working 44 groups. Note that other groups may also distribute working 45 documents as Internet-Drafts. 47 Internet-Drafts are draft documents valid for a maximum of six 48 months and may be updated, replaced, or obsoleted by other 49 documents at any time. It is inappropriate to use 50 Internet-Drafts as reference material or to cite them other 51 than as "work in progress." 53 The list of current Internet-Drafts can be accessed at 54 http://www.ietf.org/1id-abstracts.html 56 The list of Internet-Draft Shadow Directories can be accessed at 57 http://www.ietf.org/shadow.html 59 This document is not on the IETF standards-track and does not 60 specify any level of standard. This document merely provides 61 information for the Internet community. 63 This document has had extensive review within the IRTF Routing 64 Research Group, and is part of the ILNP document set. ILNP is 65 one of the recommendations made by the RG Chairs. Separately, 66 various refereed research papers on ILNP have also been published 67 during this decade. So the ideas contained herein have had much 68 broader review than the IRTF Routing RG. The views in this 69 document were considered controversial by the Routing RG, 70 but the RG reached a consensus that the document still should be 71 published. The Routing RG has had remarkably little consensus 72 on anything, so virtually all Routing RG outputs are considered 73 controversial. 75 Abstract 77 This document describes the Concept of Operations for the 78 Identifier Locator Network Protocol (ILNP), which is an 79 experimental extension to IP. This is a product of the 80 IRTF Routing RG. 82 Table of Contents 84 1. Introduction ...............................................2 85 2. Locators & Identifiers......................................4 86 3. Transport Protocols.........................................8 87 4. Mobility....................................................9 88 5. Multi-Homing...............................................12 89 6. Localised Addressing.......................................13 90 7. IP Security Enhancements...................................14 91 8. DNS Enhancements...........................................15 92 9. Referrals & Application Programming Interfaces.............17 93 10. Backwards Compatibility....................................18 94 11. Incremental Deployment.....................................19 95 12. Implementation Considerations..............................20 96 13. Security Considerations ...................................21 97 14. IANA Considerations .......................................26 98 15. References ................................................26 100 1. INTRODUCTION 102 At present, the Internet research and development community are 103 exploring various approaches to evolving the Internet 104 Architecture to solve a variety of issues including, but not 105 limited to, scalability inter-domain routing. A wide range of 106 other issues (e.g. site multi-homing, node multi-homing, 107 site/subnet mobility, node mobility) are also active concerns at 108 present. Several different classes of evolution are being 109 considered by the Internet research & development community. One 110 class is often called "Map and Encapsulate", where traffic would 111 be mapped and then tunnelled through the inter-domain core of the 112 Internet. Another class being considered is sometimes known as 113 "Identifier/Locator Split". This document relates to a proposal 114 that is in the latter class of evolutionary approaches. 116 There has been substantial research relating to naming in the 117 Internet through the years. [IEN 1] [IEN 19] [IEN 23] [IEN 31] 118 [RFC 814] [RFC 1498] More recently, mindful of that important 119 prior work, and starting well before the Routing RG was 120 re-chartered to focus on inter-domain routing scalability, the 121 author has been examining enhancements to certain naming aspects 122 of the Internet Architecture. [MobiArch07] [MobiWAC07] 123 [MobiArch08] [MILCOM08] [MILCOM09] [TeleSys] 125 The architectural concept behind ILNP derives originally from a 126 June 1994 note by Bob Smart to the IETF SIPP WG mailing list. 127 [SIPP94] In January 1995, Dave Clark sent a note to the IETF IPng 128 WG mailing list suggesting that the IPv6 address be split into 129 separate Identifier and Locator fields. [IPng95] 131 Afterwards, Mike O'Dell pursued this concept in Internet-Drafts 132 describing "8+8" or "GSE".[8+8] [GSE] More recently, the IRTF 133 Namespace Research Group (NSRG) studied this matter. Unusually 134 for an IRTF RG, the NSRG operated on the principle that unanimity 135 was required for the NSRG to make a recommendation. The author 136 was a member of the IRTF NSRG. At least one other proposal, the 137 Host Identity Protocol (HIP), also derives in part from the IRTF 138 NSRG studies (and related antecedent work). This current 139 proposal differs from O'Dell's work in various ways. 141 The crux of this proposal is to have different names for the 142 identity of a node and the location of its subnet, with crisp 143 semantics for each. This enhances the Internet Architecture 144 by adding crisp and clear semantics for the Identifier and 145 for the Locator, removing the semantically-muddled concept 146 of the IP address, and updating end system protocols slightly, 147 without requiring router changes. 149 With these naming enhancements, we have improved the Internet 150 Architecture by adding explicit support not only for 151 multi-homing, but also for mobility, localised addressing 152 (e.g. NAT/NAPT), and IP Security. 154 ILNP is an architecture, and can have more than one engineering 155 instantiation. The term ILNPv4 refers precisely to an instance 156 of ILNP that is based upon and backwards compatible with IPv4. 157 The term ILNPv6 refers precisely to an instance of ILNP that is 158 based upon and backwards compatible with IPv6. The following 159 two subsections provide brief overview of ILNPv6 and ILNPv4, 160 respectively. A full specification for either ILNPv4 or ILNPv6 161 is beyond the scope of this document. 163 Readers are referred to other related ILNP documents for details 164 not described here. [ILNP-DNS] describes additional DNS resource 165 records that support the Identifier/Locator split mode of 166 operation. [ILNP-ICMP] describes a new ICMPv6 Locator Update 167 message used by an ILNP node to inform its correspondent nodes 168 or any changes to its set of valid Locators. [ILNP-Nonce] 169 describes a new IPv6 Nonce Destination Option used by ILNP 170 nodes (1) to indicate to ILNP correspondent nodes (by inclusion 171 within the initial packets of an ILNP session) that the node 172 is operating in the Identifier/Locator split mode and 173 (2) to authenticate ICMP messages, for example the ICMPv6 174 Locator Update message, that are exchanged with ILNP 175 correspondent nodes. 177 ILNP improves routing scalability by helping multi-homed sites 178 operate effectively with provider-aggregatable addresses. 179 Many multi-homed sites today request provider-independent 180 addresses so they can provide session survivability despite 181 the failure of one or more access links or ISPs. ILNP 182 provides this session scalability by allowing correspondents 183 to change arbitrarily among multiple provider-aggregatable 184 Locator values without dirrupting the transport session. 185 In turn, this allows the multi-homed site to have the full 186 session resilience offered by provider-independent addressing 187 while using provider-aggregatable addressing, and to eliminate 188 the current need to use globally visible provider-independent 189 routing prefixes for each multi-homed site. 191 1.1 Overview 192 ILNP places an explicit Locator and Identifier in the IP packet 193 header, replacing the usual IP address. Locators are tied to the 194 topology of the network. They may change frequently, as the host 195 or site changes its network connectivity. The node Identifier is 196 normally much more static, and remains constant throughout the 197 life of a given Transport-layer session, and frequently much 198 longer. 200 Identifiers and Locators for hosts are advertised explicitly in 201 DNS, through the use of new Resource Records. This is a logical 202 and reasonable use of DNS, completely analogous to the 203 functionality that DNS provides today. At present, among other 204 current uses, the DNS is used to map from a FQDN to a set of 205 addresses. As ILNP replaces addresses with Identifiers and 206 Locators, it is then clearly rational to use the DNS to map an 207 FQDN to a set of Identifiers and a set of Locators for the host. 209 The presence of ILNP Locators and Identifiers in the DNS for a 210 DNS owner name is an indicator to correspondents that the 211 correspondents can try to establish an ILNP enhanced transport 212 session with that DNS owner name. The use of ILNP for a specific 213 session is indicated by the inclusion of an ILNP Nonce as an 214 IPv4/IPv6 option when the connection is initated. Once both 215 parties have sent an ILNP Nonce, then ILNP can be freely used for 216 that connection. 218 When a node changes Locator(s), it can send an ICMP message to 219 its current correspondents and also undertake a Secure DNS 220 Dynamic Update (RFC-3007) transaction with its DNS server. The 221 ICMP message is always protected through the use of the Nonce 222 within the ICMP message and also may optionally be protected by 223 use of the IP Authentication Header. Nonce values are 224 unidirectional. The Nonce for a given session must, for the 225 lifetime of that session, correspond with the Nonce initially 226 sent at the start of that session. 228 1.2 Terminology 230 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 231 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 232 "OPTIONAL" in this document are to be interpreted as described 233 in RFC 2119. [RFC 2119] 235 2. LOCATORS & IDENTIFIERS 237 ILNP deprecates the semantically muddled concept of an "IP 238 Address" and replaces it with 2 new concepts, the "Locator" 239 and the "Identifier". 241 The Locator is used only to name the subnetwork a node is 242 connected to, while the Identifier is used only for node 243 identity. So the routing system uses Locators, while 244 upper-layer protocols (e.g. TCP/UDP pseudo-header checksum, 245 IPsec Security Association) use only the Identifier. 247 The same Identifier definition is used for both ILNPv4 and 248 ILNPv6. This is described in the next sub-section. Following 249 that is a description of ILNPv6, including a description of 250 the 64-bit Locator value used with ILNPv6. Then, there is a 251 description of ILNPv4, including a description of the 32-bit 252 Locator value used with ILNPv4. 254 2.1 Identifiers 256 With ILNP, the Identifier is an unsigned 64-bit number. 258 This provides a fixed-length non-topological name for a node. 259 Identifiers are bound to nodes, not to interfaces of a node. 260 All ILNP Identifiers MUST comply with the modified EUI-64 syntax 261 already specified for IPv6's "Interface Identifier" values. 262 [RFC 2460][RFC 4219][IEEE-EUI] 264 Identifiers have either global-scope or local-scope. 265 A reserved bit in the modified EUI-64 syntax clearly 266 indicates whether a given Identifier has global-scope or 267 local-scope.[RFC 4219][IEEE-EUI] A node is not required 268 to use a global-scope Identifier, although that is the 269 recommended practice. 271 Most commonly, Identifiers have global-scope and are derived 272 from one or more IEEE 802 or IEEE 1394 'MAC Addresses' (sic) 273 already associated with the node, following the procedure 274 already defined for IPv6.[RFC 4219] Global-scope identifiers 275 have a high probability of being globally unique. This approach 276 eliminates the need to manage Identifiers, among other benefits. 278 Local-scope Identifiers MUST be unique within the context of 279 their Locators. The existing mechanisms of the IPv4 Address 280 Resolution Protocol [RFC 826] and IPv6 Neighbour Discovery 281 Protocol [RFC 4861] automatically enforce this constraint. 283 For example, on an Ethernet-based IPv4 subnetwork the ARP Reply 284 message is sent via link-layer broadcast, thereby advertising 285 the current binding between an IPv4 address and a MAC address 286 to all nodes on that IPv4 subnetwork. (Note also that a 287 well-known, long standing, issue with ARP is that it cannot be 288 authenticated.) Local-scope Identifiers MUST NOT be used with 289 other Locators without first ensuring uniqueness in the context 290 of those other Locators (e.g. by using IPv6 Neighbour 291 Discovery's Duplicate Address Detection mechanism when using 292 ILNPv6 or by sending an ARP Request when using ILNPv4). 294 Other methods might be used to generate local-scope Identifiers. 295 For example, one might derive Identifiers using some form of 296 cryptographic generation or using the methods specified in the 297 IPv6 Privacy Extensions to State-Less Address Auto-Configuration 298 (SLAAC). [RFC 3972, RFC 4941] When cryptographic generation of 299 Identifiers using methods described in RFC-3972 is in use, only 300 the Identifier is included, never the Locator, thereby preserving 301 roaming capability. [RFC 3972] One could also imagine creating 302 a local-scope Identifier by taking a cryptographic hash of a 303 node's public key. Of course, in the very unlikely event of a 304 Identifier collision, for example when a node has chosen to use 305 a local-scope Identifier value, the node remains free to use 306 some other local-scope Identifier value(s). 308 2.2 ILNPv6 310 It is worth remembering here that an IPv6 address names a 311 specific network interface on a specific node, but an ILNP 312 Identifier names the node itself, not a specific interface 313 on the node. This difference in definition is essential 314 to providing seamless support for mobility and multi-homing, 315 which are discussed in more detail later in this note. 317 1 1 2 3 318 0 4 8 2 6 4 1 319 +---------------+-----------------+----------------+---------------+ 320 | Version| Traffic Class | Flow Label | 321 +---------------+-----------------+----------------+---------------+ 322 | Payload Length | Next Header | Hop Limit | 323 +---------------+-----------------+--------------------------------+ 324 | Source Address | 325 + + 326 | | 327 + + 328 | | 329 + + 330 | | 331 +---------------+-----------------+----------------+---------------+ 332 | Destination Address | 333 + + 334 | | 335 + + 336 | | 337 + + 338 | | 339 +---------------+-----------------+----------------+---------------+ 341 Figure 1: Existing ("Classic") IPv6 Header 343 The high-order 64-bits of the IPv6 address become the Locator. 344 The Locator indicates the subnetwork point of attachment for a 345 node. In essence, the Locator names a subnetwork. Locators are 346 also known as Routing Prefixes. Of course, backwards 347 compatibility requirements mean that ILNPv6 Locators use the same 348 number space as IPv6 routing prefixes. This ensures that no 349 changes are needed to deployed IPv6 routers when deploying 350 ILNPv6. 352 The low-order 64-bits of the IPv6 address become the Identifier. 353 Details of the Identifier were discussed just above. 355 1 1 2 3 356 0 4 8 2 6 4 1 357 +---------------+-----------------+----------------+---------------+ 358 | Version| Traffic Class | Flow Label | 359 +---------------+-----------------+----------------+---------------+ 360 | Payload Length | Next Header | Hop Limit | 361 +---------------+-----------------+----------------+---------------+ 362 | Source Locator | 363 + + 364 | | 365 +---------------+-----------------+----------------+---------------+ 366 | Source Identifier | 367 + + 368 | | 369 +---------------+-----------------+----------------+---------------+ 370 | Destination Locator | 371 + + 372 | | 373 +---------------+-----------------+----------------+---------------+ 374 | Destination Identifier | 375 + + 376 | | 377 +---------------+-----------------+----------------+---------------+ 379 Figure 2: ILNPv6 Header 381 2.3 ILNPv4 383 ILNPv4 is merely a different instantiation of the ILNP 384 Architecture, so it retains the crisp distinction between the 385 Locator and the Identifier. Also, as with ILNPv6, when ILNPv4 386 is used for a network-layer session, the upper-layer protocols 387 (e.g. TCP/UDP pseudo-header checksum, IPsec Security 388 Association) bind only to the Identifiers, never to the Locators. 389 As with ILNPv6, only the Locator values are used for routing 390 ILNPv4 packets. 392 Just as ILNPv6 is carefully engineered to be backwards- 393 compatible with IPv6, ILNPv4 is carefully engineered 394 to be backwards-compatible with IPv4. 396 The Source IP Address in the IPv4 header becomes the Source 397 ILNPv4 Locator value, while the Destination IP Address of the 398 IPv4 header becomes the Destination ILNPv4 Locator value. Of 399 course, backwards compatibility requirements mean that ILNPv4 400 Locators use the same number space as IPv4 routing prefixes. 402 ILNPv4 uses the same 64-bit Identifier, with the same modified 403 EUI-64 syntax, as ILNPv6. Because the IPv4 address is much 404 smaller than the IPv6 address, ILNPv4 cannot carry the 405 Identifier values in the fixed portion of the IPv4 header. 406 The obvious two ways to carry the ILNP Identifier with ILNPv4 407 are either as an IPv4 Option or as an IPv6-style Extension 408 Header placed after the IPv4 header and before the upper-layer 409 protocol (e.g. OSPF, TCP, UDP, SCTP). 411 At least some currently available IPv4 forwarding silicon is able 412 to parse past IPv4 options to examine the upper-layer protocol 413 header at wire-speed on reasonably fast (e.g. 1 Gbps or better) 414 network interfaces. By contrast, no existing silicon is able to 415 parse past a new Extension Header at all. So, for engineering 416 reasons, ILNPv4 uses a new IPv4 Option to carry the Identifier 417 values. The new IPv4 option also carries a nonce value, 418 performing the same function for ILNPv4 as the IPv6 Nonce 419 Destination Option [ILNP-Nonce] performs for ILNPv6. 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 |Version|IHL=12 |Type of Service| Total Length | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Identification |Flags| Fragment Offset | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Time to Live | Protocol | Header Checksum | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Source Locator | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Destination Locator | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | OT=ILNPv4_ID | OL=5 | Padding=0x0000 | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | | 435 + Source Identifier + 436 | | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | | 439 + Destination Identifier + 440 | | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 |OT=ILNPv4_NONCE| OL=2 | top 16 bits of nonce | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | lower 32 bits of nonce | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 Figure 3: ILNPv4 header with ILNP ID option 448 and ILNP Nonce option. 450 Notation for Figure 3: 451 IHL: Internet Header Length 452 OT: Option Type 453 OL: Option Length 455 The remainder of this note focuses on ILNP for IPv6, in the 456 interest of both clarity and brevity, however the same 457 architectural concepts and principles also apply to ILNP 458 for IPv4, albeit with slightly different engineering. 460 3. TRANSPORT PROTOCOLS 462 At present, commonly deployed transport protocols include a 463 pseudo-header checksum that includes certain network-layer 464 fields, the IP addresses used for the session, in its 465 calculation. This inclusion of network-layer information 466 within the transport-layer session state creates issues for 467 multi-homing, mobility, IP Security, and localised addressing 468 (e.g. using Network Address Translation). [RFC 1631][RFC 3022] 470 This unfortunate aspect of the TCP pseudo-header checksum 471 has been understood to be an architectural problem at least 472 since 1977, well before the transition from NCP to 473 IPv4.[IEN 1][IEN 19][IEN 23][IEN 31][RFC 1498] 474 With this proposal, transport protocols include only the 475 Identifier in their pseudo-header calculations, but do not 476 include the Locator in their pseudo-header calculations. 478 To minimise the changes required within transport protocol 479 implementations, when this proposal is in use for a 480 communications session, the Locator fields are zeroed for 481 the purpose of transport-layer pseudo-header calculations. 483 Later in this document, methods for incremental deployment 484 of this change and backwards compatibility with non-upgraded 485 nodes are described. 487 4. MOBILITY 489 First, please recall that mobility and multi-homing actually 490 present the same set of issues. In each case, the set of 491 Locators associated with a node or site changes. The reason 492 for the change might be different, but the effects on the 493 network and on correspondents is identical. 495 There are no standardised mechanisms to update most transport 496 protocols with new IP addresses in use for the session. 497 Exceptionally, the Stream Control Transport Protocol (SCTP) 498 recently added this capability.[RFC 5061] In July 2008, Mark 499 Handley at UCL proposed adding such a capability to TCP during 500 a presentation at the IRTF Routing RG in Dublin, Ireland. 501 His Multi-Path TCP concept is being considered in the IETF 502 as of this writing. 504 This creates various issues for mobility. For example, there 505 is no method at present to update the IP addresses associated 506 with a transport layer session when one of the nodes in that 507 session moves (i.e. changes one of its points of network 508 attachment). 510 So, the several approaches to IP mobility seek to hide the 511 change in location (and corresponding change in IP addresses) 512 via tunnelling, home agents, foreign agents, and so forth. 513 [RFC 3775] All of this can add substantial complexity to IP 514 mobility approaches, both in the initial deployment and also 515 in ongoing operation. 517 By contrast, this ILNP proposal hides each node's location 518 information from the transport layer protocols at all times, 519 by removing location information from the transport session 520 state (e.g. pseudo-header checksum calculations). 522 In this proposal, mobility and multi-homing are supported 523 using a common set of mechanisms. In both cases, different 524 Locator values are used to identify different IP subnetworks. 525 Also, ILNP nodes are assumed to have a Fully Qualified 526 Domain Name (FQDN) stored in the Domain Name System (DNS), 527 as is already done within the deployed Internet. 529 To handle the move of a node, we add a new ICMP control message. 530 The ICMP Locator Update message is used by a node to inform its 531 existing correspondents that the set of valid Locators for the 532 node has changed. This mechanism can be used to add newly valid 533 Locators, to remove no longer valid Locators, or to do both at 534 the same time. Further, the node uses Secure Dynamic DNS Update 535 [RFC 3007] to correct the set of Locator (i.e. L32, L64) records 536 in the DNS for that node.[ILNP-DNS] This enables any new 537 correspondents to correctly initiate a new session with the 538 node at its new location. 540 This use of DNS for initial rendezvous with mobile node was 541 independently proposed by others [PHG02] and then separately 542 re-invented by the current author later on. 544 (The Locator Update control message could be an entirely new 545 protocol running over UDP, for example, but there is no obvious 546 advantage to creating a new protocol rather than using a new 547 ICMP message.) 549 With ILNP, network mobility (as well as node mobility) 550 is considered a special case of multihoming. That is, 551 when a network moves, it uses a new Locator value for all 552 of its communications sessions. So, the same mechanism, 553 using a new or additional Locator value, also supports 554 network mobility. Similarly, when a multi-homed site 555 or multi-homed node changes its set of upstream links, 556 the Locators associated with that site or node change. 558 So in ILNP, when a connectivity change affects the set of 559 valid Locators, the affected node(s) actively: 561 (1) use the ICMP Locator Update message to inform their 562 existing correspondents with the updated information 563 about their currently valid Locator(s). [ILNP-ICMP] 565 AND also 567 (2) update their DNS entries, most commonly by using 568 the Secure Dynamic DNS Update mechanism. [RFC 3007] 570 In the unlikely event of simultaneous motion which changes 571 both nodes' Locators within a very small time period, a 572 node can use the DNS to discover the new Locator value(s) 573 for the other node. 575 As a DNS performance optimisation, the "LP" DNS resource record 576 MAY be used to avoid requiring each node on a subnetwork to 577 update its DNS L64 record entries when that subnetwork's location 578 (e.g. upstream connectivity) changes. In this case, the nodes on 579 the subnetwork each would have an "LP" record pointing to a 580 common domain-name used to name that subnetwork. In turn, that 581 subnetwork's domain name would have one or more L64 record(s) in 582 the DNS. Since the contents of an "LP" record are stable, 583 relatively long DNS TTL values can be associated with these 584 records facilitating DNS caching. By contrast, the DNS TTL 585 of an L32 or L64 record for a mobile or multi-homed node 586 should be small. Experimental work at the University of 587 St Andrews indicates that the DNS continues to work well 588 even with very low DNS TTL values. [Bhatti10] 590 Correspondents of a node on that subnetwork would perform a "L64" 591 record query for that target node (or an "ID" query for that 592 target node) and receive the "LP" records as additional data in 593 the DNS reply. Then the correspondent would perform an L64 594 record lookup on the domain-name pointed to by that LP record, 595 in order to learn the Locator value to use to reach that 596 target node. 598 For bi-directional flows, such as a TCP session, each node knows 599 whether the current path in use is working by the reception of 600 data packets, acknowledgements, or both. As with TCP/IP, 601 TCP/ILNP does not need special path probes. UDP/ILNP sessions 602 with acknowledgements work similarly, and also don't need special 603 path probes. 605 In the deployed Internet, the sending node for a UDP/IP session 606 without acknowledgements does not know for certain that all 607 packets are received by the intended receiving node. Such 608 UDP/ILNP sessions fare no worse than UDP/IP sessions. The 609 receiver(s) of such a UDP session SHOULD send a gratuitous 610 IP packet containing an ILNP Nonce option to the sender, 611 in order to enable the receiver to subsequently send ICMP 612 Locator Updates if appropriate. [ILNP-Nonce] In this case, 613 UDP/ILNP sessions fare better than UDP/IP sessions, 614 still without using network path probes. 616 One might wonder what happens if a mobile node is moving more 617 quickly than DNS can be updated. This situation is unlikely, 618 particularly given the widespread use of link-layer mobility 619 mechanisms (e.g. GSM, IEEE 802 bridging) in combination with 620 network-layer mobility. However, the situation is functionally 621 equivalent to the situation where a traditional IP node is moving 622 faster than the Mobile IPv4 or Mobile IPv6 agents/servers can be 623 updated with the mobile node's new location. So the issue is not 624 new in any way. In all cases, Mobile IPv4 and Mobile IPv6 and 625 ILNP, a node moving that quickly might be temporarily unreachable 626 until it remains at a given network-layer location (e.g. IP 627 subnetwork) long enough for the location update mechanisms 628 (for Mobile IPv4, for Mobile IPv6, or ILNP) to catch up. 630 ILNP is prospectively better than either form of Mobile IP 631 with respect to key management, given that ILNP is using 632 Secure Dynamic DNS Update -- which capability is much more 633 widely available today in deployed desktop and server 634 environments (e.g. Microsoft Windows, MacOS X, Linux, other 635 UNIX), [Liu-DNS] as well as being widely available today in 636 deployed DNS server software (e.g. Microsoft and the freely 637 available BIND) and appliances [Liu-DNS], than the Security 638 enhancements needed for either Mobile IPv4 or Mobile IPv6 640 5. MULTI-HOMING 642 Conceptually, there are two kinds of multi-homing. Site 643 multi-homing is when all nodes at a site are multi-homed at the 644 same time. This is what most people mean when they talk about 645 multi-homing. However, there is also a separate concept of node 646 multi-homing, where only a single node is multi-homed. Kindly 647 recall, that multiple transport-layer sessions might currently 648 share a single current network-layer (e.g. IP or ILNP) session. 650 5.2 Node Multi-Homing 652 At present, node multi-homing is not common in the deployed 653 Internet. When TCP or UDP are in use for an IP session, node 654 multi-homing cannot provide session resilience, because the 655 transport pseudo-header checksum binds the session to a single 656 address of the multi-homed node, and hence to a single interface. 657 SCTP has a protocol-specific mechanism to support node 658 multi-homing; SCTP can support session resilience both at present 659 and also without change in the proposed approach. [RFC 5061] 661 In the new scheme, when a node is multi-homed, then the node 662 typically has more than one valid Locator value. When one 663 upstream connection fails, the node sends an ICMP Locator Update 664 message to each existing correspondent node to remove the 665 no-longer-valid Locator from the set of valid Locators. 667 [ILNP-ICMP] Also, the node can use Secure Dynamic DNS Update 668 to alter the set of currently valid L64 records associated with 669 that node. [RFC 3007] This second step ensures that any new 670 correspondents can reach the node. 672 5.2 Site Multi-Homing 674 At present, site multi-homing is common in the deployed Internet. 675 This is primarily achieved by advertising the site's routing 676 prefix(es) to more than one upstream Internet service provider 677 at a given time. In turn, this requires de-aggregation of 678 routing prefixes within the inter-domain routing system. 679 In turn, this increases the entropy of the inter-domain 680 routing system (e.g. RIB/FIB size increases beyond the 681 minimal RIB/FIB size that would be required to reach all sites). 683 In the new scheme, site multi-homing is similar to node 684 multi-homing, but with nodes within the site having one Locator 685 for each upstream connection to the Internet. To avoid a DNS 686 Update burst when a site or (sub)network moves location, a DNS 687 record optimisation is possible. This would change the number of 688 DNS Updates required from Order(number of nodes at the 689 site/subnetwork that moved) to Order(1). [ILNP-DNS] 691 Additionally, since the transport-protocol session state no 692 longer includes the Locators, a site could choose to perform 693 Locator rewriting at its site border routers, possibly in 694 combination with applying site traffic engineering policy on 695 which upstream link to use for which packets. Since the site 696 border router(s) are in the middle of any exterior packet flow, 697 they also can send proxy Locator Update messages on behalf of 698 nodes inside that site, and can even include the appropriate 699 Nonce value in such proxy Locator Updates, if desired by that 700 site's administration. 702 5.3 Multi-Path Support 704 Because ILNP decouples the transport-layer information from 705 the Locator values being used for a given session (e.g. TCP 706 pseudo-header checksum includes Identifier values, but not 707 Locator values, when ILNP is in use), ILNP can enable 708 multi-path transport-layer sessions without requiring any 709 changes to existing transport-layer protocols (e.g. TCP, UDP). 710 Note that this approach also does not interfere with SCTP's 711 existing support for multi-path transport nor with the 712 proposed TCP multi-path extensions. 714 With ILNP, any transport-layer session can use multiple paths 715 concurrently, simply by using multiple (valid) Locator values 716 in that session's ILNP packets. Obviously for any given ILNP 717 packet a single Source Locator and a single Destination Locator 718 is in use. 720 As an example, if one considers TCP with an originator using 721 Locators (A, B, C) and a responder using Locators (W, X, Y), then 722 the originator can choose which Source Locators to use and also 723 which Destination Locators on a packet-by-packet basis. So 724 different TCP segments (or TCP ACKs, or other TCP information) 725 within a single TCP session can use different Locator pairs. 727 Again, purely as an example, the originator could send packets 728 using these Locator values in this simple sequence: (A, W) (B, X) 729 (C, Y) or any other sequence that it wishes to. The choice of 730 Locator value to use for a given packet is made by the sending 731 node, selected from the current set of valid Locator values for 732 the receiving node. Similarly, the responder can use any valid 733 combination of Locators that it wishes to use. 735 The ILNP-related DNS resource records specified in [ILNP-DNS] 736 contain relative preference values. The simplest approach to 737 Locator selection probably is to use the most preferred 738 Locator value advertised by the receiving node as the 739 Destination Locator, and the local node's own most preferred 740 Locator value as the Source Locator. However, an ILNP node 741 MAY also consider local policy and other locally-available 742 information in deciding which Locator value(s) to use for 743 a given ILNP packet being sent by that node. 745 In any case, the TCP implementations at either end are 746 unaware that multiple Locators are being used (i.e. because 747 the transport-layer pseudo-header checksum only includes 748 Identifiers, never Locators). In turn, this is why not 749 special multi-path TCP (or UDP or SCTP or other) 750 transport-layer modifications are required. (Caveat: 751 Of course, the ILNP stack upgrade is needed in the 752 first place.) 754 The same concepts and general approach also apply to UDP and/or SCTP. 756 6. LOCALISED ADDRESSING 758 As the Locator value no longer forms part of the node session 759 state (e.g. TCP pseudo-header), it is easier to support 760 localised addressing, which is sometimes also called "Private 761 Addressing", based on the use of local values of the Locator. 763 This would be either in place of, or to supplement, existing 764 NAT-based schemes. [RFC 1631] [RFC 3022] 766 For example, a site that desires to use private addresses 767 internally might deploy IPv6 Unique Local Addressing 768 (ULA) for localised addressing, along with some form of ILNP/ 769 IPv6 Network Address Translation at a site border gateway. 770 [ID-ULA] [RFC 4193] This example is described in detail 771 in [MILCOM09], both as a mechanism for site multi-homing 772 and also as a mechanism to support site-controlled traffic 773 engineering. 775 In the simplest case, an ILNP capable NAT only would need to 776 change the value of the Source Locator in an outbound packet, 777 and the value of the Destination Locator for an inbound packet. 778 Identifier values would not need to change, nor would 779 transport-layer checksums, so a true end-to-end session 780 could be maintained. 782 If a site using localised addressing chooses to deploy a 783 split-horizon DNS server, then the DNS server would advertise 784 the global-scope Locator(s) of the site border routers outside 785 the site to DNS clients outside the site, and would advertise 786 the local-scope Locator(s) specific to that internal node to 787 DNS clients inside the site. Such deployments of split-horizon 788 DNS servers are not unusual in the IPv4 Internet today. If an 789 internal node (e.g. portable computer) moves outside the site, 790 it would follow the normal ILNP methods to update its 791 authoritative DNS server with its current Locator set. In this 792 deployment model, the authoritative DNS server for that mobile 793 device will be either the split-horizon DNS server itself or the 794 master DNS server providing data to the split-horizon DNS server. 796 If a site using localised addressing chooses not to deploy a 797 split-horizon DNS server, then all internal nodes would 798 advertise the global-scope Locator(s) of the site border routers. 799 To deliver packets from one internal node to another internal 800 node, the site would either choose to use layer-2 bridging 801 (e.g. IEEE Spanning Tree, IEEE Rapid Spanning Tree, or a 802 link-state layer-2 algorithm such as the IETF TRILL group or 803 IEEE 802.1 are developing), or the interior routers would 804 forward packets up to the nearest site border router, 805 which in turn would then rewrite the Locators to appropriate 806 local-scope values, and forward the packet towards the interior 807 destination node. 809 Alternately, for sites using localised addressing but not 810 deploying a split-horizon DNS server, the DNS server could 811 return all global-scope and local-scope Locators to all queriers, 812 and to assume that correspondent hosts would use address 813 selection to choose the best Locator to use to reach a given 814 correspondent. [RFC 3484] Hosts within the same site as the 815 correspondent node would only have a ULA configured, and hence 816 would select the ULA destination Locator for the correspondent. 817 Hosts outside the site would not have the same ULA configured. 818 Note that RFC 3484 probably needs to be updated to indicate 819 that the longest-prefix matching rule is inadequate when 820 comparing ULA-based Locators with global-scope Locators: 821 to choose a ULA for a correspondent, a node must have a 822 Locator that matches all 48 ULA bits of the target Locator 823 value. 825 We note that a deployment using private/local addressing can 826 also provide site multi-homing by deploying site border 827 routers in this manner. 829 Please note that with this proposal, localised addressing 830 (e.g. using Network Address Translation on the Locator bits) 831 would work in harmony with multihoming, mobility, and IP 832 Security.[MobiWAC07][MILCOM08][MILCOM09] 834 7. IP SECURITY ENHANCEMENTS 836 A current issue is that the IP Security protocols, AH and ESP, 837 have Security Associations that include the IP addresses of 838 the secure session endpoints. This was understood to be a 839 problem when AH and ESP were originally defined, however the 840 limited set of namespaces in the Internet Architecture did not 841 provide any better choices at that time. 843 Operationally, this binding causes problems for the use of the 844 IPsec protocols through Network Address Translation devices, 845 with mobile nodes (because the mobile node's IP address changes 846 at each network-layer handoff), and with multi-homed nodes 847 (because the session is bound to a particular interface of the 848 multi-homed node, rather than being bound to the node 849 itself).[RFC 3027][RFC 3715] 851 To resolve the issue of IPsec interoperability through a 852 NAT deployment, UDP encapsulation of IPsec is commonly 853 used today.[RFC 3948] 855 With this proposal, the IP Security protocols, AH and ESP, 856 are enhanced to bind Security Associations only to 857 Identifier values and never to Locator values (and also 858 not to an entire 128-bit IPv6 address). 860 Similarly, key management protocols used with IPsec would be 861 enhanced to deprecate use of IP addresses as identifiers and 862 to substitute the use of the new Identifier for that 863 purpose. 865 This small change enables IPsec to work in harmony with 866 multihoming, mobility, and localised addressing. [MILCOM08] 867 [MILCOM09] Further, it would obviate the need for specialised 868 IPsec NAT Traversal mechanisms, thus simplifying IPsec 869 implementations while enhancing deployability and 870 interoperability. [RFC 3948] 872 This change does not reduce the security provided by the 873 IP Security protocols. 875 8. DNS ENHANCEMENTS 877 As part of this proposal, additional DNS Resource Records have 878 been proposed in a separate document. [ILNP-DNS] These new 879 records store the Identifier and Locator values for nodes that 880 have been upgraded to support the Identifier-Locator Split Mode. 882 With this proposal, mobile or multi-homed nodes and sites are 883 expected to use the existing "Secure Dynamic DNS Update" protocol 884 to keep their Identifier and Locator records correct in its 885 authoritative DNS server(s). [RFC 3007] 887 While some might be surprised, Secure Dynamic DNS Update is 888 available now in a very wide range of existing deployed systems. 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. [Liu-DNS] There are credible reports 894 that when a site deploys Microsoft's Active Directory, the site 895 (silently) automatically deploys Secure Dynamic DNS 896 Update. [Liu-DNS] So it appears that many sites have already 897 deployed Secure Dynamic DNS Update even though they might not be 898 aware they have already deployed that protocol. [Liu-DNS] 900 Reverse DNS lookups, to find a node's Fully Qualified Domain Name 901 from the combination of a Locator and related Identifier value, 902 can be performed as at present. 904 Previous research by others indicates that DNS caching is largely 905 ineffective, with the exception of NS records and the addresses 906 of DNS servers referred to by NS records.[SBK2002] This means DNS 907 caching performance will not be adversely affected by assigning 908 very short time-to-live (TTL) values to the Locator records of 909 typical nodes.[Bhatti10] It also means that it is preferable 910 to deploy the DNS server function on nodes that have longer 911 DNS TTL values, rather than on nodes that have shorter DNS 912 TTL values. 914 As discussed previously, LP records normally are stable, 915 even if the L32 or L64 records they point to aren't stable, 916 so LP records normally can be given very long DNS TTL values. 918 Identifier values might be very long-lived (e.g. days) when they 919 have been generated from an IEEE MAC Address on the system. 920 Identifier values might have a shorter lifetime (e.g. hours) if 921 they have been cryptographically-generated [RFC 3972], or have 922 been created by the IPv6 Privacy Extensions [RFC 4941], or 923 otherwise have the EUI-64 scope bit at the "local-scope" value. 924 Note that when ILNP is used, the cryptographic generation 925 method described in RFC-3972 is used only for the Identifier, 926 omitting the Locator, thereby preserving roaming capability. 927 Note that a given ILNP session normally will use a single 928 Identifier value for the life of that session. 930 Existing DNS specifications require that DNS clients and DNS 931 resolvers obey the TTL values provided by the DNS servers. In 932 the context of this proposal, short DNS TTL values are assigned 933 to particular DNS records to ensure that the ubiquitous DNS 934 caching resolvers do not cache volatile values (e.g. Locator 935 records of a mobile node) and consequently return stale 936 information to new requestors. 938 As a practical matter, it is not sensible to flush all Locator 939 values associated with an existing session's correspondent node. 940 Instead, Locator values cached for a correspondent node (in the 941 ILNP Correspondent Cache, described in Section 12.1) SHOULD be 942 marked as "aged" when their TTL has expired until either the next 943 Locator Update message is received or there is other indication 944 that a given Locator is not working any longer. 946 During a long transition period, a node that is I/L-enabled 947 SHOULD have not only ID and L64 (or ID and LP) records present in 948 its authoritative DNS server, but also SHOULD have AAAA records 949 in the DNS for the benefit of non-upgraded nodes. This 950 capability might be implemented strictly inside a DNS server, 951 whereby the DNS server synthesised a set of AAAA records to 952 advertise from the ID and Locator (i.e., L32, L64, or LP) values 953 that the node has kept updated in that DNS server. 955 Existing DNS specifications require that a DNS resolver or DNS 956 client ignore unrecognised DNS record types. So gratuitously 957 appending ID and Locator (i.e., L32, L64, or LP) records as 958 "additional data" in DNS responses to AAAA queries ought not 959 create any operational issues. 961 9. REFERRALS & APPLICATION PROGRAMMING INTERFACES 963 This section is concerned with support for using 964 existing ("legacy") applications over ILNP, including 965 both referrals and APIs. 967 9.1 BSD Sockets APIs 969 The existing BSD Sockets API can continue to be used with 970 ILNP underneath the API. That API can be implemented in a 971 manner that hides the underlying protocol changes from the 972 applications. For example, the combination of a Locator 973 and an Identifier can be used with the API in the place 974 of an IPv6 address. 976 So it is believed that existing IP address referrals can 977 continue to work properly in most cases. For a rapidly 978 moving target node, referrals might break in at least some 979 cases. The potential for referral breakage is necessarily 980 dependent upon the specific application and implementation 981 being considered. 983 It is suggested, however, that a new, optional, more abstract, 984 C language API be created so that new applications may avoid 985 delving into low-level details of the underlying network 986 protocols. Such an API would be useful today, even with 987 the existing IPv4 and IPv6 Internet, whether or not ILNP 988 were ever widely deployed. 990 9.2 Java APIs 992 Most existing Java APIs already use abstracted network 993 programming interfaces, for example in the java.Net.URL class. 994 Because these APIs already hide the low-level network-protocol 995 details from the applications, the applications using these APIs 996 (and the APIs themselves) don't need any modification to work 997 equally well with IPv4, IPv6, ILNP, and probably also HIP. 999 9.3 Referrals in the Future 1000 The approach proposed in [ID-Referral] appears to be very 1001 suitable for use with ILNP, in addition to being suitable 1002 for use with the deployed Internet. Protocols using that 1003 approach would not need modification to have their referrals 1004 work well with IPv4, IPv6, ILNP, and probably also other 1005 network protocols (e.g. HIP). 1007 A more sensible approach to referrals would be to use 1008 Fully-Qualified Domain Names (FQDNs), as is commonly done 1009 today with web URLs. This is approach is highly portable 1010 across different network protocols, even with both the IPv4 1011 Internet or the IPv6 Internet. 1013 10. BACKWARDS COMPATIBILITY 1015 First, if one compares Figure 1 and Figure 2, one can see 1016 that IPv6 with the Identifier/Locator Split enhancement is 1017 fully backwards compatible with existing IPv6. This means 1018 that no router software or silicon changes are necessary to 1019 support the proposed enhancements. A router would be 1020 unaware whether the packet being forwarded were classic IPv6 1021 or the proposed enhanced version of IPv6. So no changes to 1022 IPv6 routers is required to deploy this proposal. 1024 Further, IPv6 Neighbour Discovery should work fine as is. 1026 If a node that has been enhanced to support the Identifier/ 1027 Locator Split mode initiates an IP session with another node, 1028 normally it will first perform a DNS lookup on the responding 1029 node's DNS name. If the initiator node does not find any ID 1030 or L64 DNS resource records for the responder node, then the 1031 initiator uses the Classical IPv6 mode of operation for the 1032 new session with the responder, rather than trying to use 1033 the I/L Split mode for that session. Of course, multiple 1034 transport-layer sessions can concurrently share a single 1035 network-layer (e.g. IP or ILNP) session. 1037 If the responder node for a new IP session has not been enhanced 1038 to support the I/L Split mode and receives initial packet(s) 1039 containing the Nonce Destination Option, the responder will drop 1040 the packet and send an ICMP Parameter Problem error message back 1041 to the initiator. A responder node that has been upgraded to 1042 support the I/L Split mode that receives initial packet(s) 1043 containing the Nonce Destination Option knows those packets are 1044 ILNP packets by the presence of that Nonce Destination Option. 1046 If the initiator node does not receive a response from the 1047 responder in a timely manner (e.g. within TCP timeout for a TCP 1048 session) and also does not receive an ICMP Unreachable error 1049 message for that packet, OR if the initiator receives an ICMP 1050 Parameter Problem error message for that packet, then the 1051 initiator knows that the responder is not able to support the I/L 1052 Split Operating mode. In this case, the initiator node SHOULD 1053 try again to create the new IP session but this time OMITTING the 1054 Nonce Destination Option, and this time operating in Classic IPv6 1055 mode, rather than I/L Split mode. 1057 Finally, since an ILNP node is also a fully-capable IPv6 node, 1058 then the upgraded node can use any standardised IPv6 mechanisms 1059 for communicating with a legacy IPv6 node (i.e. an IPv6 node 1060 without ILNP capability enhancements). So ILNP will in no case 1061 be worse than existing IPv6, and in many cases ILNP will out 1062 perform existing IPv6. 1064 11. INCREMENTAL DEPLOYMENT 1066 If a node has been enhanced to support the Identifier/ Locator 1067 Split operating mode, that node's fully-qualified domain name 1068 will normally have one or more ID records and one or more Locator 1069 (i.e. L32, L64, and LP) records associated with the node within 1070 the DNS. 1072 When a host ("initiator") initiates a new IP session with a 1073 correspondent ("responder"), it normally will perform a DNS 1074 lookup to determine the address(es) of the responder. A host 1075 that has been enhanced to support the Identifier/ Locator Split 1076 operating mode normally will look for Identifier ("ID") and 1077 Locator (i.e. L32, L64, and LP) records in any received DNS 1078 replies. DNS servers that support ID and Locator (i.e. L32, L64, 1079 and LP) records SHOULD include them (when they exist) as 1080 additional data in all DNS replies to queries for DNS AAAA 1081 records.[ILNP-DNS] 1083 If the initiator supports the I/L Split mode and from DNS 1084 information learns that the responder also supports the 1085 I/L Split mode, then the initiator will generate an 1086 unpredictable nonce value, store that value in a local 1087 Correspondent Cache, which is described in more detail below, 1088 and will include the Nonce Destination Option in its 1089 initial packet(s) to the responder.[ILNP-Nonce] 1091 If the responder supports the I/L Split mode and receives 1092 initial packet(s) containing the Nonce Destination Option, 1093 the responder will thereby know that the initiator supports 1094 the I/L Split mode and the responder will also operate in 1095 I/L Split mode for this new IP session. 1097 If the responder supports the I/L Split mode and receives 1098 initial packet(s) NOT containing the Nonce Destination Option, 1099 the responder will thereby know that the initiator does NOT 1100 support the I/L Split mode and the responder will operate 1101 in classic IPv6 mode for this new IP session. 1103 The previous section described how interoperability between 1104 enhanced nodes and non-enhanced nodes is retained even if a 1105 non-enhanced node erroneously has ID and/or L64 DNS resource 1106 records in place (e.g. due to some accident). 1108 The mobility capabilities of ILNP might be the most applicable 1109 to the deployment world. Despite substantial good efforts by many, 1110 neither Mobile IPv4 nor Mobile IPv6 are widely used at present. 1111 There are credible reports of specialised deployments 1112 of Mobile IPv4 and/or Mobile IPv6 within some wireless networks 1113 built using some mobile telephony standards (e.g. CDMA2000). 1114 However, much of the recent work in operating systems has focused 1115 on support for mobile devices (e.g. mobile telephone handsets, 1116 hand-held music players, hand-held organisers). Those devices 1117 probably represent the fastest growth segment of the Internet at 1118 present. Moreover, many vendors of such devices have included 1119 significant networking protocol improvements in incremental 1120 operating system updates, rather than always waiting for a new 1121 major release to add networking facilities. 1123 Data center operators might be interested in using ILNP to 1124 facilitate virtual machine mobility between VLANs within a data 1125 centre site or to a separate disaster recovery site. 1127 However, other users or vendors might be more interested by the 1128 new security models enabled by having Identifiers different from 1129 Locators, or they might be more interested in the ability to 1130 provide node-specific multi-homing, rather than always 1131 multi-homing an entire site. 1133 In the end, the marketplace has myriad users with various 1134 functional needs. The set of improvements offered by ILNP is 1135 broad, and should appeal to a wide range of vendors and users. 1137 12. IMPLEMENTATION CONSIDERATIONS 1139 This section discusses implementation considerations that 1140 are not otherwise discussed in the ILNP Internet-Drafts. 1142 12.1 ILNP Correspondent Cache 1143 An ILNP-capable node will need to modify its network protocol 1144 implementation to add an ILNP Correspondent Cache. In theory, 1145 this cache is within the ILNP network-layer. However, many 1146 network protocol implementations do not have strict protocol 1147 separation or layering. In the interest of efficient 1148 implementation, and to avoid unduly restricting implementers, 1149 an ILNP implementation is not required to limit the 1150 accessibility of ILNP Correspondent Cache to the network-layer. 1152 The ILNP Correspondent Cache contains at least the following 1153 inter-related data elements for the node itself: 1155 Set of Local Locator(s) 1156 & Preference value for each Locator 1157 Set of Local Identifier(s) 1159 and also the following per-correspondent data elements: 1160 Set of Correspondent's Locator(s) 1161 & Preference value for each Locator 1162 Set of Correspondent's Identifier(s) 1163 Nonce used from the local node to that correspondent 1164 Nonce used from that correspondent to the local node 1165 Valid Time 1167 For received packets containing an ILNP Nonce Destination Option, 1168 lookups in the ILNP Correspondent Cache MUST use the 1169 (Correspondent Identifier, Nonce) tuple as the lookup key. This 1170 facilitates situations where, perhaps due to deployment of 1171 Local-scope Identifiers, more than one correspondent node is 1172 using the same Identifier value. 1174 For all other ILNP packets, lookups in the ILNP Correspondent 1175 Cache MUST use the (Correspondent Locator, Correspondent 1176 Identifier) tuple as the lookup key. This facilitates situations 1177 where, perhaps due to deployment of Local-scope Identifiers, more 1178 than one correspondent node is using the same Identifier value. 1180 The Valid Time field indicates the remaining lifetime for which 1181 this ILNP session information is valid. For time, a node might 1182 use UTC (e.g. via Network Time Protocol) or perhaps some 1183 node-specific time (e.g. seconds since node boot). A table 1184 entry is current if the node's current time is less than or 1185 equal to the time in the Valid Time field, while a table entry 1186 is aged if the node's current time is greater than the time in 1187 the Valid Time field. 1189 While Locators are omitted from the transport-layer checksum, 1190 an implementation SHOULD use Locator values to distinguish 1191 between correspondents coincidentally using the same ID value 1192 (e.g. due to deployment of Local-scope Identifier values) 1193 when demultiplexing to determine which application(s) should 1194 receive the user data delivered by the transport-layer protocol. 1196 12.2 ICMP Locator Updates 1198 While ILNP's ICMP Locator Update message is defined in a 1199 separate document [ILNP-ICMP], it is worth mentioning that 1200 received authenticated Locator Update messages cause the 1201 ILNP Correspondent Cache described just above to be updated. 1203 Implementers should keep in mind that a node or site might 1204 have a large number of concurrent Locators, and should 1205 ensure that a system fault does not arise if the system 1206 receives an authentic ICMP Locator Update containing a 1207 large number of Locator values. 1209 13. SECURITY CONSIDERATIONS 1211 This proposal outlines a proposed evolution for the Internet 1212 Architecture to provide improved capabilities. This section 1213 discusses security considerations for this proposal. Note that 1214 ILNP provides security equivalent to IP for similar threats when 1215 similar mitigations (e.g. IPsec or not) are in use. In some 1216 cases, but not all, ILNP exceeds that objective and has less 1217 security risk than IP. 1219 13.1 Authentication of Locator Updates 1221 A separate document [ILNP-Nonce] proposes a new IPv6 1222 Destination Option that can be used to carry a session nonce 1223 end-to-end between communicating nodes. That nonce provides 1224 protection against off-path attacks on an Identifier/Locator 1225 session. The Nonce Destination Option is used ONLY for IP 1226 sessions in the Identifier/Locator Split mode. The nonce 1227 values are exchanged in the initial packets of an ILNP 1228 session. 1230 Ordinary IPv6 is vulnerable to on-path attacks unless 1231 the IP Authentication Header or IP Encapsulating Security 1232 Payload is in use. So the Nonce Destination Option 1233 only seeks to provide protection against off-path attacks 1234 on an IP session -- equivalent to ordinary IPv6 when 1235 not using IP Security. 1237 When the Identifier/Locator split mode is in use for an 1238 existing IP session, the Nonce Destination Option MUST be 1239 included in any ICMP control messages (e.g. ICMP Unreachable, 1240 ICMP Locator Update) sent with regard to that IP session. 1242 It is common to have non-symmetric paths between two nodes 1243 on the Internet. To reduce the number of on-path nodes that 1244 know the Nonce value for a given session when the I/L split 1245 mode is in use, a nonce value is unidirectional, not 1246 bidirectional. For example, for a session between two nodes 1247 A and B, one nonce value is used from A to B and a different 1248 nonce value is used from B to A. 1250 When in the I/L Split operating mode for an existing IP 1251 session, ICMP control messages received without a Nonce 1252 Destination Option MUST be discarded as forgeries. This 1253 security event SHOULD be logged. 1255 When in the I/L Split operating mode for an existing IP 1256 session, ICMP control messages received without a correct 1257 nonce value inside the Nonce Destination Option MUST be 1258 discarded as forgeries. This security event SHOULD be logged. 1260 When in the I/L Split operating mode for an existing IP 1261 session, and a node changes its Locator set, it should 1262 include the Nonce Destination Option in the first few 1263 data packets sent using a new Locator value, so that 1264 the recipient can validate the received data packets 1265 as valid (despite having an unexpected Source Locator 1266 value). 1268 For ID/Locator Split mode sessions operating in higher risk 1269 environments, the use of the cryptographic authentication 1270 provided by IP Authentication Header is recommended 1271 *in addition* to concurrent use of the Nonce Destination 1272 Option. 1274 It is important to note that at present an IPv6 session is 1275 entirely vulnerable to on-path attacks unless IPsec is in use 1276 for that particular IPv6 session, so the security properties 1277 of the new proposal are never worse than for existing IPv6. 1279 13.2 Forged Identifier Attacks 1281 In the deployed Internet, active attacks using packets with a 1282 forged Source IP Address have been publicly known at least since 1283 early 1995.[CA-1995-01] While these exist in the deployed 1284 Internet, they have not been widespread. This is equivalent to 1285 the issue of a forged Identifier value and demonstrates that this 1286 is not a new threat created by the Identifier/Locator-split mode 1287 of operation. 1289 One mitigation for these attacks has been to deploy Source IP 1290 Address Filtering.[RFC 2827] [RFC 3704] Jun Bi at U. Tsinghua 1291 cites Arbor Networks as reporting that this mechanism has less 1292 than 50% deployment and cites an MIT analysis indicating that at 1293 least 25% of the deployed Internet permits forged source IP 1294 addresses. 1296 Other parts of this document discuss the probability of an 1297 accidental duplicate Identifier being used on the Internet. 1298 However, this sub-section instead focuses on methods for 1299 mitigating attacks based on packets containing deliberately 1300 forged Source Identifier values. 1302 First, the recommendations of [RFC 2827] & [RFC 3704] remain. 1303 So any packets that have a forged Locator value can be easily 1304 filtered using existing widely available mechanisms. 1306 Second, the receiving node does not blindly accept any packet 1307 with the proper Source Identifier and proper Destination 1308 Identifier as an authentic packet. Instead, each node operating 1309 the I/L-split mode maintains an ILNP Correspondent Cache for each 1310 of its correspondents, as described above. This cache contains 1311 two unidirectional nonce values (one used in control messages 1312 sent by this node, a different one used to authenticate messages 1313 from the other node). The correspondent cache also contains 1314 the currently valid set of Locators and set of Identifiers for 1315 each correspondent node. If a received packet contains valid 1316 Identifier values and a valid Destination Locator, but contains 1317 a Source Locator value that is not present in the correspondent 1318 cache, the packet is dropped without further processing as an 1319 invalid packet, unless the packet also contains a Nonce 1320 Destination Option with the correct value used for packets from 1321 the node with that Source Identifier to this node. This prevents 1322 an off-path attacker from stealing an existing session. 1324 Third, any node can distinguish different nodes using the same 1325 Identifier value by other properties of their sessions. For 1326 example, IPv6 Neighbour Discovery prevents more than one node 1327 from using the same source (Locator + Identifier) pair at the 1328 same time on the same link. So cases of different nodes using 1329 the same Identifier value will involve nodes that have different 1330 sets of valid Locator values. A node can thus demux based on the 1331 combination of Source Locator and Source Identifier if necessary. 1332 If IP Security is in use, the combination of the Source 1333 Identifier and the SPI value would be sufficient to demux two 1334 different sessions. 1336 Fourth, deployments in high threat environments also SHOULD use 1337 the IP Authentication Header to authenticate control traffic and 1338 data traffic. Because in the I/L-split mode, IP Security binds 1339 only to the Identifier values, and never to the Locator values, 1340 this enables a mobile or multi-homed node to use IPsec even when 1341 its Locator value(s) have just changed. 1343 Last, note well that ordinary IPv4, ordinary IPv6, Mobile IPv4, 1344 and also Mobile IPv6 already are vulnerable to forged Identifier 1345 and/or forged IP address attacks. An attacker on the same link 1346 as the intended victim simply forges the victims MAC address and 1347 the victim's IP address. With IPv6, when SEND and CGAs are in 1348 use, the victim node can defend its use of its IPv6 address using 1349 SEND. With ILNP, when SEND and CGIs are in use, the victim node 1350 also can defend its use of its IPv6 address using SEND. There 1351 are no standard mechanisms to authenticate ARP messages, so IPv4 1352 is especially vulnerable to this sort of attack. These attacks 1353 also work against Mobile IPv4 and Mobile IPv6. In fact, when 1354 either form of Mobile IP is in use, there are additional risks, 1355 because the attacks work not only when the attacker has access to 1356 the victim's current IP subnetwork but also when the attacker has 1357 access to the victim's home IP subnetwork. So the risks of 1358 using ILNP are not greater than exist today with IP or Mobile IP. 1360 13.3 IP Security Enhancements 1362 The IP Security standards are enhanced here by binding IPsec 1363 Security Associations to the Identifiers of the session 1364 endpoints, rather than binding IPsec Security Associations 1365 to the IP Addresses as at present. This change enhances the 1366 deployability and interoperability of the IP Security standards, 1367 but does not decrease the security provided by those protocols. 1369 Also, the IP Authentication Header omits the Source Locator and 1370 Destination Locator fields from its authentication calculations 1371 when ILNP is in use. This enables IP AH to work well even 1372 through a NAT or other situation where a Locator value might 1373 change during transit. 1375 13.4 DNS Security 1377 The DNS enhancements proposed here are entirely compatible with, 1378 and can be protected using, the existing IETF standards for DNS 1379 Security.[RFC 4033] The Secure DNS Dynamic Update mechanism used 1380 here is also used unchanged.[RFC 3007] So there is no change to 1381 the security properties of the Domain Name System or of DNS 1382 servers due to ILNP. 1384 13.5 Firewall Considerations 1386 In the proposed new scheme, stateful firewalls are able to 1387 authenticate ICMP control messages arriving on the external 1388 interface. This enables more thoughtful handling of ICMP 1389 messages by firewalls than is commonly the case at present. As 1390 the firewall is along the path between the communicating nodes, 1391 the firewall can snoop on the Session Nonce being carried in the 1392 initial packets of an I/L Split mode session. The firewall can 1393 verify the correct nonce is present on incoming control packets, 1394 dropping any control packets that lack the correct nonce value. 1396 By always including the nonce in ILNP control messages, even when 1397 IP Security is also in use, the firewall can filter out off-path 1398 attacks against those ILNP messages. In any event, a forged 1399 packet from an on-path attacker will still be detected when the 1400 IPsec input processing occurs in the receiving node; this will 1401 cause that forged packet to be dropped rather than acted upon. 1403 13.6 Neighbour Discovery Authentication 1405 Nothing in this proposal prevents sites from using the Secure 1406 Neighbour Discovery (SEND) proposal for authenticating IPv6 1407 Neighbour Discovery. [RFC 3971] 1409 13.7 Site Topology Obfuscation 1411 A site that wishes to obscure its internal topology information 1412 MAY do so by deploying site border routers that rewrite the 1413 Locator values for the site as packets enter or leave the site. 1415 For example, a site might choose to use a ULA prefix internally 1416 for this reason.[RFC 4193] [ID-ULA] In this case, the site border 1417 routers would rewrite the Source Locator of ILNP packets leaving 1418 the site to a global-scope Locator associated with the site. 1419 Also, those site border routers would rewrite the Destination 1420 Locator of packets entering the site from the global-scope 1421 Locator to an appropriate interior ULA Locator for the 1422 destination node.[MILCOM08] 1424 13.8 Path Liveness 1426 Some perceive that an Identifier-Locator Split architecture 1427 creates a new issue that is sometimes called "Locator Liveness" 1428 or "Path Liveness". This refers to the question of whether an IP 1429 packet with a particular destination Locator value will be able 1430 to reach the intended destination or not, given that some 1431 otherwise valid paths might be unusable by the sending node 1432 (e.g. due to security policy or other administrative choice). 1433 In fact, this issue has existed in the IPv4 Internet for decades. 1435 For example, an IPv4 server might have multiple valid IP 1436 addresses, each advertised to the world via an DNS "A" record. 1437 However, at a given moment in time, it is possible that a given 1438 sending node might not be able to use a given (otherwise valid) 1439 destination IPv4 address in an IP packet to reach that IPv4 1440 server. 1442 So we see that using an Identifier/Locator Split architecture 1443 does not create this issue, nor does it make this issue worse 1444 than it is with the deployed IPv4 Internet. 1446 In ILNP, the same conceptual approach described in [RFC 5534] can 1447 be reused. Alternatively, an ILNP node can reuse the existing 1448 IPv4 methods for determining whether a given path to the target 1449 destination is currently usable, which existing methods leverage 1450 transport-layer session state information that the communicating 1451 end systems are already keeping for transport-layer protocol 1452 reasons. 1454 Last, it is important for the reader to understand that the 1455 mechanism described in [ILNP-ICMP] is a performance optimisation, 1456 significantly shortening the layer-3 handoff time if/when a 1457 correspondent changes location. Architecturally, using ICMP 1458 is no different from using UDP, of course. 1460 14. IANA CONSIDERATIONS 1462 This document has no IANA considerations. 1464 15. REFERENCES 1466 This section provides both normative and informative 1467 references relating to this note. 1469 15.1. Normative References 1471 [RFC 826] D. Plummer, "Ethernet Address Resolution Protocol: 1472 Or Converting Network Protocol Addresses to 1473 48 bit Ethernet Address for Transmission on 1474 Ethernet Hardware", RFC 826, November 1982. 1476 [RFC 2119] Bradner, S., "Key words for use in RFCs to 1477 Indicate Requirement Levels", BCP 14, RFC 2119, 1478 March 1997. 1480 [RFC 2460] S. Deering & R. Hinden, "Internet Protocol 1481 Version 6 Specification", RFC-2460, 1482 December 1998. 1484 [RFC 3007] B. Wellington, "Secure Domain Name System 1485 Dynamic Update", RFC-3007, November 2000. 1487 [RFC 3484] R. Draves, "Derfault Address Selection for IPv6", 1488 RFC 3484, February 2003. 1490 [RFC 4033] R. Arends, et alia, "DNS Security Introduction 1491 and Requirements", RFC-4033, March 2005. 1493 [RFC 4219] R. Hinden & S. Deering, "IP Version 6 1494 Addressing Architecture", RFC-4219, 1495 February 2006. 1497 [RFC 4861] T. Narten, E. Nordmark, W. Simpson, & H. Soliman, 1498 "Neighbor Discovery for IP version 6 (IPv6)", 1499 RFC 4861, September 2007. 1501 15.2. Informative References 1503 [8+8] M. O'Dell, "8+8 - An Alternate Addressing 1504 Architecture for IPv6", Internet-Draft, 1505 October 1996. 1507 [Bhatti10] S. Bhatti, "Reducing DNS Caching (or 'How low 1508 can we go ?')", Presentation to 38th JANET 1509 Networkshop, 31st March 2010, UK Joint 1510 Academic Network (JANET), University of Manchester, 1511 Manchester, England, UK. 1513 [CA-1995-01] US CERT, "IP Spoofing Attacks and Hijacked 1514 Terminal Connections", CERT Advisory 1995-01, 1515 Issued 23 JAN 1995, Revised 23 SEP 1997. 1517 [GSE] M. O'Dell, "GSE - An Alternate Addressing 1518 Architecture for IPv6", Internet-Draft, 1519 February 1997. 1521 [ID-ULA] R. Hinden, G. Huston, & T. Narten, "Centrally 1522 Assigned Unique Local IPv6 Unicast Addresses", 1523 draft-ietf-ipv6-ula-central-02.txt, 15 June 2007. 1525 [ID-Referral] B. Carpenter and others, "A Generic Referral 1526 Object for Internet Entities", 1527 draft-carpenter-behave-referral-object-01, 1528 20 October 2009. 1530 [IEEE-EUI] IEEE Standards Association, "Guidelines for 1531 64-bit Global Identifier (EUI-64)", IEEE, 1532 2007. 1534 [IEN 1] C.J. Bennett, S.W. Edge, & A.J. Hinchley, 1535 "Issues in the Interconnection of Datagram 1536 Networks", Internet Experiment Note (IEN) 1, 1537 INDRA Note 637, PSPWN 76, University College 1538 London, London, England, UK, WC1E 6BT, 1539 29 July 1977. 1540 http://www.postel.org/ien/ien001.pdf 1542 [IEN 19] J. F. Shoch, "Inter-Network Naming, Addressing, 1543 and Routing", IEN-19, January 1978. 1545 [IEN 23] J. F. Shoch, "On Names, Addresses, and 1546 Routings", IEN-23, January 1978. 1548 [IEN 31] D. Cohen, "On Names, Addresses, and Routings 1549 (II)", IEN-31, April 1978. 1551 [ILNP-Nonce] R. Atkinson, "Nonce Destination Option", 1552 draft-rja-ilnp-nonce-05.txt, August 2010. 1554 [ILNP-DNS] R. Atkinson, "DNS Resource Records for ILNP", 1555 draft-rja-ilnp-dns-06.txt, August 2010. 1557 [ILNP-ICMP] R. Atkinson, "ICMP Locator Update message" 1558 draft-rja-ilnp-icmp-04.txt, August 2010. 1560 [IPng95] D. Clark, "A thought on addressing", 1561 electronic mail message to IETF IPng WG, 1562 Message-ID: 9501111901.AA28426@caraway.lcs.mit.edu, 1563 Laboratory for Computer Science, MIT, 1564 Cambridge, MA, USA, 11 January 1995. 1566 [Liu-DNS] C. Liu & P. Albitz, "DNS & Bind", 5th Edition, 1567 O'Reilly & Associates, Sebastopol, CA, USA, 1568 May 2006. ISBN 0-596-10057-4 1570 [MobiArch07] R. Atkinson, S. Bhatti, & S. Hailes, 1571 "Mobility as an Integrated Service Through 1572 the Use of Naming", Proceedings of 1573 ACM MobiArch 2007, August 2007, 1574 Kyoto, Japan. 1576 [MobiArch08] R. Atkinson, S. Bhatti, & S. Hailes, 1577 "Mobility Through Naming: Impact on DNS", 1578 Proceedings of ACM MobiArch 2008, August 2008, 1579 Seattle, WA, USA. 1581 [MobiWAC07] R. Atkinson, S. Bhatti, & S. Hailes, 1582 "A Proposal for Unifying Mobility with 1583 Multi-Homing, NAT, & Security", 1584 Proceedings of ACM MobiWAC 2007, Chania, 1585 Crete. ACM, October 2007. 1587 [MILCOM08] R. Atkinson, S. Bhatti, & S. Hailes, 1588 "Harmonised Resilience, Security, and Mobility 1589 Capability for IP", Proceedings of IEEE 1590 Military Communications (MILCOM) Conference, 1591 San Diego, CA, USA, November 2008. 1593 [MILCOM09] R. Atkinson, S. Bhatti, & S. Hailes, 1594 "Site-Controlled Secure Multi-Homing and 1595 Traffic Engineering For IP", Proceedings of 1596 IEEE Military Communications (MILCOM) Conference, 1597 Boston, MA, USA, October 2009. 1599 [PHG02] Pappas, A, S. Hailes, & R. Giaffreda, 1600 "Mobile Host Location Tracking through DNS", 1601 Proceedings of IEEE London Communications 1602 Symposium, IEEE, September 2002, London, 1603 England, UK. 1605 [SBK2002] Alex C. Snoeren, Hari Balakrishnan, & M. Frans 1606 Kaashoek, "Reconsidering Internet Mobility", 1607 Proceedings of 8th Workshop on Hot Topics in 1608 Operating Systems, 2002. 1610 [SIPP94] Bob Smart, "Re: IPng Directorate meeting in 1611 Chicago; possible SIPP changes", electronic 1612 mail to the IETF SIPP WG mailing list, 1613 Message-ID: 1614 199406020647.AA09887@shark.mel.dit.csiro.au, 1615 Commonwealth Scientific & Industrial Research 1616 Organisation (CSIRO), Melbourne, VIC, 3001, 1617 Australia, 2 June 1994. 1619 [RFC 814] D.D. Clark, "Names, Addresses, Ports, and 1620 Routes", RFC-814, July 1982. 1622 [RFC 1498] J.H. Saltzer, "On the Naming and Binding of 1623 Network Destinations", RFC-1498, August 1993. 1625 [RFC 1631] K. Egevang & P. Francis, "The IP Network 1626 Address Translator (NAT)", RFC-1631, May 1994. 1628 [RFC 2827] P. Ferguson & D. Senie, "Network Ingress Filtering: 1629 Defeating Denial of Service Attacks which employ 1630 IP Source Address Spoofing", RFC-2827, May 2000. 1632 [RFC 3022] P. Srisuresh & K. Egevang, "Traditional IP 1633 Network Address Translator", RFC-3022, 1634 January 2001. 1636 [RFC 3027] M. Holdrege and P Srisuresh, "Protocol 1637 Complications of the IP Network Address 1638 Translator", RFC-3027, January 2001. 1640 [RFC 3704] F. Baker & P. Savola, "Ingress Filtering for 1641 Multihomed Networks, RFC-3704, March 2004. 1643 [RFC 3715] B. Aboba and W. Dixon, "IPsec-Network Address 1644 Translation (NAT) Compatibility Requirements", 1645 RFC-3715, March 2004. 1647 [RFC 3775] D. Johnson, C. Perkins, and J. Arkko, "Mobility 1648 Support in IPv6", RFC-3775, June 2004. 1650 [RFC 3948] A. Huttunen, et alia, "UDP Encapsulation of 1651 IPsec ESP Packets", RFC-3948, January 2005. 1653 [RFC 3971] J. Arkko, J. Kempf, B. Zill, & P. Nikander, 1654 "SEcure Neighbor Discovery (SEND)", RFC-3971 1655 March 2005. 1657 [RFC 3972] T. Aura, "Cryptographically Generated Addresses 1658 (CGAs)", RFC-3972, March 2005. 1660 [RFC 4193] R. Hinden & B. Haberman, "Unique Local IPv6 1661 Unicast Addresses, RFC-4193, October 2005. 1663 [RFC 4941] T. Narten, R. Draves, & S. Krishnan, "Privacy 1664 Extensions for Stateless Address Autoconfiguration 1665 in IPv6", RFC-4941, September 2007. 1667 [RFC 5061] R. Stewart, Q. Xie, M. Tuexen, S. Maruyama, & 1668 M. Kozuka, "Stream Control Transmission Protocol 1669 (SCTP) Dynamic Address Reconfiguration", RFC-5061, 1670 September 2007. 1672 [RFC 5534] J. Arkko & I. van Beijnum, "Failure Detection and 1673 Locator Pair Exploration Protocol for IPv6 1674 Multihoming", RFC-5534, June 2009. 1676 [TeleSys] R. Atkinson, S. Bhatti, & S. Hailes, 1677 "ILNP: Mobility, Multi-Homing, Localised Addressing 1678 and Security Through Naming", Telecommunications 1679 Systems, Volume 42, Number 3-4, pp 273-291, 1680 Springer-Verlag, December 2009, ISSN 1018-4864. 1682 ACKNOWLEDGEMENTS 1684 Steve Blake, Mohamed Boucadair, Saleem Bhatti, Noel Chiappa, 1685 Steve Hailes, Joel Halpern, Mark Handley, Volker Hilt, 1686 Paul Jakma, Dae-Young Kim, Tony Li, Yakov Rehkter and 1687 Robin Whittle (in alphabetical order) provided review and 1688 feedback on earlier versions of this document. Steve Blake 1689 provided an especially thorough review of the entire ILNP 1690 document set, which was extremely helpful. 1692 Noel Chiappa graciously provided the author with copies 1693 of the original email messages cited here as [SIPP94] and 1694 [IPng95], which enabled the precise citation of those 1695 messages herein. 1697 Author's Address 1699 RJ Atkinson 1700 Consultant 1701 McLean, VA 1702 22103 USA 1704 Email: rja.lists@gmail.com 1706 Expires: 7 JUN 2011