draft-daley-ipv6-tsllao-00.txt		draft-daley-ipv6-tsllao-02.txt
IPv6 Working Group Greg Daley		Network Working Group G. Daley
INTERNET-DRAFT Nick "Sharkey" Moore		Internet-Draft Monash University CTIE
Expires: December 2004 Monash University CTIE		Expires: January 19, 2006 E. Nordmark
Erik Nordmark
Sun Microsystems		Sun Microsystems
9 June 2004		N. Moore
		Monash University CTIE
Tentative Source Link-Layer Address Options		July 18, 2005
for IPv6 Neighbour Discovery
<draft-daley-ipv6-tsllao-00.txt>		Tentative Source Link-Layer Address Options for IPv6 Neighbour Discovery
		draft-daley-ipv6-tsllao-02.txt
Status of this Memo		Status of this Memo
By submitting this Internet-Draft, I certify that any applicable		By submitting this Internet-Draft, each author represents that any
patent or other IPR claims of which I am aware have been disclosed		applicable patent or other IPR claims of which he or she is aware
and any of which I become aware will be disclosed, in accordance with		have been or will be disclosed, and any of which he or she becomes
RFC 3668 (BCP 79).		aware will be disclosed, in accordance with Section 6 of 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		Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other		Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts.		other groups may also distribute working documents as Internet-
		Drafts.
Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
material or cite them other than as "work in progress".		material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html		http://www.ietf.org/shadow.html.
This document is an individual submission to the IETF. Comments		This Internet-Draft will expire on January 19, 2006.
should be directed to the authors.
Definitions of requirements keywords are in accordance with the IETF		Copyright Notice
Best Current Practice - RFC2119 [KEYW-RFC]
		Copyright (C) The Internet Society (2005).
Abstract		Abstract
The proposed IPv6 Duplicate Address Detection (DAD) Optimization		The proposed IPv6 Duplicate Address Detection (DAD) Optimization
"Optimistic DAD" defines a set of recoverable procedures which allow		"Optimistic DAD" defines a set of recoverable procedures which allow
a node to make use of an address before DAD completes. Essentially,		a node to make use of an address before DAD completes. Essentially,
Optimistic DAD forbids usage of certain Neighbour Discovery options		Optimistic DAD forbids usage of certain Neighbour Discovery options
which could pollute active neighbour cache entries, while an address		which could pollute active neighbour cache entries, while an address
is tentative.		is tentative.
This document defines a new option and procedures to replace cache		This document defines a new option and procedures to replace cache
polluting options, in a way which is useful to tentative nodes.		polluting options, in a way which is useful to tentative nodes.
These procedures are designed to be to backward compatible with		These procedures are designed to be to backward compatible with
existing devices which support IPv6 Neighbour Discovery.		existing devices which support IPv6 Neighbour Discovery.
1.0 Introduction		Table of Contents
		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
		1.1 Tentative Source Link-Layer Address Option Format . . . . 3
		1.2 Tentative Source Link-Layer Address Option Semantics . . . 4
		2. Sending Solicitations containing TSLLAO . . . . . . . . . . . 4
		2.1 Sending Neighbour Solicitations with TSLLAO . . . . . . . 5
		2.2 Sending Router Solicitations with TSLLAO . . . . . . . . . 5
		3. Receiving Tentative Source Link-Layer Address Options . . . . 5
		3.1 Handling Tentative Source Link-Layer Address Options . . . 6
		3.2 Receiving Neighbour Solicitations containing TSLLAO . . . 6
		3.3 Receiving a Router Solicitation containing TSLLAO . . . . 7
		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
		5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
		6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
		7.1 Normative References . . . . . . . . . . . . . . . . . . . 9
		7.2 Informative References . . . . . . . . . . . . . . . . . . 10
		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10
		A. Constraints imposed by IPv6 Neighbour Discovery . . . . . . . 10
		A.1 Constraints on Neighbour Solicitations . . . . . . . . . . 11
		A.2 Constraints on Router Solicitations . . . . . . . . . . . 11
		B. Interactions with legacy nodes . . . . . . . . . . . . . . . . 11
		B.1 Legacy Neighbour Solicitation processing . . . . . . . . . 11
		B.2 Legacy Router Solicitation Processing . . . . . . . . . . 12
		C. Sending Directed Advertisements without the Neighbour Cache . 13
		Intellectual Property and Copyright Statements . . . . . . . . 14
		1. Introduction
