Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00

"Hemant Singh (shemant)" <shemant@cisco.com> Sat, 22 September 2012 12:48 UTC

Return-Path: <shemant@cisco.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E949D21F85C4 for <dhcwg@ietfa.amsl.com>; Sat, 22 Sep 2012 05:48:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGewuLFmjq6v for <dhcwg@ietfa.amsl.com>; Sat, 22 Sep 2012 05:48:26 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id A54B321F85B8 for <dhcwg@ietf.org>; Sat, 22 Sep 2012 05:48:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4276; q=dns/txt; s=iport; t=1348318106; x=1349527706; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=59aW+KaQfrM3HTknzWpcwO/kJin9/FJce1mtlDP15Fc=; b=GkMx0SucTLh+sRQglgcUQyUAupZIF84nWVq+onN2P2YA48PgEqUBGG4f LsOLO5ViY77c/kcw8g3CyYaG1wt+d6Njm2f789ypUw3xZY/iFjkcCIPel jamkEvLc2GJRBP90rVvVfbrSQ1yj9yeylVGGiyC+NrzpiaUCKhPQq4hKV Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAGmzXVCtJXG+/2dsb2JhbABFviuBCIIgAQEBBBIBFBM/DAQCAQgRBAEBCxQQMh0IAgQODRqHY5hUn3+LHIVKYAOkHoFpgmeBYzQ
X-IronPort-AV: E=Sophos;i="4.80,467,1344211200"; d="scan'208";a="124255406"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 22 Sep 2012 12:48:21 +0000
Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8MCmKh1012604 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 22 Sep 2012 12:48:20 GMT
Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0298.004; Sat, 22 Sep 2012 07:48:20 -0500
From: "Hemant Singh (shemant)" <shemant@cisco.com>
To: "Bernie Volz (volz)" <volz@cisco.com>
Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00
Thread-Index: AQHNdqZP3dOUnDeDJkKs3MsN2OTAhpd/JdswgAB/xoD//5GrgIAAeqgAgAsV/xCAAo6qwIAAkkeagAiZUBA=
Date: Sat, 22 Sep 2012 12:48:19 +0000
Message-ID: <75B6FA9F576969419E42BECB86CB1B89090180@xmb-rcd-x06.cisco.com>
References: <0AE8374B-0E04-48FF-B71D-2EE8FAAC9ED1@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4F83D1@xmb-rcd-x04.cisco.com> <21C54D57-372F-46B0-892B-398919992546@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4F857F@xmb-rcd-x04.cisco.com> <CD3ECABE-12FB-428C-9FFF-078793B32C0E@nominum.com> <75B6FA9F576969419E42BECB86CB1B8908A7CF@xmb-rcd-x06.cisco.com>, <75B6FA9F576969419E42BECB86CB1B8908AAC6@xmb-rcd-x06.cisco.com> <56DD5F8D-D04D-40F6-B5BA-A5673E2264F8@cisco.com>
In-Reply-To: <56DD5F8D-D04D-40F6-B5BA-A5673E2264F8@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.86.251.15]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19202.004
x-tm-as-result: No--49.177900-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: dhc WG <dhcwg@ietf.org>, Ted Lemon <Ted.Lemon@nominum.com>, "Ole Troan (otroan)" <otroan@cisco.com>
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 22 Sep 2012 12:48:31 -0000

Bernie & Ole,

Sorry for the delay.  Please see in line below.  Also, let's talk sometime next week at work and we can resolve the issues offline and then let the mailer know.

-----Original Message-----
From: Bernie Volz (volz) 
Sent: Sunday, September 16, 2012 8:27 PM
To: Hemant Singh (shemant)
Cc: Ted Lemon; dhc WG; Ole Troan (otroan)
Subject: Re: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00

>The server I work on does not look up bindings for Confirming IAPREFIX (the server has allowed Confirm on prefixes since day one) so this text is false >and is not required. 

That's one server.  We could use text that has generic requirements for all servers.  I wrote a bunch of text including text that says client bindings should not be looked up.  I also said most of the text in the Confirm section of your document is redundant with RFC 3315.  Thus it makes sense to retain most of the text I proposed.  I think the text you say is false is this.

"The server uses configured prefixes to determine if a prefix in the IA_PD option is on-link to respond to a Confirm."

>The server does the same processing it does for addresses. It looks up the link and prefix configuration and if the delegated prefix sent by the client >(or address sent by the client) is contained by a configured prefix the client is told success. If it can't tell (this is mostly the case for addresses >that are link-local but also in cases where the clients "location" can not be determined from one of the addresses or prefixes provided by the client) it >doesn't respond. Otherwise the client is told not-on-link.

Hmm, does DHCPv6 assign a link-local address to a client that a client will issue a Confirm for a link-local address?  I am also replying to Ole in this email.  Ole said 

"(the reason we did what we did in 3633 with regards to Confirm, was because of the text around "Onlink"." 

It makes sense that OnLink is defined in some document.  Both RFC 3315 and RFC 4861 have identical definition for "link".  This definition says nodes on the link can communicate below the IP layer.  So how is a globally routable IPv6 address in an IA_NA or a prefix in the IA_PD determined to be OnLink when both entities communicate at the IP layer?  I know you have given details on how does your server determines OnLink.  But those are details and internal constructs of one server.  We need an example for how do all servers determine what is OnLink for the IA_PD prefix.
  
>Confirm never says a particular address or prefix is leased to the client. It just says whether the client has clearly moved or not (no response means >the server can't determine). 
>
>So, I do not agree with this text change at all.

Looking up a link matching a prefix configuration does not work for all cases.  The client moves and another link on the server can serve the same prefix.  So now the server has to look up a collection of prefixes.  How are prefixes collected?  Based on what metric? 

>Regarding the second issue ... If the configuration has changed to remove prefix delegation or addresses, but not the other, and the Confirm returns Not->On-Link, client would move back to Solicit but why would Solicits continue forever? Are you thinking a client would implement some, but not all changes? >I would think that is wrong - this is a package of changes the client and server need to implement. So, the other changes would prevent the continous >Solicits? We have no good way to return separate status codes for prefix vs address and I don't see this as needed per what I just wrote?

If you don't have a good way to return separate status codes for prefix vs. address, then I doubt if the sever has a good way to determine if each of the prefix and address is NotOnLink?  Why would the Solicit not continue forever.  Then network has only one server.  The server has removed one IA type and the client 's Solicit will not be responded by the server any more.  Thus if Reply received to a Confirm has one IA type as NotOnLink, the client switches to the Information-Request with that IA type. 

Thanks,

Hemant