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

"Bernie Volz (volz)" <volz@cisco.com> Mon, 20 August 2012 13:49 UTC

Return-Path: <volz@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 2544721F8681 for <dhcwg@ietfa.amsl.com>; Mon, 20 Aug 2012 06:49:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.421
X-Spam-Level:
X-Spam-Status: No, score=-10.421 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 pHMvmlPnindR for <dhcwg@ietfa.amsl.com>; Mon, 20 Aug 2012 06:49:43 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id B270C21F869A for <dhcwg@ietf.org>; Mon, 20 Aug 2012 06:49:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=7348; q=dns/txt; s=iport; t=1345470582; x=1346680182; h=from:to:cc:subject:date:message-id:mime-version; bh=OpTyfjUFVnMlB+P63PzzXkeaCYjYimpxVhkddeD4rHg=; b=CC3ZMpTf98r+BrJpqWUm7h8pPSVFbHUfc86w6FSxPNBwGmmj21AaV+Pe 1uYIG79b7J2yailaDCvbigGRdJTFdJ2DwCsK+oEuresLL1mwK/fC/l052 WKWrY+udNIUC2K3GeUqPbJk3Z0MopLu/PfxY6TQwaVC3/FfcAXk89DF9A 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFAIE/MlCtJXG9/2dsb2JhbABFgkq3f4EHgiABAQEDARIBGkwFBwYBCBEEAQELHTkUCQkBBAENBQgah2UGmHGfZIsLhjJgA4gam2KBZoJh
X-IronPort-AV: E=Sophos; i="4.77,797,1336348800"; d="scan'208,217"; a="113386029"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 20 Aug 2012 13:49:41 +0000
Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7KDnfvj030978 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Aug 2012 13:49:41 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0298.004; Mon, 20 Aug 2012 08:49:40 -0500
From: "Bernie Volz (volz)" <volz@cisco.com>
To: Ole Trøan <otroan@employees.org>, Ted Lemon <Ted.Lemon@nominum.com>
Thread-Topic: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 -- multiple adminstrative domains
Thread-Index: Ac1+2qSXxInmBkiATQCmRLl22d35Bg==
Date: Mon, 20 Aug 2012 13:49:39 +0000
Message-ID: <489D13FBFA9B3E41812EA89F188F018E0F4EE2F8@xmb-rcd-x04.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.86.255.113]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19126.004
x-tm-as-result: No--26.135600-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E0F4EE2F8xmbrcdx04ciscoc_"
MIME-Version: 1.0
Cc: dhc WG <dhcwg@ietf.org>
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00 -- multiple adminstrative domains
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 13:49:45 -0000

In the slides I presented at IETF-83 (Paris) and IETF-84 (Vancouver) about this work, the last slide had:

Multiple Administrative Domains
*       Still planning to write new Internet-Draft on multiple administrative domains
*       Basic proposal will be for Advertise to include "Administrative Domain" option which contains an "administrative domain string"
*       Clients treat Advertises with the same administrative domain string as 'equal'
*       Clients may select one or several administrative domains; If multiple, each is a separate state machine

The basic idea here is that if a client sends a Solicit with IA_NA and IA_PD, one server (or set of servers) may respond with IA_NA information and administrative domain string A and another server (or set of servers) may respond with IA_PD and administrative domain string B. This would trigger the client to initiate two separate state machines.

Of course, there is also the possibility that other server(s) may respond with both the IA_NA and IA_PD and administrative domain string C. In which case the client now has to determine whether to use one state machine (and administrative domain C) or two state machines and administrative domain A (IA_NA) & B (IA_PD).

While fairly simple in concept (and for servers [include administrative domain option] and relays [no impact]), it does greatly complicate clients.

One idea would be for clients to implement something similar to what they do for WiFi and SSIDs - a user would be required to select which administrative domains are valid. One interesting twist here is that just like with WiFI, we could also secure this -- add an encryption option which would provide a way to secure the DHCP server(s) with which you are willing to communicate.


I haven't started work on this draft as it wasn't clear how much interest there is and if there are real world requirements for something like this. If there is sufficient interest, I would be happy to start work on it.

- Bernie

-----Original Message-----
From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ole Trøan
Sent: Monday, August 20, 2012 8:45 AM
To: Ted Lemon
Cc: dhc WG
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00

Ted,

>> could we go forward with this draft that clarifies how multiple stateful options work in a single session, and with the general assumption that a client will choose one DHCP server and that server is authoritative?
>
> My concern is that if you do so, it will essentially result in clients standardizing on whatever behavior you specify, and so whether we write another standard or not, it will not be available in practice.

to turn the question around.
is there anyone who thinks that we should _not_ make multiple stateful options work in a single DHCP session?

cheers,
Ole