[DNA] RE: RS/RA Exchange

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

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

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

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

> Since working on this previously, I've come to the conclusion
> that when using SEND this problem may not occur. (and that S
> bits aren't useful, since they can't identify the transmitter).
>
> Each SEND message can have a Nonce which is used to identify
> responses to solicitations.
>
> Receipt of a secured multicast RA which does contain your
> nonce indicates some bidirectional reachability*.
>
> Receipt of a SEND message containing a different Nonce
> means that the RA isn't a response to your RS.
>
Good to know that. Nonce should work better in identifying messages.

> It may be that Nonces can be left out of multicast responses
> to RS. draft-ietf-send-ndopt-04 says in Section 5.3.3:
> "...
>  All solicited advertisements MUST include a Nonce, copied from the
>    received solicitation.  Note that routers may decide to send a
>    multicast advertisement to all nodes instead of a response to a
>    specific host.  In such case the router MAY still include the nonce
>    value for the host that triggered the multicast
> advertisement.  ..."
>
> So in this case there may be some unclear wording about
> solicited and multicast, but the intention is clear:
>
> Nonce can be left out of multicast RA responses.
>
> So there's some chance that the Router may leave out nonces,
> but if it is able to construct a new signed RA message, we
> could indicate its value in doing so.
>
> If there's a router which understands nonces, but not SEND,
> this may be able to respond with a Nonce copied from the
> solicitation.
>
> Reception of a Nonce where none was sent in the solicitation,
> or a differing Nonce to that which was sent could be used to
> indicate that this doesn't match the solicitation.
>
> Of course, in that case where the nonce matched, we may be
> unsure of who sent the message, let alone whether it is a router.
>
> Reception of router advertisements where you haven't
> received confirmation of reachability could be
> treated less favourably than those which have full
> bidirectional reachability.
>
> Additionally, when we know enough to trust a router's
> identity, it may be possible to start another type of packet
> transfer in order to use this for reachability confirmation.
> (this may lead to synchronization if we're not careful though).
>
> This may include checking routing authorization with DCS/DCA.
>
These are very interesting to me. Thanks for the pointer.

> I was considering what it would be like to have a router
> which always does unicast response at short interval, and one
> which never unicast responds, and has a large interval
> between (even solicited) mutlicast RAs.
>
> In this case, there would actually be less packets on the
> link in the case of solicitation storms, since the slow
> router would sometimes use the same multicast packet to respond to
> many hosts.
>
>
> Greg
>
>
> Note form earlier.
>
> * In wireless environments, this may not mean you can receive
>   unicast messages from the router though.
>