Pekka, thanks for giving the draft a careful reading. If I don't respond to a comment
below, that means I've incorporated your suggestion.
> 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.
I disagree - this is an important aspect of the proposal and it's appropriate to be
clear about it up front.
> 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.
This is true, but it is orthogonal to the point I was making. So I don't see a need to
change the draft.
> 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?
There was an previous request from the WG to specify this behavior. I don't recall the
reasoning behind the request, but maybe the rationale was that if implementations
behave differently it will be more difficult to ever make use of the code point in the
future, because an analysis of the impact on then-existing implementations will be
more difficult.
> 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.
I think the current formulation is more precisely prescriptive. In particular, I want
to allow simplistic senders to always send 24 byte options while more sophisticated
senders can optimize with 8 or 16 byte options.
> 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..?
No. For example, early versions of the Microsoft Research IPv6 implementation had a
default router list and a prefix list but not a routing table.
> 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.
For the purposes of this draft, the term Routing Table refers to a conceptual data
structure in the same way that the terms Default Router List and Prefix List do, so I
think it also should be capitalized for consistency.
> 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..
I will clarify that it is OK for implementations to have this race condition.
> 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.
RFC 2461 says that when no default routers are known to be reachable or probably
reachable, routers SHOULD be selected in a round-robin fashion. So the round-robin
idea here does have precedent.
> 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?
RFC 2461 says that if there are no default routers, then the destination should be
considered on-link. However RFC 2461 does not consider multiple interfaces - see
Appendix A.
> 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.
This router-reachability probing is somewhat new. It's related to the round-robining
specified in RFC 2461 when the default routers are all unreachable. The difference is
our operational experience at Microsoft produced situations in which a preferred
router was temporarily unreachable and so hosts stopped using it, but when
connectivity was restored they did not resume using it because they had already failed
over to a less-preferred but reachable router. The RFC 2461 round-robining didn't help
so I added this router-reachability probing.
With router-reachability probing, the RFC 2461 round-robining is not strictly
necessary - if the host knows of several unreachable routers, it could just use one
and let router-reachability probing check the rest, instead of having Next-Hop
Determination round-robin among them. The only real difference is exactly how often
you end up sending Neighbor Solicitations to the different routers.
> 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.
I don't understand. The point of having the firewall router advertise a Low preference
is to let hosts know that it's not a good choice for general internet connectivity -
respecting the firewall policy.
> Routers SHOULD NOT send more than 17 Route Information Options in
> Router Advertisements per link.
>
> ==> due to XXX? (MTU concerns?)
Due to feedback from an IESG member, if I recall correctly :-). The idea is to further
reinforce that this is not an appropriate mechanism for dumping lots of routes onto a
host.
> 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...
That's the point - the idea is to make these scenarios work without hacking static
routes into the hosts.
Rich
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
