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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to