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
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
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
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.
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
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.
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
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
c. The ALOC prefix of the locator header as the remote ALOC
d. The ELOC prefix of the locator header as the local IP address.
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
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
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
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
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
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
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
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).
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
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
To implement the hierarchical IPv4 framework, some basic rules are
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
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
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
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.
Identification: 16 bits
The Identification field is identical to that of RFC 791.
Flags: 3 bits
The Flags field is identical to that of RFC 791.
Fragment Offset: 13 bits
The Fragment Offset field is identical to that of RFC 791.
Time to Live: 8 bits
The Time to Live field is identical to that of RFC 791.
Protocol: 8 bits
A new protocol number must be assigned for hIPv4.
Header Checksum: 16 bits
The Header Checksum field is identical to that of RFC 791.
Source Address: 32 bits
The Source Address field is identical to that of RFC 791.
Destination Address: 32 bits
The Destination Address field is identical to that of RFC 791.
Options and Padding: Variable length
The Options and Padding fields are identical to that of RFC 791.
ALOC Realm Bit, A-bit: 1 bit
When the initiator and responder reside in different ALOC realms,
the A-bit is set to 1 and the Area and Endpoint Locator fields
must be used in the locator header. The size of the locator
header is 12 bytes. When the A-bit is set to 0, the initiator and
responder reside within the same ALOC realm. The Area and
Endpoint Locator shall not be used in the locator header. The
size of the locator header is 4 bytes.
Identifier Bit, I-bit: 1 bit
The identifier bit is set to 1 if the endpoint is using an
identifier/locator split scheme within the locator header. The
identifier/locator split scheme must indicate by how much the size
of the locator header is increased. The Locator Header Length
field is also added to the locator header.
Swap Bit, S-bit: 1 bit
The initiator sets the swap bit to 0 in the hIPv4 packet. An RBR
will set this bit to 1 when it is swapping the source and
destination addresses of the IP header with the ALOC and ELOC
prefixes of the locator header.
Forwarding Indicator, FI-bits: 2 bits
The purpose of the Forwarding Indicator (FI) field is to provide a
mechanism for a future forwarding plane to identify which
Forwarding Information Base (FIB) should be used for inter-ALOC
realm sessions. The new forwarding plane will remove the swap
functionality of IP and locator header values for both unicast and
multicast sessions. The outcome is that the IP and transport
protocol headers will remain intact and only FI and LH checksum
values in the locator header will alternate. The following values
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
10: Remote ELOC approach routing mode. The remote ALOC RBR and
following routers shall forward the packets based on the ELOC
prefix in the locator header.
11: Inter-ALOC RPF check mode. The local ALOC RBR changes the
FI-bits to 11 and the following inter-ALOC routers on the
shared tree shall apply the RPF check against the ALOC prefix
in the locator header.
Valiant Load-Balancing, VLB-bits: 2 bits (optional, subject for
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
01: First subflow. The shortest path or Valiant Load-Balancing
might be applied.
11: Next subflow(s). Valiant Load-Balancing should be applied
Load-Balanced, L-bit: 1 bit (optional, subject for further research)
The initiator must set the L-bit to zero. A Valiant Load-
Balancing-capable node can apply VLB switching for the session if
the value is set to zero; if the value is set to 1, VLB switching
is not allowed. When VLB switching is applied for the session,
the node applying the VLB algorithm must set the value to 1.
Protocol: 8 bits
The Protocol field is identical to that of RFC 791.
Locator Header Checksum: 16 bits
A checksum is calculated for the locator header only. The
checksum is computed at the initiator, recomputed at the RBR, and
verified at the responder. The checksum algorithm is identical to
that of RFC 791.
Area Locator (optional): 32 bits
The Area Locator is an IPv4 address assigned to locate an ALOC
realm in the Internet. The ALOC is assigned by an RIR to a
service provider. The ALOC is globally unique because it is
allocated from the GLB.
Endpoint Locator (optional): 32 bits
The Endpoint Locator is an IPv4 address assigned to locate an
endpoint in a local network. The ELOC block is assigned by an RIR
to a service provider or to an enterprise. In the intermediate
routing architecture the ELOC block is only unique in a
geographical region. The final policy of uniqueness shall be
defined by the RIRs. In the long-term routing architecture the
ELOC block is no longer assigned by an RIR; it is only unique in
the local ALOC realm.
Locator Header Length (optional): 16 bits
The Locator Header Length is the total length of the locator
header. Locator Header Length is applied when the identifier bit
is set to 1. Identifier/locator split scheme parameters are
inserted into the locator header after this field.
Padding (optional): variable
The locator header padding is used to ensure that the locator
header ends on a 32-bit boundary. The padding is zero.
10.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
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:
- 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
- IPsec AH: designed to detect alterations at the IP packet
- RSVP: Resource Reservation Protocol (RSVP) messages are sent
hop-by-hop between RSVP-capable routers to construct an
- 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
- 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.
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.
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
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
g. Forward the packet to the shared multicast tree.
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
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
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.
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
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
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.
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-
12. Mobility Considerations
This section considers two types of mobility solutions: site mobility
and endpoint 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
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.
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.
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.