Subject: [v6ops] draft-korhonen-v6ops-3gpp-eps - where to go from here

From: Fred Baker <[email-masked]>
Date: Tue, 4 Jan 2011 17:28:07 -0800

Question for the assembled throng: What do people want to see happen in draft-korhonen-v6ops-3gpp-eps? In the SurveyMonkey data, about 37% felt it was reasonable to work on but should be an individual effort, and about 58% were willing to take it as a working group draft. Several people said they had comments and would post them to the list.

Please post comments on the list, and if only to tell us how to proceed.

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 4 Jan 2011 21:19:01 -0800

I think it should be taken in as a WG doc, it is good for the folks in
this group to be involved with 3GPP model.  The draft does need a lot
of work and does not represent the current world as i see it.  If the
draft cannot be fixed, it should be abandoned.  It may be best if the
document simply explains the 3GPP model in IETF terms and stays away
from service deployment recommendations.  If it must make service
deployment recommendations, then it should reference the joint
3GPP-IETF in meeting in SF where the conclusions was that DS and
IPv6-only were the correct paths for moving forward, not just DS.

Notes on the draft:

1.  In the introduction section "However, the support for IPv6
   in commercially deployed networks is nearly non-existent."  This is
now not true.  Verizon Wireless in the USA has production IPv6 for
their LTE network.  Furthermore, others like T-Mobile USA have
substantial beta deployments ... but the crux of the issue is that
Verizon is big, they have it deployed for every LTE device they sell
in their stores today and support.  I suggest changing the wording to
something more representative of the world I see. Perhaps use :
"However, deployment have been limited in the last 10 years with GSM
and UMTS.  LTE represents a fresh deployment and new challenges to be
solved.  The IPv4 exhaust issue and relevance of always-on any-to-any
communication is driving the real business need for IPv6 and IPv6 is
actively being deployed in some of the first and largest LTE
networks."

2.  In section 6.1, this statement is made without any qualification
or explanation: "The approach of having parallel IPv4 and IPv6 type of
PDP contexts
   open is not optimal, because two PDP contexts require double the
   signaling and consume more network resources than a single PDP
   context.  However, these costs and complexities are lesser than what
   other transition solutions would incur"

Please explain  this cost and complexity comparison you have done,
reverse it, or remove it.  I have a pretty clean real money case for
single stack + NAT being the same cost regardless of IPv4-only or
IPv6-only and NAT44 or NAT64.  Dual stack still requires NAT44 and
double the PDP in this context.

3.  In section 7 "This can be achieved by upgrading the network to support IPv6
   while continuing to maintain IPv4 legacy.  Dual-stack capability in
   the network and devices for the foreseeable future at least is a
   pragmatic solution."  I agree with the first sentence, but not with
the 2nd.  These 2 sentences are not as tightly coupled as it sounds.
And, perhaps the detail is that the operator can support IPv4-only
services to support existing users and can support IPv6-only services
for new users / services.  But, i don't see the benefit to users (they
don't care, as long as facebook works), operators (who are not willing
to pay 2x PDP or extra support costs), or the internet at large (as
long as v4 works, no change/investment/support for v6 on the
applications end).

4.  Section 8

"Direct host to host connectivity becomes
   complicated, unless the hosts are within the same private address
   range pool and/or anchored to the same gateway, referrals using IP
   addresses will have issues and so forth"

Yep.

 "Standard NAT44 functionality
       enables the communication between hosts that are assigned the
       same IPv4 address but belong to different zones, yet are part of
       the same operator domain."

Nope.  Remeber, VoLTE?  And many LTE providers are staying v4 only.
This works well with IMS?  Or can i only call people in my region who
are also on 4G and on ipv6? Also, sometimes mobile operators do
billing and authentication based on the IP address, so there's snag
when there is one billing system and 2x ipv4 = 10.99.88.88 users.

5.  section 8.3, you may want to reference the happy eyeballs and AAAA
whitelisting work as challenges to supporting a dual-stack network

6.  section 11 " The authors believe that transitioning to IPv6 in
3GPP networks can
   be achieved without disruption to legacy devices, networks and
   services only by taking a dual-stack approach to deployment."  Have
you seen Jari's work on IPv6-only?  Or the T-Mobile USA beta
ipv6-only?  My concern here is that you are saying the dual-stack
services is the "only" way, which is clearly not the case.    I highly
object to this wording as it is simply not true and i run a network
that is testament to that.

