Well, my interpretation is that EUI-64s always have the universal/local
bit set to universal. And, non-EUI-64's have the universal/local bit
"set" to local. For local ones, I assume that the 'c' and 'm' bits are
"anything goes". The question then is whether the individual/group bit
applies.
If on
Also, the impact of assuming this individual/group bit exists is the
loss of 1 bit (so the "randomly" generated value only has 62 bits of
uniqueness rather than 63 bits). While that cuts the number of values in
half, there is still plenty of randomness.
I do think answering this question about "lo
Hi Bernie,
Bernie Volz (volz) wrote:
4291 does mention it in Appendix A:
where "c" is the bits of the assigned company_id, "0" is the value of
the universal/local bit to indicate universal scope, "g" is
individual/group bit, and "m" is the bits of the manufacturer-
selected extensio
4291 does mention it in Appendix A:
where "c" is the bits of the assigned company_id, "0" is the value of
the universal/local bit to indicate universal scope, "g" is
individual/group bit, and "m" is the bits of the manufacturer-
selected extension identifier. The IPv6 interface identi
Hi Christian,
Christian Huitema wrote:
As for anycast and multicast, these addresses supposedly set the "group" bit in
the identifiers -- and if they don't they really should, since the L2 transmission is
multicast. Setting the G bit differentiates these addresses from RFC3041 addresses.
Ag
Hi Bernie,
Instead of step 4, perhaps step 4 (or as part of 3) should state
> that the individual/group bit (bit 7) should be set to 0 to
> indiciate individual (unless a group identifier were being generated,
which I don't think is the point of this draft). There is no mention
> of this bit
> Fred explained that ISATAP identifiers should really use the
> global bit as well.
Hmm; not exactly what I said, but in (RFC4214, Section 6.1),
what if we were to change:
"When the IPv4 address is known to be globally unique, the "u" bit
(universal/local) is set to 1; otherwise, the "u" b
