Internet Draft R. Atkinson
draft-rja-ilnp-intro-05.txt Consultant
Expires: 24 DEC 2010 24 June 2010
Category: Experimental
ILNP Concept of Operations
draft-rja-ilnp-intro-04.txt
Status of this Memo
Distribution of this memo is unlimited.
Copyright (c) 2010 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
documents at any time. It is inappropriate to use
Atkinson Expires in 6 months [Page 1]
Internet Draft ILNP Intro 24 JUN 2010
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.
This document has had extensive review within the IRTF Routing
Research Group, and is part of the ILNP document set. Also, 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 also have had
broader review than just the IRTF Routing RG.
Abstract
This document descibes the Concept of Operations for the
Identifier Locator Network Protocol (ILNP), which is an
experimental extension to IP. This is a product of the
IRTF Routing RG.
Table of Contents
1. Introduction ...............................................2
2. Locators & Identifiers......................................4
3. Transport Protocols.........................................8
4. Mobility....................................................9
5. Multi-Homing...............................................12
6. Localised Addressing.......................................13
7. IP Security Enhancements...................................14
8. DNS Enhancements...........................................15
9. Referrals & Application Programming Interfaces.............17
10. Backwards Compatibility....................................18
11. Incremental Deployment.....................................19
12. Implementation Considerations..............................20
13. Security Considerations ...................................21
14. IANA Considerations .......................................26
15. References ................................................26
1. INTRODUCTION
Atkinson Expires in 6 months [Page 2]
Internet Draft ILNP Intro 24 JUN 2010
At present, the research and development community are exploring
various approaches to evolving the Internet Architecture.
Several different classes of evolution are being considered. One
class is often called "Map and Encapsulate", where traffic would
be mapped and then tunnelled through the inter-domain core of the
Internet. Another class being considered is sometimes known as
"Identifier/Locator Split". This document relates to a proposal
that is in the latter class of evoluationary approaches.
There has been substantial research relating to naming in the
Internet through the years. [IEN 1] [IEN 19] [IEN 23] [IEN 31]
[RFC 814] [RFC 1498] More recently, mindful of that important
prior work, and starting well before the Routing RG was
re-chartered to focus on inter-domain routing scalability, the
author has been examining enhancements to certain naming aspects
of the Internet Architecture. [MobiArch07] [MobiWAC07]
[MobiArch08] [MILCOM08] [MILCOM09] [TeleSys]
The architectural concept behind ILNP derives originally from a
June 1994 note by Bob Smart to the IETF SIPP WG mailing list.
[SIPP94] In January 1995, Dave Clark sent a note to the IETF IPng
WG mailing list suggesting that the IPv6 address be split into
separate Identifier and Locator fields. [IPng95]
Afterwards, Mike O'Dell persued this concept in Internet-Drafts
describing "8+8" or "GSE".[8+8] [GSE] More recently, the IRTF
Namespace Research Group (NSRG) studied this matter. Unusually
for an IRTF RG, the NSRG operated on the principle that unanimity
was required for the NSRG to make a recommendation. The author
was a member of the IRTF NSRG. At least one other proposal, the
Host Identity Protocol (HIP), also derives in part from the IRTF
NSRG studies (and related antecedent work). This current
proposal differs from O'Dell's work in various ways.
The crux of this proposal is to have different names for the
identity of a node and the location of its subnet, with crisp
semantics for each. This enhances the Internet Architecture
by adding crisp and clear semantics for the Identifier and
for the Locator, removing the semantically-muddled concept
of the IP address, and updating end system protocols slightly,
without requiring router changes.
With these naming enhancements, we have improved the Internet
Architecture by adding explicit support not only for
multi-homing, but also for mobility, localised addressing
(e.g. NAT/NAPT), and IP Security.
ILNP is an architecture, and can have more than one engineering
Atkinson Expires in 6 months [Page 3]
Internet Draft ILNP Intro 24 JUN 2010
instantiation. The term ILNPv4 refers precisely to an instance
of ILNP that is based upon and backwards compatible with IPv4.
The term ILNPv6 refers precisely to an instance of ILNP that is
based upon and backwards compatible with IPv6. The following two
subsections provide brief overview of ILNPv6 and ILNPv4,
respectively. A full specification for either ILNPv4 or ILNPv6 is
beyond the scope of this document. Readers are referred to other
related ILNP documents for details not described here. [ILNP-DNS]
[ILNP-ICMP] [ILNP-Nonce]
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. [RFC 2119]
2. LOCATORS & IDENTIFIERS
ILNP deprecates the semantically muddled concept of an "IP
Address" and replaces it with 2 new concepts, the "Locator"
and the "Identifier".
The Locator is used only to name the subnetwork a node is
connected to, while the Identifier is used only for node
identity. So the routing system uses Locators, while
upper-layer protocols (e.g. TCP/UDP pseudo-header checksum,
IPsec Security Association) use only the Identifier.
The same Identifier definition is used for both ILNPv4 and
ILNPv6. This is described in the next sub-section. Following
that is a description of ILNPv6, including a description of
the 64-bit Locator value used with ILNPv6. Then, there is a
description of ILNPv4, including a description of the 32-bit
Locator value used with ILNPv4.
2.1 Identifiers
With ILNP, the Identifier is an unsigned 64-bit number.
This provides a fixed-length non-topological name for a node.
Identifiers are bound to nodes, not to interfaces of a node.
All ILNP Identifiers MUST comply with the modified EUI-64 syntax
already specified for IPv6's "Interface Identifier" values.
[RFC 2460][RFC 4219][IEEE-EUI]
Identifiers are either globally-unique or locally-unique.
Atkinson Expires in 6 months [Page 4]
Internet Draft ILNP Intro 24 JUN 2010
A reserved bit in the modified EUI-64 syntax clearly
indicates whether a given Identifier has global-scope or
local-scope.[RFC 4219][IEEE-EUI] A node is not required
to use a global-scope Identifier, although that is the
recommended practice.
Most commonly, Identifiers have global-scope and are derived
from one or more IEEE 802 or IEEE 1394 'MAC Addresses' (sic)
already associated with the node, following the procedure
already defined for IPv6.[RFC 4219] This approach eliminates
the need to manage Identifiers, among other benefits.
Locally-unique Identifiers MUST be unique within the context
of their Locators. The existing mechanisms of the IPv4 Address
Resolution Protocol [RFC 826] and IPv6 Neighbour Discovery
Protocol [RFC 4861] automatically enforce this constraint.
Locally-unique Identifiers MUST NOT be used with other Locators
without first ensuring uniqueness in the context of those other
Locators (e.g. by using IPv6 Neighbour Discovery's Duplicate
Address Detection mechanism).
Other methods might be used to generate local-scope Identifiers.
For example, one might derive Identifiers using some form of
cryptographic generation or using the methods specified in the
IPv6 Privacy Extensions to State-Less Address Auto-Configuration
(SLAAC). [RFC 3972, RFC 4941] One could also imagine creating a
local-scope Identifier by taking a cryptographic hash of a node's
public key.
2.2 ILNPv6
It is worth remembering here that an IPv6 address names a
specific network interface on a specific node, but an ILNP
Identifier names the node itself, not a specific interface
on the node. This difference in definition is essential
to providing seamless support for mobility and multi-homing,
which are discussed in more detail later in this note.
1 1 2 3
0 4 8 2 6 4 1
+---------------+-----------------+----------------+---------------+
| Version| Traffic Class | Flow Label |
+---------------+-----------------+----------------+---------------+
| Payload Length | Next Header | Hop Limit |
+---------------+-----------------+--------------------------------+
| Source Address |
+ +
Atkinson Expires in 6 months [Page 5]
Internet Draft ILNP Intro 24 JUN 2010
| |
+ +
| |
+ +
| |
+---------------+-----------------+----------------+---------------+
| Destination Address |
+ +
| |
+ +
| |
+ +
| |
+---------------+-----------------+----------------+---------------+
Figure 1: Existing ("Classic") IPv6 Header
The high-order 64-bits of the IPv6 address become the Locator.
The Locator indicates the subnetwork point of attachment for a
node. In essence, the Locator names a subnetwork. Locators are
also known as Routing Prefixes. Of course, backwards
compatibility requirements mean that ILNPv6 Locators use the same
number space as IPv6 routing prefixes. This ensures that no
changes are needed to deployed IPv6 routers when deploying
ILNPv6.
The low-order 64-bits of the IPv6 address become the Identifier.
Details of the Identifier were discussed just above.
1 1 2 3
0 4 8 2 6 4 1
+---------------+-----------------+----------------+---------------+
| Version| Traffic Class | Flow Label |
+---------------+-----------------+----------------+---------------+
| Payload Length | Next Header | Hop Limit |
+---------------+-----------------+----------------+---------------+
| Source Locator |
+ +
| |
+---------------+-----------------+----------------+---------------+
| Source Identifier |
+ +
| |
+---------------+-----------------+----------------+---------------+
| Destination Locator |
+ +
Atkinson Expires in 6 months [Page 6]
Internet Draft ILNP Intro 24 JUN 2010
| |
+---------------+-----------------+----------------+---------------+
| Destination Identifier |
+ +
| |
+---------------+-----------------+----------------+---------------+
Figure 2: ILNPv6 Header
2.3 ILNPv4
ILNPv4 is merely a different instantiation of the ILNP
Architecture, so it retains the crisp distinction between
the Locator and the Identifier. Also, as with ILNPv6,
when ILNPv4 is used for a session, the upper-layer
protocols (e.g. TCP/UDP pseudo-header checksum, IPsec
Security Association) bind only to the Identifiers,
never to the Locators. As with ILNPv6, only the Locator
values are used for routing ILNPv4 packets.
Just as ILNPv6 is carefully engineered to be backwards-
compatible with IPv6, ILNPv4 is carefully engineered
to be backwards-compatible with IPv4.
The Source IP Address in the IPv4 header becomes the ILNPv4
Locator value, while the Destination IP Address of the IPv4
header becomes the Destination ILNPv4 Locator value. Of course,
backwards compatibility requirements mean that ILNPv4 Locators
use the same number space as IPv4 routing prefixes.
ILNPv4 uses the same 64-bit Identifier, with the same modified
EUI-64 syntax, as ILNPv6. Because the IPv4 address is much
smaller than the IPv6 address, ILNPv4 cannot carry the
Identifier values in the fixed portion of the IPv4 header.
The obvious two ways to carry the ILNP Identifier with ILNPv4
are either as an IPv4 Option or as an IPv6-style Extension
Header placed after the IPv4 header and before the upper-layer
protocol (e.g. OSPF, TCP, UDP, SCTP).
At least some currently available IPv4 forwarding silicon is able
to parse past IPv4 options to examine the upper-layer protocol
header at wire-speed on reasonably fast (e.g. 1 Gbps or better)
network interfaces. By contrast, no existing silicon is able
to parse past a new Extension Header at all. So, for engineering
reasons, ILNPv4 uses a new IPv4 Option to carry the Identifier
values.
Atkinson Expires in 6 months [Page 7]
Internet Draft ILNP Intro 24 JUN 2010
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|IHL=12 |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Locator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Locator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OT=ILNPv4_ID | OL=5 | Padding=0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Source Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Destination Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|OT=ILNPv4_NONCE| OL=2 | top 16 bits of nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| lower 32 bits of nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: ILNPv4 header with ILNP ID option
and ILNP Nonce option.
Notation for Figure 3:
IHL: Internet Header Length
OT: Option Type
OL: Option Length
The remainder of this note focuses on ILNP for IPv6, in the
interest of both clarity and brevity, however the same
architectural concepts and principles also apply to ILNP
for IPv4, albeit with slightly different engineering.
3. TRANSPORT PROTOCOLS
At present, commonly deployed transport protocols include a
pseudo-header checksum that includes certain network-layer
fields, the IP addresses used for the session, in its
calculation. This inclusion of network-layer information
within the transport-layer session state creates issues for
Atkinson Expires in 6 months [Page 8]
Internet Draft ILNP Intro 24 JUN 2010
multi-homing, mobility, IP Security, and localised addressing
(e.g. using Network Address Translation). [RFC 1631][RFC 3022]
This unfortunate aspect of the TCP pseudo-header checksum
has been understood to be an architectural problem at least
since 1977, well before the transition from NCP to
IPv4.[IEN 1][IEN 19][IEN 23][IEN 31][RFC 1498]
With this proposal, transport protocols include only the
Identifier in their pseudo-header calculations, but do not
include the Locator in their pseudo-header calculations.
To minimise the changes required within transport protocol
implementations, when this proposal is in use for a
communications session, the Locator fields are zeroed for
the purpose of transport-layer pseudo-header calculations.
Later in this document, methods for incremental deployment
of this change and backwards compatibility with non-upgraded
nodes are described.
4. MOBILITY
First, please recall that mobiity and multi-homing actually
present the same set of issues. In each case, the set of
Locators associated with a node or site changes. The reason
for the change might be different, but the effects on the
network and on correspondents is identical.
There are no standardised mechanisms to update most transport
protocols with new IP addresses in use for the session.
Exceptionally, the Stream Control Transport Protocol (SCTP)
recently added this capability.[RFC 5061] In July 2008, Mark
Handley at UCL proposed adding such a capability to TCP during
a presentation at the IRTF Routing RG in Dublin, Ireland.
His Multi-Path TCP concept is being considered in the IETF
as of this writing.
This creates various issues for mobility. For example, there
is no method at present to update the IP addresses associated
with a transport layer session when one of the nodes in that
session moves (i.e. changes one of its points of network
attachment).
So, the several approaches to IP mobility seek to hide the
change in location (and corresponding change in IP addresses)
via tunnelling, home agents, foreign agents, and so forth.
[RFC 3775] All of this can add substantial complexity to IP
Atkinson Expires in 6 months [Page 9]
Internet Draft ILNP Intro 24 JUN 2010
mobility approaches, both in the initial deployment and also
in ongoing operation.
By contrast, this ILNP proposal hides each node's location
information from the transport layer protocols at all times,
by removing location information from the transport session
state (e.g. pseudo-header checksum calculations).
In this proposal, mobility and multi-homing are supported using
a common set of mechanisms. In both cases, different Locator
values are used to identify different IP subnetworks.
To handle the move of a node, we add a new ICMP control message.
The ICMP Locator Update message is used by a node to inform its
existing correspondents 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. Further, the node uses Secure Dynamic DNS Update
to correct the set of L64 records in the DNS for that node.
[RFC 3007] This enables any new correspondents to correctly
initiate a new session with the node at its new location.
This use of DNS for initial rendezvous with mobile node was
independently proposed by others [PHG02] and then separately
re-invented by the current author later on.
(The Locator Update control message could be an entirely new
protocol running over UDP, for example, but there is no obvious
advantage to creating a new protocol rather than using a new
ICMP message.)
With ILNP, network mobility (as well as node mobility)
is considered a special case of multihoming. That is,
when a network moves, it uses a new Locator value for all
of its communications sessions. So, the same mechanism,
using a new or additional Locator value, also supports
network mobility. Similarly, when a multi-homed site
or multi-homed node changes its set of upstream links,
the Locators associated with that site or node change.
So in ILNP, when a connectivity change affects the set of
valid Locators, the affected node(s) actively:
(1) use the ICMP Locator Update message to inform their
existing correspondents with the updated information
about their currently valid Locator(s). [ILNP-ICMP]
AND also
Atkinson Expires in 6 months [Page 10]
Internet Draft ILNP Intro 24 JUN 2010
(2) update their DNS entries, most commonly by using
the Secure Dynamic DNS Update mechanism. [RFC 3007]
In the unlikely event of simultaneous motion which changes
both nodes' Locators within a very small time period, a
node can use the DNS to discover the new Locator value(s)
for the other node.
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. In this case, the nodes on
the subnetwork each would have an "LP" record pointing to a
common domain-name used to name that subnetwork. In turn, that
subnetwork's domain name would have one or more L64 record(s) in
the DNS.
Correspondents of a node on that subnetwork would perform a "L64"
record query for that target node (or an "ID" query for that
target node) and receive the "LP" records as additional data in
the DNS reply. Then the correspondent would perform an 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.
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. As with TCP/IP,
TCP/ILNP does not need special path probes. UDP/ILNP sessions
with acknowledgements work similarly, and also don't 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 fare no worse than UDP/IP sessions. The
receiver(s) of such a UDP 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. In this last case, UDP/ILNP sessions fare better
than UDP/IP sessions, still without using network path probes.
One might wonder what happens if a mobile node is moving 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
Atkinson Expires in 6 months [Page 11]
Internet Draft ILNP Intro 24 JUN 2010
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. 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) long enough for the location update mechanisms (for
Mobile IPv4, for Mobile IPv6, or ILNP) to catch up. ILNP is
prospectively better than either form of Mobile IP with respect
to key management, given that ILNP is using Secure Dynamic DNS
Update and given that neither form of Mobile IP has a
standardised and scalable key management mechanism at present.
5. MULTI-HOMING
Conceptually, there are two kinds of multi-homing. Site
multi-homing is when all nodes at a site are multi-homed
at the same time. This is what most people mean when they
talk about multi-homing. However, there is also a separate
concept of node multi-homing, where only a single node is
multi-homed.
At present, site multi-homing is common in the deployed Internet.
This is primarily achieved by advertising the site's routing
prefix(es) to more than upstream Internet service provider at a
given time. In turn, this requires de-aggregation of routing
prefixes within the inter-domain routing system. In turn, this
increases the entropy of the inter-domain routing system (e.g.
RIB/FIB size increases beyond the minimal RIB/FIB size that
would be required to reach all sites).
At present, node multi-homing is not common in the deployed
Internet. When TCP or UDP are in use for an IP session, node
multi-homing cannot provide session resilience, because the
transport pseudo-header checksum binds the session to a single
interface of the multi-homed node. SCTP has a protocol-specific
mechanism to support node multi-homing; SCTP can support session
resilience both at present and also without change in the
proposed approach. [RFC 5061]
In the new scheme, when a node is multi-homed, then the node
typically has more than one valid Locator value. When one
upstream connection fails, the node sends an ICMP Locator Update
message to each existing correspondent node to remove the
no-longer-valid Locator from the set of valid Locators.
[ILNP-ICMP] Also, the node can use Secure Dynamic DNS Update
to alter the set of currently valid L64 records associated with
that node. [RFC 3007] This second step ensures that any new
correspondents can reach the node.
Atkinson Expires in 6 months [Page 12]
Internet Draft ILNP Intro 24 JUN 2010
In the new scheme, site multi-homing works in a similar manner,
with nodes having one Locator for each upstream connection to
the Internet. To avoid a DNS Update burst when a site or
(sub)network moves location, a DNS record optimisation is
possible. This would change the number of DNS Updates required
from Order(number of nodes at the site/subnetwork that moved)
to Order(1). [ILNP-DNS]
Additionally, since the transport-protocol session state no
longer includes the Locators, a site could choose to perform
Locator rewriting at its site border routers, possibly in
combination with applying site traffic engineering policy on
which upstream link to use for which packets. Since the site
border router(s) are in the middle of any exterior packet flow,
they also can send proxy Locator Update messages on behalf of
nodes inside that site, and can even include the appropriate
Nonce value in such proxy Locator Updates, if desired by that
site's administration.
6. LOCALISED ADDRESSING
As the Locator value no longer forms part of the node session
state (e.g. TCP pseudo-header), it is easier to support
localised addressing, which is sometimes also called "Private
Addressing", based on the use of local values of the Locator.
This would be either in place of, or to supplement, existing
NAT-based schemes. [RFC 1631] [RFC 3022]
For example, a site that desires to use private addresses
internally might deploy IPv6 Unique Local Addressing
(ULA) for localised addressing, along with some form of ILNP/
IPv6 Network Address Translation at a site border gateway.
[ID-ULA] [RFC 4193] This example is described in detail
in [MILCOM09], both as a mechanism for site multi-homing
and also as a mechanism to support site-controlled traffic
engineering.
In the simplest case, an ILNP capable NAT only would need to
change the value of the Source Locator in an outbound packet,
and the value of the Destination Locator for an inbound packet.
Identifier values would not need to change, so a true end-to-end
session could be maintained.
If a site using localised addressing chooses to deploy a
split-horizon DNS server, then the DNS server would advertise
the global-scope Locator(s) of the site border routers outside
the site to DNS clients outside the site, and would advertise
the local-scope Locator(s) specific to that internal node to
Atkinson Expires in 6 months [Page 13]
Internet Draft ILNP Intro 24 JUN 2010
DNS clients inside the site. Such deployments of split-horizon
DNS servers are not unusual in the IPv4 Internet today. If an
internal node (e.g. portable computer) moves outside the site,
it would follow the normal ILNP methods to update its
authoritative DNS server with its current Locator set. In this
deployment model, the authoritative DNS server for that mobile
device will be either the split-horizon DNS server itself or the
master DNS server providing data to the split-horizon DNS server.
If a site using localised addressing chooses not to deploy a
split-horizon DNS server, then all internal nodes would
advertise the global-scope Locator(s) of the site border routers.
To deliver packets from one internal node to another internal
node, the site would either choose to use layer-2 bridging
(e.g. IEEE Spanning Tree, IEEE Rapid Spanning Tree, or a
link-state layer-2 algorithm such as the IETF TRILL group or
IEEE 802.1 are developing), or the interior routers would
forward packets up to the nearest site border router,
which in turn would then rewrite the Locators to appropriate
local-scope values, and forward the packet towards the interior
destination node.
We note that a deployment using private/local addressing can
also provide site multi-homing by deploying site border
routers in this manner.
Please note that with this proposal, localised addressing
(e.g. using Network Address Translation on the Locator bits)
would work in harmony with multihoming, mobility, and IP
Security.[MobiWAC07][MILCOM08][MILCOM09]
7. IP SECURITY ENHANCEMENTS
A current issue is that the IP Security protocols, AH and ESP,
have Security Associations that include the IP addresses of
the secure session endpoints. This was understood to be a
problem when AH and ESP were originally defined, however the
limited set of namespaces in the Internet Architecture did not
provide any better choices at that time.
Operationally, this binding causes problems for the use of the
IPsec protocols through Network Address Translation devices,
with mobile nodes (because the mobile node's IP address changes
at each network-layer handoff), and with multi-homed nodes
(because the session is bound to a particular interface of the
multi-homed node, rather than being bound to the node
itself).[RFC 3027][RFC 3715]
Atkinson Expires in 6 months [Page 14]
Internet Draft ILNP Intro 24 JUN 2010
To resolve the issue of IPsec interoperability through a
NAT deployment, UDP encapsulation of IPsec is commonly
used today.[RFC 3948]
With this proposal, the IP Security protocols, AH and ESP,
are enhanced to bind Security Associations only to
Identifier values and never to Locator values (and also
not to an entire 128-bit IPv6 address).
Similarly, key management protocols used with IPsec would be
enhanced to deprecate use of IP addresses as identifiers and
to substitute the use of the new Identifier for that
purpose.
This small change enables IPsec to work in harmony with
multihoming, mobility, and localised addressing. [MILCOM08]
[MILCOM09] Further, it would obviate the need for specialised
IPsec NAT Traversal mechanisms, thus simplifying IPsec
implementations while enhancing deployability and
interoperability. [RFC 3948]
This change does not reduce the security provided by the
IP Security protocols.
8. DNS ENHANCEMENTS
As part of this proposal, additional DNS Resource Records have
been proposed in a separate document. [ILNP-DNS] These new
records store the Identifier and Locator values for nodes that
have been upgraded to support the Identifier-Locator Split Mode.
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 and Locator records correct in its
authoritative DNS server(s). [RFC 3007]
While some might be surprised, Secure Dynamic DNS Update is
available now in a very wide range of existing deployed systems.
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. [Liu-DNS] There are credible reports
that when a site deploys Microsoft's Active Directory, the site
(silently) automatically deploys Secure Dynamic DNS
Update. [Liu-DNS] So it appears that many sites have already
deployed Secure Dynamic DNS Update even though they might not be
aware they have already deployed that protocol. [Liu-DNS]
Atkinson Expires in 6 months [Page 15]
Internet Draft ILNP Intro 24 JUN 2010
Reverse DNS lookups, to find a node's Fully Qualified Domain Name
from the combination of a Locator and related Identifier value,
can be performed as at present.
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 will not be adversely affected by assigning
very short time-to-live (TTL) values to the Locator records of
typical nodes. It also means that it is preferable to deploy the
DNS server function on nodes that have longer TTL values, rather
than on nodes that have shorter 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) if
they have been cryptographically-generated [RFC 3972], or have
been created by the IPv6 Privacy Extensions [RFC 4941], or
otherwise have the EUI-64 scope bit at the "local-scope" value.
Note that a given ILNP session normally will use a single
Identifier value for the life of that session.
Existing DNS specifications require that DNS clients and DNS
resolvers obey 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.
As a practical matter, it is not sensible to flush all Locator
values associated with an existing session's remote node from
the local node's ILNP Correspondent Cache. Instead, Locator
values in the ILNP Correspondent Cache SHOULD be marked as
"aged" when their TTL has expired until either the next Locator
Update message is received or there is other indication that
a given Locator is not working any longer.
During a long transition period, a node that is I/L-enabled
SHOULD have not only ID and L64 (or ID and LP) records present
in its authoritative DNS server, but also SHOULD have AAAA
records in the DNS for the benefit of non-upgraded nodes.
This capability might be implemented strictly inside a DNS
server, whereby the DNS server synthesised a set of AAAA records
to advertise from the ID and L64 values that the node has kept
updated in that DNS server.
Existing DNS specifications require that a DNS resolver or
Atkinson Expires in 6 months [Page 16]
Internet Draft ILNP Intro 24 JUN 2010
DNS client ignore unrecognised DNS record types. So
gratuitously appending ID and L64 records as "additional data"
in DNS responses to AAAA queries ought not create any
operational issues.
9. REFERRALS & APPLICATION PROGRAMMING INTERFACES
This section is concerned with support for using
existing ("legacy") applications over ILNP, including
both referrals and APIs.
9.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.
9.2 Java APIs
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.
9.3 Referrals in the Future
The approach proposed in [ID-Referral] appears to be very
Atkinson Expires in 6 months [Page 17]
Internet Draft ILNP Intro 24 JUN 2010
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 more sensible approach to referrals would be to use
Fully-Qualified Domain Names (FQDNs), as is commonly done
today with web URLs. This is approach is highly portable
across different network protocols, even with both the IPv4
Internet or the IPv6 Internet.
10. BACKWARDS COMPATIBILITY
First, if one compares Figure 1 and Figure 2, one can see
that IPv6 with the Identifier/Locator Split enhancement is
fully backwards compatible with existing IPv6. This means
that no router software or silicon changes are necessary to
support the proposed enhancements. A router would be
unaware whether the packet being forwarded were classic IPv6
or the proposed enhanced version of IPv6. So no changes to
IPv6 routers is required to deploy this proposal.
Further, IPv6 Neighbour Discovery should work fine as is.
If a node that has been enhanced to support the Identifier/
Locator Split mode initiates an IP session with another node,
normally it will first perform a DNS lookup on the responding
node's DNS name. If the initiator node does not find any ID
or L64 DNS resource records for the responder node, then the
initiator uses the Classical IPv6 mode of operation for the
new session with the responder, rather than trying to use
the I/L Split mode for that session.
If the responder node for a new IP session has not been enhanced
to support the I/L Split mode and receives initial packet(s)
containing the Nonce Destination Option, the responder will drop
the packet and send an ICMP Parameter Problem error message back
to the initiator.
If the initiator node does not receive a response from the
responder in a timely manner (e.g. within TCP timeout for a TCP
session) and also does not receive an ICMP Unreachable error
message for that packet, OR if the initiator receives an ICMP
Parameter Problem error message for that packet, then the
initiator knows that the responder is not able to support the I/L
Split Operating mode. In this case, the initiator node SHOULD
Atkinson Expires in 6 months [Page 18]
Internet Draft ILNP Intro 24 JUN 2010
try again to create the new IP session but this time OMITTING the
Nonce Destination Option, and this time operating in Classic IPv6
mode, rather than I/L Split mode.
Finally, since an ILNP node is also a fully-capable IPv6 node,
then the upgraded node can use any standardised IPv6 mechanisms
for communicating with a legacy IPv6 node (i.e. an IPv6 node
without ILNP capability enhancements). So ILNP will in no case
be worse than existing IPv6, and in many cases ILNP will out
perform existing IPv6.
11. INCREMENTAL DEPLOYMENT
If a node has been enhanced to support the Identifier/ Locator
Split operating mode, that node's fully-qualified domain name
will normally have one or more ID records and one or more L64
records associated with it in the DNS.
When a host ("initiator") initiates a new IP session with a
correspondent ("responder"), it normally will perform a DNS
lookup to determine the address(es) of the responder. A host
that has been enhanced to support the Identifier/ Locator Split
operating mode normally will look for Identifier ("ID") and
Locator ("L64") records in any received DNS replies. DNS servers
that support ID and L64 records SHOULD include them (when they
exist) as additional data in all DNS replies to queries for
DNS AAAA records.[ILNP-DNS]
If the initiator supports the I/L Split mode and from DNS
information learns that the responder also supports the
I/L Split mode, then the initiator will generate an
unpredictable nonce value, store that value in a local
Correspondent Cache, which is described in more detail below,
and will include the Nonce Destination Option in its
initial packet(s) to the responder.[ILNP-Nonce]
If the responder supports the I/L Split mode and receives
initial packet(s) containing the Nonce Destination Option,
the responder will thereby know that the initiator supports
the I/L Split mode and the responder will also operate in
I/L Split mode for this new IP session.
If the responder supports the I/L Split mode and receives
initial packet(s) NOT containing the Nonce Destination Option,
the responder will thereby know that the initiator does NOT
support the I/L Split mode and the responder will operate
in classic IPv6 mode for this new IP session.
Atkinson Expires in 6 months [Page 19]
Internet Draft ILNP Intro 24 JUN 2010
The previous section described how interoperability between
enhanced nodes and non-enhanced nodes is retained even if a
non-enhanced node erroneously has ID and/or L64 DNS resource
records in place (e.g. due to some accident).
The mobility capabilities of ILNP might be the most important in
the deployment world. Despite substantial good efforts by many,
neither Mobile IPv4 nor Mobile IPv6 are widely used at present.
However, much of the recent work in operating systems has focused
on support for mobile devices (e.g. mobile telephone handsets,
hand-held music players, hand-held organisers). Those devices
probably represent the fastest growth segment of the Internet at
present. Moreover, many vendors of such devices have included
significant networking protocol improvements in incremental
operating system updates, rather than always waiting for a new
major release to add networking facilities. However, other users
or vendors might be more interested by the new security models
enabled by having Identifiers different from Locators, or they
might be more interested in the ability to provide node-specific
multi-homing, rather than always multi-homing an entire site. In
the end, the marketplace has myriad users with various functional
needs. The set of improvements offered by ILNP is broad, and
should appeal to a wide range of vendors and users.
12. IMPLEMENTATION CONSIDERATIONS
This section discusses implementation considerations that
are not otherwise discussed in the ILNP Internet-Drafts.
12.1 ILNP Correspondent Cache
An ILNP-capable node will need to modify its network protocol
implementation to add an ILNP Correspondent Cache. In theory,
this cache is within the ILNP network-layer. However, many
network protocol implementations do not have strict protocol
separation or layering. In the interest of efficient
implementation, and to avoid unduly restricting implementers,
an ILNP implementation is not required to limit the
accessibility of ILNP Correspondent Cache to the network-layer.
The ILNP Correspondent Cache contains at least the following
inter-related data elements:
Set of Local Locator(s)
& Preference value for each Locator
Set of Correspondent' Locator(s)
& Preference value for each Locator
Set of Local Identifier(s)
Atkinson Expires in 6 months [Page 20]
Internet Draft ILNP Intro 24 JUN 2010
Set of Correspondent's Identifier(s)
Nonce used from the local node to that correspondent
Nonce used from that correspondent to the local node
Valid Time
Lookups in the ILNP Correspondent Cache normally use an
(Correspondent Identifier, Nonce) tuple as a 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.
The Valid Time field holds the (UTC) time (measured as seconds
since January 1st 1970, as with Network Time Protocol) through
which this ILNP session information is valid. A table entry
entry is current if the node's current time is less than or equal
to the time in the Valid Time field, while a table entry is aged
if the node's current time is greater than the time in the Valid
Time field.
12.2 ICMP Locator Updates
While ILNP's ICMP Locator Update message is defined in a
separate document [ILNP-ICMP], it is worth mentioning that
received authenticated Locator Update messages cause the
ILNP Correspondent Cache described just above to be updated.
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.
13. SECURITY CONSIDERATIONS
This proposal outlines a proposed evolution for the Internet
Architecture to provide improved capabilities. This section
discusses security considerations for this proposal.
13.1 Authentication of Locator Updates
A separate document [ILNP-Nonce] proposed a new IPv6
Destination Option that can be used to carry a session nonce
end-to-end between communicating nodes. That nonce provides
protection against off-path attacks on an Identifier/Locator
session. The Nonce Destination Option is used ONLY for IP
sessions in the Identifier/Locator Split mode.
Ordinary IPv6 is vulnerable to on-path attacks unless
the IP Authentication Header or IP Encapsulating Security
Atkinson Expires in 6 months [Page 21]
Internet Draft ILNP Intro 24 JUN 2010
Payload is in use. So the Nonce Destination Option
only seeks to provide protection against off-path attacks
on an IP session -- equivalent to ordinary IPv6 when
not using IP Security.
When the Identifier/Locator split mode is in use for an
existing IP session, the Nonce Destination Option MUST be
included in any ICMP control messages (e.g. ICMP Unreachable,
ICMP Locator Update) sent with regard to that IP session.
It is common to have non-symmetric paths between two nodes
on the Internet. To reduce the number of on-path nodes that
know the Nonce value for a given session when the I/L split
mode is in use, a nonce value is unidirectional, not
bidirectional. For example, for a session between two nodes
A and B, one nonce value is used from A to B and a different
nonce value is used from B to A.
When in the I/L Split operating mode for an existing IP
session, ICMP control messages received without a Nonce
Destination Option MUST be discarded as forgeries. This
security event SHOULD be logged.
When in the I/L Split operating mode for an existing IP
session, ICMP control messages received without a correct
nonce value inside the Nonce Destination Option MUST be
discarded as forgeries. This security event SHOULD be logged.
When in the I/L Split operating mode for an existing IP
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).
For ID/Locator Split mode sessions operating in higher risk
environments, the use of the cryptographic authentication
provided by IP Authentication Header is recommended
*in addition* to concurrent use of the Nonce Destination
Option.
It is important to note that at present an IPv6 session is
entirely vulnerable to on-path attacks unless IPsec is in use
for that particular IPv6 session, so the security properties
of the new proposal are never worse than for existing IPv6.
13.2 Forged Identifier Attacks
Atkinson Expires in 6 months [Page 22]
Internet Draft ILNP Intro 24 JUN 2010
In the deployed Internet, active attacks using packets with a
forged Source IP Address have been publicly known at least since
early 1995.[CA-1995-01] While these exist in the deployed
Internet, they have not been widespread. This is equivalent to
the issue of a forged Identifier value and demonstrates that this
is not a new threat created by the Identifier/Locator-split mode
of operation.
One mitigation for these attacks has been to deploy Source IP
Address Filtering.[RFC 2827] [RFC 3704] Jun Bi at U. Tsinghua
cites Arbor Networks as reporting that this mechanism has less
than 50% deployment and cites an MIT analysis indicating that at
least 25% of the deployed Internet permits forged source IP
addresses.
Other parts of this document discuss the probability of an
accidental duplicate Identifier being used on the Internet.
However, this sub-section instead focuses on methods for
mitigating attacks based on packets containing deliberately
forged Source Identifier values.
First, the recommendations of [RFC 2827] & [RFC 3704] remain.
So any packets that have a forged Locator value can be easily
filtered using existing widely available mechanisms.
Second, the receiving node does not blindly accept any packet
with the proper Source Identifier and proper Destination
Identifier as an authentic packet. Instead, each node operating
the I/L-split mode maintains an ILNP Correspondent Cache for each
of its correspondents, as described above. This 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). The correspondent cache also contains
the currently valid set of Locators and set of Identifiers for
each correspondent node. If a received 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 is dropped without further processing as an
invalid packet, 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 attacker from stealing an existing session.
Third, any node can distinguish different nodes using the same
Identifier value by other properties of their sessions. IPv6
Neighbor Discovery prevents more than one node from using the
same source (Locator + Identifier) pair at the same time. So
cases of different nodes using the same Identifier value will
Atkinson Expires in 6 months [Page 23]
Internet Draft ILNP Intro 24 JUN 2010
involve nodes that have different sets of valid Locator values.
A node can thus demux based on the combination of Source Locator
and Source Identifier if necessary. If IP Security is in use,
the combination of the Source Identifier and the SPI value would
be sufficient to demux two different sessions.
Finally, deployments in high threat environments also SHOULD use
the IP Authentication Header to authenticate control traffic and
data traffic. Because in the I/L-split mode, IP Security binds
only to the Identifier values, and never to the Locator values,
this enables a mobile or multi-homed node to use IPsec even when
its Locator value(s) have just changed.
13.3 IP Security Enhancements
The IP Security standards are enhanced here by binding IPsec
Security Associations to the Identifiers of the session
endpoints, rather than binding IPsec Security Associations
to the IP Addresses as at present. This change enhances the
deployability and interoperability of the IP Security standards,
but does not decrease the security provided by those protocols.
Also, the IP Authentication Header omits the Source Locator and
Destination Locator fields from its authentication calculations
when ILNP is in use. This enables IP AH to work well even
through a NAT or other situation where a Locator value might
change during transit.
13.4 DNS Security
The DNS enhancements proposed here are entirely compatible with,
and can be protected using, the existing IETF standards for DNS
Security.[RFC 4033] The Secure DNS Dynamic Update mechanism used
here is also used unchanged.[RFC 3007] So there is no change to
the security properties of the Domain Name System or of DNS
servers due to ILNP.
13.5 Firewall Considerations
In the proposed new scheme, firewalls are able to authenticate
ICMP control messages arriving on the external interface. This
enables more thoughtful handling of ICMP messages by firewalls
than is commonly the case at present. As the firewall is along
the path between the communicating nodes, the firewall can snoop
on the Session Nonce being carried in the initial packets of an
I/L Split mode session. The firewall can verify the correct
nonce is present on incoming control packets, dropping any
control packets that lack the correct nonce value.
Atkinson Expires in 6 months [Page 24]
Internet Draft ILNP Intro 24 JUN 2010
By always including the nonce, even when IP Security is also in
use, the firewall can filter out off-path attacks. In any event,
a forged packet from an on-path attacker will still be detected
when the IPsec input processing occurs in the receiving node;
this will cause that forged packet to be dropped rather than
acted upon.
13.6 Neighbor Discovery Authentication
Nothing in this proposal prevents sites from using the Secure
Neighbor Discovery (SEND) proposal for authenticating IPv6
Neighbor Discovery. [RFC 3971]
13.7 Site Topology Obfuscation
A site that wishes to obscure its internal topology information
MAY do so by deploying site border routers that rewrite the
Locator values for the site as packets enter or leave the site.
For example, a site might choose to use a ULA prefix internally
for this reason.[RFC 4193] [ID-ULA] In this case, the site border
routers would rewrite the Source Locator of ILNP packets leaving
the site to a global-scope Locator associated with the site.
Also, those site border routers would rewrite the Destination
Locator of packets entering the site from the global-scope
Locator to an appropriate interior ULA Locator for the
destination node.[MILCOM08]
13.8 Path Liveness
Some perceive that an Identifier-Locator Split architecture
creates a new issue that is sometimes called "Locator Liveness"
or "Path 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 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.
So we see that using an Identifier/Locator Split architecture
does not create this issue, nor does it make this issue worse
Atkinson Expires in 6 months [Page 25]
Internet Draft ILNP Intro 24 JUN 2010
than it is with the deployed IPv4 Internet.
In ILNP, the same conceptual approach described in [RFC 5534] 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, which existing methods leverage
transport-layer session state information that the communicating
end systems are already keeping for transport-layer protocol
reasons.
Last, it is important for the reader to understand that the
mechanism described in [ILNP-ICMP] is a performance optimisation,
significantly shortening the layer-3 handoff time if/when a
correspondent changes location. Architecturally, using ICMP
is no different from using UDP, of course.
14. IANA CONSIDERATIONS
This document has no IANA considerations.
15. REFERENCES
This section provides both normative and informative
references relating to this note.
15.1. Normative References
[RFC 826] D. Plummer, "Ethernet Address Resolution Protocol:
Or Converting Network Protocol Addresses to
48 bit Ethernet Address for Transmission on
Ethernet Hardware", RFC 826, November 1982.
[RFC 2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997.
[RFC 2460] S. Deering & R. Hinden, "Internet Protocol
Version 6 Specification", RFC-2460,
December 1998.
[RFC 3007] B. Wellington, "Secure Domain Name System
Dynamic Update", RFC-3007, November 2000.
[RFC 4033] R. Arends, et alia, "DNS Security Introduction
and Requirements", RFC-4033, March 2005.
[RFC 4219] R. Hinden & S. Deering, "IP Version 6
Addressing Architecture", RFC-4219,
Atkinson Expires in 6 months [Page 26]
Internet Draft ILNP Intro 24 JUN 2010
February 2006.
[RFC 4861] T. Narten, E. Nordmark, W. Simpson, & H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)",
RFC 4861, September 2007.
15.2. Informative References
[8+8] M. O'Dell, "8+8 - An Alternate Addressing
Architecture for IPv6", Internet-Draft,
October 1996.
[CA-1995-01] US CERT, "IP Spoofing Attacks and Hijacked
Terminal Connections", CERT Advisory 1995-01,
Issued 23 JAN 1995, Revised 23 SEP 1997.
[GSE] M. O'Dell, "GSE - An Alternate Addressing
Architecture for IPv6", Internet-Draft,
February 1997.
[ID-ULA] R. Hinden, G. Huston, & T. Narten, "Centrally
Assigned Unique Local IPv6 Unicast Addresses",
draft-ietf-ipv6-ula-central-02.txt, 15 June 2007.
[ID-Referral] B. Carpenter and others, "A Generic Referral
Object for Internet Entities",
draft-carpenter-behave-referral-object-01,
20 October 2009.
[IEEE-EUI] IEEE Standards Association, "Guidelines for
64-bit Global Identifier (EUI-64)", IEEE,
2007.
[IEN 1] C.J. Bennett, S.W. Edge, & A.J. Hinchley,
"Issues in the Interconnection of Datagram
Networks", Internet Experiment Note (IEN) 1,
INDRA Note 637, PSPWN 76, University College
London, London, England, UK, WC1E 6BT,
29 July 1977.
http://www.postel.org/ien/ien001.pdf
[IEN 19] J. F. Shoch, "Inter-Network Naming, Addressing,
and Routing", IEN-19, January 1978.
[IEN 23] J. F. Shoch, "On Names, Addresses, and
Routings", IEN-23, January 1978.
[IEN 31] D. Cohen, "On Names, Addresses, and Routings
Atkinson Expires in 6 months [Page 27]
Internet Draft ILNP Intro 24 JUN 2010
(II)", IEN-31, April 1978.
[ILNP-Nonce] R. Atkinson, "Nonce Destination Option",
draft-rja-ilnp-nonce-03.txt, June 2010.
[ILNP-DNS] R. Atkinson, "DNS Resource Records for ILNP",
draft-rja-ilnp-dns-04.txt, June 2010.
[ILNP-ICMP] R. Atkinson, "ICMP Locator Update message"
draft-rja-ilnp-icmp-02.txt, June 2010.
[IPng95] D. Clark, "A thought on addressing",
electronic mail message to IETF IPng WG,
Message-ID: 9501111901.AA28426@caraway.lcs.mit.edu,
Laboratory for Computer Science, MIT,
Cambridge, MA, USA, 11 January 1995.
[Liu-DNS] C. Liu & P. Albitz, "DNS & Bind", 5th Edition,
O'Reilly & Associates, Sebastopol, CA, USA,
May 2006. ISBN 0-596-10057-4
[MobiArch07] R. Atkinson, S. Bhatti, & S. Hailes,
"Mobility as an Integrated Service Through
the Use of Naming", Proceedings of
ACM MobiArch 2007, August 2007,
Kyoto, Japan.
[MobiArch08] R. Atkinson, S. Bhatti, & S. Hailes,
"Mobility Through Naming: Impact on DNS",
Proceedings of ACM MobiArch 2008, August 2008,
Seattle, WA, USA.
[MobiWAC07] R. Atkinson, S. Bhatti, & S. Hailes,
"A Proposal for Unifying Mobility with
Multi-Homing, NAT, & Security",
Proceedings of ACM MobiWAC 2007, Chania,
Crete. ACM, October 2007.
[MILCOM08] R. Atkinson, S. Bhatti, & S. Hailes,
"Harmonised Resilience, Security, and Mobility
Capability for IP", Proceedings of IEEE
Military Communications (MILCOM) Conference,
San Diego, CA, USA, November 2008.
[MILCOM09] R. Atkinson, S. Bhatti, & S. Hailes,
"Site-Controlled Secure Multi-Homing and
Traffic Engineering For IP", Proceedings of
IEEE Military Communications (MILCOM) Conference,
Atkinson Expires in 6 months [Page 28]
Internet Draft ILNP Intro 24 JUN 2010
Boston, MA, USA, October 2009.
[PHG02] Pappas, A, S. Hailes, & R. Giaffreda,
"Mobile Host Location Tracking through DNS",
Proceedings of IEEE London Communications
Symposium, IEEE, September 2002, London,
England, UK.
[SBK2002] Alex C. Snoeren, Hari Balakrishnan, & M. Frans
Kaashoek, "Reconsidering Internet Mobility",
Proceedings of 8th Workshop on Hot Topics in
Operating Systems, 2002.
[SIPP94] Bob Smart, "Re: IPng Directorate meeting in
Chicago; possible SIPP changes", electronic
mail to the IETF SIPP WG mailing list,
Message-ID:
199406020647.AA09887@shark.mel.dit.csiro.au,
Commonwealth Scientific & Industrial Research
Organisation (CSIRO), Melbourne, VIC, 3001,
Australia, 2 June 1994.
[RFC 814] D.D. Clark, "Names, Addresses, Ports, and
Routes", RFC-814, July 1982.
[RFC 1498] J.H. Saltzer, "On the Naming and Binding of
Network Destinations", RFC-1498, August 1993.
[RFC 1631] K. Egevang & P. Francis, "The IP Network
Address Translator (NAT)", RFC-1631, May 1994.
[RFC 2827] P. Ferguson & D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ
IP Source Address Spoofing", RFC-2827, May 2000.
[RFC 3022] P. Srisuresh & K. Egevang, "Traditional IP
Network Address Translator", RFC-3022,
January 2001.
[RFC 3027] M. Holdrege and P Srisuresh, "Protocol
Complications of the IP Network Address
Translator", RFC-3027, January 2001.
[RFC 3704] F. Baker & P. Savola, "Ingress Filtering for
Multihomed Networks, RFC-3704, March 2004.
[RFC 3715] B. Aboba and W. Dixon, "IPsec-Network Address
Translation (NAT) Compatibility Requirements",
Atkinson Expires in 6 months [Page 29]
Internet Draft ILNP Intro 24 JUN 2010
RFC-3715, March 2004.
[RFC 3775] D. Johnson, C. Perkins, and J. Arkko, "Mobility
Support in IPv6", RFC-3775, June 2004.
[RFC 3948] A. Huttunen, et alia, "UDP Encapsulation of
IPsec ESP Packets", RFC-3948, January 2005.
[RFC 3971] J. Arkko, J. Kempf, B. Zill, & P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC-3971
March 2005.
[RFC 3972] T. Aura, "Cryptographically Generated Addresses
(CGAs)", RFC-3972, March 2005.
[RFC 4193] R. Hinden & B. Haberman, "Unique Local IPv6
Unicast Addresses, RFC-4193, October 2005.
[RFC 4941] T. Narten, R. Draves, & S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration
in IPv6", RFC-4941, September 2007.
[RFC 5061] R. Stewart, Q. Xie, M. Tuexen, S. Maruyama, &
M. Kozuka, "Stream Control Transmission Protocol
(SCTP) Dynamic Address Reconfiguration", RFC-5061,
September 2007.
[RFC 5534] J. Arkko & I. van Beijnum, "Failure Detection and
Locator Pair Exploration Protocol for IPv6
Multihoming", RFC-5534, June 2009.
[TeleSys] R. Atkinson, S. Bhatti, & S. Hailes,
"ILNP: Mobility, Multi-Homing, Localised Addressing
and Security Through Naming", Telecommunications
Systems, Volume 42, Number 3-4, pp 273-291,
Springer-Verlag, December 2009, ISSN 1018-4864.
ACKNOWLEDGEMENTS
Steve Blake, Mohamed Boucadair, Saleem Bhatti, Noel Chiappa,
Steve Hailes, Joel Halpern, Mark Handley, Tony Li, and Yakov
Rehkter (in alphabetical order) provided review and feedback on
earlier versions of this document. Noel Chiappa graciously
provided the author with copies of the original email messages
cited here as [SIPP94] and [IPng95], which enabled the precise
citation of those messages herein.
AUTHOR'S ADDRESS
Atkinson Expires in 6 months [Page 30]
Internet Draft ILNP Intro 24 JUN 2010
R. Atkinson
Consultant
McLean, VA
22102 USA
Email: rja.lists@gmail.com
Expires: 24 DEC 2010
Atkinson Expires in 6 months [Page 31]