draft-ietf-6man-rfc4291bis-00.txt   draft-ietf-6man-rfc4291bis-01.txt 
Network Working Group R. Hinden Network Working Group R. Hinden
Internet-Draft Check Point Software Internet-Draft Check Point Software
Obsoletes: 4291 (if approved) S. Deering Obsoletes: 4291 (if approved) S. Deering
Intended status: Standards Track Retired Intended status: Standards Track Retired
Expires: June 18, 2016 December 16, 2015 Expires: July 24, 2016 January 21, 2016
IP Version 6 Addressing Architecture IP Version 6 Addressing Architecture
draft-ietf-6man-rfc4291bis-00 draft-ietf-6man-rfc4291bis-01
Abstract Abstract
This specification defines the addressing architecture of the IP This specification defines the addressing architecture of the IP
Version 6 (IPv6) protocol. The document includes the IPv6 addressing Version 6 (IPv6) protocol. 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 4291, "IP Version 6 Addressing This document obsoletes RFC 4291, "IP Version 6 Addressing
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on June 18, 2016. This Internet-Draft will expire on July 24, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 34 skipping to change at page 2, line 34
2. IPv6 Addressing . . . . . . . . . . . . . . . . . . . . . . . 3 2. IPv6 Addressing . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Addressing Model . . . . . . . . . . . . . . . . . . . . 4 2.1. Addressing Model . . . . . . . . . . . . . . . . . . . . 4
2.2. Text Representation of IPv6 Addresses . . . . . . . . . . 4 2.2. Text Representation of IPv6 Addresses . . . . . . . . . . 4
2.2.1. Text Representation of Addresses . . . . . . . . . . 4 2.2.1. Text Representation of Addresses . . . . . . . . . . 4
2.2.2. Text Representation of Address Prefixes . . . . . . . 5 2.2.2. Text Representation of Address Prefixes . . . . . . . 5
2.2.3. Recommendation for outputting IPv6 addresses . . . . 7 2.2.3. Recommendation for outputting IPv6 addresses . . . . 7
2.3. Address Type Identification . . . . . . . . . . . . . . . 9 2.3. Address Type Identification . . . . . . . . . . . . . . . 9
2.4. Unicast Addresses . . . . . . . . . . . . . . . . . . . . 10 2.4. Unicast Addresses . . . . . . . . . . . . . . . . . . . . 10
2.4.1. Interface Identifiers . . . . . . . . . . . . . . . . 11 2.4.1. Interface Identifiers . . . . . . . . . . . . . . . . 11
2.4.2. The Unspecified Address . . . . . . . . . . . . . . . 12 2.4.2. The Unspecified Address . . . . . . . . . . . . . . . 12
2.4.3. The Loopback Address . . . . . . . . . . . . . . . . 13 2.4.3. The Loopback Address . . . . . . . . . . . . . . . . 12
2.4.4. Global Unicast Addresses . . . . . . . . . . . . . . 13 2.4.4. Global Unicast Addresses . . . . . . . . . . . . . . 12
2.4.5. IPv6 Addresses with Embedded IPv4 Addresses . . . . . 13 2.4.5. IPv6 Addresses with Embedded IPv4 Addresses . . . . . 13
2.4.5.1. IPv4-Compatible IPv6 Address . . . . . . . . . . 14 2.4.5.1. IPv4-Compatible IPv6 Address . . . . . . . . . . 13
2.4.5.2. IPv4-Mapped IPv6 Address . . . . . . . . . . . . 14 2.4.5.2. IPv4-Mapped IPv6 Address . . . . . . . . . . . . 13
2.4.6. Link-Local IPv6 Unicast Addresses . . . . . . . . . . 14 2.4.6. Link-Local IPv6 Unicast Addresses . . . . . . . . . . 14
2.4.7. Site-Local IPv6 Unicast Addresses . . . . . . . . . . 15 2.4.7. Site-Local IPv6 Unicast Addresses . . . . . . . . . . 14
2.5. Anycast Addresses . . . . . . . . . . . . . . . . . . . . 15 2.5. Anycast Addresses . . . . . . . . . . . . . . . . . . . . 14
2.5.1. Required Anycast Address . . . . . . . . . . . . . . 16 2.5.1. Required Anycast Address . . . . . . . . . . . . . . 15
2.6. Multicast Addresses . . . . . . . . . . . . . . . . . . . 16 2.6. Multicast Addresses . . . . . . . . . . . . . . . . . . . 16
2.6.1. Pre-Defined Multicast Addresses . . . . . . . . . . . 19 2.6.1. Pre-Defined Multicast Addresses . . . . . . . . . . . 19
2.7. A Node's Required Addresses . . . . . . . . . . . . . . . 21 2.7. A Node's Required Addresses . . . . . . . . . . . . . . . 20
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
4. Security Considerations . . . . . . . . . . . . . . . . . . . 22 4. Security Considerations . . . . . . . . . . . . . . . . . . . 21
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.1. Normative References . . . . . . . . . . . . . . . . . . 23 6.1. Normative References . . . . . . . . . . . . . . . . . . 22
6.2. Informative References . . . . . . . . . . . . . . . . . 23 6.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Creating Modified EUI-64 Format Interface Appendix A. Modified EUI-64 Format Interface Identifiers . . . . 24
Identifiers . . . . . . . . . . . . . . . . . . . . 24 A.1. Creating Modified EUI-64 Format Interface Identifiers . . 25
Appendix B. CHANGES SINCE RFC 4291 . . . . . . . . . . . . . . . 27 Appendix B. CHANGES SINCE RFC 4291 . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. 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).
2. IPv6 Addressing 2. 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 interfaces (where "interface" is as defined in Section 2 of
[I-D.hinden-6man-rfc2460bis]). There are three types of addresses: [I-D.ietf-6man-rfc2460bis]). There are three types of addresses:
Unicast: An identifier for a single interface. A packet sent Unicast: An identifier for a single interface. A packet sent
to a unicast address is delivered to the interface to a unicast address is delivered to the interface
identified by that address. identified 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, identified by that address (the "nearest" one,
according to the routing protocols' measure of according to the routing protocols' measure of
skipping to change at page 11, line 30 skipping to change at page 11, line 30
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. The same interface identifier may be used on a broader scope. The same interface identifier may be used on
multiple interfaces on a single node, as long as they are attached to multiple interfaces on a single node, as long as they are attached to
different subnets. different subnets.
Interface IDs must be viewed outside of the node that created Interface IDs must be viewed outside of the node that created
Interface ID as an opaque bit string without any internal structure. Interface ID as an opaque bit string without any internal structure.
Note that the uniqueness of interface identifiers is independent of Note that the uniqueness of interface identifiers is independent of
the uniqueness of IPv6 addresses. For example, a Global Unicast the uniqueness of IPv6 addresses. For example, a Global Unicast
address may be created with a local scope interface identifier and a address may be created with an interface identifier that is only
Link-Local address may be created with a universal scope interface unique on a single subnet, and a Link-Local address may be created
identifier. with interface identifier that is unique over multiple subnets.
For all unicast addresses, except those that start with the binary For all unicast addresses, except those that start with the binary
value 000, Interface IDs are required to be 64 bits long. If derived value 000, Interface IDs are required to be 64 bits long.
from an IEEE MAC-layer address, they must be constructed in Modified
EUI-64 format.
Modified EUI-64 format-based interface identifiers may have universal
scope when derived from a universal token (e.g., IEEE 802 48-bit MAC
or IEEE EUI-64 identifiers [EUI64]) or may have local scope where a
global token is not being used (e.g., serial links, tunnel end-
points) or where global tokens are undesirable (e.g., temporary
tokens for privacy [RFC4941].
Modified EUI-64 format interface identifiers are formed by inverting
the "u" bit (universal/local bit in IEEE EUI-64 terminology) when
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 indicate universal scope, and it is set to zero (0) to indicate
local scope. The first three octets in binary of an IEEE EUI-64
identifier are as follows:
0 0 0 1 1 2
|0 7 8 5 6 3|
+----+----+----+----+----+----+
|cccc|ccug|cccc|cccc|cccc|cccc|
+----+----+----+----+----+----+
written in Internet standard bit-order, where "u" is the universal/
local bit, "g" is the individual/group bit, and "c" is the bits of
the company_id. Appendix A, "Creating Modified EUI-64 Format
Interface Identifiers", provides examples on the creation of Modified
EUI-64 format-based interface identifiers.
The motivation for inverting the "u" bit when forming an interface
identifier is to make it easy for system administrators to hand
configure non-global identifiers when hardware tokens are not
available. This is expected to be the case for serial links and
tunnel end-points, for example. 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 0:0:0:1, 0:0:0:2, etc.
IPv6 nodes are not required to validate that interface identifiers The details of forming interface identifiers are defined in other
created with modified EUI-64 tokens with the "u" bit set to universal specifications, such as "Privacy Extensions for Stateless Address
are unique. Autoconfiguration in IPv6" [RFC4941] and "Recommendation on Stable
IPv6 Interface Identifiers" [I-D.ietf-6man-default-iids]. Specific
cases are described in appropriate "IPv6 over <link>" specifications,
such as "IPv6 over Ethernet" [RFC2464] and "Transmission of IPv6
Packets over ITU-T G.9959 Networks" [RFC7428].
The details of forming interface identifiers are defined in the Earlier versions of this document described a method of forming
appropriate "IPv6 over <link>" specification, such as "IPv6 over interface identifiers derived from IEEE MAC-layer addresses call
Ethernet" [RFC2464], and "IPv6 over FDDI" [RFC2467]. Modified EUI-64 format. These are described in Appendix A and are no
longer recommended.
2.4.2. The Unspecified Address 2.4.2. The Unspecified Address
The address 0:0:0:0:0:0:0:0 is called the unspecified address. It The address 0:0:0:0:0:0:0:0 is called the unspecified address. It
must never be assigned to any node. It indicates the absence of an must never be assigned to any node. It indicates the absence of an
address. One example of its use is in the Source Address field of address. One example of its use is in the Source Address field of
any IPv6 packets sent by an initializing host before it has learned any IPv6 packets sent by an initializing host before it has learned
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
skipping to change at page 23, line 12 skipping to change at page 22, line 26
updating RFCs that were incorporated in this version of the document updating RFCs that were incorporated in this version of the document
to move IPv6 to Internet Standard. This includes Marcelo Bagnulo, to move IPv6 to Internet Standard. This includes Marcelo Bagnulo,
Congxiao Bao, Mohamed Boucadair, Brian Carpenter, Ralph Droms, Congxiao Bao, Mohamed Boucadair, Brian Carpenter, Ralph Droms,
Christian Huitema, Sheng Jiang, Seiichi Kawamura, Masanobu Kawashima, Christian Huitema, Sheng Jiang, Seiichi Kawamura, Masanobu Kawashima,
Xing Li, and Stig Venaas. Xing Li, and Stig Venaas.
6. References 6. References
6.1. Normative References 6.1. Normative References
[I-D.hinden-6man-rfc2460bis] [I-D.ietf-6man-rfc2460bis]
Deering, S. and B. Hinden, "Internet Protocol, Version 6 Deering, S. and B. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", draft-hinden-6man-rfc2460bis-07 (IPv6) Specification", draft-ietf-6man-rfc2460bis-02 (work
(work in progress), September 2015. in progress), December 2015.
6.2. Informative References 6.2. Informative References
[EUI64] "IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) [EUI64] "IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
Registration Authority"", March 1997, Registration Authority"", March 1997,
<http://standards.ieee.org/regauth/oui/tutorials/ <http://standards.ieee.org/regauth/oui/tutorials/
EUI64.html>. EUI64.html>.
[I-D.ietf-6man-default-iids]
Gont, F., Cooper, A., Thaler, D., and S. LIU,
"Recommendation on Stable IPv6 Interface Identifiers",
draft-ietf-6man-default-iids-08 (work in progress),
October 2015.
[IANA-AD] "Internet Protocol Version 6 Address Space", [IANA-AD] "Internet Protocol Version 6 Address Space",
<https://www.iana.org/assignments/ipv6-address-space/ipv6- <https://www.iana.org/assignments/ipv6-address-space/ipv6-
address-space.xhtml>. address-space.xhtml>.
[IANA-SP] "IANA IPv6 Special-Purpose Address Registry", [IANA-SP] "IANA IPv6 Special-Purpose Address Registry",
<https://www.iana.org/assignments/iana-ipv6-special- <https://www.iana.org/assignments/iana-ipv6-special-
registry/iana-ipv6-special-registry.xhtml>. registry/iana-ipv6-special-registry.xhtml>.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998,
<http://www.rfc-editor.org/info/rfc2464>. <http://www.rfc-editor.org/info/rfc2464>.
[RFC2467] Crawford, M., "Transmission of IPv6 Packets over FDDI
Networks", RFC 2467, DOI 10.17487/RFC2467, December 1998,
<http://www.rfc-editor.org/info/rfc2467>.
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
Multicast Addresses", RFC 3306, DOI 10.17487/RFC3306, Multicast Addresses", RFC 3306, DOI 10.17487/RFC3306,
August 2002, <http://www.rfc-editor.org/info/rfc3306>. August 2002, <http://www.rfc-editor.org/info/rfc3306>.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, DOI 10.17487/ (IPv6) Addressing Architecture", RFC 3513, DOI 10.17487/
RFC3513, April 2003, RFC3513, April 2003,
<http://www.rfc-editor.org/info/rfc3513>. <http://www.rfc-editor.org/info/rfc3513>.
[RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
skipping to change at page 24, line 47 skipping to change at page 24, line 15
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<http://www.rfc-editor.org/info/rfc4941>. <http://www.rfc-editor.org/info/rfc4941>.
[RFC7371] Boucadair, M. and S. Venaas, "Updates to the IPv6 [RFC7371] Boucadair, M. and S. Venaas, "Updates to the IPv6
Multicast Addressing Architecture", RFC 7371, DOI Multicast Addressing Architecture", RFC 7371, DOI
10.17487/RFC7371, September 2014, 10.17487/RFC7371, September 2014,
<http://www.rfc-editor.org/info/rfc7371>. <http://www.rfc-editor.org/info/rfc7371>.
Appendix A. Creating Modified EUI-64 Format Interface Identifiers [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets
over ITU-T G.9959 Networks", RFC 7428, DOI 10.17487/
RFC7428, February 2015,
<http://www.rfc-editor.org/info/rfc7428>.
Appendix A. Modified EUI-64 Format Interface Identifiers
Modified EUI-64 format-based interface identifiers may have universal
scope when derived from a universal token (e.g., IEEE 802 48-bit MAC
or IEEE EUI-64 identifiers [EUI64]) or may have local scope where a
global token is not being used (e.g., serial links, tunnel end-
points) or where global tokens are undesirable (e.g., temporary
tokens for privacy [RFC4941].
Modified EUI-64 format interface identifiers are formed by inverting
the "u" bit (universal/local bit in IEEE EUI-64 terminology) when
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 indicate universal scope, and it is set to zero (0) to indicate
local scope. The first three octets in binary of an IEEE EUI-64
identifier are as follows:
0 0 0 1 1 2
|0 7 8 5 6 3|
+----+----+----+----+----+----+
|cccc|ccug|cccc|cccc|cccc|cccc|
+----+----+----+----+----+----+
written in Internet standard bit-order, where "u" is the universal/
local bit, "g" is the individual/group bit, and "c" is the bits of
the company_id. Appendix A, "Creating Modified EUI-64 Format
Interface Identifiers", provides examples on the creation of Modified
EUI-64 format-based interface identifiers.
The motivation for inverting the "u" bit when forming an interface
identifier is to make it easy for system administrators to hand
configure non-global identifiers when hardware tokens are not
available. This is expected to be the case for serial links and
tunnel end-points, for example. 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 0:0:0:1, 0:0:0:2, etc.
IPv6 nodes are not required to validate that interface identifiers
created with modified EUI-64 tokens with the "u" bit set to universal
are unique.
A.1. Creating Modified EUI-64 Format Interface Identifiers
Depending on the characteristics of a specific link or node, there Depending on the characteristics of a specific link or node, there
are a number of approaches for creating Modified EUI-64 format are a number of approaches for creating Modified EUI-64 format
interface identifiers. This appendix describes some of these interface identifiers. This appendix describes some of these
approaches. approaches.
Links or Nodes with IEEE EUI-64 Identifiers Links or Nodes with IEEE EUI-64 Identifiers
The only change needed to transform an IEEE EUI-64 identifier to an The only change needed to transform an IEEE EUI-64 identifier to an
interface identifier is to invert the "u" (universal/local) bit. An interface identifier is to invert the "u" (universal/local) bit. An
skipping to change at page 27, line 41 skipping to change at page 28, line 13
and that it doesn't cause any problems in practice. and that it doesn't cause any problems in practice.
Appendix B. CHANGES SINCE RFC 4291 Appendix B. CHANGES SINCE RFC 4291
This document has the following changes from RFC4291, "IP Version 6 This document has the following changes from RFC4291, "IP Version 6
Addressing Architecture". Numbers identify the Internet-Draft Addressing Architecture". Numbers identify the Internet-Draft
version that the change was made.: version that the change was made.:
Working Group Internet Drafts Working Group Internet Drafts
01) Revised Section 2.4.1 on Interface Identifiers to reflect
current approach, this included saying Modified EUI-64
identifiers not recommended and moved the text describing the
format to Appendix A.
01) Editorial changes.
00) Working Group Draft. 00) Working Group Draft.
00) Editorial changes. 00) Editorial changes.
Individual Internet Drafts Individual Internet Drafts
06) Incorporate the updates made by RFC7371. The changes were to 06) Incorporate the updates made by RFC7371. The changes were to
the flag bits and their definitions in Section 2.6. the flag bits and their definitions in Section 2.6.
05) Incorporate the updates made by RFC7346. The change was to 05) Incorporate the updates made by RFC7346. The change was to
 End of changes. 21 change blocks. 
77 lines changed or deleted 100 lines changed or added

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