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

"Hemant Singh (shemant)" <shemant@cisco.com> Thu, 03 July 2008 20:35 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 13B123A6AA2; Thu, 3 Jul 2008 13:35:37 -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 B214A3A6ACA for <ipv6@core3.amsl.com>; Thu, 3 Jul 2008 13:35:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.063
X-Spam-Level:
X-Spam-Status: No, score=-6.063 tagged_above=-999 required=5 tests=[AWL=0.536, 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 OPbYT4oiII39 for <ipv6@core3.amsl.com>; Thu, 3 Jul 2008 13:35:34 -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 4FB083A688F for <ipv6@ietf.org>; Thu, 3 Jul 2008 13:35:34 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.27,744,1204502400"; d="scan'208";a="13153361"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 03 Jul 2008 20:35:42 +0000
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m63KZafq023415; Thu, 3 Jul 2008 16:35:36 -0400
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m63KZadl001742; Thu, 3 Jul 2008 20:35:36 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, 3 Jul 2008 16:35:36 -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 16:35:36 -0400
Message-ID: <B00EDD615E3C5344B0FFCBA910CF7E1D04E41EB4@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+WKwnVAxALufgAAhzNg
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 20:35:36.0651 (UTC) FILETIME=[595BF1B0:01C8DD4C]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6247; t=1215117336; x=1215981336; 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=tk68TSRD0kzIWkq+gJIb/FTPuvzQlb6C63kBfGbIYg4=; b=pBkFDo0GGneMaQN3rqfzHdGKvc4j9s/Z1pZ243PVBk1JtWlLIOAL//Sp0p kjNQQaTuUyeQntYIHKMMUSC3WRQWPG2TSrpkUGzmOU4JaiNPSkeEH9Xn+H2m VV3/bxh4E4;
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,

Thanks for the quick reply and review.  Please see in line below between
"<hs>" and "</hs>". 

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

<hs>Done. I had sent an email today saying the text has been removed.
What was removed is text between quotes below.
 ", or the source of a valid Neighbor Solicitation or Neighbor
Advertisement message."
</hs>


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

<hs>True, but what if someone has manually configured an IPv6 address
with prefix length, what are the Lifetime values for such a prefix? I am
not sure what happens here. Why not be then explicit and include such a
bullet. Also, the subject of our draft is focused on on-link
determination so we added such a bullet for completeness sake since
RFC4862 mentions persistent data across initializations. It is RFC4861
that deals with on-link determination. So why not have RFC4861 have such
text for on-link determination related to persistent storage. 
</hs>

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.

<hs>We'd like to keep this bullet because as you said, we wanted to
point out deprecated behavior. Further host implementations are
sometimes really blind and issue NS for non-link-local address even when
the host has been signaled off-link or host needs to issue only an
ICMPv6 error. We wanted to make such things clear even in this bullet.
It may be better to keep the behavior lock, stock, and barrel in bullet
5. Not only does an ICMPv6 Destination Unreachable need to be issued,
the host cannot issue an NS to resolve a non-link-local destination.
Further folks were also not sure where is the ICMPv6 Destination
Unreachable headed to even after RFC4943 has been published before our
draft? We made it very clear in this bullet 5.
</hs>

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

<hs>Yes, it is better - thanks! I have no problem with using it. 
    Hopefully Wes and Erik will not disagree with me.
</hs>

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

<hs>Yes, this is better too - thanks again. I have no problem with using
it.

Appreciate the quick review before a long weekend.

Have a good one.

Hemant
</hs>

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