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

Versions: 00 01 02                                                      
IPv6 Working Group                                          Greg Daley
INTERNET-DRAFT                                    Nick "Sharkey" Moore
Expires: December 2004                          Monash University CTIE
                                                         Erik Nordmark
                                                      Sun Microsystems
                                                           9 June 2004

              Tentative Source Link-Layer Address Options
                      for IPv6 Neighbour Discovery


Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668 (BCP 79).

   By submitting this Internet-Draft, I accept the provisions of Section
   3 of RFC 3667 (BCP 78).

   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 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 an individual submission to the IETF. Comments
   should be directed to the authors.

   Definitions of requirements keywords are in accordance with the IETF
   Best Current Practice - RFC2119 [KEYW-RFC]

Daley et al.         draft-daley-ipv6-tsllao-00.txt             [Page 1]

INTERNET-DRAFT Tentative Source Link-Layer Address Options     June 2004


   The proposed IPv6 Duplicate Address Detection (DAD) Optimization
   "Optimistic DAD" defines a set of recoverable procedures which allow
   a node to make use of an address before DAD completes.  Essentially,
   Optimistic DAD forbids usage of certain Neighbour Discovery options
   which could pollute active neighbour cache entries, while an address
   is tentative.

   This document defines a new option and procedures to replace cache
   polluting options, in a way which is useful to tentative nodes.
   These procedures are designed to be to backward compatible with
   existing devices which support IPv6 Neighbour Discovery.

1.0 Introduction

   Source Link-Layer Address Options (SLLAOs) are sent in Neighbour
   discovery messages in order to notify neighbours of a mapping between
   a specific IPv6 Network layer address and a link-layer (or MAC)
   address.  Upon reception of a neighbour discovery message containing
   such an option, nodes update their neighbour cache entries with the
   IP to link-layer address mapping in accordance with procedures
   defined in IPv6 Neighbour Discovery [RFC-2461].

   Optimistic DAD [OPTIDAD] prevents usage of these options in Router
   and Neighbour Solicitation messages from a tentative address (while
   Duplicate Address Detection is occurring).  This is because receiving
   a Neighbour Solicitation (NS) or Router Solicitation (RS) containing
   an SLLAO would otherwise overwrite an existing cache entry, even if
   the cache entry contained the legitimate address owner, and the
   solicitor was a duplicate address.

   Neighbour Advertisement (NA) messages don't have such an issue, since
   the Advertisement message contains a flag which explicitly disallows
   overriding of existing cache entries, by the target link-layer
   address option carried within.

   The effect of preventing SLLAOs for tentative addresses is that
   communications with these addresses are sub-optimal for the tentative
   period.  Sending solicitations without these options causes an
   additional round-trip for neighbour discovery if the advertiser does
   not have an existing neighbour cache entry for the solicitor.

   Tentative Source Link-Layer Address Options are designed to replace
   the existing Source Link-Layer Address Options available in IPv6
   Neighbour Discovery, when a device is performing Optimistic DAD, or a
   device is sending Router Solicitations from an unspecified source

Daley et al.         draft-daley-ipv6-tsllao-00.txt             [Page 2]

INTERNET-DRAFT Tentative Source Link-Layer Address Options     June 2004

1.1 Tentative Source Link-Layer Address Option Format

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 5 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     |     Type      |    Length     |    Link-Layer Address ...

      Type   TBD    <Requires IANA Allocation>

      Length         The length of the option (including the type and
                     length fields) in units of 8 octets [RFC-2461].

      Link-Layer Address
                     The variable length link-layer address.

                     The Tentative Source Link-Layer Address option
                     contains the link-layer address of the sender of
                     the packet.  It is used in the Neighbour
                     Solicitation and Router Solicitation packets.

1.2 Tentative Source Link-Layer Address Option Semantics

   The Tentative Source Link-Layer Address option (TSLLAO) functions in
   the same role as the Source Link-Layer Address option defined for
   [RFC-2461], but it MUST NOT override an existing neighbour cache

   The differing neighbour cache entry MUST NOT be affected by the
   reception of the Tentative Source Link-Layer Address option.  This
   ensures that tentative addresses are unable to modify legitimate
   neighbour cache entries.

   In the case where an entry is unable to be added to the neighbour
   cache, a node MAY send responses direct to the link-layer address
   specified in the TSLLAO.

   For these messages, no Neighbour Cache entry may be created, although
   response messages may be directed to a particular unicast address.

   These procedures are discussed further in section 3.3.

