idnits 2.17.1 draft-ahl-ipv6-nbma-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-18) 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. ** 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 241 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 26 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 100: '... - MUST...' RFC 2119 keyword, line 105: '... - SHOULD...' RFC 2119 keyword, line 112: '... - MAY...' RFC 2119 keyword, line 134: '... MAC address embedded into them MUST...' RFC 2119 keyword, line 141: '...gical interface's interface tokens MAY...' (42 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 46 has weird spacing: '... the underl...' == Line 51 has weird spacing: '...P) has been...' == Line 52 has weird spacing: '...veloped withi...' == Line 53 has weird spacing: '...l links in a...' == Line 54 has weird spacing: '...r. In addit...' == (236 more instances...) -- 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 (15 February 1996) is 10290 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) == Missing Reference: 'DHCPv6' is mentioned on line 319, but not defined == Missing Reference: 'KPLC95' is mentioned on line 475, but not defined ** Obsolete normative reference: RFC 1825 (ref. 'Atk95a') (Obsoleted by RFC 2401) ** Obsolete normative reference: RFC 1826 (ref. 'Atk95b') (Obsoleted by RFC 2402) ** Obsolete normative reference: RFC 1490 (ref. 'BBM93') (Obsoleted by RFC 2427) ** Obsolete normative reference: RFC 1885 (ref. 'CD96') (Obsoleted by RFC 2463) ** Obsolete normative reference: RFC 1883 (ref. 'DH96') (Obsoleted by RFC 2460) ** Obsolete normative reference: RFC 1483 (ref. 'Hei93') (Obsoleted by RFC 2684) -- No information found for draft-ietf-rolc-nhrp- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'KPCL95' -- No information found for draft-ietf-ipngwg-discovery- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'NN95' -- No information found for draft-ietf-addrconf-ipv6-auto- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'TN95' Summary: 17 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Randall Atkinson 2 Internet Draft cisco Systems 3 draft-ahl-ipv6-nbma-00.txt Dimitry Haskin 4 Bay Networks 5 James Luciani 6 Ascom Nexion 7 15 February 1996 9 IPv6 over NBMA Networks 11 STATUS OF THIS MEMO 13 This document is an Internet Draft. Internet Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, and its 15 working groups. Note that other groups may also distribute working 16 documents as Internet Drafts. 18 Internet Drafts are draft documents valid for a maximum of 6 months. 19 Internet Drafts may be updated, replaced, or obsoleted by other documents 20 at any time. It is not appropriate to use Internet Drafts as reference 21 material or to cite them other than as "work in progress". 23 To learn the current status of any Internet Draft, please check the 24 "1id-abstracts.txt" listing contained in the Internet Drafts Shadow 25 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au 26 (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West 27 Coast). 29 This draft is being proposed to the IETF Routing over Large Clouds and 30 IETF IP:next generation working groups for consideration as a 31 standards-track document. Editorial corrections should be sent to the 32 author. Because of the cross-technology aspect of this draft, comments on 33 this draft should be sent cross-posted to both the IPng mailing list 34 and also the Routing Over Large Clouds (ROLC) 35 mailing list . 37 ABSTRACT 39 This draft proposes an approach to IPv6 over Non-Broadcast Multiple 40 Access (NBMA) technologies that maximises reuse of existing technology and 41 should work equally well over Frame Relay, ATM, and other NBMA technologies. 43 1. INTRODUCTION 44 Traditional IPv6 Neighbor Discovery [NN95] and Address 45 Autoconfiguration [TN95] were designed for use over subnetworks where 46 the underlying media has a native broadcast capability. By 47 definition, NBMA subnetworks lack a native broadcast capability, but 48 are capable of concurrent connections to different nodes on a single 49 NBMA logical link. 51 The NBMA Next Hop Resolution Protocol (NHRP) has been 52 developed within the IETF to provide link-layer address resolution 53 capability over NBMA logical links in a network-layer independent 54 manner. In addition, NHRP may provide an important function of 55 dynamically discovering and resolving the address of the closest 56 egress router to the node associated with a target address outside 57 the NBMA portion of the network. 59 This document proposes an approach to handling IPv6 over NBMA 60 media that relies on use of NHRP to provide IPv6 Neighbor Discovery 61 and IPv6 Address Autoconfiguration support. While some ICMPv6 62 messages originally defined for traditional IPv6 Neighbor Discovery 63 [NN95] are reused for NBMA logical links, the general IPv6 Neighbor 64 Discovery process of that specification is not reused because NBMA 65 environments were outside the intended design scope of that protocol. 66 In addition, this document proposed the use of 6 octet interface 67 tokens [TN95], which are used in conjunction with IPv6 address 68 prefixes to autoconfigure IPv6 addresses. Longer interface tokens 69 are avoided to reduce the amount of IPv6 address space wasted by the 70 interface token. 72 1.1. TERMINOLOGY 74 The acronym "NBMA" expands to "Non-Broadcast, Multiple Access" and 75 refers to networking technologies that lack a native broadcast 76 facility. Examples of NBMA technologies include ATM, SMDS, Frame 77 Relay, and ISDN. 79 NBMA interfaces are considered to be attached to the same NBMA 80 logical link if these interfaces are administratively configured to 81 receive Router Advertisements from the same set of routers and 82 therefore share the same set of routing prefixes. 84 The terms "subnet" and "subnetwork" in this document refer to the 85 set of nodes connected to the same NBMA logical link (as defined just 86 above). 88 The term "MARS" refers to the proposal for "Multicast Address 89 Resolution Servers" for use with IP multicasting over ATM. 91 The term "interface token" refers to an interface-specific token, 92 usually 6 octets long, that can be used in conjunction with an IPv6 93 address prefix to autoconfigure an IPv6 address as part of IPv6 94 stateless autoconfiguration. 96 In this document, the words that are used to define the 97 significance of each particular requirement are usually capitalised. 98 These words are: 100 - MUST 102 This word or the adjective "REQUIRED" means that the item is an 103 absolute requirement of the specification. 105 - SHOULD 107 This word or the adjective "RECOMMENDED" means that there might 108 exist valid reasons in particular circumstances to ignore this item, 109 but the full implications should be understood and the case carefully 110 weighed before taking a different course. 112 - MAY 114 This word or the adjective "OPTIONAL" means that this item is truly 115 optional. One vendor might choose to include the item because a 116 particular marketplace requires it or because it enhances the 117 product, for example; another vendor may omit the same item. 119 2. FORMING AN IPV6 INTERFACE TOKEN 121 The IPv6 interface token is used when auto-configuring an IPv6 122 address on a network interface. IPv6 addresses are bound to logical 123 network interfaces rather than being bound to nodes. [DH96] There are 124 three cases to consider. The first case is when an IEEE 802 MAC 125 address is on an interface. The second case is when an IEEE 802 MAC 126 address is not available but an E.164, X.121, or ATM Forum NSAP-like 127 address is available to an interface. The last case handles 128 situations where none of those three address types is available or 129 when duplicate addresses have been detected. This specification 130 handles all three cases. 132 2.1 Interface Tokens based on IEEE 802 MAC Addresses 134 Interfaces having an IEEE 802 MAC address embedded into them MUST 135 use that IEEE 802 MAC address as the interface token for their auto- 136 configured IPv6 addresses on the first logical interface of that 137 physical interface. 139 When multiple logical interfaces exist on a single physical 140 interface and those logical interfaces share a common NBMA logical 141 link, then the 2nd and later logical interface's interface tokens MAY 142 be formed by the method described below in "Interface Tokens for 143 other cases". 145 Should Duplicate Address Detection (see below) or other information 146 indicate that the autoconfigured address is duplicate with another 147 node on the same NBMA logical link, then the node MUST NOT use that 148 address. In this case, the node SHOULD generate an address using the 149 method described below for "Address Tokens for Other Cases" available 150 to them. 152 In any event, the interface token for the IPv6 address SHOULD NOT 153 exceed 6 bytes in length. This restriction is placed to ensure that 154 sufficient IPv6 address space will remain available to facilitate 155 hierarchical routing. 157 2.2 Interface Tokens based on E.164, X.121, or NSAP-like addresses 158 If no IEEE 802 MAC address is available but an E.164 address 159 is available, then the IPv6 interface token SHOULD be formed from the 160 E.164 address as follows. The 12 right-most digits of the E.164 161 address are encoded in Binary Coded Decimal (BCD) syntax to form a 6 162 octet IPv6 address token. If the E.164 number has less than 12 163 digits, then the BCD encoded value is padded with leading semi-octet 164 0000 to obtain the 6-octet IPv6 interface token. 166 If no IEEE 802 MAC address is available, but an X.121 address 167 is available, then the IPv6 interface token SHOULD be formed from the 168 X.121 address as follows. The 12 right-most decimal digits of the 169 X.121 number are encoded in Binary Coded Decimal (BCD) syntax to form 170 a 6 octet IPv6 address token. If the X.121 number has less than 12 171 digits, then the BCD encoded value is padded with leading semi-octet 172 0000 to obtain the 6-octet IPv6 interface token. 174 If no IEEE 802 MAC address is available, but an ATM Forum 175 NSAP-like address is available, then the IPv6 interface token SHOULD 176 be the 6 octet ESI field of the ATM Forum address. 178 2.3 Address Tokens for Other Cases 179 Many believe that manual configuration of interface tokens is 180 the only reasonable choice for interfaces lacking an on-board MAC 181 address. One argument for this is the desire to retain the same 182 interface token across cold reboots of nodes. 184 If neither an IEEE 802 MAC address, nor an E.164 address, nor 185 an X.121 address, nor an ATM Forum NSAP-like address is available to 186 use in forming an IPv6 interface token, then manual configuration MAY 187 be used to form the IPv6 interface token for autoconfiguration. 188 Users are encouraged to use stateful configuration (e.g. DHCP for 189 IPv6) instead of stateless autoconfiguration to handle such cases. 191 Implementations MUST permit a system administrator to 192 manually configure an interface token for each NBMA interface that 193 lacks an on-board IEEE 802 MAC address. The use of stateful 194 autoconfiguration or manual configuration will ensure that address 195 token collisions do not occur. 197 Alternately, an extension could be added to the NHRP protocol 198 which would cause an unused address (for example, an IPv6 link-local 199 address) to be supplied from a range of specified addresses. This 200 extension would be included in an NHRP Registration Request message 201 from a client to the NHS. When the extension were included in an 202 NHRP Registration Request, an unused address would be allocated from 203 within the range of specified addresses only if the address being 204 registered has already been registered with the "uniqueness" 205 qualifier (c.f. the "Duplicate Address Detection" section of this 206 draft). In this case, the NHRP Registration Reply would still 207 contain a NAK,but the extension will include an acceptable IPv6 208 address that would then be registered using a subsequent NHRP 209 Registration Request. This approach is for further study. 211 2.4 Duplicate Address Detection 213 Duplicate Address Detection is performed with a minor 214 enhancement to the NHRP protocol. The NHRP client indicates whether 215 the upper-layer destination address in the NHRP request is to be 216 treated with the "uniqueness" qualifier. To do this, a bit is added 217 to the Mandatory part of the appropriate NHRP messages. When set, 218 this bit indicates that a registration of this upper-layer to NBMA 219 address binding is unique. This "uniqueness" bit MUST be stored in 220 the NHS/NHC cache for the given entry. 222 Any attempt to register a binding between the upper-layer 223 address and an NBMA address when this bit is set MUST be rejected 224 with a new NAK code of "Internetworking Layer Address Already 225 Registered" if an existing binding with the "uniqueness" bit set 226 already exists in the NHS cache. Further, if this bit is set in an 227 NHRP Resolution Request and multiple entries exist in the NHS cache, 228 then only the Next Hop Entry with this bit set will be returned. 229 Note that even if this bit was set at registration time, there can 230 still be multiple Next Hop Entries that might fulfill the NHRP 231 Resolution Request because an entire subnet can be registered through 232 use of the Prefix Length extension and the address of interest might 233 be within such a subnet. If the "uniqueness" bit is set in a NHRP 234 Resolution Request and the responding NHS has one or more cache 235 entries which match the request but do not have the "uniqueness" bit 236 set, then the NHRP Resolution Reply has the "P" bit set to zero and 237 no Next Hop Entry is included. If a client wishes to receive non- 238 unique Next Hop Entries, then the client must have the "uniqueness" 239 bit set to zero in its NHRP Resolution Request. It is suggested that 240 NHRP adopt a NAK code for NHRP Resolution Replies so that a reason 241 can be given for a failed NHRP Resolution Reply. 243 3. NEIGHBOR ADDRESS RESOLUTION 245 The NBMA Next-Hop Resolution Protocol (NHRP) defined in 246 [KPCL95] is used to locate the lower-layer address for a given IPv6 247 destination reached via an NBMA interface. This maximises technology 248 reuse since NHRP is an existing technology that is designed to 249 support multiple upper-layer protocols over NBMA networks. 251 The processes for initial bootstrapping, neighbor discovery, 252 and redirect handling are outlined below so that the relationship and 253 sequencing between the IPv6 Discovery messages and the NHRP messages 254 is clear. 256 None of the procedures in this section assume or imply that 257 the NHS is acting as a MARS. 259 3.1 Host Bootstrap Processing 260 The initial VC to the NHS could be created using information 261 manually configured into the node or using some kind of media- 262 specific group address (e.g. as has been proposed for the ATM UNI) 264 Initially, the host creates link-local IPv6 addresses using 265 the above procedures to generate the local-identification token of 266 the link-local address. The host registers this link-local IPv6 267 address with its NHS by sending its link-local IPv6 address and its 268 corresponding lower-layer NBMA address in an NHRP Registration 269 Request message containing a Responder Address Extension to the NHS. 270 The NHS then processes this message and sends an appropriate NHRP 271 Registration Reply and includes its unicast address in the extension. 272 If the registration is successful, then the NHS reply will have a NAK 273 code of zero. Otherwise, the NHS reply will indicate why the 274 registration failed. 276 The host has now registered its link-local IPv6 address with 277 the NHS. 279 The host then sends an NHRP Resolution Request containing the 280 host's link-local address as the IPv6 Source Address and the link- 281 local all-routers multicast address as the IPv6 Destination Address 282 to the Next-Hop Server (NHS). The NHS will respond with an NHRP 283 Resolution Reply containing all of the cached bindings between the 284 link-local all-routers multicast IPv6 address and corresponding 285 lower-layer NBMA addresses. 287 The host now knows the lower-layer NBMA address(es) for the 288 IPv6 router(s) on its NBMA logical link. 290 If the NHS is also the IPv6 router for the host's NBMA 291 logical link, then the router SHOULD immediately send a unicast IPv6 292 Router Advertisement to the requesting host. 294 If no IPv6 Router Advertisement is received, the host SHOULD 295 send an IPv6 Router Solicitation message to each known IPv6 router 296 for its NBMA logical link. Those routers will in turn send a unicast 297 IPv6 Router Advertisement back to the requesting host. The IPv6 298 Router Solicitation message MUST be sent as a unicast lower-layer 299 message though it MAY contain the link-local scope all-routers 300 multicast address as the IPv6 Destination Address. Routers SHOULD use 301 the IP Authentication Header to authenticate IPv6 Router 302 Advertisement messages whenever the router has an appropriate IP 303 Security Association with the destination node for the IPv6 Router 304 Advertisement. 306 At this point, the host knows the unicast IPv6 address(es) of 307 its router(s), the lower-layer address of its router(s), its routing 308 prefix(es), and whether it needs to perform stateful IPv6 309 configuration. 311 If stateless IPv6 autoconfiguration was indicated by the 312 received Router Advertisement(s), the host now configures its global 313 IPv6 address(es) as described in [TN95] and uses the NHRP 314 Registration Request to register its global IPv6 address(es) with the 315 NHS. 317 If stateful autoconfiguration was indicated in the IPv6 318 Router Advertisement, then the host MUST follow the stateful 319 configuration procedure described in [DHCPv6], using NHRP as 320 necessary to obtain lower- layer addresses for IPv6 addresses. Once 321 its global IPv6 address(es) is (are) configured, the node uses the 322 NHRP Registration Request message to register those addresses with 323 the NHS. 325 3.2 Ongoing Host Processing 327 The NHRP client resolves anycast addresses using the NHRP 328 Resolution Request message to the NHS, taking care to indicate that 329 the target IPv6 address is an anycast address. When NHRP is used to 330 resolve an IPv6 Anycast address, the NHRP "Additional Next Hop 331 Entries Extension" will be included with the NHRP Resolution Reply if 332 more than one IPv6 node has registered that IPv6 Anycast address with 333 the NHS. 335 The host MAY establish and maintain connections with all 336 routers for the purpose of sending Router Solicits and receiving 337 Router Advertisements if it wishes to. If it does not do this, then 338 the host SHOULD periodically establish/remove connections to handle 339 periodic transmission of IPv6 Router Solicit messages and reception 340 of corresponding IPv6 Router Advertisement messages. 342 The interval between IPv6 Router Solicit messages determines 343 how quickly a host can react to changes in the IPv6 routing prefix. 344 It is recommended that the default interval between IPv6 Router 345 Solicit messages be no smaller than the minimum time between 346 unsolicited IPv6 Router Advertisements (i.e. 3 seconds). 348 [NOTE: The authors are interested in finding out from the WG what the WG 349 believes the default interval between RS messages should be. One 350 alternative value might be 10 minutes. Perhaps this value should be 351 derived in part from one of the advertisement lifetimes carried in IPv6 352 Router Advertisement messages.] 354 3.3 Router Bootstrap Processing 356 Initially, the router creates link-local IPv6 addresses using 357 the above procedures to generate the local-identification token of 358 the link-local address. Then the router configures the globally 359 routable IPv6 addresses on those interfaces supporting IPv6 routing. 360 Because it is a router, it already knows its global routing prefixes. 362 The router then uses the NHRP Registration Request message(s) 363 to register each of its globally routable addresses with the NHS. In 364 the absence of a standards-track NHS synchronisation method, the 365 router SHOULD register its IPv6 addresses for a given NBMA logical 366 link with each known NHS for that NBMA logical link. The router MUST 367 NOT register an IPv6 address belonging to one NBMA logical link with 368 the NHS for a different NBMA logical link. 370 Then, the router registers each IPv6 interface's lower-layer 371 NBMA address and the IPv6 link-local all-routers multicast address 372 with each appropriate NHS, taking care that the "uniqueness" bit is 373 NOT set in in the NHRP Registration Request message. As above, the 374 router MUST NOT register an interface's (lower-layer address, IPv6 375 link-local all-routers multicast address) pair with an NHS that does 376 not serve that interface's NBMA logical link. 378 If the IPv6 router is its own NHS and there is no other NHS 380 for any of the attached NBMA logical links, then the above procedure 381 can be internalised. If the IPv6 router is its own NHS and other 382 NHSs exist for one or more of the attached NBMA logical links, then 383 the above procedure needs to be followed only for the non-internal 384 NHSs. 386 3.4 Neighbor Address Discovery 388 Once bootstrapped using the above procedure, the host MUST 389 use the NHRP Resolution Request and NHRP Resolution Response messages 390 to obtain the lower layer address corresponding to any IPv6 unicast 391 address not already having a lower-layer address known to the host. 392 In the case where the target IPv6 address is associated with a node 393 not on the attached NBMA network, NHRP will respond with the lower- 394 layer NBMA address of the closest egress router to the node 395 associated with the target IPv6 address. Thus, short-cut routing is 396 automatically provided to IPv6 nodes connected via NBMA. 398 3.5 Redirects 399 The ICMP Redirect messages defined for traditional IPv6 400 Neighbor Discovery are also used over NBMA networks.[NN95] 402 Routers on NBMA networks MAY include the Target Link-Layer 403 Address option in the ICMPv6 Redirect message if that target link- 404 layer address is known. Routers MUST limit the rate at which ICMPv6 405 Redirect messages are sent, as is detailed in [CD96]. Routers SHOULD 406 use the IPv6 Authentication Header or IPv6 Encapsulating Security 407 Payload to authenticate ICMPv6 Redirect messages whenever an 408 appropriate IP Security Association exists for the destination of 409 such a message. 411 Hosts on NBMA networks that receive a ICMPv6 Redirect message 412 not containing a Target Link-Layer Address option via an NBMA 413 interface MUST then use the NHRP Resolution Request procedure to 414 determine the appropriate lower-layer address to use for the 415 redirected IPv6 address. Nodes MAY ignore unauthenticated ICMPv6 416 Redirect messages. 418 3.6 Neighbor Unreachability Detection (NUD) 420 Although the IPv6 Neighbor Solicit and Neighbor Advertisement 421 messages are replaced by NHRP messages for the purpose of determining 422 the lower-layer address of neighbors, the Neighbor Solicit and 423 Neighbor Advertisement messages are retained for use in Neighbor 424 Unreachability Detection. 426 If the IPv6 Neighbor Solicit and Neighbor Advertisement 427 exchanges indicate that a remote node has become unreachable, then 428 the other node SHOULD send a NHRP Resolution Request message to 429 attempt to determine the current reachability of the remote node. 431 Over NBMA networks, the Neighbor Solicit and Neighbor 432 Advertisement messages are always unicast and they are only used for 433 the purpose of Neighbor Unreachability Detection after the existence 434 of the neighbor was established via NHRP. The Source Link-layer 435 Address Option MAY be used with Neighbor Solicit or Neighbor 436 Advertisement messages over NBMA networks, however NHRP MUST be used 437 for initial determination of lower-layer addresses except for the 438 case of a received ICMPv6 Redirect containing a Target Link-Layer 439 Address Option or for the case where manual configuration is supplied 440 (e.g. an administratively configured host route). Neighbor Solicit 441 and Neighbor Advertisement messages sent over NBMA networks MUST NOT 442 contain either the unspecified address or a multicast address. 444 Receipt of NHRP messages is considered reachability 445 confirmation for the node whose IP address is associated with that 446 lower-layer address. Otherwise, the process described in Sections 447 7.2.3, 7.2.4, 7.2.5, and 7.3 of [NN95] is followed. 449 The NHRP Purge Request message is used to invalidate cached 450 IPv6 to lower-layer NBMA address bindings in IPv6 nodes connected to 451 the NBMA network.[KPCL95] Hence, the conceptual IPv6 "Neighbor Cache" 452 entry corresponding to the address in the NHRP Purge Request message 453 MUST be deleted (in an implementation-dependent way) by an IPv6 node 454 that receives a valid NHRP Purge Request message for an IPv6 address. 455 The conceptual IPv6 "Default Router List" entry corresponding to the 456 address in the NHRP Purge Request message MUST be deleted (in an 457 implementation-dependent way) by an IPv6 node that receives a valid 458 NHRP Purge Request message for an IPv6 address that is known to be a 459 router. Unsolicited Neighbor Advertisements are NOT sent over NBMA 460 networks and section 7.2.6 of [NN95] does not apply to NBMA networks. 461 Upon receipt of a valid NHRP Purge Request, a NHRP Purge Reply 462 message MUST be sent unless the NHRP Purge Request explicitly 463 indicates that it does not require a reply. [KPCL95] 465 4. LOWER-LAYER ENCAPSULATIONS 467 The encapsulation method standardised in RFC-1483 shall be 468 used for IPv6 traffic carried over ATM Adaptation Layer 5 (AAL 469 5).[Hei93] The encapsulation method standardised in RFC-1490 shall 470 be used for IPv6 traffic carried over Frame Relay. [BBM93] The 471 encapsulation method standardised in RFC-1356 shall be used for IPv6 472 traffic carried over X.25 and ISDN in the Packet Mode. [MRU92] The 473 encapsulation method standardised in RFC-1209 shall be used for IPv6 474 traffic carried over SMDS.[PL91] NHRP traffic will always be 475 encapsulated as described in [KPLC95]. 477 In all of these cases, the SNAP NLPID encapsulation with the 478 IPv6 EtherType (namely, 86DD hexadecimal) is used instead of using 479 the IPv4 NLPID or SNAP NLPID with the IPv4 EtherType. This reduces 480 the dependence on the IP version numbers, which is important because 481 some historical IPv4 implementations have not dependably checked the 482 version numbers of the packets. This will also add consistency to 483 the IPv6 encapsulation methods used on the various NBMA media. 485 On a virtual circuit carrying only IPv6, the IPv6 packets MAY 486 be sent without a lower layer encapsulation (e.g. RFC-1483 VC-based 487 multiplexing) provided that all nodes on that virtual circuit are 488 configured to only send IPv6 over that virtual circuit.[Hei93] 490 5. CONFORMANCE REQUIREMENTS 491 The term "conforming implementation" is defined to have the 492 same meaning as "compliant implementation" for this specification. 494 A conforming implementation of this specification MUST 495 implement and comply with the Next-Hop Resolution Protocol (NHRP) as 496 specified in [KPCL95], the Neighbor Discovery for IPv6 as specified 497 in [NN95] except for the Neighbor Solicit and Neighbor Advertisement 498 messages, the IPv6 Address Configuration as specified in [TN95] 499 except as noted in this specification, and MUST follow the procedures 500 and processes outlined in this document. In cases where one process 501 is outlined in this document and a different conflicting process is 502 outlined in [NN95] and/or [TN95], then the process described here is 503 used over NBMA networks instead of the process described in those 504 other documents. 506 All conforming implementations of this specification MUST 507 also implement the IP Security Architecture [Atk95a] and the IP 508 Authentication Header [Atk95b] so that users are able to use 509 cryptographic authentication. All conforming implementations SHOULD 510 also implement the Internet Key Management Protocol (IKMP) once that 511 has been published as a standards-track RFC. 513 All conforming implementations of this specification MUST use 514 the IP Authentication Header [Atk95b] to authenticate IPv6 Neighbor 515 Discovery messages when an appropriate IPsec Security Association 516 [Atk95a] exists. 518 All conforming implementations of this specification MUST use 519 the NHRP Authentication Extension to authenticate NHRP messages when 520 an appropriate NHRP Security Association exists.[KPCL95] NHRP 521 Security Associations based on MD5 MUST be preferred to NHRP Security 522 Associations based on Cleartext Passwords in all conforming 523 implementations. 525 SECURITY CONSIDERATIONS 527 Unlike traditional IPv6 Neighbor Discovery, NHRP is not built 528 upon IP. This design decision was made so that NHRP can be used for 529 multi-protocol networks and is not limited to IPv4 or IPv6 networks. 530 Although this precludes the use of IP security mechanisms [Atk95a] 531 [Atk95b] to authenticate NHRP, this is not a decrease in security 532 relative to traditional IPv6 Neighbor Discovery because NHRP includes 533 its own cryptographic authentication mechanism (NHRP's Authentication 534 Type = 2) having similar security properties. 536 Acceptance of unauthenticated NHRP response messages can lead 537 to denial of service attacks. Use of the IP Authentication Header 538 for IPv6 traffic can preclude IP-layer host masquerading attacks that 539 would otherwise be possible if a node accepted unauthenticated NHRP 540 response messages. 542 Acceptance of unauthenticated ICMPv6 Neighbor Discovery 543 messages can lead to various attacks. Use of the IP Authentication 544 Header can preclude or significantly mitigate many of these attacks. 546 Security issues specific to IP Security are discussed in 547 [Atk95a] and [Atk95b]. Security issues specific to NHRP are discussed 548 in [KPCL95]. Security issues specific to traditional IPv6 Neighbor 549 Discovery are discussed in [NN95]. The reader is encouraged to read 550 all of these for more information on security issues relating to this 551 specification. 553 ACKNOWLEDGEMENTS 555 This document is largely based on the existing technology cited in 556 the references. The author is obliged to the contributers to those 557 drafts for helping to create that technology. 558 The author wishes to thank (in alphabetical order) Bruce Cole, 559 Francis Dupont, Bob Gilligan, Joel Halpern, Andy Malis, and Erik 560 Nordmark for their review and critique of an earlier version of this 561 draft. 563 REFERENCES 564 [Atk95a] Randall J. Atkinson, IP Security Architecture, RFC-1825, 565 August 1995. 567 [Atk95b] Randall J. Atkinson, IP Authentication Header, RFC-1826, 568 August 1995. 570 [BBM93] Terry Bradley, Caralyn Brown, & Andy Malis, "Multiprotocol 571 Interconnect over Frame Relay", RFC-1490, July 1993. 573 [CD96] Alex Conta & Steve Deering, "Internet Control Message Protocol 574 for IPv6 (ICMPv6)", RFC-1885, January 1996. 576 [DH96] Steve Deering & Robert Hinden, "Internet Protocol, version 6 577 Specification", RFC-1883, January 1996. 579 [Hei93] Juha Heinanen, "Multiprotocol Encapsulation over ATM AAL 5", 580 RFC-1483, July 1993. 582 [KPCL95] Dave Katz, David Piscitello, Bruce Cole, & James V. Luciani, 583 "NBMA Next Hop Resolution Protocol (NHRP)", Work in Progress, 584 draft-ietf-rolc-nhrp-*.txt, December 1995. 586 [MRU92] Andy Malis, David Robinson, & Robert Ullman, "Multiprotocol 587 Interconnect on X.25 and ISDN in the Packet Mode", RFC-1356, 588 August 1992. 590 [NN95] Thomas Narten & Erik Nordmark, "Neighbor Discovery for IPv6", 591 work in progress, draft-ietf-ipngwg-discovery-*.txt, November 1995. 593 [PL91] Dave Piscitello & Joseph Lawrence, "The Transmission of IP 594 Datagrams over the SMDS Service.", RFC-1209, March 1991. 596 [TN95] Susan Thomson & Thomas Narten, "IPv6 Stateless Address 597 Autoconfiguration", draft-ietf-addrconf-ipv6-auto-*.txt, 598 December 1995. 600 DISCLAIMER 602 The views and specifications here are those of the authors and are not 603 necessarily those of their employers. 605 AUTHOR INFORMATION 607 Randall Atkinson 608 cisco Systems 609 170 West Tasman Drive 610 San Jose, CA 95134-1706 611 USA 613 Telephone: +1 (408) 526-6566 615 Dimitry Haskin 616 Bay Networks 617 2 Federal Street 618 Billerica, MA 01821 620 Telephone: +1 (508) 436-8124 622 James V. Luciani 623 Ascom Nexion 624 289 Great Road 625 Acton, MA 01720-4379 626 USA 628 Telephone: +1 (508) 266-3450