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

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