Subject: RE: router selection draft comments

From: "Richard Draves" <[email-masked]>
Date: Mon, 18 Mar 2002 20:35:04 -0800

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-masked]
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Tue, 19 Mar 2002 07:27:51 +0200 (EET)

I'll just comment on just some issues.

> see a need to change the draft.

I agree: what I was describing was a way of doing a part of single-link 
functionality in a different fashion; but as I think your mechanism is 
simpler, this was just pointing out an another capability of redirects.

> 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.

Doesn't the rule I pointed above fill these requirements?

Actually, I just wanted a short sentence, like [RFC2461]:

      Length         8-bit unsigned integer.  The length of the option
                     (including the type and length fields) in units of
                     8 octets.

Perhaps the first one is obvious; when you go straight to explaining 
values to be used, it may seem a bit out of context (this is a balance 
between being too terse and too verbose though) if you don't have very 
clear visual image how Length was encoded.

> 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.

I disagree: Prefix List and DRL are the terms (capitalized) also used by 
the normative reference RFC2461, while Routing Table (capitalized) is 
*not*.  So I think it should be non-capitalized (or defined).

> I will clarify that it is OK for implementations to have this race

IMO, it would probably be better *not* to have that race condition 
(consider if implementation send out two RA's, first incorrect one, second 
good one, 100 us apart).  Not sure if that's easier to describe though.

> 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.

Concerns were raised on the w.g. meeting, so I'll leave this here for now.

> 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.

Most definitely not.

The point of the firewall is protecting hosts.  Hosts using some other 
router because of higher preference (and thus being at least partially 
unprotected) is exactly the opposite: Firewalls should advertize _high_ 
default priority.

(However, more specific routes to some other routes might have a better 
priority than the firewall, as these could most often be considered 
"internal networks").

I think you're considering firewall a bad evil connection-blocker: I see 
it as a protector.  I guess that comes from defining the firewall policies 
yourself.. :-)

> 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.

A valid concern: however, I just happen to dislike "magic numbers", but 
e.g. pre-RFC2460 had some reasoning behind the magic of maximum number of 
routing header intermediate hops (23): I was wondering if there is 
something similar here.

-- 
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