From owner-freebsd-net@FreeBSD.ORG Wed Nov 1 07:39:33 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 A40A016A407 for ; Wed, 1 Nov 2006 07:39:33 +0000 (UTC) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id 285C143D7E for ; Wed, 1 Nov 2006 07:39:31 +0000 (GMT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from impact.jinmei.org (unknown [2001:200:1b1:1010:20e:7bff:fedd:fe03]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 2A86715218; Wed, 1 Nov 2006 16:39:25 +0900 (JST) Date: Wed, 01 Nov 2006 16:39:25 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Krejsa, Dan" In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. 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: PPP IPv6 prefix length and stateless autoconfiguration? 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: Wed, 01 Nov 2006 07:39:33 -0000 (sorry for the delayed response, been busy for a while...) >>>>> On Tue, 17 Oct 2006 10:03:05 -0700, >>>>> "Krejsa, Dan" said: > This appears to make the autoconfiguration work fine, and I > encountered no other connectivity issues in brief testing; > but a coworker of mine noticed that ifconfig no longer showed > the destination address, and I investigated and found the > 128-bit enforcement in in6_update_ifa(). This makes me somewhat > nervous; but if configuring a PPP/IPv6 interface without an > IPv6 destination address is the intended method of use, > I'd be more comfortable with this. Is that the standard > way of doing things? I don't know in which sense you mean "standard", but in any event, it's an implementation specific decision (not required by a protocol specification). I believe it's at least doesn't break any protocol standard, or cause a problem in operation (except incompatibility with an application or operation that has a different assumption as you saw). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp