doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

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]
+