RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
"Hemant Singh (shemant)" <shemant@cisco.com> Fri, 18 July 2008 15:19 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 0F4853A6AD5; Fri, 18 Jul 2008 08:19:20 -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 196DE3A67FB for <ipv6@core3.amsl.com>; Fri, 18 Jul 2008 08:19:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.88
X-Spam-Level:
X-Spam-Status: No, score=-5.88 tagged_above=-999 required=5 tests=[AWL=0.718, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 mu0Diedyfn-X for <ipv6@core3.amsl.com>; Fri, 18 Jul 2008 08:19:17 -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 1E2CA28C18E for <ipv6@ietf.org>; Fri, 18 Jul 2008 08:19:17 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="4.31,210,1215388800"; d="scan'208,217"; a="14712236"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 18 Jul 2008 15:19:45 +0000
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6IFJkpe015649; Fri, 18 Jul 2008 11:19:46 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6IFJjA9007783; Fri, 18 Jul 2008 15:19:45 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); Fri, 18 Jul 2008 11:19:45 -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: Fri, 18 Jul 2008 11:19:45 -0400
Message-ID: <B00EDD615E3C5344B0FFCBA910CF7E1D04E41F9E@xmb-rtp-20e.amer.cisco.com>
In-Reply-To: <m263r4dl0q.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: Acjod+ivDzDLW86qQVOOMebafVd2ywAbHSmw
References: <m2lk09ms6m.wl%Jinmei_Tatuya@isc.org> <BB56240F3A190F469C52A57138047A03B26319@xmb-rtp-211.amer.cisco.com> <m263r4dl0q.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: 18 Jul 2008 15:19:45.0797 (UTC) FILETIME=[B5F75B50:01C8E8E9]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=18250; t=1216394386; x=1217258386; c=relaxed/simple; s=rtpdkim1001; 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=ZThajUOfLsBJ222YaTe70dy/o11k/SIskiSTBpU9TGc=; b=ljkf2gH5YBSXxHaAqnIj45UqK9aamptrZ85MBwu0aT1M68VlpjtEN9qYqc iGN3zLGprFe67gNqYqCrtoHelSR22+aXr2WQ0FTx55etu/afDHzqeieaOc73 aKRiLuEZU/;
Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );
Cc: Thomas Narten <narten@us.ibm.com>, ipv6@ietf.org, Brian Haberman <brian@innovationslab.net>, Bob Hinden <bob.hinden@nokia.com>, Suresh Krishnan <suresh.krishnan@ericsson.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: multipart/mixed; boundary="===============0631934165=="
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
Tatuya, Thanks for all your email. Please see in line between <hs> and </hs>. -----Original Message----- From: Jinmei_Tatuya@isc.org [mailto:Jinmei_Tatuya@isc.org] Sent: Thursday, July 17, 2008 9:44 PM To: Wes Beebee (wbeebee) Cc: Hemant Singh (shemant); Suresh Krishnan; Thomas Narten; Brian Haberman; Bob Hinden; ipv6@ietf.org Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt 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 Tatuya > 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: <hs> Agreed. However, Wes did make a point that these are problems FAR more likely to happen and also gave examples of timeframes that are much longer than the reload time for a host. Like weeks of vacation or 6-8 hours every night. </hs> 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). <hs> We just don't want to completely rely on an admin of the router network to do the right thing and not say, fat-finger any configuration. Soon as any admin mis-configuration is done, we can get into the problem of Section 3 and data forwarding stops. The host should be defensive as well. The goal of our draft it to cover any case that can cause the problem of Section 3. We see blind caching of on-link determination as a candidate that may cause the problem. </hs> 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. <hs> The renumbering may sound obvious to you after we have discussed the case of overnight shutdown and vacation and gave a specific example of prior and post RA (with PIO and without PIO). Anyway, this is the example in the paragraph. The main point is that blind caching of on-link determination is not recommended host behavior. We would like to keep this text - your proposed text looks fine to me. We may modify your proposed text by giving a specific prior and post RA example. Further, since RFC4862 and RFC4861 differ in the 2-hour rule for address autoconfiguration vs. on-link determination, why is it not OK to only mention on-link determination blind caching in our draft and not mention any address with blind caching? I am not too strong on this one. If we are allowed to keep our text and you still insist we add address to blind caching paragraph, I can do that. But note, even when we add address to the blind caching paragraph, there is no normative text in our paragraph that overrules anything related to caching addresses in RFC4862. So why do any host implementors have to worry about anything? Wes is on vacation till Wednesday next week. My statements here only represent me. I need to talk to Erik and Wes too about this one. </hs> Hemant --- JINMEI, Tatuya Internet Systems Consortium, Inc.
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
- 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-mod… Brian Haberman
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Wojciech Dec (wdec)
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Wes Beebee (wbeebee)
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Wojciech Dec (wdec)
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… MILES DAVID
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… MILES DAVID
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… MILES DAVID
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Thomas Narten
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Thomas Narten
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Wes Beebee (wbeebee)
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Thomas Narten
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… JINMEI Tatuya / 神明達哉
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Wes Beebee (wbeebee)
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… JINMEI Tatuya / 神明達哉
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Wes Beebee (wbeebee)
- FW: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)
- Re: FW: 6MAN WG Last Call:draft-ietf-6man-ipv6-su… JINMEI Tatuya / 神明達哉
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… JINMEI Tatuya / 神明達哉
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Thomas Narten
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… MILES DAVID
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Thomas Narten
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… JINMEI Tatuya / 神明達哉
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… JINMEI Tatuya / 神明達哉
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Thomas Narten
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Suresh Krishnan
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Suresh Krishnan
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Wes Beebee (wbeebee)
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… JINMEI Tatuya / 神明達哉
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Wes Beebee (wbeebee)
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Erik Nordmark
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Erik Nordmark
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Erik Nordmark
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Erik Nordmark
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Erik Nordmark
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… JINMEI Tatuya / 神明達哉
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… JINMEI Tatuya / 神明達哉
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… JINMEI Tatuya / 神明達哉
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… JINMEI Tatuya / 神明達哉
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Wes Beebee (wbeebee)
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Azinger, Marla
- 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-mod… Brian Haberman
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Brian Haberman
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Brian E Carpenter
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Wes Beebee (wbeebee)
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… JINMEI Tatuya / 神明達哉
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… JINMEI Tatuya / 神明達哉
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Wes Beebee (wbeebee)
- Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… JINMEI Tatuya / 神明達哉
- RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet… Hemant Singh (shemant)