From nobody Thu Aug 7 07:03:45 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A81F01B2B46 for ; Thu, 7 Aug 2014 07:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 cRonUqcSMpHO for ; Thu, 7 Aug 2014 07:03:29 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80A8A1B2B3B for ; Thu, 7 Aug 2014 07:03:29 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s77E3Rmp031958 for ; Thu, 7 Aug 2014 16:03:27 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E6C8E202C4F for ; Thu, 7 Aug 2014 16:06:27 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id DDEA2200CF7 for ; Thu, 7 Aug 2014 16:06:27 +0200 (CEST) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s77E3Mj3023968 for ; Thu, 7 Aug 2014 16:03:27 +0200 Message-ID: <53E3872A.30204@gmail.com> Date: Thu, 07 Aug 2014 16:03:22 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dhcwg@ietf.org References: <20140519150302.3625.29866.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E1B03125B@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1B03125B@xmb-rcd-x04.cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/r0M1O3th1tPlBBgngb1VZ68gDOI Subject: Re: [dhcwg] New Version Notification for draft-dhcwg-dhc-rfc3315bis-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 14:03:37 -0000 Hi, This draft defines the term 'prefix length' but it never uses it. Not 'prefix-length' either. page 10: > prefix length The number of bits in a prefix. This should be corrected: either one doesn't define it, or one uses it. One example reason is the following. I am trying to find a field containing the prefix length of an assigned address, in a DHCP exchange (IPv4's 'subnet mask') - is it present or not? Should it or not? The wireshark dump does not expose any field as "prefix length". (dump available upon request). Searching the term 'prefix length' in the draft issues precisely one hit - the definition. That DHCP exchange results in the Host assigning a prefix length 64 on the address on the interface: I am not sure whether it does so because DHCP tells it so, or otherwise the programmer thought - as often was the case in other contexts - that the 64 prefix length is something that should always be there. There is no advertised prefix on the link (there is an RA but w/o RIO). Alex Le 19/05/2014 17:16, Bernie Volz (volz) a écrit : > The dhcpv6bis team is pleased to have published a revision of > RFC3315bis work. > > This version of the draft: 1. Incorporates the RFC3315 Errata. 2. > Incorporates the changes made to RFC3315 by other RFCs. 3. Addresses > other issues raised via email to the original authors or the > dhcpv6bis team or in other documents (such as ​ > http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-clarify-auth-01). > > This mostly covers the Milestone A (apply before merge) tickets - > see http://trac.tools.ietf.org/group/dhcpv6bis/report/6 (most of the > tickets resolved are at the bottom in the "A easy, apply before > merge" category). > > This version of the draft does NOT yet cover the merge from RFC 3633 > (and RFC 3736), though you find a few instances where that work was > started. Adding this material is the next major goal. > > We would appreciate any reviews people can do on this draft - please > provide comments on what needs to be fixed or you feel is not an > appropriate change! (Send mail to dhcpv6bis@ietf.org). > > Htmlized: http://tools.ietf.org/html/draft-dhcwg-dhc-rfc3315bis-01 > Diff: http://www.ietf.org/rfcdiff?url2=draft-dhcwg-dhc-rfc3315bis-01 > > - Bernie (for the dhcpv6bis team) > > -----Original Message----- From: internet-drafts@ietf.org > [mailto:internet-drafts@ietf.org] Sent: Monday, May 19, 2014 11:03 AM > To: Andrew Yourtchenko (ayourtch); Bernie Volz (volz); Tomek > Mrugalski; Bernie Volz (volz); Marcin Siodelski; Michael C. > Richardson; Sheng Jiang; Ted Lemon; Andrew Yourtchenko (ayourtch); > Tomek Mrugalski; Sheng Jiang; Marcin Siodelski; Michael Richardson; > Ted Lemon Subject: New Version Notification for > draft-dhcwg-dhc-rfc3315bis-01.txt > > > A new version of I-D, draft-dhcwg-dhc-rfc3315bis-01.txt has been > successfully submitted by Bernie Volz and posted to the IETF > repository. > > Name: draft-dhcwg-dhc-rfc3315bis Revision: 01 Title: Dynamic Host > Configuration Protocol for IPv6 (DHCPv6) bis Document date: > 2014-05-19 Group: Individual Submission Pages: 108 URL: > http://www.ietf.org/internet-drafts/draft-dhcwg-dhc-rfc3315bis-01.txt > > > Status: https://datatracker.ietf.org/doc/draft-dhcwg-dhc-rfc3315bis/ > Htmlized: http://tools.ietf.org/html/draft-dhcwg-dhc-rfc3315bis-01 > Diff: http://www.ietf.org/rfcdiff?url2=draft-dhcwg-dhc-rfc3315bis-01 > > Abstract: The Dynamic Host Configuration Protocol for IPv6 (DHCP) > enables DHCP servers to pass configuration parameters such as IPv6 > network addresses to IPv6 nodes. It offers the capability of > automatic allocation of reusable network addresses and additional > configuration flexibility. This protocol is a stateful counterpart > to "IPv6 Stateless Address Autoconfiguration" (RFC 4862), and can be > used separately or concurrently with the latter to obtain > configuration parameters. > > > > > 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. > > The IETF Secretariat > > _______________________________________________ dhcwg mailing list > dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg > From nobody Thu Aug 7 07:12:47 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0B811B2B46 for ; Thu, 7 Aug 2014 07:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 XFCdfxqLmu23 for ; Thu, 7 Aug 2014 07:12:39 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FCE31B2B48 for ; Thu, 7 Aug 2014 07:12:39 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s77ECbO6009046 for ; Thu, 7 Aug 2014 16:12:37 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A31EC200C22 for ; Thu, 7 Aug 2014 16:15:37 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 97209204490 for ; Thu, 7 Aug 2014 16:15:37 +0200 (CEST) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s77ECapX031414 for ; Thu, 7 Aug 2014 16:12:37 +0200 Message-ID: <53E38954.1030206@gmail.com> Date: Thu, 07 Aug 2014 16:12:36 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dhcwg@ietf.org References: <20140519150302.3625.29866.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E1B03125B@xmb-rcd-x04.cisco.com> <53E3872A.30204@gmail.com> In-Reply-To: <53E3872A.30204@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/uMPQhhRmy29sNsepSntzU-gglW4 Subject: Re: [dhcwg] draft-dhcwg-dhc-rfc3315bis-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 14:12:44 -0000 Ok, so sorry, yes, the 'prefix-length' term is present in draft-3315 -02. Still, I am still wondering: does DHCPv6 assign a prefix length which tags an address? (not prefix delegation). Or is the presence of /64 on computers running DHCP a pure invention of the programmer? Alex Le 07/08/2014 16:03, Alexandru Petrescu a écrit : > Hi, > > This draft defines the term 'prefix length' but it never uses it. Not > 'prefix-length' either. > > page 10: >> prefix length The number of bits in a prefix. > > This should be corrected: either one doesn't define it, or one uses it. > > One example reason is the following. > > I am trying to find a field containing the prefix length of an assigned > address, in a DHCP exchange (IPv4's 'subnet mask') - is it present or > not? Should it or not? The wireshark dump does not expose any field > as "prefix length". (dump available upon request). Searching the term > 'prefix length' in the draft issues precisely one hit - the definition. > > That DHCP exchange results in the Host assigning a prefix length 64 on > the address on the interface: I am not sure whether it does so because > DHCP tells it so, or otherwise the programmer thought - as often was the > case in other contexts - that the 64 prefix length is something that > should always be there. > > There is no advertised prefix on the link (there is an RA but w/o RIO). > > Alex > > Le 19/05/2014 17:16, Bernie Volz (volz) a écrit : >> The dhcpv6bis team is pleased to have published a revision of >> RFC3315bis work. >> >> This version of the draft: 1. Incorporates the RFC3315 Errata. 2. >> Incorporates the changes made to RFC3315 by other RFCs. 3. Addresses >> other issues raised via email to the original authors or the >> dhcpv6bis team or in other documents (such as ​ >> http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-clarify-auth-01). >> >> This mostly covers the Milestone A (apply before merge) tickets - >> see http://trac.tools.ietf.org/group/dhcpv6bis/report/6 (most of the >> tickets resolved are at the bottom in the "A easy, apply before >> merge" category). >> >> This version of the draft does NOT yet cover the merge from RFC 3633 >> (and RFC 3736), though you find a few instances where that work was >> started. Adding this material is the next major goal. >> >> We would appreciate any reviews people can do on this draft - please >> provide comments on what needs to be fixed or you feel is not an >> appropriate change! (Send mail to dhcpv6bis@ietf.org). > > >> >> Htmlized: http://tools.ietf.org/html/draft-dhcwg-dhc-rfc3315bis-01 >> Diff: http://www.ietf.org/rfcdiff?url2=draft-dhcwg-dhc-rfc3315bis-01 >> >> - Bernie (for the dhcpv6bis team) >> >> -----Original Message----- From: internet-drafts@ietf.org >> [mailto:internet-drafts@ietf.org] Sent: Monday, May 19, 2014 11:03 AM >> To: Andrew Yourtchenko (ayourtch); Bernie Volz (volz); Tomek >> Mrugalski; Bernie Volz (volz); Marcin Siodelski; Michael C. >> Richardson; Sheng Jiang; Ted Lemon; Andrew Yourtchenko (ayourtch); >> Tomek Mrugalski; Sheng Jiang; Marcin Siodelski; Michael Richardson; >> Ted Lemon Subject: New Version Notification for >> draft-dhcwg-dhc-rfc3315bis-01.txt >> >> >> A new version of I-D, draft-dhcwg-dhc-rfc3315bis-01.txt has been >> successfully submitted by Bernie Volz and posted to the IETF >> repository. >> >> Name: draft-dhcwg-dhc-rfc3315bis Revision: 01 Title: >> Dynamic Host >> Configuration Protocol for IPv6 (DHCPv6) bis Document date: >> 2014-05-19 Group: Individual Submission Pages: 108 URL: >> http://www.ietf.org/internet-drafts/draft-dhcwg-dhc-rfc3315bis-01.txt >> >> >> > Status: > https://datatracker.ietf.org/doc/draft-dhcwg-dhc-rfc3315bis/ >> Htmlized: http://tools.ietf.org/html/draft-dhcwg-dhc-rfc3315bis-01 >> Diff: http://www.ietf.org/rfcdiff?url2=draft-dhcwg-dhc-rfc3315bis-01 >> >> Abstract: The Dynamic Host Configuration Protocol for IPv6 (DHCP) >> enables DHCP servers to pass configuration parameters such as IPv6 >> network addresses to IPv6 nodes. It offers the capability of >> automatic allocation of reusable network addresses and additional >> configuration flexibility. This protocol is a stateful counterpart >> to "IPv6 Stateless Address Autoconfiguration" (RFC 4862), and can be >> used separately or concurrently with the latter to obtain >> configuration parameters. >> >> >> >> >> 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. >> >> The IETF Secretariat >> >> _______________________________________________ dhcwg mailing list >> dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg >> > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From nobody Thu Aug 7 07:35:49 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D31A1B2B8E for ; Thu, 7 Aug 2014 07:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 y5ho7OYwB5LG for ; Thu, 7 Aug 2014 07:35:45 -0700 (PDT) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AF011B2B93 for ; Thu, 7 Aug 2014 07:35:33 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id j15so4208363qaq.29 for ; Thu, 07 Aug 2014 07:35:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=e85bMdgG3c8hEyPm0l/nfMmZe+ZR9nHvN5zDLqbHoiE=; b=b6DMGm1/hL2fhV3eE7rjzWc+NuWVFqR+ndakhXChbOOd4NFTYaWHpYGTxoBa1eIroE 0HvH6jT68pcbBgbAXPZNUbWl8JhtTX4W0BY4gOuOYK6Plk74Dk/i0NlfOkaYU0QXlun5 aM8NGholNYzCvN6mgWx8+ifn1AVEiD7b50e4MtDDRsiazIjGMYjeDGMA2xuAneEhzm9M oEk84hFQ/tQex3X9ySpdubprsHscI7VtQ2+eqnFGm4aIYufE5IOSp6dD+G4TnkcMrUbC SB/Wqd9qgFczmcjM84YPCryBj9G+XSrdq2/7fp3xNh5jyK3Cltc8FyYbTYLUBUCJ9u68 grJA== X-Received: by 10.229.59.67 with SMTP id k3mr27758281qch.26.1407422132403; Thu, 07 Aug 2014 07:35:32 -0700 (PDT) Received: from ?IPv6:2001:420:2c52:1316:5f:e35e:e670:c48f? ([2001:420:2c52:1316:5f:e35e:e670:c48f]) by mx.google.com with ESMTPSA id j65sm67312qgf.22.2014.08.07.07.35.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Aug 2014 07:35:30 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ralph Droms In-Reply-To: <53E38954.1030206@gmail.com> Date: Thu, 7 Aug 2014 10:35:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140519150302.3625.29866.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E1B03125B@xmb-rcd-x04.cisco.com> <53E3872A.30204@gmail.com> <53E38954.1030206@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/sWHNgDVib9wux81NAoftK8SPoNQ Cc: dhcwg Subject: Re: [dhcwg] draft-dhcwg-dhc-rfc3315bis-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 14:35:47 -0000 On Aug 7, 2014, at 10:12 AM 8/7/14, Alexandru Petrescu = wrote: > Ok, so sorry, yes, the 'prefix-length' term is present in draft-3315 = -02. >=20 > Still, I am still wondering: does DHCPv6 assign a prefix length which = tags an address? (not prefix delegation). Assuming you mean "128-bit IPv6 address", the answer is "no". >=20 > Or is the presence of /64 on computers running DHCP a pure invention = of the programmer? I don't understand your question. There is no "prefix length" = associated with an address. >=20 > Alex >=20 > Le 07/08/2014 16:03, Alexandru Petrescu a =C3=A9crit : >> Hi, >>=20 >> This draft defines the term 'prefix length' but it never uses it. = Not >> 'prefix-length' either. >>=20 >> page 10: >>> prefix length The number of bits in a prefix. >>=20 >> This should be corrected: either one doesn't define it, or one uses = it. >>=20 >> One example reason is the following. >>=20 >> I am trying to find a field containing the prefix length of an = assigned >> address, in a DHCP exchange (IPv4's 'subnet mask') - is it present or >> not? Should it or not? The wireshark dump does not expose any = field >> as "prefix length". (dump available upon request). Searching the = term >> 'prefix length' in the draft issues precisely one hit - the = definition. >>=20 >> That DHCP exchange results in the Host assigning a prefix length 64 = on >> the address on the interface: I am not sure whether it does so = because >> DHCP tells it so, or otherwise the programmer thought - as often was = the >> case in other contexts - that the 64 prefix length is something that >> should always be there. >>=20 >> There is no advertised prefix on the link (there is an RA but w/o = RIO). >>=20 >> Alex >>=20 >> Le 19/05/2014 17:16, Bernie Volz (volz) a =C3=A9crit : >>> The dhcpv6bis team is pleased to have published a revision of >>> RFC3315bis work. >>>=20 >>> This version of the draft: 1. Incorporates the RFC3315 Errata. 2. >>> Incorporates the changes made to RFC3315 by other RFCs. 3. Addresses >>> other issues raised via email to the original authors or the >>> dhcpv6bis team or in other documents (such as =E2=80=8B >>> http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-clarify-auth-01). >>>=20 >>> This mostly covers the Milestone A (apply before merge) tickets - >>> see http://trac.tools.ietf.org/group/dhcpv6bis/report/6 (most of the >>> tickets resolved are at the bottom in the "A easy, apply before >>> merge" category). >>>=20 >>> This version of the draft does NOT yet cover the merge from RFC 3633 >>> (and RFC 3736), though you find a few instances where that work was >>> started. Adding this material is the next major goal. >>>=20 >>> We would appreciate any reviews people can do on this draft - please >>> provide comments on what needs to be fixed or you feel is not an >>> appropriate change! (Send mail to dhcpv6bis@ietf.org). >>=20 >>=20 >>>=20 >>> Htmlized: http://tools.ietf.org/html/draft-dhcwg-dhc-rfc3315bis-01 >>> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-dhcwg-dhc-rfc3315bis-01= >>>=20 >>> - Bernie (for the dhcpv6bis team) >>>=20 >>> -----Original Message----- From: internet-drafts@ietf.org >>> [mailto:internet-drafts@ietf.org] Sent: Monday, May 19, 2014 11:03 = AM >>> To: Andrew Yourtchenko (ayourtch); Bernie Volz (volz); Tomek >>> Mrugalski; Bernie Volz (volz); Marcin Siodelski; Michael C. >>> Richardson; Sheng Jiang; Ted Lemon; Andrew Yourtchenko (ayourtch); >>> Tomek Mrugalski; Sheng Jiang; Marcin Siodelski; Michael Richardson; >>> Ted Lemon Subject: New Version Notification for >>> draft-dhcwg-dhc-rfc3315bis-01.txt >>>=20 >>>=20 >>> A new version of I-D, draft-dhcwg-dhc-rfc3315bis-01.txt has been >>> successfully submitted by Bernie Volz and posted to the IETF >>> repository. >>>=20 >>> Name: draft-dhcwg-dhc-rfc3315bis Revision: 01 Title: >>> Dynamic Host >>> Configuration Protocol for IPv6 (DHCPv6) bis Document date: >>> 2014-05-19 Group: Individual Submission Pages: 108 = URL: >>> = http://www.ietf.org/internet-drafts/draft-dhcwg-dhc-rfc3315bis-01.txt >>>=20 >>>=20 >>>=20 >> Status: >> https://datatracker.ietf.org/doc/draft-dhcwg-dhc-rfc3315bis/ >>> Htmlized: http://tools.ietf.org/html/draft-dhcwg-dhc-rfc3315bis-01 >>> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-dhcwg-dhc-rfc3315bis-01= >>>=20 >>> Abstract: The Dynamic Host Configuration Protocol for IPv6 (DHCP) >>> enables DHCP servers to pass configuration parameters such as IPv6 >>> network addresses to IPv6 nodes. It offers the capability of >>> automatic allocation of reusable network addresses and additional >>> configuration flexibility. This protocol is a stateful counterpart >>> to "IPv6 Stateless Address Autoconfiguration" (RFC 4862), and can be >>> used separately or concurrently with the latter to obtain >>> configuration parameters. >>>=20 >>>=20 >>>=20 >>>=20 >>> 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. >>>=20 >>> The IETF Secretariat >>>=20 >>> _______________________________________________ dhcwg mailing list >>> dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg >>>=20 >>=20 >>=20 >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From nobody Thu Aug 7 07:46:54 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC4C1B2B8B for ; Thu, 7 Aug 2014 07:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 UvqemKxLT27U for ; Thu, 7 Aug 2014 07:46:50 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31F361B29F0 for ; Thu, 7 Aug 2014 07:46:50 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s77Ekmlc017312; Thu, 7 Aug 2014 16:46:48 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 682E6202C4F; Thu, 7 Aug 2014 16:49:48 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5CEDD200C39; Thu, 7 Aug 2014 16:49:48 +0200 (CEST) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s77EklhB022212; Thu, 7 Aug 2014 16:46:47 +0200 Message-ID: <53E39157.8060708@gmail.com> Date: Thu, 07 Aug 2014 16:46:47 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ralph Droms References: <20140519150302.3625.29866.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E1B03125B@xmb-rcd-x04.cisco.com> <53E3872A.30204@gmail.com> <53E38954.1030206@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/wihWBBobc0cba_Y2wd6wI38SmjE Cc: dhcwg Subject: Re: [dhcwg] draft-dhcwg-dhc-rfc3315bis-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 14:46:53 -0000 Le 07/08/2014 16:35, Ralph Droms a écrit : > > On Aug 7, 2014, at 10:12 AM 8/7/14, Alexandru Petrescu > wrote: > >> Ok, so sorry, yes, the 'prefix-length' term is present in >> draft-3315 -02. >> >> Still, I am still wondering: does DHCPv6 assign a prefix length >> which tags an address? (not prefix delegation). > > Assuming you mean "128-bit IPv6 address", the answer is "no". > >> >> Or is the presence of /64 on computers running DHCP a pure >> invention of the programmer? > > I don't understand your question. There is no "prefix length" > associated with an address. I am facing this computer which receives an RA without prefix length (no Prefix Information OPtion, just helps set the default route), and then runs DHCPv6 to obtain an IPv6 address A, and the resolver's address. After these messages, the computer configures the IPv6 address as A/64. I wonder where from comes that /64? Is DHCPv6 telling it it should be a /64? Alex > >> >> Alex >> >> Le 07/08/2014 16:03, Alexandru Petrescu a écrit : >>> Hi, >>> >>> This draft defines the term 'prefix length' but it never uses it. >>> Not 'prefix-length' either. >>> >>> page 10: >>>> prefix length The number of bits in a prefix. >>> >>> This should be corrected: either one doesn't define it, or one >>> uses it. >>> >>> One example reason is the following. >>> >>> I am trying to find a field containing the prefix length of an >>> assigned address, in a DHCP exchange (IPv4's 'subnet mask') - is >>> it present or not? Should it or not? The wireshark dump does >>> not expose any field as "prefix length". (dump available upon >>> request). Searching the term 'prefix length' in the draft issues >>> precisely one hit - the definition. >>> >>> That DHCP exchange results in the Host assigning a prefix length >>> 64 on the address on the interface: I am not sure whether it does >>> so because DHCP tells it so, or otherwise the programmer thought >>> - as often was the case in other contexts - that the 64 prefix >>> length is something that should always be there. >>> >>> There is no advertised prefix on the link (there is an RA but w/o >>> RIO). >>> >>> Alex >>> >>> Le 19/05/2014 17:16, Bernie Volz (volz) a écrit : >>>> The dhcpv6bis team is pleased to have published a revision of >>>> RFC3315bis work. >>>> >>>> This version of the draft: 1. Incorporates the RFC3315 Errata. >>>> 2. Incorporates the changes made to RFC3315 by other RFCs. 3. >>>> Addresses other issues raised via email to the original authors >>>> or the dhcpv6bis team or in other documents (such as ​ >>>> http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-clarify-auth-01). >>>> >>>> >>>> This mostly covers the Milestone A (apply before merge) tickets - >>>> see http://trac.tools.ietf.org/group/dhcpv6bis/report/6 (most >>>> of the tickets resolved are at the bottom in the "A easy, apply >>>> before merge" category). >>>> >>>> This version of the draft does NOT yet cover the merge from RFC >>>> 3633 (and RFC 3736), though you find a few instances where that >>>> work was started. Adding this material is the next major goal. >>>> >>>> We would appreciate any reviews people can do on this draft - >>>> please provide comments on what needs to be fixed or you feel >>>> is not an appropriate change! (Send mail to >>>> dhcpv6bis@ietf.org). >>> >>> >>>> >>>> Htmlized: >>>> http://tools.ietf.org/html/draft-dhcwg-dhc-rfc3315bis-01 Diff: >>>> http://www.ietf.org/rfcdiff?url2=draft-dhcwg-dhc-rfc3315bis-01 >>>> >>>> - Bernie (for the dhcpv6bis team) >>>> >>>> -----Original Message----- From: internet-drafts@ietf.org >>>> [mailto:internet-drafts@ietf.org] Sent: Monday, May 19, 2014 >>>> 11:03 AM To: Andrew Yourtchenko (ayourtch); Bernie Volz (volz); >>>> Tomek Mrugalski; Bernie Volz (volz); Marcin Siodelski; Michael >>>> C. Richardson; Sheng Jiang; Ted Lemon; Andrew Yourtchenko >>>> (ayourtch); Tomek Mrugalski; Sheng Jiang; Marcin Siodelski; >>>> Michael Richardson; Ted Lemon Subject: New Version Notification >>>> for draft-dhcwg-dhc-rfc3315bis-01.txt >>>> >>>> >>>> A new version of I-D, draft-dhcwg-dhc-rfc3315bis-01.txt has >>>> been successfully submitted by Bernie Volz and posted to the >>>> IETF repository. >>>> >>>> Name: draft-dhcwg-dhc-rfc3315bis Revision: 01 Title: >>>> Dynamic Host Configuration Protocol for IPv6 (DHCPv6) bis >>>> Document date: 2014-05-19 Group: Individual Submission >>>> Pages: 108 URL: >>>> http://www.ietf.org/internet-drafts/draft-dhcwg-dhc-rfc3315bis-01.txt >>>> >>>> >>>> >>> >>>> Status: >>> https://datatracker.ietf.org/doc/draft-dhcwg-dhc-rfc3315bis/ >>>> Htmlized: >>>> http://tools.ietf.org/html/draft-dhcwg-dhc-rfc3315bis-01 Diff: >>>> http://www.ietf.org/rfcdiff?url2=draft-dhcwg-dhc-rfc3315bis-01 >>>> >>>> Abstract: The Dynamic Host Configuration Protocol for IPv6 >>>> (DHCP) enables DHCP servers to pass configuration parameters >>>> such as IPv6 network addresses to IPv6 nodes. It offers the >>>> capability of automatic allocation of reusable network >>>> addresses and additional configuration flexibility. This >>>> protocol is a stateful counterpart to "IPv6 Stateless Address >>>> Autoconfiguration" (RFC 4862), and can be used separately or >>>> concurrently with the latter to obtain configuration >>>> parameters. >>>> >>>> >>>> >>>> >>>> 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. >>>> >>>> The IETF Secretariat >>>> >>>> _______________________________________________ dhcwg mailing >>>> list dhcwg@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dhcwg >>>> >>> >>> >>> _______________________________________________ dhcwg mailing >>> list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg >> >> >> _______________________________________________ dhcwg mailing list >> dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg > > > From nobody Thu Aug 7 07:54:11 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E71361B2BBE for ; Thu, 7 Aug 2014 07:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 lYejGVqGZfHB for ; Thu, 7 Aug 2014 07:54:08 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C31B31B2B5F for ; Thu, 7 Aug 2014 07:54:08 -0700 (PDT) Received: from [192.168.10.145] (unknown [195.159.143.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id AEF426136; Thu, 7 Aug 2014 07:54:06 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1971.5\)) From: Ole Troan In-Reply-To: <53E39157.8060708@gmail.com> Date: Thu, 7 Aug 2014 16:54:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140519150302.3625.29866.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E1B03125B@xmb-rcd-x04.cisco.com> <53E3872A.30204@gmail.com> <53E38954.1030206@gmail.com> <53E39157.8060708@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1971.5) Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/h2oZxoLGZdsKe-1l_Ub4kJ8X4Eo Cc: dhcwg , Ralph Droms Subject: Re: [dhcwg] draft-dhcwg-dhc-rfc3315bis-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 14:54:10 -0000 Alex, >=20 > I am facing this computer which receives an RA without prefix length = (no Prefix Information OPtion, just helps set the default route), and = then runs DHCPv6 to obtain an IPv6 address A, and the resolver's = address. >=20 > After these messages, the computer configures the IPv6 address as = A/64. >=20 > I wonder where from comes that /64? Is DHCPv6 telling it it should be = a /64? then computer is buggy. RFC5942. cheers, Ole From nobody Thu Aug 7 07:57:47 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 825F91B2BD9 for ; Thu, 7 Aug 2014 07:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 Z7rYNBsykaYb for ; Thu, 7 Aug 2014 07:57:40 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 217411B2BDA for ; Thu, 7 Aug 2014 07:57:25 -0700 (PDT) Received: by mail-qg0-f53.google.com with SMTP id q107so4589110qgd.12 for ; Thu, 07 Aug 2014 07:57:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dSsr3nyJ1Zi1SsY/6+zrC9j3W9BXqJDX3G8+y3KPTW8=; b=me9p/dg+8UWm5qEFPeRE/l6pUnIA2pN1oJJGbQlQT3mwlv90I7d/INnha0VHRlsLEG YMYRYRU+yElPYgKxb3/wRQER2waHpp0IsNBqmtBiIVv4YFn3xI92BRNDdmhcRkrDhxK4 bBsbcBnk/5a/a9H7rWJd3RX/hRvJbHeBTVLPcfGvIYz6l5D1IQB0d/bdf/thR2xke9e1 zZLammhKFUKtt5Y8YBPEI6xqBI8k1i59ymz+DpGBpv1HbxEBq75cjzOD9auikLvfUu6y MV+zVACKlfNYZnkQt/UdMvPcPWGsru/fG7SYVbp1HubHxoMKtyeY20Zi4uU6bcdYJNjt EyXQ== X-Received: by 10.224.103.132 with SMTP id k4mr24132166qao.54.1407423444284; Thu, 07 Aug 2014 07:57:24 -0700 (PDT) Received: from [161.44.68.176] ([161.44.68.176]) by mx.google.com with ESMTPSA id a67sm110234qgf.37.2014.08.07.07.57.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Aug 2014 07:57:22 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ralph Droms In-Reply-To: <53E39157.8060708@gmail.com> Date: Thu, 7 Aug 2014 10:57:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <95EAF349-280B-4414-A66C-B5F748991261@gmail.com> References: <20140519150302.3625.29866.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E1B03125B@xmb-rcd-x04.cisco.com> <53E3872A.30204@gmail.com> <53E38954.1030206@gmail.com> <53E39157.8060708@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/qD-F30eMBQsIB46bI3K6QWc9w2M Cc: dhcwg Subject: Re: [dhcwg] draft-dhcwg-dhc-rfc3315bis-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 14:57:45 -0000 On Aug 7, 2014, at 10:46 AM 8/7/14, Alexandru Petrescu = wrote: > Le 07/08/2014 16:35, Ralph Droms a =C3=A9crit : >>=20 >> On Aug 7, 2014, at 10:12 AM 8/7/14, Alexandru Petrescu >> wrote: >>=20 >>> Ok, so sorry, yes, the 'prefix-length' term is present in >>> draft-3315 -02. >>>=20 >>> Still, I am still wondering: does DHCPv6 assign a prefix length >>> which tags an address? (not prefix delegation). >>=20 >> Assuming you mean "128-bit IPv6 address", the answer is "no". >>=20 >>>=20 >>> Or is the presence of /64 on computers running DHCP a pure >>> invention of the programmer? >>=20 >> I don't understand your question. There is no "prefix length" >> associated with an address. >=20 > I am facing this computer which receives an RA without prefix length = (no Prefix Information OPtion, just helps set the default route), and = then runs DHCPv6 to obtain an IPv6 address A, and the resolver's = address. >=20 > After these messages, the computer configures the IPv6 address as = A/64. >=20 > I wonder where from comes that /64? Is DHCPv6 telling it it should be = a /64? In my opinion, it is a bug in the network stack. The DHCPv6 server has = no knowledge of prefix(es) that might or might not be assigned on the = link to which that interface is attached. The IPv6 address from DHCPv6 = has no associated prefix length. >=20 > Alex >=20 >>=20 >>>=20 >>> Alex >>>=20 >>> Le 07/08/2014 16:03, Alexandru Petrescu a =C3=A9crit : >>>> Hi, >>>>=20 >>>> This draft defines the term 'prefix length' but it never uses it. >>>> Not 'prefix-length' either. >>>>=20 >>>> page 10: >>>>> prefix length The number of bits in a prefix. >>>>=20 >>>> This should be corrected: either one doesn't define it, or one >>>> uses it. >>>>=20 >>>> One example reason is the following. >>>>=20 >>>> I am trying to find a field containing the prefix length of an >>>> assigned address, in a DHCP exchange (IPv4's 'subnet mask') - is >>>> it present or not? Should it or not? The wireshark dump does >>>> not expose any field as "prefix length". (dump available upon >>>> request). Searching the term 'prefix length' in the draft issues >>>> precisely one hit - the definition. >>>>=20 >>>> That DHCP exchange results in the Host assigning a prefix length >>>> 64 on the address on the interface: I am not sure whether it does >>>> so because DHCP tells it so, or otherwise the programmer thought >>>> - as often was the case in other contexts - that the 64 prefix >>>> length is something that should always be there. >>>>=20 >>>> There is no advertised prefix on the link (there is an RA but w/o >>>> RIO). >>>>=20 >>>> Alex >>>>=20 >>>> Le 19/05/2014 17:16, Bernie Volz (volz) a =C3=A9crit : >>>>> The dhcpv6bis team is pleased to have published a revision of >>>>> RFC3315bis work. >>>>>=20 >>>>> This version of the draft: 1. Incorporates the RFC3315 Errata. >>>>> 2. Incorporates the changes made to RFC3315 by other RFCs. 3. >>>>> Addresses other issues raised via email to the original authors >>>>> or the dhcpv6bis team or in other documents (such as =E2=80=8B >>>>> http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-clarify-auth-01). >>>>>=20 >>>>>=20 >>>>>=20 > This mostly covers the Milestone A (apply before merge) tickets - >>>>> see http://trac.tools.ietf.org/group/dhcpv6bis/report/6 (most >>>>> of the tickets resolved are at the bottom in the "A easy, apply >>>>> before merge" category). >>>>>=20 >>>>> This version of the draft does NOT yet cover the merge from RFC >>>>> 3633 (and RFC 3736), though you find a few instances where that >>>>> work was started. Adding this material is the next major goal. >>>>>=20 >>>>> We would appreciate any reviews people can do on this draft - >>>>> please provide comments on what needs to be fixed or you feel >>>>> is not an appropriate change! (Send mail to >>>>> dhcpv6bis@ietf.org). >>>>=20 >>>>=20 >>>>>=20 >>>>> Htmlized: >>>>> http://tools.ietf.org/html/draft-dhcwg-dhc-rfc3315bis-01 Diff: >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-dhcwg-dhc-rfc3315bis-01 >>>>>=20 >>>>> - Bernie (for the dhcpv6bis team) >>>>>=20 >>>>> -----Original Message----- From: internet-drafts@ietf.org >>>>> [mailto:internet-drafts@ietf.org] Sent: Monday, May 19, 2014 >>>>> 11:03 AM To: Andrew Yourtchenko (ayourtch); Bernie Volz (volz); >>>>> Tomek Mrugalski; Bernie Volz (volz); Marcin Siodelski; Michael >>>>> C. Richardson; Sheng Jiang; Ted Lemon; Andrew Yourtchenko >>>>> (ayourtch); Tomek Mrugalski; Sheng Jiang; Marcin Siodelski; >>>>> Michael Richardson; Ted Lemon Subject: New Version Notification >>>>> for draft-dhcwg-dhc-rfc3315bis-01.txt >>>>>=20 >>>>>=20 >>>>> A new version of I-D, draft-dhcwg-dhc-rfc3315bis-01.txt has >>>>> been successfully submitted by Bernie Volz and posted to the >>>>> IETF repository. >>>>>=20 >>>>> Name: draft-dhcwg-dhc-rfc3315bis Revision: 01 Title: >>>>> Dynamic Host Configuration Protocol for IPv6 (DHCPv6) bis >>>>> Document date: 2014-05-19 Group: Individual Submission >>>>> Pages: 108 URL: >>>>> = http://www.ietf.org/internet-drafts/draft-dhcwg-dhc-rfc3315bis-01.txt >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>>=20 > Status: >>>> https://datatracker.ietf.org/doc/draft-dhcwg-dhc-rfc3315bis/ >>>>> Htmlized: >>>>> http://tools.ietf.org/html/draft-dhcwg-dhc-rfc3315bis-01 Diff: >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-dhcwg-dhc-rfc3315bis-01 >>>>>=20 >>>>> Abstract: The Dynamic Host Configuration Protocol for IPv6 >>>>> (DHCP) enables DHCP servers to pass configuration parameters >>>>> such as IPv6 network addresses to IPv6 nodes. It offers the >>>>> capability of automatic allocation of reusable network >>>>> addresses and additional configuration flexibility. This >>>>> protocol is a stateful counterpart to "IPv6 Stateless Address >>>>> Autoconfiguration" (RFC 4862), and can be used separately or >>>>> concurrently with the latter to obtain configuration >>>>> parameters. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> 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. >>>>>=20 >>>>> The IETF Secretariat >>>>>=20 >>>>> _______________________________________________ dhcwg mailing >>>>> list dhcwg@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dhcwg >>>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ dhcwg mailing >>>> list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg >>>=20 >>>=20 >>> _______________________________________________ dhcwg mailing list >>> dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg >>=20 >>=20 >>=20 >=20 >=20 From nobody Thu Aug 7 08:00:51 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E171B2BED for ; Thu, 7 Aug 2014 08:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 0Y31RL6pHWBX for ; Thu, 7 Aug 2014 08:00:45 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A6191B2BD9 for ; Thu, 7 Aug 2014 08:00:40 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s77ExZJZ022443; Thu, 7 Aug 2014 16:59:35 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B2D83200C01; Thu, 7 Aug 2014 17:02:35 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9B4CB204538; Thu, 7 Aug 2014 17:02:35 +0200 (CEST) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s77ExULT030302; Thu, 7 Aug 2014 16:59:34 +0200 Message-ID: <53E39452.5070009@gmail.com> Date: Thu, 07 Aug 2014 16:59:30 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ole Troan References: <20140519150302.3625.29866.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E1B03125B@xmb-rcd-x04.cisco.com> <53E3872A.30204@gmail.com> <53E38954.1030206@gmail.com> <53E39157.8060708@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/-lYeoz_ioiSsuh-WWnoCOyZ_yR0 Cc: dhcwg , Ralph Droms Subject: Re: [dhcwg] draft-dhcwg-dhc-rfc3315bis-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 15:00:47 -0000 Le 07/08/2014 16:54, Ole Troan a crit : > Alex, > >> >> I am facing this computer which receives an RA without prefix length (no Prefix Information OPtion, just helps set the default route), and then runs DHCPv6 to obtain an IPv6 address A, and the resolver's address. >> >> After these messages, the computer configures the IPv6 address as A/64. >> >> I wonder where from comes that /64? Is DHCPv6 telling it it should be a /64? > > then computer is buggy. RFC5942. I have never seen a computer which says 'nil' next to an address when you type ifconfig. There's always a '/' some-figure there, like /64, /128, /0, etc. It's as if you said there is no subnet mask in IPv4. Alex > > cheers, > Ole > > > From nobody Thu Aug 7 08:01:25 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5211D1B2BE8 for ; Thu, 7 Aug 2014 08:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 4TjDxDFYMeGs for ; Thu, 7 Aug 2014 08:01:19 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D73E41B2BD9 for ; Thu, 7 Aug 2014 08:01:18 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id f8so1161215wiw.5 for ; Thu, 07 Aug 2014 08:01:17 -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:date:message-id:subject :from:to:cc:content-type; bh=zcA2pj6DlS2s3J8XtEOUwX0bOdtz14fgrhk7b75zwU0=; b=AMtfdzeh+n7rnnaCF1PZtln5HpRZbSOGl2LIEHij1qO77TEfcLU7Z53YULnGAY/kOj RmvLwstbr9PTG9SapQEenZhQufPi+e7dlAcQoaYyzBjOHYvwpJ6q9oQNIus9tYYE/kkM NbUZVKPl+zBy2DwkRdkj41GVWIaP9QNIaJ3MX7/wl5Hr0xLXUl9IUovivoQEdmrL/A2T nZ4PLnzlCN67XCOWuqJupXWUAWhDWYqjl9YCy/XI3TUnFD5KAsqk2nBFON45yveAY30W hTHb2V/SUlAFBquHNuxBMjiq+fYmkZ8Wf2CORV91pEYc2uIZUMQec7rEESvL8CWPUKE2 pVEQ== MIME-Version: 1.0 X-Received: by 10.194.62.104 with SMTP id x8mr302823wjr.7.1407423677553; Thu, 07 Aug 2014 08:01:17 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.123.164 with HTTP; Thu, 7 Aug 2014 08:01:17 -0700 (PDT) In-Reply-To: <53E39157.8060708@gmail.com> References: <20140519150302.3625.29866.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E1B03125B@xmb-rcd-x04.cisco.com> <53E3872A.30204@gmail.com> <53E38954.1030206@gmail.com> <53E39157.8060708@gmail.com> Date: Thu, 7 Aug 2014 08:01:17 -0700 X-Google-Sender-Auth: 7Ll4ayD-OahetzLRgYxk4vBZZ8w Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Alexandru Petrescu Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/Z2113KdaEFRYaSoFWVrGestKA0E Cc: dhcwg , Ralph Droms Subject: Re: [dhcwg] draft-dhcwg-dhc-rfc3315bis-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 15:01:21 -0000 At Thu, 07 Aug 2014 16:46:47 +0200, Alexandru Petrescu wrote: > I am facing this computer which receives an RA without prefix length (no > Prefix Information OPtion, just helps set the default route), and then > runs DHCPv6 to obtain an IPv6 address A, and the resolver's address. > > After these messages, the computer configures the IPv6 address as A/64. > > I wonder where from comes that /64? Is DHCPv6 telling it it should be a > /64? Perhaps the behavior described in Section 3 of http://tools.ietf.org/html/draft-ietf-6man-why64-01#section-4.4 ? -- JINMEI, Tatuya From nobody Thu Aug 7 08:02:42 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 374F91B2BE1 for ; Thu, 7 Aug 2014 08:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 hEKQxnL8FxkC for ; Thu, 7 Aug 2014 08:02:14 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26D3A1B2BE9 for ; Thu, 7 Aug 2014 08:02:11 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s77F29Bo023312; Thu, 7 Aug 2014 17:02:09 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E40E3203A75; Thu, 7 Aug 2014 17:05:09 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id D85AD200C01; Thu, 7 Aug 2014 17:05:09 +0200 (CEST) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s77F28mE032467; Thu, 7 Aug 2014 17:02:09 +0200 Message-ID: <53E394F0.4060603@gmail.com> Date: Thu, 07 Aug 2014 17:02:08 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ralph Droms References: <20140519150302.3625.29866.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E1B03125B@xmb-rcd-x04.cisco.com> <53E3872A.30204@gmail.com> <53E38954.1030206@gmail.com> <53E39157.8060708@gmail.com> <95EAF349-280B-4414-A66C-B5F748991261@gmail.com> In-Reply-To: <95EAF349-280B-4414-A66C-B5F748991261@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/R8zKaa6VvW5fgcOSMl84X1AVR8c Cc: dhcwg Subject: Re: [dhcwg] draft-dhcwg-dhc-rfc3315bis-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 15:02:18 -0000 Le 07/08/2014 16:57, Ralph Droms a écrit : > > On Aug 7, 2014, at 10:46 AM 8/7/14, Alexandru Petrescu > wrote: > >> Le 07/08/2014 16:35, Ralph Droms a écrit : >>> >>> On Aug 7, 2014, at 10:12 AM 8/7/14, Alexandru Petrescu >>> wrote: >>> >>>> Ok, so sorry, yes, the 'prefix-length' term is present in >>>> draft-3315 -02. >>>> >>>> Still, I am still wondering: does DHCPv6 assign a prefix >>>> length which tags an address? (not prefix delegation). >>> >>> Assuming you mean "128-bit IPv6 address", the answer is "no". >>> >>>> >>>> Or is the presence of /64 on computers running DHCP a pure >>>> invention of the programmer? >>> >>> I don't understand your question. There is no "prefix length" >>> associated with an address. >> >> I am facing this computer which receives an RA without prefix >> length (no Prefix Information OPtion, just helps set the default >> route), and then runs DHCPv6 to obtain an IPv6 address A, and the >> resolver's address. >> >> After these messages, the computer configures the IPv6 address as >> A/64. >> >> I wonder where from comes that /64? Is DHCPv6 telling it it should >> be a /64? > > In my opinion, it is a bug in the network stack. The DHCPv6 server > has no knowledge of prefix(es) that might or might not be assigned on > the link to which that interface is attached. The IPv6 address from > DHCPv6 has no associated prefix length. I tend to agree, but I guess we have room for interpretation whenever 'nothing' is discussed. I guess it would be better if ifconfig said A/128 after a non-PIO-RA DHCP exchange, rather than saying 'nothing', or 'nil'. It shouldn't be saying '64' in any case, I think we agree with that. Alex > >> >> Alex >> >>> >>>> >>>> Alex >>>> >>>> Le 07/08/2014 16:03, Alexandru Petrescu a écrit : >>>>> Hi, >>>>> >>>>> This draft defines the term 'prefix length' but it never uses >>>>> it. Not 'prefix-length' either. >>>>> >>>>> page 10: >>>>>> prefix length The number of bits in a prefix. >>>>> >>>>> This should be corrected: either one doesn't define it, or >>>>> one uses it. >>>>> >>>>> One example reason is the following. >>>>> >>>>> I am trying to find a field containing the prefix length of >>>>> an assigned address, in a DHCP exchange (IPv4's 'subnet >>>>> mask') - is it present or not? Should it or not? The >>>>> wireshark dump does not expose any field as "prefix length". >>>>> (dump available upon request). Searching the term 'prefix >>>>> length' in the draft issues precisely one hit - the >>>>> definition. >>>>> >>>>> That DHCP exchange results in the Host assigning a prefix >>>>> length 64 on the address on the interface: I am not sure >>>>> whether it does so because DHCP tells it so, or otherwise the >>>>> programmer thought - as often was the case in other contexts >>>>> - that the 64 prefix length is something that should always >>>>> be there. >>>>> >>>>> There is no advertised prefix on the link (there is an RA but >>>>> w/o RIO). >>>>> >>>>> Alex >>>>> >>>>> Le 19/05/2014 17:16, Bernie Volz (volz) a écrit : >>>>>> The dhcpv6bis team is pleased to have published a revision >>>>>> of RFC3315bis work. >>>>>> >>>>>> This version of the draft: 1. Incorporates the RFC3315 >>>>>> Errata. 2. Incorporates the changes made to RFC3315 by >>>>>> other RFCs. 3. Addresses other issues raised via email to >>>>>> the original authors or the dhcpv6bis team or in other >>>>>> documents (such as ​ >>>>>> http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-clarify-auth-01). >>>>>> >>>>>> >>>>>> >> >>>>>> This mostly covers the Milestone A (apply before merge) tickets - >>>>>> see http://trac.tools.ietf.org/group/dhcpv6bis/report/6 >>>>>> (most of the tickets resolved are at the bottom in the "A >>>>>> easy, apply before merge" category). >>>>>> >>>>>> This version of the draft does NOT yet cover the merge from >>>>>> RFC 3633 (and RFC 3736), though you find a few instances >>>>>> where that work was started. Adding this material is the >>>>>> next major goal. >>>>>> >>>>>> We would appreciate any reviews people can do on this draft >>>>>> - please provide comments on what needs to be fixed or you >>>>>> feel is not an appropriate change! (Send mail to >>>>>> dhcpv6bis@ietf.org). >>>>> >>>>> >>>>>> >>>>>> Htmlized: >>>>>> http://tools.ietf.org/html/draft-dhcwg-dhc-rfc3315bis-01 >>>>>> Diff: >>>>>> http://www.ietf.org/rfcdiff?url2=draft-dhcwg-dhc-rfc3315bis-01 >>>>>> >>>>>> >>>>>> - Bernie (for the dhcpv6bis team) >>>>>> >>>>>> -----Original Message----- From: internet-drafts@ietf.org >>>>>> [mailto:internet-drafts@ietf.org] Sent: Monday, May 19, >>>>>> 2014 11:03 AM To: Andrew Yourtchenko (ayourtch); Bernie >>>>>> Volz (volz); Tomek Mrugalski; Bernie Volz (volz); Marcin >>>>>> Siodelski; Michael C. Richardson; Sheng Jiang; Ted Lemon; >>>>>> Andrew Yourtchenko (ayourtch); Tomek Mrugalski; Sheng >>>>>> Jiang; Marcin Siodelski; Michael Richardson; Ted Lemon >>>>>> Subject: New Version Notification for >>>>>> draft-dhcwg-dhc-rfc3315bis-01.txt >>>>>> >>>>>> >>>>>> A new version of I-D, draft-dhcwg-dhc-rfc3315bis-01.txt >>>>>> has been successfully submitted by Bernie Volz and posted >>>>>> to the IETF repository. >>>>>> >>>>>> Name: draft-dhcwg-dhc-rfc3315bis Revision: 01 >>>>>> Title: Dynamic Host Configuration Protocol for IPv6 >>>>>> (DHCPv6) bis Document date: 2014-05-19 Group: >>>>>> Individual Submission Pages: 108 URL: >>>>>> http://www.ietf.org/internet-drafts/draft-dhcwg-dhc-rfc3315bis-01.txt >>>>>> >>>>>> >>>>>> >>>>> >>>>>> >> >>>>>> Status: >>>>> https://datatracker.ietf.org/doc/draft-dhcwg-dhc-rfc3315bis/ >>>>>> Htmlized: >>>>>> http://tools.ietf.org/html/draft-dhcwg-dhc-rfc3315bis-01 >>>>>> Diff: >>>>>> http://www.ietf.org/rfcdiff?url2=draft-dhcwg-dhc-rfc3315bis-01 >>>>>> >>>>>> >>>>>> Abstract: The Dynamic Host Configuration Protocol for IPv6 >>>>>> (DHCP) enables DHCP servers to pass configuration >>>>>> parameters such as IPv6 network addresses to IPv6 nodes. >>>>>> It offers the capability of automatic allocation of >>>>>> reusable network addresses and additional configuration >>>>>> flexibility. This protocol is a stateful counterpart to >>>>>> "IPv6 Stateless Address Autoconfiguration" (RFC 4862), and >>>>>> can be used separately or concurrently with the latter to >>>>>> obtain configuration parameters. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 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. >>>>>> >>>>>> The IETF Secretariat >>>>>> >>>>>> _______________________________________________ dhcwg >>>>>> mailing list dhcwg@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dhcwg >>>>>> >>>>> >>>>> >>>>> _______________________________________________ dhcwg >>>>> mailing list dhcwg@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dhcwg >>>> >>>> >>>> _______________________________________________ dhcwg mailing >>>> list dhcwg@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dhcwg >>> >>> >>> >> >> > > > From nobody Thu Aug 7 08:06:03 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEA461B2BD3 for ; Thu, 7 Aug 2014 08:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 kW4jVvok1PP2 for ; Thu, 7 Aug 2014 08:05:59 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B7CD1B2BDA for ; Thu, 7 Aug 2014 08:05:30 -0700 (PDT) Received: by mail-qg0-f49.google.com with SMTP id j107so4517415qga.22 for ; Thu, 07 Aug 2014 08:05:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GFqT05YsLb2cq6qpJDOTT0+rdxrJoNxHuE9xnq/SHNg=; b=yLecRyGRRi90rcVzOnO63SUAd5BOpWsBnrBs3pOUnm9d0LWbKGEhfiZq6r2j2Jv12W udmP7Z9PSekJ4mUtIjpFpc/YbRo37+3Ivi5h9mglNic0OLOpLM0+Np6sDaT0ZUaiK0Nq vN4dOHxByX3bBWwNvYTbpHPqAUDAa1/lVYMfG3lL4dQLtWZfGKTkdNbw9TDFpVsJGnhD xYQZ1PONg4gFug9OJzVTLWibP13Ybyi30JDLh5EKl3JZ7t/Zf884y4yVKIwI/oMvcuO5 jMKZXRjmOrL2SnjjSDfQmESIIxC/09V7G3FYakVg8Duu8Go63dMVdyYy6ZeCLVNs1FPN mR0w== X-Received: by 10.140.38.169 with SMTP id t38mr14578244qgt.3.1407423929300; Thu, 07 Aug 2014 08:05:29 -0700 (PDT) Received: from ?IPv6:2001:420:2c52:1316:5f:e35e:e670:c48f? ([2001:420:2c52:1316:5f:e35e:e670:c48f]) by mx.google.com with ESMTPSA id j65sm148375qgf.22.2014.08.07.08.05.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Aug 2014 08:05:27 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ralph Droms In-Reply-To: <53E39452.5070009@gmail.com> Date: Thu, 7 Aug 2014 11:05:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <05436D86-123D-4BB8-A0D4-BAF62664046C@gmail.com> References: <20140519150302.3625.29866.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E1B03125B@xmb-rcd-x04.cisco.com> <53E3872A.30204@gmail.com> <53E38954.1030206@gmail.com> <53E39157.8060708@gmail.com> <53E39452.5070009@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/wedR8fMDuZqtjHSwtGAkXayFLTk Cc: dhcwg Subject: Re: [dhcwg] draft-dhcwg-dhc-rfc3315bis-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 15:06:01 -0000 On Aug 7, 2014, at 10:59 AM 8/7/14, Alexandru Petrescu = wrote: > Le 07/08/2014 16:54, Ole Troan a =E9crit : >> Alex, >>=20 >>>=20 >>> I am facing this computer which receives an RA without prefix length = (no Prefix Information OPtion, just helps set the default route), and = then runs DHCPv6 to obtain an IPv6 address A, and the resolver's = address. >>>=20 >>> After these messages, the computer configures the IPv6 address as = A/64. >>>=20 >>> I wonder where from comes that /64? Is DHCPv6 telling it it should = be a /64? >>=20 >> then computer is buggy. RFC5942. >=20 > I have never seen a computer which says 'nil' next to an address when = you type ifconfig. There's always a '/' some-figure there, like /64, = /128, /0, etc. Were it up to me, I would report the addresses without a prefix length, = and report all known assigned prefixes separately. >=20 > It's as if you said there is no subnet mask in IPv4. The subnet mask in IPv4 is used to infer prefixes assigned to a link. = IPv6 explicitly assigns links to prefixes and announces those prefixes = through RAs. Because of the explicit announcements, there is no need to = imply prefixes through subnet masks. >=20 > Alex >=20 >>=20 >> cheers, >> Ole >>=20 >>=20 >>=20 >=20 >=20 From nobody Thu Aug 7 08:07:41 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F481B2BD5 for ; Thu, 7 Aug 2014 08:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.683 X-Spam-Level: X-Spam-Status: No, score=-4.683 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 Xtw40Ft0dl0J for ; Thu, 7 Aug 2014 08:07:36 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CD7F1B2BA0 for ; Thu, 7 Aug 2014 08:07:36 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s77F7Y0e024981; Thu, 7 Aug 2014 17:07:34 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id ABC5D204500; Thu, 7 Aug 2014 17:10:34 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 946262041AE; Thu, 7 Aug 2014 17:10:34 +0200 (CEST) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s77F7XqT003872; Thu, 7 Aug 2014 17:07:34 +0200 Message-ID: <53E39635.60608@gmail.com> Date: Thu, 07 Aug 2014 17:07:33 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: =?UTF-8?B?56We5piO6YGU5ZOJ?= References: <20140519150302.3625.29866.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E1B03125B@xmb-rcd-x04.cisco.com> <53E3872A.30204@gmail.com> <53E38954.1030206@gmail.com> <53E39157.8060708@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/NzXjdz5t7FX_zCseMDmT0yj1ZGc Cc: dhcwg , Ralph Droms Subject: Re: [dhcwg] draft-dhcwg-dhc-rfc3315bis-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 15:07:40 -0000 Le 07/08/2014 17:01, 神明達哉 a écrit : > At Thu, 07 Aug 2014 16:46:47 +0200, > Alexandru Petrescu wrote: > >> I am facing this computer which receives an RA without prefix length (no >> Prefix Information OPtion, just helps set the default route), and then >> runs DHCPv6 to obtain an IPv6 address A, and the resolver's address. >> >> After these messages, the computer configures the IPv6 address as A/64. >> >> I wonder where from comes that /64? Is DHCPv6 telling it it should be a >> /64? > > Perhaps the behavior described in Section 3 of > http://tools.ietf.org/html/draft-ietf-6man-why64-01#section-4.4 ? Thanks for pointing out that section. I am surprised to discover it, although I am a co-author of this draft. As I read it I think it is very true. That aside, I wonder why programmers have set that 64 in the kernel data absent a prefix length field in DHCP/RA, if not because of the fact that specifications are lacking. Were it for DHCPv6 to have a prefix length field for assigned address A, then programmer would be clearer of what to put on that field, I think. Alex > -- > JINMEI, Tatuya > > From nobody Thu Aug 7 08:10:28 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE8D1B2C29 for ; Thu, 7 Aug 2014 08:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 ntPMzL_xdxl4 for ; Thu, 7 Aug 2014 08:10:14 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9B241B2C24 for ; Thu, 7 Aug 2014 08:10:12 -0700 (PDT) Received: from [192.168.10.145] (unknown [195.159.143.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 7300B6155; Thu, 7 Aug 2014 08:10:11 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1971.5\)) From: Ole Troan In-Reply-To: <53E39635.60608@gmail.com> Date: Thu, 7 Aug 2014 17:10:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3FF74A8E-B432-4813-B164-ED47A2CF5779@employees.org> References: <20140519150302.3625.29866.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E1B03125B@xmb-rcd-x04.cisco.com> <53E3872A.30204@gmail.com> <53E38954.1030206@gmail.com> <53E39157.8060708@gmail.com> <53E39635.60608@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1971.5) Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/YGHM4JZtIWJR_zFkxep-yh8Ft8I Cc: dhcwg , =?utf-8?B?56We5piO6YGU5ZOJ?= , Ralph Droms Subject: Re: [dhcwg] draft-dhcwg-dhc-rfc3315bis-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 15:10:21 -0000 > That aside, I wonder why programmers have set that 64 in the kernel = data absent a prefix length field in DHCP/RA, if not because of the fact = that specifications are lacking. Were it for DHCPv6 to have a prefix = length field for assigned address A, then programmer would be clearer of = what to put on that field, I think. address assignment and onlink determination are two quite separate = things. cheers, Ole From nobody Thu Aug 7 08:10:30 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C28281B2C24 for ; Thu, 7 Aug 2014 08:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 aGymKlNN_BNX for ; Thu, 7 Aug 2014 08:10:20 -0700 (PDT) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DB271B2C23 for ; Thu, 7 Aug 2014 08:10:14 -0700 (PDT) Received: by mail-pd0-f177.google.com with SMTP id p10so5295680pdj.8 for ; Thu, 07 Aug 2014 08:10:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ucrwRMjb+7QcSPmWHVUH1Q0q/5fo9l34GWoZMXt+IlI=; b=E+Whxa4fM2CMMpCIuplRzARFYXQ/IwWsWrp0TvYPbrwdY7ikYvC0qzNVPWNJUN8Ofs R+GsDH8QQgv5urO+wUKBxZEXRKMyyGlH3zm8/F5U0mgwED+/r/PZS4xnd7biM1+9xKsT cHvWpf2KzYGVT3qsyK3VxSr6wIghimr2erubiC9H2ghFOZ/0v7UvBABcpm24ht+0Y8Yy 5siNZPI4FVbEic/55iOA0b9nOGe6D1J21KpE7rXU0l5RgeeCBwA3yinTWSH4p/6foTMt PdVNAThCRmEP11G0Nm3pk7Ld9NxZC445IaEH9n3xEy8KyPabY8Q9gMerFZRFXDkSk251 VYRQ== X-Received: by 10.70.91.73 with SMTP id cc9mr3053924pdb.138.1407424214175; Thu, 07 Aug 2014 08:10:14 -0700 (PDT) Received: from ?IPv6:2001:420:2c52:1316:5f:e35e:e670:c48f? ([2001:420:2c52:1316:5f:e35e:e670:c48f]) by mx.google.com with ESMTPSA id i2sm25169pdk.70.2014.08.07.08.10.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Aug 2014 08:10:10 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ralph Droms In-Reply-To: <53E394F0.4060603@gmail.com> Date: Thu, 7 Aug 2014 11:10:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140519150302.3625.29866.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E1B03125B@xmb-rcd-x04.cisco.com> <53E3872A.30204@gmail.com> <53E38954.1030206@gmail.com> <53E39157.8060708@gmail.com> <95EAF349-280B-4414-A66C-B5F748991261@gmail.com> <53E394F0.4060603@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/Pb9CsWa38YTYJeabDvNXR8YTSLY Cc: dhcwg Subject: Re: [dhcwg] draft-dhcwg-dhc-rfc3315bis-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 15:10:22 -0000 On Aug 7, 2014, at 11:02 AM 8/7/14, Alexandru Petrescu = wrote: > Le 07/08/2014 16:57, Ralph Droms a =C3=A9crit : >>=20 >> On Aug 7, 2014, at 10:46 AM 8/7/14, Alexandru Petrescu >> wrote: >>=20 >>> Le 07/08/2014 16:35, Ralph Droms a =C3=A9crit : >>>>=20 >>>> On Aug 7, 2014, at 10:12 AM 8/7/14, Alexandru Petrescu >>>> wrote: >>>>=20 >>>>> Ok, so sorry, yes, the 'prefix-length' term is present in >>>>> draft-3315 -02. >>>>>=20 >>>>> Still, I am still wondering: does DHCPv6 assign a prefix >>>>> length which tags an address? (not prefix delegation). >>>>=20 >>>> Assuming you mean "128-bit IPv6 address", the answer is "no". >>>>=20 >>>>>=20 >>>>> Or is the presence of /64 on computers running DHCP a pure >>>>> invention of the programmer? >>>>=20 >>>> I don't understand your question. There is no "prefix length" >>>> associated with an address. >>>=20 >>> I am facing this computer which receives an RA without prefix >>> length (no Prefix Information OPtion, just helps set the default >>> route), and then runs DHCPv6 to obtain an IPv6 address A, and the >>> resolver's address. >>>=20 >>> After these messages, the computer configures the IPv6 address as >>> A/64. >>>=20 >>> I wonder where from comes that /64? Is DHCPv6 telling it it should >>> be a /64? >>=20 >> In my opinion, it is a bug in the network stack. The DHCPv6 server >> has no knowledge of prefix(es) that might or might not be assigned on >> the link to which that interface is attached. The IPv6 address from >> DHCPv6 has no associated prefix length. >=20 > I tend to agree, but I guess we have room for interpretation whenever = 'nothing' is discussed. >=20 > I guess it would be better if ifconfig said A/128 after a non-PIO-RA = DHCP exchange, rather than saying 'nothing', or 'nil'. >=20 > It shouldn't be saying '64' in any case, I think we agree with that. See my previous e-mail. In my opinion, a list of addresses with no = prefix length and a list of prefixes with prefix lengths would be most = correct. In the case you described, with no prefixes announced in RAs, the host = has no knowledge of on-link prefixes and would simply list the assigned = addresses. That host will forward all traffic (other than link-local) = to the default router. >=20 > Alex >=20 >>=20 >>>=20 >>> Alex >>>=20 >>>>=20 >>>>>=20 >>>>> Alex >>>>>=20 >>>>> Le 07/08/2014 16:03, Alexandru Petrescu a =C3=A9crit : >>>>>> Hi, >>>>>>=20 >>>>>> This draft defines the term 'prefix length' but it never uses >>>>>> it. Not 'prefix-length' either. >>>>>>=20 >>>>>> page 10: >>>>>>> prefix length The number of bits in a prefix. >>>>>>=20 >>>>>> This should be corrected: either one doesn't define it, or >>>>>> one uses it. >>>>>>=20 >>>>>> One example reason is the following. >>>>>>=20 >>>>>> I am trying to find a field containing the prefix length of >>>>>> an assigned address, in a DHCP exchange (IPv4's 'subnet >>>>>> mask') - is it present or not? Should it or not? The >>>>>> wireshark dump does not expose any field as "prefix length". >>>>>> (dump available upon request). Searching the term 'prefix >>>>>> length' in the draft issues precisely one hit - the >>>>>> definition. >>>>>>=20 >>>>>> That DHCP exchange results in the Host assigning a prefix >>>>>> length 64 on the address on the interface: I am not sure >>>>>> whether it does so because DHCP tells it so, or otherwise the >>>>>> programmer thought - as often was the case in other contexts >>>>>> - that the 64 prefix length is something that should always >>>>>> be there. >>>>>>=20 >>>>>> There is no advertised prefix on the link (there is an RA but >>>>>> w/o RIO). >>>>>>=20 >>>>>> Alex >>>>>>=20 >>>>>> Le 19/05/2014 17:16, Bernie Volz (volz) a =C3=A9crit : >>>>>>> The dhcpv6bis team is pleased to have published a revision >>>>>>> of RFC3315bis work. >>>>>>>=20 >>>>>>> This version of the draft: 1. Incorporates the RFC3315 >>>>>>> Errata. 2. Incorporates the changes made to RFC3315 by >>>>>>> other RFCs. 3. Addresses other issues raised via email to >>>>>>> the original authors or the dhcpv6bis team or in other >>>>>>> documents (such as =E2=80=8B >>>>>>> = http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-clarify-auth-01). >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>=20 >>>>>>>=20 > This mostly covers the Milestone A (apply before merge) tickets - >>>>>>> see http://trac.tools.ietf.org/group/dhcpv6bis/report/6 >>>>>>> (most of the tickets resolved are at the bottom in the "A >>>>>>> easy, apply before merge" category). >>>>>>>=20 >>>>>>> This version of the draft does NOT yet cover the merge from >>>>>>> RFC 3633 (and RFC 3736), though you find a few instances >>>>>>> where that work was started. Adding this material is the >>>>>>> next major goal. >>>>>>>=20 >>>>>>> We would appreciate any reviews people can do on this draft >>>>>>> - please provide comments on what needs to be fixed or you >>>>>>> feel is not an appropriate change! (Send mail to >>>>>>> dhcpv6bis@ietf.org). >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> Htmlized: >>>>>>> http://tools.ietf.org/html/draft-dhcwg-dhc-rfc3315bis-01 >>>>>>> Diff: >>>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-dhcwg-dhc-rfc3315bis-01 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 > - Bernie (for the dhcpv6bis team) >>>>>>>=20 >>>>>>> -----Original Message----- From: internet-drafts@ietf.org >>>>>>> [mailto:internet-drafts@ietf.org] Sent: Monday, May 19, >>>>>>> 2014 11:03 AM To: Andrew Yourtchenko (ayourtch); Bernie >>>>>>> Volz (volz); Tomek Mrugalski; Bernie Volz (volz); Marcin >>>>>>> Siodelski; Michael C. Richardson; Sheng Jiang; Ted Lemon; >>>>>>> Andrew Yourtchenko (ayourtch); Tomek Mrugalski; Sheng >>>>>>> Jiang; Marcin Siodelski; Michael Richardson; Ted Lemon >>>>>>> Subject: New Version Notification for >>>>>>> draft-dhcwg-dhc-rfc3315bis-01.txt >>>>>>>=20 >>>>>>>=20 >>>>>>> A new version of I-D, draft-dhcwg-dhc-rfc3315bis-01.txt >>>>>>> has been successfully submitted by Bernie Volz and posted >>>>>>> to the IETF repository. >>>>>>>=20 >>>>>>> Name: draft-dhcwg-dhc-rfc3315bis Revision: 01 >>>>>>> Title: Dynamic Host Configuration Protocol for IPv6 >>>>>>> (DHCPv6) bis Document date: 2014-05-19 Group: >>>>>>> Individual Submission Pages: 108 URL: >>>>>>> = http://www.ietf.org/internet-drafts/draft-dhcwg-dhc-rfc3315bis-01.txt >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>=20 >>>>>>>=20 > Status: >>>>>> https://datatracker.ietf.org/doc/draft-dhcwg-dhc-rfc3315bis/ >>>>>>> Htmlized: >>>>>>> http://tools.ietf.org/html/draft-dhcwg-dhc-rfc3315bis-01 >>>>>>> Diff: >>>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-dhcwg-dhc-rfc3315bis-01 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 > Abstract: The Dynamic Host Configuration Protocol for IPv6 >>>>>>> (DHCP) enables DHCP servers to pass configuration >>>>>>> parameters such as IPv6 network addresses to IPv6 nodes. >>>>>>> It offers the capability of automatic allocation of >>>>>>> reusable network addresses and additional configuration >>>>>>> flexibility. This protocol is a stateful counterpart to >>>>>>> "IPv6 Stateless Address Autoconfiguration" (RFC 4862), and >>>>>>> can be used separately or concurrently with the latter to >>>>>>> obtain configuration parameters. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> The IETF Secretariat >>>>>>>=20 >>>>>>> _______________________________________________ dhcwg >>>>>>> mailing list dhcwg@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dhcwg >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ dhcwg >>>>>> mailing list dhcwg@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dhcwg >>>>>=20 >>>>>=20 >>>>> _______________________________________________ dhcwg mailing >>>>> list dhcwg@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dhcwg >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >>=20 >=20 >=20 From nobody Thu Aug 7 08:12:23 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CCE91B2C95 for ; Thu, 7 Aug 2014 08:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 OveRJxhuT_QU for ; Thu, 7 Aug 2014 08:12:12 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBD541B2C37 for ; Thu, 7 Aug 2014 08:11:47 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id ey11so5531062pad.24 for ; Thu, 07 Aug 2014 08:11:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RRBiWBQ0V68Xu2VOIg7mW6bDmh4oJ3Gk6443+MkZcg0=; b=ikTUQae4Wkpvg+0INFlVDABB6WMK5LLbnvnQScQj5u6Ns+tUtoU3m9gayroOWvIxiW OQ3PnbEsTVifE4uUFk1Xw0oXj1wgFysAgc/5Tu2i0iIsHsadmK2z1bQrIjdNctjeusZq kHYEZOCMePc8gna12NjPTKtewAi36e/LiQB7ThYEKQh4DMSiAc2s9XMEcnRmpq1FZiHM snCa5sXJ2djjS9Bx8ortGEUaB4pH7ZnYaIDcgkj4IgozEJMhfgMyzMf3o/OIzH1qfdbB mSBG/3xv5tgRfiog17danZcnRFSvlXVJYTMt5XtBeiQMuyYLJ71BrxY3caAyQNRNMNMZ PQOw== X-Received: by 10.66.227.170 with SMTP id sb10mr18309224pac.56.1407424307475; Thu, 07 Aug 2014 08:11:47 -0700 (PDT) Received: from [161.44.68.176] ([161.44.68.176]) by mx.google.com with ESMTPSA id qy8sm15522368pab.12.2014.08.07.08.11.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Aug 2014 08:11:45 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ralph Droms In-Reply-To: <53E39635.60608@gmail.com> Date: Thu, 7 Aug 2014 11:11:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140519150302.3625.29866.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E1B03125B@xmb-rcd-x04.cisco.com> <53E3872A.30204@gmail.com> <53E38954.1030206@gmail.com> <53E39157.8060708@gmail.com> <53E39635.60608@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/MyH4HSNQcrwiOHbeN-156GWbPcw Cc: dhcwg , =?utf-8?B?56We5piO6YGU5ZOJ?= Subject: Re: [dhcwg] draft-dhcwg-dhc-rfc3315bis-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 15:12:14 -0000 On Aug 7, 2014, at 11:07 AM 8/7/14, Alexandru Petrescu = wrote: > Le 07/08/2014 17:01, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 a =C3=A9crit = : >> At Thu, 07 Aug 2014 16:46:47 +0200, >> Alexandru Petrescu wrote: >>=20 >>> I am facing this computer which receives an RA without prefix length = (no >>> Prefix Information OPtion, just helps set the default route), and = then >>> runs DHCPv6 to obtain an IPv6 address A, and the resolver's address. >>>=20 >>> After these messages, the computer configures the IPv6 address as = A/64. >>>=20 >>> I wonder where from comes that /64? Is DHCPv6 telling it it should = be a >>> /64? >>=20 >> Perhaps the behavior described in Section 3 of >> http://tools.ietf.org/html/draft-ietf-6man-why64-01#section-4.4 ? >=20 > Thanks for pointing out that section. I am surprised to discover it, = although I am a co-author of this draft. As I read it I think it is = very true. >=20 > That aside, I wonder why programmers have set that 64 in the kernel = data absent a prefix length field in DHCP/RA, if not because of the fact = that specifications are lacking. Were it for DHCPv6 to have a prefix = length field for assigned address A, then programmer would be clearer of = what to put on that field, I think. Does anyone know what the field is used for? The prefix length on the = prefix should be used for forwarding rules, not any length on the = address, right? >=20 > Alex >=20 >> -- >> JINMEI, Tatuya >>=20 >>=20 >=20 >=20 From nobody Thu Aug 7 08:17:17 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBDC81B2C97 for ; Thu, 7 Aug 2014 08:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 Um0bsV2Uw1T6 for ; Thu, 7 Aug 2014 08:17:14 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A93371B2D17 for ; Thu, 7 Aug 2014 08:17:13 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s77FF8dB006939; Thu, 7 Aug 2014 17:15:08 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id DDDB7202959; Thu, 7 Aug 2014 17:18:08 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id CFF8B20142D; Thu, 7 Aug 2014 17:18:08 +0200 (CEST) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s77FF3wY009477; Thu, 7 Aug 2014 17:15:08 +0200 Message-ID: <53E397F7.4070901@gmail.com> Date: Thu, 07 Aug 2014 17:15:03 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ralph Droms References: <20140519150302.3625.29866.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E1B03125B@xmb-rcd-x04.cisco.com> <53E3872A.30204@gmail.com> <53E38954.1030206@gmail.com> <53E39157.8060708@gmail.com> <53E39452.5070009@gmail.com> <05436D86-123D-4BB8-A0D4-BAF62664046C@gmail.com> In-Reply-To: <05436D86-123D-4BB8-A0D4-BAF62664046C@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/hYyZYNoRD3zV6KsIVMh0g6oEZOI Cc: dhcwg Subject: Re: [dhcwg] draft-dhcwg-dhc-rfc3315bis-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 15:17:16 -0000 Le 07/08/2014 17:05, Ralph Droms a crit : > > On Aug 7, 2014, at 10:59 AM 8/7/14, Alexandru Petrescu > wrote: > >> Le 07/08/2014 16:54, Ole Troan a crit : >>> Alex, >>> >>>> >>>> I am facing this computer which receives an RA without prefix >>>> length (no Prefix Information OPtion, just helps set the >>>> default route), and then runs DHCPv6 to obtain an IPv6 address >>>> A, and the resolver's address. >>>> >>>> After these messages, the computer configures the IPv6 address >>>> as A/64. >>>> >>>> I wonder where from comes that /64? Is DHCPv6 telling it it >>>> should be a /64? >>> >>> then computer is buggy. RFC5942. >> >> I have never seen a computer which says 'nil' next to an address >> when you type ifconfig. There's always a '/' some-figure there, >> like /64, /128, /0, etc. > > Were it up to me, I would report the addresses without a prefix > length, and report all known assigned prefixes separately. Sounds reasonable. And thus the relationship between the assigned address and the prefix valid on that link would still be variable (i.e. the address is part of that prefix, or not). >> It's as if you said there is no subnet mask in IPv4. > > The subnet mask in IPv4 is used to infer prefixes assigned to a link. > IPv6 explicitly assigns links to prefixes and announces those > prefixes through RAs. Yes, and no: prefixes are not always announced on links. The PIO (prefix information option) is not mandatory in RAs, I guess, because of the name 'option'. I just received many RAs without any PIO. This is on a cellular link. The RA just gives its src address (to use as default route) and the MTU (such as to not trigger fragmentation). Alex > Because of the explicit announcements, there > is no need to imply prefixes through subnet masks. > >> >> Alex >> >>> >>> cheers, Ole >>> >>> >>> >> >> > > > From nobody Thu Aug 7 08:20:32 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF1B1B2D2B for ; Thu, 7 Aug 2014 08:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 TUaRZmfeW920 for ; Thu, 7 Aug 2014 08:20:28 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EFFD1B2C47 for ; Thu, 7 Aug 2014 08:20:28 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s77FKQZ3029160; Thu, 7 Aug 2014 17:20:26 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E6E97204551; Thu, 7 Aug 2014 17:23:26 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id D8D6E204527; Thu, 7 Aug 2014 17:23:26 +0200 (CEST) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s77FKPYv012956; Thu, 7 Aug 2014 17:20:26 +0200 Message-ID: <53E39939.9000201@gmail.com> Date: Thu, 07 Aug 2014 17:20:25 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ralph Droms References: <20140519150302.3625.29866.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E1B03125B@xmb-rcd-x04.cisco.com> <53E3872A.30204@gmail.com> <53E38954.1030206@gmail.com> <53E39157.8060708@gmail.com> <53E39635.60608@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/kd68LD4Rn6In1D8K2o-sJMOq7jA Cc: dhcwg , =?UTF-8?B?56We5piO6YGU5ZOJ?= Subject: Re: [dhcwg] draft-dhcwg-dhc-rfc3315bis-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 15:20:30 -0000 Le 07/08/2014 17:11, Ralph Droms a écrit : > > On Aug 7, 2014, at 11:07 AM 8/7/14, Alexandru Petrescu > wrote: > >> Le 07/08/2014 17:01, 神明達哉 a écrit : >>> At Thu, 07 Aug 2014 16:46:47 +0200, Alexandru Petrescu >>> wrote: >>> >>>> I am facing this computer which receives an RA without prefix >>>> length (no Prefix Information OPtion, just helps set the >>>> default route), and then runs DHCPv6 to obtain an IPv6 address >>>> A, and the resolver's address. >>>> >>>> After these messages, the computer configures the IPv6 address >>>> as A/64. >>>> >>>> I wonder where from comes that /64? Is DHCPv6 telling it it >>>> should be a /64? >>> >>> Perhaps the behavior described in Section 3 of >>> http://tools.ietf.org/html/draft-ietf-6man-why64-01#section-4.4 >>> ? >> >> Thanks for pointing out that section. I am surprised to discover >> it, although I am a co-author of this draft. As I read it I think >> it is very true. >> >> That aside, I wonder why programmers have set that 64 in the kernel >> data absent a prefix length field in DHCP/RA, if not because of the >> fact that specifications are lacking. Were it for DHCPv6 to have a >> prefix length field for assigned address A, then programmer would >> be clearer of what to put on that field, I think. > > Does anyone know what the field is used for? It helps extract from the address the prefix and its length, and then insert a routing table entry. This becomes a 'Connected' route in some manufacturer's parlance. It is a '*' route in linux (no next-hop). On all address of it one has to run ND to find its MAC address, otherwise use the default route. > The prefix length on the prefix should be used for forwarding rules, > not any length on the address, right? YEs, but forwarding is preceded by ND: ND needs the MAC address of the default route next-hop, otherwise ND needs the MAC address of the dst in the packet. This has to do with the order in which NCache is searched and the routing table is searched. The NC is using an exact match search, the other is longest match... Sigh about too much detail ... Alex > > >> >> Alex >> >>> -- JINMEI, Tatuya >>> >>> >> >> > > > From nobody Thu Aug 7 09:24:45 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00BF71B2E06 for ; Thu, 7 Aug 2014 09:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 k_IkvohWN7wd for ; Thu, 7 Aug 2014 09:24:37 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 625251B2DDE for ; Thu, 7 Aug 2014 09:24:34 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id m15so4420697wgh.17 for ; Thu, 07 Aug 2014 09:24:33 -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:date:message-id:subject :from:to:cc:content-type; bh=X4g2R+g/9bq2m5RGUssyksHR/iiH0ulWAHZJUYKKNMA=; b=qPitvzmNJNM5Df54ZKXDhhE7KX2eKOZjp8vhUkdMUGgw5IhzeW9MOkgcpLghIRSTmn UDekdc4VYfYyXLWSi5uWZjxITH6pqfzQCCiBgIE9a9qDsnIeJ5nP95uuj/MmwUORCDKd EHVlcRsBV6rha8NnaV+hBb3ZFoGLug1IPPaatNDUA4Bv/kTew9h0JTgU3bTUeaO+C7ex QU7XxJ5B7JZe0QxaC7FZeAdP2dONkVF9m3P0o1B1cIjqKmeD6NZNhdVqs4o8kUvMEpRf 7e0m6uYgzS2GIApPAtXPOj/V0eVZSqIw5TAjSlLxKk0uuC36eyTftcdICteo6lV9F9UN 027Q== MIME-Version: 1.0 X-Received: by 10.180.12.38 with SMTP id v6mr17719723wib.31.1407428672914; Thu, 07 Aug 2014 09:24:32 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.123.164 with HTTP; Thu, 7 Aug 2014 09:24:32 -0700 (PDT) In-Reply-To: <53E39635.60608@gmail.com> References: <20140519150302.3625.29866.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E1B03125B@xmb-rcd-x04.cisco.com> <53E3872A.30204@gmail.com> <53E38954.1030206@gmail.com> <53E39157.8060708@gmail.com> <53E39635.60608@gmail.com> Date: Thu, 7 Aug 2014 09:24:32 -0700 X-Google-Sender-Auth: 0ZIIsBXVPi2v9kYKk7oqdZ5eqdc Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Alexandru Petrescu Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/oB8g69g0O4upP_8RuoU8NlHtyGo Cc: dhcwg , Ralph Droms Subject: Re: [dhcwg] draft-dhcwg-dhc-rfc3315bis-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 16:24:39 -0000 At Thu, 07 Aug 2014 17:07:33 +0200, Alexandru Petrescu wrote: > That aside, I wonder why programmers have set that 64 in the kernel data > absent a prefix length field in DHCP/RA, if not because of the fact that > specifications are lacking. Were it for DHCPv6 to have a prefix length > field for assigned address A, then programmer would be clearer of what > to put on that field, I think. I guess you're basically re-raising a long standing discussion of whether to provide an on-link prefix via DHCPv6. My understanding is that we have never reached a consensus on this at IETF (consider, for example, how http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-default-router-00 was discussed and we still don't have any published outcome), so a simple rehash of it won't bring us anywhere. At the very least it's safer to discuss it outside the scope of rfc3315bis (because otherwise we'll never be able to publish the bis). -- JINMEI, Tatuya From nobody Thu Aug 7 12:53:17 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDB401A064C for ; Thu, 7 Aug 2014 12:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.683 X-Spam-Level: X-Spam-Status: No, score=-4.683 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham 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 TJweesvQy0Ge for ; Thu, 7 Aug 2014 12:53:14 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DF181A0AEF for ; Thu, 7 Aug 2014 12:53:13 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s77JrAWi015395; Thu, 7 Aug 2014 21:53:10 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 374A3205698; Thu, 7 Aug 2014 21:56:11 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 1F7C6204620; Thu, 7 Aug 2014 21:56:11 +0200 (CEST) Received: from [127.0.0.1] ([132.166.86.3]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s77JqjU2031338; Thu, 7 Aug 2014 21:53:10 +0200 Message-ID: <53E3D90C.4080706@gmail.com> Date: Thu, 07 Aug 2014 21:52:44 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: =?UTF-8?B?56We5piO6YGU5ZOJ?= References: <20140519150302.3625.29866.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E1B03125B@xmb-rcd-x04.cisco.com> <53E3872A.30204@gmail.com> <53E38954.1030206@gmail.com> <53E39157.8060708@gmail.com> <53E39635.60608@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/DlJqfABLWckCGLrf9clCB7bY14k Cc: dhcwg , Ralph Droms Subject: Re: [dhcwg] draft-dhcwg-dhc-rfc3315bis-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 19:53:16 -0000 Le 07/08/2014 18:24, 神明達哉 a écrit : > At Thu, 07 Aug 2014 17:07:33 +0200, > Alexandru Petrescu wrote: > >> That aside, I wonder why programmers have set that 64 in the kernel data >> absent a prefix length field in DHCP/RA, if not because of the fact that >> specifications are lacking. Were it for DHCPv6 to have a prefix length >> field for assigned address A, then programmer would be clearer of what >> to put on that field, I think. > > I guess you're basically re-raising a long standing discussion of > whether to provide an on-link prefix via DHCPv6. > > My understanding is that we have never reached a consensus on this at > IETF (consider, for example, how > http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-default-router-00 > was discussed and we still don't have any published outcome), so a > simple rehash of it won't bring us anywhere. At the very least it's > safer to discuss it outside the scope of rfc3315bis (because otherwise > we'll never be able to publish the bis). Yesm this is outside the rfc3315-bis discussion. The only minor nit is that it should define "prefix length" and use it, not use "prefix-length". Alex > > -- > JINMEI, Tatuya > > From nobody Thu Aug 7 13:41:23 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E7E1A00D4 for ; Thu, 7 Aug 2014 13:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 TgA6r48roe_4 for ; Thu, 7 Aug 2014 13:41:20 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22CDB1A0218 for ; Thu, 7 Aug 2014 13:41:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s77KfIm9011834; Thu, 7 Aug 2014 15:41:18 -0500 Received: from XCH-BLV-506.nw.nos.boeing.com (xch-blv-506.nw.nos.boeing.com [130.247.25.196]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s77KfBCi011285 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Thu, 7 Aug 2014 15:41:11 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.6]) by XCH-BLV-506.nw.nos.boeing.com ([169.254.6.213]) with mapi id 14.03.0181.006; Thu, 7 Aug 2014 13:41:10 -0700 From: "Templin, Fred L" To: "dhcwg@ietf.org" Thread-Topic: DHCPv6 RAAN options Thread-Index: Ac+yf+stS7sJIaihTkKQdnTDfuT8Qw== Date: Thu, 7 Aug 2014 20:41:09 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CECA61@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/m6yecB2ddjDpJTNkwhmXdtmGnnI Subject: [dhcwg] DHCPv6 RAAN options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 20:41:21 -0000 Hi, back long ago there was a draft titled: "DHCPv6 Relay Agent Assignment Notification (RAAN) Option": http://www.ietf.org/archive/id/draft-ietf-dhc-dhcpv6-agentopt-delegate-04.t= xt This document has been dormant for 5yrs, but it looks like it was already nearly ready for publication at the time. IMHO, the mechanism it specifies would be useful for real-world networking problems that cannot be satisfied through other approaches such as simple relay "gleaning" of IAs during DHCPv6 client/server exchanges. I am wondering if this document could be revived and brought back into the working group at this time? Thanks - Fred fred.l.templin@boeing.com From nobody Thu Aug 7 14:07:28 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6521A0101 for ; Thu, 7 Aug 2014 14:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 ykGN71PWpYJK for ; Thu, 7 Aug 2014 14:07:25 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 421C41A00FC for ; Thu, 7 Aug 2014 14:07:25 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id DDF861B83AA for ; Thu, 7 Aug 2014 14:07:24 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 937EB53E071; Thu, 7 Aug 2014 14:07:24 -0700 (PDT) Received: from [10.0.10.40] (71.233.43.215) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 7 Aug 2014 14:07:24 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <2134F8430051B64F815C691A62D9831832CECA61@XCH-BLV-504.nw.nos.boeing.com> Date: Thu, 7 Aug 2014 17:06:52 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <83E91E35-3F30-4659-B4AE-58DD11E74DB6@nominum.com> References: <2134F8430051B64F815C691A62D9831832CECA61@XCH-BLV-504.nw.nos.boeing.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/xzflXH_DTe-7UMaqO-R2KoVUQCQ Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] DHCPv6 RAAN options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 21:07:27 -0000 On Aug 7, 2014, at 4:41 PM, Templin, Fred L = wrote: > I am wondering > if this document could be revived and brought back into the working > group at this time? It died for a reason. Do you have a use case for it? From nobody Thu Aug 7 14:22:18 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2BD41A0143 for ; Thu, 7 Aug 2014 14:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 MVjruMK05dLa for ; Thu, 7 Aug 2014 14:22:15 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DD871A016D for ; Thu, 7 Aug 2014 14:22:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s77LMDru029728; Thu, 7 Aug 2014 14:22:13 -0700 Received: from XCH-PHX-409.sw.nos.boeing.com (xch-phx-409.sw.nos.boeing.com [10.57.37.40]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s77LM5Cp029651 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 7 Aug 2014 14:22:05 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.6]) by XCH-PHX-409.sw.nos.boeing.com ([169.254.9.11]) with mapi id 14.03.0181.006; Thu, 7 Aug 2014 14:22:05 -0700 From: "Templin, Fred L" To: Ted Lemon Thread-Topic: [dhcwg] DHCPv6 RAAN options Thread-Index: Ac+yf+stS7sJIaihTkKQdnTDfuT8QwAPkPgAAA579MA= Date: Thu, 7 Aug 2014 21:22:04 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CECB68@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832CECA61@XCH-BLV-504.nw.nos.boeing.com> <83E91E35-3F30-4659-B4AE-58DD11E74DB6@nominum.com> In-Reply-To: <83E91E35-3F30-4659-B4AE-58DD11E74DB6@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/TrHEuI854XZghCGyfdQfjTG7dUw Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] DHCPv6 RAAN options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 21:22:17 -0000 Hi Ted, > -----Original Message----- > From: Ted Lemon [mailto:ted.lemon@nominum.com] > Sent: Thursday, August 07, 2014 2:07 PM > To: Templin, Fred L > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] DHCPv6 RAAN options >=20 > On Aug 7, 2014, at 4:41 PM, Templin, Fred L w= rote: > > I am wondering > > if this document could be revived and brought back into the working > > group at this time? >=20 > It died for a reason. Do you have a use case for it? Yes, I think so. When a DHCPv6 client sends a Solicit, Request, Renew, Rebind, etc. via a DHCPv6 relay, the relay does not know yet whether the DHCPv6 server will honor the request. For example, authentication might fail and the DHCPv6 server will ignore the client's request. So, the relay should only glean IA_NA and IA_PD information on the reverse path from the server via the relay and to the client. However, the server's reply message might not contain enough information for the relay to do the gleaning (e.g., release of IA_NA/IA_PDs). So, a RAAN option would provide the correct information sharing between server and relay. Thanks - Fred fred.l.templin@boeing.com From nobody Thu Aug 7 14:31:32 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDFB51A01A9 for ; Thu, 7 Aug 2014 14:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 FzJuSEPC7qw0 for ; Thu, 7 Aug 2014 14:31:29 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 937141A0145 for ; Thu, 7 Aug 2014 14:31:29 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 57F6A1B82FE for ; Thu, 7 Aug 2014 14:31:29 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 5056B53E070; Thu, 7 Aug 2014 14:31:29 -0700 (PDT) Received: from [10.0.10.40] (71.233.43.215) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 7 Aug 2014 14:31:29 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <2134F8430051B64F815C691A62D9831832CECB68@XCH-BLV-504.nw.nos.boeing.com> Date: Thu, 7 Aug 2014 17:30:59 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <075FB3EE-EA09-4CBD-AFE9-CF14E77ED007@nominum.com> References: <2134F8430051B64F815C691A62D9831832CECA61@XCH-BLV-504.nw.nos.boeing.com> <83E91E35-3F30-4659-B4AE-58DD11E74DB6@nominum.com> <2134F8430051B64F815C691A62D9831832CECB68@XCH-BLV-504.nw.nos.boeing.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/mWg7j0JuIy18GPOTvzJha07U6Vc Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] DHCPv6 RAAN options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 21:31:31 -0000 On Aug 7, 2014, at 5:22 PM, Templin, Fred L = wrote: > Yes, I think so. When a DHCPv6 client sends a Solicit, Request, > Renew, Rebind, etc. via a DHCPv6 relay, the relay does not know > yet whether the DHCPv6 server will honor the request. For example, > authentication might fail and the DHCPv6 server will ignore the > client's request. >=20 > So, the relay should only glean IA_NA and IA_PD information on > the reverse path from the server via the relay and to the client. > However, the server's reply message might not contain enough > information for the relay to do the gleaning (e.g., release of > IA_NA/IA_PDs). So, a RAAN option would provide the correct > information sharing between server and relay. The authentication+release case is certainly an interesting one that I = hadn't considered before, and I don't think the working group has = either. RAAN may be a heavyweight solution, though. So rather than = simply reviving the RAAN option and adapting it to this purpose, it = might be worth doing a little more analysis first. From nobody Thu Aug 7 14:47:58 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50E4C1A0191 for ; Thu, 7 Aug 2014 14:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 SCF2xuTbL8NE for ; Thu, 7 Aug 2014 14:47:54 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7633C1A010C for ; Thu, 7 Aug 2014 14:47:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s77LlsYP010917; Thu, 7 Aug 2014 14:47:54 -0700 Received: from XCH-PHX-411.sw.nos.boeing.com (xch-phx-411.sw.nos.boeing.com [10.57.37.42]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s77Lll7x010416 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 7 Aug 2014 14:47:47 -0700 Received: from XCH-BLV-107.nw.nos.boeing.com (130.247.25.123) by XCH-PHX-411.sw.nos.boeing.com (10.57.37.42) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 7 Aug 2014 14:47:47 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.6]) by XCH-BLV-107.nw.nos.boeing.com ([169.254.7.108]) with mapi id 14.03.0181.006; Thu, 7 Aug 2014 14:47:46 -0700 From: "Templin, Fred L" To: Ted Lemon Thread-Topic: [dhcwg] DHCPv6 RAAN options Thread-Index: Ac+yf+stS7sJIaihTkKQdnTDfuT8QwAPkPgAAA579MD//5LdgIAAdPIw Date: Thu, 7 Aug 2014 21:47:46 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CECBF5@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832CECA61@XCH-BLV-504.nw.nos.boeing.com> <83E91E35-3F30-4659-B4AE-58DD11E74DB6@nominum.com> <2134F8430051B64F815C691A62D9831832CECB68@XCH-BLV-504.nw.nos.boeing.com> <075FB3EE-EA09-4CBD-AFE9-CF14E77ED007@nominum.com> In-Reply-To: <075FB3EE-EA09-4CBD-AFE9-CF14E77ED007@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/r6A9rx-LRAguAPpD0o8Z0tRugRY Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] DHCPv6 RAAN options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 21:47:56 -0000 Hi Ted, > -----Original Message----- > From: Ted Lemon [mailto:ted.lemon@nominum.com] > Sent: Thursday, August 07, 2014 2:31 PM > To: Templin, Fred L > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] DHCPv6 RAAN options >=20 > On Aug 7, 2014, at 5:22 PM, Templin, Fred L w= rote: > > Yes, I think so. When a DHCPv6 client sends a Solicit, Request, > > Renew, Rebind, etc. via a DHCPv6 relay, the relay does not know > > yet whether the DHCPv6 server will honor the request. For example, > > authentication might fail and the DHCPv6 server will ignore the > > client's request. > > > > So, the relay should only glean IA_NA and IA_PD information on > > the reverse path from the server via the relay and to the client. > > However, the server's reply message might not contain enough > > information for the relay to do the gleaning (e.g., release of > > IA_NA/IA_PDs). So, a RAAN option would provide the correct > > information sharing between server and relay. >=20 > The authentication+release case is certainly an interesting one that I ha= dn't considered before, and I > don't think the working group has either. Yes, I think that is the case that most strongly calls for something more than is in the base spec. But, I think other cases that call for authentication would also benefit - perhaps to a lesser degree. > RAAN may be a heavyweight solution, though. I am quite sure you understand the server->relay engine a lot better than I do. But, could it be turned on based on a server configuration option rather than having it as the default behavior?=20 > So rather > than simply reviving the RAAN option and adapting it to this purpose, it = might be worth doing a little > more analysis first. I have been looking at this for the past couple of days, and I don't see any ways for the relay agent to securely conclude that the client's IAs have been released without receiving downstream information from the server. The relay agent could cache the client's Release request, but then if the client is a rogue the relay could be exposed to a buffer exhaustion DoS attack. Now that I think of it, though, one possibility is to use the RFC3315(bis) effort to change the behavior of the server's Reply to a Release message so that the server lists the IAs that were released and with lifetimes set to 0. But, I'm not sure that the schedule for publishing RFC3315(bis) would be within the timeframe I am hoping for. Thanks - Fred fred.l.templin@boeing.com From nobody Thu Aug 7 14:52:58 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE931A014F for ; Thu, 7 Aug 2014 14:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 N30fFQ6z-YMq for ; Thu, 7 Aug 2014 14:52:56 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56CFC1A0113 for ; Thu, 7 Aug 2014 14:52:56 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 30E641B83A8 for ; Thu, 7 Aug 2014 14:52:56 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 1DFF253E070; Thu, 7 Aug 2014 14:52:56 -0700 (PDT) Received: from [10.0.10.40] (71.233.43.215) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 7 Aug 2014 14:52:56 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <2134F8430051B64F815C691A62D9831832CECBF5@XCH-BLV-504.nw.nos.boeing.com> Date: Thu, 7 Aug 2014 17:52:26 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <9C369D15-88ED-4E1E-8138-A538760C6FDE@nominum.com> References: <2134F8430051B64F815C691A62D9831832CECA61@XCH-BLV-504.nw.nos.boeing.com> <83E91E35-3F30-4659-B4AE-58DD11E74DB6@nominum.com> <2134F8430051B64F815C691A62D9831832CECB68@XCH-BLV-504.nw.nos.boeing.com> <075FB3EE-EA09-4CBD-AFE9-CF14E77ED007@nominum.com> <2134F8430051B64F815C691A62D9831832CECBF5@XCH-BLV-504.nw.nos.boeing.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/zJNaOjgABG0cTH1ckVKVyzc0vxk Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] DHCPv6 RAAN options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 21:52:57 -0000 On Aug 7, 2014, at 5:47 PM, Templin, Fred L = wrote: > Now that I think of it, though, one possibility is to use the > RFC3315(bis) effort to change the behavior of the server's Reply > to a Release message so that the server lists the IAs that were > released and with lifetimes set to 0. Yeah, that was the other alternative that sprung readily to mind when I = thought about the problem. > But, I'm not sure that the > schedule for publishing RFC3315(bis) would be within the > timeframe I am hoping for. Trying to get work through the WG on a time schedule is always a = challenge. But I think the point is that you should raise the issue = with the working group, not presupposing a particular solution, and see = what happens. Which I think effectively we have done now by having = this conversation. :) From nobody Thu Aug 7 15:00:15 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8101E1A02E4 for ; Thu, 7 Aug 2014 15:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 QLawFo4G6Wg8 for ; Thu, 7 Aug 2014 15:00:12 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2F561A02EF for ; Thu, 7 Aug 2014 15:00:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s77M0BUo003350; Thu, 7 Aug 2014 15:00:11 -0700 Received: from XCH-PHX-513.sw.nos.boeing.com (xch-phx-513.sw.nos.boeing.com [10.57.37.30]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s77M07Vm003306 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 7 Aug 2014 15:00:07 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.6]) by XCH-PHX-513.sw.nos.boeing.com ([169.254.13.36]) with mapi id 14.03.0181.006; Thu, 7 Aug 2014 15:00:06 -0700 From: "Templin, Fred L" To: Ted Lemon Thread-Topic: [dhcwg] DHCPv6 RAAN options Thread-Index: Ac+yf+stS7sJIaihTkKQdnTDfuT8QwAPkPgAAA579MD//5LdgIAAdPIw//+RDACAAHTV8A== Date: Thu, 7 Aug 2014 22:00:06 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CECC7B@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832CECA61@XCH-BLV-504.nw.nos.boeing.com> <83E91E35-3F30-4659-B4AE-58DD11E74DB6@nominum.com> <2134F8430051B64F815C691A62D9831832CECB68@XCH-BLV-504.nw.nos.boeing.com> <075FB3EE-EA09-4CBD-AFE9-CF14E77ED007@nominum.com> <2134F8430051B64F815C691A62D9831832CECBF5@XCH-BLV-504.nw.nos.boeing.com> <9C369D15-88ED-4E1E-8138-A538760C6FDE@nominum.com> In-Reply-To: <9C369D15-88ED-4E1E-8138-A538760C6FDE@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/cOL6MD5FNexK9Yg6YnF2tNbiMtI Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] DHCPv6 RAAN options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 22:00:13 -0000 Hi Ted, > -----Original Message----- > From: Ted Lemon [mailto:ted.lemon@nominum.com] > Sent: Thursday, August 07, 2014 2:52 PM > To: Templin, Fred L > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] DHCPv6 RAAN options >=20 > On Aug 7, 2014, at 5:47 PM, Templin, Fred L w= rote: > > Now that I think of it, though, one possibility is to use the > > RFC3315(bis) effort to change the behavior of the server's Reply > > to a Release message so that the server lists the IAs that were > > released and with lifetimes set to 0. >=20 > Yeah, that was the other alternative that sprung readily to mind when I t= hought about the problem. Agreed. =20 > > But, I'm not sure that the > > schedule for publishing RFC3315(bis) would be within the > > timeframe I am hoping for. >=20 > Trying to get work through the WG on a time schedule is always a challeng= e. But I think the point is > that you should raise the issue with the working group, not presupposing = a particular solution, and > see what happens. Which I think effectively we have done now by having th= is conversation. :) Also understood. At the moment, having the relay securely conclude that a client's IAs have been released is the only use case that I can see that doesn't seem to be satisfied by the base specs. I would be happy to hear differently, however, and will keep my eyes open for other use cases that may need attention. Thanks - Fred fred.l.templin@boeing.com From nobody Thu Aug 7 15:23:39 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B786D1B2A35 for ; Thu, 7 Aug 2014 15:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 QTpYuuIEKVxk for ; Thu, 7 Aug 2014 15:23:35 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C9C91B2A2A for ; Thu, 7 Aug 2014 15:23:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s77MNYNe025416; Thu, 7 Aug 2014 15:23:34 -0700 Received: from XCH-PHX-210.sw.nos.boeing.com (xch-phx-210.sw.nos.boeing.com [130.247.25.65]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s77MNRZ1025369 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 7 Aug 2014 15:23:28 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.6]) by XCH-PHX-210.sw.nos.boeing.com ([169.254.10.130]) with mapi id 14.03.0181.006; Thu, 7 Aug 2014 15:23:27 -0700 From: "Templin, Fred L" To: Ted Lemon Thread-Topic: [dhcwg] DHCPv6 RAAN options Thread-Index: Ac+yf+stS7sJIaihTkKQdnTDfuT8QwAPkPgAAA579MD//5LdgIAAdPIw//+RDACAAHTV8IAA4dxQ Date: Thu, 7 Aug 2014 22:23:26 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CECD1A@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832CECA61@XCH-BLV-504.nw.nos.boeing.com> <83E91E35-3F30-4659-B4AE-58DD11E74DB6@nominum.com> <2134F8430051B64F815C691A62D9831832CECB68@XCH-BLV-504.nw.nos.boeing.com> <075FB3EE-EA09-4CBD-AFE9-CF14E77ED007@nominum.com> <2134F8430051B64F815C691A62D9831832CECBF5@XCH-BLV-504.nw.nos.boeing.com> <9C369D15-88ED-4E1E-8138-A538760C6FDE@nominum.com> <2134F8430051B64F815C691A62D9831832CECC7B@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832CECC7B@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/IrCCz8RMg7jIw_u0YfMQrjr9EHc Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] DHCPv6 RAAN options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 22:23:37 -0000 Hi Ted, Another thought: > > > Now that I think of it, though, one possibility is to use the > > > RFC3315(bis) effort to change the behavior of the server's Reply > > > to a Release message so that the server lists the IAs that were > > > released and with lifetimes set to 0. > > > > Yeah, that was the other alternative that sprung readily to mind when I= thought about the problem. >=20 > Agreed. what about an errata to RFC3315? Thanks - Fred fred.l.templin@boeing.com From nobody Thu Aug 7 15:56:26 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C30C01A02BB for ; Thu, 7 Aug 2014 15:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 86YgLkxsWFUU for ; Thu, 7 Aug 2014 15:56:24 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45A911A029F for ; Thu, 7 Aug 2014 15:56:24 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 57FBB1B8364 for ; Thu, 7 Aug 2014 15:56:21 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 4154953E070; Thu, 7 Aug 2014 15:56:21 -0700 (PDT) Received: from [10.0.10.40] (71.233.43.215) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 7 Aug 2014 15:56:20 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <2134F8430051B64F815C691A62D9831832CECD1A@XCH-BLV-504.nw.nos.boeing.com> Date: Thu, 7 Aug 2014 18:55:50 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <35F4F6CF-7CBC-4935-9E9F-2EC946D7EBB7@nominum.com> References: <2134F8430051B64F815C691A62D9831832CECA61@XCH-BLV-504.nw.nos.boeing.com> <83E91E35-3F30-4659-B4AE-58DD11E74DB6@nominum.com> <2134F8430051B64F815C691A62D9831832CECB68@XCH-BLV-504.nw.nos.boeing.com> <075FB3EE-EA09-4CBD-AFE9-CF14E77ED007@nominum.com> <2134F8430051B64F815C691A62D9831832CECBF5@XCH-BLV-504.nw.nos.boeing.com> <9C369D15-88ED-4E1E-8138-A538760C6FDE@nominum.com> <2134F8430051B64F815C691A62D9831832CECC7B@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CECD1A@XCH-BLV-504.nw.nos.boeing.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/usp2CM5NKI42yC61BjJHcT8neTU Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] DHCPv6 RAAN options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 22:56:25 -0000 On Aug 7, 2014, at 6:23 PM, Templin, Fred L = wrote: > what about an errata to RFC3315? It's not an error, so no, I would have to reject that. From nobody Fri Aug 8 07:44:46 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B96101B2B38 for ; Fri, 8 Aug 2014 07:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 iJnkJsxw3r7s for ; Fri, 8 Aug 2014 07:44:43 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BE661B2B47 for ; Fri, 8 Aug 2014 07:44:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s78EihLt021122; Fri, 8 Aug 2014 07:44:43 -0700 Received: from XCH-PHX-113.sw.nos.boeing.com (xch-phx-113.sw.nos.boeing.com [130.247.25.136]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s78EifGg021099 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 8 Aug 2014 07:44:42 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.6]) by XCH-PHX-113.sw.nos.boeing.com ([169.254.13.50]) with mapi id 14.03.0181.006; Fri, 8 Aug 2014 07:44:41 -0700 From: "Templin, Fred L" To: Ted Lemon Thread-Topic: [dhcwg] DHCPv6 RAAN options Thread-Index: Ac+yf+stS7sJIaihTkKQdnTDfuT8QwAPkPgAAA579MD//5LdgIAAdPIw//+RDACAAHTV8IAA4dxQ//67BgD//2x8wA== Date: Fri, 8 Aug 2014 14:44:40 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CED2CD@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832CECA61@XCH-BLV-504.nw.nos.boeing.com> <83E91E35-3F30-4659-B4AE-58DD11E74DB6@nominum.com> <2134F8430051B64F815C691A62D9831832CECB68@XCH-BLV-504.nw.nos.boeing.com> <075FB3EE-EA09-4CBD-AFE9-CF14E77ED007@nominum.com> <2134F8430051B64F815C691A62D9831832CECBF5@XCH-BLV-504.nw.nos.boeing.com> <9C369D15-88ED-4E1E-8138-A538760C6FDE@nominum.com> <2134F8430051B64F815C691A62D9831832CECC7B@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CECD1A@XCH-BLV-504.nw.nos.boeing.com> <35F4F6CF-7CBC-4935-9E9F-2EC946D7EBB7@nominum.com> In-Reply-To: <35F4F6CF-7CBC-4935-9E9F-2EC946D7EBB7@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/dCi8brTYd27TJBhKMw_g-EHkWU0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] DHCPv6 RAAN options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 14:44:44 -0000 > > what about an errata to RFC3315? >=20 > It's not an error, so no, I would have to reject that. Write a little draft that (if approved) updates RFC3315? Thanks - Fred fred.l.templin@boeing.com From nobody Fri Aug 8 07:53:51 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07A591B2B26 for ; Fri, 8 Aug 2014 07:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 ppnjqOHg062e for ; Fri, 8 Aug 2014 07:53:49 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F16471B2B07 for ; Fri, 8 Aug 2014 07:53:48 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 6FCA91B83AA for ; Fri, 8 Aug 2014 07:53:48 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 50C2053E070; Fri, 8 Aug 2014 07:53:48 -0700 (PDT) Received: from [10.0.10.40] (71.233.43.215) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 8 Aug 2014 07:53:48 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <2134F8430051B64F815C691A62D9831832CED2CD@XCH-BLV-504.nw.nos.boeing.com> Date: Fri, 8 Aug 2014 10:53:43 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <65C2A9BF-B153-4BD0-89EF-6D7D8FE459B3@nominum.com> References: <2134F8430051B64F815C691A62D9831832CECA61@XCH-BLV-504.nw.nos.boeing.com> <83E91E35-3F30-4659-B4AE-58DD11E74DB6@nominum.com> <2134F8430051B64F815C691A62D9831832CECB68@XCH-BLV-504.nw.nos.boeing.com> <075FB3EE-EA09-4CBD-AFE9-CF14E77ED007@nominum.com> <2134F8430051B64F815C691A62D9831832CECBF5@XCH-BLV-504.nw.nos.boeing.com> <9C369D15-88ED-4E1E-8138-A538760C6FDE@nominum.com> <2134F8430051B64F815C691A62D9831832CECC7B@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CECD1A@XCH-BLV-504.nw.nos.boeing.com> <35F4F6CF-7CBC-4935-9E9F-2EC946D7EBB7@nominum.com> <2134F8430051B64F815C691A62D9831832CED2CD@XCH-BLV-504.nw.nos.boeing.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/BjqzOiggtOEe2a8i1A1vXWZiJWU Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] DHCPv6 RAAN options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 14:53:50 -0000 On Aug 8, 2014, at 10:44 AM, Templin, Fred L = wrote: > Write a little draft that (if approved) updates RFC3315? That's the right process, if you can't get this into the 3315bis effort. = But it would have to go through the working group. I seem to be = talking a lot on this topic, but I'm only one working group participant, = and not an active participant in the 3315bis effort. Have any of the = 3315bis people been following this discussion? Do you have thoughts on = the matter? From nobody Fri Aug 8 08:57:17 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7A6C1B2B7E for ; Fri, 8 Aug 2014 08:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 BSyD1NN2B4za for ; Fri, 8 Aug 2014 08:57:13 -0700 (PDT) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D47D1B2B1B for ; Fri, 8 Aug 2014 08:57:13 -0700 (PDT) Received: by mail-pd0-f177.google.com with SMTP id p10so7142253pdj.8 for ; Fri, 08 Aug 2014 08:57:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=tSV5lFM6sdJeYSVCIZRAm2Se9W9OuKLio3hSevYUAM4=; b=VkTYUV0XpXtAWRTY4j5okfLYEPJio1l8eh6LYomq0lSwufCwjl8JiHYnDhko8QDkKD 9AChEITkwb2xGWhMZW7rjWVrfYw8wYKGWfBorq5txDVC96cbfwwQJZp8ONwf2xls83V0 oM0Da48ODL0buUqu09iSB+1QkOVOsZMhMAJDYZEXfxzL5/Ve4hWxPA7rgoYR7aiKhSI1 LnSarPs4TudnLeI2QtIzl65xSpaamVo2oXa4yvXgtUdPGI7nqHOGdz127cz7u3SWIp9B Y2ic3KvRLZxpRDq8kKJ7mQ3dUPq/Q1Q7+6BsAKV8kIEFDUKyV1Rt7Wx9SepUJSFYdiBX k04Q== X-Received: by 10.66.97.7 with SMTP id dw7mr24877536pab.114.1407513433032; Fri, 08 Aug 2014 08:57:13 -0700 (PDT) Received: from [10.82.101.34] (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPSA id x5sm3404443pbw.26.2014.08.08.08.57.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Aug 2014 08:57:11 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ralph Droms In-Reply-To: <65C2A9BF-B153-4BD0-89EF-6D7D8FE459B3@nominum.com> Date: Fri, 8 Aug 2014 11:57:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2134F8430051B64F815C691A62D9831832CECA61@XCH-BLV-504.nw.nos.boeing.com> <83E91E35-3F30-4659-B4AE-58DD11E74DB6@nominum.com> <2134F8430051B64F815C691A62D9831832CECB68@XCH-BLV-504.nw.nos.boeing.com> <075FB3EE-EA09-4CBD-AFE9-CF14E77ED007@nominum.com> <2134F8430051B64F815C691A62D9831832CECBF5@XCH-BLV-504.nw.nos.boeing.com> <9C369D15-88ED-4E1E-8138-A538760C6FDE@nominum.com> <2134F8430051B64F815C691A62D9831832CECC7B@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CECD1A@XCH-BLV-504.nw.nos.boeing.com> <35F4F6CF-7CBC-4935-9E9F-2EC946D7EBB7@nominum.com> <2134F8430051B64F815C691A62D9831832CED2CD@XCH-BLV-504.nw.nos.boeing.com> <65C2A9BF-B153-4BD0-89EF-6D7D8FE459B3@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/dUKkwaVHCh5kwFw8cutuZWZg0n0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] DHCPv6 RAAN options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 15:57:16 -0000 On Aug 8, 2014, at 10:53 AM 8/8/14, Ted Lemon = wrote: > On Aug 8, 2014, at 10:44 AM, Templin, Fred L = wrote: >> Write a little draft that (if approved) updates RFC3315? >=20 > That's the right process, if you can't get this into the 3315bis = effort. But it would have to go through the working group. I seem to = be talking a lot on this topic, but I'm only one working group = participant, and not an active participant in the 3315bis effort. Have = any of the 3315bis people been following this discussion? Do you have = thoughts on the matter? If I recall correctly, draft-ietf-dhc-dhcpv6-agentopt-delegate-04 was = not published by the working group because of message transport and = ordering concerns: no guarantees that... ...messages containing RAAN options will be delivered in order so that = the relay agent takes actions in the correct order ...transactions containing RAAN options will be forwarded through the = correct relay agent; e.g., the transaction delegating prefix P to device = D might be forwarded through relay agent R1, causing R1 to take action = based on that delegation, while the subsequent transaction releasing P = might be forwarded through relay agent R2, which has no knowledge of the = original delegation - Ralph PS I'm working from memory w/o bothering to research the mailing list... >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From nobody Fri Aug 8 09:07:05 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B8E1B2B54 for ; Fri, 8 Aug 2014 09:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 hFZt6_OqB_cM for ; Fri, 8 Aug 2014 09:07:00 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AF741B2B6C for ; Fri, 8 Aug 2014 09:07:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s78G70Ma005845; Fri, 8 Aug 2014 09:07:00 -0700 Received: from XCH-PHX-512.sw.nos.boeing.com (xch-phx-512.sw.nos.boeing.com [10.57.37.29]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s78G6qFV005329 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 8 Aug 2014 09:06:52 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.6]) by XCH-PHX-512.sw.nos.boeing.com ([169.254.12.132]) with mapi id 14.03.0181.006; Fri, 8 Aug 2014 09:06:52 -0700 From: "Templin, Fred L" To: Ralph Droms , Ted Lemon Thread-Topic: [dhcwg] DHCPv6 RAAN options Thread-Index: Ac+yf+stS7sJIaihTkKQdnTDfuT8QwAPkPgAAA579MD//5LdgIAAdPIw//+RDACAAHTV8IAA4dxQ//67BgD//2x8wAAnctNw///+rmA= Date: Fri, 8 Aug 2014 16:06:51 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CED559@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832CECA61@XCH-BLV-504.nw.nos.boeing.com> <83E91E35-3F30-4659-B4AE-58DD11E74DB6@nominum.com> <2134F8430051B64F815C691A62D9831832CECB68@XCH-BLV-504.nw.nos.boeing.com> <075FB3EE-EA09-4CBD-AFE9-CF14E77ED007@nominum.com> <2134F8430051B64F815C691A62D9831832CECBF5@XCH-BLV-504.nw.nos.boeing.com> <9C369D15-88ED-4E1E-8138-A538760C6FDE@nominum.com> <2134F8430051B64F815C691A62D9831832CECC7B@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CECD1A@XCH-BLV-504.nw.nos.boeing.com> <35F4F6CF-7CBC-4935-9E9F-2EC946D7EBB7@nominum.com> <2134F8430051B64F815C691A62D9831832CED2CD@XCH-BLV-504.nw.nos.boeing.com> <65C2A9BF-B153-4BD0-89EF-6D7D8FE459B3@nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/xTfwOMYDdNi8roLfsK9FEvbblNM Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] DHCPv6 RAAN options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 16:07:03 -0000 Hi Ralph, > -----Original Message----- > From: Ralph Droms [mailto:rdroms.ietf@gmail.com] > Sent: Friday, August 08, 2014 8:57 AM > To: Ted Lemon > Cc: Templin, Fred L; dhcwg@ietf.org > Subject: Re: [dhcwg] DHCPv6 RAAN options >=20 >=20 > On Aug 8, 2014, at 10:53 AM 8/8/14, Ted Lemon wro= te: >=20 > > On Aug 8, 2014, at 10:44 AM, Templin, Fred L wrote: > >> Write a little draft that (if approved) updates RFC3315? > > > > That's the right process, if you can't get this into the 3315bis effort= . But it would have to go > through the working group. I seem to be talking a lot on this topic, bu= t I'm only one working group > participant, and not an active participant in the 3315bis effort. Have = any of the 3315bis people > been following this discussion? Do you have thoughts on the matter? >=20 > If I recall correctly, draft-ietf-dhc-dhcpv6-agentopt-delegate-04 was not= published by the working > group because of message transport and ordering concerns: no guarantees t= hat... >=20 > ...messages containing RAAN options will be delivered in order so that th= e relay agent takes actions > in the correct order > ...transactions containing RAAN options will be forwarded through the cor= rect relay agent; e.g., the > transaction delegating prefix P to device D might be forwarded through re= lay agent R1, causing R1 to > take action based on that delegation, while the subsequent transaction re= leasing P might be forwarded > through relay agent R2, which has no knowledge of the original delegation I have a case where the Client can steer its DHCPv6 messaging through a specific relay agent or agents by mapping All_DHCP_Relay_Agents_and_Servers to a unicast L2 address. I think there would probably also be real-world use cases where there is only one relay agent on the link - otherwise, I think PD might have problems in some environments. But, perhaps others would know better. Thanks - Fred fred.l.templin@boeing.com > - Ralph >=20 > PS I'm working from memory w/o bothering to research the mailing list... > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www.ietf.org/mailman/listinfo/dhcwg From nobody Fri Aug 8 09:16:25 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524821B2B1B for ; Fri, 8 Aug 2014 09:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 W5OQ0IeArZV1 for ; Fri, 8 Aug 2014 09:16:22 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF9C11B2A68 for ; Fri, 8 Aug 2014 09:16:22 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 513FF1B8342 for ; Fri, 8 Aug 2014 09:16:14 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 19B2B53E070; Fri, 8 Aug 2014 09:16:14 -0700 (PDT) Received: from [10.0.10.40] (71.233.43.215) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 8 Aug 2014 09:16:13 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <2134F8430051B64F815C691A62D9831832CED559@XCH-BLV-504.nw.nos.boeing.com> Date: Fri, 8 Aug 2014 12:16:08 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <2134F8430051B64F815C691A62D9831832CECA61@XCH-BLV-504.nw.nos.boeing.com> <83E91E35-3F30-4659-B4AE-58DD11E74DB6@nominum.com> <2134F8430051B64F815C691A62D9831832CECB68@XCH-BLV-504.nw.nos.boeing.com> <075FB3EE-EA09-4CBD-AFE9-CF14E77ED007@nominum.com> <2134F8430051B64F815C691A62D9831832CECBF5@XCH-BLV-504.nw.nos.boeing.com> <9C369D15-88ED-4E1E-8138-A538760C6FDE@nominum.com> <2134F8430051B64F815C691A62D9831832CECC7B@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CECD1A@XCH-BLV-504.nw.nos.boeing.com> <35F4F6CF-7CBC-4935-9E9F-2EC946D7EBB7@nominum.com> <2134F8430051B64F815C691A62D9831832CED2CD@XCH-BLV-504.nw.nos.boeing.com> <65C2A9BF-B153-4BD0-89EF-6D7D8FE459B3@nominum.com> <2134F8430051B64F815C691A62D9831832CED559@XCH-BLV-504.nw.nos.boeing.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/SAYFoe0nI7SEKtmRBzc2_5VxD_w Cc: "dhcwg@ietf.org" , Ralph Droms Subject: Re: [dhcwg] DHCPv6 RAAN options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 16:16:24 -0000 On Aug 8, 2014, at 12:06 PM, Templin, Fred L = wrote: > I have a case where the Client can steer its DHCPv6 messaging through = a > specific relay agent or agents by mapping = All_DHCP_Relay_Agents_and_Servers > to a unicast L2 address. That's not DHCP, so it's out of scope for the WG. From nobody Fri Aug 8 09:25:04 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3373F1B2C5B for ; Fri, 8 Aug 2014 09:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 huQHkL30rxew for ; Fri, 8 Aug 2014 09:24:57 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A25521B2C54 for ; Fri, 8 Aug 2014 09:24:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s78GOvkK005580; Fri, 8 Aug 2014 09:24:57 -0700 Received: from XCH-PHX-510.sw.nos.boeing.com (xch-phx-510.sw.nos.boeing.com [10.57.37.27]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s78GOtWh005428 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 8 Aug 2014 09:24:56 -0700 Received: from XCH-BLV-406.nw.nos.boeing.com (130.247.25.162) by XCH-PHX-510.sw.nos.boeing.com (10.57.37.27) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 8 Aug 2014 09:24:55 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.6]) by XCH-BLV-406.nw.nos.boeing.com ([169.254.6.97]) with mapi id 14.03.0181.006; Fri, 8 Aug 2014 09:24:55 -0700 From: "Templin, Fred L" To: Ted Lemon Thread-Topic: [dhcwg] DHCPv6 RAAN options Thread-Index: Ac+yf+stS7sJIaihTkKQdnTDfuT8QwAPkPgAAA579MD//5LdgIAAdPIw//+RDACAAHTV8IAA4dxQ//67BgD//2x8wAAnctNw///+rmD//4QYAP//fRpg Date: Fri, 8 Aug 2014 16:24:54 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CED5E7@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832CECA61@XCH-BLV-504.nw.nos.boeing.com> <83E91E35-3F30-4659-B4AE-58DD11E74DB6@nominum.com> <2134F8430051B64F815C691A62D9831832CECB68@XCH-BLV-504.nw.nos.boeing.com> <075FB3EE-EA09-4CBD-AFE9-CF14E77ED007@nominum.com> <2134F8430051B64F815C691A62D9831832CECBF5@XCH-BLV-504.nw.nos.boeing.com> <9C369D15-88ED-4E1E-8138-A538760C6FDE@nominum.com> <2134F8430051B64F815C691A62D9831832CECC7B@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CECD1A@XCH-BLV-504.nw.nos.boeing.com> <35F4F6CF-7CBC-4935-9E9F-2EC946D7EBB7@nominum.com> <2134F8430051B64F815C691A62D9831832CED2CD@XCH-BLV-504.nw.nos.boeing.com> <65C2A9BF-B153-4BD0-89EF-6D7D8FE459B3@nominum.com> <2134F8430051B64F815C691A62D9831832CED559@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/Xh3_N5AXyl6EkeO-7XLmfH8ejac Cc: "dhcwg@ietf.org" , Ralph Droms Subject: Re: [dhcwg] DHCPv6 RAAN options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 16:25:03 -0000 Hi Ted, > -----Original Message----- > From: Ted Lemon [mailto:ted.lemon@nominum.com] > Sent: Friday, August 08, 2014 9:16 AM > To: Templin, Fred L > Cc: Ralph Droms; dhcwg@ietf.org > Subject: Re: [dhcwg] DHCPv6 RAAN options >=20 > On Aug 8, 2014, at 12:06 PM, Templin, Fred L = wrote: > > I have a case where the Client can steer its DHCPv6 messaging through a > > specific relay agent or agents by mapping All_DHCP_Relay_Agents_and_Ser= vers > > to a unicast L2 address. >=20 > That's not DHCP, so it's out of scope for the WG. It is a link-layer consideration that occurs below the IPv6 layer. So, yes it is DHCPv6 over a specific link layer. If that is still troubling, then please also consider the case of a link that is physically constrained to have only a single DHCPv6 relay. Thanks - Fred fred.l.templin@boeing.com From nobody Fri Aug 8 09:33:45 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC771B2B69 for ; Fri, 8 Aug 2014 09:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 uWAFyurOSpRZ for ; Fri, 8 Aug 2014 09:33:42 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A04A51A0046 for ; Fri, 8 Aug 2014 09:33:42 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 6DCF41B83AB for ; Fri, 8 Aug 2014 09:33:42 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 6344853E070; Fri, 8 Aug 2014 09:33:42 -0700 (PDT) Received: from [10.0.10.40] (71.233.43.215) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 8 Aug 2014 09:33:42 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <2134F8430051B64F815C691A62D9831832CED5E7@XCH-BLV-504.nw.nos.boeing.com> Date: Fri, 8 Aug 2014 12:33:36 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <2134F8430051B64F815C691A62D9831832CECA61@XCH-BLV-504.nw.nos.boeing.com> <83E91E35-3F30-4659-B4AE-58DD11E74DB6@nominum.com> <2134F8430051B64F815C691A62D9831832CECB68@XCH-BLV-504.nw.nos.boeing.com> <075FB3EE-EA09-4CBD-AFE9-CF14E77ED007@nominum.com> <2134F8430051B64F815C691A62D9831832CECBF5@XCH-BLV-504.nw.nos.boeing.com> <9C369D15-88ED-4E1E-8138-A538760C6FDE@nominum.com> <2134F8430051B64F815C691A62D9831832CECC7B@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CECD1A@XCH-BLV-504.nw.nos.boeing.com> <35F4F6CF-7CBC-4935-9E9F-2EC946D7EBB7@nominum.com> <2134F8430051B64F815C691A62D9831832CED2CD@XCH-BLV-504.nw.nos.boeing.com> <65C2A9BF-B153-4BD0-89EF-6D7D8FE459B3@nominum.com> <2134F8430051B64F815C691A62D9831832CED559@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CED5E7@XCH-BLV-504.nw.nos.boeing.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/Dvbwms2ZXkY4BgpucZTSNHkkbE4 Cc: "dhcwg@ietf.org" , Ralph Droms Subject: Re: [dhcwg] DHCPv6 RAAN options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 16:33:44 -0000 On Aug 8, 2014, at 12:24 PM, Templin, Fred L = wrote: > It is a link-layer consideration that occurs below the IPv6 layer. > So, yes it is DHCPv6 over a specific link layer. Right, I don't think this makes sense as an Internet standard unless = there's some broad applicability, in which case that would have to be = documented as a DHCP extension first. > If that is still troubling, then please also consider the case > of a link that is physically constrained to have only a single > DHCPv6 relay. A special extension to DHCP just to account for this use case seems like = the wrong approach when you consider the general applicability of the = DHCP protocol. ISTM that either solution we've talked about would work = for you as a private hack, but the question is which one (if any) makes = sense as a standard extension to DHCP. From nobody Fri Aug 8 09:48:19 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4750E1B2C9C for ; Fri, 8 Aug 2014 09:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 sNatk6hR1p7c for ; Fri, 8 Aug 2014 09:48:15 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90D101B2C9B for ; Fri, 8 Aug 2014 09:48:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s78GmFLR032322; Fri, 8 Aug 2014 09:48:15 -0700 Received: from XCH-PHX-112.sw.nos.boeing.com (xch-phx-112.sw.nos.boeing.com [130.247.25.134]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s78GmDwZ032318 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 8 Aug 2014 09:48:13 -0700 Received: from XCH-BLV-203.nw.nos.boeing.com (10.57.37.65) by XCH-PHX-112.sw.nos.boeing.com (130.247.25.134) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 8 Aug 2014 09:48:12 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.6]) by XCH-BLV-203.nw.nos.boeing.com ([169.254.3.44]) with mapi id 14.03.0181.006; Fri, 8 Aug 2014 09:48:12 -0700 From: "Templin, Fred L" To: Ted Lemon Thread-Topic: [dhcwg] DHCPv6 RAAN options Thread-Index: Ac+yf+stS7sJIaihTkKQdnTDfuT8QwAPkPgAAA579MD//5LdgIAAdPIw//+RDACAAHTV8IAA4dxQ//67BgD//2x8wAAnctNw///+rmD//4QYAP//fRpg//6AaAD//XWcsA== Date: Fri, 8 Aug 2014 16:48:12 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CED674@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832CECA61@XCH-BLV-504.nw.nos.boeing.com> <83E91E35-3F30-4659-B4AE-58DD11E74DB6@nominum.com> <2134F8430051B64F815C691A62D9831832CECB68@XCH-BLV-504.nw.nos.boeing.com> <075FB3EE-EA09-4CBD-AFE9-CF14E77ED007@nominum.com> <2134F8430051B64F815C691A62D9831832CECBF5@XCH-BLV-504.nw.nos.boeing.com> <9C369D15-88ED-4E1E-8138-A538760C6FDE@nominum.com> <2134F8430051B64F815C691A62D9831832CECC7B@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CECD1A@XCH-BLV-504.nw.nos.boeing.com> <35F4F6CF-7CBC-4935-9E9F-2EC946D7EBB7@nominum.com> <2134F8430051B64F815C691A62D9831832CED2CD@XCH-BLV-504.nw.nos.boeing.com> <65C2A9BF-B153-4BD0-89EF-6D7D8FE459B3@nominum.com> <2134F8430051B64F815C691A62D9831832CED559@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CED5E7@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/fV5q4qlSZpq5O8-Cw9RxWKytY4Y Cc: "dhcwg@ietf.org" , Ralph Droms Subject: Re: [dhcwg] DHCPv6 RAAN options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 16:48:17 -0000 Hi Ted, > -----Original Message----- > From: Ted Lemon [mailto:ted.lemon@nominum.com] > Sent: Friday, August 08, 2014 9:34 AM > To: Templin, Fred L > Cc: Ralph Droms; dhcwg@ietf.org > Subject: Re: [dhcwg] DHCPv6 RAAN options >=20 > On Aug 8, 2014, at 12:24 PM, Templin, Fred L = wrote: > > It is a link-layer consideration that occurs below the IPv6 layer. > > So, yes it is DHCPv6 over a specific link layer. >=20 > Right, I don't think this makes sense as an Internet standard unless ther= e's some broad applicability, > in which case that would have to be documented as a DHCP extension first. >=20 > > If that is still troubling, then please also consider the case > > of a link that is physically constrained to have only a single > > DHCPv6 relay. >=20 > A special extension to DHCP just to account for this use case seems like = the wrong approach when you > consider the general applicability of the DHCP protocol. ISTM that eith= er solution we've talked > about would work for you as a private hack, but the question is which one= (if any) makes sense as a > standard extension to DHCP. Just so we can be clear on the alternatives, the first one we talked about was to ask the server to include in its Reply message any IAs that were released as a result of the client's Release message and with lifetimes set to 0. The second alternative was to resurrect RAAN options somehow. If I am understanding this correctly, then the RAAN option provides a convenient way of relay agent gleaning. But, option 1 would still allow for a slightly less convenient means for gleaning. Thanks - Fred fred.l.templin@boeing.com From nobody Fri Aug 8 09:51:45 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DDB81A0407; Fri, 8 Aug 2014 09:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 LjpjKn3UP_KN; Fri, 8 Aug 2014 09:51:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2B71B2BD8; Fri, 8 Aug 2014 09:51:41 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140808165141.7089.14673.idtracker@ietfa.amsl.com> Date: Fri, 08 Aug 2014 09:51:41 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/7ZVg5MkL9G3ANq-4Ve7PVO0PnOg Cc: dhc WG Subject: [dhcwg] WG Action: Rechartered Dynamic Host Configuration (dhc) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 16:51:44 -0000 The Dynamic Host Configuration (dhc) working group in the Internet Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs. Dynamic Host Configuration (dhc) ------------------------------------------------ Current Status: Active WG Chairs: Bernie Volz Tomek Mrugalski Secretaries: Sheng Jiang Assigned Area Director: Ted Lemon Mailing list Address: dhcwg@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/dhcwg Archive: http://www.ietf.org/mail-archive/web/dhcwg/ Charter: The Dynamic Host Configuration working group (DHC WG) has developed DHCP for automated allocation, configuration and management of IP addresses and TCP/IP protocol stack parameters. DHCPv4 is currently a Draft Standard and is documented in RFC 2131 and RFC 2132. DHCPv6 is currently a Proposed Standard and is documented in RFC 3315. Subsequent RFCs document additional options and other enhancements to the specifications. The DHC WG is responsible for defining DHCP protocol extensions. Definitions of new DHCP options that are delivered using standard mechanisms with documented semantics are not considered a protocol extension and thus are outside of scope for the DHC WG. Such options should be defined within their respective WGs and reviewed by DHCP experts in the Internet Area Directorate. However, if such options require protocol extensions or new semantics, the protocol extension work must be done in the DHC WG. The DHC WG has the following main objectives: 1. Develop extensions to the DHCPv6 infrastructure as required to meet new applications and deployments of DHCP. The topics currently in development are: - DHCPv6 Stateful issues - DHCPv6 Failover - DHCPv6 Load Balancing - Extending DHCPv6 to work with multiple provisioning domains - DHCP provisioning of IPv4 clients over IPv6 networks - Access Network Identifier options - DNS registration for SLAAC - Active leasequery - Secure DHCPv6 with Public Key - Dynamic Allocation of Shared IPv4 Addresses Additional topics may only be added with approval from the responsible Area Director or by re-chartering. 2. Develop documents that help explain operational considerations for the wider community. 3. Issue updated versions of the DHCP base specifications-- RFC 3315 (DHCPv6), RFC 3633 (DHCPv6 Prefix Delegation) and RFC 3736 (Stateless DHCPv6) so as to fix errata and bring the documents to the point where they can advance along the IETF Standards Track. 4. In the process of updating the DHCP base specifications, in cases where time is of the essence, issue corrections and clarifications of the specifications in order to quickly address interoperability problems. 5. Write analyses and interoperability reports on existing DHC documents, including base specs. 6. When serious interoperability problems are found in other DHCP specifications, issue updated versions of those specifications to address the interoperability problems. Milestones: Oct 2013 - Submit dhcpv6-failover-design to IESG Dec 2013 - WG last calll on draft-ietf-dhc-addr-registration Feb 2014 - Submit draft-ietf-dhc-addr-registration to IESG Mar 2014 - WG last call on access-network-identifier Jun 2014 - Submit access-network-identifier to IESG Sep 2014 - Submit stateful issues draft to IESG Sep 2014 - Adopt 3315bis draft Jan 2015 - WG last call on 331bis draft Apr 2015 - Submit 3315bis draft to IESG May 2015 - Recharter, if needed From nobody Fri Aug 8 10:17:52 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1F081A0046 for ; Fri, 8 Aug 2014 10:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 xYN3Jo2vB1l5 for ; Fri, 8 Aug 2014 10:17:41 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D82361A0002 for ; Fri, 8 Aug 2014 10:17:41 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 6BD691B83B1 for ; Fri, 8 Aug 2014 10:17:41 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 22DB753E070; Fri, 8 Aug 2014 10:17:41 -0700 (PDT) Received: from [10.0.10.40] (71.233.43.215) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 8 Aug 2014 10:17:40 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <2134F8430051B64F815C691A62D9831832CED674@XCH-BLV-504.nw.nos.boeing.com> Date: Fri, 8 Aug 2014 13:17:34 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <3B43E4B9-8658-48CF-9A3A-C4DC7560ABFF@nominum.com> References: <2134F8430051B64F815C691A62D9831832CECA61@XCH-BLV-504.nw.nos.boeing.com> <83E91E35-3F30-4659-B4AE-58DD11E74DB6@nominum.com> <2134F8430051B64F815C691A62D9831832CECB68@XCH-BLV-504.nw.nos.boeing.com> <075FB3EE-EA09-4CBD-AFE9-CF14E77ED007@nominum.com> <2134F8430051B64F815C691A62D9831832CECBF5@XCH-BLV-504.nw.nos.boeing.com> <9C369D15-88ED-4E1E-8138-A538760C6FDE@nominum.com> <2134F8430051B64F815C691A62D9831832CECC7B@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CECD1A@XCH-BLV-504.nw.nos.boeing.com> <35F4F6CF-7CBC-4935-9E9F-2EC946D7EBB7@nominum.com> <2134F8430051B64F815C691A62D9831832CED2CD@XCH-BLV-504.nw.nos.boeing.com> <65C2A9BF-B153-4BD0-89EF-6D7D8FE459B3@nominum.com> <2134F8430051B64F815C691A62D9831832CED559@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CED5E7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CED674@XCH-BLV-504.nw.nos.boeing.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/cCIyVryomf6DQoITvRPiCMkktmg Cc: "dhcwg@ietf.org" , Ralph Droms Subject: Re: [dhcwg] DHCPv6 RAAN options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 17:17:49 -0000 On Aug 8, 2014, at 12:48 PM, Templin, Fred L = wrote: > If I am understanding this correctly, then the RAAN option provides > a convenient way of relay agent gleaning. But, option 1 would still > allow for a slightly less convenient means for gleaning. Convenient for the relay agent, modulo path asymmetries. From nobody Fri Aug 8 10:29:34 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C507B1A0118 for ; Fri, 8 Aug 2014 10:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 H1f8hYJh-Lf6 for ; Fri, 8 Aug 2014 10:29:30 -0700 (PDT) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2A321A00D5 for ; Fri, 8 Aug 2014 10:29:30 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id i13so5821394qae.6 for ; Fri, 08 Aug 2014 10:29:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/l3902npLjqEPhmGDgtojHgW4Jm0OwR7/MP/RdDd+rg=; b=FWKByJtfTkVJGuscWHG3Er5/mlOukdSovS7ROPled0Jd2fjy0j1CCftUnfg7QMZu2g BsEUi35SYO/pEBpDqyUmPE41dJ1L3ctY4q7e8yov6fTObNtOtSORYC4HrZ1qa6A8/ztc UabtE3FXyI3van/IX9OI5rFZO0z9nON8qGpZBOqozsRDDKWQi29FYxYdEyoPViTL4R9C PFobgdFoYSKipBvekAp2EVomLrnvojIPfss46wNq3bM+1SG7D+F+W69lo/hh7OsK5Z5c WO204FVeHwp6nYD7Xto0gNNUsHuinzrNNnI7WCz0Nw0wb0wYeI8ajZWYTaCblc66NRSh AkNA== X-Received: by 10.224.67.2 with SMTP id p2mr40588008qai.37.1407518969943; Fri, 08 Aug 2014 10:29:29 -0700 (PDT) Received: from [10.82.101.34] (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPSA id o3sm6512383qab.21.2014.08.08.10.29.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Aug 2014 10:29:28 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ralph Droms In-Reply-To: <2134F8430051B64F815C691A62D9831832CED559@XCH-BLV-504.nw.nos.boeing.com> Date: Fri, 8 Aug 2014 13:29:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <36D48A0F-9175-482D-A86D-969F7E53D040@gmail.com> References: <2134F8430051B64F815C691A62D9831832CECA61@XCH-BLV-504.nw.nos.boeing.com> <83E91E35-3F30-4659-B4AE-58DD11E74DB6@nominum.com> <2134F8430051B64F815C691A62D9831832CECB68@XCH-BLV-504.nw.nos.boeing.com> <075FB3EE-EA09-4CBD-AFE9-CF14E77ED007@nominum.com> <2134F8430051B64F815C691A62D9831832CECBF5@XCH-BLV-504.nw.nos.boeing.com> <9C369D15-88ED-4E1E-8138-A538760C6FDE@nominum.com> <2134F8430051B64F815C691A62D9831832CECC7B@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CECD1A@XCH-BLV-504.nw.nos.boeing.com> <35F4F6CF-7CBC-4935-9E9F-2EC946D7EBB7@nominum.com> <2134F8430051B64F815C691A62D9831832CED2CD@XCH-BLV-504.nw.nos.boeing.com> <65C2A9BF-B153-4BD0-89EF-6D7D8FE459B3@nominum.com> <2134F8430051B64F815C691A62D9831832CED559@XCH-BLV-504.nw.nos.boeing.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/2O0CKtpvxxV7G50xyKHPZtOnLcU Cc: "dhcwg@ietf.org" , Ted Lemon Subject: Re: [dhcwg] DHCPv6 RAAN options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 17:29:33 -0000 On Aug 8, 2014, at 12:06 PM 8/8/14, Templin, Fred L = wrote: > Hi Ralph, >=20 >> -----Original Message----- >> From: Ralph Droms [mailto:rdroms.ietf@gmail.com] >> Sent: Friday, August 08, 2014 8:57 AM >> To: Ted Lemon >> Cc: Templin, Fred L; dhcwg@ietf.org >> Subject: Re: [dhcwg] DHCPv6 RAAN options >>=20 >>=20 >> On Aug 8, 2014, at 10:53 AM 8/8/14, Ted Lemon = wrote: >>=20 >>> On Aug 8, 2014, at 10:44 AM, Templin, Fred L = wrote: >>>> Write a little draft that (if approved) updates RFC3315? >>>=20 >>> That's the right process, if you can't get this into the 3315bis = effort. But it would have to go >> through the working group. I seem to be talking a lot on this = topic, but I'm only one working group >> participant, and not an active participant in the 3315bis effort. = Have any of the 3315bis people >> been following this discussion? Do you have thoughts on the matter? >>=20 >> If I recall correctly, draft-ietf-dhc-dhcpv6-agentopt-delegate-04 was = not published by the working >> group because of message transport and ordering concerns: no = guarantees that... >>=20 >> ...messages containing RAAN options will be delivered in order so = that the relay agent takes actions >> in the correct order >> ...transactions containing RAAN options will be forwarded through the = correct relay agent; e.g., the >> transaction delegating prefix P to device D might be forwarded = through relay agent R1, causing R1 to >> take action based on that delegation, while the subsequent = transaction releasing P might be forwarded >> through relay agent R2, which has no knowledge of the original = delegation >=20 > I have a case where the Client can steer its DHCPv6 messaging through = a > specific relay agent or agents by mapping = All_DHCP_Relay_Agents_and_Servers > to a unicast L2 address. I think there would probably also be = real-world > use cases where there is only one relay agent on the link - otherwise, = I > think PD might have problems in some environments. But, perhaps others > would know better. After a short conversation at lunch on this topic, I also recall (and = others with better memory should certainly correct me) that the WG = eventually came to the conclusion that piggybacking information for the = relay agent on client-server transactions is not a good design. A = protocol transaction (DHCP or something else) explicitly between the = relay agent and some control function (perhaps in the DHCP server, = perhaps elsewhere) would be a more robust design. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 >> - Ralph >>=20 >> PS I'm working from memory w/o bothering to research the mailing = list... >>>=20 >>> _______________________________________________ >>> dhcwg mailing list >>> dhcwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/dhcwg >=20 From nobody Fri Aug 8 10:40:52 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1C31A00D5 for ; Fri, 8 Aug 2014 10:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 fssVEpa_3s-i for ; Fri, 8 Aug 2014 10:40:49 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D82951A007D for ; Fri, 8 Aug 2014 10:40:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s78Hen6U023411; Fri, 8 Aug 2014 10:40:49 -0700 Received: from XCH-PHX-312.sw.nos.boeing.com (xch-phx-312.sw.nos.boeing.com [130.247.25.173]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s78Hej22023385 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 8 Aug 2014 10:40:45 -0700 Received: from XCH-BLV-406.nw.nos.boeing.com (2002:82f7:19a2::82f7:19a2) by XCH-PHX-312.sw.nos.boeing.com (2002:82f7:19ad::82f7:19ad) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 8 Aug 2014 10:40:45 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.6]) by XCH-BLV-406.nw.nos.boeing.com ([169.254.6.97]) with mapi id 14.03.0181.006; Fri, 8 Aug 2014 10:40:45 -0700 From: "Templin, Fred L" To: Ted Lemon Thread-Topic: [dhcwg] DHCPv6 RAAN options Thread-Index: Ac+yf+stS7sJIaihTkKQdnTDfuT8QwAPkPgAAA579MD//5LdgIAAdPIw//+RDACAAHTV8IAA4dxQ//67BgD//2x8wAAnctNw///+rmD//4QYAP//fRpg//6AaAD//XWcsP/6aiQA//VENvA= Date: Fri, 8 Aug 2014 17:40:44 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CED77A@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832CECA61@XCH-BLV-504.nw.nos.boeing.com> <83E91E35-3F30-4659-B4AE-58DD11E74DB6@nominum.com> <2134F8430051B64F815C691A62D9831832CECB68@XCH-BLV-504.nw.nos.boeing.com> <075FB3EE-EA09-4CBD-AFE9-CF14E77ED007@nominum.com> <2134F8430051B64F815C691A62D9831832CECBF5@XCH-BLV-504.nw.nos.boeing.com> <9C369D15-88ED-4E1E-8138-A538760C6FDE@nominum.com> <2134F8430051B64F815C691A62D9831832CECC7B@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CECD1A@XCH-BLV-504.nw.nos.boeing.com> <35F4F6CF-7CBC-4935-9E9F-2EC946D7EBB7@nominum.com> <2134F8430051B64F815C691A62D9831832CED2CD@XCH-BLV-504.nw.nos.boeing.com> <65C2A9BF-B153-4BD0-89EF-6D7D8FE459B3@nominum.com> <2134F8430051B64F815C691A62D9831832CED559@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CED5E7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CED674@XCH-BLV-504.nw.nos.boeing.com> <3B43E4B9-8658-48CF-9A3A-C4DC7560ABFF@nominum.com> In-Reply-To: <3B43E4B9-8658-48CF-9A3A-C4DC7560ABFF@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/P7c59y5xY6EtXyikig7BandF-Rk Cc: "dhcwg@ietf.org" , Ralph Droms Subject: Re: [dhcwg] DHCPv6 RAAN options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 17:40:51 -0000 Hi Ted, > -----Original Message----- > From: Ted Lemon [mailto:ted.lemon@nominum.com] > Sent: Friday, August 08, 2014 10:18 AM > To: Templin, Fred L > Cc: dhcwg@ietf.org; Ralph Droms > Subject: Re: [dhcwg] DHCPv6 RAAN options >=20 > On Aug 8, 2014, at 12:48 PM, Templin, Fred L = wrote: > > If I am understanding this correctly, then the RAAN option provides > > a convenient way of relay agent gleaning. But, option 1 would still > > allow for a slightly less convenient means for gleaning. >=20 > Convenient for the relay agent, modulo path asymmetries. Right. I think I also see from the recharter announcement that the second alternative would probably be met with less resistance in the working group. Thanks - Fred fred.l.templin@boeing.com From nobody Fri Aug 8 11:33:34 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DED611A0009 for ; Fri, 8 Aug 2014 11:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 yVPrKYm1s1Pj for ; Fri, 8 Aug 2014 11:33:30 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5D621A0008 for ; Fri, 8 Aug 2014 11:33:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s78IXUKZ006778; Fri, 8 Aug 2014 11:33:30 -0700 Received: from XCH-PHX-212.sw.nos.boeing.com (xch-phx-212.sw.nos.boeing.com [130.247.25.141]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s78IXOr8006730 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Fri, 8 Aug 2014 11:33:24 -0700 Received: from XCH-BLV-203.nw.nos.boeing.com (10.57.37.65) by XCH-PHX-212.sw.nos.boeing.com (130.247.25.141) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 8 Aug 2014 11:33:24 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.6]) by XCH-BLV-203.nw.nos.boeing.com ([169.254.3.44]) with mapi id 14.03.0181.006; Fri, 8 Aug 2014 11:33:23 -0700 From: "Templin, Fred L" To: "dhcwg@ietf.org" Thread-Topic: RFC3315(bis) comment Thread-Index: AQHPszc8KUdUb080f0+HHlHHQ0+hpQ== Date: Fri, 8 Aug 2014 18:33:23 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CED7FF@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832CECA61@XCH-BLV-504.nw.nos.boeing.com> <83E91E35-3F30-4659-B4AE-58DD11E74DB6@nominum.com> <2134F8430051B64F815C691A62D9831832CECB68@XCH-BLV-504.nw.nos.boeing.com> <075FB3EE-EA09-4CBD-AFE9-CF14E77ED007@nominum.com> <2134F8430051B64F815C691A62D9831832CECBF5@XCH-BLV-504.nw.nos.boeing.com> <9C369D15-88ED-4E1E-8138-A538760C6FDE@nominum.com> <2134F8430051B64F815C691A62D9831832CECC7B@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CECD1A@XCH-BLV-504.nw.nos.boeing.com> <35F4F6CF-7CBC-4935-9E9F-2EC946D7EBB7@nominum.com> <2134F8430051B64F815C691A62D9831832CED2CD@XCH-BLV-504.nw.nos.boeing.com> <65C2A9BF-B153-4BD0-89EF-6D7D8FE459B3@nominum.com> <2134F8430051B64F815C691A62D9831832CED559@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CED5E7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CED674@XCH-BLV-504.nw.nos.boeing.com> <3B43E4B9-8658-48CF-9A3A-C4DC7560ABFF@nominum.com> <2134F8430051B64F815C691A62D9831832CED77A@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832CED77A@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/cFxt_xKAJL1brP10_HpgZtUrw2o Subject: [dhcwg] RFC3315(bis) comment X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 18:33:33 -0000 Hello, In Section 18.2.6 of 'draft-dhcwg-dhc-rfc3315bis-02.txt' the next to last paragraph of the section currently states: "After all the addresses have been processed, the server generates a Reply message and includes a Status Code option with value Success, a Server Identifier option with the server's DUID, and a Client Identifier option with the client's DUID. For each IA in the Release message for which the server has no binding information, the server adds an IA option using the IAID from the Release message, and includes a Status Code option with the value NoBinding in the IA option. No other options are included in the IA option." According to this specification, the server does not include any information about IAs that were successfully released in the transaction. Therefore, relays that need to "glean" client-server transactions will have no way of knowing that the Release was successfully executed by the server. A proposed resolution is to add an additional specification to this paragraph as follows: "After all the addresses have been processed, the server generates a Reply message and includes a Status Code option with value Success, a Server Identifier option with the server's DUID, and a Client Identifier option with the client's DUID. For each IA in the Release message for which the server has released binding information, the server adds an IA option using the IAID from the Release message with both preferred-lifetime and valid-lifetime set to 0 in the IA Address/Prefix option, and includes a Status Code option with the value Success in the IA option. For each IA in the Release message for which the server has no binding information, the server adds an IA option using the IAID from the Release message, and includes a Status Code option with the value NoBinding in the IA option. No other options are included in the IA option." Comments? Questions? Thanks - Fred fred.l.templin@boeing.com From nobody Fri Aug 8 12:32:57 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 288501A02A5 for ; Fri, 8 Aug 2014 12:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 6ZdTzVdQQt-T for ; Fri, 8 Aug 2014 12:32:55 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0A5F1A0175 for ; Fri, 8 Aug 2014 12:32:54 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 9E9D41B83B3 for ; Fri, 8 Aug 2014 12:32:54 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 5AFCD53E073; Fri, 8 Aug 2014 12:32:54 -0700 (PDT) Received: from [10.0.10.40] (71.233.43.215) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 8 Aug 2014 12:32:54 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <2134F8430051B64F815C691A62D9831832CED7FF@XCH-BLV-504.nw.nos.boeing.com> Date: Fri, 8 Aug 2014 15:32:45 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <89774E70-1F87-4A8F-9540-7119316FD2E9@nominum.com> References: <2134F8430051B64F815C691A62D9831832CECA61@XCH-BLV-504.nw.nos.boeing.com> <83E91E35-3F30-4659-B4AE-58DD11E74DB6@nominum.com> <2134F8430051B64F815C691A62D9831832CECB68@XCH-BLV-504.nw.nos.boeing.com> <075FB3EE-EA09-4CBD-AFE9-CF14E77ED007@nominum.com> <2134F8430051B64F815C691A62D9831832CECBF5@XCH-BLV-504.nw.nos.boeing.com> <9C369D15-88ED-4E1E-8138-A538760C6FDE@nominum.com> <2134F8430051B64F815C691A62D9831832CECC7B@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CECD1A@XCH-BLV-504.nw.nos.boeing.com> <35F4F6CF-7CBC-4935-9E9F-2EC946D7EBB7@nominum.com> <2134F8430051B64F815C691A62D9831832CED2CD@XCH-BLV-504.nw.nos.boeing.com> <65C2A9BF-B153-4BD0-89EF-6D7D8FE459B3@nominum.com> <2134F8430051B64F815C691A62D9831832CED559@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CED5E7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CED674@XCH-BLV-504.nw.nos.boeing.com> <3B43E4B9-8658-48CF-9A3A-C4DC7560ABFF@nominum.com> <2134F8430051B64F815C691A62D9831832CED77A@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CED7FF@XCH-BLV-504.nw.nos.boeing.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/ZsK2i0q_2BwWLJdA-xz0WpGP6I8 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] RFC3315(bis) comment X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 19:32:56 -0000 On Aug 8, 2014, at 2:33 PM, Templin, Fred L = wrote: > Comments? Questions? WFM, although that's a pretty long paragraph. I think this solves a = real problem and is worth doing. From nobody Fri Aug 8 12:39:02 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6171A014A for ; Fri, 8 Aug 2014 12:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 4y1W-_p_3F0O for ; Fri, 8 Aug 2014 12:38:59 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB5271A0114 for ; Fri, 8 Aug 2014 12:38:59 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id C33931B83B1 for ; Fri, 8 Aug 2014 12:38:59 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id B3EA953E070; Fri, 8 Aug 2014 12:38:59 -0700 (PDT) Received: from [10.0.10.40] (71.233.43.215) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 8 Aug 2014 12:38:54 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <89774E70-1F87-4A8F-9540-7119316FD2E9@nominum.com> Date: Fri, 8 Aug 2014 15:38:45 -0400 Content-Transfer-Encoding: 7bit Message-ID: <7222A66E-94AB-4D92-B930-CA3A3742423A@nominum.com> References: <2134F8430051B64F815C691A62D9831832CECA61@XCH-BLV-504.nw.nos.boeing.com> <83E91E35-3F30-4659-B4AE-58DD11E74DB6@nominum.com> <2134F8430051B64F815C691A62D9831832CECB68@XCH-BLV-504.nw.nos.boeing.com> <075FB3EE-EA09-4CBD-AFE9-CF14E77ED007@nominum.com> <2134F8430051B64F815C691A62D9831832CECBF5@XCH-BLV-504.nw.nos.boeing.com> <9C369D15-88ED-4E1E-8138-A538760C6FDE@nominum.com> <2134F8430051B64F815C691A62D9831832CECC7B@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CECD1A@XCH-BLV-504.nw.nos.boeing.com> <35F4F6CF-7CBC-4935-9E9F-2EC946D7EBB7@nominum.com> <2134F8430051B64F815C691A62D9831832CED2CD@XCH-BLV-504.nw.nos.boeing.com> <65C2A9BF-B153-4BD0-89EF-6D7D8FE459B3@nominum.com> <2134F8430051B64F815C691A62D9831832CED559@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CED5E7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CED674@XCH-BLV-504.nw.nos.boeing.com> <3B43E4B9-8658-48CF-9A3A-C4DC7560ABFF@nominum.com> <2134F8430051B64F815C691A62D9831832CED77A@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CED7FF@XCH-BLV-504.nw.nos.boeing.com> <89774E70-1F87-4A8F-9540-7119316FD2E9@nominum.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/_O5u4VZLjQQMrTenMWDozpN9K0g Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] RFC3315(bis) comment X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 19:39:01 -0000 On Aug 8, 2014, at 3:32 PM, Ted Lemon wrote: > I think this solves a real problem and is worth doing. (and, rather importantly, I think it's unlikely to break anything.) From nobody Fri Aug 8 12:52:45 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C91941A03C4 for ; Fri, 8 Aug 2014 12:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 WkoH6UK4ZCJh for ; Fri, 8 Aug 2014 12:52:40 -0700 (PDT) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDF4E1A03BB for ; Fri, 8 Aug 2014 12:52:40 -0700 (PDT) Received: by mail-qg0-f54.google.com with SMTP id z60so6714371qgd.27 for ; Fri, 08 Aug 2014 12:52:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=iu8weeETtXzW/cOi9sDq/J4xzqzY9KTwNtPwJMlqSK4=; b=SK7rAX/VASRQwycwubYj443yh23KPWbuwESVvaGcRslNMIi18is1Bun7VHmdGqG+7K XO1MCtV3bLf9t/ClsZIyjG45Qq698UlgcCMKk5uUCOKJ6UzA5cHsI2gkTqvqH3XCh1jl xJiRBv/ikdz00cNZJxA9dXL+064oMo45iKRorOgDyJhgMqvooykkq2QrpVUWrhZWR4L3 7FuCu0U3VdAOFU8RfnPHNvxhIGnXV+Q0PfvIx10QWbgcBG3HLAv2OfkHbJaAp+Plpd7J DFRRuhXOUDSN1wnD16+V2nYGe05O9rCrp6u50l6hV/p6J7kx0ksWVSQqxdkbtv3CyUG9 oblg== X-Received: by 10.224.0.141 with SMTP id 13mr40940110qab.26.1407527559900; Fri, 08 Aug 2014 12:52:39 -0700 (PDT) Received: from [10.82.101.34] (rtp-isp-nat-pool1-1.cisco.com. [64.102.254.34]) by mx.google.com with ESMTPSA id l76sm4574034qga.8.2014.08.08.12.52.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Aug 2014 12:52:37 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ralph Droms In-Reply-To: <2134F8430051B64F815C691A62D9831832CED7FF@XCH-BLV-504.nw.nos.boeing.com> Date: Fri, 8 Aug 2014 15:52:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2134F8430051B64F815C691A62D9831832CECA61@XCH-BLV-504.nw.nos.boeing.com> <83E91E35-3F30-4659-B4AE-58DD11E74DB6@nominum.com> <2134F8430051B64F815C691A62D9831832CECB68@XCH-BLV-504.nw.nos.boeing.com> <075FB3EE-EA09-4CBD-AFE9-CF14E77ED007@nominum.com> <2134F8430051B64F815C691A62D9831832CECBF5@XCH-BLV-504.nw.nos.boeing.com> <9C369D15-88ED-4E1E-8138-A538760C6FDE@nominum.com> <2134F8430051B64F815C691A62D9831832CECC7B@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CECD1A@XCH-BLV-504.nw.nos.boeing.com> <35F4F6CF-7CBC-4935-9E9F-2EC946D7EBB7@nominum.com> <2134F8430051B64F815C691A62D9831832CED2CD@XCH-BLV-504.nw.nos.boeing.com> <65C2A9BF-B153-4BD0-89EF-6D7D8FE459B3@nominum.com> <2134F8430051B64F815C691A62D9831832CED559@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CED5E7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CED674@XCH-BLV-504.nw.nos.boeing.com> <3B43E4B9-8658-48CF-9A3A-C4DC7560ABFF@nominum.com> <2134F8430051B64F815C691A62D9831832CED77A@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CED7FF@XCH-BLV-504.nw.nos.boeing.com> To: "dhcwg@ietf.org" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/Zu9VpC_a0_An63bnNeeYxf-XXJg Subject: Re: [dhcwg] RFC3315(bis) comment X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 19:52:43 -0000 I think the text needs a full disclosure warning to the effect that = there is no guarantee that the Release-Reply transaction will traverse = the same relay agent as other transactions. - Ralph On Aug 8, 2014, at 2:33 PM 8/8/14, Templin, Fred L = wrote: > Hello, >=20 > In Section 18.2.6 of 'draft-dhcwg-dhc-rfc3315bis-02.txt' the next to > last paragraph of the section currently states: >=20 > "After all the addresses have been processed, the server generates a > Reply message and includes a Status Code option with value Success, = a > Server Identifier option with the server's DUID, and a Client > Identifier option with the client's DUID. For each IA in the = Release > message for which the server has no binding information, the server > adds an IA option using the IAID from the Release message, and > includes a Status Code option with the value NoBinding in the IA > option. No other options are included in the IA option." >=20 > According to this specification, the server does not include any > information about IAs that were successfully released in the > transaction. Therefore, relays that need to "glean" client-server > transactions will have no way of knowing that the Release was > successfully executed by the server. >=20 > A proposed resolution is to add an additional specification to this > paragraph as follows: >=20 > "After all the addresses have been processed, the server generates a > Reply message and includes a Status Code option with value Success, = a > Server Identifier option with the server's DUID, and a Client > Identifier option with the client's DUID. For each IA in the = Release > message for which the server has released binding information, the > server adds an IA option using the IAID from the Release message = with > both preferred-lifetime and valid-lifetime set to 0 in the IA > Address/Prefix option, and includes a Status Code option with the > value Success in the IA option. For each IA in the Release message = for > which the server has no binding information, the server adds an IA > option using the IAID from the Release message, and includes a = Status > Code option with the value NoBinding in the IA option. No other > options are included in the IA option." >=20 > Comments? Questions? >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From nobody Fri Aug 8 15:39:37 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6B691A0161 for ; Fri, 8 Aug 2014 15:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 1Vj3SZI2akQL for ; Fri, 8 Aug 2014 15:39:31 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 083841A0154 for ; Fri, 8 Aug 2014 15:39:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s78MdTEm011459; Fri, 8 Aug 2014 17:39:29 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com (xch-blv-504.nw.nos.boeing.com [130.247.25.194]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s78MdP6B011436 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 8 Aug 2014 17:39:26 -0500 Received: from XCH-BLV-205.nw.nos.boeing.com (10.57.37.61) by XCH-BLV-504.nw.nos.boeing.com (130.247.25.194) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 8 Aug 2014 15:39:25 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.6]) by XCH-BLV-205.nw.nos.boeing.com ([169.254.5.190]) with mapi id 14.03.0181.006; Fri, 8 Aug 2014 15:39:24 -0700 From: "Templin, Fred L" To: Ralph Droms , "dhcwg@ietf.org" Thread-Topic: [dhcwg] RFC3315(bis) comment Thread-Index: AQHPszc8KUdUb080f0+HHlHHQ0+hpZvHk4OA//+0FvA= Date: Fri, 8 Aug 2014 22:39:24 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CED9D3@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832CECA61@XCH-BLV-504.nw.nos.boeing.com> <83E91E35-3F30-4659-B4AE-58DD11E74DB6@nominum.com> <2134F8430051B64F815C691A62D9831832CECB68@XCH-BLV-504.nw.nos.boeing.com> <075FB3EE-EA09-4CBD-AFE9-CF14E77ED007@nominum.com> <2134F8430051B64F815C691A62D9831832CECBF5@XCH-BLV-504.nw.nos.boeing.com> <9C369D15-88ED-4E1E-8138-A538760C6FDE@nominum.com> <2134F8430051B64F815C691A62D9831832CECC7B@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CECD1A@XCH-BLV-504.nw.nos.boeing.com> <35F4F6CF-7CBC-4935-9E9F-2EC946D7EBB7@nominum.com> <2134F8430051B64F815C691A62D9831832CED2CD@XCH-BLV-504.nw.nos.boeing.com> <65C2A9BF-B153-4BD0-89EF-6D7D8FE459B3@nominum.com> <2134F8430051B64F815C691A62D9831832CED559@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CED5E7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CED674@XCH-BLV-504.nw.nos.boeing.com> <3B43E4B9-8658-48CF-9A3A-C4DC7560ABFF@nominum.com> <2134F8430051B64F815C691A62D9831832CED77A@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CED7FF@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/iBoyfId2nwzKLRKsZM8VsUvudco Subject: Re: [dhcwg] RFC3315(bis) comment X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 22:39:33 -0000 Hi Ralph, > -----Original Message----- > From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ralph Droms > Sent: Friday, August 08, 2014 12:53 PM > To: dhcwg@ietf.org > Subject: Re: [dhcwg] RFC3315(bis) comment >=20 > I think the text needs a full disclosure warning to the effect that there= is no guarantee that the > Release-Reply transaction will traverse the same relay agent as other tra= nsactions. I think I understand the point, but this would not harm any relays that were not on the original {Solicit/Request}-Reply path; they would simply see that the client's IAs have been released regardless of which relay they were initially established through. I think the more dangerous case is for relays that would glean information from the initial {Solicit/Request}-reply path; unless the relay has some way of knowing that any subsequent Release would come through itself and not through a different relay it cannot safely do the gleaning. But, there is no warning label in the spec about that. The information I am suggesting in my proposed text would also provide potentially useful information to the client in the form of a positive confirmation of the release of individual IAs independent of what any relays might do. So, other documents that suggest relay gleaning would be the place to explain the circumstances under which gleaning can be applied. All of that said, do we really want to fully examine relay gleaning in both the forward and reverse paths in the RFC3315(bis) base spec? I hope not, but maybe that is what you were thinking? Thanks - Fred fred.l.templin@boeing.com=20 > - Ralph >=20 > On Aug 8, 2014, at 2:33 PM 8/8/14, Templin, Fred L wrote: >=20 > > Hello, > > > > In Section 18.2.6 of 'draft-dhcwg-dhc-rfc3315bis-02.txt' the next to > > last paragraph of the section currently states: > > > > "After all the addresses have been processed, the server generates a > > Reply message and includes a Status Code option with value Success, a > > Server Identifier option with the server's DUID, and a Client > > Identifier option with the client's DUID. For each IA in the Release > > message for which the server has no binding information, the server > > adds an IA option using the IAID from the Release message, and > > includes a Status Code option with the value NoBinding in the IA > > option. No other options are included in the IA option." > > > > According to this specification, the server does not include any > > information about IAs that were successfully released in the > > transaction. Therefore, relays that need to "glean" client-server > > transactions will have no way of knowing that the Release was > > successfully executed by the server. > > > > A proposed resolution is to add an additional specification to this > > paragraph as follows: > > > > "After all the addresses have been processed, the server generates a > > Reply message and includes a Status Code option with value Success, a > > Server Identifier option with the server's DUID, and a Client > > Identifier option with the client's DUID. For each IA in the Release > > message for which the server has released binding information, the > > server adds an IA option using the IAID from the Release message with > > both preferred-lifetime and valid-lifetime set to 0 in the IA > > Address/Prefix option, and includes a Status Code option with the > > value Success in the IA option. For each IA in the Release message fo= r > > which the server has no binding information, the server adds an IA > > option using the IAID from the Release message, and includes a Status > > Code option with the value NoBinding in the IA option. No other > > options are included in the IA option." > > > > Comments? Questions? > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www.ietf.org/mailman/listinfo/dhcwg >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From nobody Sat Aug 9 05:13:18 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD061A02D1 for ; Sat, 9 Aug 2014 05:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 9QQSfCbtcWdh for ; Sat, 9 Aug 2014 05:13:10 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE4DD1A039C for ; Sat, 9 Aug 2014 05:13:10 -0700 (PDT) Received: by mail-qg0-f52.google.com with SMTP id f51so6972618qge.39 for ; Sat, 09 Aug 2014 05:13:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zi2j5TIjUryvZTcifF5WjuUpjpeSaKLaWaoBvkZ4L9U=; b=EMHvpR8Cy/Rilv4arrj4rqnj0xBenn4wMw8xybolqyuAdTvYvrd4xfC4avnXNOCm+S LqtnGW+OxmF6vzBLGo89ERfzFs7qEdw4SlemoK2yJhqvoAMGTs/g26uwJ7Oo1sni3pwB kzn++JxQVs/dVoBSb/z+d0kI6+MdgOaAkyR1ao/2S1Vt2TUTnIJs+63IQzoQKr+DLaEW Ji+g0/4H37p9g/22PupIH8gzb6c2yQwbBDZplpVFzKOeJ1b5J3prPrjAcLp23slhLyvq sdjejTBUNPwZeBqBFB/yBvaG7JpKTf2O2MbwaFejxuNJq0z+ETTYFVw2VSfW9i6xHpJn NVHg== X-Received: by 10.224.120.138 with SMTP id d10mr47561775qar.55.1407586389837; Sat, 09 Aug 2014 05:13:09 -0700 (PDT) Received: from [10.116.164.53] (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPSA id q68sm6870130qgq.36.2014.08.09.05.13.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 09 Aug 2014 05:13:08 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Ralph Droms X-Mailer: iPad Mail (11D257) In-Reply-To: <2134F8430051B64F815C691A62D9831832CED9D3@XCH-BLV-504.nw.nos.boeing.com> Date: Sat, 9 Aug 2014 08:13:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9E184648-12AC-4B38-8B51-6B384EA441A4@gmail.com> References: <2134F8430051B64F815C691A62D9831832CECA61@XCH-BLV-504.nw.nos.boeing.com> <83E91E35-3F30-4659-B4AE-58DD11E74DB6@nominum.com> <2134F8430051B64F815C691A62D9831832CECB68@XCH-BLV-504.nw.nos.boeing.com> <075FB3EE-EA09-4CBD-AFE9-CF14E77ED007@nominum.com> <2134F8430051B64F815C691A62D9831832CECBF5@XCH-BLV-504.nw.nos.boeing.com> <9C369D15-88ED-4E1E-8138-A538760C6FDE@nominum.com> <2134F8430051B64F815C691A62D9831832CECC7B@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CECD1A@XCH-BLV-504.nw.nos.boeing.com> <35F4F6CF-7CBC-4935-9E9F-2EC946D7EBB7@nominum.com> <2134F8430051B64F815C691A62D9831832CED2CD@XCH-BLV-504.nw.nos.boeing.com> <65C2A9BF-B153-4BD0-89EF-6D7D8FE459B3@nominum.com> <2134F8430051B64F815C691A62D9831832CED559@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CED5E7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CED674@XCH-BLV-504.nw.nos.boeing.com> <3B43E4B9-8658-48CF-9A3A-C4DC7560ABFF@nominum.com> <2134F8430051B64F815C691A62D9831832CED77A@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CED7FF@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CED9D3@XCH-BLV-504.nw.nos.boeing.com> To: "Templin, Fred L" Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/euLVZI3EafBFv-R2N8jAhSeksFY Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] RFC3315(bis) comment X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2014 12:13:13 -0000 > On Aug 8, 2014, at 6:39 PM, "Templin, Fred L" w= rote: >=20 > Hi Ralph, >=20 >> -----Original Message----- >> From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ralph Droms >> Sent: Friday, August 08, 2014 12:53 PM >> To: dhcwg@ietf.org >> Subject: Re: [dhcwg] RFC3315(bis) comment >>=20 >> I think the text needs a full disclosure warning to the effect that there= is no guarantee that the >> Release-Reply transaction will traverse the same relay agent as other tra= nsactions. >=20 > I think I understand the point, but this would not harm any relays that > were not on the original {Solicit/Request}-Reply path; they would simply > see that the client's IAs have been released regardless of which relay > they were initially established through. I think the more dangerous case > is for relays that would glean information from the initial > {Solicit/Request}-reply path; unless the relay has some way of knowing > that any subsequent Release would come through itself and not through a > different relay it cannot safely do the gleaning. More generally, the technique of transporting the RAAN option or extending t= he Reply message to enable gleaning - in my opinion, the two are equivalent f= or managing state in relay agents - was considered to be the wrong architect= ure for managing state in relay agents. As you point out, there is no guara= ntee that subsequent transactions will be forwarded by the relevant relay ag= ent. The messages may not be delivered in the correct order. Finally, ther= e may not be a client-server transaction available when the relay agent stat= e needs to be updated. > But, there is no > warning label in the spec about that. My suggestion is to add such a warning label to this option, if it is intend= ed to enable gleaning/snooping. >=20 > The information I am suggesting in my proposed text would also provide > potentially useful information to the client in the form of a positive > confirmation of the release of individual IAs independent of what any > relays might do. So, other documents that suggest relay gleaning would > be the place to explain the circumstances under which gleaning can be > applied. Do you have an explicit use case for informing the client of the success of t= he release? >=20 > All of that said, do we really want to fully examine relay gleaning > in both the forward and reverse paths in the RFC3315(bis) base spec? > I hope not, but maybe that is what you were thinking? Relay gleaning is, to my mind, sort of a bad idea but it seems to be popular= and the solution of choice in certain situations. Note that I am speaking s= trictly from an architecture point of view; those operating DHCP services ma= y have a different opinion. >=20 > Thanks - Fred > fred.l.templin@boeing.com=20 >=20 >> - Ralph >>=20 >>> On Aug 8, 2014, at 2:33 PM 8/8/14, Templin, Fred L wrote: >>>=20 >>> Hello, >>>=20 >>> In Section 18.2.6 of 'draft-dhcwg-dhc-rfc3315bis-02.txt' the next to >>> last paragraph of the section currently states: >>>=20 >>> "After all the addresses have been processed, the server generates a >>> Reply message and includes a Status Code option with value Success, a >>> Server Identifier option with the server's DUID, and a Client >>> Identifier option with the client's DUID. For each IA in the Release >>> message for which the server has no binding information, the server >>> adds an IA option using the IAID from the Release message, and >>> includes a Status Code option with the value NoBinding in the IA >>> option. No other options are included in the IA option." >>>=20 >>> According to this specification, the server does not include any >>> information about IAs that were successfully released in the >>> transaction. Therefore, relays that need to "glean" client-server >>> transactions will have no way of knowing that the Release was >>> successfully executed by the server. >>>=20 >>> A proposed resolution is to add an additional specification to this >>> paragraph as follows: >>>=20 >>> "After all the addresses have been processed, the server generates a >>> Reply message and includes a Status Code option with value Success, a >>> Server Identifier option with the server's DUID, and a Client >>> Identifier option with the client's DUID. For each IA in the Release >>> message for which the server has released binding information, the >>> server adds an IA option using the IAID from the Release message with >>> both preferred-lifetime and valid-lifetime set to 0 in the IA >>> Address/Prefix option, and includes a Status Code option with the >>> value Success in the IA option. For each IA in the Release message for >>> which the server has no binding information, the server adds an IA >>> option using the IAID from the Release message, and includes a Status >>> Code option with the value NoBinding in the IA option. No other >>> options are included in the IA option." >>>=20 >>> Comments? Questions? >>>=20 >>> Thanks - Fred >>> fred.l.templin@boeing.com >>>=20 >>> _______________________________________________ >>> dhcwg mailing list >>> dhcwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/dhcwg >>=20 >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg From nobody Mon Aug 11 08:46:02 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7D61A0515 for ; Mon, 11 Aug 2014 08:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham 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 Ja5AO_7ebrED for ; Mon, 11 Aug 2014 08:45:58 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 804131A050E for ; Mon, 11 Aug 2014 08:45:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s7BFjvIh028679; Mon, 11 Aug 2014 10:45:57 -0500 Received: from XCH-PHX-510.sw.nos.boeing.com (xch-phx-510.sw.nos.boeing.com [10.57.37.27]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s7BFjsEc028157 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 11 Aug 2014 10:45:54 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.6]) by XCH-PHX-510.sw.nos.boeing.com ([169.254.10.81]) with mapi id 14.03.0181.006; Mon, 11 Aug 2014 08:45:53 -0700 From: "Templin, Fred L" To: Ralph Droms Thread-Topic: [dhcwg] RFC3315(bis) comment Thread-Index: AQHPszc8KUdUb080f0+HHlHHQ0+hpZvHk4OA//+0FvCAAV3fgIAC46Eg Date: Mon, 11 Aug 2014 15:45:53 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CEE7A3@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832CECA61@XCH-BLV-504.nw.nos.boeing.com> <83E91E35-3F30-4659-B4AE-58DD11E74DB6@nominum.com> <2134F8430051B64F815C691A62D9831832CECB68@XCH-BLV-504.nw.nos.boeing.com> <075FB3EE-EA09-4CBD-AFE9-CF14E77ED007@nominum.com> <2134F8430051B64F815C691A62D9831832CECBF5@XCH-BLV-504.nw.nos.boeing.com> <9C369D15-88ED-4E1E-8138-A538760C6FDE@nominum.com> <2134F8430051B64F815C691A62D9831832CECC7B@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CECD1A@XCH-BLV-504.nw.nos.boeing.com> <35F4F6CF-7CBC-4935-9E9F-2EC946D7EBB7@nominum.com> <2134F8430051B64F815C691A62D9831832CED2CD@XCH-BLV-504.nw.nos.boeing.com> <65C2A9BF-B153-4BD0-89EF-6D7D8FE459B3@nominum.com> <2134F8430051B64F815C691A62D9831832CED559@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CED5E7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CED674@XCH-BLV-504.nw.nos.boeing.com> <3B43E4B9-8658-48CF-9A3A-C4DC7560ABFF@nominum.com> <2134F8430051B64F815C691A62D9831832CED77A@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CED7FF@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CED9D3@XCH-BLV-504.nw.nos.boeing.com> <9E184648-12AC-4B38-8B51-6B384EA441A4@gmail.com> In-Reply-To: <9E184648-12AC-4B38-8B51-6B384EA441A4@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/BgB9okGJh3yPwbnEcE1XqasnMG8 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] RFC3315(bis) comment X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 15:46:00 -0000 Hi Ralph, OK, if I understand you correctly then maybe what would work would be 1-2 paragraphs added to RFC3315(bis) to discuss the practice of relay agent gleaning. So, maybe add a new Section 20.1.4 something to the effect of: "20.1.4 Relay Agent Gleaning In operational practice, relay agents are often configured to examine address and prefix information contained in client-server transactions, e.g., for the purpose of injecting and withdrawing information in the routing system. This practice (sometimes known as "gleaning") has known operational limitations. In particular, relay agents SHOULD NOT perform gleaning unless there is operational assurance that the path from the client to server will will always travel through the same agent, and that no transaction reordering will occur. Furthermore, relay agents SHOULD NOT perform gleaning based solely on the client's requests to the server since the messages may be rejected, e.g., due to authentication failure. If any gleaning is to be done, it should therefore be based on the server's replies to the client." You also asked about a use case for informing the client of the success of the release. My AERO proposal is one such use case, but certainly not the only one. In general, in any environment in which a client's request to the server is subject to authentication, the relay agent should only perform gleaning on the server's reply to the client. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: Ralph Droms [mailto:rdroms.ietf@gmail.com] > Sent: Saturday, August 09, 2014 5:13 AM > To: Templin, Fred L > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] RFC3315(bis) comment >=20 >=20 >=20 > > On Aug 8, 2014, at 6:39 PM, "Templin, Fred L" wrote: > > > > Hi Ralph, > > > >> -----Original Message----- > >> From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ralph Droms > >> Sent: Friday, August 08, 2014 12:53 PM > >> To: dhcwg@ietf.org > >> Subject: Re: [dhcwg] RFC3315(bis) comment > >> > >> I think the text needs a full disclosure warning to the effect that th= ere is no guarantee that the > >> Release-Reply transaction will traverse the same relay agent as other = transactions. > > > > I think I understand the point, but this would not harm any relays that > > were not on the original {Solicit/Request}-Reply path; they would simpl= y > > see that the client's IAs have been released regardless of which relay > > they were initially established through. I think the more dangerous cas= e > > is for relays that would glean information from the initial > > {Solicit/Request}-reply path; unless the relay has some way of knowing > > that any subsequent Release would come through itself and not through a > > different relay it cannot safely do the gleaning. >=20 > More generally, the technique of transporting the RAAN option or extendin= g the Reply message to enable > gleaning - in my opinion, the two are equivalent for managing state in re= lay agents - was considered > to be the wrong architecture for managing state in relay agents. As you = point out, there is no > guarantee that subsequent transactions will be forwarded by the relevant = relay agent. The messages > may not be delivered in the correct order. Finally, there may not be a c= lient-server transaction > available when the relay agent state needs to be updated. >=20 > > But, there is no > > warning label in the spec about that. >=20 > My suggestion is to add such a warning label to this option, if it is int= ended to enable > gleaning/snooping. >=20 > > > > The information I am suggesting in my proposed text would also provide > > potentially useful information to the client in the form of a positive > > confirmation of the release of individual IAs independent of what any > > relays might do. So, other documents that suggest relay gleaning would > > be the place to explain the circumstances under which gleaning can be > > applied. >=20 > Do you have an explicit use case for informing the client of the success = of the release? >=20 > > > > All of that said, do we really want to fully examine relay gleaning > > in both the forward and reverse paths in the RFC3315(bis) base spec? > > I hope not, but maybe that is what you were thinking? >=20 > Relay gleaning is, to my mind, sort of a bad idea but it seems to be popu= lar and the solution of > choice in certain situations. Note that I am speaking strictly from an a= rchitecture point of view; > those operating DHCP services may have a different opinion. >=20 > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > >> - Ralph > >> > >>> On Aug 8, 2014, at 2:33 PM 8/8/14, Templin, Fred L wrote: > >>> > >>> Hello, > >>> > >>> In Section 18.2.6 of 'draft-dhcwg-dhc-rfc3315bis-02.txt' the next to > >>> last paragraph of the section currently states: > >>> > >>> "After all the addresses have been processed, the server generates a > >>> Reply message and includes a Status Code option with value Success, = a > >>> Server Identifier option with the server's DUID, and a Client > >>> Identifier option with the client's DUID. For each IA in the Releas= e > >>> message for which the server has no binding information, the server > >>> adds an IA option using the IAID from the Release message, and > >>> includes a Status Code option with the value NoBinding in the IA > >>> option. No other options are included in the IA option." > >>> > >>> According to this specification, the server does not include any > >>> information about IAs that were successfully released in the > >>> transaction. Therefore, relays that need to "glean" client-server > >>> transactions will have no way of knowing that the Release was > >>> successfully executed by the server. > >>> > >>> A proposed resolution is to add an additional specification to this > >>> paragraph as follows: > >>> > >>> "After all the addresses have been processed, the server generates a > >>> Reply message and includes a Status Code option with value Success, = a > >>> Server Identifier option with the server's DUID, and a Client > >>> Identifier option with the client's DUID. For each IA in the Releas= e > >>> message for which the server has released binding information, the > >>> server adds an IA option using the IAID from the Release message wit= h > >>> both preferred-lifetime and valid-lifetime set to 0 in the IA > >>> Address/Prefix option, and includes a Status Code option with the > >>> value Success in the IA option. For each IA in the Release message f= or > >>> which the server has no binding information, the server adds an IA > >>> option using the IAID from the Release message, and includes a Statu= s > >>> Code option with the value NoBinding in the IA option. No other > >>> options are included in the IA option." > >>> > >>> Comments? Questions? > >>> > >>> Thanks - Fred > >>> fred.l.templin@boeing.com > >>> > >>> _______________________________________________ > >>> dhcwg mailing list > >>> dhcwg@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dhcwg > >> > >> _______________________________________________ > >> dhcwg mailing list > >> dhcwg@ietf.org > >> https://www.ietf.org/mailman/listinfo/dhcwg From nobody Tue Aug 12 22:51:43 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFC21A6FEE for ; Tue, 12 Aug 2014 22:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham 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 686Atkr-J4nO for ; Tue, 12 Aug 2014 22:51:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EC601A6FF0 for ; Tue, 12 Aug 2014 22:51:25 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLE33258; Wed, 13 Aug 2014 05:51:24 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 13 Aug 2014 06:51:23 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.78]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Wed, 13 Aug 2014 13:51:19 +0800 From: Sheng Jiang To: "dhcwg@ietf.org" Thread-Topic: draft DHC meeting minutes Thread-Index: Ac+2upuh7YoQHY4/QqaL4wm+EJ+sGQ== Date: Wed, 13 Aug 2014 05:51:18 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AF09B40@nkgeml512-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/XYWlwdHZUExxBs5grqlmA6c3IwQ Subject: [dhcwg] draft DHC meeting minutes X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 05:51:42 -0000 SGksIERIQyBXRywNCg0KVGhlIGJlbG93IGlzIHRoZSBkcmFmdCBESEMgV0cgbWVldGluZyBtaW51 dGVzLiBJZiB0aGVyZSBpcyBhbnkgY29ycmVjdGlvbnMsIHBsZWFzZSBzZW5kIHRvIERIQyBXRyBz ZWNyZXRhcnkgU2hlbmcgSmlhbmcgKEppYW5nc2hlbmdAaHVhd2VpLmNvbSkuDQoNCkJlc3QgcmVn YXJkcywNCg0KU2hlbmcNCg0KREhDIG1lZXRpbmcgc3RhcnQgYXQgOWFtLCBTYWxvb24gcm9vbSBC LCAyMyBKdWx5IDIwMTQuDQoNCkFuZHJldyB2b2x1bnRlZXJlZCBhcyBqYWJiZXIgc2NyaWJlLiBU aGFua3MhDQoNClNoZW5nIGhhcyBiZWVuIGFzc2lnbmVkIGFzIERIQyBzZWNyZXRhcnkNCg0KV0cg ZG9jdW1lbnRzIHN0YXR1cyByZXZpZXcNCg0KU2hlbmc6IHdlIGhhdmVuJ3QgZm91bmQgc29saWQg dXNlIGNhc2Ugb2YgU3RhdGVsZXNzIFJlY29uZmlndXJhdGlvbg0KDQpTaGVuZzogbW9yZSByZXZp ZXdzIG9uIGFkZHJlc3MgcmVnaXN0cmF0aW9uIGRyYWZ0IHdvdWxkIGJlIGhlbHBmdWwuIEF1dGhv cnMgc29sdmVkIGFsbCBjb21tZW50cyByZWNlaXZlZC4gV0cgc2hvdWxkIGdvIHNlY29uZCBXR0xD IGxhdGVyLg0KDQpCZXJuaWU6IFdHIGlzIGdvaW5nIHRocm91Z2ggYSBtaW5vciByZWNoYXJ0ZXIN Cg0KSWFuOiBpbnRyb2R1Y2UgWWFuZyBNb2RlbCBmb3IgREhDUHY2IGNsaWVudA0KDQoqKioqKioq UHJlc2VudGF0aW9ucyBTcGxpdCBMaW5lKioqKioqKg0KVG9tZWs6IHJlcG9ydCBvbiAzMzE1Ymlz IHdvcmsNCg0KVGVkOiBzaG91bGQgYWRvcHQgZmlyc3QsIGFuZCB0aGVuIHJlcXVpcmUgY29uc2Vu c3VzIHByb2Nlc3Mgd29yaw0KDQpCZXJuaWU6IHRoZSBhdXRob3JzIHdvdWxkIGxpa2UgdG8gZ2V0 IGNvbnNlbnN1cyBpbnRlcm5hbGx5IGluIHRoZSBncm91cCBhbmQgYWRkcmVzcyBhbGwga25vd24g aXNzdWVzIGJlZm9yZSBhZG9wdCwgdGhlbiBwZW9wbGUgY2FuIHJldmlldyBhIGNvbXBsZXRlIHZl cnNpb24gZHVyaW5nIGFkb3B0aW9uIGNhbGwNCg0KVG9tZWsgdGFsa2luZyBhYm91dCB0aGUgc2Vy dmVyIG1heSBpZ25vcmUgdGhlIGhpbnQgZnJvbSBjbGllbnQNCg0KT2xlOiBwcmVmaXggbGVuZ3Ro IGFzIGEgaGludCBzaG91bGQgYWxzbyBiZSBhYmxlIHRvIGJlIGlnbm9yZWQNCg0KVG9tZWs6IGl0 IGlzIG5vdCBpbnRlbmRlZCB0aGF0IHNlcnZlciBtdXN0IGFjY2VwdCB3aGF0IHRoZSBjbGllbnQg cmVxdWVzdGVkLCBtaWdodCBuZWVkIHNvbWUgcmV3b3JkaW5nLg0KDQpUZWQ6IHNob3VsZCBzcGxp dCB0aGUgY2FzZXMNCg0KQmVybmllOiBjbGllbnQgc2hvdWxkIGJlIHN1cnZpdmUgaWYgaXQgZG9l cyBub3QgZ2V0IHdoYXQgdGhlIGhpbnQgcmVxdWlyZWQsIHdvdWxkIG1ha2UgdGhpcyBjbGVhciBp biB0aGUgZG9jdW1lbnQNCg0KU3VyZXNoOiBpdCBtYXkgYmUgb3V0IG9mIHNjb3BlLiBUaGUgY2xp ZW50IGltcGxlbWVudGF0aW9uIGNvdWxkIGJlOiBnaXZlIG1lIHdoYXQgSSB3YW50IG9yIG5vdGhp bmcuDQpCZXJuaWU6IGluIGdlbmVyYWwgY2xpZW50cyBzaG91bGQgYWNjb21tb2RhdGUgd2hhdCBh cmUgZm9ybSBvcGVyYXRvcnMNCg0KVGVkOiBwcm92aWRlIGFub3RoZXIgc2NlbmFyaW8gKG1heWJl IGEgc2VwYXJhdGVkIGRyYWZ0KQ0KDQpMb3JlbnpvOiBob3cgdGhpcyBoaW50IHJlbGV2YW50IHRv IFNMQUFDIHNob3VsZCBhbHNvIGJlIGNvbnNpZGVyZWQNCg0KTWljaGFlbCBBYnJhaGFtc3Nvbjog YSB1c2UgY2FzZSBmb3IgY2xpZW50LWluaXRpYXRlZCByZW51bWJlcmluZywgZS5nLiBjdXN0b21l cnMgZG9uJ3Qgd2FudCB0aGUgY3VycmVudCBhc3NpZ25lZCBwcmVmaXgsIGFuZCB0byBnZXQgYSBu ZXcgb25lIHRocm91Z2ggc29tZSBtZWNoYW5pc20NCg0KQmVybmllOiBpdCBpcyBub3QgY2xlYXIg aG93IHRoZSBoaW50IHNob3VsZCBiZSBoYW5kbGVkIGdlbmVyYWxseQ0KDQpPbGU6IGlzIGl0IG9r IHRvIGFzayBjb250YWluZXIgb3B0aW9uIHdpdGhvdXQgc3Vib3B0aW9ucz8NCg0KVG9tZWs6IHll cw0KDQpUb21layB0YWxraW5nIGFib3V0IHRoZSBDbGllbnQgUmF0ZSBMaW1pdGluZyBpc3N1ZQ0K DQpTaGVuZzogc2VydmVyIHNob3VsZCBhbHNvIGJlIGFibGUgdG8gbGltaXQgdGhlIHJlcXVlc3Qg cmF0ZSBmcm9tIHRoZSBzYW1lIGNsaWVudA0KDQpUb21layB0YWxraW5nIGFib3V0IGZpbGxpbmcg bGluay1hZGRyZXNzDQoNClRlZDogbW9yZSBkZXRhaWwgc2hvdWxkIGJlIGdpdmVuIHdoeSBhbmQg aG93IHRvIGRvIGl0LCBtYXkgYmUgYSBzZXBhcmF0ZWQgZG9jdW1lbnQNCg0KQmVybmllOiBqdXN0 IGEgcmVjb21tZW5kYXRpb24gdGhhdCBiYXNpY2FsbHkgeW91IHNob3VsZCB1c2UgYSBHbG9iYWwg b3IgVW5pcXVlIExvY2FsIGFkZHJlc3MgZm9yIHJlbGF5DQoNCkZyZWQ6IGdpdmUgYW4gZXhhbXBs ZQ0KDQpUb21layB0YWxraW5nIGFib3V0ICJjb25maXJtIG5vIGxvbmdlciBtYW5kYXRvcnkiDQoN CkJlcm5pZSwgVGVkOiBpdCBzaG91bGQgYmUgYSAiU0hPVUxEIg0KDQoqKioqKioqUHJlc2VudGF0 aW9ucyBTcGxpdCBMaW5lKioqKioqKg0KQmVybmllIHRhbGtpbmcgYWJvdXQgc3RhdGVmdWwgaXNz dWVzDQoNClNoZW5nOiB1cGRhdGUgdG8gMzMxNSBhbmQgMzM2MyBzaG91bGQgYWxzbyBiZSBpbiAz MzE1YmlzDQoNCkJlcm5pZTogaGFzIG5vdCBiZWVuIGluY2x1ZGVkIGluIDMzMTViaXMsIHVudGls IFdHTEMNCg0KVGltIFdpbnRlcnM6IHRoZXJlIGFyZSBjbGllbnRzIHRoYXQgYWN0dWFsbHkgZG9l c24ndCBhY2NlcHQgdG9wLWxldmVsIHN0YXR1cywgYnV0IHRoZXkgZG8gaGFuZGxlIHN0YXR1cyBp biBJQV9OQXMuDQoNClJldmlld2VycyBGcmVkIFRlbXBsaW4sIExlYWYgWWVoLCBGcmFuY2lzIER1 cG9udCwgSmFzb24gV2VpbCwgSWFuIEZhcnJlciwgQW5kcmV3IFlvdXJ0Y2hlbmtvLCBRaSBTdW4s IENvbmcgTGl1DQoNCioqKioqKipQcmVzZW50YXRpb25zIFNwbGl0IExpbmUqKioqKioqDQpEYWNo ZW5nIHRhbGtpbmcgYWJvdXQgU2VjdXJlIERIQ1B2NiB3aXRoIHB1YmxpYyBrZXkNCg0KRGFuaWVs OiBhZGQgdHJ1c3QgYW5jaG9yIGlzIG5vdCB0aGF0IGRpZmZpY3VsdCwgbGVhcCBvZiBGYWl0aCBp cyBlbm91Z2ggdG8gbWFrZSBzdXJlIGNsaWVudCBjb25uZWN0IHRvIHRoZSBzYW1lIHNlcnZlcg0K DQpMb3JlbnpvOiBub3Qgc3VyZSB3aGF0IHRoZSB0aHJlYXQgbW9kZWwgaXMsIGlmIHRoZXJlIGlz IHN0cm9uZyBMMiBzZWN1cml0eSwgbWlnaHQgbm90IG5lZWQgdGhpcw0KDQpNYXJhdXM6IHByZWZl ciBvcHRpb24gNCAoZHJvcCBjZXJ0aWZpY2F0ZSBmcm9tIHRoaXMgZHJhZnQgdG90YWxseSkNCg0K RGFuaWVsOiBpdCBpcyB1c2VmdWwgZm9yIGNsaWVudCB0byBhdXRob3JpemUgc2VydmVyDQoNClRl ZDogc2VydmVyIGF1dGhvcml6ZSBjbGllbnQgaXMgYWxzbyB1c2VmdWwsIHRob3VnaCBub3QgdmVy eSBjbGVhcg0KDQpMb3JlbnpvOiBsMiBzZWN1cml0eSBtYXkgYmUgZW5vdWdoIGFuZCBiZXR0ZXIN Cg0KVGVkOiBjbGllbnQgYXV0aG9yaXplIHNlcnZlciBpcyBtb3JlIHVzZWZ1bC4gU2VjdXJlIERI Q1B2NiByZWdhcmRsZXNzIHNlcnZlciBvciBjbGllbnQgaXMgZ29vZC4NCg0KRnJhbmNpczogVVJM IGZvciBjZXJ0aWZpY2F0ZSBtYXkgYmUgaGVscA0KDQpMb3JlbnpvOiBzaG91bGQgZ2V0IGRhdGEg dG8gY29udGludWUgdGhpcyB3b3JrDQoNCkJlcm5pZTogYXQgbGVhc3Qgb25lIHVzZSBjYXNlIHRo YXQgdGhlIGNsaWVudCBhdXRoZW50aWNhdGVzIHRoZSBzZXJ2ZXINCg0KU3VyZXNoOiBob3cgdG8g cHJvdmUgYSBESENQIHNlcnZlciBvdXQgb2YgbGVhcCBvZiBmYWl0aA0KDQpUZWQ6IHRoZSBwb2lu dCBpcyB0byB0YWxrIHRvIHRoZSBzYW1lIHNlcnZlciB0aGF0IHRoZSBjbGllbnQgaGFzIHRhbGtl ZCBiZWZvcmUNCg0KTWFyYXVzOiBzdXBwb3J0DQoNClN1cmVzaDogTGVhcCBvZiBmYWl0aCBtYWtl IHNlbnNlLCBvdGhlcnMgZG9uJ3QNCg0KQmVybmllOiB0aGUgYXV0aG9ycyBjb3VsZCBzdW1tYXJp emUgdGhlIGRpc2N1c3Npb24gYW5kIGNvbWUgYmFjayB0byBtYWlsIGxpc3QgZm9yIFdHIGNvbnNl bnN1cw0KDQoqKioqKioqUHJlc2VudGF0aW9ucyBTcGxpdCBMaW5lKioqKioqKg0KVG9tZWsgcHJl c2VudGluZyBDdXN0b21pemluZyBESENQIENvbmZpZ3VyYXRpb24gT24gdGhlIGJhc2lzIG9mIE5l dHdvcmsgVG9wb2xvZ3kNCg0KU3VyZXNoOiBhc2sgYSBxdWVzdGlvbiByZWdhcmRpbmcgdG8gbm9y bWF0aXZlIHJlZmVyZW5jZSwgREhDUCBiYXNlIHJlZmVyZW5jZSB3YXMgbW92ZWQgdG8gaW5mb3Jt YXRpdmUsIGl0IHNob3VsZCByZW1haW4gbm9ybWF0aXZlDQoNClRoZSBmZWVsaW5nIGluIHRoZSBy b29tIGlzIHRoYXQgdGhlIGRyYWZ0IGlzIHJlYWR5IGZvciBXR0xDDQoNCioqKioqKipQcmVzZW50 YXRpb25zIFNwbGl0IExpbmUqKioqKioqDQpRaSBTdW4gdGFsa2luZyBhYm91dCBEeW5hbWljIEFs bG9jYXRpb24gb2YgU2hhcmVkIElQdjQgQWRkcmVzc2VzDQoNClRlZDogaXMgdGhpcyByZXF1aXJl ZCBmb3IgbGlnaHR3ZWlnaHQgNG92ZXI2Pw0KUWk6IG5vDQoNClRlZDogdGhpcyBzZWVtcyBzb2Z0 d2lyZSBXRyByZXF1aXJlbWVudA0KDQpTdXJlc2g6IGFzIHNvZnR3aXJlIGNoYWlyLCByZWFkIHRo aXMgZHJhZnQsIGJ1dCBub3QgaGF2ZSBtYWRlIHVwIG1pbmQgeWV0Lg0KDQpJYW46IGV4cGxhaW4g dGhlIGhpc3Rvcnkgb2YgdGhlIGRvY3VtZW50DQoNCkJlcm5pZTogd2lsbCBkbyBXR0xDIG9uIG1h aWwgbGlzdA0KDQoqKioqKioqUHJlc2VudGF0aW9ucyBTcGxpdCBMaW5lKioqKioqKg0KS2ltIHRh bGtpbmcgYWJvdXQgREhDUHY2IGZhaWxvdmVyIHVwZGF0ZQ0KDQpObyBjb21tZW50cw0KDQoqKioq KioqUHJlc2VudGF0aW9ucyBTcGxpdCBMaW5lKioqKioqKg0KVG9tZWsgdGFsa2luZyBhYm91dCBE SENQIHByaXZhY3kgY29uc2lkZXJhdGlvbnMNCg0KVG9tZWs6IGlzIHRoZSBXRyBpbnRlcmVzdGVk IGluIHdvcmtpbmcgb24gdGhpcz8NCg0KQmVybmllOiBmaXJzdCBzdGVwIGlzIHRvIHdyaXRlIGEg ZG9jdW1lbnQNCg0KVGVkOiB1c2VmdWwgd29yaw0KDQpEYW5pZWw6IGhhcHB5IHRvIGhlbHAgZnJv bSBvdXRzaWRlIG9mIERIQyBXRw0KDQpMb3JlbnpvOiB0aGUgd29yayBpcyB0b28gZGlmZmljdWx0 OyByZWNvbW1lbmQgbm90IHdvcmtpbmcgb24gdGhpcw0KDQpEYW5pZWw6IGlmIHNvLCB3ZSBzaG91 bGQgZG9jdW1lbnQgdGhlIGRpZmZpY3VsdA0KDQpGcmFuY2lzOiBhbmFseXNpcyBmaXJzdCwgZG9u J3QganVtcCB0byBhbnkgc29sdXRpb24geWV0DQoNClN1cmVzaDogdGhlcmUgYXJlIHNwYWNlcyB3 aXRoaW4gREhDUCB0byBpbXByb3ZlIChUaGUgZG9jdW1lbnQgRGFuaWVsIG1lbnRpb25lZCBpcyBS RkMgNjk3MyAtIFByaXZhY3kgQ29uc2lkZXJhdGlvbnMgZm9yIEludGVybmV0IFByb3RvY29scykN Cg0KVGVkOiBJRVNHIGlzIGludGVyZXN0ZWQgaW4gcHJpdmFjeSwgZXZlbiBnaXZlIHNvbWUgaGlu dCB3aGV0aGVyIHVzaW5nIERIQ1Agb3Igbm90DQoNCkxvcmVuem86IHN1cHBvcnQgYW5hbHlzaXMg d29yayBmaXJzdCwgZGlzYWdyZWUgYW5hbHlzaXMgYW5kIHNvbHV0aW9ucyBkb2luZyBhdCB0aGUg c2FtZSB0aW1lDQoNCk1pa2VhbCBBYnJhbWhhbXNzb246IFNFTkQgaXMgaGFyZGx5IGV2ZXIgYWxp dmUgaW4gcHJhY3RpY2UsIHNvIHBsZWFzZSBkZXZlbG9wIHNvbWV0aGluZyBkZXBsb3lhYmxlDQoN ClRvbWVrOiB3aG8gaXMgaW50ZXJlc3RlZCB0byB3b3JrIG9uIGl0Pw0KDQpTdXJlc2gsIFNoZW5n LCBUb21laywgRnJhbmNpcywgQW5kcmV3IHJhaXNlIGhhbmRzDQoNCioqKioqKipQcmVzZW50YXRp b25zIFNwbGl0IExpbmUqKioqKioqDQpMaSBYdWUgdGFsa2luZyBhYm91dCBESENQIGZvciBkeW5h bWljIEdSRSB0dW5uZWwNCg0KQmVybmllOiBxdWVzdGlvbiBmb3IgQUQsIGlzIERIQyBXRyByaWdo dCBwbGFjZSBmb3IgdGhpcyB3b3JrPw0KDQpUZWQ6IHdoZXJlIHRoZSByZXF1aXJlbWVudHMgY29t ZSBmcm9tPw0KDQpMaSBYdWU6IE9QUyBvcGVuIFdHDQoNClRlZDogbmVlZCBPUFMgQUQgdG8gcmVx dWVzdCB0aGlzDQoNCklhbjogMS4gbWFueSB0ZXJtcyBpbiB0aGUgZHJhZnQgbWFrZXMgdGhlIGRy YWZ0IGhhcmQgdG8gdW5kZXJzdGFuZC4yLiBUaGVyZSBpcyBubyBzdGFuZGFyZCB0cmFjayBmb3Ig R1JFIG92ZXIgSVB2Ni4NCg0KQW5kcmV3OiBDQVBXQVAgbWF5IGJlIGJldHRlciBvcHRpb24NCg0K KioqKioqKlByZXNlbnRhdGlvbnMgU3BsaXQgTGluZSoqKioqKioNClN1cmVzaCB0YWxraW5nIGFi b3V0IHN1cHBvcnQgZm9yIG11bHRpcGxlIHByb3Zpc2lvbmluZyBkb21haW5zIGluIERIQ1B2Ng0K DQpTdXJlc2g6IGl0IGlzIGFuIG9uZ29pbmcgd29yayBpbiBNSUYgV0cNCg0KSWFuOiBESENQdjYg cmVsYXkgYWdlbnQgc3VwcG9ydGluZyBPUFRJT05fUFZEX0lEIHdvdWxkIGJlIHVzZWZ1bA0KDQoN Cg0K From nobody Fri Aug 15 08:57:46 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6BB1A06DD for ; Fri, 15 Aug 2014 08:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham 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 FJ-U6AD5KRlt for ; Fri, 15 Aug 2014 08:57:40 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6B401A6F06 for ; Fri, 15 Aug 2014 08:57:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s7FFvWN5025846; Fri, 15 Aug 2014 10:57:32 -0500 Received: from XCH-BLV-507.nw.nos.boeing.com (xch-blv-507.nw.nos.boeing.com [130.247.25.197]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s7FFvSGT025815 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Fri, 15 Aug 2014 10:57:29 -0500 Received: from XCH-BLV-104.nw.nos.boeing.com (2002:82f7:1978::82f7:1978) by XCH-BLV-507.nw.nos.boeing.com (2002:82f7:19c5::82f7:19c5) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 15 Aug 2014 08:57:27 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.6]) by XCH-BLV-104.nw.nos.boeing.com ([169.254.4.223]) with mapi id 14.03.0181.006; Fri, 15 Aug 2014 08:57:28 -0700 From: "Templin, Fred L" To: "dhcwg@ietf.org" Thread-Topic: DHCPv6 server scaling Thread-Index: Ac+2upuh7YoQHY4/QqaL4wm+EJ+sGQB5dsCw Date: Fri, 15 Aug 2014 15:57:27 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CF1FB5@XCH-BLV-504.nw.nos.boeing.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AF09B40@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AF09B40@nkgeml512-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/QfsTyUDefQRpVIkhZfiiFOn8fM0 Subject: [dhcwg] DHCPv6 server scaling X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 15:57:44 -0000 Hi, does anyone have a rough order-of-magnitude idea of how many clients a single DHCPv6 server can handle? Assume clients normally send Request once upon startup and send Renew/Rebind once in a while according to timers and network conditions. They also send Release only when they shut down, which could be one or a few times per day. In such a system, how many clients can a server handle? O(10^3)? O(10^4)? O(10^5)? More? Any other tips on how to size a system like this? Thanks - Fred fred.l.templin@boeing.com From nobody Fri Aug 15 09:17:24 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 994C01A6F0E for ; Fri, 15 Aug 2014 09:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham 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 lT-IC6dT4lLa for ; Fri, 15 Aug 2014 09:17:19 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [IPv6:2001:470:1f09:baa::21]) by ietfa.amsl.com (Postfix) with ESMTP id A840F1A8A90 for ; Fri, 15 Aug 2014 09:17:16 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [192.168.1.22] (lan.furness.net [77.233.151.255]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 939891BC3E for ; Fri, 15 Aug 2014 16:17:11 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Simon Hobson In-Reply-To: <2134F8430051B64F815C691A62D9831832CF1FB5@XCH-BLV-504.nw.nos.boeing.com> Date: Fri, 15 Aug 2014 17:17:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5D36713D8A4E7348A7E10DF7437A4B923AF09B40@nkgeml512-mbx.china.huawei.com> <2134F8430051B64F815C691A62D9831832CF1FB5@XCH-BLV-504.nw.nos.boeing.com> To: "dhcwg@ietf.org" X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/BxJ3cQVbpc4Ynoa2PiUej3tRTQw Subject: Re: [dhcwg] DHCPv6 server scaling X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 16:17:22 -0000 "Templin, Fred L" wrote: > Hi, does anyone have a rough order-of-magnitude idea of how many = clients > a single DHCPv6 server can handle? Assume clients normally send = Request > once upon startup and send Renew/Rebind once in a while according to > timers and network conditions. They also send Release only when they > shut down, which could be one or a few times per day. >=20 > In such a system, how many clients can a server handle? O(10^3)? > O(10^4)? O(10^5)? More? How long is a piece of string ? Which server package you use will probably make a big difference. After = that, hardware performance (particularly disk I/O) and system config = rule. It's come up over on the ISC DHCP users list a few times in relation to = serving IPv4 addresses, but it shouldn't be much different for IPv6. = Speaking only for the ISC server, there are reports of people running = several hundred k of users off a server (or server pair). For that, I = assume they will have chosen "beefy" hardware. A key bottleneck for an RFC compliant server is disk I/O as leases must = be synced to persistent storage before offer to the client - not all = servers do this, gain a big performance advantage, but aren't RFC = compliant and will lose lease information in an "uncontrolled shutdown" = event. That means a very large number of small disk writes. Second to = that comes logging - the ISC server defaults to logging every activity, = and some setups default to synchronous logging. That can mean 6 disk = writes for a single Discover-Offer-Request-Ack cycle (again speaking = IPv4 terminology as I've not got into IPv6 DHCP yet) - 2 lease file = writes, 4 log file writes. Setting logging (syslog config on unix-like = systems) to asynchronous removes 4 of these writes from the equation. So for high transaction rates, you need adequate processing power, = ideally plenty of memory so all the tables can stay in RAM, and a disk = I/O system that supports a high rate of small write transactions. AFAIK there is no magic formula for sizing a DHCP server. From nobody Fri Aug 15 09:25:51 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2E491A000E for ; Fri, 15 Aug 2014 09:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham 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 AFcPD6cdlKyb for ; Fri, 15 Aug 2014 09:25:49 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31B091A0009 for ; Fri, 15 Aug 2014 09:25:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s7FGPm9W009979; Fri, 15 Aug 2014 11:25:48 -0500 Received: from XCH-BLV-501.nw.nos.boeing.com (xch-blv-501.nw.nos.boeing.com [130.247.25.190]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s7FGP5K0008493 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 15 Aug 2014 11:25:46 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.6]) by XCH-BLV-501.nw.nos.boeing.com ([169.254.1.169]) with mapi id 14.03.0181.006; Fri, 15 Aug 2014 09:25:16 -0700 From: "Templin, Fred L" To: Simon Hobson , "dhcwg@ietf.org" Thread-Topic: [dhcwg] DHCPv6 server scaling Thread-Index: Ac+2upuh7YoQHY4/QqaL4wm+EJ+sGQB5dsCwAA+k0AAADoqwEA== Date: Fri, 15 Aug 2014 16:25:15 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CF2066@XCH-BLV-504.nw.nos.boeing.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AF09B40@nkgeml512-mbx.china.huawei.com> <2134F8430051B64F815C691A62D9831832CF1FB5@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/Im9SmfZ8E_A81LodPR0GsNwsJ0w Subject: Re: [dhcwg] DHCPv6 server scaling X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 16:25:50 -0000 Hi Simon, Thanks for the great information - this is exactly the kind of stuff I was hoping to learn more about. So, servers as a performance bottleneck and single point of failure is probably something I'll want to account for in my design. Any other ideas are also welcome. Regards - Fred fred.l.templin@boeing.com > -----Original Message----- > From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Simon Hobson > Sent: Friday, August 15, 2014 9:17 AM > To: dhcwg@ietf.org > Subject: Re: [dhcwg] DHCPv6 server scaling >=20 > "Templin, Fred L" wrote: >=20 > > Hi, does anyone have a rough order-of-magnitude idea of how many client= s > > a single DHCPv6 server can handle? Assume clients normally send Request > > once upon startup and send Renew/Rebind once in a while according to > > timers and network conditions. They also send Release only when they > > shut down, which could be one or a few times per day. > > > > In such a system, how many clients can a server handle? O(10^3)? > > O(10^4)? O(10^5)? More? >=20 > How long is a piece of string ? > Which server package you use will probably make a big difference. After t= hat, hardware performance > (particularly disk I/O) and system config rule. >=20 > It's come up over on the ISC DHCP users list a few times in relation to s= erving IPv4 addresses, but it > shouldn't be much different for IPv6. Speaking only for the ISC server, t= here are reports of people > running several hundred k of users off a server (or server pair). For tha= t, I assume they will have > chosen "beefy" hardware. > A key bottleneck for an RFC compliant server is disk I/O as leases must b= e synced to persistent > storage before offer to the client - not all servers do this, gain a big = performance advantage, but > aren't RFC compliant and will lose lease information in an "uncontrolled = shutdown" event. That means a > very large number of small disk writes. Second to that comes logging - th= e ISC server defaults to > logging every activity, and some setups default to synchronous logging. T= hat can mean 6 disk writes > for a single Discover-Offer-Request-Ack cycle (again speaking IPv4 termin= ology as I've not got into > IPv6 DHCP yet) - 2 lease file writes, 4 log file writes. Setting logging = (syslog config on unix-like > systems) to asynchronous removes 4 of these writes from the equation. >=20 > So for high transaction rates, you need adequate processing power, ideall= y plenty of memory so all the > tables can stay in RAM, and a disk I/O system that supports a high rate o= f small write transactions. >=20 > AFAIK there is no magic formula for sizing a DHCP server. >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From nobody Fri Aug 15 09:33:18 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAA391A0021 for ; Fri, 15 Aug 2014 09:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 JUovPWMEE63L for ; Fri, 15 Aug 2014 09:33:15 -0700 (PDT) Received: from na3sys010aog107.obsmtp.com (na3sys010aog107.obsmtp.com [74.125.245.82]) by ietfa.amsl.com (Postfix) with SMTP id AB7B81A001E for ; Fri, 15 Aug 2014 09:33:15 -0700 (PDT) Received: from mail-vc0-f172.google.com ([209.85.220.172]) (using TLSv1) by na3sys010aob107.postini.com ([74.125.244.12]) with SMTP ID DSNKU+42SyzmZwI1OWUYD3PNYSA8SU22AwOQ@postini.com; Fri, 15 Aug 2014 09:33:15 PDT Received: by mail-vc0-f172.google.com with SMTP id im17so3184270vcb.31 for ; Fri, 15 Aug 2014 09:33:14 -0700 (PDT) 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:content-type; bh=2dRXR64p36YpyDPqNBRl8nSlq+KXtU/Iyzp0Jh0ZkLs=; b=W3zkfmXnXt+jSNoJpN1mW91lsnvtnUhlJgnERjKBAeqnYotlzqUcl9UsUOmsjMHVmH txaRnQBC7YhmYU1fmmctVFa9kgvrOCNPo9jwSDNkxABQXuPD6l51BcxXSCTKCeOsvOYO m2RBFc6zaJKiDRwADFZdDuiIJ4dqJUhq6Opt6SPxbOdzq6jgOuCRlCnSN2HRlSbd1/Wd bgpIinTL1PmHFcRBGMuJ8aDTI0nsdDdRCkyy8B8utZNK74aTIClOO6vee16WhBKBSPhy SLgfHR6M6VG4OJG68zmIA7TeNi4n0yV9C67ADGOBvhJXAJPzTGshPgH0awEV9uUySKO1 WHIQ== X-Gm-Message-State: ALoCoQlU1NmdZcTwHn8gkFv6XofkdCKUYyuRSH12bfnBaq0K/mJhuH0aYaCtejb4nG/cuVHbgXGOeI5DQBrvqOEmWOKIBl9/QYpsfsBCmSgN/Ujsnjyfd5e/0lvXvtsOkaxGnYuaQzoK X-Received: by 10.220.163.69 with SMTP id z5mr11088062vcx.10.1408120394766; Fri, 15 Aug 2014 09:33:14 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.220.163.69 with SMTP id z5mr11088051vcx.10.1408120394659; Fri, 15 Aug 2014 09:33:14 -0700 (PDT) Received: by 10.220.187.8 with HTTP; Fri, 15 Aug 2014 09:33:14 -0700 (PDT) In-Reply-To: <2134F8430051B64F815C691A62D9831832CF1FB5@XCH-BLV-504.nw.nos.boeing.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AF09B40@nkgeml512-mbx.china.huawei.com> <2134F8430051B64F815C691A62D9831832CF1FB5@XCH-BLV-504.nw.nos.boeing.com> Date: Fri, 15 Aug 2014 09:33:14 -0700 Message-ID: From: Andre Kostur To: "Templin, Fred L" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/Lr0ZNMGy0Ac1M8M7r3FPzOZg8zw Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] DHCPv6 server scaling X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 16:33:17 -0000 That would be a discussion for the various DHCPv6 vendors. That would depends on way too many factors beyond the scope of the standards committee. What would affect Incognito's performance may be different from Cisco, and ISC, and Nominum, and... etc. On Fri, Aug 15, 2014 at 8:57 AM, Templin, Fred L wrote: > Hi, does anyone have a rough order-of-magnitude idea of how many clients > a single DHCPv6 server can handle? Assume clients normally send Request > once upon startup and send Renew/Rebind once in a while according to > timers and network conditions. They also send Release only when they > shut down, which could be one or a few times per day. > > In such a system, how many clients can a server handle? O(10^3)? > O(10^4)? O(10^5)? More? > > Any other tips on how to size a system like this? > > Thanks - Fred > fred.l.templin@boeing.com -- Andre Kostur From nobody Fri Aug 15 10:13:04 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4437E1A00D2 for ; Fri, 15 Aug 2014 10:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham 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 CEjCXotvDqFe for ; Fri, 15 Aug 2014 10:13:02 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B2D21A00EA for ; Fri, 15 Aug 2014 10:12:54 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 37B091B861A for ; Fri, 15 Aug 2014 10:12:54 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 253BF53E070; Fri, 15 Aug 2014 10:12:54 -0700 (PDT) Received: from [10.0.10.40] (71.233.43.215) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 15 Aug 2014 10:12:47 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <2134F8430051B64F815C691A62D9831832CF1FB5@XCH-BLV-504.nw.nos.boeing.com> Date: Fri, 15 Aug 2014 13:12:22 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <71BA05D0-43C2-4103-9DF7-6718971D0DF9@nominum.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AF09B40@nkgeml512-mbx.china.huawei.com> <2134F8430051B64F815C691A62D9831832CF1FB5@XCH-BLV-504.nw.nos.boeing.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/We6juPiTgkICWq5wQ0SJhuYtl9Q Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] DHCPv6 server scaling X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 17:13:03 -0000 On Aug 15, 2014, at 11:57 AM, Templin, Fred L = wrote: > In such a system, how many clients can a server handle? O(10^3)? > O(10^4)? O(10^5)? More? A good commercial server ought to be able to handle millions of clients = at practical lease durations. The ones I am familiar with do. From nobody Fri Aug 15 11:23:19 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 482731A01FF for ; Fri, 15 Aug 2014 11:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham 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 Ojofk2HggYmv for ; Fri, 15 Aug 2014 11:23:15 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [IPv6:2001:470:1f09:baa::21]) by ietfa.amsl.com (Postfix) with ESMTP id 487711A01F2 for ; Fri, 15 Aug 2014 11:23:15 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [192.168.1.4] (88-111-161-27.dynamic.dsl.as9105.com [88.111.161.27]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 702001BC3E for ; Fri, 15 Aug 2014 18:23:10 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Simon Hobson In-Reply-To: <2134F8430051B64F815C691A62D9831832CF2066@XCH-BLV-504.nw.nos.boeing.com> Date: Fri, 15 Aug 2014 19:23:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5D36713D8A4E7348A7E10DF7437A4B923AF09B40@nkgeml512-mbx.china.huawei.com> <2134F8430051B64F815C691A62D9831832CF1FB5@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CF2066@XCH-BLV-504.nw.nos.boeing.com> To: "dhcwg@ietf.org" X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/Pkja64eXWMUMLQK95CtJ5wu9l7g Subject: Re: [dhcwg] DHCPv6 server scaling X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 18:23:16 -0000 Another factor I forgot is your lease time - the longer the lease time, = the less frequently each client needs to renew. But, that's not the whole story. In a business environment, you may find that a large proportion of your = devices get switched on during a fairly small time window every morning. = Thus while the average renew rate may be low - the peak rate may be = high. Similarly, you also need to consider abnormal events - such as a = power outage over a large part of your estate. When the power comes back = on, a large number of clients renew at once - especially if it's "always = on" kit like consumer routers. So again, it's not straightforward to work out what peak request rate = you need to support ! From nobody Fri Aug 15 11:33:53 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC171A0103 for ; Fri, 15 Aug 2014 11:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham 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 rP-5xrDGhcvs for ; Fri, 15 Aug 2014 11:33:49 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8556E1A00CD for ; Fri, 15 Aug 2014 11:33:49 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 1BDFE1B85F1 for ; Fri, 15 Aug 2014 11:33:49 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id EF90B53E070; Fri, 15 Aug 2014 11:33:48 -0700 (PDT) Received: from [10.0.10.40] (71.233.43.215) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 15 Aug 2014 11:33:43 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Fri, 15 Aug 2014 14:33:17 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <2288B59A-FC7E-44DC-8E1F-663BF243A8B4@nominum.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AF09B40@nkgeml512-mbx.china.huawei.com> <2134F8430051B64F815C691A62D9831832CF1FB5@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CF2066@XCH-BLV-504.nw.nos.boeing.com> To: Simon Hobson X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/fAVakwvBGkRlbHDe0ZzEVyGL8Bk Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] DHCPv6 server scaling X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 18:33:50 -0000 On Aug 15, 2014, at 2:23 PM, Simon Hobson = wrote: > Another factor I forgot is your lease time - the longer the lease = time, the less frequently each client needs to renew. > But, that's not the whole story. Has anybody written up an informational document that talks about these = issues? I confess I am not aware of one. From nobody Fri Aug 15 11:40:55 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B311A00FE for ; Fri, 15 Aug 2014 11:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham 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 z7UfIR9u5f8X for ; Fri, 15 Aug 2014 11:40:51 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ECE01A0130 for ; Fri, 15 Aug 2014 11:40:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s7FIeopY004252; Fri, 15 Aug 2014 11:40:50 -0700 Received: from XCH-PHX-509.sw.nos.boeing.com (xch-phx-509.sw.nos.boeing.com [10.57.37.31]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s7FIelbu004081 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 15 Aug 2014 11:40:48 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.6]) by XCH-PHX-509.sw.nos.boeing.com ([169.254.9.33]) with mapi id 14.03.0181.006; Fri, 15 Aug 2014 11:40:46 -0700 From: "Templin, Fred L" To: Simon Hobson , Ted Lemon , "dhcwg@ietf.org" Thread-Topic: [dhcwg] DHCPv6 server scaling Thread-Index: Ac+2upuh7YoQHY4/QqaL4wm+EJ+sGQB5dsCwAA+k0AAADoqwEP//rt2AgAB0hHA= Date: Fri, 15 Aug 2014 18:40:46 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CF23B1@XCH-BLV-504.nw.nos.boeing.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AF09B40@nkgeml512-mbx.china.huawei.com> <2134F8430051B64F815C691A62D9831832CF1FB5@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CF2066@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/FXHyqLE4i2bF2Npi0T6En3OQWy4 Subject: Re: [dhcwg] DHCPv6 server scaling X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 18:40:53 -0000 Hi Simon and Ted, Per your observations, scaling properties sound very reasonable modulo power outages and the like. So, I was thinking it might be best to have redundantly replicated servers. Each one could handle multitudes of clients if necessary, but we would expect the client load to be fairly evenly distributed among servers in the average case. That way, even during synchronized start-ups like after a power failure client requests should still be satisfied within a reasonable timescale. I expect to have more to say about this soon. Thanks - Fred fred.l.templin@boeing.com From nobody Fri Aug 15 12:54:18 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C46961A038A for ; Fri, 15 Aug 2014 12:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 J2BIxULo6VnE for ; Fri, 15 Aug 2014 12:54:15 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 385351A030E for ; Fri, 15 Aug 2014 12:54:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2563; q=dns/txt; s=iport; t=1408132456; x=1409342056; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7dwQaQl996H1BcLtVqN17rx5j2fvO5bj75aQJdGpeIg=; b=WQEoqf1a8VNvQoS79xIjCPIxm6+sv1i3/iCHF3XkIN0hGWFSF7V3KWy0 pwiJjgrbkvusOGS+xEH2NZMxkEIHIYTyQPiGRGXJBRYhISq5BG36r6zhL 4FYetEPUbwcQE87nx4GDxOiOkNHZ0efSaq2AIKLQqxS87re3aU9vhVXyW c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAMJk7lOtJA2N/2dsb2JhbABZgw1TW84DCodYAYETFneEAwEBAQQBAQE3NAsMBAIBCBEEAQEBChQJBycLFAkIAgQBDQUIiDoNw2ITBI5+HTEHBoMpgR0FkSCgG4NcbIFIgQcBAQE X-IronPort-AV: E=Sophos;i="5.01,872,1400025600"; d="scan'208";a="347854050" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-5.cisco.com with ESMTP; 15 Aug 2014 19:54:15 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s7FJsE5Q011147 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Aug 2014 19:54:14 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.173]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Fri, 15 Aug 2014 14:54:14 -0500 From: "Bernie Volz (volz)" To: Ted Lemon , Simon Hobson Thread-Topic: [dhcwg] DHCPv6 server scaling Thread-Index: AQHPuLd62IbTE/IKmkKXb0tCx0MiQpvSEEYA Date: Fri, 15 Aug 2014 19:54:13 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1B6567DC@xmb-rcd-x04.cisco.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AF09B40@nkgeml512-mbx.china.huawei.com> <2134F8430051B64F815C691A62D9831832CF1FB5@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CF2066@XCH-BLV-504.nw.nos.boeing.com> <2288B59A-FC7E-44DC-8E1F-663BF243A8B4@nominum.com> In-Reply-To: <2288B59A-FC7E-44DC-8E1F-663BF243A8B4@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.241.204] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/0YIrig21m2YPHh2izjFl6pwUCIw Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] DHCPv6 server scaling X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 19:54:17 -0000 This is a fairly complicated issue since servers also typically have a many= features and depending on which ones are enabled/in use, performance can v= ary considerably (consider logging, failover, DNS updates, Leasequery (sing= leton, bulk, active), lease history, ...). Even the configuration complexit= y can have a (hopefully small) impact. The Cisco Prime Network Registrar server can handle a lot of load, but as y= ou turn on various features the performance will be impacted (that various = of course by feature). I think all servers are MOST impacted by disk performance - how fast they c= an commit the lease information to disk since they must commit to disk befo= re responding to the client (although as Tomek recently pointed out to me, = RFC 2131 has such a requirement whereas RFC 3315 apparently does not state = this explicitly). On the flip side, rarely is CPU performance the limiting factor (especially= with any reasonable system today). DHCP (even DHCPv6 with longer addresses= ) is not CPU intensive. So when you are buying equipment, you should spend the money on a very high= performance disk I/O subsystem (high RPM disks or solid state). RAID or so= ftware volume shadowing should also be evaluated carefully since they typic= ally improve read performance, but significantly hurt write performance. Another consideration people often forget is steady state (i.e. when everyt= hing is running normal and renewals and new clients are being serviced) vs = avalanche situations (such as when a large number of clients are coming bac= k after a power failure or other outage). You never want to build your serv= ice so that it is near the edge in steady state since that means they'll be= severely overloaded when an avalanche situation occurs (perhaps even a sma= ll one). - Bernie -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ted Lemon Sent: Friday, August 15, 2014 2:33 PM To: Simon Hobson Cc: dhcwg@ietf.org Subject: Re: [dhcwg] DHCPv6 server scaling On Aug 15, 2014, at 2:23 PM, Simon Hobson wrote: > Another factor I forgot is your lease time - the longer the lease time, t= he less frequently each client needs to renew. > But, that's not the whole story. Has anybody written up an informational document that talks about these iss= ues? I confess I am not aware of one. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From nobody Fri Aug 15 13:13:52 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8CBE1A02F9 for ; Fri, 15 Aug 2014 13:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 jIC7naWgH-Tf for ; Fri, 15 Aug 2014 13:13:38 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 317741A03CA for ; Fri, 15 Aug 2014 13:13:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4266; q=dns/txt; s=iport; t=1408133609; x=1409343209; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=JXEPhGRbdvhvBZRou5g8YGxv/ES8B4HC+3XGdEnjhys=; b=DxQRswACs+GJzKqXqVwj1d1MgU7qvxP+Subx0u4HroYNGY1aSebjA3f9 XTxzcN+LF8Js0KsShGyAZWNoLr56Hypzo9cX8UsDVGy68Cl57P+eLnvyy UBywxPbYVLxUfV699K0L7+Md/pMjnd/g2HhkaRkGq0ONxNYMApkbr4+cH 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFACVp7lOtJV2T/2dsb2JhbABZgw1TW84ECodYAYETFneEAwEBAQQBAQE3NAsMBAIBCBEEAQEBCgsJCQcnCxQJCAIEAQ0FCBOIJw3DaReOfgUYBisHAgQEgyWBHQWBWI9IhCaITpMng1xsAYEGAR4GHIEHAQEB X-IronPort-AV: E=Sophos;i="5.01,873,1400025600"; d="scan'208";a="347939797" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-4.cisco.com with ESMTP; 15 Aug 2014 20:13:28 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s7FKDS5P001320 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Aug 2014 20:13:28 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.173]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Fri, 15 Aug 2014 15:13:28 -0500 From: "Bernie Volz (volz)" To: "Templin, Fred L" , Ted Lemon Thread-Topic: [dhcwg] DHCPv6 RAAN options Thread-Index: Ac+yf+stS7sJIaihTkKQdnTDfuT8QwALYBYAAACH5gAAAE+4gAAAlg4AAAApuQAAAESMAAAA0J4AAAEhrQAAISM8AAAAUOmAAAI4CYAAAFXUgAAAUwAAAABOYQAAAE3JAAAAgokAAVw1aYA= Date: Fri, 15 Aug 2014 20:13:27 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1B6568D8@xmb-rcd-x04.cisco.com> References: <2134F8430051B64F815C691A62D9831832CECA61@XCH-BLV-504.nw.nos.boeing.com> <83E91E35-3F30-4659-B4AE-58DD11E74DB6@nominum.com> <2134F8430051B64F815C691A62D9831832CECB68@XCH-BLV-504.nw.nos.boeing.com> <075FB3EE-EA09-4CBD-AFE9-CF14E77ED007@nominum.com> <2134F8430051B64F815C691A62D9831832CECBF5@XCH-BLV-504.nw.nos.boeing.com> <9C369D15-88ED-4E1E-8138-A538760C6FDE@nominum.com> <2134F8430051B64F815C691A62D9831832CECC7B@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CECD1A@XCH-BLV-504.nw.nos.boeing.com> <35F4F6CF-7CBC-4935-9E9F-2EC946D7EBB7@nominum.com> <2134F8430051B64F815C691A62D9831832CED2CD@XCH-BLV-504.nw.nos.boeing.com> <65C2A9BF-B153-4BD0-89EF-6D7D8FE459B3@nominum.com> <2134F8430051B64F815C691A62D9831832CED559@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CED5E7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CED674@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832CED674@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.241.204] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/5pLktk00Nix_yfyeny0o1gA-tmA Cc: "dhcwg@ietf.org" , Ralph Droms Subject: Re: [dhcwg] DHCPv6 RAAN options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 20:13:50 -0000 Fred: How about a 3rd option ... Perhaps you should look at the Active Leasequery work as that might be a be= tter option for the Relay tracking what the server has? See http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-active-leasequery. One issue for RAAN and even Relay gleaming the Reply is that the Reply mess= age might be lost and never get to the Relay. The client may not retry (or = all Releases suffer from this issue) - it is suggested that the client retr= y, not a requirement. Because Release messages may be lost, the client should retransmit the Release if no Reply is received. However, there are scenarios where the client may not wish to wait for the normal retransmission timeout before giving up (e.g., on power down). (I guess we could argue here that 3315 should say "Because Release or Reply= messages may be lost ...". Perhaps another 3315bis item if we haven't caug= ht this already? No, at least not as of the bis 02 document.) On the other hand, I'm also not sure how serious this issue is. The Relay i= s probably keeping some state about what addresses/prefixes are in use by w= hat clients. So, when a Release is received, it can at least validate that = the client has this lease and remove it. If a rouge client did the Release,= what happens? I guess that depends on what the Relay is doing with this in= formation. If the Relay is also acting as a router or network traffic cop, = such as in DOCSIS CMTS, when a unknown addresses is seen, the Relay does a = Leasequery to the server to ask it who is using this address. If it gets ba= ck information, it updates it state tables and all is well. (Note that PD l= eases can be recovered - as the Leasequery will return the PD lease contain= ing the address). The only bad thing when the Relay removes the lease early= is that if it was injecting the PD into the routing table, that would obvi= ously stop and potentially be a problem. Note that Bulk LQ might also be needed by the Relay to recover state if the= relay loses stable storage? Hence, using Active LQ may not be such a stret= ch to avoid these security holes. - Bernie -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Templin, Fred L Sent: Friday, August 08, 2014 12:48 PM To: Ted Lemon Cc: dhcwg@ietf.org; Ralph Droms Subject: Re: [dhcwg] DHCPv6 RAAN options Hi Ted, > -----Original Message----- > From: Ted Lemon [mailto:ted.lemon@nominum.com] > Sent: Friday, August 08, 2014 9:34 AM > To: Templin, Fred L > Cc: Ralph Droms; dhcwg@ietf.org > Subject: Re: [dhcwg] DHCPv6 RAAN options >=20 > On Aug 8, 2014, at 12:24 PM, Templin, Fred L = wrote: > > It is a link-layer consideration that occurs below the IPv6 layer. > > So, yes it is DHCPv6 over a specific link layer. >=20 > Right, I don't think this makes sense as an Internet standard unless=20 > there's some broad applicability, in which case that would have to be doc= umented as a DHCP extension first. >=20 > > If that is still troubling, then please also consider the case of a=20 > > link that is physically constrained to have only a single > > DHCPv6 relay. >=20 > A special extension to DHCP just to account for this use case seems like = the wrong approach when you > consider the general applicability of the DHCP protocol. ISTM that eith= er solution we've talked > about would work for you as a private hack, but the question is which=20 > one (if any) makes sense as a standard extension to DHCP. Just so we can be clear on the alternatives, the first one we talked about = was to ask the server to include in its Reply message any IAs that were rel= eased as a result of the client's Release message and with lifetimes set to= 0. The second alternative was to resurrect RAAN options somehow. If I am understanding this correctly, then the RAAN option provides a conve= nient way of relay agent gleaning. But, option 1 would still allow for a sl= ightly less convenient means for gleaning. Thanks - Fred fred.l.templin@boeing.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From nobody Fri Aug 15 13:46:03 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3359D1A0545 for ; Fri, 15 Aug 2014 13:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham 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 Ar0GMSI-7MUK for ; Fri, 15 Aug 2014 13:45:59 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 597D51A050E for ; Fri, 15 Aug 2014 13:45:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s7FKjx7Y027218; Fri, 15 Aug 2014 13:45:59 -0700 Received: from XCH-BLV-508.nw.nos.boeing.com (xch-blv-508.nw.nos.boeing.com [130.247.25.198]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s7FKjlHx026713 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 15 Aug 2014 13:45:48 -0700 Received: from XCH-BLV-407.nw.nos.boeing.com (2002:82f7:19a5::82f7:19a5) by XCH-BLV-508.nw.nos.boeing.com (2002:82f7:19c6::82f7:19c6) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 15 Aug 2014 13:45:47 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.6]) by XCH-BLV-407.nw.nos.boeing.com ([169.254.7.129]) with mapi id 14.03.0181.006; Fri, 15 Aug 2014 13:45:47 -0700 From: "Templin, Fred L" To: "Bernie Volz (volz)" , Ted Lemon Thread-Topic: [dhcwg] DHCPv6 RAAN options Thread-Index: Ac+yf+stS7sJIaihTkKQdnTDfuT8QwAPkPgAAA579MD//5LdgIAAdPIw//+RDACAAHTV8IAA4dxQ//67BgD//2x8wAAnctNw///+rmD//4QYAP//fRpg//6AaAD//XWcsP/vOK6A/97gIwA= Date: Fri, 15 Aug 2014 20:45:47 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CF25D2@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832CECA61@XCH-BLV-504.nw.nos.boeing.com> <83E91E35-3F30-4659-B4AE-58DD11E74DB6@nominum.com> <2134F8430051B64F815C691A62D9831832CECB68@XCH-BLV-504.nw.nos.boeing.com> <075FB3EE-EA09-4CBD-AFE9-CF14E77ED007@nominum.com> <2134F8430051B64F815C691A62D9831832CECBF5@XCH-BLV-504.nw.nos.boeing.com> <9C369D15-88ED-4E1E-8138-A538760C6FDE@nominum.com> <2134F8430051B64F815C691A62D9831832CECC7B@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CECD1A@XCH-BLV-504.nw.nos.boeing.com> <35F4F6CF-7CBC-4935-9E9F-2EC946D7EBB7@nominum.com> <2134F8430051B64F815C691A62D9831832CED2CD@XCH-BLV-504.nw.nos.boeing.com> <65C2A9BF-B153-4BD0-89EF-6D7D8FE459B3@nominum.com> <2134F8430051B64F815C691A62D9831832CED559@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CED5E7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CED674@XCH-BLV-504.nw.nos.boeing.com> <489D13FBFA9B3E41812EA89F188F018E1B6568D8@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1B6568D8@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/N4i5AvmIfhOaD1SmUy8jDi-Ebu4 Cc: "dhcwg@ietf.org" , Ralph Droms Subject: Re: [dhcwg] DHCPv6 RAAN options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 20:46:01 -0000 Hi Bernie, > -----Original Message----- > From: Bernie Volz (volz) [mailto:volz@cisco.com] > Sent: Friday, August 15, 2014 1:13 PM > To: Templin, Fred L; Ted Lemon > Cc: dhcwg@ietf.org; Ralph Droms > Subject: RE: [dhcwg] DHCPv6 RAAN options >=20 > Fred: >=20 > How about a 3rd option ... >=20 > Perhaps you should look at the Active Leasequery work as that might be a = better option for the Relay > tracking what the server has? >=20 > See http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-active-leasequery. Thanks - will have a look. > One issue for RAAN and even Relay gleaming the Reply is that the Reply me= ssage might be lost and never > get to the Relay. The client may not retry (or all Releases suffer from t= his issue) - it is suggested > that the client retry, not a requirement. >=20 > Because Release messages may be lost, the client should retransmit > the Release if no Reply is received. However, there are scenarios > where the client may not wish to wait for the normal retransmission > timeout before giving up (e.g., on power down). >=20 > (I guess we could argue here that 3315 should say "Because Release or Rep= ly messages may be lost ...". > Perhaps another 3315bis item if we haven't caught this already? No, at le= ast not as of the bis 02 > document.) I think the client not retrying the Release is probably something else to be concerned about, yes. > On the other hand, I'm also not sure how serious this issue is. The Relay= is probably keeping some > state about what addresses/prefixes are in use by what clients. So, when = a Release is received, it can > at least validate that the client has this lease and remove it. If a roug= e client did the Release, > what happens? A rogue client is exactly the case of concern. I have a link on which rogue nodes can easily masquerade and attempt to cancel the leases of legitimate clients. For that, I am depending on DHCP authentication. But, if the relay agent can't inspect IAs in the Reply coming back from the server it has no way of knowing *what* (if anything) has been released. > I guess that depends on what the Relay is doing with this information. If= the Relay is > also acting as a router or network traffic cop, such as in DOCSIS CMTS, w= hen a unknown addresses is > seen, the Relay does a Leasequery to the server to ask it who is using th= is address. If it gets back > information, it updates it state tables and all is well. (Note that PD le= ases can be recovered - as > the Leasequery will return the PD lease containing the address). The only= bad thing when the Relay > removes the lease early is that if it was injecting the PD into the routi= ng table, that would > obviously stop and potentially be a problem. Relay acting as a router, e.g., for PD is the case I am considering. =20 > Note that Bulk LQ might also be needed by the Relay to recover state if t= he relay loses stable > storage? Hence, using Active LQ may not be such a stretch to avoid these = security holes. I'll look at active LQ. Per my earlier messages today, however, I am also looking at ways I can get relay agents out of the picture and just have direct client<->server transactions so that we don't have to go through the gleaning headaches. I will post something on this soon. Thanks - Fred fred.l.templin@boeing.com=20 > - Bernie >=20 > -----Original Message----- > From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Templin, Fred L > Sent: Friday, August 08, 2014 12:48 PM > To: Ted Lemon > Cc: dhcwg@ietf.org; Ralph Droms > Subject: Re: [dhcwg] DHCPv6 RAAN options >=20 > Hi Ted, >=20 > > -----Original Message----- > > From: Ted Lemon [mailto:ted.lemon@nominum.com] > > Sent: Friday, August 08, 2014 9:34 AM > > To: Templin, Fred L > > Cc: Ralph Droms; dhcwg@ietf.org > > Subject: Re: [dhcwg] DHCPv6 RAAN options > > > > On Aug 8, 2014, at 12:24 PM, Templin, Fred L wrote: > > > It is a link-layer consideration that occurs below the IPv6 layer. > > > So, yes it is DHCPv6 over a specific link layer. > > > > Right, I don't think this makes sense as an Internet standard unless > > there's some broad applicability, in which case that would have to be d= ocumented as a DHCP extension > first. > > > > > If that is still troubling, then please also consider the case of a > > > link that is physically constrained to have only a single > > > DHCPv6 relay. > > > > A special extension to DHCP just to account for this use case seems lik= e the wrong approach when you > > consider the general applicability of the DHCP protocol. ISTM that ei= ther solution we've talked > > about would work for you as a private hack, but the question is which > > one (if any) makes sense as a standard extension to DHCP. >=20 > Just so we can be clear on the alternatives, the first one we talked abou= t was to ask the server to > include in its Reply message any IAs that were released as a result of th= e client's Release message > and with lifetimes set to 0. The second alternative was to resurrect RAAN= options somehow. >=20 > If I am understanding this correctly, then the RAAN option provides a con= venient way of relay agent > gleaning. But, option 1 would still allow for a slightly less convenient = means for gleaning. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From nobody Fri Aug 15 16:20:18 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0731D1A082D for ; Fri, 15 Aug 2014 16:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham 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 WqUohGcqzalb for ; Fri, 15 Aug 2014 16:19:59 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A40A81A0828 for ; Fri, 15 Aug 2014 16:19:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s7FNJuCV023434; Fri, 15 Aug 2014 16:19:56 -0700 Received: from XCH-PHX-511.sw.nos.boeing.com (xch-phx-511.sw.nos.boeing.com [10.57.37.28]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s7FNJmUG023429 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Fri, 15 Aug 2014 16:19:49 -0700 Received: from XCH-BLV-205.nw.nos.boeing.com (10.57.37.61) by XCH-PHX-511.sw.nos.boeing.com (10.57.37.28) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 15 Aug 2014 16:19:48 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.6]) by XCH-BLV-205.nw.nos.boeing.com ([169.254.5.190]) with mapi id 14.03.0181.006; Fri, 15 Aug 2014 16:19:48 -0700 From: "Templin, Fred L" To: "dhcwg@ietf.org" Thread-Topic: [dhcwg] DHCPv6 server scaling Thread-Index: Ac+2upuh7YoQHY4/QqaL4wm+EJ+sGQB5dsCwAA+k0AAADoqwEP//rt2AgAB0hHCAAJpDsA== Date: Fri, 15 Aug 2014 23:19:47 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CF2776@XCH-BLV-504.nw.nos.boeing.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AF09B40@nkgeml512-mbx.china.huawei.com> <2134F8430051B64F815C691A62D9831832CF1FB5@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CF2066@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CF23B1@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832CF23B1@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/tgzFyzzhyTtDD0TImbuhoQSDnQw Subject: Re: [dhcwg] DHCPv6 server scaling X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 23:20:08 -0000 Hi, Here I think is a pretty effective way of using DHCPv6 and IPv6 Neighbor Discovery to manage mobile nodes in an enterprise network: http://www.ietf.org/id/draft-templin-aerolink-31.txt If you are only interested in how DHCPv6 is used and don't have time to read the entire document, check sections 3.10 and 3.14 for the DHCPv6-specific pieces. The most interesting aspect from a DHCPv6 perspective is that AERO assumes there may be many DHCPv6 servers sprinkled throughout the enterprise but there is no requirement for the servers to coordinate with one another (in fact, it is better if they don't even try). So, the client load can be distributed to many servers based on factors such as topological proximity, and each server can serve as a mini mobility anchor point. I think this could open new business opportunities for bringing DHCPv6 services to enterprise networks. And, it doesn't even require enterprises to move to IPv6 first, because the mechanisms work exactly the same for managing IPv4 networks. Anyway, I just thought it might be worth a look. Thanks - Fred fred.l.templin@boeing.com=20 From nobody Sat Aug 16 05:58:39 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC6EC1A8784 for ; Sat, 16 Aug 2014 05:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham 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 acaPFx9pxXNA for ; Sat, 16 Aug 2014 05:58:35 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 744DE1A8780 for ; Sat, 16 Aug 2014 05:58:35 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 422D71B8617 for ; Sat, 16 Aug 2014 05:58:35 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 254B753E070; Sat, 16 Aug 2014 05:58:25 -0700 (PDT) Received: from [10.0.10.40] (71.233.43.215) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sat, 16 Aug 2014 05:58:15 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <2134F8430051B64F815C691A62D9831832CF2776@XCH-BLV-504.nw.nos.boeing.com> Date: Sat, 16 Aug 2014 08:57:57 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <071B5C90-8CA4-453F-BA74-BB7CFEEA4335@nominum.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AF09B40@nkgeml512-mbx.china.huawei.com> <2134F8430051B64F815C691A62D9831832CF1FB5@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CF2066@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CF23B1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CF2776@XCH-BLV-504.nw.nos.boeing.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/mC3hRdUgw3MpmhG2UJpqSqjHjNM Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] DHCPv6 server scaling X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 12:58:37 -0000 On Aug 15, 2014, at 7:19 PM, Templin, Fred L = wrote: > The most interesting aspect from a DHCPv6 perspective is that AERO > assumes there may be many DHCPv6 servers sprinkled throughout the > enterprise but there is no requirement for the servers to coordinate > with one another (in fact, it is better if they don't even try). So, > the client load can be distributed to many servers based on factors > such as topological proximity, and each server can serve as a mini > mobility anchor point. But scalability typically isn't an issue in corporate networks, because = the client load is tiny. From nobody Sat Aug 16 15:47:09 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90EA71A0493 for ; Sat, 16 Aug 2014 15:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 4x7nCugGo7ON for ; Sat, 16 Aug 2014 15:47:05 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C5721A0491 for ; Sat, 16 Aug 2014 15:47:04 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id va2so2922642obc.26 for ; Sat, 16 Aug 2014 15:47: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:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=nAwM70RvAzjETQdN1S2AHpjm8pTP5n6Axz81mqsIbpc=; b=pz2Ba6CCU4pcyOvt9XQmPu2N751w0MVnlZ32jK3O98W+yK3awSF0yQvVZxzNHxC6l0 Jf7gXI7ynAznm92JsqD5GKx0rk3dxbtvPq+sHo7HVY3CRkaz1ux/U1DVt3YYdnMWapin 9AysWWdxi31nFHV3Vgf+omI5c/Qgez54QYsEKA/8NF4I5Nxg9+zWT2EamPo61eKunGIr ww82KYIlKvDhGVJvOoG3X7K/byLS3s0JV6HS/4Lm87NfuUPrVBbfjR85n7dcRN/mUrkF vddmLe1RFNR3N1VAaK3Xp3qLXGRX/1nOv7n72qiuRIyKW5YbgIK34ggdCk2ACFJPB3SP QLNw== MIME-Version: 1.0 X-Received: by 10.182.28.66 with SMTP id z2mr28520433obg.19.1408229224529; Sat, 16 Aug 2014 15:47:04 -0700 (PDT) Sender: budmillwood@gmail.com Received: by 10.60.50.130 with HTTP; Sat, 16 Aug 2014 15:47:04 -0700 (PDT) In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1B6567DC@xmb-rcd-x04.cisco.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AF09B40@nkgeml512-mbx.china.huawei.com> <2134F8430051B64F815C691A62D9831832CF1FB5@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CF2066@XCH-BLV-504.nw.nos.boeing.com> <2288B59A-FC7E-44DC-8E1F-663BF243A8B4@nominum.com> <489D13FBFA9B3E41812EA89F188F018E1B6567DC@xmb-rcd-x04.cisco.com> Date: Sun, 17 Aug 2014 00:47:04 +0200 X-Google-Sender-Auth: RE6l6-inF3_kDEM6KaeyR2kX-to Message-ID: From: Bud Millwood To: "Bernie Volz (volz)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/nPcLl2BnPyZHX9NfcpXU7kveuW8 Cc: Ted Lemon , "dhcwg@ietf.org" Subject: Re: [dhcwg] DHCPv6 server scaling X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 22:47:06 -0000 +1 for everything here, that's our experience on the server side. *Especially* drive speed. If you figure with 1000 leases/s sustained throughput, that's 600k leases in 10 minutes disregarding backoff. Depending on the configuration, the DHCP server can naturally spread the steady-state client load over time based on its own performance. - Bud On Fri, Aug 15, 2014 at 9:54 PM, Bernie Volz (volz) wrote: > This is a fairly complicated issue since servers also typically have a ma= ny features and depending on which ones are enabled/in use, performance can= vary considerably (consider logging, failover, DNS updates, Leasequery (si= ngleton, bulk, active), lease history, ...). Even the configuration complex= ity can have a (hopefully small) impact. > > The Cisco Prime Network Registrar server can handle a lot of load, but as= you turn on various features the performance will be impacted (that variou= s of course by feature). > > I think all servers are MOST impacted by disk performance - how fast they= can commit the lease information to disk since they must commit to disk be= fore responding to the client (although as Tomek recently pointed out to me= , RFC 2131 has such a requirement whereas RFC 3315 apparently does not stat= e this explicitly). > > On the flip side, rarely is CPU performance the limiting factor (especial= ly with any reasonable system today). DHCP (even DHCPv6 with longer address= es) is not CPU intensive. > > So when you are buying equipment, you should spend the money on a very hi= gh performance disk I/O subsystem (high RPM disks or solid state). RAID or = software volume shadowing should also be evaluated carefully since they typ= ically improve read performance, but significantly hurt write performance. > > Another consideration people often forget is steady state (i.e. when ever= ything is running normal and renewals and new clients are being serviced) v= s avalanche situations (such as when a large number of clients are coming b= ack after a power failure or other outage). You never want to build your se= rvice so that it is near the edge in steady state since that means they'll = be severely overloaded when an avalanche situation occurs (perhaps even a s= mall one). > > - Bernie > > -----Original Message----- > From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ted Lemon > Sent: Friday, August 15, 2014 2:33 PM > To: Simon Hobson > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] DHCPv6 server scaling > > On Aug 15, 2014, at 2:23 PM, Simon Hobson wrote: >> Another factor I forgot is your lease time - the longer the lease time, = the less frequently each client needs to renew. >> But, that's not the whole story. > > Has anybody written up an informational document that talks about these i= ssues? I confess I am not aware of one. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From nobody Mon Aug 18 08:38:51 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4369D1A0654 for ; Mon, 18 Aug 2014 08:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham 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 EUYAJryNHhBV for ; Mon, 18 Aug 2014 08:38:49 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 084841A0647 for ; Mon, 18 Aug 2014 08:38:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s7IFcmq4008838; Mon, 18 Aug 2014 08:38:48 -0700 Received: from XCH-PHX-410.sw.nos.boeing.com (xch-phx-410.sw.nos.boeing.com [10.57.37.41]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s7IFchcc008801 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 18 Aug 2014 08:38:43 -0700 Received: from XCH-BLV-308.nw.nos.boeing.com (130.247.25.220) by XCH-PHX-410.sw.nos.boeing.com (10.57.37.41) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 18 Aug 2014 08:38:43 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.6]) by XCH-BLV-308.nw.nos.boeing.com ([169.254.8.42]) with mapi id 14.03.0181.006; Mon, 18 Aug 2014 08:38:42 -0700 From: "Templin, Fred L" To: Ted Lemon Thread-Topic: [dhcwg] DHCPv6 server scaling Thread-Index: Ac+2upuh7YoQHY4/QqaL4wm+EJ+sGQB5dsCwAA+k0AAADoqwEP//rt2AgAB0hHCAAJpDsIAAKLKA//0l7nA= Date: Mon, 18 Aug 2014 15:38:42 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CF324A@XCH-BLV-504.nw.nos.boeing.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AF09B40@nkgeml512-mbx.china.huawei.com> <2134F8430051B64F815C691A62D9831832CF1FB5@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CF2066@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CF23B1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CF2776@XCH-BLV-504.nw.nos.boeing.com> <071B5C90-8CA4-453F-BA74-BB7CFEEA4335@nominum.com> In-Reply-To: <071B5C90-8CA4-453F-BA74-BB7CFEEA4335@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/0A5aCoADTDcC8vYG_7W_SuFdljY Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] DHCPv6 server scaling X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 15:38:50 -0000 Hi Ted, > -----Original Message----- > From: Ted Lemon [mailto:ted.lemon@nominum.com] > Sent: Saturday, August 16, 2014 5:58 AM > To: Templin, Fred L > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] DHCPv6 server scaling >=20 > On Aug 15, 2014, at 7:19 PM, Templin, Fred L = wrote: > > The most interesting aspect from a DHCPv6 perspective is that AERO > > assumes there may be many DHCPv6 servers sprinkled throughout the > > enterprise but there is no requirement for the servers to coordinate > > with one another (in fact, it is better if they don't even try). So, > > the client load can be distributed to many servers based on factors > > such as topological proximity, and each server can serve as a mini > > mobility anchor point. >=20 > But scalability typically isn't an issue in corporate networks, because t= he client load is tiny. That's fine, but what I am looking for is lots of AERO Servers to spread the traffic load for forwarding lots of IP packets. Distributed mobility management. And, I don't want the AERO Servers to have to talk to each other or to a centralized DHCPv6 server. So, it is better if each AERO Server also configures a DHCPv6 server, and that the Servers not talk to each other. That way, leases are between the Client and each Server it associates with, and there is no need for relay agents at all. This approach is opening new business opportunities for DHCPv6 networking gear in enterprise networks. And, it doesn't even have to wait for the enterprise network to transition over to IPv6 since it will handle IPv4 networks the same way. Thanks - Fred fred.l.templin@boeing.com From nobody Mon Aug 18 19:22:29 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 955C81A879B for ; Mon, 18 Aug 2014 19:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham 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 OG7XclYtk2ta for ; Mon, 18 Aug 2014 19:22:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F0751A879A for ; Mon, 18 Aug 2014 19:22:25 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIJ64029; Tue, 19 Aug 2014 02:22:23 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 19 Aug 2014 03:22:22 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.78]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Tue, 19 Aug 2014 10:22:16 +0800 From: Sheng Jiang To: "dhcwg@ietf.org" Thread-Topic: DHC Minutes Thread-Index: Ac+rveIMVhNDfIPPSU6bMQp7No7YWALYNRDgAB6cXeAAPnGDkACAzumwABdRODAAGBsWAA== Date: Tue, 19 Aug 2014 02:22:15 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AF0BA23@nkgeml512-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/qZqcYUkBb8J0Hht41dkjLW5kwBI Subject: [dhcwg] FW: DHC Minutes X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 02:22:27 -0000 SGksIERIQ2VycywNCg0KVGhlIG9mZmljaWFsIERIQyBtaW51dGVzIGhhdmUgYmVlbiB1cGRhdGVk Lg0KDQpUaGUgbWludXRlcyBhcmUgYXZhaWxhYmxlIGF0DQoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcv cHJvY2VlZGluZ3MvOTAvbWludXRlcy9taW51dGVzLTkwLWRoYw0KDQpCZXN0IHJlZ2FyZHMsDQoN ClNoZW5nLCBESEMgV0cgU2VjcmV0YXJ5DQo= From nobody Tue Aug 19 11:58:00 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB2401A0686 for ; Tue, 19 Aug 2014 11:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham 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 9teiiRNb9sHk for ; Tue, 19 Aug 2014 11:57:57 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A1BF1A8796 for ; Tue, 19 Aug 2014 11:57:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s7JIvYGY027034; Tue, 19 Aug 2014 11:57:34 -0700 Received: from XCH-PHX-112.sw.nos.boeing.com (xch-phx-112.sw.nos.boeing.com [130.247.25.134]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s7JIvS9j026480 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Tue, 19 Aug 2014 11:57:28 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.6]) by XCH-PHX-112.sw.nos.boeing.com ([169.254.12.37]) with mapi id 14.03.0181.006; Tue, 19 Aug 2014 11:57:27 -0700 From: "Templin, Fred L" To: "dhcwg@ietf.org" Thread-Topic: DHCPv6 Client Authentication question Thread-Index: Ac+732urpYl+hKbiTBmG8XdVIQqwtw== Date: Tue, 19 Aug 2014 18:57:27 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CF5253@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/LHNqT_gqZUkfQHdEvu9OiX0anoM Subject: [dhcwg] DHCPv6 Client Authentication question X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 18:57:58 -0000 I have a requirement for DHCPv6 servers to be able to authenticate clients on links where a rogue client may try to impersonate a real one. I have read RFC3315, Section 21 several times but I am still not understanding whether "Delayed Authentication" gives me what I am looking for. For example, I would like Clients to be able to use a two-message Solicit/Reply exchange instead of a four-message Solicit/Advertise/Request/Reply exchange, but I'm not sure that can be securely accommodated by Delayed Authentication. That said, I have seen ""Secure DHCPv6 with Public Key": http://datatracker.ietf.org/doc/draft-ietf-dhc-sedhcpv6/ and it looks like it could fit the bill although a bit heavier in weight than what I was hoping for. So, the question is whether my requirement can be satisfied by the base RFC3315 mechanisms alone, or must I use the new Secure DHCPv6 mechanisms mentioned above? Thanks - Fred fred.l.templin@boeing.com From nobody Wed Aug 20 13:28:56 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27DE81A0B0E for ; Wed, 20 Aug 2014 13:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.48 X-Spam-Level: X-Spam-Status: No, score=0.48 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 wFLt1wLXk8EC for ; Wed, 20 Aug 2014 13:28:51 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7805E1A0AF0 for ; Wed, 20 Aug 2014 13:28:51 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id s7KKSkch071507; Wed, 20 Aug 2014 22:28:46 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201408202028.s7KKSkch071507@givry.fdupont.fr> From: Francis Dupont To: "Templin, Fred L" In-reply-to: Your message of Tue, 19 Aug 2014 18:57:27 -0000. <2134F8430051B64F815C691A62D9831832CF5253@XCH-BLV-504.nw.nos.boeing.com> Date: Wed, 20 Aug 2014 22:28:46 +0200 Sender: Francis.Dupont@fdupont.fr Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/YDF3lmGJVCHIGoouhydMdYwcdXs Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] DHCPv6 Client Authentication question X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 20:28:53 -0000 In your previous mail you wrote: => the only relationship between "Delayed Authentication" and real authentication is in its name... (:-) > So, the question is whether my requirement can be satisfied by the > base RFC3315 mechanisms alone, or must I use the new Secure DHCPv6 > mechanisms mentioned above? => the second (Secure DHCPv6) of course. Regards Francis.Dupont@fdupont.fr From nobody Wed Aug 20 14:08:03 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 430751A6F55 for ; Wed, 20 Aug 2014 14:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham 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 KZdzD4_sdUzo for ; Wed, 20 Aug 2014 14:07:57 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D33611A6ED8 for ; Wed, 20 Aug 2014 14:07:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s7KL7sL8021844; Wed, 20 Aug 2014 14:07:55 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com (xch-blv-504.nw.nos.boeing.com [130.247.25.194]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s7KL7oCd021784 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 20 Aug 2014 14:07:50 -0700 Received: from XCH-BLV-101.nw.nos.boeing.com (2002:82f7:1974::82f7:1974) by XCH-BLV-504.nw.nos.boeing.com (2002:82f7:19c2::82f7:19c2) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 20 Aug 2014 14:07:50 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.6]) by XCH-BLV-101.nw.nos.boeing.com ([169.254.1.180]) with mapi id 14.03.0181.006; Wed, 20 Aug 2014 14:07:49 -0700 From: "Templin, Fred L" To: "dhcwg@ietf.org" Thread-Topic: Question on draft-ietf-dhc-sedhcpv6 Thread-Index: Ac+8usvtlThiaS7BTzagQmSX8ZEBQg== Date: Wed, 20 Aug 2014 21:07:49 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CF60F1@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/q9DFp5hQUR1GYNFd1DvZSzRWcCs Cc: "jinmei@wide.ad.jp" Subject: [dhcwg] Question on draft-ietf-dhc-sedhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 21:07:59 -0000 Hi, In this draft, Section 6.2 says: "6.2 Processing Rules of a Recipient The recipient of a Secure DHCPv6 message could be a DHCPv6 server or a DHCPv6 client. In the failure cases, both DHCPv6 server and client SHOULD NOT process received message, and the server SHOULD reply a correspondent error status code, while the client does nothing." But, on links where rogue clients could spoof the identity of legitimate clients, why should the server reply with an error status code? If the rogue client gets the error code, it knows that its attack has failed. If the legitimate client gets the error code, it will be confused since it hasn't sent anything that would generate an error. So, why isn't it the case that the server should do nothing the same as for clients? Or, at least maybe there could be a configuration setting the allows servers to ignore failure cases instead of respond to them? Thanks - Fred fred.l.templin@boeing.com From nobody Wed Aug 20 14:49:14 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5960E1A882B for ; Wed, 20 Aug 2014 14:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham 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 8e8yRZwdx3q7 for ; Wed, 20 Aug 2014 14:49:07 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52F5B1A882E for ; Wed, 20 Aug 2014 14:49:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s7KLn43j021186; Wed, 20 Aug 2014 14:49:04 -0700 Received: from XCH-BLV-502.nw.nos.boeing.com (xch-blv-502.nw.nos.boeing.com [130.247.25.191]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s7KLn0iT021170 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 20 Aug 2014 14:49:01 -0700 Received: from XCH-BLV-406.nw.nos.boeing.com (2002:82f7:19a2::82f7:19a2) by XCH-BLV-502.nw.nos.boeing.com (2002:82f7:19bf::82f7:19bf) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 20 Aug 2014 14:49:00 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.6]) by XCH-BLV-406.nw.nos.boeing.com ([169.254.6.97]) with mapi id 14.03.0181.006; Wed, 20 Aug 2014 14:48:59 -0700 From: "Templin, Fred L" To: "Francis.Dupont@fdupont.fr" Thread-Topic: [dhcwg] DHCPv6 Client Authentication question Thread-Index: AQHPvMCMclnAxOs0DkSEtD7AO8bV9A== Date: Wed, 20 Aug 2014 21:48:59 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CF618A@XCH-BLV-504.nw.nos.boeing.com> References: Your message of Tue, 19 Aug 2014 18:57:27 -0000. <2134F8430051B64F815C691A62D9831832CF5253@XCH-BLV-504.nw.nos.boeing.com> <201408202028.s7KKSkch071507@givry.fdupont.fr> In-Reply-To: <201408202028.s7KKSkch071507@givry.fdupont.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/ZQZsGCfUFJuWlJihDfDNqtz7I-k Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] DHCPv6 Client Authentication question X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 21:49:11 -0000 Thanks Francis, > -----Original Message----- > From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > Sent: Wednesday, August 20, 2014 1:29 PM > To: Templin, Fred L > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] DHCPv6 Client Authentication question >=20 > In your previous mail you wrote: >=20 > =3D> the only relationship between "Delayed Authentication" and > real authentication is in its name... (:-) >=20 > > So, the question is whether my requirement can be satisfied by the > > base RFC3315 mechanisms alone, or must I use the new Secure DHCPv6 > > mechanisms mentioned above? >=20 > =3D> the second (Secure DHCPv6) of course. Is it just me, or are the RFC3315 DHCPv6 authentication mechanisms a bit sketchy? Is anyone using them in actual practice? Thanks - Fred fred.l.templn@boeing.com=20 > Regards >=20 > Francis.Dupont@fdupont.fr From nobody Thu Aug 21 01:31:05 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD9011A00DD for ; Thu, 21 Aug 2014 01:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham 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 3Jp86FBRYjJg for ; Thu, 21 Aug 2014 01:31:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B95E1A0007 for ; Thu, 21 Aug 2014 01:30:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLM77103; Thu, 21 Aug 2014 08:30:55 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 21 Aug 2014 09:30:47 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.78]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Thu, 21 Aug 2014 16:30:36 +0800 From: Sheng Jiang To: "Templin, Fred L" , "dhcwg@ietf.org" Thread-Topic: Question on draft-ietf-dhc-sedhcpv6 Thread-Index: Ac+8usvtlThiaS7BTzagQmSX8ZEBQgAXZQCA Date: Thu, 21 Aug 2014 08:30:35 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AF0D823@nkgeml512-mbx.china.huawei.com> References: <2134F8430051B64F815C691A62D9831832CF60F1@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832CF60F1@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/SR9u6ugD2t1k8PGBlRgbOSOKxg4 Cc: "jinmei@wide.ad.jp" Subject: Re: [dhcwg] Question on draft-ietf-dhc-sedhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 08:31:01 -0000 SGksIEZyZWQsDQoNClRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4gVGhlIGN1cnJlbnQgc3RhdHVz IGlzIHRoYXQgd2UgcHJvYmFibHkgd291bGQgZ2V0IHJpZCBvZiB0aGUgY2xpZW50IGF1dGhlbnRp Y2F0aW9uIG9uIHNlcnZlciB0b3RhbGx5LCBnaXZlbiB0aGUgcHJldmlvdXMgY29tbWVudHMuIEl0 IHNlZW1zIHRoZSBjbGllbnQgYXV0aGVudGljYXRpb24gb24gc2VydmVyIGhhcyBubyBtdWNoIHZh bHVlIGFuZCB0aGVyZSBpcyBsb25nIHdheSB0byBnbyB0byBwcm9wZXJseSBzZXR1cCBjZXJ0aWZp Y2F0ZSBhbmQgdHJ1c3QgYW5jaG9yIG9uIGNsaWVudHMuIFRoZSBuZXh0IHZlcnNpb24gcHJvYmFi bHkgd2lsbCBoYXZlIG9uZSBzZXJ2ZXIgYXV0aGVudGljYXRpb24gb24gY2xpZW50IGJhc2Ugb24g TGVhZiBvZiBGYWl0aCBtb2RlbC4gU3RpbGwsIHNvbWUgdGVjaG5pY2FsIHJlcGxpZXMgaW4gbGlu ZXMuDQoNCj5JbiB0aGlzIGRyYWZ0LCBTZWN0aW9uIDYuMiBzYXlzOg0KPg0KPiI2LjIgUHJvY2Vz c2luZyBSdWxlcyBvZiBhIFJlY2lwaWVudA0KPg0KPiAgIFRoZSByZWNpcGllbnQgb2YgYSBTZWN1 cmUgREhDUHY2IG1lc3NhZ2UgY291bGQgYmUgYSBESENQdjYgc2VydmVyIG9yDQo+ICAgYSBESENQ djYgY2xpZW50LiAgSW4gdGhlIGZhaWx1cmUgY2FzZXMsIGJvdGggREhDUHY2IHNlcnZlciBhbmQg Y2xpZW50DQo+ICAgU0hPVUxEIE5PVCBwcm9jZXNzIHJlY2VpdmVkIG1lc3NhZ2UsIGFuZCB0aGUg c2VydmVyIFNIT1VMRCByZXBseSBhDQo+ICAgY29ycmVzcG9uZGVudCBlcnJvciBzdGF0dXMgY29k ZSwgd2hpbGUgdGhlIGNsaWVudCBkb2VzIG5vdGhpbmcuIg0KPg0KPkJ1dCwgb24gbGlua3Mgd2hl cmUgcm9ndWUgY2xpZW50cyBjb3VsZCBzcG9vZiB0aGUgaWRlbnRpdHkgb2YNCj5sZWdpdGltYXRl IGNsaWVudHMsIA0KDQpJZGVhbGx5LCB0aGUgaWRlbnRpdHkgb2YgbGVnaXRpbWF0ZSBjbGllbnRz IHNob3VsZCBub3QgYmUgYWJsZSB0byBiZSBzcG9vZmVkLiBJdCBpcyBzaWduZWQgYnkgdGhlIHBy aXZhdGUga2V5IG9mIGNsaWVudC4gVGhlIHNlcnZlciB3b3VsZCB2YWxpZGF0ZSB0aGUgc2lnbmF0 dXJlIGZpcnN0Lg0KDQo+d2h5IHNob3VsZCB0aGUgc2VydmVyIHJlcGx5IHdpdGggYW4gZXJyb3IN Cj5zdGF0dXMgY29kZT8gSWYgdGhlIHJvZ3VlIGNsaWVudCBnZXRzIHRoZSBlcnJvciBjb2RlLCBp dCBrbm93cw0KPnRoYXQgaXRzIGF0dGFjayBoYXMgZmFpbGVkLiBJZiB0aGUgbGVnaXRpbWF0ZSBj bGllbnQgZ2V0cyB0aGUNCj5lcnJvciBjb2RlLCBpdCB3aWxsIGJlIGNvbmZ1c2VkIHNpbmNlIGl0 IGhhc24ndCBzZW50IGFueXRoaW5nDQo+dGhhdCB3b3VsZCBnZW5lcmF0ZSBhbiBlcnJvci4NCg0K VGhlIG1hbmRhdG9yeSByZXNwb25zZSBpcyB0aGUgcmVzdWx0IG9mIERIQyBXRyBkaXNjdXNzaW9u LiBJZiB0aGUgYWJvdmUgYXNzdW1wdGlvbiAodGhlIGlkZW50aXR5IG9mIGxlZ2l0aW1hdGUgY2xp ZW50cyBjb3VsZCBub3QgYmUgc3Bvb2ZlZCkgc3RhbmRzLCB0aGUgZXJyb3IgY29kZSB3b3VsZCBv bmx5IGJlIHJlcGxpZWQgdG8gdGhlIGxlZ2l0aW1hdGUgY2xpZW50IHdobyBzZW5kIHJlcXVlc3Qu DQoNCkJlc3QgcmVnYXJkcywNCg0KU2hlbmcNCg0KPlNvLCB3aHkgaXNuJ3QgaXQgdGhlIGNhc2Ug dGhhdCB0aGUgc2VydmVyIHNob3VsZCBkbyBub3RoaW5nIHRoZQ0KPnNhbWUgYXMgZm9yIGNsaWVu dHM/IE9yLCBhdCBsZWFzdCBtYXliZSB0aGVyZSBjb3VsZCBiZSBhDQo+Y29uZmlndXJhdGlvbiBz ZXR0aW5nIHRoZSBhbGxvd3Mgc2VydmVycyB0byBpZ25vcmUgZmFpbHVyZSBjYXNlcw0KPmluc3Rl YWQgb2YgcmVzcG9uZCB0byB0aGVtPw0KPg0KPlRoYW5rcyAtIEZyZWQNCj5mcmVkLmwudGVtcGxp bkBib2VpbmcuY29tDQo= From nobody Thu Aug 21 02:15:36 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF0DD1A00A7 for ; Thu, 21 Aug 2014 02:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham 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 JVZr1q6waKzF for ; Thu, 21 Aug 2014 02:15:32 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3BD81A0091 for ; Thu, 21 Aug 2014 02:15:31 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLM82621; Thu, 21 Aug 2014 09:15:30 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 21 Aug 2014 10:15:29 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.78]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Thu, 21 Aug 2014 17:15:21 +0800 From: Sheng Jiang To: Sheng Jiang , "Templin, Fred L" , "dhcwg@ietf.org" Thread-Topic: Question on draft-ietf-dhc-sedhcpv6 Thread-Index: Ac+8usvtlThiaS7BTzagQmSX8ZEBQgAXZQCAAAHcdkA= Date: Thu, 21 Aug 2014 09:15:21 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AF0D8AE@nkgeml512-mbx.china.huawei.com> References: <2134F8430051B64F815C691A62D9831832CF60F1@XCH-BLV-504.nw.nos.boeing.com> <5D36713D8A4E7348A7E10DF7437A4B923AF0D823@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AF0D823@nkgeml512-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/Ak2TCRn44H8OLknVA0YU1IdgCvY Cc: "jinmei@wide.ad.jp" Subject: Re: [dhcwg] Question on draft-ietf-dhc-sedhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 09:15:34 -0000 SGksIEZyZWQsDQoNCkl0IG1heSBiZSBoZWxwZnVsIGZvciB1cyB0byByZS1kZWNpZGUgd2hldGhl ciB3ZSBrZWVwIHRoZSBjbGllbnQgYXV0aGVudGljYXRpb24gb24gc2VydmVyIGlmIHlvdSBjb3Vs ZCBkZXNjcmliZSB5b3VyIHJlcXVpcmUgc2NlbmFyaW8gaW4gZGV0YWlscy4gVGhlbiB3ZSBjYW4g ZXZhbHVhdGUgd2hldGhlciBjbGllbnQgYXV0aGVudGljYXRpb24gb24gc2VydmVyIGJhc2VkIG9u IExlYWYgb2YgRmFpdGggbW9kZWwgY291bGQgbWVldCB5b3VyIHJlcXVpcmVtZW50cywgb3IgaXQg aGFzIHRvIGJlIGNlcnRpZmljYXRlIHdpdGggdHJ1c3QgYW5jaG9yIG9uIGNsaWVudHMuDQoNClJl Z2FyZHMsDQoNClNoZW5nDQoNCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IGRo Y3dnIFttYWlsdG86ZGhjd2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFNoZW5nIEpp YW5nDQo+U2VudDogVGh1cnNkYXksIEF1Z3VzdCAyMSwgMjAxNCA0OjMxIFBNDQo+VG86IFRlbXBs aW4sIEZyZWQgTDsgZGhjd2dAaWV0Zi5vcmcNCj5DYzogamlubWVpQHdpZGUuYWQuanANCj5TdWJq ZWN0OiBSZTogW2RoY3dnXSBRdWVzdGlvbiBvbiBkcmFmdC1pZXRmLWRoYy1zZWRoY3B2Ng0KPg0K PkhpLCBGcmVkLA0KPg0KPlRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4gVGhlIGN1cnJlbnQgc3Rh dHVzIGlzIHRoYXQgd2UgcHJvYmFibHkgd291bGQgZ2V0DQo+cmlkIG9mIHRoZSBjbGllbnQgYXV0 aGVudGljYXRpb24gb24gc2VydmVyIHRvdGFsbHksIGdpdmVuIHRoZSBwcmV2aW91cyBjb21tZW50 cy4NCj5JdCBzZWVtcyB0aGUgY2xpZW50IGF1dGhlbnRpY2F0aW9uIG9uIHNlcnZlciBoYXMgbm8g bXVjaCB2YWx1ZSBhbmQgdGhlcmUgaXMNCj5sb25nIHdheSB0byBnbyB0byBwcm9wZXJseSBzZXR1 cCBjZXJ0aWZpY2F0ZSBhbmQgdHJ1c3QgYW5jaG9yIG9uIGNsaWVudHMuIFRoZQ0KPm5leHQgdmVy c2lvbiBwcm9iYWJseSB3aWxsIGhhdmUgb25lIHNlcnZlciBhdXRoZW50aWNhdGlvbiBvbiBjbGll bnQgYmFzZSBvbg0KPkxlYWYgb2YgRmFpdGggbW9kZWwuIFN0aWxsLCBzb21lIHRlY2huaWNhbCBy ZXBsaWVzIGluIGxpbmVzLg0KPg0KPj5JbiB0aGlzIGRyYWZ0LCBTZWN0aW9uIDYuMiBzYXlzOg0K Pj4NCj4+IjYuMiBQcm9jZXNzaW5nIFJ1bGVzIG9mIGEgUmVjaXBpZW50DQo+Pg0KPj4gICBUaGUg cmVjaXBpZW50IG9mIGEgU2VjdXJlIERIQ1B2NiBtZXNzYWdlIGNvdWxkIGJlIGEgREhDUHY2IHNl cnZlciBvcg0KPj4gICBhIERIQ1B2NiBjbGllbnQuICBJbiB0aGUgZmFpbHVyZSBjYXNlcywgYm90 aCBESENQdjYgc2VydmVyIGFuZCBjbGllbnQNCj4+ICAgU0hPVUxEIE5PVCBwcm9jZXNzIHJlY2Vp dmVkIG1lc3NhZ2UsIGFuZCB0aGUgc2VydmVyIFNIT1VMRCByZXBseSBhDQo+PiAgIGNvcnJlc3Bv bmRlbnQgZXJyb3Igc3RhdHVzIGNvZGUsIHdoaWxlIHRoZSBjbGllbnQgZG9lcyBub3RoaW5nLiIN Cj4+DQo+PkJ1dCwgb24gbGlua3Mgd2hlcmUgcm9ndWUgY2xpZW50cyBjb3VsZCBzcG9vZiB0aGUg aWRlbnRpdHkgb2YNCj4+bGVnaXRpbWF0ZSBjbGllbnRzLA0KPg0KPklkZWFsbHksIHRoZSBpZGVu dGl0eSBvZiBsZWdpdGltYXRlIGNsaWVudHMgc2hvdWxkIG5vdCBiZSBhYmxlIHRvIGJlIHNwb29m ZWQuIEl0IGlzDQo+c2lnbmVkIGJ5IHRoZSBwcml2YXRlIGtleSBvZiBjbGllbnQuIFRoZSBzZXJ2 ZXIgd291bGQgdmFsaWRhdGUgdGhlIHNpZ25hdHVyZQ0KPmZpcnN0Lg0KPg0KPj53aHkgc2hvdWxk IHRoZSBzZXJ2ZXIgcmVwbHkgd2l0aCBhbiBlcnJvcg0KPj5zdGF0dXMgY29kZT8gSWYgdGhlIHJv Z3VlIGNsaWVudCBnZXRzIHRoZSBlcnJvciBjb2RlLCBpdCBrbm93cw0KPj50aGF0IGl0cyBhdHRh Y2sgaGFzIGZhaWxlZC4gSWYgdGhlIGxlZ2l0aW1hdGUgY2xpZW50IGdldHMgdGhlDQo+PmVycm9y IGNvZGUsIGl0IHdpbGwgYmUgY29uZnVzZWQgc2luY2UgaXQgaGFzbid0IHNlbnQgYW55dGhpbmcN Cj4+dGhhdCB3b3VsZCBnZW5lcmF0ZSBhbiBlcnJvci4NCj4NCj5UaGUgbWFuZGF0b3J5IHJlc3Bv bnNlIGlzIHRoZSByZXN1bHQgb2YgREhDIFdHIGRpc2N1c3Npb24uIElmIHRoZSBhYm92ZQ0KPmFz c3VtcHRpb24gKHRoZSBpZGVudGl0eSBvZiBsZWdpdGltYXRlIGNsaWVudHMgY291bGQgbm90IGJl IHNwb29mZWQpIHN0YW5kcywNCj50aGUgZXJyb3IgY29kZSB3b3VsZCBvbmx5IGJlIHJlcGxpZWQg dG8gdGhlIGxlZ2l0aW1hdGUgY2xpZW50IHdobyBzZW5kDQo+cmVxdWVzdC4NCj4NCj5CZXN0IHJl Z2FyZHMsDQo+DQo+U2hlbmcNCj4NCj4+U28sIHdoeSBpc24ndCBpdCB0aGUgY2FzZSB0aGF0IHRo ZSBzZXJ2ZXIgc2hvdWxkIGRvIG5vdGhpbmcgdGhlDQo+PnNhbWUgYXMgZm9yIGNsaWVudHM/IE9y LCBhdCBsZWFzdCBtYXliZSB0aGVyZSBjb3VsZCBiZSBhDQo+PmNvbmZpZ3VyYXRpb24gc2V0dGlu ZyB0aGUgYWxsb3dzIHNlcnZlcnMgdG8gaWdub3JlIGZhaWx1cmUgY2FzZXMNCj4+aW5zdGVhZCBv ZiByZXNwb25kIHRvIHRoZW0/DQo+Pg0KPj5UaGFua3MgLSBGcmVkDQo+PmZyZWQubC50ZW1wbGlu QGJvZWluZy5jb20NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPmRoY3dnIG1haWxpbmcgbGlzdA0KPmRoY3dnQGlldGYub3JnDQo+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaGN3Zw0K From nobody Thu Aug 21 07:36:37 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15D501A87CA for ; Thu, 21 Aug 2014 07:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.22 X-Spam-Level: X-Spam-Status: No, score=-2.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 bBCrl9FPMui6 for ; Thu, 21 Aug 2014 07:36:32 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9E551A03A7 for ; Thu, 21 Aug 2014 07:36:31 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id s7LEaQYa037662; Thu, 21 Aug 2014 16:36:27 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201408211436.s7LEaQYa037662@givry.fdupont.fr> From: Francis Dupont To: "Templin, Fred L" In-reply-to: Your message of Wed, 20 Aug 2014 21:48:59 -0000. <2134F8430051B64F815C691A62D9831832CF618A@XCH-BLV-504.nw.nos.boeing.com> Date: Thu, 21 Aug 2014 16:36:26 +0200 Sender: Francis.Dupont@fdupont.fr Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/gJr1-z_KRXMlfR6u7H3NjyYGeq4 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] DHCPv6 Client Authentication question X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 14:36:34 -0000 In your previous mail you wrote: > Is it just me, or are the RFC3315 DHCPv6 authentication mechanisms > a bit sketchy? => my recommendation as a multiple implementor of DHCPv6 was (and still is) to explain to someone who ask for support of this what this really does. Note I've never seen such request to go further... > Is anyone using them in actual practice? => I've heart it is supported and used so someone found an use case. I suggest to look for a DHCPv6 implementation with support of this, and to ask implementors (or to wait as they should be in this list :-). Regards Francis.Dupont@fdupont.fr PS: securing ND or DHCPv6 is a very hard problem. We have a solution for ND (SeND) so we should get one for DHCPv6. Unfortunately it will likely share SeND complexity, deployment costs and lack of public market (public == not military or similar). For your application, the cost of the current secure DHCPv6 proposal comes mainly from the intra-exchange constraint (vs inter-exchange, think about DTLS for instance where security contexts spend over far more than one packet). From nobody Thu Aug 21 09:20:01 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2831A0693 for ; Thu, 21 Aug 2014 09:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham 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 GG8GK-Nff7W4 for ; Thu, 21 Aug 2014 09:19:57 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 442CF1A033C for ; Thu, 21 Aug 2014 09:19:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s7LGJuLQ028654; Thu, 21 Aug 2014 09:19:57 -0700 Received: from XCH-PHX-312.sw.nos.boeing.com (xch-phx-312.sw.nos.boeing.com [130.247.25.173]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s7LGJplr028554 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 21 Aug 2014 09:19:51 -0700 Received: from XCH-BLV-201.nw.nos.boeing.com (10.57.37.66) by XCH-PHX-312.sw.nos.boeing.com (130.247.25.173) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 21 Aug 2014 09:19:51 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.6]) by XCH-BLV-201.nw.nos.boeing.com ([169.254.1.212]) with mapi id 14.03.0181.006; Thu, 21 Aug 2014 09:19:51 -0700 From: "Templin, Fred L" To: Sheng Jiang , "dhcwg@ietf.org" Thread-Topic: Question on draft-ietf-dhc-sedhcpv6 Thread-Index: Ac+8usvtlThiaS7BTzagQmSX8ZEBQgAXZQCAABCCZXA= Date: Thu, 21 Aug 2014 16:19:50 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CF7AE5@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832CF60F1@XCH-BLV-504.nw.nos.boeing.com> <5D36713D8A4E7348A7E10DF7437A4B923AF0D823@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AF0D823@nkgeml512-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/cEdH8iERXRJc4bzGcbp22l3jq9U Cc: "jinmei@wide.ad.jp" Subject: Re: [dhcwg] Question on draft-ietf-dhc-sedhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 16:19:59 -0000 SGkgU2hlbmcsDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogU2hlbmcg SmlhbmcgW21haWx0bzpqaWFuZ3NoZW5nQGh1YXdlaS5jb21dDQo+IFNlbnQ6IFRodXJzZGF5LCBB dWd1c3QgMjEsIDIwMTQgMTozMSBBTQ0KPiBUbzogVGVtcGxpbiwgRnJlZCBMOyBkaGN3Z0BpZXRm Lm9yZw0KPiBDYzogc2hlbnNodW9AY25uaWMuY247IFpoYW5nZGFjaGVuZyAoRGFjaGVuZyk7IGpp bm1laUB3aWRlLmFkLmpwDQo+IFN1YmplY3Q6IFJFOiBRdWVzdGlvbiBvbiBkcmFmdC1pZXRmLWRo Yy1zZWRoY3B2Ng0KPiANCj4gSGksIEZyZWQsDQo+IA0KPiBUaGFua3MgZm9yIHlvdXIgY29tbWVu dHMuIFRoZSBjdXJyZW50IHN0YXR1cyBpcyB0aGF0IHdlIHByb2JhYmx5IHdvdWxkIGdldCByaWQg b2YgdGhlIGNsaWVudA0KPiBhdXRoZW50aWNhdGlvbiBvbiBzZXJ2ZXIgdG90YWxseSwgZ2l2ZW4g dGhlIHByZXZpb3VzIGNvbW1lbnRzLiBJdCBzZWVtcyB0aGUgY2xpZW50IGF1dGhlbnRpY2F0aW9u IG9uDQo+IHNlcnZlciBoYXMgbm8gbXVjaCB2YWx1ZSBhbmQgdGhlcmUgaXMgbG9uZyB3YXkgdG8g Z28gdG8gcHJvcGVybHkgc2V0dXAgY2VydGlmaWNhdGUgYW5kIHRydXN0IGFuY2hvciBvbg0KPiBj bGllbnRzLiBUaGUgbmV4dCB2ZXJzaW9uIHByb2JhYmx5IHdpbGwgaGF2ZSBvbmUgc2VydmVyIGF1 dGhlbnRpY2F0aW9uIG9uIGNsaWVudCBiYXNlIG9uIExlYWYgb2YgRmFpdGgNCj4gbW9kZWwuDQoN CkRvZXMgdGhpcyBtZWFuIHRoYXQgdGhlIENlcnRpZmljYXRlIE9wdGlvbiB3aWxsIGJlIGRyb3Bw ZWQgZnJvbQ0KdGhlIG5leHQgdmVyc2lvbj8gSW4gbXkgdXNlIGNhc2UsIEkgYW0gT0sgd2l0aCBh IGNsaWVudCB0YWtpbmcgYQ0KbGVhcCBvZiBmYWl0aCBpbiB0cnVzdGluZyBhIHNlcnZlciwgYnV0 IEkgYW0gbm90IE9LIHdpdGggYSBzZXJ2ZXINCnRha2luZyBhIGxlYXAgb2YgZmFpdGggaW4gdHJ1 c3RpbmcgYSBjbGllbnQuDQoNCj4gU3RpbGwsIHNvbWUgdGVjaG5pY2FsIHJlcGxpZXMgaW4gbGlu ZXMuDQo+IA0KPiA+SW4gdGhpcyBkcmFmdCwgU2VjdGlvbiA2LjIgc2F5czoNCj4gPg0KPiA+IjYu MiBQcm9jZXNzaW5nIFJ1bGVzIG9mIGEgUmVjaXBpZW50DQo+ID4NCj4gPiAgIFRoZSByZWNpcGll bnQgb2YgYSBTZWN1cmUgREhDUHY2IG1lc3NhZ2UgY291bGQgYmUgYSBESENQdjYgc2VydmVyIG9y DQo+ID4gICBhIERIQ1B2NiBjbGllbnQuICBJbiB0aGUgZmFpbHVyZSBjYXNlcywgYm90aCBESENQ djYgc2VydmVyIGFuZCBjbGllbnQNCj4gPiAgIFNIT1VMRCBOT1QgcHJvY2VzcyByZWNlaXZlZCBt ZXNzYWdlLCBhbmQgdGhlIHNlcnZlciBTSE9VTEQgcmVwbHkgYQ0KPiA+ICAgY29ycmVzcG9uZGVu dCBlcnJvciBzdGF0dXMgY29kZSwgd2hpbGUgdGhlIGNsaWVudCBkb2VzIG5vdGhpbmcuIg0KPiA+ DQo+ID5CdXQsIG9uIGxpbmtzIHdoZXJlIHJvZ3VlIGNsaWVudHMgY291bGQgc3Bvb2YgdGhlIGlk ZW50aXR5IG9mDQo+ID5sZWdpdGltYXRlIGNsaWVudHMsDQo+IA0KPiBJZGVhbGx5LCB0aGUgaWRl bnRpdHkgb2YgbGVnaXRpbWF0ZSBjbGllbnRzIHNob3VsZCBub3QgYmUgYWJsZSB0byBiZSBzcG9v ZmVkLiBJdCBpcyBzaWduZWQgYnkgdGhlDQo+IHByaXZhdGUga2V5IG9mIGNsaWVudC4gVGhlIHNl cnZlciB3b3VsZCB2YWxpZGF0ZSB0aGUgc2lnbmF0dXJlIGZpcnN0Lg0KDQpJZiBsZWdpdGltYXRl IGNsaWVudCBBIHNpZ25zIHRoZSBtZXNzYWdlIHdpdGggaXRzIGNvcnJlY3QgcHJpdmF0ZSBrZXks DQp5ZXQgc2VydmVyIFMgaXMgc29tZWhvdyB1bmFibGUgdG8gYWNjZXB0IHRoZSBtZXNzYWdlLCB0 aGVuIHllcyBTIGNvdWxkDQpzYWZlbHkgcmV0dXJuIGEgc3RhdHVzIGNvZGUgdG8gQS4gQnV0LCBp ZiBib2d1cyBjbGllbnQgQiBzaWducyB0aGUNCm1lc3NhZ2Ugd2l0aCBhIGJvZ3VzIHByaXZhdGUg a2V5LCBzaG91bGRuJ3QgUyBzaW1wbHkgaWdub3JlIHRoZSBtZXNzYWdlPyANCk90aGVyd2lzZSwg aXQgd291bGQgYmUgZGl2dWxnaW5nIHNlbnNpdGl2ZSBpbmZvcm1hdGlvbiB0byBCLCB3b3VsZG4n dCBpdD8NCiANCj4gPndoeSBzaG91bGQgdGhlIHNlcnZlciByZXBseSB3aXRoIGFuIGVycm9yDQo+ ID5zdGF0dXMgY29kZT8gSWYgdGhlIHJvZ3VlIGNsaWVudCBnZXRzIHRoZSBlcnJvciBjb2RlLCBp dCBrbm93cw0KPiA+dGhhdCBpdHMgYXR0YWNrIGhhcyBmYWlsZWQuIElmIHRoZSBsZWdpdGltYXRl IGNsaWVudCBnZXRzIHRoZQ0KPiA+ZXJyb3IgY29kZSwgaXQgd2lsbCBiZSBjb25mdXNlZCBzaW5j ZSBpdCBoYXNuJ3Qgc2VudCBhbnl0aGluZw0KPiA+dGhhdCB3b3VsZCBnZW5lcmF0ZSBhbiBlcnJv ci4NCj4gDQo+IFRoZSBtYW5kYXRvcnkgcmVzcG9uc2UgaXMgdGhlIHJlc3VsdCBvZiBESEMgV0cg ZGlzY3Vzc2lvbi4gSWYgdGhlIGFib3ZlIGFzc3VtcHRpb24gKHRoZSBpZGVudGl0eSBvZg0KPiBs ZWdpdGltYXRlIGNsaWVudHMgY291bGQgbm90IGJlIHNwb29mZWQpIHN0YW5kcywgdGhlIGVycm9y IGNvZGUgd291bGQgb25seSBiZSByZXBsaWVkIHRvIHRoZQ0KPiBsZWdpdGltYXRlIGNsaWVudCB3 aG8gc2VuZCByZXF1ZXN0Lg0KDQpNYXliZSBJIGFtIHN0aWxsIG5vdCB1bmRlcnN0YW5kaW5nLCBi dXQgSSBkb24ndCB0aGluayBhbnkgZXJyb3IgY29kZQ0Kc2hvdWxkIGJlIHJldHVybmVkIHRvIGFu IGF0dGFja2VyLg0KDQpUaGFua3MgLSBGcmVkDQpmcmVkLmwudGVtcGxpbkBib2VpbmcuY29tDQoN Cj4gQmVzdCByZWdhcmRzLA0KPiANCj4gU2hlbmcNCj4gDQo+ID5Tbywgd2h5IGlzbid0IGl0IHRo ZSBjYXNlIHRoYXQgdGhlIHNlcnZlciBzaG91bGQgZG8gbm90aGluZyB0aGUNCj4gPnNhbWUgYXMg Zm9yIGNsaWVudHM/IE9yLCBhdCBsZWFzdCBtYXliZSB0aGVyZSBjb3VsZCBiZSBhDQo+ID5jb25m aWd1cmF0aW9uIHNldHRpbmcgdGhlIGFsbG93cyBzZXJ2ZXJzIHRvIGlnbm9yZSBmYWlsdXJlIGNh c2VzDQo+ID5pbnN0ZWFkIG9mIHJlc3BvbmQgdG8gdGhlbT8NCj4gPg0KPiA+VGhhbmtzIC0gRnJl ZA0KPiA+ZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbQ0K From nobody Thu Aug 21 09:32:25 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61AA91A050E for ; Thu, 21 Aug 2014 09:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham 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 N7dyo5eAyzFc for ; Thu, 21 Aug 2014 09:32:21 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 891C61A03E2 for ; Thu, 21 Aug 2014 09:32:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s7LGWL4Q027853; Thu, 21 Aug 2014 09:32:21 -0700 Received: from XCH-PHX-213.sw.nos.boeing.com (xch-phx-213.sw.nos.boeing.com [130.247.25.142]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s7LGWG5C027841 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 21 Aug 2014 09:32:17 -0700 Received: from XCH-BLV-201.nw.nos.boeing.com (10.57.37.66) by XCH-PHX-213.sw.nos.boeing.com (130.247.25.142) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 21 Aug 2014 09:32:16 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.6]) by XCH-BLV-201.nw.nos.boeing.com ([169.254.1.212]) with mapi id 14.03.0181.006; Thu, 21 Aug 2014 09:32:15 -0700 From: "Templin, Fred L" To: Sheng Jiang , "dhcwg@ietf.org" Thread-Topic: Question on draft-ietf-dhc-sedhcpv6 Thread-Index: Ac+8usvtlThiaS7BTzagQmSX8ZEBQgAXZQCAAAHcdkAADwAdYA== Date: Thu, 21 Aug 2014 16:32:15 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CF7B7B@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832CF60F1@XCH-BLV-504.nw.nos.boeing.com> <5D36713D8A4E7348A7E10DF7437A4B923AF0D823@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AF0D8AE@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AF0D8AE@nkgeml512-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/dxlqs-ilLdkst1_SxtyhwB-xC4w Cc: "jinmei@wide.ad.jp" Subject: Re: [dhcwg] Question on draft-ietf-dhc-sedhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 16:32:23 -0000 SGkgU2hlbmcsDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogU2hlbmcg SmlhbmcgW21haWx0bzpqaWFuZ3NoZW5nQGh1YXdlaS5jb21dDQo+IFNlbnQ6IFRodXJzZGF5LCBB dWd1c3QgMjEsIDIwMTQgMjoxNSBBTQ0KPiBUbzogU2hlbmcgSmlhbmc7IFRlbXBsaW4sIEZyZWQg TDsgZGhjd2dAaWV0Zi5vcmcNCj4gQ2M6IGppbm1laUB3aWRlLmFkLmpwDQo+IFN1YmplY3Q6IFJF OiBRdWVzdGlvbiBvbiBkcmFmdC1pZXRmLWRoYy1zZWRoY3B2Ng0KPiANCj4gSGksIEZyZWQsDQo+ IA0KPiBJdCBtYXkgYmUgaGVscGZ1bCBmb3IgdXMgdG8gcmUtZGVjaWRlIHdoZXRoZXIgd2Uga2Vl cCB0aGUgY2xpZW50IGF1dGhlbnRpY2F0aW9uIG9uIHNlcnZlciBpZiB5b3UgY291bGQNCj4gZGVz Y3JpYmUgeW91ciByZXF1aXJlIHNjZW5hcmlvIGluIGRldGFpbHMuIFRoZW4gd2UgY2FuIGV2YWx1 YXRlIHdoZXRoZXIgY2xpZW50IGF1dGhlbnRpY2F0aW9uIG9uDQo+IHNlcnZlciBiYXNlZCBvbiBM ZWFmIG9mIEZhaXRoIG1vZGVsIGNvdWxkIG1lZXQgeW91ciByZXF1aXJlbWVudHMsIG9yIGl0IGhh cyB0byBiZSBjZXJ0aWZpY2F0ZSB3aXRoDQo+IHRydXN0IGFuY2hvciBvbiBjbGllbnRzLg0KDQpN eSBzY2VuYXJpbyBpcyBzaW1pbGFyIHRvIHRoYXQgZGVzY3JpYmVkIGluIFNlY3Rpb24gMjEgb2Yg UkZDIDMzMTUNCndoZXJlIGl0IHNheXM6DQoNCiAgICJOZXR3b3JrIGFkbWluaXN0cmF0b3JzIG1h eSB3aXNoIHRvDQogICBjb25zdHJhaW4gdGhlIGFsbG9jYXRpb24gb2YgYWRkcmVzc2VzIHRvIGF1 dGhvcml6ZWQgaG9zdHMgdG8gYXZvaWQNCiAgIGRlbmlhbCBvZiBzZXJ2aWNlIGF0dGFja3MgaW4g Imhvc3RpbGUiIGVudmlyb25tZW50cyB3aGVyZSB0aGUgbmV0d29yaw0KICAgbWVkaXVtIGlzIG5v dCBwaHlzaWNhbGx5IHNlY3VyZWQsIHN1Y2ggYXMgd2lyZWxlc3MgbmV0d29ya3Mgb3INCiAgIGNv bGxlZ2UgcmVzaWRlbmNlIGhhbGxzLiINCg0KYnV0IG5vdCBxdWl0ZSBhcyBiYWQgYXMgdGhhdCBp biBhY3R1YWwgcHJhY3RpY2UgYmVjYXVzZSB0aGVyZQ0KaXMgYW4gZXN0YWJsaXNoZWQgdHJ1c3Qg YmFzaXMgZm9yIGhvc3RzIHRvIHRydXN0IHRoZSBESENQdjYNCnNlcnZlci4NCg0KVGhhbmtzIC0g RnJlZA0KZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbQ0KDQo+IFJlZ2FyZHMsDQo+IA0KPiBTaGVu Zw0KPiANCj4gPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID5Gcm9tOiBkaGN3ZyBbbWFp bHRvOmRoY3dnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTaGVuZyBKaWFuZw0KPiA+ U2VudDogVGh1cnNkYXksIEF1Z3VzdCAyMSwgMjAxNCA0OjMxIFBNDQo+ID5UbzogVGVtcGxpbiwg RnJlZCBMOyBkaGN3Z0BpZXRmLm9yZw0KPiA+Q2M6IGppbm1laUB3aWRlLmFkLmpwDQo+ID5TdWJq ZWN0OiBSZTogW2RoY3dnXSBRdWVzdGlvbiBvbiBkcmFmdC1pZXRmLWRoYy1zZWRoY3B2Ng0KPiA+ DQo+ID5IaSwgRnJlZCwNCj4gPg0KPiA+VGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLiBUaGUgY3Vy cmVudCBzdGF0dXMgaXMgdGhhdCB3ZSBwcm9iYWJseSB3b3VsZCBnZXQNCj4gPnJpZCBvZiB0aGUg Y2xpZW50IGF1dGhlbnRpY2F0aW9uIG9uIHNlcnZlciB0b3RhbGx5LCBnaXZlbiB0aGUgcHJldmlv dXMgY29tbWVudHMuDQo+ID5JdCBzZWVtcyB0aGUgY2xpZW50IGF1dGhlbnRpY2F0aW9uIG9uIHNl cnZlciBoYXMgbm8gbXVjaCB2YWx1ZSBhbmQgdGhlcmUgaXMNCj4gPmxvbmcgd2F5IHRvIGdvIHRv IHByb3Blcmx5IHNldHVwIGNlcnRpZmljYXRlIGFuZCB0cnVzdCBhbmNob3Igb24gY2xpZW50cy4g VGhlDQo+ID5uZXh0IHZlcnNpb24gcHJvYmFibHkgd2lsbCBoYXZlIG9uZSBzZXJ2ZXIgYXV0aGVu dGljYXRpb24gb24gY2xpZW50IGJhc2Ugb24NCj4gPkxlYWYgb2YgRmFpdGggbW9kZWwuIFN0aWxs LCBzb21lIHRlY2huaWNhbCByZXBsaWVzIGluIGxpbmVzLg0KPiA+DQo+ID4+SW4gdGhpcyBkcmFm dCwgU2VjdGlvbiA2LjIgc2F5czoNCj4gPj4NCj4gPj4iNi4yIFByb2Nlc3NpbmcgUnVsZXMgb2Yg YSBSZWNpcGllbnQNCj4gPj4NCj4gPj4gICBUaGUgcmVjaXBpZW50IG9mIGEgU2VjdXJlIERIQ1B2 NiBtZXNzYWdlIGNvdWxkIGJlIGEgREhDUHY2IHNlcnZlciBvcg0KPiA+PiAgIGEgREhDUHY2IGNs aWVudC4gIEluIHRoZSBmYWlsdXJlIGNhc2VzLCBib3RoIERIQ1B2NiBzZXJ2ZXIgYW5kIGNsaWVu dA0KPiA+PiAgIFNIT1VMRCBOT1QgcHJvY2VzcyByZWNlaXZlZCBtZXNzYWdlLCBhbmQgdGhlIHNl cnZlciBTSE9VTEQgcmVwbHkgYQ0KPiA+PiAgIGNvcnJlc3BvbmRlbnQgZXJyb3Igc3RhdHVzIGNv ZGUsIHdoaWxlIHRoZSBjbGllbnQgZG9lcyBub3RoaW5nLiINCj4gPj4NCj4gPj5CdXQsIG9uIGxp bmtzIHdoZXJlIHJvZ3VlIGNsaWVudHMgY291bGQgc3Bvb2YgdGhlIGlkZW50aXR5IG9mDQo+ID4+ bGVnaXRpbWF0ZSBjbGllbnRzLA0KPiA+DQo+ID5JZGVhbGx5LCB0aGUgaWRlbnRpdHkgb2YgbGVn aXRpbWF0ZSBjbGllbnRzIHNob3VsZCBub3QgYmUgYWJsZSB0byBiZSBzcG9vZmVkLiBJdCBpcw0K PiA+c2lnbmVkIGJ5IHRoZSBwcml2YXRlIGtleSBvZiBjbGllbnQuIFRoZSBzZXJ2ZXIgd291bGQg dmFsaWRhdGUgdGhlIHNpZ25hdHVyZQ0KPiA+Zmlyc3QuDQo+ID4NCj4gPj53aHkgc2hvdWxkIHRo ZSBzZXJ2ZXIgcmVwbHkgd2l0aCBhbiBlcnJvcg0KPiA+PnN0YXR1cyBjb2RlPyBJZiB0aGUgcm9n dWUgY2xpZW50IGdldHMgdGhlIGVycm9yIGNvZGUsIGl0IGtub3dzDQo+ID4+dGhhdCBpdHMgYXR0 YWNrIGhhcyBmYWlsZWQuIElmIHRoZSBsZWdpdGltYXRlIGNsaWVudCBnZXRzIHRoZQ0KPiA+PmVy cm9yIGNvZGUsIGl0IHdpbGwgYmUgY29uZnVzZWQgc2luY2UgaXQgaGFzbid0IHNlbnQgYW55dGhp bmcNCj4gPj50aGF0IHdvdWxkIGdlbmVyYXRlIGFuIGVycm9yLg0KPiA+DQo+ID5UaGUgbWFuZGF0 b3J5IHJlc3BvbnNlIGlzIHRoZSByZXN1bHQgb2YgREhDIFdHIGRpc2N1c3Npb24uIElmIHRoZSBh Ym92ZQ0KPiA+YXNzdW1wdGlvbiAodGhlIGlkZW50aXR5IG9mIGxlZ2l0aW1hdGUgY2xpZW50cyBj b3VsZCBub3QgYmUgc3Bvb2ZlZCkgc3RhbmRzLA0KPiA+dGhlIGVycm9yIGNvZGUgd291bGQgb25s eSBiZSByZXBsaWVkIHRvIHRoZSBsZWdpdGltYXRlIGNsaWVudCB3aG8gc2VuZA0KPiA+cmVxdWVz dC4NCj4gPg0KPiA+QmVzdCByZWdhcmRzLA0KPiA+DQo+ID5TaGVuZw0KPiA+DQo+ID4+U28sIHdo eSBpc24ndCBpdCB0aGUgY2FzZSB0aGF0IHRoZSBzZXJ2ZXIgc2hvdWxkIGRvIG5vdGhpbmcgdGhl DQo+ID4+c2FtZSBhcyBmb3IgY2xpZW50cz8gT3IsIGF0IGxlYXN0IG1heWJlIHRoZXJlIGNvdWxk IGJlIGENCj4gPj5jb25maWd1cmF0aW9uIHNldHRpbmcgdGhlIGFsbG93cyBzZXJ2ZXJzIHRvIGln bm9yZSBmYWlsdXJlIGNhc2VzDQo+ID4+aW5zdGVhZCBvZiByZXNwb25kIHRvIHRoZW0/DQo+ID4+ DQo+ID4+VGhhbmtzIC0gRnJlZA0KPiA+PmZyZWQubC50ZW1wbGluQGJvZWluZy5jb20NCj4gPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID5kaGN3ZyBt YWlsaW5nIGxpc3QNCj4gPmRoY3dnQGlldGYub3JnDQo+ID5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2RoY3dnDQo= From nobody Thu Aug 21 09:39:15 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8C21A04AA for ; Thu, 21 Aug 2014 09:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham 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 BLYmwSZrVD05 for ; Thu, 21 Aug 2014 09:39:09 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 950501A0380 for ; Thu, 21 Aug 2014 09:39:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s7LGd84Y000349; Thu, 21 Aug 2014 11:39:08 -0500 Received: from XCH-BLV-506.nw.nos.boeing.com (xch-blv-506.nw.nos.boeing.com [130.247.25.196]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s7LGd0og032675 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 21 Aug 2014 11:39:01 -0500 Received: from XCH-BLV-406.nw.nos.boeing.com (2002:82f7:19a2::82f7:19a2) by XCH-BLV-506.nw.nos.boeing.com (2002:82f7:19c4::82f7:19c4) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 21 Aug 2014 09:39:00 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.6]) by XCH-BLV-406.nw.nos.boeing.com ([169.254.6.97]) with mapi id 14.03.0181.006; Thu, 21 Aug 2014 09:38:59 -0700 From: "Templin, Fred L" To: "Francis.Dupont@fdupont.fr" Thread-Topic: [dhcwg] DHCPv6 Client Authentication question Thread-Index: AQHPvMCMclnAxOs0DkSEtD7AO8bV9JvbQLgg Date: Thu, 21 Aug 2014 16:38:59 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CF7BBD@XCH-BLV-504.nw.nos.boeing.com> References: Your message of Wed, 20 Aug 2014 21:48:59 -0000. <2134F8430051B64F815C691A62D9831832CF618A@XCH-BLV-504.nw.nos.boeing.com> <201408211436.s7LEaQYa037662@givry.fdupont.fr> In-Reply-To: <201408211436.s7LEaQYa037662@givry.fdupont.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/Dc3_k_uWTn64viCgE1tjjaCXNxE Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] DHCPv6 Client Authentication question X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 16:39:14 -0000 Hi Francis, Thanks for your responses. I have a case where securing IPv6 ND and DHCPv6 is made a bit easier because IPv6 hosts have a trust basis for trusting their default routers and DHCPv6 clients have a trust basis for trusting their DHCPv6 servers. IPv6 nodes can then come to trust one another by leveraging these shared trust anchors. With this in mind, I feel I may need just a bit more additional security which I think can be provided by DHCPv6 auth as long as it is widely implemented and known to work. Can implementers who watch this list comment? Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > Sent: Thursday, August 21, 2014 7:36 AM > To: Templin, Fred L > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] DHCPv6 Client Authentication question >=20 > In your previous mail you wrote: >=20 > > Is it just me, or are the RFC3315 DHCPv6 authentication mechanisms > > a bit sketchy? >=20 > =3D> my recommendation as a multiple implementor of DHCPv6 was (and still > is) to explain to someone who ask for support of this what this really > does. Note I've never seen such request to go further... >=20 > > Is anyone using them in actual practice? >=20 > =3D> I've heart it is supported and used so someone found an use case. > I suggest to look for a DHCPv6 implementation with support of this, > and to ask implementors (or to wait as they should be in this list :-). >=20 > Regards >=20 > Francis.Dupont@fdupont.fr >=20 > PS: securing ND or DHCPv6 is a very hard problem. We have a solution > for ND (SeND) so we should get one for DHCPv6. Unfortunately it will > likely share SeND complexity, deployment costs and lack of public > market (public =3D=3D not military or similar). > For your application, the cost of the current secure DHCPv6 proposal > comes mainly from the intra-exchange constraint (vs inter-exchange, > think about DTLS for instance where security contexts spend over > far more than one packet). From nobody Thu Aug 21 09:56:04 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF521A0453 for ; Thu, 21 Aug 2014 09:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 wQXWX8sjy151 for ; Thu, 21 Aug 2014 09:56:02 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEDE61A024C for ; Thu, 21 Aug 2014 09:56:01 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id n3so9023010wiv.11 for ; Thu, 21 Aug 2014 09:56:00 -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:date:message-id:subject :from:to:cc:content-type; bh=obFov1BfRaxgjPDHxjy8t8BKAF1PZxPaVwuO//N1u3Q=; b=sZ1AJd2qohYh8y/2wsG1yiQekO/mzJmgimF4TR6acZN1H3ZyLBHStaQCquw8sPkXen bF0je7fvPltxVmj0gbonCOTILmsOEtgd3cETTYW0s6YjaQ9lAfJYTN4yibRZG8CqWo1V FujxMJE1fEUWSOj46Ym1ymKw+7MpxxY69qxnRlgRzcTUgtgz8m2yQor3t/VyMq0pflgw Q/19wtH32QcHVAeaHc0ceFe3Oyd1UNL2DrtkIBN9plaI9m+vRUp0LkuU1T/5Yxkp7soF O7q67lkKQGfJdyWYfW+LGjtq8a7++TzHG8QU/o8O0WiqamWdH8YsKto3HDrkOxe5S3WQ G/Fg== MIME-Version: 1.0 X-Received: by 10.180.75.49 with SMTP id z17mr5487458wiv.80.1408640160221; Thu, 21 Aug 2014 09:56:00 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.123.164 with HTTP; Thu, 21 Aug 2014 09:56:00 -0700 (PDT) In-Reply-To: <2134F8430051B64F815C691A62D9831832CF7B7B@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832CF60F1@XCH-BLV-504.nw.nos.boeing.com> <5D36713D8A4E7348A7E10DF7437A4B923AF0D823@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AF0D8AE@nkgeml512-mbx.china.huawei.com> <2134F8430051B64F815C691A62D9831832CF7B7B@XCH-BLV-504.nw.nos.boeing.com> Date: Thu, 21 Aug 2014 09:56:00 -0700 X-Google-Sender-Auth: OnAzz1BKd-sUm1aHVB2GPXMp5TM Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: "Templin, Fred L" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/-aQT1HZaPj-txguEbwpXJt1O4sc Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Question on draft-ietf-dhc-sedhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 16:56:03 -0000 At Thu, 21 Aug 2014 16:32:15 +0000, "Templin, Fred L" wrote: > > It may be helpful for us to re-decide whether we keep the client authentication on server if you could > > describe your require scenario in details. Then we can evaluate whether client authentication on > > server based on Leaf of Faith model could meet your requirements, or it has to be certificate with > > trust anchor on clients. > > My scenario is similar to that described in Section 21 of RFC 3315 > where it says: > > "Network administrators may wish to > constrain the allocation of addresses to authorized hosts to avoid > denial of service attacks in "hostile" environments where the network > medium is not physically secured, such as wireless networks or > college residence halls." > > but not quite as bad as that in actual practice because there > is an established trust basis for hosts to trust the DHCPv6 > server. I wasn't in Toronto (or didn't attend the meeting remotely), but there seems to be some background discussion on this topic in the meeting minutes: http://tools.ietf.org/wg/dhc/minutes?item=minutes-90-dhc.html In particular: Ted: server authorize client is also useful, though not very clear Lorenzo: l2 security may be enough and better -- JINMEI, Tatuya From nobody Thu Aug 21 10:45:00 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 500EB1A0AF5 for ; Thu, 21 Aug 2014 10:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.668] autolearn=ham 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 gu_5g7683gHJ for ; Thu, 21 Aug 2014 10:44:58 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 426A31A0AE7 for ; Thu, 21 Aug 2014 10:44:58 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 0B2D01B85E2 for ; Thu, 21 Aug 2014 10:44:58 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id EBEBA53E070; Thu, 21 Aug 2014 10:44:52 -0700 (PDT) Received: from [10.0.10.40] (71.233.43.215) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 21 Aug 2014 10:44:53 -0700 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Thu, 21 Aug 2014 13:44:07 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <6135018F-8DF0-490E-BBD8-AA5B7F708D43@nominum.com> References: <2134F8430051B64F815C691A62D9831832CF60F1@XCH-BLV-504.nw.nos.boeing.com> <5D36713D8A4E7348A7E10DF7437A4B923AF0D823@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AF0D8AE@nkgeml512-mbx.china.huawei.com> <2134F8430051B64F815C691A62D9831832CF7B7B@XCH-BLV-504.nw.nos.boeing.com> To: =?utf-8?B?56We5piO6YGU5ZOJ?= X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/m1-ILmC623sSFvtukTmaWIRDOpc Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Question on draft-ietf-dhc-sedhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 17:44:59 -0000 On Aug 21, 2014, at 12:56 PM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = wrote: > Ted: server authorize client is also useful, though not very clear > Lorenzo: l2 security may be enough and better As I said later, though, on the mailing list, there are in fact use = cases where l2 security doesn't really work, and I think sedhcpv6 would = be applicable. From nobody Thu Aug 21 10:48:59 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 040861A0B04 for ; Thu, 21 Aug 2014 10:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.569 X-Spam-Level: X-Spam-Status: No, score=-4.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham 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 MyZPdFwFn6dv for ; Thu, 21 Aug 2014 10:48:55 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5F941A0AF5 for ; Thu, 21 Aug 2014 10:48:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s7LHmsj5001246; Thu, 21 Aug 2014 10:48:55 -0700 Received: from XCH-PHX-310.sw.nos.boeing.com (xch-phx-310.sw.nos.boeing.com [130.247.25.169]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s7LHmmpO001150 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 21 Aug 2014 10:48:48 -0700 Received: from XCH-BLV-203.nw.nos.boeing.com (10.57.37.65) by XCH-PHX-310.sw.nos.boeing.com (130.247.25.169) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 21 Aug 2014 10:48:47 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.6]) by XCH-BLV-203.nw.nos.boeing.com ([169.254.3.44]) with mapi id 14.03.0181.006; Thu, 21 Aug 2014 10:48:47 -0700 From: "Templin, Fred L" To: Ted Lemon , =?utf-8?B?56We5piO6YGU5ZOJ?= Thread-Topic: [dhcwg] Question on draft-ietf-dhc-sedhcpv6 Thread-Index: Ac+8usvtlThiaS7BTzagQmSX8ZEBQgAXZQCAAAHcdkAADwAdYAAC8/BlAAAdlDA= Date: Thu, 21 Aug 2014 17:48:47 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CF7D05@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832CF60F1@XCH-BLV-504.nw.nos.boeing.com> <5D36713D8A4E7348A7E10DF7437A4B923AF0D823@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AF0D8AE@nkgeml512-mbx.china.huawei.com> <2134F8430051B64F815C691A62D9831832CF7B7B@XCH-BLV-504.nw.nos.boeing.com> <6135018F-8DF0-490E-BBD8-AA5B7F708D43@nominum.com> In-Reply-To: <6135018F-8DF0-490E-BBD8-AA5B7F708D43@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/EVUJ1yHKSYGwNEZrTXtlpQwruio Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Question on draft-ietf-dhc-sedhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 17:48:57 -0000 KzENCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBUZWQgTGVtb24gW21h aWx0bzpUZWQuTGVtb25Abm9taW51bS5jb21dDQo+IFNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMjEs IDIwMTQgMTA6NDQgQU0NCj4gVG86IOelnuaYjumBlOWTiQ0KPiBDYzogVGVtcGxpbiwgRnJlZCBM OyBkaGN3Z0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW2RoY3dnXSBRdWVzdGlvbiBvbiBkcmFm dC1pZXRmLWRoYy1zZWRoY3B2Ng0KPiANCj4gT24gQXVnIDIxLCAyMDE0LCBhdCAxMjo1NiBQTSwg 56We5piO6YGU5ZOJIDxqaW5tZWlAd2lkZS5hZC5qcD4gd3JvdGU6DQo+ID4gIFRlZDogc2VydmVy IGF1dGhvcml6ZSBjbGllbnQgaXMgYWxzbyB1c2VmdWwsIHRob3VnaCBub3QgdmVyeSBjbGVhcg0K PiA+ICBMb3JlbnpvOiBsMiBzZWN1cml0eSBtYXkgYmUgZW5vdWdoIGFuZCBiZXR0ZXINCj4gDQo+ IEFzIEkgc2FpZCBsYXRlciwgdGhvdWdoLCBvbiB0aGUgbWFpbGluZyBsaXN0LCB0aGVyZSBhcmUg aW4gZmFjdCB1c2UgY2FzZXMgd2hlcmUgbDIgc2VjdXJpdHkgZG9lc24ndA0KPiByZWFsbHkgd29y aywgYW5kIEkgdGhpbmsgc2VkaGNwdjYgd291bGQgYmUgYXBwbGljYWJsZS4NCg0K From nobody Thu Aug 21 10:51:11 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0872F1A6F25 for ; Thu, 21 Aug 2014 10:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 kU1LKQBPxff1 for ; Thu, 21 Aug 2014 10:51:09 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A23EA1A0B04 for ; Thu, 21 Aug 2014 10:51:08 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id ho1so9074428wib.14 for ; Thu, 21 Aug 2014 10:51:07 -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:date:message-id:subject :from:to:cc:content-type; bh=XOc6835RLG9/pZPyKxNKXs9GV/IXHYR4z9XSYMiXhOs=; b=AGTTcZPPP2o8k/OvgNQ7+1t7tTKmyV4L6pj0x6dg2cdvk7NceSBRVM3hpBo2mDAUoF LdH441wgq06QmGTCtRz1LOFReX1g5zm1ArOgyawDjauEMtQCRcPhsIrXRRE7pOfQ8uOF PpAmbf5sFY9Jh+3Rz2ptrvRJww/0sQZl3cilr7tJCd1THSiFr5FuNL9iTswH0DdDDZ79 g84MvmW3/mGbvhdPjBv3tMmJYW5AH2lPJQUquX2v6hbh84Chw5AawNvGEEYHUABPG/Dn RdXltCRr9W8Qkdx1bE3NvxSXGojAqIMEI6/TSynFLgbUEpYy13I/9WoQEaVSEF3cbeRt jUXQ== MIME-Version: 1.0 X-Received: by 10.180.75.49 with SMTP id z17mr5730035wiv.80.1408643467223; Thu, 21 Aug 2014 10:51:07 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.123.164 with HTTP; Thu, 21 Aug 2014 10:51:07 -0700 (PDT) In-Reply-To: <2134F8430051B64F815C691A62D9831832CF7BBD@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832CF618A@XCH-BLV-504.nw.nos.boeing.com> <201408211436.s7LEaQYa037662@givry.fdupont.fr> <2134F8430051B64F815C691A62D9831832CF7BBD@XCH-BLV-504.nw.nos.boeing.com> Date: Thu, 21 Aug 2014 10:51:07 -0700 X-Google-Sender-Auth: Ta6sBfo5nFa_y7-Ta1Q5kM2dEuE Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: "Templin, Fred L" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/T5ou5N2uPDfpIEMHFZySLNQJ2sU Cc: "dhcwg@ietf.org" , "Francis.Dupont@fdupont.fr" Subject: Re: [dhcwg] DHCPv6 Client Authentication question X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 17:51:10 -0000 At Thu, 21 Aug 2014 16:38:59 +0000, "Templin, Fred L" wrote: > With this in mind, I feel I may need just a bit more additional > security which I think can be provided by DHCPv6 auth as long as > it is widely implemented and known to work. Can implementers who > watch this list comment? Is this about the DHCPv6 authentication defined in RFC3315 or the one defined in draft-ietf-dhc-sedhcpv6-03? And comment on what? About whether it's widely implemented and known to work? At least for dhc-sedhcpv6 I don't know of any implementation. I know there are several different implementations of the original DHCPv6 authentication. For example, the WIDE-DHCPv6 server and client implementation (http://sourceforge.net/projects/wide-dhcpv6/) supports the delayed authentication protocol. There were even interoperability tests among different implementations (many years ago, if my memory serves correctly), so to that extent they are "known to work". But I don't know of any production level deployment of the protocol; I actually suspect there's none. -- JINMEI, Tatuya From nobody Thu Aug 21 10:56:27 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 916C21A0707 for ; Thu, 21 Aug 2014 10:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.569 X-Spam-Level: X-Spam-Status: No, score=-4.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham 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 CyzHGzp0D4kU for ; Thu, 21 Aug 2014 10:56:25 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 404B51A0703 for ; Thu, 21 Aug 2014 10:56:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s7LHuOv8005968; Thu, 21 Aug 2014 12:56:24 -0500 Received: from XCH-PHX-413.sw.nos.boeing.com (xch-phx-413.sw.nos.boeing.com [10.57.37.45]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s7LHuGUW005658 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 21 Aug 2014 12:56:16 -0500 Received: from XCH-BLV-302.nw.nos.boeing.com (130.247.25.214) by XCH-PHX-413.sw.nos.boeing.com (10.57.37.45) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 21 Aug 2014 10:56:15 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.6]) by XCH-BLV-302.nw.nos.boeing.com ([169.254.2.209]) with mapi id 14.03.0181.006; Thu, 21 Aug 2014 10:56:15 -0700 From: "Templin, Fred L" To: =?utf-8?B?56We5piO6YGU5ZOJ?= Thread-Topic: [dhcwg] DHCPv6 Client Authentication question Thread-Index: AQHPvWh/U6a+JoYMSUmovPHUbI4aP5vbVoQA Date: Thu, 21 Aug 2014 17:56:14 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CF7D44@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832CF618A@XCH-BLV-504.nw.nos.boeing.com> <201408211436.s7LEaQYa037662@givry.fdupont.fr> <2134F8430051B64F815C691A62D9831832CF7BBD@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/mplynBtAKVY1io4K8f1uzjWaVF4 Cc: "dhcwg@ietf.org" , "Francis.Dupont@fdupont.fr" Subject: Re: [dhcwg] DHCPv6 Client Authentication question X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 17:56:26 -0000 SGksDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogamlubWVpLnRhdHV5 YUBnbWFpbC5jb20gW21haWx0bzpqaW5tZWkudGF0dXlhQGdtYWlsLmNvbV0gT24gQmVoYWxmIE9m ID8/Pz8NCj4gU2VudDogVGh1cnNkYXksIEF1Z3VzdCAyMSwgMjAxNCAxMDo1MSBBTQ0KPiBUbzog VGVtcGxpbiwgRnJlZCBMDQo+IENjOiBGcmFuY2lzLkR1cG9udEBmZHVwb250LmZyOyBkaGN3Z0Bp ZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW2RoY3dnXSBESENQdjYgQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIHF1ZXN0aW9uDQo+IA0KPiBBdCBUaHUsIDIxIEF1ZyAyMDE0IDE2OjM4OjU5ICswMDAwLA0K PiAiVGVtcGxpbiwgRnJlZCBMIiA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4gd3JvdGU6DQo+ IA0KPiA+IFdpdGggdGhpcyBpbiBtaW5kLCBJIGZlZWwgSSBtYXkgbmVlZCBqdXN0IGEgYml0IG1v cmUgYWRkaXRpb25hbA0KPiA+IHNlY3VyaXR5IHdoaWNoIEkgdGhpbmsgY2FuIGJlIHByb3ZpZGVk IGJ5IERIQ1B2NiBhdXRoIGFzIGxvbmcgYXMNCj4gPiBpdCBpcyB3aWRlbHkgaW1wbGVtZW50ZWQg YW5kIGtub3duIHRvIHdvcmsuIENhbiBpbXBsZW1lbnRlcnMgd2hvDQo+ID4gd2F0Y2ggdGhpcyBs aXN0IGNvbW1lbnQ/DQo+IA0KPiBJcyB0aGlzIGFib3V0IHRoZSBESENQdjYgYXV0aGVudGljYXRp b24gZGVmaW5lZCBpbiBSRkMzMzE1IG9yIHRoZSBvbmUNCj4gZGVmaW5lZCBpbiBkcmFmdC1pZXRm LWRoYy1zZWRoY3B2Ni0wMz8gIEFuZCBjb21tZW50IG9uIHdoYXQ/ICBBYm91dA0KPiB3aGV0aGVy IGl0J3Mgd2lkZWx5IGltcGxlbWVudGVkIGFuZCBrbm93biB0byB3b3JrPw0KPiANCj4gQXQgbGVh c3QgZm9yIGRoYy1zZWRoY3B2NiBJIGRvbid0IGtub3cgb2YgYW55IGltcGxlbWVudGF0aW9uLg0K PiANCj4gSSBrbm93IHRoZXJlIGFyZSBzZXZlcmFsIGRpZmZlcmVudCBpbXBsZW1lbnRhdGlvbnMg b2YgdGhlIG9yaWdpbmFsDQo+IERIQ1B2NiBhdXRoZW50aWNhdGlvbi4gIEZvciBleGFtcGxlLCB0 aGUgV0lERS1ESENQdjYgc2VydmVyIGFuZCBjbGllbnQNCj4gaW1wbGVtZW50YXRpb24gKGh0dHA6 Ly9zb3VyY2Vmb3JnZS5uZXQvcHJvamVjdHMvd2lkZS1kaGNwdjYvKSBzdXBwb3J0cw0KPiB0aGUg ZGVsYXllZCBhdXRoZW50aWNhdGlvbiBwcm90b2NvbC4gIFRoZXJlIHdlcmUgZXZlbiBpbnRlcm9w ZXJhYmlsaXR5DQo+IHRlc3RzIGFtb25nIGRpZmZlcmVudCBpbXBsZW1lbnRhdGlvbnMgKG1hbnkg eWVhcnMgYWdvLCBpZiBteSBtZW1vcnkNCj4gc2VydmVzIGNvcnJlY3RseSksIHNvIHRvIHRoYXQN Cj4gZXh0ZW50IHRoZXkgYXJlICJrbm93biB0byB3b3JrIi4gIEJ1dCBJIGRvbid0IGtub3cgb2Yg YW55IHByb2R1Y3Rpb24NCj4gbGV2ZWwgZGVwbG95bWVudCBvZiB0aGUgcHJvdG9jb2w7IEkgYWN0 dWFsbHkgc3VzcGVjdCB0aGVyZSdzIG5vbmUuDQoNClRoaXMgaXMgdmVyeSBoZWxwZnVsIGlucHV0 LCBhbmQgYW5zd2VycyBtYW55IG9mIG15IHF1ZXN0aW9ucyBpbg0KYSBzaW5nbGUgcGFzcy4NCg0K SWYgYW55b25lIGVsc2Uga25vd3Mgb2YgcHJvZHVjdGlvbiBkZXBsb3ltZW50IG9mIFJGQzMzMTUg REhDUA0KYXV0aCBJIHdvdWxkIGFwcHJlY2lhdGUgaGVhcmluZyBhYm91dCBpdC4NCg0KVGhhbmtz IC0gRnJlZA0KZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbQ0KIA0KPiAtLQ0KPiBKSU5NRUksIFRh dHV5YQ0K From nobody Thu Aug 21 11:18:15 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC4281A049A for ; Thu, 21 Aug 2014 11:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 yR7xS25cTfu5 for ; Thu, 21 Aug 2014 11:18:11 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35EAE1A048E for ; Thu, 21 Aug 2014 11:18:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8489; q=dns/txt; s=iport; t=1408645091; x=1409854691; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=xV5MkDBG6/XqOF0Ee2He0iJJV6KlrB4faIZ+ooZosao=; b=P42aZ0jpO2nBYplCUNBgis7eaiT5kAkce6G+uLhbR/3jleKX12d759KF IVm/3Ic8LL1Tzy3/MQWXWDFqByImIoNdIRN2TWdV6myrRuKj4bNlPEbCN 83groUGGQ/kgD1hVzq2Gewjh7kCemoexcsCK1ZVJgwCESYBVU4vVJll2m 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFADE39lOtJV2c/2dsb2JhbABZgw1TVwTMRQqHTgGBDxZ3hAMBAQEEAQEBNzQLDAQCAQgRAQMBAQEKFAkHIQYLFAMGCAIEAQ0FCBOIEwMRDb4YDYUZEwSMHYECgXwGKwcCBIMpgR0BBJElhmOCMJBkhjWDXmwBgUeBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,374,1406592000"; d="scan'208";a="349277217" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 21 Aug 2014 18:18:10 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s7LIIAhh031310 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Aug 2014 18:18:10 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.173]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Thu, 21 Aug 2014 13:18:09 -0500 From: "Bernie Volz (volz)" To: "Templin, Fred L" , Ralph Droms Thread-Topic: [dhcwg] RFC3315(bis) comment Thread-Index: AQHPszc8KUdUb080f0+HHlHHQ0+hpZvHk4OA//+0FvCAAV3fgIAC46EggA/nDJA= Date: Thu, 21 Aug 2014 18:18:08 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1B66487C@xmb-rcd-x04.cisco.com> References: <2134F8430051B64F815C691A62D9831832CECA61@XCH-BLV-504.nw.nos.boeing.com> <83E91E35-3F30-4659-B4AE-58DD11E74DB6@nominum.com> <2134F8430051B64F815C691A62D9831832CECB68@XCH-BLV-504.nw.nos.boeing.com> <075FB3EE-EA09-4CBD-AFE9-CF14E77ED007@nominum.com> <2134F8430051B64F815C691A62D9831832CECBF5@XCH-BLV-504.nw.nos.boeing.com> <9C369D15-88ED-4E1E-8138-A538760C6FDE@nominum.com> <2134F8430051B64F815C691A62D9831832CECC7B@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CECD1A@XCH-BLV-504.nw.nos.boeing.com> <35F4F6CF-7CBC-4935-9E9F-2EC946D7EBB7@nominum.com> <2134F8430051B64F815C691A62D9831832CED2CD@XCH-BLV-504.nw.nos.boeing.com> <65C2A9BF-B153-4BD0-89EF-6D7D8FE459B3@nominum.com> <2134F8430051B64F815C691A62D9831832CED559@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CED5E7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CED674@XCH-BLV-504.nw.nos.boeing.com> <3B43E4B9-8658-48CF-9A3A-C4DC7560ABFF@nominum.com> <2134F8430051B64F815C691A62D9831832CED77A@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CED7FF@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CED9D3@XCH-BLV-504.nw.nos.boeing.com> <9E184648-12AC-4B38-8B51-6B384EA441A4@gmail.com> <2134F8430051B64F815C691A62D9831832CEE7A3@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832CEE7A3@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.253.142] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/8XwujDK9CGa_I_61nQEbuGKkNv4 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] RFC3315(bis) comment X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 18:18:14 -0000 Of course, there could also be some communication between relays in a multi= ple relay situation where gleaning was being used and in that case this res= triction would not apply.=20 But perhaps best we ignore that. And, there's interesting issues about timi= ng in some cases with that kind of design. I think we worked on addressing = some of the timing issues in RAAN by including a sequence number scheme for= server generated messages so relays could tell the order. - Bernie -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Templin, Fred L Sent: Monday, August 11, 2014 11:46 AM To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] RFC3315(bis) comment Hi Ralph, OK, if I understand you correctly then maybe what would work would be 1-2 p= aragraphs added to RFC3315(bis) to discuss the practice of relay agent glea= ning. So, maybe add a new Section 20.1.4 something to the effect of: "20.1.4 Relay Agent Gleaning In operational practice, relay agents are often configured to examine address and prefix information contained in client-server transactions, e.g., for the purpose of injecting and withdrawing information in the routing system. This practice (sometimes known as "gleaning") has known operational limitations. In particular, relay agents SHOULD NOT perform gleaning unless there is operational assurance that the path from the client to server will will always travel through the same agent, and that no transaction reordering will occur. Furthermore, relay agents SHOULD NOT perform gleaning based solely on the client's requests to the server since the messages may be rejected, e.g., due to authentication failure. If any gleaning is to be done, it should therefore be based on the server's replies to the client." You also asked about a use case for informing the client of the success of = the release. My AERO proposal is one such use case, but certainly not the o= nly one. In general, in any environment in which a client's request to the = server is subject to authentication, the relay agent should only perform gl= eaning on the server's reply to the client. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: Ralph Droms [mailto:rdroms.ietf@gmail.com] > Sent: Saturday, August 09, 2014 5:13 AM > To: Templin, Fred L > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] RFC3315(bis) comment >=20 >=20 >=20 > > On Aug 8, 2014, at 6:39 PM, "Templin, Fred L" wrote: > > > > Hi Ralph, > > > >> -----Original Message----- > >> From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ralph=20 > >> Droms > >> Sent: Friday, August 08, 2014 12:53 PM > >> To: dhcwg@ietf.org > >> Subject: Re: [dhcwg] RFC3315(bis) comment > >> > >> I think the text needs a full disclosure warning to the effect that=20 > >> there is no guarantee that the Release-Reply transaction will traverse= the same relay agent as other transactions. > > > > I think I understand the point, but this would not harm any relays=20 > > that were not on the original {Solicit/Request}-Reply path; they=20 > > would simply see that the client's IAs have been released regardless=20 > > of which relay they were initially established through. I think the=20 > > more dangerous case is for relays that would glean information from=20 > > the initial {Solicit/Request}-reply path; unless the relay has some=20 > > way of knowing that any subsequent Release would come through itself=20 > > and not through a different relay it cannot safely do the gleaning. >=20 > More generally, the technique of transporting the RAAN option or=20 > extending the Reply message to enable gleaning - in my opinion, the=20 > two are equivalent for managing state in relay agents - was considered=20 > to be the wrong architecture for managing state in relay agents. As=20 > you point out, there is no guarantee that subsequent transactions will=20 > be forwarded by the relevant relay agent. The messages may not be delive= red in the correct order. Finally, there may not be a client-server transa= ction available when the relay agent state needs to be updated. >=20 > > But, there is no > > warning label in the spec about that. >=20 > My suggestion is to add such a warning label to this option, if it is=20 > intended to enable gleaning/snooping. >=20 > > > > The information I am suggesting in my proposed text would also=20 > > provide potentially useful information to the client in the form of=20 > > a positive confirmation of the release of individual IAs independent=20 > > of what any relays might do. So, other documents that suggest relay=20 > > gleaning would be the place to explain the circumstances under which=20 > > gleaning can be applied. >=20 > Do you have an explicit use case for informing the client of the success = of the release? >=20 > > > > All of that said, do we really want to fully examine relay gleaning=20 > > in both the forward and reverse paths in the RFC3315(bis) base spec? > > I hope not, but maybe that is what you were thinking? >=20 > Relay gleaning is, to my mind, sort of a bad idea but it seems to be=20 > popular and the solution of choice in certain situations. Note that I=20 > am speaking strictly from an architecture point of view; those operating = DHCP services may have a different opinion. >=20 > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > >> - Ralph > >> > >>> On Aug 8, 2014, at 2:33 PM 8/8/14, Templin, Fred L wrote: > >>> > >>> Hello, > >>> > >>> In Section 18.2.6 of 'draft-dhcwg-dhc-rfc3315bis-02.txt' the next=20 > >>> to last paragraph of the section currently states: > >>> > >>> "After all the addresses have been processed, the server=20 > >>> generates a Reply message and includes a Status Code option with=20 > >>> value Success, a Server Identifier option with the server's DUID,=20 > >>> and a Client Identifier option with the client's DUID. For each=20 > >>> IA in the Release message for which the server has no binding=20 > >>> information, the server adds an IA option using the IAID from the=20 > >>> Release message, and includes a Status Code option with the value=20 > >>> NoBinding in the IA option. No other options are included in the IA= option." > >>> > >>> According to this specification, the server does not include any=20 > >>> information about IAs that were successfully released in the=20 > >>> transaction. Therefore, relays that need to "glean" client-server=20 > >>> transactions will have no way of knowing that the Release was=20 > >>> successfully executed by the server. > >>> > >>> A proposed resolution is to add an additional specification to=20 > >>> this paragraph as follows: > >>> > >>> "After all the addresses have been processed, the server=20 > >>> generates a Reply message and includes a Status Code option with=20 > >>> value Success, a Server Identifier option with the server's DUID,=20 > >>> and a Client Identifier option with the client's DUID. For each=20 > >>> IA in the Release message for which the server has released=20 > >>> binding information, the server adds an IA option using the IAID=20 > >>> from the Release message with both preferred-lifetime and=20 > >>> valid-lifetime set to 0 in the IA Address/Prefix option, and=20 > >>> includes a Status Code option with the value Success in the IA=20 > >>> option. For each IA in the Release message for which the server=20 > >>> has no binding information, the server adds an IA option using=20 > >>> the IAID from the Release message, and includes a Status Code=20 > >>> option with the value NoBinding in the IA option. No other options = are included in the IA option." > >>> > >>> Comments? Questions? > >>> > >>> Thanks - Fred > >>> fred.l.templin@boeing.com > >>> > >>> _______________________________________________ > >>> dhcwg mailing list > >>> dhcwg@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dhcwg > >> > >> _______________________________________________ > >> dhcwg mailing list > >> dhcwg@ietf.org > >> https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From nobody Thu Aug 21 12:52:37 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6AF1A8737 for ; Thu, 21 Aug 2014 12:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham 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 hCr5K4vhvR6q for ; Thu, 21 Aug 2014 12:52:32 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71DE21A86F2 for ; Thu, 21 Aug 2014 12:52:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s7LJqWEY023646; Thu, 21 Aug 2014 12:52:32 -0700 Received: from XCH-PHX-410.sw.nos.boeing.com (xch-phx-410.sw.nos.boeing.com [10.57.37.41]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s7LJqLX9023537 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 21 Aug 2014 12:52:21 -0700 Received: from XCH-BLV-305.nw.nos.boeing.com (130.247.25.217) by XCH-PHX-410.sw.nos.boeing.com (10.57.37.41) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 21 Aug 2014 12:52:20 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.6]) by XCH-BLV-305.nw.nos.boeing.com ([169.254.5.203]) with mapi id 14.03.0181.006; Thu, 21 Aug 2014 12:52:20 -0700 From: "Templin, Fred L" To: "Bernie Volz (volz)" , Ralph Droms Thread-Topic: [dhcwg] RFC3315(bis) comment Thread-Index: AQHPszc8KUdUb080f0+HHlHHQ0+hpZvHk4OA//+0FvCAAV3fgIAC46EggA/nDJCAABrXMA== Date: Thu, 21 Aug 2014 19:52:20 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CF7EB8@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832CECA61@XCH-BLV-504.nw.nos.boeing.com> <83E91E35-3F30-4659-B4AE-58DD11E74DB6@nominum.com> <2134F8430051B64F815C691A62D9831832CECB68@XCH-BLV-504.nw.nos.boeing.com> <075FB3EE-EA09-4CBD-AFE9-CF14E77ED007@nominum.com> <2134F8430051B64F815C691A62D9831832CECBF5@XCH-BLV-504.nw.nos.boeing.com> <9C369D15-88ED-4E1E-8138-A538760C6FDE@nominum.com> <2134F8430051B64F815C691A62D9831832CECC7B@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CECD1A@XCH-BLV-504.nw.nos.boeing.com> <35F4F6CF-7CBC-4935-9E9F-2EC946D7EBB7@nominum.com> <2134F8430051B64F815C691A62D9831832CED2CD@XCH-BLV-504.nw.nos.boeing.com> <65C2A9BF-B153-4BD0-89EF-6D7D8FE459B3@nominum.com> <2134F8430051B64F815C691A62D9831832CED559@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CED5E7@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CED674@XCH-BLV-504.nw.nos.boeing.com> <3B43E4B9-8658-48CF-9A3A-C4DC7560ABFF@nominum.com> <2134F8430051B64F815C691A62D9831832CED77A@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CED7FF@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CED9D3@XCH-BLV-504.nw.nos.boeing.com> <9E184648-12AC-4B38-8B51-6B384EA441A4@gmail.com> <2134F8430051B64F815C691A62D9831832CEE7A3@XCH-BLV-504.nw.nos.boeing.com> <489D13FBFA9B3E41812EA89F188F018E1B66487C@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1B66487C@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/Q8jk2uUmTnoAijOVJQOlZdQUuCI Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] RFC3315(bis) comment X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 19:52:35 -0000 Thanks Bernie, The multiple relay situation certainly opens a new can of worms. That said, I don't know that I have much further to offer regarding RAAN options since it is beginning to look like my needs can be met without using relay agents at all. Thanks - Fred fred.l.templin@boeing.com =20 > -----Original Message----- > From: Bernie Volz (volz) [mailto:volz@cisco.com] > Sent: Thursday, August 21, 2014 11:18 AM > To: Templin, Fred L; Ralph Droms > Cc: dhcwg@ietf.org > Subject: RE: [dhcwg] RFC3315(bis) comment >=20 > Of course, there could also be some communication between relays in a mul= tiple relay situation where > gleaning was being used and in that case this restriction would not apply= . >=20 > But perhaps best we ignore that. And, there's interesting issues about ti= ming in some cases with that > kind of design. I think we worked on addressing some of the timing issues= in RAAN by including a > sequence number scheme for server generated messages so relays could tell= the order. >=20 > - Bernie >=20 > -----Original Message----- > From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Templin, Fred L > Sent: Monday, August 11, 2014 11:46 AM > To: Ralph Droms > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] RFC3315(bis) comment >=20 > Hi Ralph, >=20 > OK, if I understand you correctly then maybe what would work would be 1-2= paragraphs added to > RFC3315(bis) to discuss the practice of relay agent gleaning. So, maybe a= dd a new Section 20.1.4 > something to the effect of: >=20 > "20.1.4 Relay Agent Gleaning >=20 > In operational practice, relay agents are often configured to > examine address and prefix information contained in client-server > transactions, e.g., for the purpose of injecting and withdrawing > information in the routing system. This practice (sometimes known > as "gleaning") has known operational limitations. >=20 > In particular, relay agents SHOULD NOT perform gleaning unless ther= e > is operational assurance that the path from the client to server wi= ll > will always travel through the same agent, and that no transaction > reordering will occur. Furthermore, relay agents SHOULD NOT perform > gleaning based solely on the client's requests to the server since > the messages may be rejected, e.g., due to authentication failure. > If any gleaning is to be done, it should therefore be based on the > server's replies to the client." >=20 > You also asked about a use case for informing the client of the success o= f the release. My AERO > proposal is one such use case, but certainly not the only one. In general= , in any environment in which > a client's request to the server is subject to authentication, the relay = agent should only perform > gleaning on the server's reply to the client. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > > -----Original Message----- > > From: Ralph Droms [mailto:rdroms.ietf@gmail.com] > > Sent: Saturday, August 09, 2014 5:13 AM > > To: Templin, Fred L > > Cc: dhcwg@ietf.org > > Subject: Re: [dhcwg] RFC3315(bis) comment > > > > > > > > > On Aug 8, 2014, at 6:39 PM, "Templin, Fred L" wrote: > > > > > > Hi Ralph, > > > > > >> -----Original Message----- > > >> From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ralph > > >> Droms > > >> Sent: Friday, August 08, 2014 12:53 PM > > >> To: dhcwg@ietf.org > > >> Subject: Re: [dhcwg] RFC3315(bis) comment > > >> > > >> I think the text needs a full disclosure warning to the effect that > > >> there is no guarantee that the Release-Reply transaction will traver= se the same relay agent as > other transactions. > > > > > > I think I understand the point, but this would not harm any relays > > > that were not on the original {Solicit/Request}-Reply path; they > > > would simply see that the client's IAs have been released regardless > > > of which relay they were initially established through. I think the > > > more dangerous case is for relays that would glean information from > > > the initial {Solicit/Request}-reply path; unless the relay has some > > > way of knowing that any subsequent Release would come through itself > > > and not through a different relay it cannot safely do the gleaning. > > > > More generally, the technique of transporting the RAAN option or > > extending the Reply message to enable gleaning - in my opinion, the > > two are equivalent for managing state in relay agents - was considered > > to be the wrong architecture for managing state in relay agents. As > > you point out, there is no guarantee that subsequent transactions will > > be forwarded by the relevant relay agent. The messages may not be deli= vered in the correct order. > Finally, there may not be a client-server transaction available when the = relay agent state needs to be > updated. > > > > > But, there is no > > > warning label in the spec about that. > > > > My suggestion is to add such a warning label to this option, if it is > > intended to enable gleaning/snooping. > > > > > > > > The information I am suggesting in my proposed text would also > > > provide potentially useful information to the client in the form of > > > a positive confirmation of the release of individual IAs independent > > > of what any relays might do. So, other documents that suggest relay > > > gleaning would be the place to explain the circumstances under which > > > gleaning can be applied. > > > > Do you have an explicit use case for informing the client of the succes= s of the release? > > > > > > > > All of that said, do we really want to fully examine relay gleaning > > > in both the forward and reverse paths in the RFC3315(bis) base spec? > > > I hope not, but maybe that is what you were thinking? > > > > Relay gleaning is, to my mind, sort of a bad idea but it seems to be > > popular and the solution of choice in certain situations. Note that I > > am speaking strictly from an architecture point of view; those operatin= g DHCP services may have a > different opinion. > > > > > > > > Thanks - Fred > > > fred.l.templin@boeing.com > > > > > >> - Ralph > > >> > > >>> On Aug 8, 2014, at 2:33 PM 8/8/14, Templin, Fred L wrote: > > >>> > > >>> Hello, > > >>> > > >>> In Section 18.2.6 of 'draft-dhcwg-dhc-rfc3315bis-02.txt' the next > > >>> to last paragraph of the section currently states: > > >>> > > >>> "After all the addresses have been processed, the server > > >>> generates a Reply message and includes a Status Code option with > > >>> value Success, a Server Identifier option with the server's DUID, > > >>> and a Client Identifier option with the client's DUID. For each > > >>> IA in the Release message for which the server has no binding > > >>> information, the server adds an IA option using the IAID from the > > >>> Release message, and includes a Status Code option with the value > > >>> NoBinding in the IA option. No other options are included in the = IA option." > > >>> > > >>> According to this specification, the server does not include any > > >>> information about IAs that were successfully released in the > > >>> transaction. Therefore, relays that need to "glean" client-server > > >>> transactions will have no way of knowing that the Release was > > >>> successfully executed by the server. > > >>> > > >>> A proposed resolution is to add an additional specification to > > >>> this paragraph as follows: > > >>> > > >>> "After all the addresses have been processed, the server > > >>> generates a Reply message and includes a Status Code option with > > >>> value Success, a Server Identifier option with the server's DUID, > > >>> and a Client Identifier option with the client's DUID. For each > > >>> IA in the Release message for which the server has released > > >>> binding information, the server adds an IA option using the IAID > > >>> from the Release message with both preferred-lifetime and > > >>> valid-lifetime set to 0 in the IA Address/Prefix option, and > > >>> includes a Status Code option with the value Success in the IA > > >>> option. For each IA in the Release message for which the server > > >>> has no binding information, the server adds an IA option using > > >>> the IAID from the Release message, and includes a Status Code > > >>> option with the value NoBinding in the IA option. No other option= s are included in the IA > option." > > >>> > > >>> Comments? Questions? > > >>> > > >>> Thanks - Fred > > >>> fred.l.templin@boeing.com > > >>> > > >>> _______________________________________________ > > >>> dhcwg mailing list > > >>> dhcwg@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/dhcwg > > >> > > >> _______________________________________________ > > >> dhcwg mailing list > > >> dhcwg@ietf.org > > >> https://www.ietf.org/mailman/listinfo/dhcwg >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From nobody Thu Aug 21 16:55:38 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B586B1A874F for ; Thu, 21 Aug 2014 16:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.203 X-Spam-Level: X-Spam-Status: No, score=0.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_AU=0.327, HOST_MISMATCH_AU=2.444, RP_MATCHES_RCVD=-0.668] autolearn=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 Ppb4k2Uep3-C for ; Thu, 21 Aug 2014 16:55:34 -0700 (PDT) Received: from munnari.OZ.AU (munnari.OZ.AU [202.29.151.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02E071A874B for ; Thu, 21 Aug 2014 16:55:28 -0700 (PDT) Received: from perseus.noi.kre.to (localhost [IPv6:::1]) by munnari.OZ.AU with ESMTP id s7LNndWg002022; Fri, 22 Aug 2014 06:50:05 +0700 (ICT) Received: from perseus.noi.kre.to (localhost [127.0.0.1]) by perseus.noi.kre.to (8.14.7/8.14.2) with ESMTP id s7LNn2uc019634; Fri, 22 Aug 2014 06:49:03 +0700 (ICT) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.5 From: Robert Elz To: "Templin, Fred L" In-Reply-To: <2134F8430051B64F815C691A62D9831832CF7AE5@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832CF7AE5@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CF60F1@XCH-BLV-504.nw.nos.boeing.com> <5D36713D8A4E7348A7E10DF7437A4B923AF0D823@nkgeml512-mbx.china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 22 Aug 2014 06:49:02 +0700 Message-ID: <202.1408664942@perseus.noi.kre.to> Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/K76zzeCKbHLMYR3-z80_YtQ1yH0 Cc: "dhcwg@ietf.org" , "jinmei@wide.ad.jp" Subject: Re: [dhcwg] Question on draft-ietf-dhc-sedhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 23:55:35 -0000 Date: Thu, 21 Aug 2014 16:19:50 +0000 From: "Templin, Fred L" Message-ID: <2134F8430051B64F815C691A62D9831832CF7AE5@XCH-BLV-504.nw.nos.boeing.com> | But, if bogus client B signs the | message with a bogus private key, shouldn't S simply ignore the message? | Otherwise, it would be divulging sensitive information to B, wouldn't it? What sensitive information? That S is a dhcp server? Is that sensitive somehow? Why? Or that S actually verifies signatures? Again, why? Or that the bogus signature B knows it provided is in fact bogus .. really? If something else, then what? If there is in fact no information being revealed, then it is better to reply - it allows clients that should be valid (ones that believe that anyway, ie: not intentionally intruding) but somehow aren't to find out what has gone wrong, and instead of asking "why is the dhcp server broken?" ask instead "what's wrong with my credentials?". kre ps: the bigger issue with any scheme where a server is asked (or even just can be asked) to validate client signatures (in an environment that is relatively open - less of a problem on a network that for other reasons can be considered reasonably secure) are DoS attacks on the server simply by bombarding it with bogus signatures - they're essentially free to create, yet consume notable resources attempting to verify. The only (partial) defence to that that I (one who has essentially no crypto expertise) can devise is to require the clients to use very low strength keys and have the server simply reject anything strong - say for RSA, anything more than 512 bits ... for most crypto that would be (these days) considered unsafe, but it really is probably good enough for validating dhcp clients, provided that the fact of that validation isn't used (by itself) to authorise any more than allocation of an address. From nobody Fri Aug 22 07:40:55 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 971121A016C for ; Fri, 22 Aug 2014 07:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham 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 uuAVPJFK8WDn for ; Fri, 22 Aug 2014 07:40:52 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4B171A04B7 for ; Fri, 22 Aug 2014 07:40:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s7MEepQ0021728; Fri, 22 Aug 2014 07:40:51 -0700 Received: from XCH-PHX-212.sw.nos.boeing.com (xch-phx-212.sw.nos.boeing.com [130.247.25.141]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s7MEehFl021191 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 22 Aug 2014 07:40:43 -0700 Received: from XCH-BLV-402.nw.nos.boeing.com (2002:82f7:191f::82f7:191f) by XCH-PHX-212.sw.nos.boeing.com (2002:82f7:198d::82f7:198d) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 22 Aug 2014 07:40:43 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.6]) by XCH-BLV-402.nw.nos.boeing.com ([169.254.2.151]) with mapi id 14.03.0181.006; Fri, 22 Aug 2014 07:40:42 -0700 From: "Templin, Fred L" To: Robert Elz Thread-Topic: [dhcwg] Question on draft-ietf-dhc-sedhcpv6 Thread-Index: Ac+8usvtlThiaS7BTzagQmSX8ZEBQgAXZQCAABCCZXAAHq+3AAAPwcGg Date: Fri, 22 Aug 2014 14:40:41 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CF9764@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832CF7AE5@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CF60F1@XCH-BLV-504.nw.nos.boeing.com> <5D36713D8A4E7348A7E10DF7437A4B923AF0D823@nkgeml512-mbx.china.huawei.com> <202.1408664942@perseus.noi.kre.to> In-Reply-To: <202.1408664942@perseus.noi.kre.to> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/NUx83S0CEECjQ-wMcEHoEvraa0A Cc: "dhcwg@ietf.org" , "jinmei@wide.ad.jp" Subject: Re: [dhcwg] Question on draft-ietf-dhc-sedhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 14:40:53 -0000 Hi kre, > -----Original Message----- > From: Robert Elz [mailto:kre@munnari.OZ.AU] > Sent: Thursday, August 21, 2014 4:49 PM > To: Templin, Fred L > Cc: Sheng Jiang; dhcwg@ietf.org; jinmei@wide.ad.jp > Subject: Re: [dhcwg] Question on draft-ietf-dhc-sedhcpv6 >=20 > Date: Thu, 21 Aug 2014 16:19:50 +0000 > From: "Templin, Fred L" > Message-ID: <2134F8430051B64F815C691A62D9831832CF7AE5@XCH-BLV-504.nw= .nos.boeing.com> >=20 >=20 > | But, if bogus client B signs the > | message with a bogus private key, shouldn't S simply ignore the messa= ge? > | Otherwise, it would be divulging sensitive information to B, wouldn't= it? >=20 > What sensitive information? That S is a dhcp server? Is that sensitive > somehow? Why? Or that S actually verifies signatures? Again, why? Or = that > the bogus signature B knows it provided is in fact bogus .. really? >=20 > If something else, then what? You ask good questions, and I honestly don't know what other ways B might stand to benefit from getting back an error code. The reason I brought this up is that this is different behavior than what happens in DHCPv6 authorization. In RFC3315 section 21.4.5.2: "The server uses the key identified in the message and validates the message as specified in section 21.4.2. If the message fails to pass the validation test or the server does not know the key identified by the 'key ID' field, the server MUST discard the message and MAY choose to log the validation failure." So, DHCPv6 auth is drop-silent while the proposed secure DHCPv6 is drop-and-return-error. I honestly don't know what are all of the security implications for the two choices, but it just seemed to me that telling the attacker nothing seemed more secure than telling the attacker something. Maybe someone with a deeper understanding of security could provide a better analysis.=20 =20 > If there is in fact no information being revealed, then it is better to > reply - it allows clients that should be valid (ones that believe that > anyway, ie: not intentionally intruding) but somehow aren't to find out w= hat > has gone wrong, and instead of asking "why is the dhcp server broken?" > ask instead "what's wrong with my credentials?". Sure, I get that. I just wonder why DHCPv6 auth and secure DHCPv6 handle error conditions differently, and should the latter document give 1-2 sentences saying why the design departure was chosen?=20 > kre >=20 > ps: the bigger issue with any scheme where a server is asked (or even jus= t can > be asked) to validate client signatures (in an environment that is relati= vely > open - less of a problem on a network that for other reasons can be consi= dered > reasonably secure) are DoS attacks on the server simply by bombarding it = with > bogus signatures - they're essentially free to create, yet consume notabl= e > resources attempting to verify. The only (partial) defence to that that= I > (one who has essentially no crypto expertise) can devise is to require th= e > clients to use very low strength keys and have the server simply reject > anything strong - say for RSA, anything more than 512 bits ... for most c= rypto > that would be (these days) considered unsafe, but it really is probably g= ood > enough for validating dhcp clients, provided that the fact of that valida= tion > isn't used (by itself) to authorise any more than allocation of an addres= s. Right, I think I get that too. Thanks - Fred fred.l.templin@boeing.com From nobody Sat Aug 23 06:40:11 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC4C71A01E7 for ; Sat, 23 Aug 2014 06:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 WBfrcfORa-ex for ; Sat, 23 Aug 2014 06:40:07 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C2861A01EF for ; Sat, 23 Aug 2014 06:40:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18477; q=dns/txt; s=iport; t=1408801208; x=1410010808; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jdWgpK8Np2g6iOjBWaPttD1F/vXD96AmuRaxNxTej9E=; b=cgQdeoTjpAjuuz6LjE5rx8vpTl+/ZR//9t+xggTJz1JyeAz6HbmSr3Vu MXXqav+XibTyAbs+AEdH0IEuoxtXdaqK37vEUcEfqf4eW7ymfMN5nYDcT 5otqWlC4Tj3V/X5q09WbJsC5ephAXATK+n3ku3aPMbT7f/eTM449JjvRf c=; X-IronPort-AV: E=Sophos; i="5.04,386,1406592000"; d="scan'208,217"; a="71705904" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP; 23 Aug 2014 13:40:07 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s7NDe6fo014013 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 23 Aug 2014 13:40:06 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.173]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Sat, 23 Aug 2014 08:40:06 -0500 From: "Bernie Volz (volz)" To: Khurram Mohammed Thread-Topic: Clarification in http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-stateful-issues-06 Thread-Index: Ac+8/qtzkVTk9oSpSVKYw6/Wv8wSzwAM+ir9AAKiOKYAaL95gA== Date: Sat, 23 Aug 2014 13:40:05 +0000 Message-ID: References: <711d40117ff44a36a24f3a09bc2d7784@DM2PR0501MB921.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.86.253.142] Content-Type: multipart/alternative; boundary="_000_D01B6541218E1volzciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/YeBIt10g8mh-3zUnnQbKqVZ5JF4 Cc: "ot@cisco.com" , "dhcwg@ietf.org" Subject: Re: [dhcwg] Clarification in http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-stateful-issues-06 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 13:40:10 -0000 --_000_D01B6541218E1volzciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable What harm is there in including them? It is also possible that the configur= ation on the Server changed between the Advertise and Request (though a sma= ll chance). What we are trying to do here is to have the client continue to request (re= new) with ALL IA_* options, even those it did not receive in an Advertise. Of course the client should include the Advertised IA_* options =96 that is= already in the text in RFC 3315. We are documenting the changed actions in= the draft. And this is not =91replacement=92 text for RFC 3315bis. It is d= ocumenting the PROPOSED SOLUTION. - Bernie From: Khurram Mohammed > Date: Thursday, August 21, 2014 at 8:40 AM To: Cisco Employee > Cc: Ole Troan >, Marcin Siodelski > Subject: Re: Clarification in http://tools.ietf.org/html/draft-ietf-dhc-dhc= pv6-stateful-issues-06 Thanks Bernie. Shouldn't the text in draft read as 'the client should include the offered = IA option types in its Request'? I just don't see the logic behind including the NOT offered options again t= owards the server noting if the server already informed the client in ADVER= TISE what it can offer eg if server only configured for IA_PD - then if cli= ent requesting both IA_NA + IA_PD in Solicit, then server will respond with= NoAddrAvail for IA_NA & IA Prefix for IA_PD. Client sending IA_NA & IA_PD = in Request will mean server to respond again with NoAddrAvail (which was se= nt at first place by server in advertise to inform client that server is no= t offering IA_NA addresses? -Khurram Sent from my iPhone On 21 Aug 2014, at 9:25 pm, "Bernie Volz (volz)" > wrote: The client should send the Request with IA_NA and IA_PD. Text says: Proposed solution: a client SHOULD accept Advertise messages, even when not all IA option types are being offered. And, in this case, the client SHOULD include the not offered IA option types in its Request. - Bernie (from iPad) On Aug 21, 2014, at 12:59 AM, "Khurram Mohammed" > wrote: Hello folks, I was reading through this draft and had a quick clarification w.r.t sectio= n 4.2 (as provided below). Am I right to interpret the draft for the below = scenario correctly: =E8DHCPv6 Client sends SOLICIT (with IA_NA and IA_PD options) to DHCPv6 Ser= ver =E8DHCPv6 Server sends ADVERTISE (with NoAddrAvail for IA_NA & IA Prefix fo= r IA_PD) to the DHCPv6 Client =E8SHOULD the DHCPv6 Client include ONLY IA_PD in its REQUEST (with IA Pref= ix for IA_PD) to the DHCPv6 Server? OR =E8SHOULD the DHCPv6 Client restart by sending SOLICIT with only IA_PD opti= on to DHCPv6 server to complete SARR sequence? Or is the case that both client behaviour are within the RFC 3315 & draft-i= etf-dhc-dhcpv6-stateful-issues-06 compliance? 4.2. Advertise Message [RFC3315] specifies that a client must ignore an Advertise message if a server will not assign any addresses to a client. A client requesting both IA_NA and IA_PD, with a server that only offers one of them, is not supported in the current protocol specification. Proposed solution: a client SHOULD accept Advertise messages, even when not all IA option types are being offered. And, in this case, the client SHOULD include the not offered IA option types in its Request. A client SHOULD only ignore an Advertise message when no IA option includes any offered addresses or delegated prefixes (or any future allocable resource). Note that ignored messages MUST still be processed for SOL_MAX_RT and INF_MAX_RT options as specified in [RFC7083]. Thanks heaps in advance, Best Regards, -Khurram --_000_D01B6541218E1volzciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <59CCE8E0116A78479B9C1FAA1942D17C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
What harm is there in including them? It is also possible that the con= figuration on the Server changed between the Advertise and Request (though = a small chance).

What we are trying to do here is to have the client continue to reques= t (renew) with ALL IA_* options, even those it did not receive in an Advert= ise.

Of course the client should include the Advertised IA_* options =96 th= at is already in the text in RFC 3315. We are documenting the changed actio= ns in the draft. And this is not =91replacement=92 text for RFC 3315bis. It= is documenting the PROPOSED SOLUTION.

- Bernie

From: Khurram Mohammed <khurram@juniper.net>
Date: Thursday, August 21, 2014 at = 8:40 AM
To: Cisco Employee <volz@cisco.com>
Cc: Ole Troan <ot@cisco.com>, Marcin Siodelski <msiodelski@gmail.com>
Subject: Re: Clarification in http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-stateful-issues-06

Thanks Bernie. 

Shouldn't the text in draft read as 'the client should include the off= ered IA option types in its Request'?

I just don't see the logic behind including the NOT offered options ag= ain towards the server noting if the server already informed the client in = ADVERTISE what it can offer eg if server only configured for IA_PD - then i= f client requesting both IA_NA + IA_PD in Solicit, then server will respond with NoAddrAvail for IA_NA &= ; IA Prefix for IA_PD. Client sending IA_NA & IA_PD in Request will mea= n server to respond again with NoAddrAvail (which was sent at first place b= y server in advertise to inform client that server is not offering IA_NA addresses?

-Khurram

Sent from my iPhone

On 21 Aug 2014, at 9:25 pm, "Bernie Volz (volz)" <volz@cisco.com> wrote:

The client should send the Request with IA_NA and IA_PD. Text says: 

=
   Proposed solution: a client SHOULD accept Advertise messages, even
   when not all IA option types are being offered.  And, =
in this case,
   the client SHOULD include the not offered IA option types i=
n its
   Request. 

- Bernie (from iPad)

On Aug 21, 2014, at 12:59 AM, "Khurram Mohammed" <khurram@juniper.net> wrote:

Hello folks,

 

I was reading through this draft and had a quick cla= rification w.r.t section 4.2 (as provided below). Am I right to interpret t= he draft for the below scenario correctly:

 

=E8DHCPv6 Client sends SOLICIT (with IA_NA and IA_PD options) to DHCPv6 Server<= /o:p>

=E8DHCPv6 Server sends ADVERTISE (with NoAddrAvail for IA_NA & IA Prefix for IA_= PD) to the DHCPv6 Client

=E8SHOULD the DHCPv6 Client include ONLY IA_PD in its REQUEST (with IA Prefix for IA= _PD) to the DHCPv6 Server?

OR

=E8SHOULD the DHCPv6 Client restart by sending SOLICIT with only IA_PD option to DHC= Pv6 server to complete SARR sequence?

 

Or is the case that both client behaviour are within the RFC 3315 &a= mp; draft-ietf-dhc-dhcpv6-stateful-issues-06 compliance?<= /p>

4.2.  Advertise Message

   [RFC3315<=
/a>] specifies that a client must ignore an Advertise message if=

   a server will not assign any addresses to a client.&=
nbsp; A client
   requesting both IA_NA and IA_PD, with a server that =
only offers one
   of them, is not supported in the current protocol sp=
ecification.
 
   Proposed solution: a client SHOULD accept Adverti=
se messages, even
   when not all IA option types are being offered.&n=
bsp; And, in this case,
   the client SHOULD include the not offered IA opti=
on types in its
   Request.  A client SHOULD only ignore an Adv=
ertise message when no IA
   option includes any offered addresses or delegate=
d prefixes (or any
   future allocable resource).  Note that ignored messages MUST st=
ill be
   processed for SOL_MAX_RT and INF_MAX_RT options as s=
pecified in
   [RFC7083].

 

Thanks heaps in advance,

 

Best Regards,

-Khurram

 --_000_D01B6541218E1volzciscocom_-- From khurram@juniper.net Sat Aug 23 07:01:47 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543C21A0377 for ; Sat, 23 Aug 2014 07:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 5izriuhdupAY for ; Sat, 23 Aug 2014 07:01:44 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0239.outbound.protection.outlook.com [207.46.163.239]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D5E81A0367 for ; Sat, 23 Aug 2014 07:01:43 -0700 (PDT) Received: from DM2PR0501MB921.namprd05.prod.outlook.com (10.242.173.19) by DM2PR0501MB923.namprd05.prod.outlook.com (10.242.173.21) with Microsoft SMTP Server (TLS) id 15.0.1010.18; Sat, 23 Aug 2014 14:01:41 +0000 Received: from DM2PR0501MB921.namprd05.prod.outlook.com ([10.242.173.19]) by DM2PR0501MB921.namprd05.prod.outlook.com ([10.242.173.19]) with mapi id 15.00.1010.016; Sat, 23 Aug 2014 14:01:41 +0000 From: Khurram Mohammed To: "Bernie Volz (volz)" Thread-Topic: Clarification in http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-stateful-issues-06 Thread-Index: Ac+8/qtzkVTk9oSpSVKYw6/Wv8wSzwAM+ir9AAKiOKYAaL95gAABDUGQ Date: Sat, 23 Aug 2014 14:01:40 +0000 Message-ID: <6cbf12f218fb4f25967dbcc5ff4b1583@DM2PR0501MB921.namprd05.prod.outlook.com> References: <711d40117ff44a36a24f3a09bc2d7784@DM2PR0501MB921.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.190.15] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 031257FE13 x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199003)(377454003)(24454002)(64706001)(19580395003)(33646002)(54356999)(19580405001)(16236675004)(19300405004)(87936001)(76176999)(20776003)(83322001)(81542001)(46102001)(76482001)(15975445006)(74316001)(77982001)(86362001)(220493001)(66066001)(81342001)(79102001)(80022001)(105586002)(4396001)(85306004)(99286002)(106356001)(230783001)(95666004)(2656002)(19625215002)(74502001)(50986999)(93886004)(108616004)(110136001)(85852003)(83072002)(76576001)(92566001)(19617315012)(99396002)(21056001)(101416001)(31966008)(90102001)(107046002)(74662001)(18717965001)(15202345003)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR0501MB923; H:DM2PR0501MB921.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_6cbf12f218fb4f25967dbcc5ff4b1583DM2PR0501MB921namprd05p_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/phbPXhFoseOPmd3XehXc65mARmQ X-Mailman-Approved-At: Sat, 23 Aug 2014 14:41:22 -0700 Cc: "ot@cisco.com" , "dhcwg@ietf.org" Subject: Re: [dhcwg] Clarification in http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-stateful-issues-06 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 14:04:37 -0000 --_000_6cbf12f218fb4f25967dbcc5ff4b1583DM2PR0501MB921namprd05p_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks Bernie for your feedback. Appreciated very much. Sure, there is no h= arm in including them, rather I wanted to figure out if there was any other= reason in mind (as otherwise NoAddrAvail Status Code msg function seemed r= edundant) to include it in the PROPOSED SOLUTION in this draft. Best Regards, -Khurram From: Bernie Volz (volz) [mailto:volz@cisco.com] Sent: Sunday, 24 August 2014 1:40 AM To: Khurram Mohammed Cc: ot@cisco.com; Marcin Siodelski; dhcwg@ietf.org Subject: Re: Clarification in http://tools.ietf.org/html/draft-ietf-dhc-dhc= pv6-stateful-issues-06 What harm is there in including them? It is also possible that the configur= ation on the Server changed between the Advertise and Request (though a sma= ll chance). What we are trying to do here is to have the client continue to request (re= new) with ALL IA_* options, even those it did not receive in an Advertise. Of course the client should include the Advertised IA_* options - that is a= lready in the text in RFC 3315. We are documenting the changed actions in t= he draft. And this is not 'replacement' text for RFC 3315bis. It is documen= ting the PROPOSED SOLUTION. - Bernie From: Khurram Mohammed > Date: Thursday, August 21, 2014 at 8:40 AM To: Cisco Employee > Cc: Ole Troan >, Marcin Siodelski > Subject: Re: Clarification in http://tools.ietf.org/html/draft-ietf-dhc-dhc= pv6-stateful-issues-06 Thanks Bernie. Shouldn't the text in draft read as 'the client should include the offered = IA option types in its Request'? I just don't see the logic behind including the NOT offered options again t= owards the server noting if the server already informed the client in ADVER= TISE what it can offer eg if server only configured for IA_PD - then if cli= ent requesting both IA_NA + IA_PD in Solicit, then server will respond with= NoAddrAvail for IA_NA & IA Prefix for IA_PD. Client sending IA_NA & IA_PD = in Request will mean server to respond again with NoAddrAvail (which was se= nt at first place by server in advertise to inform client that server is no= t offering IA_NA addresses? -Khurram Sent from my iPhone On 21 Aug 2014, at 9:25 pm, "Bernie Volz (volz)" > wrote: The client should send the Request with IA_NA and IA_PD. Text says: Proposed solution: a client SHOULD accept Advertise messages, even when not all IA option types are being offered. And, in this case, the client SHOULD include the not offered IA option types in its Request. - Bernie (from iPad) On Aug 21, 2014, at 12:59 AM, "Khurram Mohammed" > wrote: Hello folks, I was reading through this draft and had a quick clarification w.r.t sectio= n 4.2 (as provided below). Am I right to interpret the draft for the below = scenario correctly: =E8 DHCPv6 Client sends SOLICIT (with IA_NA and IA_PD options) to DHCPv6 Se= rver =E8 DHCPv6 Server sends ADVERTISE (with NoAddrAvail for IA_NA & IA Prefix f= or IA_PD) to the DHCPv6 Client =E8 SHOULD the DHCPv6 Client include ONLY IA_PD in its REQUEST (with IA Pre= fix for IA_PD) to the DHCPv6 Server? OR =E8 SHOULD the DHCPv6 Client restart by sending SOLICIT with only IA_PD opt= ion to DHCPv6 server to complete SARR sequence? Or is the case that both client behaviour are within the RFC 3315 & draft-i= etf-dhc-dhcpv6-stateful-issues-06 compliance? 4.2. Advertise Message [RFC3315] specifies that a client must ignore an Advertise message if a server will not assign any addresses to a client. A client requesting both IA_NA and IA_PD, with a server that only offers one of them, is not supported in the current protocol specification. Proposed solution: a client SHOULD accept Advertise messages, even when not all IA option types are being offered. And, in this case, the client SHOULD include the not offered IA option types in its Request. A client SHOULD only ignore an Advertise message when no IA option includes any offered addresses or delegated prefixes (or any future allocable resource). Note that ignored messages MUST still be processed for SOL_MAX_RT and INF_MAX_RT options as specified in [RFC7083]. Thanks heaps in advance, Best Regards, -Khurram --_000_6cbf12f218fb4f25967dbcc5ff4b1583DM2PR0501MB921namprd05p_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thanks = Bernie for your feedback. Appreciated very much. Sure, there is no harm in = including them, rather I wanted to figure out if there was any other reason= in mind (as otherwise NoAddrAvail Status Code msg function seemed redundant) to include it in the PROPOSED SOLUTION= in this draft.

&n= bsp;

Best Re= gards,

-Khurra= m

 

From: Bernie Volz (volz) [mailto:volz@cisco.com]
Sent: Sunday, 24 August 2014 1:40 AM
To: Khurram Mohammed
Cc: ot@cisco.com; Marcin Siodelski; dhcwg@ietf.org
Subject: Re: Clarification in http://tools.ietf.org/html/draft-ietf-= dhc-dhcpv6-stateful-issues-06

 

What ha= rm is there in including them? It is also possible that the configuration o= n the Server changed between the Advertise and Request (though a small chan= ce).

&n= bsp;

What we= are trying to do here is to have the client continue to request (renew) wi= th ALL IA_* options, even those it did not receive in an Advertise.

&n= bsp;

Of cour= se the client should include the Advertised IA_* options – that is al= ready in the text in RFC 3315. We are documenting the changed actions in th= e draft. And this is not ‘replacement’ text for RFC 3315bis. It is documenting the PROPOSED SOLUTION.

&n= bsp;

- Berni= e

&n= bsp;

From: Khurram Mohammed <khurram@juniper.net>
Date: Thursday, August 21, 2014 at 8:40 AM
To: Cisco Employee <volz@cisco.= com>
Cc: Ole Troan <ot@cisco.com&g= t;, Marcin Siodelski <msiodelski= @gmail.com>
Subject: Re: Clarification in http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-stateful-issues-06

&n= bsp;

Thanks = Bernie. 

&n= bsp;

Shouldn= 't the text in draft read as 'the client should include the offered IA opti= on types in its Request'?

&n= bsp;

I just = don't see the logic behind including the NOT offered options again towards = the server noting if the server already informed the client in ADVERTISE wh= at it can offer eg if server only configured for IA_PD - then if client requesting both IA_NA + IA_PD in Solicit, t= hen server will respond with NoAddrAvail for IA_NA & IA Prefix for IA_P= D. Client sending IA_NA & IA_PD in Request will mean server to respond = again with NoAddrAvail (which was sent at first place by server in advertise to inform client that server is not offering = IA_NA addresses?

&n= bsp;

-Khurra= m


Sent from my iPhone


On 21 Aug 2014, at 9:25 pm, "Bernie Volz (volz)" <volz@cisco.com> wrote:

The cli= ent should send the Request with IA_NA and IA_PD. Text says:

&n= bsp;

   Proposed solution: a client SHOULD accept Adverti=
se messages, even<=
/pre>

   when not all IA option types are being offered.&n=
bsp; And, in this case,


   the client SHOULD include the not offered IA opti=
on types in its

   Request. 


- Bernie (from iPad)


On Aug 21, 2014, at 12:59 AM, "Khurram Mohammed" <khurram@juniper.net> wrote:

Hello folks,<= /span>

 =

I was reading through th= is draft and had a quick clarification w.r.t section 4.2 (as provided below= ). Am I right to interpret the draft for the below scenario correctly:=

 =

=E8 DHCPv6 Client se= nds SOLICIT (with IA_NA and IA_PD options) to DHCPv6 Server

=E8 DHCPv6 Server se= nds ADVERTISE (with NoAddrAvail for IA_NA & IA Prefix for IA_PD) to the= DHCPv6 Client

=E8 SHOULD the DHC= Pv6 Client include ONLY IA_PD in its REQUEST (with IA Prefix for IA_PD) to = the DHCPv6 Server?

OR

=E8 SHOULD the DHC= Pv6 Client restart by sending SOLICIT with only IA_PD option to DHCPv6 serv= er to complete SARR sequence?=

 

Or is the case that both client behaviour are within the RFC 3315 &a= mp; draft-ietf-dhc-dhcpv6-stateful-issues-06 compliance?

4.2.  Advertise Message 
   [RFC3315<=
/a>] specifies that a client must ignore an Advertise message if
   a server will not assign any addresses to a client.&=
nbsp; A client
   requesting both IA_NA and IA_PD, with a server that =
only offers one
   of them, is not supported in the current protocol sp=
ecification.
 
   Proposed solution: a client SHOULD accept Adverti=
se messages, even<=
/pre>

   when not all IA option types are being offered.&n=
bsp; And, in this case,


   the client SHOULD include the not offered IA opti=
on types in its

   Request.  A client SHOULD only ignore an Adv=
ertise message when no IA=



   option includes any offered addresses or delegate=
d prefixes (or any=



   future allocable resource).  Note that ignored messages MUST st=
ill be


   processed for SOL_MAX_RT and INF_MAX_RT options as s=
pecified in


   [RFC7083].


 =



Thanks heaps in advance,=



 =



Best Regards,=



-Khurram

--_000_6cbf12f218fb4f25967dbcc5ff4b1583DM2PR0501MB921namprd05p_--