Re: appropriate length of fe80:: prefix - new version of draft-petrescu-6man-ll-prefix-len

[Alexandre Petrescu <[e-mail]>]

Hi,

I submitted a new version of draft-petrescu-6man-ll-prefix-len.

The changes are:
- explanation of why fe80:1::1 does not work in a particular OS,
- refer to the new DHCPv6 RFC which considers fe80::/10.

https://datatracker.ietf.org/doc/draft-petrescu-6man-ll-prefix-len/

Alex

Le 31/01/2019 à 23:35, Brian E Carpenter a écrit :
> 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
>