Real world use for the U/L bit?
bmanning at vacation.karoshi.com
bmanning at vacation.karoshi.com
Mon Nov 15 00:24:36 CET 2010
and I thought it was for defining server addresses that were not dependent
on a given MAC address, like DNS service, You don't
want to keep changing the IP address just becuase the MAC has changed.
Same is true for any BGP speaker.
--bill
On Mon, Nov 15, 2010 at 09:38:23AM +1300, Brian E Carpenter wrote:
> Roger,
>
> Today - it is no use. Just a rule.
>
> The reason it is in the address architecture is stated explicitly
> in RFC 4291:
>
> "The use of the universal/local bit in the Modified EUI-64 format
> identifier is to allow development of future technology that can take
> advantage of interface identifiers with universal scope."
>
> This was in the hope of a multihoming solution that would avoid PI prefixes.
> That is still an active hope.
>
> Regards
> Brian Carpenter
>
>
> On 2010-11-14 23:26, Roger Wiklund wrote:
> > Hi
> >
> > I'm having problems understanding the _use_ for the U/L bit.
> >
> > I understand the concept, but I don't understand the use for it.
> >
> > The U/L bit is the seventh bit of the first byte and is used to
> > determine whether the address is universally or locally administered.
> > If the U/L bit is set to 0, the IEEE, through the designation of a
> > unique company ID, has administered the address. If the U/L bit is set
> > to 1, the address is locally administered. The network administrator
> > has overridden the manufactured address and specified a different
> > address.
> >
> > So if the EUI-64 address is created using the OUI, its universally
> > administered. If the MAC is manually configured for some reason, its
> > locally administered.
> >
> > But why do I need to know this? When will I actually have to login to
> > a router/whatever to check how the U/L is set? We still have DAD if
> > two admins accidently use the same manually configured MAC address or
> > something stupid like that.
> >
> > Thanks!
> >
> > /Roger
> >
More information about the ipv6-ops
mailing list