idnits 2.17.1 draft-ietf-ion-ipv6-atm-03.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-23) 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Since ATM PVC links do not use link-layer addresses, the link-layer address options SHOULD not be included in any ND message [11]. If a link-layer address option is present in an ND message, then the option SHOULD be ignored. -- 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 (October 17, 1998) is 9320 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? '1' on line 441 looks like a reference -- Missing reference section? '16' on line 70 looks like a reference -- Missing reference section? '11' on line 472 looks like a reference -- Missing reference section? '2' on line 445 looks like a reference -- Missing reference section? '0xAA-AA-03' on line 211 looks like a reference -- Missing reference section? '0x00-00-00' on line 149 looks like a reference -- Missing reference section? '0x86-DD' on line 149 looks like a reference -- Missing reference section? '7' on line 460 looks like a reference -- Missing reference section? '0x00-00-5E' on line 211 looks like a reference -- Missing reference section? '0x00-01' on line 157 looks like a reference -- Missing reference section? '0x86DD' on line 157 looks like a reference -- Missing reference section? '3' on line 448 looks like a reference -- Missing reference section? '0x00-03' on line 211 looks like a reference -- Missing reference section? '4' on line 451 looks like a reference -- Missing reference section? 'NTL' on line 253 looks like a reference -- Missing reference section? 'STL' on line 253 looks like a reference -- Missing reference section? '6' on line 457 looks like a reference -- Missing reference section? '9' on line 466 looks like a reference -- Missing reference section? '8' on line 463 looks like a reference -- Missing reference section? '0x00' on line 300 looks like a reference -- Missing reference section? 'ESI' on line 305 looks like a reference -- Missing reference section? 'SEL' on line 310 looks like a reference -- Missing reference section? '5' on line 454 looks like a reference -- Missing reference section? '10' on line 470 looks like a reference -- Missing reference section? 'D14' on line 344 looks like a reference -- Missing reference section? 'D13D12' on line 350 looks like a reference -- Missing reference section? 'D11D10' on line 356 looks like a reference -- Missing reference section? 'D9D8' on line 342 looks like a reference -- Missing reference section? 'D9D6' on line 342 looks like a reference -- Missing reference section? 'D5D4' on line 342 looks like a reference -- Missing reference section? 'D3D2' on line 342 looks like a reference -- Missing reference section? 'D1D0' on line 356 looks like a reference -- Missing reference section? 'D13' on line 351 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 35 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 BrightTiger Technologies 6 Markus Jork 7 Compaq 8 October 17, 1998 10 IPv6 over ATM 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@sunroof.eng.sun.com mailing list. 20 Distribution of this memo is unlimited. 22 This memo is an internet draft. Internet Drafts are working 23 documents of the Internet Engineering Task Force (IETF), its Areas, 24 and its Working Groups. Note that other groups may also distribute 25 working 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 31 "working 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 ftp.ietf.org (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 is a companion to the ION working group's architecture 42 document 'IPv6 over Non Broadcast Multiple Access (NBMA) networks'. 43 It provides specific details on how to apply the IPv6 over NBMA 44 architecture to ATM networks. This architecture allows conventional 45 host-side operation of the IPv6 Neighbor Discovery protocol, while 46 also supporting the establishment of 'shortcut' ATM forwarding paths 47 (when using SVCs). Operation over administratively configured Point 48 to Point PVCs is also supported. 50 1. Introduction. 52 This document is an ATM-specific companion document to the ION 53 working group's "IPv6 over Non Broadcast Multiple Access (NBMA) 54 networks" specification [1]. Terminology and architectural 55 descriptions will not be repeated here. 57 The use of ATM to provide point to point PVC service, or flexible 58 point to point and point to multipoint SVC service, is covered by 59 this document. 61 A minimally conforming IPv6/ATM driver SHALL support the PVC mode of 62 operation. An IPv6/ATM driver that supports the full SVC mode SHALL 63 also support PVC mode of operation. 65 2. Specification Terminology 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 69 this document are to be interpreted as described in RFC 2119 [16]. 71 3. PVC Environments 73 When the ATM network is used in PVC mode, each PVC will connect 74 exactly two nodes and the use of Neighbor Discovery and other IPv6 75 features is limited. IPv6/ATM interfaces have only one neighbor on 76 each Link. The MARS and NHRP protocols are NOT necessary, since 77 multicast and broadcast operations collapse down to an ATM level 78 unicast operation. Dynamically discovered shortcuts are not 79 supported. 81 The actual details of encapsulations, MTU, and link token generation 82 are provided in the following sections. 84 This use of PVC links does not mandate, nor does it prohibit the use 85 of extensions to the Neighbor Discovery protocol which may be 86 developed for either general use of for use in PVC connections (for 87 example, Inverse Neighbor Discovery). 89 Since ATM PVC links do not use link-layer addresses, the link-layer 90 address options SHOULD not be included in any ND message [11]. If a 91 link-layer address option is present in an ND message, then the 92 option SHOULD be ignored. 94 A minimally conforming IPv6/ATM driver SHALL support the PVC mode of 95 operation. PVC only implementations are not required to support any 96 SVC mode of operation. 98 3.1 Default Packet Encapsulation 100 Following the model in RFC 1483 [2], AAL5 SHALL be the default 101 Adaptation Layer service, and (LLC/SNAP) encapsulation SHALL be 102 default encapsulation used by unicast and multicast packets across 103 pt-pt PVC links. As defined in [1], the default IPv6 packet 104 encapsulation SHALL be: 106 [0xAA-AA-03][0x00-00-00][0x86-DD][IPv6 packet] 107 (LLC) (OUI) (PID) 109 3.2 Optional null encapsulation 111 IPv6/ATM drivers MAY also support null encapsulation as a 112 configurable option. When null encapsulation is enabled, the IPv6 113 packet is passed directly to the AAL5 layer. Both ends of the PVC 114 MUST be configured to use null encapsulation. The PVC will not be 115 available for use by protocols other than IPv6. 117 3.3 PPP encapsulation 119 The concatentation of IPv6 over PPP with PPP over AAL5 PVCs is not 120 covered by this specification. 122 3.4 MTU For PVC Environments 124 The default IP MTU size for PVC links is 9180 bytes as specified in 125 [7]. Other IP MTU values MAY be used. 127 3.5 Interface Token Formats in PVC Environments 129 When the ATM network is used in PVC mode interface tokens SHALL be 130 generated using one of the methods described in section 5. Interface 131 tokens need only be unique between the two nodes on the PVC link. 133 4 SVC environments 135 4.1 SVC Specific Code Points 137 4.1.1 ATM Adaptation Layer encapsulation for SVC environments 139 Following the model in RFC 1483 [2], AAL5 SHALL be the default 140 Adaptation Layer service, and (LLC/SNAP) encapsulation SHALL be the 141 default encapsulation used by unicast and multicast packets across 142 SVC links. 144 4.1.2 Unicast Packet Encapsulation 146 As defined in [1], the default IPv6 unicast packet encapsulation 147 SHALL be: 149 [0xAA-AA-03][0x00-00-00][0x86-DD][IPv6 packet] 150 (LLC) (OUI) (PID) 152 4.1.3 Multicast packet encapsulation 154 As defined in [1], the default IPv6 multicast packet encapsulation 155 SHALL be: 157 [0xAA-AA-03][0x00-00-5E][0x00-01][pkt$cmi][0x86DD][IPv6 158 packet] 159 (LLC) (OUI) (PID) (mars encaps) 161 The IPv6/ATM driver's Cluster Member ID SHALL be copied into 162 the 2 octet pkt$cmi field prior to transmission. 164 4.1.4 Optional null encapsulation 166 IPv6/ATM drivers MAY also support null encapsulation as a 167 configurable option. Null encapsulation SHALL only be used for 168 passing IPv6 packets from one IPv6/ATM driver to another. Null 169 encapsulation SHALL NOT be used on the pt-pt SVC between the 170 IPv6/ATM driver and its local MARS. 172 If null encapsulation is enabled, the IPv6 packet is passed directly 173 to the AAL5 layer. Both ends of the SVC MUST agree to use null 174 encapsulation during the call SETUP phase. The SVC will not be 175 available for use by protocols other than IPv6. 177 If null encapsulation is enabled on data SVCs between routers, 178 inter-router NHRP traffic SHALL utilize a separate, parallel SVC. 180 Use of null encapsulation is not encouraged when IPv6/ATM is used 181 with MARS/NHRP/ND as described in [1]. 183 4.1.5 MARS control messages 185 The encapsulation of MARS control messages (between MARS and MARS 186 Clients) remains the same as shown in RFC 2022 [3]: 188 [0xAA-AA-03][0x00-00-5E][0x00-03][MARS control message] 189 (LLC) (OUI) (PID) 191 The key control field values are: 193 The mar$afn field remains 0x0F (ATM addresses) 195 The mar$pro field SHALL be 0x86DD (IPv6) 197 The mar$op.version field remains 0x00 (MARS) 199 The mar$spln and mar$tpln fields (where relevant) are either 0 (for 200 null or non-existent information) or 16 (for the full IPv6 protocol 201 address) 203 The way in which ATM addresses are stored remains the same as shown 204 in RFC 2022 [3] 206 4.1.6 NHRP control messages 208 The encapsulation of NHRP control messages remains the same as shown 209 in RFC 2332 [4]: 211 [0xAA-AA-03][0x00-00-5E][0x00-03][NHRP control message] 212 (LLC) (OUI) (PID) 214 The key control field values are: 216 The ar$afn field remains 0x0F (ATM addresses) 218 The ar$pro field SHALL be 0x86DD (IPv6) 220 The ar$op.version field remains 0x01 (NHRP) 222 The ar$spln and ar$tpln fields (where relevant) are either 0 (for 223 null or non-existent information) or 16 (for the full IPv6 protocol 224 address) 226 The way in which ATM addresses are stored remains the same as shown 227 in RFC 2022 [3] 229 4.1.7 Neigbor Discovery control messages 231 Section 5.2 of [1] describes the ND Link-layer address option. For 232 IPv6/ATM drivers, the subfields SHALL be encoded in the following 233 manner: 235 [NTL] defines the type and length of the ATM number immediately 236 following the [STL] field. The format is as follows: 238 7 6 5 4 3 2 1 0 239 +-+-+-+-+-+-+-+-+ 240 |0|x| length | 241 +-+-+-+-+-+-+-+-+ 243 The most significant bit is reserved and MUST be set to zero. 244 The second most significant bit (x) is a flag indicating whether 245 the ATM number is in: 247 ATM Forum AESA format (x = 0). 248 Native E.164 format (x = 1). 250 The bottom 6 bits represent an unsigned integer value indicating 251 the length of the associated ATM address field in octets. 253 The [STL] format is the same as the [NTL] field. Defines the length 254 of the subaddress field, if it exists. If it does not exist this 255 entire octet field MUST be zero. If the subaddress exists it will be 256 in AESA format, so flag x SHALL be zero. 258 [NBMA Number] is a variable length field containing the ATM address 259 of the Link layer target. It is always present. 261 [NBMA Subaddress] is a variable length field containing the ATM 262 subaddress of the Link layer target. It may or may not be present. 263 When it is not, the option ends after the [NBMA Number] (or any 264 additional padding for 8 byte alignment). 266 The octet ordering of the [NBMA Number] and [NBMA Subaddress] fields 267 SHALL be the same as that used in MARS and NHRP control messages. 269 4.2 UNI 3.0/3.1 signaling issues (SVC mode). 271 When an IPv6 node places a call to another IPv6 node, it SHOULD 272 follow the procedures in [6] and [7] for signalling UNI 3.0/3.1 SVCs 273 [9] and negotiating MTU. The default IP MTU size on a LL is 9180 274 bytes as specified in [7]. 276 Note that while the procedures in [7] still apply to IPv6 over ATM, 277 IPv6 Path MTU Discovery [8] is used by nodes and routers rather than 278 IPv4 MTU discovery. Additionally, while IPv6 nodes are not required 279 to implement Path MTU Discovery, IPv6/ATM nodes SHOULD implement it. 280 Also, since IPv6 nodes will negotiate an appropriate MTU for each 281 VC, Path MTU should never be triggered since neither node should 282 ever receive a Packet Too Big message to trigger Path MTU Discovery. 283 When nodes are communicating via one or more routers Path MTU 284 Discovery will be used just as it is for legacy networks. 286 5 Interface Tokens 288 For both PVC and SVC modes of operation, one of the following 289 methods SHALL be used to generate Interface Tokens as required by 290 section 5.1 of [1]. 292 5.1 Interface Tokens Based on ESI values 294 When the underlying ATM interface is identified by an ATM End System 295 Address (AESA, formerly known as an NSAPA), the interface token MAY 296 be formed from the ESI and SEL values in the AESA as follows: 298 [0x00][ESI][SEL] 300 [0x00] is a one octet field which is always set to 0. 301 Note that the bit corresponding to the EUI-64 Global/Local 302 bit [5] is always reset indicating that this address is not a 303 globally unique IPv6 interface token. 305 [ESI] is a six octet field. 306 This field always contains the six octet ESI value for the 307 AESA used to address the specific instance of the IPv6/ATM 308 interface. 310 [SEL] is a one octet field. 311 This field always contains the SEL value from the AESA used 312 to address the specific instance of the IPv6/ATM interface. 314 5.2 Interface Tokens Based on 48 Bit MAC Values 316 Where the underlying ATM NIC driver has access to a set of one or 317 more 48 bit MAC values unique to the ATM NIC (e.g. MAC addresses 318 configured into the NIC's ROM), the IPv6/ATM interface MAY use one 319 of these values to create a unique interface token as described in 320 [10]. 322 5.3 Interface Tokens Based on EUI-64 Values 324 Where the underlying ATM NIC driver has access to a set of one or 325 more 64 bit EUI-64 values unique to the ATM NIC (e.g. EUI-64 326 addresses configured into the NIC's ROM), the IPv6/ATM interface 327 SHOULD use one of these values to create a unique interface token. 328 after inverting the Global/Local identifier bit [10]. (Any 329 relationship between these values and the ESI(s) registered with the 330 local ATM switch by the ATM driver are outside the scope of this 331 document.) 333 When EUI-64 values are used for IPv6 interface tokens the only 334 modification allowed to the octet string read from the NIC is 335 inversion of the Global/Local identifier bit. 337 5.4 Interface Tokens Based on Native E.164 Addresses 339 When an interface uses Native E.164 addresses then the E.164 values 340 MAY be used to generate an interface token as follows: 342 [D14][D13D12][D11D10][D9D8][D9D6][D5D4][D3D2][D1D0] 344 [D14] A single octet containing the semi-octet representing the most 345 significant E.164 digit shifted left four bits to the most 346 significant four bits of the octet. The lower four bits MUST be set 347 to 0. Note that the EUI-64 Global/Local indicator is set to 0 348 indicating that this is not a globally unique IPv6 interface token. 350 [D13D12] A single octet containing the semi-octet representing the 351 second most significant E.164 digit [D13] shifted left four places 352 to the most significant bits of the octet, and the third most 353 significant semi-octet in the four least significant bits of the 354 octet. 356 [D11D10] - [D1D0] Octets each containing two E.164 digits, one in 357 the most significant four bits, and one in the least significant 358 four bits as indicated. 360 5.5 Nodes Without Unique Identifiers 362 If no MAC, EUI-64, AESA, or E.164 value is available for generating 363 an interface token, then the interface token SHALL be generated as 364 described in Appendix A of [10]. 366 5.6 Multiple Logical Links on a Single Interface 368 A logical ATM interface might be associated with a different SEL 369 field of a common AESA prefix, or a set of entirely separate ESIs 370 might have been registered with the local ATM switch to create a 371 range of unique AESAs. 373 The minimum information required to uniquely identify each logical 374 ATM interface is (within the context of the local switch port) their 375 ESI+SEL combination. 377 For the vhost case described in section 5.1.2 of [1], vhost SHALL 378 select a different interface token from the range of 64 bit values 379 available to the ATM NIC (as described in 4.1). Each vhost SHALL 380 implement IPv6/ATM interfaces in such a way that no two or more 381 vhosts end up advertising the same interface token onto the same LL. 382 (Conformance with this requirement may be achieved by choosing 383 different SEL values, ESI values, or both.) 385 6. Conclusion and Open Issues. 387 This document is an ATM-specific companion document to the ION 388 working group's "IPv6 over Non Broadcast Multiple Access (NBMA) 389 networks" specification [1]. It specifies codepoints for the 390 administratively configured PVC, and dynamically established SVC, 391 modes of operation. 393 There are no major open issues. Comments to the ION mailing list are 394 solicited (ion@nexen.com). 396 7. Security Consideration 398 While this proposal does not introduce any new security mechanisms 399 all current IPv6 security mechanisms will work without modification 400 for ATM. This includes both authentication and encryption for both 401 Neighbor Discovery protocols as well as the exchange of IPv6 data 402 packets. 404 Acknowledgments 406 The original IPv6/ATM work by G. Armitage occurred while employed at 407 Bellcore. Elements of section 4 were borrowed from Matt Crawford's 408 draft on IPv6 over Ethernet. 410 The authors would like to thank Kazuhiko Yamamoto, Kenjiro Cho, 411 Yoshinobu Inoue, Hiroshi Esaki, Yoshifumi Atarashi, and Atsushi 412 Hagiwara for their contributions based on actual PVC 413 implementations. 415 Author's addresses 417 Grenville Armitage 418 Bell Laboratories, Lucent Technologies 419 101 Crawfords Corner Road 420 Holmdel, NJ 07733 421 USA 422 Email: gja@lucent.com 424 Peter Schulter 425 BrightTiger Technologies 426 125 Nagog Park 427 Acton, MA 01720 428 Email: paschulter@acm.org 430 Markus Jork 431 European Applied Research Center 432 Digital Equipment GmbH 433 CEC Karlsruhe 434 Vincenz-Priessnitz-Str. 1 435 D-76131 Karlsruhe 436 Germany 437 email: jork@kar.dec.com 439 References. 441 [1] G. Armitage, P.Schulter, M. Jork, G. Harter, "IPv6 over Non- 442 Broadcast Multiple Access (NBMA) networks", INTERNET DRAFT, draft- 443 ietf-ion-ipv6-01.txt, March 1998 445 [2] J. Heinanen, "Multiprotocol Encapsulation over ATM Adaption 446 Layer 5", RFC 1483, USC/Information Science Institute, July 1993. 448 [3] G.J. Armitage, "Support for Multicast over UNI 3.1 based ATM 449 Networks", RFC 2022, Bellcore, November 1996. 451 [4] J. Luciani, et al, "NBMA Next Hop Resolution Protocol (NHRP)", 452 RFC 2332, April 1998 454 [5] "64-Bit Global Identifier Format Tutorial", 455 http://standards.ieee.org/db/oui/tutorials/EUI64.html. 457 [6] M. Perez, et al, "ATM Signalling Support for IP over ATM", RFC 458 1755, February 1995 460 [7] R. Atkinson, "Default IP MTU for use over ATM AAL5", RFC 1626, 461 May 1994 463 [8] J. McCann, et al, "Path MTU Discovery for IP version 6", RFC 464 1981, August 1996 466 [9] ATM Forum, "ATM User Network Interface (UNI) Specification 467 Version 3.1", ISBN 0-13-393828-X, Prentice Hall, Englewood Cliffs, 468 NJ, June 1995. 470 [10] B. Hinden, S. Deering, "IP Version 6 Addressing Architecture", 472 [11] T. Narten, E. Nordmark, W.A. Simpson, "Neighbor Discovery for 473 IP Version 6 (IPv6)", RFC 1970, August 1996.