Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info

[Alexandre Petrescu <[e-mail]>]

Le 20/09/2017 à 21:35, Owen DeLong a écrit :
> 
>> On Sep 20, 2017, at 12:26 PM, Alexandre Petrescu 
>> <[e-mail]> wrote:
>> 
>> 
>> 
>> Le 20/09/2017 à 17:13, Owen DeLong a écrit :
>>>> On Sep 20, 2017, at 10:44 AM, Alexandre Petrescu 
>>>> <[e-mail] 
>>>> <mailto:[e-mail]>> wrote:
>>>> 
>>>> 
>>>> 
>>>> Le 20/09/2017 à 15:35, JORDI PALET MARTINEZ a écrit :
>>>>> Why you try to mix things?
>>>> 
>>>> I dont mix.  You want a unique STdsTRack.  Do you think the 
>>>> place is empty?
>>> I’m not sure where you get “unique”. I think Jordi wants 464XLAT 
>>> moved to Standards track rather than informational. I don’t see 
>>> anything about unique in his request.
>>>> As I said already, there is already IPv6-in-GTP for 
>>>> transitioning and DHCPv6-PD for Prefix Delegation. These are 
>>>> standards.
>>> I guess the question I have for this statement is “why is this 
>>> relevant to whether or not we move 464XLAT to standard?”
>> 
>> BEcause 464XLAT is a transitioning mechanism and IPv6-in-GTP is a 
>> transitioning mechanism too, which is deployed too.
> 
> So what?
> 
> ISIS is a Standard and so is OSPF… both are IGPs. For that matter,
> so is RIPv2.

YEs, and each uses some distinct number, maybe a UDP port number.  They
can work simultaneously on a Router.

But you cant have simultaneously CLAT and DHCPv6-PD on the same client.
  Because CLAT wants that to be a /64 prefix.  It will break when the
client gets a /63.

Moreover, design suggestions from CLAT assume that /64 is sufficient.
That is wrong - /64 is not sufficient.

> There are lots of cases where more than one solution to the same 
> problem becomes a standards track RFC.

But one wont prohibit the other.

CLAT prohibits DHCPv6-PD.

> For that matter, DHCPv6 and SLAAC are both standards. Both do
> address assignment.

Err, I agree.  Yet CLAT does not agree.  CLAT does not rely on DHCP to
get an address.  Why?  IT does not rely on DHCPv6-PD to get a prefix.  Why?

>>>>> CLAT is a transition mechanism. SLAAC or DHCPv6 (-PD) is a 
>>>>> way to provision addresses/prefixes. No sense to mix all 
>>>>> them.
>>>> 
>>>> That's a problem.  You want them to work  together, not to 
>>>> compete.
>>> This makes no sense to me. IMHO, they don’t compete and CLAT can 
>>> work regardless of how the IPv6 address on the client is 
>>> obtained, whether SLAAC, DHCPv6, static, or otherwise.
>> 
>> But you dont want CLAT's IPv6-in-IPv4 together with GTP 
>> encapsulation - that's too many encapsulations.
> 
> True, but I don’t want ISIS and OSPF running on the same links, 
> either.

At some point there is some Gateway that is possible, which runs both
protocols OSPF and ISIS.  But there cant be conversion between CLAT and
DHCP.

> Not sure I understand why this is a relevant topic here. Operators 
> are capable of choosing the standard that best meets their needs
> from multiple standards. Choice is often a good thing. This is an
> example of such a case.

Operators are influenced by Device availability.  If Android is what is
available, then operators want to satisfy this.  If Android does CLAT,
then operators choose to not implement DHCPv6-PD, because DHCPv6-PD is
part of DHCPv6, and because CLAT does not need DHCPv6.

I dont know how to explain this better to you.

Android is very important to operators.

>>>> You want them to have different functions.
>>> CLAT doesn’t have an IPv6 address assignment function so they
>>> do, in fact, have different functions.
>>>> But the function to get a prefix is a unique function.
>>> CLAT doesn’t have anything to do with getting a prefix for IPv6.
>> 
>> But it only works with a /64.  It means it cant work when
>> DHCPv6-PD gives it a /63.
> 
> You’re making no sense here. An interface would still get a /64 from 
> the /63 or /56 or /48 or whatever, so CLAT would still be perfectly 
> capable of operating after the /64 was assigned to the interface.

To be tried, before arguing.

Can you try?

Do you think a WiFi tablet behind a smartphone-on-cellular that uses a
prefix obtained with DHCPv6-PD and re-advertised with RA would be able
to get through that CLAT ok, and talk to IPv4 servers?

If you could try this, then we can have an answer on whether or not I
make sense.

Before that, we cant say CLAT and DHCPv6-PD are ok.

>>>>> Many other transition mechanisms don’t state if SLAAC or 
>>>>> DHCPv6 is used or not, and I think is perfectly correct.
>>>> 
>>>> Most of them are not dynamic in nature anyways, whereas CLAT 
>>>> seems to be.
>>> My understanding is that CLAT is dynamic only on the IPv4 side. 
>>> On the IPv6 side, to the best of my knowledge, it just uses 
>>> whatever IPv6 address is available on the client’s interface(s).
>>>> As long as they dont claim, and they abstain from to 
>>>> dynamically set a prefix on the network they are fine with 
>>>> respect to DHCP-PD.
>>>> 
>>>> But once CLAT gets into statements qualifying which is better 
>>>> SLAAC-vs-DHCP then we have a big problem.
>>> Sigh… I agree that there’s no reason for CLAT to make any such 
>>> statement. If the current CLAT RFC(s) do, then, perhaps we
>>> should argue for cleaning that up as part of the process of
>>> moving towards a standards track RFC, but if that’s what you’re
>>> on about here, then just say that. You’ve wasted multiple
>>> messages talking about completely orthogonal issues where the
>>> above statement is the first clue you’ve provided about what is
>>> apparently your actual concern.
>> 
>> I dont think it's orthogonal.
> 
> It really is.

I tell you it is not.

As long as CLAT does not agree there is DHCPv6-PD and IPv6-in-GTP then
we have little to talk about.

We have a new transition method that appeared just because an OS creator
(Android) is not able, or not willing(?) to push their own suppliers
hardware vendors into implementing forwarding of DHCPv6-PD into their
modems.

Android created a software tool (CLAT) that is totally runnable in the
linux (not in the modem), so it is totally under their control (not
modem) just to avoid the hardware modem problem.  That's not the right
thing to do: the modem has to be fixed.

Android CLAT is also ignoring that IPv6-in-GTP exists (GTP is an IPv4
protocol at 3GPP), because the GTP part happens in the modem, and
Android does not control the modem.

If Android wanted "IPv6-only" devices then the right thing to do is to
create an IPv6 version of GTP, or, even better, get rid of GTP
altogheter.  But that again - it's in the modem.

Nothing of this is orthogonal to CLAT: CLAT does some things because the
modem is forcing it into doing.

Alex