>>>>> On Fri, 31 Oct 2003 12:52:14 +1100, 
>>>>> Greg Daley <[EMAIL PROTECTED]> said:

> The difficulty comes when an RS comes from a global
> source address which is not directly connected to
> a router.

> Based on RS processing rules, the host which sent
> the RS is within a hop of the router, but has asked for
> an RA from an address which doesn't exist locally.

It is not very clear what "an address which doesn't exist locally"
means.  I guess you probably mean, e.g., an address that belongs to a
prefix that the receiving router does not configure as on-link.

RFC2461 clearly (IMO) says that such an address must be regarded as
on-link:

   on-link     - an address that is assigned to an interface on a
                 specified link.  A node considers an address to be on-
                 link if:
   (snip)
                    - any Neighbor Discovery message is received from
                      the address.
(Section 2.1 of RFC2461)

Note that in this case a neighbor discovery message (router
solicitation) is received from the address.

> Does the router reply to a message which has a source
> address not believed to be on this link?

So, again, it is not clear what "a source address not believed to be on
this link" means, but if the question is, e.g., 

  Does the router reply to a message which has a source
  address that belongs to a prefix that the receiving router does not
  configure as on-link?

then the answer is yes.

> Does it only reply with a multicast destination?

No, a unicasted response is also valid.

> What do current implementations do in this case?

This doesn't help your question here, but FWIW, the KAME/BSD
implementation only supports for multicast router advertisement.
So, the implementation always replies with a multicast destination,
whether the source of the solicitation is link-local or global.

                                        JINMEI, Tatuya
                                        Communication Platform Lab.
                                        Corporate R&D Center, Toshiba Corp.
                                        [EMAIL PROTECTED]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to