Hello,
Would there be support for putting in 6lowpan-ND that you must send from an
address based on the EUI-64 instead of anticipated 16-bit address? I think
it is more consistent with what is already in 6lowpan-ND. Consider the
following:
>From the assumptions section of 6lowpan-ND, we have:
o EUI-64s are globally unique.
o All nodes in the LLN have an EUI-64 interface identifier in order
to do address auto-configuration and detect duplicate addresses.
Thus 6lowpan-ND is already assuming we have a link-local address based on an
EUI-64. Based on those two assumptions you could greatly simplify processing
of NA by performing the following when you receive a NA message:
[1] Is the EUI-64 my address? If so skip to general processing (not
shown here)
[2] Am I a 6LR? If so continue to step 3, otherwise abort as nothing
more to do.
[3] Generate an address by performing the address autoconfiguration
algorithm on the EUI64 in the ARO with the link-local prefix
[4] Forward the message to the address generated in step 3,
recalculating ICMPv6 checksum
Such a setup has the following disadvantages:
-You ALWAYS transmit the registered address in the ARO on first hop,
wasting 16 bytes
But the following advantages:
-Cannot have collision of two 802.15.4 ACK's because you are transmitting to
two nodes at once
-Less FLASH usage, since you have removed temporary NCE, and always use the
same ARO Length which further simplifies code
-Less SRAM usage, since you never need a neighbor cache entry for multi-hop
DAD to complete
-ARO registered address can be changed by ABR. For example if ABR notices a
node is re-registering after that node reboots, the ABR could change
registered address to nodes old address in NA it sends back.
-Avoids "hacks" when sending last-hop NA. By "hack" I mean that people may
just take registered address out of ARO, and send 802.15.4 message to lower
16 bits of registered address, since they are only every registering GP16
addresses in their case. By instead explicitly using EUI-64 to generate
address, you decouple the registered IPv6 address from the MAC address used
during registration. Thus the same code could in the future be used to
register any address, not just GP16 addresses. It is only the final hop that
knows if there should be any correlation between IPv6 address & 802.15.4
address, not intermediate nodes.
-Does not need SLLAO in initial NS
Comments?
-Colin
From: [email protected] [mailto:[email protected]] On Behalf
Of Westergreen Mads-MWEST2
Sent: August 18, 2010 3:14 PM
To: [email protected]; Dario Tedeschi
Cc: [email protected]
Subject: Re: [6lowpan] ND Short Address Collisions
I also agree with this approach!.
Br,
Mads Westergreen
Senior Platform Architect, Wireless Connectivity Operation
Freescale Semiconductor
Mobile: +45 20 31 45 03
e-mail [email protected]
This e-mail, and any associated attachments have been classified as:
[ ] Freescale Semiconductor General Business
[ ] Freescale Semiconductor Internal Use Only
[ ] Freescale Semiconductor Confidential Proprietary
From: [email protected] [mailto:[email protected]] On Behalf
Of Robert Cragie
Sent: 18. august 2010 06:52
To: Dario Tedeschi
Cc: [email protected]
Subject: Re: [6lowpan] ND Short Address Collisions
I did raise this at the IETF meeting in Maastricht but let's say it wasn't
met with universal approval. What was put in was a tentative NCE, which is
better than what was there before but still has the issues Colin has pointed
out below. I have always thought the right way is to carry the 16-bit
tentative MAC address in the ARO option all the way to the ABRO, which then
really just views it as a number at that point. Only when it finally gets
back to the joining node does it then become a true MAC address and is then
autoconfigured as an IPv6 address.
Robert
Robert Cragie (Pacific Gas & Electric)
Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com <http://www.gridmerge.com/>
On 18/08/2010 12:48 AM, Dario Tedeschi wrote:
Hi Colin
I'm all for item #3. It makes handling of IP address conflicts simpler,
helps avoid media-access issues (like you mention in #2) and is more inline
with the IPv6 paradigm.
Dario
Colin O'Flynn wrote:
Hello,
I had some questions/concern about 6lowpan-ND:
#1)
I know there was much discussion about handling the case when a node
registers to a parent, and that parent already has a node registered to it
with the same address (or it is the parents address), and how to route the
response back.
I'm not convinced the addition of a 'temporary' NC makes a lot of sense to
be honest. I think a better solution is to explicitly spell out in
6lowpan-ND what happens when the case of a response not being received
occurs.
The easiest solution I can think of is that after sending
MAX_UNICAST_SOLICIT times, you take the same action as if you had a
duplicate address. You try that maybe 3 times, and if it still fails select
another router (if available).
Then what happens in the case of a duplicate entry, is the NA is routed to
the wrong device or yourself. It will throw it away since it is either not
expecting the ARO, and/or the EUI-64 does not match in the ARO. It takes an
extra few messages since the target will be re-trying but the chances of
this are minimal at least.
#2)
An interesting aspect of the above is that when the NA is sent back, there
are actually two nodes listening they will both send an 802.15.4 ACK. This
will result in a collision and the parent may not actually hear the ACK,
resulting it in thinking a failure occurred at the 802.15.4 layer.
We may not care about this, but if someone ties together the failure at the
802.15.4 layer to higher layers it might result in unnecessary traffic.
#3)
Considering the above, what was so wrong with sending from a known-unique
IPv6 address for that first hop?
There is zero added complexity, and a minimal overhead in terms of bytes.
Since you are carrying the EUI-64 inline you actually already have that
nodes address anyway, and could eliminate the SLLAO from the initial NS if
wanted (this could be a link-specific optimization , and need not be part of
6lowpan-ND).
Indeed the best idea would be to send from the link-local address based on
the EUI-64. Nodes which are using mostly 'plain' ND with special extensions
would still work fine in their neighbor table. Nodes which are specially
programmed could avoid needing an entry in the neighbor table since they can
form the destination of the NA based on the EUI-64.
Regards,
-Colin
_____
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
