At Tue, 19 Jan 2010 08:59:56 -0300,
Fernando Gont <ferna...@gont.com.ar> wrote:
> RA messages seem to be required to have a Source Address in the
> fe80::/32 prefix, rather than in the fe80::/10 prefix. That is, the
> first 32 bits of the IPv6 Source address must be fe80:0000, or else the
> message is dropped (at least, no changes are made to the destination
> cache or the neighbor cache).
> 
> Can anybody confirm this one, or correct me if I am wrong?

Your understanding of what's happening is correct, and it's an
intentional behavior.  The relevant part of the source code is the
following snippet of:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet6/ip6_input.c?rev=1.81.2.4;content-type=text/plain

        /*
         * Disambiguate address scope zones (if there is ambiguity).
         * We first make sure that the original source or destination address
         * is not in our internal form for scoped addresses.  Such addresses
         * are not necessarily invalid spec-wise, but we cannot accept them due
         * to the usage conflict.
         * in6_setscope() then also checks and rejects the cases where src or
         * dst are the loopback address and the receiving interface
         * is not loopback.
         */
        if (in6_clearscope(&ip6->ip6_src) || in6_clearscope(&ip6->ip6_dst)) {
                ip6stat.ip6s_badscope++; /* XXX */
                goto bad;
        }

So you should see the statistics counter named "violated scope rules"
(or something like that) in "netstat -p ip6 -s" increase as you send
these packets.

The superficial reason why such packets are dropped is because it
doesn't meet the specified format of link-local addresses as described
in RFC4291:

2.5.6.  Link-Local IPv6 Unicast Addresses

   Link-Local addresses are for use on a single link.  Link-Local
   addresses have the following format:

   |   10     |
   |  bits    |         54 bits         |          64 bits           |
   +----------+-------------------------+----------------------------+
   |1111111010|           0             |       interface ID         |
   +----------+-------------------------+----------------------------+

The "real" reason is described thoroughly in a book I coauthored.  I
believe you told me you had a copy of it, and assuming I'm correct,
see Section 2.9.3:-)

I admit this behavior is suboptimal for the spirit of "be liberal in
what you accept", but, as you probably know, it shouldn't cause any
interoperability trouble in practice.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Reply via email to