Daley et al.         draft-daley-ipv6-tsllao-00.txt             [Page 3]

INTERNET-DRAFT Tentative Source Link-Layer Address Options     June 2004

2.0 Sending Solicitations containing TSLLAO

   Solicitations sent containing Tentative Source Link-Layer Address
   Options need to conform to IPv6 Neighbour Discovery procedures, since
   they are send without SLLAOs, and legacy nodes will ignore the new

   In a case where it is safe to send a Source Link-Layer Address
   Option, a host SHOULD NOT send a TSLLAO, since the message may be
   mis-interpreted by legacy nodes.

   Importantly, a node MUST NOT send a TSLLAO in the same message where
   a Source Link-Layer Address Option is sent.

   A node MUST NOT send TSLLAO options except where [RFC-2461] allows
   ommision of an SLLAO i.e. in the following cases:

2.1 Sending Neighbour Solicitations with TSLLAO

   Except for packets sent from an unspecified source address, Source
   Link-Layer Address options are mandatory in Neighbour Solicitation
   messages destined to multicast addresses.

   Neighbour Solicitations for the unspecified source address are
   typically used for Duplicate Address Detection.  Any receiver of an
   unspecified source addressed Neighbour Solicitation with TSLLAO will
   believe the packet to be a DAD attempt if it is unable to interpret
   the TSLLAO option.

   Since many nodes will halt address configuration if they receive a
   DAD NS while an address is tentative, Tentative Source Link-Layer
   Address options MUST NOT be sent in Neighbour Solicitation messages
   from the unspecified source address.

   On the other hand, Neighbour Solicitation packets with unicast source
   and destination addresses are not explicitly required to include
   SLLAOs.  Such packets may instead use a Tentative Source Link-Layer
   Address Option, which is safe when undergoing Duplicate Address

   Since delivery of a packet to a unicast destination requires prior
   knowledge of the destination's hardware address, unicast Neighbour
   Solicitation packets may only be sent to destinations for which a
   neighbour cache entry already exists.

   For example, if checking bidirectional reachability to a router, it
   may be possible to send a Neighbour Solicitation with TSLLAO to the
   router's advertised address.

Daley et al.         draft-daley-ipv6-tsllao-00.txt             [Page 4]

INTERNET-DRAFT Tentative Source Link-Layer Address Options     June 2004

   As discussed in [RFC-2461], the peer device may not have a cache
   entry even if the soliciting host does, in which case reception of
   TSLLAO may create a neighbour cache entry, without the need for
   neighbour discovering the original solicitor.  If the device is a
   legacy [RFC-2461] device, which doesn't recognize TSLLAO options, it
   will perform a Neighbour Solicitation back to the tentative node.

   Hosts MUST NOT send Neighbour Solicitations with specified source
   addresses and TSLLAO to nodes for which there is no pre-existing
   neighbour cache entry, or state is INCOMPLETE, unless these nodes are
   known to support TSLLAOs.

   This is because such Neighbour Solicitations violate IPv6 Neighbour
   Discovery specifications since they contain no SLLAO, and may cause
   confusion or harm to nodes which receive them.

2.2 Sending Router Solicitations with TSLLAO

   Router Solicitations are always able to be sent without Source Link-
   Layer Address options.

   Some routers may choose to send a multicast response to devices which
   send Router Solicitations without SLLAOs when they do not have an
   existing neighbour cache entry.  If a router does not understand
   Tentative Source Link-Layer Address Options, it MAY send a multicast
   solicitation in preference to sending Neighbour Solicitation packets
   to learn unicast address's link-layer address.

   Any router solicitation, including those from the unspecified
   address, MAY be sent with a TSLLAO.

   Responses from routers depend on existing neighbour cache state, and
   their ability to send packets to identified MAC addresses without
   using the neighbour cache.

   Such issues are discussed in sections 3.4 and 3.5.

