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

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Jun 2021 10:22:51 +1200

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, [email-masked] 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
> [email-masked]
> 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
>

---

From: Nick Buraglio <[email-masked]>
Date: Fri, 11 Jun 2021 17:13:03 -0500

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
[email-masked]
+1 (510) 995-6068

On Thu, Jun 10, 2021 at 5:23 PM Brian E Carpenter <
[email-masked]> 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
>
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Mark Smith <[email-masked]>
Date: Sat, 12 Jun 2021 12:58:01 +1000

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 <[email-masked]> 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
> On Thu, Jun 10, 2021 at 5:23 PM Brian E Carpenter <[email-masked]> wrote:
>>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 12 Jun 2021 15:06:24 +1200

TL;DR: fc00::/7 is already assigned for local use. What can 0200::/7 do better?

Regards
   Brian Carpenter

---

From: Ed Horley <[email-masked]>
Date: Fri, 11 Jun 2021 20:32:22 -0700

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 <[email-masked]>
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
> >> 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
-- 
[email-masked] - 925-876-6604

---

From: Mark Smith <[email-masked]>
Date: Sat, 12 Jun 2021 14:09:34 +1000

On Sat, 12 Jun 2021 at 13:32, Ed Horley <[email-masked]> wrote:
>
> That is easy, fc00::/7 is effectively useless in dual-stack networks to test IPv6. From RFC 6724:
>

Can you explain why?

>
> 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 <[email-masked]> wrote:
>>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 12 Jun 2021 16:23:49 +1200

Ed,

That table is only the default. You can change the precedence to whatever 
you want.

Regards
   Brian

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 <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     > 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.
>     >
>     > 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 <[email-masked] <mailto:[email-masked]>> wrote:
>     >>
>     >> 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.
>     >> 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.
>     >> [email-masked] <mailto:[email-masked]>
>     >> +1 (510) 995-6068
>     >>
>     >>
>     >> On Thu, Jun 10, 2021 at 5:23 PM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
>     >>>
>     >>> On 06-Jun-21 10:27, [email-masked] <mailto:[email-masked]> wrote:
>     >>>>
>     >>>>       Date          
  : 2021-06-05
>     >>>> https://datatracker.ietf.org/doc/draft-horley-v6ops-lab/ <https://datatracker.ietf.org/doc/draft-horley-v6ops-lab/>
>     >>>>
>     >>>> https://datatracker.ietf.org/doc/html/draft-horley-v6ops-lab-00 <https://datatracker.ietf.org/doc/html/draft-horley-v6ops-lab-00>
>     >>>>
>     >>>>
>     >>>> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
>     >>>>
>     >>>>
>     >>>> [email-masked] <mailto:[email-masked]>
>     >>>> 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>
>     >>>>
>     >>>
>     >>> [email-masked] <mailto:[email-masked]>
>     >>> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
>     >>
>     >> [email-masked] <mailto:[email-masked]>
>     >> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
> 
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
> 
> -- 
> [email-masked] <mailto:[email-masked]> - 925-876-6604

---

From: David Farmer <[email-masked]>
Date: Fri, 11 Jun 2021 23:30:32 -0500

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.

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: David Farmer <[email-masked]>
Date: Sat, 12 Jun 2021 01:28:13 -0500

On Fri, Jun 11, 2021 at 21:58 Mark Smith <[email-masked]> wrote:

> does it need to be?

I don’t think it is unreasonable for there to be a larger documentation
prefix, or even multiple documentation prefixes. There should be enough
documentation IPv6 address space to provide a number of /32 ISP allocations
for an example. Even with ASCII art, examples with 3 to 5 ISPs are
relatively common.

Allocating something like a total of a /24, or even /20 for documentation
purposes isn’t going create any kind issues for IPv6, and would allow for
much more realistic examples in documentation and for training labs.

How many aggregation boundaries does there need to
> boundaries at nibble boundaries. When wouldn't that be enough to teach

I’m sorry you are suggesting for examples to be complicated and difficult
to understand.

To the contrary, examples should be simple, suggestive of what will be seen
in real operational networks, and easily understood even by IPv6 novices.

