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