idnits 2.17.1 draft-irtf-rrg-ilnp-arch-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (10 July 2012) is 4280 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'I' is mentioned on line 696, but not defined == Missing Reference: 'L' is mentioned on line 696, but not defined == Missing Reference: 'ILNP-V4OPTS' is mentioned on line 1834, but not defined == Missing Reference: 'RFC-2002' is mentioned on line 1365, but not defined ** Obsolete undefined reference: RFC 2002 (Obsoleted by RFC 3220) == Missing Reference: 'RFC-1825' is mentioned on line 1698, but not defined ** Obsolete undefined reference: RFC 1825 (Obsoleted by RFC 2401) == Missing Reference: 'RFC-1826' is mentioned on line 1698, but not defined ** Obsolete undefined reference: RFC 1826 (Obsoleted by RFC 2402) == Missing Reference: 'RFC-1827' is mentioned on line 1698, but not defined ** Obsolete undefined reference: RFC 1827 (Obsoleted by RFC 2406) == Unused Reference: 'RFC1825' is defined on line 2356, but no explicit reference was found in the text == Unused Reference: 'RFC1826' is defined on line 2359, but no explicit reference was found in the text == Unused Reference: 'RFC1827' is defined on line 2362, but no explicit reference was found in the text == Unused Reference: 'RFC2002' is defined on line 2372, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 1631 (Obsoleted by RFC 3022) -- Obsolete informational reference (is this intentional?): RFC 1825 (Obsoleted by RFC 2401) -- Obsolete informational reference (is this intentional?): RFC 1826 (Obsoleted by RFC 2402) -- Obsolete informational reference (is this intentional?): RFC 1827 (Obsoleted by RFC 2406) -- Obsolete informational reference (is this intentional?): RFC 2002 (Obsoleted by RFC 3220) -- Obsolete informational reference (is this intentional?): RFC 3177 (Obsoleted by RFC 6177) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 8 errors (**), 0 flaws (~~), 13 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft RJ Atkinson 3 draft-irtf-rrg-ilnp-arch-06.txt Consultant 4 Expires: 10 JAN 2013 SN Bhatti 5 Category: Experimental U. St Andrews 6 10 July 2012 8 ILNP Architectural Description 9 draft-irtf-rrg-ilnp-arch-06.txt 11 Status of this Memo 13 Distribution of this memo is unlimited. 15 Copyright (c) 2012 IETF Trust and the persons identified as the 16 document authors. All rights reserved. 18 This document is subject to BCP 78 and the IETF Trust's Legal 19 Provisions Relating to IETF Documents 20 (http://trustee.ietf.org/license-info) in effect on the date of 21 publication of this document. Please review these documents 22 carefully, as they describe your rights and restrictions with 23 respect to this document. Code Components extracted from this 24 document must include Simplified BSD License text as described in 25 Section 4.e of the Trust Legal Provisions and are provided 26 without warranty as described in the Simplified BSD License. 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 This document may contain material from IETF Documents or 32 IETF Contributions published or made publicly available 33 before November 10, 2008. The person(s) controlling the copyright 34 in some of this material may not have granted the IETF Trust the 35 right to allow modifications of such material outside the IETF 36 Standards Process. Without obtaining an adequate license from the 37 person(s) controlling the copyright in such materials, this 38 document may not be modified outside the IETF Standards Process, 39 and derivative works of it may not be created outside the IETF 40 Standards Process, except to format it for publication as an RFC 41 or to translate it into languages other than English. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF), its areas, and its working groups. Note that 45 other groups may also distribute working documents as 46 Internet-Drafts. 48 Internet-Drafts are draft documents valid for a maximum of six 49 months and may be updated, replaced, or obsoleted by other 50 documents at any time. It is inappropriate to use Internet-Drafts 51 as reference material or to cite them other than as "work in 52 progress." 54 The list of current Internet-Drafts can be accessed at 55 http://www.ietf.org/1id-abstracts.html 57 The list of Internet-Draft Shadow Directories can be accessed at 58 http://www.ietf.org/shadow.html 60 This document is not on the IETF standards-track and does not 61 specify any level of standard. This document merely provides 62 information for the Internet community. 64 This document is part of the ILNP document set, which has had 65 extensive review within the IRTF Routing Research Group. ILNP 66 is one of the recommendations made by the RG Chairs. Separately, 67 various refereed research papers on ILNP have also been published 68 during this decade. So the ideas contained herein have had much 69 broader review than the IRTF Routing RG. The views in this 70 document were considered controversial by the Routing RG, but the 71 RG reached a consensus that the document still should be 72 published. The Routing RG has had remarkably little consensus on 73 anything, so virtually all Routing RG outputs are considered 74 controversial. 76 Abstract 78 This document provides an Architectural description and the 79 Concept of Operations for the Identifier-Locator Network Protocol 80 (ILNP), which is an experimental, evolutionary enhancement to 81 IP. This is a product of the IRTF Routing RG. 83 Table of Contents 85 1. Introduction .........................................? 86 2. Architectural Overview................................? 87 3. Architectural Changes Introduced by ILNP..............? 88 4. ILNP Basic Connectivity...............................? 89 5. Multi-Homing & Multi-Path Transport...................? 90 6. Mobility..............................................? 91 7. IP Security with ILNP.................................? 92 8. Backwards Compatibility & Incremental Deployment......? 93 9. Security Considerations ..............................? 94 10. Privacy Considerations................................? 95 11. IANA Considerations ..................................? 96 12. References ...........................................? 98 1. INTRODUCTION 100 At present, the Internet research and development community are 101 exploring various approaches to evolving the Internet 102 Architecture to solve a variety of issues including, but not 103 limited to, scalability of inter-domain routing [RFC4984]. A wide 104 range of other issues (e.g. site multi-homing, node multi-homing, 105 site/subnet mobility, node mobility) are also active concerns at 106 present. Several different classes of evolution are being 107 considered by the Internet research & development community. One 108 class is often called "Map and Encapsulate", where traffic would 109 be mapped and then tunnelled through the inter-domain core of the 110 Internet. Another class being considered is sometimes known as 111 "Identifier/Locator Split". This document relates to a proposal 112 that is in the latter class of evolutionary approaches. 114 There has been substantial research relating to naming in the 115 Internet through the years [IEN1] [IEN19] [IEN23] [IEN31] 116 [IEN135] [RFC814] [RFC1498] [RFC2956]. Much of that research has 117 indicated that binding the end-to-end transport-layer session 118 state with a specific interface of a node at a specific location 119 is undesirable, for example creating avoidable issues for 120 mobility, multi-homing, end-to-end security. More recently, 121 mindful of that important prior work, and starting well before 122 the Routing RG was re-chartered to focus on inter-domain routing 123 scalability, the authors have been examining enhancements to 124 certain naming aspects of the Internet Architecture. Separately, 125 the Internet Architecture Board (IAB) recently considered 126 the matter of Internet evolution, including naming [RFC6250]. 128 Our ideas and progress so far are embodied in the on-going 129 definition of an experimental protocol which we call the 130 Identifier Locator Network Protocol (ILNP). 132 Links to relevant material are all available at: 133 http://ilnp.cs.st-andrews.ac.uk/ 135 At the time of writing, the main body of peer-reviewed research 136 from which the ideas in this and the accompanying documents draw 137 is given in [LABH06], [ABH07a], [ABH07b], [ABH08a], [ABH08b], 138 [ABH09a], [ABH09b], [RAB09], [ABH10], [RB10], [BA11], [BAK11], 139 [BA12]. 141 In this document, we: 143 a) describe the architectural concepts behind ILNP and 144 how various ILNP capabilities operate: this document 145 deliberately focuses on describing the key architectural 146 changes that ILNP introduces and defers engineering 147 discussion to separate documents. 149 Other documents (listed below): 151 b) show how functions based on ILNP would be realised on 152 today's Internet by proposing an instance of ILNP based 153 on IPv6, which we call ILNPv6 (there is also a document 154 describing ILNPv4, which is how ILNP could be applied 155 to IPv4). 157 c) discuss salient operational and engineering issues impacting 158 the deployment of ILNPv6 and the impact on the Internet. 160 d) give architectural descriptions of optional advanced 161 capabilities in advanced deployments based on the ILNP 162 approach. 164 1.1 Document Roadmap 166 This document describes the architecture for the Identifier Locator 167 Network Protocol (ILNP) including concept of operations. The authors 168 recommend reading and understanding this document as the starting 169 point to understanding ILNP. 171 The ILNP architecture can have more than one engineering 172 instantiation. For example, one can imagine a "clean-slate" 173 engineering design based on the ILNP architecture. In separate 174 documents, we describe two specific engineering instances of 175 ILNP. The term ILNPv6 refers precisely to an instance of ILNP that 176 is based upon, and backwards compatible with, IPv6. The term ILNPv4 177 refers precisely to an instance of ILNP that is based upon, and 178 backwards compatible with, IPv4. 180 Many engineering aspects common to both ILNPv4 and ILNPv6 are 181 described in [ILNP-ENG]. A full engineering specification for 182 either ILNPv6 or ILNPv4 is beyond the scope of this document. 184 Readers are referred to other related ILNP documents for details 185 not described here: 187 a) [ILNP-ENG] describes engineering and implementation 188 considerations that are common to both ILNPv4 and ILNPv6. 190 b) [ILNP-DNS] defines additional DNS resource records that 191 support ILNP. 193 c) [ILNP-ICMPv6] defines a new ICMPv6 Locator Update message 194 used by an ILNP node to inform its correspondent nodes 195 of any changes to its set of valid Locators. 197 d) [ILNP-NONCEv6] defines a new IPv6 Nonce Destination Option 198 used by ILNPv6 nodes (1) to indicate to ILNP correspondent 199 nodes (by inclusion within the initial packets of an ILNP 200 session) that the node is operating in the ILNP mode and 201 (2) to prevent off-path attacks against ILNP ICMP messages. 202 This Nonce is used, for example, with all ILNP ICMPv6 203 Locator Update messages that are exchanged among ILNP 204 correspondent nodes. 206 e) [ILNP-ICMPv4] defines a new ICMPv4 Locator Update message 207 used by an ILNP node to inform its correspondent nodes 208 of any changes to its set of valid Locators. 210 f) [ILNP-v4OPTS] defines a new IPv4 Nonce Option used by ILNPv4 211 nodes to carry a security nonce to prevent off-path attacks 212 against ILNP ICMP messages and also defines a new IPv4 213 Identifier Option used by ILNPv4 nodes. 215 g) [ILNP-ARP] describes extensions to ARP for use with ILNPv4. 217 h) [ILNP-ADV] describes optional engineering and deployment 218 functions for ILNP. These are not required for the operation 219 or use of ILNP and are provided as additional options. 221 1.2 History 223 In 1977, Internet researchers at University College London wrote 224 the first Internet Experiment Note (IEN), which discussed issues 225 with the interconnection of networks [IEN1]. This identified 226 the inclusion of network-layer addresses in the transport-layer 227 session state (e.g. TCP checksum) as a significant problem for 228 mobile and multi-homed nodes and networks. It also proposed 229 separation of identity from location as a better approach to take 230 when designing the TCP/IP protocol suite. Unfortunately, that 231 separation did not occur, so the deployed IPv4 and IPv6 Internet 232 entangles upper-layer protocols (e.g. TCP, UDP) with 233 network-layer routing and topology information (e.g. IP 234 addresses) [IEN1] [RFC768] [RFC793]. 236 The architectural concept behind ILNP derives from a June 1994 237 note by Bob Smart to the IETF SIPP WG mailing list [SIPP94]. In 238 January 1995, Dave Clark sent a similar note to the IETF IPng WG 239 mailing list, suggesting that the IPv6 address be split into 240 separate Identifier and Locator fields [IPng95]. 242 Afterwards, Mike O'Dell pursued this concept in Internet-Drafts 243 describing "8+8" or "GSE" [8+8] [GSE]. More recently, the IRTF 244 Namespace Research Group (NSRG) studied this matter around the 245 turn of the century. Unusually for an IRTF RG, the NSRG operated 246 on the principle that unanimity was required for the NSRG to make 247 a recommendation. Atkinson was a member of the IRTF NSRG. At 248 least one other protocol, the Host Identity Protocol (HIP), also 249 derives in part from the IRTF NSRG studies (and related 250 antecedent work). This current proposal differs from O'Dell's 251 work in various ways, notably in that it does not require 252 deployment or use of Locator rewriting. 254 The key idea proposed for ILNP is to directly and specifically 255 change the overloaded semantics of the IP address. The Internet 256 community has indicated explicitly, several times, that this use 257 of overloaded semantics is a significant problem with the use of 258 the Internet protocol today [RFC1498] [RFC2101] [RFC2956] 259 [RFC4984]. 261 While the research community has made a number of proposals that 262 could provide solutions, so far there has been little progress on 263 changing the status quo. 265 1.3 Terminology 267 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 268 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 269 document are to be interpreted as described in RFC 2119 [RFC2119]. 271 2. ARCHITECTURAL OVERVIEW 273 ILNP takes a different approach to naming of communication 274 objects within the network stack. Two new data types are 275 introduced which subsume the role of the IP address at the 276 network and transport layers in the current IP architecture. 278 2.1 Identifiers and Locators 280 ILNP explicitly replaces the use of IP addresses with two 281 distinct name spaces, each having distinct and different 282 semantics: 284 a) Identifier: a non-topological name for uniquely identifying 285 a node. 287 b) Locator: a topologically-bound name for an IP subnetwork. 289 The use of these two new namespaces in comparison to IP is given 290 in Table 1. The table shows where existing names are used for 291 state information in end-systems or protocols. 293 Layer | IP | ILNP 294 ---------------+----------------------+--------------- 295 Application | FQDN or IP address | FQDN 296 Transport | IP address | Identifier 297 Network | IP address | Locator 298 Physical i/f | IP address | MAC address 299 ---------------+----------------------+--------------- 300 FQDN = Fully Qualified Domain Name 301 i/f = interface 303 Table 1: Use of names for state information in various 304 communication layers for IP and ILNP. 306 As shown in Table 1, if an application uses a Fully-Qualified 307 Domain Name at the application-layer, rather than an IP Address 308 or other lower-layer identifier, then the application perceives 309 no architectural difference between IP and ILNP. We call such 310 applications "well-behaved" with respect to naming as use of the 311 FQDN at the application-layer is recommended in RFC1958 312 [RFC1958]. Some other applications also avoid use of IP address 313 information within the application-layer protocol; we also 314 consider these applications to be "well-behaved". Any 315 well-behaved application should be able to operate on ILNP 316 without any changes. Note that application level use of IP 317 addresses includes application-level configuration information, 318 e.g. Apache Web Server (httpd) configuration files make extensive 319 use of IP addresses as a form of identity. 321 ILNP does not require applications to be rewritten to use a new 322 Networking Application Programming Interface (API). So existing 323 well-behaved IP-based applications should be able to work over 324 ILNP as-is. 326 In ILNP, transport-layer protocols use only an end-to-end, 327 non-topological node Identifier in any transport-layer session 328 state. It is important to note that the node Identifier names the 329 node, not a specific interface of the node. In this way, it has 330 different semantics and properties than either the IPv4 Address, 331 the IPv6 Address, or the IPv6 Interface Identifier [RFC791] 332 [RFC4219]. 334 The use of the ILNP Identifier value within application-layer 335 protocols is not recommended. Instead, the use of either a 336 Fully Qualified Domain Name (FQDN) or some different 337 topology-independent namespace is recommended. 339 At the network-layer, Locator values, which have topological 340 significance, are used for routing and forwarding of ILNP 341 packets, but Locators are not used in upper-layer protocols. 343 As well as the new namespaces, another significant difference in 344 ILNP, as shown in Table 1, is that there is no binding of a 345 routable name to an interface, or Sub-Network Point of Attachment 346 (SNPA), as there is in IP. The existence of such a binding in IP 347 effectively binds transport protocol flows to a specific, single 348 interface on a node. Also, applications that include IP addresses 349 in their application-layer session state effectively bind to a 350 specific, single interface on a node. [RFC2460] [RFC3484]. 352 In ILNP, dynamic bindings exist between Identifier values and 353 associated Locator values, as well as between {Identifier, 354 Locator} pairs and (physical or logical) interfaces on the node. 356 This change enhances the Internet architecture by adding crisp 357 and clear semantics for the Identifier and for the Locator, 358 removing the overloaded semantics of the IP address [RFC1992] 359 [RFC4984], by updating end system protocols, but without 360 requiring any router or backbone changes. In ILNP, the closest 361 approximation to an IP address is an I-L Vector (I-LV), 362 which is a given binding between an Identifier and Locator pair, 363 written as [I, L]. I-LVs are discussed in more detail below. 365 Where, today, IP packets have: 367 - source IP address, destination IP address 369 instead ILNP packets have: 371 - source I-LV, destination I-LV 373 However, it must be emphasised that the I-LV and the IP address 374 are *not* equivalent. 376 With these naming enhancements, we will improve the Internet 377 architecture by adding explicit harmonised support for many 378 functions, such as multi-homing, mobility and IP Security. 380 2.2 Deprecating IP Addresses 382 ILNP places an explicit Locator and Identifier in the IP packet 383 header, replacing the usual IP address. Locators are tied to the 384 topology of the network. They may change frequently, as the node 385 or site changes its network connectivity. The node Identifier is 386 normally much more static, and remains constant throughout the 387 life of a given transport-layer session, and frequently much 388 longer. However, there are various options for Identifier values, 389 as will be discussed later [ILNP-ENG]. The way that I-LVs are 390 encoded into packet headers is different for IPv4 and IPv6, as 391 explained in [ILNP-ENG]. 393 Identifiers and Locators for hosts are advertised explicitly in 394 DNS, through the use of new Resource Records (RRs). This is a 395 logical and reasonable use of DNS, completely analogous to the 396 capability that DNS provides today. At present, among other 397 current uses, the DNS is used to map from an FQDN to a set of 398 addresses. As ILNP replaces IP addresses with Identifiers and 399 Locators, it is then clearly rational to use the DNS to map an 400 FQDN to a set of Identifiers and a set of Locators for a node. 402 The presence of ILNP Locators and Identifiers in the DNS for a 403 DNS owner name is an indicator to correspondents that the 404 correspondents can try to establish an ILNP-based transport-layer 405 session with that DNS owner name. 407 Specifically in response to [RFC4984], ILNP improves routing 408 scalability by helping multi-homed sites operate effectively with 409 provider-aggregatable (PA) address prefixes. Many multi-homed 410 sites today request provider-independent (PI) address prefixes so 411 they can provide session survivability despite the failure of one 412 or more access links or Internet Service Providers (ISPs). ILNP 413 provides this transport-layer session survivability by having a 414 provider-independent Node Identifier (NID) value that is free of 415 any topological semantics. This NID value can be bound 416 dynamically to a provider-aggregatable Locator (L) value, the 417 latter being a topological name i.e. a PA network prefix. By 418 allowing correspondents to change arbitrarily among multiple PA 419 Locator values, survivability is enabled as changes to the L 420 values need not disrupt transport-layer sessions. In turn, this 421 allows an ILNP multi-homed site to have both the full 422 transport-layer and full network-layer session resilience that is 423 today offered by PI addressing while using the equivalent of PA 424 addressing. In turn, this eliminates the current need to use 425 globally visible PI routing prefixes for each multi-homed site. 427 2.3 Session Terminology 429 To improve clarity and readability of the several ILNP 430 specification documents, this section defines the terms 431 "network-layer session" and "transport-layer session" 432 both for IP-based networks and ILNP-based networks. 434 Today, network-layer IP sessions have 2 components: 436 - Source IP address (A_S) 437 - Destination IP address (A_D) 439 For example, a tuple for an IP layer session would be: 441 443 Instead network-layer ILNP sessions have 4 components: 445 - Source Locator(s) (L_S) 446 - Source Identifier(s) (I_S) 447 - Destination Locator(s) (L_D) 448 - Destination Identifier(s) (L_S) 450 and a tuple for an ILNP session would be: 452 454 The phrase "ILNP session" refers to an ILNP-based network-layer 455 session, having the 4 components in the definition above. 457 For engineering efficiency, multiple transport-layer sessions 458 between a pair of ILNP correspondents normally share a single 459 ILNP session (IL-V pairs and associated Nonce values). Also, for 460 engineering convenience (and to cope with situation where different 461 nodes, at different locations, might use the same I values), in the 462 specific implementation of ILNPv6 and ILNPv4, we define the use of 463 nonce values: 465 - Source-to-destination Nonce value (N_S) 466 - Destination-to-source Nonce value (N_D) 468 These are explained in more detail in [ILNP-ENG], with 469 [ILNP-NONCEv6] for ILNPv6 and [ILNP-V4OPTS] for ILNPv4. 471 Today, transport-layer sessions using IP include these 472 5 components: 473 - Source IP address (A_S) 474 - Destination IP address (A_D) 475 - Transport-layer protocol (e.g. UDP, TCP, SCTP) 476 - Source transport-layer port number (P_S) 477 - Destination transport-layer port number (P_D) 479 For example, a TCP tuple would be: 481 483 Instead, transport-layer sessions using ILNP include these 484 5 components: 486 - Source Identifier (I_S) 487 - Destination Identifier (I_D) 488 - Transport-layer protocol (e.g. UDP, TCP, SCTP) 489 - Source transport-layer port number (P_S) 490 - Destination transport-layer port number (P_D) 492 and an example tuple: 494 496 2.4 Other Goals 498 While we seek to make significant enhancements to the current 499 Internet Architecture, we also wish to ensure that instantiations 500 of ILNP are: 502 a) Backwards compatible: implementations of ILNP should be able 503 to work with existing IPv6 or IPv4 deployments, without 504 requiring application changes. 506 b) Incrementally deployable: to deploy an implementation of 507 ILNP, changes to the network nodes should only be for those 508 nodes that choose to use ILNP. The use of ILNP by some nodes 509 does not require other nodes (that do not use ILNP) to be 510 upgraded. 512 3. ARCHITECTURAL CHANGES INTRODUCED BY ILNP 514 In this section, we describe the key changes that are made to the 515 current Internet architecture. These key changes impact end 516 systems, rather than routers. 518 3.1 Identifiers 520 Identifiers, also called Node Identifiers (NIDs), are non-topological 521 values that identify an ILNP node. A node might be a physical 522 node or a virtual node. For example, a single physical device 523 might contain multiple independent virtual nodes. Alternately, 524 a single virtual device might be composed from multiple physical 525 devices. In the case of a Multi-Level Secure (MLS) system, each 526 valid sensitivity label of that system might be a separate 527 virtual node. 529 A node MAY have multiple Identifier values associated with it, 530 which MAY be used concurrently. 532 In normal operation when a node is responding to a received ILNP 533 packet that creates a new network-layer session, the correct NID 534 value to use for that network-layer session with that 535 correspondent node will be learned from the received ILNP packet. 537 In normal operation, when a node is initiating communication with 538 a correspondent node, the correct I value to use for that session 539 with that correspondent node will be learned either through the 540 application-layer naming, through DNS name resolution, through 541 some alternative name resolution system, or an application may be 542 able to select different I values directly -- as Identifiers are 543 visible above the network-layer via the transport protocol. 545 3.1.1 Node Identifiers are immutable during a session 547 Once a Node Identifier (NID) value has been used to establish a 548 transport-layer session, that Node Identifier value forms part of 549 the end-to-end (invariant) transport-layer session state and so 550 MUST remain fixed for the duration of that session. This means, 551 for example, that throughout the duration of a given TCP session, 552 the Source Node Identifier and Destination Node Identifier values 553 will not change. 555 In normal operation, a node will not change its set of valid 556 Identifier values frequently. However, a node MAY change its set 557 of valid Identifier values over time, for example in an effort to 558 provide identity obfuscation, while remaining subject to the 559 architectural rule of the preceding paragraph. When a node 560 has more than one Node Identifier value concurrently, the node 561 might have multiple concurrent ILNP sessions with some 562 correspondent node, in which case Node Identifier values will 563 differ between the different concurrent ILNP sessions. 565 3.1.2 Syntax 567 ILNP Identifiers have the same syntax as IPv6 Interface 568 Identifiers [RFC4291], based on the EUI-64 format [IEEE-EUI], 569 which helps with backwards compatibility. There is no semantic 570 equivalent to an ILNP Identifier in IPv4 or IPv6 today. 572 The Modified EUI-64 syntax used by both ILNP Identifiers and IPv6 573 Interface Identifiers contains a bit indicating whether the value 574 has global-scope or local-scope [IEEE-EUI] [RFC4219]. ILNP 575 Identifiers have either global-scope or local-scope. If they have 576 global scope, they SHOULD be globally unique. 578 Regardless of whether an Identifier is global-scope or 579 local-scope, an Identifier MUST be unique within the scope of a 580 given Locator value to which it is bound for a given ILNP session or 581 packet flow. As an example, with ILNPv6, the ordinary IPv6 582 Neighbour Discovery (ND) processes ensure that this is true, just 583 as ND ensures that no two IPv6 nodes on the same IPv6 subnetwork 584 have the same IPv6 address at the same time. 586 Both the IEEE EUI-64 specification and the Modified EUI-64 syntax 587 also has a 'Group' bit [IEEE-EUI][RFC4291] For both ILNP node 588 Identifiers and also IPv6 Interface Identifiers, this Group bit 589 is set to 0. 591 3.1.3 Semantics 593 Unicast ILNP Identifier values name the node, rather than naming 594 a specific interface on that node. So ILNP Identifiers have 595 different semantics than IPv6 Interface Identifiers. 597 3.2 Locators 599 Locators are topologically-significant names, analogous to 600 (sub)network routing prefixes. The Locator names the IP 601 subnetwork that a node is connected to. ILNP neither prohibits 602 nor mandates in-transit modification of Locator values. 604 A host MAY have several Locators at the same time, for example 605 if it has a single network interface connected to multiple 606 subnetworks (e.g. VLAN deployments on wired Ethernet), or has 607 multiple interfaces each on a different subnetwork. Locator 608 values normally have Locator Precedence Indicator (LPI) values 609 associated with them. These LPIs indicate that a specific Locator 610 value has higher or lower precedence for use at a given 611 time. Local LPI values may be changed through local policy or via 612 management interfaces. Remote LPI values are normally learned 613 from the DNS, but the local copy of a remote LPI value might be 614 modified by local policy relating to preferred paths or prefixes. 616 Locator values are used only at the network-layer. Locators are 617 not used in end-to-end transport state. For example, Locators are 618 not used in transport-layer session state or application-layer 619 session state. However, this does not preclude an end-system 620 setting up local dynamic bindings for a single transport flow to 621 multiple Locator values concurrently. 623 The routing system only uses Locators, not Identifiers. For 624 unicast traffic, ILNP uses longest-prefix match routing, just as 625 the IP Internet does. 627 Section 4 below describes in more detail how Locators are used by 628 the forwarding and routing packets from a sending node on an 629 origin subnetwork to one or more receiving nodes on one or more 630 destination subnetworks. 632 A difference from earlier [GSE, 8+8] proposals is that, in normal 633 operation, the originating host supplies both Source Locator and 634 Destination Locator values in the packets it sends out. 636 Section 4.2 describes packet forwarding in more detail, while 637 Section 4.3 describes packet routing in more detail. 639 3.2.1 Locator Values are Dynamic 641 The ILNP architecture recognises that Locator values are 642 topologically significant, so the set of Locator values 643 associated with a node normally will need to change when the 644 node's connectivity to the Internet topology changes. For 645 example, a mobile or multi-homed node is likely to have 646 connectivity changes from time to time, along with the 647 corresponding changes to the set of Locator values. 649 When a node using a specific set of Locator values changes one 650 or more of those Locator values, then the node (1) needs to 651 update its local knowledge of its own Locator values, (2) needs 652 to inform all active Correspondent Nodes (CNs) of those changes 653 to its set of Locator values so that ILNP session continuity is 654 maintained, and (3) if it expects incoming connections the node 655 also needs to update its Locator related entries in the Domain 656 Name System. [ILNP-ENG] describes the engineering and 657 implementation details of this process. 659 3.2.2 Locator Updates 661 As Locator values can be dynamic, and they could change for a 662 node during an ILNP session, correspondents need to be notified 663 when a Locator value for a node changes for any existing ILNP 664 session. To enable this, a node that sees its Locator values 665 have changed MUST send a Locator Update (LU) message to its 666 correspondent nodes. The details of this procedure are discussed 667 in other ILNP documents [ILNP-ENG, ILNP-ICMPv6, ILNP-ICMPv4]. 668 (The change in Locator values may also need to be notified to DNS 669 but that is discussed elsewhere.) 671 3.2.3 Syntax 673 ILNP Locators have the same syntax as an IP unicast routing prefix. 675 3.2.4 Semantics 677 ILNP unicast Locators have the same semantics as an IP unicast 678 routing prefix, since they name a specific subnetwork. ILNP 679 neither prohibits nor requires in-transit modification of Locator 680 values. 682 3.3 IP Address and Identifier-Locator Vector (I-LV) 684 Historically, an IP Address has been considered to be an atomic 685 datum, even though it is recognised that an IP address has an 686 internal structure: the network prefix plus either the host ID 687 (IPv4) or the interface identifier (IPv6). However, this internal 688 structure has not been used in end-system protocols: instead all 689 the bits of the IP address are used. (Additionally, in IPv4 the 690 IPv4 sub-net mask uses bits from the host ID, a further confusion 691 of the structure, even thought it is an extremely useful 692 engineering mechanism.) 694 In ILNP, the IP address is replaced by an "Identifier-Locator 695 Vector" (I-LV). This consists of a pairing of an Identifier value 696 and a Locator value for that packet, written as [I, L]. All ILNP 697 packets have Source Identifier, Source Locator, Destination 698 Identifier, and Destination Locator values. The I value of the 699 I-LV is used by upper-layer protocols (e.g. TCP, UDP, SCTP), so 700 needs to be immutable. Locators are not used by upper-layer 701 protocols (e.g. TCP, UDP, SCTP). Instead, Locators are similar to 702 IP routing prefixes, and are only used to name a specific 703 subnetwork. 705 While it is possible to say that an I-LV is an approximation 706 to an IP address of today, it should be understood that 707 an I-LV: 709 a) is not an atomic datum, being a pairing of two data types, 710 an Identifier and a Locator. 712 b) has different semantics and properties to an IP address, 713 as is described in this document. 715 In our discussion, it will be convenient sometimes to refer to an 716 I-LV, but sometimes to refer only to an Identifier value, or only 717 to a Locator value. 719 ILNP packets always contain a source I-LV and a destination I-LV. 721 3.4 Notation 723 In describing how capabilities are implemented in ILNP, we will 724 consider the differences in end-systems state between IP and ILNP 725 in order to highlight the architectural changes. 727 We define a formal notation to represent the data contained in 728 the transport-layer session state. We define: 730 A = IP address 731 I = Identifier 732 L = Locator 733 P = Transport-layer port number 735 To differentiate the local and remote values for the above items, 736 we also use suffixes, for example: 738 _L = local 739 _R = remote 741 With IPv4 and IPv6 today, the invariant state at the 742 transport-layer for TCP can be represented by the tagged tuple: 744 --- (1) 746 Tag values that will be used are: 748 IP Internet Protocol 749 ILNP Identifier Locator Network Protocol 750 TCP Transmission Control Protocol 751 UDP User Datagram Protocol 753 So, for example, with IP, a UDP packet would have the 754 tagged tuple: 756 --- (2) 758 A TCP segment carried in an IP packet may be represented by the 759 tagged tuple binding: 761 --- (3) 763 and a UDP packet would have the tagged tuple binding: 765 --- (4) 767 In ILNP, the transport-layer state for TCP is: 769 --- (5) 771 The binding for a TCP segment within an ILNP packet: 773 --- (6) 775 When comparing tuple expressions (3) and (6), we see that for IP, 776 any change to network addresses impacts the end-to-end state, but 777 for ILNP, changes to Locator values do not impact end-to-end 778 state, providing end-system session state invariance, a key 779 feature of ILNP compared to IP as it is used in some situations 780 today. ILNP adopts the end-to-end approach for its architecture 781 [SRC84]. As noted previously, nodes MAY have more than one 782 Locator concurrently and nodes MAY change their set of active 783 Locator values as required. 785 While these documents don't include SCTP examples, the same 786 notation can be used, simply substituting the string SCTP for the 787 string TCP or the string UDP in the above examples. 789 3.5 Transport-layer state and transport pseudo-headers 791 In ILNP, protocols above the network-layer do not use the Locator 792 values. Thus, the transport-layer uses only the I values for the 793 transport-layer session state (e.g. TCP pseudo-header checksum, 794 UDP pseudo-header checksum), as is shown, for example, in 795 expression (6) above. 797 Additionally, again from a practical perspective, while the I 798 values are only used in protocols above the network-layer, it is 799 convenient for them to be carried in network packets, so that the 800 namespace for the I values can be used by any transport-layer 801 protocols operating above the common network-layer. 803 3.6 Rationale for this document 805 This document provides an architectural description of the core 806 ILNP capabilities and functions. It is based around the use of 807 example scenarios so that practical issues can be highlighted. 809 In some cases, illustrative suggestions and light 810 discussion are presented with respect to engineering issues, 811 but detailed discussion of engineering issues are deferred 812 to other ILNP documents. 814 The order of the examples presented below are intended 815 to allow an incremental technical understanding of ILNP 816 to be developed. There is no other reason for the ordering 817 of the examples listed below. 819 Many of the descriptions are based on the use of an example 820 site network as shown in Figure 2.1. 822 site . . . . +----+ 823 network . .-----+ CN | 824 . . . . +------+ . . +----+ 825 . . | +------. . 826 . D . | | . . 827 . .----+ SBR | . Internet . 828 . H . | | . . 829 . . | +------. . 830 . . . . +------+ . . 831 . . 832 . . . . 834 CN = Correspondent Node 835 D = Device 836 H = Host 837 SBR = Site Border Router 839 Figure 2.1: A simple site network for ILNP examples. 841 In some cases, hosts (H) or devices (D) act as end-systems 842 within the site network, and communicate with (one or more) 843 Correspondent Node (CN) instances that are beyond the site. 845 Note that the Figure is illustrative and presents a logical 846 view. For example, the CN may itself be on a site network, 847 just like H or D. 849 Also, for formulating examples, we assume ILNPv6 is in use, 850 which has the same packet header format (as viewed by 851 routers) as IPv6, and can be seen as a superset of IPv6 852 capabilities. 854 For simplicity, we assume that name resolution is via the 855 deployed DNS which has been updated to store DNS records 856 for ILNP [ILNP-DNS]. 858 Note that, from an engineering viewpoint, this does NOT mean 859 that the DNS also has to be ILNP capable: existing IPv4 or 860 IPv6 infrastructure can be used for DNS transport. 862 3.7 ILNP Multicasting 864 Multicast forwarding and routing are unchanged, in order to avoid 865 requiring changes in deployed IP routers and routing protocols. 866 ILNPv4 multicasting is the same as IETF standards-track IPv4 867 multicasting. ILNPv6 multicasting is the same as IETF 868 standards-track IPv6 multicasting. 870 4. ILNP BASIC CONNECTIVITY 872 In this section, we describe basic packet forwarding and routing 873 in ILNP. We highlight areas where it is similar to current IP, 874 and also where it is different from current IP. We use 875 examples in order to illustrate the intent and show the 876 feasibility of the approach. 878 For this section, in Figure 4.1, H is a fixed host in a simple 879 site network, CN is a remote Correspondent Node outside the site, 880 H and CN are ILNP-capable, while the Site Border Router (SBR) 881 does not need to be ILNP-capable. 883 site . . . . +----+ 884 network . .-----+ CN | 885 . . . . +------+ . . +----+ 886 . . | +------. . 887 . . | | . . 888 . .----+ SBR | . Internet . 889 . H . | | . . 890 . . | | . . 891 . . . . +------+ . . 892 . . 893 . . . . 895 CN = Correspondent Node 896 H = Host 897 SBR = Site Border Router 899 Figure 4.1: A simple site network for ILNP examples. 901 4.1 Basic Local Configuration 902 This section uses the term "Address management", in recognition 903 of the analogy with capabilities present in IP today. In this 904 document, address management is about enabling hosts to attach to 905 a subnetwork and enabling network-layer communication between and 906 among hosts, also including: 908 a) enabling identification of a node within a site. 909 b) allowing basic routing/forwarding from a node acting as 910 an end-system. 912 If we consider Figure 4.1, imagine that host H has been connected 913 to the site network. Administratively, it needs at least one I 914 value and one L value in order to be able to communicate. 916 Today, local administrative procedures allocate IP addresses, 917 often using various protocol mechanisms (e.g. NetConf-based 918 router configuration, DHCP for IPv4, DHCP for IPv6, IPv6 Router 919 Advertisements). Similarly, local administrative procedures can 920 allocate I and L values as required, e.g. I_H and L_H. This may 921 be through manual configuration. 923 Additionally, if it is expected or desired that H might have 924 incoming communication requests, e.g. it is a server, then the 925 values I_H and L_H can be added to the relevant name services 926 (e.g. DNS, NIS/YP), so that FQDN lookups for H resolve to the 927 appropriate DNS resource records (e.g. NID, L32, L64, and LP 928 [ILNP-DNS]) for node H. 930 From a network operations perspective, this whole process also 931 can be automated. As an example, consider that in Figure 3.1 the 932 Site Border Router (SBR) is an IPv6 capable router and is 933 connected via link1 to an ISP that supports IPv6. SBR will have 934 been allocated one (or more) IPv6 prefixes that it will multicast 935 using IPv6 Routing Advertisements (RAs) into the site network, 936 e.g. say prefix L_1. L_1 is actually a local IPv6 prefix (/64), 937 which is formed from an address assignment by the upstream ISP, 938 according to [RFC3177] or [RFC6177]. Host H will see these RAs, 939 for example, on its local interface with name eth0, will be able 940 to use that prefix as a Locator value, and will cache that 941 Locator value locally. 943 Also, node H can use the mechanism documented in either Section 944 2.5.1 of [RFC4291], in [RFC3972] [RFC4581] [RFC4982], or in 945 [RFC4941] in order to create a default I value, say I_H, just as 946 an IPv6 host can. For DNS, the I_H and L_1 values may be 947 pre-configured in DNS by an administrator who already has 948 knowledge of these, or added to DNS by H using Secure DNS Dynamic 949 Update [RFC3007] to add or update the correct NID and L64 records 950 to DNS for the FQDN for H. 952 4.2 I-L Communication Cache 954 For the purposes of explaining the concept of operations, we talk 955 of a local I-L Communication Cache (ILCC). This is an engineering 956 convenience and does not form part of the ILNP architecture, but 957 is used in our examples. More details on the ILCC can be found in 958 [ILNP-ENG]. The ILCC contains information that is required for 959 the operation of ILNP. This will include, amongst other things, 960 the current set of valid Identifier and Locator values in use by 961 a node, the bindings between them and the bindings between 962 Locator values and interfaces. 964 4.3 Packet Forwarding 966 When the SBR needs to send a packet to H, it uses local address 967 resolution mechanisms to discover the bindings between interface 968 addresses and currently active I-LVs for H. For our example of 969 Figure 3.1, IPv6 Neighbour Discovery (ND) can be used without 970 modification, as the I-LV for ILNPv6 occupies the same bits as 971 the IPv6 address in the IPv6 header. For packets from H to SBR, 972 the same basic mechanism applies, as long as SBR supports IPv6 973 and even if it is not ILNPv6-capable, as IPv6 ND is used 974 unmodified for ILNPv6. 976 For Figure 3.1, assuming: 978 - SBR advertises prefix L_1 locally, uses I value I_S, and has 979 an Ethernet MAC address M_S on interface with local name sbr0 981 - H uses I value I_H, and has an ethernet MAC address of M_H on 982 the interface with local name eth0 984 then H will have in its ILCC: 986 [I_H, L_1] --- (7a) 987 L_1, eth0 --- (7b) 989 After the IPv6 RA and ND mechanism has executed, the ILCC at H 990 would contain, as well as (7a) and (7b), the following entry for 991 SBR: 993 [I_S ,L_1], M_S --- (8) 995 For ILNPv6, it does not matter that the SBR is not ILNPv6 996 capable, as the I-LV [I_S, L_1] is physically equivalent to the 997 IPv6 address for the internal interface sbr0. 999 At SBR, which is not ILNP-capable, there would be the following 1000 entries in its local cache and configuration: 1002 L_1:I_S --- (9a) 1003 L_1, sbr0 --- (9b) 1005 Expression (9a) represents a valid IPv6 ND entry: in this case, 1006 the I_S value (which is 64 bits in ILNPv6) and the L_1 values 1007 are, effectively, concatenated and treated as if they were a 1008 single IPv6 address. Expression (9b) binds transmissions for L_1 1009 to interface sbr0 (again, sbr0 is a local, implementation- 1010 specific name, and such a binding is possible with standard tools 1011 today, for example ifconfig(8)). 1013 4.4 Packet Routing 1015 If we assume that host H is configured as in the previous 1016 section, it is now ready to send and receive ILNP packets. 1018 Let us assume that, for Figure 3.1, it wishes to contact the 1019 node CN, which has FQDN cn.example.com and is ILNP-capable. 1020 A DNS query by H for cn.example.com will result in NID and L64 1021 records for CN, with values I_CN and L_CN, respectively, 1022 being returned to H, and stored in its ILCC: 1024 [I_CN, L_CN] --- (10) 1026 This will be considered active, as long as the TTL values for the 1027 DNS records are valid. If the TTL for an I or L value is zero, 1028 then the value is still useable but becomes stale as soon as it 1029 has been used once. However, it is more likely that the TTL value 1030 will be greater than zero [BA11] [SBK01]. 1032 Once the CN's I value is known, the upper layer protocol, e.g. 1033 the transport protocol, can set up suitable transport-layer 1034 session state: 1036 --- (11) 1038 For routing of ILNP packets, the destination L value in an ILNPv6 1039 packet header is semantically equivalent to a routing prefix. 1040 So, once a packet has been forwarded from a host to its first-hop 1041 router, only the destination L value needs to be used for getting 1042 the packet to the destination network. Once the packet has 1043 arrived at the router for the site network, local mechanisms and 1044 packet forwarding mechanism, as described above in Section 4.3, 1045 allow the packet to be delivered to the host. 1047 For our example of Figure 4.1, H will send a UDP packet 1048 over ILNP as: 1050 --- (12a) 1052 and CN will send UDP packets to H as: 1054 --- (12b) 1056 The I value for H used in the transport-layer state (I_H in 1057 expression (12a)) selects the correct L value (L_1 in this case) 1058 from the bindings in the ILCC (expression (7a)), and that, in 1059 turn, selects the correct interface from the ILCC (expression 1060 (7b)), as described in Sec 4.2. This gets the packet to the first 1061 hop router, and beyond that, the ILNPv6 packet is treated as if 1062 it were an IPv6 packet. 1064 5.0 MULTI-HOMING AND MULTI-PATH TRANSPORT 1066 For multi-homing, there are three cases to consider: 1068 a) Host Multi-Homing (H-MH): a single host is, individually, 1069 connected to multiple upstream links, via separate routing 1070 paths, and those multiple paths are used by that host as it 1071 wishes. That is, use of multiple upstream links is managed 1072 by the single host itself. For example, the host might have 1073 multiple valid Locator values on a single interface, with 1074 each Locator value being associated with a different 1075 upstream link (provider). 1077 b) Multi-Path Transport (MPT): This is similar to using 1078 ILNP's support for host multi-homing (i.e. H-MH), 1079 so we describe multi-path transport here. (Indeed, 1080 for ILNP, this can be considered a special case of H-MH.) 1082 c) Site Multi-Homing (S-MH): a site network is connected to 1083 multiple upstream links via separate routing paths, and hosts 1084 on the site are not necessarily aware of the multiple 1085 upstream paths. That is, the multiple upstream paths are 1086 managed, typically, through a site-border router, or via the 1087 providers. 1089 Essentially, for ILNP, multi-homing is implemented by enabling: 1091 a) multiple Locator values to be used simultaneously by a node 1093 b) dynamic, simultaneous binding between one (or more) 1094 Identifier value(s) and multiple Locator values 1096 With respect to the requirements for hosts [RFC1122], the multi- 1097 homing function provided by ILNP is very flexible. It is not 1098 useful to discuss ILNP multi-homing strictly within the confines 1099 of the exposition presented in Section 3.3.4 of [RFC1122], as 1100 that text is couched in terms of relationships between IP 1101 addresses and interfaces, which can be dynamic in ILNP. The 1102 closest relationship between ILNP multi-homing and [RFC1122] 1103 would be that certainly ILNP could support the notion of 1104 "Multiple Logical Networks", "Multiple Logical Hosts" and "Simple 1105 Multihoming". 1107 5.1 Host Multi-Homing (H-MH) 1109 At present, host multi-homing is not common in the deployed 1110 Internet. When TCP or UDP are in use with an IP-based 1111 network-layer session, host multi-homing cannot provide session 1112 resilience, because the transport protocol's pseudo-header 1113 checksum binds the transport-layer session to a single IP address 1114 of the multi-homed node, and hence to a single interface of that 1115 node. SCTP has a protocol-specific mechanism to support node 1116 multi-homing; SCTP can support session resilience both at present 1117 and also without change in the proposed approach [RFC5061]. 1119 Host multi-homing in ILNP is supported directly in each host by 1120 ILNP. The simplest explanation of H-MH for ILNP is that an 1121 ILNP-capable host can simultaneously use multiple Locator values, 1122 for example by having a binding between an I value and two 1123 different L values, e.g. the ILCC may contain the I-LVs: 1125 [I_1, L_1] --- (14a) 1126 [I_1, L_2] --- (14b) 1128 Additionally, a host may use several I values concurrently, 1129 e.g. the ILCC may contain the I-LVs: 1131 [I_1, L_1] --- (15a) 1132 [I_1, L_2] --- (15b) 1133 [I_2, L_2] --- (15c) 1134 [I_3, L_1] --- (15d) 1136 Architecturally, ILNP considers these all to be cases of 1137 multi-homing: the host is connected to more than one 1138 subnetwork, each subnetwork being named by a different 1139 Locator value. 1141 In the cases above, the selection of which I-LV to use 1142 would be through local policy or through management 1143 mechanisms. Additionally, suitably modified transport-layer 1144 protocols, such as multi-path transport-layer protocol 1145 implementations, may make use of multiple I-LVs. Note that 1146 in such a case, the way in which multiple I-LVs are used 1147 would be under the control of the higher-layer protocol. 1149 Recall, however, that L values also have precedence - LPI 1150 values - and these LPI values can be used at the network-layer, 1151 or by a transport-layer protocol implementation, in order 1152 make use of L values in a specific manner. 1154 Note that, from a practical perspective, ILNP dynamically binds 1155 L values to interfaces on a node to indicate the SNPA for that 1156 L value, so the multi-homing is very flexible: a node could have 1157 a single interface and have multiple L values bound to that 1158 interface. For example, for expressions (14a) and (14b) if the 1159 end-system has a single interface with local name eth0, then the 1160 entries in the ILCC will be: 1162 L_1, eth0 --- (16a) 1163 L_2, eth0 --- (16b) 1165 and if we assume that for expressions (15a-c), the end-system 1166 has two interfaces, eth0 and eth1, then these ILCC entries 1167 are possible: 1169 L_1, eth0 --- (17a) 1170 L_2, eth1 --- (17b) 1172 Let us consider the network in Figure 5.1. 1174 site . . . . 1175 network . . 1176 . . . . +------+ L_1 . . 1177 . . | +------. . 1178 . . | | . . 1179 . .----+ SBR | . Internet . 1180 . . | | . . 1181 . H . | +------. . 1182 . . . . +------+ L_2 . . 1183 . . 1184 . . . . 1186 L_1 = global Locator value 1 1187 L_2 = global Locator value 2 1188 SBR = Site Border Router 1190 Figure 5.1: A simple multi-homing scenario for ILNP. 1192 We assume that H has a single interface, eth0. SBR will advertise 1193 L_1 and L_2 internally to the site. Host H will configure these 1194 as both reachable via its single interface, eth0, by using ILCC 1195 entries as in expressions (16a) and (16b). When packets from H 1196 that are to egress the site network reach SBR, it can make 1197 appropriate decisions on which link to use based on the source 1198 Locator value (which has been inserted by H), or based on other 1199 local policy. 1201 If, however, H has two interfaces, eth0 and eth1, then it can use 1202 ILCC entries as in expressions (17a) and (17b). 1204 Note that the values L_1 and L_2 do not need to be PI based 1205 Locator values, and can be taken from ISP-specific PA routing 1206 prefix allocations from the upstream ISPs providing the two 1207 links. 1209 Of course, this example is illustrative: many other 1210 configurations are also possible, but the fundamental mechanism 1211 remains the same, as described above. 1213 If any Locator values change then H will discover this when it 1214 sees new Locator values in RAs from SBR, and sees that L values 1215 that were previously used are no longer advertised. When this 1216 happens, H will: 1218 a) maintain existing active network-layer sessions: based on 1219 its current ILCC entries and active sessions, send Locator 1220 Update (LU) messages to CNs to notify them of the change of 1221 L values. (LU messages are synonymous to Mobile IPv6 Binding 1222 Updates.) 1224 b) if required, update its relevant DNS entries with the new L 1225 value in the appropriate DNS records, to enable correct 1226 resolution for new incoming session requests. 1228 From an engineering view point, H also updates its ILCC data, 1229 removing the old L value(s) and replacing with new L value(s) as 1230 required. 1232 Depending on the nature of the physical change in connectivity 1233 that the L value change represents, this may disrupt upper-level 1234 protocols, e.g. a fibre cut. Dealing with such physical-level 1235 disruption is beyond the scope of ILNP. However, ILNP supports 1236 graceful changes in L values, and this is explained below in 1237 Section 6 in the discussion on mobility support. 1239 5.2 Support for Multi-Path Transport Protocols (MPTs) 1241 ILNP supports deployment and use of multi-path transport 1242 protocols, such as the Multi-Path extensions to TCP (MP-TCP) 1243 being defined by the IETF TCPM Working Group. Specifically, ILNP 1244 will support the use of multiple paths as it allows a single I 1245 value to be bound to multiple L values - see Sec 5.1 and 1246 specifically expressions (15a) and (15b). 1248 Of course, there will be specific mechanisms for: 1249 - congestion control 1250 - signalling for connection/session management 1251 - path discovery and path management 1252 - engineering and implementation issues 1254 These transport-layer mechanisms fall outside the scope of ILNP 1255 and would be defined in the multi-path transport protocol 1256 specifications. 1258 As far as the ILNP architecture is concerned, the transport 1259 protocol connection is simply using multiple I-LVs, but with the 1260 same I value in each, and different L values, i.e. a multi-homed 1261 host. 1263 5.3 Site multi-homing (S-MH) 1265 At present, site multi-homing is common in the deployed 1266 Internet. This is primarily achieved by advertising the site's 1267 routing prefix(es) to more than one upstream Internet service 1268 provider at a given time. In turn, this requires de-aggregation 1269 of routing prefixes within the inter-domain routing system. This 1270 increases the entropy of the inter-domain routing system 1271 (e.g. RIB/FIB size increases beyond the minimal RIB/FIB size that 1272 would be required to reach all sites). 1274 Site multi-homing, in its simplest form in ILNP, is an extension 1275 of the H-MH scenario described in Sec 5.1. If we consider Figure 1276 5.1 and assume that there are many hosts in the site network, 1277 each can choose to manage its own ILNP connectivity and whether 1278 or not multiple Locator values are used. This allows maximal 1279 control of connectivity for each host. 1281 Of course, with ILNPv6, just as any IPv6 router is required to 1282 generate IPv6 Router Advertisement messages with the correct 1283 routing prefix information for the link the RA is advertised 1284 upon, thus also the SBR is required to generate RAs containing 1285 the correct Locator value(s) for the link that the RA is 1286 advertised upon. The correct values for these RA messages are 1287 typically configured by system administration, or might be passed 1288 down from the upstream provider. 1290 To avoid a DNS Update burst when a site or (sub)network changes 1291 location, a DNS record optimisation is possible by using the new 1292 LP record for ILNP. This would change the number of DNS Updates 1293 required from Order(Number of nodes within the site/subnetwork 1294 that moved) to Order(1) [ILNP-DNS]. 1296 5.3.1 A common multi-homing scenario - multiple SBRs 1298 The scenario of Fig 5.1 is an example to illustrate the 1299 architectural operation of multi-homing for ILNP. For site multi- 1300 homing, a scenario such as the one depicted in Figure 5.2 is also 1301 common. Here, there are two SBRs, each with its own global 1302 connectivity. 1304 site . . . . 1305 network . . 1306 . . . . +-------+ L_1 . . 1307 . . | +------. . 1308 . . | | . . 1309 . .---+ SBR_A | . . 1310 . . | | . . 1311 . . | | . . 1312 . . +-------+ . . 1313 . . ^ . . 1314 . . | CP . Internet . 1315 . . v . . 1316 . . +-------+ L_2 . . 1317 . . | +------. . 1318 . . | | . . 1319 . .---+ SBR_B | . . 1320 . . | | . . 1321 . . | | . . 1322 . . . . +-------+ . . 1323 . . 1324 . . . . 1326 CP = coordination protocol 1327 L_1 = global Locator value 1 1328 L_2 = global Locator value 2 1329 SBR_A = Site Border Router A 1330 SBR_B = Site Border Router P 1332 Figure 5.2: A dual-router multi-homing scenario for ILNP. 1334 The use of two physical routers provides an extra level of 1335 resilience compared to the scenario of Fig 5.1. The coordination 1336 protocol (CP) between the two routers keeps their actions in 1337 synchronisation according to whatever management policy is in 1338 place for the site network. Such capabilities are available today 1339 in products. Note that, logically, there is little difference 1340 between Fig 5.1 and Fig 5.2, but with two distinct routers in Fig 1341 5.2, the interaction using CP is required. Of course, it is also 1342 possible to have multiple interfaces in each router and more than 1343 two routers. 1345 5.4 Multi-Homing Requirements for Site Border Routers 1347 For multi-homing, the SBR does NOT need to be ILNP-capable for 1348 Host Multi-Homing or Site Multi-Homing. This is true provided the 1349 multi-homing is left to individual hosts as described above. In 1350 this deployment approach, the SBR need only issue Routing 1351 Advertisements (RAs) that are correct with respect to its 1352 upstream connectivity; that is, the SBR properly advertises 1353 routing prefixes (Locator values) to the ILNP hosts. 1355 In such a scenario, when hosts in the site network see new 1356 Locator values, and see that a previous Locator value is no 1357 longer being advertised, those hosts can update their ILCCs, 1358 send Locator Updates to CNs, and change connectivity 1359 as required. 1361 6. MOBILITY 1363 ILNP supports mobility directly, rather than relying upon 1364 special-purpose mobility extensions as is the case both with IPv4 1365 [RFC-2002] and also with IPv6 [RFC6275]. 1367 There are two different mobility cases to consider: 1369 a) Host Mobility: individual hosts may be mobile, moving across 1370 administrative boundaries or topological boundaries within 1371 an IP-based network, or across the Internet. Such hosts 1372 would need to independently manage their own mobility. 1374 b) Network (Site) Mobility: a whole site, i.e. one (or more) IP 1375 subnetwork(s) may be mobile, moving across administrative 1376 boundaries or topological boundaries within an IP-based 1377 network, or across the Internet. The site as a whole needs 1378 to maintain consistency in connectivity. 1380 Essentially, for ILNP, mobility is implemented by enabling: 1382 a) Locator values to be changed dynamically by a node, 1383 including for active network-layer sessions. 1385 b) use of Locator Updates to allow active network-layer 1386 sessions to be maintained. 1388 c) for those hosts that expect incoming network-layer or 1389 transport-layer session requests (e.g., servers), updates 1390 to the relevant DNS entries for those hosts. 1392 It is possible that a device is both a mobile host and part of a 1393 mobile network, e.g. a smartphone in a mobile site network. This 1394 is supported in ILNP as the mechanism for mobile hosts and mobile 1395 networks are very similar and work in harmony. 1397 For mobility, there are two general features that must be 1398 supported: 1400 a) Handover (or Hand-off): when a host changes its connectivity 1401 (e.g. it has a new SNPA as it moves to a new ILNP 1402 subnetwork), any active network-layer sessions for that host 1403 must be maintained with minimal disruption 1404 (i.e. transparently) to the upper layer protocols. 1406 b) Rendezvous: when a host that expects incoming network-layer 1407 or transport-layer session requests has new connectivity 1408 (e.g. it has a new SNPA as it moves to a new ILNP 1409 subnetwork), it needs to update its relevant DNS entries so 1410 that name resolution will provide the correct I and L values 1411 to remote nodes. 1413 6.1 Mobility/multi-homing duality in ILNP 1415 Mobility and multi-homing present the same set of issues for 1416 ILNP. Indeed, mobility and multi-homing form a duality: the set 1417 of Locators associated with a node or site changes. The reason 1418 for the change might be different for the case of mobility and 1419 multi-homing, but the effects on the network-layer session state 1420 and on correspondents is identical. 1422 With ILNP, mobility and multi-homing are supported using a common 1423 set of mechanisms. In both cases, different Locator values are 1424 used to identify different IP subnetworks. Also, ILNP nodes that 1425 expect incoming network-layer or transport-layer session requests 1426 are assumed to have a Fully Qualified Domain Name (FQDN) stored 1427 in the Domain Name System (DNS), as is already done within the 1428 deployed Internet. ILNP mobility normally relies upon the Secure 1429 Dynamic DNS Update standard for mobile nodes to update their 1430 location information in the DNS. This approach of using DNS for 1431 rendezvous with mobile systems was proposed earlier by others 1432 [PHG02]. 1434 Host Mobility considers individual hosts that are individually 1435 mobile, for example a mobile telephone carried by a person 1436 walking in a city. Network (Site) Mobility considers a group of 1437 hosts within a local topology that move jointly and periodically 1438 change their uplinks to the rest of the Internet, for example a 1439 ship that has wired connections internally but one or more 1440 wireless uplinks to the rest of the Internet. 1442 For ILNP, Host Mobility is analogous to Host Multi-homing (H-MH) 1443 and Network Mobility is analogous to Site Multi-homing 1444 (S-MH). So, mobility and multi-homing capabilities can be used 1445 together, without conflict. 1447 6.2 Host Mobility 1449 With host mobility, each individual end-system manages its own 1450 connectivity through the use of Locator values. (This is very 1451 similar to the situation described for H-MH in Sec 5.1.) 1453 Let us consider the network in Figure 6.1. 1455 site . . . . 1456 network A . . 1457 . . . . +-------+ L_A . . 1458 . . | +------. . 1459 . . | | . . 1460 . .---+ SBR_A | . . 1461 . . | | . . 1462 . H(1) . | | . . 1463 . . +-------+ . . 1464 . . . . . . . . 1465 . H(2) . . Internet . 1466 . . . . . . . . 1467 . . +-------+ L_B . . 1468 . H(3) . | +------. . 1469 . . | | . . 1471 . .---+ SBR_B | . . 1472 . . | | . . 1473 . . | | . . 1474 . . . . +-------+ . . 1475 site . . 1476 network B . . . . 1478 H(X) = host H at position X 1479 L_A = global Locator value A 1480 L_B = global Locator value B 1481 SBR = Site Border Router 1483 Figure 6.1: A simple mobile host scenario for ILNP. 1485 A host, H is at position (1), hence H(1), in a site network 1486 A. This site network might be, for example, a single radio-cell 1487 under administrative domain A. We assume that the host will move 1488 into site network B, which might be a single radio-cell under 1489 administrative domain B. We also assume that the site networks 1490 have a region of overlap so that connectivity can be maintained, 1491 else, of course, the host will loose connectivity. Also, let us 1492 assume that the host already has ILNP connectivity in site 1493 network A. 1495 If site network A has connectivity via Locator value L_A, and H 1496 uses Identifier value I_H with a single interface ra0, then the 1497 host's ILCC will contain: 1499 [I_H, L_A] --- (18a) 1500 L_A, ra0 --- (18b) 1502 Note the equivalence of expressions (18a) and (18b), 1503 respectively, with the expressions (15a) and (16a) 1504 for host multi-homing. 1506 The host now moves into the overlap region of site networks A and 1507 B, and has position (2), H(2) as indicated in Fig 6.1. As this 1508 region is now in site network B, as well as site network A, H 1509 should see RAs from SBR_B for L_B, as well as the RAs for L_A 1510 from SBR_A. The host can now start to use L_B for its 1511 connectivity. The host H must now: 1513 a) maintain existing active upper-layer sessions: based on its 1514 current ILCC entries and active sessions, send Locator 1515 Update (LU) messages to CNs to notify them of the change of 1516 L values. (LU messages are synonymous to Mobile IPv6 Binding 1517 Updates.) 1519 b) if required, update its relevant DNS entries with the new L 1520 value in the appropriate DNS records, to enable correct 1521 resolution for new incoming network-layer or transport-layer 1522 session requests. 1524 However, it can opt to do this one of two ways: 1526 1) immediate handover: the host sends Locator Update (LU) 1527 messages to CNs, immediately stops using L_A and switches 1528 to using L_B only. In this case, its ILCC entries 1529 change to: 1531 [I_H, L_B] --- (19a) 1532 L_B, ra0 --- (19b) 1534 There might be packets in flight to H which use L_A and H 1535 MAY choose to ignore these on reception. 1537 2) soft handover: the host sends Locator Update (LU) messages 1538 to CNS, but it uses both L_A and L_B until (i) it no longer 1539 receives incoming packets with destination Locator values 1540 set to L_A within a given time period (ii) it no longer sees 1541 RAs for L_A (i.e. it has left the overlap region and so has 1542 left site network A). In this case, its ILCC entries change 1543 to: 1545 [I_H, L_A] --- (20a) 1546 L_A, ra0 --- (20b) 1547 [I_H, L_B] --- (20c) 1548 L_B, ra0 --- (20d) 1550 ILNP does not mandate the use of one handover option over 1551 another. Indeed, a host may implement both and decide, through 1552 local policy or other mechanisms (e.g. under the control of a 1553 particular transport protocol implementation), to use one or 1554 other for a specific transport-layer session, as required. 1556 Note that if using soft handover, when in the overlap region 1557 the host is multi-homed. Also, soft handover is likely to 1558 provide a less disruptive handover (e.g. lower packet loss) 1559 compared to immediate handover, all other things being equal. 1561 There is a case where both the host and its correspondent node 1562 are mobile. In the unlikely event of simultaneous motion which 1563 changes both nodes' Locators within a very small time period, 1564 there is the possibility that communication may be lost. If the 1565 communication between the nodes was direct (i.e. one node 1566 initiated communication with another, through a DNS lookup) 1567 a node can use the DNS to discover the new Locator value(s) for 1568 the other node. If the communication was through some sort of 1569 middlebox providing a relay service, then communication is more 1570 likely to disrupted only if the middlebox is also mobile. 1572 It is also possible that high packet loss results in Locator 1573 Updates being lost, which could disrupt handover. However, this 1574 is an engineering issue and does not impact the basic concept of 1575 operation: additional discussion on this issue is provided in 1576 [ILNP-ENG]. 1578 Of course, for any handover, the new end-to-end path through 1579 SBR_B might have very different end-to-end path characteristics 1580 (e.g. different end-to-end delay, packet-loss, 1581 throughput). Also, the physical connectivity on interface ra0 1582 as well as through SBR_B's uplink may be different. Such impact 1583 on end-to-end packet transfer are outside the scope of ILNP. 1585 6.3 Network Mobility 1587 For network mobility, a whole site may be mobile, e.g. the SBRs 1588 of Figure 6.1 has a radio uplink on a moving vehicle. Within the 1589 site, individual hosts may or may not be mobile. 1591 In the simplest case, ILNP deals with mobile networks in the 1592 same way as for site multi-homing: the management of mobility 1593 is delegated to each host in the site, so it needs to be 1594 ILNP-capable. Each host, effectively, behaves as if it was a 1595 mobile host, even though it may not actually be mobile. Indeed, 1596 in this way, the mechanism is very similar to that for site 1597 multi-homing. 1599 Let us consider the mobile network in Figure 6.2. 1601 site ISP_1 1602 network SBR . . . 1603 . . . . +------+ L_1 . . 1604 . . | ra1+------. . 1605 . .----+ | . . 1606 . H . | ra2+-- . . 1607 . . . . +------+ . . 1608 . . . 1610 Figure 6.2a: ILNP mobile network before handover. 1612 site ISP_1 1613 network SBR . . . 1615 . . . . +------+ L_1 . . 1616 . . | ra1+------. . . . . 1617 . .----+ | . . 1618 . H . | ra2+------. . 1619 . . . . +------+ L_2 . . . . . 1620 . . 1621 . . . 1622 ISP_2 1624 Figure 6.2b: ILNP mobile network during handover. 1626 site ISP_2 1627 network SBR . . . 1628 . . . . +------+ . . 1629 . . | ra1+-- . . 1630 . .----+ | . . 1631 . H . | ra2+------. . 1632 . . . . +------+ . . 1633 . . . 1635 Figure 6.2c: ILNP mobile network after handover. 1637 H = host 1638 L_1 = global Locator value 1 1639 L_2 = global Locator value 2 1640 SBR = Site Border Router 1642 Figure 6.2: A simple mobile network scenario for ILNP. 1644 In Figure 6.2, we assume that the site network is mobile, 1645 and the SBR has two radio interfaces ra1 and ra2. However, 1646 this particular figure is chosen for simplicity and clarity 1647 for our scenario, and other configurations are possible, 1648 e.g. a single radio interface which uses separate radio 1649 channels (separate carriers, coding channels, etc.) In the 1650 figure, ISP_1 and ISP_2 are separate, radio-based service 1651 providers, accessible via ra1 and ra2. 1653 In Fig 6.2a, the SBR has connectivity via ISP_1 using Locator 1654 value L_1. The host H, with interface ra0 and Identifier I_H, 1655 has an established connectivity via the SBR and so has ILCC 1656 entries as shown in (21): 1658 [I_H, L_1] --- (21a) 1659 L_1, ra0 --- (21b) 1661 Note the equivalence to expressions (18a) and (18b). As the whole 1662 network moves, the SBR detects a new radio provider, ISP_2, and 1663 connects to it using ra2, as shown in Figure 6.2b, with the 1664 service areas of ISP_1 and ISP_2 overlapping. ISP_2 provides 1665 Locator L_2, which SBR advertises into the site network along 1666 with L_1. As with the mobile host scenario above, individual 1667 hosts may decide to perform immediate handover or soft 1668 handover. So, the ILCC state for H will be as for expressions 1669 (19a,b) and (20a,b,c,d), but with L_1 in place of L_A and L_2 in 1670 place of L_B. Finally, as in Figure 6.2c, the site network moves 1671 and is no longer served by ISP_1, and handover is complete. Note 1672 that during the handover the site is multi-homed, as in Figure 1673 6.2b. 1675 6.4 Mobility Requirements for Site Border Routers 1677 As for multi-homing, the SBR does NOT need to be ILNP-capable: 1678 it simply needs to advertise the available routing prefixes 1679 into the site network. The mobility capability is handled 1680 completely by the hosts. 1682 6.5 Mobility with multiple SBRs 1684 Just as Section 5.3.1 describes the use of multiple routers for 1685 multi-homing, so it is possible to have multiple routers for 1686 mobility for ILNP, for both mobile hosts and mobile networks. 1688 7. IP SECURITY FOR ILNP 1690 IP Security for ILNP [ILNP-ENG] becomes simpler, in principle, 1691 than IP Security as it is today, based on the use of IP addresses 1692 as Identifiers. 1694 An operational issue in the deployed IP Internet is that the IP 1695 Security protocols, AH and ESP, have Security Associations (IPsec 1696 SAs) that include the IP addresses of the secure IPsec session 1697 endpoints. This was understood to be a problem when AH and ESP 1698 were originally defined [RFC-1825, RFC-1826, RFC-1827] However, 1699 the limited set of namespaces in the Internet Architecture did 1700 not provide any better choices at that time. ILNP provides more 1701 namespaces, thus now enabling better IPsec architecture and 1702 engineering. 1704 7.1 Adapting IP Security for ILNP 1706 In essence, ILNP provides a very simple architectural change to 1707 IP security: in place of IP addresses as used today for IPsec 1708 SAs, ILNP uses Node Identifier values instead for its IPsec 1709 SAs. Recall that Identifier values are immutable once in use, 1710 so they can be used to maintain end-to-end state for any protocol 1711 that requires it. Note from the discussion above that the 1712 Identifier values for a host remain unchanged when multi-homing 1713 and mobility is in use, so IP security using ILNP can work in 1714 harmony with multi-homing and mobility [ABH08b] [ABH09a]. 1716 To resolve the issue of IPsec interoperability through a Network 1717 Address Translator (NAT) deployment [RFC1631] [RFC3022], UDP 1718 encapsulation of IPsec [RFC3948] is commonly used as of the date 1719 this document was published. This special-case handling for 1720 IPsec traffic traversing a NAT is not needed with ILNP IPsec. 1722 Further, it would obviate the need for specialised IPsec NAT 1723 Traversal mechanisms, thus simplifying IPsec implementations 1724 while enhancing deployability and interoperability [RFC3948]. 1726 This architectural change does not reduce the security provided 1727 by the IP Security protocols. In fact, had the Node Identifer 1728 namespace existed back in the early 1990s, IP Security would 1729 always have bound to that location-independent Node Identifier 1730 and would not have bound to IP Addresses. 1732 7.2 Operational use of IP Security with ILNP 1734 Operationally, this change in SA bindings to use Identifiers 1735 rather than IP addresses causes problems for the use of the IPsec 1736 protocols through IP Network Address Translation (NAT) devices, 1737 with mobile nodes (because the mobile node's IP address changes 1738 at each network-layer handoff), and with multi-homed nodes 1739 (because the network-layer IPsec session is bound to a particular 1740 interface of the multi-homed node, rather than being bound to the 1741 node itself) [RFC3027] [RFC3715]. 1743 8. BACKWARDS COMPATIBILITY & INCREMENTAL DEPLOYMENT 1745 ILNPv6 is fully backwards compatible with existing IPv6. No 1746 router software or silicon changes are necessary to support the 1747 proposed enhancements. An IPv6 router would be unaware whether 1748 the packet being forwarded were classic IPv6 or the proposed 1749 enhancement in ILNPv6. IPv6 Neighbour Discovery will work 1750 unchanged for ILNPv6. ILNPv6 multicasting is the same as IETF 1751 standards-track IPv6 multicasting. 1753 ILNPv4 is backwards compatible with existing IPv4. As the IPv4 1754 address fields are used as 32-bit Locators, using only the 1755 address prefix bits of the the 32-bit space, IPv4 routers also 1756 would not require changes. An IPv4 router would be unaware 1757 whether the packet being forwarded were classic IPv4 or the 1758 proposed enhancement in ILNPv4 [ILNP-V4OPTS]. ARP [RFC826] 1759 requires enhancements to support ILNPv4 [ILNP-ARP] [ILNP-ENG]. 1760 ILNPv4 multicasting is the same as IETF standards-track IPv4 1761 multicasting. 1763 If a node supports ILNP, and intends to receive incoming 1764 network-layer or transport-layer sessions, the node's 1765 Fully-Qualified Domain Name (FQDN) normally will have one or more 1766 NID records and one or more Locator (i.e. L32, L64, and/or LP) 1767 records associated with the node within the DNS [ILNP-ENG] 1768 [ILNP-DNS]. 1770 When an IP host ("initiator") initiates a new network-layer 1771 session with a correspondent ("responder"), it normally will 1772 perform a DNS lookup to determine the address(es) of the 1773 responder. An ILNP host normally will look for Node Identifier 1774 ("NID") and Locator (i.e. L32, L64, and LP) records in any 1775 received DNS replies. DNS servers that support NID and Locator 1776 (i.e. L32, L64, and LP) records SHOULD include them (when they 1777 exist) as additional data in all DNS replies to queries for DNS 1778 AAAA records [ILNP-DNS]. 1780 If the initiator supports ILNP, and from DNS information learns 1781 that the responder also supports ILNP, then the initiator will 1782 generate an unpredictable ILNP Nonce value, cache that value 1783 locally as part of the network-layer ILNP session, and will 1784 include the ILNP Nonce value in its initial packet(s) to the 1785 responder [ILNP-ENG] [ILNP-NONCEv6] [ILNP-V4OPTS]. 1787 If the initiator node does not find any ILNP-specific DNS 1788 resource records for the responder node, then the initiator uses 1789 classic IP for the new network-layer session with the responder, 1790 rather than trying to use ILNP for that network-layer session. Of 1791 course, multiple transport-layer sessions can concurrently share 1792 a single network-layer (e.g. IP or ILNP) session. 1794 If the responder node for a new network-layer session does not 1795 support ILNP and the responder node receives initial packet(s) 1796 containing the ILNP Nonce, then the responder will drop the 1797 packet and send an ICMP error message back to the initiator. If 1798 the responder node for a new network-layer session supports ILNP 1799 and receives initial packet(s) containing the ILNP Nonce, the 1800 responder learns that ILNP is in use for that network-layer 1801 session (i.e. by the presence of that ILNP Nonce). 1803 If the initiator node using ILNP does not receive a response from 1804 the responder in a timely manner (e.g. within TCP timeout for a 1805 TCP session) and also does not receive an ICMP Unreachable error 1806 message for that packet, OR if the initiator receives an ICMP 1807 Parameter Problem error message for that packet, then the 1808 initiator concludes that the responder does not support ILNP. In 1809 this case, the initiator node SHOULD try again to create the new 1810 network-layer session, but this time using IP (and therefore 1811 omitting the ILNP Nonce). 1813 Finally, since an ILNP node also is a fully-capable IP node, then 1814 the upgraded node can use any standardised IP mechanisms for 1815 communicating with a legacy IP-only node. So ILNP will not be 1816 worse than existing IP, but when ILNP is used the enhanced 1817 capabilities described in these ILNP documents will be available. 1819 9. SECURITY CONSIDERATIONS 1821 This proposal outlines a proposed evolution for the Internet 1822 Architecture to provide improved capabilities. This section 1823 discusses security considerations for this proposal. 1825 Note that ILNP provides security equivalent to IP for similar 1826 threats when similar mitigations (e.g. IPsec or not) are in 1827 use. In some cases, but not all, ILNP exceeds that objective and 1828 has lower security risk than IP. Additional engineering details 1829 for several of these topics can be found in [ILNP-ENG]. 1831 9.1 Authentication of Locator Updates 1833 All Locator Update messages are authenticated. ILNP requires use 1834 of an ILNP session nonce [ILNP-NONCEv6] [ILNP-V4OPTS] to prevent 1835 off-path attacks, and also allows use of IPsec cryptography to 1836 provide stronger protection where required. 1838 Ordinary network-layer sessions based on IP are vulnerable to 1839 on-path attacks unless IP Security is used. So the Nonce 1840 Destination Option only seeks to provide protection against 1841 off-path attacks on an ILNP-based network-layer session -- 1842 equivalent to ordinary IP-based network-layer sessions that 1843 aren't using IP Security. 1845 It is common to have non-symmetric paths between two nodes on the 1846 Internet. To reduce the number of on-path nodes that know the 1847 Nonce value for a given session when ILNP is in use, a nonce 1848 value is unidirectional, not bidirectional. For example, for a 1849 network-layer ILNP-based session between nodes A and B, one nonce 1850 value is used from A to B and a different nonce value is used 1851 from B to A. 1853 ILNP sessions operating in higher risk environments SHOULD also 1854 use the cryptographic authentication provided by IP Security *in 1855 addition* to concurrent use of the ILNP Nonce. 1857 It is important to note that at present a network-layer IP-based 1858 session is entirely vulnerable to on-path attacks unless IPsec is 1859 in use for that particular IP session, so the security properties 1860 of the new proposal are never worse than for existing IP. 1862 9.2 Forged Identifier Attacks 1864 In the deployed Internet, active attacks using packets with a 1865 forged Source IP Address have been publicly known at least since 1866 early 1995 [CA-1995-01]. While these exist in the deployed 1867 Internet, they have not been widespread. This is equivalent to 1868 the issue of a forged Identifier value and demonstrates that this 1869 is not a new threat created by ILNP. 1871 One mitigation for these attacks has been to deploy Source IP 1872 Address Filtering [RFC2827] [RFC3704]. Jun Bi at U. Tsinghua 1873 cites Arbor Networks as reporting that this mechanism has less 1874 than 50% deployment and cites an MIT analysis indicating that at 1875 least 25% of the deployed Internet permits forged source IP 1876 addresses. 1878 In an other document [ILNP-ENG] there is a discussion of an 1879 accidental use of a duplicate Identifier on the 1880 Internet. However, this sub-section instead focuses on methods 1881 for mitigating attacks based on packets containing deliberately 1882 forged Source Identifier values. 1884 Firstly, the recommendations of [RFC2827] & [RFC3704] remain. 1885 So any packets that have a forged Locator value can be easily 1886 filtered using existing widely available mechanisms. 1888 Secondly, the receiving node does not blindly accept any packet 1889 with the proper Source Identifier and proper Destination 1890 Identifier as an authentic packet. Instead, each ILNP node 1891 maintains an ILNP Communication Cache (ILCC) for each of its 1892 correspondents, as described in [ILNP-ENG]. Information in the 1893 cache is used in validating received messages and preventing 1894 off-path attackers from succeeding. This process is discussed 1895 more in [ILNP-ENG] 1897 Thirdly, any node can distinguish different nodes using the same 1898 Identifier value by other properties of their ILNP sessions. For 1899 example, IPv6 Neighbor Discovery prevents more than one node from 1900 using the same source I-LV at the same time on the same link 1901 [RFC4861]. So cases of different nodes using the same Identifier 1902 value will involve nodes that have different sets of valid 1903 Locator values. A node thus can demultiplex based on the 1904 combination of Source Locator and Source Identifier if 1905 necessary. If IP Security is in use, the combination of the 1906 Source Identifier and the SPI value would be sufficient to demux 1907 two different ILNP sessions. 1909 Fourthly, deployments in high threat environments also SHOULD use 1910 IP Security to authenticate control traffic and data 1911 traffic. Because IP Security for ILNP binds only to the 1912 Identifier values, and never to the Locator values, a mobile or 1913 multi-homed node can use IPsec even when its Locator value(s) 1914 have just changed. 1916 Lastly, note well that ordinary IPv4, ordinary IPv6, Mobile IPv4, 1917 and also Mobile IPv6 already are vulnerable to forged Identifier 1918 and/or forged IP address attacks. An attacker on the same link as 1919 the intended victim simply forges the victims MAC address and the 1920 victim's IP address. With IPv6, when Secure Neighbour Discovery 1921 (SEND) and Cryptographically Generated Addresses (CGAs) are in 1922 use, the victim node can defend its use of its IPv6 address using 1923 SEND. With ILNP, when SEND and CGAs are in use, the victim node 1924 also can defend its use of its IPv6 address using SEND. There are 1925 no standard mechanisms to authenticate ARP messages, so IPv4 is 1926 especially vulnerable to this sort of attack. These attacks also 1927 work against Mobile IPv4 and Mobile IPv6. In fact, when either 1928 form of Mobile IP is in use, there are additional risks, because 1929 the attacks work not only when the attacker has access to the 1930 victim's current IP subnetwork but also when the attacker has 1931 access to the victim's home IP subnetwork. So the risks of using 1932 ILNP are not greater than exist today with IP or Mobile IP. 1934 9.3 IP Security Enhancements 1936 The IP Security standards are enhanced here by binding IPsec 1937 Security Associations (SAs) to the Node Identifiers of the 1938 endpoints, rather than binding IPsec SAs to the IP Addresses of 1939 the endpoints as at present. This change enhances the 1940 deployability and interoperability of the IP Security standards, 1941 but does not decrease the security provided by those 1942 protocols. See Section 7 for a more detailed explanation. 1944 9.4 DNS Security 1945 The DNS enhancements proposed here are entirely compatible with, 1946 and can be protected using, the existing IETF standards for DNS 1947 Security [RFC4033]. The Secure DNS Dynamic Update mechanism used 1948 here is also used unchanged [RFC3007]. So ILNP does not change 1949 the security properties of the DNS or of DNS servers. 1951 9.5 Firewall Considerations 1953 In the proposed new scheme, stateful firewalls are able to 1954 authenticate ILNP-specific control messages arriving on the 1955 external interface. This enables more thoughtful handling of ICMP 1956 messages by firewalls than is commonly the case at present. As 1957 the firewall is along the path between the communicating nodes, 1958 the firewall can snoop on the ILNP Nonce being carried in the 1959 initial packets of an ILNP session. The firewall can verify the 1960 correct ILNP Nonce is present on incoming control packets, 1961 dropping any control packets that lack the correct nonce value. 1963 By always including the ILNP Nonce in ILNP-specific control 1964 messages, even when IP Security (IPsec) is also in use, the 1965 firewall can filter out off-path attacks against those ILNP 1966 messages without needing to perform computationally-expensive 1967 IPsec processing. In any event, a forged packet from an on-path 1968 attacker will still be detected when the IPsec input processing 1969 occurs in the receiving node; this will cause that forged packet 1970 to be dropped rather than acted upon. 1972 9.6 Neighbour Discovery Authentication 1974 Nothing in this proposal prevents sites from using the Secure 1975 Neighbour Discovery (SEND) proposal for authenticating IPv6 1976 Neighbour Discovery with ILNPv6 [RFC3971]. 1978 9.7 Site Topology Obfuscation 1980 A site that wishes to obscure its internal topology information 1981 MAY do so by deploying site border routers that rewrite the 1982 Locator values for the site as packets enter or leave the site. 1983 This operational scenario was presented in [ABH09a] and is 1984 discussed in more detail in [ILNP-ADV]. 1986 For example, a site might choose to use a ULA prefix internally 1987 for this reason [RFC4193] [ID-ULA]. In this case, the site border 1988 routers would rewrite the Source Locator of ILNP packets leaving 1989 the site to a global-scope Locator associated with the site. 1990 Also, those site border routers would rewrite the Destination 1991 Locator of packets entering the site from the global-scope 1992 Locator to an appropriate interior ULA Locator for the 1993 destination node [ABH08b] [ABH09a] [ILNP-ADV]. 1995 10. PRIVACY CONSIDERATIONS 1997 ILNP has support for both: 1999 - Location Privacy: to hide a node's topological location by 2000 obfuscating the ILNP Locator information. (See also Section 7 2001 of [ILNP-ADV].) 2003 - Identity Privacy: to hide a node's identity by allowing the 2004 allowing the use of Node Identifier values that are not 2005 tied to the node in some permanent or semi-permanent manner. 2006 (See also Section 11 of [ILNP-ENG].) 2008 A more detailed exposition of the possibilities is given in 2009 [BAK11]. 2011 10.1 Location Privacy 2013 Some users have concerns about the issue of "location privacy", 2014 whereby the user's location might be determined by others. The 2015 term "location privacy" does not have a crisp definition within 2016 the Internet community at present. Some mean the location of a 2017 node relative to the Internet's routing topology, while others 2018 mean the geographic coordinates of the node (i.e. latitude X, 2019 longitude Y). The concern seems to focus on Internet-enabled 2020 devices, most commonly handheld devices such as a "smart phone", 2021 that might have 1:1 mappings with individual users. 2023 There is a fundamental trade-off here. Quality of a node's 2024 Internet connectivity tends to be inversely proportional to the 2025 "location privacy" of that node. For example, if a node were to 2026 use a router with NAT as a privacy proxy, routing all traffic to 2027 and from the Internet via that proxy, then (a) latency will 2028 increase as the distance increases between the node seeking 2029 privacy and its proxy, and (b) communications with the node 2030 seeking privacy will be more vulnerable to communication faults 2031 -- both due to the proxy itself (which might fail) and due to the 2032 longer path (which has more points of potential failure than a 2033 more direct path would have). 2035 Any Internet node that wishes for other Internet nodes to be able 2036 to initiate transport-layer or network-layer sessions with it 2037 needs to include associated address (e.g. A, AAAA) or Locator 2038 (e.g. L32, L64, LP) records in the publicly accessible Domain 2039 Name System (DNS). Information placed in the DNS is publicly 2040 accessible. Since the goal of DNS is to distribute information to 2041 other Internet nodes, it does not provide mechanisms for 2042 selective privacy. Of course, a node that does not wish to be 2043 contacted need not be present in the DNS. 2045 In some cases, various parties have attempted to create mappings 2046 between IP address blocks and geographic locations. The quality 2047 of such mappings appears to vary [GUF07]. Many such mapping 2048 efforts are driven themselves by efforts to comply with legal 2049 requirements in various legal jurisdictions. For example, some 2050 content providers reportedly have licenses authorising 2051 distribution of content in one set of locations, but not in a 2052 different set of locations. 2054 ILNP does not compromise user location privacy any more than base 2055 IPv6. In fact, by its nature ILNP provides additional choices to 2056 the user to protect their location privacy. 2058 10.2 Identity Privacy 2060 Both ILNP and IPv6 permit use of identifier values generated 2061 using the IPv6 Privacy Address extension [RFC4941]. ILNP and IPv6 2062 also support a node having multiple unicast addresses/locators at 2063 the same time, which facilitates changing the node's 2064 addresses/locators over time. IPv4 does not have any non- 2065 topological identifiers, and many IPv4 nodes only support 1 IPv4 2066 unicast address per interface, so IPv4 is not directly comparable 2067 with IPv6 or ILNP. 2069 In normal operation with IPv4, IPv6, or ILNP, a mobile node might 2070 intend to be accessible for new connection attempts from the 2071 global Internet and also might wish to have both optimal routing 2072 and maximal Internet availability, both for sent and received 2073 packets. In that case, the node will want to have its addressing 2074 or location information kept in the DNS and made available to 2075 others. 2077 In some cases, a mobile node might only desire to initiate 2078 network-layer or transport-layer sessions with other Internet 2079 nodes, and thus not desire to be a responder, in which case that 2080 node need not be present in the DNS. Some potential correspondent 2081 nodes might, as a matter of local security policy, decline to 2082 communicate with nodes that do not have suitable DNS records 2083 present in the DNS. For example, some deployed IPv4-capable mail 2084 relays refuse to communicate with an initiating node that lacks 2085 an appropriate PTR record in the DNS. 2087 In some cases, for example intermittent electronic mail access or 2088 browsing specific web pages, support for long-lived network 2089 sessions (i.e. where network-layer session lifetime is longer 2090 than the time the node remains on the same subnetwork) is not 2091 required. In those cases, support for node mobility 2092 (i.e. network-layer session continuity even when the SNPA 2093 changes) is not required and need not be used. 2095 If an ILNP node that is mobile chooses not to use DNS for 2096 rendezvous, yet desires to permit any node on the global Internet 2097 to initiate communications with that node, then that node may 2098 fall back to using Mobile IPv4 or Mobile IPv6 instead. 2100 Many residential broadband Internet users are subject to 2101 involuntary renumbering, usually when their ISP's DHCP server(s) 2102 deny a DHCP RENEW request and instead issue different IP 2103 addressing information to the residential user's device(s). In 2104 many cases, such users want their home server(s) or client(s) to 2105 be externally reachable. Such users today often use Secure DNS 2106 Dynamic Update to update their addressing or location information 2107 in the DNS entries, for the devices they wish to make reachable 2108 from the global Internet [RFC2136] [RFC3007] [LA2006]. This 2109 option exists for those users, whether they use IPv4, IPv6, or 2110 ILNP. Users also have the option not to use such mechanisms. 2112 11. IANA CONSIDERATIONS 2114 This document has no IANA considerations. 2116 (Note to RFC Editor; this section can be removed prior to 2117 publication as an RFC.) 2119 12. REFERENCES 2121 This section provides normative and informative references 2122 relating to this note. 2124 12.1. Normative References 2126 [RFC768] J. Postel, "User Datagram Protocol", RFC768, 2127 August 1980. 2129 [RFC791] J. Postel, "Internet Protocol", RFC791, 2130 September 1981. 2132 [RFC793] J. Postel, "Transmission Control Protocol", 2133 RFC793, September 1981. 2135 [RFC826] D. Plummer, "Ethernet Address Resolution Protocol: 2136 Or Converting Network Protocol Addresses to 2137 48 bit Ethernet Address for Transmission on 2138 Ethernet Hardware", RFC 826, November 1982. 2140 [RFC2119] Bradner, S., "Key words for use in RFCs to 2141 Indicate Requirement Levels", BCP 14, RFC 2119, 2142 March 1997. 2144 [RFC2460] S. Deering & R. Hinden, "Internet Protocol 2145 Version 6 Specification", RFC2460, 2146 December 1998. 2148 [RFC3007] B. Wellington, "Secure Domain Name System 2149 Dynamic Update", RFC3007, November 2000. 2151 [RFC3484] R. Draves, "Derfault Address Selection for IPv6", 2152 RFC 3484, February 2003. 2154 [RFC4033] R. Arends, et alia, "DNS Security Introduction 2155 and Requirements", RFC4033, March 2005. 2157 [RFC4219] R. Hinden & S. Deering, "IP Version 6 2158 Addressing Architecture", RFC4219, 2159 February 2006. 2161 [RFC4861] T. Narten, E. Nordmark, W. Simpson, & H. Soliman, 2162 "Neighbor Discovery for IP version 6 (IPv6)", 2163 RFC 4861, September 2007. 2165 [ILNP-ARP] R.J. Atkinson & S.N. Bhatti, "ARP Extension for 2166 ILNPv4", draft-irtf-rrg-ilnp-arp, 10 July 2012. 2168 [ILNP-DNS] R.J. Atkinson, S.N. Bhatti, & S Rose, 2169 "DNS Resource Records for ILNP", 2170 draft-irtf-rrg-ilnp-dns, 10 July 2012. 2172 [ILNP-ENG] R.J. Atkinson & S.N. Bhatti, 2173 "ILNP Engineering and Implementation Considerations", 2174 draft-irtf-rrg-ilnp-eng, 10 July 2012. 2176 [ILNP-ICMPv4] R.J. Atkinson & S.N. Bhatti, 2177 "ICMPv4 Locator Update message" 2178 draft-irtf-rrg-ilnp-icmpv4, 10 July 2012. 2180 [ILNP-ICMPv6] R.J. Atkinson & S.N. Bhatti, 2181 "ICMPv6 Locator Update message" 2182 draft-irtf-rrg-ilnp-icmpv6, 10 July 2012. 2184 [ILNP-NONCEv6] R.J. Atkinson & S.N. Bhatti, 2185 "IPv6 Nonce Destination Option for ILNPv6", 2186 draft-irtf-rrg-ilnp-noncev6, 10 July 2012. 2188 [ILNP-v4OPTS] R.J. Atkinson & S.N. Bhatti, 2189 "IPv4 Options for ILNP", 2190 draft-irtf-rrg-ilnp-v4opts, 10 July 2012. 2192 12.2. Informative References 2194 [8+8] M. O'Dell, "8+8 - An Alternate Addressing 2195 Architecture for IPv6", Internet-Draft, 2196 October 1996. 2198 [ABH07a] R. Atkinson, S. Bhatti, & S. Hailes, 2199 "Mobility as an Integrated Service Through 2200 the Use of Naming", Proceedings of 2201 ACM MobiArch 2007, August 2007, 2202 Kyoto, Japan. 2204 [ABH07b] R. Atkinson, S. Bhatti, & S. Hailes, 2205 "A Proposal for Unifying Mobility with 2206 Multi-Homing, NAT, & Security", 2207 Proceedings of ACM MobiWAC 2007, Chania, 2208 Crete. ACM, October 2007. 2210 [ABH08a] R. Atkinson, S. Bhatti, & S. Hailes, 2211 "Mobility Through Naming: Impact on DNS", 2212 Proceedings of ACM MobiArch 2008, August 2008, 2213 ACM, Seattle, WA, USA. 2215 [ABH08b] R. Atkinson, S. Bhatti, & S. Hailes, 2216 "Harmonised Resilience, Security, and Mobility 2217 Capability for IP", Proceedings of IEEE 2218 Military Communications (MILCOM) Conference, 2219 San Diego, CA, USA, November 2008. 2221 [ABH09a] R. Atkinson, S. Bhatti, & S. Hailes, 2222 "Site-Controlled Secure Multi-Homing and 2223 Traffic Engineering For IP", Proceedings of 2224 IEEE Military Communications (MILCOM) Conference, 2225 Boston, MA, USA, October 2009. 2227 [ABH09b] R. Atkinson, S. Bhatti, & S. Hailes, "ILNP: Mobility, 2228 Multi-Homing, Localised Addressing and Security 2229 Through Naming", Telecommunications Systems, 2230 Volume 42, Number 3-4, pp 273-291, 2231 Springer-Verlag, December 2009, ISSN 1018-4864. 2233 [ABH10] R. Atkinson, S. Bhatti, S. Hailes, 2234 "Evolving the Internet Architecture Through Naming", 2235 IEEE Journal on Selected Areas in Communication 2236 (JSAC), vol. 28, no. 8, pp. 1319-1325, IEEE, 2237 Piscataway, NJ, USA, Oct 2010. 2239 [BA11] S. Bhatti & R. Atkinson, "Reducing DNS Caching", 2240 Proceedings of IEEE Global Internet Symposium 2241 (GI2011), Shanghai, P.R. China. 15 April 2011. 2243 [BA12] S. N. Bhatti & R. Atkinson, 2244 "Secure & Agile Wide-area Virtual Machine Mobility", 2245 Procedings of IEEE Military Communications 2246 Conference (MILCOM), Orlando, FL, USA. Oct 2012. 2248 [BAK11] S. Bhatti, R. Atkinson, & J. Klemets, "Integrating 2249 Challenged Networks", Proceedings of IEEE Military 2250 Communications Conference (MILCOM), Baltimore, MD, 2251 USA. November 2011. 2253 [CA-1995-01] US CERT, "IP Spoofing Attacks and Hijacked 2254 Terminal Connections", CERT Advisory 1995-01, 2255 Issued 23 JAN 1995, Revised 23 SEP 1997. 2257 [GSE] M. O'Dell, "GSE - An Alternate Addressing 2258 Architecture for IPv6", Internet-Draft, 2259 February 1997. 2261 [ID-ULA] R. Hinden, G. Huston, & T. Narten, "Centrally 2262 Assigned Unique Local IPv6 Unicast Addresses", 2263 draft-ietf-ipv6-ula-central-02.txt, 15 June 2007. 2265 [IEEE-EUI] IEEE, "Guidelines for 64-bit Global Identifier 2266 (EUI-64) Registration Authority", 2267 http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, 2268 IEEE, Piscataway, NJ, USA, March 1997. 2270 [IEN1] C.J. Bennett, S.W. Edge, & A.J. Hinchley, 2271 "Issues in the Interconnection of Datagram 2272 Networks", Internet Experiment Note (IEN) 1, 2273 INDRA Note 637, PSPWN 76, University College 2274 London, London, England, UK, WC1E 6BT, 2275 29 July 1977. 2276 http://www.postel.org/ien/ien001.pdf 2278 [IEN19] J. F. Shoch, "Inter-Network Naming, Addressing, 2279 and Routing", IEN-19, January 1978. 2281 [IEN23] J. F. Shoch, "On Names, Addresses, and 2282 Routings", IEN-23, January 1978. 2284 [IEN31] D. Cohen, "On Names, Addresses, and Routings 2285 (II)", IEN-31, April 1978. 2287 [IEN135] C. Sunshine & J. Postel, "Addressing Mobile Hosts in 2288 the ARPA Internet Environment", IEN 135, 2289 March 1980. 2291 [IPng95] D. Clark, "A thought on addressing", 2292 electronic mail message to IETF IPng WG, 2293 Message-ID: 9501111901.AA28426@caraway.lcs.mit.edu, 2294 Laboratory for Computer Science, MIT, 2295 Cambridge, MA, USA, 11 January 1995. 2297 [LA2006] C. Liu & P. Albitz, "DNS & Bind", 5th Edition, 2298 O'Reilly & Associates, Sebastopol, CA, USA, 2299 May 2006. ISBN 0-596-10057-4 2301 [LABH06] M. Lad, R. Atkinson, S. Bhatti, and S. Hailes, 2302 "A Proposal for Coalition Networking in Dynamic 2303 Operational Environments", Proceedings of IEEE 2304 Military Communications Conference, Washington, 2305 DC, USA. Nov 2006. 2307 [PHG02] A. Pappas, S. Hailes, & R. Giaffreda, 2308 "Mobile Host Location Tracking through DNS", 2309 Proceedings of IEEE London Communications 2310 Symposium, IEEE, London, England, UK, 2311 September 2002. 2313 [RAB09] D. Rehunthan, R. Atkinson, & S. Bhatti, 2314 "Enabling Mobile Networks Through Secure Naming", 2315 Proceedings of IEEE Military Communications 2316 Conference (MILCOM), Boston, MA, USA, October 2009. 2318 [RB10] D. Rehunathan and S. Bhatti, 2319 "A Comparative Assessment of Routing for Mobile 2320 Networks", Proceedings of IEEE International 2321 Conference on Wireless and Mobile Computing 2322 Networking and Communications (WiMob2010), 2323 IEEE, Niagara Falls, ON, Canada. Oct 2010. 2325 [SBK01] Alex C. Snoeren, Hari Balakrishnan, & M. Frans 2326 Kaashoek, "Reconsidering Internet Mobility", 2327 Proceedings of 8th Workshop on Hot Topics in 2328 Operating Systems, IEEE, Elmau, Germany, May 2001. 2330 [SIPP94] Bob Smart, "Re: IPng Directorate meeting in 2331 Chicago; possible SIPP changes", electronic 2332 mail to the IETF SIPP WG mailing list, 2333 Message-ID: 2334 199406020647.AA09887@shark.mel.dit.csiro.au, 2335 Commonwealth Scientific & Industrial Research 2336 Organisation (CSIRO), Melbourne, VIC, 3001, 2337 Australia, 2 June 1994. 2339 [SRC84] J. Saltzer, D. Reed, & D. Clark, "End to End 2340 Arguments in System Design", ACM Transactions on 2341 Computer Systems, Volume 2, Number 4, ACM, 2342 New York, NY, USA, November 1984. 2344 [RFC814] D.D. Clark, "Names, Addresses, Ports, and 2345 Routes", RFC814, July 1982. 2347 [RFC1122] R. Braden, "Requirements for Internet Hosts - 2348 Communication Layers", RFC1122, October 1989. 2350 [RFC1498] J.H. Saltzer, "On the Naming and Binding of 2351 Network Destinations", RFC1498, August 1993. 2353 [RFC1631] K. Egevang & P. Francis, "The IP Network 2354 Address Translator (NAT)", RFC1631, May 1994. 2356 [RFC1825] R. Atkinson, "Security Architecture for the Internet 2357 Protocol", RFC-1825, August 1995. 2359 [RFC1826] R. Atkinson, "IP Authentication Header", RFC-1826, 2360 August 1995. 2362 [RFC1827] R. Atkinson, "IP Encapsulating Security Payload", 2363 RFC-1827, August 1995. 2365 [RFC1958] B. Carpenter (Ed.), "Architectural Principles 2366 of the Internet", RFC1958, June 1996. 2368 [RFC1992] I. Castineyra, N. Chiappa, & M. Steenstrup, 2369 "The Nimrod Routing Architecture", RFC1992, 2370 August 1996. 2372 [RFC2002] C. Perkins et alia, "IP Mobility Support", 2373 RFC 2002, October 1996. 2375 [RFC2101] B. Carpenter, J. Crowcroft, & Y. Rekhter, 2376 "IPv4 Address Behaviour Today", RFC2101, 2377 February 1997. 2379 [RFC2136] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound, 2380 "Dynamic Updates in the Domain Name System", 2381 RFC2136, April 1997. 2383 [RFC2827] P. Ferguson & D. Senie, "Network Ingress Filtering: 2384 Defeating Denial of Service Attacks which employ 2385 IP Source Address Spoofing", RFC2827, May 2000. 2387 [RFC2956] M. Kaat, "Overview of 1999 AB WOrkshop", RFC2956, 2388 October 2000. 2390 [RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 2391 Address Allocations to Sites", RFC3177, September 2392 2001. 2394 [RFC3022] P. Srisuresh & K. Egevang, "Traditional IP 2395 Network Address Translator", RFC3022, 2396 January 2001. 2398 [RFC3027] M. Holdrege and P Srisuresh, "Protocol 2399 Complications of the IP Network Address 2400 Translator", RFC3027, January 2001. 2402 [RFC3704] F. Baker & P. Savola, "Ingress Filtering for 2403 Multihomed Networks, RFC3704, March 2004. 2405 [RFC3715] B. Aboba and W. Dixon, "IPsec-Network Address 2406 Translation (NAT) Compatibility Requirements", 2407 RFC3715, March 2004. 2409 [RFC6250] D. Thaler, "Evolution of the IP Model", 2410 RFC6250, May 2011. 2412 [RFC6275] C. Perkins, D. Johnson, and J. Arkko, "Mobility 2413 Support in IPv6", RFC6275, July 2011. 2415 [RFC3948] A. Huttunen, et alia, "UDP Encapsulation of 2416 IPsec ESP Packets", RFC3948, January 2005. 2418 [RFC3971] J. Arkko, J. Kempf, B. Zill, & P. Nikander, 2419 "SEcure Neighbor Discovery (SEND)", RFC3971 2420 March 2005. 2422 [RFC3972] T. Aura, "Cryptographically Generated Addresses 2423 (CGAs)", RFC3972, March 2005. 2425 [RFC4193] R. Hinden & B. Haberman, "Unique Local IPv6 2426 Unicast Addresses, RFC4193, October 2005. 2428 [RFC4291] R. Hinden & S. Deering, "IP version 6 Addressing 2429 Architecture", RFC4291, February 2006. 2431 [RFC4581] M. Bagnulo & J. Arkko, "Cryptographically Generated 2432 Addresses Extension Field Format", RFC4581, 2433 October 2006. 2435 [RFC4941] T. Narten, R. Draves, & S. Krishnan, "Privacy 2436 Extensions for Stateless Address Autoconfiguration 2437 in IPv6", RFC4941, September 2007. 2439 [RFC4982] M. Bagnulo & J. Arkko, "Support for Multiple Hash 2440 Algorithms in Cryptographically Generated 2441 Addresses", RFC4982, July 2007. 2443 [RFC4984] D. Meyer, L. Zhang, K. Fall, "Report from the IAB 2444 Workshop on Routing and Addressing", RFC4984, 2445 September 2007. 2447 [RFC5061] R. Stewart, Q. Xie, M. Tuexen, S. Maruyama, & 2448 M. Kozuka, "Stream Control Transmission Protocol 2449 (SCTP) Dynamic Address Reconfiguration", RFC5061, 2450 September 2007. 2452 [RFC6177] T. Narten, G. Huston, L. Roberts, "IPv6 Address 2453 Assignment to End Sites", RFC6177 (BCP157), March 2454 2011. 2456 [GUF07] B. Gueye, S. Uhlig, & S. Fdida, "Investigating the 2457 Imprecision of IP Block-Based Geolocation", 2458 Lecture Notes in Computer Science, Volume 4427, 2459 pp. 237-240, Springer-Verlag, Heidelberg, 2460 Germany, 2007. 2462 [ILNP-ADV] R.J. Atkinson & S.N. Bhatti, 2463 "Optional Advanced Deployment Scenarios for ILNP", 2464 draft-irtf-rrg-ilnp-adv, 10 July 2012. 2466 ACKNOWLEDGEMENTS 2468 Steve Blake, Stephane Bortzmeyer, Mohamed Boucadair, Noel 2469 Chiappa, Wes George, Steve Hailes, Joel Halpern, Mark Handley, 2470 Volker Hilt, Paul Jakma, Dae-Young Kim, Tony Li, Yakov Rehkter, 2471 Bruce Simpson, Robin Whittle and John Wroclawski (in alphabetical 2472 order) provided review and feedback on earlier versions of this 2473 document. Steve Blake provided an especially thorough review of 2474 an early version of the entire ILNP document set, which was 2475 extremely helpful. We also wish to thank the anonymous reviewers 2476 of the various ILNP papers for their feedback. 2478 Roy Arends provided expert guidance on technical and procedural 2479 aspects of DNS issues. 2481 Noel Chiappa graciously provided the authors with copies of the 2482 original email messages cited here as [SIPP94] and [IPng95], 2483 which enabled the precise citation of those messages herein. 2485 RFC EDITOR NOTE 2487 This section is to be removed prior to publication. 2489 Please note that this document is written in British English, so 2490 British English spelling is used throughout. This is consistent 2491 with existing practice in several other RFCs, for example 2492 RFC-5887. 2494 This document tries to be very careful with history, in the 2495 interest of correctly crediting ideas to their earliest 2496 identifiable author(s). So in several places the first published 2497 RFC about a topic is cited rather than the most recent published 2498 RFC about that topic. 2500 Author's Address 2502 RJ Atkinson 2503 Consultant 2504 San Jose, CA 2505 95125 USA 2507 Email: rja.lists@gmail.com 2509 SN Bhatti 2510 School of Computer Science 2511 University of St Andrews 2512 North Haugh, St Andrews 2513 Fife, Scotland 2514 KY16 9SX, UK 2516 Email: saleem@cs.st-andrews.ac.uk 2518 Expires: 10 JAN 2013