Default Router Preferences and More-Specific Routes
RFC 4191

Note: This ballot was opened for revision 07 and is now closed.

(Steven Bellovin) Discuss

Discuss (2004-10-05 for -)
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?

(Margaret Cullen) Yes

(Harald Alvestrand) No Objection

Comment (2004-09-16 for -)
No email
send info
Reviewed by Mary Barnes, Gen-ART

(Bill Fenner) (was Discuss) No Objection

Comment (2004-11-03)
No email
send info
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"

(Scott Hollenbeck) No Objection

(Russ Housley) No Objection

(David Kessens) No Objection

(Allison Mankin) No Objection

Comment (2004-09-16 for -)
No email
send info
It's nice to have a such a well-written document on our agenda.

(Thomas Narten) No Objection

Comment (2004-09-16 for -)
No email
send info
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.

(Jon Peterson) No Objection

(Bert Wijnen) (was Discuss) No Objection

(Alex Zinin) (was Discuss) No Objection