3.0 Receiving Tentative Source Link-Layer Address Options

   In the case that a node receives a solicitation without a Link-Layer
   identifier it will determine if a responding Advertisement will be
   sent to a unicast or multicast address.

   If the advertisement is to be sent to the solicitor's unicast
   address, the node will consult its existing neighbour cache for the
   solicitor's information, and if not present, will undertake neighbour

Daley et al.         draft-daley-ipv6-tsllao-00.txt             [Page 5]

INTERNET-DRAFT Tentative Source Link-Layer Address Options     June 2004

   Receiving a Tentative Source Link-Layer Address Option, avoids this
   neighbour discovery step, by allowing the host to create or update a
   matching entry, setting it to STALE state if it didn't previously

   Additionally, TSLLAO messages may be used to direct advertisements to
   particular link-layer destinations without updating neighbour cache
   entries.  This is described in section 3.4.

3.1 Handling messages with Tentative Source Link-Layer Address Options

   Use of Tentative Source Link-Layer Address Options is only defined
   for Neighbour and Router Solicitation messages.

   In any other received message, a Tentative Source Link-Layer Address
   Option MUST be treated as if it is an unknown option, and processed

   It is REQUIRED that the same validation algorithms for Neighbour and
   Router Solicitations received with TSLLAO as in the IPv6 Neighbour
   Discovery specification [RFC-2461], are used.  In the case that a
   solicitation containing a TSLLAO is received, this does not mean that
   the solicitor needs to be treated differently, except in the updating
   of the cache entry and processing of the option.  Particularly, there
   is no reason to believe that the host will remain tentative after
   receiving a responding advertisement.

   As defined in Section 1.2,  Tentative Source Link-Layer Address
   Options do not overwrite existing neighbour cache entries where the
   link-layer addresses differ.

   If a solicitation from a unicast source address is received where no
   conflict occurs between the TSLLAO and an existing neighbour cache
   entry, the option MUST be treated as if it were an SLLAO after
   message validation, and processed accordingly.

   In the case that a cache entry is unable to be created or updated,
   the receiving node MAY send a direct advertisement to the soliciting
   host by responding with an appropriate advertisement, where the link-
   layer address contained in the TSLLAO is copied into the destination
   address of the link-layer frame.

   This is described further in sections 3.4 and 3.5.

3.2 Receiving Neighbour Solicitations containing TSLLAO

   The TSLLAO option is only allowed in Neighbour Solicitations with
   specified source addresses for which SLLAO is not required.  A

Daley et al.         draft-daley-ipv6-tsllao-00.txt             [Page 6]

INTERNET-DRAFT Tentative Source Link-Layer Address Options     June 2004

   Neighbour Solicitation message received with TSLLAO and an
   unspecified source address MUST be silently discarded.

   Upon reception of a Tentative Source Link-Layer Address Option in a
   Neighbour Solicitation for which the receiver has the Target Address
   configured, a node checks to see if there is a neighbour cache entry
   with conflicting link-layer address.

   If no such entry exists, the neighbour cache of the receiver SHOULD
   be updated, as if the Tentative Source Link-Layer Address Option was
   a SLLAO.

   Sending of the solicited Neighbour Advertisement then proceeds
   normally, as defined in section 7.2.4 of [RFC-2461].

   If there is a conflicting neighbour cache entry, a node processes the
   solicitation in a fashion defined in in sections 3.4 and 3.5.

3.3 Receiving a Router Solicitation containing TSLLAO

   In IPv6 Neighbour Discovery  [RFC-2461],  responses to router
   solicitations are either sent to the all-nodes multicast address, or
   may be sent to the solicitation's source address if it is a unicast

   Including a TSLLAO in the solicitation allows a router to choose to
   send a packet directly to the link-layer address even in situations
   where this would not normally be possible.

   For Router Solicitations with unicast source addresses, neighbour
   caches SHOULD be updated with the link-layer address from a TSLLAO if
   there is no conflicting neighbour cache entry.  In this case, Router
   Advertisement continues as in section 6.2.6 of [RFC-2461].

   For received solicitations with a conflicting neighbour cache entry
   or those containing a TSLLAO with an unspecified source address,
   responses can be generated in accordance with sections 3.4 and 3.5

