[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11                           
Internet Draft                                          R. Atkinson
Expires:  08 AUG 2010                               8 February 2010
Category: Experimental

                       ILNP Concept of Operations

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         08 FEB 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

   The list of Internet-Draft Shadow Directories can be accessed at


   This documents the Concept of Operations for an experimental
   extension to IPv6 which is known as the Identifier Locator
   Network Protocol (ILNP).

Table of Contents

   1. Introduction ...............................................2
   2. Transport Protocols.........................................5
   3. Mobility....................................................6
   4. Multi-Homing................................................8
   5. Localised Addressing.......................................10
   6. IP Security Enhancements...................................11
   7. DNS Enhancements...........................................12
   8. Referrals & Application Programming Interfaces.............13
   9. Backwards Compatibility....................................14
  10. Incremental Deployment.....................................15
  11. Implementation Considerations..............................17
  12. Security Considerations ...................................18
  13. IANA Considerations .......................................22
  14. References ................................................22


   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, and mindful of that important
   prior work, the author has been examining enhancements to certain
   naming aspects of the Internet Architecture. [MobiArch07]

Atkinson           Expires in 6 months                          [Page 2]

Internet Draft     ILNP Intro         08 FEB 2010

   [MobiWAC07] [MobiArch08] [MILCOM08] [MILCOM09] [TeleSys]

   The architectural concept behind ILNP derives originally from a
   note by Dave Clark to the IETF mailing list suggesting that the
   IPv6 address be split into separate Identifier and Locator

   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 antecedant work).  This current
   proposal differs from O'Dell's work in various ways.

   ILNP is an architecture, and can have more than one
   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.  For the remainder
   of this document, we simply write the less precise term ILNP,
   although ILNPv6 is the focus of this document.

   The crux of this proposal is to have different names for the
   identity of a node and the location of a node, with crisp
   semantics for each.  ILNPv6 splits the IPv6 address into two
   separate names: a 64-bit Locator and a 64-bit Identifier.  It is
   worth remembering here that an IPv6 address names a specific
   interface on a node, since with ILNP the Identifier names a node,
   not a specific interface on a node.

                            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 3]

Internet Draft     ILNP Intro         08 FEB 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.

   The low-order 64-bits of the IPv6 address become the Identifier.
   The Identifier provides a fixed-length identity for a node,
   rather than an identity for a specific interface of a node.
   Identifiers are bound to nodes, not to interfaces, and are
   in the same modified EUI-64 syntax already specified for
   IPv6.[RFC 2460][RFC 4219][IEEE-EUI]

   Identifiers can be either globally unique or locally unique.
   Locally unique Identifiers are unique within the context of their
   associated Locators.  Either globally unique or locally unique
   Identifiers can be used with this protocol.  However, locally
   unique Identifiers MUST NOT be used with other Locators without
   first ensuring uniqueness (e.g. by using IPv6 Neighbor
   Discovery's Duplicate Addess Detection (DAD) mechanism).

                            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 4]

Internet Draft     ILNP Intro         08 FEB 2010

   +                                                                  +
   |                                                                  |
   |                        Destination Identifier                    |
   +                                                                  +
   |                                                                  |

              Figure 2: Enhanced IPv6 Header

   Most commonly, a node's set of Identifiers are derived from the
   IEEE 802 or IEEE 1394 MAC addresses associated with that node.
   This use of MAC addresses to generate Identifiers is convenient
   and is not required.  Other methods also might be used to
   generate Identifiers. For example, one might derive Identifiers
   using cryptographic-generation or using methods specified in the
   IPv6 Privacy Extensions to State-Less Address Auto-Configuration
   (SLAAC). [RFC 3972, RFC 4941]

   This proposal 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

   With these naming enhancements, we have improved the architecture
   by adding explicit support not only for multi-homing, but also
   for mobility, localised addressing (e.g. NAT/NAPT), and IP

1.1 Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   "OPTIONAL" in this document are to be interpreted as described
   in RFC 2119. [RFC 2119]


   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
   multi-homing, mobility, IP Security, and localised addressing
   (e.g. using Network Address Translation).  [RFC 1631][RFC 3022]

Atkinson           Expires in 6 months                          [Page 5]

Internet Draft     ILNP Intro         08 FEB 2010

   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.


   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

   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
   mobility approaches, both in the initial deployment and also
   in ongoing operation.

Atkinson           Expires in 6 months                          [Page 6]

Internet Draft     ILNP Intro         08 FEB 2010

   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.

   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

   (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

Atkinson           Expires in 6 months                          [Page 7]

Internet Draft     ILNP Intro         08 FEB 2010

   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 receiption 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
   nfaster 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

Atkinson           Expires in 6 months                          [Page 8]

Internet Draft     ILNP Intro         08 FEB 2010

   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.


   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

   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, it 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.

   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
   subnetwork moves location, a DNS record optimisation is

Atkinson           Expires in 6 months                          [Page 9]

Internet Draft     ILNP Intro         08 FEB 2010

   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.


   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

   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
   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

Atkinson           Expires in 6 months                         [Page 10]

Internet Draft     ILNP Intro         08 FEB 2010

   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


   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]

   To resolve the issue of IPsec interoperability through a
   NAT deployment, UDP encapsulation of IPsec is commonly
   used today.[RFC 3948]

