RFC 6306
Hierarchical IPv4 Framework
Pages: 65
Experimental
Experimental
Part 2 of 3 – Pages 18 to 42
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.
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.
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
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.
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.
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
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.
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).
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.
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
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.
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
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.
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.
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
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
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.
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.
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.
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.
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
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.
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)