Re: [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN]

Iljitsch van Beijnum <iljitsch@muada.com> Tue, 18 April 2006 15:13 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVrtk-0005D4-VQ; Tue, 18 Apr 2006 11:13:48 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVrti-0005Cw-Vd for ietf@ietf.org; Tue, 18 Apr 2006 11:13:46 -0400
Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVrth-0004h6-IV for ietf@ietf.org; Tue, 18 Apr 2006 11:13:46 -0400
Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k3IFDCJk032162 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 18 Apr 2006 17:13:13 +0200 (CEST) (envelope-from iljitsch@muada.com)
In-Reply-To: <20060418115032.6E82986AEC@mercury.lcs.mit.edu>
References: <20060418115032.6E82986AEC@mercury.lcs.mit.edu>
Mime-Version: 1.0 (Apple Message framework v749.3)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <0D056526-039B-4E31-8AEA-6DDE4013EC3D@muada.com>
Content-Transfer-Encoding: 7bit
From: Iljitsch van Beijnum <iljitsch@muada.com>
Date: Tue, 18 Apr 2006 17:13:38 +0200
To: Noel Chiappa <jnc@mercury.lcs.mit.edu>
X-Mailer: Apple Mail (2.749.3)
X-Spam-Status: No, score=0.4 required=5.0 tests=AWL,BAYES_00,ILJQX_SUBJ_AT, ILJQX_SUBJ_DOTINWORD,ILJQX_SUBJ_NUMINWORD autolearn=no version=3.0.2
X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: gray@washington.edu, ietf@ietf.org
Subject: Re: [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN]
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 18-apr-2006, at 13:50, Noel Chiappa wrote:

> Now we hear that anything like 8+8 is infeasiable because it's  
> incompatible
> with the installed base (all 17 of them).

18 if the IETF would finally start eating its own dog food...

Let me observe once again that 8+8/GSE is incomplete because it  
doesn't provide a secure binding between the id and the loc, which is  
very necessary in a few places, and because it doesn't have any  
failover mechanisms. So even if compatibility with existing IPv6  
wouldn't be an issue, 8+8/GSE would need significant amounts of work.

But in the IETF compatibility with existing deployments is  
historically considered important (and even though IPv6 isn't  
deployed very widely, it's already in a lot of software and even some  
hardware so changing it now would create more problems than  
deployment figures suggest).

If you add security, failover and backward compatibility to 8+8/GSE  
you get something that looks a whole lot like shim6. The only part  
that's missing is rewriting locators by routers, which wouldn't be  
extremely hard to add to shim6 but since today's routers can't do it  
shim6 needs to work without this capability first.

And while I'm observing, the recent exchange between you and Keith is  
exactly the kind of stuff that makes making fundamental changes in  
our architecture and/or base protocols so hard as we saw in multi6:  
the routing, DNS, transport and application people all want someone  
else to suffer the pain caused by something new.

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