[DNA] Re: RS/RA Exchange

[Greg Daley <greg.daley@eng.monash.edu.au>]

Hi Zhigao,

Zhigao Chen wrote:
> Hi Greg,
> 
> Sorry for the late reply. Really appreciate your comments. I've added a few
> comments below.
> 
> Regards,
> Zhigao
> 
> 
>>Hi Zhigao,
>>
>>I've reset the subject to follow the thread of discussion.
>>
> 
> I also think it is better to start a new thread since the discussion has
> deviated the previous subject a lot.
> 
> 
>>It's on the critical path in many cases.
>>
>>I think that if we talk about receiving appropriate
>>information, then initially it may be good to look at DAD
>>delay (not fixing it,
>>but interoperating with it), RS delay and RA delay,
>>if we concentate in router discovery.
>>
> 
> Yes. Those dispensable delays can be removed whereas certain delays are
> conducive and necessary. DNA should try to streamline them instead of
> getting rid of them.
> 
> 
>>Addressing delays for upper layer protocol packets are also
>>important,
>>but this is probably beyond scope for the WG.
>>
> 
> Agree.
> 
> 
>>>Good point. The impact is big on bandwidth-scarce wireless link.
>>
>>In single cell-per-access router cases, this is not a big
>>issue, though.  The only additional cost is computation on the hosts.
>>
> 
> 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.

>>I've just done a quick check RFC2461. the destination address
>>of the RS is listed as:
>>
>>" Typically the all-routers multicast address."
>>
>>This is not a strong statement.
>>
>>As you mentioned, the validation rules in section 6.1.1
>>do not seem to care whether the destination of an RS is
>>multicast or anycast.
>>
>>Further on though, in section 6.2.2, it states:
>>
>>"...
>>   A router MUST join the all-routers multicast address on an
>>   advertising interface.  Routers respond to Router
>>Solicitations sent
>>   to the all-routers address and verify the consistency of Router
>>   Advertisements sent by neighboring routers.
>>
>>..."
>>
>>Later in section 6.2.6 it mentions:
>>
>>"...
>>   In all cases, Router Advertisements sent in response to a Router
>>   Solicitation MUST be delayed by a random time between 0 and
>>   MAX_RA_DELAY_TIME seconds.
>>..."
>>
>>While this is not necessarily just for preventing router
>>transmission synchronization, it seems that there is no
>>special consideration for unicast RS.
>>
>>So it is unclear what is actually deployed in the Internet.
>>
> 
> 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.

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.

>>Even if you are correct that a particular router is the one
>>we want to solicit (based on prior information), there is a
>>problem in choosing to do a unicast RS unless you know that the
>>router will respond.
>>
> 
> I've some reservation here. I think multicast RS also has the same problem,
> especially when there is only a single router on the link. The problem is
> whether a router must response to an RS. I admit unicast RS has a weakness
> in handling the situation that router suddenly changes its link-layer
> address.

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

>>In DNA, even if we're told beforehand about a router, a host
>>is unlikely to tell if optional capabilities are supported
>>until it receives the router's first RA.
>>
> 
> Of cause, waiting for the capability indication from the first RA is a safe
> way. Even if a router discards a unicast RS, it might realize the need of an
> RA and speed up sending a scheduled RA. Passive waiting is not good enough,
> I think. If the router accepts it and the solicited RA comes early, the
> effort is worthwhile. Otherwise, we can still resort to the unsolicited RA.

I was actually talking about the issue of prior knowledge
from a link-hint, FMIP or CARD (not talking explicitly about
the standards development).

It's hard to think of a situation without these where
the unicast RA provides reliable performance benefits.

> I agree we should see how to make the best of the unsolicited RA not only in
> case such capability is unavailable.
> 
> 
>>We'd have to survey existing implementations of IPv6 Routers
>>to determine what they do with unicast RS.
>>
>>If they currently discard it, we have a 'showstopper'.
>>
>>We couldn't introduce something (especially into
>>the BCP area) which didn't reliably work with existing
>>IPv6 deployments.
>>
> 
> I agree with you the existing implementations should be looked into before
> we could say it is in line with BCP.

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.

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.

Greg