The real Internet has many ISPs, allowing for multiple /32 ISPs in an
example that is supposed to represent multiple ISPs seems necessary to meet
the above criteria, at least in my opinion.

Thanks.

---

From: Nick Buraglio <[email-masked]>
Date: Sat, 12 Jun 2021 12:05:05 -0500

Inline
---
Nick Buraglio

> the existing squatting on 0200::/7 demonstrates.*

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. The 0200::/7 has several advantages
in that it is a previously used block that has been deprecated and
lies essentially dormat, and is numerically very simple to
programmatically change ":.,$ s/0200/2000/g". 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".
> that an organisation MUST only have and  only use a single /48 ULA

True, however, that is a different solution altogether.

> 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.

> very excessive. It is twice as large as the whole of the IPv6

Possibly. We chose that space for the aforementioned reasons but are
not married to it. Obviously we welcome suggestions that could be
substituted.

> address space planning and route aggregation?

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.

Lots of thoughts on this already in the thread. David Farmer has some
good thoughts, as usual. (Hi, Dave!)

---

From: Nick Buraglio <[email-masked]>
Date: Sat, 12 Jun 2021 12:06:13 -0500

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

---

From: Mark Smith <[email-masked]>
Date: Sun, 13 Jun 2021 08:42:58 +1000

On Sat, 12 Jun 2021 at 16:28, David Farmer <[email-masked]> wrote:
> I don’t think it is unreasonable for there to be a larger documentation prefix, or even multiple documentation prefixes. There should be enough documentation IPv6 address space to provide a number of /32 ISP allocations for an example. Even with ASCII art, examples with 3 to 5 ISPs are relatively common.
>
> Allocating something like a total of a /24, or even /20 for documentation purposes isn’t going create any kind issues for IPv6, and would allow for much more realistic examples in documentation and for training labs.
>

I don't agree it would be realistic.

People who are dealing with IPv6 prefixes that are shorter than /48,
such as people at ISPs dealing with RIR /32s or shorter should be able
to work with prefix lengths that don't fall on nibble or octet
boundaries.

If they've been taught those techniques on a ULA /48 or the existing
2001:db8::/32 prefix, they should also have been taught well enough to
understand how to apply them to other prefix lengths without having to
do examples with those other prefix lengths. Doing so starts to imply
that these techniques are specific to certain prefix lengths.

> I’m sorry you are suggesting for examples to be complicated and difficult to understand.
>
> To the contrary, examples should be simple, suggestive of what will be seen in real operational networks, and easily understood even by IPv6 novices.
>

Novices aren't experts and shouldn't be expected to easily understand
what IPv6 experts do.

The trouble with making hard things too simple and easy when teaching
them is that you don't end up teaching people how to do the hard
things. The continued teaching of IPv4 Classful addressing many years
past the development and deployment of CIDR would be a canonical
example.

> The real Internet has many ISPs, allowing for multiple /32 ISPs in an example that is supposed to represent multiple ISPs seems necessary to meet the above criteria, at least in my opinion.
>

Those learning inter-ISP routing aren't going to be novices, they're
already well along the path of being IPv6 experts. The reality is that
ISPs don't all only get a /32 - the one I work for just received a /28
from our RIR.

Regards,
Mark.

---

From: David Farmer <[email-masked]>
Date: Sat, 12 Jun 2021 18:49:58 -0500

On Sat, Jun 12, 2021 at 17:43 Mark Smith <[email-masked]> wrote:

> > Allocating something like a total of a /24, or even /20 for
> documentation purposes isn’t going create any kind issues for IPv6, and
> would allow for much more realistic examples in documentation and for
> training labs.
> >
>
> > To the contrary, examples should be simple, suggestive of what will be
> seen in real operational networks, and easily understood even by IPv6
> novices.
> >
>

Why should you have to be an expert to understand a simple diagram with the
addressing for 3 typical ISPs on it? The lack of sufficient documentation
address space is what makes the diagram complicated. In reality 3 ISPs will
have 3 /32 prefixes or shorter, why can’t we create that simple example in
documentation?

