Subject: Re: [6lowpan] 6lowpan-nd: How to detect if short-address is safe to use?

From: Erik Nordmark <[email-masked]>
Date: Tue, 01 Jun 2010 00:03:33 -0700

On 05/31/10 07:50 AM, [email-masked] 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

---

From: Yoav Ben-Yehezkel <[email-masked]>
Date: Tue, 1 Jun 2010 10:21:18 +0300

>From our experience - a typical deployment of AMI applications starts off
with turning the power for a whole block where hundreds of nodes (both
routers and hosts) wake up simultaneously. It takes a while for routers
and routes to settle down.

It would be best if hosts remain as silent as possible until the routes
from 6LR to 6LBR settle down. One way is after the host fails to receive
short address, it waits to retry until the 6LR indicates to hosts that it
recently had connectivity with 6LBR so that the host can retry receiving a
short address. In the meantime, it might be useful for hosts to use
EUI-64, but this should definitely not be the favored option when it can
be avoided.

Thanks,
Yoav

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Erik Nordmark
Sent: Tuesday, June 01, 2010 10:04 AM
To: [email-masked]
Cc: [email-masked]; 6lowpan
Subject: Re: [6lowpan] 6lowpan-nd: How to detect if short-address is safe
to use?

Why not?

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

---

From: [email-masked]
Date: Thu, 3 Jun 2010 14:59:41 +0200

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.nordmark@or                                             
             acle.com>                                                   A 
                                       Matthieu                            
             01/06/2010 09:03          Vial/FR/Non/Schneider@Europe        
                                                                        cc 
                                       6lowpan <[email-masked]>,         
                                       [email-masked], Zach      
                                       Shelby <[email-masked]>         
                                                                     Objet 
                                       Re: [6lowpan] 6lowpan-nd: How to    
                                       detect if short-address is safe to  
                                       use?                                

                                                                           

Why not?

    Erik

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
______________________________________________________________________

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 03 Jun 2010 07:15:29 -0700

> - 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)
> * 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 can retransmit X times the NS with ARO until the 6LR replies with
> an successful ARO
> * 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.
> * If the short address is manually assigned and host doesn't know how to
> generate a new address
> => 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.

> - 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
> * 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.

> * Disable the DAD option within the lowpan because a DHCP is present so
> DAD and DHCP are always exclusive

*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

---

From: [email-masked]
Date: Thu, 3 Jun 2010 17:46:03 +0200

>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.nordmark@or                                             
             acle.com>                                                   A 
                                       Matthieu                            
             03/06/2010 16:15          Vial/FR/Non/Schneider@Europe        
                                                                        cc 

                                                                           

   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 03 Jun 2010 14:49:38 -0700

On 06/ 3/10 08:46 AM, [email-masked] wrote:

> 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.

That only help if you also reserve the complement of that set from being 
used by claim-and-defend.

Hence you would in essence require a cast-in-stone split of the short 
address range into
  - assignable by dhcpv6
  - claim-and-defend
in a standards track document and everybody better adhere to those rules 
or you would have duplicates.

That doesn't sound very flexible, since some environments might want 
2^^16 addresses for use by DHCPv6, and it doesn't sound very robust 
since some admins might want to configure different ranges of short 
addresses for their dhcpv6 servers hence might accidentally configure it 
to use the claim-and-defend part of the space.

    Erik