On 05/30/10 01:35 PM, Zach Shelby wrote:
In addition to the current tickets for nd-09, an issue was brought up
on the ZigBee IP list that we should discuss.

When using a 16-bit IEEE 802.15.4 address generated at random (or
manually) with the nd-09 address registration procedure, how can one
detect if the address was checked for duplicates locally or across
the LoWPAN? In order for a host to safely start using a short address
generated like this it must know that it is unique throughout the
LoWPAN. Then upon failure the host can either generate and try to
register a new address or fall back to using an EUI-64 derived
address.

And the ARO with "ok" in 6lowpan-nd-09 means that it has been checked for duplicate AFAIK.

The current draft simply returns either Success or Duplicate Address
codes. The Success code doesn't tell a host if Section 8.2 (or some
other technique) has been used to perform DAD by the 6LR. We think
there is a need to clarify this situation for addresses where a check
for LoWPAN uniqueness is required. DAD may not be performed for
multiple reasons, a 6LBR may not be reachable, Section 8.2 might not
be supported or it may just fail.

The intent is that the host shouldn't need to know whether the network is using mesh-under and route-over, nor need to know how DAD is performed in a route-over.

When the 6LR returns "ok" in the ARO option it means that the address was not a duplicate and was registered.

However, an address can become a duplicate later for instance if a partitioned 6lowpan heals. Thus there can be cases where a ARO with "duplicate" is sent to the host later.

I don't see how exposing the host to the innerworkings of multihop DAD makes things any simpler or different for the host. Until an ARO with "ok" is received, the host shouldn't use the address. If an ARO with "duplicate" is received, then the host should not use the address.

   Erik

I see two possible solutions if we agree this is a problem:

A. Include a "DAD Required" flag in the ARO message sent by the host.
If the 6LR is not able to perform DAD, then it returns an error code
something like "DAD Unavailable". This DAD Required flag also makes
it easier for the 6LR to determine if an address was assigned by
DHCPv6 already thus not requiring DAD.

B. Include a new Success code so that there are two, allowing for a
host to determine the extent to which a duplicate check was made. -
Success and address checked for local uniqueness (0) - Success and
address checked for LoWPAN uniqueness (1)

Thoughts?

Zach


_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan

Reply via email to