RE: [DNA] Re: RS/RA Exchange

[Zhigao Chen <zgchen@psl.com.sg>]

Hi Greg,

> > My understanding is that single cell per AR is more used in
> home or small
> > office networking. DNA might not be needed for such scenario, I
> am afraid.
>
> I think that if you know the environment is constrained,
> perhaps you are right.
>
> What's worth considering is that in some cases, it
> is unlikely that a wireless host will know definitively
> that they are only on a single router subnet, or
> that they will connect only to one wireless base station.
>
> In this case, it may be important to check that you
> are indeed receiving advertisements through the
> base station you expected.
>
> This may not be an IP mobility issue, but it is a DNA one, AFAIK.
>
Right. Such scenario still involves DNA.

RFC2462bis Section 5.7 discusses reusing a retained address after a router
temporarily fails or a host reboots. Under such circumstances, perhaps it is
also possible to do DNA by reusing an address stored in a nonvolatile memory
especially when the host has urgent data to send out.

> > Since sending a unicast RS is not prohibited in the RFC (I would like to
> > interpret it as implicitly supported :-), it is worthwhile to try it out
> > unless it is proved to be infeasible. Implementations usually lag behind
> > proposals, just like some features defined in standard-track
> > document are not yet available in many implementations.
>
> I think that's worth considering, but the benefit
> of this procedure comes only when devices are expected
> to return a response to a unicast RA.
>
Is the condition you talk about is that routers are expected to response to
a unicast RS? If so, I agree.

> The additional cost and time-delay of sending to
> a non-supporting router would be significant.
> Therefore, it may be worth trying to craft
> unicast RS messages to send to rtadvd, radvd, cisco,
> juniper &etc routers.
>
> In this case, if most of the manufacturers' code
> doesn't support the optimization, it's not really
> workable.
>
A router behavior survey is certainly helpful. However, even if the feature
is not yet supported, I don't think it should hinder us from enabling it in
the future, unless it is clear that doing so will bring some downsides.

> This is the same problem, you are right.
>
> We can't really do anything about this though,
> except that we know that the router actually
> processed any messages it received which are
> "vanilla" RFC2461.
>
> If the router chooses not to respond or to
> delay before responding, then that's its perogative.
>
> Hosts need to deal with this.  In most cases,
> the router will respond to solicitations, or
> have an advertisement scheduled, though.
>
> In the case that the RS is unicast, there's some
> chance that the implementation won't validate
> the message correctly. (But this can be tested readily).
>
Admittedly, router behavior is out of hosts' hand. Perhaps we don't see eye
to eye on the issue, but I think a host should have the option to send a
unicast RS rather than wait to be told if the router supports processing it.
If not supported, the host can still fall back on unsolicited RA.

> The diffculty is still in identifying the target of the
> RS.
>
> If the RS is to the old AR, then there's little benefit:
> we can send an NS, since we already know the capabilities
> of that router. Unicast RS has all the drawbacks of
> the unicast or solicited nodes' multicast NS in this case.
>
Compared to NS/NA, using RS/RA to do reachability test allows a host to
verify all the prefix(es) at the same time.

Could you please be a bit more specific of what the drawbacks of unicast RS
and solicited-node-multicast NS are?

> It certainly would provide a decent check if you had
> a suspicion about the identity of the router on the
> new link.
>
> If the destination is unknown, we need a multicast
> destination to increase our chance of response.
>
You can say that again.

Regards,
Zhigao