idnits 2.17.1 draft-templin-iron-06.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 23, 2010) is 5046 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 (-04) exists of draft-ietf-v6ops-tunnel-security-concerns-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 (~~), 6 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 23, 2010 5 Intended status: Informational 6 Expires: December 25, 2010 8 The Internet Routing Overlay Network (IRON) 9 draft-templin-iron-06.txt 11 Abstract 13 Since the Internet must continue to support escalating growth due to 14 increasing demand, it is clear that current routing architectures and 15 operational practices must be updated. This document proposes an 16 Internet Routing Overlay Network for supporting sustainable growth 17 through Provider Independent addressing while requiring no changes to 18 end systems and no changes to the existing routing system. This 19 document is a product of the IRTF Routing Research Group (RRG). 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on December 25, 2010. 38 Copyright Notice 40 Copyright (c) 2010 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. The Internet Routing Overlay Network (IRON) . . . . . . . . . 5 58 3.1. IR(EP)s - IRON Routers That Connect End User Networks 59 to the IRON . . . . . . . . . . . . . . . . . . . . . . . 6 60 3.2. IR(VP)s - IRON Routers That Serve Virtual Prefixes . . . . 7 61 3.3. IR(GW)s - IRON Routers that Connect VPC Networks to 62 the Internet . . . . . . . . . . . . . . . . . . . . . . . 8 63 4. IRON Organizational Principles . . . . . . . . . . . . . . . . 9 64 5. IRON Initialization . . . . . . . . . . . . . . . . . . . . . 10 65 5.1. IR(VP) and IR(GW) Initialization . . . . . . . . . . . . . 10 66 5.2. IR(EP) Initialization . . . . . . . . . . . . . . . . . . 11 67 6. IRON Operation . . . . . . . . . . . . . . . . . . . . . . . . 12 68 6.1. IR(EP) Operation . . . . . . . . . . . . . . . . . . . . . 12 69 6.2. IR(VP) Operation . . . . . . . . . . . . . . . . . . . . . 13 70 6.3. IR(GW) Operation . . . . . . . . . . . . . . . . . . . . . 14 71 6.4. IRON Reference Operating Scenarios . . . . . . . . . . . . 14 72 6.4.1. Two Hosts in Different IRON EUNs . . . . . . . . . . . 14 73 6.4.2. Mixed IRON and Non-IRON Hosts . . . . . . . . . . . . 16 74 6.5. Mobility, Multihoming and Traffic Engineering 75 Considerations . . . . . . . . . . . . . . . . . . . . . . 18 76 6.5.1. Mobility Management . . . . . . . . . . . . . . . . . 18 77 6.5.2. Multihoming . . . . . . . . . . . . . . . . . . . . . 18 78 6.5.3. Inbound Traffic Engineering . . . . . . . . . . . . . 18 79 6.5.4. Outbound Traffic Engineering . . . . . . . . . . . . . 18 80 6.6. Renumbering Considerations . . . . . . . . . . . . . . . . 19 81 6.7. NAT Traversal Considerations . . . . . . . . . . . . . . . 19 82 7. Open Research Areas . . . . . . . . . . . . . . . . . . . . . 20 83 8. Related Initiatives . . . . . . . . . . . . . . . . . . . . . 20 84 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 85 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 86 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 87 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 88 12.1. Normative References . . . . . . . . . . . . . . . . . . . 21 89 12.2. Informative References . . . . . . . . . . . . . . . . . . 22 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 92 1. Introduction 94 Growth in the number of entries carried in the Internet routing 95 system has led to concerns for unsustainable routing scaling 96 [I-D.narten-radir-problem-statement]. Operational practices such as 97 increased use of multihoming with IPv4 Provider-Independent (PI) 98 addressing are resulting in more and more fine-grained prefixes 99 injected into the routing system from more and more end user 100 networks. Furthermore, the forthcoming depletion of the public IPv4 101 address space has raised concerns for both increased deaggregation 102 (leading to yet further routing table entries) and an impending 103 address space run-out scenario. At the same time, the IPv6 routing 104 system is beginning to see growth in IPv6 Provider-Aggregated (PA) 105 prefixes [BGPMON] which must be managed in order to avoid the same 106 routing scaling issues the IPv4 Internet now faces. Since the 107 Internet must continue to scale to accommodate increasing demand, it 108 is clear that new routing methodologies and operational practices are 109 needed. 111 Several related works have investigated routing scaling issues and 112 proposed solutions. Virtual Aggregation (VA) [I-D.ietf-grow-va] and 113 Aggregation in Increasing Scopes (AIS) [I-D.zhang-evolution] are 114 global routing proposals that introduce routing overlays with Virtual 115 Prefixes (VPs) to reduce the number of entries required in each 116 router's Forwarding Information Base (FIB) and Routing Information 117 Base (RIB). Routing and Addressing in Networks with Global 118 Enterprise Recursion (RANGER) [RFC5720] examines recursive 119 arrangements of enterprise networks that can apply to a very broad 120 set of use case scenarios [I-D.russert-rangers]. In particular, 121 RANGER supports encapsulation and secure redirection by treating each 122 layer in the recursive hierarchy as a virtual non-broadcast, multiple 123 access (NBMA) "link". RANGER is an architectural framework that 124 includes Virtual Enterprise Traversal (VET) [I-D.templin-intarea-vet] 125 and the Subnetwork Adaptation and Encapsulation Layer (SEAL) 126 (including the SEAL Control Message Protocol (SCMP)) 127 [I-D.templin-intarea-seal] as its functional building blocks. 129 This document proposes an Internet Routing Overlay Network (IRON) 130 with goals of supporting sustainable growth while requiring no 131 changes to the existing routing system. IRON borrows concepts from 132 VA, AIS and RANGER, and further borrows concepts from the Internet 133 Vastly Improved Plumbing (Ivip) [I-D.whittle-ivip-arch] architecture 134 proposal. IRON specifically seeks to provide scalable PI addressing 135 without changing the current BGP [RFC4271] routing system. IRON 136 observes the Internet Protocol standards [RFC0791][RFC2460]. Other 137 network layer protocols that can be encapsulated within IP packets 138 (e.g., OSI/CLNP [RFC1070], etc.) are also within scope. 140 The IRON is a global overlay network routing system comprising 141 Virtual Prefix Companies (VPCs) that own and manage Virtual Prefixes 142 (VPs) from which End User Network (EUN) PI prefixes (EPs) are 143 delegated to customer sites. The IRON is motivated by a growing 144 customer demand for multihoming, mobility management and traffic 145 engineering while using stable PI addressing to avoid network 146 renumbering [RFC4192][RFC5887]. The IRON uses the existing IPv4 and 147 IPv6 global Internet routing systems as virtual links for tunneling 148 inner network protocol packets within outer IPv4 or IPv6 headers 149 (see: Section 3). The IRON requires deployment of a small number of 150 new routers that are simple commodity hardware platforms. No 151 modifications to hosts, and no modifications to most routers are 152 required. 154 Note: This document is offered in compliance with Internet Research 155 Task Force (IRTF) document stream procedures [RFC5743]; it is not an 156 IETF product and is not a standard. The views in this document were 157 considered controversial by the IRTF Routing Research Group (RRG) but 158 the RG reached a consensus that the document should still be 159 published. The document will undergo a period of review within the 160 RRG and through selected expert reviewers prior to publication. The 161 following sections discuss details of the IRON architecture. 163 2. Terminology 165 This document makes use of the following terms: 167 End User Network (EUN) 168 an edge network that connects an organization's devices (e.g., 169 computers, routers, printers, etc.) to the Internet and possibly 170 also the IRON. 172 Internet Service Provider (ISP) 173 a service provider which physically connects customer EUNs to the 174 Internet. 176 Provider Assigned (PA) prefix 177 a network layer address prefix delegated to an EUN by a service 178 provider. 180 Provider Independent (PI) prefix 181 a network layer address prefix delegated to an EUN by a third 182 party independently of the EUN's ISP arrangements. 184 Virtual Prefix (VP) 185 a highly-aggregated PI prefix block (e.g., an IPv4 /16, an IPv6 186 /20, etc.) that is owned and managed by a Virtual Prefix Company 187 (VPC). 189 Virtual Prefix Company (VPC) 190 a company that owns and manages one or several VPs from which it 191 delegates End User Network PI Prefixes (EPs) to EUNs 193 Master Virtual Prefix database (MVPd) 194 a distributed database that maintains VP-to-locator mappings for 195 all VPs in the IRON. 197 End User Network PI prefix (EP) 198 a more-specific PI prefix derived from a VP (e.g., an IPv4 /28, an 199 IPv6 /56, etc.) and delegated to an EUN by a VPC. 201 EP Address (EPA) 202 a network layer address taken from an EP address range and 203 assigned to the interface of an end system in an EUN. EPAs are 204 routable only within EUNs. 206 locator 207 an IP address taken from a non-EP address range and assigned to 208 the interface of a router or end system within a public or private 209 network. Locators taken from public IP address spaces are 210 routable within the global Internet while locators taken from 211 private IP address spaces are routable only within the network 212 where the private IP addressing plan is deployed. 214 Internet Routing Overlay Network (IRON) 215 an overlay network configured over the global Internet. The IRON 216 supports routing through encapsulation of inner packets with EPA 217 addresses within outer headers that use locator addresses. 219 3. The Internet Routing Overlay Network (IRON) 221 The Internet Routing Overlay Network (IRON) consists of IRON Routers 222 (IRs) that use Virtual Enterprise Traversal (VET) and the Subnetwork 223 Encapsulation and Adaptation Layer (SEAL) to encapsulate inner 224 network layer packets within outer IP headers (see: Figure 1) for 225 transmission over the global Internet. Each such IR connects to the 226 IRON via a VET tunnel virtual interface used for automatic tunneling. 227 Each IR therefore sees all other IRs as virtual single-hop neighbors 228 on the link from the standpoint of the inner network layer protocol, 229 while they may be separated by many physical outer IP hops. 231 +-------------------------+ 232 | Outer Packet Header | 233 ~ with locator addresses ~ 234 | (IPv4 or IPv6) | 235 +-------------------------+ +-------------------------+ 236 | Inner Packet Header | --> | Inner Packet Header | 237 ~ with EP addresses ~ --> ~ with EP addresses ~ 238 | (IPv4, IPv6, OSI, etc.) | --> | (IPv4, IPv6, OSI, etc.) | 239 +-------------------------+ +-------------------------+ 240 | | --> | | 241 ~ Inner Packet Body ~ --> ~ Inner Packet Body ~ 242 | | --> | | 243 +-------------------------+ +-------------------------+ 245 Inner packet before Outer packet after 246 before encapsulation after encapsulation 248 Figure 1: Encapsulation of Inner Packets Within Outer IP Headers 250 The IRON is manifested through a business model in which Virtual 251 Prefix Companies (VPCs) own and manage a set of IRs that are 252 distributed throughout the Internet and serve highly-aggregated 253 Virtual Prefixes (VPs). VPCs delegate sub-prefixes from their VPs 254 which they lease to customers as End User Network PI prefixes (EPs). 255 The customers in turn assign the EPs to their customer premises IRs 256 which connect their End User Networks (EUNs) to the IRON. VPCs may 257 have no affiliation with the ISP networks from which customers obtain 258 their basic connectivity. Therefore, VPCs can open for business and 259 begin serving their customers immediately without the need to 260 coordinate their activities with ISPs or with other VPCs. 262 The IRON requires no changes to end systems and no changes to most 263 routers in the Internet. Instead, the IRON comprises IRs that are 264 deployed either as new platforms or as modifications to existing 265 platforms. IRs may be deployed incrementally without disturbing the 266 existing Internet routing system, and act as waypoints (or "cairns") 267 for navigating the IRON. The functional roles of IRs are described 268 in the following sections. 270 3.1. IR(EP)s - IRON Routers That Connect End User Networks to the IRON 272 An "IR(EP)" is a tunnel endpoint router (or host with embedded 273 gateway function) that logically connects its EUNs to the IRON via 274 tunnels. IR(EP)s obtain EPs from VPCs and use them to number subnets 275 and interfaces within their EUNs. An IR(EP) can be deployed as a 276 Customer Premises Equipment (CPE) router that also physically 277 connects its EUNs to its ISPs, but it may also be a router or even a 278 singleton end system within the EUN when the CPE is a legacy router. 280 (This model applies even if the CPE router is a Network Address 281 Translator (NAT) - see Section 6.7). An IR(EP) connects its EUNs to 282 the IRON via tunnels as shown in Figure 2: 283 .-. 284 ,-( _)-. 285 +--------+ .-(_ (_ )-. 286 | IR(EP) |--(_ ISP ) 287 +---+----+ `-(______)-' 288 | <= T \ .-. 289 .-. u \ ,-( _)-. 290 ,-( _)-. n .-(_ (- )-. 291 .-(_ (_ )-. n (_ Internet ) 292 (_ EUN ) e `-(______)- 293 `-(______)-' l ___ 294 | s => (:::)-. 295 +----+---+ .-(::::::::) 296 | Host | .-(::::::::::::)-. 297 +--------+ (:::: The IRON ::::) 298 `-(::::::::::::)-' 299 `-(::::::)-' 301 Figure 2: IR(EP) Connecting EUN to the IRON 303 3.2. IR(VP)s - IRON Routers That Serve Virtual Prefixes 305 An "IR(VP)" is a tunnel endpoint router that is managed by a VPC and 306 that services one or more VPs from which it delegates EPs to 307 customers. In typical deployments, a VPC will deploy several IR(VP)s 308 (e.g., 10-20) for each VP. These IR(VP)s maintain a distributed 309 database of EP-to-customer mappings that allow correspondents to 310 navigate the IRON. 312 IR(VP)s connect to the IRON in a globally-distributed fashion as 313 shown in Figure 3 so that mapping service clients can discover a 314 server that is nearby. IR(VP)s typically forward only initial 315 packets while redirecting traffic flows, and often will require only 316 a single physical network interface. Hence, IR(VP)s may be deployed 317 on a variety of hardware platforms ranging from traditional high-end 318 routers to commodity general-purpose processors. 320 +--------+ +--------+ 321 | IR(VP) | | IR(VP) | 322 | Boston | | Tokyo | 323 +--------+ +--------+ 324 +--------+ 325 | IR(VP) | ___ 326 | Seattle| (:::)-. +--------+ 327 +--------+ .-(::::::::) | IR(VP) | 328 .-(::::::::::::)-. | Paris | 329 (:::: The IRON ::::) +--------+ 330 `-(::::::::::::)-' 331 +--------+ `-(::::::)-' +--------+ 332 | IR(VP) | | IR(VP) | 333 | Moscow | +--------+ | Sydney | 334 +--------+ | IR(VP) | +--------+ 335 | Cairo | 336 +--------+ 338 Figure 3: IR(VP) Global Distribution Example 340 3.3. IR(GW)s - IRON Routers that Connect VPC Networks to the Internet 342 An "IR(GW)" is a tunnel endpoint router that is managed by a VPC and 343 that acts as a gateway between the VPC's IR(VP)s and the non-IRON 344 Internet (i.e., the portion of the Internet used for routing of 345 prefixes that are not derived from VPs). Each VPC configures one or 346 more IR(GW)s which advertise the company's VPs into the IPv4 and/or 347 IPv6 global Internet BGP routing systems. An IR(GW) may be 348 configured on the same physical platform as an IR(VP), or as a 349 separate standalone platform. An IR(GW) will typically be a BGP 350 router that is capable of exchanging both encapsulated packets over 351 the IRON and unencapsulated packets over the native Internet. The 352 role of an IR(GW) is depicted in Figure 4: 354 ,-( _)-. 355 .-(_ (_ )-. 356 (_ Internet ) 357 `-(______)-' 358 | 359 +----+---+ 360 | IR(GW) | 361 +----+---+ 362 _|_ 363 (:::)-. 364 .-(::::::::) 365 +--------+ .-(::::::::::::)-. +--------+ 366 | IR(VP) | (:::: The IRON ::::) | IR(VP) | 367 +--------+ `-(::::::::::::)-' +--------+ 368 `-(::::::)-' 370 +--------+ 371 | IR(VP) | 372 +--------+ 374 Figure 4: IR(GW) Connecting VPC to Native Internet 376 4. IRON Organizational Principles 378 Each VPC in the IRON manages a set of IR(VP)s that service one or 379 more VPs from which EPs are delegated to IR(EP)s. The set of IR(VP)s 380 that service the same VP forms a logical subnetwork for the VP. Each 381 IR(VP) in the logical subnetwork exchanges routing/mapping 382 information via a dynamic routing protocol instance in order to 383 maintain synchronized Forwarding Information Bases (FIBs). 385 The VP company also maintains a set of IR(GW)s that connect the 386 logical subnetworks to the IPv4 and/or IPv6 Internets. Each IR(GW) 387 advertises the VPC's IPv4 VPs into the IPv4 BGP routing system and 388 advertises the VPC's IPv6 VPs into the IPv6 BGP routing system. 389 IR(GW)s forward packets coming from the Internet and destined to an 390 EPA address into the IRON. In the reverse direction, IR(GW)s forward 391 packets coming from the IRON and destined to a locator address into 392 the Internet. In this way, end systems that use locator addresses 393 can communicate with other end systems that use EPA addresses. 395 EUNs establish at least one IR(EP) to connect the EUN to the IRON. 396 The IR(EP) uses encapsulation to forward packets with EP addresses to 397 an IR(VP) belonging to its VP subnetwork as a default router. The 398 IR(VP) then forwards the packets toward their final destination, and 399 returns a SEAL Control Message Protocol (SCMP) redirect message to 400 inform the IR(EP) of a better next hop if necessary. 402 The IRON additionally requires a global mapping database to allow IRs 403 to map VPs to locators which are assigned to the interfaces of other 404 IRs. Each VP in the IRON is therefore represented in a globally 405 distributed Master VP database (MVPd). The MVPd is maintained by a 406 globally-managed assigned numbers authority in the same manner as the 407 Internet Assigned Numbers Authority (IANA) currently maintains the 408 master list of all top-level IPv4 and IPv6 delegations. The database 409 can be replicated across multiple servers for load balancing much in 410 the same way that FTP mirror sites are used to manage software 411 distributions. Each VP in the MVPd is encoded as the tuple: 412 "{address family, prefix, prefix-length, FQDN}", where: 414 o "address family" is one of IPv4, IPv6, OSI/CLNP, etc. 416 o "prefix" is the VP, e.g. - 2001:DB8::/32 (IPv6) [RFC3849], 417 192.2/16 (IPv4) [RFC5737], etc. 419 o "prefix-length" is the length (in bits) of the associated VP 421 o FQDN is a DNS Fully-Qualified Domain Name 423 For each VP entry in the MVPd, the VPC maintains a FQDN in the DNS to 424 map the VP to a list of IR(VP)s that serve it. IR(VP)s in other VPC 425 networks and IR(EP)s that hold EP delegations from the VP discover 426 the mappings by resolving the FQDN into a list of resource records. 427 Each resource record corresponds to an individual IR(VP), and encodes 428 the tuple : "{address family, locator, WGS 84 coordinates}" where 429 "address family" is the address family of the locator, "locator" is 430 the routing locator assigned to an IR(VP) interface, and "WGS 84 431 coordinates" identify the physical location of the IR(VP). Together, 432 the MVPd and the FQDNs in the global DNS provide sufficient mapping 433 capabilities to support navigation of the IRON. 435 5. IRON Initialization 437 IRON initialization entails the startup actions of VPC and EUN 438 equipment. The following sections discuss these startups procedures. 440 5.1. IR(VP) and IR(GW) Initialization 442 Upon startup, each IR(VP) and IR(GW) managed by the VPC discovers the 443 full set of VPs for the IRON by reading the MVPd (see Section 4). 444 These VPs may be IPv4 or IPv6, but they may also be prefixes of other 445 network layer protocols (e.g., OSI/CLNP NSAP [RFC4548], etc.). Each 446 IR(VP) and IR(GW) reads the MVPd from a nearby server upon startup 447 time, and periodically checks the server for deltas since the 448 database was last read. Upon reading the MVPd, each IR(VP) and 449 IR(GW) resolves the FQDN corresponding to each VP into a list of 450 locators. Each locator is a routable IPv4 or IPv6 address assigned 451 to an interface of an IR(VP) that serves the VP. 453 For each VP, each IR(VP) and IR(GW) sorts the list of locators to 454 determine a priority ranking (e.g., based on distance from the 455 locator) and inserts each "VP->locator" mapping into its FIB in order 456 of priority. The FIB entries must be configured such that packets 457 with destination addresses covered by the VP are forwarded to the 458 corresponding locator using encapsulation of the inner network layer 459 packet in an outer IP header. This is accomplished by configuring 460 the routing table entry to use the locator addresses as the L2 461 address corresponding to an imaginary L3 next-hop address. 463 Note that the VP and locator may be of different address families; 464 hence, possible encapsulations include IPv6-in-IPv4, IPv4-in-IPv6, 465 IPv6-in-IPv6, IPv4-in-IPv4, OSI/CLNP-in-IPv6, OSI/CLNP-in-IPv4, etc. 466 After each IR(VP) and IR(GW) reads in the list of VPs and sorts the 467 information accordingly, it is said to be "synchronized with the 468 IRON". Each IR(VP) next installs all EPs derived from its VPs into 469 its FIB based on the mapping information received from each of its 470 EUN customers. 472 5.2. IR(EP) Initialization 474 Before its first operational use, each IR(EP) must obtain one or more 475 EPs from a VPC along with a FQDN that can be resolved into a list of 476 locators for the IR(VP)s that service the EPs. The IR(EP) must also 477 obtain a certificate and a public/private key pair from the VPC that 478 it can later use to prove ownership of its EPs. This implies that 479 the VPC must run its own key infrastructure to be used only for the 480 purpose of verifying a customer's claimed right to use an EP. Hence, 481 the VPC need not coordinate its key infrastructure with any other 482 organizations. 484 Upon startup, each IR(EP) resolves a FQDN for the VP in order to 485 discover the locators of the company's IR(VPs). (This resolution 486 closely resembles the ISATAP Potential Router List (PRL) resolution 487 procedure [RFC5214].) The IR(EP) then selects the closest subset of 488 these locators (typically 2-4 routers chosen, e.g., based on 489 topological distance) and adds them to a default router list of FIB 490 entries that each points to a VET interface with the locator as the 491 L2 address of the next-hop. The IR(EP) will then use the default 492 router list for forwarding inner packets with EPA source addresses 493 toward the final destination via encapsulation. 495 6. IRON Operation 497 Following IRON initialization, IRs engage in the steady-state process 498 of receiving and forwarding packets. All IRs forward encapsulated 499 packets over the IRON using the mechanisms of VET 500 [I-D.templin-intarea-vet] and SEAL [I-D.templin-intarea-seal], while 501 IR(GW)s additionally forward unencapsulated packets to and from the 502 native IPv6 and IPv4 Internets. IRs also use the SEAL Control 503 Message Protocol (SCMP) to test liveness of other IRs and to receive 504 redirect messages informing them of better routes. Each IR operates 505 as specified in the following sub-sections. 507 6.1. IR(EP) Operation 509 After an IR(EP) is initialized, it must register its EP-to-locator 510 binding with the IR(VP)s that it has selected as default routers by 511 sending periodic beacons with signed certificates and prefix 512 information to prove ownership of its EPs. Each beacon is a SEAL 513 Control Message Protocol (SCMP) Router Solicitation (SRS) message, 514 and will elicit an SCMP Router Advertisement (SRA) message from the 515 IR(VP). If the IR(EP) ceases to receive SRA messages from an IR(VP), 516 it marks the IR(VP) as unreachable and selects a different IR(VP). 517 If the IR(EP) ceases to receive SRA messages from multiple IR(VP)s, 518 it marks the ISP connection as failed/failing and sends its SRS 519 beacons through a different ISP. The IR(EP) also uses the same SRS/ 520 SRA beaconing procedure to inform its IR(VP)s of a change in locator, 521 e.g., due to a mobility event, a change in its primary ISP, etc. 523 When an end system in an EUN has a packet to send, the packet is 524 forwarded through the EUN until it reaches an IR(EP). This source 525 IR(EP) then forwards the packet either to an IR(VP) or to a 526 destination IR(EP). The source IR(EP) first checks its FIB for the 527 longest matching prefix. If the longest matching prefix is more- 528 specific than "default", the source IR(EP) forwards the packet to the 529 next-hop the same as for ordinary IP forwarding. If the longest 530 match is "default", however, the source IR(EP) forwards the packet to 531 one of the IR(VP)s serving as its default routers. 533 The source IR(EP) uses VET and SEAL to encapsulate each forwarded 534 packet in an outer IP header with the IP address of the next-hop IR 535 as the destination address. The source IR(EP) further uses SCMP to 536 test liveness and/or to accept redirect messages from the next-hop 537 IR. When the source IR(EP) receives an SCMP redirect, it checks the 538 identification field of the encapsulated message to verify that the 539 redirect corresponds to a packet that it had previously sent to the 540 neighbor and accepts the redirect if there is a match. Thereafter, 541 subsequent packets forwarded by the source IR(EP) will follow a 542 route-optimized path. 544 An IR(EP) that accepts redirects may be redirected by an IR(VP) in 545 its home VPC network to one or more IR(VP)s in a "foreign" network. 546 In that case, the IR(EP) has no way of knowing if these foreign 547 IR(VP)s are reachable and able to process encapsulated packets. In 548 that case, the IR(EP) should select multiple foreign IR(VPs) (e.g., 549 2-4) and send "live" packets to one of them while sending 550 corresponding "blank" packets to the others. In turn, each foreign 551 IR(VP) accepts and forwards "live" packets, but drops "blank" packets 552 after sending a redirect. In this way, even if the original packet 553 is lost due to congestion or a short-term outage, the IR(EP) will 554 receive a redirect from at least one of the foreign IR(VP)s. 556 6.2. IR(VP) Operation 558 After an IR(VP) is initialized, it responds to SRSs by sending SRAs 559 as described in Section 6.1. The IR(VP) then propagates the mapping 560 information conveyed in the SRS message to each of its peer IR(VP)s 561 within the logical subnetwork, e.g., via a dynamic routing protocol 562 instance that all of the VP company's IR(VP)s engage in. 564 When the IR(VP) receives an encapsulated packet from another IR, it 565 examines the inner destination address then forwards the packet as 566 follows: 568 o If the inner destination address matches an EP in its FIB, the 569 IR(VP) 'A' re-encapsulates the packet using VET/SEAL and forwards 570 it to the next-hop IR(EP) 'B'. If the source IR 'C' is accepting 571 redirects, 'A' also sends an SCMP redirect message back to 'C'. 572 'C' will then send subsequent packets directly to 'B'. 574 o If the inner destination address does not match an EP but matches 575 a VP in its FIB, the IR(VP) 'A' re-encapsulates the packet using 576 VET/SEAL and forwards it to the next-hop IR(VP) 'B' . If the 577 source IR 'C' is accepting redirects, 'A' also sends an SCMP 578 redirect message back to 'C'. 'C' will then send subsequent 579 packets directly to 'B'. 581 o If the inner destination address does not match an EP or a VP in 582 the FIB, the IR(VP) forwards the packet to the public Internet 583 either directly or via an IR(GW). 585 An IR(VP) that accepts redirects may need to forward initial packets 586 via the IR(VP)s of a "foreign" network. In that case, the IR(VP) can 587 send a "live" packet in parallel with corresponding "blanks" the same 588 as for an IR(EP). 590 6.3. IR(GW) Operation 592 Each VPC must establish one or more IR(GW) routers which advertise 593 the full set of the company's VP's into the IPv4 and/or IPv6 Internet 594 BGP routing systems. The VPs will be seen as ordinary routing 595 information in the BGP, and any packets originating from the non-IRON 596 IPv4 or IPv6 Internet toward a VP will be forwarded into the VPC's 597 network by an IR(GW). When an IR(GW) receives a packet from the non- 598 IRON Internet but destined to an EP destination, it consults its FIB 599 to determine the best next-hop toward the final destination. The 600 IR(GW) then either forwards the packet to an IR(VP) within the home 601 network or acts as an IR(VP) itself to forward the packet further. 603 6.4. IRON Reference Operating Scenarios 605 The two major reference operating scenarios that may arise for IRON 606 are 1) when both hosts are within separate IRON EUNs, and 2) when one 607 host is within an IRON EUN and the other is within a non-IRON EUN. 608 The following two sections discuss these reference operating 609 scenarios. 611 6.4.1. Two Hosts in Different IRON EUNs 613 The initial path when both hosts are within separate IRON EUNs 614 involves both the two IR(EPs) and the IR(VP)s of the two VP companies 615 that serve the EUNs. Route optimization based on redirection will 616 allow shortcuts that eliminate the IR(VP)s from the path. Figure 5 617 depicts the IRON reference operating scenario for communications 618 between hosts within two separate IRON EUNs: 620 ________________________________________ 621 .-( )-. 622 .-( +------------+ +------------+ )-. 623 .-( | | | | )-. 624 .( +======>+ IR(VP(A)) +======>+ IR(VP(B)) +=====+ ). 625 .( // | | | | \\ ). 626 .( // +------------+ +------------+ \\ ). 627 ( // <------------- Initial Path --------------> \\ ) 628 ( // \\ ) 629 ( // .-. ................................ .-. \\ ) 630 ( //,-( _)-. . . ,-( _)-\\ ) 631 ( .||_ (_ )-.. <-- Route Optimized Path --> ..-(_ (_ ||. ) 632 ( _|| ISP A .) (. ISP B || )) 633 ( ||-(______)-. .`-(______)||- ) 634 ( || | . v | vv ) 635 ( +-----+ ----+ The IRON +-----+-----+ ) 636 | IR(EP(A)) | (Overlaid on the native Internet) | IR(EP(B)) | 637 +-----+-----+ +-----+-----+ 638 | ( ) | 639 .-. .-( .-) .-. 640 ,-( _)-. .-(________________________)-. ,-( _)-. 641 .-(_ (_ )-. .-(_ (_ )-. 642 (_ IRON EUN A ) (_ IRON EUN B ) 643 `-(______)-' `-(______)-' 644 | | 645 +---+----+ +---+----+ 646 | Host A | | Host B | 647 +--------+ +--------+ 649 Figure 5: Communications Between Two IRON Hosts 651 In this reference scenario, VP companies A and B have established 652 IR(VP)s within the Internet that serve EPs to EUNs. EUN A has 653 procured EP(A) from VPC A, while EUN B has procured EP(B) from VPC B. 654 The hosts in both EUNs have assigned EPAs taken from their 655 corresponding EPs on their EUN-interior interfaces, and the IR(EPs) 656 have assigned locators taken from their ISPs on their WAN interfaces. 658 When Host A in EUN A has a packet to send to Host B in EUN B, normal 659 routing conveys the packet from Host A to IR(EP(A)). If IR(EP(A )) 660 does not have a more-specific route, it encapsulates the packet and 661 forwards it to an IR(VP) managed by VPC A. (The encapsulated packet 662 uses the locator address of IR(EP(A)) as the outer source address and 663 the locator address of IR(VP(A)) as the outer destination address.) 664 When IR(VP(A)) receives the encapsulated packet, it checks its FIB 665 for a route toward the packet's inner destination address (i.e., 666 'B'). If IR(VP(A)) does not have an entry for EP(B) in its FIB, it 667 consults its full table of VP-to-locator mappings to discover that 668 the next-hop toward EP(B) is via IR(VP(B)). IR(VP(A)) then re- 669 encapsulates the packet and sends it to IR(VP(B)) which has an entry 670 for EP(B) in its FIB with IR(EP(B)) as the next hop. IR(VP(B)) then 671 re-encapsulates the packet and sends it to IR(EP(B)), which 672 decapsulates the packet and forwards it via EUN B to Host B. 674 In this process, when an IR(VP) re-encapsulates the packet and 675 forwards it to a next-hop IR, it also returns an SCMP redirect 676 message to the previous hop IR if the previous hop is willing to 677 accept redirects. The previous hop IR will then install a route in 678 its FIB that uses a better next hop. For example, if IR(EP(A)) is 679 accepting redirects IR(VP(A)) will return a redirect message when it 680 forwards a packet to IR(VP(B)). IR(EP(A)) will then send subsequent 681 packets directly to IR(VP(B)), which will return a redirect message 682 when it forwards the packets to IR(EP(B)). Finally, IR(EP(A)) will 683 have an optimized route that lists IR(EP(B)) as the next hop. 685 Another redirection scenario arises when IR(VP(A)) is itself willing 686 to accept redirects. In that case, IR(EP(A)) may discover IR(EP(B)) 687 as a better next hop toward EUN A based solely on a redirect message 688 from IR(VP(A)) and without involving IR(VP(B)). Note however that 689 this may require IR(VP(A)) to carry thousands or even millions of EP 690 entries in its FIB for all EUNs that it has sent packets to recently, 691 which may negatively impact scalability. 693 6.4.2. Mixed IRON and Non-IRON Hosts 695 When one host is within an IRON EUN and the other is in a non-IRON 696 EUN (i.e., one that connects to the native Internet instead of the 697 IRON), communications must involve an IR(GW) within the IRON host's 698 VPC. Figure 6 depicts the IRON reference operating scenario for 699 communications between Host A in an IRON EUN and Host B in a non-IRON 700 EUN: 702 _______________________________________ 703 .-( )-. )-. 704 .-( +-------)----+ )-. 705 .-( | | )-. 706 .( +======>+ IR(GW(A)) +---------------+ ). 707 .( // | | \ ). 708 .( // +--------)---+ \ ). 709 ( // ) \ ) 710 ( // The IRON ) \ ) 711 ( // .-. ) \ .-. ) 712 ( //,-( _)-. ) \ ,-( _)-. ) 713 ( .||_ (_ )-. ) The Native Internet .-|_ (_ )-. ) 714 ( _|| ISP A ) ) (_ | ISP B )) 715 ( ||-(______)-' ) |-(______)-' ) 716 ( || | )-. v | ) 717 ( +-----+ ----+ )-. +-----+-----+ ) 718 | IR(EP(A)) |)-. | Router B | 719 +-----+-----+ +-----+-----+ 720 | ( ) | 721 .-. .-(____________________________________)-. .-. 722 ,-( _)-. ,-( _)-. 723 .-(_ (_ )-. .-(_ (_ )-. 724 (_ IRON EUN A ) (_ non-IRON EUN ) 725 `-(______)-' `-(___B___)-' 726 | | 727 +---+----+ +---+----+ 728 | Host A | | Host B | 729 +--------+ +--------+ 731 Figure 6: Communications Between Hosts in IRON and Non-IRON EUNs 733 In this reference scenario, when Host A sends a flow of packets to 734 Host B, IR(EP(A)) encapsulates and forwards them to an IR(VP) from 735 its VPC as a default router. In the simple case, the IR(VP) also 736 acts as an IR(GW) (depicted here as IR(GW)(A))) that decapsulates 737 packets coming from IR(EP(A)) and forwards them into the native 738 Internet. In this scenario, no route optimization is possible since 739 EUN B is not connected to the IRON. 741 In the reverse direction, when Host B sends a flow of packets to Host 742 A, normal Internet routing conveys the packets over the native 743 Internet to IR(GW(A)) since IR(GW(A)) advertises the VP that covers 744 EP(A) into the BGP routing system. IR(GW(A)) will then encapsulate 745 the packets and forward them over the IRON to IR(EP(A)), which in 746 turn delivers them to Host A. 748 6.5. Mobility, Multihoming and Traffic Engineering Considerations 750 While IR(VP)s can be considered as fixed infrastructure, IR(EP)s may 751 need to move between different network points of attachment, connect 752 to multiple ISPs, or explicitly manage their traffic flows. The 753 following sections discuss mobility, multi-homing and traffic 754 engineering considerations for IR(EP)s. 756 6.5.1. Mobility Management 758 When an IR(EP) changes its network point of attachment (e.g., due to 759 a mobility event), it configures a new locator. The IR(EP) then 760 registers the new EP-to-locator mapping with its VPC by sending SRS 761 messages the same as described in Section 6.2. (For further study 762 are performance characteristics of various mechanisms that could be 763 used to propagate these registration updates within the VPC network.) 765 The IR(EP) also sends Neighbor Advertisement (NA) messages as 766 registration updates to each neighboring IR from which it has 767 received packets recently. The NA message includes the new locator 768 as the outer source address and includes the previous locator within 769 an NA option field. The neighboring IR will update its neighbor 770 cache so that subsequent packets will flow through the new locator. 772 6.5.2. Multihoming 774 An IR(EP) registers only the locator of its primary ISP with its VPC 775 even if it connects to multiple ISPs. If the IR(EP) later needs to 776 select a different ISP as its primary, it simply repeats the EP-to- 777 locator registration process the same as if it were reacting to a 778 mobility event as described above. 780 6.5.3. Inbound Traffic Engineering 782 When an IR(EP) receives packets via its primary ISP (i.e., the ISP 783 for which it is currently registered with the VPC), it may wish to 784 balance the load of incoming traffic between multiple ISP 785 connections. In that case, the IR(EP) may send NA messages to 786 certain neighboring IRs the same as in the case of a mobility event 787 as described in Section 6.5.1. In that way, the IR(EP) can manage 788 its incoming traffic flows for best utilization of its multiple ISPs. 790 6.5.4. Outbound Traffic Engineering 792 IR(EP)s maintain a list of IR(VP)s that serve as default routers for 793 VET interface encapsulation of inner packets with source addresses 794 taken from an EP prefix. IR(EP)s also maintain a list of neighbors 795 on underlying interfaces that serve as default routers for packets 796 with non-EP source addresses. If the inner and outer protocols are 797 of different versions (e.g., OSI/CLNP as the inner version and IPv4 798 as the outer version) then the default routes of both versions are 799 mutually exclusive and no special arrangements are needed. 801 If the inner and outer protocol versions are the same, however (e.g., 802 IPv6 as both the inner and outer protocol) then a special treatment 803 of the default route is necessary. In particular, the IR(EP) must 804 examine the source address of a packet to be forwarded to determine 805 the proper handling of "default". If the packet uses a source 806 address taken from an EP prefix, the IR(EP) forwards it to an IR(VP) 807 using encapsulation via a VET interface; otherwise, the IR(EP) 808 forwards the packet to a next hop on an underlying link. 810 Using this arrangement of default, when an IR(EP) forwards a packet 811 with an EP source address it can forward it to any of its associated 812 IR(VP)s using VET interface encapsulation over any of its underlying 813 interfaces. The choice of underlying interface can be managed, and 814 the source address assigned to the underlying interface will be used 815 as the outer source address of the encapsulated packet. Each 816 encapsulated packet can therefore be directed through the desired ISP 817 using a topologically-correct outer source address. 819 6.6. Renumbering Considerations 821 As better link layer technologies and service plans emerge, customers 822 will be motivated to select their service providers through healthy 823 competition between ISPs. If a customer's EUN addresses are tied to 824 a specific ISP, however, the customer may be forced to undergo a 825 painstaking EUN renumbering process if it wishes to changes to a 826 different ISP [RFC4192][RFC5887]. 828 When a customer obtains EP prefixes from a VPC, it can change between 829 ISPs seamlessly and without need to renumber. If the VPC itself 830 applies unreasonable costing structures for use of the EPs, however, 831 the customer may be compelled to seek a different VPC and would again 832 be required to confront a renumbering scenario. The strength of the 833 IRON approach therefore lies within a tradeoff between the 834 requirement for VPCs to conduct ethical business practices with 835 reasonable rates and the ability for customers to painlessly renumber 836 their EUNs. 838 6.7. NAT Traversal Considerations 840 The Internet today consists of a global public IPv4 routing and 841 addressing system with non-IRON EUNs that use either public or 842 private IPv4 addressing. The latter class of EUNs connect to the 843 public IPv4 Internet via Network Address Translators (NATs). When an 844 IR(EP) is located behind a NAT, its selects IR(VP)s using the same 845 procedures as for IR(EP)s with public addresses, i.e., it will send 846 SRS messages to IR(VP)s in order to get SRA messages in return. The 847 only requirement is that the IR(EP) must configure its SEAL 848 encapsulation to use a transport protocol that supports NAT 849 traversal, namely UDP. 851 Since the IR(VP) maintains state about its IR(EP) customers, it can 852 discover locator information for each IR(EP) by examining the UDP 853 port number and IPv4 address in the outer headers of SRS messages. 854 When there is a NAT in the path, the UDP port number and IPv4 address 855 in the SRS message will correspond to state in the NAT box and might 856 not correspond to the actual values assigned to the IR(EP). The 857 IR(VP) can then encapsulate packets destined to hosts serviced by the 858 IR(EP) within outer headers that use this IPv4 address and UDP port 859 number. The NAT box will receive the packets, translate the values 860 in the outer headers to match those assigned to the IR(EP), then 861 forward the packets to the IR(EP). 863 7. Open Research Areas 865 A number of open research areas exist which would need to be explored 866 in taking the IRON concept into large-scale deployment. 867 Considerations for the scalability of Internet Routing due to 868 multihoming, traffic engineering and provider-independent addressing 869 are discussed in [I-D.narten-radir-problem-statement]. Route 870 optimization considerations for mobile networks are found in 871 [RFC5522]. Finally, security implications for tunneling over large- 872 scale Internetworks and feasibility analysis for maintaining a 873 globally distributed mapping service bear further investigation. 875 8. Related Initiatives 877 IRON builds upon the concepts RANGER architecture [RFC5720], and 878 therefore inherits the same set of related initiatives. 880 Virtual Aggregation (VA) [I-D.ietf-grow-va] and Aggregation in 881 Increasing Scopes (AIS) [I-D.zhang-evolution] provide the basis for 882 the Virtual Prefix concepts. 884 Internet vastly improved plumbing (Ivip) [I-D.whittle-ivip-arch] has 885 contributed valuable insights, including the use of real-time 886 mapping. 888 9. IANA Considerations 890 There are no IANA considerations for this document. 892 10. Security Considerations 894 Security considerations that apply to tunneling in general are 895 discussed in [I-D.ietf-v6ops-tunnel-security-concerns]. Additional 896 considerations that apply also to IRON are discussed in RANGER 897 [RFC5720], VET [I-D.templin-intarea-vet] and SEAL 898 [I-D.templin-intarea-seal]. 900 IRON assumes that the mapping system (including the MVPd and 901 corresponding FQDNs in the DNS) be well-managed and not vulnerable to 902 subversion. This assumption is no different than for the current 903 state of affairs for client-server communications in the Internet 904 today. 906 IR(EP)s require a means for securely registering their EP-to-locator 907 bindings with their VPC and with correspondent nodes. Each VPC 908 provides its customer IR(EP)s with a secure means for registering and 909 re-registering their mappings, and the use of SEAL encapsulation 910 provides a nonce with each packet to allow correspondent nodes to 911 authenticate binding updates from IR(EP)s. 913 11. Acknowledgements 915 This ideas behind this work have benefited greatly from discussions 916 with colleagues; some of which appear on the RRG and other IRTF/IETF 917 mailing lists. Mohamed Boucadair, Wesley Eddy and Robin Whittle 918 provided review input. 920 12. References 922 12.1. Normative References 924 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 925 September 1981. 927 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 928 (IPv6) Specification", RFC 2460, December 1998. 930 12.2. Informative References 932 [BGPMON] Analyses, B., "BGPmon.net - Monitoring Your Prefixes, 933 http://bgpmon.net/stat.php", June 2010. 935 [I-D.ietf-grow-va] 936 Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and 937 L. Zhang, "FIB Suppression with Virtual Aggregation", 938 draft-ietf-grow-va-02 (work in progress), March 2010. 940 [I-D.ietf-v6ops-tunnel-security-concerns] 941 Hoagland, J., Krishnan, S., and D. Thaler, "Security 942 Concerns With IP Tunneling", 943 draft-ietf-v6ops-tunnel-security-concerns-02 (work in 944 progress), March 2010. 946 [I-D.narten-radir-problem-statement] 947 Narten, T., "On the Scalability of Internet Routing", 948 draft-narten-radir-problem-statement-05 (work in 949 progress), February 2010. 951 [I-D.russert-rangers] 952 Russert, S., Fleischman, E., and F. Templin, "Operational 953 Scenarios for IRON and RANGER", draft-russert-rangers-03 954 (work in progress), June 2010. 956 [I-D.templin-intarea-seal] 957 Templin, F., "The Subnetwork Encapsulation and Adaptation 958 Layer (SEAL)", draft-templin-intarea-seal-15 (work in 959 progress), June 2010. 961 [I-D.templin-intarea-vet] 962 Templin, F., "Virtual Enterprise Traversal (VET)", 963 draft-templin-intarea-vet-15 (work in progress), 964 June 2010. 966 [I-D.whittle-ivip-arch] 967 Whittle, R., "Ivip (Internet Vastly Improved Plumbing) 968 Architecture", draft-whittle-ivip-arch-04 (work in 969 progress), March 2010. 971 [I-D.zhang-evolution] 972 Zhang, B. and L. Zhang, "Evolution Towards Global Routing 973 Scalability", draft-zhang-evolution-02 (work in progress), 974 October 2009. 976 [RFC1070] Hagens, R., Hall, N., and M. Rose, "Use of the Internet as 977 a subnetwork for experimentation with the OSI network 978 layer", RFC 1070, February 1989. 980 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 981 Reserved for Documentation", RFC 3849, July 2004. 983 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 984 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 985 September 2005. 987 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 988 Protocol 4 (BGP-4)", RFC 4271, January 2006. 990 [RFC4548] Gray, E., Rutemiller, J., and G. Swallow, "Internet Code 991 Point (ICP) Assignments for NSAP Addresses", RFC 4548, 992 May 2006. 994 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 995 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 996 March 2008. 998 [RFC5522] Eddy, W., Ivancic, W., and T. Davis, "Network Mobility 999 Route Optimization Requirements for Operational Use in 1000 Aeronautics and Space Exploration Mobile Networks", 1001 RFC 5522, October 2009. 1003 [RFC5720] Templin, F., "Routing and Addressing in Networks with 1004 Global Enterprise Recursion (RANGER)", RFC 5720, 1005 February 2010. 1007 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 1008 Reserved for Documentation", RFC 5737, January 2010. 1010 [RFC5743] Falk, A., "Definition of an Internet Research Task Force 1011 (IRTF) Document Stream", RFC 5743, December 2009. 1013 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 1014 Still Needs Work", RFC 5887, May 2010. 1016 Author's Address 1018 Fred L. Templin (editor) 1019 Boeing Research & Technology 1020 P.O. Box 3707 MC 7L-49 1021 Seattle, WA 98124 1022 USA 1024 Email: fltemplin@acm.org