Re: 64share v2

On 12-Nov-20 16:00, Gyan Mishra wrote:
> 
> 
> On Wed, Nov 11, 2020 at 9:36 PM Brian E Carpenter <brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>> wrote:
> 
>     On 12-Nov-20 14:33, Lorenzo Colitti wrote:
>     > On Thu, Nov 12, 2020 at 5:21 AM Brian E Carpenter <brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com> <mailto:brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>>> wrote:
>     >
>     >     I disagree. The reality is that 3GPP has already overridden the intention
>     >     of RFC4861 by misusing an RA/PIO as a prefix delegation mechanism. That's
>     >     a clever trick, but it is a trick, and Cameron's proposal simply extends
>     >     that trick a bit.
>     >
>     >
>     > That's incorrect. 3GPP used RFC4861 as the IETF asked it to use it - to assign a /64 to the phone because a single /128 was not enough. The phone is free to use as many interface IDs within that /64 as it wants.
> 
>     I can't find any words in RFC 4861 that describe an RA/PIO as assigning or delegating a prefix. A PIO announces that a prefix is in use on the link, as far as I understand it, and that is very different from assigning or delegating it.
> 
>     Note, I'm not saying that this usage is harmful within a PDP context, but it is definitely not described by RFC 4861. It is described by RFC6459, but that's Informational.
> 
>     > If you're referring to RFC 7278 (which is an IETF document, not a 3GPP one), then I don't see how that conflicts with the intention of RFC 4861. All interface IDs are still 64 bits. It's conceptually the same as saying that the /64 is actually on the phone's downlink interface, and the phone's uplink interface is unnumbered.
> 
>     Sure, the sidestep occurs in Cameron's draft that extends the usage to prefixes shorter than /64. Again, I'm not saying that's harmful. But let's not pretend that it's normal usage of RFC 4861 that would work on an Ethernet.
> 
> 
>     Are you saying that with 64share v2 any prefix length could be sent via slaac RA.

That's what Cameron's draft says, yes.

   Brian

>  The A flag would is set for slaac so that side step won’t work as far as I can tell without updating RFC 4861.  Current 64share 7278 with 64 bit prefix but anything shorter would not work without updating the IETF standards.
> 
> The side step occurring in 7278 is a RA delegation of the radio /64 prefix.
> 
> Am I missing something?
> 
> 
> 
>         Brian
> 
>     --------------------------------------------------------------------
>     IETF IPv6 working group mailing list
>     ipv6@ietf.org <mailto:ipv6@ietf.org>
>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>     --------------------------------------------------------------------
> 
> -- 
> 
> <http://www.verizon.com/>
> 
> *Gyan Mishra*
> 
> /Network Solutions A//rchitect /
> 
> /M 301 502-1347
> 13101 Columbia Pike 
> /Silver Spring, MD
> 
> 