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

[Cameron Byrne <cb.list6@gmail.com>]

On Fri, Apr 16, 2010 at 7:27 AM, jouni korhonen <jouni.nospam@gmail.com> wrote:
> Hello,
>
> Thanks for the updated draft. I have few comments and questions regarding Section 3.1.
>
>   (typically a /64) at the time of connection establishment, and an
>   IPv4 address is assigned only on-demand (e.g., when an application
>   binds to an IPv4 socket interface).  This is feasible on the same
>   (dual-stack) PDN in LTE networks (with short DHCP lease times), or
>   with on-demand IPv4 PDNs.  On-demand IPv4 PDN and address management
>   can be effective in conserving IPv4 addresses; however, such a
>   management could have some implications to how the PDN and addresses
>   are managed at the MN.
>
> Does the on-demand IPv4 PDN management here imply establishing and tearing down IPv4 PDN connections based on the IPv4 use? If so, how does the stack figure out when to tear down the IPv4 PDN connection? Such dynamic IPv4 PDN connection handling probably has somewhat undesired signaling load effect against the core network.
>

My view on this is that NAT44 and NAT64 are equal costs.  So, i deploy
NAT64 and my UE is IPv6-only.  If there were a scenario where
DNS64/NAT64 does not work (IPv4 literal, IPv4-only App, ...), then the
IPv4 PDP is establish.  As i mentioned before, IPv6-only handset is a
very acceptable user experience using today's technology and
standards.  What Rajeev is suggesting helps with some corner cases (at
least that is how I would use it).

Cameron


> Regarding delayed IPv4 address management. I have my concerns on "split UE" cases, where the host OS runs DS stack and the  3G/4G terminal acts as a modem. How would the (DHCP-based) delayed address management work in that case without modifying the host OS stack? Typically the host OS stack would try to configure the IPv4 address also immediately.. of course one can do tricks on the driver level and fake addresses toward the host OS but..
>
> IMHO the draft should discuss side effects and constrains in more detail related to the on-demand IPv4 PDN connection and address management before suggesting them as a general guideline.
>
> - Jouni
>
> On Apr 16, 2010, at 1:04 AM, Rajeev Koodli wrote:
>
>>
>> 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
>>
>>
>
>
>