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

[Nick Buraglio <[e-mail]>]

Definitely true, it can be changed. However, doing so at scale and
across a myriad of platforms like mobile devices, embedded systems,
and esoteric instruments is functionally impossible from an
operational standpoint making the prototyping significantly more
difficult, which thereby changes the lab testing model. I had been
using the guidance from section 4.3
draft-ietf-v6ops-ula-usage-recommendations-05 to inform this view
since it states "...But since IPv6 preference is default, changing the
default in all nodes is not suitable at scale." It's certainly
possible that we are mis-interpreting or missing other context in that
vein, but it does seem fairly straightforward. As always, happy to
learn where we may be misunderstanding or lacking in context and
history.


Thanks!
nb

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


On Fri, Jun 11, 2021 at 11:23 PM Brian E Carpenter
<[e-mail]> wrote:
>
> Ed,
>
> That table is only the default. You can change the precedence to whatever
> you want.
>
> Regards
>    Brian
>
> On 12-Jun-21 15:32, Ed Horley wrote:
>
> > That is easy, fc00::/7 is effectively useless in dual-stack networks to
> test IPv6. From RFC 6724:
> >
> >
> > Prefix        Precedence Label
> >       ::1/128               50     0
> >       ::/0                  40     1
> >       ::ffff:0:0/96         35     4
> >       2002::/16             30     2
> >       2001::/32              5     5
> >       fc00::/7               3    13
> >       ::/96                  1     3
> >       fec0::/10              1    11
> >       3ffe::/16              1    12
> >
> >
> > On Fri, Jun 11, 2021 at 20:07 Brian E Carpenter <[e-mail] <mailto:[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 <http://10.0.0.0/8> and 10.0.0.0/24 <http://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/ <https://blog.apnic.net/2020/05/20/getting-ipv6-private-addressing-right/>
> >     >
> >     > On Sat, 12 Jun 2021 at 08:13, Nick Buraglio <[e-mail] <mailto:[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] <mailto:[e-mail]>
> >     >> [phone]
> >     >>
> >     >>
> >     >> On Thu, Jun 10, 2021 at 5:23 PM Brian E Carpenter <[e-mail] <mailto:[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] <mailto:[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/ <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 <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/ <ftp://ftp.ietf.org/internet-drafts/>
> >     >>>>
> >     >>>>
> >     >>>> _______________________________________________
> >     >>>> I-D-Announce mailing list
> >     >>>> [e-mail] <mailto:[e-mail]>
> >     >>>> https://www.ietf.org/mailman/listinfo/i-d-announce <https://www.ietf.org/mailman/listinfo/i-d-announce>
> >     >>>> Internet-Draft directories: http://www.ietf.org/shadow.html <http://www.ietf.org/shadow.html>
> >     >>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
> >     >>>>
> >     >>>
> >     >>> _______________________________________________
> >     >>> v6ops mailing list
> >     >>> [e-mail] <mailto:[e-mail]>
> >     >>> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
> >     >>
> >     >> _______________________________________________
> >     >> v6ops mailing list
> >     >> [e-mail] <mailto:[e-mail]>
> >     >> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
> >
> >     _______________________________________________
> >     v6ops mailing list
> >     [e-mail] <mailto:[e-mail]>
> >     https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
> >
> > --
> > [e-mail] <mailto:[e-mail]> - 925-876-6604
>