IETF Logo Mail Archive

Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)

Eliot Lear <lear@cisco.com> Fri, 28 March 2003 05:49 UTC

Received: from ran.ietf.org (ran.ietf.org [10.27.6.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05931; Fri, 28 Mar 2003 00:49:10 -0500 (EST)
Received: from majordomo by ran.ietf.org with local (Exim 4.10) id 18ymts-0002Ch-00 for ietf-list@ran.ietf.org; Fri, 28 Mar 2003 00:59:36 -0500
Received: from odin.ietf.org ([10.27.2.28] helo=ietf.org) by ran.ietf.org with esmtp (Exim 4.10) id 18ymtF-0002AF-00 for ietf@ran.ietf.org; Fri, 28 Mar 2003 00:58:57 -0500
Received: from edison.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05857 for <ietf@ietf.org>; Fri, 28 Mar 2003 00:43:27 -0500 (EST)
Received: from cisco.com (sjc-vpn3-406.cisco.com [10.21.65.150]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id VAA12927; Thu, 27 Mar 2003 21:45:39 -0800 (PST)
Message-ID: <3E83E182.5080503@cisco.com>
Date: Thu, 27 Mar 2003 21:45:38 -0800
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michel Py <michel@arneill-py.sacramento.ca.us>
CC: Ted Hardie <hardie@qualcomm.com>, The IETF <ietf@ietf.org>
Subject: Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
References: <963621801C6D3E4A9CF454A1972AE8F504560A@server2000.arneill-py.sacramento.ca.us>
In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F504560A@server2000.arneill-py.sacramento.ca.us>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: owner-ietf@ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Michel,

What you say is possible, and has happened.  But dumb things happen. 
Those dumb things could happen with non site-local addresses as well. 
But look.  Ultimately I think we as a community do need to own up to 
better tooling, which can lead to better expectations.  Also, I don't 
see any reason why an IP v6 prefix allocation can't linger for a very 
long time after a contract ends.  The tools need to set expectations, 
and perhaps some of the DHCP prefix delegation code can help here.

Regards,

Eliot

v2.23.0 | Report a Bug | By Email