idnits 2.17.1 draft-wasserman-ipv6-nd-division-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 164 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Router Discovery allows IPv6 hosts to dynamically discover routers which can be used to forward packets off-link. This is accomplished through the use of ICMPv6 Router Solicitations and Router Advertisements. In general hosts send Router Solicitations and process received Advertisements while routers send Router Advertisements periodically or in response to Solicitations. Hosts which support Router Discovery store the information received in Router Advertisements in a Default Router List. Routers which support Router Discovery MAY or MAY NOT store information based upon received Router Advertisements, but the use of that information lies outside the scope of the Neighbor Discovery protocol. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 1998) is 9416 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-02) exists of draft-ietf-ipngwg-discovery-v2-01 == Outdated reference: A later version (-01) exists of draft-ietf-ipngwg-addrconf-v2-00 Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Margaret Wasserman 3 IPng Working Group Epilogue Technology 4 January 1998 5 Expires July 1998 7 Division of IPv6 Neighbor Discovery Into Separable Mechanisms 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet- Drafts as reference 19 material or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 This memo provides information for the Internet community. This memo 28 does not specify an Internet standard of any kind, but proposes 29 changes to existing Internet Drafts. Distribution of this memo is 30 unlimited. 32 Abstract 34 This memo proposes a formal division of the existing IPv6 Neighbor 35 Discovery protocol into eight separable, related mechanisms: Address 36 Resolution, Duplicate Address Detection (DAD), Router Discovery, 37 Prefix/Parameter Discovery, Address Autoconfiguration, Router 38 Unreachability Detection (RUD), Neighbor Unreachability Detection 39 (NUD) and ICMPv6 Redirects. These mechanisms all depend upon a common 40 set of ICMPv6 Neighbor Discovery messages, but can be enabled and 41 disabled independently, subject to the restrictions and 42 recommendations outlined in this draft. 44 It is not the intention of this memo to propose substantive changes to 45 the existing IPv6 Neighbor Discovery protocol, but to allow the 46 separate portions of IPv6 Neighbor Discovery to be unambiguously 47 identified, making it possible to specify or configure different 48 portions of IPv6 Neighbor Discovery for use on specific link-types, 49 links or interfaces. 51 1. Introduction 53 In discussions within the IETF IPng Working Group and on the mailing 54 list, it has become clear that different portions of the IPv6 Neighbor 55 Discovery (ND) protocol[1] may or may not be applicable to specific 56 situations (e.g. tunnels). For example, it might be desireable to 57 perform DAD on a link for which Router Discovery is unnecessary. Or, 58 RD could be valuable in a situation where Address Resolution is not 59 needed. 61 It has also become clear that the use of some portions of ND, such as 62 Address Resolution, could be specified in the link-type specifications 63 ("IPv6 over XXXX"), whereas it might be useful to configure some 64 portions of ND on a per-link or per-interface basis (e.g. DAD). 66 In order to advance these discussions, it is necessary to view ND as a 67 group of separable, related mechanisms -- mechanisms which share a 68 common set of conceptual datastructures and ICMPv6 ND messages but 69 which can be used (or not used) independently. Although this view is 70 already discussed in the IPv6 ND specification, the current 71 specification does not separately describe the behaviour of these 72 mechanisms or divide them with sufficiently fine granularity. It is 73 the purpose of this draft to specify eight separable ND mechanisms, 74 identify their dependencies, determine restrictions on their 75 configuration and use, make recommendations regarding their default 76 state and propose their requirement levels within compliant IPv6 77 implementations. This draft is highly derivative of the IPv6 Neighbor 78 Discovery specification[1] and does not describe the ND mechanisms in 79 their entirety. This draft attempts to clarify, not substantially 80 modify, the mechanisms defined in the ND specification. 82 2. Terminology 84 This draft relies on the terminology included in the current IPv6 85 Neighbor Discovery Internet Draft [1]. 87 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 88 SHOULD NOT, RECOMMENDED, MAY and OPTIONAL, when they appear in this 89 document are to be interpreted as described in [2]. 91 3. ND Messages and Conceptual Datastructures 93 Although the basic mechanisms of IPv6 Neighbor Discovery remain 94 unchanged, the ability to selectively enable specific mechanisms will 95 result in some nodes which only require a subset of the messages or 96 datastructures required for a full IPv6 ND implementation. The 97 messages, options, datastructures and states used by each portion of 98 IPv6 ND are described in the mechanism-specific and summary sections 99 below. 101 The five ICMPv6 messages described in the Neighbor Discovery 102 specification and their options remain unchanged. Depending upon 103 which ND mechanisms are in use, however, a node could support sending 104 or receiving only a subset of the ND messages or none at all. 105 Unsupported messages MUST be silently discarded in most cases. 107 The conceptual datastructures described in the ND specification are 108 also unmodified. However, a full set of conceptual datastructures may 109 not be needed on a node which only implements a subset of IPv6 ND. 111 3.1 Levels of Neighbor Cache Support 113 The full set of Neighbor Cache states and the corresponding semantics 114 may not be necessary on all nodes (e.g. those which do not have both 115 Address Resolution and Neighbor Unreachability Detection enabled). In 116 order to specify which portions of the full Neighbor Cache are 117 necessary on different systems, it is useful to define three different 118 levels of Neighbor Cache implementation: 120 Level 0: No Neighbor Cache. 122 This level would be applicable to a host which 123 does not implement either Address Resolution or 124 Neighbor Unreachability Detection. In this 125 case, no Neighbor Cache lookup is necessary to 126 send an IPv6 packet, so no Neighbor Cache need 127 be maintained. 129 Level 1: 2-State Neighbor Cache. 131 This level would be applicable to a host which 132 implements Address Resolution but does not implement 133 Neighbor Unreachability Detection. This datastructure 134 would be roughly equivalent to the ARP cache on IPv4 135 hosts. 137 This cache would have only two states: INCOMPLETE 138 and COMPLETE. 140 Entries in the INCOMPLETE state do not have 141 any valid link-layer address information associated 142 with them. They may have one or more queued packets 143 awaiting address resolution. 145 Entries in the COMPLETE state do have link-layer 146 address information suitable for use in sending 147 packets. They can be updated by subsequent 148 Neighbor Advertisements with new link-layer 149 address information. 151 COMPLETE entries periodically timeout. An 152 implementation MAY choose whether to detect such 153 a timeout immediately, on a periodic sweep, or 154 when the next packet is sent to the corresponding 155 destination. When a timeout is detected, the 156 timed-out entry MAY be returned to the INCOMPLETE 157 state or removed from the cache. 159 These two states can be viewed as a degenerate 160 version of the states in the full Neighbor Cache 161 described in the current ND specification as follows: 163 INCOMPLETE INCOMPLETE 164 PROBE 166 STALE COMPLETE 167 REACHABLE 168 DELAY 170 Viewing the Neighbor Cache as a two-state cache 171 when Neighbor Unreachability Detection is not in 172 use can greatly simplify the implementation 173 of Address Resolution for minimal systems which 174 do not provide any support for Neighbor Unreachability 175 Detection. 177 If there is significant resistance to having different 178 cache semantics for different combinations of ND 179 features, the same functionality can be achieved by 180 adjusting the default timer values based upon the 181 specific ND options currently enabled. 183 Level 2: 5-State Neighbor Cache. 185 This level would be applicable to a host which 186 implements both Address Resolution and Neighbor 187 Unreachability Detection. This is the full 188 Neighbor Cache currently described in the 189 ND specification. 191 4. Address Resolution 193 Address Resolution is one of the core mechanisms of IPv6 Neighbor 194 Discovery. It allows IPv6 addresses to be mapped to link-layer 195 addresses via the exchange of Neighbor Solicitation and Neighbor 196 Advertisement ICMPv6 messages containing Source Link-Layer Address and 197 Target Link-Layer Address options. Information regarding the address 198 mapping is stored in a Neighbor Cache conceptual datastructure (Level 199 1 or higher). IPv6 ND Address Resolution is not dependent upon the 200 use of other IPv6 ND mechanisms. 202 IPv6 ND Address Resolution is only useful on multicast-capable 203 link-types which require a network-layer mechanism for mapping IPv6 204 addresses to link-layer addresses. 206 For multicast-capable links that require an address 207 resolution mechanism, the link-type specification SHOULD 208 mandate the use of IPv6 ND Address Resolution. 210 For multicast-capable links that do not require an address 211 resolution mechanism (e.g. some point-to-point links) the 212 link-type specification SHOULD specifically state that 213 IPv6 ND Address Resolution will not be used. 215 For non-multicast-capable links, the link-type specification 216 MAY specify modifications to the IPv6 ND Address Resolution 217 mechanism or MAY specify a different address resolution 218 mechanism. 220 >From a node's perspective, use of IPv6 ND Address Resolution is 221 enabled or disabled on a per-interface basis based solely upon the 222 link-type of the interface's link. Interfaces to links which support 223 IPv6 ND Address Resolution MUST have Address Resolution support 224 enabled while others MUST have support for IPv6 ND Address Resolution 225 disabled. ICMPv6 Neighbor Solicitation or Advertisement messages 226 received on links which have IPv6 ND Address Resolution disabled MUST 227 be silently discarded, unless they are of interest to other enabled ND 228 mechanisms. 230 The basic mechanism for IPv6 ND Address Resolution is unchanged from 231 the ND specification, except for the possible changes in the Neighbor 232 Cache states described in the previous section. 234 All compliant IPv6 implementations MUST support IPv6 ND Address 235 Resolution for any link-types which require it. 237 5. Duplicate Address Detection 239 Duplicate Address Detection (DAD) involves sending an ICMPv6 Neighbor 240 Solicitation message (with or without link-layer address options) when 241 a new address token is added to an interface in order to detect 242 duplicate address tokens in use on the link. DAD can be very valuable 243 when it is possible for two or more nodes to accidentally (or through 244 human error) choose the same interface token for use on a shared link. 245 DAD's usefulness is sharply curtailed on a given link if it is not 246 implemented for all nodes on the link. DAD requires support for 247 both the ICMPv6 Neighbor Solicitation and Advertisement messages, but 248 does not require support for either of the link-layer address options. 249 If DAD is enabled and IPv6 ND Address Resolution is not enabled, any 250 received link-layer address options MAY be ignored. 252 DAD does, however, introduce some traffic overhead and a delay in 253 interface initialization. For links that do not implement IPv6 ND 254 Address Resolution, DAD also introduces additional ICMPv6 messages. 255 So the benefits may not justify the costs in some cases. Therefore, a 256 link-type specification SHOULD specify whether DAD is or is not 257 REQUIRED for a specific link-type. If the link-type specification 258 indicates that use of DAD is optional for a given link-type, it SHOULD 259 specify what mechanism will be used to determine whether or not DAD is 260 in use on a given link at a given time (e.g. automatic mechanism, manual 261 configuration, etc.). 263 Because DAD may introduce too much overhead in specific situations, 264 implementations MAY allow DAD to be disabled on a per-node or 265 per-interface basis via stateful or manual configuration (within the 266 restrictions imposed by the link-type specifications). Implementations 267 which support DAD SHOULD default to using DAD for all new interface 268 tokens on all interfaces for which it has not be explicitly disabled. 270 DAD does not depend upon any other ND mechanisms and can be implemented 271 without support for any of the ND conceptual datastructures. Compliant 272 IPv6 implementations MUST support the use of DAD on all link-types 273 for which it is not explicitly disabled by the link-type specification. 275 6. Router Discovery 277 Router Discovery allows IPv6 hosts to dynamically discover routers 278 which can be used to forward packets off-link. This is accomplished 279 through the use of ICMPv6 Router Solicitations and Router 280 Advertisements. In general hosts send Router Solicitations and 281 process received Advertisements while routers send Router 282 Advertisements periodically or in response to Solicitations. Hosts 283 which support Router Discovery store the information received in 284 Router Advertisements in a Default Router List. Routers which support 285 Router Discovery MAY or MAY NOT store information based upon received 286 Router Advertisements, but the use of that information lies outside the 287 scope of the Neighbor Discovery protocol. 289 Router Discovery is a complex process which can be extremely valuable 290 when hosts are configured on complex or changing networks, but it may 291 be unnecessary for some link-types (e.g. Point-to-point links where 292 all traffic is sent through the remote end-point). There are also 293 security issues with Router Discovery that may make it undesireable in 294 some environments. Therefore, Router Discovery MAY be explicitly 295 enabled or disabled for a particular link-type in the link-type 296 specification. Implementations SHOULD also allow Router Discovery to be 297 disabled on a per-interface basis (via stateful or manual 298 configuration). 300 Nodes MUST silently discard Router Solicitations and Advertisements 301 received on interfaces which do not have Router Discovery enabled, 302 unless those messages are of interest to other enabled ND mechanisms. 304 The term Router Disocovery refers only to the process of receiving 305 Router Advertisements and adding and deleting advertised routers 306 to/from the Default Router List. Processing the additional 307 configuration information obtained in Router Advertisments, 308 configuring addresses based upon that information and maintaining 309 reachability information for routers are covered by Prefix/Parameter 310 Discovery, Address Autoconfiguration and Router Unreachability 311 Detection, respectively. It is possible to enable Router Discovery to 312 dynamically create and maintain a Default Router List without enabling 313 any of these separate, related mechanisms. 315 When a router is placed in the Default Router List, its lifetime is 316 also included. This lifetime may be updated by subsequent Router 317 Advertisements, pursuant to the restrictions in the ND specification. 318 When the lifetime of a Router Advertisement expires, the corresponding 319 router will be removed from the Default Router List. It is also 320 RECOMMENDED that nodes which implement Router Discovery include support 321 for Router Unreachability Detection to allow ongoing communications 322 using the "unreachable" router to choose a new next-hop address. 324 It is REQUIRED that all compliant IPv6 routers support Router 325 Discovery. It is also RECOMMENDED that a compliant IPv6 host support 326 Router Discovery, and hosts which do implement Router Discovery SHOULD 327 default to using it for all interfaces for which it has not been 328 explicitly disabled. 330 7. Prefix/Parameter Discovery 332 Prefix/Parameter Discovery is the mechanism by which hosts obtain 333 information about an attached link to use in configuration of the 334 interface. This information might include MTU information and the site 335 local and/or global prefixes in use on the link and their associated 336 lifetimes. Although this information is contained in Router 337 Advertisement messages, it is possible to use this information for 338 interface configuration without choosing to place the supplied router 339 address(es) in the Default Router List. 341 Prefix/Parameter Discovery is the mechanism used to obtain this 342 link-specific configuration information and store it in the Prefix 343 List and other interface-specific configuration structures. The 344 mechanism used for creating IPv6 addresses from this information is 345 handled by a separate mechanism called Address Autoconfiguration. 347 Since Prefix/Parameter Discovery is required for Address 348 Autoconfiguration, it is automatically enabled whenever Address 349 Autoconfiguration is in use. It is also possible to configure 350 Prefix/Parameter Discovery separately to allow configuration of 351 link-specific information (e.g. MTU) when the IPv6 addresses will be 352 obtained elsewhere (e.g. through either stateful or manual 353 configuration). 355 It is possible for a link-type specification to explicitly disable 356 the use of Prefix/Parameter Discovery for a specific link-type. 357 The use of Prefix/Parameter Discovery MAY also be configurable on 358 a per-interface basis. 360 A compliant IPv6 host SHOULD implement Prefix/Parameter Discovery 361 on any applicable link-type. Routers MUST implement the ability 362 to send Prefix and Parameter information in Router Advertisements 363 on any applicable link-types, although they MAY allow use of 364 this mechanism to be disabled on a per-interface basis. 366 8. Address Autoconfiguration 368 Address Autoconfiguration is an extremely powerful and desireable 369 Neighbor Discovery mechanism for use in many situations. It is 370 described in a separate ND-related document [3], but relies upon 371 information contained in ND Router Advertisement messages and upon the 372 Prefix/Parameter Discovery mechanism. After discovering prefix 373 information via Prefix/Parameter Discovery, a host can automatically 374 generate site-local and global IPv6 addresses to allow for global 375 communication without any explicit configuration (manual or stateful). 377 This mechanism SHOULD be supported for all link-types which do not 378 inherently allow discovery of address information through other means. 379 When Address Autoconfiguration is in use for a particular link-type, 380 the link-type specification SHOULD also specify use of DAD, unless 381 another mechanism is provided for preventing or discovering duplicate 382 IPv6 addresses. 384 A compliant IPv6 host SHOULD implement Address Autoconfiguration for 385 applicable link-types. However, a host which supports Address 386 Autoconfiguration SHOULD allow it to be disabled on a per-host or 387 per-interface basis. Address Autoconfiguration is a host-only 388 mechanism; routers obtain their address information through other 389 means outside the scope of the Neighbor Discovery protocol. 391 9. Router Unreachability Detection 393 Router Unreachability Detection is dependent upon the use of Router 394 Discovery. When a "discovered" router times-out and is removed from 395 the Default Router List, the same router may also be currently in-use 396 as a next-hop for communication with any number of destinations, either 397 because it was originally chosen as the default router for that 398 communication or due to subsequent ICMPv6 Redirects. Router Unreachability 399 Detection is the process of looking through the destination cache, and 400 causing all communications through the "unreachable" router to perform 401 a new next-hop determination. 403 Although Router Discovery can be somewhat useful without the 404 implementation of Router Unreachability Detection, it is highly 405 RECOMMENDED that this mechanism be enabled when Router Discovery is 406 enabled, as it introduces very little additional overhead and allows 407 existing communications to recover smoothly when a router becomes 408 unreachable. 410 10. Neighbor Unreachability Detection 412 Neighbor Unreachability Detection (NUD) uses Neighbor Solicitations, 413 Neighbor Advertisements and on-going advice from upper-layer protocols 414 to determine the two-way reachability of a particular neighbor. When 415 a neighbor becomes unreachable, a node can perform Address Resolution 416 again to determine if the neighbor is now reachable at a new 417 link-layer address. 419 Neighbor Unreachability Detection is an interesting concept, the uses 420 for which have not been completely established. When Address 421 Resolution is in use, NUD allows for fairly quick recovery when a node 422 changes to a new link-layer address. Also, when upper layer advice is 423 available, this mechanism can help to eliminate unnecessary Address 424 Resolution traffic. 426 However, on a link which does not use ND Address Resolution 427 (e.g. point-to-point links), in situations where upper-layer advice 428 may not be available (e.g. an SNMP agent or a transaction processing 429 system), this mechanism may actually result in more traffic than 430 otherwise necessary, determining two-way reachability on an ongoing 431 basis when the information is not of interest. 433 Ultimately, Neighbor Unreachability Detection may prove very useful to 434 allow for dynamically switching between treating a particular node as 435 on-link or off-link for particular link-types with assymetric 436 reachability (e.g. for RF links), but insufficient experience is 437 available to be certain at this time. 439 For certain link-types, reachability may already be established by 440 a link-layer mechanism before any packets are sent. In this case, 441 Neighbor Unreachability Detection is redundant and should be disabled 442 by the link-type specification. 444 For other situations, there are two factors that most influence 445 whether Neighbor Unreachability Detection is useful for a given link: 447 - Whether ND Address Resolution is in-use. 448 - Whether upper-layer advice is available for 449 a significant portion of the communications. 451 If ND Address Resolution is in use, and upper-layer advice is likely 452 to be available, it is RECOMMENDED that Neighbor Unreachability 453 Detection be used to cut down on superfluous Address Resolution 454 traffic. Although use of Address Resolution is specified on a 455 per-link-type basis, it may only be possible to determine if 456 upper-layer advice will be available on a per-node basis. Therefore, 457 implementations should allow Neighbor Discovery to be configured on a 458 per-node or per-interface basis. 460 On links which do not use ND Address Resolution, it is RECOMMENDED 461 that Neighbor Unreachability Detection be disabled unless specifically 462 overridden by the link-layer specification. 464 Given the uncertainty of the trade-offs between the complexity of 465 Neighbor Unreachability Detection and its benefits, it is OPTIONAL for 466 an implementation to support Neighbor Unreachability Detection unless 467 the implementation supports a link-type for which Neighbor 468 Unreachability Detection is REQUIRED by the link-type specification. 470 11. ICMPv6 Redirects 472 It is expected that the use of ICMPv6 Redirects will be supported on 473 most, if not all, IPv6 interfaces. This mechanism allows a router to 474 inform a host that IP datagrams destined for a particular node or 475 subnet should be sent to a different next-hop address than the one 476 currently in-use. This is accomplished via sending an ICMPv6 Redirect 477 message. 479 The use of ICMPv6 Redirects on a particular link-type MAY be disabled 480 by a link-type specification. A host implementation MAY allow ICMPv6 481 Redirects to be disabled on a per-interface basis. When ICMPv6 482 Redirects are not in use on a particular link, routers SHOULD NOT send 483 Redirect messages. Any Redirect messages received by a host on an 484 interface which has ICMPv6 Redirects disabled MUST be silently 485 discarded. 487 For all applicable link-types, ICMPv6 Redirects MUST be supported by 488 compliant IPv6 implementations. 490 12. Levels of Compliance 492 After separating the IPv6 Neighbor Discovery protocol into separate 493 mechanisms, it becomes possible to discuss a minimal compliant IPv6 494 implementation which does not implement the full set of IPv6 Neighbor 495 Discovery Mechanisms. This section attempts to summarize the 496 requirement levels for the individual mechanisms discussed in this 497 document. 499 12.1 Host Compliance 501 It is possible, on a link-type that does not require Address 502 Resolution, DAD or support for ICMPv6 Redirects (e.g. a point-to-point 503 link with a fixed end-point address), to have a compliant IPv6 host 504 implementation that does not implement any ND mechanisms at all. 505 This is not likely to be the case for a majority of IPv6 implementations, 506 however. 508 To allow for minimal IPv6 host implementations, only those ND 509 mechanisms which rely upon cooperation from all hosts on a given link 510 have been strictly REQUIRED. It is anticipated that most IPv6 511 implementations will also include some or all of the RECOMMENDED 512 mechanisms, but their usefulness to the nodes that implement them 513 will not diminished if some nodes do not participate. 515 Each of the requirement levels discussed in this document may be 516 overridden, in either direction, for a particular link-type by the 517 link-type specification. 519 Compliant IPv6 hosts are REQUIRED to implement the host portions of 520 the following mechanisms if they support any applicable link-types: 522 Address Resolution 523 Duplicate Address Detection 524 ICMPv6 Redirects 526 It is strongly RECOMMENDED that IPv6 hosts implement the host portions 527 of the following mechanisms, as applicable to their supported 528 link-types: 530 Router Discovery 531 Prefix/Parameter Discovery 532 Router Unreachability Detection 533 Address Autoconfiguration 535 The following IPv6 ND mechanism is OPTIONAL for a compliant 536 IPv6 host implementations, unless explicitly required by a 537 supported link-type: 539 Neighbor Unreachability Detection 540 12.2 Router Compliance 542 Compliant IPv6 routers are REQUIRED to implement the router portions 543 of the following IPv6 ND mechanisms if applicable to any of their 544 supported link-types: 546 Address Resolution 547 Duplicate Address Detection 548 ICMPv6 Redirects 549 Router Discovery 550 Prefix/Parameter Discovery 552 The following ND mechanisms are not applicable to routers: 554 Address Autoconfiguration 555 Router Unreachability Detection 556 Neighbor Unreachability Detection 558 Routers MAY choose to use information contained in ND messages normally 559 processed only by hosts (e.g. Router Advertisements), but use of that 560 information is outside the scope of the Neighbor Discovery protocol. 562 13. Summary of Separable ND Mechanisms 564 Each of the eight separable ND mechanisms has been summarized 565 below. These summaries include the methods by which the mechanisms 566 are configurable, the default state of each mechanism, the requirement 567 level for implementation of each mechanism in a compliant IPv6 node 568 and the messages and datastructures used by each mechanism. 570 12.1 ADDRESS RESOLUTION 572 Enabled Scope: By Link-Type (in link-type specification) 573 Default: Enabled on all interfaces 574 Requirement Level: REQUIRED (for applicable link-types) 575 Dependencies: None 576 Messages Required: Neighbor Solicitation 577 with Source Link-Layer Address Option 578 Neighbor Advertisement 579 with Target Link-Layer Address Option 580 Datastructures: Neighbor Cache, Level 1 or higher 582 12.2 DUPLICATE ADDRESS DETECTION (DAD) 584 Enabled Scope: By Link-Type (in link-type spec) 585 with OPTIONAL Per-Node or Per-Interface override 586 Default: Enabled on all interfaces 587 Requirement Level: REQUIRED (for applicable link-types) 588 Dependencies: None 589 Messages Required: Neighbor Solicitation 590 Neighbor Advertisement 591 Datastructures: None 593 12.3 ROUTER DISCOVERY 595 Enabled Scope: By Link-Type (in link-type spec) 596 with RECOMMENDED Per-Interface override 597 Default: Enabled on all interfaces, if supported 598 Requirement Level: Router: REQUIRED (for applicable link-types) 599 Host: RECOMMENDED (for applicable link-types) 600 Dependencies: None 601 Messages Required: Router Solicitation 602 Router Advertisement 603 Datastructures: Default Router List 605 12.4 PREFIX/PARAMETER DISCOVERY 607 Enabled Scope: By Link-Type (in link-type spec) 608 with RECOMMENDED Per-Interface override 609 Default: Enabled on all interfaces, if supported 610 Requirement Level: Router: REQUIRED (for applicable link-types) 611 Host: RECOMMENDED (for applicable link-types) 612 Dependencies: None 613 Messages Required: Router Solicitation 614 Router Advertisement 615 Datastructures: Prefix List 616 12.5 ADDRESS AUTOCONFIGURATION 618 Enabled Scope: By Link-Type (in link-type spec) 619 with RECOMMENDED Per-Interface override 620 Default: Router: N/A 621 Host: Enabled on all interfaces, if supported 622 Requirement Level: Host: RECOMMMENDED 623 (N/A for routers) 624 Dependencies: Requires Prefix/Parameter Discovery 625 Messages Required: Router Solicitation 626 Router Advertisement 627 Datastructures: Prefix List 629 12.6 ROUTER UNREACHABILITY DETECTION 631 Enabled Scope: By Link-Type (in link-type spec) 632 with RECOMMENDED Per-Interface override 633 Default: Router: N/A 634 Host: Enabled on all interfaces, if supported 635 Requirement Level: Host: RECOMMENDED 636 (N/A for routers) 637 Dependencies: Requires Router Discovery 638 Messages Required: Router Solicitation 639 Router Advertisement 640 Datastructures: Default Router List 642 12.7 NEIGHBOR UNREACHABILITY DETECTION 644 Enabled Scope: By Link-Type (in link-type spec) 645 with RECOMMENDED Per-Interface override 646 Default: Router: N/A 647 Host: Disabled on all interfaces 648 Requirement Level: Host: OPTIONAL 649 (N/A for routers) 650 Dependencies: None 651 Messages Required: Neighbor Advertisement 652 Neighbor Solicitation 653 Datastructures: Neighbor Cache, Level 2 655 12.8 ICMPv6 REDIRECTS 657 Enabled Scope: By Link-Type (in link-type spec) or 658 with OPTIONAL Per-Node or Per-Interface override 659 Default: Enabled on all interfaces 660 Requirement Level: REQUIRED (for applicable link-types) 661 Dependencies: None 662 Required Messages: ICMPv6 Redirect Message 663 Datastructures: Destination Cache 664 14. Impact on other documents 666 If the working group agrees with the text of this document, or a 667 modified version thereof, it would be desireable to incorporate this 668 information into the main IPv6 Neighbor Discovery specification. It 669 is also possible that the current ND specification could be broken up 670 into multiple documents to allow some mechanisms (which have remained 671 constant for some time, are widely implemented and have no known 672 problems) to advance in the standards process while we continue to 673 gather experience with other mechanisms. 675 Link-type specifications SHOULD be modified, if necessary, to 676 explicitly state whether IPv6 ND Address Resolution, DAD or ICMPv6 677 Redirects are in use for their link-type. In addition, link-type 678 specifications SHOULD specify requirement levels and/or defaults for the 679 other ND mechanisms individually if different from those discussed in 680 this document. If a link-type specification does not explicitly state 681 otherwise, it is assumed that all unmentioned ND mechanisms are 682 applicable to the interface type and are subject to the requirements 683 and defaults outlined above. 685 15. Security considerations 687 This draft introduces no new protocols or mechanisms and, therefore, 688 does not introduce new security concerns. There are some existing 689 security issues with the IPv6 Neighbor Discovery protocol, as 690 discussed in [1], which are unaffected by the organizational change 691 proposed in this draft. 693 16. Acknowledgments 695 The author would like to acknowledge the input of the IPng Working 696 Group. This draft reflects ideas put forth at the IETF meeting in 697 Washington, D.C., December 1997 by several working group members. 699 16. References 701 [1] T. Narten, E. Nordmark, W. Simpson, "Neighbor Discovery for 702 IP Version 6 (IPv6)", draft-ietf-ipngwg-discovery-v2-01.txt. 704 [2] S. Bradner, "Key words for use in RFCs to Indicate 705 Requirement Levels", RFC 2119, March 1997. 707 [3] S. Thompson, T. Narten, "IPv6 Address Autoconfiguration", 708 draft-ietf-ipngwg-addrconf-v2-00.txt. 710 17. Author's contact information 712 Please address all comments or questions regarding this draft to: 714 Margaret Wasserman mrf@epilogue.com 715 Director of IP Development (617)245-1805 716 Epilogue Technology Corporation FAX: (617) 245-0804