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

[Mark Smith <[e-mail]>]

Hi Nick,

On Sun, 13 Jun 2021 at 03:05, Nick Buraglio <[e-mail]> wrote:
>
> Inline

Likewise.

> ---

<snip>

> We're asking for space for prototyping and labbing that can be safely
> deployed without fear of leaks, and can effectively simulate a real
> deployment in protocol preference.

Prototype networks and lab networks are just examples of types of
private networks.

<snip>

> None of us are married
> to that space, but it does make some sense for those reasons. We were
> definitely thinking in the mindset of reduce-reuse-recycle rather than
> "we need something shiny and new".

This is why I'm arguing for using the ULA address space or the
existing documentation prefix when they can be.

It seems like people are thinking this lab / prototyping requirement
is new and unique. Yet people have built IPv6 (and IPv4) prototypes
and labs before without a specific IPv6 lab/prototype address space
existing.

<snip>

> > If somebody needs more private address space than a single ULA /48 can
> > provide, they can generate more for their own use, as long as they
> > have a new random Global ID part. There is no requirement in RFC4193
> > that an organisation MUST only have and  only use a single /48 ULA
> > prefix.
>
> True, however, that is a different solution altogether.
>

No such prototype/lab address space exists in IPv4. What address space
have people been using for IPv4 to do this sort of thing?

> >
> > The ULA address space wasn't specifically designed to be used to teach
> > address space planning and route aggregation, although I think the 16
> > bits between /48 and /64 could be used for that, as the 16 bits
> > between 10.0.0.0/8 and 10.0.0.0/24 have commonly been in IPv4.
>
> This starts to devolve quickly when building a parallel network for
> migration reasons. It's also unnecessarily complicated, in my opinion.
>

Pre-production staging before cutting that same infrastructure over to
production might be the actual new requirement.

The ID and the email discussion has been mixing together requirements for:

- labs and prototypes
- pre-production staging
- documentation and training

Not all of the address space needs for those different things are the
same. Labs and prototypes, documentation and training have already
been satisfied by either the ULA prefix, its site-local ancestor and
the documentation prefix for a long time.

So if pre-staging is the new requirement, then only those needs and
justifications should be the focus of this ID. The others are already
satisfied.

<snip>

>
> As big as any production network that exists, plus the X amount of
> networks that it touches. Prototyping and planning for migration is
> akin to a blast radius of the adjacent networks, not simply the
> network in question.
>

I think requesting address space for as big as any production network
exists plus external network connectivity is implying that the whole
pre-staged network is going to be pre-built entirely before an
all-at-once, big-bang cut-over.

I don't think that is a realistic scenario. Past a certain size, the
consequences of the all-at-once cut-over failing become too large. (I
call them big-bang for a reason, because that's the sound I imagine
they make when they fail.)

I'd be more open to the idea of a permanent pre-staging address space
if the requirements and scenario were more realistic than an a ::/7
for it, or the size of the largest current and future IPv6 networks
and their external connectivity.

I would also wonder if a temporary RIR allocation, beyond what normal
justification would allow, to accommodate the large all cut-over,
would be a better solution. The pre-production network is deployed
with the new production address space it would end up with. Once the
cut-over has occurred, the now unused old RIR space is given back to
the RIR. If you don't give it back after a reasonable and agreed time,
the RIR could start to impose financial penalties beyond the normal
RIR fees for that now unused address space.


Regards,
Mark.



> Lots of thoughts on this already in the thread. David Farmer has some
> good thoughts, as usual. (Hi, Dave!)
>
> >
> > The bits available for aggregation in in either 2001:db8::/32 or a ULA
> > /48 can easily support 4 levels or more of 4 bit aggregation
> > boundaries at nibble boundaries. When wouldn't that be enough to teach
> > the technique?
> >
> > Regards,
> > Mark.
> >
> > *I've seen a number of examples of people getting the ULA address
> > space incorrect too despite "Unique" actually being in the name -
> > https://blog.apnic.net/2020/05/20/getting-ipv6-private-addressing-right/
> >
> > On Sat, 12 Jun 2021 at 08:13, Nick Buraglio <[e-mail]> wrote:
> > >
> > > 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
> > >
> > >
> > >
> > >
> > > 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
> > >
> > > _______________________________________________
> > > v6ops mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/v6ops