Skip to main content

Expanding the IPv6 Lab Use Space

Document Type Active Internet-Draft (individual)
Authors Nick Buraglio , Chris Cummings , Kevin Myers , Russ White , Ed Horley
Last updated 2023-07-24
RFC stream (None)
Intended RFC status (None)
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
V6OPS                                                        N. Buraglio
Internet-Draft                                               C. Cummings
Intended status: Standards Track                 Energy Sciences Network
Expires: 25 January 2024                                        K. Myers
                                                           IP ArchiTechs
                                                                R. White
                                                     Akamai Technologies
                                                               E. Horley
                                                            24 July 2023

                    Expanding the IPv6 Lab Use Space


   To reduce the likelihood of addressing conflicts and confusion
   between lab deployments and non-lab (i.e., production) deployments,
   an IPv6 unicast address prefix is reserved for use in lab, proof-of-
   concept, and validation networks as well as for any similar use case.
   This document describes the use of the IPv6 address prefix 0200::/7
   as a prefix reserved for this purpose (repurposing the deprecated OSI
   NSAP-mapped prefix).

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

   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 25 January 2024.

Copyright Notice

   Copyright (c) 2023 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Buraglio, et al.         Expires 25 January 2024                [Page 1]
Internet-Draft      Expanding the IPv6 Lab Use Space           July 2023

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (
   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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Assignment of address space for use in large-scale lab and
           prototyping environments  . . . . . . . . . . . . . . . .   3
     3.1.  Operational Implications  . . . . . . . . . . . . . . . .   3
       3.1.1.  Resource utilization  . . . . . . . . . . . . . . . .   4
   4.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   7.  Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . .   5
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   The address architecture for IPv6 [RFC4291] does not explicitly
   define any prefixes allocated exclusively for lab use, nor is such
   address space allocated in [RFC6890] or in [RFC8200].  While lab
   deployments could potentially use IPv6 address prefixes typically
   assigned and configured in non-lab network, the use of such
   addressing in lab environments may create addressing conflicts and
   unnecessary operational confusion.  For instance, designing labs
   utilizing ULA fc00::/7 [RFC4193] is problematic due to the random
   global ID requirement preventing hierarchical network prefix design
   possibilities.  Further, default address selection behavior [RFC6724]
   by end nodes may result in a de-preference of such addresses and
   prevent lab deployments from accurately modeling their desired non-
   lab equivalents, especially in the testing of devices that are
   incapable of adjusting the global source selection table.  To resolve
   these problems involved in building large-scale lab networks, and
   pre-staging, or automating large-scale networks for deployment, this
   document allocates the IPv6 address prefix 0200::/7 for these
   purposes.  The goal is to allow organization to share working lab
   configuration files (with little or no need of modification) to be
   deployed in a third party lab environment, public and private

Buraglio, et al.         Expires 25 January 2024                [Page 2]
Internet-Draft      Expanding the IPv6 Lab Use Space           July 2023

   externally managed services, virtualization or hosting environments
   as well as in other networks such as Service Providers, Enterprise,
   Government, IoT, and Energy, all with the knowledge that the lab GUA
   address space will perform the same as any GUA but with the added
   knowledge that filtering will be used to protect accidental leaks to
   the Internet.  The following criteria is for selecting the lab

   *  Address space should reside outside of IANA allocated GUA block of

   *  The precedence for the lab prefix should not be lower than the GUA
      prefix as defined in [RFC6724] (unlike ULA).

   *  Reduce the operational impacts to IANA and the RIR's in selecting
      lab prefix space.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Assignment of address space for use in large-scale lab and
    prototyping environments

   The prefix reserved for large scale lab and testing purposes is

3.1.  Operational Implications

   This space SHOULD NOT be employed for addressing use cases which are
   already defined in other RFCs, such as addresses set apart for
   documentation, testing, etc.  Enterprise and large-scale networks
   have some specific criteria around building and validating prior to
   deployment.  The issues with ULA for infrastructure modeling, lab
   creation, configuration and behavior testing at the host level are
   notably impactful in large enterprises as well as continental and
   global scale networks.  This is primarily, but not exclusively, due
   to the increased focus on large-scale hosts, servers, and application
   testing.  Additionally, it is likely that both GUA and ULA may co-
   exist or are planned to co-exist, and reconfiguring lab hosts,
   network elements, operational technology systems, and IoT hardware
   isn't practical or desirable due to inconsistent results for host
   preference due to [RFC6724] behavior.  Most large-scale enterprises
   strive to build lab, dev, and QA environments that reflect production

Buraglio, et al.         Expires 25 January 2024                [Page 3]
Internet-Draft      Expanding the IPv6 Lab Use Space           July 2023

   as accurately as possible.  This is a fairly straightforward way to
   avoid disparity between production and non-production.  Enterprise
   environments are an area that need increased IPv6 adoption.  In an
   effort to enable a more approachable mechanism to model a global
   scale network, and to avoid the pitfalls of ULA de-preferenced host
   behavior or mis-use (i.e. address space squatting) on other IPv6
   space, a specific IPv6 lab prefix is being assigned.

3.1.1.  Resource utilization

   The prefix in question, (0200::/7) has previously been used for the
   OSI NSAP-mapped prefix set in [RFC4048] and [RFC4548], and
   deprecated, this address prefix is already limited in its usability
   and has not been officially re-purposed.  The address prefix was
   returned to IANA and is available to be marked for other purposes.
   This assignment implies that IPv6 network operators SHOULD add this
   address prefix to the list of non-routable IPv6 address space, and if
   packet filters are deployed, then this address prefix SHOULD be added
   to packet filters.  This is not a local-use address prefix so these
   filters may be used in both local and public contexts.

   As noted here (
   ipv6-address-space.xhtml) by the IANA Internet Protocol Version 6
   Address Space allocation reference, 0200::/7 was deprecated as of
   December 2004 by [RFC4048].  This space is outside of the 2000::/3
   address block, making it significantly easier to filter and providing
   straightforward visual and programmatic identification.  Because the
   resource has been previously allocated, no new resources are
   required.  Additionally, as noted by the IANA allocation list,
   approximately 85% of the IPv6 address space is reserved for future
   definition and use, and is not assigned by IANA at this time, leaving
   ample room for growth over the coming decades.

4.  Acknowledgements

   The authors would like to acknowledge the valuable input and
   contributions of the v6ops WG.  The authors further acknowledge the
   work of Bob Hinden and Stephen Deering, in authoring the protocol
   standard and the addressing architecture for IPv6.  The authors would
   also like to recognize the valuable input, suggestions, and insight
   by Tom Coffeen, Scott Hogg, and Jay Stewart.

Buraglio, et al.         Expires 25 January 2024                [Page 4]
Internet-Draft      Expanding the IPv6 Lab Use Space           July 2023

5.  Security Considerations

   The addresses assigned for lab and staging use SHOULD be filtered as
   noted above.  Setting aside address space for lab and staging use,
   and adding this address space to common filters to prevent
   destinations in this space from being routed in production networks
   (including the global Internet) improves security by preventing the
   leakage of prefixes used for testing into production environments.
   As such, setting aside this space improves the overall security
   posture of the Internet.

6.  IANA Considerations

   IANA to allocate and record the reservation of the IPv6 global
   unicast address prefix 0200::/7 as a lab-only prefix in the IPv6
   address registry.  No end party is to be assigned this address.

7.  Appendix A.

8.  References

8.1.  Normative References

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

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,

8.2.  Informative References

   [RFC4048]  Carpenter, B., "RFC 1888 Is Obsolete", RFC 4048,
              DOI 10.17487/RFC4048, April 2005,

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,

Buraglio, et al.         Expires 25 January 2024                [Page 5]
Internet-Draft      Expanding the IPv6 Lab Use Space           July 2023

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <>.

   [RFC4548]  Gray, E., Rutemiller, J., and G. Swallow, "Internet Code
              Point (ICP) Assignments for NSAP Addresses", RFC 4548,
              DOI 10.17487/RFC4548, May 2006,

   [RFC6724]  Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
              "Default Address Selection for Internet Protocol Version 6
              (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,

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

Authors' Addresses

   Nick Buraglio
   Energy Sciences Network

   Chris Cummings
   Energy Sciences Network

   Kevin Myers
   IP ArchiTechs

   Russ White
   Akamai Technologies

   Ed Horley

Buraglio, et al.         Expires 25 January 2024                [Page 6]