Subject: RE: ND- processing neighbor advertisements

From: Richard Draves <[email-masked]>
Date: Thu, 2 Dec 1999 16:44:55 -0800

Well, I thought about this further and I think MSR IPv6 is doing the wrong
thing in this situation. I said below that the solicited flag won't normally
be set. Actually it can easily happen: when there are two instances of an
anycast address on the link, and you send a NS for the anycast address,
you'll receive two NAs. When you process the second NA, you'll be in exactly
this situation - your NCE is REACHABLE (because you just processed the first
NA), the override flag is clear, the solicited flag is set, and the target
link-layer address is different than your cached link-layer address.

But I think the appendix has it backwards. In the above situation, you want
to leave the NCE in the reachable state. It's when the solicited flag is
zero that you want to change reachable -> stale.

For example suppose that you are moving anycast addresses around on the
link, removing them from some interfaces, adding them to new interfaces, but
since it's anycast at any instance the address can be assigned to several
interfaces. So when you move the anycast address off an old interface onto a
new interface you send an unsolicited NA for it with the new link-layer
address. A neighbor should update its NCE from reachable -> stale. Then if
the neighbor's cached link-layer address is still good, it will quickly
correct back to reachable, and if it's bad then it will quickly resolicit.

Rich

> -----Original Message-----
> From: Richard Draves [mailto:[email-masked]]
> Sent: Thursday, December 02, 1999 3:53 PM
> To: 'Sowmini Varadhan'; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: ND- processing neighbor advertisements
> 
> 
> For what it's worth, here's what MSR IPv6 does:
> 
> The situation is:
> - you already have an NCE with a link-layer address (the NCE is not
> INCOMPLETE).
> - you receive a neighbor advertisement for the neighbor but 
> with a different
> address in the target link-layer address option.
> - the override bit is zero.
> 
> Then if the NCE is in the REACHABLE state, we set it to 
> STALE, otherwise the
> NCE is not updated in any way.
> 
> If the solicited flag is set in this situation, then we log a 
> debugging
> event (it shouldn't happen in normal operation) but the value of the
> solicited flag doesn't change what happens to the NCE.
> 
> Rich
> 
> > -----Original Message-----
> > From: Sowmini Varadhan [mailto:[email-masked]]
> > Sent: Thursday, December 02, 1999 1:56 PM
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked];
> > [email-masked]; [email-masked]
> > Subject: ND- processing neighbor advertisements
> > 
> > 
> > 
> > 
> > RFC 2461, Section 7.2.5 [Page 62-63]  has:
> > 
> >   "[if the entry is not incomplete, and the]... Override flag 
> > is clear and the
> >    supplied link-layer address differs from that in the 
> > cache, then one
> >    of two actions takes place: if the state of the entry is 
> REACHABLE,
> >    set it to STALE, but do not update the entry in any other way;"
> > 
> > This statement (and the text leading up to it) places no requirement
> > on the Solicited flag, for the transition from REACHABLE -> STALE
> > for an NA with Override = 0, when the link-layer address in the 
> > NA differs from the cached value. 
> > 
> > 
> > However, in Appendix C [Page 85-86], the relevant transitions are:
> > 
> > 
> >   State           Event                   Action              
> >   New state
> > 
> >   REACHABLE       NA, Solicited=1,        -                 
>     STALE
> >                   Override=0
> >                   Different link-layer
> >                   address than cached.
> >                  :
> >                  :
> > 
> >   !INCOMPLETE     NA, Solicited=0,        -                   
> >   unchanged
> >                   Override=0
> > 
> > 
> > which indicate that the REACHABLE -> STALE  transition has a 
> > dependancy
> > on the Solicited flag.
> > 
> > So, which one is more accurate? Should the Solicited flag also
> > be considered along with the conditions on Page 62-63 ?
> > 
> > --Sowmini
> > 
> > --------------------------------------------------------------------
> > 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]
> > --------------------------------------------------------------------
> > 
> --------------------------------------------------------------------
> 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]
> --------------------------------------------------------------------
> 
--------------------------------------------------------------------
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: Mon, 06 Dec 1999 17:13:51 +0900

>>>>> On Thu, 2 Dec 1999 16:44:55 -0800 , 
>>>>> Richard Draves <[email-masked]> said:

> correct back to reachable, and if it's bad then it will quickly resolicit.

I agree with Rich; an implementation should change the state of an NCE
from REACHABLE to STALE if

- we already have a REACHABLE NCE with a link-layer address,
- we receive a neighbor advertisement for the neighbor but with a different
  address in the target link-layer address option, and
- the override bit is zero.

regardless of the solicited flag of the NA.

I forgot the discussion and the consensus on this point when the RFC
was updated, but I suspect that there is a mistake in the appendix.

I'll attach a digest of the KAME's implementation for this transition,
just FYI. We implemented this part according to Section 7 of the RFC,
not the transition table in Appendix C.

nd6_na_input()
...
		/*
		 * This is VERY complex.  Look at it with care.
		 *
		 * override solicit lladdr llchange	action
		 *					(L: record lladdr)
		 *
		 *	0	0	n	--	(2c)
		 *	0	0	y	n	(2b) L
		 *	0	0	y	y	(1)    REACHABLE->STALE
		 *	0	1	n	--	(2c)   *->REACHABLE
		 *	0	1	y	n	(2b) L *->REACHABLE
		 *	0	1	y	y	(1)    REACHABLE->STALE
		 *	1	0	n	--	(2a)
		 *	1	0	y	n	(2a) L
		 *	1	0	y	y	(2a) L *->STALE
		 *	1	1	n	--	(2a)   *->REACHABLE
		 *	1	1	y	n	(2a) L *->REACHABLE
		 *	1	1	y	y	(2a) L *->REACHABLE
		 */
		if (!is_override && (lladdr && llchange)) {	   /* (1) */
			/*
			 * If state is REACHABLE, make it STALE.
			 * no other updates should be done.
			 */
			if (ln->ln_state == ND6_LLINFO_REACHABLE)
				ln->ln_state = ND6_LLINFO_STALE;
			return;
		} else if (is_override				   /* (2a) */
			|| (!is_override && (lladdr && !llchange)) /* (2b) */
			|| !lladdr) {				   /* (2c) */
			/*
			 * If solicited, make the state REACHABLE.
			 * If not solicited and the link-layer address was
			 * changed, make it STALE.
			 */
			if (is_solicited) {
				ln->ln_state = ND6_LLINFO_REACHABLE;
			} else {
				if (lladdr && llchange)
					ln->ln_state = ND6_LLINFO_STALE;
			}
		}

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