Thanks for the reply, I have further comments.
Le 22/01/2010 12:32, Robert Cragie a écrit :
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.
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.
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>
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: 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>
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.
<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>
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 protected]
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
