RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
"Hemant Singh (shemant)" <shemant@cisco.com> Thu, 10 July 2008 20:06 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 F05913A69AF; Thu, 10 Jul 2008 13:06:09 -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 44B493A69AF for <ipv6@core3.amsl.com>; Thu, 10 Jul 2008 13:06:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.058
X-Spam-Level:
X-Spam-Status: No, score=-6.058 tagged_above=-999 required=5 tests=[AWL=0.541, 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 9py6dlpvigSk for <ipv6@core3.amsl.com>; Thu, 10 Jul 2008 13:06:08 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id B91F63A6824 for <ipv6@ietf.org>; Thu, 10 Jul 2008 13:06:07 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.30,340,1212364800"; d="scan'208";a="64558094"
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 10 Jul 2008 20:06:01 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m6AK61IP018070; Thu, 10 Jul 2008 13:06:01 -0700
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6AK61kF000840; Thu, 10 Jul 2008 20:06:01 GMT
Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jul 2008 16:06:00 -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: Thu, 10 Jul 2008 16:06:00 -0400
Message-ID: <B00EDD615E3C5344B0FFCBA910CF7E1D04E41F23@xmb-rtp-20e.amer.cisco.com>
In-Reply-To: <m2lk09ms6m.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: AcjixrcNU8baCcz/RH+ioutCf+WuwAAAZ2Gw
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> <m2lk09ms6m.wl%Jinmei_Tatuya@isc.org>
From: "Hemant Singh (shemant)" <shemant@cisco.com>
To: Jinmei_Tatuya@isc.org
X-OriginalArrivalTime: 10 Jul 2008 20:06:00.0770 (UTC) FILETIME=[5FBE4220:01C8E2C8]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6297; t=1215720361; x=1216584361; c=relaxed/simple; s=sjdkim4002; 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; bh=Ko9ttE050JjVdRHZqk6QCPGECyb3EwoegWWpgqone9M=; b=uKiTL6X9NNjwsSH+90nOQltTwXMyst/3LZ+5kaNzV6Vvuo6CaphfVR3HG8 UQbz9fae1RplPhT4CGCf+2xtkNGkrSKuDTRsC/UbudxUAyfD9xxMa2kjf5nj rjjogKgCgT;
Authentication-Results: sj-dkim-4; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; );
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
Jinmei, Thanks for the comment. For this comment from you: "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." Yes, we have realized that and moved the bullet entirely out of the list of bullets and moved the text to end of section 2. Here is the new section 2. 2. Host Behavior and Rules A correctly implemented IPv6 host MUST adhere to the following rules: 1. By default only the link-local prefix is on-link. 2. The configuration of an IPv6 address, whether through IPv6 stateless address autoconfiguration [RFC4862], DHCPv6 [RFC3315], or manual configuration MUST NOT implicitely cause a prefix derived from that address to be treated as on-link. A host considers a prefix to be on-link only through explicit means, such as those specified in the on-link definition in the Terminology section of [RFC4861] or via manual configuration. Note that the requirement for manually configured addresses is not explicitly mentioned in [RFC4861]. 3. In the absence of other sources of on-link information, including Redirects, if the RA advertises a prefix with the on-link(L) bit set and later the Valid Lifetime expires, the host MUST then consider addresses of the prefix to be off-link, as specified by the PIO paragraph of section 6.3.4 of [RFC4861]. 4. Newer implementations, which are compliant with [RFC4861] MUST adhere to the following rules. Older implementations, which are compliant with [RFC2461] but not [RFC4861] may remain as is. If the Default Router List is empty and there is no other source of on-link information about any address or prefix: 1. The host MUST NOT assume that all destinations are on-link. 2. The host MUST NOT perform address resolution for non-link- local addresses. 3. Since the host cannot assume the destination is on-link, and off-link traffic cannot be sent to a default router (since the Default Router List is empty), address resolution cannot be performed. This case is specified in the last paragraph of section 4 of [RFC4943]: when there is no route to destination, the host should send an ICMPv6 Destination Unreachable indication (for example, a locally delivered error message) as specified in the Terminology section of [RFC4861]. On-link information concerning particular addresses and prefixes Singh, et al. Expires January 11, 2009 [Page 4] Internet-Draft IPv6 Subnet Model July 2008 can make those specific addresses and prefixes on-link, but does not change the default behavior mentioned above for addresses and prefixes not specified. [RFC4943] provides justification for these rules. 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. Hemant -----Original Message----- From: Jinmei_Tatuya@isc.org [mailto:Jinmei_Tatuya@isc.org] Sent: Thursday, July 10, 2008 3:54 PM To: Hemant Singh (shemant) Cc: Suresh Krishnan; Wes Beebee (wbeebee); 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 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 --------------------------------------------------------------------
- 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)