[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New Version Notification for draft-koodli-ipv6-in-mobile-networks-02
Hi Teemu,
On 4/16/10 7:05 AM, "teemu.savolainen@nokia.com"
<teemu.savolainen@nokia.com> wrote:
> 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).
Well, those are options for some. But the main point here is that IPv4
address is tied to the corresponding PDN/PDP. The network may want to
reclaim the PDN/PDP due to session timers. So, when the PDN/PDP is deleted,
so is the IP address. IMO, we cannot disallow this.
>
> 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).
As I mentioned in a previous email, Deferred IP address allocation is
specified for use in LTE. If 3G handsets do not do DHCP, it does not mean
LTE handsets should not, right?
Thanks,
-Rajeev
>
> 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
>>>>
>>>
>>>
>>>