How are novices to ever become experts if they can’t be thought about the
simple stuff first?

> past the development and deployment of CIDR would be a canonical

You seem to forget to we want to make IPv6 simple. Isn’t that why we have a
/64 boundary?

> ISPs don't all only get a /32 - the one I work for just received a /28

There are plenty of novices trying to connect to an Internet exchanges.
Furthermore, you make my point for me, we should be able to represent
reality in diagrams some ISP have have prefixes shorter than /32.

Regards,
> > Office of Information Techn
> <https://www.google.com/maps/search/e+of+Information+Techn?entry=gmail&source=g>
> ology
> > University of Minnesota

---

From: Mark Smith <[email-masked]>
Date: Sun, 13 Jun 2021 12:56:09 +1000

Hi Nick,

> Inline

Likewise.

<snip>

> deployment in protocol preference.

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

<snip>

> None of us are married

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>

> 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?

> 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>

> akin to a blast radius of the adjacent networks, not simply the

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.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 13 Jun 2021 16:27:21 +1200

Mark,

Playing devil's advocate for both sides:

a) In an ideal world, trainees and lab testers (two different use cases)
would never even need to know the actual prefix length or read an
actual hexadecimal address (because we ought to automate the whole
process anyway, and there are some recent RFCs about that). But that
is still a few years away, perhaps.

b) In the lab test scenario there is an important difference between
2001:db8::/32 and xxxx::/7, which is that in the second case the variable
part of the target prefix will straddle a 32-bit boundary. Checking that
all components have their uint32_t or uint64_t handling right everywhere
is something you might want to test.

(Another thing you'd be testing is whether any code anywhere is making
the assumption that all global addresses are in 2000::/3.)

Regards
   Brian

---

From: Nick Buraglio <[email-masked]>
Date: Sun, 13 Jun 2021 00:39:16 -0500

---
Nick Buraglio

> Prototype networks and lab networks are just examples of types of

Sure, but I don't see why that is an issue.

> existing documentation prefix when they can be.

I don't think anyone is saying those couldn't be used. That's largely
how we are forced to do it now and it is quite limiting to be able to
scale it up to a reasonably sized SP and their adjacent networks
without pulling around random address blocks.

> and labs before without a specific IPv6 lab/prototype address space

No one is saying that is new. Many of us have been working on it for
very long periods of time. What is new is the rapid increase in
deployment of v6. Operationally and architecturally, it is becoming
very common to need to build and plan for extremely large, detailed
deployments where the topology is built virtually or a combination of
virtually and physically.
> > > that an organisation MUST only have and  only use a single /48 ULA

Again, I agree. What if I need to generate a /32, or a /24? One could
just randomly start grabbing blocks, and that's more times than not
what happens. It can get quite messy.

> have people been using for IPv4 to do this sort of thing?

It's quite a mess, actually. I have seen more uses of the recently
announced DoD address space used in this type of work. Just this week
I was working on a deployment that used 1.0.0.0 space that I had to
clean up.

> production might be the actual new requirement.

Not sure what this means.

> - documentation and training

Agreed, we have two drafts and they tend to get conflated and / or interchanged.
> the documentation prefix for a long time.

I wholly disagree with the statement:
"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."

> justifications should be the focus of this ID. The others are already

I also don't agree that the focus is pre-staging or that the other
requirements are satisfied in the least.
Lab / prototyping can absorb that requirement, and there is actual
operational pain that both of these address. Whether we need to adjust
some of the parameters of either is still a question that still bears
more discussion.

---

From: "Dale W. Carder" <[email-masked]>
Date: Mon, 14 Jun 2021 14:14:33 -0500

> My concern about this draft is that it intentionally creates ambiguous address space, something we have very carefully avoided since the beginning of IPv6.

I'm not sure I worry as much about ambiguous as having more prefixes 
be marked "special", some of the implications of which seem may be at 
the heart of this proposal.

In draft-horley-v6ops-lab-00.txt,

"For instance, designing labs utilizing ULA fc00::/7
   [RFC4193] is problematic due to the random global ID requirement
   preventing hierarchical network prefix design possibilities."

