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/ |