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

[Ca By <[e-mail]>]

On Wed, Sep 20, 2017 at 10:22 PM Alexandre Petrescu <
[e-mail]> wrote:

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


Not correct. GTP only runs, in LTE, from the eNB to the SGW / PGW.  There
is not GTP on the UE or modem.


> >
> > That said, my deployment includes both IPv6-in-GTP and 464xlat
> > simulatenously
>
> So, you have 2 encapsulations, right?


Only GTP is encap. You can think of 464 translation scenario (ipv4
literals) as being encap in v6 to nat64 ... but i see it as translation not
encap


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

Say the same about Apple. Show me Apple running dhcpv6 on LTE interface.


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

This seems to be your unique perspective


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

Not for me to try. I do not care about dhcpv6.

I am telling you what is in the rfc, this is the ietf. We do rfc. There is
a lot in the world outside of rfc, i agree. But that is for you to handle
in the world outside the ietf.


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

Operating not opposing dhcp is not enough. This is the part you need to
work on outside the ietf.


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