Subject: Re: UNH problems

From: [email-masked] (Tim Hartrick)
Date: Thu, 10 Jun 1999 15:53:03 -0700

> From [email-masked] Thu Jun 10 14:54:27 1999
> Received: from roll.mentat.com (roll [192.88.122.129])
> 	by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id OAA28466
> 	for <tim@leo>; Thu, 10 Jun 1999 14:54:23 -0700 (PDT)
> Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
> 	by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id OAA22037
> 	for <[email-masked]>; Thu, 10 Jun 1999 14:54:21 -0700 (PDT)
> Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
> 	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA17013;
> 	Thu, 10 Jun 1999 14:55:11 -0700 (PDT)
> Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
> 	by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA01602;
> 	Thu, 10 Jun 1999 14:55:09 -0700 (PDT)
> Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id OAA28950
> 	for ipng-dist; Thu, 10 Jun 1999 14:50:42 -0700 (PDT)
> Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
> 	by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA28943
> 	for <[email-masked]>; Thu, 10 Jun 1999 14:50:33 -0700 (PDT)
> Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
> 	by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA00698
> 	for <[email-masked]>; Thu, 10 Jun 1999 14:50:32 -0700 (PDT)

Rich,

> The other failure concerns section 6.3.5 in the ND spec. The NUT has a
> prefix in the on-link prefix list, and it has created a Destination Cache
> Entry based on the on-link prefix. When the on-link prefix is removed
> (either because its lifetime goes to zero, or because an RA is received
> setting its lifetime to zero), can the Destination Cache Entry immediately
> be purged, so subsequent packets to the destination will create a new DCE
> using a default router? Section 6.3.5 notes that the DCE "need not" be
> purged, because NUD will correct the situation if the destination address is
> in fact no longer on-link. However there is no MUST in section 6.3.5 to
> mandate this behavior. It happens to be convenient for our implementation to
> purge the DCE immediately but UNH says this is wrong.
>

Our implementation will do the same as yours for precisely the same reason.  It
is convenient to clean up everything associated with the prefix at the same
time.  Unless it says MUST NOT it isn't a requirement that the neighbor/
destination cache entry for the node be preserved.  I am with you.

I don't have a comment about the former test other than I wasn't aware that the
specification required that a node remove a router from its router list if it
receives a neighber advertisement with the IsRouter flag clear.  I thought it
only required that the neighbor cache entry for the "router" be marked to
indicate that it is not a router any longer.  I don't have the spec handy or
I would check this point myself.....

tim 

--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------