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]