Abstract - The increasing proliferation of mobile devices with

Internet access contributed to clarify some important limitations of

TCP/IP stack regarding mobility, multihoming, traceability and

security. In its original design, Internet IP addresses were

overloaded to simultaneously support host identification (ID) and

location (Loc). As a consequence, application functionality can be

affected when IP addresses are changed to update mobile nodes

location. This dual functionality causes many problems in the

current Internet, especially in supporting mobility. To deal with

this limitations several solutions based on the idea of ID/Loc

splitting have been proposed. In this position paper we present and

compare some of them, summarizing their main features and

limitations. We also identify opportunities and challenges for

future research in the area as well as expected impacts/relations

with other Future Internet aspects.

Keywords– ID/Loc splitting, mobility, location, identification,

multihoming.

I. INTRODUCTION

The Internet is underpinned by principles established for over 40 years, when memory resources, processing and communication were very limited. Its tremendous success and diversity of applications have made claims far beyond for what it was originally proposed. Its popularization in environments quite different from the time of its conception has placed in evidence many of its limitations, specially regarding scalability, mobility, multicast, multihoming, content distribution, unique identification and location of physical and logical network entities [1]. In general, the solution of these problems has been to create new protocols to patch the architecture. However, this approach has created a veritable "patchwork", which hinders the development of the network, preventing more meaningful solutions to existing problems. One of the main causes of these problems is the overload of IP addresses, since IP-based networks use a single address for both identification and location of hosts on the network. That is, the IP address has dual functionality. Ensuring mobility is a major challenge when designing a new generation network, i.e. ensuring that users can move not only within your local network, but also change the access network without loss of connectivity. Besides the logical coupling between hosts identifiers and locators, other challenges for mobility support are the management of mobile devices location data, the routing of packets to/from these devices, signaling the change from a home network to a visited one, and

finally the traceability of users and their terminals in the case of misconduct actions [2]. Multihoming means to have multiple simultaneous access connections for a network or host. Therefore, multiple locators must be used for the same network or host, at the same time. It enables access redundancy, load balancing and adequate provider selection. With ID/Loc splitting, IDs are used by the application and transport layers to identify a node, while the locators are used by network layer to logically locate them in the topology and route packets to/from the nodes. Based on this principle, several approaches were proposed in literature and standards. In this scenario, this paper aims to present, analyze qualitatively and discuss some of the ID/Loc splitting approaches, identifying opportunities for future research and summarizing their main features and limitations. The remaining of this paper is organized as follows. Section II presents some protocols and architectures for ID/Loc splitting; Section III discusses them, summarizing their main features and limitations; finally, in Section IV we conclude the paper.

II. PROTOCOLS AND ARCHITECTURES FOR ID/LOC SPLITTING

There exists several protocols and architectures for host ID/Loc splitting. The great majority is based in IP protocol. The Mobile IP, HIP (Host Identity Protocol), LISP (Locator ID Separation Protocol) and MILSA (Mobility and

Multihoming Supporting Identifier Locator Split

Architecture) are approaches that frequently appear in literature.

A. Mobile IP

The Mobile IP [3] (RFC-3344) was standardized by IETF (Internet Engineering Task Force) as an approach to provide IP devices mobility. The core idea is to designate two IP addresses for every device: (i) the home-address, which is a static address that works as an ID for the node at the application layer; and (ii) the care-of-address, which locates the node at the network layer. The latter is dynamically associated to node according to its current location on the network. The approach defines two basic components in the architecture: the local agent and the foreign agent, which are responsible to attribute respectively the home-address and the care-of-address. A mobile device receives periodic

Bruno Magalhães Martins

Instituto Nacional de Telecomunicações - Inatel P.O. Box 05 - 37540-000

Santa Rita do Sapucaí - MG - Brazil brunom@mtel.inatel.br

Antônio Marcos Alberti

Instituto Nacional de Telecomunicações - Inatel P.O. Box 05 - 37540-000

Santa Rita do Sapucaí - MG - Brazil alberti@inatel.br

Host Identification and Location Decoupling: A Comparison of Approaches

notification from an agent. It deduces it changed network when it stops to receive notifications from a local agent and it starts to receive notifications from a foreign agent [4]. The data sent to the Mobile Node (MN) are intercepted by the local agent, which is responsible to store its current location. The local agent encapsulates the data and retransmits them to the foreign agent at the visited network. The foreign agent retransmits the data to the MN. A mapping (or indirection) of the home-address with the respective care-of-address is required. Therefore, in Mobile IP devices can change its location without loss in connectivity. Figure 1 illustrates Mobile IP functionality.

