Default Router Preferences and More-Specific Routes
draft-ietf-ipv6-router-selection-07

Suggested RFC Editor Note to address Alex's concerns:

To: Alex Zinin , "Dave Thaler"
From: Margaret Wasserman
Subject: Re: draft-ietf-ipv6-router-selection-06.txt
Cc: "Bob Hinden" , "Richard Draves" , "Thomas Narten" , "Brian Haberman" , Mark Townsley
Bcc:
X-Attachments:


Picking this thread back up...

Rich and Dave both indicated that they are okay with adding this text via an RFC Editor note, but I'm not quite sure where it should go in the document...

Maybe, in section 1 (Introduction):

OLD:

  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 for an
  off-link destination.

NEW:

  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 for an
  off-link destination.

  Note that since these procedures are applicable to hosts only, the
  forwarding algorithm used by the routers (including hosts with enabled IP
  forwarding) is not affected.

Would that work?  Or did you have somewhere else in mind?

Bob and Brian, has this text been run by the WG?

If we can resolve Alex's issue, this document can be published.

Thanks,
Margaret


At 10:50 AM -0600 3/8/05, Alex Zinin wrote:
>Dave,
>
>  Right, I understand the formal definitions.
>
>  Given that it is a rather important point, may I suggest adding a note (m.b.
>  via an RFC-Editor note) saying something like this:
>
>    Note that since these procedures are applicable to hosts only, the
>    forwarding algorithm used by the routers (including hosts with enabled IP
>    forwarding) is not affected.
>
>--
>Alex
>http://www.psg.com/~zinin
>
>Tuesday, March 8, 2005, 9:26:32 AM, Dave Thaler wrote:
>>> -----Original Message-----
>>> From: Alex Zinin [mailto:zinin@psg.com]
>>> Sent: Tuesday, March 08, 2005 8:51 AM
>>> To: Margaret Wasserman
>>> Cc: Bob Hinden; Dave Thaler; Richard Draves; Thomas Narten; Brian
>> Haberman
>>> Subject: Re: draft-ietf-ipv6-router-selection-06.txt
>>>
>>> Margaret, Dave, guys-
>>>
>>>  I read section 3.2 now, and it seems that the comment I provided
>> earlier
>>> wasn't
>>>  addressed:
>>>
>>> > I read section 3.2 in the new rev. The look-up algo description is
>> less
>>> > confusing now. Though I don't like the fact that the tree needs to
>> be
>>> walked
>>> > back to find the next best match, I can remove my objection if you
>> make
>>> it clear
>>> > that the routing table lookup for the case with enabled ip-fwd'ing
>> is
>>> not
>>> > changed. The reason I'm worried about it is because one can get
>> routing
>>> loops
>>> > if your algo is used for packet forwarding.
>>>
>>>  Unless I missed more discussion.
>
>> Section 3.2 is titled "Conceptual Sending Algorithm for Hosts", and
>> the word "host" occurs multiple times in the description of the lookup
>> algorithm.  Section 3 applies to hosts, per the section title.  Section
>> 4 applies to routers, per the section title.
>
>> RFC 2460 defines these terms as:
>>    router      - a node that forwards IPv6 packets not explicitly
>>                  addressed to itself.  [See Note below].
>
>>    host        - any node that is not a router.  [See Note below].
>
>>    Note: it is possible, though unusual, for a device with multiple
>>    interfaces to be configured to forward non-self-destined packets
>>    arriving from some set (fewer than all) of its interfaces, and to
>>    discard non-self-destined packets arriving from its other interfaces.
>>    Such a device must obey the protocol requirements for routers when
>>    receiving packets from, and interacting with neighbors over, the
>>    former (forwarding) interfaces.  It must obey the protocol
>>    requirements for hosts when receiving packets from, and interacting
>>    with neighbors over, the latter (non-forwarding) interfaces.
>
>> Hence, when ip-fwd'ing is enabled, one is not a host, and all sections
>> of all RFCs that use the term "host" do not apply.  It's no different
>> for this document.
>
>> Do you still feel that an explicit statement is required that repeats
>> the standard definitions of host and router?
>
>> -Dave
>

Sent ping to authors regarding expected update:

To: richdr@microsoft.com, Dave Thaler
From: Margaret Wasserman
Subject: draft-ietf-ipv6-router-selection-06.txt
Cc: Alex Zinin , Thomas Narten , Bob Hinden , Brian Haberman
Bcc:
X-Attachments:


Hi Rich and Dave,

I just wanted to check on the status of draft-ietf-ipv6-router-selection-06.txt...

There is still one discuss open on this document from Alex (see text below).  IIRC, there was a discussion in the IPv6 WG meeting in D.C. regarding how to resolve Alex's issues, and we reached some agreement on the text.  When will you have an update that reflects those changes?

Margaret

Alex Zinin:
Discuss:
[2004-09-15] > 2.1. Preference Values
>
>    Default router preferences and preferences for more-specific routes
>    are encoded the same way.
>
>    Preference values are encoded in two bits, as follows:
                                  ^
                      please add "as a signed integer"
                      helps a lot when you look at the values
                      below first time
                     
>        01      High
>        00      Medium (default)
>        11      Low
>        10      Reserved - MUST NOT be sent
>    Note that implementations can treat the value as a two-bit signed
>    integer.

> 2.3. Route Information Option
...
>    Route Lifetime
>                32-bit unsigned integer. The length of time in seconds
>                (relative to the time the packet is sent) that the
>                prefix is valid for route determination. A value of all
>                one bits (0xffffffff) represents infinity.

should the doc say somewhere that if a route announced with infinity lifetime
later needs to be removed, it has to be explicitly withdrawn by an announcement
with a 0 lifetime?

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

> 3.2. Conceptual Sending Algorithm for Hosts
...
>  When a type C host does next-hop determination and consults its
>    Routing Table for an off-link destination, it first prefers
>    reachable routers over non-reachable routers, second uses longest-
>    matching-prefix, and third uses route preference values.  Again, if
>    the host has no information about the router's reachability then the
>    host assumes the router is reachable.

It seems there is a mistake in the above algorithm. If we follow it, a
non-matching prefix via a reachable router may be selected. Did you mean
matching routes through reachable routers over routes through unreachable
routers?

In general, however, I must note that this route look-up algorithm is not
compatible with the longest-match-first one, which has to be used even by hosts
when configured in ip forwarding on. I'm wondering if there was any discussion
on this in the WG.

> 4. Router Configuration
>
>    Routers should not advertise preferences or routes by default. In
>    particular, they should not "dump out" their entire routing table to

Should the two instances of "SHOULD NOT" above be capitalized?

>    hosts. Routers MAY have a configuration mode where a filter is
>    applied to their routing table to obtain the routes that are
>    advertised to hosts.

Well, the last one is honestly a recipe for a disaster for two reasons--"permit
any any" configuration mistake, and route flap dynamics. If you really want to
do somewhat dynamic route monitoring, it should probably be specified this way:

Routers MAY have a configuration mode where announcement of a specific prefix
is dependent on a specific condition, such as operational status of a link or
presence of the same or another prefix in the routing table installed by
another source, such as a dynamic routing protocol. If done, router
implementations MUST make sure that:

  1. Announcement of prefixes to hosts is decoupled from the routing table
    dynamics to prevent excessive load on hosts during periods of routing
    instability. In particular, unstable routes SHOULD NOT be announced
    to hosts until their stability has improved.

  2. The implementation either disallows processing of incoming Router
    Advertisements on interfaces with the AdvSendAdvertisements flag set to
    FALSE while sending outgoing Router Advertisements on others, or does not
    consider routes received in Router Advertisements from other routers
    as satisfying its own condition for prefix announcement.

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

2119-ize "should not" and "should" above?

> 6. Security Considerations

Should probably mention the possibility of overloading hosts with excessive
routing info when a router implementation is not careful about the amount
of info and frequency of its updates announced to hosts.

Ping sent to authors (see below).  Expect further revisions to address Alex's comments.

To: richdr@microsoft.com, dthaler@microsoft.com
From: Margaret Wasserman
Subject: draft-ietf-ipv6-router-selection-06.txt
Cc: Bob Hinden , Brian Haberman , Thomas Narten , "Wijnen, Bert (Bert)"
Bcc:
X-Attachments:


Hi Rich and Dave,

