INTERNET DRAFT Matt Thomas Internet Draft AltaVista Internet Software April 1997 The Use of End System Designators in IPv6 draft-thomas-ipv6-esd-00.txt Abstract There is a proposal to split unicast IPv6 addresses into two 8 byte quantities. The first 8 bytes will contain routing information which is used to reach a subnetwork. The last 8 bytes will contain a identifier of a node on that subnet. This identifier is globally unique and is called an End System Designator (ESD). The ESD (not the entire 16 byte address) will be used to accept packets and identify connections, among other things. Status of This Memo This document is a submission to the IPng Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ipng@sunroof.eng.sun.com mailing list. This document is not at this time a product of the IPng Working Group, but a proposal to become a product of the IPng Working Group. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Table Of Contents 1. Introduction 3 2. Concepts 3 2.1. EUI-48 3 2.2. EUI-60 4 3. Methods of obtaining an ESD when a EUI-64 is not available 4 Expires August 1997 [Page 1] Internet Draft IPv6 End System Designators April 1997 3.1. EUI-64 from IPv4 address 4 3.2. EUI-64 from Autonomous System Number 4 3.3. EUI-64 from random number 4 4. Usage of End System Designators 5 5. Issues for Further Consideration 5 5.1. IPv4 Compatible Addresses 5 5.2. IPv4 Mapped Addresses 6 6. Acknowledgments 6 7. References 6 8. Authors' Addresses 6 Expires August 1997 [Page 2] Internet Draft IPv6 End System Designators April 1997 1. Introduction There is a proposal to split unicast IPv6 addresses into two 8 byte quantities. The first 8 bytes will contain routing information which is used to reach a subnetwork. The last 8 bytes will contain a identifier of a node on that subnet. This identifier is globally unique and is called an End System Designator (ESD). The ESD (not the entire 16 byte address) will be used to accept packets and identify connections, among other things. 2. Concepts An End System Designator is an 8 byte globally unique value that is placed in the last 8 bytes of IPv6 address. An ESD uses the same format as an EUI-64 which is defined in the IEEE EUI-64 standard [EUI64]. The first 3 bytes is an IEEE-assigned "company_id" followed by 5 bytes of vendor supplied identification. Over an IEEE 802 media, the 24 bits of a company_id are transmitted from left to right: 00010000 00000000 11010100 (example company_id of 08-00-2B) guxxxxxx yyyyyyyy zzzzzzzz where g is the group/individual bit and u is the universal/local bit. These two bits of the IEEE company_id are reserved for future use by the IEEE. "x" represents the remaining bits of the first byte. "y" and "z" represent the bits of the second and third bytes, respectively. The canonical representation of a company is 3 bytes expressed in hexadecimal; bit 0 of each byte is the first transmitted bit of that byte. The EUI-64 format is used by IEEE 1394 (FireWire) and other media. 2.1. EUI-48 Ethernet (and other IEEE 802 compatible media) adapters or systems with Ethernet adapters are shipped with at least one 48-bit unique identifier (which will be the address used by the adapter and/or system). This 48-bit identifier (EUI-48) is divided into 2 parts. The first part is a 3 byte OUI (organizationally unique identifier) and is the same as an IEEE company_id. The last 3 bytes of the identifier are vendor supplied identification (VSID). The defined method of transforming an EUI-48 identifier into an EUI-64 identifier is to insert 2 bytes (with the hexadecimal values FF and FE, respectively) between the OUI and the VSID. ccccccFFFEvvvvvv where cccccc is the company_id and vvvvvv is vendor supplied identifier Expires August 1997 [Page 3] Internet Draft IPv6 End System Designators April 1997 2.2. EUI-60 FibreChannel uses a 60 bit EUI format. The first 24 bits correspond to an IEEE-assigned company_id and the last 36 bits consist of vendor supplied indentification. As this point in time, there is no canonical way of transforming an EUI-60 into an EUI-64. In addition, FibreChannel considers its VSIDs to unique to FibreChannel media only. These issues have been raised to the FibreChannel committee. 3. Methods of obtaining an ESD when a EUI-64 is not available Some systems (e.g. PPP servers) may not have enough vendor-supplied identifiers to generate an ESD for every link on the system. It also may not be able to supply an ESD for the remote side of a point-to-point link. Therefore at least one alternative way of generating globally unique ESDs is required. It is desireable to not create another centralized allocation scheme if at all possible. IANA was been assigned the company_id of 00-00-5E [RFC1700]. Since this company_id has only been used to construct IEEE 802 group addresses, some or all of the remaining 40 bits (subject to IANA's approval) are available to be used to construct EUI-64 identifiers. 3.1. EUI-64 from IPv4 address One method to obtain a globally unique EUI-64 value is to use one of the system's globally unique IPv4 address (not an IPv4 address with a 10/8, 127/8, 172.16/12, or 192.168/16 prefix [RFC1918]). This can be used to generate an EUI-64 in the following manner: 00-00-5E-10-aa-bb-cc-dd aa-bb-cc-dd are the bytes of the IPv4 address in network order It is expected that this can be automatically by configuration with little or no user intervention. 3.2. EUI-64 from Autonomous System Number Another method to generate an ESD is to use an assigned autonomous system number (ASN) to create a customer-assignable space from which the customer can allocate EUI-64s 00-00-5E-20-gg-hh-vv-vv gg-hh are the bytes of the ASN in network order. vv-vv are the bytes the customer can assign. 3.3. EUI-64 from random number A third method is generate a 60 bit random (not psuedo-random) and use that in conjunction with one of the reserved bits to generate a globally unique EUI-64. Expires August 1997 [Page 4] Internet Draft IPv6 End System Designators April 1997 x2-xx-xx-xx-xx-xx-xx-xx x is the 60 bit random number. The first 4 bits of EUI-64 are 0010. Note that a cryptographically good random number generator should be used. If one is not available, use a cryptographic hash function and supply as much "unique" or varying information to the hash and then truncate the hash output to 60 bits. 4. Usage of End System Designators The packet acceptance rules still operate on the entire 16 byte IPv6 address. However, once a packet has been deterimined to be addressed to the local node and the packet's destination address was not an IPv6 multicast address, only the ESD portion of the destination address is used to perform connection identification/lookup or other functions (e.g. looking security assocsiations) where an address would normally be used as an identifier. This may allow connections to survive renumbering since the ESD will not have changed. However another mechanism is needed to inform the remote node that it should be using a new IPv6 address. This can be easily done if the there exists a security association (which provides replay protection and integrity checking) from the local renumbered node to the remote node. If a valid packet is received by the remote node which is covered by the security association and that packet establishes a new upper edge of the replay window (ie. it has the highest replay counter received so far), then that packet must be the most recent packet transmitted by the renumbered node. Whenever this condition is true, the remote node stores the source address of the packet as the the remote address for its connection and/or paired security association. This would allow connections to securely transition to new addresses as a result of renumbering. However, this may not be possible is all cases (long lived UDP or datagram; e.g. NFS or RealAudio) and may require application awareness to happen. It is expected that the Advanced API for IPv6 draft will be amended to allow application control over this behavior. 5. Issues for Further Consideration 5.1. IPv4 Compatible Addresses IPv4 compatible addresses [RFC1883] are of the form ::aabb:ccdd (where aa, bb, cc, and dd are the bytes of the IPv4 address in hexadecimal). This would translate into an EUI-64 of 00-00-00-00-aa-bb-cc-dd. Since the 00-00-00 company_id is reserved [must be confirmed with IEEE.] these addresses are still globally unique. Expires August 1997 [Page 5] Internet Draft IPv6 End System Designators April 1997 5.2. IPv4 Mapped Addresses IPv4 mapped addresses [RFC1883] are of the form ::FFFF:aabb:ccdd (where aa, bb, cc, and dd are the bytes of the IPv4 address in hexadecimal). This would translate into an EUI-64 of 00-00-FF-FF-aa-bb-cc-dd. It is not known at this time whether the 00-00-FF company_id has been assigned. If not, it should be assigned to IANA. If so, then either a new prefix should be chosen for IPv4 mapped addresses or IPv4 mapped addresses can not be considered to globally unique and must as treated as a special case. The new prefix, if required, should be ::FFFF:FFFF:aabb:cc:dd so that the header checksum is preserved and FF-FF-FF company_id is in the reserved space of IEEE. 6. Acknowledgments This draft could not have been written without the considerable help of Matt Crawford, Bob Fink, and Dan Harrington. 7. References EUI64 IEEE, "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) REGISTRATION AUTHORITY", http://standards.ieee.org/db/oui/tutorials/EUI64.html, March 1997 RFC1700 Reynolds & Postel, "Assigned Numbers", October 1994 RFC1883 S. Deering and R. Hinden, "Internet Protocol Version 6 (IPv6) Specification", Proposed Standard, December 1995 RFC1884 R. Hinden and S. Deering, "IP Version 6 Addressing Architecture", Proposed Standard, December 1995 RFC1918 Rekhter, et al, "Address Allocation for Private Internets", Best Current Practice, February 1996 8. Authors' Addresses Matt Thomas AltaVista Internet Software LJO2-1/J8 30 Porter Rd Littleton, MA 01460 Email: mattthomas@earthlink.net Expires August 1997 [Page 6]