Hi Erik,
Sorry my previous post was not clear enough.
Here is the scenario
I'm not suggesting a partinioned network to keep things simple. Just 1
6LBR, 6LRs and hosts.
- host sends a multicast RS
- 6LRs reply without PIO nor ABRO because the 6LBR is not yet reachable
- host sends a unicast NS with ARO to register a link-local EUI64 address
(LL64)
- 6LR does not check the address because it is based on an EUI64 and
replies a successful NA with ARO
* If we still want a check for EUI64 addresses we might provide EUI64
+random (DHCPv6 DUID-LLT like) as a device identifier in the ARO (already
discussed in another thread, complex and does not solve all the problems).
- Host sends unicast RS until one of the 6LR neighbours has connectivity
with the 6LBR and replies a RA with PIO and ABRO
- Host creates a random short address
- Host sends a NS with ARO to register the GP16 address based on the
previous short address
1) The 6LR supports multihop DAD
- 6LR starts a DAD with the 6LBR and reply a NA without ARO
- host can retransmit X times the NS with ARO until the 6LR replies with an
successful ARO
- In case of duplicate address the host can retry with a new short address.
* If the number of nodes is important, it can take time before the
short address assignment is completely stable
RPL source routing with labels including traffic engineering
may reduce the number of short address possibilities and
increase the risk of address collision thus the stabilisation
time.
* It could be quicker if the 6LBR returns an unused short address but
then why not use a DHCP client/server ?
* If the short address is manually assigned and host doesn't know how
to generate a new address
host can try to configure an EUI64 address (GP64) and wait for
reconfiguration
2) 6LR does not support multihop DAD (misdesigned network)
- 6LR replies NA with successful ARO (local DAD)
=> Hosts thinks that the random address has been checked globally so it may
encounter problems later
* Solution: If host explicitly asks multihop DAD and 6LR replies with
an error code, the host could register a GP64 instead. GP64 could be used
temporarily to recover from the misconfigured network (configure the DHCPv6
client for example)
3) 6LR supports multihop DAD but 6LBR is temporarily unreachable
- 6LR starts a multihop DAD with the 6LBR and replies a NA without ARO
- host retransmits X times the NS with ARO without a response including an
ARO.
a) a global policy disallows GP64 so host waits a moment before registering
the GP16 again or immediatly registers with another 6LR
b) host can work temporarily with a GP64 so it registers a GP64 and will
try to register the GP16 later
* Maybe an error code could help the host to move quicker to a
fallback solution if the 6LR knows it can't reach the 6LBR now.
4) The short address comes actually from a DHCPv6 server
- Host registers the GP16
- 6LR can't make a difference between a random GP16 and a DHCP GP16 so
multihop DAD is started
If we don't want multihop DAD here:
* Disable the DAD option within the lowpan because a DHCP is present
so DAD and DHCP are always exclusive
* Add an option in NS to disable DAD. Proposition A) from Zach.
If the DHCPv6 server is unreachable and the fallback procedure is to
register a random GP16 then the 6LR
may have interest in knowing if multihop DAD is required or not
Matthieu
Erik Nordmark
<erik.nordm...@or
acle.com> A
Matthieu
01/06/2010 09:03 Vial/FR/Non/schnei...@europe
cc
6lowpan <[email protected]>,
[email protected], Zach
Shelby <[email protected]>
Objet
Re: [6lowpan] 6lowpan-nd: How to
detect if short-address is safe to
use?
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
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
______________________________________________________________________
<<inline: graycol.gif>>
<<inline: pic00058.gif>>
<<inline: ecblank.gif>>
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