Fig. 1. Mobile IP functionality.

Despite the mobility support offered by Mobile IP approach and its great popularity in cellular networks, in [4] it is shown that there is a considerable communication efficiency loss, since tunneling increases overhead. Besides efficiency, there is the triangular routing problem, where a packet destined to the MN needs to visit its home network before being routed to the current location. This introduces an extra delay, which could be very high for real time interactive communications. Mobile IPv6 avoids triangular routing using a routing optimization approach, where packets can be send directly to the care-of-address agent.

B. HIP – Host Identity Protocol

According to several references in literature [6][7][8], the standard Mobile IP does not fully solve the problems of mobility and safety on the Internet, because it relies on the IP routing to route packets, where a malicious user can impersonate another and make a Denial of Service (DoS) attack. For example, through false address notification messages. According to [8], there are three critical flaws in the current

Internet namespace. Firstly, the dynamic readdressing can not be managed directly; secondly, the anonymity can not be provided consistently and reliably; finally, there is no authentication for systems and packets. These deficiencies stem from the fact that the current computing platforms inefficiently use the current namespace. However, other proposals have been studied. HIP [8] (RFC

4423) is an alternative to Mobile IP protocol and it is based on creating a new namespace, which provides a static name to the host in order to uniquely identify them. Thus, a given IP address is used only for the location of host on the network

topology. Also, according to [8], the main idea of HIP is to create a

new namespace between network and transport layers of current Internet. This new layer – host identification layer – uses a host identifier (HI) to identify nodes in the network and to create a dynamic mapping with its locator (IP address). In other words, the host identification layer corresponds to an indirection point between the HI and the host locator. The communication between hosts using HIP is not tied to

the dual semantics of the IP address, allowing a host to be uniquely identified in the application and transport layers through the new namespace and located by IP address. Briefly, the HIP does not use the IP address as a node identifier, since it decouples upper layers from network layer Therefore, a node can move without losing its active connections. The host identity (HI) is static and globally unique. It was

developed thinking in the TCP/IP stack, but there is the possibility to use it with other protocol stacks. This feature makes HIP an interesting solution for post-IP or non-IP technologies. In addition, each HI is uniquely associated with a host and it is the result of a cryptographic hash function. The purpose of using encryption to create host identifiers is the possibility to authenticate connections in non-trusted networks. Moreover, the public key-based encryption allows each name to be considered statistically unique in a global environment. Figure 2 partially illustrates TCP/IP protocol stack (left) in

contrast to the new HIP protocol stack (right). In the latter, the host identifier and its locator are separated from each other. The IP address will continue to act as a locator, while the HI is responsible for identifying the end host.

Fig. 2. Current Internet (left) and HIP protocol (right) [6].

C. LISP – Locator Id Separation Protocol

LISP [9] is a proposal from Cisco Systems with a similar goal to those of HIP and Mobile IP protocols, i.e. to support mobility and multihoming in TCP/IP networks. However, LISP protocol is based on address mapping between edge and core IP networks and IP tunneling over UDP (User Datagram Protocol) for packet delivery. According to [9], LISP is a protocol used to implement IP address separation in EIDs (Endpoint Identifiers) and RLOCs (Routing Locators). This mechanism requires neither changes in the end hosts, nor changes in the infrastructure of existing databases.

LISP deployment occurs at edge routers of an IP network, whose IP addresses are used as routing locators (RLOC) for hosts on their domain. These routers are responsible for mapping EIDs on hosts locators [10]. Since the target domain has been determined by the ITR

(Ingress Tunnel Router), this router performs a search for a map in an RLOC EID to determine the routing path to the ETR (Egress Tunnel Router). Packets sent to the recipient are encapsulated (a datagram inserted into another) in the ITR with a new header, where the destination IP address in the datagram is configured as the destination RLOC IP address. This RLOC is responsible for routing to the destination domain. In the area of the recipient, the ETR will decapsulate the packet and route it according to the EID of the destination host. This process creates a tunnel between the edge routers. Figure 3 illustrates the operation of LISP.

Fig. 3. LISP functioning [11].

Consider the scenario of Figure 3, where the SourceNode

