From nobody Wed Jun 1 03:41:52 2016 Return-Path: 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 71D5912D157 for ; Wed, 1 Jun 2016 03:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EM62JK6hxfVt for ; Wed, 1 Jun 2016 03:41:49 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E3D512D098 for ; Wed, 1 Jun 2016 03:41:41 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id w16so9873683lfd.2 for ; Wed, 01 Jun 2016 03:41:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=AvYFx75W9f8hxJFj+WKRd7zohhOuhRhPfY8AYh/bd+k=; b=nw4Hk9AQ5l3FV87h7J+8I/SQJ7xyZF+ZsT5fm2lhgjKK3ylNLcqKT7YOCsFbJMnFbI f+PaxyijISJioPye8+ThBOfDnt1u7UkvHx5jBE5mSdeyzTLSOW/g/k1W4COEur0nhHRx VohSOoy4AXYD7A48IpvdCi3KJqT+CfvHhtmvYrUqKRPw04ZLMBv7W6css3jX10wLaCsq 4yPrRizKVisSAajvbQrfPDGLvNCak621AxQK0/1Ud9gTPriixQZjdVrvOOhwMpaDcOiS wh1ClNEFfxJ7sNNEa0g29+K0OaAzj1Dwpwrfz9/gmVvz04Cch0AlDd2IEl4YAfiUOEqu Noxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=AvYFx75W9f8hxJFj+WKRd7zohhOuhRhPfY8AYh/bd+k=; b=TeKoE4m1LhX/UUylKKb+yNHVLkbmSqP01iETLcpfjSsyaE0Xjlwug9iDEB+MmHzSLJ 0IKebLyC7ET0oRsu01kyXKW3ZkbHbeELRzZoULuGHQmyyqVfW3txy3F23NYLacDuOvih /M980+hbRTmCR5Na4bpx/SyYZNV9Vy7RpMKGUS8+EL120FGXg3K65vEqaI9A/ZqjoTuT kr8Pj7Dsxlm2TpI0P9E8CGG/2HyMzr9xG2xj/neD5sk1s6Sd17e4K4F0mQ4KJ+zXN3k/ zoxEgRfalTem63oQmrC0bv+D0zC8xdG5tQjVs7Gzdo8BN3a5YQkpO4+zXXuhjOU/0Qm+ Ph7g== X-Gm-Message-State: ALyK8tK6LuDqM5+DMnnSvIfDJGsgRS3wfg/Sly53l14BDs8FBLjfdH4RNAdwx9msk+S4HQ== X-Received: by 10.46.33.77 with SMTP id h74mr1299493ljh.50.1464777699424; Wed, 01 Jun 2016 03:41:39 -0700 (PDT) Received: from [10.0.0.100] (088156132194.dynamic-ww-04.vectranet.pl. [88.156.132.194]) by smtp.googlemail.com with ESMTPSA id rf7sm5862810lbb.11.2016.06.01.03.41.37 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Jun 2016 03:41:38 -0700 (PDT) To: dhcwg References: <5733617B.1040309@gmail.com> From: Tomek Mrugalski X-Enigmail-Draft-Status: N1110 Message-ID: <574EBBE0.4010202@gmail.com> Date: Wed, 1 Jun 2016 12:41:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <5733617B.1040309@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dhcwg] DHCP hackathon in Berlin? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 10:41:51 -0000 Just a small update regarding hackathon. Bernie and I received a couple of responses so far. One new topic has been proposed and seems to be getting some traction: RFC7550/RFC3315bis changes. There will be at least two server implementations to be tested: Cisco's CNR and ISC's Kea. We're lacking client support, so the plan is to hack a client during the hackathon. It seems the easiest open source client to modify is Dibbler, but we're also looking at the ISC DHCP client modification. There's a team from Tsinghua university that's interested in developing YANG module for DHCPv6 server. The code to be extended is Kea. We also have one newcomer (both to IETF and to hackathon) who is interested in participating! Welcome! Please keep in mind that IETF is about rough consensus and running code. We usually focus on the consensus part, but here's your chance to help with the running code as well. Tomek On 11.05.2016 18:44, Tomek Mrugalski wrote: > Hey DHCP hackers! > > The IETF meeting in Berlin is not that far off. We'll have an > opportunity to meet and hack some DHCP code, if we desire so. As usual, > the question is whether there are enough people interested in hacking > DHCP? Hackathons traditionally happen during the weekend before IETF, so > it means July 16-17 this time. > > Please respond if you're interested in participating. Feel free to > propose the topics. > > Looking at the current topics in DHC, it seems we have 2 areas that > could definitely benefit from a hackathon. The first one is secure > DHCPv6. We did some successful experiments in Prague (Kame client was > interoperating with Kea server), but that was based on an old version of > draft-ietf-dhc-sedhcpv6-12, which has changed significantly since then. > > Another prospective topic for a hackathon is YANG module. One of the > concerns raised against draft-ietf-dhc-dhcpv6-yang-01 (or rather general > comment against any attempts of configuration standardization) was that > it may be difficult to find a common denominator between existing DHCP > implementation's configurations. Having a working code > would definitely be a strong argument in favour of moving this draft > forward. > > Other topics are certainly welcome as well. Having two or more people > working in the same feature are better than focusing on independent areas. > > If you're interested in participating, but don't have a code base you'd > want to work on, feel free to contact me and I'll give you some pointers > to easily accessible open source implementations that are hackers friendly. > > Tomek > From nobody Wed Jun 1 04:29:34 2016 Return-Path: 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 4145112B059 for ; Wed, 1 Jun 2016 04:29:33 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "To" X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovg4D4ArgAM4 for ; Wed, 1 Jun 2016 04:29:31 -0700 (PDT) Received: from mail.marples.name (uberserver.marples.name [77.75.106.61]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F98312D186 for ; Wed, 1 Jun 2016 04:29:29 -0700 (PDT) Received: by mail.marples.name (Postfix, from userid 1010) id C1C16A159C; Wed, 1 Jun 2016 12:29:25 +0100 (BST) To: Tomek Mrugalski X-PHP-Originating-Script: 0:rcube.php MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 01 Jun 2016 12:29:25 +0100 From: Roy Marples To: Tomek Mrugalski In-Reply-To: <574EBBE0.4010202@gmail.com> References: <5733617B.1040309@gmail.com> <574EBBE0.4010202@gmail.com> Message-ID: <981936568739f74a5ea8b3daa4ddc7ab@mail.marples.name> X-Sender: roy@marples.name User-Agent: Roundcube Webmail/1.1.2 Archived-At: Cc: dhcwg Subject: Re: [dhcwg] DHCP hackathon in Berlin? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 11:29:33 -0000 Hi On 2016-06-01 11:41, Tomek Mrugalski wrote: > We're lacking client support, so the plan is > to hack a client during the hackathon. It seems the easiest open source > client to modify is Dibbler, but we're also looking at the ISC DHCP > client modification. No love for dhcpcd for client testing? http://roy.marples.name/projects/dhcpcd While I think it should already support the basics of RFC7550 I haven't extensively tested it against every bullet point. It should also support secure DHCPv6 from RFC3315 as well. I'm quite new to this list and am unaware if there are any newer RFC documents in the works to change secure transactions over RFC3315. Roy From nobody Wed Jun 1 05:26:31 2016 Return-Path: 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 B466B12D1A7 for ; Wed, 1 Jun 2016 05:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26WmfCHOeNWw for ; Wed, 1 Jun 2016 05:26:27 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CD9412D1A1 for ; Wed, 1 Jun 2016 05:26:27 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id b73so11623343lfb.3 for ; Wed, 01 Jun 2016 05:26:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=bE3Qd7k7kVSrb4L/feJjNnLfq3MAGb0t6km22dQHTEQ=; b=hUwMTwlCWTJShrwverE3+QWjL7C51Lqvj2UTNElPGYE9sxSfSUhaq/SW/YvqqneDka Qpe8mT/8p+kJCjs0J59eeCvKIgg7XWIJsYBHL1rVcrm2C9TAFQGnpDuzc9EaDqA4MLbH r7RHE31MwhuN0D8XlTy88B+xaFfKxnUIaLaBAJDfxIBGxE3leACQoRF8dQRllJ5zb/jc AKJALqH6TJH8cwpKvB1piYd76+AIz+uWVPxEV3BYrBKOuR/cgQEskORAxXoEESQKwkm4 L/FQTDIjK/ZSiQj89Ge8axoYSOrFD0NASEX/pVGsJu8Ph8Rgiw6gKYs+EHMRm0+d/9BZ lBow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=bE3Qd7k7kVSrb4L/feJjNnLfq3MAGb0t6km22dQHTEQ=; b=UF1lrLcxD4iu2pgu9MarkFFmRn/D8VUEbaZgVLYySloxid3wV4v59qeSJP4S73uyH3 3rVBsy9NLjZoy678/1NcAc1gvBiEHefdlAZTm9AHhODOU5+xx/u6vwa5try71PFFvU+s Bfm4ikKv09DNKaJ/PpGarcvDn4B0/2sKtvRMu/nhAoGylFWFLlyk6721rSou9ciCYZjf OhK3K9XHez3dXyvyso7fLUPG25f0fiYOgIq6k8dR+Wlc9XWHPZgP3uLgDS6a+IM5FIEQ MP283Yh6on85JBo1hs+joeQbmHoMNiHGJGb2KFYlYyyRGp/INEjqLUGIYOadYXevblh3 i7mQ== X-Gm-Message-State: ALyK8tLLwKM9q+i876JItKrZYtyfBK5UoNX8Bw6QOISCHPkxU8mA36FzLA+Tn/LpuuKark7BFab1L5gX7Upe7A== MIME-Version: 1.0 X-Received: by 10.25.144.207 with SMTP id s198mr1326142lfd.131.1464783985298; Wed, 01 Jun 2016 05:26:25 -0700 (PDT) Received: by 10.25.153.135 with HTTP; Wed, 1 Jun 2016 05:26:25 -0700 (PDT) Received: by 10.25.153.135 with HTTP; Wed, 1 Jun 2016 05:26:25 -0700 (PDT) In-Reply-To: <981936568739f74a5ea8b3daa4ddc7ab@mail.marples.name> References: <5733617B.1040309@gmail.com> <574EBBE0.4010202@gmail.com> <981936568739f74a5ea8b3daa4ddc7ab@mail.marples.name> Date: Wed, 1 Jun 2016 08:26:25 -0400 Message-ID: From: Ted Lemon To: Roy Marples Content-Type: multipart/alternative; boundary=001a11401eb41de66005343699a2 Archived-At: Cc: dhcwg Subject: Re: [dhcwg] DHCP hackathon in Berlin? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 12:26:30 -0000 --001a11401eb41de66005343699a2 Content-Type: text/plain; charset=UTF-8 https://datatracker.ietf.org/doc/draft-ietf-dhc-sedhcpv6/ Are you coming to Berlin? On Jun 1, 2016 6:29 AM, "Roy Marples" wrote: > Hi > > On 2016-06-01 11:41, Tomek Mrugalski wrote: > >> We're lacking client support, so the plan is >> to hack a client during the hackathon. It seems the easiest open source >> client to modify is Dibbler, but we're also looking at the ISC DHCP >> client modification. >> > > No love for dhcpcd for client testing? > http://roy.marples.name/projects/dhcpcd > > While I think it should already support the basics of RFC7550 I haven't > extensively tested it against every bullet point. > It should also support secure DHCPv6 from RFC3315 as well. I'm quite new > to this list and am unaware if there are any newer RFC documents in the > works to change secure transactions over RFC3315. > > Roy > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > --001a11401eb41de66005343699a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

https://datatracker.ietf.org/doc/draft-ietf-dhc-sedhcpv6/

Are you coming to Berlin?

On Jun 1, 2016 6:29 AM, "Roy Marples" = <roy@marples.name> wrote:
Hi

On 2016-06-01 11:41, Tomek Mrugalski wrote:
We're lacking client support, so the plan is
to hack a client during the hackathon. It seems the easiest open source
client to modify is Dibbler, but we're also looking at the ISC DHCP
client modification.

No love for dhcpcd for client testing?
http://roy.marples.name/projects/dhcpcd

While I think it should already support the basics of RFC7550 I haven't= extensively tested it against every bullet point.
It should also support secure DHCPv6 from RFC3315 as well. I'm quite ne= w to this list and am unaware if there are any newer RFC documents in the w= orks to change secure transactions over RFC3315.

Roy

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg
--001a11401eb41de66005343699a2-- From nobody Wed Jun 1 05:37:46 2016 Return-Path: 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 D38A212B007 for ; Wed, 1 Jun 2016 05:37:44 -0700 (PDT) X-Quarantine-ID: <8T444bUGl4RD> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "To" X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8T444bUGl4RD for ; Wed, 1 Jun 2016 05:37:42 -0700 (PDT) Received: from mail.marples.name (uberserver.marples.name [77.75.106.61]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D50812D1AB for ; Wed, 1 Jun 2016 05:37:41 -0700 (PDT) Received: by mail.marples.name (Postfix, from userid 1010) id E8958A15A0; Wed, 1 Jun 2016 13:37:38 +0100 (BST) To: Ted Lemon X-PHP-Originating-Script: 0:rcube.php MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 01 Jun 2016 13:37:38 +0100 From: Roy Marples To: Ted Lemon In-Reply-To: References: <5733617B.1040309@gmail.com> <574EBBE0.4010202@gmail.com> <981936568739f74a5ea8b3daa4ddc7ab@mail.marples.name> Message-ID: <4fb89da4a329293e925e24941cb2ccf3@mail.marples.name> X-Sender: roy@marples.name User-Agent: Roundcube Webmail/1.1.2 Archived-At: Cc: dhcwg Subject: Re: [dhcwg] DHCP hackathon in Berlin? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 12:37:45 -0000 On 2016-06-01 13:26, Ted Lemon wrote: > https://datatracker.ietf.org/doc/draft-ietf-dhc-sedhcpv6/ [3] Thanks > > Are you coming to Berlin? Sadly no, I have a prior engagement I cannot miss. Roy From nobody Wed Jun 1 05:38:06 2016 Return-Path: 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 3BC5712D1B7 for ; Wed, 1 Jun 2016 05:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOUIdn4cRvgy for ; Wed, 1 Jun 2016 05:38:03 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 149BC12D1AB for ; Wed, 1 Jun 2016 05:38:03 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id b73so11835822lfb.3 for ; Wed, 01 Jun 2016 05:38:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=P2BaQXO3b3EM1UVYBch+QNFSXozuc0z1KacN5+R3tkA=; b=QHruNHP04kcPSY9PUsxdb0Mqn8BbqNc7xJUtftSRX1ocmDUJnv+34XVmef+67UBRZT Vy/LqpbgGgLZ1iQYGmIj1riYOIbVqexKEQPy4XABd8y7LfPrJWbNE0g6EBOuKkXcYw1L Wrk7JYooLT8y1osuTetPxK3rnUtzCF9JSs2YuEzuwUg2/Q4lIrDw49mfoyZQbbXKlJBt QGOW7Ch8V6iYcVitk7omZ5JIq/j0OHzKlh+EZPdz6ZzURWX46PjOVKbu5c/uPrW/V2Z0 nSN8PfAuq4sFP1jbpmT1emvKgJUPl+T0m6hf4u/g7vmM9+Jlv3VqdgSwf4vlGGQ8D4uE vxwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=P2BaQXO3b3EM1UVYBch+QNFSXozuc0z1KacN5+R3tkA=; b=in2NminibixWHvpVNnkX25jLfMAyszmJ0LxyCrkXGvd4dLPXhDG20EDR9vfdaz+ejs Zi3uhJz2tu8btk3x8+LV6q2GgjSFZKTOIeDlgWssqWVSmKEQtBBCvtxtyC3NxmlOp9i4 9xoWwiIz3EoXogoHGif7JAp2cU/68XH0qMc2oK2uJkkTg+9plEzsFh6fGl8ipS6JjlVN STINeDHR4tSVsm7NhWwq+kv882MxwAtrTWzR1NF7qhPd/Fb91xkvgxh/U0heYsugTPBj ICgbqYY5YwRv++SHFA5gwOSPoG8NkY3aeNVt7I0oiOlby5do3sV7Q7HuElvYfn2jPxjP xmgg== X-Gm-Message-State: ALyK8tKE1VcK033AL7jTanQLzZFhTSaOhcYTbmCq8cczFWpytePI668a/K2i1Z27UgA2Bg== X-Received: by 10.25.85.12 with SMTP id j12mr1669940lfb.47.1464784681214; Wed, 01 Jun 2016 05:38:01 -0700 (PDT) Received: from [10.0.0.100] (088156132194.dynamic-ww-04.vectranet.pl. [88.156.132.194]) by smtp.googlemail.com with ESMTPSA id t11sm5798573lfd.20.2016.06.01.05.37.59 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Jun 2016 05:38:00 -0700 (PDT) To: Roy Marples References: <5733617B.1040309@gmail.com> <574EBBE0.4010202@gmail.com> <981936568739f74a5ea8b3daa4ddc7ab@mail.marples.name> From: Tomek Mrugalski X-Enigmail-Draft-Status: N1110 Message-ID: <574ED726.9020601@gmail.com> Date: Wed, 1 Jun 2016 14:37:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <981936568739f74a5ea8b3daa4ddc7ab@mail.marples.name> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: dhcwg Subject: Re: [dhcwg] DHCP hackathon in Berlin? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 12:38:05 -0000 On 01.06.2016 13:29, Roy Marples wrote: > No love for dhcpcd for client testing? > http://roy.marples.name/projects/dhcpcd We'd certainly like to test this implementation, but we need someone who's familiar with it enough to run it and fix any issues found. > While I think it should already support the basics of RFC7550 I > haven't extensively tested it against every bullet point. That's the idea here. We want to test whether we missed anything, what's the most reasonable behavior in odd corner cases etc. > It should also support secure DHCPv6 from RFC3315 as well. I would be cautious with using "secure" and "3315" in the same sentence. :) > I'm quite new to this list and am unaware if there are any newer RFC > documents in the works to change secure transactions over RFC3315. Yes, there are. First, there's secure DHCPv6 draft that's being currently actively worked on draft-ietf-dhc-sedhcpv6-12 [1]. It's a significant step forward as compared to what 3315 offered. Second, there's RFC3315bis work [2] in progress that hopes to clean up, clarify and fix lots of issues in DHCPv6. The current draft is dhc-rfc3315bis-04. There's a whole separate mailing list and issue tracker [3] dedicated to it. Authors are planning to publish -05 version in the next couple days. If you're interested in what has changed, we maintain a changelog (see Appendix A). It may not be exhaustive, though. One of the changes in 3315bis is the Delayed Authentication mechanism being deprecated. The mechanism was underspecified, difficult to deploy, had significant operational burden and its actual deployment in production networks was extremely limited at best. As there's a new alternative (sedhcpv6), we decided to get rid of the delayed auth. Both of those drafts are hoping to go through WGLC (working group last call) in the next couple months. Feel free to review them and post your comments here. 1. https://tools.ietf.org/html/draft-ietf-dhc-sedhcpv6-12 2. https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-04 3. https://wiki.tools.ietf.org/group/dhcpv6bis/ Tomek From nobody Wed Jun 1 09:47:54 2016 Return-Path: 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 A207712B034 for ; Wed, 1 Jun 2016 09:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8CB9Yp9H74v for ; Wed, 1 Jun 2016 09:47:51 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50DC512B00D for ; Wed, 1 Jun 2016 09:47:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13008; q=dns/txt; s=iport; t=1464799665; x=1466009265; h=from:to:subject:date:message-id:mime-version; bh=oYzjKrx3AxNkhu+ioU3TD94fR33/PaHyrArAn18co84=; b=P+6Iz/FQivAN9tQAjZIeM7kbRfeFcYXCGqSmZuDlJFPROlraODE2KDBo YQ1bfRRhr2IAa4+mziZ8YXcEPUKTvHP3AEAvUvNKCIurv1ItrpR/uTX8z BFf1hgMTc079z4k3rhXPWImoOnlWWqUSBp7clRsooDboXqSeUP+9AzvRO 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BFAgDKEE9X/40NJK1dgnBNVn0GqXmLH?= =?us-ascii?q?4Jqgg8BDYF6hhECgTI4FAEBAQEBAQFlJ4RFAQEFLV4BGQQBASg5FAkJAQQTCIg?= =?us-ascii?q?noCWhJQEBAQEBAQQBAQEBAQEBAR+KdIR2hSQFmDcBgS6MaoFwhE+IZI9LAR4BA?= =?us-ascii?q?UKDbW6JOH8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,402,1459814400"; d="scan'208,217";a="279626002" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Jun 2016 16:47:44 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u51GliVc020010 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 1 Jun 2016 16:47:44 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 1 Jun 2016 11:47:43 -0500 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1104.009; Wed, 1 Jun 2016 11:47:43 -0500 From: "Bernie Volz (volz)" To: "'dhcwg@ietf.org'" Thread-Topic: Results of WGLC on draft-ietf-dhc-dhcpv6-failover-protocol-01 Thread-Index: AdG8ILaAmzrgAgFrQdOQbOoMLXNgRw== Date: Wed, 1 Jun 2016 16:47:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.1.195] Content-Type: multipart/alternative; boundary="_000_c6a02d7a00cb4f1faa22914a3cfd977fXCHALN003ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [dhcwg] Results of WGLC on draft-ietf-dhc-dhcpv6-failover-protocol-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 16:47:53 -0000 --_000_c6a02d7a00cb4f1faa22914a3cfd977fXCHALN003ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The results are a bit tardy ... sorry about that. But sadly (as I need to make the call as Tomek is a co-author), I don't thi= nk we're ready to advance this document. We will try again and hopefully ge= t some more participation. Thanks to Tomek for posting thorough review comments. Tomek has requested time in Berlin to discuss this work. I propose that based on the outcome of the Berlin discussion, we may start = another WGLC after that. - Bernie From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz) Sent: Sunday, May 15, 2016 8:52 AM To: 'dhcwg@ietf.org' Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-failover-protocol-01 - R= espond by May 22, 2016 Hi. This is a reminder about this WGLC. - Tomek & Bernie From: Bernie Volz (volz) Sent: Thursday, April 28, 2016 3:25 PM To: dhcwg@ietf.org Subject: WGLC on draft-ietf-dhc-dhcpv6-failover-protocol-01 - Respond by Ma= y 22, 2016 Hi all, This message starts the DHC Working Group Last Call to advance draft-ietf-d= hc-dhcpv6-failover-protocol-01, DHCPv6 Failover Protocol. This document's i= ntended status is Proposed Standard. At present, there is no IPR file again= st this document. Please send your comments by May 22, 2016. If you do not feel this documen= t should advance, please state your reasons why. We will need several serious reviews of this document for it to pass WGLC. Bernie Volz is the assigned shepherd (Tomek is a co-author). - Tomek & Bernie --_000_c6a02d7a00cb4f1faa22914a3cfd977fXCHALN003ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The results are a bit = tardy … sorry about that.

 

But sadly (as I need t= o make the call as Tomek is a co-author), I don’t think we’re r= eady to advance this document. We will try again and hopefully get some mor= e participation.

 

Thanks to Tomek for po= sting thorough review comments.

 

Tomek has requested ti= me in Berlin to discuss this work.

 

I propose that based o= n the outcome of the Berlin discussion, we may start another WGLC after tha= t.

 

-&nb= sp;         Bernie

 

From: dhcwg [mailto:dhcwg-bounces@ietf.org] <= b>On Behalf Of Bernie Volz (volz)
Sent: Sunday, May 15, 2016 8:52 AM
To: 'dhcwg@ietf.org' <dhcwg@ietf.org>
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-failover-protocol= -01 - Respond by May 22, 2016

 

Hi. This is a reminder= about this WGLC.

 

-&nb= sp;         Tomek & Be= rnie

 

From: Bernie Volz (volz)
Sent: Thursday, April 28, 2016 3:25 PM
To: dhcwg@ietf.org
Subject: WGLC on draft-ietf-dhc-dhcpv6-failover-protocol-01 - Respon= d by May 22, 2016

 

Hi all,

 

This message starts the DHC Working Group Last Ca= ll to advance draft-ietf-dhc-dhcpv6-failover-protocol-01, DHCPv6 Failover P= rotocol. This document’s intended status is Proposed Standard. At pre= sent, there is no IPR file against this document.

 

Please send your comments by May 22, 2016. If you= do not feel this  document should advance, please state your reasons = why.

 

We will need several serious reviews of this docu= ment for it to pass WGLC.

 

Bernie Volz is the assigned shepherd (Tomek is a = co-author).

 

- Tomek & Bernie

 

--_000_c6a02d7a00cb4f1faa22914a3cfd977fXCHALN003ciscocom_-- From nobody Tue Jun 14 23:38:06 2016 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3805F12B02E; Tue, 14 Jun 2016 23:38:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.22.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160615063802.31649.38151.idtracker@ietfa.amsl.com> Date: Tue, 14 Jun 2016 23:38:02 -0700 Archived-At: Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-yang-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 06:38:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration of the IETF. Title : YANG Data Model for DHCPv6 Configuration Authors : Yong Cui Hao Wang Linhui Sun Ted Lemon Ian Farrer Sladjana Zoric Filename : draft-ietf-dhc-dhcpv6-yang-02.txt Pages : 91 Date : 2016-06-14 Abstract: This document describes a YANG data model [RFC6020] for the configuration and management of DHCPv6 servers, relays and clients. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-yang/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-yang-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv6-yang-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 15 07:57:18 2016 Return-Path: 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 2AF9412D836 for ; Wed, 15 Jun 2016 07:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oBT3ElR2r04G for ; Wed, 15 Jun 2016 07:57:16 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12E6912D85E for ; Wed, 15 Jun 2016 07:57:13 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id s186so21050985qkc.1 for ; Wed, 15 Jun 2016 07:57:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=wydMpbL8X1Hssv0yovEhcJU4zawioXY7tjFWqDhqiIc=; b=UuaTorF6vfN4iPsNtcrKeNA3ceKLXoqO+sIkep4B95CgaPYA96sNF8fNiBrCBS/G9T Wrkld2uGPlURwmuxQZjwzT6eaP/J9t5SOHhIR80PsTZmdqRXvL/0x9kpIDrBkDWC7Z0S 25b8NpHh0NFghrpmS96EKLKmOPpzQzHNbrUHAbBYa8uCbyIWFWQqKvrpWrOYckMiBTYc u5Pokd7a4uA0bA79xMOL0GihSY88EhfjvS+swR78aHyQkEE4kCtkmwQmRzD6zip1KZzv qMSssnRMOaW47S26Wblxgh+gS6+3T6AoPb7+2pJFHZmt1OYzVNrx/XofLDCKa1DgZEsY RCSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=wydMpbL8X1Hssv0yovEhcJU4zawioXY7tjFWqDhqiIc=; b=EEYz3n1dVoHiVlVSCmYAe75IItz/oUqIJHAVc7x/4SIbiWgTVyQtkAJHJb8w8d9Iqa o1VHcyQPfxUW9JYfyGahngUoS7C6zfbn2oS2p/bjYGCjbUXpxeGcpA8PyB49w/P27zzu yylwKACyBQK2B/tuWDUtyaWula6qdIkOfrNGvXUP1/7YBcWOS0HbuGtOk+Ozukwj20Z1 wH+t9o3/JpSYha81ZrQYwl8Betm5aA+706YC6myxCNEnzK5ig9eOorcqYBCn8K7nIR4t WxdVztJOTs/Tvc0B/s9fzD4jDXLs1hs7iyw225kFBM3ok6VnlQhc8raBPGtRbL8RB/I/ jdLA== X-Gm-Message-State: ALyK8tI1IrHbAg/GpqAfv15TvxVcFf2PKK5Xlf/NX6z82qhOfqbZY5JRC+djteIqRMSb79xUWsgRhwuvoz4f8Q== X-Received: by 10.200.37.98 with SMTP id 31mr26058863qtn.82.1466002632112; Wed, 15 Jun 2016 07:57:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.44.65 with HTTP; Wed, 15 Jun 2016 07:57:11 -0700 (PDT) From: Lishan Li Date: Wed, 15 Jun 2016 22:57:11 +0800 Message-ID: To: dhcwg Content-Type: multipart/alternative; boundary=001a11403cdc20b9cc05355256f7 Archived-At: Subject: [dhcwg] Open Issues for Secure DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 14:57:17 -0000 --001a11403cdc20b9cc05355256f7 Content-Type: text/plain; charset=UTF-8 Dear all, After the discussion with authors and Stephen Farrell, we have the following problems not sure and want to get further comments from WG. 1. For the applicability part, after the discussion with Jinmei, we want to made the following changes: (1). Add some opportunistic security related description in applicability part; (2). Support the following two modes of operations: 1. Authentication+Encryption with cert/public key validation; 2. (if #1 isn't possible) Encryption-only without cert/public key validation. The current version only includes "Authentication+Encryption" mode. We should add the "Encryption-only" mode. 2. According to Stephen's comment, in some scenario, such as hotspot or home network, there is not need to verify the client's identity. If someone is using DHCPv6 to allocate addresses to server boxen in a data centre, then the client authentication is needed. So in order to have the balance right there, client authentication is optional. 3. The Reply message with an error status code, is not encrypted. So the Reply message may contain the client identifier option, then the client's privacy information may be disclosed. So the solution is that: The Reply message can be encrypted to avoid privacy information disclosure. Could you please give us some comments and guidance? Thanks in advance. Best Regards, Lishan --001a11403cdc20b9cc05355256f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,

After the discussi= on with authors and Stephen Farrell, we have the following problems not sur= e and want to get further comments from WG.

1. For= the applicability part, after the discussion with Jinmei, we want to made = the following changes:
(1). Add some opportunistic security relat= ed description in applicability part;
(2). Support the following = two modes of operations: 1. Authentication+Encryption with cert/public key = validation; 2. (if #1 isn't possible) Encryption-only without cert/publ= ic key validation.
=C2=A0 =C2=A0The current version only includes= "Authentication+Encryption" mode. We should add the "Encryp= tion-only" mode.

2. According to Stephen'= s comment, in some scenario, such as hotspot or home network, there is not = need to verify the client's identity. If someone is using DHCPv6 to all= ocate addresses to server boxen in a data centre, then the client authentic= ation is needed.=C2=A0
So in order to have the balance right ther= e, client authentication is optional.

3. The Reply= message with an error status code, is not encrypted. So the Reply message = may contain the client identifier option, then the client's privacy inf= ormation may be disclosed.=C2=A0
So the solution is that: The Rep= ly message can be encrypted to avoid privacy information disclosure.
<= div>
Could you please give us some comments and guidance? Tha= nks in advance.=C2=A0


Best Regards,=
Lishan
--001a11403cdc20b9cc05355256f7-- From nobody Wed Jun 15 10:04:06 2016 Return-Path: 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 3648E12D97E for ; Wed, 15 Jun 2016 10:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSFfleweBYRx for ; Wed, 15 Jun 2016 10:04:04 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89F8912D80D for ; Wed, 15 Jun 2016 10:04:04 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id s186so28033301qkc.1 for ; Wed, 15 Jun 2016 10:04:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=tVpIq3+IWNqHrxrFN5rto1yvrvwc3ioqL3Yc9OPOJr8=; b=LpHGZgf8x1neI/3xzX0YFRv0w9hn7FXP95U1uU9R4EBJY7p+2SFwFhVrpgHT8FzI82 +ZAFij1hcVFfcCQmGqMpHD8DMFmq/BhURxqJod9Bl6cv8LbJ3l5v0qOu60f59+jKOryO yMoEDgVgWxkh7yZpj2gWqbqaRXUqkdg7O/20n7dLIiE/orpmEXO61pOttyEZvFZZ4F5k /ysyqUpnmlj+YOGgR+j7BPhtCZ0Q+Yvbs6EPGI3oOYgooEb8PfxNxiXcMrOqbSPQkcil E8PUH2z8utxwt+h++mdbOONpYVsKPSHR1o2nH9NZdbIp0grDFEwJghYKZwmJs/3n0L5H nccQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=tVpIq3+IWNqHrxrFN5rto1yvrvwc3ioqL3Yc9OPOJr8=; b=cUJ9DdYIRi9WUdUKlhxHUVeUZuUk499/UL9Wi9Tb7rVlAgo1IyV7xwhowDozlX4DNv 3qvF12vJLNNt4stz5eNZV46QaxtOGpta5I7mlg9bUXrCKKWYrtv0N3EDfkwFWzxGH8uI tGdN6I6hnFR19+dMJFGVhzairGvsPOxeJJMQcTPQD/Nhic4lmPshJ5RfJeNv1Qx4aMsn E9T5Oq3gYOfuIBInk25yGb168VYb1yTjwaoqktz6WRzOTXjKlCRpywUas+7gFHYAzFXr pNyEbtfiyjW8YIDPRa3kmdW4fsW6bd/QxiFy91u5Nol/qqfwcZN8xY3Co+VT3xwYxk0J RMDQ== X-Gm-Message-State: ALyK8tIzLEHV3z37AVc+1BhFcOtAoUGeddLo60R2acCGy7PcvuBXR2z/NXaO22KrhLE9vluXGcdEIyPOdijoZA== X-Received: by 10.200.49.73 with SMTP id h9mr17488170qtb.60.1466010243679; Wed, 15 Jun 2016 10:04:03 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.33.166 with HTTP; Wed, 15 Jun 2016 10:04:03 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Wed, 15 Jun 2016 10:04:03 -0700 X-Google-Sender-Auth: e3TU-vHNusRYoBe2r0whbEQ-d6U Message-ID: To: Lishan Li Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: dhcwg Subject: Re: [dhcwg] Open Issues for Secure DHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 17:04:06 -0000 At Wed, 15 Jun 2016 22:57:11 +0800, Lishan Li wrote: > After the discussion with authors and Stephen Farrell, we have the > following problems not sure and want to get further comments from WG. > > 1. For the applicability part, after the discussion with Jinmei, we want to > made the following changes: > (1). Add some opportunistic security related description in applicability > part; > (2). Support the following two modes of operations: 1. > Authentication+Encryption with cert/public key validation; 2. (if #1 isn't > possible) Encryption-only without cert/public key validation. > The current version only includes "Authentication+Encryption" mode. We > should add the "Encryption-only" mode. I think some more background explanation is needed here...this is simply based on my *understanding* (not opinion) of what we agreed at the Yokohama IETF meeting. I thought our consensus was to support the above two modes, while the current sedhcpv6 draft only talks about Authentication+Encryption. I guess there is some possible confusion on what "TOFU is out of scope for now" means (see agenda #4 of https://www.ietf.org/proceedings/94/minutes/minutes-94-dhc). My understanding is that it was only about authentication and the consensus was to add support for "encryption only". Am I understanding it correctly? BTW, if we make this change, I don't think we can simply update the applicability section - it will lead to quite substantial overhaul for the entire document. > 3. The Reply message with an error status code, is not encrypted. So the > Reply message may contain the client identifier option, then the client's > privacy information may be disclosed. > So the solution is that: The Reply message can be encrypted to avoid > privacy information disclosure. This is not so trivial. At least it will be tricky in case of 'AlgorithmNotSupported' - how can the server encrypt it when it doesn't support the encryption algorithm? -- JINMEI, Tatuya From nobody Wed Jun 15 15:21:30 2016 Return-Path: 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 BDBFC12D9E8; Wed, 15 Jun 2016 15:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.328 X-Spam-Level: X-Spam-Status: No, score=-108.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2aEWg1ZL4JY0; Wed, 15 Jun 2016 15:21:27 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C54912D9BD; Wed, 15 Jun 2016 15:21:27 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 2CE17B812AC; Wed, 15 Jun 2016 15:21:27 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20160615222127.2CE17B812AC@rfc-editor.org> Date: Wed, 15 Jun 2016 15:21:27 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, dhcwg@ietf.org, rfc-editor@rfc-editor.org Subject: [dhcwg] RFC 7839 on Access-Network-Identifier Option in DHCP X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 22:21:29 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7839 Title: Access-Network-Identifier Option in DHCP Author: S. Bhandari, S. Gundavelli, M. Grayson, B. Volz, J. Korhonen Status: Standards Track Stream: IETF Date: June 2016 Mailbox: shwethab@cisco.com, sgundave@cisco.com, mgrayson@cisco.com, volz@cisco.com, jouni.nospam@gmail.com Pages: 20 Characters: 42942 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dhc-access-network-identifier-13.txt URL: https://www.rfc-editor.org/info/rfc7839 DOI: http://dx.doi.org/10.17487/RFC7839 This document specifies the format and mechanism that is to be used for encoding Access-Network Identifiers in DHCPv4 and DHCPv6 messages by defining new Access-Network-Identifier options and sub-options. This document is a product of the Dynamic Host Configuration Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Jun 16 15:41:40 2016 Return-Path: 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 1B04B12DD1F for ; Thu, 16 Jun 2016 15:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.728 X-Spam-Level: X-Spam-Status: No, score=-5.728 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUukbmynkG8z for ; Thu, 16 Jun 2016 15:41:37 -0700 (PDT) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15DF212DC16 for ; Thu, 16 Jun 2016 15:41:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1466116896; x=2330030496; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=C8CAl9/4XlUoj27j6+XliWNDCje7IfaI8sEIKobL9rw=; b=dwiOaebsPkWaG+Gy2CGirjVaTI05PoykFNxrffqga0qdXpNvF/DeGU7isA447GYH MprFU3LcbEVjR51Qy7HVsajHFOiOjUtQLFBuEO0zquYUTRsLgU3tJOdb+hcIxVu8 f1UKSvHWdVS0MiFndQuU6XdK4IiGkSnd/66mcQ1jTb9XqlUBoq8poIGzsAuD3dmp BhzY8P0f648jshZXrNavsB99+ej7QqJbJ+K7XDwLohoJddVb8MrZ4CSYX9wMaP/S yJ17uW38GcFvGynDwa/6RqcbiTCvMSPXId51apg2cp0sBEv3EoZbYXr9c10l77N5 N2+Xp64yzmKbzIhzMY1ZFg==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 77.FA.19292.02B23675; Thu, 16 Jun 2016 15:41:36 -0700 (PDT) X-AuditID: 11973e11-f79356d000004b5c-0a-57632b20e83b Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id 30.45.29065.02B23675; Thu, 16 Jun 2016 15:41:36 -0700 (PDT) Received: from singda.apple.com (singda.apple.com [17.212.152.248]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0O8V0036WZ1CM120@nwk-mmpp-sz09.apple.com> for dhcwg@ietf.org; Thu, 16 Jun 2016 15:41:36 -0700 (PDT) Sender: singer@apple.com From: David Singer Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Message-id: <64A0CA2D-C8C1-415B-A532-338E4B62DF14@apple.com> Date: Thu, 16 Jun 2016 15:41:36 -0700 To: dhcwg@ietf.org MIME-version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUi2FAYoaugnRxucOi5mcXdjhZGB0aPJUt+ MgUwRnHZpKTmZJalFunbJXBlnN9+iLHgC3PF25637A2MU5i7GDk5JARMJN6+mwRli0lcuLee DcQWEtjLKHFxVS5MzaH7/4BquIDiy5gkLrV3QzkrmST+vjjMCFIlLCAh8fHjZBYQm01AVeLB nGNAcQ4OZgF1iSlTwAYxC2hLPHl3gRWi3ELi5c/9YIt5BWwkLp5/AWazALXOmn+AHcQWERCS 2HL8HRNEjZ7E5KMNbBAHyUo8ObmIBeQGCYGrrBIn+88yT2AUnIWwbhaSdbOQtC9gZF7FKJSb mJmjm5lnpJdYUJCTqpecn7uJERSU0+0EdzAeX2V1iFGAg1GJh3eFaHK4EGtiWXFl7iFGaQ4W JXHeN9MSw4UE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwlh03Pjv7+pLmhv7KT81HCj7rbXmT VG2a7n2qKOrLYcMvrt0H56dkxhRnWR6SvtMht2z6jqfie44fdbDkcjd6VP1KIHqxOvcfM8m5 E5Y32z/R1VReyb3m8YP40O06Hgy/qpUdfkv77VP2TRavzjCM073gXHLSY1OV+rkrHlfadQrD +u44VIsqsRRnJBpqMRcVJwIA9rpX9isCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphluLIzCtJLcpLzFFi42IRbCgO0FXQTg43WL3NxOJuRwujA6PHkiU/ mQIYo7hsUlJzMstSi/TtErgyzm8/xFjwhbnibc9b9gbGKcxdjJwcEgImEofu/4OyxSQu3FvP 1sXIxSEksIxJ4lJ7NzOEs5JJ4u+Lw4wgVcICEhIfP05mAbHZBFQlHsw5BhTn4GAWUJeYMiUX JMwsoC3x5N0FVohyC4mXP/eDLeAVsJG4eP4FmM0C1Dpr/gF2EFtEQEhiy/F3TBA1ehKTjzaw QRwkK/Hk5CKWCYx8sxA2zEKyYRaSjgWMzKsYBYpScxIrTfUSCwpyUvWS83M3MYLDqDBiB+P/ ZVaHGAU4GJV4eFeIJocLsSaWFVfmHmKU4GBWEuEtUAMK8aYkVlalFuXHF5XmpBYfYpTmYFES 553nnRguJJCeWJKanZpakFoEk2Xi4JRqYKwNu+LYLXt7m4Z77P3Lv+fsN1S7mbFwWk/zEo1L rL+NRUI8XHYF+vQ8m5q9UyuzzPlKc04ZV/Wu94/2esnOYhPTZn7Gdqj0ONvX8+/XeT/1iCyc /c1fd75WM/us0z/zV7UpLFM5Mf1lgPnyRfF+qhMWGyy24smoUJvEqKH54/q+61o/gnOmfVdi Kc5INNRiLipOBABcWLzXHwIAAA== Archived-At: Subject: [dhcwg] On RFC 7819, privacy considerations for DHCP... X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 22:41:38 -0000 =E2=80=A6has there been any discussion of the possibility of the client = asking for a specific allocation strategy, specifically, =E2=80=9Cplease = give me a DIFFERENT IP address from what you would normally give me=E2=80=9D= ? One of the easiest ways to fingerprint a system is by IP address; MAC = addresses are necessary local. If I=E2=80=99m trying to be private, it = might be nice to be able to change my address on request. David Singer Manager, Software Standards, Apple Inc. From nobody Sat Jun 18 06:36:17 2016 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C3E12D1B9; Sat, 18 Jun 2016 06:36:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160618133616.1100.15238.idtracker@ietfa.amsl.com> Date: Sat, 18 Jun 2016 06:36:16 -0700 Archived-At: Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-yang-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2016 13:36:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration of the IETF. Title : YANG Data Model for DHCPv6 Configuration Authors : Yong Cui Hao Wang Linhui Sun Ted Lemon Ian Farrer Sladjana Zoric Filename : draft-ietf-dhc-dhcpv6-yang-03.txt Pages : 91 Date : 2016-06-18 Abstract: This document describes a YANG data model [RFC6020] for the configuration and management of DHCPv6 servers, relays and clients. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-yang/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-yang-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv6-yang-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jun 19 17:58:14 2016 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 78A2C12D878; Sun, 19 Jun 2016 17:58:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160620005813.22460.69808.idtracker@ietfa.amsl.com> Date: Sun, 19 Jun 2016 17:58:13 -0700 Archived-At: Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 00:58:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration of the IETF. Title : DHCPv6 Prefix Length Hint Issues Authors : Yong Cui Tianxiang Li Cong Liu Filename : draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-02.txt Pages : 9 Date : 2016-06-19 Abstract: DHCPv6 Prefix Delegation [RFC3633] allows a requesting router to include a prefix-length hint value in the IA_PD option to indicate a preference for the size of the prefix to be delegated, but is unclear about how the requesting router and delegating router should act in different situations involving the prefix-length hint. This document provides a summary of the existing problems with the prefix-length hint and guidance on what the requesting router and delegating router could do in different situations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-prefix-length-hint-issue/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jun 19 18:21:13 2016 Return-Path: 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 6E03112D891 for ; Sun, 19 Jun 2016 18:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wB185_WQlNB1 for ; Sun, 19 Jun 2016 18:21:11 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E288712D888 for ; Sun, 19 Jun 2016 18:21:10 -0700 (PDT) Received: by mail-ob0-x22d.google.com with SMTP id ot10so5396860obb.2 for ; Sun, 19 Jun 2016 18:21:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=2MYBUx7LMn8MQ+mhJurNcObimiJCKZm4RjpPlwwvnjU=; b=b4jrv/c7FYy0OdB0/1CFGMghjuRgOq0tKmiAp0FinTL5hfT4HZs+5uFXgk4kKCiAyG lDOSTfDK5fxx92q662SSjZaNTA+eMbB4uyiXGsZEfQWzINEn7eaf74M7cUbuPl25gJcz kHMCVGbAbfD9GdBrP+G77yIaYPaQnMx3og+sAGHHoKzlmarC2tlWoqoINBjZkFCkEM9t TxTO8FlLYQRu5fk32W1XhoIkTF8PdNEq+lpY5MTXQEXMhUpcvKcBW228TFggEcvKCsfT IegE0TtQAvQ9eIwuhn7JCYgMrGVQqRJR8RwJdeegGlYbgTbN7dr/JoUj3dM9e0lUk/YJ fd/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=2MYBUx7LMn8MQ+mhJurNcObimiJCKZm4RjpPlwwvnjU=; b=Gt2fAH99jwsievhUiSOe1OqLI0egkKeakxh+ay94xJ8TUdJdNYk/8Ua55ZN69JAWId n+uASGRf7K8Fa+cPlosHm71EbHRd8JvM09RmXK829RYSDdrB9myTWK4qew8dVHszZZed +Tl0ETimsvcPThU/OsFe5qOC1rjvq1QMI5TW8pNg57p/xLKcrebATeHHKLpDulLgosW4 NAx4F4eoRJQp0L3H26/w3T5rFXxQhYmvaPEd1Hy7lOTv+vxYRbUBtKqsLOHEdqi2l9ch 4cZTyvjIns1fjgpgD041lY0wgME3OnNyarVmlRDPKEq+/KbU+KsGdGTzORFgyhV2lzmq rCZA== X-Gm-Message-State: ALyK8tJkcv6HUR+MynKIndfK52nPSMZ9pkVhE5GCj6JGCM0rscqYST1UV2o2MjDlHUIhZRebninjCw4MxUxdtg== X-Received: by 10.157.8.65 with SMTP id 59mr7900074oty.114.1466385670259; Sun, 19 Jun 2016 18:21:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.49.81 with HTTP; Sun, 19 Jun 2016 18:20:30 -0700 (PDT) From: tianxiang li Date: Mon, 20 Jun 2016 09:20:30 +0800 Message-ID: To: dhcwg Content-Type: multipart/alternative; boundary=94eb2c047bfafacb1d0535ab84eb Archived-At: Subject: [dhcwg] prefix-length hint issues for Standards Track? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 01:21:12 -0000 --94eb2c047bfafacb1d0535ab84eb Content-Type: text/plain; charset=UTF-8 Hi all, We've updated a new version of the prefix-length hint issues draft ( https://www.ietf.org/id/draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-02.txt ). We've edited some text in the solution sections and added normative language. Also we added some text in the introduction section to explain the motivation of the draft clearer, based on comments from the mailinglist. We hope to receive your comments, especially concerning the use of normative language, and whether it's okay for Standards Track. Thank you, Tianxiang --94eb2c047bfafacb1d0535ab84eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

We've updated a = new version of the prefix-length hint issues draft (https://= www.ietf.org/id/draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-02.txt).=

We've edited some text in the solution sectio= ns and added normative language. Also we added some text in the introductio= n section to explain the motivation of the draft clearer, based on comments= from the mailinglist.

We hope to receive your com= ments, especially concerning the use of normative language, and whether it&= #39;s okay for Standards Track.

Thank you,
Tianxiang
--94eb2c047bfafacb1d0535ab84eb-- From nobody Tue Jun 21 19:41:50 2016 Return-Path: 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 2175312DA3B for ; Tue, 21 Jun 2016 19:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ezSx9v5M9GzZ for ; Tue, 21 Jun 2016 19:41:46 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDC8012D886 for ; Tue, 21 Jun 2016 19:41:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2612; q=dns/txt; s=iport; t=1466563305; x=1467772905; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=J9hcseGeXl4SmO1NMv0fdLiV7yVlVTycmdJPmXbNE+Q=; b=DTwUexru6S9qD6B91yTP0gP905u4dNc40M9PwT74Lex8thF0bvF556ME H8zp75l5yB7avJW/dEMmzDOpgIRB1PdM60zL26r1GyqO/AKrDFgwBrbsy vUSunRCJhUq3S4e3OH671i3foswOeJi/VyQDQyMC5SKP5jteI1I6hwL+1 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/AQCN+mlX/5FdJa1dgz5WfQa6c4F6J?= =?us-ascii?q?IVzAhyBGzgUAQEBAQEBAWUcC4RMAQEBBCMRQw4EAgEZBAEBAwIjAwICAjAUAQg?= =?us-ascii?q?IAgQTCIgoDrIOkE0BAQEBAQEBAQEBAQEBAQEBAQEBAQEcgQGJc4QqLYJqgloFj?= =?us-ascii?q?XeLBQGGB4gegXBOhAWIZ495AR42g3BuAYlxfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,508,1459814400"; d="scan'208";a="120437296" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jun 2016 02:41:22 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u5M2fM9h000394 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 22 Jun 2016 02:41:22 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 21 Jun 2016 21:41:21 -0500 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1104.009; Tue, 21 Jun 2016 21:41:21 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: New Version Notification for draft-volz-dhc-relay-server-security-01.txt Thread-Index: AQHRzC9frybPqLaow0ulHGWoeGD91Z/0xnqQ Date: Wed, 22 Jun 2016 02:41:21 +0000 Message-ID: <0cbaeabc2e3a4d11badab9946c161734@XCH-ALN-003.cisco.com> References: <20160622023957.24990.34783.idtracker@ietfa.amsl.com> In-Reply-To: <20160622023957.24990.34783.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.244.58] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [dhcwg] New Version Notification for draft-volz-dhc-relay-server-security-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 02:41:49 -0000 SGk6DQoNCkkndmUgcG9zdGVkIGFuIHVwZGF0ZWQgdmVyc2lvbiB0aGF0IGFkZHJlc3NlcyBhIGZl dyBvZiB0aGUgaXNzdWVzIHJhaXNlZCBhZnRlciAwMCB3YXMgcHVibGlzaGVkLg0KDQotIEJlcm5p ZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGll dGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IFR1ZXNkYXks IEp1bmUgMjEsIDIwMTYgMTA6NDAgUE0NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtdm9sei1kaGMtcmVsYXktc2VydmVyLXNlY3VyaXR5LTAxLnR4dA0KDQoNCkEg bmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC12b2x6LWRoYy1yZWxheS1zZXJ2ZXItc2VjdXJpdHkt MDEudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEJlcm5pZSBWb2x6IGFu ZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC12b2x6LWRo Yy1yZWxheS1zZXJ2ZXItc2VjdXJpdHkNClJldmlzaW9uOgkwMQ0KVGl0bGU6CQlTZWN1cml0eSBv ZiBNZXNzYWdlcyBFeGNoYW5nZWQgQmV0d2VlbiBTZXJ2ZXJzIGFuZCBSZWxheSBBZ2VudHMNCkRv Y3VtZW50IGRhdGU6CTIwMTYtMDYtMjENCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQ YWdlczoJCTcNClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvZHJhZnQtdm9sei1kaGMtcmVsYXktc2VydmVyLXNlY3VyaXR5LTAxLnR4dA0KU3RhdHVz OiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXZvbHotZGhj LXJlbGF5LXNlcnZlci1zZWN1cml0eS8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtdm9sei1kaGMtcmVsYXktc2VydmVyLXNlY3VyaXR5LTAxDQpEaWZm OiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXZvbHot ZGhjLXJlbGF5LXNlcnZlci1zZWN1cml0eS0wMQ0KDQpBYnN0cmFjdDoNCiAgIFRoZSBEeW5hbWlj IEhvc3QgQ29uZmlndXJhdGlvbiBQcm90b2NvbCBmb3IgSVB2NCAoREhDUHY0KSBoYXMgbm8NCiAg IGd1aWRhbmNlIGZvciBob3cgdG8gc2VjdXJlIG1lc3NhZ2VzIGV4Y2hhbmdlZCBiZXR3ZWVuIHNl cnZlcnMgYW5kDQogICByZWxheSBhZ2VudHMuICBUaGUgRHluYW1pYyBIb3N0IENvbmZpZ3VyYXRp b24gUHJvdG9jb2wgZm9yIElQdjYNCiAgIChESENQdjYpIHN0YXRlcyB0aGF0IElQc2VjIHNob3Vs ZCBiZSB1c2VkIHRvIHNlY3VyZSBtZXNzYWdlcw0KICAgZXhjaGFuZ2VkIGJldHdlZW4gc2VydmVy cyBhbmQgcmVsYXkgYWdlbnRzLCBidXQgZG9lcyBub3QgcmVjb21tZW5kDQogICBlbmNyeXB0aW9u LiAgQW5kLCB3aXRoIHJlY2VudCBjb25jZXJucyBhYm91dCBwZXJ2YXNpdmUgbW9uaXRvcmluZyBp dA0KICAgaXMgYXBwcm9wcmlhdGUgdG8gcHJvdmlkZSByZWNvbW1lbmRhdGlvbnMgZm9yIERIQ1B2 NCBhbmQgYWxzbyBpbXByb3ZlDQogICB0aGUgcmVjb21tZW5kYXRpb25zIGZvciBESENQdjYuICBU aGlzIGRvY3VtZW50IHVwZGF0ZXMgUkZDMTU0MiBhbmQNCiAgIFJGQzMzMTUuDQoNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291 cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRt bGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0K DQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Wed Jun 22 11:39:32 2016 Return-Path: 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 B996412DAC8 for ; Wed, 22 Jun 2016 11:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifwIIAa2hKOk for ; Wed, 22 Jun 2016 11:39:27 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B47912D5C8 for ; Wed, 22 Jun 2016 11:39:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7486; q=dns/txt; s=iport; t=1466620766; x=1467830366; h=from:to:cc:subject:date:message-id:references: mime-version; bh=21YAQqUuVydA8LlYsPBz8Bh2lNhgdn32281IsYjfB/4=; b=bL1T7xiVCsaGjqE94qruDV5oqZhXuTEJBx2n2VmUFpd2jK+PYdPMiZNp GjwSVtgVCXakOHNDSgMukcPOWJZU2QTC+VybgAeO/38NX+C3IjrjZrn/J X5dCDGfTKZvzL63eNKHDoiEKPdMy59et70gyu7l1jB4cXp/Pt70RZjlM9 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BcAgAg2mpX/4cNJK1egz5WfQa1LYUBg?= =?us-ascii?q?XoihBqBWwKBMDgUAQEBAQEBAWUcC4RMAQEBBHcCEAIBGQMBAigHMhQHAggCBA4?= =?us-ascii?q?FiDAOxHIBAQEBAQEBAQEBAQEBAQEBAQEBAQEciB6CVoQqNhYIgm6CLwWNeIVSh?= =?us-ascii?q?TMBhgeIJYFpToQFh0yBG497AQ8PNoNwbgGJcX8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,509,1459814400"; d="scan'208,217";a="118044883" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Jun 2016 18:39:26 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u5MIdQYh012641 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 22 Jun 2016 18:39:26 GMT Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 22 Jun 2016 13:39:25 -0500 Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1104.009; Wed, 22 Jun 2016 13:39:25 -0500 From: "Naiming Shen (naiming)" To: "dhcwg@ietf.org" Thread-Topic: New Version Notification for draft-shen-dhc-client-port-00.txt Thread-Index: AQHRy33PGH3e2Zpl5U2t1woe7KbsDA== Date: Wed, 22 Jun 2016 18:39:25 +0000 Message-ID: <67E6B29E-91A7-4ED9-A2E7-4511C91EDF8F@cisco.com> References: <20160621052856.30178.16015.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.107.164] Content-Type: multipart/alternative; boundary="_000_67E6B29E91A74ED9A2E74511C91EDF8Fciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Enke Chen \(enkechen\)" Subject: [dhcwg] Fwd: New Version Notification for draft-shen-dhc-client-port-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 18:39:30 -0000 --_000_67E6B29E91A74ED9A2E74511C91EDF8Fciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We just submitted a new (individual submission) Internet draft dealing DHCP issues with large scale and distributed relay agents within a single node/r= outer/switch. Please review and comment. thanks. - Naiming Begin forwarded message: From: > Subject: New Version Notification for draft-shen-dhc-client-port-00.txt Date: June 20, 2016 at 10:28:56 PM PDT To: Naiming Shen >, Enke Chen <= enkechen@cisco.com> A new version of I-D, draft-shen-dhc-client-port-00.txt has been successfully submitted by Naiming Shen and posted to the IETF repository. Name: draft-shen-dhc-client-port Revision: 00 Title: Generalize Client UDP Port Number of DHCP Relay Document date: 2016-06-20 Group: Individual Submission Pages: 5 URL: https://www.ietf.org/internet-drafts/draft-shen-dhc-client-= port-00.txt Status: https://datatracker.ietf.org/doc/draft-shen-dhc-client-port= / Htmlized: https://tools.ietf.org/html/draft-shen-dhc-client-port-00 Abstract: This document extends the DHCP and DHCPv6 protocols for the UDP transport from server to client and allows the port to be any valid number on the DHCP relay system. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_67E6B29E91A74ED9A2E74511C91EDF8Fciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi,

We just submitted a new (individual submission) Internet dr= aft dealing DHCP
issues with large scale and distributed relay agents within= a single node/router/switch.

Please review and comment.

thanks.
- Naiming

Begin forwarded message:

From: <internet-drafts@ietf.org>
Subject: New Version Notification = for draft-shen-dhc-client-port-00.txt
Date: June 20, 2016 at 10:28:56 PM PDT
To: Naiming Shen <naiming@cisco.com>, Enke Chen <enkechen@cisco.com>


A new version of I-D, draft-shen-dhc-client-port-00.txt
has been successfully submitted by Naiming Shen and posted to the
IETF repository.

Name: draft-shen-dhc-c= lient-port
Revision: 0= 0
Title: Generalize Clie= nt UDP Port Number of DHCP Relay
Document date: 2016-06-20
Group: Individual Subm= ission
Pages: 5
URL:            https://www.ietf.org/internet-drafts/draft-shen-dhc-client-p= ort-00.txt
Status:         https://da= tatracker.ietf.org/doc/draft-shen-dhc-client-port/
Htmlized:       https://tools.ietf.org/= html/draft-shen-dhc-client-port-00


Abstract:
  This document extends the DHCP and DHCPv6 protocols for the UDP=
  transport from server to client and allows the port to be any v= alid
  number on the DHCP relay system.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--_000_67E6B29E91A74ED9A2E74511C91EDF8Fciscocom_-- From nobody Thu Jun 23 14:03:46 2016 Return-Path: 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 AC66312D73A for ; Thu, 23 Jun 2016 14:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxUuVSTNzsbr for ; Thu, 23 Jun 2016 14:03:42 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0103.outbound.protection.outlook.com [207.46.100.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B636812D662 for ; Thu, 23 Jun 2016 14:03:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yH6Vc6MmKiVMB8ovngNKzDDZhJeRoP6AbM/a1g37/ts=; b=L+N/zTGBkiLS+y0FBV/foSCIkrDVVezimAoIYzWyCzhDc82lKTq1yKjof2ma5L+gzh36jB9kQmGr8x4ySiemgKuhE+7W8G1IIkRO5wYIY1kn4zOw9la7yhSZkSjIHMo1tsyz5G+6z3lEroFpLb9h3HfhmWxPAXs+/EVSQDFpWng= Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0653.namprd03.prod.outlook.com (10.160.96.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.523.12; Thu, 23 Jun 2016 21:03:41 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0523.015; Thu, 23 Jun 2016 21:03:41 +0000 From: Christian Huitema To: David Singer , "dhcwg@ietf.org" Thread-Topic: [dhcwg] On RFC 7819, privacy considerations for DHCP... Thread-Index: AQHRyCBG3eGXvIS5ZUu/mMj9b7itlZ/3kdmw Date: Thu, 23 Jun 2016 21:03:41 +0000 Message-ID: References: <64A0CA2D-C8C1-415B-A532-338E4B62DF14@apple.com> In-Reply-To: <64A0CA2D-C8C1-415B-A532-338E4B62DF14@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=huitema@microsoft.com; x-originating-ip: [2001:4898:80e8:9::399] x-ms-office365-filtering-correlation-id: a3bf4b97-f0ba-4364-f19d-08d39ba9db26 x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0653; 6:t17IUdxluWHoXo/L9eezV8d1W5WIAr8MSk7VslSuz6CtBwFEDbgYly9lzZPjtmIgK9YD9WYojkNOqyv5AgM5RDjru/t1cn9jxBpgUZVjfzRYCY0i6Ja/m7zIr8gSwg4jooT/TVApoT61IAEIXgUqsVRCvUo53WJ+rD2zi5FRHU9TnVznLBlCoFR3cuL5q9drg8F2Ega2eENVYHNsHRVxdQv8rc07yILEj3nCMTmNHBO/4qgjWTDkycpvMiyG2IKHYFtS9KAYvgTC0yZ8bEXe41R2aJKUA9MfC+W5QZWEXj8rmNrRpItpPOvAciQySHSHETSArDte1Vh8ZX5ak4upxUYZodzMN0sweFc2sQ4NUY0=; 5:6agICZL8B2YWpP0kLq37WGb7lmakzJi38HKn6vr57akbWEIZMdR+fI7GAwfp8mC6Pn2iJkL2i82jWFU7pv3WiBbsLfJpmparlVQ9kalCoM5Sc9JqHCugX7cbQyYZ5seL37jb0Da4+MnONcQ5YH3MUA==; 24:PxHqD6Wg6mM7LFwxyEWxgnON+mc5wlORR2dTAPBa+lS6jIrGfpKbsNqHxS2RrxUuIPc7JgIGLQAaAQW2D47qnFWmboiYYWyb0yAHyoje0Fk=; 7:rlsVpDMEaFFMct0mpWJft2BKSBuyR7961pbdBIh/1SnmJdXRDcP2b28AsolGysvU/fc4eoI6EC5Q+kdRE48v09UG0kBTrGSSCUHX0a9nSGp66WX6KH8wh4RXFrKCsUPKzsQdJKaHsmBWAADDQBqF+xC/9EQOMktMJmZb7WwiAWaDsgiUUFUIFCwYIks/p3wTpByZ5CkXxmRxYpGYJSWeA/mr63UwdZsIH78XeGeDNsXgd8DSCS95NcOoyjI93LRTBdr2fOUpd1gQNAFvAkoG+/xgDUHlyTdC8M4ICRQasH0= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0653; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:DM2PR0301MB0653; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0653; x-forefront-prvs: 098291215C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(24454002)(377454003)(199003)(189002)(81156014)(86612001)(7736002)(106356001)(5001770100001)(101416001)(305945005)(106116001)(11100500001)(105586002)(87936001)(99286002)(77096005)(5005710100001)(3660700001)(76576001)(5002640100001)(8666005)(54356999)(10090500001)(8990500004)(122556002)(7846002)(107886002)(10400500002)(33656002)(74316001)(92566002)(9686002)(10290500002)(8936002)(97736004)(2906002)(8676002)(76176999)(7696003)(2900100001)(50986999)(68736007)(2501003)(2950100001)(586003)(3280700002)(6116002)(189998001)(81166006)(5003600100003)(86362001)(102836003)(7059030)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0653; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jun 2016 21:03:41.6351 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0653 Archived-At: Subject: Re: [dhcwg] On RFC 7819, privacy considerations for DHCP... X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 21:03:45 -0000 T24gVGh1cnNkYXksIEp1bmUgMTYsIDIwMTYgMzo0MiBQTSwgRGF2aWQgU2luZ2VyIHdyb3RlOg0K PiANCj4g4oCmaGFzIHRoZXJlIGJlZW4gYW55IGRpc2N1c3Npb24gb2YgdGhlIHBvc3NpYmlsaXR5 IG9mIHRoZSBjbGllbnQgYXNraW5nIGZvciBhDQo+IHNwZWNpZmljIGFsbG9jYXRpb24gc3RyYXRl Z3ksIHNwZWNpZmljYWxseSwg4oCccGxlYXNlIGdpdmUgbWUgYSBESUZGRVJFTlQgSVANCj4gYWRk cmVzcyBmcm9tIHdoYXQgeW91IHdvdWxkIG5vcm1hbGx5IGdpdmUgbWXigJ0/DQoNCldlIGNvbnNp ZGVyZWQgdGhhdCBpbiBSRkMgNzg0NCwgYnV0IHdlIGFzc29jaWF0ZWQgaXQgdG8gcmFuZG9taXph dGlvbiBvZiB0aGUgTUFDIEFkZHJlc3MsIHRoZSBDbGllbnQgSWRlbnRpZmllciBPcHRpb24gKElQ djQpIG9yIHRoZSBEVUlEIChJUHY2KS4gVGhlIGlkZWEgYmVpbmcgdGhhdCBpZiBhIG5vZGUgcHJl c2VudHMgYSBkaWZmZXJlbnQgaWRlbnRpdHkgdG8gdGhlIHNlcnZlciwgdGhlIHNlcnZlciB3aWxs IG1lY2hhbmljYWxseSBwcm92aWRlIGEgZGlmZmVyZW50IGFkZHJlc3MuDQoNCj4gT25lIG9mIHRo ZSBlYXNpZXN0IHdheXMgdG8gZmluZ2VycHJpbnQgYSBzeXN0ZW0gaXMgYnkgSVAgYWRkcmVzczsg TUFDIGFkZHJlc3Nlcw0KPiBhcmUgbmVjZXNzYXJ5IGxvY2FsLiBJZiBJ4oCZbSB0cnlpbmcgdG8g YmUgcHJpdmF0ZSwgaXQgbWlnaHQgYmUgbmljZSB0byBiZSBhYmxlIHRvDQo+IGNoYW5nZSBteSBh ZGRyZXNzIG9uIHJlcXVlc3QuDQoNClllcy4gVGhlIHNpbXBsZXN0IHdheSBpcyB0byBwaWNrIGEg bmV3IENsaWVudCBJZGVudGlmaWVyIG9yIGEgbmV3IERVSUQsIGFzIHN1Z2dlc3RlZCBpbiBSRkMg Nzg0NC4gQnV0IGlmIHRoZSBNQUMgQWRkcmVzcyByZW1haW5zIGNvbnN0YW50LCBzb21lIHNlcnZl cnMgY291bGQgc3RpbGwgdXNlIHRoYXQgdG8gaWRlbnRpZnkgdGhlIGNsaWVudCBhbmQgc2VydmUg dGhlIHNhbWUgYWRkcmVzcy4NCg0KLS0gQ2hyaXN0aWFuIEh1aXRlbWENCg0KDQo= From nobody Fri Jun 24 09:10:18 2016 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 443C612DD67; Fri, 24 Jun 2016 09:01:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160624160102.10933.33793.idtracker@ietfa.amsl.com> Date: Fri, 24 Jun 2016 09:01:02 -0700 Archived-At: Cc: dhcwg@ietf.org Subject: [dhcwg] dhc - Requested session has been scheduled for IETF 96 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 16:01:02 -0000 Dear Tomek Mrugalski, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. dhc Session 1 (2:00:00) Wednesday, Morning Session I 1000-1230 Room Name: Tiergarten size: 110 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Dynamic Host Configuration Area Name: Internet Area Session Requester: Tomek Mrugalski Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: v6ops 6man mif softwire homenet Second Priority: dane pcp sunset4 dnssd dnsop Special Requests: We would be willing to take a 2.5h slot if that helps with the scheduling. We always used full time of 2h slots (except Buenos Aires, when several important members couldn't make it). --------------------------------------------------------- From nobody Fri Jun 24 11:01:38 2016 Return-Path: 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 8C53612DCFB for ; Fri, 24 Jun 2016 11:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yl-jdGqWCBrh for ; Fri, 24 Jun 2016 11:01:30 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D684E12B05F for ; Fri, 24 Jun 2016 11:01:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13495; q=dns/txt; s=iport; t=1466791289; x=1468000889; h=from:to:subject:date:message-id:references:mime-version; bh=YqwlsNR+UpYDd3ehMMwkw0tUODE2F9x7tpc+Kb0/dLc=; b=g2v4gDOhxC6qRpuYzVFiXR1VjrsTQQ0bBv6seHIx0WPPY8TFwrHPzdlj 34snKxF7VptqPZCSo8DZpBsbyC/iXYVA/x9UIhVUilWLgsbj6ufnySrIG CNl4NXh1d7OhMSl80nJUWbchynsddMr6+5nSCvxLlGR9oDliJlUdeSL1m I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B8AgD5dG1X/4sNJK1cgnBOVn0GqWOLP?= =?us-ascii?q?oJygg+BeyKHLTgUAQEBAQEBAWUnhEwBAQUtXAIBCBEEAQEvMh0IAQEEEwiIKA7?= =?us-ascii?q?HFQEBAQEBAQEBAQEBAQEBAQEBAQEBARcFinWKGwWTTIU0AYYHiCWBcIRTiGePf?= =?us-ascii?q?QEeNoNwbogxfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,522,1459814400"; d="scan'208,217";a="122390882" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Jun 2016 18:01:29 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u5OI1SGG031611 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 24 Jun 2016 18:01:29 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 24 Jun 2016 13:01:28 -0500 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1104.009; Fri, 24 Jun 2016 13:01:28 -0500 From: "Bernie Volz (volz)" To: "'dhcwg@ietf.org'" Thread-Topic: IETF-96 (Berlin) DHC WG Session - Agenda Requests Thread-Index: AdGgpkH9N7+vCsgeRRapIcMHndhsAAK+zeEQAlRqSwAGU8PSwA== Date: Fri, 24 Jun 2016 18:01:27 +0000 Message-ID: <7a0799b87af04ad6ad861d57ad405770@XCH-ALN-003.cisco.com> References: <5d758f06a15440a49ca2534853045c89@XCH-ALN-003.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.1.195] Content-Type: multipart/alternative; boundary="_000_7a0799b87af04ad6ad861d57ad405770XCHALN003ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [dhcwg] IETF-96 (Berlin) DHC WG Session - Agenda Requests X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 18:01:36 -0000 --_000_7a0799b87af04ad6ad861d57ad405770XCHALN003ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi: Another reminder to submit agenda requests. See https://www.ietf.org/proceedings/96/agenda/agenda-96-dhc for draft agen= da. We will be meeting Wednesday, July 20, 2016, 10:00-12:30 Wednesday Morning = session I (CEST). While we requested a 2h time slot, we were assigned 2.5 hours. - Bernie From: Bernie Volz (volz) Sent: Wednesday, April 27, 2016 1:07 PM To: dhcwg@ietf.org Subject: IETF-96 (Berlin) DHC WG Session - Agenda Requests Hi: Please submit agenda requests as soon as you can if you do plan to present = at the DHC WG session in Berlin. As in the past, please provide: Title Of Session: Presenter: Related Drafts: Time Required: Purpose of Session: We do want to remind those requesting time that you should focus on discuss= ing key issues that need resolution to move a draft forward. You can view the working agenda at https://github.com/dhcwg/wg/wiki/IETF-96= -(Berlin)-DHC-WG-Agenda. We are now less than 3 months from that next meeting. Thanks! - Tomek & Bernie --_000_7a0799b87af04ad6ad861d57ad405770XCHALN003ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi:<= /p>

 

Another reminder to su= bmit agenda requests.

 

See https://www.ietf.org/proceedings/96/agenda/agenda-96-dhc for draft agen= da.

 

We will be meeting Wed= nesday, July 20, 2016, 10:00-12:30 Wednesday Morning session I (CEST).=

 

While we requested a 2= h time slot, we were assigned 2.5 hours.

 

-&nb= sp;         Bernie

 

From: Bernie Volz (volz)
Sent: Wednesday, April 27, 2016 1:07 PM
To: dhcwg@ietf.org
Subject: IETF-96 (Berlin) DHC WG Session - Agenda Requests

 

Hi:

 

Please submit agenda requests as soon as you can if = you do plan to present at the DHC WG session in Berlin.

 

As in the past, please provide:

 

Title Of Session:

Presenter:

Related Drafts:

Time Required:

Purpose of Session:

 

We do want to remind those requesting time that you = should focus on discussing key issues that need resolution to move a draft = forward.

 

You can view the working agenda at https://github.com/dhcwg/wg/wiki/IETF-96-(Berlin)-DHC-WG-Agenda.

 

We are now less than 3 months from that next meeting= .

 

Thanks!

 

-     &= nbsp;    Tomek & Bernie

 

--_000_7a0799b87af04ad6ad861d57ad405770XCHALN003ciscocom_-- From nobody Fri Jun 24 13:43:48 2016 Return-Path: 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 6E69712D643 for ; Fri, 24 Jun 2016 13:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNYLIK-bShr9 for ; Fri, 24 Jun 2016 13:43:44 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1268412D5A4 for ; Fri, 24 Jun 2016 13:43:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15117; q=dns/txt; s=iport; t=1466801024; x=1468010624; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ubYBwJDh5k6BZDx4DXoN9DZv8Pg+ae79PgD/Wx8E+7o=; b=jaomwfL3bp3GO8JElT9+4MjAXRCrHvTCwQmpwInTyJQxYKq92AOhqqHt ZwCTU2ouwJaHzjrUeYhgNBB6bqarGCNNQMQ5eGUBNXU/Oxu5mLJ3Y/KEk /QSxp69XNpD/qGg2WPUg7TQ516Hmq0iS+U2BN4SjZMVdBP940OmbE7281 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BDAgC4mm1X/5BdJa1cgnBOVn0GtSGFA?= =?us-ascii?q?YF7FwEKhXYCgTU4FAEBAQEBAQFlJ4RMAQEBBAEBAWsLEAIBCBEEAQEoBycLFAk?= =?us-ascii?q?IAQEEAQ0FiDAOxw8BAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYgfCIJOhHaCdoIvB?= =?us-ascii?q?ZNMhTQBhgeILIFphFOIZ499AR42g3BuAYgwfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,522,1459814400"; d="scan'208,217";a="288252556" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Jun 2016 20:43:43 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u5OKhhW0005159 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 24 Jun 2016 20:43:43 GMT Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 24 Jun 2016 15:43:42 -0500 Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1104.009; Fri, 24 Jun 2016 15:43:42 -0500 From: "Naiming Shen (naiming)" To: "Bernie Volz (volz)" , "tomasz.mrugalski@gmail.com" Thread-Topic: [dhcwg] IETF-96 (Berlin) DHC WG Session - Agenda Requests Thread-Index: AdGgpkH9N7+vCsgeRRapIcMHndhsAAK+zeEQAlRqSwAGU8PSwAAQM7YA Date: Fri, 24 Jun 2016 20:43:42 +0000 Message-ID: <2C26FB2B-7708-4FB9-A4B6-6330EFB19BE8@cisco.com> References: <5d758f06a15440a49ca2534853045c89@XCH-ALN-003.cisco.com> <7a0799b87af04ad6ad861d57ad405770@XCH-ALN-003.cisco.com> In-Reply-To: <7a0799b87af04ad6ad861d57ad405770@XCH-ALN-003.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.41.57.68] Content-Type: multipart/alternative; boundary="_000_2C26FB2B77084FB9A4B66330EFB19BE8ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "dhcwg@ietf.org" , "Enke Chen \(enkechen\)" Subject: Re: [dhcwg] IETF-96 (Berlin) DHC WG Session - Agenda Requests X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 20:43:47 -0000 --_000_2C26FB2B77084FB9A4B66330EFB19BE8ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I would like to present the below draft in DHC WG session in Berlin: https://www.ietf.org/id/draft-shen-dhc-client-port-00.txt Title: Generalize Client UDP Port Number of DHCP Relay Time Request: 10 minutes Regards, - Naiming On Jun 24, 2016, at 11:01 AM, Bernie Volz (volz) > wrote: Hi: Another reminder to submit agenda requests. See https://www.ietf.org/proceedings/96/agenda/agenda-96-dhc for draft agen= da. We will be meeting Wednesday, July 20, 2016, 10:00-12:30 Wednesday Morning = session I (CEST). While we requested a 2h time slot, we were assigned 2.5 hours. - Bernie From: Bernie Volz (volz) Sent: Wednesday, April 27, 2016 1:07 PM To: dhcwg@ietf.org Subject: IETF-96 (Berlin) DHC WG Session - Agenda Requests Hi: Please submit agenda requests as soon as you can if you do plan to present = at the DHC WG session in Berlin. As in the past, please provide: Title Of Session: Presenter: Related Drafts: Time Required: Purpose of Session: We do want to remind those requesting time that you should focus on discuss= ing key issues that need resolution to move a draft forward. You can view the working agenda at https://github.com/dhcwg/wg/wiki/IETF-96= -(Berlin)-DHC-WG-Agenda. We are now less than 3 months from that next meeting. Thanks! - Tomek & Bernie _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --_000_2C26FB2B77084FB9A4B66330EFB19BE8ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <4EE7ECD52DD57C41B8543D9E1582AD04@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

Hi, 

I would like to present the below draft in DHC WG session i= n Berlin:

https://www.ietf.org/id/draft-shen-dhc-client-port-00= .txt

Title: Generalize Client UDP Port Number of DHCP Relay
Time Request: 10 minutes

Regards,
- Naiming

On Jun 24, 2016, at 11:01 AM, Bernie Volz (volz) <volz@cisco.com> wrote:

Hi:
 
Another reminder to sub= mit agenda requests.
 
See https://www.ietf.org/proceedings/96/agenda/agenda-= 96-dhc for draft agenda.
 
We will be meeting Wedn= esday, July 20, 2016, 10:00-12:30 Wednesday Morning session I (CEST).
 
While we requested a 2h= time slot, we were assigned 2.5 hours.
 
-          Bernie
 
From: B= ernie Volz (volz) 
Sent: W= ednesday, April 27, 2016 1:07 PM
To: dhcwg@ietf.org
Subject: IETF-96 (Berlin) DHC WG Session - Agenda Requests
 
Hi:
 
Please submit agenda requests as soon as you can if you do plan to present = at the DHC WG session in Berlin.
 
As in the past, please provide:
 
Title Of Session:
Presenter:
Related Drafts:
Time Required:
Purpose of Session:
 
We do want to remind those requesting time that you should focus on discuss= ing key issues that need resolution to move a draft forward.
 
You can view the working agenda at&nb= sp;https://github.com/dhcwg/wg/wiki/IETF-96-(Berlin)-DHC-WG-Agenda<= /a>.
 
We are now less than 3 months from that next meeting.=
 
Thanks!
 
-        =   Tome= k & Bernie
 
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg

--_000_2C26FB2B77084FB9A4B66330EFB19BE8ciscocom_-- From nobody Mon Jun 27 05:46:57 2016 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0DC12D08F; Mon, 27 Jun 2016 05:46:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160627124656.5276.9149.idtracker@ietfa.amsl.com> Date: Mon, 27 Jun 2016 05:46:56 -0700 Archived-At: Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-05.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 12:46:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration of the IETF. Title : Dynamic Host Configuration Protocol for IPv6 (DHCPv6) bis Authors : Tomek Mrugalski Marcin Siodelski Bernie Volz Andrew Yourtchenko Michael C. Richardson Sheng Jiang Ted Lemon Timothy Winters Filename : draft-ietf-dhc-rfc3315bis-05.txt Pages : 134 Date : 2016-06-27 Abstract: This document describes the Dynamic Host Configuration Protocol for IPv6 (DHCPv6): an extensible mechanism for configuring hosts with network configuration parameters, IP addresses, and prefixes. Parameters can be provided statelessly, or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC). This document updates the text from RFC 3315, the original DHCPv6 specification, and incorporates the stateless DHCPv6 extensions (RFC 3736) and prefix delegation (RFC 3633), clarifying the interactions between these modes of operation (RFC 7550) and providing a mechanism for throttling DHCPv6 clients when DHCPv6 service is not available (RFC 7083). As such, this document obsoletes RFC3315, RFC3633, RFC3736, RFC7083, RFC7550. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-rfc3315bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-rfc3315bis-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 27 06:04:46 2016 Return-Path: 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 7C38512D1A1; Mon, 27 Jun 2016 06:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dH6SDyeSc4Tx; Mon, 27 Jun 2016 06:04:42 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD35B12D1A3; Mon, 27 Jun 2016 06:04:17 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id q132so155770775lfe.3; Mon, 27 Jun 2016 06:04:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=0f4qeorJd1qm2KzwwQwgYFPMFSKeQYEjpza7dM0rJiQ=; b=IjIB4E0NDO936WIkIguHsFR9Qr+QlPxEAv/DaU+btCP9+Tc26+SQXvw+10tscqXkX7 MzXriYPDNY3Gu3WOlt7clfIG2tWZbAFrF+HnYa7p80kE5zJRbSQ2hjqQ0sXBQMdHNUye 0DNbCWlsLbT9j223DqG0QBFZKOEtnfiUMCzpaoIJL/CQIBtT9itmG2TdpMdOeGRYNmiK f0Yj2c1YYJNQJgoyEyh8sGbmb53p2baFuSRQ5LTpy5iuxgsaEA/yrdXVQXVrd+1ifxzO WSiHch5BZid1hmpWhB48VFVA+cYVIRY/7pR3vzuL1XvciMZm7SmRseSn/pDE6ojrBatW TglA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=0f4qeorJd1qm2KzwwQwgYFPMFSKeQYEjpza7dM0rJiQ=; b=QxUKICBemif0QRxR5T6yQvNhhCra5bAVUhmWjYpqNBhfo0HjDyuRvr1o4pmCuc9Hzj kmeO7yGOHRHYabfKHaDiUbVjDlmD/Rv9QZDOaYF5LbTfynhLNTO7CxEhk0M2y7R6alFD dnPH8RhdWDI0BuFl089w3YjBblJTUn3vA4dSv8Jpd9zI1IZOhpZWtMEJt5tq/qQ/3AkR 31qHhSo/gmz8crWw651Ubb7dBykeMSWFdap5TA2gGKVFDsXsOQ1QNNjwe6RRwPdY4AkI KEVrie6AFCMCRoTSBhfDcF5Ntn0Cxf8jqrNt3jUEcwc9FUtJt9zBRc10xoUm3QMw3cVt s81Q== X-Gm-Message-State: ALyK8tJEwi4h+IXQQUllDeWS+uPI8Bw8rRXlz1yNGN4fGggYJC7Cbsroyotl/8AP8E+IXg== X-Received: by 10.25.170.200 with SMTP id t191mr201701lfe.17.1467032655527; Mon, 27 Jun 2016 06:04:15 -0700 (PDT) Received: from [10.0.0.100] (088156132194.dynamic-ww-04.vectranet.pl. [88.156.132.194]) by smtp.googlemail.com with ESMTPSA id 94sm3249116lfr.7.2016.06.27.06.04.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Jun 2016 06:04:14 -0700 (PDT) References: <20160627124656.5276.9149.idtracker@ietfa.amsl.com> To: "dhcpv6bis@ietf.org" , dhcwg From: Tomek Mrugalski X-Enigmail-Draft-Status: N1110 X-Forwarded-Message-Id: <20160627124656.5276.9149.idtracker@ietfa.amsl.com> Message-ID: <5771244C.4040609@gmail.com> Date: Mon, 27 Jun 2016 15:04:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <20160627124656.5276.9149.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-05 published X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 13:04:44 -0000 FYI This -05 version contains the combined work of the team. Here are the major changes since -04 (excerpt from ChangeLog in Appendix A): 62. Merged sections 17, 18 and 19 into a single section describing client and server behaviors. Ticket #142. 63. Added text about single session for multiple IA option types. Ticket #160. 64. Moved additional text from RFC3633 section 12.1. Ticket #102. 65. Addressed minor addition to text as per ticket 131 and also ticket #61. 66. Clarified MUST perform DAD, excepting exceptions listed in RFC4862 Section 5.4. Ticket #153. 67. Removed the requirement for the server to send Reconfigure Accept in Reply messages, also clarified why it's useful in Advertise. Ticket #154. 68. Explicitly require Elapsed Time option to be placed in messages sent by a client. Ticket #159. 69. Update section 14 - explained that Elapsed Time option (and possibly other options) must be updated prior to resending the message. Also included "retransmission" in the DHCP terminology. Ticket #157. 70. Added text explaining that the client should stop using an option if it's not being sent by the server. Ticket #150. 71. Added reference to RFC4242 (Information Refresh Time Option). Ticket #161. 72. Updated ORO Option to list Options that MUST NOT be included. Also added to that IANA Consider should keep track of which options are allowed in ORO. Ticket #81. 73. Updated Creation and Transmission of Advertise message so that the only options in the ORO will be included in the Advertise unless configured otherwise. Ticket #81. 74. Information Refresh Time Option is now mandatory for clients that support stateless mode. Added reference to RFC4242. Ticket #161. Please take a look at the diff tool (https://tools.ietf.org/rfcdiff?url2=draft-ietf-dhc-rfc3315bis-05.txt) for all changes since -04. If you'd like to get more details regarding the tickets, they can be viewed at https://tools.ietf.org/group/dhcpv6bis/. Bernie and I will discuss the next steps, but our intention is to start WGLC shortly. Since both of us are co-authors, we may be able to start it on our own, but we will ask the shepherd to determine the consensus after WGLC is done. Also, this is a complex and essential document, so we need to give enough time for people to review it thoroughly. Expect much longer WGLC than usual. Details are TBD. Tomek -------- Forwarded Message -------- Subject: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-05.txt Date: Mon, 27 Jun 2016 05:46:56 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: dhcwg@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration of the IETF. Title : Dynamic Host Configuration Protocol for IPv6 (DHCPv6) bis Authors : Tomek Mrugalski Marcin Siodelski Bernie Volz Andrew Yourtchenko Michael C. Richardson Sheng Jiang Ted Lemon Timothy Winters Filename : draft-ietf-dhc-rfc3315bis-05.txt Pages : 134 Date : 2016-06-27 Abstract: This document describes the Dynamic Host Configuration Protocol for IPv6 (DHCPv6): an extensible mechanism for configuring hosts with network configuration parameters, IP addresses, and prefixes. Parameters can be provided statelessly, or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC). This document updates the text from RFC 3315, the original DHCPv6 specification, and incorporates the stateless DHCPv6 extensions (RFC 3736) and prefix delegation (RFC 3633), clarifying the interactions between these modes of operation (RFC 7550) and providing a mechanism for throttling DHCPv6 clients when DHCPv6 service is not available (RFC 7083). As such, this document obsoletes RFC3315, RFC3633, RFC3736, RFC7083, RFC7550. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-rfc3315bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-rfc3315bis-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From nobody Tue Jun 28 08:52:51 2016 Return-Path: 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 E3E2712D1D1 for ; Tue, 28 Jun 2016 08:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZp_sJ4ZPGjM for ; Tue, 28 Jun 2016 08:52:47 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAF9E12B043 for ; Tue, 28 Jun 2016 08:52:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17487; q=dns/txt; s=iport; t=1467129166; x=1468338766; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=uIqmwjtJshRUKnA2GY8nNM1HuGF+i1mvU1NyZ3wCSHY=; b=b8WNbwxL7jjhGxvRm7VKH3ygwElF28ZM/lzXdfEUOsEi0+K+f0UEIy8r nTi0/D6f7oVnxEG5rpcFRPTMC/oV1j7rMtIs81jZWH18LQy+3+8UiBQQ1 jRJegGtffelGoru8AmJe0TNWa13YFT1H7/6N2C0JDDe5Qj42FIkc2U42G Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AgAgD4nHJX/5ldJa1bgnBOVn0GhUS0a?= =?us-ascii?q?IF7IoQbgVsCgTA4FAEBAQEBAQFlJ4RMAQEBBC1KAhACAQgRAwEBASgHMhQJCAI?= =?us-ascii?q?EAQ0FCBOIFQ7DWAEBAQEBAQEBAQEBAQEBAQEBAQEBARyKdYQqCS0WCIUdBY17h?= =?us-ascii?q?VKFNQGGB4grgXBOhAaHTIEbj34BDw82g3BuAYdtQ38BAQE?= X-IronPort-AV: E=Sophos;i="5.26,541,1459814400"; d="scan'208,217";a="119925206" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Jun 2016 15:52:30 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u5SFqPJG023242 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 28 Jun 2016 15:52:25 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 28 Jun 2016 10:52:25 -0500 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Tue, 28 Jun 2016 10:52:25 -0500 From: "Bernie Volz (volz)" To: "Naiming Shen (naiming)" , "dhcwg@ietf.org" Thread-Topic: [dhcwg] Fwd: New Version Notification for draft-shen-dhc-client-port-00.txt Thread-Index: AQHRy33PGH3e2Zpl5U2t1woe7KbsDJ//D7Kg Date: Tue, 28 Jun 2016 15:52:25 +0000 Message-ID: <410bdf4c06f242348323a6ad02a75e29@XCH-ALN-003.cisco.com> References: <20160621052856.30178.16015.idtracker@ietfa.amsl.com> <67E6B29E-91A7-4ED9-A2E7-4511C91EDF8F@cisco.com> In-Reply-To: <67E6B29E-91A7-4ED9-A2E7-4511C91EDF8F@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.131.77.132] Content-Type: multipart/alternative; boundary="_000_410bdf4c06f242348323a6ad02a75e29XCHALN003ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Enke Chen \(enkechen\)" Subject: Re: [dhcwg] Fwd: New Version Notification for draft-shen-dhc-client-port-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 15:52:50 -0000 --_000_410bdf4c06f242348323a6ad02a75e29XCHALN003ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable (WG Chair hat-off) I think this work is flawed and it will basically be impossible to get all = clients to change - and manually configuring the client as to whether to us= e the 'default port' or not is also not an option - especially for clients = that roam. If a client is configured incorrectly it will not get a lease. A= nd if there are still some clients on a network that use the default port, = you're hosed anyway. So, this just cannot work. The main reason a specific port is used is that the relay does not have an = option (or field in the packet) in which to store the response port; just t= he address (giaddr for v4, peer-address for v6). Having relays remember this information also seems rather complex (especial= ly since a relay-agent (option 82) sub-option could easily be defined for v= 4, or a relay top-level option for v6). But, that is really the lesser of t= he problems with this entire solution. Relaxing RELAY to SERVER communication to use alternate ports seems to be a= much more plausible and viable solution. And, I would think that would giv= e you exactly what you need? (The client to directly reachable server or fi= rst hop relay communication is interface specific so hard to see how that i= s an issue with using the client port.) Also, relays and servers are typica= lly within the same operator administrative domain, so upgrading both to su= pport this capability is a much more easily achieved goal. Again, the solution here is to have the relay indicate the response port. T= his would be a new relay agent option (82) sub-option and a new DHCPv6 rela= y option. The option would just need to be 2 octets to specify the 16-bit p= ort number to be used [an alternative would just be to this option be a fla= g option to indicate reply to source port, but that does not work as well f= or DHCPv6 given that relay chaining is supported there - note that each rel= ay can add its own port]. - Bernie From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Naiming Shen (naim= ing) Sent: Wednesday, June 22, 2016 2:39 PM To: dhcwg@ietf.org Cc: Enke Chen (enkechen) Subject: [dhcwg] Fwd: New Version Notification for draft-shen-dhc-client-po= rt-00.txt Hi, We just submitted a new (individual submission) Internet draft dealing DHCP issues with large scale and distributed relay agents within a single node/r= outer/switch. Please review and comment. thanks. - Naiming Begin forwarded message: From: > Subject: New Version Notification for draft-shen-dhc-client-port-00.txt Date: June 20, 2016 at 10:28:56 PM PDT To: Naiming Shen >, Enke Chen <= enkechen@cisco.com> A new version of I-D, draft-shen-dhc-client-port-00.txt has been successfully submitted by Naiming Shen and posted to the IETF repository. Name: draft-shen-dhc-client-port Revision: 00 Title: Generalize Client UDP Port Number of DHCP Relay Document date: 2016-06-20 Group: Individual Submission Pages: 5 URL: https://www.ietf.org/internet-drafts/draft-shen-dhc-client-= port-00.txt Status: https://datatracker.ietf.org/doc/draft-shen-dhc-client-port= / Htmlized: https://tools.ietf.org/html/draft-shen-dhc-client-port-00 Abstract: This document extends the DHCP and DHCPv6 protocols for the UDP transport from server to client and allows the port to be any valid number on the DHCP relay system. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_410bdf4c06f242348323a6ad02a75e29XCHALN003ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

(WG Chair hat-off)<= /p>

 

I think this work is flawed and it wi= ll basically be impossible to get all clients to change – and manuall= y configuring the client as to whether to use the ‘default port’ or not is also not an option – especially for clients th= at roam. If a client is configured incorrectly it will not get a lease. And= if there are still some clients on a network that use the default port, yo= u’re hosed anyway. So, this just cannot work.

 

The main reason a specific port is us= ed is that the relay does not have an option (or field in the packet) in wh= ich to store the response port; just the address (giaddr for v4, peer-address for v6).

 

Having relays remember this informati= on also seems rather complex (especially since a relay-agent (option 82) su= b-option could easily be defined for v4, or a relay top-level option for v6). But, that is really the lesser of the prob= lems with this entire solution.

 

Relaxing RELAY to SERVER communicatio= n to use alternate ports seems to be a much more plausible and viable solut= ion. And, I would think that would give you exactly what you need? (The client to directly reachable server or first hop relay= communication is interface specific so hard to see how that is an issue wi= th using the client port.) Also, relays and servers are typically within th= e same operator administrative domain, so upgrading both to support this capability is a much more easily achieve= d goal.

 

Again, the solution here is to have t= he relay indicate the response port. This would be a new relay agent option= (82) sub-option and a new DHCPv6 relay option. The option would just need to be 2 octets to specify the 16-bit port numbe= r to be used [an alternative would just be to this option be a flag option = to indicate reply to source port, but that does not work as well for DHCPv6= given that relay chaining is supported there – note that each relay can add its own port].

 

-   =        Bernie

 

From: dhcwg [mailto:dhcwg-bounces@ie= tf.org] On Behalf Of Naiming Shen (naiming)
Sent: Wednesday, June 22, 2016 2:39 PM
To: dhcwg@ietf.org
Cc: Enke Chen (enkechen) <enkechen@cisco.com>
Subject: [dhcwg] Fwd: New Version Notification for draft-shen-dhc-cl= ient-port-00.txt

 

 

Hi,

 

We just submitted a new (individual submission) Inte= rnet draft dealing DHCP

issues with large scale and distributed relay agents= within a single node/router/switch.

 

Please review and comment.

 

thanks.

- Naiming



Begin forwarded message:

 

Subject: New Version Notification for draft-shen-dhc-client-por= t-00.txt

Date: June 20, 2= 016 at 10:28:56 PM PDT

To: Naiming Sh= en <naiming@cisco.com>, Enke= Chen <enkechen@cisco.com><= /span>

 


A new version of I-D, draft-shen-dhc-client-port-00.txt
has been successfully submitted by Naiming Shen and posted to the
IETF repository.

Name: draft-shen-dhc-client-port
Revision: 00
Title: Generalize Client UDP Port Num= ber of DHCP Relay
Document date: 2016-06-20
Group: Individual Submission
Pages: 5
URL:            https://www.ietf.org/internet-drafts/draft-shen-dhc-client-port-00.txt<= /a>
Status:         https://datatracker.i= etf.org/doc/draft-shen-dhc-client-port/
Htmlized:       https://tools.ietf.org/html/draft-= shen-dhc-client-port-00


Abstract:
  This document extends the DHCP and DHCPv6 protocols for the UDP=
  transport from server to client and allows the port to be any v= alid
  number on the DHCP relay system.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

 

--_000_410bdf4c06f242348323a6ad02a75e29XCHALN003ciscocom_-- From nobody Tue Jun 28 12:50:01 2016 Return-Path: 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 B80A012D793 for ; Tue, 28 Jun 2016 12:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpCsvwxkbRhu for ; Tue, 28 Jun 2016 12:49:54 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9C0E12D76D for ; Tue, 28 Jun 2016 12:49:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26884; q=dns/txt; s=iport; t=1467143383; x=1468352983; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=HyQ0MpzO6hY738Ag0RT9+hZEq2GNBbND3ctLvJrTUI0=; b=QLqfzJ0xC5Qce1uxA52TYfSmmJ1gWV6fIOo3J4PGZFY9/cjgfn0eQUP3 xml8q+WgTihUiwd2EI2mNDJp0Dri3spsYPkfhCMH9eH8jXanYkm4kwAoC o1A33A7LV8K7F1jlLysDhWWMZe77ztT8N9kh++IRnN4DWHdlPBfKBZKi0 M=; X-IronPort-AV: E=Sophos;i="5.26,542,1459814400"; d="scan'208";a="636437373" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Jun 2016 19:49:41 +0000 Received: from dhcp-10-131-65-120.cisco.com (dhcp-10-131-65-120.cisco.com [10.131.65.120]) (authenticated bits=0) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u5SJndp9009813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jun 2016 19:49:40 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Kim Kinnear In-Reply-To: <57488F41.1090906@gmail.com> Date: Tue, 28 Jun 2016 15:49:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8F3B4E55-1644-4A41-846F-D01312662E91@cisco.com> References: <0a748e2ecef446ad8962a84e275e17c2@XCH-ALN-003.cisco.com> <57488F41.1090906@gmail.com> To: Tomek Mrugalski X-Mailer: Apple Mail (2.3112) X-Authenticated-User: kkinnear Archived-At: Cc: "" , Kim Kinnear Subject: Re: [dhcwg] WGLC comments on draft-ietf-dhc-dhcpv6-failover-protocol-01 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 19:49:58 -0000 Tomek, Thank you for reviewing it. My comments are embedded below... > On May 27, 2016, at 2:17 PM, Tomek Mrugalski = wrote: >=20 > On 28.04.2016 21:25, Bernie Volz (volz) wrote: >> This message starts the DHC Working Group Last Call to advance >> draft-ietf-dhc-dhcpv6-failover-protocol-01, DHCPv6 Failover Protocol. >> This document=92s intended status is Proposed Standard. At present, = there >> is no IPR file against this document. >>=20 >> Please send your comments by May 22, 2016. If you do not feel this >> document should advance, please state your reasons why. > It definitely took much longer than I initially anticipated, but here = it > goes. While my name is still on this I-D, I have not been involved > in this draft for at least a year. All the praise for this work should > go to Kim. As such, please consider this review as if it was provided = by > non-author. >=20 > I did read the draft in its entirety. It is long and complex, but very > well written with concepts, implementation details and reasons for > design choices being well explained. >=20 > Here are my comments. Many of them are editorial in nature, so please > forgive I did not segregate them out. >=20 > Abstract: > to provide for DHCPv6 failover =3D> to provide DHCPv6 failover Sure. >=20 > Section 1: > Add "Active-active mode may be defined in the future." I specifically removed this. I don't see the value of saying this. If it happens, it happens. If it doesn't, it doesn't. How does saying this help anything? If you feel strongly, we can put it back in.=20 My basic thought in the later stages of working on this draft was -- if it isn't necessary, it should not be in the draft. I've *tried* to keep to that approach, in order to keep this draft small enough to actually move through the process. Also, everything that isn't required that is in the draft is just something *else* to argue about with people who review it. And a lot of people are going to review it. At least we hope so, anyway. >=20 > Section 3: > To make it consistent, we should change all instances of Binding = status > (3 ocurrences) to binding-status (31 occurrences). Sure. Nice catch. >=20 > server when it is in the BACKUP state. =3D> > server when it is in the FREE-BACKUP state. > (there's no BACKUP state) Good catch. >=20 > and BACKUP on the secondary server =3D> > and FREE-BACKUP on the secondary server Yes. >=20 > Section 4.2.1 > used for allocating individual DHCP IPv6 addresses =3D> > used for allocating individual IPv6 addresses Yes. >=20 > When an IPv6 address goes PENDING-FREE Section 7.2 it is owned =3D> > When an IPv6 address goes PENDING-FREE (see Section 7.2) it is owned Yes. >=20 > Section 4.2.1 says: > An operational partner MUST NOT lease IPv6 addresses that were > assigned to its downed partner and later expired or were released or > declined by a client unless it is in PARTNER-DOWN state. When it is > in PARTNER-DOWN state, a server SHOULD allocate from its own pool. = It > SHOULD NOT use its partner's pool. >=20 > This text is inconsistent. Either we use SHOULD/SHOULD NOT everywhere > or MUST/MUST NOT. I could not disagree more -- it is perfectly appropriate to use MUST/MUST NOT for one situation and SHOULD/SHOULD NOT for a *different* situation. However, I think that below you are suggesting that we never let one partner do more than extend the other partner's leases, and I'm ok with that. To that end, I will change this to say: An operational partner MUST NOT lease IPv6 addresses that were assigned to its downed partner and later expired or were released or declined by a client. When it is in PARTNER-DOWN state, a server MUST allocate new leases from its own pool. It MUST NOT use its partner's pool. > Also, the last sentence should be clarified to "It > SHOULD NOT use its partner's pool to allocate new leases.". Yes, essentially. >=20 > I like the approach to allocate odd addresses on one partner and even > on another. This implies exactly 50/50 split between them (we = previously > talked about configuration parameter for that), but that's > ok. If someone is running out of IPv6 addresses, he has bigger = problems > than misbehaving failover. I agree with this change, and have made the text change above. >=20 > Section 4.3: > "will have no record at all of the lease to the DHCP client." =3D> > "will have no record at all of the lease being assigned to the DHCP > client." Sure. >=20 > Section 5.1 > The text does not define how to set transaction-id. There's reference > to Section 5.1 of RFC5460, which in turn says that the meaning of > the fields are defined in RFC3315. That RFC says that clients set them > to random value. There are no clients in failover protocol. I suppose > we need a text that whoever initiates the exchange, must set the > transaction-id. How about setting it to increasing value. This is = better > than using the usual random, which has a slim, but non-zero chance of > repeat itself. Random could work most of the time, but every couple > months the PRNG would spit the same value sufficiently close to each > other and then failover could skip an update. Good point, I'll create some words for this. >=20 > Q: section 5.2 says that msg-type is different than the one in DHCPv6. > Why? We currently have 23 types defined. Do we really expect that many > more to be defined? My thoughts about this are explained below when > commenting Section 11. See my comment when you discuss Section 11, below. >=20 > Section 5.3.9 > I think CONNECTACK is not the right name for this message, as it > can also be used to reject connection. ACK in DHCP world definitely > means a positive acknowledgement. So better name would be > CONNECT-REPLY or maybe CONNECT-RESPONSE? Sigh. I don't entirely agree that in the DHCP world that ACK always means a positive response. In the bulked DHCPv4 failover world, an ACK can have some positive and some negative responses, and I carried that over here. But it sounds like this is important to you. If we are going to change it, I would like to keep message types a single thing, no hyphens. I understand that RFC 3315 has hyphened-messages. I would=20 still like to keep these to have no hyphens for a variety of reasons. CONNECTREPLY >=20 > The same is true for BNDACK as BNDACK may actually contain NAK > response. BND-REPLY or BINDING-REPLY seems better suited. BNDREPLY >=20 > Generic comment for Sections 5.4.*. Most of the options do not have > proper names and they're referred to by the constant values. Most > (all?) DHCPv6 options have proper names that are used to refer them. > Do you think it would be useful to include them? Well, no. Why create an additional level of translation? >=20 > Also, for each option there's an explanatory text that says what the > content of the option is. It would be very useful to have one sentence > for each option that explains when and where this option may appear. I think that has two problems: 1. It duplicates information already in the draft in the messages themselves. The descriptions of the messages should say when an option should or should not appear -- that is where the context of how they are used is clear. If we have that in two places it can be inconsistent, and then which one does the user follow? 2. It creates a need to "update" the this draft if some other draft in the future decides to reuse one of these options. Which isn't a huge deal, but why make life harder for future folks? So, really, you can't expect to understand how these options are used from their definitions. Either the definitions come first, and you have to suspend your desire to know everything about these options are used until later in the draft, or we have to put the options definitions at the end of the draft and you have to keep referring to that as you read the meat of the draft. It is a circular definition problem. Seems to me that the most recent approach to this with drafts/RFCs in the DHC WG is to define the options up front, and then describe how and when they are used, which I have done here. I have written drafts both ways over the years, and neither is wonderful, but both work. But with the "option definitions first" approach, you simply cannot expect to understand how and when they are used when reading section 5.4. I don't particularly want to put the options all at the end, since I think that is not the current approach in our WG, and so I think people have to wait to find out how the options are used until the message that use them describe how they are used. >=20 > Section 5.4.3 > There should be a text similar to: "Three encapsulated options are > defined at this time, but additional options may be defined in the > future." Again, what is the value of "... but additional options may be defined in the future." That's true of anything here, why would you say that for this section and not for everything else? =20 That is just confusing. I think this is a bad idea. >=20 > Sections 5.4.4 - 5.4.6 > Extra text should be added: "This option may appear only in > OPTION_F_DNS_REMOVAL_INFO" I also think this is a bad idea. If someone wants to reuse one of these options in some other draft, why are you not allowing them to do so? >=20 > Section 5.4.7 > I'm unclear whether this is the greatest lifetime for all leases > ever processed by the server? Or is it supposed to be an encapsulated > option and it describes a single lease only? See Sections 7.3, 7.4, 7.5.3, 7.5.5, 7.8. It, along with many other options, are used inside of an IA_XX option. You have to look at the sections of the document where this is used to see what value actually goes into it. I will add: "The greatest lifetime that this server has ever acked to its partner in a BNDACK for this lease or prefix." > Section 5.4.8 > Getting the value of this option may be tricky. It depends on many > things, but one of the limiting factors in Linux are socket buffers. > They're limited by the number of bytes rather than number of packets. Hmmm. This has little to do with Linux. This is how many packets the DHCP server is willing to have *read* from the socket and be working on at once. If the receiving server has a fixed number of buffers for failover, then if you send more than it can hold, it might well drop the packets. The goal here is to *not* use TCP backpressure to stall the sender, so that the connection stays clear for important messages like DISCONNECT or STATE changes. So we want to read from the socket and keep the connection unblocked. This number tells the sender that the receiver doesn't want to see more than this number outstanding at one time. >=20 > Section 5.4.12 > When is this option sent? After connection with partner is > reestablished? See Section 6.3. >=20 > Section 5.4.13 > "associated with this IPv6 address." =3D> > "associated with this IPv6 address or prefix." Sure. >=20 > Section 5.4.14 > The figure there has extra 32bits field called protocol-version. I > think that's an editing artifact and should be removed. Good catch. I had to look at it several times to see that! >=20 > Also, do you think it would be reasonable to add a text that in > general the major version must match or the servers won't be able to > interoperate? This is just a proposal for consideration. In Kea we're > using database versioning with major/minor numbers. Minor numbers are > for backward compatible changes, like little tweaks. Once we change > something significant, we bump up the major number. It's only an idea. = I > don't insist on it in any way. I don't want to restrict people's ability to build cool software. If George wants to build a server that will work with three different major versions, should we stop him? This is entirely an implementation decision, in my view, so no, I don't think we should say this. >=20 > Section 5.4.15 > I would recommend renaming this option to OPTION_F_KEEPALIVE_TIME. > Keep-alive is immediately understood, while receive time may mean > many things. I didn't want people to somehow assume that this was related to the TCP keepalive capability. In particular, I didn't want them to say "why not just use TCP keep alive and you won't need this option", and then I have to explain it in detail. But if you want to change it, sure. OPTION_F_KEEPALIVE_TIME >=20 > Section 5.5 > Description of AddressInUse status says: > One client on one server has leases that are in conflict with the > leases that the client has on another server. Alternatively, the > address could be associated with a different IA_ID on each server. > That's IAID. IA_ID looks like a new type of IA container, which = confused > me at first. Good catch. >=20 > Section 6.1.2 > The text says that MCLT received in the CONNECT message should be > compared with the configured MCLT value. Does it make sense at all > to allow MCLT configuration on the secondary side? Removing this > ability and accepting whatever primary sends seems the way to go > here. One less parameter to misconfigure. Anyway, if you mistrust the > values primary may send, why establish the relationship at all? It is vital that the secondary and primary agree on the MCLT. We tend to ensure that they are configured identically, and consider it an warning if they are not. You are suggesting that the secondary would have to remember whatever value the primary most recently told the secondary during the CONNECT. That's reasonable, though different than our approach has been for the last decade or so. Ok, I'll change it. >=20 > Section 7.3 > liftime =3D> lifetime >=20 > The time when the this server... =3D> > The time when this server... Thanks.=20 >=20 > Section 7.4 > The following text: >=20 > Every BNDUPD message contains information about either a single > client binding in an OPTION_CLIENT_DATA option, or a single prefix > lease in an OPTION_IAPREFIX option. >=20 > is a bit confusing and took me a while to understand what it says. How > about this rewording: >=20 > Every BNDUPD message contains information about either a single > client binding in an OPTION_CLIENT_DATA option that include IAADDR > or IAPREFIX options associated with that client, or a single prefix > lease in an OPTION_IAPREFIX option for prefixes that are currently = not > associated with any clients. Great, sold! >=20 > This section also mentions that OPTION_VSS MUST appear in BNDUDP > message if certain conditions are met. I disagree with this. Support > for RFC6607 is not mandatory and there may be valid, working failover > deployments that don't support VSS. Hence I don't agree with the MUST = here. Yes, I agree that RFC6607 is not mandatory. =20 The condition where the MUST is invoked for the OPTION_VSS is the condition where you *are* using RFC 6607. If you are *not* using RFC 6607, then you MUST NOT use the OPTION_VSS. The MUST doesn't make you support RFC 6607, it says that if you *are* using RFC 6607, you MUST use OPTION_VSS. I see this as both correct and required, so I am not inclined to remove this. >=20 > I think we should to reword the list slightly. The sentence before the > list says "MUST contain at least the data shown below in its > client-options section", but then OPTION_F_RECONFIGURE_DATA has lower > case "if any". I think it would be better to rephrase this list as: >=20 > The OPTION_CLIENT_DATA option: >=20 > - MUST contain option 1 > - MAY contain option 2 > - MUST NOT contain option 3 > ... Yes, I can see that the original MUST is a little overbearing. I think this can be handled by listing the data and avoiding 2119 language except in specific circumstances. The discussion above on RFC 6607 is one of those circumstances where I think RFC 2119 language is required. >=20 > The list also mentions IA_TA. At the first glance it does not make > much sense to use failover to provide lease stability for addresses > that are temporary by nature. Do you think failover should cover > temporary addresses at all? There's a tiny bit of usefulness to > prevent duplicates in already assigned temporary addresses. But is it > worth the effort? We originally thought the same way, but then realized that=20 IA_TA leases *can* be renewed. Certainly we would expect that they would rarely be renewed, but they can. Given that, it seemed reasonable to allow them to be renewed from the other server if the primary server went away. If your server doesn't allow renewals for IA_TA leases, then supporting them in failover would have little value.=20 This is one of those cases where I am always tempted to put in more words justifying and explaining why we did something, but when we did that for v4 the draft was 121 pages. So I've tried to just say what to do for the protocol. =20 I will put in one sentence to clarify this, saying that they can be renewed and that is why we support them, as this is = likely to be a common question. >=20 > The following text is a bit confusing: >=20 > OPTION_STATUS_CODE containing an error code, or > containing a success code if a message is required. > If the information in the corresponding OPTION_IA_NA, > OPTION_IA_TA, or OPTION_IA_PD option in the BNDUPD was > accepted, and no status message was required (which is > the usual case), no OPTION_STATUS_CODE option appears. >=20 > The first sentence suggests that there are cases when success status > code sometimes is necessary, but the second one says it does > not appear. There's no normative language, I admit, but nevertheless > this should be clarified (something like status code may appear, > but it's perfectly ok to skip it for success status). The whole silly way that the OPTION_STATUS_CODE is defined is confusing, and we are just paying the continuing price for it here. I will reword this to be clearer. >=20 > Section 7.7 >=20 > partner.. (remove extra dot). Yes. >=20 > The phrase NAK is used in section 7.7 only. Other sections refer > to this condition using the word reject or rejected. Maybe we could = make > the naming consistent? Or at least add a text explaining that NAK = means > a rejected update? Sure. >=20 > Section 7.7 ends with a list of 3 bullets. It's unclear what they > relate to. Is this a continuation of the previous list? Then they > should be 3, 4, and 5. If not, then some leading sentence should > be added explaining what this list describes. They are what do with the information in the OPTION_IAPREFIX, concerning a single prefix lease. I'll add more words to make this clear. >=20 > Figure 4 - extra empty lines between counters could be useful here. > It's confusing whether the (uncorrected) comment refers to the line > above or below. I'll fix this. > Section 8.5.2 > "communications fails". This one is genuinely confusing for > non-native speaker, I must admit that. Shouldn't this be either > "communication fails" or "communications fail"? Merriam-Webster > dictionaly says that Communication is plural, but may be used as > singular or plural. Communications is plural, but there's an example > that says "Communications is...". Source: > = http://www.merriam-webster.com/dictionary/communications?show=3D0&t=3D1292= 594132 Sorry about that. I think "communication fails" would be better than what is there. >=20 > Section 8.6.2 > "This is to allow any IPv6 addresses..." =3D> > "This is to allow any IPv6 addresses or prefixes..." Sure. >=20 > Section 8.7.1 > The text says that in the RECOVER-DONE state the server may respond to > RENEW requests and extend existing leases. It MUST NOT allocate any > additional leases when in RECOVER-DONE state. Ok, so how should the > server behave if a Renew comes in and there's no lease for it. Respond > with NoAddrsAvail or not repond at all? On one hand, not responding > seems safer, because the client will likely retransmit and there's > non-trivial chance that the server will be back in Normal state by > then and everyone will be happy. On the other hand, responding with > NoAddrsAvail status has the benefit of potentially providing other > configuration options. If you don't have any preference, I think going > with no response is the way to go. Regardless of the choice, the > behavior should be clarified. I agree. Also, "change the state of lease that appear" -> "change the state of a lease that appears". >=20 > Section 11 > "These values should start at 20, in order to reduce the > chance of collisions with existing DHCPv4 Messages using the same > ports as DHCPv6 failover.". I don't like that approach for several > reasons. First, the arbitrarily chosen 20 is already outdated (we have > standard DHCP message types up to 23 defined now). No matter what > values you start from, there will likely be a conflict some time > in the future. But this is a minor thing. Second, more important > issue is the confusion it brings. When you ask what message type 1 is, > every DHCP engineer with a clue will instantly tell it's Solicit. > With this proposal, the answer will be "in what context: dhcp proper > or dhcp failover"? This has more implications than it looks at > the first glance. Many logging routines in the code would have to > be updated to pass extra info whether the message should be > interpreted as DHCP or DHCP failover message. Also, think about > cases where you use tools like wireshark to inspect existing traffic. > They would have to be extended with extra logic to do conditional > parsing based on the TCP port number. To make it more convoluted, > we already have cases of TCP-based traffic in bulk and active > leasequery. We could have more if draft-volz-dhc-relay-server-security > evolves towards TLS solution. >=20 > Oh, and the failover solution *is* using some messages from the > standard DHCP. STARTTLS is used when establishing connection. It = happens > to have message code 23, which directly conflicts with proposal to = start > the codes from 20. >=20 > So what's the problem with using existing message type registry > anyway? With the proposed 12 messages, we'd have 35 message types > defined in DHCPv6. There's still 220 more available until we run out > of types. And seriously, if we ever define 200 message types, it > would mean something somewhere went horribly wrong. >=20 > I would very much prefer to use regular message types. Failover > is complicated enough without extra message type tricks. I could spend a lot of time justifying the way that it is currently written -- and there are what I think are good reason for it, but since I am going to agree to change it, I won't bother. I will change this to be the way you want it. >=20 > -------------------- >=20 > Partners send CONTACT messages as a mechanism to keep the connection > alive. Do you think it would make sense to get rid of this message and > send STATE messages instead? The benefit is that the server would have > more up-to-date configuration that its partner is in specific > state. There would be one less message type, so it would make the spec > marginally simpler. I think this could be useful to detect cases when > one way of communication fails, but the other is still functional. On > the other hand, CONTACT message is probably empty, so sending STATE > with all the options would generate more traffic even during normal, > healthy operation. I very much want to keep the CONTACT message for a variety of reasons: 1. We have various capabilities to log messages in log files for debugging. We have one log setting that will log *all* failover messages, and a different one that will log all failover messages *except* CONTACT messages. So you only see the "good stuff". I think this is a useful capability for anyone implementing failover, and while I'm sure we could put some status bits in a STATE message to say "this isn't really a state message, this is really a contact message but we sent a state message because we got rid of the contact message", it is a lot easier to simply have two different messages. 2. CONTACT messages are shorter. 3. STATE messages MUST be sent anytime anything changes anyway, and they are useful as sentinels that something *did* change. If we send them all the time, the don't carry that meaning. If a server would have more up to date information = from receiving a STATE message used as a CONTACT message -- = information that, today, it didn't get as a STATE message, then something is broken. 4. I don't see how this helps you detect a one-way communication failure better than having CONTACT and STATE messages. 5. I very much like the fact that when you see CONTACT messages you know immediately that there isn't other traffic going on. 6. Our implementation of v4 failover did exactly what you propose with state messages, and it cost processing time since you have to interpret every STATE message and save the contents if different, and decide if the contents *are* = different. With a CONTACT message, you just ignore it very early on. It was also confusing, because you didn't know if this message came out because it was supposed to because something changed, or it came out because the timer expired. Hard to debug. In case it isn't obvious, I *really* don't want to merge the CONTACT message and the STATE message. Been there, done that, and really didn't like it. Really.=20 That's it -- I'll make the changes I've agree to. If there are some that I didn't agree to that you want to discuss, let me know. Thanks for the detailed review -- Kim >=20 > -------------------- >=20 > Ok, that's it. Overall, I think Kim did a fantastic job with this = draft. > There are some nits to be improved, but only a handful of technical > comments to be addressed. For an almost 90 pages long draft this is > constitutes a great shape. Thank you for this work, Kim. >=20 > Tomek >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg