[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 RFC 6743

Internet Draft                                               RJ Atkinson
draft-irtf-rrg-ilnp-icmpv6-00.txt                             Consultant
Category: Experimental                                          S Bhatti
Expires: 09 JUL 2012                                       U. St Andrews
                                                         January 9, 2012
                 ICMP Locator Update message for ILNPv6

Status of this Memo

   Distribution of this memo is unlimited.

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document. Code Components extracted from this
   document must include Simplified BSD License text as described in
   Section 4.e of the Trust Legal Provisions and are provided
   without warranty as described in the Simplified BSD License.

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before
   November 10, 2008.  The person(s) controlling the copyright in
   some of this material may not have granted the IETF Trust the
   right to allow modifications of such material outside the IETF
   Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be modified outside the IETF Standards Process,
   and derivative works of it may not be created outside the IETF
   Standards Process, except to format it for publication as an RFC
   or to translate it into languages other than English.  This
   document may not be modified, and derivative works of it may not
   be created, except to publish it 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.

Atkinson & Bhatti    Expires in 6 months                        [Page 1]

Internet Draft       ILNP ICMP            09 JUL 2012

   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

   The list of current Internet-Drafts can be accessed at

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

   This document is not on the IETF standards-track and does not
   specify any level of standard.  This document merely provides
   information for the Internet community.

   This document is part of the ILNP document set, which has had
   extensive review within the IRTF Routing Research Group.  ILNP
   is one of the recommendations made by the RG Chairs.  Separately,
   various refereed research papers on ILNP have also been published
   during this decade.  So the ideas contained herein have had much
   broader review than the IRTF Routing RG.  The views in this
   document were considered controversial by the Routing RG,
   but the RG reached a consensus that the document still should be
   published.  The Routing RG has had remarkably little consensus
   on anything, so virtually all Routing RG outputs are considered


   This note specifies an experimental ICMPv6 message type used
   with the Identifier-Locator Network Protocol (ILNP).  This
   message is used to dynamically update Identifier/Locator
   bindings for an existing ILNP session.  This is a product
   of the  IRTF Routing RG.

Table of Contents

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

Atkinson & Bhatti    Expires in 6 months                        [Page 2]

Internet Draft       ILNP ICMP            09 JUL 2012

1. Introduction

   At present, the research and development community are examining
   various alternatives for 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 evolutionary approaches.

   The Identifier Locator Network Protocol evolves the current Internet
   Architecture by deprecating the concept of the IP Address, and
   substituting separate Locator and Identifier objects, each with crisp
   syntax and semantics [ILNP-ARCH].

   ILNP has multiple instantiations.  [ILNP-ENG] discusses ILNP
   engineering and implementation aspects common to all instantiations
   of ILNP.  This document focuses on ILNP for IPv6 (ILNPv6).  [ILNP-
   DNS] covers new Domain Name System (DNS) resource records used with
   ILNP.  [ILNP-Nonce] describes a Nonce Destination Option used with

   The new ICMPv6 Locator Update message described in this document
   enables an ILNP-capable node to update its correspondents about the
   currently valid set of Locators valid to use in reaching the node
   sending this message.[RFC 2460] [RFC 4443]

   This new ICMPv6 message MUST ONLY be used for ILNPv6 sessions.
   Authentication is always required, as described in the Security
   Considerations section later in this note.

   Some might consider any and all use of ICMP to be undesirable.  In
   that context, please note that while this specification uses ICMP, on
   grounds that this is a control message, there is no architectural
   difference between using ICMP and using some different framing, for
   example UDP.

1.1 Terminology

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

2. Syntax

   Example ICMP message body for case where only 1 Locator value is
   being indicated:

Atkinson & Bhatti    Expires in 6 months                        [Page 3]

Internet Draft       ILNP ICMP            09 JUL 2012

   |  ICMP Type  |  ICMP Code    |        Checksum            |
   | Num of Locs |     RESERVED  |        Preference          |
   /                        Locator                           /

   Example ICMP message body for case where 2 Locator
   values are being indicated:

   |  ICMP Type  |  ICMP Code    |        Checksum            |
   | Num of Locs |     RESERVED  |        Preference          |
   /                        Locator                           /
   |        RESERVED             |        Preference          |
   /                        Locator                           /

   For cases where more than 2 Locator values are being indicated,
   the "RESERVED", "Preference", and "Locator" fields are appended
   as appropriate to carry the intended number of Locator fields.

   ICMP Type:         This 8-bit field is set to the value XXX
                      to indicate that this is a Locator Update

   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.

Atkinson & Bhatti    Expires in 6 months                        [Page 4]

Internet Draft       ILNP ICMP            09 JUL 2012

   Reserved:          These fields MUST be sent as zero.
                      At this time, recipients should ignore the
                      contents of these field, as these bits are
                      reserved for future use.  (Implementers
                should understand that these fields might
                be used in the future.)

   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.

   Preference:        A 16-bit unsigned integer which specifies
                the preference given to this Locator among
                other Locators in the same ICMP message.
                Lower Preference values are preferred
                over higher Preference values.

   NOTE: In order to prevent session stealing by an off-path
   adversary, all ICMP Locator Update packets MUST also contain an
   ILNP Nonce Destination Option with valid authentication
   information for the session associated with the ICMP Locator
   Update packet.  The ILNP Nonce Destination Option is required in
   all cases, even if some other authentication mechanism, such as
   Security for ILNP [ILNP-ENG] [RFC 4301], is also in use.

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 an ILNP design objective 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 ILNPv6, and to retain the incremental deployability
   and backwards compatibility needed, the network layer needs a
   mode bit in the Transport Control Block (or its equivalent) to

Atkinson & Bhatti    Expires in 6 months                        [Page 5]

Internet Draft       ILNP ICMP            09 JUL 2012

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

   Further, when supporting ILNPv6, nodes will need to retain a
   Correspondent Cache in the network layer as described in

   A node sending an ICMP Locator Update message MUST include all
   currently valid Locator values in that message.  A node receiving
   a valid ICMP Locator Update message MUST replace the previously
   current set of Locator values for that correspondent node in the
   ILNP Correspondent Cache with the newly received set of Locator

   Every implementation needs to support a large number of Locator
   values being sent or received in a single ICMP Locator Update
   message, because a multi-homed node or multi-homed site might
   have a large number of upstream links to different service
   providers, each with its own Locator value.

5.  Backwards Compatibility

   For all sessions operating in Identifier/Locator Split mode,
   inside each node the high-order 64-bits ("Locator") MUST be set
   to zero before calculating TCP or UDP checksums.  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.

   When ILNPv6 is not in use, the receiving IPv6 mode MUST discard
   the ICMP Locator Update packet without processing the packet.

6. Security Considerations

   A broader discussion of ILNP Security Considerations is
   found in [ILNP-ARCH], and is incorporated here by reference.

   The ICMP Locator Update message MUST ONLY be used for ILNPv6

   The ILNP 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. If either of

Atkinson & Bhatti    Expires in 6 months                        [Page 6]

Internet Draft       ILNP ICMP            09 JUL 2012

   these requirements are not met, the received packet MUST be
   discarded as not authentic, and a security event SHOULD be logged
   by the system receiving the non-authentic packet.

   Sessions operating in higher risk environments SHOULD use IP
   Security for ILNP [ILNP-ENG] [RFC 4301] *in addition* to the
   ILNPv6 Nonce Destination Option.  Use of IP Security for ILNP to
   protect a packet does NOT permit the packet to be sent without
   the Nonce Destination Option.

   Implementations need to support the case where a single ICMP
   Locator Update message contains a large number of Locator and
   Preference values and ought not develop a security fault
   (e.g. stack overflow) due to a received message containing more
   Locator values than expected.

7. IANA Considerations

   IANA is requested to assign a value, replacing the XXX, to the
   ICMP Type listed in Section 2, following the procedures in [RFC

   There are no other IANA actions for this document.

8.  References

8.1.  Normative References

   [ILNP-ARCH]  R. Atkinson and S. Bhatti, "ILNP Architecture",
                draft-irtf-rrg-ilnp-arch, January 2012.

   [ILNP-DNS]   R. Atkinson and S. Bhatti, "DNS Resource Records
                for ILNP", draft-irtf-rrg-ilnp-dns, January 2012.

   [ILNP-ENG]   R. Atkinson and S. Bhatti, "ILNP Engineering
                Considerations", draft-irtf-rrg-ilnp-eng, January 2012.

   [ILNP-Nonce] R. Atkinson and S. Bhatti, "Nonce Destination Option",
                draft-irtf-rrg-ilnp-noncev6, January 2012.

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

Atkinson & Bhatti    Expires in 6 months                        [Page 7]

Internet Draft       ILNP ICMP            09 JUL 2012

   [RFC 4301]   S. Kent & K. Seo, "Security Architecture for
                the Internet Protocol", RFC 4301, December 2005.

   [RFC 4443]   A. Conta, S. Deering, and M. Gupta (Ed.),
                "Internet Control Message Protocol (ICMPv6)
                for the Internet Protocol Version 6 (IPv6)
                Specification", RFC 4443, March 2006.

8.2.  Informative References

   ### tbd


   Steve Blake, Mohamed Boucadair, Steve Hailes, Joel Halpern, Mark
   Handley, Volker Hilt, Tony Li, and Yakov Rehkter (in alphabetical
   order) provided review and feedback on earlier versions of the
   ILNP documents.  Steve Blake provided an especially thorough
   review of the ILNP document set.

Author's Address

   RJ Atkinson
   San Jose, CA
   95125 USA

   Email: rja.lists@gmail.com

   S Bhatti
   School of Computer Science
   University of St Andrews
   North Haugh, St Andrews,
   Fife, Scotland, UK
   KY 16 9SX

   Email: saleem@cs.st-andrews.ac.uk

   Expires: 09 JUL 2012

Atkinson & Bhatti    Expires in 6 months                        [Page 8]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/