tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 6306

Experimental
Pages: 65
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: IRTF

Hierarchical IPv4 Framework

Part 1 of 3, p. 1 to 18
None       Next RFC Part

 


Top       ToC       Page 1 
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.

Page 2 
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.

Top       Page 3 
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

Top      ToC       Page 4 
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.

Top      ToC       Page 5 
   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.

Top      ToC       Page 6 
     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

Top      ToC       Page 7 
   [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.

Top      ToC       Page 8 
   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.

Top      ToC       Page 9 
   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

Top      ToC       Page 10 
   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

Top      ToC       Page 11 
   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.

Top      ToC       Page 12 
   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

Top      ToC       Page 13 
   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.

Top      ToC       Page 14 
   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.

Top      ToC       Page 15 
      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.

Top      ToC       Page 16 
   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.

Top      ToC       Page 17 
      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.

Top      ToC       Page 18 
   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.



(page 18 continued on part 2)

Next RFC Part