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

Alexandre,

There are several statements you made that i not consistent with my
understanding.

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

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


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

That said, my deployment includes both IPv6-in-GTP and 464xlat
simulatenously


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


I do not agree,  Please state what is structurally preventing this.
RFC6877 specifically calls for using dhcpv6-pd


>   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


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


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


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


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

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.


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


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



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


> 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


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


>
> 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]
> https://www.ietf.org/mailman/listinfo/v6ops
>