I think I have lost the thread on draft-ietf-ipv6-rotuer-selection-06.txt...

The document has been udpated since the IESG review, and I believe that it now addresses Bert's discuss regarding the use of examples from the documentation prefix.  Bert, if you agree, please clear your discuss.

However, the document does not seem to have been updated to address Alex's discuss (included below).  Are you working on another update to address these issues?  At least some of them seem quite straightforward...  Is there contention about any of them?

If you are not sure what changes are necessary to address Alex's concerns, we could hold a phone conference to discuss them.  Do you think that would help?

Thanks,
Margaret

Alex Zinin:
Discuss:
[2004-09-15] > 2.1. Preference Values
>
>    Default router preferences and preferences for more-specific routes
>    are encoded the same way.
>
>    Preference values are encoded in two bits, as follows:
                                  ^
                      please add "as a signed integer"
                      helps a lot when you look at the values
                      below first time
                     
>        01      High
>        00      Medium (default)
>        11      Low
>        10      Reserved - MUST NOT be sent
>    Note that implementations can treat the value as a two-bit signed
>    integer.

> 2.3. Route Information Option
...
>    Route Lifetime
>                32-bit unsigned integer. The length of time in seconds
>                (relative to the time the packet is sent) that the
>                prefix is valid for route determination. A value of all
>                one bits (0xffffffff) represents infinity.

should the doc say somewhere that if a route announced with infinity lifetime
later needs to be removed, it has to be explicitly withdrawn by an announcement
with a 0 lifetime?

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

> 3.2. Conceptual Sending Algorithm for Hosts
...
>  When a type C host does next-hop determination and consults its
>    Routing Table for an off-link destination, it first prefers
>    reachable routers over non-reachable routers, second uses longest-
>    matching-prefix, and third uses route preference values.  Again, if
>    the host has no information about the router's reachability then the
>    host assumes the router is reachable.

It seems there is a mistake in the above algorithm. If we follow it, a
non-matching prefix via a reachable router may be selected. Did you mean
matching routes through reachable routers over routes through unreachable
routers?

In general, however, I must note that this route look-up algorithm is not
compatible with the longest-match-first one, which has to be used even by hosts
when configured in ip forwarding on. I'm wondering if there was any discussion
on this in the WG.

> 4. Router Configuration
>
>    Routers should not advertise preferences or routes by default. In
>    particular, they should not "dump out" their entire routing table to

Should the two instances of "SHOULD NOT" above be capitalized?

>    hosts. Routers MAY have a configuration mode where a filter is
>    applied to their routing table to obtain the routes that are
>    advertised to hosts.

Well, the last one is honestly a recipe for a disaster for two reasons--"permit
any any" configuration mistake, and route flap dynamics. If you really want to
do somewhat dynamic route monitoring, it should probably be specified this way:

Routers MAY have a configuration mode where announcement of a specific prefix
is dependent on a specific condition, such as operational status of a link or
presence of the same or another prefix in the routing table installed by
another source, such as a dynamic routing protocol. If done, router
implementations MUST make sure that:

  1. Announcement of prefixes to hosts is decoupled from the routing table
    dynamics to prevent excessive load on hosts during periods of routing
    instability. In particular, unstable routes SHOULD NOT be announced
    to hosts until their stability has improved.

  2. The implementation either disallows processing of incoming Router
    Advertisements on interfaces with the AdvSendAdvertisements flag set to
    FALSE while sending outgoing Router Advertisements on others, or does not
    consider routes received in Router Advertisements from other routers
    as satisfying its own condition for prefix announcement.

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

2119-ize "should not" and "should" above?

> 6. Security Considerations

Should probably mention the possibility of overloading hosts with excessive
routing info when a router implementation is not careful about the amount
of info and frequency of its updates announced to hosts.

[Ballot comment]
One issue that I noticed while reviewing -06 that was also in -05:
section 3.2 says that for type B hosts, reachability is preferred
over preference when selecting routes; section 3.5 says that type
B hosts explicitly probe any unreachable preferred routers.  If
reachability is preferred, then presumably the only way that there
are any unreachable preferred routers is that there are no reachable
routers.  This is kind of pedantic so I'm not going to insist on
any change.