Source Link-Layer Address Options (SLLAOs) are sent in Neighbour		Source Link-Layer Address Options (SLLAOs) are sent in Neighbour
discovery messages in order to notify neighbours of a mapping between		discovery messages in order to notify neighbours of a mapping between
a specific IPv6 Network layer address and a link-layer (or MAC)		a specific IPv6 Network layer address and a link-layer (or MAC)
address. Upon reception of a neighbour discovery message containing		address. Upon reception of a neighbour discovery message containing
such an option, nodes update their neighbour cache entries with the		such an option, nodes update their neighbour cache entries with the
IP to link-layer address mapping in accordance with procedures		IP to link-layer address mapping in accordance with procedures
defined in IPv6 Neighbour Discovery [RFC-2461].		defined in IPv6 Neighbour Discovery [2].
Optimistic DAD [OPTIDAD] prevents usage of these options in Router		Optimistic DAD [4] prevents usage of these options in Router and
and Neighbour Solicitation messages from a tentative address (while		Neighbour Solicitation messages from a tentative address (while
Duplicate Address Detection is occurring). This is because receiving		Duplicate Address Detection is occurring). This is because receiving
a Neighbour Solicitation (NS) or Router Solicitation (RS) containing		a Neighbour Solicitation (NS) or Router Solicitation (RS) containing
an SLLAO would otherwise overwrite an existing cache entry, even if		an SLLAO would otherwise overwrite an existing cache entry, even if
the cache entry contained the legitimate address owner, and the		the cache entry contained the legitimate address owner, and the
solicitor was a duplicate address.		solicitor was a duplicate address.
Neighbour Advertisement (NA) messages don't have such an issue, since		Neighbour Advertisement (NA) messages don't have such an issue, since
the Advertisement message contains a flag which explicitly disallows		the Advertisement message contains a flag which explicitly disallows
overriding of existing cache entries, by the target link-layer		overriding of existing cache entries, by the target link-layer
address option carried within.		address option carried within.
The effect of preventing SLLAOs for tentative addresses is that		The effect of preventing SLLAOs for tentative addresses is that
communications with these addresses are sub-optimal for the tentative		communications with these addresses are sub-optimal for the tentative
period. Sending solicitations without these options causes an		period. Sending solicitations without these options causes an
additional round-trip for neighbour discovery if the advertiser does		additional round-trip for neighbour discovery if the advertiser does
not have an existing neighbour cache entry for the solicitor.		not have an existing neighbour cache entry for the solicitor. In
		some cases, multicast advertisements will be scheduled, where
		neighbour discovery is not possible on the advertiser.
