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

JINMEI Tatuya / 神明達哉 <Jinmei_Tatuya@isc.org> Thu, 10 July 2008 19: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 BEABA3A6A7C; Thu, 10 Jul 2008 12:53:40 -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 8305E3A68D8 for <ipv6@core3.amsl.com>; Thu, 10 Jul 2008 12:53:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.6
X-Spam-Level:
X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, NO_RELAYS=-0.001]
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 N88dQ0t20mmc for <ipv6@core3.amsl.com>; Thu, 10 Jul 2008 12:53:38 -0700 (PDT)
Received: from mon.jinmei.org (mon.jinmei.org [IPv6:2001:4f8:3:36::162]) by core3.amsl.com (Postfix) with ESMTP id 88F2E3A6A3E for <ipv6@ietf.org>; Thu, 10 Jul 2008 12:53:38 -0700 (PDT)
Received: from jmb.jinmei.org (unknown [IPv6:2001:4f8:3:bb:217:f2ff:fee0:a91f]) by mon.jinmei.org (Postfix) with ESMTP id 5F09633C2E; Thu, 10 Jul 2008 12:53:53 -0700 (PDT)
Date: Thu, 10 Jul 2008 12:53:53 -0700
Message-ID: <m2lk09ms6m.wl%Jinmei_Tatuya@isc.org>
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <Jinmei_Tatuya@isc.org>
To: "Hemant Singh (shemant)" <shemant@cisco.com>
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
In-Reply-To: <B00EDD615E3C5344B0FFCBA910CF7E1D04E41F16@xmb-rtp-20e.amer.cisco.com>
References: <BB56240F3A190F469C52A57138047A03A9F348@xmb-rtp-211.amer.cisco.com> <m2r6a24lwi.wl%Jinmei_Tatuya@isc.org> <B00EDD615E3C5344B0FFCBA910CF7E1D04E41F06@xmb-rtp-20e.amer.cisco.com> <m2mykq48x7.wl%Jinmei_Tatuya@isc.org> <B00EDD615E3C5344B0FFCBA910CF7E1D04E41F16@xmb-rtp-20e.amer.cisco.com>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Cc: Thomas Narten <narten@us.ibm.com>, ipv6@ietf.org, Suresh Krishnan <suresh.krishnan@ericsson.com>, 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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

At Thu, 10 Jul 2008 12:09:01 -0400,
"Hemant Singh (shemant)" <shemant@cisco.com>; wrote:

> Since you don't want any new rules added by our draft, we changed bullet
> 3 related to caching on-link determination. The new bullet text does not
> add any normative requirements but clearly says why it is a bad idea to
> cache on-link determination.  Also, our draft is about on-link
> determination - we are not adding anything related to IPv6 address
> caching - we have said repeatedly, save it for another day.

The new text does not make sense to me.

In this scenario, the same problem can occur when a host (that just
keeps working, without a reboot) happens to fail to receive the
RAs containing 0-lifetime prefixes (such a failure can happen for
various reasons: there may be a temporary failure in an intermediate
switch; the host may have been just too busy and cannot handle the
RAs, etc).  So, what's wrong in this scenario is that the router
doesn't keep advertising 0-lifetime-prefixes sufficiently long.  This
scenario itself doesn't explain 'why caching on-link prefix is a bad
idea'.

This story also explains why I previously said "such caching is a
minor implementation detail".  In terms of external behavior, a node
that caches configured address/on-link prefix and reuses it after a
reboot is often indistinguishable from a node that happens to fail
receiving some updates from RA for some period.  Killing the former
(while forgetting the latter) can just miss the more fundamental
problem.

Aside from this essential point, the new bullet does also not make
sense in the context of 'A correctly implemented IPv6 host MUST adhere
to the following rules'.  If we find any valid 'justification' like
this, it should be described outside this listing, somewhere more
appropriate in the entire context.

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