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

[Mark Smith <[e-mail]>]

Hi Nicholas,

Top posting as a summary answer.

I think you're fundamentally asking for a new private IPv6 address
space. I don't think you can rely on it being exclusively use in labs
because people don't always follow IPv6 address space use rules, as
the existing squatting on 0200::/7 demonstrates.*

You're also asking for a non-globally unique private address space. So
deployments of it, some illegitimate, may possibly suffer from many if
not all of the problems that the non-globally unique site-local
address space did - see RFC 3879, "Deprecating Site Local Addresses"
for those.

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.

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.

If a ULA's 16 bits aren't enough to teach address space planning, then
the 32 bits between /32 and /64 in the existing 2001:db8::/32
documentation prefix could be used. Gaining more bits for this purpose
by not using the /48 boundary for aggregation would demonstrate bit
level aggregation rather than sticking to nibble or octet aggregation
boundaries.

I appreciate the /7 proposed is the same size of the deprecated OSI
NSAP-mapped prefix, however a /7 to teach address space planning seems
very excessive. It is twice as large as the whole of the IPv6
multicast address space.

If the 2001:db8::/32 prefix is not big enough to usefully teach the
techniques of address space planning and route aggregation, how big
does it need to be? How many aggregation boundaries does there need to
be in a fictitious network and its address space to effectively teach
address space planning and route aggregation?

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
>
>
>
> ---
> 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
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops