[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-icmp-00.txt                              Extreme Networks
Category: Experimental
Expires: 10 June 2009                                   10 December 2008

                      ICMP Locator Update message

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 http://www.ietf.org/shadow.html.

 This document is a contribution to the IRTF Routing Research Group.
 It is neither a contribution to the IETF, nor to any IETF
 Working Group, nor to any IETF Area.


This describes an experimental ICMPv6 message type to dynamically
update Identifier/Locator bindings for an Identifier Locator
Network Protocol based upon IPv6.

Atkinson             Expires in 6 months                        [Page 1]

Internet Draft       ILNP ICMP            10 DEC 2008

Table of Contents

    1. Introduction ...........................................2
    2. Syntax..................................................3
    3. Transport Protocol Effects..............................4
    4. Backwards Compatibility.................................4
    5. Security Considerations ................................5
    6. IANA Considerations ....................................5
    7. References .............................................6

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.  In particular,
   the Identifier-Locator Network Protocol being described in this
   document and related Internet-Drafts is an evolution of IPv6. [ILNP-
   Intro] [ILNP-Nonce] [ILNP-DNS] [RFC-2460]

   The new ICMPv6 Locator Update message described in this document
   enables an enhanced node to update its correspondents about the
   currently valid set of Locators valid for use to reaching the node
   sending this message.

   This new ICMPv6 message must not be used for IP sessions operating in
   classic IPv6 mode; it must only be used for IP sessions that are
   operating in Identifier/Locator Split mode.

2. Syntax

   |  ICMP Type  |  ICMP Code    |        Checksum            |
   | Num of Locs |     RESERVED FOR FUTURE USE                |
   /                        Locator                           /

   ICMP Type:         This 8-bit field is set to a value that
                      indicates this is a Locator Update message.

Atkinson             Expires in 6 months                        [Page 2]

Internet Draft       ILNP ICMP            10 DEC 2008

   ICMP Code:         This 8-bit field indicates which kind of
                      ICMP Locator Update this is.  At present,
                      the only valid value is 0, which means
                      that this message contains all currently
                      valid Locator values for the sending node.

   Checksum:          This contains the ICMPv6 Checksum value
                      for this packet.

   Num of Locs:       This field contains the number of 64-bit
                      Locators that follow the RESERVED field.
                      This field must not contain the number zero,
                      as each ILNP node needs to be reachable via
                      at least 1 Locator value.  Multi-homed nodes
                      will have at least 2 Locator values.

   Reserved:          This 24-bit field must be sent as zero.
                      At this time, recipients should ignore the
                      contents of this field, as these bits are
                      reserved for future use.

   Locator:           This 64-bit field contains a valid Locator
                      that can be used to reach the sending node.
                      A variable number of Locator fields are
                      concatenated one after another.  These are
                      listed in priority order, with the first
                      Locator field containing the most preferred
                      Locator value.

3.  Transport Protocol Effects

   This message has no impact on any transport protocol.

   The message may affect where packets for a given transport
   session are sent, but one of the design objectives for the
   I/L Split Mode  (ILNP) is to decouple transport-protocols
   from network-layer changes.

4. Implementation Considerations

   Implementers may use any internal implementation they wish,
   provided that the external appearance is the same as this
   implementation approach.

   To support the Identifier/Locator Split operating mode, and
   retain the incremental deployability and backwards compatibility
   needed, the network layer needs a mode bit in the Transport Control
   Block (or its equivalent) to track which IP sessions are using

Atkinson             Expires in 6 months                        [Page 3]

Internet Draft       ILNP ICMP            10 DEC 2008

   the classic IPv6 mode and which IP sessions are using the
   Identifier/Locator Split mode.

   Further, when in the Identifier/Locator Split mode, nodes will
   need to retain a Correspondent Cache in the network layer that
   contains for each correspondent node:
        - Source Identifier(s) in use
        - Source Locator(s) in use
        - Destination Identifier(s) in use
        - Destination Locator(s) in use
        - Session Nonce value from Local Node to Correspondent Node
        - Session Nonce value from Correspondent Node to Local Node

5.  Backwards Compatibility

   For all sessions operating in Identifier/Locator Split mode,
   inside each node the high-order 64-bits ("Locator") are always
   set to zero before the packet is sent upwards to the transport
   protocol.  So any changes in Locator values used on the wire
   will be invisible to the transport protocol.  In this mode,
   transport-layer checksums (e.g.  TCP pseudo-header checksum)
   will be calculated with both Source Locator and Destination
   Locator fields set to all zero.

   For nodes or sessions not operating in Identifier/Locator Split
   mode, the ICMP Locator Update packet must be discarded
   by the recipient without being processed.

Atkinson             Expires in 6 months                        [Page 4]

Internet Draft       ILNP ICMP            10 DEC 2008

6. Security Considerations

   The ICMP Locator Update message must only be used for IP sessions
   operating in the Identifier/Locator Split mode.

   The experimental Nonce Destination Option [ILNP-Nonce] must be
   present in packets containing an ICMPv6 Locator Update message.
   Further, the received Nonce Destination Option must contain the
   correct nonce value for the packet to be accepted by the recipient
   and then passed to the ICMPv6 protocol for processing.

   [ Copy some text from -ilnp-intro's Security Considerations to here ]

   For sessions operating in higher risk environments, the use
   of the IP Authentication Header *in addition* to the experimental
   Nonce Destination Option is recommended.

7. IANA Considerations

   (To be written later)

8.  References

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

8.2.  Informative References

   [ILNP-Intro] Atkinson, R, "ILNP Concept of Operations",
                draft-rja-ilnp-intro-01.txt, June 2008.

   [ILNP-DNS]   Atkinson, R, "Additional DNS Resource Records",
                draft-rja-ilnp-dns-00.txt, June 2008.

   [ILNP-Nonce] Atkinson, R, "Nonce Destination Option",
                draft-rja-ilnp-nonce-00.txt, June 2008.

   (Additional references to be added later.)

Author's Address

Atkinson             Expires in 6 months                        [Page 5]

Internet Draft       ILNP ICMP            10 DEC 2008

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

   +1 (408)579-2800

Atkinson             Expires in 6 months                        [Page 6]

Internet Draft       ILNP ICMP            10 DEC 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 on an "AS IS" basis and THE CONTRIBUTOR, THE

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

   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 in 6 months                        [Page 7]

Internet Draft       ILNP ICMP            10 DEC 2008

   Expires: 10 June 2009

Atkinson             Expires in 6 months                        [Page 8]