< draft-ietf-ipv6-addr-arch-v4-00.txt   draft-ietf-ipv6-addr-arch-v4-01.txt >
INTERNET-DRAFT R. Hinden, Nokia INTERNET-DRAFT R. Hinden, Nokia
October 9, 2003 S. Deering, Cisco Systems February 17, 2005 S. Deering, Cisco Systems
IP Version 6 Addressing Architecture IP Version 6 Addressing Architecture
<draft-ietf-ipv6-addr-arch-v4-00.txt> <draft-ietf-ipv6-addr-arch-v4-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, I certify that any applicable
all provisions of Section 10 of [RFC2026]. patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
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 The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet Draft expires May 14, 2004. This Internet Draft expires August 22, 2005.
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.
This document obsoletes RFC-3513 "IP Version 6 Addressing This document obsoletes RFC-3513 "IP Version 6 Addressing
skipping to change at page 2, line 32 skipping to change at page 2, line 32
2.6 Anycast Addresses.......................................12 2.6 Anycast Addresses.......................................12
2.6.1 Required Anycast Address............................14 2.6.1 Required Anycast Address............................14
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.............................18 2.8 A Node's Required Addresses.............................18
3. Security Considerations.....................................18 3. Security Considerations.....................................18
4. IANA Considerations.........................................19 4. IANA Considerations.........................................19
APPENDIX A: Creating Modified EUI-64 format Interface IDs......20 5. References..................................................19
APPENDIX B: Changes from RFC-3513..............................23 6. Author's Addresses..........................................20
REFERENCES.....................................................24 7. Disclaimer of Validity......................................20
AUTHOR'S ADDRESSES.............................................25 8. Copyright Statement.........................................20
9. Intellectual Property.......................................21
APPENDIX A: Creating Modified EUI-64 format Interface IDs......22
APPENDIX B: Changes from RFC-3513..............................25
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).
The authors would like to acknowledge the contributions of Paul The authors would like to acknowledge the contributions of Paul
Francis, Scott Bradner, Jim Bound, Brian Carpenter, Matt Crawford, Francis, Scott Bradner, Jim Bound, Brian Carpenter, Matt Crawford,
Deborah Estrin, Roger Fajman, Bob Fink, Peter Ford, Bob Gilligan, Deborah Estrin, Roger Fajman, Bob Fink, Peter Ford, Bob Gilligan,
Dimitry Haskin, Tom Harsch, Christian Huitema, Tony Li, Greg Dimitry Haskin, Tom Harsch, Christian Huitema, Tony Li, Greg
Minshall, Thomas Narten, Erik Nordmark, Yakov Rekhter, Bill Simpson, Minshall, Thomas Narten, Erik Nordmark, Yakov Rekhter, Bill Simpson,
Sue Thomson, Markku Savela, and Larry Masinter. Sue Thomson, Markku Savela, Larry Masinter, Jun-ichiro Itojun Hagino,
Tatuya Jinmei, Suresh Krishnan, and Mahmood Ali.
2.0 IPv6 ADDRESSING 2.0 IPv6 ADDRESSING
IPv6 addresses are 128-bit identifiers for interfaces and sets of IPv6 addresses are 128-bit identifiers for interfaces and sets of
interfaces (where "interface" is as defined in section 2 of [IPV6]). interfaces (where "interface" is as defined in Section 2 of [IPV6]).
There are three types of addresses: There are three types of addresses:
Unicast: An identifier for a single interface. A packet sent to a Unicast: An identifier for a single interface. A packet sent to a
unicast address is delivered to the interface identified unicast address is delivered to the interface identified
by that address. by that address.
Anycast: An identifier for a set of interfaces (typically Anycast: An identifier for a set of interfaces (typically
belonging to different nodes). A packet sent to an belonging to different nodes). A packet sent to an
anycast address is delivered to one of the interfaces anycast address is delivered to one of the interfaces
identified by that address (the "nearest" one, according identified by that address (the "nearest" one, according
skipping to change at page 4, line 14 skipping to change at page 4, line 15
end with, zero-valued fields. end with, zero-valued fields.
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 have multiple IPv6 addresses of any type single interface may also have multiple IPv6 addresses of any type
(unicast, anycast, and multicast) or scope. Unicast addresses with (unicast, anycast, and multicast) or scope. Unicast addresses with
scope greater than link-scope are not needed for interfaces that are scope greater than link-scope are not needed for interfaces that are
not used as the origin or destination of any IPv6 packets to or from not used as the origin or destination of any IPv6 packets to or 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
skipping to change at page 4, line 37 skipping to change at page 4, line 38
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
to the same link. to the same link.
2.2 Text Representation of Addresses 2.2 Text Representation of Addresses
There are three conventional forms for representing IPv6 addresses as There are three conventional forms for representing IPv6 addresses as
text strings: text strings:
1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the 1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are one to
hexadecimal values of the eight 16-bit pieces of the address. four hexadecimal digits of the eight 16-bit pieces of the address.
Examples: Examples:
FEDC:BA98:7654:3210:FEDC:BA98:7654:3210 ABCD:EF01:2345:6789:ABCD:EF01:2345:6789
1080:0:0:0:8:800:200C:417A 2001:DB8:0:0:8:800:200C:417A
Note that it is not necessary to write the leading zeros in an Note that it is not necessary to write the leading zeros in an
individual field, but there must be at least one numeral in every individual field, but there must be at least one numeral in every
field (except for the case described in 2.). field (except for the case described in 2.).
2. Due to some methods of allocating certain styles of IPv6 2. Due to some methods of allocating certain styles of IPv6
addresses, it will be common for addresses to contain long strings addresses, it will be common for addresses to contain long strings
of zero bits. In order to make writing addresses containing zero of zero bits. In order to make writing addresses containing zero
bits easier a special syntax is available to compress the zeros. bits easier a special syntax is available to compress the zeros.
The use of "::" indicates one or more groups of 16 bits of zeros. The use of "::" indicates one or more groups of 16 bits of zeros.
The "::" can only appear once in an address. The "::" can also be The "::" can only appear once in an address. The "::" can also be
used to compress leading or trailing zeros in an address. used to compress leading or trailing zeros in an address.
For example the following addresses: For example the following addresses:
1080:0:0:0:8:800:200C:417A a unicast address 2001:DB8:0:0:8:800:200C:417A a unicast address
FF01:0:0:0:0:0:0:101 a multicast address FF01:0:0:0:0:0:0:101 a multicast address
0:0:0:0:0:0:0:1 the loopback address 0:0:0:0:0:0:0:1 the loopback address
0:0:0:0:0:0:0:0 the unspecified addresses 0:0:0:0:0:0:0:0 the unspecified address
may be represented as: may be represented as:
1080::8:800:200C:417A a unicast address 2001:DB8::8:800:200C:417A a unicast address
FF01::101 a multicast address FF01::101 a multicast address
::1 the loopback address ::1 the loopback address
:: the unspecified addresses :: the unspecified address
3. An alternative form that is sometimes more convenient when dealing 3. An alternative form that is sometimes more convenient when dealing
with a mixed environment of IPv4 and IPv6 nodes is with a mixed environment of IPv4 and IPv6 nodes is
x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of
the six high-order 16-bit pieces of the address, and the 'd's are the six high-order 16-bit pieces of the address, and the 'd's are
the decimal values of the four low-order 8-bit pieces of the the decimal values of the four low-order 8-bit pieces of the
address (standard IPv4 representation). Examples: address (standard IPv4 representation). Examples:
0:0:0:0:0:0:13.1.68.3 0:0:0:0:0:0:13.1.68.3
skipping to change at page 6, line 8 skipping to change at page 6, line 8
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 [CIDR]. An way IPv4 addresses prefixes are written in CIDR notation [CIDR]. An
IPv6 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
the prefix. the prefix.
For example, the following are legal representations of the 60-bit For example, the following are legal representations of the 60-bit
prefix 12AB00000000CD3 (hexadecimal): prefix 20010DB80000CD3 (hexadecimal):
12AB:0000:0000:CD30:0000:0000:0000:0000/60 2001:0DB8:0000:CD30:0000:0000:0000:0000/60
12AB::CD30:0:0:0:0/60 2001:0DB8::CD30:0:0:0:0/60
12AB:0:0:CD30::/60 2001:0DB8:0:CD30::/60
The following are NOT legal representations of the above prefix: The following are NOT legal representations of the above prefix:
12AB:0:0:CD3/60 may drop leading zeros, but not trailing zeros, 2001:0DB8:0:CD3/60 may drop leading zeros, but not trailing
within any 16-bit chunk of the address zeros, within any 16-bit chunk of the address
12AB::CD30/60 address to left of "/" expands to 2001:0DB8::CD30/60 address to left of "/" expands to
12AB:0000:0000:0000:0000:000:0000:CD30 2001:0DB8:0000:0000:0000:0000:0000:CD30
12AB::CD3/60 address to left of "/" expands to 2001:0DB8::CD3/60 address to left of "/" expands to
12AB:0000:0000:0000:0000:000:0000:0CD3 2001:0DB8:0000:0000:0000:0000:0000:0CD3
When writing both a node address and a prefix of that node address When writing both a node address and a prefix of that node address
(e.g., the node's subnet prefix), the two can combined as follows: (e.g., the node's subnet prefix), the two can combined as follows:
the node address 12AB:0:0:CD30:123:4567:89AB:CDEF the node address 2001:0DB8:0:CD30:123:4567:89AB:CDEF
and its subnet number 12AB:0:0:CD30::/60 and its subnet number 2001:0DB8:0:CD30::/60
can be abbreviated as 12AB:0:0:CD30:123:4567:89AB:CDEF/60 can be abbreviated as 2001:0DB8:0:CD30:123:4567:89AB:CDEF/60
2.4 Address Type Identification 2.4 Address Type Identification
The type of an IPv6 address is identified by the high-order bits of The type of an IPv6 address is identified by the high-order bits of
the address, as follows: the address, as follows:
Address type Binary prefix IPv6 notation Section Address type Binary prefix IPv6 notation Section
------------ ------------- ------------- ------- ------------ ------------- ------------- -------
Unspecified 00...0 (128 bits) ::/128 2.5.2 Unspecified 00...0 (128 bits) ::/128 2.5.2
Loopback 00...1 (128 bits) ::1/128 2.5.3 Loopback 00...1 (128 bits) ::1/128 2.5.3
Multicast 11111111 FF00::/8 2.7 Multicast 11111111 FF00::/8 2.7
Link-local unicast 1111111010 FE80::/10 2.5.6 Link-local unicast 1111111010 FE80::/10 2.5.6
Global unicast (everything else) Global unicast (everything else)
Anycast addresses are taken from the unicast address spaces (of any Anycast addresses are taken from the unicast address spaces (of any
scope) and are not syntactically distinguishable from unicast scope) and are not syntactically distinguishable from unicast
addresses. addresses.
The general format of global unicast addresses is described in The general format of global unicast addresses is described in
section 2.5.4. Some special-purpose subtypes of global unicast Section 2.5.4. Some special-purpose subtypes of global unicast
addresses which contain embedded IPv4 addresses (for the purposes of addresses which contain embedded IPv4 addresses (for the purposes of
IPv4-IPv6 interoperation) are described in section 2.5.5. IPv4-IPv6 interoperation) are described in Section 2.5.5.
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. 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 (deprecated, see section 2.5.7), global unicast, site-local unicast (deprecated, see Section 2.5.7),
and link-local unicast. There are also some special-purpose subtypes and link-local unicast. There are also some special-purpose subtypes
of global unicast, such as IPv6 addresses with embedded IPv4 of global unicast, such as IPv6 addresses with embedded IPv4
addresses or encoded NSAP addresses. Additional address types or addresses. Additional address types or subtypes can be defined in
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
(for instance, host versus router). At a minimum, a node may (for instance, host versus router). At a minimum, a node may
consider that unicast addresses (including its own) have no internal consider that unicast addresses (including its own) have no internal
structure: structure:
| 128 bits | | 128 bits |
+-----------------------------------------------------------------+ +-----------------------------------------------------------------+
| node address | | node address |
+-----------------------------------------------------------------+ +-----------------------------------------------------------------+
A slightly sophisticated host (but still rather simple) may A slightly sophisticated host (but still rather simple) may
additionally be aware of subnet prefix(es) for the link(s) it is additionally be aware of subnet prefix(es) for the link(s) it is
attached to, where different addresses may have different values for attached to, where different addresses may have different values for
n: n:
| n bits | 128-n bits | | n bits | 128-n bits |
+------------------------------------------------+----------------+ +-------------------------------+---------------------------------+
| subnet prefix | interface ID | | subnet prefix | interface ID |
+------------------------------------------------+----------------+ +-------------------------------+---------------------------------+
Though a very simple router may have no knowledge of the internal Though a very simple router may have no knowledge of the internal
structure of IPv6 unicast addresses, routers will more generally have structure of IPv6 unicast addresses, routers will more generally have
knowledge of one or more of the hierarchical boundaries for the knowledge of one or more of the hierarchical boundaries for the
operation of routing protocols. The known boundaries will differ operation of routing protocols. The known boundaries will differ
from router to router, depending on what positions the router holds from router to router, depending on what positions the router holds
in the routing hierarchy. in the routing hierarchy.
Except for the knowledge of the subnet boundary discussed in the Except for the knowledge of the subnet boundary discussed in the
pervious paragraphs nodes should not make any assumptions about the pervious paragraphs nodes should not make any assumptions about the
skipping to change at page 9, line 38 skipping to change at page 9, line 38
universal/local bit, "g" is the individual/group bit, and "c" are the universal/local bit, "g" is the individual/group bit, and "c" are the
bits of the company_id. Appendix A: "Creating Modified EUI-64 format bits of the company_id. Appendix A: "Creating Modified EUI-64 format
Interface Identifiers" provides examples on the creation of Modified Interface Identifiers" provides examples on the creation of Modified
EUI-64 format based interface identifiers. EUI-64 format based interface identifiers.
The motivation for inverting the "u" bit when forming an interface The motivation for inverting the "u" bit when forming an interface
identifier is to make it easy for system administrators to hand identifier is to make it easy for system administrators to hand
configure non-global identifiers when hardware tokens are not configure non-global identifiers when hardware tokens are not
available. This is expected to be case for serial links, tunnel end- available. This is expected to be case for serial links, tunnel end-
points, etc. The alternative would have been for these to be of the points, etc. The alternative would have been for these to be of the
form 0200:0:0:1, 0200:0:0:2, etc., instead of the much simpler 1, 2, form 0200:0:0:1, 0200:0:0:2, etc., instead of the much simpler
etc. 0:0:0:1, 0:0:0:2, etc.
IPv6 nodes are not required to validate that interface identifiers IPv6 nodes are not required to validate that interface identifiers
created with modified EUI-64 tokens with the "u" bit set to universal created with modified EUI-64 tokens with the "u" bit set to universal
are unique. are unique.
The use of the universal/local bit in the Modified EUI-64 format The use of the universal/local bit in the Modified EUI-64 format
identifier is to allow development of future technology that can take identifier is to allow development of future technology that can take
advantage of interface identifiers with universal scope. advantage of interface identifiers with universal scope.
The details of forming interface identifiers are defined in the The details of forming interface identifiers are defined in the
skipping to change at page 10, line 23 skipping to change at page 10, line 23
its own address. its own address.
The unspecified address must not be used as the destination address The unspecified address must not be used as the destination address
of IPv6 packets or in IPv6 Routing Headers. An IPv6 packet with a of IPv6 packets or in IPv6 Routing Headers. An IPv6 packet with a
source address of unspecified must never be forwarded by an IPv6 source address of unspecified must never be forwarded by an IPv6
router. router.
2.5.3 The Loopback Address 2.5.3 The Loopback Address
The unicast address 0:0:0:0:0:0:0:1 is called the loopback address. The unicast address 0:0:0:0:0:0:0:1 is called the loopback address.
It may be used by a node to send an IPv6 packet to itself. It may It may be used by a node to send an IPv6 packet to itself. It must
never be assigned to any physical interface. It is treated as not be assigned to any physical interface. It is treated as having
having link-local scope, and may be thought of as the link-local link-local scope, and may be thought of as the link-local unicast
unicast address of a virtual interface (typically called "the address of a virtual interface (typically called "the loopback
loopback interface") to an imaginary link that goes nowhere. interface") to an imaginary link that goes nowhere.
The loopback address must not be used as the source address in IPv6 The loopback address must not be used as the source address in IPv6
packets that are sent outside of a single node. An IPv6 packet with packets that are sent outside of a single node. An IPv6 packet with
a destination address of loopback must never be sent outside of a a destination address of loopback must never be sent outside of a
single node and must never be forwarded by an IPv6 router. A packet single node and must never be forwarded by an IPv6 router. A packet
received on an interface with destination address of loopback must be received on an interface with destination address of loopback must be
dropped. dropped.
2.5.4 Global Unicast Addresses 2.5.4 Global Unicast Addresses
The general format for IPv6 global unicast addresses is as follows: The general format for IPv6 global unicast addresses is as follows:
| n bits | m bits | 128-n-m bits | | n bits | m bits | 128-n-m bits |
+------------------------+-----------+----------------------------+ +------------------------+-----------+----------------------------+
| global routing prefix | subnet ID | interface ID | | global routing prefix | subnet ID | interface ID |
+------------------------+-----------+----------------------------+ +------------------------+-----------+----------------------------+
where the global routing prefix is a (typically hierarchically- where the global routing prefix is a (typically hierarchically-
structured) value assigned to a site (a cluster of subnets/links), structured) value assigned to a site (a cluster of subnets/links),
the subnet ID is an identifier of a link within the site, and the the subnet ID is an identifier of a link within the site, and the
interface ID is as defined in section 2.5.1. interface ID is as defined in Section 2.5.1.
All global unicast addresses other than those that start with binary All global unicast addresses other than those that start with binary
000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as 000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as
described in section 2.5.1. Global unicast addresses that start with described in Section 2.5.1. Global unicast addresses that start with
binary 000 have no such constraint on the size or structure of the binary 000 have no such constraint on the size or structure of the
interface ID field. interface ID field.
Examples of global unicast addresses that start with binary 000 are Examples of global unicast addresses that start with binary 000 are
the IPv6 address with embedded IPv4 addresses described in section the IPv6 address with embedded IPv4 addresses described in Section
2.5.5 and the IPv6 address containing encoded NSAP addresses 2.5.5. An example of global addresses starting with a binary value
specified in [NSAP]. An example of global addresses starting with a other than 000 (and therefore having a 64-bit interface ID field) can
binary value other than 000 (and therefore having a 64-bit interface be found in [GLOBAL].
ID field) can be found in [GLOBAL].
2.5.5 IPv6 Addresses with Embedded IPv4 Addresses 2.5.5 IPv6 Addresses with Embedded IPv4 Addresses
The IPv6 transition mechanisms [TRAN] include a technique for hosts The IPv6 transition mechanisms [TRAN] include a technique for hosts
and routers to dynamically tunnel IPv6 packets over IPv4 routing and routers to dynamically tunnel IPv6 packets over IPv4 routing
infrastructure. IPv6 nodes that use this technique are assigned infrastructure. IPv6 nodes that use this technique are assigned
special IPv6 unicast addresses that carry a global IPv4 address in special IPv6 unicast addresses that carry a global IPv4 address in
the low-order 32 bits. This type of address is termed an the low-order 32 bits. This type of address is termed an
"IPv4-compatible IPv6 address" and has the format: "IPv4-compatible IPv6 address" and has the format:
skipping to change at page 12, line 44 skipping to change at page 12, line 44
|1111111011| subnet ID | interface ID | |1111111011| subnet ID | interface ID |
+----------+-------------------------+----------------------------+ +----------+-------------------------+----------------------------+
The special behavior of this prefix defined in [RFC3513] must no The special behavior of this prefix defined in [RFC3513] must no
longer be supported in new implementations (i.e., new implementations longer be supported in new implementations (i.e., new implementations
must treat this prefix as Global Unicast). must treat this prefix as Global Unicast).
Existing implementations and deployments may continue to use this Existing implementations and deployments may continue to use this
prefix. prefix.
Note: The text in this section of this internet-draft is dependent
on [SLDEP] and is subject to change.
2.6 Anycast Addresses 2.6 Anycast Addresses
An IPv6 anycast address is an address that is assigned to more than An IPv6 anycast address is an address that is assigned to more than
one interface (typically belonging to different nodes), with the one interface (typically belonging to different nodes), with the
property that a packet sent to an anycast address is routed to the property that a packet sent to an anycast address is routed to the
"nearest" interface having that address, according to the routing "nearest" interface having that address, according to the routing
protocols' measure of distance. protocols' measure of distance.
Anycast addresses are allocated from the unicast address space, using Anycast addresses are allocated from the unicast address space, using
any of the defined unicast address formats. Thus, anycast addresses any of the defined unicast address formats. Thus, anycast addresses
skipping to change at page 13, line 27 skipping to change at page 13, line 24
address that identifies the topological region in which all address that identifies the topological region in which all
interfaces belonging to that anycast address reside. Within the interfaces belonging to that anycast address reside. Within the
region identified by P, the anycast address must be maintained as a region identified by P, the anycast address must be maintained as a
separate entry in the routing system (commonly referred to as a "host separate entry in the routing system (commonly referred to as a "host
route"); outside the region identified by P, the anycast address may route"); outside the region identified by P, the anycast address may
be aggregated into the routing entry for prefix P. be aggregated into the routing entry for prefix P.
Note that in the worst case, the prefix P of an anycast set may be Note that in the worst case, the prefix P of an anycast set may be
the null prefix, i.e., the members of the set may have no topological the null prefix, i.e., the members of the set may have no topological
locality. In that case, the anycast address must be maintained as a locality. In that case, the anycast address must be maintained as a
separate routing entry throughout the entire internet, which presents separate routing entry throughout the entire Internet, which presents
a severe scaling limit on how many such "global" anycast sets may be a severe scaling limit on how many such "global" anycast sets may be
supported. Therefore, it is expected that support for global anycast supported. Therefore, it is expected that support for global anycast
sets may be unavailable or very restricted. sets may be unavailable or very restricted.
One expected use of anycast addresses is to identify the set of One expected use of anycast addresses is to identify the set of
routers belonging to an organization providing internet service. routers belonging to an organization providing Internet service.
Such addresses could be used as intermediate addresses in an IPv6 Such addresses could be used as intermediate addresses in an IPv6
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 are specified, the following has been gained and solutions are specified, the 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.
skipping to change at page 16, line 22 skipping to change at page 16, line 19
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.
FF02:0:0:0:0:0:0:101 means all NTP servers on the same link as FF02:0:0:0:0:0:0:101 means all NTP servers on the same link as
the sender. the sender.
FF05:0:0:0:0:0:0:101 means all NTP servers in the same site as FF05:0:0:0:0:0:0:101 means all NTP servers in the same site as
the sender. the sender.
FF0E:0:0:0:0:0:0:101 means all NTP servers in the internet. FF0E:0:0:0:0:0:0:101 means all NTP servers in the Internet.
Non-permanently-assigned multicast addresses are meaningful only Non-permanently-assigned multicast addresses are meaningful only
within a given scope. For example, a group identified by the non- within a given scope. For example, a group identified by the non-
permanent, site-local multicast address FF15:0:0:0:0:0:0:101 at one permanent, site-local multicast address FF15:0:0:0:0:0:0:101 at one
site bears no relationship to a group using the same address at a site bears no relationship to a group using the same address at a
different site, nor to a non-permanent group using the same group ID different site, nor to a non-permanent group using the same group ID
with different scope, nor to a permanent group with the same group with different scope, nor to a permanent group with the same group
ID. ID.
Multicast addresses must not be used as source addresses in IPv6 Multicast addresses must not be used as source addresses in IPv6
skipping to change at page 18, line 4 skipping to change at page 17, line 50
Solicited-node multicast address are computed as a function of a Solicited-node multicast address are computed as a function of a
node's unicast and anycast addresses. A solicited-node multicast node's unicast and anycast addresses. A solicited-node multicast
address is formed by taking the low-order 24 bits of an address address is formed by taking the low-order 24 bits of an address
(unicast or anycast) and appending those bits to the prefix (unicast or anycast) and appending those bits to the prefix
FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address in the FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address in the
range range
FF02:0:0:0:0:1:FF00:0000 FF02:0:0:0:0:1:FF00:0000
to to
FF02:0:0:0:0:1:FFFF:FFFF FF02:0:0:0:0:1:FFFF:FFFF
For example, the solicited node multicast address corresponding to For example, the solicited node multicast address corresponding to
the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C. IPv6 the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C. IPv6
addresses that differ only in the high-order bits, e.g. due to addresses that differ only in the high-order bits, e.g. due to
multiple high-order prefixes associated with different aggregations, multiple high-order prefixes associated with different aggregations,
will map to the same solicited-node address thereby, reducing the will map to the same solicited-node address thereby, reducing the
number of multicast addresses a node must join. number of multicast addresses a node must join.
A node is required to compute and join (on the appropriate interface) A node is required to compute and join (on the appropriate interface)
the associated Solicited-Node multicast addresses for every unicast the associated Solicited-Node multicast addresses for all Unicast and
and anycast address it is assigned. Anycast Addresses that have been configured for the node's interfaces
(manually or automatically).
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 Its 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 The 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].
4. IANA Considerations 4. IANA Considerations
IANA is requested to reserve and not to reassign the FEC0::/10 prefix None.
(binary 1111111011) unless requested to do so by a future IETF
standards action.
The table at http://www.isi.edu/in- 5. References
notes/iana/assignments/ipv6-address-space.txt should have the line
for "Site-Local Unicast Addresses" replaced with
Reserved 1111 1110 11 1/1024 5.1 Normative References
The following note should also be added to the same page: [IPV6] Deering, S., R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC2460, December 1998.
3) The FEC0::/10 prefix (binary 1111111011) was previously known [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
as site-local. It's usage as Site-Local is now deprecated and 3", RFC2026, BCP00009, October 1996.
is currently reserved.
[SLDEP] C. Huitema, B. Carpenter, "Deprecating Site Local
Addresses", RFC3879, September 2004.
5.2 Non-Normative References
[ANYCST] Partridge, C., T. Mendez, and W. Milliken, "Host Anycasting
Service", RFC1546, November 1993.
[AUTH] Kent, S., R. Atkinson, "IP Authentication Header", RFC2402,
November 1998.
[CIDR] Fuller, V., Li, T., Yu, J., Varadhan, K., "Classless Inter-
Domain Routing (CIDR): An Address Assignment and
Aggregation Strategy", RFC1519, September 1993.
[ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC2464, December 1998.
[EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
Registration Authority",
http://standards.ieee.org/regauth/oui/tutorials/EUI64.html
, March 1997.
[FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI
Networks", RFC2467, December 1998.
[GLOBAL] Hinden, R., S. Deering, E. Nordmark, "IPv6 Global Unicast
Address Format", RFC3587, August 2003.
[MASGN] Hinden, R., "IPv6 Multicast Address Assignments", RFC2375,
July 1998.
[PRIV] Narten, T., R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC3041, January 2001.
[TOKEN] Crawford, M., T. Narten, S. Thomas, "Transmission of IPv6
Packets over Token Ring Networks", RFC2470, December 1998.
[TRAN] Gilligan, R., E. Nordmark, "Transition Mechanisms for IPv6
Hosts and Routers", RFC2893, August 2000.
6. Author's Addresses
Robert M. Hinden
Nokia
313 Fairchild Drive
Mountain View, CA 94043
USA
phone: +1 650 625-2004
email: bob.hinden@nokia.com
Stephen E. Deering
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
7. Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
8. Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
9. Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
APPENDIX A: Creating Modified EUI-64 format Interface Identifiers APPENDIX A: Creating Modified EUI-64 format Interface Identifiers
------------------------------------------------------------------ ------------------------------------------------------------------
Depending on the characteristics of a specific link or node there are Depending on the characteristics of a specific link or node there are
a number of approaches for creating Modified EUI-64 format interface a number of approaches for creating Modified EUI-64 format interface
identifiers. This appendix describes some of these approaches. identifiers. This appendix describes some of these approaches.
Links or Nodes with IEEE EUI-64 Identifiers Links or Nodes with IEEE EUI-64 Identifiers
skipping to change at page 21, line 30 skipping to change at page 23, line 30
|cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm| |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm|
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
When IEEE 802 48bit MAC addresses are available (on an interface or a When IEEE 802 48bit MAC addresses are available (on an interface or a
node), an implementation may use them to create interface identifiers node), an implementation may use them to create interface identifiers
due to their availability and uniqueness properties. due to their availability and uniqueness properties.
Links with Other Kinds of Identifiers Links with Other Kinds of Identifiers
There are a number of types of links that have link-layer interface There are a number of types of links that have link-layer interface
identifiers other than IEEE EIU-64 or IEEE 802 48-bit MACs. Examples identifiers other than IEEE EUI-64 or IEEE 802 48-bit MACs. Examples
include LocalTalk and Arcnet. The method to create an Modified include LocalTalk and Arcnet. The method to create an Modified
EUI-64 format identifier is to take the link identifier (e.g., the 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 LocalTalk 8 bit node identifier) and zero fill it to the left. For
example a LocalTalk 8 bit node identifier of hexadecimal value 0x4F example a LocalTalk 8 bit node identifier of hexadecimal value 0x4F
results in the following interface identifier: results in the following interface identifier:
|0 1|1 3|3 4|4 6| |0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3| |0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
|0000000000000000|0000000000000000|0000000000000000|0000000001001111| |0000000000000000|0000000000000000|0000000000000000|0000000001001111|
skipping to change at page 23, line 12 skipping to change at page 25, line 12
recommended that a collision detection algorithm be implemented as recommended that a collision detection algorithm be implemented as
part of any automatic algorithm. part of any automatic algorithm.
APPENDIX B: Changes from RFC-3513 APPENDIX B: Changes from RFC-3513
--------------------------------- ---------------------------------
The following changes were made from RFC-3513 "IP Version 6 The following changes were made from RFC-3513 "IP Version 6
Addressing Architecture": Addressing Architecture":
o Deprecated the Site-Local prefix. Changes included o Deprecated the Site-Local prefix. Changes included
- Removed Site-Local from special list of prefixes in section - Removed Site-Local from special list of prefixes in Section
2.4. 2.4.
- Split section titled "Local-use IPv6 Unicast Addresses" into - Split section titled "Local-use IPv6 Unicast Addresses" into
two sections, "Link-Local IPv6 Unicast Addresses" and "Site- two sections, "Link-Local IPv6 Unicast Addresses" and "Site-
Local IPv6 Unicast Addresses". Local IPv6 Unicast Addresses".
- Added text to new section describing Site-Local deprecation. - Added text to new section describing Site-Local deprecation.
- Added instructions in IANA Considerations to reserve and not
reassign the site-local prefix.
o Changes to resolve issues raised in IAB response to Robert Elz o Changes to resolve issues raised in IAB response to Robert Elz
appeal. Changes include: appeal. Changes include:
- Added clarification to section 2.5 that nodes should make no - Added clarification to Section 2.5 that nodes should make no
assumptions about the structure of an IPv6 address. assumptions about the structure of an IPv6 address.
- Changed the text in section 2.5.1 and Appendix A to refer to - Changed the text in Section 2.5.1 and Appendix A to refer to
the modified EUI-64 format interface identifiers with the "u" the modified EUI-64 format interface identifiers with the "u"
bit set to one (1) as universal. bit set to one (1) as universal.
- Added clarification to section 2.5.1 that IPv6 nodes are not - Added clarification to Section 2.5.1 that IPv6 nodes are not
required to validate that interface identifiers created in required to validate that interface identifiers created in
modified EUI-64 format with the "u" bit set to one are unique. modified EUI-64 format with the "u" bit set to one are unique.
- Changed the reference indicated in section 2.5.4 "Global Unicast o Changed the reference indicated in Section 2.5.4 "Global Unicast
Addresses" to RFC3587. Addresses" to RFC3587.
REFERENCES o Removed mention of NSAP addresses in examples.
Normative References
[IPV6] Deering, S., R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC2460, December 1998.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", RFC2026, BCP00009, October 1996.
[SLDEP] C. Huitema, B. Carpenter, "Deprecating Site Local
Addresses", Internet Draft, <draft-ietf-ipv6-deprecate-
site-local-01.txt>, September 2003.
Non-Normative References
[ANYCST] Partridge, C., T. Mendez, and W. Milliken, "Host Anycasting
Service", RFC1546, November 1993.
[AUTH] Kent, S., R. Atkinson, "IP Authentication Header", RFC2402,
November 1998.
[CIDR] Fuller, V., Li, T., Yu, J., Varadhan, K., "Classless Inter-
Domain Routing (CIDR): An Address Assignment and
Aggregation Strategy", RFC1519, September 1993.
[ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC2464, December 1998.
[EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
Registration Authority",
http://standards.ieee.org/regauth/oui/tutorials/EUI64.html
, March 1997.
[FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI
Networks", RFC2467, December 1998.
[GLOBAL] Hinden, R., S. Deering, E. Nordmark, "IPv6 Global Unicast
Address Format", RFC3587, August 2003.
[MASGN] Hinden, R., "IPv6 Multicast Address Assignments", RFC2375,
July 1998.
[NSAP] Bound, J., B. Carpenter, D. Harrington, J. Houldsworth, A.
Lloyd, "OSI NSAPs and IPv6", RFC1888, August 1996.
[PRIV] Narten, T., R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC3041, January 2001.
[TOKEN] Crawford, M., T. Narten, S. Thomas, "Transmission of IPv6
Packets over Token Ring Networks", RFC2470, December 1998.
[TRAN] Gilligan, R., E. Nordmark, "Transition Mechanisms for IPv6
Hosts and Routers", RFC2893, August 2000.
AUTHOR'S ADDRESSES
Robert M. Hinden
Nokia
313 Fairchild Drive
Mountain View, CA 94043
USA
phone: +1 650 625-2004
email: hinden@iprg.nokia.com
Stephen E. Deering o Clarified that the "x" in the textual representation can be one to
Cisco Systems, Inc. four digits.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
phone: +1 408 527-8213 o Editorial changes.
email: deering@cisco.com
 End of changes. 59 change blocks. 
162 lines changed or deleted 197 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/