Network Working Group J. Bi Internet Draft Y. Wang Intended status: Experimental K. Gao Expires: November, 2014 Tsinghua University May 5, 2014 Implementation Experience of Identifier-Locator Network Protocol for IPv6 (ILNPv6) draft-bi-rrg-ilnpv6-implementation-experience-02 Abstract The Identifier-Locator Network Protocol (ILNP) defines an evolutionary enhancement to IP to address multi-homing, mobility as well as other issues. This document provides experience of implementing ILNPv6 which is a specific engineering instance of ILNP based on IPv6. This document describes the problems arisen and our choices to solve the issues which may be helpful to others in implementing the protocol. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 5, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Bi, et al. Expires November 5, 2014 [Page 1] Internet-Draft ILNPv6 Implementation Experience May 2014 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction...................................................2 1.1. Terminology...............................................3 2. An Alternative Way to Implement ILNPv6.........................3 2.1. Transport-layer Session State Modification................3 2.1.1. Locator Erasion/Refilling ............................3 2.1.2. Packet Sending .......................................4 2.1.3. Packet Receiving .....................................5 2.2. Identical Identifiers Management..........................5 3. Handling Special Cases.........................................6 3.1. Having Multiple Identifiers...............................6 3.1.1. A Global ILCC Table ..................................6 3.1.2. Independent ILCC Tables ..............................7 3.2. Missing Nonce Values......................................8 3.2.1. Avoid Both Identical Identifiers and Nonces ..........9 4. Other Considerations..........................................10 4.1. Path Selection Subsystem.................................10 4.2. SBR Extension............................................10 5. Security Considerations.......................................12 6. IANA Considerations...........................................12 7. Acknowledgments...............................................12 8. References....................................................13 8.1. Normative References.....................................13 8.2. Informative References...................................13 1. Introduction The Identifier-Locator Network Protocol (ILNP) [RFC6740] is an evolutionary protocol which addresses a wide range of issues including site/host multi-homing, site/host mobility, end-to-end security, etc. ILNP adopts an "Identifier/Locator Split" way to decouple end-to-end transport-layer session state from interfaces and addresses of a node. ILNPv6 is a specific engineering instance of ILNP that is based on IPv6. [RFC6741], [RFC6743] and [RFC6744] describe engineering considerations about ILNPv6 implementation which needs modifications to the protocol stack of hosts. This document describes issues that arise in implementing ILNPv6 according to existing specifications Bi, et al. Expires November 5, 2014 [Page 2] Internet-Draft ILNPv6 Implementation Experience May 2014 together with possible solutions. This document only provides an alternative way to develop ILNPv6 based on Linux, and the goal is to offer experiences which may help the readers to make their own implementations of the protocol. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. Some terms used in this document are defined in [RFC6740]. This document assumes that the reader has read the related RFC: Identifier-Locator Network Protocol (ILNP) Architectural Description [RFC6740]. 2. An Alternative Way to Implement ILNPv6 This section discusses the implementation challenges and alternative ways to overcome these challenges. The implementation described in this section is based on modifying GNU/Linux kernel 3.2.12. 2.1. Transport-layer Session State Modification One of the biggest challenges in implementing ILNPv6 is how to maintain transport-layer session state. As is specified in [RFC6740], transport layer on an ILNP node uses only the Identifier value (64 bits suffix of IPv6 address) for the transport-layer session state, while current TCP and UDP use the entire IPv6 address as the session state. 2.1.1. Locator Erasion/Refilling There exist different ways to realize the modification, and the choice proposed in this document is to hide locator values (64 bits prefix of IPv6 address) from the transport layer by adopting locator erasion/refilling. The benefit of this method is that the transport layer will stay untouched while modifications are almost only required in the network layer. Locator erasion requires the network layer to erase the locator part of received ILNP packets (zero the 64 bits prefix) before sending them to the transport layer. The transport layer still regards the packets with zero prefixes as ordinary IPv6 packets and processes them normally. Since the IPv6 address within ILNP packet headers in transport layer contains only Identifier information, Locator changes Bi, et al. Expires November 5, 2014 [Page 3] Internet-Draft ILNPv6 Implementation Experience May 2014 in the network layer will never affect the session states of transport layer protocols. Locator refilling requires the network layer to refill the locator part of outgoing ILNP packets from the transport layer. The locator information is obtained from ILCC introduced in [RFC6740]. After the refilling process, ILNP packets will be forwarded normally as ordinary IPv6 packets. In order to make the implementation compatible with existing Linux IPv6 socket API, Locator erasion/refilling also requires the socket layer to erase the locator part of ILNP packets before sending them to the transport layer and refill the locator part of ILNP packets received from the transport layer. The procedures of Locator erasion/refilling in both packet sending and receiving are shown in Figure 2.1 and described separately in the next two sub-sections. | | +-------------------+ Locator + Identifier | | /\ | | Socket layer | Locator | | Locator +-------------------+ Refilling| \/ Erasion | Transport layer | Zero + Identifier +-------------------+ /\ | | | Locator | | Locator | Network layer | Erasion | \/ Refilling | | Locator + Identifier +-------------------+ /\ | | | | \/ Figure 2.1: Locator Erasion/refilling Procedure in protocol stack 2.1.2. Packet Sending The socket API stays unchanged in this implementation, but the IP addresses maintained in socket are processed by Locator erasion function and are equivalent to Identifiers. Thus data packets delivered to the transport layer do not contain Locator information. Then packets get through the unmodified transport layer and reach the network layer. To handle ILNP packets from the transport layer, modifications are made in the network layer. For each ILNP packet, the network layer Bi, et al. Expires November 5, 2014 [Page 4] Internet-Draft ILNPv6 Implementation Experience May 2014 looks up in the ILCC to get available Locator set and fills the 64 bits prefix of the IPv6 address in the packet header. Locator refilling is achieved using Netfilter Hook in this implementation. Specifically, the Locator part is refilled in NF_IP_LOCAL_OUT. After the refilling, ILNP packets will be forwarded as normal IPv6 packets. 2.1.3. Packet Receiving For each incoming ILNP packet, the network layer needs to judge whether it should be delivered to upper layer protocols for further processing. According to the implementation of Linux IPv6 protocol stack, this is achieved by adding related entries in the routing table. Thus all possible IL-Vectors MUST be added into the table and set as local entries to ensure that all ILNP packets can be correctly received. For each packet whose destination is a local socket, the network layer sets the 64 bits prefix of the IPv6 address in the header to zero and transmit it to the transport layer. Locator erasion is also achieved using Netfilter Hook NF_IP_LOCAL_IN. The packet will be handled normally by the transport layer and then go to the corresponding socket and finally reach the destined application. 2.2. Identical Identifiers Management If an ILNP node simultaneously has two or more correspondents nodes with identical Identifiers, additional information is required in the transport layer to lookup sockets. [RFC6740] suggests using Locator values to distinguish between correspondent nodes that have identical Identifier value when delivering ILNP packets to applications. In current Linux IP/TCP implementation, the sockets are hashed globally with IP addresses and ports of both the local and remote nodes. Thus, if we simply use the combination of both Identifiers and Locators to lookup sockets, a large space may be required as all possible local-remote Locator pairs must be taken into consideration. Besides, since the lookup is performed in the transport layer, Locator values are no longer transparent which violates the intention of hiding Locator information from transport layer in this implementation. This document provides an alternative way for socket lookup in the transport layer. Since using Identifier value alone is not able to uniquely identify correspondent of an ILNP node, a local number called Peer Index (PI) for an ILNP peer is introduced. Different from Identifier, the local uniqueness of PI can be ensured. Thus the transport layer is able to use the tuple Bi, et al. Expires November 5, 2014 [Page 5] Internet-Draft ILNPv6 Implementation Experience May 2014 to uniquely identify a local socket. There are different ways to generate PI and one simplest method is to use a counter which increases along with the number of ILNP correspondents. The bindings between PIs and other information of the correspondent node (including its Identifier, Locator set, nonce, etc.) is stored in a hash table in the network layer. There are two ways to get the PI value of a correspondent node: use its Identifier-Locator pair and Identifier-Nonce pair to lookup in the hash table. Thus the disadvantage of this method is that we may have to make three lookups instead of one. 3. Handling Special Cases This section discusses some special cases in implementing ILNPv6. The ways to handle these cases are not described in the existing ILNP specifications and in this document we propose possible methods to deal with them. We believe that the issues discussed in this section need to be solved not only in Linux-based ILNP implementation, but also in other ways to implement the protocol. 3.1. Having Multiple Identifiers As specified in [RFC6740], one ILNP node may have multiple Identifier values that are associated with it and used concurrently. One scenario is that multiple virtual nodes are located on one physical device. This specification has impact on the implementation of the ILCC on an ILNP node. [RFC6741] suggests that ILCC should contain both information (Identifier values, Locator values, IL-Vectors and Nonce values) of the local node and correspondent nodes but does not specify the ways to organize the information. We discuss the following to methods separately. 3.1.1. A Global ILCC Table A straight forward method is to maintain a global ILCC table on each ILNP node. This method may work well if each ILNP node uses only one Identifier value at the same time. However, having multiple Identifiers but one ILCC table may lead to inconsistency and conflicts. Considering the scenario shown in Figure 3.1, an ILNP host H uses both Identifier IH1 and IH2 to communicate with correspondent node C Bi, et al. Expires November 5, 2014 [Page 6] Internet-Draft ILNPv6 Implementation Experience May 2014 simultaneously. Since each Identifier represents a logical end point in the network, there is no way node C can be aware that the two identifiers resides in one node. Thus node C is likely to have different Nonce values for each Identifier for security reasons, and there is a high chance that C appears as two different nodes in node H's ILCC. [RFC6741] suggest using tuple as the lookup key in ILCC lookups, but in this situation, the 'two nodes' in H's ILCC will share exactly the same locator set. Thus H is not able to distinguish the correct correspondent node for packets without NONCE as they share the same tuple. +--------------+ ...... | Host H | . . | +----------+ | . . | |ID IH1 | | . . +-----------------+ | |Locator LH|-|-----. . | Correspondent C | | +----------+ | . . | | | | . Internet .----+ ID IC | | +----------+ | . . | Locator LC | | |ID IH2 |-|-----. . | | | |Locator LH| | . . +-----------------+ | +----------| | . . +--------------+ ...... Figure 3.1: Having Multiple Identifiers on One ILNP Node 3.1.2. Independent ILCC Tables Since one ILNP node could be equipped with several Identifiers, it is natural to set up an ILCC table for each one of them. Independent ILCC tables avoid the potential conflicts by using local information (Identifier_local and Locator_local) in ILNP packets when performing ILCC lookups. Another reason to choose Independent ILCC tables is that a global ILCC would cost as much memory as independent ones when processing the same number of possible Locator Update messages. One possible implementation of independent ILCC tables is shown in Figure 3.2. First we introduce Association as a data structure that stores information of an ILNP-based network-layer session (PI, Identifiers, Locators and Nonces of both local and remote nodes). We call each independent ILCC table a Cache which stores the Associations of all remote nodes that correspondent to a local Identifier. Finally all Caches constitute the local ILCC table. Bi, et al. Expires November 5, 2014 [Page 7] Internet-Draft ILNPv6 Implementation Experience May 2014 When looking up in the ILCC, the local Identifier is firstly used as the key to find a corresponding Cache. Then both Identifier_remote- Locator_remote pair and Identifier_remote-Nonce_remote pair can be used as key to find an Association. top layer: ILCC | | \/ 1st layer: Cache | or | \/ 2nd layer: Association Figure 3.2: Implementation of Independent ILCC Tables 3.2. Missing Nonce Values In the initial phase of a session between two ILNP nodes, it is possible that one side does not know the Nonce value generated by the other side for the session (for example, when no packet is sent from the other side). This case has impact on the ILCC lookup rules. [RFC6741] specifies that when looking up into the ILCC, tuple MUST be used as the lookup key if Nonce Option in contained in the packet. Otherwise, tuple MUST be used as the lookup key. However, for the packet from a remote node whose Nonce value is unknown to the local node, the lookup rule MUST be changed to: 1. Drop any received packet without Nonce Option, since [RFC6744] specifies that initial packet(s) to correspondent ILNP nodes MUST include Nonce Option. 2. For received packet with a Nonce Option, store the Nonce value in local ILCC and deliver the packet normally. After the Nonce value is acquired from the remote node, follow-up packets from the remote node MUST be processed using the normal lookup rule. Bi, et al. Expires November 5, 2014 [Page 8] Internet-Draft ILNPv6 Implementation Experience May 2014 3.2.1. Avoid Both Identical Identifiers and Nonces A special case in handling missing Nonce values is shown in Figure 3.3 where Host H is communicating with two correspondent nodes C1 and C2 with identical Identifiers. In this case, H has an on-going session with C1 while is initiating another session with C2 and has not yet get Nonce from it. ...... . . +------------------+ . . | Correspondent C1 | . .----| ID IC | +--------+ . . | Locator LC1 | | | . . +------------------+ | Host H |------. Internet . | | . . +------------------+ +--------+ . . | Correspondent C2 | . .-----| ID IC | . . | Locator LC2 | ...... +------------------+ Figure 3.3: A Special Case in Dealing with Missing Nonce Values If the Nonce value generated by C2 happens to be the same to the Nonce of C1 which is stored in H's ILCC, C1 and C2 will share both the same Identifier and Nonce. This situation MUST be avoided because it makes C1 and C2 undistinguishable when their Locators change. One way to handle the special case is to send an ICMP error message to C2 if it generates the same Nonce as C1. After receiving the ICMP error message, C2 should re-generate another Nonce value. Consequently, the lookup rule in this case is changed to: 1. Drop any received packet without Nonce Option. 2. For received packet with a Nonce Option, lookup into the ILCC using as the key. If no entry is found, store the Nonce value in local ILCC and deliver the packet normally. Otherwise send an ICMP error message to the remote node indicated by . Considering the scenario in Figure 3.3, there is another method to prevent C2 from generating the same Nonce value as C1: when initiating a session with C2, H informs C2 of the Nonce generated by C1, thus C2 can avoid generating the same value. However, Bi, et al. Expires November 5, 2014 [Page 9] Internet-Draft ILNPv6 Implementation Experience May 2014 modifications to session establishment process is required using this method. 4. Other Considerations 4.1. Path Selection Module We suggest introducing a path selection module into ILNP for better performance, especially for a multi-homing node. This module maintains the best Locator pairs of the local node and its correspondent node based on user-defined policy or other criteria such as longest matching prefixes. These maintained Locator pairs can be used to accelerate the process of selecting Locators when transmitting ILNP packets. This module MUST respond to basic ICMP messages that have an impact on the status of Locators, like Locator Update or Router Advertisement. Also, it COULD gather information from incoming/outgoing packets to enable features like load balancing. 4.2. SBR Extension According to the specifications in [RFC4830], ILNP is a global mobility protocol as it needs to change end-to-end route by sending Locator Update messages from the Mobile Node (MN) directly to all its Correspondent Nodes (CN) after network-layer handover. Thus, ILNP cannot avoid the drawbacks of such protocols: the first is heavy signaling overhead especially on the wireless links, since the number of Locator Update packets sent per handover is proportional to the number of CN; the second is large handover latency which grows with the increasing of MN-to-CN distance and may lead to high packet loss; the third is location privacy since IP address(es) of the MN are always exposed to the correspondents. Location privacy issue is addressed in [RFC6748], thus we suggest another extension to address the performance issues, i.e. the overhead and latency due to propagation and processing of Locator Update messages. We note that [RFC6748] has already utilized ILNP- capable Site Border Router (SBR) to realize localized numbering, here we further use SBR to localize Locator Update. Considering the scenario in Figure 4.1, a site network with SBR and Locator value L_1 is divided into two sub networks, e.g. sub network 1 with local Locator value L_La and sub network 2 with local Locator value L_Lb. When an MN moves from sub network 1 to sub network 2, according to the specifications in [RFC6748], the MN needs to change both its Global Locator L_1 and local Locator L_L. Therefore, even if Bi, et al. Expires November 5, 2014 [Page 10] Internet-Draft ILNPv6 Implementation Experience May 2014 the MN is roaming within a site network using localized numbering, the CN needs to be aware of Locator changes of the MN. We propose an alternative way to handle intra-site network mobility by keeping Global Locator of the MN unchanged when it moves among different sub networks within the same site network. In scenario shown in Figure 4.1, CN always learns the IL-Vector of MN as [I_H, L_1]. When packets destined to the MN arrive at the SBR, it rewrites the Locator part of each packet to a local Locator value (L_La or L_Lb in this example). During this process, SBR functions similarly to the Locator Rewriting Relay (LRR) proposed in [RFC6748], but LRR is introduced only for Location privacy issues. sub network 1 ..... . . . .L_La ........ . MN .---- . . +----+ . . \ . .----| CN | . . \ +---------+ . Internet . +----+ ..... ----| | L_1 . . + +-----. . ..... ----| | . . . . / +---------+ . . . .L_Lb/ SBR . . . MN' .---- . . . . ........ . . ..... sub network 2 CN = Correspondent Node MN = Mobile Node MN' = Mobile Node after movement L_1 = global Locator value L_La = local Locator value a L_Lb = local Locator value b SBR = Site Border Router Figure 4.1: Utilize ILNP-capable SBR to localize Locator Update To decide which local Locator should be used, SBR needs to maintain a mapping table locally which stores mappings from Identifier and global Locator values of the MN to its current local Locator value. Bi, et al. Expires November 5, 2014 [Page 11] Internet-Draft ILNPv6 Implementation Experience May 2014 An example of the mapping table for SBR in Figure 4.1 has the following form: src=[I_H, L_La], L_1 ---1(a) dst=[I_H, L_1], L_La ---1(b) Expression 1(a) says that for packets with src IL-V [I_H, L_La], its source Locator should be rewritten to L_1. Similarly, expression 1(b) says for packets with dst IL-V [I_H, L_1], its destination Locator should be rewritten to L_La. After the MN moves to another sub network within the same site network and changes its local Locator value, the MN is responsible to inform the SBR of its new local Locator value using Locator Update message. Therefore, instead of sending a Locator Update message to each CN, the MN only needs to send one Locator Update message to the SBR in this scenario, which reduces propagation and processing cost of Locator Update messages. 5. Security Considerations TBD. 6. IANA Considerations There is no IANA Consideration currently. 7. Acknowledgments Thanks to Cisco University Research Program for sponsoring the work. Thanks to Tony Li for guidance and suggestions on the implementation. Bi, et al. Expires November 5, 2014 [Page 12] Internet-Draft ILNPv6 Implementation Experience May 2014 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6740] Atkinson, R. and S. Bhatti, "Identifier-Locator Network Protocol (ILNP) Architectural Description", RFC 6740, November 2012. [RFC6741] Atkinson, R. and S. Bhatti, "Identifier-Locator Network Protocol (ILNP) Engineering and Implementation Considerations", RFC 6741, November 2012. [RFC6743] Atkinson, R. and S. Bhatti, "ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv6 (ILNPv6)", RFC 6743, November 2012. [RFC6744] Atkinson, R. and S. Bhatti, "IPv6 Nonce Destination Option for the Identifier-Locator Network Protocol for IPv6 (ILNPv6)", RFC 6744, November 2012. [RFC6748] Atkinson, R. and S. Bhatti, "Optional Advanced Deployment Scenarios for the Identifier-Locator Network Protocol (ILNP)", RFC 6748, November 2012. [RFC4830] Kempf, J., "Problem Statement for Network-Based Localized Mobility Management (NETLMM)", RFC 4830, April 2007. 8.2. Informative References Bi, et al. Expires November 5, 2014 [Page 13] Internet-Draft ILNPv6 Implementation Experience May 2014 Authors' Addresses Jun Bi Tsinghua University Network Research Center, Tsinghua University Beijing 100084 China EMail: junbi@cernet.edu.cn You Wang Tsinghua University Network Research Center, Tsinghua University Beijing 100084 China EMail: wangyou10@mails.tsinghua.edu.cn Kai Gao Tsinghua University Network Research Center, Tsinghua University Beijing 100084 China EMail: godrickk@gmail.com Bi, et al. Expires November 5, 2014 [Page 14]