From owner-freebsd-net@FreeBSD.ORG Mon Feb 1 20:31:13 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3DBE1065670 for ; Mon, 1 Feb 2010 20:31:13 +0000 (UTC) (envelope-from jinmei@isc.org) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by mx1.freebsd.org (Postfix) with ESMTP id D286B8FC24 for ; Mon, 1 Feb 2010 20:31:13 +0000 (UTC) Received: from jmb.jinmei.org (unknown [IPv6:2001:4f8:3:64:217:f2ff:fee0:a91f]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id AD888E60D7; Mon, 1 Feb 2010 20:31:12 +0000 (UTC) (envelope-from jinmei@isc.org) Date: Mon, 01 Feb 2010 12:31:12 -0800 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Fernando Gont In-Reply-To: <4B559EBC.9060502@gont.com.ar> References: <4B559EBC.9060502@gont.com.ar> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: Processing IPv6 Router Advertisements X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 20:31:14 -0000 At Tue, 19 Jan 2010 08:59:56 -0300, Fernando Gont 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.