Hi Karl,
On Mon, 21 Feb 2011 20:29:54 +1100
Karl Auer <[email protected]> wrote:
> Does anyone know if (and if so in what way) RFC2526 is honoured in the
> real world?
>
> It's standards track, dating from 1999, but I'm not sure I've seen
> anyone avoiding the stipulated reserved addresses. Addresses generated
> by SLAAC from a MAC address may well have some of the last seven bits
> set, for example.
>
> "The construction of a reserved subnet anycast address depends on the
> type of IPv6 addresses used within the subnet, as indicated by the
> format prefix in the addresses. In particular, for IPv6 address
> types required to have 64-bit interface identifiers in EUI-64 format,
> the universal/local bit MUST be set to 0 (local) in all reserved
> subnet anycast addresses, to indicate that the interface identifier
> in the address is not globally unique. IPv6 addresses of this type
> are currently specified to be those having format prefixes 001
> through 111, except for Multicast Addresses (1111 1111) [3]."
>
> Just interested to know if these supposedly reserved anycast addresses
> are something one should actually be avoiding in practice or not.
>
Reading through the above text and the subsequent text in the RFC a
few times, I don't think it is saying that the subnet anycast address is
derived from the EUI-64 identifier i.e. your MAC address with SLAAC.
I think the word "format" after "EUI-64" means it isn't talking about
a node's EUI-64 identifiers, rather I think all it is saying that if you
require reserved subnet anycast addresses with 64 bit Interface
Identifiers, then the format is -
| 64 bits | 57 bits | 7 bits |
+---------------------------------+------------------+------------+
| subnet prefix | 1111110111...111 | anycast ID |
+---------------------------------+------------------+------------+
| interface identifier field |
where the 71st bit is switched off (i.e. 6 on bits, 1 off bit, then 50
on bits for the 57 bits portion).
(It's a bit scary thinking about the code changes to be deployed if
EUI-64 a.k.a. MAC address end-octets needed to be zeroed before use in
SLAAC!).
Regards,
Mark.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
