idnits 2.17.1 draft-ietf-ion-ipv6nd-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack 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 148: '...ield in MARS messages SHALL be 0x86DD....' RFC 2119 keyword, line 154: '...ost starts up it SHALL issue a single ...' RFC 2119 keyword, line 168: '... MUST NOT cause MARS_JOIN or MARS_LE...' RFC 2119 keyword, line 181: '... - IPv6 mrouters SHALL perform a block...' RFC 2119 keyword, line 184: '... - They MUST NOT issue a block jo...' (15 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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? '1' on line 582 looks like a reference -- Missing reference section? '2' on line 585 looks like a reference -- Missing reference section? '3' on line 589 looks like a reference -- Missing reference section? '4' on line 593 looks like a reference -- Missing reference section? '5' on line 596 looks like a reference -- Missing reference section? '6' on line 600 looks like a reference -- Missing reference section? '7' on line 603 looks like a reference -- Missing reference section? '10' on line 614 looks like a reference -- Missing reference section? '11' on line 618 looks like a reference -- Missing reference section? '13' on line 625 looks like a reference -- Missing reference section? '0xAA-AA-03' on line 223 looks like a reference -- Missing reference section? '0x00-00-00' on line 206 looks like a reference -- Missing reference section? '0x08-06' on line 143 looks like a reference -- Missing reference section? '0x86-DD' on line 229 looks like a reference -- Missing reference section? '0x00-00-5E' on line 223 looks like a reference -- Missing reference section? '0x00-01' on line 223 looks like a reference -- Missing reference section? 'CMI' on line 229 looks like a reference -- Missing reference section? '9' on line 610 looks like a reference -- Missing reference section? 'Type' on line 345 looks like a reference -- Missing reference section? 'Length' on line 355 looks like a reference -- Missing reference section? 'NTL' on line 379 looks like a reference -- Missing reference section? 'STL' on line 377 looks like a reference -- Missing reference section? '8' on line 607 looks like a reference -- Missing reference section? '12' on line 621 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 1 warning (==), 26 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft Grenville Armitage 2 Bellcore 3 June 13th, 1996 5 IPv6 and Neighbor Discovery over ATM 6 8 Status of this Memo 10 This document was submitted to the IETF Internetworking over NBMA 11 (ION) WG. Publication of this document does not imply acceptance by 12 the ION WG of any ideas expressed within. Comments should be 13 submitted to the ion@nexen.com mailing list. 15 Distribution of this memo is unlimited. 17 This memo is an internet draft. Internet Drafts are working documents 18 of the Internet Engineering Task Force (IETF), its Areas, and its 19 Working Groups. Note that other groups may also distribute working 20 documents as Internet Drafts. 22 Internet Drafts are draft documents valid for a maximum of six 23 months. Internet Drafts may be updated, replaced, or obsoleted by 24 other documents at any time. It is not appropriate to use Internet 25 Drafts as reference material or to cite them other than as a "working 26 draft" or "work in progress". 28 To learn the current status of any Internet-Draft, please check the 29 "lid-abstracts.txt" listing contained in the Internet-Drafts shadow 30 directories on ds.internic.net (US East Coast), nic.nordu.net 31 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 32 Rim). 34 Abstract 36 This document attempts to describe and summarize some current 37 proposals for running IPv6 over ATM, and identifies open issues that 38 require resolution by one or more IETF working groups. The frame 39 formats for unicast and multicast transmission of IPv6 packets in a 40 UNI3.1 based ATM environment are specified. Some issues regarding the 41 construction of IPv6 link-local addresses are identified, and a 42 proposal made. A format for source and target link-layer address 43 options in Neighbor Discovery messages is suggested, and the 44 interactions between IPv6 Neighbor Discovery and existing IP over ATM 45 models are outlined. 47 This revision looks at the three models that were presented at the 48 Los Angeles IETF in March 1996, in a joint session of the IPATM, 49 IPNG, and ROLC working groups. No firm decisions were made at this 50 joint meeting. Readers are encouraged to locate and review the 51 Internet Drafts describing each model in greater detail. 53 Further discussion of the issues raised in this document is 54 requested, as not all questions are currently answered 55 satisfactorily. 57 Revision History 59 [This part to be removed when I-D is completed.] 61 June 1996, ION version 00. 62 Re-release of draft-ietf-ipatm-ipv6nd-02.txt as draft-ietf- 63 ion-ipv6nd-00.txt, after the merger of IPATM and ROLC into ION. 64 Retains a certain ATM-centricity which will be refined in later 65 releases. 67 April 1996, IPATM version 02. 68 Added further description of the orthogonal issues of interface 69 ID selection and the specification and identification of one's 70 Neighbor in an IPv6 sense. Pointers to all three models 71 presented at the March 1996 IETF. No firm consensus from this 72 meeting - most open issues are still open. 74 February 1996, IPATM version 01. 75 Re-write to deprecate some contentious suggestions issues, and 76 provides pointer to work being presented at the March 1996 IETF 77 meeting. 79 August 1995, IPATM version 00. 80 Poses the original question of how the IPng assumption of 81 'cheap' link level multicasting makes the IPng Neighbor 82 Discovery protocol hard to support when the underlying 83 technology is an ATM network. Suggests a straw-man model based 84 on MARS to identify its limitations. Solicits ideas from the 85 community. 87 1. Introduction. 89 This document deals with a number of issues associated with running 90 IPv6 [1] over UNI3.1 [2] based ATM services. These may be 91 characterised as: 93 - Packet framing and multicasting. 94 - Link Local address specification. 95 - Neighbor Discovery source/target link-layer address option. 96 - Interactions between ND and underlying IP/ATM architectures. 98 Packet framing is dealt with in section 2, applying the newly 99 assigned IPv6 Ethertype [3] to the encapsulation models developed for 100 IPv4 unicast [4] and multicast [5]. Section 2 will also note the 101 specific behaviour required of an IPv6-ATM interface when using the 102 MARS protocol defined in [5] to support IPv6 multicast over UNI3.1 103 ATM networks. 105 Section 3 outlines the requirements for the structure of IPv6 Link 106 Local addresses [6], and provides pointers to some current ideas on 107 the creation of link-local tokens. 109 The format of the source and target link-layer address options in 110 Neighbor Discovery [7] messages is described in section 4. 112 Section 5 summarizes the current discussion of how the IPv6 Neighbor 113 Discovery service and/or protocol may be applied to ATM environments. 114 Primarily it points to three models that were presented to the March 115 1996 IETF [10], [11], and [13]. 117 It is expected that the models in this document may be applied to a 118 wider community of NBMA networks, with suitable refinement of the 119 text. 121 [Editors note: Further discussion of the issues raised in this 122 document is requested on the ip-atm@nexen.com mailing list.] 124 2. Multicast support, and packet framing. 126 2.1 Using MARS for multicast support. 128 Multicasting is an integral part of IPv6. However, most NBMA networks 129 (and UNI3.0/3.1 based ATM networks in particular) do not provide 130 sufficient native multicast support to allow a trivial mapping. The 131 IP over ATM working group is nearing completion of a convergence 132 function, known as the 'MARS model' [5], which builds the required 133 multicast support using a point to multipoint VC service. A MARS 134 based IP/ATM device driver emulates link level multicast support for 135 the IP layer. 137 IPv4 is used as the main example in [5]. What follows are the main 138 changes required to use [5] for IPv6. 140 The encapsulation of MARS control messages (between MARS and MARS 141 Clients) remains the same: 143 [0xAA-AA-03][0x00-00-00][0x08-06][MARS control message] 144 (LLC) (OUI) (PID) 146 The mar$afn field in MARS messages remains 0x0F. 148 The mar$pro field in MARS messages SHALL be 0x86DD. 150 The mar$spln and mar$tpln fields (where relevant) are either 0 151 (for null or non-existent information) or 16 (for the full IPv6 152 protocol address). 154 When a host starts up it SHALL issue a single group MARS_JOIN for the 155 following groups: 157 - Its derived Solicited-node address(es) with link-local scope. 158 - The All-nodes address with link-local scope. 159 - Other multicast groups with at least link-local scope. 161 For example the IPv6 node with address 4037::01:800:200E:8C6C would 162 issue the following MARS_JOIN to register as a member of its 163 Solicited-Node multicast group: 165 MARS_JOIN(FF02::1:200E:8C6C, FF02::1:200E:8C6C) 167 Joining or leaving a multicast group with node-local scope (scope 1) 168 MUST NOT cause MARS_JOIN or MARS_LEAVE messages to be transmitted. 169 (The smallest scope managed by a MARS is scope 2 (link-local), and so 170 this is the smallest scope that MARS message are issued for.) 172 IPv6 mrouters may be considered to be built of two parts - a 173 forwarding engine, and an endpoint. The forwarding engine needs to be 174 listening promiscuously across all multicast groups that need 175 forwarding outside the link scope. The endpoint within a router needs 176 to listen only on specific groups that have scope of link-local or 177 larger. 179 To support the forwarding engine: 181 - IPv6 mrouters SHALL perform a block MARS_JOIN for the range(s) 182 of IPv6 multicast addresses they require each ATM interface to 183 listen on (described in section 9 of [5] for IPv4). 184 - They MUST NOT issue a block join for multicast addresses with 185 scope of 1 (node-local) or 2 (link-local). 187 To support any internal endpoints, IPv6 mrouters SHALL perform a 188 single group MARS_JOIN for the following groups: 190 - Their derived Solicited-node address(es). 191 - The All-nodes address with link-local scope. 192 - The All-routers address with link-local scope. 193 - Other multicast groups to which endpoints within the mrouter 194 belong with at least link-local scope. 196 It should be noted that the use of MARS for supporting the general 197 case of IPv6 multicasting is independent of how Neighbor Discovery is 198 implemented. This will be discussed further in section 5. 200 2.2 Unicast packet encapsulation. 202 The Ethertype assigned to IPv6 is 0x86DD [3]. Following the 203 convention of RFC1483 for IPv4 unicast transmissions, the default 204 encapsulation for a unicast IPv6 packet SHALL be: 206 [0xAA-AA-03][0x00-00-00][0x86-DD][IPv6 packet] 207 (LLC) (OUI) (PID) 209 Local administrators MAY choose to discard the LLC/SNAP encapsulation 210 and use 'VC multiplexing'. In this case an IPv6 packet is placed 211 directly into an AAL5 AAL_SDU. 213 An IP/ATM interface SHALL accept IPv6 packets whose IP destination 214 address is a multicast address, even if encapsulated as shown above. 215 It SHALL only transmit packets using the above encapsulation if the 216 IP destination is a unicast or anycast address. 218 2.3 Multicast packet encapsulation. 220 The encapsulation used for multicast IPv6 packets by MARS based 221 IP/ATM interfaces SHALL be: 223 [0xAA-AA-03][0x00-00-5E][0x00-01][CMI][0x86-DD][IPv6 packet] 224 (LLC) (OUI) (PID) 226 The 2 octet Cluster Member ID (CMI) field is defined in [5]. 228 Local administrators MAY choose to discard the LLC/SNAP encapsulation 229 and use 'VC multiplexing'. In this case the [CMI][0x86-DD][IPv6 230 packet] is placed directly into an AAL5 AAL_SDU. 232 An IP/ATM interface SHALL accept IPv6 packets whose IP destination 233 address is not a multicast address, even if encapsulated as shown 234 above. It SHALL only transmit packets using the above encapsulation 235 if the IP destination is a multicast address. 237 3. IPv6 Link-Local address. 239 IPv6 nodes are required to generate a unique Link-Local IPv6 address 240 for every link layer interface they have [6, 9]. Constructing these 241 addresses requires an interface ID (or link-local token) that is at 242 least unique amongst all the interfaces attached to the same link. 243 Routers are not allowed to forward packets with Link-Local 244 destinations, so it is not necessary for the interface ID to be 245 unique across multiple independent links. 247 3.1 A Logical Link Group. 249 The ATM environment complicates the sense of the word 'link' in much 250 the same way as it complicated the sense of 'subnet' in the IPv4 251 case. For IPv4 this required the definition of the Logical IP Subnet 252 (LIS) - an administratively constructed set of hosts that would share 253 the same routing prefixes (network and subnetwork masks). 255 For want of a better term this document considers the IPv6 analog to 256 be a Logical Link Group - LLG. 258 An LLG consists of nodes administratively configured to be 'on 259 link' with respect to each other. (This is described further in 260 section 5.1) 262 Sets of hosts that are members of the same MARS Cluster [5] SHALL be 263 taken from the membership of an LLG. (This is the analog of the 264 current restriction that an IPv4 MARS Cluster is constructed from the 265 multicast capable members of an LIS.) 267 It should be noted that whilst members of an LLG are IPv6 Neighbors, 268 its is possible for Neighbors to exist that are not, 269 administratively, members of the same LLG. This is discussed later in 270 this document. 272 3.2 Choice of Interface ID. 274 The choice of interface ID is a compromise. You need to uniquely 275 identify IPv6 interfaces that share the same Link, and a number space 276 large enough to keep down the probability of different IPv6 277 interfaces generating identical Link-Local addresses. On the other 278 hand, you want to keep the width (in bits) of the interface ID down 279 because it impinges on the number of bits remaining to use as routing 280 prefixes. It is preferable to choose the smallest unique identifier 281 possible to maximise our ability to build hierarchy into the routing 282 prefixes. 284 Using the model in section 3.1, the scope of uniqueness for a Link- 285 Local address is the LLG. 287 The IPv6 over Ethernet world suggests that a 48 bit interface ID is 288 large enough for uniqueness and small enough to leave a useful 289 routing prefix width. This 48 bit value is taken directly from the 48 290 bit MAC address associated with a node's Ethernet interface - each 291 Ethernet interface supporting a single IPv6 interface. 293 However, in the ATM environment we can find logical IP intefaces 294 layered over logical ATM interfaces, themselves layered over a single 295 physical ATM interface. If these logical IP interfaces are members of 296 the same IPv6 Link (e.g. virtual hosts on a single physical machine) 297 then each one needs a different interface ID in order to generate a 298 different Link-Local address. 300 This issue currently lacks a consensus solution. The previous version 301 of this ID proposed an oversized interface ID of 8 octets to cover 302 all the possible ATM based virtual interfaces. This has been 303 deprecated, but is described in Appendix A for reference. 305 Of the three Internet Drafts proposing solutions at the March 1996 306 IETF meeting, only Section 2 of [10] contained a concrete proposal 307 for generating interface IDs. The author's goal was to constrain the 308 interface ID to be 6 octets wide, equivalent to the width of 309 interface IDs on media such as Ethernet. A mechanism for generating 6 310 octet interface IDs is provided for the following cases: 312 - When a single IP interface is layered over a single ATM 313 interface, and an IEEE MAC address (or a unique ESI field from 314 an ATM Forum NSAP Address) uniquely identifies the ATM 315 interface. 316 - When a single IP interface is layered over a single ATM 317 interface, and an E.164 number uniquely identifies the ATM 318 interface. 320 The suggested mechanisms for Duplicate Address Detection, and 321 handling multiple logical IP interfaces per physical ATM interface, 322 are closely coupled to the authors' mechanism for Neighbor Discovery. 323 Readers should consider section 2 of [10] while bearing in mind that 324 at this stage there is no consensus on which ND approach is 325 appropriate, and that there was no discussion either way on 326 mechanisms for interface ID selection at the March 1996 meeting. This 327 is a good start, but still an open issue. 329 4. ND link-layer address options. 331 Neighbor Discovery defines two options for carrying link-layer 332 specific source and target addresses. In this case these options must 333 carry full ATM addresses. 335 The source and target link-layer address options must carry any one 336 of the three possibilities, and indicate which one it is. 338 The format for these two options when in an ATM environment is 339 adapted from the MARS [] and NHRP [] specs, and SHALL be: 341 [Type][Length][NTL][STL][..ATM Number..][..ATM Subaddress..] 343 | Fixed || Link layer address | 345 [Type] is a one octet field. 347 1 for Source link-layer address. 2 for Target link-layer address. 349 [Length] is a one octet field. 351 The total length of the option in multiples of 8 octets. Zeroed 352 bytes are added to the end of the option to ensure its length is a 353 multiple of 8 octets. (For example, a single ATM address in NSAPA 354 format would result in 24 bytes of real data, require no padding, 355 and result in [Length] being set to 3.) 357 [NTL] is a one octet 'Number Type & Length' field. 359 Defines the type and length of the ATM number immediately 360 following the [STL] field. The format is as follows: 362 7 6 5 4 3 2 1 0 363 +-+-+-+-+-+-+-+-+ 364 |0|x| length | 365 +-+-+-+-+-+-+-+-+ 367 The most significant bit is reserved and MUST be set to zero. The 368 second most significant bit (x) is a flag indicating whether the 369 ATM number is in: 371 ATM Forum NSAPA format (x = 0). 372 Native E.164 format (x = 1). 374 The bottom 6 bits is an unsigned integer value indicating the 375 length of the associated ATM address in octets. 377 The [STL] is a one octet 'Subaddress Type & Length' field. 379 Format is the same as the [NTL] field. Defines the length of the 380 subaddress field, if it exists. If it does not exist this entire 381 octet field MUST be zero. If the subaddress exists it will be in 382 NSAPA format, so flag x SHALL be zero. 384 [ATM Number] is a variable length field. It is always present. 386 [ATM Subaddress] is a variable length field. It may or may not be 387 present. When it is not, the option ends after the [ATM Number] (or 388 any additional padding for 8 byte alignment). 390 5. The wider implications of Neighbor Discovery. 392 The Neighbor Discovery protocol makes some assumptions about the 393 underlying link layer service that are not immediately applicable in 394 the ATM environment. ND assumes that multicast support is trivially 395 available from the IP/link-layer interface. It also makes no clear 396 statements about how 'cut through' unicast connections might be 397 achieved - a concept that has aquired some prominence in the IP over 398 ATM area through the development of NHRP [8] for IPv4 deployment. 400 As noted in section 2, multicast support needs to be emulated in UNI 401 3.0/3.1 environments. 403 The 'on-link/off-link' distinction for Neighbors might seem to lend 404 itself to a Classical IP model of IPv6 over ATM (where IPv6 405 interfaces would only use direct ATM connections between members of 406 their Logical Link Groups). However, as for IPv4, such administrative 407 boundaries need to be 'cut through' to provide maximal use of the 408 underlying ATM service. 410 A simplistic approach to ND would be to treat one's MARS based IP/ATM 411 interface as a black box that magically supports IP multicasting. The 412 ND protocol and service will then appear to 'work' as designed. A key 413 limitation is that there is no obvious way to achieve 'cut through' 414 connections. 416 5.1 Neighbor Discovery and 'cut through' routing. 418 IPv6 contains a concept of on-link and off-link. Neighbors are those 419 nodes that are considered on-link and whose link-layer addresses may 420 therefore be located using Neighbor Discovery. Borrowing from the 421 terminology definitions in the ND text: 423 on-link - an address that is assigned to a neighbor's interface on 424 a shared link. A host considers an address to be on-link 425 if: 426 - it is covered by one of the link's prefixes, or 427 - a neighboring router specifies the address as the 428 target of a Redirect message, or 429 - a Neighbor Advertisement message is received for the 430 target address, or 431 - a Router Advertisement message is received from the 432 address. 434 off-link - the opposite of "on-link"; an address that is not 435 assigned to any interfaces attached to a shared link. 437 Off-link nodes are considered to only be accessible through one of 438 the routers directly attached to the link. 440 The preceding descriptions may need refinement in the context of 441 Logical Link Groups (or equivalent concept). The LLG is the same set 442 of hosts that make up a given MARS Cluster - an administratively 443 defined group. These are an IPv6 interface's initial set of 444 neighbors, and each interface's Link-Local address only needs to be 445 unique amongst this set. 447 Events such as the receipt of ND advertisement messages, or the 448 operation of some alternative discovery protocol, may result in the 449 expansion of an IPv6 interface's set of Neighbors. However, this 450 should not be considered to have changed the set of interfaces that 451 make up its LLG. This approach leads to three possible relationships 452 between any two IPv6 interfaces: 454 - On LLG, Neighbor. 455 - Off LLG, Neighbor. 456 - Off LLG, not Neigbor. 458 Off LLG Neighors are the 'cut through' connections, where some 459 dynamic protocol activity has ascertained that although a target IPv6 460 interface is not a member of the source's LLG, it is possible to 461 achieve link level connectivity. 463 Whatever protocol we choose to locate IPv6 Neighbors should address 464 the following issues: 466 - How do you perform Duplicate Address Detection? 467 - How do you decide who is on or off link (or LLG)? 468 - ND allows the targetted Neighbor to return different link layer 469 addresses to every ND query. How do you retain this capability? 471 5.2 Solutions as of the March 1996 IETF. 473 There was no clear consensus on any one of the three ideas documented 474 in [10], [11], and [13]. What follows is a brief summary of each 475 proposal's salient points. Readers are encouraged to locate the 476 original (or subsequent) versions of these documents for more 477 specific details. (Subsequent versions are identified by a numerical 478 suffix higher than the ones listed here.) 480 5.2.1 draft-schulter-ipv6atm-framework-01.txt 482 The author builds upon the premise that the IPv6 stack's interaction 483 with an IP/ATM interface should be no different than its interaction 484 with something like an IP/Ethernet interface. This means that 485 Neighbor Discovery, as both a service and a protocol, should be run 486 unchanged. The underlying IP/ATM service itself is required to 487 perform certain special processing of ND messages to emulate the 488 required functionality. 490 The author uses Logical Link (LL) as an analog of the LLG. To solve 491 the need for multicasting ND messages around the LL, the author 492 introduces Neighbor Discovery Servers (NDSs - essentially a multicast 493 server for ND messages). A hierachy of NDSs is then constructed to 494 allow discovery messages to propagate outside an LL when necessary. 495 This provides the ability to establish 'cut through' connections by 496 discovering Off-LL neighbors. 498 Other IPv6 protocols, such as Router Discover, Duplicate Address 499 Detection, and autoconfiguration are also supported transparently by 500 the author's hierachy of NDSs. 502 The document currently makes no proposal for a mechanism to generate 503 unique Link Local addresses. 505 5.2.2 draft-ahl-ipv6-nbma-00.txt 506 (or draft-ietf-ion-ipv6-nbma-00.txt) 508 The authors propose solutions to both the discovery of Off LLG 509 Neighbors, and the generation of Link Local addresses. 511 A distinction is made between the ND service, and the ND protocol 512 defined in [7]. The authors bypass the ICMPv6 based ND protocol 513 itself, and provide a number of functional equivalents using 514 extensions to NHRP. As distinct from [11], this model implies that 515 IPv6 will perform ND according to [7] for some link technologies, and 516 delegate a number of ND services to the link layer interface for 517 other technologies such as NBMA networks. 519 The point is made that resolving next hops, and discovering 520 neighbors, amounts to the same thing. General NBMA environments do 521 not lend themselves to multicast based discovery mechanisms, so a 522 logical alternative is the client-server based NHRP. Some extensions 523 to NHRP are suggested in order for the NHRP client registration 524 process to provide duplicate address detection. 526 While NHRP is demonstrated to replace the use of ICMPv6 messages for 527 a number of ND services, the host protocol stack continues to process 528 and act on incoming ICMPv6 based ND messages (e.g. for Neighbor 529 Unreachability Detection, Redirects, etc). 531 5.2.3 draft-armitage-ipatm-tn-00.txt 532 (or draft-armitage-ion-tn-00.txt) 534 This document refines a proposal that the author presented in half- 535 baked form during the IETF itself. It attempts to synthesize a 536 solution for ND that utilizes parts of the NHRP model for discovering 537 neighbors outside one's LLG, and uses MARS emulation of multicast to 538 allow the ND protocol described in [7] to run without change within 539 an ATM based LLG. 541 The author postulates that egress routers from an LLG (which hosts 542 use in the absence of more direct information) are in a position to 543 detect the existence of IP traffic flows. Such flows are presumably 544 amenable to 'cut through'. The router generates a NHRP query in an 545 effort to establish a 'better' link level point to cut through to. 546 Once the query is resolved, the router multicasts an ND Redirect 547 message (containing the discovered ATM address) to the LLG from which 548 the traffic is originating. The source(s) of the traffic then have 549 the option of cutting over to the ATM destination supplied in the 550 Redirect message. These are considered to be Transient Neighbors. 552 Intra-LLG IPv6 Discovery services operate as defined in [7], and IPv6 553 hosts do not run NHRP to achieve cut-through. Identification of 554 suitable flows is considered an open issue. No proposal is made for 555 generating unique Link Local addresses. 557 Security Consideration 559 Security considerations are not addressed in this memo. 561 Acknowledgments 563 Sue Thomson (Bellcore) patiently answered my more inane questions 564 during the initial stages of version 00. Peter Schulter, Ran Atkins, 565 and others have ensured that the issues are being studied carefully 566 within the wider IETF environment. Unless noted otherwise, errors are 567 my own. 569 Author's address 571 Grenville Armitage 572 Internetworking Research Group, 573 Bellcore. 574 445 South Street 575 Morristown, NJ, 07960-6438 576 USA 578 Email: gja@bellcore.com 580 References. 582 [1] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) 583 Specification", RFC-1883, December 1995. 585 [2] ATM Forum, "ATM User Network Interface (UNI) Specification 586 Version 3.1", ISBN 0-13-393828-X, Prentice Hall, Englewood Cliffs, 587 NJ, June 1995. 589 [3] M. Crawford, A Method for the Tranmission of IPv6 Packets over 590 Ethernet Networks, INTERNET DRAFT, draft-ietf-ipngwg-ethernet- 591 ntwrks-02.txt, March 1996. 593 [4] J. Heinanen, "Multiprotocol Encapsulation over ATM Adaption Layer 594 5", RFC 1483, USC/Information Science Institute, July 1993. 596 [5] G.J. Armitage, "Support for Multicast over UNI 3.1 based ATM 597 Networks", INTERNET DRAFT, draft-ietf-ipatm-ipmc-12.txt, IP-over-ATM 598 WG, February 1996. 600 [6] S. Deering, R. Hinden, "IP Version 6 Addressing Architecture", 601 RFC-1884, December 1995. 603 [7] T. Narten, E. Nordmark, W.A. Simpson, "Neighbor Discovery for IP 604 Version 6 (IPv6)", INTERNET DRAFT, draft-ietf-ipngwg-discovery- 605 06.txt, March 1996. 607 [8] J. Luciani, et al, "NBMA Next Hop Resolution Protocol (NHRP)", 608 INTERNET DRAFT, draft-ietf-rolc-nhrp-08.txt, June 1996. 610 [9] S. Thomson, T. Nartin, "IPv6 Stateless Address 611 Autoconfiguration", INTERNET DRAFT, INTERNET DRAFT, draft-ietf- 612 addrconf-ipv6-auto-07.txt, December 1995. 614 [10] Randall Atkinson, Dimitry Haskin, James Luciani, "IPv6 over NBMA 615 Networks",INTERNET DRAFT, draft-ahl-ipv6-nbma-00.txt, February 1996. 616 (Or draft-ietf-ion-ipv6-nbma-00.txt, re-released June 1996) 618 [11] Peter Schulter, "A Framework for IPv6 Over ATM", INTERNET DRAFT, 619 draft-schulter-ipv6atm-framework-01.txt, February 1996. 621 [12] Robert Elz, "Identifying Interfaces in IPv6 link-local 622 addresses", INTERNET DRAFT, draft-ietf-ipngwg-iid-01.txt, February 623 1996. 625 [13] G. Armitage, "Transient Neighbors for IPv6 over ATM", INTERNET 626 DRAFT, draft-armitage-ipatm-tn-00.txt, April 1996. (Or draft- 627 armitage-ion-tn-00.txt, re-released June 1996) 629 Appendix A: A deprecated form of Interface ID generation. 631 [This text originally proposed an 8octet field, but has been modified 632 slightly to demonstrate the basic idea with a 7.5 octet field.] 634 An interface to an LLG is itself logical, and is supported by a 635 logical ATM interface. The ATM Forum allows three possible variations 636 of ATM addresses. These are: 638 - Native E.164 number. 639 - 20 byte ATM Forum NSAP format number. 640 - Native E.164 number with NSAP format subaddress. 642 When NSAP format addresses are in use, logical ATM interfaces are 643 constructed over physical ATM interfaces by using different SEL 644 within the context of a given ESI, or even having multiple ESIs route 645 to the same physical interface. When native E.164 addresses are in 646 use, each logical ATM interface requires its own E.164 number. 648 Therefore, the unique interface ID for the construction of Link-Local 649 IPv6 addresses could be 7.5 octets wide and be constructed in one of 650 two ways: 652 If the link interface has an NSAPA assigned, the 7 byte ESI+SEL 653 value of the logical ATM interface being used by the IPv6 node is 654 extracted and placed into the rightmost octets of the 7.5 octet 655 interface ID. The leftmost semi-octet is reserved and MUST be set 656 to zero. 658 If the link interface has only a native E.164 number assigned to 659 it then a 7.5 octet BCD encoded version of the E.164 number is 660 used to fill the field. The semi-octet value 1111 is used to pad 661 out the field in cases where the E.164 number was less than the 662 maximum 15 digits. 664 The Link-Local IPv6 address thus appears as: 666 | 10 | 667 | bits | 58 bits | 60 bits | 668 +----------+-------------------------+----------------------------+ 669 |1111111010| 0 | interface ID | 670 +----------+-------------------------+----------------------------+ 672 58 zero bits pad out the IPv6 address between the interface ID and 673 the 10 bit Link-Local prefix.