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

Ted Lemon <Ted.Lemon@nominum.com> Thu, 16 August 2012 16:21 UTC

Return-Path: <Ted.Lemon@nominum.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 B557221F8611 for <dhcwg@ietfa.amsl.com>; Thu, 16 Aug 2012 09:21:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.553
X-Spam-Level:
X-Spam-Status: No, score=-106.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 WpBaHiLzuRVd for <dhcwg@ietfa.amsl.com>; Thu, 16 Aug 2012 09:21:31 -0700 (PDT)
Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 1664B21F85CD for <dhcwg@ietf.org>; Thu, 16 Aug 2012 09:21:31 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKUC0eCh7OG2Pqa8YbDkdDH8gV8tPkSnTR@postini.com; Thu, 16 Aug 2012 09:21:31 PDT
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 4F79E1B82F2 for <dhcwg@ietf.org>; Thu, 16 Aug 2012 09:21:30 -0700 (PDT)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 45B46190052 for <dhcwg@ietf.org>; Thu, 16 Aug 2012 09:21:30 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Thu, 16 Aug 2012 09:21:30 -0700
From: Ted Lemon <Ted.Lemon@nominum.com>
To: dhc WG <dhcwg@ietf.org>
Thread-Topic: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00
Thread-Index: AQHNdqZP3dOUnDeDJkKs3MsN2OTAhpddHmiA
Date: Thu, 16 Aug 2012 16:21:29 +0000
Message-ID: <93E6DE37-FD02-42BC-B4E9-DF0BBCD06C02@nominum.com>
References: <0AE8374B-0E04-48FF-B71D-2EE8FAAC9ED1@nominum.com>
In-Reply-To: <0AE8374B-0E04-48FF-B71D-2EE8FAAC9ED1@nominum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.1.10]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <456BCB8C62421A43B1BC759817FB39DB@nominum.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Thu, 16 Aug 2012 16:21:31 -0000

Not wearing my chair hat, I support what this draft is trying to do.   However, the draft makes a decision to unify the state machines of the IA_NA and IA_PD maintenance process.   We've had some discussions about this with customers, and one question that came up was whether it might make sense to have different DHCP servers answering IA_NA and IA_PD requests.   Obviously this is not possible if the transaction can't be split.

Have the authors considered this issue?   Any opinions on the topic?

The reason for the potential separation is that in some cases the business logic involved in delegating prefixes may be different than the logic used to allocate addresses.   Keeping the two functions separate enables significant additional flexibility when provisioning CPE devices.   This draft, if it were to progress in its current state, would rule out any such flexibility.   This is not an absolute deal breaker for me, but I wanted to raise the issue and see if anybody else has thought about this.