>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 protected] [mailto:[email protected]] On Behalf Of Erik Nordmark Sent: Tuesday, June 01, 2010 10:04 AM To: [email protected] Cc: [email protected]; 6lowpan Subject: 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 _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
