Internet DRAFT - draft-bchv-rfc6890bis
draft-bchv-rfc6890bis
Network Working Group R. Bonica
Internet-Draft Juniper Networks
Updates: 6890 (if approved) M. Cotton
Intended status: Best Current Practice ICANN
Expires: November 3, 2017 B. Haberman
Johns Hopkins University
L. Vegoda
ICANN
May 2, 2017
Updates to Special-Purpose IP Address Registries
draft-bchv-rfc6890bis-07
Abstract
This memo updates the IANA IPv4 and IPv6 Special-Purpose Address
Registries to address issues raised by the definition of a "global"
prefix. It also corrects several errors in registry entries to
ensure the integrity of the IANA Special-Purpose Address Registries.
This memo updates RFC 6890.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 3, 2017.
Copyright Notice
Copyright (c) 2017 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
Bonica, et al. Expires November 3, 2017 [Page 1]
Internet-Draft Special Purpose Address Registries May 2017
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
2.1. Definition of Global . . . . . . . . . . . . . . . . . . 3
2.2. Updates to the IPv4 Special-Purpose Address Registry . . 3
2.3. Updates to the IPv6 Special-Purpose Address Registry . . 3
3. Security Considerations . . . . . . . . . . . . . . . . . . . 4
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. Normative References . . . . . . . . . . . . . . . . . . 4
5.2. Informative References . . . . . . . . . . . . . . . . . 4
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
In order to support new protocols and practices, the IETF
occasionally reserves an address block for a special purpose. For
example, [RFC1122] reserves an IPv4 address block (0.0.0.0/8) to
represent the local (i.e., "this") network. Likewise, [RFC4291]
reserves an IPv6 address block (fe80::/10) to represent link-scoped
unicast addresses.
Several issues have been raised with the documentation of some of the
special-purpose address blocks in [RFC6890]. Specifically, the
definition of "global" provided in [RFC6890] was misleading as it
slightly differed from the generally accepted definition of "global
scope" (i.e., the ability to forward beyond the boundaries of an
administrative domain, described as "global unicast" in the IPv6
addressing architecture [RFC4291]).
This memo updates the definition of "global" from [RFC6890] for the
IPv4 and IPv6 Special-Purpose Address Registries, augments the fields
contained within the registries in order to address the confusion
raised by the definition of "global", and corrects some errors in
some of the entries in the Special-Purpose Address Registries.
This memo updates [RFC6890].
Bonica, et al. Expires November 3, 2017 [Page 2]
Internet-Draft Special Purpose Address Registries May 2017
2. IANA Considerations
2.1. Definition of Global
[RFC6890] defined the term "global" without taking into consideration
the multiple uses of the term. Specifically, IP addresses can be
global in terms of allocation scope as well as global in terms of
routing/reachability. To address this ambiguity, the use of the term
"global" defined in [RFC6890] is replaced with "globally reachable".
The following definition replaces the definiton of "global" in the
IANA Special-Purpose Address Registries:
o Globally Reachable - A boolean value indicating whether an IP
datagram whose destination address is drawn from the allocated
special-purpose address block is forwardable beyond a specified
administrative domain.
The same relationship between the value of "Destination" and the
values of "Forwardable" and "Global" described in [RFC6890] holds for
"Globally Reachable". If the value of "Destination" is FALSE, the
values of "Forwardable" and "Globally Reachable" must also be FALSE.
The "Global" column in the IPv4 Special-Purpose Address Registry
(https://www.iana.org/assignments/iana-ipv4-special-registry) and the
IPv6 Special-Purpose Address Registry
(https://www.iana.org/assignments/iana-ipv6-special-registry) is
renamed to "Globally Reachable".
2.2. Updates to the IPv4 Special-Purpose Address Registry
o Limited Broadcast prefix (255.255.255.255/32) - The Reserved-by-
Protocol value is changed from False to True. This change is made
to align the registry with reservation of the limited broadcast
address with Section 7 of [RFC0919].
2.3. Updates to the IPv6 Special-Purpose Address Registry
The following changes to the IPv6 Special-Purpose Address Registry
involves the insertion of two new footnotes. These changes require
the footnotes to be re-numbered.
o TEREDO prefix (2001::/32) - The Globally Reachable value is
changed from False to "N/A [2]". The [2] footnote states:
* See Section 5 of [RFC4380] for details.
o EID Space for LISP (2001:5::/32) - All footnotes are incremented
by 1.
Bonica, et al. Expires November 3, 2017 [Page 3]
Internet-Draft Special Purpose Address Registries May 2017
o 6to4 (2002::/16) - All footnotes are incremented by 1.
o Unique-Local (fc00::/7) - The Globally Reachable value is changed
from False to "False [7]". The [7] footnote states:
* See [RFC4193] for more details on the routability of Unique-
Local addresses. The Unique-Local prefix is drawn from the
IPv6 Global Unicast Address range, but is specified as not
globally routed.
3. Security Considerations
This document does not raise any security issues beyond those
discussed in [RFC6890].
4. Acknowledgements
Brian Carpenter and C.M. Heard provided useful comments on initial
versions of this document. Daniel Migault provided an in-depth
review that helped strengthen the text within the document.
5. References
5.1. Normative References
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman,
"Special-Purpose IP Address Registries", BCP 153,
RFC 6890, DOI 10.17487/RFC6890, April 2013,
<http://www.rfc-editor.org/info/rfc6890>.
5.2. Informative References
[RFC0919] Mogul, J., "Broadcasting Internet Datagrams", STD 5,
RFC 919, DOI 10.17487/RFC0919, October 1984,
<http://www.rfc-editor.org/info/rfc919>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989,
<http://www.rfc-editor.org/info/rfc1122>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<http://www.rfc-editor.org/info/rfc4193>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <http://www.rfc-editor.org/info/rfc4291>.
Bonica, et al. Expires November 3, 2017 [Page 4]
Internet-Draft Special Purpose Address Registries May 2017
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380,
DOI 10.17487/RFC4380, February 2006,
<http://www.rfc-editor.org/info/rfc4380>.
Authors' Addresses
Ronald Bonica
Juniper Networks
Email: rbonica@juniper.net
Michelle Cotton
ICANN
Email: michelle.cotton@icann.org
Brian Haberman
Johns Hopkins University
Email: brian@innovationslab.net
Leo Vegoda
ICANN
Email: leo.vegoda@icann.org
Bonica, et al. Expires November 3, 2017 [Page 5]
