Subject: RE: Review: draft-ietf-v6ops-onlinkassumption-00.txt

From: "Bound, Jim" <[email-masked]>
Date: Wed, 29 Oct 2003 08:09:55 -0500

> > This entire spec is predicated on statement in 2461 that are 
> > conceptual and not required as compliance to ND RFC 2461.
> 
> Well, the behavior is actually used in section
> 6.3.6 "Default Router Selection" where section 6 is "host 
> specificatio", thus it isn't only a conceptual thing.  
> 6.3.6 says:
>      3) If the Default Router List is empty, assume that all
>         destinations are on-link as specified in Section 5.2.

This is even worse good point.  We have a requirement in 6.3.6 to a
non-normative reference essentially because it is conceptual.   I attach
all of 6.3.6 below which is very clear as I implemented this too.  And
found it to be very friendly to me as implementor for my customers and I
do not want any standard telling me how to deal with my route or link
lookups in the first place.  Not our expertise at all here in IPv6 WG
and we cannot dictate implementation to implementors.

> 
> At a minimum the specification is unclear on the requirements 
> in this space, but the way I read it (and wrote it :-) this 
> is something that nodes are recommended to do.

I agree some cleanup is in order.

My view.

When L bit set and onlink provided use that and if not use default
route.  If no default route and no link prefixes your call as
implementor but not optimal to send the packet anyway.  But as I said
there are cases where they should be sent and implementations need to
determine why and how and when to permit that configuration not the IPv6
WG.

> 
> Thus I think we need to change that recommendation and make 
> the specification clearer in the process.

I agree and that is editing.

/jim

6.3.6.  Default Router Selection

   The algorithm for selecting a router depends in part on whether or
   not a router is known to be reachable.  The exact details of how a
   node keeps track of a neighbor's reachability state are covered in
   Section 7.3.  The algorithm for selecting a default router is invoked
   during next-hop determination when no Destination Cache entry exists
   for an off-link destination or when communication through an existing
   router appears to be failing.  Under normal conditions, a router
   would be selected the first time traffic is sent to a destination,
   with subsequent traffic for that destination using the same router as
   indicated in the Destination Cache modulo any changes to the
   Destination Cache caused by Redirect messages.

   The policy for selecting routers from the Default Router List is as
   follows:

     1) Routers that are reachable or probably reachable (i.e., in any
        state other than INCOMPLETE) SHOULD be preferred over routers
        whose reachability is unknown or suspect (i.e., in the
        INCOMPLETE state, or for which no Neighbor Cache entry exists).
        An implementation may choose to always return the same router or
        cycle through the router list in a round-robin fashion as long
        as it always returns a reachable or a probably reachable router
        when one is available.

     2) When no routers on the list are known to be reachable or
        probably reachable, routers SHOULD be selected in a round-robin
        fashion, so that subsequent requests for a default router do not
        return the same router until all other routers have been
        selected.

        Cycling through the router list in this case ensures that all
        available routers are actively probed by the Neighbor
        Unreachability Detection algorithm.  A request for a default
        router is made in conjunction with the sending of a packet to a
        router, and the selected router will be probed for reachability
        as a side effect.

     3) If the Default Router List is empty, assume that all
        destinations are on-link as specified in Section 5.2.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------