From owner-freebsd-net@FreeBSD.ORG Tue Apr 1 08:29:32 2003 Return-Path: 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 E6EF237B401 for ; Tue, 1 Apr 2003 08:29:31 -0800 (PST) Received: from basie.internet2.edu (basie.internet2.edu [207.75.164.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4031543F75 for ; Tue, 1 Apr 2003 08:29:26 -0800 (PST) (envelope-from boote@internet2.edu) Received: from localhost (localhost.localdomain [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 27DBF7B4CA; Tue, 1 Apr 2003 11:29:23 -0500 (EST) Received: from internet2.edu (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id AEBAF7B4C1; Tue, 1 Apr 2003 11:29:21 -0500 (EST) Message-ID: <3E89BE61.3EDE4AEF@internet2.edu> Date: Tue, 01 Apr 2003 09:29:21 -0700 From: "Jeff W. Boote" X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Hajimu UMEMOTO References: <20030326134823.A7029@jamaica.grc.nasa.gov> <20030327104649.B18679@jamaica.grc.nasa.gov> <3E838784.F2F4E330@internet2.edu> <3E874F6C.A76F99E8@internet2.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12pre8 cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 5.0 dual-stack server X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2003 16:29:32 -0000 Hajimu UMEMOTO wrote: > boote> This seems to contradict the recommendation in RFC 3493 (which I realize > boote> is only informational)... I've been doing a web search to try and find > boote> some kind of record for the rational used for making this default to > boote> v6only. I haven't found anything substantial yet. Does anyone on this > boote> list know why? (I'm guessing there must be a good reason - and if so, I > boote> want to make sure I'm dealing with those issues in my applications.) > > Yes, this breakage against RFC2553/3493 is intentional. Please refer: > > draft-cmetz-v6ops-v4mapped-api-harmful-00.txt Thanks! So... This would mean an application that wanted to be address independent would have to create a socket for every single wildcard sockaddr returned from getaddrinfo. And then use select/accept instead of just accept. That is kind of ugly... But, I guess it does make sense in the new world of multiple addresses and address families per host. jeff