draft-ietf-ipv6-2461bis-03.txt   draft-ietf-ipv6-2461bis-04.txt 
INTERNET-DRAFT T. Narten, INTERNET-DRAFT T. Narten,
Expires: November 2005 IBM Expires: January 2006 IBM
E. Nordmark, E. Nordmark,
Sun Microsystems Sun Microsystems
W. Simpson, W. Simpson,
Daydreamer Daydreamer
H. Soliman, H. Soliman,
Flarion Flarion
May, 2005 July, 2005
Neighbor Discovery for IP version 6 (IPv6) Neighbor Discovery for IP version 6 (IPv6)
<draft-ietf-ipv6-2461bis-03.txt> <draft-ietf-ipv6-2461bis-04.txt>
Status of this memo Status of this memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
By submitting this Internet-Draft, we accept the provisions of By submitting this Internet-Draft, we accept the provisions of
Section 4 of RFC 3667 (BCP 78). Section 4 of RFC 3667 (BCP 78).
skipping to change at page 2, line 14 skipping to change at page 2, line 14
about the paths to active neighbors. about the paths to active neighbors.
Table of Contents Table of Contents
1. INTRODUCTION....................................................4 1. INTRODUCTION....................................................4
2. TERMINOLOGY.....................................................4 2. TERMINOLOGY.....................................................4
2.1. General...................................................4 2.1. General...................................................4
2.2. Link Types................................................8 2.2. Link Types................................................8
2.3. Addresses.................................................9 2.3. Addresses.................................................9
2.4. Requirements.............................................10 2.4. Requirements..............................................9
3. PROTOCOL OVERVIEW..............................................10 3. PROTOCOL OVERVIEW..............................................10
3.1. Comparison with IPv4.....................................13 3.1. Comparison with IPv4.....................................13
3.2. Supported Link Types.....................................15 3.2. Supported Link Types.....................................15
3.3. Securing Neighbor Discovery messages......................17 3.3. Securing Neighbor Discovery messages......................17
4. MESSAGE FORMATS................................................17 4. MESSAGE FORMATS................................................17
4.1. Router Solicitation Message Format.......................17 4.1. Router Solicitation Message Format.......................17
4.2. Router Advertisement Message Format......................18 4.2. Router Advertisement Message Format......................18
4.3. Neighbor Solicitation Message Format.....................20 4.3. Neighbor Solicitation Message Format.....................20
skipping to change at page 3, line 33 skipping to change at page 3, line 33
7.3.2. Neighbor Cache Entry States.......................64 7.3.2. Neighbor Cache Entry States.......................64
7.3.3. Node Behavior.....................................65 7.3.3. Node Behavior.....................................65
8. REDIRECT FUNCTION..............................................67 8. REDIRECT FUNCTION..............................................67
8.1. Validation of Redirect Messages..........................67 8.1. Validation of Redirect Messages..........................67
8.2. Router Specification.....................................68 8.2. Router Specification.....................................68
8.3. Host Specification.......................................69 8.3. Host Specification.......................................69
9. EXTENSIBILITY - OPTION PROCESSING..............................70 9. EXTENSIBILITY - OPTION PROCESSING..............................70
10. PROTOCOL CONSTANTS............................................71 10. PROTOCOL CONSTANTS............................................72
11. SECURITY CONSIDERATIONS.......................................72 11. SECURITY CONSIDERATIONS.......................................73
11.1 Threat analysis...........................................73 11.1 Threat analysis...........................................73
11.2 Securing Neighbor Discovery messages......................74 11.2 Securing Neighbor Discovery messages......................74
12. RENUMBERING CONSIDERATIONS....................................75 12. RENUMBERING CONSIDERATIONS....................................75
REFERENCES.........................................................76 REFERENCES.........................................................76
Authors' Addresses.................................................78 Authors' Addresses.................................................78
APPENDIX A: MULTIHOMED HOSTS.......................................79 APPENDIX A: MULTIHOMED HOSTS.......................................79
skipping to change at page 8, line 23 skipping to change at page 8, line 23
broadcast) or a subset of all neighbors. broadcast) or a subset of all neighbors.
point-to-point - a link that connects exactly two interfaces. A point-to-point - a link that connects exactly two interfaces. A
point-to-point link is assumed to have multicast point-to-point link is assumed to have multicast
capability and have a link-local address. capability and have a link-local address.
non-broadcast multi-access (NBMA) non-broadcast multi-access (NBMA)
- a link to which more than two interfaces can attach, - a link to which more than two interfaces can attach,
but that does not support a native form of multicast but that does not support a native form of multicast
or broadcast (e.g., X.25, ATM, frame relay, etc.). or broadcast (e.g., X.25, ATM, frame relay, etc.).
Note that all link types (including NBMA) are Note that all link types (including NBMA) are
expected to provide multicast service for expected to provide multicast service for
applications that need it(e.g., using multicast applications that need it(e.g., using multicast
servers). However, it is an issue for further study servers). However, it is an issue for further study
whether ND should use such facilities whether ND should use such facilities or an
or an alternate mechanism that provides the alternate mechanism that provides the equivalent
equivalent multicast capability for ND. multicast capability for ND.
shared media - a link that allows direct communication among a shared media - a link that allows direct communication among a
number of nodes, but attached nodes are configured number of nodes, but attached nodes are configured
in such a way that they do not have complete prefix in such a way that they do not have complete prefix
information for all on-link destinations. That is, information for all on-link destinations. That is,
at the IP level, nodes on the same link may not know at the IP level, nodes on the same link may not know
that they are neighbors; by default, they that they are neighbors; by default, they
communicate through a router. Examples are large communicate through a router. Examples are large
(switched) public data networks such as SMDS and B- (switched) public data networks such as SMDS and B-
ISDN. Also known as "large clouds". See [SH- ISDN. Also known as "large clouds". See [SH-
skipping to change at page 26, line 14 skipping to change at page 26, line 13
be included (if known). Note that on NBMA links, be included (if known). Note that on NBMA links,
hosts may rely on the presence of the Target Link- hosts may rely on the presence of the Target Link-
Layer Address option in Redirect messages as the Layer Address option in Redirect messages as the
means for determining the link-layer addresses of means for determining the link-layer addresses of
neighbors. In such cases, the option MUST be neighbors. In such cases, the option MUST be
included in Redirect messages. included in Redirect messages.
Redirected Header Redirected Header
As much as possible of the IP packet that triggered As much as possible of the IP packet that triggered
the sending of the Redirect without making the the sending of the Redirect without making the
redirect packet exceed 1280 octets. redirect packet exceed the minimum MTU specified in
[IPv6].
4.6. Option Formats 4.6. Option Formats
Neighbor Discovery messages include zero or more options, some of Neighbor Discovery messages include zero or more options, some of
which may appear multiple times in the same message. Options should which may appear multiple times in the same message. Options should
be padded when necessary to ensure that they end on their natural 64- be padded when necessary to ensure that they end on their natural 64-
bit boundaries. All options are of the form: bit boundaries. All options are of the form:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 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 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 28, line 25 skipping to change at page 28, line 26
Type 3 Type 3
Length 4 Length 4
Prefix Length 8-bit unsigned integer. The number of leading bits Prefix Length 8-bit unsigned integer. The number of leading bits
in the Prefix that are valid. The value ranges in the Prefix that are valid. The value ranges
from 0 to 128. The prefix length field provides from 0 to 128. The prefix length field provides
necessary information for on-link determination necessary information for on-link determination
(when combined with the L flag in the prefix (when combined with the L flag in the prefix
option). It also assists with address information option). It also assists with address
autoconfiguration as specified in [ADDRCONF], for autoconfiguration as specified in [ADDRCONF], for
which there may be more restrictions on the prefix which there may be more restrictions on the prefix
length. length.
L 1-bit on-link flag. When set, indicates that this L 1-bit on-link flag. When set, indicates that this
prefix can be used for on-link determination. When prefix can be used for on-link determination. When
not set the advertisement makes no statement about not set the advertisement makes no statement about
on-link or off-link properties of the prefix. For on-link or off-link properties of the prefix. For
instance, the prefix might be used for address instance, the prefix might be used for address
configuration with some of the addresses belonging configuration with some of the addresses belonging
skipping to change at page 30, line 12 skipping to change at page 30, line 12
Type 4 Type 4
Length The length of the option in units of 8 octets. Length The length of the option in units of 8 octets.
Reserved These fields are unused. They MUST be initialized Reserved These fields are unused. They MUST be initialized
to zero by the sender and MUST be ignored by the to zero by the sender and MUST be ignored by the
receiver. receiver.
IP header + data IP header + data
The original packet truncated to ensure that the The original packet truncated to ensure that the
size of the redirect message does not exceed 1280 size of the redirect message does not exceed the
octets. minimum MTU required to support IPv6 as specified
in [IPv6].
Description Description
The Redirected Header option is used in Redirect The Redirected Header option is used in Redirect
messages and contains all or part of the packet messages and contains all or part of the packet
that is being redirected. that is being redirected.
This option MUST be silently ignored for other This option MUST be silently ignored for other
Neighbor Discovery messages. Neighbor Discovery messages.
4.6.4. MTU 4.6.4. MTU
skipping to change at page 56, line 21 skipping to change at page 56, line 27
When a multicast-capable interface becomes enabled the node MUST join When a multicast-capable interface becomes enabled the node MUST join
the all-nodes multicast address on that interface, as well as the the all-nodes multicast address on that interface, as well as the
solicited-node multicast address corresponding to each of the IP solicited-node multicast address corresponding to each of the IP
addresses assigned to the interface. addresses assigned to the interface.
The set of addresses assigned to an interface may change over time. The set of addresses assigned to an interface may change over time.
New addresses might be added and old addresses might be removed New addresses might be added and old addresses might be removed
[ADDRCONF]. In such cases the node MUST join and leave the [ADDRCONF]. In such cases the node MUST join and leave the
solicited-node multicast address corresponding to the new and old solicited-node multicast address corresponding to the new and old
addresses, respectively. Joining the solicited-node multicast address addresses, respectively. Joining the solicited-node multicast address
SHOULD be done using the Multicast Listener Discovery [MLD] protocol. SHOULD be done using the Multicast Listener Discovery [MLD] or
Note that multiple unicast addresses may map into the same solicited- [MLDv2] protocols. Note that multiple unicast addresses may map into
node multicast address; a node MUST NOT leave the solicited-node the same solicited-node multicast address; a node MUST NOT leave the
multicast group until all assigned addresses corresponding to that solicited-node multicast group until all assigned addresses
multicast address have been removed. corresponding to that multicast address have been removed.
7.2.2. Sending Neighbor Solicitations 7.2.2. Sending Neighbor Solicitations
When a node has a unicast packet to send to a neighbor, but does not When a node has a unicast packet to send to a neighbor, but does not
know the neighbor's link-layer address, it performs address know the neighbor's link-layer address, it performs address
resolution. For multicast-capable interfaces this entails creating a resolution. For multicast-capable interfaces this entails creating a
Neighbor Cache entry in the INCOMPLETE state and transmitting a Neighbor Cache entry in the INCOMPLETE state and transmitting a
Neighbor Solicitation message targeted at the neighbor. The Neighbor Solicitation message targeted at the neighbor. The
solicitation is sent to the solicited-node multicast address solicitation is sent to the solicited-node multicast address
corresponding to the target address. corresponding to the target address.
skipping to change at page 59, line 25 skipping to change at page 59, line 31
If no entry exists, the advertisement SHOULD be silently discarded. If no entry exists, the advertisement SHOULD be silently discarded.
There is no need to create an entry if none exists, since the There is no need to create an entry if none exists, since the
recipient has apparently not initiated any communication with the recipient has apparently not initiated any communication with the
target. target.
Once the appropriate Neighbor Cache entry has been located, the Once the appropriate Neighbor Cache entry has been located, the
specific actions taken depend on the state of the Neighbor Cache specific actions taken depend on the state of the Neighbor Cache
entry, the flags in the advertisement and the actual link-layer entry, the flags in the advertisement and the actual link-layer
address supplied. address supplied.
In any state, if the link layer has addresses and an unsolicited
Neighbor Advertisement is received with the O flag cleared, with no
Target Link-Layer address option included, the receiving node SHOULD
silently discard the received advertisement.
If the target's Neighbor Cache entry is in the INCOMPLETE state when If the target's Neighbor Cache entry is in the INCOMPLETE state when
the advertisement is received, one of two things happen: If the the advertisement is received, one of two things happens. If the
advertisement were solicited, the state is changed to REACHABLE. link layer has addresses and no Target Link-Layer address option is
Otherwise, the state is set to STALE. Note that the Override flag is included, the receiving node SHOULD silently discard the received
ignored if the entry is in the advertisement. Otherwise, the receiving node performs the following
INCOMPLETE state. steps:
If the Neighbor Cache entry is in INCOMPLETE state, the receiving
node performs the following steps:
- It records the link-layer address in the Neighbor Cache entry. - It records the link-layer address in the Neighbor Cache entry.
- If the advertisement's Solicited flag is set, the state of the - If the advertisement's Solicited flag is set, the state of the
entry is set to REACHABLE, otherwise it is set to STALE. entry is set to REACHABLE, otherwise it is set to STALE.
- It sets the IsRouter flag in the cache entry based on the Router - It sets the IsRouter flag in the cache entry based on the Router
flag in the received advertisement. flag in the received advertisement.
- It sends any packets queued for the neighbor awaiting address - It sends any packets queued for the neighbor awaiting address
resolution. resolution.
Note that the Override flag is ignored if the entry is in the
INCOMPLETE state.
If the target's Neighbor Cache entry is in any state other than If the target's Neighbor Cache entry is in any state other than
INCOMPLETE when the advertisement is received, the following actions INCOMPLETE when the advertisement is received, the following actions
take place: take place:
I. If the Override flag is clear and the supplied link-layer address I. If the Override flag is clear and the supplied link-layer address
differs from that in the cache, then one of two actions takes differs from that in the cache, then one of two actions takes
place: place:
a. If the state of the entry is REACHABLE, set it to STALE, but a. If the state of the entry is REACHABLE, set it to STALE, but
do not update the entry in any other way. do not update the entry in any other way.
b. Otherwise, the received advertisement should be ignored and MUST b. Otherwise, the received advertisement should be ignored and
NOT update the cache. MUST NOT update the cache.
II. If the Override flag is set, or the supplied Override flag is
Clear, or the supplied link-layer address is the same as that in II. If the Override flag is set, or the supplied link-layer address
the cache, or no Target Link-layer address option was supplied, is the same as that in the cache, or no Target Link-layer address
the received advertisement MUST update the Neighbor Cache entry option was supplied, the received advertisement MUST update the
as follows: Neighbor Cache entry as follows:
- The link-layer address in the Target Link-Layer Address option - The link-layer address in the Target Link-Layer Address option
MUST be inserted in the cache (if one is supplied and is different MUST be inserted in the cache (if one is supplied and is
than the already recorded address). Different than the already recorded address).
- If the Solicited flag is set, the state of the entry MUST be set - If the Solicited flag is set, the state of the entry MUST be
to REACHABLE. If the Solicited flag is zero and the link-layer set to REACHABLE. If the Solicited flag is zero and the link
address was updated with a different address the state MUST be set layer address was updated with a different address the state
to STALE. Otherwise, the entry's state remains unchanged. MUST be set to STALE. Otherwise, the entry's state remains
unchanged.
An advertisement's Solicited flag should only be set if the An advertisement's Solicited flag should only be set if the
advertisement is a response to a Neighbor Solicitation. Because advertisement is a response to a Neighbor Solicitation.
Neighbor Unreachability Detection Solicitations are sent to the Because Neighbor Unreachability Detection Solicitations are
cached link-layer address, receipt of a solicited advertisement sent to the cached link-layer address, receipt of a solicited
indicates that the forward path is working. Receipt of an advertisement indicates that the forward path is working.
unsolicited advertisement, however, suggests that a neighbor has Receipt of an unsolicited advertisement, however, suggests that
urgent information to announce (e.g., a changed link-layer a neighbor has urgent information to announce (e.g., a changed
address). If the urgent information indicates a change from what link-layer address). If the urgent information indicates a
a node is currently using, the node should verify the reachability change from what a node is currently using, the node should
of the (new) path when it sends the next packet. There is no need verify the reachability of the (new) path when it sends the
to update the state for unsolicited advertisements that do not next packet. There is no need to update the state for
change the contents of the cache. unsolicited advertisements that do not change the contents of
the cache.
- The IsRouter flag in the cache entry MUST be set based on the - The IsRouter flag in the cache entry MUST be set based on the
Router flag in the received advertisement. In those cases where Router flag in the received advertisement. In those cases
the IsRouter flag changes from TRUE to FALSE as a result of this where the IsRouter flag changes from TRUE to FALSE as a result
update, the node MUST remove that router from the Default Router of this update, the node MUST remove that router from the
List and update the Destination Cache entries for all destinations Default Router List and update the Destination Cache entries
using that neighbor as a router as specified in Section 7.3.3. for all destinations using that neighbor as a router as
This is needed to detect when a node that is used as a router specified in Section 7.3.3. This is needed to detect when a
stops forwarding packets due to being configured as a host. node that is used as a router stops forwarding packets due to
being configured as a host.
The above rules ensure that the cache is updated either when the The above rules ensure that the cache is updated either when the
Neighbor Advertisement takes precedence (i.e., the Override flag is Neighbor Advertisement takes precedence (i.e., the Override flag is
set) or when the Neighbor Advertisement refers to the same link-layer set) or when the Neighbor Advertisement refers to the same link-layer
address that is currently recorded in the cache. If none of the address that is currently recorded in the cache. If none of the
above apply, the advertisement prompts future Neighbor Unreachability above apply, the advertisement prompts future Neighbor Unreachability
Detection (if it is not already in progress) by changing the state in Detection (if it is not already in progress) by changing the state in
the cache entry. the cache entry.
7.2.6. Sending Unsolicited Neighbor Advertisements 7.2.6. Sending Unsolicited Neighbor Advertisements
skipping to change at page 62, line 41 skipping to change at page 62, line 44
Under limited circumstances, a router MAY proxy for one or more other Under limited circumstances, a router MAY proxy for one or more other
nodes, that is, through Neighbor Advertisements indicate that it is nodes, that is, through Neighbor Advertisements indicate that it is
willing to accept packets not explicitly addressed to itself. For willing to accept packets not explicitly addressed to itself. For
example, a router might accept packets on behalf of a mobile node example, a router might accept packets on behalf of a mobile node
that has moved off-link. The mechanisms used by proxy are identical that has moved off-link. The mechanisms used by proxy are identical
to the mechanisms used with anycast addresses. to the mechanisms used with anycast addresses.
A proxy MUST join the solicited-node multicast address(es) that A proxy MUST join the solicited-node multicast address(es) that
correspond to the IP address(es) assigned to the node for which it is correspond to the IP address(es) assigned to the node for which it is
proxying. This SHOULD be done using [MLD]. proxying. This SHOULD be done using [MLD] or [MLDv2].
All solicited proxy Neighbor Advertisement messages MUST have the All solicited proxy Neighbor Advertisement messages MUST have the
Override flag set to zero. This ensures that if the node itself is Override flag set to zero. This ensures that if the node itself is
present on the link its Neighbor Advertisement (with the Override present on the link its Neighbor Advertisement (with the Override
flag set to one) will take precedence of any advertisement received flag set to one) will take precedence of any advertisement received
from a proxy. A proxy MAY send unsolicited advertisements with the from a proxy. A proxy MAY send unsolicited advertisements with the
Override flag set to one as specified in Section 7.2.6, but doing so Override flag set to one as specified in Section 7.2.6, but doing so
may cause the proxy advertisement to override a valid entry created may cause the proxy advertisement to override a valid entry created
by the node itself. by the node itself.
skipping to change at page 69, line 28 skipping to change at page 69, line 30
- In the Destination Address field: the destination address of the - In the Destination Address field: the destination address of the
invoking IP packet. invoking IP packet.
- In the options: - In the options:
o Target Link-Layer Address option: link-layer address of the o Target Link-Layer Address option: link-layer address of the
target, if known. target, if known.
o Redirected Header: as much of the forwarded packet as can o Redirected Header: as much of the forwarded packet as can
fit without the redirect packet exceeding 1280 octets in fit without the redirect packet exceeding the minimum MTU
size. required to support IPv6 as specified in [IPv6].
A router MUST limit the rate at which Redirect messages are sent, in A router MUST limit the rate at which Redirect messages are sent, in
order to limit the bandwidth and processing costs incurred by the order to limit the bandwidth and processing costs incurred by the
Redirect messages when the source does not correctly respond to the Redirect messages when the source does not correctly respond to the
Redirects, or the source chooses to ignore unauthenticated Redirect Redirects, or the source chooses to ignore unauthenticated Redirect
messages. More details on the rate-limiting of ICMP error messages messages. More details on the rate-limiting of ICMP error messages
can be found in [ICMPv6]. can be found in [ICMPv6].
A router MUST NOT update its routing tables upon receipt of a A router MUST NOT update its routing tables upon receipt of a
Redirect. Redirect.
skipping to change at page 71, line 32 skipping to change at page 71, line 36
receivers MUST be prepared to process them independently of their receivers MUST be prepared to process them independently of their
order. There can also be multiple instances of the same option in a order. There can also be multiple instances of the same option in a
message (e.g., Prefix Information options). message (e.g., Prefix Information options).
If the number of included options in a Router Advertisement causes If the number of included options in a Router Advertisement causes
the advertisement's size to exceed the link MTU, the router can send the advertisement's size to exceed the link MTU, the router can send
multiple separate advertisements each containing a subset of the multiple separate advertisements each containing a subset of the
options. options.
The amount of data to include in the Redirected Header option MUST be The amount of data to include in the Redirected Header option MUST be
limited so that the entire redirect packet does not exceed 1280 limited so that the entire redirect packet does not exceed the
octets. minimum MTU required to support IPv6 as specified in [IPv6].
All options are a multiple of 8 octets of length, ensuring All options are a multiple of 8 octets of length, ensuring
appropriate alignment without any "pad" options. The fields in the appropriate alignment without any "pad" options. The fields in the
options (as well as the fields in ND packets) are defined to align on options (as well as the fields in ND packets) are defined to align on
their natural boundaries (e.g., a 16-bit field is aligned on a 16-bit their natural boundaries (e.g., a 16-bit field is aligned on a 16-bit
boundary) with the exception of the 128-bit IP addresses/prefixes, boundary) with the exception of the 128-bit IP addresses/prefixes,
which are aligned on a 64-bit boundary. The link-layer address field which are aligned on a 64-bit boundary. The link-layer address field
contains an uninterpreted octet string; it is aligned on an 8-bit contains an uninterpreted octet string; it is aligned on an 8-bit
boundary. boundary.
The size of an ND packet including the IP header is limited to the The size of an ND packet including the IP header is limited to the
link MTU (which is at least 1280 octets). When adding options to an link MTU. When adding options to an ND packet a node MUST NOT exceed
ND packet a node MUST NOT exceed the link MTU. the link MTU.
Future versions of this protocol may define new option types. Future versions of this protocol may define new option types.
Receivers MUST silently ignore any options they do not recognize and Receivers MUST silently ignore any options they do not recognize and
continue processing the message. continue processing the message.
10. PROTOCOL CONSTANTS 10. PROTOCOL CONSTANTS
Router constants: Router constants:
MAX_INITIAL_RTR_ADVERT_INTERVAL 16 seconds MAX_INITIAL_RTR_ADVERT_INTERVAL 16 seconds
skipping to change at page 78, line 8 skipping to change at page 78, line 11
[IPv6-ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security [IPv6-ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998. Payload (ESP)", RFC 2406, November 1998.
[MIPv6] D. Johnson, C. Perkins and J. Arkko, "Mobility Support [MIPv6] D. Johnson, C. Perkins and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[MLD] Deering, S., Fenner, W, and B. Haberman, "Multicast [MLD] Deering, S., Fenner, W, and B. Haberman, "Multicast
Listener Discovery for IPv6", RFC 2710, October 1999. Listener Discovery for IPv6", RFC 2710, October 1999.
[MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[NDMAN] Arkko, J., "Manual Configuration of Security [NDMAN] Arkko, J., "Manual Configuration of Security
Associations for IPv6 Neighbor Discovery", draft-arkko- Associations for IPv6 Neighbor Discovery", draft-arkko-
manual-icmpv6-sas-02 (work in progress), March 2003. manual-icmpv6-sas-02 (work in progress), March 2003.
[RDISC] Deering, S., "ICMP Router Discovery Messages", RFC 1256, [RDISC] Deering, S., "ICMP Router Discovery Messages", RFC 1256,
September 1991. September 1991.
[RTSEL] Draves, R. and D. Thaler, "Default Router Preferences
and more Specific Routes", draft-ietf-ipv6-router-
selection-07, (work in progress), January 2005.
[SH-MEDIA] Braden, R., Postel, J. and Y. Rekhter, "Internet [SH-MEDIA] Braden, R., Postel, J. and Y. Rekhter, "Internet
Architecture Extensions for Shared Media", RFC 1620, May Architecture Extensions for Shared Media", RFC 1620, May
1994. 1994.
[SEND] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. [SEND] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P.
Nikander, "SEcure Neighbor Discovery (SEND)", Nikander, "SEcure Neighbor Discovery (SEND)",
draft-ietf-send-ndopt-04 (work in progress), draft-ietf-send-ndopt-04 (work in progress),
February 2004. February 2004.
[SYNC] S. Floyd, V. Jacobson, "The Synchronization of Periodic [SYNC] S. Floyd, V. Jacobson, "The Synchronization of Periodic
skipping to change at page 79, line 29 skipping to change at page 79, line 37
Email: H.Soliman@flarion.com Email: H.Soliman@flarion.com
APPENDIX A: MULTIHOMED HOSTS APPENDIX A: MULTIHOMED HOSTS
There are a number of complicating issues that arise when Neighbor There are a number of complicating issues that arise when Neighbor
Discovery is used by hosts that have multiple interfaces. This Discovery is used by hosts that have multiple interfaces. This
section does not attempt to define the proper operation of multihomed section does not attempt to define the proper operation of multihomed
hosts with regard to Neighbor Discovery. Rather, it identifies hosts with regard to Neighbor Discovery. Rather, it identifies
issues that require further study. Implementors are encouraged to issues that require further study. Implementors are encouraged to
experiment with various approaches to making Neighbor Discovery work experiment with various approaches to making Neighbor Discovery work
on multihomed hosts and to report their experiences. on multihomed hosts and to report their experiences. Further work
related to this problem can be found in [RTSEL].
If a multihomed host receives Router Advertisements on all of its If a multihomed host receives Router Advertisements on all of its
interfaces, it will (probably) have learned on-link prefixes for the interfaces, it will (probably) have learned on-link prefixes for the
addresses residing on each link. When a packet must be sent through addresses residing on each link. When a packet must be sent through
a router, however, selecting the "wrong" router can result in a a router, however, selecting the "wrong" router can result in a
suboptimal or non-functioning path. There are number of issues to suboptimal or non-functioning path. There are number of issues to
consider: consider:
1) In order for a router to send a redirect, it must determine that 1) In order for a router to send a redirect, it must determine that
the packet it is forwarding originates from a neighbor. The the packet it is forwarding originates from a neighbor. The
skipping to change at page 80, line 18 skipping to change at page 80, line 28
case. case.
3) Even if the first-hop router does have a route for a 3) Even if the first-hop router does have a route for a
destination, there may be a better route via another interface. destination, there may be a better route via another interface.
No mechanism exists for the multihomed host to detect this No mechanism exists for the multihomed host to detect this
situation. situation.
If a multihomed host fails to receive Router Advertisements on one or If a multihomed host fails to receive Router Advertisements on one or
more of its interfaces, it will not know (in the absence of more of its interfaces, it will not know (in the absence of
configured information) which destinations are on-link on the configured information) which destinations are on-link on the
affected interface(s). This leads to a number of problems: affected interface(s). This leads to the following problem: If Router
Advertisements are received on some, but not all interfaces, a
1) If no Router Advertisement is received on any interfaces, a multihomed host could choose to only send packets out on the
multihomed host will have no way of knowing which interface to interfaces on which it has received Router Advertisements. A key
send packets out on, even for on-link destinations. assumption made here, however, is that routers on those other
One possible approach for a multihomed node would be to attempt interfaces will be able to route packets to the ultimate destination,
to perform address resolution on all interfaces, a step even when those destinations reside on the subnet to which the sender
involving significant complexity. connects, but has no on-link prefix information. Should the
assumption be FALSE, communication would fail. Even if the assumption
2) If Router Advertisements are received on some, but not all holds, packets will traverse a sub-optimal path.
interfaces, a multihomed host could choose to only send packets
out on the interfaces on which it has received Router
Advertisements. A key assumption made here, however, is that
routers on those other interfaces will be able to route packets
to the ultimate destination, even when those destinations reside
on the subnet to which the sender connects, but has no on-link
prefix information. Should the assumption be FALSE,
communication would fail. Even if the assumption holds, packets
will traverse a sub-optimal path.
APPENDIX B: FUTURE EXTENSIONS APPENDIX B: FUTURE EXTENSIONS
Possible extensions for future study are: Possible extensions for future study are:
o Using dynamic timers to be able to adapt to links with widely o Using dynamic timers to be able to adapt to links with widely
varying delay. Measuring round trip times, however, requires varying delay. Measuring round trip times, however, requires
acknowledgments and sequence numbers in order to match received acknowledgments and sequence numbers in order to match received
Neighbor Advertisements with the actual Neighbor Solicitation that Neighbor Advertisements with the actual Neighbor Solicitation that
triggered the advertisement. Implementors wishing to experiment triggered the advertisement. Implementors wishing to experiment
skipping to change at page 81, line 43 skipping to change at page 81, line 45
retransmissions. retransmissions.
INCOMPLETE NA, Solicited=0, Record link-layer STALE INCOMPLETE NA, Solicited=0, Record link-layer STALE
Override=any address. Send queued Override=any address. Send queued
packets. packets.
INCOMPLETE NA, Solicited=1, Record link-layer REACHABLE INCOMPLETE NA, Solicited=1, Record link-layer REACHABLE
Override=any address. Send queued Override=any address. Send queued
packets. packets.
INCOMPLETE NA, Solicited=any, Retransmit NS unchanged
Override=any, No Start retransmit
Link-layer address timer
!INCOMPLETE NA, Solicited=1, - REACHABLE !INCOMPLETE NA, Solicited=1, - REACHABLE
Override=0 Override=0
Same link-layer Same link-layer
address as cached. address as cached.
!INCOMPLETE NA, Solicited=any, Update content of unchanged
Override=any, No IsRouter flag.
link-layer address
REACHABLE NA, Solicited=1, - STALE REACHABLE NA, Solicited=1, - STALE
Override=0 Override=0
Different link-layer Different link-layer
address than cached. address than cached.
STALE, PROBE NA, Solicited=1, - unchanged STALE, PROBE NA, Solicited=1, - unchanged
Or DELAY Override=0 Or DELAY Override=0
Different link-layer Different link-layer
address than cached. address than cached.
skipping to change at page 83, line 11 skipping to change at page 83, line 21
- NS, RS, RA, Redirect Create entry. STALE - NS, RS, RA, Redirect Create entry. STALE
INCOMPLETE NS, RS, RA, Redirect Record link-layer STALE INCOMPLETE NS, RS, RA, Redirect Record link-layer STALE
address. Send queued address. Send queued
packets. packets.
!INCOMPLETE NS, RS, RA, Redirect Update link-layer STALE !INCOMPLETE NS, RS, RA, Redirect Update link-layer STALE
Different link-layer address Different link-layer address
address than cached. address than cached.
INCOMPLETE NS, RS No link-layer - unchanged
address
!INCOMPLETE NS, RS, RA, Redirect - unchanged !INCOMPLETE NS, RS, RA, Redirect - unchanged
Same link-layer Same link-layer
address as cached. address as cached.
APPENDIX D: SUMMARY OF ISROUTER RULES APPENDIX D: SUMMARY OF ISROUTER RULES
This appendix presents a summary of the rules for maintaining the This appendix presents a summary of the rules for maintaining the
IsRouter flag as specified in this document. IsRouter flag as specified in this document.
The background for these rules is that the ND messages contain, The background for these rules is that the ND messages contain,
skipping to change at page 87, line 15 skipping to change at page 87, line 27
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This Internet-Draft expires November, 2005. This Internet-Draft expires January, 2006.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/