idnits 2.17.1 draft-templin-ironbis-14.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 : ---------------------------------------------------------------------------- == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 19, 2013) is 4025 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: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5743' is defined on line 1724, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin, Ed. 3 Internet-Draft Boeing Research & Technology 4 Obsoletes: RFC6179 (if approved) April 19, 2013 5 Intended status: Informational 6 Expires: October 21, 2013 8 Boeing's Interior Routing Overlay Network (IRON) 9 draft-templin-ironbis-14.txt 11 Abstract 13 Since large-scale Internetworks such as the public Internet must 14 continue to support escalating growth due to increasing demand, it is 15 clear that Autonomous Systems (ASes) must avoid injecting excessive 16 de-aggregated prefixes into the interdomain routing system and 17 instead mitigate de-aggregation internally. This document describes 18 an Interior Routing Overlay Network (IRON) architecture developed by 19 Boeing that supports sustainable growth within AS-interior routing 20 domains while requiring no changes to end systems and no changes to 21 the exterior routing system. In addition to routing scaling, IRON 22 further addresses other important issues including mobility 23 management, mobile networks, multihoming, traffic engineering, NAT 24 traversal and security. While business considerations are an 25 important determining factor for widespread adoption, they are out of 26 scope for this document. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on October 21, 2013. 45 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Differences With RFC6179 . . . . . . . . . . . . . . . . . . . 5 64 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4. The Interior Routing Overlay Network . . . . . . . . . . . . . 7 66 4.1. IRON Client . . . . . . . . . . . . . . . . . . . . . . . 9 67 4.2. IRON Serving Router . . . . . . . . . . . . . . . . . . . 10 68 4.3. IRON Relay Router . . . . . . . . . . . . . . . . . . . . 11 69 5. IRON Organizational Principles . . . . . . . . . . . . . . . . 12 70 6. IRON Control Plane Operation . . . . . . . . . . . . . . . . . 14 71 6.1. IRON Client Operation . . . . . . . . . . . . . . . . . . 14 72 6.2. IRON Server Operation . . . . . . . . . . . . . . . . . . 14 73 6.3. IRON Relay Operation . . . . . . . . . . . . . . . . . . . 15 74 7. IRON Forwarding Plane Operation . . . . . . . . . . . . . . . 15 75 7.1. IRON Client Operation . . . . . . . . . . . . . . . . . . 15 76 7.2. IRON Server Operation . . . . . . . . . . . . . . . . . . 16 77 7.3. IRON Relay Operation . . . . . . . . . . . . . . . . . . . 17 78 8. IRON Reference Operating Scenarios . . . . . . . . . . . . . . 18 79 8.1. Both Hosts within Same IRON Instance . . . . . . . . . . . 18 80 8.1.1. EUNs Served by Same Server . . . . . . . . . . . . . . 18 81 8.1.2. EUNs Served by Different Servers . . . . . . . . . . . 20 82 8.1.3. Client-to-Client Tunneling . . . . . . . . . . . . . . 22 83 8.2. Mixed IRON and Non-IRON Hosts . . . . . . . . . . . . . . 23 84 8.2.1. From IRON Host A to Non-IRON Host B . . . . . . . . . 23 85 8.2.2. From Non-IRON Host B to IRON Host A . . . . . . . . . 25 86 8.3. Hosts within Different IRON Instances . . . . . . . . . . 26 87 9. Mobility, Multiple Interfaces, Multihoming, and Traffic 88 Engineering . . . . . . . . . . . . . . . . . . . . . . . . . 26 89 9.1. Mobility Management and Mobile Networks . . . . . . . . . 27 90 9.2. Multiple Interfaces and Multihoming . . . . . . . . . . . 27 91 9.3. Traffic Engineering . . . . . . . . . . . . . . . . . . . 28 92 10. Renumbering Considerations . . . . . . . . . . . . . . . . . . 28 93 11. NAT Traversal Considerations . . . . . . . . . . . . . . . . . 28 94 12. Multicast Considerations . . . . . . . . . . . . . . . . . . . 29 95 13. Nested EUN Considerations . . . . . . . . . . . . . . . . . . 29 96 13.1. Host A Sends Packets to Host Z . . . . . . . . . . . . . . 31 97 13.2. Host Z Sends Packets to Host A . . . . . . . . . . . . . . 31 98 14. Implications for the Internet . . . . . . . . . . . . . . . . 32 99 15. Additional Considerations . . . . . . . . . . . . . . . . . . 33 100 16. Related Initiatives . . . . . . . . . . . . . . . . . . . . . 33 101 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 102 18. Security Considerations . . . . . . . . . . . . . . . . . . . 34 103 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 104 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 105 20.1. Normative References . . . . . . . . . . . . . . . . . . . 36 106 20.2. Informative References . . . . . . . . . . . . . . . . . . 36 107 Appendix A. IRON Operation over Internetworks with Different 108 Address Families . . . . . . . . . . . . . . . . . . 39 109 Appendix B. Scaling Considerations . . . . . . . . . . . . . . . 40 110 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 41 112 1. Introduction 114 Growth in the number of prefix entries instantiated in the Internet 115 routing system has led to concerns regarding unsustainable routing 116 scaling [RFC4984][RADIR] [I-D.narten-radir-problem-statement]. 117 Operational practices such as de-aggregation and the increased use of 118 multihoming with Provider-Independent (PI) addressing are resulting 119 in more and more prefixes being injected into the Internet routing 120 system. Furthermore, depletion of the public IPv4 address space has 121 raised concerns for both increased de-aggregation and an impending 122 address space run-out scenario. At the same time, the IPv6 routing 123 system is beginning to see growth [BGPMON] which must be managed in 124 order to avoid the same routing scaling issues the IPv4 Internet now 125 faces. Since the Internet must continue to scale to accommodate 126 increasing demand, it is clear that new methodologies and operational 127 practices for managing Autonomous System (AS) interior routing 128 systems are needed in order to avoid excessive routing scaling due to 129 de-aggregation. 131 These same issues apply also to Internetworks other than the public 132 Internet, including critical infrastructure networks such as 133 corporate enterprise networks, civil aviation networks, emergency 134 response networks, power grid networks, medical care networks, etc. 135 The architectural principles presented in this document therefore 136 apply equally to any such Internetwork. 138 Several related works have investigated routing scaling issues. 139 Virtual Aggregation (VA) [GROW-VA] and Aggregation in Increasing 140 Scopes (AIS) [EVOLUTION] are global routing proposals that introduce 141 routing overlays with Virtual Prefixes (VPs) to reduce the number of 142 entries required in each router's Forwarding Information Base (FIB) 143 and Routing Information Base (RIB). Routing and Addressing in 144 Networks with Global Enterprise Recursion (RANGER) [RFC5720] examines 145 recursive arrangements of enterprise networks that can apply to a 146 very broad set of use-case scenarios [RFC6139]. IRON specifically 147 adopts the RANGER Non-Broadcast, Multiple Access (NBMA) tunnel 148 virtual-interface model, and uses Virtual Enterprise Traversal (VET) 149 [INTAREA-VET] the Subnetwork Adaptation and Encapsulation Layer 150 (SEAL) [INTAREA-SEAL] and Asymmetric Extended Route Optimization 151 [RFC6706] as its functional building blocks. 153 This document introduces an Interior Routing Overlay Network (IRON) 154 architecture developed by Boeing with goals of supporting scalable 155 routing and addressing while requiring no changes to the 156 Internetwork's interdomain routing system [RFC4271]. IRON observes 157 the Internet Protocol standards [RFC0791][RFC2460], while other 158 network-layer protocols that can be encapsulated within IP packets 159 (e.g., OSI/CLNP [RFC0994], etc.) are also within scope. 161 IRON borrows concepts from VA and AIS, and further borrows concepts 162 from the Internet Vastly Improved Plumbing (Ivip) [IVIP-ARCH] 163 architecture proposal along with its associated Translating Tunnel 164 Router (TTR) mobility extensions [TTRMOB]. Indeed, the TTR model to 165 a great degree inspired the IRON mobility architecture design 166 discussed in this document. The Network Address Translator (NAT) 167 traversal techniques adapted for IRON were inspired by the Simple 168 Address Mapping for Premises Legacy Equipment (SAMPLE) proposal 169 [SAMPLE] [I-D.carpenter-softwire-sample] and by Teredo [RFC4380]. 171 IRON is specifically adapted for Virtual Service Provider (VSP) 172 overlay networks that connect to the Internetwork as an AS and 173 service Aggregated Prefixes (APs) from which more-specific Client 174 Prefixes (CPs) are delegated. IRON is motivated by a growing end 175 user demand for mobility management, mobile networks, multihoming, 176 traffic engineering, NAT traversal and security while using stable 177 addressing to minimize dependence on network renumbering 178 [RFC4192][RFC5887]. IRON VSP overlay network instances use the 179 existing IPv4 and/or IPv6 Internetwork as virtual NBMA links for 180 tunneling inner network layer packets within outer network layer 181 headers (see Section 4). Each IRON instance requires deployment of a 182 small number of relays and servers in the Internetwork, as well as 183 client devices that connect End User Networks (EUNs). No 184 modifications to hosts, and no modifications to existing routers, are 185 required. The following sections discuss details of the IRON 186 architecture. 188 2. Differences With RFC6179 190 An earlier version of IRON was published as RFC6179. This version 191 clarifies that IRON operates at the intradomain level within an AS, 192 and is therefore not intended as an interdomain solution. IRON is 193 therefore complimentary with the approaches documented in interdomain 194 solutions such as the Identifier / Locator Network Protocol (ILNP) 195 [RFC6740] and the Locator I/D Split Protocol (LISP) [RFC6830]. This 196 version of IRON further introduces significant improvements in 197 security and route optimization, as well as a direct client-to-client 198 route optimization capability not found in RFC6179. 200 Some terminology has been changed for greater clarification, 201 including Virtual Service Provier (VSP), Aggregated Prefix (AP) and 202 Client Prefix (CP). This document further introduces Asymmetric 203 Extended Route Optimization (AERO) [RFC6706] as the primary route 204 discovery mechanism. The document finally adds a new section on 205 renumbering considerations and adds enhanced security considerations. 207 3. Terminology 209 This document makes use of the following terms: 211 Aggregated Prefix (AP): 212 a short network-layer prefix (e.g., an IPv4 /16, an IPv6 /20, an 213 OSI Network Service Access Protocol (NSAP) prefix, etc.) that is 214 owned and managed by a Virtual Service Provider (VSP). 216 Client Prefix (CP): 217 a more-specific network-layer prefix (e.g., an IPv4 /28, an IPv6 218 /56, etc.) derived from an AP and delegated to a client end user 219 network. 221 Client Prefix Address (CPA): 222 a network-layer address belonging to a CP and assigned to an 223 interface in an End User Network (EUN). 225 End User Network (EUN): 226 an edge network that connects an end user's devices (e.g., 227 computers, routers, printers, etc.) to the Internetwork. IRON 228 EUNs are mobile networks, and can change their ISP attachments 229 without having to renumber. 231 Interior Routing Overlay Network (IRON): 232 an AS-interior overlay network instance that appears as a virtual 233 enterprise network, and connects to the Internetwork the same as 234 for any AS. 236 IRON Client Router/Host ("Client"): 237 a customer device that logically connects EUNs to an IRON instance 238 via an NBMA tunnel virtual interface. The device is normally a 239 router, but may instead be a host if the "EUN" is a singleton end 240 system. 242 IRON Serving Router ("Server"): 243 a VSP's IRON instance router that provides forwarding and mapping 244 services for Clients. 246 IRON Relay Router ("Relay"): 247 a VSP's router that acts as a relay between the IRON instance and 248 the Internetwork. 250 IRON Agent (IA): 251 generically refers to any of an IRON Client/Server/Relay. 253 IRON Instance: 254 a set of IRON Agents deployed by a VSP to service EUNs through 255 automatic tunneling over the Internetwork. 257 Internetwork Service Provider (ISP): 258 a service provider that connects an IA to the Internetwork. In 259 other words, an ISP is responsible for providing IAs with data 260 link services for basic connectivity. 262 Locator: 263 an IP address assigned to the interface of a router or end system 264 connected to a public or private network over which tunnels are 265 formed. Locators taken from public IP prefixes are routable on a 266 global basis, while locators taken from private IP prefixes 267 [RFC1918] are made public via Network Address Translation (NAT). 269 Routing and Addressing in Networks with Global Enterprise Recursion 270 (RANGER): 271 an architectural examination of virtual overlay networks applied 272 to enterprise network scenarios, with implications for a wider 273 variety of use cases. 275 Subnetwork Encapsulation and Adaptation Layer (SEAL): 276 an encapsulation sublayer that provides extended identification 277 fields and control messages to ensure deterministic network-layer 278 feedback. 280 Virtual Enterprise Traversal (VET): 281 a method for discovering border routers and forming dynamic tunnel 282 neighbor relationships over enterprise networks (or sites) with 283 varying properties. 285 Asymmetric Extended Route Optimization (AERO): 286 a means for a destination IA to securely inform a source IA of a 287 more direct path. 289 Virtual Service Provider (VSP): 290 a company that owns and manages a set of APs from which it 291 delegates CPs to EUNs. 293 VSP Overlay Network: 294 the same as defined above for IRON Instance. 296 4. The Interior Routing Overlay Network 298 The Interior Routing Overlay Network (IRON) operates at the AS level 299 and provides a number of important services to End User Networks 300 (EUNs) that are not well supported in the current architecture, 301 including routing scaling, mobility management, mobile networks, 302 multihoming, traffic engineering and NAT traversal. This is 303 accomplisehd through the establishment of IRON instances as overlays 304 configured over the underlying Internetwork. 306 Each IRON instance consists of IRON Agents (IAs) that automatically 307 tunnel the packets of end-to-end communication sessions within 308 encapsulating headers used for Internetwork routing. IAs use the 309 Virtual Enterprise Traversal (VET) [INTAREA-VET] virtual NBMA link 310 model in conjunction with the Subnetwork Encapsulation and Adaptation 311 Layer (SEAL) [INTAREA-SEAL] to encapsulate inner network-layer 312 packets within outer network layer headers, as shown in Figure 1. 314 +-------------------------+ 315 | Outer headers with | 316 ~ locator addresses ~ 317 | (IPv4 or IPv6) | 318 +-------------------------+ 319 | SEAL Header | 320 +-------------------------+ +-------------------------+ 321 | Inner Packet Header | --> | Inner Packet Header | 322 ~ with CPA addresses ~ --> ~ with CPA addresses ~ 323 | (IPv4, IPv6, OSI, etc.) | --> | (IPv4, IPv6, OSI, etc.) | 324 +-------------------------+ +-------------------------+ 325 | | --> | | 326 ~ Inner Packet Body ~ --> ~ Inner Packet Body ~ 327 | | --> | | 328 +-------------------------+ +-------------------------+ 330 Inner packet before Outer packet after 331 encapsulation encapsulation 333 Figure 1: Encapsulation of Inner Packets within Outer IP Headers 335 VET specifies automatic tunneling and tunnel neighbor coordination 336 mechanisms, where IAs appear as neighbors on an NBMA tunnel virtual 337 link. SEAL specifies the format and usage of the SEAL encapsulating 338 header. Additionally, Asymmetric Extended Route Optimization (AERO) 339 [RFC6706] specifies the method for route optimization to reduce 340 routing path stretch. Together, these documents specify a set of 341 control messages used to deterministically exchange and authenticate 342 neighbor discovery messages, route redirections, indications of Path 343 Maximum Transmission Unit (PMTU) limitations, destination 344 unreachables, etc. 346 Each IRON instance comprises a set of IAs distributed throughout the 347 Internetwork to provide routing services for a set of Aggregated 348 Prefixes (APs). (The APs may be owned either by the VSP, or by an 349 enterprise network customer that hires the VSP to manage its APs.) 350 VSPs delegate sub-prefixes from APs, which they provide to end users 351 as Client Prefixes (CPs). In turn, end users assign CPs to Client 352 IAs which connect their End User Networks (EUNs) to the VSP IRON 353 instance. 355 VSPs may have no affiliation with the ISP networks from which end 356 users obtain their basic Internetwork connectivity. In that case, 357 the VSP can service its end users without the need to coordinate its 358 activities with ISPs or other VSPs. Further details on VSP business 359 considerations are out of scope for this document. 361 IRON requires no changes to end systems or to existing routers. 362 Instead, IAs are deployed either as new platforms or as modifications 363 to existing platforms. IAs may be deployed incrementally without 364 disturbing the existing Internetwork routing system, and act as 365 waypoints (or "cairns") for navigating VSP overly networks. The 366 functional roles for IAs are described in the following sections. 368 4.1. IRON Client 370 An IRON Client (or, simply, "Client") is a router that logically 371 connects EUNs to the VSP's IRON instance via tunnels, as shown in 372 Figure 2. Clients obtain CPs from their VSPs and use them to number 373 subnets and interfaces within the EUNs. 375 Each Client connects to one or more Servers in the IRON instance 376 which serve as default routers. The Servers in turn consider this 377 class of Clients as "dependent" Clients. Clients also dynamically 378 discover destination-specific Servers through the receipt of 379 redirection messages. These destination-specific Servers in turn 380 consider this class of Clients as "visiting" Clients. 382 A Client can be deployed on the same physical platform that also 383 connects EUNs to the end user's ISPs, but it may also be deployed as 384 a separate router within the EUN. (This model applies even if the 385 EUN connects to the ISP via a Network Address Translator (NAT) -- see 386 Section 7.7). Finally, a Client may also be a simple end system that 387 connects a singleton EUN and exhibits the outward appearance of a 388 host. 390 .-. 391 ,-( _)-. 392 +--------+ .-(_ (_ )-. 393 | Client |--(_ ISP ) 394 +---+----+ `-(______)-' 395 | <= T \ .-. 396 .-. u \ ,-( _)-. 397 ,-( _)-. n .-(_ (- )-. 398 .-(_ (_ )-. n (_ Internetwork ) 399 (_ EUN ) e `-(______)-' 400 `-(______)-' l ___ 401 | s => (:::)-. 402 +----+---+ .-(::::::::) 403 | Host | .-(::: IRON :::)-. 404 +--------+ (:::: Instance ::::) 405 `-(::::::::::::)-' 406 `-(::::::)-' 408 Figure 2: IRON Client Connecting EUN to IRON Instance 410 4.2. IRON Serving Router 412 An IRON serving router (or, simply, "Server") is a VSP's router that 413 provides forwarding and mapping services within the IRON instance for 414 the CPs that have been delegated to end user Clients. In typical 415 deployments, a VSP will deploy many Servers for the IRON instance in 416 a globally distributed fashion (e.g., as depicted in Figure 3) around 417 the Internetwork so that Clients can discover those that are nearby. 419 +--------+ +--------+ 420 | Boston | | Tokyo | 421 | Server | | Server | 422 +--+-----+ ++-------+ 423 +--------+ \ / 424 | Seattle| \ ___ / 425 | Server | \ (:::)-. +--------+ 426 +------+-+ .-(::::::::)------+ Paris | 427 \.-(::: IRON :::)-. | Server | 428 (:::: Instance ::::) +--------+ 429 `-(::::::::::::)-' 430 +--------+ / `-(::::::)-' \ +--------+ 431 | Moscow + | \--- + Sydney | 432 | Server | +----+---+ | Server | 433 +--------+ | Cairo | +--------+ 434 | Server | 435 +--------+ 437 Figure 3: IRON Server Global Distribution Example 439 Each Server acts as a tunnel-endpoint router. The Server forms 440 bidirectional tunnel neighbor relationships with each of its 441 dependent Clients, and can also serve as the unidirectional tunnel 442 neighbor egress for dynamically discovered visiting Clients. (The 443 Server can also form bidirectional tunnel neighbor relationships with 444 visiting Clients, e.g., if a symmetric security association is 445 necessary.) Each Server also forms bidirectional tunnel neighbor 446 relationships with a set of Relays that can forward packets from the 447 IRON instance out to the native Internetwork and vice versa, as 448 discussed in the next section. 450 4.3. IRON Relay Router 452 An IRON Relay Router (or, simply, "Relay") is a router that connects 453 the VSP's IRON instance to the Internetwork as an AS. The Relay 454 therefore also serves as an Autonomous System Border Router (ASBR) 455 that is owned and managed by the VSP. 457 Each VSP configures one or more Relays that advertise the VSP's APs 458 into the IPv4 and/or IPv6 Internetwork routing systems. Each Relay 459 associates with the VSP's IRON instance Servers, e.g., via tunnel 460 virtual links over the IRON instance, via a physical interconnect 461 such as an Ethernet cable, etc. The Relay role is depicted in 462 Figure 4. 464 .-. 465 ,-( _)-. 466 .-(_ (_ )-. 467 (_ Internetwork ) 468 `-(______)-' | +--------+ 469 | |--| Server | 470 +----+---+ | +--------+ 471 | Relay |----| +--------+ 472 +--------+ |--| Server | 473 _|| | +--------+ 474 (:::)-. (Physical Interconnects) 475 .-(::::::::) 476 +--------+ .-(::: IRON :::)-. +--------+ 477 | Server |=(:::: Instance ::::)=| Server | 478 +--------+ `-(::::::::::::)-' +--------+ 479 `-(::::::)-' 480 || (Tunnels) 481 +--------+ 482 | Server | 483 +--------+ 485 Figure 4: IRON Relay Router Connecting IRON Instance to Native 486 Internet 488 5. IRON Organizational Principles 490 Each IRON instance represents a distinct "patch" on the underlying 491 Internetwork "quilt", where the patches are stitched together by 492 standard routing. When a new IRON instance is deployed, it becomes 493 yet another patch on the quilt and coordinates its internal routing 494 system independently of all other patches. 496 Each IRON instance connects to the Internetwork as an AS in the 497 interdomain routing system using a public Border Gateway Protocol 498 (BGP) Autonomous System Number (ASN). The IRON instance maintains a 499 set of Relays that serve as ASBRs as well as a set of Servers that 500 provide routing and addressing services to Clients. Figure 5 depicts 501 the logical arrangement of Relays, Servers, and Clients in an IRON 502 instance. 504 .-. 505 ,-( _)-. 506 .-(_ (_ )-. 507 (_ Internetwork ) 508 `-(______)-' 510 <------------ Relays ------------> 511 ________________________ 512 (::::::::::::::::::::::::)-. 513 .-(:::::::::::::::::::::::::::::) 514 .-(:::::::::::::::::::::::::::::::::)-. 515 (::::::::::: IRON Instance :::::::::::::) 516 `-(:::::::::::::::::::::::::::::::::)-' 517 `-(::::::::::::::::::::::::::::)-' 519 <------------ Servers ------------> 520 .-. .-. .-. 521 ,-( _)-. ,-( _)-. ,-( _)-. 522 .-(_ (_ )-. .-(_ (_ )-. .-(_ (_ )-. 523 (__ ISP A _) (__ ISP B _) ... (__ ISP x _) 524 `-(______)-' `-(______)-' `-(______)-' 525 <----------- NATs ------------> 527 <----------- Clients and EUNs -----------> 529 Figure 5: IRON Organization 531 Each Relay connects the IRON instance directly to the underlying IPv4 532 and/or IPv6 Internetworks via external BGP (eBGP) peerings with 533 neighboring ASes. It also advertises the IPv4 APs managed by the VSP 534 into the IPv4 Internetwork routing system and advertises the IPv6 APs 535 managed by the VSP into the IPv6 Internetwork routing system. Relays 536 will therefore receive packets with CPA destination addresses sent by 537 end systems in the Internetwork and forward them to a Server that 538 connects the Client to which the corresponding CP has been delegated. 539 Finally, the IRON instance Relays maintain synchronization by running 540 interior BGP (iBGP) between themselves the same as for ordinary 541 ASBRs. 543 In a simple VSP overlay network arrangement, each Server can be 544 configured as an ASBR for a stub AS using a private ASN [RFC1930] to 545 peer with each IRON instance Relay the same as for an ordinary eBGP 546 neighbor. (The Server and Relay functions can instead be deployed 547 together on the same physical platform as a unified gateway.) Each 548 Server maintains a working set of dependent Clients for which it 549 caches CP-to-Client mappings in its forwarding table. Each Server 550 also, in turn, propagates the list of CPs in its working set to its 551 neighboring Relays via eBGP. Therefore, each Server only needs to 552 track the CPs for its current working set of dependent Clients, while 553 each Relay will maintain a full CP-to-Server forwarding table that 554 represents reachability information for all CPs in the IRON instance. 556 Each Client obtains its basic Internetwork connectivity from ISPs, 557 and connects to Servers to attach its EUNs to the IRON instance. 558 Each EUN can further connect to the IRON instance via multiple 559 Clients as long as the Clients coordinate with one another, e.g., to 560 mitigate EUN partitions. Clients may additionaly use private 561 addresses behind one or several layers of NATs. Each Client 562 initially discovers a list of nearby Servers then forms a 563 bidirectional tunnel neighbor relationship with one or more Servers 564 through an initial exchange followed by periodic keepalives. 566 After a Client connects to Servers, it forwards initial outbound 567 packets from its EUNs by tunneling them to a Server, which may, in 568 turn, forward them to a nearby Relay within the IRON instance. The 569 Client may subsequently receive redirection messages informing it of 570 a more direct route through a different IA within the IRON instance 571 that serves the final destination EUN. 573 IRON can also be used to support APs of network-layer address 574 families that cannot be routed natively in the underlying 575 Internetwork (e.g., OSI/CLNP over the public Internet, IPv6 over 576 IPv4-only Internetworks, IPv4 over IPv6-only Internetworks, etc.). 577 Further details for the support of IRON APs of one address family 578 over Internetworks based on different address families are discussed 579 in Appendix A. 581 6. IRON Control Plane Operation 583 Each IRON instance supports routing through the control plane startup 584 and runtime dynamic routing operation of IAs. The following sub- 585 sections discuss control plane considerations for initializing and 586 maintaining the IRON instance routing system. 588 6.1. IRON Client Operation 590 Each Client obtains one or more CPs in a secured exchange with the 591 VSP as part of the initial end user registration. Upon startup, the 592 Client discovers a list of nearby VSP Servers via, e.g., a location 593 broker, a well known website, a static map, etc. 595 After the Client obtains a list of nearby Servers, it initiates short 596 transactions to connect to one or more Servers, e.g., via secured TCP 597 connections. During the transaction, each Server provides the Client 598 with a CP and a symmetric secret key that the Client will use to sign 599 and authenticate messages. The Client in turn provides the Server 600 with a set of link identifiers ("LINK_ID"s) that represent the 601 Client's ISP connections. Finally, the Client provides a 602 "willingness" indication as to whether or not it will accept direct 603 Client-to-Client communications without involving the Server as an 604 intermediary. The protocol details of the connection transaction are 605 specific to the VSP, and hence out of scope for this document. 607 After the Client connects to Servers, it configures default routes 608 that list the Servers as next hops on the tunnel virtual interface. 609 The Client may subsequently discover more-specific routes through 610 receipt of redirection messages. 612 6.2. IRON Server Operation 614 In a simple VSP overlay network arrangement, each IRON Server is 615 provisioned with the locators for Relays within the IRON instance. 616 The Server is further configured as an ASBR for a stub AS and uses 617 eBGP with a private ASN to peer with each Relay. 619 Upon startup, the Server uses eBGP to announce the list of CPs it is 620 currently serving to the overlay network Relays. The Server then 621 actively listens for Clients that register their CPs as part of the 622 connection establishment procedure described in Section 6.1. When a 623 new Client connects, the Server uses eBGP to announce the new CP 624 routes to its neighboring Relays; when an existing Client 625 disconnects, the Server withdraws its CP announcements. This process 626 can often be accommodated through standard eBGP router 627 configurations, e.g., on routers that can announce and withdraw 628 prefixes based on kernel route additions and deletions. 630 6.3. IRON Relay Operation 632 Each IRON Relay is provisioned with the list of APs that it will 633 serve, as well as the locators for Servers within the IRON instance. 634 The Relay is also provisioned with eBGP peerings with neighboring 635 ASes in the Internetwork -- the same as for any ASBR. 637 In a simple VSP overlay network arrangement, each Relay connects to 638 each Server via IRON instance-internal eBGP peerings for the purpose 639 of discovering CP-to-Server mappings, and connects to all other 640 Relays using iBGP either in a full mesh or using route reflectors. 641 (The Relay only uses iBGP to announce those prefixes it has learned 642 from AS peerings external to the IRON instance, however, since all 643 Relays will already discover all CPs in the IRON instance via their 644 eBGP peerings with Servers.) The Relay then engages in eBGP routing 645 exchanges with peer ASes in the IPv4 and/or IPv6 Internetworks the 646 same as for any ASBR. 648 After this initial synchronization procedure, the Relay advertises 649 the APs to its eBGP peers in the Internetwork. In particular, the 650 Relay advertises the IPv6 APs into the IPv6 interdomain routing 651 system and advertises the IPv4 APs into the IPv4 interdomain routing 652 system, but it does not advertise the full list of the IRON overlay's 653 CPs to any of its eBGP peers. The Relay further advertises "default" 654 via eBGP to its associated Servers, then engages in ordinary packet- 655 forwarding operations. 657 7. IRON Forwarding Plane Operation 659 Following control plane initialization, IAs engage in the cooperative 660 process of receiving and forwarding packets. IAs forward 661 encapsulated packets over the IRON instance using the mechanisms of 662 VET [INTAREA-VET], SEAL [INTAREA-SEAL] and AERO [RFC6706], while 663 Relays additionally forward packets to and from the native IPv6 664 and/or IPv4 Internetworks. IAs also use VET, SEAL and AERO control 665 messages to coordinate with other IAs, including the process of 666 sending and receiving redirection messages, error messages, etc. 667 Each IA operates as specified in the following sub-sections. 669 7.1. IRON Client Operation 671 After connecting to Servers as specified in Section 6.1, the Client 672 registers its active ISP connections with each of its connected 673 Servers. Thereafter, the Client sends periodic beacons (e.g., 674 cryptographically signed SEAL Control Message Protocol (SCMP) Router 675 Solicitation (SRS) messages) to the Server via each ISP connection to 676 maintain tunnel neighbor address mapping state. The beacons should 677 be sent at no more than 60 second intervals (subject to a small 678 random delay) so that state in NATs on the path as well as on the 679 Server itself is refreshed regularly. Although the Client may 680 connect via multiple ISPs (each represented by a different LINK_ID), 681 the CP itself is used to represent the bidirectional Client-to-Server 682 tunnel neighbor association. The CP therefore names this "bundle" of 683 ISP connections. 685 If the Client ceases to receive acknowledgements from a Server via a 686 specific ISP connection, it marks the Server as unreachable from that 687 ISP. (The Client should also inform the Server of this outage via 688 one of its working ISP connections.) If the Client ceases to receive 689 acknowledgements from the Server via multiple ISP connections, it 690 disconnects from the failing Server and connects to a different 691 nearby Server. The act of disconnecting from old servers and 692 connecting to new servers will soon propagate the appropriate routing 693 information among the IRON instance's Relays. 695 When an end system in an EUN sends a flow of packets to a 696 correspondent in a different network, the packets are forwarded 697 through the EUN via normal routing until they reach the Client, which 698 then tunnels the initial packets to one of its connected Servers as 699 its default router. In particular, the Client encapsulates each 700 packet in outer headers with its locator as the source address and 701 the locator of the Server as the destination address. 703 The Client uses the mechanisms specified in VET and SEAL to 704 encapsulate each packet to be forwarded, and uses the redirection 705 procedures described in AERO to coordinate route optimization. The 706 Client further accepts control messages from its Servers, including 707 neighbor coordination exchanges, indications of PMTU limitations, 708 redirections and other control messages. When the Client is 709 redirected to a foreign Server that serves a destination CP, it forms 710 a unidirectional tunnel neighbor association with the foreign Server 711 as the new next hop toward the CP. (The visiting Client can also 712 form a bidirectional tunnel neighbor association with the foreign 713 Server, e.g., if a symmetric security association is necessary.) 715 Note that Client-to-Client tunneling is also enabled when the foreign 716 Client has indicated its willingness to accept Client-to-Client 717 communications. In that case, the foreign Server can allow the final 718 destination Client to return the redirection message, which removes 719 the foreign Server from the fowarding path. 721 7.2. IRON Server Operation 723 After the Server associates with nearby Relays, it accepts Client 724 connections and authenticates the SRS messages it receives from its 725 already-connected Clients. The Server discards any SRS messages that 726 failed authentication, and responds to authentic SRS messages by 727 returning signed SCMP Router Advertisement (SRA) messages. 729 When the Server receives a SEAL-encapsulated data packet from one of 730 its dependent Clients, it uses normal longest-prefix-match rules to 731 locate a forwarding table entry that matches the packet's inner 732 destination address. The Server then re-encapsulates the packet 733 (i.e., it removes the outer header and replaces it with a new outer 734 header), sets the outer destination address to the locator address of 735 the next hop and forwards the packet to the next hop. 737 When the Server receives a SEAL-encapsulated data packet from a 738 visiting Client, it accepts the packet only if the packet's signature 739 is correct; otherwise, it silently drops the packet. The Server then 740 locates a forwarding table entry that matches the packet's inner 741 destination address. If the destination does not correspond to one 742 of the Server's dependent Clients, the Server silently drops the 743 packet. Otherwise, the Server re-encapsulates the packet and 744 forwards it to the correct dependent Client. If the Client is in the 745 process of disconnecting (e.g., due to mobility), the Server also 746 returns a redirection message listing a NULL next hop to inform the 747 visiting Client that the dependent Client has moved. 749 When the Server receives a SEAL-encapsulated data packet from a 750 Relay, it again locates a forwarding table entry that matches the 751 packet's inner destination. If the destination does not correspond 752 to one of the Server's dependent Clients, the Server drops the packet 753 and sends a destination unreachable message. Otherwise, the Server 754 re-encapsulates the packet and forwards it to the correct dependent 755 Client. 757 7.3. IRON Relay Operation 759 After each Relay has synchronized its APs (see Section 6.3) it 760 advertises them in the IPv4 and/or IPv6 interdomain routing systems. 761 These APs will be represented as ordinary routing information in the 762 interdomain routing system, and any packets originating from the IPv4 763 or IPv6 Internetwork destined to an address covered by one of the APs 764 will be forwarded to one of the VSP's Relays. 766 When a Relay receives a packet from the Internetwork destined to a 767 CPA covered by one of its APs, it behaves as an ordinary IP router. 768 Specifically, the Relay looks in its forwarding table to discover a 769 locator of a Server that serves the CP covering the destination 770 address. The Relay then simply forwards the packet to the Server, 771 e.g., via SEAL encapsulation over a tunnel virtual link, via a 772 physical interconnect, etc. 774 When a Relay receives a packet from a Server destined to a CPA 775 serviced by a different Server, the Relay forwards the packet toward 776 the correct Server while also sending a "predirect" indication as the 777 initial leg in the AERO redirection procedure. When the target IA 778 returns a redirection message, the Relay proxies the message by re- 779 encapsulating it and forwarding it to the previous hop. 781 8. IRON Reference Operating Scenarios 783 The following sections discuss the IRON reference operating 784 scenarios. 786 8.1. Both Hosts within Same IRON Instance 788 When both hosts are within EUNs served by the same IRON instance, it 789 is sufficient to consider the scenario in a unidirectional fashion, 790 i.e., by tracing packet flows only in the forward direction from 791 source host to destination host. The reverse direction can be 792 considered separately and incurs the same considerations as for the 793 forward direction. The simplest case occurs when the EUNs that 794 service the source and destination hosts are connected to the same 795 server, while the general case occurs when the EUNs are connected to 796 different Servers. The two cases are discussed in the following 797 sections. 799 8.1.1. EUNs Served by Same Server 801 In this scenario, the packet flow from the source host is forwarded 802 through the EUN to the source's IRON Client. The Client then tunnels 803 the packets to the Server, which simply re-encapsulates and forwards 804 the tunneled packets to the destination's Client. The destination's 805 Client then removes the packets from the tunnel and forwards them 806 over the EUN to the destination. Figure 6 depicts the sustained flow 807 of packets from Host A to Host B within EUNs serviced by the same 808 Server via a "hairpinned" route: 810 ________________________________________ 811 .-( )-. 812 .-( )-. 813 .-( )-. 814 .( ). 815 .( ). 816 .( +------------+ ). 817 ( +===================>| Server(S) |=====================+ ) 818 ( // +------------+ \\ ) 819 ( // .-. .-. \\ ) 820 ( //,-( _)-. ,-( _)-\\ ) 821 ( .||_ (_ )-. .-(_ (_ ||. ) 822 ((_|| ISP A .) (__ ISP B ||_)) 823 ( ||-(______)-' `-(______)|| ) 824 ( || | | vv ) 825 ( +-----+-----+ +-----+-----+ ) 826 | Client(A) | | Client(B) | 827 +-----+-----+ VSP IRON Instance +-----+-----+ 828 ^ | ( (Overlaid on the Native Interntwork) ) | | 829 | .-. .-( .-) .-. | 830 | ,-( _)-. .-(________________________)-. ,-( _)-. | 831 .|(_ (_ )-. .-(_ (_ )| 832 (_| EUN A ) (_ EUN B |) 833 |`-(______)-' `-(______)-| 834 | | Legend: | | 835 | +---+----+ ----> == Native +----+---+ | 836 +-| Host A | ====> == Tunnel | Host B |<+ 837 +--------+ +--------+ 839 Figure 6: Sustained Packet Flow via Hairpinned Route 841 With reference to Figure 6, Host A sends packets destined to Host B 842 via its network interface connected to EUN A. Routing within EUN A 843 will direct the packets to Client(A) as a default router for the EUN, 844 which then encapsulates them in outer IP/*/SEAL headers with its 845 locator address as the outer source address, the locator address of 846 Server(S) as the outer destination address, and the identifying 847 information associated with its tunnel neighbor state as the 848 identity. Client(A) then simply forwards the encapsulated packets 849 into the ISP network connection that provided its locator. The ISP 850 will forward the encapsulated packets into the Internetwork without 851 filtering since the (outer) source address is topologically correct. 852 Once the packets have been forwarded into the Internetwork, routing 853 will direct them to Server(S). 855 Server(S) will receive the encapsulated packets from Client(A) then 856 check its forwarding table to discover an entry that covers 857 destination address B with Client(B) as the next hop. Server(S) then 858 re-encapsulates the packets in a new outer header that uses the 859 source address, destination address, and identification parameters 860 associated with the tunnel neighbor state for Client(B). Server(S) 861 then forwards these re-encapsulated packets into the Internetwork, 862 where routing will direct them to Client(B). Client(B) will, in 863 turn, decapsulate the packets and forward the inner packets to Host B 864 via EUN B. 866 8.1.2. EUNs Served by Different Servers 868 In this scenario, the initial packets of a flow produced by a source 869 host within an EUN connected to the IRON instance by a Client must 870 flow through both the Server of the source host and a nearby Relay, 871 but route optimization can eliminate these elements from the path for 872 subsequent packets in the flow. Figure 7 shows the flow of initial 873 packets from Host A to Host B within EUNs of the same IRON instance: 875 ________________________________________ 876 .-( )-. 877 .-( +------------+ )-. 878 .-( +======>| Relay(R) |=======+ )-. 879 .( || +*--*--*--*-*+ || ). 880 .( || * * vv ). 881 .( +--------++--+* *+--++--------+ ). 882 ( +==>| Server(A) *| | Server(B) |====+ ) 883 ( // +----------*-+ +------------+ \\ ) 884 ( // .-. * .-. \\ ) 885 ( //,-( _)-. * ,-( _)-\\ ) 886 ( .||_ (_ )-. * .-(_ (_ ||. ) 887 ((_|| ISP A .) * (__ ISP B ||_)) 888 ( ||-(______)-' * `-(______)|| ) 889 ( || | * | vv ) 890 ( +-----+-----+ * +-----+-----+ ) 891 | Client(A) |<* | Client(B) | 892 +-----+-----+ VSP IRON Instance +-----+-----+ 893 ^ | ( (Overlaid on the Native Internetwork) ) | | 894 | .-. .-( .-) .-. | 895 | ,-( _)-. .-(________________________)-. ,-( _)-. | 896 .|(_ (_ )-. .-(_ (_ )| 897 (_| EUN A ) (_ EUN B |) 898 |`-(______)-' `-(______)-| 899 | | Legend: | | 900 | +---+----+ ----> == Native +----+---+ | 901 +-| Host A | ====> == Tunnel | Host B |<+ 902 +--------+ <**** == Redirect +--------+ 904 Figure 7: Initial Packet Flow Before Redirects 906 With reference to Figure 7, Host A sends packets destined to Host B 907 via its network interface connected to EUN A. Routing within EUN A 908 will direct the packets to Client(A) as a default router for the EUN, 909 which then encapsulates them in outer IP/*/SEAL headers that use the 910 source address, destination address, and identification parameters 911 associated with the tunnel neighbor state for Server(A). Client(A) 912 then forwards the encapsulated packets into the ISP network 913 connection that provided its locator, which will forward the 914 encapsulated packets into the Internetwork where routing will direct 915 them to Server(A). 917 Server(A) receives the encapsulated packets from Client(A) and 918 consults its forwarding table to determine that the most-specific 919 matching route is via Relay(R) as the next hop. Server(A) then re- 920 encapsulates the packets in outer headers that use the source 921 address, destination address, and identification parameters 922 associated with Relay (R), and forwards them into the Internetwork 923 where routing will direct them to Relay(R). (Note that the Server 924 could instead forward the packets directly to the Relay without 925 encapsulation when the Relay is directly connected, e.g., via a 926 physical interconnect.) 928 Relay(R) receives the forwarded packets from Server(A) then checks 929 its forwarding table to discover a CP entry that covers inner 930 destination address B with Server(B) as the next hop. Relay(R) then 931 sends a "predirect" indication forward to Server(B) to inform the 932 server that a redirection message must be returned. Relay(R) finally 933 re-encapsulates the packets in outer headers that use the source 934 address, destination address, and identification parameters 935 associated with Server(B), then forwards them into the Internetwork 936 where routing will direct them to Server(B). (Note again that the 937 Relay could instead forward the packets directly to the Server, e.g., 938 via a physical interconnect.) 940 Server(B) receives the "predirect" and forwarded packets from 941 Relay(R), then checks its forwarding table to discover a CP entry 942 that covers destination address B with Client(B) as the next hop. 943 Server(B) returns a redirection message to Relay(R), which proxies 944 the message back to Server(A), which then proxies the message back to 945 Client(A). 947 Server(B) then re-encapsulates the packets in outer headers that use 948 the source address, destination address, and identification 949 parameters associated with Client(B), then forwards them into the 950 Internetwork where routing will direct them to Client(B). Client(B) 951 will, in turn, decapsulate the packets and forward the inner packets 952 to Host B via EUN B. 954 After the initial flow of packets, Client(A) will have received one 955 or more redirection messages listing Server(B) as a better next hop, 956 and will establish unidirectional tunnel neighbor state listing 957 Server(B) as the next hop toward the CP that covers Host B. Client(A) 958 thereafter forwards its encapsulated packets directly to the locator 959 address of Server(B) without involving either Server(A) or Relay(B), 960 as shown in Figure 8. 962 ________________________________________ 963 .-( )-. 964 .-( )-. 965 .-( )-. 966 .( ). 967 .( ). 968 .( +------------+ ). 969 ( +====================================>| Server(B) |====+ ) 970 ( // +------------+ \\ ) 971 ( // .-. .-. \\ ) 972 ( //,-( _)-. ,-( _)-\\ ) 973 ( .||_ (_ )-. .-(_ (_ ||. ) 974 ((_|| ISP A .) (__ ISP B ||_)) 975 ( ||-(______)-' `-(______)|| ) 976 ( || | | vv ) 977 ( +-----+-----+ +-----+-----+ ) 978 | Client(A) | | Client(B) | 979 +-----+-----+ IRON Instance +-----+-----+ 980 ^ | ( (Overlaid on the Native Internetwork) ) | | 981 | .-. .-( .-) .-. | 982 | ,-( _)-. .-(________________________)-. ,-( _)-. | 983 .|(_ (_ )-. .-(_ (_ )| 984 (_| EUN A ) (_ EUN B |) 985 |`-(______)-' `-(______)-| 986 | | Legend: | | 987 | +---+----+ ----> == Native +----+---+ | 988 +-| Host A | ====> == Tunnel | Host B |<+ 989 +--------+ +--------+ 991 Figure 8: Sustained Packet Flow After Redirects 993 8.1.3. Client-to-Client Tunneling 995 In the scenarios shown in Sections 8.1.1 and 8.1.2, if the foreign 996 Client has indicated its willingness to accept Client-to-Client 997 communications, then the foreign Server can allow the foreign Client 998 to return the redirection message, i.e., by passing the "predirect" 999 message on to the Client. In that case, the two Clients become peers 1000 in either a unidirectional or bidirectional tunnel neighbor 1001 relationship as shown in Figure 9: 1003 ________________________________________ 1004 .-( )-. 1005 .-( )-. 1006 .-( )-. 1007 .( ). 1008 .( ). 1009 .( ). 1010 ( +=======================================================+ ) 1011 ( // \\ ) 1012 ( // .-. .-. \\ ) 1013 ( //,-( _)-. ,-( _)-\\ ) 1014 ( .||_ (_ )-. .-(_ (_ ||. ) 1015 ((_|| ISP A .) (__ ISP B ||_)) 1016 ( ||-(______)-' `-(______)|| ) 1017 ( || | | vv ) 1018 ( +-----+-----+ +-----+-----+ ) 1019 | Client(A) | | Client(B) | 1020 +-----+-----+ VSP IRON Instance +-----+-----+ 1021 ^ | ( (Overlaid on the Native Internetwork) ) | | 1022 | .-. .-( .-) .-. | 1023 | ,-( _)-. .-(________________________)-. ,-( _)-. | 1024 .|(_ (_ )-. .-(_ (_ )| 1025 (_| EUN A ) (_ EUN B |) 1026 |`-(______)-' `-(______)-| 1027 | | Legend: | | 1028 | +---+----+ <---> == Native +----+---+ | 1029 +-| Host A | <===> == Tunnel | Host B |<+ 1030 +--------+ +--------+ 1032 Figure 9: Client-to-Client Tunneling 1034 8.2. Mixed IRON and Non-IRON Hosts 1036 The cases in which one host is within an IRON EUN and the other is in 1037 a non-IRON EUN (i.e., one that connects to the native Internetwork 1038 instead of the IRON) are described in the following sub-sections. 1040 8.2.1. From IRON Host A to Non-IRON Host B 1042 Figure 10 depicts the IRON reference operating scenario for packets 1043 flowing from Host A in an IRON EUN to Host B in a non-IRON EUN. 1045 _________________________________________ 1046 .-( )-. )-. 1047 .-( +-------)----+ )-. 1048 .-( | Relay(A) |--------------------------+ )-. 1049 .( +------------+ \ ). 1050 .( +=======>| Server(A) | \ ). 1051 .( // +--------)---+ \ ). 1052 ( // ) \ ) 1053 ( // IRON ) \ ) 1054 ( // .-. Instance ) .-. \ ) 1055 ( //,-( _)-. ) ,-( _)-. \ ) 1056 ( .||_ (_ )-. ) The Native .- _ (_ )-| ) 1057 ( _|| ISP A ) ) Internetwork (_ ISP B |)) 1058 ( ||-(______)-' ) `-(______)-' | ) 1059 ( || | )-. | v ) 1060 ( +-----+ ----+ )-. +-----+-----+ ) 1061 | Client(A) |)-. | Router(B) | 1062 +-----+-----+ +-----+-----+ 1063 ^ | ( ) | | 1064 | .-. .-( .-) .-. | 1065 | ,-( _)-. .-(________________________)-. ,-( _)-. | 1066 .|(_ (_ )-. .-(_ (_ )| 1067 (_| EUN A ) ( EUN B |) 1068 |`-(______)-' `-(______)-| 1069 | | Legend: | | 1070 | +---+----+ ----> == Native +----+---+ | 1071 +-| Host A | ====> == Tunnel | Host B |<+ 1072 +--------+ +--------+ 1074 Figure 10: From IRON Host A to Non-IRON Host B 1076 In this scenario, Host A sends packets destined to Host B via its 1077 network interface connected to IRON EUN A. Routing within EUN A will 1078 direct the packets to Client(A) as a default router for the EUN, 1079 which then encapsulates them and forwards them into the Internetwork 1080 routing system where they will be directed to Server(A). 1082 Server(A) receives the encapsulated packets from Client(A) then 1083 forwards them to Relay(A), which simply forwards the unencapsulated 1084 packets into the Internetwork. Once the packets are released into 1085 the Internetwork, routing will direct them to the final destination 1086 B. (Note that for simplicity Server(A) and Relay(A) are depicted in 1087 Figure 10 as two concatenated "half-routers", and the forwarding 1088 between the two halves is via encapsulation, via a physical 1089 interconnect, via a shared memory operation when the two halves are 1090 within the same physical platform, etc.) 1092 8.2.2. From Non-IRON Host B to IRON Host A 1094 Figure 11 depicts the IRON reference operating scenario for packets 1095 flowing from Host B in an Non-IRON EUN to Host A in an IRON EUN. 1097 _________________________________________ 1098 .-( )-. )-. 1099 .-( +-------)----+ )-. 1100 .-( | Relay(A) |<-------------------------+ )-. 1101 .( +------------+ \ ). 1102 .( +========| Server(A) | \ ). 1103 .( // +--------)---+ \ ). 1104 ( // ) \ ) 1105 ( // IRON ) \ ) 1106 ( // .-. Instance ) .-. \ ) 1107 ( //,-( _)-. ) ,-( _)-. \ ) 1108 ( .||_ (_ )-. ) The Native .- _ (_ )-| ) 1109 ( _|| ISP A ) ) Internetwork (_ ISP B |)) 1110 ( ||-(______)-' ) `-(______)-' | ) 1111 ( vv | )-. | | ) 1112 ( +-----+ ----+ )-. +-----+-----+ ) 1113 | Client(A) |)-. | Router(B) | 1114 +-----+-----+ +-----+-----+ 1115 | | ( ) | | 1116 | .-. .-( .-) .-. | 1117 | ,-( _)-. .-(________________________)-. ,-( _)-. | 1118 .|(_ (_ )-. .-(_ (_ )| 1119 (_| EUN A ) ( EUN B |) 1120 |`-(______)-' `-(______)-| 1121 | | Legend: | | 1122 | +---+----+ <---- == Native +----+---+ | 1123 +>| Host A | <==== == Tunnel | Host B |-+ 1124 +--------+ +--------+ 1126 Figure 11: From Non-IRON Host B to IRON Host A 1128 In this scenario, Host B sends packets destined to Host A via its 1129 network interface connected to non-IRON EUN B. Interdomain routing 1130 will direct the packets to Relay(A), which then forwards them to 1131 Server(A). 1133 Server(A) will then check its forwarding table to discover an entry 1134 that covers destination address A with Client(A) as the next hop. 1135 Server(A) then (re-)encapsulates the packets and forwards them into 1136 the Internetwork, where routing will direct them to Client(A). 1137 Client(A) will, in turn, decapsulate the packets and forward the 1138 inner packets to Host A via its network interface connected to IRON 1139 EUN A. 1141 8.3. Hosts within Different IRON Instances 1143 Figure 12 depicts the IRON reference operating scenario for packets 1144 flowing between Host A in an IRON instance A and Host B in a 1145 different IRON instance B. In that case, forwarding between hosts A 1146 and B always involves the Servers and Relays of both IRON instances, 1147 i.e., the scenario is no different than if one of the hosts was 1148 serviced by an IRON EUN and the other was serviced by a non-IRON EUN. 1149 _________________________________________ 1150 .-( )-. .-( )-. 1151 .-( +-------)----+ +---(--------+ )-. 1152 .-( | Relay(A) | <---> | Relay(B) | )-. 1153 .( +------------+ +------------+ ). 1154 .( +=======>| Server(A) | | Server(B) |<======+ ). 1155 .( // +--------)---+ +---(--------+ \\ ). 1156 ( // ) ( \\ ) 1157 ( // IRON ) ( IRON \\ ) 1158 ( // .-. Instance A ) ( Instance B .-. \\ ) 1159 ( //,-( _)-. ) ( ,-( _). || ) 1160 ( .||_ (_ )-. ) ( .-'_ (_ )|| ) 1161 ( _|| ISP A ) ) ( (_ ISP B ||)) 1162 ( ||-(______)-' ) ( '-(______)-|| ) 1163 ( vv | )-. .-( | vv ) 1164 ( +-----+ ----+ )-. .-( +-----+-----+ ) 1165 | Client(A) |)-. .-(| Client(B) | 1166 +-----+-----+ The Native +-----+-----+ 1167 ^ | ( Internetwork ) | ^ 1168 | .-. .-( .-) .-. | 1169 | ,-( _)-. .-(________________________)-. ,-( _)-. | 1170 .|(_ (_ )-. .-(_ (_ )| 1171 (_| EUN A ) (_ EUN B |) 1172 |`-(______)-' `-(______)-| 1173 | | Legend: | | 1174 | +---+----+ <---> == Native +----+---+ | 1175 +>| Host A | <===> == Tunnel | Host B |<+ 1176 +--------+ +--------+ 1178 Figure 12: Hosts within Different IRON Instances 1180 9. Mobility, Multiple Interfaces, Multihoming, and Traffic Engineering 1182 While IRON Servers and Relays are typically arranged as fixed 1183 infrastructure, Clients may need to move between different network 1184 points of attachment, connect to multiple ISPs, or explicitly manage 1185 their traffic flows. The following sections discuss mobility, 1186 multihoming, and traffic engineering considerations for IRON Clients. 1188 9.1. Mobility Management and Mobile Networks 1190 When a Client changes its network point of attachment (e.g., due to a 1191 mobility event), it configures one or more new locators. If the 1192 Client has not moved far away from its previous network point of 1193 attachment, it simply informs its connected Server and any Client 1194 neighbors of any locator changes. This operation is performance 1195 sensitive and should be conducted immediately to avoid packet loss. 1196 This aspect of mobility can be classified as a "localized mobility 1197 event". 1199 If the Client has moved far away from its previous network point of 1200 attachment, however, it re-issues the Server discovery procedure 1201 described in Section 6.3. If the Client's current Server is no 1202 longer close by, the Client may wish to move to a new Server in order 1203 to reduce routing stretch. This operation is not performance 1204 critical, and therefore can be conducted over a matter of minutes/ 1205 seconds instead of milliseconds/microseconds. This aspect of 1206 mobility can be classified as a "global mobility event". 1208 To move to a new Server, the Client first engages in the CP 1209 registration process with the new Server, as described in Section 1210 6.3. The Client then informs its former Server that it has departed; 1211 again, via a VSP-specific secured reliable transport connection. The 1212 former Server will then withdraw its CP advertisements from the IRON 1213 instance routing system and retain the (stale) forwarding table 1214 entries until their lifetime expires. In the interim, the former 1215 Server continues to deliver packets to the Client's last-known 1216 locator addresses for the short term while informing any 1217 unidirectional tunnel neighbors that the Client has moved. 1219 Note that the Client may be either a mobile host or a mobile router. 1220 In the case of a mobile router, the Client's EUN becomes a mobile 1221 network, and can continue to use the Client's CPs without renumbering 1222 even as it moves between different network attachment points. 1224 9.2. Multiple Interfaces and Multihoming 1226 A Client may register multiple ISP connections with each Server such 1227 that multiple interfaces are naturally supported. This feature 1228 results in the Client "harnessing" its multiple ISP connections into 1229 a "bundle" that is represented as a single entity at the network 1230 layer, and therefore allows for ISP independence at the link-layer. 1232 A Client may further register with multiple Servers for fault 1233 tolerance and reduced routing stretch. In that case, the Client 1234 should register its full bundle of ISP connections with each of its 1235 Servers unless it has a reason for carefully coordinating its 1236 individual ISP-to-Server mappings. 1238 Client registration with multiple Servers results in "pseudo- 1239 multihoming", in which the multiple homes are within the same VSP 1240 IRON instance and hence share fate with the health of the IRON 1241 instance itself. 1243 9.3. Traffic Engineering 1245 A Client can dynamically adjust its ISP-to-Server mappings in order 1246 to influence inbound traffic flows. It can also change between 1247 Servers when multiple Servers are available, but should strive for 1248 stability in its Server selection in order to limit VSP network 1249 routing churn. 1251 A Client can select outgoing ISPs, e.g., based on current Quality-of- 1252 Service (QoS) considerations such as minimizing delay or variance. 1254 10. Renumbering Considerations 1256 As new link-layer technologies and/or service models emerge, end 1257 users will be motivated to select their basic Internetwork 1258 connectivity solutions through healthy competition between ISPs. If 1259 an end user's network-layer addresses are tied to a specific ISP, 1260 however, they may be forced to undergo a painstaking renumbering even 1261 if they wish to change to a different ISP [RFC4192][RFC5887]. 1263 When an end user Client obtains CPs from a VSP, it can change between 1264 ISPs seamlessly and without need to renumber the CPs. IRON therefore 1265 provides ISP independence at the link layer. If the end user is 1266 later compelled to change to a different VSP, however, it would be 1267 obliged to abandon its CPs and obtain new ones from the new VSP. In 1268 that case, the Client would again be required to engage in a 1269 painstaking renumbering event. 1271 In order to avoid any future renumbering headaches, a Client that is 1272 part of a cooperative collective (e.g., a large enterprise network) 1273 could join together with the collective to obtain a suitably large PI 1274 prefix then and hire a VSP to manage the prefix on behalf of the 1275 collective. If the collective later decides to switch to a new VSP, 1276 it simply revokes its PI prefix registration with the old VSP and 1277 activates its registration with the new VSP. 1279 11. NAT Traversal Considerations 1281 The Internet today consists of a global public IPv4 routing and 1282 addressing system with non-IRON EUNs that use either public or 1283 private IPv4 addressing. The latter class of EUNs connect to the 1284 public Internet via Network Address Translators (NATs). When an IRON 1285 Client is located behind a NAT, it selects Servers using the same 1286 procedures as for Clients with public addresses and can then send SRS 1287 messages to Servers in order to get SRA messages in return. The only 1288 requirement is that the Client must configure its encapsulation 1289 format to use a transport protocol that supports NAT traversal, e.g., 1290 UDP, TCP, etc. 1292 Since the Server maintains state about its dependent Clients, it can 1293 discover locator information for each Client by examining the 1294 transport port number and IP address in the outer headers of the 1295 Client's encapsulated packets. When there is a NAT in the path, the 1296 transport port number and IP address in each encapsulated packet will 1297 correspond to state in the NAT box and might not correspond to the 1298 actual values assigned to the Client. The Server can then 1299 encapsulate packets destined to hosts in the Client's EUN within 1300 outer headers that use this IP address and transport port number. 1301 The NAT box will receive the packets, translate the values in the 1302 outer headers, then forward the packets to the Client. In this 1303 sense, the Server's "locator" for the Client consists of the 1304 concatenation of the IP address and transport port number. 1306 In order to keep NAT and Server connection state alive, the Client 1307 sends periodic beacons to the server, e.g., by sending an SRS message 1308 to elicit an SRA message from the Server. IRON does not otherwise 1309 introduce any new complications for NAT traversal or for applications 1310 embedding address referrals in their payload. 1312 12. Multicast Considerations 1314 IRON Servers and Relays are topologically positioned to provide 1315 Internet Group Management Protocol (IGMP) / Multicast Listener 1316 Discovery (MLD) proxying for their Clients [RFC4605]. Further 1317 multicast considerations for IRON (e.g., interactions with multicast 1318 routing protocols, traffic scaling, etc.) are out of scope and will 1319 be discussed in a future document. 1321 13. Nested EUN Considerations 1323 Each Client configures a locator that may be taken from an ordinary 1324 non-CPA address assigned by an ISP or from a CPA address taken from a 1325 CP assigned to another Client. In that case, the Client is said to 1326 be "nested" within the EUN of another Client, and recursive nestings 1327 of multiple layers of encapsulations may be necessary. 1329 For example, in the network scenario depicted in Figure 13, Client(A) 1330 configures a locator CPA(B) taken from the CP assigned to EUN(B). 1331 Client(B) in turn configures a locator CPA(C) taken from the CP 1332 assigned to EUN(C). Finally, Client(C) configures a locator ISP(D) 1333 taken from a non-CPA address delegated by an ordinary ISP(D). 1335 Using this example, the "nested-IRON" case must be examined in which 1336 a Host A, which configures the address CPA(A) within EUN(A), 1337 exchanges packets with Host Z located elsewhere in a different IRON 1338 instance EUN(Z). 1340 .-. 1341 ISP(D) ,-( _)-. 1342 +-----------+ .-(_ (_ )-. 1343 | Client(C) |--(_ ISP(D) ) 1344 +-----+-----+ `-(______)-' 1345 | <= T \ .-. 1346 .-. u \ ,-( _)-. 1347 ,-( _)-. n .-(_ (- )-. 1348 .-(_ (_ )-. n (_ Internetwork ) 1349 (_ EUN(C) ) e `-(______)-' 1350 `-(______)-' l ___ 1351 | CPA(C) s => (:::)-. 1352 +-----+-----+ .-(::::::::) 1353 | Client(B) | .-(: Multiple :)-. +-----------+ 1354 +-----+-----+ (:::::: IRON ::::::) | Relay(Z) | 1355 | `-(: Instances:)-' +-----------+ 1356 .-. `-(::::::)-' +-----------+ 1357 ,-( _)-. | Server(Z) | 1358 .-(_ (_ )-. +---------------+ +-----------+ 1359 (_ EUN(B) ) |Relay/Server(C)| +-----------+ 1360 `-(______)-' +---------------+ | Client(Z) | 1361 | CPA(B) +---------------+ +-----------+ 1362 +-----+-----+ |Relay/Server(B)| | 1363 | Client(A) | +---------------+ .-. 1364 +-----------+ +---------------+ ,-( _)-. 1365 | |Relay/Server(A)| .-(_ (_ )-. 1366 .-. +---------------+ (_ EUN(Z) ) 1367 ,-( _)-. CPA(A) `-(______)-' 1368 .-(_ (_ )-. +--------+ +--------+ 1369 (_ EUN(A) )---| Host A | | Host Z | 1370 `-(______)-' +--------+ +--------+ 1372 Figure 13: Nested EUN Example 1374 The two cases of Host A sending packets to Host Z, and Host Z sending 1375 packets to Host A, must be considered separately, as described below. 1377 13.1. Host A Sends Packets to Host Z 1379 Host A first forwards a packet with source address CPA(A) and 1380 destination address Z into EUN(A). Routing within EUN(A) will direct 1381 the packet to Client(A), which encapsulates it in an outer header 1382 with CPA(B) as the outer source address and Server(A) as the outer 1383 destination address then forwards the once-encapsulated packet into 1384 EUN(B). 1386 Routing within EUN(B) will direct the packet to Client(B), which 1387 encapsulates it in an outer header with CPA(C) as the outer source 1388 address and Server(B) as the outer destination address then forwards 1389 the twice-encapsulated packet into EUN(C). Routing within EUN(C) 1390 will direct the packet to Client(C), which encapsulates it in an 1391 outer header with ISP(D) as the outer source address and Server(C) as 1392 the outer destination address. Client(C) then sends this triple- 1393 encapsulated packet into the ISP(D) network, where it will be routed 1394 via the Internetwork to Server(C). 1396 When Server(C) receives the triple-encapsulated packet, it forwards 1397 it to Relay(C) which removes the outer layer of encapsulation and 1398 forwards the resulting twice-encapsulated packet into the 1399 Internetwork to Server(B). Next, Server(B) forwards the packet to 1400 Relay(B) which removes the outer layer of encapsulation and forwards 1401 the resulting once-encapsulated packet into the Internetwork to 1402 Server(A). Next, Server(A) forwards the packet to Relay(A), which 1403 decapsulates it and forwards the resulting inner packet via the 1404 Internetwork to Relay(Z). Relay(Z), in turn, forwards the packet to 1405 Server(Z), which encapsulates and forwards the packet to Client(Z), 1406 which decapsulates it and forwards the inner packet to Host Z. 1408 13.2. Host Z Sends Packets to Host A 1410 When Host Z sends a packet to Host A, forwarding in EUN(Z) will 1411 direct it to Client(Z), which encapsulates and forwards the packet to 1412 Server(Z). Server(Z) will forward the packet to Relay(Z), which will 1413 then decapsulate and forward the inner packet into the Internetwork. 1414 Interdomain will convey the packet to Relay(A) as the next-hop 1415 towards CPA(A), which then forwards it to Server(A). 1417 Server (A) encapsulates the packet and forwards it to Relay(B) as the 1418 next-hop towards CPA(B) (i.e., the locator for CPA(A)). Relay(B) 1419 then forwards the packet to Server(B), which encapsulates it a second 1420 time and forwards it to Relay(C) as the next-hop towards CPA(C) 1421 (i.e., the locator for CPA(B)). Relay(C) then forwards the packet to 1422 Server(C), which encapsulates it a third time and forwards it to 1423 Client(C). 1425 Client(C) then decapsulates the packet and forwards the resulting 1426 twice-encapsulated packet via EUN(C) to Client(B). Client(B) in turn 1427 decapsulates the packet and forwards the resulting once-encapsulated 1428 packet via EUN(B) to Client(A). Client(A) finally decapsulates and 1429 forwards the inner packet to Host A. 1431 14. Implications for the Internet 1433 For IRON instances configured over the public Internet as the 1434 underlying Internetwork, the IRON system requires a VSP deployment of 1435 new routers/servers throughout the Internet to maintain well-balanced 1436 virtual overlay networks. These routers/servers can be deployed 1437 incrementally without disruption to existing Internet infrastructure 1438 as long as they are appropriately managed to provide acceptable 1439 service levels to end users. 1441 End-to-end traffic that traverses an IRON instance may experience 1442 delay variance between the initial packets and subsequent packets of 1443 a flow. This is due to the IRON system allowing a longer path 1444 stretch for initial packets followed by timely route optimizations to 1445 utilize better next hop routers/servers for subsequent packets. 1447 IRON instances work seamlessly with existing and emerging services 1448 within the native Internet. In particular, end users serviced by an 1449 IRON instance will receive the same service enjoyed by end users 1450 serviced by non-IRON service providers. Internet services already 1451 deployed within the native Internet also need not make any changes to 1452 accommodate IRON end users. 1454 The IRON system operates between IAs within the Internet and EUNs. 1455 Within these networks, the underlying paths traversed by the virtual 1456 overlay networks may comprise links that accommodate varying MTUs. 1457 While the IRON system imposes an additional per-packet overhead that 1458 may cause the size of packets to become slightly larger than the 1459 underlying path can accommodate, IAs have a method for naturally 1460 detecting and tuning out instances of path MTU underruns. In some 1461 cases, these MTU underruns may need to be reported back to the 1462 original hosts; however, the system will also allow for MTUs much 1463 larger than those typically available in current Internet paths to be 1464 discovered and utilized as more links with larger MTUs are deployed. 1466 Finally, and perhaps most importantly, the IRON system provides in- 1467 built mobility management, mobile networks, multihoming and traffic 1468 engineering capabilities that allow end user devices and networks to 1469 move about freely while both imparting minimal oscillations in the 1470 routing system and maintaining generally shortest-path routes. This 1471 mobility management is afforded through the very nature of the IRON 1472 service model, and therefore requires no adjunct mechanisms. The 1473 mobility management and multihoming capabilities are further 1474 supported by forward-path reachability detection that provides "hints 1475 of forward progress" in the same spirit as for IPv6 Neighbor 1476 Discovery (ND). 1478 15. Additional Considerations 1480 Considerations for the scalability of interdomain routing due to 1481 multihoming, traffic engineering, and provider-independent addressing 1482 are discussed in [RADIR] [I-D.narten-radir-problem-statement]. Other 1483 scaling considerations specific to IRON are discussed in Appendix B. 1485 Route optimization considerations for mobile networks are found in 1486 [RFC5522]. 1488 In order to ensure acceptable end user service levels, the VSP should 1489 conduct a capacity analysis and distribute sufficient Relays and 1490 Servers for the IRON instance globally throughout the Internet. As 1491 for common practices in the Internet today, such capacity analysis 1492 can be conducted in parallel with actual deployment of the service. 1494 16. Related Initiatives 1496 IRON builds upon the concepts of the RANGER architecture [RFC5720] , 1497 and therefore inherits the same set of related initiatives. The 1498 Internet Research Task Force (IRTF) Routing Research Group (RRG) 1499 mentions IRON in its recommendation for a routing architecture 1500 [RFC6115]. 1502 Virtual Aggregation (VA) [GROW-VA] and Aggregation in Increasing 1503 Scopes (AIS) [EVOLUTION] provide the basis for the Virtual Prefix 1504 concepts. 1506 Internet Vastly Improved Plumbing (Ivip) [IVIP-ARCH] has contributed 1507 valuable insights, including the use of real-time mapping. The use 1508 of Servers as mobility anchor points is directly influenced by Ivip's 1509 associated TTR mobility extensions [TTRMOB]. 1511 [RO-CR][I-D.bernardos-mext-nemo-ro-cr] discusses a route optimization 1512 approach using a Correspondent Router (CR) model. The IRON Server 1513 construct is similar to the CR concept described in this work; 1514 however, the manner in which Clients coordinate with Servers is 1515 different and based on the NBMA virtual link model [RFC5214]. 1517 Numerous publications have proposed NAT traversal techniques. The 1518 NAT traversal techniques adapted for IRON were inspired by the Simple 1519 Address Mapping for Premises Legacy Equipment (SAMPLE) proposal 1520 [SAMPLE][I-D.carpenter-softwire-sample]. 1522 The IRON Client-Server relationship is managed in essentially the 1523 same way as for the Tunnel Broker model [RFC3053]. Numerous existing 1524 provider networks that provide service similar to tunnel broker 1525 (e.g., Hurricane Electric, SixXS, freenet6, etc.) provide existence 1526 proofs that IRON-like overlay network services can be deployed and 1527 managed on a global basis [BROKER]. 1529 IRON is further related to the Identifier-Locator Network Protocol 1530 (ILNP) [RFC6740] and Locator / ID Split Protocol (LISP) [RFC6830] 1531 proposals which address routing scaling aspects at the interdomain 1532 level. IRON is therefore complimentary to these approaches. 1534 17. IANA Considerations 1536 There are no IANA considerations for this document. 1538 18. Security Considerations 1540 Security considerations that apply to tunneling in general are 1541 discussed in [RFC6169]. Additional considerations that apply also to 1542 IRON are discussed in RANGER [RFC5720][RFC6139] , VET [INTAREA-VET] 1543 and SEAL [INTAREA-SEAL]. 1545 The IRON system further depends on mutual authentication of IRON 1546 Clients to Servers and Servers to Relays. As for all Internet 1547 communications, the IRON system also depends on Relays acting with 1548 integrity and not injecting false advertisements into the interdomain 1549 routing system (e.g., to mount traffic siphoning attacks). 1551 IRON Agents must perform message origin authentication on the packets 1552 they accept from correspondents. IAs must therefore include a 1553 signature on each packet that the destination can use to verify that 1554 the IA is authorized to use the source address. 1556 IRON Servers must ensure that any changes in a Client's locator 1557 addresses are communicated only through an authenticated exchange 1558 that is not subject to replay. For this reason, Clients periodically 1559 send digitally-signed SRS messages to the Server. If the Client's 1560 locator address stays the same, the Server can accept the SRS message 1561 without verifying the signature. If the Client's locator address 1562 changes, the Server must verify the SRS message's signature before 1563 accepting the message. Once the message has been authenticated, the 1564 Server updates the Client's locator address to the new address. 1566 Each IRON instance requires a means for assuring the integrity of the 1567 interior routing system so that all Relays and Servers in the overlay 1568 have a consistent view of CP<->Server bindings. Also, Denial-of- 1569 Service (DoS) attacks on IRON Relays and Servers can occur when 1570 packets with spoofed source addresses arrive at high data rates. 1571 However, this issue is no different than for any border router in the 1572 public Internet today. 1574 Middleboxes can interfere with tunneled packets within an IRON 1575 instance in various ways. For example, a middlebox may alter a 1576 packet's contents, change a packet's locator addresses, inject 1577 spurious packets, replay old packets, etc. These issues are no 1578 different than for middlebox interactions with ordinary Internet 1579 communications. If man-in-the-middle attacks are a matter for 1580 concern in certain deployments, however, IRON Agents can use IPsec 1581 [RFC4301] or TLS/SSL [RFC5246] to protect the authenticity, integrity 1582 and (if necessary) privacy of their tunneled packets. 1584 19. Acknowledgements 1586 The ideas behind this work have benefited greatly from discussions 1587 with colleagues; some of which appear on the RRG and other IRTF/IETF 1588 mailing lists. Robin Whittle and Steve Russert co-authored the TTR 1589 mobility architecture, which strongly influenced IRON. Eric 1590 Fleischman pointed out the opportunity to leverage anycast for 1591 discovering topologically close Servers. Thomas Henderson 1592 recommended a quantitative analysis of scaling properties. 1594 The following individuals provided essential review input: Jari 1595 Arkko, Mohamed Boucadair, Stewart Bryant, John Buford, Ralph Droms, 1596 Wesley Eddy, Adrian Farrel, Dae Young Kim, and Robin Whittle. 1598 Discussions with colleagues following the publication of RFC6179 have 1599 provided useful insights that have resulted in significant 1600 improvements to this, the Second Edition of IRON. 1602 This document received substantial review input from the IESG and 1603 IETF area directorates in the February 2013 timeframe. IESG members 1604 and IETF area directorate representatives who contributed helpful 1605 comments and suggestions are gratefully acknowledged. 1607 20. References 1608 20.1. Normative References 1610 [INTAREA-SEAL] 1611 Templin, F., Ed., "The Subnetwork Encapsulation and 1612 Adaptation Layer (SEAL)", Work in Progress, February 2011. 1614 [INTAREA-VET] 1615 Templin, F., Ed., "Virtual Enterprise Traversal (VET)", 1616 Work in Progress, January 2011. 1618 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1619 September 1981. 1621 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1622 (IPv6) Specification", RFC 2460, December 1998. 1624 [RFC6706] Templin, F., "Asymmetric Extended Route Optimization 1625 (AERO)", RFC 6706, August 2012. 1627 20.2. Informative References 1629 [BGPMON] net, B., "BGPmon.net - Monitoring Your Prefixes, 1630 http://bgpmon.net/stat.php", June 2010. 1632 [BROKER] Wikipedia, W., "List of IPv6 Tunnel Brokers, 1633 http://en.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers", 1634 August 2011. 1636 [EVOLUTION] 1637 Zhang, B., Zhang, L., and L. Wang, "Evolution Towards 1638 Global Routing Scalability", Work in Progress, 1639 October 2009. 1641 [GROW-VA] Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and 1642 L. Zhang, "FIB Suppression with Virtual Aggregation", Work 1643 in Progress, February 2011. 1645 [I-D.bernardos-mext-nemo-ro-cr] 1646 Bernardos, C., Calderon, M., and I. Soto, "Correspondent 1647 Router based Route Optimisation for NEMO (CRON)", 1648 draft-bernardos-mext-nemo-ro-cr-00 (work in progress), 1649 July 2008. 1651 [I-D.carpenter-softwire-sample] 1652 Carpenter, B. and S. Jiang, "Legacy NAT Traversal for 1653 IPv6: Simple Address Mapping for Premises Legacy Equipment 1654 (SAMPLE)", draft-carpenter-softwire-sample-00 (work in 1655 progress), June 2010. 1657 [I-D.narten-radir-problem-statement] 1658 Narten, T., "On the Scalability of Internet Routing", 1659 draft-narten-radir-problem-statement-05 (work in 1660 progress), February 2010. 1662 [IVIP-ARCH] 1663 Whittle, R., "Ivip (Internet Vastly Improved Plumbing) 1664 Architecture", Work in Progress, March 2010. 1666 [RADIR] Narten, T., "On the Scalability of Internet Routing", Work 1667 in Progress, February 2010. 1669 [RFC0994] International Organization for Standardization (ISO) and 1670 American National Standards Institute (ANSI), "Final text 1671 of DIS 8473, Protocol for Providing the Connectionless- 1672 mode Network Service", RFC 994, March 1986. 1674 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1675 E. Lear, "Address Allocation for Private Internets", 1676 BCP 5, RFC 1918, February 1996. 1678 [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, 1679 selection, and registration of an Autonomous System (AS)", 1680 BCP 6, RFC 1930, March 1996. 1682 [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 1683 Tunnel Broker", RFC 3053, January 2001. 1685 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 1686 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 1687 September 2005. 1689 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1690 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1692 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1693 Internet Protocol", RFC 4301, December 2005. 1695 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1696 Network Address Translations (NATs)", RFC 4380, 1697 February 2006. 1699 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 1700 "Internet Group Management Protocol (IGMP) / Multicast 1701 Listener Discovery (MLD)-Based Multicast Forwarding 1702 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 1704 [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB 1705 Workshop on Routing and Addressing", RFC 4984, 1706 September 2007. 1708 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1709 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1710 March 2008. 1712 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1713 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1715 [RFC5522] Eddy, W., Ivancic, W., and T. Davis, "Network Mobility 1716 Route Optimization Requirements for Operational Use in 1717 Aeronautics and Space Exploration Mobile Networks", 1718 RFC 5522, October 2009. 1720 [RFC5720] Templin, F., "Routing and Addressing in Networks with 1721 Global Enterprise Recursion (RANGER)", RFC 5720, 1722 February 2010. 1724 [RFC5743] Falk, A., "Definition of an Internet Research Task Force 1725 (IRTF) Document Stream", RFC 5743, December 2009. 1727 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 1728 Still Needs Work", RFC 5887, May 2010. 1730 [RFC6115] Li, T., "Recommendation for a Routing Architecture", 1731 RFC 6115, February 2011. 1733 [RFC6139] Russert, S., Fleischman, E., and F. Templin, "Routing and 1734 Addressing in Networks with Global Enterprise Recursion 1735 (RANGER) Scenarios", RFC 6139, February 2011. 1737 [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security 1738 Concerns with IP Tunneling", RFC 6169, April 2011. 1740 [RFC6740] Atkinson,, RJ., "Identifier-Locator Network Protocol 1741 (ILNP) Architectural Description", RFC 6740, 1742 November 2012. 1744 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 1745 Locator/ID Separation Protocol (LISP)", RFC 6830, 1746 January 2013. 1748 [RO-CR] Bernardos, C., Calderon, M., and I. Soto, "Correspondent 1749 Router based Route Optimisation for NEMO (CRON)", Work 1750 in Progress, July 2008. 1752 [SAMPLE] Carpenter, B. and S. Jiang, "Legacy NAT Traversal for 1753 IPv6: Simple Address Mapping for Premises Legacy Equipment 1754 (SAMPLE)", Work in Progress, June 2010. 1756 [TTRMOB] Whittle, R. and S. Russert, "TTR Mobility Extensions for 1757 Core-Edge Separation Solutions to the Internet's Routing 1758 Scaling Problem, 1759 http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf", 1760 August 2008. 1762 Appendix A. IRON Operation over Internetworks with Different Address 1763 Families 1765 The IRON architecture leverages the routing system by providing 1766 generally shortest-path routing for packets with CPA addresses from 1767 APs that match the address family of the underlying Internetwork. 1768 When the APs are of an address family that is not routable within the 1769 underlying Internetwork, however, (e.g., when OSI/NSAP [RFC0994] APs 1770 are used over an IPv4 Internetwork) a global Master AP mapping 1771 database (MAP) is required. The MAP allows the Relays of the local 1772 IRON instance to map APs belonging to other IRON instances to 1773 addresses taken from companion prefixes of address families that are 1774 routable within the Internetwork. For example, an IPv6 AP (e.g., 1775 2001:DB8::/32) could be paired with one or more companion IPv4 1776 prefixes (e.g., 192.0.2.0/24) so that encapsulated IPv6 packets can 1777 be forwarded over IPv4-only Internetworks. (In the limiting case, 1778 the companion prefixes could themselves be singleton addresses, e.g., 1779 192.0.2.1/32). 1781 The MAP is maintained by a globally managed authority, e.g. in the 1782 same manner as the Internet Assigned Numbers Authority (IANA) 1783 currently maintains the master list of all top-level IPv4 and IPv6 1784 delegations. The MAP can be replicated across multiple servers for 1785 load balancing using common Internetworking server hierarchies, e.g., 1786 the DNS caching resolvers, ftp mirror servers, etc. 1788 Upon startup, each Relay advertises IPv4 companion prefixes (e.g., 1789 192.0.2.0/24) into the IPv4 Internetwork routing system and/or IPv6 1790 companion prefixes (e.g., 2001:DB8::/64) into the IPv6 Internetwork 1791 routing system for the IRON instance that it serves. The Relay then 1792 selects singleton host numbers within the IPv4 companion prefixes 1793 (e.g., 192.0.2.1) and/or IPv6 companion prefixes (e.g., as 1794 2001:DB8::0), and assigns the resulting addresses to its Internetwork 1795 interfaces. (When singleton companion prefixes are used (e.g., 1796 192.0.2.1/32), the Relay does not advertise a the companion prefixes 1797 but instead simply assigns them to its Internetwork interfaces and 1798 allows standard Internet routing to direct packets to the 1799 interfaces.) 1800 The Relay then discovers the APs for other IRON instances by reading 1801 the MAP, either a priori or on-demand of data packets addressed to 1802 other AP destinations. The Relay reads the MAP from a nearby MAP 1803 server and periodically checks the server for deltas since the 1804 database was last read. The Relay can then forward packets toward 1805 CPAs belonging to other IRON instances by encapsulating them in an 1806 outer header of the companion prefix address family and using the 1807 Relay anycast address as the outer destination address. 1809 Possible encapsulations in this model include IPv6-in-IPv4, IPv4-in- 1810 IPv6, OSI/CLNP-in-IPv6, OSI/CLNP-in-IPv4, etc. Details of how the 1811 DNS can be used as a MAP are given in Section 5.4 of VET 1812 [INTAREA-VET]. 1814 Appendix B. Scaling Considerations 1816 Scaling aspects of the IRON architecture have strong implications for 1817 its applicability in practical deployments. Scaling must be 1818 considered along multiple vectors, including interdomain core routing 1819 scaling, scaling to accommodate large numbers of EUNs, traffic 1820 scaling, state requirements, etc. 1822 In terms of routing scaling, each VSP will advertise one or more APs 1823 into the interdomain routing system from which CPs are delegated to 1824 end users. Routing scaling will therefore be minimized when each AP 1825 covers many CPs. For example, the IPv6 prefix 2001:DB8::/32 contains 1826 2^24 ::/56 CP prefixes for assignment to EUNs; therefore, the VSP 1827 could accommodate 2^32 ::/56 CPs with only 2^8 ::/32 APs advertised 1828 in the interdomain routing core. (When even longer CP prefixes are 1829 used, e.g., /64s assigned to individual handsets in a cellular 1830 provider network, many more EUNs can be represented within only a 1831 single AP.) 1833 In terms of traffic scaling for Relays, each Relay represents an ASBR 1834 of a "shell" enterprise network that simply directs arriving traffic 1835 packets with CPA destination addresses towards Servers that service 1836 the corresponding Clients. Moreover, the Relay sheds traffic 1837 destined to CPAs through redirection, which removes it from the path 1838 for the majority of traffic packets between Clients within the same 1839 IRON instance. On the other hand, each Relay must handle all traffic 1840 packets forwarded between the CPs it manages and the rest of the 1841 Internetwork. The scaling concerns for this latter class of traffic 1842 are no different than for ASBR routers that connect large enterprise 1843 networks to the Internet. In terms of traffic scaling for Servers, 1844 each Server services a set of CPs. The Server services all traffic 1845 packets destined to its own CPs but only services the initial packets 1846 of flows initiated from its own CPs and destined to other CPs. 1847 Therefore, traffic scaling for CPA-addressed traffic is an asymmetric 1848 consideration and is proportional to the number of CPs each Server 1849 serves. When possible, the Server can also be removed from the path 1850 in order to allow direct Client-to-Client communications as described 1851 in Section 8.1.3. In that case, the Server's burden in handling data 1852 packets is greatly reduced. 1854 In terms of state requirements for Relays, each Relay maintains a 1855 list of Servers in the IRON instance as well as forwarding table 1856 entries for the CPs that each Server handles. This Relay state is 1857 therefore dominated by the total number of CPs handled by the Relay's 1858 associated Servers. Keeping in mind that current day core router 1859 technologies are only capable of handling fast-path FIB cache sizes 1860 of O(1M) entries, a large-scale deployment may require that the total 1861 CP database for the VSP overlay be spread between the FIBs of a mesh 1862 of Relays rather than fully-resident in the FIB of each Relay. In 1863 that case, the techniques of Virtual Aggregation (VA) may be useful 1864 in bridging together the mesh of Relays. Alternatively, each Relay 1865 could elect to keep some or all CP prefixes out of the FIB and 1866 maintain them only in a slow-path forwarding table. In that case, 1867 considerably more CP entries could be kept in each Relay at the cost 1868 of incurring slow-path processing for the initial packets of a flow. 1870 In terms of state requirements for Servers, each Server maintains 1871 state only for the CPs it serves, and not for the CPs handled by 1872 other Servers in the IRON instance. Finally, neither Relays nor 1873 Servers need keep state for final destinations of outbound traffic. 1875 Clients source and sink all traffic packets originating from or 1876 destined to the CP. Therefore, traffic scaling considerations for 1877 Clients are the same as for any site border router. Clients also 1878 retain tunnel neighbor state for final destinations of outbound 1879 traffic flows. This can be managed as soft state, since stale 1880 entries purged from the cache will be refreshed when new traffic 1881 packets are sent. 1883 Author's Address 1885 Fred L. Templin (editor) 1886 Boeing Research & Technology 1887 P.O. Box 3707 MC 7L-49 1888 Seattle, WA 98124 1889 USA 1891 EMail: fltemplin@acm.org