Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

Fri Apr 1 00:22:09 UTC 2022

> But as anyone who has tried to deploy IPv6-only networks quickly discovers, 
> at the present time, you can't deploy an IPv6-only network with any 
> success on the global internet today.  There's too many IPv6-ish networks 
> out there that haven't fully established their infrastructure to be reachable 
> without v4 connectivity also in place.  In order to deploy an IPv6 network 
> today, you *must* also have IPv4 addresses to work with.  Try to ping 
> apple.com <http://apple.com/> via v6, or microsoft.com <http://microsoft.com/> via v6, and see how far you get.
> Closer to home, try to ping juniper.com/juniper.net <http://juniper.com/juniper.net> via v6, or nokia.com <http://nokia.com/>,
> and you'll find there's a whole bunch of assumptions that you've got 
> some level of working IPv4 in the picture to talk to your hardware and 
> software vendors.
> 

While I can’t ping those, I did turn off IPv4 and successfully pinged (and downloaded
web pages from):
www.apple.com <http://www.apple.com/>
www.microsoft.com <http://www.microsoft.com/>
www.juniper.net <http://www.juniper.net/>
www.nokia.com <http://www.nokia.com/>

I wasn’t able to find AAAA records for any useful variant of juniper.com <http://juniper.com/>, but since that’s
a bank (www.juniper.com <http://www.juniper.com/> has a CNAME record pointing to www.juniper.egs1b.barclaycards.com),
I expect them to be laggards… To the best of my knowledge, very few banks have deployed
IPv6 in any meaningful way.

> In short, at the moment, you *can't* deploy IPv6 without also having IPv4 
> somewhere in your network.  IPv6 hasn't solved the problem of IPv4 
> address shortage, because you can't functionally deploy IPv6 without 
> also having at least some IPv4 addresses to act as endpoints. 

Well, yes and no. The only real limitation requiring you to “have some IPv4”
is the failure of other networks to deploy IPv6. That’s not exactly an architectural or
technical problem with IPv6, it’s a deployment issue.

> For the people who already have IPv4 addresses to say "hey, that's 
> not a problem for us" to everyone who can't get IPv4 addresses is 
> exactly the problem warned against in section 6 of https://datatracker.ietf.org/doc/html/rfc7282 <https://datatracker.ietf.org/doc/html/rfc7282>:
> 
> "
> 
> 6 <https://datatracker.ietf.org/doc/html/rfc7282#section-6>.  One hundred people for and five people against might not be rough
>     consensus
> 
>    Section 3 <https://datatracker.ietf.org/doc/html/rfc7282#section-3> discussed the idea of consensus being achieved when
>    objections had been addressed (that is, properly considered, and
>    accommodated if necessary).  Because of this, using rough consensus
>    avoids a major pitfall of a straight vote: If there is a minority of
>    folks who have a valid technical objection, that objection must be
>    dealt with before consensus can be declared. “

Again, yes and no. While the failure of some networks to deploy IPv6 is proving debilitating to other
networks (including mine) ability to move forward with deprecation of IPv4 it’s really hard for me to
view that as a technical problem with IPv6, rather than a problem with the failure of those networks.

> The point at which we have parity between IPv4 and IPv6 connectivity is the point 
> at which we can start to talk about sunsetting IPv4 and declaring it historic, and 
> no longer concern ourselves with address exhaustion.  Until then, so long as 
> being able to obtain IPv4 addresses is a mandatory step in being functional on 
> the internet, it is unreasonable to say that the address exhaustion problem is
> "solved."

OK, it’s not solved. However, the solution is fully architected and widely deployed. The failure of some
networks to deploy the solution really isn’t a design problem or a protocol problem. Arguably, it’s not
really a technical problem. It’s certainly not a technical shortcoming of IPv6. It’s a deployment failure,
arguably a bureaucratic or political problem as much as anything.

Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20220331/f6da63fa/attachment.html>