Further "Enabling IPv6
   connectivity in the 3GPP networks by itself will provide some degree
   of relief to the IPv4 address space as many of the applications and
   services can start to work over IPv6 right away."

How does my web page loading over IPv6 on a dual-stack phone provide
"relief to the IPv4 address space"?  I still am using an IPv4 address.
 Please elaborate.

And, "However without
   comprehensive testing of different applications and solutions that
   exist today and are widely used, for their ability to operate over
   IPv6 PDN connections, an IPv6 only access would cause disruptions.
   Hence we recommend adopting the dual-stack approach to IPv6
   transition in 3GPP networks."

Raj, you have the phone that is IPv6-only for 9 months now.  Do the
comprehensive testing and let us know.  This statement directly
contradicts Jari's work on Symbian in
draft-arkko-ipv6-only-experience.

Cameron

On Tue, Jan 4, 2011 at 5:28 PM, Fred Baker <[email-masked]> wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 5 Jan 2011 08:14:45 +0100 (CET)

> draft-arkko-ipv6-only-experience.

My opinion right now is that we're going to have to do it all to support 
different type of mobile devices.

IPv6 only access with:
NAT64+DNS64, NAT64+BIH, 4RD+NAT44

IPv4 only access with:
6RD+NAT44

Dual PDP (since we can control that within our own network): The bad thing 
here is that the failure mode we've seen so far on dual PDP context is 
that both contexts just stop forwarding traffic, they don't get torn down 
when you roam into a network that doesn't support it.

IPv6 only access doesn't work in real life. It does work for quite a few 
things on Symbian and fewer other things on Maemo and I guess also few 
things on Windows 7 (if looking at the whole program ecosystem). I have 
yet to test Windows 7, but since Skype doesn't work, you have a very 
important application right there.

I do agree that dual stack by means of dual PDP context is really hard in 
real life to do in the current mobile ecosystem. It can be compared to 
deploying a solution based on /25 IPv4 space in todays Internet routing 
system, it works for some, but you won't be able to talk to everybody 
because of general /24 filtering.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 5 Jan 2011 05:09:53 -0800

> different type of mobile devices.

+1.  As many have noted, there is no silver bullet, including
dual-stack.  Some methods fit better than others for different, users,
apps, OSs, operators.  Trade-off's MUST be made.

> here is that the failure mode we've seen so far on dual PDP context is that
> both contexts just stop forwarding traffic, they don't get torn down when
> you roam into a network that doesn't support it.
>
> things on Windows 7 (if looking at the whole program ecosystem). I have yet
> to test Windows 7, but since Skype doesn't work, you have a very important
> application right there.
>

---

From: Merike Kaeo <[email-masked]>
Date: Wed, 5 Jan 2011 09:20:22 -0800

It seems to me to be a useful document for updating what was described in RFC 3574 - Transition Scenarios for 3GPP Networks.  Would this doc be considered an update and obsolete RFC 3574?

I would hope any deployment recommendations and/or description be fully vetted by the folks deploying in these environments...some comments have already been started by operators which is great to see.

I am mildly wondering about the intersection between this draft and with draft-ietf-v6ops-v6-in-mobile-networks-03.txt.  The latter doesn't seem to be referenced at all and I would hope that the text in this new draft would not have any conflicts with existing working group document.  I haven't had time to compare in detail but will offer some comments later in the week if still warranted.

Main jist - I would encourage this work to become working group item.

- merike

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 5 Jan 2011 09:46:29 -0800

> to test Windows 7, but since Skype doesn't work, you have a very important

Here is some IPv6-only win7 testing i did about 9 months ago

Common application http://www.youtube.com/watch?v=czDvrNKKzpU

Common web sites http://www.youtube.com/watch?v=czDvrNKKzpU

I don't use Skype, so i did not test it.  This is obviously not
comprehensive testing, but i wanted to share some of the basic
capabilities.  Regarding Skype, we cannot let applications hold back
progress.  IMHO, we cannot let "a good service" be the enemy of a
"perfect service".

Cameron

---

From: Rémi Després <[email-masked]>
Date: Wed, 5 Jan 2011 19:01:08 +0100

Hi all,

1.
Le 5 janv. 2011 à 08:14, Mikael Abrahamsson a écrit :
> ...
> My opinion right now is that we're going to have to do it all to support different type of mobile devices.
> 
> IPv6 only access with:

