Subject: RE: quick autoconf question

From: Richard Draves <[email-masked]>
Date: Fri, 30 Jun 2000 13:46:54 -0700

> > The question has to do with NA & NS where the destination 
> address (== the
> > target address) is tentative.
> 
> Seems like that shouldn't be happening normally. So the TAHI
> interpretation seems reasonable. Either way, the cited wording in 2462
> could be better.

Yes. I'm happy to go with the TAHI interpretation - it's simpler to
implement.

Thanks,
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: "Powell, Ken" <[email-masked]>
Date: Fri, 30 Jun 2000 16:31:47 -0400

Rich,

I've been working my way through the TAHI tests as well and
am running into similar questions. I think the following
sections of RFC 2462 also apply.

   5.4.1.  Message Validation

   A node MUST silently discard any Neighbor Solicitation or
   Advertisement message that does not pass the validity checks
   specified in [DISCOVERY]. A solicitation that passes these validity
   checks is called a valid solicitation or valid advertisement.

   5.4.4.  Receiving Neighbor Advertisement Messages

   On receipt of a valid Neighbor Advertisement message on an interface,
   node behavior depends on whether the target address is tentative or
   matches a unicast or anycast address assigned to the interface.  If
   the target address is assigned to the receiving interface, the
   solicitation is processed as described in [DISCOVERY]. If the target
   address is tentative, the tentative address is not unique.

I couldn't find anything that specifically states you should
silently discard the Neighbor Advertisement. On the other hand,
a Neighbor Advertisement sent in response to your Neighbor
Solicit under DAD MUST be addressed to the all nodes multicast
address, so it is probably reasonable to silently ignore the
Neighbor Advertisement in this test. I tend to prefer to leave
it up to the implementation unless there is a clear reason to
mandate one option over the other.

Ken Powell
Compaq Computer Corporation

> -----Original Message-----
> From: Richard Draves [mailto:[email-masked]]
> Sent: Friday, June 30, 2000 2:36 PM
> To: Thomas Narten (E-mail); IPng List (E-mail)
> Subject: quick autoconf question
> 
> 
> I'm reviewing the latest TAHI test results. They've added 
> some new tests for
> autoconfiguration, and one of them raises a question.
> 
> If I receive a Neighbor Advertisement and the Destination 
> Address in the
> IPv6 header is a tentative address and the Target Address in 
> the NA is the
> same tentative address, should I process the NA (therefore 
> concluding that
> the address is a duplicate) or should I silently discard the NA?
> 
> In RFC 2462 it says:
> 
>    An address on which the duplicate Address Detection Procedure is
>    applied is said to be tentative until the procedure has completed
>    successfully.  A tentative address is not considered 
> "assigned to an
>    interface" in the traditional sense. That is, the interface must
>    accept Neighbor Solicitation and Advertisement messages containing
>    the tentative address in the Target Address field, but 
> processes such
>    packets differently from those whose Target Address matches an
>    address assigned to the interface. Other packets addressed to the
>    tentative address should be silently discarded.
> 
> The TAHI test says the NA should be silently discarded, and 
> reading the
> quoted paragraph closely it's not quite clear. It hinges on 
> the word "Other"
> in the last sentence.
> 
> Note that normally when when the Target Address is a 
> tentative address, the
> destination address is multicast (ff02::1 for NAs and solicited-node
> multicast for NSs) so the answer only affects clever tests, not normal
> operation.
> 
> Thanks,
> Rich