draft-ietf-dna-tentative-01.txt   draft-ietf-dna-tentative-02.txt 
Network Working Group G. Daley Network Working Group G. Daley
Internet-Draft Internet-Draft NetStar Networks
Intended status: Standards Track E. Nordmark Intended status: Standards Track E. Nordmark
Expires: January 15, 2009 Sun Microsystems Expires: September 10, 2009 Sun Microsystems
N. Moore N. Moore
July 14, 2008 March 9, 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-01.txt draft-ietf-dna-tentative-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79. This document may contain material
have been or will be disclosed, and any of which he or she becomes from IETF Documents or IETF Contributions published or made publicly
aware will be disclosed, in accordance with Section 6 of BCP 79. available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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 Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. 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 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 January 15, 2009. This Internet-Draft will expire on September 10, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Tentative Option format . . . . . . . . . . . . . . . . . 3 2.1. Tentative Option format . . . . . . . . . . . . . . . . . 4
2.2. Tentative Option semantics . . . . . . . . . . . . . . . . 4 2.2. Tentative Option semantics . . . . . . . . . . . . . . . . 5
3. Sending solicitations containing Tentative Options . . . . . . 4 3. Sending solicitations containing Tentative Options . . . . . . 5
3.1. Sending Neighbour Solicitations with Tentative Options . . 5 3.1. Sending Neighbour Solicitations with Tentative Options . . 6
3.2. Sending Router Solicitations with Tentative Options . . . 5 3.2. Sending Router Solicitations with Tentative Options . . . 6
4. Receiving Tentative Options . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . . . . . 6 Options . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Receiving a Router Solicitation containing a Tentative 4.3. Receiving a Router Solicitation containing a Tentative
Option . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Option . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Constraints imposed by IPv6 Neighbour Discovery . . . 10 Appendix A. Constraints imposed by IPv6 Neighbour Discovery . . 11
A.1. Constraints on Neighbour Solicitations . . . . . . . . . . 10 A.1. Constraints on Neighbour Solicitations . . . . . . . . . . 11
A.2. Constraints on Router Solicitations . . . . . . . . . . . 10 A.2. Constraints on Router Solicitations . . . . . . . . . . . 12
Appendix B. Interactions with legacy nodes . . . . . . . . . . . 11 Appendix B. Interactions with legacy nodes . . . . . . . . . . . 12
B.1. Legacy Neighbour Solicitation processing . . . . . . . . . 11 Appendix B.1. Legacy Neighbour Solicitation processing . . . . . . 12
B.2. Legacy Router Solicitation processing . . . . . . . . . . 11 Appendix B.2. Legacy Router Solicitation processing . . . . . . . 12
Appendix C. Sending directed advertisements without the Appendix C. Sending directed advertisements without the
neighbour cache . . . . . . . . . . . . . . . . . . . 12 neighbour cache . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 14
1. Introduction 1. Terminology
1. Requirements notation The key words "MUST", "MUST NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
"REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be "OPTIONAL" in this document are to be interpreted as described in
interpreted as described in [RFC2119]. 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].
Optimistic DAD [RFC4429] prevents usage of these options in Router Optimistic DAD [RFC4429] prevents usage of these options in Router
and Neighbour Solicitation messages from a tentative address (while and Neighbour Solicitation messages from a tentative address (while
Duplicate Address Detection is occurring) [RFC4862]. This is because Duplicate Address Detection is occurring). This is because receiving
receiving a Neighbour Solicitation (NS) or Router Solicitation (RS) a Neighbour Solicitation (NS) or Router Solicitation (RS) containing
containing an SLLAO would otherwise overwrite an existing cache an SLLAO would otherwise overwrite an existing cache entry, even if
entry, even if the cache entry contained the legitimate address the cache entry contained the legitimate address owner, and the
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. 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.
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) suggest 17 (0x11) 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
length fields) in units of 8 octets. 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 option contains the link-layer The Tentative option contains the link-layer
address of the sender of the packet. It is used address of the sender of the packet. It is used
skipping to change at page 5, line 26 skipping to change at page 6, line 26
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 Tentative may be possible to send a Neighbour Solicitation with Tentative
Option to the router's advertised address. Option to the router's advertised address.
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 An extension which allows Router Solicitations to be sent with a TO
from the unspecified address is described in Appendix C. 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 Additionally, messages containing TO may be used to direct
advertisements to particular link-layer destinations without updating advertisements to particular link-layer destinations without updating
neighbour cache entries. This is described in Appendix C. neighbour cache entries. This is described in Appendix C.
4.1. Handling Tentative Options 4.1. Handling Tentative Options
skipping to change at page 7, line 38 skipping to change at page 8, line 38
Option if there is no differing neighbour cache entry. In this case, Option if there is no differing neighbour cache entry. In this case,
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
For standardization, it would be required that the IANA provide IANA action of options for IPv6 Neighbor Discovery require RFC
allocation of the Tentative Option for link-layer addressing (Section Approval.
1.1) from the IPv6 Neighbour Discovery options for IPv6.
Current experimental implementations have used the value 0x11 (17) For standardization, this document requires that the IANA allocate
for the Tentative Option. the Tentative Option for link-layer addressing (Section Section 2.1)
from the IPv6 Neighbour Discovery options for IPv6.
IANA action requires either IESG Approval or Standards Action Previous (older) experimental implementations have used the value
[RFC2780]. 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 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.
skipping to change at page 9, line 43 skipping to change at page 10, line 47
Erik Nordmark coined a proposal for Tentative version of the SLLAO Erik Nordmark coined a proposal for Tentative version of the SLLAO
during a conversation with JinHyeock Choi and Greg Daley. during a conversation with JinHyeock Choi and Greg Daley.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
Neighbor Discovery (SEND)", RFC 3971, March 2005. "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection for [RFC4429] Moore, N., "Optimistic Duplicate Address Detection for
IPv6", RFC RFC4429, April 2006. IPv6", RFC RFC4429, April 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, Neighbor Discovery (SEND)", RFC 3971, March 2005.
September 2007.
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
in the IPv6 Neighbour Discovery RFC [RFC4861]. in the IPv6 Neighbour Discovery RFC [RFC4861].
A.1. Constraints on Neighbour Solicitations A.1. Constraints on Neighbour Solicitations
As described in Section 7.2.2 of [RFC4861], packets sent to solicited As described in Section 7.2.2 of [RFC4861], packets sent to solicited
nodes' multicast addresses MUST contain Source Link-Layer Address nodes' multicast addresses MUST contain Source Link-Layer Address
options. options.
o Neighbour solicitations to multicast addresses MUST NOT contain Neighbour solicitations to multicast addresses MUST NOT contain
Tentative Options Tentative Options
Neighbour Solicitations to unicast addresses SHOULD include a link- Neighbour Solicitations to unicast addresses SHOULD include a link-
layer address (if the sender has one has one) as a Source Link-Layer layer address (if the sender has one has one) as a Source Link-Layer
Address option. Address option.
o Unicast neighbour solicitations without Source Link-Layer Address Unicast neighbour solicitations without Source Link-Layer Address
Options MAY contain Tentative Options, if the solicitor has a Options MAY contain Tentative Options, if the solicitor has a
Link-Layer address. Link-Layer address.
A.2. Constraints on Router Solicitations A.2. Constraints on Router Solicitations
As described in Section 6.3.7 of [RFC4861], Router Solicitations As described in Section 6.3.7 of [RFC4861], Router Solicitations
SHOULD contain Source Link-Layer Address Options. SHOULD contain Source Link-Layer Address Options.
o 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.
B.1. Legacy Neighbour Solicitation processing Appendix 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.
o An RFC 4861 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.
o 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.
o Where no neighbour cache entry exists, the recipient will send a Where no neighbour cache entry exists, the recipient will send a
multicast NS (containing its own SLLAO) in order for the original multicast NS (containing its own SLLAO) in order for the original
transmitter to respond with an NA. Upon reception of the original transmitter to respond with an NA. Upon reception of the original
transmitter's NA, an NA is sent back to the origin. transmitter's NA, an NA is sent back to the origin.
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.
o An RFC 4861 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.
o 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.
B.2. Legacy Router Solicitation processing Appendix 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.
o An RFC 4861 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.
o 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
preference. preference.
o 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.
o 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 A node can include the Tentative Option in an RS with an unspecified
source address (and no SLLAO option) when the transmitter's address source address (and no SLLAO option) when the transmitter's address
is tentative. This is described in Appendix C. is tentative. This is described in Appendix C.
o RFC 4861 routers receiving this solicitation will "see" a message RFC 2461 routers receiving this solicitation will "see" a message
without a SLLAO (such options are not allowed in RFC4861 for without a SLLAO (such options are not allowed in RFC4861 for
messages with unspecified source). messages with unspecified source).
o These routers will schedule a multicast RA response. These routers will schedule a multicast RA response.
Appendix C. Sending directed advertisements without the neighbour cache Appendix C. Sending directed advertisements without the neighbour cache
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 Tentative Option. Also, RS packets sent without a specified in the Tentative Option. Also, RS packets sent without a
specificed source address may potentially contain a Tentative Option. specificed source address may potentially contain a Tentative Option.
In this case the unicast link-layer address from the solicitation MAY In this case the unicast link-layer address from the solicitation MAY
be extracted from the Tentative Option and used as the destination of be extracted from the Tentative Option and used as the destination of
skipping to change at page 13, line 8 skipping to change at page 14, line 8
as specified in [RFC4861]. as specified in [RFC4861].
If an implementation can not send a Router Advertisement using If an implementation can not send a Router Advertisement using
information from the Tentative Option i.e, without consulting the information from the Tentative Option i.e, without consulting the
neighbour cache, then it SHOULD behave as if the Tentative Option was neighbour cache, then it SHOULD behave as if the Tentative Option was
not present in the solicitation message. not present in the solicitation message.
Authors' Addresses Authors' Addresses
Greg Daley Greg Daley
55 Pakington Street NetStar Australia Pty Ltd
Kew, Victoria 3101 Lvl 9/636 St Kilda Rd
Melbourne, Victoria 3004
Australia Australia
Phone: +61 405 494849 Phone: +61 401 772 770
Email: hoskuld@hotmail.com Email: gdaley@netstarnetworks.com
Erik Nordmark Erik Nordmark
Sun Microsystems, Inc. Sun Microsystems, Inc.
17 Network Circle 17 Network Circle
Mountain View, CA Mountain View, CA
USA USA
Phone: +1 650 786 2921 Phone: +1 650 786 2921
Fax: +1 650 786 5896
Email: erik.nordmark@sun.com Email: erik.nordmark@sun.com
Nick "Sharkey" Moore Nick "Sharkey" Moore
Email: sharkey@zoic.org Email: sharkey@zoic.org
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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 rights.
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, THE IETF TRUST 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.
Intellectual Property
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.
 End of changes. 45 change blocks. 
84 lines changed or deleted 106 lines changed or added

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