From owner-freebsd-net@FreeBSD.ORG Thu Aug 24 20:59:55 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B0DD16A518; Thu, 24 Aug 2006 20:59:55 +0000 (UTC) (envelope-from patl+freebsd@volant.org) Received: from smtp.volant.org (gate.volant.org [207.111.218.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF2E843D53; Thu, 24 Aug 2006 20:59:54 +0000 (GMT) (envelope-from patl+freebsd@volant.org) Received: from adsl-065-081-071-131.sip.gnv.bellsouth.net ([65.81.71.131] helo=[192.168.1.121]) by smtp.volant.org with asmtp (TLSv1:AES256-SHA:256) (Exim 4.34 (FreeBSD)) id 1GGMM8-000Pax-Cu; Thu, 24 Aug 2006 14:03:19 -0700 Date: Thu, 24 Aug 2006 13:59:10 -0400 From: Pat Lashley To: Fredrik Lindberg Message-ID: X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 X-Scan-Signature: 471fe4329b9bac1676f30a614122b72a46154b45 X-Spam-User: nobody X-Spam-Score: -4.1 (----) X-Spam-Score-Int: -40 X-Spam-Report: This mail has matched the spam-filter tests listed below. See http://spamassassin.org/tag/ for details about the specific tests reported. In general, the higher the number of total points, the more likely that it actually is spam. (The 'required' number of points listed below is the arbitrary number above which the message is normally considered spam.) Content analysis details: (-4.1 points total, 5.0 required) 0.1 HTML_MESSAGE BODY: HTML included in message 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.4 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date 0.1 AWL AWL: Auto-whitelist adjustment Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Doug Barton Subject: Re: Zeroconfig and Multicast DNS 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: Thu, 24 Aug 2006 20:59:55 -0000 > > I think that I'd reverse the default on that. There should normally be > > no harm in having an LLA address, as long as we've got the non-LLA > > preference stuff working correctly. It is quite likely that the LLA > > address would never actually be used; but so what? > > > > I've been thinking about that too, but I'm still not sure. The RFC > says that you shouldn't add a LLA address to an interface that > already is configured with a routeable address. I think that you're referring to the first paragraph of section 1.9. That section appears to assume that some sort of ARP-based routing will be used by all parties to allow hosts with IP addresses in different (sub)nets to directly communicate if they are on the same segment. That section then goes on to specify when both a routable and an IPv4 Link-Local address MAY be assigned. Sub-paragraph 2 indicates that if a routable address is available on the interface, we MUST stop -advertising- the IPv4 Link-Local address (i.e., remove it from the mDNS records); but may keep (and defend) the address and accept new connections on it. Note that this only applies to IPv4. It doesn't say that we can't continue to advertise an IPv6 Link-Local address. (Which makes sense; since the point of the restriction is to reduce problems caused by dynamically changing IP addresses; and that won't happen with IPv6 Link-Local.) > Configuring LLA via rc.conf should probably be done like DHCP, by > using a magic word in the ifconfig_ifX-line. > > We could have two words, one called LLA that would run in the "forced" > mode and another LLA2 (I can't come up a good name) which would run > in the RFC compliant way. The problem with that is that we want to support the use of both on the same link. So we'd either need to allow more than one keyword, or have 'DHCP', 'LLA', 'LLA+DHCP', etc. Neither of those is very attractive. I think it would be cleaner to have something like: ipv4-link-local-always="bge* fxp1" ipv4-link-local-fallback="fxp0" -Pat