idnits 2.17.1 draft-templin-ranger-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 26, 2009) is 5294 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'PREF' is mentioned on line 932, but not defined == Missing Reference: 'ENCAPS' is mentioned on line 943, but not defined == Unused Reference: 'RFC0791' is defined on line 1047, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 1050, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-lisp' is defined on line 1068, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-06) exists of draft-arkko-townsley-coexistence-03 == Outdated reference: A later version (-24) exists of draft-ietf-lisp-05 == Outdated reference: A later version (-04) exists of draft-ietf-v6ops-tunnel-security-concerns-01 == Outdated reference: A later version (-05) exists of draft-russert-rangers-01 == Outdated reference: A later version (-68) exists of draft-templin-intarea-seal-07 == Outdated reference: A later version (-40) exists of draft-templin-intarea-vet-04 -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 4423 (Obsoleted by RFC 9063) Summary: 2 errors (**), 0 flaws (~~), 13 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin, Ed. 3 Internet-Draft Boeing Phantom Works 4 Intended status: Informational October 26, 2009 5 Expires: April 29, 2010 7 Routing and Addressing in Next-Generation EnteRprises (RANGER) 8 draft-templin-ranger-09.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on April 29, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 RANGER is an architectural framework for scalable routing and 47 addressing in next generation enterprise networks. The term 48 "enterprise network" within this context extends to a wide variety of 49 use cases and deployment scenarios, where an "enterprise" can be as 50 small as a SOHO network, as dynamic as a Mobile Ad-hoc Network, as 51 complex as a multi-organizational corporation, or as large as the 52 global Internet itself. Such networks will require an architected 53 solution for the coordination of routing and addressing plans with 54 accommodations for scalability, provider-independence, mobility, 55 multi-homing and security. These considerations are particularly 56 true for existing deployments, but the same principles apply even for 57 clean-slate approaches. The RANGER architecture addresses these 58 requirements, and provides a comprehensive framework for IPv6/IPv4 59 coexistence. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. The RANGER Architecture . . . . . . . . . . . . . . . . . . . 7 66 3.1. Routing and Addressing . . . . . . . . . . . . . . . . . . 7 67 3.2. The Enterprise-within-Enterprise Framework . . . . . . . . 8 68 3.3. Virtual Enterprise Traversal (VET) . . . . . . . . . . . . 11 69 3.3.1. RANGER Organizational Principles . . . . . . . . . . . 12 70 3.3.2. RANGER End-to-End Addressing Example . . . . . . . . . 13 71 3.3.3. Dynamic Routing and On-Demand Mapping . . . . . . . . 13 72 3.3.4. Support for Legacy RLOC-Based Services . . . . . . . . 15 73 3.4. Subnetwork Encapsulation and Adaptation Layer (SEAL) . . . 17 74 3.5. Mobility Management . . . . . . . . . . . . . . . . . . . 18 75 3.6. Multihoming . . . . . . . . . . . . . . . . . . . . . . . 19 76 3.7. Implications for the Internet . . . . . . . . . . . . . . 20 77 4. Related Initiatives . . . . . . . . . . . . . . . . . . . . . 20 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 82 8.1. Normative References . . . . . . . . . . . . . . . . . . . 23 83 8.2. Informative References . . . . . . . . . . . . . . . . . . 23 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 86 1. Introduction 88 RANGER is an architectural framework for scalable routing and 89 addressing in next generation enterprise networks. The term 90 "enterprise network" within this context extends to a wide variety of 91 use cases and deployment scenarios, where an "enterprise" can be as 92 small as a SOHO network, as dynamic as a Mobile Ad-hoc Network, as 93 complex as a multi-organizational corporation, or as large as the 94 global Internet itself. Such networks will require an architected 95 solution for the coordination of routing and addressing plans with 96 accommodations for scalability, provider-independence, mobility, 97 multi-homing and security. These considerations are particularly 98 true for existing deployments, but the same principles apply even for 99 clean-slate approaches. The RANGER architecture addresses these 100 requirements, and also provides a comprehensive framework for IPv6/ 101 IPv4 coexistence [I-D.arkko-townsley-coexistence]. 103 RANGER provides a unifying architecture for enterprises that contain 104 one or more distinct interior IP routing and addressing domains (or, 105 "Routing LOCator (RLOC) space"), with each distinct RLOC space 106 containing one or more organizational groupings. Each RLOC space may 107 coordinate their own internal addressing plans independently of one 108 another such that limited-scope addresses (e.g., [RFC1918] private- 109 use IPv4 addresses) may be reused with impunity to provide unlimited 110 scaling through spatial reuse. Each RLOC space therefore appears as 111 an enterprise unto itself, where organizational partitioning of the 112 enterprise into one or more "sub-enterprises" (or, "sites") is also 113 possible and beneficial in many scenarios. Without an architected 114 approach, routing and addressing within such a framework would be 115 fragmented due to address/prefix reuse between disjoint enterprises. 116 With RANGER, however, multiple enterprises can be linked together to 117 provide a multi-hop transit for nodes attached to enterprise edge 118 networks that use Endpoint Interface iDentifier (EID) addresses taken 119 from an IP addressing range that is distinct from any RLOC space. 121 RANGER is recursive, in that multiple enterprises can be joined 122 together in a nested "enterprise-within-enterprise" fashion, where 123 each enterprise also connects edge networks with nodes that configure 124 addresses taken from EID space to support edge/core separation. In 125 this way, the same RANGER principles that apply in lower levels of 126 recursion can extend upwards to parent enterprises and ultimately to 127 the core of the global Internet itself. Furthermore, it is also 128 worth considering whether today's global Internet represents a 129 limiting condition for recursion. In particular, other Internets 130 could be manifested as "parallel universes" and joined together at 131 still higher levels of recursion. 133 The RANGER architecture is manifested through composite technologies 134 including Virtual Enterprise Traversal (VET) 135 [I-D.templin-intarea-vet], the Subnetwork Encapsulation and 136 Adaptation Layer (SEAL) [I-D.templin-intarea-seal], and the Intra- 137 Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214]. Other 138 mechanisms such as IPsec [RFC4301] are also in scope for use within 139 certain scenarios. 141 Noting that combinations with still other technologies are also 142 possible, the issues addressed either in full or in part by RANGER 143 include: 145 o scalable routing and addressing 147 o provider-independent addressing and its relation to provide- 148 aggregated addressing 150 o site mobility and multi-homing 152 o address and prefix autoconfiguration 154 o border router discovery 156 o router/host-to-router/host tunneling 158 o neighbor discovery over tunnels 160 o MTU determination for tunnels 162 o IPv6/IPv4 coexistence and transition 164 Note that while this document primarily uses the illustrative example 165 of IPv6 as a virtual overlay over or IPv4 networks, it is important 166 to note that the same architectural principles apply to any 167 combination of IPvX virtual overlays over IPvY networks. 169 2. Terminology 171 Routing Locator (RLOC) 172 an IPv4 or IPv6 address assigned to an interface in an enterprise- 173 interior routing region. Note that RLOC space is local to each 174 enterprise, hence the same RLOC space IP addresses may be assigned 175 within disjoint enterprises. 177 Endpoint Interface iDentifier (EID) 178 an IPv4 and IPv6 address assigned to an edge network interface of 179 an end system. Note that EID space must be separate and distinct 180 from any RLOC space. 182 commons 183 a enterprise-interior routing region that provides a subnetwork 184 for cooperative peering between the border routers of diverse 185 organizations that may have competing interests. A prime example 186 of a commons is the Default Free Zone (DFZ) of the global 187 Internet. The enterprise-interior routing region within the 188 commons uses an addressing plan taken from RLOC space. 190 enterprise 191 the same as defined in [RFC4852], where the enterprise deploys a 192 unified RLOC space addressing plan within the commons, but may 193 also contain partitions with disjoint RLOC spaces and/or 194 organizational groupings that can be considered as enterprises 195 unto themselves. An enterprise therefore need not be "one big 196 happy family", but instead provides a commons for the cooperative 197 interconnection of diverse organizations that may have competing 198 interests (e.g., such as the case within the global Internet 199 default free zone). 201 Enterprise networks are typically associated with large 202 corporations or academic campuses, however the RANGER 203 architectural principles apply to any network that has some degree 204 of cooperative active management. This definition therefore 205 extends to home networks, small office networks, ISP networks, a 206 wide variety of mobile ad-hoc networks (MANETs), and even to the 207 global Internet itself. 209 site 210 a logical and/or physical grouping of interfaces within an 211 enterprise commons, where the topology of the site is a proper 212 subset of the topology of the enterprise. A site may contain many 213 interior sites, which may themselves contain many interior sites 214 in a recursive fashion. 216 Throughout the remainder of this document, the term "enterprise" 217 refers to either enterprise or site, i.e., the RANGER principles 218 apply equally to enterprises and sites of any size or shape. At 219 the lowest level of recursive decomposition, a singleton 220 Enterprise Border Router can be considered as an enterprise unto 221 itself. 223 Enterprise Border Router (EBR) 224 a router at the edge of an enterprise that is also configured as a 225 tunnel endpoint in an overlay network. EBRs connect their 226 directly-attached networks to the overlay network, and connect to 227 other networks via IP-in-IP tunneling across the commons to other 228 EBRs. This definition is intended as an architectural equivalent 229 of the functional term "EBR" defined in [I-D.templin-intarea-vet]. 231 Enterprise Border Gateway (EBG) 232 an EBR that also connects the enterprise to provider networks 233 and/or to the global Internet. EBGs are typically configured as 234 default routers in the overlay, and provide forwarding services 235 for accessing IP networks not reachable via an EBR within the 236 commons. This definition is intended as an architectural 237 equivalent of the functional term "EBG" defined in 238 [I-D.templin-intarea-vet], and is synonymous with the term 239 "default mapper" used in other contexts (e.g., [I-D.jen-apt]). 241 Ingress Tunnel Endpoint (ITE) 242 a host or router interface that encapsulates inner IP packets 243 within an outer IP header for transmission over an enterprise- 244 interior routing region to the RLOC address of an Egress Tunnel 245 Endpoint (ETE). 247 Egress Tunnel Endpoint (ETE) 248 a host or router interface that receives encapsulated packets sent 249 to its RLOC address, decapsulates the inner IP packets, then 250 delivers them to the EID address of the final destination. 252 overlay network 253 a virtual network manifested by routing and addressing over 254 virtual links formed through automatic tunneling. An overlay 255 network may span many underlying enterprises. 257 6over4 258 Transmission of IPv6 over IPv4 Domains without Explicit Tunnels 259 [RFC2529]; functional specifications and operational practices for 260 automatic tunneling of unicast/multicast IPv6 packets over 261 multicast-capable IPv4 enterprises. 263 ISATAP 264 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) 265 [RFC5214]; functional specifications and operational practices for 266 automatic tunneling of unicast IPv6 packets over unicast-only IPv4 267 enterprises. 269 VET 270 Virtual Enterprise Traversal (VET) [I-D.templin-intarea-vet]; 271 functional specifications and operational practices for automatic 272 tunneling of both unicast and multicast IP packets with provisions 273 for address/prefix autoconfiguration, provider-independent 274 addressing, mobility, multihoming, and security. VET is descended 275 from both 6over4 and ISATAP, and is also known as "ISATAP version 276 2 (ISATAPv2)". 278 SEAL 279 Subnetwork Encapsulation and Adaptation Layer (SEAL) 280 [I-D.templin-intarea-seal]; an encapsulation sublayer that 281 provides an extended IP Identification field and mechanisms for 282 link MTU adaptation over tunnels. 284 Provider-Independent (PI) prefix 285 an IPv6 or IPv4 EID prefix (e.g., 2001:DB8::/48, 192.0.2/24, etc.) 286 that is routable within a limited scope and may also appear in 287 enterprise mapping tables. PI prefixes that can appear in mapping 288 tables are typically delegated to a BR by a registry, but are not 289 aggregated by a provider network. Local-use IPv6 and IPv4 290 prefixes (e.g., FD00::/8, 192.168/16, etc.) are another example of 291 a PI prefix, but these typically do not appear in mapping tables. 293 Provider-Aggregated (PA) prefix 294 an IPv6 or IPv4 EID prefix that is either derived from a PI prefix 295 or delegated directly to a provider network by a registry. 296 Although not widely discussed, it bears specific mention that a 297 prefix taken from a delegating router's PI space becomes a PA 298 prefix from the perspective of the requesting router. 300 3. The RANGER Architecture 302 The RANGER architecture enables scalable routing and addressing in 303 next-generation enterprise networks with sustaining support for 304 legacy networks and services. Key to this approach is a framework 305 that accommodates interconnection of diverse organizations across a 306 commons with a mutual spirit of cooperation, but with the potential 307 for competing interests. The following sections outline the RANGER 308 architecture within the context of anticipated use cases: 310 3.1. Routing and Addressing 312 The Internet today is facing "growing pains", with indications that 313 core Routing Information Base (RIB) scaling may not be sustainable 314 over the long term and that the remaining space for IPv4 address 315 allocations may be depleted in the near future. Therefore, there is 316 an emerging need for scalable routing and addressing solutions. It 317 must further be noted that the same solutions selected to address 318 global Internet routing and addressing scaling can apply equally for 319 large enterprises, or for any enterprise that would benefit from a 320 separation of core and edge addressing domains. 322 RANGER supports scalable routing through an approach known as map- 323 and-encaps [RFC1955]. In this approach, an Ingress Tunnel Endpoint 324 (ITE) that must forward an IP packet first consults a mapping system 325 to discover a mapping for the destination Endpoint Interface 326 iDentifier (EID) to a Routing LOCator (RLOC) assigned to an Egress 327 Tunnel Endpoint (ETE). The mapping system is typically maintained as 328 a per-enterprise distributed database which is synchronized among a 329 limited set of mapping agents. Distributed database management 330 alternatives include a BGP instance maintained by EBGs, a DNS reverse 331 zone distributed among a restricted set of caching servers, etc. 332 Mapping entries are inserted into the mapping system through 333 administrative configuration, automated prefix registrations, etc. 335 RANGER allows that an ITE either consult the mapping system itself 336 (while delaying or dropping initial IP packets) or forward initial 337 packets to an Enterprise Border Gateway (EBG) acting as a "default 338 mapper". In either case, the ITE receives a mapping reply that it 339 can use to populate its Forwarding Information Base (FIB). The 340 choice of mapping approaches must be considered with respect to the 341 individual enterprise network scenario, e.g., forwarding to an EBG 342 may be more appropriate in some scenarios while ITE self-discovery 343 may be more appropriate in others. Use of other mapping mechanisms 344 is also possible according to the specific enterprise scenario. 346 After discovering the mapping, the ITE encapsulates inner IP packets 347 in an outer IP header for transmission across the commons to the RLOC 348 address of an ETE. The ETE in turn decapsulates the packets and 349 forwards them over edge networks to the EID addresses of final 350 destinations. The Routing Information Base (RIB) within the commons 351 therefore only needs to maintain state regarding RLOCs and not EIDs, 352 while the synchronized EID-to-RLOC mapping state is maintained by a 353 smaller number of nodes and is not subject to oscillations due to 354 link state changes within the commons. Finally, EIDs are routable 355 only within a limited scope within edge networks (which may be as 356 small as node-local scope in the limiting case). 358 RANGER supports scalable addressing by selecting a suitably large EID 359 addressing range that is distinct and kept separate from any 360 enterprise-interior RLOC addressing ranges. It should therefore come 361 as no surprise that taking EID space from the IPv6 addressing 362 architecture should lead to a viable scalable addressing alternative, 363 while taking EID space from the (already exhausted) IPv4 addressing 364 architecture may not. 366 3.2. The Enterprise-within-Enterprise Framework 368 Enterprise networks traditionally distribute routing information via 369 Interior Gateway Protocols (IGPs) such as Open Shortest Path First 370 (OSPF), while large enterprises may even use an Exterior Gateway 371 Protocol (EGP) internally in place of an IGP. Thus, it is becoming 372 increasingly commonplace for large enterprises to use the Border 373 Gateway Protocol (BGP) internally and independently from the BGP 374 instance that maintains the RIB within the global Internet Default 375 Free Zone (DFZ). 377 As such, large enterprises may run an internal instance of BGP across 378 many internal Autonomous Systems (ASs). Such a large enterprise can 379 therefore appear as an Internet unto itself, albeit with default 380 routes leading to the true global Internet. Additionally, each 381 internal AS within such an enterprise may itself run BGP internally 382 in place of an IGP, and can therefore also appear as an independent 383 lower-tier enterprise unto itself. This enterprise-within-enterprise 384 framework can be extended in a recursive fashion as broadly and as 385 deeply as desired to achieve scaling factors as well as 386 organizational and/or functional compartmentalization, e.g., as shown 387 in Figure 1. 388 ,---------------. 389 ,-' Global `-. <--------+ 390 ( IPv6/IPv4 ) ,----|-----. 391 `-. Internet ,-' ( Enterprises) 392 `+--+..+--+ ...+--+ ( E2 thru EN ) 393 _.-|R1|--|R2+----|Rn|-._ `.---------/ 394 _.---'' +--+ +--+ ...+--+ -. 395 ,--'' ,---. `---. 396 ,-' X5 X6 .---.. `-. 397 ,' ,.X1-.. / \ ,' `. `. 398 ,' ,' `. .' E1.2 '. X8 E1.m \ `. 399 / / \ | ,--. | / _,.._ \ \ 400 / / E1.1 \ | Y3 `. | | / Y7 | \ 401 ; | ___ | | ` W Y4 |... | `Y6 ,' | : 402 | | ,-' `. X2 | `--' | | `'' | | 403 : | | V Y2 | \ _ / | | ; 404 \ | `-Y1,,' | \ .' Y5 / \ ,-Y8'`- / / 405 \ \ / \ \_' / X9 `. ,'/ / 406 `. \ X3 `.__,,' `._ Y9'',' ,' 407 ` `._ _,' ___.......X7_ `---' ,' 408 ` `---' ,-' `-. -' 409 `---. `. E1.3 Z _' _.--' 410 `-----. \---.......---' _.---'' 411 `----------------'' 413 <---------------- Enterprise E1 ----------------> 415 Figure 1: Enterprise-within-Enterprise Framework 417 Figure 1 depicts an enterprise 'E1' connected to the global IPv6/IPv4 418 Internet via routers 'R1' through 'Rn' and additional enterprises 419 'E2' through 'EN' that also connect to the global Internet. Within 420 the 'E1' commons, there may be arbitrarily-many hosts, routers and 421 networks (not shown in the diagram) that use addresses taken from 422 RLOC space and over which both encapsulated and unencapsulated IP 423 packets can be forwarded. There may also be many lower-tier 424 enterprises 'E1.1' through 'E1.m' (shown in the diagram) that 425 interconnect within the 'E1' commons via Enterprise Border Routers 426 (EBRs) depicted as 'X1' through 'X9' (where 'X1' through 'X9' see 427 'R1' through 'Rn' as EBGs). Within each 'E1.*' enterprise, there may 428 also be arbitrarily-many lower-tier enterprises that interconnect 429 within the 'E1.*' commons via EBRs depicted as 'Y1' through 'Y9' in 430 the diagram (where 'Y1' through 'Y9' see 'X1' through 'X9' as EBGs). 431 This recursive decomposition can be nested as deeply as desired, and 432 ultimately terminates at singleton nodes such as those depicted as 433 'V', 'W' and 'Z' in the diagram. 435 It is important to note that nodes such as 'V', 'W' and 'Z' may be 436 simple hosts, or they may be EBRs that attach arbitrarily-complex 437 edge networks with addresses taken from EID space. Such edge 438 networks could be as simple as a home network behind a residential 439 gateway or as complex as a major corporate/academic campus, a large 440 service provider network, etc. 442 Again, this enterprise-within-enterprise framework can be recursively 443 nested as broadly and deeply as desired. From the highest level of 444 the recursion, consider now that the global Internet itself can be 445 viewed as an "enterprise" that interconnects lower-tier enterprises 446 E1 through EN such that all RANGER architectural principles apply 447 equally within that context. Furthermore, the RANGER architecture 448 recognizes that the global Internet need not represent a limiting 449 condition for recursion, but rather allows that other Internets could 450 be manifested as "parallel universes" and joined together at still 451 higher levels of recursion. 453 As a specific case in point, the future global Aeronautical 454 Telecommunications Network (ATN) under consideration within the civil 455 aviation industry [I-D.bauer-mext-aero-topology] will take the form 456 of a large enterprise network that appears as an Internet unto 457 itself, i.e., exactly as depicted for 'E1' in Figure 1. Within the 458 ATN, there will be many Air Communications Service Provider (ACSP) 459 and Air Navigation Service Provider (ANSP) networks organized as 460 autonomous systems internal to the ATN, i.e., exactly as depicted for 461 'E1.*' in the diagram. The ACSP/ANSP network EBGs will participate 462 in a BGP instance internal to the ATN, and may themselves run 463 independent BGP instances internally that are further sub-divided 464 into lower-tier enterprises organized as regional, organizational, 465 functional, etc. compartments. It is important to note that, while 466 ACSPs/ANSPs within the ATN will share a common objective of safety- 467 of-flight for civil aviation services, there may be competing 468 business/social/political interests between them such that the ATN is 469 not necessarily "one big happy family". Therefore, the model 470 parallels that of the global Internet itself. 472 Such an operational framework may indeed be the case for many next- 473 generation enterprises. In particular, although the routing and 474 addressing arrangements of all enterprises will require a mutual 475 level of cooperative active management at a certain level, free 476 market forces, business objectives, political alliances, etc. may 477 drive internal competition. 479 3.3. Virtual Enterprise Traversal (VET) 481 Within the enterprise-within-enterprise framework outlined in 482 Section 3.2, the RANGER architecture is based on overlay networks 483 manifested through Virtual Enterprise Traversal (VET) 484 [I-D.templin-intarea-vet] [RFC5214]. The VET approach uses automatic 485 IP-in-IP tunneling in which ITEs encapsulate EID-based inner IP 486 packets within RLOC-based outer IP headers for transmission across 487 the commons to ETEs. 489 For each enterprise they connect to, EBRs that use VET configure a 490 Non-Broadcast, Multiple Access (NBMA) interface known as a "VET 491 interface" that sees all other EBRs within the enterprise as 492 potential single-hop neighbors from the perspective of the inner IP 493 protocol. This means that for many enterprise scenarios standard 494 neighbor discovery mechanisms (e.g., router advertisements, 495 redirects, etc.) can be used between EBR pairs. This gives rise to a 496 data-driven model in which neighbor relationships are formed based on 497 traffic demand in the data plane, which in many cases can relax the 498 requirement for dynamic routing exchanges across the overlay in the 499 control plane. 501 When multiple VET interfaces are linked together, end-to-end 502 traversal is seen as multiple VET hops from the perspective of the 503 inner IP protocol. In that case, transition between VET interfaces 504 entails a "re-encapsulation" approach in which a packet that exits 505 VET interface 'i' is decapsulated then re-encapsulated before it is 506 forwarded into VET interface 'i+1'. For example, if an end-to-end 507 path between two EID-based peers crosses N distinct VET interfaces, a 508 traceroute would show N inner IP forwarding hops corresponding to the 509 portions of the path that traverse the VET interfaces. 511 VET and its related works specify necessary mechanisms and 512 operational practices to manifest the RANGER architecture. The use 513 of VET in conjunction with SEAL (see: Section 3.4) is essential in 514 certain deployments to avoid issues related to source address 515 spoofing and black holing due to path Maximum Transmission Unit (MTU) 516 limitations. (The use of VET in conjunction with IPsec [RFC4301] can 517 also be beneficial in some enterprise network scenarios.) The 518 following sections discuss operational considerations and use cases 519 within the VET approach: 521 3.3.1. RANGER Organizational Principles 523 Figure 2 below depicts a vertical slice (albeit represented 524 horizontally) from the enterprise-within-enterprise framework shown 525 in Figure 1: 527 +------+ 528 | IPv6 | 529 " " " " " " " "" " " " " " " " " " " " " " " " |Server| 530 " <----------------- 2001:DB8::/40 (PA) " | S1 | 531 " 2001:DB8:10::/56 (PI) ----------------> " +--+---+ 532 " . . . . . . . . . . . . . . . " | 533 " . . . . . . " | 534 " . +----+ v +--- + v +----+ v +----+ +-----+-------+ 535 " . | V += e =+ Y1 += e =+ X2 += e =+ R2 +==+ Internet | 536 " . +-+--+ t +----+ t +----+ t +----+ +-----+-------+ 537 " . | 1 . . 2 . . 3 . " | 538 " . H . . . . . " | 539 " . . . . . . . . . . . . . . " +--+---+ 540 " " | IPv4 | 541 " 10/8 10/8 10/8 " |Server| 542 " " " " " " " " " " " " " " "" " " " " " " " | S2 | 543 <-- Enterprise E1 --> +------+ 545 Figure 2: Virtual Enterprise Traversal 547 Within this vertical slice, each enterprise within the 'E1' recursive 548 hierarchy is spanned by VET interfaces represented as 'vet1' through 549 'vet3'. Each VET interface within this framework is a Non-Broadcast, 550 Multiple Access (NBMA) interface that connects all EBRs within the 551 same enterprise. Each enterprise within the 'E1' hierarchy may 552 comprise a smaller topological region within a larger RLOC space, or 553 they may configure an independent RLOC space from a common (but 554 spatially reused) limited-scope prefix, e.g., depicted as multiple 555 disjoint instances of '10/8' in the diagram. 557 In the RANGER approach, EBRs within lower-tier enterprises coordinate 558 their EID prefixes with EBGs that connect to an upper-tier 559 enterprise. EID prefixes could be either Provider-Independent (PI) 560 prefixes owned by the EBR or Provider-Aggregated (PA) prefixes 561 delegated by the EBG. In either case, EID prefixes must be 562 coordinated with the enterprise routing/mapping systems. 564 When PA EID prefixes are used, the EBR for each 'E1*' enterprise 565 receives an EID prefix delegation from a delegating EBG in a parent 566 enterprise. In this example, when 'R2' is a delegating router for 567 the prefix '2001:DB8::/40, it may delegate '2001:DB8::/48' to 'X2', 568 which in turn delegates '2001:DB8::/52' to 'Y1', which in turn 569 delegates 2001:DB8::/56' to 'V'. The preferred mechanism for this 570 recursive PA prefix sub-delegation is DHCP Prefix Delegation 571 [RFC3633], which also arranges for publication of the prefixes in the 572 enterprise routing system. 574 When PI EID prefixes are used, individual EBRs (e.g., 'V') register 575 their PI prefixes (e.g., 2001:DB1:10::/56) by sending Router 576 Advertisement (RA) messages to EBGs within the enterprise to assert 577 prefix ownership. When stronger authentication is necessary, the 578 EBRs can digitally sign the messages using the mechanisms specified 579 for SEcure Neighbor Discovery (SEND) [RFC3971]. EBGs that receive 580 the RAs (e.g., 'Y1') first verify the sender's credentials, then 581 register the prefixes in the enterprise mapping system. Next, they 582 forward a proxied version of the RA to EBGs within their parent 583 enterprises (e.g., 'X2'). This proxying process continues up the 584 recursive hierarchy until a default-free commons is reached. (In 585 this case, the proxying process ends at 'R2'). After the initial 586 registration, the EBR that owns the PI prefixes must periodically 587 send additional RAs to update prefix expiration timers. 589 3.3.2. RANGER End-to-End Addressing Example 591 In Figure 2, an IPv6 host 'H' that is deeply nested within Enterprise 592 'E1' connects to IPv6 server 'S1' located somewhere on the IPv6 593 Internet. 'H' is attached to a shared link with IPv6/IPv4 dual stack 594 router 'V', which advertises the IPv6 prefixes '2001:DB8:0:0::/64' 595 and '2001:DB8:10:0::/64. 'H' uses standard IPv6 neighbor discovery 596 mechanisms to discover 'V' as a default IPv6 router that can forward 597 its packets off the local link, and configures addresses from both of 598 the advertised prefixes. 'V' in turn sees node 'Y1' as an EBG that 599 is reachable via VET interface 'vet1' and that can forward packets 600 toward IPv6 server 'S1'. Similarly, node 'Y1' is an EBR on the 601 enterprise spanned by 'vet2' that sees 'X2' as an EBG, and node 'X2' 602 is an EBR on 'vet3' that sees 'R2' as an EBG. Ultimately, 'R2' is an 603 EBR that connects 'E1' to the global Internet. 605 3.3.3. Dynamic Routing and On-Demand Mapping 607 In the example shown in Figure 2, 'V', 'Y1', 'X2' and 'R2' configure 608 separate VET interfaces for each enterprise they connect to and to 609 discover routes through a dynamic routing protocol and/or mapping 610 database lookups. After tunnels 'vet1' through 'vet3' are 611 established, the EBRs connected to a VET interface can run a dynamic 612 routing protocol such as OSPVFv3 [RFC5340] and exchange topology 613 information with one another over the VET interface. It is important 614 to note that dynamic routing protocol neighbor relationships (or, 615 "adjacencies") can be discovered on-demand, e.g., when an EBR A 616 discovers an RLOC mapping for EBR B during a mapping lookup for an 617 EID that is aggregated by B. These neighbor relationships can be 618 maintained while the "link" between A and B is actively being used to 619 convey packets, and allowed to expire after significant idle periods. 620 This allows a routing protocol operating in an overlay network that 621 spans 'E1' to dynamically adapt to changing neighbor relationships 622 within the enterprise. 624 In a second example, Figure 3 depicts an instance of on-demand 625 discovery of more-specific routes in which an IPv6 end system 'H' 626 connects to a peer end system 'J' located in a different 627 organizational entity within 'E1': 629 +------+ 630 | IPv6 | 631 " " " " " " " "" " " " " " " " " " " " " " " " |Server| 632 " <----------------- 2001:DB8::/40 (PA) " | S1 | 633 " 2001:DB8:10::/56 (PI) ----------------> " +--+---+ 634 " . . . . . . . . . . . . . . . " | 635 " . . . . . . " | 636 " . +----+ v +----+ v +----+ +----+ +-----+-------+ 637 " . | V += e =+ Y1 += e =+ X2 += =+ R2 +==+ Internet | 638 " . +-+--+ t +----+ t +----+ +----+ +-----+-------+ 639 " . | 1 . . 2 . . . " | 640 " . H . . . . v . " | 641 " . . . . . . . . . . . e . " +--+---+ 642 " . t . " | IPv4 | 643 " . . . . . . , . 3 . " |Server| 644 " . +----+ v +----+ . " | S2 | 645 " . | Z += e =+ X7 += . " +------+ 646 " . +-+--+ t +----+ . " 647 " . | 4 . . . " 648 " . J . . . . . " 649 " . . . . . . . " 650 " 2001:DB8:20::/56 (PI) --------> " 651 " " " " " " " " " " " " " " "" " " " " " " " 652 <-- Enterprise E1 --> 654 Figure 3: On-Demand Discovery 656 In this example, tunnel interfaces 'vet1' through 'vet4' as well as 657 IPv6 PI prefix registrations have been established through VET 658 enterprise autoconfiguration procedures. When IPv6 end system 'H' 659 with IPv6 address '2001:DB8:10::1' sends packets to a peer end system 660 'J' with IPv6 address '2001:DB8:20::1', the packets will be conveyed 661 through 'V', 'Y1', and finally to 'X2' via default routes. Then, 662 unless 'X2' has an IPv6 FIB entry matching 'J', it must discover that 663 'J' can be reached using a more direct route via 'X7' as the next-hop 664 across the 'E1' commons. 666 In particular, when 'X2' receives a packet on the 'vet2' interface 667 with inner destination address 'J', it can perform an on-demand 668 mapping lookup by consulting the enterprise mapping service, e.g., by 669 consulting the DNS reverse zone. Alternatively, 'X2' can send the 670 packet to a default router (e.g., 'R2') which in turn can forward the 671 packet to 'X7' and return an ICMPv6 redirect message. When 'X2' 672 receives the redirect, it can send an RA message to 'X7' to prove 673 that it is authorized to produce packets with a prefix that matches 674 source address 'J'. 'X2' can then forward subsequent packets 675 directly to 'X7' without involving 'R2'. 677 In some enterprise scenarios, dynamic routing and on-demand mapping 678 can be combined as complementary functions. In other scenarios, it 679 may be preferable to use dynamic routing only or on-demand mapping 680 only. 682 3.3.4. Support for Legacy RLOC-Based Services 684 Legacy hosts, routers and networks that were already present in pre- 685 RANGER deployments and have already numbered their interfaces with 686 RLOC addresses must see continued support for RLOC-based services for 687 the long term even as EID-based services are rolled out in new 688 deployments. For example, a legacy IPv4-only node behind an IPv4 689 Network Address Translator (NAT) must still be able to reach legacy 690 IPv4-only Internet services (e.g., "http://example.com") long after 691 the RANGER architecture and EID-based services are widely deployed. 693 Returning to the example diagrams, while virtual enterprise traversal 694 across 'E1' provides a fully-connected routing and addressing 695 capability for EID-based services, legacy nodes will still require 696 access to RLOC-based services within connected- or disjoint RLOC 697 spaces for an extended (and possibly indefinite) period. For 698 example, Figure 4 below depicts the applicable RLOC-based IPv4 699 service access scenarios for the RANGER architecture when VET 700 interfaces are used to link recursively-nested enterprises together: 702 +------+ 703 | IPv6 | 704 " " " " " " " "" " " " " " " " " " " " " " " " |Server| 705 " <----------------- 2001:DB8::/40 (PA) " | S1 | 706 " 2001:DB8:10::/56 (PI) -----------------> " +--+---+ 707 " . . . . . . . . . . . . . . . " | 708 " . . . . . . " | 709 " . +----+ v +--- + v +----+ v +----+ +-----+-------+ 710 " . | V += e =+ Y1 += e =+ X2 += e =+ R2 +==+ Internet | 711 " . +-+--+ t +----+ t +----+ t +----+ +-----+-------+ 712 " . | 1 . . 2 . . 3 . " | 713 " . K L . . . . M . " | 714 " . . . . . . . . . . . . . . " +--+---+ 715 " " | IPv4 | 716 " " |Server| 717 " " " " " " " " " " " " " " "" " " " " " " " | S2 | 718 <-- Enterprise E1 --> +------+ 720 Figure 4: Support for Legacy RLOC-Based Services 722 In a first instance, a legacy RLOC-based IPv4 client 'K' within 723 enterprise 'E1.1.1' can access RLOC-based IPv4 service 'L' within the 724 same enterprise as-normal and without the need for any encapsulation. 725 Instead, 'K' discovers a "mapping" for 'L' through a simple lookup 726 within the 'E1.1.1' enterprise-local name service, and conveys 727 packets to 'L' through unencapsulated RLOC-based IPv4 routing and 728 addressing within the 'E1.1.1' commons. In many instances, this may 729 indeed be the preferred service access model even when EID-based IPv6 730 services are widely deployed due to factors such as inability to 731 replace legacy IPv4 applications, IPv6 header overhead avoidance, 732 etc. 734 In a second instance, RLOC-based IPv4 client 'K' can access RLOC- 735 based IPv4 server 'S2' on the legacy global IPv4 Internet in a number 736 of ways based on the way the recursively nested 'E1.*' enterprises 737 are provisioned: 739 o if all of the recursively nested 'E1.*' enterprises are configured 740 within the same IPv4 RLOC space, normal IPv4 forwarding will 741 convey 'K's unencapsulated IPv4 packets toward 'R2' which then 742 acts as an IPv4 Network Address Translator (NAT) and/or an 743 ordinary IPv4 enterprise border router. 745 o if the recursively nested 'E1.*' enterprises are configured within 746 disjoint RLOC spaces, all EBGs 'Y1', 'X2' and 'R2' can be 747 configured to provide an IPv4 NAT capability (i.e., a recursive 748 nesting of NATs within NATs). However, this approach places 749 multiple instances of stateful NAT devices on the path which can 750 lead to an overall degree of brittleness and intolerance to 751 routing changes. Instead, 'R2' could act as a "Carrier-Grade NAT 752 (CGN)", and 'K's IPv4 router ('V') convey 'K's packets to the CGN 753 using IPv4-in-IPv6-in-IPv4 tunneling. The CGN can then 754 decapsulate the inner RLOC-based IPv4 packets and translate the 755 IPv4 source addresses into a global IPv4 source addresses before 756 sending the packets on to 'S2'. 758 o 'K' could be configured as an EID-based IPv6-capable node and use 759 standard IPv6 routing to reach an IPv6/IPv4 translator located at 760 an EBR for the enterprise in which 'S2' resides'. The translator 761 would then use IPv6-to-IPv4 translation before sending packets 762 onwards toward 'S2'. These and other alternatives are discussed 763 in [I-D.wing-nat-pt-replacement-comparison]. 765 In a final instance, RLOC-based IPv4 client 'K' can access an RLOC- 766 based IPv4 server 'M' in a different enterprise within E1 as long as 767 both enterprises are configured over the same IPv4 RLOC space. If 768 the enterprises are configured over disjoint IPv4 RLOC spaces, 769 however, 'K' would still be able to access 'M' by using EID-based 770 IPv6 services, by using EID-based IPv4 services if an EID-based IPv4 771 overlay were deployed, or by using some form of RLOC-based IPv4 NAT 772 traversal. 'K' could also access server 'M' if both 'V' and 'X2' 773 implemented an IPv6/IPv4 protocol translation capability. 775 3.4. Subnetwork Encapsulation and Adaptation Layer (SEAL) 777 Tunnel endpoints that depend on ICMP feedback from routers within the 778 enterprise commons may be susceptible to undetected black holes due 779 to ICMP filtering gateways and/or off-path ICMP spoofing attacks from 780 a node pretending to be a router. Furthermore, rogue nodes within 781 enterprises that do not correctly implement ingress filtering can 782 send spoofed packets of any kind, e.g., for the purpose of mounting 783 denial-of-service and/or traffic amplification attacks targeting 784 underprivileged links. 786 The Subnetwork Encapsulation and Adaptation Layer (SEAL) provisions 787 each encapsulated packet with a monotonically-incrementing extended 788 Identification field (i.e., the 32-bit SEAL_ID) that tunnel endpoints 789 can use as a nonce to detect off-path spoofing. Moreover, tunnel 790 endpoints that use SEAL can continue to operate correctly even if 791 some/many ICMPs are lost. Finally, tunnel endpoints that use SEAL 792 can adapt to subnetworks containing links with diverse MTUs 793 properties. 795 3.5. Mobility Management 797 Enterprise mobility use cases must be considered along several 798 different vectors: 800 o nomadic enterprises and end systems may be satisfied to incur 801 address renumbering events as they move between new enterprise 802 network attachment points. 804 o mobile enterprises with PI prefixes may be satisfied by dynamic 805 updates to the mapping system as long as they do not impart 806 unacceptable churn. 808 o mobile enterprises and end systems with PA addresses/prefixes may 809 require additional supporting mechanisms that can accommodate 810 address/prefix renumbering. 812 Nomadic enterprise mobility is already satisfied by currently 813 deployed technologies. For example, transporting a laptop computer 814 from a wireless access hot spot to a home network LAN would allow the 815 nomadic device to re-establish connectivity at the expense of address 816 renumbering. Such renumbering may be acceptable especially for 817 devices that do not require session persistence across mobility 818 events and do not configure servers with addresses published in the 819 global DNS. 821 Mobile enterprises with PI prefixes that use VET and SEAL can move 822 between parent enterprise attachment points as long as they withdraw 823 the prefixes from the mapping systems of departed enterprises and 824 inject them into the mapping systems of new enterprises. When moving 825 between the lower recursive tiers of a common parent enterprise, such 826 a localized event mobility may result in no changes to the parent 827 enterprise's mapping system. Hence, the organizational structure of 828 a carefully arranged enterprise-within-enterprise framework may be 829 able dampen mobility-related churn. For enterprises that require in- 830 the-network confidentiality, MobIKE [RFC4555] may also be useful 831 within this context. 833 Mobile enterprises and end systems that move quickly between 834 disparate parent enterprise attachment points should not use PI 835 prefixes if withdrawing and announcing the prefixes would impart 836 unacceptable mapping/routing churn and packet loss. They should 837 instead use PA addresses/prefixes that can be coordinated via a 838 rendezvous service. Mobility management mechanisms such as Mobile 839 IPv6 [RFC3775] and HIP [RFC4423] can be used to maintain a stable 840 identifier for fast moving devices even as they move quickly between 841 visited enterprise attachment points. 843 As a use case in point, consider an aircraft with a mobile router 844 moving between ground station points of attachment. If the ground 845 stations are located within the same enterprise, or within lower-tier 846 sites of the same parent enterprise, it should suffice for the 847 aircraft to announce its PI prefixes at its new point of attachment 848 and withdraw them from the old. This would avoid excessive mapping 849 system churn, since the prefixes need not be announced/withdrawn 850 within the parent enterprise, i.e., the churn is isolated to lower 851 layers of the recursive hierarchy. Note also that such movement 852 would not entail an aircraft-wide readdressing event. 854 As a second example, consider a wireless handset moving between 855 service coverage areas maintained by independent providers with 856 peering arrangements. Since the coverage range of terrestrial 857 cellular wireless technologies is limited, mobility events may occur 858 on a much more aggressive timescale than some other examples. In 859 this case, the handset may expect to incur a readdressing event for 860 its access interface at least, and may be obliged to arrange for a 861 rendezvous service linkage. 863 It should specifically be noted that the contingency of mobility 864 management solutions is not necessarily mutually exclusive, and must 865 be considered in relation to specific use cases. The RANGER 866 architecture is therefore naturally inclusive in this regard. In 867 particular, RANGER could benefit from mechanisms that could support 868 rapid dynamic updates of PI prefix mappings without causing excessive 869 churn. 871 3.6. Multihoming 873 As with mobility management, multi-homing use cases must be 874 considered along multiple vectors. Within an enterprise, EBRs can 875 discover multiple EBGs and use them in a fault tolerant and load- 876 balancing fashion as long as they register their PI prefixes with 877 each such EBG as described in Section 3.3.1. These registrations are 878 created through the transmission of Router Advertisement messages 879 that percolate up through the recursive enterprise-within-enterprise 880 hierarchy. 882 As a first case in point, consider the enterprise network of a major 883 corporation that obtains services from a number of ISPs. The 884 corporation should be able to register its PI prefixes with all of 885 its ISPs, and use any of the ISPs for its Internet access services. 887 As a second use case, consider an aircraft with a diverse set of 888 wireless links (e.g., VHF, 802.16, directional, SATCOM, etc.). The 889 aircraft should be able to select and utilize the most appropriate 890 link(s) based on phase of flight, and change seamlessly between links 891 as necessary. Other examples include a nomadic laptop with both 892 802.11 and Ethernet links, a wireless handset with both CDMA wireless 893 and 802.11, etc. 895 As with mobility management, the contingency of solutions is not 896 necessarily mutually exclusive and can combine to suit use cases 897 within the scope of the RANGER architecture. 899 3.7. Implications for the Internet 901 Selection of mapping alternatives may have significant implications 902 for applications, server selection, route determination, security, 903 etc. In particular, applications that expect all packets (including 904 initial ones) to experience similar delays may be adversely affected 905 by a scheme that imposes non-negligible delays when initial packets 906 are queued while a look-aside mapping table is consulted. Still 907 other applications may experience significant startup delays when its 908 initial packets are dropped during a mapping lookup event. These 909 factors would seem to favor a scheme that is able to forward initial 910 packets along a path with sub-optimal delay while a mapping lookup is 911 performed in parallel, e.g., such as when a "default mapper" is used. 913 Generally speaking, proactive mapping maintenance mechanisms may have 914 scaling issues with the amount of updates they generate, while 915 reactive mechanisms may involve effects to the delay of initial 916 packets before the cached state is updated. Also to be considered 917 are attacks against the mapping mechanism which may result in denial 918 of service of the mapping cache. 920 Encapsulation of packets in automatically created tunnels involves a 921 number of issues as well. There are obvious interactions between 922 encapsulation overhead and the effective tunnel MTU, which can be 923 addressed by SEAL and (when necessary) careful operational link 924 arrangements. Moreover, it is important to minimize the impact to 925 the global routing table without at the same time impacting the 926 ability of legacy Internet networks to connect to those employing 927 RANGER. As long as other nodes in the Internet need to connect to 928 networks implementing RANGER, EID routes need to appear both in the 929 mapping system and the global BGP routing tables. This can be 930 accommodated by keeping the number of prefixes aggregated by RANGER 931 to the bare minimum through efficient aggregation (e.g., one or a few 932 [PREF]::/4 IPv6 prefixes instead of millions of [PREF]::/32 933 prefixes). 935 4. Related Initiatives 937 The origins of the RANGER architectural principles can be traced to 938 the "Catenet model for internetworking" [CATENET][IEN48] [RFC2775] 939 beginning as early as the mid-1970's. Subsequently, deliberations of 940 the ROAD group [RFC1380] and related efforts such as NIMROD [RFC1753] 941 provided a sustained evolution of the concepts. [RFC1955] captures 942 the high-level architectural aspects of the ROAD group deliberations 943 in a "New Scheme for Internet Routing and Addressing [ENCAPS] for 944 IPNG". 946 These foundational works significantly influenced more recent 947 developments, including the X-Bone initiative [XBONE] which explored 948 virtual topologies manifested through tunneling. Various tunneling 949 approaches including IP-in-IP [RFC2003][RFC4213], 6over4 [RFC2529] 950 and ISATAP [RFC5214] have evolved from the mid-1990's until the 951 present day and are used in common operational practice. Tunnel-mode 952 IPsec [RFC4301] is also commonly used for separation of security 953 domains within enterprises. 955 Currently, initiatives with similar properties to RANGER are under 956 development within the IRTF Routing Research Group (RRG) and within 957 IETF working groups such as LISP, SOFTWIRE, V6OPS and others. 958 Numerous proposals have been offered within the RRG, including the 959 Locator-Identifier Split Protocol (LISP), Six-One, ILNP, Internet 960 vastly improved plumbing (Ivip), A Practical Transit-Mapping Service 961 (APT), and Virtual Aggregation (VA) [RRG]. Still other similar 962 initiatives almost certainly exist. 964 While RANGER shares many properties with these earlier works, it 965 uniquely provides a top-to-bottom articulation of how the various 966 pieces fit together within a recursively-nested "enterprise-within- 967 enterprise" (or "network-of-networks') framework. In this way, it 968 bears striking resemblance to the network-of-networks model 969 envisioned by CATENET. RANGER further provides a detailed 970 consideration of challenging issues such as autoconfiguration, 971 provider-independent addressing, border router discovery, tunnel MTU, 972 multihoming, etc. that many other approaches have either overlooked 973 or left for future work. A detailed analysis of RANGER applicability 974 in various use case scenarios is provided in "RANGER Scenarios 975 (RANGERS)" [I-D.russert-rangers]. 977 5. IANA Considerations 979 There are no IANA considerations for this document. 981 6. Security Considerations 983 Communications between endpoints within different sites inside an 984 enterprise are carried across a commons that joins organizational 985 entities with a mutual spirit of cooperation, but between which there 986 may be competing business/sociological/political interests. As a 987 result, mechanisms that rely on feedback from routers on the path may 988 become brittle or susceptible to spoofing attacks. This is due to 989 the fact that IP packets can be lost due to congestion or packet 990 filtering gateways, and that the source addresses of IP packets can 991 be forged. Moreover, IP packets in general can be generated by 992 anonymous attackers, e.g., from a rogue node within a third-party 993 enterprise that has malicious intent toward a victim. 995 Path MTU discovery is an example of a mechanism that relies on ICMP 996 feedback from routers on the path, and as such is susceptible to 997 these issues. For IPv4, a common workaround is to disable Path MTU 998 Discovery and let fragmentation occur in the network if necessary. 999 For IPv6, lack of fragmentation support in the network precludes this 1000 option such that the mitigation typically recommended is to discard 1001 ICMP messages that contain insufficient information and/or to operate 1002 with the minimum IPv6 path MTU. This example extends also to other 1003 mechanisms that either rely on or are enhanced by feedback from 1004 network devices, however attack vectors based on non-ICMP messages 1005 are also subject for concern. 1007 The RANGER architecture supports effective mitigations for attacks 1008 such as distributed denial-of-service, traffic amplification, etc. 1009 In particular, when VET and SEAL are used, EBGs can use the 32-bit 1010 identification encoded in the SEAL header as well as ingress 1011 filtering to determine if a message has come from a topologically- 1012 correct enterprise located across the commons. This allows 1013 enterprises to employ effective mitigations at their borders without 1014 the requirement for mutual cooperation from other enterprises. When 1015 source address spoofing by on-path attackers located within the 1016 commons is also subject for concern, additional securing mechanisms 1017 such as tunnel-mode IPsec between enterprise EBGs can also be used. 1019 EBRs can obtain PI prefixes through arrangements with a prefix 1020 delegation authority. Thereafter, the EBR can announce and/or 1021 withdraw the prefixes within an enterprise by sending IPv6 Router 1022 Advertisements (RAs). In environments where additional 1023 authenticating mechanisms are necessary, the EBR can sign its RAs 1024 using SEcure Neighbor Discovery (SEND) [RFC3971]. 1026 While the RANGER architecture does not in itself address security 1027 considerations, it proposes an architectural framework for functional 1028 specifications that do. Security concerns with tunneling along with 1029 recommendations that are compatible with the RANGER architecture are 1030 found in [I-D.ietf-v6ops-tunnel-security-concerns]. 1032 7. Acknowledgements 1034 This work was inspired through the encouragement of the Boeing DC&NT 1035 network technology team and through the communications of the IESG. 1037 Many individuals have contributed to the architectural principles 1038 that form the basis for RANGER over the course of many years. The 1039 following individuals have given specific feedback on the RANGER 1040 document itself: Jari Arkko, Brian Carpenter, Eric Fleischman, Joe 1041 Halpern, Thomas Henderson, Steven Russert, Robin Whittle. 1043 8. References 1045 8.1. Normative References 1047 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1048 September 1981. 1050 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1051 (IPv6) Specification", RFC 2460, December 1998. 1053 8.2. Informative References 1055 [CATENET] Pouzin, L., "A Proposal for Interconnecting Packet 1056 Switching Networks", May 1974. 1058 [I-D.arkko-townsley-coexistence] 1059 Arkko, J. and M. Townsley, "IPv4 Run-Out and IPv4-IPv6 Co- 1060 Existence Scenarios", draft-arkko-townsley-coexistence-03 1061 (work in progress), July 2009. 1063 [I-D.bauer-mext-aero-topology] 1064 Bauer, C. and S. Ayaz, "ATN Topology Considerations for 1065 Aeronautical NEMO RO", draft-bauer-mext-aero-topology-01 1066 (work in progress), September 2009. 1068 [I-D.ietf-lisp] 1069 Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 1070 "Locator/ID Separation Protocol (LISP)", 1071 draft-ietf-lisp-05 (work in progress), September 2009. 1073 [I-D.ietf-v6ops-tunnel-security-concerns] 1074 Hoagland, J., Krishnan, S., and D. Thaler, "Security 1075 Concerns With IP Tunneling", 1076 draft-ietf-v6ops-tunnel-security-concerns-01 (work in 1077 progress), October 2008. 1079 [I-D.jen-apt] 1080 Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and 1081 L. Zhang, "APT: A Practical Transit Mapping Service", 1082 draft-jen-apt-01 (work in progress), November 2007. 1084 [I-D.russert-rangers] 1085 Russert, S., Fleischman, E., and F. Templin, "RANGER 1086 Scenarios", draft-russert-rangers-01 (work in progress), 1087 September 2009. 1089 [I-D.templin-intarea-seal] 1090 Templin, F., "The Subnetwork Encapsulation and Adaptation 1091 Layer (SEAL)", draft-templin-intarea-seal-07 (work in 1092 progress), October 2009. 1094 [I-D.templin-intarea-vet] 1095 Templin, F., "Virtual Enterprise Traversal (VET)", 1096 draft-templin-intarea-vet-04 (work in progress), 1097 September 2009. 1099 [I-D.wing-nat-pt-replacement-comparison] 1100 Wing, D., Ward, D., and A. Durand, "A Comparison of 1101 Proposals to Replace NAT-PT", 1102 draft-wing-nat-pt-replacement-comparison-02 (work in 1103 progress), September 2008. 1105 [IEN48] Cerf, V., "The Catenet Model for Internetworking", 1106 July 1978. 1108 [RFC1380] Gross, P. and P. Almquist, "IESG Deliberations on Routing 1109 and Addressing", RFC 1380, November 1992. 1111 [RFC1753] Chiappa, J., "IPng Technical Requirements Of the Nimrod 1112 Routing and Addressing Architecture", RFC 1753, 1113 December 1994. 1115 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1116 E. Lear, "Address Allocation for Private Internets", 1117 BCP 5, RFC 1918, February 1996. 1119 [RFC1955] Hinden, R., "New Scheme for Internet Routing and 1120 Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. 1122 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 1123 October 1996. 1125 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1126 Domains without Explicit Tunnels", RFC 2529, March 1999. 1128 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 1129 February 2000. 1131 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1132 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1133 December 2003. 1135 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1136 in IPv6", RFC 3775, June 2004. 1138 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1139 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1141 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1142 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1144 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1145 Internet Protocol", RFC 4301, December 2005. 1147 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 1148 (HIP) Architecture", RFC 4423, May 2006. 1150 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 1151 (MOBIKE)", RFC 4555, June 2006. 1153 [RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D. 1154 Green, "IPv6 Enterprise Network Analysis - IP Layer 3 1155 Focus", RFC 4852, April 2007. 1157 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1158 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1159 March 2008. 1161 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1162 for IPv6", RFC 5340, July 2008. 1164 [RRG] RG, R., "Routing Research Group (RRG), http:// 1165 trac.tools.ietf.org/group/irtf/trac/wiki/ 1166 RoutingResearchGroup", October 2009. 1168 [XBONE] Touch, J., "The X-Bone, 1169 http://www.isi.edu/touch/pubs/ngi97/x-bone-ngi97.pdf", 1170 March 1997. 1172 Author's Address 1174 Fred L. Templin (editor) 1175 Boeing Phantom Works 1176 P.O. Box 3707 MC 7L-49 1177 Seattle, WA 98124 1178 USA 1180 Email: fltemplin@acm.org