Internet DRAFT - draft-bi-rrg-ilnpv6-implementation-experience

draft-bi-rrg-ilnpv6-implementation-experience








 
Network Working Group                                             J. Bi 
Internet Draft                                                  Y. Wang 
Intended status: Experimental                                    K. Gao 
Expires: November, 2016                             Tsinghua University
                                                            May 1, 2016
																	  
 
  Implementation Experience of Identifier-Locator Network Protocol for 
                             IPv6 (ILNPv6) 

              draft-bi-rrg-ilnpv6-implementation-experience-06

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 2, 2016.

Copyright Notice 

   Copyright (c) 2013 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 2, 2016               [Page 1]
 
Internet-Draft     ILNPv6 Implementation Experience           May 2016
	

   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. 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 2, 2016               [Page 2]
	
Internet-Draft     ILNPv6 Implementation Experience           May 2016
	

   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 2, 2016               [Page 3]
	
Internet-Draft     ILNPv6 Implementation Experience           May 2016
	

   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 2, 2016               [Page 4]
	
Internet-Draft     ILNPv6 Implementation Experience           May 2016
	

   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 2, 2016               [Page 5]
	
Internet-Draft     ILNPv6 Implementation Experience           May 2016
	

   <PI_local, PI_remote, Port_local, Port_remote> 

   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. 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 two 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 2, 2016               [Page 6]
	
Internet-Draft     ILNPv6 Implementation Experience           May 2016
	

   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 <Locator_remote, Identifier_remote> 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 <LC, IC> 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 2, 2016               [Page 7]
	
Internet-Draft     ILNPv6 Implementation Experience           May 2016
	

   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 
                        |    
                        |  <Identifier_local> 
                        \/ 
     1st layer:       Cache 
                        |  <Identifier_remote, Locator_remote> or 
                        |  <Identifier_remote, Nonce_remote> 
                        \/  
     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, <Identifier_remote, Nonce_remote> 
   tuple MUST be used as the lookup key if Nonce Option in contained in 
   the packet. Otherwise, <Identifier_remote, Locator_remote> 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 2, 2016               [Page 8]
	
Internet-Draft     ILNPv6 Implementation Experience           May 2016
	

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 <Identifier_remote, Nonce_remote> 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 <Identifier_remote, Locator_remote>.  

   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 2, 2016               [Page 9]
	
Internet-Draft     ILNPv6 Implementation Experience           May 2016
	

   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 potential 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 its 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 2, 2016              [Page 10]
	
Internet-Draft     ILNPv6 Implementation Experience           May 2016
	

   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 2, 2016              [Page 11]
	
Internet-Draft     ILNPv6 Implementation Experience           May 2016
	

   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 2, 2016              [Page 12]
	
Internet-Draft     ILNPv6 Implementation Experience           May 2016
	

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 2, 2016              [Page 13]
	
Internet-Draft     ILNPv6 Implementation Experience           May 2016
	

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: gaok12@mails.tsinghua.edu.cn 
	























 
 
Bi, et al.             Expires November 2, 2016              [Page 14]