idnits 2.17.1 draft-ietf-ipngwg-trans-ethernet-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-18) 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (July 3, 1997) is 9786 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) -- Looks like a reference, but probably isn't: '1' on line 185 -- Looks like a reference, but probably isn't: '16' on line 197 -- Looks like a reference, but probably isn't: '13' on line 195 -- Looks like a reference, but probably isn't: '14' on line 195 -- Looks like a reference, but probably isn't: '15' on line 197 ** Obsolete normative reference: RFC 1884 (ref. 'AARCH') (Obsoleted by RFC 2373) ** 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) Summary: 13 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPng Working Group Matt Crawford 3 Internet Draft Fermilab 4 July 3, 1997 6 Transmission of IPv6 Packets over Ethernet Networks 7 9 Status of this Memo 11 This document is an Internet Draft. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its Areas, 13 and its Working Groups. Note that other groups may also distribute 14 working documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six 17 months. Internet Drafts may be updated, replaced, or obsoleted by 18 other documents at any time. It is not appropriate to use Internet 19 Drafts as reference material or to cite them other than as a 20 "working draft" or "work in progress." 22 To learn the current status of any Internet-Draft, please check the 23 "1id-abstracts.txt" listing contained in the Internet Drafts Shadow 24 Directories on ds.internic.net (US East Coast), nic.nordu.net 25 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 26 Rim). 28 Distribution of this memo is unlimited. 30 1. Introduction 32 This document specifies the frame format for transmission of IPv6 33 packets and the method of forming IPv6 link-local addresses and 34 statelessly autoconfigured addresses on Ethernet networks. It also 35 specifies the content of the Source/Target Link-layer Address option 36 used in Router Solicitation, Router Advertisement, Neighbor 37 Solicitation, Neighbor Advertisement and Redirect messages when 38 those messages are transmitted on an Ethernet. 40 This document replaces RFC 1972, "A Method for the Transmission of 41 IPv6 Packets over Ethernet Networks", which will become historic. 43 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 44 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 45 document are to be interpreted as described in [KWORD]. 47 =0C 49 2. Maximum Transmission Unit 51 The default MTU size for IPv6 [IPV6] packets on an Ethernet is 1500 52 octets. This size may be reduced by a Router Advertisement [DISC] 53 containing an MTU option which specifies a smaller MTU, or by manual 54 configuration of each node. If a Router Advertisement received on 55 an Ethernet interface has an MTU option specifying an MTU larger 56 than 1500, or larger than a manually configured value MTU, if any, 57 that MTU option must be ignored. 59 3. Frame Format 61 IPv6 packets are transmitted in standard Ethernet frames. The 62 Ethernet header contains the Destination and Source Ethernet 63 addresses and the ethernet type code, which must contain the value 64 86DD hexadecimal. The data field contains the IPv6 header followed 65 immediately by the payload, and possibly padding octets to meet the 66 minimum frame size for Ethernet. 68 0 1 69 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 70 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 71 | Destination | 72 +- -+ 73 | Ethernet | 74 +- -+ 75 | Address | 76 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 77 | Source | 78 +- -+ 79 | Ethernet | 80 +- -+ 81 | Address | 82 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 83 |1 0 0 0 0 1 1 0 1 1 0 1 1 1 0 1| 84 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 85 | IPv6 | 86 +- -+ 87 | header | 88 +- -+ 89 | and | 90 +- -+ 91 / payload ... / 92 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 94 (Each tic mark represents one bit.) 96 =0C 98 4. Stateless Autoconfiguration 100 The interface token [CONF] for an Ethernet interface is based on the 101 EUI-64 identifier [EUI64] derived from the interface's built-in 48- 102 bit IEEE 802 address. The EUI-64 is formed as follows. (Canonical 103 bit order is assumed throughout.) 105 The OUI of the Ethernet address (the first three octets) becomes the 106 company_id of the EUI-64 (the first three octets). The fourth and 107 fifth octets of the EUI are set to the fixed value FFFE hexadecimal. 108 The last three octets of the Ethernet address become the last three 109 octets of the EUI-64. 111 The interface token is then formed from the EUI-64 by complementing 112 the "Universal/Local" (U/L) bit, which is the next-to-lowest order 113 bit of the first octet of the EUI-64. Complementing this bit will 114 generally change a 0 value to a 1, since an interface's built-in 115 address is expected to be from a universally administered address 116 space and hence have a globally unique value. A universally 117 administered IEEE 802 address or an EUI-64 is signified by a 0 in 118 the U/L bit position, while a globally unique IPv6 interface token 119 is signified by a 1 in the corresponding position. 121 For example, the interface token for an Ethernet interface whose 122 built-in address is, in hexadecimal, 124 34-56-78-9A-BC-DE 126 would be 128 36-56-78-FF-FE-9A-BC-DE. 130 A different MAC address set manually or by software should not be 131 used to derive the interface token. If such a MAC address must be 132 used, its global uniqueness property should be reflected in the 133 value of the U/L bit. 135 An IPv6 address prefix used for stateless autoconfiguration of an 136 Ethernet interface must have a length of 64 bits. 138 5. Link-Local Addresses 140 The IPv6 link-local address [AARCH] for an Ethernet interface is 141 formed by appending the interface token, as defined above, to the 142 prefix FE80::/64. 144 =0C 145 10 bits 54 bits 64 bits 146 +----------+-----------------------+----------------------------+ 147 |1111111010| (zeros) | Interface Token | 148 +----------+-----------------------+----------------------------+ 150 6. Address Mapping -- Unicast 152 The procedure for mapping IPv6 unicast addresses into Ethernet 153 link-layer addresses is described in [DISC]. The Source/Target 154 Link-layer Address option has the following form when the link layer 155 is Ethernet. 157 0 1 158 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Type | Length | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | | 163 +- Ethernet -+ 164 | | 165 +- Address -+ 166 | | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 Option fields: 171 Type 1 for Source Link-layer address. 172 2 for Target Link-layer address. 174 Length 1 (in units of 8 octets). 176 Ethernet Address 177 The 48 bit Ethernet IEEE 802 address, in canonical bit 178 order. This is the address the interface currently 179 responds to, and may be different from the built-in 180 address used to derive the interface token. 182 7. Address Mapping -- Multicast 184 An IPv6 packet with a multicast destination address DST, consisting 185 of the sixteen octets DST[1] through DST[16], is transmitted to the 186 Ethernet multicast address whose first two octets are the value 3333 187 hexadecimal and whose last four octets are the last four octets of 189 =0C 190 DST. 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 |0 0 1 1 0 0 1 1|0 0 1 1 0 0 1 1| 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | DST[13] | DST[14] | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | DST[15] | DST[16] | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 Security Considerations 202 The method of derivation of interface tokens from MAC addresses is 203 intended to preserve global uniqueness when possible. However, 204 there is no protection from duplication through accident or forgery. 206 8. References 208 [AARCH] R. Hinden, S. Deering "IP Version 6 Addressing 209 Architecture", RFC 1884. 211 [CONF] S. Thomson, T. Narten, "IPv6 Stateless Address 212 Autoconfiguration", RFC 1971. 214 [DISC] T. Narten, E. Nordmark, W. A. Simpson, "Neighbor Discovery 215 for IP Version 6 (IPv6)", RFC 1970. 217 [EUI64] "64-Bit Global Identifier Format Tutorial", 218 http://standards.ieee.org/db/oui/tutorials/EUI64.html. 220 [IPV6] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) 221 Specification", RFC 1883. 223 [KWORD] S. Bradner, "Key words for use in RFCs to Indicate 224 Requirement Levels," RFC 2119. 226 =0C 228 9. Author's Address 230 Matt Crawford 231 Fermilab MS 368 232 PO Box 500 233 Batavia, IL 60510 234 USA 236 Phone: +1 630 840-3461 238 EMail: crawdad@fnal.gov