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

It's nice to have a such a well-written document on our agenda.

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"

Reviewed by Mary Barnes, Gen-ART

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.