Address Rewriting Approaches

In the address rewriting approach, the 128 bits of an IPv6 address are split, where the 64 most significant bits are used as the routing locator and the 64 least significant bits are used as the endpoint identifier. Figure 2.5 illustrates the process of address rewriting. The routing locator information is not known by the end nodes. Whilst this approach supports IPv6 only, it allows for consistency between prefix assignment and physical network topology. ISP2 ISP1 Source (src) Destination (dst) Ingress Router Egress Router unspecified src EID dst RLOC dst EID Source address Dest. address 1 src RLOC src EID dst RLOC dst EID Source address Dest. address 2 src RLOC src EID unspecified dst EID Source address Dest. address 3

Figure 2.5: Address rewriting approach

2.7.1.1 Global locator and Identifier Split

Global locator and Identifier Split (GLI-Split) [Menth et al., 2010] is a locator-identifier addressing and routing architecture. GLI-Split implements a global locator for global routing, local locator inside domains and identifier split. Locators and identifiers are coded as IPv6 addresses to allow compatibility with IPv6 protocols.

the mapping systems. GLI-split supports mobility, but requires modifications to pro- tocols like Dynamic Host Configuration Protocol (DHCP) to support multihoming.

2.7.1.2 4+4

The 4+4 proposal [Paul et al., 2009; Tur´anyi et al., 2003] extends the Network Address Translation (NAT) architecture [Srisuresh and Egevang, 2001] to enable end-to-end host transparency. 4+4 uses two name spaces in DNS: one corresponds to the private IP addresses of the end-host and the other one is the public IP address of the NAT router responsible for the end-host. Thus, 4+4 address is formed by concatenating two IPv4 addresses, the public and the private one. As routing occurs, 4+4 routers (NAT gateways) perform swapping of addresses to assure that private IPv4 addresses are never used outside the network they belong to. The proposal allows end-hosts to have more than one address, and allows incremental deployments. Nevertheless, 4+4 only applies to IPv4 networks.

2.7.1.3 IP Next Layer

IP Next Layer (IPNL) [Francis and Gummadi, 2001] also extends NAT by adding a new layer between IP and TCP. It is different from 4+4 as it introduces new paradigms regarding the identification of a host. The end-host is identified by its FQDN, and the IPNL address, which is the locator. The IPNL address corresponds to the gateway ad- dress, the realm number and the host address triplet. Thus, for each communication, peers must use the FQDN, obtaining the IPNL address in the initial packet exchange. The host itself does not know all the possible addresses it has (when behind several routers) since it is only aware of its name. This type of design introduces overhead in packet processing; for instance, NAT routers need to maintain FQDN records per host [Tur´anyi et al., 2003].

2.7.1.4 Translating Relaying Internet Architecture integrating Active Directories

Translating Relaying Internet Architecture integrating Active Directories (TRIAD) [Grit- ter and Cheriton, 2001] is a proposal that also uses names as identifiers and introduces a new paradigm for routing that is based on content, with the goal of reducing the access time to content. A content layer and content routers holding mapping informa- tion are introduced to allow the access to specific information identified in the form of an Universal Resource Locator. A host contacts a content router that answers to a request with the next available content router. At the end, the router close to the

2.7 End-site Multihoming

destination content server replies with the preferred address of the server. With such approach, a client gets the best path to the content server. TRIAD has some implemen- tation issues, since modifications are required in the end-hosts and routers with NAT or gateway functionalities.

2.7.1.5 Pluralistic Network Architecture

Pluralistic Network Architecture (Plutarch) [Crowcroft et al., 2003] is a proposal that introduces contexts to suppress the need of global names to identify hosts. More- over, Plutarch argues that naming and addressing should be handled by end-to-end systems and not hierarchical, domain-based system, such as DNS. The dedicated func- tions are assured by context borders (e.g. NAT routers) to assure end-to-end service. Despite including some implementation primitives, Plutarch specification is not ready for a global adoption in the Internet as important aspects, such as failure notification are not specified.

Table 2.6: End-Site multihoming proposals with address rewriting approach. MH- Multihoming, OS-Operating System.

Protocol MH Goals Strengths Flaws Implementation

*

R U L F OS

GLI-Split2 √ √ √ X Security Requires nodes changes

–

4+43 _{X X X X Facilitates}

deployment

Only for IPv4. In Linuxb

IPNL3 √ √ _{X X Supports}

mobility

Hosts are not aware of their multihoming condition In Linuxc TRIAD3 _{X X X X Optimized} access to content Weak multihoming approach –

Plutarch3 X X X X Routing based on context

Weak multihoming approach

–

a_{[OpenLisp, 2013]} b_{[Tur´anyi and Valk ´o, 2003]} c_{[Francis and Gummadi, 2001]} 2_{Address rewrite} 3_{NAT extension} *_{Implementations in network simulators are not available.}

Some proposals build upon current practices in the Internet architecture and implement extensions to NAT, to allow the support of multihoming and enable end- to-end communication, as summarized in Table 2.6. For instance, 4+4 [Tur´anyi et al., 2003] supports multiaddressing, but raises security concerns since it exposes private addresses in packets. Others, such as IP Next Layer (IPNL) [Francis and Gummadi, 2001] address security but disable the multihoming information on end-hosts (e.g. hosts do not know if they have multiple addresses). Translating Relaying Internet Ar- chitecture integrating Active Directories (TRIAD) [Gritter and Cheriton, 2001] intro- duces the concept of routing by content, but requires many modifications to the actual Internet architecture. Also Plutarch [Crowcroft et al., 2003] uses context to enable iden- tification and puts emphasis on end-hosts functionalities. Nonetheless, Plutarch does not include failure detection mechanisms. GLI-Split [Menth et al., 2010] maintains compatibility with IPv6, but requires changes to protocols like DHCP.