Hi,
Now you are off of terminology, good. Let's leave the terminology alone
for a while. On 6lowpan-nd we need to concentrate on the protocol
details and implementation aspects. I changed the name of this thread.
But lets please not re-tread on old subjects here. How about we do our
best on nd-03 to make things crystal clear and then do another comment
round? OK?
Some of your criticism here is on the very foundations of what this WG
was chartered to do, and how e.g. IEEE 802.15.4 and similar link-layers
work. Those we can't do anything about, so no use arguing about them.
Alexandru Petrescu wrote:
Zach Shelby a écrit :
[...]
If you try to do a multicast with scope > 2, then you have a flooding
problem unless multicast is implemented in some other way. This is
why we use the Whiteboard approach in 6lowpan-nd, to avoid the need to
flood the LoWPAN.
6lowpan-ND Whiteboard instead of link-layer multicast... maybe we
should make another thread...
Again we are down to a link-layer reality. We don't have link-layer
multicast available.
For example it says:
Another consequence [of forming address from MAC] is that the
link-local address is presumably unique on the Extended LoWPAN,
This is not a very safe assumption IMHO.
In 6lowpan-nd we are performing DAD across the entire LoWPAN before
removing the optimistic flag on an address. So it is unique after that,
regardless of being short.
At least because the uniqueness assumed with IPv6 addresses formed from
short 16bit addresses is a uniqueness relative to a "PAN id" (and not to
a LoWPAN, not an Extended LoWPAN), even less globally unique. And we
don't know anything about the uniqueness of PAN-IDs, do we?
which enables the use of Optimistic Duplicate Address Detection (oDAD)
[RFC4429] over the Transit Link and the LoWPAN.
AFAIK oDAD does use the typical ND link-local multicast messages, so
does 6LoWPAN use ND link-local multicast messages or not?
Over the transit link, which is the backbone link in an Extended LoWPAN.
So it works exactly as in standard RFC4861. I'll fix that to say
"backbone link".
(Transit Link on Edge Router overlaps its link-local scope over the
LoWPAN)
To simplify address resolution it is assumed that nodes within a
LoWPAN use addresses in a homogeneous way and that the unicast IPv6
address IIDs resolve directly to a corresponding link-layer address.
I just suppose it unsafe to assume an IPv6 address IIDs address resolves
directly into a MAC address, IMHO. Because:
It is not unsafe, it is the basic way that 6lowpan works.
-it prohibits the use of manually assigned link-local addresses.
Not true at all. Please read IEEE 802.15.4 and RFC4944 specs. e.g. IEEE
802.15.4 MAC implementations let you assign any address you want to the
interface. So you can change your 64-bit or 16-bit address any time you
want.
-it requires link-layers to have MAC addresses (not all have).
The kinds of link layers we are dealing with in 6lowpan do have MAC
addresses.
-in particular for IPv6-over-802.15.4 it is difficult to
distinguish an IID to correspond to a short (16bit) or normal MAC
address. What is the MAC address from which this IPv6 address was
formed?
fe80::21:70ff:feb8:8252
After removing the fffe and the fe80 - is there a short 16bit MAC
address in there concatenated to the PAN ID? Or is it a locally unique
manually assigned 48bit MAC address? Or a locally-unique self-derived
non-standard USB address?
That does not conform to RFC4944. Anyways, there are only two ways to
derive the IID in RFC4944. You can tell them apart using the U/L flag in
addition to the 16-bit zero field in-between the PAN-ID and 16-bit short
address. I don't see a problem here.
Upon a registration flow, an edge router doing DAD
Doing DAD or DAD?
DAD
If successful, this address is returned in an Address Option of the RC
with the 'A' flag set and the assigned IPv6 address formed from the
generated link-layer address with the defualt prefix inline.
This is typically a DHCPv6 function (a router forming an address for a
host and sending it for assignment on interface). One would expect the
draft to refer DHCPv6 and say why not, no?
This is claim and defend addressing. It is just a random number
generated on behalf of the node (and then checked with DAD)... After
this point it is completely up to the node to defend this address. The
Whiteboard keeps absolutely no state regarding the generation, just a
standard whiteboard entry. We have talked about this many times before.
The node itself could just as well perform the random 16-bit address
generation and then try to register it (thus performing DAD) on a
trial-and-error basis.
Alex
--
http://www.sensinode.com
http://zachshelby.org - My blog “On the Internet of Things”
Mobile: +358 40 7796297
Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND
This e-mail and all attached material are confidential and may contain
legally privileged information. If you are not the intended recipient,
please contact the sender and delete the e-mail from your system without
producing, distributing or retaining copies thereof.
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
