idnits 2.17.1 draft-templin-iron-05.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 9, 2010) is 5062 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-15 == Outdated reference: A later version (-40) exists of draft-templin-intarea-vet-15 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Research Task Force F. Templin, Ed. 3 (IRTF) Boeing Research & Technology 4 Internet-Draft June 9, 2010 5 Intended status: Informational 6 Expires: December 11, 2010 8 The Internet Routing Overlay Network (IRON) 9 draft-templin-iron-05.txt 11 Abstract 13 The Internet routing system is experiencing a growth profile that has 14 led many to express concerns for unsustainable routing scaling. 15 Operational practices such as increased use of multihoming with IPv4 16 Provider-Independent (PI) addressing are resulting in more and more 17 fine-grained prefixes injected into the routing system from more and 18 more end user networks. Furthermore, depletion of the remaining 19 public IPv4 address space has raised concerns for both increased 20 deaggregation (leading to yet further routing scaling) and an 21 impending address space runout scenario. At the same time, the IPv6 22 routing system is finally beginning to see significant growth in IPv6 23 Provider-Aggregated (PA) prefixes but there does not seem to be a 24 solution on the near term horizon for IPv6 PI addressing. Since the 25 Internet must continue to support escalating growth due to increasing 26 demand, it is clear that current mechanisms and operational practices 27 must be updated. This document therefore proposes an Internet 28 Routing Overlay Network (IRON) for supporting sustainable growth 29 through PI addressing while requiring no changes to end systems and 30 no changes to the existing routing system. This document is a 31 product of the IRTF Routing Research Group (RRG). 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on December 11, 2010. 50 Copyright Notice 52 Copyright (c) 2010 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. IRON Routers . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 4. The Internet Routing Overlay Network (IRON) . . . . . . . . . 5 71 5. IRON Initialization . . . . . . . . . . . . . . . . . . . . . 7 72 5.1. IR(VP) and IR(GW) Initialization . . . . . . . . . . . . . 7 73 5.2. IR(EP) Initialization . . . . . . . . . . . . . . . . . . 8 74 6. IRON Operation . . . . . . . . . . . . . . . . . . . . . . . . 9 75 6.1. IR(EP) Operation . . . . . . . . . . . . . . . . . . . . . 9 76 6.2. IR(VP) Operation . . . . . . . . . . . . . . . . . . . . . 10 77 6.3. IR(GW) Operation . . . . . . . . . . . . . . . . . . . . . 10 78 6.4. IRON Reference Operating Scenario . . . . . . . . . . . . 11 79 6.5. Mobility, Multihoming and Traffic Engineering . . . . . . 12 80 6.5.1. Mobility Management . . . . . . . . . . . . . . . . . 12 81 6.5.2. Multihoming . . . . . . . . . . . . . . . . . . . . . 13 82 6.5.3. Inbound Traffic Engineering . . . . . . . . . . . . . 13 83 6.5.4. Outbound Traffic Engineering . . . . . . . . . . . . . 13 84 7. Related Initiatives . . . . . . . . . . . . . . . . . . . . . 14 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 87 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 89 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 90 11.2. Informative References . . . . . . . . . . . . . . . . . . 14 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 93 1. Introduction 95 The Internet routing system is experiencing a growth profile that has 96 led many to express concerns for unsustainable routing scaling. 97 Operational practices such as increased use of multihoming with IPv4 98 Provider-Independent (PI) addressing are resulting in more and more 99 fine-grained prefixes injected into the routing system from more and 100 more end user networks. Furthermore, depletion of the remaining 101 public IPv4 address space has raised concerns for both increased 102 deaggregation (leading to yet further routing scaling) and an 103 impending address space runout scenario. At the same time, the IPv6 104 routing system is finally beginning to see significant growth in IPv6 105 Provider-Aggregated (PA) prefixes but there does not seem to be a 106 solution on the near term horizon for IPv6 PI addressing. Since the 107 Internet must continue to support escalating growth due to increasing 108 demand, it is clear that current mechanisms and operational practices 109 must be updated. 111 Virtual Aggregation (VA) [I-D.ietf-grow-va] and Aggregation in 112 Increasing Scopes (AIS) [I-D.zhang-evolution] are global routing 113 proposals that introduce routing overlays with Virtual Prefixes (VPs) 114 for router Forwarding Information Base (FIB) and Routing Information 115 Base (RIB) scaling reduction. Routing and Addressing in Networks 116 with Global Enterprise Recursion (RANGER) [RFC5720] examines 117 recursive arrangements of enterprise networks that can apply to a 118 very broad set of use case scenarios [I-D.russert-rangers]. In 119 particular, RANGER supports encapsulation and secure redirection by 120 treating each layer in the recursive hierarchy as a virtual non- 121 broadcast, multiple access (NBMA) "link". RANGER is an architectural 122 framework that includes Virtual Enterprise Traversal (VET) 123 [I-D.templin-intarea-vet] and the Subnetwork Adaptation and 124 Encapsulation Layer (SEAL) [I-D.templin-intarea-seal] as its 125 functional building blocks. 127 This document proposes an Internet Routing Overlay Network (IRON) for 128 supporting sustainable growth while requiring no changes to the 129 existing routing system. IRON borrows concepts from VA, AIS and 130 RANGER, and further borrows concepts from the Internet Vastly 131 Improved Plumbing (Ivip) [I-D.whittle-ivip-arch] architecture 132 proposal. IRON specifically seeks to enable scalable Provider- 133 Independent (PI) addressing without changing the current BGP 134 [RFC4271] routing systems of the IPv4 and IPv6 Internets in any way. 136 IRON uses the IPv4 and IPv6 global Internet routing systems as 137 virtual NBMA links for tunneling inner network protocol packets that 138 use End User Network (EUN) PI Prefix (EP) source addresses within 139 outer IPv4 or IPv6 packets that use Routing LOCator (RLOC) addresses. 140 Moreover, inner packets can be either IPv4 or IPv6 without regard to 141 the address family used in the outer packet, and inner packets can 142 even be non-IP protocols such as OSI/CLNP. 144 This document is offered in compliance with Internet Research Task 145 Force (IRTF) document stream procedures [RFC5743]; it is not an IETF 146 product and is not a standard. The views in this document were 147 considered controversial by the IRTF Routing Research Group (RRG) but 148 the RG reached a consensus that the document should still be 149 published. The document will undergo a period of review within the 150 RRG and through selected expert reviewers prior to publication. The 151 following sections discuss details of the IRON architecture. 153 2. Terminology 155 The following abbreviations correspond to terms used within this 156 document and elsewhere in common Internetworking nomenclature: 158 EP - End User Network PI Prefix 160 ETE - Egress Tunnel Endpoint 162 EUN - End User Network 164 ISP - Internet Service Provider 166 ITE - Ingress Tunnel Endpoint 168 MVP - Master Virtual Prefix (database) 170 NBMA - Non-Broadcast, Multiple Access 172 PA - Provider Aggregated 174 PI - Provider Independent 176 SCMP - the SEAL Control Message Protocol 178 SEAL_ID - an Identification value, randomly initialized and 179 monotonically incremented for each SEAL protocol packet 181 TE - Tunnel Endpoint (i.e., either ingress or egress) 183 VP - Virtual Prefix 185 3. IRON Routers 187 IRON introduces a new class of routers called IRON Routers (IRs) that 188 can be deployed on platforms ranging from high-end enterprise routers 189 to customer premises routers to simple commodity servers. Moreover, 190 IRs can be introduced incrementally and without affecting existing 191 infrastructure. The purpose of these new IRs is to provide waypoints 192 (or "cairns") for navigating the IRON so that packets with 193 destination addresses taken from End User Network PI prefixes (EPs) 194 can be delivered to the correct End User Networks (EUNs) through the 195 use of encapsulation with minimum path stretch for initial packets 196 and optimized routes for non-initial packets. The different 197 categories of IRs includes: 199 o IR - an IRON Router of any kind 201 o IR(VP) - a tunnel endpoint router that is owned by a VP company 202 and that aggregates VPs from which it sub-delegates more-specific 203 EPs to EUNs. 205 o IR(EP) - a tunnel endpoint router (or host with embedded gateway 206 function) that obtains an EP from a VP company, and that connects 207 an EUN to the IRON. An IR(EP) will typically be a customer 208 premises equipment (CPE) device that connects the EUN to its 209 ISP(s), but may also be a router or even a singleton host within 210 the EUN. 212 o IR(GW) - a router that acts as a gateway between the IRON and the 213 non-IRON Internet. Each VP company configures one or more IR(GWs) 214 which advertise the company's VPs into the IPv4 and/or IPv6 global 215 Internet DFZs. An IR(GW) may be configured on the same physical 216 platform as IR(VPs), or as a separate standalone platform. An 217 IR(GW) will typically be a BGP router that is capable of sourcing 218 encapsulated packets. 220 IRON observes the Internet Protocol standards [RFC0791][RFC2460]. 221 Other network layer protocols that can be encapsulated within IP 222 packets (e.g., OSI/CLNP [RFC1070], etc.) are also within scope. 224 4. The Internet Routing Overlay Network (IRON) 226 The Internet Routing Overlay Network (IRON) consists of IRON Routers 227 (IRs) that use Virtual Enterprise Traversal (VET) and the Subnetwork 228 Encapsulation and Adaptation Layer (SEAL) for the purpose of 229 forwarding encapsulated inner network layer packets over the IPv4 and 230 IPv6 Internets. Each such IR views the IPv4 and IPv6 global 231 Internets as monolithic virtual NBMA "links", and connects to the 232 links via a VET interface used for automatic tunneling. Each IR 233 therefore sees all other IRs as virtual single-hop neighbors on the 234 link from the standpoint of the inner network layer protocol, while 235 they may be separated by many physical outer IP hops. IRs are 236 deployed incrementally and without disturbing the existing Internet 237 routing system. 239 The IRON is manifested through a business model in which VP companies 240 own and manage a set of IR(VPs) that are dispersed throughout the 241 Internet and that serve a set of highly-aggregated VPs. Each VP 242 company sets up a service in which it leases EPs taken from the VPs 243 to customer EUNs. These EUNs may be located within the same network 244 as the VP company's IR(VP) routers, or they may be located elsewhere 245 within the Internet. The VP company acts as a virtual enterprise 246 network which EUNs loosely consider as their "home" network even 247 though they physically arrange for basic connectivity via one or more 248 ISP networks that may have no affiliation with the VP company. VP 249 companies can therefore open for business and begin serving their 250 customers immediately without the need to coordinate their activities 251 with ISPs or with other VP companies. 253 Each VP company also establishes a set of IR(GW) routers that connect 254 to the IPv4 and/or IPv6 Internet DFZs. The IR(GW) advertises all of 255 the VP company's IPv4 VPs into the IPv4 DFZ and advertises all of its 256 IPv6 VPs into the IPv6 DFZ. Each IR(GW) forwards any packets coming 257 from the DFZ to an IR(VP) that can encapsulate the packet and forward 258 it to the appropriate IR(EP). In this way, end systems that use PA 259 addresses can communicate with other end systems that use PI 260 addresses taken from an IRON VP. 262 EUNs establish at least one IR(EP) that connects the EUN to the IRON. 263 The IR(EP) uses encapsulation to forward packets with EP source 264 addresses to an IR(VP) belonging to its VP company as a default 265 router. The VP company's IR(VP) then forwards the packets toward 266 their final destination, and returns a SEAL Control Message Protocol 267 (SCMP) redirect message to inform the IR(EP) of a better next hop if 268 necessary. In this way, IR(EPs) experience reasonable path stretch 269 for initial packets and can discover route-optimized paths for 270 subsequent packets. 272 The IRON additionally requires a global mapping database to allow IRs 273 to map EPs/VPs to RLOCs assigned to the interfaces of other IRs. 274 Each VP in the IRON is therefore represented in a globally 275 distributed Master VP (MVP) mapping database. The MVP database is 276 maintained by a globally-managed assigned numbers authority in the 277 same manner as the Internet Assigned Numbers Authority (IANA) 278 currently maintains the master list of all top-level IPv4 and IPv6 279 delegations. The database can be replicated across multiple servers 280 for load balancing much in the same way that FTP mirror sites are 281 used to manage software distributions. Each VP in the MVP database 282 is encoded as the tuple: "{address family, prefix, prefix-length, 283 FQDN}", where: 285 o "address family" is one of IPv4, IPv6, OSI/CLNP, etc. 287 o "prefix" is the VP, e.g., 2001:DB8::/32 (IPv6), 192.2/16 (IPv4), 288 etc. 290 o "prefix-length" is the length (in bits) of the associated VP 292 o FQDN is a DNS Fully-Qualified Domain Name 294 For each VP entry in the MVP database, the VP company maintains a 295 FQDN in the DNS to map the VP to a list of IR(VP)s that serve it. 296 The FQDN is resolved by both other IR(VP)s and by IR(EP)s that hold 297 EP delegations from the VP into a list of resource records. Each 298 resource record corresponds to an individual IR(VP), and encodes the 299 tuple : "{address family, RLOC address, WGS 84 coordinates}" where 300 "address family" is the address family of the RLOC, "RLOC" is the 301 routing locator assigned to an IR(VP), and "WGS 84 coordinates" 302 identify the physical location of the IR(VP). Together, the MVP 303 database and the FQDNs in the global DNS provide sufficient mapping 304 capabilities to support navigation of the IRON. 306 5. IRON Initialization 308 IRON initialization entails the startup actions of VP company and EUN 309 equipment. The following sections discuss these startups procedures: 311 5.1. IR(VP) and IR(GW) Initialization 313 Upon startup, each IR(VP) and IR(GW) owned by the VP company 314 discovers the full set of VPs for the IRON by reading the MVP 315 database (see Section 4). These VPs may be IPv4 or IPv6, but they 316 may also be prefixes of other network layer protocols (e.g., OSI/CLNP 317 NSAP [RFC4548], etc.). Each IR(VP/GW) reads the MVP database from a 318 nearby server upon startup time, and periodically checks for deltas 319 on the server since the database was last read. Upon reading the MVP 320 database, the IR(VP/GW) resolves the FQDN corresponding to each VP 321 into an RLOC and a physical location. Each RLOC address is an IPv4 322 or IPv6 RLOC address assigned to the IR(VP) within the DFZ. 324 For each VP, the IR(VP/GW) sorts the list of RLOCs in order of 325 "geographic closeness", and inserts each "VP->RLOC" mapping into its 326 Forwarding Information Base (FIB) with a priority corresponding to 327 geographic closeness. Specifically, the FIB entries must be 328 configured such that packets with destination addresses covered by 329 the VP are forwarded to the corresponding RLOC using encapsulation of 330 the inner network layer packet in an outer IP header. Note that the 331 VP and RLOC may be of different address families; hence, possible 332 encapsulations include IPv6-in-IPv4, IPv4-in-IPv6, IPv6-in-IPv6, 333 IPv4-in-IPv4, OSI/CLNP-in-IPv6, OSI/CLNP-in-IPv4, etc. After each 334 IR(VP/GW) reads in the list of VPs and sorts the information 335 accordingly, it is said to be "synchronized with the IRON". Each 336 IR(VP) next installs all EPs derived from its VPs into its FIB based 337 on the mapping information received from each of its EUN customers. 339 5.2. IR(EP) Initialization 341 Upon startup, each IR(EP) must register its EP-to-RLOC binding with 342 the company that owns the corresponding VP, where the RLOC is an IPv4 343 or IPv6 address assigned to the IR(EP) by an ISP network. For 344 example, if an IR(EP) owns the EP 192.2.1/24 (IPv4) and the RLOC 345 assigned to the IR(EP) by the ISP is 2001:DB8::1 (IPv6), the IR(EP) 346 informs the VP company that the route 192.2.1/24 with 2001:DB8::1 as 347 the L2 address of the next-hop must be added to the FIB in each of 348 its IR(VPs) that aggregates the EP. The IR(EP) typically informs the 349 VP company by using an authenticated short transaction protocol 350 (e.g., http(s) with username/password) to register its EP-to-RLOC 351 mapping information. (The exact specification for the short 352 transaction is up to the VP company and need only be communicated to 353 the IR(EP); the IR(EP) also uses the same EP-to-RLOC registration 354 procedure to inform its VP company of a change in RLOC, e.g., due to 355 a mobility event, a change in its primary ISP, etc.). After the 356 IR(EP) registers its mapping information, the VP company then 357 propagates it to each of its IR(VPs) that aggregates the EP, e.g., 358 via a routing protocol that all of the VP company's IR(VP)s engage 359 in. 361 After the IR(EP) informs the VP company of its EP->RLOC mapping, it 362 resolves a FQDN for the VP company in order to discover the RLOC 363 addresses and geographic locations of the IR(VPs) owned by the 364 company. (This resolution closely resembles the ISATAP Potential 365 Router List (PRL) resolution procedure [RFC5214].) The IR(EP) then 366 selects the closest subset of these RLOC addresses (typically 2-4 367 routers chosen, e.g., based on geographic distance), and adds them to 368 a default router list of FIB entries that each points to a VET 369 interface with the RLOC as the L2 address of the next-hop. The 370 IR(EP) will then use these routes in the default router list as the 371 means for forwarding encapsulated packets with EID source addresses 372 toward the final destination via encapsulation. 374 6. IRON Operation 376 Following IRON initialization, IRs engage in the steady-state process 377 of receiving and forwarding packets. Except in instances when it 378 forwards an unencapsulated packet to the public Internet, the IR 379 encapsulates each forwarded packet using the mechanisms of VET 380 [I-D.templin-intarea-vet] and SEAL [I-D.templin-intarea-seal]. IRs 381 also use the SEAL Control Message Protocol (SCMP) to test liveness of 382 other IRs and to receive redirect messages informing them of a more 383 optimal route. Each IR operates as specified in the following 384 sections: 386 6.1. IR(EP) Operation 388 After an IR(EP) is initialized, it sends periodic beacons to at least 389 2-4 of its VP company's IR(VP)s which serve as default routers. Each 390 beacon is a SEAL Control Message Protocol (SCMP) Router Solicitation 391 (RS) message, and will elicit an SCMP Router Advertisement (RA) 392 message from the IR(VP). If the IR(EP) ceases to receive RA messages 393 from an IR(VP), it marks the IR(VP) as unreachable and selects a 394 different IR(VP). If the IR(EP) ceases to receive RA messages from 395 multiple IR(VPs), it marks the ISP connection as failed/failing and 396 uses an RLOC assigned by a different ISP to re-register its EP-to- 397 RLOC mapping. 399 When an end system in an EUN has a packet to send, the packet is 400 forwarded through the EUN until it reaches the IR(EP). The source 401 IR(EP) then forwards the packet either to an IR(VP) or to a 402 destination IR(EP). The source IR(EP) first checks its FIB for the 403 longest matching prefix. If the longest matching prefix is more- 404 specific than "default", the source IR(EP) forwards the packet to the 405 next-hop the same as for ordinary IP forwarding. If the longest 406 match is "default", however, the source IR(EP) forwards the packet to 407 one of the IR(VP)s serving as its default routers. 409 The source IR(EP) uses VET and SEAL to encapsulate each forwarded 410 packet in an outer IP header with the IP address of the next-hop IR 411 as the destination address. The source IR(EP) further uses SCMP to 412 test liveness and/or to accept redirect messages from the next-hop 413 IR. When the source IR(EP) receives an SCMP redirect, it checks the 414 SEAL_ID field of the encapsulated message to verify that the redirect 415 corresponds to a packet that it had previously sent to the neighbor 416 and accepts the redirect if there is a match. Thereafter, subsequent 417 packets forwarded by the source IR(EP) will follow a route-optimized 418 path. 420 An IR(EP) that accepts redirects may be redirected by an IR(VP) in 421 its home VP company network to one or more IR(VP)s in a "foreign" 422 network. In that case, the IR(EP) has no way of knowing if these 423 foreign IR(VP)s are reachable and able to process encapsulated 424 packets. In that case, the IR(EP) should select multiple foreign 425 IR(VPs) (e.g., 2-4) and send "live" packets to one of them while 426 sending corresponding "blank" packets to the others. In turn, each 427 foreign IR(VP) accepts and forwards "live" packets, but drops "blank" 428 packets after sending a redirect. In this way, even if the original 429 packet is lost due to congestion or a short-term outage, the IR(EP) 430 will receive a redirect from at least one of the foreign IR(VP)s. 432 6.2. IR(VP) Operation 434 After an IR(VP) is initialized, it sends RA responses to the periodic 435 RS beacons sent by IR(EPs) as described in Section 6.1. When the 436 IR(VP) receives an encapsulated packet from another IR, it examines 437 the inner destination address then forwards the packet as follows: 439 o If the inner destination address matches an EP in its FIB, the 440 IR(VP) 'A' re-encapsulates the packet using VET/SEAL and forwards 441 it to the next-hop IR(EP) 'B'. If the source IR 'C' is accepting 442 redirects, 'A' also sends an SCMP redirect message back to 'C'. 443 'C' will then send subsequent packets directly to 'B'. 445 o If the inner destination address does not match an EP but matches 446 a VP in its FIB, the IR(VP) 'A' re-encapsulates the packet using 447 VET/SEAL and forwards it to the next-hop IR(VP) 'B' . If the 448 source IR 'C' is accepting redirects, 'A' also sends an SCMP 449 redirect message back to 'C'. 'C' will then send subsequent 450 packets directly to 'B'. 452 o if the inner destination address does not match an EP or a VP in 453 the FIB, the IR(VP) decapsulates the packet and forwards it to the 454 public Internet via a default or more-specific route. 456 An IR(VP) that accepts redirects may need to forward initial packets 457 via the IR(VP)s of a "foreign" network. In that case, the IR(VP) can 458 send a "live" packet in parallel with corresponding "blanks" the same 459 as for an IR(EP). 461 6.3. IR(GW) Operation 463 Each VP company must establish one or more IR(GW) routers which 464 advertise the full set of the company's VP's into the IPv4 and/or 465 IPv6 Internet BGP. The VPs will be seen as ordinary routing 466 information in the BGP, and any packets originating from the non-IRON 467 IPv4 or IPv6 Internet will be forwarded into the VP company's network 468 by an IR(GW). When an IR(GW) receives a packet from the non-IRON 469 Internet but destined to an EP destination, it consults its FIB to 470 determine the best next-hop toward the final destination. The IR(GW) 471 then either forwards the packet to an IR(VP) within the home network 472 or acts as an IR(VP) itself to forward the packet further. 474 6.4. IRON Reference Operating Scenario 476 With respect to the previous sections, a path between two EUNs can 477 potentially involve both the two IR(EPs) and the IR(VP)s of the two 478 VP companies that serve the EUNs. Route optimization based on 479 redirection will allow shortcuts that eliminate the IR(VP)s from the 480 path. The following figure depicts the IRON reference operating 481 scenario for communications between two EUNs: 483 +------------+ +------------+ 484 | | | | 485 /======>+ IR(VP(A)) +======>+ IR(VP(B)) +======\ 486 // | | | | \\ 487 // +------------+ +------------+ \\ 488 // V 489 +-----+-----+ +-----+-----+ 490 | IR(EP(A)) | ........................................>| IR(EP(B)) | 491 +-----+-----+ +-----+-----+ 492 | | 493 ........ ........ 494 ( EUN A ) ( EUN B ) 495 ........ ........ 496 | | 497 +---+----+ +---+----+ 498 | Host A | | Host B | 499 +--------+ +--------+ 501 Figure 1: IRON Reference Operating Scenario 503 In this reference scenario, VP companies A and B have established 504 IR(VP)s within the Internet that serve EPs to EUNs. EUN A has 505 procured an EP from VP company A, while EUN B has procured an EP from 506 VP company B. The hosts in both EUNs have assigned addresses taken 507 from their corresponding EPs on their EUN-interior interfaces, and 508 the IR(EPs) have assigned RLOC addresses taken from their ISPs on 509 their WAN interfaces. 511 When Host A in EUN A has a packet to send to Host B in EUN B, normal 512 routing conveys the packet from Host A to IR(EP(A)). If IR(EP(A 513 ))does not have a more-specific route, it encapsulates the packet and 514 forwards it to an IR(VP) owned by VP company A. IR(VP(A )) 515 decapsulates the packet and checks its FIB for a route toward the 516 packet's destination address. If IR(VP(A)) does not have an EP route 517 to Host B in its FIB, it consults its full table of VP-to-RLOC 518 mappings to discover that the next-hop toward Host B is via 519 IR(VP(B)). IR(VP(A)) then re-encapsulates the packet and sends it to 520 IR(VP(B)) which has an EP route to Host B via IR(EP(B)). IR(VP(B)) 521 then re-encapsulates the packet and sends it to IR(EP(B)), which 522 decapsulates the packet and forwards it via EUN B to Host B. 524 In this process, when an IR(VP) re-encapsulates the packet and 525 forwards it to a next-hop IR, it also returns an SCMP redirect 526 message to the previous hop IR if the previous hop is willing to 527 accept redirects. The previous hop IR will then install a route in 528 its FIB that uses a more optimal next hop. For example, if IR(EP(A)) 529 is accepting redirects IR(VP(A)) will return a redirect message when 530 it forwards a packet to IR(VP(B)). IR(EP(A)) will then send 531 subsequent packets directly to IR(VP(B)), which will return a 532 redirect message when it forwards the packets to IR(EP(B)). Finally, 533 IR(EP(A)) will have an optimized route that lists IR(EP(B)) as the 534 next hop (shown as "....>" in the diagram). 536 Another redirection scenario arises when IR(VP(A)) is itself willing 537 to accept redirects. In that case, IR(EP(A)) may discover IR(EP(B)) 538 as a better next hop toward EUN A based solely on a redirect message 539 from IR(VP(A)) and without involving IR(VP(B)). Note however that 540 this may require IR(VP(A)) to carry thousands or even millions of EP 541 entries in its FIB for all EUNs that it has sent packets to recently, 542 which may negatively impact scalability. 544 6.5. Mobility, Multihoming and Traffic Engineering 546 While IR(VP)s can be considered as fixed infrastructure, IR(EP)s may 547 need to move between different network points of attachment, connect 548 to multiple ISPs, or explicitly manage their traffic flows. The 549 following sections discuss mobility, multihoming and traffic 550 engineering considerations for IR(EP)s: 552 6.5.1. Mobility Management 554 When an IR(EP) moves to a new topological location, it receives a new 555 RLOC address. The IR(EP) then registers the new EP-to-RLOC mapping 556 with its VP company the same as during its initialization phase as 557 described in Section 5.2. In this way, mobile networks are naturally 558 supported without the need for ancillary mechanisms. 560 Next, the IR(EP) sends Neighbor Advertisement (NA) messages to each 561 neighboring IR from which it has received packets recently. The NA 562 message includes the new RLOC as the outer source address and 563 includes the previous RLOC within an NA option field. The 564 neighboring IR will update its neighbor cache so that subsequent 565 packets will flow through the new RLOC. 567 6.5.2. Multihoming 569 An IR(EP) registers only the RLOC of its primary ISP with its VP 570 company even if it connects to multiple ISPs. If the IR(EP) later 571 needs to select a different ISP as its primary, it simply repeats the 572 EP-to-RLOC registration process the same as if it were reacting to a 573 mobility event as described above. 575 6.5.3. Inbound Traffic Engineering 577 When an IR(EP) receives packets via its primary ISP (i.e., the ISP 578 for which it is currently registered with the VP company), it may 579 wish to balance the load of incoming traffic between multiple ISP 580 connection points. In that case, the IR(EP) may send NA messages to 581 certain neighboring IRs the same as in the case of a mobility event 582 as described in Section 6.5.1. In that way, the IR(EP) can manage 583 its incoming traffic flows for best utilization of its multiple ISPs. 585 6.5.4. Outbound Traffic Engineering 587 IR(EP)s maintain a list of IR(VP)s that serve as default routers for 588 VET interface encapsulation of inner packets with source addresses 589 taken from an EP prefix. IR(EP)s also maintain a list of neighbors 590 on underlying interfaces that serve as default routers for packets 591 with non-EP source addresses. If the inner and outer protocols are 592 of different versions (e.g., OSI/CLNP as the inner version and IPv4 593 as the outer version) then the default routes of both versions are 594 mutually exclusive and no special arrangements are needed. 596 If the inner and outer protocol versions are the same, however (e.g., 597 IPv6 as both the inner and outer protocol) then a special treatment 598 of the default route is necessary. In particular, the IR(EP) must 599 examine the source address of a packet to be forwarded to determine 600 the proper handling of "default". If the packet uses a source 601 address taken from an EP prefix, the IR(EP) forwards it to an IR(VP) 602 using encapsulation via a VET interface; otherwise, the IR(EP) 603 forwards the packet to a next hop on an underlying link. 605 Using this arrangement of default, when an IR(EP) forwards a packet 606 with an EP source address it can forward it to any of its associated 607 IR(VP)s using VET interface encapsulation over any of its underlying 608 interfaces. The choice of underlying interface can be managed, and 609 the source address assigned to the underlying interface will be used 610 as the outer source address of the encapsulated packet. Each 611 encapsulated packet can therefore be directed through the desired ISP 612 using a topologically-correct outer source address. 614 7. Related Initiatives 616 IRON builds upon the concepts RANGER architecture [RFC5720], and 617 therefore inherits the same set of related initiatives. 619 Virtual Aggregation (VA) [I-D.ietf-grow-va] and Aggregation in 620 Increasing Scopes (AIS) [I-D.zhang-evolution] provide the basis for 621 the Virtual Prefix concepts. 623 Internet vastly improved plumbing (Ivip) [I-D.whittle-ivip-arch] has 624 contributed valuable insights, including the use of real-time 625 mapping. 627 8. IANA Considerations 629 The IANA is instructed to create a Master Virtual Prefix (MVP) 630 registry for IRON. 632 9. Security Considerations 634 Security considerations for RANGER apply also to IRON. 636 10. Acknowledgements 638 This ideas behind this work have benefited greatly from discussions 639 with colleagues; some of which appear on the RRG and other IRTF/IETF 640 mailing lists. 642 11. References 644 11.1. Normative References 646 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 647 September 1981. 649 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 650 (IPv6) Specification", RFC 2460, December 1998. 652 11.2. Informative References 654 [I-D.ietf-grow-va] 655 Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and 656 L. Zhang, "FIB Suppression with Virtual Aggregation", 657 draft-ietf-grow-va-02 (work in progress), March 2010. 659 [I-D.russert-rangers] 660 Russert, S., Fleischman, E., and F. Templin, "Operational 661 Scenarios for IRON and RANGER", draft-russert-rangers-03 662 (work in progress), June 2010. 664 [I-D.templin-intarea-seal] 665 Templin, F., "The Subnetwork Encapsulation and Adaptation 666 Layer (SEAL)", draft-templin-intarea-seal-15 (work in 667 progress), June 2010. 669 [I-D.templin-intarea-vet] 670 Templin, F., "Virtual Enterprise Traversal (VET)", 671 draft-templin-intarea-vet-15 (work in progress), 672 June 2010. 674 [I-D.whittle-ivip-arch] 675 Whittle, R., "Ivip (Internet Vastly Improved Plumbing) 676 Architecture", draft-whittle-ivip-arch-04 (work in 677 progress), March 2010. 679 [I-D.zhang-evolution] 680 Zhang, B. and L. Zhang, "Evolution Towards Global Routing 681 Scalability", draft-zhang-evolution-02 (work in progress), 682 October 2009. 684 [RFC1070] Hagens, R., Hall, N., and M. Rose, "Use of the Internet as 685 a subnetwork for experimentation with the OSI network 686 layer", RFC 1070, February 1989. 688 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 689 Protocol 4 (BGP-4)", RFC 4271, January 2006. 691 [RFC4548] Gray, E., Rutemiller, J., and G. Swallow, "Internet Code 692 Point (ICP) Assignments for NSAP Addresses", RFC 4548, 693 May 2006. 695 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 696 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 697 March 2008. 699 [RFC5720] Templin, F., "Routing and Addressing in Networks with 700 Global Enterprise Recursion (RANGER)", RFC 5720, 701 February 2010. 703 [RFC5743] Falk, A., "Definition of an Internet Research Task Force 704 (IRTF) Document Stream", RFC 5743, December 2009. 706 Author's Address 708 Fred L. Templin (editor) 709 Boeing Research & Technology 710 P.O. Box 3707 MC 7L-49 711 Seattle, WA 98124 712 USA 714 Email: fltemplin@acm.org