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

"Hemant Singh (shemant)" <shemant@cisco.com> Thu, 03 July 2008 21:05 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 8413E3A68B4; Thu, 3 Jul 2008 14:05:18 -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 1B84E3A6868 for <ipv6@core3.amsl.com>; Thu, 3 Jul 2008 14:05:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.117
X-Spam-Level:
X-Spam-Status: No, score=-6.117 tagged_above=-999 required=5 tests=[AWL=0.482, 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 9AH1fFcv8KkX for <ipv6@core3.amsl.com>; Thu, 3 Jul 2008 14:05:15 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 6F9983A688F for <ipv6@ietf.org>; Thu, 3 Jul 2008 14:05:15 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.27,744,1204502400"; d="scan'208";a="13164899"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 03 Jul 2008 21:05:23 +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 m63L5N63004343; Thu, 3 Jul 2008 17:05:23 -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 m63L5NjC027465; Thu, 3 Jul 2008 21:05:23 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); Thu, 3 Jul 2008 17:05:23 -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, 3 Jul 2008 17:05:22 -0400
Message-ID: <B00EDD615E3C5344B0FFCBA910CF7E1D04E41EB6@xmb-rtp-20e.amer.cisco.com>
In-Reply-To: <200807031925.m63JPRp7031611@cichlid.raleigh.ibm.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
Thread-Index: AcjdQpxwlrI3ZGZMQ+WKwnVAxALufgADU/8A
References: <486388BD.2090801@innovationslab.net> <200807031925.m63JPRp7031611@cichlid.raleigh.ibm.com>
From: "Hemant Singh (shemant)" <shemant@cisco.com>
To: "Thomas Narten" <narten@us.ibm.com>, "Brian Haberman" <brian@innovationslab.net>
X-OriginalArrivalTime: 03 Jul 2008 21:05:23.0266 (UTC) FILETIME=[8243C220:01C8DD50]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5942; t=1215119123; x=1215983123; 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=22Thomas=20Narten=22=20<narten@us.ibm.com>,=0A=20=2 0=20=20=20=20=20=20=22Brian=20Haberman=22=20<brian@innovatio nslab.net>; bh=vhSiSfbtxEB9aCU+4J/i/sacM/55cxnHgI1oYt9LRYE=; b=iOSAVKwuyByEiiERokFtMoVyC2p3J+F8bjsuOhC2kiQaSYLNHMTJj3hifF XFp4VrGhSZ+s2RJisWkPmMdfBbFvHpB06qJ0NIZEC512Irt63IfBpqKQfQXe DrvUea2Z36;
Authentication-Results: rtp-dkim-1; header.From=shemant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );
Cc: ipv6@ietf.org, 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

Thomas,

Sorry, I forgot one item that Wes just reminded me of. Earlier in the
day I had emailed out our new text for bullet 2 that has this new line:

"The source of an ND message is no longer used for on-link
determination, which is a change from [RFC4861]."

So the new bullet 2 that you suggested in snipped below followed by our
suggestion to add the line above to the bullet.

 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 [RFC4861] or via manual
       configuration.  Note that the requirement for manually
       configured addresses is not explicitly mentioned in [RFC4861].

Better?

 2.  The configuration of an IPv6 address, whether through IPv6
       stateless address autoconfiguration [RFC4862], DHCPv6
       [RFC3315], or manual configuration MUST NOT implicitly 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 [RFC4861] or via manual
       configuration. The source of an ND message is no longer used 
       for on-link determination, which is a change from [RFC4861]. 
       Note that the requirement for manually configured addresses is 
       not explicitly mentioned in [RFC4861]. 

Thanks.

Hemant 

-----Original Message-----
From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of
Thomas Narten
Sent: Thursday, July 03, 2008 3:25 PM
To: Brian Haberman
Cc: Bob Hinden; ipv6@ietf.org
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

My. $.02.

Close to ready to ship.

Substantive:

>    In addition to the Prefix List, individual addresses are on-link if
>    they are the target of a Redirect Message indicating on-link, or
the
>    source of a valid Neighbor Solicitation or Neighbor Advertisement
>    message.

Per list discussion, this last part should be dropped.


>    3.  On-link determination SHOULD NOT persist across IPv6 interface
>        initializations.  Note that section 5.7 of [RFC4862] describes
>        the use of stable storage for addresses acquired with stateless
>        address autoconfiguration with a note that the Preferred and
>        Valid Lifetimes must be retained if this approach is used.
>        However no RFC suggests or recommends retaining the on-link
>        prefixes.

Hmm. I agree that the current specs don't suggest doing this, but is it
forbidden or wrong? I.e., is caching on-link information any worse than
caching the generated addresses? The PIO has Lifetime fields, and as
long as they are honored... ANd indeed, that is what point 4
reinforces...

I don't see right off why rule 3 is needed.

>    5.  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:

Hmm. When are we going to say implementations of 2461 should be fixed
and no longer support the "all destinations are on link?". Again, I am
not sure point 5 is appropriate to include here, other than perhaps to
point out that the 2461 behavior is deprecated.

Editorial:

> 1.  Introduction
> 
>    IPv4 implementations associate a netmask when an IPv4 address is
>    assigned to an interface.  That netmask together with the IPv4
>    address designates an on-link prefix.  Addresses that match this
>    prefix are viewed as on-link i.e., traffic to these addresses is 
> not

Better:

   IPv4 implementations typically associate a netmask with an address
   when an IPv4 address is assigned to an interface. That netmask
   together with the IPv4 address designates an on-link prefix.
   Addresses that are covered by this prefix are viewed as on-link
   i.e., traffic to these addresses is not sent to a router.  See
   section 3.3.1 in [RFC1122]. Prior to the deployment of CIDR, an
   address's netmask could be derived directly from the address. In
   tha absence of specifying a specific netmask when assigning a
   address, some implementations would fall back to deriving the
   netmask from the class of the address.



>    2.  The configuration of an IPv6 address, whether through IPv6
>        stateless address autoconfiguration [RFC4862], DHCPv6
[RFC3315],
>        or manual configuration MUST NOT imply that any prefix is on-
>        link.  A host is explicitly told that prefixes or addresses are
>        on-link through the means specified in [RFC4861].  Note that
this
>        requirement for manually configured addresses is not explicitly
>        mentioned in [RFC4861].
> 


Better (?):

   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 [RFC4861] or via manual
       configuration.  Note that the requirement for manually
       configured addresses is not explicitly mentioned in [RFC4861].






--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------