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