From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2464.txt | 395 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 doc/rfc/rfc2464.txt (limited to 'doc/rfc/rfc2464.txt') diff --git a/doc/rfc/rfc2464.txt b/doc/rfc/rfc2464.txt new file mode 100644 index 0000000..73d4a7a --- /dev/null +++ b/doc/rfc/rfc2464.txt @@ -0,0 +1,395 @@ + + + + + + +Network Working Group M. Crawford +Request for Comments: 2464 Fermilab +Obsoletes: 1972 December 1998 +Category: Standards Track + + + Transmission of IPv6 Packets over Ethernet Networks + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1998). All Rights Reserved. + +1. Introduction + + This document specifies the frame format for transmission of IPv6 + packets and the method of forming IPv6 link-local addresses and + statelessly autoconfigured addresses on Ethernet networks. It also + specifies the content of the Source/Target Link-layer Address option + used in Router Solicitation, Router Advertisement, Neighbor + Solicitation, Neighbor Advertisement and Redirect messages when those + messages are transmitted on an Ethernet. + + This document replaces RFC 1972, "A Method for the Transmission of + IPv6 Packets over Ethernet Networks", which will become historic. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC 2119]. + +2. Maximum Transmission Unit + + The default MTU size for IPv6 [IPV6] packets on an Ethernet is 1500 + octets. This size may be reduced by a Router Advertisement [DISC] + containing an MTU option which specifies a smaller MTU, or by manual + configuration of each node. If a Router Advertisement received on an + Ethernet interface has an MTU option specifying an MTU larger than + 1500, or larger than a manually configured value, that MTU option may + be logged to system management but must be otherwise ignored. + + + + + +Crawford Standards Track [Page 1] + +RFC 2464 IPv6 Packets over Ethernet December 1998 + + + For purposes of this document, information received from DHCP is + considered "manually configured" and the term Ethernet includes + CSMA/CD and full-duplex subnetworks based on ISO/IEC 8802-3, with + various data rates. + +3. Frame Format + + IPv6 packets are transmitted in standard Ethernet frames. The + Ethernet header contains the Destination and Source Ethernet + addresses and the Ethernet type code, which must contain the value + 86DD hexadecimal. The data field contains the IPv6 header followed + immediately by the payload, and possibly padding octets to meet the + minimum frame size for the Ethernet link. + + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Destination | + +- -+ + | Ethernet | + +- -+ + | Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Source | + +- -+ + | Ethernet | + +- -+ + | Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |1 0 0 0 0 1 1 0 1 1 0 1 1 1 0 1| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IPv6 | + +- -+ + | header | + +- -+ + | and | + +- -+ + / payload ... / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + (Each tic mark represents one bit.) + + + + + + + + + +Crawford Standards Track [Page 2] + +RFC 2464 IPv6 Packets over Ethernet December 1998 + + +4. Stateless Autoconfiguration + + The Interface Identifier [AARCH] for an Ethernet interface is based + on the EUI-64 identifier [EUI64] derived from the interface's built- + in 48-bit IEEE 802 address. The EUI-64 is formed as follows. + (Canonical bit order is assumed throughout.) + + The OUI of the Ethernet address (the first three octets) becomes the + company_id of the EUI-64 (the first three octets). The fourth and + fifth octets of the EUI are set to the fixed value FFFE hexadecimal. + The last three octets of the Ethernet address become the last three + octets of the EUI-64. + + The Interface Identifier is then formed from the EUI-64 by + complementing the "Universal/Local" (U/L) bit, which is the next-to- + lowest order bit of the first octet of the EUI-64. Complementing + this bit will generally change a 0 value to a 1, since an interface's + built-in address is expected to be from a universally administered + address space and hence have a globally unique value. A universally + administered IEEE 802 address or an EUI-64 is signified by a 0 in the + U/L bit position, while a globally unique IPv6 Interface Identifier + is signified by a 1 in the corresponding position. For further + discussion on this point, see [AARCH]. + + For example, the Interface Identifier for an Ethernet interface whose + built-in address is, in hexadecimal, + + 34-56-78-9A-BC-DE + + would be + + 36-56-78-FF-FE-9A-BC-DE. + + A different MAC address set manually or by software should not be + used to derive the Interface Identifier. If such a MAC address must + be used, its global uniqueness property should be reflected in the + value of the U/L bit. + + An IPv6 address prefix used for stateless autoconfiguration [ACONF] + of an Ethernet interface must have a length of 64 bits. + + + + + + + + + + + +Crawford Standards Track [Page 3] + +RFC 2464 IPv6 Packets over Ethernet December 1998 + + +5. Link-Local Addresses + + The IPv6 link-local address [AARCH] for an Ethernet interface is + formed by appending the Interface Identifier, as defined above, to + the prefix FE80::/64. + + 10 bits 54 bits 64 bits + +----------+-----------------------+----------------------------+ + |1111111010| (zeros) | Interface Identifier | + +----------+-----------------------+----------------------------+ + +6. Address Mapping -- Unicast + + The procedure for mapping IPv6 unicast addresses into Ethernet link- + layer addresses is described in [DISC]. The Source/Target Link-layer + Address option has the following form when the link layer is + Ethernet. + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + +- Ethernet -+ + | | + +- Address -+ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Option fields: + + Type 1 for Source Link-layer address. + 2 for Target Link-layer address. + + Length 1 (in units of 8 octets). + + Ethernet Address + The 48 bit Ethernet IEEE 802 address, in canonical bit + order. This is the address the interface currently + responds to, and may be different from the built-in + address used to derive the Interface Identifier. + + + + + + + + +Crawford Standards Track [Page 4] + +RFC 2464 IPv6 Packets over Ethernet December 1998 + + +7. Address Mapping -- Multicast + + An IPv6 packet with a multicast destination address DST, consisting + of the sixteen octets DST[1] through DST[16], is transmitted to the + Ethernet multicast address whose first two octets are the value 3333 + hexadecimal and whose last four octets are the last four octets of + DST. + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 1 1 0 0 1 1|0 0 1 1 0 0 1 1| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DST[13] | DST[14] | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DST[15] | DST[16] | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +8. Differences From RFC 1972 + + The following are the functional differences between this + specification and RFC 1972. + + The Address Token, which was a node's 48-bit MAC address, is + replaced with the Interface Identifier, which is 64 bits in + length and based on the EUI-64 format [EUI64]. An IEEE-defined + mapping exists from 48-bit MAC addresses to EUI-64 form. + + A prefix used for stateless autoconfiguration must now be 64 bits + long rather than 80. The link-local prefix is also shortened to + 64 bits. + +9. Security Considerations + + The method of derivation of Interface Identifiers from MAC addresses + is intended to preserve global uniqueness when possible. However, + there is no protection from duplication through accident or forgery. + +10. References + + [AARCH] Hinden, R. and S. Deering "IP Version 6 Addressing + Architecture", RFC 2373, July 1998. + + [ACONF] Thomson, S. and T. Narten, "IPv6 Stateless Address + Autoconfiguration", RFC 2462, December 1998. + + [DISC] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery + for IP Version 6 (IPv6)", RFC 2461, December 1998. + + + + + +Crawford Standards Track [Page 5] + +RFC 2464 IPv6 Packets over Ethernet December 1998 + + + [EUI64] "Guidelines For 64-bit Global Identifier (EUI-64)", + http://standards.ieee.org/db/oui/tutorials/EUI64.html + + [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + + [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + +11. Author's Address + + Matt Crawford + Fermilab MS 368 + PO Box 500 + Batavia, IL 60510 + USA + + Phone: +1 630 840-3461 + EMail: crawdad@fnal.gov + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Crawford Standards Track [Page 6] + +RFC 2464 IPv6 Packets over Ethernet December 1998 + + +12. Full Copyright Statement + + Copyright (C) The Internet Society (1998). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Crawford Standards Track [Page 7] + -- cgit v1.2.3