[121310] in North American Network Operators' Group
RE: Are IPv6-only Internet services viable today?
daemon@ATHENA.MIT.EDU (david.binet@orange-ftgroup.com)
Fri Jan 15 04:38:00 2010
From: <david.binet@orange-ftgroup.com>
To: Cameron Byrne <cb.list6@gmail.com>, "nanog@nanog.org" <nanog@nanog.org>
Date: Fri, 15 Jan 2010 10:37:02 +0100
In-Reply-To: <bcff0fba1001141110q142a4c3eje6c4b1d8fe02c6da@mail.gmail.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Hello,
Thank you for launching such useful discussions for operators. IPv6 introdu=
ction in mobile networks is certainly one major issue we have to consider f=
or services and business development.=20
As you stated, pressure on public and private IPv4 addresses is more and mo=
re important and we have to envisage IPv6 deployment in following years to =
avoid issues you are presenting in your mail.=20
To do so, I think we need to converge on IPv6 introduction scenarios and re=
quirements before investgating technical solutions. For example, if one tri=
gger for IPv6 introduction is the lack of IPv4 addresses, we can not rely o=
n some dual stack connectivity for IPv6 introduction and the only perennial=
solution will consist in allocating IPv6 only prefixes to UE, allowing to =
identify them without any ambiguity at least. Once such option has been ret=
ained we have to consider valid scenarios. Do we want that these only-v6 co=
nnected terminal access to IPv4-only Internet and walled garden services ? =
Do we want that some (piece of) IPv4 applications on the terminal access to=
IPv4 applications with an IPv6-only connectivity ?...IPv6 only services ma=
y be relevant, at least in some further stages of IPv6 integration.
Once we have retained valid scenarios we have to deploy technical solutions=
to answer such needs. NAT64 for example may be needed but it has to be cha=
llenged with other solutions, including proxys solutions, DS-Lite, A+P...Ac=
tually NAT64 that is a flavor of NAT44, already largely deployed in mobile =
networks, may be a solution hoping that applications will be more and more =
DS and that IPv6 native communications will grow. I think we have to avoid =
some technical solutions based on some several translation mechanisms for a=
n IP session.=20
David=20=20=20=20=20
> -----Message d'origine-----
> De : Cameron Byrne [mailto:cb.list6@gmail.com]=20
> Envoy=E9 : jeudi 14 janvier 2010 20:10
> =C0 : nanog@nanog.org
> Objet : Are IPv6-only Internet services viable today?
>=20
> Folks,
>=20
> My question to the community is: assuming a network based=20
> IPv6 to IP4 translator is in place (like NAT64 / DNS64), are=20
> IPv6-only Internet services viable as a product today? In=20
> particular, would it be appropriate for a 3G /smartphone or=20
> wireless broadband focused on at casual (web and email)=20
> Internet users? Keep in mind, these users have
> NAT44 today.
>=20
> There has been a lot of discussion about CGN / LSN / and=20
> other technologies around the corner. In the mobile network=20
> operator space, the lack of IPv4 addresses, both public and=20
> RFC 1918, has been very real for a long time. In North=20
> America, mobile network operators have numbered subscribers=20
> with BOGON space (obvious risk) and relaunched multiple=20
> instances of RFC1918 space multiple times within their AS=20
> (breaking end-to-end even within their own AS, which is a=20
> problem with technologies increasingly moving towards=20
> any-to-any SIP and IMS). In any event, we can clearly state=20
> the addressing issue has compromised both engineering and=20
> business decisions in today's major mobile networks. Both=20
> scenarios above require tremendous NAT44 infrastructure.=20=20
> And, future CGN technologies don't give me much comfort that=20
> things will get better for the operator or the consumer.
> So, i have been looking more at offering IPv6-only service=20
> with NAT64 translation to access the IPv4 Internet. For the=20
> network operator, the NAT44 and NAT64 aggregate network state=20
> / number of translation is the same to start, and as more=20
> native IPv6 content come on the NAT64 gracefully. In fact,=20
> given that Google is IPv6 now, and Google is content leader,=20
> moving to NAT64 would actually be a reduction in NET NAT translations.
>=20
> IMHO, any dual-stack solution is not an adequate interim=20
> solution since both private and public IPv4 addresses are=20
> simply not available or will be soon completely exhausted.=20=20
> Dual-stack will have a role in the future, just like public=20
> IPv4 addresses have a role today.
> Dual-stack will be a required service for users with special=20
> requirements (legacy IPv4 VPNs ....) , not average web and=20
> email users that account for greater than ~80% of a mobile=20
> operator's customer base. I also want to stress that this=20
> solution best fits new subscribers and devices, it will not=20
> be a solution for Window 98 ...
> or Windows XP in fact. This draft is helpful in understanding=20
> the issues as well as the IETF's work on NAT64
> draft-penno-behave-64-analysis-02
>=20
> Some folks in a lab decided to see what type of user=20
> experience can be expected using NAT64 and DNS64 and=20
> IPv6-only on the end system -- using commonly available=20
> hardware and software that's available today, but different=20
> from the kit used for the NANOG IPv6 hour. In this case,=20
> there is a NAT-PT box in place of NAT64, they used an open=20
> source DNS64 implementation, and a standard WIndows 7 Starter=20
> edition netbook. I think the conclusion is that casual=20
> Internet use, as a product, is possible today. It is not=20
> everything IPv4 offers today, but as IPv6 content and=20
> applications come on-line the IPv6 capabilities will exceed=20
> what IPv4 could do (no NAT for native flows).
>=20
> Screenshot video below, best viewed in HQ mode. This is just=20
> a data point with regard to functionality that is akin to=20
> NAT64 / DNS64 that is available today.
>=20
> http://www.youtube.com/theipv6guy
>=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.
********************************
