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

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

On Fri, Apr 16, 2010 at 10:30 AM, Rémi Després <remi.despres@free.fr> wrote:
>
> Le 16 avr. 2010 à 18:02, Cameron Byrne a écrit :
>
>> On Fri, Apr 16, 2010 at 8:27 AM, Rémi Després <remi.despres@free.fr> wrote:
>>>
>>> Le 16 avr. 2010 à 16:46, Koodli, Rajeev a écrit :
>>>
>>>> the "Standards Track" part is an error - this is an Informational ID (please see previous versions for instance)
>>>
>>> I see.
>>> Thanks for the clarification.
>>>
>>>
>>>> Regarding the IPv6-only mobile deployment section: it is an important consideration for mobile networks. The relevant section is discussing what are the issues, specifically roaming and applications impact.
>>>
>>>
>>>> It is not proposing anything new here, but highlighting the considerations.
>>>
>>> Well, I didn't understand it quite this way (with the two following sentences in particular), so that the text can probably be improved in this respect.
>>> -"This is a realistic scenario today where an LTE deployment may be IPv6-only, whereas a roamed 3G UMTS network may not offer IPv6 PDN"
>>> -"In summary, IPv6-only deployments should be encouraged."
>>>
>>> Also, when you say:
>>>  "However, by taking the initiative to introduce IPv6-only for the
>>>  newer MNs, the mobile networks can significantly reduce the demand
>>>  for private IPv4 addresses."
>>> It doesn't take into account the following:
>>> - if a dual-stack MN only connects to IPv6-enabled servers (like an IPv6-only that consumes no public IPv4 address space at all), it doesn't consume any public-IPv4 address space.
>>> - It has a NET10 IPv4 address, which gives access to a NAT44, but never uses it.
>>>
>>> In summary, that is *dual-stack deployments* that must be "encouraged" today.
>>> In my understanding, this is the current IETF stand, and should remain so until more experience is gained.
>>
>> Disagree.
>
> Thanks for the debate then, hopefully constructive.
>

yes, always.

>>  Any solution that is dependent on IPv4 is not easily
>> achievable for a larger network operator. Large mobile operators do
>> not have enough private or public space to operate the networks they
>> have now.
>
>> Overlapping spacing introduces several challenges,
>> especially in an IMS environment.
>
> Agreed.
> However, like 6rd permits to easily offer native IPv6 on IPv4-only infrastructures (see RFC 5569), the same principle reversed permits to offer public IPv4 (with restricted port sets) on IPv6-only infrastructures.
>

As others have pointed out, changes to requirement or technology on
handsets is highly discouraged. So, yet another protocol will not gain
much support unless the value is substantially better than what is
provided today. Furthermore, the IPv6 need is now a pressing
operational and business continuity issue.

>
>> Dual-stack also cost 2x the price
>> in pre-release 8 networks (per PDP pricing...)
>
> It doesn't need to.
>

Renegotiating vendor contracts of that magnitude is above my pay grade :)

But regardless, of how you pay for capacity, 2x the PDP session will
result in 2x the hardware since you will be doing 2x the signalling
and 2x the mobility events within the mobility core.


>> The IETF-3GPP joint meeting recognized this is supporting the
>> IPv6-only + v6v4 interworking model
>>
>> http://www.3gpp.org/ftp/workshop/2010-03-01_IPv4-to-IPv6_with-IETF/Docs/IPW100060.zip
>
> Thanks for the reference.
> It's indeed useful to know.
>
>> Dual-stack would have been great if this were 2005, but the dual-stack
>> ship has sailed.  It's too late.
>
> Maybe if mobile operators have already made up their mind.
> I believe however that many operational problems if IPv6-only is proposed with NAT64s are still overlooked.
> In particular:
> - The Port-Control Protocol that is under study in Softwire and considered for NAT64s is an example of additional complexity that has to be considered.

I have seen it cited that roughly 50% of mobile operators do NAT44
today.  My network does NAT44 today, so NAT64 is not an additional
complexity for me since the function and resulting quality of
experience is similar to NAT44. In fact, since NAT64 does not have to
be "on path", i can leverage the DNS64 to drive more effective load
balancing and high availability schemes.

> - If hosts cannot always distinguish whether IPv6 addresses of remote hosts are IPv6 end-to-end or are subject to NAT64 translations, the effect is in my understanding still hard to predict.
>

Like above, assuming that your only option is NAT44 (with BOGON or
multiple instances of 10/8 on the inside) for IPv4 and that NAT64 is a
similar quality of experience to NAT44, i believe it is unlikely a
subscriber will be materially impacted. There are indeed cases where
NAT64 and IPv6-only don't work perfect with today's standards, but
what Rajeev is suggesting with on-demand IPv4 may help with that.


