On 05/31/10 07:50 AM, [email protected] wrote:
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).
Why not?
And I'm not sure I know what "available" means in this context. You
might have meant "unavailable", but even that is undefined.
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.
Can you please describe your assumptions about the network (i.e.,
actually describe the problem you are trying to solve), and then
describe the detailed steps of the fallback procedure?
If your assumptions include the networking being partitioned at times,
than that means that using short addresses is rife with problems. Two
hosts in different partitions might succeed in DADing the same short
address, which means that when the partition heals one would need to
detect and recover from the duplicate addresses, which means that hosts
need to reconfigure their addresses.
Issues like that is what makes me keep on asking for a better
description of the problem you are trying to solve.
If we look at what would happen with 6lowpan-nd-09 as specified, when
the optional multihop DAD is used and the 6LBR is unreachable we get
something like this:
- Host sends NS with ARO
- 6LR receives it. If it is a new host IP address, then it needs to
perform multihop DAD before responding to the ARO. In this case the 6LR
sends a NA without ARO back to host (so that NUD doesn't fail), and
sends a multihop DAD to the 6LBR.
- Host retransmits ARO (since it has no response).
- 6LR receives retransmit, which makes it retransmit the multihop DAD
to the 6LBR.
- At some point in time the host migh give up on the ARO (and this
isn't specified in 09). It *might* be reasonable for it to try to
register an EUI-64-based address at that point in time. (Also, the spec
might mention in section 8.2 that DAD hence multihop DAD shouldn't be
done for EUI-64 based addresses.)
But more likely the network is broken or misdesigned if the initial ARO
when the hosts are powered on fails. If that is the case, it might be
counterproductive to switch from short to EUI-64, since that would
merely hide the fundamental problem of the broken or misdesigned network.
Also, if the whole network (6LBRs, 6LRs and hosts) are powered on in
arbitrary sequence, then we could have hosts that start sending AROs
before routing has settled down. It might be more sensible to have those
hosts patiently try to register a short address - sooner or later
routing will stabilize - instead of switching to EUI-64.
If they fallback to EUI-64, wouldn't that mean that they should
periodically try to get back to using a short address? Otherwise the
energy efficiency will be permanently bad due to some transient issue
when the host was powered on.
Erik
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