3.4 Sending Directed Advertisements without the Neighbour Cache.

   In the case where a received solicitation has a link-layer address
   specified in a TSLLAO which conflicts with an existing with a
   neighbour cache entry, modification of the neighbour cache MUST NOT

   Router Solicitations with the unspecified source address MUST NOT
   create neighbour cache entires.

Daley et al.         draft-daley-ipv6-tsllao-00.txt             [Page 7]

INTERNET-DRAFT Tentative Source Link-Layer Address Options     June 2004

   In both situations, it may be valuable to send a direct message to
   the soliciting nodes.

   In these cases a node MAY generate a responding advertisement
   according to the rules in [RFC-2461].

   The responding packets MAY then have the unicast link-layer address
   from the TSLLAO inserted into the destination address of the link-
   layer frame used to transport this advertisement, without consulting
   the neighbour or destination caches for this entry.

   Such packets SHOULD scheduled as if they were unicast advertisements
   as specified in [RFC-2461].

3.5 Alternatives to Sending Directed Advertisements.

   Some implementations will be unable to generate directed
   advertisements by copying the tentative source link-layer address
   into a packet.

   Also, some nodes will be unable to send unicast packets without
   consulting their neighbour caches.  Alternative mechanisms for such
   nodes SHOULD perform at least as well as implementations where TSLLAO
   is not understood.

   For such implementations as these, it is not possible to send a
   response for Neighbour Solicitation messages without modifying the
   neighbour cache.

   Such nodes MAY send a responding NA message as if it did not
   understand the TSLLAO message.

   This will deliver the NA to the soliciting host if it has both the
   tentative link-layer address and the entry in the neighbour cache
   configured on the same link.  Otherwise, the message will be sent to
   the originator of the neighbour cache entry, and the solicitor will
   receive no response.

   For Router Solicitations where no neighbour cache entry is able to be
   created, a multicast response SHOULD be sent in accordance with
   [RFC-2461].  This includes those solicitations sent from unicast
   sources, for which a conflicting neighbour cache entry was found.

4.0 IANA Considerations

   For standardization, it would be required that the IANA provide
   allocation of the Tentative Source Link-Layer Address Option (Section
   1.1) from the IPv6 Neighbour Discovery options for IPv6.

Daley et al.         draft-daley-ipv6-tsllao-00.txt             [Page 8]

INTERNET-DRAFT Tentative Source Link-Layer Address Options     June 2004

   Potential details of the allocation process for these options is
   detailed in the expired draft [IPv6-ALLOC].

5.0 Security Considerations

   The use of the TSLLAO in Neighbour and Router Solicitation messages
   acts in a similar manner to SLLAO, updating neighbour cache entries,
   in a way which causes packet transmission.

   Particular care should be taken that transmission of messages
   complies with existing IPv6 Neighbour Discovery Procedures, so that
   unmodified hosts do not receive invalid messages.

   An attacker may cause messages may be sent to another node by an
   advertising node (a reflector), without creating any ongoing state on
   the reflector.

   This is attack requires one solicitation for each advertisement and
   the advertisement has to go to a unicast MAC destination.  That said,
   the size of the advertisement may be significantly larger than the
   solicitation, or the attacker and reflector may be on a medium with
   greater available bandwidth than the victim.

   For link-layers where it isn't possible to spoof the link-layer
   source address this allows a slightly increased risk of reflection
   attacks from nodes which are on-link.

   Additionally, since a SEND host must always advertise using SEND
   options and signatures, a non-SEND attacker may cause excess
   computation on both a victim node and a router by causing SEND
   advertisement messages to be transmitted to a particular MAC address
   and the all-nodes multicast.  [SEND] specifies guidelines to hosts
   receiving unsolicited advertisements in order to mitigate such

   While this is the same effect as experienced when accepting SLLAO
   from non-SEND nodes, the lack of created neighbour cache entries on
   the advertiser may make such attacks more difficult to trace.

   Modification of Neighbour Discovery messages on the network is
   possible, unless SEND is used.  [SEND] provides a protocol
   specification in which soliciting nodes sign ND messages with a
   private key and use addresses generated from this key.

   Even if SEND is used, the lifetime of a neighbour cache entry may be
   extended by continually replaying a solicitation message to a
   particular router or hosts.   Since this may be achieved for any
   Neighbour or Router Solicitation message, corresponding

