[137512] in North American Network Operators' Group
RE: NY Times on IPv4 depletion
daemon@ATHENA.MIT.EDU (david.binet@orange-ftgroup.com)
Tue Feb 15 04:50:00 2011
From: <david.binet@orange-ftgroup.com>
To: Mark Andrews <marka@isc.org>, Cameron Byrne <cb.list6@gmail.com>
Date: Tue, 15 Feb 2011 10:48:50 +0100
In-Reply-To: <20110214225259.B93DCA0C166@drugs.dv.isc.org>
Cc: North American Network Operators Group <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Dear all,
Actually I fully agree with Cameron.=20
>From an operator point of view, it is quite difficult to rely on some speci=
fic 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 no=
t know how we can mandate some DS-lite functions in devices, for example, a=
s 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 solut=
ions integrated in devices. In mobile context, I think it is more adapted t=
o encourage IPv6 native communications and to rely on NAT64 for IPv4-only a=
ppls access even if we all know that such translation solution has some dra=
wbacks.=20=20=20=20=20
David
> -----Message d'origine-----
> De : Mark Andrews [mailto:marka@isc.org]=20
> Envoy=E9 : lundi 14 f=E9vrier 2011 23:53
> =C0 : Cameron Byrne
> Cc : North American Network Operators Group
> Objet : Re: NY Times on IPv4 depletion
>=20
>=20
> In message=20
> <AANLkTikOS1H-2APnQqWqfsj7N-L=3DkuDYGNBpYWox-DiW@mail.gmail.com>
> , Came ron Byrne writes:
> > --00163630f77d957e25049c454dc0
> > Content-Type: text/plain; charset=3DISO-8859-1
> >=20
> > On Feb 14, 2011 1:52 PM, "Mark Andrews" <marka@isc.org> wrote:
> > >
> > >
> > > In message <4D597216.1030400@brightok.net>, Jack Bates writes:
> > > >
> > > >
> > > > On 2/14/2011 12:12 PM, Cameron Byrne wrote:
> > > > > Too bad the article pushes my mobile device to their=20
> mobile site=20
> > > > > mobile.nytimes.com and that references an ipv4=20
> literal for the=20
> > > > > picture
> > to
> > > > > load .... so not only is nytimes not ipv6 it is also=20
> broken for=20
> > > > > ipv6
> > only
> > > > > users behind nat64 ....
> > > >
> > > > That's almost as bad as the hundreds of subdomains used in=20
> > > > webpages which sometimes hit broken load balancers=20
> (reporting nxdomain for AAAA).
> > >
> > > Very few do that anymore. What they do however is return=20
> the wrong=20
> > > SOA record.
> > >
> > > > So you have to check each and every domain in the=20
> source to find=20
> > > > which ones are broken.
> > >
> > > Which one really shouldn't have to do. Add DS-Lite=20
> support to the=20
> > > phone and have the carriers advertise that they support=20
> DS-Lite and=20
> > > the IPv4 literal problem goes away.
> > >
> > > This has been done in a phone already so it is possible to do.
> > >
> >=20
> > Ds-lite has been dismissed by 3gpp. Nytimes needs to start=20
> using fqdns=20
> > and ideally ipv6. Until then, it's their content that's being=20
> > mangled. It is not reasonable for network operators to engineer for=20
> > amateur web programming mistakes
>=20
> It still doesn't stop handest manufatures adding DS-Lite=20
> support and operators responding to the DHCP option so the=20
> handsets can find the AFTR box.
>=20
> NAT64/DNS64 may be the only operator side only solution but=20
> it has lots of limitation to it and it can't be made to work=20
> as well has DS-Lite even once the handset know the DNS64=20
> prefix and BIH is added to translate IPv4 to IPv6 inside the=20
> handset using the DNS64 prefix.
>=20
> Mark
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
>=20
>=20
*********************************
This message and any attachments (the "message") are confidential and inten=
ded solely for the addressees.=20
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration.=20
France Telecom Group shall not be liable for the message if altered, change=
d or falsified.
If you are not the intended addressee of this message, please cancel it imm=
ediately and inform the sender.
********************************
