< draft-ietf-ipngwg-addr-arch-v3-09.txt   draft-ietf-ipngwg-addr-arch-v3-10.txt >
INTERNET-DRAFT R. Hinden, Nokia INTERNET-DRAFT R. Hinden, Nokia
August 26, 2002 S. Deering, Cisco Systems September 11, 2002 S. Deering, Cisco Systems
IP Version 6 Addressing Architecture IP Version 6 Addressing Architecture
<draft-ietf-ipngwg-addr-arch-v3-09.txt> <draft-ietf-ipngwg-addr-arch-v3-10.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 February 27, 2003. This Internet Draft expires March 12, 2003.
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-2373 "IP Version 6 Addressing
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
2.2 Text Representation of Addresses.........................4 2.2 Text Representation of Addresses.........................4
2.3 Text Representation of Address Prefixes..................5 2.3 Text Representation of Address Prefixes..................5
2.4 Address Type Identification..............................7 2.4 Address Type Identification..............................7
2.5 Unicast Addresses........................................7 2.5 Unicast Addresses........................................7
skipping to change at page 5, line 9 skipping to change at page 5, line 9
1080:0:0:0:8:800:200C:417A 1080:0: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 multiple 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 the leading and/or trailing zeros in an address. used to compress the leading and/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 1080:0: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 addresses
skipping to change at page 9, line 7 skipping to change at page 9, line 7
address may be created with a non-global scope interface identifier address may be created with a non-global scope interface identifier
and a site-local address may be created with a global scope interface and a site-local address may be created with a global scope interface
identifier. identifier.
For all unicast addresses, except those that start with binary value For all unicast addresses, except those that start with binary value
000, Interface IDs are required to be 64 bits long and to be 000, Interface IDs are required to be 64 bits long and to be
constructed in Modified EUI-64 format. constructed in Modified EUI-64 format.
Modified EUI-64 format based Interface identifiers may have global Modified EUI-64 format based Interface identifiers may have global
scope when derived from a global token (e.g., IEEE 802 48-bit MAC or scope when derived from a global token (e.g., IEEE 802 48-bit MAC or
IEEE EUI-64 identifiers) or may have local scope where a global token IEEE EUI-64 identifiers [EUI64]) or may have local scope where a
is not available (e.g., serial links, tunnel end-points, etc.) or global token is not available (e.g., serial links, tunnel end-points,
where global tokens are undesirable (e.g., temporary tokens for etc.) or where global tokens are undesirable (e.g., temporary tokens
privacy [PRIV]). for privacy [PRIV]).
Modified EUI-64 format interface identifiers are formed by inverting Modified EUI-64 format interface identifiers are formed by inverting
the "u" bit (universal/local bit in IEEE EUI-64 terminology) when the "u" bit (universal/local bit in IEEE EUI-64 terminology) when
forming the interface identifier from IEEE EUI-64 identifiers. In forming the interface identifier from IEEE EUI-64 identifiers. In
the resulting Modified EUI-64 format the "u" bit is set to one (1) to the resulting Modified EUI-64 format the "u" bit is set to one (1) to
indicate global scope, and it is set to zero (0) to indicate local indicate global scope, and it is set to zero (0) to indicate local
scope. The first three octets in binary of an IEEE EUI-64 identifier scope. The first three octets in binary of an IEEE EUI-64 identifier
are as follows: are as follows:
0 0 0 1 1 2 0 0 0 1 1 2
skipping to change at page 23, line 11 skipping to change at page 23, line 11
specification. It is strongly recommended that a collision specification. It is strongly recommended that a collision
detection algorithm be implemented as part of any automatic detection algorithm be implemented as part of any automatic
algorithm. algorithm.
APPENDIX B: Changes from RFC-2373 APPENDIX B: Changes from RFC-2373
--------------------------------- ---------------------------------
The following changes were made from RFC-2373 "IP Version 6 The following changes were made from RFC-2373 "IP Version 6
Addressing Architecture": Addressing Architecture":
- Clarified text in section 2.2 to allow "::" to represent one or
more groups of 16 bits of zeros.
- Changed uniqueness requirement of Interface Identifiers from - Changed uniqueness requirement of Interface Identifiers from
unique on a link to unique within a subnet prefix. Also added unique on a link to unique within a subnet prefix. Also added
a recommendation that the same interface identifier not be a recommendation that the same interface identifier not be
assigned to different machines on a link. assigned to different machines on a link.
- Change site-local format to make the subnet ID field 54-bit - Change site-local format to make the subnet ID field 54-bit
long and remove the 38-bit zero's field. long and remove the 38-bit zero's field.
- Added description of multicast scop values and rules to handle - Added description of multicast scop values and rules to handle
the reserved scop value 0. the reserved scop value 0.
- Revised sections 2.4 and 2.5.6 to simplify and clarify how - Revised sections 2.4 and 2.5.6 to simplify and clarify how
different address types are identified. This was done to different address types are identified. This was done to
 End of changes. 7 change blocks. 
8 lines changed or deleted 13 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/