idnits 2.17.1 draft-rja-ilnp-intro-03.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 (8 February 2010) is 5192 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-02 == Outdated reference: A later version (-11) exists of draft-rja-ilnp-dns-02 == Outdated reference: A later version (-11) exists of draft-rja-ilnp-icmp-01 -- 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-03.txt 4 Expires: 08 AUG 2010 8 February 2010 5 Category: Experimental 7 ILNP Concept of Operations 8 draft-rja-ilnp-intro-03.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 Abstract 61 This documents the Concept of Operations for an experimental 62 extension to IPv6 which is known as the Identifier Locator 63 Network Protocol (ILNP). 65 Table of Contents 67 1. Introduction ...............................................2 68 2. Transport Protocols.........................................5 69 3. Mobility....................................................6 70 4. Multi-Homing................................................8 71 5. Localised Addressing.......................................10 72 6. IP Security Enhancements...................................11 73 7. DNS Enhancements...........................................12 74 8. Referrals & Application Programming Interfaces.............13 75 9. Backwards Compatibility....................................14 76 10. Incremental Deployment.....................................15 77 11. Implementation Considerations..............................17 78 12. Security Considerations ...................................18 79 13. IANA Considerations .......................................22 80 14. References ................................................22 82 1. INTRODUCTION 84 At present, the research and development community are exploring 85 various approaches to evolving the Internet Architecture. 86 Several different classes of evolution are being considered. One 87 class is often called "Map and Encapsulate", where traffic would 88 be mapped and then tunnelled through the inter-domain core of the 89 Internet. Another class being considered is sometimes known as 90 "Identifier/Locator Split". This document relates to a proposal 91 that is in the latter class of evoluationary approaches. 93 There has been substantial research relating to naming in the 94 Internet through the years. [IEN 1] [IEN 19] [IEN 23] [IEN 31] 95 [RFC 814] [RFC 1498] More recently, and mindful of that important 96 prior work, the author has been examining enhancements to certain 97 naming aspects of the Internet Architecture. [MobiArch07] 99 [MobiWAC07] [MobiArch08] [MILCOM08] [MILCOM09] [TeleSys] 101 The architectural concept behind ILNP derives originally from a 102 note by Dave Clark to the IETF mailing list suggesting that the 103 IPv6 address be split into separate Identifier and Locator 104 fields. 106 Afterwards, Mike O'Dell persued this concept in Internet-Drafts 107 describing "8+8" or "GSE".[8+8] [GSE] More recently, the IRTF 108 Namespace Research Group (NSRG) studied this matter. Unusually 109 for an IRTF RG, the NSRG operated on the principle that unanimity 110 was required for the NSRG to make a recommendation. The author 111 was a member of the IRTF NSRG. At least one other proposal, the 112 Host Identity Protocol (HIP), also derives in part from the IRTF 113 NSRG studies (and related antecedant work). This current 114 proposal differs from O'Dell's work in various ways. 116 ILNP is an architecture, and can have more than one 117 instantiation. The term ILNPv4 refers precisely to an instance 118 of ILNP that is based upon and backwards compatible with IPv4. 119 The term ILNPv6 refers precisely to an instance of ILNP that is 120 based upon and backwards compatible with IPv6. For the remainder 121 of this document, we simply write the less precise term ILNP, 122 although ILNPv6 is the focus of this document. 124 The crux of this proposal is to have different names for the 125 identity of a node and the location of a node, with crisp 126 semantics for each. ILNPv6 splits the IPv6 address into two 127 separate names: a 64-bit Locator and a 64-bit Identifier. It is 128 worth remembering here that an IPv6 address names a specific 129 interface on a node, since with ILNP the Identifier names a node, 130 not a specific interface on a node. 132 1 1 2 3 133 0 4 8 2 6 4 1 134 +---------------+-----------------+----------------+---------------+ 135 | Version| Traffic Class | Flow Label | 136 +---------------+-----------------+----------------+---------------+ 137 | Payload Length | Next Header | Hop Limit | 138 +---------------+-----------------+--------------------------------+ 139 | Source Address | 140 + + 141 | | 142 + + 143 | | 144 + + 145 | | 146 +---------------+-----------------+----------------+---------------+ 147 | Destination Address | 148 + + 149 | | 150 + + 151 | | 152 + + 153 | | 154 +---------------+-----------------+----------------+---------------+ 156 Figure 1: Existing ("Classic") IPv6 Header 158 The high-order 64-bits of the IPv6 address become the Locator. 159 The Locator indicates the subnetwork point of attachment for 160 a node. In essence, the Locator names a subnetwork. Locators 161 are also known as Routing Prefixes. 163 The low-order 64-bits of the IPv6 address become the Identifier. 164 The Identifier provides a fixed-length identity for a node, 165 rather than an identity for a specific interface of a node. 166 Identifiers are bound to nodes, not to interfaces, and are 167 in the same modified EUI-64 syntax already specified for 168 IPv6.[RFC 2460][RFC 4219][IEEE-EUI] 170 Identifiers can be either globally unique or locally unique. 171 Locally unique Identifiers are unique within the context of their 172 associated Locators. Either globally unique or locally unique 173 Identifiers can be used with this protocol. However, locally 174 unique Identifiers MUST NOT be used with other Locators without 175 first ensuring uniqueness (e.g. by using IPv6 Neighbor 176 Discovery's Duplicate Addess Detection (DAD) mechanism). 178 1 1 2 3 179 0 4 8 2 6 4 1 180 +---------------+-----------------+----------------+---------------+ 181 | Version| Traffic Class | Flow Label | 182 +---------------+-----------------+----------------+---------------+ 183 | Payload Length | Next Header | Hop Limit | 184 +---------------+-----------------+----------------+---------------+ 185 | Source Locator | 186 + + 187 | | 188 +---------------+-----------------+----------------+---------------+ 189 | Source Identifier | 190 + + 191 | | 192 +---------------+-----------------+----------------+---------------+ 193 | Destination Locator | 194 + + 195 | | 196 +---------------+-----------------+----------------+---------------+ 197 | Destination Identifier | 198 + + 199 | | 200 +---------------+-----------------+----------------+---------------+ 202 Figure 2: Enhanced IPv6 Header 204 Most commonly, a node's set of Identifiers are derived from the 205 IEEE 802 or IEEE 1394 MAC addresses associated with that node. 206 This use of MAC addresses to generate Identifiers is convenient 207 and is not required. Other methods also might be used to 208 generate Identifiers. For example, one might derive Identifiers 209 using cryptographic-generation or using methods specified in the 210 IPv6 Privacy Extensions to State-Less Address Auto-Configuration 211 (SLAAC). [RFC 3972, RFC 4941] 213 This proposal enhances the Internet Architecture by adding crisp 214 and clear semantics for the Identifier and for the Locator, 215 removing the semantically-muddled concept of the IP address, and 216 updating end system protocols slightly, without requiring router 217 changes. 219 With these naming enhancements, we have improved the architecture 220 by adding explicit support not only for multi-homing, but also 221 for mobility, localised addressing (e.g. NAT/NAPT), and IP 222 Security. 224 1.1 Terminology 226 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 227 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 228 "OPTIONAL" in this document are to be interpreted as described 229 in RFC 2119. [RFC 2119] 231 2. TRANSPORT PROTOCOLS 233 At present, commonly deployed transport protocols include a 234 pseudo-header checksum that includes certain network-layer 235 fields, the IP addresses used for the session, in its 236 calculation. This inclusion of network-layer information 237 within the transport-layer session state creates issues for 238 multi-homing, mobility, IP Security, and localised addressing 239 (e.g. using Network Address Translation). [RFC 1631][RFC 3022] 240 This unfortunate aspect of the TCP pseudo-header checksum 241 has been understood to be an architectural problem at least 242 since 1977, well before the transition from NCP to 243 IPv4.[IEN 1][IEN 19][IEN 23][IEN 31][RFC 1498] 245 With this proposal, transport protocols include only the 246 Identifier in their pseudo-header calculations, but do not 247 include the Locator in their pseudo-header calculations. 249 To minimise the changes required within transport protocol 250 implementations, when this proposal is in use for a 251 communications session, the Locator fields are zeroed for 252 the purpose of transport-layer pseudo-header calculations. 254 Later in this document, methods for incremental deployment 255 of this change and backwards compatibility with non-upgraded 256 nodes are described. 258 3. MOBILITY 260 First, please recall that mobiity and multi-homing actually 261 present the same set of issues. In each case, the set of 262 Locators associated with a node or site changes. The reason 263 for the change might be different, but the effects on the 264 network and on correspondents is identical. 266 There are no standardised mechanisms to update most transport 267 protocols with new IP addresses in use for the session. 268 Exceptionally, the Stream Control Transport Protocol (SCTP) 269 recently added this capability.[RFC 5061] In July 2008, Mark 270 Handley at UCL proposed adding such a capability to TCP during 271 a presentation at the IRTF Routing RG in Dublin, Ireland. 272 His Multi-Path TCP concept is being considered in the IETF 273 as of this writing. 275 This creates various issues for mobility. For example, there 276 is no method at present to update the IP addresses associated 277 with a transport layer session when one of the nodes in that 278 session moves (i.e. changes one of its points of network 279 attachment). 281 So, the several approaches to IP mobility seek to hide the 282 change in location (and corresponding change in IP addresses) 283 via tunnelling, home agents, foreign agents, and so forth. 284 [RFC 3775] All of this can add substantial complexity to IP 285 mobility approaches, both in the initial deployment and also 286 in ongoing operation. 288 By contrast, this ILNP proposal hides each node's location 289 information from the transport layer protocols at all times, 290 by removing location information from the transport session 291 state (e.g. pseudo-header checksum calculations). 293 In this proposal, mobility and multi-homing are supported using 294 a common set of mechanisms. In both cases, different Locator 295 values are used to identify different IP subnetworks. 297 To handle the move of a node, we add a new ICMP control message. 298 The ICMP Locator Update message is used by a node to inform its 299 existing correspondents that the set of valid Locators for the 300 node has changed. This mechanism can be used to add newly valid 301 Locators, to remove no longer valid Locators, or to do both at 302 the same time. Further, the node uses Secure Dynamic DNS Update 303 to correct the set of L64 records in the DNS for that node. 304 [RFC 3007] This enables any new correspondents to correctly 305 initiate a new session with the node at its new location. 307 This use of DNS for initial rendezvous with mobile node was 308 independently proposed by others [PHG02] and then separately 309 re-invented by the current author later on. 311 (The Locator Update control message could be an entirely new 312 protocol running over UDP, for example, but there is no obvious 313 advantage to creating a new protocol rather than using a new 314 ICMP message.) 316 With ILNP, network mobility (as well as node mobility) 317 is considered a special case of multihoming. That is, 318 when a network moves, it uses a new Locator value for all 319 of its communications sessions. So, the same mechanism, 320 using a new or additional Locator value, also supports 321 network mobility. 323 So in ILNP, when a connectivity change affects the set of 324 valid Locators, the affected node(s) actively: 326 (1) use the ICMP Locator Update message to inform their 327 existing correspondents with the updated information 328 about their currently valid Locator(s). [ILNP-ICMP] 330 AND also 332 (2) update their DNS entries, most commonly by using 333 the Secure Dynamic DNS Update mechanism. [RFC 3007] 335 In the unlikely event of simultaneous motion which changes 336 both nodes' Locators within a very small time period, a 337 node can use the DNS to discover the new Locator value(s) 338 for the other node. 340 As a DNS performance optimisation, the "LP" DNS resource record 341 MAY be used to avoid requiring each node on a subnetwork to 342 update its DNS L64 record entries when that subnetwork's location 343 (e.g. upstream connectivity) changes. In this case, the nodes on 344 the subnetwork each would have an "LP" record pointing to a 345 common domain-name used to name that subnetwork. In turn, that 346 subnetwork's domain name would have one or more L64 record(s) in 347 the DNS. 349 Correspondents of a node on that subnetwork would perform a "L64" 350 record query for that target node (or an "ID" query for that 351 target node) and receive the "LP" records as additional data in 352 the DNS reply. Then the correspondent would perform an L64 353 record lookup on the domain-name pointed to by that LP record, 354 in order to learn the Locator value to use to reach that 355 target node. 357 For bi-directional flows, such as a TCP session, each node knows 358 whether the current path in use is working by the receiption of 359 data packets, acknowledgements, or both. As with TCP/IP, 360 TCP/ILNP does not need special path probes. UDP/ILNP sessions 361 with acknowledgements work similarly, and also don't need special 362 path probes. 364 In the deployed Internet, the sending node for a UDP/IP session 365 without acknowledgements does not know for certain that all 366 packets are received by the intended receiving node. Such 367 UDP/ILNP sessions fare no worse than UDP/IP sessions. The 368 receiver(s) of such a UDP session SHOULD send a gratuitous IP 369 packet containing an ILNP Nonce option to the sender, in order to 370 enable the receiver to subsequently send ICMP Locator Updates if 371 appropriate. In this last case, UDP/ILNP sessions fare better 372 than UDP/IP sessions, still without using network path probes. 374 One might wonder what happens if a mobile node is moving more 375 quickly than DNS can be updated. This situation is unlikely, 376 particularly given the widespread use of link-layer mobility 377 mechanisms (e.g. GSM, IEEE 802 bridging) in combination with 378 network-layer mobility. However, the situation is functionally 379 equivalent to the situation where a traditional IP node is moving 380 nfaster than the Mobile IPv4 or Mobile IPv6 agents/servers can be 381 updated with the mobile node's new location. So the issue is not 382 new in any way. In all cases, Mobile IPv4 and Mobile IPv6 and 383 ILNP, a node moving that quickly might be temporarily unreachable 384 until it remains at a given network-layer location (e.g. IP 385 subnetwork) long enough for the location update mechanisms (for 386 Mobile IPv4, for Mobile IPv6, or ILNP) to catch up. ILNP is 387 prospectively better than either form of Mobile IP with respect 388 to key management, given that ILNP is using Secure Dynamic DNS 389 Update and given that neither form of Mobile IP has a 390 standardised and scalable key management mechanism at present. 392 4. MULTI-HOMING 394 Conceptually, there are two kinds of multi-homing. Site 395 multi-homing is when all nodes at a site are multi-homed 396 at the same time. This is what most people mean when they 397 talk about multi-homing. However, there is also a separate 398 concept of node multi-homing, where only a single node is 399 multi-homed. 401 At present, site multi-homing is common in the deployed Internet. 402 This is primarily achieved by advertising the site's routing 403 prefix(es) to more than upstream Internet service provider at a 404 given time. In turn, this requires de-aggregation of routing 405 prefixes within the inter-domain routing system. In turn, this 406 increases the entropy of the inter-domain routing system (e.g. 407 RIB/FIB size increases beyond the minimal RIB/FIB size that 408 would be required to reach all sites). 410 At present, node multi-homing is not common in the deployed 411 Internet. When TCP or UDP are in use for an IP session, node 412 multi-homing cannot provide session resilience, because the 413 transport pseudo-header checksum binds the session to a single 414 interface of the multi-homed node. SCTP has a protocol-specific 415 mechanism to support node multi-homing; SCTP can support session 416 resilience both at present and also without change in the 417 proposed approach. [RFC 5061] 419 In the new scheme, when a node is multi-homed, it has more than 420 one valid Locator value. When one upstream connection fails, 421 the node sends an ICMP Locator Update message to each existing 422 correspondent node to remove the no-longer-valid Locator from 423 the set of valid Locators. [ILNP-ICMP] Also, the node can use 424 Secure Dynamic DNS Update to alter the set of currently valid 425 L64 records associated with that node. [RFC 3007] This second 426 step ensures that any new correspondents can reach the node. 428 In the new scheme, site multi-homing works in a similar manner, 429 with nodes having one Locator for each upstream connection to 430 the Internet. To avoid a DNS Update burst when a site or 431 subnetwork moves location, a DNS record optimisation is 432 possible. This would change the number of DNS Updates required 433 from Order(number of nodes at the site/subnetwork that moved) 434 to Order(1). [ILNP-DNS] 436 Additionally, since the transport-protocol session state no 437 longer includes the Locators, a site could choose to perform 438 Locator rewriting at its site border routers, possibly in 439 combination with applying site traffic engineering policy on 440 which upstream link to use for which packets. Since the site 441 border router(s) are in the middle of any exterior packet flow, 442 they also can send proxy Locator Update messages on behalf of 443 nodes inside that site, and can even include the appropriate 444 Nonce value in such proxy Locator Updates, if desired by that 445 site's administration. 447 5. LOCALISED ADDRESSING 449 As the Locator value no longer forms part of the node session 450 state (e.g. TCP pseudo-header), it is easier to support 451 localised addressing, which is sometimes also called "Private 452 Addressing", based on the use of local values of the Locator. 453 This would be either in place of, or to supplement, existing 454 NAT-based schemes. [RFC 1631] [RFC 3022] 456 For example, a site that desires to use private addresses 457 internally might deploy IPv6 Unique Local Addressing 458 (ULA) for localised addressing, along with some form of ILNP/ 459 IPv6 Network Address Translation at a site border gateway. 460 [ID-ULA] [RFC 4193] This example is described in detail 461 in [MILCOM09], both as a mechanism for site multi-homing 462 and also as a mechanism to support site-controlled traffic 463 engineering. 465 In the simplest case, an ILNP capable NAT only would need to 466 change the value of the Source Locator in an outbound packet, 467 and the value of the Destination Locator for an inbound packet. 468 Identifier values would not need to change, so a true end-to-end 469 session could be maintained. 471 If a site using localised addressing chooses to deploy a 472 split-horizon DNS server, then the DNS server would advertise 473 the global-scope Locator(s) of the site border routers outside 474 the site to DNS clients outside the site, and would advertise 475 the local-scope Locator(s) specific to that internal node to 476 DNS clients inside the site. Such deployments of split-horizon 477 DNS servers are not unusual in the IPv4 Internet today. If an 478 internal node (e.g. portable computer) moves outside the site, 479 it would follow the normal ILNP methods to update its 480 authoritative DNS server with its current Locator set. In this 481 deployment model, the authoritative DNS server for that mobile 482 device will be either the split-horizon DNS server itself or the 483 master DNS server providing data to the split-horizon DNS server. 485 If a site using localised addressing chooses not to deploy a 486 split-horizon DNS server, then all internal nodes would 487 advertise the global-scope Locator(s) of the site border routers. 488 To deliver packets from one internal node to another internal 489 node, the site would either choose to use layer-2 bridging 490 (e.g. IEEE Spanning Tree, IEEE Rapid Spanning Tree, or a 491 link-state layer-2 algorithm such as the IETF TRILL group or 492 IEEE 802.1 are developing), or the interior routers would 493 forward packets up to the nearest site border router, 494 which in turn would then rewrite the Locators to appropriate 495 local-scope values, and forward the packet towards the interior 496 destination node. 498 We note that a deployment using private/local addressing can 499 also provide site multi-homing by deploying site border 500 routers in this manner. 502 Please note that with this proposal, localised addressing 503 (e.g. using Network Address Translation on the Locator bits) 504 would work in harmony with multihoming, mobility, and IP 505 Security.[MobiWAC07][MILCOM08][MILCOM09] 507 6. IP SECURITY ENHANCEMENTS 509 A current issue is that the IP Security protocols, AH and ESP, 510 have Security Associations that include the IP addresses of 511 the secure session endpoints. This was understood to be a 512 problem when AH and ESP were originally defined, however the 513 limited set of namespaces in the Internet Architecture did not 514 provide any better choices at that time. 516 Operationally, this binding causes problems for the use of the 517 IPsec protocols through Network Address Translation devices, 518 with mobile nodes (because the mobile node's IP address changes 519 at each network-layer handoff), and with multi-homed nodes 520 (because the session is bound to a particular interface of the 521 multi-homed node, rather than being bound to the node 522 itself).[RFC 3027][RFC 3715] 524 To resolve the issue of IPsec interoperability through a 525 NAT deployment, UDP encapsulation of IPsec is commonly 526 used today.[RFC 3948] 527 With this proposal, the IP Security protocols, AH and ESP, 528 are enhanced to bind Security Associations only to 529 Identifier values and never to Locator values (and also 530 not to an entire 128-bit IPv6 address). 532 Similarly, key management protocols used with IPsec would be 533 enhanced to deprecate use of IP addresses as identifiers and 534 to substitute the use of the new Identifier for that 535 purpose. 537 This small change enables IPsec to work in harmony with 538 multihoming, mobility, and localised addressing. [MILCOM08] 539 [MILCOM09] Further, it would obviate the need for specialised 540 IPsec NAT Traversal mechanisms, thus simplifying IPsec 541 implementations while enhancing deployability and 542 interoperability. [RFC 3948] 544 This change does not reduce the security provided by the 545 IP Security protocols. 547 7. DNS ENHANCEMENTS 549 As part of this proposal, additional DNS Resource Records have 550 been proposed in a separate document. [ILNP-DNS] These new 551 records store the Identifier and Locator values for nodes that 552 have been upgraded to support the Identifier-Locator Split Mode. 554 With this proposal, mobile or multi-homed nodes and sites are 555 expected to use the existing "Secure Dynamic DNS Update" protocol 556 to keep their Identifier and Locator records correct in its 557 authoritative DNS server(s). [RFC 3007] 559 While some might be surprised, Secure Dynamic DNS Update is 560 available now in a very wide range of existing deployed systems. 561 For example, Microsoft Windows XP (and later versions), the 562 freely distributable BIND DNS software package (used in Apple 563 MacOS X and in most UNIX systems), and the commercial Nominum DNS 564 server all implement support for Secure Dynamic DNS Update and 565 are known to interoperate. [Liu-DNS] There are credible reports 566 that when a site deploys Microsoft's Active Directory, the site 567 (silently) automatically deploys Secure Dynamic DNS 568 Update. [Liu-DNS] So it appears that many sites have already 569 deployed Secure Dynamic DNS Update even though they might not be 570 aware they have already deployed that protocol. [Liu-DNS] 572 Reverse DNS lookups, to find a node's Fully Qualified Domain Name 573 from the combination of a Locator and related Identifier value, 574 can be performed as at present. 576 Previous research by others indicates that DNS caching is largely 577 ineffective, with the exception of NS records and the addresses 578 of DNS servers referred to by NS records.[SBK2002] This means DNS 579 caching performance will not be adversely affected by assigning 580 very short time-to-live (TTL) values to the Locator records of 581 typical nodes. It also means that it is preferable to deploy the 582 DNS server function on nodes that have longer TTL values, rather 583 than on nodes that have shorter TTL values. 585 Identifier values might be very long-lived (e.g. days) when they 586 have been generated from an IEEE MAC Address on the system. 587 Identifier values might have a shorter lifetime (e.g. hours) if 588 they have been cryptographically-generated [RFC 3972], or have 589 been created by the IPv6 Privacy Extensions [RFC 4941], or 590 otherwise have the EUI-64 scope bit at the "local-scope" value. 591 Note that a given ILNP session normally will use a single 592 Identifier value for the life of that session. 594 Existing DNS specifications require that DNS clients and DNS 595 resolvers obey the TTL values provided by the DNS servers. In 596 the context of this proposal, short DNS TTL values are assigned 597 to particular DNS records to ensure that the ubiquitous DNS 598 caching resolvers do not cache volatile values (e.g. Locator 599 records of a mobile node) and consequently return stale 600 information to new requestors. 602 As a practical matter, it is not sensible to flush all Locator 603 values associated with an existing session's remote node from 604 the local node's I/L Session Cache. Instead, Locator values 605 SHOULD be marked as "aged" when their TTL has expired until 606 either the next Locator Update message is received or there 607 is other indication that a given Locator is not working any 608 longer. 610 During a long transition period, a node that is I/L-enabled 611 SHOULD have not only ID and L64 (or ID and LP) records present in 612 its authoritative DNS server, but also SHOULD have AAAA records 613 in the DNS for the benefit of non-upgraded nodes. This 614 capability might be implemented strictly inside a DNS server, 615 whereby the DNS server synthesised a set of AAAA records to 616 advertise from the ID and L64 values that the node has kept 617 updated in that DNS server. 619 Existing DNS specifications require that a DNS resolver or DNS 620 client ignore unrecognised DNS record types. So gratuitously 621 appending ID and L64 records as "additional data" in DNS 622 responses to AAAA queries should not create any operational 623 issues. 625 8. REFERRALS & APPLICATION PROGRAMMING INTERFACES 627 This section is concerned with support for using 628 existing ("legacy") applications over ILNP, including 629 both referrals and APIs. 631 8.1 BSD Sockets APIs 633 The existing BSD Sockets API can continue to be used with 634 ILNP underneath the API. That API can be implemented in a 635 manner that hides the underlying protocol changes from the 636 applications. For example, the combination of a Locator 637 and an Identifier can be used with the API in the place 638 of an IPv6 address. 640 So it is believed that existing IP address referrals can 641 continue to work properly in most cases. For a rapidly 642 moving target node, referrals might break in at least some 643 cases. The potential for referral breakage is necessarily 644 dependent upon the specific application and implementation 645 being considered. 647 It is suggested, however, that a new, optional, more abstract, 648 C language API be created so that new applications may avoid 649 delving into low-level details of the underlying network 650 protocols. Such an API would be useful today, even with 651 the existing IPv4 and IPv6 Internet, whether or not ILNP 652 were ever widely deployed. 654 8.2 Java APIs 656 Most existing Java APIs already use abstracted network 657 programming interfaces, for example in the java.Net.URL class. 658 Because these APIs already hide the low-level network-protocol 659 details from the applications, the applications using these APIs 660 (and the APIs themselves) don't need any modification to work 661 equally well with IPv4, IPv6, ILNP, and probably also HIP. 663 8.3 Referrals in the Future 665 The approach proposed in [ID-Referral] appears to be very 666 suitable for use with ILNP, in addition to being suitable 667 for use with the deployed Internet. Protocols using that 668 approach would not need modification to have their referrals 669 work well with IPv4, IPv6, ILNP, and probably also other 670 network protocols (e.g. HIP). 672 A more sensible approach to referrals would be to use 673 Fully-Qualified Domain Names (FQDNs), as is commonly done 674 today with web URLs. This is approach is highly portable 675 across different network protocols, even with both the IPv4 676 Internet or the IPv6 Internet. 678 9. BACKWARDS COMPATIBILITY 680 First, if one comapres Figure 1 and Figure 2, one can see 681 that IPv6 with the Identifier/Locator Split enhancement is 682 fully backwards compatible with existing IPv6. This means 683 that no router software or silicon changes are necessary to 684 support the proposed enhancements. A router would be 685 unaware whether the packet being forwarded were classic IPv6 686 or the proposed enhanced version of IPv6. So no changes to 687 IPv6 routers is required to deploy this proposal. 689 Further, IPv6 Neighbour Discovery should work fine as is. 691 If a node that has been enhanced to support the Identifier/ 692 Locator Split mode initiates an IP session with another node, 693 normally it will first perform a DNS lookup on the responding 694 node's DNS name. If the inititator node does not find any ID 695 or L64 DNS resource records for the responder node, then the 696 initiator uses the Classical IPv6 mode of operation for the 697 new session with the responder, rather than trying to use 698 the I/L Split mode for that session. 700 If the responder node for a new IP session has not been enhanced 701 to support the I/L Split mode and receives initial packet(s) 702 containing the Nonce Destination Option, the responder will drop 703 the packet and send an ICMP Parameter Problem error message back 704 to the initiator. 706 If the initiator node does not receive a response from the 707 responder in a timely manner (e.g. within TCP timeout for a TCP 708 session) and also does not receive an ICMP Unreachable error 709 message for that packet, OR if the initiator receives an ICMP 710 Parameter Problem error message for that packet, then the 711 initiator knows that the responder is not able to support the I/L 712 Split Operating mode. In this case, the initiator node SHOULD 713 try again to create the new IP session but this time OMITTING the 714 Nonce Destination Option, and this time operating in Classic IPv6 715 mode, rather than I/L Split mode. 717 Finally, since an ILNP node is also a fully-capable IPv6 node, 718 then the upgraded node can use any standardised IPv6 mechanisms 719 for communicating with a legacy IPv6 node (i.e. an IPv6 node 720 without ILNP capability enhancements). So ILNP will in no case 721 be worse than existing IPv6, and in many cases ILNP will out 722 perform existing IPv6. 724 10. INCREMENTAL DEPLOYMENT 726 If a node has been enhanced to support the Identifier/ Locator 727 Split operating mode, that node's fully-qualified domain name 728 will normally have one or more ID records and one or more L64 729 records associated with it in the DNS. 731 When a host ("initiator") initiates a new IP session with a 732 correspondent ("responder"), it normally will perform a DNS 733 lookup to determine the address(es) of the responder. A host 734 that has been enhanced to support the Identifier/ Locator Split 735 operating mode normally will look for Identifier ("ID") and 736 Locator ("L64") records in any received DNS replies. DNS servers 737 that support ID and L64 records SHOULD include them (when they 738 exist) as additional data in all DNS replies to queries for 739 DNS AAAA records.[ILNP-DNS] 741 If the initiator supports the I/L Split mode and from DNS 742 information learns that the responder also supports the I/L Split 743 mode, then the initiator will generate an unpredictable nonce 744 value, store that value in a local Correspondent Cache, and will 745 include the Nonce Destination Option in its initial packet(s) 746 to the responder.[ILNP-Nonce] 748 If the responder supports the I/L Split mode and receives 749 initial packet(s) containing the Nonce Destination Option, 750 the responder will thereby know that the initiator supports 751 the I/L Split mode and the responder will also operate in 752 I/L Split mode for this new IP session. 754 If the responder supports the I/L Split mode and receives 755 initial packet(s) NOT containing the Nonce Destination Option, 756 the responder will thereby know that the initiator does NOT 757 support the I/L Split mode and the responder will operate 758 in classic IPv6 mode for this new IP session. 760 The previous section described how interoperability between 761 enhanced nodes and non-enhanced nodes is retained even if a 762 non-enhanced node erroneously has ID and/or L64 DNS resource 763 records in place (e.g. due to some accident). 765 The mobility capabilities of ILNP might be the most important in 766 the deployment world. Despite substantial good efforts by many, 767 neither Mobile IPv4 nor Mobile IPv6 are widely used at present. 768 However, much of the recent work in operating systems has focused 769 on support for mobile devices (e.g. mobile telephone handsets, 770 hand-held music players, hand-held organisers). Those devices 771 probably represent the fastest growth segment of the Internet at 772 present. Moreover, many vendors of such devices have included 773 significant networking protocol improvements in incremental 774 operating system updates, rather than always waiting for a new 775 major release to add networking facilities. However, other users 776 or vendors might be more interested by the new security models 777 enabled by having Identifiers different from Locators, or they 778 might be more interested in the ability to provide node-specific 779 multi-homing, rather than always multi-homing an entire site. In 780 the end, the marketplace has myriad users with various functional 781 needs. The set of improvements offered by ILNP is broad, and 782 should appeal to a wide range of vendors and users. 784 11. IMPLEMENTATION CONSIDERATIONSa 786 This section discusses implementation considerations that 787 are not otherwise discussed in the ILNP Internet-Drafts. 789 11.1 ILNP Session Cache 791 An ILNP-capable node will need to modify its network protocol 792 implementation to add an ILNP Session Cache. In theory, this 793 cache is within the ILNP network-layer. However, many network 794 protocol implementations do not have strict protocol separation 795 or layering. In the interest of efficient implementation, and 796 to avoid unduly restricting implementers, an ILNP implementation 797 is not required to limit the accessibility of ILNP Session Cache 798 to the network-layer. 800 The ILNP Session Cache contains at least the following 801 inter-related data elements: 803 Set of Local Locator(s) 804 Set of Correspondent' Locator(s) 805 Set of Local Identifier(s) 806 Set of Correspondent's Identifier(s) 807 Nonce used from the local node to that correspondent 808 Nonce used from that correspondent to the local node 809 Valid Time 811 Lookups in the ILNP Session Cache use an (Correspondent 812 Identifier, Nonce) tuple as a lookup key. This facilitates 813 situations where, perhaps due to deployment of Local-scope 814 Identifiers, more than one correspondent node is using the same 815 Identifier value. 817 The Valid Time field holds the (UTC) time (measured as seconds 818 since January 1st 1970, as with Network Time Protocol) through 819 which this ILNP session information is valid. A table entry 820 entry is current if the node's current time is less than or equal 821 to the time in the Valid Time field, while a table entry is aged 822 if the node's current time is greater than the time in the Valid 823 Time field. 825 12. SECURITY CONSIDERATIONS 827 This proposal outlines a proposed evolution for the Internet 828 Architecture to provide improved capabilities. This section 829 discusses security considerations for this proposal. 831 12.1 Authentication of Locator Updates 833 A separate document [ILNP-Nonce] proposed a new IPv6 834 Destination Option that can be used to carry a session nonce 835 end-to-end between communicating nodes. That nonce provides 836 protection against off-path attacks on an Identifier/Locator 837 session. The Nonce Destination Option is used ONLY for IP 838 sessions in the Identifier/Locator Split mode. 840 Ordinary IPv6 is vulnerable to on-path attacks unless 841 the IP Authentication Header or IP Encapsulating Security 842 Payload is in use. So the Nonce Destination Option 843 only seeks to provide protection against off-path attacks 844 on an IP session -- equivalent to ordinary IPv6 when 845 not using IP Security. 847 When the Identifier/Locator split mode is in use for an 848 existing IP session, the Nonce Destination Option MUST be 849 included in any ICMP control messages (e.g. ICMP Unreachable, 850 ICMP Locator Update) sent with regard to that IP session. 852 It is common to have non-symmetric paths between two nodes 853 on the Internet. To reduce the number of on-path nodes that 854 know the Nonce value for a given session when the I/L split 855 mode is in use, a nonce value is unidirectional, not 856 bidirectional. For example, for a session between two nodes 857 A and B, one nonce value is used from A to B and a different 858 nonce value is used from B to A. 860 When in the I/L Split operating mode for an existing IP 861 session, ICMP control messages received without a Nonce 862 Destination Option MUST be discarded as forgeries. This 863 security event SHOULD be logged. 865 When in the I/L Split operating mode for an existing IP 866 session, ICMP control messages received without a correct 867 nonce value inside the Nonce Destination Option MUST be 868 discarded as forgeries. This security event SHOULD be logged. 870 When in the I/L Split operating mode for an existing IP 871 session, and a node changes its Locator set, it should 872 include the Nonce Destination Option in the first few 873 data packets sent using a new Locator value, so that 874 the recipient can validate the received data packets 875 as valid (despite having an unexpected Source Locator 876 value). 878 For ID/Locator Split mode sessions operating in higher risk 879 environments, the use of the cryptographic authentication 880 provided by IP Authentication Header is recommended 881 *in addition* to concurrent use of the Nonce Destination 882 Option. 884 It is important to note that at present an IPv6 session is 885 entirely vulnerable to on-path attacks unless IPsec is in use 886 for that particular IPv6 session, so the security properties 887 of the new proposal are never worse than for existing IPv6. 889 12.2 Forged Identifier Attacks 891 In the deployed Internet, active attacks using packets with a 892 forged Source IP Address have been publicly known at least since 893 early 1995.[CA-1995-01] While these exist in the deployed 894 Internet, they have not been widespread. This is equivalent to 895 the issue of a forged Identifier value and demonstrates that this 896 is not a new threat created by the Identifier/Locator-split mode 897 of operation. 899 One mitigation for these attacks has been to deploy Source IP 900 Address Filtering.[RFC 2827] [RFC 3704] Jun Bi at U. Tsinghua 901 cites Arbor Networks as reporting that this mechanism has less 902 than 50% deployment and cites an MIT analysis indicating that at 903 least 25% of the deployed Internet permits forged source IP 904 addresses. 906 Other parts of this document discuss the probability of an 907 accidental duplicate Identifier being used on the Internet. 908 However, this sub-section instead focuses on methods for 909 mitigating attacks based on packets containing deliberately 910 forged Source Identifier values. 912 First, the recommendations of [RFC 2827] & [RFC 3704] remain. 913 So any packets that have a forged Locator value can be easily 914 filtered using existing widely available mechanisms. 916 Second, the receiving node does not blindly accept any packet 917 with the proper Source Identifier and proper Destination 918 Identifier as an authentic packet. Instead, each node operating 919 the I/L-split mode maintains a session cache for each of its 920 correspondents, as described above. This cache contains two 921 unidirectional nonce values (one used in control messages sent by 922 this node, a different one used to authenticate messages from the 923 other node). The cache also contains the currently valid set of 924 Locators and set of Identifiers for each correspondent node. If 925 a received packet contains valid Identifier values and a valid 926 Destination Locator, but contains a Source Locator value that is 927 not present in the session cache, the packet is dropped without 928 further processing as an invalid packet, unless the packet also 929 contains a Nonce Destination Option with the correct value used 930 for packets from the node with that Source Identifier to this 931 node. This prevents an off-path attacker from stealing an 932 existing session. 934 Third, any node can distinguish different nodes using the same 935 Identifier value by other properties of their sessions. IPv6 936 Neighbor Discovery prevents more than one node from using the 937 same source (Locator + Identifier) pair at the same time. So 938 cases of different nodes using the same Identifier value will 939 involve nodes that have different sets of valid Locator values. 940 A node can thus demux based on the combination of Source Locator 941 and Source Identifier if necessary. If IP Security is in use, 942 the combination of the Source Identifier and the SPI value would 943 be sufficient to demux two different sessions. 945 Finally, deployments in high threat environments also SHOULD use 946 the IP Authentication Header to authenticate control traffic and 947 data traffic. Because in the I/L-split mode, IP Security binds 948 only to the Identifier values, and never to the Locator values, 949 this enables a mobile or multi-homed node to use IPsec even when 950 its Locator value(s) have just changed. 952 12.3 IP Security Enhancements 954 The IP Security standards are enhanced here by binding IPsec 955 Security Associations to the Identifiers of the session 956 endpoints, rather than binding IPsec Security Associations 957 to the IP Addresses as at present. This change enhances the 958 deployability and interoperability of the IP Security standards, 959 but does not decrease the security provided by those protocols. 961 Also, the IP Authentication Header omits the Source Locator and 962 Destination Locator fields from its authentication calculations 963 when ILNP is in use. This enables IP AH to work well even 964 through a NAT or other situation where a Locator value might 965 change during transit. 967 12.4 DNS Security 969 The DNS enhancements proposed here are entirely compatible with, 970 and can be protected using, the existing IETF standards for DNS 971 Security.[RFC 4033] The Secure DNS Dynamic Update mechanism used 972 here is also used unchanged.[RFC 3007] So there is no change to 973 the security properties of the Domain Name System or of DNS 974 servers due to ILNP. 976 12.5 Firewall Considerations 978 In the proposed new scheme, firewalls are able to authenticate 979 ICMP control messages arriving on the external interface. This 980 enables more thoughtful handling of ICMP messages by firewalls 981 than is commonly the case at present. As the firewall is along 982 the path between the communicating nodes, the firewall can snoop 983 on the Session Nonce being carried in the initial packets of an 984 I/L Split mode session. The firewall can verify that nonce is 985 present on incoming control packets, dropping any control packets 986 that lack the correct nonce value. 988 By always including the nonce, even when IP Security is also in 989 use, the firewall can filter out all off-path attacks. In this 990 case, a forged packet from an on-path attacker will still be 991 detected when the IPsec input processing occurs in the receiving 992 node; this will cause that forged packet to be dropped rather 993 than acted upon. 995 12.6 Neighbor Discovery Authentication 997 Nothing in this proposal prevents sites from using the 998 Secure Neighbor Discovery (SEND) proposal for authenticating 999 IPv6 Neighbor Discovery. [RFC 3971] 1001 12.7 Site Topology Obfuscation 1003 A site that wishes to obscure its internal topology information 1004 MAY do so by deploying site border routers that rewrite the 1005 Locator values for the site as packets enter or leave the site. 1007 For example, a site might choose to use a ULA prefix internally 1008 for this reason.[RFC 4193] [ID-ULA] In this case, the site border 1009 routers would rewrite the Source Locator of ILNP packets leaving 1010 the site to a global-scope Locator associated with the site. 1011 Also, those site border routers would rewrite the Destination 1012 Locator of packets entering the site from the global-scope 1013 Locator to an appropriate interior ULA Locator for the 1014 destination node.[MILCOM08] 1016 12.8 Path Liveness 1018 Some perceive that an Identifier-Locator Split architecture 1019 creates a new issue that is sometimes called "Locator Liveness" 1020 or "Path Liveness". This refers to the question of whether an IP 1021 packet with a particular destination Locator value will be able 1022 to reach the intended destination or not, given that some 1023 otherwise valid paths might be unusable by the sending node 1024 (e.g. due to security policy or other administrative choice). 1025 In fact, this issue has existed in the IPv4 Internet for decades. 1027 For example, an IPv4 server might have multiple valid IP 1028 addresses, each advertised to the world via an DNS "A" record. 1029 However, at a given moment in time, it is possible that a given 1030 sending node might not be able to use a given (otherwise valid) 1031 destination IPv4 address in an IP packet to reach that IPv4 1032 server. 1034 So we see that using an Identifier/Locator Split architecture 1035 does not create this issue, nor does it make this issue worse 1036 than it is with the deployed IPv4 Internet. 1038 In ILNP, the same conceptual approach described in [RFC 5534] can 1039 be reused. Alternatively, an ILNP node can reuse the existing 1040 IPv4 methods for determining whether a given path to the target 1041 destination is currently usable, which existing methods leverage 1042 session state information that the communicating end systems are 1043 already keeping (e.g. for transport-layer protocol reasons). 1045 Last, it is important for the reader to understand that the 1046 mechanism described in [ILNP-ICMP] is a performance optimisation, 1047 significantly shortening the layer-3 handoff time if/when a 1048 correspondent changes location. Architecturally, using ICMP 1049 is no different from using UDP, of course. 1051 13. IANA CONSIDERATIONS 1053 This document has no IANA considerations. 1055 14. REFERENCES 1056 This section provides both normative and informative 1057 references relating to this note. 1059 14.1. Normative References 1061 [RFC 2119] Bradner, S., "Key words for use in RFCs to 1062 Indicate Requirement Levels", BCP 14, RFC 2119, 1063 March 1997. 1065 [RFC 2460] S. Deering & R. Hinden, "Internet Protocol 1066 Version 6 Specification", RFC-2460, 1067 December 1998. 1069 [RFC 3007] B. Wellington, "Secure Domain Name System 1070 Dynamic Update", RFC-3007, November 2000. 1072 [RFC 4033] R. Arends, et alia, "DNS Security Introduction 1073 and Requirements", RFC-4033, March 2005. 1075 [RFC 4219] R. Hinden & S. Deering, "IP Version 6 1076 Addressing Architecture", RFC-4219, February 1077 2006. 1079 14.2. Informative References 1081 [8+8] M. O'Dell, "8+8 - An Alternate Addressing 1082 Architecture for IPv6", Internet-Draft, 1083 October 1996. 1085 [CA-1995-01] US CERT, "IP Spoofing Attacks and Hijacked 1086 Terminal Connections", CERT Advisory 1995-01, 1087 Issued 23 JAN 1995, Revised 23 SEP 1997. 1089 [GSE] M. O'Dell, "GSE - An Alternate Addressing 1090 Architecture for IPv6", Internet-Draft, 1091 February 1997. 1093 [ID-ULA] R. Hinden, G. Huston, & T. Narten, "Centrally 1094 Assigned Unique Local IPv6 Unicast Addresses", 1095 draft-ietf-ipv6-ula-central-02.txt, 15 June 2007. 1097 [ID-Referral] B. Carpenter and others, "A Generic Referral 1098 Object for Internet Entities", 1099 draft-carpenter-behave-referral-object-01, 1100 20 October 2009. 1102 [IEEE-EUI] IEEE Standards Association, "Guidelines for 1103 64-bit Global Identifier (EUI-64)", IEEE, 1104 2007. 1106 [IEN 1] C.J. Bennett, S.W. Edge, & A.J. Hinchley, 1107 "Issues in the Interconnection of Datagram 1108 Networks", Internet Experiment Note (IEN) 1, 1109 INDRA Note 637, PSPWN 76, University College 1110 London, London, England, UK, WC1E 6BT, 1111 29 July 1977. 1112 http://www.postel.org/ien/ien001.pdf 1114 [IEN 19] J. F. Shoch, "Inter-Network Naming, Addressing, 1115 and Routing", IEN-19, January 1978. 1117 [IEN 23] J. F. Shoch, "On Names, Addresses, and 1118 Routings", IEN-23, January 1978. 1120 [IEN 31] D. Cohen, "On Names, Addresses, and Routings 1121 (II)", IEN-31, April 1978. 1123 [ILNP-Nonce] R. Atkinson, "Nonce Destination Option", 1124 draft-rja-ilnp-nonce-02.txt, February 2010. 1126 [ILNP-DNS] R. Atkinson, "Additional DNS Resource Records", 1127 draft-rja-ilnp-dns-02.txt, February 2010. 1129 [ILNP-ICMP] R. Atkinson, "ICMP Locator Update message" 1130 draft-rja-ilnp-icmp-01.txt, February 2010. 1132 [Liu-DNS] C. Liu & P. Albitz, "DNS & Bind", 5th Edition, 1133 O'Reilly & Associates, Sebastopol, CA, USA, 1134 May 2006. ISBN 0-596-10057-4 1136 [MobiArch07] R. Atkinson, S. Bhatti, & S. Hailes, 1137 "Mobility as an Integrated Service Through 1138 the Use of Naming", Proceedings of 1139 ACM MobiArch 2007, August 2007, 1140 Kyoto, Japan. 1142 [MobiArch08] R. Atkinson, S. Bhatti, & S. Hailes, 1143 "Mobility Through Naming: Impact on DNS", 1144 Proceedings of ACM MobiArch 2008, August 2008, 1145 Seattle, WA, USA. 1147 [MobiWAC07] R. Atkinson, S. Bhatti, & S. Hailes, 1148 "A Proposal for Unifying Mobility with 1149 Multi-Homing, NAT, & Security", 1150 Proceedings of ACM MobiWAC 2007, Chania, 1151 Crete. ACM, October 2007. 1153 [MILCOM08] R. Atkinson, S. Bhatti, & S. Hailes, 1154 "Harmonised Resilience, Security, and Mobility 1155 Capability for IP", Proceedings of IEEE 1156 Military Communications (MILCOM) Conference, 1157 San Diego, CA, USA, November 2008. 1159 [MILCOM09] R. Atkinson, S. Bhatti, & S. Hailes, 1160 "Site-Controlled Secure Multi-Homing and 1161 Traffic Engineering For IP", Proceedings of 1162 IEEE Military Communications (MILCOM) Conference, 1163 Boston, MA, USA, October 2009. 1165 [PHG02] Pappas, A, S. Hailes, & R. Giaffreda, 1166 "Mobile Host Location Tracking through DNS", 1167 Proceedings of IEEE London Communications 1168 Symposium, IEEE, September 2002, London, 1169 England, UK. 1171 [SBK2002] Alex C. Snoeren, Hari Balakrishnan, & M. Frans 1172 Kaashoek, "Reconsidering Internet Mobility", 1173 Proceedings of 8th Workshop on Hot Topics in 1174 Operating Systems, 2002. 1176 [RFC 814] D.D. Clark, "Names, Addresses, Ports, and 1177 Routes", RFC-814, July 1982. 1179 [RFC 1498] J.H. Saltzer, "On the Naming and Binding of 1180 Network Destinations", RFC-1498, August 1993. 1182 [RFC 1631] K. Egevang & P. Francis, "The IP Network 1183 Address Translator (NAT)", RFC-1631, May 1994. 1185 [RFC 2827] P. Ferguson & D. Senie, "Network Ingress Filtering: 1186 Defeating Denial of Service Attacks which employ 1187 IP Source Address Spoofing", RFC-2827, May 2000. 1189 [RFC 3022] P. Srisuresh & K. Egevang, "Traditional IP 1190 Network Address Translator", RFC-3022, 1191 January 2001. 1193 [RFC 3027] M. Holdrege and P Srisuresh, "Protocol 1194 Complications of the IP Network Address 1195 Translator", RFC-3027, January 2001. 1197 [RFC 3704] F. Baker & P. Savola, "Ingress Filtering for 1198 Multihomed Networks, RFC-3704, March 2004. 1200 [RFC 3715] B. Aboba and W. Dixon, "IPsec-Network Address 1201 Translation (NAT) Compatibility Requirements", 1202 RFC-3715, March 2004. 1204 [RFC 3775] D. Johnson, C. Perkins, and J. Arkko, "Mobility 1205 Support in IPv6", RFC-3775, June 2004. 1207 [RFC 3948] A. Huttunen, et alia, "UDP Encapsulation of 1208 IPsec ESP Packets", RFC-3948, January 2005. 1210 [RFC 3971] J. Arkko, J. Kempf, B. Zill, & P. Nikander, 1211 "SEcure Neighbor Discovery (SEND)", RFC-3971 1212 March 2005. 1214 [RFC 3972] T. Aura, "Cryptographically Generated Addresses 1215 (CGAs)", RFC-3972, March 2005. 1217 [RFC 4193] R. Hinden & B. Haberman, "Unique Local IPv6 1218 Unicast Addresses, RFC-4193, October 2005. 1220 [RFC 4941] T. Narten, R. Draves, & S. Krishnan, "Privacy 1221 Extensions for Stateless Address Autoconfiguration 1222 in IPv6", RFC-4941, September 2007. 1224 [RFC 5061] R. Stewart, Q. Xie, M. Tuexen, S. Maruyama, & 1225 M. Kozuka, "Stream Control Transmission Protocol 1226 (SCTP) Dynamic Address Reconfiguration", RFC-5061, 1227 September 2007. 1229 [RFC 5534] J. Arkko & I. van Beijnum, "Failure Detection and 1230 Locator Pair Exploration Protocol for IPv6 1231 Multihoming", RFC-5534, June 2009. 1233 [TeleSys] R. Atkinson, S. Bhatti, & S. Hailes, 1234 "ILNP: Mobility, Multi-Homing, Localised Addressing 1235 and Security Through Naming", Telecommunications 1236 Systems, Volume 42, Number 3-4, pp 273-291, 1237 Springer-Verlag, December 2009, ISSN 1018-4864. 1239 ACKNOWLEDGEMENTS 1241 Saleem Bhatti, Steve Hailes, Joel Halpern, Mark Handley, Tony Li, 1242 and Yakov Rehkter (in alphabetical order) provided review and 1243 feedback on earlier versions of this document. 1245 AUTHOR'S ADDRESS 1247 R. Atkinson 1248 McLean, VA, USA 1249 Email: rja.lists@gmail.com 1251 Expires: 08 AUG 2010