Subject: [v6ops] draft-ietf-v6ops-v6-in-mobile-networks WGLC

From: Fred Baker <[email-masked]>
Date: Sun, 10 Oct 2010 11:00:08 -0700

This is to initiate a two week working group last call of draft-ietf-v6ops-v6-in-mobile-networks. Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list.

We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make.

---

From: Cameron Byrne <[email-masked]>
Date: Sun, 10 Oct 2010 11:37:22 -0700

On Sun, Oct 10, 2010 at 11:00 AM, Fred Baker <[email-masked]> wrote:
> This is to initiate a two week working group last call of
> draft-ietf-v6ops-v6-in-mobile-networks. Please read it now. If you find nits
> (spelling errors, minor suggested wording changes, etc), comment to the
> authors; if you find greater issues, such as disagreeing with a statement or
> finding additional issues that need to be addressed, please post
> your comments to the list.
> We are looking specifically for comments on the importance of the document
> as well as its content. If you have read the document and believe it to be
> of operational utility, that is also an important comment to make.

FYI, some of my comments that have not made it into a new rev yet

http://www.ietf.org/mail-archive/web/v6ops/current/msg05426.html

Cameron
======
http://groups.google.com/group/tmoipv6beta
======

---

From: Rajeev Koodli <[email-masked]>
Date: Sun, 10 Oct 2010 13:25:45 -0700

Hi Cameron,

Yes, I intend to incorporate the outcome of the ML discussion we had in the
next version.
In the meanwhile, folks may provide input as well, as part of this.

Thanks,

-Rajeev

On 10/10/10 11:37 AM, "Cameron Byrne" <[email-masked]> wrote:

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

---

From: <[email-masked]>
Date: Thu, 21 Oct 2010 14:01:23 +0200

Hi,