Tentative Source Link-Layer Address Options are designed to replace		Tentative Source Link-Layer Address Options are designed to replace
the existing Source Link-Layer Address Options available in IPv6		the existing Source Link-Layer Address Options available in IPv6
Neighbour Discovery, when a device is performing Optimistic DAD, or a		Neighbour Discovery, when a device is performing Optimistic DAD.
device is sending Router Solicitations from an unspecified source
address.
1.1 Tentative Source Link-Layer Address Option Format		1.1 Tentative Source Link-Layer Address Option Format
0 1 2 3		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		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 | Length | Link-Layer Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:		Fields:
Type TBD <Requires IANA Allocation>		Type TBD (Requires IANA Allocation) suggest 33 (0x21)
Length The length of the option (including the type and		Length The length of the option (including the type and
length fields) in units of 8 octets [RFC-2461].		length fields) in units of 8 octets.
Link-Layer Address		Link-Layer Address
The variable length link-layer address.		The variable length link-layer address.
Description		Description
The Tentative Source Link-Layer Address option		The Tentative Source Link-Layer Address option
contains the link-layer address of the sender of		contains the link-layer address of the sender of
the packet. It is used in the Neighbour		the packet. It is used in the Neighbour
Solicitation and Router Solicitation packets.		Solicitation and Router Solicitation packets.
1.2 Tentative Source Link-Layer Address Option Semantics		1.2 Tentative Source Link-Layer Address Option Semantics
The Tentative Source Link-Layer Address option (TSLLAO) functions in		The Tentative Source Link-Layer Address option (TSLLAO) functions in
the same role as the Source Link-Layer Address option defined for		the same role as the Source Link-Layer Address option defined for
[RFC-2461], but it MUST NOT override an existing neighbour cache		[2], but it MUST NOT override an existing neighbour cache entry.
entry.
The differing neighbour cache entry MUST NOT be affected by the		The differing neighbour cache entry MUST NOT be affected by the
reception of the Tentative Source Link-Layer Address option. This		reception of the Tentative Source Link-Layer Address option. This
ensures that tentative addresses are unable to modify legitimate		ensures that tentative addresses are unable to modify legitimate
neighbour cache entries.		neighbour cache entries.
In the case where an entry is unable to be added to the neighbour		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		cache, a node MAY send responses direct to the link-layer address
specified in the TSLLAO.		specified in the TSLLAO.
For these messages, no Neighbour Cache entry may be created, although		For these messages, no Neighbour Cache entry may be created, although
response messages may be directed to a particular unicast address.		response messages may be directed to a particular unicast address.
These procedures are discussed further in section 3.3.		These procedures are discussed further in Section 3.3.
2.0 Sending Solicitations containing TSLLAO		2. Sending Solicitations containing TSLLAO
Solicitations sent containing Tentative Source Link-Layer Address		Tentative Source Link-Layer Address Options may be sent in Router and
Options need to conform to IPv6 Neighbour Discovery procedures, since		Neighbour Solicitations, as described below.
they are send without SLLAOs, and legacy nodes will ignore the new
option.
In a case where it is safe to send a Source Link-Layer Address		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		Option, a host SHOULD NOT send a TSLLAO, since the message may be
mis-interpreted by legacy nodes.		misinterpreted by legacy nodes.
Importantly, a node MUST NOT send a TSLLAO in the same message where		Importantly, a node MUST NOT send a TSLLAO in the same message where
a Source Link-Layer Address Option is sent.		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		2.1 Sending Neighbour Solicitations with TSLLAO
Except for packets sent from an unspecified source address, Source		Neighbour Solicitations sent to unicast addresses MAY contain a
Link-Layer Address options are mandatory in Neighbour Solicitation		TSLLAO.
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
Detection[OPTIDAD].
Since delivery of a packet to a unicast destination requires prior		Since delivery of a packet to a unicast destination requires prior
knowledge of the destination's hardware address, unicast Neighbour		knowledge of the destination's hardware address, unicast Neighbour
Solicitation packets may only be sent to destinations for which a		Solicitation packets may only be sent to destinations for which a
neighbour cache entry already exists.		neighbour cache entry already exists.
For example, if checking bidirectional reachability to a router, it		For example, if checking bidirectional reachability to a router, it
may be possible to send a Neighbour Solicitation with TSLLAO to the		may be possible to send a Neighbour Solicitation with TSLLAO to the
router's advertised address.		router's advertised address.
As discussed in [RFC-2461], the peer device may not have a cache		As discussed in [2], the peer device may not have a cache entry even
entry even if the soliciting host does, in which case reception of		if the soliciting host does, in which case reception of TSLLAO may
TSLLAO may create a neighbour cache entry, without the need for		create a neighbour cache entry, without the need for neighbour
neighbour discovering the original solicitor. If the device is a		discovering the original solicitor.
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		2.2 Sending Router Solicitations with TSLLAO
Router Solicitations are always able to be sent without Source Link-		Any Router Solicitation from a Preferred, Deprecated or Optimistic
Layer Address options.		address MAY be sent with a TSLLAO [4].
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		An extension which allows Router Solicitations to be sent with a
		TSLLAO from the unspecified address is described in Appendix C.
