idnits 2.17.1 draft-ietf-ipngwg-fddi-ntwrks-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-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 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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages 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 are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. 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 (November 7, 1995) is 10369 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) -- 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') == Outdated reference: A later version (-07) exists of draft-ietf-addrconf-ipv6-auto-05 == Outdated reference: A later version (-06) exists of draft-ietf-ipngwg-discovery-02 -- Unexpected draft version: The latest known version of draft-ietf-ipngwg-ipv6-spec is -01, but you're referring to -02. Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Matt Crawford 2 INTERNET-DRAFT Fermilab 3 November 7, 1995 5 A Method for the Transmission of IPv6 Packets over FDDI 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 "working 18 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 Shadow 22 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 MTU frame format for transmission of IPv6 31 [IPV6] packets on FDDI networks, including a method for MTU 32 determination in the presence of 802.1d bridges to other media. It 33 also specifies the method of forming IPv6 link-local addresses on 34 FDDI networks and the content of the Source/Target Link-layer Address 35 option used the the Router Solicitation, Router Advertisement, 36 Neighbor Solicitation, and Neighbor Advertisement messages described 37 in [DISC], when those messages are transmitted on an FDDI network. 39 Maximum Transmission Unit 41 FDDI permits a frame length of 4500 octets (9000 symbols), including 42 at least 22 octets (44 symbols) of Data Link encapsulation when 43 long-format addresses are used. Subtracting 8 octets of LLC/SNAP 44 header, this would, in principle, allow the IPv6 packet in the 45 Information field to be up to 4470 octets. However, it is desirable 46 to allow for the variable sizes and possible future extensions to the 47 MAC header and frame status fields. The default MTU size for IPv6 48 packets on an FDDI network is therefore 4352 octets. This size may 49 be reduced by a Router Advertisement [DISC] containing an MTU option 50 which specifies a smaller MTU, or by manual configuration of a 51 smaller value on each node. If a Router Advertisement is received 52 with an MTU option specifying an MTU larger than the default or the 53 manually configured value, that MTU option may be logged to system or 54 network management but must be otherwise ignored. 56 Frame Format 58 FDDI provides both synchronous and asynchronous transmission, with 59 the latter class further subdivided by the use of restricted and 60 unrestricted tokens. Only asynchronous transmission with 61 unrestricted tokens is required for FDDI interoperability. 62 Accordingly, IPv6 packets shall be sent in asynchronous frames using 63 unrestricted tokens. The robustness principle dictates that nodes 64 should be able to receive synchronous frames and asynchronous frames 65 sent using restricted tokens. 67 IPv6 packets are transmitted in LLC/SNAP frames, using long-format 68 (48 bit) addresses. The data field contains the IPv6 header and 69 payload and is followed by the FDDI Frame Check Sequence, Ending 70 Delimiter, and Frame Status symbols. 72 +-------+ ^ 73 | FC | | 74 +-------+-------+-------+-------+-------+-------+ | 75 | Destination FDDI address | | 76 +-------+-------+-------+-------+-------+-------+ FDDI 77 | Source FDDI address | header 78 +-------+-------+-------+-------+-------+-------+ | 79 | DSAP | SSAP | CTL | OUI | | 80 +-------+-------+-------+-------+-------+-------+ | 81 | Ethertype | v 82 +-------+-------+-------+-------+-------+------+------+ 83 | IPv6 header and payload ... / 84 +-------+-------+-------+-------+-------+------+------+ 86 FDDI Header Fields: 88 FC The Frame Code shall be in the range 50 to 57 hexadecimal, 89 inclusive, with the three low order bits indicating the 90 frame priority. Transmission by hosts and routers of frames 91 with priority zero (FC =3D 50 hex) is discouraged in order to= 93 aid implementors who wish to distinguish on-ring nodes from 94 nodes which lie behind bridges. 96 DSAP, SSAP Both the DSAP and SSAP fields shall contain the value AA 97 hexadecimal, indictating SNAP encapsulation. 99 CTL The Control field shall be set to 03 hexadecimal, indicating 100 Unnumbered Information. 102 OUI The Organizationally Unique Identifier shall be set to 103 000000 hexadecimal. 105 Ethertype The ethernet protocol type ("ethertype") shall be set to the 106 value 86DD hexadecimal. 108 Interaction with Bridges 110 For correct operation when mixed media are bridged together, nodes 111 transmitting IPv6 on FDDI must implement the following simple 112 mechanism for bridge detection. If a node receives a valid Router 113 Advertisement or Neighbor Advertisement on an FDDI interface in a 114 frame with priority zero (FC =3D 50 hexadecimal), the link MTU used by= 116 that node on that interface shall not exceed 1500 octets. The event 117 of detecting a mixed-media bridged network should be logged to system 118 management the first time it occurs after interface initialization, 119 and such logging should include the source IPv6 address of the packet 120 which triggered bridge detection. 122 Nodes transmitting IPv6 on FDDI must provide a configuration option 123 to disable the bridge detection mechanism. This option may be used 124 when the presence of a non-conforming implementation is known. By 125 default, bridge detection must be enabled. 127 It is possible that a medium other than Ethernet may be bridged to 128 FDDI, and that the correct MTU will be neither 1500 nor 4352 octets. 129 In such a case, bridge detection should be disabled and routers 130 should be configured to advertise the correct MTU. 132 The only contemplated use of the LLC priority field of the FC octet 133 is to aid in link MTU determination. It would be sufficient for that 134 purpose to require only that Router Advertisements and Neighbor 135 Advertisements sent on FDDI always have non-zero priority. However, 136 it may be simpler or more useful to transmit all IPv6 packets on FDDI 137 with non-zero priority. 139 Stateless Autoconfiguration and Link-Local Addresses 141 The address token [CONF] for an FDDI interface is the interface's 142 built-in 48-bit IEEE 802 address, in canonical bit order and with the 143 octet in the same order in which they would appear in the header of 144 an ethernet frame. (The individual/group bit is in the first octet 145 and the OUI is in the first three octets.) A different MAC address 146 set manually or by software should not be used as the address token. 148 An IPv6 address prefix used for stateless autoconfiguration of an 149 FDDI interface must be 80 bits in length. 151 The IPv6 Link-local address [AARCH] for an FDDI interface is formed 152 by appending the interface's IEEE 802 address to the 80-bit prefix 153 FE80::. 155 +-------+-------+-------+-------+-------+-------+------+------+ 156 | FE 80 00 00 00 00 00 00 | 157 +-------+-------+-------+-------+-------+-------+------+------+ 158 | 00 00 | FDDI Address | 159 +-------+-------+-------+-------+-------+-------+------+------+ 161 Address Mapping -- Unicast 163 The procedure for mapping IPv6 addresses into FDDI link-layer 164 addresses is described in [DISC]. The Source/Target Link-layer 165 Address option has the following form when the link layer is FDDI. 167 +-------+-------+-------+-------+-------+-------+------+------+ 168 | Type |Length | FDDI Address | 169 +-------+-------+-------+-------+-------+-------+------+------+ 171 Option fields: 173 Type 1 for Source Link-layer address. 174 2 for Target Link-layer address. 176 Length 1 (in units of 8 octets). 178 FDDI Address 179 The 48 bit FDDI IEEE 802 address, in canonical bit order. 181 Address Mapping -- Multicast 183 An IPv6 packet with a multicast destination address DST is 184 transmitted to the FDDI multicast address whose first two octets are 185 the value 3333 hexadecimal and whose last four octets are the last 186 four octets of DST, ordered from more to least significant. 188 +-------+-------+-------+-------+-------+-------+ 189 | 33 | 33 | DST13 | DST14 | DST15 | DST16 | 190 +-------+-------+-------+-------+-------+-------+ 192 Security Considerations 194 Security considerations are not addressed in this memo. 196 References 198 [AARCH] R. Hinden, S. Deering, IP Version 6 Addressing Architecture. 199 Currently draft-ietf-ipngwg-addr-arch-03.txt. 201 [CONF] S. Thomson, IPv6 Stateless Address Autoconfiguration. Currently 202 draft-ietf-addrconf-ipv6-auto-05.txt. 204 [DISC] T. Narten, E. Nordmark, W. A. Simpson, Neighbor Discovery for IP 205 Version 6 (IPv6). Currently draft-ietf-ipngwg-discovery-02.txt. 207 [IPV6] S. Deering, R. Hinden, Internet Protocol, Version 6 (IPv6) 208 Specification. Currently draft-ietf-ipngwg-ipv6-spec-02.txt. 210 Author's Address 212 Matt Crawford 213 Fermilab MS 368 214 PO Box 500 215 Batavia, IL 60510 216 USA 218 Phone: +1 708 840-3461 220 EMail: crawdad@fnal.gov