Subject: RE: ND- processing neighbor advertisements

From: Richard Draves <[email-masked]>
Date: Tue, 7 Dec 1999 08:26:14 -0800

> Or did you suggest that we *should not change* the NCE state from
> REACHABLE to STALE when we receive a solicited (and Override=0,
> different link-layer addr) NA?

Yes, that is what I was trying to suggest. When solicited=1, override=0, and
link-layer is different, then the NA is presumably a second response to an
NS for an anycast address. So ignoring the NA is best, although
transitioning REACHABLE -> STALE should be pretty innocuous. When
solicited=0, override=0, and link-layer is different, then the NA is
presumably an unsolicited attempt to inform the subnet about a new
link-layer address for an anycast address, so give NUD a little nudge by
transitioning REACHABLE -> STALE.

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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 08 Dec 1999 02:15:21 +0900

>>>>> On Tue, 7 Dec 1999 08:26:14 -0800 , 
>>>>> Richard Draves <[email-masked]> said:

> Yes, that is what I was trying to suggest.

Okay.

> When solicited=1, override=0, and
> transitioning REACHABLE -> STALE should be pretty innocuous.

I don't oppose that ignoring the NA is best in such a situation, but
the second (or third, forth...) responses would normally appear only
in the 1st time (i.e. during the address resolution procedure). Once
we resolve a link-layer address for the anycast address, we'll just
send succeeding NSes to the link-layer address directly, and thus
we won't get additional NAs.

So I think there is a tradeoff;
- If we adopt the *best* approach, we can avoid redundant NS/NA
  exchanges in a (link-layer) address resolution procedure. But the
  code will be a bit more complicated, since we need an additional
  condition (i.e check if the solicited flag is on or not).
- If we don't adopt the apporach, we may encounter the redundant NS/NA
  exchanges. But the code will remain simple.

So far, I don't think that the apporach is reasonable enough to change
a draft standard RFC. But I don't mind change our implementation if
the ipngwg gets a consensus on this.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------