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