Subject: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05

From: jouni korhonen <[email-masked]>
Date: Fri, 21 Jan 2011 13:02:57 +0200

Folks,

We have updated the I-D and tried to reflect the recent discussion in the V6OPS list as well we could for the time being. Thanks to everybody who provided constructive feedback. The attempt has been making the I-D just a description of the existing architecture. I hope we can move I-D forward rather soon as it has been around for quite some time already. Additional comments and feedback are of course solicited.

- Jouni

Begin forwarded message:

> From: IETF I-D Submission Tool <[email-masked]>
> Date: January 21, 2011 12:48:01 PM GMT+02:00
> To: [email-masked]
> Cc: [email-masked],[email-masked],[email-masked],[email-masked],[email-masked]
> Subject: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05 
> 
> 
> A new version of I-D, draft-korhonen-v6ops-3gpp-eps-05.txt has been successfully submitted by Jouni Korhonen and posted to the IETF repository.
> 
> Filename:	 draft-korhonen-v6ops-3gpp-eps
> Revision:	 05
> Title:		 IPv6 in 3GPP Evolved Packet System
> Creation_date:	 2011-01-21
> WG ID:		 Independent Submission
> Number_of_pages: 26
> 
> Abstract:
> Internet connectivity and use of data services in 3GPP based mobile
> networks has increased rapidly as a result of smart phones, broadband
> service via HSPA and HSPA+ networks, competitive service offerings by
> operators and a large number of applications.  Operators who have
> deployed networks based on 3GPP architectures are facing IPv4 address
> shortages.  With the impending exhaustion of available IPv4 addresses
> from the registries there is an increased emphasis for operators to
> migrate to IPv6.  This document describes the support for IPv6 in
> 3GPP network architectures.
> 
> 
> 
> The IETF Secretariat.
> 
>

---

From: Fred Baker <[email-masked]>
Date: Fri, 21 Jan 2011 08:45:45 -0800

> We have updated the I-D and tried to reflect the recent discussion in the V6OPS list as well we could for the time being. Thanks to everybody who provided constructive feedback. The attempt has bee…

OK, different question for the group. At IETF-79, we asked (in the survey) whether this should become a working group draft, and opinion was supportive of the draft but divided on status. In my opinion, we should adopt this as a working group draft at this time, run it around the block at IETF-80, and then ship it to the IESG.

Opinions? Shall we:
   - tell the chairs to send it to the IESG now as an individual submission?
   - adopt it as a working group draft and immediately WGLC it?
   - adopt it as a working group draft and continue discussion?

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 21 Jan 2011 09:42:41 -0800

On 1/21/11 8:45 AM, Fred Baker wrote:
>> We have updated the I-D and tried to reflect the recent discussion
>> in the V6OPS list as well we could for the time being. Thanks to
>> everybody who provided constructive feedback. The attempt has been
>> making the I-D just a description of the existing architecture. I
>> hope we can move I-D forward rather soon as it has been around for
>> quite some time already. Additional comments and feedback are of
>> course solicited.
> 
> 
> OK, different question for the group. At IETF-79, we asked (in the
> survey) whether this should become a working group draft, and opinion
> was supportive of the draft but divided on status. In my opinion, we
> should adopt this as a working group draft at this time, run it
> around the block at IETF-80, and then ship it to the IESG.
> 
> Opinions? Shall we: - tell the chairs to send it to the IESG now as
> an individual submission? - adopt it as a working group draft and
> immediately WGLC it?

given the recently updated status, I favor this... if wghlc produces new
feeback then an ammended draft may be forwarded to the iesg.

joel

> - adopt it as a working group draft and continue
> discussion? _______________________________________________ v6ops
> mailing list [email-masked] 
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 21 Jan 2011 21:58:53 -0800

" If the
      visited network to which outbound roamers attach to does not
      support PDP/PDN Type IPv6, then there needs to be a fallback
      option."

This is  also relevant to v4v6 since v4v6 is much newer and thus much
less widely deployed than IPv6 PDP.

Can you provide some more guidance about what the fall back mechanism
may be?  This is quite a hot topic.   One of the things we have
discussed deploying is having PCRF rules that reject PDP Type IPv6
from Gp (if MNC == my MNC ok, else reject) until roaming agreements
are ratified and engineered for.

Today, IPv6 roaming is revenue leakage in most case.  To fix this,
IPv6 roaming should be rejected until fixed and billed properly.
Given that prcess will take a long time and IPv6 deployments are
rolling out now in various 3G and 4G networks, what will be the fall
back?  Should the device have multiple APNs with priorities set (IPv6
= p1, ipv4 = p2)?  What are the proper failure codes that the UE
should expect to advance the through the priority list and retry the
next APN.

Thanks,
Cameron

---

From: Jouni <[email-masked]>
Date: Sat, 22 Jan 2011 12:21:55 +0200

Hi,

Thanks for the quick feedback.

> less widely deployed than IPv6 PDP.

Right. I definitely should add few words around that.

> may be?  This is quite a hot topic.   One of the things we have

I am afraid there is no solution that would please all parties. And given the wished stricter scope of the I-D, we don't really have 3GPP TS level defined fallback mechanisms. Using S2c comes to my mind.. but..

> are ratified and engineered for.

Good point. I have been a bit hesitant to add anything PCC related so far as PCC is an optional functionality. One could probably do that also in a MME/SGSN level using the grey blob "roaming restrictions". However, in that case the responsibility falls into the visited operator..

> IPv6 roaming should be rejected until fixed and billed properly.

The formal practicalities are of course up to the operator community to decide.

> should expect to advance the through the priority list and retry the

Above priority based mechanisms are being implemented (or partially already implemented) to devices, at least to some of them. Some guidance is already there in 23.401 that relate to return codes received from the network and how the mobile device should act after based on those. The operator can affect those by tuning the subscription profile/PDN-GW configuration. Unfortunately, there is also a grey area that is mostly left for mobile device implementers to come up with their innovative ways to handle the situation.

Would it make sense to list some of the possible ways that are possible strictly following the 23.401 "toolbox"? That would probably be a new section 8.x.

- Jouni

---

From: Cameron Byrne <[email-masked]>
Date: Sat, 22 Jan 2011 20:29:27 -0800

> I am afraid there is no solution that would please all parties. And given the wished stricter scope of the I-D, we don't really have 3GPP TS level defined fallback mechanisms. Using S2c comes to my…

Right, agreed regarding stricter scope and 3GPP failing to provide
real world guidance to operators in this situation ... as well as GSMA
...

> Good point. I have been a bit hesitant to add anything PCC related so far as PCC is an optional functionality. One could probably do that also in a MME/SGSN level using the grey blob "roaming restr…

I cannot assume the visited network even knows what an IPv6 PDP is,
right?  And, if the visited network does allow the IPv6 PDP, they will
want to charge for it.  They will want to charge the home network for
it.  So, if i host an IPv6 capable APN across GRX/IPX, i am liable for
the billing of it ... yet ZERO billing arrangements account for IPv6
today.  So, the home network MUST block the IPv6 PDP across the
roaming until it is possible to bill for it, which involves
complexities that nobody believes will be solved before IPv6 is rolled
out to users.

