Re: SLAAC RFC4862 - appropriate length of fe80:: prefix

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

Incidentally, this matches the terminology of draft-carpenter-6man-lap-01.
The Shortest Acceptable Identifier Length (SAIL) is 64 because
of SLAAC, and the Longest Acceptable Prefix (LAP) is 10. This
is made very clear by the diagram in RFC4291 section 2.5.6.
The inequality LAP + SAIL <= 128 is satisfied, and the bits in
the middle are zero by definition.

Regards
   Brian

On 2018-09-15 04:41, 神明達哉 wrote:
> At Fri, 14 Sep 2018 15:57:04 +0200,
> Alexandre Petrescu <[e-mail]> wrote:
> 
>> In RFC4862 'SLAAC' there is text about an 'appropriate length' of the
>> link-local prefix, and further pointing to RFC4291.
>>
>> What is the 'appropriate length'?
>>
>> Because otherwise it is hard to implement step 2, because it tells the
>> bits after the ll prefix are set to 0.
>>
>>>    A link-local address is formed by combining the well-known link-local
>>>     prefix FE80::0 [RFC4291 <https://tools.ietf.org/html/rfc4291>] (of
> appropriate length) with an interface
>>>     identifier as follows:
>>>
>>>     1.  The left-most 'prefix length' bits of the address are those of
>>>         the link-local prefix.
>>>
>>>     2.  The bits in the address to the right of the link-local prefix
> are
>>>         set to all zeroes.
>>
>> Which are those bits?
> 
> The short answer would be:
> - "the link-local prefix" is fe80::/10
> - "the bits" in bullet #2 are the rightmost 118 bits
> 
> Somewhat longer answer, or explanation:
> 
> I guess a background motivation of the question is that RFC4291
> doesn't explicitly define the term "link-local prefix".  While I
> personally believe the specifications are sufficiently clear for the
> vast majority of implementors, it would have been even more super
> perfect if the description of RFC4862 referred to Section 2.4 of
> RFC4291 and stated "the link-local prefix is the binary prefix shown
> in Section 2.4 of RFC4291 that identifies link-local unicast
> addresses".
> 
> In practice, if it were not fe80::/10, the only other possibility from
> RFC4291 would be fe80::/64 according to this diagram:
> 
>    |   10     |
>    |  bits    |         54 bits         |          64 bits           |
>    +----------+-------------------------+----------------------------+
>    |1111111010|           0             |       interface ID         |
>    +----------+-------------------------+----------------------------+
> 
> Again, personally, I wouldn't consider the intermediate 54 bits to be
> a part of the "link-local prefix", but since RFC4291 doesn't
> explicitly define this term, I can't deny the possibility that someone
> with extraordinary imagination could think that the 54 bits are part
> of "the prefix".
> 
> Even with this interpretation, however, that doesn't matter much in
> practice (at least today), since as of RFC4862 the length of the
> interface ID is supposed to be defined in link-type documents, and
> (AFAIK) all existing such documents say it's 64 bits.
> 
> So, either way, an implementation can auto-configure a link-local
> address, and the result is the same.
> 
> --
> JINMEI, Tatuya
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>