IETF Logo Mail Archive

Re: Call for action vs. lost opportunity (Was: Re: Renumbering)

itojun@itojun.org (Jun-ichiro itojun Hagino) Fri, 12 October 2007 03:28 UTC

Return-path: <ietf-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgBC6-0004La-2p; Thu, 11 Oct 2007 23:28:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgBC5-0004E2-13 for ietf@ietf.org; Thu, 11 Oct 2007 23:28:09 -0400
Received: from coconut.itojun.org ([2001:240:501:0:204:23ff:fecb:8908]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgBC3-0001IS-4T for ietf@ietf.org; Thu, 11 Oct 2007 23:28:09 -0400
Received: by coconut.itojun.org (Postfix, from userid 501) id 4E4F7233C5; Fri, 12 Oct 2007 12:27:58 +0900 (JST)
To: brian.e.carpenter@gmail.com
In-Reply-To: Your message of "Fri, 12 Oct 2007 08:43:17 +1300" <470E7CD5.3000209@gmail.com>
References: <470E7CD5.3000209@gmail.com>
X-Mailer: Cue version 0.8 (070521-1856/itojun)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Message-Id: <20071012032758.4E4F7233C5@coconut.itojun.org>
Date: Fri, 12 Oct 2007 12:27:58 +0900
From: itojun@itojun.org
X-Spam-Score: -0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Cc: ietf@ietf.org
Subject: Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Errors-To: ietf-bounces@ietf.org

> On 2007-10-11 23:46, Jun-ichiro itojun Hagino wrote:
> >> Not viewed from the socket programmer's point of view.
> >> Look at how an AF_INET6 socket behaves when given
> >> an address like ::FFFF:192.0.2.3
> >> afaik the behavior is then exactly what you describe.
> >> Whether the stacks are independent code modules or
> >> alternate paths through the same code is irrelevant
> >> to the externally observed behavior.
> > 
> > 	see draft-ietf-v6ops-security-overview-06.txt section 2.2.
> 
> Sure. I absolutely don't like to see ::FFFF/96 on the wire.

	then we'd have to deprecate SIIT at least.  still, you cannot be sure
	that ::ffff:0:0/96 are not on the wire.

itojun

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

v2.23.0 | Report a Bug | By Email