idnits 2.17.1 draft-irtf-rrg-ilnp-adv-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, 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 4308 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC4984' is mentioned on line 95, but not defined == Missing Reference: 'RFC3587' is mentioned on line 391, but not defined ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 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-adv-06.txt Consultant 4 Expires: 10 Jan 2013 SN Bhatti 5 Category: Experimental U. St Andrews 6 10 July 2012 8 Optional Advanced Deployment Scenarios for ILNP 9 draft-irtf-rrg-ilnp-adv-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 (http://trustee.ietf.org 20 /license-info) in effect on the date of publication of this 21 document. Please review these documents carefully, as they 22 describe your rights and restrictions with respect to this 23 document. Code Components extracted from this document must 24 include Simplified BSD License text as described in Section 4.e 25 of the Trust Legal Provisions and are provided without warranty 26 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 Abstract 66 This document provides an Architectural description and the 67 Concept of Operations of some optional advanced deployment 68 scenarios for the Identifier-Locator Network Protocol (ILNP), 69 which is an evolutionary enhancement to IP. None of the functions 70 described here is required for the use or deployment of ILNP. 71 Instead, it offers descriptions of engineering and deployment 72 options that might provide either enhanced capability or 73 convenience in administration or management of ILNP-based 74 systems. 76 Table of Contents 78 1. Introduction......................................? 79 2. Localised Numbering...............................? 80 3. An Alternative For Site Multi-Homing..............? 81 4. An Alternative For Site (Network) Mobility........? 82 5. Traffic Engineering Options.......................? 83 6. ILNP in Datacentres ..............................? 84 7. Location Privacy..................................? 85 8. Identity Privacy..................................? 86 9. Security Considerations...........................? 87 10. IANA Considerations...............................? 88 11. References........................................? 90 1. INTRODUCTION 92 At present, the Internet research and development community are 93 exploring various approaches to evolving the Internet 94 Architecture to solve a variety of issues including, but not 95 limited to, scalability of inter-domain routing [RFC4984]. A wide 96 range of other issues (e.g. site multi-homing, node multi-homing, 97 site/subnet mobility, node mobility) are also active concerns at 98 present. Several different classes of evolution are being 99 considered by the Internet research & development community. One 100 class is often called "Map and Encapsulate", where traffic would 101 be mapped and then tunnelled through the inter-domain core of the 102 Internet. Another class being considered is sometimes known as 103 "Identifier/Locator Split". This document relates to a proposal 104 that is in the latter class of evolutionary approaches. 106 ILNP is, in essence, an end-to-end architecture: the 107 functions required for ILNP are implemented in, and controlled 108 by, only those end-systems that wish to use ILNP, as described 109 in [ILNP-ARCH]. Other nodes, such as Site Border Routers (SBRs) 110 need only support IP to allow operation of ILNP, e.g. an SBR 111 should support IPv6 in order to enable end-systems to operate 112 ILNPv6 within the site network for which an SBR provides a 113 service [ILNP-ENG]. 115 However, some features of ILNP could be optimised, from an 116 engineering perspective, by the use of an intermediate system (a 117 router, security gateway or "middlebox") that modifies (rewrites) 118 Locator values of transit ILNP packets. It would also perform 119 other control functions for an entire site, as an administrative 120 convenience, such as providing a centralised point of management 121 for a site. For example, an SBR might manipulate the topological 122 presence of the packet, providing an elegant solution to the 123 provision of functions such as site (network) mobility for an 124 entire end site [ABH09a]. 126 This document discusses several such optional advanced deployment 127 scenarios for ILNP. These typically use an ILNP-capable Site 128 Border Router (SBR). 130 Nothing in this document is a requirement for any ILNP 131 implementation or any ILNP deployment. 133 Readers are strongly advised to first read the ILNP Architecture 134 Description [ILNP-ARCH], as this document uses the notation and 135 terminology described or referenced in that document. 137 1.1 Document roadmap 139 This document describes engineering and implementation 140 considerations that are common to both ILNPv4 and ILNPv6. 142 The ILNP architecture can have more than one engineering 143 instantiation. For example, one can imagine a "clean-slate" 144 engineering design based on the ILNP architecture. In separate 145 documents, we describe two specific engineering instances of 146 ILNP. The term ILNPv6 refers precisely to an instance of ILNP that 147 is based upon, and backwards compatible with, IPv6. The term ILNPv4 148 refers precisely to an instance of ILNP that is based upon, and 149 backwards compatible with, IPv4. 151 Many engineering aspects common to both ILNPv4 and ILNPv6 are 152 described in [ILNP-ENG]. A full engineering specification for 153 either ILNPv6 or ILNPv4 is beyond the scope of this document. 155 Readers are referred to other related ILNP documents for details 156 not described here: 158 a) [ILNP-ARCH] is the main architectural description of ILNP, 159 including the concept of operations. 161 b) [ILNP-ENG] describes engineering and implementation 162 considerations that are common to both ILNPv4 and ILNPv6. 164 c) [ILNP-DNS] defines additional DNS resource records that 165 support ILNP. 167 d) [ILNP-ICMPv6] defines a new ICMPv6 Locator Update message 168 used by an ILNP node to inform its correspondent nodes 169 of any changes to its set of valid Locators. 171 e) [ILNP-NONCEv6] defines a new IPv6 Nonce Destination Option 172 used by ILNPv6 nodes (1) to indicate to ILNP correspondent 173 nodes (by inclusion within the initial packets of an ILNP 174 session) that the node is operating in the ILNP mode and 175 (2) to prevent off-path attacks against ILNP ICMP messages. 176 This Nonce is used, for example, with all ILNP ICMPv6 177 Locator Update messages that are exchanged among ILNP 178 correspondent nodes. 180 f) [ILNP-ICMPv4] defines a new ICMPv4 Locator Update message 181 used by an ILNP node to inform its correspondent nodes 182 of any changes to its set of valid Locators. 184 g) [ILNP-v4OPTS] defines a new IPv4 Nonce Option used by ILNPv4 185 nodes to carry a security nonce to prevent off-path attacks 186 against ILNP ICMP messages and also defines a new IPv4 187 Identifier Option used by ILNPv4 nodes. 189 h) [ILNP-ARP] describes extensions to ARP for use with ILNPv4. 191 1.2 Terminology 193 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 194 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 195 in this document are to be interpreted as described in RFC 2119 196 [RFC2119]. 198 2. LOCALISED NUMBERING 200 Today, Network Address Translation [RFC3022] is used for a number 201 of purposes. Whilst one of the original intentions of NAT was to 202 reduce the rate of use of global IPv4 addresses, through use of 203 IPv4 private address space [RFC1918], NAT also offers to site 204 administrators a convenient localised address management 205 capability combined with a local-scope/private address space, 206 for example [RFC1918] for IPv4. 208 For IPv6, NAT would not necessarily be required to reduce the 209 rate of IPv6 address depletion, because the availability of 210 addresses is not such an issue as for IPv4. The IETF has 211 standardised Unique Local IPv6 Unicast Addresses [RFC4193], 212 which provide local-scope IPv6 unicast address space that can be 213 used by end sites. However, localised address management, in a 214 manner similar to that provided by IPv4 NAT and private address 215 space [RFC1918], is still desirable for IPv6 [RFC5902], even 216 though there is debate about the efficacy of such an approach 217 [RFC4864]. 219 One of the major concerns that many have had with NAT is the loss 220 of end-to-end transport-layer and network-layer session state 221 invariance, which is still considered an important architectural 222 principle by the IAB [RFC4924]. Nevertheless, the use of 223 localised addressing remains in wide use and there is interest in 224 its continued use in IPv6, e.g. proposals such as [RFC6296]. 226 It is possible to have the benefits of NAT-like functions for 227 ILNP without losing end-to-end state. Indeed, such a mechanism - 228 the use of Locator re-writing in ILNP - forms the basis of many 229 of the optional functions described in this document. In ILNP, 230 we call this feature "localised numbering". 232 Recall, that a Locator value in ILNP has the same semantics as a 233 routing prefix in IP: indeed, in ILNPv4 and ILNPv6 [ILNP-ENG], 234 routing prefixes from IPv4 and IPv6, respectively, are used as 235 Locator values. 237 We note that a deployment using private/local numbering can also 238 provide a convenient solution to centralised management of site 239 multi-homing and network mobility by deploying SBRs in this manner 240 - this is described below. 242 Please note that with this proposal, localised numbering (e.g. 243 using the equivalent of IP NAT on the ILNP Locator bits) would 244 work in harmony with multihoming, mobility (for individual hosts 245 and whole networks), and IP Security, plus the other advanced 246 functions described in this document [BA11] [LABH06] [ABH07a] 247 [ABH07b] [ABH08a] [ABH08b] [ABH09a] [ABH09b] [RAB09] [RB10] 248 [ABH10] [BAK11]. 250 2.1 Localised Locators 252 For ILNP, the NAT-like function can best be descried by using a 253 simple example, based on Figure 2.1. 255 site . . . . +----+ 256 network SBR . .-----+ CN | 257 . . . . +------+ L_1 . . +----+ 258 . . | +------. . 259 . .L_L | | . . 260 . .----+ | . Internet . 261 . H . | | . . 262 . . | | . . 263 . . . . +------+ . . 264 . . 265 . . . . 267 CN = Correspondent Node 268 H = Host 269 L_1 = global Locator value 270 L_L = local Locator value 271 SBR = Site Border Router 273 Figure 2.1: A simple localised numbering example for ILNP. 275 In this scenario, the SBR is allocated global locator value L_1 276 from the upstream provider. However, the SBR advertises internally 277 a "local" Locator value L_L. By "local" we mean that the Locator 278 value only has significance within the site network, and any 279 packets that have L_L as a source Locator cannot be forwarded 280 beyond the SBR with value L_L as the source Locator. In 281 engineering terms, L_L would, for example in ILNPv6, be an IPv6 282 prefix based on the assignments possible according to IPv6 Unique 283 Local Addresses (ULA) [RFC4193]. 285 We assume that H uses Identifier I_H then it will use 286 Identifier-Locator Vector (IL-V) [I_H, L_L], and that the 287 correspondent node (CN) uses IL-V [I_CN, L_CN]. If we consider 288 that H will send a UDP packet from its port P_H to CN's port P_CN, 289 then, H could send a UDP/ILNP packet with the tuple expression: 291 --- (1a) 293 When this packet reaches the SBR, it knows that L_L is a local 294 Locator value and so re-writes the source Locator on the egress 295 packet to L_1, and forwards that out onto its external-facing 296 interface. The value L_1 is a global prefix, which allows the 297 packet to be routed globally: 299 --- (1b) 301 This packet reaches CN using normal routing based on the Locator 302 value L_1, as it is a routing prefix. 304 Note that from expressions (1a) and (1b), the end-to-end state (in 305 the UDP tuple) remains unchanged - end-to-end state invariance is 306 honoured, for UDP. CN would send a UDP packet to H as: 308 --- (2a) 310 and the SBR would re-write the Locator value on the ingress packet 311 before forwarding the packet on its internal interface: 313 --- (2b) 315 Again, this preserves the end-to-end transport-layer session 316 state invariance. 318 As the Locator values are not used in the transport layer pseudo 319 header for ILNP [ILNP-ENG], the checksum would not have to be 320 re-written. That is, the Locator re-writing function is stateless 321 and has low overhead. 323 (A discussion on the generation of Identifier values for initial 324 use is presented in [ILNP-ENG].) 326 2.2 Mixed local/global numbering 328 It is possible for the SBR to advertise both L_1 and L_L within 329 the site, and for hosts within the site to have IL-Vs using both 330 L_1 and L_L. For example, host H may have IL-Vs [I_H, L_1] and 331 [I_H, L_L]. The configuration and use of such a mechanism can be 332 controlled through local policy. 334 2.3 Dealing with internal subnets with Locator re-writing 336 Where the site network uses subnets, packets will need to be 337 routed correctly, internally. That is, the site network may have 338 several internal Locator values, e.g. L_La, L_Lb, and L_Lc. When 339 an ingress packet has I-LV [I_H, L_1], it is expected that the 340 SBR is capable of identifying the correct internal network for 341 I_H, and so the correct Locator value to re-write for the ingress 342 packet. This is not obvious as the I value and the L value are 343 not related in any way. 345 There are numerous ways the SBR could facilitate the correct 346 lookup of the internal Locator value. This document does not 347 prescribe any specific method. Of course, we do not preclude 348 mappings directly from Identifier values to internal Locator 349 values. 351 Of course, such a "flat" mapping (between Identifier values and 352 Locators) would serve, but maintaining such a mapping would be 353 impractical for a large site. So, we propose the following 354 solution. 356 Consider that the Locator value, L_x consists of two parts, L_pp 357 and L_ss, where L_pp is a network prefix and L_ss is a subnet 358 selector. Also, consider that this structure is true for both 359 the local identifier, L_L, as well as the global Identifier, L_1. 360 Then an SBR need only to know the mapping from the values of L_ss 361 as visible in L_1 and the values of L_ss used locally. 363 Such a mapping could be mechanical, e.g. the L_ss part of L_L and 364 L_1 are the same and it is only the L_pp part which is different. 365 Where this is not desirable (e.g. for obfuscation of interior 366 topology), an administrator would need to configure a suitable 367 mapping policy in the SBR, which could be realised as a simple 368 lookup table. Note that with such a policy, the L_pp for L_L and 369 L_1 do not need to be of the same size. 371 From a practical perspective, this is possible for both ILNPv6 372 [RFC6177] and ILNPv4 [RFC4632]. For ILNPv6, recall that the 373 Locator value is encoded to be syntactically similar to an IPv6 374 address prefix, as shown in Figure 2.2, taken from [ILNP-ENG]. 376 /* IPv6 */ 377 | 3 | 45 bits | 16 bits | 64 bits | 378 +---+---------------------+-----------+-------------------------+ 379 |001|global routing prefix| subnet ID | Interface Identifier | 380 +---+---------------------+-----------+-------------------------+ 381 /* ILNPv6 */ 382 | 64 bits | 64 bits | 383 +---+---------------------+-----------+-------------------------+ 384 | Locator (L64) | Node Identifier (NID) | 385 +---+---------------------+-----------+-------------------------+ 386 +<-------- L_pp --------->+<- L_ss -->+ 388 L_pp = Locator prefix part (assigned IPv6 prefix) 389 L_ss = Locator subnet selector (locally managed subnet ID) 391 Figure 2.2: IPv6 address format [RFC3587] as used in ILNPv6, 392 showing how subnets can be identified. 394 Note that the subnet ID forms part of the Locator value. Note 395 also that [RFC6177] allows the global routing prefix to be more 396 than 45 bits, and for the subnet ID to be smaller, but still 397 preserving the 64-bit size of the Locator overall. 399 For ILNPv4, the L_pp value overall is an IPv4 routing prefix, 400 which is typically less than 32 bits. However, the ILNPv4 Locator 401 value is carried in the 32-bit IP address space, so the bits not 402 used for the routing prefix could be used for L_ss, e.g. for a 403 /24 IPv4 prefix, the situation would be as shown in Fig 2.3, and 404 L_ss could use any of the remaining 8-bits as required. 406 24 bits 8 bits 407 +------------------------+----------+ 408 | Locator (L32) | 409 +------------------------+----------+ 410 +<------- L_pp --------->+<- L_ss ->+ 412 L_pp = Locator prefix (assigned IPv4 prefix) 413 L_ss = Locator subnet selector (locally managed subnet ID) 415 Figure 2.3: IPv4 address format for /24 IPv4 prefix, as used in 416 ILNPv4, showing how subnets can be identified. 418 As an example, for the case where the interior topology is not 419 obfuscated, an interior "engineering" node might have an LP 420 record pointing to eng.example.com and eng.example.com might have 421 L32/L64 records for a specific subnet inside the site. Meanwhile, 422 an interior "operations" node might have an LP record pointing at 423 "ops.example.com" which might have different L32/L64 records for 424 that specific subnet within the site. That is, eng.example.com 425 might have Locator value L_pp_1:L_ss_1 and ops.example.com might 426 have Locator value L_pp_1:L_ss_2. However, just as for IPv6 or 427 IPv4 routing today, the routing for the site would only need to 428 use L_pp_1, which is a routing prefix in either IPv6 (for ILNPv6) 429 or IPv4 (for ILNPv4). 431 2.4 Localised name resolution with DNS 433 To support private numbering with IPv4 and IPv6 today, some sites 434 use a split-horizon DNS service for the site [ID-appDNS]. 436 If a site using localised numbering chooses to deploy a 437 split-horizon DNS server, then the DNS server would return the 438 global-scope Locator(s) (L_1 in our example above) of the SBR to 439 DNS clients outside the site, and would advertise the local-scope 440 Locator(s) (L_L in our example above) specific to that internal 441 node to DNS clients inside the site. Such deployments of 442 split-horizon DNS servers are not unusual in the IPv4 Internet 443 today. If an internal node (e.g. portable computer) moves outside 444 the site, it would follow the normal ILNP methods to update its 445 authoritative DNS server with its current Locator set. In this 446 deployment model, the authoritative DNS server for that mobile 447 device will be either the split-horizon DNS server itself or the 448 master DNS server providing data to the split-horizon DNS server. 450 If a site using localised numbering chooses not to deploy a 451 split-horizon DNS server, then each internal nodes would 452 advertise the global-scope Locator(s) of the site border routers 453 in its respective DNS entries. To deliver packets from one 454 internal node to another internal node, the site would either 455 choose to use layer-2 bridging (e.g. IEEE Spanning Tree or IEEE 456 Rapid Spanning Tree [IEEE04], or a link- state layer-2 algorithm 457 such as the IETF TRILL group or IEEE 802.1 are developing), or 458 the interior routers would forward packets up to the nearest site 459 border router, which in turn would then rewrite the Locators to 460 appropriate local-scope values, and forward the packet towards 461 the interior destination node. 463 Alternately, for sites using localised numbering but not 464 deploying a split-horizon DNS server, the DNS server could return 465 all global-scope and local-scope Locators to all queriers, and 466 assume that nodes would use normal, local address/route selection 467 criteria to choose the best Locator to use to reach a given 468 remote node [RFC3484]. Hosts within the same site as the 469 correspondent node would only have a ULA configured, and hence 470 would select the ULA destination Locator for the correspondent 471 (L_L in our example). Hosts outside the site would not have the 472 same ULA configured (L_CN for the CN in our example). Note that 473 RFC3484 probably needs to be updated to indicate that the 474 longest-prefix matching rule is inadequate when comparing ULA- 475 based Locators with global-scope Locators: to choose a ULA for a 476 correspondent, a node must have a Locator that matches all ULA 477 bits of the target Locator value. 479 Note that for split-horizon operation, there needs to be a DNS 480 management policy for mobile hosts, as when such hosts are away 481 from their "home" network, they will need to update DNS entries 482 so that the global-scope Locator(s) only is (are) used, and these 483 are consistent with the current topological position of the 484 mobile host. Such updates would need to be done using Secure 485 Dynamic DNS Update. 487 For an ILNP mobile network using LP records, there are likely to 488 separate LP records for internal and external use. 490 2.5 Use of mDNS 492 Multicast DNS (mDNS) [ID-mDNS11] is popularly used in many end- 493 system OSs today, especially desktop OSs (such as Windows, MacOSX 494 and Linux). It is used for localised name resolution using names 495 with a ".local" suffix, for both IPv4 and IPv6. This protocol 496 would need to be modified so that when an ILNP-capable node 497 advertises its ".local" name, another ILNP-capable node would be 498 able to see that it is an ILNP-capable, but other, non-ILNP nodes 499 would not be perturbed in operation. The details of a mechanism 500 for using mDNS to enable such a feature are not defined here. 502 2.6 Site Network Name in DNS 504 In this scenario, if H expects incoming ILNP session requests, 505 for example, then remote nodes normally will need to look up 506 appropriate Identifier and Locator information in the DNS. Just 507 as for IP, and as already described in [ILNP-ARCH], a Fully 508 Qualified Domain Name (FQDN) lookup for H should resolve to the 509 correct NID and L32/L64 records. If there are many hosts like H 510 that need to keep DNS records (for any reason, including to allow 511 incoming ILNP session requests), then, potentially, there are 512 many such DNS Resource Records. 514 As an optimisation, the network as a whole may be configured with 515 one or more L32 and L64 records (to store the value L_1 from our 516 example) that are resolved from an FQDN. At the same time, 517 individual hosts now have an FQDN that returns one or more LP 518 record entries [ILNP-DNS] as well as NID records. The LP record 519 points to the L32 or L64 records for the site. A multi-homed 520 site normally will have at least one L32 or L64 record for each 521 distinct uplink (i.e. link from a Site Border Router towards the 522 global Internet), because ILNP uses provider-aggregatable 523 addressing. 525 More than one L32 or L64 will be required if multiple Locator 526 values are in use. For example, if an ILNPv6 site has multiple 527 links for multi-homing, it will use one L64 record for each 528 Locator value it is using on each link. 530 2.7 Site Interior Topology Obfuscation 532 In some situations, it can be desirable to obfuscate the details 533 of the interior topology of an end site. Alternately, in some 534 situations, local site policy requires that local-scope routing 535 prefixes be used within the local site. ILNP can provide these 536 capabilities through the ILNP local addressing capability 537 described here, under the control of the SBR. 539 As described in Sec. 2.3 above, locator re-writing can be used to 540 hid the internal structure of the network with respect to the 541 sub-netting arrangement of the site network. Specifically, the 542 procedure described in Sec 2.3 would be followed, with the 543 following additional modification of the use of Locator values: 545 (1) only the aggregated Locator value, i.e. L_pp, is advertised 546 outside the site (e.g. in an L32 or L64 record), and L_ss is 547 zeroed in that advertisement. 549 (2) the SBR needs to maintain a mapping table to restore the 550 interior topology information for received packets, for 551 example by using a mapping table from I values to either 552 L_ss values or to internal Locator values. 554 (3) the SBR needs to zero the L_ss values for all Source Locators 555 of egress packets, as well as performing an Locator re-writing 556 effecting the L_pp bits of the Locator value. 558 Of course, this only obscures the interior topology of the site, 559 not the exterior connectivity of the site. In order for the site 560 to be reachable from the global Internet, the site's DNS entries 561 need to advertise Locator values for the site to the global 562 Internet (e.g. in L32, L64 records). 564 2.8 Other SBR considerations 566 For backwards compatibility, for ILNP, the ICMP checksum is 567 always calculated identically as for IPv6 or IPv4. For ILNPv6, 568 this means that the SBR need not be aware if ILNPv6 is operating 569 as described in [ILNP-ARCH] and [ILNP-ENG]. For ILNPv4, again, 570 the SBR need not be aware of the operation if ILNPv4 is operating 571 as it will not need to inspect the extension header carrying the 572 I value. 574 In order to support communication between two internal nodes that 575 happen to be using global-scope addresses (for whatever reason), 576 the SBR MUST support the "hair pinning" behaviour commonly used 577 in existing NAT/NAPT devices. (This behaviour is described in 578 Section 6 of RFC4787 [RFC4787].) 580 In the near-term, a more common deployment scenario will be to 581 deploy ILNP incrementally, with some ordinary classic IP traffic 582 still existing. In this case, the SBR should maintain flow state 583 that contains a flag for each flow indicating whether that flow 584 is using ILNP or not. If that flag indicated ILNP were enabled 585 for a given flow, and ILNP local numbering were also enabled, 586 then the SBR would know that it should perform the simpler ILNP 587 Locator re-writing mapping. If that flag indicated ILNP were not 588 enabled for a given flow and IP NAT or IP NAPT were also enabled, 589 then the SBR would know that it should perform the more complex 590 NAT/NAPT translation (e.g. including TCP or UDP checksum 591 recalculation). 593 NOTE: Existing commercial security-aware routers 594 (e.g. Juniper SRX routers) already can maintain flow state 595 for millions of concurrent IP flows. This feature would add 596 one flag to each flow's state, so this approach is believed 597 scalable today using existing commercial technology. 599 Those applications that do not use IP address values in 600 application state or configuration data are considered to be 601 "well-behaved". For well-behaved applications, no further 602 enhancements are required. Where application-layer protocols are 603 not well-behaved, for example the File Transfer Protocol (FTP), 604 then the SBR might need to perform additional stateful processing 605 -- just as NAT and NAPT equipment needs to do today for FTP. See 606 the description in Section 7.6 of [ILNP-ENG]. 608 When the SBR rewrites a Locator in an ILNP packet, that obscures 609 information about how well a particular path is working between 610 the sender and the receiver of that ILNP packet. So, the SBR that 611 rewrites Locator values needs to include mechanisms to ensure 612 that any packet with a new Destination Locator will travel along 613 a valid path to the intended destination node. For ILNPv4, the 614 path liveness will be no worse than IPv4, and mechanisms already 615 in use for IPv4 can be re-used. For ILNPv6, the path liveness 616 will be no worse than for IPv6, and mechanisms already in use for 617 IPv6 can be re-used. 619 In the future, the Border Router Discovery Protocol (BRDP) also 620 might be used in some deployments to indicate which routing 621 prefixes are currently valid and which site border routers 622 currently have a working uplink [ID-BRDP11]. 624 3. AN ALTERNATIVE FOR SITE MULTI-HOMING 626 The ILNP Architectural Description [ILNP-ARCH] describes the 627 basic approach to enabling site multi-homing (S-MH) with ILNP. 628 However, as an option, it is possible to leave the control of 629 S-MH to an ILNP-enabled SBR. This alternative is based on the use 630 of the Localised Numbering function described in Section 2 of 631 this document. 633 3.1 Site multi-homing (S-MH) connectivity using an SBR 635 The approach to Site Multi-Homing (S-MH) using an SBR is best 636 illustrated through an example, as shown in Figure 3.1. 638 site . . . . +----+ 639 network SBR . .-----+ CN | 640 . . . . +------+ L_1 . . +----+ 641 . . | sbr1+------. . 642 . .L_L | | . . 643 . .----+ | . Internet . 644 . H . | | . . 645 . . | sbr2+------. . 646 . . . . +------+ L_2 . . 647 . . 648 . . . . 650 CN = Correspondent Node 651 H = Host 652 L_1 = global Locator value 1 653 L_2 = global Locator value 2 654 L_L = local Locator value 655 SBR = Site Border Router 656 sbrN = interface N on SBR 658 Figure 3.1: Alternative site multi-homing example with an SBR. 660 The situation here is similar to the localised numbering example, 661 except that the SBR now has two external links, with using 662 locator value L_1 and another using Locator value L_2. These 663 could, e.g. for ILNPv6, be separate, provider aggregated (PA) 664 IPv6 prefixes from two different ISPs. H has IL-V [I_H, L_L], and 665 will forward a packet to CN as given in expression (1a). However, 666 when the packet reaches the SBR, local policy will decide whether 667 the packet is forwarded on the link sbr1 using L_1 or on sbr2 668 using L_2. Of course, the correct Locator value will be re- 669 written into the egress packet in place of L_L. 671 If only local numbering is being used, then the SBR need never 672 advertise any global Locator values. However, it could do, as 673 described in Section 2.2. 675 3.2 Dealing with link/connectivity changes 677 One of the key uses for multi-homing is providing resilience to 678 link failure. If either link breaks, then the SBR can manage the 679 change in connectivity locally. For example, assume SBR has been 680 configured to use sbr1 for all traffic, and sbr2 only as backup 681 link. So, SBR directs packets from H to communicate with CN using 682 sbr1, and CN will receive packets as in expression (1b) and 683 respond with packets as in expression (2a). 685 However, if sbr1 goes down then SBR will move the communication 686 to interface sbr2. As H is not aware of the actions of the SBR, 687 the SBR must maintain some state about IL-V "pairs" in order 688 hand-off the connectivity from sbr1 to sbr2. So, when moving the 689 the communication to sbr2, the SBR would firstly send a Locator 690 Update (LU) message [ILNP-ICMPv4] [ILNP-ICMPv6], to CN informing 691 it that L_2 is now the valid Locator for the communication. This 692 operation would not be visible to H, although there might be some 693 disruption to transmission, e.g. packets being sent from CN to H 694 that are in flight when sbr1 goes down may be lost. The SBR might 695 also need to update DNS entries (see Section 3.3). Since ILNP 696 requires that all Locator Update messages be authenticated by the 697 ILNP Nonce, the SBR will need to include the appropriate Nonce 698 values as part of its cache of information about ILNP sessions 699 traversing the SBR. (NOTE: Since commercial security gateways 700 available as of this writing reportedly can handle full stateful 701 packet inspection for millions of flows at multi-gigabit speeds, 702 it should be practical for such devices to cache the ILNP flow 703 information, including Nonce values.) 705 This approach has some efficiency gains over the approach for 706 multi-homing described in [ILNP-ARCH], where each hosts manages 707 its own connectivity. 709 If sbr1 was to be re-instated, now with Locator value L_3, then 710 local policy would determine if the communication should be moved 711 back to sbr1, with appropriate additional actions, such as 712 transmission of LU messages with the new Locator values and also 713 the updates to DNS. 715 Note that in such movement of an ILNP session across interfaces 716 at the SBR, only Locator values in ILNP packets are changed. As 717 already noted in [ILNP-ARCH], end-to-end transport-layer session 718 state invariance is maintained. 720 3.3 SBR updates to DNS 722 When the SBR manages connectivity as described above, the internal 723 hosts, such as H, are not necessarily aware of any connectivity 724 changes. Indeed, there is certainly no requirement for them to be 725 aware. So, if H was a server expecting incoming connections, the 726 SBR must update the relevant DNS entries when the site 727 connectivity changes. 729 There are two possibilities: each host could have its own L32 730 or L64 records; or the site might use a combination of LP and 731 L32/L64 records (see Section 2.4). Either way, the SBR would need 732 to update the relevant DNS entries. For our example, with ILNPv6 733 and LP records in use, the SBR would need to manage two L64 734 records (one for each uplink) which would resolve from 735 a FQDN, for example, site.example.com. Meanwhile, individual 736 hosts, such as H, have an FQDN which resolves to an NID value and 737 an LP record that would contain the value site.example.com, which 738 then would be used to lookup the two L64 records. 740 If the SBR is multi-homed, as in Fig 3.1, then it will have (at 741 least) two Locator values, one for each link, and local policy 742 will need to be used to determine how preference values are 743 applied in the relevant L32 and L64 records. 745 3.4 DNS TTL values for L32 and L64 records 747 Imagine that in the scenario described above, there was a link 748 failure that resulted in sbr1 going down and sbr2 was used. 749 Existing ILNP sessions in progress would move to sbr2 as 750 described above. However, new incoming ILNP sessions to the site 751 would need to know to use L_2 and not L_1. L_1 and L_2 would be 752 stored in DNS records (e.g. L32 for ILNPv4 or L64 for ILNPv6). 753 If a remote host has already resolved from DNS that L_1 is the 754 correct Locator for sending packets to the site, then that host 755 might be holding stale information. 757 DNS allows values returned to be aged using Time-To-Live (TTL) 758 which is specified in the time unit of seconds. So that remote 759 nodes do not hold on to stale values from DNS, the L64 records for 760 our site should have low TTL values. An appropriate value must be 761 considered carefully. For example, let us assume that the site 762 administrator knows that when sbr1 fails, it takes 20 seconds to 763 failover to sbr2. Then, 20s would seem to be an appropriate time 764 to use for the TTL value of an L64 for the site: if a remote node 765 had just resolved the value L_1 for the site, and the link to sbr1 766 went down, that remote node would not hold the stale value of L_1 767 for any longer than it takes the site to failover to sbr2 and use 768 L_2. 770 Our studies for a university School site network show that low TTL 771 values, as low as zero, are feasible for operational use [BA11]. 773 NOTE: From 01 Nov 2010, the site network of the School of Computer 774 Science, University of St Andrews, UK, has been running 775 operational DNS with DNS A records that have TTL of zero. 776 At the time of writing of this note (05 Jan 2011), 777 a zero DNS TTL was still in use at the school. 779 3.5 Multiple SBRs 781 For site multi-homing, with multiple SBRs, a situation may be as 782 follows (see also Sec 5.3.1 in [ILNP-ARCH]). 784 site . . . . 785 network . . 786 . . . . +-------+ L_1 . . 787 . . | +------. . 788 . . | | . . 789 . .---+ SBR_A | . . 790 . . | | . . 791 . . | | . . 792 . . +-------+ . . 793 . . ^ . . 794 . . | CP . Internet . 795 . . v . . 796 . . +-------+ L_2 . . 797 . . | +------. . 798 . . | | . . 799 . .---+ SBR_B | . . 800 . . | | . . 801 . . | | . . 802 . . . . +-------+ . . 803 . . 804 . . . . 806 CP = coordination protocol 807 L_1 = global Locator value 1 808 L_2 = global Locator value 2 809 SBR_A = Site Border Router A 810 SBR_B = Site Border Router P 812 Figure 3.2: A dual-router multi-homing scenario for ILNP. 814 The use of two physical routers provides an extra level of 815 resilience compared to the scenario of Fig 3.1. The coordination 816 protocol (CP) between the two routers keeps their actions in 817 synchronisation according to whatever management policy is in 818 place for the site network. Such functions are available today in 819 some commercial network security products. Note that, logically, 820 there is little difference between Fig 5.1 and Fig 3.2, but with 821 two distinct routers in Fig 3.2, the interaction using CP is 822 required. Of course, it is also possible to have multiple 823 interfaces in each router and more than two routers. 825 4. AN ALTERNATIVE FOR SITE (NETWORK) MOBILITY 827 The ILNP Architectural Description [ILNP-ARCH] describes the basic 828 approach to enabling site (network) mobility with ILNP. However, 829 as an option, it is possible to leave the control of site mobility 830 to an ILNP-enabled SBR by exploiting the alternative site 831 multi-homing feature described in Section 3 of this document. 833 Again, as described in [ILNP-ARCH], we exploit the duality between 834 mobility and multi-homing for ILNP. 836 4.1 Site (network) mobility 838 Let us consider the mobile network in Figure 4.2, which is taken 839 from [ILNP-ARCH]. 841 site ISP_1 842 network SBR . . . 843 . . . . +------+ L_1 . . 844 . . L_L | ra1+------. . 845 . .----+ | . . 846 . H . | ra2+-- . . 847 . . . . +------+ . . 848 . . . 850 Figure 4.1a: ILNP mobile network before handover. 852 site ISP_1 854 network SBR . . . 855 . . . . +------+ L_1 . . 856 . . L_L | ra1+------. . . . . 857 . .----+ | . . 858 . H . | ra2+------. . 859 . . . . +------+ L_2 . . . . . 860 . . 861 . . . 862 ISP_2 864 Figure 4.1b: ILNP mobile network during handover. 866 site ISP_2 867 network SBR . . . 868 . . . . +------+ . . 869 . . L_L | ra1+-- . . 870 . .----+ | . . 871 . H . | ra2+------. . 872 . . . . +------+ L_2 . . 873 . . . 875 Figure 4.1c: ILNP mobile network after handover. 877 H = host 878 L_1 = global Locator value 1 879 L_2 = global Locator value 2 880 L_L = local Locator value 881 raN = radio interface N 882 SBR = Site Border Router 884 Figure 4.1: An alternative mobile network scenario with an SBR. 886 We assume that the site (network) is mobile, and the SBR has two 887 radio interfaces ra1 and ra2. In the figure, ISP_1 and ISP_2 are 888 separate, radio-based service providers, accessible via interfaces 889 ra1 and ra2. 891 While the SBR makes the transition from using a single link (Fig. 892 4.1a) to the hand-over overlap on both links (Fig 4.1b), to only 893 using a single link again (Fig 4.1c), the host H continues to use 894 only Locator value L_L, as already described for site multi-homing 895 (S-MH). During this time the actions taken by the SBR are the same 896 as already described in [ILNP-ARCH], except that the SBR: 898 a) also performs that ILNP localised numbering function 899 described in Section 2. 900 b) does not need to advertise L_1 and L_2 internally if only 901 local numbering is being used. 903 As for the case of S-MH above, H need not be aware of the change 904 in connectivity for the SBR if it is only using local numbering, 905 and the SBR would send LU messages for H (for any correspondent 906 nodes, not shown in Fig 4.1), and would update DNS entries as 907 required. 909 The difference to the S-MH scenario described earlier in this 910 document is that in the situation of Fig 4.1b, the SBR can opt to 911 use soft handover has previously described in [ILNP-ARCH]. 913 Again, there is an efficiency gain compared to the situation 914 described in [ILNP-ARCH]: the SBR provides a convenient point at 915 which to centrally manage the movement of the site as a whole. 916 Note that in Fig 4.1b, the site is multi-homed. 918 As for S-MH, L_1 and L_2 could be advertised internally, as a 919 local policy decision, for those hosts that require direct control 920 of their connectivity. 922 Note that for handover, immediate handover will have a similar 923 behaviour to a link outage as described for S-MH. However, as ILNP 924 allows soft-handover, during the handover period, this should help 925 to reduce (perhaps even remove) packet loss. 927 4.3 SBR updates to DNS 929 As for S-MH, a similar discussion to Section 3.3 applies for 930 mobile networks with respect to the updates to DNS. As a mobile 931 network is likely to have more frequent changes to its 932 connectivity than a multi-homed network would due to connectivity 933 changes, the use of LP DNS records is likely to be particularly 934 advantageous here. 936 4.4 DNS TTL values for L32 and L64 records 938 As for S-MH, a similar discussion to Section 3.4 applies for 939 mobile networks with respect to the TTL of L32 and/or L64 records 940 that are used for the name of the mobile network. In the case of 941 the mobile network, it makes sense for the TTL to be aligned to 942 the time for handover. 944 5. TRAFFIC ENGINEERING OPTIONS 946 The use of Locator re-writing provides some simple yet useful 947 options for traffic engineering (TE) controlled from the edge-site 948 via the SBR, requiring no cooperation from the service provider 949 other than the provision of basic connectivity services, e.g. 950 physical connectivity, allocation of IP address prefixes and 951 packet forwarding. This does not preclude other TE options that 952 are already in use, such as use of MPLS, but we choose to 953 highlight here the specific options available and controllable 954 solely through the use of ILNP. 956 When a site network is multi-homed, we have seen that the use of 957 the Locator re-writing function permits the SBR to have 958 packet-by-packet control when forwarding on external links. 959 Various configuration and policies could be applied at the SBR in 960 order to control the egress and ingress traffic to the site 961 network. 963 5.1 Load balancing 965 Let us consider Figure 5.1, and assume ILNP local numbering is in 966 use; that H1, H2 and H3 use, respectively, Identifier values, I_1, 967 I_2 and I_3; and all of them use Locator value L_L. 969 site . . . . 970 network SBR . . 971 . . . . +------+ L_1 . . 972 . . | sbr1+------. . 973 . H2 .L_L | | . . 974 . H3 .----+ | . Internet . 975 . . | | . . 976 . H1 . | sbr2+------. . 977 . . . . +------+ L_2 . . 978 . . 979 . . . . 981 HN = host N 982 L_1 = global Locator value 1 983 L_2 = global Locator value 2 984 L_L = local Locator value 985 SBR = Site Border Router 986 sbrN = interface N on sbr 988 Figure 5.1: A site multi-homing scenario for traffic control. 990 The SBR could be configured, subject to local policy, to try to 991 control load across the external links. For example, it could be 992 configured initially with the following mappings: 994 srcI=I_1, sbr1 --- (3a) 995 srcI=I_2, sbr2 --- (3b) 996 srcI=I_3, sbr1 --- (3c) 998 These mappings direct packets matching course Identifier values 999 to particular outgoing interfaces. As load changes, these 1000 mappings could be changed. For example, expression (3c) could be 1001 changed to: 1003 srcI=I_3, sbr2 --- (4) 1005 and the SBR would need to send LU message to the correspondents of 1006 H3 (sbr to uses L_2 while sbr1 uses L_1). The egress connectivity 1007 is totally within control of the SBR under administrative policy, 1008 as already seen in the descriptions of multi-homing and mobility 1009 in this document. 1011 Of course, more complex policies are possible, based on: 1013 - whether ILNP sessions are incoming or outgoing 1014 - time of day 1015 - internal subnets 1017 and any number of criteria already in use for control of traffic. 1019 In expressions (3a,b,c) above, source I values are used. However: 1021 - destination I values could be used 1022 - source or destination L values could be used 1023 - mappings could be to L values, not to specific interfaces 1025 and, again, any number of criteria could be used to manipulate 1026 the packet path, based on filtering of values in header fields 1027 and local policy. 1029 With ILNP, hosts do not need to be aware of the operation of the 1030 SBR in this manner. 1032 Note, again, that in this scenario, there is nothing to prevent 1033 SBR from also advertising L_1 and L_2 into the site network. If 1034 required, administrative controls could be used to enable 1035 selective hosts in the site network to use L_1 and L_2 directly as 1036 described in [ILNP-ARCH]. 1038 5.2 Control of egress traffic paths 1040 Extending the scenario for load-balancing described above, it is 1041 also be possible for the ILNP-capable SBR to direct traffic along 1042 specific network paths based on the use of different L values, 1043 i.e. by using multiple prefixes assigned from upstream providers. 1045 Of course, as previously discussed, these prefixes can be Provider 1046 Aggregated (PA) and need not be Provider Independent (PI). 1048 Let us consider Figure 5.2, and assume ILNP local numbering is in 1049 use; that H1, H2 and H3 use, respectively, Identifier values, I_1, 1050 I_2 and I_3; and all of them use Locator value L_L. Let us also 1051 assume that the node CN uses IL-V [I_CN, L_CN]. 1053 site . . . . +----+ 1054 network SBR . .-----+ CN | 1055 . . . . +------+ L1,L2 . . +----+ 1056 . . | sbr1+--------. . 1057 . H2 .L_L | | . . 1058 . H3 .----+ sbr2+--------. Internet . 1059 . . | | L3,L4 . . 1060 . . | | . . 1061 . H1 . | sbr3+--------. . 1062 . . . . +------+ L5,L6 . . 1063 . . 1064 . . . . 1066 CN = correspondent node 1067 HN = host N 1068 LN = global Locator value N 1069 L_L = local Locator value 1070 SBR = Site Border Router 1071 sbrN = interface N on sbr 1073 Figure 5.2: A site multi-homing scenario for traffic control. 1075 Here, many configurations are possible. For example, for egress 1076 traffic: 1078 srcI=I_2, L2 --- (5a) 1079 srcI=I_3, L3 --- (5b) 1080 dstI=I_CN, L6 --- (5c) 1081 srcI=I_1 dstI=I_CN, L1 --- (5d) 1083 Expression (5a) maps all egress packets from H2 to have their 1084 source Locator value re-written to L2 (and implicitly to use 1085 interface sbr1). Expression (5b) maps all egress packets from H3 1086 to have their source Locator value re-written to L3 (and 1087 implicitly to use interface sbr2). Expression (5c) directs ay 1088 traffic to CN to use Locator value L6 as the source Locator (and 1089 implicitly to use interface sbr3), and may override (5a) and (5b), 1090 subject to local policy, when packets to CN are from H2 or H3. 1092 Meanwhile, in expression (5d), we see a further, more specific 1093 rule, in that packets from H1 destined to CN should use Locator 1094 value L1 (and implicitly to use interface sbr1). 1096 Note the implicit bindings to interfaces in expressions 1097 (5a,b,c,d), compared to the explicit bindings in expressions 1098 (3a,b,c). ILNP only requires that the Locator values are correctly 1099 re-written and packets forwarded in conformance with the routing 1100 already configured for the Locator values. 1102 Of course, these rules can be changed dynamically at the SBR, and 1103 the SBR will migrate ILNP sessions across Locator values, as 1104 already described above for mobility. 1106 6. ILNP IN DATACENTRES 1108 As ILNP has first class support for mobility and multi-homing, 1109 and supports flexible options for localised addressing, there is 1110 great potential for it to be used in datacentre scenarios. Further 1111 details of possibilities are in [BA12], with a summary presented 1112 here. 1114 There are several scenarios that could be beneficial to 1115 datacentres, in order to provide functions such as load 1116 balancing, resilience and fault tolerance, and resource 1117 management: 1119 - Same datacentre, internal VM mobility: This could be beneficial 1120 in load balancing, dynamically, where load changes are taking 1121 place. The remote user does not see the VM has moved. 1123 - Different datacentres, transparent mobility: This is where the 1124 datacentre resources may be geographically distributed, but 1125 the geographical movement is transparent to the remote user. 1127 - Different datacentres, mobility is visible: This is where the 1128 datacentre resources may be geographically distributed, but 1129 the geographical movement is visible to the remote user. 1131 These are three situations which may be supported by ILNP, but 1132 they are not the only ones: we provide these here as examples, 1133 and they are not intended to be prescriptive. The intention is 1134 only to show the flexibility that is possible through the use of 1135 ILNP. 1137 This section describes some Virtual Machine (VM) mobility 1138 capabilities that are possible with ILNP. Depending on the 1139 internal details and virtualisation model provided by a VM 1140 platform, it might be sufficient for the guest operating system 1141 to support ILNP. In a some cases, again depending on the internal 1142 details and virtualisation model provided by a VM platform, the 1143 VM platform itself also might need to include support for ILNP. 1145 Details of how a particular VM platform works, and which 1146 virtualisation model(s) a VM platform supports, are beyond the 1147 scope of this document. Internal implementation details of VM 1148 platform support for ILNP are also beyond the scope of this 1149 document, just as internal implementation details for any other 1150 networked system supporting ILNP are beyond the scope of this 1151 document. 1153 6.1 Virtual image mobility within a single datacentre 1155 Let us consider first the scenario of Figure 6.1, noting its 1156 similarity to Figure 2.1 for use of localised numbering. 1158 site . . . . +----+ 1159 network SBR . .-----+ CN | 1160 . . . . +------+ L_1 . . +----+ 1161 . . | +------. . 1162 . H2 .L_L | | . . 1163 . .----+ | . Internet . 1164 . V*H1 . | | . . 1165 . . | | . . 1166 . . . . +------+ . . 1167 . . 1168 . . . . 1170 CN = Correspondent Node 1171 V = Virtual machine image 1172 Hx = Host x 1173 L_1 = global Locator value 1174 L_L = local Locator value 1175 SBR = Site Border Router 1177 Figure 6.1: A simple virtual image mobility example for ILNP. 1179 L_L is a Locator value used for the ILNP hosts H1 an H2. Here, 1180 the "V*H1" signifies that the virtual machine image V is 1181 currently resident on H1. Let us assume that V has Identifier 1182 I_V. Note that as H1 and H2 have the same Locator value (L_1), as 1183 far as CN is concerned, it does not matter if V is resident on H1 1184 or H2, all transport packets between V and CN will have the same 1185 signature as far as CN is concerned, e.g. for a UDP flow (in 1186 analogy to (1a)): 1188 --- (6a) 1190 Now, if V was to migrate to H2, the migration would be an issue 1191 purely local to the site-network, and the end-to-end integrity of 1192 the transport flow would be maintained. 1194 Of course, there are practical operating systems issues in 1195 enabling such a migration locally, but products exist today that 1196 could be modified and made ILNP-aware in order to enable such VM 1197 image mobility. 1199 Note that for convenience, above, we have used localised 1200 numbering for ILNP, but if local Locator values were not used and 1201 the whole site simply used L_1, the principle would be the same. 1203 6.2 Virtual image mobility between data centres - invisible 1205 Let us now consider an extended version of the scenario above in 1206 Fig. 6.2, where we see that there is a second site network, which 1207 is geographically distant to the first site network, and the two 1208 site networks are interconnected via their respective SBRs. 1210 site . . . . +----+ 1211 network 1 SBR1 . .-----+ CN | 1212 . . . . +------+ L_1 . . +----+ 1213 . . | +------. . 1214 . .L_L1| | . . 1215 . .----+ | . Internet . 1216 . V*H1 . | | . . 1217 . . | | . . 1218 . . . . +---+--+ . . 1219 : . . 1220 : . . 1221 . . . . +---+--+ L_2 . . 1222 . . | +------. . 1223 . H2 .L_L2| | . . 1224 . .----+ | . . 1225 . . | | . . 1226 . . | | . . 1227 . . . . +------+ . . 1228 site SBR2 . . 1229 network 2 . . . . 1231 : = logical inter-router link and coordination 1232 CN = Correspondent Node 1233 V = Virtual machine image 1234 Hx = Host x 1236 L_y = global Locator value y 1237 L_Lz = local Locator value z 1238 SBR = Site Border Router 1240 Figure 6.2: A simple localised numbering example for ILNP. 1242 Note that the logical inter-router link between SBR1 and SBR2 1243 could be realised physically in many different ways that are 1244 available today and are not ILNP specific, e.g. leased line, 1245 secure IP-layer or layer-2 tunnel, etc. We assume that this link 1246 also allows coordination between the two SBRs. For now, we ignore 1247 external link L_2 on SBR2, and assume that the remote node, CN, 1248 is in communication with V through SBR1. 1250 When in initial communication, the packets have the signature is 1251 given in expression (6a). When V moves to H2, it now uses Locator 1252 value L_L2, but all communication between V and CN is still 1253 routed via SBR1. So, the remote CN still sees that same packet 1254 signature as given in expression (6a). L_L1 and L_L2 are, 1255 effectively, two internal (private) subnetworks, and are not 1256 visible to CN. 1258 However, SBR2 and SBR1 must coordinate so that any further 1259 communication to V via SBR1 is routed across the inter-router 1260 link. Again, there are commercial products today that could be 1261 adapted to manage such shared state. 1263 6.3 Virtual image mobility between data centres - visible 1265 Clearly, in the scenario of the section above, once V has moved 1266 to site network 2, it may be beneficial, for a number of reasons, 1267 for communication to V to be routed via SBR2 rather than SBR1. 1269 When V moves from site network 1 to site network 2, this 1270 visibility of mobility could be by V sending ILNP Locator Update 1271 messages to the CN during the mobility process. Also, V would 1272 update any relevant ILNP DNS records, such as L64 records, for 1273 new ILNP session requests to be routed via SBR2. 1275 Indeed, let us now consider again Fig 6.2, and assume now that 1276 Local locators L_L1 and L_L2 are not in use on either site 1277 network, and each site networks uses its own global Locator 1278 value, L_1 and L_2, respectively, internally. In that case, the 1279 packet flow signature for V when it is in site network 1 as 1280 viewed from CN is, again as given in expression (6a). However, 1281 when V moves to site network 2, it would simply use L_2 as its 1282 new Locator, send Locator Update messages to CN as would a normal 1283 mobile node for ILNP, and complete its migration to H2. Then, CN 1284 would see the packet signatures as in expression (6b). 1286 --- (6b) 1288 In this case, no "special" inter-router link is required for 1289 mobility - the normal Internet connectivity between SBR1 and SBR2 1290 would suffice. However, it is quite likely that some sort of 1291 tunnelled link would still be desirable to offer protection of 1292 the VM image as it migrates. 1294 6.4 ILNP capability in the remote host for VM image mobility 1296 For the remote host - the correspondent node (CN) - the 1297 availability of ILNP would be beneficial. However, for the first 1298 two scenarios listed above, as the packet signature of the 1299 transport flows remains fixed from the viewpoint of the CN, it 1300 seems possible that the benefits of ILNP VM mobility could be 1301 used for datacentres even while CNs remain as normal IP hosts. 1302 Of course, a major caveat here is that the application level 1303 protocols should be "well-behaved": that is, the application 1304 protocol or configuration should not rely on the use of IP 1305 addresses. 1307 7. LOCATION PRIVACY 1309 Extending the Locator re-writing paradigm, it is possible to also 1310 enable Location privacy for ILNP by a modified version of the 1311 "onion routing" paradigm that is used for Tor [DMS04] [RSG98]. 1313 7.1 Locator Re-writing Relay (LRR) 1315 To enable this function, we use a middlebox which we call the the 1316 Locator Re-writing Relay. The function of this unit is described 1317 by the use of Figure 7.1. 1319 --- (7a) 1321 v 1322 | 1323 +--+--+ 1324 | | src=[I_H, L_1], L_X --- (7b) 1325 | LRR | dst=[I_H, L_X], L_1 --- (7c) 1326 | | 1327 +--+--+ 1328 | 1329 v 1331 --- (7d) 1333 LRR = Locator Re-writing Relay 1335 Figure 7.1: Locator Re-Writing Relay (LRR) example 1337 The operation of the LRR is conceptually very simple. We assume 1338 that the LRR first has mappings as given in expressions (7b) and 1339 (7c) (see next sub-section). Expression (7b) says that for 1340 packets with src IL-V [I_H, L_1], the packet's source Locator 1341 value should be re-written to value L_X and then forwarded. 1342 Expression (7c) has the complimentary mapping for packets with 1343 destination IL-V [I_H, L_1] (for the reverse direction). 1345 Expression (6a) is a UDP/ILNP packet as might be sent in Figure 1346 2.1 from H to CN. However, instead of going directly to L_CN, the 1347 packet with destination Locator L_1 goes to a LRR. Expression 1348 (7d) is the result of the mapping of packet (7a) using expression 1349 (7b). 1351 Note that it is entirely possible that the packet of expression 1352 (7d) then is processed by another LRR for source Locator value 1353 L_X. Effectively, this creates and LRR path for the packet, as an 1354 overlay path on top of the normal IP routing. 1356 In this way, there is a level of protection, without the need for 1357 cryptographic techniques, for the (topological) Location of the 1358 packet. Of course, an extremely well-resourced adversary could, 1359 potentially, backtrack the LRR path, but, depending on the LRR 1360 overlay path that is created, could be very difficult to trace in 1361 reality. For example, the mechanism will protect against off-path 1362 attacks, but where the threat regime includes the potential for 1363 on-path attacks, cryptographically protected tunnels between H 1364 and LRR might be required. 1366 Again, as the Locator value is not part of the end-to-end state, 1367 this mechanism is very general and has a low overhead. 1369 7.2 Options for installing LRR packet forwarding state 1371 There are many options for managing the "network" of LRRs that 1372 could be in place if such a system was used on a large scale, 1373 including the setting up and removal of LRR state for packet 1374 relaying, as for expressions (7b) and (7c). We consider this 1375 function to be outside the scope of these ILNP specifications, 1376 but note that there are many existing mechanisms that could 1377 modified for use, and also many possibilities for new mechanisms 1378 that would be specific to the use of ILNP LRRs. 1380 (Note also that the control/management communication with the LRR 1381 does not need to use ILNP: IPv4 or IPv6 could be used.) 1383 The host, H, by itself could install the required state, assuming 1384 it was aware of suitable information to contact the LRR. The 1385 first packet in an ILNP session might contain a header option 1386 called a Locator Redirection Option (LRO). The LRO would contain 1387 the Locator value that should be re-written into the source 1388 Locator of the packet. When a LRR receives such a packet, it 1389 would install the required state. Such a mechanism could be soft- 1390 state, requiring periodic use of the LRO in order to maintain the 1391 state in the LRR. The LRO could also be delivered using an ICMP 1392 ECHO packet sent from H to the LRR, periodically, again to 1393 maintain a soft-state update. 1395 It would, of course, be prudent to protect the LRR state control 1396 packets with some sort of authentication token, to prevent an 1397 adversary from easily installing false LRR state and causing packets 1398 from H or its correspondent to be subject to man-in-the-middle 1399 attacks, or black-holing. Again, such attacks are not specific 1400 to ILNP or new to ILNP. 1402 It would also be possible to use proprietary application level 1403 protocols, with strong authentication for the control of the LRR 1404 state. For example, an application level protocol based on XMPP 1405 (http://xmpp.org/) operating over SSL. 1407 Above, we have offered very brief and incomplete descriptions of 1408 some possibilities, and we do not necessarily mandate any one of 1409 them: they serve only as examples. 1411 8. IDENTITY PRIVACY 1413 For the sake of completeness, and in complement to Section 6, it 1414 should be noted that ILNP can use either cryptographically 1415 verifiable Identifier values, or use Identifier values that 1416 provide a level of anonymity to protect a user's privacy. More 1417 details are given in Section 2 and 11 of [ILNP-ENG]. 1419 9. SECURITY CONSIDERATIONS 1421 The relevant security considerations to this document are 1422 the same as for the main ILNP Architectural Description 1423 [ILNP-ARCH]. The one additional point to note is that this 1424 document describes ILNP capability in the SBR and so those 1425 adversaries wishing to subvert the operation of ILNP 1426 specifically, have a target that would, potentially, disable 1427 an entire site. However, this is not an attack vector that is 1428 specific to ILNP: today, disruption of an IPv4 or IPv6 SBR 1429 would have the same impact. 1431 The security considerations for Section 7 (Location Privacy) are 1432 already documented in [DMS04] and [RSG98]. One possibility is 1433 that the LRR mechanism itself could be used by an adversary to 1434 launch an attack and hide his own (topological) Location, for 1435 example. This is already possible for IPv4 and IPv4 with a 1436 Tor-like system today, so is not new to ILNP. 1438 10. IANA Considerations 1440 There are no IANA considerations for this document. 1441 (Note to RFC Editor: please remove this section 1442 prior to publication.) 1444 11. REFERENCES 1446 11.1. Normative References 1448 [RFC1918] Y. Rekther, B. Moskowitz, D. Karrenberg & G. J. 1449 de Groot, 1450 "Address Allocation for Private Internets", 1451 RFC1918, Feb 1996 1453 [RFC2119] S. Bradner, "Key Words for Use in RFCs to 1454 Indicate Requirement Levels", RFC2119, 1455 March 1997. 1457 [RFC3022] P. Srisuresh & K. Egevang, 1458 "Traditional IP Network Address Translator 1459 (Traditional NAT)", 1460 RFC3022, Jan 2011. 1462 [RFC3484] R. Draves, "Default Address Selection for IPv6", 1463 RFC3484, Feb 2003. 1465 [RFC4193] R. Hinden and B. Haberman, "Unique Local IPv6 1466 Unicast Addresses", RFC4193, October 2005. 1468 [RFC4632] V. Fuller and T. Li, "Classless Inter-domain 1469 Routing (CIDR): The Internet Address Assignment and 1470 Aggregation Plan", RFC4632, August 2006. 1472 [RFC4787] F. Audet & C. Jennings, "NAT Behavioural 1473 Requirements for Unicast UDP", RFC4787, 1474 January 2007. 1476 [RFC4864] G. Van de Velde, T. Hain, R. Droms, B. Carpenter & 1477 E. Klein, 1478 "Local Network Protection for IPv6", 1479 RFC4864, May 2007 1481 [RFC4924] B. Adoba & E. Davbies (eds), 1482 "Reflections on Internet Transparency", 1483 RFC4924, Jul 2007 1485 [RFC5902] D. Thaler, L. Zhang & G. Lebovitz, 1486 "IAB Thoughts on IPv6 Network Address Translation", 1487 RFC5902, Jul 2010 1489 [RFC6177] T. Narten, G. Huston, L. Roberts, "IPv6 Address 1490 Assignment to End Sites", RFC6177 (BCP157), March 1491 2011. 1493 [ILNP-ARCH] R.J. Atkinson & S.N. Bhatti, 1494 "ILNP Architectural Description", 1495 draft-irtf-rrg-ilnp-arch, 10 July 2012. 1497 [ILNP-ARP] R.J. Atkinson & S.N. Bhatti, "ARP Extension for 1498 ILNPv4", draft-irtf-rrg-ilnp-arp, 10 July 2012. 1500 [ILNP-DNS] R.J. Atkinson, S.N. Bhatti, & S Rose, 1501 "DNS Resource Records for ILNP", 1502 draft-irtf-rrg-ilnp-dns, 10 July 2012. 1504 [ILNP-ENG] R.J. Atkinson & S.N. Bhatti, 1505 "ILNP Engineering and Implementation Considerations", 1506 draft-irtf-rrg-ilnp-eng, 10 July 2012. 1508 [ILNP-ICMPv4] R.J. Atkinson & S.N. Bhatti, 1509 "ICMPv4 Locator Update message" 1510 draft-irtf-rrg-ilnp-icmpv4, 10 July 2012. 1512 [ILNP-ICMPv6] R.J. Atkinson & S.N. Bhatti, 1513 "ICMPv6 Locator Update message" 1514 draft-irtf-rrg-ilnp-icmpv6, 10 July 2012. 1516 [ILNP-NONCEv6] R.J. Atkinson & S.N. Bhatti, 1517 "IPv6 Nonce Destination Option for ILNPv6", 1518 draft-irtf-rrg-ilnp-noncev6, 10 July 2012. 1520 [ILNP-v4OPTS] R.J. Atkinson & S.N. Bhatti, 1521 "IPv4 Options for ILNP", 1522 draft-irtf-rrg-ilnp-v4opts, 10 July 2012. 1524 11.2. Informative References 1526 [ABH07a] R. Atkinson, S. Bhatti, & S. Hailes, 1527 "Mobility as an Integrated Service Through the Use of 1528 Naming", Proceedings of ACM Workshop on Mobility 1529 in the Evolving Internet Architecture (MobiArch), 1530 ACM SIGCOMM, Kyoto, Japan. 27 Aug 2007. 1532 [ABH07b] R. Atkinson, S. Bhatti, & S. Hailes, 1533 "A Proposal for Unifying Mobility with Multi-Homing, 1534 NAT, & Security", Proceedings of 2nd ACM Workshop on 1535 Mobility Management and Wireless Access (MobiWAC), 1536 ACM, Chania, Crete. Oct 2007. 1537 ISBN: 978-1-59593-809-1 1539 [ABH08a] R. Atkinson, S. Bhatti, & S. Hailes, 1540 "Mobility Through Naming: Impact on DNS", Proceedings 1541 of 3rd ACM Workshop on Mobility in the Evolving 1542 Internet Architecture (MobiArch), ACM SIGCOMM, 1543 Seattle, WA, USA. Aug 2008. 1545 [ABH08b] R. Atkinson, S. Bhatti, & S. Hailes, 1546 "Harmonised Resilience, Security, and Mobility 1547 Capability for IP", Proceedings of the IEEE 1548 Military Communications Conference (MILCOM), 1549 IEEE, San Diego, CA, USA. Nov 2008. 1551 [ABH09a] R. Atkinson, S. Bhatti, & S. Hailes, 1552 "Site-Controlled Secure Multi-Homing and Traffic 1553 Engineering For IP", Proceedings of IEEE 1554 Military Communications Conference (MILCOM), IEEE, 1555 Boston, MA, USA. Oct 2009. 1557 [ABH09b] R. Atkinson, S. Bhatti, S. Hailes, 1558 "ILNP: Mobility, Multi-Homing, Localised Addressing and 1559 Security Through Naming"", Telecommunication Systems, 1560 vol. 42, no. 3-4, pp273-291, Springer-Verlag, Dec 2009. 1562 [ABH10] R. Atkinson, S. Bhatti, S. Hailes, 1563 "Evolving the Internet Architecture Through Naming", 1564 IEEE Journal on Selected Areas in Communication 1565 (JSAC), vol. 28, no. 8, pp1319-1325, IEEE, Oct 2010. 1567 [BA11] S. Bhatti & R. Atkinson, 1568 "Reducing DNS Caching", Proceedings of IEEE 1569 Global Internet Symposium (GI2011), Shanghai, 1570 P.R. China. 15 Apr 2011. 1572 [BA12] S. N. Bhatti & R. Atkinson, 1573 "Secure & Agile Wide-area Virtual Machine Mobility", 1574 Proceedings of IEEE Military Communications 1575 Conference (MILCOM), Orlando, FL, USA. Oct 2012. 1577 [BAK11] S. N. Bhatti, R. Atkinson, J. Klemets, 1578 "Integrating Challenged Networks", Proceedings of 1579 IEEE Military Communications Conference (MILCOM), 1580 IEEE, Baltimore, MD, USA. Nov 2011. 1582 [DMS04] R. Dingledine, N. Mathewson, & P. Syverson, 1583 "Tor: the second-generation onion router", 1584 Proceedings of 13th USENIX Security Symposium, USENIX 1585 Association, San Diego, CA, USA. 2004. 1587 [ID-appDNS] O. Kolman, J. Peterson, H. Tschofenig & B. Aboba, 1588 "Architectural Considerations on Application Features 1589 in the DNS", draft-iab-dns-applications, March 2012. 1591 [ID-BRDP11] T. Boot & A. Holtzer, "Border Router Discovery 1592 Protocol (BRDP) Framework", 1593 draft-boot-brdp-framework-00, Internet-Draft, 1594 31 Jan 2011. 1596 [ID-mDNS11] S. Cheshire, M. Krochmal, "Multicast DNS", 1597 draft-cheshire-dnsext-multicastdns-15, 09 Dec 2011. 1599 [IEEE04] "IEEE 802.1D - IEEE Standard for Local and Metropolitan 1600 Area Networks, Media Access Control (MAC) Bridges", 1601 IEEE Standards Association, New York, NY, USA, 9 June 1602 2004. 1603 Print: ISBN 0-7381-3881-5 SH95213 1604 PDF: ISBN 0-7381-3982-3 SS95213 1606 [LABH06] R. Atkinson, M. Lad, S. Bhatti, and S. Hailes, 1607 "A Proposal for Coalition Networking in Dynamic 1608 Operational Environments", Proceedings of IEEE 1609 Military Communications Conference (MILCOM), 1610 IEEE, Washington, DC, USA. Nov 2006. 1612 [RAB09] D. Rehunthan, R. Atkinson, S. Bhatti, 1613 "Enabling Mobile Networks Through Secure Naming", 1614 Proceedings of IEEE Military Communications 1615 Conference (MILCOM), IEEE, Boston, MA, USA, Oct 2009 1617 [RB10] D. Rehunathan, S. Bhatti, 1618 "A Comparative Assessment of Routing for Mobile 1619 Networks", Procedings of 6th IEEE International 1620 Conference on Wireless and Mobile Computing 1621 Networking and Communications (WiMob), IEEE, Niagara 1622 Falls, ON, Canada. Oct 2010. 1624 [RSG98] Michael G. Reed, Paul F. Syverson, and David 1625 M. Goldschlag, "Anonymous Connections and 1626 Onion Routing", IEEE Journal on Selected Areas 1627 in Communications, Vol. 16, No. 4, IEEE, 1628 Piscataway, NJ, USA, May 1998. 1630 [RFC4193] R. Hinden and B. Haberman, "Unique Local IPv6 Unicast 1631 Addresses", RFC4193, October 2005. 1633 [RFC6296] W. Wasserman, F. Baker, "IPv6-to-IPv6 Network Prefix 1634 Translation", RFC6296, June 2011. 1636 ACKNOWLEDGEMENTS 1638 Steve Blake, Stephane Bortzmeyer, Mohamed Boucadair, Noel 1639 Chiappa, Wes George, Steve Hailes, Joel Halpern, Mark Handley, 1640 Volker Hilt, Paul Jakma, Dae-Young Kim, Tony Li, Yakov Rehkter, 1641 Bruce Simpson, Robin Whittle and John Wroclawski (in alphabetical 1642 order) provided review and feedback on earlier versions of this 1643 document. Steve Blake provided an especially thorough review of 1644 an early version of the entire ILNP document set, which was 1645 extremely helpful. We also wish to thank the anonymous reviewers 1646 of the various ILNP papers for their feedback. 1648 Roy Arends provided expert guidance on technical and procedural 1649 aspects of DNS issues. 1651 RFC EDITOR NOTE 1653 This section is to be removed prior to publication. 1655 Please note that this document is written in British English, so 1656 British English spelling is used throughout. This is consistent 1657 with existing practice in several other RFCs, for example 1658 RFC-5887. 1660 This document tries to be very careful with history, in the 1661 interest of correctly crediting ideas to their earliest 1662 identifiable author(s). So in several places the first published 1663 RFC about a topic is cited rather than the most recent published 1664 RFC about that topic. 1666 Author's Address 1668 RJ Atkinson 1669 Consultant 1670 San Jose, CA 1671 95125 USA 1673 Email: rja.lists@gmail.com 1675 SN Bhatti 1676 School of Computer Science 1677 University of St Andrews 1678 North Haugh, St Andrews 1679 Fife, Scotland 1680 KY16 9SX, UK 1682 Email: saleem@cs.st-andrews.ac.uk 1684 Expires: 10 JAN 2013