draft-ietf-dna-tentative-02.txt   draft-ietf-dna-tentative-03.txt 
Network Working Group G. Daley Network Working Group G. Daley
Internet-Draft NetStar Networks Internet-Draft NetStar Networks
Intended status: Standards Track E. Nordmark Intended status: Standards Track E. Nordmark
Expires: September 10, 2009 Sun Microsystems Expires: April 29, 2010 Sun Microsystems
N. Moore N. Moore
March 9, 2009 October 26, 2009
Tentative Options for Link-Layer Addresses in IPv6 Neighbour Discovery Tentative Options for Link-Layer Addresses in IPv6 Neighbour Discovery
draft-ietf-dna-tentative-02.txt draft-ietf-dna-tentative-03.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 to 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/1id-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 Internet-Draft will expire on September 10, 2009. This Internet-Draft will expire on April 29, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 9 skipping to change at page 3, line 9
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.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Tentative Option format . . . . . . . . . . . . . . . . . 4 2.1. Tentative Option format . . . . . . . . . . . . . . . . . 5
2.2. Tentative Option semantics . . . . . . . . . . . . . . . . 5 2.2. Tentative Option semantics . . . . . . . . . . . . . . . . 5
3. Sending solicitations containing Tentative Options . . . . . . 5 3. Sending solicitations containing Tentative Options . . . . . . 5
3.1. Sending Neighbour Solicitations with Tentative Options . . 6 3.1. Sending Neighbour Solicitations with Tentative Options . . 6
3.2. Sending Router Solicitations with Tentative Options . . . 6 3.2. Sending Router Solicitations with Tentative Options . . . 6
4. Receiving Tentative Options . . . . . . . . . . . . . . . . . 6 4. Receiving Tentative Options . . . . . . . . . . . . . . . . . 6
4.1. Handling Tentative Options . . . . . . . . . . . . . . . . 7 4.1. Handling Tentative Options . . . . . . . . . . . . . . . . 6
4.2. Receiving Neighbour Solicitations containing Tentative 4.2. Receiving Neighbour Solicitations containing Tentative
Options . . . . . . . . . . . . . . . . . . . . . . . . . 7 Options . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Receiving a Router Solicitation containing a Tentative 4.3. Receiving a Router Solicitation containing a Tentative
Option . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Option . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Constraints imposed by IPv6 Neighbour Discovery . . 11 Appendix A. Constraints imposed by IPv6 Neighbour Discovery . . 11
A.1. Constraints on Neighbour Solicitations . . . . . . . . . . 11 A.1. Constraints on Neighbour Solicitations . . . . . . . . . . 11
A.2. Constraints on Router Solicitations . . . . . . . . . . . 12 A.2. Constraints on Router Solicitations . . . . . . . . . . . 11
Appendix B. Interactions with legacy nodes . . . . . . . . . . . 12 Appendix B. Interactions with legacy nodes . . . . . . . . . . . 11
Appendix B.1. Legacy Neighbour Solicitation processing . . . . . . 12 Appendix B.1. Legacy Neighbour Solicitation processing . . . . . . 12
Appendix B.2. Legacy Router Solicitation processing . . . . . . . 12 Appendix B.2. Legacy Router Solicitation processing . . . . . . . 12
Appendix C. Sending directed advertisements without the Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
neighbour cache . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Terminology 1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
RFC 2119. RFC 2119.
2. Introduction 2. Introduction
skipping to change at page 4, line 47 skipping to change at page 4, line 47
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. In not have an existing neighbour cache entry for the solicitor. In
some cases, multicast advertisements will be scheduled, where some cases, multicast advertisements will be scheduled, where
Neighbour Discovery is not possible on the advertiser. Neighbour Discovery is not possible on the advertiser.
This document proposes Tentative Options which designed to replace This document proposes Tentative Options which 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. Neighbour Discovery, when a device is performing Optimistic DAD.
Operations in this document are safe with respect to existing nodes
that implement IPv6 Neighbor Discovery [RFC4861] and Stateless
Address Autoconfiguration. Expected behaviours of legacy decives are
summarized in Appendix B.
2.1. Tentative Option format 2.1. Tentative 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)
Length The length of the option (including the type and Length The length of the option (including the type and
skipping to change at page 6, line 4 skipping to change at page 6, line 7
These procedures are discussed further in Section 4.3. These procedures are discussed further in Section 4.3.
3. Sending solicitations containing Tentative Options 3. Sending solicitations containing Tentative Options
Tentative Options may be sent in Router and Neighbour Solicitations, Tentative Options may be sent in Router and Neighbour Solicitations,
as described below. as described below.
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 TO, since the message may be Option, a host SHOULD NOT send a TO, since the message may be
misinterpreted by legacy nodes. misinterpreted by legacy nodes. Importantly, a node MUST NOT send a
Tentative Option in the same message where a Source Link-Layer
Address Option is sent.
Importantly, a node MUST NOT send a Tentative Option in the same Particularly, Tentative Options are premitted to be sent when
message where a Source Link-Layer Address Option is sent. addressing state precludes sending the SLLAO, but a neighbour cache
entry will be created on a peer node [RFC4429].
3.1. Sending Neighbour Solicitations with Tentative Options 3.1. Sending Neighbour Solicitations with Tentative Options
Neighbour Solicitations sent to unicast addresses MAY contain a Neighbour Solicitations sent to unicast addresses MAY contain a
Tentative Option. Tentative Option.
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.
skipping to change at page 6, line 33 skipping to change at page 6, line 39
As discussed in [RFC4861], the peer device may not have a cache entry As discussed in [RFC4861], the peer device may not have a cache entry
even if the soliciting host does, in which case reception of the even if the soliciting host does, in which case reception of the
Tentative Option may create a neighbour cache entry, without the need Tentative Option may create a neighbour cache entry, without the need
for Neighbour Discovering the original solicitor. for Neighbour Discovering the original solicitor.
3.2. Sending Router Solicitations with Tentative Options 3.2. Sending Router Solicitations with Tentative Options
Any Router Solicitation from a Preferred, Deprecated or Optimistic Any Router Solicitation from a Preferred, Deprecated or Optimistic
address MAY be sent with a Tentative Option [RFC4429]. address MAY be sent with a Tentative Option [RFC4429].
An extension which allows Router Solicitations to be sent with a TO
from the unspecified address is described in Appendix C.
4. Receiving Tentative Options 4. Receiving Tentative Options
Receiving a Tentative Option allows nodes to unicast responses to Receiving a Tentative Option allows nodes to unicast responses to
solicitations without performing Neighbour Discovery. solicitations without performing Neighbour Discovery.
It does this by allowing the solicitation to create STALE neighbour It does this by allowing the solicitation to create STALE neighbour
cache entries if one doesn't exist, but only update an entry if the cache entries if one doesn't exist, but only update an entry if the
link-layer address in the option matches the entry. link-layer address in the option matches the entry.
Additionally, messages containing TO may be used to direct
advertisements to particular link-layer destinations without updating
neighbour cache entries. This is described in Appendix C.
4.1. Handling Tentative Options 4.1. Handling Tentative Options
Use of Tentative Options is only defined for Neighbour and Router Use of Tentative Options is only defined for Neighbour and Router
Solicitation messages. Solicitation messages.
In any other received message, the presence of the option is silently In any other received message, the presence of the option is silently
ignored, that is, the packet is processed as if the option was not ignored, that is, the packet is processed as if the option was not
present. present.
It is REQUIRED that the same validation algorithms for Neighbour and It is REQUIRED that the same validation algorithms for Neighbour and
skipping to change at page 7, line 37 skipping to change at page 7, line 32
If a solicitation from a unicast source address is received where no If a solicitation from a unicast source address is received where no
difference exists between the TO and an existing neighbour cache difference exists between the TO 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 due In the case that a cache entry is unable to be created or updated due
to existence of a conflicting neighbour cache entry, it MUST NOT to existence of a conflicting neighbour cache entry, it MUST NOT
update the neighbour cache entry. update the neighbour cache entry.
An extension which allows a direct advertisement to the soliciting
host without modifying the neighbour cache entry is described in
Appendix C.
4.2. Receiving Neighbour Solicitations containing Tentative Options 4.2. Receiving Neighbour Solicitations containing Tentative Options
The Tentative Option is only allowed in Neighbour Solicitations with The Tentative Option is only allowed in Neighbour Solicitations with
specified source addresses for which SLLAO is not required. specified source addresses for which SLLAO is not required.
A Neighbour Solicitation message received with a TO and an A Neighbour Solicitation message received with a TO and an
unspecified source address MUST be silently discarded. unspecified source address MUST be silently discarded.
Upon reception of a Tentative Option in a Neighbour Solicitation for Upon reception of a Tentative Option in a Neighbour Solicitation for
which the receiver has the Target Address configured, a node checks which the receiver has the Target Address configured, a node checks
skipping to change at page 8, line 41 skipping to change at page 8, line 32
For received solicitations with a differing link-layer address to For received solicitations with a differing link-layer address to
that stored in the neighbour cache, the node processes the that stored in the neighbour cache, the node processes the
solicitation as defined in Section 6.2.6 of [RFC4861], except that solicitation as defined in Section 6.2.6 of [RFC4861], except that
the Neighbour Cache entry MUST NOT be modified. the Neighbour Cache entry MUST NOT be modified.
5. IANA Considerations 5. IANA Considerations
IANA action of options for IPv6 Neighbor Discovery require RFC IANA action of options for IPv6 Neighbor Discovery require RFC
Approval. Approval.
For standardization, this document requires that the IANA allocate This document asks the IANA to allocate the Tentative Option for
the Tentative Option for link-layer addressing (Section Section 2.1) link-layer addressing (Section Section 2.1) from the IPv6 Neighbour
from the IPv6 Neighbour Discovery options for IPv6. Discovery options for IPv6.
Previous (older) experimental implementations have used the value
0x11 (17) for the Tentative Option, before the IPv6 Neighbour
Discovery experimental range was defined [RFC4727].
6. Security Considerations 6. Security Considerations
The use of the Tentative Option in Neighbour and Router Solicitation The use of the Tentative Option in Neighbour and Router Solicitation
messages acts in a similar manner to SLLAO, updating neighbour cache messages acts in a similar manner to SLLAO, updating neighbour cache
entries, in a way which causes packet transmission. entries, in a way which affects the transmission of subsequent
packets.
Particular care should be taken that transmission of messages Particular care is taken that transmission of messages complies with
complies with existing IPv6 Neighbour Discovery Procedures, so that existing IPv6 Neighbour Discovery Procedures, so that unmodified
unmodified hosts do not receive invalid messages. 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
advertising node (a reflector), without creating any ongoing state on advertising node (a reflector), without creating any ongoing state on
the reflector. the reflector.
This is attack requires one solicitation for each advertisement and This is attack requires one solicitation for each advertisement and
the advertisement has to go to a unicast MAC destination. That said, the advertisement has to go to a unicast MAC destination. That said,
the size of the advertisement may be significantly larger than the the size of the advertisement may be significantly larger than the
solicitation, or the attacker and reflector may be on a medium with solicitation, or the attacker and reflector may be on a medium with
greater available bandwidth than the victim. greater available bandwidth than the victim.
skipping to change at page 13, line 20 skipping to change at page 13, line 5
preference. preference.
If no neighbour cache entry exists, some routers will not be able If no neighbour cache entry exists, some routers will not be able
to provide a unicast response. These routers will schedule a to provide a unicast response. These routers will schedule a
multicast response. multicast response.
Other routers may attempt to perform neighbour discovery (by Other routers may attempt to perform neighbour discovery (by
sending a multicast NS), and unicast a response when a neighbour sending a multicast NS), and unicast a response when a neighbour
cache entry has been created. cache entry has been created.
A node can include the Tentative 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 RFC4861 for
messages with unspecified source).
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 Tentative Option. Also, RS packets sent without a
specificed source address may potentially contain a Tentative Option.
In this case the unicast link-layer address from the solicitation MAY
be extracted from the Tentative 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 [RFC4861].
If an implementation can not send a Router Advertisement using
information from the Tentative Option i.e, without consulting the
neighbour cache, then it SHOULD behave as if the Tentative Option was
not present in the solicitation message.
Authors' Addresses Authors' Addresses
Greg Daley Greg Daley
NetStar Australia Pty Ltd NetStar Australia Pty Ltd
Lvl 9/636 St Kilda Rd Lvl 9/636 St Kilda Rd
Melbourne, Victoria 3004 Melbourne, Victoria 3004
Australia Australia
Phone: +61 401 772 770 Phone: +61 401 772 770
Email: gdaley@netstarnetworks.com Email: gdaley@netstarnetworks.com
 End of changes. 21 change blocks. 
70 lines changed or deleted 31 lines changed or added

This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/