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

[Ed Horley <[e-mail]>]

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]>
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
>
-- 
[e-mail] - 925-876-6604