In the case that a node receives a solicitation without a Link-Layer		3. Receiving Tentative Source Link-Layer Address Options
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		Receiving a Tentative Source Link-Layer Address Option allows nodes
address, the node will consult its existing neighbour cache for the		to unicast responses to solicitations without performing neighbour
solicitor's information, and if not present, will undertake neighbour
discovery.		discovery.
Receiving a Tentative Source Link-Layer Address Option, avoids this		It does this by allowing the solicitation to create STALE neighbour
neighbour discovery step, by allowing the host to create or update a		cache entries if one doesn't exist, but only update an entry if the
matching entry, setting it to STALE state if it didn't previously		link-layer address in the option matches the entry.
exist.
Additionally, TSLLAO messages may be used to direct advertisements to		Additionally, TSLLAO messages may be used to direct advertisements to
particular link-layer destinations without updating neighbour cache		particular link-layer destinations without updating neighbour cache
entries. This is described in section 3.4.		entries. This is described in Appendix C.
3.1 Handling messages with Tentative Source Link-Layer Address Options		3.1 Handling Tentative Source Link-Layer Address Options
Use of Tentative Source Link-Layer Address Options is only defined		Use of Tentative Source Link-Layer Address Options is only defined
for Neighbour and Router Solicitation messages.		for Neighbour and Router Solicitation messages.
In any other received message, a Tentative Source Link-Layer Address		In any other received message, the presence of the option is silently
Option MUST be treated as if it is an unknown option, and processed		ignored, that is, the packet is processed as if the option was not
appropriately.		present.
It is REQUIRED that the same validation algorithms for Neighbour and		It is REQUIRED that the same validation algorithms for Neighbour and
Router Solicitations received with TSLLAO as in the IPv6 Neighbour		Router Solicitations received with TSLLAO as in the IPv6 Neighbour
Discovery specification [RFC-2461], are used. In the case that a		Discovery specification [2], are used.
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		In the case that a solicitation containing a TSLLAO is received, The
		only processing differences occur in checking and updating the
		neighbour cache entry. Particularly, there is no reason to believe
		that the host will remain tentative after receiving a responding
		advertisement.
		As defined in Section 1.1, Tentative Source Link-Layer Address
Options do not overwrite existing neighbour cache entries where the		Options do not overwrite existing neighbour cache entries where the
link-layer addresses differ.		link-layer addresses of the option and entry differ.
If a solicitation from a unicast source address is received where no		If a solicitation from a unicast source address is received where no
conflict occurs between the TSLLAO and an existing neighbour cache		difference exists between the TSLLAO and an existing neighbour cache
entry, the option MUST be treated as if it were an SLLAO after		entry, the option MUST be treated as if it were an SLLAO after
message validation, and processed accordingly.		message validation, and processed accordingly.
In the case that a cache entry is unable to be created or updated,		In the case that a cache entry is unable to be created or updated due
the receiving node MAY send a direct advertisement to the soliciting		to existence of a conflicting neighbour cache entry, it MUST NOT
host by responding with an appropriate advertisement, where the link-		update the neighbour cache entry.
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.		An extension which allows a direct advertisement to the soliciting
		host without modifying the neighbour cache entry is described in
		Appendix C.
3.2 Receiving Neighbour Solicitations containing TSLLAO		3.2 Receiving Neighbour Solicitations containing TSLLAO
The TSLLAO option is only allowed in Neighbour Solicitations with		The TSLLAO option is only allowed in Neighbour Solicitations with
specified source addresses for which SLLAO is not required. A		specified source addresses for which SLLAO is not required.
Neighbour Solicitation message received with TSLLAO and an
		A Neighbour Solicitation message received with TSLLAO and an
unspecified source address MUST be silently discarded.		unspecified source address MUST be silently discarded.
Upon reception of a Tentative Source Link-Layer Address Option in a		Upon reception of a Tentative Source Link-Layer Address Option in a
Neighbour Solicitation for which the receiver has the Target Address		Neighbour Solicitation for which the receiver has the Target Address
configured, a node checks to see if there is a neighbour cache entry		configured, a node checks to see if there is a neighbour cache entry
with conflicting link-layer address.		with conflicting link-layer address.
If no such entry exists, the neighbour cache of the receiver SHOULD		If no such entry exists, the neighbour cache of the receiver SHOULD
be updated, as if the Tentative Source Link-Layer Address Option was		be updated, as if the Tentative Source Link-Layer Address Option was
a SLLAO.		a SLLAO.
Sending of the solicited Neighbour Advertisement then proceeds		Sending of the solicited Neighbour Advertisement then proceeds
normally, as defined in section 7.2.4 of [RFC-2461].		normally, as defined in section 7.2.4 of [2].
If there is a conflicting neighbour cache entry, a node processes the		If there is a conflicting neighbour cache entry, the node processes
solicitation in a fashion defined in in sections 3.4 and 3.5.		the solicitation as defined in Section 7.2.4 of [2], except that the
		Neighbour Cache entry MUST NOT be modified.
