Internet-Draft Expanding IPv6 Lab Use Space June 2021
Horley, et al. Expires 7 December 2021 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-horley-v6ops-lab-00
Published:
Intended Status:
Informational
Expires:
Authors:
E. Horley
HexaBuild
T. Coffeen
HexaBuild
S. Hogg
HexaBuild
N. Buraglio
Energy Sciences Network
K. Myers
IP ArchiTechs
C. Cummings
Energy Sciences Network
R. White
Juniper Networks

Expanding IPv6 Lab Use Space

Abstract

TTo 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 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 https://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 7 December 2021.

Table of Contents

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]. 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 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 depreferencing of such addresses and prevent lab deployments from accurately modeling their desired non-lab equivalents.

To resolve these problems involved in building large scale lab networks, and pre-staging large-scale networks for deployment, this document allocates the IPv6 address prefix 0200::/7 for these purposes.

2. New Lab IPv6 Address Prefix

The prefix reserved for lab and testing purposes is 0200::/7.

3. Operational Implications

This space SHOULD NOT be employed for addressing use cases which are already defined in other RFCs, such as addrfesses set apart for documentation, testing, etc.

Because this address prefix 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. In addition, the address prefix was returned to IANA and is available to be marked for lab or other purposes.

This assignment implies that IPv6 network operators SHOULD add this address prefix to the list of non-routeable 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.

4. IANA Considerations

IANA is to 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.

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

The authors acknowledge the work of Bob Hinden and Stephen Deering, in authoring the protocol standard and the addressing architecture for IPv6.

7. References

7.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.

7.2. Informative References

[RFC3515]
Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, DOI 10.17487/RFC3515, , <https://www.rfc-editor.org/info/rfc3515>.
[RFC4048]
Carpenter, B., "RFC 1888 Is Obsolete", RFC 4048, DOI 10.17487/RFC4048, , <https://www.rfc-editor.org/info/rfc4048>.
[RFC4193]
Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, , <https://www.rfc-editor.org/info/rfc4193>.
[RFC4291]
Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, , <https://www.rfc-editor.org/info/rfc4291>.
[RFC4548]
Gray, E., Rutemiller, J., and G. Swallow, "Internet Code Point (ICP) Assignments for NSAP Addresses", RFC 4548, DOI 10.17487/RFC4548, , <https://www.rfc-editor.org/info/rfc4548>.
[RFC5180]
Popoviciu, C., Hamza, A., Van de Velde, G., and D. Dugatkin, "IPv6 Benchmarking Methodology for Network Interconnect Devices", RFC 5180, DOI 10.17487/RFC5180, , <https://www.rfc-editor.org/info/rfc5180>.
[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, , <https://www.rfc-editor.org/info/rfc6724>.
[RFC6890]
Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, "Special-Purpose IP Address Registries", BCP 153, RFC 6890, DOI 10.17487/RFC6890, , <https://www.rfc-editor.org/info/rfc6890>.

Authors' Addresses

Ed Horley
HexaBuild
Tom Coffeen
HexaBuild
Scott Hogg
HexaBuild
Nick Buraglio
Energy Sciences Network
Kevin Myers
IP ArchiTechs
Chris Cummings
Energy Sciences Network
Russ White
Juniper Networks