Reserved IPv6 Interface Identifiers
RFC 5453
|
| Document |
Type |
|
RFC - Proposed Standard
(February 2009; No errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
|
Reviews |
|
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 5453 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Jari Arkko
|
|
Send notices to |
|
(None)
|
Network Working Group S. Krishnan
Request for Comments: 5453 Ericsson
Category: Standards Track February 2009
Reserved IPv6 Interface Identifiers
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (http://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
Interface identifiers in IPv6 unicast addresses are used to identify
interfaces on a link. They are required to be unique within a
subnet. Several RFCs have specified interface identifiers or
identifier ranges that have a special meaning attached to them. An
IPv6 node autoconfiguring an interface identifier in these ranges
will encounter unexpected consequences. Since there is no
centralized repository for such reserved identifiers, this document
aims to create one.
Krishnan Standards Track [Page 1]
RFC 5453 Reserved IPv6 Interface Identifiers February 2009
Table of Contents
1. Introduction ....................................................2
1.1. Applicability ..............................................2
1.2. Requirements Notation ......................................3
2. Issues with Reusing Reserved Interface Identifiers ..............3
2.1. Possible Solutions .........................................3
3. IANA Considerations .............................................3
4. Acknowledgements ................................................4
5. Security Considerations .........................................4
6. References ......................................................5
6.1. Normative References .......................................5
6.2. Informative References .....................................5
Appendix A. List of Potentially Affected RFCs ......................6
1. Introduction
An IPv6 unicast address is composed of two parts: a subnet prefix and
an interface identifier (IID) that identifies a unique interface
within the subnet prefix. The structure of an IPv6 unicast address
is depicted in "IPv6 Addressing Architecture" [RFC4291] and is
replicated here for clarity.
| n bits | 128-n bits |
+-------------------------------+---------------------------------+
| subnet prefix | interface ID |
+-------------------------------+---------------------------------+
Figure 1: IPv6 Unicast Address Format
For all unicast addresses, except those that start with the binary
value 000, Interface IDs are required to be 64 bits long and to be
constructed in Modified EUI-64 format [RFC4291]. Examples of
mechanisms that generate interface identifiers without a unique token
include Cryptographically Generated Addresses [RFC3972], Privacy
Addresses [RFC4941], Hash-Based Addresses [HBA], etc. Non-unique
interface identifiers can also be allocated using managed address
assignment mechanisms like DHCPv6 (Dynamic Host Configuration
Protocol for IPv6) [RFC3315].
1.1. Applicability
This document applies only to interface identifiers that are formed
in the modified EUI-64 format as defined in Appendix A of [RFC4291].
All other types of interface identifiers are out of its scope.
Krishnan Standards Track [Page 2]
RFC 5453 Reserved IPv6 Interface Identifiers February 2009
1.2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Issues with Reusing Reserved Interface Identifiers
Show full document text