IPv6 woes - RFC

Sun Sep 5 16:11:42 UTC 2021

On 9/5/21 12:48 AM, Carsten Bormann wrote:
> There we get to the heart of things.
> 
> The problem is not with IPv6 or your ISP (*), but with the Netflix software.

Hum....

> Doing happy eyeballs and selecting an IP address out of the ones 
> available that they *then* reject because they don’t like it: 
> beyond broken, just plain stupid.

I feel like that might be conflating a couple of things; the selection 
of $SERVICE's destination IP address, and the $CLIENT's inherent source 
is coming from.

The $SERVICE can choose any number of destination IP addresses.  The 
$CLIENT only has minimal control over which protocol is used; IPv4 or IPv6.

I do feel like the $SERVICE could rely on something a bit more 
intelligent than DNS such that they make a more informed decision based 
on the $CLIENT's inherent source address(es).

> Netflix should be using only those IP addresses that it likes (**).

I don't know if it's the case or not, but I believe that simple DNS 
based name resolution tends to be largely ignorant of knowledge of the 
$CLIENT's IP address.  --  Yes, there are some options, but those tend 
to take us way off into the weeds.

> (*) Well, an ISP that does not offer 128-bit IP *is* a problem, 
> but not the one that led to this thread.

Agreed.

> (**) if it needs to deal in address liking at all, which is also 
> fundamentally broken, but seems to be an addiction of their specific 
> industry.

First:  I like the "seems to be an addition of their specific industry".

Second:  I think that there are technological solutions that would 
present a better end user experience.  E.g. serve a page / redirect that 
sends the client to an IPv4 only destination.  Or at the very least 
provide a more graceful UX that briefly describes the problem instead of 
the service falling over leaving the end user -> consumer -> paying 
customer holding the ball and wondering what's wrong.  In many cases, 
the end user -> consumer -> paying customer is quite likely the party 
least equipped / ill-equipped to deal with the ""problem.  Especially 
when the so called problem is really something that the $SERVICE 
provider dislikes and is not a real technological problem preventing 
communications.

-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4013 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20210905/3324d149/attachment.bin>