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

"Hemant Singh (shemant)" <shemant@cisco.com> Sun, 16 September 2012 16:17 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 CFD1621F8413 for <dhcwg@ietfa.amsl.com>; Sun, 16 Sep 2012 09:17:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.149
X-Spam-Level:
X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 Ql2sFgPdOf0x for <dhcwg@ietfa.amsl.com>; Sun, 16 Sep 2012 09:17:26 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 4D31821F8523 for <dhcwg@ietf.org>; Sun, 16 Sep 2012 09:17:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4376; q=dns/txt; s=iport; t=1347812246; x=1349021846; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ev1tyXl4YBhLLM2wdYYTRImAWlh4PGF5J+JJQ5IL1wQ=; b=SPd8E1vMkHe2SvvyvASEoKZJD+cKRi+LN97gIISHmGYOHjn3jmgIOXEP tiHS7Hoj3JKomUwKS4w87+WEt4ykW8cfDyVYvaMglHTCjmfpCmq8/mzfD 0Kg7fMK1Pdtl9Sv7EtrrjDGUwJrjxr9YpKHdFD84FjC0+kzdKKwS2wUB+ w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAHv6VVCtJV2c/2dsb2JhbABFvBKBB4IgAQEBBBIBJz8MBAIBCBEEAQELFAkHMhQJCAIEAQ0FCBqHXppCnwaGJYR8hghgA6QagWmCZoFjNA
X-IronPort-AV: E=Sophos;i="4.80,431,1344211200"; d="scan'208";a="122128168"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 16 Sep 2012 16:17:25 +0000
Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q8GGHPfW005248 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 16 Sep 2012 16:17:25 GMT
Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0298.004; Sun, 16 Sep 2012 11:17:25 -0500
From: "Hemant Singh (shemant)" <shemant@cisco.com>
To: "Hemant Singh (shemant)" <shemant@cisco.com>, Ted Lemon <Ted.Lemon@nominum.com>, "Bernie Volz (volz)" <volz@cisco.com>
Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00
Thread-Index: AQHNdqZP3dOUnDeDJkKs3MsN2OTAhpd/JdswgAB/xoD//5GrgIAAeqgAgAsV/xCAAo6qwA==
Date: Sun, 16 Sep 2012 16:17:25 +0000
Message-ID: <75B6FA9F576969419E42BECB86CB1B8908AAC6@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>
In-Reply-To: <75B6FA9F576969419E42BECB86CB1B8908A7CF@xmb-rcd-x06.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.86.252.137]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19186.002
x-tm-as-result: No--36.757900-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>, "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: Sun, 16 Sep 2012 16:17:27 -0000

Bernie,

Here is what I prefer for text for section 4.4 of the document.  All other text in the current section 4.4 is redundant with RFC 3315.

   The Confirm message, as described in [RFC3315], is specific to
   address assignment.  Note a server processing a Confirm message
   that includes only IA_NAs does not have to look up any client
   bindings. This document extends the Confirm to include other 
   IA option types.  It is desirable other IA option 
   types do not enforce the server to look up any client bindings 
   to respond to a Confirm.  Another IA option type is the IA_PD. 
   The server uses configured prefixes to determine if a prefix in 
   the IA_PD option is on-link to respond to a Confirm.

Another issue I'd like to bring up for the Confirm section of this document.  I realize the document only supports the case of one server replying to both the IA_NA and the IA_PD.  However, after a client has completed DHCPv6 for both the IA_NA and the IA_PD, some configuration on the server changes.  Later the client issues a Confirm and the server configuration change causes one IA type to fail the on-link check.  If the Status code option in the Reply is global, the Reply has a failed on-link code and the client moves to Solicit processing and the Solicits may continue indefinitely.  I recommend using the Status code option per IA option type.  Then for an IA option type not on-link status, the client can now use Information-request rather than moving to a Solicit transaction.  Thus more text changes to RFC 3315 are required.
 
Hemant

-----Original Message-----
From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Hemant Singh (shemant)
Sent: Friday, September 14, 2012 9:09 PM
To: Ted Lemon; Bernie Volz (volz)
Cc: dhc WG; Ole Troan (otroan)
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00

Ted/Bernie/Ole,

Humble apologies I was buried with other priorities and did not check my DHC WG email folder in a while. I actually replied to the xlat document in v6ops during my 10 days of PTO up till the Labor Day.  Bernie kindly reminded me this week of this document.  Most of my comments have been addressed.  Some pending are included below.

Why was the CONFIRM message deliberately specified by RFC 3633 as not supported for the IA_PD?  

It would be good to reply to this question.  Otherwise the IESG is likely to ask the same question and the answer to such a question may uncover issues for us.  

For one, it is easy for a server to respond to a CONFIRM to an IA_MA by just matching the IPv6 address configured on the machine the server is running on.  I am always reminded by some authors of RFC 3315 that the server distinctly does not consult its client bindings to respond to a CONFIRM for an IA_NA.  The server just relies on the machine IPv6 configuration to compute a status of on-link or not-on-link.  Thus why it is not a sea-change to support the CONFIRM for the IA_PD option and we may need to step gingerly?  If the server has to respond to a CONFIRM for an IA_PD, the server now consults with its bindings (I think Bernie alluded to in his reply to this thread) which the server did not do before for the IA_NA.  Searching thru bindings has delay implications and additional server computations.  Or as I had already said in my earlier reply that the server checks what prefixes are configured on the server to determine on-link status.  However checking prefixes for IA_PD 
 at a server has to exclude prefixes that are used for allocation of IA_NA.  So now the server maintains two types of prefixes.  

Thus I will try and propose some text over the weekend that IA_PD support in CONFIRM can't suffice with network configuration.  Some other data in the server needs checking and we should try and be little specific about the data.  Just saying something like "the sever checks network configuration" doesn't cut it for the IA_PD.  

Let me see what I can do over this weekend and propose some text as to how the server checks for on-link or not for the IA_PD to respond to a CONFIRM.  I will also catch up with other emails on this document and reply, if necessary.

Regards,

Hemant