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

itojun@itojun.org (Jun-ichiro itojun Hagino) Thu, 11 October 2007 10:47 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 1IfvZZ-00055p-H4; Thu, 11 Oct 2007 06:47:21 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfvZY-00054j-Av for ietf@ietf.org; Thu, 11 Oct 2007 06:47:20 -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 1IfvZT-0002nR-UG for ietf@ietf.org; Thu, 11 Oct 2007 06:47:16 -0400
Received: by coconut.itojun.org (Postfix, from userid 501) id 52D96233D1; Thu, 11 Oct 2007 19:46:53 +0900 (JST)
To: brian.e.carpenter@gmail.com
In-Reply-To: Your message of "Thu, 11 Oct 2007 09:45:25 +1300" <470D39E5.5060807@gmail.com>
References: <470D39E5.5060807@gmail.com>
X-Mailer: Cue version 0.8 (070521-1856/itojun)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Message-Id: <20071011104653.52D96233D1@coconut.itojun.org>
Date: Thu, 11 Oct 2007 19:46:53 +0900
From: itojun@itojun.org
X-Spam-Score: -0.0 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
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

> 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.

itojun

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