idnits 2.17.1 draft-ietf-ion-ipv6-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-26) 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 38 longer pages, the longest (page 1) being 62 lines 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.) ** There are 117 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** 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 182: '...ations and link token generation SHALL...' RFC 2119 keyword, line 184: '... They SHALL conform to the following...' RFC 2119 keyword, line 186: '...ast IPv6 packets SHALL be transmitted ...' RFC 2119 keyword, line 189: '...ns for PVC links SHALL be constructed ...' RFC 2119 keyword, line 198: '...panion documents MAY additionally spec...' (86 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1241 has weird spacing: '...scribed in th...' == Line 1245 has weird spacing: '...ecurity seman...' == Line 1246 has weird spacing: '...nses to solic...' == Line 1248 has weird spacing: '...scovery since...' == Line 1250 has weird spacing: '...rent to the n...' == (112 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 section? '17' on line 1235 looks like a reference -- Missing reference section? '14' on line 1225 looks like a reference -- Missing reference section? '13' on line 1221 looks like a reference -- Missing reference section? '3' on line 1190 looks like a reference -- Missing reference section? '8' on line 1205 looks like a reference -- Missing reference section? '7' on line 1884 looks like a reference -- Missing reference section? '5' on line 1729 looks like a reference -- Missing reference section? '16' on line 1232 looks like a reference -- Missing reference section? '11' on line 1214 looks like a reference -- Missing reference section? '12' on line 1217 looks like a reference -- Missing reference section? '0xAA-AA-03' on line 873 looks like a reference -- Missing reference section? '0x00-00-00' on line 839 looks like a reference -- Missing reference section? '0x86-DD' on line 839 looks like a reference -- Missing reference section? '0x00-00-5E' on line 873 looks like a reference -- Missing reference section? '0x00-01' on line 873 looks like a reference -- Missing reference section? '0x86DD' on line 873 looks like a reference -- Missing reference section? '10' on line 1211 looks like a reference -- Missing reference section? 'Type' on line 1071 looks like a reference -- Missing reference section? 'Length' on line 1077 looks like a reference -- Missing reference section? 'NTL' on line 1096 looks like a reference -- Missing reference section? 'STL' on line 1096 looks like a reference -- Missing reference section? '1' on line 1183 looks like a reference -- Missing reference section? '2' on line 1186 looks like a reference -- Missing reference section? '4' on line 1193 looks like a reference -- Missing reference section? '6' on line 1199 looks like a reference -- Missing reference section? '9' on line 1575 looks like a reference -- Missing reference section? '15' on line 1229 looks like a reference -- Missing reference section? 'IPV6-DHCP' on line 1588 looks like a reference -- Missing reference section? 'IPV6-ADDRCONF' on line 1558 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 8 warnings (==), 31 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft Grenville Armitage 3 Lucent Technologies 4 Peter Schulter 5 Bright Tiger Technologies 6 Markus Jork, Geraldine Harter 7 Digital 8 October 11th, 1997 10 IPv6 over Non-Broadcast Multiple Access (NBMA) networks 11 13 Status of this Memo 15 This document was submitted to the IETF Internetworking over NBMA 16 (ION) WG. Publication of this document does not imply acceptance by 17 the ION WG of any ideas expressed within. Comments should be 18 submitted to the ion@nexen.com mailing list. 20 Distribution of this memo is unlimited. 22 This memo is an internet draft. Internet Drafts are working documents 23 of the Internet Engineering Task Force (IETF), its Areas, and its 24 Working Groups. Note that other groups may also distribute working 25 documents as Internet Drafts. 27 Internet Drafts are draft documents valid for a maximum of six 28 months. Internet Drafts may be updated, replaced, or obsoleted by 29 other documents at any time. It is not appropriate to use Internet 30 Drafts as reference material or to cite them other than as a "working 31 draft" or "work in progress". 33 To learn the current status of any Internet-Draft, please check the 34 "lid-abstracts.txt" listing contained in the Internet-Drafts shadow 35 directories on ds.internic.net (US East Coast), nic.nordu.net 36 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 37 Rim). 39 Abstract 41 This document describes a general architecture for IPv6 over NBMA 42 networks. It forms the basis for subsidiary companion documents that 43 describe details for various specific NBMA technologies (such as ATM 44 or Frame Relay). The IPv6 over NBMA architecture allows conventional 45 host-side operation of the IPv6 Neighbor Discovery protocol, while 46 also supporting the establishment of 'shortcut' NBMA forwarding paths 47 when dynamically signaled NBMA links are available. Operations over 48 administratively configured Point to Point NBMA links are also 49 described. 51 Dynamic NBMA shortcuts are achieved through the use of IPv6 Neighbor 52 Discovery protocol operation within Logical Links, and inter-router 53 NHRP for the discovery of off-Link NBMA destinations. Both flow- 54 triggered and explicitly source-triggered shortcuts are supported. 56 Revision History 58 September 1997, split draft-ietf-ion-tn-01.txt apart to make 59 separate the NBMA-generic parts of the architecture from the 60 ATM-specific details document. New name of this document: 61 draft-ietf-ion-ipv6-00.txt, new name of ATM-specific details: 62 draft-ietf-ion-ipv6-atm-00.txt. Added explicit details for 63 NBMA networks used in pt2pt NBMA mode. Companion docs for IPv6 64 over NBMA are expected to add FR, etc, support. 66 June 1997, version 01 as an official ION working group work item. 67 Host tokens now generated to look like EUI-64 addresses. 68 Updated "on-link" definitions to match current ND spec. 70 March 1997, version 00 (again) as an official ION working group 71 work item. Augmented MARS now required, add SVC signalling 72 procedures, host token, and other issues raised at December 73 1996 IETF and on the ION mailing list. Name changed to draft- 74 ietf-ion-tn-00.txt. 76 October 1996, version 01 under ION working group. 77 Significantly expanded description of IPv6 Neighbor Discovery, 78 DHCPv6, IGMPv6 protocol operation (based on IPv6 specific 79 material from draft-ietf-ion-ipv6atm-framework-00.txt). New 80 authors added. 82 June 1996, version 00 (again) 83 Reissued under the ION working group. No substantive changes. 84 Prelude to June 1996 IETF. Name changed to draft-armitage- 85 ion-tn-00.txt 87 April 1996, version 00 under IP-ATM working group. 88 Documents and expands on an informal presentation at the March 89 1996 IETF. 91 1. Introduction. 93 Non Broadcast Multiple Access (NBMA) networks may be utilized in a 94 variety of ways. At one extreme, they can be used to simply provide 95 administratively configurable point to point service, sufficient to 96 interconnect IPv6 routers (and even IPv6 hosts, in certain 97 situations). At the other extreme, NBMA networks that support dynamic 98 establishment and teardown of Virtual Circuits (or functional 99 equivalents) may be used to emulate the service provided to the IPv6 100 layer by conventional broadcast media such as Ethernet. Typically 101 this emulation requires complex convergence protocols, particularly 102 to support IPv6 multicast. 104 This document describes a general architecture for IPv6 over NBMA 105 networks. It forms the basis for companion documents that provide 106 details specific to various NBMA technologies (for example, ATM [17] 107 or Frame Relay). The IPv6 over NBMA architecture allows conventional 108 host-side operation of the IPv6 Neighbor Discovery protocol, while 109 also supporting the establishment of 'shortcut' NBMA forwarding paths 110 (when dynamically signaled NBMA links are available). 112 The majority of this document focusses on the use of dynamically 113 managed point to point and point to multipoint calls between 114 interfaces on an NBMA network. These will be generically refered to 115 as "SVCs" in the rest of the document. The use of administratively 116 configured point to point calls will also be discussed. Such calls 117 will be generically refered to as "PVCs". Depending on context, 118 either may be shortened to "VC". 120 Certain NBMA networks may provide a form of connectionless service 121 (e.g. SMDS). In these cases, a "call" or "VC" shall be considered to 122 implicitly exist if the sender has an NBMA destination address to 123 which it can transmit packets whenever it desires. 125 1.1 Neighbor Discovery. 127 A key difference between this architecture and previous IP over NBMA 128 protocols is its mechanism for supporting IPv6 Neighbor Discovery. 130 The IPv4 world evolved an approach to address resolution that 131 depended on the operation of an auxiliary protocol operating at the 132 'link layer' - starting with Ethernet ARP (RFC 826 [14]). In the 133 world of NBMA (Non Broadcast, Multiple Access) networks ARP has been 134 applied to IPv4 over SMDS (RFC 1209 [13]) and IPv4 over ATM (RFC1577 135 [3]). More recently the ION working group has developed NHRP (Next 136 Hop Resolution Protocol [8]), a general protocol for performing 137 intra-subnet and inter-subnet address resolution applicable to a 138 range of NBMA network technologies. 140 IPv6 developers opted to migrate away from a link layer specific 141 approach, chosing to combine a number of tasks into a protocol known 142 as Neighbor Discovery [7], intended to be non-specific across a 143 number of link layer technologies. A key assumption made by Neighbor 144 Discovery's actual protocol is that the link technology underlying a 145 given IP interface is capable of native multicasting. This is not 146 particularly true of most NBMA network services, and usually requires 147 convergence protocols to emulate the desired service. (The MARS 148 protocol, RFC 2022 [5], is an example of such a convergence 149 protocol.) This document augments and optimizes the MARS protocol for 150 use in support of IPv6 Neighbor Discovery, generalizing the 151 applicability of RFC 2022 beyond ATM networks. 153 1.2 NBMA Shortcuts. 155 A shortcut is an NBMA level call (VC) directly connecting two IP 156 endpoints that are logically separated by one or more routers at the 157 IP level. IPv6 packets traversing this VC are said to 'shortcut' the 158 routers that are in the logical IPv6 path between the VC's endpoints. 160 NBMA shortcuts are a mechanism for minimizing the consumption of 161 resources within an IP over NBMA cloud (e.g. router hops and NBMA 162 VCs). 164 It is important that NBMA shortcuts are supported whenever IP is 165 deployed across NBMA networks capable of supporting dynamic 166 establishment of calls (SVCs or functional equivalent). For IPv6 167 over NBMA, shortcut discovery and management is achieved through a 168 mixture of Neighbor Discovery and NHRP. 170 1.3 Key components of the IPv6 over NBMA architecture. 172 1.3.1 NBMA networks providing PVC support. 174 When the NBMA network is used in PVC mode, each PVC will connect 175 exactly two nodes and the use of Neighbor Discovery and other IPv6 176 features is limited. IPv6/NBMA interfaces have only one neighbor on 177 each Link. The MARS and NHRP protocols are NOT necessary, since 178 multicast and broadcast operations collapse down to an NBMA level 179 unicast operation. Dynamically discovered shortcuts are not 180 supported. 182 The actual details of encapsulations and link token generation SHALL 183 be covered by companion documents covering specific NBMA technology. 184 They SHALL conform to the following guidlines: 186 Both unicast and multicast IPv6 packets SHALL be transmitted over 187 PVC links using the encapsulation described in section 4.4.1. 189 Interface tokens for PVC links SHALL be constructed as described 190 in section 5. Interface tokens need only be unique between the two 191 nodes on the PVC link. 193 This use of PVC links does not mandate, nor does it prohibit the 194 use of extensions to the Neighbor Discovery protocol which may be 195 developed for either general use of for use in PVC connections 196 (for example, Inverse Neighbor Discovery). 198 NBMA-specific companion documents MAY additionally specify the 199 concatenation of IPv6 over PPP and PPP over NBMA mechanisms as an 200 OPTIONAL approach to point to point IPv6. 202 Except where noted above, the remainder of this document focuses on 203 the SVC case. 205 1.3.2 NBMA networks providing SVC support. 207 When the NBMA network is used in SVC mode, the key components are: 209 - The IPv6 Neighbor model, where neighbors are discovered through 210 the use of messages multicast to members of an IPv6 interface's 211 local IPv6 Link. 212 - The MARS model, allowing emulation of general multicast using 213 multipoint calls provided by the underlying NBMA network. 215 - The NHRP service for seeking out the NBMA identities of IP 216 interfaces who are logically distant in an IP topological sense. 217 - The modeling of IP traffic as 'flows', and optionally using the 218 existence of a flow as the basis for attempting to set up a 219 shortcut link level connection. 221 In summary: 223 The IPv6 "Link" is generalised to "Logical Link" (LL) in NBMA 224 environments (analogous to the generalisation of IPv4 IP Subnet to 225 Logical IP Subnet in RFC 1209 and subsequently RFC1577). 227 IPv6/NBMA interfaces utilize RFC 2022 (MARS) for general intra- 228 Logical Link multicasting. The MARS itself is used to optimally 229 distribute discovery messages within the Logical Link. 231 For destinations not currently considered to be Neighbors, a host 232 sends the packets to its default router. 234 When appropriately configured, the egress router from a Logical 235 Link is responsible for detecting the existence of an IP packet 236 flow through it that might benefit from a shortcut connection. 238 While continuing to conventionally forward the flow's packets, 239 the router initiates an NHRP query for the flow's destination 240 IP address. 242 The last router/NHS before the target of the NHRP query 243 ascertains the target interface's preferred NBMA address. 245 The originally querying router then issues a Redirect to the IP 246 source, identifying the flow's destination as a transient 247 Neighbor. 249 Host-initiated triggering of shortcut discovery, regardless of the 250 existence of a packet flow, is also supported through specific 251 Neighbor Solicitations sent to a source host's default router. 253 A number of key advantages are claimed for this approach. These are: 255 The IPv6 stacks on hosts do not implement separate ND protocols 256 for each link layer technology. 258 When the destination of a flow is solicited as a transient 259 neighbor, the returned NBMA address will be the one chosen by the 260 destination when the flow was originally established through hop- 261 by-hop processing. This supports the existing ND ability for IPv6 262 destinations to perform their own dynamic interface load sharing. 264 1.4 Terminology. 266 The bit-pattern or numeric value used to identify a particular NBMA 267 interface at the NBMA level will be referred to as an "NBMA address". 268 (An example would be an ATM End System Address, AESA, when applying 269 this architecture to ATM networks, or an E.164 number when applying 270 this architecture to SMDS networks.) 272 The call that, once established, is used to transfer IP packets from 273 one NBMA interface to another will be referred to as an SVC or PVC 274 depending on whether the call is dynamically established through some 275 signaling mechanism, or administratively established. The specific 276 signaling mechanisms used to establish or tear down an SVC will be 277 defined in the NBMA-specific companion specifications. Certain NBMA 278 networks may provide a form of connectionless service (e.g. SMDS). In 279 these cases, a "call" or "SVC" shall be considered to implicitly 280 exist if the sender has an NBMA destination address to which it can 281 transmit packets whenever it desires. 283 The following terminology is used in the items of specification in 284 this document: 286 o MUST, SHALL, or MANDATORY -- the item is an absolute 287 requirement of the specification. 289 o SHOULD or RECOMMENDED -- the item should generally be followed 290 for all but exceptional circumstances. 292 o MAY or OPTIONAL -- the item is truly optional and may be 293 followed or ignored according to the needs of the implementor. 295 They are to be interpreted as described in RFC 2119 [16]. 297 1.5 Document Structure. 299 The remainder of this document is structured as follows: Section 2 300 explains the generalization of IPv6 Link to "Logical Link" when used 301 over NBMA networks, and introduces the notion of the Transient 302 Neighbor. Section 3 describes the modifications to the MARS protocol 303 for efficient distribution of ND messages within a Logical Link, and 304 the rules and mechanisms for discovering Transient Neighbors. 305 Section 4 covers the basic rules governing IPv6/NBMA interface 306 initialization, packet and control message encapsulations, and rules 307 for SVC management. Section 5 describes the general rules for 308 constructing Interface Tokens, the Link Layer Address Option, and 309 Link Local addresses. Section 6 concludes the normative sections of 310 the document. Appendix A provides some non-normative descriptive 311 text regarding the operation of Ipv6 neighbor discovery. Appendix B 312 describes some sub-optimal solutions for emulating the multicasting 313 of Neighbor Discovery messages around a Logical Link. Appendix C 314 discusses shortcut suppression and briefly reviews the future 315 relationships between flow detection and mapping of flows onto SVCs 316 of differing qualities of service. 318 2. Logical Links, and Transient Neighbors. 320 IPv6 contains a concept of on-link and off-link. Neighbors are those 321 nodes that are considered on-link and whose link-layer addresses may 322 therefore be located using Neighbor Discovery. Borrowing from the 323 terminology definitions in the ND text: 325 on-link - an address that is assigned to a neighbor's interface on 326 a shared link. A host considers an address to be on-link 327 if: 328 - it is covered by one of the link's prefixes, or 329 - a neighboring router specifies the address as the 330 target of a Redirect message, or 331 - a Neighbor Advertisement message is received for the 332 target address, or 333 - a Neighbor Discovery message is received from the 334 address. 336 off-link - the opposite of "on-link"; an address that is not 337 assigned to any interfaces attached to a shared link. 339 Off-link nodes are considered to only be accessible through one of 340 the routers directly attached to the link. 342 The NBMA environment complicates the sense of the word 'link' in much 343 the same way as it complicated the sense of 'subnet' in the IPv4 344 case. For IPv4 this required the definition of the Logical IP Subnet 345 (LIS) - an administratively constructed set of hosts that would share 346 the same routing prefixes (network and subnetwork masks). 348 This document considers the IPv6 analog to be a Logical Link (LL). 350 An LL consists of nodes administratively configured to be 'on 351 link' with respect to each other. 353 The members of an LL are an IPv6 interface's initial set of 354 neighbors, and each interface's Link Local address only needs to 355 be unique amongst this set. 357 It should be noted that whilst members of an LL are IPv6 Neighbors, 358 it is possible for Neighbors to exist that are not, administratively, 359 members of the same LL. 361 Neighbor Discovery events can result in the expansion of an IPv6 362 interface's set of Neighbors. However, this does not change the set 363 of interfaces that make up its LL. This leads to three possible 364 relationships between any two IPv6 interfaces: 366 - On LL, Neighbor. 367 - Off LL, Neighbor. 368 - Off LL, not Neighbor. 370 Off LL Neighbors represent the 'shortcut' connections, where it has 371 been ascertained that direct connectivity at the NBMA level is 372 possible to a target that is not a member of the source's LL. 374 Neighbors discovered through the operation of unsolicited messages, 375 such as Redirects, are termed 'Transient Neighbors'. 377 3. Intra-LL and Inter-LL Discovery. 379 This document makes a distinction between the discovery of neighbors 380 within a Logical Link (intra-LL) and neighbors beyond the LL (inter- 381 LL). The goal is to allow both inter- and intra-LL neighbor discovery 382 to involve no changes to the host-side IPv6 stack for NBMA 383 interfaces. 385 Note that section 1.3.1 applies when the NBMA network is being used 386 to provide only configured point to point (PVC) service. 388 3.1 Intra-LL - ND over emulated multicast. 390 The basic model of ND assumes that a link layer interface will do 391 something meaningful with an ICMPv6 packet sent to a multicast IP 392 destination address. (IPv6 assumes that multicasting is an integral 393 part of the Internet service.) This document assumes multicast 394 support will be provided using the RFC 2022 (MARS) [5] service 395 (generalized for use over other NBMA technologies in addition to 396 ATM). An IPv6 LL maps directly onto an IPv6 MARS Cluster in the same 397 way an IPv4 LIS maps directly onto an IPv4 MARS Cluster. 399 The goal of intra-LL operation is that the IPv6 layer must be able to 400 simply pass multicast ICMPv6 packets down to the IPv6/NBMA driver 401 without any special, NBMA specific processing. The underlying 402 mechanism for distributing Neighbor Discovery and Router Discovery 403 messages then works as expected. 405 Sections 3.1.1 describes the additional functionality that SHALL be 406 required of any MARS used in conformance with this document. 407 Background discussion of these additions is provided in Appendix B. 409 3.1.1 Mandatory augmented MARS and MARS Client behavior. 411 IPv6/NBMA interfaces SHALL register as MARS Cluster members as 412 described in section 4.1, and SHALL send certain classes of outgoing 413 IPv6 packets directly to their local MARS as described in section 414 4.4.2. 416 The MARS itself SHALL then re-transmit these packets according to the 417 following rules: 419 - When the MARS receives an IPv6 packet, it scans the group 420 membership database to find the NBMA addresses of the IPv6 421 destination group's members. 423 - The MARS then checks to see if every group member currently has 424 its pt-pt control VC open to the MARS. If so, the MARS sends a 425 copy of the data packet directly to each group member over the 426 existing pt-pt VCs. 428 - If one or more of the discovered group members do not have an 429 open pt-pt VC to the MARS, or if there are no group members 430 listed, the packet is sent out ClusterControlVC instead. No 431 copies of the packet are sent over the existing (if any) pt-pt 432 VCs. 434 3.2 Inter-LL - Redirects, and their generation. 436 Shortcut connections are justified on the grounds that demanding 437 flows of IP packets may exist between source/destination pairs that 438 are separated by IP routing boundaries. Shortcuts are created between 439 Transient Neighbors. 441 The key to creating transient neighbors is the Redirect message 442 (section 8 [7]). IPv6 allows a router to inform the members of an LL 443 that there is a better 'first hop' to a given destination (section 444 8.2 [7]). The advertisement itself is achieved through a Router 445 Redirect message, which may carry the link layer address of this 446 better hop. 448 A transmitting host only listens to Router Redirects from the router 449 that is currently acting as the default router for the IP destination 450 that the Redirect refers to. If a Redirect arrives that indicates a 451 better first hop for a given destination, and supplies a link layer 452 (NBMA) address to use as the better first hop, the associated 453 Neighbor Cache entry in the source host is updated and its 454 reachability set to STALE. Updating the cache in this context 455 involves building a new VC to the new NBMA address. If this is 456 successful, the old VC is torn down only if it no longer required 457 (since the old VC was to the router, it may still be required by 458 other packets from the host that are heading to the router). 460 Two mechanisms are provided for triggering the discovery of a better 461 first hop: 463 Router-based flow identification/detection. 465 Host-initiated shortcut request. 467 Section 3.2.1 discusses flow-based triggers, section 3.2.2 discusses 468 the host initiated trigger, and section 3.2.3 discusses the use of 469 NHRP to discover mappings for IPv6 targets in remote LLs. 471 3.2.1 Flow Triggered Redirection. 473 The modification of forwarding paths based on the dynamic detection 474 of IP packet flows is at the core of models such as the Cell Switch 475 Router [11] and the IP Switch [12]. Responsibility for detecting 476 flows is placed into the routers, where packets cross the edges of IP 477 routing boundaries. 479 For the purpose of conformance with this document, a router MAY 480 choose to initiate the discovery of a better first-hop when it 481 determines that an identifiable flow of IP packets are passing 482 through it. 484 Such a router: 486 SHALL only track flows that originate from a directly attached 487 host (a host that is within the LL-local scope of one of the 488 router's interfaces). 490 SHALL NOT use IP packets arriving from another router to 491 trigger the generation of a Router Redirect. 493 SHALL only consider IPv6 packets with FlowID of zero for the 494 purposes of flow detection as defined in this section. 496 SHALL utilize NHRP as described in section 3.2.3 to ascertain a 497 better first-hop when a suitable flow is detected, and 498 advertise the information in a Router Redirect. 500 IPv6 routers that support the OPTIONAL flow detection behavior 501 described above SHALL support administrative mechanisms to switch off 502 flow-detection. They MAY provide mechanisms for adding additional 503 contstraints to the categories of IPv6 packets that constitute a 504 'flow'. 506 The actual algorithm(s) for determining what sequence of IPv6 packets 507 constitute a 'flow' are outside the scope of this document. Appendix 508 C discusses the rationale behind the use of non-zero FlowID to 509 suppress flow detection. 511 3.2.2 Host Triggered Redirection 513 A source host MAY also trigger a redirection to a transient neighbor. 514 To support host-triggered redirects, routers conforming to this 515 document SHALL recognize specific Neighbor Solicitation messages sent 516 by hosts as requests for the resolution of off-link addresses. 518 To perform a host-triggered redirect, a source host SHALL: 520 Create a Neighbor Solicitation message refering to the off-LL 521 destination (target) for which a shortcut is desired 523 Address the NS message to the router that would be the next hop 524 for traffic sent towards the off-LL target (rather than the 525 target's solicited node multicast address). 527 Instead of using the standard ND hop limit of 255, supply the 528 desired value which will be used in restricting the reach of the 529 requested shortcut attempt. The recommended value is the hop limit 530 of the flow for which this trigger is being sent. 532 Forward the NS packet to the router that would be the next hop for 533 traffic sent towards the off-LL target. 535 Routers SHALL consider a unicast NS with an off-LL target address as 536 a request for a host-triggered redirect. However, actual shortcut 537 discovery is OPTIONAL for IPv6 routers. 539 When shortcut discovery is not supported, the router SHALL construct 540 a Neighbor Advertisement message identifying the router itself as the 541 best 'shortcut', and return it to the soliciting host. 543 If short discovery is to be supported, the router's response SHALL 544 be: 546 A suitable NHRP Request is constructed and sent as described in 547 section 3.2.3. The original NS message SHOULD be discarded. 549 Once the NHRP Reply is received by the originating router, the 550 router SHALL construct a Neighbor Advertisement message containing 551 the IPv6 address of the transient neighbor, the NBMA link layer 552 address returned by the NHRP resolution process, and the Overide 553 bit set to 1. 555 If the NHRP Reply returns the address of an egress router 556 rather than of the destination node itself, the Router bit MUST 557 be set to 1 in the NA message and the egress router MUST behave 558 as a proxy router as defined in [7]. 560 The resulting NA message SHALL then be transmitted back to the 561 source host. When the NA message is received, the source host 562 SHALL update its Neighbor and Destination caches. 564 The off-LL target is now considered a Transient Neighbor. The 565 next packet sent to the Transient Neighbor will result in the 566 creation of the direct, shortcut VC (to the off-LL target itself, 567 or to the best egress router towards that neighbor as determined 568 by NHRP). 570 If a NHRP NAK resolution reply or error indication is received for 571 a host-triggered shortcut attempt, the requesting router SHALL 572 construct a Neighbor Advertisement message identifying the router 573 itself as the best 'shortcut', and return it to the soliciting 574 host. 576 3.2.3 Use of NHRP between routers. 578 Once flow detection has occurred, or a host trigger has been 579 detected, routers SHALL use NHRP in an NHS to NHS mode to establish 580 the IPv6 to link level address mapping of a better first hop. 582 IPv6/NBMA routers supporting shortcut discovery will need to perform 583 some or all of the following functions: 585 - Construct NHRP Requests and Replies. 587 - Parse incoming NHRP Requests and Replies from other NHSes 588 (routers). 590 - Forward NHRP Requests towards an NHS that is topologically 591 closer to the IPv6 target. 593 - Forward NHRP Replies towards an NHS that is topologically closer 594 to the requester. 596 - Perform syntax translation between Neighbor Solicitations and 597 outbound NHRP Requests. 599 - Perform syntax translation between inbound NHRP Replies and 600 Neighbor Redirects or Neighbor Advertisements. 602 The destination of the flow that caused the trigger (or the target of 603 the host initiated trigger) is used as the target for resolution in a 604 NHRP Request. The router then forwards this NHRP Request to the next 605 closest NHS. The process continues (as it would for normal NHRP) 606 until the Request reaches an NHS that believes the IP target is 607 within link-local scope of one of its interfaces. (This may 608 potentially occur within a single router.) 610 As NHRP resolution requests always follow the routed path for a given 611 target protocol address, the scope of a shortcut request will be 612 automatically bounded to the scope of the IPv6 target address. (e.g. 613 resolution requests for site-local addresses will not be forwarded 614 across site boundaries.) 616 The last hop router SHALL resolve the NHRP Request from mapping 617 information contained in its neighbor cache for the interface on 618 which the specified target is reachable. If there is no appropriate 619 entry in the neighbor cache, or the destination is currently 620 considered unreachable, the last hop router SHALL perform Neighbor 621 Discovery on the local interface, and build the NHRP Reply from the 622 resulting answer. (Note, in the case where the NHRP Request 623 originated due to flow detection, there must already be a hop-by-hop 624 flow of packets going through the last hop router towards the target. 625 In this typical case the Neighbor cache will already have the desired 626 information.) 628 The NHRP Reply is propagated back to the source of the NHRP Request, 629 using a hop-by-hop path as it would for normal NHRP. 631 If the discovery process was triggered through flow detection at the 632 originating router, the return of the NHRP Reply results in the 633 following events: 635 A Router Redirect is constructed using the IPv6/NBMA mapping 636 carried in the NHRP Reply. 638 The Router Redirect is unicast to the IP packet flow's source 639 (using the VC on which the flow is arriving at the router, if it 640 is a bi-directional pt-pt VC). 642 Note that the router constructing the NHRP Reply does so using the 643 NBMA address returned by the target host when the target host first 644 accepted the flow of IP traffic. This retains a useful feature of 645 Neighbor Discovery - destination interface load sharing. 647 Upon receipt of a NHRP NAK reply or error indication for a flow- 648 triggered shortcut attempt, no indication is sent to the source of 649 the flow. 651 3.2.3.1 NHRP/ND packet translation rules. 653 The following translation rules are meant to augment the packet 654 format specification in section 5 of the NHRP specification [8], 655 covering those packet fields specifically utilized by the IPv6/NBMA 656 architecture. 658 NHRP messages are constructed and sent according to the rules in [8]. 659 The value of the NBMA technology specific fields such as ar$afn, 660 ar$pro.type, ar$pro.snap and link layer address format are defined in 661 NBMA-specific companion documents. Source, destination or client 662 protocol addresses in the common header or CIE of a NHRP message are 663 always IPv6 addresses of length 16. 665 When constructing an host-triggered NHRP resolution request in 666 response to a Neighbor Solicitation: 668 The ar$hopcnt field MUST NOT exceed the hop limit of the 669 triggering NS message. (This ensures that hosts have control over 670 the reach of their shortcut request.) 672 The Flags field in the common header of the NHRP resolution 673 request SHOULD have the Q and S bits set. 675 The U bit SHOULD be set. NBMA and protocol source addresses are 676 those of the router constructing the request. 678 The target address from the NS message is used as the NHRP target 679 protocol address. A CIE SHALL NOT be specified. 681 When constructing a NHRP resolution request as a result of flow 682 detection, the choice of values is configuration dependent. 684 A NHRP resolution reply is build according to the rules in [8]. 686 For each CIE returned, the holding time is 10 minutes. 688 The MTU may be 0 or a value specified in the NBMA-specific 689 companion document. 691 A successful NHRP resolution reply for a host-triggered shortcut 692 attempt is translated into an IPv6 Neighbor Advertisement message as 693 follows: 695 Source Address 696 NHRP Client Protocol Address 697 Destination Address 698 IPv6 Source Address of the triggering NS 699 Hop Limit 700 255 701 R flag 702 1 if NHRP Client Protocol Address is different from NHRP 703 Destination Protocol Address 704 S flag 705 1 706 O flag 707 Inverse of R flag 708 Target Address 709 Target of triggering NS 710 Target link-layer address 711 NHRP Client NBMA Address 713 All NHRP extensions currently defined in [8] have no effect on 714 NHRP/ND translation and MAY be used in NHRP messages for IPv6. 716 3.2.3.2 NHRP Purge rules. 718 Purges are generated by NHRP when changes are detected that 719 invalidate a previously issued NHRP Reply (this may include topology 720 changes, or a target host going down or changing identity). Any IPv6 721 shortcut previously established on the basis of newly purged 722 information SHOULD be torn down. 724 Routers SHALL keep track of NHRP cache entries for which they have 725 issued Neighbor Advertisements or Router Redirects. If a NHRP Purge 726 is received that invalidates information previously issued to local 727 host, the router SHALL issue a Router Redirect specifying the router 728 itself as the new best next-hop for the affected IPv6 target. 730 Routers SHALL keep track of Neighbor Cache entries that have 731 previously been used to generate an NHRP Reply. The expiry of any 732 such Neighbor Cache entry SHALL result in a NHRP Purge being sent 733 towards the router that originally requested the NHRP Reply. 735 3.3. Neighbor Unreachability Detection. 737 Neighbor Solicitations sent for the purposes of Neighbor 738 Unreachability Detection (NUD) are unicast to the Neighbor in 739 question, using the VC that is already open to that Neighbor. This 740 suggests that as far as NUD is concerned, the Transient Neighbor is 741 indistinguishable from an On-LL Neighbor. 743 3.4. Duplicate Address Detection. 745 Duplicate Address Detection is only required within the link-local 746 scope, which in this case is the LL-local scope. Transient Neighbors 747 are outside the scope of the LL. No particular interaction is 748 required between the mechanism for establishing shortcuts and the 749 mechanism for detection of duplicate link local addresses. 751 4 Node Operation Concepts. 753 This section describes node operations for performing basic functions 754 (such as sending and receiving data) on a Logical Link. The 755 application of these basic functions to the operation of the various 756 IPv6 protocols such as Neighbor Discovery is described in Appendix A. 758 The majority of this section applies only to NBMA networks when used 759 to provide point to point and point to multipoint SVCs. Section 7 760 discusses the case where the NBMA network is being used to supply 761 only point to point PVCs. 763 4.1.Connecting to a Logical Link. 765 Before a node can send or receive IPv6 datagrams its underlying 766 IPv6/NBMA interface(s) must first join a Logical Link. 768 An IPv6/NBMA driver SHALL establish a pt-pt VC to the MARS associated 769 with its Logical Link, and register as a Cluster Member [5]. The 770 node's IPv6/NBMA interface will then be a member of the LL, have a 771 Cluster Member ID (CMI) assigned, and can begin supporting IPv6 and 772 IPv6 ND operations. 774 If the node is a host or router starting up it SHALL issue a single 775 group MARS_JOIN for the following groups: 777 - Its derived Solicited-node address(es) with link-local scope. 778 - The All-nodes address with link-local scope. 779 - Other configured multicast groups with at least link-local 780 scope. 782 If the node is a router it SHALL additionally issue: 784 - A single group MARS_JOIN for the All-routers address with link- 785 local scope. 786 - A block MARS_JOIN for the range(s) of IPv6 multicast addresses 787 (with greater than link-local scope) for which promiscuous 788 reception is required. 790 The encapsulation mechanism for, and key field values of, MARS 791 control messages SHALL be defined in companion documents specific to 792 particular NBMA network technologies. 794 4.2 Joining a Multicast Group. 796 This section describes the node's behavior when it gets a 797 JoinLocalGroup request from the IPv6 Layer. The details of how this 798 behavior is achieved are going to be implementation specific. 800 If a JoinLocalGroup for a node-local address is received, the 801 IPv6/NBMA driver SHALL return success indication to the caller and 802 take no additional action. (Packets sent to node-local addresses 803 never reach the IPv6/NBMA driver.) 804 If a JoinLocalGroup is received for an address with greater than 805 node-local scope, the IPv6/NBMA driver SHALL send an appropriate 806 single group MARS_JOIN request to register this address with the 807 MARS. 809 4.3. Leaving a Multicast Group. 811 This section describes the node's behavior when it gets a 812 LeaveLocalGroup request from the IPv6 Layer. The details of how this 813 behavior is achieved are going to be implementation specific. 815 If a LeaveLocalGroup for a node-local address is received, the 816 IPv6/NBMA driver SHALL return success indication to the caller and 817 take no additional action. (Packets sent to node-local addresses 818 never reach the IPv6/NBMA driver.) 820 If a LeaveLocalGroup is received for an address with greater than 821 node-local scope, the IPv6/NBMA driver SHALL send an appropriate 822 single group MARS_LEAVE request to deregister this address with the 823 MARS. 825 4.4. Sending Data. 827 Separate processing and encapsulation rules apply for outbound 828 unicast and multicast packets. 830 4.4.1. Sending Unicast Data. 832 The IP level 'next hop' for each outbound unicast IPv6 packet is used 833 to identify a pt-pt VC on which to forward the packet. 835 For NBMA networks where LLC/SNAP encapsulation is typically used 836 (e.g. ATM or SMDS), the IPv6 packet SHALL be encapsulated with the 837 following LLC/SNAP header and sent over the VC. 839 [0xAA-AA-03][0x00-00-00][0x86-DD][IPv6 packet] 840 (LLC) (OUI) (PID) 842 For NBMA networks that do not use LLC/SNAP encapsulation, an 843 alternative rule SHALL be specified in the NBMA-specific companion 844 document. 846 If no pt-pt VC exists for the next hop address for the packet, the 847 node SHALL place a call to set up a VC to the next hop destination. 848 Any time the IPv6/NBMA driver receives a unicast packet for 849 transmission the IPv6 layer will already have determined the link- 850 layer (NBMA) address of the next hop. Thus, the information needed 851 to place the NBMA call to the next hop will be available. 853 The sending node SHOULD queue the packet that triggered the call 854 request, and send it when the call is established. 856 If the call to the next hop destination node fails the sending node 857 SHALL discard the packet that triggered the call setup. Persistent 858 failure to create a VC to the next hop destination will be detected 859 and handled at the IPv6 Network Layer through NUD. 861 At this time no rules are specified for mapping outbound packets to 862 VCs using anything more than the packet's destination address. 864 4.4.2. Sending Multicast Data. 866 The IP level 'next hop' for each outbound multicast IPv6 packet is 867 used to identify a pt-pt or pt-mpt VC on which to forward the packet. 869 For NBMA networks where LLC/SNAP encapsulation is typically used 870 (e.g. ATM or SMDS), multicast packets SHALL be encapsulated in the 871 following manner: 873 [0xAA-AA-03][0x00-00-5E][0x00-01][pkt$cmi][0x86DD][IPv6 packet] 874 (LLC) (OUI) (PID) (mars encaps) 876 The IPv6/NBMA driver's Cluster Member ID SHALL be copied into 877 the 2 octet pkt$cmi field prior to transmission. 879 For NBMA networks that do not use LLC/SNAP encapsulation, an 880 alternative rule SHALL be specified in the NBMA-specific companion 881 document. Some mechanism for carrying the IPv6/NBMA driver's 882 Cluster Member ID SHALL be provided. 884 If the packet's destination is one of the following multicast 885 addresses, it SHALL be sent over the IPv6/NBMA driver's direct pt-pt 886 VC to the MARS: 888 - A Solicited-node address with link-local scope. 889 - The All-nodes address with link-local scope. 890 - The All-routers address with link-local scope. 891 - A DHCP-v6 relay or server multicast address. 893 The MARS SHALL then redistribute the IPv6 packet as described in 894 section 3.1.3. (If the VC to the MARS has been idle timed out for 895 some reason, it MUST be re-established before forwarding the packet 896 to the MARS.) 898 If packet's destination is any other address, then the usual MARS 899 client mechanisms are used by the IPv6/NBMA driver to select and/or 900 establish a pt-mpt VC on which the packet is to be sent. 902 At this time no rules are specified for mapping outbound packets to 903 VCs using anything more than the packet's destination address. 905 4.5. Receiving Data. 907 Packets received using the encapsulation shown in section 4.4.1 908 SHALL be de-encapsulated and passed up to the IPv6 layer. The IPv6 909 layer then determines how the incoming packet is to be handled. 911 Packets received using the encapsulation specified in section 4.4.2 912 SHALL have their pkt$cmi field compared to the local IPv6/NBMA 913 driver's own CMI. If the pkt$cmi in the header matches the local CMI 914 the packet SHALL be silently dropped. Otherwise, the packet SHALL be 915 de-encapsulated and passed to the IPv6 layer. The IPv6 layer then 916 determines how the incoming packet is to be handled. 918 For NBMA networks that do not use LLC/SNAP encapsulation, alternative 919 rules SHALL be specified in the NBMA-specific companion document. 921 The IPv6/NBMA driver SHALL NOT attempt to filter out multicast IPv6 922 packets arriving with encapsulation defined for unicast packets, nor 923 attempt to filter out unicast IPv6 packets arriving with 924 encapsulation defined for multicast packets. 926 4.6. VC Setup and release for unicast data. 928 Unicast VCs are maintained separately from multicast VCs. The setup 929 and maintenance of multicast VCs are handled by the MARS client in 930 each IPv6/NBMA driver [5]. Only the setup and maintenance of pt-pt 931 VCs for unicast IPv6 traffic will be described here. Only best 932 effort unicast VCs are considered. The creation of VCs for other 933 classes of service is outside the scope of this document. 935 Before sending a packet to a new destination within the same LL a 936 node will first perform a Neighbor Discovery on the intra-LL target. 937 This is done to resolve the IPv6 destination address into a link- 938 layer address which the sender can then use to send unicast packets. 939 Appendix A.1.1 contains non-normative, descriptive text covering the 940 Neighbor Solicitation/Advertisement exchange and eventual 941 establishment of a new SVC. 943 A Redirect message (either a redirect to a node on the same LL, or a 944 shortcut redirect to a node outside the LL) results in the sending 945 (redirected) node creating a new pt-pt VC to a new receiving node. 946 the Redirect message SHALL contain the link layer (NBMA) address of 947 the new receiving IPv6/NBMA interface. The redirected node does not 948 concern itself where the new receiving node is located on the NBMA 949 network. The redirected node will set up a pt-pt VC to the new node 950 if one does not previously exist. The redirected node will then use 951 the new VC to send data rather than whatever VC it had previously 952 been using. 954 Redirects are unidirectional. Even after the source has reacted to a 955 redirect, the destination will continue to send IPv6 packets back to 956 the redirected node on the old path. This happens because the 957 destination node has no way of determining the IPv6 address of the 958 other end of a new VC in the absence of Neighbor Discovery. Thus, 959 redirects will not result in both ends of a connection using the new 960 VC. IPv6 redirects are not intended to provide symetrical 961 redirection. If the non-redirected node eventually receives a 962 redirect it MAY discover the existing VC to the target node and use 963 that rather than creating a new VC. 965 It is desirable that VCs are released when no longer needed. 967 An IPv6/NBMA driver SHALL release any VC that has been idle for 20 968 minutes. 970 This time limit MAY be reduced through configuration or as specified 971 in companion documents for specific NBMA networks. 973 If a Neighbor or Destination cache entry is purged then any VCs 974 associated with the purged entry SHOULD be released. 976 If the state of an entry in the Neighbor cache is set to STALE, then 977 any VCs associated with the stale entry SHOULD be released. 979 4.7 NBMA SVC Signalling Support and MTU issues. 981 Mechanisms for signaling the establishment and teardown of pt-pt and 982 pt-mpt SVCs for different NBMA networks SHALL be specified in 983 companion documents. 985 Since any given IPv6/NBMA driver will not know if the remote end of a 986 VC is in the same LL, drivers SHALL implement NBMA-specific 987 mechanisms to negotiate acceptable MTUs at the VC level. These 988 mechanisms SHALL be specified in companion documents. 990 However, IPv6/NBMA drivers can assume that they will always be 991 talking to another driver attached to the same type of NBMA network. 992 (For example, an IPv6/ATM driver does not need to consider the 993 possibility of establishing a shortcut VC directly to an IPv6/FR 994 driver.) 996 5. Interface Tokens, Link Layer Address Options, Link-Local Addresses 998 5.1 Interface Tokens 1000 Each IPv6 interface must have an interface token from which to form 1001 IPv6 autoconfigured addresses. This interface token must be unique 1002 within a Logical Link to prevent the creation of duplicate addresses 1003 when stateless address configuration is used. 1005 In cases where two nodes on the same LL produce the same interface 1006 token then one interface MUST choose another host-token. All 1007 implementations MUST support manual configuration of interface tokens 1008 to allow operators to manually change a interface token on a per-LL 1009 basis. Operators may choose to manually set interface tokens for 1010 reasons other than eliminating duplicate addresses. 1012 All interface tokens MUST be 64 bits in length and formatted as 1013 described in the following sections. The hosts tokens will be based 1014 on the format of an EUI-64 identifier [10]. For IPv6 use, the 1015 semantics of the EUI-64 Global/Local indicator bit has been inverted. 1016 (A universally administered EUI-64 is signified by a Global/Local 1017 indicator bit value of 0, while a globally unique IPv6 interface 1018 token is signified by a 1 in the corresponding position.) 1020 5.1.1 Single Logical Links on a Single NBMA Interface 1022 Physical NBMA interfaces will generally have some local identifier 1023 that may be used to generate a unique IPv6/NBMA interface token. The 1024 exact mechanism for generating interface tokens SHALL be specified in 1025 companion documents specific to each NBMA network. 1027 5.1.2 Multiple Logical Links on a Single NBMA Interface 1029 Physical NBMA interfaces MAY be used to provide multiple logical NBMA 1030 interfaces. Since each logical NBMA interface MAY support an 1031 independent IPv6 interface, two separate scenarios are possible: 1033 - A single host with separate IPv6/NBMA interfaces onto a number 1034 of independent Logical Links. 1036 - A set of 2 or more 'virtual hosts' (vhosts) sharing a common 1037 NBMA driver. Each vhost is free to establish IPv6/ATM interfaces 1038 associated with different or common LLs. However, vhosts are 1039 bound by the same requirement as normal hosts - no two 1040 interfaces to the same LL can share the same interface token. 1042 In the first scenario, since each IPv6/NBMA interface is associated 1043 with a different LL, each interface's external identity can be 1044 differentiated by the LL's routing prefix. Thus, the host can re-use 1045 a single unique interface token across all its IPv6/NBMA interfaces. 1046 (Internally the host will tag received packets in some locally 1047 specific manner to identify what IPv6/NBMA interface they arrived on. 1048 However, this is an issue generic to IPv6, and does not required 1049 clarification in this document.) 1051 The second scenario is more complex, but likely to be rarer. 1053 When supporting multiple logical NBMA interfaces over a single 1054 physical NBMA interface, indepedent and unique identifiers SHALL be 1055 generated for each virtual NBMA interface to enable the construction 1056 of unique IPv6/NBMA interface tokens. The exact mechanism for 1057 generating interface tokens SHALL be specified in companion documents 1058 specific to each NBMA network. 1060 5.2 Link Layer Address Options 1062 Neighbor Discovery defines two option fields for carrying link-layer 1063 specific source and target addresses. 1065 Between IPv6/NBMA interfaces, the format for these two options is 1066 adapted from the MARS [5] and NHRP [8] specs. It SHALL be: 1068 [Type][Length][NTL][STL][..NBMA Number..][..NBMA Subaddress..] 1069 | Fixed || Link layer address | 1071 [Type] is a one octet field. 1073 1 for Source link-layer address. 1075 2 for Target link-layer address. 1077 [Length] is a one octet field. 1079 The total length of the option in multiples of 8 octets. Zeroed bytes 1080 are added to the end of the option to ensure its length is a multiple 1081 of 8 octets. 1083 [NTL] is a one octet 'Number Type & Length' field. 1085 [STL] is a one octet 'SubAddress Type & Length' field. 1087 [NBMA Number] is a variable length field. It is always present. This 1088 contains the primary NBMA address. 1090 [NBMA Subaddress] is a variable length field. It may or may not be 1091 present. This contains any NBMA subaddress that may be required. 1093 If the [NBMA Subaddress] is not present, the option ends after the 1094 [NBMA Number] ( and any additional padding for 8 byte alignment). 1096 The contents and interpretation of the [NTL], [STL], [NBMA Number], 1097 and [NBMA Subaddress] fields are specific to each NBMA network, and 1098 SHALL be specified in companion documents. 1100 5.3 Link-Local Addresses 1102 The IPv6 link-local address is formed by appending the interface 1103 token, as defined above, to the prefix FE80::/64. 1105 10 bits 54 bits 64 bits 1106 +----------+-----------------------+----------------------------+ 1107 |1111111010| (zeros) | Interface Token | 1108 +----------+-----------------------+----------------------------+ 1110 6. Conclusion and Open Issues 1112 This document describes a general architecture for IPv6 over NBMA 1113 networks. It forms the basis for subsidiary companion documents that 1114 provide details for various specific NBMA technologies (such as ATM 1115 or Frame Relay). The IPv6 over NBMA architecture allows conventional 1116 host-side operation of the IPv6 Neighbor Discovery protocol, while 1117 also supporting the establishment of 'shortcut' NBMA forwarding paths 1118 (when dynamically signaled NBMA links are available). 1120 The IPv6 "Link" is generalized to "Logical Link" in an analagous 1121 manner to the IPv4 "Logical IP Subnet". The MARS protocol is 1122 augmented and used to provide relatively efficient intra Logical Link 1123 multicasting of IPv6 packets, and distribution of Discovery messages. 1124 Shortcut NBMA level paths are supported either through router based 1125 flow detection, or host originated explicit requests. Neighbor 1126 Discovery is used without modification for all intra-LL control 1127 (including the initiation of NBMA shortcut discovery). Router to 1128 router NHRP is used to obtain the IPv6/NBMA address mappings for 1129 shortcut targets outside a source's Logical Link. 1131 7. Security Consideration 1133 While this proposal does not introduce any new security mechanisms 1134 all current IPv6 security mechanisms will work without modification 1135 for NBMA. This includes both authentication and encryption for both 1136 Neighbor Discovery protocols as well as the exchange of IPv6 data 1137 packets. The MARS protocol is modified in a manner that does not 1138 affect or augment the security offered by RFC 2022. 1140 Acknowledgments 1142 Eric Nordmark confirmed the usefulness of ND Redirect messages in 1143 private email during the March 1996 IETF. The discussions with 1144 various ION WG members during the June and December 1996 IETF helped 1145 solidify the architecture described here. Grenville Armitage's 1146 original work on IPv6/ATM occurred while employed at Bellcore. 1147 Elements of section 5 were borrowed from Matt Crawford's draft on 1148 IPv6 over Ethernet. 1150 Author's address 1152 Grenville Armitage 1153 Bell Laboratories, Lucent Technologies 1154 101 Crawfords Corner Road 1155 Holmdel, NJ 07733 1156 USA 1157 Email: gja@lucent.com 1159 Peter Schulter 1160 Bright Tiger Technologies 1161 125 Nagog Park 1162 Acton, MA 01720 1163 Email: paschulter@acm.org 1165 Markus Jork 1166 European Applied Research Center 1167 Digital Equipment Corporation 1168 CEC Karlsruhe 1169 Vincenz-Priessnitz-Str. 1 1170 D-76131 Karlsruhe 1171 Germany 1172 email: jork@kar.dec.com 1174 Geraldine Harter 1175 Digital UNIX Networking 1176 Digital Equipment Corporation 1177 110 Spit Brook Road 1178 Nashua, NH 03062 1179 Email: harter@zk3.dec.com 1181 References. 1183 [1] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) 1184 Specification", RFC-1883, December 1995. 1186 [2] ATM Forum, "ATM User Network Interface (UNI) Specification 1187 Version 3.1", ISBN 0-13-393828-X, Prentice Hall, Englewood Cliffs, 1188 NJ, June 1995. 1190 [3] M. Crawford, "A Method for the Transmission of IPv6 Packets over 1191 Ethernet Networks", RFC 1972, August 1996. 1193 [4] J. Heinanen, "Multiprotocol Encapsulation over ATM Adaption Layer 1194 5", RFC 1483, USC/Information Science Institute, July 1993. 1196 [5] G.J. Armitage, "Support for Multicast over UNI 3.1 based ATM 1197 Networks", RFC 2022, Bellcore, November 1996. 1199 [6] S. Deering, R. Hinden, "IP Version 6 Addressing Architecture", 1200 RFC-1884, December 1995. 1202 [7] T. Narten, E. Nordmark, W.A. Simpson, "Neighbor Discovery for IP 1203 Version 6 (IPv6)", RFC 1970, August 1996. 1205 [8] J. Luciani, et al, "NBMA Next Hop Resolution Protocol (NHRP)", 1206 INTERNET DRAFT, draft-ietf-rolc-nhrp-11.txt, March 1997. 1208 [9] S. Thomson, T. Nartin, "IPv6 Stateless Address 1209 Autoconfiguration", RFC 1971, August 1996. 1211 [10] "64-Bit Global Identifier Format Tutorial", 1212 http://standards.ieee.org/db/oui/tutorials/EUI64.html. 1214 [11] Y. Katsube, K. Nagami, H. Esaki, "Toshiba's Router Architecture 1215 Extensions for ATM : Overview", RFC 2098, February 1997 1217 [12] P. Newman, T. Lyon, G. Minshall, "Flow Labeled IP: ATM under 1218 IP", Proceedings of INFOCOM'96, San Francisco, March 1996, pp.1251- 1219 1260 1221 [13] D. Piscitello, J. Lawrence, "The Transmission of IP Datagrams 1222 over the SMDS Service", RFC 1209, Bell Communications Research, March 1223 1991 1225 [14] D. Plummer, "An Ethernet Address Resolution Protocol - or - 1226 Converting Network Protocol Addresses to 48.bit Ethernet Address for 1227 Transmission on Ethernet Hardware", RFC 826, MIT, November 1982 1229 [15] J. McCann, et al, "Path MTU Discovery for IP version 6", RFC 1230 1981, August 1996 1232 [16] S. Bradner, "Key words for use in RFCs to Indicate Requirement 1233 Levels", RFC 2119, Harvard University, March 1997 1235 [17] G. Armitage, P.Schulter, M. Jork, G. Harter, "IPv6 over ATM 1236 Networks", INTERNET DRAFT, draft-ietf-ion-ipv6-atm-00.txt, September 1237 1997 1239 Appendix A. IPv6 Protocol Operation Description 1241 The IPv6 over NBMA model described in this document maintains the 1242 complete semantics of the IPv6 protocols. No changes need to be made 1243 to the IPv6 Network Layer. Since the concept of the security 1244 association is not being changed for NBMA, this framework maintains 1245 complete IPv6 security semantics and features. This allows IPv6 1246 nodes to choose their responses to solicitations based on security 1247 information as is done with other datalinks, thereby maintaining the 1248 semantics of Neighbor Discovery since it is always the 1249 solicited node that chooses what (and even if) to reply to the 1250 solicitation. Thus, NBMA will be transparent to the network layer 1251 except in cases where extra services (such as QoS VCs) are offered. 1253 The remainder of this Appendix describes how the core IPv6 protocols 1254 will operate within the model described here. 1256 A.1 Neighbor Discovery Operations 1258 Before performing any sort of Neighbor discover operation, each node 1259 must first join the all-node multicast group, and it's solicited node 1260 multicast address (the use of this address in relation to DAD is 1261 described in A.1.4). The IPv6 Network layer will join these 1262 multicast groups as described in 4.2. 1264 A.1.1 Performing Address Resolution 1266 An IPv6 host performs address resolution by sending a Neighbor 1267 Solicitation to the solicited-node multicast address of the target 1268 host, as described in [7]. The Neighbor Solicitation message will 1269 contain a Source Link-Layer Address Option set to the 1270 soliciting node's NBMA address on the LL. 1272 When the local node's IPv6/NBMA driver is passed the Neighbor 1273 Solicitation message from the IPv6 network layer, it follows the 1274 steps described in section 4.4.2 Sending Multicast Data. 1276 One or more nodes will receive the Neighbor Solicitation message. The 1277 nodes will process the data as described in section 4.5 and pass the 1278 de-encapsulated packets to the IPv6 network layer. 1280 If the receiving node is the target of the Neighbor Solicitation it 1281 will update its Neighbor Cache with the soliciting node's NBMA 1282 address, contained in the Neighbor Solicitation message's Source 1283 Link-Layer Address Option as described in [7]. 1285 The solicited IPv6 host will respond to the Neighbor Solicitation 1286 with a Neighbor Advertisement message sent to the IPv6 unicast 1287 address of the soliciting node. The Neighbor Advertisement 1288 message will contain a Target Link-Layer Address Option set to 1289 the solicited node's ATM address on the LL. 1291 The solicited node's IPv6/NBMA driver will be passed the Neighbor 1292 Advertisement and the soliciting node's link-layer address from 1293 the IPv6 network layer. It will then follow the steps described in 1294 section section 4.4.1 to send the NA message to the soliciting node. 1295 This will create a pt-pt VC between the solicited node and soliciting 1296 node if one did not already exist. 1298 The soliciting node will then receive the Neighbor Advertisement 1299 message over the new PtP VC, de-encapsulate the message, and pass it 1300 to the IPv6 Network layer for processing as described in section 4.5. 1301 The soliciting node will then make the appropriate entries in it's 1302 Neighbor cache, including caching the NBMA link-layer address of the 1303 solicited node as described in [7]. 1305 At this point each system has a complete Neighbor cache entry for the 1306 other system. They can exchange data over the pt-pt VC newly created 1307 by the solicited node when it returned the Neighbor Advertisement, or 1308 create a new VC. 1310 An IPv6 host can also send an Unsolicited Neighbor Advertisement to 1311 the all-nodes multicast address. When the local node IPv6/NBMA driver 1312 is passed the Neighbor Advertisement from the IPv6 network layer, it 1313 follows the steps described in section 4.4.2 to send the NA message 1314 to the all-nodes multicast address. Each node wil process the 1315 incoming packet as described in section 4.5 and then pass the packet 1316 to the IPv6 Network layer where it will be processed as described in 1317 [7]. 1319 A.1.2 Performing Router Discovery 1321 Router Discovery is described in [7]. To support Router Discovery an 1322 IPv6 router will join the IPv6 all-routers multicast group address. 1323 When the IPv6/NBMA driver gets the JoinLocalGroup request from the 1324 IPv6 Network Layer, it follows the process described in section 4.2. 1326 IPv6 routers periodically send unsolicited Router Advertisements 1327 announcing their availability on the LL. When an IPv6 router 1328 sends an unsolicited Router Advertisement, it sends a data packet 1329 addressed to the IPv6 all-nodes multicast address. When the local 1330 node IPv6/NBMA driver gets the Router Advertisement message from 1331 the IPv6 Network layer, it transmits the message by following steps 1332 described in section 4.4.2. The MARS will transmit the packet on 1333 the LL's ClusterControlVC, which sends the packets to all nodes on 1334 the LL. Each node on the LL will then process the incoming packet as 1335 described in section 4.5 and pass the received packet to the IPv6 1336 Network layer for processing as appropriate. 1338 To perform Router Discovery, an IPv6 host sends a Router Solicitation 1339 message to the all-routers multicast address. When the local node 1340 IPv6/NBMA driver gets the request from the IPv6 Network Layer to send 1341 the packet, it follows the steps described in section 4.4.2. The 1342 RS message will be sent to either those nodes which have joined the 1343 all-routers multicast group or to all nodes. The nodes which receive 1344 the RA message will process the message as described in section 4.5 1345 and pass the RA message up to the IPv6 layer for processing. Only 1346 those nodes which are routers will process the message and respond to 1347 it. 1349 An IPv6 router responds to a Router Solicitation by sending a Router 1350 Advertisement addressed to the IPv6 all-nodes multicast address if 1351 the source address of the Router Solicitation was the unspecified 1352 address. If the source address in the Router Solicitation is not the 1353 unspecified address, the the router will unicast the Router 1354 Advertisement to the soliciting node. If the router sends the Router 1355 Advertisement to the all-nodes multicast address then it follows the 1356 steps described above for unsolicited Router Advertisements. 1358 If the Router Advertisement is to be unicast to the soliciting node, 1359 the IPv6 Network Layer will give the node's IPv6/NBMA driver the 1360 Router Advertisement and link-layer address of the soliciting node 1361 (obtained through Address Resolution if necessary) which will send 1362 the packet according to the steps described in section 4.4.1 This 1363 will result in a new pt-pt VC being created between the router and 1364 the soliciting node if one did not already exist. 1366 The soliciting node will receive and process the Router Advertisement 1367 as described in section 4.5 and will pass the RA message to the IPv6 1368 Network layer. The IPv6 Network Layer may, depending on the state of 1369 the Neighbor Cache entry, update the Neighbor Cache with the 1370 router's NBMA address, contained in the Router Advertisement 1371 message's Source Link-Layer Address Option. 1373 If a pt-pt VC is set up during Router Discovery, subsequent IPv6 best 1374 effort unicast data between the soliciting node and the router will 1375 be transmitted over the new PtP VC. 1377 A.1.3 Performing Neighbor Unreachability Detection (NUD) 1379 Neighbor Unreachability Detection (NUD) is the process by which an 1380 IPv6 host determines that a neighbor is no longer reachable, as 1381 described in [7]. Each Neighbor Cache entry contains information 1382 used by the NUD algorithm to detect reachability failures. 1383 Confirmation of a neighbor's reachability comes either from 1384 upper-layer protocol indications that data recently sent to the 1385 neighbor was received, or from the receipt of a Neighbor 1386 Advertisement message in response to a Neighbor Solicitation probe. 1388 Connectivity failures at the node's IPv6/NBMA driver, such as 1389 released VCs (see section 4.6) and the inability to create a VC to a 1390 neighbor (see section 4.4.1), are detected and handled at the IPv6 1391 Network Layer, through Neighbor Unreachability Detection. The node's 1392 IPv6/NBMA driver does not attempt to detect or recover from these 1393 conditions. 1395 A persistent failure to create a VC from the IPv6 host to one of its 1396 IPv6 neighbors will be detected and handled through NUD. On each 1397 attempt to send data from the IPv6 host to its neighbor, the node's 1398 IPv6/NBMA driver will attempt to set up a VC to the neighbor, and 1399 failing to do so, will drop the packet. IPv6 reachability 1400 confirmation timers will eventually expire, and the neighbor's 1401 Neighbor Cache entry will enter the PROBE state. The PROBE state will 1402 cause the IPv6 host to unicast Neighbor Solicitations to the 1403 neighbor, which will be dropped by the local node's IPv6/NBMA driver 1404 after again failing to setup the VC. The IPv6 host will therefore 1405 never receive the solicited Neighbor Advertisements needed for 1406 reachability confirmation, causing the neighbor's entry to be 1407 deleted from the Neighbor Cache. The next time the IPv6 host tries to 1408 send data to that neighbor, address resolution will be performed. 1409 Depending on the reason for the previous failure, connectivity to the 1410 neighbor could be re-established (for example, if the previous VC 1411 setup failure was caused by an obsolete link- layer address in the 1412 Neighbor Cache). 1414 In the event that a VC from an IPv6 neighbor is released, the next 1415 time a packet is sent from the IPv6 host to the neighbor, the node's 1416 IPv6/NBMA driver will recognize that it no longer has a VC to that 1417 neighbor and attempt to setup a new VC to the neighbor. If, on the 1418 first and on subsequent transmissions, the node is unable to create 1419 a VC to the neighbor, NUD will detect and handle the failure as 1420 described earlier (handling the persistent failure to create a VC 1421 from the IPv6 host to one of its IPv6 neighbors). Depending on the 1422 reason for the previous failure, connectivity to the neighbor may or 1423 may not be re-established. 1425 A.1.4 Performing Duplicate Address Detection (DAD) 1427 An IPv6 host performs Duplicate Address Detection (DAD) to determine 1428 that the address it wishes to use on the LL (i.e. a tentative 1429 address) is not already in use, as described in [9] and [7]. 1430 Duplicate Address Detection is performed on all addresses the host 1431 wishes to use, regardless of the configuration mechanism used to 1432 obtain the address. 1434 Prior to performing Duplicate Address Detection, a host will join 1435 the all-nodes multicast address and the solicited-node multicast 1436 address corresponding to the host's tentative address (see 4.2. 1437 Joining a Multicast Group). The IPv6 host initiates Duplicate 1438 Address Detection by sending a Neighbor Solicitation to solicited- 1439 node multicast address corresponding to the host's tentative 1440 address, with the tentative address as the target. When the local 1441 node's IPv6/NBMA driver gets the Neighbor Solicitation message from 1442 the IPv6 Network layer, it follows the steps outlined in section 1443 4.4.2. The NS message will be sent to those nodes which joined the 1444 target solicited-node multicast group or to all nodes. The DAD NS 1445 message will be received by one or more nodes on the LL and processed 1446 by each as described in section 4.5. Note that the MARS client of 1447 the sending node will filter out the message so that the sending 1448 node's IPv6 Network layer will not see the message. The IPv6 Network 1449 Layer of any node which is not a member of the target solicited-node 1450 multicast group will discard the Neighbor Solicitation message. 1452 If no other hosts have joined the solicited-node multicast address 1453 corresponding to the tentative address, then the host will not 1454 receive a Neighbor Advertisement containing its tentative address 1455 as the target. The host will perform the retransmission logic 1456 described in [9], terminate Duplicate Address Detection, 1457 and assign the tentative address to the NBMA interface. 1459 Otherwise, other hosts on the LL that have joined the solicited-node 1460 multicast address corresponding to the tentative address will 1461 process the Neighbor Solicitation. The processing will depend on 1462 whether or not receiving IPv6 host considers the target address to 1463 be tentative. 1465 If the receiving IPv6 host's address is not tentative, the host will 1466 respond with a Neighbor Advertisement containing the target address. 1467 Because the source of the Neighbor Solicitation is the unspecified 1468 address, the host sends the Neighbor Advertisement to the all-nodes 1469 multicast address following the steps outlined in section 4.4.2. The 1470 DAD NA message will be received and processed by the MARS clients on 1471 all nodes in the LL as described in section 4.5. Note that the 1472 sending node will filter the incoming message since the CMI in the 1473 message header will match that of the receiving node. All other 1474 nodes will de-encapsulate the message and pass it to the IPv6 Network 1475 layer. The host performing DAD will detect that its tentative 1476 address is the target of the Neighbor Advertisement, and determine 1477 that the tentative address is not unique and cannot be assigned to 1478 its NBMA interface. 1480 If the receiving IPv6 host's address is tentative, then both hosts 1481 are performing DAD using the same tentative address. The receiving 1482 host will determine that the tentative address is not unique and 1483 cannot be assigned to its NBMA interface. 1485 A.1.5 Processing Redirects 1487 An IPv6 router uses a Redirect Message to inform an IPv6 host of a 1488 better first-hop for reaching a particular destination, as described 1489 in [7]. This can be used to direct hosts to a better first hop 1490 router, another host on the same LL, or to a transient neighbor on 1491 another LL. The IPv6 router will unicast the Redirect to the IPv6 1492 source address that triggered the Redirect. The router's IPv6/NBMA 1493 driver will transmit the Redirect message using the procedure 1494 described in section 4.4.1. This will create a VC between the router 1495 and the redirected host if one did not previously exist. 1497 The node's IPv6/NBMA driver of the IPv6 host that triggered the 1498 Redirect will receive the encapsulated Redirect over one of it's 1499 pt-pt VCs. It will the de-encapsulate the packet, and pass the 1500 Redirect message to the IPv6 Network Layer, as described section 4.5. 1502 Subsequent data sent from the IPv6 host to the destination will be 1503 sent to the next-hop address specified in the Redirect Message. For 1504 NBMA networks, the Redirect Message should contain the link-layer 1505 address option as described in [7] and section 5.2, thus the 1506 redirected node will not have to perform a Neighbor Solicitation to 1507 learn the link-layer address of the node to which it has been 1508 redirected. Thus, the redirect can be to any node on the ATM 1509 network, regardless of the LL membership of the new target node. This 1510 allows NBMA hosts to be redirected off their LL to achieve shortcut 1511 by using standard IPv6 protocols. 1513 Once redirected, the IPv6 Network Layer will give the node's 1514 IPv6/NBMA driver the IPv6 packet and the link-layer address of the 1515 next-hop node when it sends data to the redirected destination. The 1516 node's IPv6/NBMA driver will determine if a VC to the next-hop 1517 destination exists. If a pt-pt VC does not exist, then the IPv6/NBMA 1518 driver will queue the data packet and initiate a setup of a VC to the 1519 destination. When the VC is created, or if one already exists, then 1520 the node will encapsulate the outgoing data packet and send it on the 1521 VC. 1523 Note that Redirects are unidirectional. The redirected host will 1524 create a VC to the next-hop destination as specified in the Redirect 1525 message, but the next-hop will not be redirected to the source host. 1526 Because no Neighbor Discovery takes place, the next-hop destination 1527 has no way of determining the identity of the caller when it receives 1528 the new VC. Also, since ND does not take place on redirects, the 1529 next-hop receives no event that would cause it to update it's 1530 neighbor or destination caches. However, it will continue to 1531 transmit data back to the redirected host on the former path to the 1532 redirected host. The next-hop node should be able to use the new VC 1533 from the redirected destination if it too receives a redirect 1534 redirecting it to the redirected node. This behavior is consistent 1535 with [7]. 1537 A.2 Address Configuration 1539 IPv6 addresses are auto-configured using the stateless or stateful 1540 address auto-configuration mechanisms, as described in [IPV6- 1541 ADDRCONF] and [IPV6-DHCP]. The IPv6 auto-configuration process 1542 involves creating and verifying the uniqueness of a link-local 1543 address on an LL, determining whether to use stateless and/or 1544 stateful configuration mechanisms to obtain addresses, and 1545 determining if other (non-address) information is to be 1546 autoconfigured. IPv6 addresses can also be manually configured, if 1547 for example, auto-configuration fails because the autoconfigured 1548 link-local address is not unique. An LL administrator specifies the 1549 type of autoconfiguration to use; the hosts on an LL receive this 1550 autoconfiguration information through Router Advertisement messages. 1552 The following sections describe how stateless, stateful and manual 1553 address configuration will work in an IPv6/NBMA environment. 1555 A.2.1 Stateless Address Configuration 1557 IPv6 stateless address configuration is the process by which an 1558 IPv6 host autoconfigures its interfaces, as described in [IPV6- 1559 ADDRCONF]. 1561 When an IPv6 host first starts up, it generates a link-local 1562 address for the interface attached to the Logical Link. It then 1563 verifies the uniqueness of the link-local address using Duplicate 1564 Address Detection (DAD). If the IPv6 host detects that the link- 1565 local address is not unique, the autoconfiguration process 1566 terminates. The IPv6 host must then be manually configured. 1568 After the IPv6 host determines that the link-local address is 1569 unique and has assigned it to the interface on the Logical Link, 1570 the IPv6 host will perform Router Discovery to obtain auto- 1571 configuration information. The IPv6 host will send out a Router 1572 Solicitation and will receive a Router Advertisement, or it will 1573 wait for an unsolicited Router Advertisement. The IPv6 host will 1574 process the M and O bits of the Router Advertisement, as described 1575 in [9] and as a result may invoke stateful address auto- 1576 configuration. 1578 If there are no routers on the Logical Link, the IPv6 host will be 1579 able to communicate with other IPv6 hosts on the Logical Link 1580 using link-local addresses. The IPv6 host will obtain a neighbor's 1581 link-layer address using Address Resolution. The IPv6 host will 1582 also attempt to invoke stateful auto-configuration, unless it has 1583 been explicitly configured not to do so. 1585 A.2.2 Stateful Address Configuration (DHCP) 1587 IPv6 hosts use the Dynamic Host Configuration Protocol (DHCPv6) to 1588 perform stateful address auto-configuration, as described in [IPV6- 1589 DHCP]. 1591 A DHCPv6 server or relay agent is present on a Logical Link that has 1592 been configured with manual or stateful auto-configuration. The 1593 DHCPv6 server or relay agent will join the IPv6 DHCPv6 Server/Relay- 1594 Agent multicast group on the Logical Link. When the node's IPv6/NBMA 1595 driver gets the JoinLocalGroup request from the IPv6 Network Layer, 1596 it follows the process described in section 4.2. 1598 An IPv6 host will invoke stateful auto-configuration if M and O 1599 bits of Router Advertisements indicate it should do so, and may 1600 invoke stateful auto-configuration if it detects that no routers 1601 are present on the Logical Link. An IPv6 host that is obtaining 1602 configuration information through the stateful mechanism will 1603 hereafter be referred to as a DHCPv6 client. 1605 A DHCPv6 client will send a DHCPv6 Solicit message to the 1606 DHCPv6 Server/Relay-Agent multicast address to locate a DHCPv6 1607 Agent. When the soliciting node's IPv6/NBMA driver gets the 1608 request from the IPv6 Network Layer to send the packet, it follows 1609 the steps described in section 4.4.2. Sending Multicast Data. This 1610 will result in one or more nodes on the LL receiving the message. 1611 Each node that receives the solicitation packet will process it as 1612 described in section section 4.5 and will pass the message up to the 1613 IPv6 network layer. Only the IPv6 network layer of the DHCPv6 1614 server/relay-agent will accept the packet and process it. 1616 A DHCPv6 Server or Relay Agent on the Logical Link will unicast a 1617 DHCPv6 Advertisement to the DHCPv6 client. The IPv6 Network Layer 1618 will give the node's IPv6/NBMA driver the packet and link-layer 1619 address of the DHCPv6 client (obtained through Neighbor Discovery if 1620 necessary). The node IPv6/NBMA driver will then transmit the 1621 packet as described in section 4.4.1. This will result in a new pt- 1622 pt VC being created between the server and the client if one did not 1623 previously exist. 1625 The DHCP client's IPv6/NBMA driver will receive the encapsulated 1626 packet from the DHCP Server or Relay Agent, as described in section 1627 4.5. The node will de-encapsulate the multicast packet and then pass 1628 it up to the IPv6 Network Layer for processing. The IPv6 Network 1629 Layer will deliver the DHCPv6 Advertise message to the DHCPv6 client. 1631 Other DHCPv6 messages (Request, Reply, Release and Reconfigure) are 1632 unicast between the DHCPv6 client and the DHCPv6 Server. Depending 1633 on the reachability of the DHCPv6 client's address, messages 1634 exchanged between a DHCPv6 client and a DHCPv6 Server on another LL 1635 are sent either via a router or DHCPv6 Relay-Agent. Prior to sending 1636 the DHCPv6 message, the IPv6 Network Layer will perform Neighbor 1637 Discovery (if necessary) to obtain the link-layer address 1638 corresponding to the packet's next-hop. A pt-pt VC will be set up 1639 between the sender and the next hop, and the encapsulated packet 1640 transmitted over it, as described in 4.4. Sending Data. 1642 A.2.3 Manual Address Configuration 1644 An IPv6 host will be manually configured if it discovers through DAD 1645 that its link-local address is not unique. Once the IPv6 host is 1646 configured with a unique interface token, the auto-configuration 1647 mechanisms can then be invoked. 1649 A.3 Internet Group Management Protocol (IGMP) 1651 IPv6 multicast routers will use the IGMPv6 protocol to periodically 1652 determine group memberships of local hosts. In the framework 1653 described here, the IGMPv6 protocols can be used without any special 1654 modifications for NBMA. While these protocols might not be the most 1655 efficient in this environment, they will still work as described 1656 below. However, IPv6 multicast routers connected to an NBMA LL could 1657 optionally optimize the IGMP functions by sending 1658 MARS_GROUPLIST_REQUEST messages to the MARS serving the LL and 1659 determining group memberships by the MARS_GROUPLIST_REPLY messages. 1661 Querying the MARS for multicast group membership is an optional 1662 enchancement and is not required for routers to determine IPv6 1663 multicast group membership on a LL. 1665 There are three ICMPv6 message types that carry multicast group 1666 membership information: the Group Membership Query, Group Membership 1667 Report and Group Membership Reduction messages. IGMPv6 will 1668 continue to work unmodified over the IPv6/NBMA architecture 1669 described in this document. 1671 An IPv6 multicast router receives all IPv6 multicast packets on the 1672 LL joining all multicast groups in promiscuous mode [5]. The MARS 1673 server will then cause the multicast router to be added to all 1674 existing and future multicast VCs. The IPv6 multicast router will 1675 thereafter be the recipient of all IPv6 multicast packets sent 1676 within the Logical Link. 1678 An IPv6 multicast router discovers which multicast groups have 1679 members in the Logical Link by periodically sending Group Membership 1680 Query messages to the IPv6 all-nodes multicast address. When the 1681 local node's IPv6/NBMA driver gets the request from the IPv6 Network 1682 Layer to send the Group Membership Query packet, it follows the steps 1683 described in 4.4.2. The node determines that the destination 1684 address of the packet is the all-nodes multicast address and passes 1685 the packet to the node's MARS client where the packet is encapsulated 1686 and directly transmitted to the MARS. The MARS then relays the packet 1687 to all nodes in the LL. Each node's IPv6/NBMA drivers will receive 1688 the packet, de-encapsulat it, and passed it up to the IPv6 Network 1689 layer. If the originating node receives the encapsulated packet, 1690 the packet will be filtered out by the MARS client since the Cluster 1691 Member ID of the receiving node will match the CMI in the packet's 1692 MARS encapsulation header. 1694 IPv6 hosts in the Logical Link will respond to a Group Membership 1695 Query with a Group Membership Report for each IPv6 multicast group 1696 joined by the host. IPv6 hosts can also transmit a Group 1697 Membership Report when the host joins a new IPv6 multicast group. 1698 The Group Membership Report is sent to the multicast group whose 1699 address is being reported. When the local node IPv6/ATM driver 1700 gets the request from the IPv6 Network Layer to send the packet, it 1701 follows the steps described in 4.4.2. Sending Multicast Data. 1702 The node determines that the packet is being sent to a multicast 1703 address so forwards it to the node's MARS client for sending on the 1704 appropriate VC. 1706 The Group Membership Report packets will arrive at every node which 1707 is a member of the group being reported through one of the VC 1708 attached to each node's MARS client. The MARS client will de- 1709 encapsulate the incoming packet and the packet will be passed to the 1710 IPv6 Network layer for processing. The MARS client of the sending 1711 node will filter out the packet when it receives it. 1713 An IPv6 host sends a Group Membership Reduction message when the 1714 host leaves an IPv6 multicast group. The Group Membership 1715 Reduction is sent to the multicast group the IPv6 host is leaving. 1716 The transmission and receipt of Group Membership Reduction messages 1717 are handled in the same manner as Group Membership Reports. 1719 Appendix B. Alternative models of MARS support for Intra-LL ND 1721 B.1 Simplistic approach - Use MARS 'as is'. 1723 The IPv6/NBMA driver utilizes the standard MARS protocol to establish 1724 a VC forwarding path out of the interface on which it can transmit 1725 all multicast IPv6 packets, including ICMPv6 packets. The IPv6 1726 packets are then transmitted, and received by the intended 1727 destination set, using separate pt-mpt VCs per destination group. 1729 In this approach all the protocol elements in [5] are used 'as is'. 1730 However, SVC resource consumption must be taken into consideration. 1731 Unfortunately, ND assumes that link level multicast resources are 1732 best conserved by generating a sparsely distributed set of Solicited 1733 Node multicast addresses (to which discovery queries are initially 1734 sent). The original goal was to minimize the number of innocent nodes 1735 that simultaneously received discovery messages really intended for 1736 someone else. 1738 However, in connection oriented NBMA environments it becomes equally 1739 (or more) important to minimize the number of independent VCs that a 1740 given NBMA interface is required to originate or terminate. If we 1741 treat the MARS service as a 'black box' the sparse Solicited Node 1742 address space can lead to a large number of short-use, but longer 1743 lived, pt-mpt VCs (generated whenever the node is transmitting 1744 Neighbor Solicitations). Even more annoying, these VCs are only 1745 useful for additional packets being sent to their associated 1746 Solicited Node multicast address. A new pt-pt VC is required to 1747 actually carry the unicast IPv6 traffic that prompted the Neighbor 1748 Solicitation. 1750 The axis of inefficiency brought about by the sparse Solicited Nodes 1751 address space is orthogonal to the VC mesh vs Multicast Server 1752 tradeoff. Typically a multicast server aggregates traffic flow to a 1753 common multicast group onto a single VC. To reduce the VC consumption 1754 for ND, we need to aggregate across the Solicited Node address space 1755 - performing aggregation on the basis of a packet's function rather 1756 than its explicit IPv6 destination. The trade-off here is that the 1757 aggregation removes the original value of scattering nodes sparsely 1758 across the Solicited Nodes space. This is a price of the mismatch 1759 between ND and connection oriented networks. 1761 B.2 MARS as a Link (Multicast) Server. 1763 One possible aggregation mechanism is for every node's IPv6/NBMA 1764 driver to trap multicast ICMPv6 packets carrying multicast ND or RD 1765 messages, and logically remap their destinations to the All Nodes 1766 group (link local scope). By ensuring that the All Nodes group is 1767 supported by an MCS, the resultant VC load within the LL will be 1768 significantly reduced. 1770 A further optimization is for every node's IPv6/NBMA driver to trap 1771 multicast ICMPv6 packets carrying multicast ND or RD messages, and 1772 send them to the MARS itself for retransmission on ClusterControlVC 1773 (involving a trivial extension to the MARS itself.) This approach 1774 recognizes that in any LL where IPv6 multicasting is supported: 1776 - Nodes already have a pt-pt VC to their MARS. 1778 - The MARS has a pt-mpt VC (ClusterControlVC) out to all Cluster 1779 members (LL members registered for multicast support). 1781 Because the VCs between a MARS and its MARS clients carry LLC/SNAP 1782 encapsulated packets, ICMP packets can be multiplexed along with 1783 normal MARS control messages. In essence the MARS behaves as a 1784 multicast server for non-MARS packets that it receives from around 1785 the LL. 1787 As there is no requirement that a MARS client accepts only MARS 1788 control messages on ClusterControlVC, ICMP packets received in this 1789 fashion may be passed to every node's IP layer without further 1790 comment. Within the IP layer, filtering will occur based on the 1791 packet's actual destination IP address, and only the targeted node 1792 will end up responding. 1794 Regrettably this approach does result in the entire Cluster's 1795 membership having to receive a variety of ICMPv6 messages that they 1796 will always throw away. 1798 Appendix C. Flow detection 1800 The relationship between IPv6 packet flows, Quality of Service 1801 guarantees, and optimal use of underlying IP and NBMA network 1802 resources are still subjects of ongoing research in the IETF 1803 (specifically the ISSLL, RSVP, IPNG, and ION working groups). This 1804 document currently only describes the use of flow detection as a 1805 means to optimize the use of NBMA network resources through the 1806 establishment of inter-LL shortcuts. 1808 C.1. The use of non-zero FlowID to suppress flow detection 1810 For the purposes of this IPv6/NBMA architecture, a flow is: 1812 A related sequence of IPv6 packets that the first hop router is 1813 allowed to perform flow-detection on for the purposes of 1814 triggering shortcut discovery. 1816 How these packets are considered to be related to each other (e.g. 1817 through common header fields such as IPv6 destination addresses) is a 1818 local configuration issue. 1820 The flow-detection rule specifies that only packets with a zero 1821 FlowID can be considered as flows for which shortcut discovery may be 1822 triggered. The rationale behind this decision is: 1824 NBMA shortcuts are for the benefit of 'the network' optimizing its 1825 forwarding of IPv6 packets in the absence of any other guidance 1826 from the host. 1828 It is desirable for an IPv6/NBMA host to have some mechanism for 1829 overriding attempts by 'the network' to optimize its internal 1830 forwarding path. 1832 A zero FlowID has IPv6 semantics of "the source allows the network 1833 to utilize its own discretion in providing best-effort forwarding 1834 service for packets with zero FlowID" 1836 The IPv6 semantics of zero FlowID are consistent with the flow- 1837 detection rule in this document of "if the FlowID is zero, we are 1838 free to optimize the forwarding path using shortcuts" 1840 A non-zero FlowID has IPv6 semantics of "the source has previously 1841 established some preferred, end to end hop by hop forwarding 1842 behaviour for packets with this FlowID" 1844 The IPv6 semantics of non-zero FlowID are consistent with the 1845 flow-detection rule in this document of "if the FlowID is non- 1846 zero, do not attempt to impose a shortcut". 1848 A non-zero FlowID might be assigned by the source host after 1849 negotiating a preferred forwarding mechanism with 'the network' (e.g. 1850 through dynamic means such as RSVP, or administrative means). 1851 Alternatively it can simply be assigned randomly by the source host, 1852 and the network will provide default best effort forwarding (an IPv6 1853 router defaults to providing best-effort forwarding for packets whose 1854 FlowID/source-address pair is not recognized). 1856 Thus, the modes of operation supported by this document becomes: 1858 Zero FlowID 1859 Best effort forwarding, with optional shortcut discovery 1860 triggered through flow-detection. 1862 Non-zero FlowID 1863 Best effort forwarding if the routers along the path have not 1864 been otherwise configured with alternative processing rules for 1865 this FlowID/source-address pair. Flow detection relating to 1866 shortcut discovery is suspended. 1868 If the routers along the path have been configured with 1869 particular processing rules for this FlowID/source-address 1870 pair, the flow is handled according to those rules. Flow 1871 detection relating to shortcut discovery is suspended. 1873 Mechanisms for establishing particular per-hop processing rules for 1874 packets with non-zero FlowID are neither constrained by, nor implied 1875 by, this document. 1877 C.2. Future directions for Flow Detection 1879 In the future, accurate mapping of IPv6 flows onto NBMA VCs may 1880 require more information to be exchanged during the Neighbor 1881 Discovery process than is currently available in Neighbor Discovery 1882 packets. In these cases, the IPv6 Neighbor Discover protocols can be 1883 extended to include new TLV options (see section 4.6 of RFC 1790 1884 [7]). However, if new options are required, the specification of 1885 these options must be co-ordinated with the IPNG working group. Since 1886 RFC 1790 specifies that nodes must silently ignore options they do 1887 not understand, new options can be added at any time without breaking 1888 backward compatability with existing implementations. 1890 NHRP also provides mechanisms for adding optional TLVs to NHRP 1891 Requests and NHRP Replies. Future developments of this document's 1892 architecture will require consistent QoS extensions to both ND and 1893 NHRP in order to ensure they are semantically equivalent (syntactic 1894 differences are undesirable, but can be tolerated). 1896 Support for QoS on IPv6 unicast flows will not require further 1897 extensions to the existing MARS protocol. However, future support for 1898 QoS on IPv6 multicast flows may require extenions. MARS control 1899 messages share the same TLV extension mechanism as NHRP, allowing QoS 1900 extensions to be developed as needed.