RS/RA Exchange (was Re: RE: [DNA] Comments ondraft-shim-dna-proactive-00.txt)

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

Hi Zhigao, 

I've reset the subject to follow the thread of discussion.

----- Original Message -----
From: Zhigao Chen <zgchen@psl.com.sg>
Date: Wednesday, March 3, 2004 4:23 am
Subject: RE: [DNA] Comments on draft-shim-dna-proactive-00.txt

> Hi Greg,
> 
> Thanks for the comments. Please find my further comment inline.
> 
> Regards,
> Zhigao
> 
> 
> <snip>
> > > I get your point after realizing that you make a 
> > distinction between 
> > > trigger and hint in your draft. The gain of doing reachability 
> test 
> > > (with unicast RS/RA) in the case of weak hint could be less 
> > signaling 
> > > overhead, especially in the downlink, and less disruption to 
> > > routers/hosts. Consider that RS/RA exchange between hosts 
> > and routers 
> > > is changed from one-multiple-multiple to one-one-one.
> > 
> > I agree that the issue of multiple response is one 
> > which may be useful to check in the case 
> > 
> > Indeed, it may make sense for a router not to do
> > any delay when sending an RA in response to unicast RS
> > (if indeed it is suitable for a router to receive
> > unicast RS (I need to read 2461 again)).
> > 
> I think it makes sense to send an RS in unicast in the case of
> reachability test despite certain potential risk, e.g. router changes
> its link-layer address (a rare event unlikely happening in such a 
> shortHO interval, IMO). Mulitcast RS is more useful in router 
> discovery. I
> have a discussion on the RA random delay issue in the Section 7.1 
> of our
> I-D (http://www.psl.com.sg/draft-chen-dnav6-apid-00.txt). The
> Introduction section of the FastRA I-D
> (http://www.join.uni-muenster.de/Dokumente/drafts/draft-mkhalil-
> ipv6-fas
> tra-04.txt) also explains why the RA delay is used in RFC2461. I
> strongly agree we should look into this issue in hopes to shorten the
> DNA latency. 

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.
 
Addressing delays for upper layer protocol packets are also important, 
but this is probably beyond scope for the WG.

> > Depending on the network topology and technology, 
> > the number of routers (which in many cases will be 
> > small) may not matter, but the cost of multicast response
> > may be large (uniform bandwidth consumption on all cells
> > in the link).
> > 
> 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.

> > I'd like to think that the issue of whether a router responds 
> > unicast is determined by the access network administrator. 
> > This assumes that the admin knows best for their network. 
> > Therefore, the host won't have control of whether the router 
> > responds unicast or multicast.
> > 
> RFC 2461 neither precludes a host from sending a unicast RS nor a 
> routerfrom receiving it. The unicast RS in fact passes the validity 
> check in
> the router. Section 6.2.6 of RFC2461 says "a router sends 
> advertisementsin response to valid solicitations received on an 
> advertisinginterface". So it seems that an implementation should 
> support unicast
> RS/RA. As for administrative consideration, I would certainly like to
> hear opinions from network admin/implementers on whether there will be
> any reason of not processing a unicast RS. I think the feature 
> should be
> turned on once the operator realizes the benefit (provided we have
> consensus) of doing so.

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.

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.

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.

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.

> > Using RS/RA exchange in this case may not be one-one-one,
> > but it may not matter.
> > 
> For reachability test, sending a multicast RS may be okay (RA delay 
> willbe incurred though), but I am afraid multicast RA response will 
> causeconfusion to other hosts. Suppose a host also sent an RS, 
> which gets
> dropped due to link failure, but it received the multicast RA 
> triggeredby another host. In this case, the receipt of the RA after 
> sending a RS
> can not confirm the bi-directional reachability and the host could be
> misled. Considering the NUD in NDv6 is done with unicast NS/NA, I 
> thinkit is difficult to perform reachability test of using 
> multicast RA (with
> R and S bits).

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.

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.

> > Significantly, it may be worthwhile determining if there are 
> > network topologies which make sense that don't have large 
> > numbers of RA responders in short time frames (perhaps on the 
> > slow responding router, a multicast RA can be scheduled at a 
> > lower rate), and what happens to hosts when the advertisement 
> > intervals for multiple routers on a link are skewed.
> > 
> Increasing the RA interval gives rise to the freshness issue of router
> information. However, I agree that is interesting to look into.

I'm actually not talking about _increasing_ the advertisement 
interval. 

That's not a good solution in general.

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.