idnits 2.17.1 draft-russert-rangers-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5720]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 2, 2010) is 5076 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'H' is mentioned on line 1418, but not defined == Missing Reference: 'S' is mentioned on line 1426, but not defined == Unused Reference: 'RFC1035' is defined on line 1617, but no explicit reference was found in the text == Unused Reference: 'RFC3344' is defined on line 1665, but no explicit reference was found in the text == Unused Reference: 'RFC3775' is defined on line 1668, but no explicit reference was found in the text == Unused Reference: 'RFC4309' is defined on line 1697, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-10) exists of draft-ietf-behave-v6v4-framework-09 == Outdated reference: A later version (-04) exists of draft-ietf-v6ops-tunnel-security-concerns-02 == Outdated reference: A later version (-16) exists of draft-irtf-rrg-recommendation-08 == Outdated reference: A later version (-17) exists of draft-templin-iron-01 -- Obsolete informational reference (is this intentional?): RFC 2767 (Obsoleted by RFC 6535) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3344 (Obsoleted by RFC 5944) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Russert, Ed. 3 Internet-Draft E. Fleischman, Ed. 4 Intended status: Informational F. Templin, Ed. 5 Expires: December 4, 2010 Boeing Research & Technology 6 June 2, 2010 8 Operational Scenarios for IRON and RANGER 9 draft-russert-rangers-03.txt 11 Abstract 13 The Internet Routing Overlay Network (IRON) [draft-templin-iron] and 14 Routing and Addressing in Networks with Global Enterprise Recursion 15 (RANGER) [RFC5720] provide an architectural framework for scalable 16 routing and addressing. Together, these architectures provide for 17 scalability, provider independence, mobility, multihoming and 18 security for the next generation Internet. This document describes a 19 series of operational use case scenarios in order to showcase the 20 architectural capabilities. It further shows how IRON and RANGER 21 restore the network-within-network principles originally intended for 22 the sustained growth of the Internet. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on December 4, 2010. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 4. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 12 62 4.1. Global Concerns . . . . . . . . . . . . . . . . . . . . . 12 63 4.1.1. Scaling the Global Interdomain Routing Core . . . . . 12 64 4.1.2. Supporting Large Corporate Enterprise Networks . . . . 14 65 4.2. Autonomous System Concerns . . . . . . . . . . . . . . . . 16 66 4.3. Small Enterprise Concerns . . . . . . . . . . . . . . . . 17 67 4.4. IPv4/IPv6 Transition and Coexistence . . . . . . . . . . . 19 68 4.5. Mobility and MANET . . . . . . . . . . . . . . . . . . . . 22 69 4.5.1. Global Mobility Management . . . . . . . . . . . . . . 22 70 4.5.2. First-Responder Mobile Ad-Hoc Networks (MANETs) . . . 23 71 4.5.3. Tactical Military MANETs . . . . . . . . . . . . . . . 25 72 4.6. Provider Concerns . . . . . . . . . . . . . . . . . . . . 28 73 4.6.1. ISP Networks . . . . . . . . . . . . . . . . . . . . . 28 74 4.6.2. Cellular Operator Networks . . . . . . . . . . . . . . 29 75 4.6.3. Aeronautical Telecommunications Network (ATN) . . . . 29 76 4.6.4. Unmanaged Networks . . . . . . . . . . . . . . . . . . 32 77 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 78 6. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 34 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 81 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 83 10.1. Normative References . . . . . . . . . . . . . . . . . . . 34 84 10.2. Informative References . . . . . . . . . . . . . . . . . . 35 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 87 1. Introduction 89 The Internet is continually required to support more users, more 90 internetwork connections and increasing complexity due to diverse 91 policy requirements. This growth and change strains the 92 infrastructure and demands new solutions. Some of the complimentary 93 approaches to transform Internet technology are being pursued 94 concurrently within the IETF: translation (including Network Address 95 Translation (NAT)), tunneling (map and encapsulate), and native IPv6 96 [RFC2460] deployment. The Internet Routing Overlay Network (IRON) 97 [I-D.templin-iron] and Routing and Addressing in Networks with Global 98 Enterprise Recursion (RANGER) [RFC5720] describe the architectural 99 elements of a map and encapsulate approach that also facilitates the 100 other two approaches. This document discusses operational scenarios 101 for IRON and RANGER. Since they are separable yet complimentary 102 architectures that are often mentioned together, this document uses 103 the nomenclature "IRON/RANGER" to mean "IRON in conjunction with 104 RANGER". 106 IRON/RANGER provides an architectural framework for scalable routing 107 and addressing. They provide for scalability, provider independence, 108 mobility, multihoming and security for the next generation Internet. 109 The IRON/RANGER architectural principles are not new. They can be 110 traced to the deliberations of the ROAD group [RFC1380], and also to 111 still earlier works including NIMROD [RFC1753] and the Catenet model 112 for internetworking [CATENET][IEN48][RFC2775]. [RFC1955] captures 113 the high-level architectural aspects of the ROAD group deliberations 114 in a "New Scheme for Internet Routing and Addressing (ENCAPS) for 115 IPNG". 117 The Internet has grown tremendously since these architectural 118 principles were first developed, and that evolution increases the 119 need for these capabilities. The Internet has become a critical 120 resource for business, for government, and for individual users 121 throughout the developed world. The IRON/RANGER architectures carry 122 forward these historic architectural principles, creating a 123 ubiquitous enterprise network structure that can represent 124 collections of network elements ranging from the granularity of a 125 singleton router all the way up to an entire Internet. This 126 enterprise network structure uses border routers that configure 127 tunnel endpoints to connect potentially recursively-nested networks. 128 Each enterprise network may use completely independent internal 129 Routing Locator (RLOC) address spaces, supporting a virtual overlay 130 network connecting edge networks and devices that are addressed with 131 globally unique Endpoint Interface iDentifiers (EIDs). The IRON/ 132 RANGER virtual overlay can transcend traditional administrative and 133 organizational boundaries. In its purest form, this overlay network 134 could therefore span the entire Internet and restore the end-to-end 135 transparency envisioned in [RFC2775]. 137 The IRON/RANGER architectures are built using Virtual Enterprise 138 Traversal (VET) [RFC5558], the Subnetwork Encapsulation and 139 Adaptation Layer (SEAL) [RFC5320], Intra-Site Automatic Tunnel 140 Addressing Protocol (ISATAP) [RFC5214][RFC5579], and other mechanisms 141 including IPsec [RFC4301]. This document describes use cases and 142 shows how the IRON/RANGER mechanisms apply. Complimentary mechanisms 143 (e.g., DNS, DHCP, NAT, etc.) are included to show how the various 144 pieces can work together. It expands on the concepts introduced in 145 IPv6 Enterprise Network Scenarios [RFC4057] and analysis [RFC4852], 146 and shows how the enterprise network model generalizes to a broad 147 range of scenarios. These use cases are included to provide 148 examples, invite criticism and comment, and explore the potential for 149 creating the next-generation Internet using the IRON/RANGER 150 architectures. Familiarity with IRON, RANGER, VET, SEAL, and ISATAP 151 are assumed. 153 2. Terminology 155 Internet Topology Hierarchy 156 The Internet Protocol (IP) natively supports a topology hierarchy 157 comprised of increasing aggregations of networked elements. 158 Network interfaces of devices are grouped into subnetworks and 159 subnetworks are grouped into larger aggregations. Subnetworks can 160 be optionally grouped into areas and the areas grouped into an 161 autonomous system (AS). Alternatively, subnetworks can be 162 directly grouped into an AS. The foundation of the IP Topology 163 Hierarchy is the AS, which determines the administrative 164 boundaries of a network deployment including its routing, 165 addressing, quality of service, security, and management. Intra- 166 domain routing occurs within an autonomous system and inter-domain 167 routing links autonomous systems into a network of networks 168 (Internet). 170 Routing Locator (RLOC) 171 an address assigned to an interface in an enterprise-interior 172 routing region. Note that RLOC space is local to each enterprise 173 network. 175 The IPv4 public address space currently in use today can be 176 considered as the RLOC space for the global Internet as a giant 177 "enterprise network". 179 Endpoint Interface iDentifier (EID) 180 an address assigned to an edge network interface of an end system. 181 Note that EID space is global in scope, and must be separate and 182 distinct from any RLOC space. 184 commons 185 an enterprise-interior routing region that provides a subnetwork 186 for cooperative peering between the border routers of diverse 187 organizations that may have competing interests. An example of a 188 commons is the Default Free Zone (DFZ) of the global Internet. 189 The enterprise-interior routing region within the commons uses an 190 addressing plan taken from RLOC space. 192 enterprise network 193 the same as defined in [RFC4852], where the enterprise network 194 deploys a unified RLOC space addressing plan within the commons, 195 but may also contain partitions with disjoint RLOC spaces and/or 196 organizational groupings that can be considered as enterprises 197 unto themselves. An enterprise network therefore need not be "one 198 big happy family", but instead provides a commons for the 199 cooperative interconnection of diverse organizations that may have 200 competing interests (e.g., such as the case within the global 201 Internet default free zone). 203 Historically, enterprise networks are associated with large 204 corporations or academic campuses. However, in IRON/RANGER an 205 enterprise network may exist at any IP Topology Hierarchy level. 206 The IRON/RANGER architectural principles apply to any networked 207 entity that has some degree of cooperative active management. 208 This definition therefore extends to home networks, small office 209 networks, a wide variety of mobile ad-hoc networks (MANETs), and 210 even to the global Internet itself. 212 site 213 a logical and/or physical grouping of interfaces within an 214 enterprise network commons, where the topology of the site is a 215 proper subset of the topology of the enterprise network. A site 216 may contain many interior sites, which may themselves contain many 217 interior sites in a recursive fashion. 219 Throughout the remainder of this document, the term "enterprise" 220 refers to either enterprise or site, i.e., the IRON/RANGER 221 principles apply equally to enterprises and sites of any size or 222 shape. At the lowest level of recursive decomposition, a 223 singleton Enterprise Border Router can be considered as an 224 enterprise unto itself. 226 Enterprise Border Router (EBR) 227 a node at the edge of an enterprise network that is also 228 configured as a tunnel endpoint in an overlay network. EBRs 229 connect their directly-attached networks to the overlay network, 230 and connect to other networks via IP-in-IP tunneling across the 231 commons to other EBRs. This definition is intended as an 232 architectural equivalent of the functional term "EBR" defined in 233 [RFC5558], and is synonymous with the term "xTR" used in other 234 contexts (e.g., [I-D.farinacci-lisp]). 236 Enterprise Border Gateway (EBG) 237 an EBR that also connects the enterprise network to provider 238 networks and/or to the global Internet. EBGs are typically 239 configured as default routers in the overlay, and provide 240 forwarding services for accessing IP networks not reachable via an 241 EBR within the commons. This definition is intended as an 242 architectural equivalent of the functional term "EBG" defined in 243 [RFC5558], and is synonymous with the term "default mapper" used 244 in other contexts (e.g., [I-D.jen-apt]). 246 overlay network 247 a virtual network manifested by routing and addressing over 248 virtual links formed through automatic tunneling. An overlay 249 network may span many underlying enterprise networks. 251 6over4 252 Transmission of IPv6 over IPv4 Domains without Explicit Tunnels 253 [RFC2529]; functional specifications and operational practices for 254 automatic tunneling of unicast/multicast IPv6 packets over 255 multicast-capable IPv4 enterprise networks. 257 ISATAP 258 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) 259 [RFC5214][RFC5579]; functional specifications and operational 260 practices for automatic tunneling over unicast-only enterprise 261 networks. 263 VET 264 Virtual Enterprise Traversal (VET) [RFC5558]; functional 265 specifications and operational practices that provide a functional 266 superset of 6over4 and ISATAP. In addition to both unicast and 267 multicast tunneling, VET also supports address/prefix 268 autoconfiguration as well as additional encapsulations such as 269 IPSec, SEAL, LISP/UDP, Teredo/UDP, etc. 271 SEAL 272 Subnetwork Encapsulation and Adaptation Layer (SEAL) [RFC5320]; a 273 functional specification for robust packet identification and link 274 MTU adaptation over tunnels. SEAL supports effective ingress 275 filtering and adapts to subnetworks configured over links with 276 diverse characteristics. 278 Within the IRON/RANGER architectural context, the SEAL 279 "subnetwork" and IRON/RANGER "enterprise" should be considered as 280 identical abstractions. 282 Provider-Independent (PI) prefix 283 an EID prefix (e.g., 2001:DB8::/48, 192.0.2/24, etc.) that is 284 routable within a limited scope and may also appear in enterprise 285 network mapping tables. PI prefixes that can appear in mapping 286 tables are typically delegated to a BR by a registry, but are not 287 aggregated by a provider network. 289 Provider-Aggregated (PA) prefix 290 an EID prefix that is either derived from a PI prefix or delegated 291 directly to a provider network by a registry. Although not widely 292 discussed, it bears specific mention that a prefix taken from a 293 delegating router's PI space becomes a PA prefix from the 294 perspective of the requesting router. 296 Customer Premises Equipment (CPE) Router 297 a residential or small office router that provides IPv4 and/or 298 IPv6 support. The user or the service provider may manage the 299 router. 301 Carrier Grade NAT (CGN) 302 a special (usually high capacity) IPv4 to IPv4 NAT deployed within 303 the service provider network that serves multiple subnets. 305 3. Approach 307 The IRON [I-D.templin-iron] and RANGER [RFC5720] architectures seek 308 to fulfill the objectives set forth in [RFC1955]: 310 o No Changes to Hosts 312 o No Changes to Most Routers 314 o No New Routing Protocols 316 o No New Internet Protocols 317 o No Translation of Addresses in Packets 319 o Reduces the Routing Table Size in All Routers 321 o Uses the Current Internet Address Structure 323 The IRON/RANGER enterprise network is a cooperative networked 324 collective sharing a common (business, social, political, etc.) goal. 325 An enterprise network can be simple or complex in composition and can 326 operate at any IP Topology Hierarchy level. Although IRON/RANGER 327 focuses on encapsulation, it is also compatible with both native and 328 translated routing and addressing. 330 IRON/RANGER enables a protocol and/or addressing system to be 331 connected in a virtual overlay across an untrusted transit network, 332 or "commons". While it does not show all possible uses, Figure 1 333 illustrates that IRON/RANGER supports the creation of a distributed 334 network across an intervening commons which could implement a 335 dissimilar IP version, routing protocol, or addressing system. 337 .--------------. .--------------. .-------------. 338 / \_ _/ \_ _/ \ 339 \ Enterprise A / \ Commons / \ Enterprise B / 340 \_ _ _ _ _ _ _ / \_ _ _ _ _ _ _ / \_ _ _ _ _ _ _/ 341 Domains 343 Network / IPvx IPvy IPvz 344 Protocol \ IPv6 IPv4 IPv6 346 IP Security secured unsecured secured 348 Mgmt Domain Entity A ISP Entity B 350 / 351 | Public Addresses Private Addresses Public Addresses 352 Addressing |Private Addresses Public Addresses Private Addresses 353 | PA Addresses PI Addresses PA Addresses 354 \ PI Addresses PA Addresses PI Addresses 356 Figure 1: IRON/RANGER links Distributed Enterprise networks 358 The IRON/RANGER concepts can be applied recursively. They can be 359 implemented at any level within the IP Topology Hierarchy to create 360 an enterprise-within-enterprise organizational structure extending 361 traditional AS, area, or subnetwork boundaries. This structure uses 362 border routers that configure tunnel endpoints to enable 363 communications between potentially recursively-nested enterprise 364 networks in a virtual overlay network that transcends traditional 365 administrative and organizational boundaries. In its purest form, 366 this overlay network could therefore span the entire Internet and 367 restore end-to-end transparency (RFC 2775). 369 The IRON/RANGER architectures apply the best current practice 370 insights from previous encapsulation systems as they are currently 371 articulated within the Virtual Enterprise Traversal [RFC5558], and 372 Subnetwork Encapsulation and Adaptation Layer [RFC5320] functional 373 specifications. The result is an architecture and protocol system 374 that can be used to create arbitrarily complex, scalable IP 375 deployments that support both unicast and multicast routing and 376 addressing systems. 378 IRON/RANGER supports scalable routing through a recursively-nested 379 enterprise-within-enterprise network capability. The fundamental 380 building block is the Enterprise Border Router (EBR) (see Figure 2). 381 The EBR is the limiting factor for IRON/RANGER recursion, and in 382 certain contexts a singleton EBR can be viewed as an enterprise 383 network unto itself. Traditional network infrastructures can be 384 extended to support complex structures solely with the addition of 385 EBRs with no other modification to any networked entity. 387 An EBR can be a commercial off the shelf router, a tactical military 388 radio, an aircraft mobile router, etc., but it can also be an end 389 system (e.g., a laptop computer, a soldiers' handheld device, etc.) 390 that has an embedded gateway function [RFC1122]. 392 Provider-edge Interfaces 393 x x x 394 | | | 395 +--------------------+---+--------+----------+ E 396 | | | | | n 397 | I | | .... | | t 398 | n +---+---+--------+---+ | e 399 | t | +--------+ /| | r 400 | e I x----+ | Host | I /*+------+--< p I 401 | r n | |Function| n|**| | r n 402 | n t | +--------+ t|**| | i t 403 | a e x----+ V e|**+------+--< s e 404 | l r . | E r|**| . | e r 405 | f . | T f|**| . | f 406 | V a . | +--------+ a|**| . | I a 407 | i c . | | Router | c|**| . | n c 408 | r e x----+ |Function| e \*+------+--< t e 409 | t s | +--------+ \| | e s 410 | u +---+---+--------+---+ | r 411 | a | | .... | | i 412 | l | | | | o 413 +--------------------+---+--------+----------+ r 414 | | | 415 x x x 416 Enterprise-edge Interfaces 418 Figure 2: Enterprise Border Router (EBR) 420 EBRs connect networks and end systems to one or more enterprise 421 networks via a repertoire of interface types. Enterprise-interior 422 interfaces attach to a commons. Provider-edge interfaces support 423 traditional routing relationships up the IP Topology Hierarchy and 424 Enterprise-edge Interfaces support traditional relationships down the 425 IP Topology Hierarchy. Internal virtual interfaces are typically 426 loopback interfaces or VMware-like host-in-host interfaces. 428 VET interfaces support IRON/RANGER recursion and IP-in-IP 429 encapsulation. VET interfaces are configured over provider-edge, 430 enterprise interior, or enterprise-edge interfaces to allow recursion 431 horizontally or vertically within the IP Topology Hierarchy. A VET 432 interface may be configured over several underlying interfaces that 433 all connect to the same enterprise network. This creates a link- 434 layer multiplexing capability that can provide several advantages 435 (see [RFC5558] Appendix B). One important advantage is continuous 436 operation across failovers between multiple links attached to the 437 same enterprise network, without any need for readdressing. 439 Figure 3 shows two enterprise networks (each with their own internal 440 addressing and routing systems) that communicate over a virtual 441 overlay network across a commons. The virtual overlay is manifested 442 by tunneling, which links enterprise networks separated by 443 geographical remoteness, protocol incompatibility, or both. An 444 ingress EBR (iEBR) within the left enterprise network seeks to 445 forward encapsulated packets across the commons to the egress EBR 446 (eEBR) within the right enterprise network. 448 The figure shows that the eEBR assigns a Routing LOCator (RLOC) 449 address on its interface to the Commons' interior IP routing and 450 address space, while the destination host assigns an Endpoint 451 interface IDentifier (EID) on its enterprise edge interface. The 452 iEBR uses a mapping system to discover the RLOC of an eEBR on the 453 path to the destination EID address. A distinct mapping system is 454 maintained within each recursively-nested enterprise network instance 455 operating at a specific level of the IP Topology Hierarchy. IRON/ 456 RANGER uses the mapping system to join peer enterprise networks via a 457 virtual overlay across a commons. 459 Mapping System RLOC EID 460 . (BGP, DNS, etc.) . . 461 .---.------. .----------. . .------.---. 462 / . \ / \ . / . \ 463 / (O) iEBR------/--------------\------eEBR * \ 464 \ / \ Commons / \ / 465 \_ _ _ _ _ _ / \_ _ _ _ _ _ / \_ _ _ _ _ _/ 467 Figure 3: The IRON/RANGER Model 469 EBRs must configure both RLOC and EID addresses and/or prefixes. 470 Autoconfiguration is coordinated with Enterprise Border Gateways 471 (EBGs) that connect to the next-higher layer in the recursive 472 hierarchy, as specified in VET. Standard mechanisms including DHCP 473 [RFC2131] [RFC3315] and Stateless Address Autoconfiguration (SLAAC) 474 [RFC4862] are used for this purpose. 476 Similarly, EBRs require a means to discover other EBRs and EBGs that 477 can be used as enterprise network exit points. VET specifies 478 mechanisms for border router discovery using both the global DNS 479 and/or enterprise-local name services such as LLMNR [RFC4795]. 481 The mapping system is a distributed database that is synchronized 482 among a limited set of mapping agents. Many different database 483 synchronization and mapping protocol alternatives have been proposed, 484 however the IRON/RANGER system uses dynamic routing protocols (e.g., 485 a BGP instance) within an Internet Routing Overlay Network (IRON) 486 that tracks virtual EID prefixes owned by registries from which more- 487 specific prefixes are delegated to customers. It must specifically 488 be noted that this EID-based dynamic routing protocol instance is 489 maintained separately from any RLOC-based dynamic routing protocol 490 instances. In this way, the Routing Information Bases (RIBs) of 491 routers connected to the IRON need only retain a manageable number of 492 short EID prefixes (e.g., a few thousand ::/20 IPv6 prefixes) while 493 more-specific prefixes are kept out of the RIB. 495 EBRs forward initial packets for which they have no mapping to an 496 EBG. The EBG in turn forwards the packet toward the final 497 destination and returns a redirect to inform the EBR of a better next 498 hop if necessary. The EBR then receives a mapping reply that it can 499 use to populate its Forwarding Information Base (FIB). It then 500 encapsulates each forwarded packet in an outer IP header for 501 transmission across the commons to the remote RLOC address of an 502 eEBR. The eEBR in turn decapsulates the packets and forwards them to 503 the destination EID address. The Routing Information Base (RIB) 504 within the commons only needs to maintain state regarding RLOCs and 505 not EIDs. The synchronized EID-to-RLOC mapping state is not subject 506 to oscillations due to link state changes within the commons. IRON/ 507 RANGER supports scalable addressing by selecting a suitably large EID 508 addressing range that is distinct from any enterprise-interior RLOC 509 addressing ranges. 511 4. Scenarios 513 4.1. Global Concerns 515 4.1.1. Scaling the Global Interdomain Routing Core 517 Growth in the Internet has created challenges in routing and 518 addressing that have been recognized for more than 15 years. IPv4 519 [RFC0791] address space is limited, and Regional Internet Registry 520 (RIR) allocation is passing the "very painful" Host Density (HD) 521 ratio threshold of 86% (that is, 192M allocated addresses) [RFC3194]. 522 As a result, exhaustion of the IPv4 address pool is predicted within 523 the next two years [V4pool], [Huston-end]. IPv6 promises to resolve 524 the address shortage with a much larger address space, but transition 525 is costly and could exacerbate Border Gateway Protocol (BGP) problems 526 described below. Richer interconnection, increased multihoming 527 (especially with Provider-Independent (PI) addresses), and a desire 528 to support traffic engineering via finer control of routing has led 529 to super-linear growth of BGP routing tables in the default-free zone 530 or "DFZ" of the Internet. This growth is placing increasing 531 pressures on router capacities and technology costs that are 532 unsustainable for the longer term within the current Internet routing 533 framework. 535 IRON/RANGER allows the coordinated reuse of addresses from Enterprise 536 to Enterprise by making RLOC address spaces independent of one 537 another. Figure 4 shows how the IRON/RANGER architectures allow the 538 use of separate address spaces for RLOC and EID addressing in the 539 Internet. This yields more endpoint address space, especially with 540 the use of IPv6, and also reduces the load on BGP in the Internet 541 routing core. Note that Figure 4 could represent variants of RFC 542 4057 scenarios 1 and 2. 544 EID RLOC EID 545 PA Spaces PI 546 Allocation Registration 547 .-------------------------------. ^ 548 / Internet Commons \ | 549 | .---------------------------. | | 550 2001:DB8::/40 | / Enterprise A \ | 2001:DB8:10::/56 551 | |/ 10.1/16 \ | ^ 552 | || .-------------------------. || | 553 V || / Enterprise A.1 \ || | 554 2001:DB8::/48 || | 10.1/16 | || 2001:DB8:11::/56 555 || \_________________________/ / | 556 | \ / | 557 | --------------------------- | 558 | | 559 | .---------------------------. | 560 | / Enterprise B \ | 561 2001:DB8:100::/40 | | 10.1/16 | | 2001:DB8:12::/56 562 | \____________________________/ | 563 \ / 564 \_______________________________/ 566 Figure 4: Enterprise networks and the Internet 568 RLOC address spaces are entirely independent of one another, as they 569 are used only within an enterprise network (recall that an enterprise 570 network can exist at any level of the IP Topology Hierarchy). Such 571 an arrangement allows each RLOC space to maintain an independent 572 routing system and thereby avoid the inherent scaling issues if a 573 single monolithic routing system were used for all. 575 EID address space can be Provider-Aggregated (PA) or PI, and taken 576 from either IPv4, or IPv6. EID addresses (barring use of Network 577 Address Translation (NAT)) are globally unique, even when routable 578 only within a more limited scope (e.g., in their own edge networks). 580 The IRTF routing research group is investigating a Preliminary 581 Recommendation for a Routing Architecture 583 [I-D.irtf-rrg-recommendation] that provides a taxonomy for routing 584 scaling solutions for the global Internet interdomain routing core. 585 IRON/RANGER present a core/edge separation architecture within this 586 taxonomy that uniquely shows applicability from the core all the way 587 out to edge networks via its recursive enterprise-within-enterprise 588 framework. IRON/RANGER is further compatible with a number of 589 schemes intending to address routing scaling issues, including A 590 Practical Transit Mapping Service (APT) [I-D.jen-apt], FIB 591 Suppression with Virtual Aggregation [I-D.francis-intra-va], LISP 592 [I-D.farinacci-lisp] and others. 594 4.1.2. Supporting Large Corporate Enterprise Networks 596 Each enterprise network operator must be able to manage its internal 597 networks and use the Internet infrastructure to achieve its 598 performance and reliability goals. Enterprise networks that are 599 multihomed or have mobile components frequently require provider- 600 independent addressing and the ability to coordinate with multiple 601 providers without renumbering flag days [RFC4192], 602 [I-D.carpenter-renum-needs-work]. IRON/RANGER provides a way to 603 coordinate addressing plans and inter-enterprise routing, with full 604 support for scalability, provider-independence, mobility, multi- 605 homing and security. 607 _.--------------------._ 608 _.---'' -. 609 ,--'' ,---. `---. 610 ,-' X5 X6 .---.. `-. 611 ,' ,.X1-.. / \ ,' `. `. 612 ,' ,' `. .' E2 '. X8 Em \ `. 613 / / \ | ,--. | / _,.._ \ \ 614 / / E1 \ | Y3 `. | | / Y7 | \ 615 ; | ___ | | ` W Y4 |... | `Y6 ,' | : 616 | | ,-' `. X2 | `--' | | `'' | | 617 : | | V Y2 | \ _ / | | ; 618 \ | `-Y1,,' | \ .' Y5 / \ ,-Y8'`- / / 619 \ \ / \ \_' / X9 `. ,'/ / 620 `. \ X3 `.__,,' `._ Y9'',' ,' 621 ` `._ _,' ___.......X7_ `---' ,' 622 ` `---' ,-' `-. -' 623 `---. `. E3 Z _' _.--' 624 `-----. \---.......---' _.---'' 625 `----------------'' 627 <------------------- Global IPv4 Internet ------------------> 629 Figure 5: Wnterprise networks within the Internet Commons 631 Figure 5 depicts enterprise networks E1 through Em connected to the 632 global IPv4 Internet via Enterprise Border Routers (EBRs) X1 through 633 X9. This same set of border nodes also act as Enterprise Border 634 Gateways (EBGs) that provide default routing services for nodes 635 within their respective enterprise networks. The global Internet 636 forms a commons across which the various enterprise networks connect 637 as cooperating yet potentially competing entities. Within each 638 enterprise network there may be arbitrarily many hosts, routers and 639 networks (not shown in the diagram) that use addresses taken from 640 that enterprise network's RLOC space and over which both encapsulated 641 IP packets with (global-scoped) EID addresses and unencapsulated IP 642 packets with (enterprise-local) RLOC addresses can be forwarded. 644 Each enterprise network may encompass lower-tier networks; for 645 instance, the singleton EBR "W" in network E2 resides in a lower-tier 646 network (say E2.1), and (along with any of its attached devices) may 647 be considered as an enterprise unto itself. W sees Y3 and Y4 as 648 EBGs, which in turn see X5 and X6 as EBGs that connect to a common 649 provider network (in this case, the Internet). Each enterprise 650 network has one or more Endpoint identifier (EID) address prefixes 651 used for addressing nodes on edge networks. IRON/RANGER's map-and- 652 encaps approach separates the mapping of EIDs to RLOCs from the 653 Routing Information Base (RIB) in the Internet commons that are 654 assigned to EBR router interfaces. Not only does BGP in the Internet 655 commons only need to maintain state regarding Routing Locators 656 (RLOCs)in the Internet commons, it has fewer unique routes to 657 maintain because only routes to EBRs are needed; traffic engineering 658 can therefore be accommodated via the mapping database. 660 In Figure 5, enterprise network E2 represents a corporation that has 661 multiple locations and connections to multiple ISPs. The corporation 662 has recently merged with another corporation so that its internal 663 network has two disjoint RLOC address spaces, but neither of the 664 formerly separate entities can bear the burden of address 665 renumbering. Enterprise network E2 can use a suitably large IPv4 666 and/or IPv6 EID addressing range (that is distinct from any 667 enterprise-interior RLOC addressing range) to support end systems on 668 enterprise edge networks with no disruption to preexisting address 669 numbering. 671 As EBRs are deployed to connect enterprise networks together, 672 ordinary routers within the enterprise network continue to function 673 as-normal and deliver both ordinary and encapsulated packets across 674 the existing Internet infrastructure and the network's own RLOC 675 commons. Legacy IPv4 services that bind to RLOC addresses continue 676 to be supported even as EID-based services are rolled out. Where 677 legacy IP client and server are within the same RLOC address space, 678 they simply communicate by using RLOC-based routing across the 679 enterprise network commons. If client and server are not within the 680 same RLOC address space, they communicate through some form of 681 network address and/or protocol translation [RFC5720] Section 3.3.4 682 for details). EBRs from the various enterprise networks publish 683 their EID prefixes to an enterprise-specific mapping system, so that 684 other EBRs from the various enterprise networks can consult the 685 mapping system to receive the RLOC address of one or more EBRs that 686 serve the EID prefix. 688 As an example, when an end system connected to W in E2.1 has a packet 689 to send to node Z in enterprise network E3, W sends the packet to EBR 690 Y4 which encapsulates the packet in an outer IP packet with its own 691 source address and the RLOC address of the next-hop EBR as 692 destination - in this case, X6. X6 decapsulates the packet and looks 693 up the destination EID prefix, obtaining the RLOC of X7 as next-hop. 694 X6 then encapsulates the IPv6 packet in a packet with RLOC address X6 695 as source and X7 as destination. X7 decapsulates the packet on 696 receipt and forwards it via its enterprise-edge interface to node Z. 698 This example uses one thread out of many that are possible using 699 IRON/RANGER; see [RFC5720] and [RFC5558] for other options and 700 details. Many enterprise networks that use proxies and firewalls at 701 their border routers today will wish to maintain that control over 702 their enterprise borders, and the use of IRON/RANGER does not 703 preclude such configurations (for example, see Section 4.3). 705 4.2. Autonomous System Concerns 707 An enterprise network such as E2 in Figure 5 above can represent an 708 AS within the IP Topology Hierarchy. A possible configuration for 709 enterprise network E2 is for each of its enterprise components to 710 also be recursive ASs linked together using the IRON/RANGER 711 constructs. Such a configuration is increasingly commonplace today 712 for the networks of very large corporations (e.g., Boeing's corporate 713 enterprise network). These networks support an internal instance of 714 the Border Gateway Protocol (BGP) linking many corporate-internal ASs 715 and independent from the BGP instance which maintains the RIB within 716 the global Internet Default Free Zone (DFZ). Such configurations are 717 often motivated by scaling or administrative requirements. 719 Such a corporate entity is internally an Internet unto itself, albeit 720 with separate default routes leading to the true global Internet. 721 The enterprise network E2 therefore appears to the rest of the 722 Internet as if it were a traditional IP Topology Hierarchy AS. Since 723 IRON/RANGER supports recursion, each AS within such a network may 724 itself use BGP internally in place of an IGP, and can therefore also 725 internally be composed of a locally-internal Internet in a recursive 726 fashion. This enterprise-within-enterprise framework can recursively 727 be extended as broadly and as deeply as required in order to achieve 728 the specific requirements of the deployment (e.g., scaling, unique 729 administration, and/or functional compartmentalization). 731 4.3. Small Enterprise Concerns 733 Global enterprise networks operating at the autonomous system level 734 of the IP Topology Hierarchy include multiple geographical regions, 735 multiple ISPs, and complex internal structures which naturally 736 benefit from the application of IRON/RANGER techniques. However, all 737 other enterprise network instances (both large and small) can also be 738 served by IRON/RANGER. For example, Small and Home Office (SOHO) 739 networks may comprise only a few computers on a single network 740 segment or extend to larger configurations with security islands, 741 internal routers and switches, etc. 743 An important concern of the small enterprise network is the ability 744 to grow the network, change ISPs, or expand to more locations without 745 readdressing the existing network. Consider a small company that has 746 a single location in California. The ISP connection is via a router 747 that acts as Network Address Translator and firewall for the company. 748 Addresses of the few computers ("Wksta") are taken from the [RFC1918] 749 private address space. 751 ISP 752 -------|----- Wksta Wksta 753 | Firewall |_____________|____________| 754 | NAT | 755 ------------- 757 Figure 6: Simple SOHO network 759 This configuration has been adequate for the few employees performing 760 software development work, since there is no need to expose services 761 within the site to the outside world. But now a web presence is 762 required as product introduction approaches. The network manager 763 deploys an EBR either as a co-resident function on the existing NAT/ 764 firewall platform as depicted below, or on a separate platform. 766 The EBR has a provider-edge interface connected to the ISP, the 767 preexisting workstations, the preexisting enterprise-edge interfaces 768 connecting workstations, and enterprise-edge interfaces connecting 769 several network segments connected by routers that host web servers, 770 workstations and other enterprise network services. A VET interface 771 is configured over the new service network to allow the servers to be 772 addressed from the public Internet. 774 ISP 775 | 776 +------|-----+ 777 | <|-- 778 | VET2 < | 779 | <|--- 780 | | 781 | | Server Server 782 | VET1 <|--------|-----------|------- 783 | | 784 | +--------+ | Wksta Wksta 785 | |Firewall| |_____________|____________| 786 | | NAT | | 787 | +--------+ | 788 +------------+ 790 Figure 7: IRON/RANGER serving the small company 792 In this new configuration, the EBR maintains the services within a 793 "demilitarized zone (DMZ)" that is accessible from the public 794 Internet without exposing other corporate assets that are still 795 protected by the preexisting firewall/NAT functions. 797 Shortly afterward an infusion of venture capital allows acceleration 798 of the product development and marketing work by adding programmers 799 in Tokyo and sales offices in New York and London. These new 800 branches connect via Virtual Private Network (VPN) links across the 801 Internet, and a new VET interface (VET2) is configured over these 802 links to form a new sub-enterprise. 804 ISP 805 | 806 +------|-----+ 807 | <|------------London 808 | VET2 < | 809 | <|--------------------New York 810 | | 811 | | Server Server 812 | VET1 <|--------|-----------|------- 813 | | 814 | +--------+ | Wksta Wksta 815 | |Firewall| |_____________|____________| 816 | | NAT | | 817 | +--------+ | 818 +------------+ 820 Figure 8: IRON/RANGER for multiple locations 822 4.4. IPv4/IPv6 Transition and Coexistence 824 End systems and networks need to accommodate long-term support for 825 both IPv4 and IPv6. Requirements for transition include support for 826 IPv4 applications running over IPv4 protocol stacks, IPv4 827 applications over IPv6 stacks, IPv4 applications over dual stacks, 828 IPv6 or IPv4/IPv6 capable applications over both IPv6 and dual 829 stacks. Both encapsulation and translation will likely be needed to 830 allow applications, enterprises and providers to incorporate IPv6, 831 including all intermediate states, without global coordination or a 832 'flag day'. 834 The IRON/RANGER architectures facilitate the addition of IPv6 835 addressing to existing IPv4 end systems and routers (i.e., via dual- 836 stack) as well as the addition of IPv6 networks to the existing set 837 of IPv4 networks. IRON/RANGER (with VET and SEAL) make it possible 838 to carry packets originated in one protocol across network 839 infrastructure supporting another protocol or routing system. Figure 840 1 on page 8 shows how IRON/RANGER supports various combinations of 841 edge (EID) and core (RLOC commons) technologies, going beyond IP 842 version differences to include mixed security, management, and 843 addressing as well. 845 The IRON/RANGER architectures support end-to-end communications 846 across arbitrarily-long paths of concatenated enterprise networks 847 connected by EBRs. When IPv6 is used as Endpoint interface 848 Identifier (EID) space, each EBR can provision a globally unique set 849 of IPv6 EID prefixes without scaling limitations due to the expanded 850 IPv6 address space. For example, figure 9 shows a pair of end 851 systems 'H' and 'J' separated by an intervening set of enterprise 852 networks, where the path between 'H' and 'J' traverses the EBR path 853 'V->Y1->X2->X7->Z': 855 +------+ 856 | IPv6 | 857 |Server| 858 " " " " " " " "" " " " " " " " " " " " " " " " | S1 | 859 " " +--+---+ 860 " . . . . . . . . . . . . . . . " | 861 " . . . . . . " | 862 " . +----+ v +----+ v +----+ +----+ +-----+-------+ 863 " . | V += e =+ Y1 += e =+ X2 += =+ R2 +==+ Internet | 864 " . +-+--+ t +----+ t +----+ +----+ +-----+-------+ 865 " . | 1 . . 2 . . . " | 866 " . H . . . . v . " | 867 " . . . . . . . . . . . e . " +--+---+ 868 " . t . " | IPv4 | 869 " . . . . . . , . 3 . " |Server| 870 " . +----+ v +----+ . " | S2 | 871 " . | Z += e =+ X7 += . " +------+ 872 " . +-+--+ t +----+ . " 873 " . | 4 . . . " 874 " . J . . . . . " 875 " . . . . . . . " 876 " " 877 " " " " " " " " " " " " " " "" " " " " " " " 879 Figure 9: EBR Waypoint Navigation using IPv6 881 When each EBR in the path is assigned a unique set of IPv6 EID 882 prefixes (and registers these prefixes in the appropriate routing/ 883 mapping tables), IPv6 can be used for navigation purposes with each 884 EBR in the path seen as a waypoint for navigation. This is true even 885 if IPv4 is used as the enterprise-local Routing LOCator (RLOC) 886 address space, and there were many IPv4 hops on the path between each 887 pair of neighboring EBRs. 889 IRON/RANGER further provides a compatible framework for incorporating 890 supporting mechanisms including protocol translation, application- 891 layer aspects of IPv4/IPv6 transition discussed in [RFC4038] and DNS 892 issues for IPv6 from [RFC4472]. For instances where IPv4 893 applications remain in use, IRON/RANGER expects that IPv4<->IPv6 894 translation will be supported via network-based 895 [I-D.ietf-behave-v6v4-framework] and/or end system stack-based (e.g., 896 [RFC2767]) protocol translation systems. Figure 10 shows the NAT-PT- 897 equivalent translation in the VET router, and Figure 11 shows the 898 BIS-equivalent translation in end systems. These examples address 899 scenarios not mentioned in RFC 4852. 901 IPv4 App A IPv4 App B 902 _____________ _____________ 903 |_TCP or UDP__| |_TCP or UDP__| 904 |____IPv4_____| |____IPv4_____| 905 ______|______ _______|_____ 906 / \ / \ 907 | IPv4-Only | | IPv4-Only | 908 | Site 1 | | Site 2 | 909 \_____________/ \_____________/ 910 ______|______ ______|_______ 911 |____IPv4_____| _____________ |____IPv4_____| 912 |NAT-PT-equiv_| / \ |NAT-PT-equiv_| 913 |_TCP or UDP__| | Internet | |_TCP or UDP__| 914 |____IPv6_____| | (IRON/RANGER)| |____IPv6_____| 915 |__VET/SEAL___| \_____________/ |__VET/SEAL___| 916 \_______________/ \___________/ 918 Figure 10: Translation in Routers 920 In Figure 10, an IPv4 application on end system A operates normally 921 and the end system sends IPv4 packets on the IPv4-only site network. 922 The IPv4 packets are received by an Enterprise Border Router (EBR) 923 that translates them into IPv6 packets by a NAT-PT-equivalent 924 process. The EBR then encapsulates the packets into IPv4 and sends 925 them across the IRON/RANGER enabled Internet to Site 2 where they are 926 received and decapsulated by an EBR for Site 2. The EBR uses NAT-PT- 927 equivalent translation to translate the resulting IPv6 packet back to 928 an IPv4 packet that is delivered across the Site 2 IPv4-only network 929 to an IPv4 application on end system B. 931 IPv4 App A IPv4 App B 932 _____________ _____________ _____________ 933 |_TCP or UDP__| / \ |_TCP or UDP__| 934 |____BIS______| | Internet | |____BIS______| 935 |____IPv6_____| | (IRON/RANGER)| |____IPv6_____| 936 |__VET/SEAL___| \_____________/ |__VET/SEAL___| 937 \_______________/ \___________/ 939 Figure 11: BIS-style Translation in Dual-Stack End Systems 941 Figure 11 shows the simplified approach using a Bump-In the Stack 942 (BIS) translation process within dual-stack end systems ([RFC2767]). 943 In this case, the IPv4 application on dual-stack end system A forms 944 an IPv4 payload which is then transformed into an IPv6 packet within 945 the end system protocol stack itself. The IPv6 packet can then be 946 encapsulated and sent across the Internet to be decapsulated and sent 947 to the dual-stack end system hosting IPv4 application B. The BIS- 948 equivalent process on end system B reverses the translation, yielding 949 an IPv4 packet for consumption by the IPv4-only application. 951 Other issues besides IP protocol translation may arise during IPv4- 952 IPv6 transition; [RFC4038] points out issues including IPv4/IPv6 953 capable applications running on IPv4-only protocol stacks, DNS 954 responses that include addresses of both IP versions, and the 955 difficulty of supporting multiple application versions. It also 956 advises that applications be converted to dual support as a preferred 957 solution. These issues are outside the scope of this document. 959 4.5. Mobility and MANET 961 4.5.1. Global Mobility Management 963 Ubiquitous wireless access enables connection to network 964 infrastructure nearly anywhere. Vehicles and even persons can host 965 networks that move around with them. For example, commercial 966 aircraft networks include requirements for nomadic networks, local 967 mobility, and global mobility where the connection point between 968 airplane and ground station can move from one continent to another. 969 Mobile networks need to be able to use Provider-Independent (PI) as 970 well as Provider-aggregated (PA) address prefixes. Some applications 971 such as voice require rapid or seamless connection handoffs - also 972 known as session survivability. Internet routing should not be 973 unduly disrupted by mobility, so movement of mobile nodes or edge 974 networks should not cause large ripples of routing protocol traffic, 975 especially in the DFZ. 977 When an IRON/RANGER enterprise network is overlaid on the Internet, 978 mobile nodes or mobile routers (that connect arbitrarily complex edge 979 networks or enterprise networks) can move between different points of 980 attachment while remaining reachable and without creating excessive 981 routing churn. In a commercial airline scenario, an aircraft with a 982 mobile router would move between ground station points of attachment 983 (that may be on different continents) without readdressing of its 984 onboard networks. Figure 12 shows an aircraft transiting between 985 four different access points; two that are part of Air Communications 986 Service Provider (ACSP) 1, one in ACSP2 and the last directly to the 987 Air Navigation Service Provider (ANSP). ACSP1 and ACSP2 in this 988 example might be on different continents, so a traditional Mobile IP 989 Home Agent scheme , [RFC3775]would result in very inefficient paths 990 for one ACSP or the other. The Aero enterprise network is an overlay 991 that spans both continents and allows efficient paths by providing 992 multiple entry and exit points (only one, R2, is shown). 994 Aircraft - - - - - - ,.- - - - - -.- - -> 995 . , . . +------+ 996 . , . . | IPv6 | 997 . , . . |Server| 998 " ." " " ", "" " " ." " " " " .? " " " " " | S1 | 999 " . , . . " +--+---+ 1000 " . , . . " | 1001 " . ... . . . . . +----+ " | 1002 " . . . . . =+ X3 + " | 1003 " . v +--- + . v . . v +----+ ? | 1004 " . e =+ Y1 + . e . . e . +----+ +--------+ 1005 " . t +----+ . t +----+ . t . =+-R2-+==+Internet| 1006 " . 1 . . 2 =+ X2 + . 3 . +----+ +--------+ 1007 " . . . +----+ . . " | 1008 " . . . . . . . " +------+ 1009 " " | IPv4 | 1010 " " |Server| 1011 " - - vet 4 - - " | S2 | 1012 " " " " " " " " " " " " " "" " " " " " " | S2 | 1013 <-- Aero enterprise network --> +------+ 1015 Figure 12: Commercial Airplane Mobility 1017 When the plane moves between ground stations that are located within 1018 the ACSP1 enterprise network, no routing or mapping changes need be 1019 made outside ACSP1. Moreover, if link-layer multiplexing (as 1020 mentioned in section 3 above) is used then the VET interface network 1021 layer is unaware of the movement. When the point of access moves to 1022 ACSP2, no changes are made outside the aero enterprise network. When 1023 the aircraft moves between ground stations of the same parent 1024 enterprise network (as indicated by the two different links from the 1025 aircraft to ACSP1 in Figure 12), the aircraft announces its PI 1026 prefixes at its new point of attachment and withdraws them from the 1027 old. The worldwide Internet sees no change, and mapping system churn 1028 is confined to ACSP1, since the prefixes need not be announced or 1029 withdrawn within the parent aero enterprise network, i.e., the churn 1030 is isolated to lower tiers of the recursive hierarchy. This can be 1031 contrasted with the deprecated mobility solution previously fielded 1032 by Connexion, which propagated disruptive BGP changes into the 1033 Internet routing system to support mobile onboard networks. 1035 4.5.2. First-Responder Mobile Ad-Hoc Networks (MANETs) 1037 Many emerging network scenarios require autoconfiguration of Mobile 1038 Ad-Hoc Networks (MANETs). Where first responders need networking for 1039 communications and coordination between teams, IRON/RANGER allows 1040 each team or agency to quickly stand up a network and then use the 1041 autoconfiguration described in [RFC5558] to coordinate address/prefix 1042 autoconfiguration and discover border routers needed for teams and 1043 agencies to interconnect. 1045 For example, Figure 13 shows how police units arriving on a scene 1046 with no network infrastructure can create a wireless network using 1047 vehicle-mounted 802.11 hotspots with one or more cellular, 802.16, or 1048 satellite links in order to reach the Internet. In this example, the 1049 California Highway Patrol sets up an incident management center with 1050 a satellite link to the Internet and vet1 serving network L1. The 1051 Los Angeles County Sheriff team sets up network L1.1 at their field 1052 headquarters and the Altadena police force creates the L1.2 network 1053 with their mobile units. R2 is the router that serves as an EBG for 1054 border routers X3 and X4, which connect networks L1.2 and L1.1 1055 respectively. X3 serves vet3 and X4 serves vet2. 1057 In like manner, the Angeles National Forest creates enterprise 1058 network F1, with the San Gabriel Ranger District setting up 1059 enterprise network F1.1 and the Fire Response Team Enterprise Network 1060 F1.2. R1 and R2 discover one another and become peer EBRs across the 1061 Internet by means of manual configuration. In network L1, individual 1062 PI address prefixes are announced from L1.2 and L1.1 to L1 and R2 1063 advertises them to the satellite ISP. R1 receives a PA prefix from 1064 its WiMAX provider and delegates parts of the prefix to X1 and X2. 1065 R2 also runs an IGP with R1, advertising the PI prefixes to R1 and 1066 learning the PA prefixes there. 1068 +------+ 1069 | IPv6 | 1070 |Server| 1071 " " " " " " " "" " " " " " " " " " " " " " " " | S1 | 1072 " Law Enforcement Enterprise Network " +--+---+ 1073 " 2001:DB8:10::/56 (PI) ----------------> " | 1074 " . . . . . . . +--- + . . . . " | 1075 " . =+ X3 +===========. . " +-----+-------+ 1076 " . +----+ v +--- + . v +----+ | + 1077 " . | V += e . . . . e =+ R2 +==+ | 1078 " . +-+--+ t . . +----+ t +----+ | | 1079 " . | 3 . . vet2 + X4 += 1 . " | | 1080 " . H1 . . +----+ . " | | 1081 " . . . . . . . . . . . . . . " | | 1082 " " | | 1083 " 10/8 10/8 10/8 " | | 1084 " " " " " " " " " " " " " " "" " " " " " " " | Internet | 1085 | | 1086 " " " " " " " "" " " " " " " " " " " " " " " " | | 1087 " USDA Forest Service Enterprise Network " | | 1088 " <----------------- 2001:DB8::/40 (PA) " | | 1089 " . . . . . . . +--- + . . . . " | | 1090 " . =+ X1 +===========. . " | | 1091 " . +----+ v +--- + . v +----+ | | 1092 " . | J += e . . . . e =+ R1 +==+ | 1093 " . +-+--+ t . . +----+ t +----+ | | 1094 " . | 6 . . vet5 + X2 += 4 . " +-----+-------+ 1095 " . H2 . . +----+ . " | 1096 " . . . . . . . . . . . . . . " +--+---+ 1097 " " | IPv4 | 1098 " 10/8 10/8 10/8 " |Server| 1099 " " " " " " " " " " " " " " "" " " " " " " " | S2 | 1100 +--+---+ 1102 Figure 13: First-Responder MANET 1104 4.5.3. Tactical Military MANETs 1106 Military networks reflect well-defined policy requirements that 1107 differ in many ways from civilian networks. The military's 1108 information security requirements result in information being labeled 1109 into specific classifications. The Bell-LaPadula model 1110 [Bell-LaPadula] provides a mechanism to extend information security 1111 policy into networked environments. This extension creates 1112 communications security (COMSEC), whose routing and addressing 1113 elements are cleanly supported by IRON/RANGER concepts. 1115 Figure 3 on page 10 shows that IRON/RANGER supports creation of a VET 1116 interface between the Enterprise Interior (network) Interface of two 1117 Enterprise Border Routers (EBR) located within separate enterprise 1118 networks, A and B. When this concept is applied to enterprise 1119 networks operating above the subnetwork level of the IP Topology 1120 Hierarchy, then this VET interface uses IP-in-IP encapsulation. This 1121 corresponds with a popular COMSEC approach (IPsec - [RFC4301]). When 1122 this same IRON/RANGER concept is applied to enterprise networks 1123 operating at the subnetwork level of the IP Topology Hierarchy then 1124 this corresponds to an older form of COMSEC (Link Layer Encryption). 1125 When the same IRON/RANGER concept is applied to enterprise networks 1126 being singleton EBR nodes (i.e., the interface level of the IP 1127 Topology Hierarchy) then this corresponds to a third military COMSEC 1128 alternative (Link Encryption). 1130 The previous paragraph shows the flexibility of the IRON/RANGER 1131 architecture to describe COMSEC approaches in terms of IP Topology 1132 Hierarchy structured relationships. The power of the IRON/RANGER 1133 architecture becomes apparent when one recognizes that each of the 1134 entities in Figure 3 may themselves be simple or complex network 1135 structures operating at any specific level of the IP Topology 1136 Hierarchy. (Complex structures refer to architectures that have been 1137 extended by IRON/RANGER recursion.) For example, the commons in the 1138 figure may itself be an interface, a subnetwork, an autonomous 1139 system, or an Internet. Enterprise networks A and B can be a single 1140 end system, a subnetwork, an autonomous system or an Internet. 1142 Tactical military MANETs differ from traditional networks in many 1143 ways, the most obvious being the high mobility of tactical 1144 deployments and self-forming-network attributes of MANETs themselves. 1145 Because each networked tactical entity supports a radio/router, the 1146 numbers of routers within military MANETs can be orders of magnitude 1147 more numerous (denser) than traditional civilian networks. This 1148 means that even small deployments have comparatively large router 1149 populations when compared to non-MANET deployments. Larger router 1150 populations directly create greater sensitivity to protocol 1151 scalability issues. Router scalability issues are further 1152 exacerbated because IP protocols react unfavorably to signal 1153 intermittence, which effectively dampens and constrains router 1154 scaling even when mitigation techniques are employed. Signal 1155 intermittence itself is a characteristic of mobility and the radio 1156 signal propagation attributes of local deployment environments (e.g., 1157 issues as terrain, foliage, buildings, weather, distance, etc.). War 1158 fighting also encourages war fighters to locate into more defensible 1159 terrain features, many of which naturally reduce radio signal 1160 propagation, further increasing the probability of signal 1161 intermittence. 1163 IRON/RANGER recursion enables MANET networks that naturally encourage 1164 route aggregation and scaling through simple "plug and play" 1165 hierarchical arrangements that parallel organizational structures and 1166 do not entail complex manual configurations. For example, a MANET 1167 autonomous system may benefit from IRON/RANGER recursion by being 1168 physically comprised of enterprise networks that are autonomous 1169 systems themselves. This relationship can be recursively extended 1170 vertically as deep as required in order to create route aggregation 1171 between entities having common mission assignments at differing 1172 levels of abstraction. Since MANET routing is an active research 1173 topic, it is helpful to realize that these structures may or may not 1174 use routing protocols similar to their civilian IP Topology Hierarchy 1175 peers. For example, because of the behavior of BGP within highly 1176 mobile environments, the Exterior Gateway Protocol (EGP) used to link 1177 ASs may or may not be BGP and, if it is BGP, it may have unusual 1178 timer settings. However, whatever IGP and EGP is used, IRON/RANGER 1179 constructs can increase route aggregation between entities sharing 1180 common mission assignments to enable route scaling. 1182 Tactical Military MANETs often have requirements to communicate with 1183 stationary infrastructures. By localizing mobility into an 1184 enterprise network then the specific mobility-friendly protocols can 1185 be localized and their aggregation results presented to the 1186 stationary network using a protocol supported by the stable network. 1187 This also reduces the impact of mobility upon routing and addressing 1188 systems as reported to the stationary infrastructure. Mobility 1189 induced route fluctuations (e.g., routing flaps) can still occur but 1190 their impact can be dampened if IRON/RANGER constructs are used to 1191 localize them in lower tiers of the IP Topology Hierarchy. For 1192 example, enterprise network A in Figure 3 can be a military MANET and 1193 enterprise network B may be a stationary military entity. Recall 1194 that enterprise networks A and B interface at a specific IP Topology 1195 Hierarchy level but they may be physically extended by IRON/RANGER 1196 mechanisms. For example, enterprise network A can be a MANET 1197 enterprise that is physically a network-of-networks Internet that 1198 interfaces to enterprise network B as if it were an Autonomous 1199 System. This gives enterprise network B a more stable and aggregated 1200 view of the enterprise network A Internet than would be the case if 1201 it were directly aware of A's various sub-enterprise components. 1203 Another key distinctive of Tactical Military networks is that, 1204 because radio networks operate at a different classification level 1205 than the data they convey, tactical military networks have several 1206 orders of magnitude more COMSEC devices than do equivalently sized 1207 stationary military deployments (i.e., the number of COMSEC devices 1208 is a function of the number of mobile war-fighting entities). This 1209 can create significant scalability issues within the overlay COMSEC 1210 network relationships themselves. COMSEC scaling problems are 1211 manifested in several dimensions. It is important to recognize, 1212 however, that just as IRON/RANGER recursion was used vertically to 1213 create IP Topology enterprise-within-enterprise structures in order 1214 to improve routing aggregation and scaling, so IRON/RANGER recursion 1215 allows for authorization of route optimized transactions between peer 1216 enterprises (within the same IP Topology Hierarchy level) to improve 1217 COMSEC aggregation and scaling of the network overlay system. The 1218 IRON/RANGER use of VET also combines with the Subnetwork 1219 Encapsulation and Adaptation Layer (SEAL) to provide robust packet 1220 identification and maximum transmission unit (MTU) link adaptation 1221 services over tunnels. These capabilities protect against both 1222 source address spoofing and black holes caused by MTU limitations. 1224 4.6. Provider Concerns 1226 Network providers must have a way to support the protocol transitions 1227 and network types mentioned above and still remain reliable and 1228 financially sound. The IRON/RANGER architecture provides ways to 1229 support general Internet Service Providers (ISPs), cellular operator 1230 networks, and specialized networks such as the Aeronautical 1231 Telecommunications Network (ATN). 1233 4.6.1. ISP Networks 1235 Internet service provider networks provide a commons for the 1236 connection of Customer Premises Equipment (CPE) routers [I-D.ietf- 1237 v6ops-ipv6-cpe-router] that connect arbitrarily-complex customer 1238 networks. This is true whether the ISP permits direct customer-to- 1239 customer communications, or whether all communications are forwarded 1240 through ISP Provider Edge (PE) equipment. 1242 The ISP commons must potentially support hundreds of thousands of CPE 1243 routers (or more), hence the ISP may be obliged to assign private 1244 IPv4 address allocations (i.e., instead of public) as RLOCs for CPE 1245 routers. This gives rise to a "nested NATs" scenario, which can 1246 increase the overall brittleness brought on by NAT traversal. 1248 To address this brittleness, the ISP can deploy "Carrier Grade NATs" 1249 (CGNs) [I-D.jiang-incremental-cgn] that provide a second level of 1250 RLOC address translation on the path from the CPE to the Internet. 1251 When the CGNs are also configured as EBGs, CPE routers can discover 1252 them as default routers for reaching EID-based services using the EBG 1253 discovery mechanisms specified in VET. 1255 Scenarios and Analysis for Introducing IPv6 into ISP Networks 1256 [RFC4029] discusses both ISP backbone network and customer connection 1257 transition considerations, however this document considers router-to- 1258 router tunneling use cases. Therefore the ISATAP mechanism (which 1259 only supports host-to-router or host-to-host tunneling) is not 1260 mentioned as a candidate technology. Early point solutions (e.g., 1261 TSP, STEP, etc.) recommended. This document suggests that IRON, 1262 RANGER, VET and SEAL would also be suitable solutions in these 1263 networks. 1265 4.6.2. Cellular Operator Networks 1267 [RFC4215] provides a (dated) Analysis on IPv6 Transition in Third 1268 Generation Partnership Project (3GPP) Networks. It envisions an 1269 extended period of support for both IPv4 and IPv6 protocols in the 1270 operator network. User Equipment (UE) uses the Packet Data Protocol 1271 (PDP) context to establish tunnels through the operator network to a 1272 Gateway GPRS Support Node (GGSN). IRON/RANGER could be used in 3GPP 1273 transition; when the UE uses IPv6, and the PDP context is established 1274 across an IPv4 provider network, the UE can configure itself as an 1275 EBR and contact the GGSN (as an IRON/RANGER EBG) through VET 1276 tunneling. 1278 Other [RFC4215] scenarios examine IPv4-only UEs, IPv6-only UEs, and 1279 various combinations of IPv4 and IPv6 within the operator network. 1280 Also to be considered are scenarios in which the UE is configured as 1281 a router or bridge that connects an end system such as a laptop 1282 computer. In that case, the UE could be the first-hop router/bridge 1283 into the cellular provider network, and the laptop computer could be 1284 configured as an EBR in the IRON/RANGER model. Again, the GGSN or a 1285 device reachable through the GGSN could serve as a IRON/RANGER EBG. 1287 4.6.3. Aeronautical Telecommunications Network (ATN) 1289 The Aeronautical Telecommunications Network (ATN) is currently based 1290 on the OSI and IPv4 protocols and is deployed only in limited areas. 1291 The future ATN under consideration within the civil aviation industry 1292 will be IPv6-based. The IP variant of ATN is expected to take the 1293 form of a worldwide enterprise network that internally comprises an 1294 aeronautical-only Internet which has additional external interfaces 1295 to the global Internet. Within the ATN, there may be many Air 1296 Communications Service Provider (ACSP) and Air Navigation Service 1297 Provider (ANSP) networks that are internally organized either as 1298 autonomous systems or internets within the ATN, i.e., as depicted in 1299 figure 5 on page 13. Each of these entities may themselves be 1300 further internally sub-divided into lower-tier enterprise networks 1301 organized as regional, organizational, or functional compartments. 1302 It is important to note that while ACSPs and ANSPs within the ATN 1303 will share a common objective of safety-of-flight for civil aviation 1304 services, enterprise networks may have competing business, social, or 1305 political interests which require that components be distinct ASs. 1306 The IRON/RANGER principles therefore support collaborative objectives 1307 while allowing very diverse local policy distinctions. In this 1308 manner entities that do not trust each other can create collaborative 1309 infrastructures to achieve common goals. 1311 Operational associations like this will characterize many future 1312 deployments, including the US Department of Defense's Global 1313 Information Grid (GIG). In particular, although the routing and 1314 addressing arrangements of all enterprise networks require a mutual 1315 level of cooperative active management at a certain level, scaling 1316 issues, security policy differences, free market forces, 1317 organizational differences, political distinctions, or other factors 1318 may create internal competition among entities that otherwise share 1319 common goals. This will require different enterprise networks within 1320 that association to be separated into distinct ASs that are linked 1321 within their own functional Internet relationship. 1323 The ATN illustrates transition from OSI protocols to IPv6. It must 1324 support mobility (see Section 4.5.1) and it serves many government 1325 and private entities which cooperate to provide safe and efficient 1326 air travel while often competing with one another. One possible way 1327 to meet these needs with IRON/RANGER is to create an overlay using IP 1328 in IP tunneling across the Internet, as illustrated in Figure 14. 1329 The aero overlay forms an enterprise network, so that inner packets 1330 from ACSP, ANSP, or AOC edge networks that travel between VET 1331 interfaces on EBRs see their passage across the Internet as only one 1332 hop. 1334 _...--------------------------------------..._ 1335 / \ 1336 ( IPv4 Internet ) 1337 -...________________________________________...- 1338 | / | \ | 1339 | / | \ | 1340 _...--------------------------------------..._ 1341 / \ 1342 ( Aero Overlay ) 1343 -...________________________________________...- 1344 . . . . . . 1345 . . . . . . 1346 _...-------.._ _...-------.._ _...-------.._ 1347 / \ / \ / \ 1348 ( ACSP1 ) ( ANSP ) ( ACSP2 ) 1349 -...________...- -...________...- -...________...- 1351 Figure 14: Aeronautical Overlay 1353 Each Aeronautical Communications Service Provider (ACSP), and 1354 Aeronautical Navigation Service Provider (ANSP) constitute an 1355 enterprise network recursively nested below the aero overlay. 1356 Relationships between the various enterprise networks can vary from 1357 slight to tight integration. In the example, the ACSP and ANSP might 1358 choose to exchange full routing information for their edge networks 1359 using a coordinated global-scope RLOC address space across which ACSP 1360 and ANSP EBRs can route traffic without further mapping lookups or 1361 re-encapsulation at intermediate EBRs. Other enterprise networks 1362 that have the aero network as a common parent may not have any 1363 knowledge of each other's interior routing but will merely forward 1364 packets on a default route up to the aero overlay. 1366 The ATN is currently an OSI network but is projected to transition to 1367 IPv6 over time. IRON/RANGER can bridge OSI networks together across 1368 the IPv4 (or IPv6) Internet, or bridge IPv4 or IPv6 networks across 1369 an OSI network. A pair of EBRs that have IP interfaces on a common 1370 enterprise network (whether it is the Internet, the aero network, or 1371 another parent or child enterprise network) can support 1372 communications between their attached OSI edge networks by looking up 1373 ISO network service access point (NSAP) addresses [IS8348] instead of 1374 IP addresses for RLOC mappings. OSI ConnectionLess Network Protocol 1375 (CLNP) [IS8473] packets can therefore be encapsulated within IPv4 (or 1376 IPv6) headers for transmission across an Internet Protocol enterprise 1377 network. Some OSI networks may transition to IPv6 addressing 1378 [RFC4548] while applications are adapted by using RFC 2126 [RFC2126] 1379 to carry OSI upper layers over TCP/IP, with the resulting IP packets 1380 carried across and between IRON/RANGER enterprises in the normal way. 1381 Another approach is to use subnetwork convergence to tunnel OSI 1382 network protocol data units over Internet protocol networks 1383 [RFC1070]. 1385 Figure 15 depicts an ACSP and ANSP connected via an IPv4 aero 1386 overlay. Host H represents a system onboard an aircraft that has a 1387 wireless link to the ACSP, connected via an enterprise-edge network 1388 interface on EBR F within the ACSP enterprise network. H resides on 1389 an IPv6 edge network, and its EID is taken from the ACSP IPv6 prefix. 1390 H needs to send a query to server S in the ANSP enterprise network. 1391 H starts by sending a DNS query to the server at G and in return it 1392 receives the EID of server S. H then creates an IPv6 packet with 1393 source EID(H) and destination EID(S) and forwards it to its default 1394 router, F. F consults G for a mapping from EID(S) to the appropriate 1395 RLOC. In this case, EBR F encapsulates the IPv6 packet in an IPv6 1396 outer packet and forwards the packet to its default EBG, A. A 1397 decapsulates the packet and looks up the destination EID(S) by 1398 querying the DNS server at EBR B. B returns a mapping with the RLOC 1399 of EBR E. A encapsulates the IPv6 inner packet in an IPv4 outer 1400 packet with source RLOC(A) and destination RLOC(E). The packet is 1401 forwarded via EBRs C and D in the aero overlay until it reaches E, 1402 where it is decapsulated. E consults its cache of EID/RLOC mappings 1403 and finds that the EBR for S is N. E encapsulates the packet in an 1404 IPv6 packet with source RLOC(E) and destination RLOC(N). When the 1405 packet reaches N, it is decapsulated and the inner IPv6 packet is 1406 forwarded on the edge network to the server, S. 1408 _...--------------------------------------..._ 1409 / (B) (D) \ 1410 ( Aero Overlay (IPv4) ) 1411 -...________________________________________...- 1412 . . . 1413 (A) (C) . 1414 . . . 1415 _...------------------------.._ (E) 1416 / \ . 1417 / (F) \ . 1418 ( [H] ACSP (IPv6) ) . 1419 \ (G) / . 1420 \...__________________________... . 1421 . 1422 _...------------------------.._ 1423 / \ 1424 / (M) (N) \ 1425 ( ANSP (IPv6) ) 1426 \ [S] / 1427 \...__________________________... 1429 Figure 15: Packet Forwarding for Aeronautical Networks 1431 4.6.4. Unmanaged Networks 1433 Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks 1434 [RFC3904] considers four cases for support of IPv6-enabled routers 1435 and end systems connected to an ISP network via a gateway: 1437 a. a gateway which does not provide IPv6 at all; 1439 b. a dual-stack gateway connected to a dual-stack ISP; 1441 c. a dual-stack gateway connected to an IPv4-only ISP; and 1443 d. a gateway connected to an IPv6-only ISP. 1445 Case a is typified by the widespread practice of customer networks 1446 using IPv4-only NAT boxes to connect to their service providers. 1447 IRON/RANGER do not address this scenario directly, however the TEREDO 1448 mechanism [RFC4380] can provide a sufficient solution in many cases. 1450 Case d is a scenario that has not yet seen widespread adoption. In 1451 this scenario, the customer network could be configured as IPv6 only 1452 and the deployment could be considered as an IPv6-only extension to a 1453 IRON/RANGER enterprise-edge network. End systems in this scenario 1454 would still require support for legacy IPv4-only applications, and if 1455 the customer network contained IPv4-only routers and end systems the 1456 IRON/RANGER encapsulation mechanisms would still apply. 1458 Cases b and c correspond to the scenario of the customer gateway to 1459 the ISP becoming an IPv6 router. In that case, the gateway could 1460 become an IRON/RANGER EBR, and the scenario becomes the same as the 1461 SOHO network use cases discussed in Section 4.3. In particular, when 1462 traditional home network IPv4 NAT boxes are updated to also support 1463 IPv6 routing, the NAT box becomes an IRON/RANGER EBR. 1465 5. Summary 1467 The Internet today can be considered as a giant enterprise network, 1468 with nodes in the Internet addressed from the public IPv4 address 1469 space as RLOCs. Due to the 32-bit addressing limitations of IPv4, 1470 however, continued expansion has occurred through the widespread 1471 deployment of IPv4 Network Address Translators (NATs) while IPv6 has 1472 yet to see wide adoption. 1474 In many senses, however, this has resulted in a degenerate 1475 manifestation of the network-of-networks model originally envisaged, 1476 e.g., in the CATENET model. Indeed, these NATed domains have the 1477 external appearance of being a simple host within the global Internet 1478 RLOC space even though they may be proxying for arbitrarily large 1479 networks of end systems. The end result is a loss of transparency in 1480 the end-to-end model; it is no longer true that any node in the 1481 Internet can directly address any other node. 1483 By adopting the principle of using RLOCs as the local addressing 1484 range and EIDs as the global addressing range, IRON/RANGER enables a 1485 true network-within-network (or enterprise-within-enterprise) 1486 framework. This is true even across a wide array of deployment 1487 scenarios as documented here, and even for networks-within-networks 1488 that may be recursively nested to an arbitrary depth. IRON/RANGER 1489 therefore brings a unifying architecture applied consistently across 1490 all layers of recursion, rather than a mixed bag of point solutions 1491 that may or may not be mutually compatible. 1493 If the IRON/RANGER approach is adopted, the next generation can be 1494 arbitrarily scalable while simultaneously supporting provider 1495 independence, mobility, multihoming and security. 1497 6. Limitations 1499 The scenarios discussed in this document have not closely examined 1500 future growth of the native IPv6 and IPv4 Internets independently of 1501 any growth in IRON/RANGER overlay networking. For example, it is 1502 likely that current-day major Internet services that talk to millions 1503 of customers simultaenously (e.g., google, yahoo, ebay, amazon, etc.) 1504 will continue to be served best by native Internet routing and 1505 addressing rather than by overlay network arrangements that require 1506 dynamic mapping state coordination. A study of the balance between 1507 growth in the native Internet for supporting large Internet services 1508 and growth in overlay networks for supporting smaller multihomed end 1509 user networks is topic for ongoing efforts including IRON 1510 [I-D.templin-iron]. 1512 7. IANA Considerations 1514 There are no IANA considerations for this document. 1516 8. Security Considerations 1518 Security considerations are addressed in [RFC5720], [RFC5558], and 1519 [RFC5320]. While the IRON/RANGER architecture does not in itself 1520 address security considerations, it proposes an architectural 1521 framework for functional specifications that do. Security concerns 1522 with tunneling along with recommendations that are compatible with 1523 the IRON/RANGER architecture are found in 1524 [I-D.ietf-v6ops-tunnel-security-concerns]. Security considerations 1525 for specific use cases are discussed there. 1527 9. Acknowledgements 1529 This work was inspired by the original architectural principles of 1530 the Internet supplemented with "lessons learned" by many peers from 1531 actual Internet deployments and experience developing encapsulation 1532 protocols. The editors acknowledge that they are furthering work 1533 initiated by many. 1535 10. References 1537 10.1. Normative References 1539 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1540 September 1981. 1542 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1543 (IPv6) Specification", RFC 2460, December 1998. 1545 10.2. Informative References 1547 [Bell-LaPadula] 1548 Bell, D. and L. LaPadula, "Secure Computer Systems: 1549 Mathematical Foundations and Model", October 1974. 1551 [CATENET] Pouzin, L., "A Proposal for Interconnecting Packet 1552 Switching Networks", May 1974. 1554 [Huston-end] 1555 Huston, G., "The End of the (IPv4) World is Nigher", 1556 July 2007. 1558 [I-D.carpenter-renum-needs-work] 1559 Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 1560 still needs work", draft-carpenter-renum-needs-work-05 1561 (work in progress), January 2010. 1563 [I-D.farinacci-lisp] 1564 Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 1565 "Locator/ID Separation Protocol (LISP)", 1566 draft-farinacci-lisp-12 (work in progress), March 2009. 1568 [I-D.francis-intra-va] 1569 Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and 1570 L. Zhang, "FIB Suppression with Virtual Aggregation", 1571 draft-francis-intra-va-01 (work in progress), April 2009. 1573 [I-D.ietf-behave-v6v4-framework] 1574 Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 1575 IPv4/IPv6 Translation", 1576 draft-ietf-behave-v6v4-framework-09 (work in progress), 1577 May 2010. 1579 [I-D.ietf-v6ops-tunnel-security-concerns] 1580 Hoagland, J., Krishnan, S., and D. Thaler, "Security 1581 Concerns With IP Tunneling", 1582 draft-ietf-v6ops-tunnel-security-concerns-02 (work in 1583 progress), March 2010. 1585 [I-D.irtf-rrg-recommendation] 1586 Li, T., "Recommendation for a Routing Architecture", 1587 draft-irtf-rrg-recommendation-08 (work in progress), 1588 May 2010. 1590 [I-D.jen-apt] 1591 Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and 1592 L. Zhang, "APT: A Practical Transit Mapping Service", 1593 draft-jen-apt-01 (work in progress), November 2007. 1595 [I-D.jiang-incremental-cgn] 1596 Jiang, S. and D. Guo, "An Incremental Carrier-Grade NAT 1597 (CGN) for IPv6 Transition", draft-jiang-incremental-cgn-00 1598 (work in progress), March 2009. 1600 [I-D.templin-iron] 1601 Templin, F., "The Internet Routing Overlay Network 1602 (IRON)", draft-templin-iron-01 (work in progress), 1603 April 2010. 1605 [IEN48] Cerf, V., "The Catenet Model for Internetworking", 1606 July 1978. 1608 [IS8348] International Organization for Standardization, 1609 International Electrotechnical Commission, "Open Systems 1610 Interconnection -- Network service definition", 2002. 1612 [IS8473] International Organization for Standardization, 1613 International Electrotechnical Commission, "Protocol for 1614 providing the connectionless-mode network service: 1615 Protocol specification", 1998. 1617 [RFC1035] Mockapetris, P., "Domain names - implementation and 1618 specification", STD 13, RFC 1035, November 1987. 1620 [RFC1070] Hagens, R., Hall, N., and M. Rose, "Use of the Internet as 1621 a subnetwork for experimentation with the OSI network 1622 layer", RFC 1070, February 1989. 1624 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1625 Communication Layers", STD 3, RFC 1122, October 1989. 1627 [RFC1380] Gross, P. and P. Almquist, "IESG Deliberations on Routing 1628 and Addressing", RFC 1380, November 1992. 1630 [RFC1753] Chiappa, J., "IPng Technical Requirements Of the Nimrod 1631 Routing and Addressing Architecture", RFC 1753, 1632 December 1994. 1634 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1635 E. Lear, "Address Allocation for Private Internets", 1636 BCP 5, RFC 1918, February 1996. 1638 [RFC1955] Hinden, R., "New Scheme for Internet Routing and 1639 Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. 1641 [RFC2126] Pouffary, Y. and A. Young, "ISO Transport Service on top 1642 of TCP (ITOT)", RFC 2126, March 1997. 1644 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1645 RFC 2131, March 1997. 1647 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1648 Domains without Explicit Tunnels", RFC 2529, March 1999. 1650 [RFC2767] Tsuchiya, K., HIGUCHI, H., and Y. Atarashi, "Dual Stack 1651 Hosts using the "Bump-In-the-Stack" Technique (BIS)", 1652 RFC 2767, February 2000. 1654 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 1655 February 2000. 1657 [RFC3194] Durand, A. and C. Huitema, "The H-Density Ratio for 1658 Address Assignment Efficiency An Update on the H ratio", 1659 RFC 3194, November 2001. 1661 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1662 and M. Carney, "Dynamic Host Configuration Protocol for 1663 IPv6 (DHCPv6)", RFC 3315, July 2003. 1665 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1666 August 2002. 1668 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1669 in IPv6", RFC 3775, June 2004. 1671 [RFC3904] Huitema, C., Austein, R., Satapati, S., and R. van der 1672 Pol, "Evaluation of IPv6 Transition Mechanisms for 1673 Unmanaged Networks", RFC 3904, September 2004. 1675 [RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. 1676 Savola, "Scenarios and Analysis for Introducing IPv6 into 1677 ISP Networks", RFC 4029, March 2005. 1679 [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. 1680 Castro, "Application Aspects of IPv6 Transition", 1681 RFC 4038, March 2005. 1683 [RFC4057] Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057, 1684 June 2005. 1686 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 1687 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 1688 September 2005. 1690 [RFC4215] Wiljakka, J., "Analysis on IPv6 Transition in Third 1691 Generation Partnership Project (3GPP) Networks", RFC 4215, 1692 October 2005. 1694 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1695 Internet Protocol", RFC 4301, December 2005. 1697 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM 1698 Mode with IPsec Encapsulating Security Payload (ESP)", 1699 RFC 4309, December 2005. 1701 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1702 Network Address Translations (NATs)", RFC 4380, 1703 February 2006. 1705 [RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational 1706 Considerations and Issues with IPv6 DNS", RFC 4472, 1707 April 2006. 1709 [RFC4548] Gray, E., Rutemiller, J., and G. Swallow, "Internet Code 1710 Point (ICP) Assignments for NSAP Addresses", RFC 4548, 1711 May 2006. 1713 [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local 1714 Multicast Name Resolution (LLMNR)", RFC 4795, 1715 January 2007. 1717 [RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D. 1718 Green, "IPv6 Enterprise Network Analysis - IP Layer 3 1719 Focus", RFC 4852, April 2007. 1721 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1722 Address Autoconfiguration", RFC 4862, September 2007. 1724 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1725 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1726 March 2008. 1728 [RFC5320] Templin, F., "The Subnetwork Encapsulation and Adaptation 1729 Layer (SEAL)", RFC 5320, February 2010. 1731 [RFC5558] Templin, F., "Virtual Enterprise Traversal (VET)", 1732 RFC 5558, February 2010. 1734 [RFC5579] Templin, F., "Transmission of IPv4 Packets over Intra-Site 1735 Automatic Tunnel Addressing Protocol (ISATAP) Interfaces", 1736 RFC 5579, February 2010. 1738 [RFC5720] Templin, F., "Routing and Addressing in Networks with 1739 Global Enterprise Recursion (RANGER)", RFC 5720, 1740 February 2010. 1742 [V4pool] Hain, T., "The IPv4 Address Pool Projection", April 2009. 1744 Authors' Addresses 1746 Steven W. Russert (editor) 1747 Boeing Research & Technology 1748 P.O. Box 3707 MC 7L-49 1749 Seattle, WA 98124 1750 USA 1752 Email: srussert3561@charterinternet.com 1754 Eric W. Fleischman (editor) 1755 Boeing Research & Technology 1756 P.O. Box 3707 MC 7L-49 1757 Seattle, WA 98124 1758 USA 1760 Email: eric.fleischman@boeing.com 1762 Fred L. Templin (editor) 1763 Boeing Research & Technology 1764 P.O. Box 3707 MC 7L-49 1765 Seattle, WA 98124 1766 USA 1768 Email: fltemplin@acm.org