So, if the home network must block the IPv6 PDP, it must be done on
the GGSN/P-GW via GGSN/P-GW features or PCRF rules.

> The formal practicalities are of course up to the operator community to decide.

Right now, operators are looking to cover revenue leakage that is
happening via IPv6.  They are not looking to enable it across roaming.

> Above priority based mechanisms are being implemented (or partially already implemented) to devices, at least to some of them. Some guidance is already there in 23.401 that relate to return codes r…

Can you provide a pointer in 23.401? I could not find this text.

> Would it make sense to list some of the possible ways that are possible strictly following the 23.401 "toolbox"? That would probably be a new section 8.x.

I believe that would be a great addition to the draft as this is a
real problem and the community should have a good discussion on it
across the various stakeholders.

 As i mentioned, my operating assumption is that the home network must
reject IPv6 PDP from Gp as long as there is not a roaming agreement
and billing infrastructure to support it.   Today, there is nothing
for roaming with IPv6, so it should not be supported anywhere via
roaming.  That said, the home network must reject the PDP, and the UE
must react by retrying with IPv4.

Cameron

---

From: [email-masked]
Date: Sun, 23 Jan 2011 20:22:42 +0200

Hi Cameron,

I am not sure that "So, the home network MUST block the IPv6 PDP across the roaming until it is possible to bill for it"  is a proper statement for an IPv6 PDP. I have tried IPv6 PDP in roaming in 3 different countries without any prior testing arrangements and have been billed correctly in every case. Obviously I can not assume it will be perfect for any country I visit and we need a mechanism indeed to define it on a formal level.

"which involves complexities that nobody believes will be solved before IPv6 is rolled out to users." - so, you believe it will be easier and faster to create fallback mechanism that will most likely come as a part of a major release years from now, rather then correct the billing, which in most cases may disconsider the IP address anyway and does not care about IP version?

At this point I am somehow seeing the light at the end of the tunnel with the IPv6 only PDP and believe that the roaming partners should simply check their capabilities in this regards.
Regarding the v4v6 PDP the issue is more complex indeed as it will take years for operators to upgrade to supporting releases. In that specific case the fallback mechanisms should be in place and they might arrive just in time before the issues are widespread.

Best,
Roman

[email-masked] wrote: -----

To: Jouni <[email-masked]>
From: Cameron Byrne
Sent by: [email-masked]
Date: 01/23/2011 06:29AM
Cc: IPv6 Ops WG <[email-masked]>
Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05

Cameron

>> Cameron
_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Cameron Byrne <[email-masked]>
Date: Sun, 23 Jan 2011 10:33:45 -0800

On Sun, Jan 23, 2011 at 10:22 AM,  <[email-masked]> wrote:
> Hi Cameron,
>
> I am not sure that "So, the home network MUST block the IPv6 PDP across the
> roaming until it is possible to bill for it"  is a proper statement for an
> IPv6 PDP. I have tried IPv6 PDP in roaming in 3 different countries without
> any prior testing arrangements and have been billed correctly in every case.
> Obviously I can not assume it will be perfect for any country I visit and we
> need a mechanism indeed to define it on a formal level.
>

This is surprising.  You were billed for the proper international
roaming usage?  We have reached out to many roaming partners and they
have explicitly said they do not have plans to support this.

So, is your information based on what you have tried or what various
operators have contractually agreed to?  I agree there is a difference
between the 2, but both must be clearly supported before we can allow
customers to do it.

 Furthermore, Ericsson has relayed a situation where they did ipv6 pdp
in Japan recently and it crashed the Japanese billing system since
there was unexpected data in the CDRs.... 128 bit Severed PDP field
instead of 32 crashed the CDR batch processing.

> "which involves complexities that nobody believes will be solved before IPv6
> is rolled out to users." - so, you believe it will be easier and faster to
> create fallback mechanism that will most likely come as a part of a major
> release years from now, rather then correct the billing, which in most cases
> may disconsider the IP address anyway and does not care about IP version?
>

Yes.  I believe fall back is required since the official word from our
roaming partners is that they do not support it.  Without official
support, we cannot take it to production.  And, with so many roaming
partners running different software for billing and different hardware
in their networks, it is a very complicated environment to drive
change.

> At this point I am somehow seeing the light at the end of the tunnel with
> the IPv6 only PDP and believe that the roaming partners should simply check
> their capabilities in this regards.

I am sorry to be pessimistic just as you are becoming optimistic !  I
too believe IPv6-only is good, but the roaming part .... it is a
challenge to make "officially" work while i am aware that in some
places it does unofficially work.  I can tell you today that Ericsson
has done IPv6 roaming on the T-Mobile USA back to Telia as the home
network.  It was not billed from T-Mobile to Telia ... the IPv6 CDRs
are discarded as part of CDR data validation.  So it technically works
for the user, but it will not be billed... which is bad for the
operator.

> Regarding the v4v6 PDP the issue is more complex indeed as it will take
> years for operators to upgrade to supporting releases. In that specific case
> the fallback mechanisms should be in place and they might arrive just in
> time before the issues are widespread.
>
> Best,
> Roman
>
>
>
>
>> I am afraid there is no solution that would please all parties. And given
>> the wished stricter scope of the I-D, we don't really have 3GPP TS level
>> defined fallback mechanisms. Using S2c comes to my mind.. but..
>>
>
>> Good point. I have been a bit hesitant to add anything PCC related so far
>> as PCC is an optional functionality. One could probably do that also in a
>> MME/SGSN level using the grey blob "roaming restrictions". However, in that
>> case the responsibility falls into the visited operator..
>>
>
>> Above priority based mechanisms are being implemented (or partially
>> already implemented) to devices, at least to some of them. Some guidance is
>> already there in 23.401 that relate to return codes received from the
>> network and how the mobile device should act after based on those. The
>> operator can affect those by tuning the subscription profile/PDN-GW
>> configuration. Unfortunately, there is also a grey area that is mostly left
>> for mobile device implementers to come up with their innovative ways to
>> handle the situation.
>>
>
>> Would it make sense to list some of the possible ways that are possible
>> strictly following the 23.401 "toolbox"? That would probably be a new
>> section 8.x.
>>
>

---

From: [email-masked]
Date: Sun, 23 Jan 2011 20:50:58 +0200

Yes,

Properly billed for international usage in 3 European countries. Have checked with billing on that.
The information is based on what I have tried. No prior official arrangements have been made.

The case with E/// is interesting and it might have been the case. Indeed, the prior change of the IP field to 128 bits should be made. We had a similar issue, however it has been solved in less then 2 weeks.

Now I am not saying that a fallback mechanism is something we do not need. All I am suggesting is as long as timing is involved, we are unlikely to see it in 3-5 years from now in all the networks we have roaming arrangements with. While, IPv6 PDP is there starting from R99, so it might be easier to ask the partners to have a look in their billing now then try and explain our customers for the next 5 years that we are still waiting for a fallback mechanism, this is why they should manually select another APN to use when they are going abroad. The question is either in 5 years from now we might have customers with IPv6/v4v6 only APNs?

So, the problem is really complex here. I would rather start working on what we have now and still hope for the fallback, rather then sabotage the proper IPv6 deployment for years in hope that country X will have their network elements upgraded.

