MULTIHOMING

So, whilst multihoming offers great flexibility in how network connectivity may be used, it is subject to the constraints of how addressing & routing are implemented in IP, discussed in the following section.

2.2.1. Names, Addresses & Routes. In order to understand why the use of multihoming2

creates problems, it is helpful to consider first how the addressing system functions. An early Internet Engineering Note (IEN) defines network names, addresses, and routes – as follows: “The name tells what the process is; the address tells where the process is; the route tells how to get there.” [12, Pg. 2] Whilst names generally provide a human-readable description of a network element – e.g. as manifest in the Domain Name System (DNS) used in the Internet today, addresses are used to provide a machine-usable means by which such network elements may be referenced. Following this, routes express the topological information required to reach an address through the network.

2.2.1.1. Origins. The scalability of the IP address system has been a concern since the late 1970s. In 1977, [13] represented a milestone in understanding the problem ofhierarchical routing, whereby the routing of data traffic could scale efficiently with the growth of the wider network. Whilst IP has now employed this since 1981 – first introduced in the form of “classful” IP subnetting, based on octet boundaries of the IP address [14, Sec. 2.3] – the practice of variable-length subnet masking (VLSM), whereby addresses were further divided at arbitrary (yet contiguous) bit indices, was not formally proposed until 1993 in the form of Classless Inter-Domain Routing (CIDR) [15].

The further division of IP address space – in the form of CIDR – was driven by the growth of the network; at that time, networking based on the ISO protocol families was widespread, and envisioned as the future standard. So, Berkeley UNIX3

(BSD) introduced one of the first widely-available implementations of a generictrie- based routing scheme [16], supporting both ISO & IP protocol families. However,

2

Here, I am discussing the role of unicast addressing in multihoming, as is normally used for 1:1 communication between hosts; and not multicast, broadcast or the special case of anycasting.

3

FreeBSD – its direct descendant, in terms of code base – is used as the basis of the empirical studies in Chapters 4-6.

10 2. PROBLEM BACKGROUND

as concerns over the long-term scalability of the IPv4 addressing system grew, the Internet research community began to advocate a transition to a new version of IP: IPv6. Whilst both IPv4 and IPv6 are incompatible at wire level, IPv6 makes several improvements and changes beyond IPv4. Here, I confine myself to discussing those details of the addressing system which are relevant to multihoming; refer to Subsec. 2.4.3 for a discussion of relevant points.

2.2.1.2. Addresses in IPv4. The first widely-used version of the Internet Protocol, IPv4, uses an address format which is 32 bits wide. A common human-readable representation of the IP address is the “dot-quad”, which many people are familiar with: e.g. the form 192.168.0.1, where each four octets are separated by a period. However, the bits contained within this address play an essential role inhierarchical routing [14, Pg.6, Para. 4]: each IP address also has aprefix length, which specifies the number of significant bits forming the network part of the address; in CIDR notation, this is usually written after the address, e.g. 192.168.0.1/24 [17, Pg. 5, Para. 1]. The remainder of the IP address (i.e. the least significant bits after the prefix length) forms the host part, intended to uniquely identify the host within its local subnetwork. It is this overloaded use of the IP address which gives rise to the problems described at length in Subsec. 2.2.2; in addition, the current shortage4

of available, contiguous IPv4 address space creates additional problems for hierarchical routing in IPv4, which I discuss in Sec. 2.3.

2.2.1.3. Changes in IPv6. Whilst IPv6 uses a larger address representation (128 bits) [18], it largely follows existing IPv4 practices for hierarchical routing [19] (with some key exceptions, which I discuss in Subsec. 2.4.3): the IPv6 address is also di- vided5

into network and host parts, using the same CIDR semantics as for IP ad- dresses. However, as IPv6 has inherited many of IPv4’s operational practices and architectural features – including how addresses are allocated and used in the routing

4

http://www.internetsociety.org/news/ietf-statement-ipv4-depletion

5

Alternative addressing schemes based on IPv6 (e.g. GSE/8+8, discussed in Sec. 3.3) propose further changes to its logical structure.

2.2. MULTIHOMING 11

system – it also inherits the problems described in Subsec. 2.2.2, and these are dis- cussed further in [3, Sec. 5] (although IPv6 has richer support for multihoming; refer to Subsec. 2.4.3).

2.2.2. IP address entanglement. The overloaded use of IP addresses – i.e. to represent bothnetwork locationandnode identity – creates a set of well-known prob- lems [3, Sec. 2]. From an implementation viewpoint, this may be further understood by considering the bindings of an IP address within the protocol stack, as shown in Table 2.1.

Layer

Protocol

IP (v4 and v6) ILNP (ILNPv6) Application FQDNa

, IP address FQDN or app-specific Transport IP address [Node] Identifier (NID), NID

Network IP address Locator (L64), L64

Link IP address Dynamic binding

a

Fully Qualified Domain Name

Table 2.1. _{Use of names and addresses in IP by layer (derived from [20,}

Tab. II]) – as compared with the ILSA studied in this dissertation, ILNP. IP sessions become “bound” to physical links, as the same IP address is used by each protocol layer to both identify individual nodes and for topological routing. By contrast, an ILSA – e.g. ILNP – treats both roles as logically separate; nodes may be reached by several paths, represented by multiple locator values.

Transport layer protocols (e.g. TCP & UDP) use the IP address to identify

nodes. In conjunction with port numbers, these are used to uniquely identify sessions between two hosts. However, as shown in Table 2.1, the overloaded use of the IP address creates an implicit binding. So, transport layer sessions become bound to specific links, further complicating the separation of location from identity within the current IP architecture. [3] further describes the shortcomings of IPv4 addresses in the light of operational experience: specifically, their lack of utility as a unique node identifier.

Additionally, the IP network layer and routing functions use the IP address to identify IP sub-networks, i.e. network location. Such use of IP addresses as locators

12 2. PROBLEM BACKGROUND

reached. Multihomed sites add complexity to this exchange, by requiring additional prefixes to be advertised; refer to Sec. 2.3. Whilst this can be mitigated to some extent by the use of Network Address Translation (NAT), this introduces other problems; refer to Subsec. 2.3.5.

2.2.3. The Identifier-Locator Split. Given the problems inherent to how IP addresses are used today (and their role in multihoming, described in Subsec. 2.2.2), there has been renewed interest in networking architectures wherelocation andiden- tity are logically separate, often abbreviated as the “ID/Loc” split: i.e. Identifier- Locator Split Architectures (ILSAs), which I discuss further in Subsec. 2.4 & Chapter 3. In ILSAs, multihoming may be realised as a choice between locators used to reach nodes. However, changes may be required at hosts if they participate directly in such an ILSA.

In addition, concurrent multi-path transport protocolshave recently emerged as a mechanism for host multihoming at the transport layer. I review two such protocols in Chapter 3 as part of the solution space: SCTP & MP-TCP. By contrast, ILSAs provide multihoming capabilities at the network layer. However, multi-path proto- cols cannot solve the problems of how IP addresses may be used by applications on their own; and, moreover, such protocols do not address the problem space of site multihoming.

2.2.4. Summary. In this section, I have reviewed how the IP addressing & rout- ing system used today has developed, followed by a description of how the overloaded use of IP addresses for multihoming affects several layers of the networking stack. Their co-mingled use as identifiers and locators (in hierarchical routing) creates prob- lems for both routing and applications; and, whilst IPv6 proposes a larger address space, this – on its own – cannot solve these problems. In the following section, I examine how these problems manifest within the IP routing system.