Router Selection Issues List

We probably agree that it shouldn't be done because it just wastes bandwidth but I don't think nodes doing it would actually break anything.

ND is being performed in the presence of real traffic anyway (at least my KAME box does so)..

[Rich Draves] Perhaps. I added this in response to the feedback at Minneapolis, where it was clear the earlier wording was misunderstood to mean that probing would happen in the absence of useful traffic; perhaps I over-reacted. Any other opinions on MUST NOT vs SHOULD NOT here?

[DT/RD/BH] MUST NOT is good to protect the network, no known plausible scenario for allowing

[Thomas Narten] I assume router-select is an optional document, and there is no intent to require all IPv6 nodes to implement it.  However, it appears to contain a change to the ND specification, one intended that all ND implementations make.

The Abstract says:

> The second

> change is a mandatory modification of the conceptual sending

> algorithm to support load-sharing among equivalent routers.

The intro says:

> This document also describes a mandatory change in host behavior.

> Neighbor Discovery's conceptual sending algorithm is modified to

> require hosts to select randomly among equivalent routers. This

> distributes traffic to different destinations among the routers.

> Traffic to a single destination continues to use a single router,

> because of the Destination Cache.

I assume that the above text resulted from a merging of draft-ietf-ipv6-host-load-sharing-00.txt with router-selection.

If I understand the intent, I believe it is a mistake to merge the two documents. It would be better to keep all mandatory changes to the ND spec in a way that they are clearly identifiable. Burying mandatory changes to the ND document within a related (but optional-to-implement) document will make it hard for folks to find those changes.

Resurrecting host-load-sharing seems a fine way to go. At some point, it would probably make sense to incorporate the text directly in the ND spec anyway. (Or maybe we should just delay making the update until ND needs to be respun -- this depends on what other issues people have with the ND spec.)

[Rich Draves] Yes, originally this document was entirely optional but when I merged in load-sharing it picked up a mandatory requirement. The main rationale for merging is that both affect the same code (next-hop determination). On the other hand, it is confusing to have mandatory & optional mixed. Bob, what do you think?

[Bob Hinden] My original preference was to keep them separate, but there was a lot of push back on the mailing list. Based on the mailing list discussion, we combined them. I agree that despite the work to combine them, it is confusing to have mandatory & optional mixed.

My recommendation is to publish them separately. This will require some small changes in the default router selection document (keeping the load sharing, but changing the mandatory/optional text).

Any objections to this approach?

[Rich Draves] I don't quite understand. Are you saying keep the load-sharing section in the router-selection draft, but make it optional, and then a second document makes load sharing mandatory??

[Bob Hinden] Sorry, I wasn't clear. Keep the load-sharing that applies to routers of equal priority in the router-selection draft. Load-sharing should be done

in these cases. The text that applies to the basic ND default-router case should be removed as it would duplicate the load-sharing draft.

[Rich Draves] So section 3.5 in the draft would be kept (changing MUST to SHOULD) and the references to "mandatory" in the abstract and intro would be removed?

[Bob Hinden] Yes, that is what I had in mind.

[Robert Elz] I'm still not clear what this means. I really think that one doc for both of these is what is desirable.

I suspect that part of the problem is that the relationship (or at least what I would like the relationship to be) isn't clear.

That is, if load sharing is done, router preferences MUST be done as well.

So, whatever status we give to load sharing, router preferences has to have at least the same status. I'm not sure that got adequately represented in the draft.

The reason is that it simply isn't acceptable for nodes to start broadcasting packets over all routers on the link at random. If we don't have load balancing, it is possible to arrange for the "right" routers to get used (though in situations where load balancing would help, the net loses).

If we have some kind of mandatory load balancing however, there needs to be a way for the net administrator to control it, and router prefs are that way - we can load balance amongst the preferred routers, and just ignore the others we're not going to choose anyway.

Splitting this back into 2 docs will, I suspect, revert to the situation we had before, where "everyone has to implement load balancing" (because if they don't, it is useless), but router prefs are optional (because people keep wondering if it is possible to configure them properly, which is bizarre, but never mind).

Keep it as one, but get the requirements right.

[Erik Nordmark] Given that load sharing is currently described as mandatory, your point implies that router preferences should also be mandatory.

Perhaps others have different views. Given the 3 pieces

    load sharing,

    router preference,

    more specific routes (which have preference a load sharing themselves)

we might have the following choices (I can't think of other combinations that make sense to me):

    1. all are optional

    2. load sharing is mandatory; others are optional

    3. load sharing and router preferences are mandatory; more specific is optional

    4. all are mandatory

The current document says #2. Your point is #3 as far as I can tell. I guess the WG needs to choose.

But independent of this, if is confusing to have both mandatory and optional protocol pieces in the same document if it can be easily avoided.

[Bob Hinden] The current proposal is to split the document and make load sharing mandatory and router preferences and more specific routes optional. This is choice 2.

As far as I can tell only one person has objected to this approach and has suggested choice 3. (perhaps 4).

Are there any other objections to the current proposal?

Here is what the document says:

> The preference values (both Default Router Preferences and Route

> Preferences) should not be routing metrics or automatically derived

> from metrics: the preference values should be configured. The High

> and Low (non-default) preference values should only be used when

> someone with knowledge of both routers and the network topology

> configures them explicitly. For example, it could be a common

> network administrator, or it could be a customer request to

> different administrators managing the routers.

I worry that the above will not hold in practice in a majority of cases.

I wonder if a better applicability section would help, that describes where this is expected to be used and how things need to be configured by default in such environments.

[Rich Draves] Section 4 specifies a couple exceptions to the usual rule that advertising preferences or specific routes requires coordinated admin of the routers. In particular, I think common scenarios like VPN or two independent ISPs should be handled correctly without coordinated admin of the routers.

[Thomas Narten] Section 4 has some "mays", some of which might better be should/SHOULDs. I.e., an admin SHOULD set a low priority if the router doesn't reach the internet (due to connectivity or firewall).

perhaps also, SHOULD NOT set high priority unless it has control over all the routers at issue and can thus make sensible decisions.

Does it ever make sense to advertise a high preference in the absence of more detailed knowledge of the topology?

Also, in chatting with Erik Nordmark, he indicated that at one point there were some discussions about adding a client capability to have a map table that mapped received preferences into other values, to handle situations where the received preferences didn't have the desired result. Would that be a useful thing to have?

[Robert Elz]

| Section 4 has some "mays", some of which might better be

| should/SHOULDs. I.e., an admin SHOULD set a low priority if the router

| doesn't reach the internet (due to connectivity or firewall).

Thomas, the point of the SHOULD etc words is to tell the implementor what to implement. They're not at all effective in attempting to control how people actually configure the equipment.

And in any case, this is certainly not the doc to be attempting to tell people how to do that - if you want a BCP on setting up IPv6 routers in nice ways, then get someone to write one (as well as what prefs to set, and when, it could go into what lifetimes to use in various situations, etc).

But none of that belongs here (or not pretending to be any more than general commentary so the implementor can understand what the user might want to do with the implementation).

| Does it ever make sense to advertise a high preference in the absence

| of more detailed knowledge of the topology?

"None of your business."

I will configure the preferences of the routers I manage in the way that makes my net work for me. All that is needed of the IETF is to provide the tool for me to use (and if you also want to give some "good usage" advice, that's OK as well, but it should not be as part of the protocol spec).

| Also, in chatting with Erik Nordmark, he indicated that at one point

| there were some discussions about adding a client capability to have a

| map table that mapped received preferences into other values, to

| handle situations where the received preferences didn't have the

| desired result. Would that be a useful thing to have?

Maybe. But this is a quality of implementation issue. I think this kind of thing only matters when one is attempting to specify things like "if I see any normal or high pref routers on interface A, that's what I want to use as my default, but if all I see is low, and there is a high pref router on interface B, then use that one" ...

All this is really beyond the scope of the protocol of router prefs though.

[Thomas Narten]

> Thomas, the point of the SHOULD etc words is to tell the implementor

> what to implement. They're not at all effective in attempting to control

> how people actually configure the equipment.

SHOULD (or should) are used both to tell implementors what to implement and to make recommendations on how stuff ought to be configured/deployed/used. A goal of having shoulds on how things should be configured is to prevent ill-thought settings from being used by default. We do this all the time. Its prudent damage-avoidance.

> And in any case, this is certainly not the doc to be attempting to

> tell people how to do that - if you want a BCP on setting up IPv6

> routers in nice ways, then get someone to write one (as well as what

> prefs to set, and when, it could go into what lifetimes to use in

> various situations, etc).

Its common to mix applicability stuff in with a protocol standard. We do it far more often than writing a separate standalone applicability document.

> But none of that belongs here (or not pretending to be any more than

> general commentary so the implementor can understand what the user

> might want to do with the implementation).

> | Does it ever make sense to advertise a high preference in the absence

> | of more detailed knowledge of the topology?

> "None of your business."

In other words, are you saying the document should provide no guidance to admins on how they should configure things, because that is by definition out of scope in a protocol document? If so, I disagree.

> I will configure the preferences of the routers I manage in the way

> that makes my net work for me. All that is needed of the IETF is

> to provide the tool for me to use (and if you also want to give some

> "good usage" advice, that's OK as well, but it should not be as part

> of the protocol spec).

Noone is saying you can't configure things the way you want. A SHOULD means, do this unless you understand what you are doing, understand the consequences of doing something different, but want to do something different anyway.

> | Also, in chatting with Erik Nordmark, he indicated that at one point

> | there were some discussions about adding a client capability to have a

> | map table that mapped received preferences into other values, to

> | handle situations where the received preferences didn't have the

> | desired result. Would that be a useful thing to have?

> Maybe. But this is a quality of implementation issue. I think this kind

> of thing only matters when one is attempting to specify things like

> "if I see any normal or high pref routers on interface A, that's what

> I want to use as my default, but if all I see is low, and there is a

> high pref router on interface B, then use that one" ...

> All this is really beyond the scope of the protocol of router prefs though.

You seem to be making it sound like a protocol spec should document only the on-the-wire part, and things relating to configuration are out-of-scope. If this is your point, I disagree on principle.

[DT comment] client MAY may be configurable; admin recommendations: SHOULD advertise site prefix, SHOULD be low if not internet, SHOULD NOT be high unless have control over all the routers, and explain why for each.

[Thomas Narten] The document isn't very clear about exactly when to probe, and what the actual probe algorithm is. ND has a very simple probe model. Whenever sending to/through a neighbor, if that neighbor is not known to be reachable (and sufficient time has elapsed), one probes. Probes are then retransmitted if not responded to. In ND, one never needs to probe neighboring routers that one is not actually using (except when all routers are unreachable). This is OK, because the assumption/model is that all neighboring routers are equal, and if you have a working one, there is no need to check for a better one. NUD handles the case where a next-hop fails and another one should be tried.

With this document, the model changes. There is an assumption that some routers are better than others, and which router is better for a destination depends on the actual route prefixes that are advertised. That raises an issue of consistency. Are the neighbors that are being used always consistent with the known preferences of the routers? In particular, if a higher preference router is not reachable, when is it probed? Or, suppose there is a change in the routing table (a prefix is added or deleted), is there an attempt to (or a need to) revalidate that all the next-hops currently in use are the right ones based on the priorities/prefixes?

It seems to me that a users of this document will intuitively expect that when the highest preference router is reachable, it will be used. Or when a higher preference router becomes available, routes will be updated to use it.

the document says:

> 3.3. Destination Cache Management

>

> When host C processes a Router Advertisement and updates its

> conceptual Routing Table, it SHOULD invalidate or remove Destination

> Cache Entries and redo next-hop determination for destinations

> affected by the Routing Table changes. The host MAY implement this

> requirement by flushing its entire Destination Cache.

Seems like the above SHOULD should be a MUST, in order to meet the principle of least astonishment. [DT: done]

However, the MAY seems ill-advised, as the Destination Cache may also include other information (e.g., path MTU info?) that should not be flushed as a side-effect of such a route change. Can the above be implemented reasonably without resorting to just flushing the table and rebuilding whenever a change is present? [DT removed sentence]

[Rich Draves] I view this as a quality of implementation issue. In many environments advertised preferences & routes might change rarely so a minimal implementation might choose simplicity. However my implementation does what you want - it incrementally revalidates Destination Cache Entries when routes & preferences change.

[Thomas Narten] One problem with the above is you assume that the implementor has knowledge about the enivironments in which technology will be deployed, and can thus make such tradeoffs. Is this a valid assumption here? I suspect that in this case, the implementor can only assume that it will be deployed in general and widely-diverse enivoronments and that the above assumptions simply cannot be reasonably made.

It would be better if the spec did not allow poor implementation choices (that have undesirable consequences on the internet) to be considered "in conformance with the standard".

[Robert Elz]

| One problem with the above is you assume that the implementor has

| knowledge about the enivironments in which technology will be

| deployed, and can thus make such tradeoffs.

Naturally. This applies to all implementation choices in just about everything, from how much RAM is (and can be) installed, to what protocols are supported.

If the implementor hasn't implemented the protocols with the features that are required, or in the way that makes sense for a particular environment, then that implementation should not be used there.

| It would be better if the spec did not allow poor implementation

| choices (that have undesirable consequences on the internet) to be

| considered "in conformance with the standard".

If they actually have undesirable consequences for the internet, I'd agree. But I don't see that here, only possibly undesirable consequences for the customer who installed the equipment. Given that, thanks for caring, but I want to be able to acquire cheap implementations when those are adequate for my purposes.

[Thomas Narten]

> Naturally. This applies to all implementation choices in just about

> everything, from how much RAM is (and can be) installed, to what

> protocols are supported.

> If the implementor hasn't implemented the protocols with the features

> that are required, or in the way that makes sense for a particular

> environment, then that implementation should not be used there.

You are assuming that an end user will have the choice of not using a feature. If the device is (say) a PDA, you might not have the ability to turn it off or otherwise control its usage. For better or worse, I think there are fewer and fewer places where the implementor really has a good idea of where something will be deployed. Consequently, we have to assume things will be deployed in the general internet, not in some sort of restricted environment (or include an applicability statement saying where something shouldn't be used).

> | It would be better if the spec did not allow poor implementation

> | choices (that have undesirable consequences on the internet) to be

> | considered "in conformance with the standard".

> If they actually have undesirable consequences for the internet, I'd

> agree. But I don't see that here, only possibly undesirable consequences

> for the customer who installed the equipment. Given that, thanks for

> caring, but I want to be able to acquire cheap implementations when

> those are adequate for my purposes.

My text relates to flushing the entire ND cache and losing associated cached PMTU information. Are you saying this is OK to do this and doesn't have harmful consequences?

[Markku Savola]

If we have two routes

    prefix1/K -> router1

    prefix2/L -> router2

with K < L, and such that prefix1/K == prefix2/K (e.g. shorter prefix also covers addresses of the longer prefix).

(...)

- if router2 is not reachable, obviously packets matching prefix2/L can be sent to router1. But, is there any advice on algorithm how the system detects if router2 becomes available? Just wait for RA? Probe with some logic?. (There is no RA in IPv4 -- I think this should work for IPv4 too!)

Note: default routes are just a special case where K=0

[Rich Draves] As kre points out I think the draft answers your questions, but I want to followup on one point that should probably be clarified in the draft. When you say "currently unreachable (no entry in neighbor cache)" it sounds like you might have a misunderstanding. If the host has no information about the router's reachability then the host should assume the router is reachable. [Done]

[Markku Savola] Hmm.... the IPv6 neighbor discovery says that after probes fail, entry should be removed, see RFC-2461 7.3.3

> Upon entering the PROBE state, a node sends a unicast Neighbor

> Solicitation message to the neighbor using the cached link-layer

> address.....

> ..... If no response is received after waiting RetransTimer

> milliseconds after sending the MAX_UNICAST_SOLICIT solicitations,

> retransmissions cease and the entry SHOULD be deleted.

As to 3.4 in internet-drafts/draft-ietf-ipv6-router-selection-02.txt, it talks only about routers X and Y.

Playing nasty, I imagine situation where I have routers X, Y and Z (with prefix lengths X > Y > Z) and destination matching all of them. Now, if only Z is currently reachable, I should probably probe both X and Y using some logic...

[Rich Draves] I think to implement router-selection, you need to keep track of whether a router is reachable or unreachable. Whether that's in the Neighbor Cache Entry or not and how it interacts with the ND states is an implementation concern that is not specified in the draft.

Note that RFC 2461 does not really say that implementations should delete a data structure, it is saying that implementations should behave as if the conceptual data structure were deleted. RFC 2461 is a protocol spec not an implementation spec.

Yes both X & Y should be probed. I think section 3.4 implies that, although it could be clarified. Section 3.4 says "When a host avoids using a non-reachable router X ..." - it's quite possible for this clause to apply to more than one router.   [DT: Done]

[Erik Nordmark] "probe" isn't well-defined. There are two possible interpretations:

    1. Send a single unicast neighbor solicitation

    2. Do what RFC 2461 does when in the PROBE state (implies retransmitting NS messages N times)

I think #1 is the intent; it would make sense to state that explicitly. [DT: Done]

[Dave Thaler]: also changed spec to say once a minute

[Thomas Narten]  I'm also unclear as to how easy it will be to implement the specific lookup algorithm that type C hosts will implement. My understandinng is that routing lookups today are done using longest-match, where the lookup stops at a particular node in the tree. I could imagine multiple nodes being at the same point in the tree (i.e., corresponding to two or more instances of a prefix but using different routers with possibly different preferences).

But the algorithm specified actually says reachable routers are to be preferred over unreachable ones. This means that the longest-match lookup may stop at a node with an unreachable router. What is done in this case? Does one have to unwind the tree search to try a node visited earlier (i.e., a shorter match?)? Is this reasonable for implementations? [note: its not immediately clear that one can just remove nodes from the routing tree that correspond to unreachable routers, because one must also probe these routers in some cases.]

Another implementation complexity is due to the preferences combined with the reachability status. Many implementations have a user-level process which takes preferences into account and only installs the most preferred route for a given prefix into the kernel. Hence the kernel need not be aware of preferences. Given the reachability status all routes need to be in the kernel since the most preferred for a given prefix might be unreachable and a less preferred route might exist for the identical prefix.

Q: who has implemented this draft? Can they comment on the implementations issues mentioned above?

[Rich Draves] I've implemented it (except for the new load-sharing part). Yes, the kernel needs to know all the routes.

Keep in mind that the new Conceptual Sending Algorithm (section 3.2) applies only to hosts. Optimized router implementations, designed to support zillions of routes, are not affected.

Now my route lookup is not particularly optimized so this wasn't an issue. But I have thought a bit about how I'd use a fancy longest-matching-prefix data structure. I think you could do a first tree search looking for a reachable router. If that fails, then you search again for an unreachable router. In either case, you end up at a node that has all the routes of the same length, and you pick the one with the best preference. And for load-sharing, choose randomly among the routes with the same preference.

[Thomas Narten] Agreed. I'd still be interested from other folks that have (or are considering) implementing it.

[No change needed]

> Routers SHOULD NOT include in a Router Advertisement two Route

> Information Options with the same Prefix and Prefix Length.

[Thomas Narten] Seems like MUST NOT would be better. Is there ever a valid reason to allow routers to include two such options?

[Rich Draves] OK. I don't know of a valid reason.

> If the Reserved

> (10) value is received, the Route Information Option

> MUST be ignored.

[Thomas Narten] Why ignored? In the case where PrF is in the message header, the rules say treat the value as 00. What is the motivation for handling these two case differently?

[Rich Draves] Actually, when Prf in the message header is 10, the rules say to treat the *Router Lifetime* as 0. This means there is no default route, which is like ignoring the Route Information Option. So I think the two cases are handled similarly.

[Thomas Narten] Not quite the same. A lifetime of 0 would update/replace the lifetime for an existing route. Just ignoring the option wouldn't do that.

I think what you want here is to design for future extensibility. If sometime in the future, someone were to define a usage for the 10 value, you wouldn't want existing implementations to do things that prevent the new usage. Seems like having such entries be completely ignored would be more flexible than having it treated like a lifetime of 0. I.e, the current semantics might effectively prevent being able to define the value later because of what existing implementations will then do with it.

But, given that there are existing implementations that will never look at the preference value, I think the safest thing to do is go with "treat the value as if it had the default preference".

[Rich Draves] OK

> 1. It allows for a distinction between "best default router" and

> "best router for default", as described below in section 5.1.

>

> 2. When the best default router is also the best router for

> default (which will be a common case), encoding the preference

> value in the message header is more efficient than having to send

> a separate option.

[Thomas Narten] After a number of re-reads, I still do not understand the above distinction. I think I understand the example, but the explanatory text above is not intuitive at all.

Suppose you have a host with two next-hop routers, R1 and R2. R1 connects the host to the rest of the internet. R2 connects the host to a specific /48. 99% of the host's traffic goes to that /48. Then R2 is the best default router for the host, because sending traffic to R2 will produce the fewest Redirects. But R1 is the best router for ::/0.

[Thomas Narten]

> You mean you don't understand the distinction between "best default

> router" and "best router for default"?

Its a subtle distinction and the terms used to distinguish are not very intuitive.

> I have to give credit to Steve Deering for pointing it out to me.

> Here's the idea again (although I think section 5.1 already says

> this):

Note that the paragraph quoted above which introduces the terms precedes section 5.1 quite a lot.

> Suppose you have a host with two next-hop routers, R1 and R2. R1

> connects the host to the rest of the internet. R2 connects the host to

> a specific /48. 99% of the host's traffic goes to that /48. Then R2 is

> the best default router for the host, because sending traffic to R2

> will produce the fewest Redirects. But R1 is the best router for ::/0.

I understand the example (though I'm not immediately convinced the distinction is terribly useful). But that doesn't mean the definitions of the terms will make sense to the reader. It would be nice if you could define/explain the two terms without having to use that example. Can't the difference be described intuitively, and not with a circular definition?

two suggestions. The first reference to the words (which doesn't define them) includes a forward reference to much later in the document. It would be nice to not need the reference, since the first use of the terms doesn't at all explain them. The later words could be better:

I.e.,

> The best default router is not quite the same thing as the best

> router for default. The best default router is the router that will

> generate the fewest number of redirects for the host's traffic. The

> best router for default is the router with the best route toward the

> wider internet.

How about changing the last part of the last sentence:

> The best router for default is the router with the best route

> toward the wider internet.

But, I still think these terms are confusing and not particularly useful.

[Robert Elz]

| > You mean you don't understand the distinction between "best default

| > router" and "best router for default"?

|

| Its a subtle distinction and the terms used to distinguish are not

| very intuitive.

It isn't that subtle, but it is also not very important in most cases.

It sounds as if it should be, but unless the implementation is ignoring redirects, it isn't the volume of traffic that matters, but the number of different destinations. Then the best default router, and the best route to default, tend to be the same thing (you get one redirect for each local destination, and use that redirect to send large amounts of traffic), you get no redirects for the large numbers of different destinations all over the net, to each of which you probably send almost no traffic at all. That's better than no redirects for the comparatively smaller number of local hosts, and lots of redirects for all the rest, or it is in many cases.

If we had "redirect this prefix" instead of just "redirect this address" then there would be almost no rationale at all for splitting the two concepts. "Type C" hosts (which will probably turn out to be most of them) won't care anyway, they'll see the routes announced, and rarely ever see any kind of redirect.

[Erik Nordmark]

> Suppose you have a host with two next-hop routers, R1 and R2. R1

> connects the host to the rest of the internet. R2 connects the host to

> a specific /48. 99% of the host's traffic goes to that /48. Then R2 is

> the best default router for the host, because sending traffic to R2

> will produce the fewest Redirects. But R1 is the best router for ::/0.

I don't understand what this means.

"Best router for ::/0" is the same as best default router in my mind.

As far as I can tell the distinction you are trying to make only makes sense when the question asked is "which is the best router for prefix P". But the node cares about "which is the best router for destination D" - nodes don't send packets to prefixes - they send packets to addresses.

So I'm utterly confused.

[DT] Changed "best default" to "least likely to redirect"

> If there are no routes matching the destination (i.e., no default

> routes and no more-specific routes), then if a type C host has a

> single interface then it SHOULD assume the destination is on-link to

> that interface. If the type C host has multiple interfaces then it

> SHOULD discard the packet and report a Destination Unreachable / No

> Route To Destination error to the upper layer.

this "onlink-by-default" rule has big problems, and it has been removed in rfc2461bis -- I think it should be removed from here as well, or at least reworded. Additionally, there doesn't appear to be anything router-selection specific here.

[Dave Thaler] Proposed text:

> If there are no routes matching the destination (i.e., no default

> routes and no more-specific routes), then a type C host

> SHOULD discard the packet and report a Destination Unreachable / No

> Route To Destination error to the upper layer.

> A malicious node could send Router Advertisement messages,

> specifying High Default Router Preference or carrying specific

> routes, with the effect of pulling traffic away from legitimate

> routers. However, a malicious node could easily achieve this same

> effect in other ways. For example, it could fabricate Router

> Advertisement messages with zero Router Lifetime from the other

> routers, causing hosts to stop using the other routes. Hence, this

> document has no new appreciable impact on Internet infrastructure

> security.

this is inaccurate. There is a significant difference between a blackhole attack, and a redirection attack. Redirection can e.g., be a trivial way to mount MITM attacks. This draft actually makes it even easier. This needs to be explained better in this memo, with appropriate pointers to SEND stuff.

[RD] "However, by advertising a specific prefix, this attack could be carried out in a less noticeable way.  Hence, this document has no significant incremental impact..."

[DT] Made the above change and added a reference to RFC 3756.  See issue 17 for the new text.

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

==> a host can be multi-homed (at the site level) while still having only

one interface, so proposing to reword: s/multi-homed/multi-homed (through

multiple interfaces)/

> scenarios can add additional tunnels. For example, hosts may have

> 6-over-4 [RFC3056] or configured tunnel [RFC1933] network

==> s/6-over-4/6to4/

==> rFC1933 has been obsoleted, soon twice :-)

> values. If the host has no information about the routerÆs

==> strange character, should be "'" ? (many other places as well)

> As one exception to this general rule, the administrator of a router

> that does not have a connection to the internet, or is connected

==> s/internet/Internet/

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

==> s/Here's another scenario:/In another scenario,/

==> remove "6bone".

> Author's Addresses

==> s/Author's/Authors'/

> Full Copyright Statement

==> one must add an IPR boilerplate before this section.

==> as a preface, one should IMHO discuss how this relates to the router reachability probing of RFC2461. As far as I see, the only difference here is that that unreachable, preferable routers are explicitly being probed to notice when they become reachable again -- while with vanilla RFC2461 this doesn't matter as all the routers are equally preferable.

[RD] agree.

[DT] Proposed text at end of 3.5:

For a type A host (following the algorithm in [RFC2461]), no probing is needed since all routers are equally preferable.  A type B or C host, on the other hand, explicitly probes unreachable, preferable routers to notice when they become reachable again.

[Suresh Krishnan]

When the better router becomes available again(say due to a system restart) it will send a new RA message which can trigger the switchover to the better router. Why is the probing needed at all?

[RD] because sometimes it's an intermediate problem like a hub coming back up.  Yes this could be explained.

[DT] Old text:

This requirement allows the host to discover when router X becomes reachable and to start using router X at that point. Otherwise, the host might not notice router X's reachability and continue to use the less-desirable router Y.

Proposed text:

This requirement allows the host to discover when router X becomes reachable and to start using router X at that point. Otherwise, the host might not notice router X's reachability and continue to use the less-desirable router Y until the next Router Advertisement is sent by X. Note that the router may have been unreachable for reasons other than being down (e.g., a switch in the middle being down), so it may be up to 30 minutes (the maximum advertisement period) before the next Router Advertisement would be sent.

> 5.1. Best Router for ::/0 vs Router Least Likely to Redirect

==> I think these examples show, that if you don't know which type of nodes (A, B vs C) there exist in the network, the optimal network configuration can be a very delicate process.

[RD] sure

This should be explicitly called out somewhere.

[DT] propose text?

Another approach might be "disallowing" type B hosts, requiring full router-selection implementation, which would simplify the types and the configuration quite a bit.

[DT] B is a relatively minor change from A, but C may entail a significant rewrite. 

[Pekka Savola]
Maybe add something like below to section 5, just before 5.1 as it seems to apply to 5.2 as well:

It is worth noting that the network administrator setting up preferences and/or more specific routes in Routing Advertisements typically does not know which kind of nodes (Type A, B, and/or C) will be connected to its links. This requires that the administrator will need to configure the settings that will work in an optimal fashion no matter which kinds of nodes will be attached.

[DT] Added proposed text at end of section 4.1 (Guidance to Administrators) which is immediately above the section 5 header and hence immediately above the 5.1 header.

Section 7 talks about "packet diagrams", but these have now gone.  [DT: no, it's still there in 2.2]

Section 3.1 para 4 says the right stuff, but maybe the sentences are in the wrong order. It jumps from talking about what to do with a specific route option, updating ::/0 from the main header, then talks about walking through the route options one by one. Maybe a little reordering needed?

[DT] proposed text reorders as follows:
When a type C host receives a Router Advertisement, it modifies its Routing Table as follows. When processing a Router Advertisement, a type C host first updates a ::/0 route based on the Router Lifetime and Default Router Preference in the Router Advertisement message header. Then as the host processes Route Information Options in the Router Advertisement message body, it updates its routing table for each such option. The Router Preference and Lifetime values in a ::/0 Route Information Option override the preference and lifetime values in the Router Advertisement header. Updating each route is done as follows.  If the received route's lifetime is zero, the route is removed from the Routing Table if present. If a route's lifetime is non-zero, the route is added to the Routing Table if not present and the route's lifetime and preference is updated if the route is already present. A route is located in the Routing Table based on prefix, prefix length, and next-hop router.

Section 1 references RFC1933. This should maybe be RFC2893. [DT: done]

Section 2.2 discusses the "Prf" field. Concerning the interpretation of the Prf field by receivers, it says (I've elided some stuff):

(A) If Router Lifetime is zero, it ... MUST be ignored by the receiver.

(B) If the Reserved (10) value is received, the receiver MUST treat the treat the value as if it had the value 00.

The latter sentence has multiple "treat" and "value" which could be removed. [DT: done]

Why does (A) say "ignore", implying treat as 00, while (B) says explicitly "treat as 00"? If there is some subtle difference here then I haven't grasped it, else could they both say the same thing?
[DT comment] No change?  See Issue 9.

[Tim Gleeson]

Thanks for cleaning up the multiple "treat" and "values".

But the definition of "Prf" is section 2.2 still has some ambiguity. Here's your new pre-04 text:

(1)Prf (Default Router Preference)

(2) 2-bit signed integer.

(3) Indicates whether or not to prefer this router over other default routers.

(4) If Router Lifetime is zero, it MUST be initialized to zero by the sender and MUST be ignored by the receiver.

(5) If the Reserved (10) value is received, the receiver MUST treat the value as if it were 00.

Looking at (4). The word "it" could refer to the preceding "Router Lifetime"

(wrong?) or to "Prf" (right?). The second "MUST" isn't preceded by a noun so it presumably refers to the preceding "it". I think that's wrong in either interpretation.

Here's a suggestion to try and clarify, though I'm still unsure if this is what is intended:

(4.1) If Router Lifetime is zero, Prf MUST be set to (00) by the sender and the Router Advertisement MUST be ignored by the receiver for router selection purposes.

Looking at (5). Change "00" to "(00)" for consistency?

[DT]

Previous text:

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 MUST treat the value as if it were 00.

Proposed text:

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, the preference value MUST be set to (00) by the sender and MUST be ignored by the receiver. If the Reserved (10) value is received, the receiver MUST treat the value as if it were (00).

In the security considerations, the draft mentions that this draft is no worse than status quo. But it may not be so. With 2461 a router advertisement expires after a maximum of 18 hrs. But with this draft we can send a route information option with an infinite lifetime. Thus the effect of a misconfigured/malicious router can linger around for longer.

[DT] Probing continues forever.  Similar to prefix information option with infinite lifetime.  Compare 4.6.2 of RFC2461.  Will lose connectivity all together.

Proposed text:

A malicious node could send Router Advertisement messages, specifying High Default Router Preference or carrying specific routes, with the effect of pulling traffic away from legitimate routers. However, a malicious node could easily achieve this same effect in other ways. For example, it could fabricate Router Advertisement messages with zero Router Lifetime from the other routers, causing hosts to stop using the other routes.  By advertising a specific prefix, this attack could be carried out in a less noticeable way.  However, this attack has no significant incremental impact on Internet infrastructure security.

A malicious node could also include an infinite lifetime in a Route Information Option causing the route to linger indefinitely.  A similar attack already exists with Prefix Information Options in RFC2461, where a malicious node causes a prefix to appear as on-link indefinitely, resulting in lack of connectivity if it is not.  In contrast, an infinite lifetime in a Route Information Option will cause router reachability probing to continue indefinitely, but will not result in lack of connectivity.

RFC3756 provides more details on the trust models, and there is work in progress in the SEND WG on securing router discovery messages that will address these problems.

Section 2.2 Changes to RA message:

This draft assumes the presence of the H bit in the RA message. The MIPv6 spec which defines this is still a draft. Assuming that it becomes a standard this draft still needs to mention MIPv6 as a normative reference.

[DT comment]: MIPv6 is now RFC3775.  Added MIPv6 as a normative reference.

Section 5.2:

Router X and router Y are mixed up in paragraph 1 and 3.

para 1 mentions

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

para 3 mentions

"For example, router X on the isolated network should advertise a Route Information Option for the isolated network prefix."

[DT: done]

When a parameter is changed (e.g. the operator changes the default router preference or adds a route option) what should the router do?  I guess it's implicit it should do the same as [RFC2461,6.2.4,last para] i.e. as for "becoming an advertising interface". If so, could this be made explicit?

[DT,RD] Agree

When a router interface is going down: [RFC2461,6.2.5] currently says

(roughly) "SHOULD transmit one or more RAs with Router Lifetime zero". I'm uncertain if this would clear a ::/0 route in a type C host - the text currently says "updates a ::/0 route ... based on the Router Advertisement message header". Does "update" encompass "delete"?

[DT] Section 3.1 says "If the received route's lifetime is zero, the route is removed from the Routing Table if present."

Also, such a final RA wouldn't clear any more specific routes. Does the latter case need some more text e.g. "SHOULD send all more specific routes with lifetime zero" or somesuch?

[DT,RD] Agree

[DT] Proposed text:

The information contained in Router Advertisements may change through actions of system management.  For instance, the lifetime or preference of advertised routes may change, new routes could be added, etc.  In such cases, the router MAY transmit up to MAX_INITIAL_RTR_ADVERTISEMENTS unsolicited advertisements, using the same rules as in [RFC2461].  When ceasing to be an advertising interface and sending Router Advertisements with a Router Lifetime of zero, the Router Advertisement SHOULD also set the Route Lifetime to zero in all Route Information Options.

* The length can be more tightly specified. For example if the prefix length is 0 the draft allows the length to be 1,2 or 3 while it is sufficient to specify 1 as the only valid value for the length. Is there a reason for this?

[DT comment]: "Be liberal in what you accept and conservative in what you send".

* Since the preference is in the middle of the octet (between the reserved fields) the host needs to do an arithmetic shift for this to be used. Is this necessary?

[RD comment]: The preference bits are in the same location in both the header and the option, allowing common code.  The bits in the header are there because those are the next bits available.

* The following statement

"If a host processes a Router Advertisement carrying multiple Router Information Options with the same Prefix and Prefix Length, it MUST process one of the options (unspecified which one) and it MUST effectively ignore the rest."

implies that the host needs to keep state about the previously encountered route information options in the message. Does this need to be specified?

[DT comment]: Removed this sentence.

[Jim Bound]

I am fine with this and it is good spec. One question in my mind is do we want to use up precious RSVD bits in the RA message or make this an option? It would also work as option as I see it and save using up the RA RSVD header bits.

[DT comment] The WG already has rough consensus and running code as is.  We are glad that you are "fine with this" :).

[Alex Zinin comment on draft -05] (Sept.26, 2004):
> > Routers MUST NOT include two Route Information Options with the same
> > Prefix and Prefix Length in the same Router Advertisement.
>
> What should the receiver do if it does find more than one RIOs for the
> same prefix in the same message? a) honor 1st, ignore others; b) honor
> last, ignore others; c) ignore all?

[DT] Draft -03 contained the sentence:
"If a host processes a Router Advertisement carrying multiple Router Information Options with the same Prefix and Prefix Length, it MUST process one of the options (unspecified which one) and it MUST effectively ignore the rest."

In Issue #20 (http://www.icir.org/dthaler/RouterSelectionIssues.htm#Issue20)
it was pointed out that this "implies that the host needs to keep state about the previously encountered route information options in the message. Does this need to be specified?"

This sentence was removed in draft-04 as a result, allowing the implementation the freedom to do any of a, b, or c (b being the simplest implementation).
 

[Alex Zinin] Given that inconsistent decisions among hosts will not lead to loops, I agree that this is OK to be left unspecified.