Processing IPv6 Router Advertisements

[JINMEI Tatuya / 神明達哉]

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