idnits 2.17.1 draft-templin-iron-09.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 date (August 6, 2010) is 5013 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'VP' is mentioned on line 1405, but not defined == Missing Reference: 'CE' is mentioned on line 1438, but not defined == Missing Reference: 'VE' is mentioned on line 1676, but not defined == Missing Reference: 'VC' is mentioned on line 1612, but not defined == Missing Reference: 'B' is mentioned on line 1380, but not defined ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-06) exists of draft-ietf-grow-va-02 == Outdated reference: A later version (-04) exists of draft-ietf-v6ops-tunnel-security-concerns-02 == Outdated reference: A later version (-68) exists of draft-templin-intarea-seal-16 == Outdated reference: A later version (-40) exists of draft-templin-intarea-vet-16 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Research Task Force F. Templin, Ed. 3 (IRTF) Boeing Research & Technology 4 Internet-Draft August 6, 2010 5 Intended status: Informational 6 Expires: February 7, 2011 8 The Internet Routing Overlay Network (IRON) 9 draft-templin-iron-09.txt 11 Abstract 13 Since the Internet must continue to support escalating growth due to 14 increasing demand, it is clear that current routing architectures and 15 operational practices must be updated. This document proposes an 16 Internet Routing Overlay Network for supporting sustainable growth 17 through Provider Independent addressing while requiring no changes to 18 end systems and no changes to the existing routing system. This 19 document is a product of the IRTF Routing Research Group (RRG). 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on February 7, 2011. 38 Copyright Notice 40 Copyright (c) 2010 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. The Internet Routing Overlay Network (IRON) . . . . . . . . . 5 58 3.1. IR[CE] - IRON Customer Edge Router . . . . . . . . . . . . 7 59 3.2. IR[VE] - IRON Virtual Prefix Company Edge Router . . . . . 7 60 3.3. IR[VC] - IRON Virtual Prefix Company Core Router . . . . . 8 61 3.4. IR[VP] - IRON Virtual Prefix Company Combined Router . . . 9 62 4. IRON Organizational Principles . . . . . . . . . . . . . . . . 10 63 5. IRON Initialization . . . . . . . . . . . . . . . . . . . . . 12 64 5.1. IR[VC] Initialization . . . . . . . . . . . . . . . . . . 12 65 5.2. IR[VE] Initialization . . . . . . . . . . . . . . . . . . 12 66 5.3. IR[CE] Initialization . . . . . . . . . . . . . . . . . . 13 67 6. IRON Operation . . . . . . . . . . . . . . . . . . . . . . . . 13 68 6.1. IR[CE] Operation . . . . . . . . . . . . . . . . . . . . . 14 69 6.2. IR[VE] Operation . . . . . . . . . . . . . . . . . . . . . 16 70 6.3. IR(VC) Operation . . . . . . . . . . . . . . . . . . . . . 17 71 6.4. IRON Reference Operating Scenarios . . . . . . . . . . . . 17 72 6.4.1. Both Hosts Within IRON EUNs . . . . . . . . . . . . . 18 73 6.4.2. Mixed IRON and Non-IRON Hosts . . . . . . . . . . . . 24 74 6.5. Mobility, Multihoming and Traffic Engineering 75 Considerations . . . . . . . . . . . . . . . . . . . . . . 27 76 6.5.1. Mobility Management . . . . . . . . . . . . . . . . . 27 77 6.5.2. Multihoming . . . . . . . . . . . . . . . . . . . . . 28 78 6.5.3. Inbound Traffic Engineering . . . . . . . . . . . . . 28 79 6.5.4. Outbound Traffic Engineering . . . . . . . . . . . . . 28 80 6.6. Renumbering Considerations . . . . . . . . . . . . . . . . 28 81 6.7. NAT Traversal Considerations . . . . . . . . . . . . . . . 29 82 6.8. Nested EUN Considerations . . . . . . . . . . . . . . . . 29 83 6.8.1. Host A Sends Packets to Host Z . . . . . . . . . . . . 30 84 6.8.2. Host Z Sends Packets to Host A . . . . . . . . . . . . 32 85 7. Additional Considerations . . . . . . . . . . . . . . . . . . 33 86 8. Related Initiatives . . . . . . . . . . . . . . . . . . . . . 33 87 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 88 10. Security Considerations . . . . . . . . . . . . . . . . . . . 34 89 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 90 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 91 12.1. Normative References . . . . . . . . . . . . . . . . . . . 34 92 12.2. Informative References . . . . . . . . . . . . . . . . . . 34 93 Appendix A. IRON VPs Over Non-Native Internetworks . . . . . . . 36 94 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 38 96 1. Introduction 98 Growth in the number of entries carried in the Internet routing 99 system has led to concerns for unsustainable routing scaling 100 [I-D.narten-radir-problem-statement]. Operational practices such as 101 increased use of multihoming with IPv4 Provider-Independent (PI) 102 addressing are resulting in more and more fine-grained prefixes 103 injected into the routing system from more and more end user 104 networks. Furthermore, the forthcoming depletion of the public IPv4 105 address space has raised concerns for both increased deaggregation 106 (leading to yet further routing table entries) and an impending 107 address space run-out scenario. At the same time, the IPv6 routing 108 system is beginning to see growth in IPv6 Provider-Aggregated (PA) 109 prefixes [BGPMON] which must be managed in order to avoid the same 110 routing scaling issues the IPv4 Internet now faces. Since the 111 Internet must continue to scale to accommodate increasing demand, it 112 is clear that new routing methodologies and operational practices are 113 needed. 115 Several related works have investigated routing scaling issues and 116 proposed solutions. Virtual Aggregation (VA) [I-D.ietf-grow-va] and 117 Aggregation in Increasing Scopes (AIS) [I-D.zhang-evolution] are 118 global routing proposals that introduce routing overlays with Virtual 119 Prefixes (VPs) to reduce the number of entries required in each 120 router's Forwarding Information Base (FIB) and Routing Information 121 Base (RIB). Routing and Addressing in Networks with Global 122 Enterprise Recursion (RANGER) [RFC5720] examines recursive 123 arrangements of enterprise networks that can apply to a very broad 124 set of use case scenarios [I-D.russert-rangers]. In particular, 125 RANGER supports encapsulation and secure redirection by treating each 126 layer in the recursive hierarchy as a virtual non-broadcast, multiple 127 access (NBMA) "link". RANGER is an architectural framework that 128 includes Virtual Enterprise Traversal (VET) [I-D.templin-intarea-vet] 129 and the Subnetwork Adaptation and Encapsulation Layer (SEAL) 130 (including the SEAL Control Message Protocol (SCMP)) 131 [I-D.templin-intarea-seal] as its functional building blocks. 133 This document proposes an Internet Routing Overlay Network (IRON) 134 with goals of supporting sustainable growth while requiring no 135 changes to the existing routing system. IRON borrows concepts from 136 VA, AIS and RANGER, and further borrows concepts from the Internet 137 Vastly Improved Plumbing (Ivip) [I-D.whittle-ivip-arch] architecture 138 proposal along with its associated Translating Tunnel Router (TTR) 139 mobility extensions [TTRMOB]. Indeed, the TTR model to a great 140 degree inspired the IRON mobility architecture design discussed in 141 this document. The Network Address Translator (NAT) traversal 142 techniques adapted for IRON were inspired by the Simple Address 143 Mapping for Premises Legacy Equipment (SAMPLE) proposal 145 [I-D.carpenter-softwire-sample]. 147 IRON specifically seeks to provide scalable PI addressing without 148 changing the current BGP [RFC4271] routing system. IRON observes the 149 Internet Protocol standards [RFC0791][RFC2460]. Other network layer 150 protocols that can be encapsulated within IP packets (e.g., OSI/CLNP 151 [RFC1070], etc.) are also within scope. 153 The IRON is a global overlay network routing system comprising 154 Virtual Prefix Companies (VPCs) that own and manage Virtual Prefixes 155 (VPs) from which End User Network (EUN) PI prefixes (EPs) are 156 delegated to customer sites. The IRON is motivated by a growing 157 customer demand for multihoming, mobility management and traffic 158 engineering while using stable PI addressing to avoid network 159 renumbering [RFC4192][RFC5887]. The IRON uses the existing IPv4 and 160 IPv6 global Internet routing systems as virtual links for tunneling 161 inner network protocol packets within outer IPv4 or IPv6 headers 162 (see: Section 3). The IRON requires deployment of a small number of 163 new routers that can often be simple commodity hardware platforms. 164 No modifications to hosts, and no modifications to most routers are 165 required. 167 Note: This document is offered in compliance with Internet Research 168 Task Force (IRTF) document stream procedures [RFC5743]; it is not an 169 IETF product and is not a standard. The views in this document were 170 considered controversial by the IRTF Routing Research Group (RRG) but 171 the RG reached a consensus that the document should still be 172 published. The document will undergo a period of review within the 173 RRG and through selected expert reviewers prior to publication. The 174 following sections discuss details of the IRON architecture. 176 2. Terminology 178 This document makes use of the following terms: 180 End User Network (EUN) 181 an edge network that connects an organization's devices (e.g., 182 computers, routers, printers, etc.) to the Internet and possibly 183 also the IRON. 185 Internet Service Provider (ISP) 186 a service provider which physically connects customer EUNs to the 187 Internet. 189 Provider Aggregated (PA) prefix 190 a network layer address prefix delegated to an EUN by a service 191 provider. 193 Provider Independent (PI) prefix 194 a network layer address prefix delegated to an EUN by a third 195 party independently of the EUN's ISP arrangements. 197 Virtual Prefix (VP) 198 a highly-aggregated PI prefix block (e.g., an IPv4 /16, an IPv6 199 /20, an OSI NSAP prefix, etc.) that is owned and managed by a 200 Virtual Prefix Company (VPC). 202 Virtual Prefix Company (VPC) 203 a company that owns and manages a set of VPs from which it 204 delegates End User Network PI Prefixes (EPs) to EUNs 206 Master Virtual Prefix database (MVPd) 207 a distributed database that maintains VP-to-locator mappings for 208 all VPs in the IRON. 210 End User Network PI prefix (EP) 211 a more-specific PI prefix derived from a VP (e.g., an IPv4 /28, an 212 IPv6 /56, etc.) and delegated to an EUN by a VPC. 214 EP Address (EPA) 215 a network layer address taken from an EP address range and 216 assigned to the interface of an end system in an EUN. 218 locator 219 an IP address assigned to the interface of a router or end system 220 within a public or private network. Locators taken from public IP 221 address spaces are routable within the global Internet while 222 locators taken from private IP address spaces are routable only 223 within the network where the private IP addressing plan is 224 deployed. 226 Internet Routing Overlay Network (IRON) 227 an overlay network configured over the global Internet. The IRON 228 supports routing through encapsulation of inner packets with EPA 229 addresses within outer headers that use locator addresses. 231 3. The Internet Routing Overlay Network (IRON) 233 The Internet Routing Overlay Network (IRON) consists of IRON Routers 234 (IRs) that automatically tunnel the packets of end-to-end 235 communication sessions within encapsulating headers used for 236 Internetwork routing. IRs use Virtual Enterprise Traversal (VET) 237 [I-D.templin-intarea-vet] in conjunction with the Subnetwork 238 Encapsulation and Adaptation Layer (SEAL) [I-D.templin-intarea-seal] 239 to encapsulate inner network layer packets within outer headers as 240 shown in Figure 1: 242 +-------------------------+ 243 | Outer headers with | 244 ~ locator addresses ~ 245 | (IPv4 or IPv6) | 246 +-------------------------+ 247 | SEAL Header | 248 +-------------------------+ +-------------------------+ 249 | Inner Packet Header | --> | Inner Packet Header | 250 ~ with EP addresses ~ --> ~ with EP addresses ~ 251 | (IPv4, IPv6, OSI, etc.) | --> | (IPv4, IPv6, OSI, etc.) | 252 +-------------------------+ +-------------------------+ 253 | | --> | | 254 ~ Inner Packet Body ~ --> ~ Inner Packet Body ~ 255 | | --> | | 256 +-------------------------+ +-------------------------+ 258 Inner packet before Outer packet after 259 before encapsulation after encapsulation 261 Figure 1: Encapsulation of Inner Packets Within Outer IP Headers 263 VET specifies the automatic tunneling mechanisms used for 264 encapsulation, while SEAL specifies the format and usage of the SEAL 265 header as well as a set of control messages. Most notably, IRs use 266 SEAL to deterministically exchange and authenticate control messages 267 such as indications of Path Maximum Transmission Unit (PMTU) 268 limitations. 270 The IRON is manifested through a business model in which Virtual 271 Prefix Companies (VPCs) own and manage a set of IRs that are 272 distributed throughout the Internet and serve highly-aggregated 273 Virtual Prefixes (VPs). VPCs delegate sub-prefixes from their VPs 274 which they lease to customers as End User Network PI prefixes (EPs). 275 The customers in turn assign the EPs to their customer edge IRs which 276 connect their End User Networks (EUNs) to the IRON. VPCs may have no 277 affiliation with the ISP networks from which customers obtain their 278 basic connectivity. Therefore, VPCs can open for business and begin 279 serving their customers immediately without the need to coordinate 280 their activities with ISPs or with other VPCs. 282 The IRON requires no changes to end systems and no changes to most 283 routers in the Internet. Instead, the IRON comprises IRs that are 284 deployed either as new platforms or as modifications to existing 285 platforms. IRs may be deployed incrementally without disturbing the 286 existing Internet routing system, and act as waypoints (or "cairns") 287 for navigating the IRON. The functional roles for IRs are described 288 in the following sections. 290 3.1. IR[CE] - IRON Customer Edge Router 292 An "IR[CE]" is a Customer Edge router (or host with embedded gateway 293 function) that logically connects the customer's EUNs and their 294 associated EPs to the IRON via tunnels. IR[CE]s obtain EPs from VPCs 295 and use them to number subnets and interfaces within their EUNs. An 296 IR[CE] can be deployed on the same physical platform that also 297 connects the customer's EUNs to its ISPs, but it may also be a 298 separate router or even a singleton end system located within the 299 EUN. (This model applies even if the EUN connects to the ISP via a 300 Network Address Translator (NAT) - see Section 6.7). An IR[CE] 301 connects its EUNs to the IRON via tunnels as shown in Figure 2: 302 .-. 303 ,-( _)-. 304 +--------+ .-(_ (_ )-. 305 | IR[CE] |--(_ ISP ) 306 +---+----+ `-(______)-' 307 | <= T \ .-. 308 .-. u \ ,-( _)-. 309 ,-( _)-. n .-(_ (- )-. 310 .-(_ (_ )-. n (_ Internet ) 311 (_ EUN ) e `-(______)- 312 `-(______)-' l ___ 313 | s => (:::)-. 314 +----+---+ .-(::::::::) 315 | Host | .-(::::::::::::)-. 316 +--------+ (:::: The IRON ::::) 317 `-(::::::::::::)-' 318 `-(::::::)-' 320 Figure 2: IR[CE] Connecting EUN to the IRON 322 3.2. IR[VE] - IRON Virtual Prefix Company Edge Router 324 An "IR[VE]" is a VPC's overlay network edge router that provides 325 forwarding and mapping services for the EPs owned by customer 326 IR[CE]s. In typical deployments, a VPC will deploy many IR[VE]s 327 around the IRON in a globally-distributed fashion (e.g., as depicted 328 in Figure 3) so that IR[CE] clients can discover those that are 329 nearby. 331 +--------+ +--------+ 332 | IR[VE] | | IR[VE] | 333 | Boston | | Tokyo | 334 +--+-----+ ++-------+ 335 +--------+ \ / 336 | IR[VE] | \ ___ / 337 | Seattle| \ (:::)-. +--------+ 338 +------+-+ .-(::::::::)------+ IR[VE] | 339 \.-(::::::::::::)-. | Paris | 340 (:::: The IRON ::::) +--------+ 341 `-(::::::::::::)-' 342 +--------+ / `-(::::::)-' \ +--------+ 343 | IR[VE] + | \--- + IR[VE] | 344 | Moscow | +----+---+ | Sydney | 345 +--------+ | IR[VE] | +--------+ 346 | Cairo | 347 +--------+ 349 Figure 3: IR[VE] Global Distribution Example 351 An IR[VE] is a customer-facing tunnel endpoint router that IR[CE]s 352 form bidirectional tunnels with over the IRON. Each IR[VE] 353 associates with the VPC's Internet-facing IR[VC]s that can forward 354 packets from the IRON out to the native public Internet and vice- 355 versa as discussed in the next section. 357 3.3. IR[VC] - IRON Virtual Prefix Company Core Router 359 An "IR[VC]" is a VPC's overlay network core router that acts as a 360 gateway between the IRON and the native public Internet. Each VPC 361 configures one or more IR[VC]s which advertise the company's VPs into 362 the IPv4 and/or IPv6 global Internet BGP routing systems. Each 363 IR[VC] associates with all of the VPC's overlay network edge routers, 364 either via tunnels over the IRON or via a direct interconnect (e.g., 365 via an Ethernet cable, etc. ). The IR[VC] role is depicted in 366 Figure 4: 368 ,-( _)-. 369 .-(_ (_ )-. 370 (_ Internet ) 371 `-(______)-' 372 | 373 +----+---+ 374 | IR[VC] | 375 +----+---+ 376 _|_ 377 (:::)-. 378 .-(::::::::) 379 +--------+ .-(::::::::::::)-. +--------+ 380 | IR[VE] | (:::: The IRON ::::) | IR[VE] | 381 +--------+ `-(::::::::::::)-' +--------+ 382 `-(::::::)-' 384 +--------+ 385 | IR[VE] | 386 +--------+ 388 Figure 4: IR[VC] Connecting IRON to Native Internet 390 3.4. IR[VP] - IRON Virtual Prefix Company Combined Router 392 An "IR[VP]" is a VPC's overlay network router that combines the 393 functions of both the IR[VE] and IR[VC]. In that case, the IR[VE] 394 and IR[VC] functions can be thought of as "half-gateway" functions 395 that together comprise a unified IR[VP]. The IR[VE] and IR[VC] 396 functions can therefore be discussed separately even when both 397 functions reside within the same physical IR[VP] router as shown in 398 Figure 5: 400 ,-( _)-. 401 .-(_ (_ )-. 402 (_ Internet ) 403 `-(______)-' 404 | 405 +----------+----------+ 406 | IR[VC] half-gateway | 407 +---------------------+ 408 | IR[VE] half-gateway | 409 +----------+----------+ 410 <- IR[VP] Unified Gateway -> 411 _|_ 412 (:::)-. 413 .-(::::::::) 414 .-(::::::::::::)-. 415 (:::: The IRON ::::) 416 `-(::::::::::::)-' 417 `-(::::::)-' 419 Figure 5: IR[VP] Combining IR[VE] and IR[VC] Functions 421 4. IRON Organizational Principles 423 The IRON consists of the union of all VPC overlay networks worldwide. 424 Each such overlay network represents a distinct "patch" on the 425 Internet "quilt", where the patches are stitched together by tunnels 426 over the links, routers, bridges, etc that connect the public 427 Internet. When a new VPC overlay network is deployed, it becomes yet 428 another patch on the quilt. The IRON is therefore a composite 429 overlay network consisting of multiple individual patches, where each 430 patch can be discussed independently of all others. In particular, 431 each patch (i.e., each VP overlay network) can operate independently 432 of the other patches. (NB: each patch needs to be aware of the VPs 433 assigned to all other patches.) 435 Each VPC in the IRON maintains a set of IR[VC]s that connect its 436 overlay network directly to the public IPv4 and/or IPv6 Internets. 437 In particular, if the VPC serves IPv4 VPs the IR[VC]s must configure 438 locator addresses on the public IPv4 Internet, and if the VPC serves 439 IPv6 VPs the IR[VC]s must configure locator addresses on the public 440 IPv6 Internet. Each IR[VC] advertises the VPC's IPv4 VPs into the 441 IPv4 BGP routing system and advertises the VPC's IPv6 VPs into the 442 IPv6 BGP routing system. IR[VC]s will therefore receive packets with 443 EPA destination addresses sent by end systems in the Internet then 444 (re)encapsulate and forward them to the correct EPA-addressed end 445 systems connected to the VPC overlay network. 447 Each VPC also manages a set of IR[VE]s that connect its overlay 448 network directly to the public IPv4 and/or IPv6 Internets the same as 449 for IR[VC]s, except that IR[VE]s need not be BGP routers and can 450 often be simple commodity hardware platforms. As such, the IR[VE] 451 and IR[VC] functions can be deployed together on the same physical 452 platform as an IR[VP], or they may be deployed on separate platforms 453 (e.g., for load balancing purposes). Each IR[VE] maintains a working 454 set of IR[CE]s for which it caches EP-to-IR[CE] mappings in its 455 Forwarding Information Base (FIB). Each IR[VE] also in turn 456 propagates the list of EPs in its working set to each of the VPC's 457 IR[VC]s, e.g., via a dynamic routing protocol. Each IR[VE] will 458 therefore commonly track only the EPs for its current working set of 459 IR[CE]s, while each IR[VC] will maintain a full EP-to-IR[VE] mapping 460 table that represents reachability information for all EPs in the VPC 461 overlay network. 463 Customers establish IR[CE]s to connect their EUNs to the VPC overlay 464 network. Each EUN can connect to the overlay network via one or 465 multiple IR[CE]s as long as the multiple IR[CE]s coordinate with one 466 another, e.g., to mitigate EUN partitions. Unlike IR[VC]s and 467 IR[VE]s, IR[CE]s may use private addresses behind one or several 468 layers of NATs. The IR[CE] initially discovers a list of nearby 469 IR[VE]s through an exchange with its VPC, then forms tunnels with one 470 or more of the IR[VE]s through initial exchanges followed by periodic 471 keepalives. The IR[CE] then adds each such IR[VE] to its default 472 router list. 474 The IR[CE] forwards outbound packets from its EUNs by tunneling them 475 to an IR[VC]/IR[VE] that can forward them further toward their final 476 destination. When the IR[CE] configures a locator with the same 477 protocol version of its EPs, it tunnels packets with EPA destination 478 addresses to an IR[VC]/IR[VE] within the VPC overlay network that 479 manages the EUN of the final destination without involving one of the 480 IR[VE]s in its default router list. When the IR[CE] configures a 481 locator of a different protocol version than its EPs, or when it 482 forwards packets with non-EPA destination addresses, it instead 483 tunnels the packets to one of the IR[VE]s in its default router list. 485 If a flow of packets uses an EPA destination address, the IR[CE]/ 486 IR[VE] tunnels the initial packets of the flow by encapsulating them 487 within an outer header that also uses the EPA as a destination 488 address. It then forwards the encapsulated packets into the public 489 Internet where they will be routed to an IR[VC] that owns a VP that 490 covers destination. Thereafter, the IR[VE]/IR[CE] may receive 491 redirects from the IR[VC] informing it of a more direct route via an 492 IR[VE] that manages the EUN. If a flow of packets uses a non-EPA 493 address, however, the IR[CE] tunnels them to a IR[VE] in its default 494 router list which will then forward them into the public Internet. 496 These arrangements are necessary to avoid ingress filtering issues 497 and to allow for generally shortest path routes. 499 The IRON can also be used to support VPs of network layer protocols 500 that cannot be routed natively in the underlying Internetwork (e.g., 501 OSI/CLNP within the public Internet, IPv6 within in IPv4-only 502 Internetworks, IPv4 within IPv6-only Internetworks, etc.). In that 503 case, however, the native routing capabilities of the Internetwork 504 cannot be leveraged such that a more rigid structure that depends on 505 a globally-distributed mapping database is required. Further details 506 for support of IRON VPs over non-native Internetworks are discussed 507 in Appendix A. 509 5. IRON Initialization 511 IRON initialization entails the startup actions of IRs within the VPC 512 overlay network and customer EUNs. The following sections discuss 513 these startups procedures. 515 5.1. IR[VC] Initialization 517 Before its first operational use, each IR[VC] in a VPC overlay 518 network is pre-provisioned with the list of VPs that it will serve as 519 well as the locators for all IR[VE]s that belong to the same overlay 520 network. The IR[VC] is also provisioned with BGP peerings the same 521 as for any BGP router. 523 Upon startup, the IR[VC] engages in BGP routing exchanges with its 524 peers in the IPv4 and/or IPv6 Internets the same as for any BGP 525 router. It then connects to all of the IR[VE]s that service its VPs 526 (e.g., via a TCP connection over a two-way tunnel, via a route 527 reflector, etc.) for the purpose of discovering EP->IR[VE] mappings. 528 After the IR[VC] has thus fully populated its EP->IR[VE] mapping 529 information database, it is said to be "synchronized" wrt its VPs. 530 The IR[VC] then advertises its VPs into the IPv4 and/or IPv6 Internet 531 BGP routing systems and engages in ordinary packet forwarding 532 operations. 534 5.2. IR[VE] Initialization 536 Before its first operational use, each IR[VE] in a VPC overlay 537 network is pre-provisioned with the locators for all IR[VC]s that 538 serve the overlay network's VPs. In order to support route 539 optimization, the IR[VE] must also be pre-provisioned with the list 540 of all VPs in the IRON (i.e., and not just the VPs of it own overlay 541 network) so that it can discern EPA and non-EPA addresses. 543 Upon startup, the IR[VE] connects to all of the IR[VC]s in the 544 overlay network for the purpose of reporting its EP->IR[VE] mappings. 545 The IR[VE] then actively listens for IR[CE] customers which will 546 create a two-way tunnel while registering its EP prefixes. When a 547 new IR[CE] registers its EP prefixes, the IR[VE] informs all IR[VC]s 548 of the new EP additions; when an existing IR[CE] unregisters its EP 549 prefixes, the IR[VE] informs all IR[VC]s of the deletions. 551 5.3. IR[CE] Initialization 553 Before its first operational use, each IR[CE] must obtain one or more 554 EPs from a VPC along with a certificate and a public/private key pair 555 from the VPC that it can later use to prove ownership of its EPs. 556 This implies that each VPC must run its own key infrastructure to be 557 used only for the purpose of verifying a customer's claimed right to 558 use an EP. Hence, the VPC need not coordinate its key infrastructure 559 with any other organizations. In order to support route 560 optimization, the IR[CE] must also be pre-provisioned with the list 561 of all VPs in the IRON (i.e., and not just the VPs of this VPC) so 562 that it can discern EPA and non-EPA addresses. 564 Upon startup, the IR[CE] sends a router discovery message using an 565 implicit anycast procedure (see Section 6.1) to discover the nearest 566 IR[VC]. The IR[VC] will in turn return a list of locators of the 567 company's nearby IR[VE]s. (This list is analogous to the ISATAP 568 Potential Router List (PRL) [RFC5214].) The IR[CE] then selects a 569 subset of IR[VE]s from this list and tests them to determine those 570 that offer the best performance (see: Section 6.1). The IR[CE] then 571 registers its EP prefixes with one or more IR[VE]s and adds them to 572 its default router list. 574 6. IRON Operation 576 Following this IRON initialization, IRs engage in the steady-state 577 process of receiving and forwarding packets. All IRs forward 578 encapsulated packets over the IRON using the mechanisms of VET 579 [I-D.templin-intarea-vet] and SEAL [I-D.templin-intarea-seal], while 580 IR[VC]s and IR[VE]s additionally forward packets to and from the 581 native IPv6 and IPv4 Internets. IRs also use the SEAL Control 582 Message Protocol (SCMP) to coordinate with other IRs, including the 583 process of sending and receiving redirect messages for route 584 optimization. Each IR operates as specified in the following sub- 585 sections. 587 6.1. IR[CE] Operation 589 During its initialization phase, the IR[CE] first sends a SEAL 590 Control Message Protocol (SCMP) Router Solicitation (SRS) message 591 using an implicit anycast addressing scheme to determine the closest 592 IR[VC] in its VPC overlay network. In this procedure, the IR[CE] 593 sets the "Router Alert" bit in the SEAL header to alert the nearest 594 IR[VC] that this SRS message must be processed locally and not 595 forwarded. The IR[CE] then sets the source address of the SRS 596 message to one of its locator addresses and sets the destination 597 address of the message to one of its own EPA addresses. (If the EPA 598 address is of a different protocol version than the underlying 599 Internetwork routing system, however, the IR[CE] sets the destination 600 address to any EPA address of the Internetwork protocol version that 601 is covered by a VP owned by the VPC overlay network.) Normal 602 Internet routing will then convey the SRS message to the nearest 603 IR[VC] that advertises a VP that covers the EPA. When the IR[VC] 604 receives the SRS message, it notices that the Router Alert bit is set 605 and sends back an SCMP Router Advertisement (SRA) message that lists 606 the locator addresses of one or more nearby IR[VE] routers. 608 After the IR[CE] receives an SRS message from the nearby IR[VC] 609 listing the locator addresses of nearby IR[VE]s, it sends SRS test 610 messages to one or more of the locator addresses to elicit SRA 611 messages. The IR[VE] that configures the locator will include the 612 header of the soliciting SRS message in its SRA message so that the 613 IR[CE] can determine the number of hops along the forward path. The 614 IR[VE] also includes a metric in its SRA messages indicating its 615 current load average so that the IR[CE] can avoid selecting IR[VE]s 616 that are overloaded. The IR[VE] also includes a challenge/response 617 puzzle that the IR[CE] must answer if it wishes to enlist this 618 IR[VE]'s services. 620 When the IR[CE] receives these SRA messages, it can measure the round 621 trip time between sending the SRS and receiving the SRA as an 622 indication of round-trip delay. If the IR[CE] wishes the enlist the 623 services of a specific IR[VE] (e.g., based on the measured 624 performance), it then calculates the answer to the puzzle using its 625 keying information and sends the answer back to the IR[VE] in a new 626 SRS message that also contains all of the IR[CE]'s EP prefixes for 627 which it claims ownership. If the IR[CE] answered the puzzle 628 correctly, the IR[VE] will send back a new SRA message that includes 629 a non-zero default router lifetime and that signifies the 630 establishment of a two-way tunnel. (A zero default router lifetime 631 on the other hand signifies that the IR[VE] is currently unable to 632 establish a two-way tunnel, e.g., due to heavy load, due to 633 challenge/response failure, etc.) 634 Note that in the above procedure it is essential that the IR[CE] 635 select one and only one IR[VE]. This is to allow the VPC overlay 636 network mapping system to have one and only one active EP-to-IR[VE] 637 mapping at any point in time which shares fate with the IR[VE] 638 itself. If this IR[VE] fails, the IR[CE] will quickly select a new 639 one which will automatically update the VPC overlay network mapping 640 system with a new EP-to-IR[VE] mapping. 642 After selecting its serving IR[VE], the IR[CE] should register each 643 of its ISP connections with the IR[VE] in order to establish multiple 644 two-way tunnels for multihoming purposes. To do so, it sends 645 periodic SRS messages via each of its ISPs to establish additional 646 two-way tunnels and to keep each two-way tunnel alive. These 647 messages need not include challenge/response mechanisms since prefix 648 proof of ownership was already established in the initial exchange 649 and the SEAL ID in the SEAL header can be used to confirm that the 650 SRS message was sent by the correct IR[CE]. This implies that a 651 single SEAL_ID is used to represent the set of all two-way tunnels 652 between the IR[CE] and the IR[VE]. Therefore, there are multiple 653 two-way tunnels and the SEAL_ID names this "bundle" of tunnels. 655 If the IR[CE] ceases to receive SRA messages from its serving IR[VE] 656 via a specific ISP connection, it marks the IR[VE] as unreachable 657 from that address and therefore over that ISP connection. (The 658 IR[CE] must also inform its serving IR[VE] of this outage via one of 659 its working ISP connections.) If the IR[CE] ceases to receive SRA 660 messages from its serving IR[VE] via multiple ISP connections, it 661 marks the IR[VE] as unusable and quickly attempts to establish a 662 connection with a new IR[VE]. The act of establishing the connection 663 with a new serving IR[VE] will automatically purge the stale mapping 664 state associated with the old serving IR[VE]. 666 When an end system in an EUN has a packet to send, the packet is 667 forwarded through the EUN via normal routing until it reaches the 668 IR[CE], which then tunnels the packet either to its serving IR[VE]s 669 or to an IR[VC]/IR[VE] associated with the packet's destination. In 670 particular, if the IR[CE] does not configure a locator of the same 671 protocol version as the packet's destination or if the destination 672 address is a non-EPA address, the IR[CE] encapsulates the packet in 673 an outer header with its locator as the source address and the 674 locator of its serving IR[VE]s as the destination address. 675 Otherwise, the IR[CE] encapsulates the packet in an outer header with 676 its locator as the source address and the destination address of the 677 inner packet copied into the destination address of the outer packet. 678 The IR[CE] then forwards the encapsulated packet via one of its ISP 679 connections, where normal Internet routing will convey it to the 680 correct tunnel far end. 682 The IR[CE] uses the mechanisms specified in VET and SEAL to 683 encapsulate each forwarded packet. The IR[CE] further uses the SCMP 684 protocol to coordinate with other IRs, including accepting redirect 685 messages that indicate a better next hop. When the IR[CE] receives 686 an SCMP redirect, it checks the identification field of the 687 encapsulated message to verify that the redirect corresponds to a 688 packet that it had previously sent and accepts the redirect if there 689 is a match. Thereafter, subsequent packets forwarded by the source 690 IR[CE] will follow a route-optimized path. 692 6.2. IR[VE] Operation 694 After an IR[VE] is initialized, it responds to SRSs from IR[CE]s by 695 sending SRAs as described in Section 6.1. When the IR[VE] receives 696 an SRS message from a potential IR[CE], it sends back an SRA message 697 with a challenge/response puzzle. The IR[CE] in turn sends an SRS 698 message with an answer to the puzzle. If this authentication fails, 699 the IR[VE] discards the message. Otherwise, it creates tunnel state 700 for this new IR[CE], records the EPs in its FIB, and records the 701 locator address from the SCMP message as the link-layer address of 702 the next hop. The IR[VE] next sends an SRA message back to the 703 IR[CE] to complete the tunnel establishment. 705 When the IR[VE] receives an encapsulated packet from one of its 706 IR[CE] tunnel endpoints, it decapsulates the packet and examines the 707 inner destination address. If the inner destination address is an 708 EPA, the IR[VE] re-encapsulates the packet, sets the outer source 709 address of the packet to one of its own locator address, sets the 710 outer destination address of the packet to the inner destination 711 address then forwards the encapsulated packet into the Internet via a 712 default or more-specific route. If the inner destination address is 713 not an EPA, however, the IR[VE] either forwards it unencapsulated 714 into the Internet if it is able to do so without loss due to ingress 715 filtering or tunnels the packet over the IRON to an IR[VC] within its 716 VPC overlay network which will then decapsulate the packet and 717 forward it into the Internet. 719 When the IR[VE] receives an encapsulated packet from the Internet, if 720 the inner destination address matches an EP in its FIB the IR[VE] 'A' 721 re-encapsulates the packet using VET/SEAL and forwards it to its 722 client IR[CE] 'B' which in turn decapsulates the packet and forwards 723 it to the correct end system in the EUN. If 'B' has left notice with 724 'A' that it has moved to a new IR[VE] 'C', however, 'A' will instead 725 forward the re-encapsulated packet to 'C' and also send an SCMP 726 redirect message back to the source of the packet. In this way, 727 IR[CE]s can change between IR[VE]s (e.g., due to mobility events) 728 without exposing packets to loss. 730 6.3. IR(VC) Operation 732 After an IR[VC] has synchronized its VPs (see: Section 5.1) it 733 advertises the full set of the company's VP's into the IPv4 and/or 734 IPv6 Internet BGP routing systems. The VPs will be represented as 735 ordinary routing information in the BGP, and any packets originating 736 from the IPv4 or IPv6 Internet destined to an EPA covered by one of 737 the VPs will be forwarded into the VPC's overlay network by an 738 IR[VC]. 740 When an IR[VC] receives a packet from the Internet destined to an EPA 741 covered by one of its VPs, it looks in its FIB for a matching EP to 742 discover the locator of the serving IR[VE], then examines the packet 743 format. 745 If the packet is not a SEAL-encapsulated packet, the IR[VC] simply 746 encapsulates the packet with its own locator as the outer source 747 address and the locator of the IR[VE] as the outer destination 748 address and forwards the packet to the IR[VE]. 750 If the packet is a SEAL-encapsulated packet, however, the IR[VC] 751 examines the "Router Alert" flag in the SEAL header. If the Router 752 Alert flag is set, and the packet encodes an SRS message, the IR[VC] 753 sends an SRA message back to the source listing the locator addresses 754 of nearby IR[VE] routers. In all cases when the Route Alert flag is 755 set, the IR[VC] next discards the packet. 757 For all other SEAL-encapsulated packets, the IR[VC] sends an SCMP 758 redirect message back to the source of the packet with the locator of 759 the serving IR[VE] as the redirected target. The source and 760 destination addresses of the SCMP redirect message use the outer 761 destination and source addresses of the original packet, 762 respectively. This arrangement is necessary to allow the redirect 763 messages to flow through any NATs on the path. 765 After sending a redirect message, the IR[VC] then rewrites the outer 766 source address of the packet to one of its own locators, rewrites the 767 outer destination address of the packet to the locator of the IR[VE] 768 and forwards the (re)encapsulated packet to the IR[VE]. In this way, 769 the IR[VC] "bends" the initial encapsulated packets of a flow in 770 flight to deflect them toward a correct IR[VE], while subsequent 771 packets in the flow will be sent directly to the IR[VE] after the 772 source receives a redirect. 774 6.4. IRON Reference Operating Scenarios 776 The IRON is used to support communications when one or both hosts are 777 located within EP-addressed EUNs regardless of whether the EPs are 778 provisioned by the same VPC or by different VPCs . When both hosts 779 are within IRON EUNs, route optimizations that eliminate unnecessary 780 IR[VC]s from the path are possible. When only one host is within an 781 IRON EUN, however, route optimization cannot be used. 783 The following sections discuss the two scenarios. Note that it is 784 sufficient to discuss the scenarios in a unidirectional fashion, 785 i.e., by tracing packet flows only in the forward direction from the 786 source host to destination host. The reverse direction can be 787 considered separately, and incurs the same considerations as for the 788 forward direction. 790 6.4.1. Both Hosts Within IRON EUNs 792 When both hosts are within EP-addressed EUNs, the initial packets of 793 the flow may need to involve an IR[VC] of the destination host but 794 route optimization can eliminate the IR[VC] from the path for 795 subsequent packets. The two sub-scenarios that exist occur based on 796 whether or not the IR[CE] of the source host configures a locator of 797 the same version as the packet. The sub-cases are discussed in the 798 following sections. 800 6.4.1.1. IR[CE] of Source Host Configures a Locator of the Same 801 Protocol Version as the EPA 803 Figure 6 shows the flow of initial packets from host A to host B 804 within two EP-addressed EUNs when the IR[CE] of the source host A 805 configures a locator of the same protocol version as the inner 806 packet: 808 ________________________________________ 809 .-( .-. )-. 810 .-( ,-( _)-. )-. 811 .-( +=================+ _ +========+ )-. 812 .( // (_|| Internet|| _) || ). 813 .( // ||-(______)|| vv ). 814 .( // || || +------------+ ). 815 ( // vv || | IR[VE](B) |====+ ) 816 ( // +------------+ +------------+ \\ ) 817 ( // .-. | IR[VC](B) | .-. \\ ) 818 ( //,-( _)-. +------------+ ,-( _)-\\ ) 819 ( .||_ (_ )-. / .-(_ (_ ||. ) 820 ( _|| ISP A .) / (redirect) (__ ISP B ||_)) 821 ( ||-(______)-' / `-(______)|| ) 822 ( || | / | vv ) 823 ( +-----+-----+ <=/ +-----+-----+ ) 824 | IR[CE](A) | | IR[CE](B) | 825 +-----+-----+ The IRON +-----+-----+ 826 | ( (Overlaid on the native Internet) ) | 827 .-. .-( .-) .-. 828 ,-( _)-. .-(________________________)-. ,-( _)-. 829 .-(_ (_ )-. .-(_ (_ )-. 830 (_ IRON EUN A ) (_ IRON EUN B ) 831 `-(______)-' `-(______)-' 832 | | 833 +---+----+ +---+----+ 834 | Host A | | Host B | 835 +--------+ +--------+ 837 Figure 6: EPA/Locator Matching Scenario Before Redirects 839 In this scenario, host A sends its packets with destination address B 840 on its network interface connected to EUN A. (This interface could be 841 a physical interface such as an Ethernet NIC, an ISATAP tunnel 842 virtual interface with IR[CE](A) as a PRL router, etc.) Routing with 843 EUN A will direct the packets to IR[CE](A) as a default router for 844 the EUN which then uses VET and SEAL to encapsulate them in outer 845 headers with its locator address as the outer source address and B as 846 the outer destination address (i.e., the inner and outer destination 847 address will be the same). IR[CE](A) then simply releases the 848 encapsulated packets into its ISP network connection that provided 849 its locator. The ISP will release the packet into the Internet 850 without filtering since the (outer) source address is topologically 851 correct. Once the packets have been released into the Internet, 852 routing will direct them to the nearest IR[VC] that advertises 853 reachability to a VP that covers destination address B (namely, 854 IR[VC](B)). 856 IR[VC](B) will receive the encapsulated packets from IR[CE](A) then 857 check its FIB to discover an entry that covers destination address B 858 with IR[VE](B) as the next hop. IR[VC](B) will then issue SCMP 859 redirect messages to inform IR[CE](A) that IR[VE](B) is a better next 860 hop (*). IR[VC](B) then rewrites the outer source address of the 861 encapsulated packets to its own locator address and rewrites the 862 destination address of the encapsulated packets to the locator 863 address of IR[VE](B). IR[VC](B) then releases these (re)encapsulated 864 packets into the native Internet, where routing will direct them to 865 IR[VE](B). 867 IR[VE](B) will receive the encapsulated packets from IR[VC](B) then 868 check its FIB to discover an entry that covers destination address B 869 with IR[CE](B) as the next hop. IR[VE](B) then rewrites the outer 870 source address of the packets to its own locator address and rewrites 871 the outer destination address to the locator address of IR[CE](B). 872 (If IR[CE](B) is located behind a NAT, IR[VE](B) also rewrites the 873 UDP destination port number in the encapsulating header in order to 874 support NAT traversal.) IR[VE](B) then tunnels these 875 (re)encapsulated packets to IR[CE](B), which will in turn decapsulate 876 the packets and forward the inner packets to host B via EUN B. 878 (*) Note that after the initial flow of packets, IR[CE](A) will have 879 received one or more SCMP redirect messages from IR[VC](B) informing 880 it of IR[VE](B) as a better next hop. Thereafter, IR[CE](A) will 881 forward its encapsulated packets directly to the locator address of 882 IR[VE](B) without involving IR[VC](B) as shown in Figure 7: 884 ________________________________________ 885 .-( .-. )-. 886 .-( ,-( _)-. )-. 887 .-( +=============> .-(_ (_ )-.======+ )-. 888 .( // (__ Internet _) || ). 889 .( // `-(______)-' vv ). 890 .( // +------------+ ). 891 ( // | IR[VE](B) |====+ ) 892 ( // +------------+ \\ ) 893 ( // .-. .-. \\ ) 894 ( //,-( _)-. ,-( _)-\\ ) 895 ( .||_ (_ )-. .-(_ (_ ||. ) 896 ( _|| ISP A .) (__ ISP B ||_)) 897 ( ||-(______)-' `-(______)|| ) 898 ( || | | vv ) 899 ( +-----+-----+ The IRON +-----+-----+ ) 900 | IR[CE](A) | (Overlaid on the native Internet) | IR[CE](B) | 901 +-----+-----+ +-----+-----+ 902 | ( ) | 903 .-. .-( .-) .-. 904 ,-( _)-. .-(________________________)-. ,-( _)-. 905 .-(_ (_ )-. .-(_ (_ )-. 906 (_ IRON EUN A ) (_ IRON EUN B ) 907 `-(______)-' `-(______)-' 908 | | 909 +---+----+ +---+----+ 910 | Host A | | Host B | 911 +--------+ +--------+ 913 Figure 7: EPA/Locator Matching Scenario After Redirects 915 6.4.1.2. IR[CE] of Source Host Configures a Locator of a Different 916 Protocol Version than the EPA 918 Figure 8 shows the flow of initial packets from host A to host B 919 within two EP-addressed EUNs when the IR[CE] of source host A cannot 920 configure a locator of the same protocol version as the inner network 921 layer protocol. For example, if the IR[CE] configures only an IPv4 922 locator, but EUN A uses IPv6 natively, IR[CE] is obliged to forward 923 its packets through its serving IR[VE]. 925 ________________________________________ 926 .-( .-. )-. 927 .-( ,-( _)-. )-. 928 .-( +========+(_ (_ +=====+ )-. 929 .( || (_|| Internet ||_) || ). 930 .( || ||-(______)-|| vv ). 931 .( +--------++--+ || || +------------+ ). 932 ( +==>| IR[VE](A) | vv || | IR[VE](B) |====+ ) 933 ( // +------------+ +--++----++--+ +------------+ \\ ) 934 ( // .-. | IR[VC](B) | .-. \\ ) 935 ( //,-( _)-. +------------+ ,-( _)-\\ ) 936 ( .||_ (_ )-. / .-(_ (_ ||. ) 937 ( _|| ISP A .) / (redirect) (__ ISP B ||_)) 938 ( ||-(______)-' / `-(______)|| ) 939 ( || | / | vv ) 940 ( +-----+-----+ <=/ +-----+-----+ ) 941 | IR[CE](A) | | IR[CE](B) | 942 +-----+-----+ The IRON +-----+-----+ 943 | ( (Overlaid on the native Internet) ) | 944 .-. .-( .-) .-. 945 ,-( _)-. .-(________________________)-. ,-( _)-. 946 .-(_ (_ )-. .-(_ (_ )-. 947 (_ IRON EUN A ) (_ IRON EUN B ) 948 `-(______)-' `-(______)-' 949 | | 950 +---+----+ +---+----+ 951 | Host A | | Host B | 952 +--------+ +--------+ 954 Figure 8: EPA/Locator Mis-matching Scenario Before Redirects 956 In this scenario, host A sends its packets with destination address B 957 on its network interface connected to EUN A. (This interface could be 958 a physical interface such as an Ethernet NIC, an ISATAP tunnel 959 virtual interface with IR[CE](A) as a PRL router, etc.) Routing with 960 EUN A will direct the packets to IR[CE](A) as a default router for 961 the EUN which then uses VET and SEAL to encapsulate them in outer 962 headers with its locator address as the outer source address and the 963 locator address of its serving IR[VE](A) as the outer destination 964 address. IR[CE](A) then simply releases the encapsulated packets 965 into its ISP network connection that provided its locator. The ISP 966 will release the packets into the Internet without filtering since 967 the (outer) source address is topologically correct. Once the 968 packets have been released into the Internet, routing will direct 969 them to IR[VE](A). 971 IR[VE](A) receives the encapsulated packets from IR[CE](A) then 972 rewrites the outer source address to its own locator address and 973 rewrites the outer destination address to B (i.e., the inner and 974 outer destination address will be the same). IR[VE](A) then releases 975 the (re)encapsulated packets into the Internet where routing will 976 direct them to IR[VC](B) which advertises the VP that covers B. 978 IR[VC](B) will receive the encapsulated packets from IR[VE](A) then 979 check its FIB to discover an entry that covers destination address B 980 with IR[VE](B) as the next hop. IR[VC](B) will then issue SCMP 981 redirect messages to inform IR[VE](A) that IR[VE](B) is a better next 982 hop (*). IR[VC](B) then rewrites the outer source address of the 983 encapsulated packets to its own locator address and rewrites the 984 outer destination address to the locator address of IR[VE](B). 985 IR[VC](B) then releases these (re)encapsulated packets into the 986 Internet, where routing will direct them to IR[VE](B). 988 IR[VE](B) will receive the encapsulated packets from IR[VC](B) then 989 check its FIB to discover an entry that covers destination address B 990 with IR[CE](B) as the next hop. IR[VE](B) then rewrites the outer 991 source address of the packets to its own locator address and rewrites 992 the outer destination address to the locator address of IR[CE](B). 993 (If IR[CE](B) is located behind a NAT, then IR[VE](B) also rewrites 994 the UDP destination port number in the encapsulating header in order 995 to support NAT traversal.) IR[VE](B) then releases these 996 (re)encapsulated packets into the Internet, where routing will direct 997 them to IR[CE](B). IR[CE](B) will in turn decapsulate the packets 998 and forward the inner packets to host B via EUN B. 1000 (*) Note that after the initial flow of packets, IR[VE](A) will have 1001 received one or more SCMP redirect messages from IR[VC](B) informing 1002 it of IR[VE](B) as a better next hop. Thereafter, IR[VE](A) will 1003 forward its encapsulated packets directly to the locator address of 1004 IR[VE](B) without involving IR[VC](B) as shown in Figure 9: 1006 ________________________________________ 1007 .-( .-. )-. 1008 .-( ,-( _)-. )-. 1009 .-( +====> .-(_ (_ )-.======+ )-. 1010 .( || (__ Internet _) || ). 1011 .( || `-(______)-' vv ). 1012 .( +--------++--+ +------------+ ). 1013 ( +==>| IR[VE](A) | | IR[VE](B) |====+ ) 1014 ( // +------------+ +------------+ \\ ) 1015 ( // .-. .-. \\ ) 1016 ( //,-( _)-. ,-( _)-\\ ) 1017 ( .||_ (_ )-. .-(_ (_ ||. ) 1018 ( _|| ISP A .) (__ ISP B ||_)) 1019 ( ||-(______)-' `-(______)|| ) 1020 ( || | | vv ) 1021 ( +-----+-----+ The IRON +-----+-----+ ) 1022 | IR[CE](A) | (Overlaid on the native Internet) | IR[CE](B) | 1023 +-----+-----+ +-----+-----+ 1024 | ( ) | 1025 .-. .-( .-) .-. 1026 ,-( _)-. .-(________________________)-. ,-( _)-. 1027 .-(_ (_ )-. .-(_ (_ )-. 1028 (_ IRON EUN A ) (_ IRON EUN B ) 1029 `-(______)-' `-(______)-' 1030 | | 1031 +---+----+ +---+----+ 1032 | Host A | | Host B | 1033 +--------+ +--------+ 1035 Figure 9: EPA/Locator Mis-matching Scenario After Redirects 1037 6.4.2. Mixed IRON and Non-IRON Hosts 1039 When one host is within an IRON EUN and the other is in a non-IRON 1040 EUN (i.e., one that connects to the native Internet instead of the 1041 IRON), the IR elements involved depend on the packet flow directions. 1042 The cases are described in the following sections: 1044 6.4.2.1. From IRON Host A to Non-IRON Host B 1046 Figure 10 depicts the IRON reference operating scenario for packets 1047 flowing from Host A in an IRON EUN to Host B in a non-IRON EUN: 1049 _________________________________________ 1050 .-( )-. )-. 1051 .-( +-------)----+ )-. 1052 .-( | IR[VC](A) |--------------+ )-. 1053 .( +------------+ \ ). 1054 .( +=======>| IR[VE](A) | \ ). 1055 .( // +--------)---+ \ ). 1056 ( // ) \ ) 1057 ( // The IRON ) \ ) 1058 ( // .-. ) \ .-. ) 1059 ( //,-( _)-. ) \ ,-( _)-. ) 1060 ( .||_ (_ )-. ) The Native Internet .-|_ (_ )-. ) 1061 ( _|| ISP A ) ) (_ | ISP B )) 1062 ( ||-(______)-' ) |-(______)-' ) 1063 ( || | )-. v | ) 1064 ( +-----+ ----+ )-. +-----+-----+ ) 1065 | IR[CE](A) |)-. | Router B | 1066 +-----+-----+ +-----+-----+ 1067 | ( ) | 1068 .-. .-(____________________________________)-. .-. 1069 ,-( _)-. ,-( _)-. 1070 .-(_ (_ )-. .-(_ (_ )-. 1071 (_ IRON EUN A ) (_ non-IRON EUN ) 1072 `-(______)-' `-(___B___)-' 1073 | | 1074 +---+----+ +---+----+ 1075 | Host A | | Host B | 1076 +--------+ +--------+ 1078 Figure 10: From IRON Host A to Non-IRON Host B 1080 In this scenario, host A sends its packets with destination address B 1081 on its network interface connected to IRON EUN A. (This interface 1082 could be a physical interface such as an Ethernet NIC, an ISATAP 1083 tunnel virtual interface with IR[CE](A) as a PRL router, etc.) 1084 Routing with EUN A will direct the packets to IR[CE](A) as a default 1085 router for the EUN which then uses VET and SEAL to encapsulate them 1086 in outer headers with its locator address as the outer source address 1087 and the locator address of a serving IR[VE] (i.e., IR[VE](A) as the 1088 outer destination address. The ISP will pass the packets without 1089 filtering since the (outer) source address is topologically correct. 1090 Once the packets have been released into the native Internet, routing 1091 will direct them to IR[VE](A). 1093 IR[VE](A) receives the encapsulated packets from IR[CE](A) then 1094 forwards them to IR[VC](A) which simply decapsulates them and 1095 releases the unencapsulated packets into the Internet. Once the 1096 packets are released into the Internet, routing will direct them to 1097 the final destination B. (Note that in this diagram IR[VE](A) and 1098 IR[VC](A) are depicted as two halves of a unified IR[VP](A). In that 1099 case, the "forwarding" between IR[VE](A) and IR[VC](A) is a zero- 1100 instruction imaginary operation.) 1102 Note that this scenario always involves an IR[VC](A) owned by the VPC 1103 that provides service to IRON EUN A. This scenario therefore imparts 1104 a cost that would need to be borne by either the VPC or its 1105 customers. 1107 6.4.2.2. From Non-IRON Host B to IRON Host A 1109 Figure 10 depicts the IRON reference operating scenario for packets 1110 flowing from Host B in an Non-IRON EUN to Host A in an IRON EUN: 1112 _______________________________________ 1113 .-( )-. )-. 1114 .-( +-------)----+ )-. 1115 .-( | IR[VC](A) |<-------------+ )-. 1116 .( +------------+ \ ). 1117 .( +========| IR[VE](A) | \ ). 1118 .( // +--------)---+ \ ). 1119 ( // ) \ ) 1120 ( // The IRON ) \ ) 1121 ( // .-. ) \ .-. ) 1122 ( //,-( _)-. ) \ ,-( _)-. ) 1123 ( .||_ (_ )-. ) The Native Internet .-|_ (_ )-. ) 1124 ( _|| ISP A ) ) (_ | ISP B )) 1125 ( ||-(______)-' ) |-(______)-' ) 1126 ( vv | )-. | | ) 1127 ( +-----+ ----+ )-. +-----+-----+ ) 1128 | IR[CE](A) |)-. | Router B | 1129 +-----+-----+ +-----+-----+ 1130 | ( ) | 1131 .-. .-(____________________________________)-. .-. 1132 ,-( _)-. ,-( _)-. 1133 .-(_ (_ )-. .-(_ (_ )-. 1134 (_ IRON EUN A ) (_ non-IRON EUN ) 1135 `-(______)-' `-(___B___)-' 1136 | | 1137 +---+----+ +---+----+ 1138 | Host A | | Host B | 1139 +--------+ +--------+ 1141 Figure 11: From Non-IRON Host B to IRON Host A 1143 In this scenario, host B sends its unencapsulated packets with 1144 destination address A on its network interface connected to non-IRON 1145 EUN B. Routing will direct the packets to IR[VC](A) which then 1146 forwards them to IR[VE](A) using encapsulation if necessary. (Note 1147 that in this diagram IR[VE](A) and IR[VC](A) are depicted as two 1148 halves of a unified IR[VP](A). In that case, the "forwarding" 1149 between IR[VE](A) and IR[VC](A) is a zero-instruction imaginary 1150 operation.) 1152 IR[VE](A) will then check its FIB to discover an entry that covers 1153 destination address A with IR[CE](A) as the next hop. IR[VE](A) then 1154 encapsulates the packets using its own locator address as the outer 1155 source address and the locator address of IR[CE](A) as the outer 1156 destination address. IR[VE](A) then releases these (re)encapsulated 1157 packets into the Internet, where routing will direct them to 1158 IR[CE](A). IR[CE](A) will in turn decapsulate the packets and 1159 forward the inner packets to host A via its network interface 1160 connected to IRON EUN A. (This interface could be a physical 1161 interface such as an Ethernet NIC, an ISATAP tunnel virtual interface 1162 with Host A as the next-hop neighbor, etc.). 1164 Note that this scenario always involves an IR[VC](A) owned by the VPC 1165 that provides service to IRON EUN A. This scenario therefore imparts 1166 a cost that would need to be borne by either the VPC or its 1167 customers. 1169 6.5. Mobility, Multihoming and Traffic Engineering Considerations 1171 While IR[VE]s and IR[VC]s can be considered as fixed infrastructure, 1172 IR[CE]s may need to move between different network points of 1173 attachment, connect to multiple ISPs, or explicitly manage their 1174 traffic flows. The following sections discuss mobility, multi-homing 1175 and traffic engineering considerations for IR[CE]s. 1177 6.5.1. Mobility Management 1179 When an IR[CE] changes its network point of attachment (e.g., due to 1180 a mobility event), it configures one or more new locators. If the 1181 IR[CE] has not moved far away from its previous network point of 1182 attachment, it simply informs its serving IR[VE] of any locator 1183 additions or deletions. This operation is performance-sensitive, and 1184 should be conducted immediately to avoid packet loss. 1186 If the IR[CE] has moved far away from its previous network point of 1187 attachment, however, it re-issues the implicit anycast discovery 1188 procedure described in Section 6.1 to discover whether its candidate 1189 set of serving IR[VE]s has changed. If the IR[CE]'s current serving 1190 IR[VE] is also included in the new list received from the VPC, this 1191 serves as indication that the IR[CE] has not moved far enough to 1192 warrant changing to a new serving IR[VE]. Otherwise, the IR[CE] may 1193 wish to move to a new serving IR[VE] in order to maintain optimal 1194 routing. This operation is not performance-critical, and therefore 1195 can be conducted over a matter of seconds/minutes instead of 1196 milliseconds/microseconds. 1198 To move to a new IR[VE], the IR[CE] first engages in the EP 1199 registration process with the new IR[VE] and maintains the 1200 registrations through periodic SRS/SRA exchanges the same as 1201 described in Section 6.1. The IR[CE] then informs its former IR[VE] 1202 that it has moved by providing it with the locator address of the new 1203 IR[VE]. The IR[CE] then discontinues the SRS/SRA keepalive process 1204 with the former IR[VE], which will garbage-collect the stale FIB 1205 entries when their lifetime expires. This will allow the former 1206 IR[VE] to redirect existing correspondents to the new IR[VE] so that 1207 no packets are lost. 1209 6.5.2. Multihoming 1211 An IR[CE] may register multiple locators with its serving IR[VE]. It 1212 can assign metrics with its registrations to inform its IR[VE] of 1213 preferred locators, and can select outgoing locators according to its 1214 local preferences. Multihoming is therefore naturally supported. 1216 6.5.3. Inbound Traffic Engineering 1218 An IR[CE] can dynamically adjust the priorities of its prefix 1219 registrations with its serving IR[VE] in order to influence inbound 1220 traffic flows. It can also change between serving IR[VE]s when 1221 multiple IR[VE]s are available, but should strive for stability in 1222 its IR[VE] selection in order to limit routing churn. 1224 6.5.4. Outbound Traffic Engineering 1226 An IR[CE] can select outgoing locators, e.g., based on current QoS 1227 considerations. 1229 6.6. Renumbering Considerations 1231 As better link layer technologies and service plans emerge, customers 1232 will be motivated to select their service providers through healthy 1233 competition between ISPs. If a customer's EUN addresses are tied to 1234 a specific ISP, however, the customer may be forced to undergo a 1235 painstaking EUN renumbering process if it wishes to changes to a 1236 different ISP [RFC4192][RFC5887]. 1238 When a customer obtains EP prefixes from a VPC, it can change between 1239 ISPs seamlessly and without need to renumber. If the VPC itself 1240 applies unreasonable costing structures for use of the EPs, however, 1241 the customer may be compelled to seek a different VPC and would again 1242 be required to confront a renumbering scenario. The IRON approach to 1243 renumbering avoidance therefore depends on VPCs conducting ethical 1244 business practices with reasonable rates. 1246 6.7. NAT Traversal Considerations 1248 The Internet today consists of a global public IPv4 routing and 1249 addressing system with non-IRON EUNs that use either public or 1250 private IPv4 addressing. The latter class of EUNs connect to the 1251 public IPv4 Internet via Network Address Translators (NATs). When an 1252 IR[CE] is located behind a NAT, its selects IR[VE]s using the same 1253 procedures as for IR[CE]s with public addresses, i.e., it will send 1254 SRS messages to IR[VE]s in order to get SRA messages in return. The 1255 only requirement is that the IR[CE] must configure its SEAL 1256 encapsulation to use a transport protocol that supports NAT 1257 traversal, namely UDP. 1259 Since the IR[VE] maintains state about its IR[CE] customers, it can 1260 discover locator information for each IR[CE] by examining the UDP 1261 port number and IPv4 address in the outer headers of SRS messages. 1262 When there is a NAT in the path, the UDP port number and IPv4 address 1263 in the SRS message will correspond to state in the NAT box and might 1264 not correspond to the actual values assigned to the IR[CE]. The 1265 IR[VE] can then encapsulate packets destined to hosts serviced by the 1266 IR[CE] within outer headers that use this IPv4 address and UDP port 1267 number. The NAT box will receive the packets, translate the values 1268 in the outer headers to match those assigned to the IR[CE], then 1269 forward the packets to the IR[CE]. 1271 6.8. Nested EUN Considerations 1273 Each IR[CE] configures a locator that may be taken from an ordinary 1274 non-EPA address assigned by an ISP or from an EPA address taken from 1275 an EP assigned to another IR[CE]. In that case, the IR[CE] is said 1276 to be "nested" within the EUN of another IR[CE]. 1278 For example, assume a configuration in which IR[CE](A) configures a 1279 locator EPA(B) taken from the EP assigned to EUN(B). IR[CE](B) in 1280 turn configures a locator EPA(C) taken from the EP assigned to 1281 EUN(C). Finally, IR[CE](C) assigns a locator ISP(D) taken from a 1282 non-EPA address delegated by an ordinary ISP(D). Using this example, 1283 the "nested-IRON" case must be examined in which a host A which 1284 configures the address EPA(A) within EUN(A) exchanges packets with 1285 host Z located elsewhere in the Internet. The example configuration 1286 is depicted in Figure 12: 1288 .-. 1289 EPA(D) ,-( _)-. 1290 +-----------+ .-(_ (_ )-. 1291 | IR[CE](C) |--(_ ISP(D) ) 1292 +-----+-----+ `-(______)-' 1293 | <= T \ .-. 1294 .-. u \ ,-( _)-. 1295 ,-( _)-. n .-(_ (- )-. 1296 .-(_ (_ )-. n (_ Internet ) 1297 (_ EUN(C) ) e `-(______)- +--------+ 1298 `-(______)-' l ___ | Host Z | 1299 | EPA(C) s => (:::)-. +--------+ 1300 +-----+-----+ .-(::::::::) 1301 | IR[CE](B) | .-(::::::::::::)-. 1302 +-----+-----+ (:::: The IRON ::::) 1303 | `-(::::::::::::)-' 1304 .-. `-(::::::)-' 1305 ,-( _)-. 1306 .-(_ (_ )-. +-----------------+ 1307 (_ EUN(B) ) | IR[VP/VC/VE]'s] | 1308 `-(______)-' +-----------------+ 1309 | EPA(B) 1310 +-----+-----+ 1311 | IR[CE](A) | 1312 +-----------+ 1313 | 1314 .-. 1315 ,-( _)-. EPA(A) 1316 .-(_ (_ )-. +--------+ 1317 (_ EUN(A) )---| Host A | 1318 `-(______)-' +--------+ 1320 Figure 12: Nested EUN Example 1322 The two cases of host A sending packets to host Z, and host Z sending 1323 packets to host A, must be considered separately as described below: 1325 6.8.1. Host A Sends Packets to Host Z 1327 There are two distinct cases of Host A sending packets to Host Z 1328 which are dependent upon whether Z is an EPA or non-EPA address. The 1329 two cases are discussed below: 1331 6.8.1.1. Nested IRON Example When Z Configures an EPA Address 1333 Host A first forwards a packet with source address EPA(A) and 1334 destination address EPA(Z) into EUN(A). Routing within EUN(A) will 1335 direct the packet to IR[CE](A), which encapsulates it in an outer 1336 header with EPA(B) as the outer source address and EPA(Z) as the 1337 outer destination address then forwards the encapsulated packet into 1338 EUN(B). Routing within EUN[B] will direct the packet to IR[CE](B), 1339 which encapsulates it in an outer header with EPA(C) as the outer 1340 source address and EPA(Z) as the outer destination address then 1341 forwards the encapsulated packet into EUN(C). Routing within EUN(C) 1342 will direct the packet to IR[CE](C), which encapsulates it in an 1343 outer header with ISP(D) as the outer source address and EPA(Z) as 1344 the outer destination address. IR[CE](C) then sends this "triple- 1345 encapsulated" packet into the ISP(D) network, where it will be routed 1346 into the Internet to an IR[VC](Z) that advertises a VP that covers 1347 destination address EPA(Z). 1349 When IR[VC](Z) receives the "triple-encapsulated" packet, it consults 1350 its FIB to determine that IR[VE](Z) is the serving router for EP(Z). 1351 It then (re)encapsulates the packet by changing the outer source 1352 address to its own locator address and the outer destination address 1353 to the locator address for IR[VE](Z). It also sends a redirect 1354 message back to IR[CE](C) as normal. When IR[VE](Z) receives the 1355 "triple-encapsulated" packet, it strips off all outer layers of 1356 encapsulation and (re)encapsulates the inner packet using its own 1357 locator address as the source address and the locator address of 1358 IR[CE](Z) as the destination address. IR[VE](Z) then tunnels the 1359 packet to IR[CE](Z), which decapsulates the packet and forwards it to 1360 host Z. 1362 The key architectural requirement derived from this case is that each 1363 IR[VE] must iteratively decapsulate each layer of a multi- 1364 encapsulated packet when the outer destination address matches an EPA 1365 assigned to one of its IR[CE] customers. When the final such layer 1366 of encapsulation is reached, the IR[VE] must (re)encapsulate the 1367 packet and forward it to the correct customer IR[CE]. This class of 1368 packets can be considered as "inbound" wrt the IR[VE]'s client 1369 customer EUNs. 1371 6.8.1.2. Nested IRON Example when Z Configures a non-EPA Address 1373 Host A first forwards a packet with source address EPA(A) and 1374 destination address Z into EUN(A). Routing within EUN(A) will direct 1375 the packet to IR[CE](A), which encapsulates it in an outer header 1376 with EPA(B) as the outer source address and IR[VE](A) as the outer 1377 destination address then forwards the encapsulated packet into 1378 EUN(B). (Note that IR[CE](A) must forward this packet via its 1379 serving IR[VE](A) for reasons explained in Section 6.4.2). Routing 1380 within EUN[B] will direct the packet to IR[CE](B), which encapsulates 1381 it in an outer header with EPA(C) as the outer source address and 1382 IR[VE](B) as the outer destination address then forwards the 1383 encapsulated packet into EUN(C). Routing within EUN(C) will direct 1384 the packet to IR[CE](C), which encapsulates it in an outer header 1385 with ISP(D) as the outer source address and IR[VE](C) as the outer 1386 destination address. IR[CE](C) then sends this "triple-encapsulated" 1387 packet into its ISP network, where it will be routed to IR[VE](C). 1389 To ease in discussion of this case, now consider that each IR[VE] 1390 named above is half of a unified IR[VP] that combines both the IR[VC] 1391 and IR[VE] functions. With this simplification in mind, when 1392 IR[VP](C) receives the "triple-encapsulated" packet, it removes the 1393 outermost layer of encapsulation and forwards the packet into the 1394 Internet where Internet routing will direct it to IR[VP](B). 1395 IR[VP](B) in turn removes the next layer of encapsulation and 1396 forwards the packet into the Internet where Internet routing will 1397 direct it to IR[VP](A). IR[VP](A) will finally remove the final 1398 layer of encapsulation and forward the packet into the Internet where 1399 Internet routing will direct it to host Z. 1401 The key architectural requirement derived from this case is that each 1402 IR[VP] must iteratively decapsulate each layer of a multi- 1403 encapsulated packet when the outer destination address is one of its 1404 own locator addresses. When the final such layer of encapsulation is 1405 reached, the IR[VP] forwards the packet into the Internet. This 1406 class of packets can be considered as "outbound" wrt the IR[VP]'s 1407 client customer EUNs. 1409 6.8.2. Host Z Sends Packets to Host A 1411 Whether or not host Z configures an EPA address, its packets destined 1412 to Host A will eventually reach IR[VE](A). IR[VE](A) will have a 1413 mapping that lists IR[CE](A) as the next hop toward EPA(A). 1414 IR[VE](A) will then encapsulate the packet with EPA(B) as the outer 1415 destination address and forward the packet into the Internet. 1416 Internet routing will convey this once-encapsulated packet to 1417 IR[VE](B) which will have a mapping that lists IR[CE](B) as the next 1418 hop toward EPA(B). IR[VE](B) will then encapsulate the packet with 1419 EPA(C) as the outer destination address and forward the packet into 1420 the Internet. Internet routing will then convey this twice- 1421 encapsulated packet to IR[VE](C) which will have a mapping that lists 1422 IR[CE](C) as the next hop toward EPA(C). IR[VE](C) will then 1423 encapsulate the packet with ISP(D) as the outer destination address 1424 and forward the packet into the Internet. Internet routing will then 1425 convey this triple-encapsulated packet to IR[CE](C). 1427 When the triple-encapsulated packet arrives at IR[CE](C), it strips 1428 the outer layer of encapsulation and forwards the twice-encapsulated 1429 packet to EPA(C) which is the locator address of IR[CE](B). When 1430 IR[CE](B) receives the twice-encapsulated packet, it strips the outer 1431 layer of encapsulation and forwards the once-encapsulated packet to 1432 EPA(B) which is the locator address of IR[CE](A). When IR[CE](A) 1433 receives the once-encapsulated packet, it strips the outer layer of 1434 encapsulation and forwards the unencapsulated packet to EPA(A) which 1435 is the host address of host A. 1437 The key architectural requirement derived from this case is that each 1438 IR[CE] must decapsulate only the outermost layer of a multi- 1439 encapsulated packet when the outer destination address matches an EPA 1440 assigned to a device in its EUN. This class of packets can be 1441 considered as "inbound" wrt the IR[CE]'s EUNs. The outbound cases 1442 are discussed in Section 6.8.1 1444 7. Additional Considerations 1446 Considerations for the scalability of Internet Routing due to 1447 multihoming, traffic engineering and provider-independent addressing 1448 are discussed in [I-D.narten-radir-problem-statement]. Route 1449 optimization considerations for mobile networks are found in 1450 [RFC5522]. 1452 8. Related Initiatives 1454 IRON builds upon the concepts RANGER architecture [RFC5720], and 1455 therefore inherits the same set of related initiatives. 1457 Virtual Aggregation (VA) [I-D.ietf-grow-va] and Aggregation in 1458 Increasing Scopes (AIS) [I-D.zhang-evolution] provide the basis for 1459 the Virtual Prefix concepts. 1461 Internet vastly improved plumbing (Ivip) [I-D.whittle-ivip-arch] has 1462 contributed valuable insights, including the use of real-time 1463 mapping. The use of IR[VE]s as mobility anchor points is directly 1464 influenced by Ivip's associated TTR mobility extensions [TTRMOB]. 1466 Numerous publications have proposed NAT traversal techniques. The 1467 NAT traversal techniques adapted for IRON were inspired by the Simple 1468 Address Mapping for Premises Legacy Equipment (SAMPLE) proposal 1469 [I-D.carpenter-softwire-sample]. 1471 9. IANA Considerations 1473 There are no IANA considerations for this document. 1475 10. Security Considerations 1477 Security considerations that apply to tunneling in general are 1478 discussed in [I-D.ietf-v6ops-tunnel-security-concerns]. Additional 1479 considerations that apply also to IRON are discussed in RANGER 1480 [RFC5720], VET [I-D.templin-intarea-vet] and SEAL 1481 [I-D.templin-intarea-seal]. 1483 IR[CE]s require a means for securely registering their EP-to-locator 1484 bindings with their VPC. Each VPC provides its customer IR[CE]s with 1485 a secure means for registering and re-registering their mappings. 1487 11. Acknowledgements 1489 This ideas behind this work have benefited greatly from discussions 1490 with colleagues; some of which appear on the RRG and other IRTF/IETF 1491 mailing lists. Mohamed Boucadair, Wesley Eddy, Dae Young Kim and 1492 Robin Whittle provided review input. Eric Fleischman pointed out the 1493 opportunity to leverage anycast for discovering topologically-close 1494 serving IR[VE]s. 1496 12. References 1498 12.1. Normative References 1500 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1501 September 1981. 1503 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1504 (IPv6) Specification", RFC 2460, December 1998. 1506 12.2. Informative References 1508 [BGPMON] net, B., "BGPmon.net - Monitoring Your Prefixes, 1509 http://bgpmon.net/stat.php", June 2010. 1511 [I-D.carpenter-softwire-sample] 1512 Carpenter, B. and S. Jiang, "Legacy NAT Traversal for 1513 IPv6: Simple Address Mapping for Premises Legacy Equipment 1514 (SAMPLE)", draft-carpenter-softwire-sample-00 (work in 1515 progress), June 2010. 1517 [I-D.ietf-grow-va] 1518 Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and 1519 L. Zhang, "FIB Suppression with Virtual Aggregation", 1520 draft-ietf-grow-va-02 (work in progress), March 2010. 1522 [I-D.ietf-v6ops-tunnel-security-concerns] 1523 Hoagland, J., Krishnan, S., and D. Thaler, "Security 1524 Concerns With IP Tunneling", 1525 draft-ietf-v6ops-tunnel-security-concerns-02 (work in 1526 progress), March 2010. 1528 [I-D.narten-radir-problem-statement] 1529 Narten, T., "On the Scalability of Internet Routing", 1530 draft-narten-radir-problem-statement-05 (work in 1531 progress), February 2010. 1533 [I-D.russert-rangers] 1534 Russert, S., Fleischman, E., and F. Templin, "RANGER 1535 Scenarios", draft-russert-rangers-05 (work in progress), 1536 July 2010. 1538 [I-D.templin-intarea-seal] 1539 Templin, F., "The Subnetwork Encapsulation and Adaptation 1540 Layer (SEAL)", draft-templin-intarea-seal-16 (work in 1541 progress), July 2010. 1543 [I-D.templin-intarea-vet] 1544 Templin, F., "Virtual Enterprise Traversal (VET)", 1545 draft-templin-intarea-vet-16 (work in progress), 1546 July 2010. 1548 [I-D.whittle-ivip-arch] 1549 Whittle, R., "Ivip (Internet Vastly Improved Plumbing) 1550 Architecture", draft-whittle-ivip-arch-04 (work in 1551 progress), March 2010. 1553 [I-D.zhang-evolution] 1554 Zhang, B. and L. Zhang, "Evolution Towards Global Routing 1555 Scalability", draft-zhang-evolution-02 (work in progress), 1556 October 2009. 1558 [RFC1070] Hagens, R., Hall, N., and M. Rose, "Use of the Internet as 1559 a subnetwork for experimentation with the OSI network 1560 layer", RFC 1070, February 1989. 1562 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 1563 Reserved for Documentation", RFC 3849, July 2004. 1565 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 1566 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 1567 September 2005. 1569 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1570 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1572 [RFC4548] Gray, E., Rutemiller, J., and G. Swallow, "Internet Code 1573 Point (ICP) Assignments for NSAP Addresses", RFC 4548, 1574 May 2006. 1576 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1577 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1578 March 2008. 1580 [RFC5522] Eddy, W., Ivancic, W., and T. Davis, "Network Mobility 1581 Route Optimization Requirements for Operational Use in 1582 Aeronautics and Space Exploration Mobile Networks", 1583 RFC 5522, October 2009. 1585 [RFC5720] Templin, F., "Routing and Addressing in Networks with 1586 Global Enterprise Recursion (RANGER)", RFC 5720, 1587 February 2010. 1589 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 1590 Reserved for Documentation", RFC 5737, January 2010. 1592 [RFC5743] Falk, A., "Definition of an Internet Research Task Force 1593 (IRTF) Document Stream", RFC 5743, December 2009. 1595 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 1596 Still Needs Work", RFC 5887, May 2010. 1598 [TTRMOB] Whittle, R. and S. Russert, "TTR Mobility Extensions for 1599 Core-Edge Separation Solutions to the Internet's Routing 1600 Scaling Problem, 1601 http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf", 1602 August 2008. 1604 Appendix A. IRON VPs Over Non-Native Internetworks 1606 The IRON architecture leverages the native Internet routing system by 1607 providing generally shortest-path routing when EPAs are taken from 1608 VPs that are routable. When the VPs are not routable within the 1609 native underlying Internetwork, however (e.g., when OSI/NSAP 1610 [RFC4548] VPs are used within a private IPv4 Internetwork) packets 1611 with EPA addresses covered by the VPs must be carried solely via 1612 tunnels within the IRON. In such an environment, the IR[VC] role is 1613 deprecated since there is no native underlying Internetwork to 1614 support VP routing. This restricted model therefore entails only 1615 IR[CE]s and IR[VE]s. 1617 When IRON VPs are carried over a non-native Internetwork, a global 1618 mapping database is required to allow IR[VE]s to map VPs to locators 1619 which are assigned to the interfaces of other IR[VE]s. Each such 1620 non-routable VP in the IRON must therefore be represented in a 1621 globally distributed Master VP database (MVPd). The MVPd is 1622 maintained by a globally-managed assigned numbers authority in the 1623 same manner as the Internet Assigned Numbers Authority (IANA) 1624 currently maintains the master list of all top-level IPv4 and IPv6 1625 delegations. The database can be replicated across multiple servers 1626 for load balancing much in the same way that FTP mirror sites are 1627 used to manage software distributions. 1629 Each VP in the MVPd is encoded as the tuple: "{address family, 1630 prefix, prefix-length, FQDN}", where: 1632 o "address family" is one of IPv4, IPv6, OSI/CLNP, etc. 1634 o "prefix" is the VP, e.g. - 2001:DB8::/32 (IPv6) [RFC3849], 1635 192.2/16 (IPv4) [RFC5737], etc. 1637 o "prefix-length" is the length (in bits) of the associated VP 1639 o FQDN is a DNS Fully-Qualified Domain Name 1641 For each VP entry in the MVPd, the VPC maintains a FQDN in the DNS to 1642 map the VP to a list of IR[VE]s that serve it. Other IR[VE]s 1643 discover the mappings by resolving the FQDN into a list of resource 1644 records. Each resource record corresponds to an individual IR[VE], 1645 and encodes the tuple : "{address family, locator, WGS 84 1646 coordinates}" where "address family" is the address family of the 1647 locator, "locator" is the routing locator assigned to an IR[VE] 1648 interface, and "WGS 84 coordinates" identify the physical location of 1649 the IR[VE]. 1651 Upon startup, each IR[VE] managed by the VPC discovers the full set 1652 of VPs for the IRON by reading the MVPd. Each IR[VE] reads the MVPd 1653 from a nearby server upon startup time, and periodically checks the 1654 server for deltas since the database was last read. Upon reading the 1655 MVPd, each IR[VE] resolves the FQDN corresponding to each VP into a 1656 list of locators. Each locator is an address that is routable within 1657 the underlying Internetwork and assigned to an interface of an IR[VE] 1658 that serves the VP. 1660 For each VP, each IR[VE] sorts the list of locators to determine a 1661 priority ranking (e.g., based on distance from the locator) and 1662 inserts each "VP->locator" mapping into its FIB in order of priority. 1663 The FIB entries must be configured such that packets with destination 1664 addresses covered by the VP are forwarded to the corresponding 1665 locator using encapsulation of the inner network layer packet in an 1666 outer header of a network layer protocol that is routable within the 1667 Internetwork. This is accomplished by configuring the routing table 1668 entry to use the locator addresses as the L2 address corresponding to 1669 an imaginary L3 next-hop address. 1671 Note that the VP and locator may be of different address families; 1672 hence, possible encapsulations include IPv6-in-IPv4, IPv4-in-IPv6, 1673 IPv6-in-IPv6, IPv4-in-IPv4, OSI/CLNP-in-IPv6, OSI/CLNP-in-IPv4, etc. 1674 After each IR[VE] reads in the list of VPs and sorts the information 1675 accordingly, it is said to be "synchronized with the IRON". Each 1676 IR[VE] next installs all EPs derived from its VPs into its FIB based 1677 on the mapping information received from the IR[CE]s each of its EUN 1678 customers. 1680 Author's Address 1682 Fred L. Templin (editor) 1683 Boeing Research & Technology 1684 entire. Box 3707 MC 7L-49 1685 Seattle, WA 98124 1686 USA 1688 Email: fltemplin@acm.org