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

"Hemant Singh (shemant)" <shemant@cisco.com> Thu, 10 July 2008 00:53 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 203993A68D5; Wed, 9 Jul 2008 17:53:55 -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 04D263A68D5 for <ipv6@core3.amsl.com>; Wed, 9 Jul 2008 17:53:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.722
X-Spam-Level:
X-Spam-Status: No, score=-5.722 tagged_above=-999 required=5 tests=[AWL=0.877, 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 AOQbefgIZFQ6 for <ipv6@core3.amsl.com>; Wed, 9 Jul 2008 17:53:52 -0700 (PDT)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 7038A3A67E7 for <ipv6@ietf.org>; Wed, 9 Jul 2008 17:53:52 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.30,334,1212364800"; d="scan'208";a="13764256"
Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 10 Jul 2008 00:54:05 +0000
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6A0s5FO032416; Wed, 9 Jul 2008 20:54:05 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6A0s5Q7028248; Thu, 10 Jul 2008 00:54:05 GMT
Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Jul 2008 20:54:05 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
Date: Wed, 9 Jul 2008 20:54:04 -0400
Message-ID: <B00EDD615E3C5344B0FFCBA910CF7E1D04E41F06@xmb-rtp-20e.amer.cisco.com>
In-Reply-To: <m2r6a24lwi.wl%Jinmei_Tatuya@isc.org>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
Thread-Index: AcjiJNG86cY+ShduT9W/aq3+txGUhwAAHryg
References: <BB56240F3A190F469C52A57138047A03A9F348@xmb-rtp-211.amer.cisco.com> <m2r6a24lwi.wl%Jinmei_Tatuya@isc.org>
From: "Hemant Singh (shemant)" <shemant@cisco.com>
To: <Jinmei_Tatuya@isc.org>, "Wes Beebee (wbeebee)" <wbeebee@cisco.com>
X-OriginalArrivalTime: 10 Jul 2008 00:54:05.0196 (UTC) FILETIME=[73A69CC0:01C8E227]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5390; t=1215651245; x=1216515245; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shemant@cisco.com; z=From:=20=22Hemant=20Singh=20(shemant)=22=20<shemant@cisco. com> |Subject:=20RE=3A=206MAN=20WG=20Last=20Call=3Adraft-ietf-6m an-ipv6-subnet-model-00.txt |Sender:=20 |To:=20<Jinmei_Tatuya@isc.org>,=20=22Wes=20Beebee=20(wbeebe e)=22=20<wbeebee@cisco.com>; bh=TVhefGbjblH1DkAl1eOqwJJyxSR3d51C/Tj0R5nBBAE=; b=qsmx0lP3fpXbK/E9YYSa6J0evJhzjzFB3Cq29fbIbzNYx5Px3hK+E5NVD9 w/ggDy68oIHzRIG2KsCRSlAd9qirNbw38N5sGj8fr5TVghHozInbStB/Estk VUQCZq8E2k;
Authentication-Results: rtp-dkim-2; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; );
Cc: Thomas Narten <narten@us.ibm.com>, ipv6@ietf.org, Brian Haberman <brian@innovationslab.net>, Bob Hinden <bob.hinden@nokia.com>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

Tatuya,

Thanks for the reply. Let's see if we can meet common ground with you.

Our justification for prohibiting on-link caching is only in emails to
6man as follows:

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

We can add such text to the draft against bullet 3 and also add text
that even address SHOULD NOT be cached like we say for on-link
determination. Notice our rule is also not very strict by saying "MUST
NOT". It's a SHOULD NOT. With the SHOULD NOT also including address, we
still do not go against any existing RFC and also allow an existing
implementation to still cache the address if the implementation wants
to.


    3. On-link determination and IPv6 address SHOULD NOT persist 
       across IPv6 interface initializations.  This is a new requirement

       compared to [RFC4861].  If such information is cached, there is 
       risk associated with cache-inconsistency problems, prefix
renumbering, 
       or stale information.  It is better to just get information fresh

       from RA's.  That way, administrators can better rationalize the
behavior 
       of their network from the configured RA's.

Thanks.

Hemant

-----Original Message-----
From: Jinmei_Tatuya@isc.org [mailto:Jinmei_Tatuya@isc.org] 
Sent: Wednesday, July 09, 2008 8:35 PM
To: Wes Beebee (wbeebee)
Cc: Hemant Singh (shemant); Thomas Narten; Brian Haberman; Bob Hinden;
ipv6@ietf.org
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

At Wed, 9 Jul 2008 10:08:02 -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.

> <wb>
> We agree - and we believe implementations shouldn't be caching the 
> address either - but, unfortunately, the text of RFC4862 already 
> allows it and an implementation already does it - so that is something

> we cannot change.  However, our draft is dealing with on-link 
> determination and we've shown clear problems with caching on-link 
> determination.  RFC4861 and RFC4862 do not mention caching on-link 
> information, so we can add this rule to our draft.
> </wb>

Note: as I said in my previous comment, RFC4862 does not *allow* address
caching.  It just makes note when an implementation chooses to adopt it.

Anyway, I'm not convinced with this logic.  As I pointed out, killing
on-link information caching effectively kills address caching, too, by
making the cached address of almost no use.  Again, I'm personally not a
fan of this caching trick, but effectively killing address caching with
saying "we don't talk about address caching because it's out of scope of
this document" sounds like an unfair action for me.

I'd accept, if

1. we prohibit both address caching and on-link caching (with
   reasonable argument, of course)
or,
2. we don't talk about on-link caching (either allow or prohibit) if
   we don't talk about address caching

but it would be unfair if
3. we prohibit on-link caching while ignoring its effect on address
   caching.

> <wb>
> Again, they probably shouldn't be caching the address anyway - but 
> that's an argument for another day.  We have already given our 
> justification why on-link determination should not be cached.
> </wb>

Sorry, I've not seen the justification.  At least I don't see it in the
draft.

> <wb>
> No - screwing up on-link determination is not a minor thing nor 
> caching of it. See section 3 of our draft where we give one example of

> how data forwarding by a host may totally break down if a wrong 
> on-link determination is made.
> </wb>

I see the problem described in Section 3 and that's why I basically
support this document.  But I don't understand why this problem
justifies killing on-link caching.

As a meta level comment, my basic understanding of the purpose of this
document is to clarify a subtle point in the existing RFC(s) that can be
misinterpreted by implementors and can cause problems in the real world
operation.  I support that, but I'm not really comfortable if this
document tries to set new rules or amend the published document as long
as we deem this document as a "clarification".  Of course, I don't
oppose to that discussion per se, which will eventually be necessary
anyway, but that should be performed more explicitly and with seeking
consensus among implementors that might be affected by that action.  I'd
like this document to concentrate on its "clarification" work.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------