idnits 2.17.1 draft-ietf-ipngwg-tokenring-01.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-19) 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 Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character 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 346: '... network, all multicast packets SHOULD...' RFC 2119 keyword, line 354: '...y, an implementation MAY wish to allow...' RFC 2119 keyword, line 358: '... MUST be to use the Spanning Tree ...' 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.) -- The document date (September 7, 1997) is 9721 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) == Unused Reference: 'IPV6' is defined on line 409, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-ipngwg-addr-arch-v2-01 -- Possible downref: Non-RFC (?) normative reference: ref. 'BRIDGE' ** Obsolete normative reference: RFC 1971 (ref. 'CONF') (Obsoleted by RFC 2462) ** Obsolete normative reference: RFC 1970 (ref. 'DISC') (Obsoleted by RFC 2461) -- Possible downref: Non-RFC (?) normative reference: ref. 'EUI64' ** Obsolete normative reference: RFC 1883 (ref. 'IPV6') (Obsoleted by RFC 2460) -- Possible downref: Non-RFC (?) normative reference: ref. 'LLC' Summary: 14 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPng Working Group Stephen Thomas 3 Internet Draft TransNexus 4 September 7, 1997 6 Transmission of IPv6 Packets over Token Ring Networks 7 9 Status of this Memo 11 This document is an Internet Draft. Internet Drafts are 12 working documents of the Internet Engineering Task Force 13 (IETF), its Areas, and its Working Groups. Note that other 14 groups may also distribute working documents as Internet 15 Drafts. 17 Internet Drafts are draft documents valid for a maximum of 18 six months. Internet Drafts may be updated, replaced, or 19 obsoleted by other documents at any time. It is not 20 appropriate to use Internet Drafts as reference material or 21 to cite them other than as a "working draft" or "work in 22 progress." 24 To learn the current status of any Internet-Draft, please 25 check the "1id-abstracts.txt" listing contained in the 26 Internet Drafts Shadow Directories on ds.internic.net (US 27 East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West 28 Coast), or munnari.oz.au (Pacific Rim). 30 This Internet Draft expires December 15, 1997. 32 1. Introduction 34 This memo specifies the MTU and frame format for transmission 35 of IPv6 packets on Token Ring networks. It also specifies the 36 method of forming IPv6 link-local addresses on Token Ring 37 networks and the content of the Source/Target Link-layer 38 Address option used the Router Solicitation, Router 39 Advertisement, Neighbor Solicitation and Neighbor 40 Advertisement messages when those messages are transmitted on 41 a Token Ring network. 43 2. Maximum Transmission Unit 45 IEEE 802.5 networks have a maximum frame size based on the 46 maximum time a node may hold the token. This time depends on 47 many factors including the data signaling rate and the number 48 of nodes on the ring. Because the maximum frame size varies, 49 implementations must rely on manual configuration or router 50 advertisements [DISC] to determine actual MTU sizes. Common 51 default values include approximately 2000, 4000, and 8000 52 octets. 54 In the absence of any other information, an implementation 55 should use a default MTU of 1500 octets. This size offers 56 compatibility with all common 802.5 defaults, as well as with 57 Ethernet LANs in an environment using transparent bridging. 59 In an environment using source route bridging, the process of 60 discovering the MAC-level path to a neighbor can yield the 61 MTU for the path to that neighbor. The information is 62 contained in the largest frame (LF) subfield of the routing 63 information field. This field limits the size of the 64 information field of frames to that destination, and that 65 information field includes both the LLC [LLC] header and the 66 IPv6 datagram. Since, for IPv6, the LLC header is always 8 67 octets in length, the IPv6 MTU can be found by subtracting 8 68 from the maximum frame size defined by the LF subfield. If an 69 implementation uses this information to determine MTU sizes, 70 it must maintain separate MTU values for each neighbor. 72 A detailed list of the LF values and the resulting maximum 73 frame size can be found in [BRIDGE]. To illustrate the 74 calculation of IPv6 MTU, the following table lists several 75 common values. Note that some of the 802.1D LF values would 76 result in an IP MTU less than 576 bytes. This size is less 77 than the IPv6 minimum, and communication across paths with 78 those MTUs is generally not possible using IPv6. 80 LF (base) LF (extension) MAC MTU IP MTU 81 001 000 1470 1462 82 010 000 2052 2044 83 011 000 4399 4391 84 100 000 8130 8122 85 101 000 11407 11399 86 110 000 17749 17741 87 111 000 41600 41592 89 When presented with conflicting MTU values from several 90 sources, an implementation should choose from those sources 91 according to the following priorities: 93 1. Largest Frame values from source route bridging 94 (only for specific, unicast destinations) 96 2. Router advertisements 98 3. Manual configuration (including DHCP) 100 4. Default of 1500 102 3. Frame Format 104 IPv6 packets are transmitted in LLC/SNAP frames. The data 105 field contains the IPv6 header and payload. The following 106 figure shows a complete 802.5 frame containing an IPv6 107 datagram. 109 +-------+-------+-------+-------+ 110 | SD | AC | FC | | 111 +-----------------------+ | 112 | Destination Address | 113 | +-----------------------+ 114 | | Source | 115 +-------+ Address +-------+ 116 | | DSAP | 117 +-------+-------+-------+-------+ 118 | SSAP | CTL | OUI | 119 +-------+-------+-------+-------+ 120 | OUI | EtherType | | 121 +-------+---------------+ | 122 | | 123 ~ IPv6 header and payload... ~ 124 | | 125 +-------------------------------+ 126 | FCS | 127 +-------+-------+---------------+ 128 | ED | FS | 129 +-------+-------+ 131 Token Ring Header Fields 133 SD: Starting Delimiter 135 AC: Access Control 137 FC: Frame Control 139 Destination Address: 48-bit IEEE address of destination 140 station 142 Source Address: 48-bit IEEE address of source station 144 DSAP: Destination Service Access Point (for LLC/SNAP 145 format, shall always contain the value 0xAA) 147 SSAP: Source Service Access Point (for LLC/SNAP format, 148 shall always contain the value 0xAA) 150 CTL: Control Field (for Unnumbered Information, shall 151 always contain the value 0x03) 153 OUI: Organizationally Unique Identifier (for EtherType 154 encoding, shall always contain the value 0x000000) 156 EtherType: Protocol type of encapsulated payload (for 157 IPv6, shall always contain the value 0x86DD) 159 FCS: Frame Check Sequence 161 ED: Ending Delimiter 163 FS: Frame Status 165 In the presence of source route bridges, a routing 166 information field (RIF) may appear immediately after the 167 source address. A RIF is present in frames when the most 168 significant bit of the source address is set to one. (This is 169 the bit whose position corresponds to that of the 170 Individual/Group bit in the Destination Address.) 172 The RIF is a variable-length field that (when present) 173 contains a two-octet Routing Control (RC) header, followed by 174 zero or more two-octet Route Designator fields: 176 0 1 177 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 Routing Control: |Bcast| Length |D| LF |rsvd | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 Route Designator 1: | Segment 1 |Bridge1| 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 ~ ... ~ 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 Route Designator N: | Segment N |BridgeN| 186 (0 <= N <= 7) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 Route Designator Fields: 190 Bcast: Broadcast Indicator, Defined values: 192 10x: All Routes Explorer 193 11x: Spanning Tree Explorer 194 0xx: Specifically Routed Frame 196 Length: Total length of RIF field in octets 198 D: Direction of source route. A value of 0 means that 199 the left-to-right sequence of Route Designators 200 provides the path from the sender to recipient. A 201 value of 0 indicates the sequence goes from 202 recipient to sender. 204 LF: Largest Frame 206 rsvd: Reserved 208 On transmission, the Route Designator fields give the 209 sequence of (bridge, LAN segment) numbers the packet is to 210 traverse. It is the responsibility of the sender to provide 211 this sequence for Specifically Routed Frames, i.e., unicast 212 IP datagrams. 214 4. Stateless Autoconfiguration 216 The interface token [CONF] for a Token Ring interface is the 217 EUI-64 identifier [EUI64] derived from the interface's built- 218 in 48-bit IEEE 802 address. The OUI of the Token Ring address 219 (the first three octets) becomes the company_id of the EUI-64 220 (the first three octets). The fourth and fifth octets of the 221 EUI are set to the fixed value FFFE hexadecimal. The last 222 three octets of the Token Ring address become the last three 223 octets of the EUI-64. 225 The Interface Identifier is then formed from the EUI-64 by 226 complementing the "Universal/Local" (U/L) bit, which is the next- 227 to-lowest order bit of the first octet of the EUI-64. Complementing 228 this bit will generally change a 0 value to a 1, since an 229 interface's built-in address is expected to be from a universally 230 administered address space and hence have a globally unique value. 231 A universally administered IEEE 802 address or an EUI-64 is 232 signified by a 0 in the U/L bit position, while a globally unique 233 IPv6 Interface Identifier is signified by a 1 in the corresponding 234 position. For further discussion on this point, see [AARCH]. 236 For example, the interface token for a Token Ring interface 237 whose built-in address is, in hexadecimal and in canonical 238 bit order, 239 34-56-78-9A-BC-DE 240 would be 241 36-56-78-FF-FE-9A-BC-DE. 243 A different MAC address set manually or by software should 244 not be used to derive the interface token. If such a MAC 245 address must be used, its global uniqueness property should 246 be reflected in the value of the U/L bit. 248 An IPv6 address prefix used for stateless autoconfiguration 249 of a Token Ring interface must have a length of 64 bits. 251 5. Link Local Address 253 The IPv6 link-local address [AARCH] for a Token Ring 254 interface is formed by appending the interface token, as 255 defined above, to the prefix FE80::/64. 257 10 bits 54 bits 64 bits 258 +----------+-----------------------+----------------------------+ 259 |1111111010| (zeros) | Interface Token | 260 +----------+-----------------------+----------------------------+ 262 6. Address Mapping -- Unicast 264 The procedure for mapping IPv6 addresses into Token Ring 265 link-layer addresses is described in [DISC]. The 266 Source/Target Link-layer Address option has the following 267 form when the link layer is Token Ring. 269 0 1 270 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Type | Length | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | | 275 +- Token Ring -+ 276 | | 277 +- Address -+ 278 | | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 Option fields: 283 Type: 1 for Source Link-layer address. 284 2 for Target Link-layer address. 286 Length: 1 (in units of 8 octets). 288 Token Ring Address: The 48 bit Token Ring IEEE 802 289 address, in canonical bit order. This is the 290 address the interface currently responds to, and 291 may be different from the built-in address used as 292 the interface token. 294 When source routing bridges are used, the source route for 295 the path to a destination can be extracted from the RIF field 296 of received Neighbor Advertisement messages. Note that the 298 RIF field of received packets can be reversed into a source 299 route suitable for transmitting return traffic by toggling 301 the value of the 'D' bit and insuring that the Bcast field is 302 set to indicate a Specifically Routed Frame. 304 7. Address Mapping -- Multicast 306 All IPv6 packets with multicast destination addresses are 307 transmitted to Token Ring functional addresses. The following 308 table shows the specific mapping between the IPv6 addresses 309 and Token Ring functional addresses (in canonical form). Note 310 that protocols other than IPv6 may use these same functional 311 addresses, so all Token Ring frames destined to these 312 functional addresses are not guaranteed to be IPv6 datagrams. 314 MAC Addr (canonical) IPv6 Multicast Addresses 316 03-00-80-00-00-00 all nodes (FF01::1 and FF02::1) and 317 solicited node (FF02:0:0:0:0:1:FFXX:XXXX) 318 addresses 320 03-00-40-00-00-00 all routers addresses (FF0X::2) 322 03-00-00-80-00-00 any other multicast address with three 323 least significant bits = 000 325 03-00-00-40-00-00 any other multicast address with three 326 least significant bits = 001 328 03-00-00-20-00-00 any other multicast address with three 329 least significant bits = 010 331 03-00-00-10-00-00 any other multicast address with three 332 least significant bits = 011 334 03-00-00-08-00-00 any other multicast address with three 335 least significant bits = 100 337 03-00-00-04-00-00 any other multicast address with three 338 least significant bits = 101 340 03-00-00-02-00-00 any other multicast address with three 341 least significant bits = 110 343 03-00-00-01-00-00 any other multicast address with three 344 least significant bits = 111 346 In a bridged token ring network, all multicast packets SHOULD 347 be sent with a RIF header specifying the use of the Spanning 348 Tree Explorer. 350 Note: it is believed that some (very) old bridge 351 implementations do not properly support the Spanning Tree 352 Explorer mechanism. In such environments, multicast traffic 353 sent through bridges must use a RIF with the All Routes 354 Explorer. Consequently, an implementation MAY wish to allow 355 the sending of IP multicast traffic using an All Routes 356 Explorer. However, such an ability must be configurable by a 357 system administrator and the default setting of the switch 358 MUST be to use the Spanning Tree Explorer. 360 8. Security Considerations 362 Token Ring, like most broadcast LAN technologies, has 363 inherent security vulnerabilities. For example, any sender 364 can claim the identity of another and forge traffic. It is 365 the responsibility of higher layers to take appropriate steps 366 in those environments where such vulnerabilities are 367 unacceptable. 369 9. Acknowledgments 371 Several members of the IEEE 802.5 Working Group contributed 372 their knowledge and experience to the drafting of this 373 specification, including Jim, Andrew Draper, George Lin, John 374 Messenger, Kirk Preiss, and Trevor Warwick. The author would 375 also like to thank many members of the IPng working group for 376 their advice and suggestions, including Ran Atkinson, Scott 377 Bradner, Matt Crawford, Steve Deering, Francis Dupont, Robert 378 Elz, Thomas Narten, and Matt Thomas. A special thanks is due 379 Steve Wise, who gave the most relevant advice of all by 380 actually trying to implement this specification while it was 381 in progress. 383 10. References 385 [802.5] 8802-5 : 1995 (ISO/IEC) [ANSI/IEEE 802.5, 1995 386 Edition] Information technology--Telecommunications 387 and information exchange between systems--Local and 388 metropolitan area networks--Specific requirements-- 389 Part 5: Token ring access method and physical layer 390 specification. 392 [AARCH] R. Hinden, S. Deering, "IP Version 6 Addressing 393 Architecture", draft-ietf-ipngwg-addr-arch-v2-01.txt. 395 [BRIDGE] 10038: 1993 (ISO/IEC) [ANSI/IEEE Std 802.1D, 1993 396 Edition] Information technology--Telecommunications 397 and information exchange between systems--Local 398 area networks--Media access control (MAC) bridges. 400 [CONF] S. Thomson, T. Narten, "IPv6 Stateless Address 401 Autoconfiguration", RFC 1971. 403 [DISC] T. Narten, E. Nordmark, W. A. Simpson, "Neighbor 404 Discovery for IP Version 6 (IPv6)", RFC 1970. 406 [EUI64] "64-Bit Global Identifier Format Tutorial", http: 407 //standards.ieee.org/db/oui/tutorials/EUI64.html. 409 [IPV6] S. Deering, R. Hinden, "Internet Protocol, Version 410 6 (IPv6) Specification", RFC 1883. 412 [LLC] 8802-2 : 1994 (ISO/IEC) [ANSI/IEEE 802.2, 1994 413 Edition] Information technology--Telecommunications 414 and information exchange between systems--Local and 415 Metropolitan area networks--Specific requirements-- 416 Part 2: Logical link control. 418 11. Author's Address 420 Stephen Thomas 421 TransNexus 422 430 Tenth Street NW Suite N204 423 Atlanta, GA 30318 424 US 426 Email: stephen.thomas@transnexus.com 428 Phone: +1 404 872 4745 429 Fax: +1 404 872 9515 431 ------=_NextPart_000_01BCBBE4.A9243030--