Re: please read: Clarification on GUID's universal/loc al bit

Yes.  This is how one could construct an IPv6 IID from an the lower 64 
bits of an IB GID.

I've attached a write-up that goes into detail on the IB solution.  Also 
see below for a note on timeframe

Margaret Wasserman wrote:
> 
> Hi Daniel,
> 
> It is good to know that the IBTA is working to address this issue.
> 
> If I understand your proposal correctly, once this change has been 
> adopted by the IBTA, the correct way to build a IPv6 IID from a GUID 
> would be:
> 
> (1) Start with the 64-bit GUID
> (2) If the OUI portion of the GUID is equal to the specified value, then 
> the "u" bit should be cleared (regardless of its original value) to 
> indicate that the IID is locally administered.
> (3) Else (if the OUI portion of the GUID does not equal the specified 
> value) the "u" bit should be set
> (regardless of its original value) to indicate that the IID is globally 
> unique.
> 
> If I am understanding you correctly, this would always result in the 
> proper setting of the "u" bit in IPv6 addresses.
> 
> What is the timeframe for an IBTA decision on this issue?  This is 
> somewhat urgent, as we won't be able to finalize and approve the IPOIB 
> specification until this issue is resolved in the IBTA.

It will take a while for all this to percolate through the IB 
bureaucracy.  The plan is to release the modified spec in mid-july for 
internal review with external release as part of the IBA1.2 release 
planned for Sept of this year. As a practical matter, the IBTA link work 
group has indicated approval of this approach, with the biggest hurdle 
being approval by the IEEE registration authority.  Without a lot of 
pushing this will not happen for about 6 weeks.  Is that timeframe ok or 
do we need to push this?

> 
> Thanks,
> Margaret
> 
> 
> At 5:28 PM -0400 5/24/04, Daniel Cassiday wrote:
> 
>> The IBTA link WG (who is responsible for this mess in the first place) 
>> has discussed this issus and is exploring solutions.
>>
>> The current thinking is not to use the u bit to indicate global scope. 
>> Instead, any locally administered IB addresses (i.e. IB 64-bit Global 
>> identifiers) would use a reserved vendor identifier (i.e. a reserved 
>> OUI).  Any IB 64-bit Global ID that does not use this vendor tag will 
>> have global scope and be globally unique.
>>
>> In this approach, the IBTA would apply to the IEEE Registration 
>> Authority for a OUI to be used for this purpose. The IBTA would also 
>> clarify the IBA spec and add the requirement the "u" bit is ignored in 
>> the EUI-64 (i.e. a vendor cannot have two EUI-64s differing only in 
>> the value of the "u" bit)
>>

_______________________________________________
IPoverIB mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ipoverib

The following note describes an EUI-64 addressing issue in the IB
specification (and its proposed resolution):

The EUI-64 identifier is used by IB devices to provide a unique device
ID and to form addresses for use in IB fabrics.  The EUI-64 is made up
of a 24-bit OUI (assigned by the IEEE Registration Authority) and a
40-bit extension assigned by the organization owning the OUI.

These identifiers are used in generating addresses (IPv6 and IB GIDs).
In IB, a user can generate a GID by concatenating the EUI-64 with the
64-bit subnet address.  Further, a means is needed for a user to
generate additional GIDs for that port (among other needs, this is
needed to support mulitple GIDs per port). 

Unfortunately, the IBA did not clearly define how the EUI-64 should be
assigned to the device.  Specifically, the IBA is unclear on how to set
the universal/local bit.  To fix this confusion without breaking current
implementations, the LWG would like to allow either values of the
univeral/local bit to be used by manufacturers in setting the EUI-64.

This creates a problem for locally assigned addresses (GIDs), however
These are addresses that are not constructed by concatination of the
EUI-64 and subnet addresses.  To illustrate the problem, consider an IB
fabric where a device has multiple GIDs per port.  Each additional GID
on this port must have a locally assigned address.  The lower 64-bits of
this address must be different from any manufacturer assigned EUI-64.
This is because, a device with that EUI-64 could conceivably be plugged
into the IB fabric causing an address collision.

The universal/local bit in the EUI-64 was intended to protect against
this collision possibility.  Locally assigned address would have the
local bit set, while manufactirers assigned EUI-64 would have it set to
universal.  Unfortunately the IBA is not clear on how this bit should be
set by IB device manufacturers.

To resolve this problem, the LWG is proposing that locally assigned
addresses use a special OUI rather than the universal/local bit.  The
IBTA would obtain this OUI from the IEEE registry.  The IBA would be
clarified to suggest that manufacturers clear the universal/local bit
(indicating global scope) but the opposite setting is still accepted.
Any addresses assigned locally (i.e. any address assigned not using a
vendors OUI) should use the special OUI.

To do this, the LWG first needs approval from the TWG and SC to request
a OUI from the IEEE registry.  (The IEEE registry may already have an
OUI that could be used for this purpose) This involves a one time fee of
$1650.