Processing IPv6 Router Advertisements

JINMEI Tatuya / 神明達哉 jinmei at
Mon Feb 1 20:31:14 UTC 2010

At Tue, 19 Jan 2010 08:59:56 -0300,
Fernando Gont <fernando at> 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:;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.

More information about the freebsd-net mailing list