Discussion:
NetBSD's Implementation of IPv6 Default Router Selection
(too old to reply)
Vijayrajan ranganathan
2009-01-27 10:27:05 UTC
Permalink
Hi,
I am wondering whether NetBSD's implementation of "IPv6 Default
Router Selection" is correct
as per RFC 2461 "Neighbor Discovery for IP Version 6 (IPv6)"

This is implemented in defrouter_select and the references to this
function are
as follows
References in nd6.c
===============
nd6_purge
nd6_free
nd6_ioctl
nd6_cache_lladdr

References in nd6_rtr.c
=================
defrtrlist_del
defrtrlist_update

This is what the RFC has to say about Default Router Selection.
I'd like you to look at the double-quoted portions of this text
carefully.

6.3.6. Default Router Selection

The algorithm for selecting a router depends in part on whether or
not a router is known to be reachable. The exact details of how a
node keeps track of a neighbor's reachability state are covered in
Section 7.3. "The algorithm for selecting a default router is invoked
during next-hop determination when no Destination Cache entry exists
for an off-link destination or when communication through an existing
router appears to be failing" Under normal conditions, a router
would be selected the first time traffic is sent to a destination,
with subsequent traffic for that destination using the same router as
indicated in the Destination Cache modulo any changes to the
Destination Cache caused by Redirect messages.

The policy for selecting routers from the Default Router List is as
follows:
1) ...
2) "When no routers on the list are known to be reachable or
probably reachable, routers SHOULD be selected in a round-robin
fashion, so that subsequent requests for a default router do not
return the same router until all other routers have been
selected.

Cycling through the router list in this case ensures that all
available routers are actively probed by the Neighbor
Unreachability Detection algorithm. A request for a default
router is made in conjunction with the sending of a packet to a
router, and the selected router will be probed for reachability
as a side effect"
3) ...

Should'nt the round-robining of default routers be happening when we try to
determine next-hop(for default route) while trying to send packets through
unreachable routers??

Look at this kind of scenario:
Say, there are 2 default routers and both are unreachable. For
argument sake,
lets think that the 2 routers are dis-connected from the network
after they've
sent 1/2 RAs each. My interpretation of these RFC lines would be
that, if we try to
send packets using default route, we should pick up the default
routers in a
round-robin fashion when we do the next-hop determination for those packets.
For this to happen, we need to round-robin when we do next-hop
determination.

To clarify, I am not suggesting that we do round robin selection
of default router
for every packet that we send. But that we do round-robining only in such a
scenario.

I am trying to get an ANVL test to pass on a "netbsd like" implementation.
Basically, this is the test case. With the netbsd implementation,
this is not
passing.

- ANVL: Send Router Advertisement Message to <DIface-0>,
from RTR-1, containing:
- No Source link-layer address option
- ANVL: Wait for <ProcessTime> for DUT to process Router
Advertisement
- ANVL: Send Router Advertisement Message to <DIface-0>,
from RTR-2, containing:
- No Source link-layer address option
- ANVL: Wait for <ProcessTime> for DUT to process Router
Advertisement
- ANVL: Send ICMP Echo Request from global address of HOST-1
over prefix PREFIX-2 to global address of <DIface-0>
over prefix PREFIX-1
- ANVL: Listen (for upto <ListenTime> seconds) on <AIface-0>
- DUT: Select one from RTR-1, RTR-2, as default router
- DUT: Send Neighbor Solicitation to resolve address of
default router
- ANVL: Verify that received ICMP Message contains:
- ICMP Type field set to ICMP-TYPE-NS
- ICMP Target Address field set to link-local
address of RTR-1 or RTR-2
- ANVL: Send ICMP Echo Request from global address of HOST-1
over prefix PREFIX-2 to global address of <DIface-0>
over prefix PREFIX-1
- ANVL: Listen (for upto <ListenTime> seconds) on <AIface-0>
- DUT: Select the other one as default router
- DUT: Send Neighbor Solicitation to resolve address of
default router

I'd like to know which interpretation of the RFC, netbsd's or ANVL's,
is correct here?? Any answer on the same is much appreciated.

Thanks & Regards
Vijay

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Kevin Lahey
2009-01-30 03:18:45 UTC
Permalink
On Tue, 27 Jan 2009 15:57:05 +0530
Post by Vijayrajan ranganathan
I am wondering whether NetBSD's implementation of "IPv6 Default
Router Selection" is correct
as per RFC 2461 "Neighbor Discovery for IP Version 6 (IPv6)"
[...]
Post by Vijayrajan ranganathan
I'd like to know which interpretation of the RFC, netbsd's or
ANVL's, is correct here?? Any answer on the same is much appreciated.
I'm not certain of the answer here, without reading more of the RFC
and the code, but you probably want to reference RFC 4861 instead of
RFC 2461.

Kevin
***@patheticgeek.net

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Loading...