Re: appropriate length of fe80:: prefix and new IP-over-foo drafts

[Brian E Carpenter <[e-mail]>]

Hi Fernando,
On 2019-02-01 00:15, Fernando Gont wrote:
> On 30/1/19 19:14, Brian E Carpenter wrote:
>> Section 5.3 "Creation of Link-Local Addresses" of RFC4862 refers to
>> an interface identifier of N bits and an fe80::0 prefix "of
>> appropriate length", which according to the addressing architecture
>> is 128-N. But N is undefined by RFC4862 and cannot be derived from an
>> RA because all this happens as soon as the interface is enabled.
>> Therefore N must be predefined.
> 
> I guess that since link-local addresses are generated with SLAAC, at
> least according to current specs that implies a prefix length of /64?

All the current specs (including the ones Alexandre mentioned) specify
64 bit IIDs for LL assignment. But as I pointed out, it isn't necessary
that the same IID is used for LL creation and for a routeable address
created later after receiving an RA/PIO. I can't see anything in nature
or RFC4862 that requires the lengths to be the same either.

I have no problem with every ipv6-over-foo specifying 64 for the LL IID,
or with implementations using the same IID for both LL and SLAAC, but
these are choices, not rules.

There's probably a privacy argument for *not* using the same IID for
LL and routeable addresses.

>> As pioneered by RFC2464**, all ipv6-over-foo documents must therefore
>> specify N for their link type. So far, everybody has specified 64, as
>> far as I know. Is there a reason to do otherwise for the two drafts
>> mentioned below?
> 
> I'd regard that as an artifact of history ;-) , which made sense at a
> time when we generated IIDs embedding MAC addresses in the IID.
> Nowadays, I don't think there's a valid technical reason for a link
> layer to specify the IID length. Why would they care? In fact, some
> might even regard that as a layering violation...

You're 100% correct about the historical reason for this. It's quite
amusing to see the magical 0xfffe appearing in draft-hou-6lo-plc
for no obvious reason. But I think that an ipv6-over-foo MUST specify
the IID length for LL addresses, because it's explicitly a free parameter
N in RFC4862. Of course these days the IID bits should be specified
as "see [RFC8064], [RFC7217]".

>> Why does it matter, since the unrouteable fe80::/(128-N) prefix is
>> quite disjoint from the question of the routeable /64 prefix? All we
>> care about is that it matches fe80::/10.
>>
>> (As a matter of curiousity, is there any particular reason to use the
>> same IID to generate the LL address and the stable routeable address?
>> It surely isn't necessary, otherwise temporary addresses wouldn't
>> work.)
> 
> Where I've found this "expectation", it has been associated with some
> sort of "compression" -- some way to avoid storing or transmitting part
> of the IP address because you can derive/imply it form elsewhere.

Which sounds like bad computer science. And again, temporary addresses
seem to show that it is a wrong assumption.

    Brian