Re: 64share v2

[神明達哉 <[e-mail]>]

At Thu, 12 Nov 2020 09:21:27 +1300,
Brian E Carpenter <[e-mail]> wrote:

> > On Wed, Nov 11, 2020 at 9:01 AM Brian E Carpenter <[e-mail] <mailto:[e-mail]>> wrote:
> >
> >        This memo requests the 3GPP to change this requirement to allow any
> >        prefix size less than or equal to 64 be advertised by the 3GPP
> >        gateway RA. It also, for this purpose only, overrides the implication
> >        of [RFC 4291] and [RFC 4861] that subnet prefixes in RAs are
> >        always /64.
> >
> > I think that if we want to gain consensus on this document, we
> > should avoid overriding/updating/touching RFC 4291.
>
> 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.

I tend to agree that "64share" abuses RA/PIO as a prefix delegation
mechanism (although I'd say it rather overrides the intention of
RFC4862 than 4861).  But I'm not sure what you mean by "the
implication of [RFC4291]".  If it refers to this part of the RFC,

   For all unicast addresses, except those that start with the binary
   value 000, Interface IDs are required to be 64 bits long

then I don't think "64share v2" (https://pastebin.com/duyYRkzG) has to
say it overrides RFC4291.  "v2" is still a prefix delegation
mechanism, so I don't (necessarily) see overriding the implication of
RFC4291 just like RFC3633 (or RFC8415) doesn't override it simply
because it can delegate non /64 prefixes starting with bits 000.  If,
for example, 64share v2 stated the host should auto-configure an
address from (e.g.)  2001:db8:1::/48 by appending a 80-bit identifier,
then, yes, it would override the intent of RFC4291.  But from my quick
read of the draft of draft, it doesn't say anything like that.

--
JINMEI, Tatuya