>>>>> On Sun, 5 Aug 2001 14:53:07 +0200 (CEST),
>>>>> Erik Nordmark <[EMAIL PROTECTED]> said:
>> > 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.
Well, I was just about to send exactly the same comment on the current
version of the draft, and
> Thus I think it makes sense to have an explicit mention of the
> "assume all destinations on-link" case in this rule.
I agree with you.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
p.s. our (KAME's) implementation uses a "default" route to make
neighbor caches when there is no default router, which was called
"broken" in this thread. But I'd rather say that the essential
problem here is that the meaning of "route" is vague, and that such
implementations like ours should be allowed as a possible
interpretation of RFC 2461.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
