draft-ietf-dna-tentative-03.txt   draft-ietf-dna-tentative-04.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: April 29, 2010 Sun Microsystems Expires: April 29, 2010 Sun Microsystems
N. Moore N. Moore
October 26, 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-03.txt draft-ietf-dna-tentative-04.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 3, line 11 skipping to change at page 3, line 11
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 . . . . . . . . . . . . . . . . . 5 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 . . . . . . 6
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 . . . . . . . . . . . . . . . . 6 4.1. Handling Tentative Options . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . 11 A.2. Constraints on Router Solicitations . . . . . . . . . . . 11
Appendix B. Interactions with legacy nodes . . . . . . . . . . . 11 Appendix B. Interactions with legacy nodes . . . . . . . . . . . 11
Appendix B.1. Legacy Neighbour Solicitation processing . . . . . . 12 B.1. Legacy Neighbour Solicitation processing . . . . . . . . . 12
Appendix B.2. Legacy Router Solicitation processing . . . . . . . 12 B.2. Legacy Router Solicitation processing . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
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
[RFC2119]
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119
2. Introduction 2. 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 [RFC4861]. defined in IPv6 Neighbour Discovery [RFC4861].
skipping to change at page 4, line 49 skipping to change at page 5, line 8
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 Operations in this document are safe with respect to existing nodes
that implement IPv6 Neighbor Discovery [RFC4861] and Stateless that implement IPv6 Neighbor Discovery [RFC4861] and Stateless
Address Autoconfiguration. Expected behaviours of legacy decives are Address Autoconfiguration [RFC4862]. Expected behaviours of legacy
summarized in Appendix B. devices 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:
skipping to change at page 6, line 11 skipping to change at page 6, line 18
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. Importantly, a node MUST NOT send a misinterpreted by legacy nodes. Importantly, a node MUST NOT send a
Tentative Option in the same message where a Source Link-Layer Tentative Option in the same message where a Source Link-Layer
Address Option is sent. Address Option is sent.
Particularly, Tentative Options are premitted to be sent when Particularly, Tentative Options are permitted to be sent when
addressing state precludes sending the SLLAO, but a neighbour cache addressing state precludes sending the SLLAO, but a neighbour cache
entry will be created on a peer node [RFC4429]. 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
skipping to change at page 8, line 30 skipping to change at page 8, line 39
Router Advertisement continues as in Section 6.2.6 of [RFC4861]. Router Advertisement continues as in Section 6.2.6 of [RFC4861].
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 [RFC2780].
This document asks the IANA to allocate the Tentative Option for This document asks the IANA to allocate the Tentative Option for
link-layer addressing (Section Section 2.1) from the IPv6 Neighbour link-layer addressing (Section Section 2.1) from the IPv6 Neighbour
Discovery options for IPv6. Discovery options for IPv6.
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 affects the transmission of subsequent entries, in a way which affects the transmission of subsequent
packets. packets.
Particular care is 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 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 11, line 5 skipping to change at page 11, line 9
8.2. Informative References 8.2. Informative References
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
Values In the Internet Protocol and Related Headers", Values In the Internet Protocol and Related Headers",
BCP 37, RFC 2780, March 2000. BCP 37, RFC 2780, March 2000.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4,
ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.
Appendix A. Constraints imposed by IPv6 Neighbour Discovery Appendix A. Constraints imposed by IPv6 Neighbour Discovery
Hosts which send and receive Tentative Options may be interacting Hosts which send and receive Tentative Options may be interacting
with legacy nodes which support IPv6 Neighbour Discovery procedures, with legacy nodes which support IPv6 Neighbour Discovery procedures,
but do not understand the new option. but do not understand the new option.
For these nodes, the presence of the option is silently ignored, that For these nodes, the presence of the option is silently ignored, that
is, the packet is processed as if the option was not present. is, the packet is processed as if the option was not present.
Therefore all messages sent with Tentative Options MUST be compliant Therefore all messages sent with Tentative Options MUST be compliant
with the existing requirements for options and addressing specified with the existing requirements for options and addressing specified
skipping to change at page 12, line 5 skipping to change at page 12, line 7
Router Solicitations without Source Link-Layer Address options MAY Router Solicitations without Source Link-Layer Address options MAY
contain a Tentative Option. contain a Tentative Option.
Appendix B. Interactions with legacy nodes Appendix B. Interactions with legacy nodes
Devices which do not implement Tentative Options will act as if no Devices which do not implement Tentative Options will act as if no
option was placed within the Neighbour Discovery message. The option was placed within the Neighbour Discovery message. The
following sections summarize how legacy hosts will interact with following sections summarize how legacy hosts will interact with
messages containing Tentative Options. messages containing Tentative Options.
Appendix B.1. Legacy Neighbour Solicitation processing B.1. Legacy Neighbour Solicitation processing
A node can include the Tentative Option in a unicast NS (and no SLLAO A node can include the Tentative Option in a unicast NS (and no SLLAO
option) when the transmitter's address is either preferred, tentative option) when the transmitter's address is either preferred, tentative
or optimistic. or optimistic.
An RFC 2461 host receiving such a packet will "see" a packet An RFC 2461 host receiving such a packet will "see" a packet
without an SLLAO option, which is allowed in RFC4861. without an SLLAO option, which is allowed in RFC4861.
If the recipient host has an existing neighbour cache entry for If the recipient host has an existing neighbour cache entry for
the transmitter, it can then send a Neighbour Advertisement. the transmitter, it can then send a Neighbour Advertisement.
skipping to change at page 12, line 32 skipping to change at page 12, line 34
The Tentative Option MUST NOT be included in an NS message which has The Tentative Option MUST NOT be included in an NS message which has
no source address. no source address.
An RFC 2461 host sees an NS without a source address as a An RFC 2461 host sees an NS without a source address as a
Duplicate Address Detection message. Duplicate Address Detection message.
Reception of duplicate address detection messages may cause side- Reception of duplicate address detection messages may cause side-
effects on other hosts, which may cause them to treat addresses as effects on other hosts, which may cause them to treat addresses as
invalid. invalid.
Appendix B.2. Legacy Router Solicitation processing B.2. Legacy Router Solicitation processing
A node can include the Tentative Option in an RS with a unicast A node can include the Tentative Option in an RS with a unicast
source address (and no SLLAO option) when the transmitter's address source address (and no SLLAO option) when the transmitter's address
is either tentative or optimistic. is either tentative or optimistic.
An RFC 2461 router receiving such a packet will "see" a packet An RFC 2461 router receiving such a packet will "see" a packet
without an SLLAO option, which is allowed in RFC4861. without an SLLAO option, which is allowed in RFC4861.
If the router has an existing neighbour cache entry for this host, 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 it may send a Unicast RA in response, but may send a multicast in
 End of changes. 13 change blocks. 
21 lines changed or deleted 20 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/