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

[David Farmer <[e-mail]>]

First of all, allocating a continuous /32 or shorter prefix out of FC00::7
would technically violate RFC 4193. If you want to update RFC 4193 allowing
prefixes shorter that /48 for lab testing, I’d be fine with that.

Next there is nothing magical about /32 it is the minimum allocation size
for RIRs to an LIR (in most cases an ISP), there are very many allocations
larger than /32.

In fact RIPE allows the allocation of /32 to /29 without additional
justification, see the following;

https://www.ripe.net/publications/docs/ripe-738#initial_size

So, the fact that the Documentation Prefix is limited to a /32 seems
problematic to me, at least unnecessarily limiting the examples that can be
created. If you want to represent multiple ISPs in your documentation or
example, the multiple example ISPs need to have prefixes longer than /32 to
fit in the /32 documentation prefix.

So, even if you think it is appropriate to limit the allocation to an ISP
in documentation examples to /32, you can’t represent multiple /32 ISP
allocations within the current documentation prefix.

For the documentation prefix I see at least a couple of possible solutions;

1. Allocate more documentation prefixes, maybe even asking each RIR to
allocate a documentation prefix, that would provide five sufficiently
non-contiguous documentation prefixes.

2. Ask APNIC if the current documentation prefix can be expanded in place.

It is my understanding that it was a common RIR practice for early /32
allocations to reserve a /29 for possible future in place expansion.  This
would allow up to eight /32 ISP allocations in examples. However, pointing
out the obvious, they will be continuous.

Maybe even do both.

In any case, while I support work in the area, I don’t support allocating
0200::/7 for this purpose, or validating the squatting mention elsewhere on
this deprecated allocation, by reallocating it as private use.

Thanks.

On Fri, Jun 11, 2021 at 22:06 Brian E Carpenter <[e-mail]>
wrote:

> TL;DR: fc00::/7 is already assigned for local use. What can 0200::/7 do
> better?
>
> Regards
>    Brian Carpenter
>
> On 12-Jun-21 14:58, Mark Smith wrote:
> > 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
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>
-- 
===============================================
David Farmer               Email:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================