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

Cameron Byrne <cb.list6@gmail.com> Mon, 19 April 2010 05:08 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 6A8193A6AA4 for <ietfarch-v6ops-archive@core3.amsl.com>; Sun, 18 Apr 2010 22:08:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.188
X-Spam-Level:
X-Spam-Status: No, score=-0.188 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
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 dbzw8FbrCUVO for <ietfarch-v6ops-archive@core3.amsl.com>; Sun, 18 Apr 2010 22:08:51 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BE0D73A6895 for <v6ops-archive@lists.ietf.org>; Sun, 18 Apr 2010 22:08:50 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1O3j9o-000KYU-G9 for v6ops-data0@psg.com; Mon, 19 Apr 2010 05:04:28 +0000
Received: from [209.85.217.224] (helo=mail-gx0-f224.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <cb.list6@gmail.com>) id 1O3j9k-000KY6-KS for v6ops@ops.ietf.org; Mon, 19 Apr 2010 05:04:24 +0000
Received: by gxk24 with SMTP id 24so2531248gxk.18 for <v6ops@ops.ietf.org>; Sun, 18 Apr 2010 22:04:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=NBxOMQZT0JyKkZZwLVlSUqr6fV6hvmkLg8GYgo5fLxk=; b=xy8tZ1a7ttT+3yoL/mB22vgSZ52KdDPUgMl2ZfwTFAQ+MGSzd+tb8BMAU6dWfNqFoI mQ8+wUdossvJbA8jMUh+q8l8mcinJR1V27pEzRKIa5h9Lhncf2XHxoih9MYsLMldDBev NtBn3YQUd4zOJ82ALaRXgE/jcMvKAL7Cz3K9g=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VWhzBbwq4Bxxl8NMAoG00ozES+9tVquFsO8BWVWS07qhCWFhZnHoICmWeROP6xaI// VY6jcATFqecW9jlWB64+U69UDdZR2sAGbgPbcz6bnMFhPotfZZOWkvz0dEG4g/E/1Hwy eHqnA1q5grC3Xp4wBzWiHYznCx6J0HqGHpMDI=
MIME-Version: 1.0
Received: by 10.150.215.2 with HTTP; Sun, 18 Apr 2010 22:04:23 -0700 (PDT)
In-Reply-To: <4BCBD4D7.6050808@bogus.com>
References: <20100413233059.8DA253A6923@core3.amsl.com> <C7ECDB88.52D4%rkoodli@cisco.com> <18034D4D7FE9AE48BF19AB1B0EF2729F59D5E2FA16@NOK-EUMSG-01.mgdnok.nokia.com> <x2tbcff0fba1004160615ka06b9ce8t73a80f84858eb3fe@mail.gmail.com> <4BCBD4D7.6050808@bogus.com>
Date: Sun, 18 Apr 2010 22:04:23 -0700
Received: by 10.150.193.16 with SMTP id q16mr5395268ybf.324.1271653463271; Sun, 18 Apr 2010 22:04:23 -0700 (PDT)
Message-ID: <t2vbcff0fba1004182204t64fd57b0o615455ac0323ac89@mail.gmail.com>
Subject: Re: New Version Notification for draft-koodli-ipv6-in-mobile-networks-02
From: Cameron Byrne <cb.list6@gmail.com>
To: joel jaeggli <joelja@bogus.com>
Cc: teemu.savolainen@nokia.com, rkoodli@cisco.com, v6ops@ops.ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

On Sun, Apr 18, 2010 at 8:58 PM, joel jaeggli <joelja@bogus.com> wrote:
> 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.
>

I strongly believe in Occum's Razor.  If an IPv4 data bearer is
"required", then it is required and should be established.  If a
"service" to a subscriber can be designed where applications are IP
version agnostic (Symbian is a good example, i have not found anything
IP version specific yet in Ovi), the case should NOT be that an IPv4
bearer is required.  The only thing required is the bearer that
enables the communication to be established.  A relevant example that
Rajeev cites is the roaming scenario, where an IPv6-only service in
the home network now needs to be an IPv4-only service in the visited
network that only supports IPv4 PDP type (no dual-stack service here
either, just v4).  Keep in mind, the handset is alway dual-stack
capable, but the service can be defined as one bearer at a time
depending on if the user is roaming or not, or perhaps 2 bearers if
the user "requires" a transient IPv4 bearer to deal with an IPv4
literal or a legacy IPv4-only applications.  If the service the
customer needs is IPv4 alway-on, then the customer should buy an IPv4
service.  IPv4 services will not go away any time soon.

If the application and OS are IP version agnostic AND there is a
suitable protocol translation scheme like DNS64/NAT64 AND there is
legitimate reason to believe that a substantial amount of content will
become available via IPv6, then it just might make sense to encourage
IPv6-only (the better term is IPv6-primary) deployments.

Thanks,
Cameron

> 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
>>>>
>>>
>>>
>>>
>>
>
>