Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - rant

[Alexandru Petrescu <[e-mail]>]

Le 18/02/2015 13:56, Metzler, Dan J a écrit :
>
>
>> -----Original Message----- From: Alexandru Petrescu
>> [mailto:[e-mail]] Sent: Sunday, February 15,
>> 2015 1:56 PM To: Metzler, Dan J; [e-mail];
>> Heatley, Nick Cc: [e-mail] Subject: Re: [v6ops] I-D Action:
>> draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT
>>
>> On 13/02/2015 22:36, Metzler, Dan J wrote:
>>> Hi,
>>>
>>>> -----Original Message----- From: v6ops
>>>> [mailto:[e-mail]] On Behalf Of Alexandru
>>>> Petrescu Sent: Friday, February 13, 2015 10:59 AM To:
>>>> [e-mail]; Heatley, Nick Cc: [e-mail]
>>>> Subject: Re: [v6ops] I-D Action:
>>>> draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9
>>>> 464XLAT
>>>>
>>> <snip/>
>>>>
>>>>> Some operators are seeing CLAT as critical because they don't
>>>>> want to have a service disruption compared to IPv4 when
>>>>> IPv6-only connectivity is provided to their customers.
>>>>
>>>> I agree about the criticality of IPv4 apps when IPv6-only
>>>> connectivity is in place.
>>>>
>>>> But why should there be IPv6-only connectivity in place today
>>>> for the masses?
>>>
>>> Because whether it exists today, or not, that's the goal we are
>>> working toward.  It's far too late to be designing things based
>>> on some assumption that IPv6-only connectivity doesn't have to
>>> actually work anyway.  The ultimate goal is IPv6-only
>>> connectivity for the masses, and if we make no other assumptions,
>>> we ought to be able to start with the assumption that at least
>>> works to all internet connected IPv6 endpoints.
>>
>> Yes, I agree with the goal.  But I think it is too early to think
>> IPv6-only for the masses.
>
> In this group, it is too late not to think IPv6-only for the masses.
>  We past that point long ago.  Certainly, we aren't ready to stop
> thinking about transition technologies.

I think IPv6-only for the masses is too early to plan for.  Most
notably I dont think linux platforms(2.x to 3.x) ready to turn
off their IPv4 stacks.

YEs, there could be a geeky Android out there not segfaulting upon IPv4
disable, but we're way away from devices sold at large which dont
support IPv4.  Nobody will buy a tablet without IPv4 an stack - it's 
perceived as a miss-feature: can't connect to all networks.  It's as 
when I naïvely bought a smartphone without WCDMA thinking I'd never go 
to Korea, or that 4G solves it - it's no and no.

Transition technologies: yes, but maybe we can learn from some of the
past IPv4-IPv6 transition methods.

Maybe the easiest transition is to offer both IPv4 and IPv6 to end user
and let her decide when to switch.

>> I talk to a number of professional deployers and the majority is
>> still questioning the necessity of IPv6.
>
> I think you're suggesting that, since the majority of a few selected
>  "professional deployers", are still questioning the necessity of
> IPv6, that v6ops should not be worried about IPv6 only actually
> working?

Right, no.  I suggest v6ops activities are well on track.  I disagree 
though with thinking an IPv6-only access is necessary today.

> That doesn't make much sense. Our job at this point should be: 1)
> Make sure IPv6 works, and works better than IPv4.

Agree with point 1.  But disagree to making it better than IPv4 (other
than the larger address space).

There is some time spent in migrating features from IPv6 back
to IPv4.  There is also resistance from IP deployers due to IPv6 being
so different than IPv4.

> (If we don't do this first, then there is no reason for number 2.) 2)
> Make sure there is a good and effective working long term migration
> path to get from IPv4 only to IPv6 only.
>
> Without number 1, number 2 is not a viable option that I'm aware of.

I agree with you about the long term towards IPv6.  It's just the near
term that I disagree with.  I think one is safe to plan for some good
years of side-by-side IPv4-IPv6 access.

>>>> Nobody but some ultra-geek do this IPv6-only today.
>>>
>>> Ouch!
>>
>> Sorry, didnt mean to hurt anyone's feelings.  Geek is said with
>> respect.
>>
>> One must be ultra-geek to turn off her IPv4 stack.  Have you
>> tried?
>>
>>>> Even if the operator's network is IPv6 only, it should have
>>>> means to translate between v4 and v6 at its edges, such as to
>>>> show pure IPv4 and pure IPv6 t user.
>>>>
>>>
>>> I think we should stay away from assumptions like this.
>>
>> But 464xlat/clat is already doing translation. Except that it does
>>  translation only on one edge and on the terminal.  It should have
>>  done translation on both edges and let the terminal free of not
>> implementing CLAT.
>>
>>> If no one is going to mandate that all ISPs MUST provide IPv6
>>> connectivity, (and that hasn't happened yet), then it doesn't
>>> seem like we can make assumptions about where the translation
>>> needs to happen.
>>
>> I agree with you, IPv6 must be recommended.  But there several
>> types in which to bring IPv6 in.  Some are smoother than others.
>>
>> In the case I struggle with, in the current situation (CLAT
>> required on the terminal), I will be forced to recommend and use an
>> IPv4-only APN type, and leave IPv6 for a few years later.
>>
>> The end users will not even have a chance to see an RA coming from
>>  the network and their Windows end-systems naturally self-configure
>>  an address.
>>
>> The end user does not want IPv6, the backend system does not want
>> to provide IPv6.  Only the cellular system imposes IPv6.
>
> What do you mean by backend system?

Clouds, server farms, services.  (and yes, I know google youtube
facebook are on IPv6).

> The end user usually does not "want" IPv4, but we still gave it to
> them.  That the end user "does not want IPv6" is a questionable
> statement in light of the current state of the internet.  The end
> user really wants the Internet, and that's as far as it goes.  The
> typical end user is unaware of what they want at layer 3, because
> they tend not to look below layer 7.  The reality is, either the end
>  user wants to run out of IPv4 addresses, or they want IPv6.  (They
> just might not be aware of it yet.)

Ok, yes, yes... But.

If by the 'current state of the internet' you mean IPv4 address exhaust...

IPv4 addresses exhaust unless they're NATted.  One wouldn't argue that
IPv6-only is a solution to IPv4 exhaustion; or that 464xlat/clat is such
a solution for that matter.   I suggest neither is a solution to IPv4
exhaust: IPv6-only does not accommodate IPv4 apps and 464xlat/clat
deployments I am aware of use non-routable IPv4 addresses.  In that
sense, NAT is a solution to IPv4 exhaust, as before.

If IPv6-only/464xlat/clat was offering a publicly routable IPv4 address
to the smartphone's AF-dependent literal-using applications - then I
would not complain about IPv6-only/464xlat/clat.

Alex


>
>>
>> Alex
>>
>>>
>>> <snip/>
>>>
>>> Thanks,
>>>
>>> - Dan (part time ultra-geek I guess)
>>>
>>>>
>>>>
>>>> _______________________________________________ v6ops mailing
>>>> list [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>>
>> --- L'absence de virus dans ce courrier électronique a été vérifiée
>> par le logiciel antivirus Avast. http://www.avast.com
>