Hello all,
A couple of comments on -01 draft. Most are just clarifications and
similar.
--8<--
Abstract
This document describes an optional extension to Neighbor Discovery
Router Advertisement messages for communicating default router
preferences and more-specific routes from routers to hosts. This
improves the ability of hosts to pick an appropriate router,
especially when the host is multi-homed and the routers are on
different links. The preference values and specific routes
advertised to hosts require administrative configuration; they are
not automatically derived from routing tables.
==> The preference values [...] could be removed IMO: this is being overly
verbose detail for an abstract.
1. Introduction
Neighbor Discovery [2] specifies a conceptual model for hosts that
includes a Default Router List and a Prefix List. Hosts send Router
Solicitation messages and receive from routers Router Advertisement
messages.
==> s/receive from routers Router Advertisement messages/
receive Router Advertisement messages from routers/
Neighbor Discovery provides a Redirect message that routers can use
to correct a host's choice of router. A router can send a Redirect
message to a host, telling it to use a different router for a
specific destination. However, the Redirect functionality is limited
to a single link. A router on one link cannot redirect a host to a
router on another link. Hence, Redirect messages do not help multi-
homed hosts select an appropriate router.
==> Note about on-link redirecting. Usually, this is interpreted to mean:
+- router1 -x - routerA -->
host -| X
+- router2 -x - routerB -->
the only "trivial ones" are:
traffic: host -> router1 -> router2 -> router{A,B}, router1 redirect ->
router2
traffic: host -> router2 -> router1 -> router{A,B}, router2 redirect ->
router1
One should note that on-link redirection _could_ theoretically be done for
more complex scenarios (e.g. host -> router1 -> routerB, router1 send
redirects to host for router2), but that would be difficult
algorithmically.
We use Router Advertisement messages, instead of some other protocol
like RIP [5], is that Router Advertisements are an existing
standard, stable protocol for router-to-host communication.
==> Because we use ...
2.2. Changes to Router Advertisement Message Format
Prf (Default Router Preference)
2-bit signed integer. Indicates whether or not to prefer
this router over other default routers. If Router
Lifetime is zero, it MUST be initialized to zero by the
sender and MUST be ignored by the receiver. If the
Reserved (10) value is received, the receiver should
treat the RA as having a zero Router Lifetime.
==> Is there a reason to specify any behaviour for 10 at this point?
2.3. Route Information Option
Length 1, 2, or 3 depending on Prefix Length. If Prefix Length
is greater than 64, then Length must be at least 3. If
Prefix Length is greater than 0, then Length must be at
least 2. If Prefix Length is zero, then Length may be 1.
==> Perhaps it would be best by defining that Length is the length of the
option padded up to 8-byte blocks.
3.1. Conceptual Data Structures for Hosts
Host B uses a Default Router List augmented with preference values.
Host B does not have a routing table. Host B uses the Default Router
Preference value in the Router Advertisement header. Host B ignores
Route Information Options.
==> doesn't every host have a routing table of sorts..?
Host C uses a Routing Table instead of a Default Router List. (The
Routing Table may also subsume the Prefix List, but that is beyond
the scope of this document.) Entries in the Routing Table have a
prefix, prefix length, preference value, lifetime, and next-hop
router. Host C uses both the Default Router Preference value in the
Router Advertisement header and Route Information Options.
==> I think Routing Table shouldn't be capitalized, because it isn't an
"official" term anywhere.
When host C receives a Router Advertisement, it modifies its Routing
Table as follows. If a route's lifetime is zero, the route is
==> s/If a route's/If the received route's/
prefix, prefix length, and next-hop router. When processing a Router
Advertisment, host C first updates a ::/0 route based on the Router
==> Advertisement
For example, suppose a host receives a Router Advertisement from
router X with a Router Lifetime of 100 seconds and Default Router
Preference of Medium. The body of the Router Advertisement contains
a Route Information Option for ::/0 with a Route Lifetime of 200
seconds and a Route Preference of Low. After processing the Router
Advertisement, host A will have an entry for router X in its Default
Router List with lifetime 100 seconds. If host B receives the same
Router Advertisement, it will have an entry in its Default Router
List for router X with Medium preference and lifetime 100 seconds.
Host C will have an entry in its Routing Table for ::/0 -> router X,
with Low preference and lifetime 200 seconds.
==> Depending on the implementation, there may be a race condition if the
implementation don't wait until the end of the processing of the whole
message (first accept lifetime 100, pref=low for a very short time until
the rest of the message is parsed). I'm not sure whether this is obvious
or not..
3.2. Conceptual Sending Algorithm for Hosts
When host B does next-hop determination and consults its Default
Router List, it first prefers reachable routers over non-reachable
routers and second uses the router preference values.
==> first .. second sounds a bit awkward: "secondarily" would perhaps be a
bit better, or via some rephrasing.
If all default
routers are not reachable, then it SHOULD round-robin among them all
regardless of preference value.
==> s/not reachable/unreachable/
==> Is this similar policy already used somewhere (e.g. RFC2461)? Some
comparison with "old" mechanism in this case might be in order.
If there are no routes matching the destination, then if host C has
a single interface then it SHOULD assume the destination is on-link.
If host C has multiple interfaces then it SHOULD discard the packet
and report a Destination Unreachable / No Route To Destination error
to the upper layer.
==> how does this relate to current mechanism?
3.4. Router Reachability Probing
When a host avoids using a non-reachable router X and instead uses a
reachable router Y, and the host would have used router X if router
X were reachable, then the host SHOULD probe router X�s reachability
by sending a Neighbor Solicitation. These probes MUST be rate-
limited to no more than one per minute per router.
==> ditto.
4. Router Configuration
As one exception to this general rule, the administrator of a router
that does not have a connection to the internet, or is connected
through a firewall that blocks general traffic, may configure the
router to advertise a Low Default Router Preference.
==> usually if there is such a policy in the firewall, it's there for a
reason, and should not be tried to be avoided. Therefore, I think the
firewall part of the above should be removed.
Routers SHOULD NOT send more than 17 Route Information Options in
Router Advertisements per link.
==> due to XXX? (MTU concerns?)
5.2. Multi-Homed Host and Isolated Network
Here's another scenario: a multi-homed host is connected to the
6bone/internet via router X on one link and to an isolated network
via router Y on another link. The multi-homed host might have a
tunnel into a fire-walled corporate network, or it might be directly
connected to an isolated test network.
In this situation, a multi-homed host A (which has no default router
preferences or more-specific routes) will have no way to choose
between the two routers X and Y on its Default Router List. Users of
the host will see unpredictable connectivity failures, depending on
the destination address and the choice of router.
==> just a note: in this kind of scenario, there would be static routes in
the nodes...
--
Pekka Savola "Tell me of difficulties surmounted,
Netcore Oy not those you stumble over and fall"
Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