(EID = 1.0.0.1) wants to communicate with the DestinationNode (EID = 2.0.0.2). Since the ITR (RLOC = 11.0.0.1) knows the chosen destination ETR (RLOC = 12.0.0.2), it encapsulates the data containing the EID of SourceNode and sends them to the DestinationNode ETR. The ETR, in turn, receives data and forwards them to the DestinationNode through its EID 2.0.0.2. In other words, the SourceNode knows the EID identifier of the DestinationNode and the ITR knows ETR RLOC`s locator. Despite the overhead added by this encapsulation and the

inflexibility to use LISP in post-IP or non-IP architectures, there are many benefits achieved by separating the current address space in EIDs and RLOCs: (i) the routing table size reduction at the DFZ (Default-Free Zone); (ii) the multihoming support for sites that are connected to different service providers (in which they can control their own flow policies); and (iii) the easier IP readdressing when customers change service operators [9].

D. MILSA – Mobility and Multihoming Supporting

Identifier Locator Split Architecture

The MILSA architecture [7] was proposed as a solution to the problems of naming, addressing and routing in the current Internet. There are three principles adopted in MILSA: (i) separation of trust relations, called domains, and the relations of connectivity, called zones; (ii) separation between the functions of signaling and data plan, in order to improve

performance and to support mobility; (iii) separation of the identifier and locator to provide transparency to the application and transport layers. Also according to [7], a domain represents a group of

hosts in the same hierarchy and it is responsible for assigning the identifier for entities in its scope. Domains from the same hierarchy establish trust relations, while the zone is a topologically aggregated physical unit responsible for assigning and aggregating hosts connected to them. The logical link between a domain and a zone is

maintained by the RZBS (Zone Bridging Realm Server). This server can be designed considering particularities of a certain domain hierarchy. In other words, a domain authority is responsible for identifying hosts belonging logically to him, while a zone authority holds the information of one or more addresses or locators of such hosts. The RZBS takes care of mapping domains and zones, dynamically mapping host identifiers on locators. Figure 4 illustrates MILSA.

Fig. 4. MILSA conceptual architecture [7].

The two terminals MILSA user identifiers illustrated in

Figure 4 could be "User-1.Subdomain-1.Domain-A" and "User-2.Subdomain-2.Domain-B", respectively. The leftmost part of the identifier would be designed as flat and the rest of the name could be conceived in a hierarchical manner, in order to represent the logical position at the domain hierarchy. Figure 5 illustrates name composition in MILSA.

Fig. 5. MILSA name formation example.

The flat part of the name must be unique in the

subdomain to avoid conflicts and it can be created based on public key encryption or hash algorithms. If both users are in the same subdomain, there is no need to use full names, it is necessary, therefore, only the leftmost part of the name.

E. Akari ID/Loc Decoupling Approach

The Akari [1] project involves Japanese government, universities and the private sector to design and implement a new generation network by the year 2015. The project's motto is "a little light in the darkness that points to the

future" and its philosophy is to seek the ideal architecture for a new generation network. Akari Project has three basic principles that underlie the

creation of a new generation network: (i) the KISS (Keep It Simple, Stupid) principle, which states that the network layer should be kept as simple as possible; (ii) real world connection principle, which supports the interaction of the virtual world with the real world and that confirms the necessity identification and location decoupling; and (iii), the principle of sustainable development, which means that the network must become a free environment for progress and development, being able to meet society's demand for many decades [1]. The Akari proposed architecture uses distinct sets of

entities to identify and locate hosts on the network. However, this proposal is quite different from those previously mentioned, since it is independent of the interconnection technology. In other words, the solution proposed by the Akari project can be applied in post-IP or non-IP networks. Akari identifiers can be hierarchical or flat. Identifiers

hierarchically established can support greater network coverage and scalability as well as to provide tips to locators resolution. However, they may require a central authority to assign its hierarchical components. Moreover, the flat identifiers allow network nodes to create your identifiers autonomously. The project authors consider very important for both types of identifiers the deployment of a high availability identification/location mapping database [1]. Also according to Harai [1], a host can be identified by two

ways: by name and/or by its identifier (ID). A name can be local or global. Local names are unique on the local network and are used for host identification and network management. These names are generated by the combination of representative host related words, i.e. their function in context, owner, serial number or date and time of installation of the host on the network. Consider the protocol stack of Figure 6. The application

layer sends data to the transport layer through an interface identified by the primary source and destination IDs, in addition to the related application port number. The transport layer, in turn, inserts the transport header in the packet and sends it to the identity layer through another interface also identified the primary ID. In the identity layer, the primary identifier is mapped to an active identifier, which is inserted in the header of this layer. A second mapping between the active identifier and the host locators is also done by this identity layer. Then, this layer inserts the active identifier in the packet and sends this packet to the network layer through an interface identified by source and destination locators. Finally, the source and destination locators are entered into the network layer header and the packet is then sent to its destination.

F. MCP – Mobility Control Protocol

MCP is a South Korean approach to deal with host mobility in future networks. It was developed on the scope of MOFI (Mobile Oriented Future Internet) project. According to [14], hosts are uniquely and statically identified by a HID (Host Identifier). HIDs are obtained by a 128 bits hash function of a

host’s proprietary public key, in a process similar to what happens on HIP with the HIT (Host Identity Tag). Such HIDs are released on the network or to a name resolution system, while host’s proprietary private key is kept confidential to enable further authentication. The HID based delivery is used in access or edge networks. For global scale, MCP approach is to form HIDs hierarchically, including Autonomous System (AS) number [14]. To locate the backbone nearby some host, MCP uses a network locator (LOC). It is used to delivery data packets between core backbones. At the access or edge networks, HIDs are used to communicate. To support host mobility, network locator is updated to reflect its current position, while HID remains static. Mapping (or indirection resolution) between LOC and HID is dynamically done through a system called LBS (LOC Binding System). Figure 7 illustrates MCP protocol stack compared to TCP/IP.

Fig. 6. Akari proposal for an identity layer between transport and network layers. Adapted from [1].

Fig. 7. TCP/IP stack (left) compared to MCP (right).

MCP network layer is divided into two sublayers: host communication sublayer and packet delivery sublayer. Host communication contains two protocols: ADP (Access

Delivery Protocol) and BDP (Backbone Delivery Protocol), respectively used on access and backbone networks.

III. COMPARISON OF PRESENTED APPROACHES

The choice of the naming scheme is an important starting point in designing a network architecture, since many aspects (such as security and routing) are dependent on how the names are designed. Consider Mobile IP and LISP. Both are based on the current Internet hierarchical naming scheme. They divide IP address space in two hierarchical namespaces to support host ID/Loc splitting. On the other side, HIP uses a flat namespace to uniquely identify hosts and IP addresses to location them in the network topology. Moreover, MILSA and Akari identifiers are partially plane and partially hierarchical. MILSA identifiers are IP-based, but can be adapted to be used with another type of protocol. According to Harai [1], most of these approaches are based

on inflexible identifiers (using IP addresses), such as Mobile IP and LISP, or based on identifiers generated by public key cryptography, such as the HIP. The advantage of using IP-based identifiers is that current Internet applications can still be used without change. However, these approaches are inflexible and can not be used in post-IP or non-IP architectures. On the other side, identifiers based on public key cryptography or hash functions are long and unreadable for humans, despite its advantages in terms of security.

Akari identifiers are totally flexible, independent of the interconnection technology. In addition, they are created based on the result of a hash function of the host name, which in turn is legible and captures network hierarchical information at local and global level. Security support in Mobile IP uses IPSec, while LISP

security is based on the mapping process from EIDs to RLOCs. HIP, MILSA, Akari and MCP use the concept of cryptographic identities to encrypt information as a way of implementing security for packets transmission. Regarding mobility, Mobile IP does not provide

transparent support for mobility, i.e. to update the location of a mobile node the local agent must intervene creating the previously cited triangular routing. This fact implies in long waiting times while updating the location records. Also, it can cause packet loss. The routing optimization for Mobile IPv6 attempts to address such problem, but it requires considerable changes to both end hosts [7]. The LISP approach has some drawbacks such as

increased overhead and delays caused by the mapping of EIDs to RLOCs. Packet loss is also a concern. In HIP, packet loss can happen when two communication terminals move at the same time. Table 1 summarizes the comparisons between the main

features of ID/Loc splitting protocols.

TABLE I – ID/LOC SPLITTING COMPARISON TABLE. Mobile IP HIP LISP MILSA Akari MCP

�aming

Scheme

Hierarchical (IP); legible names.

Flat; opaque names. Hierarchical (IP); legible names.

Partially flat, partially hierarchical.

Flat with a hierarchical portion. Legible names for local and global names in the hierarchical part.

Flat, but hierarchical portion being studied to work world-wide.

Routing Only IP – Inflexible. IP, post-IP or non-IP – Flexible.

Only IP – Inflexible. IP routing. Can use ROFL. Partially flexible.

Fully flexible. Routing independent of transport technology.

IP, but can be adapted to become flexible.

Security IPSec. Public key cryptography. Deny of service problem.

Related to EID-RLOC mapping.

Public key cryptography.

Public key cryptography and hash function.

Public key cryptography and hash function.

Performance Increased overhead; triangular routing; waiting on update registration.

Overhead on host identifica-tion layer.

Increased overhead, latency in EID-RLOC mappings.

Overhead on HMS layer.

Overhead on identity layer. Overhead on HID-LOC mapping.

Packet loss Due to long waiting periods on record update.

When two terminals move at the same time.

Can occur due to mapping delay.

Not analyzed. Not analyzed. Not analyzed

IV. CONCLUSION

The host ID/Loc splitting is one of the most important solutions to address the shortcomings of mobility, multihoming, security, and other problems associated with dual functionality of IP addresses. Although there are today several proposals to separate the identification and location of networked devices, as Jianli describes in [7], most of them do not provide a comprehensive solution for the relationship among identifiers, names, locators and routing. In this position paper we have provided a qualitative

comparison among some important approaches for ID/Loc splitting. We can observe a great diversity of approaches. Some maintain compatibility with IP, but are unable to support experimentation and to be integrated with post-IP

Internet. All approaches are concerned with security aspects, but some of them restricted to current IP security solutions. Therefore, more holistic and integrated designs are required, e.g. to support trust networks; to accommodate information ID/Loc splitting; to support not only hosts mobility, but also other entities mobility; to enable automatic functionalities in order to reduce human intervention, etc. Finally, performance is a concern in approaches that use tunneling or dual addressing. The solutions that create new layers increase the overhead, decreasing efficiency. Is the approach to create new layers the best one? From this comparison, we identified some issues and

open research challenges: (i) what is the most appropriate name scheme for a new Internet: flat, hierarchical, mixed or

both? (ii) should routing be compatible with IP? (iii) how to support multi-path, multicast and anycast routing on these proposals? (iv) how to support millions or billions of networked devices in the so called Internet of Things (IoT)? In other words, how to enable scalability? (v) several proposals for a new Internet also perform information/location decoupling. How to create more holistic approaches for ID/Loc splitting and indirection resolution? (vi) how to analyze performance of these and other proposals? Many of these questions need to be answered.

REFERENCES

[1] HARAI, Hiroaki. et al. Akari (2007) ,ew Generation ,etwork

Architecture AKARI Conceptual Design (ver2.0), Available at project web site1 in March 2011.

[2] IN Min-kyo, LEE Seung-yun, KIM Dae-young. Splitting mechanism for

IP into Identifier and Locator in ,G,. 2007. [3] PERKINS C. RFC3344 - IP Mobility Support for IPv4. 2002. [4] RAMACHANDRAN, Kishore. Mobile IP - deployment after a decade.

2005. [5] JOHNSON D., PERKINS C. and ARKKO J. RFC 3775 Mobility

Support in IPv6. 2004. [6] BARBATO, Wander. A mobilidade na Internet com o padrão HIP.

2007. [7] JIANLI Pan, SUBHARTHI Paul, RAJ Jain, MIC Bowman. MILSA: A

Mobility and Multihoming Supporting Identifier Locator Split

Architecture for ,aming in the ,ext Generation Internet. 2008. [8] MOSKOWITZ, R. NIKANDER, P. RFC 4423 - Host Identity Protocol

(HIP) Architecture. 2006. [9] LEWIS, D.; MEYER, D.; FARINACCI, D.; FULLER, V. Locator/ID

Separation Protocol (LISP). Work in Progress. 2010. Disponível em http://tools.ietf.org/html/draft-ietf-lisp-06 LISP Draft 06, January 2010.

[10] IANNONE, L., SAUCEZ, D., BONAVENTURE, O., OpenLISP: An

Open Source Implementation of the Locator/ID Separation Protocol. 2009.

[11] MEYER, D. The Locator/Identifier Separation Protocol (LISP). The Internet Protocol Journal, Volume 11, No. 1. Available at http://www.cisco.com/web/about/ac123/ac147/archived_issues/ ipj_11-1/111_lisp.html. 2010.

[12] CAESAR Matthew, CONDIE Tyson, KANNAN Jayanthkumar, LAKSHMINARAYANAN Karthik, STOICA Íon. SHENKER Scott ROFL: Routing on Flat Labels. 2006.

[13] CAMPISTA, Miguel Elias M. et al., Interconexão de Redes na Internet do Futuro: Desafios e Soluções. 2010. Technical report available at author web site2 in March 2011.

[14] KIM Ji In and KOH Seok Joo . Mobility Control Protocol for MOFI. September 2010.

1http://akari-project.nict.go.jp/eng/conceptdesign.htm#Akari_6 2http://www.gta.ufrj.br/ftp/gta/TechReports/CFM10.pdf. 2010.