idnits 2.17.1 draft-ietf-ipngwg-trans-ethernet-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-03-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. 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 (September 26, 1997) is 9671 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 187 -- 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 == Outdated reference: A later version (-06) exists of draft-ietf-ipngwg-addr-arch-v2-02 == Outdated reference: A later version (-01) exists of draft-ietf-ipngwg-addrconf-v2-00 == Outdated reference: A later version (-02) exists of draft-ietf-ipngwg-discovery-v2-00 -- Possible downref: Non-RFC (?) normative reference: ref. 'EUI64' == Outdated reference: A later version (-01) exists of draft-ietf-ipngwg-ipv6-spec-v2-00 Summary: 9 errors (**), 0 flaws (~~), 6 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 September 26, 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 2. Maximum Transmission Unit 49 The default MTU size for IPv6 [IPV6] packets on an Ethernet is 1500 50 octets. This size may be reduced by a Router Advertisement [DISC] 51 containing an MTU option which specifies a smaller MTU, or by manual 52 configuration of each node. If a Router Advertisement received on 53 an Ethernet interface has an MTU option specifying an MTU larger 54 than 1500, or larger than a manually configured value, that MTU 55 option may be logged to system management but must be otherwise 56 ignored. 58 For purposes of this document, information received from DHCP is 59 considered "manually configured" and the term Ethernet includes 60 CSMA/CD and full-duplex subnetworks based on ISO/IEC 8802-3, with 61 various data rates. 63 3. Frame Format 65 IPv6 packets are transmitted in standard Ethernet frames. The 66 Ethernet header contains the Destination and Source Ethernet 67 addresses and the Ethernet type code, which must contain the value 68 86DD hexadecimal. The data field contains the IPv6 header followed 69 immediately by the payload, and possibly padding octets to meet the 70 minimum frame size for the Ethernet link. 72 0 1 73 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 74 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 75 | Destination | 76 +- -+ 77 | Ethernet | 78 +- -+ 79 | Address | 80 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 81 | Source | 82 +- -+ 83 | Ethernet | 84 +- -+ 85 | Address | 86 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 87 |1 0 0 0 0 1 1 0 1 1 0 1 1 1 0 1| 88 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 89 | IPv6 | 90 +- -+ 91 | header | 92 +- -+ 93 | and | 94 +- -+ 95 / payload ... / 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 98 (Each tic mark represents one bit.) 100 4. Stateless Autoconfiguration 102 The Interface Identifier [AARCH] for an Ethernet interface is based 103 on the EUI-64 identifier [EUI64] derived from the interface's 104 built-in 48-bit IEEE 802 address. The EUI-64 is formed as follows. 105 (Canonical bit order is assumed throughout.) 107 The OUI of the Ethernet address (the first three octets) becomes the 108 company_id of the EUI-64 (the first three octets). The fourth and 109 fifth octets of the EUI are set to the fixed value FFFE hexadecimal. 110 The last three octets of the Ethernet address become the last three 111 octets of the EUI-64. 113 The Interface Identifier is then formed from the EUI-64 by 114 complementing the "Universal/Local" (U/L) bit, which is the next- 115 to-lowest order bit of the first octet of the EUI-64. Complementing 116 this bit will generally change a 0 value to a 1, since an 117 interface's built-in address is expected to be from a universally 118 administered address space and hence have a globally unique value. 119 A universally administered IEEE 802 address or an EUI-64 is 120 signified by a 0 in the U/L bit position, while a globally unique 121 IPv6 Interface Identifier is signified by a 1 in the corresponding 122 position. For further discussion on this point, see [AARCH]. 124 For example, the Interface Identifier for an Ethernet interface 125 whose built-in address is, in hexadecimal, 127 34-56-78-9A-BC-DE 129 would be 131 36-56-78-FF-FE-9A-BC-DE. 133 A different MAC address set manually or by software should not be 134 used to derive the Interface Identifier. If such a MAC address must 135 be used, its global uniqueness property should be reflected in the 136 value of the U/L bit. 138 An IPv6 address prefix used for stateless autoconfiguration [ACONF] 139 of an Ethernet interface must have a length of 64 bits. 141 5. Link-Local Addresses 143 The IPv6 link-local address [AARCH] for an Ethernet interface is 144 formed by appending the Interface Identifier, as defined above, to 145 the prefix FE80::/64. 147 10 bits 54 bits 64 bits 148 +----------+-----------------------+----------------------------+ 149 |1111111010| (zeros) | Interface Identifier | 150 +----------+-----------------------+----------------------------+ 152 6. Address Mapping -- Unicast 154 The procedure for mapping IPv6 unicast addresses into Ethernet 155 link-layer addresses is described in [DISC]. The Source/Target 156 Link-layer Address option has the following form when the link layer 157 is Ethernet. 159 0 1 160 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Type | Length | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | | 165 +- Ethernet -+ 166 | | 167 +- Address -+ 168 | | 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 Ethernet Address 179 The 48 bit Ethernet IEEE 802 address, in canonical bit 180 order. This is the address the interface currently 181 responds to, and may be different from the built-in 182 address used to derive the Interface Identifier. 184 7. Address Mapping -- Multicast 186 An IPv6 packet with a multicast destination address DST, consisting 187 of the sixteen octets DST[1] through DST[16], is transmitted to the 188 Ethernet multicast address whose first two octets are the value 3333 189 hexadecimal and whose last four octets are the last four octets of 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 8. Security Considerations 202 The method of derivation of Interface Identifiers from MAC addresses 203 is intended to preserve global uniqueness when possible. However, 204 there is no protection from duplication through accident or forgery. 206 9. References 208 [AARCH] R. Hinden, S. Deering "IP Version 6 Addressing 209 Architecture", Currently draft-ietf-ipngwg-addr-arch-v2- 210 02.txt. 212 [ACONF] S. Thomson, T. Narten, "IPv6 Stateless Address 213 Autoconfiguration", currently draft-ietf-ipngwg-addrconf- 214 v2-00.txt. 216 [DISC] T. Narten, E. Nordmark, W. A. Simpson, "Neighbor Discovery 217 for IP Version 6 (IPv6)", currently draft-ietf-ipngwg- 218 discovery-v2-00.txt. 220 [EUI64] "64-Bit Global Identifier Format Tutorial", 221 http://standards.ieee.org/db/oui/tutorials/EUI64.html. 223 [IPV6] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) 224 Specification", currently draft-ietf-ipngwg-ipv6-spec-v2- 225 00.txt. 227 [KWORD] S. Bradner, "Key words for use in RFCs to Indicate 228 Requirement Levels," RFC 2119. 230 10. Author's Address 232 Matt Crawford 233 Fermilab MS 368 234 PO Box 500 235 Batavia, IL 60510 236 USA 238 Phone: +1 630 840-3461 240 EMail: crawdad@fnal.gov