Section 3.1: it is true that IPv4 PDN on-demand and deferred IPv4 address allocations are "approaches" in theory, but I do not believe their applicability in practice. E.g. what is the likelyhood that popular desktop OSes would suddenly implement that kind of features (isn't the style usually ask DHCPv4 right at interface up and then renew forever)?

Section 3.1: I do not believe cellular handsets will implement DHCPv4 for cellular interfaces. Hence I disagree with:"this may very well change in the future release". Cellular handsets have managed without DHCPv4 since the dawn of packet switched cellular networks. Why on earth they would now start to use DHCPv4 on cellular access at the very twilight of IPv4?

The "additional considerations" is huge, like there is no benefit whatsoever for hosts to do IPv4 on-demand or deferred IPv4 address allocation. Also it is non-trivial, like whether DHCPv4 should be triggered if application binds socket to 127.0.0.1..

I also slightly disagree with this:" On the other hand, in the existing 3G UMTS networks, there is no requirement for an always-on connection". While there is no such requirement from standards bodies, essentially for many devices there is from the end user direction: users want to have IM/Skype/email always on. Should be clarified.

I seem to agree with the conclusions document draws at the end of section 3.1 (there is nothing wrong in doing investigations of on-demand PDN..:)

Best regards,

Teemu

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Fred Baker
Sent: 10. lokakuuta 2010 21:00
To: IPv6 Operations
Cc: [email-masked]; Ron Bonica
Subject: [v6ops] draft-ietf-v6ops-v6-in-mobile-networks WGLC

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 21 Oct 2010 21:17:48 -0700

Hi Teemu,

Thanks for your feedback.

On-demand approaches: we had a good discussion already on the matter, and I
have revised the ID based on that discussion. Yes, there are no handsets
doing this, but we left it open for laptops which may do this. If this is
not a possibility at all, it would remain as an option; at this stage, I am
not sure if we should say it is Not an option at all..

DHCPv4 on cellular handsets: again, the statement is not implying that they
will surely implement DHCPv4. May be you can see what¹s coming in the future
better than I do, but I am going with the option that already exists in 3GPP
standards  PCO to defer address allocation and then using DHCPv4. Again,
this may never be done, but it¹s premature to say it will never be done.
Besides, consider the handsets accessing the EPC via WiFi interface, and not
the cellular interface. Would you say that handsets will not do DHCPv4 over
WiFi as well?

Yes, there are additional considerations, and the ID is not making any
recommendations to use on-demand/DHCPv4.As you point out, the ID is only
pointing out that carriers may consider investigating the on-demand
addressing.
(BTW, on-demand PDN is subject to session inactivity timers, and is not the
same as on-demand IPv4 addressing).

3G always-on: okay, I will add some clarifying text.

Regards,

-Rajeev

On 10/21/10 5:01 AM, "[email-masked]"
<[email-masked]> wrote:

> Hi,
>  
> Section 3.1: it is true that IPv4 PDN on-demand and deferred IPv4 address
> allocations are ³approaches² in theory, but I do not believe their
> applicability in practice. E.g. what is the likelyhood that popular desktop
> OSes would suddenly implement that kind of features (isn¹t the style usually
> ask DHCPv4 right at interface up and then renew forever)?
>  
> Section 3.1: I do not believe cellular handsets will implement DHCPv4 for
> cellular interfaces. Hence I disagree with:²this may very well change in the
> future release². Cellular handsets have managed without DHCPv4 since the dawn
> of packet switched cellular networks. Why on earth they would now start to use
> DHCPv4 on cellular access at the very twilight of IPv4?
>  
> The ³additional considerations² is huge, like there is no benefit whatsoever
> for hosts to do IPv4 on-demand or deferred IPv4 address allocation. Also it is
> non-trivial, like whether DHCPv4 should be triggered if application binds
> socket to 127.0.0.1..
>  
> I also slightly disagree with this:² On the other hand, in the existing 3G
> UMTS networks, there is no requirement for an always-on connection². While
> there is no such requirement from standards bodies, essentially for many
> devices there is from the end user direction: users want to have
> IM/Skype/email always on. Should be clarified.
>  
> I seem to agree with the conclusions document draws at the end of section 3.1
> (there is nothing wrong in doing investigations of on-demand PDN..J
>  
> Best regards,
>  
> Teemu
>  
> 
> finding additional issues that need to be addressed, please post your comments
> to the list.
> 
>  
> 
> We are looking specifically for comments on the importance of the document as
> well as its content. If you have read the document and believe it to be of
> operational utility, that is also an important comment to make.
> 
>

---

From: <[email-masked]>
Date: Mon, 25 Oct 2010 10:57:49 +0200

Rajeev,

I agree that anything may happen in the future:)

Hence IPv4 on-demand could happen, but I don't see it happening at the moment. Hence the draft should be clear that it is something that might be doable, but not something is there out of the box just for network operator to activate.

DHCPv4: for WiFi DHCPv4 is used for sure, of course. But a handset that uses DHCPv4 for WiFi, but not for cellular (as it is point-to-point), needs modifications. These modifications needs justification, IOP testing, and so forth *for no benefit* for the handset. And of course not all handsets come with WiFi, but may come with dual-stack cellular. Justifying introduction of a feature that does not bring benefits but requires effort (money) is oftentimes challenging - even if standard would allow. And AFAIK there is no really significant deployments of DHCPv4 on handsets over cellular that I would be aware.

On-demand PDN connection and on-demand IPv4 addressing: I'm against for both. Tunneling like DS-Lite would be far easier (static private address, and then NAT bindings on-demand).

Best regards,

Teemu

From: ext Rajeev Koodli [mailto:[email-masked]]
Sent: 22. lokakuuta 2010 07:18
To: Savolainen Teemu (Nokia-MS/Tampere); Fred Baker; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-v6-in-mobile-networks WGLC

Hi Teemu,

On-demand approaches: we had a good discussion already on the matter, and I have revised the ID based on that discussion. Yes, there are no handsets doing this, but we left it open for laptops which may do this. If this is not a possibility at all, it would remain as an option; at this stage, I am not sure if we should say it is Not an option at all..

DHCPv4 on cellular handsets: again, the statement is not implying that they will surely implement DHCPv4. May be you can see what's coming in the future better than I do, but I am going with the option that already exists in 3GPP standards - PCO to defer address allocation and then using DHCPv4. Again, this may never be done, but it's premature to say it will never be done. Besides, consider the handsets accessing the EPC via WiFi interface, and not the cellular interface. Would you say that handsets will not do DHCPv4 over WiFi as well?

Yes, there are additional considerations, and the ID is not making any recommendations to use on-demand/DHCPv4.As you point out, the ID is only pointing out that carriers may consider investigating the on-demand addressing.
(BTW, on-demand PDN is subject to session inactivity timers, and is not the same as on-demand IPv4 addressing).

Regards,

-Rajeev

On 10/21/10 5:01 AM, "[email-masked]" <[email-masked]> wrote:
Hi,

Best regards,

Teemu

We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make.
________________________________
_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 25 Oct 2010 09:24:24 -0700

Teemu,

I am not sure how it is an issue to run DHCPv4 over WiFi and not use DHCPv4
over cellular.
AFAICT, iPhone seems to be doing it today; please correct me otherwise.

Thanks,

-Rajeev

On 10/25/10 1:57 AM, "[email-masked]"
<[email-masked]> wrote:

> Rajeev,
>  
> I agree that anything may happen in the futureJ
>  
> Hence IPv4 on-demand could happen, but I don¹t see it happening at the moment.
> Hence the draft should be clear that it is something that might be doable, but
> not something is there out of the box just for network operator to activate.
>  
> DHCPv4: for WiFi DHCPv4 is used for sure, of course. But a handset that uses
> DHCPv4 for WiFi, but not for cellular (as it is point-to-point), needs
> modifications. These modifications needs justification, IOP testing, and so
> forth *for no benefit* for the handset. And of course not all handsets come
> with WiFi, but may come with dual-stack cellular. Justifying introduction of a
> feature that does not bring benefits but requires effort (money) is oftentimes
> challenging  even if standard would allow. And AFAIK there is no really
> significant deployments of DHCPv4 on handsets over cellular that I would be
> aware. 
>  
> On-demand PDN connection and on-demand IPv4 addressing: I¹m against for both.
> Tunneling like DS-Lite would be far easier (static private address, and then
> NAT bindings on-demand).
>  
> Best regards,
>  
> Teemu
>  
>  
> 
> have revised the ID based on that discussion. Yes, there are no handsets doing
> this, but we left it open for laptops which may do this. If this is not a
> possibility at all, it would remain as an option; at this stage, I am not sure
> if we should say it is Not an option at all..
> 
> standards  PCO to defer address allocation and then using DHCPv4. Again, this
> may never be done, but it¹s premature to say it will never be done. Besides,
> consider the handsets accessing the EPC via WiFi interface, and not the
> cellular interface. Would you say that handsets will not do DHCPv4 over WiFi
> as well?
>

---

From: <[email-masked]>
Date: Mon, 25 Oct 2010 22:59:46 +0200

Hi,

Remember the host-based vs. network-based mobility discussions?

I am essentially using the "network-based" camp's argumentation herein: modifying large host population (in time!) to support IPv4 on-demand (especially with DHCPv4) on cellular access is an infeasible approach and the dual-stack using network should just implement some flavor of NAT instead.

Actually I think the reason is even stronger with the IPv4 on-demand. With DSMIP6 a host actually gains benefits (like mobility always and not just within an administrative domain), but with IPv4 on-demand, or with DHCPv4 on cellular, the host gains nothing.

Best regards,

Teemu

P.S. We don't use iOS but you do network elements. Maybe you have packet captures to share?

Sent: 25. lokakuuta 2010 19:24

Teemu,

I am not sure how it is an issue to run DHCPv4 over WiFi and not use DHCPv4 over cellular.
AFAICT, iPhone seems to be doing it today; please correct me otherwise.

Thanks,

-Rajeev

On 10/25/10 1:57 AM, "[email-masked]" <[email-masked]> wrote:
Rajeev,

Best regards,

Teemu

Hi Teemu,

Regards,

-Rajeev

Best regards,

Teemu

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 25 Oct 2010 15:00:41 -0700

Teemu,

I remember well, and am not suggesting anything host-specific.

You stated ³But a handset that uses DHCPv4 for WiFi, but not for cellular
(as it is point-to-point), needs modifications. ³

I pointed that iPhone already does that today. I don¹t know what you call
this  host modification etc. But, IMHO, it does not matter what you call;
it¹s already out there.

The ID is not stating any requirement for the hosts, but brings the
possibilities and the associated issues.

Regards,

-Rajeev

On 10/25/10 1:59 PM, "[email-masked]"
<[email-masked]> wrote:

> I am essentially using the ³network-based² camp¹s argumentation herein:
> modifying large host population (in time!) to support IPv4 on-demand
> (especially with DHCPv4) on cellular access is an infeasible approach and the
> dual-stack using network should just implement some flavor of NAT instead.
>  
> Actually I think the reason is even stronger with the IPv4 on-demand. With
> DSMIP6 a host actually gains benefits (like mobility always and not just
> within an administrative domain), but with IPv4 on-demand, or with DHCPv4 on
> cellular, the host gains nothing.
>  
> Best regards,
>  
> Teemu
>  
> P.S. We don¹t use iOS but you do network elements. Maybe you have packet
> captures to share?
>  
>

---

From: "Heatley, Nick " <[email-masked]>
Date: Wed, 27 Oct 2010 14:15:36 +0100

Hi Rajeev,

An interesting and potentially useful draft, thanks.

To refine the draft I would kindly ask you to consider the 4 items
below:

Section 3.1

The document states:

>In other words, the IETF's recommended model of dual-stack IPv6 and
IPv4 networks is readily applicable to mobile networks with the support
for distinct APNs and the ability to carry IPv6 traffic on PDP/PDN
connections.

1. I see an additional barrier to dual stack for mobile - the PDP
resource overhead in RAN and Core from two PDPs (separate PDP for v4 and
v6). I think you mention this but do you regard it as a barrier or not?

There is the resource aspects from the number of sessions supported, and
also there may be licensing costs, a commercial barrier to dual stack
for the mass market.

This has a bearing on the Operator's IPv6 introduction strategy.

2. Mitigation to this resource overhead could be  

i) Implement IPv6-only-bearer, as per section 3.3 

Or (ii) to couple the dual-stack-bearer with LTE (Release 9 network)

Can both these points be mentioned where dual stack is recommended, to
balance the argument?

3. I would like to propose a specific sub section in Section 3 covering
the advantages of "IPv6 in the LTE network" (with more information on
the combined v4v6 pdp/pdn connection).

Combined v4v6 pdp/pdn connection

-          LTE introduces the v4v6 combined PDP which is supported by a
release 8 terminal.

-          The LTE Release 9 network allows the v4v6 combined PDP to be
maintained consistently in LTE and when falling back to 3G/2G.

-          This removes the overhead of two PDPs in 2G/3G, as well as
LTE.

-          Given an operator's LTE coverage may start in major urban
areas and take time to rollout nationally, and the dual PDP resource
issues (as above), then a LTE Release 9 network can work optimally with
dual stack. Depending on timescales, some mobile operators may use LTE
as the vehicle for enabling a dual stack bearer network.

[Note that some people prefer "LTE" rather than "4G" as it can be argued
that only LTE-Advanced (Release 10) is truly 4G by the standards
definition. I leave that one up to you :-)]

4. Finally if you are releasing a draft on "IPv6 in mobile networks" I
would request you include something on IP version for packet voice
meaning specifically Voice in LTE networks. I would expect this to fall
under the LTE section. Otherwise I would argue this document is "v6 for
mobile internet" :-)

Is it intentional that packet voice is an omission? I appreciate that
some discussions here are not yet concluded. However IP version is very
relevant and a steer here could help the industry.

I am happy to send you my thoughts on packet voice and IP addressing
issues.

Just my 2 cents for your consideration!

Best Regards,

Nick Heatley

NOTICE AND DISCLAIMER
This e-mail (including any attachments) is intended for the above-named person(s).  If you are not the intended recipient, notify the sender immediately, delete this email from your system and do not disclose or use for any purpose.  
 
We may monitor all incoming and outgoing emails in line with current legislation. We have taken steps to ensure that this email and attachments are free from any virus, but it remains your responsibility to ensure that viruses do not adversely affect you. 

Everything Everywhere Limited
Registered in England and Wales
Company Registered Number: 02382161
Registered Office Address: Hatfield Business Park, Hatfield, Hertfordshire, AL10 9BW