draft-ietf-ipv6-2461bis-11.txt | rfc4861.txt | |||
---|---|---|---|---|
INTERNET-DRAFT T. Narten, | Network Working Group T. Narten | |||
Expires: September 2007 IBM | Request for Comments: 4861 IBM | |||
Obsoletes: 2461 (if approved) E. Nordmark, | Obsoletes: 2461 E. Nordmark | |||
Sun Microsystems | Category: Standards Track Sun Microsystems | |||
W. Simpson, | W. Simpson | |||
Daydreamer | Daydreamer | |||
H. Soliman, | H. Soliman | |||
Elevate Technologies | Elevate Technologies | |||
March, 2007 | September 2007 | |||
Neighbor Discovery for IP version 6 (IPv6) | Neighbor Discovery for IP version 6 (IPv6) | |||
<draft-ietf-ipv6-2461bis-11.txt> | ||||
Status of this memo | ||||
By submitting this Internet-Draft, each author represents that any | ||||
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 | ||||
aware will be disclosed, in accordance with Section 6 of BCP 79. | ||||
Internet-Drafts are working documents of the Internet Engineering | Status of This Memo | |||
Task Force (IETF), its areas, and its working groups. Note that other | ||||
groups may also distribute working documents as Internet- Drafts. | ||||
Internet-Drafts are draft documents valid for a maximum of six months | ||||
and may be updated, replaced, or obsoleted by other documents at any | ||||
time. It is inappropriate to use Internet-Drafts as reference | ||||
material or to cite them other than as "work in progress." | ||||
The list of current Internet-Drafts can be accessed at | ||||
http://www.ietf.org/ietf/1id-abstracts.txt. | ||||
The list of Internet-Draft Shadow Directories can be accessed at | ||||
http://www.ietf.org/shadow.html. | ||||
Copyright Notice | ||||
Copyright (C) The IETF Trust (2007). | This document specifies an Internet standards track protocol for the | |||
Internet community, and requests discussion and suggestions for | ||||
improvements. Please refer to the current edition of the "Internet | ||||
Official Protocol Standards" (STD 1) for the standardization state | ||||
and status of this protocol. Distribution of this memo is unlimited. | ||||
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....................................................3 | 1. Introduction ....................................................4 | |||
2. TERMINOLOGY.....................................................4 | 2. Terminology .....................................................4 | |||
2.1. General....................................................4 | 2.1. General....................................................4 | |||
2.2. Link Types.................................................7 | 2.2. Link Types .................................................8 | |||
2.3. Addresses..................................................9 | 2.3. Addresses..................................................9 | |||
2.4. Requirements...............................................9 | 2.4. Requirements ..............................................10 | |||
3. PROTOCOL OVERVIEW..............................................10 | 3. Protocol Overview ..............................................10 | |||
3.1. Comparison with IPv4......................................13 | 3.1. Comparison with IPv4 ......................................14 | |||
3.2. Supported Link Types......................................15 | 3.2. Supported Link Types ......................................16 | |||
3.3. Securing Neighbor Discovery messages.......................17 | 3.3. Securing Neighbor Discovery Messages ......................18 | |||
4. MESSAGE FORMATS................................................17 | 4. Message Formats ................................................18 | |||
4.1. Router Solicitation Message Format........................17 | 4.1. Router Solicitation Message Format ........................18 | |||
4.2. Router Advertisement Message Format.......................18 | 4.2. Router Advertisement Message Format .......................19 | |||
4.3. Neighbor Solicitation Message Format......................20 | 4.3. Neighbor Solicitation Message Format ......................22 | |||
4.4. Neighbor Advertisement Message Format.....................22 | 4.4. Neighbor Advertisement Message Format .....................23 | |||
4.5. Redirect Message Format...................................24 | 4.5. Redirect Message Format ...................................26 | |||
4.6. Option Formats............................................26 | 4.6. Option Formats ............................................28 | |||
4.6.1. Source/Target Link-layer Address.....................26 | 4.6.1. Source/Target Link-layer Address ...................28 | |||
4.6.2. Prefix Information...................................27 | 4.6.2. Prefix Information .................................29 | |||
4.6.3. Redirected Header....................................29 | 4.6.3. Redirected Header ..................................31 | |||
4.6.4. MTU..................................................30 | 4.6.4. MTU ................................................32 | |||
5. CONCEPTUAL MODEL OF A HOST.....................................31 | 5. Conceptual Model of a Host .....................................33 | |||
5.1. Conceptual Data Structures................................31 | 5.1. Conceptual Data Structures ................................33 | |||
5.2. Conceptual Sending Algorithm..............................33 | 5.2. Conceptual Sending Algorithm ..............................36 | |||
5.3. Garbage Collection and Timeout Requirements...............34 | 5.3. Garbage Collection and Timeout Requirements ...............37 | |||
6. ROUTER AND PREFIX DISCOVERY....................................35 | 6. Router and Prefix Discovery ....................................38 | |||
6.1. Message Validation........................................36 | 6.1. Message Validation ........................................39 | |||
6.1.1. Validation of Router Solicitation Messages...........36 | 6.1.1. Validation of Router Solicitation Messages .........39 | |||
6.1.2. Validation of Router Advertisement Messages..........36 | 6.1.2. Validation of Router Advertisement Messages ........39 | |||
6.2. Router Specification......................................37 | 6.2. Router Specification ......................................40 | |||
6.2.1. Router Configuration Variables.......................37 | 6.2.1. Router Configuration Variables .....................40 | |||
6.2.2. Becoming An Advertising Interface....................41 | 6.2.2. Becoming an Advertising Interface ..................45 | |||
6.2.3. Router Advertisement Message Content.................42 | 6.2.3. Router Advertisement Message Content ...............45 | |||
6.2.4. Sending Unsolicited Router Advertisements............43 | 6.2.4. Sending Unsolicited Router Advertisements ..........47 | |||
6.2.5. Ceasing To Be An Advertising Interface...............43 | 6.2.5. Ceasing To Be an Advertising Interface .............47 | |||
6.2.6. Processing Router Solicitations......................44 | 6.2.6. Processing Router Solicitations ....................48 | |||
6.2.7. Router Advertisement Consistency.....................45 | 6.2.7. Router Advertisement Consistency ...................50 | |||
6.2.8. Link-local Address Change............................46 | 6.2.8. Link-local Address Change ..........................50 | |||
6.3. Host Specification........................................47 | 6.3. Host Specification ........................................51 | |||
6.3.1. Host Configuration Variables.........................47 | 6.3.1. Host Configuration Variables .......................51 | |||
6.3.2. Host Variables.......................................47 | 6.3.2. Host Variables .....................................51 | |||
6.3.3. Interface Initialization.............................48 | 6.3.3. Interface Initialization ...........................52 | |||
6.3.4. Processing Received Router Advertisements............48 | 6.3.4. Processing Received Router Advertisements ..........53 | |||
6.3.5. Timing out Prefixes and Default Routers..............51 | 6.3.5. Timing out Prefixes and Default Routers ............56 | |||
6.3.6. Default Router Selection.............................51 | 6.3.6. Default Router Selection ...........................56 | |||
6.3.7. Sending Router Solicitations.........................52 | 6.3.7. Sending Router Solicitations .......................57 | |||
7. ADDRESS RESOLUTION AND NEIGHBOR UNREACHABILITY DETECTION.......53 | 7. Address Resolution and Neighbor Unreachability Detection .......59 | |||
7.1. Message Validation........................................54 | 7.1. Message Validation ........................................59 | |||
7.1.1. Validation of Neighbor Solicitations.................54 | 7.1.1. Validation of Neighbor Solicitations ...............59 | |||
7.1.2. Validation of Neighbor Advertisements................55 | 7.1.2. Validation of Neighbor Advertisements ..............60 | |||
7.2. Address Resolution........................................55 | 7.2. Address Resolution ........................................60 | |||
7.2.1. Interface Initialization.............................56 | 7.2.1. Interface Initialization ...........................61 | |||
7.2.2. Sending Neighbor Solicitations.......................56 | 7.2.2. Sending Neighbor Solicitations .....................61 | |||
7.2.3. Receipt of Neighbor Solicitations....................57 | 7.2.3. Receipt of Neighbor Solicitations ..................62 | |||
7.2.4. Sending Solicited Neighbor Advertisements............58 | 7.2.4. Sending Solicited Neighbor Advertisements ..........63 | |||
7.2.5. Receipt of Neighbor Advertisements...................59 | 7.2.5. Receipt of Neighbor Advertisements .................64 | |||
7.2.6. Sending Unsolicited Neighbor Advertisements..........60 | 7.2.6. Sending Unsolicited Neighbor Advertisements ........66 | |||
7.2.7. Anycast Neighbor Advertisements......................62 | 7.2.7. Anycast Neighbor Advertisements ....................67 | |||
7.2.8. Proxy Neighbor Advertisements........................62 | 7.2.8. Proxy Neighbor Advertisements ......................68 | |||
7.3. Neighbor Unreachability Detection.........................63 | 7.3. Neighbor Unreachability Detection .........................68 | |||
7.3.1. Reachability Confirmation............................63 | 7.3.1. Reachability Confirmation ..........................69 | |||
7.3.2. Neighbor Cache Entry States..........................64 | 7.3.2. Neighbor Cache Entry States ........................70 | |||
7.3.3. Node Behavior........................................65 | 7.3.3. Node Behavior ......................................71 | |||
8. REDIRECT FUNCTION..............................................67 | 8. Redirect Function ..............................................73 | |||
8.1. Validation of Redirect Messages...........................67 | 8.1. Validation of Redirect Messages ...........................74 | |||
8.2. Router Specification......................................68 | 8.2. Router Specification ......................................75 | |||
8.3. Host Specification........................................69 | 8.3. Host Specification ........................................76 | |||
9. EXTENSIBILITY - OPTION PROCESSING..............................70 | 9. Extensibility - Option Processing ..............................76 | |||
10. PROTOCOL CONSTANTS............................................71 | 10. Protocol Constants ............................................78 | |||
11. SECURITY CONSIDERATIONS.......................................73 | 11. Security Considerations .......................................79 | |||
11.1 Threat analysis............................................73 | 11.1. Threat Analysis ..........................................79 | |||
11.2 Securing Neighbor Discovery messages.......................74 | 11.2. Securing Neighbor Discovery Messages .....................81 | |||
12. RENUMBERING CONSIDERATIONS....................................75 | 12. Renumbering Considerations ....................................81 | |||
IANA CONSIDERATIONS................................................76 | 13. IANA Considerations ...........................................83 | |||
REFERENCES.........................................................77 | 14. References ....................................................84 | |||
Authors' Addresses.................................................79 | 14.1. Normative References .....................................84 | |||
APPENDIX A: MULTIHOMED HOSTS.......................................80 | 14.2. Informative References ...................................84 | |||
APPENDIX B: FUTURE EXTENSIONS......................................81 | Appendix A: Multihomed Hosts ......................................87 | |||
APPENDIX C: STATE MACHINE FOR THE REACHABILITY STATE...............82 | Appendix B: Future Extensions .....................................88 | |||
APPENDIX D: SUMMARY OF ISROUTER RULES..............................84 | Appendix C: State Machine for the Reachability State ..............89 | |||
APPENDIX E: IMPLEMENTATION ISSUES..................................85 | Appendix D: Summary of IsRouter Rules .............................91 | |||
APPENDIX F: CHANGES FROM RFC 2461..................................86 | Appendix E: Implementation Issues .................................92 | |||
Intellectual Property Statement....................................87 | Appendix F: Changes from RFC 2461 .................................94 | |||
Full Copyright Statement...........................................88 | Acknowledgments ...................................................95 | |||
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 | |||
of which neighbors are reachable and which are not, and to detect | of which neighbors are reachable and which are not, and to detect | |||
changed link-layer addresses. When a router or the path to a router | changed link-layer addresses. When a router or the path to a router | |||
fails, a host actively searches for functioning alternates. | fails, a host actively searches for functioning alternates. | |||
Unless specified otherwise (in a document that covers operating IP | Unless specified otherwise (in a document that covers operating IP | |||
over a particular link type) this document applies to all link types. | over a particular link type) this document applies to all link types. | |||
However, because ND uses link-layer multicast for some of its | However, because ND uses link-layer multicast for some of its | |||
services, it is possible that on some link types (e.g., NBMA links) | services, it is possible that on some link types (e.g., Non-Broadcast | |||
alternative protocols or mechanisms to implement those services will | Multi-Access (NBMA) links), alternative protocols or mechanisms to | |||
be specified (in the appropriate document covering the operation of | implement those services will be specified (in the appropriate | |||
IP over a particular link type). The services described in this | document covering the operation of IP over a particular link type). | |||
document that are not directly dependent on multicast, such as | The services described in this document that are not directly | |||
Redirects, Next-hop determination, Neighbor Unreachability Detection, | dependent on multicast, such as Redirects, Next-hop determination, | |||
etc., are expected to be provided as specified in this document. The | Neighbor Unreachability Detection, etc., are expected to be provided | |||
details of how one uses ND on NBMA links are addressed in [IPv6- | as specified in this document. The details of how one uses ND on | |||
NBMA]. In addition, [IPv6-3GPP] and [IPv6-CELL] discuss the use of | NBMA links are addressed in [IPv6-NBMA]. In addition, [IPv6-3GPP] | |||
this protocol over some cellular links, which are examples of NBMA | and[IPv6-CELL] discuss the use of this protocol over some cellular | |||
links. | links, which are examples of NBMA links. | |||
The authors of RFC 2461 would like to acknowledge the contributions | ||||
of the IPv6 working group and, in particular, (in alphabetical order) | ||||
Ran Atkinson, Jim Bound, Scott Bradner, Alex Conta, Stephen Deering, | ||||
Richard Draves, Francis Dupont, Robert Elz, Robert Gilligan, Robert | ||||
Hinden, Tatuya Jinmei, Allison Mankin, Dan McDonald, Charles Perkins, | ||||
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 | |||
IPv6 are used only in contexts where necessary to avoid | are used only in contexts where necessary to avoid | |||
ambiguity. | ambiguity. | |||
ICMP - Internet Control Message 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-layer (or lower-layer) protocols being | |||
over (i.e., encapsulated in) IP such as IPX, AppleTalk, | "tunneled" over (i.e., encapsulated in) IP such as | |||
or IP itself. | Internetwork Packet Exchange (IPX), AppleTalk, 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-layer (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 | |||
interfaces. | interfaces. | |||
anycast address | anycast address | |||
skipping to change at page 5, line 50 | skipping to change at page 6, line 9 | |||
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 (e.g. | - it is covered by one of the link's prefixes (e.g., | |||
as indicated by the on-link flag in the Prefix | as indicated by the on-link flag in the Prefix | |||
Information option), or | Information option), or | |||
- a neighboring router specifies the address as | - a neighboring router specifies the address as the | |||
the target of a Redirect message, or | 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. | |||
off-link - the opposite of "on-link"; an address that is not | off-link - the opposite of "on-link"; an address that is not | |||
assigned to any interfaces on the specified link. | assigned to any interfaces on the specified link. | |||
longest prefix match | longest prefix match | |||
- The process of determining which prefix (if any) in | - the process of determining which prefix (if any) in a | |||
a set of prefixes covers a target address. A target | set of prefixes covers a target address. A target | |||
address is covered by a prefix if all of the bits in | address is covered by a prefix if all of the bits in | |||
the prefix match the left-most bits of the target | the prefix match the left-most bits of the target | |||
address. When multiple prefixes cover an address, | address. When multiple prefixes cover an address, the | |||
the longest prefix is the one that matches. | longest prefix is the one that matches. | |||
reachability | reachability | |||
- whether or not the one-way "forward" path to a | - whether or not the one-way "forward" path to a neighbor | |||
neighbor is functioning properly. In particular, | is functioning properly. In particular, whether | |||
whether packets sent to a neighbor are reaching the | packets sent to a neighbor are reaching the IP layer on | |||
IP layer on the neighboring machine and are being | the neighboring machine and are being processed | |||
processed properly by the receiving IP layer. For | properly by the receiving IP layer. For neighboring | |||
neighboring routers, reachability means that packets | routers, reachability means that packets sent by a | |||
sent by a node's IP layer are delivered to the | node's IP layer are delivered to the router's IP layer, | |||
router's IP layer, and the router is indeed | and the router is indeed forwarding packets (i.e., it | |||
forwarding packets (i.e., it is configured as a | is configured as a router, not a host). For hosts, | |||
router, not a host). For hosts, reachability means | reachability means that packets sent by a node's IP | |||
that packets sent by a node's IP layer are delivered | 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 | size in octets, that can be conveyed in one | |||
transmission unit over a link. | transmission unit over a link. | |||
target - an address about which address resolution | target - an address about which address resolution information | |||
information is sought, or an address which is the | is sought, or an address that is the new first hop when | |||
new first-hop when being redirected. | being redirected. | |||
proxy - a node 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 | |||
on behalf of a mobile node that has moved off-link | behalf of a mobile node that has moved off-link could | |||
could potentially act as a proxy for the mobile | 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 | |||
of a packet that cannot be delivered for the reasons | 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 | |||
error message is generated. If the error occurs on | error message is generated. If the error occurs on the | |||
the originating node, an implementation is not | originating node, an implementation is not required to | |||
required to actually create and send an ICMP error | actually create and send an ICMP error packet to the | |||
packet to the source, as long as the upper-layer | source, as long as the upper-layer sender is notified | |||
sender is notified through an appropriate mechanism | through an appropriate mechanism (e.g., return value | |||
(e.g., return value from a procedure call). Note, | from a procedure call). Note, however, that an | |||
however, that an implementation may find it | implementation may find it convenient in some cases to | |||
convenient in some cases to return errors to the | return errors to the sender by taking the offending | |||
sender by taking the offending packet, generating an | packet, generating an ICMP error message, and then | |||
ICMP error message, and then delivering it (locally) | delivering it (locally) through the generic error- | |||
through the generic error handling routines. | handling routines. | |||
random delay | random delay | |||
- when sending out messages, it is sometimes necessary to | - when sending out messages, it is sometimes necessary to | |||
delay a transmission for a random amount of time in | delay a transmission for a random amount of time in | |||
order to prevent multiple nodes from transmitting at | order to prevent multiple nodes from transmitting at | |||
exactly the same time, or to prevent long-range | exactly the same time, or to prevent long-range | |||
periodic transmissions from synchronizing with each | periodic transmissions from synchronizing with each | |||
other [SYNC]. When a random component is required, a | other [SYNC]. When a random component is required, a | |||
node calculates the actual delay in such a way that the | node calculates the actual delay in such a way that the | |||
computed delay forms a uniformly-distributed random | computed delay forms a uniformly distributed random | |||
value that falls between the specified minimum and | value that falls between the specified minimum and | |||
maximum delay times. The implementor must take care to | maximum delay times. The implementor must take care to | |||
insure that the granularity of the calculated random | ensure 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 ensure 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 identifier alone as the seed, since interface | interface identifier alone as the seed, since interface | |||
identifiers will not always be unique. To reduce the | identifiers will not always be unique. To reduce the | |||
probability that duplicate interface identifiers cause | probability that duplicate interface identifiers cause | |||
the 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 identifier. Additional information on | interface identifier. Additional information on | |||
randomness and random number generation can be found in | randomness and random number generation can be found in | |||
[RAND]. | [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 | |||
link-layer for sending packets to all (i.e., | layer for sending packets to all (i.e., broadcast) | |||
broadcast) or a subset of all neighbors. | 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 a link-local address. | |||
non-broadcast multi-access (NBMA) | non-broadcast multi-access (NBMA) | |||
- a link to which more than two interfaces can attach, | - a link to which more than two interfaces can attach, | |||
but that does not support a native form of multicast | but that does not support a native form of multicast | |||
or broadcast (e.g., X.25, ATM, frame relay, etc.). | or broadcast (e.g., X.25, ATM, frame relay, etc.). | |||
Note that all link types (including NBMA) are | Note that all link types (including NBMA) are | |||
expected to provide multicast service for | expected to provide multicast service for | |||
applications that need it (e.g., using multicast | applications that need it (e.g., using multicast | |||
servers). However, it is an issue for further study | servers). However, it is an issue for further study | |||
whether ND should use such facilities or an | whether ND should use such facilities or an | |||
alternate mechanism that provides the equivalent | alternate mechanism that provides the equivalent | |||
multicast capability for ND. | multicast capability for ND. | |||
shared media - a link that allows direct communication among a | shared media - a link that allows direct communication among a | |||
number of nodes, but attached nodes are configured | number of nodes, but attached nodes are configured | |||
in such a way that they do not have complete prefix | in such a way that they do not have complete prefix | |||
information for all on-link destinations. That is, | information for all on-link destinations. That is, | |||
at the IP level, nodes on the same link may not know | at the IP level, nodes on the same link may not know | |||
that they are neighbors; by default, they | that they are neighbors; by default, they | |||
communicate through a router. Examples are large | communicate through a router. Examples are large | |||
(switched) public data networks such as SMDS and B- | (switched) public data networks such as Switched | |||
ISDN. Also known as "large clouds". See [SH- | Multimegabit Data Service (SMDS) and Broadband | |||
MEDIA]. | Integrated Services Digital Network (B-ISDN). Also | |||
known as "large clouds". See [SH-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. | |||
2.3. Addresses | 2.3. Addresses | |||
Neighbor Discovery makes use of a number of different addresses | Neighbor Discovery makes use of a number of different addresses | |||
defined in [ADDR-ARCH], including: | defined in [ADDR-ARCH], including: | |||
skipping to change at page 9, line 22 | skipping to change at page 9, line 38 | |||
FF02::1. | FF02::1. | |||
all-routers multicast address | all-routers multicast address | |||
- the link-local scope address to reach all routers, | - the link-local scope address to reach all routers, | |||
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 that differ only in the | |||
most significant bits, e.g., due to multiple | most significant bits, e.g., due to multiple prefixes | |||
prefixes associated with different providers, will map | associated with different providers, will map to the | |||
to the same solicited-node address thereby reducing the | same solicited-node address thereby reducing the number | |||
number of multicast addresses a node must join at the | of multicast addresses a node must join at the link | |||
link-layer. | 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 | |||
skipping to change at page 10, line 14 | skipping to change at page 10, line 35 | |||
This document also makes use of internal conceptual variables to | This document also makes use of internal conceptual variables to | |||
describe protocol behavior and external variables that an | describe protocol behavior and external variables that an | |||
implementation must allow system administrators to change. The | implementation must allow system administrators to change. The | |||
specific variable names, how their values change, and how their | specific variable names, how their values change, and how their | |||
settings influence protocol behavior are provided to demonstrate | settings influence protocol behavior are provided to demonstrate | |||
protocol behavior. An implementation is not required to have them in | protocol behavior. An implementation is not required to have them in | |||
the exact form described here, so long as its external behavior is | the exact form described here, so long as its external behavior is | |||
consistent with that described in this document. | consistent with that described in this document. | |||
3. PROTOCOL OVERVIEW | 3. Protocol Overview | |||
This protocol solves a set of problems related to the interaction | This protocol solves a set of problems related to the interaction | |||
between nodes attached to the same link. It defines mechanisms for | between nodes attached to the same link. It defines mechanisms for | |||
solving each of the following problems: | solving each of the following problems: | |||
Router Discovery: How hosts locate routers that reside on an | Router Discovery: How hosts locate routers that reside on an | |||
attached link. | attached link. | |||
Prefix Discovery: How hosts discover the set of address prefixes | Prefix Discovery: How hosts discover the set of address prefixes | |||
that define which destinations are on-link for an | that define which destinations are on-link for an | |||
attached link. (Nodes use prefixes to distinguish | attached link. (Nodes use prefixes to distinguish | |||
destinations that reside on-link from those only | destinations that reside on-link from those only | |||
reachable through a router.) | reachable through a router.) | |||
Parameter Discovery: How a node learns such link parameters as the | Parameter Discovery: How a node learns link parameters (such as the | |||
link MTU or such Internet parameters as the hop limit | link MTU) or Internet parameters (such 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 configure an address for an | order to allow nodes to configure an address for an | |||
interface in a stateless manner. Stateless address | interface in a stateless manner. Stateless address | |||
autoconfiguration is specified in [ADDRCONF]. | 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. | |||
skipping to change at page 10, line 54 | skipping to change at page 11, line 26 | |||
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 whether or not | Duplicate Address Detection: How a node determines whether or not | |||
an address it wishes to use is already in use by | an address it wishes to use is already in use by another | |||
another node. | 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 determining whether another address | are used for determining whether another address shares | |||
shares the same link (on-link determination) and/or | the same link (on-link determination) and/or address | |||
address configuration, a suggested hop limit value, etc. | 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 12, line 5 | skipping to change at page 12, line 34 | |||
detect router failure; a separate Neighbor Unreachability Detection | detect router failure; a separate Neighbor Unreachability Detection | |||
algorithm provides failure detection. | algorithm provides failure detection. | |||
Router Advertisements contain a list of prefixes used for on-link | Router Advertisements contain a list of prefixes used for on-link | |||
determination and/or autonomous address configuration; flags | determination and/or autonomous address configuration; flags | |||
associated with the prefixes specify the intended uses of a | associated with the prefixes specify the intended uses of a | |||
particular prefix. Hosts use the advertised on-link prefixes to | particular prefix. Hosts use the advertised on-link prefixes to | |||
build and maintain a list that is used in deciding when a packet's | build and maintain a list that is used in deciding when a packet's | |||
destination is on-link or beyond a router. Note that a destination | destination is on-link or beyond a router. Note that a destination | |||
can be on-link even though it is not covered by any advertised on- | can be on-link even though it is not covered by any advertised on- | |||
link prefix. In such cases a router can send a Redirect informing | link prefix. In such cases, a router can send a Redirect informing | |||
the sender that the destination is a neighbor. | the sender that the destination is a neighbor. | |||
Router Advertisements (and per-prefix flags) allow routers to inform | Router Advertisements (and per-prefix flags) allow routers to inform | |||
hosts how to perform Address Autoconfiguration. For example, routers | hosts how to perform Address Autoconfiguration. For example, routers | |||
can specify whether hosts should use DHCPv6 and/or | can specify whether hosts should use DHCPv6 and/or autonomous | |||
autonomous (stateless) address configuration. | (stateless) address configuration. | |||
Router Advertisement messages also contain Internet parameters such | Router Advertisement messages also contain Internet parameters such | |||
as the hop limit that hosts should use in outgoing packets and, | as the hop limit that hosts should use in outgoing packets and, | |||
optionally, link parameters such as the link MTU. This facilitates | optionally, link parameters such as the link MTU. This facilitates | |||
centralized administration of critical parameters that can be set on | centralized administration of critical parameters that can be set on | |||
routers and automatically propagated to all attached hosts. | routers and automatically propagated to all attached hosts. | |||
Nodes accomplish address resolution by multicasting a Neighbor | Nodes accomplish address resolution by multicasting a Neighbor | |||
Solicitation that asks the target node to return its link-layer | Solicitation that asks the target node to return its link-layer | |||
address. Neighbor Solicitation messages are multicast to the | address. Neighbor Solicitation messages are multicast to the | |||
skipping to change at page 13, line 19 | skipping to change at page 14, line 5 | |||
delay may be somewhat longer. | delay may be somewhat longer. | |||
Inbound load balancing - Nodes with replicated interfaces may want | Inbound load balancing - Nodes with replicated interfaces may want | |||
to load balance the reception of incoming packets across | to load balance the reception of incoming packets across | |||
multiple network interfaces on the same link. Such nodes | multiple network interfaces on the same link. Such nodes | |||
have multiple link-layer addresses assigned to the same | have multiple link-layer addresses assigned to the same | |||
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, e.g., | contain link-layer addresses that differ depending on, e.g., | |||
who issued the solicitation. This specification does not | who issued the solicitation. This specification does not | |||
define a mechanism that allows hosts to Load-balance | define a mechanism that allows hosts to Load-balance incoming | |||
incoming packets. See [LD-SHRE]. | packets. See [LD-SHRE]. | |||
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. A non-Override | tagged as being non-Override advertisements. A non-Override | |||
advertisement is one that does not update or replace the | advertisement is one that does not update or replace the | |||
information sent by another advertisement. These | information sent by another advertisement. These | |||
advertisements are discussed later in the context of Neighbor | advertisements are discussed later in the context of Neighbor | |||
advertisement messages. This invokes specific rules to | advertisement messages. This invokes specific rules to | |||
determine which of potentially multiple advertisements should | determine which of potentially multiple advertisements should | |||
be used. | be used. | |||
Proxy advertisements - A node 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 | |||
the IPv4 protocols ARP [ARP], ICMP Router Discovery [RDISC], and ICMP | the IPv4 protocols Address Resolution Protocol [ARP], ICMP Router | |||
Redirect [ICMPv4]. In IPv4 there is no generally agreed upon | Discovery [RDISC], and ICMP Redirect [ICMPv4]. In IPv4 there is no | |||
protocol or mechanism for Neighbor Unreachability Detection, although | generally agreed upon protocol or mechanism for Neighbor | |||
Hosts Requirements [HR-CL] does specify some possible algorithms for | Unreachability Detection, although the Hosts Requirements document | |||
Dead Gateway Detection (a subset of the problems Neighbor | [HR-CL] does specify some possible algorithms for Dead Gateway | |||
Unreachability Detection tackles). | Detection (a subset of the problems Neighbor Unreachability Detection | |||
tackles). | ||||
The Neighbor Discovery protocol provides a multitude of improvements | The Neighbor Discovery protocol provides a multitude of improvements | |||
over the IPv4 set of protocols: | over the IPv4 set of protocols: | |||
Router Discovery is part of the base protocol set; there is no | Router Discovery is part of the base protocol set; there is no | |||
need for hosts to "snoop" the routing protocols. | need for hosts to "snoop" the routing protocols. | |||
Router advertisements carry link-layer addresses; no additional | Router Advertisements carry link-layer addresses; no additional | |||
packet exchange is needed to resolve the router's link-layer | packet exchange is needed to resolve the router's link-layer | |||
address. | address. | |||
Router advertisements carry prefixes for a link; there is no need | Router Advertisements carry prefixes for a link; there is no need | |||
to have a separate mechanism to configure the "netmask". | to have a separate mechanism to configure the "netmask". | |||
Router advertisements enable Address Autoconfiguration. | Router Advertisements enable Address Autoconfiguration. | |||
Routers can advertise an MTU for hosts to use on the link, | Routers can advertise an MTU for hosts to use on the link, | |||
ensuring that all nodes use the same MTU value on links lacking a | ensuring that all nodes use the same MTU value on links lacking a | |||
well-defined MTU. | well-defined MTU. | |||
Address resolution multicasts are "spread" over 16 million (2^24) | Address resolution multicasts are "spread" over 16 million (2^24) | |||
multicast addresses greatly reducing address resolution related | multicast addresses, greatly reducing address-resolution-related | |||
interrupts on nodes other than the target. Moreover, non-IPv6 | interrupts on nodes other than the target. Moreover, non-IPv6 | |||
machines should not be interrupted at all. | machines should not be interrupted at all. | |||
Redirects contain the link-layer address of the new first hop; | Redirects contain the link-layer address of the new first hop; | |||
separate address resolution is not needed upon receiving a | separate address resolution is not needed upon receiving a | |||
redirect. | redirect. | |||
Multiple prefixes can be associated with the same link. By | Multiple prefixes can be associated with the same link. By | |||
default, hosts learn all on-link prefixes from Router | default, hosts learn all on-link prefixes from Router | |||
Advertisements. However, routers may be configured to omit some | Advertisements. However, routers may be configured to omit some | |||
skipping to change at page 15, line 8 | skipping to change at page 15, line 52 | |||
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, which | Neighbor Unreachability Detection is part of the base, which | |||
significantly improves 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, or 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 | |||
do not contain a preference field. The preference field is not | do not contain a preference field. The preference field is not | |||
needed to handle routers of different "stability"; the Neighbor | needed to handle routers of different "stability"; the Neighbor | |||
Unreachability Detection will detect dead routers and switch to a | Unreachability Detection will detect dead routers and switch to a | |||
working one. | working one. | |||
The use of link-local addresses to uniquely identify routers (for | The use of link-local addresses to uniquely identify routers (for | |||
Router Advertisement and Redirect messages) makes it possible for | Router Advertisement and Redirect messages) makes it possible for | |||
hosts to maintain the router associations in the event of the site | hosts to maintain the router associations in the event of the site | |||
renumbering to use new global prefixes. | renumbering to use new global prefixes. | |||
By setting the Hop Limit to 255, Neighbor Discovery is immune to | By setting the Hop Limit to 255, Neighbor Discovery is immune to | |||
off-link senders that accidentally or intentionally send ND | off-link senders that accidentally or intentionally send ND | |||
messages. In IPv4 off-link senders can send both ICMP Redirects | messages. In IPv4, off-link senders can send both ICMP Redirects | |||
and Router Advertisement messages. | and Router Advertisement messages. | |||
Placing address resolution at the ICMP layer makes the protocol | Placing address resolution at the ICMP layer makes the protocol | |||
more media-independent than ARP and makes it possible to use | more media-independent than ARP and makes it possible to use | |||
generic IP layer authentication and security mechanisms as | generic IP-layer authentication and security mechanisms as | |||
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.) | can be assigned link-local addresses.) | |||
multicast - Neighbor Discovery operates over multicast capable | multicast - Neighbor Discovery operates over multicast capable | |||
links as 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 are | |||
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 16, line 34 | skipping to change at page 17, line 32 | |||
of a host, which it needs to send redirect | of a host, which it needs to send redirect | |||
messages to the host. | messages to the host. | |||
- How a router determines that it is the first- | - How a router determines that it is the first- | |||
hop router for a received packet. | hop router for a received packet. | |||
The protocol is extensible (through the definition | The protocol is extensible (through the definition | |||
of new options) so that other solutions might be | of new options) so that other solutions might be | |||
possible in the future. | possible in the future. | |||
variable MTU - Neighbor Discovery allows routers to specify a MTU | variable MTU - Neighbor Discovery allows routers to specify an | |||
for the link, which all nodes then use. All nodes | MTU for the link, which all nodes then use. All | |||
on a link must use the same MTU (or Maximum | nodes on a link must use the same MTU (or Maximum | |||
Receive Unit) in order for multicast to work | Receive Unit) in order for multicast to work | |||
properly. Otherwise when multicasting, a sender, | properly. Otherwise, when multicasting, a sender, | |||
which can not know which nodes will receive the | which can not know which nodes will receive the | |||
packet, could not determine a minimum packet size | packet, could not determine a minimum packet size | |||
that all receivers can process (or Maximum Receive | that all receivers can process (or Maximum Receive | |||
Unit). | Unit). | |||
asymmetric reachability | asymmetric reachability | |||
- Neighbor Discovery detects the absence of | - Neighbor Discovery detects the absence of | |||
symmetric reachability; a node avoids paths to a | symmetric reachability; a node avoids paths to a | |||
neighbor with which it does not have symmetric | neighbor with which it does not have symmetric | |||
connectivity. | connectivity. | |||
The Neighbor Unreachability Detection will | The Neighbor Unreachability Detection will | |||
typically identify such half-links and the node | typically identify such half-links and the node | |||
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. | |||
functions are designed to allow hosts to ascertain the ownership of | Several functions are designed to allow hosts to ascertain the | |||
an address or the mapping between link-layer and IP layer addresses. | ownership of an address or the mapping between link-layer and IP- | |||
Vulnerabilities related to Neighbor Discovery are discussed in | layer addresses. Vulnerabilities related to Neighbor Discovery are | |||
section 11.1. A general solution for securing Neighbor Discovery is | discussed in Section 11.1. A general solution for securing Neighbor | |||
outside the scope of this specification and is discussed in [SEND]. | Discovery is outside the scope of this specification and is discussed | |||
However, Section 11.2 explains how and under which constraints IPsec | in [SEND]. However, Section 11.2 explains how and under which | |||
AH or ESP can be used to secure Neighbor Discovery. | constraints IPsec Authentication Header (AH) or Encapsulating | |||
Security Payload (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 | This section introduces message formats for all messages used in this | |||
specification. | 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 | |||
skipping to change at page 17, line 49 | skipping to change at page 19, line 4 | |||
Source Address | Source Address | |||
An IP address assigned to the sending interface, or | An IP address assigned to the sending interface, or | |||
the unspecified address if no address is assigned | the unspecified address if no address is assigned | |||
to the sending interface. | to the sending interface. | |||
Destination Address | Destination Address | |||
Typically the all-routers multicast address. | Typically the all-routers multicast address. | |||
Hop Limit 255 | Hop Limit 255 | |||
ICMP Fields: | ICMP Fields: | |||
Type 133 | Type 133 | |||
Code 0 | Code 0 | |||
Checksum The ICMP checksum. See [ICMPv6]. | Checksum The ICMP checksum. See [ICMPv6]. | |||
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 | |||
The link-layer address of the sender, if known. | known. MUST NOT be included if the Source Address | |||
MUST NOT be included if the Source Address is the | is the unspecified address. Otherwise, it SHOULD | |||
unspecified address. Otherwise it SHOULD be | 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 messages periodically, or in | |||
response to a Router Solicitation. | response to Router Solicitations. | |||
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 | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Cur Hop Limit |M|O| Reserved | Router Lifetime | | | Cur Hop Limit |M|O| Reserved | Router Lifetime | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Reachable Time | | | Reachable Time | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
skipping to change at page 19, line 24 | skipping to change at page 20, line 32 | |||
means unspecified (by this router). | means unspecified (by this router). | |||
M 1-bit "Managed address configuration" flag. When | M 1-bit "Managed address configuration" flag. When | |||
set, it indicates that addresses are available via | set, it indicates that addresses are available via | |||
Dynamic Host Configuration Protocol [DHCPv6]. | Dynamic Host Configuration Protocol [DHCPv6]. | |||
If the M flag is set, the O flag is redundant and | If the M flag is set, the O flag is redundant and | |||
can be ignored because DHCPv6 will return all | can be ignored because DHCPv6 will return all | |||
available configuration information. | available configuration information. | |||
O 1-bit "Other configuration" flag. When | O 1-bit "Other configuration" flag. When set, it | |||
set, it indicates that other configuration | indicates that other configuration information is | |||
information is available via DHCPv6. | available via DHCPv6. Examples of such information | |||
Examples of such information are DNS-related | are DNS-related information or information on other | |||
information or information on other servers within | servers within the network. | |||
the network. | ||||
Note: If neither M nor O flags are set this indicates that no | Note: If neither M nor O flags are set, this indicates that no | |||
information is available via DHCPv6. | information is available via DHCPv6. | |||
Reserved A 6-bit unused field. It MUST be initialized to | Reserved A 6-bit unused field. It MUST be initialized to | |||
zero by the sender and MUST be ignored by the | zero by the sender and MUST be ignored by the | |||
receiver. | receiver. | |||
Router Lifetime | Router Lifetime | |||
16-bit unsigned integer. The lifetime associated | 16-bit unsigned integer. The lifetime associated | |||
with the default router in units of seconds. | with the default router in units of seconds. The | |||
The field can contain values up to 65535 and | field can contain values up to 65535 and receivers | |||
receivers should handle any value, while the | should handle any value, while the sending rules in | |||
sending rules in section 6 limit the lifetime to | Section 6 limit the lifetime to 9000 seconds. A | |||
9000 seconds. A Lifetime of 0 indicates that the | Lifetime of 0 indicates that the router is not a | |||
router is not a default router and SHOULD NOT | default router and SHOULD NOT appear on the default | |||
appear on the default router list. The Router | router list. The Router Lifetime applies only to | |||
Lifetime applies only to the router's usefulness as | the router's usefulness as a default router; it | |||
a default router; it does not apply to information | does not apply to information contained in other | |||
contained in other message fields or options. | message fields or options. Options that need time | |||
Options that need time limits for their information | limits for their information include their own | |||
include their own lifetime fields. | lifetime fields. | |||
Reachable Time 32-bit unsigned integer. The time, in | Reachable Time 32-bit unsigned integer. The time, in | |||
milliseconds, that a node assumes a neighbor is | milliseconds, that a node assumes a neighbor is | |||
reachable after having received a reachability | reachable after having received a reachability | |||
confirmation. Used by the Neighbor Unreachability | confirmation. Used by the Neighbor Unreachability | |||
Detection algorithm (see Section 7.3). A value of | Detection algorithm (see Section 7.3). A value of | |||
zero means unspecified (by this router). | zero means unspecified (by this router). | |||
Retrans Timer 32-bit unsigned integer. The time, in | Retrans Timer 32-bit unsigned integer. The time, in | |||
milliseconds, between retransmitted Neighbor | milliseconds, between retransmitted Neighbor | |||
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 | |||
skipping to change at page 21, line 39 | skipping to change at page 23, line 4 | |||
Either the solicited-node multicast address | Either the solicited-node multicast address | |||
corresponding to the target address, or the target | corresponding to the target address, or the target | |||
address. | address. | |||
Hop Limit 255 | Hop Limit 255 | |||
ICMP Fields: | ICMP Fields: | |||
Type 135 | Type 135 | |||
Code 0 | Code 0 | |||
Checksum The ICMP checksum. See [ICMPv6]. | Checksum The ICMP checksum. See [ICMPv6]. | |||
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. | |||
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 23, line 53 | skipping to change at page 25, line 22 | |||
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 | |||
sender of the solicitation has the correct link- | sender of the solicitation has the correct link- | |||
layer address; otherwise it would not be able | layer address; otherwise, it would not be able to | |||
to send the unicast solicitation in the first | send the unicast solicitation in the first place. | |||
place. However, including the link-layer address in | However, including the link-layer address in this | |||
this case adds little overhead and eliminates a | case adds little overhead and eliminates a | |||
potential race condition where the sender deletes | potential race condition where the sender deletes | |||
the cached link-layer address prior to receiving a | the cached link-layer address prior to receiving a | |||
response to a previous solicitation. | response to a previous solicitation. | |||
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.5. Redirect Message Format | 4.5. Redirect Message Format | |||
skipping to change at page 25, line 33 | skipping to change at page 27, line 16 | |||
Type 137 | Type 137 | |||
Code 0 | Code 0 | |||
Checksum The ICMP checksum. See [ICMPv6]. | Checksum The ICMP checksum. See [ICMPv6]. | |||
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. | |||
Target Address An IP address that is a better first hop to use for | Target Address | |||
An IP address that is a better first hop to use for | ||||
the ICMP Destination Address. When the target is | the ICMP Destination Address. When the target is | |||
the actual endpoint of communication, i.e., the | the actual endpoint of communication, i.e., the | |||
destination is a neighbor, the Target Address field | destination is a neighbor, the Target Address field | |||
MUST contain the same value as the ICMP Destination | MUST contain the same value as the ICMP Destination | |||
Address field. Otherwise the target is a better | Address field. Otherwise, the target is a better | |||
first-hop router and the Target Address MUST be the | first-hop router and the Target Address MUST be the | |||
router's link-local address so that hosts can | router's link-local address so that hosts can | |||
uniquely identify routers. | uniquely identify routers. | |||
Destination Address | Destination Address | |||
The IP address of the destination which is | The IP address of the destination that is | |||
redirected to the target. | redirected to the target. | |||
Possible options: | Possible options: | |||
Target link-layer address | Target link-layer address | |||
The link-layer address for the target. It SHOULD | The link-layer address for the target. It SHOULD | |||
be included (if known). Note that on NBMA links, | be included (if known). Note that on NBMA links, | |||
hosts may rely on the presence of the Target Link- | hosts may rely on the presence of the Target Link- | |||
Layer Address option in Redirect messages as the | Layer Address option in Redirect messages as the | |||
means for determining the link-layer addresses of | means for determining the link-layer addresses of | |||
skipping to change at page 26, line 17 | skipping to change at page 28, line 9 | |||
Redirected Header | Redirected Header | |||
As much as possible of the IP packet that triggered | As much as possible of the IP packet that triggered | |||
the sending of the Redirect without making the | the sending of the Redirect without making the | |||
redirect packet exceed the minimum MTU specified in | redirect packet exceed the minimum MTU specified in | |||
[IPv6]. | [IPv6]. | |||
4.6. Option Formats | 4.6. Option Formats | |||
Neighbor Discovery messages include zero or more options, some of | Neighbor Discovery messages include zero or more options, some of | |||
which may appear multiple times in the same message. Options should | which may appear multiple times in the same message. Options should | |||
be padded when necessary to ensure that they end on their natural 64- | be padded when necessary to ensure that they end on their natural | |||
bit boundaries. All options are of the form: | 64-bit boundaries. All options are of the form: | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Type | Length | ... | | | Type | Length | ... | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
~ ... ~ | ~ ... ~ | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Fields: | Fields: | |||
skipping to change at page 27, line 4 | skipping to change at page 28, line 46 | |||
silently discard an ND packet that contains an | silently discard an ND packet that contains an | |||
option with length zero. | option with length zero. | |||
4.6.1. Source/Target Link-layer Address | 4.6.1. Source/Target Link-layer Address | |||
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 | Link-Layer Address ... | | Type | Length | Link-Layer Address ... | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Fields: | Fields: | |||
Type | Type | |||
1 for Source Link-layer Address | 1 for Source Link-layer Address | |||
2 for Target Link-layer Address | 2 for Target Link-layer Address | |||
Length The length of the option (including the type and | Length The length of the option (including the type and | |||
length fields) in units of 8 octets. 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 | |||
ETHER]. | [IPv6-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 30, line 41 | skipping to change at page 32, line 44 | |||
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. | |||
MTU 32-bit unsigned integer. The recommended MTU for | MTU 32-bit unsigned integer. The recommended MTU for | |||
the link. | the link. | |||
Description | Description | |||
The MTU option is used in Router Advertisement | The MTU option is used in Router Advertisement | |||
messages to insure that all nodes on a link use the | messages to ensure that all nodes on a link use the | |||
same MTU value in those cases where the link MTU is | same MTU value in those cases where the link MTU is | |||
not well known. | not well known. | |||
This option MUST be silently ignored for other | This option MUST be silently ignored for other | |||
Neighbor Discovery messages. | Neighbor Discovery messages. | |||
In configurations in which heterogeneous | In configurations in which heterogeneous | |||
technologies are bridged together, the maximum | technologies are bridged together, the maximum | |||
supported MTU may differ from one segment to | supported MTU may differ from one segment to | |||
another. If the bridges do not generate ICMP | another. If the bridges do not generate ICMP | |||
Packet Too Big messages, communicating nodes will | Packet Too Big messages, communicating nodes will | |||
be unable to use Path MTU to dynamically determine | be unable to use Path MTU to dynamically determine | |||
the appropriate MTU on a per-neighbor basis. In | the appropriate MTU on a per-neighbor basis. In | |||
such cases, routers can be configured to use the | such cases, routers can be configured to use the | |||
MTU option to specify the maximum MTU value that is | MTU option to specify the maximum MTU value that is | |||
supported by all segments. | supported by all segments. | |||
5. CONCEPTUAL MODEL OF A HOST | 5. Conceptual Model of a Host | |||
This section describes a conceptual model of one possible data | This section describes a conceptual model of one possible data | |||
structure organization that hosts (and to some extent routers) will | structure organization that hosts (and, to some extent, routers) will | |||
maintain in interacting with neighboring nodes. The described | maintain in interacting with neighboring nodes. The described | |||
organization is provided to facilitate the explanation of how the | organization is provided to facilitate the explanation of how the | |||
Neighbor Discovery protocol should behave. This document does not | Neighbor Discovery protocol should behave. This document does not | |||
mandate that implementations adhere to this model as long as their | mandate that implementations adhere to this model as long as their | |||
external behavior is consistent with that described in this document. | external behavior is consistent with that described in this document. | |||
This model is only concerned with the aspects of host behavior | This model is only concerned with the aspects of host behavior | |||
directly related to Neighbor Discovery. In particular, it does not | directly related to Neighbor Discovery. In particular, it does not | |||
concern itself with such issues as source address selection or the | concern itself with such issues as source address selection or the | |||
selecting of an outgoing interface on a multihomed host. | selecting of an outgoing interface on a multihomed host. | |||
skipping to change at page 31, line 36 | skipping to change at page 33, line 44 | |||
each interface: | each interface: | |||
Neighbor Cache | Neighbor Cache | |||
- A set of entries about individual neighbors to | - A set of entries about individual neighbors to | |||
which traffic has been sent recently. Entries are | which traffic has been sent recently. Entries are | |||
keyed on the neighbor's on-link unicast IP address | keyed on the neighbor's on-link unicast IP address | |||
and contain such information as its link-layer | and contain such information as its link-layer | |||
address, a flag indicating whether the neighbor is | address, a flag indicating whether the neighbor is | |||
a router or a host (called IsRouter in this | a router or a host (called IsRouter in this | |||
document), a pointer to any queued packets waiting | document), a pointer to any queued packets waiting | |||
for address resolution to complete, etc. | for address resolution to complete, etc. A | |||
A Neighbor Cache entry also contains information | Neighbor Cache entry also contains information used | |||
used by the Neighbor Unreachability Detection | by the Neighbor Unreachability Detection algorithm, | |||
algorithm, including the reachability state, the | including the reachability state, the number of | |||
number of unanswered probes, and the time the next | unanswered probes, and the time the next Neighbor | |||
Neighbor Unreachability Detection event is | Unreachability Detection event is scheduled to take | |||
scheduled to take place. | place. | |||
Destination Cache | Destination Cache | |||
- A set of entries about destinations to which | - A set of entries about destinations to which | |||
traffic has been sent recently. The Destination | traffic has been sent recently. The Destination | |||
Cache includes both on-link and off-link | Cache includes both on-link and off-link | |||
destinations and provides a level of indirection | destinations and provides a level of indirection | |||
into the Neighbor Cache; the Destination Cache maps | into the Neighbor Cache; the Destination Cache maps | |||
a destination IP address to the IP address of the | a destination IP address to the IP address of the | |||
next-hop neighbor. This cache is updated with | next-hop neighbor. This cache is updated with | |||
information learned from Redirect messages. | information learned from Redirect messages. | |||
Implementations may find it convenient to store | Implementations may find it convenient to store | |||
additional information not directly related to | additional information not directly related to | |||
Neighbor Discovery in Destination Cache entries, | Neighbor Discovery in Destination Cache entries, | |||
such as the Path MTU (PMTU) and round trip timers | such as the Path MTU (PMTU) and round-trip timers | |||
maintained by transport protocols. | maintained by transport protocols. | |||
Prefix List - A list of the prefixes that define a set of | Prefix List - A list of the prefixes that define a set of | |||
addresses that are on-link. Prefix List entries | addresses that are on-link. Prefix List entries | |||
are created from information received in Router | are created from information received in Router | |||
Advertisements. Each entry has an associated | Advertisements. Each entry has an associated | |||
invalidation timer value (extracted from the | invalidation timer value (extracted from the | |||
advertisement) used to expire prefixes when they | advertisement) used to expire prefixes when they | |||
become invalid. A special "infinity" timer value | become invalid. A special "infinity" timer value | |||
specifies that a prefix remains valid forever, | specifies that a prefix remains valid forever, | |||
skipping to change at page 33, line 20 | skipping to change at page 35, line 39 | |||
reachable recently (within tens of seconds ago). | reachable recently (within tens of seconds ago). | |||
STALE The neighbor is no longer known to be reachable but | STALE The neighbor is no longer known to be reachable but | |||
until traffic is sent to the neighbor, no attempt | until traffic is sent to the neighbor, no attempt | |||
should be made to verify its reachability. | should be made to verify its reachability. | |||
DELAY The neighbor is no longer known to be reachable, and | DELAY The neighbor is no longer known to be reachable, and | |||
traffic has recently been sent to the neighbor. | traffic has recently been sent to the neighbor. | |||
Rather than probe the neighbor immediately, however, | Rather than probe the neighbor immediately, however, | |||
delay sending probes for a short while in order to | delay sending probes for a short while in order to | |||
give upper layer protocols a chance to provide | give upper-layer protocols a chance to provide | |||
reachability confirmation. | reachability confirmation. | |||
PROBE The neighbor is no longer known to be reachable, and | PROBE The neighbor is no longer known to be reachable, and | |||
unicast Neighbor Solicitation probes are being sent to | unicast Neighbor Solicitation probes are being sent to | |||
verify reachability. | verify reachability. | |||
5.2. Conceptual Sending Algorithm | 5.2. Conceptual Sending Algorithm | |||
When sending a packet to a destination, a node uses a combination of | When sending a packet to a destination, a node uses a combination of | |||
the Destination Cache, the Prefix List, and the Default Router List | the Destination Cache, the Prefix List, and the Default Router List | |||
skipping to change at page 34, line 13 | skipping to change at page 36, line 42 | |||
neighbor. If no entry exists, the sender creates one, sets its state | neighbor. If no entry exists, the sender creates one, sets its state | |||
to INCOMPLETE, initiates Address Resolution, and then queues the data | to INCOMPLETE, initiates Address Resolution, and then queues the data | |||
packet pending completion of address resolution. For multicast- | packet pending completion of address resolution. For multicast- | |||
capable interfaces Address Resolution consists of sending a Neighbor | capable interfaces Address Resolution consists of sending a Neighbor | |||
Solicitation message and waiting for a Neighbor Advertisement. When | Solicitation message and waiting for a Neighbor Advertisement. When | |||
a Neighbor Advertisement response is received, the link-layer | a Neighbor Advertisement response is received, the link-layer | |||
addresses is entered in the Neighbor Cache entry and the queued | addresses is entered in the Neighbor Cache entry and the queued | |||
packet is transmitted. The address resolution mechanism is described | packet is transmitted. The address resolution mechanism is described | |||
in detail in Section 7.2. | in detail in Section 7.2. | |||
For multicast packets the next-hop is always the (multicast) | For multicast packets, the next-hop is always the (multicast) | |||
destination address and is considered to be on-link. The procedure | destination address and is considered to be on-link. The procedure | |||
for determining the link-layer address corresponding to a given IP | for determining the link-layer address corresponding to a given IP | |||
multicast address can be found in a separate document that covers | multicast address can be found in a separate document that covers | |||
operating IP over a particular link type (e.g., [IPv6-ETHER]). | operating IP over a particular link type (e.g., [IPv6-ETHER]). | |||
Each time a Neighbor Cache entry is accessed while transmitting a | Each time a Neighbor Cache entry is accessed while transmitting a | |||
unicast packet, the sender checks Neighbor Unreachability Detection | unicast packet, the sender checks Neighbor Unreachability Detection | |||
related information according to the Neighbor Unreachability | related information according to the Neighbor Unreachability | |||
Detection algorithm (Section 7.3). This unreachability check might | Detection algorithm (Section 7.3). This unreachability check might | |||
result in the sender transmitting a unicast Neighbor Solicitation to | result in the sender transmitting a unicast Neighbor Solicitation to | |||
skipping to change at page 34, line 39 | skipping to change at page 37, line 25 | |||
used. If at some point communication ceases to proceed, as | used. If at some point communication ceases to proceed, as | |||
determined by the Neighbor Unreachability Detection algorithm, next- | determined by the Neighbor Unreachability Detection algorithm, next- | |||
hop determination may need to be performed again. For example, | hop determination may need to be performed again. For example, | |||
traffic through a failed router should be switched to a working | traffic through a failed router should be switched to a working | |||
router. Likewise, it may be possible to reroute traffic destined for | router. Likewise, it may be possible to reroute traffic destined for | |||
a mobile node to a "mobility agent". | a mobile node to a "mobility agent". | |||
Note that when a node redoes next-hop determination there is no need | Note that when a node redoes next-hop determination there is no need | |||
to discard the complete Destination Cache entry. In fact, it is | to discard the complete Destination Cache entry. In fact, it is | |||
generally beneficial to retain such cached information as the PMTU | generally beneficial to retain such cached information as the PMTU | |||
and round trip timer values that may also be kept in the Destination | and round-trip timer values that may also be kept in the Destination | |||
Cache entry. | Cache entry. | |||
Routers and multihomed hosts have multiple interfaces. The remainder | Routers and multihomed hosts have multiple interfaces. The remainder | |||
of this document assumes that all sent and received Neighbor | of this document assumes that all sent and received Neighbor | |||
Discovery messages refer to the interface of appropriate context. | Discovery messages refer to the interface of appropriate context. | |||
For example, when responding to a Router Solicitation, the | For example, when responding to a Router Solicitation, the | |||
corresponding Router Advertisement is sent out the interface on which | corresponding Router Advertisement is sent out the interface on which | |||
the solicitation was received. | the solicitation was received. | |||
5.3. Garbage Collection and Timeout Requirements | 5.3. Garbage Collection and Timeout Requirements | |||
The conceptual data structures described above use different | The conceptual data structures described above use different | |||
mechanisms for discarding potentially stale or unused information. | mechanisms for discarding potentially stale or unused information. | |||
From the perspective of correctness there is no need to periodically | From the perspective of correctness, there is no need to periodically | |||
purge Destination and Neighbor Cache entries. Although stale | purge Destination and Neighbor Cache entries. Although stale | |||
information can potentially remain in the cache indefinitely, the | information can potentially remain in the cache indefinitely, the | |||
Neighbor Unreachability Detection algorithm ensures that stale | Neighbor Unreachability Detection algorithm ensures that stale | |||
information is purged quickly if it is actually being used. | information is purged quickly if it is actually being used. | |||
To limit the storage needed for the Destination and Neighbor Caches, | To limit the storage needed for the Destination and Neighbor Caches, | |||
a node may need to garbage-collect old entries. However, care must | a node may need to garbage-collect old entries. However, care must | |||
be taken to insure that sufficient space is always present to hold | be taken to ensure that sufficient space is always present to hold | |||
the working set of active entries. A small cache may result in an | the working set of active entries. A small cache may result in an | |||
excessive number of Neighbor Discovery messages if entries are | excessive number of Neighbor Discovery messages if entries are | |||
discarded and rebuilt in quick succession. Any LRU-based policy that | discarded and rebuilt in quick succession. Any Least Recently Used | |||
only reclaims entries that have not been used in some time (e.g., ten | (LRU)-based policy that only reclaims entries that have not been used | |||
minutes or more) should be adequate for garbage-collecting unused | in some time (e.g., ten minutes or more) should be adequate for | |||
entries. | garbage-collecting unused entries. | |||
A node should retain entries in the Default Router List and the | A node should retain entries in the Default Router List and the | |||
Prefix List until their lifetimes expire. However, a node may | Prefix List until their lifetimes expire. However, a node may | |||
garbage collect entries prematurely if it is low on memory. If not | garbage-collect entries prematurely if it is low on memory. If not | |||
all routers are kept on the Default Router list, a node should retain | all routers are kept on the Default Router list, a node should retain | |||
at least two entries in the Default Router List (and preferably more) | at least two entries in the Default Router List (and preferably more) | |||
in order to maintain robust connectivity for off-link destinations. | in order to maintain robust connectivity for off-link destinations. | |||
When removing an entry from the Prefix List there is no need to purge | When removing an entry from the Prefix List, there is no need to | |||
any entries from the Destination or Neighbor Caches. Neighbor | purge any entries from the Destination or Neighbor Caches. Neighbor | |||
Unreachability Detection will efficiently purge any entries in these | Unreachability Detection will efficiently purge any entries in these | |||
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 stateless address | configuration parameters related to stateless address | |||
autoconfiguration. | 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 | |||
skipping to change at page 37, line 42 | skipping to change at page 40, line 42 | |||
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 | |||
to or from the interface. | from the interface. | |||
Default: FALSE | Default: FALSE | |||
AdvSendAdvertisements | AdvSendAdvertisements | |||
A flag indicating whether or not the router sends | A flag indicating whether or not the router sends | |||
periodic Router Advertisements and responds to | periodic Router Advertisements and responds to | |||
Router Solicitations. | Router Solicitations. | |||
Default: FALSE | Default: FALSE | |||
skipping to change at page 38, line 31 | skipping to change at page 41, line 42 | |||
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 * | seconds and no greater than .75 * | |||
MaxRtrAdvInterval. | MaxRtrAdvInterval. | |||
Default: 0.33 * MaxRtrAdvInterval | Default: 0.33 * MaxRtrAdvInterval If | |||
If MaxRtrAdvInterval >= 9 seconds, otherwise the | MaxRtrAdvInterval >= 9 seconds; otherwise, the | |||
Default is MaxRtrAdvInterval. | 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 | |||
configuration" flag field in the Router | configuration" flag field in the Router | |||
Advertisement. See [ADDRCONF]. | Advertisement. See [ADDRCONF]. | |||
Default: FALSE | Default: FALSE | |||
AdvLinkMTU The value to be placed in MTU options sent by the | AdvLinkMTU The value to be placed in MTU options sent by the | |||
router. A value of zero indicates that no MTU | router. A value of zero indicates that no MTU | |||
options are sent. | options are sent. | |||
skipping to change at page 39, line 23 | skipping to change at page 42, line 36 | |||
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 the | the router. The value should be set to the current | |||
current diameter of the Internet. The value zero | diameter of the Internet. The value zero means | |||
means unspecified (by this router). | 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" [ASSIGNED] that was in effect at the time | |||
time of implementation. | 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, | |||
in seconds. MUST be either zero or between | in seconds. MUST be either zero or between | |||
MaxRtrAdvInterval and 9000 seconds. A value of | MaxRtrAdvInterval and 9000 seconds. A value of | |||
zero indicates that the router is not to be used as | zero indicates that the router is not to be used as | |||
a default router. | a default router. These limits may be overridden | |||
by specific documents that describe how IPv6 | ||||
operates over different link layers. For instance, | ||||
in a point-to-point link the peers may have enough | ||||
information about the number and status of devices | ||||
at the other end so that advertisements are needed | ||||
less frequently. | ||||
Default: 3 * MaxRtrAdvInterval | Default: 3 * MaxRtrAdvInterval | |||
AdvPrefixList | AdvPrefixList | |||
A list of prefixes to be placed in Prefix | A list of prefixes to be placed in Prefix | |||
Information options in Router Advertisement | Information options in Router Advertisement | |||
messages sent from the interface. | messages sent from the interface. | |||
Default: all prefixes that the router advertises | Default: all prefixes that the router advertises | |||
via routing protocols as being on-link for the | via routing protocols as being on-link for the | |||
interface from which the advertisement is sent. | interface from which the advertisement is sent. | |||
The link-local prefix SHOULD NOT be included in the | The link-local prefix SHOULD NOT be included in the | |||
list of advertised prefixes. | list of advertised prefixes. | |||
Each prefix has an associated: | Each prefix has an associated: | |||
AdvValidLifetime | AdvValidLifetime | |||
The value to be placed in the Valid | The value to be placed in the Valid | |||
Lifetime in the Prefix Information | Lifetime in the Prefix Information option, | |||
option, in seconds. The designated value | in seconds. The designated value of all | |||
of all 1's (0xffffffff) represents | 1's (0xffffffff) represents infinity. | |||
infinity. Implementations MAY allow | Implementations MAY allow AdvValidLifetime | |||
AdvValidLifetime to be specified in two | to be specified in two ways: | |||
ways: | ||||
- a time that decrements in real time, | - a time that decrements in real time, | |||
that is, one that will result in a | that is, one that will result in a | |||
Lifetime of zero at the specified | Lifetime of zero at the specified time | |||
time in the future, or | in the future, or | |||
- a fixed time that stays the same in | - a fixed time that stays the same in | |||
consecutive advertisements. | consecutive advertisements. | |||
Default: 2592000 seconds (30 days), fixed | Default: 2592000 seconds (30 days), fixed | |||
(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 | |||
flag ("L-bit") field in the Prefix | ("L-bit") field in the Prefix Information | |||
Information option. | option. | |||
Default: TRUE | Default: TRUE | |||
Stateless address configuration [ADDRCONF] | Stateless address configuration [ADDRCONF] defines | |||
defines additional information associated with | additional information associated with each of the | |||
each the prefixes: | 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, | |||
option, in seconds. The designated value | in seconds. The designated value of all | |||
of all 1's (0xffffffff) represents | 1's (0xffffffff) represents infinity. See | |||
infinity. See [ADDRCONF] for details on | [ADDRCONF] for details on how this value is | |||
how this value is used. Implementations | used. Implementations MAY allow | |||
MAY allow AdvPreferredLifetime to be | AdvPreferredLifetime to be specified in two | |||
specified in two ways: | ways: | |||
- a time that decrements in real time, | - a time that decrements in real time, | |||
that is, one that will result in a | that is, one that will result in a | |||
Lifetime of zero at a specified time | Lifetime of zero at a specified time in | |||
in the future, or | the future, or | |||
- a fixed time that stays the same in | - a fixed time that stays the same in | |||
consecutive advertisements. | consecutive advertisements. | |||
Default: 604800 seconds (7 days), fixed | Default: 604800 seconds (7 days), fixed | |||
(i.e., stays the same in consecutive | (i.e., stays the same in consecutive | |||
advertisements). This value MUST NOT be | advertisements). This value MUST NOT be | |||
larger than AdvValidLifetime. | larger than AdvValidLifetime. | |||
AdvAutonomousFlag | AdvAutonomousFlag | |||
skipping to change at page 41, line 29 | skipping to change at page 45, line 11 | |||
CurHopLimit, RetransTimer, and ReachableTime) apply to all nodes | CurHopLimit, RetransTimer, and ReachableTime) apply to all nodes | |||
including routers. In practice, these variables may not actually be | including routers. In practice, these variables may not actually be | |||
present on routers, since their contents can be derived from the | present on routers, since their contents can be derived from the | |||
variables described above. However, external router behavior MUST be | variables described above. However, external router behavior MUST be | |||
the same as host behavior with respect to these variables. In | the same as host behavior with respect to these variables. In | |||
particular, this includes the occasional randomization of the | particular, this includes the occasional randomization of the | |||
ReachableTime value as described in Section 6.3.2. | ReachableTime value as described in Section 6.3.2. | |||
Protocol constants are defined in Section 10. | Protocol constants are defined in Section 10. | |||
6.2.2. Becoming An Advertising Interface | 6.2.2. Becoming an Advertising Interface | |||
The term "advertising interface" refers to any functioning and | The term "advertising interface" refers to any functioning and | |||
enabled interface that has at least one unicast IP address | enabled interface that has at least one unicast IP address assigned | |||
assigned to it and whose corresponding AdvSendAdvertisements flag is | to it and whose corresponding AdvSendAdvertisements flag is TRUE. A | |||
TRUE. A router MUST NOT send Router Advertisements out any interface | router MUST NOT send Router Advertisements out any interface that is | |||
that is not an advertising interface. | not an advertising interface. | |||
An interface may become an advertising interface at times other than | An interface may become an advertising interface at times other than | |||
system startup. For example: | system startup. For example: | |||
- changing the AdvSendAdvertisements flag on an enabled interface | - changing the AdvSendAdvertisements flag on an enabled interface | |||
from FALSE to TRUE, or | from FALSE to TRUE, or | |||
- administratively enabling the interface, if it had been | - administratively enabling the interface, if it had been | |||
administratively disabled, and its AdvSendAdvertisements flag is | administratively disabled, and its AdvSendAdvertisements flag is | |||
TRUE, or | TRUE, or | |||
skipping to change at page 42, line 35 | skipping to change at page 46, line 22 | |||
AdvRetransTimer. | AdvRetransTimer. | |||
- In the options: | - In the options: | |||
o Source Link-Layer Address option: link-layer address of the | o Source Link-Layer Address option: link-layer address of the | |||
sending interface. This option MAY be omitted to | sending interface. This option MAY be omitted to | |||
facilitate in-bound load balancing over replicated | facilitate in-bound load balancing over replicated | |||
interfaces. | interfaces. | |||
o MTU option: the interface's configured AdvLinkMTU value if | o MTU option: the interface's configured AdvLinkMTU value if | |||
the value is non-zero. If AdvLinkMTU is zero the MTU | the value is non-zero. If AdvLinkMTU is zero, the MTU | |||
option is not sent. | option is not sent. | |||
o Prefix Information options: one Prefix Information option | o Prefix Information options: one Prefix Information option | |||
for each prefix listed in AdvPrefixList with the option | for each prefix listed in AdvPrefixList with the option | |||
fields set from the information in the AdvPrefixList entry | fields set from the information in the AdvPrefixList entry | |||
as follows: | as follows: | |||
- In the "on-link" flag: the entry's AdvOnLinkFlag. | - In the "on-link" flag: the entry's AdvOnLinkFlag. | |||
- In the Valid Lifetime field: the entry's | - In the Valid Lifetime field: the entry's | |||
skipping to change at page 43, line 31 | skipping to change at page 47, line 21 | |||
6.2.4. Sending Unsolicited Router Advertisements | 6.2.4. Sending Unsolicited Router Advertisements | |||
A host MUST NOT send Router Advertisement messages at any time. | A host MUST NOT send Router Advertisement messages at any time. | |||
Unsolicited Router Advertisements are not strictly periodic: the | Unsolicited Router Advertisements are not strictly periodic: the | |||
interval between subsequent transmissions is randomized to reduce the | interval between subsequent transmissions is randomized to reduce the | |||
probability of synchronization with the advertisements from other | probability of synchronization with the advertisements from other | |||
routers on the same link [SYNC]. Each advertising interface has its | routers on the same link [SYNC]. Each advertising interface has its | |||
own timer. Whenever a multicast advertisement is sent from an | own timer. Whenever a multicast advertisement is sent from an | |||
interface, the timer is reset to a uniformly-distributed random value | interface, the timer is reset to a uniformly distributed random value | |||
between the interface's configured MinRtrAdvInterval and | between the interface's configured MinRtrAdvInterval and | |||
MaxRtrAdvInterval; expiration of the timer causes the next | MaxRtrAdvInterval; expiration of the timer causes the next | |||
advertisement to be sent and a new random value to be chosen. | advertisement to be sent and a new random value to be chosen. | |||
For the first few advertisements (up to | For the first few advertisements (up to | |||
MAX_INITIAL_RTR_ADVERTISEMENTS) sent from an interface when it | MAX_INITIAL_RTR_ADVERTISEMENTS) sent from an interface when it | |||
becomes an advertising interface, if the randomly chosen interval is | becomes an advertising interface, if the randomly chosen interval is | |||
greater than MAX_INITIAL_RTR_ADVERT_INTERVAL, the timer SHOULD be set | greater than MAX_INITIAL_RTR_ADVERT_INTERVAL, the timer SHOULD be set | |||
to MAX_INITIAL_RTR_ADVERT_INTERVAL instead. Using a smaller interval | to MAX_INITIAL_RTR_ADVERT_INTERVAL instead. Using a smaller interval | |||
for the initial advertisements increases the likelihood of a router | for the initial advertisements increases the likelihood of a router | |||
skipping to change at page 43, line 53 | skipping to change at page 47, line 43 | |||
presence of possible packet loss. | presence of possible packet loss. | |||
The information contained in Router Advertisements may change through | The information contained in Router Advertisements may change through | |||
actions of system management. For instance, the lifetime of | actions of system management. For instance, the lifetime of | |||
advertised prefixes may change, new prefixes could be added, a router | advertised prefixes may change, new prefixes could be added, a router | |||
could cease to be a router (i.e., switch from being a router to being | could cease to be a router (i.e., switch from being a router to being | |||
a host), etc. In such cases, the router MAY transmit up to | a host), etc. In such cases, the router MAY transmit up to | |||
MAX_INITIAL_RTR_ADVERTISEMENTS unsolicited advertisements, using the | MAX_INITIAL_RTR_ADVERTISEMENTS unsolicited advertisements, using the | |||
same rules as when an interface becomes an advertising interface. | same rules as when an interface becomes an advertising interface. | |||
6.2.5. Ceasing To Be An Advertising Interface | 6.2.5. Ceasing To Be an Advertising Interface | |||
An interface may cease to be an advertising interface, through | An interface may cease to be an advertising interface, through | |||
actions of system management such as: | actions of system management such as: | |||
- changing the AdvSendAdvertisements flag of an enabled interface | - changing the AdvSendAdvertisements flag of an enabled interface | |||
from TRUE to FALSE, or | from TRUE to FALSE, or | |||
- 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 ensure 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 | |||
skipping to change at page 45, line 30 | skipping to change at page 49, line 32 | |||
Note that a router is permitted to send multicast Router | Note that a router is permitted to send multicast Router | |||
Advertisements more frequently than indicated by the | Advertisements more frequently than indicated by the | |||
MinRtrAdvInterval configuration variable so long as the more frequent | MinRtrAdvInterval configuration variable so long as the more frequent | |||
advertisements are responses to Router Solicitations. In all cases, | advertisements are responses to Router Solicitations. In all cases, | |||
however, unsolicited multicast advertisements MUST NOT be sent more | however, unsolicited multicast advertisements MUST NOT be sent more | |||
frequently than indicated by MinRtrAdvInterval. | frequently than indicated by MinRtrAdvInterval. | |||
Router Solicitations in which the Source Address is the unspecified | Router Solicitations in which the Source Address is the unspecified | |||
address MUST NOT update the router's Neighbor Cache; solicitations | address MUST NOT update the router's Neighbor Cache; solicitations | |||
with a proper source address update the Neighbor Cache as follows. If | with a proper source address update the Neighbor Cache as follows. | |||
the router already has a Neighbor Cache entry for the solicitation's | If the router already has a Neighbor Cache entry for the | |||
sender, the solicitation contains a Source Link-Layer Address option, | solicitation's sender, the solicitation contains a Source Link-Layer | |||
and the received link-layer address differs from that already in the | Address option, and the received link-layer address differs from that | |||
cache, the link-layer address SHOULD be updated in the appropriate | already in the cache, then the link-layer address SHOULD be updated | |||
Neighbor Cache entry, and its reachability state MUST also be set to | in the appropriate Neighbor Cache entry, and its reachability state | |||
STALE. If there is no existing Neighbor Cache entry for the | MUST also be set to STALE. If there is no existing Neighbor Cache | |||
solicitation's sender, the router creates one, installs the link- | entry for the solicitation's sender, the router creates one, installs | |||
layer address and sets its reachability state to STALE as specified | the link- layer address and sets its reachability state to STALE as | |||
in Section 7.3.3. If there is no existing Neighbor Cache entry and no | specified in Section 7.3.3. If there is no existing Neighbor Cache | |||
Source Link-Layer Address option was present in the solicitation, the | entry and no Source Link-Layer Address option was present in the | |||
router may respond with either a multicast or a unicast router | solicitation, the router may respond with either a multicast or a | |||
advertisement. Whether or not a Source Link-Layer Address option | unicast router advertisement. Whether or not a Source Link-Layer | |||
is provided, if a Neighbor Cache entry for the solicitation's sender | Address option is provided, if a Neighbor Cache entry for the | |||
exists (or is created) the entry's IsRouter flag MUST be set to | solicitation's sender exists (or is created) the entry's IsRouter | |||
FALSE. | flag MUST be set to FALSE. | |||
6.2.7. Router Advertisement Consistency | 6.2.7. Router Advertisement Consistency | |||
Routers SHOULD inspect valid Router Advertisements sent by other | Routers SHOULD inspect valid Router Advertisements sent by other | |||
routers and verify that the routers are advertising consistent | routers and verify that the routers are advertising consistent | |||
information on a link. Detected inconsistencies indicate that one or | information on a link. Detected inconsistencies indicate that one or | |||
more routers might be misconfigured and SHOULD be logged to system or | more routers might be misconfigured and SHOULD be logged to system or | |||
network management. The minimum set of information to check | network management. The minimum set of information to check | |||
includes: | includes: | |||
- Cur Hop Limit values (except for the unspecified value of zero | - Cur Hop Limit values (except for the unspecified value of zero | |||
skipping to change at page 46, line 19 | skipping to change at page 50, line 28 | |||
- Values of the M or O flags. | - Values of the M or O flags. | |||
- Reachable Time values (except for the unspecified value of zero). | - Reachable Time values (except for the unspecified value of zero). | |||
- Retrans Timer values (except for the unspecified value of zero). | - Retrans Timer values (except for the unspecified value of zero). | |||
- Values in the MTU options. | - Values in the MTU options. | |||
- Preferred and Valid Lifetimes for the same prefix. If | - Preferred and Valid Lifetimes for the same prefix. If | |||
AdvPreferredLifetime and/or AdvValidLifetime decrement in real | AdvPreferredLifetime and/or AdvValidLifetime decrement in real | |||
time as specified in section 6.2.1 then the comparison of the | time as specified in Section 6.2.1 then the comparison of the | |||
lifetimes can not compare the content of the fields in the Router | lifetimes can not compare the content of the fields in the Router | |||
Advertisement but must instead compare the time at which the | Advertisement, but must instead compare the time at which the | |||
prefix will become deprecated and invalidated, respectively. Due | prefix will become deprecated and invalidated, respectively. Due | |||
to link propagation delays and potentially poorly synchronized | to link propagation delays and potentially poorly synchronized | |||
clocks between the routers such comparison SHOULD allow some time | clocks between the routers such comparison SHOULD allow some time | |||
skew. | skew. | |||
Note that it is not an error for different routers to advertise | Note that it is not an error for different routers to advertise | |||
different sets of prefixes. Also, some routers might leave some | different sets of prefixes. Also, some routers might leave some | |||
fields as unspecified, i.e., with the value zero, while other routers | fields as unspecified, i.e., with the value zero, while other routers | |||
specify values. The logging of errors SHOULD be restricted to | specify values. The logging of errors SHOULD be restricted to | |||
conflicting information that causes hosts to switch from one value to | conflicting information that causes hosts to switch from one value to | |||
skipping to change at page 46, line 45 | skipping to change at page 51, line 5 | |||
router is beyond the scope of this document. | router is beyond the scope of this document. | |||
6.2.8. Link-local Address Change | 6.2.8. Link-local Address Change | |||
The link-local address on a router should rarely change, if ever. | The link-local address on a router should rarely change, if ever. | |||
Nodes receiving Neighbor Discovery messages use the source address to | Nodes receiving Neighbor Discovery messages use the source address to | |||
identify the sender. If multiple packets from the same router | identify the sender. If multiple packets from the same router | |||
contain different source addresses, nodes will assume they come from | contain different source addresses, nodes will assume they come from | |||
different routers, leading to undesirable behavior. For example, a | different routers, leading to undesirable behavior. For example, a | |||
node will ignore Redirect messages that are believed to have been | node will ignore Redirect messages that are believed to have been | |||
sent by a router other than the current first-hop router. Thus the | sent by a router other than the current first-hop router. Thus, the | |||
source address used in Router Advertisements sent by a particular | source address used in Router Advertisements sent by a particular | |||
router must be identical to the target address in a Redirect message | router must be identical to the target address in a Redirect message | |||
when redirecting to that router. | when redirecting to that router. | |||
Using the link-local address to uniquely identify routers on the link | Using the link-local address to uniquely identify routers on the link | |||
has the benefit that the address a router is known by should not | has the benefit that the address a router is known by should not | |||
change when a site renumbers. | change when a site renumbers. | |||
If a router changes the link-local address for one of its interfaces, | If a router changes the link-local address for one of its interfaces, | |||
it SHOULD inform hosts of this change. The router SHOULD multicast a | it SHOULD inform hosts of this change. The router SHOULD multicast a | |||
skipping to change at page 47, line 18 | skipping to change at page 51, line 30 | |||
interface, and a different one starts being an advertising interface. | interface, and a different one starts being an advertising interface. | |||
6.3. Host Specification | 6.3. Host Specification | |||
6.3.1. Host Configuration Variables | 6.3.1. Host Configuration Variables | |||
None. | None. | |||
6.3.2. Host Variables | 6.3.2. Host Variables | |||
A host maintains certain Neighbor Discovery related variables in | A host maintains certain Neighbor-Discovery-related variables in | |||
addition to the data structures defined in Section 5.1. The specific | addition to the data structures defined in Section 5.1. The specific | |||
variable names are used for demonstration purposes only, and an | variable names are used for demonstration purposes only, and an | |||
implementation is not required to have them, so long as its external | implementation is not required to have them, so long as its external | |||
behavior is consistent with that described in this document. | behavior is consistent with that described in this document. | |||
These variables have default values that are overridden by | These variables have default values that are overridden by | |||
information received in Router Advertisement messages. The default | information received in Router Advertisement messages. The default | |||
values are used when there is no router on the link or when all | values are used when there is no router on the link or when all | |||
received Router Advertisements have left a particular value | received Router Advertisements have left a particular value | |||
unspecified. | unspecified. | |||
skipping to change at page 47, line 40 | skipping to change at page 52, line 10 | |||
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 IP | |||
IP packets. | 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" [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. | |||
ReachableTime The time a neighbor is considered reachable after | ReachableTime The time a neighbor is considered reachable after | |||
receiving a reachability confirmation. | receiving a reachability confirmation. | |||
This value should be a uniformly-distributed | This value should be a uniformly distributed | |||
random value between MIN_RANDOM_FACTOR and | random value between MIN_RANDOM_FACTOR and | |||
MAX_RANDOM_FACTOR times BaseReachableTime | MAX_RANDOM_FACTOR times BaseReachableTime | |||
milliseconds. A new random value should be | milliseconds. A new random value should be | |||
calculated when BaseReachableTime changes (due to | calculated when BaseReachableTime changes (due to | |||
Router Advertisements) or at least every few | Router Advertisements) or at least every few | |||
hours even if no Router Advertisements are | hours even if no Router Advertisements are | |||
received. | received. | |||
RetransTimer The time between retransmissions of Neighbor | RetransTimer The time between retransmissions of Neighbor | |||
Solicitation messages to a neighbor when | Solicitation messages to a neighbor when | |||
skipping to change at page 48, line 41 | skipping to change at page 53, line 17 | |||
When multiple routers are present, the information advertised | When multiple routers are present, the information advertised | |||
collectively by all routers may be a superset of the information | collectively by all routers may be a superset of the information | |||
contained in a single Router Advertisement. Moreover, information | contained in a single Router Advertisement. Moreover, information | |||
may also be obtained through other dynamic means like DHCPv6. Hosts | may also be obtained through other dynamic means like DHCPv6. Hosts | |||
accept the union of all received information; the receipt of a Router | accept the union of all received information; the receipt of a Router | |||
Advertisement MUST NOT invalidate all information received in a | Advertisement MUST NOT invalidate all information received in a | |||
previous advertisement or from another source. However, when | previous advertisement or from another source. However, when | |||
received information for a specific parameter (e.g., Link MTU) or | received information for a specific parameter (e.g., Link MTU) or | |||
option (e.g., Lifetime on a specific Prefix) differs from information | option (e.g., Lifetime on a specific Prefix) differs from information | |||
received earlier, and the parameter/option can only have one value, | received earlier, and the parameter/option can only have one value, | |||
the most recently-received information is considered authoritative. | the most recently received information is considered authoritative. | |||
Some Router Advertisement fields (e.g., Cur Hop Limit, Reachable Time | A Router Advertisement field (e.g., Cur Hop Limit, Reachable Time, | |||
and Retrans Timer) may contain a value denoting unspecified. In such | and Retrans Timer) may contain a value denoting that it is | |||
cases, the parameter should be ignored and the host should continue | unspecified. In such cases, the parameter should be ignored and the | |||
using whatever value it is already using. In particular, a host MUST | host should continue using whatever value it is already using. In | |||
NOT interpret the unspecified value as meaning change back to the | particular, a host MUST NOT interpret the unspecified value as | |||
default value that was in use before the first Router Advertisement | meaning change back to the default value that was in use before the | |||
was received. This rule prevents hosts from continually changing an | first Router Advertisement was received. This rule prevents hosts | |||
internal variable when one router advertises a specific value, but | from continually changing an internal variable when one router | |||
other routers advertise the unspecified value. | advertises a specific value, but other routers advertise the | |||
unspecified value. | ||||
On receipt of a valid Router Advertisement, a host extracts the | On receipt of a valid Router Advertisement, a host extracts the | |||
source address of the packet and does the following: | source address of the packet and does the following: | |||
- If the address is not already present in the host's Default | - If the address is not already present in the host's Default | |||
Router List, and the advertisement's Router Lifetime is non- | Router List, and the advertisement's Router Lifetime is non- | |||
zero, create a new entry in the list, and initialize its | zero, create a new entry in the list, and initialize its | |||
invalidation timer value from the advertisement's Router | invalidation timer value from the advertisement's Router | |||
Lifetime field. | Lifetime field. | |||
- If the address is already present in the host's Default Router | - If the address is already present in the host's Default Router | |||
List as a result of a previously-received advertisement, reset | List as a result of a previously received advertisement, reset | |||
its invalidation timer to the Router Lifetime value in the | its invalidation timer to the Router Lifetime value in the newly | |||
newly-received advertisement. | received advertisement. | |||
- If the address is already present in the host's Default Router | - If the address is already present in the host's Default Router | |||
List and the received Router Lifetime value is zero, immediately | List and the received Router Lifetime value is zero, immediately | |||
time-out the entry as specified in Section 6.3.5. | time-out the entry as specified in Section 6.3.5. | |||
To limit the storage needed for the Default Router List, a host MAY | To limit the storage needed for the Default Router List, a host MAY | |||
choose not to store all of the router addresses discovered via | choose not to store all of the router addresses discovered via | |||
advertisements. However, a host MUST retain at least two router | advertisements. However, a host MUST retain at least two router | |||
addresses and SHOULD retain more. Default router selections are made | addresses and SHOULD retain more. Default router selections are made | |||
whenever communication to a destination appears to be failing. Thus, | whenever communication to a destination appears to be failing. Thus, | |||
the more routers on the list, the more likely an alternative working | the more routers on the list, the more likely an alternative working | |||
router can be found quickly (e.g., without having to wait for the | router can be found quickly (e.g., without having to wait for the | |||
next advertisement to arrive). | next advertisement to arrive). | |||
If the received Cur Hop Limit value is non-zero the host SHOULD set | If the received Cur Hop Limit value is non-zero, the host SHOULD set | |||
its CurHopLimit variable to the received value. | its CurHopLimit variable to the received value. | |||
If the received Reachable Time value is non-zero the host SHOULD set | If the received Reachable Time value is non-zero, the host SHOULD set | |||
its BaseReachableTime variable to the received value. If the new | its BaseReachableTime variable to the received value. If the new | |||
value differs from the previous value, the host SHOULD recompute a | value differs from the previous value, the host SHOULD re-compute a | |||
new random ReachableTime value. ReachableTime is computed as a | new random ReachableTime value. ReachableTime is computed as a | |||
uniformly-distributed random value between MIN_RANDOM_FACTOR and | uniformly distributed random value between MIN_RANDOM_FACTOR and | |||
MAX_RANDOM_FACTOR times the BaseReachableTime. Using a random | MAX_RANDOM_FACTOR times the BaseReachableTime. Using a random | |||
component eliminates the possibility Neighbor Unreachability | component eliminates the possibility that Neighbor Unreachability | |||
Detection messages synchronize with each other. | Detection messages will synchronize with each other. | |||
In most cases, the advertised Reachable Time value will be the same | In most cases, the advertised Reachable Time value will be the same | |||
in consecutive Router Advertisements and a host's BaseReachableTime | in consecutive Router Advertisements, and a host's BaseReachableTime | |||
rarely changes. In such cases, an implementation SHOULD insure that | rarely changes. In such cases, an implementation SHOULD ensure that | |||
a new random value gets recomputed at least once every few hours. | a new random value gets re-computed at least once every few hours. | |||
The RetransTimer variable SHOULD be copied from the Retrans Timer | The RetransTimer variable SHOULD be copied from the Retrans Timer | |||
field, if the received value is non-zero. | field, if the received value is non-zero. | |||
After extracting information from the fixed part of the Router | After extracting information from the fixed part of the Router | |||
Advertisement message, the advertisement is scanned for valid | Advertisement message, the advertisement is scanned for valid | |||
options. If the advertisement contains a Source Link-Layer Address | options. If the advertisement contains a Source Link-Layer Address | |||
option the link-layer address SHOULD be recorded in the Neighbor | option, the link-layer address SHOULD be recorded in the Neighbor | |||
Cache entry for the router (creating an entry if necessary) and the | Cache entry for the router (creating an entry if necessary) and the | |||
IsRouter flag in the Neighbor Cache entry MUST be set to TRUE. If no | IsRouter flag in the Neighbor Cache entry MUST be set to TRUE. If no | |||
Source Link-Layer Address is included, but a corresponding Neighbor | Source Link-Layer Address is included, but a corresponding Neighbor | |||
Cache entry exists, its IsRouter flag MUST be set to TRUE. The | Cache entry exists, its IsRouter flag MUST be set to TRUE. The | |||
IsRouter flag is used by Neighbor Unreachability Detection to | IsRouter flag is used by Neighbor Unreachability Detection to | |||
determine when a router changes to being a host (i.e., no longer | determine when a router changes to being a host (i.e., no longer | |||
capable of forwarding packets). If a Neighbor Cache entry is created | capable of forwarding packets). If a Neighbor Cache entry is created | |||
for the router its reachability state MUST be set to STALE as | for the router, its reachability state MUST be set to STALE as | |||
specified in Section 7.3.3. If a cache entry already exists and is | specified in Section 7.3.3. If a cache entry already exists and is | |||
updated with a different link-layer address the reachability state | updated with a different link-layer address, the reachability state | |||
MUST also be set to STALE. | MUST also be set to STALE. | |||
If the MTU option is present, hosts SHOULD copy the option's value | If the MTU option is present, hosts SHOULD copy the option's value | |||
into LinkMTU so long as the value is greater than or equal to the | into LinkMTU so long as the value is greater than or equal to the | |||
minimum link MTU [IPv6] and does not exceed the maximum LinkMTU value | minimum link MTU [IPv6] and does not exceed the maximum LinkMTU value | |||
specified in the link type specific document (e.g., [IPv6-ETHER]). | specified in the link-type-specific document (e.g., [IPv6-ETHER]). | |||
Prefix Information options that have the "on-link" (L) flag set | Prefix Information options that have the "on-link" (L) flag set | |||
indicate a prefix identifying a range of addresses that should be | indicate a prefix identifying a range of addresses that should be | |||
considered on-link. Note, however, that a Prefix Information option | considered on-link. Note, however, that a Prefix Information option | |||
with the on-link flag set to zero conveys no information concerning | with the on-link flag set to zero conveys no information concerning | |||
on-link determination and MUST NOT be interpreted to mean that | on-link determination and MUST NOT be interpreted to mean that | |||
addresses covered by the prefix are off-link. The only way to cancel | addresses covered by the prefix are off-link. The only way to cancel | |||
a previous on-link indication is to advertise that prefix with the | a previous on-link indication is to advertise that prefix with the | |||
L-bit set and the Lifetime set to zero. The default behavior (see | L-bit set and the Lifetime set to zero. The default behavior (see | |||
Section 5.2) when sending a packet to an address for which no | Section 5.2) when sending a packet to an address for which no | |||
skipping to change at page 50, line 48 | skipping to change at page 55, line 31 | |||
- If the prefix is the link-local prefix, silently ignore the | - If the prefix is the link-local prefix, silently ignore the | |||
Prefix Information option. | Prefix Information option. | |||
- If the prefix is not already present in the Prefix List, and the | - If the prefix is not already present in the Prefix List, and the | |||
Prefix Information option's Valid Lifetime field is non-zero, | Prefix Information option's Valid Lifetime field is non-zero, | |||
create a new entry for the prefix and initialize its | create a new entry for the prefix and initialize its | |||
invalidation timer to the Valid Lifetime value in the Prefix | invalidation timer to the Valid Lifetime value in the Prefix | |||
Information option. | Information option. | |||
- If the prefix is already present in the host's Prefix List as | - If the prefix is already present in the host's Prefix List as | |||
the result of a previously-received advertisement, reset its | the result of a previously received advertisement, reset its | |||
invalidation timer to the Valid Lifetime value in the Prefix | invalidation timer to the Valid Lifetime value in the Prefix | |||
Information option. If the new Lifetime value is zero, time-out | Information option. If the new Lifetime value is zero, time-out | |||
the prefix immediately (see Section 6.3.5). | the prefix immediately (see Section 6.3.5). | |||
- If the Prefix Information option's Valid Lifetime field is zero, | - If the Prefix Information option's Valid Lifetime field is zero, | |||
and the prefix is not present in the host's Prefix List, | and the prefix is not present in the host's Prefix List, | |||
silently ignore the option. | silently ignore the option. | |||
Stateless address autoconfiguration [ADDRCONF] may in some | Stateless address autoconfiguration [ADDRCONF] may in some | |||
circumstances use a larger Valid Lifetime of a prefix or ignore it | circumstances use a larger Valid Lifetime of a prefix or ignore it | |||
completely in order to prevent a particular denial of service attack. | completely in order to prevent a particular denial-of-service attack. | |||
However, since the effect of the same denial of service targeted at | However, since the effect of the same denial of service targeted at | |||
the on-link prefix list is not catastrophic (hosts would send packets | the on-link prefix list is not catastrophic (hosts would send packets | |||
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 stateless address | the prefixes separately from the stateless address | |||
autoconfiguration aspects of the prefixes by, e.g., passing a copy | autoconfiguration aspects of the prefixes by, e.g., passing a copy | |||
skipping to change at page 52, line 35 | skipping to change at page 57, line 24 | |||
router is made in conjunction with the sending of a packet to a | router is made in conjunction with the sending of a packet to a | |||
router, and the selected router will be probed for reachability | router, and the selected router will be probed for reachability | |||
as a side effect. | as a side effect. | |||
6.3.7. Sending Router Solicitations | 6.3.7. Sending Router Solicitations | |||
When an interface becomes enabled, a host may be unwilling to wait | When an interface becomes enabled, a host may be unwilling to wait | |||
for the next unsolicited Router Advertisement to locate default | for the next unsolicited Router Advertisement to locate default | |||
routers or learn prefixes. To obtain Router Advertisements quickly, | routers or learn prefixes. To obtain Router Advertisements quickly, | |||
a host SHOULD transmit up to MAX_RTR_SOLICITATIONS Router | a host SHOULD transmit up to MAX_RTR_SOLICITATIONS Router | |||
Solicitation messages each separated by at least | Solicitation messages, each separated by at least | |||
RTR_SOLICITATION_INTERVAL seconds. Router Solicitations may be sent | RTR_SOLICITATION_INTERVAL seconds. Router Solicitations may be sent | |||
after any of the following events: | after any of the following events: | |||
- The interface is initialized at system startup time. | - The interface is initialized at system startup time. | |||
- The interface is reinitialized after a temporary interface | - The interface is reinitialized after a temporary interface | |||
failure or after being temporarily disabled by system | failure or after being temporarily disabled by system | |||
management. | management. | |||
- The system changes from being a router to being a host, by | - The system changes from being a router to being a host, by | |||
having its IP forwarding capability turned off by system | having its IP forwarding capability turned off by system | |||
management. | management. | |||
- The host attaches to a link for the first time. | - The host attaches to a link for the first time. | |||
- The host re-attaches to a link after being detached for some | - The host re-attaches to a link after being detached for some | |||
time. | time. | |||
A host sends Router Solicitations to the All-Routers multicast | A host sends Router Solicitations to the all-routers multicast | |||
address. The IP source address is set to either one of the | address. The IP source address is set to either one of the | |||
interface's unicast addresses or the unspecified address. The Source | interface's unicast addresses or the unspecified address. The Source | |||
Link-Layer Address option SHOULD be set to the host's link-layer | Link-Layer Address option SHOULD be set to the host's link-layer | |||
address, if the IP source address is not the unspecified address. | address, if the IP source address is not the unspecified address. | |||
Before a host sends an initial solicitation, it SHOULD delay the | Before a host sends an initial solicitation, it SHOULD delay the | |||
transmission for a random amount of time between 0 and | transmission for a random amount of time between 0 and | |||
MAX_RTR_SOLICITATION_DELAY. This serves to alleviate congestion when | MAX_RTR_SOLICITATION_DELAY. This serves to alleviate congestion when | |||
many hosts start up on a link at the same time, such as might happen | many hosts start up on a link at the same time, such as might happen | |||
after recovery from a power failure. If a host has already performed | after recovery from a power failure. If a host has already performed | |||
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 it is outside the scope of this specification. Note that | |||
this mechanism inappropriately (e.g. based on weak or transient | using this mechanism inappropriately (e.g., based on weak or | |||
indications) may result in Router Solicitation storms. Furthermore, | transient indications) may result in Router Solicitation storms. | |||
simultaneous mobility of a large number of mobile nodes that use this | Furthermore, simultaneous mobility of a large number of mobile nodes | |||
mechanism can result in a large number of solicitations sent | that use this mechanism can result in a large number of solicitations | |||
simultaneously. | sent 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. | |||
Responses to solicited advertisements are expected to contain | Responses to solicited advertisements may contain more information | |||
complete information. | than unsolicited advertisements. | |||
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 | |||
This section describes the functions related to Neighbor Solicitation | This section describes the functions related to Neighbor Solicitation | |||
and Neighbor Advertisement messages and includes descriptions of | and Neighbor Advertisement messages and includes descriptions of | |||
address resolution and the Neighbor Unreachability Detection | address resolution and the Neighbor Unreachability Detection | |||
algorithm. | algorithm. | |||
Neighbor Solicitation and Advertisement messages are also used for | Neighbor Solicitation and Advertisement messages are also used for | |||
Duplicate Address Detection as specified by [ADDRCONF]. In | Duplicate Address Detection as specified by [ADDRCONF]. In | |||
particular, Duplicate Address Detection sends Neighbor Solicitation | particular, Duplicate Address Detection sends Neighbor Solicitation | |||
messages with an unspecified source address targeting its own | messages with an unspecified source address targeting its own | |||
"tentative" address. Such messages trigger nodes already using the | "tentative" address. Such messages trigger nodes already using the | |||
skipping to change at page 55, line 45 | skipping to change at page 61, line 4 | |||
A Neighbor Advertisements that passes the validity checks is called a | A Neighbor Advertisements that passes the validity checks is called a | |||
"valid advertisement". | "valid advertisement". | |||
7.2. Address Resolution | 7.2. Address Resolution | |||
Address resolution is the process through which a node determines the | Address resolution is the process through which a node determines the | |||
link-layer address of a neighbor given only its IP address. Address | link-layer address of a neighbor given only its IP address. Address | |||
resolution is performed only on addresses that are determined to be | resolution is performed only on addresses that are determined to be | |||
on-link and for which the sender does not know the corresponding | on-link and for which the sender does not know the corresponding | |||
link-layer address (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 | |||
for the source of such a message, Address Resolution will be required | exist for the source of such a message, Address Resolution will be | |||
before unicast communications with that address can begin. This is | required before unicast communications with that address can begin. | |||
particularly relevant for unicast responses to solicitations where an | This is particularly relevant for unicast responses to solicitations | |||
additional packet exchange is required for advertisement delivery. | where an 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 | |||
the all-nodes multicast address on that interface, as well as the | join the all-nodes multicast address on that interface, as well as | |||
solicited-node multicast address corresponding to each of the IP | the 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 | |||
is done using a Multicast Listener Discovery such as [MLD] or [MLDv2] | address is done using a Multicast Listener Discovery such as [MLD] or | |||
protocols. Note that multiple unicast addresses may map into the same | [MLDv2] protocols. Note that multiple unicast addresses may map into | |||
solicited-node multicast address; a node MUST NOT leave the | the same 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 | |||
Neighbor Cache entry in the INCOMPLETE state and transmitting a | a Neighbor Cache entry in the INCOMPLETE state and transmitting a | |||
Neighbor Solicitation message targeted at the neighbor. The | Neighbor Solicitation message targeted at the neighbor. The | |||
solicitation is sent to the solicited-node multicast address | solicitation is sent to the solicited-node multicast address | |||
corresponding to the target address. | corresponding to the target address. | |||
If the source address of the packet prompting the solicitation is the | If the source address of the packet prompting the solicitation is the | |||
same as one of the addresses assigned to the outgoing interface, that | same as one of the addresses assigned to the outgoing interface, that | |||
address SHOULD be placed in the IP Source Address of the outgoing | address SHOULD be placed in the IP Source Address of the outgoing | |||
solicitation. Otherwise, any one of the addresses assigned to the | solicitation. Otherwise, any one of the addresses assigned to the | |||
interface should be used. Using the prompting packet's source | interface should be used. Using the prompting packet's source | |||
address when possible ensures that the recipient of the Neighbor | address when possible ensures that the recipient of the Neighbor | |||
skipping to change at page 57, line 36 | skipping to change at page 63, line 4 | |||
7.2.3. Receipt of Neighbor Solicitations | 7.2.3. Receipt of Neighbor Solicitations | |||
A valid Neighbor Solicitation that does not meet any of the following | A valid Neighbor Solicitation that does not meet any of the following | |||
requirements MUST be silently discarded: | requirements MUST be silently discarded: | |||
- The Target Address is a "valid" unicast or anycast address | - The Target Address is a "valid" unicast or anycast address | |||
assigned to the receiving interface [ADDRCONF], | assigned to the receiving interface [ADDRCONF], | |||
- 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. | |||
If a Neighbor Cache entry is created the IsRouter flag SHOULD be set | If a Neighbor Cache entry is created, the IsRouter flag SHOULD be set | |||
to FALSE. This will be the case even if the Neighbor Solicitation is | to FALSE. This will be the case even if the Neighbor Solicitation is | |||
sent by a router since the Neighbor Solicitation messages do not | sent by a router since the Neighbor Solicitation messages do not | |||
contain an indication of whether or not the sender is a router. In | contain an indication of whether or not the sender is a router. In | |||
the event that the sender is a router, subsequent Neighbor | the event that the sender is a router, subsequent Neighbor | |||
Advertisement or Router Advertisement messages will set the correct | Advertisement or Router Advertisement messages will set the correct | |||
IsRouter value. If a Neighbor Cache entry already exists its | IsRouter value. If a Neighbor Cache entry already exists, its | |||
IsRouter flag MUST NOT be modified. | IsRouter flag MUST NOT be modified. | |||
If the Source Address is the unspecified address the node MUST NOT | If the Source Address is the unspecified address, the node MUST NOT | |||
create or update the Neighbor Cache entry. | create or update the Neighbor Cache entry. | |||
After any updates to the Neighbor Cache, the node sends a Neighbor | After any updates to the Neighbor Cache, the node sends a Neighbor | |||
Advertisement response as described in the next section. | Advertisement response as described in the next section. | |||
7.2.4. Sending Solicited Neighbor Advertisements | 7.2.4. Sending Solicited Neighbor Advertisements | |||
A node sends a Neighbor Advertisement in response to a valid Neighbor | A node sends a Neighbor Advertisement in response to a valid Neighbor | |||
Solicitation targeting one of the node's assigned addresses. The | Solicitation targeting one of the node's assigned addresses. The | |||
Target Address of the advertisement is copied from the Target Address | Target Address of the advertisement is copied from the Target Address | |||
of the solicitation. If the solicitation's IP Destination Address is | of the solicitation. If the solicitation's IP Destination Address is | |||
not a multicast address, the Target Link-Layer Address option MAY be | not a multicast address, the Target Link-Layer Address option MAY be | |||
omitted; the neighboring node's cached value must already be current | omitted; the neighboring node's cached value must already be current | |||
in order for the solicitation to have been received. If the | in order for the solicitation to have been received. If the | |||
solicitation's IP Destination Address is a multicast address, the | solicitation's IP Destination Address is a multicast address, the | |||
Target Link-Layer option MUST be included in the advertisement. | Target Link-Layer option MUST be included in the advertisement. | |||
Furthermore, if the node is a router, it MUST set the Router flag to | Furthermore, if the node is a router, it MUST set the Router flag to | |||
one; otherwise it MUST set the flag to zero. | one; otherwise, it MUST set the flag to zero. | |||
If the Target Address is either an anycast address or a unicast | If the Target Address is either an anycast address or a unicast | |||
address for which the node is providing proxy service, or the Target | address for which the node is providing proxy service, or the Target | |||
Link-Layer Address option is not included, the Override flag SHOULD | Link-Layer Address option is not included, the Override flag SHOULD | |||
be set to zero. Otherwise, the Override flag SHOULD be set to one. | be set to zero. Otherwise, the Override flag SHOULD be set to one. | |||
Proper setting of the Override flag ensures that nodes give | Proper setting of the Override flag ensures that nodes give | |||
preference to non-proxy advertisements, even when received after | preference to non-proxy advertisements, even when received after | |||
proxy advertisements, and also ensures that the first advertisement | proxy advertisements, and also ensures that the first advertisement | |||
for an anycast address "wins". | for an anycast address "wins". | |||
If the source of the solicitation is the unspecified address, the | If the source of the solicitation is the unspecified address, the | |||
node MUST set the Solicited flag to zero and multicast the | node MUST set the Solicited flag to zero and multicast the | |||
advertisement to the all-nodes address. Otherwise, the node MUST set | advertisement to the all-nodes address. Otherwise, the node MUST set | |||
the Solicited flag to one and unicast the advertisement to the Source | the Solicited flag to one and unicast the advertisement to the Source | |||
Address of the solicitation. | Address of the solicitation. | |||
If the Target Address is an anycast address the sender SHOULD delay | If the Target Address is an anycast address, the sender SHOULD delay | |||
sending a response for a random time between 0 and | sending a response for a random time between 0 and | |||
MAX_ANYCAST_DELAY_TIME seconds. | MAX_ANYCAST_DELAY_TIME seconds. | |||
Because unicast Neighbor Solicitations are not required to include a | Because unicast Neighbor Solicitations are not required to include a | |||
Source Link-Layer Address, it is possible that a node sending a | Source Link-Layer Address, it is possible that a node sending a | |||
solicited Neighbor Advertisement does not have a corresponding link- | solicited Neighbor Advertisement does not have a corresponding link- | |||
layer address for its neighbor in its Neighbor Cache. In such | layer address for its neighbor in its Neighbor Cache. In such | |||
situations, a node will first have to use Neighbor Discovery to | situations, a node will first have to use Neighbor Discovery to | |||
determine the link-layer address of its neighbor (i.e., send out a | determine the link-layer address of its neighbor (i.e., send out a | |||
multicast Neighbor Solicitation). | multicast Neighbor Solicitation). | |||
skipping to change at page 59, line 19 | skipping to change at page 64, line 43 | |||
When a valid Neighbor Advertisement is received (either solicited or | When a valid Neighbor Advertisement is received (either solicited or | |||
unsolicited), the Neighbor Cache is searched for the target's entry. | unsolicited), the Neighbor Cache is searched for the target's entry. | |||
If no entry exists, the advertisement SHOULD be silently discarded. | If no entry exists, the advertisement SHOULD be silently discarded. | |||
There is no need to create an entry if none exists, since the | There is no need to create an entry if none exists, since the | |||
recipient has apparently not initiated any communication with the | recipient has apparently not initiated any communication with the | |||
target. | target. | |||
Once the appropriate Neighbor Cache entry has been located, the | Once the appropriate Neighbor Cache entry has been located, the | |||
specific actions taken depend on the state of the Neighbor Cache | specific actions taken depend on the state of the Neighbor Cache | |||
entry, the flags in the advertisement and the actual link-layer | entry, the flags in the advertisement, and the actual link-layer | |||
address supplied. | address supplied. | |||
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 | |||
flag in the received advertisement. | flag in the received advertisement. | |||
- It sends any packets queued for the neighbor awaiting address | - It sends any packets queued for the neighbor awaiting address | |||
resolution. | resolution. | |||
Note that the Override flag is ignored if the entry is in the | Note that the Override flag is ignored if the entry is in the | |||
INCOMPLETE state. | INCOMPLETE state. | |||
skipping to change at page 60, line 6 | skipping to change at page 65, line 32 | |||
I. If the Override flag is clear and the supplied link-layer address | I. If the Override flag is clear and the supplied link-layer address | |||
differs from that in the cache, then one of two actions takes | differs from that in the cache, then one of two actions takes | |||
place: | place: | |||
a. If the state of the entry is REACHABLE, set it to STALE, but | a. If the state of the entry is REACHABLE, set it to STALE, but | |||
do not update the entry in any other way. | do not update the entry in any other way. | |||
b. Otherwise, the received advertisement should be ignored and | 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 differs | MUST be inserted in the cache (if one is supplied and differs | |||
from 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, may indicate | Receipt of an unsolicited advertisement, however, may indicate | |||
that a neighbor has urgent information to announce (e.g., a | that a neighbor has urgent information to announce (e.g., a | |||
changed link-layer address). If the urgent information | changed link-layer address). If the urgent information | |||
indicates a change from what a node is currently using, the | indicates a change from what a node is currently using, the | |||
node should verify the reachability of the (new) path when it | node should verify the reachability of the (new) path when it | |||
sends the next packet. There is no need to update the state for | sends the next packet. There is no need to update the state | |||
unsolicited advertisements that do not change the contents of | for unsolicited advertisements that do not change the contents | |||
the cache. | of the cache. | |||
- The IsRouter flag in the cache entry MUST be set based on the | - The IsRouter flag in the cache entry MUST be set based on the | |||
Router flag in the received advertisement. In those cases | 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 | |||
node that is used as a router stops forwarding packets due to | node that is used as a router stops forwarding packets due to | |||
being configured as a host. | being configured as a host. | |||
The above rules ensure that the cache is updated either when the | The above rules ensure that the cache is updated either when the | |||
Neighbor Advertisement takes precedence (i.e., the Override flag is | Neighbor Advertisement takes precedence (i.e., the Override flag is | |||
set) or when the Neighbor Advertisement refers to the same link-layer | set) or when the Neighbor Advertisement refers to the same link-layer | |||
address that is currently recorded in the cache. If none of the | address that is currently recorded in the cache. If none of the | |||
above apply, the advertisement prompts future Neighbor Unreachability | above apply, the advertisement prompts future Neighbor Unreachability | |||
Detection (if it is not already in progress) by changing the state in | Detection (if it is not already in progress) by changing the state in | |||
the cache entry. | the cache entry. | |||
7.2.6. Sending Unsolicited Neighbor Advertisements | 7.2.6. Sending Unsolicited Neighbor Advertisements | |||
In some cases a node may be able to determine that its link-layer | ||||
In some cases, a node may be able to determine that its link-layer | ||||
address has changed (e.g., hot-swap of an interface card) and may | address has changed (e.g., hot-swap of an interface card) and may | |||
wish to inform its neighbors of the new link-layer address quickly. | wish to inform its neighbors of the new link-layer address quickly. | |||
In such cases a node MAY send up to MAX_NEIGHBOR_ADVERTISEMENT | In such cases, a node MAY send up to MAX_NEIGHBOR_ADVERTISEMENT | |||
unsolicited Neighbor Advertisement messages to the all-nodes | unsolicited Neighbor Advertisement messages to the all-nodes | |||
multicast address. These advertisements MUST be separated by at | multicast address. These advertisements MUST be separated by at | |||
least RetransTimer seconds. | least RetransTimer seconds. | |||
The Target Address field in the unsolicited advertisement is set to | The Target Address field in the unsolicited advertisement is set to | |||
an IP address of the interface, and the Target Link-Layer Address | an IP address of the interface, and the Target Link-Layer Address | |||
option is filled with the new link-layer address. The Solicited flag | option is filled with the new link-layer address. The Solicited flag | |||
MUST be set to zero, in order to avoid confusing the Neighbor | MUST be set to zero, in order to avoid confusing the Neighbor | |||
Unreachability Detection algorithm. If the node is a router, it MUST | Unreachability Detection algorithm. If the node is a router, it MUST | |||
set the Router flag to one; otherwise it MUST set it to zero. The | set the Router flag to one; otherwise, it MUST set it to zero. The | |||
Override flag MAY be set to either zero or one. In either case, | Override flag MAY be set to either zero or one. In either case, | |||
neighboring nodes will immediately change the state of their Neighbor | neighboring nodes will immediately change the state of their Neighbor | |||
Cache entries for the Target Address to STALE, prompting them to | Cache entries for the Target Address to STALE, prompting them to | |||
verify the path for reachability. If the Override flag is set to | verify the path for reachability. If the Override flag is set to | |||
one, neighboring nodes will install the new link-layer address in | one, neighboring nodes will install the new link-layer address in | |||
their caches. Otherwise, they will ignore the new link-layer | their caches. Otherwise, they will ignore the new link-layer | |||
address, choosing instead to probe the cached address. | address, choosing instead to probe the cached address. | |||
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 | |||
the proxies should provide a mechanism that prevents multiple proxies | addresses, the proxies should provide a mechanism that prevents | |||
from multicasting advertisements for any one address, in order to | multiple proxies from multicasting advertisements for any one | |||
reduce the risk of excessive multicast traffic. This is a requirement | address, in order to reduce the risk of excessive multicast traffic. | |||
on other protocols that need to use proxies for Neighbor | This is a requirement on other protocols that need to use proxies for | |||
Advertisements. An example of a node that performs proxy | Neighbor 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. | |||
Note that because unsolicited Neighbor Advertisements do not reliably | Note that because unsolicited Neighbor Advertisements do not reliably | |||
update caches in all nodes (the advertisements might not be received | update caches in all nodes (the advertisements might not be received | |||
by all nodes), they should only be viewed as a performance | by all nodes), they should only be viewed as a performance | |||
optimization to quickly update the caches in most neighbors. The | optimization to quickly update the caches in most neighbors. The | |||
skipping to change at page 62, line 44 | skipping to change at page 68, line 25 | |||
that has moved off-link. The mechanisms used by proxy are | that has moved off-link. The mechanisms used by proxy are | |||
essentially the same as 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 a multicast listener discovery | proxying. This SHOULD be done using a multicast listener discovery | |||
protocol such as [MLD] or [MLDv2]. | 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 to avoid collisions due | between 0 and MAX_ANYCAST_DELAY_TIME seconds to avoid collisions due | |||
to multiple responses sent by several proxies. However, in some cases | to multiple responses sent by several proxies. However, in some | |||
(e.g. Mobile IPv6) where only one proxy is present, such delay is not | cases (e.g., Mobile IPv6) where only one proxy is present, such delay | |||
necessary. | 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 63, line 42 | skipping to change at page 69, line 25 | |||
Neighbor Unreachability Detection is performed only for neighbors to | Neighbor Unreachability Detection is performed only for neighbors to | |||
which unicast packets are sent; it is not used when sending to | which unicast packets are sent; it is not used when sending to | |||
multicast addresses. | multicast addresses. | |||
7.3.1. Reachability Confirmation | 7.3.1. Reachability Confirmation | |||
A neighbor is considered reachable if the node has recently received | A neighbor is considered reachable if the node has recently received | |||
a confirmation that packets sent recently to the neighbor were | a confirmation that packets sent recently to the neighbor were | |||
received by its IP layer. Positive confirmation can be gathered in | received by its IP layer. Positive confirmation can be gathered in | |||
two ways: hints from upper layer protocols that indicate a connection | two ways: hints from upper-layer protocols that indicate a connection | |||
is making "forward progress", or receipt of a Neighbor Advertisement | is making "forward progress", or receipt of a Neighbor Advertisement | |||
message that is a response to a Neighbor Solicitation message. | message that is a response to a Neighbor Solicitation message. | |||
A connection makes "forward progress" if the packets received from a | A connection makes "forward progress" if the packets received from a | |||
remote peer can only be arriving if recent packets sent to that peer | remote peer can only be arriving if recent packets sent to that peer | |||
are actually reaching it. In TCP, for example, receipt of a (new) | are actually reaching it. In TCP, for example, receipt of a (new) | |||
acknowledgement indicates that previously sent data reached the peer. | acknowledgment indicates that previously sent data reached the peer. | |||
Likewise, the arrival of new (non-duplicate) data indicates that | Likewise, the arrival of new (non-duplicate) data indicates that | |||
earlier acknowledgements are being delivered to the remote peer. If | earlier acknowledgments are being delivered to the remote peer. If | |||
packets are reaching the peer, they must also be reaching the | packets are reaching the peer, they must also be reaching the | |||
sender's next-hop neighbor; thus "forward progress" is a confirmation | sender's next-hop neighbor; thus, "forward progress" is a | |||
that the next-hop neighbor is reachable. For off-link destinations, | confirmation that the next-hop neighbor is reachable. For off-link | |||
forward progress implies that the first-hop router is reachable. | destinations, forward progress implies that the first-hop router is | |||
When available, this upper-layer information SHOULD be used. | reachable. When available, this upper-layer information SHOULD be | |||
used. | ||||
In some cases (e.g., UDP-based protocols and routers forwarding | In some cases (e.g., UDP-based protocols and routers forwarding | |||
packets to hosts) such reachability information may not be readily | packets to hosts), such reachability information may not be readily | |||
available from upper-layer protocols. When no hints are available | available from upper-layer protocols. When no hints are available | |||
and a node is sending packets to a neighbor, the node actively probes | and a node is sending packets to a neighbor, the node actively probes | |||
the neighbor using unicast Neighbor Solicitation messages to verify | the neighbor using unicast Neighbor Solicitation messages to verify | |||
that the forward path is still working. | that the forward path is still working. | |||
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 its perspective, not the neighbor's | forward path to a neighbor from its perspective, not the neighbor's | |||
perspective. Note that receipt of a solicited advertisement | perspective. Note that receipt of a solicited advertisement | |||
indicates that a path is working in both directions. The solicitation | indicates that a path is working in both directions. The | |||
must have reached the neighbor, prompting it to generate an | solicitation must have reached the neighbor, prompting it to generate | |||
advertisement. Likewise, receipt of an advertisement indicates that | an advertisement. Likewise, receipt of an advertisement indicates | |||
the path from the sender to the recipient is working. However, the | that the path from the sender to the recipient is working. However, | |||
latter fact is known only to the recipient; the advertisement's | the latter fact is known only to the recipient; the advertisement's | |||
sender has no direct way of knowing that the advertisement it sent | sender has no direct way of knowing that the advertisement it sent | |||
actually reached a neighbor. From the perspective of Neighbor | actually reached a neighbor. From the perspective of Neighbor | |||
Unreachability Detection, only the reachability of the forward path | Unreachability Detection, only the 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. | |||
skipping to change at page 65, line 9 | skipping to change at page 70, line 48 | |||
STALE More than ReachableTime milliseconds have elapsed | STALE More than ReachableTime milliseconds have elapsed | |||
since the last positive confirmation was received that | since the last positive confirmation was received that | |||
the forward path was functioning properly. While | the forward path was functioning properly. While | |||
stale, no action takes place until a packet is sent. | stale, no action takes place until a packet is sent. | |||
The STALE state is entered upon receiving an | The STALE state is entered upon receiving an | |||
unsolicited Neighbor Discovery message that updates | unsolicited Neighbor Discovery message that updates | |||
the cached link-layer address. Receipt of such a | the cached link-layer address. Receipt of such a | |||
message does not confirm reachability, and entering | message does not confirm reachability, and entering | |||
the STALE state insures reachability is verified | the STALE state ensures reachability is verified | |||
quickly if the entry is actually being used. However, | quickly if the entry is actually being used. However, | |||
reachability is not actually verified until the entry | reachability is not actually verified until the entry | |||
is actually used. | is actually used. | |||
DELAY More than ReachableTime milliseconds have elapsed | DELAY More than ReachableTime milliseconds have elapsed | |||
since the last positive confirmation was received that | since the last positive confirmation was received that | |||
the forward path was functioning properly, and a | the forward path was functioning properly, and a | |||
packet was sent within the last DELAY_FIRST_PROBE_TIME | packet was sent within the last DELAY_FIRST_PROBE_TIME | |||
seconds. If no reachability confirmation is received | seconds. If no reachability confirmation is received | |||
within DELAY_FIRST_PROBE_TIME seconds of entering the | within DELAY_FIRST_PROBE_TIME seconds of entering the | |||
DELAY state, send a Neighbor Solicitation and change | DELAY state, send a Neighbor Solicitation and change | |||
the state to PROBE. | the state to PROBE. | |||
The DELAY state is an optimization that gives upper- | The DELAY state is an optimization that gives upper- | |||
layer protocols additional time to provide | layer protocols additional time to provide | |||
reachability confirmation in those cases where | reachability confirmation in those cases where | |||
ReachableTime milliseconds have passed since the last | ReachableTime milliseconds have passed since the last | |||
confirmation due to lack of recent traffic. Without | confirmation due to lack of recent traffic. Without | |||
this optimization the opening of a TCP connection | this optimization, the opening of a TCP connection | |||
after a traffic lull would initiate probes even though | after a traffic lull would initiate probes even though | |||
the subsequent three-way handshake would provide a | the subsequent three-way handshake would provide a | |||
reachability confirmation almost immediately. | reachability confirmation almost immediately. | |||
PROBE A reachability confirmation is actively sought by | PROBE A reachability confirmation is actively sought by | |||
retransmitting Neighbor Solicitations every | retransmitting Neighbor Solicitations every | |||
RetransTimer milliseconds until a reachability | RetransTimer milliseconds until a reachability | |||
confirmation is received. | confirmation is received. | |||
7.3.3. Node Behavior | 7.3.3. Node Behavior | |||
skipping to change at page 65, line 51 | skipping to change at page 71, line 42 | |||
sending of packets to a neighbor. While reasserting a neighbor's | sending of packets to a neighbor. While reasserting a neighbor's | |||
reachability, a node continues sending packets to that neighbor using | reachability, a node continues sending packets to that neighbor using | |||
the cached link-layer address. If no traffic is sent to a neighbor, | the cached link-layer address. If no traffic is sent to a neighbor, | |||
no probes are sent. | no probes are sent. | |||
When a node needs to perform address resolution on a neighboring | When a node needs to perform address resolution on a neighboring | |||
address, it creates an entry in the INCOMPLETE state and initiates | address, it creates an entry in the INCOMPLETE state and initiates | |||
address resolution as specified in Section 7.2. If address | address resolution as specified in Section 7.2. If address | |||
resolution fails, the entry SHOULD be deleted, so that subsequent | resolution fails, the entry SHOULD be deleted, so that subsequent | |||
traffic to that neighbor invokes the next-hop determination procedure | traffic to that neighbor invokes the next-hop determination procedure | |||
again. Invoking next-hop determination at this point insures that | again. Invoking next-hop determination at this point ensures that | |||
alternate default routers are tried. | alternate default routers are tried. | |||
When a reachability confirmation is received (either through upper- | When a reachability confirmation is received (either through upper- | |||
layer advice or a solicited Neighbor Advertisement) an entry's state | layer advice or a solicited Neighbor Advertisement), an entry's state | |||
changes to REACHABLE. The one exception is that upper-layer advice | changes to REACHABLE. The one exception is that upper-layer advice | |||
has no effect on entries in the INCOMPLETE state (e.g., for which no | has no effect on entries in the INCOMPLETE state (e.g., for which no | |||
link-layer address is cached). | link-layer address is cached). | |||
When ReachableTime milliseconds have passed since receipt of the last | When ReachableTime milliseconds have passed since receipt of the last | |||
reachability confirmation for a neighbor, the Neighbor Cache entry's | reachability confirmation for a neighbor, the Neighbor Cache entry's | |||
state changes from REACHABLE to STALE. | state changes from REACHABLE to STALE. | |||
Note: An implementation may actually defer changing the state from | Note: An implementation may actually defer changing the state from | |||
REACHABLE to STALE until a packet is sent to the neighbor, i.e., | REACHABLE to STALE until a packet is sent to the neighbor, i.e., | |||
there need not be an explicit timeout event associated with the | there need not be an explicit timeout event associated with the | |||
expiration of ReachableTime. | expiration of ReachableTime. | |||
The first time a node sends a packet to a neighbor whose entry is | The first time a node sends a packet to a neighbor whose entry is | |||
STALE, the sender changes the state to DELAY and a sets a timer to | STALE, the sender changes the state to DELAY and sets a timer to | |||
expire in DELAY_FIRST_PROBE_TIME seconds. If the entry is still in | expire in DELAY_FIRST_PROBE_TIME seconds. If the entry is still in | |||
the DELAY state when the timer expires, the entry's state changes to | the DELAY state when the timer expires, the entry's state changes to | |||
PROBE. If reachability confirmation is received, the entry's state | PROBE. If reachability confirmation is received, the entry's state | |||
changes to REACHABLE. | changes to REACHABLE. | |||
Upon entering the PROBE state, a node sends a unicast Neighbor | Upon entering the PROBE state, a node sends a unicast Neighbor | |||
Solicitation message to the neighbor using the cached link-layer | Solicitation message to the neighbor using the cached link-layer | |||
address. While in the PROBE state, a node retransmits Neighbor | address. While in the PROBE state, a node retransmits Neighbor | |||
Solicitation messages every RetransTimer milliseconds until | Solicitation messages every RetransTimer milliseconds until | |||
reachability confirmation is obtained. Probes are retransmitted even | reachability confirmation is obtained. Probes are retransmitted even | |||
if no additional packets are sent to the neighbor. If no response is | if no additional packets are sent to the neighbor. If no response is | |||
received after waiting RetransTimer milliseconds after sending the | received after waiting RetransTimer milliseconds after sending the | |||
MAX_UNICAST_SOLICIT solicitations, retransmissions cease and the | MAX_UNICAST_SOLICIT solicitations, retransmissions cease and the | |||
entry SHOULD be deleted. Subsequent traffic to that neighbor will | entry SHOULD be deleted. Subsequent traffic to that neighbor will | |||
recreate the entry and performs address resolution again. | recreate the entry and perform address resolution again. | |||
Note that all Neighbor Solicitations are rate-limited on a per- | Note that all Neighbor Solicitations are rate-limited on a per- | |||
neighbor basis. A node MUST NOT send Neighbor Solicitations to the | neighbor basis. A node MUST NOT send Neighbor Solicitations to the | |||
same neighbor more frequently than once every RetransTimer | same neighbor more frequently than once every RetransTimer | |||
milliseconds. | milliseconds. | |||
A Neighbor Cache entry enters the STALE state when created as a | A Neighbor Cache entry enters the STALE state when created as a | |||
result of receiving packets other than solicited Neighbor | result of receiving packets other than solicited Neighbor | |||
Advertisements (i.e., Router Solicitations, Router Advertisements, | Advertisements (i.e., Router Solicitations, Router Advertisements, | |||
Redirects, and Neighbor Solicitations). These packets contain the | Redirects, and Neighbor Solicitations). These packets contain the | |||
link-layer address of either the sender or, in the case of Redirect, | link-layer address of either the sender or, in the case of Redirect, | |||
the redirection target. However, receipt of these link-layer | the redirection target. However, receipt of these link-layer | |||
addresses does not confirm reachability of the forward-direction path | addresses does not confirm reachability of the forward-direction path | |||
to that node. Placing a newly created Neighbor Cache entry for which | to that node. Placing a newly created Neighbor Cache entry for which | |||
the link-layer address is known in the STALE state provides assurance | the link-layer address is known in the STALE state provides assurance | |||
that path failures are detected quickly. In addition, should a | that path failures are detected quickly. In addition, should a | |||
cached link-layer address be modified due to receiving one of the | cached link-layer address be modified due to receiving one of the | |||
above messages the state SHOULD also be set to STALE to provide | above messages, the state SHOULD also be set to STALE to provide | |||
prompt verification that the path to the new link-layer address is | prompt verification that the path to the new link-layer address is | |||
working. | working. | |||
To properly detect the case where a router switches from being a | To properly detect the case where a router switches from being a | |||
router to being a host (e.g., if its IP forwarding capability is | router to being a host (e.g., if its IP forwarding capability is | |||
turned off by system management), a node MUST compare the Router flag | turned off by system management), a node MUST compare the Router flag | |||
field in all received Neighbor Advertisement messages with the | field in all received Neighbor Advertisement messages with the | |||
IsRouter flag recorded in the Neighbor Cache entry. When a node | IsRouter flag recorded in the Neighbor Cache entry. When a node | |||
detects that a neighbor has changed from being a router to being a | detects that a neighbor has changed from being a router to being a | |||
host, the node MUST remove that router from the Default Router List | host, the node MUST remove that router from the Default Router List | |||
skipping to change at page 67, line 27 | skipping to change at page 73, line 27 | |||
again before using the entry. | again before using the entry. | |||
In some cases, link-specific information may indicate that a path to | In some cases, link-specific information may indicate that a path to | |||
a neighbor has failed (e.g., the resetting of a virtual circuit). In | a neighbor has failed (e.g., the resetting of a virtual circuit). In | |||
such cases, link-specific information may be used to purge Neighbor | such cases, link-specific information may be used to purge Neighbor | |||
Cache entries before the Neighbor Unreachability Detection would do | Cache entries before the Neighbor Unreachability Detection would do | |||
so. However, link-specific information MUST NOT be used to confirm | so. However, link-specific information MUST NOT be used to confirm | |||
the reachability of a neighbor; such information does not provide | the reachability of a neighbor; such information does not provide | |||
end-to-end confirmation between neighboring IP layers. | end-to-end confirmation between neighboring IP layers. | |||
8. REDIRECT FUNCTION | 8. Redirect Function | |||
This section describes the functions related to the sending and | This section describes the functions related to the sending and | |||
processing of Redirect messages. | processing of Redirect messages. | |||
Redirect messages are sent by routers to redirect a host to a better | Redirect messages are sent by routers to redirect a host to a better | |||
first-hop router for a specific destination or to inform hosts that a | first-hop router for a specific destination or to inform hosts that a | |||
destination is in fact a neighbor (i.e., on-link). The latter is | destination is in fact a neighbor (i.e., on-link). The latter is | |||
accomplished by having the ICMP Target Address be equal to the ICMP | accomplished by having the ICMP Target Address be equal to the ICMP | |||
Destination Address. | Destination Address. | |||
A router MUST be able to determine the link-local address for each of | A router MUST be able to determine the link-local address for each of | |||
its neighboring routers in order to ensure that the target address in | its neighboring routers in order to ensure that the target address in | |||
a Redirect message identifies the neighbor router by its link-local | a Redirect message identifies the neighbor router by its link-local | |||
address. For static routing this requirement implies that the next- | address. For static routing, this requirement implies that the next- | |||
hop router's address should be specified using the link-local address | hop router's address should be specified using the link-local address | |||
of the router. For dynamic routing this requirement implies that all | of the router. For dynamic routing, this requirement implies that | |||
IPv6 routing protocols must somehow exchange the link-local addresses | all IPv6 routing protocols must somehow exchange the link-local | |||
of neighboring routers. | addresses of neighboring routers. | |||
8.1. Validation of Redirect Messages | 8.1. Validation of Redirect Messages | |||
A host MUST silently discard any received Redirect message that does | A host MUST silently discard any received Redirect message that does | |||
not satisfy all of the following validity checks: | not satisfy all of the following validity checks: | |||
- IP Source Address is a link-local address. Routers must use | - IP Source Address is a link-local address. Routers must use | |||
their link-local address as the source for Router Advertisement | their link-local address as the source for Router Advertisement | |||
and Redirect messages so that hosts can uniquely identify | and Redirect messages so that hosts can uniquely identify | |||
routers. | routers. | |||
skipping to change at page 68, line 27 | skipping to change at page 74, line 36 | |||
- The ICMP Destination Address field in the redirect message does | - The ICMP Destination Address field in the redirect message does | |||
not contain a multicast address. | not contain a multicast address. | |||
- The ICMP Target Address is either a link-local address (when | - The ICMP Target Address is either a link-local address (when | |||
redirected to a router) or the same as the ICMP Destination | redirected to a router) or the same as the ICMP Destination | |||
Address (when redirected to the on-link destination). | Address (when redirected to the on-link destination). | |||
- All included options have a length that is greater than zero. | - All included options have a length that is greater than zero. | |||
The contents of the Reserved field, and of any unrecognized options | The contents of the Reserved field, and of any unrecognized options, | |||
MUST be ignored. Future, backward-compatible changes to the protocol | MUST be ignored. Future, backward-compatible changes to the protocol | |||
may specify the contents of the Reserved field or add new options; | may specify the contents of the Reserved field or add new options; | |||
backward-incompatible changes may use different Code values. | backward-incompatible changes may use different Code values. | |||
The contents of any defined options that are not specified to be used | The contents of any defined options that are not specified to be used | |||
with Redirect messages MUST be ignored and the packet processed as | with Redirect messages MUST be ignored and the packet processed as | |||
normal. The only defined options that may appear are the Target | normal. The only defined options that may appear are the Target | |||
Link-Layer Address option and the Redirected Header option. | Link-Layer Address option and the Redirected Header option. | |||
A host MUST NOT consider a redirect invalid just because the Target | A host MUST NOT consider a redirect invalid just because the Target | |||
skipping to change at page 68, line 49 | skipping to change at page 75, line 9 | |||
prefixes. Part of the semantics of the Redirect message is that the | prefixes. Part of the semantics of the Redirect message is that the | |||
Target Address is on-link. | Target Address is on-link. | |||
A redirect that passes the validity checks is called a "valid | A redirect that passes the validity checks is called a "valid | |||
redirect". | redirect". | |||
8.2. Router Specification | 8.2. Router Specification | |||
A router SHOULD send a redirect message, subject to rate limiting, | A router SHOULD send a redirect message, subject to rate limiting, | |||
whenever it forwards a packet that is not explicitly addressed to | whenever it forwards a packet that is not explicitly addressed to | |||
itself (i.e. a packet that is not source routed through the router) | itself (i.e., a packet that is not source routed through the router) | |||
in which: | in which: | |||
- the Source Address field of the packet identifies a neighbor, | - the Source Address field of the packet identifies a neighbor, | |||
and | and | |||
- the router determines (by means outside the scope of this | - the router determines (by means outside the scope of this | |||
specification) that a better first-hop node resides on | specification) that a better first-hop node resides on the same | |||
the same link as the sending node for the Destination Address of | link as the sending node for the Destination Address of the | |||
the packet being forwarded, and | 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 | |||
target, if known. | target, if known. | |||
skipping to change at page 69, line 50 | skipping to change at page 76, line 12 | |||
A router MUST NOT update its routing tables upon receipt of a | A router MUST NOT update its routing tables upon receipt of a | |||
Redirect. | Redirect. | |||
8.3. Host Specification | 8.3. Host Specification | |||
A host receiving a valid redirect SHOULD update its Destination Cache | A host receiving a valid redirect SHOULD update its Destination Cache | |||
accordingly so that subsequent traffic goes to the specified target. | accordingly so that subsequent traffic goes to the specified target. | |||
If no Destination Cache entry exists for the destination, an | If no Destination Cache entry exists for the destination, an | |||
implementation SHOULD create such an entry. | implementation SHOULD create such an entry. | |||
If the redirect contains a Target Link-Layer Address option the host | If the redirect contains a Target Link-Layer Address option, the host | |||
either creates or updates the Neighbor Cache entry for the target. | either creates or updates the Neighbor Cache entry for the target. | |||
In both cases the cached link-layer address is copied from the Target | In both cases, the cached link-layer address is copied from the | |||
Link-Layer Address option. If a Neighbor Cache entry is created for | Target Link-Layer Address option. If a Neighbor Cache entry is | |||
the target its reachability state MUST be set to STALE as specified | created for the target, its reachability state MUST be set to STALE | |||
in Section 7.3.3. If a cache entry already existed and it is updated | as specified in Section 7.3.3. If a cache entry already existed and | |||
with a different link-layer address, its reachability state MUST also | it is updated with a different link-layer address, its reachability | |||
be set to STALE. If the link-layer address is the same as that | state MUST also be set to STALE. If the link-layer address is the | |||
already in the cache, the cache entry's state remains unchanged. | same as that already in the cache, the cache entry's state remains | |||
unchanged. | ||||
If the Target and Destination Addresses are the same, the host MUST | If the Target and Destination Addresses are the same, the host MUST | |||
treat the Target as on-link. If the Target Address is not the same | treat the Target as on-link. If the Target Address is not the same | |||
as the Destination Address, the host MUST set IsRouter to TRUE for | as the Destination Address, the host MUST set IsRouter to TRUE for | |||
the target. If the Target and Destination Addresses are the same, | the target. If the Target and Destination Addresses are the same, | |||
however, one cannot reliably determine whether the Target Address is | however, one cannot reliably determine whether the Target Address is | |||
a router. Consequently, newly created Neighbor Cache entries should | a router. Consequently, newly created Neighbor Cache entries should | |||
set the IsRouter flag to FALSE, while existing cache entries should | set the IsRouter flag to FALSE, while existing cache entries should | |||
leave the flag unchanged. If the Target is a router, subsequent | leave the flag unchanged. If the Target is a router, subsequent | |||
Neighbor Advertisement or Router Advertisement messages will update | Neighbor Advertisement or Router Advertisement messages will update | |||
IsRouter accordingly. | IsRouter accordingly. | |||
Redirect messages apply to all flows that are being sent to a given | Redirect messages apply to all flows that are being sent to a given | |||
destination. That is, upon receipt of a Redirect for a Destination | destination. That is, upon receipt of a Redirect for a Destination | |||
Address, all Destination Cache entries to that address should be | Address, all Destination Cache entries to that address should be | |||
updated to use the specified next-hop, regardless of the contents of | updated to use the specified next-hop, regardless of the contents of | |||
the Flow Label field that appears in the Redirected Header option. | the Flow Label field that appears in the Redirected Header option. | |||
A host MUST NOT send Redirect messages. | A host MUST NOT send Redirect messages. | |||
9. EXTENSIBILITY - OPTION PROCESSING | 9. Extensibility - Option Processing | |||
Options provide a mechanism for encoding variable length fields, | Options provide a mechanism for encoding variable length fields, | |||
fields that may appear multiple times in the same packet, or | fields that may appear multiple times in the same packet, or | |||
information that may not appear in all packets. Options can also be | information that may not appear in all packets. Options can also be | |||
used to add additional functionality to future versions of ND. | used to add additional functionality to future versions of ND. | |||
In order to ensure that future extensions properly coexist with | In order to ensure that future extensions properly coexist with | |||
current implementations, all nodes MUST silently ignore any options | current implementations, all nodes MUST silently ignore any options | |||
they do not recognize in received ND packets and continue processing | they do not recognize in received ND packets and continue processing | |||
the packet. All options specified in this document MUST be | the packet. All options specified in this document MUST be | |||
recognized. A node MUST NOT ignore valid options just because the ND | recognized. A node MUST NOT ignore valid options just because the ND | |||
message contains unrecognized ones. | message contains unrecognized ones. | |||
The current set of options is defined in such a way that receivers | The current set of options is defined in such a way that receivers | |||
can process multiple options in the same packet independently of each | can process multiple options in the same packet independently of each | |||
other. In order to maintain these properties future options SHOULD | other. In order to maintain these properties, future options SHOULD | |||
follow the simple rule: | follow the simple rule: | |||
The option MUST NOT depend on the presence or absence of any | The option MUST NOT depend on the presence or absence of any other | |||
other options. The semantics of an option should depend only on | options. The semantics of an option should depend only on the | |||
the information in the fixed part of the ND packet and on the | information in the fixed part of the ND packet and on the | |||
information contained in the option itself. | information contained in the option itself. | |||
Adhering to the above rule has the following benefits: | Adhering to the above rule has the following benefits: | |||
1) Receivers can process options independently of one another. For | 1) Receivers can process options independently of one another. For | |||
example, an implementation can choose to process the Prefix | example, an implementation can choose to process the Prefix | |||
Information option contained in a Router Advertisement message | Information option contained in a Router Advertisement message | |||
in a user-space process while the link-layer address option in | in a user-space process while the link-layer address option in | |||
the same message is processed by routines in the kernel. | the same message is processed by routines in the kernel. | |||
skipping to change at page 71, line 30 | skipping to change at page 77, line 46 | |||
receivers should only act on the expiration of timers and on the | receivers should only act on the expiration of timers and on the | |||
information that is received in the packets. | information that is received in the packets. | |||
Options in Neighbor Discovery packets can appear in any order; | Options in Neighbor Discovery packets can appear in any order; | |||
receivers MUST be prepared to process them independently of their | receivers MUST be prepared to process them independently of their | |||
order. There can also be multiple instances of the same option in a | order. There can also be multiple instances of the same option in a | |||
message (e.g., Prefix Information options). | message (e.g., Prefix Information options). | |||
If the number of included options in a Router Advertisement causes | If the number of included options in a Router Advertisement causes | |||
the advertisement's size to exceed the link MTU, the router can send | the advertisement's size to exceed the link MTU, the router can send | |||
multiple separate advertisements each containing a subset of the | multiple separate advertisements, each containing a subset of the | |||
options. | options. | |||
The amount of data to include in the Redirected Header option MUST be | The amount of data to include in the Redirected Header option MUST be | |||
limited so that the entire redirect packet does not exceed the | limited so that the entire redirect packet does not exceed the | |||
minimum MTU required to support IPv6 as specified in [IPv6]. | minimum MTU required to support IPv6 as specified in [IPv6]. | |||
All options are a multiple of 8 octets of length, ensuring | All options are a multiple of 8 octets of length, ensuring | |||
appropriate alignment without any "pad" options. The fields in the | appropriate alignment without any "pad" options. The fields in the | |||
options (as well as the fields in ND packets) are defined to align on | options (as well as the fields in ND packets) are defined to align on | |||
their natural boundaries (e.g., a 16-bit field is aligned on a 16-bit | their natural boundaries (e.g., a 16-bit field is aligned on a 16-bit | |||
boundary) with the exception of the 128-bit IP addresses/prefixes, | boundary) with the exception of the 128-bit IP addresses/prefixes, | |||
which are aligned on a 64-bit boundary. The link-layer address field | which are aligned on a 64-bit boundary. The link-layer address field | |||
contains an uninterpreted octet string; it is aligned on an 8-bit | contains an uninterpreted octet string; it is aligned on an 8-bit | |||
boundary. | boundary. | |||
The size of an ND packet including the IP header is limited to the | The size of an ND packet including the IP header is limited to the | |||
link MTU. When adding options to an ND packet a node MUST NOT exceed | link MTU. When adding options to an ND packet, a node MUST NOT | |||
the link MTU. | exceed the link MTU. | |||
Future versions of this protocol may define new option types. | Future versions of this protocol may define new option types. | |||
Receivers MUST silently ignore any options they do not recognize and | Receivers MUST silently ignore any options they do not recognize and | |||
continue processing the message. | continue processing the message. | |||
10. PROTOCOL CONSTANTS | 10. Protocol Constants | |||
Router constants: | Router constants: | |||
MAX_INITIAL_RTR_ADVERT_INTERVAL 16 seconds | MAX_INITIAL_RTR_ADVERT_INTERVAL 16 seconds | |||
MAX_INITIAL_RTR_ADVERTISEMENTS 3 transmissions | MAX_INITIAL_RTR_ADVERTISEMENTS 3 transmissions | |||
MAX_FINAL_RTR_ADVERTISEMENTS 3 transmissions | MAX_FINAL_RTR_ADVERTISEMENTS 3 transmissions | |||
MIN_DELAY_BETWEEN_RAS 3 seconds | MIN_DELAY_BETWEEN_RAS 3 seconds | |||
skipping to change at page 72, line 51 | skipping to change at page 79, line 21 | |||
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 | |||
mechanisms that can mitigate these threats. | mechanisms that can mitigate these threats. | |||
11.1 Threat analysis | 11.1. Threat Analysis | |||
This section discusses the main threats associated with Neighbor | This section discusses the main threats associated with Neighbor | |||
Discovery. A more detailed analysis can be found in [PSREQ]. The main | Discovery. A more detailed analysis can be found in [PSREQ]. The | |||
vulnerabilities of the protocol fall under three categories: | main vulnerabilities of the protocol fall under three categories: | |||
- Denial of Service (DoS) attacks. | - Denial-of-Service (DoS) attacks. | |||
- Address spoofing attacks. | - Address spoofing attacks. | |||
- Router spoofing attacks. | - Router spoofing attacks. | |||
An example of denial of service attacks is that a node on the link | An example of denial of service attacks is that a node on the link | |||
that can send packets with an arbitrary IP source address can both | that can send packets with an arbitrary IP source address can both | |||
advertise itself as a default router and also send "forged" Router | advertise itself as a default router and also send "forged" Router | |||
Advertisement messages that immediately time out all other default | Advertisement messages that immediately time out all other default | |||
routers as well as all on-link prefixes. An intruder can achieve | routers as well as all on-link prefixes. An intruder can achieve | |||
this by sending out multiple Router Advertisements, one for each | this by sending out multiple Router Advertisements, one for each | |||
legitimate router, with the source address set to the address of | legitimate router, with the source address set to the address of | |||
another router, the Router Lifetime field set to zero, and the | another router, the Router Lifetime field set to zero, and the | |||
Preferred and Valid lifetimes set to zero for all the prefixes. Such | Preferred and Valid lifetimes set to zero for all the prefixes. Such | |||
an attack would cause all packets, for both on-link and off-link | an attack would cause all packets, for both on-link and off-link | |||
destinations, to go to the rogue router. That router can then | destinations, to go to the rogue router. That router can then | |||
selectively examine, modify or drop all packets sent on the link. The | selectively examine, modify, or drop all packets sent on the link. | |||
Neighbor Unreachability Detection (NUD) will not detect such a black | The Neighbor Unreachability Detection (NUD) will not detect such a | |||
hole as long as the rogue router politely answers the NUD probes with | black hole as long as the rogue router politely answers the NUD | |||
a Neighbor Advertisement with the R-bit set. | probes with a Neighbor Advertisement with the R-bit set. | |||
It is also possible for any host to launch a DoS attack on another | It is also possible for any host to launch a DoS attack on another | |||
host by preventing it from configuring an address using [ADDRCONF]. | host by preventing it from configuring an address using [ADDRCONF]. | |||
The protocol does not allow hosts to verify whether the sender of a | The protocol does not allow hosts to verify whether the sender of a | |||
Neighbor Advertisement is the true owner of the IP address included | Neighbor Advertisement is the true owner of the IP address included | |||
in the message. | in the message. | |||
Redirect attacks can also be achieved by any host in order to flood a | Redirect attacks can also be achieved by any host in order to flood a | |||
victim or steal its traffic. A host can send a Neighbor advertisement | victim or steal its traffic. A host can send a Neighbor | |||
(in response to a solicitation) that contains its IP address and a | Advertisement (in response to a solicitation) that contains its IP | |||
victim's link-layer address in order to flood the victim with | address and a victim's link-layer address in order to flood the | |||
unwanted traffic. Alternatively, the host can send a Neighbor | victim with unwanted traffic. Alternatively, the host can send a | |||
Advertisement that includes a victim's IP address and its own link- | Neighbor Advertisement that includes a victim's IP address and its | |||
layer address to overwrite an existing entry in the sender's | own link-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 | |||
being redirected; the target host, once subverted, could always act | being redirected; the target host, once subverted, could always act | |||
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 (Carrier | |||
(e.g., by sending packets closely back-to-back or asserting the | Sense Multiple Access with Collision Detection) networks (e.g., by | |||
collision signal on the link), or originating packets with somebody | sending packets closely back-to-back or asserting the collision | |||
else's source MAC address to confuse, e.g., Ethernet switches. On the | signal on the link), or originating packets with somebody else's | |||
other hand, many of the threats discussed in this section are less | source MAC address to confuse, e.g., Ethernet switches. On the 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 | |||
The protocol reduces the exposure to the above threats in the absence | The protocol reduces the exposure to the above threats in the absence | |||
of authentication by ignoring ND packets received from off-link | of authentication by ignoring ND packets received from off-link | |||
senders. The Hop Limit field of all received packets is verified to | senders. The Hop Limit field of all received packets is verified to | |||
contain 255, the maximum legal value. Because routers decrement the | contain 255, the maximum legal value. Because routers decrement the | |||
Hop Limit on all packets they forward, received packets containing a | Hop Limit on all packets they forward, received packets containing a | |||
Hop Limit of 255 must have originated from a neighbor. | Hop Limit of 255 must have originated from a neighbor. | |||
Cryptographic security mechanisms for Neighbor Discovery are outside | Cryptographic security mechanisms for Neighbor Discovery are outside | |||
the scope of this document and are defined in [SEND]. Alternatively, | the scope of this document and are defined in [SEND]. Alternatively, | |||
skipping to change at page 75, line 7 | skipping to change at page 81, line 34 | |||
In some cases, it may be acceptable to use statically configured | In some cases, it may be acceptable to use statically configured | |||
security associations with either [IPv6-AUTH] or [IPv6-ESP] to secure | security associations with either [IPv6-AUTH] or [IPv6-ESP] to secure | |||
Neighbor Discovery messages. However, it is important to note that | Neighbor Discovery messages. However, it is important to note that | |||
statically configured security associations are not scalable | statically configured security associations are not scalable | |||
(especially when considering multicast links) and are therefore | (especially when considering multicast links) and are therefore | |||
limited to small networks with known hosts. In any case, if either | limited to small networks with known hosts. In any case, if either | |||
[IPv6-AUTH] or [IPv6-ESP] is used, ND packets MUST be verified for | [IPv6-AUTH] or [IPv6-ESP] is used, ND packets MUST be verified for | |||
the purpose of authentication. Packets that fail authentication | the purpose of authentication. Packets that fail authentication | |||
checks MUST be silently discarded. | checks MUST be silently discarded. | |||
12. RENUMBERING CONSIDERATIONS | 12. Renumbering Considerations | |||
The Neighbor Discovery protocol together with IPv6 Address | The Neighbor Discovery protocol together with IPv6 Address | |||
Autoconfiguration [ADDRCONF] provides mechanisms to aid in | Autoconfiguration [ADDRCONF] provides mechanisms to aid in | |||
renumbering - new prefixes and addresses can be introduced and old | renumbering -- new prefixes and addresses can be introduced and old | |||
ones can be deprecated and removed. | ones can be deprecated and removed. | |||
The robustness of these mechanisms is based on all the nodes on the | The robustness of these mechanisms is based on all the nodes on the | |||
link receiving the Router Advertisement messages in a timely manner. | link receiving the Router Advertisement messages in a timely manner. | |||
However, a host might be turned off or be unreachable for an extended | However, a host might be turned off or be unreachable for an extended | |||
period of time (i.e., a machine is powered down for months after a | period of time (i.e., a machine is powered down for months after a | |||
project terminates). It is possible to preserve robust renumbering | project terminates). It is possible to preserve robust renumbering | |||
in such cases but it does place some constraints on how long prefixes | in such cases, but it does place some constraints on how long | |||
must be advertised. | prefixes must be advertised. | |||
Consider the following example in which a prefix is initially | Consider the following example in which a prefix is initially | |||
advertised with a lifetime of 2 months, but on August 1st it is | advertised with a lifetime of 2 months, but on August 1st it is | |||
determined that the prefix needs to be deprecated and removed due to | determined that the prefix needs to be deprecated and removed due to | |||
renumbering by September 1st. This can be done by reducing the | renumbering by September 1st. This can be done by reducing the | |||
advertised lifetime to 1 week starting on August 1st and as the | advertised lifetime to 1 week starting on August 1st, and as the | |||
cutoff gets closer the lifetimes can be made shorter until by | cutoff gets closer, the lifetimes can be made shorter until by | |||
September 1st the prefix is advertised with a zero lifetime. The | September 1st the prefix is advertised with a lifetime of 0. The | |||
point is that, if one or more nodes were unplugged from the link | point is that, if one or more nodes were unplugged from the link | |||
prior to September 1st they might still think that the prefix is | prior to September 1st, they might still think that the prefix is | |||
valid since the last lifetime they received was 2 months. Thus if a | valid since the last lifetime they received was 2 months. Thus, if a | |||
node was unplugged on July 31st it thinks the prefix is valid until | node was unplugged on July 31st, it thinks the prefix is valid until | |||
September 30th. If that node is plugged back in prior to September | September 30th. If that node is plugged back in prior to September | |||
30th it may continue to use the old prefix. The only way to force a | 30th, it may continue to use the old prefix. The only way to force a | |||
node to stop using a prefix that was previously advertised with a | node to stop using a prefix that was previously advertised with a | |||
long Lifetime is to have that node receive an advertisement for that | long lifetime is to have that node receive an advertisement for that | |||
prefix that changes the lifetime downward. The solution in this | prefix that changes the lifetime downward. The solution in this | |||
example is simple: continue advertising the prefix with a lifetime of | example is simple: continue advertising the prefix with a lifetime of | |||
0 from September 1st until October 1st. | 0 from September 1st until October 1st. | |||
In general, in order to be robust against nodes that might be | In general, in order to be robust against nodes that might be | |||
unplugged from the link it is important to track the furthest into | unplugged from the link, it is important to track the furthest into | |||
the future a particular prefix can be viewed valid by any node on the | the future that a particular prefix can be viewed as valid by any | |||
link. The prefix must then be advertised with a 0 Lifetime until | node on the link. The prefix must then be advertised with a 0 | |||
that point in future. This "furthest into the future" time is simply | lifetime until that point in the future. This "furthest into the | |||
the maximum, over all Router Advertisements, of the time the | future" time is simply the maximum, over all Router Advertisements, | |||
advertisement was sent plus the prefix's Lifetime contained in the | of the time the advertisement was sent, plus the prefix's lifetime | |||
advertisement. | contained in the advertisement. | |||
The above has an important implication on using infinite lifetimes. | The above has an important implication on using infinite lifetimes. | |||
If a prefix is advertised with an infinite lifetime, and that prefix | If a prefix is advertised with an infinite lifetime, and that prefix | |||
later needs to be renumbered, it is undesirable to continue | later needs to be renumbered, it is undesirable to continue | |||
advertising that prefix with a zero lifetime forever. Thus either | advertising that prefix with a zero lifetime forever. Thus, either | |||
infinite lifetimes should be avoided or there must be a limit on how | infinite lifetimes should be avoided or there must be a limit on how | |||
long time a node can be unplugged from the link before it is plugged | long of a time a node can be unplugged from the link before it is | |||
back in again. However, it is unclear how the network administrator | plugged back in again. However, it is unclear how the network | |||
can enforce a limit on how long time hosts such as laptops can be | administrator can enforce a limit on how long time hosts such as | |||
unplugged from the link. | laptops can be unplugged from the link. | |||
Network administrators should give serious consideration to using | Network administrators should give serious consideration to using | |||
relatively short lifetimes (i.e., no more than a few weeks). While | relatively short lifetimes (i.e., no more than a few weeks). While | |||
it might appear that using long lifetimes would help insure | it might appear that using long lifetimes would help ensure | |||
robustness, in reality a host will be unable to communicate in the | robustness, in reality, a host will be unable to communicate in the | |||
absence of properly functioning routers. Such routers will be | absence of properly functioning routers. Such routers will be | |||
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 | 13. IANA Considerations | |||
This document does not require any new ICMPv6 types or codes to be | This document does not require any new ICMPv6 types or codes to be | |||
allocated. However, existing ICMPv6 types should be updated to point | allocated. However, existing ICMPv6 types have been updated to point | |||
to the document instead of RFC 2461. The procedure for the assignment | to this document instead of RFC 2461. The procedure for the | |||
of ICMPv6 types/codes is described in Section 6 of [ICMPv6]. | assignment of ICMPv6 types/codes is described in Section 6 of | |||
[ICMPv6]. | ||||
This document continues to use the following ICMPv6 message types | This document continues to use the following ICMPv6 message types | |||
introduced in RFC 2461 and already assigned by IANA: | introduced in RFC 2461 and already assigned by IANA: | |||
Message name ICMPv6 Type | Message name ICMPv6 Type | |||
Router Solicitation 133 | Router Solicitation 133 | |||
Router Advertisement 134 | Router Advertisement 134 | |||
Neighbor Solicitation 135 | Neighbor Solicitation 135 | |||
Neighbor Advertisement 136 | Neighbor Advertisement 136 | |||
skipping to change at page 77, line 4 | skipping to change at page 83, line 39 | |||
This document continues to use the following Neighbor Discovery | This document continues to use the following Neighbor Discovery | |||
option types introduced in RFC 2461 and already assigned by IANA: | option types introduced in RFC 2461 and already assigned by IANA: | |||
Option Name Type | Option Name Type | |||
Source Link-Layer Address 1 | Source Link-Layer Address 1 | |||
Target Link-Layer Address 2 | Target Link-Layer Address 2 | |||
Prefix Information 3 | Prefix Information 3 | |||
Redirected Header 4 | Redirected Header 4 | |||
MTU 5 | MTU 5 | |||
Neighbor Discovery option types are allocated using following | ||||
Neighbor Discovery option types are allocated using the following | ||||
procedure: | procedure: | |||
1. The IANA should allocate and permanently register new option types | 1. The IANA should allocate and permanently register new option types | |||
from IETF RFC publication. This is for all RFC types | from IETF RFC publication. This is for all RFC types including | |||
including standards track, informational, and experimental status | standards track, informational, and experimental status that | |||
that originate from the IETF and have been approved by the IESG | originate from the IETF and have been approved by the IESG for | |||
for publication. | publication. | |||
2. IETF working groups with working group consensus and area director | 2. IETF working groups with working group consensus and area director | |||
approval can request reclaimable Neighbor Discovery option type | approval can request reclaimable Neighbor Discovery option type | |||
assignments from the IANA. The IANA will tag the values as | assignments from the IANA. The IANA will tag the values as | |||
"reclaimable in future". | "reclaimable in future". | |||
The "reclaimable in the future" tag will be removed when an RFC is | The "reclaimable in the future" tag will be removed when an RFC is | |||
published documenting the protocol as defined in 1). This will | published documenting the protocol as defined in 1). This will make | |||
make the assignment permanent and update the reference on the IANA | the assignment permanent and update the reference on the IANA Web | |||
web pages. | pages. | |||
At the point where the option type values are 85% assigned, the | At the point where the option type values are 85% assigned, the IETF | |||
IETF will review the assignments tagged "reclaimable in the | will review the assignments tagged "reclaimable in the future" and | |||
future" and inform the IANA which ones should be reclaimed and | inform the IANA which ones should be reclaimed and reassigned. | |||
reassigned. | ||||
3. Requests for new option type value assignments from outside the | 3. Requests for new option type value assignments from outside the | |||
IETF are only made through the publication of an IETF document, | IETF are only made through the publication of an IETF document, per | |||
per 1) above. Note also that documents published as "RFC Editor | 1) above. Note also that documents published as "RFC Editor | |||
contributions" [RFC3667] are not considered to be IETF documents. | contributions" [RFC3667] are not considered to be IETF documents. | |||
REFERENCES | 14. References | |||
NORMATIVE | 14.1. Normative References | |||
[ADDR-ARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing | [ADDR-ARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing | |||
Architecture", RFC 4291, February 2006. | Architecture", RFC 4291, February 2006. | |||
[ICMPv6] Conta, A. and S. Deering, "Internet Control Message | [ICMPv6] Conta, A., Deering, S., and M. Gupta, Ed., "Internet | |||
Protocol (ICMPv6) for the Internet Protocol Version 6 | Control Message Protocol (ICMPv6) for the Internet | |||
(IPv6) Specification", RFC 4443, March 2006. | Protocol Version 6 (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 | 14.2. Informative References | |||
[ADDRCONF] Thomson, S. Narten, T, and T. Jinmei, "IPv6 Address | [ADDRCONF] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless | |||
Autoconfiguration", draft-ietf-ipv6-rfc2462bis-08, May | Address Autoconfiguration", RFC 4862, September 2007. | |||
2005. | ||||
[ADDR-SEL] Draves, R., "Default Address Selection for Internet | [ADDR-SEL] Draves, R., "Default Address Selection for Internet | |||
Protocol version 6 (IPv6)", RFC 3484, February 2003. | Protocol version 6 (IPv6)", RFC 3484, February 2003. | |||
[ARP] Plummer, D., "An Ethernet Address Resolution Protocol", | [ARP] Plummer, D., "Ethernet Address Resolution Protocol: Or | |||
STD 37, RFC 826, November 1982. | Converting Network Protocol Addresses to 48.bit Ethernet | |||
Address for Transmission on Ethernet Hardware", STD 37, | ||||
RFC 826, November 1982. | ||||
[ASSIGNED] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by | [ASSIGNED] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is | |||
an On-line Database", RFC 3232, January 2002. | Replaced by an On-line Database", RFC 3232, January | |||
2002. | ||||
[DHCPv6] Droms, R., Ed, "Dynamic Host Configuration Protocol for | [DHCPv6] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, | |||
IPv6 (DHCPv6)", RFC 3315, July 2003. | C., and M. Carney, "Dynamic Host Configuration Protocol | |||
for IPv6 (DHCPv6)", RFC 3315, July 2003. | ||||
[HR-CL] Braden, R., Editor, "Requirements for Internet Hosts -- | [HR-CL] Braden, R., Ed., "Requirements for Internet Hosts - | |||
Communication Layers", STD 3, RFC 1122, October 1989. | Communication Layers", STD 3, RFC 1122, October 1989. | |||
[ICMPIKE] Arkko, J., "Effects of ICMPv6 on IKE", | [ICMPIKE] Arkko, J., "Effects of ICMPv6 on IKE", Work in Progress, | |||
draft-arkko-icmpv6-ike-effects-02 (work in progress), | ||||
March 2003. | March 2003. | |||
[ICMPv4] Postel, J., "Internet Control Message Protocol", STD 5, | [ICMPv4] Postel, J., "Internet Control Message Protocol", STD 5, | |||
RFC 792, September 1981. | RFC 792, September 1981. | |||
[IPv6-3GPP] Wasserman, M., Ed, "Recommendations for IPv6 in Third | [IPv6-3GPP] Wasserman, M., Ed., "Recommendations for IPv6 in Third | |||
Generation Partnership Project (3GPP) standards", RFC | Generation Partnership Project (3GPP) Standards", RFC | |||
3314, September 2002. | 3314, September 2002. | |||
[IPv6-CELL] Arkko, J., Kuipers, G., Soliman, H., Loughney, J. and J. | [IPv6-CELL] Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and | |||
Wiljakka, " Internet Protocol version 6 (IPv6) for Some | J. Wiljakka, "Internet Protocol Version 6 (IPv6) for | |||
Second and Third Generation Cellular Hosts", RFC 3316, | Some Second and Third Generation Cellular Hosts", RFC | |||
April 2003. | 3316, April 2003. | |||
[IPv6-ETHER] Crawford, M., "Transmission of IPv6 Packets over | [IPv6-ETHER] Crawford, M., "Transmission of IPv6 Packets over | |||
Ethernet Networks", RFC 2464, December 1998. | Ethernet Networks", RFC 2464, December 1998. | |||
[IPv6-SA] Kent, S. and R. Atkinson, "Security Architecture for the | [IPv6-SA] Kent, S. and K. Seo, "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] Kent, S., "IP Authentication Header", RFC 4302, December | |||
2005. | 2005. | |||
[IPv6-ESP] S. Kent, "IP Encapsulating Security Payload (ESP)", RFC | [IPv6-ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC | |||
4303, December 2005. | 4303, December 2005. | |||
[IPv6-NBMA] Armitage, G., Schulter, P., Jork, M and G. Harter "IPv6 | [IPv6-NBMA] Armitage, G., Schulter, P., Jork, M., and G. Harter, | |||
over Non-Broadcast Multiple Access (NBMA) networks", RFC | "IPv6 over Non-Broadcast Multiple Access (NBMA) | |||
2491, January 1999. | 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] Johnson, D., Perkins, C., and J. Arkko, "Mobility | |||
in IPv6", RFC 3775, June 2004. | Support 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 (MLD) for IPv6", RFC 2710, October | |||
1999. | ||||
[MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery | [MLDv2] Vida, R., Ed., and L. Costa, Ed., "Multicast Listener | |||
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. | Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June | |||
2004. | ||||
[PSREQ] Nikander, P., Kempf, J. And E. Nordmark, "IPv6 Neighbor | [PSREQ] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 | |||
Discovery (ND) Trust and Threats", RFC 3756, May 2004. | Neighbor Discovery (ND) Trust Models and Threats", RFC | |||
rd [RAND] Eastlake, 3 , D., Schiller, J and S. Crocker, | 3756, May 2004. | |||
"Randomness Requirements for Security", RFC 4086, June | ||||
2005. | ||||
[RDISC] Deering, S., "ICMP Router Discovery Messages", RFC 1256, | [RAND] Eastlake, D., 3rd, Schiller, J., and S. Crocker, | |||
September 1991. | "Randomness Requirements for Security", BCP 106, RFC | |||
4086, June 2005. | ||||
[RDISC] Deering, S., Ed., "ICMP Router Discovery Messages", RFC | ||||
1256, 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", RFC 4191, November 2005. | |||
selection-07, (work in progress), January 2005. | ||||
[SH-MEDIA] Braden, R., Postel, J. and Y. Rekhter, "Internet | [SH-MEDIA] Braden, B., Postel, J., and Y. Rekhter, "Internet | |||
Architecture Extensions for Shared Media", RFC 1620, May | Architecture Extensions for Shared Media", RFC 1620, May | |||
1994. | 1994. | |||
[SEND] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. | [SEND] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, | |||
Nikander, "SEcure Neighbor Discovery (SEND)",RFC3971, | "SEcure Neighbor Discovery (SEND)", RFC 3971, March | |||
March 2005. | 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 | |||
Authors' Addresses | Appendix A: Multihomed Hosts | |||
Thomas Narten | ||||
IBM Corporation | ||||
P.O. Box 12195 | ||||
Research Triangle Park, NC 27709-2195 | ||||
USA | ||||
Phone: +1 919 254 7798 | ||||
EMail: narten@us.ibm.com | ||||
Erik Nordmark | ||||
Sun Microsystems, Inc. | ||||
901 San Antonio Road | ||||
Palo Alto, CA 94303 | ||||
USA | ||||
Phone: +1 650 786 5166 | ||||
Fax: +1 650 786 5896 | ||||
EMail: nordmark@sun.com | ||||
William Allen Simpson | ||||
Daydreamer | ||||
Computer Systems Consulting Services | ||||
1384 Fontaine | ||||
Madison Heights, Michigan 48071 | ||||
USA | ||||
EMail: Bill.Simpson@um.cc.umich.edu | ||||
bsimpson@MorningStar.com | ||||
Hesham Soliman | ||||
Elevate Technologies | ||||
Email: hesham@elevatemobile.com | ||||
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 | |||
related to this problem can be found in [RTSEL]. | related to this problem can be found in [RTSEL]. | |||
skipping to change at page 81, line 7 | skipping to change at page 87, line 35 | |||
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. Additional discussion on this topic can | only have one interface. Additional discussion on this topic | |||
be found in RFC1122 under section 3.3.4.2. | can be found in RFC 1122 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. | |||
No mechanism exists for the multihomed host to detect this | No mechanism exists for the multihomed host to detect this | |||
situation. | situation. | |||
If a multihomed host fails to receive Router Advertisements on one or | If a multihomed host fails to receive Router Advertisements on one or | |||
more of its interfaces, it will not know (in the absence of | more of its interfaces, it will not know (in the absence of | |||
configured information) which destinations are on-link on the | configured information) which destinations are on-link on the | |||
affected interface(s). This leads to the following problem: If Router | affected interface(s). This leads to the following problem: If | |||
Advertisements are received on some, but not all interfaces, a | Router Advertisements are received on some, but not all, interfaces, | |||
multihomed host could choose to only send packets out on the | a multihomed host could choose to only send packets out on the | |||
interfaces on which it has received Router Advertisements. A key | interfaces on which it has received Router Advertisements. A key | |||
assumption made here, however, is that routers on those other | assumption made here, however, is that routers on those other | |||
interfaces will be able to route packets to the ultimate destination, | interfaces will be able to route packets to the ultimate destination, | |||
even when those destinations reside on the subnet to which the sender | even when those destinations reside on the subnet to which the sender | |||
connects, but has no on-link prefix information. Should the | connects, but has no on-link prefix information. Should the | |||
assumption be FALSE, communication would fail. Even if the assumption | assumption be FALSE, communication would fail. Even if the | |||
holds, packets will traverse a sub-optimal path. | assumption holds, packets will traverse a suboptimal path. | |||
APPENDIX B: FUTURE EXTENSIONS | Appendix B: Future Extensions | |||
Possible extensions for future study are: | Possible extensions for future study are: | |||
o Using dynamic timers to be able to adapt to links with widely | o Using dynamic timers to be able to adapt to links with widely | |||
varying delay. Measuring round trip times, however, requires | varying delay. Measuring round-trip times, however, requires | |||
acknowledgments and sequence numbers in order to match received | acknowledgments and sequence numbers in order to match received | |||
Neighbor Advertisements with the actual Neighbor Solicitation that | Neighbor Advertisements with the actual Neighbor Solicitation that | |||
triggered the advertisement. Implementors wishing to experiment | triggered the advertisement. Implementors wishing to experiment | |||
with such a facility could do so in a backwards-compatible way by | with such a facility could do so in a backwards-compatible way by | |||
defining a new option carrying the necessary information. Nodes | defining a new option carrying the necessary information. Nodes | |||
not understanding the option would simply ignore it. | not understanding the option would simply ignore it. | |||
o Adding capabilities to facilitate the operation over links that | o Adding capabilities to facilitate the operation over links that | |||
currently require hosts to register with an address resolution | currently require hosts to register with an address resolution | |||
server. This could for instance enable routers to ask hosts to | server. This could, for instance, enable routers to ask hosts to | |||
send them periodic unsolicited advertisements. Once again this | send them periodic unsolicited advertisements. Once again, this | |||
can be added using a new option sent in the Router Advertisements. | can be added using a new option sent in the Router Advertisements. | |||
o Adding additional procedures for links where asymmetric and non- | o Adding additional procedures for links where asymmetric and non- | |||
transitive reachability is part of normal operations. Such | transitive reachability is part of normal operations. Such | |||
procedures might allow hosts and routers to find usable paths on, | procedures might allow hosts and routers to find usable paths on, | |||
e.g., radio links. | e.g., radio links. | |||
APPENDIX C: STATE MACHINE FOR THE REACHABILITY STATE | Appendix C: State Machine for the Reachability State | |||
This appendix contains a summary of the rules specified in Sections | This appendix contains a summary of the rules specified in Sections | |||
7.2 and 7.3. This document does not mandate that implementations | 7.2 and 7.3. This document does not mandate that implementations | |||
adhere to this model as long as their external behavior is consistent | adhere to this model as long as their external behavior is consistent | |||
with that described in this document. | with that described in this document. | |||
When performing address resolution and Neighbor Unreachability | When performing address resolution and Neighbor Unreachability | |||
Detection the following state transitions apply using the conceptual | Detection the following state transitions apply using the conceptual | |||
model: | model: | |||
skipping to change at page 84, line 28 | skipping to change at page 91, line 30 | |||
Different link-layer address | Different link-layer address | |||
address than cached. | address than cached. | |||
INCOMPLETE NS, RS No link-layer - unchanged | INCOMPLETE NS, RS No link-layer - unchanged | |||
address | address | |||
!INCOMPLETE NS, RS, RA, Redirect - unchanged | !INCOMPLETE NS, RS, RA, Redirect - unchanged | |||
Same link-layer | Same link-layer | |||
address as cached. | address as cached. | |||
APPENDIX D: SUMMARY OF ISROUTER RULES | Appendix D: Summary of IsRouter Rules | |||
This appendix presents a summary of the rules for maintaining the | This appendix presents a summary of the rules for maintaining the | |||
IsRouter flag as specified in this document. | IsRouter flag as specified in this document. | |||
The background for these rules is that the ND messages contain, | The background for these rules is that the ND messages contain, | |||
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 Advertisement is implicitly assumed to be a | - The sender of a Router Advertisement is implicitly assumed to be a | |||
skipping to change at page 85, line 5 | skipping to change at page 92, line 13 | |||
flag", the R-bit. | flag", the R-bit. | |||
- The target of the redirect, when the target differs from the | - The target of the redirect, when the target differs from the | |||
destination address in the packet being redirected, is implicitly | destination address in the packet being redirected, is implicitly | |||
assumed to be a router. This is a natural assumption since that | assumed to be a router. This is a natural assumption since that | |||
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 | |||
it could be either a host or a router. | but 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 | |||
or Router Advertisement message will set the correct IsRouter value. | Advertisement or Router Advertisement message will set the correct | |||
IsRouter value. | ||||
APPENDIX E: IMPLEMENTATION ISSUES | Appendix E: Implementation Issues | |||
Appendix E.1: Reachability confirmations | E.1. Reachability Confirmations | |||
Neighbor Unreachability Detection requires explicit confirmation that | Neighbor Unreachability Detection requires explicit confirmation that | |||
a forward-path is functioning properly. To avoid the need for | a forward-path is functioning properly. To avoid the need for | |||
Neighbor Solicitation probe messages, upper layer protocols should | Neighbor Solicitation probe messages, upper-layer protocols should | |||
provide such an indication when the cost of doing so is small. | provide such an indication when the cost of doing so is small. | |||
Reliable connection-oriented protocols such as TCP are generally | Reliable connection-oriented protocols such as TCP are generally | |||
aware when the forward-path is working. When TCP sends (or receives) | aware when the forward-path is working. When TCP sends (or receives) | |||
data, for instance, it updates its window sequence numbers, sets and | data, for instance, it updates its window sequence numbers, sets and | |||
cancels retransmit timers, etc. Specific scenarios that usually | cancels retransmit timers, etc. Specific scenarios that usually | |||
indicate a properly functioning forward-path include: | indicate a properly functioning forward-path include: | |||
- Receipt of an acknowledgement that covers a sequence number (e.g., | - Receipt of an acknowledgment that covers a sequence number (e.g., | |||
data) not previously acknowledged indicates that the forward path | data) not previously acknowledged indicates that the forward path | |||
was working at the time the data was sent. | was working at the time the data was sent. | |||
- Completion of the initial three-way handshake is a special case of | - Completion of the initial three-way handshake is a special case of | |||
the previous rule; although no data is sent during the handshake, | the previous rule; although no data is sent during the handshake, | |||
the SYN flags are counted as data from the sequence number | the SYN flags are counted as data from the sequence number | |||
perspective. This applies to both the SYN+ACK for the active open | perspective. This applies to both the SYN+ACK for the active open | |||
the ACK of that packet on the passively opening peer. | and the ACK of that packet on the passively opening peer. | |||
- Receipt of new data (i.e., data not previously received) indicates | - Receipt of new data (i.e., data not previously received) indicates | |||
that the forward-path was working at the time an acknowledgement | that the forward-path was working at the time an acknowledgment | |||
was sent that advanced the peer's send window that allowed the new | was sent that advanced the peer's send window that allowed the new | |||
data to be sent. | data to be sent. | |||
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 | |||
implementations 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 (Remote Procedure Call (RPC), DNS), it is | |||
the client send reachability confirmations when the response packet | relatively simple to make the client send reachability confirmations | |||
is received. It is more difficult and in some cases impossible for | when the response packet is received. It is more difficult and in | |||
the server to generate such confirmations since there is no flow | some cases impossible for the server to generate such confirmations | |||
control, i.e., the server can not determine whether a received | since there is no flow control, i.e., the server cannot determine | |||
request indicates that a previous response reached the client. | whether a received request indicates that a previous response reached | |||
the client. | ||||
Note that an implementation can not use negative upper-layer advice | Note that an implementation cannot use negative upper-layer advice as | |||
as a replacement for the Neighbor Unreachability Detection algorithm. | a replacement for the Neighbor Unreachability Detection algorithm. | |||
Negative advice (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 acknowledgment 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 | |||
or as part of validating the received message. | 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. | |||
o Removed the on-link assumption in section 5.2 based on | o Removed the on-link assumption in Section 5.2 based on RFC 4942, | |||
draft-ietf-v6ops-onlinkassumption | "IPv6 Neighbor Discovery On-Link Assumption Considered Harmful". | |||
o Clarified the definition of the Router Lifetime field in section | o Clarified the definition of the Router Lifetime field in Section | |||
4.2. | 4.2. | |||
o Updated the text in section 4.6.2 and 6.2.1 to indicate that the | o Updated the text in Sections 4.6.2 and 6.2.1 to indicate that the | |||
preferred lifetime must not be larger than valid lifetime. | preferred lifetime must not be larger than valid lifetime. | |||
o Removed the reference to stateful configuration and added | o Removed the reference to stateful configuration and added reference | |||
reference for DHCPv6 instead. | for DHCPv6 instead. | |||
o Added the IsRouter flag definition to section 6.2.1 to allow for | o Added the IsRouter flag definition to Section 6.2.1 to allow for | |||
mixed host/router behavior. | mixed host/router behavior. | |||
o Allowed mobile nodes to be exempt from adding random delays before | o Allowed mobile nodes to be exempt from adding random delays before | |||
sending an RS during a handover. | sending an RS during a handover. | |||
o Updated the definition of the prefix length in the prefix option | o Updated the definition of the prefix length in the prefix option. | |||
o Updated the applicability to NBMA links in the introduction and | o Updated the applicability to NBMA links in the introduction and | |||
added references to 3GPP RFCs. | added references to 3GPP RFCs. | |||
o Clarified support for Load balancing is limited to routers. | o Clarified that support for load balancing is limited to routers. | |||
o Clarified router behaviour when receiving a Router Solicitation | o Clarified router behavior when receiving a Router Solicitation | |||
without SLLAO. | without Source Link-Layer Address Option (SLLAO). | |||
o Clarified that inconsistency checks for CurHopLimit are done for | o Clarified that inconsistency checks for CurHopLimit are done for | |||
non-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 | |||
upon receiving a message without SLLAO. | receiving a message without SLLAO. | |||
O Added New IANA section. | o Added new IANA section. | |||
o Miscellaneous editorials. | o Miscellaneous editorials. | |||
Intellectual Property Statement | Acknowledgments | |||
The authors of RFC 2461 would like to acknowledge the contributions | ||||
of the IPV6 working group and, in particular, (in alphabetical order) | ||||
Ran Atkinson, Jim Bound, Scott Bradner, Alex Conta, Stephen Deering, | ||||
Richard Draves, Francis Dupont, Robert Elz, Robert Gilligan, Robert | ||||
Hinden, Tatuya Jinmei, Allison Mankin, Dan McDonald, Charles Perkins, | ||||
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. | ||||
Authors' Addresses | ||||
Thomas Narten | ||||
IBM Corporation | ||||
P.O. Box 12195 | ||||
Research Triangle Park, NC 27709-2195 | ||||
USA | ||||
Phone: +1 919 254 7798 | ||||
EMail: narten@us.ibm.com | ||||
Erik Nordmark | ||||
Sun Microsystems, Inc. | ||||
17 Network Circle | ||||
Menlo Park, CA 94025 | ||||
USA | ||||
Phone: +1 650 786 2921 | ||||
Fax: +1 650 786 5896 | ||||
EMail: erik.nordmark@sun.com | ||||
William Allen Simpson | ||||
Daydreamer | ||||
Computer Systems Consulting Services | ||||
1384 Fontaine | ||||
Madison Heights, Michigan 48071 | ||||
USA | ||||
EMail: william.allen.simpson@gmail.com | ||||
Hesham Soliman | ||||
Elevate Technologies | ||||
EMail: hesham@elevatemobile.com | ||||
Full Copyright Statement | ||||
Copyright (C) The IETF Trust (2007). | ||||
This document is subject to the rights, licenses and restrictions | ||||
contained in BCP 78, and except as set forth therein, the authors | ||||
retain all their rights. | ||||
This document and the information contained herein are provided on an | ||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | ||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND | ||||
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS | ||||
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF | ||||
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | ||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ||||
Intellectual Property | ||||
The IETF takes no position regarding the validity or scope of any | The IETF takes no position regarding the validity or scope of any | |||
Intellectual Property Rights or other rights that might be claimed to | Intellectual Property Rights or other rights that might be claimed to | |||
pertain to the implementation or use of the technology described in | pertain to the implementation or use of the technology described in | |||
this document or the extent to which any license under such rights | this document or the extent to which any license under such rights | |||
might or might not be available; nor does it represent that it has | might or might not be available; nor does it represent that it has | |||
made any independent effort to identify any such rights. Information | made any independent effort to identify any such rights. Information | |||
on the IETF's procedures with respect to rights in IETF Documents can | on the procedures with respect to rights in RFC documents can be | |||
be found in RFC 3667 (BCP 78) and RFC 3668 (BCP 79). | found in BCP 78 and BCP 79. | |||
Copies of IPR disclosures made to the IETF Secretariat and any | Copies of IPR disclosures made to the IETF Secretariat and any | |||
assurances of licenses to be made available, or the result of an | assurances of licenses to be made available, or the result of an | |||
attempt made to obtain a general license or permission for the use of | attempt made to obtain a general license or permission for the use of | |||
such proprietary rights by implementers or users of this | such proprietary rights by implementers or users of this | |||
specification can be obtained from the IETF on-line IPR repository at | specification can be obtained from the IETF on-line IPR repository at | |||
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 | |||
ipr@ietf.org. | ietf-ipr@ietf.org. | |||
Full Copyright Statement | ||||
Copyright (C) The IETF Trust (2007). This document is subject | ||||
to the rights, licenses and restrictions contained in BCP 78, and | ||||
except as set forth therein, the authors retain all their rights. | ||||
Disclaimer of Validity | ||||
This document and the information contained herein are provided on an | ||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | ||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND | ||||
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS | ||||
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF | ||||
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | ||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ||||
This Internet-Draft expires September, 2007. | ||||
End of changes. 305 change blocks. | ||||
751 lines changed or deleted | 771 lines changed or added | |||
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |