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

Ole Trøan <otroan@employees.org> Mon, 20 August 2012 09:13 UTC

Return-Path: <ichiroumakino@gmail.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 D360C21F8682 for <dhcwg@ietfa.amsl.com>; Mon, 20 Aug 2012 02:13:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.093
X-Spam-Level:
X-Spam-Status: No, score=-3.093 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
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 W9T1WvGgEJ2H for <dhcwg@ietfa.amsl.com>; Mon, 20 Aug 2012 02:13:18 -0700 (PDT)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id C81B421F8543 for <dhcwg@ietf.org>; Mon, 20 Aug 2012 02:13:17 -0700 (PDT)
Received: by eekb45 with SMTP id b45so1532162eek.31 for <dhcwg@ietf.org>; Mon, 20 Aug 2012 02:13:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=10ah5Zsbs6wkX5HMPCOfxvo4zvS45nokJplVObfGTXc=; b=l/HtOTbS6M1qnRf8d18WW1wrJkZdMrAQWyIYjQWCzEawCjcVPbPEuWO8Ji6vcpzv29 R9qRvRQ/eZmm0UPWk63MtFKTrAy0N51UOi8HgzJiLA1fvg+E2OZtbm8dfriIOSxwZ2ZP EYHyWdGcgZU0y7iX2AigRcJ0+VmuSNnsK4N5Yz+E1iW0UyvWYJIY+hXRq3zYsjampK9G 0x0Il+51Y47yYN7zMr5AEbSkhqNYyZ/GsKHInLHuHSlY6maCFo0ce0GTAyGdFWV5P1Fr oOSg6HmSWgBefsDs033FspwcRqMm50SJEqxcYej5STVr8LGBbvIaepkeYBE4g4xtBfLR GEeA==
Received: by 10.14.206.200 with SMTP id l48mr7899624eeo.41.1345453997039; Mon, 20 Aug 2012 02:13:17 -0700 (PDT)
Received: from dhcp-lys01-vla250-10-147-112-132.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id z6sm40091299eeo.6.2012.08.20.02.13.14 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Aug 2012 02:13:15 -0700 (PDT)
Sender: Ole Troan <ichiroumakino@gmail.com>
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: multipart/signed; boundary="Apple-Mail=_E3E2458F-2BEF-4ADE-B46E-D1BAE1C85A4E"; protocol="application/pkcs7-signature"; micalg="sha1"
From: Ole Trøan <otroan@employees.org>
In-Reply-To: <75B6FA9F576969419E42BECB86CB1B89071546@xmb-rcd-x06.cisco.com>
Date: Mon, 20 Aug 2012 11:13:15 +0200
Message-Id: <805BB5B0-7046-4C98-9368-2CEC2BDC360D@employees.org>
References: <0AE8374B-0E04-48FF-B71D-2EE8FAAC9ED1@nominum.com> <93E6DE37-FD02-42BC-B4E9-DF0BBCD06C02@nominum.com> <5AAE3B81-ABDE-49AF-BD14-C5307EC7CA7E@nominum.com> <75B6FA9F576969419E42BECB86CB1B89071546@xmb-rcd-x06.cisco.com>
To: Hemant Singh <shemant@cisco.com>
X-Mailer: Apple Mail (2.1278)
Cc: dhc WG <dhcwg@ietf.org>, Ted Lemon <Ted.Lemon@nominum.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: Mon, 20 Aug 2012 09:13:19 -0000

Hemant,

> +1 to Wes' comment that this document is addressing a very important problem space and the solutions are needed urgently.  However, more thought is required for the solutions.
> 
> In regards to section 4.4, if the server only checks the network configuration to reply to a Confirm message, how is it possible for most network configurations that the server determines an IA_PD is on-link?   I suspect that is why RFC 3633 prohibited use of the Confirm for the IA_PD.  In any case this document should explain why did RFC 3633 have a restriction on using the Confirm for the IA_PD.  Or does network configuration include looking up the prefix pool configured on the server for allocation?  In contrast, to make an on-link determination for an IA_NA IA_Address, all the server has to do is match (longest-prefix match) all IPv6 addresses configured on the machine that the server is running on.  These addresses are clearly network configuration. 

right, either the server has the binding, or the server has configuration that it can look up in, to verify if the client has moved or not. if it has no information it MUST not reply.

> Section 4.1:  
> 
> # In relation to the first paragraph the document is addressing the fact that one server replies with, say, an IA_NA, while another server replies back with only the IA_PD.   Then why in section 4.7 the case of section 4.1 is deemed out of scope?   I also do not understand what does "equal" in section 4.7 mean.  Does it mean each server replies with all IAs that the deployment needs?

the assumption in 3315/3633 is that a client is connected to a single administrative dhc domain on an interface.
scenarios where a client finds two DHCP servers, that are administered by two different entities, are outside of the scope of 3315/3633 and therefore also outside the scope of this update. there is as far as I know separate work in progress on this.

> # In relation to the text in the last paragraph of section 4.1, if the client does not restart the Solicit retransmissions timers, what does the client do?

continues with the timers it has.
otherwise as the text says, a received advertise with a consequent restart of solicit timers would result in a solicit storm.

> 
> # Other comment:  Shouldn't the header of the document have an Updates tag to signify this document updates RFC 3315?

good point. both 3315 and 3633.

cheers,
Ole