Daley et al.         draft-daley-ipv6-tsllao-00.txt             [Page 9]

INTERNET-DRAFT Tentative Source Link-Layer Address Options     June 2004

   advertisements to the original transmitters of these solicitation
   messages may occur.

   SEND defines use of Timestamp values to protect a device from attack
   through replay of previously sent messages.  Although this applies to
   Neighbour and Router Solicitation messages, granularity of the
   timestamp allows the messages to be used for up to two hours in
   extreme cases [SEND].

   All Router and Neighbour Solicitations using SEND contain a Nonce
   option, containing a random identifier octet string.  Since SEND
   messages are digitally signed, and may not be easily modified, replay
   attacks will contain the same Nonce option, as was used in the
   original solicitation.

   While the Nonce Option included in a transmission to another node may
   not vary within one short solicitation period (the host may itself
   replay solicitations in the case of packet loss), the presence of the
   timestamp option ensures that for later solicitations, a different
   Timestamp and Nonce will be used.

   Therefore, a receiver seeing a solicitation with the same Timestamp
   and Nonce (and signature) for more than either of
   MAX_RTR_SOLICITATIONS (for router solicitations), MAX_UNICAST_SOLICIT
   or MAX_MULTICAST_SOLICIT (for Neighbour Solicitations), SHOULD ignore
   further solicitations with this (Nonce,Timestamp,Source) triple,
   ensuring that no modification is made to neighbour cache entries.
   This applies to any solicitation packet capable of carrying a SEND
   payload, whether they use TSLLAO or SLLAO.

   Stations noticing such an attack SHOULD notify their administrator of
   the attempt at Denial-of-service.

Normative References

   [KEYW-RFC] S. Bradner.  Key words for use in RFCs to Indicate
        Requirement Levels. Request for Comments (Best Current Practice)
        2119 (BCP 14), Internet Engineering Task Force, March 1997

   [OPTIDAD] N. Moore. Optimistic Duplicate Address Detection.  Internet
        Draft (work in progress), March 2004.

   [RFC-2461]  T. Narten, E.Nordmark, W. Simpson. Neighbour Discovery
        for IP Version 6 (IPv6). Request for Comments (Draft Standard)
        2461, Internet Engineering Task Force, December 1998.

   [SEND]  J. Arkko (Editor) et al. SEcure Neighbour Discovery (SEND).
        Internet Draft (work in progress), April 2004.

Daley et al.         draft-daley-ipv6-tsllao-00.txt            [Page 10]

INTERNET-DRAFT Tentative Source Link-Layer Address Options     June 2004

Non-Normative References

   [IPv6-ALLOC] T. Narten. "IANA Allocation Guidelines for Values in
        IPv6 and Related Headers", Internet Draft (work in progress),
        October 2002.  www.watersprings.org/pub/id/draft-narten-


   Erik Nordmark coined a proposal for TSLLAO during a conversation with
   JinHyeock Choi and Greg Daley.

Authors' Addresses

   Greg Daley


   Nick "Sharkey" Moore


   Centre for Telecommunications and Information Engineering
   Department of Electrical and Computer Systems Engineering
   Monash University
   Clayton 3800

   Erik Nordmark


   Sun Microsystems, Inc.
   17 Network Circle
   Mountain View, CA

   phone: +1 650 786 2921
   fax:   +1 650 786 5896

Intellectual Property Rights

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

Daley et al.         draft-daley-ipv6-tsllao-00.txt            [Page 11]

INTERNET-DRAFT Tentative Source Link-Layer Address Options     June 2004

Copyright Statement

   Copyright (C) The Internet Society (2004).  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

   This document and the information contained herein are provided

   This document expires in December 2004.

Daley et al.         draft-daley-ipv6-tsllao-00.txt            [Page 12]