Internet DRAFT - draft-moreiras-v6ops-rfc3849bis

draft-moreiras-v6ops-rfc3849bis







Internet Engineering Task Force                              A. Moreiras
Internet-Draft                                               E. Cordeiro
Intended status: Best Current Practice                         R. Santos
Expires: April 24, 2014                                           NIC.br
                                                               A. Servin
                                                                  LACNIC
                                                               A. Acosta
                                               Universidad Nueva Esparta
                                                        October 21, 2013


            IPv6 Address Prefixes Reserved for Documentation
                   draft-moreiras-v6ops-rfc3849bis-01

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 defines the allocation of a new global unicast (GUA) block
   and a new unique local (ULA) block, to expand the range of
   documentation blocks.  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 April 24, 2014.





Moreiras, et al.         Expires April 24, 2014                 [Page 1]

Internet-Draft                 RFC 3849bis                  October 2013


Copyright Notice

   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.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Didactic Usage  . . . . . . . . . . . . . . . . . . . . .   3
     3.2.  Test Networks . . . . . . . . . . . . . . . . . . . . . .   4
     3.3.  Visual Identification and Address Filtering . . . . . . .   4
   4.  IPv6 Documentation Prefixes . . . . . . . . . . . . . . . . .   4
   5.  Operational Implications  . . . . . . . . . . . . . . . . . .   4
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

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 April 24, 2014                 [Page 2]

Internet-Draft                 RFC 3849bis                  October 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.  Problem Statement

   This document proposes a solution for the situations where the length
   of the current documentation prefix for IPv6 (2001:db8::/32) is not
   enough to represent some addressing scenarios and also proposes a
   specific documentation block for ULA.

3.1.  Didactic Usage

   In some didactic laboratories and materials, people are using other
   prefixes from Global Address space when they need networks bigger
   than /32.  For example, if you have a lab setup where each group
   represents an Autonomous System (AS) the ideal situation is that each
   group receives a block of the same size of the smallest allocation,
   it means a /32 for each group.  A typical scenery is to have 8 to 16
   groups, each one with your own /32, that requires a /28.  This
   scenery is used by the authors of this document in IPv6 courses in
   Latin America.

   Some IPv6 instructors use of ULA addresses when they have to
   represent networks bigger than /32, but it generates confusion on



Moreiras, et al.         Expires April 24, 2014                 [Page 3]

Internet-Draft                 RFC 3849bis                  October 2013


   students that are struggling to understand the differences between
   IPv4 and IPv6.  Some other instructors use non allocated or already
   allocated prefixes and it may lead to operational problems in the
   event of an example being inadvertently copied into a production
   environment.

   The same problems may occur to ULA being used for teaching purposes,
   as the [RFC3849] does not define an ULA for documentation.

3.2.  Test Networks

   Some transition techniques from IPv4 to IPv6 uses the IPv4 addresses
   embedded in the IPv6 addresses, for example, 6rd [RFC5969], 464XLAT
   [RFC6877] and MAP-E [I-D.ietf-softwire-map].  Using only a /32 to
   test those network may generate prefixes bigger than /64 that will
   conflict with SLAAC mechanism, as described in [RFC6052].

   New protocols development may also need test networks larger than a
   single /32, specially when making a large functional test to check
   the new protocol behavior on a big network trying to emulate a
   production environment.

3.3.  Visual Identification and Address Filtering

   It is important that the documentation blocks and addresses can be
   easily identified, specially to avoid that those address to generate
   problems in production networks.  A simple visual identification also
   avoid that people will use allocated or unallocated addresses to test
   or teach IPv6, just because those addresses would be easier to
   remember.

   Books and documentation that includes IPv6 addresses would have a
   standard to follow and that will serve their needs.

   Having a large defined block for documentation will also help
   filtering test and documentation addresses that may leak into
   production networks.

4.  IPv6 Documentation Prefixes

   The blocks provided for use in documentation are: 2001:0db8::/32 (v6
   -TEST-NET-1), UUUU:U000::/20 [Note to RFC Editor: this address range
   is to be added before publication] (v6-TEST-NET-2) and
   FCUU:UUUU:UUU0::/44 [Note to RFC Editor: this address range is to be
   added before publication] (v6-TEST-NET-3).

5.  Operational Implications




Moreiras, et al.         Expires April 24, 2014                 [Page 4]

Internet-Draft                 RFC 3849bis                  October 2013


   Addresses within the v6-TEST-NET-1, v6-TEST-NET-2 and v6-TEST-NET-3
   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-
   routable 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.

6.  Security Considerations

   There are no new security considerations pertaining to this document.

7.  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.

   IANA is asked to record the reservation of v6-TEST-NET-3 prefix,
   within the range reserved for Unique Local 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.

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

8.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.





Moreiras, et al.         Expires April 24, 2014                 [Page 5]

Internet-Draft                 RFC 3849bis                  October 2013


   [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.

   [RFC5969]  Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
              Infrastructures (6rd) -- Protocol Specification", RFC
              5969, August 2010.

   [RFC6877]  Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
              Combination of Stateful and Stateless Translation", RFC
              6877, April 2013.

   [RFC6052]  Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
              Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
              October 2010.

   [I-D.ietf-softwire-map]
              Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S.,
              Murakami, T., and T. Taylor, "Mapping of Address and Port
              with Encapsulation (MAP)", draft-ietf-softwire-map-08
              (work in progress), August 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


   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




Moreiras, et al.         Expires April 24, 2014                 [Page 6]

Internet-Draft                 RFC 3849bis                  October 2013


   Rodrigo Santos
   NIC.br
   Av das Nacoes Unidas 11541 7o andar
   Sao Paulo, SP  04578-000
   Brazil

   Phone: +55 11 5509 3537
   Email: rsantos@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 April 24, 2014                 [Page 7]