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

Versions: 00 01 02 03 04 05 06 07 08 09 10 11                           
Internet Draft                                               R. Atkinson
draft-rja-ilnp-intro-00.txt                             Extreme Networks
Category: Experimental
Expires April 2007                                      16 February 2008

                       ILNP Concept of Operations

Status of this Memo

   Distribution of this memo is unlimited.

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 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 document is a contribution to the IRTF Routing Research Group.
   It is NOT a contribution to the IETF or to any IETF Working Group
   or to any IETF Area.

   This documents the Concept of Operations for an experimental
   extension to IPv6 which is known as the Identifier Locator
   network protocol.

Atkinson           Expires August 2008                          [Page 1]

Internet Draft     ILNP Intro         16 February 2008

Table of Contents

   1. Introduction ....................................................2
   2. Transport Protocols..............................................4
   3. Multi-Homing.....................................................5
   4. Mobility.........................................................5
   5. Localised Addressing.............................................6
   6. IP Security Enhancements.........................................6
   7. Backwards Compatibility & Incremental Deployment.................7
   8. Security Considerations .........................................8
   9. IANA Considerations .............................................9
  10. References ......................................................9

1. Introduction

   At present, the IRTF Routing Research Group is studying different
   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.

   This architectural concept 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 fields.  Afterwards, Mike
   O'Dell persued this concept in Internet-Drafts describing "GSE" or
   "8+8".[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

   The crux of this proposal is to split each 128-bit IPv6 address into
   two separate fields, with crisp semantics for each.  It is worth
   remembering here that an IPv6 address names a specific interface on a
   node, since the new scheme will be different in that regard.

Atkinson           Expires August 2008                          [Page 2]

Internet Draft     ILNP Intro         16 February 2008

                            1        1                2               3
    0       4      8        2        6                4               1
   | Version| Traffic Class |           Flow Label                    |
   |          Payload Length         |   Next Header  |  Hop Limit    |
   |                          Source Address                          |
   +                                                                  +
   |                                                                  |
   +                                                                  +
   |                                                                  |
   +                                                                  +
   |                                                                  |
   |                        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.
   Identifiers are unique within the context of a given Locator;
   in many cases, Identifiers might happen to be globally unique,
   but that is not a functional requirement for this proposal.

                            1        1                2               3
    0       4      8        2        6                4               1
   | Version| Traffic Class |           Flow Label                    |
   |          Payload Length         |   Next Header  |   Hop Limit   |

Atkinson           Expires August 2008                          [Page 3]

Internet Draft     ILNP Intro         16 February 2008

   |                          Source Locator                          |
   +                                                                  +
   |                                                                  |
   |                         Source Identifier                        |
   +                                                                  +
   |                                                                  |
   |                        Destination  Locator                      |
   +                                                                  +
   |                                                                  |
   |                        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.

   So this proposal enhances the architecture by adding crisp
   clear semantics for the Identifier and for the Locator,
   removing the semantically muddled IP address, and updating
   end system protocols slightly, without requiring router
   changes.  With these enhancements, we have improved
   architectural support not only for multi-homing, but also for
   mobility, localised addressing, and IP Security.

2. Transport Protocols

   At present, transport protocols include a pseudo-header that
   includes certain network-layer fields, the IP addresses for
   the session, in its calculation.

   With this proposal, transport protocols include 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 an IP session, the network
   layer zeros the Locator fields before passing the information
   up to the transport protocol in use.

Atkinson           Expires August 2008                          [Page 4]

Internet Draft     ILNP Intro         16 February 2008

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

   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-omain routing system (e.g.
   RIB/FIB size increases beyond the minimal RIB/FIB
   size that would be required to reach all sites).

   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.  The node also
   will use Secure Dynamic DNS Update to alter the set of
   currently valid L records associated with that node.
   This second step ensures that any new correspondents can
   reach the node.[ILNP-ICMP]

   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 possible.  This would change the
   number of DNS Updates required from O(number of nodes
   at the site/subnetwork that moved) to O(1).

4.  Mobility

   There are no standardised mechanisms to update transport
   protocols with new IP addresses in use for the session
   (SCTP might be an exception, depending on the progress
   of a current Internet-Draft).

   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.  So, the several approaches

Atkinson           Expires August 2008                          [Page 5]

Internet Draft     ILNP Intro         16 February 2008

   to Mobile IP seek to hide the change in location (and
   corresponding change in IP addresses) via tunnelling,
   home agents, foreign agents, and so forth.  All of this
   can add substantial complexity to IP mobility approaches.

   By contrast, this new proposal hides the nodes location
   information from the transport layer protocols at all times.
   In this proposal, mobility is supported using the same
   mechanisms as multihoming.  That is, the us of Locator values
   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 L records in the DNS for that node.
   This enables any new correspondents to correctly initiate a new
   session with the node at its new location.

   Note that we can (and do) treat network mobility (as well
   as node mobility) as 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.

5. Localised Addressing

   As the Locator value no longer forms part of the node
   session state (e.g. TCP pseudo-header), it is easier
   to implement localised 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.
   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 can be maintained.

   Note that localised addressing would work in harmony
   with multihoming, mobility, and IP Security.

6.  IP Security Enhancements

   The IP Security protocols, AH and ESP, should be
   enhanced to bind Security Associations only to
   Identifier values and never to Locator values

Atkinson           Expires August 2008                          [Page 6]

Internet Draft     ILNP Intro         16 February 2008

   (and not to an entire 128 bit IPv6 address).

   This small change enables IPsec to work in harmony
   with multihoming, mobility, and localised addressing.
   Further, it would obviate the need for specialised
   IPsec NAT Traversal mechanisms, thus simplifying
   IPsec implementations while enhancing deployability
   and interoperability.

7. Backwards Compatibility & Incremental Deployment

   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.

   Further, IPv6 Neighbour Discovery should work fine without
   any significant protocol changes.

   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 I records and one or more L
   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 ("I") and
   Locator ("L") records in any received DNS replies.  DNS servers
   that support I and L 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 session 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

Atkinson           Expires August 2008                          [Page 7]

Internet Draft     ILNP Intro         16 February 2008

   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.

   If the responder does not 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 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 should
   try again to create the new IP session but this time
   OMITTING the Nonce Destination Option.

8. Security Considerations

   This proposal defines a new non-cryptographic Nonce
   Destination Option.  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.

   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.

Atkinson           Expires August 2008                          [Page 8]

Internet Draft     ILNP Intro         16 February 2008

   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.

   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

9. IANA Considerations

   This document has no IANA considerations.

10.  References

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

10.1.  Normative References

   None at this time.

10.2.  Informative References

   [8+8]        M. O'Dell, "8+8 - An Alternate Addressing
                Architecture for IPv6", Internet-Draft, October 1996.
   [ABH07]      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.
   [Clark82]    D.D. Clark, "Names, Addresses, Ports, and Routes",
                RFC-814, July 1982.
   [GSE]        M. O'Dell, "GSE - An Alternate Addressing
                Architecture for IPv6", Internet-Draft,
                February 1997.
   [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",
                February 2008.
   [ILNP-DNS]   R. Atkinson, "DNS Resource Records for
                Identifier/Locator Use", February 2008.
   [ILNP-ICMP]  R. Atkinson, "ICMP Locator Update message"

Atkinson           Expires August 2008                          [Page 9]

Internet Draft     ILNP Intro         16 February 2008

                February 2008.
   [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.
   [Saltzer93]  Saltzer, J, "On the Naming and Binding of Network
                Destinations", RFC-1498, August 1993.

   (Additional references to be added later.)

Author's Address

   R. Atkinson
   Extreme Networks
   3585 Monroe Street
   Santa Clara, CA
   95051  USA

   Telephone: +1 (408)579-2800
   Email:     rja@extremenetworks.com

Atkinson           Expires August 2008                         [Page 10]

Internet Draft     ILNP Intro         16 February 2008

Full Copyright Statement

"Copyright (C) The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights."

"This document and the information contained herein are provided

Intellectual Property

  The IETF takes no position regarding the validity or scope of any
  Intellectual Property Rights or other rights that might be claimed
  to pertain to the implementation or use of the technology
  described in this document or the extent to which any license
  under such rights might or might not be available; nor does it
  represent that it has made any independent effort to identify any
  such rights.  Information on the procedures with respect to
  rights in RFC documents can be found in BCP 78 and BCP 79.

  Copies of IPR disclosures made to the IETF Secretariat and any
  assurances of licenses to be made available, or the result of an
  attempt made to obtain a general license or permission for the use
  of such proprietary rights by implementers or users of this
  specification can be obtained from the IETF on-line IPR repository
  at http://www.ietf.org/ipr.

  The IETF invites any interested party to bring to its attention
  any copyrights, patents or patent applications, or other
  proprietary rights that may cover technology that may be required
  to implement this standard.  Please address the information to the
  IETF at ietf-ipr@ietf.org.

  This document may not be modified, and derivative works of it
  may not be created.

  This document may only be posted in an Internet-Draft.

Atkinson           Expires August 2008                         [Page 11]