idnits 2.17.1 draft-templin-iron-03.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 (June 7, 2010) is 5065 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-06) exists of draft-ietf-grow-va-02 == Outdated reference: A later version (-05) exists of draft-russert-rangers-03 == Outdated reference: A later version (-68) exists of draft-templin-intarea-seal-14 == Outdated reference: A later version (-40) exists of draft-templin-intarea-vet-13 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). 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 June 7, 2010 5 Expires: December 9, 2010 7 The Internet Routing Overlay Network (IRON) 8 draft-templin-iron-03.txt 10 Abstract 12 The Internet routing system is experiencing a growth profile that has 13 led many to express concerns for unsustainable routing scaling. 14 Operational practices such as increased use of multihoming with IPv4 15 Provider-Independent (PI) addressing are resulting in more and more 16 fine-grained prefixes injected into the routing system from more and 17 more end user networks. Furthermore, depletion of the remaining 18 public IPv4 address space has raised concerns for both increased 19 deaggregation (leading to yet further routing scaling) and an 20 impending address space runout scenario. At the same time, the IPv6 21 routing system is finally beginning to see significant growth in IPv6 22 Provider-Aggregated (PA) prefixes but there does not seem to be a 23 solution on the near term horizon for IPv6 PI addressing. Since the 24 Internet must continue to support escalating growth due to increasing 25 demand, it is clear that current mechanisms and operational practices 26 are reaching a tipping point where something must be done. This 27 document proposes an Internet Routing Overlay Network (IRON) for 28 supporting sustainable growth through PI addressing while requiring 29 no changes to end systems and no changes to the existing routing 30 system. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on December 9, 2010. 49 Copyright Notice 51 Copyright (c) 2010 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. IRON Routers . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 4. The Internet Routing Overlay Network (IRON) . . . . . . . . . 5 70 5. IRON Initialization . . . . . . . . . . . . . . . . . . . . . 6 71 5.1. IR(VP) and IR(GW) Initialization . . . . . . . . . . . . . 6 72 5.2. IR(EUN) Initialization . . . . . . . . . . . . . . . . . . 7 73 6. IRON Operation . . . . . . . . . . . . . . . . . . . . . . . . 8 74 6.1. IR(EUN) Operation . . . . . . . . . . . . . . . . . . . . 8 75 6.2. IR(VP) Operation . . . . . . . . . . . . . . . . . . . . . 9 76 6.3. IR(GW) Operation . . . . . . . . . . . . . . . . . . . . . 10 77 6.4. IRON Example Scenario . . . . . . . . . . . . . . . . . . 10 78 6.5. Mobility Management . . . . . . . . . . . . . . . . . . . 12 79 7. Related Initiatives . . . . . . . . . . . . . . . . . . . . . 12 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 81 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 82 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 85 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 1. Introduction 90 The Internet routing system is experiencing a growth profile that has 91 led many to express concerns for unsustainable routing scaling. 92 Operational practices such as increased use of multihoming with IPv4 93 Provider-Independent (PI) addressing are resulting in more and more 94 fine-grained prefixes injected into the routing system from more and 95 more end user networks. Furthermore, depletion of the remaining 96 public IPv4 address space has raised concerns for both increased 97 deaggregation (leading to yet further routing scaling) and an 98 impending address space runout scenario. At the same time, the IPv6 99 routing system is finally beginning to see significant growth in IPv6 100 Provider-Aggregated (PA) prefixes but there does not seem to be a 101 solution on the near term horizon for IPv6 PI addressing. Since the 102 Internet must continue to support escalating growth due to increasing 103 demand, it is clear that current mechanisms and operational practices 104 are reaching a tipping point where something must be done. 106 Virtual Aggregation (VA) [I-D.ietf-grow-va] and Aggregation in 107 Increasing Scopes (AIS) [I-D.zhang-evolution] are global routing 108 proposals that introduce routing overlays using Virtual Prefixes 109 (VPs) to reduce router Forwarding Information Base (FIB) and Routing 110 Information Base (RIB) scaling. Routing and Addressing in Networks 111 with Global Enterprise Recursion (RANGER) [RFC5720] examines 112 recursive arrangements of enterprise networks that can apply to a 113 very broad set of use case scenarios [I-D.russert-rangers]. In 114 particular, RANGER supports encapsulation and secure redirection by 115 treating each layer in the recursive hierarchy as a virtual non- 116 broadcast, multiple access (NBMA) "link". RANGER is an architectural 117 framework that includes Virtual Enterprise Traversal (VET) 118 [I-D.templin-intarea-vet] and the Subnetwork Adaptation and 119 Encapsulation Layer (SEAL) [I-D.templin-intarea-seal] as its 120 functional building blocks. 122 This document proposes an Internet Routing Overlay Network (IRON) for 123 supporting sustainable growth while requiring no changes to the 124 existing routing system. IRON borrows concepts from VA, AIS and 125 RANGER, and further borrows concepts from the Internet Vastly 126 Improved Plumbing (Ivip) [I-D.whittle-ivip-arch] architecture 127 proposal. IRON specifically seeks to enable scalable Provider- 128 Independent (PI) addressing without changing the current BGP 129 [RFC4271] routing systems of the IPv4 and IPv6 Internets in any way. 131 IRON uses the IPv4 and IPv6 global Internet routing systems as 132 virtual NBMA links for tunneling inner network protocol packets that 133 use End User Network (EUN) addresses within outer IPv4 or IPv6 134 packets that use Routing LOCator (RLOC) addresses. Moreover, inner 135 packets can be either IPv4 or IPv6 without regard to the address 136 family used in the outer packet, and inner packets can even be non-IP 137 protocols such as OSI. The following sections discuss details of the 138 IRON architecture. 140 2. Terminology 142 The following abbreviations correspond to terms used within this 143 document and elsewhere in common Internetworking nomenclature: 145 EP - End User Network PI Prefix 147 ETE - Egress Tunnel Endpoint 149 EUN - End User Network 151 ISP - Internet Service Provider 153 ITE - Ingress Tunnel Endpoint 155 NBMA - Non-Broadcast, Multiple Access 157 PA - Provider Aggregated 159 PI - Provider Independent 161 SCMP - the SEAL Control Message Protocol 163 SEAL_ID - an Identification value, randomly initialized and 164 monotonically incremented for each SEAL protocol packet 166 TE - Tunnel Endpoint (i.e., either ingress or egress) 168 VP - Virtual Prefix 170 3. IRON Routers 172 IRON introduces a new class of routers called IRON Routers (IRs) that 173 can be deployed on platforms ranging from high-end enterprise routers 174 to simple commodity servers. Moreover, IRs can be introduced 175 incrementally and without affecting existing infrastructure. The 176 purpose of these new IRs is to provide waypoints (or "cairns") for 177 navigating the IRON so that packets with destination addresses taken 178 from End User Network PI prefixes (EPs) can be delivered to the 179 correct End User Networks (EUNs) through the use of encapsulation 180 with minimum path stretch for initial packets and optimized routes 181 for non-initial packets. The different categories of IRs includes: 183 o IR - an IRON Router of any kind 185 o IR(VP) - a tunnel endpoint router that is owned by a VP company 186 and that aggregates VPs from which it sub-delegates more-specific 187 EPs to EUNs. 189 o IR(EUN) - a tunnel endpoint router (or host with embedded gateway 190 function) that obtains an EP from a VP company, and that connects 191 an EUN to the IRON. An IR(EUN) will typically be a customer 192 premises equipment (CPE) device that connects the EUN to its 193 ISP(s), but may also be a router or even a singleton host within 194 the EUN. 196 o IR(GW) - a router that acts as a gateway between the IRON and the 197 non-IRON Internet. Each VP company configures one or more IR(GWs) 198 which advertise the company's VPs into the IPv4 and/or IPv6 global 199 Internet DFZs. An IR(GW) may be configured on the same physical 200 platform as IR(VPs), or as a separate standalone platform. An 201 IR(GW) will typically be a BGP router that is capable of sourcing 202 encapsulated packets. 204 IRON observes the Internet Protocol standards [RFC0791][RFC2460]. 205 Other network layer protocols that can be encapsulated within IP 206 packets (e.g., OSI/CLNP [RFC1070], etc.) are also within scope. 208 4. The Internet Routing Overlay Network (IRON) 210 The Internet Routing Overlay Network (IRON) consists of IRON Routers 211 (IRs) that use Virtual Enterprise Traversal (VET) and the Subnetwork 212 Encapsulation and Adaptation Layer (SEAL) for the purpose of 213 forwarding encapsulated inner network layer packets over the IPv4 and 214 IPv6 Internets. Each such IR views the IPv4 and IPv6 global 215 Internets as monolithic virtual NBMA "links", and connects to the 216 links via a VET interface used for automatic tunneling. Each IR 217 therefore sees all other IRs as virtual single-hop neighbors on the 218 link from the standpoint of the inner network layer protocol, while 219 they may be separated by many physical outer IP hops. IRs are 220 deployed incrementally and without disturbing the existing Internet 221 routing system. 223 The IRON is manifested through a business model in which VP companies 224 own and manage a set of IR(VPs) that are dispersed throughout the 225 Internet and that serve a set of highly-aggregated VPs. Each VP 226 company sets up a service in which it leases EPs taken from the VPs 227 to customer EUNs. These EUNs may be located on the same network as 228 the VP company's IR(VP) routers, or they may be located elsewhere 229 within the Internet. The VP company acts as a virtual enterprise 230 network which EUNs loosely consider as their "home" network even 231 though they physically arrange for basic connectivity via one or more 232 ISP networks that may have no affiliation with the VP company. VP 233 companies can therefore open for business and begin serving their 234 customers immediately without the need to coordinate their activities 235 with ISPs or with other VP companies. 237 Each VP company also establishes a set of IR(GW) routers that connect 238 to the IPv4 and/or IPv6 Internet DFZs. The IR(GW) advertises all of 239 the vendor's IPv4 VPs into the IPv4 DFZ and advertises all of its 240 IPv6 VPs into the IPv6 DFZ. Each IR(GW) forwards any packets coming 241 from the DFZ to an IR(VP) that can encapsulate the packet and forward 242 it to the appropriate IR(EUN). In this way, end systems that use PA 243 addresses can communicate with other end systems that use PI 244 addresses taken from an IRON VP. 246 EUNs establish at least one IR(EUN) that connects the EUN to the 247 IRON. The IR(EUN) uses encapsulation to forward packets with PI 248 source addresses to an IR(VP) belonging to its VP company as a 249 default router. The VP company's IR(VP) then forwards the packets 250 toward their final destination, and returns a SEAL Control Message 251 Protocol (SCMP) redirect message to inform the IR(EP) of a better 252 next hop if necessary. In this way, IR(EPs) experience reasonable 253 path stretch for initial packets and can discover route-optimized 254 paths for subsequent packets. 256 In a typical scenario, an IR(EUN) 'A' forwards initial packets 257 addressed to another IR(EUN) 'B' through an IR(VP) in its home 258 network. The IR(VP) in 'A's home network then forwards the packet to 259 an IR(VP) in 'B's home network, then sends a redirect message to 'A'. 260 'A' will forward subsequent packets through an IR(VP) in 'B's home 261 network, which will forward the packets to IR(EUN) 'B' and return a 262 redirect message to 'A'. Following these redirections, subsequent 263 packets will flow directly from 'A' to 'B'. 265 5. IRON Initialization 267 IRON initialization entails the startup actions of VP company and EUN 268 equipment. The following sections discuss these startups procedures: 270 5.1. IR(VP) and IR(GW) Initialization 272 Upon startup, each IR(VP) and IR(GW) owned by the VP company 273 discovers the full set of VPs for the IRON. These VPs may be IPv4 or 274 IPv6, but they may also be prefixes of other network layer protocols 275 (e.g., OSI NSAP [RFC4548], etc.). Each VP is maintained in a Master 276 VP (MVP) flat file that consists of the union of all VPs in the IRON. 278 The MVP file is maintained by a globally-managed assigned numbers 279 authority in exactly the same manner as the Internet Assigned Numbers 280 Authority (IANA) currently maintains the master list of all top-level 281 IPv4 and IPv6 delegations. (Indeed, the IANA is proposed as the 282 primary registration authority for the MVP file.) Each VP in the MVP 283 file is encoded as the tuple: "{address family, prefix/length, 284 FQDN}", where: 286 o "address family" is one of IPv4, IPv6, OSI/CLNP, etc. 288 o "prefix/length" is the VP and its associated length, e.g., 2001: 289 DB8::/32 (IPv6), 192.2/16 (IPv4), etc. 291 o FQDN is a DNS Fully-Qualified Domain Name 293 Each IR(VP/GW) reads the MVP from a nearby server upon startup time, 294 and periodically checks for deltas on the server since the MVP was 295 last read. (The MVP can be replicated across multiple servers for 296 load balancing much in the same way that FTP mirror sites are used to 297 manage software distributions.) Upon reading the MVP, the IR(VP/GW) 298 resolves the FQDN corresponding to each VP into a list of DNS Well- 299 Known Service (WKS) resource records with an IRON-specific format (to 300 be specified) that includes the address family, RLOC address, and 301 geographic (Latitude/Longitude) coordinates at which the IR(VP) is 302 physically located. Each RLOC address is an IPv4 or IPv6 RLOC 303 address of an IR(VP) within the DFZ. 305 For each VP, the IR(VP/GW) sorts the list of RLOCs in order of 306 "geographic closeness", and inserts each "VP->RLOC" mapping into its 307 Forwarding Information Base (FIB) with a priority corresponding to 308 geographic closeness. Specifically, the FIB entries must be 309 configured such that packets with destination addresses covered by 310 the VP are forwarded to the corresponding RLOC using encapsulation of 311 the inner network layer packet in an outer IP header. Note that the 312 VP and RLOC may be of different address families; hence, possible 313 encapsulations include IPv6-in-IPv4, IPv4-in-IPv6, IPv6-in-IPv6, 314 IPv4-in-IPv4, OSI/CLNP-in-IPv6, OSI/CLNP-in-IPv4, etc. After each 315 IR(VP/GW) reads in the list of VPs and sorts the information 316 accordingly, it is said to be "synchronized with the IRON". Each 317 IR(VP) next installs all EPs derived from its VPs into its FIB based 318 on the mapping information received from each EUN that owns a prefix. 320 5.2. IR(EUN) Initialization 322 Upon startup, each IR(EUN) must register its EP-to-RLOC binding with 323 the company that owns the corresponding VP, where the RLOC is an IPv4 324 or IPv6 address assigned to the IR(EUN) by an ISP network. For 325 example, if an IR(EUN) owns the EP 192.2.1/24 (IPv4) and the RLOC 326 assigned to the IR(EUN) by the ISP is 2001:DB8::1 (IPv6), the IR(EUN) 327 informs the VP company that the route 192.2.1/24 with 2001:DB8::1 as 328 the L2 address of the next-hop must be added to the FIB in each of 329 its IR(VPs) that aggregates the EP. The IR(EUN) typically informs 330 the VP company by using an authenticated short transaction protocol 331 (e.g., http(s) with username/password) to register its EP-to-RLOC 332 mapping information. (The exact specification for the short 333 transaction is up to the VP company and need only be communicated to 334 the IR(EUN); the IR(EUN) also uses the same EP-to-RLOC registration 335 procedure to inform its VP company of a change in RLOC, e.g., due to 336 a mobility event.) After the IR(EUN) registers its mapping 337 information, the VP company then propagates it to each of its IR(VPs) 338 that aggregates the EP, e.g., via a routing protocol that all of the 339 VP company's IR(VP)s engage in. 341 After the IR(EUN) informs the VP company of its EP->RLOC mapping, it 342 resolves a FQDN for the VP company in order to discover the RLOC 343 addresses and geographic locations of the IR(VPs) owned by the 344 company. (This resolution is analogous to the ISATAP Potential 345 Router List (PRL) resolution procedure [RFC5214].) The IR(EUN) then 346 selects the closest subset of these RLOC addresses (typically 2-4 347 routers chosen, e.g., based on geographic distance), and adds them to 348 a default router list of FIB entries that each points to a tunnel 349 virtual interface with the RLOC as the L2 address of the next-hop. 350 The IR(EP) will then use these routes in the default router list as 351 the means for forwarding encapsulated packets with EID source 352 addresses toward the final destination via encapsulation. 354 6. IRON Operation 356 Following IRON initialization, IRs engage in the steady-state process 357 of receiving and forwarding packets. Except in instances when it 358 forwards an unencapsulated packet to the public Internet, the IR 359 encapsulates each forwarded packet using the mechanisms of VET 360 [I-D.templin-intarea-vet] and SEAL [I-D.templin-intarea-seal]. IRs 361 also use the SEAL Control Message Protocol (SCMP) to test liveness of 362 other IRs and to receive redirects informing them of a better next 363 hop. Each IR operates as specified in the following sections: 365 6.1. IR(EUN) Operation 367 After an IR(EUN) is initialized, it sends periodic beacons to at 368 least 2-4 of its VP company's IR(VP)s which serve as default routers. 369 Each beacon is a SEAL Control Message Protocol (SCMP) Router 370 Solicitation (RS) message, and will elicit an SCMP Router 371 Advertisement (RA) message from the IR(VP). If the IR(EUN) ceases to 372 receive RA messages from an IR(VP), it marks that IR(VP) as 373 unreachable and selects a different IR(VP). If the IR(EUN) ceases to 374 receive RA message from multiple IR(VPs), it marks the ISP connection 375 as failed/failing and uses an RLOC assigned by a different ISP to re- 376 register its EP-to-RLOC mapping. 378 When an end system in an EUN has a packet to send, the packet is 379 forwarded through the EUN until it reaches the IR(EUN). The source 380 IR(EUN) then forwards the packet either to an IR(VP) or to a 381 destination IR(EUN). The source IR(EUN) first checks its FIB for the 382 longest matching prefix. If the longest matching prefix is more- 383 specific than "default", the source IR(EUN) forwards the packet to 384 the next-hop the same as for ordinary IP forwarding. If the longest 385 match is "default", however, the source IR(EUN) forwards the packet 386 to one of its default routers. 388 The source IR(EUN) uses VET and SEAL to encapsulate each forwarded 389 packet in an outer IP header with the IP address of the next-hop IR 390 as the destination address. The source IR(EUN) further uses SCMP to 391 test liveness and/or to accept redirect messages from the next-hop 392 IR. When the source IR(EUN) receives an SCMP redirect, it checks the 393 SEAL_ID field of the encapsulated message to verify that the redirect 394 corresponds to a packet that it had previously sent to the neighbor 395 and accepts the redirect if there is a match. Thereafter, subsequent 396 packets forwarded by the source IR(EUN) will follow a route-optimized 397 path. 399 An IR(EUN) that accepts redirects may be redirected by an IR(VP) in 400 its home VP company network to one or more IR(VP)s in a "foreign" 401 network. In that case, the IR(EUN) has no way of knowing if these 402 foreign IR(VP)s are reachable and able to process encapsulated 403 packets. Therefore, the IR(EUN) should select multiple foreign 404 IR(VPs) (e.g., 2-4) and send "live" packets to one of them while 405 sending corresponding "blank" packets to the others. In turn, each 406 foreign IR(VP) accepts and forwards "live" packets, but drops "blank" 407 packets after sending a redirect. In this way, even if the original 408 packet is lost due to short- or long-term outage, the IR(EUN) should 409 receive a redirect from at least one of the foreign IR(VP)s. 411 6.2. IR(VP) Operation 413 After an IR(VP) is initialized, it sends RA responses to the periodic 414 RS beacons sent by IR(EUNs) as described in Section 6.1. When the 415 IR(VP) receives an encapsulated packet from another IR, it examines 416 the inner destination address then forwards the packet as follows: 418 o If the inner destination address matches an EP in its FIB, the 419 IR(VP) 'A' re-encapsulates the packet using VET/SEAL and forwards 420 it to the next-hop IR(EUN) 'B'. If the source IR 'C' is accepting 421 redirects, 'A' also sends an SCMP redirect message back to 'C'. 422 'C' will then send subsequent packets directly to 'B'. 424 o If the inner destination address does not match an EP but matches 425 a VP in its FIB, the IR(VP) 'A' re-encapsulates the packet using 426 VET/SEAL and forwards it to the next-hop IR(VP) 'B' . If the 427 source IR 'C' is accepting redirects, 'A' also sends an SCMP 428 redirect message back to 'C'. 'C' will then send subsequent 429 packets directly to 'B'. 431 o if the inner destination address does not match an EP or a VP in 432 the FIB, the IR(VP) decapsulates the packet and forwards it to the 433 public Internet via a default or more-specific route. 435 An IR(VP) that accepts redirects may need to forward encapsulated 436 packets via the IR(VP)s of a "foreign" network. In that case, the 437 IR(VP) can send a "live" packet in parallel with corresponding 438 "blanks" the same as for an IR(EUN). 440 6.3. IR(GW) Operation 442 Each VP company must establish one or more IR(GW) routers which 443 advertise the full set of the company's VP's into the IPv4 and/or 444 IPv6 Internet BGP. The VPs will be seen as ordinary routing 445 information in the BGP, and any packets originating from the non-IRON 446 IPv4 or IPv6 Internet will be forwarded into the VP company's network 447 by an IR(GW). When an IR(GW) receives a packet from the non-IRON 448 Internet but destined to an EP destination, it consults its FIB to 449 determine the best next-hop toward the final destination. The IR(GW) 450 then either forwards the packet to an IR(VP) within the home network 451 or acts as an IR(VP) itself to forward the packet further. 453 6.4. IRON Example Scenario 455 With respect to the previous sections, a path between two EUNs can 456 potentially involve both the two IR(EUNs) and the IR(VP)s of the two 457 VP companies that serve the EUNs. Route optimization based on 458 redirection will allow shortcuts that eliminate the IR(VP)s from the 459 path. The following figure depicts a simple example IRON scenario 460 for communications between two EUNs: 462 +------------+ +------------+ 463 | | | | 464 /======>+ IR(VP(A)) +======>+ IR(VP(B)) +======\ 465 // | | | | \\ 466 // +------------+ +------------+ \\ 467 // V 468 +-----+-----+ +-----+-----+ 469 | IR(EUN(A))| ........................................>| IR(EUN(B))| 470 +-----+-----+ +-----+-----+ 471 | | 472 ........ ........ 473 ( EUN B ) ( EUN B ) 474 ........ ........ 475 | | 476 +---+----+ +---+----+ 477 | Host A | | Host B | 478 +--------+ +--------+ 480 Figure 1: Example IRON Scenario 482 In this example scenario, VP companies A and B have established 483 IR(VP)s within the Internet that serve EPs to EUNs. EUN A has 484 procured an EP from VP company A, while EUN B has procured an EP from 485 VP company B. The hosts in both EUNs have assigned addresses taken 486 from their corresponding EPs on their EUN-interior interfaces, and 487 the IR(EUNs) have assigned provider-aggregated addresses taken from 488 their ISPs on their WAN interfaces. 490 When Host A in EUN A has a packet to send to Host B in EUN B, normal 491 routing conveys the packet from Host A to IR(EUN(A)). If IR(EUN(A 492 ))does not have a more-specific route, it encapsulates the packet and 493 forwards it to an IR(VP) owned by VP company A. IR(VP(A )) 494 decapsulates the packet and checks its FIB for a route toward the 495 packet's destination address. If IR(VP(A)) does not have an EP route 496 to B in its FIB, it consults its full table of VP-to-RLOC mappings to 497 discover that the next-hop toward Host B is via IR(VP(B)). IR(VP(A)) 498 then re-encapsulates the packet and sends it to IR(VP(B)) which has 499 an EP route B via IR(EUN(B)). IR(VP(B)) then re-encapsulates the 500 packet and sends it to IR(EUN(B)), which decapsulates the packet and 501 forwards it via EUN B to Host B. 503 In this process, when an IR(VP) re-encapsulates the packet and 504 forwards it to a next-hop IR, it also returns an SCMP redirect 505 message to the previous hop IR if the previous hop is willing to 506 accept redirects. The previous hop IR will then install a route in 507 its FIB that uses a more optimal next hop. For example, if 508 IR(EUN(A)) is accepting redirects IR(VP(A)) will return a redirect 509 message when it forwards a packet to IR(VP(B)). IR(EUN(A)) will then 510 send subsequent packets directly to IR(VP(B)), which will return a 511 redirect message when it forwards the packets to IR(EUN(B)). 512 Finally, IR(EUN(A)) will have an optimized route that lists 513 IR(EUN(B)) as the next hop (shown as "....>" in the diagram). 515 A more interesting redirection scenario arises when IR(VP(A)) is 516 itself willing to accept redirects. In that case, IR(EUN(A)) may 517 discover IR(EUN(B)) as a better next hop toward EUN A based solely on 518 a redirect message from IR(VP(A)) and without involving IR(VP(B)). 519 Note however that this may require IR(VP(A)) to carry thousands or 520 even millions of EP entries in its FIB for all EUNs that it has sent 521 packets to recently. 523 6.5. Mobility Management 525 When an IR(EUN) moves to a new topological location and/or changes 526 its primary ISP, it receives a new RLOC address. The IR(EUN) then 527 registers the new EP-to-RLOC mapping with its VP company the same as 528 during its initialization phase as described in Section 5.2. 530 Next, the IR(EUN) sends Neighbor Advertisement (NA) messages to each 531 neighboring IR from which it has received packets recently. The NA 532 message includes the new RLOC as the outer source address and 533 includes the previous RLOC within an NA option field. The 534 neighboring IR will update its neighbor cache so that subsequent 535 packets will flow through the new RLOC. 537 Further details on these mobility management procedures are specified 538 in [I-D.templin-intarea-vet] and [I-D.templin-intarea-seal]. 540 7. Related Initiatives 542 IRON builds upon the concepts RANGER architecture [RFC5720], and 543 therefore inherits the same set of related initiatives. 545 Virtual Aggregation (VA) [I-D.ietf-grow-va] and Aggregation in 546 Increasing Scopes (AIS) [I-D.zhang-evolution] provide the basis for 547 the Virtual Prefix concepts. 549 Internet vastly improved plumbing (Ivip) [I-D.whittle-ivip-arch] has 550 contributed valuable insights, including the use of real-time 551 mapping. 553 8. IANA Considerations 555 The IANA is instructed to create a Master Virtual Prefix (MVP) 556 registry for IRON. 558 9. Security Considerations 560 Security considerations for RANGER apply also to IRON. 562 10. Acknowledgements 564 This ideas behind this work have benefited greatly from discussions 565 with colleagues; some of which appear on the RRG and other IRTF/IETF 566 mailing lists. 568 11. References 570 11.1. Normative References 572 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 573 September 1981. 575 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 576 (IPv6) Specification", RFC 2460, December 1998. 578 11.2. Informative References 580 [I-D.ietf-grow-va] 581 Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and 582 L. Zhang, "FIB Suppression with Virtual Aggregation", 583 draft-ietf-grow-va-02 (work in progress), March 2010. 585 [I-D.russert-rangers] 586 Russert, S., Fleischman, E., and F. Templin, "Operational 587 Scenarios for IRON and RANGER", draft-russert-rangers-03 588 (work in progress), June 2010. 590 [I-D.templin-intarea-seal] 591 Templin, F., "The Subnetwork Encapsulation and Adaptation 592 Layer (SEAL)", draft-templin-intarea-seal-14 (work in 593 progress), June 2010. 595 [I-D.templin-intarea-vet] 596 Templin, F., "Virtual Enterprise Traversal (VET)", 597 draft-templin-intarea-vet-13 (work in progress), 598 June 2010. 600 [I-D.whittle-ivip-arch] 601 Whittle, R., "Ivip (Internet Vastly Improved Plumbing) 602 Architecture", draft-whittle-ivip-arch-04 (work in 603 progress), March 2010. 605 [I-D.zhang-evolution] 606 Zhang, B. and L. Zhang, "Evolution Towards Global Routing 607 Scalability", draft-zhang-evolution-02 (work in progress), 608 October 2009. 610 [RFC1070] Hagens, R., Hall, N., and M. Rose, "Use of the Internet as 611 a subnetwork for experimentation with the OSI network 612 layer", RFC 1070, February 1989. 614 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 615 Protocol 4 (BGP-4)", RFC 4271, January 2006. 617 [RFC4548] Gray, E., Rutemiller, J., and G. Swallow, "Internet Code 618 Point (ICP) Assignments for NSAP Addresses", RFC 4548, 619 May 2006. 621 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 622 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 623 March 2008. 625 [RFC5720] Templin, F., "Routing and Addressing in Networks with 626 Global Enterprise Recursion (RANGER)", RFC 5720, 627 February 2010. 629 Author's Address 631 Fred L. Templin (editor) 632 Boeing Research & Technology 633 P.O. Box 3707 MC 7L-49 634 Seattle, WA 98124 635 USA 637 Email: fltemplin@acm.org