Roman

-----Cameron Byrne <[email-masked]> wrote: -----

To: [email-masked]
From: Cameron Byrne <[email-masked]>
Date: 01/23/2011 08:33PM
Cc: [email-masked], [email-masked]
Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05

---

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Sun, 23 Jan 2011 19:59:26 +0100

> arrangements have been made.
Hi

We deployed IPv6 at two Slovenian mobile operators in April 2010, since 
then I tested IPv6 PDP in roaming from various places around the world - 
most intensively from July to October last year.

Received bills from operators - none.

We received a bill for v6 traffic in November, but just from one 
operator (you would never guess which, but sorry, no names...)

I agree that billing needs to be fixed (and here goes away my free 
mobile communication), but this can't be basis for refusing IPv6 PDP 
context in roaming mode. If you can't charge it, then it's free. If you 
can or want to charge it, charge it. But please don't suggest people to 
drop PDP contexts.

Cheers, Jan Zorz
go6.si

---

From: Cameron Byrne <[email-masked]>
Date: Sun, 23 Jan 2011 11:12:17 -0800

Roman,

> arrangements have been made.

Good.  But, the bilateral roaming contracts need to be updated likely.
 This is the policy issues that has us most concerned.  The technical
pieces have available technical solutions.

> The case with E/// is interesting and it might have been the case. Indeed,
> the prior change of the IP field to 128 bits should be made. We had a
> similar issue, however it has been solved in less then 2 weeks.
>

For some it will be easy to solve. Others, it will not be easy to
solve.  And, you are progressive and savvy with IPv6.  Not all
operators have IPv6 on the their near term roadmap and billing systems
tend to be very inflexible and hard to update for many operators.
Yet, we both have to support the roaming partners and assume they do
not have ipv6 until they explicitly tell us in the roaming contracts
that IPv6 is ok. If we assume IPv6 works, i can lead to billing
systems crashing and revenue leakage where customers are not billed.
Trial and error is not good enough here, as the business folks have
very little tolerance for these problems.

> Now I am not saying that a fallback mechanism is something we do not need.
> All I am suggesting is as long as timing is involved, we are unlikely to see
> it in 3-5 years from now in all the networks we have roaming arrangements
> with. While, IPv6 PDP is there starting from R99, so it might be easier to
> ask the partners to have a look in their billing now then try and explain

Agreed.  This seems something GSMA should prioritize.

> our customers for the next 5 years that we are still waiting for a fallback
> mechanism, this is why they should manually select another APN to use when
> they are going abroad. The question is either in 5 years from now we might
> have customers with IPv6/v4v6 only APNs?
>
> So, the problem is really complex here. I would rather start working on what
> we have now and still hope for the fallback, rather then sabotage the proper
> IPv6 deployment for years in hope that country X will have their network
> elements upgraded.
>

I agree. We do not want to sabotage IPv6 roaming adoption.  This needs
to be pushed, but even as a high priority in GSMA, a fallback will be
required for 5+ years at least since we both have over 100 roaming
partners all around the globe.

The fall back i have suggested works well, in my mind.  The UE always
tries IPv6 first.  The home network will reject or accept the PDP
based on PCRF rule.  For example, "Mobile Network Code" == "MNC
whitelist of IPv6 roaming partners" then OK, else reject.  And upon
reject, the UE tries IPv4

This way, IPv6 is always first and allowed when possible.  The
fallback is IPv4, which always works.  Fallback for a given roaming
partner will end when they support IPv6 in the roaming contracts and
are added to the whitelist.  The PCRF supports this logic very easy
today.

Cameron

---

From: Joel Jaeggli <[email-masked]>
Date: Sun, 23 Jan 2011 11:13:03 -0800

> have explicitly said they do not have plans to support this.

I'm not sure that the level of granularity around whether or why ipv6
roaming/billing does or does not work is wholly appropiate to an ietf
document. certainly such information is has a level of timelyness that
may or may not be releveant by the time the document arrives at the
publication stage.

---

From: [email-masked]
Date: Sun, 23 Jan 2011 21:14:15 +0200

Hi Jan,

"but this can't be basis for refusing IPv6 PDP context in roaming mode." - yes, I can't imagine that either from a purely user experience perspective. Especially if we project ourselves 2-3 years into the future. Obviously from business perspective it makes sense.

I will recheck once again the CDRs with the billing, however I am absolutely sure in October 2010 the IPv6 PDP was working in roaming and we have received the bills. Was it a coincidence? I have no idea. Probably it might make sense to ask the billing folks select randomly 10 partners and ask them to give a spin for the IPv6 PDP and recheck on that on a broader scale.

On the Slovenian part, how do you plan to solve the billing issues? Do you think it should this be more broadly reflected in the existing drafts and how?

Best,
Roman

[email-masked] wrote: -----

To: [email-masked]
From: "Jan Zorz @ go6.si"
Sent by: [email-masked]
Date: 01/23/2011 09:00PM
Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05

Hi

Cheers, Jan Zorz
go6.si

---

From: Cameron Byrne <[email-masked]>
Date: Sun, 23 Jan 2011 11:27:22 -0800

Jan,
==========
"I agree that billing needs to be fixed (and here goes away my free
mobile communication), but this can't be basis for refusing IPv6 PDP
context in roaming mode. If you can't charge it, then it's free. If you
can or want to charge it, charge it. But please don't suggest people to
drop PDP contexts."
==========

Sorry, the business folks believe otherwise.  No free rides.  The only
reason it is free for you today is that the mobile providers don't
know what i happening.

Today, our beta IPv6 APN is not announced to roamers at all.

As we go to production, we will be rejecting IPv6 PDP from roaming
partners that have not explicitly updated the roaming agreements to
include IPv6, which validates that the end to end billing process will
work correctly.

Cameron

---

From: Cameron Byrne <[email-masked]>
Date: Sun, 23 Jan 2011 11:29:05 -0800

> may or may not be releveant by the time the document arrives at the

Agreed.  But this conversation is needed to scope the problem and
outline the applicability of fallback mechanisms that are available
today and specified in 3GPP.

cameron

---

From: [email-masked]
Date: Sun, 23 Jan 2011 21:46:28 +0200

I partially agree here. However it is important that we address roaming issues. Roaming is one of the major things that differentiates a fixed line deployment from a mobile network deployment. Roaming might be both within the same country and international. From what I see it is a thing that is overlooked quite often. This might be well demonstrated by the fact that Jan for instance has free service worldwide.
Now, if we speak in details regarding applications that do/don't work here (draft-arkko-ipv6-only-experience-02), I believe we should also address the issues related to IPv6 in the mobile networks from all the aspects.

Best,
Roman

---

From: [email-masked]
Date: Sun, 23 Jan 2011 22:02:01 +0200

Cameron,

The fallback suggestion is relevant. However it does apply only to the operators with a PCRF. As was previously noted by Jouni this is an optional function. I tend to believe it won't apply to the majority of deployments today (can't confirm it though with any figures). I would prefer an SGSN functionality instead. I still can see this to be needed on both core and handset sides - this seems to be really hard.
What I still don't understand is, if you are going to the production IPv6 PDP and there is an average customer going into roaming without a prior fallback mechanism, does it imply he will have to figure out he must select another APN to connect? And in the case in 2 years from now for any reason a customer of yours has an IPv6/v4v6 only PDP, to what exactly will it fallback?

