An identifier-locator approach to host multihoming Bruce Simpson Saleem N. Bhatti University of St Andrews, UK University of St Andrews, UK [email protected] [email protected] Abstract—Host multihoming allows individual hosts to be demonstrate multihoming and load balancing functions. We multiply connected to the network, e.g. by concurrent use of two evaluate its performance in comparison to IPv6. We use the network prefixes, each network prefix tied to a separate network terms Locator and Identifier as defined in RFC6115 [8]. interface. Such multihoming capability improves the host’s ability to implement such features as load-balancing, fail-over and multi- We begin in Section II by describing how an ‘ID/Loc’ path transport protocols. However, IP does not directly support split affects routing state for multihomed sites (and hosts). host multihoming today. The Identifier / Locator split solution After presenting some related work in Section III, we describe space is seen as one way for reducing such negative impact. how the ILNPv6 host architecture has been implemented in We present an evaluation of host-multihoming as a prototype Section IV, with emphasis on how existing Application Pro- implementation of the Identifier Locator Network Protocol (ILNP) on FreeBSD, as a superset of IPv6 – called ILNPv6. We demon- gramming Interfaces (APIs) are affected. Section V describes strate load-balancing using ILNPv6 multihoming and compare our experimental configuration, method and results. Scalability performance with IPv6 forwarding at the end host. and performance is discussed briefly in Section VI, and we conclude in Section VII. I. INTRODUCTION The growth of the Internet routing table is a significant II. BACKGROUND problem. It is known that load balancing and multihoming The overloaded use of IP addresses today may be under- are the two principal factors involved. Whilst much of this stood by considering the bindings of an IP address within the growth is at the edge [1]–[4] of the network, it impacts upon protocol stack [9], as shown in Table I. The second column the core network: the state required for these functions must shows that IP addresses are used as both node identifiers and be propagated throughout the routing infrastructure. topological locators. Whilst this table describes these in terms There is significant overlap between node identity and of ‘names’ we do not discuss this beyond API compatibility. network location as represented by the way IP addresses have TABLE I been used for 35 years [5], [6]. Architectures which propose USE OF NAMES IN IP AND ILNP aseparationoflocationfromidentitymaymitigatetheeffects of routing table growth [1]. Whilst IPv6 has expanded the Protocol layer IP (v4 and v6) ILNP (ILNPv6) Application FQDN*, IP address FQDN or app-specific address space, the routing and addressing architecture has Transport IP address (node) Identifier (NID), NID not changed to reflect location independence. The Identifier- Network IP address Locator (L64), L64 Locator Network Protocol (ILNP) is a host-based, end-to-end (interface) IP address dynamic binding ‘ID/Loc’ architecture. ILNP nodes do not use IP addresses * Fully Qualified Domain Name but instead use Node Identifier and topologically-significant The IP network layer and routing functions use the IP Locators. address to identify IP sub-networks, i.e. network location. Amultihomedhost(orsite)isconnectedtomorethanone Such use of IP addresses as locators requires that routers IP network. With IP today, multihoming and load balancing exchange information about IP address prefixes and the paths must be implemented within the routing infrastructure. In by which they may be reached, e.g. using routing protocols ‘ID/Loc’ architectures, these may be realised as a choice such as the Border Gateway Protocol (BGP). between network locations. ILNP advertises network location Transport layer communication protocols (such as TCP and values in the Domain Name System (DNS) [7]. Load balancing UDP) also use the IP address to identify nodes. In conjunction can be viewed as a choice between these locations (based on an with port numbers, these are used to uniquely identify sessions additional policy), and therefore may be implemented without between two hosts. However, as can be seen in Table I, the requiring support from network routers or ‘middleboxes’. It overloaded use of the IP address creates an implicit binding. is, effectively, a policy applied to the forwarding plane. Transport layer sessions become ‘bound’ to specific interfaces as they are established, making it difficult to separate location A. Contribution from identity within the current IP architecture. Host-based While ILNP is a radically different architecture, the claim approaches to the ‘ID/Loc’ split aim to disentangle these two is that it can be implemented on the current codebase, rather uses, which we discuss further in Subsec. IV-A and IV-J. than requiring a ‘clean-slate’ approach. We examine how the Multi-homing may be desirable for hosts, e.g. to achieve FreeBSD stack can be modified to implement ILNPv6 and robustness through diverse connectivity. However, it needs special treatment for IP [10]. Moreover, it contributes to rout- of network addresses. Compared to ILNPv6, HIP poses an ing table growth by requiring routers to advertise additional additional requirement for use of cryptographic identities, prefixes. This can be demonstrated by considering Fig. 1. Here, which may not be suited for all uses. Additionally, HIP asitenetworkusestwoprefixes,P1 and P2.Thesemustboth requires existing applications to be ported to a new API, while be visible upstream from the two ISPs, ISP1 and ISP2. ILNP can work with the existing sockets API (see later). Level 3 Multihoming Shim Protocol for IPv6 (SHIM6) [14] supports multihoming and traffic engineering for IPv6. SHIM6 is host-based and end-systems use two IPv6 address – one as an Identifier and one as a Locator. It is implemented as ashimunderneathIPv6transportprotocolAPIs.Afour-way handshake is used to establish a SHIM6 context (exchange of Identifier and Locator values), and separate security mecha- nisms are required to protect its signalling [15], [16]. The Locator/Identifier Separation Protocol (LISP) [17] pro- poses a complete routing architecture and is not host based. Fig. 1. Illustrative scenario for multihoming: a site network,withasiteborder router (SBR), connecting to two separate ISPs. We assume that,inthiscase, This has the advantage that end-host stacks do not need to the site network has two routing prefixes, P1 and P2. change. LISP’s Routing Locators (RLOCs) and Endpoint Iden- We assume that these prefixes are de-aggregated within tifiers (EIDs) re-use IP address values. LISP requires an in- the global routing table, i.e. that connectivity to each ISP is network mapping system between the two namespaces. LISP topologically diverse (common practice where BGP is used to uses a ‘map-and-encapsulate’ (map-encap) approach to for- multihome sites). Such prefixes are also known as Provider warding (i.e. tunnelling), creating an overlay mesh. Additional Independent (PI) prefixes, allocated to allow the user (the headers are interposed between existing IPv4 header fields, end site) to maintain use of these prefixes even if their ISP which are normally visible only to LISP-enabled routers. LISP changes. Therefore, ISP1 and ISP2, as well as upstream routers may require significant changes to some existing network must advertise these prefixes separately. This is because they routers (perhaps the deployment of new routers). The map- form part of the IP address, which is used in end-to-end state encap mechanism may impact existing applications, e.g. due (identity) for hosts – see Table I. It follows that the additional to MTU size issues, and use of tunnels. upstream routing state required for NP site prefixes with NI HIP, SHIM6 and ILNP are host-based ‘ID/Loc’ architec- upstream ISPs is O(NP .NI ). tures. These approaches push deployment costs mainly to Whilst we have used site multihoming in our example (as the end-user, though there may be impact to site networks, that is the more common case for IP today), a site would e.g. firewall configuration for new extension headers. Whilst need to support multihoming to allow individual hosts to be ILNP requires changes to the end-host stack, no shim layer multihomed, and the scalability analysis is the same. is required. It does not require additional IPv6 addresses for signalling its protocol state. ILNP does not use tunnelling. III. RELATED WORK IV. ILNPV6OVERVIEW Aexcellentsummaryofapproachestothe‘ID/Loc’split ILNP defines an ‘ID/Loc’ split architecture with experimen- is provided in RFC6115 [8]. These may be divided into two tal RFC status [9], [18]. It is specified for both IPv6 [19], [20] categories: network-based approaches which make the split and IPv4 [21]–[23] networks, i.e. ILNPv6 can be engineered as apropertyoftheroutinginfrastructure(leavingIPaddresses asetofextensionstoIPv6.Inthispaper,wediscussonlythose unchanged at hosts), and host-based approaches which make it aspects which apply to IPv6 hosts. As, architecturally, ILNP apropertyofhostaddressmanagement(possiblyintroducing is radically different from IP – there are no addresses in ILNP new namespaces or addresses). In line with the IETF’s current –ourimplementationconsiders(1)whatneedstochangein thinking regarding the ‘sunsetting’ of IPv4 [11], many of these current stack engineering in order to enable ILNPv6; and (2) consider only IPv6. So, we constrain ourselves here to consider what impact this could have on performance. This work has three proposals with similar intent and scope to those of ILNP. taken a dual-stack approach to implementation, as described The Host Identity Protocol (HIP) [12] supports multihoming further in RFC6740 [9] and RFC6741 [18]. and mobility. The ‘ID/Loc’ split is implemented using an Our implementation is based on FreeBSD 8.2, and is a asymmetric key crypto-system; Host Identifiers (HI) are public separate kernel module, ilnp6,withchangestotheexist- keys, Locators are IP addresses. Whilst a host can have many ing IPv6 stack.