Re: 64share v2

Le 10/11/2020 à 11:58, Lorenzo Colitti a écrit :
> On Tue, 10 Nov 2020, 19:32 , <otroan@employees.org 
> <mailto:otroan@employees.org>> wrote:
> 
>      > 3GPP networks do have this property. The PIO lifetime in the RA
>     is set to infinite and the actual lifetime is the link lifetime. By
>     and large that seems to work in practice :-)
> 
>     It works fine for the directly connected node.
>     Now please put a large network behind this link and tell me how that
>     goes...
> 
> 
> What problems do you see with this that aren't already addressed by 
> existing RFC7278 implementations?

Well, I think the 64share-v2, as currently formulated, does allude to 
new needed mechanisms when it says:
   "/56 is received from the 3GPP network, it will assign a /64 to the
    wireless LAN interface, another /64 is to be used for a CLAT [RFC
    6877], and the remainder of addresses will create a pool of prefixes
    that are assigned to downstream DHCPv6 PD clients."
These things are not done in current 64share implementations.  There are 
no DHCPv6-PD servers in the smartphones, and there is no standard way to 
form /64s automatically out of a /56.  There are many non-interoperable 
implementations to realize that derivation.

Additionally, a smartphone receiving an RA with a /64, as in current 
64share deployments, will correctly configure an address, but it would 
illegitimately do so if it received a /56 as per 64share-v2, because the 
IID len is 64 currently.

It might be that it might be easier to have a SLAAC with an IID len 72
to match the plen /56 of 64share-v2, rather than a prefix exclude option
in a SLAAC-DHCP combination.

Alex

> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 