diff options
Diffstat (limited to 'doc/rfc/rfc6306.txt')
| -rw-r--r-- | doc/rfc/rfc6306.txt | 3643 |
1 files changed, 3643 insertions, 0 deletions
diff --git a/doc/rfc/rfc6306.txt b/doc/rfc/rfc6306.txt new file mode 100644 index 0000000..6a0ee13 --- /dev/null +++ b/doc/rfc/rfc6306.txt @@ -0,0 +1,3643 @@ + + + + + + +Internet Research Task Force (IRTF) P. Frejborg +Request for Comments: 6306 July 2011 +Category: Experimental +ISSN: 2070-1721 + + + Hierarchical IPv4 Framework + +Abstract + + This document describes a framework for how the current IPv4 address + space can be divided into two new address categories: a core address + space (Area Locators, ALOCs) that is globally unique, and an edge + address space (Endpoint Locators, ELOCs) that is regionally unique. + In the future, the ELOC space will only be significant in a private + network or in a service provider domain. Therefore, a 32x32 bit + addressing scheme and a hierarchical routing architecture are + achieved. The hierarchical IPv4 framework is backwards compatible + with the current IPv4 Internet. + + This document also discusses a method for decoupling the location and + identifier functions -- future applications can make use of the + separation. The framework requires extensions to the existing Domain + Name System (DNS), the existing IPv4 stack of the endpoints, + middleboxes, and routers in the Internet. The framework can be + implemented incrementally for endpoints, DNS, middleboxes, and + routers. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for examination, experimental implementation, and + evaluation. + + This document defines an Experimental Protocol for the Internet + community. This document is a product of the Internet Research Task + Force (IRTF). The IRTF publishes the results of Internet-related + research and development activities. These results might not be + suitable for deployment. This RFC represents the individual + opinion(s) of one or more members of the Routing Research Group of + the Internet Research Task Force (IRTF). Documents approved for + publication by the IRSG are not a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6306. + + + + +Frejborg Experimental [Page 1] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + +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 + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Frejborg Experimental [Page 2] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + +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 ....................58 + + + + + + + + + + + + + +Frejborg Experimental [Page 3] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + +1. Introduction + + A Locator/Identifier Separation Protocol [LISP] presentation from a + breakout session at an expo held in January, 2008, triggered a + research study; findings from the study are described in this + document. Further studies revealed that the routing community at + IETF is concerned about the scalability of the routing and addressing + system of the future Internet. The Internet Architecture Board (IAB) + held a Routing and Addressing workshop on October 18-19, 2006, in + Amsterdam. The outcome from the workshop is documented in [RFC4984]. + Also, the IRTF had established a Routing Research Group [RRG] in 2007 + and created some design guidelines; see [RFC6227]. + + The author of this document found the LISP approach very interesting + because the IP address space is proposed to be separated into two + groups: Routing Locators (RLOCs), which are present in the global + routing table of the Internet called the Default-Free Zone (DFZ), and + Endpoint Identifiers (EIDs), which are only present in edge networks + attached to the Internet. + + The proposed LISP architecture reduces the routing information in the + DFZ, but it also introduces a new mapping system that would require a + caching solution at the border routers installed between the edge + networks and DFZ. EID prefixes are not needed in the DFZ since a + tunneling (overlay) scheme is applied between the border routers. To + the author, this seems to be a complex architecture that could be + improved by applying lessons learned from similar past architectures + -- in the '90s, overlay architectures were common, deployed on top of + Frame Relay and ATM technologies. Cache-based routing architectures + have also been tried, for example, Ipsilon's IP Switching. These + architectures have largely been replaced by MPLS [RFC3031] for + several reasons -- one being that overlay and caching solutions have + historically suffered from scalability issues. Technology has + certainly evolved since the '90s. The scalability issues of overlay + and caching solutions may prove to be less relevant for modern + hardware and new methods; see [Revisiting_Route_Caching] + + Nevertheless, the author has some doubt whether overlay and caching + will scale well, based upon lessons learned from past overlay and + caching architectures. The hierarchical IPv4 framework proposal + arose from the question of whether the edge and core IP addressing + groupings from LISP could be used without creating an overlay + solution by borrowing ideas from MPLS to develop a peer-to-peer + architecture. That is, 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 and Realm Border Router + (RBR) functionality on the network, the edge locators are no longer + needed in the routing table of DFZ. + + + +Frejborg Experimental [Page 4] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + Two architectural options existed regarding how to assemble the + packet so that RBR functionality can be applied in the DFZ: the + packet was assembled by either an ingress network node (similar to + LISP or MPLS) or at the endpoint itself. The major drawback in + assembling the packet with a shim header at the endpoint is that the + endpoint's stack must be upgraded; however, a significant advantage + is that the Path MTU Discovery issue, as discussed in, e.g., LISP, + would not exist. In addition, 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 new dimension. In an MPLS network, + overlapping IP addresses are allowed since the forwarding plane is + leveraging 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, although the core + locators must still be globally unique. The location of an endpoint + is also no longer described by a single address space; it is + 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 close to the abbreviation of Host Identity Protocol (HIP) + [RFC4423]. Thus, the reader needs to pay attention to the use of the + two abbreviations -- hIPv4 and HIP, which represent two different + architectures. + + Use of the hIPv4 abbreviation has caused much confusion, but it was + chosen for two reasons: + + o 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. The author believes that + this claim is not valid -- today's Internet uses one flat address + space. + + + +Frejborg Experimental [Page 5] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + 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. + + Thus, 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, independent from 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 describing 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. + + o IPv4 - to emphasize that the framework is still based upon the IPv4 + addressing scheme, and is only an evolution from the currently + deployed addressing scheme of the Internet. + + While performing 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 to + a standard RFC, it is recommended that the hierarchical IPv4 + framework name be replaced with Extended Internet Protocol, EIP, + since both architectures share similarities, e.g., backwards + compatibility with existing deployed architecture, hierarchical + addressing, etc., and the hIPv4 abbreviation can be mixed up with + HIP. + + This document is an individual contribution to the IRTF Routing + Research Group (RRG); discussions between those on the mailing list + of the group 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. Since consensus was not achieved at RGG + regarding which proposal should be preferred -- as stated in + + + +Frejborg Experimental [Page 6] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + [RFC6115]: "The group explored a number of proposed solutions but did + not reach consensus on a single best approach" -- thus, 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 + + This document 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. + + + + + +Frejborg Experimental [Page 7] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + 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. + + + + + + + + + +Frejborg Experimental [Page 8] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + 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 + + + +Frejborg Experimental [Page 9] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + 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 + + + +Frejborg Experimental [Page 10] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + 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). + +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 + + As mentioned in previous sections, the role of an Area Locator (ALOC) + prefix is similar to a country code in PSTN; the ALOC prefix provides + a location functionality of an area within an autonomous system (AS), + or an area spanning over a group of ASes, in the Internet. An area + can have several ALOC prefixes assigned, e.g., for traffic + engineering purposes such as load balancing among several + ingress/egress points at the area. The ALOC prefix is used for + routing and forwarding purposes on the Internet, and so the ALOC + prefix must be globally unique and is allocated from an IPv4 address + block. This globally unique IPv4 address block is called the Global + Locator Block (GLB). + + When an area within an AS (or a group of ASes) is assigned an ALOC + prefix, the area has the potential to become an ALOC realm. In order + to establish an ALOC realm, more elements, more than just the ALOC + prefix, are needed. One or multiple Realm Border Routers (RBRs) must + be attached to the ALOC realm. An RBR element is a node capable of + swapping the prefixes of the IP header and the new shim header, + called the locator header. The swap service is described in detail + in Section 5.2, step 3. + + + + + +Frejborg Experimental [Page 11] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + Today's routers do not support this RBR functionality. Therefore, + the new functionality will most likely be developed on an external + device attached to a router belonging to the ALOC realm. The + external RBR might be a server with two interfaces attached to a + router, the first interface configured with the prefix of the ALOC + and the second with any IPv4 prefix. The RBRs do not make use of + dynamic routing protocols, so neither a Forwarding Information Base + (FIB) nor a cache is needed -- the RBR performs a service, swapping + headers. + + The swap service is applied on a per-packet basis, and the + information needed to carry out the swap is included in the locator + header of the hIPv4 packet. Thus, a standalone device with + sufficient computing and I/O resources to handle the incoming traffic + can take the role as an RBR. Later on, the RBR functionality might + be integrated into the forwarding plane of a router. It is expected + that one RBR will not be able to handle all the incoming traffic + designated for an ALOC realm and that having a single RBR would also + create a potential single point of failure in the network. + Therefore, several RBRs might be installed in the ALOC realm and 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. The placement of the RBRs in the network will influence + the ingress traffic to the ALOC realm. + + Since the forwarding paradigm of multicast packets is quite different + from forwarding unicast packets, the multicast functionality will + have an impact on the RBR. Because the multicast RBR (mRBR) + functionality is not available on today's routers, an external device + is needed -- later on the functionality might be integrated into the + routers. 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 neither a FIB nor a cache is required. As with the RBR, + the multicast hIPv4 packets are carrying all needed information in + their headers in order to apply the swap service; for details, see + Section 10.5. + + The ALOC realm is not yet fully constructed. We can now locate the + ALOC realm on the Internet, but to locate the endpoints attached to + the ALOC realm, a new element is needed: the Endpoint Locator (ELOC). + As mentioned in the previous section, the ELOC prefixes can be + considered similar to the subscriber numbers in PSTN. The ELOC is + not a new element but a redefinition of the current IPv4 address + configured at an endpoint. The term redefinition is applied because + when the hIPv4 framework is fully implemented, the global uniqueness + of the IPv4 addresses is no longer valid. A more regional address + + + +Frejborg Experimental [Page 12] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + allocation policy of IPv4 addresses can be deployed, as discussed in + Appendix A. The ELOC prefix will only be used for routing and + forwarding purposes inside the local and remote ALOC realms, and it + is not used in the intermediate ALOC realms. + + When an initiator is establishing a session to a responder residing + outside the local ALOC realm, the value in 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 is + installed in the destination address field of the IP header. Because + the value in the destination address field of the IP header is + carrying an ALOC prefix, the intermediate ALOC realms do not need to + install the ELOC prefixes of other ALOC realms in their routing + tables. It is sufficient for the intermediate ALOC realms to carry + only the ALOC prefixes. + + The outcome is that the routing tables at each ALOC realm will be + reduced when the hIPV4 framework is fully implemented. The ALOC + prefixes are still globally unique and must be installed in the DFZ. + Thus, the service provider cannot control the growth of the ALOC + prefixes, but she/he can control the amount of local ELOC prefixes in + her/his local ALOC realm. + + When the hIPv4 packet arrives at the remote ALOC realm, it is + forwarded to the nearest RBR, since the value in the destination + address field of the IP header is the remote ALOC prefix. When the + RBR has swapped the hIPv4 header, the value in the destination + address field of the IP header is the remote ELOC; thus, the hIPv4 + packet will be forwarded to the final destination at the remote ALOC + realm. An endpoint using an ELOC prefix can be attached + simultaneously to two different ALOC realms without the requirement + to deploy a classical multi-homing solution; for details, see Section + 12 and Appendix B. + + Understanding that the addressing structure is no longer + unidimensional and that a second level of hierarchy has been added, + it is important to solve the problems of locating the remote ELOC + (endpoint) and remote ALOC realm on the Internet, as well as + determining where to assemble the header of the hIPv4 packet. The + hierarchical IPv4 framework relies upon the Domain Name System needs + to support a new record type so that the ALOC information can be + distributed to the endpoints. To construct the header of the hIPv4 + packet, either the endpoint or an intermediate node (e.g., a proxy) + should be used. A proxy solution is likely to prove suboptimal due + to a complication induced by the proxy's need to listen to DNS + messages, and a cache solution has scalability issues. + + + + + +Frejborg Experimental [Page 13] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + A better solution is to extend the current IPv4 stack at the + endpoints so that the ALOC and ELOC elements are incorporated at the + endpoint's stack; however, backwards compatibility must be preserved. + Most applications will not be aware of the extensions while other IP- + aware applications, such as Mobile IP, SIP, IPsec AH and so on (see + Section 10.3) will suffer and cannot be used outside their ALOC realm + when the hIPv4 framework is fully implemented, unless they are + upgraded. The reason is that the IP-aware applications depend upon + the underlying network addressing structure, e.g., to identify an + endpoint. + + Note that the applications used inside the local ALOC realm (e.g., + enterprise's private network) do not need to be upgraded -- neither + in the intermediate nor in the long-term routing architecture. The + classical IPv4 framework is preserved in that 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. When this architecture is in place, the ELOC space is + no longer globally unique. Instead, a regional allocation policy can + be implemented. For further details, see Appendix A. The transition + from the current routing architecture to the intermediate routing + architecture is discussed in Appendix D. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Frejborg Experimental [Page 14] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + 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 hIPv4 + +5.2. Life of a hIPv4 Session + + This section provides an example of a hIPv4 session between two hIPv4 + endpoints: an initiator and a responder residing in different ALOC + realms. + + When the hIPv4 stack is assembling the packet for transport, the + hIPv4 stack shall decide if a classical IPv4 or a hIPv4 header is + used based on the ALOC information received by a DNS reply. If the + initiator's local ALOC prefix equals the responder's ALOC prefix, + there is no need to use the hIPv4 header for routing purposes, + because both the initiator and responder reside in the local ALOC + realm. The packet is routed according to the prefixes in the IP + header since the packet will not exit the local ALOC realm. When the + local ALOC prefix does not match the remote ALOC prefix, a hIPv4 + header must be assembled because the packet needs to be routed to a + remote ALOC realm. + + + + + + +Frejborg Experimental [Page 15] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + A session between two endpoints inside an ALOC realm might use the + locator header -- not for routing purposes, but 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 making use of VLB, the initiator + adds the locator header to the packet and by setting the VLB-bits to + 01 or 11, indicating to the responder and intermediate routers that + VLB is requested for the subflow. Because this is an intra-ALOC + realm session, there is no need to add ALOC and ELOC fields to the + locator header, and thus the size of the locator header will be 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. Identifier/locator + split scheme information is inserted into the locator header after + the Locator Header Length field. + + How a hIPv4 session is established follows: + + 1. The initiator queries the DNS server. The hIPv4 stack notices + that the local and remote ALOCs do not match and therefore must + use the hIPv4 header for the session. The hIPv4 stack of the + initiator must assemble the packet by the following method: + + 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. + + + + + + +Frejborg Experimental [Page 16] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + h. Calculate IP, locator, and transport protocol header checksums. + The transport protocol header calculation does not include the + locator header fields. When completed, the packet is + transmitted. + + 2. The hIPv4 packet is routed throughout the Internet based on the + value in the destination address field of the IP header. + + 3. The hIPv4 packet will reach 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. + + 4. 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 to the final destination. + + + + + +Frejborg Experimental [Page 17] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + 5. 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. + + 6. 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 will respond to the initiator and the + returning packet will take almost the same steps, which are steps 1 + to 6, as when the initiator started the session. In step 1, the + responder does not need to do a DNS lookup since all information is + provided by the packet. + +6. Long-Term Routing Architecture + + The long-term routing architecture is 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. Why then would + private network or service provider administrators upgrade their + infrastructure? There are two incentives: + + o 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. + + o 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. + + + + +Frejborg Experimental [Page 18] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + 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 + + The swap service at the RBR was added to the framework in order to + provide a smooth transition from the current IPv4 framework to the + hIPv4 framework; a major upgrade of the current forwarding plane is + avoided by the introduction of the swap service. In the future, the + swap service can be left "as is" in the ALOC realm, if preferred, or + the swap service can be pushed towards the edge of the ALOC realm + when routers are upgraded in their natural lifecycle process. + + Once an upgrade of a router is required because of, for example, + increased demand for bandwidth, the modified forwarding plane might + concurrently support IPv4 and hIPv4 forwarding -- and the swap + service can be pushed towards the edge and in the future removed at + the ALOC realm. This is accomplished by adding an extension to the + current routing protocols, both IGP and BGP. When an RBR receives a + hIPv4 packet where the value of 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 this prefix against the FIB. If the + next-hop entry is RBR-capable, the packet will be forwarded according + to the ELOC prefix. If the next-hop is a classical IPv4 router, the + RBR must apply the tasks defined in Section 5.2, step 3 and, once + completed, forward the packet according to the new value in the + destination address field of the IP header. + + When all endpoints (that need to establish sessions outside the local + ALOC realm) and infrastructure nodes in an ALOC realm are hIPv4- + capable, there is no need to apply swap service for unicast sessions. + Forwarding decisions can be based on information in the IP and + locator headers. In the local ALOC realm, packets are routed to + their upstream anycast or unicast ALOC RBR according to the ALOC + prefix in the locator header; local ALOC exit routing is applied + against the local ALOC FIB. Remote ELOC approach routing is applied + against the ELOC FIB in the remote ALOC realm. + + Note that IP and transport protocol headers will remain intact + (except for TTL values, since the RBR is a router); only FI and LH + checksum values in the locator header will alternate in local ALOC + exit routing mode and remote ELOC approach routing mode. + + + + + + +Frejborg Experimental [Page 19] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + Figure 2 shows a conceptual overview of the long-term hIPv4 routing + architecture. + + Legend: *attachment point in the ALOC realm + UER=Unique ELOC region + EP=Endpoint + aRBR=anycast RBR + uRBR=unicast RBR + + |-------------------------------------------------------------| + | 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 + + Also, the swap service for multicast can be removed when the + forwarding planes are upgraded in all consequent ALOC realms. The + source's ALOC RBR sets the FI-bits to 11, and a Reverse Path + Forwarding (RPF) check is hereafter applied against the ALOC prefix + in the locator header. Here, IP and transport protocol headers will + not alternate. + + A long-term evolution will provide a 32x32 bit locator space. The + ALOC prefixes are allocated only to service providers; ELOC prefixes + are only significant at a local ALOC realm. An enterprise can use a + 32-bit locator space for its private network (the ALOC prefix is + + + + +Frejborg Experimental [Page 20] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + 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 provides an example of a hIPv4 session between two hIPv4 + endpoints: an initiator in an ALOC realm where the forwarding plane + has been upgraded to support the hIPv4 framework, and a responder + residing in a remote ALOC realm with the classical IPv4 forwarding + plane. + + When the forwarding plane at the local ALOC realm has been upgraded, + the endpoints must be informed about it; that is, extensions to DHCP + are needed or the endpoints are manually configured to be notified + that the local ALOC realm is fully hIPv4 compliant. + + How a hIPV4 session is established follows: + + 1. The initiator queries the DNS server. The hIPv4 stack notices + that the local and remote ALOCs do not match and therefore 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-bits of the locator header to 01. + + 2. The hIPv4 packet is routed throughout the local ALOC realm + according to the ALOC prefix of the locator header; local ALOC + exit routing is applied. + + 3. 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-bits are + set to 01, 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-bits of the locator header to 00. + + d. Decrease the TTL value by one. + + e. Calculate IP and locator header checksums. + + + + + +Frejborg Experimental [Page 21] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + f. Forward the packet according to the value in the destination + address field of the IP header. + + 4. The hIPv4 packet is routed to the responder as described in + Section 5.2, steps 2 to 6. DFZ routing is applied. + + 5. 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: + + 6. 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-bits are set to 00, 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-bits of the locator header to 10. + + 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. + + 7. The hIPv4 packet is routed throughout the initiator's ALOC realm + according to the ELOC prefix of the locator header. Remote ELOC + approach routing is applied. + + 8. 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. + + + + + + +Frejborg Experimental [Page 22] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + +7. Decoupling Location and Identification + + The design guidelines and rationale behind decoupling the location + from identification are stated in [RFC6227]. Another important + influence source is the report and presentations from the [Dagstuhl] + workshop that declared "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". + + Therefore, identifier elements need to be added to the hIPv4 + framework to provide a path for future applications to be able to + remove the current dependency on the underlying network layer + addressing scheme (local and remote IP address tuple). + + However, there are various ways to apply an identifier/locator split, + as discussed in an [ID/loc_Split] presentation from the MobiArch + workshop at Sigcomm 2008. Thus, the hIPv4 framework will not propose + or define a single identifier/locator split solution; a split can be + achieved by, for example, a multipath transport protocol or by an + identifier/locator database scheme such as HIP. A placeholder has + been added to the locator header so identifier/locator split schemes + can be integrated into the hIPv4 framework. But identifier/locator + split schemes may cause privacy inconveniences, as discussed in + [Mobility_&_Privacy]. + + Multipath transport protocols, such as SCTP and the currently under + development Multipath TCP (MPTCP) [RFC6182], are the most interesting + candidates to enable an identifier/locator split for the hIPv4 + framework. MPTCP is especially interesting from hIPv4's point of + view; one of the main goals of MPTCP is to provide backwards + compatibility with current implementations: hIPv4 shares the same + goal. + + MPTCP itself does not provide an identifier/locator database scheme + as HIP does. Instead, MPTCP is proposing a token -- with local + meaning -- to manage and bundle subflows under one session between + two endpoints. The token can be considered to have the + characteristics of a session identifier, providing a generic cookie + mechanism for the application layer and creating a session layer + between the application and transport layers. Thus, the use of a + session identifier will provide a mechanism to improve mobility, both + in site and endpoint mobility scenarios. + + Since the session identifier improves site and endpoint mobility, + routing scalability is improved by introducing a hierarchical + addressing scheme, why then add an identifier/locator database scheme + to the hIPv4 framework? Introducing an identifier/locator database + + + +Frejborg Experimental [Page 23] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + scheme, as described in HIP, Identifier/Locator Network Protocol + [ILNP] and Name-Based Sockets [NBS], might ease or remove the locator + renumbering dependencies at firewalls that are used to scope security + zones, but this approach would fundamentally change the currently + deployed security architecture. + + However, combining an identifier/locator database scheme with DNS + Security (DNSSEC) [RFC4033] is interesting. Today, security zones + are scoped by using locator prefixes in the security rule sets. + Instead, a Fully Qualified Domain Name (FQDN) could be used in the + rule sets and the renumbering of locator prefixes would no longer + depend upon the security rule sets in firewalls. Another interesting + aspect is that 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. Nevertheless, + combining identifier/locator database schemes with security + architectures and DNSSEC needs further study. + + In order to provide multi-homing and mobility capabilities for single + path transport protocols such as TCP and UDP, an identifier/locator + database scheme is needed. This scheme can also be used to create a + bidirectional NAT traversal solution with a locator translation map + consisting of private locator prefixes and public identifiers at the + border router. + + The hIPv4 routing architecture provides only location information for + the endpoints; that is, 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 -- the + application layer may or may not make use of an identifier/locator + split scheme. + +8. ALOC Use Cases + + Several ALOC use cases are explored in this section. As mentioned in + Section 5.1, ALOC describes an area in the Internet that can span + several autonomous systems (ASes), or if the area is equal to an AS + you can say that the ALOC describes an AS. When the ALOC describes + an area, it is hereafter called an anycast ALOC. + + The ALOC can also be used to describe a specific node between two + ALOC realms, e.g., a node installed between a private and an ISP ALOC + realm, or between two private ALOC realms. In this use case the ALOC + describes an attachment point, e.g., where a private network is + attached to the Internet. This ALOC type is hereafter called a + unicast ALOC. + + + + +Frejborg Experimental [Page 24] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + The main difference between anycast and unicast ALOC types is: + + o In an anycast ALOC scenario, ELOC routing information is shared + between the attached ALOC realms. + + o In a unicast ALOC scenario, no ELOC routing information is shared + between the attached ALOC realms. + + Unicast ALOC functionalities should not be deployed between private + and ISP ALOC realms in the intermediate routing architecture -- it + would require too many locators from the GLB space. Instead, unicast + ALOC functionality will be used to separate private ALOC realms. + + ALOC space is divided into two types, a globally unique ALOC space + (a.k.a. GLB) that is installed in DFZ, and a private ALOC space that + is used inside private networks. Private ALOCs use the same locator + space as defined in [RFC1918]; a private ALOC must be unique inside + the private network and not overlap private ELOC prefixes. Only ISPs + should be allowed to apply for global ALOC prefixes. For further + discussion, see Appendix A. The ISP should aggregate global ALOC + prefixes as much as possible in order to reduce the size of the + routing table in DFZ. + + When a user logs on to the enterprise's network, the endpoint will + receive the following locator prefixes via provisioning means (e.g., + DHCP or manually configured): + + o One ELOC prefix for each network interface. + + o One private ALOC prefix due to + + - The enterprise has recently been merged with another enterprise + and overlapping ELOC spaces exist. + + o Several private ALOC prefixes due to + + - 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. + + o One or several global ALOC prefixes. These ALOCs describe how the + enterprise network is attached to the Internet. + + As the user establishes a session to a remote endpoint, DNS is + usually used to resolve remote locator prefixes. DNS will return + ELOC and ALOC prefixes of the remote endpoint. If no ALOC prefixes + are returned, a classical IPv4 session is initiated to the remote + + + +Frejborg Experimental [Page 25] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + endpoint. When ALOC prefixes are returned, the initiator compares + the ALOC prefixes with its own local ALOC prefixes (that are provided + via DHCP or manually configured). + + o 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 to design a network to use private ALOC + functionality. The remote endpoint is far away, leveraging high- + speed long-distance connections, and in order to improve performance + for the session a multipath transport protocol should be used. + + The other use case is when the remote endpoint resides in a network + that recently has been merged and private ELOC [RFC1918] spaces + overlap if no renumbering is applied. 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 returned ALOC + prefixes from DNS with its own local ALOC prefixes: + + o 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 resides outside the enterprise's + private network, and the global remote ALOC prefixes indicate 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 -- both at 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, routed to an explicit path (e.g., MPLS LSP, L2TPv3 tunnel, + etc.) based on the ALOC prefix in the locator header. A local ALOC + overlay exit routing scheme can be designed. 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 having a + multipath session over a VPN connection and over the Internet (in the + intermediate routing architecture). + + + + + + + + + +Frejborg Experimental [Page 26] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + 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 Internet + + The first subflow is established from the initiator (EP1) via uRBR3 + and uRBR4 (both use a private unicast ALOC prefix) to the responder + (EP2). Normal unicast forwarding is applied; ALOC prefixes of uRBR3 + and uRBR4 are installed in the routing tables of both the local and + remote ALOC realms. A second subflow is established via the + Internet, that is, via BR1->BR2 to EP2. 0/0 exit routing is used to + enter the Internet at both ALOC realms. + + + +Frejborg Experimental [Page 27] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + Note that ELOC prefixes can overlap since the local and remote ALOC + realms reside in different ELOC regions and are separated by private + unicast ALOC prefixes. + + The fourth use case is to leverage the private and global ALOC + functionalities to be aligned 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 upon the service offer + and network design of the ISP. If the ISP prefers to offer advanced + support for multipath transport protocols and local ALOC exit + routing, the residential user is provided with several ALOC prefixes. + The ALOC provided for residential users is taken from the GLB space + and anycast ALOC functionality is applied. + +9. Mandatory Extensions + +9.1. Overview + + To implement the hierarchical IPv4 framework, some basic rules are + needed: + + 1. The DNS architecture must support a new extension; an A type + Resource Record should be able to associate ALOC prefixes. + + 2. 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. + + 3. 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. + + 4. 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. + + 5. 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 to appropriate routing + protocols in order to be distributed to the DFZ. + + 6. 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 + + + +Frejborg Experimental [Page 28] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + 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 + + Since the hierarchical IPv4 framework introduces an extended + addressing scheme and because DNS serves as the "phone book" for the + Internet, it is obvious that DNS needs a new Resource Record (RR) + type to serve endpoints that are upgraded to support hIPv4. Future + RR types must follow the guidelines described in [RFC3597] and + [RFC5395] with the following characteristics: + + o Associated with the appropriate Fully Qualified Domain Name + (FQDN), inserted in the NAME field. + + o Assigned a new integer (QTYPE) in the TYPE field, to be assigned + by IANA. + + o The CLASS field is set to IN. + + o The RDATA field is of an unknown type as defined in [RFC3597] and + shall have the following format: + + o 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. + + o ALOC subfield: A 32-bit integer that specifies the Area Locator + of the associated FQDN. + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | Preference | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | | + | ALOC | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + Figure 4: RDATA format of the ALOC RR + + Only endpoints that have been upgraded to support hIPv4 shall make + use of the new ALOC RR. Also, there is no need to define a new ELOC + RR because the A RR is used for that purpose when the ALOC RR is + returned. + + + + + +Frejborg Experimental [Page 29] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + +9.3. Extensions to the IPv4 Header + + Figure 5 shows how the locator header is added to the current IPv4 + header, creating a hIPv4 header. + + 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 header + + Version: 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. + + + + + +Frejborg Experimental [Page 30] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + 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. + + + + + + +Frejborg Experimental [Page 31] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + 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. + + + + + + + +Frejborg Experimental [Page 32] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + 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. + + + +Frejborg Experimental [Page 33] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + 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 + + Because an ELOC prefix is only significant within the local ALOC + realm, there is a slight possibility that a session between two + endpoints residing in separate ALOC realms might use the same local + and remote ELOC prefixes. But the session is still unique because + the two processes communicating over the transport protocol form a + logical session that is uniquely identifiable by the 5-tuple + involved, by the combination of <protocol, local IP address, local + port, remote IP address, remote port>. + + The session might no longer be unique when two initiators with the + same local ELOC prefix residing in two separate ALOC realms are + accessing a responder located in a third ALOC realm. In this + scenario, the possibility exists that the initiators will use the + same local port value. This situation will cause an "identical + session situation" for the application layer. + + To overcome this scenario, the hIPv4 stack must accept only one + unique session with the help of the ALOC information. If there is an + "identical session situation", i.e., both initiators use the same + values in the 5-tuple <protocol, local IP address, local port, remote + IP address, remote port>, the hIPv4 stack shall allow only the first + + + +Frejborg Experimental [Page 34] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + established session to continue. The following sessions must be + prohibited and the initiator is informed by ICMP notification about + the "identical session situation". + + MPTCP introduces a token that is locally significant and currently + defined as 32 bits long. The token will provide a sixth tuple for + future applications to identify and verify the uniqueness of a + session. Thus, the probability to have an "identical session + situation" is further reduced. By adding an identifier/locator + database scheme to the hIPv4 framework, the "identical session + situation" is completely removed. + +10.2. Large Encapsulated Packets + + Adding the locator header to an IPv4 packet in order to create a + hIPv4 packet will increase the size of it, but since the packet is + assembled at the endpoint it will not add complications of the + current Path MTU Discovery (PMTUD) mechanism in the network. The + intermediate network between two endpoints will not see any + difference in the size of packets; IPv4 and hIPv4 packet sizes are + the same from the network point of view. + +10.3. Affected Applications + + There are several applications that insert IP address information to + the payload of a packet. Some applications use the IP address + information to create new sessions or for identification purposes. + Some applications collect IP address information to be used as + referrals. This section tries to list the applications that need to + be enhanced; however, this is by no means a comprehensive list. The + applications can be divided into five main categories: + + o Applications based on raw sockets - a raw socket receives packets + containing the complete header, in contrast to the other sockets + that only receive the payload. + + o Applications needed to enable the hIPv4 framework, such as DNS and + DHCP databases, which must be extended to support ALOC prefixes. + + o 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 belonging to 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: + + + + + +Frejborg Experimental [Page 35] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + - SIP: IP addresses are inserted in the SDP offers/answers, XML + body, Contact, Via, maddr, Route, Record-Route SIP 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. + + o Applications related to security, such as firewalls, must be + enhanced to support ALOC prefixes. + + o Applications that will function with FQDN, 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 that a lot of applications need to be re- + engineered and ported, but the situation is not all that bad. The + 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 the + migration of applications from IPv4 to IPv6 can impose some capital + expenditures for enterprises, especially if the applications are + customized or homegrown; see [Porting_IPv4]. + + As stated earlier, hIPv4 does not require to port applications used + inside a private network. The conclusion is that, whatever next + generation architecture is deployed, some applications will suffer, + either during the transition period or when being re-engineered in + order to be compatible with the new architecture. + + + + +Frejborg Experimental [Page 36] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + +10.4. ICMP + + As long as the 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 is a constraint with Reverse Path + Forwarding (RPF) that is used to ensure loop-free forwarding of + multicast packets. The source address of a multicast group (S,G) is + used against the RPF check. The address of the source can no longer + be used as a RPF checkpoint outside the local ALOC realm. + + 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 acts + also 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. + + + + + +Frejborg Experimental [Page 37] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + In order 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. In order for the receiver to + create Real-time Transport Control Protocol (RTCP) receiver reports, + all information 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 the placement of RBRs at the realm; 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 is not fully distributed into the DFZ. + + + + + + +Frejborg Experimental [Page 38] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + 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 is 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 the 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 + + The use of multipath-enabled transport protocols opens up the + possibility to develop a new design methodology of backbone networks, + based on Valiant Load-Balancing [VLB]. If two sites that are + connected with a single uplink to the Internet, and the endpoints are + using multipath-enabled transport protocols and are attached to the + network with only one interface/ELOC-prefix, both subflows will most + likely take the shortest path throughout the Internet. That is, both + subflows are established over the same links and when there is + congestion on a link or a failure of a link, both subflows might + simultaneously drop packets. Thus, the benefit of multi-pathing is + lost. + + The "subflows-over-same-links" scenario can be avoided if the + subflows are traffic engineered to traverse the Internet on different + paths, but this is difficult to achieve by using classical traffic + engineering, such as IGP tuning or MPLS-based traffic engineering. + By adding a mechanism to the locator header, the "subflows-over-same- + links" scenario might be avoided. + + + +Frejborg Experimental [Page 39] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + 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. That is, + 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 is + an intra-ALOC realm subflow belonging to a multipath-enabled session. + + With this combination of parameters in the locator header, the + subflow is VLB switched only at the first ALOC realm and the subflows + might be routed throughout the Internet on different paths. If VLB + switching is applied at every ALOC realm, this would most likely add + too much latency for the subflows. The VLB switching at the first + ALOC realm will not separate the subflows on the first and last mile + links (site with a single uplink). 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 is influencing traffic patterns between + interconnected VLB [iVLB] backbone networks have been done. + Nevertheless, more studies are needed regarding Valiant Load- + Balancing scenarios. + +12. Mobility Considerations + + This section considers two types of mobility solutions: site mobility + and endpoint mobility. + + Site mobility: + + Today, classical multi-homing is the most common solution for + enterprises that wish to achieve site mobility. 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 provide a solution + for enterprises to have site mobility without the requirement of + implementing a classical multi-homed solution. + + One of the reasons to deploy multi-homing is to avoid renumbering of + the local infrastructure when an upstream ISP is replaced. Thus, + today, PI-address blocks are deployed at enterprises. In the + intermediate routing architecture, an enterprise is allocated a + regional PI ELOC block (for details, see Appendix A) that is used for + internal routing. The upstream ISP provides an ALOC prefix that + + + +Frejborg Experimental [Page 40] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + describes how the enterprise's network is connected to the Internet. + If the enterprise wishes to switch to another ISP, it only changes + the ALOC prefix at endpoints, from the previous ISP's ALOC prefix to + the new ISP's ALOC prefix, without connectivity interruptions in the + local network since the ALOC prefix is only used for Internet + connectivity -- several ALOCs can be used simultaneously at the + endpoints; thus, a smooth migration from one ISP to another is + possible. In the long-term routing architecture, when the forwarding + plane is upgraded, the regional PI ELOC block is returned to the RIR + and the enterprise can use a full 32-bit ELOC space to design the + 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 said earlier, MPTCP is the most interesting identifier/locator + split scheme to solve endpoint mobility scenarios. MPTCP introduces + a token, which is locally significant and currently defined as 32 + bits long. The token will provide a sixth tuple to identify and + verify the uniqueness of a session. This sixth tuple -- the token -- + does not depend upon the underlying layer, the IP layer. The session + is identified with the help of the token and thus the application is + not aware when the locator parameters are changed, e.g., during a + roaming situation, but it is required that the application is not + making use of ELOC/ALOC information. In multi-homed scenarios, the + application can make use of ELOC information, which will not change + if the endpoint is fixed to the 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 + requires 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 that the + responder resides in the fixed network and the initiator is mobile. + Thus, MPTCP will provide roaming capabilities for the mobile + endpoint, if both endpoints are making use of the MPTCP extension. + However, in some use cases, the fixed endpoint needs to initialize a + session to a mobile responder. Therefore, Mobile IP (MIP) [RFC5944] + should incorporate the hIPv4 extension -- MIP provides a rendezvous + service for the mobile endpoints. + + + + +Frejborg Experimental [Page 41] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + Also, many applications provide rendezvous services for their users, + e.g., SIP, peer-to-peer, Instant Messaging services. A generic + rendezvous service solution can be provided by an identifier/locator + database scheme, e.g., HIP, ILNP, or NBS. If desired, the user + (actually the application) can make use of 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 will not define which identifier/locator split + solution should be used for endpoint mobility. The hIPv4 framework + is focusing 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 is not introducing any new protocols that would + be mandatory for the transition from IPv4 to hIPv4; instead, + extensions are added to existing protocols. The hIPv4 framework + requires 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 remains 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 make use of 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 present. + + When will the unidimensional addressing structure be replaced by a + hierarchical addressing scheme and a fourth hierarchy added to the + routing architecture? The author thinks there are two possible + tipping points: + + o When the RIB of DFZ is getting 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? + + o When the depletion of IPv4 addresses is causing enough problems + for service providers and enterprises. + + The biggest risk and reason why the hIPv4 framework will not succeed + is the very short time frame until the expected depletion of the IPv4 + address space occurs -- actually the first RIR has run out of IPv4 + + + +Frejborg Experimental [Page 42] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + addresses during the IESG review process of this document (April + 2011). Also, will enterprises give up their global allocation of the + current IPv4 address block they have gained, as an IPv4 address block + has become an asset with an economical value. + + The transition requires the upgrade of endpoint's stack, and this is + a drawback compared to the [CES] architectures proposed in [RFC6115]. + A transition to an architecture that requires the upgrade of + endpoint's stack is considerably slower than an architecture that + requires only upgrade of some network nodes. But the transition + might not be as slow or challenging at it first seems since hIPv4 is + an evolution of the current deployed Internet. + + o Not all endpoints need to be upgraded; the endpoints that do not + establish sessions to other ALOC realms can continue to make use + of the classical IPv4 framework. Also, legacy applications that + are used only inside a local ALOC realm do not need to be ported + to another framework. For further details, see Appendix C. + + o Upgrading endpoint's stack, e.g., at critical or complicated + systems, will definitely take time; thus, it would be more + convenient to install a middlebox in front of such systems. It is + obvious that the hIPv4 framework needs a middlebox solution to + speed up the transition; combining CES architectures with the + hIPv4 framework might produce such a middlebox. For further + details, see Appendix D. + + o 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 is, to achieve ELOC + status for the prefixes used in a local network in the + intermediate routing architecture, see Appendix D. An ALOC realm + that wishes to achieve local unique status for its ELOC block in + the long-term routing architecture does not need to wait for other + ALOC realms to proceed to the same level simultaneously. It is + sufficient that the other ALOC realms have achieved the + intermediate routing architecture status. For further details, + see Section 6. + +14. Security Considerations + + Because the hIPv4 framework does not introduce other network + mechanisms than a new type of border router to the currently deployed + routing architecture, the best current practices for securing ISP + networks are still valid. Since the DFZ will no longer contain ELOC + prefixes, there are some benefits and complications regarding + security that need to be taken into account. + + + +Frejborg Experimental [Page 43] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + The hijacking of a single ELOC prefix by longest match from another + ALOC realm is no longer possible because the prefixes are separated + by a locator, the ALOC. To carry out a hijack of a certain ELOC + prefix, the whole ALOC realm must be routed via a bogus ALOC realm. + Studies should be done with the Secure Inter-Domain Routing (SIDR) + working group to determine whether the ALOC prefixes can be protected + from hijacking. + + By not being able to hijack a certain ELOC prefix, there are some + implications when mitigating distributed denial-of-service (DDoS) + attacks. This implication occurs especially in the long-term routing + architecture, e.g., when a multi-homed enterprise is connected with + unicast ALOC RBRs to the ISPs. + + One method used today to mitigate DDoS attacks is to inject a more + specific prefix (typically host prefix) to the routing table so that + 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 the 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. To have the sinkhole at the enterprise's ALOC + realm may saturate the connections between the enterprise and ISPs, + thus this approach is not a real option. + + By borrowing ideas from a service-centric networking architecture + [SCAFFOLD], a sinkhole service can be created. An example of how a + distributed sinkhole service can be designed follows: + + 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 the incoming traffic caused by the + attack is soon saturating the connections or other resources. + Thus, the staff informs the upstream ISPs of the attack, also + about 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; the resources are + 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 + + + +Frejborg Experimental [Page 44] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + matches Y. Also, the service ID is inserted to the locator + header; the service ID acts as a referral for the sinkhole. It + is possible that the sinkhole serves several victims; thus, 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); 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 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. Thus, traffic that does not contain the + agreed service ID might be bogus. Also, by inserting a service + ID to the valid packets, overlay solutions between the routers, + sinkholes, and victim can be avoided. In case the 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. This method can still be used inside an ALOC realm + for intra-ALOC attacks. For attacks spanning over several ALOC + realms new methods are needed; one example is described above. It is + desirable that the RBR and hIPv4-enabled routers are capable of + applying NAT rules and inserting service ID to selected packets in + the forwarding plane. + +15. Conclusions + + This document offers a high-level overview of the hierarchical IPv4 + framework that could be built in parallel with the current Internet + by implementing extensions at several architectures. Implementation + of the hIPv4 framework will not require a major service window break + in the Internet or at the private networks of enterprises. + Basically, the hIPv4 framework is an evolution of the current IPv4 + framework. + + The transition to hIPv4 might be attractive for enterprises since the + hIPv4 framework does not create a catch-22 situation, e.g., when + should an application used only inside the private network be ported + from IPv4 to IPv6? Also, what is the business justification for + porting the application to IPv6? Another matter is that when an + + + + +Frejborg Experimental [Page 45] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + 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, however, the legacy + applications do not need to be ported because hIPv4 is backwards + compatible with the classical IPv4 framework. This means lower costs + for the enterprise, and an additional bonus is the new stack's + capabilities to better serve mobility use cases. + + But the enterprise must take the decision soon and act promptly, + because the 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. + + However, though this document has focused only on IPv4, a similar + scheme can be deployed for IPv6 in the future, that is, creating a + 64x64 bit locator space. But some benefits would have been lost at + the time this document was written, such as: + + o Backwards compatibility with the current Internet and therefore + no smooth migration plan is gained. + + o 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 as pros or cons, depending upon one's view of the + privacy issue, as discussed in [RFC4941] and in + [Mobility_& _Privacy]. + + If an enterprise prefers hIPv4 (e.g., due to gaining additional IPv4 + addresses and smooth migration capabilities), there is 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 the service providers to + create an Internet routing architecture that holds less prefixes and + generates less BGP updates in DFZ than the current Internet. + + The hIPv4 framework is providing a new hierarchy in the routing + subsystem and is complementary work to multipath-enabled transport + protocols (such as MPTCP and SCTP) and service-centric networking + architectures (such as SCAFFOLD). End users and enterprises are not + interested in routing issues in the Internet; instead, a holistic + view should be applied on the three disciplines with a focus on new + service opportunities and communicated to the end users and + enterprises. Then perhaps the transition request to a new routing + architecture will be accepted and carried out. However, more work is + needed to accomplish a holistic framework of the three disciplines. + + + +Frejborg Experimental [Page 46] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + +16. References + +16.1. Normative References + + [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 + + [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. + + + + + + +Frejborg Experimental [Page 47] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + [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. + + + +Frejborg Experimental [Page 48] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + [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. + + + + + + + +Frejborg Experimental [Page 49] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + [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 + + The active participants at the Routing Research Group [RRG] mailing + list are acknowledged. They have provided ideas, proposals, and + discussions that have influenced the architecture of the hIPv4 + framework. The following persons, in alphabetical order, have + provided valuable review input: Aki Anttila, Mohamed Boucadair, Antti + Jarvenpaa, Dae Young Kim, Mark Lewis, Wes Toman, and Robin Whittle. + + Also, during the IRSG and IESG review process, Rajeev Koodli, Wesley + Eddy, Jari Arkko, and Adrian Farrel provided valuable review input. + + Lastly, a special thanks to Alfred Schwab from the Poughkeepsie ITSO + for his editorial assistance. + + + + + + + + + + + + + + + + + + + +Frejborg Experimental [Page 50] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + +Appendix A. Short-Term and Future IPv4 Address Allocation Policy + + In this section, we study how the hIPv4 framework could influence the + IPv4 address allocation policies to ensure that the new framework + will enable some reusage of IPv4 address blocks. It is the Regional + Internet Registries (RIRs) that shall define the final policies. + + When the intermediate routing architecture (see Figure 1) is fully + implemented, every ALOC realm could have a full IPv4 address space, + except the GLB, from which to allocate ELOC blocks. There are some + implications, however. In order for an enterprise to achieve site + mobility, that is, to change service provider 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. + + Larger enterprises have the resources to implement AS border routing. + Most large enterprises have already implemented multi-homing + solutions. Small and midsize enterprises (SMEs) may not have the + resources to implement AS border routing, or the implementation + introduces unnecessary costs for the SME. Also, if every enterprise + needs to have an allocated ALOC prefix, this will have an impact on + the RIB at the DFZ -- the RIB will be populated with a huge number of + non-aggregatable ALOC prefixes. + + It is clear that a compromise is needed. An SME site usually deploys + a single uplink to the Internet and should be able to reserve a PI + ELOC block from the RIR without being forced to create an ALOC realm, + that is, implement an RBR solution and AS border routing. Since the + PI ELOC block is no longer globally unique, an SME can only reserve + the PI ELOC block for the region where it is active or has its + attachment point to the Internet. The attachment point rarely + changes to another country; therefore, it is sufficient that the PI + ELOC block is regionally unique. + + When the enterprise replaces its Internet service provider, it does + not have to change its ELOC scheme -- only the local ALOC prefix at + the endpoints is changed. The internal traffic at an enterprise does + not make use of the ALOC prefix. The internal routing uses only the + ELOC prefixes, and thus the internal routing and addressing + architectures are preserved. + + Mergers and acquisitions of enterprises can cause ELOC conflicts, + because the PI ELOC block is hereafter only regionally unique. If an + enterprise in region A acquires an enterprise in region B, there is a + slight chance that both enterprises have overlapping ELOC prefixes. + + + + + +Frejborg Experimental [Page 51] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + If overlapping of ELOC prefixes occurs, the private unicast ALOC + solution can be implemented to separate them -- if all affected + endpoints support the hIPv4 framework. + + Finally, residential users will receive only PA locators. When a + residential user changes a service provider, she/he has to replace + the locators. Since a PA ELOC block is no longer globally unique, + every Internet service provider can use the PA ELOC blocks at their + ALOC realms; the PA locators become kind of private locators for the + service providers. + + If the forwarding planes and all hosts that establish inter-ALOC + realm sessions are upgraded to support the hIPv4 framework, that is, + the long-term routing architecture (see Figure 2) is implemented, + several interesting possibilities occur: + + o The regional allocation policy for PI ELOC spaces can be removed, + and the enterprise can make use of the whole IPv4 address space + that is globally unique today. The ELOC space is hereafter only + significant at a local ALOC realm. + + o In case of mergers or acquisitions of enterprises, the private + unicast ALOC solution can be used to separate overlapping ELOC + spaces. + + o The GLB space can be expanded to make use of all 32 bits (except + for the blocks defined in RFC 1918) for anycast and unicast ALOC + allocations; only ISPs are allowed to apply for GLB prefixes. + + o 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. Also, there is enough space in + the GLB to reserve global unicast ALOC prefix(es) for every + enterprise. + + o Residential users will still use global anycast ALOC solutions, + and if they change service providers, their locators need to be + replaced. + + The result is that a 32x32 bit locator space is achieved. When an + enterprise replaces an ISP with another ISP, only the ALOC prefix(es) + is replaced at endpoints and infrastructure nodes. Renumbering of + ALOC prefixes can be automated by, for example, DHCP and extensions + to IGP. + + + + + + + +Frejborg Experimental [Page 52] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + +Appendix B. Multi-Homing becomes Multi-Pathing + + When the transition to the intermediate routing architecture (see + Figure 1) is fully completed, the RIB of an ISP that has created an + ALOC realm will have the following entries: + + o The PA ELOC blocks of directly attached customers (residential and + enterprises) + + o The PI ELOC blocks of directly attached customers (e.g., + enterprises) + + o 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. In order to do routing and + forwarding of packets between ISPs, only ALOC information of other + ISPs is needed. + + Then, the question is how to keep the growth of ALOC reasonable? If + the enterprise is using PI addresses, has an AS number, and is + implementing BGP, why not apply for an ALOC prefix? + + Classical multi-homing is causing the biggest impact on the growth of + the size of the RIB in the DFZ -- so replacing a /20 IPv4 prefix with + a /32 ALOC prefix will not reduce the size of the RIB in the DFZ. + + Most likely, the only way to prevent this from happening is to impose + a yearly cost for the allocation of an ALOC prefix, except if you are + a service provider that is providing access and/or transit traffic + for your customers. And it is reasonable to impose a cost for + allocating an ALOC prefix for the non-service providers, because when + an enterprise uses an ALOC prefix, it is reserving a FIB entry + throughout the DFZ; the ALOC FIB entry needs to have power, space, + hardware, and cooling on all the routers in the DFZ. + + Implementing this kind of ALOC allocating policy will reduce the RIB + size in the DFZ quite well, because multi-homing will no longer + increase the RIB size of the DFZ. But this policy will have some + impact on the resilience behavior because by compressing routing + information we will lose visibility in the network. In today's + multi-homing solutions the network always knows where the remote + endpoint resides. In case of a link or network failure, a backup + path is calculated and an alternative path is found, and all routers + in the DFZ are aware of the change in the topology. This + functionality has off-loaded the workload of the endpoints; they only + need to find the closest ingress router and the network will deliver + + + +Frejborg Experimental [Page 53] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + the packets to the egress router, regardless (almost) of what + failures happen in the network. And with the growth of multi-homed + prefixes, the routers in the DFZ have been forced to carry greater + workloads, perhaps close to their limits -- the workload between the + network and endpoints is not in balance. The conclusion is that the + endpoints should take more responsibility for their sessions by + offloading the workload in the network. How? Let us 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) that 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 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). + + + + + + +Frejborg Experimental [Page 54] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + If the network link between the BR-I3 and 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 not blocked by + some security functionality) and thus try to switch the session over + to the other ISP by replacing the ALOC prefixes in the hIPv4 header. + Or the endpoints might try themselves to switch to the other ALOCs + 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; 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: + + o Concurrent and separate exit/entry paths via different attachment + points at multi-homed sites. + + o 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. + + o Only a single Network Interface Card (NIC) on the endpoints is + required. + + + + +Frejborg Experimental [Page 55] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + o 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 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. And the IP address space 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 that will have the following + characteristics: + + o An AS number is not mandatory for enterprises. + + o BGP is not mandatory at the enterprise's border routers; static + routing with Bidirectional Forwarding Detection (BFD) [RFC5880] is + an option. + + o Allocation of global ALOC prefixes for the enterprise should not + be allowed; instead, upstream ISPs provide the global ALOC + prefixes for the enterprise. + + o MPTCP provides dynamic load-balancing without using routing + protocols; several paths can be used simultaneously and thus + resilience is achieved. + + o Provides low growth of RIB entries at the DFZ. + + o 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. + + o 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. + + + + + +Frejborg Experimental [Page 56] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + - The enterprise's border router can cause BGP churn for the + adjacent ISPs, but not in the DFZ. + + o The cost of the border router should be less than in today's + multi-homing solution. + +Appendix C. Incentives and Transition Arguments + + The media has announced the meltdown of the Internet and the + depletion of IPv4 addresses several times, but the potential chaos + has been postponed and the general public has lost interest in these + announcements. Perhaps it could be worthwhile to find other valuable + arguments that the general public could be interested in, such as: + + o Not all endpoints need to be upgraded, only those that are + directly attached to the Internet, such as portable laptops, smart + mobile phones, proxies, and DMZ/frontend endpoints. But the most + critical endpoints, the backend endpoints where enterprises keep + their most critical business applications, do not need to be + upgraded. These endpoints should not be reached at all from the + Internet, only from the private network. And this functionality + can be achieved with the hIPv4 framework, since it is backwards + compatible with the current IPv4 stack. Therefore, investments in + legacy applications used inside an ALOC realm are preserved. + + o Mobility - it is estimated that the demand for applications that + perform well over the wireless access network will increase. + Introduction of MPTCP and identifier/locator split schemes opens + up new possibilities to create new solutions and applications that + are optimized for mobility. The hIPv4 framework requires an + upgrade of the endpoint's stack; if possible, the hIPv4 stack + should also contain MPTCP and identifier/locator split scheme + features. Applications designed for mobility could bring + competitive benefits. + + o The intermediate routers in the network do not need to be upgraded + immediately; the current forwarding plane can still be used. The + benefit is that the current network equipment can be preserved at + the service providers, enterprises, and residences (except + middleboxes). This means that the carbon footprint is a lot lower + compared to other solutions. Many enterprises do have green + programs and many residential users are concerned with the global + warming issue. + + o The migration from IPv4 to IPv6 (currently defined architecture) + will increase the RIB and FIB throughout DFZ. Whether it will + require a new upgrade of the forwarding plane as discussed in + [RFC4984] is unclear. Most likely an upgrade is needed. The + + + +Frejborg Experimental [Page 57] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + outcome of deploying IPv4 and IPv6 concurrently is that the + routers need to have larger memories for the RIB and FIB -- every + globally unique prefix is installed in the routers that are + participating in the DFZ. Since the enterprise reserves one or + several RIB/FIB entries on every router in the DFZ, it is + increasing the power consumption of the Internet, thus increasing + the carbon footprint. And many enterprises are committed to green + programs. If hIPv4 is deployed, the power consumption of the + Internet will not grow as much as in an IPv4 to IPv6 transition + scenario. + + o Another issue: if the migration from IPv4 to IPv6 (currently + defined architecture) occurs, the routers in the DFZ most likely + need to be upgraded to more expensive routers, as discussed in + [RFC4984]. In the wealthy part of the world, where a large + penetration of Internet users is already present, the service + providers can pass the costs of the upgrade along to their + subscribers more easily. With a "wealthy/high penetration" ratio + the cost will not grow so much that the subscribers would abandon + the Internet. But in the less wealthy part of the world, where + there is usually a lower penetration of subscribers, the cost of + the upgrade cannot be accepted so easily -- a "less wealthy/low + penetration" ratio could impose a dramatic increase of the cost + that needs to be passed along to the subscribers. And thus fewer + subscribers could afford to get connected to the Internet. For + the global enterprises and the enterprises in the less wealthy + part of the world, this scenario could mean less potential + customers and there could be situations when the nomads of the + enterprises can't get connected to the Internet. This is also not + fair; every human being should have a fair chance to be able to + enjoy the Internet experience -- and the wealthy part of the world + should take this right into consideration. Many enterprises are + committed to Corporate Social Responsibility programs. + + Not only technical and economical arguments can be found. Other + arguments that the general public is interested in and concerned + about can be found, for example, that the Internet becomes greener + and more affordable for everyone, in contrast with the current + forecast of the evolution of the Internet. + +Appendix D. Integration with CES Architectures + + Because the hIPv4 framework requires changes to the endpoint's stack, + it will take some time before the migration of the current IPv4 + architecture to the intermediate hIPv4 routing architecture is fully + completed. If a hIPv4 proxy solution could be used in front of + + + + + +Frejborg Experimental [Page 58] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + classical IPv4 endpoints, the threshold for early adopters to start + to migrate towards the hIPv4 framework would be less questionable and + the migration phase would also most likely be much shorter. + + Therefore, it should be investigated whether the hIPv4 framework can + be integrated with Core-Edge Separation [CES] architectures. In CES + architectures the endpoints do not need to be modified. The design + goal of a CES solution is to minimize the PI-address entries in the + DFZ and to preserve the current stack at the endpoints. But a CES + solution requires a new mapping system and also introduces a caching + mechanism in the map-and-encapsulate network nodes. Much debate + about scalability of a mapping system and the caching mechanism has + been going on at the [RRG] list. At the present time it is unclear + how well both solutions will scale; research work on both topics is + still in progress. + + Since the CES architectures divide the address spaces into two new + categories, one that is installed in the RIB of the DFZ and one that + is installed in the local networks, there are to some degree + similarities between CES architectures and the hIPv4 framework. + Actually, the invention of the IP and locator header swap + functionality was inspired by [LISP]. + + In order to describe how these two architectures might be integrated, + some terminology definitions are needed: + + CES-node: + + A network node installed in front of a local network that must + have the following characteristics: + + o Map-and-encapsulate ingress functionality + + o Map-and-encapsulate egress functionality + + o Incorporate the hIPv4 stack + + o Routing functionality, [RFC1812] + + o Being able to apply policy-based routing on the ALOC field + in the locator header + + The CES-node does not include the MPTCP extension because it would + most likely put too much of a burden on the CES-node to signal and + maintain MPTCP subflows for the cached hIPv4 entries. + + + + + + +Frejborg Experimental [Page 59] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + Consumer site: + + A site that is not publishing any services towards the Internet, + that is, there are no entries in DNS for this site. It is used by + local endpoints to establish outbound connectivity -- endpoints + are initiating sessions from the site towards content sites. + Usually such sites are found at small enterprises and residences. + PA-addresses are usually assigned to them. + + Content site: + + A site that is publishing services towards the Internet, and which + usually does have DNS entries. Such a site is used by local + endpoints to establish both inbound and outbound connectivity. + Large enterprises use PI-addresses, while midsize/small + enterprises use either PI- or PA-address space. + + The CES architectures aim to reduce the PI-address entries in the + DFZ. Therefore, map-and-encapsulate egress functionality will be + installed in front of the content sites. It is likely that the node + containing map-and-encapsulate egress functionality will also contain + map-and-encapsulate ingress functionality; it is also a router, so + the node 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 is possible that the large content providers (LCPs) are not + willing to install map-and-encapsulate functionality in front of + their sites. If the caching mechanism is not fully reliable or if + the mapping lookup delay does have an impact on their clients' user + experience, then most likely the LCPs will not adopt the CES + architecture. + + In order to convince a 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 will + scale. That is, if the endpoint stack is upgraded, the caching + mechanism is maintained by the endpoint itself. The mapping + mechanism can be removed if the CES architecture's addressing scheme + is replaced with the addressing scheme of hIPv4 when the CES solution + is integrated at the endpoints. With this approach, the LCPs might + install a CES-node in front of their sites. Also, some endpoints at + the content site might be upgraded with the hIPv4 stack. + + + + + + + +Frejborg Experimental [Page 60] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + If the LCP faces issues with the caching or mapping mechanisms, the + provider can ask its clients to upgrade their endpoint's stack to + ensure a proper service level. At the same time, the LCP promotes + the migration from the current routing architecture to a new routing + architecture, not for the sake of the routing architecture but + instead to ensure a proper service level -- you can say that a + business model will promote the migration of a new routing + architecture. + + The hIPv4 framework proposes that the IPv4 addresses (ELOC) should no + longer be globally unique; once the transition is completed, a more + regional allocation can be deployed. But this is only possible once + all endpoints (that are establishing sessions to other ALOC realms) + have migrated to support the hIPv4 framework. Here the CES + architecture can speed up the re-usage of IPv4 addresses; that is, + once an IPv4 address block has become an ELOC block it can be re-used + in the other RIR regions, without the requirement that all endpoints + in the Internet must first be upgraded. + + As stated earlier, the CES architecture aims to remove PI-addresses + from the DFZ, making the content sites more or less the primary + target for the roll-out of a CES solution. At large content sites a + CES-node most likely will be installed. To upgrade all endpoints + (that are providing services towards the Internet) at a large content + site will take time, and it might be that the endpoints at the + content site are upgraded only within their normal lifecycle process. + But if the size of the content site is small, the administrator + either installs a CES-node or upgrades the endpoint's stack -- a + decision influenced by availability, reliability, and economic + feasibility. + + Once the content sites have been upgraded, the PI-address entries + have been removed from the DFZ. Most likely also some endpoints at + the consumer sites have been upgraded to support the hIPv4 stack -- + especially if there have been issues with the caches or mapping + delays that have influenced the service levels at the LCPs. Then, + the issue is how to keep track of the upgrade of the content sites -- + have they been migrated or not? If the content sites or content + endpoints have been migrated, the DNS records should have either a + CES-node entry or ALOC entry for each A-record. When the penetration + of CES solutions at content sites (followed up by CES-node/ALOC + records in DNS) is high enough, the ISP can start to promote the + hIPv4 stack upgrade at the consumer sites. + + Once a PA-address block has been migrated it can be released from + global allocation to a regional allocation. Why would an ISP then + push its customers to deploy hIPv4 stacks? Because of the business + model -- it will be more expensive to stay in the current + + + +Frejborg Experimental [Page 61] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + architecture. The depletion of IPv4 addresses will either cause more + NAT at the service provider's network (operational expenditures will + increase because the network will become more complex) or the ISP + should force its customers to migrate to IPv6. But the ISP could + lose customers to other ISPs that are offering IPv4 services. + + When PA-addresses have been migrated to the hIPv4 framework, the ISP + will have a more independent routing domain (ALOC realm) with only + ALOC prefixes from other ISPs and ELOC prefixes from directly + attached customers. BGP churn from other ISPs is no longer received, + the amount of alternative paths is reduced, and the ISP can better + control the growth of the RIB at their ALOC realm. The operational + and capital expenditures should be lower than in the current routing + architecture. + + To summarize, the content providers might find the CES+hIPv4 solution + attractive. It will remove the forthcoming IPv4 address depletion + constraints without forcing the consumers to switch to IPv6, and thus + the content providers can continue to grow (reach more consumers). + + The ISP might also find this solution attractive because it should + reduce the capital and operational expenditures in the long term. + Both the content providers and the ISPs are providing the foundation + of the Internet. If both adopt this architecture, the consumers have + to adopt. Both providers might find business models to "guide" the + consumers towards the new routing architecture. + + Then, how will this affect the consumer and content sites? + Residential users will need to upgrade their endpoints. But it + doesn't really matter which IP version they use. It is the + availability and affordability of the Internet that matters most. + + Enterprises will be affected a little bit more. The edge devices at + the enterprises' local networks need to be upgraded -- edge nodes + such as AS border routers, middleboxes, DNS, DHCP, and public nodes + -- but by installing a CES-node in front of them, the upgrade process + is postponed and the legacy nodes can be upgraded during their normal + lifecycle process. The internal infrastructure is preserved, + internal applications can still use IPv4, and all investment in IPv4 + skills is preserved. + + Walkthrough of use cases: + + 1. A legacy endpoint at a content site establishes a session to a + content site with a hIPv4 upgraded endpoint. + + + + + + +Frejborg Experimental [Page 62] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + When the legacy endpoint resolves the DNS entry for the remote + endpoint (a hIPv4 upgraded endpoint), it receives an ALOC record + in the DNS response. The legacy endpoint ignores the ALOC record. + Only the A-record is used to establish the session. Next, the + legacy endpoint initializes the session and a packet is sent + towards the map-and-encapsulate ingress node, which needs to do a + lookup at the CES mapping system (the assumption here is that 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, the + mapping system returns an ALOC prefix. + + The CES-node will not use the CES encapsulation scheme for this + session. Instead, the hIPv4 header scheme will be used and a /32 + entry will be created in the cache. A /32 entry must be created; + it is possible that not all endpoints at the remote site are + upgraded to support the hIPv4 framework. The /32 cache entry can + be replaced with a shorter prefix in the cache if all endpoints + are upgraded at the remote site. To indicate this situation, a + subfield should be added for the ALOC record in the mapping + system. + + The CES-node must execute the following steps for the egress + packets: + + 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. + + + + +Frejborg Experimental [Page 63] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + i. 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. + + j. Because the size of the packet might exceed MTU due to the + insertion of the locator header, and if 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. + + 2. 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 if the new record prefix is used to locate RBR- + nodes or CES-nodes in the Internet -- the CES-node will act as a + hIPv4 proxy in front of the remote legacy endpoint. Thus the + hIPv4 endpoint assembles a hIPv4 packet to initialize the session, + and when the packet arrives at the CES-node it 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 an entry already exists) for + returning packets. A /32 entry is required. To optimize the + usage of cache entries, the CES-node might ask the CES mapping + node whether all endpoints at the remote site are upgraded or + not. If upgraded, a shorter prefix can be used in the cache. + + g. Decrease the TTL value by one. + + + + +Frejborg Experimental [Page 64] + +RFC 6306 Hierarchical IPv4 Framework July 2011 + + + h. Calculate IP and transport protocol header checksums. + + i. Forward the packet according to the destination address of the + IP header. + + 3. A hIPv4-enabled endpoint with a regionally unique ELOC at a + consumer site establishes a session to a consumer site with a + legacy endpoint. + + In this use case, 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. Sessions between ALOC realms will + fail. Some applications establish sessions between consumer + sites. The most common are gaming and peer-to-peer applications. + These communities have historically been in the forefront of + adopting new technologies. It is expected that they either + develop workarounds to solve this issue or simply ask their + members to upgrade their stacks. + + 4. 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. + + 5. 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 + + + + + + + + + + + + + + + + + +Frejborg Experimental [Page 65] + |