> > 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 PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
