Subject: Re: [6lowpan] RFC4944 about EUI-64 "addresses"?

From: Robert Cragie <[email-masked]>
Date: Fri, 22 Jan 2010 11:32:31 +0000

Hi Alex,

In general, I think if you consider the term "EUI-64 address" as 
shorthand for "IEEE EUI-64-based address" (or even just "IEEE address") 
and scope the context of the term to link layer addresses then it makes 
sense.

Further comments below, bracketed by <RCC></RCC>.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com <http://www.gridmerge.com/>

Alexandru Petrescu wrote:
> 6LoWPANners,
>
> I believe I have another complain about the RFC 4944.  Yes, we are not
> modifying RFC4944 neither here nor now.
>
> However, I have been referred to it several times while discussing the
> current WG items.  For example, in private and in public I have been
> told that RFC 4944 says "EUI-64 address".  Or, I am used to EUI-64 being
> not an address but an identifier.
>
> RFC 2464 mentions it as an "EUI-64 identifier", or "Interface
> Identifier".  It never calls it an "EUI-64 address".
<RCC>Strictly speaking, an EUI-64 identifier is an identifier. In IEEE 
802.15.4 it is also used as a link-layer address, therefore has a dual 
purpose for that type of link layer</RCC>
>
> RFC 4944 mentions it as an "EUI-64 address" in some places:
>
> rfc4944:
>> All 802.15.4 devices have an IEEE EUI-64 address, but 16-bit short 
>> addresses (Section 3 and Section 12) are also possible.
<RCC>So this is almost correct - perhaps "IEEE EUI-64-based address" 
might be more accurate. But it is always used in the context of a link 
layer address.</RCC>
> [...]
>> Length:  This is the length of this option (including the type and 
>> length fields) in units of 8 octets.  The value of this field is 2 if
>> using EUI-64 addresses, or 1 if using 16-bit short addresses.
>
> It's very difficult to understand it ok.
<RCC>Again, if you take this as "IEEE EUI-64-based address" then it 
makes sense to me.</RCC>
>
> I am used for an address to be unique, otherwise it's not very good.
> But an identifier is not necessarily unique, it's good, and it has that
> g bit to distinguish it being unique or not.
>
> Now that you read up to here, also understand my complain about RFC 4944
> reading "short address".  Instead, I would like it to say "short MAC
> address" throughout.  This would have saved me much misunderstandings in
> many discussions in 6LoWPAN and RoLL.
<RCC>Again, I think this is only used in the context of link layer 
address so I am not sure if the distinction is needed.</RCC>
>
> Thank you,
>
> Alex
>
>
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 22 Jan 2010 16:58:01 +0100

Thanks for the reply, I have further comments.

Le 22/01/2010 12:32, Robert Cragie a écrit :
> shorthand for "IEEE EUI-64-based address" (or even just "IEEE
> address") and scope the context of the term to link layer addresses
> then it makes sense.

WEll yes,  when I read IEEE documents and see the term 'address' I read
it as a 'MAC address' or 'EUI-64 address' and not as IP address - there
is little risk of confusion, in there.

> Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 (0)
> 1924 910888 http://www.gridmerge.com <http://www.gridmerge.com/>
>
>
>
>> I believe I have another complain about the RFC 4944. Yes, we are
>> not modifying RFC4944 neither here nor now.
>>
>> However, I have been referred to it several times while discussing
>>  the current WG items. For example, in private and in public I have
>>  been told that RFC 4944 says "EUI-64 address". Or, I am used to
>> EUI-64 being not an address but an identifier.
>>
> <RCC>Strictly speaking, an EUI-64 identifier is an identifier. In
> IEEE 802.15.4 it is also used as a link-layer address, therefore has
>  a dual purpose for that type of link layer</RCC>
>>
>>> All 802.15.4 devices have an IEEE EUI-64 address, but 16-bit
>>> short addresses (Section 3 and Section 12) are also possible.
>
>  might be more accurate. But it is always used in the context of a
> link layer address.</RCC>

I prefer the more accuracy implied by the use of the long expression
"IEEE EUI-64-based address".

This distinction is necessary especially when talking how IP addresses
are formed from MAC identifiers.

>>> length fields) in units of 8 octets. The value of this field is 2
>>> if using EUI-64 addresses, or 1 if using 16-bit short addresses.
>>

Yes, to me too, provided it said 'IEEE EUI-64-based address' instead of
EUI-64 address.

>> I am used for an address to be unique, otherwise it's not very
>> good. But an identifier is not necessarily unique, it's good, and
>> it has that g bit to distinguish it being unique or not.
>>
>> Now that you read up to here, also understand my complain about RFC
>> 4944 reading "short address". Instead, I would like it to say
>> "short MAC address" throughout. This would have saved me much
>> misunderstandings in many discussions in 6LoWPAN and RoLL.
>

I RoLL WG often was discussion about reducing the size of an IPv6 base
header, and even reducing the size of an IPv6 address.  Some people
suggest to reduce the size of an address (as they have done when
reducing the 48bit MAC identifier into an 16bit 'short' MAC address).
And then they realize they're at IETF and IPv6 addresses are too long
for memory-constrained devices.  And then suggest to reduce the size of
an IPv6 address.  Which is not of much sense.

And during these discussions this clarification is needed.

One way to clarify is to say that an 'address' is actually an 'IPv6
address' and all the others are identifiers.  This would be in line with
rfc2460 and rfc 2464 (IPv6 over Ethernet).  But it would not be inline
with RFC4944.  That's why I suggest modifying RFC 4944.

Alex

>>
>> Thank you,
>>
>> Alex
>>
>>
>> _______________________________________________ 6lowpan mailing
>> list [email-masked]