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