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

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

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

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

Alex
> 
> Owen
> 
>>
>> Alex
>>
>>> Regarsd,
>>> Jordi
>>>  -----Mensaje original-----
>>> De: v6ops <[e-mail] <mailto:[e-mail]>> en 
>>> nombre de Alexandre Petrescu <[e-mail] 
>>> <mailto:[e-mail]>>
>>> Responder a: <[e-mail] 
>>> <mailto:[e-mail]>>
>>> Fecha: miércoles, 20 de septiembre de 2017, 10:28
>>> Para: <[e-mail] <mailto:[e-mail]>>
>>> Asunto: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 
>>> 464XLAT as standard instead of info
>>>               Le 20/09/2017 à 15:19, JORDI PALET MARTINEZ a écrit :
>>>     > Google is your friend:
>>>     >
>>>     > https://android.googlesource.com/platform/external/android-clat/
>>>          Google is my friend.
>>>          Ctrl-F also, and that page does not seem to display any 
>>> correction that
>>>     says "DHCP" in the last 3 and a half years.
>>>          But I think CLAT should run DHCP somehow, otherwise it's a 
>>> non standard
>>>     way to get Prefix Delegation.  Does it?  (I may download it later and
>>>     look at it).
>>>          As long as these two things stay distinct they are in 
>>> competition.
>>>          Once you make 464XLAT StdsTrack you cant also keep DHCPv6-PD as
>>>     StdsTrack - they are on the same layer.
>>>          But yes, you can keep XMPP on the StdsTrack, because it's on 
>>> another layer.
>>>          Alex
>>>          >
>>>     > Same for other questions that you asked before … you can find 
>>> it also for OpenWRT.
>>>     >
>>>     > Regards,
>>>     > Jordi
>>>     >
>>>     >
>>>     > -----Mensaje original-----
>>>     > De: v6ops <[e-mail] 
>>> <mailto:[e-mail]>> en nombre de Alexandre Petrescu 
>>> <[e-mail] <mailto:[e-mail]>>
>>>     > Responder a: <[e-mail] 
>>> <mailto:[e-mail]>>
>>>     > Fecha: miércoles, 20 de septiembre de 2017, 9:55
>>>     > Para: Erik Kline <[e-mail] <mailto:[e-mail]>>
>>>     > CC: "[e-mail] <mailto:[e-mail]>" <[e-mail] 
>>> <mailto:[e-mail]>>
>>>     > Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info
>>>     >
>>>     >      No need to stress terms like billions; that's what modem 
>>> manufacturers
>>>     >      put on the market too routinely.  Maybe we can talk 
>>> trillions of IoT
>>>     >      devices.  Maybe we can use the SI prefixes, like exa, or peta.
>>>     >
>>>     >      That aside, I would like to ask you whether the CLAT src 
>>> on Android is
>>>     >      something I could look at?
>>>     >
>>>     >      Alex
>>>     >
>>>     >      Le 20/09/2017 à 08:03, Erik Kline a écrit :
>>>     >      > There seem to be some misconceptions flying around here.
>>>     >      >
>>>     >      >> Well, I dont think 464XLAT is deployed anywhere else 
>>> than on cellular. These
>>>     >      >> are the big numbers that the Original Poster talked 
>>> about: miliions of users
>>>     >      >> - they are on cellular.
>>>     >      >
>>>     >      > 464xlat is a client-side bit of code (the NAT64+DNS64 in 
>>> the network
>>>     >      > is the "other half").  It is primarily implemented in 
>>> mobile devices,
>>>     >      > and primarily in Android, to be more specific.
>>>     >      >
>>>     >      > As such, the number of 464xlat capable nodes is numbered 
>>> in the /billions/.
>>>     >      >
>>>     >      > There are also some wifi (and wired) networks that are 
>>> IPv6-only with
>>>     >      > NAT64+DNS64; mobile networks aren't the only ones.
>>>     >      >
>>>     >      > NAT64+DNS64 is easily the single most successful IPv6 
>>> transition
>>>     >      > technology on the planet ([a] if one excludes 
>>> "dualstack", [b] queue
>>>     >      > the Sean Spicer jokes).  464xlat can help ease things on 
>>> the client
>>>     >      > side, but it's not the only way to do it (cf. iOS).
>>>     >      >
>>>     >
>>>     >      _______________________________________________
>>>     >      v6ops mailing list
>>>     > [e-mail] <mailto:[e-mail]>
>>>     > https://www.ietf.org/mailman/listinfo/v6ops
>>>     >
>>>     >
>>>     >
>>>     >
>>>     > **********************************************
>>>     > IPv4 is over
>>>     > Are you ready for the new Internet ?
>>>     > http://www.consulintel.es
>>>     > The IPv6 Company
>>>     >
>>>     > This electronic message contains information which may be 
>>> privileged or confidential. The information is intended to be for the 
>>> exclusive use of the individual(s) named above and further 
>>> non-explicilty authorized disclosure, copying, distribution or use of 
>>> the contents of this information, even if partially, including 
>>> attached files, is strictly prohibited and will be considered a 
>>> criminal offense. If you are not the intended recipient be aware that 
>>> any disclosure, copying, distribution or use of the contents of this 
>>> information, even if partially, including attached files, is strictly 
>>> prohibited, will be considered a criminal offense, so you must reply 
>>> to the original sender to inform about this communication and delete it.
>>>     >
>>>     >
>>>     >
>>>     > _______________________________________________
>>>     > v6ops mailing list
>>>     > [e-mail] <mailto:[e-mail]>
>>>     > https://www.ietf.org/mailman/listinfo/v6ops
>>>     >
>>>          _______________________________________________
>>>     v6ops mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>     **********************************************
>>> IPv4 is over
>>> Are you ready for the new Internet ?
>>> http://www.consulintel.es
>>> The IPv6 Company
>>> This electronic message contains information which may be privileged 
>>> or confidential. The information is intended to be for the exclusive 
>>> use of the individual(s) named above and further non-explicilty 
>>> authorized disclosure, copying, distribution or use of the contents 
>>> of this information, even if partially, including attached files, is 
>>> strictly prohibited and will be considered a criminal offense. If you 
>>> are not the intended recipient be aware that any disclosure, copying, 
>>> distribution or use of the contents of this information, even if 
>>> partially, including attached files, is strictly prohibited, will be 
>>> considered a criminal offense, so you must reply to the original 
>>> sender to inform about this communication and delete it.
>>> _______________________________________________
>>> v6ops mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>> _______________________________________________
>> v6ops mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/v6ops
>