A couple of nits that slipped into -06:
- "hose" should be "host" in the next-to-last paragraph of 5.2
   
- In section 2.1, "Note that implementations can treat the value
  as a two-bit signed integer" seems extraneous now that it starts
  "preference values are encoded as a two bit signed integer"

[Ballot discuss]
Unless I badly misunderstand something, the reachability issue is discussed incorrectly.  Suppose a host is connected to routers A and B, and wishes to reach site X.  Further suppose that X is reachable by both paths, but that B is preferable; this new option will indicate that to the sending host.  If, however, B is up but its path towards X is down, the sender's attempt will fail.  But the reachability tests will show that B is up.  While in some sense this is no worse than what we have today, the whole point of this option is to provide better service to multi-homed hosts.  Am I misunderstanding things?

[Ballot comment]
2004-09-15: -05 on agenda

>    Note that implementations can treat the value as a two-bit signed
>    integer.

what is 2-bit signed number? :-)

It would be good to have the protocol explicitely delete/expire all
routes through a router, if the router declares itself to be "going
down", regardless of whether  it remembers to explicitely include an
option for each prefix with lifetime of zero. (This may be the case
already, but I wasn't entirely convinced...)

>    would have sent to the router if it were reachable. In any case,
>    these probes MUST be rate-limited to no more than one per minute per
>    router.

is this timer consistent with generic ND constants? (I would hope it
is.)

section 4.1: assumption simply does not hold in practice, in
particular, consider  the example cited in the introduction:

  Multi-homed hosts are an increasingly important scenario, especially
  with IPv6. In addition to a wired network connection, like Ethernet,
  hosts may have one or more wireless connections, like 802.11 or
  Bluetooth. In addition to physical network connections, hosts may
  have virtual or tunnel network connections. For example, in addition
  to a direct connection to the public Internet, a host may have a
  tunnel into a private corporate network. Some IPv6 transition
  scenarios can add additional tunnels. For example, hosts may have
  6to4 [RFC3056] or configured tunnel [RFC2893] network connections.

I suspect the public connection/private VPN case will be common. And
it will always be the case that they are different administrative
domains. This makes me wonder how generally applicable this technique
will be.

[Ballot comment]
In the 5th paragraph of the intro, should [RFC2893] be a reference
to draft-ietf-v6ops-mech-v2?

The first sentence of the 2nd paragraph of section 2.1 should maybe
be
    Preference values are encoded as a two-bit signed integer, as follows:
since there was a fair bit of confusion about the values chosen, it makes
sense to introduce it right up front.

In the 4th paragraph of 3.1, I'd like to see the last sentence moved
up to immediately after "..done as follows." -- describe how it's
looked up before you describe what to do with what you've looked it up.

The 3rd and 4th sentences of the 5th paragraph of 3.1 (about what type
A and type B hosts would do) could use parallelism -- "an entry for
router X in its Default Router List" vs. "an entry in its Default Router
List for router X".

In the last paragraph of section 4.1, one is left wondering how to
figure out what the optimal settings are.  It might be useful to add
"Two examples of how to do so follow."

In section 5.2, it's left to the reader to decide what a type B host
will do.  It'll probably be able to reach the Internet fine and the
testbed not at all.

[Ballot discuss]
I actually like this a lot, within the scenarios presented by the draft.  I think the concerns are more about "once we have this, what will people do with it?"

In section 3.2, I think the next-hop determination for type C hosts should be rewritten.  A type C host needs to know the longest-match highest-preference route, even if it's to a non-reachable router, because it needs to know to do Router Reachability probing.  Perhaps it could be described as doing longest-match, then removing non-reachable routers, then going to the next longest match if that eliminated all of the possibilities?  It's really kind of "find all prefixes in the routing table that match, order them by prefix length and then priority.  The last route in this ordered list that points to a reachable router is the one to use; if there are any routes later in the list remember them for the algorithm in 3.5".

In section 3.4, for a type C host, is the configured preference value per-prefix?  If not, does it apply to all prefixes, or just the default value in the header?

In section 3.5, does this generalize?  If the host avoids using non-reachable routers X and Y, and instead sends the data packet to another router Z, should it be probing X and Y?  I.e., just the best, or all of the possibilities that were pruned because they were unreachable?

I have the same concerns as Alex regarding router configuration, especially of the filter applied to the routing table.  I do prefer the general mechanism of "advertise this statically configured prefix if this condition applies", where the condition might be "you have a route to the prefix" or "this link is up" or similar.

[Ballot discuss]
> 2.1. Preference Values
>
>    Default router preferences and preferences for more-specific routes
>    are encoded the same way.
>
>    Preference values are encoded in two bits, as follows:
                                  ^
                      please add "as a signed integer"
                      helps a lot when you look at the values
                      below first time
                     
>        01      High
>        00      Medium (default)
>        11      Low
>        10      Reserved - MUST NOT be sent
>    Note that implementations can treat the value as a two-bit signed
>    integer.

> 2.3. Route Information Option
...
>    Route Lifetime
>                32-bit unsigned integer. The length of time in seconds
>                (relative to the time the packet is sent) that the
>                prefix is valid for route determination. A value of all
>                one bits (0xffffffff) represents infinity.

should the doc say somewhere that if a route announced with infinity lifetime
later needs to be removed, it has to be explicitly withdrawn by an announcement
with a 0 lifetime?

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

> 3.2. Conceptual Sending Algorithm for Hosts
...
>  When a type C host does next-hop determination and consults its
>    Routing Table for an off-link destination, it first prefers
>    reachable routers over non-reachable routers, second uses longest-
>    matching-prefix, and third uses route preference values.  Again, if
>    the host has no information about the router's reachability then the
>    host assumes the router is reachable.

It seems there is a mistake in the above algorithm. If we follow it, a
non-matching prefix via a reachable router may be selected. Did you mean
matching routes through reachable routers over routes through unreachable
routers?

In general, however, I must note that this route look-up algorithm is not
compatible with the longest-match-first one, which has to be used even by hosts
when configured in ip forwarding on. I'm wondering if there was any discussion
on this in the WG.

> 4. Router Configuration
>
>    Routers should not advertise preferences or routes by default. In
>    particular, they should not "dump out" their entire routing table to

Should the two instances of "SHOULD NOT" above be capitalized?

>    hosts. Routers MAY have a configuration mode where a filter is
>    applied to their routing table to obtain the routes that are
>    advertised to hosts.

Well, the last one is honestly a recipe for a disaster for two reasons--"permit
any any" configuration mistake, and route flap dynamics. If you really want to
do somewhat dynamic route monitoring, it should probably be specified this way:

Routers MAY have a configuration mode where announcement of a specific prefix
is dependent on a specific condition, such as operational status of a link or
presence of the same or another prefix in the routing table installed by
another source, such as a dynamic routing protocol. If done, router
implementations MUST make sure that:

  1. Announcement of prefixes to hosts is decoupled from the routing table
    dynamics to prevent excessive load on hosts during periods of routing
    instability. In particular, unstable routes SHOULD NOT be announced
    to hosts until their stability has improved.

  2. The implementation either disallows processing of incoming Router
    Advertisements on interfaces with the AdvSendAdvertisements flag set to
    FALSE while sending outgoing Router Advertisements on others, or does not
    consider routes received in Router Advertisements from other routers
    as satisfying its own condition for prefix announcement.

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

2119-ize "should not" and "should" above?

> 6. Security Considerations

Should probably mention the possibility of overloading hosts with excessive
routing info when a router implementation is not careful about the amount
of info and frequency of its updates announced to hosts.

[Ballot discuss]
2.1 says that the preference values can be treated as 2-bit integers.  However, the collating sequence is wrong for that -- "high" is in between "low" and "medium".  If this isn't an error, it needs to be justified, and the comment about  integral values should be deleted.

Unless I badly misunderstand something, the reachability issue is discussed incorrectly.  Suppose a host is connected to routers A and B, and wishes to reach site X.  Further suppose that X is reachable by both paths, but that B is preferable; this new option will indicate that to the sending host.  If, however, B is up but its path towards X is down, the sender's attempt will fail.  But the reachability tests will show that B is up.  While in some sense this is no worse than what we have today, the whole point of this option is to provide better service to multi-homed hosts.  Am I misunderstanding things?

1) Have the chairs personally reviewed this version of the ID and do
  they believe this ID is sufficiently baked to forward to the IESG
  for publication?

Yes

2) Has the document had adequate review from both key WG members and
  key non-WG members? Do you have any concerns about the depth or
  breadth of the reviews that have been performed?

This document received reviews from several members of the IPv6
WG as well as a review on the ipv6mib mailing list.

3) Do you have concerns that the document needs more review from a
  particular (broader) perspective (e.g., security, operational
  complexity, someone familiar with AAA, etc.)?

No concerns.

4) Do you have any specific concerns/issues with this document that
  you believe the ADs and/or IESG should be aware of? For example,
  perhaps you are uncomfortable with certain parts of the document,
  or whether there really is a need for it, etc., but at the same
  time these issues have been discussed in the WG and the WG has
  indicated it wishes to advance the document anyway.

No.

5) How solid is the WG consensus behind this document?  Does it
  represent the strong concurrence of a few individuals, with others
  being silent, or does the WG as a whole understand and agree with
  it?

The support within the IPv6 WG is limited to those people who are
experts or have a vested interest in MIBs.  The remainder of the
group is silent on the document.  It should be noted that there is
apparent broad support on the ipv6mib mailing list.

6) Has anyone threatened an appeal or otherwise indicated extreme
  discontent?  If so, please summarize what are they upset about.

The chairs are unaware of any appeals in the works or of any
serious discontent.

7) Have the chairs verified that the document adheres to _all_ of the
  ID nits?

Yes.

- Technical Summary

This memo defines a Management Information Base (MIB) for use with
network management protocols in the Internet community.  In
particular, it describes managed objects used for managing tunnels
of any type over IPv4 and IPv6 networks.  Extension MIBs may be
designed for managing protocol-specific objects. Likewise,
extension MIBs may be designed for managing security-specific
objects.  This MIB does not support tunnels over non-IP networks.
Management of such tunnels may be supported by other MIBs.

- Working Group Summary

The IPv6 working group has reviewed this document and
this document reflects the consensus of the group.

- Protocol Quality

This document has been reviewed by members of the ipv6@ietf.org
mailing list, the IPv6 working group chairs, and members of the
ipv6mib mailing list.

Submission Questionnaire:

1) Have the chairs personally reviewed this version of the ID and do
  they believe this ID is sufficiently baked to forward to the IESG
  for publication?

Yes

2) Has the document had adequate review from both key WG members and
  key non-WG members? Do you have any concerns about the depth or
  breadth of the reviews that have been performed?

This document received reviews from several members of the IPv6
WG.

3) Do you have concerns that the document needs more review from a
  particular (broader) perspective (e.g., security, operational
  complexity, someone familiar with AAA, etc.)?

The chairs are unaware of any in-depth operational review of this
document.  However, that should not hinder the advancement process.

4) Do you have any specific concerns/issues with this document that
  you believe the ADs and/or IESG should be aware of? For example,
  perhaps you are uncomfortable with certain parts of the document,
  or whether there really is a need for it, etc., but at the same
  time these issues have been discussed in the WG and the WG has
  indicated it wishes to advance the document anyway.

No concerns.

5) How solid is the WG consensus behind this document?  Does it
  represent the strong concurrence of a few individuals, with others
  being silent, or does the WG as a whole understand and agree with
  it?

This document has gone through several major discussions due to its
structure and relationship to other documents.  The chairs feel
that there is solid consensus for this document.

6) Has anyone threatened an appeal or otherwise indicated extreme
  discontent?  If so, please summarize what are they upset about.

The chairs are unaware of any appeals in the works or of any
serious discontent.

7) Have the chairs verified that the document adheres to _all_ of the
  ID nits?

Yes.

- Technical Summary

  This document describes an optional extension to 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.

- Working Group Summary

The IPv6 working group has done extensive review of this document and
this document reflects the consensus of the group.

- Protocol Quality

This document has been reviewed by members of the ipv6@ietf.org
mailing list and by the working group chairs.

[Note]: 'Comments sent to WG 2002-07-25; author acknowledges that new ID is needed; WG will need to re-review at that time due to length of time elapsed.' added by Thomas Narten

Comments sent to WG 2002-07-25; author acknowledges that new ID is needed; WG will need to re-review at that time due to length of time elapsed.