idnits 2.17.1 draft-ietf-ion-ipv6-fr-02.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-03-28) 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 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 == The page length should not exceed 58 lines per page, but there was 19 longer pages, the longest (page 2) being 59 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 5 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 105: '... The keywords MUST, MUST NOT, MAY, O...' RFC 2119 keyword, line 106: '... SHALL, SHALL NOT, SHOULD, SHOULD NO...' RFC 2119 keyword, line 220: '... messages MUST be done according to ...' RFC 2119 keyword, line 261: '...4 bit field that MAY hold a 10, 17, or...' RFC 2119 keyword, line 262: '...DLCI value which MUST be extended with...' (9 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 626 has weird spacing: '... Source link-...' == Line 652 has weird spacing: '...virtual circu...' == Line 668 has weird spacing: '...viewing this ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 1999) is 9204 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'ND' on line 437 looks like a reference -- Missing reference section? 'IND' on line 689 looks like a reference -- Missing reference section? 'IPv6-NBMA' on line 704 looks like a reference -- Missing reference section? 'IPv6-ATM' on line 695 looks like a reference -- Missing reference section? 'IPv6-ETH' on line 698 looks like a reference -- Missing reference section? 'IPv6-FDDI' on line 701 looks like a reference -- Missing reference section? 'IPv6-PPP' on line 710 looks like a reference -- Missing reference section? 'RFC 2119' on line 108 looks like a reference -- Missing reference section? 'IPv6' on line 692 looks like a reference -- Missing reference section? 'ENCAPS' on line 686 looks like a reference -- Missing reference section? 'ASSNUM' on line 678 looks like a reference -- Missing reference section? 'AARCH' on line 386 looks like a reference -- Missing reference section? 'AUTOCONF' on line 680 looks like a reference -- Missing reference section? 'E164' on line 728 looks like a reference -- Missing reference section? 'X25' on line 737 looks like a reference -- Missing reference section? 'NSAP' on line 732 looks like a reference -- Missing reference section? 'IPv6-ND' on line 707 looks like a reference -- Missing reference section? 'IPSEC' on line 716 looks like a reference -- Missing reference section? 'IPSEC-Auth' on line 719 looks like a reference -- Missing reference section? 'IPSEC-ESP' on line 722 looks like a reference -- Missing reference section? 'CANON' on line 683 looks like a reference -- Missing reference section? 'IPv6-TR' on line 713 looks like a reference -- Missing reference section? 'RFC2119' on line 725 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 25 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ION/IPng Working Group A. Conta 3 INTERNET-DRAFT (Lucent) 4 A. Malis 5 (Ascend) 6 M. Mueller 7 (Lucent) 8 January 1999 10 Transmission of IPv6 Packets over Frame Relay Networks 12 Specification 14 draft-ietf-ion-ipv6-fr-02.txt 16 Status of this Memo 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 To view the entire list of current Internet-Drafts, please check the 29 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 30 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 31 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 32 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 34 This Internet Draft expires in June 1999. 36 Abstract 38 This memo describes mechanisms for the transmission of IPv6 packets 39 over Frame Relay networks. 41 Table of Contents 43 1. Introduction......................................................3 44 2. Maximum Transmission Unit.........................................4 45 3. Frame Format......................................................5 46 4. Stateless Autoconfiguration.......................................6 47 4.1 Generating the MID field......................................8 48 5. Link-Local Address...............................................10 49 6. Address Mapping -- Unicast, Multicast............................10 50 7. Sending Neighbor Discovery Messages..............................15 51 8. Receiving Neighbor Discovery Messages............................16 52 9. Security Considerations..........................................16 53 10. Acknowledgments.................................................17 54 11. References......................................................17 55 12. Authors' Addresses..............................................20 56 1. Introduction 58 This document specifies the frame format for transmission of IPv6 59 packets over Frame Relay networks, the method of forming IPv6 link- 60 local addresses on Frame Relay links, and the mapping of the IPv6 61 addresses to Frame Relay addresses. It also specifies the content of 62 the Source/Target link-layer address option used in Neighbor 63 Discovery [ND] and Inverse Neighbor Discovery [IND] messages when 64 those messages are transmitted over a Frame Relay link. It is part 65 of a set of specifications that define such IPv6 mechanisms for Non 66 Broadcast Multi Access (NBMA) media [IPv6-NBMA], [IPv6-ATM], and a 67 larger set that defines such mechanisms for specific link layers 68 [IPv6-ETH], [IPv6-FDDI], [IPv6-PPP], [IPv6-ATM], etc... 70 The information in this document applies to Frame Relay devices which 71 serve as end stations (DTEs) on a public or private Frame Relay 72 network (for example, provided by a common carrier or PTT.) Frame 73 Relay end stations can be IPv6 hosts or routers. In this document 74 they are referred to as nodes. 76 In a Frame Relay network, a number of virtual circuits form the 77 connections between the attached stations (nodes). The resulting set 78 of interconnected devices forms a private Frame Relay group which may 79 be either fully interconnected with a complete "mesh" of virtual 80 circuits, or only partially interconnected. In either case, each 81 virtual circuit is uniquely identified at each Frame Relay interface 82 (card) by a Data Link Connection Identifier (DLCI). In most 83 circumstances, DLCIs have strictly local significance at each Frame 84 Relay interface. 86 A Frame Relay virtual circuit acts like a virtual-link (also referred 87 to as logical-link), with its own link parameters, distinct from the 88 parameters of other virtual circuits established on the same wire or 89 fiber. Such parameters are the input/output maximum frame size, 90 incoming/outgoing requested/agreed throughput, incoming/outgoing 91 acceptable throughput, incoming/outgoing burst size, 92 incoming/outgoing frame rate. 94 By default a DLCI is 10 bits in length. Frame Relay specifications 95 define also 16, 17, or 23 bit DLCIs. The former is not used, while 96 the latter two are suggested for use with SVCs. 98 Frame Relay virtual circuits can be created administratively as 99 Permanent Virtual Circuits -- PVCs -- or dynamically as Switched 100 Virtual Circuits -- SVCs. The mechanisms defined in this document 101 are intended to apply to both permanent and switched Frame Relay 102 virtual circuits, whether they are point to point or point to multi- 103 point. 105 The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, 106 SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as 107 defined in [RFC 2119]. 109 2. Maximum Transmission Unit 111 The IPv6 minimum MTU is defined in [IPv6]. 113 In general, Frame Relay devices are configured to have a maximum 114 frame size of at least 1600 octets. Therefore, the default IPv6 MTU 115 size for a Frame Relay interface is considered to be 1592. 117 A smaller than default frame size can be configured but of course not 118 smaller than the minimum IPv6 MTU. 120 An adequate larger than default IPv6 MTU and Frame Relay frame size 121 can be configured to avoid fragmentation. The maximum frame size is 122 controlled by the CRC generation mechanisms employed at the HDLC 123 level. CRC16 will protect frames up to 4096 bytes in length, which 124 reduces the effective maximum frame size to approximately 4088 bytes. 125 A larger desired frame size (such as that used by FDDI or Token 126 Ring), would require the CRC32 mechanism, which is not yet widely 127 used and is not mandatory for frame relay systems conforming to Frame 128 Relay Forum and ITU-T standards. 130 In general, if upper layers provide adequate error 131 protection/detection mechanisms, implementations may allow 132 configuring a Frame Relay link with a larger than 4080 octets frame 133 size but with a lesser error protection/detection mechanism at link 134 layer. However, because IPv6 relies on the upper and lower layer 135 error detection, configuring the IPv6 MTU to a value larger than 4080 136 is strongly discouraged. 138 Although a Frame Relay circuit allows the definition of distinct 139 maximum frame sizes for input and output, for simplification 140 purposes, this specification assumes symmetry, i.e. the same MTU for 141 both input and output. 143 Furthermore, implementations may limit the setting of the Frame Relay 144 maximum frame size to the interface (link, or card) level, which then 145 is enforced on all of the PVCs or SVCs on that interface (on that 146 link, or card). For an SVC, the maximum frame size parameter 147 negotiated during circuit setup will not exceed the configured 148 maximum frame size. 150 3. IPv6 Frame Format 152 The IPv6 frame encapsulation for Frame Relay (for both PVCs and SVCs) 153 follows [ENCAPS], which allows a VC to carry IPv6 packets along with 154 other protocol packets. The NLPID frame format is used, in which the 155 IPv6 NLPID has a value of 0x8E: 157 0 1 (Octets) 158 +-----------------------+-----------------------+ 159 (Octets)0 | | 160 / Q.922 Address / 161 / (length 'n' equals 2 or 4) / 162 | | 163 +-----------------------+-----------------------+ 164 n | Control (UI) 0x03 | NLPID 0x8E | NLPID 165 +-----------------------+-----------------------+ indicating 166 n+2 | . | IPv6 167 / . / 168 / IPv6 packet / 169 | . | 170 +-----------------------+-----------------------+ 171 | | 172 + FCS + 173 | | 174 +-----------------------+-----------------------+ 176 "n" is the length of the Q.922 address which can be 2 or 4 177 octets. 179 The Q.922 representation of a DLCI (in canonical order - the 180 first bit is stored in the least significant, i.e., the right- 181 most bit of a byte in memory) [CANON]is the following: 183 7 6 5 4 3 2 1 0 (bit order) 184 +-----+-----+-----+-----+-----+-----+-----+-----+ 185 (octet) 0 | DLCI(high order) | 0 | 0 | 186 +-----+-----+-----+-----+-----+-----+-----+-----+ 187 1 | DLCI(low order) | 0 | 0 | 0 | 1 | 188 +-----+-----+-----+-----+-----+-----+-----+-----+ 190 10 bits DLCI 191 7 6 5 4 3 2 1 0 (bit order) 192 +-----+-----+-----+-----+-----+-----+-----+-----+ 193 (octet) 0 | DLCI(high order) | 0 | 0 | 194 +-----+-----+-----+-----+-----+-----+-----+-----+ 195 1 | DLCI | 0 | 0 | 0 | 0 | 196 +-----+-----+-----+-----+-----+-----+-----+-----+ 197 2 | DLCI(low order) | 0 | 198 +-----+-----+-----+-----+-----+-----+-----+-----+ 199 3 | unused (set to 0) | 1 | 1 | 200 +-----+-----+-----+-----+-----+-----+-----+-----+ 202 17 bits DLCI 204 7 6 5 4 3 2 1 0 (bit order) 205 +-----+-----+-----+-----+-----+-----+-----+-----+ 206 (octet) 0 | DLCI(high order) | 0 | 0 | 207 +-----+-----+-----+-----+-----+-----+-----+----- 208 1 | DLCI | 0 | 0 | 0 | 0 | 209 +-----+-----+-----+-----+-----+-----+-----+-----+ 210 2 | DLCI | 0 | 211 +-----+-----+-----+-----+-----+-----+-----+-----+ 212 3 | DLCI (low order) | 0 | 1 | 213 +-----+-----+-----+-----+-----+-----+-----+-----+ 215 23 bits DLCI 217 The encapsulation of data or control messages exchanged by various 218 protocols that use SNAP encapsulation (with their own PIDs) is not 219 affected. The encoding of the IPv6 protocol identifier in such 220 messages MUST be done according to the specifications of those 221 protocols, and [ASSNUM]. 223 4. Stateless Autoconfiguration 225 An interface identifier [AARCH] for an IPv6 Frame Relay interface 226 must be unique on a Frame Relay link [AARCH], and must be unique on 227 each of the virtual links represented by the VCs terminated on the 228 interface. 230 The interface identifier for the Frame Relay interface is locally 231 generated by the IPv6 module. 233 Each virtual circuit in a Frame Relay network is uniquely identified 234 on a Frame Relay interface by a DLCI. Furthermore, a DLCI can be seen 235 as an identification of the end point of a virtual circuit on a Frame 236 Relay interface. Since each Frame Relay VC is configured or 237 established separately, and acts like an independent virtual-link 238 from other VCs in the network, or on the interface, link, wire or 239 fiber, it seems beneficial to view each VC's termination point on the 240 Frame Relay interface as a "pseudo-interface" or "logical-interface" 241 overlaid on the Frame Relay interface. Furthermore, it seems 242 beneficial to be able to generate and associate an IPv6 243 autoconfigured address (including an IPv6 link local address) to each 244 "pseudo-interface", i.e. end-point of a VC, i.e. to each DLCI on a 245 Frame Relay interface. 247 In order to achieve the benefits described above, the mechanisms 248 specified in this document suggest constructing the Frame Relay 249 interface identifier from 3 distinct fields (Fig.1): 251 (a) The "EUI bits" field. Bits 6 and 7 of the first octet, 252 representing the EUI-64 "universal/local" and respectively 253 "individual/group" bits converted to IPv6 use. The former is set 254 to zero to reflect that the 64 bit interface identifier value has 255 local significance [AARCH]. The latter is set to 0 to reflect the 256 unicast address [AARCH]. 258 (b) The "Mid" field. A 38 bit field which is generated with the 259 purpose of adding uniqueness to the interface identifier. 261 (c) The "DLCI" field. A 24 bit field that MAY hold a 10, 17, or 23 262 bit DLCI value which MUST be extended with 0's to 24 bits. A DLCI 263 based interface identifier -- which contains a valid DLCI -- 264 SHOULD be generated as a result of successfully establishing a VC 265 -- PVC or SVC. 267 If a DLCI is not known, the field MUST be set to the "unspecified 268 DLCI" value which consists of setting each of the 24 bits to 1. 270 Since DLCIs are local to a Frame Relay node, it is possible to have 271 Frame Relay distinct virtual circuits within a Frame Relay network 272 identified with the same DLCI values. 274 7 6 5 4 3 2 1 0 (bit order) 275 +-----+-----+-----+-----+-----+-----+-----+-----+ 276 (Octets) 0 | |"EUI bits" | 277 + +-----+-----+ 278 1 | | 279 + + 280 2 | "Mid" | 281 + + 282 3 | | 283 + + 284 4 | | 285 +-----+-----+-----+-----+-----+-----+-----+-----+ 286 5 | | 287 + + 288 6 | "DLCI" | 289 + + 290 7 | | 291 +-----+-----+-----+-----+-----+-----+-----+-----+ 293 Fig.1 Frame Relay Pseudo-Interface Identifier 295 The Duplicate Address Detection specified in [AUTOCONF] is used 296 repeatedly during the interface identifier and local-link address 297 generation process, until the generated identifier and consequently 298 the link-local address on the link -- VC -- are unique. 300 4.1 Generating the "Mid" field. 302 The "Mid" can be generated in multiple ways. This specification 303 suggests two mechanisms: 305 (b.1) "Use of Local Administrative Numbers" 307 The "Mid" is filled with the result of merging: 309 (b.1.1) A random number of 6 bits in length (Fig.2). 311 (b.1.2) The Frame Relay Node Identifier -- 16 bits -- is a user 312 administered value used to locally identify a Frame Relay 313 node (Fig.2). 315 (b.1.3) The Frame Relay Link Identifier -- 16 bits -- is a numerical 316 representation of the Frame Relay interface or link (Fig.2). 318 7 6 5 4 3 2 1 0 (bit order) 319 +-----+-----+-----+-----+-----+-----+-----+-----+ 320 (Octets) 0 | Random Number | MBZ | 321 +-----------------------------------+-----+-----+ 322 1 | | 323 + Frame Relay Node Identifier + 324 2 | | 325 +-----+-----+-----+-----+-----+-----+-----+-----+ 326 3 | | 327 + Frame Relay Link Identifier + 328 4 | | 329 +-----+-----+-----+-----+-----+-----+-----+-----+ 330 5 | | 331 + + 332 6 | "DLCI" | 333 + + 334 7 | | 335 +-----+-----+-----+-----+-----+-----+-----+-----+ 337 Fig.2 Frame Relay Pseudo-Interface Identifier 339 or, 341 (b.2) "Use of The Frame Relay address - E.164 [E164], X.121 342 [X25]numbers, or NSAP [NSAP] address" 344 If a Frame Relay interface has an E.164 or a X.121 number, or an 345 NSAP address, the "Mid" field MUST be filled in with a number 346 resulted from it as follows: the number represented by the BCD 347 encoding of the E.164 or X.121 number, or the binary encoding of 348 the NSAP address is truncated to 38 bits (Fig.3). Since the Frame 349 Relay interface identifier has a "local" significance, the use of 350 such a value has no real practical purposes other than adding to 351 the uniqueness of the interface identifier on the link. Therefore 352 the truncation can be performed on the high order or low order 353 bits. If the high order bits truncation does not provide 354 uniqueness on the link -- perhaps the DLCI value is not unique -- 355 this most likely means that the VC spans more for instance than a 356 national and/or international destination area for an E.164 357 number, and therefore the truncation of the low order bits should 358 be performed next, which most likely will provide the desired 359 uniqueness. 361 7 6 5 4 3 2 1 0 (bit order) 362 +-----+-----+-----+-----+-----+-----+-----+-----+ 363 (Octets) 0 | | MBZ | 364 + +-----+-----+ 365 1 | | 366 + E.164, X.121 (BCD encoding) + 367 2 | or NSAP Address | 368 + + 369 3 | (truncated to 38 bits) | 370 + + 371 4 | | 372 +-----+-----+-----+-----+-----+-----+-----+-----+ 373 5 | | 374 + + 375 6 | "DLCI" | 376 + + 377 7 | | 378 +-----+-----+-----+-----+-----+-----+-----+-----+ 380 Fig.3 Frame Relay (Pseudo) Interface Identifier 382 5. Link-Local Addresses 384 The IPv6 link-local address [AARCH] for an IPv6 Frame Relay interface 385 is formed by appending the interface identifier, formed as defined 386 above, to the prefix FE80::/64 [AARCH]. 388 10 bits 54 bits 64 bits 389 +----------+-----------------------+----------------------------+ 390 |1111111010| (zeros) |Frame Relay Interface Ident.| 391 +----------+-----------------------+----------------------------+ 393 6. Address Mapping -- Unicast, Multicast 395 The procedure for mapping IPv6 addresses to link-layer addresses is 396 described in [IPv6-ND]. Additionally, extensions to Neighbor 397 Discovery (ND) that allow the mapping of link-layer addresses to IPv6 398 addresses are defined as Inverse Neighbor Discovery (IND) in [IND]. 399 This document defines the formats of the link-layer address fields 400 used by ND and IND. This specification does not define an algorithmic 401 mapping of IPv6 multicast addresses to Frame Relay link-layer 402 addresses. 404 The Source/Target Link-layer Address option used in Neighbor 405 Discovery and Inverse Neighbor Discovery messages for a Frame Relay 406 link follows the general rules defined by [IPv6-ND]. IPv6 addresses 407 can map two type of identifiers equivalent to link-layer addresses: 408 DLCIs, and Frame Relay Addresses. Therefore, for Frame Relay, this 409 document defines two distinct formats for the ND and IND messages 410 Link-Layer Address field: 412 (a) DLCI Format -- used in ND and/or IND messages on VCs that were 413 established prior to the ND or IND message exchange -- mostly 414 PVCs. The use on SVCs makes sense with Inverse Neighbor 415 Discovery [IND] messages if IND is employed after the successful 416 establishing of an SVC to gather information about other IPv6 417 addresses assigned to the remote node and that SVC. 419 (b) Frame Relay Address Format -- used mostly prior to establishing 420 a new SVC, to get the Frame Relay remote node identifier 421 (link-layer address) mapping to a certain IPv6 address. 423 Note: An implementation may hold both types of link layer 424 identifiers in the Neighbor Discovery cache. Additionally, in case 425 of multiple VCs between two nodes, one node's Neighbor Discovery 426 cache may hold a mapping of one of the remote node's IPv6 427 addresses to each and every DLCI identifying the VCs. 429 The mechanisms which in such an implementation would make the 430 distinction between the Neighbor Discovery Cache mapping of an 431 IPv6 address to a "Frame Relay Address Format" and a "DLCI Format" 432 link-layer address, or among several mappings to a "DLCI Format" 433 addresses are beyond the scope of this specification. 435 The use of the override "O" bit in the advertisement messages that 436 contain the above Link-Layer Address formats SHOULD be consistent 437 with the [ND] specifications. Additionally, there should be 438 consistency related to the type of Link-Layer Address format: an 439 implementation should override one address format in its Neighbor 440 Discovery cache with the same type of address format. 442 The "DLCI Format" is defined as follows: 444 7 6 5 4 3 2 1 0 (bit order) 445 +-----+-----+-----+-----+-----+-----+-----+-----+ 446 0 | Type | 447 +-----+-----+-----+-----+-----+-----+-----+-----+ 448 1 | Length | 449 +-----+-----+-----+-----+-----+-----+-----+-----+ 450 with a DLCI (Q.922 address) encoded as option value: 452 7 6 5 4 3 2 1 0 (bit order) 453 +-----+-----+-----+-----+-----+-----+-----+-----+ 454 2 | | 1 | 1 | 455 + unused +-----+-----+ 456 3 | | 457 +-----+-----+-----+-----+-----+-----+-----+-----+ 458 4 | DLCI(high order) | 0 | 0 | 459 +-----+-----+-----+-----+-----+-----+-----+-----+ 460 5 | DLCI(low order) | 0 | 0 | 0 | 1 | 461 +-----+-----+-----+-----+-----+-----+-----+-----+ 462 6 | | 463 + Padding + 464 7 | (zeros) | 465 +-----+-----+-----+-----+-----+-----+-----+-----+ 467 10 bits DLCI 469 7 6 5 4 3 2 1 0 (bit order) 470 +-----+-----+-----+-----+-----+-----+-----+-----+ 471 2 | | 1 | 1 | 472 + unused +-----+-----+ 473 3 | | 474 +-----+-----+-----+-----+-----+-----+-----+-----+ 475 4 | DLCI(high order) | 0 | 0 | 476 +-----+-----+-----+-----+-----+-----+-----+-----+ 477 5 | DLCI | 0 | 0 | 0 | 0 | 478 +-----+-----+-----+-----+-----+-----+-----+-----+ 479 6 | DLCI(low order) | 0 | 480 +-----+-----+-----+-----+-----+-----+-----+-----+ 481 7 | unused (set to 0) | 1 | 1 | 482 +-----+-----+-----+-----+-----+-----+-----+-----+ 484 17 bits DLCI 485 7 6 5 4 3 2 1 0 (bit order) 486 +-----+-----+-----+-----+-----+-----+-----+-----+ 487 2 | | 1 | 1 | 488 + unused +-----+-----+ 489 3 | | 490 +-----+-----+-----+-----+-----+-----+-----+-----+ 491 4 | DLCI(high order) | 0 | 0 | 492 +-----+-----+-----+-----+-----+-----+-----+----- 493 5 | DLCI | 0 | 0 | 0 | 0 | 494 +-----+-----+-----+-----+-----+-----+-----+-----+ 495 6 | DLCI | 0 | 496 +-----+-----+-----+-----+-----+-----+-----+-----+ 497 7 | DLCI (low order) | 0 | 1 | 498 +-----+-----+-----+-----+-----+-----+-----+-----+ 500 23 bits DLCI 502 Option fields: 504 Type 1 for Source Link-layer address. 505 2 for Target Link-layer address. 507 Length The Length of the Option (including the Type 508 and Length fields) in units of 8 octets. 509 It has the value 1. 511 Link-Layer Address The DLCI encoded as a Q.922 address. 513 Description 515 The "DLCI Format" option value field has two components: 517 (a) Address Type -- encoded in the first two bits of the first 518 two octets. Both bits are set to 1 to indicate the DLCI 519 format. The rest of the bits in the two first octets are 520 not used -- they MUST be set to zero on transmit and MUST 521 be ignored by the receiver. 523 (b) DLCI -- encoded as a Q.922 address padded with zeros to the 524 last octet of the 6 octets available for the entire Link- 525 Layer Address field of this format. 527 The "Frame Relay Address Format" is defined as follows: 529 7 6 5 4 3 2 1 0 (bit order) 530 +-----+-----+-----+-----+-----+-----+-----+-----+ 531 0 | Type | 532 +-----+-----+-----+-----+-----+-----+-----+-----+ 533 1 | Length | 534 +-----+-----+-----+-----+-----+-----+-----+-----+ 536 with an E.164, X.121, number or NSAP address encoded as option 537 value: 539 7 6 5 4 3 2 1 0 (bit order) 540 +-----+-----+-----+-----+-----+-----+-----+-----+ 541 2 | size | 1 | 0 | 542 +-----+-----+-----+-----+-----+-----+-----+-----+ 543 3 | E.164 or X.121, or NSAP | 544 +--- Address Family Number ---+ 545 4 | (Assigned Number) | 546 +-----+-----+-----+-----+-----+-----+-----+-----+ 547 5 | | 548 / E.164, or X.121 number (BCD encoded) / 549 / or NSAP address / 550 4+size | | 551 +-----+-----+-----+-----+-----+-----+-----+-----+ 552 5+size | | 553 / Padding / 554 / (zeros) / 555 8*Length-1| | 556 +-----+-----+-----+-----+-----+-----+-----+-----+ 558 Option fields: 560 Type 1 for Source Link-layer address. 561 2 for Target Link-layer address. 563 Length The length of the Option (including the 564 Type and Length fields) in units of 8 octet. 565 It may have the value: 567 2 -- for E.164, or X.121 numbers or NSAP 568 addresses not longer than 11 octets 569 [E164], [X25], [NSAP]. 571 3 -- for NSAP addresses longer than 11 but 572 not longer than 19 octets. 574 4 -- for NSAP addresses longer than 19 octets 575 (not longer than the maximum NSAP address 576 length) [NSAP]. 578 Link-Layer Address The E.164, X.121, number encoded in 579 Binary Coded Decimal (BCD), or the NSAP 580 address. 582 Description 584 The "Frame Relay Address" option value has three components: 586 (a) Address Type -- encoded in the first two bits of the first 587 octet. The first bit is set to 0, the second bit is set to 1. 589 (b) Size -- encoded in the last (high order) 6 bits of the first 590 octet. The maximum value of the field is the maximum size of 591 the E.164, X.121, or NSAP addresses. 593 (c) Address Family Number -- the number assigned for the E.164, 594 X.121, or NSAP address family [ASSNUM]. 596 (d) E.164, X.121, number -- encoded in BCD (two digits per octet). 597 If the E.164, or X.121 has an even number of digits the 598 encoding will fill all encoding octets -- half the number of 599 digits. If the E.164, or X.121 number has an odd number of 600 digits, the lowest order digit fills only half of an octet -- 601 it is placed in the first 4 bits of the last octet of the 602 E.164, or X.121 BCD encoding. The rest of the field up to the 603 last octet of the 11 octets available is padded with zeros. 605 NSAP address -- the NSAP address. It is padded with zeros if 606 the NSAP address does not fit in a number of octets that makes 607 the length of the option an even number of 8 octets. 609 7. Sending Neighbor Discovery Messages 611 Frame Relay networks do not provide link-layer native multicasting 612 mechanisms. For the correct functioning of the Neighbor Discovery 613 mechanisms, link-layer multicasting must be emulated. 615 To emulate multicasting for Neighbor Discovery (ND) the node MUST 616 send frames carrying ND multicast packets to all VCs on a Frame Relay 617 interface. This applies to ND messages addressed to both all-node and 618 solicited-node multicast addresses. This method works well with PVCs. 619 A mesh of PVCs MAY be configured and dedicated to multicast traffic 620 only. An alternative to a mesh of PVCs is a set of point-to- 621 multipoint PVCs. 623 8. Receiving Neighbor Discovery Messages 625 If a Neighbor Discovery Solicitation message received by a node 626 contains the Source link-layer address option with a DLCI, the 627 message MUST undergo Frame Relay specific preprocessing required for 628 the correct interpretation of the field during the ND protocol engine 629 processing. This processing is done before the Neighbor Discovery 630 message is processed by the Neighbor Discovery (ND) protocol engine. 632 The motivation for this processing is the local significance of the 633 DLCI fields in the Neighbor Discovery message: the DLCI significance 634 at the sender node is different than the DLCI significance at the 635 receiver node. In other words, the DLCI that identifies the Frame 636 Relay virtual circuit at the sender may be different than the DLCI 637 that identifies the virtual circuit at the receiver node. 638 Furthermore, the sender node may not be aware of the DLCI value at 639 the receiver. Therefore, the Frame Relay specific preprocessing 640 consists in modifying the Neighbor Discovery Solicitation message 641 received, by storing into the Source link-layer address option the 642 DLCI value of the virtual circuit on which the frame was received, as 643 known to the receiver node. The DLCI value being stored must be 644 encoded in the appropriate format (see previous sections). The 645 passing of the DLCI value from the Frame Relay module to the Neighbor 646 Discovery preprocessing module is an implementation choice. 648 9. Security Considerations 650 The mechanisms defined in this document for generating an IPv6 Frame 651 Relay interface identifier are intended to provide uniqueness at link 652 level -- virtual circuit. The protection against duplication is 653 achieved by way of IPv6 Stateless Autoconfiguration Duplicate Address 654 Detection mechanisms. Security protection against forgery or accident 655 at the level of the mechanisms described here is provided by the IPv6 656 security mechanisms [IPSEC], [IPSEC-Auth], [IPSEC-ESP] applied to 657 Neighbor Discovery [IPv6-ND] or Inverse Neighbor Discovery [IND] 658 messages. 660 To avoid an IPsec Authentication verification failure, the Frame 661 Relay specific preprocessing of a Neighbor Discovery Solicitation 662 message that contains a DLCI format Source link-layer address option, 663 MUST be done by the receiver node after it completed IP Security 664 processing. 666 10.Acknowledgments 668 Thanks to D. Harrington, and M. Merhar for reviewing this document 669 and providing useful suggestions. Also thanks to G. Armitage for his 670 reviewing and suggestions. Many thanks also to Thomas Narten for 671 suggestions on improving the document. 673 11.References 675 [AARCH]R. Hinden, S. Deering "IPv6 Addressing Architecture", RFC2373, 676 July 1998. 678 [ASSNUM] J. Postel "Assigned Numbers", RFC 1700. 680 [AUTOCONF] S. Thomson, T. Narten "IPv6 Stateless Autoconfiguration", 681 RFC 2462, December 1998. 683 [CANON] T. Narten, C. Burton "A Caution on the Canonical Ordering of 684 Link-Layer Addresses", RFC 2469, December 1998. 686 [ENCAPS] C. Brown, A. Malis, "Multiprotocol Interconnect over Frame 687 Relay", RFC 2427, November 1998. 689 [IND] A. Conta, "Extensions to IPv6 Neighbor Discovery for Inverse 690 Discovery", Work in progress, December 1998. 692 [IPv6] S. Deering, R. Hinden, "Internet Protocol Version 6 693 Specification", RFC 2460, December 1998. 695 [IPv6-ATM] G. Armitage, P. Schulter, M. York, G. Harter, "IPv6 over 696 ATM Networks", Work in progress, October 1998. 698 [IPv6-ETH] M. Crowford "Transmission of IPv6 packets over Ethernet 699 Networks", RFC 2464, December 1998. 701 [IPv6-FDDI] M. Crowford "Transmission of IPv6 packets over FDDI 702 Networks", RFC 2467, December 1998. 704 [IPv6-NBMA] G. Armitage, P. Schulter, M. York, G. Harter, "IPv6 over 705 NBMA networks", Work in progress, March 1998. 707 [IPv6-ND] T. Narten, E. Nordmark, W.Simpson "Neighbor Discovery for 708 IP Version 6 (IPv6)", RFC 2461, December 1998. 710 [IPv6-PPP] D. Haskin, E. Allen, "IP Version 6 over PPP", RFC 2472, 711 December 1998. 713 [IPv6-TR] T. Narten, M. Crowford, M. Thomas "Transmission of IPv6 714 packets over Token Ring Networks", RFC 2470, December 1998. 716 [IPSEC] Atkinson, R., S. Kent, "Security Architecture for the 717 Internet Protocol", RFC 2401, November 1998. 719 [IPSEC-Auth] Atkinson, R., S. Kent, "IP Authentication Header", RFC 720 2402, December 1998. 722 [IPSEC-ESP] Atkinson, R., S. Kent, "IP Encapsulating Security 723 Protocol (ESP)", RFC 2406, November 1998. 725 [RFC2119] S. Bradner "Key words for use in RFCs to indicate 726 Requirement Levels", RFC 2119. 728 [E164] International Telecommunication Union - "Telephone Network and 729 ISDN Operation, Numbering, Routing, amd Mobile Service", ITU-T 730 Recommendation E.164, 1991. 732 [NSAP] ISO/IEC, "Information Processing Systems -- Data 733 Communications -- Network Service Definition Addendum 2: Network 734 Layer Addressing". International Standard 8348/Addendum 2, ISO/IEC 735 JTC 1, Switzerland 1988. 737 [X25] "Information Technology -- Data Communications -- X.25 Packet 738 Layer Protocol for Data Terminal Equipment", International Standard 739 8208, March 1988. 741 12.Authors' Addresses 743 Alex Conta 744 Lucent Technologies Inc. 745 300 Baker Ave, Suite 100 746 Concord, MA 01742 747 +1-978-287-2842 748 email: aconta@lucent.com 750 Andrew Malis 751 Ascend Communications 752 1 Robbins Rd 753 Westford, MA 01886 754 +1-978-952-7414 755 email: malis@ascend.com 757 Martin Mueller 758 Lucent Technologies Inc. 759 300 Baker Ave, Suite 100 760 Concord, MA 01742 761 +1-978-287-2833 762 email: memueller@lucent.com 763 1180