>
>> The easiest path forward is IPv6-only
>> given that devices are always,  the only IPv4 space available is BOGON
>> or overlapped with SBCs and complicated internal NATs, communication
>> is any to any, connected devices grow exponentially,
>
> (I didn't get the meaning of this sentence.)
>

Sorry, i rushed this last email between meetings and did not do a good
job editing.

My point is that for a mobile operator that does NAT44 today,
IPv6-only with NAT64 is the simplest path forward.  This is because:

1.  More and more devices are alway-on.  Before, handsets would only
have IP address when you go to a web site or actively transfer data.
Now, handsets are always connected to mobile network and always
transmitting data on your location, sycn your email and contacts,
register with SIP / IMS ...  This is a big change for the dimensioning
of the network.

2.  Mobile operators have deployed both BOGON and overlapping IP
address space, both are bad and substantially limit peer to peer (e2e)
communication.  In case of BOGON, the operator needs to change IP
address space periodically as the space they are using is claimed by
its rightful owner.  That is a risk to be managed.  In the re-using IP
address space case, any mobile to mobile communication (voice, video,
p2p) must go through some device that can disambiguate the addresses
based on location and state, like a SIP B2BUA or Session Border
Controller.  This is costly and complicated to operate.

3.  Users are increasingly communicating end to end  IMS / SIP services.

4.  As everyone know, mobile subscribers are growing very quickly

All of the above make the case that work-arounds with IPv4 are poor
investments.  The smart money is being spent to bring IPv6 primary
services in quickly since the pay back time on the investment is as
long as you use IPv6, not the life of a NAT444 CGN or other
infrastructure.  Any technology that has a lead time of 18 months to
develop and other 2 years to tune in production cannot meet the
investments requirements since they will be obsolete too soon.   As we
agree, IPv6 content will be here very soon.


>> and major content
>> is going IPv6 in the next year (Google is there now, others are on
>> their way).  I predict by this time next year i have AAAA for over 50%
>> of the bandwidth my customers use.
>
> That's certainly a good expectation, which I share to a good extent (I use native IPv6 in my home-office, deployed by Free since December 2007).
>
>> On a personal note, for the last 2 months i have been IPv6-only with
>> NAT64 on my 3G mobile (work and persona) devices for the last 2 months
>> with not negative impacts.
>
> That's good indeed (although of course it doesn't prove that others, with different terminals and/or applications, would also be fully satisfied with IPv6-only)
>

IPv4-only service won't go away any time soon.  IPv6-only will be
specific handsets and services that will certainly be regression
tested to make sure the user experience is acceptable.  For people
where IPv6-only + NAT64 works, we should encourage them to use it.
For people that it does not work, we can have products / services for
that too.


> Regards,
> RD
>
>
>
>
>>
>> Cameron
>>
>>>
>>> Regards,
>>> RD
>>>
>>>
>>>>
>>>> Regards,
>>>>
>>>> -Rajeev
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: owner-v6ops@ops.ietf.org on behalf of Rémi Després
>>>> Sent: Fri 4/16/2010 6:55 AM
>>>> To: Fred Baker
>>>> Cc: IPv6 Operations
>>>> Subject: Re: New Version Notification for  draft-koodli-ipv6-in-mobile-networks-02
>>>>
>>>> Hi Fred,
>>>>
>>>> The informational part of the draft very clear and IMHO extremely valuable.
>>>> Like Mohamed, I therefore support, like Mohamed in particular, that it can become an "informational" WG document.
>>>>
>>>> As far as the proposal that "an LTE deployment may be IPv6-only" is concerned (sec. 3.3), it is more than informational (which BTW is consistent with the Standards Track intended status of the current draft).
>>>> It could therefore IMHO be part of another draft, but should not be included in the informational WG document.
>>>>
>>>> (About this particular proposal, I rather think that LTE mobile access networks should be all made dual stack, for some undetermined time, while those of previous generation should continue to evolve so as to become all dual stack.)
>>>>
>>>> Regards,
>>>> RD
>>>>
>>>>
>>>> Le 16 avr. 2010 à 02:08, Fred Baker a écrit :
>>>>
>>>>> I would like feedback from the working group. Rajeev would like to make this a working group document. Is there support?
>>>>>
>>>>> On Apr 15, 2010, at 3:04 PM, 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
>>>>>>
>>>>>>
>>>>>
>>>>> http://www.ipinc.net/IPv4.GIF
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
>