3.3 Receiving a Router Solicitation containing TSLLAO		3.3 Receiving a Router Solicitation containing TSLLAO
In IPv6 Neighbour Discovery [RFC-2461], responses to router		In IPv6 Neighbour Discovery [2], responses to Router Solicitations
solicitations are either sent to the all-nodes multicast address, or		are either sent to the all-nodes multicast address, or may be sent to
may be sent to the solicitation's source address if it is a unicast		the solicitation's source address if it is a unicast address.
address.
Including a TSLLAO in the solicitation allows a router to choose to		Including a TSLLAO in the solicitation allows a router to choose to
send a packet directly to the link-layer address even in situations		send a packet directly to the link-layer address even in situations
where this would not normally be possible.		where this would not normally be possible.
For Router Solicitations with unicast source addresses, neighbour		For Router Solicitations with unicast source addresses, neighbour
caches SHOULD be updated with the link-layer address from a TSLLAO if		caches SHOULD be updated with the link-layer address from a TSLLAO if
there is no conflicting neighbour cache entry. In this case, Router		there is no differing neighbour cache entry. In this case, Router
Advertisement continues as in section 6.2.6 of [RFC-2461].		Advertisement continues as in Section 6.2.6 of [2].
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
below.
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
occur.
Router Solicitations with the unspecified source address MUST NOT
create neighbour cache entires.
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		For received solicitations with a differing link-layer address to
created, a multicast response SHOULD be sent in accordance with		that stored in the neighbour cache, the node processes the
[RFC-2461]. This includes those solicitations sent from unicast		solicitation as defined in Section 6.2.6 of [2], except that the
sources, for which a conflicting neighbour cache entry was found.		Neighbour Cache entry MUST NOT be modified.
4.0 IANA Considerations		4. IANA Considerations
For standardization, it would be required that the IANA provide		For standardization, it would be required that the IANA provide
allocation of the Tentative Source Link-Layer Address Option (Section		allocation of the Tentative Source Link-Layer Address Option (Section
1.1) from the IPv6 Neighbour Discovery options for IPv6.		1.1) from the IPv6 Neighbour Discovery options for IPv6.
		Current experimental implementations have used the value 0x11 (17)
		for the Tentative Source Link-Layer Address Option.
