>> 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
>*If* the network might end up using both claim-and-defend and DHCPv6
>(either at the same time, or switch between the two) then all non-EUI-64
>address must be registered in the DAD table in the 6LBRs. In such a
>configuration we can have DHCPv6 hand out a short address to a host
>while another host is trying to claim that address. With your proposal
>the second host would get itself registered in the DAD table in the
>6LBR, while the first host would just register with its 6LR(s) hence we
>would end up with duplicates.
We can imagine a reserved range of addresses in the DHCP server for random
and static addresses (a well known sink or very simple hosts without DHCPv6
support). But even in that case a safe DAD would require a multihop DAD.
The new bit would just be an optimisation for each dedicated range of
addresses.
Matthieu
Erik Nordmark
<erik.nordm...@or
acle.com> A
Matthieu
03/06/2010 16:15 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 06/ 3/10 05:59 AM, [email protected] wrote:
> 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
That means the network is partitioned; some parts are cut-off from other
parts.
If a 6LR has never received the prefix (and compression context)
information from a 6LBR then it doesn't make sense for that 6LR to start
advertising itself as a default router using RAs.
But that is somewhat orthogonal to this discussion, since the network
can partition after the prefixes (and contexts) have been distributed to
the 6LRs.
> - 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
Sure, that is the nature of using claim-and-defend for the short
addresses instead of DHCPv6 address allocation.
> 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)
Perhaps this isn't stated explicitly, but for route-over when anything
but EUI-64 is used the routers MUST support some way to perform DAD
across the 6lowpan. That requirement can be satisfied using section 8.2
in 6lowpan-nd, or any other protocol that is developed for this purpose.
Hence that isn't a reason to add such a bit to the host-to-router
interaction.
> 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.
I don't understand how the error code will make things any quicker. All
it would do is to move the decision from when to fallback from the host
to the 6LR.
> 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
*If* the network might end up using both claim-and-defend and DHCPv6
(either at the same time, or switch between the two) then all non-EUI-64
address must be registered in the DAD table in the 6LBRs. In such a
configuration we can have DHCPv6 hand out a short address to a host
while another host is trying to claim that address. With your proposal
the second host would get itself registered in the DAD table in the
6LBR, while the first host would just register with its 6LR(s) hence we
would end up with duplicates.
Erik
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
______________________________________________________________________
<<inline: graycol.gif>>
<<inline: pic18373.gif>>
<<inline: ecblank.gif>>
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
