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

JINMEI Tatuya / 神明達哉 <Jinmei_Tatuya@isc.org> Fri, 18 July 2008 01:43 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 955D128C147; Thu, 17 Jul 2008 18:43:21 -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 5F04828C147 for <ipv6@core3.amsl.com>; Thu, 17 Jul 2008 18:43:20 -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 gaJ4poyi9LVk for <ipv6@core3.amsl.com>; Thu, 17 Jul 2008 18:43:19 -0700 (PDT)
Received: from mon.jinmei.org (mon.jinmei.org [IPv6:2001:4f8:3:36::162]) by core3.amsl.com (Postfix) with ESMTP id DCF8D28C13D for <ipv6@ietf.org>; Thu, 17 Jul 2008 18:43:18 -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 4852E33C2E; Thu, 17 Jul 2008 18:43:49 -0700 (PDT)
Date: Thu, 17 Jul 2008 18:43:49 -0700
Message-ID: <m263r4dl0q.wl%Jinmei_Tatuya@isc.org>
From: JINMEI Tatuya / 神明達哉 <Jinmei_Tatuya@isc.org>
To: "Wes Beebee (wbeebee)" <wbeebee@cisco.com>
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
In-Reply-To: <BB56240F3A190F469C52A57138047A03B26319@xmb-rtp-211.amer.cisco.com>
References: <m2lk09ms6m.wl%Jinmei_Tatuya@isc.org> <BB56240F3A190F469C52A57138047A03B26319@xmb-rtp-211.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>, Brian Haberman <brian@innovationslab.net>, ipv6@ietf.org, Suresh Krishnan <suresh.krishnan@ericsson.com>, 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

At Thu, 10 Jul 2008 16:21:35 -0400,
"Wes Beebee (wbeebee)" <wbeebee@cisco.com> wrote:

> The problem is that one problem is FAR more likely to happen than the other.
> 
> I shutdown my machine every night and power it on again in the
> morning when I come to work.  Therefore, every night of every
> workday I experience the type of outage described in our draft.
> Furthermore, I occasionally go on vacations too - so the outage may
> last more than a day.
> 
> What this means for an administrator is that he has to predict, in
> advance, how long I may be on vacation so that the RA deprecating
> the old prefix can last long enough.  That puts an unreasonable
> expectation on the network administrator.  Furthermore, I don't want
> to have to get permission from my network administrator in order to
> go on vacation.

You're using inappropriate examples to justify the proposed text:

   Using cached on-link determination information without first
   verifying that the information is still valid after IPv6 interface
   re-initialization may lead to lack of IPv6 network connectivity.  For
   example, a host receives an RA from a router with on-link prefix A.
   The host reboots.  During the reboot, the router sends out prefix A
   with on-link bit set and a zero lifetime to indicate a renumbering.
   The host misses the renumbering.  The host comes online.  Then, the
   router sends an RA with no PIO.  The host uses cached on-link prefix
   A and issues NS's instead of sending traffic to a default router.
   The "Observed Incorrect Implementation Behavior" section below
   describes how this can result in lack of IPv6 connectivity.

This reads to me that the outage is a pretty short time (i.e., while
the host is rebooting), while assuming the administrator stops
advertising the 0-lifetime RAs so quickly.  That's why I said "what's
wrong in this scenario is that the router doesn't keep advertising
0-lifetime-prefixes sufficiently long".

Even if in the vacation case, the administrator shouldn't stop
advertising 0-lifetime RAs as long as some hosts may keep an old
address or prefix.  Note that they don't have to predict anything
about the users' vacation plan to do so: the necessary period can be
calculated from the previously advertised lifetime and the time when
the renumbering procedure starts.

Having said that, I see your point if we are mainly considering a case
of reconnecting after a long term absence such as a vacation.  Even
though the administrator should keep advertising 0-lifetime RAs to
avoid confusion, it should also be advisable for the host to purge the
old information (or at least confirm whether it's still valid).

So, for example, if the proposed text were something like this:

   Using cached on-link determination information without first
   verifying that the information is still valid after IPv6 interface
   re-initialization may lead to lack of IPv6 network connectivity.  For
   example, consider the case where a host caches an on-link prefix
   and leaves the subnet for weeks.  If the network renumbers during
   the period but the host continues to keep the cached (already
   invalid) information when it returns, it may lead to a problem
   described in Section 3 below.

that would make sense to me.  I'd then be wondering whether this is
really something to be noted explicitly since it may sound something
pretty obvious.

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