Regarding bilateral agreements, yes, they have to be a must. I fully agree with you. Trial and error solution is definitely not something that would make the operator happy.

Best,
Roman

-----Cameron Byrne <[email-masked]> wrote: -----

Date: 01/23/2011 09:12PM

Roman,

Cameron

---

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Sun, 23 Jan 2011 21:17:42 +0100

On 1/23/11 8:14 PM, [email-masked] wrote:
> Hi Jan,
>
> "but this can't be basis for refusing IPv6 PDPcontext in roaming mode."
> - yes, I can't imagine that either from a purely user experience
> perspective. Especially if we project ourselves 2-3 years into the
> future. Obviously from business perspective it makes sense.
>
> I will recheck once again the CDRs with the billing, however I am
> absolutely sure in October 2010 the IPv6 PDP was working in roaming and
> we have received the bills. Was it a coincidence? I have no idea.
> Probably it might make sense to ask the billing folks select randomly 10
> partners and ask them to give a spin for the IPv6 PDP and recheck on
> that on a broader scale.

I have test SIM cards from both mobile operators here that has IPv6 APN 
and I checked with smaller one, if there are was some billing regarding 
IPv6 incoming for that SIM.

>
> On the Slovenian part, how do you plan to solve the billing issues? Do
> you think it should this be more broadly reflected in the existing
> drafts and how?

Well, mobile operators charges roaming based on what bills they receive 
from foreign operators. Local CDRs are only for reference and double 
check. If there's no bill from foreign operator, no fee is charged.

So, we have IPv6 APN and I go around the world. Some operators block 
IPv6 PDP, some are not able to do dual PDP context (for N900), at least 
one of them is charging for IPv6 content, others don't have a clue.

So, basically, what Cameron is saying - if I have no clue -> block.

Wouldn't be better to say "if I have no clue, investigate and fix it?"

/jan

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 23 Jan 2011 21:18:21 +0100 (CET)

On Sun, 23 Jan 2011, [email-masked] wrote:

> And in the case in 2 years from now for any reason a customer of yours 
> has an IPv6/v4v6 only PDP, to what exactly will it fallback?

I'd imagine one has to try to make sure the customer terminals have v6 as 
primary and v4 as secondary (Symbian has this concept anyway). When dual 
stack ones are working, perhaps v4v6, v6, v4 is going to be 1, 2 and 3 on 
the list.

Getting v6 only to work is mostly a billing (and perhaps licensing) 
problem, getting v4v6 to work means lifting the whole infrastructure 
version if I understood correctly.

I would very much like to know what thoughts Apple and Google have on this 
for their future software...

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Sun, 23 Jan 2011 21:20:53 +0100

> Jan,

Beta APNs of our mobile operators (public pilot testing for users) are 
annonced to roamers. Why not? If foreign operator sends a bill, it gets 
charged to customer. Otherwise not :)

> include IPv6, which validates that the end to end billing process will

This might severly speed-up the process of fixing the billing schema 
around the world.

/jan

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 23 Jan 2011 21:23:47 +0100 (CET)

> one of them is charging for IPv6 content, others don't have a clue.

I was told that v6 PDP is an extra license in (some) SGSN, I guess it 
might be the same in RNC. Dual PDP context is definitely an extra license 
in RNC.

So this is going to be different experience all around the world depending 
on what each operator has chosen to implement.

When we initially started looking into this we (IP guys) discovered that 
dual PDP context worked on the "new" GSM/EDGE network we were rolling out, 
it didn't work on the UMTS/HSPA network (when one established the second 
one, it just silently stopped forwarding traffic on both, didn't tear down 
any PDP), and our "old" GSM network didn't support it either (don't 
remember how it behaved).

Much confusion before we figured out why it worked "sometimes" :P

It's a nightmare to try to get this working properly globally, I can 
understand why Cameron wants to disable v6 for roaming.

---

From: [email-masked]
Date: Sun, 23 Jan 2011 22:42:46 +0200

Interesting. I was not aware of the issue regarding billing. As I previously mentioned I had the "luck" to be charged. I was supposing that there will be issues for some operators. Will have to further address that aspect of deployment and recheck with billing and roaming folks.
Yes, I am as well aware of at least 1 operator that blocks IPv6 PDP.

Roman

-----"Jan Zorz @ go6.si" <[email-masked]> wrote: -----

To: [email-masked]
From: "Jan Zorz @ go6.si" <[email-masked]>
Date: 01/23/2011 10:17PM
Cc: [email-masked]
Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05

/jan

---

From: jouni korhonen <[email-masked]>
Date: Sun, 23 Jan 2011 22:49:33 +0200

Hi,

> On 1/23/11 8:14 PM, [email-masked] wrote:

[snip]

> 
> Well, mobile operators charges roaming based on what bills they receive from foreign operators. Local CDRs are only for reference and double check. If there's no bill from foreign operator, no fee is charged.
> 
> So, we have IPv6 APN and I go around the world. Some operators block IPv6 PDP, some are not able to do dual PDP context (for N900), at least one of them is charging for IPv6 content, others don't have a clue.
> 

I know that some operators whose networks I have roamed to using IPv6, have contacted Sonera's (whose SIMs I have been using past year) roaming folks complaining about unknown PDP Types, unknown addresses and such. I have not verified whether those caused any actions but I doubt as such "error cases" are rare compared to other stuff..

Anyway, even if this discussion is interesting, it imho would mostly belong to GSMA something concrete to happen. They have established a task force for IPv6 transition.

- Jouni

---

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Sun, 23 Jan 2011 21:53:30 +0100

On 1/23/11 9:49 PM, jouni korhonen wrote:
> I know that some operators whose networks I have roamed to using
> IPv6, have contacted Sonera's (whose SIMs I have been using past
> year) roaming folks complaining about unknown PDP Types, unknown
> addresses and such. I have not verified whether those caused any
> actions but I doubt as such "error cases" are rare compared to other
> stuff..

Hey,

Yes, if that error rate in unknown PDP type (CDR tickets) is small 
enough it is ignored. Otherwise it might get manually resolved.

The best for operator is to define proper CDR type and get over with it. 
You don't have to change billing for that, just tell tickets normaliser 
and billing what that type is. Easy as that.

/jan

---

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Sun, 23 Jan 2011 22:07:33 +0100

Cameron,

So, if I understand correctly, if your customer goes abroad and tries to 
connect with IPv6 PDP context to your IPv6 APN via roaming, you will 
block it if paper agreements are not updated, even though roaming remote 
operator is not blocking it and may or may not send the bill for this 
IPv6 PDP context, that you can charge to your customer?

Not sure I get the point, why complicate?

If user can get through with PDP, good for him. If he gets billed, good. 
If the bill does never come, even better. If user can't connect through, 
get him to complain and fix this with roaming operator. You as operator 
can't be harmed or your income leaked :)

/jan

---

From: [email-masked]
Date: Sun, 23 Jan 2011 23:08:10 +0200