+1

Yet, this isn't the current 3GPP view.
Consequently, IMHO:
- EITHER draft-Korhonen proceeds as purely informational on 3GPP current architecture,
- OR it proceeds with authors' opinion on what to do => it should tell HOW to offer DS service to mobile devices.  

2.
> Dual PDP (since we can control that within our own network): The bad thing here is that the failure mode we've seen so far on dual PDP context is that both contexts just stop forwarding traffic, they don't get torn down when you roam into a network that doesn't support it.
> 
> IPv6 only access doesn't work in real life. It does work for quite a few things on Symbian and fewer other things on Maemo and I guess also few things on Windows 7 (if looking at the whole program ecosystem). I have yet to test Windows 7, but since Skype doesn't work, you have a very important application right there.
> 
> I do agree that dual stack by means of dual PDP context is really hard in real life to do in the current mobile ecosystem. It can be compared to deploying a solution based on /25 IPv4 space in todays Internet routing system, it works for some, but you won't be able to talk to everybody because of general /24 filtering.

If these 3 points do describe constraints to be faced, they can be summarized as:
- v4PDP + v6PDP has significant problems
- v6PDP + NAT64 has significant limitations for mobile devices that need the DS service
- v4v6PDP is significantly hard in real life 
Then, the solution that remains for rapid DS service in mobile hosts is:
- v4PDP + 6rd 
(With my apologies to those who don't like my comments about what 6rd does)

For a early v4PDP + 6rd trial, AFAIK:
- Some host OS supporting 6rd should soon be available (at least with Linux Ubuntu at Telecom Bretagne). 
- Using these in PCs having 3G USB keys should be feasible
- These mobile PCs can then have a DS service with any operator that
  . supports at least one 6rd relay
  . then configures the 6rd option in its DHCP server(s).

For production, adding 6rd support in DS-capable phones shouldn't be difficult if there is the will.

Regards,
RD

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 5 Jan 2011 12:08:50 -0800 (PST)

To my knowledge, this draft (and also 

draft-sarikaya-v6ops-prefix-delegation
) is in AD-sponsored track. 

Of course, reviews are always welcome.

Behcet

----- Original Message ----
> From: Cameron Byrne <[email-masked]>
> To: Mikael Abrahamsson <[email-masked]>
> Cc: IPv6 Ops WG <[email-masked]>; [email-masked]
> Sent: Wed, January 5, 2011 11:46:29 AM
> Subject: Re: [v6ops] draft-korhonen-v6ops-3gpp-eps - where to go from here
>

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 06 Jan 2011 09:54:02 -0800

Hi,

> IPv6-only were the correct paths for moving forward, not just DS.

I agree, that the draft is useful with explanation of the 3GPP model and its
working. I also think that the draft scope should be just that, and not
involve any deployment recommendations etc.

Regards,

-Rajeev

---

From: james woodyatt <[email-masked]>
Date: Thu, 06 Jan 2011 10:19:47 -0800

> Question for the assembled throng: What do people want to see happen in draft-korhonen-v6ops-3gpp-eps? In the SurveyMonkey data, about 37% felt it was reasonable to work on but should be an individ…

I have no well-formed opinion about whether the working group should adopt the draft, but I do think it's worth hammering on it until it's ready for publication.  The information it contains doesn't appear to be presented as concisely anywhere else.

I think I still have some questions that the draft should answer, but I need to read it more carefully to be sure they aren't already answered adequately.  If the working group adopts the draft, then I'm prepared to pitch in and help sort its editorial issues.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: <[email-masked]>
Date: Thu, 6 Jan 2011 17:42:34 +0000

We are working on revising the draft based on comments received.
I do agree that the I-D is intended to provide an understanding of the
3GPP EPC architecture and the operating model and not recommend any
approach for transition.

-Raj

---

From: jouni korhonen <[email-masked]>
Date: Thu, 6 Jan 2011 21:25:19 +0200

Right, agree as well on the scope. It is no problem to strip out parts that currently try to go beyond explaining the 3GPP model and its working.

- Jouni

---

From: Jan Zorz <[email-masked]>
Date: Fri, 07 Jan 2011 00:07:18 +0100

+1

I think that's good document. I'm willing to contribute, will talk to authors.

Jan Zorz
go6.si