draft-ietf-ipv6-2461bis-02.txt | draft-ietf-ipv6-2461bis-03.txt | |||
---|---|---|---|---|
INTERNET-DRAFT T. Narten, | INTERNET-DRAFT T. Narten, | |||
Expires: August 2005 IBM | Expires: November 2005 IBM | |||
E. Nordmark, | E. Nordmark, | |||
Sun Microsystems | Sun Microsystems | |||
W. Simpson, | W. Simpson, | |||
Daydreamer | Daydreamer | |||
H. Soliman, | H. Soliman, | |||
Flarion | Flarion | |||
February, 2005 | May, 2005 | |||
Neighbor Discovery for IP version 6 (IPv6) | Neighbor Discovery for IP version 6 (IPv6) | |||
<draft-ietf-ipv6-2461bis-02.txt> | <draft-ietf-ipv6-2461bis-03.txt> | |||
Status of this memo | Status of this memo | |||
By submitting this Internet-Draft, we certify that any applicable | By submitting this Internet-Draft, each author represents that any | |||
patent or other IPR claims of which we are aware have been disclosed, | applicable patent or other IPR claims of which he or she is aware | |||
and any of which we become aware will be disclosed, in accordance | have been or will be disclosed, and any of which he or she becomes | |||
with RFC 3668 (BCP 79). | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
By submitting this Internet-Draft, we accept the provisions of | By submitting this Internet-Draft, we accept the provisions of | |||
Section 4 of RFC 3667 (BCP 78). | Section 4 of RFC 3667 (BCP 78). | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that other | Task Force (IETF), its areas, and its working groups. Note that other | |||
groups may also distribute working documents as Internet-Drafts. | groups may also distribute working documents as Internet-Drafts. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
skipping to change at page 2, line 14 | skipping to change at page 2, line 14 | |||
about the paths to active neighbors. | about the paths to active neighbors. | |||
Table of Contents | Table of Contents | |||
1. INTRODUCTION....................................................4 | 1. INTRODUCTION....................................................4 | |||
2. TERMINOLOGY.....................................................4 | 2. TERMINOLOGY.....................................................4 | |||
2.1. General...................................................4 | 2.1. General...................................................4 | |||
2.2. Link Types................................................8 | 2.2. Link Types................................................8 | |||
2.3. Addresses.................................................9 | 2.3. Addresses.................................................9 | |||
2.4. Requirements..............................................9 | 2.4. Requirements.............................................10 | |||
3. PROTOCOL OVERVIEW..............................................10 | 3. PROTOCOL OVERVIEW..............................................10 | |||
3.1. Comparison with IPv4.....................................13 | 3.1. Comparison with IPv4.....................................13 | |||
3.2. Supported Link Types.....................................15 | 3.2. Supported Link Types.....................................15 | |||
3.3. Securing Neighbor Discovery messages......................17 | 3.3. Securing Neighbor Discovery messages......................17 | |||
4. MESSAGE FORMATS................................................17 | 4. MESSAGE FORMATS................................................17 | |||
4.1. Router Solicitation Message Format.......................17 | 4.1. Router Solicitation Message Format.......................17 | |||
4.2. Router Advertisement Message Format......................18 | 4.2. Router Advertisement Message Format......................18 | |||
4.3. Neighbor Solicitation Message Format.....................20 | 4.3. Neighbor Solicitation Message Format.....................20 | |||
4.4. Neighbor Advertisement Message Format....................22 | 4.4. Neighbor Advertisement Message Format....................22 | |||
4.5. Redirect Message Format..................................24 | 4.5. Redirect Message Format..................................24 | |||
4.6. Option Formats...........................................26 | 4.6. Option Formats...........................................26 | |||
4.6.2. Prefix Information.................................27 | 4.6.2. Prefix Information.................................27 | |||
4.6.3. Redirected Header..................................29 | 4.6.3. Redirected Header..................................29 | |||
4.6.4. MTU................................................30 | 4.6.4. MTU................................................30 | |||
5. CONCEPTUAL MODEL OF A HOST.....................................31 | 5. CONCEPTUAL MODEL OF A HOST.....................................31 | |||
5.1. Conceptual Data Structures...............................31 | 5.1. Conceptual Data Structures...............................31 | |||
5.2. Conceptual Sending Algorithm.............................33 | 5.2. Conceptual Sending Algorithm.............................33 | |||
5.3. Garbage Collection and Timeout Requirements..............34 | 5.3. Garbage Collection and Timeout Requirements..............35 | |||
6. ROUTER AND PREFIX DISCOVERY....................................35 | 6. ROUTER AND PREFIX DISCOVERY....................................35 | |||
6.1. Message Validation.......................................36 | 6.1. Message Validation.......................................36 | |||
6.1.1. Validation of Router Solicitation Messages.........36 | 6.1.1. Validation of Router Solicitation Messages.........36 | |||
6.1.2. Validation of Router Advertisement Messages........36 | 6.1.2. Validation of Router Advertisement Messages........36 | |||
6.2. Router Specification.....................................37 | 6.2. Router Specification.....................................37 | |||
6.2.1. Router Configuration Variables....................37 | 6.2.1. Router Configuration Variables....................37 | |||
6.2.2. Becoming An Advertising Interface.................41 | 6.2.2. Becoming An Advertising Interface.................41 | |||
6.2.3. Router Advertisement Message Content..............41 | 6.2.3. Router Advertisement Message Content..............42 | |||
6.2.4. Sending Unsolicited Router Advertisements.........43 | 6.2.4. Sending Unsolicited Router Advertisements.........43 | |||
6.2.5. Ceasing To Be An Advertising Interface............43 | 6.2.5. Ceasing To Be An Advertising Interface............44 | |||
6.2.6. Processing Router Solicitations...................44 | 6.2.6. Processing Router Solicitations...................44 | |||
6.2.7. Router Advertisement Consistency..................45 | 6.2.7. Router Advertisement Consistency..................45 | |||
6.2.8. Link-local Address Change.........................46 | 6.2.8. Link-local Address Change.........................46 | |||
6.3. Host Specification.......................................47 | 6.3. Host Specification.......................................47 | |||
6.3.1. Host Configuration Variables......................47 | 6.3.1. Host Configuration Variables......................47 | |||
6.3.2. Host Variables....................................47 | 6.3.2. Host Variables....................................47 | |||
6.3.3. Interface Initialization..........................48 | 6.3.3. Interface Initialization..........................48 | |||
6.3.4. Processing Received Router Advertisements.........48 | 6.3.4. Processing Received Router Advertisements.........48 | |||
6.3.5. Timing out Prefixes and Default Routers...........51 | 6.3.5. Timing out Prefixes and Default Routers...........51 | |||
6.3.6. Default Router Selection..........................51 | 6.3.6. Default Router Selection..........................51 | |||
6.3.7. Sending Router Solicitations......................52 | 6.3.7. Sending Router Solicitations......................52 | |||
7. ADDRESS RESOLUTION AND NEIGHBOR UNREACHABILITY DETECTION.......53 | 7. ADDRESS RESOLUTION AND NEIGHBOR UNREACHABILITY DETECTION.......54 | |||
7.1. Message Validation.......................................54 | 7.1. Message Validation.......................................54 | |||
7.1.1. Validation of Neighbor Solicitations..............54 | 7.1.1. Validation of Neighbor Solicitations..............54 | |||
7.1.2. Validation of Neighbor Advertisements.............54 | 7.1.2. Validation of Neighbor Advertisements.............55 | |||
7.2. Address Resolution.......................................55 | 7.2. Address Resolution.......................................55 | |||
7.2.1. Interface Initialization..........................55 | 7.2.1. Interface Initialization..........................56 | |||
7.2.2. Sending Neighbor Solicitations....................56 | 7.2.2. Sending Neighbor Solicitations....................56 | |||
7.2.3. Receipt of Neighbor Solicitations.................57 | 7.2.3. Receipt of Neighbor Solicitations.................57 | |||
7.2.4. Sending Solicited Neighbor Advertisements.........58 | 7.2.4. Sending Solicited Neighbor Advertisements.........58 | |||
7.2.5. Receipt of Neighbor Advertisements................58 | 7.2.5. Receipt of Neighbor Advertisements................59 | |||
7.2.6. Sending Unsolicited Neighbor Advertisements.......60 | 7.2.6. Sending Unsolicited Neighbor Advertisements.......61 | |||
7.2.7. Anycast Neighbor Advertisements...................61 | 7.2.7. Anycast Neighbor Advertisements...................62 | |||
7.2.8. Proxy Neighbor Advertisements.....................62 | 7.2.8. Proxy Neighbor Advertisements.....................62 | |||
7.3. Neighbor Unreachability Detection........................62 | 7.3. Neighbor Unreachability Detection........................63 | |||
7.3.1. Reachability Confirmation.........................63 | 7.3.1. Reachability Confirmation.........................63 | |||
7.3.2. Neighbor Cache Entry States.......................64 | 7.3.2. Neighbor Cache Entry States.......................64 | |||
7.3.3. Node Behavior.....................................65 | 7.3.3. Node Behavior.....................................65 | |||
8. REDIRECT FUNCTION..............................................67 | 8. REDIRECT FUNCTION..............................................67 | |||
8.1. Validation of Redirect Messages..........................67 | 8.1. Validation of Redirect Messages..........................67 | |||
8.2. Router Specification.....................................68 | 8.2. Router Specification.....................................68 | |||
8.3. Host Specification.......................................69 | 8.3. Host Specification.......................................69 | |||
9. EXTENSIBILITY - OPTION PROCESSING..............................70 | 9. EXTENSIBILITY - OPTION PROCESSING..............................70 | |||
10. PROTOCOL CONSTANTS............................................71 | 10. PROTOCOL CONSTANTS............................................71 | |||
11. SECURITY CONSIDERATIONS.......................................72 | 11. SECURITY CONSIDERATIONS.......................................72 | |||
11.1 Threat analysis...........................................72 | 11.1 Threat analysis...........................................73 | |||
11.2 Securing Neighbor Discovery messages......................74 | 11.2 Securing Neighbor Discovery messages......................74 | |||
12. RENUMBERING CONSIDERATIONS....................................74 | 12. RENUMBERING CONSIDERATIONS....................................75 | |||
REFERENCES.........................................................76 | REFERENCES.........................................................76 | |||
Authors' Addresses.................................................78 | Authors' Addresses.................................................78 | |||
APPENDIX A: MULTIHOMED HOSTS.......................................78 | APPENDIX A: MULTIHOMED HOSTS.......................................79 | |||
APPENDIX B: FUTURE EXTENSIONS......................................80 | APPENDIX B: FUTURE EXTENSIONS......................................80 | |||
APPENDIX C: STATE MACHINE FOR THE REACHABILITY STATE...............80 | APPENDIX C: STATE MACHINE FOR THE REACHABILITY STATE...............81 | |||
APPENDIX D: SUMMARY OF ISROUTER RULES..............................82 | APPENDIX D: SUMMARY OF ISROUTER RULES..............................83 | |||
APPENDIX E: IMPLEMENTATION ISSUES..................................83 | APPENDIX E: IMPLEMENTATION ISSUES..................................84 | |||
Appendix E.1: Reachability confirmations...........................83 | Appendix E.1: Reachability confirmations...........................84 | |||
APPENDIX F: CHANGES FROM RFC 2461..................................85 | APPENDIX F: CHANGES FROM RFC 2461..................................85 | |||
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 | |||
skipping to change at page 4, line 37 | skipping to change at page 4, line 37 | |||
etc., are expected to be provided as specified in this document. The | etc., are expected to be provided as specified in this document. The | |||
details of how one uses ND on NBMA links are addressed in [IPv6- | details of how one uses ND on NBMA links are addressed in [IPv6- | |||
NBMA]. In addition, [IPv6-3GPP] and [IPv6-CELLULAR] discuss the use | NBMA]. In addition, [IPv6-3GPP] and [IPv6-CELLULAR] discuss the use | |||
of this protocol over some cellular links, which are examples of NBMA | of this protocol over some cellular links, which are examples of NBMA | |||
links. | links. | |||
The authors would like to acknowledge the contributions of the IPv6 | The authors would like to acknowledge the contributions of the IPv6 | |||
working group and, in particular, (in alphabetical order) Ran | working group and, in particular, (in alphabetical order) Ran | |||
Atkinson, Jim Bound, Scott Bradner, Alex Conta, Elwyn Davies, Stephen | Atkinson, Jim Bound, Scott Bradner, Alex Conta, Elwyn Davies, Stephen | |||
Deering Richard Draves, Francis Dupont, Robert Elz, Robert Gilligan, | Deering Richard Draves, Francis Dupont, Robert Elz, Robert Gilligan, | |||
Robert Hinden, Allison Mankin, Dan McDonald, Charles Perkins, Matt | Robert Hinden, Tatuya Jinmei, Allison Mankin, Dan McDonald, Charles | |||
Thomas, and Susan Thomson. | Perkins, Matt Thomas, and Susan Thomson. | |||
2. TERMINOLOGY | 2. TERMINOLOGY | |||
2.1. General | 2.1. General | |||
IP - Internet Protocol Version 6. The terms IPv4 and | IP - Internet Protocol Version 6. The terms IPv4 and | |||
IPv6 are used only in contexts where necessary to avoid | IPv6 are used only in contexts where necessary to avoid | |||
ambiguity. | ambiguity. | |||
ICMP - Internet Message Control Protocol for the Internet | ICMP - Internet Message Control Protocol for the Internet | |||
skipping to change at page 8, line 25 | skipping to change at page 8, line 25 | |||
point-to-point - a link that connects exactly two interfaces. A | point-to-point - a link that connects exactly two interfaces. A | |||
point-to-point link is assumed to have multicast | point-to-point link is assumed to have multicast | |||
capability and have a link-local address. | capability and have a link-local address. | |||
non-broadcast multi-access (NBMA) | non-broadcast multi-access (NBMA) | |||
- a link to which more than two interfaces can attach, | - a link to which more than two interfaces can attach, | |||
but that does not support a native form of multicast | but that does not support a native form of multicast | |||
or broadcast (e.g., X.25, ATM, frame relay, etc.). | or broadcast (e.g., X.25, ATM, frame relay, etc.). | |||
Note that all link types (including NBMA) are | Note that all link types (including NBMA) are | |||
expected to provide multicast service for IP (e.g., | expected to provide multicast service for | |||
using multicast servers), but it is an issue for | applications that need it(e.g., using multicast | |||
further study whether ND should use such facilities | servers). However, it is an issue for further study | |||
whether ND should use such facilities | ||||
or an alternate mechanism that provides the | or an alternate mechanism that provides the | |||
equivalent ND services. | equivalent multicast capability for ND. | |||
shared media - a link that allows direct communication among a | shared media - a link that allows direct communication among a | |||
number of nodes, but attached nodes are configured | number of nodes, but attached nodes are configured | |||
in such a way that they do not have complete prefix | in such a way that they do not have complete prefix | |||
information for all on-link destinations. That is, | information for all on-link destinations. That is, | |||
at the IP level, nodes on the same link may not know | at the IP level, nodes on the same link may not know | |||
that they are neighbors; by default, they | that they are neighbors; by default, they | |||
communicate through a router. Examples are large | communicate through a router. Examples are large | |||
(switched) public data networks such as SMDS and B- | (switched) public data networks such as SMDS and B- | |||
ISDN. Also known as "large clouds". See [SH- | ISDN. Also known as "large clouds". See [SH- | |||
skipping to change at page 9, line 24 | skipping to change at page 9, line 25 | |||
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 which differ only in the | |||
high-order bits, e.g., due to multiple high-order | least significant bits, e.g., due to multiple | |||
prefixes associated with different providers, will map | high-order prefixes associated with different | |||
to the same solicited-node address thereby reducing the | providers, will map to the same solicited-node address | |||
number of multicast addresses a node must join. | thereby reducing the number of multicast addresses a | |||
node must join. | ||||
link-local address | link-local address | |||
- a unicast address having link-only scope that can be | - a unicast address having link-only scope that can be | |||
used to reach neighbors. All interfaces on routers | used to reach neighbors. All interfaces on routers | |||
MUST have a link-local address. Also, [ADDRCONF] | MUST have a link-local address. Also, [ADDRCONF] | |||
requires that interfaces on hosts have a link-local | requires that interfaces on hosts have a link-local | |||
address. | address. | |||
unspecified address | unspecified address | |||
- a reserved address value that indicates the lack of an | - a reserved address value that indicates the lack of an | |||
address (e.g., the address is unknown). It is never | address (e.g., the address is unknown). It is never | |||
used as a destination address, but may be used as a | used as a destination address, but may be used as a | |||
source address if the sender does not (yet) know its | source address if the sender does not (yet) know its | |||
own address (e.g., while verifying an address is unused | own address (e.g., while verifying an address is unused | |||
during address autoconfiguration [ADDRCONF]). The | during address autoconfiguration [ADDRCONF]). The | |||
unspecified address has a value of 0:0:0:0:0:0:0:0. | unspecified address has a value of 0:0:0:0:0:0:0:0. | |||
Note that this specification does not strictly comply with the | Note that this specification does not strictly comply with the | |||
consistency requirements for the scopes of source and destination | consistency requirements in [ADDR-SEL] for the scopes of source and | |||
addresses. It is possible in some cases for hosts to use a source | destination addresses. It is possible in some cases for hosts to use | |||
address of a larger scope than the destination address in the IPv6 | a source address of a larger scope than the destination address in | |||
header. | the IPv6 header. | |||
2.4. Requirements | 2.4. Requirements | |||
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, | The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, | |||
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this | SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this | |||
document, are to be interpreted as described in [KEYWORDS]. | document, are to be interpreted as described in [KEYWORDS]. | |||
This document also makes use of internal conceptual variables to | This document also makes use of internal conceptual variables to | |||
describe protocol behavior and external variables that an | describe protocol behavior and external variables that an | |||
implementation must allow system administrators to change. The | implementation must allow system administrators to change. The | |||
skipping to change at page 19, line 18 | skipping to change at page 19, line 22 | |||
Cur Hop Limit 8-bit unsigned integer. The default value that | Cur Hop Limit 8-bit unsigned integer. The default value that | |||
should be placed in the Hop Count field of the IP | should be placed in the Hop Count field of the IP | |||
header for outgoing IP packets. A value of zero | header for outgoing IP packets. A value of zero | |||
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 Dynamic Host Configuration | set, it indicates that Dynamic Host Configuration | |||
Protocol [DHCPv6] is available for address | Protocol [DHCPv6] is available for address | |||
configuration in addition to any addresses | configuration in addition to any addresses | |||
autoconfigured using stateless address | autoconfigured using stateless address | |||
autoconfiguration. The use of this flag is | autoconfiguration. | |||
further described in [ADDRCONF]. | ||||
O 1-bit "Other configuration" flag. When | O 1-bit "Other configuration" flag. When | |||
set, it indicates that [DHCPv6lite] is available | set, it indicates that [DHCPv6lite] is available | |||
for autoconfiguration of other (non-address) | for autoconfiguration of other (non-address) | |||
information. Examples of such information are DNS- | information. Examples of such information are DNS- | |||
related information or information on other servers | related information or information on other servers | |||
within the network. | within the network. | |||
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 | |||
skipping to change at page 24, line 14 | skipping to change at page 24, line 17 | |||
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 have be able | layer address; otherwise it would not be able | |||
to send the unicast solicitation in the first | to send the unicast solicitation in the first | |||
place. However, including the link-layer address in | place. However, including the link-layer address in | |||
this case adds little overhead and eliminates a | this 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. | |||
skipping to change at page 28, line 18 | skipping to change at page 28, line 24 | |||
Fields: | Fields: | |||
Type 3 | Type 3 | |||
Length 4 | Length 4 | |||
Prefix Length 8-bit unsigned integer. The number of leading bits | Prefix Length 8-bit unsigned integer. The number of leading bits | |||
in the Prefix that are valid. The value ranges | in the Prefix that are valid. The value ranges | |||
from 0 to 128. The prefix length field provides | from 0 to 128. The prefix length field provides | |||
necessary information for on-link determination | necessary information for on-link determination | |||
(when combined with other flags in the prefix | (when combined with the L flag in the prefix | |||
option). It also assists with address | option). It also assists with address | |||
autoconfiguration as specified in [ADDRCONF], for | autoconfiguration as specified in [ADDRCONF], for | |||
which there may be more restrictions on the prefix | which there may be more restrictions on the prefix | |||
length. | length. | |||
L 1-bit on-link flag. When set, indicates that this | L 1-bit on-link flag. When set, indicates that this | |||
prefix can be used for on-link determination. When | prefix can be used for on-link determination. When | |||
not set the advertisement makes no statement about | not set the advertisement makes no statement about | |||
on-link or off-link properties of the prefix. For | on-link or off-link properties of the prefix. For | |||
instance, the prefix might be used for address | instance, the prefix might be used for address | |||
configuration with some of the addresses belonging | configuration with some of the addresses belonging | |||
to the prefix being on-link and others being off- | to the prefix being on-link and others being off- | |||
link. | link. | |||
A 1-bit autonomous address-configuration flag. When | A 1-bit autonomous address-configuration flag. When | |||
set indicates that this prefix can be used for | set indicates that this prefix can be used for | |||
autonomous address configuration as specified in | stateless address configuration as specified in | |||
[ADDRCONF]. | [ADDRCONF]. | |||
Reserved1 6-bit unused field. It MUST be initialized to zero | Reserved1 6-bit unused field. It MUST be initialized to zero | |||
by the sender and MUST be ignored by the receiver. | by the sender and MUST be ignored by the receiver. | |||
Valid Lifetime | Valid Lifetime | |||
32-bit unsigned integer. The length of time in | 32-bit unsigned integer. The length of time in | |||
seconds (relative to the time the packet is sent) | seconds (relative to the time the packet is sent) | |||
that the prefix is valid for the purpose of on-link | that the prefix is valid for the purpose of on-link | |||
determination. A value of all one bits | determination. A value of all one bits | |||
skipping to change at page 42, line 12 | skipping to change at page 42, line 18 | |||
A router sends periodic as well as solicited Router Advertisements | A router sends periodic as well as solicited Router Advertisements | |||
out its advertising interfaces. Outgoing Router Advertisements are | out its advertising interfaces. Outgoing Router Advertisements are | |||
filled with the following values consistent with the message format | filled with the following values consistent with the message format | |||
given in Section 4.2: | given in Section 4.2: | |||
- In the Router Lifetime field: the interface's configured | - In the Router Lifetime field: the interface's configured | |||
AdvDefaultLifetime. | AdvDefaultLifetime. | |||
- In the M and O flags: the interface's configured AdvManagedFlag | - In the M and O flags: the interface's configured AdvManagedFlag | |||
and AdvOtherConfigFlag, respectively. See [ADDRCONF]. | and AdvOtherConfigFlag, respectively. | |||
- In the Cur Hop Limit field: the interface's configured | - In the Cur Hop Limit field: the interface's configured | |||
CurHopLimit. | CurHopLimit. | |||
- In the Reachable Time field: the interface's configured | - In the Reachable Time field: the interface's configured | |||
AdvReachableTime. | AdvReachableTime. | |||
- In the Retrans Timer field: the interface's configured | - In the Retrans Timer field: the interface's configured | |||
AdvRetransTimer. | AdvRetransTimer. | |||
skipping to change at page 50, line 54 | skipping to change at page 51, line 10 | |||
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 increase the 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 | |||
skipping to change at page 55, line 44 | skipping to change at page 55, line 51 | |||
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 or a router | ||||
advertisement without a link-layer address option included. These | ||||
messages MUST not create or update neighbor 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 for the source of | ||||
such a message, Address Resolution will be required before unicast | ||||
communications with that address to begin. This is particularly | ||||
relevant for unicast responses to solicitations 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 join | |||
the all-nodes multicast address on that interface, as well as the | the all-nodes multicast address on that interface, as well as the | |||
solicited-node multicast address corresponding to each of the IP | solicited-node multicast address corresponding to each of the IP | |||
addresses assigned to the interface. | addresses assigned to the interface. | |||
The set of addresses assigned to an interface may change over time. | The set of addresses assigned to an interface may change over time. | |||
New addresses might be added and old addresses might be removed | New addresses might be added and old addresses might be removed | |||
[ADDRCONF]. In such cases the node MUST join and leave the | [ADDRCONF]. In such cases the node MUST join and leave the | |||
skipping to change at page 57, line 15 | skipping to change at page 57, line 31 | |||
Retransmissions MUST be rate-limited to at most one solicitation per | Retransmissions MUST be rate-limited to at most one solicitation per | |||
neighbor every RetransTimer milliseconds. | neighbor every RetransTimer milliseconds. | |||
If no Neighbor Advertisement is received after MAX_MULTICAST_SOLICIT | If no Neighbor Advertisement is received after MAX_MULTICAST_SOLICIT | |||
solicitations, address resolution has failed. The sender MUST return | solicitations, address resolution has failed. The sender MUST return | |||
ICMP destination unreachable indications with code 3 (Address | ICMP destination unreachable indications with code 3 (Address | |||
Unreachable) for each packet queued awaiting address resolution. | Unreachable) for each packet queued awaiting address resolution. | |||
7.2.3. Receipt of Neighbor Solicitations | 7.2.3. Receipt of Neighbor Solicitations | |||
A valid Neighbor Solicitation that does not meet any 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]. | |||
skipping to change at page 59, line 20 | skipping to change at page 59, line 37 | |||
Target Link-Layer address option included, the receiving node SHOULD | Target Link-Layer address option included, the receiving node SHOULD | |||
silently discard the received advertisement. | silently discard the received advertisement. | |||
If the target's Neighbor Cache entry is in the INCOMPLETE state when | If the target's Neighbor Cache entry is in the INCOMPLETE state when | |||
the advertisement is received, one of two things happen: If the | the advertisement is received, one of two things happen: If the | |||
advertisement were solicited, the state is changed to REACHABLE. | advertisement were solicited, the state is changed to REACHABLE. | |||
Otherwise, the state is set to STALE. Note that the Override flag is | Otherwise, the state is set to STALE. Note that the Override flag is | |||
ignored if the entry is in the | ignored if the entry is in the | |||
INCOMPLETE state. | INCOMPLETE state. | |||
If the Neighbor Cache entry is not in INCOMPLETE state, the receiving | If the Neighbor Cache entry is in INCOMPLETE state, the receiving | |||
node performs the following steps: | node performs the following steps: | |||
- It records the link-layer address in the Neighbor Cache entry. | - It records the link-layer address in the Neighbor Cache entry. | |||
- If the advertisement's Solicited flag is set, the state of the | - If the advertisement's Solicited flag is set, the state of the | |||
entry is set to REACHABLE, otherwise it is set to STALE. | entry is set to REACHABLE, otherwise it is set to STALE. | |||
- It sets the IsRouter flag in the cache entry based on the Router | - It sets the IsRouter flag in the cache entry based on the Router | |||
flag in the received advertisement. | flag in the received advertisement. | |||
skipping to change at page 59, line 45 | skipping to change at page 60, line 12 | |||
INCOMPLETE when the advertisement is received, the following actions | INCOMPLETE when the advertisement is received, the following actions | |||
take place: | take place: | |||
I. If the Override flag is clear and the supplied link-layer address | I. If the Override flag is clear and the supplied link-layer address | |||
differs from that in the cache, then one of two actions takes | differs from that in the cache, then one of two actions takes | |||
place: | place: | |||
a. If the state of the entry is REACHABLE, set it to STALE, but | a. If the state of the entry is REACHABLE, set it to STALE, but | |||
do not update the entry in any other way. | do not update the entry in any other way. | |||
b. Otherwise, the received advertisement should be ignored and MUST | b. Otherwise, the received advertisement should be ignored and MUST | |||
NOT update the cache. | NOT update the cache. | |||
II. If the Override flag is set, or, both the Override flag is clear | II. If the Override flag is set, or the supplied Override flag is | |||
and the supplied link-layer address is the same as that in the | Clear, or the supplied link-layer address is the same as that in | |||
cache, or no Target Link-layer address option was supplied, | the cache, or no Target Link-layer address option was supplied, | |||
the received advertisement MUST update the Neighbor Cache entry as | the received advertisement MUST update the Neighbor Cache entry | |||
follows: | as follows: | |||
- The link-layer address in the Target Link-Layer Address option | - The link-layer address in the Target Link-Layer Address option | |||
MUST be inserted in the cache (if one is supplied and is different | MUST be inserted in the cache (if one is supplied and is different | |||
than the already recorded address). | than the already recorded address). | |||
- If the Solicited flag is set, the state of the entry MUST be set | - If the Solicited flag is set, the state of the entry MUST be set | |||
to REACHABLE. If the Solicited flag is zero and the link-layer | to REACHABLE. If the Solicited flag is zero and the link-layer | |||
address was updated with a different address the state MUST be set | address was updated with a different address the state MUST be set | |||
to STALE. Otherwise, the entry's state remains unchanged. | to STALE. Otherwise, the entry's state remains unchanged. | |||
skipping to change at page 63, line 52 | skipping to change at page 64, line 18 | |||
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 confirm the one-way path from the sender | of unsolicited messages only confirms the one-way path from the | |||
to the recipient node. In contrast, Neighbor Unreachability | sender to the recipient node. In contrast, Neighbor Unreachability | |||
Detection requires that a node keep track of the reachability of the | Detection requires that a node keep track of the reachability of the | |||
forward path to a neighbor from the its perspective, not the | forward path to a neighbor from the its perspective, not the | |||
neighbor's perspective. Note that receipt of a solicited | neighbor's perspective. Note that receipt of a solicited | |||
advertisement indicates that a path is working in both directions. | advertisement indicates that a path is working in both directions. | |||
The solicitation must have reached the neighbor, prompting it to | The solicitation must have reached the neighbor, prompting it to | |||
generate an advertisement. Likewise, receipt of an advertisement | generate an advertisement. Likewise, receipt of an advertisement | |||
indicates that the path from the sender to the recipient is working. | indicates that the path from the sender to the recipient is working. | |||
However, the latter fact is known only to the recipient; the | However, the latter fact is known only to the recipient; the | |||
advertisement's sender has no direct way of knowing that the | advertisement's sender has no direct way of knowing that the | |||
advertisement it sent actually reached a neighbor. From the | advertisement it sent actually reached a neighbor. From the | |||
skipping to change at page 68, line 42 | skipping to change at page 69, line 8 | |||
- 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 link as the sending node for the Destination Address of | the same link as the sending node for the Destination Address of | |||
the packet being forwarded, and | the packet being forwarded, and | |||
- the Destination Address of the packet is not a multicast | - the Destination Address of the packet is not a multicast | |||
address, and | 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. | |||
skipping to change at page 72, line 52 | skipping to change at page 73, line 17 | |||
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 main | |||
vulnerabilities of the protocol fall under three categories: | vulnerabilities of the protocol fall under three categories: | |||
- 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. The | |||
Neighbor Unreachability Detection will not detect such a black hole | Neighbor Unreachability Detection (NUD) will not detect such a black | |||
as long as the rogue router politely answers the NUD probes with a | hole as long as the rogue router politely answers the NUD probes with | |||
Neighbor Advertisement with the R-bit set. | 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 advertisement | |||
(in response to a solicitation) that contains its IP address and a | (in response to a solicitation) that contains its IP address and a | |||
victim's link layer address in order to flood the victim with | victim's link layer address in order to flood the victim with | |||
unwanted traffic. Alternatively, the host can send a Neighbor | unwanted traffic. Alternatively, the host can send a Neighbor | |||
Advertisement that includes a victim's IP address and its own link | Advertisement that includes a victim's IP address and its own link | |||
layer address to overwrite an existing entry in the sender's | layer address to overwrite an existing entry in the sender's | |||
destination cache, thereby forcing the sender to forward all of the | destination cache, thereby forcing the sender to forward all of the | |||
victim's traffic to itself. | victim's traffic to itself. | |||
The trust model for redirects is the same as in IPv4. A redirect is | The trust model for redirects is the same as in IPv4. A redirect is | |||
accepted only if received from the same router that is currently | accepted only if received from the same router that is currently | |||
being used for that destination. It is natural to trust the routers | being used for that destination. If a host has been redirected to | |||
on the link. If a host has been redirected to another node (i.e., | another node (i.e., the destination is on-link) there is no way to | |||
the destination is on-link) there is no way to prevent the target | prevent the target from issuing another redirect to some other | |||
from issuing another redirect to some other destination. However, | destination. However, this exposure is no worse than it was before | |||
this exposure is no worse than it was before being redirected; the | being redirected; the target host, once subverted, could always act | |||
target host, once subverted, could always act as a hidden router to | as a hidden router to forward traffic elsewhere. | |||
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 | |||
skipping to change at page 74, line 38 | skipping to change at page 74, line 55 | |||
resolution or neighbor solicitation messages as documented in | resolution or neighbor solicitation messages as documented in | |||
[ICMPIKE]. The security of Neighbor Discovery messages through | [ICMPIKE]. The security of Neighbor Discovery messages through | |||
dynamic keying is outside the scope of this document and is addressed | dynamic keying is outside the scope of this document and is addressed | |||
in [SEND]. | in [SEND]. | |||
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-AH] or [IPv6-ESP] to secure | security associations with either [IPv6-AH] 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. | limited to small networks with known hosts. In any case, if either | |||
[IPv6-AH] or [IPv6-ESP] is used, ND packets MUST be verified for the | ||||
purpose of authentication. Packets that fail authentication 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. | |||
skipping to change at page 76, line 26 | skipping to change at page 76, line 45 | |||
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 | [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 | |||
(IPv6) Specification", RFC 2460, December 1998. | (IPv6) Specification", RFC 2460, December 1998. | |||
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate | [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
INFORMATIVE | INFORMATIVE | |||
[ADDRCONF] Thomson, S. Narten, T, and T. Jinmei, "IPv6 Address | [ADDRCONF] Thomson, S. Narten, T, and T. Jinmei, "IPv6 Address | |||
Autoconfiguration", draft-ietf-ipv6-rfc2462bis-07, Dec | Autoconfiguration", draft-ietf-ipv6-rfc2462bis-08, May | |||
2004. | 2005. | |||
[ADDR-SEL] Draves, R., "Default Address Selection for Internet | ||||
Protocol version 6 (IPv6)", RFC 3484, February 2003. | ||||
[ANYCST] Partridge, C., Mendez, T. and W. Milliken, "Host | [ANYCST] Partridge, C., Mendez, T. and W. Milliken, "Host | |||
Anycasting Service", RFC 1546, November 1993. | Anycasting Service", RFC 1546, November 1993. | |||
[ARP] Plummer, D., "An Ethernet Address Resolution Protocol", | [ARP] Plummer, D., "An Ethernet Address Resolution Protocol", | |||
STD 37, RFC 826, November 1982. | STD 37, RFC 826, November 1982. | |||
[ASSIGNED] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by | [ASSIGNED] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by | |||
an On-line Database", RFC 3232, January 2002. | an On-line Database", RFC 3232, January 2002. | |||
[DHCPv6] Droms, R., Ed, "Dynamic Host Configuration Protocol for | [DHCPv6] Droms, R., Ed, "Dynamic Host Configuration Protocol for | |||
skipping to change at page 79, line 48 | skipping to change at page 80, line 22 | |||
No mechanism exists for the multihomed host to detect this | No mechanism exists for the multihomed host to detect this | |||
situation. | situation. | |||
If a multihomed host fails to receive Router Advertisements on one or | If a multihomed host fails to receive Router Advertisements on one or | |||
more of its interfaces, it will not know (in the absence of | more of its interfaces, it will not know (in the absence of | |||
configured information) which destinations are on-link on the | configured information) which destinations are on-link on the | |||
affected interface(s). This leads to a number of problems: | affected interface(s). This leads to a number of problems: | |||
1) If no Router Advertisement is received on any interfaces, a | 1) If no Router Advertisement is received on any interfaces, a | |||
multihomed host will have no way of knowing which interface to | multihomed host will have no way of knowing which interface to | |||
send packets out on, even for on-link destinations. Under | send packets out on, even for on-link destinations. | |||
similar conditions in the non-multihomed host case, a node | One possible approach for a multihomed node would be to attempt | |||
treats all destinations as residing on-link, and communication | to perform address resolution on all interfaces, a step | |||
proceeds. In the multihomed case, however, additional | involving significant complexity. | |||
information is needed to select the proper outgoing interface. | ||||
Alternatively, a node could attempt to perform address | ||||
resolution on all interfaces, a step involving significant | ||||
complexity that is not present in the non-multihomed host case. | ||||
2) If Router Advertisements are received on some, but not all | 2) If Router Advertisements are received on some, but not all | |||
interfaces, a multihomed host could choose to only send packets | interfaces, a multihomed host could choose to only send packets | |||
out on the interfaces on which it has received Router | out on the interfaces on which it has received Router | |||
Advertisements. A key assumption made here, however, is that | Advertisements. A key assumption made here, however, is that | |||
routers on those other interfaces will be able to route packets | routers on those other interfaces will be able to route packets | |||
to the ultimate destination, even when those destinations reside | to the ultimate destination, even when those destinations reside | |||
on the subnet to which the sender connects, but has no on-link | on the subnet to which the sender connects, but has no on-link | |||
prefix information. Should the assumption be FALSE, | prefix information. Should the assumption be FALSE, | |||
communication would fail. Even if the assumption holds, packets | communication would fail. Even if the assumption holds, packets | |||
skipping to change at page 84, line 38 | skipping to change at page 85, line 6 | |||
directly (i.e., without an expensive lookup) once the TCP packet has | directly (i.e., without an expensive lookup) once the TCP packet has | |||
been demultiplexed to its corresponding control block. For other | been demultiplexed to its corresponding control block. For other | |||
implementation it may be possible to piggyback the reachability | implementation 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. In merely indicates that 30 minutes | the path is currently working. It merely indicates that 30 minutes | |||
ago the window update reached the peer i.e. the path was working at | ago the window update reached the peer i.e. the path was working at | |||
that point in time. An implementation must also take into account | that point in time. An implementation must also take into account | |||
TCP zero-window probes that are sent even if the path is broken and | TCP zero-window probes that are sent even if the path is broken and | |||
the window update did not reach the peer. | the window update did not reach the peer. | |||
For UDP based applications (RPC, DNS) it is relatively simple to make | For UDP based applications (RPC, DNS) it is relatively simple to make | |||
the client send reachability confirmations when the response packet | the client send reachability confirmations when the response packet | |||
is received. It is more difficult and in some cases impossible for | is received. It is more difficult and in some cases impossible for | |||
the server to generate such confirmations since there is no flow | the server to generate such confirmations since there is no flow | |||
control, i.e., the server can not determine whether a received | control, i.e., the server can not determine whether a received | |||
skipping to change at page 85, line 51 | skipping to change at page 86, line 21 | |||
o Clarified router behaviour when receiving a Router Solicitation | o Clarified router behaviour when receiving a Router Solicitation | |||
without SLLAO. | without SLLAO. | |||
o Clarified that inconsistency checks for CurHopLimit are done for | o Clarified that inconsistency checks for CurHopLimit are done for | |||
none zero values only. | none 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 | ||||
upon receiving a message without SLLAO. | ||||
o Miscellaneous editorials. | o Miscellaneous editorials. | |||
Intellectual Property Statement | Intellectual Property Statement | |||
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 | |||
skipping to change at page 86, line 31 | skipping to change at page 86, line 52 | |||
http://www.ietf.org/ipr. | http://www.ietf.org/ipr. | |||
The IETF invites any interested party to bring to its attention any | The IETF invites any interested party to bring to its attention any | |||
copyrights, patents or patent applications, or other proprietary | copyrights, patents or patent applications, or other proprietary | |||
rights that may cover technology that may be required to implement | rights that may cover technology that may be required to implement | |||
this standard. Please address the information to the IETF at ietf- | this standard. Please address the information to the IETF at ietf- | |||
ipr@ietf.org. | ipr@ietf.org. | |||
Full Copyright Statement | Full Copyright Statement | |||
Copyright (C) The Internet Society (2004). This document is subject | Copyright (C) The Internet Society (2005). This document is subject | |||
to the rights, licenses and restrictions contained in BCP 78, and | to the rights, licenses and restrictions contained in BCP 78, and | |||
except as set forth therein, the authors retain all their rights. | except as set forth therein, the authors retain all their rights. | |||
Disclaimer of Validity | Disclaimer of Validity | |||
This document and the information contained herein are provided on an | This document and the information contained herein are provided on an | |||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | |||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET | OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET | |||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | |||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | |||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | |||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |||
This Internet-Draft expires August, 2005. | This Internet-Draft expires November, 2005. | |||
End of changes. | ||||
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |