Subject: [v6ops] IPv6 for mobile

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 21 Dec 2010 17:56:17 +0100 (CET)

First off, this information is regarding the mobile side only, not wifi.

We inventoried what kind of devices held IPv4 addresses in our mobile 
network totally (we don't do NAT currently). This includes both phones and 
dongles for mobile broadband, WAP traffic etc. Just a dump of IPv4 
addresses held at a single point in time, mapped these into phone models 
and guessed what OSes they were.

A very significant portion of the addresses held were Android and Apple 
iOS devices (I don't want to give away the details on exact numbers 
because I haven't been okeyed to publicise these yet). They don't support 
IPv6. Another large part was USB dongles from Huawei. No IPv6 support that 
we have been able to discern (at least not in the connection managers 
shipped with it). Another significant was just plain non-smartphones. No 
IPv6 support in sight that we know of.

The only platforms having any significant IPv6 support are Nokia phones 
based on Symbian and Maemo, and they're not a large portion of addresses 
held in our network, not even close to be large enough to warrant doing 
any IPv6 on the mobile side as a commercial service.

Thus, the conclusion is that IPv6 in the mobile network is not deployable 
today in real life. We're going to have to start NATing when we run out of 
new addresses to add to the smartphone explosion of "always on" we're 
seeing. We tried to do the right thing, it doesn't work in real life right 
now or in the near future as far as we can see.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 21 Dec 2010 09:10:05 -0800

Same experience.

+1 for nokia, all the operators need to start with v6 and i hope that
pays off for nokia. Ipv6 phones have to live with v4 in the ecosystem,
i encourage all to start with what is available and not wait for the
v6 business case to arrive ... For many, it will not come for a few
years ... Especially if the case is dual stack where no v4 addresses
are saved, pdp attach and signally ( real cost finance people have to
approve) goes up, and there is no meaningful benefit to the consumer

On 12/21/10, Mikael Abrahamsson <[email-masked]> wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

-- 
Sent from my mobile device

---

From: Ted Lemon <[email-masked]>
Date: Tue, 21 Dec 2010 12:10:02 -0500

I'm assume that you did this survey before iOS 4.2 came out.   It would be interesting to see how rapid uptake of 4.2 has been.   Presumably, new handsets ship with 4.2 as well.   Also, Windows 7 mobile (I assume!) comes with IPv6. So while the state of IPv6 at the time of your survey was no doubt very limited, it seems to me that that sample is probably not representative of what's in the wild today, and certainly not of what's going to be out there in six months or a year.

---

From: Fred Baker <[email-masked]>
Date: Tue, 21 Dec 2010 09:10:20 -0800

On Dec 21, 2010, at 8:56 AM, Mikael Abrahamsson wrote:

> Thus, the conclusion is that IPv6 in the mobile network is not deployable today in real life. We're going to have to start NATing when we run out of new addresses to add to the smartphone explosion of "always on" we're seeing. We tried to do the right thing, it doesn't work in real life right now or in the near future as far as we can see.

I understand the conclusion; it fits what a lot of other folks are seeing. You have two broad classes of systems in your network - those that run IPv4 and those that run IPv6, and (think venn diagrams) some subset of the systems are in both sets.

For the IPv4 systems, you have little choice but to use CGN. A lot of your colleagues have been there for a while.

For the IPv6 systems, you have the option of providing a common network.

It seems to me that you have the option of sending a note to Apple and Google to the effect of "we'd really like you to support IPv6, as it would make our network operations simpler". Android 2.1 apparently has had this capability for a while (per http://www.google.com/search?q=android+ipv6 and specifically http://www.personal.psu.edu/dvm105/blogs/ipv6/2010/05/ipv6-on-smartphones---its-happ.html), and iPhone has it in OS4 (http://www.google.com/search?q=iPhone+ipv6, and note http://www.personal.psu.edu/dvm105/blogs/ipv6/2010/06/ipv6-on-iphone.html). What you're saying is that phones in your network appear to not have been upgraded to those OS levels. What would it take to make such an upgrade happen?

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 21 Dec 2010 09:20:29 -0800

Let me repeat, only nokia has handsets that do cellular v6 today. Some
os's support wifi v6, but that is a very different function with
different hardware peices.

Also, nobody controls the os/chip/oem/sp eco system. No one entity can
make it happen. Many sp's ask and ask, very little action and no
comittments.

On 12/21/10, Ted Lemon <[email-masked]> wrote:
> I'm assume that you did this survey before iOS 4.2 came out.   It would be
> interesting to see how rapid uptake of 4.2 has been.   Presumably, new
> handsets ship with 4.2 as well.   Also, Windows 7 mobile (I assume!) comes
> with IPv6. So while the state of IPv6 at the time of your survey was no
> doubt very limited, it seems to me that that sample is probably not
> representative of what's in the wild today, and certainly not of what's
> going to be out there in six months or a year.
>

---

From: Rémi Després <[email-masked]>
Date: Tue, 21 Dec 2010 18:42:51 +0100

Le 21 déc. 2010 à 18:10, Cameron Byrne a écrit :
> +1 for nokia, all the operators need to start with v6 and i hope that pays off for nokia. ...
>> ...
>> today in real life.

With 6rd, adding an IPv6 service to a NATed IPv4 service is not complex for operators .
(It just takes to have 6rd border relays between IPv4 and IPv6 networks, ref. RFC 5569 and RFC 5969).

of course, only mobile phones that support 6rd can take advantage of such an IPv6 service, but, in smartphones that are already dual-stack like those of Nokia, it shouldn't be difficult to add 6rd (with the DHCP option of RFC 5969 that makes it plug-and-play).

Regards,
RD

---

From: Fred Baker <[email-masked]>
Date: Tue, 21 Dec 2010 09:47:02 -0800

Let's see if I have this right. Folks are concerned that phones don't have IPv6 on the cellular interface, and your proposal is to have the cell phones add a work-around service for the lack of IPv6 instead of asking them to add IPv6. Did I correctly understand your proposal?

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 21 Dec 2010 09:47:28 -0800 (PST)

> Also, nobody controls the os/chip/oem/sp eco system. 

This is exactly where I heard the problem is.
Otherwise all OSes have been supporting IPv6 since long time.

>No  one entity can

Is there a standards body where these people go?
I was going to suggest sending an IETF liaison to them.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 21 Dec 2010 12:51:28 -0500

> Let's see if I have this right. Folks are concerned that phones don't have IPv6 on the cellular interface, and your proposal is to have the cell phones add a work-around service for the lack of IPv…

In all fairness, at least one person has asserted that the *hardware* somehow doesn't support IPv6.   I find this difficult to believe, but if true, Rémi's proposal makes sense.

---

From: Rémi Després <[email-masked]>
Date: Tue, 21 Dec 2010 18:56:13 +0100

> Let's see if I have this right. Folks are concerned that phones don't have IPv6 on the cellular interface, and your proposal is to have the cell phones add a work-around service for the lack of IPv…

Not quite.
They can do both:
- be happy if they can *rapidly* get IPv6 service on existing infrastructures (the objection that is is complex to operate dual-stack routing becoming becoming ineffective)
- insist on having asap a better service (one that doesn't need encapsulation).

RD

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 21 Dec 2010 09:57:17 -0800

Who benefits from 6rd on a handset? The user does not know the
difference and the sp does not remove any business risk related to
ipv4 exhaust.

On 12/21/10, Ted Lemon <[email-masked]> wrote:
>> Let's see if I have this right. Folks are concerned that phones don't have
>> IPv6 on the cellular interface, and your proposal is to have the cell
>> phones add a work-around service for the lack of IPv6 instead of asking
>> them to add IPv6. Did I correctly understand your proposal?
>
> In all fairness, at least one person has asserted that the *hardware*
> somehow doesn't support IPv6.   I find this difficult to believe, but if
> true, Rémi's proposal makes sense.
>

---

From: Rémi Després <[email-masked]>
Date: Tue, 21 Dec 2010 19:17:16 +0100

Le 21 déc. 2010 à 18:57, Cameron Byrne a écrit :

> Who benefits from 6rd on a handset?

The question you ask amounts to "what is the benefit of having an IPv6 global address at which you can be reached".
That is the question asked by those who aren't interested in IPv6-service rapid deployment.

RD

> The user does not know the

---

From: Rémi Després <[email-masked]>
Date: Tue, 21 Dec 2010 19:31:55 +0100

> That is the question asked by those who aren't interested in IPv6-service rapid deployment.

Oops, I meant that what the handset gets, with 6rd in addition to its NATed IPv4 address, is a native IPv6 PREFIX.
This is important because some handsets include an internal router.
With an IPv6 prefix, hosts behind such a router can all have their individual IPv6 global addresses.

Regards,
RD

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 21 Dec 2010 11:03:33 -0800

Thd issue here is that 6rd costs money, but gradma just wants facebook
to work and it just works today with v4.

One unofficial definition of insanity is doing the same thing (dual
stack) & and expecting a different result (deployment, even not
deployed in new LTE networks).

You and i like and value unique addresses, but the folks in marketing
that understands what common consumers will pay for do not value
unique v6, they value time to market and no new incremenatal costs
....

On 12/21/10, Rémi Després <[email-masked]> wrote:
>> The question you ask amounts to "what is the benefit of having an IPv6
>> global address at which you can be reached".

---

From: Ted Lemon <[email-masked]>
Date: Tue, 21 Dec 2010 14:24:03 -0500

> difference and the sp does not remove any business risk related to

You'd have to use an RFC1918 address space, but since you would not be routing it to the public internet, but only using it essentially for framing, you wouldn't have to run an address translator.

Note that I am not seriously proposing this as a solution, because I do not believe there is a need for it.   If there *were* some sort of hardware restriction in handsets preventing the use of native IPv6, then this might be a useful thing to do.

---

From: <[email-masked]>
Date: Tue, 21 Dec 2010 19:29:08 +0000

Hi,

It might be worthwhile to repeat here that last year 3GPP had lengthy discussion on transition mechanisms and if something was clear, was that there is no interest for generalized host based tunneling (IPvx over IPvx) approaches.

For hosts the 3GPP access will look like dual-stack, or IPv6-only with NAT64.

In some mail there was question of HW dependencies. It is this: in 3GPP networks layer 2 has to explicitly support transport of IPv4 and IPv6 packets (I refer here to IPv4, IPv6, or IPv4v6 type of PDP contexts). This layer 2 is usually implemented as part of modem chipset firmware, which is more difficult to upgrade than the main handset OS. Current firmwares used in modem chipsets don't always support IPv6 type of PDP context..

I'm quite confident things are improving where gaps exist.

Best regards,

Teemu
________________________________________
From: [email-masked] [[email-masked]] on behalf of ext Rémi Després [[email-masked]]
Sent: Tuesday, December 21, 2010 8:31 PM
To: Cameron Byrne
Cc: v6ops v6ops
Subject: Re: [v6ops] IPv6 for mobile

Regards,
RD

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 21 Dec 2010 20:39:53 +0100 (CET)

On Tue, 21 Dec 2010, Ted Lemon wrote:

> I'm assume that you did this survey before iOS 4.2 came out.

Someone else said it as well, but let's just be crystal clear:

There is no production image of Apple iOS or Android that supports IPv6 
PDP context on any hardware platform available publically. There also are 
no public roadmaps stating when this might change.

As an mobile operator, I can only assume this means it's at least 6-12 
months into the future and we will act accordingly. We could be ready in a 
few months with IPv6 enabled mobile core and we're doing some of that, but 
there seems to be no chance that we can dent the IPv4 address usage growth 
before exhaustion, thus NAT is the only realistic way out right now and 
for the near future.

---

From: Martin Millnert <[email-masked]>
Date: Tue, 21 Dec 2010 20:39:44 +0100

Hi,

On Tue, 2010-12-21 at 09:10 -0800, Fred Baker wrote:
> Android 2.1 apparently has had this capability for a while (per
> http://www.google.com/search?q=android+ipv6 and specifically
> http://www.personal.psu.edu/dvm105/blogs/ipv6/2010/05/ipv6-on-smartphones---its-happ.html), and iPhone has it in OS4 (http://www.google.com/search?q=iPhone+ipv6, and note http://www.personal.psu.edu/dvm105/blogs/ipv6/2010/06/ipv6-on-iphone.html). What you're saying is that phones in your network appear to not have been upgraded to those OS levels.

The following is as per my understanding from the google ipv6 conference
2010 and mostly Cameron on v6-ml:s.

What Cameron (as the mobile network) has been saying on a few occasions
(almost with some kind of regularity), is that after the OS supports it,
the handset providers has to license the v6 code from the chipset
manufacturers, where available (it is increasingly available AFAIK).
~none has. 
So even if the chipset manufacturers has produced v6 code in the chipset
(which some seems to have done during 2009/2010, and increasingly do; ST
Ericsson has a new one out which seems functional), ~no handset provider
has so far chosen to buy the feature.

Lacking an absent standardization of IPv6 as a requirement on this mess
of entities involved in successfully rolling out IPv6 on the mobile
networks, it seems to me that one of the better ways to kill the
dead-lock would be if the chipset providers (by some financial magic,
at worst) gave a discount on chipsets that had v6 *enabled*.  At the
least, made it free to license.  But I guess that the former won't
happen (not the first time the idea of $ as an incentive to roll out
IPv6 has appeared). The chances of the latter happening I have no idea.

If all these involved entities can't figure it out, my guess is that
regulators will start to think they have to do something about it
eventually.

Cheers,
-- 
Martin Millnert <[email-masked]>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 21 Dec 2010 20:47:00 +0100 (CET)

On Tue, 21 Dec 2010, Fred Baker wrote:

> It seems to me that you have the option of sending a note to Apple and 
> Google to the effect of "we'd really like you to support IPv6, as it 
> would make our network operations simpler".

I have done this to some people on this list. We're also contacting them 
thru official channels.

> What you're saying is that phones in your network appear to not have 
> been upgraded to those OS levels. What would it take to make such an 
> upgrade happen?

Because the baseband parts of the phones don't support IPv6, there is no 
possibility on any production Android phone I am aware of to run an IPv6 
PDP context, neither so for Apple iOS.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 21 Dec 2010 15:06:24 -0500

> PDP context, neither so for Apple iOS.

This being the case, Rémy's proposal is not without merit.   Although I still question which is harder: upgrading the baseband, or adding 6rd to the O.S.   Given the level of control Apple seems to exert over their baseband firmware (to wit, the carrier locking they do), it would still really surprise me if they really didn't have the ability to install v6 on the baseband, but perhaps there are stability concerns.   I suspect Google has less influence, since they are not the hardware manufacturer.

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 21 Dec 2010 13:41:29 -0800 (PST)

> Hi,
> 
> It might be worthwhile to repeat here that last year 3GPP had lengthy  
>discussion on transition mechanisms and if something was clear, was that there  
>is no interest for generalized host based tunneling (IPvx over IPvx)  
>approaches.
> 
> In some mail there was question of HW dependencies.  It is this: in 3GPP 
>networks layer 2 has to explicitly support transport of IPv4  and IPv6 packets 
>(I refer here to IPv4, IPv6, or IPv4v6 type of PDP contexts).  This layer 2 is 
>usually implemented as part of modem chipset firmware, which is  more difficult 
>to upgrade than the main handset OS. Current firmwares used in  modem chipsets 
>don't always support IPv6 type of PDP context..
> 

Isn't it a layer violation to support IPv6 in Layer 2?
In fact PDP context should be session layer in OSI layering, UE sets up a 
session with PDN GW and hence the implementation should be above IP layer.
It is really weird.

---

From: Rémi Després <[email-masked]>
Date: Wed, 22 Dec 2010 10:39:56 +0100

Hi, Teemu,

Le 21 déc. 2010 à 20:29, <[email-masked]> <[email-masked]> a écrit :
> ...It might be worthwhile to repeat here that last year 3GPP had lengthy discussion on transition mechanisms and if something was clear, was that there is no interest for generalized host based tunneling (IPvx over IPvx) approaches.

Don't get me wrong: the idea is by no means to "generalize" IP/IP tunneling.
It only to recognize that, where IPv6-routing can't be rapidly available, the 6rd automatic tunneling is an inexpensive way to rapidly offer the IPv6-service.

I know some people say that, after all, rapid deployment of the IPv6-service isn't that important.
Some others, of which I am, believe IPv6-service should be made available asap, in as many environments as possible.

> For hosts the 3GPP access will look like dual-stack, or IPv6-only with NAT64.

For clarification, do you mean both 3G and LTE or just LTE? 
Even if it is LTE-only, I remain confused: Cameron wrote in a recent mail that "vodafone in germany is launched LTE v4 only because of green field core lte gear not supporting v6."

In any case, 6rd can be used to rapidly extend the IPv6-service across those pre-3GPP networks (GPRS, Edge ...) that, for a significant time, will remain with IPv4-only routing.
No obligation, of course, but why not?

> I'm quite confident things are improving where gaps exist.

So am I.
But isn't IPv6-service across pre-3GPP networks good to have? 

Best regards,
RD

---

From: <[email-masked]>
Date: Wed, 22 Dec 2010 13:22:07 +0000

Hi Rémi,

In high level view you can think of GPRS, EDGE, WCDMA, HSPA, and LTE as being layer 1. Hence there is no difference IP address family wise which one you use.

I.e. IPv4-only, dual-stack, IPv6-only, are all possible in all those techniques. That is why e.g. Symbian devices have had IPv6 over cellular support since 2003 or so.

It should also be known that there are no standard mandates to have IPv6 in LTE. IPv6 is fully optional. There was discussion in the past if IPv6 should be mandatory e.g. in LTE by the spec, but such proposals were not accepted. It continues to be up-to marketplace to decide whether or not to have IPv6 supported.

Anyhow, the 3GPP has pretty much decided that it is not worthwhile to deploy host based tunneling techniques (except maybe for IP mobility - DSMIP6), but it is better go always native instead. With the trouble one puts 6RD to a host one can have native IPv6 as well, but you avoid issues with quality of service, policy and charging controls, header overhead, and so on (these also are some reasons why with DSMIP6 the mobile is at home when in 3GPP access). Of course the IP packets sent by mobile are then GTP/PMIP tunneled to gateway over infrastructure using IPv4 and/or IPv6.

Please see also: https://datatracker.ietf.org/doc/draft-korhonen-v6ops-3gpp-eps/

Best regards,

Teemu

> -----Original Message-----
> From: ext Rémi Després [mailto:[email-masked]]
> Sent: 22. joulukuuta 2010 11:40
> To: Savolainen Teemu (Nokia-MS/Tampere)
> Cc: v6ops v6ops
> > ...It might be worthwhile to repeat here that last year 3GPP had
> lengthy discussion on transition mechanisms and if something was clear,
> was that there is no interest for generalized host based tunneling
> (IPvx over IPvx) approaches.
> 
> It only to recognize that, where IPv6-routing can't be rapidly
> available, the 6rd automatic tunneling is an inexpensive way to rapidly
> offer the IPv6-service.
> 
> Some others, of which I am, believe IPv6-service should be made
> available asap, in as many environments as possible.
> 
> 
> Even if it is LTE-only, I remain confused: Cameron wrote in a recent
> mail that "vodafone in germany is launched LTE v4 only because of green
> field core lte gear not supporting v6."
> 
> In any case, 6rd can be used to rapidly extend the IPv6-service across
> those pre-3GPP networks (GPRS, Edge ...) that, for a significant time,
> will remain with IPv4-only routing.
> > In some mail there was question of HW dependencies. It is this: in
> 3GPP networks layer 2 has to explicitly support transport of IPv4 and
> IPv6 packets (I refer here to IPv4, IPv6, or IPv4v6 type of PDP
> contexts). This layer 2 is usually implemented as part of modem chipset
> firmware, which is more difficult to upgrade than the main handset OS.
> Current firmwares used in modem chipsets don't always support IPv6 type
> of PDP context..
> >

---

From: Rémi Després <[email-masked]>
Date: Wed, 22 Dec 2010 19:14:49 +0100

Hi Teemu,

Le 22 déc. 2010 à 14:22, <[email-masked]> <[email-masked]> a écrit :
> ... In high level view you can think of GPRS, EDGE, WCDMA, HSPA, and LTE as being layer 1. Hence there is no difference IP address family wise which one you use.
> 
> I.e. IPv4-only, dual-stack, IPv6-only, are all possible in all those techniques.

Thanks.
That's a useful clarification on layer-orthogonality of 3GPP recommendations.

Does this mean that operators that will offer IPv6 on their 4G networks will always offer IPv6 on their GPRS and Edge networks at the same time?

> That is why e.g. Symbian devices have had IPv6 over cellular support since 2003 or so.
> 

> 
> Anyhow, the 3GPP has pretty much decided that it is not worthwhile to deploy host based tunneling techniques (except maybe for IP mobility - DSMIP6), but it is better go always native instead.

I agree that, if there is no consideration about WHEN IPv6 connectivity is offered, DS-routing is ALWAYS better than automatic IPv6 tunneling over IPv4.

The point is that, if an operator has difficulties to add an IPv6 bearer service to its network, supporting one or a few 6rd relays at its border, and 6rd parameters in its DHCP service, is easy to do.
This doesn't provide as complete a solution, but does provide some IPv6 connectivity to UEs that support 6rd.   

> With the trouble one puts 6RD to a host one can have native IPv6 as well,

Of course, any 6rd-capable UE should FIRST be able to support native IPv6 at its WAN interface!

The goal is that 6rd-capable hosts have IPv6 connectivity NOT ONLY on networks that moved their bearer services from IPv4-only to dual-stack routing, BUT ALSO on networks that are still IPv4-only.
 
To become 6rd-capable, a UE only needs a modified 6to4 module, and recognition of the 6rd DHCP option.
Note that not only handsets are concerned, but also PCs having mobile broadband sticks (they may not need fast roaming but may need IPv6 incoming connectivity). 

> but you avoid issues with quality of service, policy and charging controls, header overhead, and so on (these also are some reasons why with DSMIP6 the mobile is at home when in 3GPP access). Of course the IP packets sent by mobile are then GTP/PMIP tunneled to gateway over infrastructure using IPv4 and/or IPv6.

6rd has clearly a header overhead.
It can therefore only be envisaged as an transition solution.
Its purpose can only be to permit SOME operators, that have difficulties to deploy dual-stack bearer services, to offer IPv6 connectivity more rapidly (IMHO a valuable objective).

About the header overhead, wouldn't header compression work for TCP-UDP/IPv6/IPv4 as well as it does for TCP-UDP/IPv4 or TCP-UDP/IPv6?
(I don't have all the knowledge to check it myself.)

As to QoS and charging issues, they remain those of IPv4.
In my understanding, they shouldn't be a problem with 6rd.

> Please see also: https://datatracker.ietf.org/doc/draft-korhonen-v6ops-3gpp-eps/

I may not understand all the context, but this is indeed a useful reference. 

UE vendors and Operators make their own choices, this couldn't be clearer to me.
My contribution is only to suggest looking at some approaches that, in my understanding, haven't been completely considered yet, and might contribute to accelerate IPv6 connectivity.

Best regards,
RD

---

From: <[email-masked]>
Date: Wed, 22 Dec 2010 21:09:09 +0000

Hi Rémi,

It would hardly make sense to provide IPv6 only at 3G or LTE access, which has less coverage than 2(.5)G. So yes, IPv6 once deployed by an operator would be available elsewhere (otherwise your IPv6 sessions would break when moving away from LTE or 3G coverage to 3G or 2G).

I think the host based tunneling benefits were pretty thoroughly discussed in 3GPP and all-in-all it was seen that it is more advantageous to deploy IPv6 (and IPv4) natively than have interim tunneling solutions in play. The story might be different if there were IPv6-only services that would have to be made available *by an access operator*, but there just are none yet (there are IPv6-only services, but hosts using those tend to have IPv6-over-something already and required tunnel servers are then hosted by the vendor of such IPv6-only service).

It is really worthwhile to remember that 3GPP architecture already uses a lot of network based tunneling solutions (GTP/PMIP6) that support transport of user plane IPv6 packets over IPv4-only network infrastructures, and that is the reason why providing IPv6 for hosts probably is also easier than in some fixed networks. 

Please btw note that DS-Lite, 4RD, and other IPv4-over-IPv6 host based tunneling solutions are as rejected due same reasons.

About header compressions. RoHC definitely does good job in compression, but it is relatively expensive CPU-wise and not widely deployed yet. Requirement to deploy header compressions as a solution to compensate overhead caused by tunneling will not fly:)

Best regards,

Teemu

> Sent: 22. joulukuuta 2010 20:15
> Cc: [email-masked]
> > ... In high level view you can think of GPRS, EDGE, WCDMA, HSPA, and
> LTE as being layer 1. Hence there is no difference IP address family
> wise which one you use.
> >
> Does this mean that operators that will offer IPv6 on their 4G networks
> will always offer IPv6 on their GPRS and Edge networks at the same
> time?
> 
> 
> > It should also be known that there are no standard mandates to have
> IPv6 in LTE. IPv6 is fully optional. There was discussion in the past
> if IPv6 should be mandatory e.g. in LTE by the spec, but such proposals
> were not accepted. It continues to be up-to marketplace to decide
> whether or not to have IPv6 supported.
> 
> >
> > Anyhow, the 3GPP has pretty much decided that it is not worthwhile to
> deploy host based tunneling techniques (except maybe for IP mobility -
> DSMIP6), but it is better go always native instead.
> 
> I agree that, if there is no consideration about WHEN IPv6 connectivity
> is offered, DS-routing is ALWAYS better than automatic IPv6 tunneling
> over IPv4.
> 
> The point is that, if an operator has difficulties to add an IPv6
> bearer service to its network, supporting one or a few 6rd relays at
> its border, and 6rd parameters in its DHCP service, is easy to do.
> The goal is that 6rd-capable hosts have IPv6 connectivity NOT ONLY on
> networks that moved their bearer services from IPv4-only to dual-stack
> routing, BUT ALSO on networks that are still IPv4-only.
> 
> Note that not only handsets are concerned, but also PCs having mobile
> broadband sticks (they may not need fast roaming but may need IPv6
> incoming connectivity).
> 
> > but you avoid issues with quality of service, policy and charging
> controls, header overhead, and so on (these also are some reasons why
> with DSMIP6 the mobile is at home when in 3GPP access). Of course the
> IP packets sent by mobile are then GTP/PMIP tunneled to gateway over
> infrastructure using IPv4 and/or IPv6.
> 
> Its purpose can only be to permit SOME operators, that have
> difficulties to deploy dual-stack bearer services, to offer IPv6
> connectivity more rapidly (IMHO a valuable objective).
> 
> About the header overhead, wouldn't header compression work for TCP-
> UDP/IPv6/IPv4 as well as it does for TCP-UDP/IPv4 or TCP-UDP/IPv6?
> My contribution is only to suggest looking at some approaches that, in
> my understanding, haven't been completely considered yet, and might
> contribute to accelerate IPv6 connectivity.
> 
> 
> Best regards,
> RD
> 
>

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 23 Dec 2010 16:58:55 +1100

Remi,

In my opinion the easiest and quickest way for people deploy IPv6 in 3G
networks is to simply enable IPv6 on the handsets. There are also tweaks
needed within the core network but they're more like lots of trivial tasks
than major tasks. Many people have already explained that IPv6 is supported
in the IPv6 stacks in handsets but what's missing on those newer phones is
the PDP context activation for IPv6. This is way simpler and closer to the
ultimate goal than trying to implement something complex in the host that
allows it to "fool" the core network. That type of approach won't work in 3G
networks because there is cross layer violation all over the place for QoS,
monitoring, charging. ...etc. It simply isn't worth the trouble.

Hesham

On 22/12/10 8:39 PM, "Rémi Després" <[email-masked]> wrote:

>> ...It might be worthwhile to repeat here that last year 3GPP had lengthy
>> discussion on transition mechanisms and if something was clear, was that
>> there is no interest for generalized host based tunneling (IPvx over IPvx)
>> approaches.
> 
> It only to recognize that, where IPv6-routing can't be rapidly available, the
> 6rd automatic tunneling is an inexpensive way to rapidly offer the
> IPv6-service.
> 
> Some others, of which I am, believe IPv6-service should be made available
> asap, in as many environments as possible.
>  
> 
> Even if it is LTE-only, I remain confused: Cameron wrote in a recent mail that
> "vodafone in germany is launched LTE v4 only because of green field core lte
> gear not supporting v6."
> 
> In any case, 6rd can be used to rapidly extend the IPv6-service across those
> pre-3GPP networks (GPRS, Edge ...) that, for a significant time, will remain
> with IPv4-only routing.
>> usually implemented as part of modem chipset firmware, which is more
>> difficult to upgrade than the main handset OS. Current firmwares used in
>> modem chipsets don't always support IPv6 type of PDP context..
>>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 23 Dec 2010 07:49:21 +0100 (CET)

> For clarification, do you mean both 3G and LTE or just LTE?

I'd imagine most operators will use the same core nodes for 
GSM/UMTS-HSPA/LTE so the capabilities will be very similar.

> field core lte gear not supporting v6."

Having participated in a LTE core node procurement, I can say that if IPv6 
was a requirement, there are nodes to support it (at least with vendors 
willing to commit to roadmaps enabling basic IPv6 connectivity this year). 
I doubt it's a core problem, I think it's a terminal problem. LTE has 
enough terminal problems as it is, without involving IPv6.

---

From: Rémi Després <[email-masked]>
Date: Thu, 23 Dec 2010 09:34:47 +0100

Le 21 déc. 2010 à 20:47, Mikael Abrahamsson a écrit :

>> It seems to me that you have the option of sending a note to Apple and Google to the effect of "we'd really like you to support IPv6, as it would make our network operations simpler".
> 
> I have done this to some people on this list. We're also contacting them thru official channels.
> 
>> What you're saying is that phones in your network appear to not have been upgraded to those OS levels. What would it take to make such an upgrade happen?
> 
> Because the baseband parts of the phones don't support IPv6, there is no possibility on any production Android phone I am aware of to run an IPv6 PDP context, neither so for Apple iOS.

In my understanding, 6rd permits to use the IPv4 PDP context to support IPv6 connectivity.

RD

---

From: Rémi Després <[email-masked]>
Date: Thu, 23 Dec 2010 09:57:01 +0100

Mikael,

It seems that:
- IPv6 availability is easy on 3G (as it is on LTE, but LTE has its own youth problems)
- at least Nokia has some 3G handsets that support dual stack,
- 3GPP encourages IPv6 connectivity.

Then, what prevents operators to offer IPv6 now?
If it is only a terminal problem, I wonder which comments Nokia has to offer.

Regards,
RD

Le 23 déc. 2010 à 07:49, Mikael Abrahamsson a écrit :

> I'd imagine most operators will use the same core nodes for GSM/UMTS-HSPA/LTE so the capabilities will be very similar.
> 
> Having participated in a LTE core node procurement, I can say that if IPv6 was a requirement, there are nodes to support it (at least with vendors willing to commit to roadmaps enabling basic IPv6 connectivity this year).
> I doubt it's a core problem, I think it's a terminal problem. LTE has enough terminal problems as it is, without involving IPv6.
> 
> --

---

From: Rémi Després <[email-masked]>
Date: Thu, 23 Dec 2010 10:20:02 +0100

> Please btw note that DS-Lite, 4RD, and other IPv4-over-IPv6 host based tunneling solutions are as rejected due same reasons.

Indeed, but, as we know, all these are solution to add IPv4 connectivity to IPv6-only infrastructures.
Mobile operators don't need to discontinue their fully operational IPv4 services.
Therefore, they don't need any IPv4-over-IPv6 tunneling.

What is expected from operators is rapid deployment of IPv6 connectivity.
Whether 6rd is one of the useful solutions is, I agree, debatable, but 6rd is at least in scope for the problem at hand.

Cheers,
RD

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 23 Dec 2010 10:57:29 +0100 (CET)

On Thu, 23 Dec 2010, Rémi Després wrote:

>> Because the baseband parts of the phones don't support IPv6, there is 
>> no possibility on any production Android phone I am aware of to run an 
>> IPv6 PDP context, neither so for Apple iOS.
>

Of course.

But then again, I am not aware of any 6RD functionality in any of the 
above mentioned devices either. I also don't really see the point, if we 
have to NAT them anyway then I think we can wait until they have IPv6 
properly and then perhaps do some kind of translation/tunneling for IPv4 
connectivity.

Proper dual stack for mobile with dual PDP context (or GTPv2 dual stack 
carrier) is a long way away due to cost and lack of support from roaming 
partners.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 23 Dec 2010 10:59:53 +0100 (CET)

> If it is only a terminal problem, I wonder which comments Nokia has to offer.

In our network, the amount of Symbian and Maemo devices doesn't warrant 
launching an IPv6 service. We need widespread IPv6 support on Apple iOS, 
Android or USB dongles to warrant doing IPv6 service.

---

From: Xiangsong Cui <[email-masked]>
Date: Thu, 23 Dec 2010 17:59:19 +0800

> IPv6 has appeared). The chances of the latter happening I have no idea.

ICPs and applications also need to update to IPv6, would carriers give ICPs
discount for their IPv6 bandwidth access?
And for end customers, what is their motivation to turn on IPv6? The user
equipments MUST support IPv4 in many years. Sometimes, in current networks,
IPv4 is the better choice to users, for example, VoIP service, IPv6 leads to
bigger size packet (longer IP header), which would increase the traffic
amount, and for mobile users (wireless, low bandwidth), maybe means worse
quality of experience. Would carriers also give discount to IPv6 users?

> regulators will start to think they have to do something about it

In my mind regulator is the only way, but does this destroy "Network
Neutrality" of free internet?

PS, I'm serious.

Thanks and Regards,
Xiangsong

---

From: Rémi Després <[email-masked]>
Date: Thu, 23 Dec 2010 11:23:50 +0100

Le 23 déc. 2010 à 10:59, Mikael Abrahamsson a écrit :

> In our network, the amount of Symbian and Maemo devices doesn't warrant launching an IPv6 service.

If you launch the service for those devices that are ready, others are more likely to follow than if you don't.
Right?

That's where minimizing the cost of your initial deployment is important.
If it is significantly more expensive without 6rd than with it, starting with just as many 6rd border relays as you have 10/8 IPv4  could be a good initial approach.

Doing so, IPv6 connectivity would rapidly be available to devices that support 6rd.

Note that Linux already has some open-source code for 6rd.
Windows and OS X have 6to4 and DHCP modules. THese need only minor complements to support the 6rd of RFC 5969.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Thu, 23 Dec 2010 11:31:59 +0100

Le 23 déc. 2010 à 10:57, Mikael Abrahamsson a écrit :
> I also don't really see the point, if we have to NAT them anyway

What you mean isn't clear:
- 6rd does provide IPv6 global addresses, with e2e transparency
- 6rd is precisely a NO-NAT solution.
- It has been working as such since December 2007 (RFC5569).

RD

---

From: jouni korhonen <[email-masked]>
Date: Thu, 23 Dec 2010 12:46:34 +0200

> Then, what prevents operators to offer IPv6 now?

There are potentially "minor" things (on top of my head) like lack of IPv6 support in backend billing systems, lack of IPv6 support in subscriber provisioning systems, lack of IPv6 "definition" in subscription process, untested monitoring/management systems for IPv6 subscribers, missing IPv6 knowledge in customer support, lack of GSMA IPv6 roaming guidelines, roaming billing procedures not being updated yet for IPv6 etc.. So while the technology has practically been there for quite some time, it does not mean business and operations enablers are there yet.

- Jouni

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 23 Dec 2010 12:12:30 +0100 (CET)

> If you launch the service for those devices that are ready, others are more likely to follow than if you don't.

That's easy to say. What should we call the service? It's going to IPv6 
only with NAT64/DNS64, so it's highly likely to be worse than NATed IPv4 
right now.

> That's where minimizing the cost of your initial deployment is important.

We're very well aware of the possibilities. Our IP core and peering 
infrastructure has been natively IPv6 enabled for 2 years and we've beeon 
6bone since it's inception..

> If it is significantly more expensive without 6rd than with it, starting 
> with just as many 6rd border relays as you have 10/8 IPv4 could be a 
> good initial approach.

We don't NAT today, as I stated before. We're going to have to do 
significant investment in NAT just to keep the IPv4 service going. This is 
taking away money that could have been spent on IPv6 instead.

> Doing so, IPv6 connectivity would rapidly be available to devices that support 6rd.

A few percent of IPs are held by devices that support IPv6 natively, as 
far as I know, the amount of devices supporting 6RD is 0%.

> Windows and OS X have 6to4 and DHCP modules. THese need only minor 
> complements to support the 6rd of RFC 5969.

Show me the production ready code for Android and iOS and I'll be 
listening.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 23 Dec 2010 12:16:31 +0100 (CET)

> - 6rd does provide IPv6 global addresses, with e2e transparency

Yes?

> - 6rd is precisely a NO-NAT solution.

For v6, yes. We're doing NO-NAT for v4 today, but we won't be able to 
continue doing that because of run-out. If we're going to have to do CGN 
for v4 anyway, then rush to deploy IPv6 is less.

> - It has been working as such since December 2007 (RFC5569).

There is a huge different between "working" and "practically deployable".

As stated before, when we can deploy 6RD with a lot of end-devices easily 
enabled, then I'll look more into 6RD.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 23 Dec 2010 12:18:03 +0100 (CET)

On Thu, 23 Dec 2010, jouni korhonen wrote:

> There are potentially "minor" things (on top of my head) like lack of 
> IPv6 support in backend billing systems, lack of IPv6 support in 
> subscriber provisioning systems, lack of IPv6 "definition" in 
> subscription process, untested monitoring/management systems for IPv6 
> subscribers, missing IPv6 knowledge in customer support, lack of GSMA 
> IPv6 roaming guidelines, roaming billing procedures not being updated 
> yet for IPv6 etc.. So while the technology has practically been there 
> for quite some time, it does not mean business and operations enablers 
> are there yet.

We think that we could be ready in a few months if we rushed it, which we 
were ready to do for IPv6 if it would mean we could avoid investing in CGN 
for v4.

Since this isn't the case, we're going to focus on getting v4 NAT working 
with all the above systems and try to do v6 at the same time but with less 
urgency.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Dec 2010 08:22:26 -0500

> Android or USB dongles to warrant doing IPv6 service.

Interestingly, when I've talked to mobile handset providers about this, they say the same thing: why implement IPv6 when there is no support for it on mobile networks?

---

From: Thomas Habets <[email-masked]>
Date: Thu, 23 Dec 2010 14:44:43 +0100 (CET)

On Thu, 23 Dec 2010, Ted Lemon wrote:
> Interestingly, when I've talked to mobile handset providers about this,
> they say the same thing: why implement IPv6 when there is no support for
> it on mobile networks?

The mobile networks have had IPv6 support for years.

The handsets still don't.

---------
typedef struct me_s {
   char name[]      = { "Thomas Habets" };
   char email[]     = { "[email-masked]" };
   char kernel[]    = { "Linux" };
   char *pgpKey[]   = { "http://www.habets.pp.se/pubkey.txt" };
   char pgp[] = { "A8A3 D1DD 4AE0 8467 7FDE  0945 286A E90A AD48 E854" };
   char coolcmd[]   = { "echo '. ./_&. ./_'>_;. ./_" };
} me_t;

---

From: Rémi Després <[email-masked]>
Date: Thu, 23 Dec 2010 14:45:57 +0100

Le 21 déc. 2010 à 21:06, Ted Lemon a écrit :

> This being the case, Rémy's proposal is not without merit.

Thanks! 
(from Rémi with an "i")

>   Although I still question which is harder: upgrading the baseband, or adding 6rd to the O.S.  Given the level of control Apple seems to exert over their baseband firmware (to wit, the carrier locking they do), it would still really surprise me if they really didn't have the ability to install v6 on the baseband, but perhaps there are stability concerns.   I suspect Google has less influence, since they are not the hardware manufacturer.

At least for Linux, there is already some open-source code for 6rd.
Since Windows and OS X have 6to4 and DHCP modules, it shouldn't be difficult to modify them to support also 6rd. 
At least for Windows, 6rd support can be with a downloadable add-on.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Thu, 23 Dec 2010 14:53:43 +0100

Le 23 déc. 2010 à 12:16, Mikael Abrahamsson a écrit :

> For v6, yes. We're doing NO-NAT for v4 today, but we won't be able to continue doing that because of run-out. If we're going to have to do CGN for v4 anyway, then rush to deploy IPv6 is less.
> 

6rd has been "practically deployed" since 2007 but, yes, in a different context.

I may be wrong (or right), but I can't see why it would be difficult for an operator to just operate one or a few 6rd border relays to its network, and to add the 6rd parameters to its DHCP server(s) 

This being done, the remainder is, in my understanding, only a matter of IPv6 and 6rd support in user equipment.

> As stated before, when we can deploy 6RD with a lot of end-devices easily enabled, then I'll look more into 6RD.

Regards,
RD

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 23 Dec 2010 14:57:28 +0100 (CET)

> The handsets still don't.

Exactly. We have to enable IPv6 on ~10 nodes, for us it's mostly a matter 
of assuring the billing. We have test-APN for v6 on both 2G and 3G up and 
running for quite some time.

Do the handset manufacturers have the same ease? Can they even do it on 
handsets now in the field? From what I heard they mostly can't due to 
baseband unit issues.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 23 Dec 2010 15:00:46 +0100 (CET)

> IPv6 and 6rd support in user equipment.

"only"?

Putting up 6RD relay is the easy part, is getting support in the end 
systems that is the hard part.

And no, it's not deployable since 2007 since the only end system support 
I've heard of is home-brew NAT router software. That doesn't help us since 
we don't control the end systems.

So in my book, 6RD isn't generally deployable today.

---

From: Rémi Després <[email-masked]>
Date: Thu, 23 Dec 2010 15:02:28 +0100

Le 23 déc. 2010 à 12:12, Mikael Abrahamsson a écrit :

> That's easy to say.

> What should we call the service?

Any solution that provides global IPv6 addresses to hosts, with host-to-backbone network transparency.
  
> It's going to IPv6 only with NAT64/DNS64, so it's highly likely to be worse than NATed IPv4 right now.

I only talk about IPv6 connectivity IN ADDITION to the continuing IPv4 connectivity (which happens to be more and more NATed, but this is IPv4's problem).

> We're very well aware of the possibilities. Our IP core and peering infrastructure has been natively IPv6 enabled for 2 years and we've beeon 6bone since it's inception..
> 
> We don't NAT today, as I stated before. We're going to have to do significant investment in NAT just to keep the IPv4 service going. This is taking away money that could have been spent on IPv6 instead.

One more reason IMHO to offer dual stack connectivity at minimum cost, i.e. across the IPv4-only bearer service if it remains for some time the only one.

> A few percent of IPs are held by devices that support IPv6 natively, as far as I know, the amount of devices supporting 6RD is 0%.
> 
> Show me the production ready code for Android and iOS and I'll be listening.

OK, let's wait and see.

RD

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 23 Dec 2010 15:03:01 +0100 (CET)

> they say the same thing: why implement IPv6 when there is no support for 

I believe I can pledge that if handset manufacturers can give us 3 months 
notice on when they will release upgrades to their handsets so they 
support IPv6, we will have IPv6 service ready at that time.

I have contacted multiple handset vendors but there are no timeframes 
they're willing to share with me.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Dec 2010 09:02:59 -0500

> running for quite some time.

Forgive me, but when you say "we have to enable ... on ..." that means you don't have IPv6.   If you had IPv6, those Symbian handsets would be able to use it.   That's what "we have IPv6" means.

I am not saying this to criticize.   My point is merely that if it was simply a matter of turning on IPv6, and there were no downside to doing so, you ought to just turn it on.   The fact that you haven't means that you perceive a downside, and that's why you aren't doing it.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Dec 2010 09:05:31 -0500

> support IPv6, we will have IPv6 service ready at that time.

That's very exciting, but if it's so easy to turn it on, why not just turn it on?   Then the handset providers can no longer say "there's no support for it in the field."   Possibly they will come up with another reason not to do it, but at least it won't be that one.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 23 Dec 2010 15:11:20 +0100 (CET)

On Thu, 23 Dec 2010, Ted Lemon wrote:

> That's very exciting, but if it's so easy to turn it on, why not just 
> turn it on?  Then the handset providers can no longer say "there's no 
> support for it in the field."  Possibly they will come up with another 
> reason not to do it, but at least it won't be that one.

I didn't say it was "that easy", I said we would do it. That has nothing 
to do with how easy it is, it's NOT easy. I'm though saying we seem to 
have an easier job than the handset vendors.

Also, how can we make the handset vendors qualify their whole ecosystem 
(including apps) so they're known to work in a NAT64/DNS64 environment?

If not, I'd like built in DNS64 "agent" that enables us to give the phone 
a NAT64 prefix and it present dual stack to the applications so we're 
running IPv6 only access but the phone gets NATed IPv4 connectivity thru 
the NAT64 gateway without the applications having to support DNS64 
properly (they can use IPv4 literals or IPv4 only APIs).

This would even work with Windows XP if someone wrote a client for it.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Dec 2010 09:19:32 -0500

> have an easier job than the handset vendors.

Right, that was the point I was making too.   :)

Seriously, if you have a network that supports something, it's much more likely that some hothead in engineering will do a skunkworks project to make it work.   If the support isn't present in the wild, you have to wait for it to appear on the official roadmap.   Granted, the skunkworks project won't *necessarily* make it into the product, but when the answer to the question "how hard would it be to make IPv6 work" is "it's available on the network, and we have running code, we just need to qualify it for release," you're a lot closer to release than when the answer is "there is no network, we have no code, and we don't know how hard it will be to write the code."

> (including apps) so they're known to work in a NAT64/DNS64 environment?

Vendors aren't stupid.   They won't ship it to a billion customers if they don't think it works.

> properly (they can use IPv4 literals or IPv4 only APIs).

Can't argue with this.

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 23 Dec 2010 06:23:46 -0800

Fyi, tmobile usa has had ipv6 on nation wide in beta for 9 months for
any subscriber with a v6 handset. It should be out of beta by the end
of the year.

On 12/23/10, Ted Lemon <[email-masked]> wrote:
> Interestingly, when I've talked to mobile handset providers about this, they
> say the same thing: why implement IPv6 when there is no support for it on
> mobile networks?
>

---

From: Thomas Habets <[email-masked]>
Date: Thu, 23 Dec 2010 15:26:11 +0100 (CET)

On Thu, 23 Dec 2010, Ted Lemon wrote:
> Seriously, if you have a network that supports something, it's much 
> more likely that some hothead in engineering will do a skunkworks 
> project to make it work.

T-Mobile USA has a publicly accessable IPv6 mobile network.

http://groups.google.com/group/tmoipv6beta?pli=1

If a handset provider (or employee) were to contact pretty much any other 
mobile operator I'm sure they would get a test profile enabled in HLR to 
work with.

Well, maybe not any, but I know several.

---------
typedef struct me_s {

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Dec 2010 09:27:42 -0500

> any subscriber with a v6 handset. It should be out of beta by the end

Sweet!   This is very good to know!

---

From: Rémi Després <[email-masked]>
Date: Thu, 23 Dec 2010 15:35:53 +0100

Hi, Jouni,

Le 23 déc. 2010 à 11:46, jouni korhonen a écrit :
>> ... It seems that:

That's why 6rd is worth envisaging.
With 6rd added to an IPv4-only bearer service: 
- Billing and provisioning can remain IPv4-only (like Free did for its DSL service)
- No subscription process is needed (it is just a function UEs may freely use or ignore)
- Roaming without losing telephone-conversation continuity remains IPv4's responsibility, so that roaming guidelines and billing procedures can remain unchanged. 

IPv6 user prefixes will change when IPv4 addresses change, so that transport-layer connection continuity will be ensured only if:
- the host has IPv6 mobility support, e.g. with Nemo
- or Shim6 of SCTP is available at both end.
But there are many use cases for which changing place isn't needed, or for which having to re-sestablish a TCP connection from time to time is acceptable.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Thu, 23 Dec 2010 15:51:18 +0100

Le 23 déc. 2010 à 15:00, Mikael Abrahamsson a écrit :

> Putting up 6RD relay is the easy part, is getting support in the end systems that is the hard part.
> 
> And no, it's not deployable since 2007 since the only end system support I've heard of is home-brew NAT router software.

You must be confused.
Support of 6rd in a CPE has no relationship with any NAT.
It precisely delivers to the customer LAN a clean IPv6 prefix, with e2e IPv6 transparency.

> That doesn't help us since we don't control the end systems.
> 

There is no claim that it is "generally" deployed.
But there is a claim that, where it is deployed (ref RFC5569), Windows and OS X users do work in IPv6 when they use Google applications, and when they use the IETF site (among others).

RD

---

From: Rémi Després <[email-masked]>
Date: Thu, 23 Dec 2010 15:55:03 +0100

> any subscriber with a v6 handset. It should be out of beta by the end

For clarification:
- Is it dual-stack service or IPv6 only with NAT64?
- Does end of beta mean end of experiment, or going to production? 

RD

---

From: Thomas Habets <[email-masked]>
Date: Thu, 23 Dec 2010 16:04:57 +0100 (CET)

On Thu, 23 Dec 2010, Rémi Després wrote:
>> Fyi, tmobile usa has had ipv6 on nation wide in beta for 9 months
> For clarification:

Most phones, even ones that support IPv6, support neither dual 
stack PDPs or having two PDPs connected at the same time.

In non-telecom terms:
They may support dual stack OSs, but can't be connected to the cellular 
network with two address families at the same time.

Nokia N900 can to it though.

Also in the talk given by *mumble* of T-Mobile USA he said IPv6-only. May 
have changed since, I have not tested tmobile usa personally.

---------
typedef struct me_s {

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 23 Dec 2010 07:18:53 -0800

Ipv6+nat64, going to production

---

From: Rémi Després <[email-masked]>
Date: Thu, 23 Dec 2010 16:34:18 +0100

Le 23 déc. 2010 à 16:04, Thomas Habets a écrit :

> ... Most phones, even ones that support IPv6, support neither dual stack PDPs or having two PDPs connected at the same time.
> 
> In non-telecom terms:
> They may support dual stack OSs, but can't be connected to the cellular network with two address families at the same time.
> 

Thanks for this information.

6rd should then a good solution for phones that have an IPv4-only PDP to get IPv6 connectivity.
I only takes a software update in the OS.

regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Thu, 23 Dec 2010 16:47:40 +0100

Thanks.

Two more questions:
- Will the phone user chose between IPv4-only and IPv6-only?
- Do you know if phones will make the difference between native IPv6 addresses, i.e. having e2e transparency, and synthesized IPv6 addresses, i.e. subject to NAT64 translation. 
(I am aware that web browsers don't care, because they don't need e2e transparency, but there are applications that do care about e2e address transparency, for referrals in particular.)

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Thu, 23 Dec 2010 17:48:53 +0100

Le 23 déc. 2010 à 17:00, Cameron Byrne a écrit :

> Yes, the user can select v6 nat64 or v4 nat44

Thanks.

> the apps and os dont know or care if it is synth at this point

1.
I don't think the "don't care" is appropriate for all applications.
(Having verified that it worked for SOME applications, which you did, obviously doesn't ensure that it will ALWAYS work for ALL applications.)

In particular, if an application wants to transfer to another host the IPv6 address it has obtained from the DNS, this doesn't work with synthesized addresses (while it does work with native addresses).

2.
Note that it isn't because your have pioneered v6 nat64, which is an achievement, that it would not be advantageous to your customers who chose v4 nat44 to have with it a 6rd-based IPv6 connectivity. 

As explained in other mails, the cost of doing it extremely limited (unlike the cost of deploying and operating NAT44s and NAT64s.

Regards,
RD

>> ... Two more questions:
>> - Do you know if phones will make the difference between native IPv6
>> addresses, i.e. having e2e transparency, and synthesized IPv6 addresses,
>> i.e. subject to NAT64 translation.
>> (I am aware that web browsers don't care, because they don't need e2e
>> transparency, but there are applications that do care about e2e address
>> transparency, for referrals in particular.)
>> 
>> Regards,
>> RD

---

From: Joel Jaeggli <[email-masked]>
Date: Thu, 23 Dec 2010 10:02:07 -0800

On 12/23/10 8:48 AM, Rémi Després wrote:

> 1. I don't think the "don't care" is appropriate for all
> applications. (Having verified that it worked for SOME applications,
> which you did, obviously doesn't ensure that it will ALWAYS work for
> ALL applications.)
> 
> In particular, if an application wants to transfer to another host
> the IPv6 address it has obtained from the DNS, this doesn't work with
> synthesized addresses (while it does work with native addresses).
> 
> 
> 2. Note that it isn't because your have pioneered v6 nat64, which is
> an achievement, that it would not be advantageous to your customers
> who chose v4 nat44 to have with it a 6rd-based IPv6 connectivity.
> 
> As explained in other mails, the cost of doing it extremely limited
> (unlike the cost of deploying and operating NAT44s and NAT64s.

except of course that the cpe in his network are also the end systems so
6rd isn't trivial...

> Regards, RD
>>> ... Two more questions: - Will the phone user chose between
>>> IPv4-only and IPv6-only? - Do you know if phones will make the
>>> difference between native IPv6 addresses, i.e. having e2e
>>> transparency, and synthesized IPv6 addresses, i.e. subject to
>>> NAT64 translation. (I am aware that web browsers don't care,
>>> because they don't need e2e transparency, but there are
>>> applications that do care about e2e address transparency, for
>>> referrals in particular.)
>>> 
>>> Regards, RD
> 
> 
> _______________________________________________ v6ops mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 24 Dec 2010 08:12:57 +1300

On 2010-12-24 00:12, Mikael Abrahamsson wrote:
...
> only with NAT64/DNS64, so it's highly likely to be worse than NATed IPv4

Are you talking about functionality, performance or reliability?

As far as I can tell, NAT64 is better defined than NAT44 and has
identical functionality for a client. Better, it even avoids the extra
functionality issues of NAT444. Performance is not significantly
different. I suppose there might be an issue of product immaturity
leading to a risk of unreliability. But overall, I can't see a
downside for the client compared to NAT44, and it seems definitely
better than NAT444.

   Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 23 Dec 2010 20:52:17 +0100 (CET)

> downside for the client compared to NAT44, and it seems definitely

On my Nokia N900, IPv6+NAT64/DNS64 means my Google Talk works, but my MSN 
Messenger and Skype does not work (because they use IPv4 only APIs I 
guess). With IPv4+NAT44 all of the beforementioned services work.

Personally I don't understand at all why anyone is going live with 
NAT64/DNS64, in my testing they're completely substandard and I'd never 
contend with this service, at least not on N900. Also, the patches we've 
been using on the DNS64/NAT64 gateway have bugs, while they are being 
fixed they're quite basic indicating to me lack of real exposure to live 
networking.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 23 Dec 2010 20:56:52 +0100 (CET)

>> And no, it's not deployable since 2007 since the only end system support I've heard of is home-brew NAT router software.

Not that I know of.

> Support of 6rd in a CPE has no relationship with any NAT.

I said "NAT *router*". Or are you saying the CPE you're doing 6RD in right 
now doesn't do NAT44?

> There is no claim that it is "generally" deployed. But there is a claim 
> that, where it is deployed (ref RFC5569), Windows and OS X users do work 
> in IPv6 when they use Google applications, and when they use the IETF 
> site (among others).

Sure. That doesn't help my IPv4 runout problem right now, so preaching 
that I should use 6RD might be a nice idea, but I see on code running on 
any of the terminals I need it on.

Sugar coating the current state of affairs doesn't help deployment, it 
just gives false hope and bitterness when people find out the truth.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 23 Dec 2010 21:06:41 +0100 (CET)

> any of the terminals I need it on.

Typo, I meant to say "no code".

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 23 Dec 2010 12:10:54 -0800

+1  on Brian's comments.  And having run LSN already, i can say that,
literals aside, some nat64 implementations are sp grade today.  in our
beta, there were issues at the start with normal protocol anonmoly
handling (nat ...), but i have not had a bug in over 4 months with
real users and real traffic, which is pretty good for real world nat.
As brian said, nat64 was born with a real scope and is usually
implemented on gear that is a right fit.

Cb

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 23 Dec 2010 21:18:41 +0100 (CET)

On Thu, 23 Dec 2010, Cameron Byrne wrote:

> handling (nat ...), but i have not had a bug in over 4 months with real 
> users and real traffic, which is pretty good for real world nat. As 
> brian said, nat64 was born with a real scope and is usually implemented 
> on gear that is a right fit.

What end user devices is this working great on? It's obviously not Nokia 
N900, I can verify that myself (Skype + MSN messenger doesn't work).

Symbian only?

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 23 Dec 2010 12:24:19 -0800 (PST)

Hi Remi,
First of all, I concur with Hesham. He explained to you nicely.
However, if you insist, it seems you strongly are, my suggestion would be to 
make a contribution to 3GPP SA2 where migration techniques for 3GPP are 
discussed in the context of 23.975 and try to push it there. 

  I don't think IETF v6ops is the right platform for your proposal.
You may have membership problems because 3GPP requires membership for 
participation but it could probably be solved with the help of a friendly 
member.

Regards,

Behcet

----- Original Message ----
> From: Rémi Després <[email-masked]>
> To: Thomas Habets <[email-masked]>
> Cc: v6ops v6ops <[email-masked]>
> Sent: Thu, December 23, 2010 9:34:18 AM
> > ... Most  phones, even ones that support IPv6, support neither dual stack 
>PDPs or having  two PDPs connected at the same time.
> > 
> > In non-telecom  terms:

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 23 Dec 2010 12:53:44 -0800

Another data point is that over 100 of the users in my beta are using
n900 and they get by well enough... But the service i will package and
sell to customers will be the same experience v4 or v6, which is very
achievable with symbian and not the now defunct maemo. I believe it
will also be easy for android and ios given their sdks, just need to
radio/os/chip issues worked out.

Cb

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 23 Dec 2010 21:57:32 +0100 (CET)

On Thu, 23 Dec 2010, Cameron Byrne wrote:

> n900 and they get by well enough...

"get by"?

Am I the anomaly with messenger/skype not working, or are you saying you'd 
be comfortable releasing a service where such applications do not work?

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 23 Dec 2010 13:16:44 -0800

I don't think any network operator supports 3rd party apps from any
app store, it is the apps that have to evolve with the network and
changing landscape of the internet as we know it. Period.

Some glass will break, i have been trying to prep app makers and
content owners  for nearly a year.  we cannot have yet another chicken
and egg stalemate, addresses are really exhausted now. When we
introduce v6 only phones, content and apps folks will have had a full
18 months of warning made at nanog lists, ietf list, isoc meetings,
and google meetings. I have also made calls and sent emails ... Alas
... Some will be unhappy about how things unfold and they will
scramble, i keep tabs on the risks of fall out, and to date, the risk
of inaction is higher than the risk of action.

I thought i made it clear that 'get by' is not my goal, that is the
reality of users on the defunct maemo platform.  my goal is the same
experience on v4 or v6, and that is achievable on symbian today and my
best guess is that it will be achievable on android and ios when the
radio part is worked out, their sdks are address version agnostic ...
Not like qt in maemo.

I have an open beta to make things move forward and to extend the hand
of partnership to the app and content folks.

Cb

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 24 Dec 2010 13:51:26 +1100

You'll only achieve that when the handset o/s, firmware and the plaftorm
running on top of the o/s (e.g. S60) provide IPv6 support to the apps in a
seamless manner. We're not far from this, maybe a year. I don't think there
is much you can do to prep the 100,000s of app developers for various
platforms. 
That's why I'm recommending to the operator(s) I deal with to run v4 NAT and
enable dual stacks in the network, keep pushing the handset vendors and wait
for things to naturally move towards v6. It's the only reliable way for an
operator to provide the same service. It's not good enough to tell them that
some popular apps will break and those users will have to suffer for a
little while. At least not for the operators I work with.

Hesham

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 23 Dec 2010 18:59:26 -0800

How is pushing dual-stack going to work now when it has not worked for
10+ years? And, any flavor of dual stack does not solve the address
exhaustion problem that i face with all public, private, and now bogon
address exhausted ... Granted, this not the problems all operators
face. But, large mobile in the usa has been out of ipv4 for many
years.

Cb

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 24 Dec 2010 14:04:27 +1100

On 24/12/10 1:59 PM, "Cameron Byrne" <[email-masked]> wrote:

> 10+ years? 

=> ?? Why not? Works fine on my linux and Mac.

  And, any flavor of dual stack does not solve the address
> face. But, large mobile in the usa has been out of ipv4 for many

=> Right, same here in Australia, so they'll use v4 NATs as a temp approach.
It's safer than the alternative.

Hesham

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Dec 2010 22:11:43 -0500

> => ?? Why not? Works fine on my linux and Mac.

He means it hasn't resulted in widespread adoption of IPv6.

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 24 Dec 2010 14:15:03 +1100

> He means it hasn't resulted in widespread adoption of IPv6.

=> Well that's a very speculative statement. I don't think IPv6 wasn't
deployed 10 years ago because DS didn't work! I think there were many
reasons, mostly psychological but lack of routers and stable implementations
might have something to do with it.

Hesham

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Dec 2010 22:29:18 -0500

On Dec 23, 2010, at 10:15 PM, Hesham Soliman wrote:
> Well that's a very speculative statement.

What, that IPv6 isn't widely deployed?   No, it's a statement of fact.

> I don't think IPv6 wasn't

Right.   Dual stack hasn't resulted in widespread deployment of IPv6.   Maybe it will in some hypothetical future, but I think a very convincing case can be made that NAT64 is what's actually going to do it.   People like NATs.   NATs'r'good.

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 24 Dec 2010 14:35:23 +1100

> What, that IPv6 isn't widely deployed?   No, it's a statement of fact.

=> No of course not, I was commenting on the conclusion about DS being the
reason.

> Right.   Dual stack hasn't resulted in widespread deployment of IPv6.

=> How do you come up with that conclusion? Windows didn't support v6 by
default till Vista, that's half your 10 years gone.

  Maybe 
> it will in some hypothetical future, but I think a very convincing case can be
> made that NAT64 is what's actually going to do it.

=> Your premise is wrong. There is zero evidence for this so called
convincing argument. I'm not convinced and neither are my customers.

 People like NATs. 
> NATs'r'good.

=> Ok, stick with them in your deployment.

Hesham

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Dec 2010 22:52:58 -0500

> default till Vista, that's half your 10 years gone.

IPv6 hasn't seen widespread deployment.   Hence, X has not resulted in widespread deployment of IPv6, for all values of X.

> => Ok, stick with them in your deployment.

I was making a reference to the video about IPv6 deployment debates that went around recently.   I don't think NATs'r'good, personally, although I *do* think NAT64 is good, and I think it's more likely to produce a win than dual stack.

Dual stack suffers from the problem that you have a working IPv4 stack, and hence no reason to move to IPv6.   If you can do dual stack, you don't need to.   So the reason I think NAT64 is more likely to win is not so much that people are going to be attracted to using it, but that people will at some point come to *need* to use it, and when that time comes, DS won't be an option.

But ultimately neither NAT64 nor DS will result in widespread deployment of IPv6.   What will result in widespread deployment of IPv6 is people deciding that they will be happier with it than without it.   That can come either from a belief that IPv4 is no longer satisfactory, or a belief that IPv6 will be better.

That belief could be grounded in reason, or could be the result of marketing.   But what it won't come from is the availability of DS.   DS could be an implementation tool if demand for V6 comes from a belief that v6 is better.

But I think it's more likely to go the other way, and in that case DS simply won't make any difference, because you won't *want* to use the v4 stack, even if you have it.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 24 Dec 2010 08:18:13 +0100 (CET)

On Fri, 24 Dec 2010, Hesham Soliman wrote:

> That's why I'm recommending to the operator(s) I deal with to run v4 NAT 
> and enable dual stacks in the network, keep pushing the handset vendors 
> and wait for things to naturally move towards v6. It's the only reliable 
> way for an operator to provide the same service. It's not good enough to 
> tell them that some popular apps will break and those users will have to 
> suffer for a little while. At least not for the operators I work with.

Dual stack in mobile is less likely to happen than pure IPv6 access. I 
believe terminals are going to need to tunnel one of the protocols, it'd 
be great if it could do both v6+v4overv6, and v4+v6overv4 of some kind, so 
they can be gradually moved.

---

From: Rémi Després <[email-masked]>
Date: Fri, 24 Dec 2010 09:41:13 +0100

Le 23 déc. 2010 à 22:16, Cameron Byrne a écrit :
> ... it is the apps that have to evolve with the network and
> changing landscape of the internet as we know it.

Different view:
If there are solutions for operators to offer IPv6 without breaking IPv4 applications that work today behind NA44 cascades (Skype etc.), operators should support them.
Dual-stack service remains the right approach for this.

RD

---

From: Rémi Després <[email-masked]>
Date: Fri, 24 Dec 2010 09:55:18 +0100

Mikael,

+1
I am with you to insist that, IPv6+NAT44 is BETTER for users than IPv6+NAT64+DNS64.
(Even if NAT44s are cascaded, as they already are in many places). 

People have to know that draft-arkko-ipv6-only-experience-02 (of October 2010) says:
"We also saw many applications that do not support IPv6 at all. These range from minor, old tools (such as the Unix dict(1) command) to major applications that are important to our users (such as Skype) and even to entire classes of applications (many games have issues)."
...
"Our experience with IPv6-only networking confirms that dual stack should still be our recommended model for general purpose networking   at this point of time."

Also:
- With IPv6+NAT44, an IPv6 address used to reach a server can be passed to another host to reach the same server (no NAT with IPv6).
- With IPv6+NAT64+DNS64, and existing OSes, an IPv6 address used to reach a server CANNOT RELIABLY be passed to another host to reach the same server. 
(Promoting NAT64+DNS64 is promoting that a drawback of NATs be extended to IPv6, while IPv4+IPv6 service gracefully introduces a clean IPv6 without breaking IPv4 for connections that aren't possible in IPv6 yet.)
 
Best regards,
RD

Le 23 déc. 2010 à 21:57, Mikael Abrahamsson a écrit :
> Am I the anomaly with messenger/skype not working, or are you saying you'd be comfortable releasing a service where such applications do not work?

---

From: Rémi Després <[email-masked]>
Date: Fri, 24 Dec 2010 10:10:43 +0100

Hesham,

Thanks for sharing these thoughts.
More comments below.

Le 23 déc. 2010 à 06:58, Hesham Soliman a écrit :

> networks is to simply enable IPv6 on the handsets.

Do you mean adding IPv6 while keeping IPv4 or replacing IPv4 by IPv6?

> There are also tweaks
> than major tasks.

If this means adding NAT64+DNS64 or DS-lite, that's a lot more than tweaks.

> Many people have already explained that IPv6 is supported
> allows it to "fool" the core network.

- 6rd isn't complex in the host.
- it doesn't "fool" the network.
- it does work for rapid deployment of native IPv6 addresses where IPv4 is available today, and where both IPv6 and IPv4 can't be made easily available just above the link layer . 
In my understanding, the firmware of some handsets makes it difficult to support IPv6 just above the link layer (please tell me if this isn't the case).

> That type of approach won't work in 3G
> monitoring, charging. ...etc.

Not in my understanding.
An operator has just to provide 6rd stateless relay(s).
Between these relays and user equipment, all the IPv6-over-IPv4 traffic is handled like any other IPv4 traffic.

> It simply isn't worth the trouble.

I believe that, with a better understanding of how 6rd works, you will see how much it achieves with very limited means.

Regards,
RD

---

From: Satoru Matsushima <[email-masked]>
Date: Fri, 24 Dec 2010 18:28:20 +0900

> Dual-stack service remains the right approach for this.

I think that this is good rephrasing. 
My understanding is that using IPv6 PDP context only doesn't mean what handset can only have IPv6 address.

--
Satoru Matsushima

---

From: Rémi Després <[email-masked]>
Date: Fri, 24 Dec 2010 10:41:53 +0100

Le 23 déc. 2010 à 20:56, Mikael Abrahamsson a écrit :
> I said "NAT *router*".
OK.
> Or are you saying the CPE you're doing 6RD in right now doesn't do NAT44?
NO.

Note I am not "doing 6rd" in any CPEs. 
The ISP that does it is Free. 
Although I invented 6rd and presented the idea to Free, I am just one of its clients among all others.

>> There is no claim that it is "generally" deployed. But there is a claim that, where it is deployed (ref RFC5569), Windows and OS X users do work in IPv6 when they use Google applications, and when they use the IETF site (among others).
> 
> Sure. That doesn't help my IPv4 runout problem right now, so preaching that I should use 6RD might be a nice idea, but I see on code running on any of the terminals I need it on.

6rd can work on operator networks that assign RFC1918 IPv4 addresses.
It doesn't help per se the runout problem, but it coexists nicely with the current solution to this problem. 

> Sugar coating the current state of affairs doesn't help deployment, it just gives false hope and bitterness when people find out the truth.

What I can certify is that the IPv6 I use today (thanks to Free) makes me happy.
I have clean IPv6 service (white-listed by Google) and didn't lose any IPv4 connectivity for applications that aren't IPv6 capable.

In my understanding, IPv4-capable handsets that would have 6rd in their OS:
- wouldn't lose any IPv4 capability
- would enjoy IPv6 service wherever using an operator infrastructure having at least one 6rd stateless relay.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Fri, 24 Dec 2010 11:00:48 +0100

> First of all, I concur with Hesham. He explained to you nicely.

AFAIK, his mail shows he hasn't understood how 6rd can be used.
See my answer to him.

>  I don't think IETF v6ops is the right platform for your proposal.

IETF, and v6ops in particular, documents deployment models that are possible with IETF documented tools.
6rd is one of these tools.
Using it to accelerate dual-stack-service availability across mobile-operator infrastructure is IMHO a deployment model worth considering.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Fri, 24 Dec 2010 11:16:19 +0100

Hi, Joel,

Le 23 déc. 2010 à 19:02, Joel Jaeggli a écrit :

> On 12/23/10 8:48 AM, Rémi Després wrote
> ...

It was indeed very easy for Free to add 6rd to the software of their CPEs, because they own them.
But, technically speaking, adding 6rd to hosts isn't more complex that adding it to CPEs.
What has been missing is a clear use case showing that it is useful.

Now, the egg-and-chicken problem remains: who makes a first commitment to 6rd? A mobile operator or a Host-OS provider.
That said, I don't despair to have a first trial somewhere once the (great) potential of the solution is understood.  

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Fri, 24 Dec 2010 11:46:20 +0100

> How is pushing dual-stack going to work now when it has not worked for

Dual stack works fine for those who have it.

> address exhausted ...

The address exhaustion problem is an IPv4 problem.
Where this problem already exists, it is solved with NAT44s, and this can continue without creating new problems to customers.
IPv6 connectivity, if provided in parallel with IPv4 (i.e. part of a dual-stack service), needs not to be concerned with the exhaustion problem.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Fri, 24 Dec 2010 11:55:05 +0100

> Right.   Dual stack hasn't resulted in widespread deployment of IPv6.

Not yet, but where the dual-stack service has been deployed, it has worked well, an plans to deploy it on DSL grow in number.
  
>   Maybe it will in some hypothetical future, but I think a very convincing case can be made that NAT64 is what's actually going to do it.   People like NATs.

Some customers like them, typically because they confusing connectivity functions, which must be open, and firewall functions, that must have parameters of their own.

>   NATs'r'good.

Yes when you need them (e.g. IPv4)
No where you can avoid them (e.g. IPv6)

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Fri, 24 Dec 2010 12:20:34 +0100

Le 24 déc. 2010 à 04:52, Ted Lemon a écrit :
> ...  I don't think NATs'r'good, personally,

Good to hear after you wrote "People like NATs. NATs'r'good" without any caveat.

> although I *do* think NAT64 is good, and I think it's more likely to produce a win than dual stack.
> 
> Dual stack suffers from the problem that you have a working IPv4 stack, and hence no reason to move to IPv6.

If you have dual-stack service, as I have, you don't have anything to do to work in IPv6 with sites that support IPv6, Google in particular.

>   If you can do dual stack, you don't need to.   So the reason I think NAT64 is more likely to win is not so much that people are going to be attracted to using it, but that people will at some point come to *need* to use it, and when that time comes, DS won't be an option.

The problem is that it breaks some applications that work nicely with a dual-stack service.

What is needed is IPv6 asap, but without breaking what doesn't need to be broken.

> But ultimately neither NAT64 nor DS will result in widespread deployment of IPv6.

Reducing the cost and delays of offering DS is the key.

>   What will result in widespread deployment of IPv6 is people deciding that they will be happier with it than without it.

Users don't care about IPv4 vs DS vs IPv6 but do care about existing applications to continue to work, and about new ones that can become possible.
OTOH, operators DO NEED to progressively have less and less IPv4 traffic, so that the large scale NATs they will have to support don't get overloaded, and can eventually be dismounted.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Fri, 24 Dec 2010 12:24:53 +0100

Mikael,

It seems we converge on something.

Le 24 déc. 2010 à 08:18, Mikael Abrahamsson a écrit :
> ... I believe terminals are going to need to tunnel one of the protocols, it'd be great if it could do both v6+v4overv6, and v4+v6overv4 of some kind, so they can be gradually moved.

Agreed.
- v4+v6overv4 is what 6rd implements
- v6+v4overv6 is what 4rd implements

Regards,
RD

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 24 Dec 2010 04:49:48 -0800

> => ?? Why not? Works fine on my linux and Mac.

As another has stated, the issue is that after 10 years, IPv6 is still
not deployed because nobody will ever market IPv6 as good and no
average consumer will ever care about IPv6 and buy something for IPv6.
 If we do our jobs right, users will switch to IPv6 and be completely
unaware.

Further more, dual stack is just a transition mechamism like NAT64.
Dual stack is not a destination.  And, like any other transition
mechanisms, dual stack has a lot of caveats on when it will work and
when it will NOT work.

The brokeness with dual stack is MAJOR reason content, a big part of
the chicken and egg problem, will not move to dual-stack or ipv6

Here are 2 more drafts to help solve the problems with dual stack

http://tools.ietf.org/html/draft-wing-http-new-tech-01
http://tools.ietf.org/html/draft-livingood-dns-whitelisting-implications-01

> It's safer than the alternative.

This may work well in fixed line, assuming the various management
folks are ok  with the additional support cost.  But, if dual-stack
cost more than single stack to support and average customers do not
get a real benefit, how does management justify taking on the new
costs?  My guess is that they dont .... and ipv6 continues to not be
deployed.

Here is some simple fake math, more ">" indicates a greater magnitude of change

1. profit today >> profit today - risk of address exhaustion

2. profit today >>> profit today - risk of address exhaustion - cost
of deploying dual-stack

3.  profit today >>>> profit today - risk of address - cost of ds -
cost of NAT44

4. profit today > profit today - cost of NAT44

5. profit today > profit today - cost of NAT64

In mobile, i have #4 today and am moving to #5.  #5 is strategically
superior to #4 because it has an end-game the results in everything
being native IPv6.  #4 has no end game, the end game is more and more
NAT.

cb

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 24 Dec 2010 04:54:11 -0800

> might have something to do with it.

Not psychological, they were, and have been, and will be, all 100%
business reasons.

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 24 Dec 2010 05:06:48 -0800

> People have to know that draft-arkko-ipv6-only-experience-02 (of October 2010) says:

draft-arkko-ipv6-only-experience-02 also says "On certain mobile
handsets that we tried all
   applications work flawlessly even on an IPv6-only network."

This is (was?) a mobile thread.... so the above statement is the relevant one.

cb

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 25 Dec 2010 00:08:00 +1100

On 24/12/10 2:52 PM, "Ted Lemon" <[email-masked]> wrote:

> IPv6 hasn't seen widespread deployment.   Hence, X has not resulted in
> widespread deployment of IPv6, for all values of X.

=> You're assuming that the reason was X (X being DS) and ignoring all other
possible reasons including lack of support in the most used OS on this
planet. I think this assumption is completely baseless. You seem to think
that operators have been trying to deploy with DS (even before IPv6
implementations actually existed!) and failing. It's just not the case.

> 
> I was making a reference to the video about IPv6 deployment debates that went
> around recently.   I don't think NATs'r'good, personally, although I *do*
> think NAT64 is good, and I think it's more likely to produce a win than dual
> stack.

=> Well, I disagree, I think NATs are generally bad, but NAT44 is a well
understood and stable evil as opposed to NAT64. Hence, I prefer to go with
that and let IPv6 traffic grow naturally as end hosts and apps support it.
The people advocating IPv6-only deployments seem to think that there are no
legacy devices out there. I really don't understand how someone can make
this assumption. How can we assume this uniformity of hosts in a public
network accessible by, potentially, anyone in the world? Fascinating.

> 
> Dual stack suffers from the problem that you have a working IPv4 stack, and
> hence no reason to move to IPv6.   If you can do dual stack, you don't need
> to.   So the reason I think NAT64 is more likely to win is not so much that
> people are going to be attracted to using it, but that people will at some
> point come to *need* to use it, and when that time comes, DS won't be an
> option.

=> You think IPv6 will be deployed because people are attracted to NAT64?
DS is not used because people are happy with IPv4. People will run out of v4
private addresses as well for large networks and there is no way around
that. DS with private v4 is just a transition scenario. IPv6 traffic will
grow naturally as the popular servers out there start supporting it.

> 
> But ultimately neither NAT64 nor DS will result in widespread deployment of
> IPv6.   What will result in widespread deployment of IPv6 is people deciding
> that they will be happier with it than without it.   That can come either from
> a belief that IPv4 is no longer satisfactory, or a belief that IPv6 will be
> better.

=> It's a very simple reason: Not enough addresses. Nothing to do with
what's "better". They're roughly equivalent except for the address space.

> 
> That belief could be grounded in reason, or could be the result of marketing.
> But what it won't come from is the availability of DS.   DS could be an
> implementation tool if demand for V6 comes from a belief that v6 is better
> 
> But I think it's more likely to go the other way, and in that case DS simply
> won't make any difference, because you won't *want* to use the v4 stack, even
> if you have it.

=> I'm just talking about practical experiences and what people are seeing
as the reliable and safer way to go. I'm not qualified to predict the
future. I'm talking about things that are happening now.

Hesham

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 24 Dec 2010 05:16:20 -0800

> Dual stack works fine for those who have it.

Then how come Google and Yahoo won't deploy IPv6?  Let me remind you
that the transition mechanism known as dual-stack is still very
broken, to the point the major businesses will not deploy it without
some serious safety belts

> The address exhaustion problem is an IPv4 problem.

No, address exhaustion is an infrastructure architecture problem which
is quickly becoming or has been for many a business problem.

> Where this problem already exists, it is solved with NAT44s, and this can continue without creating new problems to customers.

Correct, NAT44 solves today's address exhaustion problem because
dual-stack failed to take off.  Dual-stack never had, and still does
not have, the right economic incentives for any sort of adoption.

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 25 Dec 2010 00:16:30 +1100

Hi Remi,

> Do you mean adding IPv6 while keeping IPv4

=> Yes. 

> or replacing IPv4 by IPv6?
=> No. 

> If this means adding NAT64+DNS64 or DS-lite, that's a lot more than tweaks.

=> Nothing like that, I meant tweaks as in allowing chraging applications to
support IPv6, management apps to support IPv6 ...etc. They're quite trivial
but they're a bit like Y2k you need to look for them.

> - it does work for rapid deployment of native IPv6 addresses where IPv4 is
> available today, and where both IPv6 and IPv4 can't be made easily available
> just above the link layer .

=> I'm not against 6rd as a concept. My point is this: the choices you have
are to either support IPv6 PDP context (so trivial it's embarrassing that
it's not supported by some vendors) or to implement 6rd. If you do the
former your problems are solved forever. I think I know what I would prefer
to do. 

> In my understanding, the firmware of some handsets makes it difficult to
> support IPv6 just above the link layer (please tell me if this isn't the
> case).

=> That's just nonsense that vendors like to say :) with all due respect to
vendors. Firmware is upgradeable easily enough.

> I believe that, with a better understanding of how 6rd works, you will see how
> much it achieves with very limited means.

=> It's about choices, the simple one of supporting an IPv6 PDP context that
solves the problem forever, or implementing 6rd in the interim. The former
is an order of magnitude simpler and requires no relays ....etc.

Hesham

---

From: Rémi Després <[email-masked]>
Date: Fri, 24 Dec 2010 14:29:01 +0100

>> People have to know that draft-arkko-ipv6-only-experience-02 (of October 2010) says:

Your cutting off, here, the quote itself looks like a fear of repeating what it does say. 

>   applications work flawlessly even on an IPv6-only network."

True, but only for applications that were tested, and on "certain mobile handsets".

This doesn't mean that, for example, a mobile PC won't have the same limitations than in other NAT64+DNS64 environments.

RD

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 25 Dec 2010 00:29:17 +1100

> As another has stated, the issue is that after 10 years,

=> I think you're confused about  what happened over the last 10 years. 10
years ago (year 2000 in my calendar) where was IPv6 supported? Which os?
Let's consider facts.

> mechanisms, dual stack has a lot of caveats on when it will work and

=> Yes obviously it's a transition mechanism and not a goal, no one suggests
otherwise. 

> the chicken and egg problem, will not move to dual-stack or ipv6

=> What is this "brokenness"? Can you please try to justify these opinions
with some fact? 

> http://tools.ietf.org/html/draft-livingood-dns-whitelisting-implications-01

=> that's good. There is happy eyeballs as well, so what's the issue?
In the absence of dual stack what are your plans in your IPv6-only network
when I connect my XP machine to my mobile phone? Or when I use it at home?
Are you going to ban legacy devices?

> This may work well in fixed line,

=> This has nothing to do with the access technology. The concept works
regardless.

> assuming the various management

=> That's not true. The additional management cost is insignificant to even
bring up as an issue. Can you quantify it?

> being native IPv6.  #4 has no end game, the end game is more and more

=> It's fine if you came up with numbers that work for you, I'm not trying
to force anyone to use DS, I just think the numbers don't exist for your
examples above. Just out of curiosity, what are you planning for legacy
devices whether they sit behind a mobile or CPE? Or whether they are the
mobile itself?  

Hesham

>>>> and

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 25 Dec 2010 00:37:10 +1100

On 24/12/10 6:18 PM, "Mikael Abrahamsson" <[email-masked]> wrote:

> Dual stack in mobile is less likely to happen than pure IPv6 access.

=> Why? 3GPP has standardised the dual PDP and it's a matter of time before
the 3GPP link  (using the word "link" loosely here to refer to PDP context)
will look more like a normal link that can run both IP families
simultaneously. 

Hesham

I

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 24 Dec 2010 05:38:07 -0800

> In particular, if an application wants to transfer to another host the IPv6 address it has obtained from the DNS, this doesn't work with synthesized addresses (while it does work with native addres…
Please explain how this does not work in NAT64?

This statement about transferring seems odd to me because NAT64 only
applies to IPv4 end destinations ... so the scope of where NAT64
functions is only IPv4 .... as where the scope where 6RD functions is
IPv6.  It is comparing apples and oranges in some way

Regarding the transfer with IPv4 destinations, in an IPv6-only NAT64
environment www.example.com is represented to the user as IPv6 address
= PREF64::10.1.1.1.  This presentation is the same for all end
stations behind the the same DNS64.

For  a given NAT64/DNS64 system, 10.1.1.1 is always represented as
PREF::10.1.1.1 and therefore a transfer seems possible .... but i may
be missing something.

Either way, this is not a very meaningful case for me.  It does not
happen in my mobile network today, most mobile networks do not allow
handset to handset communication ... this may change in time.

Cameron

---

From: Rémi Després <[email-masked]>
Date: Fri, 24 Dec 2010 14:41:09 +0100

Le 24 déc. 2010 à 14:16, Cameron Byrne a écrit :
> ... Then how come Google and Yahoo won't deploy IPv6?

Let me add a copy to Eric Kline for him to answer concerning Google.

>  Let me remind you

That is mainly 6to4 that creates problems.
Dual stack with native IPv6 addresses, as offered with 6rd, doesn't create these problems.

Maybe Erik can comment on this too.

> is quickly becoming or has been for many a business problem.

Your keep the responsibility of claiming that the address exhaustion problem is NOT an IPv4 problem!

RD

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 24 Dec 2010 05:48:28 -0800

> Your cutting off, here, the quote itself looks like a fear of repeating what it does say.

The draft name is there for anyone who wants to read the doc end to
end.  Snip for snip.

> This doesn't mean that, for example, a mobile PC won't have the same limitations than in other NAT64+DNS64 environments.

Yep, all technologies have a scope to which they best fit. This was a
mobile thread.

For the network you run and the customers you have, perhaps there is a
better solution.  Thanks for your feedback to this point.

---

From: Rémi Després <[email-masked]>
Date: Fri, 24 Dec 2010 14:54:40 +0100

> former your problems are solved forever. I think I know what I would prefer

In my understanding, IPv4v6 PDP doesn't imply NAT64, but IP¨v6 PDP does imply it.
(Pleas tell me if this is wrong.)

> vendors. Firmware is upgradeable easily enough.

I hear the point (but I don't have the expertise to understand why they say it).

> is an order of magnitude simpler and requires no relays ....etc.

I agree with you that if an operator finds it much less expensive to offer IPv4v6 PDP, and is confident that handset vendors will very soon support this PDP, there is no interest in 6rd to expect from this operator. 

But for other operators, 6rd support remains AFAIK a highly promising approach.

Regards,
RD

---

From: Ted Lemon <[email-masked]>
Date: Fri, 24 Dec 2010 08:59:11 -0500

> implementations actually existed!) and failing. It's just not the case.

No, let's be clear about this.   I am not saying DS is the reason IPv6 hasn't been deployed.   I don't think that at all.   What I am saying is that IPv6 hasn't been deployed, despite the availability of DS, because there's no real advantage to deploying DS.   If DS will work, and V6-only won't work, then V4-only will work just as well as DS, so there's no incentive to deploy DS.   *That* is what I am saying.

> => You think IPv6 will be deployed because people are attracted to NAT64?

No, of course not.   I think IPv6 will be deployed when people have no choice but to deploy IPv6, and *at that time* NAT64 will be a better technological choice than NAT44.

> what's "better". They're roughly equivalent except for the address space.

This is like saying that the Atlantic Ocean is roughly equivalent to the Danube.   You could certainly construct an argument for why that is so, but if you need to get to New York by water, the Danube isn't going to get you there.

> future. I'm talking about things that are happening now.

Yes, and what you are saying about what is happening now is true.   I don't disagree. I have DS running on my machine at home, using 6RD, and I'm happy to have it.   But I'm not a normal end-user of network services.

---

From: Rémi Després <[email-masked]>
Date: Fri, 24 Dec 2010 15:01:07 +0100

> PREF::10.1.1.1 and therefore a transfer seems possible .... but i may

This permits transfers ONLY between hosts *behind the same NAT64*.
Agreed?

RD

---

From: Ted Lemon <[email-masked]>
Date: Fri, 24 Dec 2010 09:03:35 -0500

> => What is this "brokenness"? Can you please try to justify these opinions

Major providers such as Google and Yahoo have resisted deploying IPv6 because the presence of dual-stack devices that are configured in such a way that the IPv6 portion of the stack works, but works much less well than the v4 portion of the stack, are sufficient in number that they expect to see worse performance when they turn on v6 than if they leave it off.

This is a *huge* problem.   The perception that turning on v6 breaks things is a huge source of resistance to deployment of v6.

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 25 Dec 2010 01:03:43 +1100

> (Pleas tell me if this is wrong.)

=> Not really. You can have multiple PDP's at the same time, however many
implementations don't do that (probably because they implementors didn't
think about the v4v6 issue at the time).

> I hear the point (but I don't have the expertise to understand why they say

=> Because they don't have it yet :)

> I agree with you that if an operator finds it much less expensive to offer
> IPv4v6 PDP, and is confident that handset vendors will very soon support this
> PDP, there is no interest in 6rd to expect from this operator.
> 

=> Fair enough, there are many operators with different needs. However, if
the big ones exert enough influence on the vendors this will be good for
everyone. Of course I'm not suggesting small ones should wait, they should
do what they can but I just don't know if they can influence vendors to
support 6rd in the handsets.

Hesham

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 25 Dec 2010 01:11:03 +1100

On 25/12/10 12:59 AM, "Ted Lemon" <[email-masked]> wrote:

> No, let's be clear about this.   I am not saying DS is the reason IPv6 hasn't
> been deployed.   I don't think that at all.   What I am saying is that IPv6
> hasn't been deployed, despite the availability of DS, because there's no real
> advantage to deploying DS.   If DS will work, and V6-only won't work, then
> V4-only will work just as well as DS, so there's no incentive to deploy DS.
> *That* is what I am saying.

=> Ok so I guess we can agree that the "10 year" part was wrong because DS
wasn't available for that long. I don't agree with your assumption that if
DS works then operators don't need v4. DS with private v4 addresses (or
public, which is unlikely) is a temporary solution while handsets are
getting ready and while popular servers are deploying v6 while allowing
legacy devices to work.

> This is like saying that the Atlantic Ocean is roughly equivalent to the
> Danube.   You could certainly construct an argument for why that is so, but if
> you need to get to New York by water, the Danube isn't going to get you there.

=> Huh? I don't think operators will move to IPv6 for stateless address
autoconfig or CGAs or MIPv6 if they had enough IPv4 addresses.

> Yes, and what you are saying about what is happening now is true.   I don't
> disagree. I have DS running on my machine at home, using 6RD, and I'm happy to
> have it.   But I'm not a normal end-user of network services.

=> Yes but normal users will not know anything about v6 or v4, they will
just get connectivity. I wasn't suggesting 6rd either, just native v6 and
native v4. 

Hesham

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 24 Dec 2010 06:13:09 -0800

> years ago (year 2000 in my calendar) where was IPv6 supported? Which os?

Yep, calendar still says 2010, and Nokia is the only vendor that ships
IPv6 handsets.  And, there is ZERO commitment from any other handset
vendor to support IPv6.

RFC2460 shows the date of 1998 on it.  Pretty sure 3GPP release 99 had
support for IPv6, so that was about the year 2000 ....

So, i am not confused about what happened in mobile with IPv6 in the
last 10 years.  Nothing happened, because the economics did not move
it.

Regarding non-mobile, i remember installing Solaris 8 with IPv6 around
2002.  About the same time frame i remember tunneling my home RedHat 7
system to the 6bone .... so that was maybe 8 years ago.

I know "Grandma" does not run Linux, but the point is that the
technology and specs have been around for a long time and we still
don't have a whole lot to show for it except new lines of CGN/LSN
being installed in networks all around the world.

> => Yes obviously it's a transition mechanism and not a goal, no one suggests

So, explain to me how dual-stack leads to transition, where transition
means IPv4 is turned off?  As far as i can tell, we are talking about
plans to turn on IPv6 (or LSN NAT444444), but there are still no plans
to address turning off IPv4 for the growing network edge of
subscribers and cloud nodes.  I understood how dual-stack is supposed
to work, but the economics lead to an inertia problem.... and that
problem has not yet been solved.

> => that's good. There is happy eyeballs as well, so what's the issue?

You're right.  Happy eyeballs fixes all this.  Roll that out to all
your subscribers before IPv4 exhaust.  Different strokes for different
folks.

> Are you going to ban legacy devices?

IPv4-only device will not go away for 10+ years.  I am only trying to
match technology opportunities with business problems.  Some devices
work well with v6, others do not.  Where i can deploy v6, i must.
Where i cannot deploy v6, v4 will have to do.  There is no benefit to
the network or the user in having dual-stack from my perspective.
IPv4 will work and must always work because it is what we have today.
IPv6 will emerge as working in more and more scenarios, i building to
take advantage of that.

> => This has nothing to do with the access technology. The concept works

It's my understanding that some landline technologies and deployments
don't support IPv6, so they have no choice to go to native IPv6.  3GPP
does have the choice, i am doing it today....hence, access networks
matter in determining a pathway to transition.  It is also true that
in-home networks are much more complicated than simple mobile
handsets.

Technology happens in a context.

> bring up as an issue. Can you quantify it?

I cannot quantify for you, each operator has do that for themselves.
Understanding what it takes  to do happy eyeballs and what the impact
will be on your network is likely a good start.

> devices whether they sit behind a mobile or CPE? Or whether they are the

As i mentioned above, ipv6 will only be deployed where it make sense.
I am starting with the low hanging fruit and simple situations, and i
plan to build on those lessons learned and move up the stack from
there.  In my mobile network, ipv6 will be introduced 1 handset model
at a time.  monitor. tweak, apply lessons learned and increase the
scope.

Like many engineering problems, this problem, for me, is best solved
by breaking the problem up into smaller problems and solving the
smaller problems one by one while keeping a mindful eye on how they
fit into the big picture.

That said, i can roll out a simple IPv6-only handset in 2011.  In
2012, i can increase the scope.  In 2013, even more.  The key, for me,
is to make incremental progress towards the end state goal we all want
to be at, ipv6-only end to end, while making this transition a
non-issue for the customer.

This is just my approach, if something else works for you, great.  I
appreciate the feedback you have provided in this conversation.

Cameron

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 25 Dec 2010 01:13:42 +1100

On 25/12/10 1:03 AM, "Ted Lemon" <[email-masked]> wrote:

> Major providers such as Google and Yahoo have resisted deploying IPv6 because
> the presence of dual-stack devices that are configured in such a way that the
> IPv6 portion of the stack works, but works much less well than the v4 portion
> of the stack, are sufficient in number that they expect to see worse
> performance when they turn on v6 than if they leave it off.

=> I think "much less well" isn't a clear indication of DS "brokenness". It
might be that IPv6 connectivity is crap, which is mostly true, that's why
Google has whitelisting arrangements, but I can't speak on their behalf.
This has nothing to do with DS, it's about connectivity.

> 
> This is a *huge* problem.   The perception that turning on v6 breaks things is
> a huge source of resistance to deployment of v6.

=> I agree, but you can't jump from there to blaming DS as a transition
mechanism.

Hesham

---

From: Rémi Després <[email-masked]>
Date: Fri, 24 Dec 2010 15:14:20 +0100

> Yep, all technologies have a scope to which they best fit. This was a
In my understanding, a PC that has a USB mobile broadband stick DOES FIT in this mobile thread.

> better solution.  Thanks for your feedback to this point.

I don't run a network myself, but I appreciate the openness of this comment.
(I just helped some DSL ISPs to rapidly deploy native IPv6, and try to continue to do so for mobile operators.)

Regards,
RD

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 24 Dec 2010 15:14:24 +0100 (CET)

> 6rd can work on operator networks that assign RFC1918 IPv4 addresses.

I am well aware of this.

> - would enjoy IPv6 service wherever using an operator infrastructure having at least one 6rd stateless relay.

It seems we have a massive disconnect in the discussion. I am well aware 
of what *could* be done, my problem is that I want to *do* it *now* (or 
at least in the next 3-4 months).

I agree that 6RD could be used in mobile networks, but it doesn't work 
right now because there is little code to do it in the terminals where it 
needs to be. Calling 6RD deployable here means you have a completely 
different opinion of what "deployable" is compared to me.

So you suggesting to me that 6RD could be used in mobile is like saying 
someone should build 100 new powerplants to solve the problem when I'm 
sitting here in the dark without power.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 24 Dec 2010 15:16:26 +0100 (CET)

On Fri, 24 Dec 2010, Rémi Després wrote:

> Now, the egg-and-chicken problem remains: who makes a first commitment 
> to 6rd? A mobile operator or a Host-OS provider. That said, I don't 
> despair to have a first trial somewhere once the (great) potential of 
> the solution is understood.

If the code existed in terminals, 6RD is very quick and easy to deploy for 
the "core". I'd be very happy in participating in 6RD trials if some 
handset manufacturer wants to do this to test code.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 24 Dec 2010 15:18:41 +0100 (CET)

On Sat, 25 Dec 2010, Hesham Soliman wrote:

> => Why? 3GPP has standardised the dual PDP and it's a matter of time 
> before the 3GPP link (using the word "link" loosely here to refer to PDP 
> context) will look more like a normal link that can run both IP families 
> simultaneously.

Dual PDP is a technical niceness, but in real life there is little support 
across the globe when it comes to core nodes and RAN (due to licensing 
reasons) and also a problem with handsets (I'm not even sure Symbian 
supports this, only device I've seen to support it is N900 with devel 
grade code).

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 25 Dec 2010 01:23:38 +1100

> support for IPv6, so that was about the year 2000 ....

=> DS availability is not related to RFC 2460, it's about implementations.
Yes rel 5 had a broken support for IPv6 which was fixed over the years. I
think you know what I'm referring to.

>Nothing happened, because the economics did not move
> it.

=> Right, so stop blaming DS for the last 10 years because it confuses
people who don't know.

> I know "Grandma" does not run Linux,

=> Not just grandma, most of the world, so if you know that lets not use it
as an example and confuse the issue!

  but the point is that the
> being installed in networks all around the world.

=> Which has nothing to do with DS, more to do with available popular
implementatios and the will to deploy.

> means IPv4 is turned off?

=> Transition doesn't mean replacement. Implementations will default to IPv6
connectivity when they get a AAAA record and they have IPv6 connectivity.
Simple as that. Over time this will naturally result in more IPv6 traffic.
If there is zero IPv4 traffic then it will be turned off. I don't think that
will happen anytime soon.

As far as i can tell, we are talking about
> problem has not yet been solved.

=> You haven't even got 1000 IPv6 users yet, why are you worried about
turning off IPv4? 

> IPv6 will emerge as working in more and more scenarios, i building to

=> Sounds like you're planning a DS network then.

> Technology happens in a context.

=> Sorry I don't know which technologies you refer to.

> will be on your network is likely a good start.

=> Right, which I did and found it insignificant.

Hesham

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 24 Dec 2010 06:24:39 -0800

> This permits transfers ONLY between hosts *behind the same NAT64*.

Agreed.  But today, on my network and others, mobiles cannot
communicate with each other directly.   This must change for IMS
deployments, but has not yet changed.

For me, this is a corner case without much relevance, but thanks for
bringing it to light.

Cameron

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 24 Dec 2010 06:49:13 -0800

> => Right, so stop blaming DS for the last 10 years because it confuses

Sorry if some found it confusing, that was not my intention.  My
belief is that the technologies and their impacts on the economic
factors are tightly coupled.  BetaMax may have been a better
technology, but the VHS economics were much much better... hence VHS,
an inferior technology gained dominance.

> as an example and confuse the issue!

Once again, not trying to confuse.  My only point was that the specs
were done, reference implementations (Linux, Solaris, BSD ...) were
complete, *nearly* 10 years ago.  Today, if you google IPv6, most
sites you will see talk about how to turn it off, because dual-stack
is seen as a problem to many users who do or do not have ipv6
connectivity.

> implementatios and the will to deploy.

Right, the ecosystem is broken. I point back to the economics issues,
lack of incentives, and the fact that DS does not solve *today's*
exhaust issue,... which has become a tactical issue from growing
networks .... networks that are not growing do not have an urgent
problem, unless my ipv6-only nodes try to connect to them :)

> => Transition doesn't mean replacement. Implementations will default to IPv6

To many, transition means replacement.  If i transition from a blue
shirt to a red shirt, i am now wearing a red shirt, not a blue shirt.

> Simple as that. Over time this will naturally result in more IPv6 traffic.

Keep your eyes on happy eyeballs.  If they fail the happy eyeballs
test (P value?), none of your traffic will go IPv6 because peering is
bad, latency is high,  support is bad , the application never had
pressure to go to IPv6....  Then, the ISP will say my IPv6 transit
links are not growing, no need to invest to make them bigger and
better... no need train more staff to be ipv6 savy .. which results in
growing CGNs that "just work" but kill the architecture of the
internet .... this is called a negative feedback loop.  I am not
saying it will certainly happen, but it may. And, it concerns me that
IPv6 will still not *transition* due to not only failure to provide
economic incentives as well as escalating issues around negative
feedback loops.

> will happen anytime soon.

see above, i am not trying to provide FUD or confuse.  It is just a
scenario i see as possible.  Since I am really out of IPv4 addresses,
i am completely deep into moving to IPv6 as soon as possible and
limiting and eventually eliminating my ipv4 risks. And, i encourage
others to move to IPv6 as soon as possible not because it is better
for them, but because it is better for me (no need to quote adam smith
here).    But, there is no silver bullet.  Buyer beware.

> => You haven't even got 1000 IPv6 users yet, why are you worried about

Not worried about turning it off for at least 10 years, but i do need
to decouple my business growth from IPv4 address dependencies in the
short term.  So, i need to grow without IPv4 because IPv4 is simply
not available.

As you may know, 3GPP support IPv4 PDP handset and IPv6 PDP handset
today.  They live in harmony today on my network.  Relative the the
rate overall end user growth, i need the IPv6 PDP growth rate to
increase and the IPv4 PDP growth rate to decrease in order to keep my
business going.

> => Sounds like you're planning a DS network then.

No, i will be supporting IPv4 stacks for some users and IPv6 stacks
for some users.

> => Sorry I don't know which technologies you refer to.

I don't either.  But the cable (pre-DOCSIS 3.0?) and DSL (ppp?) guys
seem to say their access networks are complicated and difficult to
transition.  It may be more of a deployment issue.

> => Right, which I did and found it insignificant.

Excellent.  Sounds like you are well on your way.

Cameron

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 24 Dec 2010 13:10:10 -0800

On 12/24/10 12:55 AM, Rémi Després wrote:
> Mikael,
> 
> +1 I am with you to insist that, IPv6+NAT44 is BETTER for users than
> IPv6+NAT64+DNS64. (Even if NAT44s are cascaded, as they already are
> in many places).

Note that in the mobile netwrk context, that may need out to twice as
much signaling, which is an implmentation detail which should not be
trivialized. There is more than one set of trade-offs to be put in
context, and the impact on legacy applications is but one of many.

> People have to know that draft-arkko-ipv6-only-experience-02 (of
> October 2010) says: "We also saw many applications that do not
> support IPv6 at all. These range from minor, old tools (such as the
> Unix dict(1) command) to major applications that are important to our
> users (such as Skype) and even to entire classes of applications
> (many games have issues)." ... "Our experience with IPv6-only
> networking confirms that dual stack should still be our recommended
> model for general purpose networking   at this point of time."
> 
> Also: - With IPv6+NAT44, an IPv6 address used to reach a server can
> be passed to another host to reach the same server (no NAT with
> IPv6). - With IPv6+NAT64+DNS64, and existing OSes, an IPv6 address
> used to reach a server CANNOT RELIABLY be passed to another host to
> reach the same server. (Promoting NAT64+DNS64 is promoting that a
> drawback of NATs be extended to IPv6, while IPv4+IPv6 service
> gracefully introduces a clean IPv6 without breaking IPv4 for
> connections that aren't possible in IPv6 yet.)
> 
> Best regards, RD
> 
> 
>>> Another data point is that over 100 of the users in my beta are
>>> using n900 and they get by well enough...
>> 
>> "get by"?
>> 
>> Am I the anomaly with messenger/skype not working, or are you
>> saying you'd be comfortable releasing a service where such
>> applications do not work?
> 
> 
> Cambridge Audio

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 24 Dec 2010 13:17:19 -0800

> But, technically speaking, adding 6rd to hosts isn't more complex that adding it to CPEs.

Maybe it is, maybe it isn't. the majority of the existing and near
future cpe in a mobile phone context were not designed to be routers
(some of them in fact were), so the availability code is not quite so
simple as patch this version of openwrt and do an OTA update.

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 25 Dec 2010 19:21:27 +1100

> No, i will be supporting IPv4 stacks for some users and IPv6 stacks

=> Hence your network is dual stacked....

Hesham

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 25 Dec 2010 09:36:11 +0100 (CET)

> => Hence your network is dual stacked....

Network yes, users no (if I interpret it correctly).

This will be the same for "my" mobile users, they will have single stack 
access, if I want DS then either v4 or v6 is going to be tunneled over the 
other.

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 25 Dec 2010 23:44:43 +1100

> access, if I want DS then either v4 or v6 is going to be tunneled over the

=> But you realise that you have no control over that? If a device can set
up multiple PDPs you won't stop that.

Hesham

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 25 Dec 2010 13:49:34 +0100 (CET)

On Sat, 25 Dec 2010, Hesham Soliman wrote:

> => But you realise that you have no control over that? If a device can 
> set up multiple PDPs you won't stop that.

Well, our 3G network only supports single simultaneous PDP context, so no, 
I don't realise that I don't have any control over that.

And we control what subscription can connect to what APN, so I don't get 
why you're saying I can't control that?

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 25 Dec 2010 23:53:06 +1100

> why you're saying I can't control that?

=> APN != PDP. You can have multiple PDPs on the same APN. But if you're
limiting a device to 1 PDP then that's something else. It's a bit strange
because you're limiting any traffic filtering which requires multiple PDPs.
But I guess no one's complaining, probably because no one uses it.

Hesham

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 25 Dec 2010 13:58:12 +0100 (CET)

On Sat, 25 Dec 2010, Hesham Soliman wrote:

> limiting a device to 1 PDP then that's something else. It's a bit 
> strange because you're limiting any traffic filtering which requires 
> multiple PDPs. But I guess no one's complaining, probably because no one 
> uses it.

I still don't understand. My APN is going to be either v4 or v6, why would 
someone want to connect multiple PDPs to the same APN and why would that 
affect what I said earlier about tunneling to get dual stack access?

---

From: Hesham Soliman <[email-masked]>
Date: Sun, 26 Dec 2010 00:04:37 +1100

> affect what I said earlier about tunneling to get dual stack access?

=> According to 3GPP standards (I don't know your setup) an APN is a generic
concept that defines the type of access. Within an APN there can be multiple
PDP contexts. IPv4 or IPv6 is an attribute of the PDP not the APN.
The standard allows you to have multiple PDP contexts whenever you feel like
it (i.e. The UE can initiate that at will). So, at least in theory, a device
can create 2 PDP contexts, one for IPv4 and one for IPv6.
There are traffic filtering capabilitites ...etc associated with the PDP
(TFT) that allows you to request special treatments for certain flows
...etc. That's part of the reason for having multiple PDPs per APN.

As to how it relates to tunnelling, obviously if you have both IPv4 and IPv6
PDPs then tunnelling is redundant. Since you have a DS network, you can
support both natively.

Hesham

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 25 Dec 2010 14:25:25 +0100 (CET)

On Sun, 26 Dec 2010, Hesham Soliman wrote:

> As to how it relates to tunnelling, obviously if you have both IPv4 and 
> IPv6 PDPs then tunnelling is redundant. Since you have a DS network, you 
> can support both natively.

I have yet to see terminals who support multiple PDP contexts apart for 
Internet+MMS.

Do you have other experiences?

---

From: Hesham Soliman <[email-masked]>
Date: Sun, 26 Dec 2010 01:27:38 +1100

> Do you have other experiences?

=> No I don't, but the point is that they can and they would be compliant if
they do so. That's why I said you can't really control that because the
standard allows it and it's up to the implementation. In the context of this
thread I've been saying that this is the easiest way of supporting IPv6
without affecting legacy systems or apps.

Hesham

---

From: Cameron Byrne <[email-masked]>
Date: Sat, 25 Dec 2010 07:13:45 -0800

Another good thing about symbian in this context it that it allows for
tightly coupling apns/profiles to applications, so mms can use v4 pdp
while web can use v6.  in this sense, it is very different from a pc
which may have a routing table and may be subject to unhappy eyeballs
and always needing scarce v4 resources.  Symbian has applications that
must be mapped to a v4 pipe/pdp or a v6 pipe/pdp.  that said, i do not
think it is possible today to support v6 and v4 connections with a
single web browser session ....meaning, on symbian the only mobile
platform that is currently supporting v6 aside from the defunct maemo,
only supports data sessions for individual stacks, v4 or v6 for that
app. There is no concept of a dual stack data session or dual stack
application, as far as i can tell, in symbian.

All that said, the way symbian has deployed works well for me, as i
only desire to support one stack per user at a time.  symbian also
allows the flexability for me to move web and email to ipv6 + nat64
and have that tied to a v6 pdp while still supporting legacy apps that
can open a v4 pdp on demand for a v4 apn profile tied to a v4-only
app.  that does not mean that i will support v4 with v6, but i believe
there is some flexability and i believe it is unique to symbian.  i do
not believe winmo or android can do this app to apn mapping, they have
routing tables like pc's do ...

Teemu knows more than me, but the above is my real world v6 experience.

Happy holidays,

cb

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 25 Dec 2010 16:37:49 +0100 (CET)

On Sun, 26 Dec 2010, Hesham Soliman wrote:

> => No I don't, but the point is that they can and they would be 
> compliant if they do so. That's why I said you can't really control that 
> because the standard allows it and it's up to the implementation. In the 
> context of this thread I've been saying that this is the easiest way of 
> supporting IPv6 without affecting legacy systems or apps.

If I only allow IPv6 PDPs in the only APN the subscriber is allowed to 
connect to, then I can control it.

Also, a lot of networks have not purchased the "multiple PDP context" 
license so this would not work when roaming. I therefore see this less 
likely as being implemented in real life in the short to medium term.

---

From: Hesham Soliman <[email-masked]>
Date: Sun, 26 Dec 2010 05:06:30 +1100

> connect to, then I can control it.

=> Yes of course, if you duplicate the APNs you have that would work. I
don't know how much control you have over that but if you can do that then
it will work. Of course you have to make sure your subscriber has an IPv6
capable phone and will never change it before he tells you so you can switch
his APN then switch it back with his other phone ...and so on. Practical?

> license so this would not work when roaming.

=> No that would work, your IPv6-only approach might be a problem when
you're roaming. A DS host would just use IPv4 if no IPv6 was available.
There are other ways of roaming in 3GPP anyway that would connect back to
the home network so that's not the issue.

I therefore see this less
> likely as being implemented in real life in the short to medium term.

=> Not because of the reason you have above. Roaming won't matter here.

Hesham

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 25 Dec 2010 19:45:41 +0100 (CET)

On Sun, 26 Dec 2010, Hesham Soliman wrote:

> don't know how much control you have over that but if you can do that 
> then it will work. Of course you have to make sure your subscriber has 
> an IPv6 capable phone and will never change it before he tells you so 
> you can switch his APN then switch it back with his other phone ...and 
> so on. Practical?

I don't understand what you're talking about. I'm wondering if your world 
is very different from mine.

I have little theoretical knowledge about what the 3GPP standards say can 
be done, I have only practical knowledge about what is done and what is 
possible today.

> the home network so that's not the issue.

Again, I don't understand what you're talking about. The phones available 
today isn't DS, they only support single PDP context, and if I only 
provide IPv6 PDP context for that subscriber, they will use that or fail.

> => Not because of the reason you have above. Roaming won't matter here.

Again, same thing. I don't understand how this would not matter. Roaming 
is important and it needs to work.

---

From: Cameron Byrne <[email-masked]>
Date: Sat, 25 Dec 2010 11:31:58 -0800

My expectation is that gprs roaming with native v6 pdp will not work
and be properly build for a long long time. Strangely, v6 pdp roaming
works by default on many networks today, but it is not properly
billed, and thus is a big problem. We are setting it up so that the
handset always tries v6 pdp first and the ggsn, via pcrf rules,
rejects roamers attempting to connect on v6. The ue gets the pdp
reject and then retries with v4 and suceeds. This does work today with
symbian's notion of apn priorities. V6 is the first priorty and v4 is
2nd. Given that our goal is service parity  (for common services: web,
email, ...) with v4 and v6, the fact that user has v6 in network and
v4 out of network should not be an issue to the end user on a handset.

Cb

Cb

---

From: Gert Doering <[email-masked]>
Date: Sat, 25 Dec 2010 22:58:28 +0100

Hi,

On Sat, Dec 25, 2010 at 01:11:03AM +1100, Hesham Soliman wrote:
> wasn't available for that long. 

Just for the record: it was.  Our first DS router was put in place in
May 1997.  Not production quality, of course, and IPv6 support for
NT 4.0 was *very* experimental, but DS *was* available.

At that time I assumed that people would deploy IPv6 because they see
that it's just the better protocol - and boy, how I was wrong.  Even with
the IPv4 run-out looming, it wasn't deployed.  So what Ted Lemon is saying
is so true: for the generic (Internet access) end-user, if IPv4 does the 
job, there is no reason to deploy DS, and so it isn't done.

Basically, there's three major groups of player here, and to blindly state
that one solution is going to work for all three of them is too close-
minded.

 - established Internet access customers (DSL, cable, ...) - these already
   have IPv4, and could run dual-stack - but they will just stay with IPv4,
   unless their ISPs will offer some sort of incentive to move to IPv6
   (or the ISP will just "make it happen" without the customer knowing)

 - new growth in Internet access customers - there's no IPv4 for those, so 
   they can't run dual-stack without NAT444 for IPv4 - but we'll see those 
   deployments anyway.  A subset of that group is "mobile" - very controlled
   device and program environment, and the network operator knows precisely
   what sort of device is trying to use the network, so IPv6-only can be 
   made work, handset vendor-by-vendor

 - content - here we'll *have* to go to dual-stack, because there will be
   IPv4-only access customers for a long while, and for the networks that
   have no more IPv4, "direct IPv6" has less overhead and less middleboxes
   than NAT64 - so has a higher propability of working

> I don't agree with your assumption that if

Why would anyone deploy DS if IPv4 is good enough for them?

(Except some few geeks like us)

Gert Doering
        -- NetMaster
-- 
did you enable IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Gert Doering <[email-masked]>
Date: Sat, 25 Dec 2010 23:03:17 +0100

Hi,

> years ago (year 2000 in my calendar) where was IPv6 supported? Which os?

13.5 years ago:

NT 4.0 + experimental stack, Solaris 2.5 (or 2.6?) + experimental stack, 
FreeBSD/NetBSD + Kame stack, Linux + Usagi stack.

I'm fairly sure that about 10 years ago, all the *BSDs and Linux had IPv6 
in the standard kernel already.  Of course, lots of bits and pieces were
missing (but some are still missing).

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Sat, 25 Dec 2010 23:16:17 +0100

Hi,

> In my understanding, a PC that has a USB mobile broadband stick DOES FIT in this mobile thread.

Actually, it doesn't.  That's just a PC with a weird access technology
to the Internet - but it's not a typical mobile handset with a very
controlled application environment and a large amount of control on the
side of the network operator.

(Also, there seems to be no USB UMTS stick on the market yet that does
IPv6 at all...)

Gert Doering
        -- NetMaster

---

From: Joel Jaeggli <[email-masked]>
Date: Sat, 25 Dec 2010 14:39:18 -0800

> (Also, there seems to be no USB UMTS stick on the market yet that does

There are theoretically LTE sticks from hauwei which do, I haven't
actually tested one yet.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 25 Dec 2010 23:49:34 +0100 (CET)

> side of the network operator.

I don't agree. For us as a mobile operator we so far has treated all 
terminals the same, and the newer smartphones have more in common with PCs 
than they have with what 3GPP might think out is special about mobiles.

> (Also, there seems to be no USB UMTS stick on the market yet that does

Well, actually we have gotten IPv6 to "work" on a huawei stick, but we had 
to manually configure the IPv6 address in linux (logged into the GGSN to 
find out what address it was supposed to be), as IPV6CP didn't seem to 
work on the PPP layer from the usb stick.

So I agree, in real life it doesn't work, but we've been able to pass 
packets anyway...

---

From: Hesham Soliman <[email-masked]>
Date: Sun, 26 Dec 2010 14:47:04 +1100

> is very different from mine.

=> I'm starting to think that as well.

> provide IPv6 PDP context for that subscriber, they will use that or fail.

=> Right and my comment was how would you like it if they fail? That has
nothing to do with theoritical knowledge, you'll offer an IPv6 only PDP and
the user might not be able to establish that, then what? You're associating
a subscription with an IP address family. The support of IPv6 is an
attribute of the device not the subscription.

> is important and it needs to work.

=> I didn't say it's not important, I said there are ways of making it work
regardldess by connectimg to the home network. I also said that a DS host
would roam fine using IPv4 if v6 was not available. I don't see anything
complex in that.

Hesham

---

From: Hesham Soliman <[email-masked]>
Date: Sun, 26 Dec 2010 14:49:25 +1100

> FreeBSD/NetBSD + Kame stack, Linux + Usagi stack.

=> Yes I know that but I don't think you'd seriously say that IPv6 support
was ready because 10% of the OS's supported it. That's silly. Beta releases
by MS cannot count for any serious deployment. I can't believer we're
discussing this

Hesham

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 26 Dec 2010 08:10:06 +0100 (CET)

On Sat, 25 Dec 2010, Mikael Abrahamsson wrote:

> Well, actually we have gotten IPv6 to "work" on a huawei stick, but we 
> had to manually configure the IPv6 address in linux (logged into the 
> GGSN to find out what address it was supposed to be), as IPV6CP didn't 
> seem to work on the PPP layer from the usb stick.

Correction, this wasn't a dongle, it was a symbian phone attached to a 
computer running linux.

---

From: Gert Doering <[email-masked]>
Date: Sun, 26 Dec 2010 11:43:32 +0100

Hi,

> than they have with what 3GPP might think out is special about mobiles.

I think one of the important differences is the software ecosystems on
the PC vs. the mobile.  On a mobile, you just don't have that many 
"legacy applications" that people insist must continue to work - and if
the mobile programming environment is halfway sane, apps will handle IPv6
right away, instead of the programmer having to choose between an IPv4-only
API that they know, and "something new" that they are not paid to learn...

(Or, phrasing it differently, I have hope for the mobiles, while PCs 
inevitable are a bag of legacy cruft and users that insist that a 20-year-
old game that is using IPv4 via an IPX-to-IPv4 adaption shim still has
to work...)

> So I agree, in real life it doesn't work, but we've been able to pass 

Well, since IPv6CP will not tell the PPP client its IPv6 address anyway
(it will negotiate host IDs, and thus link-locals, but never any other
IPv6 addresses -- DHCPv6 or RA will do the actual IPv6 address assignment) 
this does not sound too bad...

I'm happy to hear that, anyway.  The sticks I have tested either give up
right away when you request an IPv6 PDP, or claim to support it but fail 
to actually answer to the hosts's IPv6CP packets...

Was that with a regular firmware, or something you got for your lab?  If
"regular", could you share the model + firmware version of the stick?

regards,

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Sun, 26 Dec 2010 11:45:55 +0100

Hi,

> Correction, this wasn't a dongle, it was a symbian phone attached to a 

No big surprise here - the Nokia (symbian) phones support IPv6 quite well,
both as a "modem" and for running local apps.

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Sun, 26 Dec 2010 11:50:47 +0100

Hi,

> by MS cannot count for any serious deployment. I can't believer we're

I'm just inserting some facts into the claims you have made.

But it doesn't really matter - you obviously have some very strong beliefs
how the IPv6 world is going to develop, and some other participants on this 
list have abandoned these ideas a few years ago already.

We run a full dual-stacked backbone and office network, and are working
on getting all the Internet facing servers to be dual-stacked - but for
the access customers (eyballs), the move to dual-stack has been extremely 
slow in the last 13 years, and it's hard to believe that this is going to
change all of a sudden.  

"If they have enough IPv4 addresses to run dual-stack, what's the benefit in 
running dual-stack?"

Gert Doering
        -- NetMaster

---

From: Hesham Soliman <[email-masked]>
Date: Sun, 26 Dec 2010 22:30:55 +1100

> list have abandoned these ideas a few years ago already.

=> Actually I have no idea about the future, I'm questioning statements and
assumptions made. I'll be the first to say I don't know what will happen but
I do know what my opinion is based on the current state of play.

> slow in the last 13 years, and it's hard to believe that this is going to

=> Do you have IPv6 access natively? I would guess that until you dual stack
your servers and allocate IPv6 addresses to those end systems you won't see
much traffic on IPv6. Lets face it, there is nothing IPv6 on the Internet
now. But my point is that this will gradually happen and being DS'ed makes
you ready for a slow but reliable transition where apps won't suffer.

Hesham

---

From: Cameron Byrne <[email-masked]>
Date: Sun, 26 Dec 2010 05:23:12 -0800

> attribute of the device not the subscription.

IP address family is absolutely part of the subscription.  That is one
of the areas we have had to work hard on.  As the user profile in the
HLR/HSS today is defined as IPv4 PDP, we have go through and update
all subscriber records in the HLR to support IPv4 and IPv6 PDP.

We have found that enabling the HLR profile for IPv6 and IPv4 then
setting the handset to automatically attempt ipv6 PDP first and fail
back to attempting ipv4 pdp if v6 fails is functional and supports
legacy v4 roaming.

Cameron

---

From: Cameron Byrne <[email-masked]>
Date: Sun, 26 Dec 2010 05:27:32 -0800

> you ready for a slow but reliable transition where apps won't suffer.

Umm.... there is a lot of content available of IPv6 today.  I have a
very good understanding of where my mobile users are going today to
get content.  I also know that Google, Facebook, and now Yahoo to a
lesser degree and a few others are highly functional on IPv6 today.  I
feel VERY confident that my IPv6-only + NAT64 users, by the end of
2011, will service over 50% of their content natively over IPv6.
Google and Facebook are whales in the USA, when they move, the
industry moves.

Cameron

---

From: Joel Jaeggli <[email-masked]>
Date: Mon, 27 Dec 2010 00:11:36 -0800

This thread is at 157 messages since 12/21.

It started with Mikael Ambrahmsson, describing the current state of play
with mobile-devices and v6 stacks.

I think it can safely take a timeout.

Enjoy the new year.

joel

---

From: Rémi Després <[email-masked]>
Date: Mon, 27 Dec 2010 09:27:05 +0100

Le 24 déc. 2010 à 15:03, Ted Lemon a écrit :
> ... The perception that turning on v6 breaks things is a huge source of resistance to deployment of v6.

Agreed.

That's why we should try to build up awareness that those who having native IPv6 addresses today are happy users of their operational dual-stacks.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Mon, 27 Dec 2010 10:02:50 +0100

Le 25 déc. 2010 à 23:16, Gert Doering a écrit :
> ... there seems to be no USB UMTS stick on the market yet that does
> IPv6 at all...)

With 6rd, the stick doesn't need to.
The OS adds an IPv6 "pseudo interface" to its IPv4 "real interface" provided by the stick. 

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Mon, 27 Dec 2010 10:06:28 +0100

> old game that is using IPv4 via an IPX-to-IPv4 adaption shim still has

IMHO, operators should prefer solutions that work for the complete 3GPP-customer ecosystem:
- simple smartphones (with all applications capable of both v4 and v6) 
- high-end smartphones, capable of supporting many applications and acting as routers
- PCs with USB sticks and/or behind smartphone that act as routers routers
- ...

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Mon, 27 Dec 2010 10:54:46 +0100

> that one solution is going to work for all three of them is too close-

What would IMHO be close-minded would be not looking at "6rd across the IPv4 bearer service", proposed as a workable solution for these 3 player groups:  

1.
>   have IPv4, and could run dual-stack - but they will just stay with IPv4

>   (or the ISP will just "make it happen" without the customer knowing)

With 6rd, the ISP can "make it happen" very easily (as Free did in production in 2007, and as Comcast did in one of its trials in 2010.) 

2.
>   deployments anyway.  

o Agreed, there will be NAT44s in operator networks. (AFAIK, there are some already. For high-end handsets that act as routers this will indeed be NAT444 scenarios.)
o In PCs, NAT64 is more disruptive than NAT444 plus IPv6 (easily feasible with 6rd).

> A subset of that group is "mobile" - very controlled

o I agree that IPv6-only+NAT64 may work for specific devices whose applications are restricted, and under operator control (e.g. web browsing without transmission of addresses, and e-mail). For these devices, 6rd can work too, but isn't a must. 

3.
>   than NAT64 - so has a higher propability of working

o 6rd offers a real dual-stack service. 
o the IPv4 header added to IPv6 packets won't be noticed in user normal operation. 

Regards,
RD

---

From: Gert Doering <[email-masked]>
Date: Mon, 27 Dec 2010 12:06:51 +0100

Hi,

On Sun, Dec 26, 2010 at 10:30:55PM +1100, Hesham Soliman wrote:
> => Do you have IPv6 access natively? 

Yes, sure.

> I would guess that until you dual stack
> much traffic on IPv6. 

As I said: all our backbone and office networks are dual-stacked, and we're
working on the servers - some are already done, and to some intranet servers
we already see >90% of the traffic being IPv6 (which is not overly surprising).

> Lets face it, there is nothing IPv6 on the Internet now. 

Well, there are some high-profile sites already (heise.de, vg.no) - but
those are dual-stacked, of course, as IPv6-only does not make sense to
do for content.

Which means that there still is no compelling reason for the access to go
to dual-stack.

> But my point is that this will gradually happen and being DS'ed makes

The problem is: while DS is nice in theory, there is no reason why 99% of
the Internet "eyeballs" would *want* to go there.  This is what we have
come to understand some years ago, when our IPv6 product offering didn't
sell as we expected.

Those that have IPv4 can reach everything they need with IPv4, so there
is no big incentive to add DS.

Those that do not have IPv4 can't run dual-stack (they will have to do
NAT64 or DS-Lite to access IPv4-only content).

So there will be a move from IPv4 to IPv6 (for pressure on the eyeball
side where no more IPv4 is available), but whether it will be "dual-stacked"
will be seen.  I think there's lots of good arguments for Cameron's
approach (and I strongly hope that Apple and Android will wake up soon
and provide IPv6 on the 3G side of their mobiles).

Gert Doering
        -- NetMaster