IETF Logo Mail Archive

Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

Thomas Narten <narten@us.ibm.com> Thu, 10 July 2008 01:29 UTC

Return-Path: <ipv6-bounces@ietf.org>
X-Original-To: ipv6-archive@megatron.ietf.org
Delivered-To: ietfarch-ipv6-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 745273A687A; Wed, 9 Jul 2008 18:29:44 -0700 (PDT)
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9075D3A6844 for <ipv6@core3.amsl.com>; Wed, 9 Jul 2008 18:29:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ohjl2f1gUnw5 for <ipv6@core3.amsl.com>; Wed, 9 Jul 2008 18:29:42 -0700 (PDT)
Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by core3.amsl.com (Postfix) with ESMTP id A34423A6765 for <ipv6@ietf.org>; Wed, 9 Jul 2008 18:29:42 -0700 (PDT)
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m6A1Tjro015870 for <ipv6@ietf.org>; Wed, 9 Jul 2008 21:29:45 -0400
Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m6A1Tjru210978 for <ipv6@ietf.org>; Wed, 9 Jul 2008 21:29:45 -0400
Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m6A1Titu030070 for <ipv6@ietf.org>; Wed, 9 Jul 2008 21:29:44 -0400
Received: from cichlid.raleigh.ibm.com (sig-9-76-148-45.mts.ibm.com [9.76.148.45]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m6A1TgJ3030036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Jul 2008 21:29:44 -0400
Received: from cichlid.raleigh.ibm.com (cichlid-new [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id m6A1TeXm026532; Wed, 9 Jul 2008 21:29:41 -0400
Message-Id: <200807100129.m6A1TeXm026532@cichlid.raleigh.ibm.com>
To: JINMEI Tatuya / 神明達哉 <Jinmei_Tatuya@isc.org>
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
In-reply-to: <m2lk0b6d24.wl%Jinmei_Tatuya@isc.org>
References: <B00EDD615E3C5344B0FFCBA910CF7E1D04E41EB4@xmb-rtp-20e.amer.cisco.com> <BB56240F3A190F469C52A57138047A03A9E94F@xmb-rtp-211.amer.cisco.com> <m2lk0b6d24.wl%Jinmei_Tatuya@isc.org>
Comments: In-reply-to JINMEI Tatuya / 神明達哉 <Jinmei_Tatuya@isc.org> message dated "Tue, 08 Jul 2008 18:50:27 -0700."
Date: Wed, 09 Jul 2008 21:29:40 -0400
From: Thomas Narten <narten@us.ibm.com>
Cc: ipv6@ietf.org, Bob Hinden <bob.hinden@nokia.com>, Brian Haberman <brian@innovationslab.net>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

Note: replying to a number of separate messages here...

JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
 <Jinmei_Tatuya@isc.org> writes:

> At Thu, 3 Jul 2008 17:07:34 -0400,
> "Wes Beebee (wbeebee)" <wbeebee@cisco.com> wrote:

> > <wb>
> > What if there are cache-inconsistency problems, prefix renumbering, or
> > stale information?  I think it's better just to get rid of caching
> > on-link information in stable storage and get such information fresh
> > from RA's.  That way, administrators can better rationalize the behavior
> > of their network from the configured RA's.
> > </wb>

> The same argument applies to caching the address, so it cannot be a
> reason why we specifically prohibit the (on-link) prefix part of this
> behavior.

Exactly.

> Actually, I see it can rather be harmful if we only prohibit the
> on-link prefix part of this behavior.

Again, I agree.

Note also, that DNA approaches essentially "cache" information about
the configuration of an interface across interfaces going up and down
-- which is very similar to the type of caching you are proposing to
disallow.

There is nothing wrong with caching information (as long as it has not
expired) so long as one replaces it if updated information comes along
later.

So I continue to be unpersuaded by any of the discussion so far that
we should saying "don't do that". 

Thomas

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

v2.23.0 | Report a Bug | By Email