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