Potential details of the allocation process for these options is		Potential details of the allocation process for these options is
detailed in the expired draft [IPv6-ALLOC].		detailed in the expired draft [5].
5.0 Security Considerations		5. Security Considerations
The use of the TSLLAO in Neighbour and Router Solicitation messages		The use of the TSLLAO in Neighbour and Router Solicitation messages
acts in a similar manner to SLLAO, updating neighbour cache entries,		acts in a similar manner to SLLAO, updating neighbour cache entries,
in a way which causes packet transmission.		in a way which causes packet transmission.
Particular care should be taken that transmission of messages		Particular care should be taken that transmission of messages
complies with existing IPv6 Neighbour Discovery Procedures, so that		complies with existing IPv6 Neighbour Discovery Procedures, so that
unmodified hosts do not receive invalid messages.		unmodified hosts do not receive invalid messages.
An attacker may cause messages may be sent to another node by an		An attacker may cause messages may be sent to another node by an
Skipping to change at page 9, line 36:
greater available bandwidth than the victim.		greater available bandwidth than the victim.
For link-layers where it isn't possible to spoof the link-layer		For link-layers where it isn't possible to spoof the link-layer
source address this allows a slightly increased risk of reflection		source address this allows a slightly increased risk of reflection
attacks from nodes which are on-link.		attacks from nodes which are on-link.
Additionally, since a SEND host must always advertise using SEND		Additionally, since a SEND host must always advertise using SEND
options and signatures, a non-SEND attacker may cause excess		options and signatures, a non-SEND attacker may cause excess
computation on both a victim node and a router by causing SEND		computation on both a victim node and a router by causing SEND
advertisement messages to be transmitted to a particular MAC address		advertisement messages to be transmitted to a particular MAC address
and the all-nodes multicast. [SEND] specifies guidelines to hosts		and the all-nodes multicast. [3] specifies guidelines to hosts
receiving unsolicited advertisements in order to mitigate such		receiving unsolicited advertisements in order to mitigate such
attacks.		attacks.
While this is the same effect as experienced when accepting SLLAO		While this is the same effect as experienced when accepting SLLAO
from non-SEND nodes, the lack of created neighbour cache entries on		from non-SEND nodes, the lack of created neighbour cache entries on
the advertiser may make such attacks more difficult to trace.		the advertiser may make such attacks more difficult to trace.
Modification of Neighbour Discovery messages on the network is		Modification of Neighbour Discovery messages on the network is
possible, unless SEND is used. [SEND] provides a protocol		possible, unless SEND is used. [3] provides a protocol specification
specification in which soliciting nodes sign ND messages with a		in which soliciting nodes sign ND messages with a private key and use
private key and use addresses generated from this key.		addresses generated from this key.
Even if SEND is used, the lifetime of a neighbour cache entry may be		Even if SEND is used, the lifetime of a neighbour cache entry may be
extended by continually replaying a solicitation message to a		extended by continually replaying a solicitation message to a
particular router or hosts. Since this may be achieved for any		particular router or hosts. Since this may be achieved for any
Neighbour or Router Solicitation message, corresponding		Neighbour or Router Solicitation message, corresponding
advertisements to the original transmitters of these solicitation		advertisements to the original transmitters of these solicitation
messages may occur.		messages may occur.
SEND defines use of Timestamp values to protect a device from attack		SEND defines use of Timestamp values to protect a device from attack
through replay of previously sent messages. Although this applies to		through replay of previously sent messages. Although this applies to
Neighbour and Router Solicitation messages, granularity of the		Neighbour and Router Solicitation messages, granularity of the
timestamp allows the messages to be used for up to two hours in		timestamp allows the messages to be used for up to five minutes [3].
extreme cases [SEND].
All Router and Neighbour Solicitations using SEND contain a Nonce		All Router and Neighbour Solicitations using SEND contain a Nonce
option, containing a random identifier octet string. Since SEND		option, containing a random identifier octet string. Since SEND
messages are digitally signed, and may not be easily modified, replay		messages are digitally signed, and may not be easily modified, replay
attacks will contain the same Nonce option, as was used in the		attacks will contain the same Nonce option, as was used in the
original solicitation.		original solicitation.
While the Nonce Option included in a transmission to another node may		While the Nonce Option included in a transmission to another node may
not vary within one short solicitation period (the host may itself		not vary within one short solicitation period (the host may itself
replay solicitations in the case of packet loss), the presence of the		replay solicitations in the case of packet loss), the presence of the
timestamp option ensures that for later solicitations, a different		timestamp option ensures that for later solicitations, a different
Timestamp and Nonce will be used.		Timestamp and Nonce will be used.
Therefore, a receiver seeing a solicitation with the same Timestamp		Therefore, a receiver seeing a solicitation with the same Timestamp
and Nonce (and signature) for more than either of		and Nonce (and signature) for more than either of
MAX_RTR_SOLICITATIONS (for router solicitations), MAX_UNICAST_SOLICIT		MAX_RTR_SOLICITATIONS (for Router Solicitations), MAX_UNICAST_SOLICIT
or MAX_MULTICAST_SOLICIT (for Neighbour Solicitations), SHOULD ignore		or MAX_MULTICAST_SOLICIT (for Neighbour Solicitations), SHOULD ignore
further solicitations with this (Nonce,Timestamp,Source) triple,		further solicitations with this (Nonce,Timestamp,Source) triple,
ensuring that no modification is made to neighbour cache entries.		ensuring that no modification is made to neighbour cache entries.
This applies to any solicitation packet capable of carrying a SEND		This applies to any solicitation packet capable of carrying a SEND
payload, whether they use TSLLAO or SLLAO.		payload, whether they use TSLLAO or SLLAO.
Stations noticing such an attack SHOULD notify their administrator of		Stations noticing such an attack SHOULD notify their administrator of
the attempt at Denial-of-service.		the attempt at Denial-of-service.
Normative References		6. Acknowledgments
[KEYW-RFC] S. Bradner. Key words for use in RFCs to Indicate		Erik Nordmark coined a proposal for TSLLAO during a conversation with
Requirement Levels. Request for Comments (Best Current Practice)		JinHyeock Choi and Greg Daley.
2119 (BCP 14), Internet Engineering Task Force, March 1997
[OPTIDAD] N. Moore. Optimistic Duplicate Address Detection. Internet		7. References
Draft (work in progress), March 2004.
[RFC-2461] T. Narten, E.Nordmark, W. Simpson. Neighbour Discovery		7.1 Normative References
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).		[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Internet Draft (work in progress), April 2004.		Levels", BCP 14, RFC 2119, March 1997.
Non-Normative References		[2] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
		for IP Version 6 (IPv6)", RFC 2461, December 1998.
[IPv6-ALLOC] T. Narten. "IANA Allocation Guidelines for Values in		[3] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B., and P. Nikander,
IPv6 and Related Headers", Internet Draft (work in progress),		"SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-06
October 2002. www.watersprings.org/pub/id/draft-narten-		(work in progress), July 2004.
ipv6-iana-considerations-00.txt
Acknowledgments		[4] Moore, N., "Optimistic Duplicate Address Detection for IPv6",
		draft-ietf-ipv6-optimistic-dad-03 (work in progress),
		January 2005.
Erik Nordmark coined a proposal for TSLLAO during a conversation with		7.2 Informative References
JinHyeock Choi and Greg Daley.
		[5] Narten, T., "IANA Allocation Guidelines for Values in IPv6 and
		Related Headers", draft-narten-ipv6-iana-considerations-00 (work
		in progress), October 2002.
		[6] Thomson, S. and T. Narten, "IPv6 Stateless Address
		Autoconfiguration", RFC 2462, December 1998.
