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

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=
40umn.edu@dmarc.ietf.org> 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 <kevin.myers@iparchitechs.com>
> 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
>>
>> -----Original Message-----
>> From: v6ops <v6ops-bounces@ietf.org> On Behalf Of Nick Buraglio
>> Sent: Tuesday, June 15, 2021 6:36 PM
>> To: Mark Smith <markzzzsmith@gmail.com>
>> Cc: v6ops list <v6ops@ietf.org>
>> Subject: Re: [v6ops] I-D Action: draft-horley-v6ops-lab-00.txt
>>
>> 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 <markzzzsmith@gmail.com>
>> wrote:
>> >
>> >
>> >
>> > On Wed, 16 Jun 2021, 07:00 Brian E Carpenter, <
>> brian.e.carpenter@gmail.com> wrote:
>> >>
>> >> On 16-Jun-21 02:17, sthaug@nethelp.no wrote:
>> >> >>> 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.
>> >> >
>> >> > 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.
>> >
>> >
>> > 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.
>> >
>> >
>> >
>> >
>> >>
>> >>    Brian
>> >>
>> >> _______________________________________________
>> >> v6ops mailing list
>> >> v6ops@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/v6ops
>> >
>> > _______________________________________________
>> > v6ops mailing list
>> > v6ops@ietf.org
>> > https://www.ietf.org/mailman/listinfo/v6ops
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
> --
> ===============================================
> David Farmer               Email:farmer@umn.edu
> 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
> ===============================================
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>