idnits 2.17.1 draft-rja-ilnp-intro-05.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 (24 June 2010) is 5048 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-11) exists of draft-rja-ilnp-nonce-03 == Outdated reference: A later version (-11) exists of draft-rja-ilnp-dns-04 == Outdated reference: A later version (-11) exists of draft-rja-ilnp-icmp-02 -- 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: 1 error (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft R. Atkinson 3 draft-rja-ilnp-intro-05.txt Consultant 4 Expires: 24 DEC 2010 24 June 2010 5 Category: Experimental 7 ILNP Concept of Operations 8 draft-rja-ilnp-intro-04.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. Also, ILNP 65 is 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 also have had 68 broader review than just the IRTF Routing RG. 70 Abstract 72 This document descibes the Concept of Operations for the 73 Identifier Locator Network Protocol (ILNP), which is an 74 experimental extension to IP. This is a product of the 75 IRTF Routing RG. 77 Table of Contents 79 1. Introduction ...............................................2 80 2. Locators & Identifiers......................................4 81 3. Transport Protocols.........................................8 82 4. Mobility....................................................9 83 5. Multi-Homing...............................................12 84 6. Localised Addressing.......................................13 85 7. IP Security Enhancements...................................14 86 8. DNS Enhancements...........................................15 87 9. Referrals & Application Programming Interfaces.............17 88 10. Backwards Compatibility....................................18 89 11. Incremental Deployment.....................................19 90 12. Implementation Considerations..............................20 91 13. Security Considerations ...................................21 92 14. IANA Considerations .......................................26 93 15. References ................................................26 95 1. INTRODUCTION 96 At present, the research and development community are exploring 97 various approaches to evolving the Internet Architecture. 98 Several different classes of evolution are being considered. One 99 class is often called "Map and Encapsulate", where traffic would 100 be mapped and then tunnelled through the inter-domain core of the 101 Internet. Another class being considered is sometimes known as 102 "Identifier/Locator Split". This document relates to a proposal 103 that is in the latter class of evoluationary approaches. 105 There has been substantial research relating to naming in the 106 Internet through the years. [IEN 1] [IEN 19] [IEN 23] [IEN 31] 107 [RFC 814] [RFC 1498] More recently, mindful of that important 108 prior work, and starting well before the Routing RG was 109 re-chartered to focus on inter-domain routing scalability, the 110 author has been examining enhancements to certain naming aspects 111 of the Internet Architecture. [MobiArch07] [MobiWAC07] 112 [MobiArch08] [MILCOM08] [MILCOM09] [TeleSys] 114 The architectural concept behind ILNP derives originally from a 115 June 1994 note by Bob Smart to the IETF SIPP WG mailing list. 116 [SIPP94] In January 1995, Dave Clark sent a note to the IETF IPng 117 WG mailing list suggesting that the IPv6 address be split into 118 separate Identifier and Locator fields. [IPng95] 120 Afterwards, Mike O'Dell persued this concept in Internet-Drafts 121 describing "8+8" or "GSE".[8+8] [GSE] More recently, the IRTF 122 Namespace Research Group (NSRG) studied this matter. Unusually 123 for an IRTF RG, the NSRG operated on the principle that unanimity 124 was required for the NSRG to make a recommendation. The author 125 was a member of the IRTF NSRG. At least one other proposal, the 126 Host Identity Protocol (HIP), also derives in part from the IRTF 127 NSRG studies (and related antecedent work). This current 128 proposal differs from O'Dell's work in various ways. 130 The crux of this proposal is to have different names for the 131 identity of a node and the location of its subnet, with crisp 132 semantics for each. This enhances the Internet Architecture 133 by adding crisp and clear semantics for the Identifier and 134 for the Locator, removing the semantically-muddled concept 135 of the IP address, and updating end system protocols slightly, 136 without requiring router changes. 138 With these naming enhancements, we have improved the Internet 139 Architecture by adding explicit support not only for 140 multi-homing, but also for mobility, localised addressing 141 (e.g. NAT/NAPT), and IP Security. 143 ILNP is an architecture, and can have more than one engineering 144 instantiation. The term ILNPv4 refers precisely to an instance 145 of ILNP that is based upon and backwards compatible with IPv4. 146 The term ILNPv6 refers precisely to an instance of ILNP that is 147 based upon and backwards compatible with IPv6. The following two 148 subsections provide brief overview of ILNPv6 and ILNPv4, 149 respectively. A full specification for either ILNPv4 or ILNPv6 is 150 beyond the scope of this document. Readers are referred to other 151 related ILNP documents for details not described here. [ILNP-DNS] 152 [ILNP-ICMP] [ILNP-Nonce] 154 1.1 Terminology 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 157 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 158 "OPTIONAL" in this document are to be interpreted as described 159 in RFC 2119. [RFC 2119] 161 2. LOCATORS & IDENTIFIERS 163 ILNP deprecates the semantically muddled concept of an "IP 164 Address" and replaces it with 2 new concepts, the "Locator" 165 and the "Identifier". 167 The Locator is used only to name the subnetwork a node is 168 connected to, while the Identifier is used only for node 169 identity. So the routing system uses Locators, while 170 upper-layer protocols (e.g. TCP/UDP pseudo-header checksum, 171 IPsec Security Association) use only the Identifier. 173 The same Identifier definition is used for both ILNPv4 and 174 ILNPv6. This is described in the next sub-section. Following 175 that is a description of ILNPv6, including a description of 176 the 64-bit Locator value used with ILNPv6. Then, there is a 177 description of ILNPv4, including a description of the 32-bit 178 Locator value used with ILNPv4. 180 2.1 Identifiers 182 With ILNP, the Identifier is an unsigned 64-bit number. 184 This provides a fixed-length non-topological name for a node. 185 Identifiers are bound to nodes, not to interfaces of a node. 186 All ILNP Identifiers MUST comply with the modified EUI-64 syntax 187 already specified for IPv6's "Interface Identifier" values. 188 [RFC 2460][RFC 4219][IEEE-EUI] 190 Identifiers are either globally-unique or locally-unique. 192 A reserved bit in the modified EUI-64 syntax clearly 193 indicates whether a given Identifier has global-scope or 194 local-scope.[RFC 4219][IEEE-EUI] A node is not required 195 to use a global-scope Identifier, although that is the 196 recommended practice. 198 Most commonly, Identifiers have global-scope and are derived 199 from one or more IEEE 802 or IEEE 1394 'MAC Addresses' (sic) 200 already associated with the node, following the procedure 201 already defined for IPv6.[RFC 4219] This approach eliminates 202 the need to manage Identifiers, among other benefits. 204 Locally-unique Identifiers MUST be unique within the context 205 of their Locators. The existing mechanisms of the IPv4 Address 206 Resolution Protocol [RFC 826] and IPv6 Neighbour Discovery 207 Protocol [RFC 4861] automatically enforce this constraint. 208 Locally-unique Identifiers MUST NOT be used with other Locators 209 without first ensuring uniqueness in the context of those other 210 Locators (e.g. by using IPv6 Neighbour Discovery's Duplicate 211 Address Detection mechanism). 213 Other methods might be used to generate local-scope Identifiers. 214 For example, one might derive Identifiers using some form of 215 cryptographic generation or using the methods specified in the 216 IPv6 Privacy Extensions to State-Less Address Auto-Configuration 217 (SLAAC). [RFC 3972, RFC 4941] One could also imagine creating a 218 local-scope Identifier by taking a cryptographic hash of a node's 219 public key. 221 2.2 ILNPv6 223 It is worth remembering here that an IPv6 address names a 224 specific network interface on a specific node, but an ILNP 225 Identifier names the node itself, not a specific interface 226 on the node. This difference in definition is essential 227 to providing seamless support for mobility and multi-homing, 228 which are discussed in more detail later in this note. 230 1 1 2 3 231 0 4 8 2 6 4 1 232 +---------------+-----------------+----------------+---------------+ 233 | Version| Traffic Class | Flow Label | 234 +---------------+-----------------+----------------+---------------+ 235 | Payload Length | Next Header | Hop Limit | 236 +---------------+-----------------+--------------------------------+ 237 | Source Address | 238 + + 239 | | 240 + + 241 | | 242 + + 243 | | 244 +---------------+-----------------+----------------+---------------+ 245 | Destination Address | 246 + + 247 | | 248 + + 249 | | 250 + + 251 | | 252 +---------------+-----------------+----------------+---------------+ 254 Figure 1: Existing ("Classic") IPv6 Header 256 The high-order 64-bits of the IPv6 address become the Locator. 257 The Locator indicates the subnetwork point of attachment for a 258 node. In essence, the Locator names a subnetwork. Locators are 259 also known as Routing Prefixes. Of course, backwards 260 compatibility requirements mean that ILNPv6 Locators use the same 261 number space as IPv6 routing prefixes. This ensures that no 262 changes are needed to deployed IPv6 routers when deploying 263 ILNPv6. 265 The low-order 64-bits of the IPv6 address become the Identifier. 266 Details of the Identifier were discussed just above. 268 1 1 2 3 269 0 4 8 2 6 4 1 270 +---------------+-----------------+----------------+---------------+ 271 | Version| Traffic Class | Flow Label | 272 +---------------+-----------------+----------------+---------------+ 273 | Payload Length | Next Header | Hop Limit | 274 +---------------+-----------------+----------------+---------------+ 275 | Source Locator | 276 + + 277 | | 278 +---------------+-----------------+----------------+---------------+ 279 | Source Identifier | 280 + + 281 | | 282 +---------------+-----------------+----------------+---------------+ 283 | Destination Locator | 284 + + 285 | | 286 +---------------+-----------------+----------------+---------------+ 287 | Destination Identifier | 288 + + 289 | | 290 +---------------+-----------------+----------------+---------------+ 292 Figure 2: ILNPv6 Header 294 2.3 ILNPv4 296 ILNPv4 is merely a different instantiation of the ILNP 297 Architecture, so it retains the crisp distinction between 298 the Locator and the Identifier. Also, as with ILNPv6, 299 when ILNPv4 is used for a session, the upper-layer 300 protocols (e.g. TCP/UDP pseudo-header checksum, IPsec 301 Security Association) bind only to the Identifiers, 302 never to the Locators. As with ILNPv6, only the Locator 303 values are used for routing ILNPv4 packets. 305 Just as ILNPv6 is carefully engineered to be backwards- 306 compatible with IPv6, ILNPv4 is carefully engineered 307 to be backwards-compatible with IPv4. 309 The Source IP Address in the IPv4 header becomes the ILNPv4 310 Locator value, while the Destination IP Address of the IPv4 311 header becomes the Destination ILNPv4 Locator value. Of course, 312 backwards compatibility requirements mean that ILNPv4 Locators 313 use the same number space as IPv4 routing prefixes. 315 ILNPv4 uses the same 64-bit Identifier, with the same modified 316 EUI-64 syntax, as ILNPv6. Because the IPv4 address is much 317 smaller than the IPv6 address, ILNPv4 cannot carry the 318 Identifier values in the fixed portion of the IPv4 header. 319 The obvious two ways to carry the ILNP Identifier with ILNPv4 320 are either as an IPv4 Option or as an IPv6-style Extension 321 Header placed after the IPv4 header and before the upper-layer 322 protocol (e.g. OSPF, TCP, UDP, SCTP). 324 At least some currently available IPv4 forwarding silicon is able 325 to parse past IPv4 options to examine the upper-layer protocol 326 header at wire-speed on reasonably fast (e.g. 1 Gbps or better) 327 network interfaces. By contrast, no existing silicon is able 328 to parse past a new Extension Header at all. So, for engineering 329 reasons, ILNPv4 uses a new IPv4 Option to carry the Identifier 330 values. 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 |Version|IHL=12 |Type of Service| Total Length | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Identification |Flags| Fragment Offset | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Time to Live | Protocol | Header Checksum | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Source Locator | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Destination Locator | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | OT=ILNPv4_ID | OL=5 | Padding=0x0000 | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | | 346 + Source Identifier + 347 | | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | | 350 + Destination Identifier + 351 | | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 |OT=ILNPv4_NONCE| OL=2 | top 16 bits of nonce | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | lower 32 bits of nonce | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 Figure 3: ILNPv4 header with ILNP ID option 359 and ILNP Nonce option. 361 Notation for Figure 3: 362 IHL: Internet Header Length 363 OT: Option Type 364 OL: Option Length 366 The remainder of this note focuses on ILNP for IPv6, in the 367 interest of both clarity and brevity, however the same 368 architectural concepts and principles also apply to ILNP 369 for IPv4, albeit with slightly different engineering. 371 3. TRANSPORT PROTOCOLS 373 At present, commonly deployed transport protocols include a 374 pseudo-header checksum that includes certain network-layer 375 fields, the IP addresses used for the session, in its 376 calculation. This inclusion of network-layer information 377 within the transport-layer session state creates issues for 378 multi-homing, mobility, IP Security, and localised addressing 379 (e.g. using Network Address Translation). [RFC 1631][RFC 3022] 381 This unfortunate aspect of the TCP pseudo-header checksum 382 has been understood to be an architectural problem at least 383 since 1977, well before the transition from NCP to 384 IPv4.[IEN 1][IEN 19][IEN 23][IEN 31][RFC 1498] 386 With this proposal, transport protocols include only the 387 Identifier in their pseudo-header calculations, but do not 388 include the Locator in their pseudo-header calculations. 390 To minimise the changes required within transport protocol 391 implementations, when this proposal is in use for a 392 communications session, the Locator fields are zeroed for 393 the purpose of transport-layer pseudo-header calculations. 395 Later in this document, methods for incremental deployment 396 of this change and backwards compatibility with non-upgraded 397 nodes are described. 399 4. MOBILITY 401 First, please recall that mobiity and multi-homing actually 402 present the same set of issues. In each case, the set of 403 Locators associated with a node or site changes. The reason 404 for the change might be different, but the effects on the 405 network and on correspondents is identical. 407 There are no standardised mechanisms to update most transport 408 protocols with new IP addresses in use for the session. 409 Exceptionally, the Stream Control Transport Protocol (SCTP) 410 recently added this capability.[RFC 5061] In July 2008, Mark 411 Handley at UCL proposed adding such a capability to TCP during 412 a presentation at the IRTF Routing RG in Dublin, Ireland. 413 His Multi-Path TCP concept is being considered in the IETF 414 as of this writing. 416 This creates various issues for mobility. For example, there 417 is no method at present to update the IP addresses associated 418 with a transport layer session when one of the nodes in that 419 session moves (i.e. changes one of its points of network 420 attachment). 422 So, the several approaches to IP mobility seek to hide the 423 change in location (and corresponding change in IP addresses) 424 via tunnelling, home agents, foreign agents, and so forth. 425 [RFC 3775] All of this can add substantial complexity to IP 426 mobility approaches, both in the initial deployment and also 427 in ongoing operation. 429 By contrast, this ILNP proposal hides each node's location 430 information from the transport layer protocols at all times, 431 by removing location information from the transport session 432 state (e.g. pseudo-header checksum calculations). 434 In this proposal, mobility and multi-homing are supported using 435 a common set of mechanisms. In both cases, different Locator 436 values are used to identify different IP subnetworks. 438 To handle the move of a node, we add a new ICMP control message. 439 The ICMP Locator Update message is used by a node to inform its 440 existing correspondents that the set of valid Locators for the 441 node has changed. This mechanism can be used to add newly valid 442 Locators, to remove no longer valid Locators, or to do both at 443 the same time. Further, the node uses Secure Dynamic DNS Update 444 to correct the set of L64 records in the DNS for that node. 445 [RFC 3007] This enables any new correspondents to correctly 446 initiate a new session with the node at its new location. 448 This use of DNS for initial rendezvous with mobile node was 449 independently proposed by others [PHG02] and then separately 450 re-invented by the current author later on. 452 (The Locator Update control message could be an entirely new 453 protocol running over UDP, for example, but there is no obvious 454 advantage to creating a new protocol rather than using a new 455 ICMP message.) 457 With ILNP, network mobility (as well as node mobility) 458 is considered a special case of multihoming. That is, 459 when a network moves, it uses a new Locator value for all 460 of its communications sessions. So, the same mechanism, 461 using a new or additional Locator value, also supports 462 network mobility. Similarly, when a multi-homed site 463 or multi-homed node changes its set of upstream links, 464 the Locators associated with that site or node change. 466 So in ILNP, when a connectivity change affects the set of 467 valid Locators, the affected node(s) actively: 469 (1) use the ICMP Locator Update message to inform their 470 existing correspondents with the updated information 471 about their currently valid Locator(s). [ILNP-ICMP] 473 AND also 474 (2) update their DNS entries, most commonly by using 475 the Secure Dynamic DNS Update mechanism. [RFC 3007] 477 In the unlikely event of simultaneous motion which changes 478 both nodes' Locators within a very small time period, a 479 node can use the DNS to discover the new Locator value(s) 480 for the other node. 482 As a DNS performance optimisation, the "LP" DNS resource record 483 MAY be used to avoid requiring each node on a subnetwork to 484 update its DNS L64 record entries when that subnetwork's location 485 (e.g. upstream connectivity) changes. In this case, the nodes on 486 the subnetwork each would have an "LP" record pointing to a 487 common domain-name used to name that subnetwork. In turn, that 488 subnetwork's domain name would have one or more L64 record(s) in 489 the DNS. 491 Correspondents of a node on that subnetwork would perform a "L64" 492 record query for that target node (or an "ID" query for that 493 target node) and receive the "LP" records as additional data in 494 the DNS reply. Then the correspondent would perform an L64 495 record lookup on the domain-name pointed to by that LP record, 496 in order to learn the Locator value to use to reach that 497 target node. 499 For bi-directional flows, such as a TCP session, each node knows 500 whether the current path in use is working by the reception of 501 data packets, acknowledgements, or both. As with TCP/IP, 502 TCP/ILNP does not need special path probes. UDP/ILNP sessions 503 with acknowledgements work similarly, and also don't need special 504 path probes. 506 In the deployed Internet, the sending node for a UDP/IP session 507 without acknowledgements does not know for certain that all 508 packets are received by the intended receiving node. Such 509 UDP/ILNP sessions fare no worse than UDP/IP sessions. The 510 receiver(s) of such a UDP session SHOULD send a gratuitous IP 511 packet containing an ILNP Nonce option to the sender, in order to 512 enable the receiver to subsequently send ICMP Locator Updates if 513 appropriate. In this last case, UDP/ILNP sessions fare better 514 than UDP/IP sessions, still without using network path probes. 516 One might wonder what happens if a mobile node is moving more 517 quickly than DNS can be updated. This situation is unlikely, 518 particularly given the widespread use of link-layer mobility 519 mechanisms (e.g. GSM, IEEE 802 bridging) in combination with 520 network-layer mobility. However, the situation is functionally 521 equivalent to the situation where a traditional IP node is moving 522 faster than the Mobile IPv4 or Mobile IPv6 agents/servers can be 523 updated with the mobile node's new location. So the issue is not 524 new in any way. In all cases, Mobile IPv4 and Mobile IPv6 and 525 ILNP, a node moving that quickly might be temporarily unreachable 526 until it remains at a given network-layer location (e.g. IP 527 subnetwork) long enough for the location update mechanisms (for 528 Mobile IPv4, for Mobile IPv6, or ILNP) to catch up. ILNP is 529 prospectively better than either form of Mobile IP with respect 530 to key management, given that ILNP is using Secure Dynamic DNS 531 Update and given that neither form of Mobile IP has a 532 standardised and scalable key management mechanism at present. 534 5. MULTI-HOMING 536 Conceptually, there are two kinds of multi-homing. Site 537 multi-homing is when all nodes at a site are multi-homed 538 at the same time. This is what most people mean when they 539 talk about multi-homing. However, there is also a separate 540 concept of node multi-homing, where only a single node is 541 multi-homed. 543 At present, site multi-homing is common in the deployed Internet. 544 This is primarily achieved by advertising the site's routing 545 prefix(es) to more than upstream Internet service provider at a 546 given time. In turn, this requires de-aggregation of routing 547 prefixes within the inter-domain routing system. In turn, this 548 increases the entropy of the inter-domain routing system (e.g. 549 RIB/FIB size increases beyond the minimal RIB/FIB size that 550 would be required to reach all sites). 552 At present, node multi-homing is not common in the deployed 553 Internet. When TCP or UDP are in use for an IP session, node 554 multi-homing cannot provide session resilience, because the 555 transport pseudo-header checksum binds the session to a single 556 interface of the multi-homed node. SCTP has a protocol-specific 557 mechanism to support node multi-homing; SCTP can support session 558 resilience both at present and also without change in the 559 proposed approach. [RFC 5061] 561 In the new scheme, when a node is multi-homed, then the node 562 typically has more than one valid Locator value. When one 563 upstream connection fails, the node sends an ICMP Locator Update 564 message to each existing correspondent node to remove the 565 no-longer-valid Locator from the set of valid Locators. 566 [ILNP-ICMP] Also, the node can use Secure Dynamic DNS Update 567 to alter the set of currently valid L64 records associated with 568 that node. [RFC 3007] This second step ensures that any new 569 correspondents can reach the node. 571 In the new scheme, site multi-homing works in a similar manner, 572 with nodes having one Locator for each upstream connection to 573 the Internet. To avoid a DNS Update burst when a site or 574 (sub)network moves location, a DNS record optimisation is 575 possible. This would change the number of DNS Updates required 576 from Order(number of nodes at the site/subnetwork that moved) 577 to Order(1). [ILNP-DNS] 579 Additionally, since the transport-protocol session state no 580 longer includes the Locators, a site could choose to perform 581 Locator rewriting at its site border routers, possibly in 582 combination with applying site traffic engineering policy on 583 which upstream link to use for which packets. Since the site 584 border router(s) are in the middle of any exterior packet flow, 585 they also can send proxy Locator Update messages on behalf of 586 nodes inside that site, and can even include the appropriate 587 Nonce value in such proxy Locator Updates, if desired by that 588 site's administration. 590 6. LOCALISED ADDRESSING 592 As the Locator value no longer forms part of the node session 593 state (e.g. TCP pseudo-header), it is easier to support 594 localised addressing, which is sometimes also called "Private 595 Addressing", based on the use of local values of the Locator. 596 This would be either in place of, or to supplement, existing 597 NAT-based schemes. [RFC 1631] [RFC 3022] 599 For example, a site that desires to use private addresses 600 internally might deploy IPv6 Unique Local Addressing 601 (ULA) for localised addressing, along with some form of ILNP/ 602 IPv6 Network Address Translation at a site border gateway. 603 [ID-ULA] [RFC 4193] This example is described in detail 604 in [MILCOM09], both as a mechanism for site multi-homing 605 and also as a mechanism to support site-controlled traffic 606 engineering. 608 In the simplest case, an ILNP capable NAT only would need to 609 change the value of the Source Locator in an outbound packet, 610 and the value of the Destination Locator for an inbound packet. 611 Identifier values would not need to change, so a true end-to-end 612 session could be maintained. 614 If a site using localised addressing chooses to deploy a 615 split-horizon DNS server, then the DNS server would advertise 616 the global-scope Locator(s) of the site border routers outside 617 the site to DNS clients outside the site, and would advertise 618 the local-scope Locator(s) specific to that internal node to 619 DNS clients inside the site. Such deployments of split-horizon 620 DNS servers are not unusual in the IPv4 Internet today. If an 621 internal node (e.g. portable computer) moves outside the site, 622 it would follow the normal ILNP methods to update its 623 authoritative DNS server with its current Locator set. In this 624 deployment model, the authoritative DNS server for that mobile 625 device will be either the split-horizon DNS server itself or the 626 master DNS server providing data to the split-horizon DNS server. 628 If a site using localised addressing chooses not to deploy a 629 split-horizon DNS server, then all internal nodes would 630 advertise the global-scope Locator(s) of the site border routers. 631 To deliver packets from one internal node to another internal 632 node, the site would either choose to use layer-2 bridging 633 (e.g. IEEE Spanning Tree, IEEE Rapid Spanning Tree, or a 634 link-state layer-2 algorithm such as the IETF TRILL group or 635 IEEE 802.1 are developing), or the interior routers would 636 forward packets up to the nearest site border router, 637 which in turn would then rewrite the Locators to appropriate 638 local-scope values, and forward the packet towards the interior 639 destination node. 641 We note that a deployment using private/local addressing can 642 also provide site multi-homing by deploying site border 643 routers in this manner. 645 Please note that with this proposal, localised addressing 646 (e.g. using Network Address Translation on the Locator bits) 647 would work in harmony with multihoming, mobility, and IP 648 Security.[MobiWAC07][MILCOM08][MILCOM09] 650 7. IP SECURITY ENHANCEMENTS 652 A current issue is that the IP Security protocols, AH and ESP, 653 have Security Associations that include the IP addresses of 654 the secure session endpoints. This was understood to be a 655 problem when AH and ESP were originally defined, however the 656 limited set of namespaces in the Internet Architecture did not 657 provide any better choices at that time. 659 Operationally, this binding causes problems for the use of the 660 IPsec protocols through Network Address Translation devices, 661 with mobile nodes (because the mobile node's IP address changes 662 at each network-layer handoff), and with multi-homed nodes 663 (because the session is bound to a particular interface of the 664 multi-homed node, rather than being bound to the node 665 itself).[RFC 3027][RFC 3715] 666 To resolve the issue of IPsec interoperability through a 667 NAT deployment, UDP encapsulation of IPsec is commonly 668 used today.[RFC 3948] 670 With this proposal, the IP Security protocols, AH and ESP, 671 are enhanced to bind Security Associations only to 672 Identifier values and never to Locator values (and also 673 not to an entire 128-bit IPv6 address). 675 Similarly, key management protocols used with IPsec would be 676 enhanced to deprecate use of IP addresses as identifiers and 677 to substitute the use of the new Identifier for that 678 purpose. 680 This small change enables IPsec to work in harmony with 681 multihoming, mobility, and localised addressing. [MILCOM08] 682 [MILCOM09] Further, it would obviate the need for specialised 683 IPsec NAT Traversal mechanisms, thus simplifying IPsec 684 implementations while enhancing deployability and 685 interoperability. [RFC 3948] 687 This change does not reduce the security provided by the 688 IP Security protocols. 690 8. DNS ENHANCEMENTS 692 As part of this proposal, additional DNS Resource Records have 693 been proposed in a separate document. [ILNP-DNS] These new 694 records store the Identifier and Locator values for nodes that 695 have been upgraded to support the Identifier-Locator Split Mode. 697 With this proposal, mobile or multi-homed nodes and sites are 698 expected to use the existing "Secure Dynamic DNS Update" protocol 699 to keep their Identifier and Locator records correct in its 700 authoritative DNS server(s). [RFC 3007] 702 While some might be surprised, Secure Dynamic DNS Update is 703 available now in a very wide range of existing deployed systems. 704 For example, Microsoft Windows XP (and later versions), the 705 freely distributable BIND DNS software package (used in Apple 706 MacOS X and in most UNIX systems), and the commercial Nominum DNS 707 server all implement support for Secure Dynamic DNS Update and 708 are known to interoperate. [Liu-DNS] There are credible reports 709 that when a site deploys Microsoft's Active Directory, the site 710 (silently) automatically deploys Secure Dynamic DNS 711 Update. [Liu-DNS] So it appears that many sites have already 712 deployed Secure Dynamic DNS Update even though they might not be 713 aware they have already deployed that protocol. [Liu-DNS] 714 Reverse DNS lookups, to find a node's Fully Qualified Domain Name 715 from the combination of a Locator and related Identifier value, 716 can be performed as at present. 718 Previous research by others indicates that DNS caching is largely 719 ineffective, with the exception of NS records and the addresses 720 of DNS servers referred to by NS records.[SBK2002] This means DNS 721 caching performance will not be adversely affected by assigning 722 very short time-to-live (TTL) values to the Locator records of 723 typical nodes. It also means that it is preferable to deploy the 724 DNS server function on nodes that have longer TTL values, rather 725 than on nodes that have shorter TTL values. 727 Identifier values might be very long-lived (e.g. days) when they 728 have been generated from an IEEE MAC Address on the system. 729 Identifier values might have a shorter lifetime (e.g. hours) if 730 they have been cryptographically-generated [RFC 3972], or have 731 been created by the IPv6 Privacy Extensions [RFC 4941], or 732 otherwise have the EUI-64 scope bit at the "local-scope" value. 733 Note that a given ILNP session normally will use a single 734 Identifier value for the life of that session. 736 Existing DNS specifications require that DNS clients and DNS 737 resolvers obey the TTL values provided by the DNS servers. In 738 the context of this proposal, short DNS TTL values are assigned 739 to particular DNS records to ensure that the ubiquitous DNS 740 caching resolvers do not cache volatile values (e.g. Locator 741 records of a mobile node) and consequently return stale 742 information to new requestors. 744 As a practical matter, it is not sensible to flush all Locator 745 values associated with an existing session's remote node from 746 the local node's ILNP Correspondent Cache. Instead, Locator 747 values in the ILNP Correspondent Cache SHOULD be marked as 748 "aged" when their TTL has expired until either the next Locator 749 Update message is received or there is other indication that 750 a given Locator is not working any longer. 752 During a long transition period, a node that is I/L-enabled 753 SHOULD have not only ID and L64 (or ID and LP) records present 754 in its authoritative DNS server, but also SHOULD have AAAA 755 records in the DNS for the benefit of non-upgraded nodes. 756 This capability might be implemented strictly inside a DNS 757 server, whereby the DNS server synthesised a set of AAAA records 758 to advertise from the ID and L64 values that the node has kept 759 updated in that DNS server. 761 Existing DNS specifications require that a DNS resolver or 762 DNS client ignore unrecognised DNS record types. So 763 gratuitously appending ID and L64 records as "additional data" 764 in DNS responses to AAAA queries ought not create any 765 operational issues. 767 9. REFERRALS & APPLICATION PROGRAMMING INTERFACES 769 This section is concerned with support for using 770 existing ("legacy") applications over ILNP, including 771 both referrals and APIs. 773 9.1 BSD Sockets APIs 775 The existing BSD Sockets API can continue to be used with 776 ILNP underneath the API. That API can be implemented in a 777 manner that hides the underlying protocol changes from the 778 applications. For example, the combination of a Locator 779 and an Identifier can be used with the API in the place 780 of an IPv6 address. 782 So it is believed that existing IP address referrals can 783 continue to work properly in most cases. For a rapidly 784 moving target node, referrals might break in at least some 785 cases. The potential for referral breakage is necessarily 786 dependent upon the specific application and implementation 787 being considered. 789 It is suggested, however, that a new, optional, more abstract, 790 C language API be created so that new applications may avoid 791 delving into low-level details of the underlying network 792 protocols. Such an API would be useful today, even with 793 the existing IPv4 and IPv6 Internet, whether or not ILNP 794 were ever widely deployed. 796 9.2 Java APIs 798 Most existing Java APIs already use abstracted network 799 programming interfaces, for example in the java.Net.URL class. 800 Because these APIs already hide the low-level network-protocol 801 details from the applications, the applications using these APIs 802 (and the APIs themselves) don't need any modification to work 803 equally well with IPv4, IPv6, ILNP, and probably also HIP. 805 9.3 Referrals in the Future 807 The approach proposed in [ID-Referral] appears to be very 808 suitable for use with ILNP, in addition to being suitable 809 for use with the deployed Internet. Protocols using that 810 approach would not need modification to have their referrals 811 work well with IPv4, IPv6, ILNP, and probably also other 812 network protocols (e.g. HIP). 814 A more sensible approach to referrals would be to use 815 Fully-Qualified Domain Names (FQDNs), as is commonly done 816 today with web URLs. This is approach is highly portable 817 across different network protocols, even with both the IPv4 818 Internet or the IPv6 Internet. 820 10. BACKWARDS COMPATIBILITY 822 First, if one compares Figure 1 and Figure 2, one can see 823 that IPv6 with the Identifier/Locator Split enhancement is 824 fully backwards compatible with existing IPv6. This means 825 that no router software or silicon changes are necessary to 826 support the proposed enhancements. A router would be 827 unaware whether the packet being forwarded were classic IPv6 828 or the proposed enhanced version of IPv6. So no changes to 829 IPv6 routers is required to deploy this proposal. 831 Further, IPv6 Neighbour Discovery should work fine as is. 833 If a node that has been enhanced to support the Identifier/ 834 Locator Split mode initiates an IP session with another node, 835 normally it will first perform a DNS lookup on the responding 836 node's DNS name. If the initiator node does not find any ID 837 or L64 DNS resource records for the responder node, then the 838 initiator uses the Classical IPv6 mode of operation for the 839 new session with the responder, rather than trying to use 840 the I/L Split mode for that session. 842 If the responder node for a new IP session has not been enhanced 843 to support the I/L Split mode and receives initial packet(s) 844 containing the Nonce Destination Option, the responder will drop 845 the packet and send an ICMP Parameter Problem error message back 846 to the initiator. 848 If the initiator node does not receive a response from the 849 responder in a timely manner (e.g. within TCP timeout for a TCP 850 session) and also does not receive an ICMP Unreachable error 851 message for that packet, OR if the initiator receives an ICMP 852 Parameter Problem error message for that packet, then the 853 initiator knows that the responder is not able to support the I/L 854 Split Operating mode. In this case, the initiator node SHOULD 855 try again to create the new IP session but this time OMITTING the 856 Nonce Destination Option, and this time operating in Classic IPv6 857 mode, rather than I/L Split mode. 859 Finally, since an ILNP node is also a fully-capable IPv6 node, 860 then the upgraded node can use any standardised IPv6 mechanisms 861 for communicating with a legacy IPv6 node (i.e. an IPv6 node 862 without ILNP capability enhancements). So ILNP will in no case 863 be worse than existing IPv6, and in many cases ILNP will out 864 perform existing IPv6. 866 11. INCREMENTAL DEPLOYMENT 868 If a node has been enhanced to support the Identifier/ Locator 869 Split operating mode, that node's fully-qualified domain name 870 will normally have one or more ID records and one or more L64 871 records associated with it in the DNS. 873 When a host ("initiator") initiates a new IP session with a 874 correspondent ("responder"), it normally will perform a DNS 875 lookup to determine the address(es) of the responder. A host 876 that has been enhanced to support the Identifier/ Locator Split 877 operating mode normally will look for Identifier ("ID") and 878 Locator ("L64") records in any received DNS replies. DNS servers 879 that support ID and L64 records SHOULD include them (when they 880 exist) as additional data in all DNS replies to queries for 881 DNS AAAA records.[ILNP-DNS] 883 If the initiator supports the I/L Split mode and from DNS 884 information learns that the responder also supports the 885 I/L Split mode, then the initiator will generate an 886 unpredictable nonce value, store that value in a local 887 Correspondent Cache, which is described in more detail below, 888 and will include the Nonce Destination Option in its 889 initial packet(s) to the responder.[ILNP-Nonce] 891 If the responder supports the I/L Split mode and receives 892 initial packet(s) containing the Nonce Destination Option, 893 the responder will thereby know that the initiator supports 894 the I/L Split mode and the responder will also operate in 895 I/L Split mode for this new IP session. 897 If the responder supports the I/L Split mode and receives 898 initial packet(s) NOT containing the Nonce Destination Option, 899 the responder will thereby know that the initiator does NOT 900 support the I/L Split mode and the responder will operate 901 in classic IPv6 mode for this new IP session. 903 The previous section described how interoperability between 904 enhanced nodes and non-enhanced nodes is retained even if a 905 non-enhanced node erroneously has ID and/or L64 DNS resource 906 records in place (e.g. due to some accident). 908 The mobility capabilities of ILNP might be the most important in 909 the deployment world. Despite substantial good efforts by many, 910 neither Mobile IPv4 nor Mobile IPv6 are widely used at present. 911 However, much of the recent work in operating systems has focused 912 on support for mobile devices (e.g. mobile telephone handsets, 913 hand-held music players, hand-held organisers). Those devices 914 probably represent the fastest growth segment of the Internet at 915 present. Moreover, many vendors of such devices have included 916 significant networking protocol improvements in incremental 917 operating system updates, rather than always waiting for a new 918 major release to add networking facilities. However, other users 919 or vendors might be more interested by the new security models 920 enabled by having Identifiers different from Locators, or they 921 might be more interested in the ability to provide node-specific 922 multi-homing, rather than always multi-homing an entire site. In 923 the end, the marketplace has myriad users with various functional 924 needs. The set of improvements offered by ILNP is broad, and 925 should appeal to a wide range of vendors and users. 927 12. IMPLEMENTATION CONSIDERATIONS 929 This section discusses implementation considerations that 930 are not otherwise discussed in the ILNP Internet-Drafts. 932 12.1 ILNP Correspondent Cache 934 An ILNP-capable node will need to modify its network protocol 935 implementation to add an ILNP Correspondent Cache. In theory, 936 this cache is within the ILNP network-layer. However, many 937 network protocol implementations do not have strict protocol 938 separation or layering. In the interest of efficient 939 implementation, and to avoid unduly restricting implementers, 940 an ILNP implementation is not required to limit the 941 accessibility of ILNP Correspondent Cache to the network-layer. 943 The ILNP Correspondent Cache contains at least the following 944 inter-related data elements: 946 Set of Local Locator(s) 947 & Preference value for each Locator 948 Set of Correspondent' Locator(s) 949 & Preference value for each Locator 950 Set of Local Identifier(s) 951 Set of Correspondent's Identifier(s) 952 Nonce used from the local node to that correspondent 953 Nonce used from that correspondent to the local node 954 Valid Time 956 Lookups in the ILNP Correspondent Cache normally use an 957 (Correspondent Identifier, Nonce) tuple as a lookup key. 958 This facilitates situations where, perhaps due to deployment 959 of Local-scope Identifiers, more than one correspondent node 960 is using the same Identifier value. 962 The Valid Time field holds the (UTC) time (measured as seconds 963 since January 1st 1970, as with Network Time Protocol) through 964 which this ILNP session information is valid. A table entry 965 entry is current if the node's current time is less than or equal 966 to the time in the Valid Time field, while a table entry is aged 967 if the node's current time is greater than the time in the Valid 968 Time field. 970 12.2 ICMP Locator Updates 972 While ILNP's ICMP Locator Update message is defined in a 973 separate document [ILNP-ICMP], it is worth mentioning that 974 received authenticated Locator Update messages cause the 975 ILNP Correspondent Cache described just above to be updated. 976 Implementers should keep in mind that a node or site might 977 have a large number of concurrent Locators, and should 978 ensure that a system fault does not arise if the system 979 receives an authentic ICMP Locator Update containing a 980 large number of Locator values. 982 13. SECURITY CONSIDERATIONS 984 This proposal outlines a proposed evolution for the Internet 985 Architecture to provide improved capabilities. This section 986 discusses security considerations for this proposal. 988 13.1 Authentication of Locator Updates 990 A separate document [ILNP-Nonce] proposed a new IPv6 991 Destination Option that can be used to carry a session nonce 992 end-to-end between communicating nodes. That nonce provides 993 protection against off-path attacks on an Identifier/Locator 994 session. The Nonce Destination Option is used ONLY for IP 995 sessions in the Identifier/Locator Split mode. 997 Ordinary IPv6 is vulnerable to on-path attacks unless 998 the IP Authentication Header or IP Encapsulating Security 999 Payload is in use. So the Nonce Destination Option 1000 only seeks to provide protection against off-path attacks 1001 on an IP session -- equivalent to ordinary IPv6 when 1002 not using IP Security. 1004 When the Identifier/Locator split mode is in use for an 1005 existing IP session, the Nonce Destination Option MUST be 1006 included in any ICMP control messages (e.g. ICMP Unreachable, 1007 ICMP Locator Update) sent with regard to that IP session. 1009 It is common to have non-symmetric paths between two nodes 1010 on the Internet. To reduce the number of on-path nodes that 1011 know the Nonce value for a given session when the I/L split 1012 mode is in use, a nonce value is unidirectional, not 1013 bidirectional. For example, for a session between two nodes 1014 A and B, one nonce value is used from A to B and a different 1015 nonce value is used from B to A. 1017 When in the I/L Split operating mode for an existing IP 1018 session, ICMP control messages received without a Nonce 1019 Destination Option MUST be discarded as forgeries. This 1020 security event SHOULD be logged. 1022 When in the I/L Split operating mode for an existing IP 1023 session, ICMP control messages received without a correct 1024 nonce value inside the Nonce Destination Option MUST be 1025 discarded as forgeries. This security event SHOULD be logged. 1027 When in the I/L Split operating mode for an existing IP 1028 session, and a node changes its Locator set, it should 1029 include the Nonce Destination Option in the first few 1030 data packets sent using a new Locator value, so that 1031 the recipient can validate the received data packets 1032 as valid (despite having an unexpected Source Locator 1033 value). 1035 For ID/Locator Split mode sessions operating in higher risk 1036 environments, the use of the cryptographic authentication 1037 provided by IP Authentication Header is recommended 1038 *in addition* to concurrent use of the Nonce Destination 1039 Option. 1041 It is important to note that at present an IPv6 session is 1042 entirely vulnerable to on-path attacks unless IPsec is in use 1043 for that particular IPv6 session, so the security properties 1044 of the new proposal are never worse than for existing IPv6. 1046 13.2 Forged Identifier Attacks 1047 In the deployed Internet, active attacks using packets with a 1048 forged Source IP Address have been publicly known at least since 1049 early 1995.[CA-1995-01] While these exist in the deployed 1050 Internet, they have not been widespread. This is equivalent to 1051 the issue of a forged Identifier value and demonstrates that this 1052 is not a new threat created by the Identifier/Locator-split mode 1053 of operation. 1055 One mitigation for these attacks has been to deploy Source IP 1056 Address Filtering.[RFC 2827] [RFC 3704] Jun Bi at U. Tsinghua 1057 cites Arbor Networks as reporting that this mechanism has less 1058 than 50% deployment and cites an MIT analysis indicating that at 1059 least 25% of the deployed Internet permits forged source IP 1060 addresses. 1062 Other parts of this document discuss the probability of an 1063 accidental duplicate Identifier being used on the Internet. 1064 However, this sub-section instead focuses on methods for 1065 mitigating attacks based on packets containing deliberately 1066 forged Source Identifier values. 1068 First, the recommendations of [RFC 2827] & [RFC 3704] remain. 1069 So any packets that have a forged Locator value can be easily 1070 filtered using existing widely available mechanisms. 1072 Second, the receiving node does not blindly accept any packet 1073 with the proper Source Identifier and proper Destination 1074 Identifier as an authentic packet. Instead, each node operating 1075 the I/L-split mode maintains an ILNP Correspondent Cache for each 1076 of its correspondents, as described above. This cache contains 1077 two unidirectional nonce values (one used in control messages 1078 sent by this node, a different one used to authenticate messages 1079 from the other node). The correspondent cache also contains 1080 the currently valid set of Locators and set of Identifiers for 1081 each correspondent node. If a received packet contains valid 1082 Identifier values and a valid Destination Locator, but contains 1083 a Source Locator value that is not present in the correspondent 1084 cache, the packet is dropped without further processing as an 1085 invalid packet, unless the packet also contains a Nonce 1086 Destination Option with the correct value used for packets from 1087 the node with that Source Identifier to this node. This prevents 1088 an off-path attacker from stealing an existing session. 1090 Third, any node can distinguish different nodes using the same 1091 Identifier value by other properties of their sessions. IPv6 1092 Neighbor Discovery prevents more than one node from using the 1093 same source (Locator + Identifier) pair at the same time. So 1094 cases of different nodes using the same Identifier value will 1095 involve nodes that have different sets of valid Locator values. 1096 A node can thus demux based on the combination of Source Locator 1097 and Source Identifier if necessary. If IP Security is in use, 1098 the combination of the Source Identifier and the SPI value would 1099 be sufficient to demux two different sessions. 1101 Finally, deployments in high threat environments also SHOULD use 1102 the IP Authentication Header to authenticate control traffic and 1103 data traffic. Because in the I/L-split mode, IP Security binds 1104 only to the Identifier values, and never to the Locator values, 1105 this enables a mobile or multi-homed node to use IPsec even when 1106 its Locator value(s) have just changed. 1108 13.3 IP Security Enhancements 1110 The IP Security standards are enhanced here by binding IPsec 1111 Security Associations to the Identifiers of the session 1112 endpoints, rather than binding IPsec Security Associations 1113 to the IP Addresses as at present. This change enhances the 1114 deployability and interoperability of the IP Security standards, 1115 but does not decrease the security provided by those protocols. 1117 Also, the IP Authentication Header omits the Source Locator and 1118 Destination Locator fields from its authentication calculations 1119 when ILNP is in use. This enables IP AH to work well even 1120 through a NAT or other situation where a Locator value might 1121 change during transit. 1123 13.4 DNS Security 1125 The DNS enhancements proposed here are entirely compatible with, 1126 and can be protected using, the existing IETF standards for DNS 1127 Security.[RFC 4033] The Secure DNS Dynamic Update mechanism used 1128 here is also used unchanged.[RFC 3007] So there is no change to 1129 the security properties of the Domain Name System or of DNS 1130 servers due to ILNP. 1132 13.5 Firewall Considerations 1134 In the proposed new scheme, firewalls are able to authenticate 1135 ICMP control messages arriving on the external interface. This 1136 enables more thoughtful handling of ICMP messages by firewalls 1137 than is commonly the case at present. As the firewall is along 1138 the path between the communicating nodes, the firewall can snoop 1139 on the Session Nonce being carried in the initial packets of an 1140 I/L Split mode session. The firewall can verify the correct 1141 nonce is present on incoming control packets, dropping any 1142 control packets that lack the correct nonce value. 1144 By always including the nonce, even when IP Security is also in 1145 use, the firewall can filter out off-path attacks. In any event, 1146 a forged packet from an on-path attacker will still be detected 1147 when the IPsec input processing occurs in the receiving node; 1148 this will cause that forged packet to be dropped rather than 1149 acted upon. 1151 13.6 Neighbor Discovery Authentication 1153 Nothing in this proposal prevents sites from using the Secure 1154 Neighbor Discovery (SEND) proposal for authenticating IPv6 1155 Neighbor Discovery. [RFC 3971] 1157 13.7 Site Topology Obfuscation 1159 A site that wishes to obscure its internal topology information 1160 MAY do so by deploying site border routers that rewrite the 1161 Locator values for the site as packets enter or leave the site. 1163 For example, a site might choose to use a ULA prefix internally 1164 for this reason.[RFC 4193] [ID-ULA] In this case, the site border 1165 routers would rewrite the Source Locator of ILNP packets leaving 1166 the site to a global-scope Locator associated with the site. 1167 Also, those site border routers would rewrite the Destination 1168 Locator of packets entering the site from the global-scope 1169 Locator to an appropriate interior ULA Locator for the 1170 destination node.[MILCOM08] 1172 13.8 Path Liveness 1174 Some perceive that an Identifier-Locator Split architecture 1175 creates a new issue that is sometimes called "Locator Liveness" 1176 or "Path Liveness". This refers to the question of whether an IP 1177 packet with a particular destination Locator value will be able 1178 to reach the intended destination or not, given that some 1179 otherwise valid paths might be unusable by the sending node 1180 (e.g. due to security policy or other administrative choice). 1181 In fact, this issue has existed in the IPv4 Internet for decades. 1183 For example, an IPv4 server might have multiple valid IP 1184 addresses, each advertised to the world via an DNS "A" record. 1185 However, at a given moment in time, it is possible that a given 1186 sending node might not be able to use a given (otherwise valid) 1187 destination IPv4 address in an IP packet to reach that IPv4 1188 server. 1190 So we see that using an Identifier/Locator Split architecture 1191 does not create this issue, nor does it make this issue worse 1192 than it is with the deployed IPv4 Internet. 1194 In ILNP, the same conceptual approach described in [RFC 5534] can 1195 be reused. Alternatively, an ILNP node can reuse the existing 1196 IPv4 methods for determining whether a given path to the target 1197 destination is currently usable, which existing methods leverage 1198 transport-layer session state information that the communicating 1199 end systems are already keeping for transport-layer protocol 1200 reasons. 1202 Last, it is important for the reader to understand that the 1203 mechanism described in [ILNP-ICMP] is a performance optimisation, 1204 significantly shortening the layer-3 handoff time if/when a 1205 correspondent changes location. Architecturally, using ICMP 1206 is no different from using UDP, of course. 1208 14. IANA CONSIDERATIONS 1210 This document has no IANA considerations. 1212 15. REFERENCES 1214 This section provides both normative and informative 1215 references relating to this note. 1217 15.1. Normative References 1219 [RFC 826] D. Plummer, "Ethernet Address Resolution Protocol: 1220 Or Converting Network Protocol Addresses to 1221 48 bit Ethernet Address for Transmission on 1222 Ethernet Hardware", RFC 826, November 1982. 1224 [RFC 2119] Bradner, S., "Key words for use in RFCs to 1225 Indicate Requirement Levels", BCP 14, RFC 2119, 1226 March 1997. 1228 [RFC 2460] S. Deering & R. Hinden, "Internet Protocol 1229 Version 6 Specification", RFC-2460, 1230 December 1998. 1232 [RFC 3007] B. Wellington, "Secure Domain Name System 1233 Dynamic Update", RFC-3007, November 2000. 1235 [RFC 4033] R. Arends, et alia, "DNS Security Introduction 1236 and Requirements", RFC-4033, March 2005. 1238 [RFC 4219] R. Hinden & S. Deering, "IP Version 6 1239 Addressing Architecture", RFC-4219, 1240 February 2006. 1242 [RFC 4861] T. Narten, E. Nordmark, W. Simpson, & H. Soliman, 1243 "Neighbor Discovery for IP version 6 (IPv6)", 1244 RFC 4861, September 2007. 1246 15.2. Informative References 1248 [8+8] M. O'Dell, "8+8 - An Alternate Addressing 1249 Architecture for IPv6", Internet-Draft, 1250 October 1996. 1252 [CA-1995-01] US CERT, "IP Spoofing Attacks and Hijacked 1253 Terminal Connections", CERT Advisory 1995-01, 1254 Issued 23 JAN 1995, Revised 23 SEP 1997. 1256 [GSE] M. O'Dell, "GSE - An Alternate Addressing 1257 Architecture for IPv6", Internet-Draft, 1258 February 1997. 1260 [ID-ULA] R. Hinden, G. Huston, & T. Narten, "Centrally 1261 Assigned Unique Local IPv6 Unicast Addresses", 1262 draft-ietf-ipv6-ula-central-02.txt, 15 June 2007. 1264 [ID-Referral] B. Carpenter and others, "A Generic Referral 1265 Object for Internet Entities", 1266 draft-carpenter-behave-referral-object-01, 1267 20 October 2009. 1269 [IEEE-EUI] IEEE Standards Association, "Guidelines for 1270 64-bit Global Identifier (EUI-64)", IEEE, 1271 2007. 1273 [IEN 1] C.J. Bennett, S.W. Edge, & A.J. Hinchley, 1274 "Issues in the Interconnection of Datagram 1275 Networks", Internet Experiment Note (IEN) 1, 1276 INDRA Note 637, PSPWN 76, University College 1277 London, London, England, UK, WC1E 6BT, 1278 29 July 1977. 1279 http://www.postel.org/ien/ien001.pdf 1281 [IEN 19] J. F. Shoch, "Inter-Network Naming, Addressing, 1282 and Routing", IEN-19, January 1978. 1284 [IEN 23] J. F. Shoch, "On Names, Addresses, and 1285 Routings", IEN-23, January 1978. 1287 [IEN 31] D. Cohen, "On Names, Addresses, and Routings 1288 (II)", IEN-31, April 1978. 1290 [ILNP-Nonce] R. Atkinson, "Nonce Destination Option", 1291 draft-rja-ilnp-nonce-03.txt, June 2010. 1293 [ILNP-DNS] R. Atkinson, "DNS Resource Records for ILNP", 1294 draft-rja-ilnp-dns-04.txt, June 2010. 1296 [ILNP-ICMP] R. Atkinson, "ICMP Locator Update message" 1297 draft-rja-ilnp-icmp-02.txt, June 2010. 1299 [IPng95] D. Clark, "A thought on addressing", 1300 electronic mail message to IETF IPng WG, 1301 Message-ID: 9501111901.AA28426@caraway.lcs.mit.edu, 1302 Laboratory for Computer Science, MIT, 1303 Cambridge, MA, USA, 11 January 1995. 1305 [Liu-DNS] C. Liu & P. Albitz, "DNS & Bind", 5th Edition, 1306 O'Reilly & Associates, Sebastopol, CA, USA, 1307 May 2006. ISBN 0-596-10057-4 1309 [MobiArch07] R. Atkinson, S. Bhatti, & S. Hailes, 1310 "Mobility as an Integrated Service Through 1311 the Use of Naming", Proceedings of 1312 ACM MobiArch 2007, August 2007, 1313 Kyoto, Japan. 1315 [MobiArch08] R. Atkinson, S. Bhatti, & S. Hailes, 1316 "Mobility Through Naming: Impact on DNS", 1317 Proceedings of ACM MobiArch 2008, August 2008, 1318 Seattle, WA, USA. 1320 [MobiWAC07] R. Atkinson, S. Bhatti, & S. Hailes, 1321 "A Proposal for Unifying Mobility with 1322 Multi-Homing, NAT, & Security", 1323 Proceedings of ACM MobiWAC 2007, Chania, 1324 Crete. ACM, October 2007. 1326 [MILCOM08] R. Atkinson, S. Bhatti, & S. Hailes, 1327 "Harmonised Resilience, Security, and Mobility 1328 Capability for IP", Proceedings of IEEE 1329 Military Communications (MILCOM) Conference, 1330 San Diego, CA, USA, November 2008. 1332 [MILCOM09] R. Atkinson, S. Bhatti, & S. Hailes, 1333 "Site-Controlled Secure Multi-Homing and 1334 Traffic Engineering For IP", Proceedings of 1335 IEEE Military Communications (MILCOM) Conference, 1336 Boston, MA, USA, October 2009. 1338 [PHG02] Pappas, A, S. Hailes, & R. Giaffreda, 1339 "Mobile Host Location Tracking through DNS", 1340 Proceedings of IEEE London Communications 1341 Symposium, IEEE, September 2002, London, 1342 England, UK. 1344 [SBK2002] Alex C. Snoeren, Hari Balakrishnan, & M. Frans 1345 Kaashoek, "Reconsidering Internet Mobility", 1346 Proceedings of 8th Workshop on Hot Topics in 1347 Operating Systems, 2002. 1349 [SIPP94] Bob Smart, "Re: IPng Directorate meeting in 1350 Chicago; possible SIPP changes", electronic 1351 mail to the IETF SIPP WG mailing list, 1352 Message-ID: 1353 199406020647.AA09887@shark.mel.dit.csiro.au, 1354 Commonwealth Scientific & Industrial Research 1355 Organisation (CSIRO), Melbourne, VIC, 3001, 1356 Australia, 2 June 1994. 1358 [RFC 814] D.D. Clark, "Names, Addresses, Ports, and 1359 Routes", RFC-814, July 1982. 1361 [RFC 1498] J.H. Saltzer, "On the Naming and Binding of 1362 Network Destinations", RFC-1498, August 1993. 1364 [RFC 1631] K. Egevang & P. Francis, "The IP Network 1365 Address Translator (NAT)", RFC-1631, May 1994. 1367 [RFC 2827] P. Ferguson & D. Senie, "Network Ingress Filtering: 1368 Defeating Denial of Service Attacks which employ 1369 IP Source Address Spoofing", RFC-2827, May 2000. 1371 [RFC 3022] P. Srisuresh & K. Egevang, "Traditional IP 1372 Network Address Translator", RFC-3022, 1373 January 2001. 1375 [RFC 3027] M. Holdrege and P Srisuresh, "Protocol 1376 Complications of the IP Network Address 1377 Translator", RFC-3027, January 2001. 1379 [RFC 3704] F. Baker & P. Savola, "Ingress Filtering for 1380 Multihomed Networks, RFC-3704, March 2004. 1382 [RFC 3715] B. Aboba and W. Dixon, "IPsec-Network Address 1383 Translation (NAT) Compatibility Requirements", 1384 RFC-3715, March 2004. 1386 [RFC 3775] D. Johnson, C. Perkins, and J. Arkko, "Mobility 1387 Support in IPv6", RFC-3775, June 2004. 1389 [RFC 3948] A. Huttunen, et alia, "UDP Encapsulation of 1390 IPsec ESP Packets", RFC-3948, January 2005. 1392 [RFC 3971] J. Arkko, J. Kempf, B. Zill, & P. Nikander, 1393 "SEcure Neighbor Discovery (SEND)", RFC-3971 1394 March 2005. 1396 [RFC 3972] T. Aura, "Cryptographically Generated Addresses 1397 (CGAs)", RFC-3972, March 2005. 1399 [RFC 4193] R. Hinden & B. Haberman, "Unique Local IPv6 1400 Unicast Addresses, RFC-4193, October 2005. 1402 [RFC 4941] T. Narten, R. Draves, & S. Krishnan, "Privacy 1403 Extensions for Stateless Address Autoconfiguration 1404 in IPv6", RFC-4941, September 2007. 1406 [RFC 5061] R. Stewart, Q. Xie, M. Tuexen, S. Maruyama, & 1407 M. Kozuka, "Stream Control Transmission Protocol 1408 (SCTP) Dynamic Address Reconfiguration", RFC-5061, 1409 September 2007. 1411 [RFC 5534] J. Arkko & I. van Beijnum, "Failure Detection and 1412 Locator Pair Exploration Protocol for IPv6 1413 Multihoming", RFC-5534, June 2009. 1415 [TeleSys] R. Atkinson, S. Bhatti, & S. Hailes, 1416 "ILNP: Mobility, Multi-Homing, Localised Addressing 1417 and Security Through Naming", Telecommunications 1418 Systems, Volume 42, Number 3-4, pp 273-291, 1419 Springer-Verlag, December 2009, ISSN 1018-4864. 1421 ACKNOWLEDGEMENTS 1423 Steve Blake, Mohamed Boucadair, Saleem Bhatti, Noel Chiappa, 1424 Steve Hailes, Joel Halpern, Mark Handley, Tony Li, and Yakov 1425 Rehkter (in alphabetical order) provided review and feedback on 1426 earlier versions of this document. Noel Chiappa graciously 1427 provided the author with copies of the original email messages 1428 cited here as [SIPP94] and [IPng95], which enabled the precise 1429 citation of those messages herein. 1431 AUTHOR'S ADDRESS 1432 R. Atkinson 1433 Consultant 1434 McLean, VA 1435 22102 USA 1437 Email: rja.lists@gmail.com 1439 Expires: 24 DEC 2010