Authors' Addresses		Authors' Addresses
Greg Daley		Greg Daley
		Centre for Telecommunications and Information Engineering
		Department of Electrical and Computer Systems Engineering
		Monash University
		Clayton, Victoria 3800
		Australia
greg.daley@eng.monash.edu.au		Phone: +61 3 9905 4655
		Email: greg.daley@eng.monash.edu.au
Nick "Sharkey" Moore		Erik Nordmark
		Sun Microsystems, Inc.
		17 Network Circle
		Mountain View, CA
		USA
nick.moore@eng.monash.edu.au		Phone: +1 650 786 2921
		Email: erik.nordmark@sun.com
		Nick "Sharkey" Moore
Centre for Telecommunications and Information Engineering		Centre for Telecommunications and Information Engineering
Department of Electrical and Computer Systems Engineering		Department of Electrical and Computer Systems Engineering
Monash University		Monash University
Clayton 3800		Clayton, Victoria 3800
Victoria
Australia		Australia
Erik Nordmark		Email: nick.moore@eng.monash.edu.au
erik.nordmark@sun.com		Appendix A. Constraints imposed by IPv6 Neighbour Discovery
Sun Microsystems, Inc.		Hosts which send and receive Tentative Source Link Layer Address
17 Network Circle		Options may be interacting with legacy nodes which support IPv6
Mountain View, CA		Neighbour Discovery procedures, but do not understand the new option.
USA
phone: +1 650 786 2921		For these nodes, the presence of the option is silently ignored, that
fax: +1 650 786 5896		is, the packet is processed as if the option was not present.
		Therefore all messages sent with TSLLAO options MUST be compliant
		with the existing requirements for options and addressing specified
		in the IPv6 Neighbour Discovery RFC [2].
