GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6306

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
  1. The enterprise has recently been merged with another enterprise

and overlapping ELOC spaces exist.

 o  Several private ALOC prefixes due to
  1. 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

  1. SIP: IP addresses are inserted in the SDP offers/answers, XML

body, Contact, Via, maddr, Route, Record-Route SIP headers.

  1. Mobile IP: the mobile node uses several IP addresses during the

registration process.

  1. IPsec AH: designed to detect alterations at the IP packet

header.

  1. RSVP: Resource Reservation Protocol (RSVP) messages are sent

hop-by-hop between RSVP-capable routers to construct an

       explicit path.
  1. ICMP: notifications need to be able to incorporate ALOC

information and assemble the hIPv4 header in order to be routed

       back to the source.
  1. Source Specific Multicast: the receiver must specify the source

address.

  1. 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:
  1. 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.

  1. 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:
  1. 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

  1. 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6306.txt · Last modified: 2011/07/09 00:22 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki