Re: New Version Notification for draft-koodli-ipv6-in-mobile-networks-02

joel jaeggli <joelja@bogus.com> Mon, 19 April 2010 04:04 UTC

Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F8053A699C for <ietfarch-v6ops-archive@core3.amsl.com>; Sun, 18 Apr 2010 21:04:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.058
X-Spam-Level:
X-Spam-Status: No, score=-2.058 tagged_above=-999 required=5 tests=[AWL=0.541, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjY34hl4OPhm for <ietfarch-v6ops-archive@core3.amsl.com>; Sun, 18 Apr 2010 21:04:36 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5E7A53A6808 for <v6ops-archive@lists.ietf.org>; Sun, 18 Apr 2010 21:04:35 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1O3i7w-0009vd-L8 for v6ops-data0@psg.com; Mon, 19 Apr 2010 03:58:28 +0000
Received: from [2001:418:1::81] (helo=nagasaki.bogus.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from <joelja@bogus.com>) id 1O3i7t-0009vK-H1 for v6ops@ops.ietf.org; Mon, 19 Apr 2010 03:58:25 +0000
Received: from [192.168.1.135] (c-98-234-104-156.hsd1.ca.comcast.net [98.234.104.156]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id o3J3wEMB061015 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 19 Apr 2010 03:58:15 GMT (envelope-from joelja@bogus.com)
Message-ID: <4BCBD4D7.6050808@bogus.com>
Date: Sun, 18 Apr 2010 20:58:15 -0700
From: joel jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: Cameron Byrne <cb.list6@gmail.com>
CC: teemu.savolainen@nokia.com, rkoodli@cisco.com, v6ops@ops.ietf.org
Subject: Re: New Version Notification for draft-koodli-ipv6-in-mobile-networks-02
References: <20100413233059.8DA253A6923@core3.amsl.com> <C7ECDB88.52D4%rkoodli@cisco.com> <18034D4D7FE9AE48BF19AB1B0EF2729F59D5E2FA16@NOK-EUMSG-01.mgdnok.nokia.com> <x2tbcff0fba1004160615ka06b9ce8t73a80f84858eb3fe@mail.gmail.com>
In-Reply-To: <x2tbcff0fba1004160615ka06b9ce8t73a80f84858eb3fe@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Mon, 19 Apr 2010 03:58:16 +0000 (UTC)
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

On 4/16/2010 6:15 AM, Cameron Byrne wrote:
> On Fri, Apr 16, 2010 at 2:25 AM,<teemu.savolainen@nokia.com>  wrote:
>> Hi Rajeev, all,
>>
>> I'm worried about the on-demand DHCP based address allocation descriptions herein.
>>
>> Majority of 3GPP devices do not implement DHCP at all today for 3GPP access, because it is optional and gives very little when compared to mandatory PPP-like address allocation during bearer establishment procedures.
>>
>> Introduction of DHCP for significant host population (to get statistical savings) just for the deferred IPv4 address allocation feature does not sound right thing to do for me.
>>
>> We should be adding IPv6 features to hosts, not IPv4 features.
>>
>
> Teemu, many handsets have DHCP for  the WiFi.  I agree with you in
> principle somewhat (many transition steps add IPv4 functions), but i
> believe the reality makes your point moot in many relevant cases.  I
> strongly feel the transient on-demand IPv4 connection that  Rajeev has
> suggested is very useful in IPv4 constrained environments that require
> always-on connectivity (IMS ...).  I believe the on-demand IPv4
> address can help address the IPv4 literal issue that is described in
> draft-wing-behave-http-ip-address-literals, similar to a
> dial-on-demand function... the handset always has a path to IPv4, but
> the PDP is only setup when a packet needs to be transmitted.

What happens when the device actually requires that the ipv4 databearer 
be in use all the time? Insofar as I have experience that case is not 
particularly rare, and likely to get less so rather than more.

Given that the ipv4 problem described in 3.1 and 3.2 exists today and is 
addressed using existing techniques there doesn't seem to be that much 
to solve really for the v4 case. certainly nothing that I'd want to 
design new software for handsets and mngs to address.

> Prior to release 7, i believe this is easy to control (give back ipv4
> quickly) since we can configure the handset to terminate idle IPv4 PDP
> quickly while the IPv6 is always up.  Once to release 8 and we have
> dual-stack bearers, i am not sure the best way to address the
> on-demand use of a transient IPv4 address.
>
> Would you suggest the EPS bearer be re-established / re-negotiated to
> deliver the IPv4 and IPv6 addresses over PCO- IE?  Is it possible to
> send / request PCO-IE without dropping the original EPS bearer?
>
> Cameron
>
> ps.  This type of discussion is why the WG should accept this draft
>
>
>
>> Best regards,
>>
>> Teemu
>>
>>> -----Original Message-----
>>> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On
>>> Behalf Of ext Rajeev Koodli
>>> Sent: 16. huhtikuuta 2010 01:05
>>> To: v6ops@ops.ietf.org
>>> Subject: FW: New Version Notification for draft-koodli-ipv6-in-mobile-
>>> networks-02
>>>
>>>
>>> Hello folks,
>>>
>>> I was asked at the Anaheim meeting to clarify the intended audience for
>>> this
>>> ID, which I have done in the Introduction; this document can be a
>>> useful
>>> reference for service providers and network designers.
>>> This ID does not propose any new protocols or suggest any new protocol
>>> work.
>>>
>>> I also got a good review from Mohamed Boucadier (thanks!) which I have
>>> addressed.
>>>
>>> It seemed there was good interest that this ID is useful.
>>>
>>> So, Chairs: how do we proceed?
>>>
>>> Thanks,
>>>
>>> -Rajeev
>>>
>>> http://tools.ietf.org/html/draft-koodli-ipv6-in-mobile-networks-02
>>>
>>>
>>>
>>> ------ Forwarded Message
>>> From: IETF I-D Submission Tool<idsubmission@ietf.org>
>>> Date: Tue, 13 Apr 2010 16:30:59 -0700 (PDT)
>>> To: Rajeev Koodli<rkoodli@cisco.com>
>>> Subject: New Version Notification for
>>> draft-koodli-ipv6-in-mobile-networks-02
>>>
>>>
>>> A new version of I-D, draft-koodli-ipv6-in-mobile-networks-02.txt has
>>> been
>>> successfully submitted by Rajeev Koodli and posted to the IETF
>>> repository.
>>>
>>> Filename:  draft-koodli-ipv6-in-mobile-networks
>>> Revision:  02
>>> Title:   Mobile Networks Considerations for IPv6 Deployment
>>> Creation_date:  2010-04-14
>>> WG ID:   Independent Submission
>>> Number_of_pages: 15
>>>
>>> Abstract:
>>> Mobile Internet access from smartphones and other mobile devices is
>>> accelerating the exhaustion of IPv4 addresses.  IPv6 is widely seen
>>> as crucial for the continued operation and growth of the Internet,
>>> and in particular, it is critical in mobile networks.  This document
>>> discusses the issues that arise when deploying IPv6 in mobile
>>> networks.  Hence, this document can be a useful reference for service
>>> providers and network designers.
>>>
>>>
>>>
>>> The IETF Secretariat.
>>>
>>>
>>>
>>> ------ End of Forwarded Message
>>>
>>
>>
>>
>