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