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

<teemu.savolainen@nokia.com> Fri, 16 April 2010 14:10 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 DDAB93A6901 for <ietfarch-v6ops-archive@core3.amsl.com>; Fri, 16 Apr 2010 07:10:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.936
X-Spam-Level:
X-Spam-Status: No, score=-4.936 tagged_above=-999 required=5 tests=[AWL=-0.441, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 LSR63U2VbgLj for <ietfarch-v6ops-archive@core3.amsl.com>; Fri, 16 Apr 2010 07:10:12 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6FF1028C0D9 for <v6ops-archive@lists.ietf.org>; Fri, 16 Apr 2010 07:07:52 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1O2mBK-000GyE-DP for v6ops-data0@psg.com; Fri, 16 Apr 2010 14:06:06 +0000
Received: from [192.100.122.230] (helo=mgw-mx03.nokia.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from <teemu.savolainen@nokia.com>) id 1O2mBG-000Gwq-8H for v6ops@ops.ietf.org; Fri, 16 Apr 2010 14:06:02 +0000
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o3GE5bnr003559; Fri, 16 Apr 2010 17:05:54 +0300
Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Apr 2010 17:05:50 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Apr 2010 17:05:45 +0300
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Fri, 16 Apr 2010 16:05:45 +0200
From: teemu.savolainen@nokia.com
To: cb.list6@gmail.com
CC: rkoodli@cisco.com, v6ops@ops.ietf.org
Date: Fri, 16 Apr 2010 16:05:42 +0200
Subject: RE: New Version Notification for draft-koodli-ipv6-in-mobile-networks-02
Thread-Topic: New Version Notification for draft-koodli-ipv6-in-mobile-networks-02
Thread-Index: AcrdZvfXjmWqCHaaT7SFQTXxrgWmlQABYenA
Message-ID: <18034D4D7FE9AE48BF19AB1B0EF2729F59D5E2FC5B@NOK-EUMSG-01.mgdnok.nokia.com>
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>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 16 Apr 2010 14:05:45.0769 (UTC) FILETIME=[E8A39990:01CADD6D]
X-Nokia-AV: Clean
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Hi,

My suggestion is to provide hosts with a (private) IPv4 address always when dual-stack type of connection has been established. There are several documents that describe solutions for solving private IPv4 address shortage on the network side (DS-Lite, GI-DS-Lite, L2NAT and probably more).

In the discussion during the winter the conclusion was, afaik, that host changes should be avoided.

Mandating hosts to change its address allocation method used in an access technology, and even to include IPv4 on-demand (with deferred DHCPv4 and also "quick" release) is a significant host change, imho. Even in the case handset has DHCP for WiFi (and not all handsets have WiFi). Even more in the split-UE case, where DHCP is running on a separate device (such as laptop).

Best regards,

Teemu

> -----Original Message-----
> From: ext Cameron Byrne [mailto:cb.list6@gmail.com]
> Sent: 16. huhtikuuta 2010 16:16
> To: Savolainen Teemu (Nokia-D/Tampere)
> Cc: rkoodli@cisco.com; v6ops@ops.ietf.org
> Subject: Re: New Version Notification for draft-koodli-ipv6-in-mobile-
> networks-02
> 
> 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.
> 
> 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
> >>
> >
> >
> >