draft-ietf-ipv6-2461bis-00.txt   draft-ietf-ipv6-2461bis-01.txt 
INTERNET-DRAFT T. Narten, INTERNET-DRAFT T. Narten,
Expires: January 2005 IBM Expires: April 2005 IBM
E. Nordmark, E. Nordmark,
Sun Microsystems Sun Microsystems
W. Simpson, W. Simpson,
Daydreamer Daydreamer
H. Soliman, H. Soliman,
Flarion Flarion
July, 2004 October, 2004
Neighbor Discovery for IP version 6 (IPv6) Neighbor Discovery for IP version 6 (IPv6)
<draft-ietf-ipv6-2461bis-00.txt> <draft-ietf-ipv6-2461bis-01.txt>
Status of this memo Status of this memo
By submitting this Internet-Draft, we certify that any applicable By submitting this Internet-Draft, we certify that any applicable
patent or other IPR claims of which we are aware have been disclosed, patent or other IPR claims of which we are aware have been disclosed,
and any of which we become aware will be disclosed, in accordance and any of which we become aware will be disclosed, in accordance
with RFC 3668 (BCP 79). with RFC 3668 (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..............................................9 2.4. Requirements.............................................10
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......................16 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
4.4. Neighbor Advertisement Message Format....................21 4.4. Neighbor Advertisement Message Format....................22
4.5. Redirect Message Format..................................24 4.5. Redirect Message Format..................................24
4.6. Option Formats...........................................25 4.6. Option Formats...........................................26
4.6.2. Prefix Information.................................27 4.6.2. Prefix Information.................................27
4.6.3. Redirected Header..................................29 4.6.3. Redirected Header..................................29
4.6.4. MTU................................................30 4.6.4. MTU................................................30
5. CONCEPTUAL MODEL OF A HOST.....................................30 5. CONCEPTUAL MODEL OF A HOST.....................................31
5.1. Conceptual Data Structures...............................31 5.1. Conceptual Data Structures...............................31
5.2. Conceptual Sending Algorithm.............................33 5.2. Conceptual Sending Algorithm.............................33
5.3. Garbage Collection and Timeout Requirements..............34 5.3. Garbage Collection and Timeout Requirements..............34
6. ROUTER AND PREFIX DISCOVERY....................................35 6. ROUTER AND PREFIX DISCOVERY....................................35
6.1. Message Validation.......................................35 6.1. Message Validation.......................................36
6.1.1. Validation of Router Solicitation Messages.........35 6.1.1. Validation of Router Solicitation Messages.........36
6.1.2. Validation of Router Advertisement Messages........36 6.1.2. Validation of Router Advertisement Messages........36
6.2. Router Specification.....................................37 6.2. Router Specification.....................................37
6.2.1. Router Configuration Variables....................37 6.2.1. Router Configuration Variables....................37
6.2.2. Becoming An Advertising Interface.................41 6.2.2. Becoming An Advertising Interface.................41
6.2.3. Router Advertisement Message Content..............41 6.2.3. Router Advertisement Message Content..............41
6.2.4. Sending Unsolicited Router Advertisements.........43 6.2.4. Sending Unsolicited Router Advertisements.........43
6.2.5. Ceasing To Be An Advertising Interface............43 6.2.5. Ceasing To Be An Advertising Interface............43
6.2.6. Processing Router Solicitations...................44 6.2.6. Processing Router Solicitations...................44
6.2.7. Router Advertisement Consistency..................45 6.2.7. Router Advertisement Consistency..................45
6.2.8. Link-local Address Change.........................46 6.2.8. Link-local Address Change.........................46
6.3. Host Specification.......................................46 6.3. Host Specification.......................................46
6.3.1. Host Configuration Variables......................46 6.3.1. Host Configuration Variables......................47
6.3.2. Host Variables....................................46 6.3.2. Host Variables....................................47
6.3.3. Interface Initialization..........................48 6.3.3. Interface Initialization..........................48
6.3.4. Processing Received Router Advertisements.........48 6.3.4. Processing Received Router Advertisements.........48
6.3.5. Timing out Prefixes and Default Routers...........51 6.3.5. Timing out Prefixes and Default Routers...........51
6.3.6. Default Router Selection..........................51 6.3.6. Default Router Selection..........................51
6.3.7. Sending Router Solicitations......................52 6.3.7. Sending Router Solicitations......................52
7. ADDRESS RESOLUTION AND NEIGHBOR UNREACHABILITY DETECTION.......53 7. ADDRESS RESOLUTION AND NEIGHBOR UNREACHABILITY DETECTION.......53
7.1. Message Validation.......................................53 7.1. Message Validation.......................................54
7.1.1. Validation of Neighbor Solicitations..............53 7.1.1. Validation of Neighbor Solicitations..............54
7.1.2. Validation of Neighbor Advertisements.............54 7.1.2. Validation of Neighbor Advertisements.............54
7.2. Address Resolution.......................................55 7.2. Address Resolution.......................................55
7.2.1. Interface Initialization..........................55 7.2.1. Interface Initialization..........................55
7.2.2. Sending Neighbor Solicitations....................55 7.2.2. Sending Neighbor Solicitations....................55
7.2.3. Receipt of Neighbor Solicitations.................56 7.2.3. Receipt of Neighbor Solicitations.................56
7.2.4. Sending Solicited Neighbor Advertisements.........57 7.2.4. Sending Solicited Neighbor Advertisements.........57
7.2.5. Receipt of Neighbor Advertisements................58 7.2.5. Receipt of Neighbor Advertisements................58
7.2.6. Sending Unsolicited Neighbor Advertisements.......60 7.2.6. Sending Unsolicited Neighbor Advertisements.......60
7.2.7. Anycast Neighbor Advertisements...................61 7.2.7. Anycast Neighbor Advertisements...................61
7.2.8. Proxy Neighbor Advertisements.....................61 7.2.8. Proxy Neighbor Advertisements.....................61
7.3. Neighbor Unreachability Detection........................62 7.3. Neighbor Unreachability Detection........................62
7.3.1. Reachability Confirmation.........................62 7.3.1. Reachability Confirmation.........................62
7.3.2. Neighbor Cache Entry States.......................63 7.3.2. Neighbor Cache Entry States.......................63
7.3.3. Node Behavior.....................................64 7.3.3. Node Behavior.....................................64
8. REDIRECT FUNCTION..............................................66 8. REDIRECT FUNCTION..............................................66
8.1. Validation of Redirect Messages..........................66 8.1. Validation of Redirect Messages..........................67
8.2. Router Specification.....................................67 8.2. Router Specification.....................................68
8.3. Host Specification.......................................68 8.3. Host Specification.......................................69
9. EXTENSIBILITY - OPTION PROCESSING..............................69 9. EXTENSIBILITY - OPTION PROCESSING..............................69
10. PROTOCOL CONSTANTS............................................71 10. PROTOCOL CONSTANTS............................................71
11. SECURITY CONSIDERATIONS.......................................72 11. SECURITY CONSIDERATIONS.......................................72
11.1 Threat analysis...........................................72 11.1 Threat analysis...........................................72
11.2 Securing Neighbor Discovery messages......................73 11.2 Securing Neighbor Discovery messages......................73
12. RENUMBERING CONSIDERATIONS....................................74 12. RENUMBERING CONSIDERATIONS....................................74
REFERENCES.........................................................75 REFERENCES.........................................................75
Authors' Addresses.................................................77 Authors' Addresses.................................................77
APPENDIX A: MULTIHOMED HOSTS.......................................77 APPENDIX A: MULTIHOMED HOSTS.......................................78
APPENDIX B: FUTURE EXTENSIONS......................................79 APPENDIX B: FUTURE EXTENSIONS......................................79
APPENDIX C: STATE MACHINE FOR THE REACHABILITY STATE...............79 APPENDIX C: STATE MACHINE FOR THE REACHABILITY STATE...............80
APPENDIX D: SUMMARY OF ISROUTER RULES..............................81 APPENDIX D: SUMMARY OF ISROUTER RULES..............................82
APPENDIX E: IMPLEMENTATION ISSUES..................................82 APPENDIX E: IMPLEMENTATION ISSUES..................................83
Appendix E.1: Reachability confirmations...........................82 Appendix E.1: Reachability confirmations...........................83
APPENDIX F: CHANGES FROM RFC 2461..................................84 APPENDIX F: CHANGES FROM RFC 2461..................................84
Full Copyright Statement...........................................84 Full Copyright Statement.................Error! Bookmark not defined.
1. INTRODUCTION 1. INTRODUCTION
This specification defines the Neighbor Discovery (ND) protocol for This specification defines the Neighbor Discovery (ND) protocol for
Internet Protocol Version 6 (IPv6). Nodes (hosts and routers) use Internet Protocol Version 6 (IPv6). Nodes (hosts and routers) use
Neighbor Discovery to determine the link-layer addresses for Neighbor Discovery to determine the link-layer addresses for
neighbors known to reside on attached links and to quickly purge neighbors known to reside on attached links and to quickly purge
cached values that become invalid. Hosts also use Neighbor Discovery cached values that become invalid. Hosts also use Neighbor Discovery
to find neighboring routers that are willing to forward packets on to find neighboring routers that are willing to forward packets on
their behalf. Finally, nodes use the protocol to actively keep track their behalf. Finally, nodes use the protocol to actively keep track
skipping to change at page 4, line 35 skipping to change at page 4, line 35
document that are not directly dependent on multicast, such as document that are not directly dependent on multicast, such as
Redirects, Next-hop determination, Neighbor Unreachability Detection, Redirects, Next-hop determination, Neighbor Unreachability Detection,
etc., are expected to be provided as specified in this document. The etc., are expected to be provided as specified in this document. The
details of how one uses ND on NBMA links are addressed in [IPv6- details of how one uses ND on NBMA links are addressed in [IPv6-
NBMA]. In addition, [IPv6-3GPP] and [IPv6-CELLULAR] discuss the use NBMA]. In addition, [IPv6-3GPP] and [IPv6-CELLULAR] discuss the use
of this protocol over some cellular links, which are examples of NBMA of this protocol over some cellular links, which are examples of NBMA
links. links.
The authors would like to acknowledge the contributions of the IPv6 The authors would like to acknowledge the contributions of the IPv6
working group and, in particular, (in alphabetical order) Ran working group and, in particular, (in alphabetical order) Ran
Atkinson, Jim Bound, Scott Bradner, Alex Conta, Stephen Deering Atkinson, Jim Bound, Scott Bradner, Alex Conta, Elwyn Davies, Stephen
Richard Draves, Francis Dupont, Robert Elz, Robert Gilligan, Robert Deering Richard Draves, Francis Dupont, Robert Elz, Robert Gilligan,
Hinden, Allison Mankin, Dan McDonald, Charles Perkins, Matt Thomas, Robert Hinden, Allison Mankin, Dan McDonald, Charles Perkins, Matt
and Susan Thomson. Thomas, and Susan Thomson.
2. TERMINOLOGY 2. TERMINOLOGY
2.1. General 2.1. General
IP - Internet Protocol Version 6. The terms IPv4 and IP - Internet Protocol Version 6. The terms IPv4 and
IPv6 are used only in contexts where necessary to avoid IPv6 are used only in contexts where necessary to avoid
ambiguity. ambiguity.
ICMP - Internet Message Control Protocol for the Internet ICMP - Internet Message Control Protocol for the Internet
skipping to change at page 7, line 39 skipping to change at page 7, line 39
exactly the same time, or to prevent long-range exactly the same time, or to prevent long-range
periodic transmissions from synchronizing with each periodic transmissions from synchronizing with each
other [SYNC]. When a random component is required, a other [SYNC]. When a random component is required, a
node calculates the actual delay in such a way that the node calculates the actual delay in such a way that the
computed delay forms a uniformly-distributed random computed delay forms a uniformly-distributed random
value that falls between the specified minimum and value that falls between the specified minimum and
maximum delay times. The implementor must take care to maximum delay times. The implementor must take care to
insure that the granularity of the calculated random insure that the granularity of the calculated random
component and the resolution of the timer used are both component and the resolution of the timer used are both
high enough to insure that the probability of multiple high enough to insure that the probability of multiple
nodes delaying the same amount of time is small. random nodes delaying the same amount of time is small.
delay seed
random delay seed
- If a pseudo-random number generator is used in - If a pseudo-random number generator is used in
calculating a random delay component, the generator calculating a random delay component, the generator
should be initialized with a unique seed prior to being should be initialized with a unique seed prior to being
used. Note that it is not sufficient to use the used. Note that it is not sufficient to use the
interface token alone as the seed, since interface interface token alone as the seed, since interface
tokens will not always be unique. To reduce the tokens will not always be unique. To reduce the
probability that duplicate interface tokens cause the probability that duplicate interface tokens cause the
same seed to be used, the seed should be calculated same seed to be used, the seed should be calculated
from a variety of input sources (e.g., machine from a variety of input sources (e.g., machine
components) that are likely to be different even on components) that are likely to be different even on
identical "boxes". For example, the seed could be identical "boxes". For example, the seed could be
formed by combining the CPU's serial number with an formed by combining the CPU's serial number with an
interface token. interface token.
2.2. Link Types 2.2. Link Types
Different link layers have different properties. The ones of concern Different link layers have different properties. The ones of concern
to Neighbor Discovery are: to Neighbor Discovery are:
multicast - a link that supports a native mechanism at the multicast capable
- a link that supports a native mechanism at the
link layer for sending packets to all (i.e., link layer for sending packets to all (i.e.,
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
skipping to change at page 9, line 45 skipping to change at page 9, line 47
unspecified address unspecified address
- a reserved address value that indicates the lack of an - a reserved address value that indicates the lack of an
address (e.g., the address is unknown). It is never address (e.g., the address is unknown). It is never
used as a destination address, but may be used as a used as a destination address, but may be used as a
source address if the sender does not (yet) know its source address if the sender does not (yet) know its
own address (e.g., while verifying an address is unused own address (e.g., while verifying an address is unused
during address autoconfiguration [ADDRCONF]). The during address autoconfiguration [ADDRCONF]). The
unspecified address has a value of 0:0:0:0:0:0:0:0. unspecified address has a value of 0:0:0:0:0:0:0:0.
Note that this specification does not strictly comply with the
consistency requirements for the scopes of source and destination
addresses. It is possible in some cases for hosts to use a source
address of a larger scope than the destination address in the IPv6
header.
2.4. Requirements 2.4. Requirements
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [KEYWORDS]. document, are to be interpreted as described in [KEYWORDS].
This document also makes use of internal conceptual variables to This document also makes use of internal conceptual variables to
describe protocol behavior and external variables that an describe protocol behavior and external variables that an
implementation must allow system administrators to change. The implementation must allow system administrators to change. The
specific variable names, how their values change, and how their specific variable names, how their values change, and how their
skipping to change at page 10, line 28 skipping to change at page 10, line 39
Prefix Discovery: How hosts discover the set of address prefixes Prefix Discovery: How hosts discover the set of address prefixes
that define which destinations are on-link for an that define which destinations are on-link for an
attached link. (Nodes use prefixes to distinguish attached link. (Nodes use prefixes to distinguish
destinations that reside on-link from those only destinations that reside on-link from those only
reachable through a router.) reachable through a router.)
Parameter Discovery: How a node learns such link parameters as the Parameter Discovery: How a node learns such link parameters as the
link MTU or such Internet parameters as the hop limit link MTU or such Internet parameters as the hop limit
value to place in outgoing packets. value to place in outgoing packets.
Address Autoconfiguration: How nodes automatically configure an Address Autoconfiguration: Introduces the mechanisms needed in
order to allow nodes to automatically configure an
address for an interface. address for an interface.
Address resolution: How nodes determine the link-layer address of Address resolution: How nodes determine the link-layer address of
an on-link destination (e.g., a neighbor) given only the an on-link destination (e.g., a neighbor) given only the
destination's IP address. destination's IP address.
Next-hop determination: The algorithm for mapping an IP destination Next-hop determination: The algorithm for mapping an IP destination
address into the IP address of the neighbor to which address into the IP address of the neighbor to which
traffic for the destination should be sent. The next- traffic for the destination should be sent. The next-
hop can be a router or the destination itself. hop can be a router or the destination itself.
skipping to change at page 13, line 35 skipping to change at page 13, line 45
expect to receive multiple Neighbor Advertisements for the expect to receive multiple Neighbor Advertisements for the
same target. All advertisements for anycast addresses are same target. All advertisements for anycast addresses are
tagged as being non-Override advertisements. This invokes tagged as being non-Override advertisements. This invokes
specific rules to determine which of potentially multiple specific rules to determine which of potentially multiple
advertisements should be used. advertisements should be used.
Proxy advertisements - A router willing to accept packets on behalf Proxy advertisements - A router willing to accept packets on behalf
of a target address that is unable to respond to Neighbor of a target address that is unable to respond to Neighbor
Solicitations can issue non-Override Neighbor Advertisements. Solicitations can issue non-Override Neighbor Advertisements.
Proxy advertisements are used by Mobile IPv6 home Agents to Proxy advertisements are used by Mobile IPv6 home Agents to
defend mobile nodes addresses when they move off-link. defend mobile nodes' addresses when they move off-link.
However, it is not intended as a general mechanism to handle However, it is not intended as a general mechanism to handle
nodes that, e.g., do not implement this protocol. nodes that, e.g., do not implement this protocol.
3.1. Comparison with IPv4 3.1. Comparison with IPv4
The IPv6 Neighbor Discovery protocol corresponds to a combination of The IPv6 Neighbor Discovery protocol corresponds to a combination of
the IPv4 protocols ARP [ARP], ICMP Router Discovery [RDISC], and ICMP the IPv4 protocols ARP [ARP], ICMP Router Discovery [RDISC], and ICMP
Redirect [ICMPv4]. In IPv4 there is no generally agreed upon Redirect [ICMPv4]. In IPv4 there is no generally agreed upon
protocol or mechanism for Neighbor Unreachability Detection, although protocol or mechanism for Neighbor Unreachability Detection, although
Hosts Requirements [HR-CL] does specify some possible algorithms for Hosts Requirements [HR-CL] does specify some possible algorithms for
skipping to change at page 15, line 13 skipping to change at page 15, line 23
do not contain a preference field. The preference field is not do not contain a preference field. The preference field is not
needed to handle routers of different "stability"; the Neighbor needed to handle routers of different "stability"; the Neighbor
Unreachability Detection will detect dead routers and switch to a Unreachability Detection will detect dead routers and switch to a
working one. working one.
The use of link-local addresses to uniquely identify routers (for The use of link-local addresses to uniquely identify routers (for
Router Advertisement and Redirect messages) makes it possible for Router Advertisement and Redirect messages) makes it possible for
hosts to maintain the router associations in the event of the site hosts to maintain the router associations in the event of the site
renumbering to use new global prefixes. renumbering to use new global prefixes.
Using the Hop Limit equal to 255 trick Neighbor Discovery is By setting the Hop Limit to 255, Neighbor Discovery is immune to
immune to off-link senders that accidentally or intentionally send off-link senders that accidentally or intentionally send ND
ND messages. In IPv4 off-link senders can send both ICMP messages. In IPv4 off-link senders can send both ICMP Redirects
Redirects and Router Advertisement messages. and Router Advertisement messages.
Placing address resolution at the ICMP layer makes the protocol Placing address resolution at the ICMP layer makes the protocol
more media-independent than ARP and makes it possible to use more media-independent than ARP and makes it possible to use
standard IP authentication and security mechanisms as appropriate. standard IP authentication and security mechanisms as appropriate.
3.2. Supported Link Types 3.2. Supported Link Types
Neighbor Discovery supports links with different properties. In the Neighbor Discovery supports links with different properties. In the
presence of certain properties only a subset of the ND protocol presence of certain properties only a subset of the ND protocol
mechanisms are fully specified in this document: mechanisms are fully specified in this document:
skipping to change at page 19, line 14 skipping to change at page 19, line 22
M 1-bit "Managed address configuration" flag. When M 1-bit "Managed address configuration" flag. When
set, it indicates that Dynamic Host Configuration set, it indicates that Dynamic Host Configuration
Protocol [DHCPv6] is available for address Protocol [DHCPv6] is available for address
configuration in addition to any addresses configuration in addition to any addresses
autoconfigured using stateless address autoconfigured using stateless address
autoconfiguration. The use of this flag is autoconfiguration. The use of this flag is
further described in [ADDRCONF]. further described in [ADDRCONF].
O 1-bit "Other stateful configuration" flag. When O 1-bit "Other stateful configuration" flag. When
set, it indicates that [DHCPv6-lite] is available set, it indicates that [DHCPv6lite] is available
for autoconfiguration of other (non-address) for autoconfiguration of other (non-address)
information. Examples of such information are DNS- information. Examples of such information are DNS-
related information or information on other servers related information or information on other servers
within the network. The use of this flag for add is within the network. The use of this flag for add is
further described in [ADDRCONF]. further described in [ADDRCONF].
Reserved A 6-bit unused field. It MUST be initialized to Reserved A 6-bit unused field. It MUST be initialized to
zero by the sender and MUST be ignored by the zero by the sender and MUST be ignored by the
receiver. receiver.
skipping to change at page 26, line 4 skipping to change at page 26, line 16
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 1280 octets.
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. All options are which may appear multiple times in the same message. Options should
of the form: be padded when necessary to ensure that they end on their natural 64-
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | ... | | Type | Length | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~ ~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields: Fields:
skipping to change at page 37, line 32 skipping to change at page 37, line 44
required to have them, so long as its external behavior is consistent required to have them, so long as its external behavior is consistent
with that described in this document. Default values are specified with that described in this document. Default values are specified
to simplify configuration in common cases. to simplify configuration in common cases.
The default values for some of the variables listed below may be The default values for some of the variables listed below may be
overridden by specific documents that describe how IPv6 operates over overridden by specific documents that describe how IPv6 operates over
different link layers. This rule simplifies the configuration of different link layers. This rule simplifies the configuration of
Neighbor Discovery over link types with widely differing performance Neighbor Discovery over link types with widely differing performance
characteristics. characteristics.
For each multicast interface: For each interface:
IsRouter A flag indicating whether routing is enabled on IsRouter A flag indicating whether routing is enabled on
this interface. Enabling routing on the interface this interface. Enabling routing on the interface
would imply that a router can forward packets would imply that a router can forward packets
to or from the interface. to or from the interface.
Default: FALSE Default: FALSE
AdvSendAdvertisements AdvSendAdvertisements
A flag indicating whether or not the router sends A flag indicating whether or not the router sends
skipping to change at page 41, line 16 skipping to change at page 41, line 29
variables described above. However, external router behavior MUST be variables described above. However, external router behavior MUST be
the same as host behavior with respect to these variables. In the same as host behavior with respect to these variables. In
particular, this includes the occasional randomization of the particular, this includes the occasional randomization of the
ReachableTime value as described in Section 6.3.2. ReachableTime value as described in Section 6.3.2.
Protocol constants are defined in Section 10. Protocol constants are defined in Section 10.
6.2.2. Becoming An Advertising Interface 6.2.2. Becoming An Advertising Interface
The term "advertising interface" refers to any functioning and The term "advertising interface" refers to any functioning and
enabled multicast interface that has at least one unicast IP address enabled interface that has at least one unicast IP address
assigned to it and whose corresponding AdvSendAdvertisements flag is assigned to it and whose corresponding AdvSendAdvertisements flag is
TRUE. A router MUST NOT send Router Advertisements out any interface TRUE. A router MUST NOT send Router Advertisements out any interface
that is not an advertising interface. that is not an advertising interface.
An interface may become an advertising interface at times other than An interface may become an advertising interface at times other than
system startup. For example: system startup. For example:
- changing the AdvSendAdvertisements flag on an enabled interface - changing the AdvSendAdvertisements flag on an enabled interface
from FALSE to TRUE, or from FALSE to TRUE, or
skipping to change at page 49, line 49 skipping to change at page 50, line 9
IsRouter flag is used by Neighbor Unreachability Detection to IsRouter flag is used by Neighbor Unreachability Detection to
determine when a router changes to being a host (i.e., no longer determine when a router changes to being a host (i.e., no longer
capable of forwarding packets). If a Neighbor Cache entry is created capable of forwarding packets). If a Neighbor Cache entry is created
for the router its reachability state MUST be set to STALE as for the router its reachability state MUST be set to STALE as
specified in Section 7.3.3. If a cache entry already exists and is specified in Section 7.3.3. If a cache entry already exists and is
updated with a different link-layer address the reachability state updated with a different link-layer address the reachability state
MUST also be set to STALE. MUST also be set to STALE.
If the MTU option is present, hosts SHOULD copy the option's value If the MTU option is present, hosts SHOULD copy the option's value
into LinkMTU so long as the value is greater than or equal to the into LinkMTU so long as the value is greater than or equal to the
minimum link MTU [IPv6] and does not exceed the default LinkMTU value minimum link MTU [IPv6] and does not exceed the maximum LinkMTU value
specified in the link type specific document (e.g., [IPv6-ETHER]). specified in the link type specific document (e.g., [IPv6-ETHER]).
Prefix Information options that have the "on-link" (L) flag set Prefix Information options that have the "on-link" (L) flag set
indicate a prefix identifying a range of addresses that should be indicate a prefix identifying a range of addresses that should be
considered on-link. Note, however, that a Prefix Information option considered on-link. Note, however, that a Prefix Information option
with the on-link flag set to zero conveys no information concerning with the on-link flag set to zero conveys no information concerning
on-link determination and MUST NOT be interpreted to mean that on-link determination and MUST NOT be interpreted to mean that
addresses covered by the prefix are off-link. The only way to cancel addresses covered by the prefix are off-link. The only way to cancel
a previous on-link indication is to advertise that prefix with the a previous on-link indication is to advertise that prefix with the
L-bit set and the Lifetime set to zero. The default behavior (see L-bit set and the Lifetime set to zero. The default behavior (see
skipping to change at page 52, line 12 skipping to change at page 52, line 23
return the same router until all other routers have been return the same router until all other routers have been
selected. selected.
Cycling through the router list in this case ensures that all Cycling through the router list in this case ensures that all
available routers are actively probed by the Neighbor available routers are actively probed by the Neighbor
Unreachability Detection algorithm. A request for a default Unreachability Detection algorithm. A request for a default
router is made in conjunction with the sending of a packet to a router is made in conjunction with the sending of a packet to a
router, and the selected router will be probed for reachability router, and the selected router will be probed for reachability
as a side effect. as a side effect.
3) If the Default Router List is empty, assume that all
destinations are on-link as specified in Section 5.2.
6.3.7. Sending Router Solicitations 6.3.7. Sending Router Solicitations
When an interface becomes enabled, a host may be unwilling to wait When an interface becomes enabled, a host may be unwilling to wait
for the next unsolicited Router Advertisement to locate default for the next unsolicited Router Advertisement to locate default
routers or learn prefixes. To obtain Router Advertisements quickly, routers or learn prefixes. To obtain Router Advertisements quickly,
a host SHOULD transmit up to MAX_RTR_SOLICITATIONS Router a host SHOULD transmit up to MAX_RTR_SOLICITATIONS Router
Solicitation messages each separated by at least Solicitation messages each separated by at least
RTR_SOLICITATION_INTERVAL seconds. Router Solicitations may be sent RTR_SOLICITATION_INTERVAL seconds. Router Solicitations may be sent
after any of the following events: after any of the following events:
skipping to change at page 53, line 12 skipping to change at page 53, line 20
again before sending the first Router Solicitation message. In some again before sending the first Router Solicitation message. In some
cases, the random delay MAY be omitted if necessary. For instance, a cases, the random delay MAY be omitted if necessary. For instance, a
mobile node, using [MIPv6], moving to a new link would need to mobile node, using [MIPv6], moving to a new link would need to
discover such movement as soon as possible to minimize the amount of discover such movement as soon as possible to minimize the amount of
packet losses resulting from the change in its topological movement. packet losses resulting from the change in its topological movement.
Router Solicitations provide a useful tool for movement detection in Router Solicitations provide a useful tool for movement detection in
Mobile IPv6 as they allow mobile nodes to determine movement to new Mobile IPv6 as they allow mobile nodes to determine movement to new
links. Hence, if a mobile node received link layer information links. Hence, if a mobile node received link layer information
indicating that movement might have taken place, it MAY send a Router indicating that movement might have taken place, it MAY send a Router
Solicitation immediately, without random delays. The strength of such Solicitation immediately, without random delays. The strength of such
indications should be assessed by the mobile nodes implementation indications should be assessed by the mobile node's implementation
and is outside the scope of this specification. and is outside the scope of this specification.
Once the host sends a Router Solicitation, and receives a valid Once the host sends a Router Solicitation, and receives a valid
Router Advertisement with a non-zero Router Lifetime, the host MUST Router Advertisement with a non-zero Router Lifetime, the host MUST
desist from sending additional solicitations on that interface, until desist from sending additional solicitations on that interface, until
the next time one of the above events occurs. Moreover, a host the next time one of the above events occurs. Moreover, a host
SHOULD send at least one solicitation in the case where an SHOULD send at least one solicitation in the case where an
advertisement is received prior to having sent a solicitation. advertisement is received prior to having sent a solicitation.
Unsolicited Router Advertisements may be incomplete (see Section Unsolicited Router Advertisements may be incomplete (see Section
6.2.3); solicited advertisements are expected to contain complete 6.2.3); solicited advertisements are expected to contain complete
skipping to change at page 55, line 24 skipping to change at page 55, line 33
A Neighbor Advertisements that passes the validity checks is called a A Neighbor Advertisements that passes the validity checks is called a
"valid advertisement". "valid advertisement".
7.2. Address Resolution 7.2. Address Resolution
Address resolution is the process through which a node determines the Address resolution is the process through which a node determines the
link-layer address of a neighbor given only its IP address. Address link-layer address of a neighbor given only its IP address. Address
resolution is performed only on addresses that are determined to be resolution is performed only on addresses that are determined to be
on-link and for which the sender does not know the corresponding on-link and for which the sender does not know the corresponding
link-layer address. Address resolution is never performed on link-layer address (see section 5.2). Address resolution is never
multicast addresses. performed on multicast addresses.
7.2.1. Interface Initialization 7.2.1. Interface Initialization
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. Note that multiple unicast addresses may addresses, respectively. Joining the solicited-node multicast address
map into the same solicited-node multicast address; a node MUST NOT SHOULD be done using the Multicast Listener Discovery [MLD] protocol.
leave the solicited-node multicast group until all assigned addresses Note that multiple unicast addresses may map into the same solicited-
corresponding to that multicast address have been removed. node multicast address; a node MUST NOT leave the solicited-node
multicast group until all assigned addresses 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.
If the source address of the packet prompting the solicitation is the If the source address of the packet prompting the solicitation is the
same as one of the addresses assigned to the outgoing interface, that same as one of the addresses assigned to the outgoing interface, that
skipping to change at page 58, line 40 skipping to change at page 58, line 50
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 happens. If the the advertisement is received, one of two things happens.
link layer has addresses and no Target Link-Layer address option is Otherwise, the receiving node performs the following
included, the receiving node SHOULD silently discard the received
advertisement. Otherwise, the receiving node performs the following
steps: 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.
skipping to change at page 61, line 44 skipping to change at page 62, line 7
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. proxying. This SHOULD be done using [MLD].
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 67, line 10 skipping to change at page 67, line 23
not satisfy all of the following validity checks: not satisfy all of the following validity checks:
- IP Source Address is a link-local address. Routers must use - IP Source Address is a link-local address. Routers must use
their link-local address as the source for Router Advertisement their link-local address as the source for Router Advertisement
and Redirect messages so that hosts can uniquely identify and Redirect messages so that hosts can uniquely identify
routers. routers.
- The IP Hop Limit field has a value of 255, i.e., the packet - The IP Hop Limit field has a value of 255, i.e., the packet
could not possibly have been forwarded by a router. could not possibly have been forwarded by a router.
- If the message includes an IP Authentication Header, the message
authenticates correctly.
- ICMP Checksum is valid. - ICMP Checksum is valid.
- ICMP Code is 0. - ICMP Code is 0.
- ICMP length (derived from the IP length) is 40 or more octets. - ICMP length (derived from the IP length) is 40 or more octets.
- The IP source address of the Redirect is the same as the current - The IP source address of the Redirect is the same as the current
first-hop router for the specified ICMP Destination Address. first-hop router for the specified ICMP Destination Address.
- The ICMP Destination Address field in the redirect message does - The ICMP Destination Address field in the redirect message does
skipping to change at page 72, line 45 skipping to change at page 73, line 4
Preferred and Valid lifetimes set to zero for all the prefixes. Such Preferred and Valid lifetimes set to zero for all the prefixes. Such
an attack would cause all packets, for both on-link and off-link an attack would cause all packets, for both on-link and off-link
destinations, to go to the rogue router. That router can then destinations, to go to the rogue router. That router can then
selectively examine, modify or drop all packets sent on the link. The selectively examine, modify or drop all packets sent on the link. The
Neighbor Unreachability Detection will not detect such a black hole Neighbor Unreachability Detection will not detect such a black hole
as long as the rogue router politely answers the NUD probes with a as long as the rogue router politely answers the NUD probes with a
Neighbor Advertisement with the R-bit set. Neighbor Advertisement with the R-bit set.
It is also possible for any host to launch a DoS attack on another It is also possible for any host to launch a DoS attack on another
host by preventing it from configuring an address using [ADDRCONF]. host by preventing it from configuring an address using [ADDRCONF].
The protocol does not allow hosts to verify whether the sender of a The protocol does not allow hosts to verify whether the sender of a
Neighbor Advertisement is the true owner of the IP address included Neighbor Advertisement is the true owner of the IP address included
in the message. in the message.
Redirect attacks can also be achieved by any host in order to flood a Redirect attacks can also be achieved by any host in order to flood a
victim or steal its traffic. A host can send a Neighbor advertisement victim or steal its traffic. A host can send a Neighbor advertisement
(in response to a solicitation) that contains its IP address and a (in response to a solicitation) that contains its IP address and a
victims link layer address in order to flood the victim with victim's link layer address in order to flood the victim with
unwanted traffic. Alternatively, the host can send a Neighbor unwanted traffic. Alternatively, the host can send a Neighbor
Advertisement that includes a victim∆s IP address and its own link Advertisement that includes a victim's IP address and its own link
layer address to overwrite an existing entry in the sender∆s layer address to overwrite an existing entry in the sender's
destination cache, thereby forcing the sender to forward all of the destination cache, thereby forcing the sender to forward all of the
victims traffic to itself. victim's traffic to itself.
The trust model for redirects is the same as in IPv4. A redirect is The trust model for redirects is the same as in IPv4. A redirect is
accepted only if received from the same router that is currently accepted only if received from the same router that is currently
being used for that destination. It is natural to trust the routers being used for that destination. It is natural to trust the routers
on the link. If a host has been redirected to another node (i.e., on the link. If a host has been redirected to another node (i.e.,
the destination is on-link) there is no way to prevent the target the destination is on-link) there is no way to prevent the target
from issuing another redirect to some other destination. However, from issuing another redirect to some other destination. However,
this exposure is no worse than it was; the target host, once this exposure is no worse than it was; the target host, once
subverted, could always act as a hidden router to forward traffic subverted, could always act as a hidden router to forward traffic
elsewhere. elsewhere.
skipping to change at page 75, line 29 skipping to change at page 75, line 41
routers is likely to have more serious problems than just a lack of a routers is likely to have more serious problems than just a lack of a
valid prefix and address. valid prefix and address.
The above discussion does not distinguish between the preferred and The above discussion does not distinguish between the preferred and
valid lifetimes. For all practical purposes it is probably valid lifetimes. For all practical purposes it is probably
sufficient to track the valid lifetime since the preferred lifetime sufficient to track the valid lifetime since the preferred lifetime
will not exceed the valid lifetime. will not exceed the valid lifetime.
REFERENCES REFERENCES
[ADDRCONF] Thomson, S. Narten, T, and T. Jinmei, "IPv6 Address NORMATIVE
Autoconfiguration", draft-ietf-ipv6-rfc2462bis-02, June
2004.
[ADDR-ARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing [ADDR-ARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998. Architecture", RFC 2373, July 1998.
[ICMPv6] Conta, A. and S. Deering, "Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6
(IPv6) Specification", RFC 2463, December 1998.
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[MLD] Deering, S., Fenner, W, and B. Haberman, "Multicast
Listener Discovery for IPv6", RFC 2710, October 1999.
INFORMATIVE
[ADDRCONF] Thomson, S. Narten, T, and T. Jinmei, "IPv6 Address
Autoconfiguration", draft-ietf-ipv6-rfc2462bis-02, June
2004.
[ANYCST] Partridge, C., Mendez, T. and W. Milliken, "Host [ANYCST] Partridge, C., Mendez, T. and W. Milliken, "Host
Anycasting Service", RFC 1546, November 1993. Anycasting Service", RFC 1546, November 1993.
[ARP] Plummer, D., "An Ethernet Address Resolution Protocol", [ARP] Plummer, D., "An Ethernet Address Resolution Protocol",
STD 37, RFC 826, November 1982. STD 37, RFC 826, November 1982.
[DHCPv6] Droms, R., Ed, "Dynamic Host Configuration Protocol for [DHCPv6] Droms, R., Ed, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[DHCPv6lite] Droms, R., "Stateless Dynamic Host Configuration
Protocol (DHCP)for IPv6", RFC 3736, April 2004.
[HR-CL] Braden, R., Editor, "Requirements for Internet Hosts -- [HR-CL] Braden, R., Editor, "Requirements for Internet Hosts --
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
[ICMPIKE] Arkko, J., "Effects of ICMPv6 on IKE", [ICMPIKE] Arkko, J., "Effects of ICMPv6 on IKE",
draft-arkko-icmpv6-ike-effects-02 (work in progress), draft-arkko-icmpv6-ike-effects-02 (work in progress),
March 2003. March 2003.
[ICMPv4] Postel, J., "Internet Control Message Protocol", STD 5, [ICMPv4] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981. RFC 792, September 1981.
[ICMPv6] Conta, A. and S. Deering, "Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6
(IPv6) Specification", RFC 2463, December 1998.
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[IPv6-3GPP] Wasserman, M., Ed, "Recommendations for IPv6 in Third [IPv6-3GPP] Wasserman, M., Ed, "Recommendations for IPv6 in Third
Generation Partnership Project (3GPP) standards", RFC Generation Partnership Project (3GPP) standards", RFC
3314, September 2002. 3314, September 2002.
[IPv6-CELL] Arkko, J., Kuipers, G., Soliman, H., Loughney, J. and J. [IPv6-CELL] Arkko, J., Kuipers, G., Soliman, H., Loughney, J. and J.
Wiljakka, " Internet Protocol version 6 (IPv6) for Some Wiljakka, " Internet Protocol version 6 (IPv6) for Some
Second and Third Generation Cellular Hosts", RFC 3316, Second and Third Generation Cellular Hosts", RFC 3316,
April 2003. April 2003.
[IPv6-ETHER] Crawford, M., "Transmission of IPv6 Packets over [IPv6-ETHER] Crawford, M., "Transmission of IPv6 Packets over
skipping to change at page 77, line 49 skipping to change at page 78, line 19
Computer Systems Consulting Services Computer Systems Consulting Services
1384 Fontaine 1384 Fontaine
Madison Heights, Michigan 48071 Madison Heights, Michigan 48071
USA USA
EMail: Bill.Simpson@um.cc.umich.edu EMail: Bill.Simpson@um.cc.umich.edu
bsimpson@MorningStar.com bsimpson@MorningStar.com
Hesham Soliman Hesham Soliman
Flarion Technologies Flarion Technologies
H.Soliman@flarion.com Phone: +1 908 997 9775
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.
skipping to change at page 80, line 12 skipping to change at page 80, line 34
Detection the following state transitions apply using the conceptual Detection the following state transitions apply using the conceptual
model: model:
State Event Action New state State Event Action New state
- Packet to send. Create entry. INCOMPLETE - Packet to send. Create entry. INCOMPLETE
Send multicast NS. Send multicast NS.
Start retransmit timer Start retransmit timer
INCOMPLETE Retransmit timeout, Retransmit NS INCOMPLETE INCOMPLETE Retransmit timeout, Retransmit NS INCOMPLETE
less than N Start retransmit timer less than N Start retransmit
retransmissions. retransmissions. timer
INCOMPLETE Retransmit timeout, Discard entry - INCOMPLETE Retransmit timeout, Discard entry -
N or more Send ICMP error N or more Send ICMP error
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
skipping to change at page 80, line 37 skipping to change at page 81, line 11
!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.
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 or PROBE NA, Solicited=1, - unchanged STALE, PROBE NA, Solicited=1, - unchanged
Override=0 Or DELAY Override=0
Different link-layer Different link-layer
address than cached. address than cached.
!INCOMPLETE NA, Solicited=1, Record link-layer REACHABLE !INCOMPLETE NA, Solicited=1, Record link-layer REACHABLE
Override=1 address (if Override=1 address (if
different). different).
!INCOMPLETE NA, Solicited=0, - unchanged !INCOMPLETE NA, Solicited=0, - unchanged
Override=0 Override=0
skipping to change at page 84, line 48 skipping to change at page 85, line 19
o Allowed mobile nodes to be exempt from adding random delays before o Allowed mobile nodes to be exempt from adding random delays before
sending an RS during a handover. sending an RS during a handover.
o Updated the definition of the prefix length in the prefix option o Updated the definition of the prefix length in the prefix option
o Updated the applicability to NBMA links in the introduction and o Updated the applicability to NBMA links in the introduction and
added references to 3GPP RFCs. added references to 3GPP RFCs.
o Miscellaneous editorials. o Miscellaneous editorials.
Full Copyright Statement Intellectual Property Statement
Copyright (C) The Internet Society (1998). All Rights Reserved. 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 IETF's procedures with respect to rights in IETF Documents can
be found in RFC 3667 (BCP 78) and RFC 3668 (BCP 79).
This document and translations of it may be copied and furnished to Copies of IPR disclosures made to the IETF Secretariat and any
others, and derivative works that comment on or otherwise explain it assurances of licenses to be made available, or the result of an
or assist in its implementation may be prepared, copied, published attempt made to obtain a general license or permission for the use of
and distributed, in whole or in part, without restriction of any such proprietary rights by implementers or users of this
kind, provided that the above copyright notice and this paragraph are specification can be obtained from the IETF on-line IPR repository at
included on all such copies and derivative works. However, this http://www.ietf.org/ipr.
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be The IETF invites any interested party to bring to its attention any
revoked by the Internet Society or its successors or assigns. 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.
This document and the information contained herein is provided on an Copyright Statement
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING Copyright (C) The Internet Society (2004). This document is subject
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION to the rights, licenses and restrictions contained in BCP 78, and
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF except as set forth therein, the authors retain all their rights.
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
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.
This Internet-Draft expires April, 2005.
 End of changes. 

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