Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard

[Alexandre Petrescu <[e-mail]>]

Le 27/02/2017 à 16:40, Lorenzo Colitti a écrit :
> On Fri, Feb 24, 2017 at 3:45 AM, 神明達哉 <[e-mail]
> <mailto:[e-mail]>> wrote:
>
> Out of curiosity: which code is it, and exactly what does its
> assumption mean?  Does it mean, for example, it allows manual
> configuration of an address but requires its IID length be 64 bits?
>
>
> The first example that came to mind was one in the Android 464xlat
> implementation. This takes the IPv6 prefix configured on the
> interface, fills the bottom 64 bits with randomness, adjusts the
> middle bytes to make the result checksum-neutral, and uses that as
> the IID. If we change the IID to != 64 bits, then that code becomes
> incorrect.

For my part, I agree with you: we want that IID len to continue working
with 464xlat.

I dont appreciate the confusion android - and linux for that matter
- introduces when adding by default an fe80::/64 entry in the routing
table.  I dont mind the route, but I mind the 64.

I dont appreciate the linux kernel complaining when receiving a plen==65
in RA.

I think text in 4291bis - if any text - should allow the first case
(IID==64 for 464xlat), but disallow the other two cases (fe80::/64 by
default in linux rt, and linux kernel complaining of plen==65 in RA).

I.e. text in 4291bis - if any text - should allow IID==64, RA plen==65
but should disallow by-default fe80::/64.

Contrary to expectactions, allowed IID==64 for 464xlat should not mean
that plen==65 in RA is prohibited.

(I now realize that because 64 is precisely half of 128 we actually have
two problems: default plens at 64 and also default IIDs at 64.)

Alex