< draft-ietf-ipngwg-addr-arch-v3-06.txt   draft-ietf-ipngwg-addr-arch-v3-07.txt >
INTERNET-DRAFT R. Hinden, Nokia INTERNET-DRAFT R. Hinden, Nokia
July 16, 2001 S. Deering, Cisco Systems November 20, 2001 S. Deering, Cisco Systems
IP Version 6 Addressing Architecture IP Version 6 Addressing Architecture
<draft-ietf-ipngwg-addr-arch-v3-06.txt> <draft-ietf-ipngwg-addr-arch-v3-07.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of [RFC2026]. all provisions of Section 10 of [RFC2026].
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
To view the list Internet-Draft Shadow Directories, see To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet Draft expires January 16, 2002. This Internet Draft expires May 20, 2002.
Abstract Abstract
This specification defines the addressing architecture of the IP This specification defines the addressing architecture of the IP
Version 6 protocol [IPV6]. The document includes the IPv6 addressing Version 6 protocol [IPV6]. The document includes the IPv6 addressing
model, text representations of IPv6 addresses, definition of IPv6 model, text representations of IPv6 addresses, definition of IPv6
unicast addresses, anycast addresses, and multicast addresses, and an unicast addresses, anycast addresses, and multicast addresses, and an
IPv6 node's required addresses. IPv6 node's required addresses.
Table of Contents Table of Contents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
2.5.1 Interface Identifiers................................8 2.5.1 Interface Identifiers................................8
2.5.2 The Unspecified Address..............................9 2.5.2 The Unspecified Address..............................9
2.5.3 The Loopback Address................................10 2.5.3 The Loopback Address................................10
2.5.4 Global Unicast Addresses............................10 2.5.4 Global Unicast Addresses............................10
2.5.5 IPv6 Addresses with Embedded IPv4 Addresses.........11 2.5.5 IPv6 Addresses with Embedded IPv4 Addresses.........11
2.5.6 Local-use IPv6 Unicast Addresses....................11 2.5.6 Local-use IPv6 Unicast Addresses....................11
2.6 Anycast Addresses.......................................12 2.6 Anycast Addresses.......................................12
2.6.1 Required Anycast Address............................13 2.6.1 Required Anycast Address............................13
2.7 Multicast Addresses.....................................14 2.7 Multicast Addresses.....................................14
2.7.1 Pre-Defined Multicast Addresses.....................16 2.7.1 Pre-Defined Multicast Addresses.....................16
2.8 A Node's Required Addresses.............................17 2.8 A Node's Required Addresses.............................18
3. Security Considerations.....................................18 3. Security Considerations.....................................18
APPENDIX A: Creating Modified EUI-64 format Interface IDs......19 4. IANA Considerations.........................................19
APPENDIX B: Changes from RFC-2373..............................22 APPENDIX A: Creating Modified EUI-64 format Interface IDs......21
APPENDIX C: IANA Considerations................................24 APPENDIX B: Changes from RFC-2373..............................24
REFERENCES.....................................................26 REFERENCES.....................................................26
AUTHOR'S ADDRESSES.............................................27 AUTHOR'S ADDRESSES.............................................27
1.0 INTRODUCTION 1.0 INTRODUCTION
This specification defines the addressing architecture of the IP This specification defines the addressing architecture of the IP
Version 6 protocol. It includes the basic formats for the various Version 6 protocol. It includes the basic formats for the various
types of IPv6 addresses (unicast, anycast, and multicast). types of IPv6 addresses (unicast, anycast, and multicast).
skipping to change at page 4, line 15 skipping to change at page 4, line 15
2.1 Addressing Model 2.1 Addressing Model
IPv6 addresses of all types are assigned to interfaces, not nodes. IPv6 addresses of all types are assigned to interfaces, not nodes.
An IPv6 unicast address refers to a single interface. Since each An IPv6 unicast address refers to a single interface. Since each
interface belongs to a single node, any of that node's interfaces' interface belongs to a single node, any of that node's interfaces'
unicast addresses may be used as an identifier for the node. unicast addresses may be used as an identifier for the node.
All interfaces are required to have at least one link-local unicast All interfaces are required to have at least one link-local unicast
address (see section 2.8 for additional required addresses). A address (see section 2.8 for additional required addresses). A
single interface may also be assigned multiple IPv6 addresses of any single interface may also have multiple IPv6 addresses of any type
type (unicast, anycast, and multicast) or scope. Unicast addresses (unicast, anycast, and multicast) or scope. Unicast addresses with
with scope greater than link-scope are not needed for interfaces that scope greater than link-scope are not needed for interfaces that are
are not used as the origin or destination of any IPv6 packets to or not used as the origin or destination of any IPv6 packets to or from
from non-neighbors. This is sometimes convenient for point-to-point non-neighbors. This is sometimes convenient for point-to-point
interfaces. There is one exception to this addressing model: interfaces. There is one exception to this addressing model:
A unicast address or a set of unicast addresses may be assigned to A unicast address or a set of unicast addresses may be assigned to
multiple physical interfaces if the implementation treats the multiple physical interfaces if the implementation treats the
multiple physical interfaces as one interface when presenting it multiple physical interfaces as one interface when presenting it
to the internet layer. This is useful for load-sharing over to the internet layer. This is useful for load-sharing over
multiple physical interfaces. multiple physical interfaces.
Currently IPv6 continues the IPv4 model that a subnet prefix is Currently IPv6 continues the IPv4 model that a subnet prefix is
associated with one link. Multiple subnet prefixes may be assigned associated with one link. Multiple subnet prefixes may be assigned
skipping to change at page 5, line 47 skipping to change at page 5, line 47
or in compressed form: or in compressed form:
::13.1.68.3 ::13.1.68.3
::FFFF:129.144.52.38 ::FFFF:129.144.52.38
2.3 Text Representation of Address Prefixes 2.3 Text Representation of Address Prefixes
The text representation of IPv6 address prefixes is similar to the The text representation of IPv6 address prefixes is similar to the
way IPv4 addresses prefixes are written in CIDR notation. An IPv6 way IPv4 addresses prefixes are written in CIDR notation [CIDR]. An
address prefix is represented by the notation: IPv6 address prefix is represented by the notation:
ipv6-address/prefix-length ipv6-address/prefix-length
where where
ipv6-address is an IPv6 address in any of the notations listed ipv6-address is an IPv6 address in any of the notations listed
in section 2.2. in section 2.2.
prefix-length is a decimal value specifying how many of the prefix-length is a decimal value specifying how many of the
leftmost contiguous bits of the address comprise leftmost contiguous bits of the address comprise
skipping to change at page 7, line 37 skipping to change at page 7, line 37
Future specifications may redefine one or more sub-ranges of the Future specifications may redefine one or more sub-ranges of the
global unicast space for other purposes, but unless and until that global unicast space for other purposes, but unless and until that
happens, implementations must treat all addresses that do not start happens, implementations must treat all addresses that do not start
with any of the above-listed prefixes as global unicast addresses. with any of the above-listed prefixes as global unicast addresses.
2.5 Unicast Addresses 2.5 Unicast Addresses
IPv6 unicast addresses are aggregatable with prefixes of arbitrary IPv6 unicast addresses are aggregatable with prefixes of arbitrary
bit-length similar to IPv4 addresses under Classless Interdomain bit-length similar to IPv4 addresses under Classless Interdomain
Routing [CIDR]. Routing.
There are several types of unicast addresses in IPv6, in particular There are several types of unicast addresses in IPv6, in particular
global unicast, site-local unicast, and link-local unicast. There global unicast, site-local unicast, and link-local unicast. There
are also some special-purpose subtypes of global unicast, such as are also some special-purpose subtypes of global unicast, such as
IPv6 addresses with embedded IPv4 addresses or encoded NSAP IPv6 addresses with embedded IPv4 addresses or encoded NSAP
addresses. Additional address types or subtypes can be defined in addresses. Additional address types or subtypes can be defined in
the future. the future.
IPv6 nodes may have considerable or little knowledge of the internal IPv6 nodes may have considerable or little knowledge of the internal
structure of the IPv6 address, depending on the role the node plays structure of the IPv6 address, depending on the role the node plays
skipping to change at page 11, line 26 skipping to change at page 11, line 26
"IPv4-compatible IPv6 address" and has the format: "IPv4-compatible IPv6 address" and has the format:
| 80 bits | 16 | 32 bits | | 80 bits | 16 | 32 bits |
+--------------------------------------+--------------------------+ +--------------------------------------+--------------------------+
|0000..............................0000|0000| IPv4 address | |0000..............................0000|0000| IPv4 address |
+--------------------------------------+----+---------------------+ +--------------------------------------+----+---------------------+
Note: The IPv4 address used in the "IPv4-compatible IPv6 address" Note: The IPv4 address used in the "IPv4-compatible IPv6 address"
must be a globally-unique IPv4 unicast address. must be a globally-unique IPv4 unicast address.
A second type of IPv6 address which holds an embedded global IPv4 A second type of IPv6 address which holds an embedded IPv4 address is
address is also defined. This address type is used to represent the also defined. This address type is used to represent the addresses
addresses of IPv4 nodes as IPv6 addresses. This type of address is of IPv4 nodes as IPv6 addresses. This type of address is termed an
termed an "IPv4-mapped IPv6 address" and has the format: "IPv4-mapped IPv6 address" and has the format:
| 80 bits | 16 | 32 bits | | 80 bits | 16 | 32 bits |
+--------------------------------------+--------------------------+ +--------------------------------------+--------------------------+
|0000..............................0000|FFFF| IPv4 address | |0000..............................0000|FFFF| IPv4 address |
+--------------------------------------+----+---------------------+ +--------------------------------------+----+---------------------+
2.5.6 Local-Use IPv6 Unicast Addresses 2.5.6 Local-Use IPv6 Unicast Addresses
There are two types of local-use unicast addresses defined. These There are two types of local-use unicast addresses defined. These
are Link-Local and Site-Local. The Link-Local is for use on a single are Link-Local and Site-Local. The Link-Local is for use on a single
skipping to change at page 13, line 30 skipping to change at page 13, line 30
Routing header, to cause a packet to be delivered via a particular Routing header, to cause a packet to be delivered via a particular
service provider or sequence of service providers. service provider or sequence of service providers.
Some other possible uses are to identify the set of routers attached Some other possible uses are to identify the set of routers attached
to a particular subnet, or the set of routers providing entry into a to a particular subnet, or the set of routers providing entry into a
particular routing domain. particular routing domain.
There is little experience with widespread, arbitrary use of internet There is little experience with widespread, arbitrary use of internet
anycast addresses, and some known complications and hazards when anycast addresses, and some known complications and hazards when
using them in their full generality [ANYCST]. Until more experience using them in their full generality [ANYCST]. Until more experience
has been gained and solutions agreed upon for those problems, the has been gained and solutions are specified, the following
following restrictions are imposed on IPv6 anycast addresses: restrictions are imposed on IPv6 anycast addresses:
o An anycast address must not be used as the source address of an o An anycast address must not be used as the source address of an
IPv6 packet. IPv6 packet.
o An anycast address must not be assigned to an IPv6 host, that o An anycast address must not be assigned to an IPv6 host, that
is, it may be assigned to an IPv6 router only. is, it may be assigned to an IPv6 router only.
2.6.1 Required Anycast Address 2.6.1 Required Anycast Address
The Subnet-Router anycast address is predefined. Its format is as The Subnet-Router anycast address is predefined. Its format is as
skipping to change at page 15, line 22 skipping to change at page 15, line 25
7 (unassigned) 7 (unassigned)
8 organization-local scope 8 organization-local scope
9 (unassigned) 9 (unassigned)
A (unassigned) A (unassigned)
B (unassigned) B (unassigned)
C (unassigned) C (unassigned)
D (unassigned) D (unassigned)
E global scope E global scope
F reserved F reserved
interface-local scope spans only a single interface on a
node, and is useful only for loopback transmission of
multicast.
link-local and site-local multicast scopes span the same
topological regions as the corresponding unicast scopes.
subnet-local scope is given a different and larger value
than link-local to enable possible support for subnets
that span multiple links.
admin-local scope is the smallest scope that must be
administratively configured, i.e., not automatically
derived from physical connectivity or other, non-
multicast-related configuration.
organization-local scope is intended to span multiple
sites belonging to a single organization.
scopes labelled "(unassigned)" are available for
administrators to define additional multicast regions.
group ID identifies the multicast group, either permanent or group ID identifies the multicast group, either permanent or
transient, within the given scope. transient, within the given scope.
The "meaning" of a permanently-assigned multicast address is The "meaning" of a permanently-assigned multicast address is
independent of the scope value. For example, if the "NTP servers independent of the scope value. For example, if the "NTP servers
group" is assigned a permanent multicast address with a group ID of group" is assigned a permanent multicast address with a group ID of
101 (hex), then: 101 (hex), then:
FF01:0:0:0:0:0:0:101 means all NTP servers on the same interface FF01:0:0:0:0:0:0:101 means all NTP servers on the same interface
(i.e., the same node) as the sender. (i.e., the same node) as the sender.
skipping to change at page 17, line 34 skipping to change at page 18, line 11
A node is required to compute and join the associated Solicited-Node A node is required to compute and join the associated Solicited-Node
multicast addresses for every unicast and anycast address it is multicast addresses for every unicast and anycast address it is
assigned. assigned.
2.8 A Node's Required Addresses 2.8 A Node's Required Addresses
A host is required to recognize the following addresses as A host is required to recognize the following addresses as
identifying itself: identifying itself:
o It's required Link-Local Address for each interface. o Its required Link-Local Address for each interface.
o Any additional Unicast and Anycast Addresses that have been o Any additional Unicast and Anycast Addresses that have been
configured for the node's interfaces (manually or configured for the node's interfaces (manually or
automatically). automatically).
o The Loopback Address. o The loopback address.
o The All-Nodes Multicast Addresses defined in section 2.7.1. o The All-Nodes Multicast Addresses defined in section 2.7.1.
o Solicited-Node Multicast Address for each of its unicast and o The Solicited-Node Multicast Address for each of its unicast and
anycast addresses. anycast addresses.
o Multicast Addresses of all other groups to which the node o Multicast Addresses of all other groups to which the node
belongs. belongs.
A router is required to recognize all addresses that a host is A router is required to recognize all addresses that a host is
required to recognize, plus the following addresses as identifying. required to recognize, plus the following addresses as identifying.
itself: itself:
o The Subnet-Router Anycast Addresses for all interfaces for which o The Subnet-Router Anycast Addresses for all interfaces for which
it is configured to act as a router. it is configured to act as a router.
o All other Anycast Addresses with which the router has been o All other Anycast Addresses with which the router has been
configured. configured.
o The All-Routers Multicast Addresses defined in section 2.7.1. o The All-Routers Multicast Addresses defined in section 2.7.1.
3. Security Considerations 3. Security Considerations
IPv6 addressing documents do not have any direct impact on Internet IPv6 addressing documents do not have any direct impact on Internet
infrastructure security. Authentication of IPv6 packets is defined infrastructure security. Authentication of IPv6 packets is defined
in [AUTH]. in [AUTH].
APPENDIX A: Creating Modified EUI-64 format Interface Identifiers 4. IANA Considerations
Depending on the characteristics of a specific link or node there are
a number of approaches for creating Modified EUI-64 format interface
identifiers. This appendix describes some of these approaches.
Links or Nodes with IEEE EUI-64 Identifiers
The only change needed to transform an IEEE EUI-64 identifier to an
interface identifier is to invert the "u" (universal/local) bit. For
example, a globally unique IEEE EUI-64 identifier of the form:
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
+----------------+----------------+----------------+----------------+
where "c" are the bits of the assigned company_id, "0" is the value
of the universal/local bit to indicate global scope, "g" is
individual/group bit, and "m" are the bits of the manufacturer-
selected extension identifier. The IPv6 interface identifier would
be of the form:
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
+----------------+----------------+----------------+----------------+
The only change is inverting the value of the universal/local bit.
Links or Nodes with IEEE 802 48 bit MAC's
[EUI64] defines a method to create a IEEE EUI-64 identifier from an
IEEE 48bit MAC identifier. This is to insert two octets, with
hexadecimal values of 0xFF and 0xFE, in the middle of the 48 bit MAC
(between the company_id and vendor supplied id). For example the 48
bit IEEE MAC with global scope:
|0 1|1 3|3 4|
|0 5|6 1|2 7|
+----------------+----------------+----------------+
|cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|
+----------------+----------------+----------------+
where "c" are the bits of the assigned company_id, "0" is the value
of the universal/local bit to indicate global scope, "g" is
individual/group bit, and "m" are the bits of the manufacturer-
selected extension identifier. The interface identifier would be of
the form:
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm|
+----------------+----------------+----------------+----------------+
When IEEE 802 48bit MAC addresses are available (on an interface or a
node), an implementation may use them to create interface identifiers
due to their availability and uniqueness properties.
Links with Non-Global Identifiers
There are a number of types of links that, while multi-access, do not
have globally unique link identifiers. Examples include LocalTalk
and Arcnet. The method to create an Modified EUI-64 format
identifier is to take the link identifier (e.g., the LocalTalk 8 bit
node identifier) and zero fill it to the left. For example a
LocalTalk 8 bit node identifier of hexadecimal value 0x4F results in
the following interface identifier:
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|0000000000000000|0000000000000000|0000000000000000|0000000001001111|
+----------------+----------------+----------------+----------------+
Note that this results in the universal/local bit set to "0" to
indicate local scope.
Links without Identifiers
There are a number of links that do not have any type of built-in
identifier. The most common of these are serial links and configured
tunnels. Interface identifiers must be chosen that are unique for
the link.
When no built-in identifier is available on a link the preferred
approach is to use a global interface identifier from another
interface or one which is assigned to the node itself. When using
this approach no other interface connecting the same node to the same
link may use the same identifier.
If there is no global interface identifier available for use on the
link the implementation needs to create a local scope interface
identifier. The only requirement is that it be unique on the link.
There are many possible approaches to select a link-unique interface
identifier. These include:
Manual Configuration
Node Serial Number
Other node-specific token
The link-unique interface identifier should be generated in a manner
that it does not change after a reboot of a node or if interfaces are
added or deleted from the node.
The selection of the appropriate algorithm is link and implementation
dependent. The details on forming interface identifiers are defined
in the appropriate "IPv6 over <link>" specification. It is strongly
recommended that a collision detection algorithm be implemented as
part of any automatic algorithm.
APPENDIX B: Changes from RFC-2373
The following changes were made from RFC-2373 "IP Version 6
Addressing Architecture":
- Many small changes to clarify and make the text more consistent.
- Revised sections 2.4 and 2.5.6 to simplify and clarify how
different address types are identified. This was done to insure
that implementations do build in any knowledge about global
unicast format prefixes. Changes include:
o Removed Format Prefix (FP) terminology
o Revised list of address types only includes exceptions to
global unicast and a singe entry that identifies everything
else as Global Unicast.
o Removed list of defined prefix exceptions from section 2.5.6
as it is now the main part of section 2.4.
- Clarified text relating to EUI-64 identifiers to distinguish
between IPv6's "Modified EUI-64 format" identifiers and IEEE
EUI-64 identifiers.
- Combined the sections on the Global Unicast Addresses and NSAP
Addresses into a single section on Global Unicast Addresses,
generalized the Global Unicast format, and cited [AGGR] and [NSAP]
as examples.
- Reordered sections 2.5.4 and 2.5.5.
- Removed section 2.7.2 Assignment of New IPv6 Multicast Addresses
because this is being redefined elsewhere.
- Added an IANA considerations section that updates the IANA IPv6
address allocations and documents the NSAP and AGGR allocations.
- Added clarification that the "IPv4-compatible IPv6 address" must
use global IPv4 unicast addresses.
- Divided references in to normative and non-normative sections.
- Added reference to [PRIV] in section 2.5.1
- Revised section 2.4 Address Type Representation to
- Added clarification that routers must not forward multicast
packets outside of the scope indicated in the multicast address.
- Added clarification that routers must not forward packets with
source address of the unspecified address.
- Added clarification that routers must drop packets received on an
interface with destination address of loopback.
- Clarified the definition of IPv4-mapped addresses.
- Removed the ABNF Description of Text Representations Appendix.
- Removed the address block reserved for IPX addresses.
- Multicast scope changes:
o Changed name of scope value 1 from "node-local" to "interface-
local"
o Defined scope value 3 for "subnet-local" for multi-link
subnets
o Defined scope value 4 as "admin-local"
- Corrected reference to RFC1933 and updated references.
APPENDIX C: IANA Considerations
[Note to RFC editor: "RFCxxxx" below should be the RFC assigned to [Note to RFC editor: "RFCxxxx" below should be the RFC assigned to
this document] this document]
The table and notes at http://www.isi.edu/in- The table and notes at http://www.isi.edu/in-
notes/iana/assignments/ipv6-address-space.txt should be replaced with notes/iana/assignments/ipv6-address-space.txt should be replaced with
the following: the following:
INTERNET PROTOCOL VERSION 6 ADDRESS SPACE INTERNET PROTOCOL VERSION 6 ADDRESS SPACE
As defined in RFCxxxx the type of an IPv6 address is identified by As defined in RFCxxxx the type of an IPv6 address is identified by
the high-order bits of the address, as follows: the high-order bits of the address, as follows:
The current allocation of these prefixes is listed below.
Allocation Prefix Fraction of Allocation Prefix Fraction of
(binary) Address Space (binary) Address Space
----------------------------------- -------- ------------- ----------------------------------- -------- -------------
Unassigned (see Note 1 below) 0000 0000 1/256 Unassigned (see Note 1 below) 0000 0000 1/256
Unassigned 0000 0001 1/256 Unassigned 0000 0001 1/256
Reserved for NSAP Allocation 0000 001 1/128 [RFC1888] Reserved for NSAP Allocation 0000 001 1/128 [RFC1888]
Unassigned 0000 01 1/64 Unassigned 0000 01 1/64
Unassigned 0000 1 1/32 Unassigned 0000 1 1/32
Unassigned 0001 1/16 Unassigned 0001 1/16
Global Unicast 001 1/8 [RFC2374] Global Unicast 001 1/8 [RFC2374]
skipping to change at page 26, line 5 skipping to change at page 21, line 5
Addresses with Embedded IPv4 Addresses are assigned out of the Addresses with Embedded IPv4 Addresses are assigned out of the
0000 0000 binary prefix space. 0000 0000 binary prefix space.
2) For now, IANA should limit its allocation of IPv6 unicast 2) For now, IANA should limit its allocation of IPv6 unicast
address space to the range of addresses that start with binary address space to the range of addresses that start with binary
value 001. The rest of the global unicast address space value 001. The rest of the global unicast address space
(approximately 85% of the IPv6 address space) is reserved for (approximately 85% of the IPv6 address space) is reserved for
future definition and use, and is not to be assigned by IANA at future definition and use, and is not to be assigned by IANA at
this time. this time.
APPENDIX A: Creating Modified EUI-64 format Interface Identifiers
------------------------------------------------------------------
Depending on the characteristics of a specific link or node there
are a number of approaches for creating Modified EUI-64 format
interface identifiers. This appendix describes some of these
approaches.
Links or Nodes with IEEE EUI-64 Identifiers
The only change needed to transform an IEEE EUI-64 identifier to
an interface identifier is to invert the "u" (universal/local)
bit. For example, a globally unique IEEE EUI-64 identifier of the
form:
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
+----------------+----------------+----------------+----------------+
where "c" are the bits of the assigned company_id, "0" is the
value of the universal/local bit to indicate global scope, "g" is
individual/group bit, and "m" are the bits of the manufacturer-
selected extension identifier. The IPv6 interface identifier
would be of the form:
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
+----------------+----------------+----------------+----------------+
The only change is inverting the value of the universal/local bit.
Links or Nodes with IEEE 802 48 bit MAC's
[EUI64] defines a method to create a IEEE EUI-64 identifier from
an IEEE 48bit MAC identifier. This is to insert two octets, with
hexadecimal values of 0xFF and 0xFE, in the middle of the 48 bit
MAC (between the company_id and vendor supplied id). For example
the 48 bit IEEE MAC with global scope:
|0 1|1 3|3 4|
|0 5|6 1|2 7|
+----------------+----------------+----------------+
|cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|
+----------------+----------------+----------------+
where "c" are the bits of the assigned company_id, "0" is the
value of the universal/local bit to indicate global scope, "g" is
individual/group bit, and "m" are the bits of the manufacturer-
selected extension identifier. The interface identifier would be
of the form:
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm|
+----------------+----------------+----------------+----------------+
When IEEE 802 48bit MAC addresses are available (on an interface
or a node), an implementation may use them to create interface
identifiers due to their availability and uniqueness properties.
Links with Non-Global Identifiers
There are a number of types of links that, while multi-access, do
not have globally unique link identifiers. Examples include
LocalTalk and Arcnet. The method to create an Modified EUI-64
format identifier is to take the link identifier (e.g., the
LocalTalk 8 bit node identifier) and zero fill it to the left.
For example a LocalTalk 8 bit node identifier of hexadecimal value
0x4F results in the following interface identifier:
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|0000000000000000|0000000000000000|0000000000000000|0000000001001111|
+----------------+----------------+----------------+----------------+
Note that this results in the universal/local bit set to "0" to
indicate local scope.
Links without Identifiers
There are a number of links that do not have any type of built-in
identifier. The most common of these are serial links and
configured tunnels. Interface identifiers must be chosen that are
unique for the link.
When no built-in identifier is available on a link the preferred
approach is to use a global interface identifier from another
interface or one which is assigned to the node itself. When using
this approach no other interface connecting the same node to the
same link may use the same identifier.
If there is no global interface identifier available for use on
the link the implementation needs to create a local-scope
interface identifier. The only requirement is that it be unique
on the link. There are many possible approaches to select a link-
unique interface identifier. These include:
Manual Configuration
Node Serial Number
Other node-specific token
The link-unique interface identifier should be generated in a
manner that it does not change after a reboot of a node or if
interfaces are added or deleted from the node.
The selection of the appropriate algorithm is link and
implementation dependent. The details on forming interface
identifiers are defined in the appropriate "IPv6 over <link>"
specification. It is strongly recommended that a collision
detection algorithm be implemented as part of any automatic
algorithm.
APPENDIX B: Changes from RFC-2373
---------------------------------
The following changes were made from RFC-2373 "IP Version 6
Addressing Architecture":
- Added description of multicast scop values.
- Many small changes to clarify and make the text more
consistent.
- Revised sections 2.4 and 2.5.6 to simplify and clarify how
different address types are identified. This was done to
insure that implementations do build in any knowledge about
global unicast format prefixes. Changes include:
o Removed Format Prefix (FP) terminology
o Revised list of address types only includes exceptions to
global unicast and a singe entry that identifies everything
else as Global Unicast.
o Removed list of defined prefix exceptions from section
2.5.6 as it is now the main part of section 2.4.
- Clarified text relating to EUI-64 identifiers to distinguish
between IPv6's "Modified EUI-64 format" identifiers and IEEE
EUI-64 identifiers.
- Combined the sections on the Global Unicast Addresses and NSAP
Addresses into a single section on Global Unicast Addresses,
generalized the Global Unicast format, and cited [AGGR] and
[NSAP] as examples.
- Reordered sections 2.5.4 and 2.5.5.
- Removed section 2.7.2 Assignment of New IPv6 Multicast
Addresses because this is being redefined elsewhere.
- Added an IANA considerations section that updates the IANA IPv6
address allocations and documents the NSAP and AGGR
allocations.
- Added clarification that the "IPv4-compatible IPv6 address"
must use global IPv4 unicast addresses.
- Divided references in to normative and non-normative sections.
- Added reference to [PRIV] in section 2.5.1
- Revised section 2.4 Address Type Representation to
- Added clarification that routers must not forward multicast
packets outside of the scope indicated in the multicast
address.
- Added clarification that routers must not forward packets with
source address of the unspecified address.
- Added clarification that routers must drop packets received on
an interface with destination address of loopback.
- Clarified the definition of IPv4-mapped addresses.
- Removed the ABNF Description of Text Representations Appendix.
- Removed the address block reserved for IPX addresses.
- Multicast scope changes:
o Changed name of scope value 1 from "node-local" to
"interface-local"
o Defined scope value 3 for "subnet-local" for multi-link
subnets
o Defined scope value 4 as "admin-local"
- Corrected reference to RFC1933 and updated references.
REFERENCES REFERENCES
Normative References Normative References
[IPV6] Deering, S., R. Hinden, "Internet Protocol, Version 6 [IPV6] Deering, S., R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC2460, December 1998. (IPv6) Specification", RFC2460, December 1998.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", RFC2026, BCP00009, October 1996. 3", RFC2026, BCP00009, October 1996.
skipping to change at page 27, line 6 skipping to change at page 27, line 6
[NSAP] Bound, J., B. Carpenter, D. Harrington, J. Houldsworth, A. [NSAP] Bound, J., B. Carpenter, D. Harrington, J. Houldsworth, A.
Lloyd, "OSI NSAPs and IPv6", RFC1888, August 1996. Lloyd, "OSI NSAPs and IPv6", RFC1888, August 1996.
[PRIV] Narten, T., R. Draves, "Privacy Extensions for Stateless [PRIV] Narten, T., R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC3041, January 2001. Address Autoconfiguration in IPv6", RFC3041, January 2001.
[TOKEN] Crawford, M., T. Narten, S. Thomas, "Transmission of IPv6 [TOKEN] Crawford, M., T. Narten, S. Thomas, "Transmission of IPv6
Packets over Token Ring Networks", RFC2470, December 1998. Packets over Token Ring Networks", RFC2470, December 1998.
[TRAN] Gilligan, R., E. Nordmark, "Transition Mechanisms for IPv6 [TRAN] Gilligan, R., E. Nordmark, "Transition Mechanisms for IPv6
Hosts and Routers", RFC1933, April 1996. Hosts and Routers", RFC2893, August 2000.
AUTHOR'S ADDRESSES AUTHOR'S ADDRESSES
Robert M. Hinden Robert M. Hinden
Nokia Nokia
313 Fairchild Drive 313 Fairchild Drive
Mountain View, CA 94043 Mountain View, CA 94043
USA USA
phone: +1 650 625-2004 phone: +1 650 625-2004
 End of changes. 20 change blocks. 
194 lines changed or deleted 222 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/