Re: [v6ops] reclassify 464XLAT as standard instead of info

Le 20/09/2017 à 03:34, JORDI PALET MARTINEZ a écrit :
> I think you may be right, it makes sense that a single /128 will be able to allow that, but I think it is clear that needs to be a different one that the CLAT WAN interface. I guess the authors indicated a separated /64 as it seems easier to allocate it than a single address if you’re using DHCPv6-PD. I was just recalling what is in the actual RFC:
> 
> 6.3.  IPv6 Prefix Handling
> 
>     There are two relevant IPv6 prefixes that the CLAT must be aware of.
> 
>     First, CLAT must know its own IPv6 prefixes.  The CLAT should acquire
>     a /64 for the uplink interface, a /64 for all downlink interfaces

Why does it say '/64'?  Why not '/63'?

>     and a dedicated /64 prefix for the purpose of sending and receiving
>     statelessly translated packets.  When a dedicated /64 prefix is not
>     available for translation from DHCPv6-PD [RFC3633],

In cases where this is not available it's because it is a chicken and 
egg problem.

Some modem manufacturers say that because IETF does recommend RA instead 
of DHCP then they stop forwarding DHCP through their modems.  They 
wrongly understand what IETF recommends.  We have to go through tedious 
emails among us in v6ops to explain what really the recommendation is 
with respect to DHCPv6 vs RA.

Some operator say that because modems dont support then operator does 
not deploy DHCPv6-PD.

Some people say that modem should not do any sort of IP related stuff, 
whereas the modem people say that's the only way they can build one 
modem able to connect to so many different cellular network (it's not 
only the frequencies and codecs that change but also the way they set up 
the connections).

One should also know that at some point some modem did implement somehow 
correctly some DHCPv6 form of 'proxy', yet that became to block DHCPv6 
altogether recently.

> the CLAT may
>     perform NAT44 for all IPv4 LAN packets

'may'?  Or MAY?

Make NATx a StdsTrack?

Alex

> so that all the LAN-originated
>     IPv4 packets appear from a single IPv4 address and are then
>     statelessly translated to one interface IPv6 address that is claimed
>     by the CLAT via the Neighbor Discovery Protocol (NDP) and defended
>     with Duplicate Address Detection (DAD).
> 
> Regards,
> Jordi
>   
> 
> -----Mensaje original-----
> De: <dschinazi@apple.com> en nombre de David Schinazi <dschinazi@apple.com>
> Responder a: <dschinazi@apple.com>
> Fecha: martes, 19 de septiembre de 2017, 22:21
> Para: <jordi.palet@consulintel.es>
> CC: <v6ops@ietf.org>
> Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info
> 
>      
>      > On Sep 19, 2017, at 17:51, JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote:
>      >
>      > If you do it with SLAAC, as described in the RFC, the NAT46 will be stateful (by means of a previous NAT44) because you don’t have a specific /64 for the translation. Otherwise will be stateless.
>      
>      I don't think that's correct. In order to make 464XLAT stateless you need a separate /128, not /64. And SLAAC allows you to generate that extra /128. As far as I know, this is how Android works.
>      
>      As far the discussion of changing the Category of the RFC, I'm not sure what it accomplishes, and whether it's worth spending time on.
>      
>      David
>      
> 
> 
> 
> **********************************************
> 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
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> 