Hi Robert,
On Sep 2, 2010, at 2:21 AM, Robert Cragie wrote:
> It's a minor point and the text is not specifically wrong in hc-11 but the
> following change would make things 100% consistent, in my view.
>
> The link-local prefix is by definition FE80::/64. So the following:
>
> 10: 16 bits. The first 112 bits of the address are elided.
> The value of the first 64 bits is the link-local prefix
> padded with zeros. The following 64 bits are 0000:00ff:
> fe00:XXXX, where XXXX are the 16 bits carried in-line.
>
> would look better as:
>
> 10: 16 bits. The first 112 bits of the address are elided.
> The value of the first 64 bits is the link-local prefix.
> The following 64 bits are 0000:00ff:fe00:XXXX,
> where XXXX are the 16 bits carried in-line.
>
> as the 'padded with zeros' seems to be a hangover from the previous text when
> it expanded it to a 112-bit prefix.
As defined in Section 2.4 of RFC4291, the link-local prefix is only 10 bits
long:
Address type Binary prefix IPv6 notation Section
------------ ------------- ------------- -------
Unspecified 00...0 (128 bits) ::/128 2.5.2
Loopback 00...1 (128 bits) ::1/128 2.5.3
Multicast 11111111 FF00::/8 2.7
Link-Local unicast 1111111010 FE80::/10 2.5.6
RFC4862 has similar wording in forming a link-local address:
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.
3. If the length of the interface identifier is N bits, the right-
most N bits of the address are replaced by the interface
identifier.
So the 'padded with zeros' text isn't a mistake, the well-known link-local
prefix needs to be "expanded" from 10 to 64 bits.
--
Jonathan Hui
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
