RFC 6139
Routing and Addressing in Networks with Global Enterprise Recursion (RANGER) Scenarios
Routing and Addressing in Networks with Global Enterprise Recursion (RANGER) Scenarios 🎀
Okay bestie, let's get into RFC 6139! 🫶 Here's the title block tea:
- Number: 6139, ISSN 2070-1721 🔢
- Category: Informational, so it's not a Standards Track spec, just ideas and vibes 💅
- Stream: Independent Submission 🌸
- Date: February 2011 📅
- Authors: S. Russert, Ed. (Unaffiliated), E. Fleischman, Ed., and F. Templin, Ed. (both from Boeing Research & Technology) 👩💻
- Obsoletes / Updates: none listed in the title block 🙌
Abstract
RANGER (that's RFC 5720 🧠) is an architectural framework for scalable routing and addressing. It's incrementally deployable for scalability, provider independence, mobility, multihoming, traffic engineering, and security, so it's giving main character energy 🔥. This doc walks through a bunch of use cases to show off what the architecture can do, and shows how RANGER brings back the network-within-network principles the Internet was originally built on for sustained growth 🌈.
Status of This Memo
Not an Internet Standards Track spec. It's published for informational purposes only 📚.
This is a contribution to the RFC Series, separate from 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 the RFC Editor approves for publication aren't a candidate for any level of Internet Standard. See Section 2 of RFC 5741 for the details 💅.
For the current status, errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc6139 🔗.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. ©️
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date this doc was published. Read those carefully, because they spell out your rights and restrictions for this doc 📜⚖️.
Table of Contents
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Approach ........................................................7
4. Scenarios ......................................................11
4.1. Global Concerns ...........................................11
4.1.1. Scaling the Global Inter-Domain Routing Core .......11
4.1.2. Supporting Large Corporate Enterprise Networks .....13
4.2. Autonomous System Concerns ................................16
4.3. Small Enterprise Concerns .................................16
4.4. IPv4/IPv6 Transition and Coexistence ......................18
4.5. Mobility and MANET ........................................21
4.5.1. Global Mobility Management .........................21
4.5.2. First-Responder Mobile Ad Hoc Networks (MANETs) ....23
4.5.3. Tactical Military MANETs ...........................24
4.6. Provider Concerns .........................................27
4.6.1. ISP Networks .......................................27
4.6.2. Cellular Operator Networks .........................28
4.6.3. Aeronautical Telecommunications Network (ATN) ......28
4.6.4. Unmanaged Networks .................................31
5. Mapping and Encapsulation Concerns .............................32
6. Problem Statement and Call for Solutions .......................32
7. Summary ........................................................33
8. Security Considerations ........................................33
9. Acknowledgements ...............................................34
10. References ....................................................34
10.1. Normative References .....................................34
10.2. Informative References ...................................341. Introduction ✨
The Internet keeps needing to support more users, more internetwork connections, and more complicated policy requirements 😵💫. All that growth strains the infrastructure and demands new solutions. Some complementary approaches to upgrading Internet tech are being pursued at the IETF at the same time: translation (including Network Address Translation (NAT)), tunneling (map and encapsulate), and native IPv6 [RFC2460] deployment. RANGER [RFC5720] describes the architectural elements of a "map and encapsulate" approach that also helps the other two approaches 🦋. This doc discusses RANGER operational scenarios.
RANGER gives you an architectural framework for scalable routing and addressing. It covers scalability, provider independence, mobility, multihoming, and security for the next-generation Internet 🚀. Honestly, the RANGER principles aren't new 🙈. They trace back to the deliberations of the ROAD group [RFC1380], and even earlier works like NIMROD [RFC1753] and the Catenet model for internetworking [CATENET] [IEN48] [RFC2775]. [RFC1955] captures the high-level architectural aspects of the ROAD group deliberations in a "New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG" 📖.
The Internet has grown tremendously since these principles were first developed, and that evolution makes these capabilities even more needed 📈. It's become a critical resource for business, for government, and for individual users throughout the developed world 🌍. RANGER carries these historic principles forward and creates a ubiquitous enterprise network structure. That structure can represent collections of network elements, from the granularity of a singleton router all the way up to an entire Internet 🧚. It uses border routers that configure tunnel endpoints to connect potentially recursively nested networks. Each enterprise network may use completely independent internal Routing Locator (RLOC) address spaces, which supports a virtual overlay network connecting edge networks and devices addressed with globally unique Endpoint Interface iDentifiers (EIDs) 💜. The RANGER virtual overlay can transcend traditional administrative and organizational boundaries. In its purest form, this overlay network could therefore span the entire Internet and restore the end-to-end transparency envisioned in [RFC2775] 👑.
RANGER drew early observations from the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214] [RFC5579], but now uses Virtual Enterprise Traversal (VET) [RFC5558], the Subnetwork Encapsulation and Adaptation Layer (SEAL) [RFC5320], and other mechanisms including IPsec [RFC4301] as its functional building blocks 🧩. This doc describes use cases and shows how the RANGER mechanisms apply. Complementary mechanisms (e.g., DNS, DHCP, NAT, etc.) are included to show how the various pieces can work together 🫧. It expands on the concepts introduced in "IPv6 Enterprise Network Scenarios" [RFC4057] and "IPv6 Enterprise Network Analysis - IP Layer 3 Focus" [RFC4852], and shows how the enterprise network model generalizes to a broad range of scenarios 🌸. These use cases are here to provide examples, invite criticism and comment, and explore the potential for creating the next-generation Internet using RANGER 🎀. Heads up: you need to already know RANGER, VET, SEAL, and ISATAP before this part hits different 🤓.
(Part 1 of 11, more parts are coming, bestie! 🦋)
2. Terminology ✨
okay bestie, let's get into the vocab, because these terms are the foundation for everything else 💅
Internet Topology Hierarchy 🌈 the Internet Protocol (IP) natively supports a topology hierarchy made of increasing aggregations of networked elements. Network interfaces of devices get grouped into subnetworks, and subnetworks get grouped into bigger aggregations. Subnetworks can optionally be grouped into areas, and those areas can be grouped into an autonomous system (AS). Or, subnetworks can be directly grouped into an AS, no areas needed. The foundation of the IP Topology Hierarchy is the AS, which sets the administrative boundaries of a network deployment, including its routing, addressing, quality of service, security, and management. Intra-domain routing happens within an autonomous system, and inter-domain routing links autonomous systems together into a "network of networks" (Internet). It's giving architecture 🏛️✨
Routing Locator (RLOC) 📍 an address assigned to an interface in an enterprise-interior routing region. Note that RLOC space is local to each enterprise network, so it's very much a "what happens in the enterprise stays in the enterprise" situation 🙈
The IPv4 public address space in use today can be considered as the RLOC space for the global Internet, treating the whole thing as one giant "enterprise network" 🌍💜
Endpoint Interface iDentifier (EID) 🎀 an address assigned to an edge network interface of an end system. Note that EID space is global in scope, and it must be separate and distinct from any RLOC space. Not the same vibe as RLOC at all 🦋
commons 🤝 an enterprise-interior routing region that provides a subnetwork for cooperative peering between the border routers of diverse organizations, even ones that may have competing interests. An example of a commons 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. Competing companies sharing a space and still getting along? iconic 👑
enterprise network 🏢 the same as defined in [RFC4852]. The enterprise network deploys a unified RLOC space addressing plan within the commons, but it may also contain partitions with disjoint RLOC spaces and/or organizational groupings that can be considered enterprises unto themselves. So an enterprise network 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 (like what's happening in the global Internet Default-Free Zone, honestly the ultimate group project energy 💀).
Historically, enterprise networks are associated with large corporations or academic campuses. However, in RANGER an enterprise network can exist at any IP Topology Hierarchy level 🧚 The RANGER architectural principles apply to any networked entity with some degree of cooperative active management. That means this definition stretches to home networks, small office networks, a whole bunch of Mobile Ad hoc Networks (MANETs), and even the global Internet itself. Main character energy for every network 🌸
site 🌷 a logical and/or physical grouping of interfaces within an enterprise network commons, where the topology of the site is a proper subset of the topology of the enterprise network. A site can contain many interior sites, which can themselves contain many interior sites, recursively. Like nesting dolls but make it networking 🪆
Throughout the rest of this document, the term "enterprise" refers to either enterprise or site. In other words, 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 an enterprise unto itself. A one-router party is still a party 🎉
Enterprise Border Router (EBR) 🚪 a node at the edge of an enterprise network that is also configured as a tunnel endpoint in an overlay network. EBRs connect their directly attached networks to the overlay network, and they connect to other networks via IP-in-IP tunneling across the commons to other EBRs. This definition is meant as the architectural equivalent of the functional term "EBR" defined in [RFC5558]. It's also synonymous with the term "xTR" used in other contexts (e.g., [LISP]) ✨
Enterprise Border Gateway (EBG) 🌉 an EBR that also connects the enterprise network to provider networks and/or to the global Internet. EBGs are typically configured as default routers in the overlay, and they provide forwarding services for accessing IP networks that aren't reachable via an EBR within the commons. This definition is meant as the architectural equivalent of the functional term "EBG" defined in [RFC5558], and it's synonymous with the term "default mapper" used in other contexts (e.g., [APT]). The EBG is the one with the connections to the outside world, and it's lowkey the MVP 👑
overlay network 🦄 a virtual network made by routing and addressing over virtual links that get formed through automatic tunneling. An overlay network may span many underlying enterprise networks. Layers on layers, it's so giving 🧁
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 enterprise networks. Tunnels without the paperwork, iykyk 🙈
ISATAP 🌺 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214] [RFC5579]. Functional specifications and operational practices for automatic tunneling over unicast-only enterprise networks. So 6over4's unicast-only cousin 🫶
VET 🌟 Virtual Enterprise Traversal (VET) [RFC5558]. Functional specifications and operational practices that provide a functional superset of 6over4 and ISATAP. In addition to both unicast and multicast tunneling, VET also supports address/prefix autoconfiguration, plus additional encapsulations such as IPsec, SEAL, UDP, etc. VET really said "why not both" and then did it all 💅🔥
SEAL 🍓 Subnetwork Encapsulation and Adaptation Layer (SEAL) [RFC5320]. A functional specification for robust packet identification and link MTU adaptation over tunnels. SEAL supports effective ingress filtering and adapts to subnetworks configured over links with diverse characteristics. Adaptable and secure, that's a whole personality 🦋
Within the RANGER architectural context, the SEAL "subnetwork" and the RANGER "enterprise" should be considered identical abstractions. Same energy, different name 🌈
Provider-Independent (PI) prefix 🌙 an 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 network mapping tables. PI prefixes that can appear in mapping tables are typically delegated to a BR by a registry, but they aren't aggregated by a provider network. Independent and proud of it 😤💖
Provider-Aggregated (PA) prefix 🧸 an EID prefix that is either derived from a PI prefix or delegated directly to a provider network by a registry. Although it isn't widely discussed, it's worth mentioning that a prefix taken from a delegating router's PI space becomes a PA prefix from the perspective of the requesting router. Plot twist, the same prefix can be PI for one router and PA for another 🤯✨
Customer Premises Equipment (CPE) Router 🏠 a residential or small office router that provides IPv4 and/or IPv6 support. The user or the service provider may manage the router. Home base, but make it networked 🏡💜
Carrier-Grade NAT (CGN) ⭐ a special (usually high capacity) IPv4-to-IPv4 NAT deployed within the service provider network that serves multiple subnets. Big, powerful, and doing a lot of translating behind the scenes. Respect, honestly 🙌
3. Approach ✨
okay so the RANGER [RFC5720] architecture is basically going for the goals from [RFC1955] 🦋 and bestie, the list is iconic:
- No Changes to Hosts
- No Changes to Most Routers
- No New Routing Protocols
- No New Internet Protocols
- No Translation of Addresses in Packets
- Reduce the Routing Table Size in All Routers
- Use the Current Internet Address Structure
so the RANGER enterprise network is a cooperative networked collective 🫶 with a shared goal (business, social, political, etc.) 💅 An enterprise network can be simple or complex and can run at any IP Topology Hierarchy level. RANGER mostly focuses on encapsulation, but it's also compatible with both native and translated routing and addressing 🌸
RANGER lets a protocol and/or addressing system get connected in a virtual overlay across an untrusted transit network, aka the "commons" 🎀 It doesn't show every possible use, but Figure 1 shows how RANGER makes a distributed network across a commons, which could run a different IP version, routing protocol, or addressing system. literally main character energy 👑
.--------------. .--------------. .-------------.
/ \_ _/ \_ _/ \
\ Enterprise A / \ Commons / \ Enterprise B /
\_ _ _ _ _ _ _ / \_ _ _ _ _ _ _ / \_ _ _ _ _ _ _/
Domains
Network / IPvx IPvy IPvz
Protocol \ IPv6 IPv4 IPv6
IP Security secured unsecured secured
Mgmt Domain Entity A ISP Entity B
/
| Public Addresses Private Addresses Public Addresses
Addressing |Private Addresses Public Addresses Private Addresses
| PA Addresses PI Addresses PA Addresses
\ PI Addresses PA Addresses PI Addresses
Figure 1. RANGER Links Distributed Enterprise NetworksThe RANGER concepts can be applied recursively 🔥 They can be used at any level of the IP Topology Hierarchy to make an enterprise-within-enterprise setup that stretches past traditional AS, area, or subnetwork boundaries. This uses border routers that set up tunnel endpoints so the recursively nested enterprise networks can talk over a virtual overlay that goes right past traditional administrative and organizational boundaries 🦋 In its purest form, this overlay could span the entire Internet and restore end-to-end transparency [RFC2775] ✨
The RANGER architecture takes the best current practice insights from older encapsulation systems, as they're currently written up in the Virtual Enterprise Traversal [RFC5558] and Subnetwork Encapsulation and Adaptation Layer [RFC5320] functional specifications. The result is an architecture and protocol system that can build arbitrarily complex, scalable IP deployments supporting both unicast and multicast routing and addressing systems 💖
RANGER supports scalable routing through a recursively nested enterprise-within-enterprise network capability 🧚 The fundamental building block is the Enterprise Border Router (EBR) (see Figure 2). The EBR is the limiting factor for RANGER recursion, and in certain contexts a singleton EBR can be viewed as an enterprise network unto itself 😭 Traditional network infrastructures can be extended to support complex structures solely by adding EBRs, with no other modification to any networked entity 🫶
An EBR can be a commercial off-the-shelf router, a tactical military radio, an aircraft mobile router, etc. 🌈 It can also be an end system (e.g., a laptop computer, a soldiers' handheld device, etc.) with an embedded gateway function [RFC1122] 💅
Provider-Edge Interfaces
x x x
| | |
+--------------------+---+--------+----------+ E
| | | | | n
| I | | .... | | t
| n +---+---+--------+---+ | e
| t | +--------+ /| | r
| e I x----+ | Host | I /*+------+--< p I
| r n | |Function| n|**| | r n
| n t | +--------+ t|**| | i t
| a e x----+ V e|**+------+--< s e
| l r . | E r|**| . | e r
| f . | T f|**| . | f
| V a . | +--------+ a|**| . | I a
| i c . | | Router | c|**| . | n c
| r e x----+ |Function| e \*+------+--< t e
| t s | +--------+ \| | e s
| u +---+---+--------+---+ | r
| a | | .... | | i
| l | | | | o
+--------------------+---+--------+----------+ r
| | |
x x x
Enterprise-Edge Interfaces
Figure 2. Enterprise Border Router (EBR)EBRs connect networks and end systems to one or more enterprise networks through a whole repertoire of interface types 🎀 Enterprise-interior interfaces attach to a commons. Provider-edge interfaces support traditional routing relationships up the IP Topology Hierarchy, and enterprise-edge interfaces support traditional relationships down the IP Topology Hierarchy. Internal virtual interfaces are typically loopback interfaces or VMware-like host-in-host interfaces 🧚
VET interfaces support RANGER recursion and IP-in-IP encapsulation 🔥 They get configured over provider-edge, enterprise-interior, or enterprise-edge interfaces so recursion can happen horizontally or vertically within the IP Topology Hierarchy. A VET interface may be configured over several underlying interfaces that all connect to the same enterprise network. This creates a link-layer multiplexing capability that can provide several advantages (see [RFC1122], Section 3.3.4). One important advantage is continuous operation across failovers between multiple links attached to the same enterprise network, without any need for readdressing 🌸
Figure 3 shows two enterprise networks (each with their own internal addressing and routing systems) that talk over a virtual overlay network across a commons 💜 The virtual overlay is made by tunneling, which links enterprise networks that are separated by geographical remoteness, protocol incompatibility, or both. An ingress EBR (iEBR) inside the left enterprise network tries to forward encapsulated packets across the commons to the egress EBR (eEBR) inside the right enterprise network 🦋
The figure shows that the eEBR assigns a Routing Locator (RLOC) address on its interface to the commons' interior IP routing and address space, while the destination host assigns an Endpoint Interface iDentifier (EID) on its enterprise-edge interface. The iEBR uses a mapping system to discover the RLOC of an eEBR on the path to the destination EID address. A distinct mapping system is maintained within each recursively nested enterprise network instance operating at a specific level of the IP Topology Hierarchy. RANGER uses the mapping system to join peer enterprise networks through a virtual overlay across a commons ✨
Mapping System RLOC EID
. (BGP, DNS, etc.) . .
.---.------. .----------. . .------.---.
/ . \ / \ . / . \
/ (O) iEBR------/--------------\------eEBR * \
\ / \ Commons / \ /
\_ _ _ _ _ _ / \_ _ _ _ _ _ / \_ _ _ _ _ _/
Enterprise Network A Enterprise Network B
Figure 3. The RANGER ModelEBRs MUST configure both RLOC and EID addresses and/or prefixes 🫶 Autoconfiguration is coordinated with Enterprise Border Gateways (EBGs) that connect to the next-higher layer in the recursive hierarchy, as specified in VET. Standard mechanisms, including DHCP [RFC2131] [RFC3315] and Stateless Address Autoconfiguration (SLAAC) [RFC4862], are used for this purpose 💅
Similarly, EBRs need a way to discover other EBRs and EBGs that can be used as enterprise network exit points 👑 VET specifies mechanisms for border router discovery using the global DNS and/or enterprise-local name services such as Link-Local Multicast Name Resolution (LLMNR) [RFC4795] 🌈
The mapping system is a distributed database that is synchronized among a limited set of mapping agents. Database synchronization can be achieved by many different protocol alternatives. The most commonly used alternatives are either the Border Gateway Protocol (BGP) [RFC4271] or the Domain Name System (DNS) [RFC1035]. Mapping-system databases can be populated by many different mechanisms, including administrative configuration and automated prefix registrations 🍓
EBRs MUST forward initial packets for which they have no mapping to an EBG 😭 The EBG in turn forwards the packet toward the final destination and returns a redirect to inform the EBR of a better next hop if necessary. The EBR then receives a mapping reply that it can use to populate its Forwarding Information Base (FIB). It then encapsulates each forwarded packet in an outer IP header for transmission across the commons to the remote RLOC address of an eEBR. The eEBR in turn decapsulates the packets and forwards them to the destination EID address. The Routing Information Base (RIB) within the commons only needs to maintain state regarding RLOCs and not EIDs. The synchronized EID-to-RLOC mapping state is not subject to oscillations due to link state changes within the commons 🧚 RANGER supports scalable addressing by selecting a suitably large EID addressing range that is distinct from any enterprise-interior RLOC addressing ranges 💜
4.1. Global Concerns ✨
4.1.1. Scaling the Global Inter-Domain Routing Core 🌈
okay so routing and addressing problems on the Internet have been around for MANY years, and people have written about them a lot [RADIR-PROB-STATE] 😭. IPv4 [RFC0791] address space is super limited. Regional Internet Registry (RIR) allocation is passing the "very painful" Host Density (HD) ratio threshold of 86% (that's 192M allocated addresses) [RFC3194]. So exhaustion of the IPv4 address pool is predicted within the next two years [IPv4POOL], [HUSTON-END] 💀. IPv6 promises to fix the address shortage with a much bigger address space, but the transition is costly and could make the BGP problems below even worse 🙈. Richer interconnection, more multihoming (especially with provider-independent (PI) addresses), and the desire for traffic engineering through finer control of routing have all led to super-linear growth of BGP routing tables in the Default-Free Zone, or "DFZ", of the Internet. That growth is putting more and more pressure on router capacity and technology costs, and it's not sustainable for the long term within the current Internet routing framework 📉.
RANGER allows the coordinated reuse of addresses from enterprise to enterprise by making RLOC address spaces independent of one another 🦋. Figure 4 shows how the RANGER architecture lets separate address spaces be used for RLOC and EID addressing in the Internet. This gives you more endpoint address space, especially with IPv6, and it also reduces the load on BGP in the Internet routing core ✨. Note that Figure 4 could represent variants of RFC 4057 scenarios 1 and 2 🎀.
EID RLOC EID
PA Spaces PI
Allocation Registration
.-------------------------------. ^
/ Internet Commons \ |
| .---------------------------. | |
2001:DB8::/40 | / Enterprise A \ | 2001:DB8:10::/56
| |/ 10.1/16 \ | ^
| || .-------------------------. || |
V || / Enterprise A.1 \ || |
2001:DB8::/48 || | 10.1/16 | || 2001:DB8:11::/56
|| \_________________________/ / |
| \ / |
| --------------------------- |
| |
| .---------------------------. |
| / Enterprise B \ |
2001:DB8:100::/40 | | 10.1/16 | | 2001:DB8:12::/56
| \____________________________/ |
\ /
\_______________________________/Figure 4. Enterprise Networks and the Internet
RLOC address spaces are totally independent of one another, since they're only used inside an enterprise network (remember that an enterprise network can exist at any level of the IP Topology Hierarchy 🧚). This setup lets each RLOC space keep its own independent routing system, which helps avoid the inherent scaling issues you'd get if one giant monolithic routing system handled everything 💜.
EID address space can be provider-aggregated (PA) or PI, and it can come from either IPv4 or IPv6 🌸. EID addresses (barring the use of Network Address Translation (NAT)) are globally unique, even when they're only routable within a more limited scope (e.g., in their own edge networks) 🫶.
The IRTF routing research group is looking into a Preliminary Recommendation for a routing architecture [RFC6115] that gives a taxonomy for routing scaling solutions for the global Internet inter-domain routing core 🔥. RANGER presents a core/edge separation architecture within this taxonomy, and it's iconic because it shows applicability all the way from the core out to edge networks through its recursive enterprise-within-enterprise framework 👑. RANGER is also compatible with a bunch of schemes that address routing scaling issues, including "APT: A Practical Transit Mapping Service" [APT], "FIB Suppression with Virtual Aggregation" [GROW-VA], "Locator/ID Separation Protocol (LISP)" [LISP], and others 💅.
4.1.2. Supporting Large Corporate Enterprise Networks 🏢
Each enterprise network operator must be able to manage its internal networks and use the Internet infrastructure to hit its performance and reliability goals ⭐. Enterprise networks that are multihomed or have mobile components often need provider-independent addressing and the ability to coordinate with multiple providers without renumbering "flag days" [RFC4192] [RFC5887] 😩. RANGER provides a way to coordinate addressing plans and inter-enterprise routing, with full support for scalability, provider independence, mobility, multihoming, and security 💖.
_.--------------------._
_.---'' -.
,--'' ,---. `---.
,-' X5 X6 .---.. `-.
,\' ,.X1-.. / \ ,' `. `.
,\' ,' `. .' E2 '. X8 Em \ `.
/ / \ | ,--. | / _,.._ \ \
/ / E1 \ | Y3 `. | | / Y7 | \
; | ___ | | ` W Y4 |... | `Y6 ,' | :
| | ,-' `. X2 | `--' | | `'' | |
: | | V Y2 | \ _ / | | ;
\ | `-Y1,,' | \ .' Y5 / \ ,-Y8'`- / /
\ \ / \ \_' / X9 `. ,'/ /
`. \ X3 `.__,,' `._ Y9'',' ,'
` `._ _,' ___.......X7_ `---' ,'
` `---' ,-' `-. -'
`---. `. E3 Z _' _.--'
`-----. \---.......---' _.---''
`----------------''
<------------------- Global IPv4 Internet ------------------>Figure 5. Enterprise Networks within the Internet Commons
Figure 5 shows enterprise networks E1 through Em connected to the global IPv4 Internet through Enterprise Border Routers (EBRs) X1 through X9 🌈. These same border nodes also act as Enterprise Border Gateways (EBGs) that provide default routing services for nodes inside their own enterprise networks 🧁. The global Internet forms a commons that the various enterprise networks connect across, as cooperating yet potentially competing entities 🤝. Inside each enterprise network there may be arbitrarily many hosts, routers, and networks (not shown in the diagram) that use addresses from that enterprise network's RLOC space. Both encapsulated IP packets with (global-scoped) EID addresses and unencapsulated IP packets with (enterprise-local) RLOC addresses can be forwarded over them 🦋.
Each enterprise network may contain lower-tier networks. For instance, the singleton EBR "W" in network E2 lives in a lower-tier network (say E2.1), and it (along with any of its attached devices) may be considered an enterprise unto itself 🧚. W sees Y3 and Y4 as EBGs, and those in turn see X5 and X6 as EBGs that connect to a common provider network (in this case, the Internet) 💫. Each enterprise network has one or more Endpoint Interface iDentifier (EID) address prefixes used for addressing nodes on edge networks 🎀. RANGER's map-and-encaps approach separates the mapping of EIDs to Routing Locators (RLOCs) from the Routing Information Base (RIB) in the Internet commons, which are assigned to EBR router interfaces 🗺️. Not only does BGP in the Internet commons only need to keep state about RLOCs in the Internet commons, it also has fewer unique routes to maintain, because only routes to EBRs are needed. That means traffic engineering can be accommodated via the mapping database 🙌.
In Figure 5, enterprise network E2 represents a corporation with multiple locations and connections to multiple ISPs 🏬. The corporation recently merged with another corporation, so its internal network now has two disjoint RLOC address spaces, but neither of the formerly separate entities can bear the burden of address renumbering 😵. Enterprise network E2 can use a suitably large IPv4 and/or IPv6 EID addressing range (one that is distinct from any enterprise-interior RLOC addressing range) to support end systems on enterprise-edge networks with no disruption to preexisting address numbering 🍓.
As EBRs get deployed to connect enterprise networks together, ordinary routers inside the enterprise network keep working as normal and deliver both ordinary and encapsulated packets across the existing Internet infrastructure and the network's own RLOC commons 🔥. Legacy IPv4 services that bind to RLOC addresses continue to be supported even as EID-based services roll out 💜. When a legacy IP client and server are within the same RLOC address space, they simply communicate using RLOC-based routing across the enterprise network commons 🫶. If the client and server are not within the same RLOC address space, they communicate through some form of network address and/or protocol translation (see [RFC5720], Section 3.3.4 for details) 🔁. EBRs from the various enterprise networks publish their EID prefixes to an enterprise-specific mapping system, so that other EBRs from the various enterprise networks can consult that mapping system to get the RLOC address of one or more EBRs that serve the EID prefix 🗂️.
As an example, when an end system connected to W in E2.1 has a packet to send to node Z in enterprise network E3, W sends the packet to EBR Y4 👀. Y4 encapsulates the packet in an outer IP packet with its own source address and the RLOC address of the next-hop EBR as the destination, which in this case is X6 🎁. X6 decapsulates the packet and looks up the destination EID prefix, getting the RLOC of X7 as the next hop. X6 then encapsulates the IPv6 packet in a packet with RLOC address X6 as the source and X7 as the destination 🌊. X7 decapsulates the packet on receipt and forwards it through its enterprise-edge interface to node Z 🏁.
This example is just one thread out of the many that are possible with RANGER, so see [RFC5720] and [RFC5558] for other options and details 🧵. Many enterprise networks that use proxies and firewalls at their border routers today will want to keep that control over their enterprise borders, and using RANGER doesn't rule out those configurations (for example, see Section 4.3) 🛡️✨.
4.2. Autonomous System Concerns 🌸
okay so, an enterprise network like E2 in Figure 5 above can totally be its own AS inside the IP Topology Hierarchy 💅 one way to set E2 up is to make each of its enterprise components a recursive AS, and then link them together using the RANGER constructs ✨ this is getting more and more common for really big corporations (Boeing's corporate enterprise network is a good example 🛫). These networks run an internal instance of BGP that links all the corporate-internal ASs together. That instance is separate from the BGP instance that keeps the RIB inside the global Internet Default-Free Zone (DFZ) 🔥 people usually set it up this way for scaling or administrative reasons 🫶
the corporate entity is basically an Internet all to itself, just with separate default routes that lead out to the true global Internet 🌈 so from the rest of the Internet's point of view, E2 looks like a regular IP Topology Hierarchy AS. and since RANGER supports recursion, each AS inside that network can use BGP internally instead of an IGP 😭 which means it can also be made up of its own little internal Internet, recursively, bestie 🧚 this enterprise-within-enterprise setup can keep going as broadly and as deeply as needed to meet the deployment's requirements, like scaling, unique administration, and/or functional compartmentalization 💜
4.3. Small Enterprise Concerns 💖
so global enterprise networks running at the autonomous system level of the IP Topology Hierarchy have multiple geographical regions, multiple ISPs, and complicated internal structures, which is exactly where RANGER techniques shine ✨ but honestly, every other enterprise network (big or small) can be served by RANGER too 🦋 for example, Small and Home Office (SOHO) networks might only have a few computers on one network segment, or they could grow into bigger setups with security islands, internal routers and switches, etc. 🍓
the thing a small enterprise really cares about is being able to grow the network, switch ISPs, or expand to more locations WITHOUT having to readdress the existing network 🎀 picture a small company with one location in California 🌴 its ISP connection runs through a router that acts as a Network Address Translator and firewall for the company. The addresses of the few computers ("Wksta") come from the [RFC1918] private address space 💅
ISP
-------|----- Wksta Wksta
| Firewall |_____________|____________|
| NAT |
-------------
Figure 6. Simple SOHO Networkthis setup has been totally fine for the few employees doing software development, since nothing inside the site needs to be exposed to the outside world 🙈 but now the company needs a web presence because the product launch is coming up fast 🚀 so the network manager deploys an EBR, either as a co-resident function on the existing NAT/firewall platform (as shown in Figure 7) or on a separate platform 💖
the EBR has a provider-edge interface connected to the ISP 🔌 it also has interfaces for the preexisting workstations, the preexisting enterprise-edge interfaces connecting those workstations, and enterprise-edge interfaces connecting several network segments. Those segments are linked by routers that host web servers, workstations, and other enterprise network services 🧁 a VET interface gets configured over the new service network so the servers can be reached from the public Internet 🌍
ISP
|
+------|-----+
| <|--
| VET2 < |
| <|---
| |
| | Server Server
| VET1 <|--------|-----------|-------
| |
| +--------+ | Wksta Wksta
| |Firewall| |_____________|____________|
| | NAT | |
| +--------+ |
+------------+
Figure 7. RANGER Serving the Small Companyin this new setup, the EBR keeps the services inside a "demilitarized zone (DMZ)" 🛡️ that the public Internet can access, WITHOUT exposing the other corporate assets, which are still protected by the preexisting firewall/NAT functions 🫶
then, shortly afterward, a venture capital infusion 💸 lets the company speed up product development and marketing by adding programmers in Tokyo and sales offices in New York and London 🗽🇬🇧 these new branches connect over Virtual Private Network (VPN) links across the Internet, and a new VET interface (VET2) gets configured over those links to form a brand-new sub-enterprise 👑
ISP
|
+------|-----+
| <|------------London
| VET2 < |
| <|--------------------New York
| |
| | Server Server
| VET1 <|--------|-----------|-------
| |
| +--------+ | Wksta Wksta
| |Firewall| |_____________|____________|
| | NAT | |
| +--------+ |
+------------+
Figure 8. RANGER for Multiple Locations4.4. IPv4/IPv6 Transition and Coexistence ✨
okay so end systems and networks need to be ready for IPv4 and IPv6 for the long haul 🫶 that means IPv4 apps on IPv4 stacks, IPv4 apps on IPv6 stacks, IPv4 apps on dual stacks, and IPv6 or IPv4/IPv6-capable apps on both IPv6 and dual stacks. Encapsulation AND translation will probably both be needed so apps, enterprises, and providers can bring IPv6 in, including every in-between state, without global coordination or a "flag day" 💅 (no one has to flip the switch on the same day, periodt).
The RANGER architecture makes it easy to add IPv6 addressing to existing IPv4 end systems and routers (aka via dual stack) and to add IPv6 networks next to the IPv4 networks you already have 🦋 RANGER, together with VET and SEAL, lets packets that started in one protocol travel across infrastructure that runs another protocol or routing system. Figure 1 shows how RANGER mixes different edge (EID) and core (RLOC commons) technologies, and it's not just about IP version either. security, management, and addressing can be mixed too, which is so iconic 🌈
RANGER supports end-to-end communication across arbitrarily long paths made of enterprise networks chained together by EBRs. When IPv6 is the Endpoint Interface iDentifier (EID) space, each EBR can give out a globally unique set of IPv6 EID prefixes, and there are no scaling limits because the IPv6 address space is so huge 🌸 For example, Figure 9 shows two end systems, "H" and "J", separated by a bunch of enterprise networks linked by VET interfaces called "vet1" through "vet4". The path between "H" and "J" goes through the EBR path "V->Y1->X2->X7->Z":
+------+
| IPv6 |
|Server|
" " " " " " " "" " " " " " " " " " " " " " " " | S1 |
" " +--+---+
" . . . . . . . . . . . . . . . " |
" . . . . . . " |
" . +----+ 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 . . . . . "
" . . . . . . . "
" "
" " " " " " " " " " " " " " "" " " " " " " " "Figure 9. EBR Waypoint Navigation Using IPv6 🧚
When every EBR on the path gets its own unique set of IPv6 EID prefixes (and registers them in the right routing/mapping tables), IPv6 can be used for navigation, with each EBR on the path acting as a waypoint 🍓 And this still works even when IPv4 is the enterprise-local Routing Locator (RLOC) address space, with lots of IPv4 hops between each pair of neighbouring EBRs. Main character energy ✨
RANGER also gives you a compatible framework for other supporting mechanisms, like protocol translation, the application-layer side of IPv4/IPv6 transition covered in [RFC4038], and the DNS issues for IPv6 from [RFC4472] 💜 For cases where IPv4 applications are still in use, RANGER expects IPv4<->IPv6 translation to be handled by network-based [BEHAVE-v6v4] and/or end-system stack-based protocol translation systems (e.g., [RFC2767]). Figure 10 shows the NAT - Protocol Translation (NAT-PT)-equivalent translation happening in the VET router, and Figure 11 shows the "Bump-In-the-Stack" (BIS)-equivalent translation happening in end systems ([RFC2767]). These examples cover scenarios that RFC 4852 doesn't mention 🙈
IPv4 App A IPv4 App B
_____________ _____________
|_TCP or UDP__| |_TCP or UDP__|
|____IPv4_____| |____IPv4_____|
______|______ _______|_____
/ \ / \
| IPv4-Only | | IPv4-Only |
| Site 1 | | Site 2 |
\_____________/ \_____________/
______|______ ______|_______
|____IPv4_____| _____________ |____IPv4_____|
|NAT-PT-equiv_| / \ |NAT-PT-equiv_|
|_TCP or UDP__| | Internet | |_TCP or UDP__|
|____IPv6_____| | (RANGER) | |____IPv6_____|
|__VET/SEAL___| \_____________/ |__VET/SEAL___|
\_______________/ \___________/
Figure 10. Translation in RoutersIn Figure 10, an IPv4 app on end system A just does its thing, and the end system sends IPv4 packets over the IPv4-only site network. An Enterprise Border Router (EBR) receives those packets and translates them into IPv6 packets with a NAT-PT-equivalent process. Then the EBR encapsulates the packets in IPv4 and sends them across the RANGER-enabled Internet to Site 2, where an EBR for Site 2 receives and decapsulates them. That EBR uses NAT-PT-equivalent translation to turn the resulting IPv6 packet back into an IPv4 packet, which gets delivered across the Site 2 IPv4-only network to IPv4 app B on end system B 💖
IPv4 App A IPv4 App B
_____________ _____________ _____________
|_TCP or UDP__| / \ |_TCP or UDP__|
|____BIS______| | Internet | |____BIS______|
|____IPv6_____| | (RANGER) | |____IPv6_____|
|__VET/SEAL___| \_____________/ |__VET/SEAL___|
\_______________/ \___________/
Figure 11. BIS-Style Translation in Dual-Stack End SystemsFigure 11 shows the simpler approach, where BIS translation happens inside dual-stack end systems ([RFC2767]) 🎀 Here the IPv4 app on dual-stack end system A forms an IPv4 payload, and that payload gets transformed into an IPv6 packet inside the end system's own protocol stack. That IPv6 packet can then be encapsulated and sent across the Internet, decapsulated, and handed to the dual-stack end system running IPv4 app B. The BIS-equivalent process on end system B reverses the translation, so the IPv4-only app gets an IPv4 packet it can actually read ✨
Other stuff besides IP protocol translation can pop up during IPv4-IPv6 transition. [RFC4038] calls out things like IPv4/IPv6-capable apps running on IPv4-only stacks, DNS responses that include addresses from both IP versions, and how hard it is to support multiple versions of an app. It also suggests converting apps to dual support as the preferred solution 🌈 These issues are outside the scope of this document, so we're leaving them for another day 🫠
4.5. Mobility and MANET 🦋
4.5.1. Global Mobility Management
Okay so ubiquitous wireless access means you can get connected pretty much anywhere 🌈✨ Vehicles and even people can host networks that move right along with them 🚗💖 Like, commercial aircraft networks need to handle nomadic networks, local mobility, and global mobility, where the connection point between the plane and the ground station can hop from one continent to another 🛫🌍 Mobile networks need to be able to use provider-independent (PI) as well as provider-aggregated (PA) address prefixes 🎀 Some apps, like voice, need quick or seamless connection handoffs, which is also called session survivability 📞💅 Internet routing should not be unduly disrupted by mobility, so when mobile nodes or edge networks move, it should not cause big ripples of routing protocol traffic, especially in the DFZ 🫶 Not the vibe we want 💀
When a RANGER enterprise network is overlaid on the Internet, mobile nodes or mobile routers (the ones connecting arbitrarily complex edge networks or enterprise networks) can move between different points of attachment and still stay reachable, without creating excessive routing churn 🦋✨ In a commercial airline scenario, an aircraft with a mobile router moves between ground station points of attachment (which might be on different continents) without readdressing its onboard networks 🛩️🌸 Figure 12 shows an aircraft bouncing between four different access points: two that are part of Air Communications Service Provider (ACSP) 1, one in ACSP2, and the last one directly to the Air Navigation Service Provider (ANSP) 🧚 ACSP1 and ACSP2 might be on different continents in this example, so a traditional Mobile IP Home Agent scheme [RFC3775] [RFC5944] would give really inefficient paths for one ACSP or the other 😭 The aero enterprise network is an overlay that spans both continents and allows efficient paths by providing multiple entry and exit points (only one, R2, is shown) 👑
Aircraft - - - - - - ,.- - - - - -.- - ->
. , . . +------+
. , . . | IPv6 |
. , . . |Server|
" ." " " ", "" " " ." " " " " .? " " " " " | S1 |
" . , . . " +--+---+
" . , . . " |
" . ... . . . . . +----+ " |
" . . . . . =+ X3 + " |
" . v +--- + . v . . v +----+ ? |
" . e =+ Y1 + . e . . e . +----+ +--------+
" . t +----+ . t +----+ . t . =+-R2-+==+Internet|
" . 1 . . 2 =+ X2 + . 3 . +----+ +--------+
" . . . +----+ . . " |
" . . . . . . . " +------+
" <ACSP1> <ACSP2> <ANSP> " | IPv4 |
" " |Server|
" - - vet4 - - " | S2 |
" " " " " " " " " " " " " "" " " " " " " | S2 |
<-- Aero Enterprise Network --> +------+Figure 12. Commercial Airplane Mobility
When the plane moves between ground stations located within the ACSP1 enterprise network, no routing or mapping changes need to be made outside ACSP1 🛬 Plus, if link-layer multiplexing (as mentioned in Section 3 above) is used, then the VET interface network layer is unaware of the movement 🙈 When the point of access moves to ACSP2, no changes are made outside the aero enterprise network 🌷 When the aircraft moves between ground stations of the same parent enterprise network (as shown by the two different links from the aircraft to ACSP1 in Figure 12), the aircraft announces its PI prefixes at its new point of attachment and withdraws them from the old one 🔁 The worldwide Internet sees no change, and mapping-system churn is confined to ACSP1, since the prefixes don't need to be announced or withdrawn within the parent aero enterprise network. In other words, the churn is isolated to lower tiers of the recursive hierarchy 🧁 This can be contrasted with the deprecated mobility solution previously fielded by Connexion, which pushed disruptive BGP changes into the Internet routing system to support mobile onboard networks 🙅♀️💔
4.5.2. First-Responder Mobile Ad Hoc Networks (MANETs)
Many emerging network scenarios need autoconfiguration of Mobile Ad hoc Networks (MANETs) 🚨💜 When first responders need networking for communications and coordination between teams, RANGER lets each team or agency quickly stand up a network, then use the autoconfiguration described in [RFC5558] to coordinate address/prefix autoconfiguration and discover the border routers teams and agencies need to interconnect 🚓🔥
For example, Figure 13 shows how police units arriving on a scene with no network infrastructure can create a wireless network using vehicle-mounted 802.11 hotspots, with one or more cellular, 802.16, or satellite links to reach the Internet 📡🌈 In this example, the California Highway Patrol sets up an incident management center with a satellite link to the Internet and vet1 serving network L1 🛰️💖 The Los Angeles County Sheriff team sets up network L1.1 at their field headquarters, and the Altadena police force creates the L1.2 network with their mobile units 🚔✨ R2 is the router that serves as an EBG for border routers X3 and X4, which connect networks L1.2 and L1.1, respectively. X3 serves vet3, and X4 serves vet2 🦋
In like manner, the Angeles National Forest creates enterprise network F1, with the San Gabriel Ranger District setting up enterprise network F1.1 and the Fire Response Team Enterprise Network F1.2 🌲🍓 R1 and R2 discover one another and become peer EBRs across the Internet by means of manual configuration 🤝 In network L1, individual PI address prefixes are announced from L1.2 and L1.1 to L1, and R2 advertises them to the satellite ISP 📶 R1 receives a PA prefix from its WiMAX provider and delegates parts of the prefix to X1 and X2 🫧 R2 also runs an IGP with R1, advertising the PI prefixes to R1 and learning the PA prefixes there 🧠💅
+------+
| IPv6 |
|Server|
" " " " " " " "" " " " " " " " " " " " " " " " | S1 |
" Law Enforcement Enterprise Network " +--+---+
" 2001:DB8:10::/56 (PI) ----------------> " |
" . . . . . . . +--- + . . . . " |
" . =+ X3 +===========. . " +-----+-------+
" . +----+ v +--- + . v +----+ | +
" . | V += e . . . . e =+ R2 +==+ |
" . +-+--+ t . . +----+ t +----+ | |
" . | 3 . . vet2 + X4 += 1 . " | |
" . H1 . . +----+ . " | |
" . . . . . . . . . . . . . . " | |
" <L1.2> <L1.1> <L1> " | |
" 10/8 10/8 10/8 " | |
" " " " " " " " " " " " " " "" " " " " " " " | Internet |
| |
" " " " " " " "" " " " " " " " " " " " " " " " | |
" USDA Forest Service Enterprise Network " | |
" <----------------- 2001:DB8::/40 (PA) " | |
" . . . . . . . +--- + . . . . " | |
" . =+ X1 +===========. . " | |
" . +----+ v +--- + . v +----+ | |
" . | J += e . . . . e =+ R1 +==+ |
" . +-+--+ t . . +----+ t +----+ | |
" . | 6 . . vet5 + X2 += 4 . " +-----+-------+
" . H2 . . +----+ . " |
" . . . . . . . . . . . . . . " +--+---+
" <F1.2> <F1.1> <F1> " | IPv4 |
" 10/8 10/8 10/8 " |Server|
" " " " " " " " " " " " " " "" " " " " " " " | S2 |
+--+---+Figure 13. First-Responder MANET
4.5.3. Tactical Military MANETs 🦋
okay so military networks have totally different policy vibes than civilian ones 🫶 Their info security rules mean every bit of info gets labeled into specific classifications. The Bell-LaPadula model [BELL-LaPADULA] is how they stretch that info security policy into networked environments. That stretch creates communications security (COMSEC), and RANGER concepts slot right into its routing and addressing pieces, no cap 💅
Figure 3 shows RANGER making a VET interface between the enterprise-interior (network) interfaces of two Enterprise Border Routers (EBR) sitting in separate enterprise networks, A and B 🎀 When this is applied to enterprise networks working above the subnetwork level of the IP Topology Hierarchy, the VET interface uses IP-in-IP encapsulation. That matches a popular COMSEC approach (IPsec -- [RFC4301]) ✨ When the same RANGER concept is applied at the subnetwork level, it lines up with an older form of COMSEC (Link Layer Encryption). And when it's applied to enterprise networks that are singleton EBR nodes (aka the interface level of the IP Topology Hierarchy), it matches a third military COMSEC alternative (Link Encryption) 🧚
The last bit shows how flexible RANGER is for describing COMSEC approaches through structured relationships in the IP Topology Hierarchy 💖 The real power is that every entity in Figure 3 can itself be a simple or complex network structure, working at any level of the IP Topology Hierarchy. (Complex structures are architectures that got extended by RANGER recursion.) For example, the commons in the figure could be an interface, a subnetwork, an autonomous system, or an Internet. Enterprise networks A and B can each be a single end system, a subnetwork, an autonomous system, or an Internet 👑
Tactical military MANETs are different from traditional networks in lots of ways, but the biggest are how mobile the tactical deployments are and how the MANETs form themselves 🔥 Each networked tactical entity runs a radio/router, so there can be orders of magnitude more routers in military MANETs (they're way denser) than in traditional civilian networks 😭 That means even small deployments have comparatively large router populations next to non-MANET deployments. And bigger router populations make protocol scalability issues way more sensitive. It gets worse, though, because IP protocols react unfavorably to signal intermittence. That dampens and constrains router scaling even when mitigation techniques are used 💀 Signal intermittence is itself a feature of mobility and of the radio signal propagation in local deployment environments (things like terrain, foliage, buildings, weather, distance, etc.). War fighting also pushes war fighters into more defensible terrain features, and a lot of those naturally cut down radio signal propagation, which makes signal intermittence even more likely 🌸
RANGER recursion lets MANETs naturally encourage route aggregation and scaling through simple "plug and play" hierarchical arrangements. Those arrangements match organizational structures and don't need complex manual configuration 🫶 For example, a MANET autonomous system can benefit from RANGER recursion by being physically made up of enterprise networks that are autonomous systems themselves. This relationship can be recursively extended vertically as deep as needed, so you get route aggregation between entities that share common mission assignments at different levels of abstraction 🌈 Since MANET routing is still an active research topic, just know these structures may or may not use routing protocols like their civilian IP Topology Hierarchy peers. For example, because of how BGP behaves in highly mobile environments, the Exterior Gateway Protocol (EGP) used to link ASs may or may not be BGP. And if it is BGP, it may have unusual timer settings 🙈 Still, whatever IGP and EGP are used, RANGER constructs can increase route aggregation between entities sharing common mission assignments, which helps route scaling ✨
Tactical military MANETs often need to talk to stationary infrastructures 🍓 By localizing mobility inside an enterprise network, the mobility-friendly protocols can stay localized, and their aggregation results get presented to the stationary network using a protocol the stable network supports. This also cuts down how much mobility messes with routing and addressing systems as reported to the stationary infrastructure 🦋 Mobility-induced route fluctuations (e.g., routing flaps) can still happen, but their impact can get dampened if RANGER constructs are used to localize them in lower tiers of the IP Topology Hierarchy. For example, enterprise network A in Figure 3 can be a military MANET, while enterprise network B might be a stationary military entity. Remember that A and B interface at a specific IP Topology Hierarchy level, but RANGER mechanisms can physically extend them. For instance, enterprise network A can be a MANET enterprise that's physically a network-of-networks Internet, and it interfaces to enterprise network B as if it were an autonomous system. That gives enterprise network B a more stable, aggregated view of the enterprise network A Internet than it would have if it were directly aware of A's various sub-enterprise components 👑
Another key thing that makes tactical military networks special is that radio networks run at a different classification level than the data they carry 😭 So tactical military networks have several orders of magnitude more COMSEC devices than equivalently sized stationary military deployments. The number of COMSEC devices is a function of how many mobile war-fighting entities there are. This can cause some serious scalability issues inside the overlay COMSEC network relationships themselves 💀 COMSEC scaling problems show up in several dimensions. Here's the thing though: just like RANGER recursion was used vertically to build enterprise-within-enterprise structures for better routing aggregation and scaling, RANGER recursion also lets you authorize route-optimized transactions between peer enterprises (at the same IP Topology Hierarchy level). That improves COMSEC aggregation and scaling of the network overlay system 🧚 The RANGER use of VET also combines with the Subnetwork Encapsulation and Adaptation Layer (SEAL) to provide robust packet identification and maximum transmission unit (MTU) link adaptation services over tunnels. These capabilities protect against both source address spoofing and black holes caused by MTU limitations 🔥
4.6. Provider Concerns 🌈
Network providers must have a way to support the protocol transitions and network types mentioned above and still stay reliable and financially sound 💅 RANGER gives ways to support general Internet Service Providers (ISPs), cellular operator networks, and specialized networks like the Aeronautical Telecommunications Network (ATN) ✨
4.6.1. ISP Networks 🎀
Internet service provider networks give you a commons where Customer Premises Equipment (CPE) routers [CPE-RTRS] connect, and those routers connect arbitrarily complex customer networks 💖 This is true whether the ISP allows direct customer-to-customer communications or whether all communications get forwarded through ISP provider-edge equipment 🫶
The ISP commons has to potentially support hundreds of thousands of CPE routers (or more). So the ISP may be obliged to assign private IPv4 address allocations (instead of public ones) as RLOCs for CPE routers 😭 That creates a "nested NATs" scenario, which can increase the overall brittleness that comes with NAT traversal 💀
To deal with that brittleness, the ISP can deploy "Carrier-Grade NATs" (CGNs) [INCR-CGN] that give a second level of RLOC address translation on the path from the CPE to the Internet 🧚 When the CGNs are also configured as EBGs, CPE routers can discover them as default routers for reaching EID-based services, using the EBG discovery mechanisms specified in VET 👑
"Scenarios and Analysis for Introducing IPv6 into ISP Networks" [RFC4029] talks about both ISP backbone network and customer connection transition considerations. But this document focuses on router-to-router tunneling use cases 🌸 So the ISATAP mechanism (which only supports host-to-router or host-to-host tunneling) isn't mentioned as a candidate technology. Early point solutions (e.g., the Tunnel Setup Protocol (TSP) [RFC5572], the Simple IPv6-in-IPv4 Tunnel Establishment Procedure (STEP) [STEP], etc.) were recommended. This document suggests that RANGER, VET, and SEAL would also be suitable solutions in these networks ✨
4.6.2. Cellular Operator Networks 📱
[RFC4215] gives a (dated) "Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks" 🍓 It envisions an extended period of support for both IPv4 and IPv6 protocols in the operator network. User Equipment (UE) uses the Packet Data Protocol (PDP) context to set up tunnels through the operator network to a Gateway General Packet Radio Service (GPRS) Support Node (GGSN) 💅 RANGER could be used in 3GPP transition. When the UE uses IPv6 and the PDP context is set up across an IPv4 provider network, the UE can configure itself as an EBR and contact the GGSN (as a RANGER EBG) through VET tunneling 🦋
Other [RFC4215] scenarios look at IPv4-only UEs, IPv6-only UEs, and different combos of IPv4 and IPv6 inside the operator network 🫶 Also worth considering are scenarios where the UE is configured as a router or bridge that connects an end system, like a laptop computer. In that case, the UE could be the first-hop router/bridge into the cellular provider network, and the laptop could be configured as an EBR in the RANGER model 🌈 Again, the GGSN or a device reachable through the GGSN could serve as a RANGER EBG 💖
4.6.3. Aeronautical Telecommunications Network (ATN) ✈️
okay so the Aeronautical Telecommunications Network (ATN) is currently based on the OSI and IPv4 protocols and is only deployed in limited areas 🛫. The future ATN that the civil aviation industry is considering will be IPv6-based 💖. The IP version of ATN is expected to be a worldwide enterprise network. Inside, it's basically an aeronautical-only Internet with extra external interfaces to the global Internet 🌍. Within the ATN there may be lots of Air Communications Service Provider (ACSP) and Air Navigation Service Provider (ANSP) networks, and they might be organized either as autonomous systems or as internets within the ATN, like in Figure 5 ✨. Each of these can also be split up into lower-tier enterprise networks organized as regional, organizational, or functional compartments 🧚. Here's the important part: even though ACSPs and ANSPs share the same goal of safety-of-flight for civil aviation services, enterprise networks can have competing business, social, or political interests that mean the components need to be distinct ASs 👑.
The RANGER principles are what make this work. They support collaborative objectives while still allowing very diverse local policy distinctions 🫶. That's how entities that don't trust each other can build collaborative infrastructures to reach common goals. it's giving teamwork with boundaries 💅
Operational associations like this will show up in lots of future deployments, including the US Department of Defense's Global Information Grid (GIG) 🌸. Even though the routing and addressing arrangements of all enterprise networks need a mutual level of cooperative active management at a certain level, scaling issues, security policy differences, free market forces, organizational differences, political distinctions, or other factors can create internal competition among entities that otherwise share common goals 😭. So different enterprise networks inside that association will need to be separated into distinct ASs that are linked within their own functional Internet relationship 🦋.
The ATN shows the transition from OSI protocols to IPv6 🌈. It must support mobility (see Section 4.5.1), and it serves a bunch of government and private entities that cooperate to provide safe and efficient air travel while often competing with each other 🙈. One possible way to meet these needs with RANGER is to make an overlay using IP-in-IP tunneling across the Internet, as shown in Figure 14. The aero overlay forms an enterprise network, so inner packets from ACSP and ANSP edge networks that travel between VET interfaces on EBRs see their trip across the Internet as only one hop 🍓.
_...--------------------------------------..._
/ \
( IPv4 Internet )
-...________________________________________...-
| / | \ |
| / | \ |
_...--------------------------------------..._
/ \
( Aero Overlay )
-...________________________________________...-
. . . . . .
. . . . . .
_...-------.._ _...-------.._ _...-------.._
/ \ / \ / \
( ACSP1 ) ( ANSP ) ( ACSP2 )
-...________...- -...________...- -...________...-
Figure 14. Aeronautical OverlayEach Aeronautical Communications Service Provider (ACSP) and Aeronautical Navigation Service Provider (ANSP) is an enterprise network that's recursively nested below the aero overlay 💜. The relationships between the different enterprise networks can range from slight to tight integration 🎀. In this example, the ACSP and ANSP might decide to exchange full routing information for their edge networks, using a coordinated global-scope RLOC address space. They can route traffic across it without further mapping lookups or re-encapsulation at intermediate EBRs ⭐. Other enterprise networks that have the aero network as a common parent might not know anything about each other's interior routing. They'll just forward packets on a default route up to the aero overlay 🫠.
The ATN is an OSI network right now, but it's projected to transition to IPv6 over time 🔥. RANGER can bridge OSI networks together across the IPv4 (or IPv6) Internet, or bridge IPv4 or IPv6 networks across an OSI network 🧁. A pair of EBRs that have IP interfaces on a common enterprise network (whether that's the Internet, the aero network, or another parent or child enterprise network) can support communications between their attached OSI edge networks. They do this by looking up ISO network service access point (NSAP) addresses [IS8348] instead of IP addresses for RLOC mappings 🪄. That means OSI ConnectionLess Network Protocol (CLNP) [IS8473] packets can be encapsulated within IPv4 (or IPv6) headers for transmission across an Internet Protocol enterprise network 💫. Some OSI networks may transition to IPv6 addressing [RFC4548], while applications are adapted by using RFC 2126 [RFC2126] to carry OSI upper layers over TCP/IP. The resulting IP packets then get carried across and between RANGER enterprises in the normal way 🌷. Another approach is to use subnetwork convergence to tunnel OSI network protocol data units over Internet Protocol networks [RFC1070] 🐣.
Figure 15 shows an ACSP and ANSP connected via an IPv4 aero overlay 🫧. Host H stands for a system onboard an aircraft that has a wireless link to the ACSP. It connects through an enterprise-edge network interface on EBR F, inside the ACSP enterprise network 🛩️. H lives on an IPv6 edge network, and its EID comes from the ACSP IPv6 prefix. H needs to send a query to server S in the ANSP enterprise network 💌. So H starts by sending a DNS query to the server at G, and in return it gets the EID of server S 🔍. Then H creates an IPv6 packet with source EID(H) and destination EID(S) and forwards it to its default router, F 📦. F consults G for a mapping from EID(S) to the appropriate RLOC. In this case, EBR F encapsulates the IPv6 packet in an IPv6 outer packet and forwards it to its default EBG, A 🎁. A decapsulates the packet and looks up the destination EID(S) by querying the DNS server at EBR B. B returns a mapping with the RLOC of EBR E 🗺️. A then encapsulates the IPv6 inner packet in an IPv4 outer packet with source RLOC(A) and destination RLOC(E) 🌀. The packet gets forwarded via EBRs C and D in the aero overlay until it reaches E, where it's decapsulated 🛰️. E consults its cache of EID/RLOC mappings and finds that the EBR for S is N. So E encapsulates the packet in an IPv6 packet with source RLOC(E) and destination RLOC(N) 🧃. When the packet reaches N, it's decapsulated, and the inner IPv6 packet is forwarded on the edge network to the server, S 🏁.
_...--------------------------------------..._
/ (B) (D) \
( Aero Overlay (IPv4) )
-...________________________________________...-
. . .
(A) (C) .
. . .
_...------------------------.._ (E)
/ \ .
/ (F) \ .
( [H] ACSP (IPv6) ) .
\ (G) / .
\...__________________________... .
.
_...------------------------.._
/ \
/ (M) (N) \
( ANSP (IPv6) )
\ [S] /
\...__________________________...
Figure 15. Packet Forwarding for Aeronautical Networks4.6.4. Unmanaged Networks 🏠
"Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks" [RFC3904] looks at four cases for supporting IPv6-enabled routers and end systems that connect to an ISP network through a gateway 🧩:
- a. a gateway that does not provide IPv6 at all;
- b. a dual-stack gateway connected to a dual-stack ISP;
- c. a dual-stack gateway connected to an IPv4-only ISP; and
- d. a gateway connected to an IPv6-only ISP.
Case a is basically the super common setup where customer networks use IPv4-only NAT boxes to connect to their service providers 🙃. RANGER doesn't address this scenario directly, but the Teredo mechanism [RFC4380] can be a sufficient solution in many cases 🦄.
Case d hasn't seen widespread adoption yet 🌙. In this scenario, the customer network could be configured as IPv6 only, and the deployment could count as an IPv6-only extension to a RANGER enterprise-edge network. End systems here would still need support for legacy IPv4-only applications. And if the customer network has IPv4-only routers and end systems, the RANGER encapsulation mechanisms would still apply 🫣.
Cases b and c are when the customer gateway to the ISP becomes an IPv6 router 🥹. Then the gateway could become a RANGER EBR, and the situation is the same as the SOHO network use cases in Section 4.3. Specifically, when traditional home network IPv4 NAT boxes get updated to also support IPv6 routing, the NAT box becomes a RANGER EBR 🎉.
5. Mapping and Encapsulation Concerns 💌
Mapping and encapsulation concerns related to RANGER have been discussed in Section 3.7 of [RFC5720] 📚. These include the effects of mapping systems on application traffic, the need to secure the mapping system, MTU effects, and the ability of legacy Internet networks to connect to the ones using RANGER 🔐. bestie, that's a lot of stuff to keep track of, but we got this 🫶✨
6. Problem Statement and Call for Solutions ✨
okay so bestie, the scenarios in this doc haven't really looked at how big the native IPv6 and IPv4 Internets get on their own, separate from how much RANGER overlay networking grows 👀. Think about it: the huge services that serve millions of people at once (Google, Yahoo, eBay, Amazon, etc.) are most likely going to keep running best on native Internet routing and addressing 🌐, not on overlay setups that need dynamic mapping state coordination. BUT 😭 more and more small end user networks are going to want provider-independent addressing so they can multihome across several ISPs, and they'll want traffic engineering and mobility management too 🦋.
So what do we actually need? An overlay solution that plays nicely with BOTH RANGER and the IPv6 and IPv4 native Internet routing system, without wrecking Internet routing scaling 💅. It has to dodge the mapping and encapsulation drama from Section 3.7 of [RFC5720]. That means it must give generally shortest path routing and NOT add unacceptable delays for the initial packets ⚡. It must also give mobile end user networks mobility management that can use route optimization, and it must need NO changes to end systems 🙈. And last but not least, the business model has to let end user networks get Internet access from multiple ISPs at the same time, with support for traffic engineering and fault tolerance 👑.
7. Summary 🌸
okay so the Internet today is basically a giant enterprise network 🏢, with nodes addressed from the public IPv4 address space as RLOCs. But IPv4 only has 32-bit addresses, so the Internet kept growing by deploying a ton of IPv4 Network Address Translators (NATs) 🧱, while IPv6 still hasn't gotten super widespread adoption 😬.
ngl, this is kind of a messy version of the network-of-networks model that was originally pictured, like in the Catenet model 🧩. Those NATed domains look like a single simple host sitting in the global Internet RLOC space 🎭, even when they're secretly proxying for huge networks of end systems. The result? Transparency in the end-to-end model is gone 💔. It's no longer true that any node on the Internet can directly address any other node.
RANGER makes a true network-within-network (or enterprise-within-enterprise) framework possible 🪆. This works across a wide range of deployment scenarios, as documented here, and even for networks-within-networks nested to an arbitrary depth 🌈. So RANGER brings one unifying architecture that's applied consistently at every layer of recursion ✨, instead of a mixed bag of point solutions that may or may not play well together 🙃. Pair it with an overlay network solution that coexists with the IPv6 and IPv4 native Internet routing systems, and a unified future Internet architecture becomes possible 🚀👑.
8. Security Considerations 🔐
okay this part is SERIOUS bestie 😤, so read it carefully. Security considerations are covered in [RFC5720], [RFC5558], and [RFC5320] 📖. The RANGER architecture doesn't handle security by itself, BUT it proposes an architectural framework for functional specifications that DO address it 🛡️. Security concerns with tunneling, plus recommendations that work with the RANGER architecture, are in [TUNNEL-SEC] 🕵️♀️. Security considerations for specific use cases are discussed there too.
⚠️ Reminder: the security stuff lives in those documents, so don't skip them. Tunneling and overlays are exactly where things get sketchy, so go read [TUNNEL-SEC] before you build anything 😭💀.
9. Acknowledgements 🫶
this work came from the original architectural principles of the Internet, plus "lessons learned" from tons of peers who've done real Internet deployments and built encapsulation protocols 🧡. The editors are really clear that they're just carrying forward work that a whole lot of people started 🌷, so big love to everyone who came before 💜.
10. References 📚
10.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.
[RFC5720] Templin, F., "Routing and Addressing in Networks with
Global Enterprise Recursion (RANGER)", RFC 5720, February
2010.10.2. Informative References 📚✨
Okay bestie, these are the informative references, meaning the stuff the doc points to for extra context. Here they are, copied exactly as written 🫶
[APT] Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and
L. Zhang, "APT: A Practical Transit Mapping Service",
Work in Progress, November 2007.
[BEHAVE-v6v4]
Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
IPv4/IPv6 Translation", Work in Progress, August 2010.
[BELL-LaPADULA]
Bell, D. and L. LaPadula, "Secure Computer Systems:
Mathematical Foundations and Model", October 1974.
[CATENET] Pouzin, L., "A Proposal for Interconnecting Packet
Switching Networks", May 1974.
[CPE-RTRS] Singh, H., Beebee, W., Donley, C., Stark, B., and O.
Troan, Ed., "Basic Requirements for IPv6 Customer Edge
Routers", Work in Progress, December 2010.
[GROW-VA] Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R.,
and L. Zhang, "FIB Suppression with Virtual Aggregation",
Work in Progress, August 2010.
[HUSTON-END]
Huston, G., "The End of the (IPv4) World is Nigher!",
July 2007.
[IEN48] Cerf, V., "The Catenet Model for Internetworking", July
1978.
[INCR-CGN] Jiang, S., Guo, D., and B. Carpenter, "An Incremental
Carrier-Grade NAT (CGN) for IPv6 Transition", Work in
Progress, March 2009.
[IPv4POOL] Hain, T., "The IPv4 Address Pool Projection", April 2009.
[IS8348] International Organization for Standardization,
International Electrotechnical Commission, "Open Systems
Interconnection -- Network service definition", 2002.
[IS8473] International Organization for Standardization,
International Electrotechnical Commission, "Protocol for
providing the connectionless-mode network service:
Protocol specification", 1998.
[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol (LISP)", Work in
Progress, March 2009.
[RADIR-PROB-STATE]
Narten, T., "On the Scalability of Internet Routing",
Work in Progress, February 2010.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1070] Hagens, R., Hall, N., and M. Rose, "Use of the Internet
as a subnetwork for experimentation with the OSI network
layer", RFC 1070, February 1989.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[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.
[RFC2126] Pouffary, Y. and A. Young, "ISO Transport Service on top
of TCP (ITOT)", RFC 2126, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over
IPv4 Domains without Explicit Tunnels", RFC 2529, March
1999.
[RFC2767] Tsuchiya, K., Higuchi, H., and Y. Atarashi, "Dual Stack
Hosts using the "Bump-In-the-Stack" Technique (BIS)",
RFC 2767, February 2000.
[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775,
February 2000.
[RFC3194] Durand, A. and C. Huitema, "The H-Density Ratio for
Address Assignment Efficiency An Update on the H ratio",
RFC 3194, November 2001.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC3904] Huitema, C., Austein, R., Satapati, S., and R. van der
Pol, "Evaluation of IPv6 Transition Mechanisms for
Unmanaged Networks", RFC 3904, September 2004.
[RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P.
Savola, "Scenarios and Analysis for Introducing IPv6 into
ISP Networks", RFC 4029, March 2005.
[RFC4038] Shin, M-K., Ed., Hong, Y-G., Hagino, J., Savola, P., and
E. Castro, "Application Aspects of IPv6 Transition",
RFC 4038, March 2005.
[RFC4057] Bound, J., Ed., "IPv6 Enterprise Network Scenarios",
RFC 4057, June 2005.
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day",
RFC 4192, September 2005.
[RFC4215] Wiljakka, J., Ed., "Analysis on IPv6 Transition in Third
Generation Partnership Project (3GPP) Networks",
RFC 4215, October 2005.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, January
2006.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380, February
2006.
[RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational
Considerations and Issues with IPv6 DNS", RFC 4472, April
2006.
[RFC4548] Gray, E., Rutemiller, J., and G. Swallow, "Internet Code
Point (ICP) Assignments for NSAP Addresses", RFC 4548,
May 2006.
[RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local
Multicast Name Resolution (LLMNR)", RFC 4795, January
2007.
[RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D.
Green, "IPv6 Enterprise Network Analysis - IP Layer 3
Focus", RFC 4852, April 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
March 2008.
[RFC5320] Templin, F., Ed., "The Subnetwork Encapsulation and
Adaptation Layer (SEAL)", RFC 5320, February 2010.
[RFC5558] Templin, F., Ed., "Virtual Enterprise Traversal (VET)",
RFC 5558, February 2010.
[RFC5572] Blanchet, M. and F. Parent, "IPv6 Tunnel Broker with the
Tunnel Setup Protocol (TSP)", RFC 5572, February 2010.
[RFC5579] Templin, F., Ed., "Transmission of IPv4 Packets over
Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
Interfaces", RFC 5579, February 2010.
[RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering
Still Needs Work", RFC 5887, May 2010.
[RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4,
Revised", RFC 5944, November 2010.
[RFC6115] Li, T., Ed., "Recommendation for a Routing Architecture",
RFC 6115, February 2011.
[STEP] Savola, P., "Simple IPv6-in-IPv4 Tunnel Establishment
Procedure (STEP)", Work in Progress, January 2004.
[TUNNEL-SEC]
Krishnan, S., Thaler, D., and J. Hoagland, "Security
Concerns With IP Tunneling", Work in Progress, October
2010.Authors' Addresses 🎀
And finally, who to thank for all of this brilliance! 💖 Here are the editors, with their addresses copied exactly:
Steven W. Russert (editor)
1078 Ridge Crest Dr.
Wenatchee, WA 98801
USA
EMail: russerts@hotmail.com
Eric W. Fleischman (editor)
Boeing Research & Technology
P.O. Box 3707 MC 7L-49
Seattle, WA 98124
USA
EMail: eric.fleischman@boeing.com
Fred L. Templin (editor)
Boeing Research & Technology
P.O. Box 3707 MC 7L-49
Seattle, WA 98124
USA
EMail: fltemplin@acm.orgThat's the whole doc, besties! 🌈🦋👑
📦 where this page comes from
- ietf: rfc6139 2011-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms