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]>]

In this email, the important part are at the beginning.  The rest is 
repetition.

Le 21/09/2017 à 00:29, Ca By a écrit :
[...]

> IPv6-in-GTP is a transport mechanism with mobility. It does not help an 
> ipv6-only node communicate with an ipv4 internet.

It helps to transport the IPv6 packets through the intermediary network 
that is IPv4-only.  The intermediary network is made of modem, base 
station, SGW and PGW.  The linux part is not the modem.
> 
> That said, my deployment includes both IPv6-in-GTP and 464xlat 
> simulatenously

So, you have 2 encapsulations, right?

[...]
>     But you cant have simultaneously CLAT and DHCPv6-PD on the same client.
> 
> 
> I do not agree,  Please state what is structurally preventing this.  
> RFC6877 specifically calls for using dhcpv6-pd

RFC is one thing, but many implementations block some RFCs.

What structurally prevents this is that there are very numerous Android 
devices.

Each of these Android device has a structural risk if it wants to 
'root'.  If the 'root' operation fails you can structurally through it 
out a window.

Android refuses to include DHCPv6-PD client in the main OS (public URL 
available upon request).  Because of that, one has to 'root' the device 
in order to include it.

Second, the modem part of many Android devices block DHCPv6.  Private 
indication of the dhcpv6 file blocking it is available upon request.  It 
is confidential information.  The rights are to Qualcom and Balong.

On another hand, I would like you to ask me what structurally does _not_ 
prevent Android to run DHCPv6-PD.  If you did, I would tell you this: 
the operator does not oppose running DHCPv6-PD (some already run); 
operator does not block DHCPv6 std ports, nor DHCPv6 std multicast; 
router manufacturer does offer DHCPv6-PD server in the infrastructure; 
open source software does exist for DHCPv6-PD server; 3GPP specs do tell 
DHCPv6-PD should run; Android app DHCPv6 does exist on Store; many 
flavors of DHCPv6-PD software was compiled and run on Android.

Less important repetitions follow:

> 
>        Because CLAT wants that to be a /64 prefix.  It will break when the
>     client gets a /63.
> 
> 
> It requires a /64, which may come to the CLAT via a /56 via dhcpv6-pd

It "can"?

I dont think it can.  See above the reasons.  Basically, Android opposes 
the inclusion of DHCPv6 software altogether in their code.

DHCPv6-PD can not run without DHCPv6 code.

But if you are afraid of IA_NA, dont mistake: DHCPv6 code has an option 
called IA_PD (or -P in some implementations) that makes that even if the 
DHCPv6 entire binary is present on the file system, only the IA_PD part 
is called (not the IA_NA).

That's why we have to be careful with words like "it can", or "is 
orthogonal to", or "is independent of", or "CLAT regardless of RA or DHCP".

It's not that way.  It is that CLAT means no DHCP.

> 
> 
>     Moreover, design suggestions from CLAT assume that /64 is sufficient.
>     That is wrong - /64 is not sufficient.
> 
> 
> It is sufficient for CLAT function of execuating rfc6145. CLAT just 
> rfc6145.

No.

When you make such statement - have you tried?

>      > 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.
> 
> 
> Not correct.

See above.  CLAT is what makes Android to explicitely not want DHCP.

Because CLAT says "we are independent of SLAAC or DHCP", but they also 
say "so we use _only_ SLAAC".

If you wanted to support your statement, then you showed me some 
implementation in where CLAT and DHCPv6 worked together.  There is no such.

> 
> 
>      > 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 correct, again. Please see rfc6877.

See public URL in which discussion illustrates Android does not want DHCPv6.

See Android app on Android store that runs DHCPv6, but which is not 
integrated in Android.  Running it requires 'root'.


> 
> 
>      > 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. 
> 
> 
> This operator (and esteamed co-authors)  saw a problem, came to the 
> ietf, worked with Android open source, worked with v6ops, and specified 
> 464xlat.

Another operator has an option in which DHCPv6 is there.

Android blocks that.

Fix Android.

Modem blocks that - fix modem.

> 
> Device availabilty followed.
> 
>     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.
> 
> 
> Again. Dhcpv6-pd and 464xlat are compatible and their deployment 
> motivations are largely orthogonal.

"Compatible", but have you tried?


>     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.
> 
> 
> Owen is correct here.
> 
> 
>     To be tried, before arguing.
> 
>     Can you try?
> 
> 
> Seems you are the one interested in this area.
> 
> The Android source code is available for you.

That is true to some extent.  SOme smartphone manufacturers do offer the 
source code of their platforms, yes.  Some still not, but will come.

On another hand, in order to make my own OS I must 'root' the device. 
That's a risk.

The other option is that the responsible numerous Android devices take 
pride (not oppose) some RFCs like the ones you mention, before blocking 
them.

>     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.
> 
> 
> We can say the specification allows CLAT and DHCPv6-PD to work 
> together.  Running code is an exercise left to those with a demand for 
> that usecase.

Promoting an RFC from INFO to StdsTrack demandes usecase.

>      >>>>> 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.
> 
> 
> agreeing with Owen, it is orthogonal.

Orthogonal.

> 
> 
>     As long as CLAT does not agree there is DHCPv6-PD and IPv6-in-GTP then
>     we have little to talk about.
> 
> 
> 3 different things
> 
> CLAT is just rfc6145
> 
> Ipv6-in-GTP is just an ip in UDP tunnel for mobility in 3gpp 
> infrastructure, it has nothing to do with the internet or the UE
> 
> Dhcpv6-pd ... assignes prefixes.
> 
> 3 different and orthogonal things.
> 
> 
> 
> 
>     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.
> 
> 
> Again, 464xlat was not pushed by Android, it was pulled by operators in 
> the ietf

Operators also ask what Android wants.

Operators dont oppose DHCPv6-PD.  3GPP doesnt either.  Yet Android 
refuses DHCPv6-PD.

>     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.
> 
> 
> Modem is the wrong place ...

Modem manufacturers say differently.

Modem manufacturers do implement IP features.  Sometimes they block 
RFCs, just like Android blocks DHCP too.

But they found a sort of living together: it's the old Host-IMP interface.

The Host (Android) does some stuff assuming their matter is 'orthogonal' 
to the IMP (Qualcom).  However, for the IMP we are not allowed to know 
what it does and for Android we are not allowed to ask them do DHCP.

That's not an interface: it is independence, orthogonality.

That leads to problems.

Alex

> 
> 
> 
>     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
> 
>     _______________________________________________
>     v6ops mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/v6ops
>