[email-masked] wrote: -----
To: [email-masked]
From: Mikael Abrahamsson 
Sent by: [email-masked]
Date: 01/23/2011 10:24PM
Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05

/* I understand that as well. However something tells me it would be easier to deal with 100+ roaming partners that are interested to make sure that they don't loose revenue, rather then explain a dozen or so millions of your customers why a service you have just rolled out as commercial should make you learn what is an APN and why IPv6 PDP should not be used in roaming.

---

From: Cameron Byrne <[email-masked]>
Date: Sun, 23 Jan 2011 14:00:01 -0800

> /* I understand that as well. However something tells me it would be easier to deal with 100+ roaming partners that are interested to make sure that they don't loose revenue, rather then explain a…

The expectation is that the handset has the logic to try IPv4 after
IPv6 has failed.  This should not be something the user has to deal
with, the logic is pre-programmed in the handset.  I believe Nokia has
this working today (Teemu?).  My goal is that the users do not know
about ipv4 or ipv6, the service just works.  If i cannot bill over
IPv6, the service is not working and it must be rejected so that a
working and billable ipv4 session can be created.

Regarding GSMA, yes they are the right group.  I am not involved in
GSMA, at this point to launch IPv6 we have to engineer around them and
the policies that are in place.

Regarding SGSN functions, it is the home network that must be
responsible for the end to end billing scheme and is hosting the ipv6
apn, so the  home network must be able to signal if IPv6 across the
roaming network is workable with a PDP reject if it is not workable.
The visited SGSN cannot have this end to end logic.  The feature can
be implemented easily in PCRF or perhaps with some GGSN non-standard
logic.

Cameron

---

From: [email-masked]
Date: Mon, 24 Jan 2011 00:50:13 +0200

-----Cameron Byrne <[email-masked]> wrote: -----
To: [email-masked]
From: Cameron Byrne <[email-masked]>
Date: 01/24/2011 12:00AM
Cc: [email-masked], [email-masked]
Subject: Re: [v6ops] Fwd: New Version Notification for draft-korhonen-v6ops-3gpp-eps-05

/// The discussion is forked at this point. The blocking issue we have discussed is related to the current state of things? And the fact that a service provider must be blocking IPv6 PDP for various reasons, with the major one being the billing.
The fallback mechanisms described are related to R8 and above. The issue is that as long as your GGSN/P-GW is R8, and on my side I have a lower release, from my understanding there is currently no way SGSN can signal you a fallback request as long as I have denied IPv6 PDPs on  my network. The result will be an unhappy customer of yours, and lost revenue for both of us. Am I missing something?
I am not sure either this applies to the current draft and should be placed anywhere, however as long as the draft has a very general overview of current operational aspects of running an IPv6 only PDP, it might make sense to have a look at those "commercially deployed networks by the end of 2010 is nearly non-existent." feedbacks and add the billing issues and free service, along with issues such as lack of business and commercial incentives.
Otherwise I am ok with what and how the draft describes things.

///Jouni, same here. I understand no action will be triggered as the result of this draft, however as long as you have decided to go above a pure description of current state of 3GPP and touched on Operational Aspects, I would say it is a little misleading. To me it looks like the major issue with say roaming today as per this draft is the lack of formal agreements and the possibility of some operators dropping unnecessarily IPv6 user traffic. However, as per today discussion it does not really look like this are the only issues.

///Agreed. It will take a lot of time until everyone has the logic build in the core. The question is what do we to till then?

Roman

Cameron

---

From: jouni korhonen <[email-masked]>
Date: Mon, 24 Jan 2011 00:55:44 +0200

Hi,

> less widely deployed than IPv6 PDP.

One point on IPv4v6 being unknown/unsupported. A pre-rel-8 SGSN does not recognize the PDP Type IPv4v6 and therefore should default to IPv4 (unknown PDP Types _should_ be interpreted as IPv4). PDP Type IPv6 _should_ always be known and not processed by the "unknown PDP Type value handling code" ('_should_' as the reality has been different).

So, would the behavior be illformed if PDP Type IPv6 gets rejected by SGSN instead of being changed to IPv4 e.g. because of IPv6 being a licensable feature??

- JOuni

---

From: <[email-masked]>
Date: Mon, 24 Jan 2011 10:01:31 +0000

> working and billable ipv4 session can be created.

Right, you can configure that on Symbian. 

Generally a 3GPP handset should try to do fallback to IPv4 PDP in case the IPv6 (or IPv4v6) PDP requests result in (any kind of) failure. This failure can, after all, be caused by visited SGSN not supporting IPv6 PDP type (ought not to be very common, but I've understood such do exist).

In the case of well working R8/R9 network the network can instruct handset to do fallback from IPv4v6 PDP to parallel IPv4 & IPv6 PDPs or to IPv6-only PDP or to IPv4-only PDP. 

It would be quite silly functionality on a handset side to bother users about IPv6 PDP activation failures if the reasons are related these deployment challenges and an IPv4 connection could be set up instead. 

After all, there are really no IPv6-only services yet (and those who do provide IPv6-only services also provide tunneling solutions e.g. for cases of accessing via IPv4-only WLAN).

If IPv6-only services were common the handset could maybe show users something like:"You have only limited internet connectivity":-)

Best regards,

	Teemu

---

From: Rémi Després <[email-masked]>
Date: Mon, 24 Jan 2011 15:05:15 +0100

Hi Jouni,

As already said, I find this document extremely useful, and hope it can proceed quickly.

In the section on overlapping IPv4 addresses (8.1), I suggest to add a small clarification.
Its purpose is to remind the relationship that exists between overlapping RFC 1918 IPv4 address spaces and the 6rd of RFC 5969.

As you know, RFC 5969 permits a host to derive its native IPv6 prefix from its assigned IPv4 address, INCLUDING if this address is RFC1918.
This point, which is particularly relevant to the mobile environment where RFC 1918 is already a reality, is unfortunately overlooked. For example, the otherwise very good document of the NIST on Secure Deployment of IPv6 states that, like 6to4, 6rd requires public IPv4 addresses (!). (Ref.: csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf, sec. 6.5.7, 2nd sentence). 

At the end of item 2 of your section 8.1, which says:
"Operators with large subscriber bases have multiple gateways and hence the same [RFC1918] IPv4 address space can be reused across gateways. The IPv4 address assigned to a host is unique within the scope of a single gateway."
ONE COULD ADD, for example:
"If an operator supports 6rd border relays of [RFC5969] in parallel with its gateways, the host can derive from this [RFC1918] IPv4 address its globally assigned IPv6 prefix. (Then, to traverse the local [RFC1918] addressing area, IPv6 packets using this prefix are encapsulated in IPv4 packets)."  

First instances of UEs to benefit from this possibility could  be PCs equipped with with 3G dongles, with their 6to4 module extended to support the RFC 5969 customer-edge function. 
Next, as  some mobile operators start supporting 6rd border relays, it is likely that some PDPv4-capable mobile phones will also become RFC-1918-capable (a simple stateless function).

Best regards,
RD

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 24 Jan 2011 06:28:12 -0800

On Jan 23, 2011 11:10 PM, <[email-masked]> wrote:

> Now, imagine the following. Your operator has rolled out IPv6 service
without telling you about that. As the average user you should not care. You
go to, say, Japan, where they know there might be billing issues and have
blocked the IPv6 PDP instead of looking into their billing issues. Most
likely by that time (1-2 years) we will not be using the R8-R9 with dual
stack worldwide, and even worse, older core network elements worldwide will
still be on R5, R6 without any plans to go further. This folks do have
knowledge of IPv6 PDP most likely, however have no idea about any fallback.
Your handset does not have knowledge of fallback either.
> What happens is that you switch on your phone in Japan and see how it
unsuccessfully struggles to connect to the data network and fails. There
will most likely be no error message, and the only way you can correct
things is by manually selecting an IPv4 APN.
> Now, this IS (not MAY be) broken service for 100% of customers.

Nobody would agree to be breaking roaming.

Roman, the solution I have proposed always provides access to the user since
there is logic in the handset to fall back to ipv4 regardless if the home
network rejects based on policy or visited network rejects based on
features.  I will not roll out features or services that fail as you have
described or features that are not billed. Both the "service" MUST work in
roaming and MUST be billed.  The solution I have proposed does both in all
situations using existing 3GPP functions by attempting IPv6 PDP first and
fallback to IPv4 on failure.  If we cannot do this, it is a road block to
deployment where no IPv6 gets deployed until 100s of roaming partners
contractually agree to support and bill IPv6.... which will take 5+ years.

That is why I want this solution that uses existing 3GPP methods with logic
on the handset to be documented here in this draft.

In summary of this thread.

1.  This draft is good and can benefit from adding a fall back section with
the method i have described.  As the thread has proven, roaming is broken
and operators are at various stages of awareness to this issue.

2.  GSMA is the right place to fix roaming, not the IETF or 3GPP. But, the
GSMA is slow and we must engineer around them in a way that does not close
doors on v6 roaming eventually working.

3.  The service to the user, regardless of v4 or v6, must always work and be
billed.  Neither the operator or user care if the service is v4 or v6 or
v4v6, facebook and google must work.  I have proposed a solution that works
in light of the various constraints of home network policy, visited network
features, and providing a path for IPv6 roaming to work when permitted by
both the home and visited network.

cameron

---

From: Merike Kaeo <[email-masked]>
Date: Tue, 25 Jan 2011 02:43:14 -0800

On Jan 24, 2011, at 6:28 AM, Cameron Byrne wrote:

> > Now, imagine the following. Your operator has rolled out IPv6 service without telling you about that. As the average user you should not care. You go to, say, Japan, where they know there might be billing issues and have blocked the IPv6 PDP instead of looking into their billing issues. Most likely by that time (1-2 years) we will not be using the R8-R9 with dual stack worldwide, and even worse, older core network elements worldwide will still be on R5, R6 without any plans to go further. This folks do have knowledge of IPv6 PDP most likely, however have no idea about any fallback. Your handset does not have knowledge of fallback either. 
> > What happens is that you switch on your phone in Japan and see how it unsuccessfully struggles to connect to the data network and fails. There will most likely be no error message, and the only way you can correct things is by manually selecting an IPv4 APN. 
> Roman, the solution I have proposed always provides access to the user since there is logic in the handset to fall back to ipv4 regardless if the home network rejects based on policy or visited network rejects based on features.  I will not roll out features or services that fail as you have described or features that are not billed. Both the "service" MUST work in roaming and MUST be billed.  The solution I have proposed does both in all situations using existing 3GPP functions by attempting IPv6 PDP first and fallback to IPv4 on failure.  If we cannot do this, it is a road block to deployment where no IPv6 gets deployed until 100s of roaming partners contractually agree to support and bill IPv6.... which will take 5+ years.
> 
> That is why I want this solution that uses existing 3GPP methods with logic on the handset to be documented here in this draft.

I have to agree with Cameron that some fallback logic needs to be documented.   

After thinking about this for a while I keep coming back to 'what have mobile vendors implemented that operators can use?'  Is there shipping code and is there concensus amongst  some of that code or does everyone do it differently? (or is everyone in wait-state?)

Sifting through 23.401 gave me brain drain but the IP address allocation section was somewhat useful.  Having statement like 'a reason cause shall be returned to the UE indicating that only the assigned PDN type is allowed'.  Does anyone more familiar with 3GPP know if the reason causes are explicitly defined somewhere?  If the 3GPP standards do not explicitly define failure modes / notification messages that can cause fallback to IPv4 or if they are ambiguous, then that fact should be documented.    If they are documented, the details should be enumerated in this doc.

Generally I think this draft is useful and would like to see it progress.   

- merike

> 1.  This draft is good and can benefit from adding a fall back section with the method i have described.  As the thread has proven, roaming is broken and operators are at various stages of awareness to this issue.
> 
> 
> 
> 2.  GSMA is the right place to fix roaming, not the IETF or 3GPP. But, the GSMA is slow and we must engineer around them in a way that does not close doors on v6 roaming eventually working.
> 
> 
> 
> 3.  The service to the user, regardless of v4 or v6, must always work and be billed.  Neither the operator or user care if the service is v4 or v6 or v4v6, facebook and google must work.  I have proposed a solution that works in light of the various constraints of home network policy, visited network features, and providing a path for IPv6 roaming to work when permitted by both the home and visited network.
> 
> 
> 
> cameron
> 
> 
> 
>

---

From: jouni korhonen <[email-masked]>
Date: Tue, 25 Jan 2011 14:45:20 +0200

Hi,

> I have to agree with Cameron that some fallback logic needs to be documented.   

There could be some guidance as indicated here:
http://www.ietf.org/mail-archive/web/v6ops/current/msg07022.html

However, I would keep it strictly in limits what we have in the existing TS level toolbox.

> Sifting through 23.401 gave me brain drain but the IP address allocation section was somewhat useful.  Having statement like 'a reason cause shall be returned to the UE indicating that only the ass…

24.008 and 24.302. To be honest, I am sure why I have not given references to these yet ;)

- Jouni

---

From: jouni korhonen <[email-masked]>
Date: Tue, 25 Jan 2011 20:59:49 +0200

On Jan 25, 2011, at 2:45 PM, jouni korhonen wrote:

[snip]

> 24.008 and 24.302. To be honest, I am sure why I have not given references to these yet ;)

24.301 to be exact.. sorry for the typo.

- JOuni

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 26 Jan 2011 14:13:39 +0100 (CET)

On Mon, 24 Jan 2011, Rémi Després wrote:

> In the section on overlapping IPv4 addresses (8.1), I suggest to add a 
> small clarification. Its purpose is to remind the relationship that 
> exists between overlapping RFC 1918 IPv4 address spaces and the 6rd of 
> RFC 5969.

I think this is a good idea to point out in the document.

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 26 Jan 2011 05:23:47 -0800

I disagree.  6rd has been rejected by 3gpp as a transition tool. The scope
of this doc is just summarizing existing 3gpp tools and technologies.

RD ... please respect the agreed scope and take the 6rd sales pitch off
line.

Cb

>> In the section on overlapping IPv4 addresses (8.1), I suggest to add a
small clarification. Its purpose is to remind the relationship that exists
between overlapping RFC 1918 IPv4 address spaces and the 6rd of RFC 5969.

---

From: Rémi Després <[email-masked]>
Date: Wed, 26 Jan 2011 17:16:54 +0100

Le 26 janv. 2011 à 14:23, Cameron Byrne a écrit :

> I disagree.  6rd has been rejected by 3gpp as a transition tool.

I have doubts that it was considered by 3GPP with enough understanding that 6rd works also for operators that assign RFC 1918 IPv4 addresses.
New ideas are sometimes cause of progress.

Someone of Tele2 (not a minor operator), interested in noting that 6rd can be used in some 3GPP configurations is IMHO very significant.

I add Guillaume Leclanche of Swisscom (another operator) as cc, because I know he also has some interest in 6rd/3GPP.

> The scope of this doc is just summarizing existing 3gpp tools and technologies.

The draft "describes the support for IPv6 in 3GPP network architectures." 
Noting that, in 3GPP configurations of sec 8.1 (overlapping IPv4 addresses), 6rd is its own application scope does fit in the document. 
(That is a "recommendation" to use it that would have been off scope, several other solutions being described, and none being recommended.)

> RD ... please respect the agreed scope and take the 6rd sales pitch off line.

It would be easier if you would keep the anti-6rd pitch offline.

And please note that I don't have any product to sell, just the desire to see the IETF promote rapid deployment of native IPv6 addresses.

RD

> >> In the section on overlapping IPv4 addresses (8.1), I suggest to add a small clarification. Its purpose is to remind the relationship that exists between overlapping RFC 1918 IPv4 address spaces and the 6rd of RFC 5969.
> >
> >

---

From: <[email-masked]>
Date: Thu, 27 Jan 2011 07:35:13 +0100

>> I disagree.  6rd has been rejected by 3gpp as a transition tool.

Concerning the 6rd question wrt 3gpp: since you can do it without modifying any of your devices in the mobile access/core network (under verification for us, there might be some legal implications), there is no need to refer to 3gpp. It can even be considered as a userspace service.

Technically, given that we deployed the 6rd machinery for residential accesses, it's a no-brainer to add one port and a few lines of configs on the routers. And then it's up to UE to support it if they want to.
Of course, you need to get the tunnelled traffic just before the IPv4 NAT platform, meaning that if you have distributed your NAT accross the country (that's the case for you Cameron, iirc ?), it makes it more costly.

> I add Guillaume Leclanche of Swisscom (another operator) as cc, because
> I know he also has some interest in 6rd/3GPP.

I'm subscribed to the list already, by the way.

Guillaume

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 27 Jan 2011 07:51:51 +0100 (CET)

On Thu, 27 Jan 2011, [email-masked] wrote:

> Technically, given that we deployed the 6rd machinery for residential 
> accesses, it's a no-brainer to add one port and a few lines of configs 
> on the routers. And then it's up to UE to support it if they want to.

My thinking is exactly the same. I'm advocating that we should support 
(perhaps inofficially) "all" transitional mechanisms, because with DSL, 
ETTH, mobile (both PCs and phones), both for residential and corporate, 
we're doing "everything" and currently there is no single way to 
transition all these technologies. Some will get dual stack, some will get 
native IPv6 only access, some will stay at native IPv4 only. The ones with 
single native protocol access still need access to the other address 
family, so... Tunneling to something that'll fix that. NAT64 is of course 
on the table as well.

If Apple iOS and Android devices are going to support 6RD, we're going to 
support it too.

3GPP might not like tunneling within their tunneling, but personally I 
don't care. For me it's IP regardless.

---

From: <[email-masked]>
Date: Thu, 27 Jan 2011 09:18:26 +0000

Have you measured whether eyeballs of cellular handset users are happier or equally happy when accessing content directly over IPv4 or when through 6RD?

In other words, if a host would implement both 6RD and happy eyeballs, which one would it use for download: IPv4 or IPv6?

In the case IPv6 would not provide equal latency and host would end up using IPv4 (as IPv4 connection would complete first), what would be the point of having 6RD (until the day IPv6-only services emerge)?

Best regards,

Teemu

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of ext Mikael Abrahamsson
> Sent: 27. tammikuuta 2011 08:52
> To: [email-masked]
> Cc: [email-masked]

---

From: <[email-masked]>
Date: Thu, 27 Jan 2011 13:05:58 +0100

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, January 27, 2011 10:18 AM
> 
> Have you measured whether eyeballs of cellular handset users are
> happier or equally happy when accessing content directly over IPv4 or
> when through 6RD?

Oh we've not measured anything in the mobile, it's not deployed yet. Our experience from the residential area shows equal latency provided that the services are connected in the same way in v4 and v6. It can even happen that the v6 connection is faster due to the simple fact that ipv6 servers are less loaded (when services are not dual-stacked at the service provider)

> In other words, if a host would implement both 6RD and happy eyeballs,
> which one would it use for download: IPv4 or IPv6?

Happy eyeballs would be the decisive factor here. 6rd is just providing IPv6 connectivity.

> In the case IPv6 would not provide equal latency and host would end up
> using IPv4 (as IPv4 connection would complete first), what would be the
> point of having 6RD (until the day IPv6-only services emerge)?

The goal is to allow IPv6-only services to emerge. Chicken and egg. It's not solving the v4 exhaustion problem, it's not simplifying the architecture, it's just providing v6 connectivity to whatever UE would support it (Linux > 2.6.33 only today). Any carrier that has already 6rd for residential broadband can simply enable it on the mobile network without a lot of work.

Guillaume

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 27 Jan 2011 11:55:19 -0800 (PST)

Guillaume, 

  I think you have some point but I believe Cameron is right.
What would change it is 23.975. Currently no standard talks about having 6rd BRs 
in 3GPP network.
So you can of course say that Swisscom have plans to deploy 6RD BRs.

No offense to Remi.

Regards,

Behcet

> Concerning the 6rd question wrt 3gpp: since you can do it without  modifying 
>any of your devices in the mobile access/core network (under  verification for 
>us, there might be some legal implications), there is no need  to refer to 3gpp. 
>It can even be considered as a userspace  service.
> 
>accesses, it's a no-brainer to add one port and a few lines of  configs on the 
>routers. And then it's up to UE to support it if they want  to.
> Of course, you need to get the tunnelled traffic just before the IPv4 NAT  
>platform, meaning that if you have distributed your NAT accross the country  
>(that's the case for you Cameron, iirc ?), it makes it more costly.
>

---

From: <[email-masked]>
Date: Thu, 27 Jan 2011 21:16:27 +0100

> From: Behcet Sarikaya [mailto:[email-masked]]
> Sent: Thursday, January 27, 2011 8:55 PM
>
 
I must apologize for something here: I jumped into the thread without checking the subject or the draft itself. In fact I don't really want to influence whatever the draft is saying, I was just giving an additionnal point of view. I let the authors decide how relevant it was and how they want to deal with it.

Guillaume

---

From: Rémi Després <[email-masked]>
Date: Fri, 28 Jan 2011 11:12:44 +0100

Hi Behcet,

> What would change it is 23.975. Currently no standard talks about having 6rd BRs 

AFAIK, no change to 3GPP 23.975 is needed.
It is just noting that 6rd can be combined with 3GPP networks as specified in 3GPP documents.

> No offense to Remi.

There is no offense.
Making constructive proposals is legitimate.
Objecting to them in good faith is legitimate too.

Now, let me explain more.
The concern is that readers of the document are led to believe that significant problems need to be solved BEFORE a dual-stack service can be used across 3GPP infrastructures, which ISN'T TRUE.
Mentioned problems include:
- Pre-Release-8: "Deployment and migration cases described in Section 6.1 for providing dual-stack like capability may mean doubled resource usage in operator's network. This is a major concern against providing dual-stack like connectivity using techniques discussed in Section 6.1."
- Release-8 and after: "If a network knows a mobile may do handovers between Release-8 and pre-Release-8 networks (segment), network will only provide single stack bearers, even if the mobile host requests dual-stack bearers." 

Now, before these problems are solved, a solution happens to be available with 6rd across 3GPP networks: 
- It works with IPv4 bearers, available before and after release-8 
- IPv6 addresses used across IPv6/IPv4 tunnels are native (starting with operator prefixes, no translation needed)

I know that 3GPP has defiance against IP/IP tunnels in UEs, and doesn't propose any in its specifications.
But this doesn't change the fact that:
- There is nothing to change to 3GPP networks to add 6rd support across them,
- This permits rapid deployment of the dual-stack service in 3GPP UEs (phones, PCs with dongles,...)
This is worth knowing, and can mitigate the frustration of having to wait a long time before dual-stack services can be available in mobile devices.

If I miss something, thank you for explaining what.

Regards,
RD

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 28 Jan 2011 09:25:01 -0800

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Rémi Després
> Sent: Friday, January 28, 2011 2:13 AM
> To: Behcet Sarikaya
> Cc: [email-masked]; [email-masked]
> Subject: Re: [v6ops] Fwd: New Version Notification 
> fordraft-korhonen-v6ops-3gpp-eps-05
> 
> Hi Behcet,
> 

Or maybe they should be deploying a better service than 6RD:

http://www.rfc-editor.org/internet-drafts/draft-templin-iron-17.txt

Fred
[email-masked]
 
> The concern is that readers of the document are led to 
> believe that significant problems need to be solved BEFORE a 
> dual-stack service can be used across 3GPP infrastructures, 
> which ISN'T TRUE.
> - Pre-Release-8: "Deployment and migration cases described in 
> Section 6.1 for providing dual-stack like capability may mean 
> doubled resource usage in operator's network. This is a major 
> concern against providing dual-stack like connectivity using 
> techniques discussed in Section 6.1."
> - Release-8 and after: "If a network knows a mobile may do 
> handovers between Release-8 and pre-Release-8 networks 
> (segment), network will only provide single stack bearers, 
> even if the mobile host requests dual-stack bearers." 
> 
> Now, before these problems are solved, a solution happens to 
> be available with 6rd across 3GPP networks: 
> - IPv6 addresses used across IPv6/IPv4 tunnels are native 
> (starting with operator prefixes, no translation needed)
> 
> I know that 3GPP has defiance against IP/IP tunnels in UEs, 
> and doesn't propose any in its specifications.
> This is worth knowing, and can mitigate the frustration of 
> having to wait a long time before dual-stack services can be 
> available in mobile devices.
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 28 Jan 2011 22:05:01 +0100 (CET)

> http://www.rfc-editor.org/internet-drafts/draft-templin-iron-17.txt

I see running code in several products for 6RD right now. What is the 
status of IRON when it comes to actual implementation in software?

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 28 Jan 2011 14:07:20 -0800

Hi Mikael,

A first-version of the code has been announced and
is available for experimentation:

http://www.ietf.org/mail-archive/web/int-area/current/msg02472.html

I have said that I believe IRON to be a better service
than 6RD, and there are several vectors along which I
believe this to be true. But, just to mention one within
this context is that IRON allows multi-access devices
(e.g., a handset with both 3G and WiFi) to connect
through any available links of opportunity and still
retain a stable IPv6 address/prefix - be it as a mobile
host or a mobile router.

Thanks - Fred

> From: Mikael Abrahamsson [mailto:[email-masked]] 
> Sent: Friday, January 28, 2011 1:05 PM
> To: Templin, Fred L
> Cc: [email-masked]
> Subject: Re: [v6ops] Fwd: New Version 
> Notificationfordraft-korhonen-v6ops-3gpp-eps-05
>

---

From: Joel Jaeggli <[email-masked]>
Date: Sun, 30 Jan 2011 12:15:01 -0800

Inline.

On 1/28/11 2:12 AM, Rémi Després wrote:

> Now, let me explain more. The concern is that readers of the document
> are led to believe that significant problems need to be solved BEFORE
> a dual-stack service can be used across 3GPP infrastructures, which
> ISN'T TRUE. Mentioned problems include: - Pre-Release-8: "Deployment
> and migration cases described in Section 6.1 for providing dual-stack
> like capability may mean doubled resource usage in operator's
> network. This is a major concern against providing dual-stack like
> connectivity using techniques discussed in Section 6.1." - Release-8
> and after: "If a network knows a mobile may do handovers between
> Release-8 and pre-Release-8 networks (segment), network will only
> provide single stack bearers, even if the mobile host requests
> dual-stack bearers."
> 
> Now, before these problems are solved, a solution happens to be
> available with 6rd across 3GPP networks: - It works with IPv4
> bearers, available before and after release-8 - IPv6 addresses used
> across IPv6/IPv4 tunnels are native (starting with operator prefixes,
> no translation needed)
> 
> I know that 3GPP has defiance against IP/IP tunnels in UEs, and
> doesn't propose any in its specifications. But this doesn't change
> the fact that: - There is nothing to change to 3GPP networks to add
> 6rd support across them, - This permits rapid deployment of the
> dual-stack service in 3GPP UEs (phones, PCs with dongles,...) This is
> worth knowing, and can mitigate the frustration of having to wait a
> long time before dual-stack services can be available in mobile
> devices.

This really isn't a productive line of reasoning, the fact that over
Ipv4 I can tunnel virtually anything I want is not, a constructive
insight for this document.

Nor is useful advice to operators per-say. Nothing prevents them from
refering to rfc 5969, if they discover a business case for native v6
edges tunneled over ipv4. It appears, for that they may look to wireline
isp or mso (with whom they do compete) for examples where it could we be
appropriate if they so choose (a wireless router is rather different
business case than a handset).

As noted in the abstract and from the outset:

	" This document describes the support for IPv6 in 3GPP network
	architectures."

The authors can and should engage in some editorial proscription what is
an is in not in scope for that discussion.  Your (RD) contribution from
the 24th is noted, but in my opinion not in scope.

I hope that we can close off the discussion of this particular point.

joel

---

From: Rémi Després <[email-masked]>
Date: Mon, 31 Jan 2011 11:21:53 +0100

Hi Joel,

> I hope that we can close off the discussion of this particular point.

Fair enough.
Unless someone revives it, that's a close for me concerning this draft.
(Some other means will have to be used for operators that are interested in quickly offering a dual-stack service to have the 6rd/3GPP approach documented).

Regards,
RD