> I had always read that section as 'if you don't know a router simply try ND
> as a last resort'. I would still consider an implementation broken if it
> interpreted the lack of a router entry to mean that it should declare one of
> its interfaces to be the default route.
Are you talking about multi-interface hosts?
There isn't a specification that talks about such hosts and it would be good
to have such a spec because I think there are some complex issues hiding
in this area.
> I realize this is simply a semantic
> difference, but mixing the routing table with the neighbor cache seems like
> an operational disaster waiting to happen.
What is the problem?
> > One possible way of making the draft clearer would be to, instead
> > of using the implementation concept of a routing table, express
> > the rule using the conceptual model in RFC 2461.
>
> I didn't read the rule as being restricted to a routing table because it
> included 'or the current next-hop neighbor'. I agree that could be
> interpreted as a router, but it could also be just the destination pointed
> to by the NC entry. How about 'or the current next-hop in the neighbor cache
> for DB is known to be unreachable'?
But in this case the next-hop wouldn't be known to be unreachable - its state
would be unknown.
Not until traffic is actually sent towards the next-hop can NUD detect
that it is unreachable.
Thus I think it makes sense to have an explicit mention of the
"assume all destinations on-link" case in this rule.
Erik
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
