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]