RFC 5720
Routing and Addressing in Networks with Global Enterprise Recursion (RANGER)
Part 1 of 7, more coming, bestie! 💖
Routing and Addressing in Networks with Global Enterprise Recursion (RANGER) 🦋
Okay so this is RFC 5720 🎀, and it's called Routing and Addressing in Networks with Global Enterprise Recursion (RANGER). It was written by F. Templin from Boeing Phantom Works. It's an Independent Submission, the category is Informational, the date is February 2010, and the ISSN is 2070-1721. The header doesn't list any RFC that it obsoletes or updates, so there's no drama there ✨
Abstract ✨
RANGER is an architectural framework for scalable routing and addressing in networks with global enterprise recursion 🌸 The word "enterprise network" stretches to cover a lot: an "enterprise" could be as small as a Small Office, Home Office (SOHO) network, as dynamic as a Mobile Ad Hoc Network, as complex as a multi-organizational corporation, or as big as the global Internet itself 🌈 These networks need an architected solution that coordinates routing and addressing plans, with accommodations for scalability, provider-independence, mobility, multihoming, and security 💅 These considerations matter most for existing deployments, but the same principles still apply to clean-slate approaches. RANGER addresses all of this and provides a comprehensive framework for IPv6/IPv4 coexistence 🫶
Status of This Memo 📝
This document is not an Internet Standards Track specification. It's published for informational purposes 🍓
This is a contribution to the RFC Series, independent of any other RFC stream. The RFC Editor chose to publish it at their discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741 🙈
Information about the current status of this document, any errata, and how to give feedback on it can be found at http://www.rfc-editor.org/info/rfc5720 💜
Copyright Notice ©️
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved ✨
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication. Please review these documents carefully, because they describe your rights and restrictions for this document 👑
Table of Contents 🧚
1. Introduction ....................................................3
2. Terminology .....................................................4
3. The RANGER Architecture .........................................7
3.1. Routing and Addressing .....................................7
3.2. The Enterprise-within-Enterprise Framework .................9
3.3. Virtual Enterprise Traversal (VET) ........................12
3.3.1. RANGER Organizational Principles ...................12
3.3.2. RANGER End-to-End Addressing Example ...............14
3.3.3. Dynamic Routing and On-Demand Mapping ..............14
3.3.4. Support for Legacy RLOC-Based Services .............16
3.4. Subnetwork Encapsulation and Adaptation Layer (SEAL) ......18
3.5. Mobility Management .......................................18
3.6. Multihoming ...............................................20
3.7. Implications for the Internet .............................20
4. Related Initiatives ............................................21
5. Security Considerations ........................................22
6. Acknowledgements ...............................................23
7. References .....................................................23
7.1. Normative References ......................................23
7.2. Informative References ....................................241. Introduction 🌷
RANGER is an architectural framework for scalable routing and addressing in networks with global enterprise recursion 💖 The term "enterprise network" covers a wide range of use cases and deployment scenarios. An "enterprise" can be as small as a SOHO network, as dynamic as a Mobile Ad Hoc Network, as complex as a multi-organizational corporation, or as large as the global Internet itself 🌍 These networks will need an architected solution that coordinates routing and addressing plans, with accommodations for scalability, provider-independence, mobility, multihoming, and security 🔥 These considerations are especially true for existing deployments, but the same principles apply even to clean-slate approaches. RANGER addresses these requirements and also provides a comprehensive framework for IPv6/IPv4 coexistence [COEXIST] ✨
RANGER provides a unifying architecture for enterprises that contain one or more distinct interior IP routing and addressing domains (or "Routing LOCator (RLOC) space"). Each distinct RLOC space contains one or more organizational groupings 🦋 Each RLOC space can coordinate its own internal addressing plans independently of the others, so limited-scope addresses (e.g., [RFC1918] private-use IPv4 addresses) can be reused with impunity, which gives unlimited scaling through spatial reuse 🌈 Each RLOC space therefore appears as an enterprise unto itself. Splitting the enterprise into one or more "sub-enterprises" (or "sites") along organizational lines is also possible, and it's beneficial in many scenarios 🧁 Without an architected approach, routing and addressing in this kind of framework would be fragmented, because the same address/prefix gets reused between disjoint enterprises 😭 With RANGER, though, multiple enterprises can be linked together to provide a multi-hop transit for nodes attached to enterprise edge networks. Those nodes use Endpoint Interface iDentifier (EID) addresses taken from an IP addressing range that is distinct from any RLOC space 🫶
RANGER is recursive: multiple enterprises can be joined together in a nested "enterprise-within-enterprise" fashion 🪆 Each enterprise also connects edge networks with nodes that configure addresses taken from EID space, which supports edge/core separation 🧚 This means the same RANGER principles that apply at lower levels of recursion can extend upwards to parent enterprises and ultimately to the core of the global Internet itself 👑 It's also worth considering whether today's global Internet is a limiting condition for recursion. In particular, could other internets be manifested as "parallel universes" and joined together at still higher levels of recursion? 🌌👀
The RANGER architecture is made real through composite technologies, including Virtual Enterprise Traversal (VET) [VET], the Subnetwork Encapsulation and Adaptation Layer (SEAL) [SEAL], and the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214]. Other mechanisms, such as IPsec [RFC4301], are also in scope for use within certain scenarios 🔐
Combinations with other technologies are also possible, and the issues that RANGER addresses either fully or partly include:
- scalable routing and addressing
- provider-independent addressing and its relation to provider-aggregated addressing
- site mobility and multihoming
- address and prefix autoconfiguration
- border router discovery
- router/host-to-router/host tunneling
- neighbor discovery over tunnels
- MTU determination for tunnels
- IPv6/IPv4 coexistence and transition
Note that while this document mainly uses IPv6 [RFC2460] running as a virtual overlay over IPv4 [RFC0791] networks as its illustrative example, the same architectural principles apply to any combination of IPvX virtual overlays over IPvY networks 🌸💅
2. Terminology ✨
okay bestie, let's lock in the vocab first 💅 these terms are the building blocks for everything else, so no skipping 🫶
Routing Locator (RLOC)
an IPv4 or IPv6 address assigned to an interface in an enterprise-interior routing region. ngl, private-use IP addresses are local to each enterprise, so the same private-use addresses can show up in totally separate enterprises 🙈
Endpoint Interface iDentifier (EID)
an IPv4 or IPv6 address assigned to an edge network interface of an end system. EID space has to be separate and distinct from any RLOC space 🦋
commons
an enterprise-interior routing region that provides a subnetwork for cooperative peering between the border routers of diverse organizations that may have competing interests. the big example is the Default-Free Zone (DFZ) of the global Internet 🌍 the enterprise-interior routing region within the commons uses an addressing plan taken from RLOC space.
enterprise
the same as defined in [RFC4852], where the enterprise deploys a unified RLOC space addressing plan within the commons but may also contain partitions with disjoint RLOC spaces and/or organizational groupings that can be considered as enterprises unto themselves. so an enterprise doesn't need to be "one big happy family" 🎀 instead it provides a commons for the cooperative interconnection of diverse organizations that may have competing interests (e.g., such as the case within the global Internet DFZ) 👑
enterprise networks are typically associated with large corporations or academic campuses, but the RANGER architectural principles apply to any network that has some degree of cooperative active management. so this definition stretches to home networks, small office networks, ISP networks, a wide variety of Mobile Ad Hoc Networks (MANETs), and even the global Internet itself 🌈
site
a logical and/or physical grouping of interfaces within an enterprise commons, where the topology of the site is a proper subset of the topology of the enterprise. a site can contain many interior sites, which can themselves contain many interior sites in a recursive fashion 🪆
throughout the rest of this document, the term "enterprise" refers to either enterprise or site. so the RANGER principles apply equally to enterprises and sites of any size or shape ✨ at the lowest level of recursive decomposition, a singleton Enterprise Border Router can be considered as an enterprise unto itself.
Enterprise Border Router (EBR)
a router at the edge of an enterprise that is also configured as a tunnel endpoint in an overlay network. EBRs connect their directly attached networks to the overlay network, and connect to other networks via IP-in-IP tunneling across the commons to other EBRs. this definition is meant as an architectural equivalent of the functional term "EBR" defined in [VET] 💜
Enterprise Border Gateway (EBG)
an EBR that also connects the enterprise to provider networks and/or to the global Internet. EBGs are typically configured as default routers in the overlay and provide forwarding services for accessing IP networks not reachable via an EBR within the commons. this definition is meant as an architectural equivalent of the functional term "EBG" defined in [VET], and it's synonymous with the term "default mapper" used in other contexts (e.g., [JEN]) 🧚
Ingress Tunnel Endpoint (ITE)
a host or router interface that encapsulates inner IP packets within an outer IP header for transmission over an enterprise-interior routing region to the RLOC address of an Egress Tunnel Endpoint (ETE) 📦
Egress Tunnel Endpoint (ETE)
a host or router interface that receives encapsulated packets sent to its RLOC address, decapsulates the inner IP packets, then delivers them to the EID address of the final destination 📬
overlay network
a virtual network manifested by routing and addressing over virtual links formed through automatic tunneling. an overlay network may span many underlying enterprises 🕸️
Provider-Independent (PI) prefix
an IPv6 or IPv4 EID prefix (e.g., 2001:DB8::/48, 192.0.2/24, etc.) that is routable within a limited scope and may also appear in enterprise mapping tables. PI prefixes that can appear in mapping tables are typically delegated to a Border Router (BR) by a registry but are not aggregated by a provider network. local-use IPv6 and IPv4 prefixes (e.g., FD00::/8, 192.168/16, etc.) are another example of a PI prefix, but these typically do not appear in mapping tables 🏠
Provider-Aggregated (PA) prefix
an IPv6 or IPv4 EID prefix that is either derived from a PI prefix or delegated directly to a provider network by a registry. not widely discussed, but it bears specific mention that a prefix taken from a delegating router's PI space becomes a PA prefix from the perspective of the requesting router 🤯
Additionally, RANGER provides an informative consideration of functional specifications and operational practices outlined in other documents. these documents include:
6over4
Transmission of IPv6 over IPv4 Domains without Explicit Tunnels [RFC2529]; functional specifications and operational practices for automatic tunneling of unicast/multicast IPv6 packets over multicast-capable IPv4 enterprises.
ISATAP
Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214]; functional specifications and operational practices for automatic tunneling of unicast IPv6 packets over unicast-only IPv4 enterprises.
VET
Virtual Enterprise Traversal (VET) [VET]; functional specifications and operational practices for automatic tunneling of both unicast and multicast IP packets with provisions for address/prefix autoconfiguration, provider-independent addressing, mobility, multihoming, and security. VET is descended from both 6over4 and ISATAP and is also known as "ISATAP version 2 (ISATAPv2)" 🧬
SEAL
Subnetwork Encapsulation and Adaptation Layer (SEAL) [SEAL]; an encapsulation sublayer that provides an extended IP Identification field and mechanisms for link MTU adaptation over tunnels 🔧
3. The RANGER Architecture ✨
this is where RANGER really shows off 👑 it enables scalable routing and addressing in networks with global enterprise recursion while still supporting legacy networks and services. the key is a framework that handles interconnection of diverse organizations across a commons that have a mutual spirit of cooperation but also the potential for competing interests 🤝 the sections below walk through the architecture using anticipated use cases:
3.1. Routing and Addressing
the Internet is literally going through "growing pains" 😭 there are signs that core Routing Information Base (RIB) scaling may not be sustainable over the long term, and that the remaining space for IPv4 address allocations may run out in the near future. so there's a real need for scalable routing and addressing solutions 📈 it must further be noted that the same solutions picked to fix global Internet routing and addressing scaling can apply just as well to large enterprises, or to any enterprise that would benefit from separating its core and edge addressing domains 🏢
RANGER supports scalable routing through an approach that parallels the "New Scheme for Internet Routing and Addressing" described in [RFC1955]. this approach is also commonly known as "map-and-encaps" 🗺️ here's how it goes: an Ingress Tunnel Endpoint (ITE) that has to forward an IP packet first consults a mapping system to find a mapping from the destination Endpoint Interface iDentifier (EID) to a Routing LOCator (RLOC) assigned to an Egress Tunnel Endpoint (ETE). the mapping system is typically maintained as a per-enterprise distributed database that's synchronized among a limited set of mapping agents. distributed database management alternatives include a routing protocol instance maintained by Enterprise Border Gateways (EBGs), a DNS reverse zone distributed among a restricted set of caching servers, etc. mapping entries get inserted into the mapping system through administrative configuration, automated prefix registrations, etc. 📝
RANGER allows an ITE to either consult the mapping system itself (while delaying or dropping initial IP packets) or forward initial packets to an EBG acting as a "default mapper" 🙋♀️ either way, the ITE gets a mapping reply it can use to populate its Forwarding Information Base (FIB). the choice of mapping approach must be considered with respect to the individual enterprise network scenario. for example, forwarding to an EBG may be more appropriate in some scenarios, while ITE self-discovery may be more appropriate in others. other mapping mechanisms are also possible depending on the specific enterprise scenario 🧩
after discovering the mapping, the ITE encapsulates inner IP packets in an outer IP header for transmission across the commons to the RLOC address of an ETE. the ETE then decapsulates the packets and forwards them over the next hop toward the EID address of the final destination 🎁 so the Routing Information Base (RIB) within the commons only needs to keep state about RLOCs and not EIDs. meanwhile, the synchronized EID-to-RLOC mapping state is kept by a smaller number of nodes and is not subject to oscillations due to link state changes within the commons. finally, EIDs are only routable within a limited scope inside edge networks (which can be as small as node-local scope in the limiting case) 🧘♀️
RANGER supports scalable addressing by picking a suitably large EID addressing range that is distinct and kept separate from any enterprise-interior RLOC addressing ranges. so it should come as no surprise that taking EID space from the IPv6 addressing architecture should lead to a viable, scalable addressing alternative, while taking EID space from the (already exhausted) IPv4 addressing architecture may not 💀🔥
3.2. The Enterprise-within-Enterprise Framework ✨
okay so big enterprises have traditionally handed out their routing info with Interior Gateway Protocols (IGPs) like Open Shortest Path First (OSPF) 🧚. Some of the really big ones even use an Exterior Gateway Protocol (EGP) internally instead of an IGP. So it's getting super common for large enterprises to run the Border Gateway Protocol (BGP) inside their own walls, totally separate from the BGP instance that keeps the RIB in the global Internet DFZ. it's giving independent BGP 💅
So a large enterprise can run an internal BGP instance across lots of internal Autonomous Systems (ASs). That means the enterprise can look like its own little internet 🌈, the only difference being that it has default routes pointing out to the true global Internet. And each internal AS can run BGP internally instead of an IGP, which means it can also look like its own lower-tier enterprise 🫶. This enterprise-within-enterprise setup can be recursed as broadly and as deeply as you want, for scaling, for organizational and/or functional compartmentalization, e.g., as shown in Figure 1 ✨.
,---------------.
,-' Global `-. <--------+
( IPv6/IPv4 ) ,----|-----.
`-. Internet ,-' ( Enterprises)
`+--+..+--+ ...+--+ ( E2 thru EN )
_.-|R1|--|R2+----|Rn|-._ `.---------/
_.---'' +--+ +--+ ...+--+ -.
,--'' ,---. `---.
,-' X5 X6 .---.. `-.
,' ,.X1-.. / \ ,' `. `.
,' ,' `. .' E1.2 '. X8 E1.m \ `.
/ / \ | ,--. | / _,.._ \ \
/ / E1.1 \ | Y3 `. | | / Y7 | \
; | ___ | | ` W Y4 |... | `Y6 ,' | :
| | ,-' `. X2 | `--' | | `'' | |
: | | V Y2 | \ _ / | | ;
\ | `-Y1,,' | \ .' Y5 / \ ,-Y8'`- / /
\ \ / \ \_' / X9 `. ,'/ /
`. \ X3 `.__,,' `._ Y9'',' ,'
` `._ _,' ___.......X7_ `---' ,'
` `---' ,-' `-. -'
`---. `. E1.3 Z _' _.--'
`-----. \---.......---' _.---''
`----------------''
<---------------- Enterprise E1 ---------------->
Figure 1: Enterprise-within-Enterprise FrameworkFigure 1 shows an enterprise 'E1' hooked up to the global IPv6/IPv4 Internet through routers 'R1' through 'Rn', alongside additional enterprises 'E2' through 'EN' that also connect to the global Internet 🌸. Inside the 'E1' commons there can be arbitrarily many hosts, routers, and networks (not drawn here) using addresses from RLOC space, and both encapsulated and unencapsulated IP packets can be forwarded across them 🦋. There can also be lots of lower-tier enterprises, 'E1.1' through 'E1.m' (the ones in the diagram), that interconnect inside the 'E1' commons through Enterprise Border Routers (EBRs), which are the 'X1' through 'X9' nodes. (Where 'X1' through 'X9' see 'R1' through 'Rn' as EBGs.) Inside each 'E1.*' enterprise, there can be arbitrarily many more lower-tier enterprises interconnecting through EBRs, drawn as 'Y1' through 'Y9' (where 'Y1' through 'Y9' see 'X1' through 'X9' as EBGs) 🍓. This recursive breakdown can nest as deep as you like and eventually bottoms out at singleton nodes, like the 'V', 'W', and 'Z' in the diagram 🧚.
Here's the tea: nodes like 'V', 'W', and 'Z' can be simple hosts, or they can be EBRs attaching arbitrarily complex edge networks with addresses from EID space 👑. Those edge networks can be as small as a home network behind a residential gateway, or as big as a major corporate or academic campus, a huge service provider network, etc. 💜
And again, this enterprise-within-enterprise setup can be nested recursively as broadly and deeply as you want 🙈. At the very top of the recursion, you can even treat the global Internet itself as an "enterprise" that interconnects lower-tier enterprises E1 through EN. All the RANGER architectural principles apply equally in that context 💖. RANGER also doesn't treat the global Internet as a hard limit on recursion. It allows other internets to show up as "parallel universes" and get joined together at even higher levels of recursion 🌈✨.
A real-life example: the future global Aeronautical Telecommunications Network (ATN), which the civil aviation industry is considering [BAUER], is going to be a large enterprise network that looks like its own internet, exactly like 'E1' in Figure 1 ✈️. Inside the ATN, there will be lots of Air Communications Service Provider (ACSP) and Air Navigation Service Provider (ANSP) networks organized as autonomous systems, exactly like the 'E1.*' enterprises in the diagram 🎀. The ACSP/ANSP network EBGs will take part in a BGP instance inside the ATN, and they may run their own independent BGP instances internally too, split further into lower-tier enterprises organized by region, organization, function, etc. compartments 🦋. Important tea: even though the ACSPs/ANSPs in the ATN all share the same goal of safety-of-flight for civil aviation services, they may have competing business, social, and political interests. So the ATN is not necessarily "one big happy family" 😭. That makes the model parallel the global Internet itself 💅.
This kind of operational setup may very well be the case for lots of next-generation enterprises 🔥. Specifically, even though all enterprises will need some mutual level of cooperative active management for their routing and addressing arrangements at a certain level, free market forces, business objectives, political alliances, etc. may drive internal competition 👑.
3.3. Virtual Enterprise Traversal (VET) 🦋
Inside the enterprise-within-enterprise framework from Section 3.2, the RANGER architecture is built on overlay networks made real through Virtual Enterprise Traversal (VET) ([VET], [RFC5214]) 🫶. The VET approach uses automatic IP-in-IP tunneling, where ITEs wrap EID-based inner IP packets inside RLOC-based outer IP headers so they can travel across the commons to ETEs 💖.
For every enterprise they connect to, EBRs that use VET set up a Non-Broadcast, Multiple Access (NBMA) interface called a "VET interface" 🌸. From the inner IP protocol's point of view, that interface sees all the other EBRs in the enterprise as potential single-hop neighbors. So in lots of enterprise scenarios, standard neighbor discovery mechanisms (e.g., router advertisements, redirects, etc.) can be used between EBR pairs 🧚. This leads to a data-driven model where neighbor relationships form based on traffic demand in the data plane, which in many cases can relax the need for dynamic routing exchanges across the overlay in the control plane ✨.
When you link multiple VET interfaces together, end-to-end traversal looks like multiple VET hops from the inner IP protocol's point of view 🍓. In that case, moving between VET interfaces uses a "re-encapsulation" approach: a packet leaving VET interface 'i' gets decapsulated, then re-encapsulated before it's forwarded into VET interface 'i+1' 💅. For example, if an end-to-end path between two EID-based peers crosses N distinct VET interfaces, a traceroute would show N inner IP forwarding hops, matching the parts of the path that traverse the VET interfaces 🌈.
VET and its related works specify the mechanisms and operational practices needed to make the RANGER architecture real 👑. Using VET together with SEAL (see Section 3.4) is essential in certain deployments, so you dodge issues with source address spoofing and black holing caused by path Maximum Transmission Unit (MTU) limitations 😭. (Using VET with IPsec [RFC4301] may also be necessary in some enterprise network scenarios 🔐.) The following sections talk about operational considerations and use cases within the VET approach 🎀.
3.3.1. RANGER Organizational Principles ✨
okay so bestie, Figure 2 is basically a vertical slice of the enterprise-within-enterprise setup from Figure 1 🦋. It's drawn sideways, so tilt your head 💅
+------+
| IPv6 |
" " " " " " " "" " " " " " " " " " " " " " " " |Server|
" <----------------- 2001:DB8::/40 (PA) " | S1 |
" 2001:DB8:10::/56 (PI) ----------------> " +--+---+
" . . . . . . . . . . . . . . . " |
" . . . . . . " |
" . +----+ v +--- + v +----+ v +----+ +-----+-------+
" . | V += e =+ Y1 += e =+ X2 += e =+ R2 +==+ Internet |
" . +-+--+ t +----+ t +----+ t +----+ +-----+-------+
" . | 1 . . 2 . . 3 . " |
" . H . . . . . " |
" . . . . . . . . . . . . . . " +--+---+
" <E1.1.1> <E1.1> <E1> " | IPv4 |
" 10/8 10/8 10/8 " |Server|
" " " " " " " " " " " " " "" " " " " " " " " | S2 |
<-- Enterprise E1 --> +------+
Figure 2: Virtual Enterprise TraversalInside this slice, every enterprise in the recursive E1 hierarchy is spanned by VET interfaces, labeled vet1 through vet3 🎀. Each VET interface here is a Non-Broadcast, Multiple Access (NBMA) interface that links up all the EBRs in the same enterprise 🌸. An enterprise within the E1 hierarchy can be a smaller chunk of a bigger RLOC space, OR it can set up its own independent RLOC space from a shared (but spatially reused) limited-scope prefix. That's why you see multiple disjoint copies of 10/8 in the diagram. Iconic reuse, honestly 👑
Now the coordination part 🫶. In RANGER, EBRs in lower-tier enterprises coordinate their EID prefixes with the EBGs that connect up to an upper-tier enterprise. An EID prefix can be either provider-independent (PI), meaning the EBR owns it, or provider-aggregated (PA), meaning the EBG delegates it. Either way, the EID prefixes have to be coordinated with the enterprise routing and mapping systems 😭
For PA prefixes, the EBR for each E1* enterprise gets an EID prefix delegation from a delegating EBG in a parent enterprise 💜. In this example, if R2 is the delegating router for 2001:DB8::/40, it can hand 2001:DB8::/48 to X2. Then X2 passes 2001:DB8::/52 down to Y1, and Y1 passes 2001:DB8::/56 down to V. The preferred way to do this recursive PA sub-delegation is DHCP Prefix Delegation [RFC3633], which also takes care of publishing the prefixes in the enterprise routing system ✨
For PI prefixes, individual EBRs (like V) register their PI prefixes (like 2001:DB1:10::/56) by sending Router Advertisement (RA) messages to the EBGs in the enterprise, which is how they claim ownership 🧚. When stronger authentication is needed, the EBRs can digitally sign those messages using the mechanisms specified for SEcure Neighbor Discovery (SEND) [RFC3971] 🔥. The EBGs that get the RAs (like Y1) verify the sender's credentials first, THEN register the prefixes in the enterprise mapping system. After that, they forward a proxied version of the RA up to the EBGs in their parent enterprises (like X2) 🌈. This proxying keeps going up the recursive hierarchy until a default-free commons is reached. (In this case, the proxying stops at R2 🍓.) Once the initial registration is done, the EBR that owns the PI prefixes has to keep sending more RAs on a regular basis to refresh the prefix expiration timers ⏰
3.3.2. RANGER End-to-End Addressing Example 🦋
In Figure 2, an IPv6 host H, which is deeply nested inside Enterprise E1, wants to reach IPv6 server S1, which lives somewhere on the IPv6 Internet 💖. H is plugged into a shared link with the IPv6/IPv4 dual-stack router V, and V advertises the IPv6 prefixes 2001:DB8:0:0::/64 and 2001:DB8:10:0::/64 🌸. H uses standard IPv6 neighbor discovery to find V as its default IPv6 router, which can forward packets off the local link. Then H configures addresses from both of those advertised prefixes 🫶. From V's point of view, Y1 is an EBG reachable over VET interface vet1, and it can forward packets toward S1 ✨. Meanwhile, Y1 is an EBR on the enterprise spanned by vet2, and it sees X2 as an EBG. Node X2 is an EBR on vet3, and it sees R2 as an EBG 💅. Finally, R2 is the EBR that connects E1 to the global Internet 🌈
3.3.3. Dynamic Routing and On-Demand Mapping 🧚
In the Figure 2 example, V, Y1, X2, and R2 each set up separate VET interfaces for every enterprise they connect to 🎀. That way they can discover routes through a dynamic routing protocol and/or mapping database lookups. Once tunnels vet1 through vet3 are up, the EBRs attached to a VET interface can run a dynamic routing protocol such as OSPVFv3 [RFC5340] and swap topology information over that VET interface using the NBMA interface model 👑. This is how each EBR finds the other EBRs on the link, through routing protocol control message exchanges 🍓
Next up, Figure 3 shows on-demand discovery of more specific routes 🔥. Here an IPv6 end system H is talking to a peer end system J, which sits in a different organizational entity inside E1:
+------+
| IPv6 |
" " " " " " " "" " " " " " " " " " " " " " " " |Server|
" <----------------- 2001:DB8::/40 (PA) " | S1 |
" 2001:DB8:10::/56 (PI) ----------------> " +--+---+
" . . . . . . . . . . . . . . . " |
" . . . . . . " |
" . +----+ v +----+ v +----+ +----+ +-----+-------+
" . | V += e =+ Y1 += e =+ X2 += =+ R2 +==+ Internet |
" . +-+--+ t +----+ t +----+ +----+ +-----+-------+
" . | 1 . . 2 . . . " |
" . H . . . . v . " |
" . . . . . . . . . . . e . " +--+---+
" . t . " | IPv4 |
" . . . . . . , . 3 . " |Server|
" . +----+ v +----+ . " | S2 |
" . | Z += e =+ X7 += . " +------+
" . +-+--+ t +----+ . "
" . | 4 . . . "
" . J . . . . . "
" . . . . . . . "
" 2001:DB8:20::/56 (PI) --------> "
" " " " " " " " " " " " " "" " " " " " " " "
<-- Enterprise E1 -->
Figure 3: On-Demand DiscoveryIn this setup, tunnel interfaces vet1 through vet4, plus the IPv6 PI prefix registrations, were all set up through VET enterprise autoconfiguration procedures 🧚♀️. When IPv6 end system H (address 2001:DB8:10::1) sends packets to peer J (address 2001:DB8:20::1), those packets go through V, then Y1, and finally reach X2 via default routes 💖. After that, unless X2 has an IPv6 FIB entry matching J, it has to figure out that J is reachable by a more direct route through X7 as the next hop across the E1 commons 😭
Here's the spicy part 🌶️. When X2 gets a packet on the vet2 interface with inner destination address J, it can do an on-demand mapping lookup by asking the enterprise mapping service, for example by checking the DNS reverse zone 🫶. Or, X2 can send the packet to a default router (like R2), which can then forward it to X7 and send back an ICMPv6 redirect message 🌸. When X2 receives that redirect, it can send an RA message to X7 to prove it's authorized to produce packets with a prefix matching source address J ✨. From then on, X2 can forward subsequent packets straight to X7 without going through R2 🦋
In some enterprise scenarios, dynamic routing and on-demand mapping can team up as complementary functions 👑. In other scenarios, it may be better to use only dynamic routing, or only on-demand mapping 💅
3.3.4. Support for Legacy RLOC-Based Services ✨
Okay bestie, the legacy stuff is lowkey the most important vibe check 🫶. Legacy hosts, routers, and networks that were already around in pre-RANGER deployments and already numbered their interfaces with RLOC addresses must see continued support for RLOC-based services for the long term, even while EID-based services roll out in new deployments. For example, a legacy IPv4-only node behind an IPv4 Network Address Translator (NAT) must still be able to reach legacy IPv4-only Internet services (e.g., http://example.com) long after RANGER and EID-based services are widely deployed 💅.
Back to the example diagrams! Virtual enterprise traversal across 'E1' gives a fully connected routing and addressing capability for EID-based services, but legacy nodes will still need access to RLOC-based services within connected or disjoint RLOC spaces for an extended (and possibly indefinite) period 🌸. For example, Figure 4 shows the applicable RLOC-based IPv4 service-access scenarios for the RANGER architecture when VET interfaces are used to link recursively nested enterprises together:
+------+
| IPv6 |
" " " " " " " "" " " " " " " " " " " " " " " " |Server|
" <----------------- 2001:DB8::/40 (PA) " | S1 |
" 2001:DB8:10::/56 (PI) -----------------> " +--+---+
" . . . . . . . . . . . . . . . " |
" . . . . . . " |
" . +----+ v +--- + v +----+ v +----+ +-----+-------+
" . | V += e =+ Y1 += e =+ X2 += e =+ R2 +==+ Internet |
" . +-+--+ t +----+ t +----+ t +----+ +-----+-------+
" . | 1 . . 2 . . 3 . " |
" . K L . . . . M . " |
" . . . . . . . . . . . . . . " +--+---+
" <E1.1.1> <E1.1> <E1> " | IPv4 |
" " |Server|
" " " " " " " " " " " " " "" " " " " " " " " | S2 |
<-- Enterprise E1 --> +------+Figure 4: Support for Legacy RLOC-Based Services
In a first instance, a legacy RLOC-based IPv4 client 'K' within enterprise 'E1.1.1' can access RLOC-based IPv4 service 'L' within the same enterprise as normal, and no encapsulation is needed at all 🎀.
Instead, 'K' discovers a "mapping" for 'L' through a simple lookup within the 'E1.1.1' enterprise-local name service, and sends packets to 'L' through unencapsulated RLOC-based IPv4 routing and addressing within the 'E1.1.1' commons. Honestly, this may be the preferred service-access model in many cases, even when EID-based IPv6 services are widely deployed 🦋. Reasons include an inability to replace legacy IPv4 applications, avoiding IPv6 header overhead, etc.
In a second instance, RLOC-based IPv4 client 'K' can access RLOC-based IPv4 server 'S2' on the legacy global IPv4 Internet in a few different ways, depending on how the recursively nested 'E1.*' enterprises are provisioned 🧚:
- if all of the recursively nested 'E1.*' enterprises are configured within the same IPv4 RLOC space, normal IPv4 forwarding will convey unencapsulated IPv4 packets from 'K' toward 'R2', which then acts as an IPv4 Network Address Translator (NAT) and/or an ordinary IPv4 Enterprise Border Router.
- if the recursively nested 'E1.*' enterprises are configured within disjoint RLOC spaces, all EBGs 'Y1', 'X2', and 'R2' can be configured to provide an IPv4 NAT capability (i.e., a recursive nesting of NATs within NATs). However, this approach places multiple instances of stateful NAT devices on the path, which can lead to an overall degree of brittleness and intolerance to routing changes 💀. Instead, 'R2' can act as a "Carrier-Grade NAT (CGN)", and 'V' can convey packets from 'K' to the CGN using IPv4-in-IPv6-in-IPv4 tunneling. The CGN can then decapsulate the inner, RLOC-based IPv4 packets and translate the IPv4 source addresses into global IPv4 source addresses before sending the packets on to 'S2' 🔥.
- 'K' could be configured as an EID-based, IPv6-capable node and use standard IPv6 routing to reach an IPv6/IPv4 translator located at an EBR for the enterprise in which 'S2' resides. The translator would then use IPv6-to-IPv4 translation before sending packets onwards toward 'S2'. These and other alternatives are discussed in [WING].
In a final instance, RLOC-based IPv4 client 'K' can access an RLOC-based IPv4 server 'M' in a different enterprise within E1 as long as both enterprises are configured over the same IPv4 RLOC space. If the enterprises are configured over disjoint IPv4 RLOC spaces, though, 'K' would still be able to reach 'M' by using EID-based IPv6 services, by using EID-based IPv4 services if an EID-based IPv4 overlay were deployed, or by using some form of RLOC-based IPv4 NAT traversal 👑. 'K' could also access server 'M' if both 'V' and 'X2' implemented an IPv6/IPv4 protocol translation capability. Finally, 'K' and/or 'M' could implement a bump-in-the-wire or bump-in-the-api IPv6/IPv4 protocol translation capability. Bestie, that's a whole menu of options 😭🌈.
3.4. Subnetwork Encapsulation and Adaptation Layer (SEAL) 🦋
Tunnel endpoints that depend on ICMP feedback from routers within the enterprise commons may be susceptible to undetected black holes, due to ICMP filtering gateways and/or off-path ICMP spoofing attacks from a node pretending to be a router. Furthermore, rogue nodes within enterprises that do not correctly implement ingress filtering can send spoofed packets of any kind, e.g., for the purpose of mounting denial-of-service and/or traffic amplification attacks targeting underprivileged links 🚨. Not okay, obviously.
The Subnetwork Encapsulation and Adaptation Layer (SEAL) provisions each encapsulated packet with a monotonically incrementing, extended Identification field (i.e., the 32-bit SEAL_ID) that tunnel endpoints can use as a nonce to detect off-path spoofing 🔐. Moreover, tunnel endpoints that use SEAL can keep operating correctly even if some or many ICMPs are lost. Finally, tunnel endpoints that use SEAL can adapt to subnetworks containing links with diverse MTU properties ✨.
3.5. Mobility Management 🚀
Enterprise mobility use cases must be considered along several different vectors 🗺️:
- nomadic enterprises and end systems may be satisfied to incur address renumbering events as they move between new enterprise network attachment points.
- mobile enterprises with PI prefixes may be satisfied by dynamic updates to the mapping system as long as they do not impart unacceptable churn.
- mobile enterprises and end systems with PA addresses/prefixes may require additional supporting mechanisms that can accommodate address/prefix renumbering.
Nomadic enterprise mobility is already handled by currently deployed technologies 💻. For example, transporting a laptop computer from a wireless-access hot spot to a home network LAN would let the nomadic device re-establish connectivity at the expense of address renumbering. That renumbering may be totally acceptable, especially for devices that do not need session persistence across mobility events and do not configure servers with addresses published in the global DNS.
Mobile enterprises with PI prefixes that use VET and SEAL can move between parent enterprise attachment points as long as they withdraw the prefixes from the mapping systems of departed enterprises and inject them into the mapping systems of new enterprises. When moving between the lower recursive tiers of a common parent enterprise, this kind of localized mobility may result in no changes to the parent enterprise's mapping system. Hence, a carefully arranged enterprise-within-enterprise framework may be able to dampen mobility-related churn 🧸. For enterprises that need in-the-network confidentiality, IKEv2 Mobility and Multihoming (MOBIKE) [RFC4555] may also be useful in this context.
Mobile enterprises and end systems that move quickly between disparate parent enterprise attachment points should not use PI prefixes if withdrawing and announcing the prefixes would impart unacceptable mapping/routing churn and packet loss 🙈. They should instead use PA addresses/prefixes that can be coordinated via a rendezvous service. Mobility management mechanisms such as Mobile IPv6 [RFC3775] and the Host Identity Protocol (HIP) [RFC4423] can be used to maintain a stable identifier for fast-moving devices, even as they move quickly between visited enterprise attachment points.
As a use case in point, consider an aircraft with a mobile router moving between ground station points of attachment ✈️. If the ground stations are located within the same enterprise, or within lower-tier sites of the same parent enterprise, it should be enough for the aircraft to announce its PI prefixes at its new point of attachment and withdraw them from the old one. This avoids excessive mapping system churn, since the prefixes need not be announced or withdrawn within the parent enterprise. In other words, the churn is isolated to lower layers of the recursive hierarchy. Note also that this movement would not entail an aircraft-wide readdressing event 🛫.
As a second example, consider a wireless handset moving between service coverage areas maintained by independent providers with peering arrangements 📱. Since the coverage range of terrestrial cellular wireless technologies is limited, mobility events may occur on a much more aggressive timescale than in some other examples. In this case, the handset may expect to incur a readdressing event for its access interface at least, and may be obliged to arrange for a rendezvous service linkage 💜.
It should specifically be noted that the contingency of mobility management solutions is not necessarily mutually exclusive, and must be considered in relation to specific use cases. The RANGER architecture is therefore naturally inclusive in this regard 🌈. In particular, RANGER could benefit from mechanisms that support rapid dynamic updates of PI prefix mappings without causing excessive churn.
3.6. Multihoming 🌐
Okay so multihoming is another one where we have to think from a bunch of angles, bestie 🧚. Inside an enterprise, EBRs can find multiple EBGs and use them in a fault-tolerant and load-balancing way 🔥, as long as they register their PI prefixes with each of those EBGs (see Section 3.3.1 🎀). Those registrations happen through Router Advertisement messages that percolate up through the recursive enterprise-within-enterprise hierarchy 🫧.
Case one: a major corporation's enterprise network that gets services from a bunch of ISPs 💼. The corp should be able to register its PI prefixes with all of its ISPs and use any of them for Internet access services ✨.
Case two: an aircraft with a diverse set of wireless links (e.g., VHF, 802.16, directional, SATCOM, etc.) ✈️. It should be able to select and use the most appropriate link(s) based on the phase of flight, and switch seamlessly between links as needed 🦋. Other examples include a nomadic laptop with both 802.11 and Ethernet links 💻, and a wireless handset with both CDMA wireless and 802.11 📱, etc.
Same as with mobility management, the solutions aren't necessarily mutually exclusive, and they can combine to suit use cases within the scope of the RANGER architecture 🌈💅.
3.7. Implications for the Internet 🌍
Okay, picking a mapping option can have big implications for applications, server selection, route determination, security, etc. 👀 Like, apps that expect all packets (including the initial ones) to have similar delays can get messed up by a scheme that adds non-negligible delay when initial packets get queued while a look-aside mapping table is consulted 😭. Other apps can have seriously slow startups if their initial packets get dropped during a mapping lookup event 💀.
So these factors kinda favor a scheme that can forward initial packets along a path with sub-optimal delay while a mapping lookup is performed in parallel, e.g., when a "default mapper" is used 🧚✨.
Generally speaking, proactive mapping-maintenance mechanisms may have scaling issues with the amount of updates they generate 📈, while reactive mechanisms may affect the delay of initial packets before the cached state is updated ⏳. Also on the list: attacks against the mapping mechanism, which may result in denial of service of the mapping cache 🚨.
Encapsulating packets in automatically created tunnels comes with its own pile of issues 🫠. There are obvious interactions between encapsulation overhead and the effective tunnel MTU, which can be addressed by SEAL and (when necessary) careful operational link arrangements 🎀. Plus, it's important to minimize the impact on the global routing table without also messing with the ability of legacy Internet networks to connect to those employing RANGER 🌸. As long as other nodes in the Internet need to connect to networks implementing RANGER, EID routes need to appear both in the mapping system and the global BGP routing tables. This can be handled by keeping the number of prefixes aggregated by RANGER to the bare minimum through efficient aggregation (e.g., one or a few [PREF]::/4 IPv6 prefixes instead of millions of [PREF]::/32 prefixes) 💖.
4. Related Initiatives 🧶
The origins of the RANGER architectural principles can be traced back to the "Catenet model for internetworking" ([CATENET], [IEN48], [RFC2775]), beginning as early as the mid-1970's 🕰️. After that, the deliberations of the ROAD group [RFC1380] and related efforts such as NIMROD [RFC1753] kept the concepts evolving 🔄. [RFC1955], "New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG", captures the high-level architectural aspects of the ROAD group deliberations 📜.
These foundational works had a huge influence on more recent developments 👑, including the X-Bone initiative [XBONE], which explored virtual topologies manifested through tunneling 🚇. Various tunneling approaches, including IP-in-IP ([RFC2003], [RFC4213]), 6over4 [RFC2529], and ISATAP [RFC5214], have evolved from the mid-1990's until today and are used in common, operational practice 🛠️. Tunnel-mode IPsec [RFC4301] is also commonly used for separating security domains within enterprises 🔐.
Right now, initiatives with similar properties to RANGER are under development within the IRTF Routing Research Group (RRG) and within IETF working groups such as LISP, SOFTWIRE, V6OPS, and others 👀. The RRG has seen numerous proposals, including the Locator-Identifier Split Protocol (LISP) [LISP], Six-One [VOGT], ILNP [ILNP], Internet vastly improved plumbing (Ivip) [WHITTLE], A Practical Transit-Mapping Service (APT) [JEN], and Virtual Aggregation [VA] 🦋. Still, other similar initiatives almost certainly exist 🤷♀️.
RANGER shares a lot of properties with these earlier works, but it uniquely gives a top-to-bottom articulation of how the various pieces fit together within a recursively nested "enterprise-within-enterprise" (or "network-of-networks") framework 🪆. In this way, it bears a striking resemblance to the network-of-networks model envisioned by CATENET 😭✨. RANGER also gives a detailed look at tricky issues like autoconfiguration, provider-independent addressing, border router discovery, tunnel MTU, multihoming, etc., which many other approaches have either overlooked or left for future work 🙈. A detailed analysis of RANGER applicability in various use case scenarios is provided in "RANGER Scenarios (RANGERS)" [RUSSERT] 💅.
5. Security Considerations 🔒
Communications between endpoints within different sites inside an enterprise are carried across a commons that joins organizational entities with a mutual spirit of cooperation 🤝, but between which there may be competing business/sociological/political interests 😬. Because of that, mechanisms that rely on feedback from routers on the path may become brittle or susceptible to spoofing attacks 🚨. This is due to the fact that IP packets can be lost due to congestion or packet-filtering gateways, and that the source addresses of IP packets can be forged 🫣. Moreover, IP packets in general can be generated by anonymous attackers, e.g., from a rogue node within a third-party enterprise that has malicious intent toward a victim 👿.
Path MTU Discovery is an example of a mechanism that relies on ICMP feedback from routers on the path and, as such, is susceptible to these issues 🙃. For IPv4, a common workaround is to disable Path MTU Discovery and let fragmentation occur in the network if necessary 🔧. For IPv6, lack of fragmentation support in the network rules out that option, so the mitigation typically recommended is to discard ICMP messages that contain insufficient information and/or to operate with the minimum IPv6 path MTU 🧯. This example extends to other mechanisms that either rely on or are enhanced by feedback from network devices; however, attack vectors based on non-ICMP messages are also a concern 👀.
The RANGER architecture supports effective mitigations for attacks such as distributed denial-of-service, traffic amplification, etc. 🛡️ In particular, when VET and SEAL are used, EBGs can use the 32-bit identification encoded in the SEAL header, as well as ingress filtering, to determine if a message has come from a topologically correct enterprise located across the commons 🎯. This lets enterprises use effective mitigations at their borders without needing mutual cooperation from other enterprises 💪. When source address spoofing by on-path attackers located within the commons is also a concern, additional securing mechanisms such as tunnel-mode IPsec between enterprise EBGs can also be used 🔐✨.
EBRs can obtain PI prefixes through arrangements with a prefix delegation authority 📮. After that, the EBR can announce and/or withdraw the prefixes within an enterprise by sending IPv6 Router Advertisements (RAs) 📢. In environments where additional authenticating mechanisms are necessary, the EBR can sign its RAs using SEcure Neighbor Discovery (SEND) [RFC3971] ✍️.
While the RANGER architecture doesn't address security considerations in itself, it proposes an architectural framework for functional specifications that do 🧠. Security concerns with tunneling, along with recommendations that are compatible with the RANGER architecture, are found in [HOAGLAND] 💜.
6. Acknowledgements 🫶
This work was inspired by the encouragement of the Boeing DC&NT network technology team and by the communications of the IESG 🌟.
Many individuals have contributed to the architectural principles that form the basis for RANGER over the course of many years 🎉. The following individuals gave specific feedback on the RANGER document itself: Jari Arkko, Brian Carpenter, Eric Fleischman, Joel Halpern, Thomas Henderson, Steven Russert, Dallas Thomas, Robin Whittle 💖.
7. References 📚
7.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
7.2. Informative References ✨
These are the extra reads that back up the story without being required to get it right. Bestie, there are a lot of them, so grab a snack 🍓
[CATENET]Pouzin, L., "A Proposal for Interconnecting Packet Switching Networks", Proceedings of EUROCOMP, Bronel University, p. 1023-1036, May 1974. 📜[COEXIST]Arkko, J. and M. Townsley, "IPv4 Run-Out and IPv4-IPv6 Co-Existence Scenarios", Work in Progress, July 2009. 🌈[BAUER]Bauer, C. and S. Ayaz, "ATN Topology Considerations for Aeronautical NEMO RO", Work in Progress, September 2009. ✈️[LISP]Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", Work in Progress, September 2009. 🦋[HOAGLAND]Hoagland, J., Krishnan, S., and D. Thaler, "Security Concerns With IP Tunneling", Work in Progress, October 2008. 💀[JEN]Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and L. Zhang, "APT: A Practical Transit Mapping Service", Work in Progress, November 2007. 🧚[RUSSERT]Russert, S., Fleischman, E., and F. Templin, "RANGER Scenarios", Work in Progress, September 2009. 🎀[SEAL]Templin, F., Ed., "The Subnetwork Encapsulation and Adaptation Layer (SEAL)", RFC 5320, February 2010. 💖[VET]Templin, F., Ed., "Virtual Enterprise Traversal (VET)", RFC 5558, February 2010. 💜[WING]Wing, D., Ward, D., and A. Durand, "A Comparison of Proposals to Replace NAT-PT", Work in Progress, September 2008. 🌸[IEN48]Cerf, V., "The Catenet Model for Internetworking", July 1978. 📼[ILNP]Atkinson, R., "ILNP Concept of Operations", Work in Progress, December 2008. 🫶[RFC1380]Gross, P. and P. Almquist, "IESG Deliberations on Routing and Addressing", RFC 1380, November 1992. 🗂️[RFC1753]Chiappa, N., "IPng Technical Requirements Of the Nimrod Routing and Addressing Architecture", RFC 1753, December 1994. 🌿[RFC1918]Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. 🏠[RFC1955]Hinden, R., "New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. 🍭[RFC2003]Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. 🎁[RFC2529]Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999. 🌙[RFC2775]Carpenter, B., "Internet Transparency", RFC 2775, February 2000. 🔍[RFC3633]Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. 🧁[RFC3775]Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. 🚲[RFC3971]Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. 🔐[RFC4213]Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005. 🌉[RFC4301]Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. 🛡️[RFC4423]Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006. 🪪[RFC4555]Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006. 📱[RFC4852]Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D. Green, "IPv6 Enterprise Network Analysis - IP Layer 3 Focus", RFC 4852, April 2007. 🏢[RFC5214]Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008. 🚇[RFC5340]Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008. 🗺️[VA]Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and L. Zhang, "FIB Suppression with Virtual Aggregation", Work in Progress, October 2009. 🫧[VOGT]Vogt, C., "Six/One: A Solution for Routing and Addressing in IPv6", Work in Progress, October 2009. 🍑[WHITTLE]Whittle, R., "Ivip (Internet Vastly Improved Plumbing) Architecture", Work in Progress, August 2008. 🚰[XBONE]Touch, J., "The X-Bone", March 1997,http://www.isi.edu/touch/pubs/ngi97/x-bone-ngi97.pdf🦄
Author's Address 🎀
Here's where to find the author, the one and only Fred L. Templin 👑
Fred L. Templin
Boeing Phantom Works
P.O. Box 3707 MC 7L-49
Seattle, WA 98124
USA
EMail: fltemplin@acm.orgThat's the whole thing, bestie! 🌈💖 RFC 5720 is wrapped up, and you made it through every last reference 🫶✨
📦 where this page comes from
- ietf: rfc5720 2010-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms