draft-ietf-ipv6-2461bis-09.txt | draft-ietf-ipv6-2461bis-10.txt | |||
---|---|---|---|---|
INTERNET-DRAFT T. Narten, | INTERNET-DRAFT T. Narten, | |||
Expires: April 2007 IBM | Expires: June 2007 IBM | |||
Obsoletes: 2461 (if approved) E. Nordmark, | Obsoletes: 2461 (if approved) E. Nordmark, | |||
Sun Microsystems | Sun Microsystems | |||
W. Simpson, | W. Simpson, | |||
Daydreamer | Daydreamer | |||
H. Soliman, | H. Soliman, | |||
Flarion | Elevate Technologies | |||
October, 2006 | January, 2007 | |||
Neighbor Discovery for IP version 6 (IPv6) | Neighbor Discovery for IP version 6 (IPv6) | |||
<draft-ietf-ipv6-2461bis-09.txt> | <draft-ietf-ipv6-2461bis-10.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. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that other | Task Force (IETF), its areas, and its working groups. Note that other | |||
skipping to change at page 1, line 40 | skipping to change at page 1, line 40 | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (2006). | Copyright (C) The Internet Society (2007). | |||
Abstract | Abstract | |||
This document specifies the Neighbor Discovery protocol for IP | This document specifies the Neighbor Discovery protocol for IP | |||
Version 6. IPv6 nodes on the same link use Neighbor Discovery to | Version 6. IPv6 nodes on the same link use Neighbor Discovery to | |||
discover each other's presence, to determine each other's link-layer | discover each other's presence, to determine each other's link-layer | |||
addresses, to find routers and to maintain reachability information | addresses, to find routers and to maintain reachability information | |||
about the paths to active neighbors. | about the paths to active neighbors. | |||
Table of Contents | Table of Contents | |||
1. INTRODUCTION....................................................4 | 1. INTRODUCTION....................................................3 | |||
2. TERMINOLOGY.....................................................4 | 2. TERMINOLOGY.....................................................4 | |||
2.1. General...................................................4 | 2.1. General....................................................4 | |||
2.2. Link Types................................................8 | 2.2. Link Types.................................................7 | |||
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 | |||
4.4. Neighbor Advertisement Message Format....................22 | 4.4. Neighbor Advertisement Message Format.....................22 | |||
4.5. Redirect Message Format..................................24 | 4.5. Redirect Message Format...................................24 | |||
4.6. Option Formats...........................................26 | 4.6. Option Formats............................................26 | |||
4.6.2. Prefix Information.................................27 | 4.6.1. Source/Target Link-layer Address.....................26 | |||
4.6.3. Redirected Header..................................29 | 4.6.2. Prefix Information...................................27 | |||
4.6.4. MTU................................................30 | 4.6.3. Redirected Header....................................29 | |||
4.6.4. MTU..................................................30 | ||||
5. CONCEPTUAL MODEL OF A HOST.....................................31 | 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..............35 | 5.3. Garbage Collection and Timeout Requirements...............34 | |||
6. ROUTER AND PREFIX DISCOVERY....................................35 | 6. ROUTER AND PREFIX DISCOVERY....................................35 | |||
6.1. Message Validation.......................................36 | 6.1. Message Validation........................................36 | |||
6.1.1. Validation of Router Solicitation Messages.........36 | 6.1.1. Validation of Router Solicitation Messages...........36 | |||
6.1.2. Validation of Router Advertisement Messages........37 | 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..............42 | 6.2.3. Router Advertisement Message Content.................42 | |||
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............44 | 6.2.5. Ceasing To Be An Advertising Interface...............44 | |||
6.2.6. Processing Router Solicitations...................44 | 6.2.6. Processing Router Solicitations......................44 | |||
6.2.7. Router Advertisement Consistency..................46 | 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.......................................47 | 6.3. Host Specification........................................47 | |||
6.3.1. Host Configuration Variables......................47 | 6.3.1. Host Configuration Variables.........................47 | |||
6.3.2. Host Variables....................................47 | 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.......54 | 7. ADDRESS RESOLUTION AND NEIGHBOR UNREACHABILITY DETECTION.......54 | |||
7.1. Message Validation.......................................54 | 7.1. Message Validation........................................54 | |||
7.1.1. Validation of Neighbor Solicitations..............54 | 7.1.1. Validation of Neighbor Solicitations.................54 | |||
7.1.2. Validation of Neighbor Advertisements.............55 | 7.1.2. Validation of Neighbor Advertisements................55 | |||
7.2. Address Resolution.......................................55 | 7.2. Address Resolution........................................55 | |||
7.2.1. Interface Initialization..........................56 | 7.2.1. Interface Initialization.............................56 | |||
7.2.2. Sending Neighbor Solicitations....................56 | 7.2.2. Sending Neighbor Solicitations.......................56 | |||
7.2.3. Receipt of Neighbor Solicitations.................57 | 7.2.3. Receipt of Neighbor Solicitations....................57 | |||
7.2.4. Sending Solicited Neighbor Advertisements.........58 | 7.2.4. Sending Solicited Neighbor Advertisements............58 | |||
7.2.5. Receipt of Neighbor Advertisements................59 | 7.2.5. Receipt of Neighbor Advertisements...................59 | |||
7.2.6. Sending Unsolicited Neighbor Advertisements.......61 | 7.2.6. Sending Unsolicited Neighbor Advertisements..........61 | |||
7.2.7. Anycast Neighbor Advertisements...................62 | 7.2.7. Anycast Neighbor Advertisements......................62 | |||
7.2.8. Proxy Neighbor Advertisements.....................62 | 7.2.8. Proxy Neighbor Advertisements........................62 | |||
7.3. Neighbor Unreachability Detection........................63 | 7.3. Neighbor Unreachability Detection.........................63 | |||
7.3.1. Reachability Confirmation.........................63 | 7.3.1. Reachability Confirmation............................63 | |||
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............................................72 | 10. PROTOCOL CONSTANTS............................................72 | |||
11. SECURITY CONSIDERATIONS.......................................73 | 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 | |||
IANA CONSIDERATIONS................................................76 | ||||
REFERENCES.........................................................76 | REFERENCES.........................................................77 | |||
Authors' Addresses.................................................79 | Authors' Addresses.................................................79 | |||
APPENDIX A: MULTIHOMED HOSTS.......................................80 | APPENDIX A: MULTIHOMED HOSTS.......................................80 | |||
APPENDIX B: FUTURE EXTENSIONS......................................81 | APPENDIX B: FUTURE EXTENSIONS......................................81 | |||
APPENDIX C: STATE MACHINE FOR THE REACHABILITY STATE...............82 | APPENDIX C: STATE MACHINE FOR THE REACHABILITY STATE...............82 | |||
APPENDIX D: SUMMARY OF ISROUTER RULES..............................84 | APPENDIX D: SUMMARY OF ISROUTER RULES..............................84 | |||
APPENDIX E: IMPLEMENTATION ISSUES..................................85 | APPENDIX E: IMPLEMENTATION ISSUES..................................85 | |||
Appendix E.1: Reachability confirmations...........................85 | ||||
APPENDIX F: CHANGES FROM RFC 2461..................................86 | APPENDIX F: CHANGES FROM RFC 2461..................................86 | |||
Intellectual Property Statement....................................87 | ||||
Full Copyright Statement...........................................88 | ||||
Disclaimer of Validity.............................................88 | ||||
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 33 | skipping to change at page 4, line 20 | |||
be specified (in the appropriate document covering the operation of | be specified (in the appropriate document covering the operation of | |||
IP over a particular link type). The services described in this | IP over a particular link type). The services described in this | |||
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-CELL] discuss the use of | NBMA]. In addition, [IPv6-3GPP] and [IPv6-CELL] discuss the use of | |||
this protocol over some cellular links, which are examples of NBMA | 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 of RFC 2461 would like to acknowledge the contributions | |||
working group and, in particular, (in alphabetical order) Ran | of the IPv6 working group and, in particular, (in alphabetical order) | |||
Atkinson, Jim Bound, Scott Bradner, Alex Conta, Elwyn Davies, Stephen | Ran Atkinson, Jim Bound, Scott Bradner, Alex Conta, Stephen Deering, | |||
Deering Richard Draves, Francis Dupont, Robert Elz, Robert Gilligan, | Richard Draves, Francis Dupont, Robert Elz, Robert Gilligan, Robert | |||
Robert Hinden, Tatuya Jinmei, Allison Mankin, Dan McDonald, Charles | Hinden, Tatuya Jinmei, Allison Mankin, Dan McDonald, Charles Perkins, | |||
Perkins, Matt Thomas, and Susan Thomson. | Matt Thomas, and Susan Thomson. | |||
The editor of this document (Hesham Soliman) would like to thank the | ||||
ipv6 working group for the numerous contributions to this revision, | ||||
in particular, (in alphabetical order), Greg Daley, Elwyn Davies, | ||||
Ralph Droms, Brian Haberman, Bob Hinden, Tatuya Jinmei, Pekka Savola, | ||||
Fred Templin and Christian Vogt. | ||||
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 Control Message Protocol for the Internet | |||
Protocol Version 6. The terms ICMPv4 and ICMPv6 are | Protocol Version 6. The terms ICMPv4 and ICMPv6 are | |||
used only in contexts where necessary to avoid | used only in contexts where necessary to avoid | |||
ambiguity. | ambiguity. | |||
node - a device that implements IP. | node - a device that implements IP. | |||
router - a node that forwards IP packets not explicitly | router - a node that forwards IP packets not explicitly | |||
addressed to itself. | addressed to itself. | |||
host - any node that is not a router. | host - any node that is not a router. | |||
upper layer - a protocol layer immediately above IP. Examples are | upper layer - a protocol layer immediately above IP. Examples are | |||
transport protocols such as TCP and UDP, control | transport protocols such as TCP and UDP, control | |||
protocols such as ICMP, routing protocols such as OSPF, | protocols such as ICMP, routing protocols such as OSPF, | |||
and internet or lower-layer protocols being "tunneled" | and internet or lower-layer protocols being "tunneled" | |||
over (i.e., encapsulated in) IP such as IPX, AppleTalk, | over (i.e., encapsulated in) IP such as IPX, AppleTalk, | |||
or IP itself. | or IP itself. | |||
link - a communication facility or medium over which nodes can | link - a communication facility or medium over which nodes can | |||
communicate at the link layer, i.e., the layer | communicate at the link-layer, i.e., the layer | |||
immediately below IP. Examples are Ethernets (simple | immediately below IP. Examples are Ethernets (simple | |||
or bridged), PPP links, X.25, Frame Relay, or ATM | or bridged), PPP links, X.25, Frame Relay, or ATM | |||
networks as well as internet (or higher) layer | networks as well as internet (or higher) layer | |||
"tunnels", such as tunnels over IPv4 or IPv6 itself. | "tunnels", such as tunnels over IPv4 or IPv6 itself. | |||
interface - a node's attachment to a link. | interface - a node's attachment to a link. | |||
neighbors - nodes attached to the same link. | neighbors - nodes attached to the same link. | |||
address - an IP-layer identifier for an interface or a set of | address - an IP-layer identifier for an interface or a set of | |||
skipping to change at page 6, line 9 | skipping to change at page 5, line 50 | |||
bits of an address. | bits of an address. | |||
link-layer address | link-layer address | |||
- a link-layer identifier for an interface. Examples | - a link-layer identifier for an interface. Examples | |||
include IEEE 802 addresses for Ethernet links. | include IEEE 802 addresses for Ethernet links. | |||
on-link - an address that is assigned to an interface on a | on-link - an address that is assigned to an interface on a | |||
specified link. A node considers an address to be on- | specified link. A node considers an address to be on- | |||
link if: | link if: | |||
- it is covered by one of the link's prefixes, or | - it is covered by one of the link's prefixes (e.g. | |||
as indicated by the on-link flag in the Prefix | ||||
Information option), or | ||||
- a neighboring router specifies the address as | - a neighboring router specifies the address as | |||
the target of a Redirect message, or | the target of a Redirect message, or | |||
- a Neighbor Advertisement message is received for | - a Neighbor Advertisement message is received for | |||
the (target) address, or | the (target) address, or | |||
- any Neighbor Discovery message is received from | - any Neighbor Discovery message is received from | |||
the address. | the address. | |||
skipping to change at page 6, line 48 | skipping to change at page 6, line 40 | |||
sent by a node's IP layer are delivered to the | sent by a node's IP layer are delivered to the | |||
router's IP layer, and the router is indeed | router's IP layer, and the router is indeed | |||
forwarding packets (i.e., it is configured as a | forwarding packets (i.e., it is configured as a | |||
router, not a host). For hosts, reachability means | router, not a host). For hosts, reachability means | |||
that packets sent by a node's IP layer are delivered | that packets sent by a node's IP layer are delivered | |||
to the neighbor host's IP layer. | to the neighbor host's IP layer. | |||
packet - an IP header plus payload. | packet - an IP header plus payload. | |||
link MTU - the maximum transmission unit, i.e., maximum packet | link MTU - the maximum transmission unit, i.e., maximum packet | |||
size in octets, that can be conveyed in one piece | size in octets, that can be conveyed in one | |||
over a link. | transmission unit over a link. | |||
target - an address about which address resolution | target - an address about which address resolution | |||
information is sought, or an address which is the | information is sought, or an address which is the | |||
new first-hop when being redirected. | new first-hop when being redirected. | |||
proxy - a router that responds to Neighbor Discovery query | proxy - a node that responds to Neighbor Discovery query | |||
messages on behalf of another node. A router acting | messages on behalf of another node. A router acting | |||
on behalf of a mobile node that has moved off-link | on behalf of a mobile node that has moved off-link | |||
could potentially act as a proxy for the mobile | could potentially act as a proxy for the mobile | |||
node. | node. | |||
ICMP destination unreachable indication | ICMP destination unreachable indication | |||
- an error indication returned to the original sender | - an error indication returned to the original sender | |||
of a packet that cannot be delivered for the reasons | of a packet that cannot be delivered for the reasons | |||
outlined in [ICMPv6]. If the error occurs on a node | outlined in [ICMPv6]. If the error occurs on a node | |||
other than the node originating the packet, an ICMP | other than the node originating the packet, an ICMP | |||
skipping to change at page 7, line 47 | skipping to change at page 7, line 40 | |||
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. | nodes delaying the same amount of time is small. | |||
random 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 identifier alone as the seed, since interface | |||
tokens will not always be unique. To reduce the | identifiers will not always be unique. To reduce the | |||
probability that duplicate interface tokens cause the | probability that duplicate interface identifiers cause | |||
same seed to be used, the seed should be calculated | the 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 identifier. Additional information on | |||
randomness and random number generation can be found in | ||||
[RAND]. | ||||
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 capable | multicast capable | |||
- a link that supports a native mechanism at the | - 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 | |||
or broadcast (e.g., X.25, ATM, frame relay, etc.). | or broadcast (e.g., X.25, ATM, frame relay, etc.). | |||
skipping to change at page 8, line 47 | skipping to change at page 8, line 42 | |||
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- | |||
MEDIA]. | MEDIA]. | |||
variable MTU - a link that does not have a well-defined MTU (e.g., | variable MTU - a link that does not have a well-defined MTU (e.g., | |||
IEEE 802.5 token rings). Many links (e.g., | IEEE 802.5 token rings). Many links (e.g., | |||
Ethernet) have a standard MTU defined by the link- | Ethernet) have a standard MTU defined by the link- | |||
layer protocol or by the specific document | layer protocol or by the specific document | |||
describing how to run IP over the link layer. | describing how to run IP over the link-layer. | |||
asymmetric reachability | asymmetric reachability | |||
- a link where non-reflexive and/or non-transitive | - a link where non-reflexive and/or non-transitive | |||
reachability is part of normal operation. (Non- | reachability is part of normal operation. (Non- | |||
reflexive reachability means packets from A reach B | reflexive reachability means packets from A reach B | |||
but packets from B don't reach A. Non-transitive | but packets from B don't reach A. Non-transitive | |||
reachability means packets from A reach B, and | reachability means packets from A reach B, and | |||
packets from B reach C, but packets from A don't | packets from B reach C, but packets from A don't | |||
reach C.) Many radio links exhibit these | reach C.) Many radio links exhibit these | |||
properties. | properties. | |||
skipping to change at page 9, line 29 | skipping to change at page 9, line 26 | |||
FF02::2. | FF02::2. | |||
solicited-node multicast address | solicited-node multicast address | |||
- a link-local scope multicast address that is computed | - a link-local scope multicast address that is computed | |||
as a function of the solicited target's address. The | as a function of the solicited target's address. The | |||
function is described in [ADDR-ARCH]. The function is | function is described in [ADDR-ARCH]. The function is | |||
chosen so that IP addresses which differ only in the | chosen so that IP addresses which differ only in the | |||
most significant bits, e.g., due to multiple | most significant bits, e.g., due to multiple | |||
prefixes associated with different providers, will map | prefixes associated with different providers, will map | |||
to the same solicited-node address thereby reducing the | to the same solicited-node address thereby reducing the | |||
number of multicast addresses a node must join. | number of multicast addresses a node must join at the | |||
link-layer. | ||||
link-local address | link-local address | |||
- a unicast address having link-only scope that can be | - a unicast address having link-only scope that can be | |||
used to reach neighbors. All interfaces on routers | used to reach neighbors. All interfaces on routers | |||
MUST have a link-local address. Also, [ADDRCONF] | MUST have a link-local address. Also, [ADDRCONF] | |||
requires that interfaces on hosts have a link-local | requires that interfaces on hosts have a link-local | |||
address. | address. | |||
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 stateless address autoconfiguration [ADDRCONF]). | |||
unspecified address has a value of 0:0:0:0:0:0:0:0. | The unspecified address has a value of 0:0:0:0:0:0:0:0. | |||
Note that this specification does not strictly comply with the | Note that this specification does not strictly comply with the | |||
consistency requirements in [ADDR-SEL] for the scopes of source and | consistency requirements in [ADDR-SEL] for the scopes of source and | |||
destination addresses. It is possible in some cases for hosts to use | destination addresses. It is possible in some cases for hosts to use | |||
a source address of a larger scope than the destination address in | a source address of a larger scope than the destination address in | |||
the IPv6 header. | 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 | |||
skipping to change at page 10, line 40 | skipping to change at page 10, line 34 | |||
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: Introduces the mechanisms needed in | Address Autoconfiguration: Introduces the mechanisms needed in | |||
order to allow nodes to automatically configure an | order to allow nodes to configure an address for an | |||
address for an interface. | interface in a stateless manner. Stateless address | |||
autoconfiguration is specified in [ADDRCONF]. | ||||
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. | |||
Neighbor Unreachability Detection: How nodes determine that a | Neighbor Unreachability Detection: How nodes determine that a | |||
neighbor is no longer reachable. For neighbors used as | neighbor is no longer reachable. For neighbors used as | |||
routers, alternate default routers can be tried. For | routers, alternate default routers can be tried. For | |||
both routers and hosts, address resolution can be | both routers and hosts, address resolution can be | |||
performed again. | performed again. | |||
Duplicate Address Detection: How a node determines that an address | Duplicate Address Detection: How a node determines whether or not | |||
it wishes to use is not already in use by another node. | an address it wishes to use is already in use by | |||
another node. | ||||
Redirect: How a router informs a host of a better first-hop node | Redirect: How a router informs a host of a better first-hop node | |||
to reach a particular destination. | to reach a particular destination. | |||
Neighbor Discovery defines five different ICMP packet types: A pair | Neighbor Discovery defines five different ICMP packet types: A pair | |||
of Router Solicitation and Router Advertisement messages, a pair of | of Router Solicitation and Router Advertisement messages, a pair of | |||
Neighbor Solicitation and Neighbor Advertisements messages, and a | Neighbor Solicitation and Neighbor Advertisements messages, and a | |||
Redirect message. The messages serve the following purpose: | Redirect message. The messages serve the following purpose: | |||
Router Solicitation: When an interface becomes enabled, hosts may | Router Solicitation: When an interface becomes enabled, hosts may | |||
send out Router Solicitations that request routers to | send out Router Solicitations that request routers to | |||
generate Router Advertisements immediately rather than | generate Router Advertisements immediately rather than | |||
at their next scheduled time. | at their next scheduled time. | |||
Router Advertisement: Routers advertise their presence together | Router Advertisement: Routers advertise their presence together | |||
with various link and Internet parameters either | with various link and Internet parameters either | |||
periodically, or in response to a Router Solicitation | periodically, or in response to a Router Solicitation | |||
message. Router Advertisements contain prefixes that | message. Router Advertisements contain prefixes that | |||
are used for on-link determination and/or address | are used for determining whether an another address | |||
configuration, a suggested hop limit value, etc. | shares the same link (on-link determination) and/or | |||
address configuration, a suggested hop limit value, etc. | ||||
Neighbor Solicitation: Sent by a node to determine the link-layer | Neighbor Solicitation: Sent by a node to determine the link-layer | |||
address of a neighbor, or to verify that a neighbor is | address of a neighbor, or to verify that a neighbor is | |||
still reachable via a cached link-layer address. | still reachable via a cached link-layer address. | |||
Neighbor Solicitations are also used for Duplicate | Neighbor Solicitations are also used for Duplicate | |||
Address Detection. | Address Detection. | |||
Neighbor Advertisement: A response to a Neighbor Solicitation | Neighbor Advertisement: A response to a Neighbor Solicitation | |||
message. A node may also send unsolicited Neighbor | message. A node may also send unsolicited Neighbor | |||
Advertisements to announce a link-layer address change. | Advertisements to announce a link-layer address change. | |||
skipping to change at page 13, line 29 | skipping to change at page 13, line 25 | |||
interface. For example, a single network driver could | interface. For example, a single network driver could | |||
represent multiple network interface cards as a single | represent multiple network interface cards as a single | |||
logical interface having multiple link-layer addresses. | logical interface having multiple link-layer addresses. | |||
Neighbor Discovery allows a router to perform Load balancing | Neighbor Discovery allows a router to perform Load balancing | |||
for traffic addressed to itself by allowing routers to omit | for traffic addressed to itself by allowing routers to omit | |||
the source link-layer address from Router Advertisement | the source link-layer address from Router Advertisement | |||
packets, thereby forcing neighbors to use Neighbor | packets, thereby forcing neighbors to use Neighbor | |||
Solicitation messages to learn link-layer addresses of | Solicitation messages to learn link-layer addresses of | |||
routers. Returned Neighbor Advertisement messages can then | routers. Returned Neighbor Advertisement messages can then | |||
contain link-layer addresses that differ depending on who | contain link-layer addresses that differ depending on, e.g., | |||
issued the solicitation. This specification does not support | who issued the solicitation. This specification does not | |||
a mechanism that allows host to Load balance incoming | support a mechanism that allows hosts to Load-balance | |||
packets. | incoming packets. | |||
Anycast addresses - Anycast addresses identify one of a set of | Anycast addresses - Anycast addresses identify one of a set of | |||
nodes providing an equivalent service, and multiple nodes on | nodes providing an equivalent service, and multiple nodes on | |||
the same link may be configured to recognize the same Anycast | the same link may be configured to recognize the same Anycast | |||
address. Neighbor Discovery handles anycasts by having nodes | address. Neighbor Discovery handles anycasts by having nodes | |||
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. A non-Override | |||
specific rules to determine which of potentially multiple | advertisement is one that does not replace the information | |||
advertisements should be used. | sent by another advertisement. These advertisements are | |||
discussed later in the context of Neighbor advertisement | ||||
messages. This invokes specific rules to determine which of | ||||
potentially multiple advertisements should be used. | ||||
Proxy advertisements - A router willing to accept packets on behalf | Proxy advertisements - A node 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 | |||
skipping to change at page 15, line 5 | skipping to change at page 14, line 54 | |||
Unlike IPv4, the recipient of an IPv6 redirect assumes that the | Unlike IPv4, the recipient of an IPv6 redirect assumes that the | |||
new next-hop is on-link. In IPv4, a host ignores redirects | new next-hop is on-link. In IPv4, a host ignores redirects | |||
specifying a next-hop that is not on-link according to the link's | specifying a next-hop that is not on-link according to the link's | |||
network mask. The IPv6 redirect mechanism is analogous to the | network mask. The IPv6 redirect mechanism is analogous to the | |||
XRedirect facility specified in [SH-MEDIA]. It is expected to be | XRedirect facility specified in [SH-MEDIA]. It is expected to be | |||
useful on non-broadcast and shared media links in which it is | useful on non-broadcast and shared media links in which it is | |||
undesirable or not possible for nodes to know all prefixes for | undesirable or not possible for nodes to know all prefixes for | |||
on-link destinations. | on-link destinations. | |||
Neighbor Unreachability Detection is part of the base | Neighbor Unreachability Detection is part of the base, which | |||
significantly improving the robustness of packet delivery in the | significantly improves the robustness of packet delivery in the | |||
presence of failing routers, partially failing or partitioned | presence of failing routers, partially failing or partitioned | |||
links and nodes that change their link-layer addresses. For | links and nodes that change their link-layer addresses. For | |||
instance, mobile nodes can move off-link without losing any | instance, mobile nodes can move off-link without losing any | |||
connectivity due to stale ARP caches. | connectivity due to stale ARP caches. | |||
Unlike ARP, Neighbor Discovery detects half-link failures (using | Unlike ARP, Neighbor Discovery detects half-link failures (using | |||
Neighbor Unreachability Detection) and avoids sending traffic to | Neighbor Unreachability Detection) and avoids sending traffic to | |||
neighbors with which two-way connectivity is absent. | neighbors with which two-way connectivity is absent. | |||
Unlike in IPv4 Router Discovery the Router Advertisement messages | Unlike in IPv4 Router Discovery the Router Advertisement messages | |||
skipping to change at page 15, line 45 | skipping to change at page 15, line 43 | |||
appropriate. | 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: | |||
point-to-point - Neighbor Discovery handles such links just like | point-to-point - Neighbor Discovery handles such links just like | |||
multicast links. (Multicast can be trivially | multicast links. (Multicast can be trivially | |||
provided on point to point links, and interfaces | provided on point-to-point links, and interfaces | |||
can be assigned link-local addresses.) Neighbor | can be assigned link-local addresses.) | |||
Discovery should be implemented as described in | ||||
this document. | ||||
multicast - Neighbor Discovery should be implemented as | multicast - Neighbor Discovery supports multicast capable | |||
described in this document. | links as described in this document. | |||
non-broadcast multiple access (NBMA) | non-broadcast multiple access (NBMA) | |||
- Redirect, Neighbor Unreachability Detection and | - Redirect, Neighbor Unreachability Detection and | |||
next-hop determination should be implemented as | next-hop determination should be implemented as | |||
described in this document. Address resolution, | described in this document. Address resolution, | |||
and the mechanism for delivering Router | and the mechanism for delivering Router | |||
Solicitations and Advertisements on NBMA links is | Solicitations and Advertisements on NBMA links is | |||
not specified in this document. Note that if | not specified in this document. Note that if | |||
hosts support manual configuration of a list of | hosts support manual configuration of a list of | |||
default routers, hosts can dynamically acquire the | default routers, hosts can dynamically acquire the | |||
link-layer addresses for their neighbors from | link-layer addresses for their neighbors from | |||
Redirect messages. | Redirect messages. | |||
shared media - The Redirect message is modeled after the | shared media - The Redirect message is modeled after the | |||
XRedirect message in [SH-MEDIA] in order to | XRedirect message in [SH-MEDIA] in order to | |||
simplify use of the protocol on shared media | simplify use of the protocol on shared media | |||
links. | links. | |||
skipping to change at page 17, line 13 | skipping to change at page 17, line 10 | |||
will refrain from using them. | will refrain from using them. | |||
The protocol can presumably be extended in the | The protocol can presumably be extended in the | |||
future to find viable paths in environments that | future to find viable paths in environments that | |||
lack reflexive and transitive connectivity. | lack reflexive and transitive connectivity. | |||
3.3. Securing Neighbor Discovery messages | 3.3. Securing Neighbor Discovery messages | |||
Neighbor Discovery messages are needed for various functions. Several | Neighbor Discovery messages are needed for various functions. Several | |||
functions are designed to allow hosts to ascertain the ownership of | functions are designed to allow hosts to ascertain the ownership of | |||
an address or the mapping between link layer and IP layer addresses. | an address or the mapping between link-layer and IP layer addresses. | |||
Vulnerabilities related to Neighbor Discovery are discussed in | Vulnerabilities related to Neighbor Discovery are discussed in | |||
section 11.1. A general solution for securing Neighbor Discovery is | section 11.1. A general solution for securing Neighbor Discovery is | |||
outside the scope of this specification and is discussed in [SEND]. | outside the scope of this specification and is discussed in [SEND]. | |||
However, Section 11.2 explains how and under which constraints IPsec | However, Section 11.2 explains how and under which constraints IPsec | |||
AH or ESP can be used to secure Neighbor Discovery. | AH or ESP can be used to secure Neighbor Discovery. | |||
4. MESSAGE FORMATS | 4. MESSAGE FORMATS | |||
This section introduces message formats for all messages used in this | ||||
specification. | ||||
4.1. Router Solicitation Message Format | 4.1. Router Solicitation Message Format | |||
Hosts send Router Solicitations in order to prompt routers to | Hosts send Router Solicitations in order to prompt routers to | |||
generate Router Advertisements quickly. | generate Router Advertisements quickly. | |||
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 | Code | Checksum | | | Type | Code | Checksum | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
skipping to change at page 18, line 15 | skipping to change at page 18, line 15 | |||
Reserved This field is unused. It MUST be initialized to | Reserved This field is unused. 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. | |||
Valid Options: | Valid Options: | |||
Source link-layer address | Source link-layer address | |||
The link-layer address of the sender, if known. | The link-layer address of the sender, if known. | |||
MUST NOT be included if the Source Address is the | MUST NOT be included if the Source Address is the | |||
unspecified address. Otherwise it SHOULD be | unspecified address. Otherwise it SHOULD be | |||
included on link layers that have addresses. | included on link-layers that have addresses. | |||
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 | Receivers MUST silently ignore any options they do not recognize | |||
and continue processing the message. | and continue processing the message. | |||
4.2. Router Advertisement Message Format | 4.2. Router Advertisement Message Format | |||
Routers send out Router Advertisement message periodically, or in | Routers send out Router Advertisement message periodically, or in | |||
response to a Router Solicitation. | response to a Router Solicitation. | |||
skipping to change at page 20, line 20 | skipping to change at page 20, line 19 | |||
Solicitation messages. Used by address resolution | Solicitation messages. Used by address resolution | |||
and the Neighbor Unreachability Detection algorithm | and the Neighbor Unreachability Detection algorithm | |||
(see Sections 7.2 and 7.3). A value of zero means | (see Sections 7.2 and 7.3). A value of zero means | |||
unspecified (by this router). | unspecified (by this router). | |||
Possible options: | Possible options: | |||
Source link-layer address | Source link-layer address | |||
The link-layer address of the interface from which | The link-layer address of the interface from which | |||
the Router Advertisement is sent. Only used on | the Router Advertisement is sent. Only used on | |||
link layers that have addresses. A router MAY omit | link-layers that have addresses. A router MAY omit | |||
this option in order to enable inbound load sharing | this option in order to enable inbound load sharing | |||
across multiple link-layer addresses. | across multiple link-layer addresses. | |||
MTU SHOULD be sent on links that have a variable MTU | MTU SHOULD be sent on links that have a variable MTU | |||
(as specified in the document that describes how to | (as specified in the document that describes how to | |||
run IP over the particular link type). MAY be sent | run IP over the particular link type). MAY be sent | |||
on other links. | on other links. | |||
Prefix Information | Prefix Information | |||
These options specify the prefixes that are on-link | These options specify the prefixes that are on-link | |||
and/or are used for address autoconfiguration. A | and/or are used for stateless address | |||
router SHOULD include all its on-link prefixes | autoconfiguration. A router SHOULD include all its | |||
(except the link-local prefix) so that multihomed | on-link prefixes (except the link-local prefix) so | |||
hosts have complete prefix information about on- | that multihomed hosts have complete prefix | |||
link destinations for the links to which they | information about on-link destinations for the | |||
attach. If complete information is lacking, a | links to which they attach. If complete | |||
multihomed host may not be able to choose the | information is lacking, a host with multiple | |||
correct outgoing interface when sending traffic to | interfaces may not be able to choose the correct | |||
its neighbors. | outgoing interface when sending traffic to its | |||
neighbors. | ||||
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 | Receivers MUST silently ignore any options they do not recognize | |||
and continue processing the message. | and continue processing the message. | |||
4.3. Neighbor Solicitation Message Format | 4.3. Neighbor Solicitation Message Format | |||
Nodes send Neighbor Solicitations to request the link-layer address | Nodes send Neighbor Solicitations to request the link-layer address | |||
of a target node while also providing their own link-layer address to | of a target node while also providing their own link-layer address to | |||
the target. Neighbor Solicitations are multicast when the node needs | the target. Neighbor Solicitations are multicast when the node needs | |||
skipping to change at page 22, line 10 | skipping to change at page 21, line 54 | |||
Target Address | Target Address | |||
The IP address of the target of the solicitation. | The IP address of the target of the solicitation. | |||
It MUST NOT be a multicast address. | It MUST NOT be a multicast address. | |||
Possible options: | Possible options: | |||
Source link-layer address | Source link-layer address | |||
The link-layer address for the sender. MUST NOT be | The link-layer address for the sender. MUST NOT be | |||
included when the source IP address is the | included when the source IP address is the | |||
unspecified address. Otherwise, on link layers | unspecified address. Otherwise, on link-layers | |||
that have addresses this option MUST be included in | that have addresses this option MUST be included in | |||
multicast solicitations and SHOULD be included in | multicast solicitations and SHOULD be included in | |||
unicast solicitations. | unicast solicitations. | |||
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 | Receivers MUST silently ignore any options they do not recognize | |||
and continue processing the message. | and continue processing the message. | |||
4.4. Neighbor Advertisement Message Format | 4.4. Neighbor Advertisement Message Format | |||
skipping to change at page 24, line 8 | skipping to change at page 23, line 50 | |||
prompted this advertisement. For an unsolicited | prompted this advertisement. For an unsolicited | |||
advertisement, the address whose link-layer address | advertisement, the address whose link-layer address | |||
has changed. The Target Address MUST NOT be a | has changed. The Target Address MUST NOT be a | |||
multicast address. | multicast address. | |||
Possible options: | Possible options: | |||
Target link-layer address | Target link-layer address | |||
The link-layer address for the target, i.e., the | The link-layer address for the target, i.e., the | |||
sender of the advertisement. This option MUST be | sender of the advertisement. This option MUST be | |||
included on link layers that have addresses when | included on link-layers that have addresses when | |||
responding to multicast solicitations. When | responding to multicast solicitations. When | |||
responding to a unicast Neighbor Solicitation this | responding to a unicast Neighbor Solicitation this | |||
option SHOULD be included. | option SHOULD be included. | |||
The option MUST be included for multicast | The option MUST be included for multicast | |||
solicitations in order to avoid infinite Neighbor | solicitations in order to avoid infinite Neighbor | |||
Solicitation "recursion" when the peer node does | Solicitation "recursion" when the peer node does | |||
not have a cache entry to return a Neighbor | not have a cache entry to return a Neighbor | |||
Advertisements message. When responding to unicast | Advertisements message. When responding to unicast | |||
solicitations, the option can be omitted since the | solicitations, the option can be omitted since the | |||
skipping to change at page 27, line 30 | skipping to change at page 27, line 20 | |||
length fields) in units of 8 octets. For example, | length fields) in units of 8 octets. For example, | |||
the length for IEEE 802 addresses is 1 [IPv6- | the length for IEEE 802 addresses is 1 [IPv6- | |||
ETHER]. | ETHER]. | |||
Link-Layer Address | Link-Layer Address | |||
The variable length link-layer address. | The variable length link-layer address. | |||
The content and format of this field (including | The content and format of this field (including | |||
byte and bit ordering) is expected to be specified | byte and bit ordering) is expected to be specified | |||
in specific documents that describe how IPv6 | in specific documents that describe how IPv6 | |||
operates over different link layers. For instance, | operates over different link-layers. For instance, | |||
[IPv6-ETHER]. | [IPv6-ETHER]. | |||
Description | Description | |||
The Source Link-Layer Address option contains the | The Source Link-Layer Address option contains the | |||
link-layer address of the sender of the packet. It | link-layer address of the sender of the packet. It | |||
is used in the Neighbor Solicitation, Router | is used in the Neighbor Solicitation, Router | |||
Solicitation, and Router Advertisement packets. | Solicitation, and Router Advertisement packets. | |||
The Target Link-Layer Address option contains the | The Target Link-Layer Address option contains the | |||
link-layer address of the target. It is used in | link-layer address of the target. It is used in | |||
skipping to change at page 28, line 37 | skipping to change at page 28, line 26 | |||
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 | |||
information 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. In | |||
instance, the prefix might be used for address | other words, if the L flag is not set a host MUST | |||
configuration with some of the addresses belonging | NOT assume that an address derived from the prefix | |||
to the prefix being on-link and others being off- | is on-link unless it is explicitly told in another | |||
link. | message (e.g. Redirect). For instance, the prefix | |||
might be used for address configuration with some | ||||
of the addresses belonging to the prefix being on- | ||||
link and others being off-link. | ||||
A 1-bit autonomous address-configuration flag. When | A 1-bit autonomous address-configuration flag. When | |||
set indicates that this prefix can be used for | set indicates that this prefix can be used for | |||
stateless address configuration as specified in | stateless address configuration as specified in | |||
[ADDRCONF]. | [ADDRCONF]. | |||
Reserved1 6-bit unused field. It MUST be initialized to zero | Reserved1 6-bit unused field. It MUST be initialized to zero | |||
by the sender and MUST be ignored by the receiver. | by the sender and MUST be ignored by the receiver. | |||
Valid Lifetime | Valid Lifetime | |||
skipping to change at page 29, line 35 | skipping to change at page 29, line 27 | |||
leading bits in the prefix. The bits in the prefix | leading bits in the prefix. The bits in the prefix | |||
after the prefix length are reserved and MUST be | after the prefix length are reserved and MUST be | |||
initialized to zero by the sender and ignored by | initialized to zero by the sender and ignored by | |||
the receiver. A router SHOULD NOT send a prefix | the receiver. A router SHOULD NOT send a prefix | |||
option for the link-local prefix and a host SHOULD | option for the link-local prefix and a host SHOULD | |||
ignore such a prefix option. | ignore such a prefix option. | |||
Description | Description | |||
The Prefix Information option provide hosts with | The Prefix Information option provide hosts with | |||
on-link prefixes and prefixes for Address | on-link prefixes and prefixes for Address | |||
Autoconfiguration. | Autoconfiguration. The Prefix Information option | |||
appears in Router Advertisement packets and MUST be | ||||
The Prefix Information option appears in Router | silently ignored for other messages. | |||
Advertisement packets and MUST be silently ignored | ||||
for other messages. | ||||
4.6.3. Redirected Header | 4.6.3. Redirected Header | |||
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 | Reserved | | | Type | Length | Reserved | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Reserved | | | Reserved | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
skipping to change at page 35, line 51 | skipping to change at page 35, line 41 | |||
caches that have become invalid. When removing an entry from the | caches that have become invalid. When removing an entry from the | |||
Default Router List, however, any entries in the Destination Cache | Default Router List, however, any entries in the Destination Cache | |||
that go through that router must perform next-hop determination again | that go through that router must perform next-hop determination again | |||
to select a new default router. | to select a new default router. | |||
6. ROUTER AND PREFIX DISCOVERY | 6. ROUTER AND PREFIX DISCOVERY | |||
This section describes router and host behavior related to the Router | This section describes router and host behavior related to the Router | |||
Discovery portion of Neighbor Discovery. Router Discovery is used to | Discovery portion of Neighbor Discovery. Router Discovery is used to | |||
locate neighboring routers as well as learn prefixes and | locate neighboring routers as well as learn prefixes and | |||
configuration parameters related to address autoconfiguration. | configuration parameters related to stateless address | |||
autoconfiguration. | ||||
Prefix Discovery is the process through which hosts learn the ranges | Prefix Discovery is the process through which hosts learn the ranges | |||
of IP addresses that reside on-link and can be reached directly | of IP addresses that reside on-link and can be reached directly | |||
without going through a router. Routers send Router Advertisements | without going through a router. Routers send Router Advertisements | |||
that indicate whether the sender is willing to be a default router. | that indicate whether the sender is willing to be a default router. | |||
Router Advertisements also contain Prefix Information options that | Router Advertisements also contain Prefix Information options that | |||
list the set of prefixes that identify on-link IP addresses. | list the set of prefixes that identify on-link IP addresses. | |||
Stateless Address Autoconfiguration must also obtain subnet prefixes | Stateless Address Autoconfiguration must also obtain subnet prefixes | |||
as part of configuring addresses. Although the prefixes used for | as part of configuring addresses. Although the prefixes used for | |||
skipping to change at page 37, line 52 | skipping to change at page 37, line 43 | |||
A router MUST allow for the following conceptual variables to be | A router MUST allow for the following conceptual variables to be | |||
configured by system management. The specific variable names are | configured by system management. The specific variable names are | |||
used for demonstration purposes only, and an implementation is not | used for demonstration purposes only, and an implementation is not | |||
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 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. | |||
skipping to change at page 38, line 40 | skipping to change at page 38, line 29 | |||
unsolicited multicast Router Advertisements from | unsolicited multicast Router Advertisements from | |||
the interface, in seconds. MUST be no less than 4 | the interface, in seconds. MUST be no less than 4 | |||
seconds and no greater than 1800 seconds. | seconds and no greater than 1800 seconds. | |||
Default: 600 seconds | Default: 600 seconds | |||
MinRtrAdvInterval | MinRtrAdvInterval | |||
The minimum time allowed between sending | The minimum time allowed between sending | |||
unsolicited multicast Router Advertisements from | unsolicited multicast Router Advertisements from | |||
the interface, in seconds. MUST be no less than 3 | the interface, in seconds. MUST be no less than 3 | |||
seconds and no greater than .75 *MaxRtrAdvInterval. | seconds and no greater than .75 * | |||
MaxRtrAdvInterval. | ||||
Default: 0.33 * MaxRtrAdvInterval | Default: 0.33 * MaxRtrAdvInterval | |||
If MaxRtrAdvInterval >= 9 seconds, otherwise the | ||||
Default is MaxRtrAdvInterval. | ||||
AdvManagedFlag | AdvManagedFlag | |||
The TRUE/FALSE value to be placed in the "Managed | The TRUE/FALSE value to be placed in the "Managed | |||
address configuration" flag field in the Router | address configuration" flag field in the Router | |||
Advertisement. See [ADDRCONF]. | Advertisement. See [ADDRCONF]. | |||
Default: FALSE | Default: FALSE | |||
AdvOtherConfigFlag | AdvOtherConfigFlag | |||
The TRUE/FALSE value to be placed in the "Other | The TRUE/FALSE value to be placed in the "Other | |||
skipping to change at page 39, line 32 | skipping to change at page 39, line 26 | |||
AdvRetransTimer The value to be placed in the Retrans Timer field | AdvRetransTimer The value to be placed in the Retrans Timer field | |||
in the Router Advertisement messages sent by the | in the Router Advertisement messages sent by the | |||
router. The value zero means unspecified (by this | router. The value zero means unspecified (by this | |||
router). | router). | |||
Default: 0 | Default: 0 | |||
AdvCurHopLimit | AdvCurHopLimit | |||
The default value to be placed in the Cur Hop Limit | The default value to be placed in the Cur Hop Limit | |||
field in the Router Advertisement messages sent by | field in the Router Advertisement messages sent by | |||
the router. The value should be set to that | the router. The value should be set to the | |||
current diameter of the Internet. The value zero | current diameter of the Internet. The value zero | |||
means unspecified (by this router). | means unspecified (by this router). | |||
Default: The value specified in the "Assigned | Default: The value specified in the "Assigned | |||
Numbers" RFC [ASSIGNED] that was in effect at the | Numbers" RFC [ASSIGNED] that was in effect at the | |||
time of implementation. | time of implementation. | |||
AdvDefaultLifetime | AdvDefaultLifetime | |||
The value to be placed in the Router Lifetime field | The value to be placed in the Router Lifetime field | |||
of Router Advertisements sent from the interface, | of Router Advertisements sent from the interface, | |||
skipping to change at page 40, line 41 | skipping to change at page 40, line 35 | |||
(i.e., stays the same in consecutive | (i.e., stays the same in consecutive | |||
advertisements). | advertisements). | |||
AdvOnLinkFlag | AdvOnLinkFlag | |||
The value to be placed in the on-link | The value to be placed in the on-link | |||
flag ("L-bit") field in the Prefix | flag ("L-bit") field in the Prefix | |||
Information option. | Information option. | |||
Default: TRUE | Default: TRUE | |||
Automatic address configuration [ADDRCONF] | Stateless address configuration [ADDRCONF] | |||
defines additional information associated with | defines additional information associated with | |||
each the prefixes: | each the prefixes: | |||
AdvPreferredLifetime | AdvPreferredLifetime | |||
The value to be placed in the Preferred | The value to be placed in the Preferred | |||
Lifetime in the Prefix Information | Lifetime in the Prefix Information | |||
option, in seconds. The designated value | option, in seconds. The designated value | |||
of all 1's (0xffffffff) represents | of all 1's (0xffffffff) represents | |||
infinity. See [ADDRCONF] for details on | infinity. See [ADDRCONF] for details on | |||
how this value is used. Implementations | how this value is used. Implementations | |||
skipping to change at page 43, line 14 | skipping to change at page 43, line 7 | |||
AdvValidLifetime. | AdvValidLifetime. | |||
- In the "Autonomous address configuration" flag: the | - In the "Autonomous address configuration" flag: the | |||
entry's AdvAutonomousFlag. | entry's AdvAutonomousFlag. | |||
- In the Preferred Lifetime field: the entry's | - In the Preferred Lifetime field: the entry's | |||
AdvPreferredLifetime. | AdvPreferredLifetime. | |||
A router might want to send Router Advertisements without advertising | A router might want to send Router Advertisements without advertising | |||
itself as a default router. For instance, a router might advertise | itself as a default router. For instance, a router might advertise | |||
prefixes for address autoconfiguration while not wishing to forward | prefixes for stateless address autoconfiguration while not wishing to | |||
packets. Such a router sets the Router Lifetime field in outgoing | forward packets. Such a router sets the Router Lifetime field in | |||
advertisements to zero. | outgoing advertisements to zero. | |||
A router MAY choose not to include some or all options when sending | A router MAY choose not to include some or all options when sending | |||
unsolicited Router Advertisements. For example, if prefix lifetimes | unsolicited Router Advertisements. For example, if prefix lifetimes | |||
are much longer than AdvDefaultLifetime, including them every few | are much longer than AdvDefaultLifetime, including them every few | |||
advertisements may be sufficient. However, when responding to a | advertisements may be sufficient. However, when responding to a | |||
Router Solicitation or while sending the first few initial | Router Solicitation or while sending the first few initial | |||
unsolicited advertisements, a router SHOULD include all options so | unsolicited advertisements, a router SHOULD include all options so | |||
that all information (e.g., prefixes) is propagated quickly during | that all information (e.g., prefixes) is propagated quickly during | |||
system initialization. | system initialization. | |||
skipping to change at page 44, line 29 | skipping to change at page 44, line 23 | |||
- administratively disabling the interface, or | - administratively disabling the interface, or | |||
- shutting down the system. | - shutting down the system. | |||
In such cases the router SHOULD transmit one or more (but not more | In such cases the router SHOULD transmit one or more (but not more | |||
than MAX_FINAL_RTR_ADVERTISEMENTS) final multicast Router | than MAX_FINAL_RTR_ADVERTISEMENTS) final multicast Router | |||
Advertisements on the interface with a Router Lifetime field of zero. | Advertisements on the interface with a Router Lifetime field of zero. | |||
In the case of a router becoming a host, the system SHOULD also | In the case of a router becoming a host, the system SHOULD also | |||
depart from the all-routers IP multicast group on all interfaces on | depart from the all-routers IP multicast group on all interfaces on | |||
which the router supports IP multicast (whether or not they had been | which the router supports IP multicast (whether or not they had been | |||
advertising interfaces). In addition, the host MUST insure that | advertising interfaces). In addition, the host MUST ensure that | |||
subsequent Neighbor Advertisement messages sent from the interface | subsequent Neighbor Advertisement messages sent from the interface | |||
have the Router flag set to zero. | have the Router flag set to zero. | |||
Note that system management may disable a router's IP forwarding | Note that system management may disable a router's IP forwarding | |||
capability (i.e., changing the system from being a router to being a | capability (i.e., changing the system from being a router to being a | |||
host), a step that does not necessarily imply that the router's | host), a step that does not necessarily imply that the router's | |||
interfaces stop being advertising interfaces. In such cases, | interfaces stop being advertising interfaces. In such cases, | |||
subsequent Router Advertisements MUST set the Router Lifetime field | subsequent Router Advertisements MUST set the Router Lifetime field | |||
to zero. | to zero. | |||
skipping to change at page 47, line 50 | skipping to change at page 47, line 43 | |||
The default values in this specification may be overridden by | The default values in this specification may be overridden by | |||
specific documents that describe how IP operates over different link | specific documents that describe how IP operates over different link | |||
layers. This rule allows Neighbor Discovery to operate over links | layers. This rule allows Neighbor Discovery to operate over links | |||
with widely varying performance characteristics. | with widely varying performance characteristics. | |||
For each interface: | For each interface: | |||
LinkMTU The MTU of the link. | LinkMTU The MTU of the link. | |||
Default: The valued defined in the specific | Default: The valued defined in the specific | |||
document that describes how IPv6 operates over | document that describes how IPv6 operates over | |||
the particular link layer (e.g., [IPv6-ETHER]). | the particular link-layer (e.g., [IPv6-ETHER]). | |||
CurHopLimit The default hop limit to be used when sending | CurHopLimit The default hop limit to be used when sending | |||
(unicast) IP packets. | IP packets. | |||
Default: The value specified in the "Assigned | Default: The value specified in the "Assigned | |||
Numbers" RFC [ASSIGNED] that was in effect at the | Numbers" RFC [ASSIGNED] that was in effect at the | |||
time of implementation. | time of implementation. | |||
BaseReachableTime | BaseReachableTime | |||
A base value used for computing the random | A base value used for computing the random | |||
ReachableTime value. | ReachableTime value. | |||
Default: REACHABLE_TIME milliseconds. | Default: REACHABLE_TIME milliseconds. | |||
skipping to change at page 51, line 31 | skipping to change at page 51, line 24 | |||
to a default router and receive a redirect rather than sending | to a default router and receive a redirect rather than sending | |||
packets directly to a neighbor) the Neighbor Discovery protocol does | packets directly to a neighbor) the Neighbor Discovery protocol does | |||
not impose such a check on the prefix lifetime values. Similarly, | not impose such a check on the prefix lifetime values. Similarly, | |||
[ADDRCONF] may impose certain restrictions on the prefix length for | [ADDRCONF] may impose certain restrictions on the prefix length for | |||
address configuration purposes. Therefore, the prefix might be | address configuration purposes. Therefore, the prefix might be | |||
rejected by [ADDRCONF] implementation in the host. However, the | rejected by [ADDRCONF] implementation in the host. However, the | |||
prefix length is still valid for on-link determination when combined | prefix length is still valid for on-link determination when combined | |||
with other flags in the prefix option. | with other flags in the prefix option. | |||
Note: Implementations can choose to process the on-link aspects of | Note: Implementations can choose to process the on-link aspects of | |||
the prefixes separately from the address autoconfiguration aspects | the prefixes separately from the stateless address | |||
of the prefixes by, e.g., passing a copy of each valid Router | autoconfiguration aspects of the prefixes by, e.g., passing a copy | |||
Advertisement message to both an "on-link" and an "addrconf" | of each valid Router Advertisement message to both an "on-link" | |||
function. Each function can then operate independently on the | and an "addrconf" function. Each function can then operate | |||
prefixes that have the appropriate flag set. | independently on the prefixes that have the appropriate flag set. | |||
6.3.5. Timing out Prefixes and Default Routers | 6.3.5. Timing out Prefixes and Default Routers | |||
Whenever the invalidation timer expires for a Prefix List entry, that | Whenever the invalidation timer expires for a Prefix List entry, that | |||
entry is discarded. No existing Destination Cache entries need be | entry is discarded. No existing Destination Cache entries need be | |||
updated, however. Should a reachability problem arise with an | updated, however. Should a reachability problem arise with an | |||
existing Neighbor Cache entry, Neighbor Unreachability Detection will | existing Neighbor Cache entry, Neighbor Unreachability Detection will | |||
perform any needed recovery. | perform any needed recovery. | |||
Whenever the Lifetime of an entry in the Default Router List expires, | Whenever the Lifetime of an entry in the Default Router List expires, | |||
skipping to change at page 53, line 33 | skipping to change at page 53, line 26 | |||
a random delay since the interface became (re)enabled (e.g., as part | a random delay since the interface became (re)enabled (e.g., as part | |||
of Duplicate Address Detection [ADDRCONF]) there is no need to delay | of Duplicate Address Detection [ADDRCONF]) there is no need to delay | |||
again before sending the first Router Solicitation message. | again before sending the first Router Solicitation message. | |||
In some cases, the random delay MAY be omitted if necessary. For | In some cases, the random delay MAY be omitted if necessary. For | |||
instance, a mobile node, using [MIPv6], moving to a new link would | instance, a mobile node, using [MIPv6], moving to a new link would | |||
need to discover such movement as soon as possible to minimize the | need to discover such movement as soon as possible to minimize the | |||
amount of packet losses resulting from the change in its topological | amount of packet losses resulting from the change in its topological | |||
movement. Router Solicitations provide a useful tool for movement | movement. Router Solicitations provide a useful tool for movement | |||
detection in Mobile IPv6 as they allow mobile nodes to determine | detection in Mobile IPv6 as they allow mobile nodes to determine | |||
movement to new links. Hence, if a mobile node received link layer | movement to new links. Hence, if a mobile node received link-layer | |||
information indicating that movement might have taken place, it MAY | information indicating that movement might have taken place, it MAY | |||
send a Router Solicitation immediately, without random delays. The | send a Router Solicitation immediately, without random delays. The | |||
strength of such indications should be assessed by the mobile node's | strength of such indications should be assessed by the mobile node's | |||
implementation depending on the level of certainty of the link layer | implementation depending on the level of certainty of the link-layer | |||
hints and is outside the scope of this specification. Note that using | hints and is outside the scope of this specification. Note that using | |||
this mechanism inappropriately (e.g. based on weak or transient | this mechanism inappropriately (e.g. based on weak or transient | |||
indications) may result in Router Solicitation storms. Furthermore, | indications) may result in Router Solicitation storms. Furthermore, | |||
simultaneous mobility of a large number of mobile nodes that use this | simultaneous mobility of a large number of mobile nodes that use this | |||
mechanism can result in a large number of solicitations sent | mechanism can result in a large number of solicitations sent | |||
simultaneously. | simultaneously. | |||
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 | Responses to solicited advertisements are expected to contain | |||
6.2.3); solicited advertisements are expected to contain complete | complete information. | |||
information. | ||||
If a host sends MAX_RTR_SOLICITATIONS solicitations, and receives no | If a host sends MAX_RTR_SOLICITATIONS solicitations, and receives no | |||
Router Advertisements after having waited MAX_RTR_SOLICITATION_DELAY | Router Advertisements after having waited MAX_RTR_SOLICITATION_DELAY | |||
seconds after sending the last solicitation, the host concludes that | seconds after sending the last solicitation, the host concludes that | |||
there are no routers on the link for the purpose of [ADDRCONF]. | there are no routers on the link for the purpose of [ADDRCONF]. | |||
However, the host continues to receive and process Router | However, the host continues to receive and process Router | |||
Advertisements messages in the event that routers appear on the link. | Advertisements messages in the event that routers appear on the link. | |||
7. ADDRESS RESOLUTION AND NEIGHBOR UNREACHABILITY DETECTION | 7. ADDRESS RESOLUTION AND NEIGHBOR UNREACHABILITY DETECTION | |||
skipping to change at page 56, line 13 | skipping to change at page 56, line 5 | |||
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 (see section 5.2). Address resolution is never | link-layer address (see section 5.2). Address resolution is never | |||
performed on multicast addresses. | performed on multicast addresses. | |||
It is possible that a host may receive a solicitation, a router | It is possible that a host may receive a solicitation, a router | |||
advertisement, or a Redirect message without a link-layer address | advertisement, or a Redirect message without a link-layer address | |||
option included. These messages MUST NOT create or update neighbor | option included. These messages MUST NOT create or update neighbor | |||
cache entries, except with respect to the IsRouter flag as specified | cache entries, except with respect to the IsRouter flag as specified | |||
in sections 6.3.4 and 7.2.5. If a neighbor cache entry does not exist | in sections 6.3.4 and 7.2.5. If a neighbor cache entry does not exist | |||
for the source of such a message, Address Resolution will be required | for the source of such a message, Address Resolution will be required | |||
before unicast communications with that address to begin. This is | before unicast communications with that address can begin. This is | |||
particularly relevant for unicast responses to solicitations where an | particularly relevant for unicast responses to solicitations where an | |||
additional packet exchange is required for advertisement delivery. | additional packet exchange is required for advertisement delivery. | |||
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. Joining the solicited-node multicast address | addresses, respectively. Joining the solicited-node multicast address | |||
SHOULD be done using the Multicast Listener Discovery [MLD] or | is done using a Multicast Listener Discovery such as [MLD] or [MLDv2] | |||
[MLDv2] protocols. Note that multiple unicast addresses may map into | protocols. Note that multiple unicast addresses may map into the same | |||
the same solicited-node multicast address; a node MUST NOT leave the | solicited-node multicast address; a node MUST NOT leave the | |||
solicited-node multicast group until all assigned addresses | solicited-node multicast group until all assigned addresses | |||
corresponding to that 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 | |||
skipping to change at page 57, line 54 | skipping to change at page 57, line 45 | |||
- The Target Address is a unicast or anycast address for which the | - The Target Address is a unicast or anycast address for which the | |||
node is offering proxy service, or | node is offering proxy service, or | |||
- The Target Address is a "tentative" address on which Duplicate | - The Target Address is a "tentative" address on which Duplicate | |||
Address Detection is being performed [ADDRCONF]. | Address Detection is being performed [ADDRCONF]. | |||
If the Target Address is tentative, the Neighbor Solicitation should | If the Target Address is tentative, the Neighbor Solicitation should | |||
be processed as described in [ADDRCONF]. Otherwise, the following | be processed as described in [ADDRCONF]. Otherwise, the following | |||
description applies. If the Source Address is not the unspecified | description applies. If the Source Address is not the unspecified | |||
address and, on link layers that have addresses, the solicitation | address and, on link-layers that have addresses, the solicitation | |||
includes a Source Link-Layer Address option, then the recipient | includes a Source Link-Layer Address option, then the recipient | |||
SHOULD create or update the Neighbor Cache entry for the IP Source | SHOULD create or update the Neighbor Cache entry for the IP Source | |||
Address of the solicitation. If an entry does not already exist, the | Address of the solicitation. If an entry does not already exist, the | |||
node SHOULD create a new one and set its reachability state to STALE | node SHOULD create a new one and set its reachability state to STALE | |||
as specified in Section 7.3.3. If an entry already exists, and the | as specified in Section 7.3.3. If an entry already exists, and the | |||
cached link-layer address differs from the one in the received Source | cached link-layer address differs from the one in the received Source | |||
Link-Layer option, the cached address should be replaced by the | Link-Layer option, the cached address should be replaced by the | |||
received address and the entry's reachability state MUST be set to | received address and the entry's reachability state MUST be set to | |||
STALE. | STALE. | |||
skipping to change at page 59, line 34 | skipping to change at page 59, line 26 | |||
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. | |||
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. If the | |||
link layer has addresses and no Target Link-Layer address option is | link-layer has addresses and no Target Link-Layer address option is | |||
included, the receiving node SHOULD silently discard the received | included, the receiving node SHOULD silently discard the received | |||
advertisement. Otherwise, the receiving node performs the following | 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 | |||
skipping to change at page 60, line 20 | skipping to change at page 60, line 12 | |||
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 | b. Otherwise, the received advertisement should be ignored and | |||
MUST NOT update the cache. | MUST NOT update the cache. | |||
II. If the Override flag is set, or the supplied link-layer address | II. If the Override flag is set, or the supplied link-layer address | |||
is the same as that in the cache, or no Target Link-layer address | is the same as that in the cache, or no Target Link-layer address | |||
option was supplied, the received advertisement MUST update the | option was supplied, the received advertisement MUST update the | |||
Neighbor Cache entry 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 | MUST be inserted in the cache (if one is supplied and differs | |||
Different than the already recorded address). | from the already recorded address). | |||
- If the Solicited flag is set, the state of the entry MUST be | - If the Solicited flag is set, the state of the entry MUST be | |||
set to REACHABLE. If the Solicited flag is zero and the link | set to REACHABLE. If the Solicited flag is zero and the link | |||
layer address was updated with a different address the state | layer address was updated with a different address the state | |||
MUST be set to STALE. Otherwise, the entry's state remains | MUST be set to STALE. Otherwise, the entry's state remains | |||
unchanged. | 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. | advertisement is a response to a Neighbor Solicitation. | |||
Because Neighbor Unreachability Detection Solicitations are | Because Neighbor Unreachability Detection Solicitations are | |||
sent to the cached link-layer address, receipt of a solicited | sent to the cached link-layer address, receipt of a solicited | |||
advertisement indicates that the forward path is working. | advertisement indicates that the forward path is working. | |||
Receipt of an unsolicited advertisement, however, suggests that | Receipt of an unsolicited advertisement, however, may indicate | |||
a neighbor has urgent information to announce (e.g., a changed | that a neighbor has urgent information to announce (e.g., a | |||
link-layer address). If the urgent information indicates a | changed link-layer address). If the urgent information | |||
change from what a node is currently using, the node should | indicates a change from what a node is currently using, the | |||
verify the reachability of the (new) path when it sends the | node should verify the reachability of the (new) path when it | |||
next packet. There is no need to update the state for | sends the next packet. There is no need to update the state for | |||
unsolicited advertisements that do not change the contents of | unsolicited advertisements that do not change the contents of | |||
the cache. | 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 | Router flag in the received advertisement. In those cases | |||
where the IsRouter flag changes from TRUE to FALSE as a result | where the IsRouter flag changes from TRUE to FALSE as a result | |||
of this update, the node MUST remove that router from the | of this update, the node MUST remove that router from the | |||
Default Router List and update the Destination Cache entries | Default Router List and update the Destination Cache entries | |||
for all destinations using that neighbor as a router as | for all destinations using that neighbor as a router as | |||
specified in Section 7.3.3. This is needed to detect when a | specified in Section 7.3.3. This is needed to detect when a | |||
skipping to change at page 61, line 44 | skipping to change at page 61, line 39 | |||
A node that has multiple IP addresses assigned to an interface MAY | A node that has multiple IP addresses assigned to an interface MAY | |||
multicast a separate Neighbor Advertisement for each address. In | multicast a separate Neighbor Advertisement for each address. In | |||
such a case the node SHOULD introduce a small delay between the | such a case the node SHOULD introduce a small delay between the | |||
sending of each advertisement to reduce the probability of the | sending of each advertisement to reduce the probability of the | |||
advertisements being lost due to congestion. | advertisements being lost due to congestion. | |||
A proxy MAY multicast Neighbor Advertisements when its link-layer | A proxy MAY multicast Neighbor Advertisements when its link-layer | |||
address changes or when it is configured (by system management or | address changes or when it is configured (by system management or | |||
other mechanisms) to proxy for an address. If there are multiple | other mechanisms) to proxy for an address. If there are multiple | |||
nodes that are providing proxy services for the same set of addresses | nodes that are providing proxy services for the same set of addresses | |||
the proxies SHOULD provide a mechanism that prevents multiple proxies | the proxies should provide a mechanism that prevents multiple proxies | |||
from multicasting advertisements for any one address, in order to | from multicasting advertisements for any one address, in order to | |||
reduce the risk of excessive multicast traffic. This is a requirement | reduce the risk of excessive multicast traffic. This is a requirement | |||
on other protocols that need to use proxies for Neighbor | on other protocols that need to use proxies for Neighbor | |||
Advertisements. An example of a node that performs proxy | Advertisements. An example of a node that performs proxy | |||
advertisements is the Home Agent specified in [MIPv6]. | advertisements is the Home Agent specified in [MIPv6]. | |||
Also, a node belonging to an anycast address MAY multicast | Also, a node belonging to an anycast address MAY multicast | |||
unsolicited Neighbor Advertisements for the anycast address when the | unsolicited Neighbor Advertisements for the anycast address when the | |||
node's link-layer address changes. | node's link-layer address changes. | |||
skipping to change at page 62, line 42 | skipping to change at page 62, line 35 | |||
As with unicast addresses, Neighbor Unreachability Detection ensures | As with unicast addresses, Neighbor Unreachability Detection ensures | |||
that a node quickly detects when the current binding for an anycast | that a node quickly detects when the current binding for an anycast | |||
address becomes invalid. | address becomes invalid. | |||
7.2.8. Proxy Neighbor Advertisements | 7.2.8. Proxy Neighbor Advertisements | |||
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 | |||
to the mechanisms used with anycast addresses. | essentially the same as 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] or [MLDv2]. | proxying. This SHOULD be done using a multicast listener discovery | |||
protocol such as [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. | |||
Finally, when sending a proxy advertisement in response to a Neighbor | Finally, when sending a proxy advertisement in response to a Neighbor | |||
Solicitation, the sender should delay its response by a random time | Solicitation, the sender should delay its response by a random time | |||
between 0 and MAX_ANYCAST_DELAY_TIME seconds. | between 0 and MAX_ANYCAST_DELAY_TIME seconds to avoid collisions due | |||
to multiple responses sent by several proxies. However, in some cases | ||||
(e.g. Mobile IPv6) where only one proxy is present, such delay is not | ||||
necessary. | ||||
7.3. Neighbor Unreachability Detection | 7.3. Neighbor Unreachability Detection | |||
Communication to or through a neighbor may fail for numerous reasons | Communication to or through a neighbor may fail for numerous reasons | |||
at any time, including hardware failure, hot-swap of an interface | at any time, including hardware failure, hot-swap of an interface | |||
card, etc. If the destination has failed, no recovery is possible | card, etc. If the destination has failed, no recovery is possible | |||
and communication fails. On the other hand, if it is the path that | and communication fails. On the other hand, if it is the path that | |||
has failed, recovery may be possible. Thus, a node actively tracks | has failed, recovery may be possible. Thus, a node actively tracks | |||
the reachability "state" for the neighbors to which it is sending | the reachability "state" for the neighbors to which it is sending | |||
packets. | packets. | |||
skipping to change at page 64, line 26 | skipping to change at page 64, line 25 | |||
The receipt of a solicited Neighbor Advertisement serves as | The receipt of a solicited Neighbor Advertisement serves as | |||
reachability confirmation, since advertisements with the Solicited | reachability confirmation, since advertisements with the Solicited | |||
flag set to one are sent only in response to a Neighbor Solicitation. | flag set to one are sent only in response to a Neighbor Solicitation. | |||
Receipt of other Neighbor Discovery messages such as Router | Receipt of other Neighbor Discovery messages such as Router | |||
Advertisements and Neighbor Advertisement with the Solicited flag set | Advertisements and Neighbor Advertisement with the Solicited flag set | |||
to zero MUST NOT be treated as a reachability confirmation. Receipt | to zero MUST NOT be treated as a reachability confirmation. Receipt | |||
of unsolicited messages only confirms the one-way path from the | of unsolicited messages only confirms the one-way path from the | |||
sender to the recipient node. In contrast, Neighbor Unreachability | sender to the recipient node. In contrast, Neighbor Unreachability | |||
Detection requires that a node keep track of the reachability of the | Detection requires that a node keep track of the reachability of the | |||
forward path to a neighbor from the its perspective, not the | forward path to a neighbor from its perspective, not the neighbor's | |||
neighbor's perspective. Note that receipt of a solicited | perspective. Note that receipt of a solicited advertisement | |||
advertisement indicates that a path is working in both directions. | indicates that a path is working in both directions. The solicitation | |||
The solicitation must have reached the neighbor, prompting it to | must have reached the neighbor, prompting it to generate an | |||
generate an advertisement. Likewise, receipt of an advertisement | advertisement. Likewise, receipt of an advertisement indicates that | |||
indicates that the path from the sender to the recipient is working. | the path from the sender to the recipient is working. However, the | |||
However, the latter fact is known only to the recipient; the | latter fact is known only to the recipient; the advertisement's | |||
advertisement's sender has no direct way of knowing that the | sender has no direct way of knowing that the advertisement it sent | |||
advertisement it sent actually reached a neighbor. From the | actually reached a neighbor. From the perspective of Neighbor | |||
perspective of Neighbor Unreachability Detection, only the | Unreachability Detection, only the reachability of the forward path | |||
reachability of the forward path is of interest. | is of interest. | |||
7.3.2. Neighbor Cache Entry States | 7.3.2. Neighbor Cache Entry States | |||
A Neighbor Cache entry can be in one of five states: | A Neighbor Cache entry can be in one of five states: | |||
INCOMPLETE Address resolution is being performed on the entry. | INCOMPLETE Address resolution is being performed on the entry. | |||
Specifically, a Neighbor Solicitation has been sent to | Specifically, a Neighbor Solicitation has been sent to | |||
the solicited-node multicast address of the target, | the solicited-node multicast address of the target, | |||
but the corresponding Neighbor Advertisement has not | but the corresponding Neighbor Advertisement has not | |||
yet been received. | yet been received. | |||
skipping to change at page 69, line 20 | skipping to change at page 69, line 18 | |||
the same link as the sending node for the Destination Address of | the same link as the sending node for the Destination Address of | |||
the packet being forwarded, and | the packet being forwarded, and | |||
- the Destination Address of the packet is not a multicast | - the Destination Address of the packet is not a multicast | |||
address | address | |||
The transmitted redirect packet contains, consistent with the message | The transmitted redirect packet contains, consistent with the message | |||
format given in Section 4.5: | format given in Section 4.5: | |||
- In the Target Address field: the address to which subsequent | - In the Target Address field: the address to which subsequent | |||
packets for the destination SHOULD be sent. If the target is a | packets for the destination should be sent. If the target is a | |||
router, that router's link-local address MUST be used. If the | router, that router's link-local address MUST be used. If the | |||
target is a host the target address field MUST be set to the | target is a host the target address field MUST be set to the | |||
same value as the Destination Address field. | same value as the Destination Address field. | |||
- 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 | |||
skipping to change at page 73, line 6 | skipping to change at page 72, line 54 | |||
MAX_RANDOM_FACTOR 1.5 | MAX_RANDOM_FACTOR 1.5 | |||
Additional protocol constants are defined with the message formats in | Additional protocol constants are defined with the message formats in | |||
Section 4. | Section 4. | |||
All protocol constants are subject to change in future revisions of | All protocol constants are subject to change in future revisions of | |||
the protocol. | the protocol. | |||
The constants in this specification may be overridden by specific | The constants in this specification may be overridden by specific | |||
documents that describe how IPv6 operates over different link layers. | documents that describe how IPv6 operates over different link-layers. | |||
This rule allows Neighbor Discovery to operate over links with widely | This rule allows Neighbor Discovery to operate over links with widely | |||
varying performance characteristics. | varying performance characteristics. | |||
11. SECURITY CONSIDERATIONS | 11. SECURITY CONSIDERATIONS | |||
Neighbor Discovery is subject to attacks that cause IP packets to | Neighbor Discovery is subject to attacks that cause IP packets to | |||
flow to unexpected places. Such attacks can be used to cause denial | flow to unexpected places. Such attacks can be used to cause denial | |||
of service but also allow nodes to intercept and optionally modify | of service but also allow nodes to intercept and optionally modify | |||
packets destined for other nodes. This section deals with the main | packets destined for other nodes. This section deals with the main | |||
threats related to Neighbor Discovery messages and possible security | threats related to Neighbor Discovery messages and possible security | |||
skipping to change at page 73, line 54 | skipping to change at page 73, line 52 | |||
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 | |||
victim's 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 | |||
victim's 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. If a host has been redirected to | being used for that destination. If a host has been redirected to | |||
another node (i.e., the destination is on-link) there is no way to | another node (i.e., the destination is on-link) there is no way to | |||
prevent the target from issuing another redirect to some other | prevent the target from issuing another redirect to some other | |||
destination. However, this exposure is no worse than it was before | destination. However, this exposure is no worse than it was before | |||
skipping to change at page 74, line 26 | skipping to change at page 74, line 24 | |||
as a hidden router to forward traffic elsewhere. | as a hidden router to forward traffic elsewhere. | |||
The protocol contains no mechanism to determine which neighbors are | The protocol contains no mechanism to determine which neighbors are | |||
authorized to send a particular type of message (e.g., Router | authorized to send a particular type of message (e.g., Router | |||
Advertisements); any neighbor, presumably even in the presence of | Advertisements); any neighbor, presumably even in the presence of | |||
authentication, can send Router Advertisement messages thereby being | authentication, can send Router Advertisement messages thereby being | |||
able to cause denial of service. Furthermore, any neighbor can send | able to cause denial of service. Furthermore, any neighbor can send | |||
proxy Neighbor Advertisements as well as unsolicited Neighbor | proxy Neighbor Advertisements as well as unsolicited Neighbor | |||
Advertisements as a potential denial of service attack. | Advertisements as a potential denial of service attack. | |||
Many link layers are also subject to different denial of service | Many link-layers are also subject to different denial of service | |||
attacks such as continuously occupying the link in CSMA/CD networks | attacks such as continuously occupying the link in CSMA/CD networks | |||
(e.g., by sending packets closely back-to-back or asserting the | (e.g., by sending packets closely back-to-back or asserting the | |||
collision signal on the link), or originating packets with somebody | collision signal on the link), or originating packets with somebody | |||
else's source MAC address to confuse, e.g., Ethernet switches. On the | else's source MAC address to confuse, e.g., Ethernet switches. On the | |||
other hand, many of the threats discussed in this section are less | other hand, many of the threats discussed in this section are less | |||
effective, or non-existent, on point-to-point links, or cellular | effective, or non-existent, on point-to-point links, or cellular | |||
links where a host shares a link with only one neighbor, i.e. the | links where a host shares a link with only one neighbor, i.e. the | |||
default router. | default router. | |||
11.2 Securing Neighbor Discovery messages | 11.2 Securing Neighbor Discovery messages | |||
skipping to change at page 76, line 29 | skipping to change at page 76, line 26 | |||
sending Router Advertisements that contain appropriate (and current) | sending Router Advertisements that contain appropriate (and current) | |||
prefixes. A host connected to a network that has no functioning | prefixes. A host connected to a network that has no functioning | |||
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. | |||
IANA CONSIDERATIONS | ||||
This document does not require any new ICMPv6 types or codes to be | ||||
allocated. However, existing ICMPv6 types should be updated to point | ||||
to the document instead of RFC 2461. The procedure for the assignment | ||||
of ICMPv6 types/codes is described in Section 6 of [ICMPv6]. | ||||
This document continues to use the following ICMPv6 message types | ||||
introduced in RFC 2461 and already assigned by IANA: | ||||
Message name ICMPv6 Type | ||||
Router Solicitation 133 | ||||
Router Advertisement 134 | ||||
Neighbor Solicitation 135 | ||||
Neighbor Advertisement 136 | ||||
Redirect 137 | ||||
This document continues to use the following Neighbor Discovery | ||||
option types introduced in RFC 2461 and already assigned by IANA: | ||||
Option Name Type | ||||
Source Link-Layer Address 1 | ||||
Target Link-Layer Address 2 | ||||
Prefix Information 3 | ||||
Redirected Header 4 | ||||
MTU 5 | ||||
Neighbor Discovery option types are allocated using following | ||||
procedure: | ||||
1. The IANA should allocate and permanently register new option types | ||||
from IETF RFC publication. This is for all RFC types | ||||
including standards track, informational, and experimental status | ||||
that originate from the IETF and have been approved by the IESG | ||||
for publication. | ||||
2. IETF working groups with working group consensus and area director | ||||
approval can request reclaimable Neighbor Discovery option type | ||||
assignments from the IANA. The IANA will tag the values as | ||||
"reclaimable in future". | ||||
The "reclaimable in the future" tag will be removed when an RFC is | ||||
published documenting the protocol as defined in 1). This will | ||||
make the assignment permanent and update the reference on the IANA | ||||
web pages. | ||||
At the point where the option type values are 85% assigned, the | ||||
IETF will review the assignments tagged "reclaimable in the | ||||
future" and inform the IANA which ones should be reclaimed and | ||||
reassigned. | ||||
3. Requests for new option type value assignments from outside the | ||||
IETF are only made through the publication of an IETF document, | ||||
per 1) above. Note also that documents published as "RFC Editor | ||||
contributions" [RFC3667] are not considered to be IETF documents. | ||||
REFERENCES | REFERENCES | |||
NORMATIVE | NORMATIVE | |||
[ADDR-ARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing | [ADDR-ARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing | |||
Architecture", RFC 3513, April 2003. | Architecture", RFC 4291, February 2006. | |||
[ICMPv6] Conta, A. and S. Deering, "Internet Control Message | [ICMPv6] Conta, A. and S. Deering, "Internet Control Message | |||
Protocol (ICMPv6) for the Internet Protocol Version 6 | Protocol (ICMPv6) for the Internet Protocol Version 6 | |||
(IPv6) Specification", RFC 2463, December 1998. | (IPv6) Specification", RFC 4443, March 2006. | |||
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 | [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 | |||
(IPv6) Specification", RFC 2460, December 1998. | (IPv6) Specification", RFC 2460, December 1998. | |||
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate | [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
INFORMATIVE | INFORMATIVE | |||
[ADDRCONF] Thomson, S. Narten, T, and T. Jinmei, "IPv6 Address | [ADDRCONF] Thomson, S. Narten, T, and T. Jinmei, "IPv6 Address | |||
skipping to change at page 77, line 43 | skipping to change at page 78, line 50 | |||
[IPv6-SA] Kent, S. and R. Atkinson, "Security Architecture for the | [IPv6-SA] Kent, S. and R. Atkinson, "Security Architecture for the | |||
Internet Protocol", RFC 4301, December 2005. | Internet Protocol", RFC 4301, December 2005. | |||
[IPv6-AUTH] S. Kent, "IP Authentication Header", RFC 4302, December | [IPv6-AUTH] S. Kent, "IP Authentication Header", RFC 4302, December | |||
2005. | 2005. | |||
[IPv6-ESP] S. Kent, "IP Encapsulating Security Payload (ESP)", RFC | [IPv6-ESP] S. Kent, "IP Encapsulating Security Payload (ESP)", RFC | |||
4303, December 2005. | 4303, December 2005. | |||
[IPv6-NBMA] Armitage, G., Schulter, P., Jork, M and G. Harter "IPv6 | ||||
over Non-Broadcast Multiple Access (NBMA) networks", RFC | ||||
2491, January 1999. | ||||
[LD-SHRE] Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load | [LD-SHRE] Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load | |||
Sharing", RFC 4311, November 2005. | Sharing", RFC 4311, November 2005. | |||
[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 | [MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery | |||
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. | Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. | |||
[PSREQ] Nikander, P., Kempf, J. And E. Nordmark, "IPv6 Neighbor | [PSREQ] Nikander, P., Kempf, J. And E. Nordmark, "IPv6 Neighbor | |||
Discovery (ND) Trust and Threats", RFC 3756, May 2004. | Discovery (ND) Trust and Threats", RFC 3756, May 2004. | |||
rd [RAND] Eastlake, 3 , D., Schiller, J and S. Crocker, | ||||
"Randomness Requirements for Security", RFC 4086, June | ||||
2005. | ||||
[RDISC] Deering, S., "ICMP Router Discovery Messages", RFC 1256, | [RDISC] Deering, S., "ICMP Router Discovery Messages", RFC 1256, | |||
September 1991. | September 1991. | |||
[RFC3667] Bradner, S., "IETF Rights in Contributions", RFC 3667, | [RFC3667] Bradner, S., "IETF Rights in Contributions", RFC 3667, | |||
February 2004. | February 2004. | |||
[RTSEL] Draves, R. and D. Thaler, "Default Router Preferences | [RTSEL] Draves, R. and D. Thaler, "Default Router Preferences | |||
and more Specific Routes", draft-ietf-ipv6-router- | and more Specific Routes", draft-ietf-ipv6-router- | |||
selection-07, (work in progress), January 2005. | selection-07, (work in progress), January 2005. | |||
skipping to change at page 78, line 30 | skipping to change at page 79, line 43 | |||
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)",RFC3971, | Nikander, "SEcure Neighbor Discovery (SEND)",RFC3971, | |||
March 2005. | March 2005. | |||
[SYNC] S. Floyd, V. Jacobson, "The Synchronization of Periodic | [SYNC] S. Floyd, V. Jacobson, "The Synchronization of Periodic | |||
Routing Messages", IEEE/ACM Transactions on Networking, | Routing Messages", IEEE/ACM Transactions on Networking, | |||
April 1994. ftp://ftp.ee.lbl.gov/papers/sync_94.ps.Z | April 1994. ftp://ftp.ee.lbl.gov/papers/sync_94.ps.Z | |||
IANA CONSIDERATIONS | ||||
This document does not require any new ICMPv6 types or codes to be | ||||
allocated. However, existing ICMPv6 types should be updated to point | ||||
to the document instead of RFC 2461. The procedure for the assignment | ||||
of ICMPv6 types/codes is described in Section 6 of [ICMPv6]. | ||||
This document continues to use the following ICMPv6 message types | ||||
introduced in RFC 2461 and already assigned by IANA: | ||||
Message name ICMPv6 Type | ||||
Router Solicitation 133 | ||||
Router Advertisement 134 | ||||
Neighbor Solicitation 135 | ||||
Neighbor Advertisement 136 | ||||
Redirect 137 | ||||
This document continues to use the following Neighbor Discovery | ||||
option types introduced in RFC 2461 and already assigned by IANA: | ||||
Option Name Type | ||||
Source Link-Layer Address 1 | ||||
Target Link-Layer Address 2 | ||||
Prefix Information 3 | ||||
Redirected Header 4 | ||||
MTU 5 | ||||
Neighbor Discovery option types are allocated using following | ||||
procedure: | ||||
1. The IANA should allocate and permanently register new option types | ||||
from IETF RFC publication. This is for all RFC types | ||||
including standards track, informational, and experimental status | ||||
that originate from the IETF and have been approved by the IESG | ||||
for publication. | ||||
2. IETF working groups with working group consensus and area director | ||||
approval can request reclaimable Neighbor Discovery option type | ||||
assignments from the IANA. The IANA will tag the values as | ||||
"reclaimable in future". | ||||
The "reclaimable in the future" tag will be removed when an RFC is | ||||
published documenting the protocol as defined in 1). This will | ||||
make the assignment permanent and update the reference on the IANA | ||||
web pages. | ||||
At the point where the option type values are 85% assigned, the | ||||
IETF will review the assignments tagged "reclaimable in the | ||||
future" and inform the IANA which ones should be reclaimed and | ||||
reassigned. | ||||
3. Requests for new option type value assignments from outside the | ||||
IETF are only made through the publication of an IETF document, | ||||
per 1) above. Note also that documents published as "RFC Editor | ||||
contributions" [RFC3667] are not considered to be IETF documents. | ||||
Authors' Addresses | Authors' Addresses | |||
Thomas Narten | Thomas Narten | |||
IBM Corporation | IBM Corporation | |||
P.O. Box 12195 | P.O. Box 12195 | |||
Research Triangle Park, NC 27709-2195 | Research Triangle Park, NC 27709-2195 | |||
USA | USA | |||
Phone: +1 919 254 7798 | Phone: +1 919 254 7798 | |||
EMail: narten@raleigh.ibm.com | EMail: narten@us.ibm.com | |||
Erik Nordmark | Erik Nordmark | |||
Sun Microsystems, Inc. | Sun Microsystems, Inc. | |||
901 San Antonio Road | 901 San Antonio Road | |||
Palo Alto, CA 94303 | Palo Alto, CA 94303 | |||
USA | USA | |||
Phone: +1 650 786 5166 | Phone: +1 650 786 5166 | |||
Fax: +1 650 786 5896 | Fax: +1 650 786 5896 | |||
EMail: nordmark@sun.com | EMail: nordmark@sun.com | |||
skipping to change at page 80, line 24 | skipping to change at page 80, line 25 | |||
Daydreamer | Daydreamer | |||
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 | |||
Qualcomm-Flarion Technologies | Elevate Technologies | |||
Email: Hesham@Qualcomm.com | Email: hesham@elevatemobile.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. Further work | on multihomed hosts and to report their experiences. Further work | |||
skipping to change at page 81, line 7 | skipping to change at page 81, line 9 | |||
standard test for this case is to compare the source address of | standard test for this case is to compare the source address of | |||
the packet to the list of on-link prefixes associated with the | the packet to the list of on-link prefixes associated with the | |||
interface on which the packet was received. If the originating | interface on which the packet was received. If the originating | |||
host is multihomed, however, the source address it uses may | host is multihomed, however, the source address it uses may | |||
belong to an interface other than the interface from which it | belong to an interface other than the interface from which it | |||
was sent. In such cases, a router will not send redirects, and | was sent. In such cases, a router will not send redirects, and | |||
suboptimal routing is likely. In order to be redirected, the | suboptimal routing is likely. In order to be redirected, the | |||
sending host must always send packets out the interface | sending host must always send packets out the interface | |||
corresponding to the outgoing packet's source address. Note | corresponding to the outgoing packet's source address. Note | |||
that this issue never arises with non-multihomed hosts; they | that this issue never arises with non-multihomed hosts; they | |||
only have one interface. | only have one interface. Additional discussion on this topic can | |||
be found in RFC1122 under section 3.3.4.2. | ||||
2) If the selected first-hop router does not have a route at all | 2) If the selected first-hop router does not have a route at all | |||
for the destination, it will be unable to deliver the packet. | for the destination, it will be unable to deliver the packet. | |||
However, the destination may be reachable through a router on | However, the destination may be reachable through a router on | |||
one of the other interfaces. Neighbor Discovery does not | one of the other interfaces. Neighbor Discovery does not | |||
address this scenario; it does not arise in the non-multihomed | address this scenario; it does not arise in the non-multihomed | |||
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. | |||
skipping to change at page 82, line 46 | skipping to change at page 82, line 49 | |||
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, Update content of unchanged | INCOMPLETE NA, Solicited=any, Update content of unchanged | |||
Override=any, No IsRouter flag | Override=any, No IsRouter flag | |||
Link-layer address | Link-layer address | |||
- NS, RS, Redirect - - | - NS, RS, Redirect - - | |||
No link layer address | No link-layer address | |||
!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 | !INCOMPLETE NA, Solicited=any, Update content of unchanged | |||
Override=any, No IsRouter flag. | Override=any, No IsRouter flag. | |||
link-layer address | 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 | |||
skipping to change at page 84, line 37 | skipping to change at page 84, line 40 | |||
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, | |||
either implicitly or explicitly, information that indicates whether | either implicitly or explicitly, information that indicates whether | |||
or not the sender (or Target Address) is a host or a router. The | or not the sender (or Target Address) is a host or a router. The | |||
following assumptions are used: | following assumptions are used: | |||
- The sender of a Router Solicitation is implicitly assumed to be a | ||||
host since there is no need for routers to send such messages. | ||||
- The sender of a Router Advertisement is implicitly assumed to be a | - The sender of a Router Advertisement is implicitly assumed to be a | |||
router. | router. | |||
- Neighbor Solicitation messages do not contain either an implicit | - Neighbor Solicitation messages do not contain either an implicit | |||
or explicit indication about the sender. Both hosts and routers | or explicit indication about the sender. Both hosts and routers | |||
send such messages. | send such messages. | |||
- Neighbor Advertisement messages contain an explicit "IsRouter | - Neighbor Advertisement messages contain an explicit "IsRouter | |||
flag", the R-bit. | flag", the R-bit. | |||
skipping to change at page 85, line 12 | skipping to change at page 85, line 12 | |||
node is expected to be able to forward the packets towards the | node is expected to be able to forward the packets towards the | |||
destination. | destination. | |||
- The target of the redirect, when the target is the same as the | - The target of the redirect, when the target is the same as the | |||
destination, does not carry any host vs. router information. All | destination, does not carry any host vs. router information. All | |||
that is known is that the destination (i.e. target) is on-link but | that is known is that the destination (i.e. target) is on-link but | |||
it could be either a host or a router. | it could be either a host or a router. | |||
The rules for setting the IsRouter flag are based on the information | The rules for setting the IsRouter flag are based on the information | |||
content above. If an ND message contains explicit or implicit | content above. If an ND message contains explicit or implicit | |||
information the receipt of the message will cause the IsRouter flag | information, the receipt of the message will cause the IsRouter flag | |||
to be updated. But when there is no host vs. router information in | to be updated. But when there is no host vs. router information in | |||
the ND message the receipt of the message MUST NOT cause a change to | the ND message the receipt of the message MUST NOT cause a change to | |||
the IsRouter state. When the receipt of such a message causes a | the IsRouter state. When the receipt of such a message causes a | |||
Neighbor Cache entry to be created this document specifies that the | Neighbor Cache entry to be created this document specifies that the | |||
IsRouter flag be set to FALSE. There is greater potential for | IsRouter flag be set to FALSE. There is greater potential for | |||
mischief when a node incorrectly thinks a host is a router, than the | mischief when a node incorrectly thinks a host is a router, than the | |||
other way around. In these cases a subsequent Neighbor Advertisement | other way around. In these cases a subsequent Neighbor Advertisement | |||
or Router Advertisement message will set the correct IsRouter value. | or Router Advertisement message will set the correct IsRouter value. | |||
APPENDIX E: IMPLEMENTATION ISSUES | APPENDIX E: IMPLEMENTATION ISSUES | |||
skipping to change at page 86, line 10 | skipping to change at page 86, line 10 | |||
To minimize the cost of communicating reachability information | To minimize the cost of communicating reachability information | |||
between the TCP and IP layers, an implementation may wish to rate- | between the TCP and IP layers, an implementation may wish to rate- | |||
limit the reachability confirmations its sends IP. One possibility | limit the reachability confirmations its sends IP. One possibility | |||
is to process reachability only every few packets. For example, one | is to process reachability only every few packets. For example, one | |||
might update reachability information once per round trip time, if an | might update reachability information once per round trip time, if an | |||
implementation only has one round trip timer per connection. For | implementation only has one round trip timer per connection. For | |||
those implementations that cache Destination Cache entries within | those implementations that cache Destination Cache entries within | |||
control blocks, it may be possible to update the Neighbor Cache entry | control blocks, it may be possible to update the Neighbor Cache entry | |||
directly (i.e., without an expensive lookup) once the TCP packet has | directly (i.e., without an expensive lookup) once the TCP packet has | |||
been demultiplexed to its corresponding control block. For other | been demultiplexed to its corresponding control block. For other | |||
implementation it may be possible to piggyback the reachability | implementations it may be possible to piggyback the reachability | |||
confirmation on the next packet submitted to IP assuming that the | confirmation on the next packet submitted to IP assuming that the | |||
implementation guards against the piggybacked confirmation becoming | implementation guards against the piggybacked confirmation becoming | |||
stale when no packets are sent to IP for an extended period of time. | stale when no packets are sent to IP for an extended period of time. | |||
TCP must also guard against thinking "stale" information indicates | TCP must also guard against thinking "stale" information indicates | |||
current reachability. For example, new data received 30 minutes | current reachability. For example, new data received 30 minutes | |||
after a window has opened up does not constitute a confirmation that | after a window has opened up does not constitute a confirmation that | |||
the path is currently working. It merely indicates that 30 minutes | the path is currently working; it merely indicates that 30 minutes | |||
ago the window update reached the peer i.e. the path was working at | ago the window update reached the peer i.e. the path was working at | |||
that point in time. An implementation must also take into account | that point in time. An implementation must also take into account | |||
TCP zero-window probes that are sent even if the path is broken and | TCP zero-window probes that are sent even if the path is broken and | |||
the window update did not reach the peer. | the window update did not reach the peer. | |||
For UDP based applications (RPC, DNS) it is relatively simple to make | For UDP based applications (RPC, DNS) it is relatively simple to make | |||
the client send reachability confirmations when the response packet | the client send reachability confirmations when the response packet | |||
is received. It is more difficult and in some cases impossible for | is received. It is more difficult and in some cases impossible for | |||
the server to generate such confirmations since there is no flow | the server to generate such confirmations since there is no flow | |||
control, i.e., the server can not determine whether a received | control, i.e., the server can not determine whether a received | |||
request indicates that a previous response reached the client. | request indicates that a previous response reached the client. | |||
Note that an implementation can not use negative upper-layer advise | Note that an implementation can not use negative upper-layer advice | |||
as a replacement for the Neighbor Unreachability Detection algorithm. | as a replacement for the Neighbor Unreachability Detection algorithm. | |||
Negative advise (e.g. from TCP when there are excessive | Negative advice (e.g., from TCP when there are excessive | |||
retransmissions) could serve as a hint that the forward path from the | retransmissions) could serve as a hint that the forward path from the | |||
sender of the data might not be working. But it would fail to detect | sender of the data might not be working. But it would fail to detect | |||
when the path from the receiver of the data is not functioning | when the path from the receiver of the data is not functioning, | |||
causing, none of the acknowledgement packets to reach the sender. | causing none of the acknowledgement packets to reach the sender. | |||
APPENDIX F: CHANGES FROM RFC 2461 | APPENDIX F: CHANGES FROM RFC 2461 | |||
o Removed references to IPsec AH and ESP for securing messages | o Removed references to IPsec AH and ESP for securing messages | |||
or as part of validating the received message. | or as part of validating the received message. | |||
o Added section 3.3. | o Added section 3.3. | |||
o Updated section 11 to include more detailed discussion on threats, | o Updated section 11 to include more detailed discussion on threats, | |||
IPsec limitations, and use of SeND. | IPsec limitations, and use of SeND. | |||
skipping to change at page 87, line 28 | skipping to change at page 87, line 28 | |||
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 Clarified support for Load balancing is limited to routers. | o Clarified support for Load balancing is limited to routers. | |||
o Clarified router behaviour when receiving a Router Solicitation | o Clarified router behaviour when receiving a Router Solicitation | |||
without SLLAO. | without SLLAO. | |||
o Clarified that inconsistency checks for CurHopLimit are done for | o Clarified that inconsistency checks for CurHopLimit are done for | |||
none zero values only. | non-zero values only. | |||
o Rearranged section 7.2.5 for clarity and described the processing | o Rearranged section 7.2.5 for clarity and described the processing | |||
when receiving the NA in INCOMPLETE state. | when receiving the NA in INCOMPLETE state. | |||
o Added clarifications in section 7.2 on how a node should react | o Added clarifications in section 7.2 on how a node should react | |||
upon receiving a message without SLLAO. | upon receiving a message without SLLAO. | |||
O Added New IANA section. | O Added New IANA section. | |||
o Miscellaneous editorials. | o Miscellaneous editorials. | |||
skipping to change at page 88, line 15 | skipping to change at page 88, line 15 | |||
http://www.ietf.org/ipr. | http://www.ietf.org/ipr. | |||
The IETF invites any interested party to bring to its attention any | The IETF invites any interested party to bring to its attention any | |||
copyrights, patents or patent applications, or other proprietary | copyrights, patents or patent applications, or other proprietary | |||
rights that may cover technology that may be required to implement | rights that may cover technology that may be required to implement | |||
this standard. Please address the information to the IETF at ietf- | this standard. Please address the information to the IETF at ietf- | |||
ipr@ietf.org. | ipr@ietf.org. | |||
Full Copyright Statement | Full Copyright Statement | |||
Copyright (C) The Internet Society (2006). This document is subject | Copyright (C) The Internet Society (2007). This document is subject | |||
to the rights, licenses and restrictions contained in BCP 78, and | to the rights, licenses and restrictions contained in BCP 78, and | |||
except as set forth therein, the authors retain all their rights. | except as set forth therein, the authors retain all their rights. | |||
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 April, 2007. | This Internet-Draft expires June, 2007. | |||
End of changes. 104 change blocks. | ||||
289 lines changed or deleted | 308 lines changed or added | |||
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |