Hi,
>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.
But then what a host is supposed to do if an ARO with "duplicate" is
received?
If I'm right the possibilities are:
1) Register a new short address
2) Register an EUI64 address
3) Stop talking
If DAD is available the host can try 1) but if not it should try 2).
3) shall only be used if a global policy within the lowpan prevents from
using EUI64 address or if the EUI64 is duplicated (IP spoofing?).
Zach's propositions allow the host to run a fall back procedure.
As I understand the sequence with B) seems quite complex when DAD is
unavailable.
- The host registers an IP based on a short address
- The 6LR returns only success local uniqueness
- The host unregisters the previous address
- The host registers an EUI64 based address.
- The 6LR still returns only local uniqueness but the EUI64 is supposed to
be unique within the lowpan so the host can use it.
So my preference goes to A) as it also provides a solution when a DHCP is
present.
Matthieu
Erik Nordmark
<erik.nordm...@or
acle.com> A
Envoyé par : Zach Shelby <[email protected]>
6lowpan-boun...@i cc
etf.org 6lowpan <[email protected]>
Objet
Re: [6lowpan] 6lowpan-nd: How to
31/05/2010 13:28 detect if short-address is safe to
use?
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
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
______________________________________________________________________
<<inline: graycol.gif>>
<<inline: pic16549.gif>>
<<inline: ecblank.gif>>
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
