Subject: [DNA] Bootstrapping router knowledge for landmark-based DNA proposal

From: Brett Pentland <[email-masked]>
Date: Tue, 12 Jul 2005 18:21:01 +1000

Hi folks,

I have been updating the landmark-based DNA proposal to reflect earlier
discussion on this list and just wanted to check something.

There was a query about the router behaviour during startup.  The draft
says that a router should send out router solicitations on startup so
that it can quickly learn about the other routers/prefixes active on the
link.  The draft is mute about how it should behave during this period.

My thought is that the router should basically behave like a non-DNA
router during this bootstrapping phase so that it can make its own
prefixes known, but won't make assumptions about its own knowledge of
the other routers/prefixes on the link.

A possible optimization would be to allow router to answer landmark
questions if the answer is yes (since the router knows it's right about
that regardless of what other routers are doing), but for a few seconds
around startup, it's probably not worth doing.

Any comments?
Brett.

---

From: James Kempf <[email-masked]>
Date: Tue, 12 Jul 2005 10:27:00 -0700

Brett,

Actually, I think that a DNA router should refrain from answering any RSs
until the bootstrap phase is complete. This phase is likely to be relatively
transient, and, in addition, it is possible the hosts will be starting up
too. Thus, in addition to the router not having complete information on the
link, the router could possibly fail over into the multicast with a higher
probability. So why not just limit any RAs during the bootstrap phase to
multicast?

Does 2461 say anthing about this?

            jak

----- Original Message -----
From: "Brett Pentland" <[email-masked]>
To: "Dna" <[email-masked]>
Sent: Tuesday, July 12, 2005 1:21 AM
Subject: [DNA] Bootstrapping router knowledge for landmark-based DNA
proposal

---

From: Brett Pentland <[email-masked]>
Date: Wed, 13 Jul 2005 12:06:54 +1000

Hi Jim,

If DNA routers refrain from answering RSs altogether, then the
bootstapping process will achieve nothing when all the routers
on a link startup together since they'll just ignore each others'
RSs.

Regarding RFC 2461, the only bit I could find on this is section
6.2.1 which deals with becoming an advertising interface.  It doesn't
have any bootstrapping period; it just says that the interface
should respond to Router Solicitations sent to the all-routers
multicast address and that it should verify the consistancy of
RAs sent by neighbouring routers.

So I don't think it matters whether responses are unicast or
multicast but I think routers should respond with RAs that have
no DNA-specific options included.

Brett.

---

From: Subba Reddy <[email-masked]>
Date: Wed, 13 Jul 2005 09:26:48 +0530

Hi Brett and James,

> on a link startup together since they'll just ignore each others'

I think routers should advertise RAs atleast for non DNA RSs.

For landmark queries, if the prefix advertised by the router 
(not learned prefix) and the landmark prefix matches, 
then it may be better to send "Yes".

<cut>

Thanks & Regards,
Subba Reddy

---

From: James Kempf <[email-masked]>
Date: Wed, 13 Jul 2005 09:16:39 -0700

Brett,

RFC 2461 seems to be a little thin on describing how a link (as opposed to a
single router) bootstraps.

I can see two possibilities;

1) The routers multicast RSs to All_Routers_Multicast, and receive unicast
nonDNA RAs in reply. To accommodate drops, the routers would have to
multicast a sequence of RSs at exponentially increasing intervals up to some
limit.

2) The routers multicast nonDNA RAs to All_Routers_Multicast at
exponentially increasing intervals until a limit. This technique was used in
SLP for bootstrapping a network of Service Agents.

The advantage of the first is that routers receive replies to their queries.

The disadvantage of the first is that hosts too can send out queries during
the bootstrap phase. The host will not learn anything different in the first
than the second, since the multicast nonDNA RAs in the second will provide
the same information as the unicast in the first, but an attacker could
utilize this to disrupt the bootstrapping phase by causing the routers to
roll over to multicast (which is actually what the second technique does
anyway).

Regarding the amount of traffic, there should be exactly as much multicast
traffic for the first as the second, but less unicast traffic on the second
because there is no unicast reply.

            jak

----- Original Message -----
From: "Brett Pentland" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Dna" <[email-masked]>
Sent: Tuesday, July 12, 2005 7:06 PM
Subject: Re: [DNA] Bootstrapping router knowledge for landmark-based DNA
proposal