idnits 2.17.1 draft-ietf-ipngwg-token-ring-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-27) 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 == The page length should not exceed 58 lines per page, but there was 4 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 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. 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 (August 24, 1995) is 10474 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) -- Possible downref: Non-RFC (?) normative reference: ref. '8025' -- Unexpected draft version: The latest known version of draft-ietf-ipngwg-addr-arch is -02, but you're referring to -03. ** Downref: Normative reference to an Historic draft: draft-ietf-ipngwg-addr-arch (ref. 'AARCH') -- No information found for draft-ietf-addrconf-ipv6 - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'CONF' == Outdated reference: A later version (-06) exists of draft-ietf-ipngwg-discovery-01 -- Unexpected draft version: The latest known version of draft-ietf-ipngwg-ipv6-spec is -01, but you're referring to -02. (However, the state information for draft-ietf-addrconf-ipv6 is not up-to-date. The last update was unsuccessful) Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Stephen Thomas 2 INTERNET DRAFT AT&T Tridom 3 August 24, 1995 5 A Method for the Transmission of IPv6 Packets over Token Ring Networks 7 Status of this Memo 9 This document is an Internet Draft. Internet Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its Areas, 11 and its Working Groups. Note that other groups may also distribute 12 working documents as Internet Drafts. 14 Internet Drafts are draft documents valid for a maximum of six 15 months. Internet Drafts may be updated, replaced, or obsoleted by 16 other documents at any time. It is not appropriate to use Internet 17 Drafts as reference material or to cite them other than as a 18 "working draft" or "work in progress." 20 To learn the current status of any Internet-Draft, please check the 21 ``1id-abstracts.txt'' listing contained in the Internet Drafts 22 Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net 23 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 24 Rim). 26 Distribution of this memo is unlimited. 28 Introduction 30 This memo specifies the frame format for transmission of IPv6 [IPV6] 31 packets and the method of forming IPv6 link-local addresses on Token 32 Ring networks [8025]. It also specifies the content of the 33 Source/Target Link-layer Address option used the the Router 34 Solicitation, Router Advertisement, Neighbor Solicitation, and 35 Neighbor Advertisement messages described in [DISC], when those 36 messages are transmitted on a Token Ring. 38 IPv6 Encapsulation 40 IPv6 packets are transmitted in LLC/SNAP frames, using long-format 41 (48 bit) addresses. The data field contains the IPv6 header and 42 payload. The following figure shows a complete IPv6 frame. 44 +-------+-------+-------+-------+ 45 | SD | AC | FC | | 46 +-----------------------+ | 47 | Destination Address | 48 | +-----------------------+ 49 | | Source | 50 +-------+ Address +-------+ 51 | | DSAP | 52 +-------+-------+-------+-------+ 53 | SSAP | CTL | OUI | 54 +-------+-------+-------+-------+ 55 | OUI | EtherType | | 56 +-------+---------------+ | 57 | | 58 ~ IPv6 header and payload... ~ 59 | | 60 +-------------------------------+ 61 | FCS | 62 +-------+-------+---------------+ 63 | ED | FS | 64 +-------+-------+ 66 In the presence of source route bridges, a routing information field 67 (RIF) may appear immediately after the source address. A RIF is 68 present in frames when the most signficant bit of the source address 69 is set to one. 71 Token Ring Header Fields 73 SD - Starting Delimiter 75 AC - Access Control 77 FC - Frame Control 79 Destination Address - 48-bit IEEE address of destination station 81 Source Address - 48-bit IEEE address of source station 83 DSAP - Destination Service Access Point (for LLC/SNAP format, shall 84 always contain the value 0xAA) 86 SSAP - Source Service Access Point (for LLC/SNAP format, shall 87 always contain the value 0xAA) 89 CTL - Control Field (for Unnumbered Information, shall always 90 contain the value 0x03) 92 OUI - Organizationally Unique Identifier (for EtherType encoding, 93 shall always contain the value 0x000000) 95 EtherType - Protocol type of encapsulated payload (for IPv6, shall 96 always contain the value 0x86DD) 98 FCS - Frame Check Sequence 100 ED - Ending Delimiter 102 FS - Frame Status 104 Maximum Transmission Unit 106 IEEE 802.5 networks have a maximum packet size based on the maximum 107 time a node may hold the token. This time depends on many factors 108 including the data signalling rate and the number of nodes on the 109 ring. The determination of maximum packet size becomes even more 110 complex when multi-ring networks with bridges are considered. 112 The possible ranges for MTU sizes are 256-4472 octets (for 4 Mbit/s 113 rings) and 256-17800 octets (for 16 Mbit/s rings). This variation 114 suggests that implementations must rely on static configuration or 115 router advertisements [DISC] to determine actual MTU sizes. Common 116 default values include 2002 octets (4 Mbit/s rings) and 8188 octets 117 (16 Mbit/s rings). 119 In a environment using source route bridging, the process of 120 discovering the MAC-level route to a neighbor can yield the MTU for 121 the path to that neighbor. The information is contained in the 122 largest frame subfield of the routing information field. The 123 following table lists the possible values of that subfield, and the 124 IPv6 MTU size that results. If an implementation uses this 125 information to determine MTU sizes, it must maintain separate MTU 126 values for each neighbor. 128 LF (binary) MAC MTU IP MTU 130 000 552 508 131 001 1064 1020 132 010 2088 2044 133 011 4136 4092 134 100 8232 8188 136 Stateless Autoconfiguration and Link-local Addresses 138 The address token [CONF] for a Token Ring interface is the 139 interface's built-in 48-bit IEEE 802 address, in canonical bit 140 order. A different MAC address set manually or by software should 141 not be used as the address token. 143 An IPv6 address prefix used for stateless autoconfiguration of a 144 Token Ring interface must be 80 bits in length. 146 The IPv6 Link-local address [AARCH] for a Token Ring interface is 147 formed by appending the interface's IEEE 802 address to the 80-bit 148 prefix FE80::. 150 +-------+-------+-------+-------+ 151 | FE 80 00 00 | 152 +-------+-------+-------+-------+ 153 | 00 00 00 00 | 154 +-------+-------+-------+-------+ 155 | 00 00 | | 156 +-------+-------+ | 157 | Token Ring Address | 158 +-------+-------+-------+-------+ 160 Address Mapping - Unicast 162 The procedure for mapping IPv6 addresses into Token Ring link layer 163 addresses is described in [DISC]. The Source/Target Link Layer 164 Address option has the following form when the link layer is Token 165 Ring. 167 +-------+-------+-------+-------+ 168 | Type |Length | | 169 +-------+-------+ | 170 | Token Ring Address | 171 +-------+-------+-------+-------+ 173 Option Fields: 175 Type 1 for Source Link Layer Address 176 2 for Target Link Layer Address 178 Length 1 (in units of 8 octets) 180 Token Ring Address 181 The 48-bit IEEE 802 address, in canonical bit order. 183 Address Mapping - Multicast 185 All IPv6 packets with multicast destination addresses are 186 transmitted to the Token Ring functional address 03-00-00-20-00-00 187 (in canonical form). Note that protocols other than IPv6 may use 188 this same functional address, so all frames destined to this address 189 are not guaranteed to be IPv6 packets. 191 Security Considerations 193 Security considerations are not addressed in this memo. 195 References 197 [8025] IEEE Standards for Local Area Networks: Token Ring Access 198 Method and Physical Layer Specifications. IEEE Std 802.5-1989. 200 [AARCH] R. Hinden, S. Deering, IP Version 6 Addressing Architecture. 201 Currently draft-ietf-ipngwg-addr-arch-03.txt. 203 [CONF] S. Thomson, IPv6 Stateless Address Autoconfiguration. 204 Currently draft-ietf-addrconf-ipv6-03.txt. 206 [DISC] T. Narten, E. Nordmark, W. A. Simpson, Neighbor Discovery 207 for IP Version 6 (IPv6). Currently draft-ietf-ipngwg- 208 discovery-01.txt. 210 [IPV6] S. Deering, R. Hinden, Internet Protocol, Version 6 (IPv6) 211 Specification. Currently draft-ietf-ipngwg-ipv6-spec-02.txt. 213 Author's Address 215 Stephen Thomas 216 AT&T Tridom Phone: (770) 514-3522 217 840 Franklin Court Fax: (770) 514-3491 218 Marietta, GA 30067 USA Email: stephen.thomas@tridom.com