Re: [v6ops] I-D Action: draft-horley-v6ops-lab-00.txt

[Nick Buraglio <[e-mail]>]

Our reasoning behind this is that it is not practical for all organizations
to request and justify new address space simply for modeling their network
in order to test migrations / tests / prototyping, particularly when
building drop in replacement architectures or brownfield migrations for
very, very large networks with allocations larger than /32 (nor should they
have to do so). As such, the use cases here are drawn directly from
operational pain and inefficiencies.
For example, having to make a request in the ARIN region for IPv6 resource
allocation requires a network design. Entities that are building a very
large network requesting an allocation of /24 are left between a rock and a
hard place since the design has no real mechanism for both address planning
and prototyping / labbing. The current way this is accomplished is to use
often clunky compromises on numbering, a mix of whatever address space is
randomly chosen which in turn requires some level of extra and arguably
avoidable effort in order to migrate to production, and uses some randomly
chosen address block which may or may not be allocated somewhere else.
Since building a prototype using an address schema that won't reflect the
end state as well as it could is very often either a mash up of
documentation prefixes, randomly chosen unallocated space, or a mirror of
the GUA allocation, it introduces a lot of margin of error in both
configuration and migration operations.
The last of the aforementioned list -  a mirror of the GUA allocation - has
its own set of "...and here be dragons" problems, not the least of which is
potential for leaking into the existing network, confusion about devices,
and other very real human errors.

Documentation prefixes already exist which are arguably in that category of
"ambiguous" due to the lack of any kind of reserved and speciality block
for prototyping and labbing, of which they are very often used. Leveraging
a block from the global address space also loses the advantage of being
dereferenced ala rfc6724 as some of the other blocks are (ULA, etc. ). This
could be added to an update to also become deprioritized if adopted.

Additionally, we also have a very recent example of the block in question
being used in an available platform that is running production traffic in
their overlay. It is largely undocumented, functionally squatting the
0200::/7 block. It is structurally important for, for example, cloud
providers, energy industry (i.e. power meters)  that have extremely large
networks that do not want to risk using their actual GUA space in a lab
that could potentially be leaked by misconfiguration. Since the 0200::/7 is
very close to 2000::/3 and can be fairly trivially migrated from lab /
prototyping to production with very straightforward programmatic means.

Moreover, we believe this prototype / lab prefix should be different from
documentation address space in order to retain unique address space for
actual documentation to avoid the haphazard way it is typically done in the
wild in v4 land. for example, code snippets intended for cut-and-paste
should be lab, documentation should be documentation prefix.

I hope this helps inform our reasons for proposing it. We're all happy to
discuss this further!

nb



---
Nick Buraglio
Planning and Architecture Group
Energy Sciences Network; AS293
Lawrence Berkeley National Laboratory
[e-mail]
[phone]


On Thu, Jun 10, 2021 at 5:23 PM Brian E Carpenter <
[e-mail]> wrote:

> My concern about this draft is that it intentionally creates ambiguous
> address space, something we have very carefully avoided since the beginning
> of IPv6.
>
> Regards
>    Brian
>
> On 06-Jun-21 10:27, [e-mail] wrote:
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> >
> >
> >         Title           : Expanding IPv6 Lab Use Space
> >         Authors         : Ed Horley
> >                           Tom Coffeen
> >                           Scott Hogg
> >                           Nick Buraglio
> >                           Kevin Myers
> >                           Chris Cummings
> >                           Russ White
> >       Filename        : draft-horley-v6ops-lab-00.txt
> >       Pages           : 5
> >       Date            : 2021-06-05
> >
> > 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).
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-horley-v6ops-lab/
> >
> > There is also an htmlized version available at:
> > https://datatracker.ietf.org/doc/html/draft-horley-v6ops-lab-00
> >
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> >
> > _______________________________________________
> > I-D-Announce mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/i-d-announce
> > Internet-Draft directories: http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>