I'll just comment on just some issues.
On Mon, 18 Mar 2002, Richard Draves wrote:
> 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.
>
> > 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.
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.
> > 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.
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.
> > 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.
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).
> > 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.
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.
> > 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.
Concerns were raised on the w.g. meeting, so I'll leave this here for now.
> > 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.
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.. :-)
> > 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.
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
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
