< draft-ietf-ipv6-addr-arch-v4-03.txt   draft-ietf-ipv6-addr-arch-v4-04.txt >
INTERNET-DRAFT R. Hinden, Nokia INTERNET-DRAFT R. Hinden, Nokia
April 29, 2005 S. Deering, Cisco Systems May 20, 2005 S. Deering, Cisco Systems
Obsoletes: RFC3513
IP Version 6 Addressing Architecture IP Version 6 Addressing Architecture
<draft-ietf-ipv6-addr-arch-v4-03.txt> <draft-ietf-ipv6-addr-arch-v4-04.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 1, line 33 skipping to change at page 1, line 34
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at 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 November 3, 2005. This Internet Draft expires November 25, 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. The document includes the IPv6 addressing model,
model, text representations of IPv6 addresses, definition of IPv6 text representations of IPv6 addresses, definition of IPv6 unicast
unicast addresses, anycast addresses, and multicast addresses, and an addresses, anycast addresses, and multicast addresses, and an IPv6
IPv6 node's required addresses. node's required addresses.
This document obsoletes RFC-3513 "IP Version 6 Addressing This document obsoletes RFC-3513 "IP Version 6 Addressing
Architecture". Architecture".
Table of Contents Table of Contents
1. Introduction.................................................3 1. Introduction.................................................3
2. IPv6 Addressing..............................................3 2. IPv6 Addressing..............................................3
2.1 Addressing Model.........................................4 2.1 Addressing Model.........................................4
skipping to change at page 8, line 28 skipping to change at page 8, line 28
+-------------------------------+---------------------------------+ +-------------------------------+---------------------------------+
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 previous paragraphs nodes should not make any assumptions about the
structure of an IPv6 address. structure of an IPv6 address.
2.5.1 Interface Identifiers 2.5.1 Interface Identifiers
Interface identifiers in IPv6 unicast addresses are used to identify Interface identifiers in IPv6 unicast addresses are used to identify
interfaces on a link. They are required to be unique within a subnet interfaces on a link. They are required to be unique within a subnet
prefix. It is recommended that the same interface identifier not be prefix. It is recommended that the same interface identifier not be
assigned to different nodes on a link. They may also be unique over assigned to different nodes on a link. They may also be unique over
a broader scope. In some cases an interface's identifier will be a broader scope. In some cases an interface's identifier will be
derived directly from that interface's link-layer address. The same derived directly from that interface's link-layer address. The same
skipping to change at page 14, line 36 skipping to change at page 14, line 36
An IPv6 multicast address is an identifier for a group of interfaces An IPv6 multicast address is an identifier for a group of interfaces
(typically on different nodes). An interface may belong to any (typically on different nodes). An interface may belong to any
number of multicast groups. Multicast addresses have the following number of multicast groups. Multicast addresses have the following
format: format:
| 8 | 4 | 4 | 112 bits | | 8 | 4 | 4 | 112 bits |
+------ -+----+----+---------------------------------------------+ +------ -+----+----+---------------------------------------------+
|11111111|flgs|scop| group ID | |11111111|flgs|scop| group ID |
+--------+----+----+---------------------------------------------+ +--------+----+----+---------------------------------------------+
binary 11111111 at the start of the address identifies the binary 11111111 at the start of the address identifies the address
address as being a multicast address. as being a multicast address.
+-+-+-+-+ +-+-+-+-+
flgs is a set of 4 flags: |0|0|0|T| flgs is a set of 4 flags: |0|R|P|T|
+-+-+-+-+ +-+-+-+-+
The high-order 3 flags are reserved, and must be The high-order flag is reserved, and must be initialized to 0.
initialized to 0.
T = 0 indicates a permanently-assigned ("well-known") T = 0 indicates a permanently-assigned ("well-known") multicast
multicast address, assigned by the Internet Assigned Number address, assigned by the Internet Assigned Number Authority
Authority (IANA). (IANA).
T = 1 indicates a non-permanently-assigned ("transient") T = 1 indicates a non-permanently-assigned ("transient" or
multicast address. "dynamically" assigned) multicast address.
scop is a 4-bit multicast scope value used to limit the scope of The P flag's definition and usage can be found in [RFC3306].
the multicast group. The values are:
0 reserved The R flag's definition and usage can be found in [RFC3956].
1 interface-local scope
2 link-local scope
3 reserved
4 admin-local scope
5 site-local scope
6 (unassigned)
7 (unassigned)
8 organization-local scope
9 (unassigned)
A (unassigned)
B (unassigned)
C (unassigned)
D (unassigned)
E global scope
F reserved
interface-local scope spans only a single interface on a scop is a 4-bit multicast scope value used to limit the scope of
node, and is useful only for loopback transmission of the multicast group. The values are:
multicast.
link-local multicast scope spans the same 0 reserved
topological region as the corresponding unicast scope. 1 interface-local scope
2 link-local scope
3 reserved
4 admin-local scope
5 site-local scope
6 (unassigned)
7 (unassigned)
8 organization-local scope
9 (unassigned)
A (unassigned)
B (unassigned)
C (unassigned)
D (unassigned)
E global scope
F reserved
admin-local scope is the smallest scope that must be interface-local scope spans only a single interface on a
administratively configured, i.e., not automatically node, and is useful only for loopback transmission of
derived from physical connectivity or other, non- multicast.
multicast-related configuration.
site-local scope is intended to span a single site. link-local multicast scope spans the same
topological region as the corresponding unicast scope.
organization-local scope is intended to span multiple admin-local scope is the smallest scope that must be
sites belonging to a single organization. administratively configured, i.e., not automatically
derived from physical connectivity or other, non-
multicast-related configuration.
scopes labeled "(unassigned)" are available for site-local scope is intended to span a single site.
administrators to define additional multicast regions.
group ID identifies the multicast group, either permanent or organization-local scope is intended to span multiple
transient, within the given scope. sites belonging to a single organization.
scopes labeled "(unassigned)" are available for
administrators to define additional multicast regions.
group ID identifies the multicast group, either permanent or
transient, within the given scope. Additional definitions of the
multicast group ID field structure is defined in [RFC3306].
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.
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
the sender. 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
the sender. 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 19, line 8 skipping to change at page 19, line 8
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
The "IPv4-compatible IPv6 address" is deprecated by this document. The "IPv4-compatible IPv6 address" is deprecated by this document.
The IANA should continue to list the address block containing this The IANA should continue to list the address block containing these
address as "Reserved by IETF" and not reassign it for any other addresses at http://www.iana.org/assignments/ipv6-address-space as
purpose. "Reserved by IETF" and not reassign it for any other purpose. For
example:
The IANA should update the references for the IPv6 Address 0000::/8 Reserved by IETF [RFC3513] [1]
The IANA is requested to add the following note and link it to this
address block.
[5] 0000::/96 was previously defined as the "IPv4-compatible IPv6
address" prefix. This definition has been deprecated by
[RFC-ietf-ipv6-addr-arch-v4-04.txt].
The IANA is requested to update the references for the IPv6 Address
Architecture in the IANA registries to this RFC when it is published. Architecture in the IANA registries to this RFC when it is published.
5. References 5. References
5.1 Normative References 5.1 Normative References
[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [IPV6] Deering, S. and 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.
5.2 Non-Normative References 5.2 Non-Normative References
[ANYCST] Partridge, C., Mendez, T., and W. Milliken, "Host
Anycasting Service", RFC1546, November 1993.
[AUTH] Kent, S., and R. Atkinson, "IP Authentication Header", [AUTH] Kent, S., and R. Atkinson, "IP Authentication Header",
RFC2402, November 1998. RFC2402, November 1998.
[CIDR] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless [CIDR] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless
Inter-Domain Routing (CIDR): An Address Assignment and Inter-Domain Routing (CIDR): An Address Assignment and
Aggregation Strategy", RFC1519, September 1993. Aggregation Strategy", RFC1519, September 1993.
[ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet [ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC2464, December 1998. Networks", RFC2464, December 1998.
[EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
Registration Authority", Registration Authority",
http://standards.ieee.org/regauth/oui/tutorials/EUI64.html http://standards.ieee.org/regauth/oui/tutorials/EUI64.html,
, March 1997. March 1997.
[FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI [FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI
Networks", RFC2467, December 1998. Networks", RFC2467, December 1998.
[GLOBAL] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global [GLOBAL] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
Unicast Address Format", RFC3587, August 2003. Unicast Address Format", RFC3587, August 2003.
[MASGN] Hinden, R., "IPv6 Multicast Address Assignments", RFC2375,
July 1998.
[PRIV] Narten, T. and R. Draves, "Privacy Extensions for Stateless [PRIV] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC3041, January 2001. Address Autoconfiguration in IPv6", RFC3041, January 2001.
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
Multicast Addresses", RFC 3306, August 2002.
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous Point
(RP) Address in an IPv6 Multicast Address", RFC 3956,
November 2004.
[RFC4038] Shin, M-K., et. al., "Application Aspects of IPv6 [RFC4038] Shin, M-K., et. al., "Application Aspects of IPv6
Transition", RFC4038, March 2005. Transition", RFC4038, March 2005.
[SLDEP] Huitema, C. and B. Carpenter, "Deprecating Site Local [SLDEP] Huitema, C. and B. Carpenter, "Deprecating Site Local
Addresses", RFC3879, September 2004. Addresses", RFC3879, September 2004.
[TOKEN] Crawford, M., Narten, T., and S. Thomas, "Transmission of
IPv6 Packets over Token Ring Networks", RFC2470, December
1998.
[TRAN] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
IPv6 Hosts and Routers", RFC2893, August 2000.
6. Author's Addresses 6. 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
email: bob.hinden@nokia.com email: bob.hinden@nokia.com
skipping to change at page 25, line 46 skipping to change at page 25, line 46
Addresses" to RFC3587. Addresses" to RFC3587.
o Removed mention of NSAP addresses in examples. o Removed mention of NSAP addresses in examples.
o Clarified that the "x" in the textual representation can be one to o Clarified that the "x" in the textual representation can be one to
four digits. four digits.
o Deprecated the "IPv6 Compatible Address" because it is not being o Deprecated the "IPv6 Compatible Address" because it is not being
used in the IPv6 transition mechanisms. used in the IPv6 transition mechanisms.
o Added the "R" and "P" flags to Section 2.7 on Multicast addresses,
and pointers to the documents that define them.
o Editorial changes. o Editorial changes.
 End of changes. 31 change blocks. 
80 lines changed or deleted 92 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/