Intellectual Property Rights		A.1 Constraints on Neighbour Solicitations
By submitting this Internet-Draft, I certify that any applicable		As described in Section 7.2.2 of [2], packets sent to solicited
patent or other IPR claims of which I am aware have been disclosed,		nodes' multicast addresses MUST contain Source Link-Layer Address
and any of which I become aware will be disclosed, in accordance with		options.
RFC 3668.
		Neighbour solicitations to multicast addresses MUST NOT contain
		TSLLAO
		Neighbour Solicitations to unicast addresses SHOULD include a link-
		layer address (if the sender has one has one) as a Source Link-Layer
		Address option.
		Unicast neighbour solicitations without Source Link-Layer Address
		Options MAY contain TSLLAO, if the solicitor has a Link-Layer
		address.
		A.2 Constraints on Router Solicitations
		As described in Section 6.3.7 of [2], Router Solicitations SHOULD
		contain Source Link-Layer Address Options.
		Router Solicitations without Source Link-Layer Address options MAY
		contain a TSLLAO.
		Appendix B. Interactions with legacy nodes
		Devices which do not implement Tentative Source Link Layer address
		options will act as if no option was placed within the Neighbour
		Discovery message. The following sections summarize how legacy hosts
		will interact with messages containing TSLLAO.
		Appendix B.1 Legacy Neighbour Solicitation processing
		A node can include the TSLLAO option in a unicast NS (and no SLLAO
		option) when the transmitter's address is either tentative or
		optimistic.
		An RFC 2461 host receiving such a packet will "see" a packet
		without an SLLAO option, which is allowed in RFC2461.
		If the recipient host has an existing neighbour cache entry for
		the transmitter, it can then send a Neighbour Advertisement.
		Where no neighbour cache entry exists, the recipient will send a
		multicast NS (containing its own SLLAO) in order for the original
		transmitter to respond with an NA. Upon reception of the original
		transmitter's NA, an NA is sent back to the origin.
		The TSLLAO option MUST NOT be included in an NS message which has no
		source address.
		An RFC 2461 host sees an NS without a source address as a
		Duplicate Address Detection message.
		Reception of duplicate address detection messages may cause side-
		effects on other hosts, which may cause them to treat addresses as
		invalid.
		Appendix B.2 Legacy Router Solicitation Processing
		A node can include the TSLLAO option in an RS with a unicast source
		address (and no SLLAO option) when the transmitter's address is
		either tentative or optimistic.
		An RFC 2461 router receiving such a packet will "see" a packet
		without an SLLAO option, which is allowed in RFC2461.
		If the router has an existing neighbour cache entry for this host,
		it may send a Unicast RA in response, but may send a multicast in
		preference.
		If no neighbour cache entry exists, some routers will not be able
		to provide a unicast response. These routers will schedule a
		multicast response.
		Other routers may attempt to perform neighbour discovery (by
		sending a multicast NS), and unicast a response when a neighbour
		cache entry has been created.
		A node can include the TSLLAO option in an RS with an unspecified
		source address (and no SLLAO option) when the transmitter's address
		is tentative. This is described in Appendix C.
		RFC 2461 routers receiving this solicitation will "see" a message
		without a SLLAO (such options are not allowed in RFC2461).
		These routers will schedule a multicast RA response.
		Appendix C. Sending Directed Advertisements without the Neighbour Cache
		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. Also, RS packets sent without a specificed
		source address may potentially contain a TSLLAO.
		In this case the unicast link-layer address from the solicitation MAY
		be extracted from the TSLLAO option and used as the destination of
		the link-layer frame for a responding Router Advertisment.
		Sending such a packet MUST NOT consult the neighbour or destination
		caches for address.
		Such packets SHOULD scheduled as if they were unicast advertisements
		as specified in [2].
		If an implementation can not send a Router Advertisement using
		information from the TSLLAO i.e, without consulting the neighbour
		cache, then it SHOULD behave as if the TSLLAO option was not present
		in the solicitation message.
		Intellectual Property Statement
		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.
		Disclaimer of Validity
		This document and the information contained herein are provided on an
		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement		Copyright Statement
Copyright (C) The Internet Society (2004). This document is		Copyright (C) The Internet Society (2005). This document is subject
subject to the rights, licenses and restrictions contained in BCP		to the rights, licenses and restrictions contained in BCP 78, and
78, and except as set forth therein, the authors retain all their		except as set forth therein, the authors retain all their rights.
rights.
This document and the information contained herein are provided		Acknowledgment
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
This document expires in December 2004.		Funding for the RFC Editor function is currently provided by the
		Internet Society.
End of changes.
This html diff was produced by rfcdiff v1.01, available from http://www.levkowetz.com/ietf/tools/rfcdiff/