RFC 6306
Hierarchical IPv4 Framework
Hierarchical IPv4 Framework ✨
okay bestie, let's start with the receipts 🧾 This is RFC 6306, called Hierarchical IPv4 Framework, written by P. Frejborg and dated July 2011. It's an Experimental doc from the Internet Research Task Force (IRTF) stream, with ISSN 2070-1721. Its header doesn't list anything it obsoletes or updates, so no drama there 💅
Abstract 🌸
okay so this doc is about taking the IPv4 address space we already have and splitting it into two new categories 🎀 The first is a core space of Area Locators (ALOCs) that's globally unique. The second is an edge space of Endpoint Locators (ELOCs) that's only regionally unique. Later on, the ELOC space will only matter inside a private network or a service provider domain 🫶 That's how you get a 32x32 bit addressing scheme and a hierarchical routing architecture, and it's giving clean structure ✨ It's also backwards compatible with today's IPv4 Internet, which is so important to me 🥹
The doc also talks about separating the location and identifier jobs, which is lowkey the big idea 🧚 Future apps can take advantage of that split 🦋 The framework needs extensions to the existing Domain Name System (DNS), the IPv4 stack on endpoints, middleboxes, and routers across the Internet. The good news is it can roll out incrementally across endpoints, DNS, middleboxes, and routers, so nobody has to do it all at once 💖
Status of This Memo 📜
okay the vibe here is "experimental, not final" 🧪 This is not an Internet Standards Track spec. It's published so people can look at it, try it out in experimental implementations, and evaluate it 🔬
It does define an Experimental Protocol for the Internet community. It comes from the Internet Research Task Force (IRTF), which shares research and development results about the Internet. Those results might not be ready to deploy, btw 💀 This RFC is one or more members of the Routing Research Group of the IRTF sharing their own opinions, not an official consensus 🎀 Documents approved by the IRSG are not a candidate for any level of Internet Standard. If you want the details, check Section 2 of RFC 5741 📖
For the current status, errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6306 🔗
Copyright Notice ©️
Copyright (c) 2011 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, which you can find at http://trustee.ietf.org/license-info, as they were in effect on the date of publication. Please read those carefully, bestie, because they explain your rights and restrictions for this document 🙈
Table of Contents 🗺️
1. Introduction ....................................................4
2. Requirements Notation ...........................................7
3. Definitions of Terms ............................................7
4. Hierarchical Addressing .........................................9
5. Intermediate Routing Architecture ..............................11
5.1. Overview ..................................................11
5.2. Life of a hIPv4 Session ...................................15
6. Long-Term Routing Architecture .................................18
6.1. Overview ..................................................19
6.2. Exit, DFZ, and Approach Routing ...........................21
7. Decoupling Location and Identification .........................23
8. ALOC Use Cases .................................................24
9. Mandatory Extensions ...........................................28
9.1. Overview ..................................................28
9.2. DNS Extensions ............................................29
9.3. Extensions to the IPv4 Header .............................30
10. Consequences ..................................................34
10.1. Overlapping Local and Remote ELOC Prefixes/Ports .........34
10.2. Large Encapsulated Packets ...............................35
10.3. Affected Applications ....................................35
10.4. ICMP .....................................................37
10.5. Multicast ................................................37
11. Traffic Engineering Considerations ............................38
11.1. Valiant Load-Balancing ...................................39
12. Mobility Considerations .......................................40
13. Transition Considerations .....................................42
14. Security Considerations .......................................43
15. Conclusions ...................................................45
16. References ....................................................47
16.1. Normative References .....................................47
16.2. Informative References ...................................47
17. Acknowlegments ................................................50
Appendix A. Short Term and Future IPv4 Address Allocation Policy ..51
Appendix B. Multi-Homing becomes Multi-Pathing ....................53
Appendix C. Incentives and Transition Arguments ...................57
Appendix D. Integration with CES Architectures ....................58the front matter is all served, let's gooo 🌈✨
1. Introduction ✨
okay so a Locator/Identifier Separation Protocol [LISP] presentation at a breakout session at an expo in January, 2008 sparked a whole research study 🔍, and this document is where those findings live 📝. Then it turned out the routing community at IETF was lowkey worried about the scalability of the routing and addressing system of the future Internet 😬. The Internet Architecture Board (IAB) ran a Routing and Addressing workshop on October 18-19, 2006, in Amsterdam, and the outcome is documented in [RFC4984]. The IRTF also set up a Routing Research Group [RRG] in 2007 and came up with some design guidelines; see [RFC6227] 🗺️.
The author found the LISP approach super interesting 🤩 because the IP address space is proposed to be split into two groups: Routing Locators (RLOCs), which live in the global routing table of the Internet called the Default-Free Zone (DFZ), and Endpoint Identifiers (EIDs), which only show up in edge networks attached to the Internet 🌐.
The proposed LISP architecture cuts the routing info in the DFZ, but it also adds a new mapping system that would need a caching solution at the border routers sitting between the edge networks and the DFZ 🧠. EID prefixes aren't needed in the DFZ because a tunneling (overlay) scheme is applied between the border routers 🚇. To the author this seems like a complex setup 🙃, and it could be improved by applying lessons learned from similar past architectures. In the '90s, overlay architectures were everywhere, deployed on top of Frame Relay and ATM technologies 📼. Cache-based routing architectures were tried too, like Ipsilon's IP Switching ⚡. These got largely replaced by MPLS [RFC3031] for several reasons, one being that overlay and caching solutions had historically suffered from scalability issues 💀. Tech has definitely evolved since the '90s, though 📈. The scalability issues of overlay and caching solutions may prove to be less relevant for modern hardware and new methods; see [Revisiting_Route_Caching] 🔥.
Still, the author has some doubt about whether overlay and caching will scale well, based on lessons from past overlay and caching architectures 🤔. The hierarchical IPv4 framework proposal came from asking whether the edge and core addressing groupings from LISP could be used without creating an overlay solution, by borrowing ideas from MPLS to build a peer-to-peer architecture 🦋. Like, instead of tunneling, why not swap IP addresses (hereafter called locators) on a node in the DFZ? 💡 By introducing a shim header to the IPv4 header, plus Realm Border Router (RBR) functionality on the network, the edge locators are no longer needed in the routing table of the DFZ 🎀.
There were two architectural options for how to assemble the packet so RBR functionality could be applied in the DFZ: the packet could be assembled either by an ingress network node (similar to LISP or MPLS) or at the endpoint itself 🧩. The major drawback of assembling the packet with a shim header at the endpoint is that the endpoint's stack must be upgraded 😩. The big win, though, is that the Path MTU Discovery issue, as discussed in, e.g., LISP, would not exist ✨. On top of that, the caching scalability issue is mitigated to the greatest extent possible by pushing caching to the endpoint 💅.
This approach also opened up the possibility of extending the current IP address scheme with a whole new dimension 🌈. In an MPLS network, overlapping IP addresses are allowed because the forwarding plane leverages label information from the MPLS shim header 🏷️. By applying RBR functionality, extending the current IPv4 header with a shim header, and assembling the new header at endpoints, an IP network can also carry packets with overlapping edge locators 👯. The core locators, though, must still be globally unique 🌍. The location of an endpoint is also no longer described by a single address space. It's described by a combination of an edge locator and a core locator, or a set of core locators 📍.
Later on, it was determined that the current 32-bit address scheme can be extended to 64 bits 🎉: 32 bits reserved for globally unique core locators, and 32 bits reserved for locally unique edge locators 🔢.
The new 64-bit addressing scheme is backwards compatible with the currently deployed Internet addressing scheme 🫶.
By making the architectural decisions described above, the foundation for the hierarchical IPv4 framework was laid out 🏗️.
Note that the hierarchical IPv4 framework is abbreviated as hIPv4, which is super close to the abbreviation of Host Identity Protocol (HIP) [RFC4423] 😭. So the reader needs to pay attention to the two abbreviations, hIPv4 and HIP, because they represent two different architectures ⚠️.
Use of the hIPv4 abbreviation has caused a lot of confusion 🙈, but it was chosen for two reasons:
- Hierarchical 👑: to emphasize that a hierarchical addressing scheme is developed. A formalized hierarchy is achieved in the routing architecture. Some literature describes today's Internet as already using hierarchical addressing, but the author believes that claim is not valid, since today's Internet uses one flat address space 🙅.
It is true that we have hierarchical routing in place. A routing architecture can consist of at least three types of areas: stub area, backbone area, and autonomous system (AS) 🏘️. The current flat address space is summarized or aggregated at border routers between the areas to suppress the size of a routing table 📉. In order to carry out summaries or aggregates of prefixes, the address space must be continuous over the areas 🧵.
So the author concludes that the current method is best described as an aggregating addressing scheme, since there are address block dependencies between the areas 🔗. Dividing addresses into edge and core locator spaces (a formalized hierarchy) opens up a new dimension 🌸: the edge locator space can still be deployed as an aggregating address scheme on the three types of areas mentioned earlier. In hIPv4, the core locators are combined with edge locators independently of each other. The two locator space allocation policies are separated, and no dependencies exist between the two addressing schemes in the long-term architecture 🫧.
A new hierarchical addressing scheme is achieved: a two-level addressing scheme that describes how the endpoint is attached to the local network and also how the endpoint is attached to the Internet 🪄. This change in the addressing scheme will enable a fourth level, called the Area Locator (ALOC) realm, at the routing architecture 🚀.
- IPv4 🧡: to emphasize that the framework is still based on the IPv4 addressing scheme, and is only an evolution from the currently deployed addressing scheme of the Internet 🌱.
While doing this research study, the author reviewed a previous hierarchical addressing and routing architecture that had been proposed in the past, the Extended Internet Protocol (EIP) [RFC1385] 📚. Should the hIPv4 framework ever be developed from a research study into a standard RFC, it is recommended that the hierarchical IPv4 framework name be replaced with Extended Internet Protocol, EIP 🎀. Both architectures share similarities, e.g., backwards compatibility with the existing deployed architecture, hierarchical addressing, etc., and the hIPv4 abbreviation can get mixed up with HIP 🙃.
This document is an individual contribution to the IRTF Routing Research Group (RRG), and discussions between people on the group's mailing list have influenced the framework 💬. The views in this document are considered controversial by the IRTF Routing Research Group (RRG), but the group reached a consensus that the document should still be published 🤝. Consensus was not achieved at RGG regarding which proposal should be preferred. As stated in [RFC6115]: "The group explored a number of proposed solutions but did not reach consensus on a single best approach" 📜. So all proposals produced within RRG can be considered controversial 🌪️.
2. Requirements Notation 💅
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in [RFC2119] 🫶.
3. Definitions of Terms ✨
okay so before we get into the good stuff, we need to be on the same page with the vocab 💅 this doc makes use of the following terms:
Regional Internet Registry (RIR): this is an organization overseeing the allocation and registration of Internet number resources within a particular region of the world. Resources include IP addresses (both IPv4 and IPv6) and autonomous system numbers. 🌍
Locator: a name for a point of attachment within the topology at a given layer. Objects that change their point(s) of attachment will need to change their associated locator(s). 📍
Global Locator Block (GLB): an IPv4 address block that is globally unique. 🌐
Area Locator (ALOC): an IPv4 address (/32) assigned to locate an ALOC realm in the Internet. The ALOC is assigned by an RIR to a service provider. The ALOC is globally unique because it is allocated from the GLB. 🦋
Endpoint Locator (ELOC): an IPv4 address assigned to locate an endpoint in a local network. The ELOC block is assigned by an RIR to a service provider or to an enterprise. In the intermediate routing architecture, the ELOC block is only unique in a geographical region. The final policy of uniqueness shall be defined by the RIRs. In the long-term routing architecture, the ELOC block is no longer assigned by an RIR; it is only unique in the local ALOC realm. 🏠
ALOC realm: an area in the Internet with at least one attached Realm Border Router (RBR). Also, an ALOC must be assigned to the ALOC realm. The Routing Information Base (RIB) of an ALOC realm holds both local ELOC prefixes and global ALOC prefixes. An ALOC realm exchanges only ALOC prefixes with other ALOC realms. 👑
Realm Border Router (RBR): a router or node that is able to identify and process the hIPv4 header. In the intermediate routing architecture, the RBR shall be able to produce a service, that is, to swap the prefixes in the IP header and locator header, and then forward the packet according to the value in the destination address field of the IP header. In the long-term routing architecture, the RBR is not required to produce the swap service. Instead, the RBR can make use of the Forwarding Indicator field in the locator header. Once the FI-bits are processed, the RBR forwards the packet according to the value in the destination address of the IP header or according to the value in the ELOC field of the locator header. The RBR must have the ALOC assigned as its locator. 🚦
Locator Header: a 4-byte or 12-byte field, inserted between the IP header and transport protocol header. If an identifier/locator split scheme is used, the size of the locator header is further expanded. 🧩
Identifier: the name of an object at a given layer. Identifiers have no topological sensitivity and do not have to change, even if the object changes its point(s) of attachment within the network topology. 🪪
Identifier/locator split scheme: separate identifiers used by applications from locators that are used for routing. The exchange of identifiers can occur discreetly between endpoints that have established a session, or the identifier/locator split can be mapped at a public database. 🤫
Session: an interactive information exchange between endpoints that is established at a certain time and torn down at a later time. 🤝
Provider Independent Address Space (PI addresses/prefixes): an IPv4 address block that is assigned by a Regional Internet Registry directly to a user organization. 🏢
Provider Aggregatable Address Space (PA addresses/prefixes): an IPv4 address block assigned by a Regional Internet Registry to an Internet Service Provider that can be aggregated into a single route advertisement. 📦
Site mobility: a site wishing to change its attachment point to the Internet without changing its IP address block. 🏡
Endpoint mobility: an endpoint moves relatively rapidly between different networks, changing its IP layer network attachment point. 🏃♀️
Subflow: a flow of packets operating over an individual path, the flow forming part of a larger transport protocol connection. 🌊
4. Hierarchical Addressing 🌸
The current IP addressing (IPv4) and the future addressing (IPv6) schemes of the Internet are unidimensional by their nature. This limitation -- the unidimensional addressing scheme -- has created some roadblocks, for example, breaking end-to-end connectivity due to NAT, limited deployment of Stream Control Transmission Protocol (SCTP) [RFC4960], etc., for further growth of the Internet. 😭
If we compare the Internet's current addressing schemes to other global addressing or location schemes, we notice that the other schemes use several levels in their structures. For example, the postal system uses street address, city, and country to locate a destination. To locate a geographical site, we use longitude and latitude in the cartography system. The other global network, the Public Switched Telephone Network (PSTN), has been built upon a three-level numbering scheme that has enabled a hierarchical signaling architecture. By expanding the current IPv4 addressing scheme from a single level to a two-level addressing structure, most of the issues discussed in [RFC4984] can be solved. Also, a hierarchical addressing scheme would better describe the Internet we have in place today. 🗺️
Looking back, it seems that the architecture of the Internet changed quite radically from the intended architecture with the introduction of [RFC1918], which divides the hosts into three categories and the address space into two categories: globally unique and private address spaces. This idea allowed for further growth of the Internet and extended the life of the IPv4 address space, and it ended up becoming much more successful than expected. RFC 1918 didn't solve the multi-homing requirements for endpoints providing services for Internet users, that is, multi-homed sites with globally unique IP addresses at endpoints to be accessed from the Internet. 🙈
Multi-homing has imposed some challenges for the routing architecture that [RRG] is addressing in [RFC6115]. Almost all proposals in the report suggest a core and edge locator separation or elimination to create a scalable routing architecture. The core locator space can be viewed to be similar to the globally unique address space, and the edge locator space similar to the private address space in RFC 1918. 🧠
RFC 1918 has already demonstrated that Internet scales better with the help of categorized address spaces, that is, globally unique and private address spaces. The RRG proposals suggest that the Internet will be able to scale even further by introducing core and edge locators. Why not then change the addressing scheme (both IPv4 and IPv6 addressing schemes, though this document is only focusing on IPv4) to better reflect the current and forthcoming Internet routing architecture? If we continue to use a flat addressing scheme, and combine it with core (global) and edge (private) locator (address) categories, the routing architecture will have to support additional mechanisms, such as NAT, tunneling, or locator rewriting with the help of an identifier to overcome the mismatch. The result will be that information is lost or hidden for the endpoints. With a two-level addressing scheme, these additional mechanisms can be removed and core/edge locators can be used to create new routing and forwarding directives. 💡
A convenient way to understand the two-level addressing scheme of the hIPv4 framework is to compare it to the PSTN numbering scheme (E.164), which uses country codes, national destination codes, and subscriber numbers. The Area Locator (ALOC) prefix in the hIPv4 addressing scheme can be considered similar to the country code in PSTN; i.e., the ALOC prefix locates an area in the Internet called an ALOC realm. The Endpoint Locator (ELOC) prefixes in hIPv4 can be compared to the subscriber numbers in PSTN -- the ELOC is regionally unique (in the future, locally unique) at the attached ALOC realm. The ELOC can also be attached simultaneously to several ALOC realms. 📞
By inserting the ALOC and ELOC elements as a shim header (similar to the MPLS and [RBridge] architectures) between the IPv4 header and the transport protocol header, a hIPv4 header is created. From the network point of view, the hIPv4 header "looks and feels like" an IPv4 header, thus fulfilling some of the goals as outlined in EIP and in the early definition of [Nimrod]. The outcome is that the current forwarding plane does not need to be upgraded, though some minor changes are needed in the control plane (e.g., ICMP extensions). this is the part where it all clicks 🫶
5. Intermediate Routing Architecture 🦋
The intermediate routing architecture is backwards compatible with the currently deployed Internet; that is, the forwarding plane remains intact except that the control plane needs to be upgraded to support ICMP extensions. The endpoint's stack needs to be upgraded, and middleboxes need to be upgraded or replaced. In order to speed up the transition phase, middleboxes might be installed in front of endpoints so that their stack upgrade can be postponed; for further details, see Appendix D. 🚀
5.1. Overview 🫶
okay so, like we've been saying, the Area Locator (ALOC) prefix is lowkey the PSTN country code of the Internet 🌍. It tells you where an area is, whether that's one area inside an autonomous system (AS) or a whole group of ASes working together 🌐. An area can have several ALOC prefixes assigned, e.g., for traffic engineering stuff like load balancing across several ingress/egress points at the area ⚖️. The ALOC prefix gets used for routing and forwarding on the Internet, so it must be globally unique 💅, and it's allocated from an IPv4 address block. That globally unique block is called the Global Locator Block (GLB) 🎀.
Once an area inside an AS (or a group of ASes) gets an ALOC prefix, it has the potential to become an ALOC realm ✨. But you need more than just the prefix to actually make it happen. One or multiple Realm Border Routers (RBRs) have to be attached to the ALOC realm 🚪. An RBR is a node that can swap the prefixes of the IP header and the new shim header, which is called the locator header 🔄. The swap service is explained in detail in Section 5.2, step 3, so go check it out 👀.
Real talk, today's routers don't support RBR functionality 😭. So the new stuff will most likely get built on an external device hooked up to a router in the ALOC realm. The external RBR might literally be a server with two interfaces attached to a router: one configured with the ALOC prefix and the other with any IPv4 prefix 🖥️. RBRs don't run dynamic routing protocols, so they don't need a Forwarding Information Base (FIB) or a cache either. The RBR just performs a service, which is swapping headers 🔁.
The swap service happens per packet, and all the info needed for the swap rides along in the locator header of the hIPv4 packet 📦. So a standalone device with enough computing and I/O resources to handle the incoming traffic can totally be an RBR 💪. Later on, the RBR functionality might get baked into a router's forwarding plane 🧚. It's expected that one RBR won't be able to handle all the incoming traffic for an ALOC realm, and a single RBR would also be a potential single point of failure 💀. So several RBRs might get installed in the ALOC realm. The RBRs shall use the ALOC prefix as their locator, and the routers announce the ALOC prefix as an anycast locator within the local ALOC realm 📡. The ALOC prefix is advertised throughout the DFZ by BGP mechanisms 🌏. Where you place the RBRs will influence the ingress traffic to the ALOC realm 🗺️.
Multicast is its own whole vibe 🌈, because forwarding multicast packets is super different from forwarding unicast packets. So multicast will have an impact on the RBR too. Multicast RBR (mRBR) functionality isn't on today's routers either, so an external device is needed again (and again, the functionality might get integrated into routers later) 🔮. The mRBR shall take the role of an anycast Rendezvous Point with the Multicast Source Discovery Protocol (MSDP) [RFC3618] and Protocol Independent Multicast (PIM) [RFC4601] capabilities. But to swap headers, it doesn't need a FIB or a cache. Just like the RBR, the multicast hIPv4 packets carry all the info they need in their headers to apply the swap service 🎁. For the details, see Section 10.5 🙈.
The ALOC realm isn't fully constructed yet 🚧. We can now locate the ALOC realm on the Internet, but to find the endpoints attached to it, we need a new element: the Endpoint Locator (ELOC) 📍. Like we said in the previous section, ELOC prefixes are kinda like subscriber numbers in the PSTN ☎️. The ELOC isn't a brand-new element, though. It's a redefinition of the current IPv4 address configured at an endpoint 🔖. We use the word redefinition because once the hIPv4 framework is fully implemented, global uniqueness of IPv4 addresses is no longer valid 🙅♀️. A more regional address allocation policy for IPv4 addresses can be deployed, as discussed in Appendix A 🗂️. The ELOC prefix is only used for routing and forwarding inside the local and remote ALOC realms. It's not used in the intermediate ALOC realms 🙌.
Now here's the plot twist 😤. When an initiator is setting up a session with a responder that lives outside the local ALOC realm, the destination address field of the IP header of an outgoing packet is no longer the remote destination address (ELOC prefix). Instead, the remote ALOC prefix goes in the destination address field of the IP header 🎯. Because that field is carrying an ALOC prefix, the intermediate ALOC realms don't need to install the ELOC prefixes of other ALOC realms in their routing tables. It's enough for them to carry only the ALOC prefixes 🧠.
The result is that the routing tables at each ALOC realm get smaller once the hIPv4 framework is fully implemented 📉. The ALOC prefixes are still globally unique and must be installed in the DFZ, so a service provider can't control how much the ALOC prefixes grow 😩. But they can control how many local ELOC prefixes exist in their own local ALOC realm 💜.
When an hIPv4 packet shows up at the remote ALOC realm, it gets forwarded to the nearest RBR, since the destination address field is the remote ALOC prefix 🚗. Once the RBR has swapped the hIPv4 header, the destination address field holds the remote ELOC, so the packet gets forwarded to its final destination inside the remote ALOC realm 🏁. An endpoint using an ELOC prefix can be attached to two different ALOC realms at the same time, without needing a classical multi-homing solution. For the details, see Section 12 and Appendix B 🦋.
Okay, so the addressing structure isn't unidimensional anymore, since a second level of hierarchy got added 📚. That means it's important to solve the problems of locating the remote ELOC (endpoint) and the remote ALOC realm on the Internet, and also figuring out where to assemble the header of the hIPv4 packet 🧩. The hierarchical IPv4 framework relies on the Domain Name System, which needs to support a new record type so the ALOC information can get distributed to the endpoints 📬. To construct the hIPv4 packet header, either the endpoint or an intermediate node (e.g., a proxy) should be used. A proxy solution is likely to be suboptimal because the proxy would need to listen to DNS messages, and a cache solution has scalability issues 🙃.
A better solution is to extend the current IPv4 stack at the endpoints, so the ALOC and ELOC elements are incorporated into the endpoint's stack. Backwards compatibility must be preserved though 🫶. Most applications won't even notice the extensions. But other IP-aware applications, like Mobile IP, SIP, IPsec AH and so on (see Section 10.3), will suffer and can't be used outside their ALOC realm once the hIPv4 framework is fully implemented, unless they get upgraded 😬. That's because IP-aware applications depend on the underlying network addressing structure, e.g., to identify an endpoint 🔍.
Note that applications used inside the local ALOC realm (like an enterprise's private network) don't need to be upgraded, not in the intermediate or the long-term routing architecture 🏢. The classical IPv4 framework is preserved, since only IP-aware applications used between ALOC realms need to be upgraded to support the hIPv4 header 🙌.
Figure 1 shows a conceptual overview of the intermediate routing architecture 🖼️. Once this architecture is in place, the ELOC space is no longer globally unique. Instead, a regional allocation policy can be implemented. For more details, see Appendix A. The transition from the current routing architecture to the intermediate routing architecture is discussed in Appendix D 🛣️.
Legend: *attachment point in the ALOC realm
UER=Unique ELOC region
EP=Endpoint
|-------------------------------------------------------------|
| UER1 | | UER2 |
|-------------------------------------------------------------|
| Enterprise1 | ISP1 | ISP | ISP2 | Enterprise2 |
| ALOC Realm | ALOC Realm | Tier1 | ALOC Realm | ALOC Realm |
| | | | | |
| *EP | *RBR | | *RBR | *EP |
| ELOC1 | ALOC1 | | ALOC2 | ELOC4 |
| | | | | |
| | *EP | | *EP | |
| | ELOC2 | | ELOC3 | |
| | | | | |
|-------------|xxxxxxxxxxxxxx DFZ xxxxxxxxxxxxxx| ------------|
| RIB | RIB | RIB | RIB | RIB |
| | | | | |
| ALOC1 | ALOC1 | ALOC1 | ALOC2 | ALOC2 |
| ELOC1 | ALOC2 | ALOC2 | ALOC1 | ELOC4 |
| | ELOC2 | | ELOC3 | |
| | ELOC1 | | ELOC4 | |
| | | | | |
|-------------------------------------------------------------|
Figure 1: Intermediate routing architecture of hIPv45.2. Life of a hIPv4 Session ✨
okay so this section walks through a whole hIPv4 session from start to finish 🦋 between two endpoints, an initiator and a responder, living in different ALOC realms. bestie, this is the main character arc 💅
When the hIPv4 stack is putting the packet together for transport, the hIPv4 stack shall decide whether a classical IPv4 header or a hIPv4 header gets used, based on the ALOC info it got from a DNS reply 🔍. If the initiator's local ALOC prefix equals the responder's ALOC prefix, there's no need for the hIPv4 header for routing purposes, because both of them are chilling in the same local ALOC realm 🏡. The packet gets routed by the prefixes in the IP header, since it's never leaving the local ALOC realm. When the local ALOC prefix and the remote ALOC prefix do not match, a hIPv4 header must be assembled, because the packet needs to get routed to a remote ALOC realm 🚀.
A session between two endpoints inside one ALOC realm might still use the locator header 🧚. Not for routing, though! It's to make use of Valiant Load-Balancing [VLB] for multipath-enabled transport protocols (see Section 11.1), or to make use of an identifier/locator split scheme (see Section 7). When going for VLB, the initiator adds the locator header and sets the VLB-bits to 01 or 11, which tells the responder and the intermediate routers that VLB is requested for the subflow. Since this is an intra-ALOC realm session, there's no need to add ALOC and ELOC fields to the locator header, so the locator header ends up being 4 bytes 🍓.
If an identifier/locator split scheme is applied for the session (intra-ALOC or inter-ALOC), the initiator must set the I-bit to 1 and make use of the Locator Header Length field. The identifier/locator split scheme info gets inserted into the locator header right after the Locator Header Length field 🌸.
Here's how a hIPv4 session gets set up:
- The initiator queries the DNS server. The hIPv4 stack notices that the local and remote ALOCs do not match, so it has to use the hIPv4 header for the session. The hIPv4 stack of the initiator must assemble the packet like this:
- a. Set the local IP address from the API in the source address field of the IP header.
- b. Set the remote IP address from the API in the ELOC field of the locator header.
- c. Set the local ALOC prefix in the ALOC field of the locator header.
- d. Set the remote ALOC prefix in the destination address field of the IP header.
- e. Set the transport protocol value in the protocol field of the locator header, and set the hIPv4 protocol value in the protocol field of the IP header.
- f. Set the desired parameters in the A-, I-, S-, VLB-, and L- fields of the locator header.
- g. Set the FI-bits of the locator header to 00.
- h. Calculate IP, locator, and transport protocol header checksums. The transport protocol header calculation does not include the locator header fields. Once that's done, the packet gets transmitted 💖.
- The hIPv4 packet gets routed throughout the Internet based on the value in the destination address field of the IP header 🌍.
- The hIPv4 packet reaches the closest RBR of the remote ALOC realm. When the RBR notices that the value in the destination address of the IP header matches the local ALOC prefix, the RBR must:
- a. Verify that the received packet uses the hIPv4 protocol value in the protocol field of the IP header.
- b. Verify IP, locator, and transport protocol header checksums. The transport protocol header verification does not include the locator header fields.
- c. Replace the source address in the IP header with the ALOC prefix of the locator header.
- d. Replace the destination address in the IP header with the ELOC prefix of the locator header.
- e. Replace the ALOC prefix in the locator header with the destination address of the IP header.
- f. Replace the ELOC prefix in the locator header with the source address of the IP header.
- g. Set the S-field to 1.
- h. Decrease the Time to Live (TTL) value by one.
- i. Calculate IP, locator, and transport protocol header checksums. The transport header calculation does not include the locator header fields.
- j. Forward the packet according to the value in the destination address field of the IP header 🔁.
- The swapped hIPv4 packet is now routed inside the remote ALOC realm, based on the new value in the destination address field of the IP header, until it reaches the final destination 🎯.
- The responder receives the hIPv4 packet.
- a. The hIPv4 stack must verify that the received packet uses the hIPv4 protocol value in the protocol field of the IP header.
- b. Verify IP, locator, and transport protocol header checksums. The transport protocol header verification does not include the locator header fields.
- The hIPv4 stack of the responder must present the following to the extended IPv4 socket API:
- a. The source address of the IP header as the remote ALOC prefix.
- b. The destination address of the IP header as the local IP address.
- c. Verify that the received ALOC prefix of the locator header equals the local ALOC prefix.
- d. The ELOC prefix of the locator header as the remote IP address 🥰.
The responder's application responds to the initiator, and the returning packet takes almost the same steps as when the initiator started the session, which are steps 1 to 6. In step 1, the responder doesn't need to do a DNS lookup, since all the information is already provided by the packet 🫶.
6. Long-Term Routing Architecture 🌈
The long-term routing architecture gets established once the forwarding planes of private ALOC realms or service providers' ALOC realms containing subscribers are upgraded. The forwarding planes of transit DFZ routers do not need to be upgraded. So why would private network or service provider administrators upgrade their infrastructure? ngl, there are two incentives 👑:
- The overlay local ALOC exit routing topology (as discussed in Section 11) can be replaced by a peer-to-peer local ALOC exit routing topology, which is simpler to operate, thus decreasing operational expenditures 💰.
- Locator freedom: Once the local ALOC realm is upgraded, the enterprise or service provider can use the full 32-bit ELOC address space to remove address space constraints and to design a well-aggregated routing topology with an overdimensioned ELOC allocation policy 🌟.
When an enterprise or service provider upgrades the forwarding plane in their ALOC realm, the previous PI or PA address space allocation is released back to the RIR, to be used for ALOC allocations in the GLB 🦋.
6.1. Overview ✨
okay so the swap service at the RBR got added to the framework so the move from the current IPv4 framework to hIPv4 could be smooth 🦋 we avoid a major upgrade of the current forwarding plane by adding the swap service instead. in the future the swap service can just stay as it is in the ALOC realm 💅, or it can get pushed toward the edge of the ALOC realm whenever routers get upgraded in their natural lifecycle process 🌸
once a router needs an upgrade because of stuff like increased demand for bandwidth 📈, the modified forwarding plane might support IPv4 and hIPv4 forwarding at the same time. then the swap service can get pushed to the edge and eventually removed from the ALOC realm ✨ this happens by adding an extension to the current routing protocols, both IGP and BGP 🧚 now here's the main character moment: when an RBR gets an hIPv4 packet where the destination address field in the IP header matches the local ALOC prefix, the RBR will -- contrary to the tasks defined in Section 5.2, step 3 -- look up the ELOC field in the locator header and compare that prefix against the FIB 👀 if the next-hop entry is RBR-capable, the packet gets forwarded according to the ELOC prefix 💖 but if the next-hop is a classical IPv4 router, the RBR must apply the tasks defined in Section 5.2, step 3 and, once that's completed, forward the packet according to the new value in the destination address field of the IP header 🎀
when all the endpoints (the ones that need to establish sessions outside the local ALOC realm) and the infrastructure nodes in an ALOC realm are hIPv4-capable, there's no need to apply the swap service for unicast sessions 🙌 forwarding decisions can be based on information in the IP and locator headers. in the local ALOC realm, packets get routed to their upstream anycast or unicast ALOC RBR according to the ALOC prefix in the locator header, and local ALOC exit routing gets applied against the local ALOC FIB 🌈 remote ELOC approach routing is applied against the ELOC FIB in the remote ALOC realm 🛸
ngl this next bit is so important 😭 the IP and transport protocol headers stay intact (except for TTL values, since the RBR is a router) 💜 only the FI and LH checksum values in the locator header change when you're in local ALOC exit routing mode and remote ELOC approach routing mode 🍓
here's a conceptual overview of the long-term hIPv4 routing architecture 👑
|-------------------------------------------------------------|
| UER1 | UER2 | | UER3 | UER4 |
|-------------------------------------------------------------|
| Enterprise1 | ISP1 | ISP | ISP2 | Enterprise2 |
| ALOC Realm | ALOC Realm | Tier1 | ALOC Realm | ALOC Realm |
| | | | | |
| *EP | *aRBR | | *aRBR | *EP |
| ELOC1 | ALOC1.1 | | ALOC2.1 | ELOC4 |
| | | | | |
| *uRBR | | uRBR* |
| |ALOC1.2 | | ALOC2.2| |
| | | | | |
| | *EP | | *EP | |
| | ELOC2 | | ELOC3 | |
| | | | | |
|-------------|xxxxxxxxxxxxxx DFZ xxxxxxxxxxxxxx|-------------|
| RIB | RIB | RIB | RIB | RIB |
| | | | | |
| ALOC1.2 | ALOC1.1 | ALOC1 | ALOC2.1 | ALOC2.2 |
| ELOC1 | ALOC1.2 | ALOC2 | ALOC2.2 | ELOC4 |
| | ALOC2 | | ALOC1 | |
| | ELOC2 | | ELOC3 | |
| | | | | |
|-------------------------------------------------------------|Figure 2: Long-term routing architecture of hIPv4 🖼️
Legend: *attachment point in the ALOC realm UER=Unique ELOC region EP=Endpoint aRBR=anycast RBR uRBR=unicast RBR
btw the swap service for multicast can be removed once the forwarding planes are upgraded in all the consequent ALOC realms 🔥 the source's ALOC RBR sets the FI-bits to 11, and then a Reverse Path Forwarding (RPF) check gets applied against the ALOC prefix in the locator header. and yes, IP and transport protocol headers won't alternate here either 🫶
a long-term evolution will give us a 32x32 bit locator space 🤩 the ALOC prefixes only get allocated to service providers, and ELOC prefixes only matter inside a local ALOC realm. an enterprise can use a 32-bit locator space for its private network (the ALOC prefix is rented from the attached ISP) 🏢 and an ISP can use a 32-bit ELOC space to provide Internet connectivity services for its directly attached customers, residential and enterprise 🏠✨
6.2. Exit, DFZ, and Approach Routing 🌊
this section gives an example of a hIPv4 session between two hIPv4 endpoints 💕 the initiator lives in an ALOC realm whose forwarding plane has been upgraded to support the hIPv4 framework, and the responder is in a remote ALOC realm running the classical IPv4 forwarding plane 🧚♀️
when the forwarding plane at the local ALOC realm has been upgraded, the endpoints have to be informed about it 📣 that means either extensions to DHCP are needed, or the endpoints get manually configured to be notified that the local ALOC realm is fully hIPv4 compliant.
okay so here's how a hIPV4 session gets established 🎀
- The initiator queries the DNS server. The hIPv4 stack notices that the local and remote ALOCs don't match, and therefore it must use the hIPv4 header for the session. The hIPv4 stack of the initiator must assemble the packet as described in Section 5.2, step 1, except for the following:
- g. Set the
FI-bitsof the locator header to01.
- g. Set the
- The hIPv4 packet gets routed throughout the local ALOC realm according to the ALOC prefix of the locator header 🗺️ local ALOC exit routing is applied.
- The hIPv4 packet will reach the closest RBR of the local ALOC realm. When the RBR notices that the packet's ALOC prefix of the locator header matches the local ALOC prefix and the
FI-bitsare set to01, the RBR must:- a. Verify that the received packet uses the hIPv4 protocol value in the protocol field of the IP header.
- b. Verify the IP and locator header checksums.
- c. Set the
FI-bitsof the locator header to00. - d. Decrease the TTL value by one.
- e. Calculate IP and locator header checksums.
- f. Forward the packet according to the value in the destination address field of the IP header.
- The hIPv4 packet gets routed to the responder as described in Section 5.2, steps 2 to 6. DFZ routing is applied. 🌐
- The responder's application responds to the initiator, and the returning packet takes almost the same steps as described in Section 5.2 except for:
- The hIPv4 packet will reach the closest RBR of the initiator's ALOC realm. When the RBR notices that the value in the destination address field of the IP header matches the local ALOC prefix and the
FI-bitsare set to00, the RBR must:- a. Verify that the received packet uses the hIPv4 protocol value in the protocol field of the IP header.
- b. Verify the IP and locator header checksums.
- c. Set the
FI-bitsof the locator header to10. - d. Decrease the TTL value by one.
- e. Calculate IP and locator header checksums.
- f. Forward the packet according to the ELOC prefix of the locator header.
- The hIPv4 packet gets routed throughout the initiator's ALOC realm according to the ELOC prefix of the locator header. Remote ELOC approach routing is applied. 🦋
- The hIPv4 stack of the responder must present the following to the extended IPv4 socket API:
- a. The source address of the IP header as the remote IP address.
- b. The destination address of the IP header as the local ALOC prefix.
- c. The ALOC prefix of the locator header as the remote ALOC prefix.
- d. The ELOC prefix of the locator header as the local IP address.
7. Decoupling Location and Identification ✨
okay so bestie, the design guidelines and the reasoning behind splitting location from identification live in [RFC6227] 🧠. Another big influence is the report and slides from the [Dagstuhl] workshop, which basically said that "a future Internet architecture must hence decouple the functions of IP addresses as names, locators, and forwarding directives in order to facilitate the growth and new network-topological dynamisms of the Internet" 💅🌸
So the hIPv4 framework needs identifier elements added to it 🦋. That gives future applications a way to stop depending on the underlying network layer addressing scheme (the local and remote IP address tuple). Iconic for future apps 👑
BUT, and this is a big but 🙈, there are lots of ways to do an identifier/locator split. The [ID/loc_Split] presentation from the MobiArch workshop at Sigcomm 2008 walks through several of them. So the hIPv4 framework is not going to propose or define one single split solution 🚫. A split could be done by a multipath transport protocol, or by an identifier/locator database scheme like HIP, for example. There's a placeholder in the locator header so split schemes can plug into hIPv4 later 🧚. Just know that identifier/locator split schemes may cause privacy inconveniences, as discussed in [Mobility_&_Privacy] 🙈🔒
Now the multipath transport protocols! 💜 SCTP and the still-in-progress Multipath TCP (MPTCP) [RFC6182] are the most interesting candidates for enabling an identifier/locator split in hIPv4. MPTCP is especially spicy from hIPv4's point of view, because one of its main goals is backwards compatibility with current implementations, and hIPv4 wants that too. Same goals, bestie, it's a match made in heaven 🫶
Here's the thing though: MPTCP does NOT come with an identifier/locator database scheme the way HIP does 😭. What it does instead is use a token (which only has local meaning) to manage and bundle subflows under one session between two endpoints. That token acts a lot like a session identifier. It's basically a generic cookie mechanism for the application layer, and it creates a session layer sitting between the application and transport layers ✨. So a session identifier can help improve mobility, in both site mobility and endpoint mobility scenarios. Main character energy 🌈
Okay, now the question everyone's asking: if the session identifier already improves site and endpoint mobility, and the hierarchical addressing scheme already makes routing more scalable, why bother adding an identifier/locator database scheme to hIPv4? 🤔 Good question! Schemes like HIP, the Identifier/Locator Network Protocol [ILNP], and Name-Based Sockets [NBS] could ease or even remove the locator renumbering dependencies at the firewalls that scope security zones. BUT this would fundamentally change the security architecture that's already deployed, which is a whole vibe shift 💀
Still, combining an identifier/locator database scheme with DNS Security (DNSSEC) [RFC4033] is lowkey very interesting 🍓. Right now, security zones are scoped using locator prefixes in the security rule sets. Instead, a Fully Qualified Domain Name (FQDN) could go in those rule sets, so renumbering locator prefixes would no longer depend on the firewall rule sets at all 🎀. Another cute detail: an FQDN is, and needs to be, globally unique. The ALOC prefix must be globally unique, but ELOC prefixes are only regionally unique and, in the long term, only locally unique 🌸. Combining identifier/locator database schemes with security architectures and DNSSEC still needs further study, so this is a work in progress, bestie 🧪
Another reason to want this: to give multi-homing and mobility capabilities to single path transport protocols like TCP and UDP, an identifier/locator database scheme is needed 🦋. This scheme can also build a bidirectional NAT traversal solution, using a locator translation map made of private locator prefixes and public identifiers at the border router 🔥
Last but not least, the hIPv4 routing architecture only provides location information for endpoints. The ELOC describes how the endpoint is attached to the local network, and the ALOC prefixes describe how the endpoint is attached to the Internet 🌍. Identifier/locator split schemes are decoupled from the routing architecture, which means the application layer may or may not use an identifier/locator split scheme. Totally up to the app, no pressure 💅✨
8. ALOC Use Cases 💖
okay so, let's look at some ALOC use cases 💅 Like Section 5.1 said, an ALOC can describe an area of the Internet that spans several autonomous systems (ASes). If that area is exactly one AS, then you can say the ALOC describes an AS. When an ALOC describes an area, we call it an anycast ALOC 🌸
An ALOC can also describe one specific node sitting between two ALOC realms. Think of a box installed between a private ALOC realm and an ISP ALOC realm, or between two private ALOC realms. In this case the ALOC marks an attachment point, like where a private network plugs into the Internet. We call this a unicast ALOC 🦋
The big difference between the two types is:
- In an anycast ALOC scenario, ELOC routing information is shared between the attached ALOC realms.
- In a unicast ALOC scenario, no ELOC routing information is shared between the attached ALOC realms.
Unicast ALOC functionality should not be deployed between private and ISP ALOC realms in the intermediate routing architecture 🙈 It would eat through way too many locators from the GLB space. Instead, unicast ALOC functionality is used to separate private ALOC realms 🧚
ALOC space comes in two flavours: a globally unique ALOC space (a.k.a. GLB) that lives in the DFZ, and a private ALOC space for use inside private networks ✨ Private ALOCs use the same locator space defined in [RFC1918]. A private ALOC must be unique inside its private network and must not overlap private ELOC prefixes. Only ISPs should be allowed to apply for global ALOC prefixes. For more on this, see Appendix A. The ISP should aggregate global ALOC prefixes as much as possible so the routing table in the DFZ stays small 🧠
When a user logs on to the enterprise network, the endpoint gets the following locator prefixes through provisioning (e.g., DHCP or manual configuration) 🎀
- One ELOC prefix for each network interface.
- One private ALOC prefix, because:
- The enterprise has recently merged with another enterprise and overlapping ELOC spaces exist.
- Several private ALOC prefixes, because:
- The enterprise network spans high-speed long-distance connections. It is well known that TCP cannot sustain high throughput for extended periods of time. Higher throughput might be achieved by using multiple paths concurrently.
- One or several global ALOC prefixes. These ALOCs describe how the enterprise network is attached to the Internet 🌈
When the user starts a session to a remote endpoint, DNS is usually used to resolve the remote locator prefixes. DNS returns the ELOC and ALOC prefixes of the remote endpoint. If no ALOC prefixes come back, a classical IPv4 session is started to the remote endpoint 😭 When ALOC prefixes do come back, the initiator compares them with its own local ALOC prefixes (which were provided via DHCP or manually configured).
- If the remote ALOC prefix is from the private ALOC space, the initiator will use the given private ALOC prefix for the session.
Two use cases exist for designing a network that uses private ALOC functionality 🚀 The first is when the remote endpoint is far away and reached over high-speed long-distance connections. To improve performance for the session, a multipath transport protocol should be used. The second is when the remote endpoint is in a network that was recently merged, and private ELOC [RFC1918] spaces overlap because no renumbering was applied. In that case, one or several unicast ALOC solutions are needed in the network between the initiator and responder. For long-distance sessions with no overlapping ELOC prefixes, anycast or unicast ALOC solutions can be deployed.
A third use case follows. Again, the initiator compares the ALOC prefixes returned from DNS with its own local ALOC prefixes:
- If the remote ALOC prefix is from the global ALOC space and the remote ALOC doesn't match the given global ALOC prefix, the initiator will use the given global ALOC prefix for the session.
In this use case the remote endpoint is outside the enterprise's private network, and the global remote ALOC prefixes show how the remote network is attached to the Internet 🌍 When a multipath transport protocol is used, the subflows can be routed via separate border routers to the remote endpoint, at both the local and remote sites if both are multi-homed. The initiator's egress packets in the local ALOC realm can be identified by the protocol value in the IP header, then routed to an explicit path (e.g., MPLS LSP, L2TPv3 tunnel, etc.) based on the ALOC prefix in the locator header. This lets you design a local ALOC overlay exit routing scheme. In the long-term routing architecture, the overlay (the tunnel mechanism) can be removed; see Section 6.2 💅
Figure 3 shows a conceptual diagram with two endpoints that have a multipath session over a VPN connection and over the Internet (in the intermediate routing architecture) 👑
Legend: *attachment point in the ALOC realm
UER=Unique ELOC region
EP=Endpoint
aRBR=anycast RBR
uRBR=unicast RBR
BR=Border Router
|-------------------------------------------------------------|
| UER1 | | UER2 |
|-----------------------------------------------|-------------|
| Enterprise1 | | Enterprise2 |
| ALOC Realm | | ALOC Realm |
| |---------------------------------| |
| | VPN | |
| | ALOC Realm | |
| *uRBR3 uRBR4* |
| |ALOC3 ALOC4| |
| |xxxxxxxxxxxX VPN RIB xxxxxxxxxxxx| |
| | | |
| | ALOC3 & ALOC4 | |
| |---------------------------------| |
| *EP1 | | *EP2 |
| ELOC1 |---------------------------------| ELOC2 |
| | ISP1 | ISP | ISP2 | |
| | ALOC Realm | Tier1 | ALOC Realm | |
| | | | | |
| BR1* *aRBR | | *aRBR *BR2 |
| | ALOC1 | | ALOC2 | |
| | | | | |
|-------------|xxxxxxxxxxxxxx DFZ xxxxxxxxxxxxxx|-------------|
| RIB | RIB | RIB | RIB | RIB |
| | | | | |
| ALOC1 | ALOC1 | ALOC1 | ALOC2 | ALOC2 |
| ALOC3 | ALOC2 | ALOC2 | ALOC1 | ALOC4 |
| ALOC4 | ELOC1 | | ELOC2 | ALOC3 |
| ELOC1 | | | | ELOC2 |
| | | | | |
|-------------------------------------------------------------|
Figure 3: Multi-pathing via VPN and the InternetThe first subflow is set up from the initiator (EP1) via uRBR3 and uRBR4 (both use a private unicast ALOC prefix) to the responder (EP2) ✨ Normal unicast forwarding is applied, and the ALOC prefixes of uRBR3 and uRBR4 are installed in the routing tables of both the local and remote ALOC realms. A second subflow goes over the Internet, specifically via BR1->BR2 to EP2. 0/0 exit routing is used to enter the Internet at both ALOC realms.
Note that ELOC prefixes can overlap, since the local and remote ALOC realms live in different ELOC regions and are separated by private unicast ALOC prefixes 🫶
The fourth use case is to use the private and global ALOC functionalities so they line up with the design and implementation of [Split-DNS] solutions 🔥
The fifth use case is for residential users. A residential user may use one or several ALOC prefixes, depending on the service offer and network design of the ISP. If the ISP wants to offer advanced support for multipath transport protocols and local ALOC exit routing, the residential user gets several ALOC prefixes. The ALOC provided to residential users comes from the GLB space, and anycast ALOC functionality is applied 🏡
9. Mandatory Extensions 🌸
9.1. Overview
To implement the hierarchical IPv4 framework, a few basic rules are needed 📝
- The DNS architecture must support a new extension: an A type Resource Record should be able to associate ALOC prefixes.
- An endpoint upgraded to support hIPv4 shall have information about the local ALOC prefixes. The local ALOC prefixes can be configured manually or provided via provisioning means such as DHCP.
- A globally unique IPv4 address block shall be reserved. This block is called the Global Locator Block (GLB). A service provider can have one or several ALOC prefixes allocated from the GLB.
- ALOC prefixes are announced via current BGP to adjacent peers. They are installed in the RIB of the DFZ. When the hIPV4 framework is fully implemented, only ALOC prefixes are announced between the BGP peers in the DFZ.
- An ALOC realm must have one or several RBRs attached to it. The ALOC prefix is configured as an anycast IP address on the RBR. The anycast IP address is installed into appropriate routing protocols so it can be distributed to the DFZ.
- The IPv4 socket API at endpoints must be extended to support local and remote ALOC prefixes. The modified IPv4 socket API must be backwards compatible with the current IPv4 socket API. The outgoing hIPv4 packet must be assembled by the hIPv4 stack with the local IP address from the socket as the source address and the remote ALOC prefix as the destination address in the IP header. The local ALOC prefix is inserted in the ALOC field of the locator header. The remote IP address from the socket API is inserted in the ELOC field of the locator header.
9.2. DNS Extensions ✨
Okay so, DNS is basically the "phone book" of the Internet, and hIPv4 brings a whole new addressing scheme 🫶. That means DNS needs a brand new Resource Record (RR) type for endpoints that have been upgraded to support hIPv4. Future RR types must follow the guidelines in [RFC3597] and [RFC5395], and this one has the following characteristics:
- Associated with the appropriate Fully Qualified Domain Name (FQDN), inserted in the NAME field.
- Assigned a new integer (QTYPE) in the TYPE field, to be assigned by IANA.
- The CLASS field is set to IN.
- The RDATA field is of an unknown type as defined in [RFC3597] and shall have the following format:
- Preference subfield: A 16-bit integer that specifies the preference given to this RR among others associated with a FQDN. Lower values are preferred over higher values.
- ALOC subfield: A 32-bit integer that specifies the Area Locator of the associated FQDN.
Here's the RDATA layout, bestie 🎀:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Preference |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
| ALOC |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 4: RDATA format of the ALOC RROnly endpoints that have been upgraded to support hIPv4 shall make use of the new ALOC RR. 💅 Also, there's no need to define a new ELOC RR, because the A RR does that job when the ALOC RR is returned. Iconic efficiency, no cap 🌸
9.3. Extensions to the IPv4 Header 🦋
Figure 5 shows how the locator header gets added onto the current IPv4 header, which creates a hIPv4 header. It's giving layers 🧚
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|I|S| FI|VLB|L| Protocol | LH Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area Locator (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint Locator (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LH Length (optional) | Padding (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: hIPv4 headerVersion: 4 bits
The Version field is identical to that of RFC 791.
IHL: 4 bits
The Internet Header Length field is identical to that of RFC 791.
Type of Service: 8 bits
The Type of Service is identical to that of RFC 791.
Total Length: 16 bits
The Total Length field is identical to that of RFC 791.
Identification: 16 bits
The Identification field is identical to that of RFC 791.
Flags: 3 bits
The Flags field is identical to that of RFC 791.
Fragment Offset: 13 bits
The Fragment Offset field is identical to that of RFC 791.
Time to Live: 8 bits
The Time to Live field is identical to that of RFC 791.
Protocol: 8 bits
A new protocol number must be assigned for hIPv4.
Header Checksum: 16 bits
The Header Checksum field is identical to that of RFC 791.
Source Address: 32 bits
The Source Address field is identical to that of RFC 791.
Destination Address: 32 bits
The Destination Address field is identical to that of RFC 791.
Options and Padding: Variable length
The Options and Padding fields are identical to that of RFC 791.
ALOC Realm Bit, A-bit: 1 bit 🌈
When the initiator and responder reside in different ALOC realms, the A-bit is set to 1 and the Area and Endpoint Locator fields must be used in the locator header. The size of the locator header is 12 bytes. When the A-bit is set to 0, the initiator and responder reside within the same ALOC realm. The Area and Endpoint Locator shall not be used in the locator header. The size of the locator header is 4 bytes.
Identifier Bit, I-bit: 1 bit 🔥
The identifier bit is set to 1 if the endpoint is using an identifier/locator split scheme within the locator header. The identifier/locator split scheme must indicate by how much the size of the locator header is increased. The Locator Header Length field is also added to the locator header.
Swap Bit, S-bit: 1 bit 🍓
The initiator sets the swap bit to 0 in the hIPv4 packet. An RBR will set this bit to 1 when it is swapping the source and destination addresses of the IP header with the ALOC and ELOC prefixes of the locator header.
Forwarding Indicator, FI-bits: 2 bits 👑
The purpose of the Forwarding Indicator (FI) field is to provide a mechanism for a future forwarding plane to identify which Forwarding Information Base (FIB) should be used for inter-ALOC realm sessions. The new forwarding plane will remove the swap functionality of IP and locator header values for both unicast and multicast sessions. The outcome is that the IP and transport protocol headers will remain intact and only FI and LH checksum values in the locator header will alternate. The following values are defined:
01: Local ALOC exit routing mode. The initiator shall set the FI-bits to 01 and the ALOC prefix in the locator header is used to forward the packets to the RBR that is the owner of the local ALOC prefix. The RBR shall change the FI-bits to 00.00: DFZ routing mode. The local ALOC RBR shall forward the packets according to the value in the destination address field of the IP header. The DFZ routers shall forward the packets based on the value in the destination address field of the IP header unless the destination address matches the local ALOC prefix. When this situation occurs, the packet enters the remote ALOC realm and the remote RBR shall change the FI-bits to 10.10: Remote ELOC approach routing mode. The remote ALOC RBR and following routers shall forward the packets based on the ELOC prefix in the locator header.11: Inter-ALOC RPF check mode. The local ALOC RBR changes the FI-bits to 11 and the following inter-ALOC routers on the shared tree shall apply the RPF check against the ALOC prefix in the locator header.
Valiant Load-Balancing, VLB-bits: 2 bits (optional, subject for further research) 🦋
The purpose of the Valiant Load-Balancing field is to provide a mechanism for multipath-enabled transport protocols to request explicit paths in the network for subflows, which are component parts of a session between two endpoints. The subflow path request can be set as follows:
00: Latency-sensitive application. Only one single subflow (multipath not applied), the shortest path through the network is requested.01: First subflow. The shortest path or Valiant Load-Balancing might be applied.11: Next subflow(s). Valiant Load-Balancing should be applied
Load-Balanced, L-bit: 1 bit (optional, subject for further research) ⭐
The initiator must set the L-bit to zero. A Valiant Load-Balancing-capable node can apply VLB switching for the session if the value is set to zero; if the value is set to 1, VLB switching is not allowed. When VLB switching is applied for the session, the node applying the VLB algorithm must set the value to 1.
Protocol: 8 bits
The Protocol field is identical to that of RFC 791.
Locator Header Checksum: 16 bits 💜
A checksum is calculated for the locator header only. The checksum is computed at the initiator, recomputed at the RBR, and verified at the responder. The checksum algorithm is identical to that of RFC 791.
Area Locator (optional): 32 bits
The Area Locator is an IPv4 address assigned to locate an ALOC realm in the Internet. The ALOC is assigned by an RIR to a service provider. The ALOC is globally unique because it is allocated from the GLB.
Endpoint Locator (optional): 32 bits
The Endpoint Locator is an IPv4 address assigned to locate an endpoint in a local network. The ELOC block is assigned by an RIR to a service provider or to an enterprise. In the intermediate routing architecture the ELOC block is only unique in a geographical region. The final policy of uniqueness shall be defined by the RIRs. In the long-term routing architecture the ELOC block is no longer assigned by an RIR; it is only unique in the local ALOC realm.
Locator Header Length (optional): 16 bits
The Locator Header Length is the total length of the locator header. Locator Header Length is applied when the identifier bit is set to 1. Identifier/locator split scheme parameters are inserted into the locator header after this field.
Padding (optional): variable
The locator header padding is used to ensure that the locator header ends on a 32-bit boundary. The padding is zero. 🙈
10. Consequences ✨
10.1. Overlapping Local and Remote ELOC Prefixes/Ports 💖
Okay so an ELOC prefix only means something inside its own ALOC realm, which means two endpoints in separate ALOC realms could, in a tiny unlucky chance, end up using the same local and remote ELOC prefixes 🫣 but don't panic, bestie, the session is still unique! The two processes talking over the transport protocol form a logical session that's uniquely identifiable by the 5-tuple, aka the combo <protocol, local IP address, local port, remote IP address, remote port> 🎀
It gets messy when two initiators with the same local ELOC prefix, sitting in two different ALOC realms, are hitting a responder in a third ALOC realm 😭 The initiators could pick the same local port value, and then you get an "identical session situation" for the application layer. Yikes 💀
To fix this, the hIPv4 stack has to accept only one unique session with the help of the ALOC info. If there's an "identical session situation" (both initiators using the same values in the 5-tuple), the hIPv4 stack shall allow only the first established session to continue. The following sessions must be prohibited, and the initiator gets told about the "identical session situation" through an ICMP notification 🙅♀️
MPTCP brings in a token that's locally significant and currently defined as 32 bits long ✨ This token gives a sixth tuple for future applications to identify and verify session uniqueness, so the chance of an "identical session situation" drops even further. And adding an identifier/locator database scheme to the hIPv4 framework completely removes the "identical session situation" 👑
10.2. Large Encapsulated Packets 🧚
Adding the locator header to an IPv4 packet to create an hIPv4 packet makes it bigger, yes, but since the packet is assembled at the endpoint, it doesn't add complications to the current Path MTU Discovery (PMTUD) mechanism in the network 🙌 The intermediate network between two endpoints won't see any difference in packet size, because from the network's point of view, IPv4 and hIPv4 packet sizes are the same. Iconic, honestly 💅
10.3. Affected Applications 🌸
Lots of apps stuff IP address info into the payload of a packet 👀 Some use it to set up new sessions or for identification, and some collect it to use as referrals. This section tries to list the apps that need to be enhanced, but it's by no means a comprehensive list! The apps can be sorted into five main categories:
- Applications based on raw sockets - a raw socket receives packets containing the complete header, unlike the other sockets that only receive the payload.
- Applications needed to enable the hIPv4 framework, such as DNS and DHCP databases, which must be extended to support ALOC prefixes.
- Applications that insert IP addresses into the payload or use the IP address for setting up new sessions or for some kind of identification or as referrals. An application in this category cannot set up sessions to other ALOC realms until extensions have been incorporated. Within the local ALOC realm there are no restrictions, since the current IPv4 scheme is still valid. The following applications have been identified:
- SIP: IP addresses are inserted in the SDP offers/answers, XML body,
Contact,Via,maddr,Route,Record-RouteSIP headers. - Mobile IP: the mobile node uses several IP addresses during the registration process.
- IPsec AH: designed to detect alterations at the IP packet header.
- RSVP: Resource Reservation Protocol (RSVP) messages are sent hop-by-hop between RSVP-capable routers to construct an explicit path.
- ICMP: notifications need to be able to incorporate ALOC information and assemble the hIPv4 header in order to be routed back to the source.
- Source Specific Multicast: the receiver must specify the source address.
- IGMPv3: a source-list is included in the IGMP reports.
- SIP: IP addresses are inserted in the SDP offers/answers, XML body,
- Applications related to security, such as firewalls, must be enhanced to support ALOC prefixes.
- Applications that work with FQDNs, but many use IP addresses instead, such as ping, traceroute, telnet, and so on. The CLI syntax needs to be upgraded to support ALOC and ELOC information via the extended socket API.
At first glance it seems like a LOT of apps need to be re-engineered and ported, but it's not all that bad 🥹 Applications used inside the local ALOC realm (e.g., an enterprise's private network) do not need to be upgraded, neither in the intermediate nor in the long-term architecture. The classical IPv4 framework is preserved. Only IP-aware applications used between ALOC realms need to be upgraded to support the hIPv4 header. IPv6 has the definitions in place of the applications mentioned above, but migrating apps from IPv4 to IPv6 can cost enterprises some capital expenditure, especially if the apps are customized or homegrown; see [Porting_IPv4].
As I said earlier, hIPv4 doesn't require porting apps used inside a private network. The takeaway: whatever next-generation architecture gets deployed, some apps will suffer, either during the transition period or while being re-engineered to be compatible with the new architecture 😤
10.4. ICMP 🛸
As long as an ICMP request is executed inside the local ALOC realm, the normal IPv4 ICMP mechanism can be used. As soon as the ICMP request exits the local ALOC realm, the locator header shall be used in the notifications. Therefore, extensions to the ICMP shall be implemented. These shall be compatible with [RFC4884] and support ALOC and ELOC information 📡
10.5. Multicast 🦋
Since local ELOC prefixes are only installed in the routing table of the local ALOC realm, there's a constraint with Reverse Path Forwarding (RPF), the check that keeps multicast forwarding loop-free 🔁 The source address of a multicast group (S,G) is what gets used for the RPF check, but the source's address can no longer be used as an RPF checkpoint outside the local ALOC realm. Rude 😒
To enable RPF globally for an (S,G), the multicast-enabled RBR (mRBR) must, at the source's ALOC realm, replace the value of the source address field in the IP header with the local ALOC prefix for inter-ALOC multicast streams. This can be achieved if the local RBR also acts as an anycast Rendezvous Point with MSDP and PIM capabilities. With these functionalities, the RBR becomes a multicast-enabled RBR (mRBR). The source registers at the mRBR, and a source tree is established between the source and the mRBR. When an inter-ALOC realm receiver subscribes to the multicast group, the mRBR has to swap the hIPv4 header in the following way:
a. Verify that the received packet uses the hIPv4 protocol value in the protocol field of the IP header.
b. Verify IP, locator, and transport protocol header checksums.
c. Replace the source address in the IP header with the local ALOC prefix.
d. Set the S-field to 1.
e. Decrease the TTL value by one.
f. Calculate IP, locator, and transport protocol header checksums. Transport protocol header calculations do not include the locator header fields.
g. Forward the packet to the shared multicast tree.
For the mRBR to function as described above, the source must assemble the multicast hIPv4 packet in the following way:
a. Set the local IP address (S) from the API in the source address field of the IP header and in the ELOC field of the locator header.
b. Set the multicast address (G) from the API in the destination address field of the IP header.
c. Set the local ALOC prefix in the ALOC field of the locator header.
d. Set the transport protocol value in the protocol field of the locator header and the hIPv4 protocol value in the protocol field of the IP header.
e. Set the desired parameters in the A-, I-, S-, VLB-, and L-fields of the locator header.
f. Set the FI-bits of the locator header to 00.
g. Calculate IP, locator, and transport protocol header checksums. Transport protocol header calculations do not include the locator header fields. When completed, the packet is transmitted.
The downstream routers from the mRBR towards the receiver will use the source address (which is the source's ALOC prefix after the mRBR) in the IP header for RPF verification 🧭 And for the receiver to create Real-time Transport Control Protocol (RTCP) receiver reports, all the info is provided in the hIPv4 header of the packet.
Because Source Specific Multicast (SSM) and IGMPv3 use IP addresses in the payload, both protocols need to be modified to support the hIPv4 framework 🫠
11. Traffic Engineering Considerations 🎀
When the intermediate phase of the hIPv4 framework is fully implemented, ingress load balancing to an ALOC realm can be influenced by where the RBRs are placed in the realm, since an RBR provides a shortest path scheme. Also, if RIR policies allow, a service provider can have several ALOCs assigned. Hence, traffic engineering and filtering can be done with the help of ALOC prefixes. For example, sensitive traffic can be aggregated under one ALOC prefix that isn't fully distributed into the DFZ. Main character planning 🧠
If needed, an ALOC traffic engineering solution between ALOC realms might be developed, to create explicit paths that can be engineered via specific ALOC prefixes. For example, develop a mechanism similar to the one described in [Pathlet_Routing]. Further studies are needed; first it should be evaluated whether there's demand for such a solution 🔍
Ingress load balancing to a private remote ALOC realm (remote site) is influenced by how many attachment points to the Internet the site uses and where those attachment points are placed at the site. In order to apply local ALOC exit routing, e.g., from a multi-homed site, some new network nodes are needed between the initiator and the border routers of the site.
In the intermediate routing architecture this is achieved by using overlay architectures such as MPLS LSP, L2TPv3 tunnels, etc. The new network node(s) shall be able to identify hIPv4 packets, based on the protocol field in the IP header, and switch the packets to explicit paths based on the ALOC prefix in the locator header. In the long-term routing architecture, the overlay solution is replaced with a new forwarding plane; see Section 6.2 🦋
Together with a multipath transport protocol, the subflows can be routed via specific attachment points, that is, border routers sitting between the private local/remote ALOC realms (multi-homed sites) and the Internet. Multi-homing becomes multi-pathing ✨ For details, see Appendix B.
11.1. Valiant Load-Balancing 💖
okay so multipath-enabled transport protocols open the door to a whole new way of designing backbone networks, based on Valiant Load-Balancing [VLB] 🦋. picture this: two sites hang off the Internet through a single uplink each, the endpoints are multipath-enabled, and they're only attached with one interface/ELOC-prefix. ngl both subflows will most likely take the shortest path through the Internet 😭. same links, same congestion. if a link gets congested or fails, both subflows might drop packets at the same time, and the whole point of multi-pathing just vanishes 💀.
the "subflows-over-same-links" problem can be avoided if you traffic engineer the subflows to take different paths, but that's hard to pull off with classic traffic engineering like IGP tuning or MPLS-based traffic engineering 🙈. the fix is adding a mechanism to the locator header, and that's how the "subflows-over-same-links" scenario might be avoided 🧚
now here's the glow-up. if the RBR functionality is deployed on a Valiant Load-Balancing enabled backbone node (hereafter called vRBR) and the backbone nodes are interconnected via logical full meshed connections, Valiant Load-Balancing can be applied for the subflows ✨. when a subflow has the appropriate bits set in the VLB-field of the locator header, the first ingress vRBR SHALL do VLB switching of the subflow 👑. the ingress vRBR is allowed to do VLB switching of the subflow's packets if the VLB-bits are set to 01 or 11, the L-bit is set to 0, and the local ALOC prefix of the vRBR matches the ALOC-field's prefix. if there are no ALOC and ELOC fields in the locator header, but the other fields' values are set as described above, the vRBR SHOULD apply VLB switching as well for the subflow, because it's an intra-ALOC realm subflow belonging to a multipath-enabled session 🫶
with this combo of parameters, the subflow only gets VLB switched at the first ALOC realm, and the subflows might be routed through the Internet on different paths 🦋. if VLB switching happened at every ALOC realm, it would most likely add too much latency for the subflows, which is a big nope 😭. the VLB switching at the first ALOC realm won't separate the subflows on the first and last mile links (the site with a single uplink). so if the subflows on the first and last mile link need to be routed on separate links, the endpoints SHOULD be deployed in a multi-homed environment 💅. studies on how Valiant Load-Balancing influences traffic patterns between interconnected VLB [iVLB] backbone networks have been done. nevertheless, more studies are needed regarding Valiant Load-Balancing scenarios 🌸
12. Mobility Considerations 🦋
okay this section looks at two types of mobility solutions: site mobility and endpoint mobility 💜
Site mobility:
classical multi-homing is the most common solution for enterprises that want site mobility today 💼. multi-homing is one of the key findings behind the growth of the DFZ RIB, see [RFC4984], Sections 2.1 and 3.1.2 📈. the hIPv4 framework can give enterprises site mobility without needing a classical multi-homed solution ✨
one of the big reasons people multi-home is to avoid renumbering the local infrastructure when an upstream ISP gets replaced 😩. so today, PI-address blocks are deployed at enterprises. in the intermediate routing architecture, an enterprise gets a regional PI ELOC block (for details, see Appendix A) that's used for internal routing 🧚. the upstream ISP provides an ALOC prefix that describes how the enterprise's network is connected to the Internet. if the enterprise wants to switch to another ISP, it only changes the ALOC prefix at the endpoints, from the previous ISP's ALOC prefix to the new ISP's ALOC prefix. no connectivity interruptions in the local network, because the ALOC prefix is only used for Internet connectivity. several ALOCs can be used at the same time at the endpoints, so a smooth migration from one ISP to another is possible 🎀. in the long-term routing architecture, once the forwarding plane is upgraded, the regional PI ELOC block gets returned to the RIR and the enterprise can use a full 32-bit ELOC space to design its internal routing topology 👑
an enterprise can easily become multi-homed or switch ISPs 🌈. the local ELOC block is used for internal routing, and upstream ISPs provide their ALOC prefixes for Internet connectivity. multi-homing is discussed in detail in Appendix B 💅
Endpoint mobility:
as I said earlier, MPTCP is the most interesting identifier/locator split scheme for solving endpoint mobility scenarios 🦋. MPTCP introduces a token, which is locally significant and currently defined as 32 bits long. the token gives you a sixth tuple to identify a session and verify it's unique. this sixth tuple (the token) doesn't depend on the underlying layer, the IP layer. so the session is identified with the help of the token, and the application isn't aware when the locator parameters change, e.g., during a roaming situation. but it is REQUIRED that the application doesn't make use of ELOC/ALOC information 🙈. in multi-homed scenarios, the application can make use of ELOC information, which won't change if the endpoint stays fixed in its location 🧚
security issues arise 😱: the token can be captured during the session by, for example, a man-in-the-middle attack. these attacks can be mitigated by applying [tcpcrypt], for example. if the application needs full protection against man-in-the-middle attacks, the user SHOULD apply the Transport Layer Security Protocol (TLS) [RFC5246] for the session 🔒
the most common endpoint mobility use case today is one where the responder lives in the fixed network and the initiator is mobile 📱. so MPTCP will provide roaming capabilities for the mobile endpoint, as long as both endpoints are using the MPTCP extension. however, in some use cases the fixed endpoint needs to start a session to a mobile responder. that's why Mobile IP (MIP) [RFC5944] SHOULD incorporate the hIPv4 extension, since MIP provides a rendezvous service for mobile endpoints 🌸
also, lots of applications provide rendezvous services for their users, e.g., SIP, peer-to-peer, and Instant Messaging services 💬. a generic rendezvous service can be provided by an identifier/locator database scheme, e.g., HIP, ILNP, or NBS. if desired, the user (actually the application) can use one of these rendezvous service schemes, such as extended MIP, some application-specific rendezvous services, or a generic rendezvous service, or some combination of them 🫶
the hIPv4 framework won't define which identifier/locator split solution SHOULD be used for endpoint mobility 🤷♀️. the hIPv4 framework focuses on routing scalability and supports several identifier/locator split solutions that can be exploited to develop new services, with the focus on endpoint mobility 💖
13. Transition Considerations 🌈
the hIPv4 framework isn't introducing any new protocols that would be mandatory for the transition from IPv4 to hIPv4. instead, extensions get added to existing protocols 🧚. the framework needs extensions to the current IPv4 stack, to infrastructure systems, and to some applications that use IP address information. but the current forwarding plane in the Internet stays intact, except that a new forwarding element (the RBR) is REQUIRED to create an ALOC realm 👑
extensions to the IPv4 stack, to infrastructure systems, and to applications that use IP address information can be deployed in parallel with the current IPv4 framework 🦋. genuine hIPv4 sessions can be established between endpoints even though the current unidimensional addressing structure is still around ✨
so when will the unidimensional addressing structure get replaced by a hierarchical addressing scheme, with a fourth hierarchy added to the routing architecture? the author thinks there are two possible tipping points 🤔
- when the RIB of the DFZ gets close to the capabilities of current forwarding planes. who will pay for the upgrade? or will the service provider only accept ALOC prefixes from other service providers and avoid capital expenditures? 💸
- when the depletion of IPv4 addresses causes enough problems for service providers and enterprises 😬
the biggest risk, and the reason the hIPv4 framework might not succeed, is how short the time frame is until the expected depletion of the IPv4 address space. honestly, the first RIR ran out of IPv4 addresses during the IESG review process of this document (April 2011) 😭. also, will enterprises give up the global allocation of the current IPv4 address block they've gained, now that an IPv4 address block has become an asset with economic value? 💰
the transition requires upgrading the endpoint's stack, and that's a drawback compared to the [CES] architectures proposed in [RFC6115] 🙈. a transition to an architecture that requires upgrading the endpoint's stack is considerably slower than one that only requires upgrading some network nodes. but the transition might not be as slow or challenging as it first seems, since hIPv4 is an evolution of the Internet that's already deployed 🌸
- not all endpoints need to be upgraded. the endpoints that don't establish sessions to other ALOC realms can keep using the classical IPv4 framework. also, legacy applications that are only used inside a local ALOC realm don't need to be ported to another framework. for further details, see Appendix C 💅
- upgrading the endpoint's stack, e.g., at critical or complicated systems, will definitely take time, so it would be more convenient to install a middlebox in front of such systems. it's obvious that the hIPv4 framework needs a middlebox solution to speed up the transition, and combining CES architectures with the hIPv4 framework might produce such a middlebox. for further details, see Appendix D 🎀
- the framework is incrementally deployable. not all endpoints in the Internet need to be upgraded before the first IPv4 block can be released from a globally unique allocation status to a regionally unique allocation status. that means achieving ELOC status for the prefixes used in a local network in the intermediate routing architecture, see Appendix D. an ALOC realm that wants local unique status for its ELOC block in the long-term routing architecture doesn't need to wait for other ALOC realms to reach the same level at the same time. it's sufficient that the other ALOC realms have achieved the intermediate routing architecture status. for further details, see Section 6 🌈
14. Security Considerations 🔐
Okay bestie, security is where things get SERIOUS 😭 hIPv4 doesn't bring in any new network mechanisms except one new type of border router, so it sits on the same routing architecture that's already deployed. That means the best current practices for securing ISP networks are still valid 💅 And since the DFZ won't contain ELOC prefixes anymore, there are some security benefits AND some complications, so let's unpack it 🧐
Here's the good news ✨ A single ELOC prefix can't be hijacked by longest match from another ALOC realm anymore, because the prefixes are separated by a locator, the ALOC. To pull off a hijack of a certain ELOC prefix, the attacker would need the WHOLE ALOC realm to be routed via a bogus ALOC realm, which is a much bigger ask 🙅♀️ Studies should be done with the Secure Inter-Domain Routing (SIDR) working group to figure out whether the ALOC prefixes can be protected from hijacking 🔍
But here's the plot twist 😬 Not being able to hijack a certain ELOC prefix has some implications when you're mitigating distributed denial-of-service (DDoS) attacks. This is especially true in the long-term routing architecture, e.g., when a multi-homed enterprise is connected with unicast ALOC RBRs to the ISPs.
One method people use today to mitigate DDoS attacks is to inject a more specific prefix (typically a host prefix) into the routing table, so the victim of the attack is "relocated", i.e., a sinkhole is created in front of the victim 🕳️ The sinkhole may separate bogus traffic from valid traffic, or analyze the attack. The challenge in the long-term routing architecture is how to reroute a specific ELOC prefix of the multi-homed enterprise when that ELOC prefix cannot be installed in the ISP's routing table 😵
Creating a sinkhole for all traffic designated to an ALOC realm might be challenging and expensive, depending on the size of the multi-homed enterprise. Putting the sinkhole at the enterprise's ALOC realm could saturate the connections between the enterprise and the ISPs, so this approach is not a real option 🙅♀️
Now the fun part 🧚 By borrowing ideas from a service-centric networking architecture [SCAFFOLD], a sinkhole service can be created. Here's an example of how a distributed sinkhole service could be designed:
a. A firewall (or similar node) at the victim's ALOC realm discovers an attack. The security staff at the enterprise realizes that the amount of incoming traffic caused by the attack is soon going to saturate the connections or other resources. So the staff informs the upstream ISPs of the attack, and also the victim's ALOC prefix X and ELOC prefix Y. 🚨
b. The ISP reserves the resources for the sinkhole service. These resources make use of ALOC prefix Z, and they're programmed with a service ID and the victim's X and Y prefixes. The ISP informs the victim's security staff of the service ID. The ISP applies a NAT rule on their RBRs and/or hIPv4-enabled routers. The NAT rule replaces the destination address in the IP header of packets with Z when the destination address of the IP header matches X and the ELOC prefix of the locator header matches Y. Also, the service ID is inserted into the locator header; the service ID acts as a referral for the sinkhole. It's possible that the sinkhole serves several victims, so a referral is needed. PMTUD issues must be taken into account. 🎀
c. The victim's inbound traffic is now routed at the RBRs and/or hIPv4-enabled routers to the sinkhole(s), and the traffic is identified by the service ID. Bogus traffic is discarded at the sinkhole. For valid traffic, the value of the destination address in the IP header, Z, is replaced with X. By using a service ID in the analyzed packets, the enterprise is informed that the packets containing the service ID are valid traffic and allowed to be forwarded to the victim 💖 It might be possible that not all upstream ISPs are redirecting traffic to the distributed sinkholes, so traffic that does not contain the agreed service ID might be bogus. Also, by inserting a service ID into the valid packets, overlay solutions between the routers, sinkholes, and victim can be avoided 🦋 If a valid packet with a service ID traverses another RBR or hIPv4-enabled router containing the same NAT rule, that packet is not rerouted to the sinkhole. The enterprise shall ensure that the victim does not use the service ID in its replies -- if the attacker becomes aware of the service ID, the sinkhole is disarmed 💀
Today, traffic is sent to sinkholes by injecting host routes into the routing table. That method can still be used inside an ALOC realm for intra-ALOC attacks. For attacks spanning several ALOC realms, new methods are needed, and one example is described above. It is desirable that the RBR and hIPv4-enabled routers are capable of applying NAT rules and inserting service IDs into selected packets in the forwarding plane ⭐
15. Conclusions 🌈
This document gives a high-level overview of the hierarchical IPv4 framework, which could be built in parallel with the current Internet by implementing extensions at several architectures. Implementing the hIPv4 framework won't require a major service window break in the Internet or in the private networks of enterprises. Basically, hIPv4 is an evolution of the current IPv4 framework 🦋
The transition to hIPv4 might be attractive for enterprises, since the hIPv4 framework doesn't create a catch-22 situation. Like, when should an application that's only used inside the private network be ported from IPv4 to IPv6? And what's the business justification for porting it to IPv6? 🤔 Another thing: when an IPv4/v6 dual-stack solution is used, it could impose operational expenditures, especially with rule sets at firewalls, both in front of servers and at clients 💸
If an enterprise chooses to deploy hIPv4, the legacy applications don't need to be ported, because hIPv4 is backwards compatible with the classical IPv4 framework. That means lower costs for the enterprise, and the new stack's capabilities to better serve mobility use cases are an extra bonus 🎁
But the enterprise has to decide soon and act promptly, because IPv4 address depletion is a reality in the very near future ⏰ If the decision is delayed, IPv6 will arrive, and then, sooner or later, the legacy applications will need to be ported.
Though this document has focused only on IPv4, a similar scheme could be deployed for IPv6 in the future, creating a 64x64 bit locator space. But at the time this document was written, some benefits would have been lost, such as:
- Backwards compatibility with the current Internet, and therefore no smooth migration plan is gained.
- The locator header, including ALOC and ELOC prefixes, would have been larger: 160 bits versus 96 bits. And the identifier (EUI-64) would always have been present, which can be considered a pro or a con depending on one's view of the privacy issue, as discussed in [RFC4941] and in [Mobility_& _Privacy] 🙈
If an enterprise prefers hIPv4 (e.g., because it gains additional IPv4 addresses and smooth migration capabilities), there's an unintentional side effect, from the enterprise's point of view, on the routing architecture of the Internet 🌸 Multi-homing becomes multi-pathing, and an opportunity opens up for service providers to create an Internet routing architecture that holds fewer prefixes and generates fewer BGP updates in the DFZ than the current Internet 👑
The hIPv4 framework provides a new hierarchy in the routing subsystem, and it's complementary work to multipath-enabled transport protocols (such as MPTCP and SCTP) and service-centric networking architectures (such as SCAFFOLD) 💜 End users and enterprises aren't interested in routing issues in the Internet, so a holistic view should be applied across the three disciplines, with a focus on new service opportunities, and communicated to end users and enterprises. Then maybe the transition request to a new routing architecture will be accepted and carried out 🫶 But more work is needed to build a holistic framework across the three disciplines.
16. References 📚
16.1. Normative References
Here's the normative reference list, verbatim so nothing gets lost in translation 🧾
[RFC1385] Wang, Z., "EIP: The Extended Internet Protocol", RFC
1385, November 1992.
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC
4033, March 2005.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro,
"Extended ICMP to Support Multi-Part Messages", RFC 4884,
April 2007.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4,
Revised", RFC 5944, November 2010.16.2. Informative References 📚✨
okay bestie, this is the extra-credit reading list 🤓💅 these are the sources the document points to for background, not the ones it depends on to work. here they are, exactly as written:
[CES] Jen, D., Meisel, M., Yan, H. Massey, D., Wang, L., Zhang,
B., Zhang, L., "Towards A New Internet Routing
Architecture: Arguments for Separating Edges from Transit
Core", 2008, http://conferences.sigcomm.org/
hotnets/2008/papers/18.pdf.
[Dagstuhl] Arkko, J., Braun, M.B., Brim, S., Eggert, L., Vogt, C.,
Zhang, L., "Perspectives Workshop: Naming and Addressing
in a Future Internet", 2009, http://www.dagstuhl.de/
de/programm/kalender/semhp/?semnr=09102.
[ID/loc_Split]
Thaler, D., "Why do we really want an ID/locator split
anyway?", 2008,
http://conferences.sigcomm.org/sigcomm/2008/workshops/
mobiarch/slides/thaler.pdf.
[ILNP] Atkinson, R., "ILNP Concept of Operations", Work in
Progress, February 2011.
[iVLB] Babaioff, M., Chuang, J., "On the Optimality and
Interconnection of Valiant Load-Balancing Networks",
2007, http://people.ischool.berkeley.edu/~chuang/
pubs/VLB-infocom07.pdf.
[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol", Work in Progress, June
2011.
[Mobility_&_Privacy]
Brim, S., Linsner. M., McLaughlin, B., and K. Wierenga,
"Mobility and Privacy", Work in Progress, March 2011.
[NBS] Ubillos, J., Xu, M., Ming, Z., and C. Vogt, "Name-Based
Sockets Architecture", Work in Progress, September 2010.
[Nimrod] Chiappa, N., "A New IP Routing and Addressing
Architecture", 1991, http://ana-3.lcs.mit.edu/
~jnc/nimrod/overview.txt.
[Pathlet_Routing]
Godfrey, P.G., Shenker, S., Stoica, I., "Pathlet
Routing", 2008,
http://conferences.sigcomm.org/hotnets/2008/
papers/17.pdf.
[Porting_IPv4]
DeLong, O., "Porting IPv4 applications to dual stack,
with examples", 2010,
http://www.apricot.net/apricot2010/program/tutorials/
porting-ipv4-apps.html.
[RBridge] Perlman, R., "RBridges, Transparent Routing", 2004,
http://www.ieee-infocom.org/2004/Papers/26_1.PDF.
[Revisiting_Route_Caching]
Kim, C., Caesar, M., Gerber, A., Rexford, J., "Revisiting
Route Caching: The World Should Be Flat", 2009,
http://www.springerlink.com/content/80w13260665v2013/.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, September 2003.
[RFC3618] Fenner, B., Ed., and D. Meyer, Ed., "Multicast Source
Discovery Protocol (MSDP)", RFC 3618, October 2003.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, May 2006.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, September 2007.
[RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report
from the IAB Workshop on Routing and Addressing", RFC
4984, September 2007.
[RFC5395] Eastlake 3rd, D., "Domain Name System (DNS) IANA
Considerations", RFC 5395, November 2008.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, June 2010.
[RFC6115] Li, T., Ed., "Recommendation for a Routing Architecture",
RFC 6115, February 2011.
[RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J.
Iyengar, "Architectural Guidelines for Multipath TCP
Development", RFC 6182, March 2011.
[RFC6227] Li, T., Ed., "Design Goals for Scalable Internet
Routing", RFC 6227, May 2011.
[RRG] RRG, "IRTF Routing Research Group Home Page",
http://tools.ietf.org/group/irtf/trac/wiki/
RoutingResearchGroup.
[SCAFFOLD] Freedman, M.J., Arye, M., Gopalan, P., Steven Y. Ko,
S.Y., Nordstrom, E., Rexford, J., Shue, D. "Service-
Centric Networking with SCAFFOLD", September 2010
http://www.cs.princeton.edu/research/techreps/TR-885-10.
[Split-DNS] BIND 9 Administrator Reference Manual,
http://www.bind9.net/manual/bind/9.3.1/
Bv9ARM.ch04.html#AEN767.
[tcpcrypt] Bittau, A., Hamburg, M., Handley, M., Mazi`eres, D.,
Boneh, D., "The case for ubiquitous transport-level
encryption", 2010, http://tcpcrypt.org/tcpcrypt.pdf.
[VLB] Zhang-Shen, R., McKeown, N., "Designing a Predictable
Internet Backbone with Valiant Load-Balancing", 2004,
http://conferences.sigcomm.org/hotnets/
2004/HotNets-III%20Proceedings/zhang-shen.pdf.17. Acknowledgments 🫶💖
big thank-yous to everyone who helped make this happen 🥹 first, the active folks on the Routing Research Group mailing list [RRG]. they tossed in ideas, proposals, and discussions that shaped the architecture of the hIPv4 framework 🌸 the people who gave super valuable review input, listed alphabetically, are Aki Anttila, Mohamed Boucadair, Antti Jarvenpaa, Dae Young Kim, Mark Lewis, Wes Toman, and Robin Whittle 👑
during the IRSG and IESG review process, Rajeev Koodli, Wesley Eddy, Jari Arkko, and Adrian Farrel also gave valuable review input 🦋
and lastly, a special shoutout to Alfred Schwab from the Poughkeepsie ITSO for his editorial assistance 🎀 iconic team behaviour, no notes 💅
Appendix A. Short-Term and Future IPv4 Address Allocation Policy 🔮
okay so this appendix is the "what would this do to IPv4 address handouts" section 👀 we're looking at how the hIPv4 framework could shake up IPv4 address allocation policies, so the new framework can reuse some IPv4 address blocks ♻️ the Regional Internet Registries (RIRs) are the ones who shall define the final policies, not us 🙅♀️
when the intermediate routing architecture (see Figure 1) is fully implemented, every ALOC realm could have a full IPv4 address space, except the GLB, to allocate ELOC blocks from ✨ there are some implications though 😬 for an enterprise to get site mobility, meaning switching service providers without changing its ELOC scheme, the enterprise should implement an autonomous system (AS) solution with an ALOC prefix at the attachment point to the service provider 🧚
bigger enterprises have the resources to do AS border routing, and most of them already have multi-homing solutions 💼 small and midsize enterprises (SMEs) might not have the resources for AS border routing, or the implementation costs them way too much 💸 also, if every enterprise needs its own allocated ALOC prefix, the RIB at the DFZ -- the RIB gets stuffed with a huge number of non-aggregatable ALOC prefixes 📈💀
so a compromise is needed 🤝 an SME usually has a single uplink to the Internet, and it should be able to reserve a PI ELOC block from the RIR without being forced to create an ALOC realm, meaning it doesn't have to implement an RBR solution and AS border routing 🙌 since the PI ELOC block is no longer globally unique, an SME can only reserve it for the region where it is active or has its attachment point to the Internet 🌍 the attachment point rarely moves to another country, so it's enough for the PI ELOC block to be regionally unique 💅
when the enterprise changes its Internet service provider, it doesn't have to change its ELOC scheme, only the local ALOC prefix at the endpoints changes 🔁 the internal traffic at an enterprise doesn't use the ALOC prefix at all. internal routing only uses the ELOC prefixes, so the internal routing and addressing architectures stay preserved 🫶
⚠️ heads up: mergers and acquisitions can cause ELOC conflicts, because the PI ELOC block is now only regionally unique 😭 if an enterprise in region A acquires an enterprise in region B, there's a slight chance both have overlapping ELOC prefixes.
if overlapping ELOC prefixes do happen, the private unicast ALOC solution can be used to separate them, but only if all the affected endpoints support the hIPv4 framework 🧩
finally, residential users only get PA locators 🏠 when a residential user changes service provider, they have to replace their locators. since a PA ELOC block is no longer globally unique, every Internet service provider can use the PA ELOC blocks in its ALOC realms, and the PA locators basically become private locators for the service providers 🌸
now, if the forwarding planes and all hosts that set up inter-ALOC realm sessions are upgraded to support the hIPv4 framework, meaning the long-term routing architecture (see Figure 2) is implemented, a few really interesting things happen 🤩
- the regional allocation policy for PI ELOC spaces can be removed, and the enterprise can use the whole IPv4 address space that's globally unique today. the ELOC space is then only significant inside its local ALOC realm 🌈
- in case of mergers or acquisitions of enterprises, the private unicast ALOC solution can be used to separate overlapping ELOC spaces 🧠
- the GLB space can be expanded to use all 32 bits (except for the blocks defined in RFC 1918) for anycast and unicast ALOC allocations, and only ISPs are allowed to apply for GLB prefixes 🏢
- the global anycast ALOC solution can be replaced with the global unicast ALOC solution, since the ISP and enterprise no longer need to share ELOC routing information. there's also enough space in the GLB to reserve global unicast ALOC prefix(es) for every enterprise 🎉
- residential users will still use global anycast ALOC solutions, and if they change service providers, their locators need to be replaced 🏠🔄
the result is a 32x32 bit locator space 🌟 when an enterprise replaces one ISP with another, only the ALOC prefix(es) get replaced, at endpoints and infrastructure nodes. renumbering of ALOC prefixes can be automated by, for example, DHCP and extensions to IGP 🤖💖
Appendix B. Multi-Homing becomes Multi-Pathing ✨
Okay so picture the endgame 🦋. Once the move to the intermediate routing architecture (see Figure 1) is fully completed, the RIB of an ISP that has created an ALOC realm is gonna have these entries:
- The PA ELOC blocks of directly attached customers (residential and enterprises)
- The PI ELOC blocks of directly attached customers (e.g., enterprises)
- The globally unique ALOC prefixes, received from other service providers
The ISP will not carry any PA or PI ELOC blocks from other service providers in its routing table 🙈. To do routing and forwarding between ISPs, only the ALOC info of other ISPs is needed. Lowkey genius, no cap.
So then the big question: how do we keep ALOC growth reasonable? If the enterprise is using PI addresses, has an AS number, and is implementing BGP, like, why not just apply for an ALOC prefix? 🤔
Classical multi-homing is causing the biggest impact on RIB growth in the DFZ 😭, so swapping a /20 IPv4 prefix for a /32 ALOC prefix will not reduce the size of the RIB in the DFZ. Not me watching that happen 💀.
Honestly, the only thing that will probably stop this is a yearly cost for allocating an ALOC prefix, except if you're a service provider providing access and/or transit traffic for your customers. And it's totally reasonable to charge non-service providers, because when an enterprise uses an ALOC prefix, it's reserving a FIB entry throughout the DFZ. That FIB entry needs power, space, hardware, and cooling on all the routers in the DFZ. Somebody's paying for that, bestie 🫶.
Implementing this kind of ALOC allocation policy will shrink the DFZ RIB size quite well, because multi-homing will no longer increase the RIB size of the DFZ. 💖 But this policy will have some impact on resilience behavior, because by compressing routing information we lose visibility in the network. In today's multi-homing solutions, the network always knows where the remote endpoint resides. If a link or network failure happens, a backup path is calculated, an alternative path is found, and all routers in the DFZ are aware of the topology change. That functionality takes the workload off the endpoints: they only need to find the closest ingress router, and the network will deliver the packets to the egress router, regardless (almost) of what failures happen in the network 😤. But with the growth of multi-homed prefixes, the DFZ routers have been forced to carry bigger workloads, perhaps close to their limits. The workload between the network and the endpoints is not in balance anymore.
So the conclusion is that endpoints should take more responsibility for their sessions by offloading the workload from the network. How? Let's walk through an example 👀.
A remote enterprise has been given an ELOC block 192.168.1.0/24, either via static routing or BGP announced to the upstream service providers. The upstream service providers provide the ALOC information for the enterprise, 10.1.1.1 and 10.2.2.2. A remote endpoint has been installed and given ELOC 192.168.1.1. The ELOC is a locator defining where the remote endpoint is attached to the remote network. The remote endpoint has been assigned ALOCs 10.1.1.1 and 10.2.2.2. An ALOC is a locator defining the attachment point of the remote network to the Internet.
The initiator (local endpoint), which has ELOC 172.16.1.1 and ALOC prefixes 10.3.3.3 and 10.4.4.4, has established a session by using ALOC 10.3.3.3 to the responder (remote endpoint) at ELOC 192.168.1.1 and ALOC 10.1.1.1. That is, both networks 192.168.10/24 and 172.16.1.0/24 are multi-homed. ALOCs are not available in the current IP stack's API, but both ELOCs are seen as the local and remote IP addresses in the API, so the application will communicate between IP addresses 172.16.1.1 and 192.168.1.1. If ALOC prefixes are included, the session is established between 10.3.3.3:172.16.1.1 and 10.1.1.1:192.168.1.1.
Next, a network failure occurs and the link between the responder border router (BR-R1) and the service provider that owns ALOC 10.1.1.1 goes down. The border router of the initiator (BR-I3) will not be aware of the situation, because only ALOC information is exchanged between service providers, and ELOC information is compressed to stay within ALOC realms. But BR-R1 will notice the link failure. BR-R1 could rewrite the ALOC field in the locator header for this session from 10.1.1.1 to 10.2.2.2 and send the packets to the second service provider via BR-R2. The session between the initiator 10.3.3.3:172.16.1.1 and the responder 10.2.2.2:192.168.1.1 remains intact, because the legacy 5-tuple at the IP stack API does not change. Only the ALOC prefix of the responder has changed, and this information is not shown to the application. An assumption here is that the hIPv4 stack does accept changes of ALOC prefixes on the fly (more about this later) 🧚.
If the network link between BR-I3 and the ISP providing ALOC 10.3.3.3 fails, BR-I3 could rewrite the ALOC prefix in the locator header and route the packets via BR-I4, and the session would stay up. If there is a failure somewhere in the network, the border routers might receive an ICMP destination unreachable message (if it isn't blocked by some security functionality) and then try to switch the session over to the other ISP by replacing the ALOC prefixes in the hIPv4 header. Or the endpoints might try to switch to the other ALOCs themselves after a certain time-out in the session. In all session transition cases, the legacy 5-tuple remains intact. ✨
⚠️ If border routers or one of the endpoints changes the ALOC prefix without a negotiation with the remote endpoint, security issues arise. Can the endpoints trust the remote endpoint when ALOC prefixes are changed on the fly? Is it still the same remote endpoint, or has the session been hijacked by a bogus endpoint? The obvious answer is that an identification mechanism is needed to ensure that after a change in the path or a change of the attachment point of the endpoint, the endpoints are still the same. An identifier needs to be exchanged during the transition of the session. 😱
Identifier/locator split schemes have been discussed on the [RRG] mailing list, for example multipath-enabled transport protocols and identifier database schemes. Both types of identifiers can be used to protect the session from being hijacked. A session identifier will provide a low-level security mechanism, offering some protection against hijacking of the session, and also provide mobility. SCTP uses the verification tag to identify the association, and MPTCP incorporates a token functionality for the same purpose. Both can be considered to fulfill the characteristics of a session identifier. [tcpcrypt] can be used to further mitigate session hijacking. If the application requires full protection against man-in-the-middle attacks, TLS should be applied for the session. Both transport protocols are also multipath-capable. Implementing multipath-capable transport protocols in a multi-homed environment will provide new capabilities, such as:
- Concurrent and separate exit/entry paths via different attachment points at multi-homed sites.
- True dynamic load-balancing, in which the endpoints do not participate in any routing protocols or do not update rendezvous solutions due to network link or node failures.
- Only a single Network Interface Card (NIC) on the endpoints is required.
- In case of a border router or ISP failure, the multipath transport protocol will provide resilience.
By adding more intelligence at the endpoints, such as multipath-enabled transport protocols, the workload of the network is offloaded, and the network can take less responsibility for providing visibility of destination prefixes on the Internet. For example, prefix compression in the DFZ can be applied, and only the attachment points of a local network need to be announced in the DFZ. 🌈 The IP address space also no longer needs to be globally unique. It is sufficient that only a part is globally unique, with the rest being only regionally unique (in the long-term routing architecture, locally unique), as discussed in Appendix A.
The outcome is that the current multi-homing solution can migrate towards a multi-pathing environment with the following characteristics:
- An AS number is not mandatory for enterprises.
- BGP is not mandatory at the enterprise's border routers. Static routing with Bidirectional Forwarding Detection (BFD) [RFC5880] is an option.
- Allocation of global ALOC prefixes for the enterprise should not be allowed. Instead, upstream ISPs provide the global ALOC prefixes for the enterprise.
- MPTCP provides dynamic load-balancing without using routing protocols. Several paths can be used simultaneously, and thus resilience is achieved.
- Provides low growth of RIB entries at the DFZ.
- When static routing is used between the enterprise and the ISP:
- The RIB size at the enterprise's border routers does not depend upon the size of the RIB in the DFZ or in adjacent ISPs.
- The enterprise's border router cannot cause BGP churn in the DFZ or in the adjacent ISPs' RIB.
- When dynamic routing is used between the enterprise and the ISP:
- The RIB size at the enterprise's border routers depends upon the size of the RIB in the DFZ and adjacent ISPs.
- The enterprise's border router can cause BGP churn for the adjacent ISPs, but not in the DFZ.
- The cost of the border router should be less than in today's multi-homing solution. 💜
Appendix C. Incentives and Transition Arguments ✨
Okay so the media has announced the meltdown of the Internet and the run-out of IPv4 addresses like a bajillion times 😭, but the chaos keeps getting pushed back and honestly everyone has tuned out 💀. So maybe we should find other arguments the general public actually cares about, like:
- Not every endpoint needs an upgrade 🎀. Only the ones directly attached to the Internet need it, like portable laptops, smart mobile phones, proxies, and DMZ/frontend endpoints. The most critical stuff, the backend endpoints where enterprises keep their key business apps, doesn't need an upgrade either. Those should not be reachable from the Internet at all, only from the private network, and hIPv4 can get that done because it's backwards compatible with the current IPv4 stack. So the money spent on legacy apps running inside an ALOC realm is preserved 💅.
- Mobility 📱 - apparently demand for apps that perform well over the wireless access network is expected to go up. Bringing in MPTCP and identifier/locator split schemes opens the door to new solutions and apps built for mobility, and that's giving main character energy ✨. The hIPv4 framework needs an upgrade to the endpoint's stack, and if possible, the hIPv4 stack should also include MPTCP and identifier/locator split scheme features. Apps designed for mobility could be a real competitive win 👑.
- The middle routers don't need an immediate upgrade either, since the current forwarding plane can still be used 🌸. That means the gear already sitting at service providers, enterprises, and homes can stay put (middleboxes excepted), so the carbon footprint is way lower than other options 🌍. Plenty of enterprises have green programs, and lots of home users are worried about global warming, so this one really hits 🍃.
- Moving from IPv4 to IPv6 (the currently defined architecture) is gonna bulk up the RIB and FIB across the DFZ 📈. It's unclear whether a new forwarding-plane upgrade, like the one discussed in [RFC4984], will be needed, but most likely yes 🤷. Running IPv4 and IPv6 at the same time means routers need bigger memories for the RIB and FIB, because every globally unique prefix gets installed on the routers taking part in the DFZ. Since each enterprise reserves one or several RIB/FIB entries on every DFZ router, the Internet's power consumption goes up, and so does the carbon footprint 🥀. That's awkward, since so many enterprises are committed to green programs. If hIPv4 gets deployed, the power consumption won't grow as much as it would in an IPv4-to-IPv6 transition scenario 🌈.
- Another issue 👀: if the migration from IPv4 to IPv6 (the currently defined architecture) happens, the routers in the DFZ most likely need to be swapped for more expensive ones, as discussed in [RFC4984]. In the wealthy part of the world, where lots of Internet users already exist, service providers can pass the upgrade costs along to their subscribers more easily. With a "wealthy/high penetration" ratio, the cost won't climb so high that subscribers abandon the Internet. But in the less wealthy part of the world, where there's usually a lower penetration of subscribers, the upgrade cost can't be accepted so easily. A "less wealthy/low penetration" ratio could cause a dramatic cost increase that has to be passed along to subscribers, and so fewer people could afford to get connected at all. For global enterprises and enterprises in the less wealthy part of the world, that could mean fewer potential customers, and there could be situations where the enterprises' nomads can't get connected to the Internet. That's also not fair 😤. Every human being should have a fair chance to enjoy the Internet experience, and the wealthy part of the world should take that right into consideration. Many enterprises are committed to Corporate Social Responsibility programs 🫶.
And it's not just tech and money talk 💜. There are other arguments the general public actually cares about, like the Internet getting greener and more affordable for everyone, which is a pretty different vibe from the current forecast for how the Internet is evolving 🌸.
Appendix D. Integration with CES Architectures 🦋
Because the hIPv4 framework requires changes to the endpoint's stack, it's going to take some time before the move from the current IPv4 architecture to the intermediate hIPv4 routing architecture is fully finished 🐢. If an hIPv4 proxy solution could sit in front of classical IPv4 endpoints, early adopters wouldn't have to wonder so much about whether to jump in, and the migration phase would most likely be way shorter ⚡.
So it should be investigated whether the hIPv4 framework can be integrated with Core-Edge Separation [CES] architectures 🔍. In CES architectures, the endpoints don't need to be modified. The design goal of a CES solution is to minimize the PI-address entries in the DFZ and to keep the current stack at the endpoints intact 💖. But a CES solution needs a new mapping system and also brings in a caching mechanism in the map-and-encapsulate network nodes. There's been a lot of drama about the scalability of the mapping system and the caching mechanism on the [RRG] list 🍿. Right now it's unclear how well both solutions will scale, and research on both topics is still in progress 🧪.
Since CES architectures split the address spaces into two new categories, one installed in the RIB of the DFZ and one installed in the local networks, CES and hIPv4 are somewhat similar to each other 👯. Fun fact: the invention of the IP and locator header swap functionality was inspired by [LISP] 🤯.
To describe how these two architectures might be integrated, we need some terminology definitions first 📖:
CES-node:
- Map-and-encapsulate ingress functionality
- Map-and-encapsulate egress functionality
- Incorporate the hIPv4 stack
- Routing functionality, [RFC1812]
- Being able to apply policy-based routing on the ALOC field in the locator header
The CES-node doesn't include the MPTCP extension, because it would most likely be too much of a burden for the CES-node to signal and maintain MPTCP subflows for the cached hIPv4 entries 🙈.
Consumer site: A site that isn't publishing any services towards the Internet, meaning there are no entries in DNS for this site. Local endpoints use it to establish outbound connectivity, so endpoints start sessions from the site towards content sites 📤. These are usually found at small enterprises and residences, and PA-addresses are usually assigned to them 🏠.
Content site: A site that publishes services towards the Internet and usually does have DNS entries 📣. Local endpoints use it to establish both inbound and outbound connectivity. Large enterprises use PI-addresses, while midsize and small enterprises use either PI- or PA-address space 🏢.
The CES architectures aim to reduce the PI-address entries in the DFZ 🎯. So map-and-encapsulate egress functionality will be installed in front of the content sites. The node with map-and-encapsulate egress functionality will likely also have map-and-encapsulate ingress functionality. It's also a router, so it just needs to support the hIPv4 stack and be able to apply policy-based routing using the ALOC field of the locator header to become a CES-node 🎀.
It's possible that the large content providers (LCPs) won't want to install map-and-encapsulate functionality in front of their sites 😬. If the caching mechanism isn't fully reliable, or if the mapping lookup delay affects their clients' user experience, then the LCPs will most likely skip the CES architecture entirely 🙅.
To convince an LCP to adopt the CES architecture, it should provide a mechanism to mitigate the caching and mapping lookup delay risks 🛡️. One method is to push the CES architectures to the edge. The closer to the edge you add new functionality, the better it scales 📈. So if the endpoint stack is upgraded, the endpoint itself maintains the caching mechanism. The mapping mechanism can be removed if the CES architecture's addressing scheme is replaced with the hIPv4 addressing scheme when the CES solution is integrated at the endpoints ✨. With this approach, LCPs might install a CES-node in front of their sites, and some endpoints at the content site might get upgraded with the hIPv4 stack 💅.
If the LCP runs into trouble with the caching or mapping mechanisms, the provider can ask its clients to upgrade their endpoint's stack to keep a proper service level 🙏. At the same time, the LCP pushes the move from the current routing architecture to a new one. It's not for the sake of the routing architecture itself, but to keep a proper service level. Basically, a business model will drive the migration to a new routing architecture 💼💜.
The hIPv4 framework proposes that IPv4 addresses (ELOC) no longer need to be globally unique. Once the transition is done, a more regional allocation can be deployed 🗺️. But that's only possible once all endpoints establishing sessions to other ALOC realms have migrated to support the hIPv4 framework 🔑. Here the CES architecture can speed up the re-use of IPv4 addresses. Once an IPv4 address block has become an ELOC block, it can be re-used in the other RIR regions, without requiring that every endpoint on the Internet be upgraded first 🌍.
As we said earlier, the CES architecture aims to remove PI-addresses from the DFZ, which makes content sites the main target for rolling out a CES solution 🎯. At large content sites, a CES-node will most likely be installed. Upgrading every endpoint that provides services towards the Internet at a large content site will take time, so those endpoints might only get upgraded within their normal lifecycle process 🔄. But if the content site is small, the administrator either installs a CES-node or upgrades the endpoint's stack. That decision depends on availability, reliability, and economic feasibility 🧾💅.
Okay bestie, once the content sites are upgraded, the PI-address entries are gone from the DFZ 🌸✨ Most likely some endpoints at the consumer sites are upgraded to the hIPv4 stack too, especially if the caches or mapping delays were messing with service levels at the LCPs 😭 So then the big question is how to track which content sites have migrated. If a content site or its endpoints moved over, the DNS records should have a CES-node entry or an ALOC entry for each A-record 🎀 Once CES solutions are popular enough at content sites (with CES-node/ALOC records in DNS to back them up), the ISP can start pushing the hIPv4 stack upgrade on the consumer side 💅
Once a PA-address block has been migrated, it can be released from global allocation to regional allocation 🦋 So why would an ISP push its customers to deploy hIPv4 stacks? Because of the business model, obviously. Staying in the current architecture is going to cost more 💸 IPv4 depletion means either more NAT at the service provider's network (opex goes up because the network gets more complicated) or the ISP has to force its customers over to IPv6. But then the ISP could lose customers to other ISPs still offering IPv4 services 😬
When PA-addresses have moved to the hIPv4 framework, the ISP ends up with a more independent routing domain (ALOC realm) that only has ALOC prefixes from other ISPs and ELOC prefixes from directly attached customers 🧚 BGP churn from other ISPs stops reaching it, there are fewer alternative paths, and the ISP can keep the RIB growth in its ALOC realm under control. Opex and capex should be lower than in the current routing architecture 🤑
So the vibe: content providers might find CES+hIPv4 super attractive 👑 It clears the forthcoming IPv4 address depletion constraints without forcing consumers to switch to IPv6, so content providers can keep growing and reach more consumers 📈
ISPs might also love this because it should cut capex and opex in the long run 💜 Content providers and ISPs both provide the foundation of the Internet, so if both adopt this architecture, consumers kinda have to follow. Both could find business models to "guide" consumers toward the new routing architecture 🫶
Now, how does this affect consumer and content sites? Residential users will need to upgrade their endpoints, but honestly it doesn't really matter which IP version they use. What matters most is that the Internet is available and affordable 🌈
Enterprises get hit a little harder ngl 🙈 The edge devices on enterprise local networks need upgrading: AS border routers, middleboxes, DNS, DHCP, and public nodes. But if you install a CES-node in front of them, the upgrade gets postponed and the legacy nodes can be upgraded during their normal lifecycle process 🍓 Internal infrastructure is preserved, internal applications can still use IPv4, and all that IPv4 skill investment is preserved too 🎀
Walkthrough of use cases:
- A legacy endpoint at a content site establishes a session to a content site with a hIPv4 upgraded endpoint. ✨
When the legacy endpoint resolves the DNS entry for the remote endpoint (a hIPv4 upgraded endpoint), it gets an ALOC record in the DNS response. The legacy endpoint ignores the ALOC record, and only the A-record is used to set up the session. Next, the legacy endpoint initializes the session and a packet is sent toward the map-and-encapsulate ingress node, which has to do a lookup at the CES mapping system (assuming no cache entry exists for the remote endpoint) 💖 The mapping system returns either a CES-node prefix or an ALOC prefix for the lookup. Since the requested remote endpoint has been upgraded, it returns an ALOC prefix 🦋
The CES-node will not use the CES encapsulation scheme for this session. Instead, the hIPv4 header scheme is used and a /32 entry gets created in the cache. A /32 entry must be created, because not all endpoints at the remote site might be upgraded to support the hIPv4 framework 🙈 The /32 cache entry can be replaced with a shorter prefix in the cache if all endpoints at the remote site are upgraded. To signal this, a subfield should be added for the ALOC record in the mapping system 🌸
For egress packets, the CES-node must execute these steps:
- a. Verify IP and transport header checksums.
- b. Create the locator header and copy the value in the destination address field of the IP header to the ELOC field of the locator header.
- c. Replace the destination address in the IP header with the ALOC prefix given in the cache.
- d. Insert the local CES-node prefix in the ALOC field of the locator header.
- e. Copy the transport protocol value of the IP header to the protocol field of the locator header, and set the hIPv4 protocol value in the protocol field of the IP header.
- f. Set the desired parameters in the A-, I-, S-, VLB-, and L-fields of the locator header.
- g. Set the FI-bits of the locator header to
00. - h. Decrease the TTL value by one.
- i. Calculate IP, locator, and transport protocol header checksums. Transport protocol header calculations do not include the locator header fields. When that's done, the packet is transmitted 🔥
- j. Because the packet size might exceed the MTU due to the locator header insertion, and if the MTU is exceeded, the CES-node should inform the source endpoint of the situation with an ICMP message, and the CES-node should apply fragmentation of the hIPv4 packet 💀
- A hIPv4-upgraded endpoint at a consumer/content site establishes a session to a content site with a CES-node in front of a legacy endpoint. 🧚
The hIPv4 upgraded endpoint receives, in the DNS response, either an ALOC record or a CES-node record for the resolved destination. From the requesting hIPv4 endpoint's point of view, it really doesn't matter whether the new record prefix is used to locate RBR-nodes or CES-nodes in the Internet, because the CES-node acts as a hIPv4 proxy in front of the remote legacy endpoint 👑 So the hIPv4 endpoint assembles a hIPv4 packet to initialize the session, and when that packet arrives at the CES-node, the CES-node must execute the following:
- a. Verify that the received packet uses the hIPv4 protocol value in the protocol field of the IP header.
- b. Verify IP, locator, and transport protocol header checksums. Transport protocol header verification does not include the locator header fields.
- c. Replace the protocol field value of the IP header with the protocol field value of the locator header.
- d. Replace the destination address in the IP header with the ELOC prefix of the locator header.
- e. Remove the locator header.
- f. Create a cache entry (unless one already exists) for returning packets. A /32 entry is required. To optimize cache entry usage, the CES-node might ask the CES mapping node whether all endpoints at the remote site are upgraded. If they are, a shorter prefix can be used in the cache 🫶
- g. Decrease the TTL value by one.
- h. Calculate IP and transport protocol header checksums.
- i. Forward the packet according to the destination address of the IP header.
- A hIPv4-enabled endpoint with a regionally unique ELOC at a consumer site establishes a session to a consumer site with a legacy endpoint. 🙈
Here the sessions will fail unless some mechanism is invented and implemented at the ISPs' map-and-encapsulate nodes 😭 The sessions will work inside an ALOC realm, since the classical IPv4 framework is still valid there. Sessions between ALOC realms will fail. Some applications set up sessions between consumer sites, the most common being gaming and peer-to-peer apps. Those communities have historically been at the forefront of adopting new technologies, so it's expected that they either develop workarounds for this issue or simply ask their members to upgrade their stacks 🎮
- A legacy endpoint at a consumer/content site establishes a session to a content site with a CES-node in front of a legacy endpoint. 🌈
Assumed to be described in CES architecture documents 📚
- A hIPv4-enabled endpoint at a consumer/content site establishes a session to a content site with a hIPv4-enabled endpoint. 💜
See Section 5.2. ⭐
Author's Address
Patrick Frejborg EMail: pfrejborg@gmail.com 🦋
📦 where this page comes from
- ietf: rfc6306 2011-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms