On 08/21/10 04:45 AM, Colin O'Flynn wrote:
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:
What you are proposing is very different than how RFC 4861 and
6lowpan-nd works for NS and NA. Currently NS and NA make a statement
about the source address when they include a SLLAO. But with your
approach it is sometimes a statement about the source address, and
sometimes a statement about the ARO registered address.
I think this will lead to confusion, and result in corner cases that are
hard to handle.
And in fact you don't need any of that. All you seem to need to handle
your concerns is an "errors-to" MAC address, which the host might set to
its EUI-64 MAC address. (It could also be an "errors-to" IPv6 address
like the LP64.) We can easily add such a field to the ARO.
But having some packets, depending on option content, redefine the IPv6
source address field as the "errors-to" field makes no sense to me.
Two examples of corner cases to worry about in the short term.
1. Assume an NS with ARO+SLLAO where IPv6 source is LL64 and the
registered address is a GP16. In that case what should happen if
1a. There is no NCE for the LL64? (Should one be created?)
1b. There is an NCE for the LL64, but the stored mac address is
different than what is in the SLLAO. (Should it be updated?)
Those questions don't arise in 6lowpan-nd-12 because the NS only applies
to one address - the one in the IPv6 source field.
2. Apply ARO to CGA addresses and Secure Neighbor Discovery. In that
case, which addresses should be used for the SeND verification?
In 6lowpan-nd-12 the answer is simple since it is always the IPv6 source
address.
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
I listed a few architectural disadvantages above. In addition this
causes more complexity in the implementation since an implementation
still has to handle NS and NA messages that do not contain an ARO, and
the rules for how such messages are processed will be different than
when the ARO is in place.
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
The ARO length is already overloaded to distinguish between multi-hop
DAD messages (which are disjoint for all other use of NS and NA) from
normal NS/NA.
Hence as 6lowpan-nd is currently written hosts can't send ARO with
length=4 since those have completely different semantics. That detail
could be fixed, but is an example of the confusion in this space.
-Less SRAM usage, since you never need a neighbor cache entry for
multi-hop DAD to complete
First of all, wouldn't you need the SRAM once the DAD has completed?
Second of all, I think the notion of a temporary NCE is needed to avoid
security issues (preventing an off-link attacker from creating bogus
NCEs - there is no ttl check on the multi-hop DAD messages to protect
against such attacks.)
-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.
Why is this an important problem to solve? How does it relate to the
importance of your original issue around short address collisions? How
does it relate to the overall goal of making 6lowpan compact, simple,
and sufficient to handle 6lowpans.
-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.
I'm sure misguided implementors can still be creative in coming up with
things that violate the letter or intent of the specification.
-Does not need SLLAO in initial NS
I suspect you are referring to the notion of "first time an address is
registered with a particular 6LR" when you say "initial NS".
That notion only exists on a the 6LR. In particular, a host can not
reliably know whether or not a particular 6LR has a NCE for the host's
address.
Thus for robustness all messages that contain the ARO must be able to
function whether or not the 6LR has an NCE.
So while I understand the problem you are trying to solve, the proposed
solution looks like it is making things a few orders of magnitude worse
than the problem you tried to solve.
Introducing an "errors-to" field in the ARO (either as a MAC address or
an IP address) solves the problem without adding more confusion,
complexity, and ill-defined behaviors.
Regards,
Erik
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
