Re: [dhcwg] Comments on draft-troan-dhc-dhcpv6-stateful-issues-00
"Gaurav Halwasia (ghalwasi)" <ghalwasi@cisco.com> Fri, 25 May 2012 08:12 UTC
Return-Path: <ghalwasi@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 6EE6121F855F for <dhcwg@ietfa.amsl.com>; Fri, 25 May 2012 01:12:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gewcMjI7TuCb for <dhcwg@ietfa.amsl.com>; Fri, 25 May 2012 01:12:04 -0700 (PDT)
Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA4D21F8585 for <dhcwg@ietf.org>; Fri, 25 May 2012 01:12:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ghalwasi@cisco.com; l=25287; q=dns/txt; s=iport; t=1337933521; x=1339143121; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=gs8ivJP7gFpH5gscmRNBFWAc2yat9KF3VXPJA9xK8ts=; b=ecUhGs6UyRsnUU+gkDyPNn16eC9KlMQJUWgI01qJ6UfHsY3YGt7k0uoy JdWSUINHrabwPdqQahqKXC+o0JAWGig2Pl4WC17ZEtNcKF1oAJHzIaUko miItjUdM0/13qtTX/fGWXvCazVC9pMeA69VRpOpLII5ukUQrG6nllyhVl 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ar0EAFQ9v09Io8UY/2dsb2JhbABEgkWofgGKU4IVAQEBBBIBCREDWQIBCBEEAQELBhAHAQYBRQkIAQEEAQoICBMHh2sLmz6gAosBhGZgA4g9jWqMfYFkgmiBTgc
X-IronPort-AV: E=Sophos; i="4.75,655,1330905600"; d="scan'208,217"; a="12996859"
Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 25 May 2012 08:11:57 +0000
Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q4P8Bvpf025801 for <dhcwg@ietf.org>; Fri, 25 May 2012 08:11:57 GMT
Received: from xmb-bgl-41e.cisco.com ([72.163.129.220]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 May 2012 13:41:57 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD3A4E.0D82F8AE"
Date: Fri, 25 May 2012 13:40:08 +0530
Message-ID: <3CF88B99A9ED504197498BC6F6F04B81069F0308@XMB-BGL-41E.cisco.com>
In-Reply-To: <D9B5773329187548A0189ED6503667890C7B57AC@XMB-RCD-101.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [dhcwg] Comments on draft-troan-dhc-dhcpv6-stateful-issues-00
Thread-Index: Ac05uKdEL2fp8FLMS7ymS5aexC6oDgAKig9QAA/9SaA=
References: <D9B5773329187548A0189ED6503667890C7B57AC@XMB-RCD-101.cisco.com>
From: "Gaurav Halwasia (ghalwasi)" <ghalwasi@cisco.com>
To: "Bernie Volz (volz)" <volz@cisco.com>, dhcwg@ietf.org
X-OriginalArrivalTime: 25 May 2012 08:11:57.0690 (UTC) FILETIME=[0DCB4DA0:01CD3A4E]
Subject: Re: [dhcwg] Comments on draft-troan-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: Fri, 25 May 2012 08:12:07 -0000
Thanks Bernie for clarification. <snip> I believe, it is possible that a particular server is willing to offer only a subset of IA_'s which has been requested. In that case, what's the use of including the other IA_ in the subsequent renew/rebind. As in this case server will anyway only renew only one IA_. ? Are we suggesting that a client at any given point of time should only be talking to one server after the advertise is accepted. BV> What harm is there in continuing to include this in the subsequent operations? If the server's policy prohibits returning addresses or delegated prefixes for these other IA types, there is no harm. The main assumption is that clients are in a single administrative domain and thus talking to another server will be unlikely to help (except of course in the case of misconfiguration, but better that the issue is detected early and dealt with). </snip> [Gaurav] I don't see any harm in including not assigned IA_'s in subsequent renew and rebind. I wanted to clarify that with this text, we implicitly mean that client can only be associated with one server at a time. So we are saying that we can not have a deployment where 2 dhcpv6 servers (one doing IA_NA and other doing IA_PD) can be present. Also what if client first did IA_NA and at any later point of time it wants to do IA_PD. 1. Does it need to wait for the next renew time to get expired before it can ask IA_PD along.? 2. So are we saying that it should not send SOLICIT for IA_PD anytime in between.? If we are still allowing SOLICIT, should it only accept ADVERTISE from the server (which initially gave IA_NA) Thanks, Gaurav From: Bernie Volz (volz) Sent: Friday, May 25, 2012 1:00 AM To: Gaurav Halwasia (ghalwasi); dhcwg@ietf.org Subject: RE: [dhcwg] Comments on draft-troan-dhc-dhcpv6-stateful-issues-00 Hi and thanks for reading and commenting! Comments below (BV>). - Bernie From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Gaurav Halwasia (ghalwasi) Sent: Thursday, May 24, 2012 11:03 AM To: dhcwg@ietf.org Subject: [dhcwg] Comments on draft-troan-dhc-dhcpv6-stateful-issues-00 I have read this informational draft and I have couple of comments so far. 1.)Section 3.1 Replace Section 17.1.3 <http://tools.ietf.org/html/draft-troan-dhc-dhcpv6-stateful-issues-00#se ction-17.1.3> : (existing errata) The client MUST ignore any Advertise message that includes a Status Code option containing the value NoAddrsAvail, with the exception that the client MAY display the associated status message to the user. With: The client MUST ignore any IAs in an Advertise message that includes a Status Code option containing the value NoAddrsAvail, with the exception that the client MAY display the associated status message to the user. An Advertise message without any IA options MUST be ignored. Is this only applicable to IA_NA.? I guess in case client sends SOLICIT with both IA_NA and IA_PD. Then in that case I guess we should mention "NoPrefixAvail" as well. BV> It is applicable to IA_NA and IA_TA as those are the cases that end up with the Status Code option of NoAddsAvailable in the "main" part of the message - not in each IA_NA/IA_TA. (IA_PD puts the NoPrefixAvail Status Code option in the IA_PD itself. This is what we wish had been specified for IA_NA/IA_TA but was not.) 2.) Section 3.6 Proposed solution: the client should keep a single session with the server. The client should continue with the IA_ options received, while continuing to request the other IA options in subsequent messages to the server. That means continue to include the empty unanswered IAs in subsequent Renew and Rebind messages. I believe, it is possible that a particular server is willing to offer only a subset of IA_'s which has been requested. In that case, what's the use of including the other IA_ in the subsequent renew/rebind. As in this case server will anyway only renew only one IA_. ? Are we suggesting that a client at any given point of time should only be talking to one server after the advertise is accepted. BV> What harm is there in continuing to include this in the subsequent operations? If the server's policy prohibits returning addresses or delegated prefixes for these other IA types, there is no harm. The main assumption is that clients are in a single administrative domain and thus talking to another server will be unlikely to help (except of course in the case of misconfiguration, but better that the issue is detected early and dealt with). - Bernie
- [dhcwg] Comments on draft-troan-dhc-dhcpv6-statef… Gaurav Halwasia (ghalwasi)
- Re: [dhcwg] Comments on draft-troan-dhc-dhcpv6-st… Bernie Volz (volz)
- Re: [dhcwg] Comments on draft-troan-dhc-dhcpv6-st… Stephen Jacob
- Re: [dhcwg] Comments on draft-troan-dhc-dhcpv6-st… Gaurav Halwasia (ghalwasi)
- Re: [dhcwg] Comments on draft-troan-dhc-dhcpv6-st… Bernie Volz (volz)
- Re: [dhcwg] Comments on draft-troan-dhc-dhcpv6-st… Bernie Volz (volz)
- Re: [dhcwg] Comments on draft-troan-dhc-dhcpv6-st… Bernie Volz (volz)