Have the authors considered updating 4193?  Is the randomness the issue,
or is the resultant /48 the issue?  (of course, one could utilize
multiple random /48's as I think has been pointed out)

"Further, default address selection behavior [RFC6724] by end nodes
   may result in a depreferencing of such addresses and prevent lab
   deployments from accurately modeling their desired non-lab
   equivalents."

And this is the implication of having prefixes marked as special.  The
default behavior (which is only a SHOULD, i think) is not configurable or
at least not in a sane manner on a variety of platforms.  Presumably the
closed ecosystem devices (handhelds, particularly) have a goal of
minimizing user complaints and implement the table as specified, notably
with ULA at a lower precedence than GUA.  Would your document also need
to update 6724's table?  If I were a closed ecosystem vendor, once I
found out that $new_prefix gets assigned for lab use, I would probably
be inclined to move it fc00::/7 now that it becomes "special" rather
than as a stock GUA.

Dale

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Jun 2021 10:14:37 +1200

On 15-Jun-21 07:14, Dale W. Carder wrote:
> Have the authors considered updating 4193?

I'd say that isn't even necessary. The #1 rule is that fc00::/7 must be
filtered at the IGP/EGP boundary. Inside that boundary, where's the harm
(for lab tests, staging, or training)?

The point about default address selection precedence is actually
more tricky, since it would need a config update on every host.

   Brian

> Is the randomness the issue,

---

From: Ed Horley <[email-masked]>
Date: Mon, 14 Jun 2021 15:50:40 -0700

Dale,
Comments inline below with [ETH] starting my comments

> multiple random /48's as I think has been pointed out)

[ETH] RFC 4193 section 3.2 is pretty clear.
"  The allocation of Global IDs is pseudo-random [RANDOM].  They MUST
   NOT be assigned sequentially or with well-known numbers.  This is to
   ensure that there is not any relationship between allocations and to
   help clarify that these prefixes are not intended to be routed
   globally.  Specifically, these prefixes are not designed to
   aggregate."

The authors of RFC 4193 felt the pseudo-random property important enough
aspect of ULA to make it a "MUST NOT" use without it. In addition, because
of that specific requirement, there are operational implementations of ULA
that have this REQUIREMENT already built into it. For us to come back and
change that fundamental characteristic now would likely cause more pain and
confusion. It is far simplier to assign the use of a currently deprecated
address space (we are proposing 200::/7, but I am certainly open to hearing
if others have a better recommendation) and move forward without changing a
fundamental attribute of ULA.

> [ETH] If we adopt something other than ULA (fc00::/7), Site-Local
(fec0::/10), 6bone (3ffe::/16) then there is nothing that needs to be done
to RFC 6724. I would prefer to not update or touch RFC 6724 at all. The
current prefix policy table in 6724 is:

      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

Everything below (less than Precedence 35 for ::ffff:0:0/96) is
functionally useless on an dual-stack network. The majority of lab
implementations, we believe, will utilize a dual-stack approach and if ULA,
Site-Local or even 6bone address space is used for lab purposes, you will
NOT have a realistic set of host OS behaviors compared to when you actually
deploy with GUA. To state it simply, ULA is not a functional solution for
the lab prefix without fundamentally changing both RFC 4193 (see comments
above about why that is a poor idea) and also RFC 6724.

To avoid this very simple problem, we felt the solution was to just assign
GUA space that is for a lab function, mark it as "MUST" be filtered at the
Internet edge, have IANA reserve it for that purpose and the problem is
solved. We picked, as I mentioned above, 200::/7 because it is reusing a
large prefix allocation that is currently marked as deprecated by IANA (not
useable). So we are bringing life back to an address space, that will still
work for the lab functional requirement, and not allocating something that
could break up the larger address prefixes that could be assigned to any of
the RIRs. We saw this as a win/win/win. We don't have to change RFC's, we
don't need to change software OS code, we are recycling/reusing without
breaking out additional address space from the useable GUA ranges not
allocated yet.

Dale

-- 
Ed Horley
[email-masked] | (925) 876-6604
Advancing Cloud, IoT, and Security with IPv6
https://hexabuild.io
And check out the IPv6 Buzz Podcast at
https://packetpushers.net/series/ipv6-buzz/

---

From: David Farmer <[email-masked]>
Date: Tue, 15 Jun 2021 08:01:38 -0500

> fundamental attribute of ULA.

Technically, the pseudo-random assignment strategy only applies to
fd00::/8, where L = 1, and fc00::/8, where L = 0, is reserved and has no
allocation strategy define at this time, see RFC 4193, section 3.1. There
were ideas to define L = 0 for centrally assigned ULA, sometimes known as
ULA-C, for one attempt, see;

https://datatracker.ietf.org/doc/html/draft-hain-ipv6-ulac-02

So, I see no reason why we cannot define an allocation strategy for L =  0,
allowing for the local allocation of large contiguous blocks.

While allowing for L = 1 to remain for pseudo-random allocation of /48
blocks, ensuring no collisions with ULA blocks assigned per RFC 4193.
Probably adding a recommendation that two networks using large contiguous
blocks, from the L = 0 range, SHOULD NOT be merged with each other without
careful coordination of the assignments made from the L = 0 range.

Maybe recommending the Global ID for L=0 be taken from the corresponding 40
bits of the network's GUA Prefix.

Just a thought.

--

---

From: Ed Horley <[email-masked]>
Date: Tue, 15 Jun 2021 06:23:42 -0700

On Tue, Jun 15, 2021 at 06:01 David Farmer <[email-masked]> wrote:

> So, I see no reason why we cannot define an allocation strategy for L =
> 0, allowing for the local allocation of large contiguous blocks.
>
> Maybe recommending the Global ID for L=0 be taken from the corresponding
> 40 bits of the network's GUA Prefix.
>
> Just a thought.
>

Understood, and a reasonable suggestion, however it still doesn’t address
that ULA space precedence, effectively makes it useless for dual-stack lab
scenarios. Even for IPv6 only it doesn’t work unless you take all the
effort to turn off APIPA.

Preference was just not to touch ULA. The goal was to get an address prefix
that behaves and works just like GUA, just specify that it should be
filtered, and sufficiently large too.

> 2218 University Ave SE
> <https://www.google.com/maps/search/2218+University+Ave+SE?entry=gmail&source=g>
>       Phone: 612-626-0815

---

From: [email-masked]
Date: Tue, 15 Jun 2021 16:17:32 +0200 (CEST)

> effort to turn off APIPA.

Some of us use ULA for lab networks with no apparent problems.

Steinar Haug, AS2116

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Jun 2021 08:59:58 +1200

> Some of us use ULA for lab networks with no apparent problems.

But if your test case wants the internal test addresses to have exactly
the same behavior in address selection as external GUAs, the default
precedence for ULAs is an issue. I think that's Ed's point.

   Brian

---

From: Mark Smith <[email-masked]>
Date: Wed, 16 Jun 2021 07:39:06 +1000

> precedence for ULAs is an issue. I think that's Ed's point.

We're all guessing until Ed explains in more detail what his issue is.

Posting a copy of the IPv6 default address selection table without
explanation doesn't do that. We need example test scenarios to see why
there would be issues.

It seems Ed thinks IPv4 is preferred more often in a dual stack network
than it is, but I'm guessing.

Regards,
Mark.

---

From: Nick Buraglio <[email-masked]>
Date: Tue, 15 Jun 2021 18:36:19 -0500

Mark,

Here is an example of correct behavior that I see literally every day.

buraglio@netmon:~$ host gw-starlink.lab.buragl.io
gw-starlink.lab.buragl.io has address 10.255.255.3
gw-starlink.lab.buragl.io has IPv6 address fd68:1e02:dc1a:ffff::3

buraglio@netmon:~$ ssh -vvv gw-starlink.lab.buragl.io
OpenSSH_8.2p1 Ubuntu-4ubuntu0.2, OpenSSL 1.1.1f 31 Mar 2020
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include
/etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug2: resolving "gw-starlink.lab.buragl.io" port 22
debug2: ssh_connect_direct
debug1: Connecting to gw-starlink.lab.buragl.io [10.255.255.3] port 22.

As expected, this breaks comprehensive dual stack testing using DNS
(as one should) when compared to any real world behavior of GUA space.
with the 0200::/7 block configured:

buraglio@netmon:~$ host !$
host gw-starlink.lab.buragl.io
gw-starlink.lab.buragl.io has address 10.255.255.3
gw-starlink.lab.buragl.io has IPv6 address 200:1e02:dc1a:ffff::3

ssh -vvv gw-starlink.lab.buragl.io
OpenSSH_8.2p1 Ubuntu-4ubuntu0.2, OpenSSL 1.1.1f  31 Mar 2020
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include
/etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug2: resolving "gw-starlink.lab.buragl.io" port 2
debug2: ssh_connect_direct
debug1: Connecting to gw-starlink.lab.buragl.io [200:1e02:dc1a:ffff::3] port 22.
debug1: Connection established.

nb

----
Nick Buraglio

On Tue, Jun 15, 2021 at 4:39 PM Mark Smith <[email-masked]> wrote:
>
>
>
> On Wed, 16 Jun 2021, 07:00 Brian E Carpenter, <[email-masked]> wrote:
>>
> Posting a copy of the IPv6 default address selection table without explanation doesn't do that. We need example test scenarios to see why there would be issues.
>
> It seems Ed thinks IPv4 is preferred more often in a dual stack network than it is, but I'm guessing.
>
> Regards,
> Mark.
>
>
>
>
>>
>>    Brian
>>

---

From: Ed Horley <[email-masked]>
Date: Wed, 16 Jun 2021 08:39:07 -0700

On Tue, Jun 15, 2021 at 2:00 PM Brian E Carpenter <
[email-masked]> wrote:

> Yes, that is one of the issues. The fact that ULA behavior is not
consistent for host OS platforms (in my experience) confuses things. The
fact that network devices do route forwarding for ULA just like GUA (at
least from what I have seen) doesn't address the issue of how the host OS
is doing s/d address selection and prefix policy table stuff.

---

From: Kevin Myers <[email-masked]>
Date: Wed, 16 Jun 2021 15:55:03 +0000

As someone who spends time consulting in both service provider and large enterprise networks, I would also argue that the issues with ULA for infrastructure modeling/labbing at the host level are going to be far more impactful in large enterprises. Not only because of increased focus on large scale hosts/servers/apps vs. service provider - but also, GUA and ULA may both exist (or are planned) and reconfiguring lab hosts/systems isn't practical or desirable due to inconsistent results for host preference. 

Most large enterprises I've worked for strive to build lab, dev and qa environments that reflect prod as accurately as possible and this is a fairly straightforward way to avoid disparity between prod and non-prod.  

Enterprise networking is an area that we desperately need increased IPv6 adoption.  IMO, we should be making it easier to model a global enterprise that will likely have more than a /32 of GUA in order to avoid the pitfalls of ULA de-preferenced behavior or squatting on other IPv6 space. 

Kevin Myers 

-----Original Message-----
From: v6ops <[email-masked]> On Behalf Of Nick Buraglio
Sent: Tuesday, June 15, 2021 6:36 PM
To: Mark Smith <[email-masked]>
Cc: v6ops list <[email-masked]>
Subject: Re: [v6ops] I-D Action: draft-horley-v6ops-lab-00.txt

Mark,

buraglio@netmon:~$ host gw-starlink.lab.buragl.io gw-starlink.lab.buragl.io has address 10.255.255.3 gw-starlink.lab.buragl.io has IPv6 address fd68:1e02:dc1a:ffff::3

debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files

As expected, this breaks comprehensive dual stack testing using DNS (as one should) when compared to any real world behavior of GUA space.
with the 0200::/7 block configured:

buraglio@netmon:~$ host !$
host gw-starlink.lab.buragl.io
gw-starlink.lab.buragl.io has address 10.255.255.3 gw-starlink.lab.buragl.io has IPv6 address 200:1e02:dc1a:ffff::3

debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files

nb

----
Nick Buraglio

On Tue, Jun 15, 2021 at 4:39 PM Mark Smith <[email-masked]> wrote:
>> >> Understood, and a reasonable suggestion, however it still doesn’t 
>> >> address that ULA space precedence, effectively makes it useless 
>> >> for dual-stack
>> lab
>> >> scenarios. Even for IPv6 only it doesn’t work unless you take all 
>> >> the effort to turn off APIPA.
>> >
>> But if your test case wants the internal test addresses to have 
>> exactly the same behavior in address selection as external GUAs, the 
>> default precedence for ULAs is an issue. I think that's Ed's point.
>
>

---

From: David Farmer <[email-masked]>
Date: Wed, 16 Jun 2021 11:05:21 -0500

So why not use PI assignment GUA for the LAB, DEV, and QA environments?  If
it’s a question of RIR policies, I’ll happily propose policy amendments
allowing it.  However, those seem like justified requirements and I see
nothing in RIR policy to disallow LAB, DEV, and QA needs in resource
requests.

On Wed, Jun 16, 2021 at 10:55 Kevin Myers <[email-masked]>
wrote:

> As someone who spends time consulting in both service provider and large
> enterprise networks, I would also argue that the issues with ULA for
> infrastructure modeling/labbing at the host level are going to be far more
> impactful in large enterprises. Not only because of increased focus on
> large scale hosts/servers/apps vs. service provider - but also, GUA and ULA
> may both exist (or are planned) and reconfiguring lab hosts/systems isn't
> practical or desirable due to inconsistent results for host preference.
>
> Most large enterprises I've worked for strive to build lab, dev and qa
> environments that reflect prod as accurately as possible and this is a
> fairly straightforward way to avoid disparity between prod and non-prod.
>
> Enterprise networking is an area that we desperately need increased IPv6
> adoption.  IMO, we should be making it easier to model a global enterprise
> that will likely have more than a /32 of GUA in order to avoid the pitfalls
> of ULA de-preferenced behavior or squatting on other IPv6 space.
>
> Kevin Myers
>
> As expected, this breaks comprehensive dual stack testing using DNS (as
> one should) when compared to any real world behavior of GUA space.

---

From: Chris Cummings <[email-masked]>
Date: Wed, 16 Jun 2021 11:22:21 -0500

Getting enterprises to deploy v6 is already hard enough—Getting them to go
through the RIR process to get PI just to test out and learn v6 is a very
high barrier. I can speak to direct experience to this, during my time at a
large enterprise, getting time/resources to "play with" that "newfangled
IPv6" was a nearly insurmountable task. Anything we can do to make that
easier, and thus hopefully increase v6 adoption is a win in my book. And
sure, I know that they can lab out GUA using 2001:db8::/32, but since there
are enterprises that need more than a /32, we seem to have a
conundrum—having GUA space to lab with that is smaller than allocations
that are now considered fairly normal seems to be ignoring a segment of
potential IPv6 users.

Chris Cummings

On Wed, Jun 16, 2021 at 11:06 AM David Farmer <farmer=
[email-masked]> wrote:

> So why not use PI assignment GUA for the LAB, DEV, and QA environments?
> If it’s a question of RIR policies, I’ll happily propose policy amendments

---

From: Owen DeLong <[email-masked]>
Date: Thu, 17 Jun 2021 17:54:57 -0700

I can get virtually any enterprise that wants through the RIR IPv6 process for less than $2k of my time except in an extraordinary circumstance.

While it’s perceived to be difficult, it really is not that hard.

Owen

> On Jun 16, 2021, at 09:22 , Chris Cummings <[email-masked]> wrote:
> 
> Getting enterprises to deploy v6 is already hard enough—Getting them to go through the RIR process to get PI just to test out and learn v6 is a very high barrier. I can speak to direct experience to this, during my time at a large enterprise, getting time/resources to "play with" that "newfangled IPv6" was a nearly insurmountable task. Anything we can do to make that easier, and thus hopefully increase v6 adoption is a win in my book. And sure, I know that they can lab out GUA using 2001:db8::/32, but since there are enterprises that need more than a /32, we seem to have a conundrum—having GUA space to lab with that is smaller than allocations that are now considered fairly normal seems to be ignoring a segment of potential IPv6 users. 
> 
> Chris Cummings
> 
> 
> On Wed, Jun 16, 2021 at 11:06 AM David Farmer <farmer=[email-masked] <mailto:[email-masked]>> wrote:
> So why not use PI assignment GUA for the LAB, DEV, and QA environments?  If it’s a question of RIR policies, I’ll happily propose policy amendments allowing it.  However, those seem like justified requirements and I see nothing in RIR policy to disallow LAB, DEV, and QA needs in resource requests.
> 
> On Wed, Jun 16, 2021 at 10:55 Kevin Myers <[email-masked] <mailto:[email-masked]>> wrote:
> From: v6ops <[email-masked] <mailto:[email-masked]>> On Behalf Of Nick Buraglio
> To: Mark Smith <[email-masked] <mailto:[email-masked]>>
> Cc: v6ops list <[email-masked] <mailto:[email-masked]>>
> buraglio@netmon:~$ host gw-starlink.lab.buragl.io <http://gw-starlink.lab.buragl.io/> gw-starlink.lab.buragl.io <http://gw-starlink.lab.buragl.io/> has address 10.255.255.3 gw-starlink.lab.buragl.io <http://gw-starlink.lab.buragl.io/> has IPv6 address fd68:1e02:dc1a:ffff::3
> 
> buraglio@netmon:~$ ssh -vvv gw-starlink.lab.buragl.io <http://gw-starlink.lab.buragl.io/>
> debug2: resolving "gw-starlink.lab.buragl.io <http://gw-starlink.lab.buragl.io/>" port 22
> debug1: Connecting to gw-starlink.lab.buragl.io <http://gw-starlink.lab.buragl.io/> [10.255.255.3] port 22.
> 
> host gw-starlink.lab.buragl.io <http://gw-starlink.lab.buragl.io/>
> gw-starlink.lab.buragl.io <http://gw-starlink.lab.buragl.io/> has address 10.255.255.3 gw-starlink.lab.buragl.io <http://gw-starlink.lab.buragl.io/> has IPv6 address 200:1e02:dc1a:ffff::3
> 
> ssh -vvv gw-starlink.lab.buragl.io <http://gw-starlink.lab.buragl.io/>
> debug2: resolving "gw-starlink.lab.buragl.io <http://gw-starlink.lab.buragl.io/>" port 2
> debug1: Connecting to gw-starlink.lab.buragl.io <http://gw-starlink.lab.buragl.io/> [200:1e02:dc1a:ffff::3] port 22.
> On Tue, Jun 15, 2021 at 4:39 PM Mark Smith <[email-masked] <mailto:[email-masked]>> wrote:
> >
> >
> >
> > On Wed, 16 Jun 2021, 07:00 Brian E Carpenter, <[email-masked] <mailto:[email-masked]>> wrote:
> >>
> >> On 16-Jun-21 02:17, [email-masked] <mailto:[email-masked]> wrote:
> David Farmer               Email:[email-masked] <mailto:[email-masked]>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 18 Jun 2021 08:18:32 +0200

True and in any of the 5 RIRs.

Been there several times.

Regards,

Jordi

@jordipalet

El 18/6/21 2:55, "v6ops en nombre de Owen DeLong" <[email-masked] en nombre de owen=[email-masked]> escribió:

Owen

Chris Cummings

On Wed, Jun 16, 2021 at 11:06 AM David Farmer <farmer=[email-masked]> wrote:

On Wed, Jun 16, 2021 at 10:55 Kevin Myers <[email-masked]> wrote:

Kevin Myers 

-----Original Message-----
From: v6ops <[email-masked]> On Behalf Of Nick Buraglio
Sent: Tuesday, June 15, 2021 6:36 PM
To: Mark Smith <[email-masked]>
Cc: v6ops list <[email-masked]>
Subject: Re: [v6ops] I-D Action: draft-horley-v6ops-lab-00.txt

Mark,

nb

----
Nick Buraglio

-- 

_______________________________________________ v6ops mailing list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops 

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.