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 21/09/2017 à 04:20, Owen DeLong a écrit :
[...]

>> 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.
> 
> Again, I don’t entirely buy this because if the client gets an IA_PD 
> /63, I’m not sure CLAT cares.

Yes, not sure either, but have you tried?

Do you understand this 'root' problem?


[...]

>> Moreover, design suggestions from CLAT assume that /64 is sufficient.
>> That is wrong - /64 is not sufficient.
> 
> If you feel strongly about this, publish an ID obsoleting the current 
> CLAT specification and arguing for more than a /64.

There is an Analysis of /64 boundary RFC, osme proposal to the Addr 
Archi RFC which has strong opposition too from, err, you will see.

That's done.

>>> 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.
> 
> Continuing to say this doesn’t make it true.

There is truth in trying: try it.

>>> 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?
> 
> Neither do any Android phones, nor do the vast majority of systems that 
> I administer.
> 
> What’s your point?
> 
> IMHO, no protocol should _RELY_ on DHCPv6 or DHCPv6_PD, but, instead, 
> they should all function regardless of the mechanism by which addresses 
> are assigned.

I can agree with the principle, but in practice the situation may have 
another light.

> Arguably you could say that insisting a link is a /64 is 
> not valid and you might have a case there, but even there, I think for 
> some things, that ship has sailed.

Ship sailed...

> 
>>>>>>> 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.
> 
> Right, because CLAT doesn’t assign addresses and DHCP doesn’t provide a 
> gateway between IPv4 and IPv6.
> 
> That’s sort of like saying there can’t be conversion between RIP and TELNET.
> 
> It’s true, but I’m not sure why it matters.

On Android, what makes HTTP more successful than Telnet to access remote 
computers is that you dont need root access to run HTTP.

You dont need root access for CLAT to run, but you do for DHCPv6-PD.

>>> 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.
> 
> Sorry, but this is absurd logic.
> 
> The reason operators choose not to implement DHCPv6-PD in 
> android-centric networks is because Android doesn’t support DHCPv6. That 
> is a completely orthogonal issue to whether android supports 
> 464XLAT/CLAT or not.

Android says CLAT is sufficient.

Please look at the public discussion on public URL about DHCPv6, CLAT, 
and everything.

> 
> That would be sort of like saying “Because my linux system is running 
> Quagga and speaks OSPF, it can’t handle SSH sessions.”
> 
> The lack of DHCPv6 on Android devices is (as near as I can tell) largely 
> a religious position taken by Lorenzo.
> 
> This situation existed long before CLAT and if they chose to put DHCPv6 
> clients on Android, it wouldn’t eliminate their ability to run CLAT.

I agree.

But I think they dont.

> 
>> I dont know how to explain this better to you.
> 
> I’m not the one who seems to be misunderstanding the situation.
> 
>> Android is very important to operators.
> 
> And? Android supports 464XLAT. It’s not going to support DHCPv6 until 
> someone convinces Lorenzo (or someone above him at Alphabits) to do so. 
> Support could be added without breaking 464XLAT/CLAT, so I really don’t 
> see why you are connecting these two things other than perhaps in your 
> mind they are connected because Lorenzo was also one of the early 
> backers of 464XlAT.

BEcause Lorenzo makes same argument against DHCPv6.

Were Lorenzo (because you name him) to agree DHCPv6 is necessary on 
Android, then many things would change, including CLAT.

If CLAT works ok with DHCPv6-PD, then I have no problem with CLAT.

If CLAT works ok with only 64share (and not with DHCPv6-PD), then I 
disagree with both CLAT and 64share.

That will bring  you even further back, but that's the way it is.


> 
>>>>>> 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?
> 
> I don’t see why not. Admittedly, I don’t bother to try, I have enough 
> IPv4 addresses on the networks I run that dual stack is a perfectly 
> viable solution and the idea of all of these silly variants of the NAT 
> shell game just turn my stomach. However, I recognize the real need in 
> the real world for them.
> 
> Now, a counter-question… Do you think a WiFi tablet behind that same 
> smart-phone-on-cellular that gets its address via static or some other 
> address assignment mechanism would have the same difficulty? If not, why 
> not?

I think the smartphone will get a prefix from the operator that is very 
different than the prefix that is assigned on the smartphone interface. 
The tablet will use that prefix to form an address.  The smartphone has 
a different address and prefix on its CLAT-supporting interface.  I am 
afraid there is some non-working there.

I did not try it.  I am stumbling on this 'root' feature.

Make CLAT StdsTrack - but does it work with DHCPv6-PD?

> 
>> 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.
> 
> You’re making the bold assertion that CLAT fails if the /64 on the 
> interface is assigned by some mechanism other than 64share. As far as 
> I’m concerned, it’s not my responsibility to prove that assertion false, 
> it’s up to you to provide some factual basis behind the assertion and/or 
> some proof that it is valid.

That's about the effort - who does the effort.  I did some part of it: I 
shown DHCPv6-PD is possible on cellular, that modems have some problem, 
and that there is a 'root' problem.  All these are questions that were 
raised on the list.

I think it is up on the CLAT proponents to move on StdsTrack to answer 
to questions like: is CLAT compatible with existing protocols.

Its not sufficient to say it's orthogonal.  That does not mean anything.

> 
>> Nothing of this is orthogonal to CLAT: CLAT does some things because the
>> modem is forcing it into doing.
> 
> Probably now is the time for us to (as usual) agree to disagree…
> 
> Regardless of the reason CLAT was created, it is now widely deployed and 
> very popular. It is a pragmatic solution. Deploying it does not break 
> any of the protocols that are near and dear to your heart.

It does not work with DHCPv6-PD.


  It provides
> an optional way to deal with circumstances where those protocols are not 
> the best choice for the operator regardless of the reasons behind that.
> 
> Would it be nice to get the modem vendors to fix the silicon? Sure. But 
> reality check here… They’re not going to retroactively replace the 
> silicon in billions of smart phones even if they can be convinced to 
> correct future chipsets. As such, the “right thing” is completely 
> infeasible in the real world.

I disagree.  Some look at this seriously.



> 
> So again, I say that fixing the chipsets, DHCPv6, and IPv6-in-GTP are 
> all orthogonal to this discussion because there is no inherent conflict 
> in deploying CLAT on the phone, it simply provides yet another option 
> for accomplishing a similar task.
> 
> In fact, unless I misunderstood IPv6-in-GTP, 464XLAT solves a different 
> problem than IPv6-in-GTP in that IPv6-in-GTP provides (roughly) the 
> cellular equivalent of a 6in4 tunnel rather than providing a mechanism 
> for an IPv6-only device to speak to an IPv4 device at the far end.

For some reason, I think we discussed this already.

Alex

> 
> Owen
>