tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6306

 
 
 

Hierarchical IPv4 Framework

Part 2 of 3, p. 18 to 42
Prev RFC Part       Next RFC Part

 


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

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

Top      Up      ToC       Page 20 
   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

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

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

Top      Up      ToC       Page 23 
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

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

Top      Up      ToC       Page 25 
   The main difference between anycast and unicast ALOC types is:

   o  In an anycast ALOC scenario, ELOC routing information is shared
      between the attached ALOC realms.

   o  In a unicast ALOC scenario, no ELOC routing information is shared
      between the attached ALOC realms.

   Unicast ALOC functionalities should not be deployed between private
   and ISP ALOC realms in the intermediate routing architecture -- it
   would require too many locators from the GLB space.  Instead, unicast
   ALOC functionality will be used to separate private ALOC realms.

   ALOC space is divided into two types, a globally unique ALOC space
   (a.k.a. GLB) that is installed in DFZ, and a private ALOC space that
   is used inside private networks.  Private ALOCs use the same locator
   space as defined in [RFC1918]; a private ALOC must be unique inside
   the private network and not overlap private ELOC prefixes.  Only ISPs
   should be allowed to apply for global ALOC prefixes.  For further
   discussion, see Appendix A.  The ISP should aggregate global ALOC
   prefixes as much as possible in order to reduce the size of the
   routing table in DFZ.

   When a user logs on to the enterprise's network, the endpoint will
   receive the following locator prefixes via provisioning means (e.g.,
   DHCP or manually configured):

   o  One ELOC prefix for each network interface.

   o  One private ALOC prefix due to

      -  The enterprise has recently been merged with another enterprise
         and overlapping ELOC spaces exist.

   o  Several private ALOC prefixes due to

      -  The enterprise network spans high-speed long-distance
         connections.  It is well-known that TCP cannot sustain high
         throughput for extended periods of time.  Higher throughput
         might be achieved by using multiple paths concurrently.

   o  One or several global ALOC prefixes.  These ALOCs describe how the
      enterprise network is attached to the Internet.

   As the user establishes a session to a remote endpoint, DNS is
   usually used to resolve remote locator prefixes.  DNS will return
   ELOC and ALOC prefixes of the remote endpoint.  If no ALOC prefixes
   are returned, a classical IPv4 session is initiated to the remote

Top      Up      ToC       Page 26 
   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).

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

Top      Up      ToC       Page 28 
   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

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

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

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

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

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

Top      Up      ToC       Page 34 
   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

Top      Up      ToC       Page 35 
   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:

Top      Up      ToC       Page 36 
      -  SIP: IP addresses are inserted in the SDP offers/answers, XML
         body, Contact, Via, maddr, Route, Record-Route SIP headers.

      -  Mobile IP: the mobile node uses several IP addresses during the
         registration process.

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

      -  RSVP: Resource Reservation Protocol (RSVP) messages are sent
         hop-by-hop between RSVP-capable routers to construct an
         explicit path.

      -  ICMP: notifications need to be able to incorporate ALOC
         information and assemble the hIPv4 header in order to be routed
         back to the source.

      -  Source Specific Multicast: the receiver must specify the source
         address.

      -  IGMPv3: a source-list is included in the IGMP reports.

   o  Applications related to security, such as firewalls, must be
      enhanced to support ALOC prefixes.

   o  Applications that will function with FQDN, but many use IP
      addresses instead, such as ping, traceroute, telnet, and so on.
      The CLI syntax needs to be upgraded to support ALOC and ELOC
      information via the extended socket API.

   At first glance, it seems that a lot of applications need to be re-
   engineered and ported, but the situation is not all that bad.  The
   applications used inside the local ALOC realm (e.g., an enterprise's
   private network) do not need to be upgraded, neither in the
   intermediate nor in the long-term architecture.  The classical IPv4
   framework is preserved.  Only IP-aware applications used between ALOC
   realms need to be upgraded to support the hIPv4 header.  IPv6 has the
   definitions in place of the applications mentioned above, but the
   migration of applications from IPv4 to IPv6 can impose some capital
   expenditures for enterprises, especially if the applications are
   customized or homegrown; see [Porting_IPv4].

   As stated earlier, hIPv4 does not require to port applications used
   inside a private network.  The conclusion is that, whatever next
   generation architecture is deployed, some applications will suffer,
   either during the transition period or when being re-engineered in
   order to be compatible with the new architecture.

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

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

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

Top      Up      ToC       Page 40 
   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

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

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



(page 42 continued on part 3)

Next RFC Part