Internet Draft RJ Atkinson
draft-irtf-rrg-ilnp-eng-00.txt Consultant
Expires: 09 JUL 2012 SN Bhatti
Category: Experimental U. St Andrews
9 January 2012
ILNP Engineering Considerations
draft-irtf-rrg-ilnp-eng-00.txt
Status of this Memo
Distribution of this memo is unlimited.
Copyright (c) 2012 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
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.
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before
November 10, 2008. The person(s) controlling the copyright in
some of this material may not have granted the IETF Trust the
right to allow modifications of such material outside the IETF
Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process,
and derivative works of it may not be created outside the IETF
Standards Process, except to format it for publication as an RFC
or to translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
Atkinson & Bhatti Expires in 6 months [Page 1]
Internet Draft ILNP Eng 09 JUL 2012
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This document is not on the IETF standards-track and does not
specify any level of standard. This document merely provides
information for the Internet community.
The ILNP document set has had extensive review within the IRTF
Routing Research Group. ILNP is one of the recommendations made
by the RG Chairs. Separately, various refereed research papers
on ILNP have also been published during this decade. So the
ideas contained herein have had much broader review than
IRTF Routing RG. The views in this document were considered
controversial by the Routing RG, but the RG reached a consensus
that the document still should be published. The Routing RG has
had remarkably little consensus on anything, so virtually all
Routing RG outputs are considered controversial.
Abstract
This document describes common (i.e. version independent)
engineering details for the Identifier-Locator Network Protocol
(ILNP), which is an experimental, evolutionary enhancement to IP.
This document is a product of the IRTF Routing RG.
Table of Contents
1. Introduction ..........................................2
2. Generating Identifiers.................................3
3. Transport-Layer Changes................................?
4. ILNP Correspondent Cache...............................?
5. Handling Location/Connectivity Changes.................?
6. Secure Dynamic DNS Update..............................?
7. Backwards Compatibility................................?
8. Incremental Deployment.................................?
9. Security Considerations ..............................21
10. IANA Considerations...................................28
11. References ...........................................28
1. INTRODUCTION
Atkinson & Bhatti Expires in 6 months [Page 2]
Internet Draft ILNP Eng 09 JUL 2012
The Identifier Locator Network Protocol (ILNP) is an experimental
network protocol that provides evolutionary enhancements to
IP. ILNP is backwards-compatible with IP and also is
incrementally deployable. The best starting point for learning
about ILNP is the ILNP Architectural Description, which includes
a document roadmap [ILNP-ARCH].
ILNP is a single architecture that can have multiple
instantiations. Engineering considerations common to all
instantiations of ILNP are described in this document. Packet
formats and certain other IPv4-centric details of ILNP for IPv4
(ILNPv4) are specified in separate documents [ILNP-v4opts]
[ILNP-ICMPv4]. Packet formats and certain other IPv6-centric
details of ILNP for IPv6 (ILNPv6) are specified in separate
documents [ILNP-NONCE6] [ILNP-ICMPv6].
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].
2. ILNP IDENTIFIERS
All ILNP nodes must have at least one Identifier value. However,
there are various options for generating those Identifier
values. We describe in this section the relevant engineering
issues related to Identifier generation and usage.
Note well that ILNP Identifiers name an ILNP-capable node, and
are NOT bound to a specific interface of that node. So a given
ILNP Identifier is valid on all active interfaces of the node to
which that ILNP Identifier is bound. This is true even if the
bits used to form the Identifier value happened to be taken from
a specific interface as an engineering convenience.
2.1 Syntax
ILNP Identifiers are always unsigned 64-bit strings, and may be
realised as 64-bit unsigned integers. Both ILNPv4 and ILNPv6 use
the Modified EUI-64 syntax that is used by IPv6 Interface
Identifiers, as shown in Figure 1.
+--------------------------------------------------+
| 6 id bits | U bit | G bit | 24 id bits |
+--------------------------------------------------+
| 32 id bits |
+--------------------------------------------------+
Atkinson & Bhatti Expires in 6 months [Page 3]
Internet Draft ILNP Eng 09 JUL 2012
Figure 1. IEEE EUI-64 format as used for IPv6 [RFC4291, Sec 2.5.1].
That syntax contains two special reserved bit flags. One flag
(the U bit) indicates whether the value has "universal"
(i.e. global) scope (1) or "local" (0) scope. The other flag (the
G bit) indicates whether the value is an "individual" address (1)
or "group" (i.e multicast) (0) address.
However, this format does allow other values to be set, by use of
administrative or other policy control, as required, by setting
the U bit to "local".
2.1 Default values for an Identifier
By default, this value, including the U bit and G bit, are set as
described in Appendix A of RFC4291 [RFC4291]. Where no other
value of Identifier is available for an ILNP node, this is the
value that MUST be used.
Because ILNP Identifiers might have local scope, and also to
handle the case where two nodes at different locations happen to
be using the same global scope Identifier (e.g. due to a
manufacturing fault in a network chipset or card), implementers
must be careful in how ILNP Identifiers are handled within an end
system's networking implementation. Some details are discussed in
Section 4 below.
2.2 Local-scoped Identifier values
ILNP Identifiers for a node also MAY have the Scope bit of the
Modified EUI-64 set to "local"" scope. Locally unique identifiers
MAY be Cryptographically Generated, created following the
procedures used for IPv6 Cryptographically Generated Addresses
(CGAs) [RFC3972] [RFC4581] [RFC4982].
Also, locally unique identifiers MAY be used to create the ILNP
equivalent to the "Privacy Extensions for IPv6", generating ILNP
Identifiers following the procedures used for IPv6 [RFC4941].
2.3 Multicast Identifiers
An ILNP Identifier with the G bit set to "group" names an ILNP
multicast group, while an ILNP Identifier with the G bit set to
"individual" names an individual ILNP node. However, this usage
of multicast for Identifiers for ILNP is currently undefined:
Atkinson & Bhatti Expires in 6 months [Page 4]
Internet Draft ILNP Eng 09 JUL 2012
ILNP uses IPv6 multicast for ILNPv6 and IPv4 multicast for ILNPv4
and uses the multicast address formats defined as
appropriate. The use of multicast Identifiers and design of an
enhanced multicast capability for ILNPv6 and ILNPv4 is currently
work in progress.
3. TRANSPORT-LAYER CHANGES
ILNP uses an Identifier value in order to form the invariant
end-system state for end-to-end protocols. Currently, transport
protocols such as TCP and UDP use all the bits of an IP address
to form such state. So, transport protocol implementations MUST
be modified in order to operate over ILNP.
3.1 End-system state
Currently, TCP and UDP, for example, use the 4-tuple:
<local IP address, remote IP address, local port, remote port>
for the end-system state for a transport layer end-point. For
ILNP, implementations must be modified to instead use:
<local Identifier, remote Identifier, local port, remote port>
3.2 Pseudo-header checksum
In IP-based implementations, the TCP or UDP pseudo-header
checksum calculations include all the bits of the IP address.
By contrast, when calculating the TCP or UDP pseudo-header
checksums for use with ILNP, only the Identifier values are
included in the TCP or UDP pseudo-header checksum calculations.
To minimise the changes required within transport protocol
implementations, and to maximise interoperability, current
implementations are modified to zero the Locator fields (only for
the purpose of TCP or UDP checksum calculations). For example,
for ILNPv6, this means that the existing code for IPv6 can be
used, with the ILNPv6 Identifier bits occupying the lower 64 bits
of the IPv6 address field, and the upper 64 bits of the IPv6
address filed being set to zero. For ILNPv4, the Identifier
fields are carried in an IPv4 Option [ILNP-v4opts].
Section 7 describes methods for incremental deployment of this
ILNP-specific change and backwards compatibility with non-
upgraded nodes (e.g. classic IPv4 or IPv6 nodes) in more detail.
Atkinson & Bhatti Expires in 6 months [Page 5]
Internet Draft ILNP Eng 09 JUL 2012
4. ILNP CORRESPONDENT CACHE (ILCC)
For operational purposes, implementations need to have a local
cache of state information that allow communication end-points to
be constructed and for communication protocols to operate. Such
cache information is common today, e.g. IPv4 nodes commonly
maintain an Address Resolution Protocol (ARP) cache with
information relating to current and recent Correspondent Nodes;
IPv6 nodes maintain a Neighbor Discovery (ND) table with
information relating to current and CNs. Likewise, ILNP maintains
an Identifier-Locator Correspondent Cache (ILCC) with information
relating to the operation of ILNP.
The ILCC is a (logical) set of data values required for ILNP to
operate. These values are maintained by the endpoints of each
ILNP communications session. From an engineering viewpoint, the
ILCC could be implemented by extending or enhancing existing data
structures within existing implementations. For example, by
adding appropriate flags to the data structures in existing
implementations.
In theory, this cache is within the ILNP network-layer. However,
many network protocol implementations do not have strict protocol
separation or layering. So there is no requirement that the ILCC
be kept partitioned from transport-layer protocols.
4.1 Formal Definition
The ILCC contains information about both the local node and also
about current or recent correspondent nodes, as follows.
Information about the local node:
- Each currently valid Identifier value,
including its Identifier Precedence
and whether it is active at present.
- Each currently valid Locator value, including
its associated local interface(s),
its Locator Precedence, and
whether it is active at present.
- Each currently valid IL Vector (IL-V), including
whether it is active at present.
Information about each correspondent node:
- Most recent set of Identifiers,
Atkinson & Bhatti Expires in 6 months [Page 6]
Internet Draft ILNP Eng 09 JUL 2012
including lifetime and validity for each.
- Most recent set of Locators,
including lifetime and validity for each.
- Nonce value for packets from the local host
to the correspondent.
- Nonce value for packets from the correspondent
to the local host.
In the above list for the ILNP Correspondent Cache:
- A "valid" item is useable, from an administrative point of
view, but might or might not be in use at present.
- The "validity" parameter for the correspondent node indicates
one of several different states for a datum. These include at
least the following:
- "valid" : data is useable and has not expired.
- "active" : data is useable, has not expired,
and is in active use at present.
- "expired" : data is still in use at present,
but is beyond its expiration (i.e.
without a replacement value).
- "aged" : data was recently in use, but is not
in active use at present, and is
beyond its expiration.
- The "lifetime" parameter is an implementation-specific
representation of the validity lifetime for the associated
data element. In normal operation, the Lifetime for a
correspondent node's Locator(s) are learned from the DNS
Time-To-Live (DNS TTL) value associated with DNS records
(ID, L32, L64 etc) of the FQDN owner name of the
correspondent node. For time, a node might use UTC
(e.g. via Network Time Protocol) or perhaps some
node-specific time (e.g. seconds since node boot).
4.2 Aging ILCC Entries
As a practical matter, it is not sensible to flush all Locator
values associated with an existing session's correspondent node
Atkinson & Bhatti Expires in 6 months [Page 7]
Internet Draft ILNP Eng 09 JUL 2012
even if the DNS TTL associated with those Locator values expires.
In some situations, a CN might be disconnected briefly when
moving location (e.g. immediate handover). If this happens, there
might be a brief pause before the Correspondent Node can (a)
update its own L values in the DNS and (b) send an ICMP Locator
Update message to the local node with information about its new
location. Implementers ought to try to maintain ILNP sessions
even when such events occur.
Instead, Locator values cached for a correspondent node SHOULD be
marked as "aged" when their TTL has expired, but retained until
either the next Locator Update message is received, there is
other indication that a given Locator is not working any longer,
there is positive indication that the Correspondent Node has
terminated the session (e.g. TCP RST), until some appropriate
timeout (e.g. 2*MSL for TCP), or the session has been inactive
for several minutes and the storage space associated with the
aged entry needs to be reclaimed.
Separately, received authenticated Locator Update messages cause
the ILCC entries listed above to be updated.
Similarly, if there is indication that a session with a
Correspondent Node remains active and the DNS TTL associated with
that Correspondent Node's active Identifier value(s) has expired,
those remote Identifier value(s) ought to be marked as "aged" but
retained since they are in active use.
4.3 Large Numbers of Locators
Implementers should keep in mind that a node or site might have a
large number of concurrent Locators, and should ensure that a
system fault does not arise if the system receives an authentic
ICMP Locator Update containing a large number of Locator values.
4.4 Lookups into the ILCC
For received packets containing an ILNP Nonce Option, lookups in
the ILCC MUST use the <remote Identifier, Nonce> tuple as the
lookup key. This facilitates situations where, perhaps due to
deployment of Local-scope Identifiers, more than one
Correspondent Node is using the same Identifier value.
For all other ILNP packets, lookups in the ILNP Correspondent
Cache MUST use the <remote Locator, remote Identifier} tuple as
the lookup key. This facilitates situations where, perhaps due to
deployment of Local-scope Identifiers, more than one
Atkinson & Bhatti Expires in 6 months [Page 8]
Internet Draft ILNP Eng 09 JUL 2012
correspondent node is using the same Identifier value.
(NOTE: Other mechanisms, such as IPv6 Neighbor Discovery, ensure
that 2 different nodes are incapable of using a given IL-V tuple
at the same location.)
While Locators are omitted from the transport-layer checksum, an
implementation SHOULD use Locator values to distinguish between
correspondents coincidentally using the same Identifier value
(e.g. due to deployment of Local-scope Identifier values) when
demultiplexing to determine which application(s) should receive
the user data delivered by the transport-layer protocol.
5. HANDLING LOCATION/CONNECTIVITY CHANGES
In normal operation, an ILNP node uses the DNS for initial
rendezvous in setting up sessions. The use of DNS for initial
rendezvous with mobile nodes was earlier proposed by others
[PHG02] and then separately re-invented by the current authors
later on.
5.1 Node Location/Connectivity Changes
To handle the move of a node or a change to the upstream
connectivity of a multi-homed node, we add a new ICMP control
message [ILNP-ICMPv4] [ILNP-ICMPv6]. The ICMP Locator Update (LU)
message is used by a node to inform its existing CNs that the set
of valid Locators for the node has changed. This mechanism can
be used to add newly valid Locators, to remove no longer valid
Locators, or to do both at the same time. The LU mechanisms is
analogous to the Binding Update mechanism in Mobile IPv6, but in
ILNP, such messages are used any time Locator value changes need
to be notified to CNs, e.g. for multi-homed hosts as well as for
mobile hosts.
Further, if the node wishes to be able to receive new incoming
sessions, the node uses Secure Dynamic DNS Update [RFC3007] to
ensure that a correct set of Locator values are present in the
appropriate DNS records (i.e. L32, L64) in the DNS for that node
[ILNP-DNS]. This enables any new correspondents to correctly
initiate a new session with the node at its new location.
While the Locator Update control message could be an entirely new
protocol running over UDP, for example, there is no obvious
advantage to creating a new protocol rather than using a new ICMP
message. So ILNP defines a new ICMP Locator Update message
for both IPv4 and IPv6.
Atkinson & Bhatti Expires in 6 months [Page 9]
Internet Draft ILNP Eng 09 JUL 2012
5.2 Network Connectivity/Locator Changes
As a DNS performance optimisation, the LP DNS resource record
MAY be used to avoid requiring each node on a subnetwork to
update its DNS L64 record entries when that subnetwork's
location (e.g. upstream connectivity) changes [ILNP-DNS].
This can reduce the number of DNS updates required when a
subnetwork moves from O(number of nodes on subnetwork) to O(1).
In this case, the nodes on the subnetwork each would have an LP
record pointing to a common Fully-Qualified Domain Name (FQDN)
used to name that subnetwork. In turn, that subnetwork's domain
name would have one or more L64 record(s) in the DNS. Since the
contents of an LP record are stable, relatively long DNS TTL
values can be associated with these records facilitating DNS
caching. By contrast, the DNS TTL of an L32 or L64 record for a
mobile or multi-homed node should be small. Experimental work at
the University of St Andrews indicates that the DNS continues to
work well even with very low (e.g. zero) DNS TTL values [BA2011].
Correspondents of a node on a mobile subnetwork using this DNS
performance optimisation would perform an ID, L32, or L64 record
query for that target node, and would receive the LP records as
additional data in the DNS reply. Next, the correspondent would
perform an L32 or L64 record lookup on the domain-name pointed to
by that LP record, in order to learn the Locator value to use to
reach that target node.
6. DNS CONSIDERATIONS
ILNP makes use of DNS for name resolution, as does IP. However,
unlike IP, ILNP also uses DNS to support functions such as
mobility and multi-homing. While such usage is appropriate to the
function of DNS, it is important to discuss operational and
engineering issues that may impact DNS usage.
6.1 Secure Dynamic DNS Update
When a host that expects incoming connections changes one or more
of its Locator values, the host normally uses the IETF Secure
Dynamic DNS Update protocol [RFC3007] to update the set of
currently valid Locator values associated with its Fully
Qualified Domain Name (FQDN). This ensures that the authoritative
DNS server for its FQDN will be able to generate an accurate set
of Locator values if the DNS server receives DNS name resolution
request for its FQDN.
Atkinson & Bhatti Expires in 6 months [Page 10]
Internet Draft ILNP Eng 09 JUL 2012
Liu & Albitz [LA2006] report that Secure Dynamic DNS Update has
been supported on the client-side for several years now in widely
deployed operating systems (e.g. MS Windows, Apple MacOS X, UNIX,
and Linux) and also in DNS server software (e.g. BIND). Publicly
available product data sheets indicate that some other DNS server
software packages, such as that from Nominum, also support this
capability.
For example, Microsoft Windows XP (and later versions), the
freely distributable BIND DNS software package (used in Apple
MacOS X and in most UNIX systems), and the commercial Nominum DNS
server all implement support for Secure Dynamic DNS Update and
are known to interoperate [LA2006]. There are credible reports
that when a site deploys Microsoft's Active Directory, the site
(silently) automatically deploys Secure Dynamic DNS Update
[LA2006]. So, many sites have already deployed Secure Dynamic DNS
Update even though they are not actively using it (and might not
be aware they have already deployed that protocol) [LA2006].
So DNS update via Secure Dynamic DNS Update is not only
standards-based, but also readily available in widely deployed
systems today.
6.3. New DNS RR types
As part of this proposal, additional DNS Resource Records have
been proposed in a separate document [ILNP-DNS]. These new
records are summarised in Table 6.1.
new DNS RR type | Purpose
-----------------+------------------------------------------------
ID | store the value of an Identifier
L32 | store the value of a 32-bit Locator for ILNPv4
L64 | store the value of a 64-bit Locator for ILNPv6
LP | points to a (several) L32 and/or L64 record(s)
-----------------+------------------------------------------------
Table 6.1: Summary of new DNS RR types for ILNP
With this proposal, mobile or multi-homed nodes and sites are
expected to use the existing "Secure Dynamic DNS Update" protocol
to keep their Identifier (ID) and Locator (L32 and/or L43)
records correct in their authoritative DNS server(s) [RFC3007]
[ILNP-DNS].
Reverse DNS lookups, to find a node's Fully Qualified Domain Name
from the combination of a Locator and related Identifier value,
Atkinson & Bhatti Expires in 6 months [Page 11]
Internet Draft ILNP Eng 09 JUL 2012
can be performed as at present.
6.4 DNS TTL values for ILNP RRS types
Existing DNS specifications require that DNS clients and DNS
resolvers honour the TTL values provided by the DNS servers. In
the context of this proposal, short DNS TTL values are assigned
to particular DNS records to ensure that the ubiquitous DNS
caching resolvers do not cache volatile values (e.g. Locator
records of a mobile node) and consequently return stale
information to new requestors.
The time-to-live (TTL) values for L32 and L64 records may have to
be relatively low (perhaps a few seconds) in order to support
mobility and multi-homing. Low TTL values may be of concern to
administrators who might think that this would reduce efficacy of
DNS caching increase DNS load significantly.
Previous research by others indicates that DNS caching is largely
ineffective, with the exception of NS records and the addresses
of DNS servers referred to by NS records [SBK2002]. This means
DNS caching performance and DNS load will not be adversely
affected by assigning very short TTL values (down to zero) to the
Locator records of typical nodes for a edge site [BA2011]. It
also means that it is preferable to deploy the DNS server
function on nodes that have longer DNS TTL values, rather than on
nodes that have shorter DNS TTL values.
LP records normally are stable and will have relatively long TTL
values, even if the L32 or L64 records they point to have values
that have relatively low TTL values.
Identifier values might be very long-lived (e.g. days) when they
have been generated from an IEEE MAC address on the
system. Identifier values might have a shorter lifetime
(e.g. hours or minutes) if they have been cryptographically-
generated [RFC3972], or have been created by the IPv6 Privacy
Extensions [RFC4941], or otherwise have the EUI-64 scope bit set
to "local-scope". Note that when ILNP is used, the cryptographic
generation method described in RFC 3972 is used only for the
Identifier, omitting the Locator, thereby preserving roaming
capability. Note that a given ILNP session normally will use a
single Identifier value for the lifetime of that session.
6.5 IP/ILNP dual operation and transition
During a long transition period, a node that is ILNP-capable
SHOULD have not only have ID and l32/L64 (or ID and LP) records
Atkinson & Bhatti Expires in 6 months [Page 12]
Internet Draft ILNP Eng 09 JUL 2012
present in its authoritative DNS server, but also SHOULD have
A/AAAA records in the DNS for the benefit of non-upgraded
nodes. Then, when any CN performs an FQDN lookup for that node,
it will receive the A/AAAA with the appropriate ID, L32/L64
and/or LP records as "additional data".
Existing DNS specifications require that a DNS resolver or DNS
client ignore unrecognised DNS record types. So gratuitously
appending ID and Locator (i.e., L32, L64, or LP) records as
"additional data" in DNS responses to A/AAAA queries ought not to
create any operational issues. So, IP only nodes would use the
A/AAAA RRs, but ILNP-capable nodes would be able to use the ID,
L32/L64 and/or LP records are required.
There is nothing to prevent this capability being implemented
strictly inside a DNS server, whereby the DNS server synthesises
a set of A/AAAA records to advertise from the ID and Locator
(i.e., L32, L64, or LP) values that the node has kept updated in
that DNS server. Indeed, such a capability may be desirable,
reducing the amount of manual configuration required for a site,
and reducing the potential for errors as the A/AAAA records would
be automatically generated.
7. BACKWARDS COMPATIBILITY & INCREMENTAL DEPLOYMENT
Experience with IPv6 deployment over the past many years has
shown that it is important for any new network protocol to
provide backwards compatibility with the deployed IP base and
should be incrementally deployable, ideally requiring
modification of only those nodes that wish to use ILNP and no
requiring the modification of nodes that do not intend to use
ILNP. The two instances of ILNP, ILNPv4 and ILNPv6, are intended
to be, respectively, backwards compatible with, and incrementally
deployable on, the existing IPv4 and IPv6 installed
based. Indeed, ILNPv4 and ILNPv6 each be seen, from an
engineering viewpoint, as supersets of the IPv4 and IPv6
respectively.
However, in some cases, ILNP introduces functionality that
supersedes equivalent functionality available in IP. For example,
ILNP has a mobility model and so does not need to use the models
for Mobile IPv4 or Mobile IPv6.
As ILNP changes the use of end-to-end namespaces, for the most
part, it is only end-systems that need to be modified. However,
in order to leverage existing engineering (e.g. existing
protocols), in some cases, there is a compromise, and these
Atkinson & Bhatti Expires in 6 months [Page 13]
Internet Draft ILNP Eng 09 JUL 2012
are highlighted in this section.
7.1 Interworking between IP and ILNP
A related topic is interworking: for example, how would an IPv6
node communicate with an ILNPv6 node? Currently, we make the
assumption that ILNP nodes "drop down" to using IP when
communicating with a non-ILNP capable node, i.e. there is no
interworking as such. In the future, it may be beneficial to
define interworking scenarios, for example by the use of suitable
gateways or middleboxes. However, at the current time, such
functionality is not defined.
Realistically, we see that it is likely that just as many
observers expect IPv4 to remain in place for a long time even
though IPv6 has been available for over a decade, it is likely
that in the future there may be hosts that are both IP and ILNP
hosts. Until there is a better understanding of the deployment
and usage scenarios that will develop, it is not clear what
interworking scenarios would be useful to define between IP and
ILNP.
7.2 Priorities in the design of ILNPv4 and ILNPv4
In the engineering design of ILNPv4 and ILNPv6, we have used the
following priorities. In some ways, this choice is arbitrary, and
it may be equally valid to "invert" these priorities for a
different architectural and engineering design.
1. Infrastructure
As much of the deployed IP network infrastructure should be
used without change. That is, routers and switches should
require minimal or zero modifications in order to run
ILNP. As much of the existing installed base of core
protocols should be re-used.
2. Core protocols
As much of the deployed network control protocols, such as
routing, should be used without change. That is, existing
routing protocols and switch configuration should require
minimal or zero modifications in order to run ILNP.
3. Scope of end-system changes
Atkinson & Bhatti Expires in 6 months [Page 14]
Internet Draft ILNP Eng 09 JUL 2012
Any nodes that do not need to run ILNP should not need to be
upgraded. It should be possible to have a site network that
has a mix of IP-only and ILNP-capable nodes without any
changes required to the IP-only nodes.
4. Applications
There should be minimal impact on applications, even though
ILNP requires end-to-end protocols to be upgraded. Indeed,
for those applications that are "well-behaved" (e.g. do not
use IP address values directly for application state or
application configuration), there should be little or no
effort required in enabling them to operate over ILNP.
Each of these items is discussed in its own section below.
7.3 Infrastructure
ILNP is designed to be deployed on existing infrastructure. No
new infrastructure is required to run ILNP as it will be
implemented as a software upgrade impacting only end-to-end
protocols. Existing routing protocols can be re-used: no new
routing protocols are required. This means that network operators
and service providers do not need to learn about, test, and deploy
new protocols, or change the structure of their network in order
for ILNP to be deployed. Exceptionally, edge routers supporting
ILNPv4 hosts will need to support an enhanced version of ARP.
7.4 Core protocols
Existing routing and other control protocols should not need to
change in devices such as switches and routers. We believe this
to be true for ILNPv6. However, for ILNPv4, we believe that ARP
will need to be enhanced in edge routers (or layer-3 switches)
that support ILNPv4 hosts. Backbone and transit routers
still ought not require changes for either ILNPv4 or ILNPv6.
However, for both ILNPv4 and ILNPv6, the basic packet format for
packets re-uses that format that is seen by routers for IPv4 and
IPv6 respectively. Specifically, as the ILNP Locator value is
always a routing prefix (either IPv4 or IPv6), routing protocols
should work unchanged.
For packet forwarding, as both ILNPv4 and ILNPv6 introduce new
header options (e.g Nonce Option messages) and ICMP messages
(e.g. Locator Update messages) which are used to enable
end-to-end signalling, depending on the forwarding policies used
Atkinson & Bhatti Expires in 6 months [Page 15]
Internet Draft ILNP Eng 09 JUL 2012
by some providers or site border routers, there may need to be
modifications to those policies to allow the new header options
and new ICMP messages to be forwarded. However, as the header
options and new ICMP messages are end-to-end, such modifications
are likely to be in configuration files (or firewall policy on
edge routers), as core routers do NOT need to parse and act upon
the information contained in the header options or ICMP messages.
7.5 Scope of end-system changes
Only end-systems that need to use ILNP need to be updated in
order for ILNP to be used at a site.
There are three exceptions to this statement as follows:
a) ILNPv4 ARP: as the Identifier value for IPv4 cannot fit into
the normal 20-byte IPv4 packet header (a header extension is
used), ARP must be modified. This only impacts end-systems
that use ILNPv4 and those switches or site-border routers
that are the first hop from an ILNPv4 node. For ILNPv6, as
the I and L values fit into the existing basic IPv6 packet,
IPv6 Neighbour Discovery can operate without modification
b) Use of IP NAT: Where IP NAT or NAPT is in use for a site,
existing NAT/NAPT device will re-write address fields in
ILNPv4 packets or ILNPv6 packets. To avoid this, the NAT
should either (i) configured to allow the pass-through of
packets originating from ILNP-capable nodes (e.g. by
filtering on source address fields in the IP header);
or (ii) should be enhanced to recognise ILNPv4 or ILNPv6
packets (e.g. by looking for the ILNP Nonce option).
c) Site border routers (SBRs) in ILNP Advanced Deployment
scenarios: There are options to use an ILNP-capable site
border router (SBR) as described in another document
[ILNP-ADV]. In such scenarios, the SBR(s) need to be
ILNP-capable.
Other than these exceptions, it is entirely possible to have a
site that uses a mix of IP and ILNP nodes and requires no changes
to nodes other than the nodes that wish to use ILNP. For example,
if a user on a site wishes to have his laptop use ILNPv6, only
that laptop would need to have an upgraded stack: no other
devices (end-systems, layer-2 switches or routers) at that site
would need to be upgraded.
Atkinson & Bhatti Expires in 6 months [Page 16]
Internet Draft ILNP Eng 09 JUL 2012
7.6 Applications
As noted, in the Architecture Description [ILNP-ARCH], those
applications that do not use IP address values in application
state or configuration data are considered to be "well-behaved".
Applications that work today through a NAT or NAPT device without
application-specific support are also considered "well behaved".
Such applications might use DNS FQDNs or application-specific
name spaces. (Note Well: application-specific name spaces should
not be derived from IP address values).
For well-behaved applications, replacing IP with ILNP should have
no impact. That is, well-behaved applications should work
unmodified over ILNP.
Those applications that use directly IP address values in
application state or configuration will need to be modified for
operation over ILNP. Examples of such applications include:
- FTP: which uses IP address values in the application layer
protocol. In practice, use of Secure Copy (SCP) is growing,
while use of FTP is either flat or declining, in part due
to the improved security provided by SCP.
- SNMP: which uses IP address values in MIB definitions, and
values derived from IP address values in SNMP object names.
Further experimentation in this area is planned to validate
these details.
8. SECURITY CONSIDERATIONS
There are numerous security considerations for ILNP from an
engineering viewpoint. Overall, ILNP functionality is no less
secure than equivalent IP functionality. In some cases, ILNP has
the potential to be more secure, or offer security capability in
a more harmonised manner, for example with ILNP's use of IPsec in
conjunction with multi-homing and mobility. [ILNP-ARCH]
describes several security considerations that apply to ILNP and
is included here by reference.
8.1 Authenticating ICMP Locator Updates
Separate documents propose a new IPv4 Option [ILNP-v4opts]
and a new IPv6 Destination Option [ILNP-NONCE6]. Each of
these options can be used to carry a session nonce end-to-end
Atkinson & Bhatti Expires in 6 months [Page 17]
Internet Draft ILNP Eng 09 JUL 2012
between communicating nodes. That nonce provides protection
against off-path attacks on an Identifier/Locator session. The
Nonce options are used ONLY for ILNP and not for IP. The nonce
values are exchanged in the initial packets of an ILNP session
by including them in those initial/handshake packets.
When ILNP is in use, the Nonce Destination Option MUST be
included in any ICMP control messages (e.g. ICMP Unreachable,
ICMP Locator Update) sent by a correspondent node with regard to
their ILNP sessions. Note that in a small number of situations,
a transit router or firewall legitimately might send an ICMP
message (e.g. Packet Too Big) to an end system without including
the ILNP Nonce.
When using ILNP for an existing session, ICMP control messages
for that session that are received from a correspondent node
without a Nonce Destination Option MUST be discarded as
forgeries. This security event SHOULD be logged.
When using ILNP for an existing session, ICMP control messages
received from a correspondent node that contain an ILNP Nonce
option, but do not have the correct nonce value inside the Nonce
Destination Option, MUST be discarded as forgeries. This security
event SHOULD be logged.
When using ILNP for an existing session, and a node changes its
Locator set, it SHOULD include the Nonce Destination Option in
the first few data packets sent using a new Locator value, so
that the recipient can validate the received data packets as
valid (despite having an unexpected Source Locator value).
8.2 Forged Identifier Attacks
The ILNP Correspondent Cache contains two unidirectional nonce
values (one used in control messages sent by this node, a
different one used to authenticate messages from the other node)
for each active or recent ILNP session. The correspondent cache
also contains the currently valid set of Locators and set of
Identifiers for each correspondent node.
If a received ILNP packet contains valid Identifier values and a
valid Destination Locator, but contains a Source Locator value
that is not present in the correspondent cache, the packet MUST
be dropped as an invalid packet and a security event SHOULD be
logged, UNLESS the packet also contains a Nonce Destination
Option with the correct value used for packets from the node with
that Source Identifier to this node. This prevents an off-path
Atkinson & Bhatti Expires in 6 months [Page 18]
Internet Draft ILNP Eng 09 JUL 2012
attacker from stealing an existing session.
9. OPERATIONAL CONSIDERATIONS
This section covers various operational considerations relating
to ILNP, including potential session liveness and reachability
considerations and Key Management considerations. Again, the
situation is similar to IP, but it is useful to explain the
issues in relation to ILNP nevertheless.
9.1 Session Liveness and Reachability
For bi-directional flows, such as a TCP session, each node knows
whether the current path in use is working by the reception of
data packets, acknowledgements, or both. Therefore, as with
TCP/IP, TCP/ILNP does not need special path probes. UDP/ILNP
sessions with acknowledgements work similarly, and also do not
need special path probes.
In the deployed Internet, the sending node for a UDP/IP session
without acknowledgements does not know for certain that all
packets are received by the intended receiving node. Such
UDP/ILNP sessions have the same properties as UDP/IP sessions in
this respect. The receiver(s) of such an UDP/ILNP session SHOULD
send a gratuitous IP packet containing an ILNP Nonce option to
the sender, in order to enable the receiver to subsequently send
ICMP Locator Updates if appropriate [ILNP-NONCE6]. In this case,
UDP/ILNP sessions fare better than UDP/IP sessions, still without
using network path probes.
A mobile (or multi-homed) node may change its connectivity more
quickly than DNS can be updated. This situation is unlikely,
particularly given the widespread use of link-layer mobility
mechanisms (e.g. GSM, IEEE 802 bridging) in combination with
network-layer mobility. However, the situation is functionally
equivalent to the situation where a traditional IP node is moving
faster than the Mobile IPv4 or Mobile IPv6 agents/servers can be
updated with the mobile node's new location. So the issue is not
new in any way to ILNP. In all cases, Mobile IPv4 and Mobile IPv6
and ILNP, a node moving that quickly might be temporarily
unreachable until it remains at a given network-layer location
(e.g. IP subnetwork, ILNP Locator value) long enough for the
location update mechanisms (for Mobile IPv4, for Mobile IPv6, or
ILNP) to catch up.
Atkinson & Bhatti Expires in 6 months [Page 19]
Internet Draft ILNP Eng 09 JUL 2012
Another potential issue for IP is what is sometimes called "Path
Liveness" or, in the case of ILNP, "Locator Liveness". This
refers to the question of whether an IP packet with a particular
destination Locator value will be able to reach the intended
destination network or not, given that some otherwise valid paths
might be unusable by the sending node (e.g. due to security
policy or other administrative choice). In fact, this issue has
existed in the IPv4 Internet for decades.
For example, an IPv4 server might have multiple valid IP
addresses, each advertised to the world via an DNS A
record. However, at a given moment in time, it is possible that a
given sending node might not be able to use a given (otherwise
valid) destination IPv4 address in an IP packet to reach that
IPv4 server.
Indeed, for ILNPv6, as the ILNP packet reuses the IPv6 packet
header and uses IPv6 routing prefixes as Locator values, such
liveness considerations are no worse than they are for IPv6
today. For example, for IPv6, if a host, H, performs a DNS lookup
for an FQDN for remote host F, and receives a AAAA RR with IPv6
address F_A, this does not mean necessarily that H can reach F on
its F_A using its current connectivity, i.e. an IPv6 path may not
be available from H to F at that point in time.
So we see that using an Identifier/Locator Split architecture
does not create this issue, nor does it make this issue worse
than it is with the deployed IPv4 Internet.
In ILNP, the same conceptual approach described in [RFC5534]
(Locator Pair Exploration for SHIM6) can be
reused. Alternatively, an ILNP node can reuse the existing IPv4
methods for determining whether a given path to the target
destination is currently usable, for which existing methods
leverage transport-layer session state information that the
communicating end systems are already keeping for transport-layer
protocol reasons.
Lastly, it is important to note that the ICMP Locator Update
mechanism described in [ILNP-ICMPv6] [ILNP-ICMPv4] is a
performance optimisation, significantly shortening the
network-layer handoff time if/when a correspondent changes
location. Architecturally, using ICMP is no different from
using UDP, of course.
9.2 Key Management Considerations
ILNP potentially has advantages over either form of Mobile IP
Atkinson & Bhatti Expires in 6 months [Page 20]
Internet Draft ILNP Eng 09 JUL 2012
with respect to key management, given that ILNP is using Secure
Dynamic DNS Update -- which capability is much more widely
available today in deployed desktop and server environments
(e.g. Microsoft Windows, MacOS X, Linux, other UNIX), as well as
being widely available today in deployed DNS server software
(e.g. Microsoft and the freely available BIND) and appliances
[LA2006], than the Security enhancements needed by either Mobile
IPv4 or Mobile IPv6.
IETF work in progress is addressing use of DNS to support key
management for entities having DNS Fully-Qualified Domain Names.
10. REFERRALS & APPLICATION PROGRAMMING INTERFACES
This section is concerned with support for using existing
("legacy") applications over ILNP, including both referrals and
Application Programming Interfaces (APIs).
ILNP does NOT require well-behaved applications be modified to
use a new networking API, nor does it require applications be
modified to use extensions to an existing API. Existing
well-behaved IP applications should work over ILNP without
modification using existing networking APIs.
10.1 BSD Sockets APIs
The existing BSD Sockets API can continue to be used with ILNP
underneath the API. That API can be implemented in a manner that
hides the underlying protocol changes from the applications. For
example, the combination of a Locator and an Identifier can be
used with the API in the place of an IPv6 address.
So it is believed that existing IP address referrals can continue
to work properly in most cases. For a rapidly moving target node,
referrals might break in at least some cases. The potential for
referral breakage is necessarily dependent upon the specific
application and implementation being considered.
It is suggested, however, that a new, optional, more abstract, C
language API be created so that new applications may avoid
delving into low-level details of the underlying network
protocols. Such an API would be useful today, even with the
existing IPv4 and IPv6 Internet, whether or not ILNP were ever
widely deployed.
10.2 Java (and other) APIs
Atkinson & Bhatti Expires in 6 months [Page 21]
Internet Draft ILNP Eng 09 JUL 2012
Most existing Java APIs already use abstracted network
programming interfaces, for example in the java.Net.URL
class. Because these APIs already hide the low-level
network-protocol details from the applications, the applications
using these APIs (and the APIs themselves) don't need any
modification to work equally well with IPv4, IPv6, ILNP, and
probably also HIP.
Other programming languages, such as C++, python and ruby, also
provide higher-level APIs that abstract away from sockets, even
though sockets may be used beneath those APIs.
10.3 Referrals in the Future
The approach proposed in [ID-Referral] appears to be very
suitable for use with ILNP, in addition to being suitable for use
with the deployed Internet. Protocols using that approach would
not need modification to have their referrals work well with
IPv4, IPv6, ILNP, and probably also other network protocols
(e.g. HIP).
A sensible approach to referrals is to use Fully-Qualified Domain
Names (FQDNs), as is commonly done today with web URLs. This
approach is highly portable across different network protocols,
even with both the IPv4 Internet or the IPv6 Internet.
11. IANA CONSIDERATIONS
There are no IANA considerations.
(The RFC Editor is requested to remove this section prior to
publication.)
12. REFERENCES
12.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997.
[RFC3007] B. Wellington, "Secure Domain Name System
Dynamic Update", RFC-3007, November 2000.
[ILNP-ARCH] R. Atkinson & S. Bhatti, "ILNP Architecture",
draft-irtf-rrg-ilnp-arch, January 2012.
Atkinson & Bhatti Expires in 6 months [Page 22]
Internet Draft ILNP Eng 09 JUL 2012
[ILNP-DNS] R. Atkinson, S. Bhatti, & S. Rose, "DNS Resource
Records for ILNP", draft-irtf-rrg-ilnp-dns,
January 2012.
[ILNP-ICMPv4] R. Atkinson & S. Bhatti, "ICMPv4 Locator Update
message" draft-irtf-rrg-ilnp-icmpv4, January 2012.
[ILNP-ICMPv6] R. Atkinson, "ICMPv6 Locator Update message"
draft-irtf-rrg-ilnp-icmpv6, January 2012.
[ILNP-NONCE6] R. Atkinson & S. Bhatti, "IPv6 Nonce Destination
Option for ILNPv6", draft-irtf-rrg-ilnp-nonce6,
January 2012.
[ILNP-v4opts] R. Atkinson & S. Bhatti, "IPv4 Options for ILNP",
draft-irtf-rrg-ilnp-v4opts, January 2012.
12.2 Informative References
[BA2011] S. Bhatti & R. Atkinson, "Reducing DNS Caching",
Proc. GI2011 - 14th IEEE Global Internet Symposium.
Shanghai, China. 15 April 2011.
[LA2006] Cricket Liu and Paul Albitz, "DNS and Bind",
5th Edition, O'Reilly & Associates, Sebastopol,
CA, USA. 2006. ISBN 0-596-10057-4.
[PHG02]
[SBK2002]
[ID-Referral]
[RFC3972]
[RFC4291]
[RFC4581]
[RFC4941]
[RFC4982]
[RFC5534]
ACKNOWLEDGEMENTS
Atkinson & Bhatti Expires in 6 months [Page 23]
Internet Draft ILNP Eng 09 JUL 2012
Steve Blake, Mohamed Boucadair, Noel Chiappa, Steve Hailes, Joel
Halpern, Mark Handley, Volker Hilt, Paul Jakma, Dae-Young Kim,
Tony Li, Yakov Rehkter, Robin Whittle and John Wroclawski (in
alphabetical order) provided review and feedback on earlier
versions of ILNP documents. Steve Blake provided an especially
thorough review of an early version of the entire ILNP document
set, which was extremely helpful. We also wish to thank the
anonymous reviewers of the various ILNP papers for their
feedback.
Author's Address
RJ Atkinson
Consultant
San Jose, CA
95125 USA
Email: rja.lists@gmail.com
SN Bhatti
School of Computer Science
University of St Andrews
North Haugh, St Andrews
Fife, Scotland
KY16 9SX, UK
Email: saleem@cs.st-andrews.ac.uk
Expires: 09 JUL 2012
Atkinson & Bhatti Expires in 6 months [Page 24]
