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

[Owen DeLong <[e-mail]>]

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 <[e-mail]> 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=[e-mail] <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]>> On Behalf Of Nick Buraglio
> Sent: Tuesday, June 15, 2021 6:36 PM
> To: Mark Smith <[e-mail] <mailto:[e-mail]>>
> Cc: v6ops list <[e-mail] <mailto:[e-mail]>>
> 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 <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/>
> 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 <http://gw-starlink.lab.buragl.io/>" port 22
> debug2: ssh_connect_direct
> debug1: Connecting to gw-starlink.lab.buragl.io <http://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 <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/>
> 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 <http://gw-starlink.lab.buragl.io/>" port 2
> debug2: ssh_connect_direct
> debug1: Connecting to gw-starlink.lab.buragl.io <http://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 <[e-mail] <mailto:[e-mail]>> wrote:
> >
> >
> >
> > On Wed, 16 Jun 2021, 07:00 Brian E Carpenter, <[e-mail] <mailto:[e-mail]>> wrote:
> >>
> >> On 16-Jun-21 02:17, [e-mail] <mailto:[e-mail]> 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
> >> [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>
> _______________________________________________
> v6ops mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
> -- 
> ===============================================
> David Farmer               Email:[e-mail] <mailto:[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
> ===============================================
> _______________________________________________
> 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]
> https://www.ietf.org/mailman/listinfo/v6ops