The RFC Archive
 The RFC Archive   RFC 1972   « Jump to any RFC number directly 
 RFC Home
Full RFC Index
Recent RFCs
RFC Standards
Best Current Practice
RFC Errata
1 April RFC



IETF RFC 1972

A Method for the Transmission of IPv6 Packets over Ethernet Networks

Last modified on Wednesday, August 14th, 1996

Permanent link to RFC 1972
Search GitHub Wiki for RFC 1972
Show other RFCs mentioning RFC 1972







Network Working Group                                        M. Crawford
Request for Comments: 1972                                      Fermilab
Category: Standards Track                                  August 1996



  A Method for the 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.

Introduction

   This memo specifies the frame format for transmission of IPv6 [IPV6]
   packets and the method of forming IPv6 link-local addresses on
   Ethernet networks.  It also specifies the content of the
   Source/Target Link-layer Address option used the the Router
   Solicitation, Router Advertisement, Neighbor Solicitation, and
   Neighbor Advertisement messages described in [DISC], when those
   messages are transmitted on an Ethernet.

Maximum Transmission Unit

   The default MTU size for 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 is received
   with an MTU option specifying an MTU larger than 1500, or larger than
   a manually configured value less than 1500, that MTU option must be
   ignored.

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 Ethernet.







Crawford                    Standards Track                  PAGE 1 top


RFC 1972 Transmission of IPv6 Packets Over Ethernet August 1996 +-------+-------+-------+-------+-------+-------+ ^ | Destination Ethernet address | | +-------+-------+-------+-------+-------+-------+ ethernet | Source Ethernet address | header +-------+-------+-------+-------+-------+-------+ | | 86 DD | v +-------+-------+-------+-------+-------+------+------+ | IPv6 header and payload ... / +-------+-------+-------+-------+-------+------+------+ Stateless Autoconfiguration and Link-Local Addresses The address token [CONF] for an Ethernet interface is the interface's built-in 48-bit IEEE 802 address, in canonical bit order and with the octets in the same order in which they would appear in the header of an ethernet frame. (The individual/group bit is in the first octet and the OUI is in the first three octets.) A different MAC address set manually or by software should not be used as the address token. An IPv6 address prefix used for stateless autoconfiguration of an ethernet interface must be 80 bits in length. The IPv6 Link-local address [AARCH] for an Ethernet interface is formed by appending the interface's IEEE 802 address to the 80-bit prefix FE80::. +-------+-------+-------+-------+-------+-------+------+------+ | FE 80 00 00 00 00 00 00 | +-------+-------+-------+-------+-------+-------+------+------+ | 00 00 | Ethernet Address | +-------+-------+-------+-------+-------+-------+------+------+ Address Mapping -- Unicast The procedure for mapping IPv6 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. +-------+-------+-------+-------+-------+-------+-------+-------+ | Type |Length | Ethernet Address | +-------+-------+-------+-------+-------+-------+-------+-------+ Crawford Standards Track PAGE 2 top

RFC 1972 Transmission of IPv6 Packets Over Ethernet August 1996 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 as the address token. Address Mapping -- Multicast An IPv6 packet with a multicast destination address DST 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, ordered from more to least significant. +-------+-------+-------+-------+-------+-------+ | 33 | 33 | DST13 | DST14 | DST15 | DST16 | +-------+-------+-------+-------+-------+-------+ Security Considerations Security issues are not discussed in this memo. References [AARCH] Hinden, R., and S. Deering, "IP Version 6 Addressing Architecture", RFC 1884, December 1995. [CONF] Thomson, S., and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 1971, August 1996. [DISC] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 1970, August 1996. [IPV6] Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, December 1995. Crawford Standards Track PAGE 3 top

RFC 1972 Transmission of IPv6 Packets Over Ethernet August 1996 Author's Address Matt Crawford Fermilab MS 368 PO Box 500 Batavia, IL 60510 USA Phone: +1 708 840-3461 EMail: crawdad@fnal.gov Crawford Standards Track PAGE 4 top

A Method for the Transmission of IPv6 Packets over Ethernet Networks RFC TOTAL SIZE: 6353 bytes PUBLICATION DATE: Wednesday, August 14th, 1996 LEGAL RIGHTS: The IETF Trust (see BCP 78)


RFC-ARCHIVE.ORG

© RFC 1972: The IETF Trust, Wednesday, August 14th, 1996
© the RFC Archive, 2024, RFC-Archive.org
Maintainer: J. Tunnissen

Privacy Statement