Atkinson           Expires in 6 months                         [Page 11]

Internet Draft     ILNP Intro         08 FEB 2010

   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

   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.


   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]

   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.

Atkinson           Expires in 6 months                         [Page 12]

Internet Draft     ILNP Intro         08 FEB 2010

   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 I/L Session Cache.  Instead, Locator values
   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

   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 DNS
   client ignore unrecognised DNS record types.  So gratuitously
   appending ID and L64 records as "additional data" in DNS
   responses to AAAA queries should not create any operational

Atkinson           Expires in 6 months                         [Page 13]

Internet Draft     ILNP Intro         08 FEB 2010


   This section is concerned with support for using
   existing ("legacy") applications over ILNP, including
   both referrals and APIs.

8.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.

8.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.

8.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).

Atkinson           Expires in 6 months                         [Page 14]

Internet Draft     ILNP Intro         08 FEB 2010

   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.


   First, if one comapres 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 inititator 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
   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

Atkinson           Expires in 6 months                         [Page 15]

Internet Draft     ILNP Intro         08 FEB 2010

   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.


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

   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,

Atkinson           Expires in 6 months                         [Page 16]

Internet Draft     ILNP Intro         08 FEB 2010

   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.


   This section discusses implementation considerations that
   are not otherwise discussed in the ILNP Internet-Drafts.

11.1  ILNP Session Cache

   An ILNP-capable node will need to modify its network protocol
   implementation to add an ILNP Session 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 Session Cache
   to the network-layer.

   The ILNP Session Cache contains at least the following
   inter-related data elements:

        Set of Local Locator(s)
        Set of Correspondent' Locator(s)
        Set of Local Identifier(s)
        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 Session Cache 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

Atkinson           Expires in 6 months                         [Page 17]

Internet Draft     ILNP Intro         08 FEB 2010

   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.


   This proposal outlines a proposed evolution for the Internet
   Architecture to provide improved capabilities.  This section
   discusses security considerations for this proposal.

12.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
   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

Atkinson           Expires in 6 months                         [Page 18]

Internet Draft     ILNP Intro         08 FEB 2010

   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

   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

   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.

12.2 Forged Identifier Attacks

   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

   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.

Atkinson           Expires in 6 months                         [Page 19]

Internet Draft     ILNP Intro         08 FEB 2010

   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 a session 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 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 session 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
   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.

12.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.

Atkinson           Expires in 6 months                         [Page 20]

Internet Draft     ILNP Intro         08 FEB 2010

   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.

12.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.

12.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 that nonce is
   present on incoming control packets, dropping any control packets
   that lack the correct nonce value.

   By always including the nonce, even when IP Security is also in
   use, the firewall can filter out all off-path attacks.  In this
   case, 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.

12.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]

12.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

Atkinson           Expires in 6 months                         [Page 21]

Internet Draft     ILNP Intro         08 FEB 2010

   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]

12.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

   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 [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
   session state information that the communicating end systems are
   already keeping (e.g. 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.


   This document has no IANA considerations.


Atkinson           Expires in 6 months                         [Page 22]

Internet Draft     ILNP Intro         08 FEB 2010

   This section provides both normative and informative
   references relating to this note.

14.1.  Normative References

   [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, February

14.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",
                 20 October 2009.

   [IEEE-EUI]   IEEE Standards Association, "Guidelines for
                64-bit Global Identifier (EUI-64)", IEEE,

Atkinson           Expires in 6 months                         [Page 23]

Internet Draft     ILNP Intro         08 FEB 2010


   [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.

   [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
                (II)", IEN-31, April 1978.

   [ILNP-Nonce] R. Atkinson, "Nonce Destination Option",
                draft-rja-ilnp-nonce-02.txt, February 2010.

   [ILNP-DNS]   R. Atkinson, "Additional DNS Resource Records",
                draft-rja-ilnp-dns-02.txt, February 2010.

   [ILNP-ICMP]  R. Atkinson, "ICMP Locator Update message"
                draft-rja-ilnp-icmp-01.txt, February 2010.

   [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.

Atkinson           Expires in 6 months                         [Page 24]

Internet Draft     ILNP Intro         08 FEB 2010

   [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,
                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.

   [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

Atkinson           Expires in 6 months                         [Page 25]

Internet Draft     ILNP Intro         08 FEB 2010

                Translation (NAT) Compatibility Requirements",
                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.


   Saleem Bhatti, Steve Hailes, Joel Halpern, Mark Handley, Tony Li,
   and Yakov Rehkter (in alphabetical order) provided review and
   feedback on earlier versions of this document.


   R. Atkinson
   McLean, VA, USA

Atkinson           Expires in 6 months                         [Page 26]

Internet Draft     ILNP Intro         08 FEB 2010

   Email:     rja.lists@gmail.com

   Expires: 08 AUG 2010

Atkinson           Expires in 6 months                         [Page 27]