Too bad the article pushes my mobile device to their mobile site mobile.nytimes.com and that references an ipv4 literal for the picture to
load .... so not only is nytimes not ipv6 it is also broken for ipv6 only
users behind nat64 ....
That's almost as bad as the hundreds of subdomains used in webpages which sometimes hit broken load balancers (reporting nxdomain for AAAA). So you have to check each and every domain in the source to find which ones are broken.
> Too bad the article pushes my mobile device to their mobile site
> mobile.nytimes.com and that references an ipv4 literal for the picture to
> load .... so not only is nytimes not ipv6 it is also broken for ipv6 only
> users behind nat64 ....
That's almost as bad as the hundreds of subdomains used in webpages
which sometimes hit broken load balancers (reporting nxdomain for AAAA).
Very few do that anymore. What they do however is return the wrong SOA
record.
So you have to check each and every domain in the source to find which
ones are broken.
Which one really shouldn't have to do. Add DS-Lite support to the
phone and have the carriers advertise that they support DS-Lite and
the IPv4 literal problem goes away.
This has been done in a phone already so it is possible to do.
>
>
> > Too bad the article pushes my mobile device to their mobile site
> > mobile.nytimes.com and that references an ipv4 literal for the picture
to
> > load .... so not only is nytimes not ipv6 it is also broken for ipv6
only
> > users behind nat64 ....
>
> That's almost as bad as the hundreds of subdomains used in webpages
> which sometimes hit broken load balancers (reporting nxdomain for AAAA).
Very few do that anymore. What they do however is return the wrong SOA
record.
> So you have to check each and every domain in the source to find which
> ones are broken.
Which one really shouldn't have to do. Add DS-Lite support to the
phone and have the carriers advertise that they support DS-Lite and
the IPv4 literal problem goes away.
This has been done in a phone already so it is possible to do.
Ds-lite has been dismissed by 3gpp. Nytimes needs to start using fqdns and
ideally ipv6. Until then, it's their content that's being mangled. It is
not reasonable for network operators to engineer for amateur web programming
mistakes
It still doesn't stop handest manufatures adding DS-Lite support
and operators responding to the DHCP option so the handsets can
find the AFTR box.
NAT64/DNS64 may be the only operator side only solution but it has
lots of limitation to it and it can't be made to work as well has
DS-Lite even once the handset know the DNS64 prefix and BIH is added
to translate IPv4 to IPv6 inside the handset using the DNS64 prefix.
From an operator point of view, it is quite difficult to rely on some specific functions in mobile, besides an IPv6 stack - that is already difficult to get if we have a look on IPv6-ready devices available on market. I do not know how we can mandate some DS-lite functions in devices, for example, as far as there is no document where 3GPP devices are "specified". So, it is not possible to set up some IPv6 introduction strategy based on some solutions integrated in devices. In mobile context, I think it is more adapted to encourage IPv6 native communications and to rely on NAT64 for IPv4-only appls access even if we all know that such translation solution has some drawbacks.