Internet Engineering Task Force A. Moreiras
Internet-Draft E. Cordeiro
Intended status: Best Current Practice NIC.br
Expires: February 12, 2014 A. Servin
LACNIC
A. Acosta
Universidad Nueva Esparta
August 11, 2013
IPv6 Address Prefixes Reserved for Documentation
draft-moreiras-v6ops-rfc3849bis-00
Abstract
[RFC3849] specified an IPv6 prefix to be used in documentation, in
order to reduce the likelihood of conflict and confusion when
relating examples of deployed systems. This prefix was reserved to
be used in examples in RFCs, books, documentation, and the like. It
became widely accepted and used.
Although the IPv6 documentation prefix proved to be very useful, a /
32 prefix is not enough to be used to document some kinds of IPv6
deployments, such as large ISP deployments, transition techniques,
and other useful examples that require longer prefixes. This
document requests the allocation of a new global unicast /20 block,
as a documentation prefix, and expands the range of uses that can be
expected for these prefixes. It also updates [RFC3849].
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 February 12, 2014.
Copyright Notice
Moreiras, et al. Expires February 12, 2014 [Page 1]
Internet-Draft RFC 3849bis August 2013
Copyright (c) 2013 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. 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. IPv6 Documentation Prefixes . . . . . . . . . . . . . . . . . 3
4. Operational Implications . . . . . . . . . . . . . . . . . . 3
5. Security Considerations . . . . . . . . . . . . . . . . . . . 3
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
7.1. Normative References . . . . . . . . . . . . . . . . . . 4
7.2. Informative References . . . . . . . . . . . . . . . . . 4
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4
1. Introduction
This document describes the IPv6 address blocks provided to be used
in documentation. These blocks SHOULD be used to describe network
topologies, transition techniques or other systems, in RFCs, books,
videos, and documentation in general. They also MAY be used in
didactic laboratories, which aim to teach IPv6 or network principles.
The first block was reserved in [RFC3849], from the address space of
the Asia Pacific (APNIC) regional addressing community. Other
documentation ranges have been defined in the IETF, such as example
domain names described in [RFC2606], and IPv4 documentation-only
address blocks described in [RFC5737]. The IPv4 ranges reserved in
[RFC1918] for private use are also used in documentation, as well as
the Autonomous System numbers reserved in [RFC6996].
Moreiras, et al. Expires February 12, 2014 [Page 2]
Internet-Draft RFC 3849bis August 2013
Although the address block defined in [RFC3849] was within the range
of a conventional allocation size for an Internet Service Provider,
and it was expected that it could accurately match deployment
scenarios, there are some situations that can't be represented
accordingly with a prefix of 32 bits, such as: transition techniques,
peering between multiple ISPs, IPv6 address plan for multi-regional
ISPs, and others.
This situation leads to the same problem that [RFC3849] tried to
address. Some documentation material, particularly some didactic
material and laboratories, today is using IPv6 prefixes drawn from
address blocks already allocated or assigned. A similar situation
with IPv4 addresses caused problems in production environments,
because of address and routing conflicts with other services.
This document reserves an additional larger IPv6 block for
documentation, avoiding such problems. It does not obsolete the
current IPv6 documentation block 2001:0db8::/32, since it is widely
deployed. Nonetheless, it updates the current practice and specifies
one larger IPv6 block, for the same use.
2. Terminology
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].
3. IPv6 Documentation Prefixes
The blocks provided for use in documentation are: 2001:0db8::/32 (v6
-TEST-NET-1), and DDDD:D000::/20 [Note to RFC Editor: this address
range is to be added before publication] (v6-TEST-NET-2).
4. Operational Implications
Addresses within the v6-TEST-NET-1, and v6-TEST-NET-2, SHOULD NOT
appear on the public Internet and are used without any coordination
with IANA or an Internet Regional Registry (RIR). Network operators
SHOULD add these address blocks to the list of non-routeable address
spaces, and if packet filters are deployed, then this address block
SHOULD be added to packet filters.
These blocks are not for local use, and the filters may be used in
both local and public contexts.
5. Security Considerations
There are no new security considerations pertaining to this document.
Moreiras, et al. Expires February 12, 2014 [Page 3]
Internet-Draft RFC 3849bis August 2013
6. IANA Considerations
IANA recorded the allocation of the IPv6 global unicast address
prefix v6-TEST-NET-1 as a documentation-only prefix in the IPv6
address registry.
IANA is asked to record the allocation of v6-TEST-NET-2 prefix,
within the range reserved for Global IPv6 addresses, for use as an
additional documentation-only prefix, in the IPv6 address registry.
No end party is to be assigned any of these address blocks.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", BCP
5, RFC 1918, February 1996.
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS
Names", BCP 32, RFC 2606, June 1999.
[RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
Reserved for Documentation", RFC 3849, July 2004.
[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks
Reserved for Documentation", RFC 5737, January 2010.
[RFC6996] Mitchell, J., "Autonomous System (AS) Reservation for
Private Use", BCP 6, RFC 6996, July 2013.
Authors' Addresses
Antonio Marcos Moreiras
NIC.br
Av das Nacoes Unidas 11541 7o andar
Sao Paulo, SP 04578-000
Brazil
Phone: +55 11 5509 3553
Email: moreiras@nic.br
Moreiras, et al. Expires February 12, 2014 [Page 4]
Internet-Draft RFC 3849bis August 2013
Edwin Cordeiro
NIC.br
Av das Nacoes Unidas 11541 7o andar
Sao Paulo, SP 04578-000
Brazil
Phone: +55 11 5509 3537
Email: ecordeiro@nic.br
Arturo Servin
LACNIC
Rambla Republica de Mexico 6125
Montevideo 11300
Uruguay
Phone: +598 2604 2222
Email: aservin@lacnic.net
Alejandro Acosta
Universidad Nueva Esparta
Avenida Sur 7
Caracas, Los Naranjos del Cafetal CP 1081
Venezuela
Email: aacosta@rocketmail.com
Moreiras, et al. Expires February 12, 2014 [Page 5]