From nobody Mon Jan 4 01:47:24 2016 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 93CE61A8033; Mon, 4 Jan 2016 01:47:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160104094721.20761.14254.idtracker@ietfa.amsl.com> Date: Mon, 04 Jan 2016 01:47:21 -0800 Archived-At: Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-access-network-identifier-11.txt 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: Mon, 04 Jan 2016 09:47:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Access Network Identifier Option in DHCP Authors : Shwetha Bhandari Sri Gundavelli Mark Grayson Bernie Volz Jouni Korhonen Filename : draft-ietf-dhc-access-network-identifier-11.txt Pages : 19 Date : 2016-01-04 Abstract: This document specifies the format and mechanism that is to be used for encoding access network identifiers in DHCPv4 and DHCPv6 messages by defining new access network identifier options and sub-options. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-access-network-identifier/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dhc-access-network-identifier-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-access-network-identifier-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 4 13:44:59 2016 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 8AC401AC3D2 for ; Mon, 4 Jan 2016 13:44:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 LZ8KqU8yEjYj for ; Mon, 4 Jan 2016 13:44:56 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7DD61ABB1A for ; Mon, 4 Jan 2016 13:44:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13246; q=dns/txt; s=iport; t=1451943895; x=1453153495; h=from:to:subject:date:message-id:mime-version; bh=uxoDh3JfAg+VO5nB5a4boCT3MDKLTKOQ3JZZzasA7WA=; b=TXAhPOl3efuWstk7TmdmZbgW+aQ1VUCh1TFqvZP+LdbmTuISXgAZMJhI UByoMQSjZ77lytGvxfQ1OsB6XnOQxnbQ4DBiR4OnaSjR6ObRoTbTmbHj3 /ppP2mNiw+YObhR3LZaBNh5Zlz2YSJRjZa7np3FaTi3K93UQE8OX4SVSH Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/AQCp54pW/5tdJa1egm5MUnOIU7Fkg?= =?us-ascii?q?hMBDYFkhy44FAEBAQEBAQF/C4Q7KQReAQJ+JgEEG4gnoGigZQEBAQEBBQEBAQE?= =?us-ascii?q?BAR2VEQWHaIcFiBkBjUmBY4RGiFmOOQEgAQFCghEcgV2EeoEIAQEB?= X-IronPort-AV: E=Sophos; i="5.20,522,1444694400"; d="scan'208,217"; a="58423891" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Jan 2016 21:44:49 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u04LinJW016815 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 4 Jan 2016 21:44:49 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 4 Jan 2016 15:44:48 -0600 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1104.009; Mon, 4 Jan 2016 15:44:48 -0600 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: WG Session @ IETF-95 (Buenos Aires) Agenda Requests - Deadline 2/14/2016 Thread-Index: AdFHORD4y95fMyRVQ56UWvb6lX4DVg== Importance: high X-Priority: 1 Date: Mon, 4 Jan 2016 21:44:48 +0000 Message-ID: <005134edeb9e4550b55a23776afaef15@XCH-ALN-003.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.1.195] Content-Type: multipart/alternative; boundary="_000_005134edeb9e4550b55a23776afaef15XCHALN003ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [dhcwg] WG Session @ IETF-95 (Buenos Aires) Agenda Requests - Deadline 2/14/2016 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, 04 Jan 2016 21:44:57 -0000 --_000_005134edeb9e4550b55a23776afaef15XCHALN003ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi: The scheduling requests for meeting slots for IETF-95 in Buenos Aires have = opened up (we must submit a request before 2/19/2016). Our plan for IETF-95 will be the same as we did for IETF-94: - We are encouraging agenda requests NOW thru February= 14th, 2016 (this will give us a few days to organize the agenda and decide= on the session length request). - We will submit our time request for IETF-95 based on= the RECEIVED agenda requests (by the February 14th deadline). - Requests after February 14th will most likely be REJ= ECTED (once the time slot is filled). In the past we have been more accommo= dating, but because of the pressure on IETF meeting time, we are being aske= d to justify our time slot request. And meeting time should be used to disc= uss and resolve issues, not present overviews of drafts or status updates. Therefore, please submit requests as soon as you can (and well before 2/14)= if you do plan to present at the DHC WG session in Buenos Aires. As in the past, please provide: Title Of Session: Presenter: Related Drafts: Time Required: Purpose of Session: We do want to remind those requesting time that you should focus on discuss= ing key issues that need resolution to move a draft forward. We are 3 months from that next meeting. - Tomek & Bernie --_000_005134edeb9e4550b55a23776afaef15XCHALN003ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi:

 

The scheduling requests for meeting slots for IETF-9= 5 in Buenos Aires have opened up (we must submit a request before 2/19/2016= ).

 

Our plan for IETF-95 will be the same as we did for = IETF-94:

-       = ;            &n= bsp;  We are encouraging agenda requests NOW thru Februar= y 14th, 2016 (this will give us a few days to organize the agenda and decid= e on the session length request).

-       = ;            &n= bsp;  We will submit our time request for IETF-95 based o= n the RECEIVED agenda requests (by the February 14th deadline).<= /p>

-       = ;            &n= bsp;  Requests after February 14th will most likely be RE= JECTED (once the time slot is filled). In the past we have been more accomm= odating, but because of the pressure on IETF meeting time, we are being ask= ed to justify our time slot request. And meeting time should be used to discuss and resolve issues, not present= overviews of drafts or status updates.

 

Therefore, please submit requests as soon as you can= (and well before 2/14) if you do plan to present at the DHC WG session in = Buenos Aires.

 

As in the past, please provide:

 

Title Of Session:

Presenter:

Related Drafts:

Time Required:

Purpose of Session:

 

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

 

We are 3 months from that next meeting.

 

-     &= nbsp;    Tomek & Bernie

 

--_000_005134edeb9e4550b55a23776afaef15XCHALN003ciscocom_-- From nobody Wed Jan 6 09:49:28 2016 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 6F80B1A0029 for ; Wed, 6 Jan 2016 09:49:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 jN5OnMbmshdF for ; Wed, 6 Jan 2016 09:49:25 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 154B41A0026 for ; Wed, 6 Jan 2016 09:49:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15206; q=dns/txt; s=iport; t=1452102565; x=1453312165; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=AcMa5fzckC6F0Rsyh2t7q73/FF5+NVBuz6QVP698rAk=; b=DRw3c+AWRMWeA2W5L6B7/5h3VV1NglOPBx+bZOoxCc1elXhBzsLHFFjQ IZdjqKEjYcFbYQ+62QZTODiXYP6yOtQ/RlOVhvJZQF413y5un6Ynhf8Vf 13EIBCdxQOlaOu0J0oyTQ565nIfhvwiBRLLa/M40jXqgC6Tze824p4aeB U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DUAgB1Uo1W/4kNJK1egm5MUm0GhTWDH?= =?us-ascii?q?qQDj1QBDYFkJIQUgVcCgSQ4FAEBAQEBAQF/C4Q0AQEBBB0QXAIBCBEEAQEoBzI?= =?us-ascii?q?UCQgBAQQTCIgnDsF8AQEBAQEBAQEBAQEBAQEBAQEBAQEBGItVgTyCahEBTAmEL?= =?us-ascii?q?wWXCgGFQYgMgWNKg3mIW45GAREPAQFCgkqBQHIBhB46gQgBAQE?= X-IronPort-AV: E=Sophos; i="5.20,530,1444694400"; d="scan'208,217"; a="61220198" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Jan 2016 17:49:24 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u06HnNLT015288 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 6 Jan 2016 17:49:24 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 6 Jan 2016 11:49:23 -0600 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1104.009; Wed, 6 Jan 2016 11:49:23 -0600 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: Adoption Call for draft-cui-dhc-dhcpv6-prefix-length-hint-issue (Ends January 8, 2016) Thread-Index: AdE4MfuqkAEjr/PZS32nv4P+3Sj+0QK5tiJAAWRdgKA= Date: Wed, 6 Jan 2016 17:49:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.131.78.123] Content-Type: multipart/alternative; boundary="_000_bea9b87ae80344009d37d4cd0dfd91c7XCHALN003ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [dhcwg] Adoption Call for draft-cui-dhc-dhcpv6-prefix-length-hint-issue (Ends January 8, 2016) 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, 06 Jan 2016 17:49:27 -0000 --_000_bea9b87ae80344009d37d4cd0dfd91c7XCHALN003ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable (WG co-chair hat off) I do support adoption of this work. I think this is u= seful work to help clarify how clients/servers should interact in getting t= he "proper" prefix lengths. - Bernie From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz) Sent: Wednesday, December 30, 2015 10:44 AM To: dhcwg@ietf.org Subject: Re: [dhcwg] Adoption Call for draft-cui-dhc-dhcpv6-prefix-length-h= int-issue (Ends January 8, 2016) Reminder - Adoption call ends January 8. - Bernie From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz) Sent: Wednesday, December 16, 2015 1:46 PM To: dhcwg@ietf.org Subject: [dhcwg] Adoption Call for draft-cui-dhc-dhcpv6-prefix-length-hint-= issue (Ends January 8, 2016) Hello: This email initiates a WG call for adoption of the draft-cui-dhc-dhcpv6-pre= fix-length-hint-issue-03 (http://tools.ietf.org/html/draft-cui-dhc-dhcpv6-p= refix-length-hint-issue-03) document as a DHC WG work item. Please indicate whether you support the adoption or not, and if not, why no= t. See https://tools.ietf.org/html/rfc7221#section-2.2 if you have question= s about the criteria for adoption. This document falls within the WG Charte= r (https://datatracker.ietf.org/wg/dhc/charter/) under items #2, #3, and #4= . There are currently NO IPR claims against this draft (please see http://dat= atracker.ietf.org/wg/dhc/documents/ as this could change at any time). The co-chairs will determine the consensus after January 8, 2016. (This is = a longer period than usual because of the year end Holidays.) Happy Holidays & New Year! - Tomek & Bernie --_000_bea9b87ae80344009d37d4cd0dfd91c7XCHALN003ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

(WG co-chair hat off) = I do support adoption of this work. I think this is useful work to help cla= rify how clients/servers should interact in getting the “proper”= ; prefix lengths.

 

-&nb= sp;         Bernie

 

From: dhcwg [mailto:dhcwg-bounces@ietf.org] <= b>On Behalf Of Bernie Volz (volz)
Sent: Wednesday, December 30, 2015 10:44 AM
To: dhcwg@ietf.org
Subject: Re: [dhcwg] Adoption Call for draft-cui-dhc-dhcpv6-prefix-l= ength-hint-issue (Ends January 8, 2016)

 

Reminder – Adopt= ion call ends January 8.

 

-&nb= sp;         Bernie

 

From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz)
Sent: Wednesday, December 16, 2015 1:46 PM
To: dhcwg@ietf.org
Subject: [dhcwg] Adoption Call for draft-cui-dhc-dhcpv6-prefix-lengt= h-hint-issue (Ends January 8, 2016)

 

Hello:

 

This email initiates a WG call for adoption of th= e draft-cui-dhc-dhcpv6-prefix-length-hint-issue-03 (http://too= ls.ietf.org/html/draft-cui-dhc-dhcpv6-prefix-length-hint-issue-03) document as a DHC WG work item.

 

Please indicate whether you support the adoption = or not, and if not, why not. See https://tools.i= etf.org/html/rfc7221#section-2.2 if you have questions about the criter= ia for adoption. This document falls within the WG Charter (https://datatracker.ietf.org/wg/d= hc/charter/) under items #2, #3, and #4.

 

There are currently NO IPR claims against this dr= aft (please see http://datatracke= r.ietf.org/wg/dhc/documents/ as this could change at any time).

 

The co-chairs will determine the consensus after = January 8, 2016. (This is a longer period than usual because of the year en= d Holidays.)

 

Happy Holidays & New Year!

 

-       = ;   Tomek & Bernie

 

--_000_bea9b87ae80344009d37d4cd0dfd91c7XCHALN003ciscocom_-- From nobody Thu Jan 7 07:01:26 2016 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 696551A8AFA for ; Thu, 7 Jan 2016 07:01:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 YzUlZAdWXGEF for ; Thu, 7 Jan 2016 07:01:22 -0800 (PST) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E35A1A8AFE for ; Thu, 7 Jan 2016 07:01:22 -0800 (PST) Received: by mail-ig0-x22b.google.com with SMTP id ik10so57228079igb.1 for ; Thu, 07 Jan 2016 07:01:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wMho2IT5TArpKhE456uV/BWlYcfh9w37lffmMHHnF4U=; b=PQjoaCy5QSb9yb03kHsCVrjYMcwRriGCXfqS9Fep3/C3rTNqnmG/xHKM5fnOR8G4Oq 5MPppUNxL8MvSdS7UrGKomeQxg2/+r2R2bXQR5X2ALYq1Vct0OrJidP9HAJc5RKmRGW1 rJRg6B532+2HBhDf7WtFAA1Fd9aWtafymG+YE= 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=wMho2IT5TArpKhE456uV/BWlYcfh9w37lffmMHHnF4U=; b=hJvFynPX6dWw500LBoLBZFXYkbn4lKM/nOs0ORfFn1NEGMuhxMU4kdsAyRW0Pcx/2T OF5V7YJlbVL/2+pB4OemV4bFAUthyiJPkctwAp2VTmzgTZPr1dbiFLNkuPAL2w3wQ3Mh luLm6B7HFL5Rihb9SCBr640J+b0hUFd2Y2NEGVeffUvdmIg2zU6m63CRZbaPUcc6GvH5 swcY14NbQb4x+avApr7iZlxax8NqiiUysRh+g8aJAnV5VVMVbkUurebUa5xK2EvnACHN wdNWbRwhwPnPNw6d8k2tKofO2boZMSdZtMFgG4VNpthSX7GQGZhqnnRFAGhqEiNT63xq WEyg== X-Gm-Message-State: ALoCoQl+d6f0HazUeWLUOpXWReF9HP9skx6Ip1vqHAe+bWBhTIYcXULWux6c7RexACbFnaBNmzKMVuM1UT5dscmmu9D4dTZ2hGpb9jopKNWeI6mOdecTGJI= MIME-Version: 1.0 X-Received: by 10.50.156.103 with SMTP id wd7mr16745355igb.5.1452178881472; Thu, 07 Jan 2016 07:01:21 -0800 (PST) Received: by 10.64.252.169 with HTTP; Thu, 7 Jan 2016 07:01:21 -0800 (PST) In-Reply-To: References: Date: Thu, 7 Jan 2016 10:01:21 -0500 Message-ID: From: Timothy Winters To: "Bernie Volz (volz)" Content-Type: multipart/alternative; boundary=001a1136b2d661c2990528bfbeca Archived-At: Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Adoption Call for draft-cui-dhc-dhcpv6-prefix-length-hint-issue (Ends January 8, 2016) 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 Jan 2016 15:01:24 -0000 --001a1136b2d661c2990528bfbeca Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I also support the DHC working group adopting this work. ~Tim On Wed, Jan 6, 2016 at 12:49 PM, Bernie Volz (volz) wrote: > (WG co-chair hat off) I do support adoption of this work. I think this is > useful work to help clarify how clients/servers should interact in gettin= g > the =E2=80=9Cproper=E2=80=9D prefix lengths. > > > > - Bernie > > > > *From:* dhcwg [mailto:dhcwg-bounces@ietf.org] *On Behalf Of *Bernie Volz > (volz) > *Sent:* Wednesday, December 30, 2015 10:44 AM > *To:* dhcwg@ietf.org > *Subject:* Re: [dhcwg] Adoption Call for > draft-cui-dhc-dhcpv6-prefix-length-hint-issue (Ends January 8, 2016) > > > > Reminder =E2=80=93 Adoption call ends January 8. > > > > - Bernie > > > > *From:* dhcwg [mailto:dhcwg-bounces@ietf.org ] *O= n > Behalf Of *Bernie Volz (volz) > *Sent:* Wednesday, December 16, 2015 1:46 PM > *To:* dhcwg@ietf.org > *Subject:* [dhcwg] Adoption Call for > draft-cui-dhc-dhcpv6-prefix-length-hint-issue (Ends January 8, 2016) > > > > Hello: > > > > This email initiates a WG call for adoption of the > draft-cui-dhc-dhcpv6-prefix-length-hint-issue-03 ( > http://tools.ietf.org/html/draft-cui-dhc-dhcpv6-prefix-length-hint-issue-= 03) > document as a DHC WG work item. > > > > Please indicate whether you support the adoption or not, and if not, why > not. See https://tools.ietf.org/html/rfc7221#section-2.2 if you have > questions about the criteria for adoption. This document falls within the > WG Charter (https://datatracker.ietf.org/wg/dhc/charter/) under items #2, > #3, and #4. > > > > There are currently NO IPR claims against this draft (please see > http://datatracker.ietf.org/wg/dhc/documents/ as this could change at any > time). > > > > The co-chairs will determine the consensus after January 8, 2016. (This i= s > a longer period than usual because of the year end Holidays.) > > > > Happy Holidays & New Year! > > > > - Tomek & Bernie > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > --=20 Timothy Winters UNH-IOL Senior Executive, Software and IP Networking *Please note we've moved!* 21 Madbury Rd, Suite 100, Durham, NH 03824 603-421-4987 --001a1136b2d661c2990528bfbeca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I also support the DHC working group adopting this work.
~Tim

On Wed, Jan 6, 2016 at 12:49 PM, Bernie Volz (volz) <volz@ci= sco.com> wrote:

(WG co-chair hat off) = I do support adoption of this work. I think this is useful work to help cla= rify how clients/servers should interact in getting the =E2=80=9Cproper=E2= =80=9D prefix lengths.

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Bernie<= /u>

=C2=A0

From: dhcwg [mailto:dhcwg-bounces@ietf.org= ] On Behalf Of Bernie Volz (volz)
Sent: Wednesday, December 30, 2015 10:44 AM
To: dhcwg@ietf.o= rg
Subject: Re: [dhcwg] Adoption Call for draft-cui-dhc-dhcpv6-prefix-l= ength-hint-issue (Ends January 8, 2016)

=C2=A0

Reminder =E2=80=93 Ado= ption call ends January 8.

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Bernie<= /u>

=C2=A0

From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz)
Sent: Wednesday, December 16, 2015 1:46 PM
To: dhcwg@ietf.o= rg
Subject: [dhcwg] Adoption Call for draft-cui-dhc-dhcpv6-prefix-lengt= h-hint-issue (Ends January 8, 2016)

=C2=A0

Hello:

=C2=A0

This email initiates a WG call for adoption of the draft-cui-dhc-dhcpv6-= prefix-length-hint-issue-03 (http://tools.ie= tf.org/html/draft-cui-dhc-dhcpv6-prefix-length-hint-issue-03) document as a DHC WG work item.

=C2=A0

Please indicate whether you support the adoption or not, and if not, why= not. See https://tools.ietf.org/html/rfc7221#section-2.2 if you have question= s about the criteria for adoption. This document falls within the WG Charte= r (https://datatracker.ietf.org/wg/dhc/charter/) under items #2, #3, and #4.

=C2=A0

There are currently NO IPR claims against this draft (please see http://datatracker.ietf.org/wg/dhc/documents/ as this could change at = any time).

=C2=A0

The co-chairs will determine the consensus after January 8, 2016. (This = is a longer period than usual because of the year end Holidays.)<= /u>

=C2=A0

Happy Holidays & New Year!

=C2=A0

-=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Tomek & Bernie

=C2=A0


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg




--

Timothy Wint= ers
U= NH-IOL Senior Executive, Software and IP Networking
Please note we've moved!<= br>21 Ma= dbury Rd, Suite 100, Durham, NH 03824
603-421-4987

<= /div>
--001a1136b2d661c2990528bfbeca-- From nobody Thu Jan 7 15:10:20 2016 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 5A76C1A1B13; Thu, 7 Jan 2016 15:10:19 -0800 (PST) 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 M3Cuh7GNYonn; Thu, 7 Jan 2016 15:10:16 -0800 (PST) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B03B21A1B8B; Thu, 7 Jan 2016 15:10:16 -0800 (PST) Received: by mail-io0-x230.google.com with SMTP id 77so238445792ioc.2; Thu, 07 Jan 2016 15:10:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=TdZeFZbAQ+rX1uS/TpDAAXEWfE3Cf7j/MPBvPqw61do=; b=O1SCV1hBptb/86oFRaqGVkcHY78kSPCTf7QQr1fXR4rlJ+kwPdK44GaDS0mrPtcMws e9k/bAmMEyfl+hdOYbPi9Ibg2GMhQ1TJRrue4h6U8WyzXKsmPi23K/yPZcbXYyBUkGeG FC5i/oaoMaCeRtBtXGIiNr+pfoXUG5TDPKsWSDjecIKpGJQI9lfq8w5YALWN8sYX2Hb4 nxVQUgYS9dFmgLfSaXxzj55qV2BOHdw7iisLr+wYoqvUFIEiqDGl89VpRRX06epAQdrj 1oJ468NZc+PNcof1OzrQsQY2VS6WUTsNBDElGmU4jMczqk1/Lwu3ERYHeJK9fcVnD4p5 VqsQ== MIME-Version: 1.0 X-Received: by 10.107.137.151 with SMTP id t23mr72900834ioi.172.1452208215958; Thu, 07 Jan 2016 15:10:15 -0800 (PST) Sender: jinmei.tatuya@gmail.com Received: by 10.107.129.80 with HTTP; Thu, 7 Jan 2016 15:10:15 -0800 (PST) Date: Thu, 7 Jan 2016 15:10:15 -0800 X-Google-Sender-Auth: PWfUcDPgOiDd3fRHg_TGlwEY5ow Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: draft-ietf-dhc-sedhcpv6@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "dhcwg@ietf.org" Subject: [dhcwg] comments on draft-ietf-dhc-sedhcpv6-10.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 Jan 2016 23:10:19 -0000 I've read this version of draft. While I happen to be listed as a co-author, I was not really involved in this revision process, so I'm basically making these comments as a third-party reader. First, I have some higher-level points to discuss: - this protocol changes DHCPv6 message exchanges quite substantially: previously, the client first sends a Solicit message, gets possibly multiple Advertise messages, chooses the server (= sender of one of the Advertises) that would be best for the client, and then sends a Request to that chosen server. Now the server selection is done at the key exchange phase (the initial Information-request and Reply exchange), and the Solicit can be sent only to a single server. If the client doesn't like the Advertise it could restart the whole process, but it will be more expensive, and there's no guarantee that other servers can provide a better Advertise. One might argue that it's okay as "secure DHCPv6" is an "optional" extension. But, with keeping in mind that the current IETF trend is to make everything privacy-aware (often by making everything encrypted), I'd personally say we should consider it to be the standard mode of DHCPv6 operation even if users can still disable it. From this point of view, I think we should either A. make the server selection behavior more compatible with the pre-encryption protocol, or B. accept we give up the previous server selection feature for privacy (after careful assessment of its effect and with clear wg consensus), and explicitly note that. we might even have to reflect that in rfc3315bis. - As encryption is now mandatory, I now wonder whether we need a separate "signature" at all. Except for the signature in the reply to the initial Information-request, the explicit signature doesn't seem to provide any additional integrity or authentication. And, as we now don't allow TOFU for authentication (i.e., we should validate the certificate out-of-band anyway, and that's almost the only important content of this reply), the signature in the first Reply wouldn't be much useful either. So we might consider simplifying the protocol - Slightly related to the previous point, this draft doesn't talk about encryption algorithms, let alone whether/how to negotiate the encryption algorithm. (Aside from whether we need a separate 'signature') Perhaps it implicitly assumes to use the "signature algorithm" for encryption, too, but, if so, I think it should explicitly say so. - This protocol uses the server DUID as the identifier of the server key (pair), and (implicitly) assumes the client only has one key (pair). Is that okay? Don't we need a separate key ID value so we can identify the key to be used for decryption without actually trying to decrypt the message with all possible keys? (In the case of client this might be trickier since the 'key ID' can reveal the identify of the client). - The 'public key option' has been removed in this version. I probably missed some part of the past discussions, but did we make that decision? What's the rationale of the removal? - The "security issues" and "applicability" sections (especially the latter) look still weak/insufficient to me. I'll make some more specific comments below. - Related to the previous point, what (will) happened for the separate threat analysis/usage document? If the plan was to move all difficult discussions regarding the "security issues" to the separate document, we should also see it with this protocol document. (In my understanding) the latter can't move forward itself otherwise. Some specific comments on the draft text follow: - Section 4 authentication method. However, this method provides little message integrity or source integrity check, and it protects only the Reconfigure message. This key is transmitted in plaintext. I'm not sure if I get the phrase "this method provides little message integrity or source integrity check". Does it try to say "*Because* the key is transmitted in plaintext"? - Section 4 IETF has expressed strong agreement that PM is an attack that needs to be mitigated where possible in [RFC7258]. I think the acronym "PM" should be explicitly introduced when "pervasive monitoring" first appears (in Introduction). - Section 5.1 [...] Depending on its policy, it can choose to connect repeat the server discovery process after certain delay or attempt to connect to a different network. I'm not sure what this 'connect' means. Does it intend to say cases like a smartphone/laptop trying to find a wifi base station? - Section 5.3: what about the server-to-client case? Clients are expected to rely on the selection in the initial Information-request/Reply exchange? If the recipient does not support the algorithm used by the sender, it cannot authenticate the message. In the client-to-server case, the server SHOULD reply with an AlgorithmNotSupported status code (defined in Section 10.3). Upon receiving this status code, the client MAY resend the message protected with the mandatory algorithm (defined in Section 10.1.2). - Section 5.4: in general, I think this section is still quite weak and/or insufficient. First, the current text reads as if PKI is (readily) usable in enterprise networks, yet it dismisses its deployment as out-of-scope. I don't think this would address concerns/questions raised by external reviewers. My understanding of the external feedback and our followup discussions is that one sure way to deploy this protocol in enterprise network is to almost manually configure the clients with the server certificate and configure the server with clients certificates. But we'll then have to explain what's the advantage of this new protocol against the RFC3315 security mechanism since Section 4 of this document states manual configuration is one major flaw of the RFC3315 mechanism. My personal answer to this question is that the public-key based approach is slightly securer in cases such as that where clients keys are quietly stolen by an attacker (so they can pretend to be a valid client later). On top of such realistic discussions, I think we can also mention the use of PKI as a possibility of making the configuration (much) less manual. But since it would require answering many difficult questions, IMO we should be honest to say its feasibility is unclear right now and subject to future study and development. Also, if we revise this section as suggested above, Section 4 will have to be adjusted, too, since we can't (yet) claim secure DHCPv6 solves the "flaws" of the existing mechanisms. - Section 5.4: [...] In enterprise network, the security policy is strict and the clients are stable terminals. The PKI model is used What does 'stable' mean? A desktop PC would be considered a "stable terminal", but what about laptops? How about smart phones connected to the enterprise network based on the BYOD policy? - Section 6 For the security DHCPv6 client, it must have a public certificate. What does "*public* certificate" mean? Does that mean it's not "private"? Same for Section 7. - Section 6 [...] The Information-request message MUST NOT include any option which may reveal the private information of the client, such as the client identifier option. I suggest adding "...or the certificate option". - Section 6 non-security options assigned to it. The Option Request option in the Information-request message MUST contain the option code of certificate option, signature option, timestamp option, and server identifier option. Should we really need to include all of these? The certificate option should surely be specified, but the need for the others seem to be almost automatically derived from the specification. - Section 6 [...] The client SHOULD also use the same algorithms in the return messages. It's not very clear to me what "return messages" mean (as the client is usually the initiator of DHCP exchanges). Perhaps "in subsequent messages (of the same DHCPv6 session)"? - Section 6 [...] Depending on its policy, it can choose to connect using plain, unencrypted DHCPv6, repeat the server discovery process after certain delay or attempt to connect to a different network. What "connect to a different network" means isn't very clear to me (see also the same sense of comment on Section 5.1) - Section 6 For the received Encrypted-Response message, the client extracts the encrypted-message option and decrypts it using its private key to obtain the original DHCPv6 message. What if the client has more than one key pair (see also the higher level comment above)? Is it assumed to associate transaction-id to a particular key? - Section 6 o Upon receiving a SignatureFail error status code, the client MAY resend the message following normal retransmission routines defined in [RFC3315]. What's the rationale of this behavior? - Section 7 If the server does not send the timestamp option, the client ignores the timestamp check and verifies the signature. If there is a [...] I don't understand the role of the first sentence in this context. - Section 7 [...] Depending on server's local policy, the message without a Timestamp option MAY be acceptable or rejected. If the server rejects such a message, a TimestampFail error status code, defined in Section 10.3, should be sent back to the client. [...] To be sure: is the TimestampFail supposed to be returned when a message from the client doesn't have Timestamp but the server wanted it? - Section 8 [...] Actually, by definition in this document, relay agents SHOULD NOT add any secure DHCPv6 options. Why is this a "SHOULD NOT", i.e. can't this be "MUST NOT"? - Section 10.1.2 Note: if both signature and authentication option are present, signature option does not protect the Authentication Option. It Should we still worry about it? The only possible reason for having both that I can see is to allow a newer client implementation to work with both new and old server implementations. But now that the message is encrypted in a way that older implementations don't understand, it's completely impossible anymore. I think we can now simply say Authentication Option shouldn't be used with Secure DHCPv6 (and if it's used the behavior is undefined). - Section 10.1.3 Timestamp The current time of day (SeND-format timestamp in UTC (Coordinated Universal Time). It can reduce the danger of replay attacks. I'd add a reference to the SeND RFC here. - Section 10.2.1 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | msg-type | transaction-id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . DUID . | (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Why is the DUID dedicated field, instead of using the server identifier option? There are other types of messages that require a server identifier option (e.g., RENEW), but they don't make it a separate field. I don't see any reason how this case is different, and using a separate format will make implementations unnecessarily complicated. Editorial nits: - Section 4: this sentence at least misses a period (I'm not sure if it's terminated with 'improved' or some other text was expected after that). [...] The basic DHCPv6 specification [RFC3315] defines security mechanisms, but they have significant flaws and can be improved - Section 5.1: s/authentication, MUST/authentication MUST/ key. The message that fails client authentication, MUST be dropped. And the server sends the corresponding error status code to client. - Section 6: s/security/Secure/ For the security DHCPv6 client, it must have a public certificate. - Section 7: s/pre-configured/pre-configured with/ The server may be pre-configured a public key certificate, which is - Section 7: s/replies/replies with/ (same for some other use cases of 'reply') server authentication information, it replies the Reply message to - Section 8 s/describes/described/ [...] The unknown messages MUST be forwarded as describes in [RFC7283]. - Section 10.1.2 s/be/be in/ [...] The signature option could be any place within the DHCPv6 message while it is logically created - Section 10.1.2 s/chose not/chose not to/ Also, this sentence(-like) seems grammatically broken but I have no idea about how to fix it. changing auth option, the authors chose not include authentication option in the signature. From nobody Sun Jan 10 13:53:57 2016 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 344FD1A037B; Sun, 10 Jan 2016 13:53:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 8OHwVsGY6Ino; Sun, 10 Jan 2016 13:53:50 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 518801A0378; Sun, 10 Jan 2016 13:53:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0AA94BE39; Sun, 10 Jan 2016 21:53:42 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ae646a1Vwcz; Sun, 10 Jan 2016 21:53:39 +0000 (GMT) Received: from [10.87.48.91] (unknown [86.46.21.60]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3E166BE38; Sun, 10 Jan 2016 21:53:39 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1452462819; bh=x2Uu0vSK8nBknouxrG+CBJUCYVW80qgQ/x5Z5D60tVY=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=DF5nDSuu5101Shwwaj5HqTlDOgW+fasay6mimsujXx4PgUUjfV4ok6k3lgZFgo+ki KDyZ6NRZErqlmMUnDBWl3boOqVF0I86yNh+OMXH0LAz/mAtJ9ZoAb+a4I/hDkcDLJJ R8Fyz53tE/Z5snuCNIwruBAXAz8aIJk9o8R5m58I= To: "Sri Gundavelli (sgundave)" References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Enigmail-Draft-Status: N1110 Message-ID: <5692D2E0.3030607@cs.tcd.ie> Date: Sun, 10 Jan 2016 21:53:36 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "Bernie Volz \(volz\)" , "dhc-chairs@ietf.org" , "draft-ietf-dhc-access-network-identifier.shepherd@ietf.org" , IESG , "draft-ietf-dhc-access-network-identifier.ad@ietf.org" , "" , "draft-ietf-dhc-access-network-identifier@ietf.org" Subject: Re: [dhcwg] Stephen Farrell's Discuss on draft-ietf-dhc-access-network-identifier-10: (with DISCUSS) 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: Sun, 10 Jan 2016 21:53:53 -0000 Hi Sri, Sorry for the slow response, I see you've posted -11 so this response is based on the diff from -10 to -11. Apologies if I've lost some context over the holidays, but I'm sure we can re-establish that quickly enough. On 14/12/15 17:18, Sri Gundavelli (sgundave) wrote: > > > > From: Sri Gundavelli > > Date: Tuesday, December 8, 2015 at 3:06 PM To: Stephen Farrell > > Cc: > "Bernie Volz (volz)" >, IESG > >, > "dhc-chairs@ietf.org" > >, > "draft-ietf-dhc-access-network-identifier.shepherd@ietf.org" > >, > "draft-ietf-dhc-access-network-identifier.ad@ietf.org" > >, > "draft-ietf-dhc-access-network-identifier@ietf.org" > >, > Brian Haberman > >, > ">" > > Subject: Re: Ben Campbell's > Discuss on draft-ietf-dhc-access-network-identifier-10: (with > DISCUSS) > > Hi Stephen, > > Thank you for your review. We probably addressed most of these issues > as part of addressing Alissa's comments as there is overlap. Any > case, please let us know if you are not happy with the changes. I note that Alissa hasn't yet cleared her discuss and her mail from Dec 8th didn't seem to indicate that was about to happen. (Though the direction in which the discussion seems to be heading looks good.) > > > > (1) Did the DHC working group consider how this information, when > sent without adequate protection between relay and dhcp server, could > help in pervasive monitoring? If so, what was the conclusion reached? > We have seen http header field information sent between > infrastructure nodes being intercepted for that purpose, so this has > to be similarly at risk. If the answer is that this is only to be > used within a single network operator's setup (or a roaming > arrangement) then that needs to be justified (as practical) and, if > it can be justified (I'm not sure tbh), also made explicit. > > [Sri] I believe this issue is now resolved after discussions with > Alissa Cooper and the newly agreed text that introduces the "same > operator" assumption. Sorry, it's not clear to me that it does. Can you explain how the addition of "collocated" in section 2 resolves this? (Or if I got the change wrong, can you say what change addresses the issue?) > > > (2) I had a DISCUSS on the draft that became rfc 6757 about > protection of this kind of data. In that context I think I was > assured that everything (in PMIPv6) was IPsec protected so it was > fine. Why, in what we now know is a more threated environment, is it > ok to now have weaker protection when I was assured then that IPsec > was in fact quite usable in PMIPv6? I think you maybe need to put in > a MUST use IPsec requirement for this to be as safe. > > > [Sri] No, its not. We are still identifying the information that is > at risk in certain operating environments. We are also listing the > tools that operator has their disposal as per the below text. The > question is that determination on when the information is at risk, if > its an operator call, or IETF call. I'm OK, but I will let Bernie and > other DHCP experts comment on this MUST requirement. > > > "In deployments where this information is considered secure and when > such threat cannot be mitigated using IPsec [RFC4301] or other > security protocols, then the administrators have to consider > disabling the capability specified in this document on the DHCP > entities." Again, sorry for the loss of context, but I'm not getting how that addition resolves the issue, can you explain? > > (3) section 7: MAY store - this is possibly sensitive information so > you ought say that it SHOULD NOT be stored unless needed, and if > stored, SHOULD be deleted as soon as possible. Storing sensitive > information when not needed just shouldn't be considered acceptable > anymore I think - is that reasonable? > > > [Sri] Ok. > > Looking at RFC 7268, SSID (Network-Id-Name attribute) can be present > in accounting records. So, this information is stored by network > functions. I don't see a change in section 7 - are you saying that none is needed? Thanks and sorry again for the loss of context, Cheers, S. > > > > * > > I (strongly) support Alissa's DISCUSS and will be interested in > watching how that is resolved. Some of my DISCUSS points do overlap > though so from my POV feel free to mix'n'match the discussions. Or to > process first one then the other, whatever you think is best. > > > > [Sri] We resolved it; hope you are OK with the conclusion. > > - RFC6757 defines exactly this for PMIPv6. That implies that PMIPv6 > should not be used to illustrate or motivate this, as that problem is > solved. Perhaps you would be better off if you limited the scope of > this to be used for networks that are some kind of extension to > PMIPv6 only? (You'd need to define what kind I think.) > > [Sri] I believe with all the text around "single operator", "IPsec" > and other assumptions, I think we have resolved this issue. > > Thanks for the reviews. > > Regards Sri > > From nobody Mon Jan 11 07:13:16 2016 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 37D111A0218; Mon, 11 Jan 2016 07:13:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 7oO9eMuUP7Ro; Mon, 11 Jan 2016 07:13:11 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 432CB1A0233; Mon, 11 Jan 2016 07:13:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14004; q=dns/txt; s=iport; t=1452525191; x=1453734791; h=from:to:cc:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=LOuMANURJSmhQZ9T4WbIExHW/s+OTDwVtEEJe9JAEJA=; b=REbd2/zZIutWxICVbaq1vQDF9L2zGiTOsQ3KcdgWyimEEqKhoWYaMglm sAfm64G7BmcnliWu83MTkKU2DbxAwQTi0CbHtCnIuJqutIOdSkNbc9XM+ rrkETCFaAGj64YlE2TikJI74TXcbSi8G49u9sRBwzzmtZyk5IMMpqRTMc I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAgBYxZNW/5pdJa1egzpSbQaIU7FOg?= =?us-ascii?q?hMBDYFmIoVtHoEHOBQBAQEBAQEBgQqENAEBAQQ0MwQOEAIBCBEDAQIBBCMFAgI?= =?us-ascii?q?wFAkIAgQOBYguDpF8nS4GkAIBAQEBAQEBAQEBAQEBAQEBAQEXBHuFW4N7gQSEJ?= =?us-ascii?q?goGAgEFFxgWDAKCXIFPBY0/hVGEAwGNWIFehEODKoUyil6DcgEgAQFCggwFHB2?= =?us-ascii?q?BQHIBhFxDgQgBAQE?= X-IronPort-AV: E=Sophos;i="5.20,553,1444694400"; d="scan'208";a="224729571" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jan 2016 15:13:10 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u0BFDAH7027735 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 11 Jan 2016 15:13:10 GMT Received: from xch-aln-007.cisco.com (173.36.7.17) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 11 Jan 2016 09:13:09 -0600 Received: from xch-aln-007.cisco.com ([173.36.7.17]) by XCH-ALN-007.cisco.com ([173.36.7.17]) with mapi id 15.00.1104.009; Mon, 11 Jan 2016 09:13:09 -0600 From: "Sri Gundavelli (sgundave)" To: Stephen Farrell Thread-Topic: Stephen Farrell's Discuss on draft-ietf-dhc-access-network-identifier-10: (with DISCUSS) Thread-Index: AQHRTGmPaG22P+82zkStEz8DB3NxeZ72J3AA Date: Mon, 11 Jan 2016 15:13:09 +0000 Message-ID: References: <5692D2E0.3030607@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.70.99] Content-Type: text/plain; charset="euc-kr" Content-ID: <085E63D43F01314D8B49CAA226643660@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "Bernie Volz \(volz\)" , "dhc-chairs@ietf.org" , "draft-ietf-dhc-access-network-identifier.shepherd@ietf.org" , IESG , "draft-ietf-dhc-access-network-identifier.ad@ietf.org" , "" , "draft-ietf-dhc-access-network-identifier@ietf.org" Subject: Re: [dhcwg] Stephen Farrell's Discuss on draft-ietf-dhc-access-network-identifier-10: (with DISCUSS) 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 Jan 2016 15:13:14 -0000 SGkgU3RlcGhlbiwNCg0KVGhhbmsgeW91IGZvciB5b3VyIHJlc3BvbnNlLg0KDQoNCk9uIDEvMTAv MTYsIDE6NTMgUE0sICJTdGVwaGVuIEZhcnJlbGwiIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmll PiB3cm90ZToNCg0KPg0KPkhpIFNyaSwNCj4NCj5Tb3JyeSBmb3IgdGhlIHNsb3cgcmVzcG9uc2Us IEkgc2VlIHlvdSd2ZSBwb3N0ZWQgLTExIHNvIHRoaXMNCj5yZXNwb25zZSBpcyBiYXNlZCBvbiB0 aGUgZGlmZiBmcm9tIC0xMCB0byAtMTEuIEFwb2xvZ2llcyBpZg0KPkkndmUgbG9zdCBzb21lIGNv bnRleHQgb3ZlciB0aGUgaG9saWRheXMsIGJ1dCBJJ20gc3VyZSB3ZSBjYW4NCj5yZS1lc3RhYmxp c2ggdGhhdCBxdWlja2x5IGVub3VnaC4NCg0KDQpOb3QgYW4gaXNzdWUuIEkgdW5kZXJzdGFuZCwg aXQgd2FzIHRoZSBob2xpZGF5IGJyZWFrLiBJIGhhZCB0aGUgc2FtZQ0KaXNzdWUsIEkgbmVlZCB0 byBjbG9zZSBvbmUgdGhyZWFkLg0KDQoNCg0KPg0KPk9uIDE0LzEyLzE1IDE3OjE4LCBTcmkgR3Vu ZGF2ZWxsaSAoc2d1bmRhdmUpIHdyb3RlOg0KPj4gPFJlc2VuZGluZyB3aXRoIHRoZSBjb3JyZWN0 IHN1YmplY3QgbGluZT4NCj4+IA0KPj4gDQo+PiBGcm9tOiBTcmkgR3VuZGF2ZWxsaSA8c2d1bmRh dmVAY2lzY28uY29tPG1haWx0bzpzZ3VuZGF2ZUBjaXNjby5jb20+Pg0KPj4gRGF0ZTogVHVlc2Rh eSwgRGVjZW1iZXIgOCwgMjAxNSBhdCAzOjA2IFBNIFRvOiBTdGVwaGVuIEZhcnJlbGwNCj4+IDxz dGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPG1haWx0bzpzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmll Pj4gQ2M6DQo+PiAiQmVybmllIFZvbHogKHZvbHopIiA8dm9sekBjaXNjby5jb208bWFpbHRvOnZv bHpAY2lzY28uY29tPj4sIElFU0cNCj4+IDxpZXNnQGlldGYub3JnPG1haWx0bzppZXNnQGlldGYu b3JnPj4sDQo+PiAiZGhjLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86ZGhjLWNoYWlyc0BpZXRmLm9y Zz4iDQo+PiA8ZGhjLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86ZGhjLWNoYWlyc0BpZXRmLm9yZz4+ LA0KPj4gDQo+PiJkcmFmdC1pZXRmLWRoYy1hY2Nlc3MtbmV0d29yay1pZGVudGlmaWVyLnNoZXBo ZXJkQGlldGYub3JnPG1haWx0bzpkcmFmdC0NCj4+aWV0Zi1kaGMtYWNjZXNzLW5ldHdvcmstaWRl bnRpZmllci5zaGVwaGVyZEBpZXRmLm9yZz4iDQo+PiANCj4+PGRyYWZ0LWlldGYtZGhjLWFjY2Vz cy1uZXR3b3JrLWlkZW50aWZpZXIuc2hlcGhlcmRAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LQ0KPj5p ZXRmLWRoYy1hY2Nlc3MtbmV0d29yay1pZGVudGlmaWVyLnNoZXBoZXJkQGlldGYub3JnPj4sDQo+ PiANCj4+ImRyYWZ0LWlldGYtZGhjLWFjY2Vzcy1uZXR3b3JrLWlkZW50aWZpZXIuYWRAaWV0Zi5v cmc8bWFpbHRvOmRyYWZ0LWlldGYtZA0KPj5oYy1hY2Nlc3MtbmV0d29yay1pZGVudGlmaWVyLmFk QGlldGYub3JnPiINCj4+IA0KPj48ZHJhZnQtaWV0Zi1kaGMtYWNjZXNzLW5ldHdvcmstaWRlbnRp Zmllci5hZEBpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1kDQo+PmhjLWFjY2Vzcy1uZXR3b3Jr LWlkZW50aWZpZXIuYWRAaWV0Zi5vcmc+PiwNCj4+IA0KPj4iZHJhZnQtaWV0Zi1kaGMtYWNjZXNz LW5ldHdvcmstaWRlbnRpZmllckBpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1kaGMtDQo+PmFj Y2Vzcy1uZXR3b3JrLWlkZW50aWZpZXJAaWV0Zi5vcmc+Ig0KPj4gDQo+PjxkcmFmdC1pZXRmLWRo Yy1hY2Nlc3MtbmV0d29yay1pZGVudGlmaWVyQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWRo Yy0NCj4+YWNjZXNzLW5ldHdvcmstaWRlbnRpZmllckBpZXRmLm9yZz4+LA0KPj4gQnJpYW4gSGFi ZXJtYW4NCj4+IDxicmlhbkBpbm5vdmF0aW9uc2xhYi5uZXQ8bWFpbHRvOmJyaWFuQGlubm92YXRp b25zbGFiLm5ldD4+LA0KPj4gIjxkaGN3Z0BpZXRmLm9yZzxtYWlsdG86ZGhjd2dAaWV0Zi5vcmc+ PiINCj4+IDxkaGN3Z0BpZXRmLm9yZzxtYWlsdG86ZGhjd2dAaWV0Zi5vcmc+PiBTdWJqZWN0OiBS ZTogQmVuIENhbXBiZWxsJ3MNCj4+IERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1kaGMtYWNjZXNzLW5l dHdvcmstaWRlbnRpZmllci0xMDogKHdpdGgNCj4+IERJU0NVU1MpDQo+PiANCj4+IEhpIFN0ZXBo ZW4sDQo+PiANCj4+IFRoYW5rIHlvdSBmb3IgeW91ciByZXZpZXcuIFdlIHByb2JhYmx5IGFkZHJl c3NlZCBtb3N0IG9mIHRoZXNlIGlzc3Vlcw0KPj4gYXMgcGFydCBvZiBhZGRyZXNzaW5nIEFsaXNz YSdzIGNvbW1lbnRzIGFzIHRoZXJlIGlzIG92ZXJsYXAuIEFueQ0KPj4gY2FzZSwgcGxlYXNlIGxl dCB1cyBrbm93IGlmIHlvdSBhcmUgbm90IGhhcHB5IHdpdGggdGhlIGNoYW5nZXMuDQo+DQo+SSBu b3RlIHRoYXQgQWxpc3NhIGhhc24ndCB5ZXQgY2xlYXJlZCBoZXIgZGlzY3VzcyBhbmQgaGVyIG1h aWwNCj5mcm9tIERlYyA4dGggZGlkbid0IHNlZW0gdG8gaW5kaWNhdGUgdGhhdCB3YXMgYWJvdXQg dG8gaGFwcGVuLg0KPihUaG91Z2ggdGhlIGRpcmVjdGlvbiBpbiB3aGljaCB0aGUgZGlzY3Vzc2lv biBzZWVtcyB0byBiZSBoZWFkaW5nDQo+bG9va3MgZ29vZC4pDQoNCg0KW1NyaV0gV2UgcG9zdGVk IHRoZSB1cGRhdGVkIHZlcnNpb24ganVzdCBjb3VwbGUgb2YgZGF5cyBiYWNrLiBNeSBkcmFmdA0K ZWRpdG9yIGRpZCBtaXNzIG9uZSBlbWFpbCBhbmQgbWlzc2VkIHNvbWUgYWdyZWVkIHRleHQuIEJ1 dCwgbXkNCnVuZGVyc3RhbmRpbmcgaXMgdGhhdCB3ZSBoYXZlIGFuIGFncmVlbWVudCB3aXRoIEFs aXNzYSBvbiB0aGUgdGV4dC4gSSByZWFkDQp0aGUgdGhyZWFkIGFnYWluLCBhdCBsZWFzdCB0aGF0 IGlzIG15IHVuZGVyc3RhbmRpbmcuDQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2 ZS93ZWIvZGhjd2cvY3VycmVudC9tc2cxNzEzMi5odG1sDQoNCg0KDQo+DQo+PiANCj4+IA0KPj4g DQo+PiAoMSkgRGlkIHRoZSBESEMgd29ya2luZyBncm91cCBjb25zaWRlciBob3cgdGhpcyBpbmZv cm1hdGlvbiwgd2hlbg0KPj4gc2VudCB3aXRob3V0IGFkZXF1YXRlIHByb3RlY3Rpb24gYmV0d2Vl biByZWxheSBhbmQgZGhjcCBzZXJ2ZXIsIGNvdWxkDQo+PiBoZWxwIGluIHBlcnZhc2l2ZSBtb25p dG9yaW5nPyBJZiBzbywgd2hhdCB3YXMgdGhlIGNvbmNsdXNpb24gcmVhY2hlZD8NCj4+IFdlIGhh dmUgc2VlbiBodHRwIGhlYWRlciBmaWVsZCBpbmZvcm1hdGlvbiBzZW50IGJldHdlZW4NCj4+IGlu ZnJhc3RydWN0dXJlIG5vZGVzIGJlaW5nIGludGVyY2VwdGVkIGZvciB0aGF0IHB1cnBvc2UsIHNv IHRoaXMgaGFzDQo+PiB0byBiZSBzaW1pbGFybHkgYXQgcmlzay4gIElmIHRoZSBhbnN3ZXIgaXMg dGhhdCB0aGlzIGlzIG9ubHkgdG8gYmUNCj4+IHVzZWQgd2l0aGluIGEgc2luZ2xlIG5ldHdvcmsg b3BlcmF0b3IncyBzZXR1cCAob3IgYSByb2FtaW5nDQo+PiBhcnJhbmdlbWVudCkgdGhlbiB0aGF0 IG5lZWRzIHRvIGJlIGp1c3RpZmllZCAoYXMgcHJhY3RpY2FsKSBhbmQsIGlmDQo+PiBpdCBjYW4g YmUganVzdGlmaWVkIChJJ20gbm90IHN1cmUgdGJoKSwgYWxzbyBtYWRlIGV4cGxpY2l0Lg0KPj4g DQo+PiBbU3JpXSBJIGJlbGlldmUgdGhpcyBpc3N1ZSBpcyBub3cgcmVzb2x2ZWQgYWZ0ZXIgZGlz Y3Vzc2lvbnMgd2l0aA0KPj4gQWxpc3NhIENvb3BlciBhbmQgdGhlIG5ld2x5IGFncmVlZCB0ZXh0 IHRoYXQgaW50cm9kdWNlcyB0aGUgInNhbWUNCj4+IG9wZXJhdG9yIiBhc3N1bXB0aW9uLg0KPg0K PlNvcnJ5LCBpdCdzIG5vdCBjbGVhciB0byBtZSB0aGF0IGl0IGRvZXMuIENhbiB5b3UgZXhwbGFp biBob3cNCj50aGUgYWRkaXRpb24gb2YgImNvbGxvY2F0ZWQiIGluIHNlY3Rpb24gMiByZXNvbHZl cyB0aGlzPyAoT3INCj5pZiBJIGdvdCB0aGUgY2hhbmdlIHdyb25nLCBjYW4geW91IHNheSB3aGF0 IGNoYW5nZSBhZGRyZXNzZXMNCj50aGUgaXNzdWU/KQ0KDQpUaGUgaW5mb3JtYXRpb24gYXQgcmlz ayBpcyBvbiB0aGUgaW50ZXJmYWNlIGJldHdlZW4gdGhlIERIQ1AgUmVsYXkgYW5kIHRoZQ0KREhD UCBTZXJ2ZXIuIFRoZSBmdW5jdGlvbnMgaW52b2x2ZWQgaW4gdGhpcyB0cmFuc2FjdGlvbiBhbmQg aW4gdGhlIGN1cnJlbnQNCmNvbnRleHQgYXJlIGluIHRoZSBhY2Nlc3MgbmV0d29yay4gSW4gYWxs IFNQIFdpLUZpIGRlcGxveW1lbnRzIHRoZSBESENQDQpzZXJ2ZXIgaXMgaW4gdGhlIGFjY2VzcyBu ZXR3b3JrIGFuZCB3aGljaCBpcyB0aGUgTUFHL1RXQUcgYW5kIHRoZSBESENQDQpSZWxheSBpcyBv biB0aGUgV2lyZWxlc3MgVGVybWluYXRpb24gcG9pbnQvQVAuIEknbSBub3QgYXdhcmUgb2YgYW55 DQpkZXBsb3ltZW50IHdoZXJlIHRoZSBhY2Nlc3MgbmV0d29yayBpcyBvcGVyYXRlZCBieSB0d28g b3BlcmF0b3JzLiBQZXINCkFsaXNzYSdzIGNvbW1lbnQsIGlmIHdlIGhhdmUgYW4gYXBwbGljYWJp bGl0eSBub3RlIHRoYXQgc3RhdGVzIHRoaXMNCmFzc3VtcHRpb24sIEkgYXNzdW1lZCBJRVNHIGlz IE9LIHRvIGNsZWFyIHRoZSBESVNDVVNTLg0KDQoNClBlciBBbGlzc2Gp9nMgY29tbWVudDoNCiIN Cm15IHRoaW5raW5nIGlzIHRoYXQgd2hhdCB3b3VsZCBoZWxwIGhlcmUgaXMgYW4gYXBwbGljYWJp bGl0eSBzdGF0ZW1lbnQNCnRoYXQgZXhwbGFpbnMgdGhhdCB0aGVzZSBvcHRpb25zIGFyZSBiZWlu ZyBzcGVjaWZpZWQgb25seSBmb3IgdGhlIHB1cnBvc2UNCm9mIGNvbW11bmljYXRpbmcgYWNjZXNz IG5ldHdvcmsgaWRlbnRpZmljYXRpb24gYmV0d2VlbiBhIERIQ1AgcmVsYXkgYWdlbnQNCmFuZCBh IE1vYmlsZSBBY2Nlc3MgR2F0ZXdheSB3aGVyZSB0aGUgc2FtZSBvcGVyYXRvciB0eXBpY2FsbHkg b3BlcmF0ZXMNCmJvdGguqfcNCg0KIlRoZSBzY29wZSBvZiBhcHBsaWNhYmlsaXR5IGZvciB0aGlz IG9wdGlvbiBpcyBiZXR3ZWVuIGEgREhDUCByZWxheSBhZ2VudA0KYW5kIGEgTW9iaWxlIEFjY2Vz cyBHYXRld2F5IHdoZXJlIHRoZSBzYW1lIG9wZXJhdG9yIHR5cGljYWxseSBvcGVyYXRlcw0KYm90 aC4gRG8geW91IGhhdmUgZGlmZmljdWx0eSB0byBwdXQgYSBub3RlIGFib3V0IHRoaXMgbGltaXRh dGlvbiBpbiBzY29wZQ0KaW50byB0aGUgZHJhZnQ/Ig0KDQoNCk5FVzoNCiJUaGlzIGRvY3VtZW50 IHNwZWNpZmllcyBEeW5hbWljIEhvc3QgQ29uZmlndXJhdGlvbiBQcm90b2NvbCBmb3IgSVB2NA0K ICAgKERIQ1B2NCkgW1JGQzIxMzFdIGFuZCBEeW5hbWljIEhvc3QgQ29uZmlndXJhdGlvbiBQcm90 b2NvbCBmb3IgSVB2Ng0KICAgKERIQ1B2NikgW1JGQzMzMTVdIG9wdGlvbnMgZm9yIGFjY2VzcyBu ZXR3b3JrIGlkZW50aWZpY2F0aW9uIHRoYXQgaXMNCiAgIGFkZGVkIGJ5IFJlbGF5IGFnZW50IGlu IHRoZSBESENQdjQgb3IgREhDUHY2IG1lc3NhZ2VzIHRvd2FyZHMgdGhlDQogICBTZXJ2ZXIuICBU aGUgc2NvcGUgb2YgYXBwbGljYWJpbGl0eSBmb3IgdGhpcyBvcHRpb24gaXMgYmV0d2VlbiBhIERI Q1ANCnJlbGF5ICAgIGFnZW50IGFuZCBhIG1vYmlsZSBhY2Nlc3MgZ2F0ZXdheSB3aGVyZSB0aGUg c2FtZSBvcGVyYXRvcg0KdHlwaWNhbGx5DQpvcGVyYXRlcyBib3RoIHRoZXNlIGZ1bmN0aW9ucyIN Cg0KDQoNCg0KDQoNCj4NCj4+IA0KPj4gDQo+PiAoMikgSSBoYWQgYSBESVNDVVNTIG9uIHRoZSBk cmFmdCB0aGF0IGJlY2FtZSByZmMgNjc1NyBhYm91dA0KPj4gcHJvdGVjdGlvbiBvZiB0aGlzIGtp bmQgb2YgZGF0YS4gSW4gdGhhdCBjb250ZXh0IEkgdGhpbmsgSSB3YXMNCj4+IGFzc3VyZWQgdGhh dCBldmVyeXRoaW5nIChpbiBQTUlQdjYpIHdhcyBJUHNlYyBwcm90ZWN0ZWQgc28gaXQgd2FzDQo+ PiBmaW5lLiAgV2h5LCBpbiB3aGF0IHdlIG5vdyBrbm93IGlzIGEgbW9yZSB0aHJlYXRlZCBlbnZp cm9ubWVudCwgaXMgaXQNCj4+IG9rIHRvIG5vdyBoYXZlIHdlYWtlciBwcm90ZWN0aW9uIHdoZW4g SSB3YXMgYXNzdXJlZCB0aGVuIHRoYXQgSVBzZWMNCj4+IHdhcyBpbiBmYWN0IHF1aXRlIHVzYWJs ZSBpbiBQTUlQdjY/IEkgdGhpbmsgeW91IG1heWJlIG5lZWQgdG8gcHV0IGluDQo+PiBhIE1VU1Qg dXNlIElQc2VjIHJlcXVpcmVtZW50IGZvciB0aGlzIHRvIGJlIGFzIHNhZmUuDQo+PiANCj4+IA0K Pj4gW1NyaV0gTm8sIGl0cyBub3QuIFdlIGFyZSBzdGlsbCBpZGVudGlmeWluZyB0aGUgaW5mb3Jt YXRpb24gdGhhdCBpcw0KPj4gYXQgcmlzayBpbiBjZXJ0YWluIG9wZXJhdGluZyBlbnZpcm9ubWVu dHMuIFdlIGFyZSBhbHNvIGxpc3RpbmcgdGhlDQo+PiB0b29scyB0aGF0IG9wZXJhdG9yIGhhcyB0 aGVpciBkaXNwb3NhbCBhcyBwZXIgdGhlIGJlbG93IHRleHQuIFRoZQ0KPj4gcXVlc3Rpb24gaXMg dGhhdCBkZXRlcm1pbmF0aW9uIG9uIHdoZW4gdGhlIGluZm9ybWF0aW9uIGlzIGF0IHJpc2ssIGlm DQo+PiBpdHMgYW4gb3BlcmF0b3IgY2FsbCwgb3IgSUVURiBjYWxsLiBJJ20gT0ssIGJ1dCBJIHdp bGwgbGV0IEJlcm5pZSBhbmQNCj4+IG90aGVyIERIQ1AgZXhwZXJ0cyBjb21tZW50IG9uIHRoaXMg TVVTVCByZXF1aXJlbWVudC4NCj4+IA0KPj4gDQo+PiAiSW4gZGVwbG95bWVudHMgd2hlcmUgdGhp cyBpbmZvcm1hdGlvbiBpcyBjb25zaWRlcmVkIHNlY3VyZSBhbmQgd2hlbg0KPj4gc3VjaCB0aHJl YXQgY2Fubm90IGJlIG1pdGlnYXRlZCB1c2luZyBJUHNlYyBbUkZDNDMwMV0gb3Igb3RoZXINCj4+ IHNlY3VyaXR5IHByb3RvY29scywgdGhlbiB0aGUgYWRtaW5pc3RyYXRvcnMgaGF2ZSB0byBjb25z aWRlcg0KPj4gZGlzYWJsaW5nIHRoZSBjYXBhYmlsaXR5IHNwZWNpZmllZCBpbiB0aGlzIGRvY3Vt ZW50IG9uIHRoZSBESENQDQo+PiBlbnRpdGllcy4iDQo+DQo+QWdhaW4sIHNvcnJ5IGZvciB0aGUg bG9zcyBvZiBjb250ZXh0LCBidXQgSSdtIG5vdCBnZXR0aW5nIGhvdw0KPnRoYXQgYWRkaXRpb24g cmVzb2x2ZXMgdGhlIGlzc3VlLCBjYW4geW91IGV4cGxhaW4/DQoNCg0KQm90aCBpbiBSRkMgNjc1 NyBhbmQgaW4gdGhlIGJlbG93IGRvY3VtZW50LCB3ZSBoYXZlIGlkZW50aWZpZWQgdGhlDQppbmZv cm1hdGlvbiB3aGljaCBpcyBhdCByaXNrIGFuZCB0aGUgdG9vbHMgdGhhdCBjYW4gYmUgdXNlZCB0 byBwcm90ZWN0IGl0Lg0KSSB0aG91Z2ggd2UgYXJlIGNvbnNpc3Qgd2l0aCByZXNwZWN0IHRvIElQ c2VjIHVzZS4NCg0KDQpIZXJlIGlzIHRoZSB0ZXh0IGZyb20gUkZDIDY3NTc6DQoNCiJUaGUgR2Vv LUxvY2F0aW9uIHN1Yi1vcHRpb24gY2FycmllZCBpbiB0aGUgQWNjZXNzIE5ldHdvcmsgSW5mb3Jt YXRpb24NCiAgIG9wdGlvbiBleHBvc2VzIHRoZSBnZW8tbG9jYXRpb24gb2YgdGhlIG5ldHdvcmsg dG8gd2hpY2ggdGhlIG1vYmlsZQ0KICAgbm9kZSBpcyBhdHRhY2hlZC4gIFRoaXMgaW5mb3JtYXRp b24gaXMgY29uc2lkZXJlZCB0byBiZSB2ZXJ5DQogICBzZW5zaXRpdmUsIHNvIGNhcmUgbXVzdCBi ZSB0YWtlbiB0byBzZWN1cmUgdGhlIFByb3h5IE1vYmlsZSBJUHY2DQogICBzaWduYWxpbmcgbWVz c2FnZXMgd2hlbiBjYXJyeWluZyB0aGlzIHN1Yi1vcHRpb24uICBUaGUgYmFzZSBQcm94eQ0KICAg TW9iaWxlIElQdjYgc3BlY2lmaWNhdGlvbiBbUkZDNTIxM10gc3BlY2lmaWVzIHRoZSB1c2Ugb2Yg SVBzZWMgZm9yDQogICBzZWN1cmluZyB0aGUgc2lnbmFsaW5nIG1lc3NhZ2VzLCBhbmQgdGhvc2Ug bWVjaGFuaXNtcyBjYW4gYmUgZW5hYmxlZA0KICAgZm9yIHByb3RlY3RpbmcgdGhpcyBpbmZvcm1h dGlvbi4gIE9wZXJhdG9ycyBjYW4gcG90ZW50aWFsbHkgYXBwbHkNCiAgIElQc2VjIEVuY2Fwc3Vs YXRpbmcgU2VjdXJpdHkgUGF5bG9hZCAoRVNQKSB3aXRoIGNvbmZpZGVudGlhbGl0eSBhbmQNCiAg IGludGVncml0eSBwcm90ZWN0aW9uIGZvciBwcm90ZWN0aW5nIHRoZSBsb2NhdGlvbiBpbmZvcm1h dGlvbi4iDQoNCg0KDQpIZXJlIGlzIHRoZSB0ZXh0IGZyb20gdGhlIGN1cnJlbnQgZHJhZnQ6DQoN CiJJbiBkZXBsb3ltZW50cyB3aGVyZSB0aGlzIGluZm9ybWF0aW9uIGlzIGNvbnNpZGVyZWQgc2Vj dXJlIGFuZCB3aGVuDQpzdWNoIHRocmVhdCBjYW5ub3QgYmUgbWl0aWdhdGVkIHVzaW5nIElQc2Vj IFtSRkM0MzAxXSBvciBvdGhlcg0Kc2VjdXJpdHkgcHJvdG9jb2xzLCB0aGVuIHRoZSBhZG1pbmlz dHJhdG9ycyBoYXZlIHRvIGNvbnNpZGVyDQpkaXNhYmxpbmcgdGhlIGNhcGFiaWxpdHkgc3BlY2lm aWVkIGluIHRoaXMgZG9jdW1lbnQgb24gdGhlIERIQ1ANCmVudGl0aWVzLiINCg0KDQoNClJGQyA1 MjEzOg0KDQpJUHNlYyBpcyBhIG1hbmRhdG9yeS10by1pbXBsZW1lbnQgc2VjdXJpdHkNCm1lY2hh bmlzbS4gSG93ZXZlciwgYWRkaXRpb25hbCBkb2N1bWVudHMgbWF5IHNwZWNpZnkgYWx0ZXJuYXRp dmUNCm1lY2hhbmlzbXMgYW5kIHRoZSBtb2JpbGl0eSBlbnRpdGllcyBjYW4gZW5hYmxlIGEgc3Bl Y2lmaWMgbWVjaGFuaXNtDQpmb3Igc2VjdXJpbmcgUHJveHkgTW9iaWxlIElQdjYgc2lnbmFsaW5n IG1lc3NhZ2VzLCBiYXNlZCBvbiBlaXRoZXIgYQ0Kc3RhdGljIGNvbmZpZ3VyYXRpb24gb3IgYWZ0 ZXIgYSBkeW5hbWljIG5lZ290aWF0aW9uIHVzaW5nIGFueQ0Kc3RhbmRhcmQgc2VjdXJpdHkgbmVn b3RpYXRpb24gcHJvdG9jb2xzLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQo+DQo+PiANCj4+ ICgzKSBzZWN0aW9uIDc6IE1BWSBzdG9yZSAtIHRoaXMgaXMgcG9zc2libHkgc2Vuc2l0aXZlIGlu Zm9ybWF0aW9uIHNvDQo+PiB5b3Ugb3VnaHQgc2F5IHRoYXQgaXQgU0hPVUxEIE5PVCBiZSBzdG9y ZWQgdW5sZXNzIG5lZWRlZCwgYW5kIGlmDQo+PiBzdG9yZWQsIFNIT1VMRCBiZSBkZWxldGVkIGFz IHNvb24gYXMgcG9zc2libGUuIFN0b3Jpbmcgc2Vuc2l0aXZlDQo+PiBpbmZvcm1hdGlvbiB3aGVu IG5vdCBuZWVkZWQganVzdCBzaG91bGRuJ3QgYmUgY29uc2lkZXJlZCBhY2NlcHRhYmxlDQo+PiBh bnltb3JlIEkgdGhpbmsgLSBpcyB0aGF0IHJlYXNvbmFibGU/DQo+PiANCj4+IA0KPj4gW1NyaV0g T2suDQo+PiANCj4+IExvb2tpbmcgYXQgUkZDIDcyNjgsIFNTSUQgKE5ldHdvcmstSWQtTmFtZSBh dHRyaWJ1dGUpIGNhbiBiZSBwcmVzZW50DQo+PiBpbiBhY2NvdW50aW5nIHJlY29yZHMuIFNvLCB0 aGlzIGluZm9ybWF0aW9uIGlzIHN0b3JlZCBieSBuZXR3b3JrDQo+PiBmdW5jdGlvbnMuDQo+DQo+ SSBkb24ndCBzZWUgYSBjaGFuZ2UgaW4gc2VjdGlvbiA3IC0gYXJlIHlvdSBzYXlpbmcgdGhhdCBu b25lDQo+aXMgbmVlZGVkPw0KDQoNClllcy4gVGhpcyBuZWVkcyB0byBnbyBpbi4gU29ycnkgYWJv dXQgdGhhdC4NCg0KDQpSZWdhcmRzDQpTcmkNCg0KDQoNCg0KDQo+DQo+VGhhbmtzIGFuZCBzb3Jy eSBhZ2FpbiBmb3IgdGhlIGxvc3Mgb2YgY29udGV4dCwNCj5DaGVlcnMsDQo+Uy4NCj4NCj4NCj4+ IA0KPj4gDQo+PiANCj4+ICoNCj4+IA0KPj4gSSAoc3Ryb25nbHkpIHN1cHBvcnQgQWxpc3NhJ3Mg RElTQ1VTUyBhbmQgd2lsbCBiZSBpbnRlcmVzdGVkIGluDQo+PiB3YXRjaGluZyBob3cgdGhhdCBp cyByZXNvbHZlZC4gU29tZSBvZiBteSBESVNDVVNTIHBvaW50cyBkbyBvdmVybGFwDQo+PiB0aG91 Z2ggc28gZnJvbSBteSBQT1YgZmVlbCBmcmVlIHRvIG1peCduJ21hdGNoIHRoZSBkaXNjdXNzaW9u cy4gT3IgdG8NCj4+IHByb2Nlc3MgZmlyc3Qgb25lIHRoZW4gdGhlIG90aGVyLCB3aGF0ZXZlciB5 b3UgdGhpbmsgaXMgYmVzdC4NCj4+IA0KPj4gDQo+PiANCj4+IFtTcmldIFdlIHJlc29sdmVkIGl0 OyBob3BlIHlvdSBhcmUgT0sgd2l0aCB0aGUgY29uY2x1c2lvbi4NCj4+IA0KPj4gLSBSRkM2NzU3 IGRlZmluZXMgZXhhY3RseSB0aGlzIGZvciBQTUlQdjYuIFRoYXQgaW1wbGllcyB0aGF0IFBNSVB2 Ng0KPj4gc2hvdWxkIG5vdCBiZSB1c2VkIHRvIGlsbHVzdHJhdGUgb3IgbW90aXZhdGUgdGhpcywg YXMgdGhhdCBwcm9ibGVtIGlzDQo+PiBzb2x2ZWQuIFBlcmhhcHMgeW91IHdvdWxkIGJlIGJldHRl ciBvZmYgaWYgeW91IGxpbWl0ZWQgdGhlIHNjb3BlIG9mDQo+PiB0aGlzIHRvIGJlIHVzZWQgZm9y IG5ldHdvcmtzIHRoYXQgYXJlIHNvbWUga2luZCBvZiBleHRlbnNpb24gdG8NCj4+IFBNSVB2NiBv bmx5PyAoWW91J2QgbmVlZCB0byBkZWZpbmUgd2hhdCBraW5kIEkgdGhpbmsuKQ0KPj4gDQo+PiBb U3JpXSBJIGJlbGlldmUgd2l0aCBhbGwgdGhlIHRleHQgYXJvdW5kICJzaW5nbGUgb3BlcmF0b3Ii LCAiSVBzZWMiDQo+PiBhbmQgb3RoZXIgYXNzdW1wdGlvbnMsIEkgdGhpbmsgd2UgaGF2ZSByZXNv bHZlZCB0aGlzIGlzc3VlLg0KPj4gDQo+PiBUaGFua3MgZm9yIHRoZSByZXZpZXdzLg0KPj4gDQo+ PiBSZWdhcmRzIFNyaQ0KPj4gDQo+PiANCg0KDQo= From nobody Tue Jan 12 05:15:27 2016 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 A20CF1AD1EE; Tue, 12 Jan 2016 05:15:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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.001, 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 mb0K93F1k0EY; Tue, 12 Jan 2016 05:15:23 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF95C1AD1DB; Tue, 12 Jan 2016 05:15:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14779; q=dns/txt; s=iport; t=1452604522; x=1453814122; h=from:to:cc:subject:date:message-id:mime-version; bh=Mg0NhIV0vs14MHq/AOdlXivMLLctWqvFLEJa2lBPTQc=; b=TrvP37cQHKqs02a0Fdgesjpm1HvQTg/yCWrVCOUXbrcGETA9WyN0vg8g 6uFYrX0bNOhXNCEhvzNbMyVbEynImco5FMrG9gy6yeB+ZP8nAlBtCAG3o 60b9p8RerDs6C3ePwZ+7eZ9df3TE+IL5A1zYxT6YdTn/kp16cABuW54mX U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAgA7+5RW/5BdJa1UCoJuTFJziFOzJ?= =?us-ascii?q?wENgWaGD4EnOBQBAQEBAQEBfwuENwQtTBIBgQAmAQQODYgmv2ABAQEBAQEBAQI?= =?us-ascii?q?BAQEBAQEBAQEakAEShH8Fh2CHE4QdhAMBgQ6MQ48DjlIBIAEBQoIRHIFdhVgkH?= =?us-ascii?q?4EIAQEB?= X-IronPort-AV: E=Sophos;i="5.20,557,1444694400"; d="scan'208,217";a="226674285" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jan 2016 13:15:21 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u0CDFLXL010132 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 12 Jan 2016 13:15:21 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 12 Jan 2016 07:15:21 -0600 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1104.009; Tue, 12 Jan 2016 07:15:20 -0600 From: "Bernie Volz (volz)" To: "draft-ietf-dhc-dhcpv6-privacy@ietf.org" Thread-Topic: Minor issue in draft-ietf-dhc-dhcpv6-privacy-02 Thread-Index: AdFNOwRKD7rEdtcxTuiAHkRh2E9YBg== Date: Tue, 12 Jan 2016 13:15:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.240.42] Content-Type: multipart/alternative; boundary="_000_a68466a6f26945b593756a60ac149c5aXCHALN003ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "dhcwg@ietf.org" Subject: [dhcwg] Minor issue in draft-ietf-dhc-dhcpv6-privacy-02 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, 12 Jan 2016 13:15:25 -0000 --_000_a68466a6f26945b593756a60ac149c5aXCHALN003ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi: In my review for the shepherd write-up, I noticed the following in 4.1 Temp= orary addresses: However, in section 18.1.3 it explicitly mentions that temporary addresses can be renewed. Client implementations may mistakenly renew temporary addresses if they are not careful (i.e., by including the IA_TA with the same IAID in Renew or Rebind requests, rather than a new IAID - see [RFC3315] Section 22.5), thus forfeiting short Per RFC 3315 section 22.5: An IA_TA option does not include values for T1 and T2. A client MAY request that the lifetimes on temporary addresses be extended by including the addresses in a IA_TA option sent in a Renew or Rebind message to a server. For example, a client would request an extension on the lifetime of a temporary address to allow an application to continue to use an established TCP connection. ... A server MUST return the same set of temporary address for the same IA_TA (as identified by the IAID) as long as those addresses are still valid. After the lifetimes of the addresses in an IA_TA have expired, the IAID may be reused to identify a new IA_TA with new temporary addresses. This text says to EXTEND lifetimes, a client MUST include the addresses (IA= ADDR options). Just sending an IA_TA itself causes the server to return the= existing address(es) if still valid (or new ones if not), but does NOT res= ult in extending the lifetimes. (I agree that this subtle distinction could= be lost on many [server] implementations.) The text in 18.1.3 does indicate that to Renew, one includes the IAADDR opt= ion(s). So, it may be that the text in the draft is technically OK. I think thought that the draft text: Client implementations may mistakenly renew temporary addresses if they are not careful (i.e., by including the IA_TA with the same IAID in Renew or Rebind requests, rather than a new IAID - see [RFC3315] Section 22.5), Is what is technically wrong as it isn't just including the IA_TA with the = same IAID, but also by including the addresses. My suggestion is: Drop "i.e= ., by including the IA_TA with the same IAID in Renew or Rebind requests, r= ather than a new IAID -". This way you just refer people to Section 22.5 fo= r how to do this. Not sure this is worth a respin. It may be better for me to point out this = issue and send the document to the AD for now as the AD review may turn up = a few other issues? We can respin before sending off to IESG itself? - Bernie --_000_a68466a6f26945b593756a60ac149c5aXCHALN003ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi:

 

In my review for the shepherd write-up, I noticed th= e following in 4.1 Temporary addresses:

 

=    However, in section 18.1.3 it explicitly mentions that tempora= ry

=    addresses can be renewed.  Client implementations may mis= takenly

=    renew temporary addresses if they are not careful (i.e., by in= cluding

=    the IA_TA with the same IAID in Renew or Rebind requests, rath= er than

=    a new IAID - see [RFC3315] Section 22.5), thus forfeiting shor= t

 

Per RFC 3315 section 22.5:

 

   An IA_TA option does not include= values for T1 and T2.  A client MAY

   request that the lifetimes on te= mporary addresses be extended by

   including the addresses in a IA_= TA option sent in a Renew or Rebind

   message to a server.  For e= xample, a client would request an

   extension on the lifetime of a t= emporary address to allow an

   application to continue to use a= n established TCP connection.

…

   A server MUST return the same se= t of temporary address for the same

   IA_TA (as identified by the IAID= ) as long as those addresses are

   still valid.  After the lif= etimes of the addresses in an IA_TA have

   expired, the IAID may be reused = to identify a new IA_TA with new

=    temporary addresses.

 

This text says to EXTEND lifetimes, a client MUST in= clude the addresses (IAADDR options). Just sending an IA_TA itself causes t= he server to return the existing address(es) if still valid (or new ones if= not), but does NOT result in extending the lifetimes. (I agree that this subtle distinction could be lost on many= [server] implementations.)

 

The text in 18.1.3 does indicate that to Renew, one = includes the IAADDR option(s). So, it may be that the text in the draft is = technically OK.

 

I think thought that the draft text:

 

=             &nb= sp;            =      Client implementations may mistakenly

=    renew temporary addresses if they are not careful (i.e., by in= cluding

=    the IA_TA with the same IAID in Renew or Rebind requests, rath= er than

=    a new IAID - see [RFC3315] Section 22.5),

 

Is what is technically wrong as it isn’t just = including the IA_TA with the same IAID, but also by including the addresses= . My suggestion is: Drop “i.e., by including the IA_TA with the same = IAID in Renew or Rebind requests, rather than a new IAID –“. This way you just refer people to Section 22.5 = for how to do this.

 

Not sure this is worth a respin. It may be better fo= r me to point out this issue and send the document to the AD for now as the= AD review may turn up a few other issues? We can respin before sending off= to IESG itself?

 

-     &= nbsp;    Bernie

--_000_a68466a6f26945b593756a60ac149c5aXCHALN003ciscocom_-- From nobody Wed Jan 13 06:47:25 2016 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 C45E11B2E5E; Wed, 13 Jan 2016 06:47:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.267 X-Spam-Level: ** X-Spam-Status: No, score=2.267 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_220=2.118, RP_MATCHES_RCVD=-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 8yCEhi5A5lAd; Wed, 13 Jan 2016 06:47:14 -0800 (PST) Received: from m15-47.126.com (m15-47.126.com [220.181.15.47]) by ietfa.amsl.com (Postfix) with ESMTP id 0808E1B2E76; Wed, 13 Jan 2016 06:47:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com; s=s110527; h=Date:From:Subject:MIME-Version:Message-ID; bh=Lpx+H tsYdDc5sBsSqCqXiOsVsiMlveHXOOqN/8KluUA=; b=D8sf4JeiFD7yGVmgmfj5r ckUU1RXPoJeMcb4CGoqZ6SHhUtpjNCBBZjIII/aGBSWTNuEnAVSk0D5WGZnlHcF4 nKu9ZpQVXBTEY6Z1p+pw5PnFpMZry7lajwJ1nJI67wmg6DmzVHTB8U1OX7q22VQT isz5kfvU8jbteIy3rmkIE0= Received: from lilishan48$126.com ( [166.111.68.231] ) by ajax-webmail-wmsvr47 (Coremail) ; Wed, 13 Jan 2016 22:46:54 +0800 (CST) X-Originating-IP: [166.111.68.231] Date: Wed, 13 Jan 2016 22:46:54 +0800 (CST) From: "Lishan Li" To: "Bernie Volz (volz)" X-Priority: 3 X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build 20150911(74783.7961) Copyright (c) 2002-2016 www.mailtech.cn 126com In-Reply-To: <5a5833511dbd4176b7fabc0b70517a57@XCH-ALN-003.cisco.com> References: <20151211034139.6215.53473.idtracker@ietfa.amsl.com> <5a5833511dbd4176b7fabc0b70517a57@XCH-ALN-003.cisco.com> X-CM-CTRLDATA: aTSNNWZvb3Rlcl9odG09MzA0NTo1Ng== Content-Type: multipart/mixed; boundary="----=_Part_241165_1088287836.1452696414365" MIME-Version: 1.0 Message-ID: <46aab9d7.d724.1523b74289d.Coremail.lilishan48@126.com> X-CM-TRANSID: L8qowAC3FgxfY5ZWG8hKAA--.35706W X-CM-SenderInfo: 5olox2hkdqkma6rslhhfrp/1tbi4x-uwVUw2abRhgAAse X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU== Archived-At: Cc: "dhcwg@ietf.org" , "draft-ietf-dhc-sedhcpv6@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-sedhcpv6-10.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: Wed, 13 Jan 2016 14:47:24 -0000 ------=_Part_241165_1088287836.1452696414365 Content-Type: multipart/alternative; boundary="----=_Part_241167_1740648986.1452696414365" ------=_Part_241167_1740648986.1452696414365 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: base64 RGVhciBCZXJuaWUsCgoKVGhhbmtzIGEgbG90IGZvciB5b3VyIHRocm91Z2hvdXQgcmV2aWV3IGFu ZCB2YWx1YWJsZSBjb21tZW50cy4gSSBoYXZlIGRpc2N1c3NlZCBpdCB3aXRoIFNoZW5nIEppYW5n LiBBY2NvcmRpbmcgdG8geW91ciBjb21tZW50cywgd2UgaGF2ZSBtb2RpZmllZCB0aGUgZHJhZnQg YW5kIHNvbHZlZCBtb3N0IGlzc3Vlcy4KRm9yIHRoZSByZW1haW5pbmcgY29tbWVudHMsIHBsZWFz ZSBzZWUgdGhlIGF0dGFjaG1lbnQgZG9jdW1lbnQgd2l0aCB0aGUgcmVwbHkgdG8geW91ciBjb21t ZW50cyAodGhlc2UgbGluZXMgc3RhcnQgd2l0aCBMUz4pLgpMb29raW5nIGZvcndhcmQgdG8geW91 ciBmdXJ0aGVyIGd1aWRhbmNlLgoKCkJlc3QgUmVnYXJkcywKTGlzaGFuCkF0IDIwMTUtMTItMzEg MDQ6NDg6MTAsICJCZXJuaWUgVm9seiAodm9seikiIDx2b2x6QGNpc2NvLmNvbT4gd3JvdGU6Cj5I aToKPgo+VGhhbmtzIHRvIHRoZSB1cGRhdGVkIGRvY3VtZW50IGJhc2VkIG9uIGRpc2N1c3Npb25z IGFuZCBmZWVkYmFjayBhdCBJRVRGLTk0Lgo+Cj5JIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVu dCAuLi4gc2VlIHRoZSBhdHRhY2hlZCBkb2N1bWVudCB3aXRoIGNvbW1lbnRzL2NvcnJlY3Rpb25z IGZvbGxvd2luZyB0aGUgbGluZXMgd2l0aCBpc3N1ZXMgKHRoZXNlIGxpbmVzIHN0YXJ0IHdpdGgg QlY+KS4KPgo+LSBCZXJuaWUKPgo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KPkZyb206IGRo Y3dnIFttYWlsdG86ZGhjd2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZwo+U2VudDogVGh1cnNkYXksIERlY2VtYmVyIDEwLCAyMDE1IDEwOjQy IFBNCj5UbzogaS1kLWFubm91bmNlQGlldGYub3JnCj5DYzogZGhjd2dAaWV0Zi5vcmcKPlN1Ympl Y3Q6IFtkaGN3Z10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1kaGMtc2VkaGNwdjYtMTAudHh0Cj4K Pgo+QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50 ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLgo+IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2Yg dGhlIER5bmFtaWMgSG9zdCBDb25maWd1cmF0aW9uIFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYu Cj4KPiAgICAgICAgVGl0bGUgICAgICAgICAgIDogU2VjdXJlIERIQ1B2Ngo+ICAgICAgICBBdXRo b3JzICAgICAgICAgOiBTaGVuZyBKaWFuZwo+ICAgICAgICAgICAgICAgICAgICAgICAgICBMaXNo YW4gTGkKPiAgICAgICAgICAgICAgICAgICAgICAgICAgWW9uZyBDdWkKPiAgICAgICAgICAgICAg ICAgICAgICAgICAgVGF0dXlhIEppbm1laQo+ICAgICAgICAgICAgICAgICAgICAgICAgICBUZWQg TGVtb24KPiAgICAgICAgICAgICAgICAgICAgICAgICAgRGFjaGVuZyBaaGFuZwo+CUZpbGVuYW1l ICAgICAgICA6IGRyYWZ0LWlldGYtZGhjLXNlZGhjcHY2LTEwLnR4dAo+CVBhZ2VzICAgICAgICAg ICA6IDI1Cj4JRGF0ZSAgICAgICAgICAgIDogMjAxNS0xMi0xMAo+Cj5BYnN0cmFjdDoKPiAgIFRo ZSBEeW5hbWljIEhvc3QgQ29uZmlndXJhdGlvbiBQcm90b2NvbCBmb3IgSVB2NiAoREhDUHY2KSBl bmFibGVzCj4gICBESENQdjYgc2VydmVycyB0byBwYXNzIGNvbmZpZ3VyYXRpb24gcGFyYW1ldGVy cy4gIEl0IG9mZmVycwo+ICAgY29uZmlndXJhdGlvbiBmbGV4aWJpbGl0eS4gIElmIG5vdCBiZWlu ZyBzZWN1cmVkLCBESENQdjYgaXMKPiAgIHZ1bG5lcmFibGUgdG8gdmFyaW91cyBhdHRhY2tzLiAg VGhpcyBkb2N1bWVudCBhbmFseXplcyB0aGUgc2VjdXJpdHkKPiAgIGlzc3VlcyBvZiBESENQdjYg YW5kIHNwZWNpZmllcyBhIHNlY3VyZSBESENQdjYgbWVjaGFuaXNtIGZvciB0aGUKPiAgIGF1dGhl bnRpY2F0aW9uIGFuZCBlbmNyeXB0aW9uIGJldHdlZW4gREhDUHY2IGNsaWVudCBhbmQgREhDUHY2 Cj4gICBzZXJ2ZXIuCj4KPgo+VGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRo aXMgZHJhZnQgaXM6Cj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRm LWRoYy1zZWRoY3B2Ni8KPgo+VGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFi bGUgYXQ6Cj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kaGMtc2VkaGNw djYtMTAKPgo+QSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0 Ogo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtZGhjLXNlZGhj cHY2LTEwCj4KPgo+UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51 dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lv biBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLgo+Cj5JbnRlcm5ldC1E cmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6Cj5mdHA6Ly9mdHAu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLwo+Cj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwo+ZGhjd2cgbWFpbGluZyBsaXN0Cj5kaGN3Z0BpZXRmLm9yZwo+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaGN3Zwo= ------=_Part_241167_1740648986.1452696414365 Content-Type: text/html; charset=GBK Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2NvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7 Zm9udC1mYW1pbHk6QXJpYWwiPjxkaXY+PGRpdj5EZWFyIEJlcm5pZSw8L2Rpdj48ZGl2Pjxicj48 L2Rpdj48ZGl2PlRoYW5rcyBhIGxvdCBmb3IgeW91ciB0aHJvdWdob3V0IHJldmlldyBhbmQgdmFs dWFibGUgY29tbWVudHMuIEkgaGF2ZSBkaXNjdXNzZWQgaXQgd2l0aCBTaGVuZyBKaWFuZy4gQWNj b3JkaW5nIHRvIHlvdXIgY29tbWVudHMsIHdlIGhhdmUgbW9kaWZpZWQgdGhlIGRyYWZ0IGFuZCBz b2x2ZWQgbW9zdCBpc3N1ZXMuPC9kaXY+PGRpdj5Gb3IgdGhlIHJlbWFpbmluZyBjb21tZW50cywg cGxlYXNlIHNlZSB0aGUgYXR0YWNobWVudCBkb2N1bWVudCB3aXRoIHRoZSByZXBseSB0byB5b3Vy IGNvbW1lbnRzICh0aGVzZSBsaW5lcyBzdGFydCB3aXRoIExTJmd0OykuPC9kaXY+PGRpdj5Mb29r aW5nIGZvcndhcmQgdG8geW91ciBmdXJ0aGVyIGd1aWRhbmNlLjwvZGl2PjxkaXY+PGJyPjwvZGl2 PjxkaXY+QmVzdCBSZWdhcmRzLDwvZGl2PjxkaXY+TGlzaGFuPC9kaXY+PC9kaXY+PHByZT5BdCAy MDE1LTEyLTMxIDA0OjQ4OjEwLCAiQmVybmllIFZvbHogKHZvbHopIiAmbHQ7dm9sekBjaXNjby5j b20mZ3Q7IHdyb3RlOgomZ3Q7SGk6CiZndDsKJmd0O1RoYW5rcyB0byB0aGUgdXBkYXRlZCBkb2N1 bWVudCBiYXNlZCBvbiBkaXNjdXNzaW9ucyBhbmQgZmVlZGJhY2sgYXQgSUVURi05NC4KJmd0Owom Z3Q7SSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgLi4uIHNlZSB0aGUgYXR0YWNoZWQgZG9j dW1lbnQgd2l0aCBjb21tZW50cy9jb3JyZWN0aW9ucyBmb2xsb3dpbmcgdGhlIGxpbmVzIHdpdGgg aXNzdWVzICh0aGVzZSBsaW5lcyBzdGFydCB3aXRoIEJWJmd0OykuCiZndDsKJmd0Oy0gQmVybmll CiZndDsKJmd0Oy0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCiZndDtGcm9tOiBkaGN3ZyBbbWFp bHRvOmRoY3dnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBpbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmcKJmd0O1NlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAxMCwgMjAxNSAxMDo0MiBQTQom Z3Q7VG86IGktZC1hbm5vdW5jZUBpZXRmLm9yZwomZ3Q7Q2M6IGRoY3dnQGlldGYub3JnCiZndDtT dWJqZWN0OiBbZGhjd2ddIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtZGhjLXNlZGhjcHY2LTEwLnR4 dAomZ3Q7CiZndDsKJmd0O0EgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRo ZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4KJmd0OyBUaGlzIGRyYWZ0IGlz IGEgd29yayBpdGVtIG9mIHRoZSBEeW5hbWljIEhvc3QgQ29uZmlndXJhdGlvbiBXb3JraW5nIEdy b3VwIG9mIHRoZSBJRVRGLgomZ3Q7CiZndDsgICAgICAgIFRpdGxlICAgICAgICAgICA6IFNlY3Vy ZSBESENQdjYKJmd0OyAgICAgICAgQXV0aG9ycyAgICAgICAgIDogU2hlbmcgSmlhbmcKJmd0OyAg ICAgICAgICAgICAgICAgICAgICAgICAgTGlzaGFuIExpCiZndDsgICAgICAgICAgICAgICAgICAg ICAgICAgIFlvbmcgQ3VpCiZndDsgICAgICAgICAgICAgICAgICAgICAgICAgIFRhdHV5YSBKaW5t ZWkKJmd0OyAgICAgICAgICAgICAgICAgICAgICAgICAgVGVkIExlbW9uCiZndDsgICAgICAgICAg ICAgICAgICAgICAgICAgIERhY2hlbmcgWmhhbmcKJmd0OwlGaWxlbmFtZSAgICAgICAgOiBkcmFm dC1pZXRmLWRoYy1zZWRoY3B2Ni0xMC50eHQKJmd0OwlQYWdlcyAgICAgICAgICAgOiAyNQomZ3Q7 CURhdGUgICAgICAgICAgICA6IDIwMTUtMTItMTAKJmd0OwomZ3Q7QWJzdHJhY3Q6CiZndDsgICBU aGUgRHluYW1pYyBIb3N0IENvbmZpZ3VyYXRpb24gUHJvdG9jb2wgZm9yIElQdjYgKERIQ1B2Nikg ZW5hYmxlcwomZ3Q7ICAgREhDUHY2IHNlcnZlcnMgdG8gcGFzcyBjb25maWd1cmF0aW9uIHBhcmFt ZXRlcnMuICBJdCBvZmZlcnMKJmd0OyAgIGNvbmZpZ3VyYXRpb24gZmxleGliaWxpdHkuICBJZiBu b3QgYmVpbmcgc2VjdXJlZCwgREhDUHY2IGlzCiZndDsgICB2dWxuZXJhYmxlIHRvIHZhcmlvdXMg YXR0YWNrcy4gIFRoaXMgZG9jdW1lbnQgYW5hbHl6ZXMgdGhlIHNlY3VyaXR5CiZndDsgICBpc3N1 ZXMgb2YgREhDUHY2IGFuZCBzcGVjaWZpZXMgYSBzZWN1cmUgREhDUHY2IG1lY2hhbmlzbSBmb3Ig dGhlCiZndDsgICBhdXRoZW50aWNhdGlvbiBhbmQgZW5jcnlwdGlvbiBiZXR3ZWVuIERIQ1B2NiBj bGllbnQgYW5kIERIQ1B2NgomZ3Q7ICAgc2VydmVyLgomZ3Q7CiZndDsKJmd0O1RoZSBJRVRGIGRh dGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOgomZ3Q7aHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kaGMtc2VkaGNwdjYvCiZndDsKJmd0O1Ro ZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0OgomZ3Q7aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZGhjLXNlZGhjcHY2LTEwCiZndDsKJmd0O0Eg ZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoKJmd0O2h0dHBz Oi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWRoYy1zZWRoY3B2Ni0xMAom Z3Q7CiZndDsKJmd0O1BsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWlu dXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNp b24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4KJmd0OwomZ3Q7SW50 ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0OgomZ3Q7 ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8KJmd0OwomZ3Q7X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KJmd0O2RoY3dnIG1haWxpbmcgbGlz dAomZ3Q7ZGhjd2dAaWV0Zi5vcmcKJmd0O2h0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZGhjd2cKPC9wcmU+PC9kaXY+PGJyPjxicj48c3BhbiB0aXRsZT0ibmV0ZWFzZWZvb3Rl ciI+PHA+Jm5ic3A7PC9wPjwvc3Bhbj4= ------=_Part_241167_1740648986.1452696414365-- ------=_Part_241165_1088287836.1452696414365 Content-Type: text/plain; name="draft-ietf-dhc-sedhcpv6-10.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-ietf-dhc-sedhcpv6-10.txt" CgoKCkRIQyBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBTLiBKaWFuZwpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEh1YXdlaSBUZWNobm9sb2dpZXMgQ28uLCBMdGQKSW50ZW5kZWQgc3RhdHVzOiBTdGFu ZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEwuIExpCkV4cGly ZXM6IEp1bHkgMTYsIDIwMTYgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIFkuIEN1aQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFRzaW5naHVhIFVuaXZlcnNpdHkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVC4gSmlubWVpCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSW5mb2Jsb3ggSW5j LgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgVC4gTGVtb24KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBOb21pbnVtLCBJbmMuCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBELiBaaGFuZwogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEphbnVhcnkg MTMsIDIwMTYKCgogICAgICAgICAgICAgICAgICAgICAgICAgICAgIFNlY3VyZSBESENQdjYKICAg ICAgICAgICAgICAgICAgICAgICBkcmFmdC1pZXRmLWRoYy1zZWRoY3B2Ni0xMAoKQWJzdHJhY3QK CiAgIFRoZSBEeW5hbWljIEhvc3QgQ29uZmlndXJhdGlvbiBQcm90b2NvbCBmb3IgSVB2NiAoREhD UHY2KSBlbmFibGVzCiAgIERIQ1B2NiBzZXJ2ZXJzIHRvIHBhc3MgY29uZmlndXJhdGlvbiBwYXJh bWV0ZXJzLiAgSXQgb2ZmZXJzCiAgIGNvbmZpZ3VyYXRpb24gZmxleGliaWxpdHkuICBJZiBub3Qg c2VjdXJlZCwgREhDUHY2IGlzIHZ1bG5lcmFibGUgdG8KICAgdmFyaW91cyBhdHRhY2tzLiAgVGhp cyBkb2N1bWVudCBhbmFseXplcyB0aGUgc2VjdXJpdHkgaXNzdWVzIG9mCiAgIERIQ1B2NiBhbmQg c3BlY2lmaWVzIGEgc2VjdXJlIERIQ1B2NiBtZWNoYW5pc20gZm9yIHRoZSBhdXRoZW50aWNhdGlv bgogICBhbmQgZW5jcnlwdGlvbiBvZiBtZXNzYWdlcyBiZXR3ZWVuIGEgREhDUHY2IGNsaWVudCBh bmQgYSBESENQdjYKICAgc2VydmVyLgoKU3RhdHVzIG9mIFRoaXMgTWVtbwoKICAgVGhpcyBJbnRl cm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZQogICBw cm92aXNpb25zIG9mIEJDUCA3OCBhbmQgQkNQIDc5LgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3 b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcKICAgVGFzayBGb3Jj ZSAoSUVURikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUKICAg d29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVu dCBJbnRlcm5ldC0KICAgRHJhZnRzIGlzIGF0IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k cmFmdHMvY3VycmVudC8uCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2 YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMKICAgYW5kIG1heSBiZSB1cGRhdGVkLCBy ZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkKICAgdGltZS4g IEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UK ICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jl c3MuIgoKICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBKdWx5IDE2LCAyMDE2 LgoKQ29weXJpZ2h0IE5vdGljZQoKICAgQ29weXJpZ2h0IChjKSAyMDE2IElFVEYgVHJ1c3QgYW5k IHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlCiAgIGRvY3VtZW50IGF1dGhvcnMuICBBbGwg cmlnaHRzIHJlc2VydmVkLgoKCgoKSmlhbmcsIGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVzIEp1 bHkgMTYsIDIwMTYgICAgICAgICAgICAgICAgIFtQYWdlIDFdCgwKSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgICAgICBTZURIQ1B2NiAgICAgICAgICAgICAgICAgICAgSmFudWFyeSAyMDE2CgoK ICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3Qn cyBMZWdhbAogICBQcm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzCiAgIChodHRw Oi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBv ZgogICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNlIHJldmlldyB0aGVzZSBk b2N1bWVudHMKICAgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIgcmlnaHRzIGFuZCBy ZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0CiAgIHRvIHRoaXMgZG9jdW1lbnQuICBDb2RlIENvbXBv bmVudHMgZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVudCBtdXN0CiAgIGluY2x1ZGUgU2ltcGxp ZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZgogICB0 aGUgVHJ1c3QgTGVnYWwgUHJvdmlzaW9ucyBhbmQgYXJlIHByb3ZpZGVkIHdpdGhvdXQgd2FycmFu dHkgYXMKICAgZGVzY3JpYmVkIGluIHRoZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlLgoKVGFibGUg b2YgQ29udGVudHMKCiAgIDEuICBJbnRyb2R1Y3Rpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMgogICAyLiAgUmVxdWlyZW1lbnRzIExhbmd1YWdl IGFuZCBUZXJtaW5vbG9neSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDMKICAgMy4gIFRlcm1p bm9sb2d5IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g ICA0CiAgIDQuICBTZWN1cml0eSBJc3N1ZXMgb2YgREhDUHY2IC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAgNAogICA1LiAgU2VjdXJlIERIQ1B2NiBPdmVydmlldyAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDUKICAgICA1LjEuICBTb2x1dGlvbiBP dmVydmlldyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA1CiAgICAg NS4yLiAgTmV3IENvbXBvbmVudHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAgNwogICAgIDUuMy4gIFN1cHBvcnQgZm9yIEFsZ29yaXRobSBBZ2lsaXR5IC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDcKICAgICA1LjQuICBJbXBvc2VkIEFkZGl0aW9uYWwg Q29uc3RyYWludHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA4CiAgICAgNS41LiAgQXBw bGljYWJpbGl0eSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAg OAogICA2LiAgREhDUHY2IENsaWVudCBCZWhhdmlvciAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgIDkKICAgNy4gIERIQ1B2NiBTZXJ2ZXIgQmVoYXZpb3IgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDExCiAgIDguICBSZWxheSBBZ2VudCBCZWhh dmlvciAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMwogICA5LiAg UHJvY2Vzc2luZyBSdWxlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgMTQKICAgICA5LjEuICBUaW1lc3RhbXAgQ2hlY2sgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE0CiAgIDEwLiBFeHRlbnNpb25zIGZvciBTZWN1cmUgREhD UHY2ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxNQogICAgIDEwLjEuICBOZXcg REhDUHY2IE9wdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTUK ICAgICAgIDEwLjEuMS4gIENlcnRpZmljYXRlIG9wdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gIDE1CiAgICAgICAxMC4xLjIuICBTaWduYXR1cmUgb3B0aW9uIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxNgogICAgICAgMTAuMS4zLiAgVGltZXN0YW1w IG9wdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTgKICAgICAgIDEw LjEuNC4gIEVuY3J5cHRlZC1tZXNzYWdlIE9wdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDE4CiAgICAgMTAuMi4gIE5ldyBESENQdjYgTWVzc2FnZXMgIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAxOQogICAgIDEwLjMuICBTdGF0dXMgQ29kZXMgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTkKICAgMTEuIFNlY3VyaXR5IENv bnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDIwCiAg IDEyLiBJQU5BIENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAyMAogICAxMy4gQWNrbm93bGVkZ2VtZW50cyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMjIKICAgMTQuIFJlZmVyZW5jZXMgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDIyCiAgICAgMTQuMS4g IE5vcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICAyMgogICAgIDE0LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgMjMKICAgQXV0aG9ycycgQWRkcmVzc2VzICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDI0CgoxLiAgSW50cm9kdWN0aW9uCgog ICBUaGUgRHluYW1pYyBIb3N0IENvbmZpZ3VyYXRpb24gUHJvdG9jb2wgZm9yIElQdjYgKERIQ1B2 NiwgW1JGQzMzMTVdKQogICBlbmFibGVzIERIQ1B2NiBzZXJ2ZXJzIHRvIHBhc3MgY29uZmlndXJh dGlvbiBwYXJhbWV0ZXJzIGFuZCBvZmZlcnMKCgoKCkppYW5nLCBldCBhbC4gICAgICAgICAgICAg RXhwaXJlcyBKdWx5IDE2LCAyMDE2ICAgICAgICAgICAgICAgICBbUGFnZSAyXQoMCkludGVybmV0 LURyYWZ0ICAgICAgICAgICAgICAgICAgU2VESENQdjYgICAgICAgICAgICAgICAgICAgIEphbnVh cnkgMjAxNgoKCiAgIGNvbmZpZ3VyYXRpb24gZmxleGliaWxpdHkuICBJZiBub3QgYmVpbmcgc2Vj dXJlZCwgREhDUHY2IGlzCiAgIHZ1bG5lcmFibGUgdG8gdmFyaW91cyBhdHRhY2tzLgoKICAgVGhp cyBkb2N1bWVudCBhbmFseXplcyB0aGUgc2VjdXJpdHkgaXNzdWVzIG9mIERIQ1B2NiBhbmQgcHJv dmlkZXMgdGhlCiAgIGZvbGxvd2luZyBtZWNoYW5pc21zIGZvciBpbXByb3ZpbmcgdGhlIHNlY3Vy aXR5IG9mIERIQ1B2NiBiZXR3ZWVuCiAgIGNsaWVudCBhbmQgc2VydmVyOgoKICAgbyAgdGhlIGF1 dGhlbnRpY2F0aW9uIG9mIHRoZSBESENQdjYgY2xpZW50IGFuZCB0aGUgREhDUHY2IHNlcnZlciB0 bwogICAgICBkZWZlbmQgYWdhaW5zdCBhY3RpdmUgYXR0YWNrcywgc3VjaCBhcyBzcG9vZmluZyBh dHRhY2suCgogICBvICB0aGUgZW5jcnlwdGlvbiBiZXR3ZWVuIHRoZSBESENQdjYgY2xpZW50IGFu ZCB0aGUgREhDUHY2IHNlcnZlciBpbgogICAgICBvcmRlciB0byBwcm90ZWN0IHRoZSBESENQdjYg ZnJvbSBwYXNzaXZlIGF0dGFja3MsIHN1Y2ggYXMKICAgICAgcGVydmFzaXZlIG1vbml0b3Jpbmcu CgogICBvICB0aGUgaW50ZWdyaXR5IGNoZWNrIG9mIERIQ1B2NiBtZXNzYWdlcyBieSB0aGUgcmVj aXBpZW50IG9mIHRoZQogICAgICBtZXNzYWdlIGJhc2VkIG9uIHNpZ25hdHVyZS4KCiAgIG8gIGFu dGktcmVwbGF5IHByb3RlY3Rpb24gYmFzZWQgb24gdGltZXN0YW1wcy4KCiAgIE5vdGU6IHRoaXMg c2VjdXJlIG1lY2hhbmlzbSBpbiB0aGlzIGRvY3VtZW50IGRvZXMgbm90IHByb3RlY3Qgb3V0ZXIK ICAgb3B0aW9ucyBpbiBSZWxheS1Gb3J3YXJkIGFuZCBSZWxheS1SZXBseSBtZXNzYWdlcywgZWl0 aGVyIGFkZGVkIGJ5IGEKICAgcmVsYXkgYWdlbnQgdG93YXJkIGEgc2VydmVyIG9yIGFkZGVkIGJ5 IGEgc2VydmVyIHRvd2FyZCBhIHJlbGF5CiAgIGFnZW50LiAgQ29tbXVuaWNhdGlvbiBiZXR3ZWVu IGEgc2VydmVyIGFuZCBhIHJlbGF5IGFnZW50LCBhbmQKICAgY29tbXVuaWNhdGlvbnMgYmV0d2Vl biByZWxheSBhZ2VudHMsIG1heSBiZSBzZWN1cmVkIHRocm91Z2ggdGhlIHVzZQogICBvZiBJUHNl YywgYXMgZGVzY3JpYmVkIGluIHNlY3Rpb24gMjEuMSBpbiBbUkZDMzMxNV0uCgogICBUaGUgc2Vj dXJpdHkgbWVjaGFuaXNtcyBzcGVjaWZpZWQgaW4gdGhpcyBkb2N1bWVudCBhY2hpZXZlcyB0aGUK ICAgREhDUHY2IGF1dGhlbnRpY2F0aW9uIGFuZCBlbmNyeXB0aW9uIGJhc2VkIG9uIHRoZSBzZW5k ZXIncyBwdWJsaWMga2V5CiAgIGNlcnRpZmljYXRlLiAgV2UgaW50cm9kdWNlIHR3byBuZXcgREhD UHY2IG1lc3NhZ2VzOiBFbmNyeXB0ZWQtUXVlcnkKICAgbWVzc2FnZSBhbmQgRW5jcnlwdGVkLVJl c3BvbnNlIG1lc3NhZ2UgYW5kIGZvdXIgbmV3IERIQ1B2NiBvcHRpb25zOgogICBDZXJ0aWZpY2F0 ZSBvcHRpb24sIFNpZ25hdHVyZSBvcHRpb24sIFRpbWVzdGFtcCBvcHRpb24gYW5kIEVuY3J5cHRl ZC0KICAgbWVzc2FnZSBvcHRpb24gZm9yIERIQ1B2NiBhdXRoZW50aWNhdGlvbiBhbmQgZW5jcnlw dGlvbi4gIFRoZQogICBDZXJ0aWZpY2F0ZSBvcHRpb24gaXMgdXNlZCBmb3IgREhDUHY2IGF1dGhl bnRpY2F0aW9uLiAgSXQgYWxzbwogICBpbnRlZ3JhdGVzIFNpZ25hdHVyZSBvcHRpb24gZm9yIHRo ZSBpbnRlZ3JpdHkgY2hlY2sgYW5kIFRpbWVzdGFtcAogICBvcHRpb24gZm9yIGFudGktcmVwbGF5 IHByb3RlY3Rpb24uICBUaGUgRW5jcnlwdGlvbi1RdWVyeSBtZXNzYWdlLAogICBFbmNyeXB0aW9u LVJlc3BvbnNlIG1lc3NhZ2UgYW5kIEVuY3J5cHRlZC1tZXNzYWdlIG9wdGlvbiBhcmUgdXNlZCBm b3IKICAgREhDUHY2IGVuY3J5cHRpb24uCgoyLiAgUmVxdWlyZW1lbnRzIExhbmd1YWdlIGFuZCBU ZXJtaW5vbG9neQoKICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJF RCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLAogICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVD T01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcwogICBkb2N1bWVudCBhcmUg dG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFtSRkMyMTE5XSB3aGVuIHRoZXkKICAg YXBwZWFyIGluIEFMTCBDQVBTLiAgV2hlbiB0aGVzZSB3b3JkcyBhcmUgbm90IGluIEFMTCBDQVBT IChzdWNoIGFzCiAgICJzaG91bGQiIG9yICJTaG91bGQiKSwgdGhleSBoYXZlIHRoZWlyIHVzdWFs IEVuZ2xpc2ggbWVhbmluZ3MsIGFuZAogICBhcmUgbm90IHRvIGJlIGludGVycHJldGVkIGFzIFtS RkMyMTE5XSBrZXkgd29yZHMuCgoKCgoKSmlhbmcsIGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVz IEp1bHkgMTYsIDIwMTYgICAgICAgICAgICAgICAgIFtQYWdlIDNdCgwKSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgICAgICBTZURIQ1B2NiAgICAgICAgICAgICAgICAgICAgSmFudWFyeSAyMDE2 CgoKMy4gIFRlcm1pbm9sb2d5CgogICBUaGlzIHNlY3Rpb24gZGVmaW5lcyB0ZXJtaW5vbG9neSBz cGVjaWZpYyB0byBzZWN1cmUgREhDUHY2IHVzZWQgaW4KICAgdGhpcyBkb2N1bWVudC4KCiAgIHNl Y3VyZSBESENQdjYgY2xpZW50OiAgQSBub2RlIHRoYXQgaW5pdGlhdGVzIHRoZSBESENQdjYgcmVx dWVzdCBvbiBhCiAgICAgICAgICAgICAgICAgICBsaW5rIHRvIG9idGFpbiB0aGUgREhDUHY2IGNv bmZpZ3VyYXRpb24gcGFyYW1ldGVycwogICAgICAgICAgICAgICAgICAgZnJvbSBvbmUgb3IgbW9y ZSBESENQdjYgc2VydmVycy4gIFRoZSBjb25maWd1cmF0aW9uCiAgICAgICAgICAgICAgICAgICBw cm9jZXNzIGlzIGF1dGhlbnRpY2F0ZWQgYW5kIGVuY3J5cHRlZCB1c2luZyB0aGUKICAgICAgICAg ICAgICAgICAgIGRlZmluZWQgbWVjaGFuaXNtcyBpbiB0aGlzIGRvY3VtZW50LgoKICAgc2VjdXJl IERIQ1B2NiBzZXJ2ZXI6ICBBIG5vZGUgdGhhdCByZXNwb25kcyB0byByZXF1ZXN0cyBmcm9tIGNs aWVudHMKICAgICAgICAgICAgICAgICAgIHVzaW5nIHRoZSBhdXRoZW50aWNhdGlvbiBhbmQgZW5j cnlwdGlvbiBtZWNoYW5pc20KICAgICAgICAgICAgICAgICAgIGRlZmluZWQgaW4gdGhpcyBkb2N1 bWVudC4KCjQuICBTZWN1cml0eSBJc3N1ZXMgb2YgREhDUHY2CgogICBESENQdjYgaXMgYSBjbGll bnQvc2VydmVyIHByb3RvY29sIHRoYXQgcHJvdmlkZXMgbWFuYWdlZAogICBjb25maWd1cmF0aW9u IG9mIGRldmljZXMuICBJdCBlbmFibGVzIGEgREhDUHY2IHNlcnZlciB0bwogICBhdXRvbWF0aWNh bGx5IGNvbmZpZ3VyZSByZWxldmFudCBuZXR3b3JrIHBhcmFtZXRlcnMgb24gY2xpZW50cy4gIFRo ZQogICBiYXNpYyBESENQdjYgc3BlY2lmaWNhdGlvbiBbUkZDMzMxNV0gZGVmaW5lcyBzZWN1cml0 eSBtZWNoYW5pc21zLCBidXQKICAgdGhleSBoYXZlIHNpZ25pZmljYW50IGZsYXdzIGFuZCBjYW4g YmUgaW1wcm92ZWQuCkJWPiBtaW5vciAtIHBlcmlvZCBtaXNzaW5nLgkKW0xpc2hhbl06IHNvcnJ5 IGZvciBub3QgdW5kZXJzdGFuZGluZyB3aGF0IHlvdSBtZWFuLiBzaWduaWZpY2FudCBmbGF3cyAt PiBtaW5vciBmbGF3cz8JCgogICBUaGUgYmFzaWMgREhDUHY2IHNwZWNpZmljYXRpb25zIGNhbiBv cHRpb25hbGx5IGF1dGhlbnRpY2F0ZSB0aGUKICAgb3JpZ2luIG9mIG1lc3NhZ2VzIGFuZCB2YWxp ZGF0ZSB0aGUgaW50ZWdyaXR5IG9mIG1lc3NhZ2VzIHVzaW5nIGFuCiAgIGF1dGhlbnRpY2F0aW9u IG9wdGlvbiB3aXRoIGEgc3ltbWV0cmljIGtleSBwYWlyLiAgW1JGQzMzMTVdIHJlbGllcyBvbgog ICBwcmUtZXN0YWJsaXNoZWQgc2VjcmV0IGtleXMuICBGb3IgYW55IGtpbmQgb2YgbWVhbmluZ2Z1 bCBzZWN1cml0eSwKICAgZWFjaCBESENQdjYgY2xpZW50IHdvdWxkIG5lZWQgdG8gYmUgY29uZmln dXJlZCB3aXRoIGl0cyBvd24gc2VjcmV0CiAgIGtleTsgW1JGQzMzMTVdIHByb3ZpZGVzIG5vIG1l Y2hhbmlzbSBmb3IgZG9pbmcgdGhpcy4KCiAgIEZvciB0aGUgb3V0IG9mIGJhbmQgYXBwcm9hY2gs IG9wZXJhdG9ycyBjYW4gc2V0IHVwIGEga2V5IGRhdGFiYXNlIGZvcgogICBib3RoIHNlcnZlcnMg YW5kIGNsaWVudHMgZnJvbSB3aGljaCB0aGUgY2xpZW50IG9idGFpbnMgYSBrZXkgYmVmb3JlCiAg IHJ1bm5pbmcgREhDUHY2LiAgTWFudWFsIGtleSBkaXN0cmlidXRpb24gcnVucyBjb3VudGVyIHRv IHRoZSBnb2FsIG9mCiAgIG1pbmltaXppbmcgdGhlIGNvbmZpZ3VyYXRpb24gZGF0YSBuZWVkZWQg YXQgZWFjaCBob3N0LgoKICAgW1JGQzMzMTVdIHByb3ZpZGVzIGFuIGFkZGl0aW9uYWwgbWVjaGFu aXNtIGZvciBwcmV2ZW50aW5nIG9mZi1uZXR3b3JrCiAgIHRpbWluZyBhdHRhY2tzIHVzaW5nIHRo ZSBSZWNvbmZpZ3VyZSBtZXNzYWdlOiB0aGUgUmVjb25maWd1cmUgS2V5CiAgIGF1dGhlbnRpY2F0 aW9uIG1ldGhvZC4gIEhvd2V2ZXIsIHRoaXMgbWV0aG9kIHByb3ZpZGVzIGxpdHRsZSBtZXNzYWdl CiAgIGludGVncml0eSBvciBzb3VyY2UgaW50ZWdyaXR5IGNoZWNrLCBhbmQgaXQgcHJvdGVjdHMg b25seSB0aGUKICAgUmVjb25maWd1cmUgbWVzc2FnZS4gIFRoZSBrZXkgaXMgdHJhbnNtaXR0ZWQg aW4gcGxhaW50ZXh0IHRvIHRoZQogICBjbGllbnQgaW4gZWFybGllciBleGNoYW5nZXMuCgogICBJ biBhZGRpdGlvbiwgdGhlIGN1cnJlbnQgREhDUHY2IG1lc3NhZ2VzIGFyZSBzdGlsbCB0cmFuc21p dHRlZCBpbgogICBjbGVhcnRleHQgYW5kIHRoZSBwcml2YWN5IGluZm9ybWF0aW9uIHdpdGhpbiB0 aGUgREhDUHY2IG1lc3NhZ2UgaXMKICAgbm90IHByb3RlY3RlZCBmcm9tIHBhc3NpdmUgYXR0YWNr LCBzdWNoIGFzIHBlcnZhc2l2ZSBtb25pdG9yaW5nLiAgVGhlCiAgIElFVEYgaGFzIGV4cHJlc3Nl ZCBzdHJvbmcgYWdyZWVtZW50IHRoYXQgUE0gaXMgYW4gYXR0YWNrIHRoYXQgbmVlZHMKICAgdG8g YmUgbWl0aWdhdGVkIHdoZXJlIHBvc3NpYmxlIGluIFtSRkM3MjU4XS4KCgoKCkppYW5nLCBldCBh bC4gICAgICAgICAgICAgRXhwaXJlcyBKdWx5IDE2LCAyMDE2ICAgICAgICAgICAgICAgICBbUGFn ZSA0XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgU2VESENQdjYgICAgICAgICAg ICAgICAgICAgIEphbnVhcnkgMjAxNgoKCiAgIEluIGNvbXBhcmlzb24sIHRoZSBzZWN1cml0eSBt ZWNoYW5pc21zIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudAogICBwcm92aWVzIGZvciBhdXRoZW50 aWNhdGlvbiBhbmQgZW5jcnlwdGlvbiBiYXNlZCBvbiB0aGUgcHVibGljIGtleQogICBjZXJ0aWZp Y2F0ZXMgb2YgdGhlIGNsaWVudCBvciBzZXJ2ZXIuICBUaGUgREhDUHY2IGF1dGhlbnRpY2F0aW9u IGNhbgogICBwcm90ZWN0IERIQ1B2NiBmcm9tIGFjdGl2ZSBhdHRhY2tzLCBzdWNoIGFzIHNwb29m aW5nIGF0dGFjay4gIEFuZCB0aGUKICAgREhDUHY2IGVuY3J5cHRpb24gZGVmZW5kcyBhZ2FpbnN0 IHBhc3NpdmUgYXR0YWNrcywgc3VjaCBhcyBwZXJ2YXNpdmUKICAgbW9uaXRvcmluZyBhdHRhY2su Cgo1LiAgU2VjdXJlIERIQ1B2NiBPdmVydmlldwoKNS4xLiAgU29sdXRpb24gT3ZlcnZpZXcKCiAg IFRoaXMgc29sdXRpb24gcHJvdmlkZXMgdGhlIGF1dGhlbnRpY2F0aW9uIGFuZCBlbmNyeXB0aW9u IG1lY2hhbmlzbXMKICAgYmFzZWQgb24gdGhlIHB1YmxpYyBjZXJ0aWZpY2F0ZXMgb2YgdGhlIERI Q1B2NiBjbGllbnQgYW5kIHNlcnZlci4KICAgQmVmb3JlIHRoZSBzdGFuZGFyZCBESENQdjYgY29u ZmlndXJhdGlvbiBwcm9jZXNzLCB0aGUgSW5mb3JtYXRpb24tCiAgIHJlcXVlc3QgYW5kIFJlcGx5 IG1lc3NhZ2VzIGFyZSBleGNoYW5nZWQgdG8gc2VsZWN0IG9uZSBhdXRoZW50aWNhdGVkCiAgIERI Q1B2NiBzZXJ2ZXIuICBUaGUgZm9sbG93aW5nIERIQ1B2NiBjb25maWd1cmF0aW9uIHByb2Nlc3Mg aXMKICAgZW5jcnlwdGVkIHRvIGF2b2lkIHRoZSBwcml2YWN5IGRpc2Nsb3N1cmUuICBXZSBpbnRy b2R1Y2UgdHdvIG5ldwogICBESENQdjYgbWVzc2FnZXM6IEVuY3J5cHRlZC1RdWVyeSBtZXNzYWdl LCBFbmNyeXB0ZWQtUmVzcG9uc2UgbWVzc2FnZQogICBhbmQgZm91ciBuZXcgREhDUHY2IG9wdGlv bnM6IEVuY3J5cHRlZC1tZXNzYWdlIG9wdGlvbiwgQ2VydGlmaWNhdGUKICAgb3B0aW9uLCBTaWdu YXR1cmUgb3B0aW9uLCBUaW1lc3RhbXAgb3B0aW9uLiAgQmFzZWQgb24gdGhlIG5ldyBkZWZpbmVk CiAgIG1lc3NhZ2VzIGFuZCBvcHRpb25zLCB0aGUgY29ycmVzcG9uZGluZyBhdXRoZW50aWNhdGlv biBhbmQgZW5jcnlwdGlvbgogICBtZWNoYW5pc21zIGFyZSBwcm9wb3NlZC4KCiAgIFRoZSBmb2xs b3dpbmcgZmlndXJlIGlsbHVzdHJhdGVzIHRoZSBzZWN1cmUgREhDUHY2IHByb2NlZHVyZS4gIFRo ZQogICBESENQdjYgY2xpZW50IGZpcnN0IHNlbmRzIGFuIEluZm9ybWF0aW9uLXJlcXVlc3QgbWVz c2FnZSB0byB0aGUKICAgc3RhbmRhcmQgbXVsdGljYXN0IGFkZHJlc3MgdG8gYWxsIERIQ1B2NiBz ZXJ2ZXJzLiAgVGhlIEluZm9ybWF0aW9uLQogICByZXF1ZXN0IG1lc3NhZ2UgaXMgdXNlZCB0byBy ZXF1ZXN0IHRoZSBzZXJ2ZXJzIGZvciBzZXJ2ZXIKICAgYXV0aGVudGljYXRpb24gaW5mb3JtYXRp b24sIHdpdGhvdXQgZ29pbmcgdGhyb3VnaCBhbnkgYWRkcmVzcywgcHJlZml4CiAgIG9yIG5vbi1z ZWN1cml0eSBvcHRpb24gYXNzaWdubWVudCBwcm9jZXNzLiAgVGhlIEluZm9ybWF0aW9uLXJlcXVl c3QKICAgaXMgc2VudCB3aXRob3V0IGFueSBjbGllbnQgc3BlY2lmaWMgaW5mb3JtYXRpb24sIHN1 Y2ggYXMgY2xpZW50CiAgIGlkZW50aWZpZXIgb3B0aW9uIHRvIG1pbmltaXplIGluZm9ybWF0aW9u IGxlYWthZ2UgYW5kIGluY3JlYXNlIHRoZQogICBjbGllbnQncyBwcml2YWN5LiAgV2hlbiByZWNl aXZpbmcgdGhlIEluZm9ybWF0aW9uLXJlcXVlc3QgbWVzc2FnZSwKICAgdGhlIHNlcnZlciBzZW5k cyB0aGUgUmVwbHkgbWVzc2FnZSB0aGF0IGNvbnRhaW5zIHRoZSBzZXJ2ZXIncwogICBDZXJ0aWZp Y2F0ZSBvcHRpb24sIFNpZ25hdHVyZSBvcHRpb24sIFRpbWVzdGFtcCBvcHRpb24gYW5kIFNlcnZl cgogICBJZGVudGlmaWVyIG9wdGlvbiBkZWZpbmVkIGluIFtSRkMzMzE1XS4gIFVwb24gdGhlIHJl Y2VpcHQgb2YgdGhlCiAgIFJlcGx5IG1lc3NhZ2UsIHRoZSBESENQdjYgY2xpZW50IHZlcmlmaWVz IHRoZSBzZXJ2ZXIncyBpZGVudGl0eQpCVj4gU2hvdWxkIHRoZXJlIGJlIGFueSBtZW50aW9uIHRo YXQgc2VydmVycyBub3Qgc3VwcG9ydGluZyB0aGlzIHdvcms/CQpMUz4gVGhhbmtzIGZvciB0aGlz IHZhbHVhYmxlIGNvbW1lbnRzLgkKTFM+IElmIHRoZSBzZXJ2ZXIgZG9uJ3Qgc3VwcG9ydCB0aGlz IHdvcmssIGl0IGhhcyB0d28gY2hvaWNlczoJCkxTPiAxLiBkcm9wIHRoZSByZWNlaXZlZCBJbmZv cm1hdGlvbi1yZXF1ZXN0IG1lc3NhZ2U7CQpMUz4gSW4gdGhpcyB3YXksIHRoZSBjbGllbnQgd2ls bCBub3QgcmVjZWl2ZSBhbnkgbWVzc2FnZSB3aGljaCBpbGx1c3RyYXRlCQpMUz4gdGhhdCB0aGUg c2VydmVyIGRvbid0IHN1cHBvcnQgc2VjdXJlIERIQ1B2Ni4gSWYgdGhlcmUgaXMgbm8gYXV0aGVu dGljYXRlZAkKTFM+IERIQ1B2NiBzZXJ2ZXIsIHRoZSBjbGllbnQgbWF5IHJlc2VuZCB0aGUgSW5m b3JtYXRpb24tcmVxdWVzdCBtZXNzYWdlOwkKTFM+IDIuIHNlbmQgdGhlIFJlcGx5IG1lc3NhZ2Ug d2l0aCB0aGUgY29ycmVzcG9uZGluZyBlcnJvciBzdGF0dXMgY29kZSB0bwkKTFM+IHRoZSBjbGll bnTvvJsJCkxTPiBUaGlzIHdheSB3aWxsIGludHJvZHVjZSB0aGUgZG93bmdyYWRlIGF0dGFjaywg YSB0aGlyZCBwYXJ0eSBtYXkgc2VuZAkKTFM+IHRoZSBSZXBseSBtZXNzYWdlIHdpdGggdGhlIGNv cnJlc3BvbmRpbmcgZXJyb3Igc3RhdHVzIGNvZGUuIEFuZCB0aGVuCQpMUz4gdGhlIERIQ1B2NiBj b25maWd1cmF0aW9uIHByb2Nlc3MgbWF5IGJlIHVuc2VjdXJlZC4JCkxTPiBJIHByZWZlciB0aGUg Zmlyc3Qgb25lIHNvbHV0aW9uLiBXaGljaCBvbmUgd291bGQgeW91IHByZWZlcj8gTG9va2luZwkK TFM+IGZvcndhcmQgdG8geW91ciBndWlkYW5jZS4KICAgYWNjb3JkaW5nIHRvIHRoZSBjb250YWlu ZWQgc2VydmVyIGF1dGhlbnRpY2F0aW9uIGluZm9ybWF0aW9uIGluIHRoZQogICBSZXBseSBtZXNz YWdlLiAgSWYgdGhlcmUgYXJlIG11bHRpcGxlIGF1dGhlbnRpY2F0ZWQgREhDUHY2IHNlcnZlcnMs CiAgIHRoZSBjbGllbnQgc2VsZWN0cyBvbmUgYXV0aGVudGljYXRlZCBESENQdjYgc2VydmVyIGZv ciB0aGUgZm9sbG93aW5nCiAgIERIQ1B2NiBjb25maWd1cmF0aW9uIHByb2Nlc3MuICBJZiB0aGVy ZSBhcmUgbm8gYXV0aGVudGljYXRlZCBESENQdjYKICAgc2VydmVycyBvciBleGlzdGluZyBzZXJ2 ZXJzIGZhaWxlZCBhdXRoZW50aWNhdGlvbiwgdGhlIGNsaWVudAogICBiZWhhdmlvciBpcyBwb2xp Y3kgc3BlY2lmaWMuICBEZXBlbmRpbmcgb24gaXRzIHBvbGljeSwgaXQgY2FuIGNob29zZQogICB0 byByZXBlYXQgdGhlIHNlcnZlciBkaXNjb3ZlcnkgcHJvY2VzcyBhZnRlciBjZXJ0YWluIGRlbGF5 IG9yIGF0dGVtcHQKICAgdG8gdXNlIGFuIHVuc2VjdXJlZCBESENQdjYgc2VydmVyLgoKICAgQWZ0 ZXIgdGhlIHNlcnZlcidzIGF1dGhlbnRpY2F0aW9uLCB0aGUgZmlyc3QgREhDUHY2IG1lc3NhZ2Ug c2VudCBmcm9tCiAgIGNsaWVudCB0byBzZXJ2ZXIsIHN1Y2ggYXMgU29saWNpdCBtZXNzYWdlLCBj b250YWlucyB0aGUgY2xpZW50J3MKICAgQ2VydGlmaWNhdGUgb3B0aW9uLCBTaWduYXR1cmUgb3B0 aW9uIGFuZCBUaW1lc3RhbXAgb3B0aW9uIGZvciBjbGllbnQKCgoKSmlhbmcsIGV0IGFsLiAgICAg ICAgICAgICBFeHBpcmVzIEp1bHkgMTYsIDIwMTYgICAgICAgICAgICAgICAgIFtQYWdlIDVdCgwK SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICBTZURIQ1B2NiAgICAgICAgICAgICAgICAg ICAgSmFudWFyeSAyMDE2CgoKICAgYXV0aGVudGljYXRpb24uICBUaGUgREhDUHY2IG1lc3NhZ2Ug c2VudCBmcm9tIGNsaWVudCB0byBzZXJ2ZXIgaXMKICAgZW5jcnlwdGVkIHdpdGggdGhlIHNlcnZl cidzIHB1YmxpYyBrZXkgYW5kIGVuY2Fwc3VsYXRlZCBpbnRvIHRoZQogICBFbmNyeXB0ZWQtbWVz c2FnZSBvcHRpb24uICBUaGUgREhDUHY2IGNsaWVudCBzZW5kcyB0aGUgRW5jcnlwdGVkLQogICBR dWVyeSBtZXNzYWdlIHRvIHNlcnZlciwgd2hpY2ggY2FycmllcyB0aGUgU2VydmVyIElkZW50aWZp ZXIgb3B0aW9uCiAgIGFuZCB0aGUgRW5jcnlwdGVkLW1lc3NhZ2Ugb3B0aW9uLiAgV2hlbiB0aGUg REhDUHY2IHNlcnZlciByZWNlaXZlcwogICB0aGUgRW5jcnlwdGVkLVF1ZXJ5IG1lc3NhZ2UsIGl0 IGRlY3J5cHRzIHRoZSBtZXNzYWdlIHVzaW5nIGl0cwogICBwcml2YXRlIGtleS4gIElmIHRoZSBk ZWNyeXB0ZWQgbWVzc2FnZSBjb250YWlucyB0aGUgY2xpZW50J3MKICAgQ2VydGlmaWNhdGUgb3B0 aW9uLCBTaWduYXR1cmUgb3B0aW9uLCBUaW1lc3RhbXAgb3B0aW9uLCB0aGUgREhDUHY2CiAgIHNl cnZlciB2ZXJpZmllcyB0aGUgY2xpZW50J3MgaWRlbnRpdHkgYWNjb3JkaW5nIHRvIHRoZSBjb250 YWluZWQKICAgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGluZm9ybWF0aW9uLiAgQWZ0ZXIgdGhlIGNs aWVudCdzCiAgIGF1dGhlbnRpY2F0aW9uLCB0aGUgc2VydmVyIHNlbmRzIHRoZSBFbmNyeXB0ZWQt UmVzcG9uc2UgbWVzc2FnZSB0bwogICB0aGUgY2xpZW50LCB3aGljaCBjb250YWlucyB0aGUgRW5j cnlwdGVkLW1lc3NhZ2Ugb3B0aW9uLiAgVGhlCiAgIEVuY3J5cHRlZC1tZXNzYWdlIG9wdGlvbiBj b250YWlucyB0aGUgZW5jcnlwdGVkIERIQ1B2NiBtZXNzYWdlIHNlbnQKICAgZnJvbSBzZXJ2ZXIg dG8gY2xpZW50LCB3aGljaCBpcyBlbmNyeXB0ZWQgdXNpbmcgdGhlIGNsaWVudCdzIHB1YmxpYwog ICBrZXkuICBJZiB0aGUgbWVzc2FnZSBmYWlscyBjbGllbnQgYXV0aGVudGljYXRpb24sIHRoZW4g dGhlIHNlcnZlcgogICBzZW5kcyB0aGUgY29ycmVzcG9uZGluZyBlcnJvciBzdGF0dXMgY29kZSB0 byB0aGUgY2xpZW50LgoKICAgICAgICAgICArLS0tLS0tLS0tLS0tLSsgICAgICAgICAgICAgICAg ICAgICAgICAgICArLS0tLS0tLS0tLS0tLSsKICAgICAgICAgICB8REhDUHY2IENsaWVudHwgICAg ICAgICAgICAgICAgICAgICAgICAgICB8REhDUHY2IFNlcnZlcnwKICAgICAgICAgICArLS0tLS0t LS0tLS0tLSsgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLSsKICAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgIEluZm9ybWF0aW9uLXJlcXVlc3QgICAgICAgICAgIHwK ICAgICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tPnwKICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgT3B0aW9uIFJlcXVlc3Qgb3B0aW9u ICAgICAgICAgIHwKICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwKICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAg UmVwbHkgICAgICAgICAgICAgICAgIHwKICAgICAgICAgICAgICAgICAgfDwtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwKICAgICAgICAgICAgICAgICAgfCAgICAgICAg ICAgICBDZXJ0aWZpY2F0ZSBvcHRpb24gICAgICAgICAgIHwKICAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgU2lnbmF0dXJlIG9wdGlvbiAgICAgICAgICAgIHwKICAgICAgICAgICAgICAg ICAgfCAgICAgICAgICAgICAgVGltZXN0YW1wIG9wdGlvbiAgICAgICAgICAgIHwKICAgICAgICAg ICAgICAgICAgfCAgICAgICAgIFNlcnZlciBJZGVudGlmaWVyIG9wdGlvbiAgICAgICAgIHwKICAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwKICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgIEVuY3J5cHRpb24tUXVlcnkgICAgICAg ICAgICAgIHwKICAgICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPnwKICAgICAgICAgICAgICAgICAgfCAgICAgICAgICBFbmNyeXB0ZWQtbWVz c2FnZSBvcHRpb24gICAgICAgIHwKICAgICAgICAgICAgICAgICAgfCAgICAgICAgICBTZXJ2ZXIg SWRlbnRpZmllciBvcHRpb24gICAgICAgIHwKICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgICAgICAgICAgICAgfCAgICAg ICAgICAgIEVuY3J5cHRpb24tUmVzcG9uc2UgICAgICAgICAgIHwKICAgICAgICAgICAgICAgICAg fDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwKICAgICAgICAgICAg ICAgICAgfCAgICAgICAgICBFbmNyeXB0ZWQtbWVzc2FnZSBvcHRpb24gICAgICAgIHwKICAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwK CiAgICAgICAgICAgICAgICAgICAgICAgICAgU2VjdXJlIERIQ1B2NiBQcm9jZWR1cmUKCiAgIEl0 IGlzIHdvcnRoIG5vdGljaW5nIHRoYXQgdGhlIHNpZ25hdHVyZSBvbiBhIFNlY3VyZSBESENQdjYg bWVzc2FnZQogICBjYW4gYmUgZXhwZWN0ZWQgdG8gc2lnbmlmaWNhbnRseSBpbmNyZWFzZSB0aGUg c2l6ZSBvZiB0aGUgbWVzc2FnZS4KICAgT25lIGV4YW1wbGUgaXMgbm9ybWFsIERIQ1B2NiBtZXNz YWdlIGxlbmd0aCBwbHVzIDEgS0IgZm9yIGEgWC41MDkKICAgY2VydGlmaWNhdGUgYW5kIHNpZ25h dHVyZSBhbmQgMjU2IGJ5dGUgZm9yIGEgc2lnbmF0dXJlLiAgSVB2NgogICBmcmFnbWVudHMgW1JG QzI0NjBdIGFyZSBoaWdobHkgcG9zc2libGUuICBIZW5jZSwgZGVwbG95bWVudCBvZiBTZWN1cmUK CgoKSmlhbmcsIGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVzIEp1bHkgMTYsIDIwMTYgICAgICAg ICAgICAgICAgIFtQYWdlIDZdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICBTZURI Q1B2NiAgICAgICAgICAgICAgICAgICAgSmFudWFyeSAyMDE2CgoKICAgREhDUHY2IHNob3VsZCBh bHNvIGNvbnNpZGVyIHRoZSBpc3N1ZXMgb2YgSVAgZnJhZ21lbnQsIFBNVFUsIGV0Yy4KICAgQWxz bywgaWYgdGhlcmUgYXJlIGZpcmV3YWxscyBiZXR3ZWVuIHNlY3VyZSBESENQdjYgY2xpZW50cyBh bmQgc2VjdXJlCiAgIERIQ1B2NiBzZXJ2ZXJzLCBpdCBpcyBSRUNPTU1FTkRFRCB0aGF0IHRoZSBm aXJld2FsbHMgYXJlIGNvbmZpZ3VyZWQKICAgdG8gcGFzcyBJQ01QIFBhY2tldCBUb28gQmlnIG1l c3NhZ2VzIFtSRkM0NDQzXS4KQlY+IFRoZXJlIGFyZSBhbHNvIHJlbGF5IGltcGxpY2F0aW9ucyBh cyB0aGV5IG11c3Qgc3VwcG9ydCB0aGUgbGFyZ2VyCQpCVj4gbWVzc2FnZXMgYW5kIGZyYWdtZW50 YXRpb24gKGFzIHdlbGwgYXMgc2VuZGluZyBJQ01QdjYgUGFja2V0IFRvbwkKQlY+IEJpZyBtZXNz YWdlcz8JCkxTPiBJbiB0aGUgaW5pdGlhbCwgd2UgdGhpbmsgdGhlIHJlbGF5IGlzIGFsd2F5cyB1 c2VkIGZvciB0aGUgcGFja2V0CQpMUz4gZm9yd2FyZCBhbmQgd2lsbCBub3QgcHJvY2VzcyB0aGUg bWVzc2FnZS4gU28gd2UgZGlkJ3QgY29uc2lkZXIJCkxTPiByZWxheS4gSWYgaXQgaXMgbmVjZXNz YXJ5LCBob3cgYWJvdXQgdGhlIGZvbGxvd2luZyB0ZXh0OgkKTFM+IElmIHRoZXJlIGFyZSBmaXJl d2FsbHMgYW5kIHJlbGF5cyBiZXR3ZWVuIHNlY3VyZSBESENQdjYgY2xpZW50cwkKTFM+IGFuZCBz ZWN1cmUgREhDUHY2IHNlcnZlcnMsIGl0IGlzIFJFQ09NTUVOREVEIHRoYXQgdGhlIGZpcmV3YWxs cyBhbmQJCkxTPiByZWxheXMgYXJlIGNvbmZpZ3VyZWQgdG8gcGFzcyBJQ01QIFBhY2tldCBUb28g QmlnIG1lc3NhZ2VzIFtSRkM0NDQzXS4KCjUuMi4gIE5ldyBDb21wb25lbnRzCgogICBUaGUgbmV3 IGNvbXBvbmVudHMgb2YgdGhlIHNvbHV0aW9uIHNwZWNpZmllZCBpbiB0aGlzIGRvY3VtZW50IGFy ZSBhcwogICBmb2xsb3dzOgoKICAgbyAgU2VydmVycyBhbmQgY2xpZW50cyB0aGF0IHVzZSBjZXJ0 aWZpY2F0ZXMgZmlyc3QgZ2VuZXJhdGUgYSBwdWJsaWMvCiAgICAgIHByaXZhdGUga2V5IHBhaXIg YW5kIHRoZW4gb2J0YWluIGEgcHVibGljIGtleSBjZXJ0aWZpY2F0ZSBmcm9tIGEKICAgICAgQ2Vy dGlmaWNhdGUgQXV0aG9yaXR5IHRoYXQgc2lnbnMgdGhlIHB1YmxpYyBrZXkuICBUaGUgQ2VydGlm aWNhdGUKICAgICAgb3B0aW9uIGlzIGRlZmluZWQgdG8gY2FycnkgdGhlIGNlcnRpZmljYXRlLgoK ICAgbyAgQSBzaWduYXR1cmUgZ2VuZXJhdGVkIHVzaW5nIHRoZSBwcml2YXRlIGtleSB3aGljaCBp cyB1c2VkIGJ5IHRoZQogICAgICByZWNlaXZlciB0byB2ZXJpZnkgdGhlIGludGVncml0eSBvZiB0 aGUgREhDUHY2IG1lc3NhZ2VzIGFuZCB0aGVuCiAgICAgIHRoZSBhdXRoZW50aWNhdGlvbiBvZiB0 aGUgY2xpZW50L3NlcnZlci4gIFRoZSBTaWduYXR1cmUgb3B0aW9uIGlzCiAgICAgIGRlZmluZWQg dG8gY2FycnkgdGhlIHNpZ25hdHVyZS4KCiAgIG8gIEEgdGltZXN0YW1wIHRoYXQgY2FuIGJlIHVz ZWQgdG8gZGV0ZWN0IHJlcGxheWVkIHBhY2tldC4gIFRoZQogICAgICBzZWN1cmUgREhDUHY2IGNs aWVudC9zZXJ2ZXIgbmVlZCB0byBtZWV0IHNvbWUgYWNjdXJhY3kKICAgICAgcmVxdWlyZW1lbnRz IGFuZCBiZSBzeW5jZWQgdG8gZ2xvYmFsIHRpbWUsIHdoaWxlIHRoZSB0aW1lc3RhbXAKICAgICAg Y2hlY2tpbmcgbWVjaGFuaXNtIGFsbG93cyBhIGNvbmZpZ3VyYWJsZSB0aW1lIHZhbHVlIGZvciBj bG9jawogICAgICBkcmlmdC4gIFRoZSByZWFsIHRpbWUgcHJvdmlzaW9uIGlzIG91dCBvZiBzY29w ZSBvZiB0aGlzIGRvY3VtZW50LgogICAgICBUaGUgVGltZXN0YW1wIG9wdGlvbiBpcyBkZWZpbmVk IHRvIGNhcnJ5IHRoZSBjdXJyZW50IHRpbWUgb2YgdGhlCiAgICAgIGNsaWVudC9zZXJ2ZXIuCgog ICBvICBUaGUgRW5jcnlwdGVkLW1lc3NhZ2Ugb3B0aW9uIHRoYXQgY29udGFpbnMgdGhlIGVuY3J5 cHRlZCBESENQdjYKICAgICAgbWVzc2FnZS4KCiAgIG8gIFRoZSBFbmNyeXB0ZWQtUXVlcnkgbWVz c2FnZSB0aGF0IGlzIHNlbnQgZnJvbSBjbGllbnQgdG8gc2VydmVyLgogICAgICBUaGUgRW5jcnlw dGVkLVF1ZXJ5IG1lc3NhZ2UgY29udGFpbnMgdGhlIEVuY3J5cHRlZC1tZXNzYWdlIG9wdGlvbgog ICAgICBhbmQgU2VydmVyIElkZW50aWZpZXIgb3B0aW9uLgoKICAgbyAgVGhlIEVuY3J5cHRlZC1S ZXNwb25zZSBtZXNzYWdlIHRoYXQgaXMgc2VudCBmcm9tIHNlcnZlciB0byBjbGllbnQuCiAgICAg IFRoZSBFbmNyeXB0ZWQtUmVzcG9uc2UgbWVzc2FnZSBjb250YWlucyB0aGUgRW5jcnlwdGVkLW1l c3NhZ2UKICAgICAgb3B0aW9uLgoKNS4zLiAgU3VwcG9ydCBmb3IgQWxnb3JpdGhtIEFnaWxpdHkK CiAgIEhhc2ggZnVuY3Rpb25zIGFyZSB1c2VkIHRvIHByb3ZpZGUgbWVzc2FnZSBpbnRlZ3JpdHkg Y2hlY2tzLiAgSW4KICAgb3JkZXIgdG8gcHJvdmlkZSBhIG1lYW5zIG9mIGFkZHJlc3NpbmcgcHJv YmxlbXMgdGhhdCBtYXkgZW1lcmdlIGluCiAgIHRoZSBmdXR1cmUgd2l0aCBleGlzdGluZyBoYXNo IGFsZ29yaXRobXMsIGFzIHJlY29tbWVuZGVkIGluCiAgIFtSRkM0MjcwXSwgdGhpcyBkb2N1bWVu dCBwcm92aWRlcyBhIG1lY2hhbmlzbSBmb3IgbmVnb3RpYXRpbmcgdGhlIHVzZQogICBvZiBtb3Jl IHNlY3VyZSBoYXNoZXMgaW4gdGhlIGZ1dHVyZS4KCgoKCgpKaWFuZywgZXQgYWwuICAgICAgICAg ICAgIEV4cGlyZXMgSnVseSAxNiwgMjAxNiAgICAgICAgICAgICAgICAgW1BhZ2UgN10KDApJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIFNlREhDUHY2ICAgICAgICAgICAgICAgICAgICBK YW51YXJ5IDIwMTYKCgogICBJbiBhZGRpdGlvbiB0byBoYXNoIGFsZ29yaXRobSBhZ2lsaXR5LCB0 aGlzIGRvY3VtZW50IGFsc28gcHJvdmlkZXMgYQogICBtZWNoYW5pc20gZm9yIHNpZ25hdHVyZSBh bGdvcml0aG0gYWdpbGl0eS4KCiAgIFRoZSBzdXBwb3J0IGZvciBhbGdvcml0aG0gYWdpbGl0eSBp biB0aGlzIGRvY3VtZW50IGlzIG1haW5seSBhCiAgIHVuaWxhdGVyYWwgbm90aWZpY2F0aW9uIG1l Y2hhbmlzbSBmcm9tIHNlbmRlciB0byByZWNpcGllbnQuICBBCiAgIHJlY2lwaWVudCBNQVkgc3Vw cG9ydCB2YXJpb3VzIGFsZ29yaXRobXMgc2ltdWx0YW5lb3VzbHkgYW1vbmcKICAgZGlmZmVyZW50 IHNlbmRlcnMsIGFuZCB0aGUgZGlmZmVyZW50IHNlbmRlcnMgbWF5IGJlIGFsbG93ZWQgdG8gdXNl CiAgIHZhcmlvdXMgYWxnb3JpdGhtcyBzaW11bHRhbmVvdXNseS4gIEl0IGlzIE5PVCBSRUNPTU1F TkRFRCB0aGF0IHRoZQogICBzYW1lIHNlbmRlciBhbmQgcmVjaXBpZW50IHVzZSB2YXJpb3VzIGFs Z29yaXRobXMgaW4gYSBzaW5nbGUKICAgY29tbXVuaWNhdGlvbiBzZXNzaW9uLgoKICAgSWYgdGhl IHJlY2lwaWVudCBkb2VzIG5vdCBzdXBwb3J0IHRoZSBhbGdvcml0aG0gdXNlZCBieSB0aGUgc2Vu ZGVyLAogICBpdCBjYW5ub3QgYXV0aGVudGljYXRlIHRoZSBtZXNzYWdlLiAgSW4gdGhlIGNsaWVu dC10by1zZXJ2ZXIgY2FzZSwKICAgdGhlIHNlcnZlciBTSE9VTEQgcmVwbHkgd2l0aCBhbiBBbGdv cml0aG1Ob3RTdXBwb3J0ZWQgc3RhdHVzIGNvZGUKICAgKGRlZmluZWQgaW4gU2VjdGlvbiAxMC4z KS4gIFVwb24gcmVjZWl2aW5nIHRoaXMgc3RhdHVzIGNvZGUsIHRoZQogICBjbGllbnQgTUFZIHJl c2VuZCB0aGUgbWVzc2FnZSBwcm90ZWN0ZWQgd2l0aCB0aGUgbWFuZGF0b3J5IGFsZ29yaXRobQog ICAoZGVmaW5lZCBpbiBTZWN0aW9uIDEwLjEuMikuCgo1LjQuICBJbXBvc2VkIEFkZGl0aW9uYWwg Q29uc3RyYWludHMKCiAgIFRoZSBjbGllbnQvc2VydmVyIHRoYXQgc3VwcG9ydHMgaWRlbnRpdHkg dmVyaWZpY2F0aW9uIE1BWSBpbXBvc2UKICAgYWRkaXRpb25hbCBjb25zdHJhaW50cyBmb3IgdmVy aWZpY2F0aW9uLiAgRm9yIGV4YW1wbGUsIGl0IG1heSBpbXBvc2UKICAgbGltaXRzIG9uIG1pbmlt dW0gYW5kIG1heGltdW0ga2V5IGxlbmd0aHMuCgogICBNaW5iaXRzICBUaGUgbWluaW11bSBhY2Nl cHRhYmxlIGtleSBsZW5ndGggZm9yIHB1YmxpYyBrZXlzLiAgQW4gdXBwZXIKICAgICAgbGltaXQg TUFZIGFsc28gYmUgc2V0IGZvciB0aGUgYW1vdW50IG9mIGNvbXB1dGF0aW9uIG5lZWRlZCB3aGVu CiAgICAgIHZlcmlmeWluZyBwYWNrZXRzIHRoYXQgdXNlIHRoZXNlIHNlY3VyaXR5IGFzc29jaWF0 aW9ucy4gIFRoZQogICAgICBhcHByb3ByaWF0ZSBsZW5ndGhzIFNIT1VMRCBiZSBzZXQgYWNjb3Jk aW5nIHRvIHRoZSBzaWduYXR1cmUKICAgICAgYWxnb3JpdGhtIGFuZCBhbHNvIGZvbGxvd2luZyBw cnVkZW50IGNyeXB0b2dyYXBoaWMgcHJhY3RpY2UuICBGb3IKICAgICAgZXhhbXBsZSwgbWluaW11 bSBsZW5ndGggMTAyNCBhbmQgdXBwZXIgbGltaXQgMjA0OCBtYXkgYmUgdXNlZCBmb3IKICAgICAg UlNBIFtSU0FdLgoKNS41LiAgQXBwbGljYWJpbGl0eQoKICAgU2VjdXJlIERIQ1B2NiBpcyBhcHBs aWNhYmxlIGluIGVudmlyb25tZW50cyB3aGVyZSBwaHlzaWNhbCBzZWN1cml0eQogICBvbiB0aGUg bGluayBpcyBub3QgYXNzdXJlZCBhbmQgYXR0YWNrcyBvbiBESENQdjYgYXJlIGEgY29uY2Vybiwg c3VjaAogICBhcyBlbnRlcnByaXNlIG5ldHdvcmtzLiAgSW4gZW50ZXJwcmlzZSBuZXR3b3Jrcywg dGhlIHNlY3VyaXR5IHBvbGljeQogICBpcyBzdHJpY3QgYW5kIHRoZSBjbGllbnRzIGFyZSBzdGFi bGUgdGVybWluYWxzLiAgVGhlIFBLSSBtb2RlbCBpcwogICB1c2VkIGZvciB0aGUgc2VjdXJlIERI Q1B2NiBkZXBsb3ltZW50LiAgVGhlIGRlcGxveW1lbnQgb2YgUEtJIGlzIG91dAogICBvZiB0aGUg c2NvcGUgb2YgdGhpcyBkb2N1bWVudC4gIFRoZSBzZXJ2ZXIgaXMgYWx3YXlzIGNvbnNpZGVyZWQg dG8KICAgaGF2ZSBjb25uZWN0aXZpdHkgdG8gYW4gYXV0aG9yaXplZCBDQSBhbmQgYWJsZSB0byB2 ZXJpZnkgdGhlIGNsaWVudHMnCiAgIGNlcnRpZmljYXRlcy4gIFRoZSBjbGllbnQgcGVyZm9ybXMg dGhlIHNlcnZlciBhdXRoZW50aWNhdGlvbiBsb2NhbGx5LgogICBUaGUgdHJ1c3RlZCBzZXJ2ZXJz JyBjZXJ0aWZpY2F0ZXMgb3IgdHJ1c3RlZCBDQXMnIGNlcnRpZmljYXRlcywgd2hpY2gKICAgZm9y bSBhIGNlcnRpZmljYXRpb24gcGF0aCBbUkZDNTI4MF0sIGlzIGRlcGxveWVkIGluIHRoZSBjbGll bnQgdG8KICAgYWNoaWV2ZSB0aGUgc2VydmVyIGF1dGhlbnRpY2F0aW9uLiAgVGhlIERIQ1B2NiBj bGllbnQgaXMgcHJlLQogICBjb25maWd1cmVkIHdpdGggdGhlIHRydXN0ZWQgY2VydGlmaWNhdGUu ICBBZnRlciB0aGUgbXV0dWFsCiAgIGF1dGhlbnRpY2F0aW9uLCB0aGUgREhDUHY2IG1lc3NhZ2Ug aXMgZW5jcnlwdGVkIHdpdGggdGhlIHJlY2lwaWVudCdzCiAgIHB1YmxpYyBrZXksIHdoaWNoIGlz IGNvbnRhaW5lZCBpbiB0aGUgY2VydGlmaWNhdGUuCgoKCkppYW5nLCBldCBhbC4gICAgICAgICAg ICAgRXhwaXJlcyBKdWx5IDE2LCAyMDE2ICAgICAgICAgICAgICAgICBbUGFnZSA4XQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgU2VESENQdjYgICAgICAgICAgICAgICAgICAgIEph bnVhcnkgMjAxNgoKCjYuICBESENQdjYgQ2xpZW50IEJlaGF2aW9yCgogICBGb3IgdGhlIHNlY3Vy aXR5IERIQ1B2NiBjbGllbnQsIGl0IG11c3QgaGF2ZSBhIHB1YmxpYyBjZXJ0aWZpY2F0ZS4KICAg VGhlIGNsaWVudCBtYXkgYmUgcHJlLWNvbmZpZ3VyZWQgd2l0aCBhIHB1YmxpYyBrZXkgY2VydGlm aWNhdGUsIHdoaWNoCiAgIGlzIHNpZ25lZCBieSBhIENBIHRydXN0ZWQgYnkgdGhlIHNlcnZlciwg YW5kIGl0cyBjb3JyZXNwb25kaW5nCiAgIHByaXZhdGUga2V5LgoKICAgVGhlIERIQ1B2NiBjbGll bnQgbXVsdGljYXN0cyB0aGUgSW5mb3JtYXRpb24tcmVxdWVzdCBtZXNzYWdlIHRvIHRoZQogICBE SENQdjYgc2VydmVycy4gIFRoZSBJbmZvcm1hdGlvbi1yZXF1ZXN0IG1lc3NhZ2UgTVVTVCBOT1Qg aW5jbHVkZSBhbnkKICAgb3B0aW9uIHdoaWNoIG1heSByZXZlYWwgdGhlIHByaXZhdGUgaW5mb3Jt YXRpb24gb2YgdGhlIGNsaWVudCwgc3VjaAogICBhcyB0aGUgY2xpZW50IGlkZW50aWZpZXIgb3B0 aW9uLiAgVGhlIGluZm9ybWF0aW9uLXJlcXVlc3QgbWVzc2FnZSBpcwogICB1c2VkIGJ5IHRoZSBE SENQdjYgY2xpZW50IHRvIHJlcXVlc3QgdGhlIHNlcnZlcidzIGlkZW50aXR5CiAgIHZlcmlmaWNh dGlvbiBpbmZvcm1hdGlvbiB3aXRob3V0IGhhdmluZyBhZGRyZXNzZXMsIHByZWZpeGVzIG9yIGFu eQogICBub24tc2VjdXJpdHkgb3B0aW9ucyBhc3NpZ25lZCB0byBpdC4gIFRoZSBPcHRpb24gUmVx dWVzdCBvcHRpb24gaW4KICAgdGhlIEluZm9ybWF0aW9uLXJlcXVlc3QgbWVzc2FnZSBNVVNUIGNv bnRhaW4gdGhlIG9wdGlvbiBjb2RlIG9mIHRoZQogICBDZXJ0aWZpY2F0ZSBvcHRpb24sIFNpZ25h dHVyZSBvcHRpb24sIFRpbWVzdGFtcCBvcHRpb24gYW5kIFNlcnZlcgogICBJZGVudGlmaWVyIG9w dGlvbi4KQlY+IERvIHdlIGFsc28gd2FudCB0aGUgU09MX01BWF9SVCBhbmQgSU5GX01BWF9SVCBv cHRpb25zIGluIE9STyAoUkZDCQpCVj4gNzA4Myk/IENsaWVudCBzaG91bGQgdXNlIHRoZXNlPwkK TFM+IFRoZSByZXF1ZXN0IG9mIHRoZSBTT0xfTUFYX1JGIGFuZCBJTkZfTUFYX1JGIG9wdGlvbnMg aW4gT1JPCQpMUz4gd2lsbCBub3QgcmV2ZWFsIGFueSBwcml2YWN5IGluZm9ybWF0aW9uLiBUaGUg T1JPIGNhbiBjb250YWluIHRoZSAKTFM+IHRoZSByZXF1ZXN0IG9mIHRoZXNlIHR3byBvcHRpb25z LiBJbiB0aGUgY3VycmVudCB2ZXJzaW9uLCB3ZQkKTFM+IHNwZWNpZmllcyB0aGF0IHRoZSBPUk8g TVVTVCBjb250YWluIHRoZSBjb2RlIG9mIGNlcnRpZmljYXRlIG9wdGlvbiwJCkxTPiBzaWduYXR1 cmUgb3B0aW9uLCB0aW1lc3RhbXAgb3B0aW9uIGFuZCBzZXJ2ZXIgaWRlbnRpZmllciBvcHRpb24u CQpMUz4gRm9yIHRoZSBvdGhlciBvcHRpb25zLCB0aGUgY2xpZW50IG1heSBjb250YWluIHRoZSBj b2RlIGluIHRoZSBPUk8uCQpMUz4gSW4gbXkgb3B0aW9uLCBpdCBpcyBub3QgbmVjZXNzYXJ5IHRv IHNwZWNpZnkgdGhlc2UgdHdvIG9wdGlvbnMuIApMUz4gV2hhdCBpcyB5b3VyIG9wdGlvbj8gTG9v a2luZyBmb3J3YXJkIHRvIHlvdXIgY29tbWVudHMuCgogICBXaGVuIHJlY2VpdmluZyB0aGUgUmVw bHkgbWVzc2FnZXMgZnJvbSBESENQdjYgc2VydmVycywgYSBzZWN1cmUKICAgREhDUHY2IGNsaWVu dCBTSE9VTEQgZGlzY2FyZCBhbnkgREhDUHY2IG1lc3NhZ2VzIHRoYXQgbWVldCBhbnkgb2YgdGhl CiAgIGZvbGxvd2luZyBjb25kaXRpb25zOgoKICAgbyAgdGhlIFNpZ25hdHVyZSBvcHRpb24gaXMg bWlzc2luZywKCiAgIG8gIG11bHRpcGxlIFNpZ25hdHVyZSBvcHRpb25zIGFyZSBwcmVzZW50LAoK ICAgbyAgdGhlIENlcnRpZmljYXRlIG9wdGlvbiBpcyBtaXNzaW5nLgoKICAgQW5kIHRoZW4gdGhl IGNsaWVudCBTSE9VTEQgZmlyc3QgY2hlY2sgdGhlIHN1cHBvcnQgb2YgdGhlIGhhc2ggYW5kCiAg IHNpZ25hdHVyZSBhbGdvcml0aG1zIHRoYXQgdGhlIHNlcnZlciB1c2VkLiAgSWYgdGhlIGNoZWNr IGZhaWxzLCB0aGUKICAgUmVwbHkgbWVzc2FnZSBTSE9VTEQgYmUgZHJvcHBlZC4gIElmIGJvdGgg aGFzaCBhbmQgc2lnbmF0dXJlCiAgIGFsZ29yaXRobXMgYXJlIHN1cHBvcnRlZCwgdGhlIGNsaWVu dCB0aGVuIGNoZWNrcyB0aGUgYXV0aG9yaXR5IG9mCiAgIHRoaXMgc2VydmVyLiAgVGhlIGNsaWVu dCBTSE9VTEQgYWxzbyB1c2UgdGhlIHNhbWUgYWxnb3JpdGhtcyBpbiB0aGUKICAgc3Vic2VxdWVu dCBtZXNzYWdlcy4KCiAgIFRoZSBjbGllbnQgU0hPVUxEIHZhbGlkYXRlIHRoZSBjZXJ0aWZpY2F0 ZSBhY2NvcmRpbmcgdG8gdGhlIHJ1bGVzCiAgIGRlZmluZWQgaW4gW1JGQzUyODBdLiAgQW4gaW1w bGVtZW50YXRpb24gbWF5IGNyZWF0ZSBhIGxvY2FsIHRydXN0CiAgIGNlcnRpZmljYXRlIHJlY29y ZCBmb3IgdmVyaWZpZWQgY2VydGlmaWNhdGVzIGluIG9yZGVyIHRvIGF2b2lkCiAgIHJlcGVhdGVk IHZlcmlmaWNhdGlvbiBwcm9jZWR1cmUgaW4gdGhlIGZ1dHVyZS4gIEEgY2VydGlmaWNhdGUgdGhh dAogICBmaW5kcyBhIG1hdGNoIGluIHRoZSBsb2NhbCB0cnVzdCBjZXJ0aWZpY2F0ZSBsaXN0IGlz IHRyZWF0ZWQgYXMKICAgdmVyaWZpZWQuICBBdCB0aGlzIHBvaW50LCB0aGUgY2xpZW50IGhhcyBl aXRoZXIgcmVjb2duaXplZCB0aGUKICAgYXV0aGVudGljYXRpb24gb2YgdGhlIHNlcnZlciwgb3Ig ZGVjaWRlZCB0byBkcm9wIHRoZSBtZXNzYWdlLgoKICAgVGhlIGNsaWVudCBNVVNUIG5vdyBhdXRo ZW50aWNhdGUgdGhlIHNlcnZlciBieSB2ZXJpZnlpbmcgdGhlCiAgIHNpZ25hdHVyZSBhbmQgY2hl Y2tpbmcgdGltZXN0YW1wIGlmIHRoZXJlIGlzIGEgVGltZXN0YW1wIG9wdGlvbi4gIFRoZQogICBj bGllbnQgU0hPVUxEIGNoZWNrIHRpbWVzdGFtcCBhY2NvcmRpbmcgdG8gdGhlIHJ1bGVzIGRlZmlu ZWQgaW4KICAgU2VjdGlvbiA5LjEpLCBUaGUgb3JkZXIgb2YgdHdvIHByb2NlZHVyZXMgaXMgbGVm dCBhcyBhbgogICBpbXBsZW1lbnRhdGlvbiBkZWNpc2lvbi4gIEl0IGlzIFJFQ09NTUVOREVEIHRv IGNoZWNrIHRpbWVzdGFtcCBmaXJzdCwKCgoKSmlhbmcsIGV0IGFsLiAgICAgICAgICAgICBFeHBp cmVzIEp1bHkgMTYsIDIwMTYgICAgICAgICAgICAgICAgIFtQYWdlIDldCgwKSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICAgICBTZURIQ1B2NiAgICAgICAgICAgICAgICAgICAgSmFudWFyeSAy MDE2CgoKICAgYmVjYXVzZSBzaWduYXR1cmUgdmVyaWZpY2F0aW9uIGlzIG11Y2ggbW9yZSBjb21w dXRhdGlvbmFsbHkKICAgZXhwZW5zaXZlLgoKICAgVGhlIHNpZ25hdHVyZSBmaWVsZCB2ZXJpZmlj YXRpb24gTVVTVCBzaG93IHRoYXQgdGhlIHNpZ25hdHVyZSBoYXMKICAgYmVlbiBjYWxjdWxhdGVk IGFzIHNwZWNpZmllZCBpbiBTZWN0aW9uIDEwLjEuMi4gIE9ubHkgdGhlIG1lc3NhZ2VzCiAgIHRo YXQgZ2V0IHRocm91Z2ggYm90aCB0aGUgc2lnbmF0dXJlIHZlcmlmaWNhdGlvbiBhbmQgdGltZXN0 YW1wIGNoZWNrCiAgIChpZiB0aGVyZSBpcyBhIFRpbWVzdGFtcCBvcHRpb24pIGFyZSBhY2NlcHRl ZC4gIFJlcGx5IG1lc3NhZ2UgdGhhdAogICBkb2VzIG5vdCBwYXNzIHRoZSBhYm92ZSB0ZXN0cyBN VVNUIGJlIGRpc2NhcmRlZC4KCiAgIElmIHRoZXJlIGFyZSBtdWx0aXBsZSBhdXRoZW50aWNhdGVk IERIQ1B2NiBzZXJ2ZXJzLCB0aGUgY2xpZW50CiAgIHNlbGVjdHMgb25lIERIQ1B2NiBzZXJ2ZXIg Zm9yIHRoZSBmb2xsb3dpbmcgbmV0d29yayBwYXJhbWV0ZXJzCiAgIGNvbmZpZ3VyYXRpb24uICBJ ZiB0aGVyZSBhcmUgbm8gYXV0aGVudGljYXRlZCBESENQdjYgc2VydmVycyBvcgpCVj4gQ291bGQg YWxzbyBhbGxvdyBjbGllbnQgdG8gdHJ5IG11bHRpcGxlIHRyYW5zYWN0aW9ucyAoZWFjaCB3aXRo CQpCVj4gZGlmZmVyZW50IHNlcnZlcikgYXQgdGhlICJzYW1lIiB0aW1lPyBJJ20gbm90IHN1cmUg d2hldGhlciB0aGF0CQpCVj4gaXMgYmV0dGVyIG9yIHRvbyBjb21wbGV4LCBidXQgSSBkb24ndCB0 aGluayB3ZSB3YW50IHRoaXMgZG9jdW1lbnQJCkJWPiB0byByZXF1aXJlIG9uZSBzcGVjaWZpYyBt ZXRob2Q/CQpMUz4gRm9yIHRoZSBtdWx0aXBsZSBhdXRoZW50aWNhdGVkIERIQ1B2NiBzZXJ2ZXIg c2NlbmFyaW8sIHRoZSBjbGllbnQJCkxTPiBoYXMgdHdvIGNob2ljZXM6IDEuIHNlbGVjdCBvbmUg REhDUHY2IHNlcnZlciBmb3IgdGhlIGZvbGxvd2luZwkKTFM+IG5ldHdvcmsgcGFyYW10ZXJzIGNv bmZpZ3VyYXRpb24uIElmIHRoZSBzZWxlY3RlZCBvbmUgY2Fubm90IGNvbmZpdXJlCQpMUz4gdGhl IHByb3BlciBwYXJhbWV0ZXJzLCBzZWxlY3QgYW5vdGhlciBvbmUgREhDUHY2IHNlcnZlcjsgMi4g dHJ5CQpMUz4gbXVsdGlwbGUgdHJhbnNhY3Rpb25zIChlYWNoIHdpdGggZGlmZmVyZW50IHNlcnZl cikgYXQgdGhlIHNhbWUJCkxTPiB0aW1lLiBJdCBpcyBkZWNpZGVkIGJ5IHRoZSBjbGllbnQncyBs b2NhbCBwb2xpY3kgYW5kIGltcGxlbWVudC4JCgogICBleGlzdGluZyBzZXJ2ZXJzIGZhaWxlZCBh dXRoZW50aWNhdGlvbiwgdGhlIGNsaWVudCBiZWhhdmlvciBpcyBwb2xpY3kKICAgc3BlY2lmaWMu ICBEZXBlbmRpbmcgb24gaXRzIHBvbGljeSwgaXQgY2FuIGNob29zZSB0byBjb25uZWN0IHVzaW5n CiAgIHBsYWluLCB1bmVuY3J5cHRlZCBESENQdjYsIHJlcGVhdCB0aGUgc2VydmVyIGRpc2NvdmVy eSBwcm9jZXNzIGFmdGVyCiAgIGNlcnRhaW4gZGVsYXkgb3IgYXR0ZW1wdCB0byBjb25uZWN0IHRv IGEgZGlmZmVyZW50IG5ldHdvcmsuICBUaGUKICAgY2xpZW50IE1VU1QgTk9UIGNvbmR1Y3QgdGhl IHNlcnZlciBkaXNjb3ZlcnkgcHJvY2VzcyBpbW1lZGlhdGVseSB0bwogICBhdm9pZCB0aGUgcGFj a2V0IHN0b3JtLgoKICAgT25jZSB0aGUgc2VydmVyIGhhcyBiZWVuIGF1dGhlbnRpY2F0ZWQsIHRo ZSBESENQdjYgY2xpZW50IHNlbmRzIHRoZQogICBFbmNyeXB0ZWQtUXVlcnkgbWVzc2FnZSB0byB0 aGUgREhDUHY2IHNlcnZlci4gIFRoZSBFbmNyeXB0ZWQtUXVlcnkKICAgbWVzc2FnZSBpcyBjb25z dHJ1Y3RlZCB3aXRoIHRoZSBFbmNyeXB0ZWQtbWVzc2FnZSBvcHRpb24sIHdoaWNoIE1VU1QKICAg YmUgY29uc3RydWN0ZWQgYXMgZXhwbGFpbmVkIGluIFNlY3Rpb24gMTAuMS40LCBhbmQgU2VydmVy IElkZW50aWZpZXIKICAgb3B0aW9uLiAgVGhlIEVuY3J5cHRlZC1tZXNzYWdlIG9wdGlvbiBjb250 YWlucyB0aGUgREhDUHY2IG1lc3NhZ2UKICAgdGhhdCBpcyBlbmNyeXB0ZWQgdXNpbmcgdGhlIHNl bGVjdGVkIHNlcnZlcidzIHB1YmxpYyBrZXkuICBUaGUgU2VydmVyCiAgIElkZW50aWZpZXIgb3B0 aW9uIGlzIGV4dGVybmFsbHkgdmlzaWJsZSB0byBhdm9pZCBkZWNyeXB0aW9uIGNvc3QgYnkKICAg dGhvc2UgdW5zZWxlY3RlZCBzZXJ2ZXJzLgoKICAgVGhlIGluZm9ybWF0aW9uIGZvciBjbGllbnQg YXV0aGVudGljYXRpb24gaXMgY29udGFpbmVkIGluIHRoZQogICBTb2xpY2l0L0luZm9ybWF0aW9u LXJlcXVlc3QgbWVzc2FnZSwgd2hpY2ggaXMgZW5jcnlwdGVkIGFuZCB0aGVuCiAgIGVuY2Fwc3Vs YXRlZCBpbnRvIHRoZSBFbmNyeXB0ZWQtUXVlcnkgbWVzc2FnZSB0byBhdm9pZCBjbGllbnQgcHJp dmFjeQogICBkaXNjbG9zdXJlLiAgVGhlIFNvbGljaXQvSW5mb3JtYXRpb24tcmVxdWVzdCBtZXNz YWdlIE1VU1QgY29udGFpbiB0aGUKICAgQ2VydGlmaWNhdGUgb3B0aW9uLCB3aGljaCBNVVNUIGJl IGNvbnN0cnVjdGVkIGFzIGV4cGxhaW5lZCBpbgogICBTZWN0aW9uIDEwLjEuMS4gIEluIGFkZGl0 aW9uLCBvbmUgYW5kIG9ubHkgb25lIFNpZ25hdHVyZSBvcHRpb24gTVVTVAogICBiZSBjb250YWlu ZWQsIHdoaWNoIE1VU1QgYmUgY29uc3RydWN0ZWQgYXMgZXhwbGFpbmVkIGluCiAgIFNlY3Rpb24g MTAuMS4yLiAgSXQgcHJvdGVjdHMgdGhlIG1lc3NhZ2UgaGVhZGVyIGFuZCBhbGwgREhDUHY2CiAg IG9wdGlvbnMgZXhjZXB0IGZvciB0aGUgQXV0aGVudGljYXRpb24gT3B0aW9uLiAgT25lIGFuZCBv bmx5IG9uZQogICBUaW1lc3RhbXAgb3B0aW9uLCB3aGljaCBNVVNUIGJlIGNvbnN0cnVjdGVkIGFz IGV4cGxhaW5lZCBpbgogICBTZWN0aW9uIDEwLjEuMy4gIFRoZSBUaW1lc3RhbXAgZmllbGQgU0hP VUxEIGJlIHNldCB0byB0aGUgY3VycmVudAogICB0aW1lLCBhY2NvcmRpbmcgdG8gc2VuZGVyJ3Mg cmVhbCB0aW1lIGNsb2NrLgoKICAgRm9yIHRoZSByZWNlaXZlZCBFbmNyeXB0ZWQtUmVzcG9uc2Ug bWVzc2FnZSwgdGhlIGNsaWVudCBleHRyYWN0cyB0aGUKICAgRW5jcnlwdGVkLW1lc3NhZ2Ugb3B0 aW9uIGFuZCBkZWNyeXB0cyBpdCB1c2luZyBpdHMgcHJpdmF0ZSBrZXkgdG8KICAgb2J0YWluIHRo ZSBvcmlnaW5hbCBESENQdjYgbWVzc2FnZS4gIFRoZW4gaXQgaGFuZGxlcyB0aGUgbWVzc2FnZSBh cwogICBwZXIgW1JGQzMzMTVdLiAgSWYgdGhlIGNsaWVudCBmYWlscyB0byBnZXQgdGhlIHByb3Bl ciBwYXJhbWV0ZXJzIGZyb20KICAgdGhlIGNob3NlbiBzZXJ2ZXIsIGl0IHNlbmRzIHRoZSBFbmNy eXB0ZWQtUXVlcnkgbWVzc2FnZSB0byBhbm90aGVyCiAgIGF1dGhlbnRpY2F0ZWQgc2VydmVyIGZv ciBwYXJhbWV0ZXJzIGNvbmZpZ3VyYXRpb24gdW50aWwgdGhlIGNsaWVudAogICBvYnRhaW5zIHRo ZSBwcm9wZXIgcGFyYW1ldGVycy4KCgoKSmlhbmcsIGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVz IEp1bHkgMTYsIDIwMTYgICAgICAgICAgICAgICAgW1BhZ2UgMTBdCgwKSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgICAgICBTZURIQ1B2NiAgICAgICAgICAgICAgICAgICAgSmFudWFyeSAyMDE2 CgoKICAgV2hlbiB0aGUgY2xpZW50IHJlY2VpdmVzIGEgUmVwbHkgbWVzc2FnZSB3aXRoIGFuIGVy cm9yIHN0YXR1cyBjb2RlLApCVj4gV2hhdCBpcyB0aGlzICJSZXBseSBtZXNzYWdlIiB0bz8gQ291 bGQgaXQgYmUgYW4gQWR2ZXJ0aXNlPyBOZWVkIHRvCQpCVj4gY2xhcmlmeSBleGFjdGx5IHdoZXJl IGluIHRoZSBwcm9jZXNzaW5nIHRoaXMgb2NjdXJzPwkKTFM+IFNvcnJ5IGZvciBub3QgdW5kZXJz dGFuZGluZyB0aGlzIHByb2JsZW0uIEFmdGVyIHNlbmRpbmcgdGhlCQpMUz4gSW5mb3JtYXRpb24t cmVxdWVzdCBtZXNzYWdlLCB0aGUgY2xpZW50IHdpbGwgcmVjZWl2ZSB0aGUgUmVwbHkgbWVzc2Fn ZQkKTFM+IHRvIHZlcmlmeSB0aGUgc2VydmVyJ3MgaWRlbnRpdHkuCiAgIHRoZSBlcnJvciBzdGF0 dXMgY29kZSBpbmRpY2F0ZXMgdGhlIGZhaWx1cmUgcmVhc29uIG9uIHRoZSBzZXJ2ZXIKICAgc2lk ZS4gIEFjY29yZGluZyB0byB0aGUgcmVjZWl2ZWQgc3RhdHVzIGNvZGUsIHRoZSBjbGllbnQgTUFZ IHRha2UKICAgZm9sbG93LXVwIGFjdGlvbjoKQlY+IEkgYXNzdW1lIHRoaXMgUmVwbHkgbWVzc2Fn ZSBpcyByZXR1cm5lZCB1bmF1dGhlbnRpY2F0ZWQgLSBpc24ndAkKQlY+IHNvbWUgZGlzY3Vzc2lv biBhYm91dCB0aGlzIHdhcnJhbnRlZD8gQSBEZW5pYWwgb2YgU2VydmljZSBhdHRhY2sJCkJWPiBt YXkgYmUgcG9zc2libGUgYnkgYSB0aGlyZCBwYXJ0eSB0aGF0IHNlbmRzIHRoZXNlIG1lc3NhZ2Vz PwkKTFM+IFRoYW5rcyBmb3IgdGhlIHZhbHVhYmxlIGNvbW1lbnRzLiBIb3cgYWJvdXQgYWRkaW5n IHRoZSBmb2xsb3dpbmcgCkxTPiB0ZXh0IGluIHNlY3VyaXR5IGNvbnNpZGVyYXRpb246CQpMUz4g V2hlbiB0aGUgREhDUHY2IHNlcnZlciByZWNlaXZlcyB0aGUgSW5mb3JtYXRpb24tcmVxdWVzdCBt ZXNzYWdlIGFuZAkKTFM+IHRoZSBjb250YWluZWQgT3B0aW9uIFJlcXVlc3Qgb3B0aW9uIGlkZW50 aWZpZXMgdGhlIHJlcXVlc3QgaXMgZm9yIHRoZQkKTFM+IHNlcnZlciBhdXRoZW50aWNhdGlvbiBp bmZvcm1hdGlvbiwgdGhlIFJlcGx5IG1lc3NhZ2UgaXMgcmV0dXJuZWQJCkxTPiB1bmF1dGhlbnRp Y2F0ZWQuIEEgRGVuaWFsIG9mIFNlcnZpY2UgYXR0YWNrIG1heSBiZSBwb3NzaWJsZSBieSBhCQpM Uz4gdGhpcmQgcGFydHkgdGhhdCBzZW5kcyB0aGUgUmVwbHkgbWVzc2FnZSB3aXRoIGFuIGVycm9y IHN0YXR1cyBjb2RlLgkKIAkJCkJWPiBUaGlzIHJhaXNlcyBhIHJlbGF0ZWQgaXNzdWUgLi4uIGZv ciB0aGUgRW5jcnlwdGVkLW1lc3NhZ2UsIGRvZXMJCkJWPiB0aGF0IGhlYWRlcidzIFhJRCBoYXZl IGFueSBjb25uZWN0aW9uIHRvIHRoZSBYSUQgb2YgdGhlIG9yaWdpbmFsCQpCVj4gY2xpZW50J3Mg bWVzc2FnZSBYSUQ/IFNob3VsZCBwZXJoYXBzIHRoZXNlIGJlIHJlY29tbWVuZGVkIHRvIGJlCQpC Vj4gZGlmZmVyZW50PwkKTFM+IEkgdGhpbmsgaXQgY2Fubm90IGJlIGRpZmZlcmVudC4gQmVjYXVz ZSB0aHJvdWdoIHRoZSBYSUQsIHRoZSBjbGllbnQJCkxTPiBhbmQgdGhlIHNlcnZlciBjYW4gZmlu ZCB0aGUgY29ycmVzcG9uZGluZyBwdWJsaWMga2V5IGZvciBlbmNyeXB0aW9uCQpMUz4gYW5kIGRl Y3J5cHRpb24uIFNvLCB0aGUgWElEIG5lZWQgdG8gYmUgc2FtZS4gQW5kIEkgdGhpbmsgdGhhdCB0 aGUgCkxTPiBzYW1lIFhJRCB3aWxsIG5vdCBicmluZyBzZWN1cml0eSBpc3N1ZS4gTG9va2luZyBm b3J3YXJkIHRvIHlvdXIgCkxTPiBmdXJ0aGVyIGd1aWRhbmNlLgoKICAgbyAgVXBvbiByZWNlaXZp bmcgYW4gQWxnb3JpdGhtTm90U3VwcG9ydGVkIGVycm9yIHN0YXR1cyBjb2RlLCB0aGUKICAgICAg Y2xpZW50IFNIT1VMRCByZXNlbmQgdGhlIG1lc3NhZ2UgcHJvdGVjdGVkIHdpdGggb25lIG9mIHRo ZQogICAgICBtYW5kYXRvcnkgYWxnb3JpdGhtcy4KCiAgIG8gIFVwb24gcmVjZWl2aW5nIGFuIEF1 dGhlbnRpY2F0aW9uRmFpbCBlcnJvciBzdGF0dXMgY29kZSwgdGhlIGNsaWVudAogICAgICBpcyBu b3QgYWJsZSB0byBidWlsZCB1cCB0aGUgc2VjdXJlIGNvbW11bmljYXRpb24gd2l0aCB0aGUKICAg ICAgcmVjaXBpZW50LiAgSG93ZXZlciwgdGhlcmUgbWF5IGJlIG90aGVyIERIQ1B2NiBzZXJ2ZXJz IGF2YWlsYWJsZQogICAgICB0aGF0IHN1Y2Nlc3NmdWxseSBjb21wbGV0ZSBhdXRoZW50aWNhdGlv bi4gIFRoZSBjbGllbnQgTUFZIHVzZSB0aGUKICAgICAgQXV0aGVudGljYXRpb25GYWlsIGFzIGEg aGludCBhbmQgc3dpdGNoIHRvIG90aGVyIHB1YmxpYyBrZXkKICAgICAgY2VydGlmaWNhdGUgaWYg aXQgaGFzIGFub3RoZXIgb25lOyBidXQgb3RoZXJ3aXNlIHRyZWF0IHRoZSBtZXNzYWdlCiAgICAg IGNvbnRhaW5pbmcgdGhlIHN0YXR1cyBjb2RlIGFzIGlmIGl0IGhhZCBub3QgYmVlbiByZWNlaXZl ZC4gIEJ1dCBpdAogICAgICBTSE9VTEQgTk9UIHJldHJ5IHdpdGggdGhlIHNhbWUgY2VydGlmaWNh dGUuICBIb3dldmVyLCBpZiB0aGUKICAgICAgY2xpZW50IGRlY2lkZXMgdG8gcmV0cmFuc21pdCB1 c2luZyB0aGUgc2FtZSBjZXJ0aWZpY2F0ZSBhZnRlcgogICAgICByZWNlaXZpbmcgQXV0aGVudGlj YXRpb25GYWlsLCBpdCBNVVNUIE5PVCByZXRyYW5zbWl0IGltbWVkaWF0ZWx5CiAgICAgIGFuZCBN VVNUIGZvbGxvdyBub3JtYWwgcmV0cmFuc21pc3Npb24gcm91dGluZXMgZGVmaW5lZCBpbgogICAg ICBbUkZDMzMxNV0uCgogICBvICBVcG9uIHJlY2VpdmluZyBhIFRpbWVzdGFtcEZhaWwgZXJyb3Ig c3RhdHVzIGNvZGUsIHRoZSBjbGllbnQgTUFZCiAgICAgIHJlc2VuZCB0aGUgbWVzc2FnZSB3aXRo IGFuIGFkanVzdGVkIHRpbWVzdGFtcCBhY2NvcmRpbmcgdG8gdGhlCiAgICAgIHJldHVybmVkIGNs b2NrIGZyb20gdGhlIERIQ1B2NiBzZXJ2ZXIuICBUaGUgY2xpZW50IFNIT1VMRCBOT1QKICAgICAg Y2hhbmdlIGl0cyBvd24gY2xvY2ssIGJ1dCBvbmx5IGNvbXB1dGUgYW4gb2Zmc2V0IGZvciB0aGUK ICAgICAgY29tbXVuaWNhdGlvbiBzZXNzaW9uLgoKICAgbyAgVXBvbiByZWNlaXZpbmcgYSBTaWdu YXR1cmVGYWlsIGVycm9yIHN0YXR1cyBjb2RlLCB0aGUgY2xpZW50IE1BWQogICAgICByZXNlbmQg dGhlIG1lc3NhZ2UgZm9sbG93aW5nIG5vcm1hbCByZXRyYW5zbWlzc2lvbiByb3V0aW5lcwogICAg ICBkZWZpbmVkIGluIFtSRkMzMzE1XS4KCjcuICBESENQdjYgU2VydmVyIEJlaGF2aW9yCgogICBG b3IgdGhlIHNlY3VyZSBESENQdjYgc2VydmVyLCBpdCBoYXMgYSBwdWJsaWMgY2VydGlmaWNhdGUu ICBUaGUKICAgc2VydmVyIGlzIHByZS1jb25maWd1cmVkIHdpdGggYSBwdWJsaWMga2V5IGNlcnRp ZmljYXRlLCB3aGljaCBpcwogICBzaWduZWQgYnkgYSBDQSB0cnVzdGVkIGJ5IHRoZSBzZXJ2ZXIs IGFuZCBpdHMgY29ycmVzcG9uZGluZyBwcml2YXRlCiAgIGtleS4KCiAgIFdoZW4gdGhlIERIQ1B2 NiBzZXJ2ZXIgcmVjZWl2ZXMgdGhlIEluZm9ybWF0aW9uLXJlcXVlc3QgbWVzc2FnZSBhbmQKICAg dGhlIGNvbnRhaW5lZCBPcHRpb24gUmVxdWVzdCBvcHRpb24gaWRlbnRpZmllcyB0aGUgcmVxdWVz dCBpcyBmb3IgdGhlCiAgIHNlcnZlciBhdXRoZW50aWNhdGlvbiBpbmZvcm1hdGlvbiwgaXQgcmVw bGllcyB3aXRoIGEgUmVwbHkgbWVzc2FnZSB0bwogICB0aGUgY2xpZW50LiAgVGhlIHJlcGx5IG1l c3NhZ2UgTVVTVCBjb250YWluIHRoZSByZXF1ZXN0ZWQgQ2VydGlmaWNhdGUKICAgb3B0aW9uLCB3 aGljaCBNVVNUIGJlIGNvbnN0cnVjdGVkIGFzIGV4cGxhaW5lZCBpbiBTZWN0aW9uIDEwLjEuMS4g IEluCiAgIGFkZGl0aW9uLCB0aGUgUmVwbHkgbWVzc2FnZSBNVVNUIGNvbnRhaW4gb25lIGFuZCBv bmx5IG9uZSBTaWduYXR1cmUKICAgb3B0aW9uLCB3aGljaCBNVVNUIGJlIGNvbnN0cnVjdGVkIGFz IGV4cGxhaW5lZCBpbiBTZWN0aW9uIDEwLjEuMi4gIEl0CiAgIHByb3RlY3RzIHRoZSBtZXNzYWdl IGhlYWRlciBhbmQgYWxsIERIQ1B2NiBvcHRpb25zIGV4Y2VwdCBmb3IgdGhlCiAgIEF1dGhlbnRp Y2F0aW9uIE9wdGlvbi4gIEJlc2lkZXMsIHRoZSBSZXBseSBtZXNzYWdlIFNIT1VMRCBjb250YWlu IG9uZQoKCgpKaWFuZywgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgSnVseSAxNiwgMjAxNiAg ICAgICAgICAgICAgICBbUGFnZSAxMV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAg IFNlREhDUHY2ICAgICAgICAgICAgICAgICAgICBKYW51YXJ5IDIwMTYKCgogICBhbmQgb25seSBv bmUgVGltZXN0YW1wIG9wdGlvbiwgd2hpY2ggTVVTVCBiZSBjb25zdHJ1Y3RlZCBhcyBleHBsYWlu ZWQKICAgaW4gU2VjdGlvbiAxMC4xLjMuICBUaGUgVGltZXN0YW1wIGZpZWxkIFNIT1VMRCBiZSBz ZXQgdG8gdGhlIGN1cnJlbnQKICAgdGltZSwgYWNjb3JkaW5nIHRvIHNlcnZlcidzIHJlYWwgdGlt ZSBjbG9jay4KCiAgIFVwb24gdGhlIHJlY2VpcHQgb2YgRW5jcnlwdGVkLVF1ZXJ5IG1lc3NhZ2Us IHRoZSBzZXJ2ZXIgY2hlY2tzIHRoZQogICBTZXJ2ZXIgSWRlbnRpZmllciBvcHRpb24uICBJdCBk ZWNyeXB0cyB0aGUgRW5jcnlwdGVkLW1lc3NhZ2Ugb3B0aW9uCiAgIHVzaW5nIGl0cyBwcml2YXRl IGtleSBpZiBpdCBpcyB0aGUgdGFyZ2V0IHNlcnZlci4gIFRoZSBESENQdjYgc2VydmVyCiAgIGRy b3BzIHRoZSBtZXNzYWdlIHRoYXQgaXMgbm90IGZvciBpdCwgdGh1cyBub3QgcGF5aW5nIGNvc3Qg dG8gZGVjcnlwdAogICBtZXNzYWdlcyBub3QgZm9yIGl0LgoKICAgSWYgdGhlIGRlY3J5cHRlZCBt ZXNzYWdlIGlzIGEgU29saWNpdC9JbmZvcm1hdGlvbi1yZXF1ZXN0IG1lc3NhZ2UsCiAgIHRoZSBz ZWN1cmUgREhDUHY2IHNlcnZlciBTSE9VTEQgZGlzY2FyZCB0aGUgcmVjZWl2ZWQgbWVzc2FnZSB0 aGF0CiAgIG1lZXQgYW55IG9mIHRoZSBmb2xsb3dpbmcgY29uZGl0aW9uczoKCiAgIG8gIHRoZSBT aWduYXR1cmUgb3B0aW9uIGlzIG1pc3NpbmcsCgogICBvICBtdWx0aXBsZSBTaWduYXR1cmUgb3B0 aW9ucyBhcmUgcHJlc2VudCwKCiAgIG8gIHRoZSBDZXJ0aWZpY2F0ZSBvcHRpb24gaXMgbWlzc2lu Zy4KCiAgIEluIHN1Y2ggZmFpbHVyZSwgdGhlIHNlcnZlciBTSE9VTEQgcmVwbHkgYW4gVW5zcGVj RmFpbCAodmFsdWUgMSwKICAgW1JGQzMzMTVdKSBlcnJvciBzdGF0dXMgY29kZS4KCiAgIFRoZSBz ZXJ2ZXIgU0hPVUxEIGZpcnN0IGNoZWNrIHRoZSBzdXBwb3J0IG9mIHRoZSBoYXNoIGFuZCBzaWdu YXR1cmUKICAgYWxnb3JpdGhtcyB0aGF0IHRoZSBjbGllbnQgdXNlZC4gIElmIHRoZSBjaGVjayBm YWlscywgdGhlIHNlcnZlcgogICBTSE9VTEQgcmVwbHkgd2l0aCBhbiBBbGdvcml0aG1Ob3RTdXBw b3J0ZWQgZXJyb3Igc3RhdHVzIGNvZGUsIGRlZmluZWQKICAgaW4gU2VjdGlvbiAxMC4zLCBiYWNr IHRvIHRoZSBjbGllbnQuICBJZiBib3RoIGhhc2ggYW5kIHNpZ25hdHVyZQogICBhbGdvcml0aG1z IGFyZSBzdXBwb3J0ZWQsIHRoZSBzZXJ2ZXIgdGhlbiBjaGVja3MgdGhlIGF1dGhvcml0eSBvZgog ICB0aGlzIGNsaWVudC4KCiAgIElmIGEgQ2VydGlmaWNhdGUgb3B0aW9uIGlzIHByb3ZpZGVkLCB0 aGUgc2VydmVyIFNIT1VMRCB2YWxpZGF0ZSB0aGUKICAgY2VydGlmaWNhdGUgYWNjb3JkaW5nIHRv IHRoZSBydWxlcyBkZWZpbmVkIGluIFtSRkM1MjgwXS4gIEFuCiAgIGltcGxlbWVudGF0aW9uIG1h eSBjcmVhdGUgYSBsb2NhbCB0cnVzdCBjZXJ0aWZpY2F0ZSByZWNvcmQgZm9yCiAgIHZlcmlmaWVk IGNlcnRpZmljYXRlcyBpbiBvcmRlciB0byBhdm9pZCByZXBlYXRlZCB2ZXJpZmljYXRpb24KICAg cHJvY2VkdXJlIGluIHRoZSBmdXR1cmUuICBBIGNlcnRpZmljYXRlIHRoYXQgZmluZHMgYSBtYXRj aCBpbiB0aGUKICAgbG9jYWwgdHJ1c3QgY2VydGlmaWNhdGUgbGlzdCBpcyB0cmVhdGVkIGFzIHZl cmlmaWVkLgoKICAgVGhlIG1lc3NhZ2UgdGhhdCBmYWlscyBjZXJ0aWZpY2F0ZSB2YWxpZGF0aW9u LCBNVVNUIGJlIGRyb3BwZWQuICBJbgogICBzdWNoIGZhaWx1cmUsIHRoZSBESENQdjYgc2VydmVy IFNIT1VMRCByZXBseSB3aXRoIGFuCiAgIEF1dGhlbnRpY2F0aW9uRmFpbCBlcnJvciBzdGF0dXMg Y29kZSwgZGVmaW5lZCBpbiBTZWN0aW9uIDEwLjMsIGJhY2sKICAgdG8gdGhlIGNsaWVudC4gIEF0 IHRoaXMgcG9pbnQsIHRoZSBzZXJ2ZXIgaGFzIGVpdGhlciByZWNvZ25pemVkIHRoZQogICBhdXRo ZW50aWNhdGlvbiBvZiB0aGUgY2xpZW50LCBvciBkZWNpZGVkIHRvIGRyb3AgdGhlIG1lc3NhZ2Uu CgogICBJZiB0aGUgY2xpZW50IGRvZXMgbm90IHNlbmQgdGhlIFRpbWVzdGFtcCBvcHRpb24sIHRo ZSBzZXJ2ZXIgaWdub3JlcwogICB0aGUgdGltZXN0YW1wIGNoZWNrIGFuZCB2ZXJpZmllcyB0aGUg c2lnbmF0dXJlLiAgSWYgdGhlcmUgaXMgYQogICBUaW1lc3RhbXAgb3B0aW9uLCB0aGUgc2VydmVy IE1VU1Qgbm93IGF1dGhlbnRpY2F0ZSB0aGUgY2xpZW50IGJ5CiAgIHZlcmlmeWluZyB0aGUgc2ln bmF0dXJlIGFuZCBjaGVja2luZyB0aW1lc3RhbXAgKHNlZSBkZXRhaWxzIGluCiAgIFNlY3Rpb24g OS4xKS4gIFRoZSBvcmRlciBvZiB0d28gcHJvY2VkdXJlcyBpcyBsZWZ0IGFzIGFuCgoKCkppYW5n LCBldCBhbC4gICAgICAgICAgICAgRXhwaXJlcyBKdWx5IDE2LCAyMDE2ICAgICAgICAgICAgICAg IFtQYWdlIDEyXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgU2VESENQdjYgICAg ICAgICAgICAgICAgICAgIEphbnVhcnkgMjAxNgoKCiAgIGltcGxlbWVudGF0aW9uIGRlY2lzaW9u LiAgSXQgaXMgUkVDT01NRU5ERUQgdG8gY2hlY2sgdGltZXN0YW1wIGZpcnN0LAogICBiZWNhdXNl IHNpZ25hdHVyZSB2ZXJpZmljYXRpb24gaXMgbXVjaCBtb3JlIGNvbXB1dGF0aW9uYWxseQogICBl eHBlbnNpdmUuICBEZXBlbmRpbmcgb24gc2VydmVyJ3MgbG9jYWwgcG9saWN5LCB0aGUgbWVzc2Fn ZSB3aXRob3V0IGEKICAgVGltZXN0YW1wIG9wdGlvbiBNQVkgYmUgYWNjZXB0YWJsZSBvciByZWpl Y3RlZC4gIElmIHRoZSBzZXJ2ZXIKICAgcmVqZWN0cyBzdWNoIGEgbWVzc2FnZSwgYSBUaW1lc3Rh bXBGYWlsIGVycm9yIHN0YXR1cyBjb2RlLCBkZWZpbmVkIGluCiAgIFNlY3Rpb24gMTAuMywgc2hv dWxkIGJlIHNlbnQgYmFjayB0byB0aGUgY2xpZW50LiAgVGhlIHJlcGx5IG1lc3NhZ2UKICAgdGhh dCBjYXJyaWVzIHRoZSBUaW1lc3RhbXBGYWlsIGVycm9yIHN0YXR1cyBjb2RlIFNIT1VMRCBjYXJy eSBhCiAgIFRpbWVzdGFtcCBvcHRpb24sIHdoaWNoIGluZGljYXRlcyB0aGUgc2VydmVyJ3MgY2xv Y2sgZm9yIHRoZSBjbGllbnQKICAgdG8gdXNlLgoKICAgVGhlIHNpZ25hdHVyZSBmaWVsZCB2ZXJp ZmljYXRpb24gTVVTVCBzaG93IHRoYXQgdGhlIHNpZ25hdHVyZSBoYXMKICAgYmVlbiBjYWxjdWxh dGVkIGFzIHNwZWNpZmllZCBpbiBTZWN0aW9uIDEwLjEuMi4gIE9ubHkgdGhlIGNsaWVudHMKICAg dGhhdCBnZXQgdGhyb3VnaCBib3RoIHRoZSBzaWduYXR1cmUgdmVyaWZpY2F0aW9uIGFuZCB0aW1l c3RhbXAgY2hlY2sKICAgKGlmIHRoZXJlIGlzIGEgVGltZXN0YW1wIG9wdGlvbikgYXJlIGFjY2Vw dGVkIGFzIGF1dGhlbnRpY2F0ZWQKICAgY2xpZW50cyBhbmQgY29udGludWUgdG8gYmUgaGFuZGxl ZCB0aGVpciBtZXNzYWdlIGFzIGRlZmluZWQgaW4KICAgW1JGQzMzMTVdLiAgQ2xpZW50cyB0aGF0 IGRvIG5vdCBwYXNzIHRoZSBhYm92ZSB0ZXN0cyBNVVNUIGJlIHRyZWF0ZWQKICAgYXMgdW5hdXRo ZW50aWNhdGVkIGNsaWVudHMuICBUaGUgREhDUHY2IHNlcnZlciBTSE9VTEQgcmVwbHkgYQogICBT aWduYXR1cmVGYWlsIGVycm9yIHN0YXR1cyBjb2RlLCBkZWZpbmVkIGluIFNlY3Rpb24gMTAuMywg Zm9yIHRoZQogICBzaWduYXR1cmUgdmVyaWZpY2F0aW9uIGZhaWx1cmU7IG9yIGEgVGltZXN0YW1w RmFpbCBlcnJvciBzdGF0dXMgY29kZSwKICAgZGVmaW5lZCBpbiBTZWN0aW9uIDEwLjMsIGZvciB0 aGUgdGltZXN0YW1wIGNoZWNrIGZhaWx1cmUsIGJhY2sgdG8gdGhlCiAgIGNsaWVudC4KCiAgIE9u Y2UgdGhlIGNsaWVudCBoYXMgYmVlbiBhdXRoZW50aWNhdGVkLCB0aGUgREhDUHY2IHNlcnZlciBz ZW5kcyB0aGUKICAgRW5jcnlwdGVkLXJlc3BvbnNlIG1lc3NhZ2UgdG8gdGhlIERIQ1B2NiBjbGll bnQuICBUaGUgRW5jcnlwdGVkLQogICByZXNwb25zZSBtZXNzYWdlIGNvbnRhaW5zIHRoZSBFbmNy eXB0ZWQtbWVzc2FnZSBvcHRpb24sIHdoaWNoIE1VU1QgYmUKICAgY29uc3RydWN0ZWQgYXMgZXhw bGFpbmVkIGluIFNlY3Rpb24gMTAuMS40LiAgVGhlIEVuY3J5cHRlZC1tZXNzYWdlCiAgIG9wdGlv biBjb250YWlucyB0aGUgZW5jcnlwdGVkIERIQ1B2NiBtZXNzYWdlIHRoYXQgaXMgZW5jcnlwdGVk IHVzaW5nCiAgIHRoZSBhdXRoZW50aWNhdGVkIGNsaWVudCdzIHB1YmxpYyBrZXkuCgo4LiAgUmVs YXkgQWdlbnQgQmVoYXZpb3IKCiAgIFdoZW4gYSBESENQdjYgcmVsYXkgYWdlbnQgcmVjZWl2ZXMg YW4gRW5jcnlwdGVkLXF1ZXJ5IG9yIEVuY3J5cHRlZC0KICAgcmVzcG9uc2UgbWVzc2FnZSwgaXQg bWF5IG5vdCByZWNvZ25pemUgdGhpcyBtZXNzYWdlLiAgVGhlIHVua25vd24KICAgbWVzc2FnZXMg TVVTVCBiZSBmb3J3YXJkZWQgYXMgZGVzY3JpYmVzIGluIFtSRkM3MjgzXS4KCiAgIFdoZW4gYSBE SENQdjYgcmVsYXkgYWdlbnQgcmVjb2duaXplcyB0aGUgRW5jcnlwdGVkLXF1ZXJ5IGFuZAogICBF bmNyeXB0ZWQtcmVzcG9uc2UgbWVzc2FnZXMsIGl0IGZvcndhcmRzIHRoZSBtZXNzYWdlIGFjY29y ZGluZyB0bwogICBzZWN0aW9uIDIwIG9mIFtSRkMzMzE1XS4gIFRoZXJlIGlzIG5vdGhpbmcgbW9y ZSB0aGUgcmVsYXkgYWdlbnRzIGhhdmUKICAgdG8gZG8sIGl0IG5laXRoZXIgbmVlZHMgdG8gdmVy aWZ5IHRoZSBtZXNzYWdlcyBmcm9tIGNsaWVudCBvciBzZXJ2ZXIsCiAgIG5vciBhZGQgYW55IHNl Y3VyZSBESENQdjYgb3B0aW9ucy4gIEFjdHVhbGx5LCBieSBkZWZpbml0aW9uIGluIHRoaXMKICAg ZG9jdW1lbnQsIHJlbGF5IGFnZW50cyBTSE9VTEQgTk9UIGFkZCBhbnkgc2VjdXJlIERIQ1B2NiBv cHRpb25zLgoKICAgUmVsYXktZm9yd2FyZCBhbmQgUmVsYXktcmVwbHkgbWVzc2FnZXMgTVVTVCBO T1QgY29udGFpbiBhbnkKICAgYWRkaXRpb25hbCBDZXJ0aWZpY2F0ZSBvcHRpb24gb3IgU2lnbmF0 dXJlIG9wdGlvbiBvciBUaW1lc3RhbXAKICAgb3B0aW9uLCBhc2lkZSBmcm9tIHRob3NlIHByZXNl bnQgaW4gdGhlIGlubmVybW9zdCBlbmNhcHN1bGF0ZWQKICAgbWVzc2FnZXMgZnJvbSB0aGUgY2xp ZW50IG9yIHNlcnZlci4KCgoKCgpKaWFuZywgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgSnVs eSAxNiwgMjAxNiAgICAgICAgICAgICAgICBbUGFnZSAxM10KDApJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgICAgIFNlREhDUHY2ICAgICAgICAgICAgICAgICAgICBKYW51YXJ5IDIwMTYKCgo5 LiAgUHJvY2Vzc2luZyBSdWxlcwoKOS4xLiAgVGltZXN0YW1wIENoZWNrCgogICBJbiBvcmRlciB0 byBjaGVjayB0aGUgVGltZXN0YW1wIG9wdGlvbiwgZGVmaW5lZCBpbiBTZWN0aW9uIDEwLjEuMywK ICAgcmVjaXBpZW50cyBTSE9VTEQgYmUgY29uZmlndXJlZCB3aXRoIGFuIGFsbG93ZWQgdGltZXN0 YW1wIERlbHRhCiAgIHZhbHVlLCBhICJmdXp6IGZhY3RvciIgZm9yIGNvbXBhcmlzb25zLCBhbmQg YW4gYWxsb3dlZCBjbG9jayBkcmlmdAogICBwYXJhbWV0ZXIuICBUaGUgcmVjb21tZW5kZWQgZGVm YXVsdCB2YWx1ZSBmb3IgdGhlIGFsbG93ZWQgRGVsdGEgaXMKICAgMzAwIHNlY29uZHMgKDUgbWlu dXRlcyk7IGZvciBmdXp6IGZhY3RvciAxIHNlY29uZDsgYW5kIGZvciBjbG9jawogICBkcmlmdCwg MC4wMSBzZWNvbmQuCgogICBOb3RlOiB0aGUgVGltZXN0YW1wIG1lY2hhbmlzbSBpcyBiYXNlZCBv biB0aGUgYXNzdW1wdGlvbiB0aGF0CiAgIGNvbW11bmljYXRpb24gcGVlcnMgaGF2ZSByb3VnaGx5 IHN5bmNocm9uaXplZCBjbG9ja3MsIHdpdGhpbiBjZXJ0YWluCiAgIGFsbG93ZWQgY2xvY2sgZHJp ZnQuICBTbywgYW4gYWNjdXJhdGUgY2xvY2sgaXMgbm90IG5lY2Vzc2FyeS4gIElmIG9uZQogICBo YXMgYSBjbG9jayB0b28gZmFyIGZyb20gdGhlIGN1cnJlbnQgdGltZSwgdGhlIHRpbWVzdGFtcCBt ZWNoYW5pc20KICAgd291bGQgbm90IHdvcmsuCgogICBUbyBmYWNpbGl0YXRlIHRpbWVzdGFtcCBj aGVja2luZywgZWFjaCByZWNpcGllbnQgU0hPVUxEIHN0b3JlIHRoZQogICBmb2xsb3dpbmcgaW5m b3JtYXRpb24gZm9yIGVhY2ggc2VuZGVyLCBmcm9tIHdoaWNoIGF0IGxlYXN0IG9uZQogICBhY2Nl cHRlZCBzZWN1cmUgREhDUHY2IG1lc3NhZ2UgaXMgc3VjY2Vzc2Z1bGx5IHZlcmlmaWVkIChmb3Ig Ym90aAogICB0aW1lc3RhbXAgY2hlY2sgYW5kIHNpZ25hdHVyZSB2ZXJpZmljYXRpb24pOgoKICAg byAgVGhlIHJlY2VpdmUgdGltZSBvZiB0aGUgbGFzdCByZWNlaXZlZCBhbmQgYWNjZXB0ZWQgREhD UHY2IG1lc3NhZ2UuCiAgICAgIFRoaXMgaXMgY2FsbGVkIFJEbGFzdC4KCiAgIG8gIFRoZSB0aW1l c3RhbXAgaW4gdGhlIGxhc3QgcmVjZWl2ZWQgYW5kIGFjY2VwdGVkIERIQ1B2NiBtZXNzYWdlLgog ICAgICBUaGlzIGlzIGNhbGxlZCBUU2xhc3QuCgogICBBIHZlcmlmaWVkIChmb3IgYm90aCB0aW1l c3RhbXAgY2hlY2sgYW5kIHNpZ25hdHVyZSB2ZXJpZmljYXRpb24pCiAgIHNlY3VyZSBESENQdjYg bWVzc2FnZSBpbml0aWF0ZXMgdGhlIHVwZGF0ZSBvZiB0aGUgYWJvdmUgdmFyaWFibGVzIGluCiAg IHRoZSByZWNpcGllbnQncyByZWNvcmQuCgogICBSZWNpcGllbnRzIE1VU1QgY2hlY2sgdGhlIFRp bWVzdGFtcCBmaWVsZCBhcyBmb2xsb3dzOgoKICAgbyAgV2hlbiBhIG1lc3NhZ2UgaXMgcmVjZWl2 ZWQgZnJvbSBhIG5ldyBwZWVyIChpLmUuLCBvbmUgdGhhdCBpcyBub3QKICAgICAgc3RvcmVkIGlu IHRoZSBjYWNoZSksIHRoZSByZWNlaXZlZCB0aW1lc3RhbXAsIFRTbmV3LCBpcyBjaGVja2VkLAog ICAgICBhbmQgdGhlIG1lc3NhZ2UgaXMgYWNjZXB0ZWQgaWYgdGhlIHRpbWVzdGFtcCBpcyByZWNl bnQgZW5vdWdoIHRvCiAgICAgIHRoZSByZWNlcHRpb24gdGltZSBvZiB0aGUgcGFja2V0LCBSRG5l dzoKCiAgICAgICAgIC1EZWx0YSA8IChSRG5ldyAtIFRTbmV3KSA8ICtEZWx0YQoKICAgICAgQWZ0 ZXIgdGhlIHNpZ25hdHVyZSB2ZXJpZmljYXRpb24gYWxzbyBzdWNjZWVkcywgdGhlIFJEbmV3IGFu ZAogICAgICBUU25ldyB2YWx1ZXMgU0hPVUxEIGJlIHN0b3JlZCBpbiB0aGUgY2FjaGUgYXMgUkRs YXN0IGFuZCBUU2xhc3QuCgogICBvICBXaGVuIGEgbWVzc2FnZSBpcyByZWNlaXZlZCBmcm9tIGEg a25vd24gcGVlciAoaS5lLiwgb25lIHRoYXQKICAgICAgYWxyZWFkeSBoYXMgYW4gZW50cnkgaW4g dGhlIGNhY2hlKSwgdGhlIHRpbWVzdGFtcCBpcyBjaGVja2VkCiAgICAgIGFnYWluc3QgdGhlIHBy ZXZpb3VzbHkgcmVjZWl2ZWQgU2VjdXJlIERIQ1B2NiBtZXNzYWdlOgoKCgoKSmlhbmcsIGV0IGFs LiAgICAgICAgICAgICBFeHBpcmVzIEp1bHkgMTYsIDIwMTYgICAgICAgICAgICAgICAgW1BhZ2Ug MTRdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICBTZURIQ1B2NiAgICAgICAgICAg ICAgICAgICAgSmFudWFyeSAyMDE2CgoKICAgICAgICAgVFNuZXcgKyBmdXp6ID4gVFNsYXN0ICsg KFJEbmV3IC0gUkRsYXN0KSB4ICgxIC0gZHJpZnQpIC0gZnV6egoKICAgICAgSWYgdGhpcyBpbmVx dWFsaXR5IGRvZXMgbm90IGhvbGQgb3IgUkRuZXcgPCBSRGxhc3QsIHRoZSByZWNpcGllbnQKICAg ICAgU0hPVUxEIHNpbGVudGx5IGRpc2NhcmQgdGhlIG1lc3NhZ2UuICBJZiwgb24gdGhlIG90aGVy IGhhbmQsIHRoZQogICAgICBpbmVxdWFsaXR5IGhvbGRzLCB0aGUgcmVjaXBpZW50IFNIT1VMRCBw cm9jZXNzIHRoZSBtZXNzYWdlLgoKICAgICAgTW9yZW92ZXIsIGlmIHRoZSBhYm92ZSBpbmVxdWFs aXR5IGhvbGRzIGFuZCBUU25ldyA+IFRTbGFzdCwgdGhlCiAgICAgIHJlY2lwaWVudCBTSE9VTEQg dXBkYXRlIFJEbGFzdCBhbmQgVFNsYXN0IGFmdGVyIHRoZSBzaWduYXR1cmUKICAgICAgdmVyaWZp Y2F0aW9uIGFsc28gc3VjY2Vzc2VzLiAgT3RoZXJ3aXNlLCB0aGUgcmVjaXBpZW50IE1VU1QgTk9U CiAgICAgIHVwZGF0ZSBSRGxhc3Qgb3IgVFNsYXN0LgoKICAgQW4gaW1wbGVtZW50YXRpb24gTUFZ IHVzZSBzb21lIG1lY2hhbmlzbSBzdWNoIGFzIGEgdGltZXN0YW1wIGNhY2hlIHRvCiAgIHN0cmVu Z3RoZW4gcmVzaXN0YW5jZSB0byByZXBsYXkgYXR0YWNrcy4gIFdoZW4gdGhlcmUgaXMgYSB2ZXJ5 IGxhcmdlCiAgIG51bWJlciBvZiBub2RlcyBvbiB0aGUgc2FtZSBsaW5rLCBvciB3aGVuIGEgY2Fj aGUgZmlsbGluZyBhdHRhY2sgaXMKICAgaW4gcHJvZ3Jlc3MsIGl0IGlzIHBvc3NpYmxlIHRoYXQg dGhlIGNhY2hlIGhvbGRpbmcgdGhlIG1vc3QgcmVjZW50CiAgIHRpbWVzdGFtcCBwZXIgc2VuZGVy IHdpbGwgYmVjb21lIGZ1bGwuICBJbiB0aGlzIGNhc2UsIHRoZSBub2RlIE1VU1QKICAgcmVtb3Zl IHNvbWUgZW50cmllcyBmcm9tIHRoZSBjYWNoZSBvciByZWZ1c2Ugc29tZSBuZXcgcmVxdWVzdGVk CiAgIGVudHJpZXMuICBUaGUgc3BlY2lmaWMgcG9saWN5IGFzIHRvIHdoaWNoIGVudHJpZXMgYXJl IHByZWZlcnJlZCBvdmVyCiAgIG90aGVycyBpcyBsZWZ0IGFzIGFuIGltcGxlbWVudGF0aW9uIGRl Y2lzaW9uLgoKICAgQW4gaW1wbGVtZW50YXRpb24gTUFZIHN0YXRlZnVsbHkgcmVjb3JkIHRoZSBs YXRlc3QgdGltZXN0YW1wcyBmcm9tCiAgIHNlbmRlcnMuICBJbiBzdWNoIGltcGxlbWVudGF0aW9u LCB0aGUgdGltZXN0YW1wcyBNVVNUIGJlIHN0cmljdGx5CiAgIG1vbm90b25vdXNseSBpbmNyZWFz aW5nLiAgVGhpcyBpcyByZWFzb25hYmxlIGdpdmVuIHRoYXQgREhDUHY2CiAgIG1lc3NhZ2VzIGFy ZSByYXJlbHkgbWlzb3JkZXJlZC4KCjEwLiAgRXh0ZW5zaW9ucyBmb3IgU2VjdXJlIERIQ1B2NgoK ICAgVGhpcyBzZWN0aW9uIGRlc2NyaWJlcyB0aGUgZXh0ZW5zaW9ucyB0byBESENQdjYuICBGaXZl IG5ldyBESENQdjYKICAgb3B0aW9ucywgdHdvIG5ldyBESENQdjYgbWVzc2FnZXMgYW5kIGZpdmUg c3RhdHVzIGNvZGVzIGFyZSBkZWZpbmVkLgoKMTAuMS4gIE5ldyBESENQdjYgT3B0aW9ucwoKMTAu MS4xLiAgQ2VydGlmaWNhdGUgb3B0aW9uCgogICBUaGUgQ2VydGlmaWNhdGUgb3B0aW9uIGNhcnJp ZXMgdGhlIHB1YmxpYyBrZXkgY2VydGlmaWNhdGUgb2YgdGhlCiAgIGNsaWVudC9zZXJ2ZXIuICBU aGUgZm9ybWF0IG9mIHRoZSBDZXJ0aWZpY2F0ZSBvcHRpb24gaXMgZGVzY3JpYmVkIGFzCiAgIGZv bGxvd3M6CgoKCgoKCgoKCgoKCgoKSmlhbmcsIGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVzIEp1 bHkgMTYsIDIwMTYgICAgICAgICAgICAgICAgW1BhZ2UgMTVdCgwKSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgICAgICBTZURIQ1B2NiAgICAgICAgICAgICAgICAgICAgSmFudWFyeSAyMDE2CgoK ICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAg ICAgICAgIDMKICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEg MiAzIDQgNSA2IDcgOCA5IDAgMQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICAgICAgT1BUSU9OX0NFUlRJRklD QVRFICAgICAgIHwgICAgICAgICBvcHRpb24tbGVuICAgICAgICAgICAgfAogICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwog ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfAogICAuICAgICAgICAgICAgICAgICAgICBDZXJ0aWZpY2F0ZSAodmFyaWFibGUg bGVuZ3RoKSAgICAgICAgICAgICAgLgogICAuICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLgogICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwoKICAgb3B0aW9u LWNvZGUgICAgT1BUSU9OX0NFUlRJRklDQVRFIChUQkExKS4KCiAgIG9wdGlvbi1sZW4gICAgIExl bmd0aCBvZiBjZXJ0aWZpY2F0ZSBpbiBvY3RldHMuCgogICBDZXJ0aWZpY2F0ZSAgICBBIHZhcmlh YmxlLWxlbmd0aCBmaWVsZCBjb250YWluaW5nIGNlcnRpZmljYXRlLiBUaGUKICAgICAgICAgICAg ICAgICAgZW5jb2Rpbmcgb2YgY2VydGlmaWNhdGUgYW5kIGNlcnRpZmljYXRlIGRhdGEgTVVTVAog ICAgICAgICAgICAgICAgICBiZSBpbiBmb3JtYXQgYXMgZGVmaW5lZCBpbiBTZWN0aW9uIDMuNiwg W1JGQzcyOTZdLgogICAgICAgICAgICAgICAgICBUaGUgc3VwcG9ydCBvZiBYLjUwOSBjZXJ0aWZp Y2F0ZSAtIFNpZ25hdHVyZSAoNCkKICAgICAgICAgICAgICAgICAgaXMgbWFuZGF0b3J5LgoKMTAu MS4yLiAgU2lnbmF0dXJlIG9wdGlvbgoKICAgVGhlIFNpZ25hdHVyZSBvcHRpb24gYWxsb3dzIGEg c2lnbmF0dXJlIHRoYXQgaXMgc2lnbmVkIGJ5IHRoZSBwcml2YXRlCiAgIGtleSB0byBiZSBhdHRh Y2hlZCB0byBhIERIQ1B2NiBtZXNzYWdlLiAgVGhlIFNpZ25hdHVyZSBvcHRpb24gY291bGQKICAg YmUgYW55IHBsYWNlIHdpdGhpbiB0aGUgREhDUHY2IG1lc3NhZ2Ugd2hpbGUgaXQgaXMgbG9naWNh bGx5IGNyZWF0ZWQKICAgYWZ0ZXIgdGhlIGVudGlyZSBESENQdjYgaGVhZGVyIGFuZCBvcHRpb25z LCBleGNlcHQgZm9yIHRoZQogICBBdXRoZW50aWNhdGlvbiBPcHRpb24uICBJdCBwcm90ZWN0cyB0 aGUgZW50aXJlIERIQ1B2NiBoZWFkZXIgYW5kCiAgIG9wdGlvbnMsIGluY2x1ZGluZyBpdHNlbGYs IGV4Y2VwdCBmb3IgdGhlIEF1dGhlbnRpY2F0aW9uIE9wdGlvbi4gIFRoZQogICBmb3JtYXQgb2Yg dGhlIFNpZ25hdHVyZSBvcHRpb24gaXMgZGVzY3JpYmVkIGFzIGZvbGxvd3M6CgogICAgMCAgICAg ICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMwog ICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYg NyA4IDkgMCAxCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAgIE9QVElPTl9TSUdOQVRVUkUgICAgICAgICAg fCAgICAgICAgb3B0aW9uLWxlbiAgICAgICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAgIEhB LWlkICAgICB8ICAgICBTQS1pZCAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8CiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8CiAgIC4gICAgICAgICAgICAgICAgICAgIFNpZ25hdHVy ZSAodmFyaWFibGUgbGVuZ3RoKSAgICAgICAgICAgICAgICAuCiAgIC4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAuCiAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rCgogICBvcHRpb24tY29kZSAgICBPUFRJT05fU0lHTkFUVVJFIChUQkEyKS4KCiAgIG9wdGlv bi1sZW4gICAgIDIgKyBMZW5ndGggb2YgU2lnbmF0dXJlIGZpZWxkIGluIG9jdGV0cy4KCiAgIEhB LWlkICAgICAgICAgIEhhc2ggQWxnb3JpdGhtIGlkLiBUaGUgaGFzaCBhbGdvcml0aG0gaXMgdXNl ZCBmb3IKICAgICAgICAgICAgICAgICAgY29tcHV0aW5nIHRoZSBzaWduYXR1cmUgcmVzdWx0LiBU aGlzIGRlc2lnbiBpcwoKCgpKaWFuZywgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgSnVseSAx NiwgMjAxNiAgICAgICAgICAgICAgICBbUGFnZSAxNl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgICAgIFNlREhDUHY2ICAgICAgICAgICAgICAgICAgICBKYW51YXJ5IDIwMTYKCgogICAg ICAgICAgICAgICAgICBhZG9wdGVkIGluIG9yZGVyIHRvIHByb3ZpZGUgaGFzaCBhbGdvcml0aG0g YWdpbGl0eS4KICAgICAgICAgICAgICAgICAgVGhlIHZhbHVlIGlzIGZyb20gdGhlIEhhc2ggQWxn b3JpdGhtIGZvciBTZWN1cmUKICAgICAgICAgICAgICAgICAgREhDUHY2IHJlZ2lzdHJ5IGluIElB TkEuIFRoZSBzdXBwb3J0IG9mIFNIQS0yNTYgaXMKICAgICAgICAgICAgICAgICAgbWFuZGF0b3J5 LiBBIHJlZ2lzdHJ5IG9mIHRoZSBpbml0aWFsIGFzc2lnbmVkIHZhbHVlcwogICAgICAgICAgICAg ICAgICBpcyBkZWZpbmVkIGluIFNlY3Rpb24gMTIuCgogICBTQS1pZCAgICAgICAgICBTaWduYXR1 cmUgQWxnb3JpdGhtIGlkLiBUaGUgc2lnbmF0dXJlIGFsZ29yaXRobSBpcwogICAgICAgICAgICAg ICAgICB1c2VkIGZvciBjb21wdXRpbmcgdGhlIHNpZ25hdHVyZSByZXN1bHQuIFRoaXMKICAgICAg ICAgICAgICAgICAgZGVzaWduIGlzIGFkb3B0ZWQgaW4gb3JkZXIgdG8gcHJvdmlkZSBzaWduYXR1 cmUKICAgICAgICAgICAgICAgICAgYWxnb3JpdGhtIGFnaWxpdHkuIFRoZSB2YWx1ZSBpcyBmcm9t IHRoZSBTaWduYXR1cmUKICAgICAgICAgICAgICAgICAgQWxnb3JpdGhtIGZvciBTZWN1cmUgREhD UHY2IHJlZ2lzdHJ5IGluIElBTkEuIFRoZQogICAgICAgICAgICAgICAgICBzdXBwb3J0IG9mIFJT QVNTQS1QS0NTMS12MV81IGlzIG1hbmRhdG9yeS4gQQogICAgICAgICAgICAgICAgICByZWdpc3Ry eSBvZiB0aGUgaW5pdGlhbCBhc3NpZ25lZCB2YWx1ZXMgaXMgZGVmaW5lZAogICAgICAgICAgICAg ICAgICBpbiBTZWN0aW9uIDEyLgoKICAgU2lnbmF0dXJlICAgICAgQSB2YXJpYWJsZS1sZW5ndGgg ZmllbGQgY29udGFpbmluZyBhIGRpZ2l0YWwKICAgICAgICAgICAgICAgICAgc2lnbmF0dXJlLiBU aGUgc2lnbmF0dXJlIHZhbHVlIGlzIGNvbXB1dGVkIHdpdGgKICAgICAgICAgICAgICAgICAgdGhl IGhhc2ggYWxnb3JpdGhtIGFuZCB0aGUgc2lnbmF0dXJlIGFsZ29yaXRobSwKICAgICAgICAgICAg ICAgICAgYXMgZGVzY3JpYmVkIGluIEhBLWlkIGFuZCBTQS1pZC4gVGhlIHNpZ25hdHVyZQogICAg ICAgICAgICAgICAgICBjb25zdHJ1Y3RlZCBieSB1c2luZyB0aGUgc2VuZGVyJ3MgcHJpdmF0ZSBr ZXkKICAgICAgICAgICAgICAgICAgcHJvdGVjdHMgdGhlIGZvbGxvd2luZyBzZXF1ZW5jZSBvZiBv Y3RldHM6CgogICAgICAgICAgICAgICAgICAxLiBUaGUgREhDUHY2IG1lc3NhZ2UgaGVhZGVyLgoK ICAgICAgICAgICAgICAgICAgMi4gQWxsIERIQ1B2NiBvcHRpb25zIGluY2x1ZGluZyB0aGUgU2ln bmF0dXJlCiAgICAgICAgICAgICAgICAgIG9wdGlvbiAoZmlsbCB0aGUgc2lnbmF0dXJlIGZpZWxk IHdpdGggemVyb2VzKQogICAgICAgICAgICAgICAgICBleGNlcHQgZm9yIHRoZSBBdXRoZW50aWNh dGlvbiBPcHRpb24uCgogICAgICAgICAgICAgICAgICBUaGUgc2lnbmF0dXJlIGZpZWxkIE1VU1Qg YmUgcGFkZGVkLCB3aXRoIGFsbCAwLCB0bwogICAgICAgICAgICAgICAgICB0aGUgbmV4dCBvY3Rl dCBib3VuZGFyeSBpZiBpdHMgc2l6ZSBpcyBub3QgYQogICAgICAgICAgICAgICAgICBtdWx0aXBs ZSBvZiA4IGJpdHMuIFRoZSBwYWRkaW5nIGxlbmd0aCBkZXBlbmRzIG9uCiAgICAgICAgICAgICAg ICAgIHRoZSBzaWduYXR1cmUgYWxnb3JpdGhtLCB3aGljaCBpcyBpbmRpY2F0ZWQgaW4gdGhlCiAg ICAgICAgICAgICAgICAgIFNBLWlkIGZpZWxkLgoKICAgTm90ZTogaWYgYm90aCBzaWduYXR1cmUg YW5kIGF1dGhlbnRpY2F0aW9uIG9wdGlvbiBhcmUgcHJlc2VudCwKICAgU2lnbmF0dXJlIG9wdGlv biBkb2VzIG5vdCBwcm90ZWN0IHRoZSBBdXRoZW50aWNhdGlvbiBPcHRpb24uICBJdAogICBhbGxv d3MgdGhlIEF1dGhlbnRpY2F0aW9uIE9wdGlvbiB0byBiZSBjcmVhdGVkIGFmdGVyIHNpZ25hdHVy ZSBoYXMKICAgYmVlbiBjYWxjdWxhdGVkIGFuZCBmaWxsZWQgd2l0aCB0aGUgdmFsaWQgc2lnbmF0 dXJlLiAgSXQgaXMgYmVjYXVzZQogICBib3RoIG9wdGlvbnMgbmVlZCB0byBhcHBseSBoYXNoIGFs Z29yaXRobSB0byB3aG9sZSBtZXNzYWdlLCBzbyB0aGVyZQogICBtdXN0IGJlIGEgY2xlYXIgb3Jk ZXIgYW5kIHRoZXJlIGNhbiBiZSBvbmx5IG9uZSBsYXN0LWNyZWF0ZWQgb3B0aW9uLgogICBJbiBv cmRlciB0byBhdm9pZCB1cGRhdGUgW1JGQzMzMTVdIGJlY2F1c2Ugb2YgY2hhbmdpbmcgYXV0aCBv cHRpb24sCiAgIHRoZSBhdXRob3JzIGNob29zZSBub3QgaW5jbHVkZSBhdXRoZW50aWNhdGlvbiBv cHRpb24gaW4gdGhlCiAgIHNpZ25hdHVyZS4KCgoKCgoKCgpKaWFuZywgZXQgYWwuICAgICAgICAg ICAgIEV4cGlyZXMgSnVseSAxNiwgMjAxNiAgICAgICAgICAgICAgICBbUGFnZSAxN10KDApJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIFNlREhDUHY2ICAgICAgICAgICAgICAgICAgICBK YW51YXJ5IDIwMTYKCgoxMC4xLjMuICBUaW1lc3RhbXAgb3B0aW9uCgogICBUaGUgVGltZXN0YW1w IG9wdGlvbiBjYXJyaWVzIHRoZSBjdXJyZW50IHRpbWUgb24gdGhlIHNlbmRlci4gIEl0IGFkZHMK ICAgdGhlIGFudGktcmVwbGF5IHByb3RlY3Rpb24gdG8gdGhlIERIQ1B2NiBtZXNzYWdlcy4gIEl0 IGlzIG9wdGlvbmFsLgoKICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAg ICAyICAgICAgICAgICAgICAgICAgIDMKICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0 IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQogICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8ICAgICBP UFRJT05fVElNRVNUQU1QICAgICAgICAgIHwgICAgICAgIG9wdGlvbi1sZW4gICAgICAgICAgICAg fAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKwogICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfAogICB8ICAgICAgICAgICAgICAgICAgICAgVGltZXN0 YW1wICg2NC1iaXQpICAgICAgICAgICAgICAgICAgICAgICAgfAogICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfAogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKwoKICAgb3B0aW9uLWNvZGUgICAgT1BUSU9OX1RJTUVTVEFNUCAoVEJB MykuCgogICBvcHRpb24tbGVuICAgICA4LCBpbiBvY3RldHMuCgogICBUaW1lc3RhbXAgICAgICBU aGUgY3VycmVudCB0aW1lIG9mIGRheSAoU2VORC1mb3JtYXQgdGltZXN0YW1wCiAgICAgICAgICAg ICAgICAgIGluIFVUQyAoQ29vcmRpbmF0ZWQgVW5pdmVyc2FsIFRpbWUpLiBJdCBjYW4gcmVkdWNl CiAgICAgICAgICAgICAgICAgIHRoZSBkYW5nZXIgb2YgcmVwbGF5IGF0dGFja3MuIFRoZSB0aW1l c3RhbXAgZGF0YSBNVVNUCiAgICAgICAgICAgICAgICAgIGJlIGluIGZvcm1hdCBhcyBkZWZpbmVk IGluIFNlY3Rpb24gNS4zLjEsIFtSRkMzOTcxXS4KCjEwLjEuNC4gIEVuY3J5cHRlZC1tZXNzYWdl IE9wdGlvbgoKICAgVGhlIEVuY3J5cHRlZC1tZXNzYWdlIG9wdGlvbiBjYXJyaWVzIHRoZSBlbmNy eXB0ZWQgREhDUHY2IG1lc3NhZ2UKICAgd2l0aCB0aGUgcmVjaXBpZW50J3MgcHVibGljIGtleS4K CiAgIFRoZSBmb3JtYXQgb2YgdGhlIEVuY3J5cHRlZC1tZXNzYWdlIG9wdGlvbiBpczoKCiAgICAg IDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAg ICAgIDMKICAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAy IDMgNCA1IDYgNyA4IDkgMCAxCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgICB8ICAgICAgICAgIG9wdGlvbi1j b2RlICAgICAgICAgIHwgICAgICAgICAgIG9wdGlvbi1sZW4gICAgICAgICAgfAogICAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rCiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwKICAgICAuICAgICAgICAgICAgICAgICAgZW5jcnlwdGVkIERIQ1B2 NiBtZXNzYWdlICAgICAgICAgICAgICAgICAgICAgLgogICAgIC4gICAgICAgICAgICAgICAgICAg ICAgICh2YXJpYWJsZSkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAuCiAgICAgLiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IC4KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKwoKICAgICAgICAgICAgICAgICBGaWd1cmUgMTogRW5jcnlwdGVkLW1l c3NhZ2UgT3B0aW9uIEZvcm1hdAoKICAgb3B0aW9uLWNvZGUgIE9QVElPTl9FTkNSWVBURURfTVNH IChUQkE0KS4KCiAgIG9wdGlvbi1sZW4gIExlbmd0aCBvZiB0aGUgZW5jcnlwdGVkIERIQ1B2NiBt ZXNzYWdlLgoKCgpKaWFuZywgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgSnVseSAxNiwgMjAx NiAgICAgICAgICAgICAgICBbUGFnZSAxOF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAg ICAgIFNlREhDUHY2ICAgICAgICAgICAgICAgICAgICBKYW51YXJ5IDIwMTYKCgogICBlbmNyeXB0 ZWQgREhDUHY2IG1lc3NhZ2UgIEEgdmFyaWFibGUgbGVuZ3RoIGZpZWxkIGNvbnRhaW5pbmcgdGhl CiAgICAgIGVuY3J5cHRlZCBESENQdjYgbWVzc2FnZSBzZW50IGJ5IHRoZSBjbGllbnQgb3IgdGhl IHNlcnZlci4gIEluCiAgICAgIEVuY3J5cHRlZC1RdWVyeSBtZXNzYWdlLCBpdCBjb250YWlucyBl bmNyeXB0ZWQgREhDUHY2IG1lc3NhZ2Ugc2VudAogICAgICBieSBhIGNsaWVudC4gIEluIEVuY3J5 cHRlZC1yZXNwb25zZSBtZXNzYWdlLCBpdCBjb250YWlucyBlbmNyeXB0ZWQKICAgICAgREhDUHY2 IG1lc3NhZ2Ugc2VudCBieSBhIHNlcnZlci4KQlY+IFNlZSBjb21tZW50cyB0byAxMC4yLjEuIEFs c28sIEkgd29uZGVyIGlmIHRoZSBTZXJ2ZXIgSWRlbnRpZmllciBvcHRpb24JCkJWPiBzaG91bGQg YmUgaGVyZSB0b28gLSB0aGF0IHdvdWxkIGFsbG93IHRoZSBjbGllbnQgdG8gY2hlY2sgdGhlIHRy YW5zYWN0aW9uCQpCVj4gaWQgYW5kIHNlcnZlciBpZGVudGlmaWVyIHRvIGJlIHN1cmUgaXQgY2Ft ZSBmcm9tIHRoZSBjb3JyZWN0IHNlcnZlcj8gQnV0CQpCVj4gcGVyaGFwcyBYSUQgaXMgZW5vdWdo PwkKTFM+IEluIG15IG9wdGlvbiwgdGhlIFhJRCBjYW4gaGVscCB0aGUgY2xpZW50IGRldGVybWlu ZSB3aGV0aGVyIHRoZSBtZXNzYWdlCQpMUz4gY2FtZSBmcm9tIHRoZSBiZWZvcmUgY29ycmVjdCBz ZXJ2ZXIuIFdoYXQgaXMgeW91ciBvcHRpb24/CgoxMC4yLiAgTmV3IERIQ1B2NiBNZXNzYWdlcwoK ICAgVHdvIG5ldyBESENQdjYgbWVzc2FnZXMgYXJlIGRlZmluZWQgdG8gYWNoaWV2ZSB0aGUgREhD UHY2IGVuY3J5cHRpb246CiAgIEVuY3J5cHRlZC1RdWVyeSBhbmQgRW5jcnlwdGVkLVJlc3BvbnNl LiAgQm90aCB0aGUgREhDUHY2IG1lc3NhZ2VzCiAgIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCBz aGFyZSB0aGUgZm9sbG93aW5nIGZvcm1hdDoKCiAgICAgIDAgICAgICAgICAgICAgICAgICAgMSAg ICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMKICAgICAgMCAxIDIgMyA0IDUg NiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxCiAgICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsKICAgICB8ICAgIG1zZy10eXBlICAgfCAgICAgICAgICAgICAgIHRyYW5zYWN0aW9u LWlkICAgICAgICAgICAgICAgICAgfAogICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAu ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvcHRpb25zICAgICAgICAgICAgICAgICAgICAg ICAgICAgLgogICAgIC4gICAgICAgICAgICAgICAgICAgICAgICAgICAodmFyaWFibGUpICAgICAg ICAgICAgICAgICAgICAgICAgICAuCiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwoKICAgICAg RmlndXJlIDI6IFRoZSBmb3JtYXQgb2YgRW5jcnlwdGVkLVF1ZXJ5IGFuZCBFbmNyeXB0ZWQtUmVz cG9uc2UKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTWVzc2FnZXMKCiAgIG1zZy10 eXBlICAgICAgICBJZGVudGlmaWVyIG9mIHRoZSBtZXNzYWdlIHR5cGUuICBJdCBjYW4gYmUgZWl0 aGVyCiAgICAgICAgICAgICAgICAgICBFbmNyeXB0ZWQtUXVlcnkgKFRCQTUpIG9yIERIQ1B2Ni1S ZXNwb25zZSAoVEJBNikuCgogICB0cmFuc2FjdGlvbi1pZCAgVGhlIHRyYW5zYWN0aW9uIElEIGZv ciB0aGlzIG1lc3NhZ2UgZXhjaGFuZ2UuCgogICBvcHRpb25zICAgICAgICAgVGhlIEVuY3J5cHRl ZC1RdWVyeSBtZXNzYWdlIE1VU1QgY29udGFpbiB0aGUgU2VydmVyCiAgICAgICAgICAgICAgICAg ICBJZGVudGlmaWVyIG9wdGlvbiBhbmQgRW5jcnlwdGVkLW1lc3NhZ2Ugb3B0aW9uLiAgVGhlCiAg ICAgICAgICAgICAgICAgICBFbmNyeXB0ZWQtUmVzcG9uc2UgbWVzc2FnZSBNVVNUIGNvbnRhaW4g dGhlCiAgICAgICAgICAgICAgICAgICBFbmNyeXB0ZWQtbWVzc2FnZSBvcHRpb24uCgoxMC4zLiAg U3RhdHVzIENvZGVzCgogICBUaGUgZm9sbG93aW5nIG5ldyBzdGF0dXMgY29kZXMsIHNlZSBTZWN0 aW9uIDUuNCBvZiBbUkZDMzMxNV0gYXJlCiAgIGRlZmluZWQuCgogICBvICBBbGdvcml0aG1Ob3RT dXBwb3J0ZWQgKFRCRDcpOiBpbmRpY2F0ZXMgdGhhdCB0aGUgREhDUHY2IHNlcnZlcgogICAgICBk b2VzIG5vdCBzdXBwb3J0IGFsZ29yaXRobXMgdGhhdCBzZW5kZXIgdXNlZC4KCiAgIG8gIEF1dGhl bnRpY2F0aW9uRmFpbCAoVEJEOCk6IGluZGljYXRlcyB0aGF0IHRoZSBESENQdjYgY2xpZW50IGZh aWxzCiAgICAgIGF1dGhlbnRpY2F0aW9uIGNoZWNrLgoKCgoKCkppYW5nLCBldCBhbC4gICAgICAg ICAgICAgRXhwaXJlcyBKdWx5IDE2LCAyMDE2ICAgICAgICAgICAgICAgIFtQYWdlIDE5XQoMCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgU2VESENQdjYgICAgICAgICAgICAgICAgICAg IEphbnVhcnkgMjAxNgoKCiAgIG8gIFRpbWVzdGFtcEZhaWwgKFRCRDkpOiBpbmRpY2F0ZXMgdGhl IG1lc3NhZ2UgZnJvbSBESENQdjYgY2xpZW50CiAgICAgIGZhaWxzIHRoZSB0aW1lc3RhbXAgY2hl Y2suCgogICBvICBTaWduYXR1cmVGYWlsIChUQkQxMCk6IGluZGljYXRlcyB0aGUgbWVzc2FnZSBm cm9tIERIQ1B2NiBjbGllbnQKICAgICAgZmFpbHMgdGhlIHNpZ25hdHVyZSBjaGVjay4KCjExLiAg U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMKCiAgIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgdGhlIGF1 dGhlbnRpY2F0aW9uIGFuZCBlbmNyeXB0aW9uIG1lY2hhbmlzbXMKICAgZm9yIERIQ1B2Ni4KCiAg IFtSRkM2MjczXSBoYXMgYW5hbHl6ZWQgcG9zc2libGUgdGhyZWF0cyB0byB0aGUgaGFzaCBhbGdv cml0aG1zIHVzZWQKICAgaW4gU0VORC4gIFNpbmNlIHRoZSBTZWN1cmUgREhDUHY2IGRlZmluZWQg aW4gdGhpcyBkb2N1bWVudCB1c2VzIHRoZQogICBzYW1lIGhhc2ggYWxnb3JpdGhtcyBpbiBzaW1p bGFyIHdheSB0byBTRU5ELCBhbmFseXNpcyByZXN1bHRzIGNvdWxkCiAgIGJlIGFwcGxpZWQgYXMg d2VsbDogY3VycmVudCBhdHRhY2tzIG9uIGhhc2ggZnVuY3Rpb25zIGRvIG5vdAogICBjb25zdGl0 dXRlIGFueSBwcmFjdGljYWwgdGhyZWF0IHRvIHRoZSBkaWdpdGFsIHNpZ25hdHVyZXMgdXNlZCBp biB0aGUKICAgc2lnbmF0dXJlIGFsZ29yaXRobSBpbiB0aGUgU2VjdXJlIERIQ1B2Ni4KCiAgIEEg c2VydmVyLCB3aG9zZSBsb2NhbCBwb2xpY3kgYWNjZXB0cyBtZXNzYWdlcyB3aXRob3V0IGEgVGlt ZXN0YW1wCiAgIG9wdGlvbiwgbWF5IGhhdmUgdG8gZmFjZSB0aGUgcmlzayBvZiByZXBsYXkgYXR0 YWNrcy4KCiAgIEEgd2luZG93IG9mIHZ1bG5lcmFiaWxpdHkgZm9yIHJlcGxheSBhdHRhY2tzIGV4 aXN0cyB1bnRpbCB0aGUKICAgdGltZXN0YW1wIGV4cGlyZXMuICBTZWN1cmUgREhDUHY2IG5vZGVz IGFyZSBwcm90ZWN0ZWQgYWdhaW5zdCByZXBsYXkKICAgYXR0YWNrcyBhcyBsb25nIGFzIHRoZXkg Y2FjaGUgdGhlIHN0YXRlIGNyZWF0ZWQgYnkgdGhlIG1lc3NhZ2UKICAgY29udGFpbmluZyB0aGUg dGltZXN0YW1wLiAgVGhlIGNhY2hlZCBzdGF0ZSBhbGxvd3MgdGhlIG5vZGUgdG8KICAgcHJvdGVj dCBpdHNlbGYgYWdhaW5zdCByZXBsYXllZCBtZXNzYWdlcy4gIEhvd2V2ZXIsIG9uY2UgdGhlIG5v ZGUKICAgZmx1c2hlcyB0aGUgc3RhdGUgZm9yIHdoYXRldmVyIHJlYXNvbiwgYW4gYXR0YWNrZXIg Y2FuIHJlLWNyZWF0ZSB0aGUKICAgc3RhdGUgYnkgcmVwbGF5aW5nIGFuIG9sZCBtZXNzYWdlIHdo aWxlIHRoZSB0aW1lc3RhbXAgaXMgc3RpbGwgdmFsaWQuCiAgIEluIGFkZGl0aW9uLCB0aGUgZWZm ZWN0aXZlbmVzcyBvZiB0aW1lc3RhbXBzIGlzIGxhcmdlbHkgZGVwZW5kZW50CiAgIHVwb24gdGhl IGFjY3VyYWN5IG9mIHN5bmNocm9uaXphdGlvbiBiZXR3ZWVuIGNvbW11bmljYXRpbmcgbm9kZXMu CiAgIEhvd2V2ZXIsIGhvdyB0aGUgdHdvIGNvbW11bmljYXRpbmcgbm9kZXMgY2FuIGJlIHN5bmNo cm9uaXplZCBpcyBvdXQKICAgb2Ygc2NvcGUgb2YgdGhpcyB3b3JrLgoKICAgQXR0YWNrcyBhZ2Fp bnN0IHRpbWUgc3luY2hyb25pemF0aW9uIHByb3RvY29scyBzdWNoIGFzIE5UUCBbUkZDNTkwNV0K ICAgbWF5IGNhdXNlIFNlY3VyZSBESENQdjYgbm9kZXMgdG8gaGF2ZSBhbiBpbmNvcnJlY3QgdGlt ZXN0YW1wIHZhbHVlLgogICBUaGlzIGNhbiBiZSB1c2VkIHRvIGxhdW5jaCByZXBsYXkgYXR0YWNr cywgZXZlbiBvdXRzaWRlIHRoZSBub3JtYWwKICAgd2luZG93IG9mIHZ1bG5lcmFiaWxpdHkuICBU byBwcm90ZWN0IGFnYWluc3QgdGhlc2UgYXR0YWNrcywgaXQgaXMKICAgcmVjb21tZW5kZWQgdGhh dCBTZWN1cmUgREhDUHY2IG5vZGVzIGtlZXAgaW5kZXBlbmRlbnRseSBtYWludGFpbmVkCiAgIGNs b2NrcyBvciBhcHBseSBzdWl0YWJsZSBzZWN1cml0eSBtZWFzdXJlcyBmb3IgdGhlIHRpbWUKICAg c3luY2hyb25pemF0aW9uIHByb3RvY29scy4KCjEyLiAgSUFOQSBDb25zaWRlcmF0aW9ucwoKICAg VGhpcyBkb2N1bWVudCBkZWZpbmVzIGZpdmUgbmV3IERIQ1B2NiBbUkZDMzMxNV0gb3B0aW9ucy4g IFRoZSBJQU5BIGlzCiAgIHJlcXVlc3RlZCB0byBhc3NpZ24gdmFsdWVzIGZvciB0aGVzZSBmaXZl IG9wdGlvbnMgZnJvbSB0aGUgREhDUHY2CiAgIE9wdGlvbiBDb2RlcyB0YWJsZSBvZiB0aGUgREhD UHY2IFBhcmFtZXRlcnMgcmVnaXN0cnkgbWFpbnRhaW5lZCBpbgogICBodHRwOi8vd3d3LmlhbmEu b3JnL2Fzc2lnbm1lbnRzL2RoY3B2Ni1wYXJhbWV0ZXJzLiAgVGhlIGZpdmUgb3B0aW9ucwogICBh cmU6CgoKCkppYW5nLCBldCBhbC4gICAgICAgICAgICAgRXhwaXJlcyBKdWx5IDE2LCAyMDE2ICAg ICAgICAgICAgICAgIFtQYWdlIDIwXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAg U2VESENQdjYgICAgICAgICAgICAgICAgICAgIEphbnVhcnkgMjAxNgoKCiAgICAgIFRoZSBDZXJ0 aWZpY2F0ZSBvcHRpb24gKFRCQTEpLCBkZXNjcmliZWQgaW4gU2VjdGlvbiAxMC4xLjEuCgogICAg ICBUaGUgU2lnbmF0dXJlIG9wdGlvbiAoVEJBMiksIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDEwLjEu Mi4KCiAgICAgIFRoZSBUaW1lc3RhbXAgb3B0aW9uIChUQkEzKSxkZXNjcmliZWQgaW4gU2VjdGlv biAxMC4xLjMuCgogICAgICBUaGUgRW5jcnlwdGVkLW1lc3NhZ2Ugb3B0aW9uIChUQkE0KSwgZGVz Y3JpYmVkIGluIFNlY3Rpb24gMTAuMS40LgoKICAgVGhlIElBTkEgaXMgYWxzbyByZXF1ZXN0ZWQg dG8gYXNzaWduIHZhbHVlIGZvciB0aGVzZSB0d28gbWVzc2FnZXMKICAgZnJvbSB0aGUgREhDUHY2 IE1lc3NhZ2UgVHlwZXMgdGFibGUgb2YgdGhlIERIQ1B2NiBQYXJhbWV0ZXJzIHJlZ2lzdHJ5CiAg IG1haW50YWluZWQgaW4gaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9kaGNwdjYtcGFy YW1ldGVycy4gIFRoZQogICB0d28gbWVzc2FnZXMgYXJlOgoKICAgICAgVGhlIEVuY3J5cHRlZC1R dWVyeSBtZXNzYWdlIChUQkE1KSwgZGVzY3JpYmVkIGluIFNlY3Rpb24gMTAuMS40LgoKICAgICAg VGhlIEVuY3J5cHRlZC1SZXNwb25zZSBtZXNzYWdlIChUQkE2KSwgZGVzY3JpYmVkIGluCiAgICAg IFNlY3Rpb24gMTAuMS40LgoKICAgVGhlIElBTkEgaXMgYWxzbyByZXF1ZXN0ZWQgdG8gYWRkIHR3 byBuZXcgcmVnaXN0cnkgdGFibGVzIHRvIHRoZQogICBESENQdjYgUGFyYW1ldGVycyByZWdpc3Ry eSBtYWludGFpbmVkIGluCiAgIGh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvZGhjcHY2 LXBhcmFtZXRlcnMuICBUaGUgdHdvIHRhYmxlcwogICBhcmUgdGhlIEhhc2ggQWxnb3JpdGhtIGZv ciBTZWN1cmUgREhDUHY2IHRhYmxlIGFuZCB0aGUgU2lnbmF0dXJlCiAgIEFsZ29yaXRobSBmb3Ig U2VjdXJlIERIQ1B2NiB0YWJsZS4KCiAgIEluaXRpYWwgdmFsdWVzIGZvciB0aGVzZSByZWdpc3Ry aWVzIGFyZSBnaXZlbiBiZWxvdy4gIEZ1dHVyZQogICBhc3NpZ25tZW50cyBhcmUgdG8gYmUgbWFk ZSB0aHJvdWdoIFN0YW5kYXJkcyBBY3Rpb24gW1JGQzUyMjZdLgogICBBc3NpZ25tZW50cyBmb3Ig ZWFjaCByZWdpc3RyeSBjb25zaXN0IG9mIGEgbmFtZSwgYSB2YWx1ZSBhbmQgYSBSRkMKICAgbnVt YmVyIHdoZXJlIHRoZSByZWdpc3RyeSBpcyBkZWZpbmVkLgoKICAgSGFzaCBBbGdvcml0aG0gZm9y IFNlY3VyZSBESENQdjYuICBUaGUgdmFsdWVzIGluIHRoaXMgdGFibGUgYXJlIDgtYml0CiAgIHVu c2lnbmVkIGludGVnZXJzLiAgVGhlIGZvbGxvd2luZyBpbml0aWFsIHZhbHVlcyBhcmUgYXNzaWdu ZWQgZm9yCiAgIEhhc2ggQWxnb3JpdGhtIGZvciBTZWN1cmUgREhDUHY2IGluIHRoaXMgZG9jdW1l bnQ6CgogICAgICAgICAgICAgTmFtZSAgICAgICAgfCAgVmFsdWUgIHwgIFJGQ3MKICAgICAgLS0t LS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0KICAgICAgICAgICAgU0hB LTI1NiAgICAgIHwgICAgMCAgICB8IHRoaXMgZG9jdW1lbnQKICAgICAgICAgICAgU0hBLTUxMiAg ICAgIHwgICAgMSAgICB8IHRoaXMgZG9jdW1lbnQKCiAgIFNpZ25hdHVyZSBBbGdvcml0aG0gZm9y IFNlY3VyZSBESENQdjYuICBUaGUgdmFsdWVzIGluIHRoaXMgdGFibGUgYXJlCiAgIDgtYml0IHVu c2lnbmVkIGludGVnZXJzLiAgVGhlIGZvbGxvd2luZyBpbml0aWFsIHZhbHVlcyBhcmUgYXNzaWdu ZWQKICAgZm9yIFNpZ25hdHVyZSBBbGdvcml0aG0gZm9yIFNlY3VyZSBESENQdjYgaW4gdGhpcyBk b2N1bWVudDoKCiAgICAgICAgICAgICBOYW1lICAgICAgICB8ICBWYWx1ZSAgfCAgUkZDcwogICAg ICAtLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLQogICAgICAgUlNB U1NBLVBLQ1MxLXYxXzUgfCAgICAwICAgIHwgdGhpcyBkb2N1bWVudAoKCgoKCgpKaWFuZywgZXQg YWwuICAgICAgICAgICAgIEV4cGlyZXMgSnVseSAxNiwgMjAxNiAgICAgICAgICAgICAgICBbUGFn ZSAyMV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIFNlREhDUHY2ICAgICAgICAg ICAgICAgICAgICBKYW51YXJ5IDIwMTYKCgogICBJQU5BIGlzIHJlcXVlc3RlZCB0byBhc3NpZ24g dGhlIGZvbGxvd2luZyBuZXcgREhDUHY2IFN0YXR1cyBDb2RlcywKICAgZGVmaW5lZCBpbiBTZWN0 aW9uIDEwLjMsIGluIHRoZSBESENQdjYgUGFyYW1ldGVycyByZWdpc3RyeSBtYWludGFpbmVkCiAg IGluIGh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvZGhjcHY2LXBhcmFtZXRlcnM6Cgog ICAgICAgICBDb2RlICB8ICAgICAgICAgICBOYW1lICAgICAgICB8ICAgUmVmZXJlbmNlCiAgICAg IC0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLQogICAgICAg ICBUQkQ3ICB8IEFsZ29yaXRobU5vdFN1cHBvcnRlZCB8IHRoaXMgZG9jdW1lbnQKICAgICAgICAg VEJEOCAgfCAgIEF1dGhlbnRpY2F0aW9uRmFpbCAgfCB0aGlzIGRvY3VtZW50CiAgICAgICAgIFRC RDkgIHwgICAgIFRpbWVzdGFtcEZhaWwgICAgIHwgdGhpcyBkb2N1bWVudAogICAgICAgICBUQkQx MCB8ICAgICBTaWduYXR1cmVGYWlsICAgICB8IHRoaXMgZG9jdW1lbnQKCjEzLiAgQWNrbm93bGVk Z2VtZW50cwoKICAgVGhlIGF1dGhvcnMgd291bGQgbGlrZSB0byB0aGFuayBUb21layBNcnVnYWxz a2ksIEJlcm5pZSBWb2x6LCBSYW5keQogICBCdXNoLCBZaXUgTGVlLCBKaWFucGluZyBXdSwgU2Vh biBTaGVuLCBSYWxwaCBEcm9tcywgSmFyaSBBcmtrbywgU2VhbgogICBUdXJuZXIsIFN0ZXBoZW4g RmFycmVsbCwgQ2hyaXN0aWFuIEh1aXRlbWEsIFN0ZXBoZW4gS2VudCwgVGhvbWFzCiAgIEh1dGgs IERhdmlkIFNjaHVtYWNoZXIsIEZyYW5jaXMgRHVwb250LCBHYW5nIENoZW4sIFN1cmVzaCBLcmlz aG5hbiwKICAgRnJlZCBUZW1wbGluLCBSb2JlcnQgRWx6LCBOaWNvIFdpbGxpYW1zLCBFcmlrIEts aW5lLCBBbGFuIERlS29rLAogICBCZXJuYXJkIEFib2JhLCBTYW0gSGFydG1hbiwgUWkgU3VuLCBa aWxvbmcgTGl1IGFuZCBvdGhlciBtZW1iZXJzIG9mCiAgIHRoZSBJRVRGIERIQyB3b3JraW5nIGdy b3VwIGZvciB0aGVpciB2YWx1YWJsZSBjb21tZW50cy4KCiAgIFRoaXMgZG9jdW1lbnQgd2FzIHBy b2R1Y2VkIHVzaW5nIHRoZSB4bWwycmZjIHRvb2wgW1JGQzI2MjldLgoKMTQuICBSZWZlcmVuY2Vz CgoxNC4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtSRkMyMTE5XSAgQnJhZG5lciwgUy4s ICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlCiAgICAgICAgICAgICAgUmVx dWlyZW1lbnQgTGV2ZWxzIiwgQkNQIDE0LCBSRkMgMjExOSwKICAgICAgICAgICAgICBET0kgMTAu MTc0ODcvUkZDMjExOSwgTWFyY2ggMTk5NywKICAgICAgICAgICAgICA8aHR0cDovL3d3dy5yZmMt ZWRpdG9yLm9yZy9pbmZvL3JmYzIxMTk+LgoKICAgW1JGQzI0NjBdICBEZWVyaW5nLCBTLiBhbmQg Ui4gSGluZGVuLCAiSW50ZXJuZXQgUHJvdG9jb2wsIFZlcnNpb24gNgogICAgICAgICAgICAgIChJ UHY2KSBTcGVjaWZpY2F0aW9uIiwgUkZDIDI0NjAsIERPSSAxMC4xNzQ4Ny9SRkMyNDYwLAogICAg ICAgICAgICAgIERlY2VtYmVyIDE5OTgsIDxodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8v cmZjMjQ2MD4uCgogICBbUkZDMzMxNV0gIERyb21zLCBSLiwgRWQuLCBCb3VuZCwgSi4sIFZvbHos IEIuLCBMZW1vbiwgVC4sIFBlcmtpbnMsCiAgICAgICAgICAgICAgQy4sIGFuZCBNLiBDYXJuZXks ICJEeW5hbWljIEhvc3QgQ29uZmlndXJhdGlvbiBQcm90b2NvbAogICAgICAgICAgICAgIGZvciBJ UHY2IChESENQdjYpIiwgUkZDIDMzMTUsIERPSSAxMC4xNzQ4Ny9SRkMzMzE1LCBKdWx5CiAgICAg ICAgICAgICAgMjAwMywgPGh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmMzMzE1Pi4K CiAgIFtSRkMzOTcxXSAgQXJra28sIEouLCBFZC4sIEtlbXBmLCBKLiwgWmlsbCwgQi4sIGFuZCBQ LiBOaWthbmRlciwKICAgICAgICAgICAgICAiU0VjdXJlIE5laWdoYm9yIERpc2NvdmVyeSAoU0VO RCkiLCBSRkMgMzk3MSwKICAgICAgICAgICAgICBET0kgMTAuMTc0ODcvUkZDMzk3MSwgTWFyY2gg MjAwNSwKICAgICAgICAgICAgICA8aHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzM5 NzE+LgoKCgoKCgpKaWFuZywgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgSnVseSAxNiwgMjAx NiAgICAgICAgICAgICAgICBbUGFnZSAyMl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAg ICAgIFNlREhDUHY2ICAgICAgICAgICAgICAgICAgICBKYW51YXJ5IDIwMTYKCgogICBbUkZDNDQ0 M10gIENvbnRhLCBBLiwgRGVlcmluZywgUy4sIGFuZCBNLiBHdXB0YSwgRWQuLCAiSW50ZXJuZXQK ICAgICAgICAgICAgICBDb250cm9sIE1lc3NhZ2UgUHJvdG9jb2wgKElDTVB2NikgZm9yIHRoZSBJ bnRlcm5ldAogICAgICAgICAgICAgIFByb3RvY29sIFZlcnNpb24gNiAoSVB2NikgU3BlY2lmaWNh dGlvbiIsIFJGQyA0NDQzLAogICAgICAgICAgICAgIERPSSAxMC4xNzQ4Ny9SRkM0NDQzLCBNYXJj aCAyMDA2LAogICAgICAgICAgICAgIDxodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZj NDQ0Mz4uCgogICBbUkZDNTI4MF0gIENvb3BlciwgRC4sIFNhbnRlc3NvbiwgUy4sIEZhcnJlbGws IFMuLCBCb2V5ZW4sIFMuLAogICAgICAgICAgICAgIEhvdXNsZXksIFIuLCBhbmQgVy4gUG9saywg IkludGVybmV0IFguNTA5IFB1YmxpYyBLZXkKICAgICAgICAgICAgICBJbmZyYXN0cnVjdHVyZSBD ZXJ0aWZpY2F0ZSBhbmQgQ2VydGlmaWNhdGUgUmV2b2NhdGlvbiBMaXN0CiAgICAgICAgICAgICAg KENSTCkgUHJvZmlsZSIsIFJGQyA1MjgwLCBET0kgMTAuMTc0ODcvUkZDNTI4MCwgTWF5IDIwMDgs CiAgICAgICAgICAgICAgPGh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM1MjgwPi4K CiAgIFtSRkM1OTA1XSAgTWlsbHMsIEQuLCBNYXJ0aW4sIEouLCBFZC4sIEJ1cmJhbmssIEouLCBh bmQgVy4gS2FzY2gsCiAgICAgICAgICAgICAgIk5ldHdvcmsgVGltZSBQcm90b2NvbCBWZXJzaW9u IDQ6IFByb3RvY29sIGFuZCBBbGdvcml0aG1zCiAgICAgICAgICAgICAgU3BlY2lmaWNhdGlvbiIs IFJGQyA1OTA1LCBET0kgMTAuMTc0ODcvUkZDNTkwNSwgSnVuZSAyMDEwLAogICAgICAgICAgICAg IDxodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNTkwNT4uCgogICBbUkZDNzI4M10g IEN1aSwgWS4sIFN1biwgUS4sIGFuZCBULiBMZW1vbiwgIkhhbmRsaW5nIFVua25vd24gREhDUHY2 CiAgICAgICAgICAgICAgTWVzc2FnZXMiLCBSRkMgNzI4MywgRE9JIDEwLjE3NDg3L1JGQzcyODMs IEp1bHkgMjAxNCwKICAgICAgICAgICAgICA8aHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZv L3JmYzcyODM+LgoKICAgW1JGQzcyOTZdICBLYXVmbWFuLCBDLiwgSG9mZm1hbiwgUC4sIE5pciwg WS4sIEVyb25lbiwgUC4sIGFuZCBULgogICAgICAgICAgICAgIEtpdmluZW4sICJJbnRlcm5ldCBL ZXkgRXhjaGFuZ2UgUHJvdG9jb2wgVmVyc2lvbiAyCiAgICAgICAgICAgICAgKElLRXYyKSIsIFNU RCA3OSwgUkZDIDcyOTYsIERPSSAxMC4xNzQ4Ny9SRkM3Mjk2LCBPY3RvYmVyCiAgICAgICAgICAg ICAgMjAxNCwgPGh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM3Mjk2Pi4KCjE0LjIu ICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzCgogICBbUkZDMjYyOV0gIFJvc2UsIE0uLCAiV3JpdGlu ZyBJLURzIGFuZCBSRkNzIHVzaW5nIFhNTCIsIFJGQyAyNjI5LAogICAgICAgICAgICAgIERPSSAx MC4xNzQ4Ny9SRkMyNjI5LCBKdW5lIDE5OTksCiAgICAgICAgICAgICAgPGh0dHA6Ly93d3cucmZj LWVkaXRvci5vcmcvaW5mby9yZmMyNjI5Pi4KCiAgIFtSRkM0MjcwXSAgSG9mZm1hbiwgUC4gYW5k IEIuIFNjaG5laWVyLCAiQXR0YWNrcyBvbiBDcnlwdG9ncmFwaGljCiAgICAgICAgICAgICAgSGFz aGVzIGluIEludGVybmV0IFByb3RvY29scyIsIFJGQyA0MjcwLAogICAgICAgICAgICAgIERPSSAx MC4xNzQ4Ny9SRkM0MjcwLCBOb3ZlbWJlciAyMDA1LAogICAgICAgICAgICAgIDxodHRwOi8vd3d3 LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNDI3MD4uCgogICBbUkZDNTIyNl0gIE5hcnRlbiwgVC4g YW5kIEguIEFsdmVzdHJhbmQsICJHdWlkZWxpbmVzIGZvciBXcml0aW5nIGFuCiAgICAgICAgICAg ICAgSUFOQSBDb25zaWRlcmF0aW9ucyBTZWN0aW9uIGluIFJGQ3MiLCBCQ1AgMjYsIFJGQyA1MjI2 LAogICAgICAgICAgICAgIERPSSAxMC4xNzQ4Ny9SRkM1MjI2LCBNYXkgMjAwOCwKICAgICAgICAg ICAgICA8aHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzUyMjY+LgoKICAgW1JGQzYy NzNdICBLdWtlYywgQS4sIEtyaXNobmFuLCBTLiwgYW5kIFMuIEppYW5nLCAiVGhlIFNlY3VyZQog ICAgICAgICAgICAgIE5laWdoYm9yIERpc2NvdmVyeSAoU0VORCkgSGFzaCBUaHJlYXQgQW5hbHlz aXMiLCBSRkMgNjI3MywKICAgICAgICAgICAgICBET0kgMTAuMTc0ODcvUkZDNjI3MywgSnVuZSAy MDExLAogICAgICAgICAgICAgIDxodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNjI3 Mz4uCgoKCgoKSmlhbmcsIGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVzIEp1bHkgMTYsIDIwMTYg ICAgICAgICAgICAgICAgW1BhZ2UgMjNdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAg ICBTZURIQ1B2NiAgICAgICAgICAgICAgICAgICAgSmFudWFyeSAyMDE2CgoKICAgW1JGQzcyNThd ICBGYXJyZWxsLCBTLiBhbmQgSC4gVHNjaG9mZW5pZywgIlBlcnZhc2l2ZSBNb25pdG9yaW5nIElz IGFuCiAgICAgICAgICAgICAgQXR0YWNrIiwgQkNQIDE4OCwgUkZDIDcyNTgsIERPSSAxMC4xNzQ4 Ny9SRkM3MjU4LCBNYXkKICAgICAgICAgICAgICAyMDE0LCA8aHR0cDovL3d3dy5yZmMtZWRpdG9y Lm9yZy9pbmZvL3JmYzcyNTg+LgoKICAgW1JTQV0gICAgICBSU0EgTGFib3JhdG9yaWVzLCAiUlNB IEVuY3J5cHRpb24gU3RhbmRhcmQsIFZlcnNpb24gMi4xLAogICAgICAgICAgICAgIFBLQ1MgMSIs IE5vdmVtYmVyIDIwMDIuCgpBdXRob3JzJyBBZGRyZXNzZXMKCiAgIFNoZW5nIEppYW5nCiAgIEh1 YXdlaSBUZWNobm9sb2dpZXMgQ28uLCBMdGQKICAgUTE0LCBIdWF3ZWkgQ2FtcHVzLCBOby4xNTYg QmVpcWluZyBSb2FkCiAgIEhhaS1EaWFuIERpc3RyaWN0LCBCZWlqaW5nLCAxMDAwOTUKICAgQ04K CiAgIEVtYWlsOiBqaWFuZ3NoZW5nQGh1YXdlaS5jb20KCgogICBMaXNoYW4gTGkKICAgVHNpbmdo dWEgVW5pdmVyc2l0eQogICBCZWlqaW5nICAxMDAwODQKICAgUC5SLkNoaW5hCgogICBQaG9uZTog Kzg2LTE1MjAxNDQxODYyCiAgIEVtYWlsOiBsaWxpc2hhbjkyNDhAMTI2LmNvbQoKCiAgIFlvbmcg Q3VpCiAgIFRzaW5naHVhIFVuaXZlcnNpdHkKICAgQmVpamluZyAgMTAwMDg0CiAgIFAuUi5DaGlu YQoKICAgUGhvbmU6ICs4Ni0xMC02MjYwLTMwNTkKICAgRW1haWw6IHlvbmdAY3NuZXQxLmNzLnRz aW5naHVhLmVkdS5jbgoKCiAgIFRhdHV5YSBKaW5tZWkKICAgSW5mb2Jsb3ggSW5jLgogICAzMTEx IENvcm9uYWRvIERyaXZlCiAgIFNhbnRhIENsYXJhLCBDQQogICBVUwoKICAgRW1haWw6IGppbm1l aUB3aWRlLmFkLmpwCgoKCgoKCgoKSmlhbmcsIGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVzIEp1 bHkgMTYsIDIwMTYgICAgICAgICAgICAgICAgW1BhZ2UgMjRdCgwKSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgICAgICBTZURIQ1B2NiAgICAgICAgICAgICAgICAgICAgSmFudWFyeSAyMDE2CgoK ICAgVGVkIExlbW9uCiAgIE5vbWludW0sIEluYy4KICAgMjAwMCBTZWFwb3J0IEJsdmQKICAgUmVk d29vZCBDaXR5LCBDQSAgOTQwNjMKICAgVVNBCgogICBQaG9uZTogKzEtNjUwLTM4MS02MDAwCiAg IEVtYWlsOiBUZWQuTGVtb25Abm9taW51bS5jb20KCgogICBEYWNoZW5nIFpoYW5nCiAgIEJlaWpp bmcKICAgQ04KCiAgIEVtYWlsOiBkYWNoZW5nLnpoYW5nQGdtYWlsLmNvbQoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpKaWFuZywgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMg SnVseSAxNiwgMjAxNiAgICAgICAgICAgICAgICBbUGFnZSAyNV0K ------=_Part_241165_1088287836.1452696414365-- From nobody Wed Jan 13 09:18:54 2016 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 EDC821B2B40 for ; Wed, 13 Jan 2016 09:18:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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.001, 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 0LanbGvEKFA8 for ; Wed, 13 Jan 2016 09:18:47 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA9A71B2B3E for ; Wed, 13 Jan 2016 09:18:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18760; q=dns/txt; s=iport; t=1452705526; x=1453915126; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=PEH7edfncO3f3SLXN4ODM/f/LchnuB2LeuB47VFnJSA=; b=W/jer80VPoqCrNkSB8ojzcsat1D+wLKUCla2P3vpw2nke4RI1enEwTfP AmTEbFf9ITGVMvLwiZY4K8HbrV18DC+z7Bcot3CuG80nvz15R+EeQbJeB aa2QxDSYtgl0FPHlmcrntH1AiDOS0fgfvRzTm2sQB136CSjXUiNhFMiKe E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AWAgBHhpZW/4MNJK1egm5MUm0GhTaDH?= =?us-ascii?q?rEDghMBDYFkIoQWgVcCgTs4FAEBAQEBAQF/C4Q0AQEBBC1cAgEIEQQBASEHBzI?= =?us-ascii?q?UCQgBAQQTCIgmDsBRAQEBAQEBAQEBAQEBAQEBAQEBAQEBGItVhQ2EMAWHb4cGi?= =?us-ascii?q?CABhUKIEIFlSoN6iF6FaIhtAREPAQFCgWAxHIFdcgGFE4EIAQEB?= X-IronPort-AV: E=Sophos; i="5.22,290,1449532800"; d="scan'208,217"; a="66573368" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Jan 2016 17:18:45 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u0DHIjew009728 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 13 Jan 2016 17:18:45 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 13 Jan 2016 11:18:44 -0600 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1104.009; Wed, 13 Jan 2016 11:18:44 -0600 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: WG Session @ IETF-95 (Buenos Aires) Agenda Requests - Deadline 2/14/2016 Thread-Index: AdFHORD4y95fMyRVQ56UWvb6lX4DVgG6yemw Date: Wed, 13 Jan 2016 17:18:44 +0000 Message-ID: <94bd6379777449dd82d513d749bfe746@XCH-ALN-003.cisco.com> References: <005134edeb9e4550b55a23776afaef15@XCH-ALN-003.cisco.com> In-Reply-To: <005134edeb9e4550b55a23776afaef15@XCH-ALN-003.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.254.87] Content-Type: multipart/alternative; boundary="_000_94bd6379777449dd82d513d749bfe746XCHALN003ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [dhcwg] WG Session @ IETF-95 (Buenos Aires) Agenda Requests - Deadline 2/14/2016 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 Jan 2016 17:18:53 -0000 --_000_94bd6379777449dd82d513d749bfe746XCHALN003ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The DHCPv6 bis team requests some time to discuss open issues (still TBD, s= ee http://trac.tools.ietf.org/group/dhcpv6bis/report/1 for current list). Title Of Session: DHCPv6 bis update and issues Presenter: TBD (Tomek, Bernie, or others from the bis team) Related Drafts: draft-ietf-dhc-rfc3315bis Time Required: 20 minutes (this is a guess at this time) Purpose of Session: Provide a quick update as to status of draft and discus= s open issues that need WG input We do expect to publish at least one, if not two, updates to the draft-ietf= -dhc-rfc3315bis document before the WG meeting. - Bernie From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz) Sent: Monday, January 04, 2016 4:45 PM To: dhcwg@ietf.org Subject: [dhcwg] WG Session @ IETF-95 (Buenos Aires) Agenda Requests - Dead= line 2/14/2016 Importance: High Hi: The scheduling requests for meeting slots for IETF-95 in Buenos Aires have = opened up (we must submit a request before 2/19/2016). Our plan for IETF-95 will be the same as we did for IETF-94: - We are encouraging agenda requests NOW thru February= 14th, 2016 (this will give us a few days to organize the agenda and decide= on the session length request). - We will submit our time request for IETF-95 based on= the RECEIVED agenda requests (by the February 14th deadline). - Requests after February 14th will most likely be REJ= ECTED (once the time slot is filled). In the past we have been more accommo= dating, but because of the pressure on IETF meeting time, we are being aske= d to justify our time slot request. And meeting time should be used to disc= uss and resolve issues, not present overviews of drafts or status updates. Therefore, please submit requests as soon as you can (and well before 2/14)= if you do plan to present at the DHC WG session in Buenos Aires. As in the past, please provide: Title Of Session: Presenter: Related Drafts: Time Required: Purpose of Session: We do want to remind those requesting time that you should focus on discuss= ing key issues that need resolution to move a draft forward. We are 3 months from that next meeting. - Tomek & Bernie --_000_94bd6379777449dd82d513d749bfe746XCHALN003ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The DHCPv6 bis team re= quests some time to discuss open issues (still TBD, see http://trac= .tools.ietf.org/group/dhcpv6bis/report/1 for current list).<= /span>

 

Title Of Session: DHCP= v6 bis update and issues

Presenter: TBD (Tomek,= Bernie, or others from the bis team)

Related Drafts: draft-ietf-dhc-rfc3315bis<= /p>

Time Required: 20 minu= tes (this is a guess at this time)

Purpose of Session: Pr= ovide a quick update as to status of draft and discuss open issues that nee= d WG input

 

We do expect to publis= h at least one, if not two, updates to the draft-ietf-dhc-rfc3315bis docume= nt before the WG meeting.

 

-&nb= sp;         Bernie

 

From: dhcwg [mailto:dhcwg-bounces@ietf.org] <= b>On Behalf Of Bernie Volz (volz)
Sent: Monday, January 04, 2016 4:45 PM
To: dhcwg@ietf.org
Subject: [dhcwg] WG Session @ IETF-95 (Buenos Aires) Agenda Requests= - Deadline 2/14/2016
Importance: High

 

Hi:

 

The scheduling requests for meeting slots for IETF-9= 5 in Buenos Aires have opened up (we must submit a request before 2/19/2016= ).

 

Our plan for IETF-95 will be the same as we did for = IETF-94:

-       = ;            &n= bsp;  We are encouraging agenda requests NOW thru Februar= y 14th, 2016 (this will give us a few days to organize the agenda and decid= e on the session length request).

-       = ;            &n= bsp;  We will submit our time request for IETF-95 based o= n the RECEIVED agenda requests (by the February 14th deadline).<= /p>

-       = ;            &n= bsp;  Requests after February 14th will most likely be RE= JECTED (once the time slot is filled). In the past we have been more accomm= odating, but because of the pressure on IETF meeting time, we are being ask= ed to justify our time slot request. And meeting time should be used to discuss and resolve issues, not present= overviews of drafts or status updates.

 

Therefore, please submit requests as soon as you can= (and well before 2/14) if you do plan to present at the DHC WG session in = Buenos Aires.

 

As in the past, please provide:

 

Title Of Session:

Presenter:

Related Drafts:

Time Required:

Purpose of Session:

 

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

 

We are 3 months from that next meeting.

 

-     &= nbsp;    Tomek & Bernie

 

--_000_94bd6379777449dd82d513d749bfe746XCHALN003ciscocom_-- From nobody Wed Jan 13 17:02:59 2016 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 55F931A874F; Wed, 13 Jan 2016 17:02:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.12.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160114010256.10291.77642.idtracker@ietfa.amsl.com> Date: Wed, 13 Jan 2016 17:02:56 -0800 Archived-At: Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-anonymity-profile-05.txt 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: Thu, 14 Jan 2016 01:02:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Anonymity profile for DHCP clients Authors : Christian Huitema Tomek Mrugalski Suresh Krishnan Filename : draft-ietf-dhc-anonymity-profile-05.txt Pages : 25 Date : 2016-01-13 Abstract: Some DHCP options carry unique identifiers. These identifiers can enable device tracking even if the device administrator takes care of randomizing other potential identifications like link-layer addresses or IPv6 addresses. The anonymity profile is designed for clients that wish to remain anonymous to the visited network. The profile provides guidelines on the composition of DHCP or DHCPv6 requests, designed to minimize disclosure of identifying information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-anonymity-profile/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dhc-anonymity-profile-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-anonymity-profile-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 13 17:55:08 2016 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 87EB81B29B8 for ; Wed, 13 Jan 2016 17:55:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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.001, 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 PoGKuQAnM-qE for ; Wed, 13 Jan 2016 17:55:05 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 606591B29B7 for ; Wed, 13 Jan 2016 17:55:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10674; q=dns/txt; s=iport; t=1452736505; x=1453946105; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=QyYzaxI9PGXGwwGBn0v/9OcrASwA5ktXT7Lav3Ct4iA=; b=RAX9vdPg5/cat7vDc/iyrHniiT8beFr7Fhh50x4SMeSNFvrn3a4DU1BM RtyAdzQNU8qDkWAfbXjQlNVcRnAIgbL2d2TVqDP8kflVPE2eNqm7e1bDi H3cg0qkv1gbC2K6JvfF/xQOzLoj5vcJ5HgvZ83EfrHwDJOu7sRO2v+X6c s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AlBAC6/5ZW/4cNJK1egm5MUm2FPYMeo?= =?us-ascii?q?zaPMCsBDYFkJIQUgVcCgTg4FAEBAQEBAQF/C4Q0AQEBBB0QXAIBGQQBASgHMhQ?= =?us-ascii?q?JCAIEE4guDsAPAQEBAQEBAQEBAQEBAQEBAQEBAQEBGIhlgnCEJhEBTAmDFYEbB?= =?us-ascii?q?ZMShAMBgQ6ENIgXgV5Kg3qIXo5WAREPAQFCgkqBQHIBhFWBQgEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,292,1449532800"; d="scan'208,217";a="227345281" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Jan 2016 01:55:04 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u0E1t4EP027676 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 14 Jan 2016 01:55:04 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 13 Jan 2016 19:55:03 -0600 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1104.009; Wed, 13 Jan 2016 19:55:03 -0600 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: Results of Adoption Call for draft-cui-dhc-dhcpv6-prefix-length-hint-issue - adopted Thread-Index: AQHRTm6VxqU7EHBlvkeJvNg6hNKlJw== Date: Thu, 14 Jan 2016 01:55:03 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_AC5AB41B949A4F0580F4C9B63AA19340ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [dhcwg] Results of Adoption Call for draft-cui-dhc-dhcpv6-prefix-length-hint-issue - adopted 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, 14 Jan 2016 01:55:07 -0000 --_000_AC5AB41B949A4F0580F4C9B63AA19340ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The chairs have concluded the there is consensus from the WG to adopt this = document. The authors are requested to publish draft-ietf-dhc-dhcpv6-prefix-length-hi= nt-issue-00. Thanks. - Tomek & Bernie From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz) Sent: Wednesday, December 16, 2015 1:46 PM To: dhcwg@ietf.org Subject: [dhcwg] Adoption Call for draft-cui-dhc-dhcpv6-prefix-length-hint-= issue (Ends January 8, 2016) Hello: This email initiates a WG call for adoption of the draft-cui-dhc-dhcpv6-pre= fix-length-hint-issue-03 (http://tools.ietf.org/html/draft-cui-dhc-dhcpv6-p= refix-length-hint-issue-03) document as a DHC WG work item. Please indicate whether you support the adoption or not, and if not, why no= t. See https://tools.ietf.org/html/rfc7221#section-2.2 if you have question= s about the criteria for adoption. This document falls within the WG Charte= r (https://datatracker.ietf.org/wg/dhc/charter/) under items #2, #3, and #4= . There are currently NO IPR claims against this draft (please see http://dat= atracker.ietf.org/wg/dhc/documents/ as this could change at any time). The co-chairs will determine the consensus after January 8, 2016. (This is = a longer period than usual because of the year end Holidays.) Happy Holidays & New Year! - Tomek & Bernie --_000_AC5AB41B949A4F0580F4C9B63AA19340ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The chairs have concluded the there is consensus from the WG to adopt = this document.

The authors are requested to publish draft-i= etf-dhc-dhcpv6-prefix-length-hint-issue-00.

Thanks.

- Tomek & Bernie

From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz)
Sent: Wednesday, December 16, 2015 1:46 PM
To: dhcwg@ietf.org
Subject: [dhcwg] Adoption Call for draft-cui-dhc-dhcpv6-prefix-lengt= h-hint-issue (Ends January 8, 2016)

 

Hello:

 

This email initiates a WG call for adoption of th= e draft-cui-dhc-dhcpv6-prefix-length-hint-issue-03 (http://too= ls.ietf.org/html/draft-cui-dhc-dhcpv6-prefix-length-hint-issue-03) document as a DHC WG work item.

 

Please indicate whether you support the adoption = or not, and if not, why not. See https://tools.i= etf.org/html/rfc7221#section-2.2 if you have questions about the criter= ia for adoption. This document falls within the WG Charter (https://datatracker.ietf.org/wg/d= hc/charter/) under items #2, #3, and #4.

 

There are currently NO IPR claims against this dr= aft (please see http://datatracke= r.ietf.org/wg/dhc/documents/ as this could change at any time).

 

The co-chairs will determine the consensus after = January 8, 2016. (This is a longer period than usual because of the year en= d Holidays.)

 

Happy Holidays & New Year!

 

-      &= nbsp;   Tomek & Bernie

 

--_000_AC5AB41B949A4F0580F4C9B63AA19340ciscocom_-- From nobody Wed Jan 13 17:58:17 2016 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8056B1B29C7; Wed, 13 Jan 2016 17:58:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.12.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160114015815.28633.25989.idtracker@ietfa.amsl.com> Date: Wed, 13 Jan 2016 17:58:15 -0800 Archived-At: Subject: [dhcwg] The DHC WG has placed draft-cui-dhc-dhcpv6-prefix-length-hint-issue in state "Adopted by a WG" 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: Thu, 14 Jan 2016 01:58:15 -0000 The DHC WG has placed draft-cui-dhc-dhcpv6-prefix-length-hint-issue in state Adopted by a WG (entered by Bernie Volz) The document is available at https://datatracker.ietf.org/doc/draft-cui-dhc-dhcpv6-prefix-length-hint-issue/ From nobody Thu Jan 14 01:31:22 2016 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E46A41B2D9B; Thu, 14 Jan 2016 01:31:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.12.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160114093119.9181.74560.idtracker@ietfa.amsl.com> Date: Thu, 14 Jan 2016 01:31:19 -0800 Archived-At: Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-00.txt 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: Thu, 14 Jan 2016 09:31:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHCPv6 Prefix Length Hint Issues Authors : Yong Cui Tianxiang Li Cong Liu Filename : draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-00.txt Pages : 9 Date : 2016-01-13 Abstract: DHCPv6 Prefix Delegation [RFC3633] allows a requesting router to include a prefix-length hint value in the IA_PD option to indicate a preference for the size of the prefix to be delegated, but is unclear about how the requesting router and delegating router should act in different situations involving the prefix-length hint. This document provides a summary of the existing problems with the prefix-length hint and guidance on what the requesting router and delegating router could do in different situations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-prefix-length-hint-issue/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jan 15 17:34:13 2016 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF6971B34F2; Fri, 15 Jan 2016 17:34:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.12.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160116013412.5770.75631.idtracker@ietfa.amsl.com> Date: Fri, 15 Jan 2016 17:34:12 -0800 Archived-At: Cc: dhc-chairs@ietf.org, acmorton@att.com, draft-ietf-dhc-access-network-identifier@ietf.org, dhcwg@ietf.org Subject: [dhcwg] Benoit Claise's Discuss on draft-ietf-dhc-access-network-identifier-11: (with DISCUSS and COMMENT) 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: Sat, 16 Jan 2016 01:34:13 -0000 Benoit Claise has entered the following ballot position for draft-ietf-dhc-access-network-identifier-11: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dhc-access-network-identifier/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- MY PREVIOUS DISCUSS: I would like to discuss the following point. You define the "Vendor ID" and then the Operator Enterprise ID. Why don't you reuse the RFC 6757 Operator-Identifier? Operator-Identifier The Operator-Identifier is the Structure of Management Information (SMI) Network Management Private Enterprise Code of the IANA- maintained "Private Enterprise Numbers" registry [SMI]. It identifies the operator running the network attached to a specific interface of the mobile access gateway. MY NEW DISCUSS: I see that you have now used the Operator-Identier. Good. However, it's not fully inline with the RFC 6757 definition. Why? Why not refer to the RFC 6757 definition, and include it here for the convenience of the readers. Also, what is the Enterprise ID (two instances of this)? Operator Enterprise ID The operator's Enterprise ID (as described in Section 3) is Private Enterprise Number (PEN) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm been confused by the following text and the figure 1, as it doesn't mention the dhcp relay-agents and servers The PMIPv6 extension as specified in [RFC6757] defines PMIPv6 options to carry access network identifiers in PMIPv6 signaling from Mobile Access Gateway (MAG) to LMA. MAG can learn this information from DHCP options as inserted by DHCP Relay agent before MAG. If MAG relays DHCP messages to LMA as specified in [RFC5844] this information can be inserted by MAG towards LMA in the forwarded DHCP messages. Figure 1 illustrates an example Proxy Mobile IPv6 deployment where Access Points (AP) acting as a DHCP relay agent inserts access network identifiers in DHCP messages relayed from the connected clients. The mobile access gateway learns this information over DHCP and delivers the information elements related to the access network to the local mobility anchor over Proxy Mobile IPv6 signaling messages. In this example, the additional information could comprise the SSID of the used IEEE 802.11 network and the identities of the operators running the IEEE 802.11 access network infrastructure. Discussing with Sri and Mark, I discovered my source of confusion. There are two cases, as discussed in https://tools.ietf.org/html/rfc5844#section-3.4: This specification supports the following two DHCP deployment configurations. o DHCP relay agent co-located with the mobile access gateway. o DHCP server co-located in the mobile access gateway. Either the DHCP server is on the LMA, and the MAG just forwards the DHCP message to the LMA. The LMA receives the access network identifiers from DHCP (the MAG just forwards the DHCP message, modified by the AP) Or the DHCP server is on the MAG, and then the PMIPv6 extension carries the access network identifiers to the LMA, learned with DHCP from the AP. However, in the context of WLAN-EPC interworking, the only supported mode is DHCP server collocation on the MAG. Hence the figure 1 focuses on this case. The text and the figure should be improved IMO. From nobody Sun Jan 17 01:19:46 2016 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 7D40C1B2E5D; Sun, 17 Jan 2016 01:19:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.251 X-Spam-Level: * X-Spam-Status: No, score=1.251 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 wq_QhusdMpvQ; Sun, 17 Jan 2016 01:19:33 -0800 (PST) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 933F71B2E62; Sun, 17 Jan 2016 01:19:32 -0800 (PST) Received: by mail-lf0-x22f.google.com with SMTP id 17so102045176lfz.1; Sun, 17 Jan 2016 01:19:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=euKnHIFZVBtr8ApW48stpaafrgDhkBnGcaSXu5h6aPE=; b=Zi4Sj8Y7AYI+4wtX6LEReEiuOHuuV2nbYWnL/Ony2CuF/rGfGhGCBpnZvIm3uQ+zl1 d7bpxXTCiJVK34jdCB3PcopQOrIZOJOiA8WTkM0uOd4pNqCnVbxzpOsfEc3Vv0uV+3Cs SMqQB4eEdkBBhn/V6YMifHGDr1T/s0d4AB9Q7IHMIcuH6QZp2kCtk0NARF0Sr40d+A2N 2q7Kd5hDIjCU5Px0c2SYFhONsV8K63TL6Kbo4Hv8jVVkVbh3Qym9iYLbSJTZocKVVqTo WHmU30Md0cX0w1vTDEWfqZlgo/vpiEUOB9CSTZmRP/rOLpp2p+YUYt0ZZZq7SSbAEJXb tDOQ== 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=euKnHIFZVBtr8ApW48stpaafrgDhkBnGcaSXu5h6aPE=; b=b+rhhhqhGqA4V5CMmN4YhUNt1q6kKPesT0JYI3mRH5Kzf4sB9xIyYS1DVcgN6Vbw1I vtF/QN4OR5QyEBkP1B2ON3t2uYIqxDNnv07xbvd1o3J29cyMIuIIw/j7WLiIQ/mfuP/0 EWEm5Y8FiZ+AyWN0UXk+GrHbrbTaKiuFYKkQ0qcSNCCO7FKVt7P+2nOkf+ezWSjCqkFo /stuH6bkCs6HTLwtLlxQTX7zD6Cy1QS1y8VQq0I87/X306u9U1Q7KjJmabduZ6QY5aeb 94WeI0SYxnyw3g7ENqDXDJM8mm1QpNb9TSs33jyzzhp9Iv2PYwk5JLEtSUp5fAFPVzzc DsEA== X-Gm-Message-State: ALoCoQm7gbMkXT01Qhh3P+uKaoNyPxKBfASVAswHuciLQzMPgjz+T9Th6eBbyV8HQBcksMJwNA55AMGGc78Bf1vXTBzzUpeuUQ== MIME-Version: 1.0 X-Received: by 10.25.142.136 with SMTP id q130mr6809339lfd.56.1453021878858; Sun, 17 Jan 2016 01:11:18 -0800 (PST) Received: by 10.114.79.194 with HTTP; Sun, 17 Jan 2016 01:11:18 -0800 (PST) In-Reply-To: References: Date: Sun, 17 Jan 2016 17:11:18 +0800 Message-ID: From: Lishan Li To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Content-Type: multipart/alternative; boundary=001a114035acf0b9b20529840430 Archived-At: Cc: "dhcwg@ietf.org" , draft-ietf-dhc-sedhcpv6@ietf.org Subject: Re: [dhcwg] comments on draft-ietf-dhc-sedhcpv6-10.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: Sun, 17 Jan 2016 09:19:39 -0000 --001a114035acf0b9b20529840430 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Jinmei, Thanks a lot for your valuable comments. For the detailed replies, please see inline ( these lines start with [LS] ). Best Regards, Lishan 2016-01-08 7:10 GMT+08:00 =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 : > I've read this version of draft. While I happen to be listed as a > co-author, I was not really involved in this revision process, so I'm > basically making these comments as a third-party reader. > > First, I have some higher-level points to discuss: > > - this protocol changes DHCPv6 message exchanges quite substantially: > previously, the client first sends a Solicit message, gets possibly > multiple Advertise messages, chooses the server (=3D sender of one of > the Advertises) that would be best for the client, and then sends a > Request to that chosen server. Now the server selection is done at > the key exchange phase (the initial Information-request and Reply > exchange), and the Solicit can be sent only to a single server. If > the client doesn't like the Advertise it could restart the whole > process, but it will be more expensive, and there's no guarantee > that other servers can provide a better Advertise. > > One might argue that it's okay as "secure DHCPv6" is an "optional" > extension. But, with keeping in mind that the current IETF trend is > to make everything privacy-aware (often by making everything > encrypted), I'd personally say we should consider it to be the > standard mode of DHCPv6 operation even if users can still disable > it. From this point of view, I think we should either > A. make the server selection behavior more compatible with the > pre-encryption protocol, or > B. accept we give up the previous server selection feature for > privacy (after careful assessment of its effect and with clear wg > consensus), and explicitly note that. we might even have to > reflect that in rfc3315bis. > > [LS]: In my opinion, we should give up the previous server selection feature for privacy. Compared with rfc3315 and rfc3315bits, secure DHCPv6 is another mode. rfc3315bis is clear-text mode. And the secure DHCPv6 is secure mode which achieves authentication and encryption. The server selection feature and configuration process are all different. And I think it is not necessary to reflect the character of secure DHCPv6 mode in rfc3315bis. Looking forward to your further guidance. - As encryption is now mandatory, I now wonder whether we need a > separate "signature" at all. Except for the signature in the reply > to the initial Information-request, the explicit signature doesn't > seem to provide any additional integrity or authentication. And, as > we now don't allow TOFU for authentication (i.e., we should validate th= e > certificate out-of-band anyway, and that's almost the only important > content of this reply), the signature in the first Reply wouldn't be > much useful either. So we might consider simplifying the protocol > [LS]: In the current version, the client-to-server and server-to-client both send the certificate option, signature option and timestamp option. I think that only the server-to-client case MUST contain the signature option and timestamp option. In the server-to-client case, the signature and timestamp option in the Reply message is used to protect the message integrity. So it is better to remain the timestamp and signature option. In the client-to-server case, the certificate option is contained in the encrypted Solicit/Information-request message. Because the message is encrypted, there is no need to contain the signature and timestamp option to protect the message integrity. What do you think of it? > > - Slightly related to the previous point, this draft doesn't talk > about encryption algorithms, let alone whether/how to negotiate the > encryption algorithm. (Aside from whether we need a separate > 'signature') Perhaps it implicitly assumes to use the "signature > algorithm" for encryption, too, but, if so, I think it should > explicitly say so. > > [LS]: The encryption algorithm need to be added. I will try to add it in the next version. - This protocol uses the server DUID as the identifier of the server > key (pair), and (implicitly) assumes the client only has one key > (pair). Is that okay? Don't we need a separate key ID value so we > can identify the key to be used for decryption without actually > trying to decrypt the message with all possible keys? (In the case > of client this might be trickier since the 'key ID' can reveal the > identify of the client). > > [LS]: I think we can use the message transaction-id as the identifier of the server's public key for encryption, and the client's private key for decryption. What do you think of it? - The 'public key option' has been removed in this version. I > probably missed some part of the past discussions, but did we make > that decision? What's the rationale of the removal? > > [LS]: In the current version, TOFU is out of scope. The client and server use certificates for authentication, not public key. So I think the certificate option is enough. The public key option is removed. - The "security issues" and "applicability" sections (especially the > latter) look still weak/insufficient to me. I'll make some more > specific comments below. > > - Related to the previous point, what (will) happened for the separate > threat analysis/usage document? If the plan was to move all > difficult discussions regarding the "security issues" to the > separate document, we should also see it with this protocol > document. (In my understanding) the latter can't move forward > itself otherwise. > > [LS]: we have updated a new version of the secure DHCPv6 deployment. I wish you can give some comments on the secure DHCPv6 deployment draft. Thanks in advance. Some specific comments on the draft text follow: > > - Section 4 > > authentication method. However, this method provides little message > integrity or source integrity check, and it protects only the > Reconfigure message. This key is transmitted in plaintext. > > I'm not sure if I get the phrase "this method provides little > message integrity or source integrity check". Does it try to say > "*Because* the key is transmitted in plaintext"? > > [LS]: How about the following text: [...] However, this method provides little message integrity or source integrity check, and it protects only the Reconfigure message. In addition, the key is transmitted in plaintext to the client in earlier exchanges. [...] - Section 4 > > IETF has expressed strong agreement that PM is an attack that needs > to be mitigated where possible in [RFC7258]. > > I think the acronym "PM" should be explicitly introduced when > "pervasive monitoring" first appears (in Introduction). > > [LS]: Will correct it. > - Section 5.1 > > [...] Depending on > its policy, it can choose to connect repeat the server discovery > process after certain delay or attempt to connect to a different > network. > > I'm not sure what this 'connect' means. Does it intend to say cases > like a smartphone/laptop trying to find a wifi base station? > > [LS]: According to Bernie's comment, we have changed this sentence as follows: Depending on its policy, it can choose to repeat the server discovery process after certain delay or attempt to use an unsecured DHCPv6 server. - Section 5.3: what about the server-to-client case? Clients are > expected to rely on the selection in the initial > Information-request/Reply exchange? > > If the recipient does not support the algorithm used by the sender, > it cannot authenticate the message. In the client-to-server case, > the server SHOULD reply with an AlgorithmNotSupported status code > (defined in Section 10.3). Upon receiving this status code, the > client MAY resend the message protected with the mandatory algorithm > (defined in Section 10.1.2). > > [LS]: In the next version, only in the server-to-client case, the server will send the Reply message with signature and timestamp option to the client for server authentication. So, how about replacing with the following text: If the client does not support the hash and signature algorithms used by the server, the Reply message SHOULD be dropped. If both hash and signature algorithms are supported, the client then checks the authority of this server. The client SHOULD also use the same algorithms in the subsequent messages. - Section 5.4: in general, I think this section is still quite weak > and/or insufficient. First, the current text reads as if PKI is > (readily) usable in enterprise networks, yet it dismisses its > deployment as out-of-scope. I don't think this would address > concerns/questions raised by external reviewers. > > My understanding of the external feedback and our followup > discussions is that one sure way to deploy this protocol in > enterprise network is to almost manually configure the clients with > the server certificate and configure the server with clients > certificates. But we'll then have to explain what's the advantage > of this new protocol against the RFC3315 security mechanism since > Section 4 of this document states manual configuration is one major > flaw of the RFC3315 mechanism. My personal answer to this question > is that the public-key based approach is slightly securer in cases > such as that where clients keys are quietly stolen by an attacker > (so they can pretend to be a valid client later). > > On top of such realistic discussions, I think we can also mention > the use of PKI as a possibility of making the configuration (much) > less manual. But since it would require answering many difficult > questions, IMO we should be honest to say its feasibility is unclear > right now and subject to future study and development. > > Also, if we revise this section as suggested above, Section 4 will > have to be adjusted, too, since we can't (yet) claim secure DHCPv6 > solves the "flaws" of the existing mechanisms. > > [LS]: How about the following "applicability" section: Secure DHCPv6 is applicable in environments where physical security on the link is not assured and attacks on DHCPv6 are a concern, such as enterprise networks. In enterprise networks, the DHCPv6 clients are manually pre-configured with the trusted servers' certificates to achieve server authentication. In addition, the DHCPv6 server is pre-configured with the trusted clients' certificates to verify the client'= s identity. After the mutual authentication, the DHCPv6 message is encrypted with the recipient's public key, which is contained in the certificate. The use of PKI as a possibility of making the configuration less manual. However, its feasibility is unclear right now and subject to future study and development. And we supply the following text in section 4: The public-key based approach proposed in this document is slightly securer in some cases. For example, if the client's key is quietly stolen by an attacker, then the attack can pretend to be a valid client later. > - Section 5.4: > > [...] In enterprise network, the security policy is > strict and the clients are stable terminals. The PKI model is used > > What does 'stable' mean? A desktop PC would be considered a "stable > terminal", but what about laptops? How about smart phones connected > to the enterprise network based on the BYOD policy? > > - Section 6 > > For the security DHCPv6 client, it must have a public certificate. > > What does "*public* certificate" mean? Does that mean it's not > "private"? Same for Section 7. > > [LS]: Will correct it. public certificate -> certificate. > - Section 6 > > [...] The Information-request message MUST NOT include any > option which may reveal the private information of the client, such > as the client identifier option. > > I suggest adding "...or the certificate option". > > [LS]: Will correct it. > - Section 6 > > non-security options assigned to it. The Option Request option in > the Information-request message MUST contain the option code of > certificate option, signature option, timestamp option, and server > identifier option. > > Should we really need to include all of these? The certificate > option should surely be specified, but the need for the others seem > to be almost automatically derived from the specification. > > [LS]: The signature option and timestamp option are used for the message integrity check. The Reply message is transmitted in clear text. So in order to protect the Reply message integrity, I think the timestamp and signature option MUST be contained. > - Section 6 > > [...] The client SHOULD also use the same algorithms in the > return messages. > > It's not very clear to me what "return messages" mean (as the client > is usually the initiator of DHCP exchanges). Perhaps "in subsequent > messages (of the same DHCPv6 session)"? > > [LS]: Have corrected it. return messages -> subsequent messages > - Section 6 > > [...] Depending on its policy, it can choose to connect using > plain, unencrypted DHCPv6, repeat the server discovery process after > certain delay or attempt to connect to a different network. > > What "connect to a different network" means isn't very clear to me > (see also the same sense of comment on Section 5.1) [LS]: According to Bernie's comment, we have changed this sentence as follows: Depending on its policy, it can choose to repeat the server discovery process after certain delay or attempt to use an unsecured DHCPv6 server. - Section 6 > > For the received Encrypted-Response message, the client extracts the > encrypted-message option and decrypts it using its private key to > obtain the original DHCPv6 message. > > What if the client has more than one key pair (see also the higher > level comment above)? Is it assumed to associate transaction-id to > a particular key? > > [LS]: Yes. In my option, the particular key is associated with transaction-id. What is your opinion? Looking forward to further guidance. - Section 6 > > o Upon receiving a SignatureFail error status code, the client MAY > resend the message following normal retransmission routines > defined in [RFC3315]. > > What's the rationale of this behavior? > > [LS]: In the new version, the client will not send the signature option a= nd timestamp option. So we will delete these sentence. - Section 7 > > If the server does not send the timestamp option, the client ignores > the timestamp check and verifies the signature. If there is a [...] > > I don't understand the role of the first sentence in this context. > > [LS]: Will delete the first sentence in the next version. > - Section 7 > > [...] Depending on server's local policy, the message without a > Timestamp option MAY be acceptable or rejected. If the server > rejects such a message, a TimestampFail error status code, defined in > Section 10.3, should be sent back to the client. [...] > > To be sure: is the TimestampFail supposed to be returned when a > message from the client doesn't have Timestamp but the server wanted > it? > > [LS]: Yes. Maybe the above sentences are not clear. How about the followi= ng sentences: [...] Depending on server's local policy, the message without a Timestamp option MAY be accepted or rejected. If the server rejects such a message without Timestamp option, then a TimestampFail error status code, defined in Section 10.3, should be sent back to the client. [...] - Section 8 > > [...] Actually, by definition in this > document, relay agents SHOULD NOT add any secure DHCPv6 options. > > Why is this a "SHOULD NOT", i.e. can't this be "MUST NOT"? > > [LS]: Agree. Will correct it. > - Section 10.1.2 > > Note: if both signature and authentication option are present, > signature option does not protect the Authentication Option. It > > Should we still worry about it? The only possible reason for having > both that I can see is to allow a newer client implementation to > work with both new and old server implementations. But now that the > message is encrypted in a way that older implementations don't > understand, it's completely impossible anymore. I think we can now > simply say Authentication Option shouldn't be used with Secure > DHCPv6 (and if it's used the behavior is undefined). > > [LS]: I agree. So we replce this section with the following sentences: If the Secure DHCPv6 is applied, then the Authentication Option shouldn't be used. - Section 10.1.3 > > Timestamp The current time of day (SeND-format timestamp > in UTC (Coordinated Universal Time). It can reduce > the danger of replay attacks. > > I'd add a reference to the SeND RFC here. > > [LS]: Have added a reference: Section 5.3.1, [RFC3971]. > - Section 10.2.1 > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | msg-type | transaction-id | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > . DUID . > | (variable) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Why is the DUID dedicated field, instead of using the server > identifier option? There are other types of messages that require a > server identifier option (e.g., RENEW), but they don't make it a > separate field. I don't see any reason how this case is different, > and using a separate format will make implementations unnecessarily > complicated. > > [LS]: Have modified it. In the new version, the diagram should just have basic client format (see RFC 3315, Section 6) and then text to specify that it MUST contain a Server Identifier option and an Encrypted-message option. Editorial nits: > > Thanks a lot for the throughout review. I will correct the editorial nits in the next version. - Section 4: this sentence at least misses a period (I'm not sure if > it's terminated with 'improved' or some other text was expected > after that). > > [...] The > basic DHCPv6 specification [RFC3315] defines security mechanisms, but > they have significant flaws and can be improved > > - Section 5.1: s/authentication, MUST/authentication MUST/ > > key. The message that fails client authentication, MUST be dropped. > And the server sends the corresponding error status code to client. > > - Section 6: s/security/Secure/ > > For the security DHCPv6 client, it must have a public certificate. > > - Section 7: s/pre-configured/pre-configured with/ > > The server may be pre-configured a public key certificate, which is > > - Section 7: s/replies/replies with/ (same for some other use cases of > 'reply') > > server authentication information, it replies the Reply message to > > - Section 8 s/describes/described/ > > [...] The unknown > messages MUST be forwarded as describes in [RFC7283]. > > - Section 10.1.2 s/be/be in/ > > [...] The signature option could > be any place within the DHCPv6 message while it is logically created > > - Section 10.1.2 s/chose not/chose not to/ Also, this sentence(-like) > seems grammatically broken but I have no idea about how to fix it. > > changing auth option, the authors chose not include authentication > option in the signature. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > --001a114035acf0b9b20529840430 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Jinmei,

Thanks a l= ot for your valuable comments. For the detailed replies, please see inline = ( these lines start with [LS] ).=C2=A0

Best Regard= s,
Lishan

2016-01-08 7:10 GMT+08:00 =E7=A5=9E=E6=98=8E=E9=81=94=E5=93= =89 <jinmei@wide.ad.jp>:
I've read t= his version of draft.=C2=A0 While I happen to be listed as a
co-author, I was not really involved in this revision process, so I'm basically making these comments as a third-party reader.

First, I have some higher-level points to discuss:

- this protocol changes DHCPv6 message exchanges quite substantially:
=C2=A0 previously, the client first sends a Solicit message, gets possibly<= br> =C2=A0 multiple Advertise messages, chooses the server (=3D sender of one o= f
=C2=A0 the Advertises) that would be best for the client, and then sends a<= br> =C2=A0 Request to that chosen server.=C2=A0 Now the server selection is don= e at
=C2=A0 the key exchange phase (the initial Information-request and Reply =C2=A0 exchange), and the Solicit can be sent only to a single server.=C2= =A0 If
=C2=A0 the client doesn't like the Advertise it could restart the whole=
=C2=A0 process, but it will be more expensive, and there's no guarantee=
=C2=A0 that other servers can provide a better Advertise.

=C2=A0 One might argue that it's okay as "secure DHCPv6" is a= n "optional"
=C2=A0 extension.=C2=A0 But, with keeping in mind that the current IETF tre= nd is
=C2=A0 to make everything privacy-aware (often by making everything
=C2=A0 encrypted), I'd personally say we should consider it to be the =C2=A0 standard mode of DHCPv6 operation even if users can still disable =C2=A0 it.=C2=A0 From this point of view, I think we should either
=C2=A0 A. make the server selection behavior more compatible with the
=C2=A0 =C2=A0 =C2=A0pre-encryption protocol, or
=C2=A0 B. accept we give up the previous server selection feature for
=C2=A0 =C2=A0 =C2=A0privacy (after careful assessment of its effect and wit= h clear wg
=C2=A0 =C2=A0 =C2=A0consensus), and explicitly note that.=C2=A0 we might ev= en have to
=C2=A0 =C2=A0 =C2=A0reflect that in rfc3315bis.

[LS]: In my opinion, we should give up the previous s= erver selection feature for=C2=A0
privacy. Compared with rfc3315 = and rfc3315bits, secure DHCPv6 is another=C2=A0
mode. rfc3315bis = is clear-text mode. And the secure DHCPv6 is secure mode=C2=A0
wh= ich achieves authentication and encryption. The server selection feature
and configuration process are all different. And I think it is not = necessary=C2=A0
to reflect the character of secure DHCPv6 mode in= rfc3315bis. Looking forward=C2=A0
to your further guidance.=C2= =A0

- As encryption is now mandatory, I now wonder whether we need a
=C2=A0 separate "signature" at all.=C2=A0 Except for the signatur= e in the reply
=C2=A0 to the initial Information-request, the explicit signature doesn'= ;t
=C2=A0 seem to provide any additional integrity or authentication.=C2=A0 An= d, as
=C2=A0 we now don't allow TOFU for authentication (i.e., we should vali= date the
=C2=A0 certificate out-of-band anyway, and that's almost the only impor= tant
=C2=A0 content of this reply), the signature in the first Reply wouldn'= t be
=C2=A0 much useful either.=C2=A0 So we might consider simplifying the proto= col
=C2=A0
[LS]: In the current version, the= client-to-server and server-to-client=C2=A0
both send the certif= icate option, signature option and timestamp option.=C2=A0
I thin= k that only the server-to-client case MUST contain the signature=C2=A0
option and timestamp option.=C2=A0
In the server-to-client = case, the signature and timestamp option in=C2=A0
the Reply messa= ge is used to protect the message integrity. So it is=C2=A0
bette= r to remain the timestamp and signature option.=C2=A0
In the clie= nt-to-server case, the certificate option is contained in
the enc= rypted Solicit/Information-request message. Because the message
i= s encrypted, there is no need to contain the signature and timestamp
<= div>option to protect the message integrity.
What do you think of= it?=C2=A0

- Slightly related to the previous point, this draft doesn't talk
=C2=A0 about encryption algorithms, let alone whether/how to negotiate the<= br> =C2=A0 encryption algorithm.=C2=A0 (Aside from whether we need a separate =C2=A0 'signature') Perhaps it implicitly assumes to use the "= signature
=C2=A0 algorithm" for encryption, too, but, if so, I think it should =C2=A0 explicitly say so.

[LS]: The encryption algorithm need to be added. I wi= ll try to add
it in the next version.=C2=A0

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex"> - This protocol uses the server DUID as the identifier of the server
=C2=A0 key (pair), and (implicitly) assumes the client only has one key
=C2=A0 (pair).=C2=A0 Is that okay?=C2=A0 Don't we need a separate key I= D value so we
=C2=A0 can identify the key to be used for decryption without actually
=C2=A0 trying to decrypt the message with all possible keys?=C2=A0 (In the = case
=C2=A0 of client this might be trickier since the 'key ID' can reve= al the
=C2=A0 identify of the client).

[LS]: I think we can use the message transaction-id a= s the identifier of=C2=A0
the server's public key for encrypt= ion, and the client's private key
for decryption. What do you= think of it?=C2=A0

- The 'public key option' has been removed in this version.=C2=A0 I=
=C2=A0 probably missed some part of the past discussions, but did we make =C2=A0 that decision?=C2=A0 What's the rationale of the removal?

[LS]: In the current version, TOFU is out of scope. T= he client and server=C2=A0
use =C2=A0certificates for authenticat= ion, not public key. So I think the certificate
option is enough.= The public key option is removed.=C2=A0

- The "security issues" and "applicability" sections (e= specially the
=C2=A0 latter) look still weak/insufficient to me.=C2=A0 I'll make some= more
=C2=A0 specific comments below.

- Related to the previous point, what (will) happened for the separate
=C2=A0 threat analysis/usage document?=C2=A0 If the plan was to move all =C2=A0 difficult discussions regarding the "security issues" to t= he
=C2=A0 separate document, we should also see it with this protocol
=C2=A0 document.=C2=A0 (In my understanding) the latter can't move forw= ard
=C2=A0 itself otherwise.

[LS]: we have updated a new version of the secure DHC= Pv6 deployment.=C2=A0
I wish you can give some comments on the se= cure DHCPv6 deployment draft.
Thanks in advance.=C2=A0
=
Some specific comments on the draft text follow:

- Section 4

=C2=A0 =C2=A0authentication method.=C2=A0 However, this method provides lit= tle message
=C2=A0 =C2=A0integrity or source integrity check, and it protects only the<= br> =C2=A0 =C2=A0Reconfigure message.=C2=A0 This key is transmitted in plaintex= t.

=C2=A0 I'm not sure if I get the phrase "this method provides litt= le
=C2=A0 message integrity or source integrity check".=C2=A0 Does it try= to say
=C2=A0 "*Because* the key is transmitted in plaintext"?

[LS]: How about the following text:
[...] = =C2=A0However, this method provides little message integrity or source=C2= =A0
integrity check, and it protects only the Reconfigure message= . In addition,=C2=A0
the key is transmitted in plaintext to the c= lient in earlier exchanges. =C2=A0
[...]=C2=A0

- Section 4

=C2=A0 =C2=A0IETF has expressed strong agreement that PM is an attack that = needs
=C2=A0 =C2=A0to be mitigated where possible in [RFC7258].

=C2=A0 I think the acronym "PM" should be explicitly introduced w= hen
=C2=A0 "pervasive monitoring" first appears (in Introduction).
[LS]: Will correct it.
=C2=A0
- Section 5.1

=C2=A0 =C2=A0[...]=C2=A0 Depending on
=C2=A0 =C2=A0its policy, it can choose to connect repeat the server discove= ry
=C2=A0 =C2=A0process after certain delay or attempt to connect to a differe= nt
=C2=A0 =C2=A0network.

=C2=A0 I'm not sure what this 'connect' means.=C2=A0 Does it in= tend to say cases
=C2=A0 like a smartphone/laptop trying to find a wifi base station?

[LS]: According to Bernie's comment, we have chan= ged this sentence as follows:
Depending on its policy, it can cho= ose to repeat the server discovery=C2=A0
process after certain de= lay or attempt to use an unsecured DHCPv6 server.=C2=A0

- Section 5.3: what about the server-to-client case?=C2=A0 Clients are
=C2=A0 expected to rely on the selection in the initial
=C2=A0 Information-request/Reply exchange?

=C2=A0 =C2=A0If the recipient does not support the algorithm used by the se= nder,
=C2=A0 =C2=A0it cannot authenticate the message.=C2=A0 In the client-to-ser= ver case,
=C2=A0 =C2=A0the server SHOULD reply with an AlgorithmNotSupported status c= ode
=C2=A0 =C2=A0(defined in Section 10.3).=C2=A0 Upon receiving this status co= de, the
=C2=A0 =C2=A0client MAY resend the message protected with the mandatory alg= orithm
=C2=A0 =C2=A0(defined in Section 10.1.2).

[LS]: In the next version, only in the server-to-clie= nt case, the server=C2=A0
will send the Reply message with signat= ure and timestamp option to the=C2=A0
client for server authentic= ation.
So, how about replacing with the following text:
If the client does not support the hash and signature algorithms used by= =C2=A0
the server, the Reply message SHOULD be dropped. If both h= ash and signature=C2=A0
algorithms are supported, the client then= checks the authority of this=C2=A0
server. The client SHOULD als= o use the same algorithms in the subsequent=C2=A0
messages. =C2= =A0=C2=A0

- Section 5.4: in general, I think this section is still quite weak
=C2=A0 and/or insufficient.=C2=A0 First, the current text reads as if PKI i= s
=C2=A0 (readily) usable in enterprise networks, yet it dismisses its
=C2=A0 deployment as out-of-scope.=C2=A0 I don't think this would addre= ss
=C2=A0 concerns/questions raised by external reviewers.

=C2=A0 My understanding of the external feedback and our followup
=C2=A0 discussions is that one sure way to deploy this protocol in
=C2=A0 enterprise network is to almost manually configure the clients with<= br> =C2=A0 the server certificate and configure the server with clients
=C2=A0 certificates.=C2=A0 But we'll then have to explain what's th= e advantage
=C2=A0 of this new protocol against the RFC3315 security mechanism since =C2=A0 Section 4 of this document states manual configuration is one major<= br> =C2=A0 flaw of the RFC3315 mechanism.=C2=A0 My personal answer to this ques= tion
=C2=A0 is that the public-key based approach is slightly securer in cases =C2=A0 such as that where clients keys are quietly stolen by an attacker =C2=A0 (so they can pretend to be a valid client later).

=C2=A0 On top of such realistic discussions, I think we can also mention =C2=A0 the use of PKI as a possibility of making the configuration (much) =C2=A0 less manual.=C2=A0 But since it would require answering many difficu= lt
=C2=A0 questions, IMO we should be honest to say its feasibility is unclear=
=C2=A0 right now and subject to future study and development.

=C2=A0 Also, if we revise this section as suggested above, Section 4 will =C2=A0 have to be adjusted, too, since we can't (yet) claim secure DHCP= v6
=C2=A0 solves the "flaws" of the existing mechanisms.

[LS]: How about the following "applicability&quo= t; section:
Secure DHCPv6 is applicable in environments where phy= sical security
on the link is not assured and attacks on DHCPv6 a= re a concern, such
as enterprise networks. In enterprise networks= , the DHCPv6 clients=C2=A0
are manually pre-configured with the t= rusted servers' certificates to=C2=A0
achieve server authenti= cation. In addition, the DHCPv6 server is=C2=A0
pre-configured wi= th the trusted clients' certificates to verify the client's
identity. After the mutual authentication, the DHCPv6 message is encrypt= ed
=C2=A0with the recipient's public key, which is contained = in the certificate.
The use of PKI as a possibility of making the= configuration less manual.=C2=A0
However, its feasibility is unc= lear right now and subject to future study=C2=A0
and development.=

And we supply the following text in section 4:
The public-key based approach proposed in this document is slightly= =C2=A0
securer in some cases. For example, if the client's ke= y is quietly=C2=A0
stolen by an attacker, then the attack can pre= tend to be a valid client=C2=A0
later.
=C2=A0
- Section 5.4:

=C2=A0 =C2=A0[...]=C2=A0 In enterprise network, the security policy is
=C2=A0 =C2=A0strict and the clients are stable terminals.=C2=A0 The PKI mod= el is used

=C2=A0 What does 'stable' mean?=C2=A0 A desktop PC would be conside= red a "stable
=C2=A0 terminal", but what about laptops?=C2=A0 How about smart phones= connected
=C2=A0 to the enterprise network based on the BYOD policy?

- Section 6

=C2=A0 =C2=A0For the security DHCPv6 client, it must have a public certific= ate.

=C2=A0 What does "*public* certificate" mean?=C2=A0 Does that mea= n it's not
=C2=A0 "private"?=C2=A0 Same for Section 7.

[LS]: Will correct it. public certificate -> certi= ficate.
=C2=A0
- Section 6

=C2=A0 =C2=A0[...]=C2=A0 The Information-request message MUST NOT include a= ny
=C2=A0 =C2=A0option which may reveal the private information of the client,= such
=C2=A0 =C2=A0as the client identifier option.

=C2=A0 I suggest adding "...or the certificate option".

[LS]: Will correct it.
=C2=A0
- Section 6

=C2=A0 =C2=A0non-security options assigned to it.=C2=A0 The Option Request = option in
=C2=A0 =C2=A0the Information-request message MUST contain the option code o= f
=C2=A0 =C2=A0certificate option, signature option, timestamp option, and se= rver
=C2=A0 =C2=A0identifier option.

=C2=A0 Should we really need to include all of these?=C2=A0 The certificate=
=C2=A0 option should surely be specified, but the need for the others seem<= br> =C2=A0 to be almost automatically derived from the specification.

[LS]: The signature option and timestamp option are u= sed for the message=C2=A0
integrity check. The Reply message is t= ransmitted in clear text. So in
order to protect the Reply messag= e integrity, I think the timestamp=C2=A0
and signature option MUS= T be contained.
=C2=A0
- Section 6

=C2=A0 =C2=A0[...] The client SHOULD also use the same algorithms in the =C2=A0 =C2=A0return messages.

=C2=A0 It's not very clear to me what "return messages" mean = (as the client
=C2=A0 is usually the initiator of DHCP exchanges).=C2=A0 Perhaps "in = subsequent
=C2=A0 messages (of the same DHCPv6 session)"?

[LS]: Have corrected it. return messages -> subseq= uent messages
=C2=A0
- Section 6

=C2=A0 =C2=A0[...]=C2=A0 Depending on its policy, it can choose to connect = using
=C2=A0 =C2=A0plain, unencrypted DHCPv6, repeat the server discovery process= after
=C2=A0 =C2=A0certain delay or attempt to connect to a different network.
=C2=A0 What "connect to a different network" means isn't very= clear to me
=C2=A0 (see also the same sense of comment on Section 5.1)=C2=A0
=C2=A0
[LS]: According to Bernie's comment, we have ch= anged this sentence as follows:
Depending on its policy, it can c= hoose to repeat the server discovery=C2=A0
process after certain = delay or attempt to use an unsecured DHCPv6 server.=C2=A0

- Section 6

=C2=A0 =C2=A0For the received Encrypted-Response message, the client extrac= ts the
=C2=A0 =C2=A0encrypted-message option and decrypts it using its private key= to
=C2=A0 =C2=A0obtain the original DHCPv6 message.

=C2=A0 What if the client has more than one key pair (see also the higher =C2=A0 level comment above)?=C2=A0 Is it assumed to associate transaction-i= d to
=C2=A0 a particular key?

[LS]: Yes. In my option, the particular key is associ= ated with transaction-id.
What is your opinion? Looking forward t= o further guidance.=C2=A0

- Section 6

=C2=A0 =C2=A0o=C2=A0 Upon receiving a SignatureFail error status code, the = client MAY
=C2=A0 =C2=A0 =C2=A0 resend the message following normal retransmission rou= tines
=C2=A0 =C2=A0 =C2=A0 defined in [RFC3315].

=C2=A0 What's the rationale of this behavior?

[LS]: In the new version, the client will not send th= e signature option and
timestamp option. So we will delete these = sentence.=C2=A0

- Section 7

=C2=A0 =C2=A0If the server does not send the timestamp option, the client i= gnores
=C2=A0 =C2=A0the timestamp check and verifies the signature.=C2=A0 If there= is a [...]

=C2=A0 I don't understand the role of the first sentence in this contex= t.

[LS]: Will delete the first sentence in the next vers= ion.=C2=A0
=C2=A0
- Section 7

=C2=A0 =C2=A0[...]=C2=A0 Depending on server's local policy, the messag= e without a
=C2=A0 =C2=A0Timestamp option MAY be acceptable or rejected.=C2=A0 If the s= erver
=C2=A0 =C2=A0rejects such a message, a TimestampFail error status code, def= ined in
=C2=A0 =C2=A0Section 10.3, should be sent back to the client.=C2=A0 [...]
=C2=A0 To be sure: is the TimestampFail supposed to be returned when a
=C2=A0 message from the client doesn't have Timestamp but the server wa= nted
=C2=A0 it?

[LS]: Yes. Maybe the above sentences are not clear. H= ow about the following
sentences:
[...] =C2=A0Depending= on server's local policy, the message without a
Timestamp op= tion MAY be accepted or rejected.=C2=A0 If the server
rejects suc= h a message without Timestamp option, then a TimestampFail=C2=A0
= error status code, defined in Section 10.3, should be sent=C2=A0
= back to the client. =C2=A0[...]=C2=A0

- Section 8

=C2=A0 =C2=A0[...]=C2=A0 Actually, by definition in this
=C2=A0 =C2=A0document, relay agents SHOULD NOT add any secure DHCPv6 option= s.

=C2=A0 Why is this a "SHOULD NOT", i.e. can't this be "M= UST NOT"?

[LS]: Agree. Will correct it.=C2=A0
=C2=A0<= /div>
- Section 10.1.2

=C2=A0 =C2=A0Note: if both signature and authentication option are present,=
=C2=A0 =C2=A0signature option does not protect the Authentication Option.= =C2=A0 It

=C2=A0 Should we still worry about it?=C2=A0 The only possible reason for h= aving
=C2=A0 both that I can see is to allow a newer client implementation to
=C2=A0 work with both new and old server implementations.=C2=A0 But now tha= t the
=C2=A0 message is encrypted in a way that older implementations don't =C2=A0 understand, it's completely impossible anymore.=C2=A0 I think we= can now
=C2=A0 simply say Authentication Option shouldn't be used with Secure =C2=A0 DHCPv6 (and if it's used the behavior is undefined).

[LS]: I agree. So we replce this section with the fol= lowing sentences:
If the Secure DHCPv6 is applied, then the Authe= ntication Option shouldn't=C2=A0
be used.=C2=A0
- Section 10.1.3

=C2=A0 =C2=A0Timestamp=C2=A0 =C2=A0 =C2=A0 The current time of day (SeND-fo= rmat timestamp
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in UTC (Coor= dinated Universal Time). It can reduce
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the danger o= f replay attacks.

=C2=A0 I'd add a reference to the SeND RFC here.

[LS]: Have added a reference: Section 5.3.1, [RFC3971= ].=C2=A0
=C2=A0
- Section 10.2.1

=C2=A0 =C2=A0 =C2=A0 0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A03
=C2=A0 =C2=A0 =C2=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 = 7 8 9 0 1
=C2=A0 =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+
=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 msg-type=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0transaction-id=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+
=C2=A0 =C2=A0 =C2=A0.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DUID=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 .
=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(variable)=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+

=C2=A0 Why is the DUID dedicated field, instead of using the server
=C2=A0 identifier option?=C2=A0 There are other types of messages that requ= ire a
=C2=A0 server identifier option (e.g., RENEW), but they don't make it a=
=C2=A0 separate field.=C2=A0 I don't see any reason how this case is di= fferent,
=C2=A0 and using a separate format will make implementations unnecessarily<= br> =C2=A0 complicated.

[LS]: Have modified it. In the new version, the diagr= am should just have basic=C2=A0
client format (see RFC 3315, Sect= ion 6) and then text to specify that it=C2=A0
MUST contain a Serv= er Identifier option and an Encrypted-message option.=C2=A0

<= /div>
Editorial nits:

Thanks a lot for the throughout review. I will correc= t the editorial nits in the next
version. =C2=A0

- Section 4: this sentence at least misses a period (I'm not sure if =C2=A0 it's terminated with 'improved' or some other text was e= xpected
=C2=A0 after that).

=C2=A0 =C2=A0[...]=C2=A0 The
=C2=A0 =C2=A0basic DHCPv6 specification [RFC3315] defines security mechanis= ms, but
=C2=A0 =C2=A0they have significant flaws and can be improved

- Section 5.1: s/authentication, MUST/authentication MUST/

=C2=A0 =C2=A0key.=C2=A0 The message that fails client authentication, MUST = be dropped.
=C2=A0 =C2=A0And the server sends the corresponding error status code to cl= ient.

- Section 6: s/security/Secure/

=C2=A0 =C2=A0For the security DHCPv6 client, it must have a public certific= ate.

- Section 7: s/pre-configured/pre-configured with/

=C2=A0 =C2=A0The server may be pre-configured a public key certificate, whi= ch is

- Section 7: s/replies/replies with/ (same for some other use cases of
=C2=A0 'reply')

=C2=A0 =C2=A0server authentication information, it replies the Reply messag= e to

- Section 8 s/describes/described/

=C2=A0 =C2=A0[...]=C2=A0 The unknown
=C2=A0 =C2=A0messages MUST be forwarded as describes in [RFC7283].

- Section 10.1.2 s/be/be in/

=C2=A0 =C2=A0[...]=C2=A0 The signature option could
=C2=A0 =C2=A0be any place within the DHCPv6 message while it is logically c= reated

- Section 10.1.2 s/chose not/chose not to/ Also, this sentence(-like)
=C2=A0 seems grammatically broken but I have no idea about how to fix it.
=C2=A0 =C2=A0changing auth option, the authors chose not include authentica= tion
=C2=A0 =C2=A0option in the signature.

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

--001a114035acf0b9b20529840430-- From nobody Mon Jan 18 10:42:16 2016 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 EA9281B3B7E; Mon, 18 Jan 2016 10:42:14 -0800 (PST) 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 PM_56NHAzIEZ; Mon, 18 Jan 2016 10:42:13 -0800 (PST) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A496D1B3B32; Mon, 18 Jan 2016 10:42:13 -0800 (PST) Received: by mail-ig0-x235.google.com with SMTP id z14so61282136igp.1; Mon, 18 Jan 2016 10:42:13 -0800 (PST) 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=U7uW1gaOZOVDogCpnNuWZ7gGKvnC+k+f9NN/pGvUaDA=; b=Ee46EncYNvHgbCMebUmnI+QRbvaGTa6V6j0Lyttrxal3c1sWnh6q5Nw+recuFyHtnj qAFDMP2wW45WXMRGBwcI+56UaVhJ+O3PyCUQQvdvx1hzkY+VAhbGY6A/Okx2F5+BK1mD hmkRXjudvlKuqQKnehzZzXMMxqIgYdgTNsqXu32pWOG/IqRWy0AEm8r9LH9oLYpKxtsa 990xf4lmkv9y/Aaqcoptibg0+tt/iRx9AFjmylSHtdaAH4SimjDfSD0pygwPaNzbZhcT kyH1MY6g0Z7AnaaQtIAdM994qZQlpWptEk5+whT37BPg57z5vCUtpqstXwujjpGkEgLK bn3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=U7uW1gaOZOVDogCpnNuWZ7gGKvnC+k+f9NN/pGvUaDA=; b=LC8XYYtaiEoZX0UBfRnEc0TDTy6qcsUFANVgIjpEaFsyvwLXWj1D0D4602takbr7AL w87IxGywbiBv45rTXDtffwIjpVf7PpU/eovmda2j8kx0YzVvUTfJ7bg8zh1dfcVFRMeW VSZwDTAXINWVUN2mvNU2ur+fGqwehBLPOf2kE9fRELLKFiFurLs2QE7BzLZO6ZVHhuIw 9PFByuMVAFOV0reNvQToO6GrBWphorH1jdi3TSN2vS4ClQUif5zk9t0FKO9x2twxUv0L dP6tn1Ha+8CEutUEht+knYeAkinGTAroVt0a2dBNKHx3/LOlNVA7nsnfCj5do+CmNKB8 Jv8A== X-Gm-Message-State: AG10YOQaJ0w2+yN+l80muw5T1Lm7JFxJbVidobeVUtJTP6nzEJ1W+rtdjeEXHafA3m5eMFk3+SRAv1kJnfrjXw== MIME-Version: 1.0 X-Received: by 10.50.111.111 with SMTP id ih15mr12413079igb.78.1453142533102; Mon, 18 Jan 2016 10:42:13 -0800 (PST) Sender: jinmei.tatuya@gmail.com Received: by 10.107.129.80 with HTTP; Mon, 18 Jan 2016 10:42:13 -0800 (PST) In-Reply-To: References: Date: Mon, 18 Jan 2016 10:42:13 -0800 X-Google-Sender-Auth: vfjBN3OA5XRHV-1PVJ0Zm2_Q-0Q Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Lishan Li Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "dhcwg@ietf.org" , draft-ietf-dhc-sedhcpv6@ietf.org Subject: Re: [dhcwg] comments on draft-ietf-dhc-sedhcpv6-10.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: Mon, 18 Jan 2016 18:42:15 -0000 I'm going to answer one specific point first, as I think that's most substantial and requires explicit attention from other wg members. At Sun, 17 Jan 2016 17:11:18 +0800, Lishan Li wrote: > > - this protocol changes DHCPv6 message exchanges quite substantially: > > previously, the client first sends a Solicit message, gets possibly > > multiple Advertise messages, chooses the server (= sender of one of > > the Advertises) that would be best for the client, and then sends a > > Request to that chosen server. Now the server selection is done at > > the key exchange phase (the initial Information-request and Reply > > exchange), and the Solicit can be sent only to a single server. If > > the client doesn't like the Advertise it could restart the whole > > process, but it will be more expensive, and there's no guarantee > > that other servers can provide a better Advertise. > > > > One might argue that it's okay as "secure DHCPv6" is an "optional" > > extension. But, with keeping in mind that the current IETF trend is > > to make everything privacy-aware (often by making everything > > encrypted), I'd personally say we should consider it to be the > > standard mode of DHCPv6 operation even if users can still disable > > it. From this point of view, I think we should either > > A. make the server selection behavior more compatible with the > > pre-encryption protocol, or > > B. accept we give up the previous server selection feature for > > privacy (after careful assessment of its effect and with clear wg > > consensus), and explicitly note that. we might even have to > > reflect that in rfc3315bis. > > > > [LS]: In my opinion, we should give up the previous server selection > feature for > privacy. Compared with rfc3315 and rfc3315bits, secure DHCPv6 is another > mode. rfc3315bis is clear-text mode. And the secure DHCPv6 is secure mode > which achieves authentication and encryption. The server selection feature > and configuration process are all different. And I think it is not > necessary > to reflect the character of secure DHCPv6 mode in rfc3315bis. Looking > forward > to your further guidance. This basically seems to be what "one might argue" in my original comment, so, obviously, I personally disagree on that rationale. But I wouldn't be surprised if the wg reaches to a different consensus than my personal opinion, so I suggest you start a separate discussion on this to form the consensus. -- JINMEI, Tatuya From nobody Mon Jan 18 11:08:06 2016 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 BF1381B3BF6; Mon, 18 Jan 2016 11:08:04 -0800 (PST) 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 gzlXUTac1yXz; Mon, 18 Jan 2016 11:08:02 -0800 (PST) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DCE51B3BD3; Mon, 18 Jan 2016 11:08:01 -0800 (PST) Received: by mail-ig0-x22d.google.com with SMTP id t15so61811370igr.0; Mon, 18 Jan 2016 11:08:01 -0800 (PST) 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=lLFbyz/Wz+jCD5hZUpxkNhkKlwmcS8Ow1kDSxZ6TaJY=; b=x45vqo3rIys6cmkQjxiBTsVpqLfI3bUr4AZqP4AnsE7Mi8r8moP+RHzQSjT+pKbIzb LxFB4blcsMHdarWGfBuIFSTxk0evK9+E+6zRF/sWu0QHUtaGyaZjoUL+N6rH4r0YadOi XLNDHbG2PE0CLqhcw43Kf1T5FOZMsZA0T4BiZUsumGSdF3Mel8lVWqjsf63k9bYFv96U PTGMP5LxgzitBMtIaNcBZuFKxWw5WQo4XCgbE9wBWYr0QDuoWX2g31mwPIxBNtvyO+A/ WMFA1tQTwGOGqKkcR30QIWg+POpDZqYVCHrs9QLEVgJpAGLf+hXi/MONuSJMaqMSfoBH tJ1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=lLFbyz/Wz+jCD5hZUpxkNhkKlwmcS8Ow1kDSxZ6TaJY=; b=b0U/Ylv2iDfCwM2RZ8xuCDvQXTqTq0oME0OMxQ89MobK3g8UUp11abw/MpF+tOwJ2q fIhhApFeB5NAtrY0TuC7+mslcuQ1X/AP+DtMC273NnT2PqqsIm2Q36lNr7NnrAiiY7Ws 9tkqWK9Otn/U6hC+9JjO6UcPhf3FZZHeZ/e/9hO2h4W2Cah/QtFxNcW6ZGQsFOEEfN5b hak0IIsTDXQO9lw8BW8UmepZ6IlWHf7/BMDeC34NHfiWNS30bsERfceZ5/IYVYKyI8ZB flQbXYm2a1+/IFw6/cxNcnSx2yHcljnrk+RU8g6SAXwZM6I6X4YR5PEH1OSQm7QaPLxe +9FQ== X-Gm-Message-State: AG10YORa6SCAklD77MKu+yf+YxZ7adDeRH9vk631qMU0/BHZ9PaVrqulAOZqy6usIzqfIShoAKft/AeV+Hu+nA== MIME-Version: 1.0 X-Received: by 10.50.13.100 with SMTP id g4mr11246853igc.64.1453144080397; Mon, 18 Jan 2016 11:08:00 -0800 (PST) Sender: jinmei.tatuya@gmail.com Received: by 10.107.129.80 with HTTP; Mon, 18 Jan 2016 11:08:00 -0800 (PST) In-Reply-To: References: Date: Mon, 18 Jan 2016 11:08:00 -0800 X-Google-Sender-Auth: MTUEH7W-jjKc5iG-2TUz4Lwf4FI Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Lishan Li Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "dhcwg@ietf.org" , draft-ietf-dhc-sedhcpv6@ietf.org Subject: Re: [dhcwg] comments on draft-ietf-dhc-sedhcpv6-10.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: Mon, 18 Jan 2016 19:08:04 -0000 At Sun, 17 Jan 2016 16:52:38 +0800 (CST), "Lishan Li" wrote: > >- As encryption is now mandatory, I now wonder whether we need a > > separate "signature" at all. Except for the signature in the reply > > to the initial Information-request, the explicit signature doesn't > > seem to provide any additional integrity or authentication. And, as > > we now don't allow TOFU for authentication (i.e., we should validate the > > certificate out-of-band anyway, and that's almost the only important > > content of this reply), the signature in the first Reply wouldn't be > > much useful either. So we might consider simplifying the protocol > > > > [LS]: In the current version, the client-to-server and server-to-client > both send the certificate option, signature option and timestamp option. > I think that only the server-to-client case MUST contain the signature > option and timestamp option. > In the server-to-client case, the signature and timestamp option in > the Reply message is used to protect the message integrity. So it is > better to remain the timestamp and signature option. > In the client-to-server case, the certificate option is contained in > the encrypted Solicit/Information-request message. Because the message > is encrypted, there is no need to contain the signature and timestamp > option to protect the message integrity. > What do you think of it? Maybe my points weren't clear enough. First off, I didn't talk about timestamp at all; let's focus on the signature option. Secondly, I don't see why encryption is not enough in the server-to-client case for message integrity. > >- This protocol uses the server DUID as the identifier of the server > > key (pair), and (implicitly) assumes the client only has one key > > (pair). Is that okay? Don't we need a separate key ID value so we > > can identify the key to be used for decryption without actually > > trying to decrypt the message with all possible keys? (In the case > > of client this might be trickier since the 'key ID' can reveal the > > identify of the client). > > > > [LS]: I think we can use the message transaction-id as the identifier of > the server's public key for encryption, and the client's private key > for decryption. What do you think of it? It's probably okay. I think it should be described more explicitly. > >- The 'public key option' has been removed in this version. I > > probably missed some part of the past discussions, but did we make > > that decision? What's the rationale of the removal? > > > [LS]: In the current version, TOFU is out of scope. The client and server > use certificates for authentication, not public key. So I think the certificate > option is enough. The public key option is removed. I don't understand that. We should still be able to manually configure public keys on clients and servers (see also the applicability discussion), so simply because we removed the TOFU mode shouldn't me we should remove the public key option. > >Some specific comments on the draft text follow: > > > >- Section 4 > > > > authentication method. However, this method provides little message > > integrity or source integrity check, and it protects only the > > Reconfigure message. This key is transmitted in plaintext. > > > > I'm not sure if I get the phrase "this method provides little > > message integrity or source integrity check". Does it try to say > > "*Because* the key is transmitted in plaintext"? > > > [LS]: How about the following text: > [...] However, this method provides little message integrity or source > integrity check, and it protects only the Reconfigure message. In addition, > the key is transmitted in plaintext to the client in earlier exchanges. > [...] This one still has the same problem. Why does this method (=Reconfigure Key Authentication Protocol) provide little message integrity or source integrity? > >- Section 5.3: what about the server-to-client case? Clients are > > expected to rely on the selection in the initial > > Information-request/Reply exchange? > > > > If the recipient does not support the algorithm used by the sender, > > it cannot authenticate the message. In the client-to-server case, > > the server SHOULD reply with an AlgorithmNotSupported status code > > (defined in Section 10.3). Upon receiving this status code, the > > client MAY resend the message protected with the mandatory algorithm > > (defined in Section 10.1.2). > > > [LS]: In the next version, only in the server-to-client case, the server > will send the Reply message with signature and timestamp option to the > client for server authentication. > So, how about replacing with the following text: > If the client does not support the hash and signature algorithms used by > the server, the Reply message SHOULD be dropped. If both hash and signature > algorithms are supported, the client then checks the authority of this > server. The client SHOULD also use the same algorithms in the subsequent > messages. Dropping the message is fine, but then what? Should the client keep waiting for an expected reply and then possibly retransmit its message? > >- Section 5.4: in general, I think this section is still quite weak > > and/or insufficient. [...] > > > > [LS]: How about the following "applicability" section: > Secure DHCPv6 is applicable in environments where physical security > on the link is not assured and attacks on DHCPv6 are a concern, such > as enterprise networks. In enterprise networks, the DHCPv6 clients > are manually pre-configured with the trusted servers' certificates to > achieve server authentication. In addition, the DHCPv6 server is > pre-configured with the trusted clients' certificates to verify the client's > identity. After the mutual authentication, the DHCPv6 message is encrypted > with the recipient's public key, which is contained in the certificate. > The use of PKI as a possibility of making the configuration less manual. > However, its feasibility is unclear right now and subject to future study > and development. > > And we supply the following text in section 4: > The public-key based approach proposed in this document is slightly > securer in some cases. For example, if the client's key is quietly > stolen by an attacker, then the attack can pretend to be a valid client > later. I'd first like to know whether we (the wg in general including yourself) agree on my points and understanding of previous feedback. On top of that, I'll probably offer my own proposed text on these. > >- Section 5.4: > > > > [...] In enterprise network, the security policy is > > strict and the clients are stable terminals. The PKI model is used > > > > What does 'stable' mean? A desktop PC would be considered a "stable > > terminal", but what about laptops? How about smart phones connected > > to the enterprise network based on the BYOD policy? This point isn't answered. > >- Section 6 > > > > non-security options assigned to it. The Option Request option in > > the Information-request message MUST contain the option code of > > certificate option, signature option, timestamp option, and server > > identifier option. > > > > Should we really need to include all of these? The certificate > > option should surely be specified, but the need for the others seem > > to be almost automatically derived from the specification. > > > [LS]: The signature option and timestamp option are used for the message > integrity check. The Reply message is transmitted in clear text. So in > order to protect the Reply message integrity, I think the timestamp > and signature option MUST be contained. We are probably talking about different things. My question and point are whether timestamp and signature are specified in the "option request option". Your response doesn't seem to answer that point. > >- Section 6 > > > > For the received Encrypted-Response message, the client extracts the > > encrypted-message option and decrypts it using its private key to > > obtain the original DHCPv6 message. > > > > What if the client has more than one key pair (see also the higher > > level comment above)? Is it assumed to associate transaction-id to > > a particular key? > > > > [LS]: Yes. In my option, the particular key is associated with transaction-id. > What is your opinion? Looking forward to further guidance. See above. > > > >- Section 6 > > > > o Upon receiving a SignatureFail error status code, the client MAY > > resend the message following normal retransmission routines > > defined in [RFC3315]. > > > > What's the rationale of this behavior? > > > > [LS]: In the new version, the client will not send the signature option and > timestamp option. So we will delete these sentence. Deleting it is probably fine, but it doesn't answer my point. We'll still need to answer what the client should do if the server indicates a failure in decryption (which is equivalent to SignatureFail). > >- Section 7 > > > > [...] Depending on server's local policy, the message without a > > Timestamp option MAY be acceptable or rejected. If the server > > rejects such a message, a TimestampFail error status code, defined in > > Section 10.3, should be sent back to the client. [...] > > > > To be sure: is the TimestampFail supposed to be returned when a > > message from the client doesn't have Timestamp but the server wanted > > it? > > > [LS]: Yes. Maybe the above sentences are not clear. How about the following > sentences: > [...] Depending on server's local policy, the message without a > Timestamp option MAY be accepted or rejected. If the server > rejects such a message without Timestamp option, then a TimestampFail > error status code, defined in Section 10.3, should be sent > back to the client. [...] Doesn't the original text (also) cover the case where Timestamp is included but the check on it fails? If so, the new text now loses its original sense. > >- Section 10.1.2 > > > > Note: if both signature and authentication option are present, > > signature option does not protect the Authentication Option. It > > > > Should we still worry about it? The only possible reason for having > > both that I can see is to allow a newer client implementation to > > work with both new and old server implementations. But now that the > > message is encrypted in a way that older implementations don't > > understand, it's completely impossible anymore. I think we can now > > simply say Authentication Option shouldn't be used with Secure > > DHCPv6 (and if it's used the behavior is undefined). > > > > [LS]: I agree. So we replce this section with the following sentences: > If the Secure DHCPv6 is applied, then the Authentication Option shouldn't > be used. It should also describe the rationale. Also, we might consider using an RFC2119 keyword, either SHOULD NOT or MUST NOT. -- JINMEI, Tatuya From nobody Mon Jan 18 23:31:11 2016 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F0AC01ACE3B; Mon, 18 Jan 2016 23:31:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.12.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160119073107.29743.83162.idtracker@ietfa.amsl.com> Date: Mon, 18 Jan 2016 23:31:07 -0800 Archived-At: Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcp-privacy-03.txt 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: Tue, 19 Jan 2016 07:31:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Privacy considerations for DHCPv4 Authors : Sheng Jiang Suresh Krishnan Tomek Mrugalski Filename : draft-ietf-dhc-dhcp-privacy-03.txt Pages : 14 Date : 2016-01-18 Abstract: DHCP is a protocol that is used to provide addressing and configuration information to IPv4 hosts. This document discusses the various identifiers used by DHCP and the potential privacy issues. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcp-privacy/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dhc-dhcp-privacy-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcp-privacy-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 20 14:54:51 2016 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5451B2A45; Wed, 20 Jan 2016 14:54:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160120225444.15828.5822.idtracker@ietfa.amsl.com> Date: Wed, 20 Jan 2016 14:54:44 -0800 Archived-At: Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-privacy-03.txt 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: Wed, 20 Jan 2016 22:54:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Privacy considerations for DHCPv6 Authors : Suresh Krishnan Tomek Mrugalski Sheng Jiang Filename : draft-ietf-dhc-dhcpv6-privacy-03.txt Pages : 16 Date : 2016-01-20 Abstract: DHCPv6 is a protocol that is used to provide addressing and configuration information to IPv6 hosts. This document described the privacy issues associated with the use of DHCPv6 by the Internet users. It is intended to be an analysis of the present situation and doe not propose any solutions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-privacy/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-privacy-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv6-privacy-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 21 06:34:36 2016 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ACF571A888B; Thu, 21 Jan 2016 06:34:27 -0800 (PST) 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: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160121143427.11084.41743.idtracker@ietfa.amsl.com> Date: Thu, 21 Jan 2016 06:34:27 -0800 Archived-At: Cc: dhc-chairs@ietf.org, draft-ietf-dhc-dhcp-privacy@ietf.org, volz@cisco.com, dhcwg@ietf.org Subject: [dhcwg] Last Call: (Privacy considerations for DHCPv4) to Informational RFC X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 14:34:28 -0000 The IESG has received a request from the Dynamic Host Configuration WG (dhc) to consider the following document: - 'Privacy considerations for DHCPv4' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-02-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract DHCP is a protocol that is used to provide addressing and configuration information to IPv4 hosts. This document discusses the various identifiers used by DHCP and the potential privacy issues. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcp-privacy/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcp-privacy/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Jan 21 06:48:59 2016 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0818C1B2B0A; Thu, 21 Jan 2016 06:48:57 -0800 (PST) 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: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160121144857.31868.39483.idtracker@ietfa.amsl.com> Date: Thu, 21 Jan 2016 06:48:57 -0800 Archived-At: Cc: dhc-chairs@ietf.org, volz@cisco.com, dhcwg@ietf.org, draft-ietf-dhc-dhcpv6-privacy@ietf.org Subject: [dhcwg] Last Call: (Privacy considerations for DHCPv6) to Informational RFC X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 14:48:57 -0000 The IESG has received a request from the Dynamic Host Configuration WG (dhc) to consider the following document: - 'Privacy considerations for DHCPv6' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-02-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract DHCPv6 is a protocol that is used to provide addressing and configuration information to IPv6 hosts. This document described the privacy issues associated with the use of DHCPv6 by the Internet users. It is intended to be an analysis of the present situation and doe not propose any solutions. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-privacy/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-privacy/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Jan 21 07:27:23 2016 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 04EB31B3205; Thu, 21 Jan 2016 07:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 DUlcIv_YiMAo; Thu, 21 Jan 2016 07:27:06 -0800 (PST) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFEFC1B31FE; Thu, 21 Jan 2016 07:27:05 -0800 (PST) Received: by mail-lb0-x22a.google.com with SMTP id oh2so25173969lbb.3; Thu, 21 Jan 2016 07:27:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YwRu2CpUzTL/mNzbHq5zgzzg66ABp8S5iQSjMLkx0Ro=; b=TzvKzJNZZhcnku52PUDlQrh1/mfup2q6htxDPj34P4ivvjBsxgHyflpN6BXXD9utlB C3ATwJSlwwdLqluho/A6gVEauIdQK24qSZBOORKoL9Q69+6o1R4LGAFK4r2u8nYV2VG2 E3YbtSMWPSeO0xFYaPM7S6aOTHsejXy524P3f9qcbc5C4FKtnL5oXP49VPVLLq3Kn28f /Djy7MSWQRAsDY3PGBOPaVtoQYYsqzGwKNttcbEH+p8v4RrVXCtCdaoii7WiYLs7TU06 fdPyzeCXPHmD1Qp5cEaQLn/TieRnL3Ag6mcbxVHr7IcB8xloQQqn/cM9K53vmVfObt3p hxgA== 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=YwRu2CpUzTL/mNzbHq5zgzzg66ABp8S5iQSjMLkx0Ro=; b=bQR44wN2aR0T5MAi+fCscB+dtK/dTzAClI7UZOO2/HYyB48d6ZsR5hYYQKmeWJihDP /67H5bsaFQClxZAqRESn9cfQlbyVkZ8Vej17Q/DOid42QycZdfdZbgg2ZagTGr3sj5E4 duYOu96scYvxFRBh0nSUHrulsfo4LrKTIfidlIQVLQAZdXtCceq9zAl15E9WHWi2ToLz ElzdLdIxE1admeBsx2ELXLoUlkJgyDB8J4UyyuV6kMOJy5Oj6VUW/waeOSAQOATN0N1J 8iGpGzpgrC7HPNYHyG9UzI2SEHoE9IiAykY6LTf09ft3F7isDSguIy9SWFJxCO+b05Qa H9WA== X-Gm-Message-State: ALoCoQlROdcADJYRgaM3wJXBKUuVRSCOdBzhBO47DUNq6p05AR501+Oy/A8rbfRqT/pQkRagr2ZyQ4/BO31n8YMdNvxN45ZR+g== MIME-Version: 1.0 X-Received: by 10.112.132.6 with SMTP id oq6mr12782548lbb.38.1453390023850; Thu, 21 Jan 2016 07:27:03 -0800 (PST) Received: by 10.114.79.194 with HTTP; Thu, 21 Jan 2016 07:27:03 -0800 (PST) In-Reply-To: References: Date: Thu, 21 Jan 2016 23:27:03 +0800 Message-ID: From: Lishan Li To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Content-Type: multipart/alternative; boundary=047d7b3a825c17ab840529d9bc42 Archived-At: Cc: "dhcwg@ietf.org" , draft-ietf-dhc-sedhcpv6@ietf.org Subject: Re: [dhcwg] comments on draft-ietf-dhc-sedhcpv6-10.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, 21 Jan 2016 15:27:11 -0000 --047d7b3a825c17ab840529d9bc42 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Jinmei, Please see inline. 2016-01-19 3:08 GMT+08:00 =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 : > At Sun, 17 Jan 2016 16:52:38 +0800 (CST), > "Lishan Li" wrote: > > > >- As encryption is now mandatory, I now wonder whether we need a > > > separate "signature" at all. Except for the signature in the reply > > > to the initial Information-request, the explicit signature doesn't > > > seem to provide any additional integrity or authentication. And, as > > > we now don't allow TOFU for authentication (i.e., we should validate > the > > > certificate out-of-band anyway, and that's almost the only important > > > content of this reply), the signature in the first Reply wouldn't be > > > much useful either. So we might consider simplifying the protocol > > > > > > > [LS]: In the current version, the client-to-server and server-to-client > > both send the certificate option, signature option and timestamp option= . > > I think that only the server-to-client case MUST contain the signature > > option and timestamp option. > > In the server-to-client case, the signature and timestamp option in > > the Reply message is used to protect the message integrity. So it is > > better to remain the timestamp and signature option. > > In the client-to-server case, the certificate option is contained in > > the encrypted Solicit/Information-request message. Because the message > > is encrypted, there is no need to contain the signature and timestamp > > option to protect the message integrity. > > What do you think of it? > > Maybe my points weren't clear enough. First off, I didn't talk about > timestamp at all; let's focus on the signature option. Secondly, I > don't see why encryption is not enough in the server-to-client case > for message integrity. > [LS]:In the server-to-client case, the Reply message is transmitted in cleartext not encryption, which contains the server's certificate information. So I think that it is better to contain the signature option for the Reply message integrity check. Looking forward to your further guidance. > >- This protocol uses the server DUID as the identifier of the server > > > key (pair), and (implicitly) assumes the client only has one key > > > (pair). Is that okay? Don't we need a separate key ID value so we > > > can identify the key to be used for decryption without actually > > > trying to decrypt the message with all possible keys? (In the case > > > of client this might be trickier since the 'key ID' can reveal the > > > identify of the client). > > > > > > > [LS]: I think we can use the message transaction-id as the identifier o= f > > the server's public key for encryption, and the client's private key > > for decryption. What do you think of it? > > It's probably okay. I think it should be described more explicitly. > > [LS]: Will add the explicit description. > >- The 'public key option' has been removed in this version. I > > > probably missed some part of the past discussions, but did we make > > > that decision? What's the rationale of the removal? > > > > > [LS]: In the current version, TOFU is out of scope. The client and serv= er > > use certificates for authentication, not public key. So I think the > certificate > > option is enough. The public key option is removed. > > I don't understand that. We should still be able to manually > configure public keys on clients and servers (see also the > applicability discussion), so simply because we removed the TOFU mode > shouldn't me we should remove the public key option. > > [LS]: If the device is pre-configured with public key not certificate, it can generate the self-signed certificate for authentication. So, I think that the certificate option is enough for authentication. Looking forward to your further guidance. > >Some specific comments on the draft text follow: > > > > > >- Section 4 > > > > > > authentication method. However, this method provides little messag= e > > > integrity or source integrity check, and it protects only the > > > Reconfigure message. This key is transmitted in plaintext. > > > > > > I'm not sure if I get the phrase "this method provides little > > > message integrity or source integrity check". Does it try to say > > > "*Because* the key is transmitted in plaintext"? > > > > > [LS]: How about the following text: > > [...] However, this method provides little message integrity or source > > integrity check, and it protects only the Reconfigure message. In > addition, > > the key is transmitted in plaintext to the client in earlier exchanges. > > [...] > > This one still has the same problem. Why does this method > (=3DReconfigure Key Authentication Protocol) provide little message > integrity or source integrity? > > [LS]: The authentication mechanism defined in RFC3315 can provide for the authentication of the client and server, and for the integrity of messages delivered between DHCPv6 clients and servers. So, how about the following text: [...] However, this method protects only the Reconfigure message. In addition, the key is transmitted in plaintext to the client in earlier exchanges. [...] > >- Section 5.3: what about the server-to-client case? Clients are > > > expected to rely on the selection in the initial > > > Information-request/Reply exchange? > > > > > > If the recipient does not support the algorithm used by the sender, > > > it cannot authenticate the message. In the client-to-server case, > > > the server SHOULD reply with an AlgorithmNotSupported status code > > > (defined in Section 10.3). Upon receiving this status code, the > > > client MAY resend the message protected with the mandatory algorith= m > > > (defined in Section 10.1.2). > > > > > [LS]: In the next version, only in the server-to-client case, the serve= r > > will send the Reply message with signature and timestamp option to the > > client for server authentication. > > So, how about replacing with the following text: > > If the client does not support the hash and signature algorithms used b= y > > the server, the Reply message SHOULD be dropped. If both hash and > signature > > algorithms are supported, the client then checks the authority of this > > server. The client SHOULD also use the same algorithms in the subsequen= t > > messages. > > Dropping the message is fine, but then what? Should the client keep > waiting for an expected reply and then possibly retransmit its message? > > [LS]: If the Reply message is dropped and there is no other authenticated DHCPv6 server, then the scenario is no authenticated DHCPv6 server. And then the client's following behavior is: If there are no authenticated DHCPv6 servers or existing servers failed authentication, the client behavior is policy specific. Depending on its policy, it can choose to repeat the server discovery process after certain delay or attempt to use an unsecured DHCPv6 server. > >- Section 5.4: in general, I think this section is still quite weak > > > and/or insufficient. [...] > > > > > > > [LS]: How about the following "applicability" section: > > Secure DHCPv6 is applicable in environments where physical security > > on the link is not assured and attacks on DHCPv6 are a concern, such > > as enterprise networks. In enterprise networks, the DHCPv6 clients > > are manually pre-configured with the trusted servers' certificates to > > achieve server authentication. In addition, the DHCPv6 server is > > pre-configured with the trusted clients' certificates to verify the > client's > > identity. After the mutual authentication, the DHCPv6 message is > encrypted > > with the recipient's public key, which is contained in the certificate= . > > The use of PKI as a possibility of making the configuration less manual= . > > However, its feasibility is unclear right now and subject to future stu= dy > > and development. > > > > And we supply the following text in section 4: > > The public-key based approach proposed in this document is slightly > > securer in some cases. For example, if the client's key is quietly > > stolen by an attacker, then the attack can pretend to be a valid client > > later. > > I'd first like to know whether we (the wg in general including > yourself) agree on my points and understanding of previous feedback. > On top of that, I'll probably offer my own proposed text on these. > > [LS]: I agree with your proposed point. Looking forward to your proposed text on this. > >- Section 5.4: > > > > > > [...] In enterprise network, the security policy is > > > strict and the clients are stable terminals. The PKI model is used > > > > > > What does 'stable' mean? A desktop PC would be considered a "stable > > > terminal", but what about laptops? How about smart phones connected > > > to the enterprise network based on the BYOD policy? > > This point isn't answered. > > [LS]: In the secure DHCPv6 deployment draft, we mainly consider two different scenario: stable client with strict security policy and roaming client with loose security policy. For the stable clients, such as the desktop PC in enterprise network, they are pre-configured the trusted servers' certificates or the trusted CAs' certificates for server authentication. For the roaming clients, such as the smart phones in coffee room, it is difficult to be pre-configured the trusted certificates for authentication. What do you think of the scenario classification? > >- Section 6 > > > > > > non-security options assigned to it. The Option Request option in > > > the Information-request message MUST contain the option code of > > > certificate option, signature option, timestamp option, and server > > > identifier option. > > > > > > Should we really need to include all of these? The certificate > > > option should surely be specified, but the need for the others seem > > > to be almost automatically derived from the specification. > > > > > [LS]: The signature option and timestamp option are used for the messag= e > > integrity check. The Reply message is transmitted in clear text. So in > > order to protect the Reply message integrity, I think the timestamp > > and signature option MUST be contained. > > We are probably talking about different things. My question and point > are whether timestamp and signature are specified in the "option > request option". Your response doesn't seem to answer that point. > > [LS]: The certificate option "MUST" be contained, and the signature optio= n and timestamp option "SHOULD" be contained. Have I got what you mean? > >- Section 6 > > > > > > For the received Encrypted-Response message, the client extracts th= e > > > encrypted-message option and decrypts it using its private key to > > > obtain the original DHCPv6 message. > > > > > > What if the client has more than one key pair (see also the higher > > > level comment above)? Is it assumed to associate transaction-id to > > > a particular key? > > > > > > > [LS]: Yes. In my option, the particular key is associated with > transaction-id. > > What is your opinion? Looking forward to further guidance. > > See above. > > > > > > >- Section 6 > > > > > > o Upon receiving a SignatureFail error status code, the client MAY > > > resend the message following normal retransmission routines > > > defined in [RFC3315]. > > > > > > What's the rationale of this behavior? > > > > > > > [LS]: In the new version, the client will not send the signature option > and > > timestamp option. So we will delete these sentence. > > Deleting it is probably fine, but it doesn't answer my point. We'll > still need to answer what the client should do if the server indicates > a failure in decryption (which is equivalent to SignatureFail). > > [LS]: In the current version, we consider the scenario where the server indicates a failure in authentication. If the message fails certificate validation, the DHCPv6 server SHOULD reply with an AuthenticationFail error status code to the client. So, you suggest to define a new error status code: DecryptionFail error status code. If the DHCPv6 server fails decryption, the DHCPv6 server SHOULD reply with an DecryptionFail error status code to the client. Could you please check whether my understanding is correct? > >- Section 7 > > > > > > [...] Depending on server's local policy, the message without a > > > Timestamp option MAY be acceptable or rejected. If the server > > > rejects such a message, a TimestampFail error status code, defined = in > > > Section 10.3, should be sent back to the client. [...] > > > > > > To be sure: is the TimestampFail supposed to be returned when a > > > message from the client doesn't have Timestamp but the server wanted > > > it? > > > > > [LS]: Yes. Maybe the above sentences are not clear. How about the > following > > sentences: > > [...] Depending on server's local policy, the message without a > > Timestamp option MAY be accepted or rejected. If the server > > rejects such a message without Timestamp option, then a TimestampFail > > error status code, defined in Section 10.3, should be sent > > back to the client. [...] > > Doesn't the original text (also) cover the case where Timestamp is > included but the check on it fails? If so, the new text now loses its > original sense. > > [LS]: The original text covers the scenario where the timestamp check fails. But the lack of timestamp and timestamp check failure are two different scenario. So I don't understand why the new text now loses its original sense. Looking forward to the further guidance. > >- Section 10.1.2 > > > > > > Note: if both signature and authentication option are present, > > > signature option does not protect the Authentication Option. It > > > > > > Should we still worry about it? The only possible reason for having > > > both that I can see is to allow a newer client implementation to > > > work with both new and old server implementations. But now that the > > > message is encrypted in a way that older implementations don't > > > understand, it's completely impossible anymore. I think we can now > > > simply say Authentication Option shouldn't be used with Secure > > > DHCPv6 (and if it's used the behavior is undefined). > > > > > > > [LS]: I agree. So we replce this section with the following sentences: > > If the Secure DHCPv6 is applied, then the Authentication Option shouldn= 't > > be used. > > It should also describe the rationale. Also, we might consider using > an RFC2119 keyword, either SHOULD NOT or MUST NOT. [LS]: How about the following text=EF=BC=9B If Secure DHCPv6 is used, the DHCPv6 message is encrypted in a way that the authentication mechanism defined in RFC3315 don't understand. So, the Authentication option SHOULD NOT be used if Secure DHCPv6 is applied. Best Regards, Lishan --047d7b3a825c17ab840529d9bc42 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Jinmei,

Please see inline.

2016-01-19 3:0= 8 GMT+08:00 =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 <jinmei@wide.ad.jp>= ;:
At Sun, 17 Jan 2016 16:52:38 +0800 (CST),
"Lishan Li" <lilishan48@126.com> wrote:

> >- As encryption is now mandatory, I now wonder whether we need a > >=C2=A0 separate "signature" at all.=C2=A0 Except for the= signature in the reply
> >=C2=A0 to the initial Information-request, the explicit signature = doesn't
> >=C2=A0 seem to provide any additional integrity or authentication.= =C2=A0 And, as
> >=C2=A0 we now don't allow TOFU for authentication (i.e., we sh= ould validate the
> >=C2=A0 certificate out-of-band anyway, and that's almost the o= nly important
> >=C2=A0 content of this reply), the signature in the first Reply wo= uldn't be
> >=C2=A0 much useful either.=C2=A0 So we might consider simplifying = the protocol
>
> >
> [LS]: In the current version, the client-to-server and server-to-clien= t
> both send the certificate option, signature option and timestamp optio= n.
> I think that only the server-to-client case MUST contain the signature=
> option and timestamp option.
> In the server-to-client case, the signature and timestamp option in > the Reply message is used to protect the message integrity. So it is > better to remain the timestamp and signature option.
> In the client-to-server case, the certificate option is contained in > the encrypted Solicit/Information-request message. Because the message=
> is encrypted, there is no need to contain the signature and timestamp<= br> > option to protect the message integrity.
> What do you think of it?

Maybe my points weren't clear enough.=C2=A0 First off, I didn= 9;t talk about
timestamp at all; let's focus on the signature option.=C2=A0 Secondly, = I
don't see why encryption is not enough in the server-to-client case
for message integrity. =C2=A0
=C2=A0
[LS]:In the server-to-client case, the Reply message is transmi= tted in=C2=A0
cleartext not encryption, which contains the server= 's certificate information.=C2=A0
So I think that it is bette= r to contain the signature option for the Reply=C2=A0
message int= egrity check.
Looking forward to your further guidance.=C2=A0

> >- This protocol= uses the server DUID as the identifier of the server
> >=C2=A0 key (pair), and (implicitly) assumes the client only has on= e key
> >=C2=A0 (pair).=C2=A0 Is that okay?=C2=A0 Don't we need a separ= ate key ID value so we
> >=C2=A0 can identify the key to be used for decryption without actu= ally
> >=C2=A0 trying to decrypt the message with all possible keys?=C2=A0= (In the case
> >=C2=A0 of client this might be trickier since the 'key ID'= can reveal the
> >=C2=A0 identify of the client).
>
> >
> [LS]: I think we can use the message transaction-id as the identifier = of
> the server's public key for encryption, and the client's priva= te key
> for decryption. What do you think of it?

It's probably okay.=C2=A0 I think it should be described more ex= plicitly.

[LS]: Will add the explicit description.

> >- The 'public key= option' has been removed in this version.=C2=A0 I
> >=C2=A0 probably missed some part of the past discussions, but did = we make
> >=C2=A0 that decision?=C2=A0 What's the rationale of the remova= l?
> >
> [LS]: In the current version, TOFU is out of scope. The client and ser= ver
> use=C2=A0 certificates for authentication, not public key. So I think = the certificate
> option is enough. The public key option is removed.

I don't understand that.=C2=A0 We should still be able to manual= ly
configure public keys on clients and servers (see also the
applicability discussion), so simply because we removed the TOFU mode
shouldn't me we should remove the public key option.

[LS]: If the device is pre-configured with public = key not certificate, it can=C2=A0
generate the self-signed certif= icate for authentication. So, I think that
the certificate option= is enough for authentication.=C2=A0
Looking forward to your furt= her guidance.=C2=A0

&= gt; >Some specific comments on the draft text follow:
> >
> >- Section 4
> >
> >=C2=A0 =C2=A0authentication method.=C2=A0 However, this method pro= vides little message
> >=C2=A0 =C2=A0integrity or source integrity check, and it protects = only the
> >=C2=A0 =C2=A0Reconfigure message.=C2=A0 This key is transmitted in= plaintext.
> >
> >=C2=A0 I'm not sure if I get the phrase "this method prov= ides little
> >=C2=A0 message integrity or source integrity check".=C2=A0 Do= es it try to say
> >=C2=A0 "*Because* the key is transmitted in plaintext"?<= br> > >
> [LS]: How about the following text:
> [...]=C2=A0 However, this method provides little message integrity or = source
> integrity check, and it protects only the Reconfigure message. In addi= tion,
> the key is transmitted in plaintext to the client in earlier exchanges= .
> [...]

This one still has the same problem.=C2=A0 Why does this method
(=3DReconfigure Key Authentication Protocol) provide little message
integrity or source integrity?

[LS]: The authentication mechanism defined in RFC3= 315 can provide for the=C2=A0
authentication of the client and se= rver, and for the integrity of messages=C2=A0
delivered between D= HCPv6 clients and servers.
So, how about the following text:
[...] =C2=A0However, this method protects only the Reconfigure messag= e. In addition,
the key is transmitted in plaintext to the client= in earlier exchanges.
[...]=C2=A0

> >- Section 5.3: what about the server-to-cl= ient case?=C2=A0 Clients are
> >=C2=A0 expected to rely on the selection in the initial
> >=C2=A0 Information-request/Reply exchange?
> >
> >=C2=A0 =C2=A0If the recipient does not support the algorithm used = by the sender,
> >=C2=A0 =C2=A0it cannot authenticate the message.=C2=A0 In the clie= nt-to-server case,
> >=C2=A0 =C2=A0the server SHOULD reply with an AlgorithmNotSupported= status code
> >=C2=A0 =C2=A0(defined in Section 10.3).=C2=A0 Upon receiving this = status code, the
> >=C2=A0 =C2=A0client MAY resend the message protected with the mand= atory algorithm
> >=C2=A0 =C2=A0(defined in Section 10.1.2).
> >
> [LS]: In the next version, only in the server-to-client case, the serv= er
> will send the Reply message with signature and timestamp option to the=
> client for server authentication.
> So, how about replacing with the following text:
> If the client does not support the hash and signature algorithms used = by
> the server, the Reply message SHOULD be dropped. If both hash and sign= ature
> algorithms are supported, the client then checks the authority of this=
> server. The client SHOULD also use the same algorithms in the subseque= nt
> messages.

Dropping the message is fine, but then what?=C2=A0 Should the client= keep
waiting for an expected reply and then possibly retransmit its message?

[LS]: If the Reply message is dropped and there is= no other authenticated=C2=A0
DHCPv6 server, then the scenario is= no authenticated DHCPv6 server. And=C2=A0
then the client's = following behavior is:
If there are no authenticated DHCPv6 serve= rs or existing servers failed=C2=A0
authentication, the client be= havior is policy specific.=C2=A0 Depending on its=C2=A0
policy, i= t can choose to repeat the server discovery process after certain=C2=A0
delay or attempt to use an unsecured DHCPv6 server.=C2=A0
=
> >- Section 5.4: in gene= ral, I think this section is still quite weak
> >=C2=A0 and/or insufficient. [...]
>
> >
> [LS]: How about the following "applicability" section:
> Secure DHCPv6 is applicable in environments where physical security > on the link is not assured and attacks on DHCPv6 are a concern, such > as enterprise networks. In enterprise networks, the DHCPv6 clients
> are manually pre-configured with the trusted servers' certificates= to
> achieve server authentication. In addition, the DHCPv6 server is
> pre-configured with the trusted clients' certificates to verify th= e client's
> identity. After the mutual authentication, the DHCPv6 message is encry= pted
>=C2=A0 with the recipient's public key, which is contained in the c= ertificate.
> The use of PKI as a possibility of making the configuration less manua= l.
> However, its feasibility is unclear right now and subject to future st= udy
> and development.
>
> And we supply the following text in section 4:
> The public-key based approach proposed in this document is slightly > securer in some cases. For example, if the client's key is quietly=
> stolen by an attacker, then the attack can pretend to be a valid clien= t
> later.

I'd first like to know whether we (the wg in general including yourself) agree on my points and understanding of previous feedback.
On top of that, I'll probably offer my own proposed text on these.

[LS]: I agree with your proposed point. Looking fo= rward to your proposed
text on this.=C2=A0

> >- Section 5.4:
> >
> >=C2=A0 =C2=A0[...]=C2=A0 In enterprise network, the security polic= y is
> >=C2=A0 =C2=A0strict and the clients are stable terminals.=C2=A0 Th= e PKI model is used
> >
> >=C2=A0 What does 'stable' mean?=C2=A0 A desktop PC would b= e considered a "stable
> >=C2=A0 terminal", but what about laptops?=C2=A0 How about sma= rt phones connected
> >=C2=A0 to the enterprise network based on the BYOD policy?

This point isn't answered.

[LS]: In the secure DHCPv6 deployment draft, we ma= inly consider two different
scenario: stable client with strict s= ecurity policy and roaming client with loose=C2=A0
security polic= y.
For the stable clients, such as the desktop PC in enterprise n= etwork, they are=C2=A0
pre-configured the trusted servers' ce= rtificates or the trusted CAs' certificates=C2=A0
for server = authentication.=C2=A0
For the roaming clients, such as the smart = phones in coffee room, it is difficult
to be pre-configured the t= rusted certificates for authentication.=C2=A0
What do you think o= f the scenario classification?

> >- Section 6
> >
> >=C2=A0 =C2=A0non-security options assigned to it.=C2=A0 The Option= Request option in
> >=C2=A0 =C2=A0the Information-request message MUST contain the opti= on code of
> >=C2=A0 =C2=A0certificate option, signature option, timestamp optio= n, and server
> >=C2=A0 =C2=A0identifier option.
> >
> >=C2=A0 Should we really need to include all of these?=C2=A0 The ce= rtificate
> >=C2=A0 option should surely be specified, but the need for the oth= ers seem
> >=C2=A0 to be almost automatically derived from the specification.<= br> > >
> [LS]: The signature option and timestamp option are used for the messa= ge
> integrity check. The Reply message is transmitted in clear text. So in=
> order to protect the Reply message integrity, I think the timestamp > and signature option MUST be contained.

We are probably talking about different things.=C2=A0 My question an= d point
are whether timestamp and signature are specified in the "option
request option".=C2=A0 Your response doesn't seem to answer that p= oint.

[LS]: The certificate option "MUST" be c= ontained, and the signature option
and timestamp option "SHO= ULD" be contained.=C2=A0
Have I got what you mean?=C2=A0

> >- Section 6
> >
> >=C2=A0 =C2=A0For the received Encrypted-Response message, the clie= nt extracts the
> >=C2=A0 =C2=A0encrypted-message option and decrypts it using its pr= ivate key to
> >=C2=A0 =C2=A0obtain the original DHCPv6 message.
> >
> >=C2=A0 What if the client has more than one key pair (see also the= higher
> >=C2=A0 level comment above)?=C2=A0 Is it assumed to associate tran= saction-id to
> >=C2=A0 a particular key?
>
> >
> [LS]: Yes. In my option, the particular key is associated with transac= tion-id.
> What is your opinion? Looking forward to further guidance.

See above.
>
>
> >- Section 6
> >
> >=C2=A0 =C2=A0o=C2=A0 Upon receiving a SignatureFail error status c= ode, the client MAY
> >=C2=A0 =C2=A0 =C2=A0 resend the message following normal retransmi= ssion routines
> >=C2=A0 =C2=A0 =C2=A0 defined in [RFC3315].
> >
> >=C2=A0 What's the rationale of this behavior?
>
> >
> [LS]: In the new version, the client will not send the signature optio= n and
> timestamp option. So we will delete these sentence.

Deleting it is probably fine, but it doesn't answer my point.=C2= =A0 We'll
still need to answer what the client should do if the server indicates
a failure in decryption (which is equivalent to SignatureFail).

[LS]: In the current version, we consider the scen= ario where the server=C2=A0
indicates a failure in authentication= . If the message fails certificate=C2=A0
validation, the DHCPv6 s= erver SHOULD reply with an AuthenticationFail=C2=A0
error status = code to the client.
So, you suggest to define a new error status = code: DecryptionFail error=C2=A0
status code. If the DHCPv6 serve= r fails decryption, the DHCPv6 server=C2=A0
SHOULD reply with an = DecryptionFail error status code to the client.
Could you please = check whether my understanding is correct?=C2=A0

> >- Section 7
> >
> >=C2=A0 =C2=A0[...]=C2=A0 Depending on server's local policy, t= he message without a
> >=C2=A0 =C2=A0Timestamp option MAY be acceptable or rejected.=C2=A0= If the server
> >=C2=A0 =C2=A0rejects such a message, a TimestampFail error status = code, defined in
> >=C2=A0 =C2=A0Section 10.3, should be sent back to the client.=C2= =A0 [...]
> >
> >=C2=A0 To be sure: is the TimestampFail supposed to be returned wh= en a
> >=C2=A0 message from the client doesn't have Timestamp but the = server wanted
> >=C2=A0 it?
> >
> [LS]: Yes. Maybe the above sentences are not clear. How about the foll= owing
> sentences:
> [...]=C2=A0 Depending on server's local policy, the message withou= t a
> Timestamp option MAY be accepted or rejected.=C2=A0 If the server
> rejects such a message without Timestamp option, then a TimestampFail<= br> > error status code, defined in Section 10.3, should be sent
> back to the client.=C2=A0 [...]

Doesn't the original text (also) cover the case where Timestamp = is
included but the check on it fails?=C2=A0 If so, the new text now loses its=
original sense.

[LS]: The original text covers the scenario where = the timestamp check=C2=A0
fails. But the lack of timestamp and ti= mestamp check failure are two=C2=A0
different scenario. So I don&= #39;t understand why the new text now loses
its original sense. L= ooking forward to the further guidance. =C2=A0

> >- Section 10.1.2
> >
> >=C2=A0 =C2=A0Note: if both signature and authentication option are= present,
> >=C2=A0 =C2=A0signature option does not protect the Authentication = Option.=C2=A0 It
> >
> >=C2=A0 Should we still worry about it?=C2=A0 The only possible rea= son for having
> >=C2=A0 both that I can see is to allow a newer client implementati= on to
> >=C2=A0 work with both new and old server implementations.=C2=A0 Bu= t now that the
> >=C2=A0 message is encrypted in a way that older implementations do= n't
> >=C2=A0 understand, it's completely impossible anymore.=C2=A0 I= think we can now
> >=C2=A0 simply say Authentication Option shouldn't be used with= Secure
> >=C2=A0 DHCPv6 (and if it's used the behavior is undefined). >
> >
> [LS]: I agree. So we replce this section with the following sentences:=
> If the Secure DHCPv6 is applied, then the Authentication Option should= n't
> be used.

It should also describe the rationale.=C2=A0 Also, we might consider= using
an RFC2119 keyword, either SHOULD NOT or MUST NOT.=C2=A0
= =C2=A0
[LS]: How about the following text=EF=BC=9B
If S= ecure DHCPv6 is used, the DHCPv6 message is encrypted in a way that=C2=A0
the authentication mechanism defined in RFC3315 don't understa= nd. So, the=C2=A0
Authentication option SHOULD NOT be used if Sec= ure DHCPv6 is applied.=C2=A0

Best Regards,
Lishan

--047d7b3a825c17ab840529d9bc42-- From nobody Mon Jan 25 11:40:45 2016 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 CD16F1A005B for ; Mon, 25 Jan 2016 11:40:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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.001, 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 bJutlrUjWYKQ for ; Mon, 25 Jan 2016 11:40:41 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9771B1A0060 for ; Mon, 25 Jan 2016 11:40:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18343; q=dns/txt; s=iport; t=1453750840; x=1454960440; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=VRfpoQyWu3KY+MYJEEGT0d/XJqyr2SMCUirE6gE6llE=; b=C9joeXxps8XKrjBObcVx41Xh3PuOHbCMKAbePzYu4ZP/xKo9tGt9w8P7 1anXz+4KOieeEtBIKeUYW24laon9enUhGw1IhSyr53KivZ4SZSlzTM94n bNIaKlov1b5h06v46HgOzoQGBITvRC3gr4ixOvJSeih3VkZpoq4Q0meBR M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAgBteaZW/4sNJK1egm5MUm0GiFGvf?= =?us-ascii?q?4ITAQ2BY4YPAoFDOBQBAQEBAQEBfwuEQQEBAQQtXAIBCBEEAQEoBzIUCQgBAQQ?= =?us-ascii?q?TCIgTvmcBAQEBAQEBAQEBAQEBAQEBAQEBAQEVix+FAYQFBYdghnqIHAGNToFlh?= =?us-ascii?q?ESIV4VuiFABHgEBQoIBGIFQaoZAfAEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,346,1449532800"; d="scan'208,217";a="231430731" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Jan 2016 19:40:39 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u0PJedst021203 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 25 Jan 2016 19:40:39 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 25 Jan 2016 13:40:38 -0600 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1104.009; Mon, 25 Jan 2016 13:40:38 -0600 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: WG Session @ IETF-95 (Buenos Aires) Agenda Requests - Deadline 2/14/2016 Thread-Index: AdFHORD4y95fMyRVQ56UWvb6lX4DVgQbpvJg Date: Mon, 25 Jan 2016 19:40:38 +0000 Message-ID: References: <005134edeb9e4550b55a23776afaef15@XCH-ALN-003.cisco.com> In-Reply-To: <005134edeb9e4550b55a23776afaef15@XCH-ALN-003.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.1.196] Content-Type: multipart/alternative; boundary="_000_acd163eee61e46d4895e2c3dcdb1d7f4XCHALN003ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [dhcwg] WG Session @ IETF-95 (Buenos Aires) Agenda Requests - Deadline 2/14/2016 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, 25 Jan 2016 19:40:44 -0000 --_000_acd163eee61e46d4895e2c3dcdb1d7f4XCHALN003ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just a reminder about requesting agenda slots! We have only one request: - DHCPv6 bis I would think we MAY want to discuss: - Secure DHCPv6 (and draft-li-dhc-secure-dhcpv6-deployment) - DHCPv6 Prefix Length Hint Issues (though perhaps we'll just want= to try to WGLC this?) - Yang model? - Failover? - Relay Initiated Release (though this would need an update based = on the IETF-94 discussions)?? - Bernie From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz) Sent: Monday, January 04, 2016 4:45 PM To: dhcwg@ietf.org Subject: [dhcwg] WG Session @ IETF-95 (Buenos Aires) Agenda Requests - Dead= line 2/14/2016 Importance: High Hi: The scheduling requests for meeting slots for IETF-95 in Buenos Aires have = opened up (we must submit a request before 2/19/2016). Our plan for IETF-95 will be the same as we did for IETF-94: - We are encouraging agenda requests NOW thru February= 14th, 2016 (this will give us a few days to organize the agenda and decide= on the session length request). - We will submit our time request for IETF-95 based on= the RECEIVED agenda requests (by the February 14th deadline). - Requests after February 14th will most likely be REJ= ECTED (once the time slot is filled). In the past we have been more accommo= dating, but because of the pressure on IETF meeting time, we are being aske= d to justify our time slot request. And meeting time should be used to disc= uss and resolve issues, not present overviews of drafts or status updates. Therefore, please submit requests as soon as you can (and well before 2/14)= if you do plan to present at the DHC WG session in Buenos Aires. As in the past, please provide: Title Of Session: Presenter: Related Drafts: Time Required: Purpose of Session: We do want to remind those requesting time that you should focus on discuss= ing key issues that need resolution to move a draft forward. We are 3 months from that next meeting. - Tomek & Bernie --_000_acd163eee61e46d4895e2c3dcdb1d7f4XCHALN003ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just a reminder about = requesting agenda slots!

 

We have only one reque= st:

-&nb= sp;         DHCPv6 bis

 

I would think we MAY w= ant to discuss:

-&nb= sp;         Secure DHCPv6 = (and draft-li-dhc-secure-dhcpv6-deployment)

-&nb= sp;         DHCPv6 Prefix = Length Hint Issues (though perhaps we’ll just want to try to WGLC thi= s?)

-&nb= sp;         Yang model?

-&nb= sp;         Failover?=

-&nb= sp;         Relay Initiate= d Release (though this would need an update based on the IETF-94 discussion= s)??

 

-&nb= sp;         Bernie

 

From: dhcwg [mailto:dhcwg-bounces@ietf.org] <= b>On Behalf Of Bernie Volz (volz)
Sent: Monday, January 04, 2016 4:45 PM
To: dhcwg@ietf.org
Subject: [dhcwg] WG Session @ IETF-95 (Buenos Aires) Agenda Requests= - Deadline 2/14/2016
Importance: High

 

Hi:

 

The scheduling requests for meeting slots for IETF-9= 5 in Buenos Aires have opened up (we must submit a request before 2/19/2016= ).

 

Our plan for IETF-95 will be the same as we did for = IETF-94:

-       = ;            &n= bsp;  We are encouraging agenda requests NOW thru Februar= y 14th, 2016 (this will give us a few days to organize the agenda and decid= e on the session length request).

-       = ;            &n= bsp;  We will submit our time request for IETF-95 based o= n the RECEIVED agenda requests (by the February 14th deadline).<= /p>

-       = ;            &n= bsp;  Requests after February 14th will most likely be RE= JECTED (once the time slot is filled). In the past we have been more accomm= odating, but because of the pressure on IETF meeting time, we are being ask= ed to justify our time slot request. And meeting time should be used to discuss and resolve issues, not present= overviews of drafts or status updates.

 

Therefore, please submit requests as soon as you can= (and well before 2/14) if you do plan to present at the DHC WG session in = Buenos Aires.

 

As in the past, please provide:

 

Title Of Session:

Presenter:

Related Drafts:

Time Required:

Purpose of Session:

 

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

 

We are 3 months from that next meeting.

 

-     &= nbsp;    Tomek & Bernie

 

--_000_acd163eee61e46d4895e2c3dcdb1d7f4XCHALN003ciscocom_-- From nobody Mon Jan 25 12:27:11 2016 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 A1F2E1A0113 for ; Mon, 25 Jan 2016 12:27:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 1WFr2pX_aG4s for ; Mon, 25 Jan 2016 12:27:09 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 980D71A0103 for ; Mon, 25 Jan 2016 12:27:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3272; q=dns/txt; s=iport; t=1453753628; x=1454963228; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=ES2zVRJamus7LIvTQlaFWs/QTbJWWaqTLlnJ4koGbfw=; b=lOkxY58xRUjOTEGncNN/9iqvUOFffpo3Y8d3rZYaOEpLC73s8cwYMvcH 2SJ4aVgjrNAnIdQKk7T6G1vBZpLj5QEaVwPIPtXCOB2Z5cQNjn4MjwJrT ELzw5aS/+kkF4xNbYanoarHXYiT2aw1T/cTfVTRxKy9QtLn9oEhOe5Y8t Q=; X-IronPort-AV: E=Sophos;i="5.22,346,1449532800"; d="scan'208";a="624778169" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jan 2016 20:27:06 +0000 Received: from dhcp-10-131-65-118.cisco.com (dhcp-10-131-65-118.cisco.com [10.131.65.118]) (authenticated bits=0) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u0PKR53Q018461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jan 2016 20:27:06 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Kim Kinnear In-Reply-To: Date: Mon, 25 Jan 2016 15:27:05 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <45451857-DAFA-46E2-B470-1CE115DDF70A@cisco.com> References: <005134edeb9e4550b55a23776afaef15@XCH-ALN-003.cisco.com> To: "Bernie Volz (volz)" X-Mailer: Apple Mail (2.3112) X-Authenticated-User: kkinnear Archived-At: Cc: "dhcwg@ietf.org" , Kim Kinnear Subject: Re: [dhcwg] WG Session @ IETF-95 (Buenos Aires) Agenda Requests - Deadline 2/14/2016 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, 25 Jan 2016 20:27:10 -0000 Regarding DHCPv6 failover.... We have had two excellent reviews, and I folded the considerable = comments into a new draft right before the holidays in December: https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-failover-protocol-01 = At this point, we could use another good technical review (or two). If we don't have any before IETF-95, it would make sense to talk about how to get some. If we do have some, it would make sense to talk about either: o Issues raised by the review(s) o Next steps or both. So, it would make sense to put DHCP Failover on the agenda, as there = will be *something* worth talking about. Regards -- Kim > On Jan 25, 2016, at 2:40 PM, Bernie Volz (volz) = wrote: >=20 > Just a reminder about requesting agenda slots! > =20 > We have only one request: > - DHCPv6 bis > =20 > I would think we MAY want to discuss: > - Secure DHCPv6 (and draft-li-dhc-secure-dhcpv6-deployment) > - DHCPv6 Prefix Length Hint Issues (though perhaps we=E2=80=99l= l just want to try to WGLC this?) > - Yang model? > - Failover? > - Relay Initiated Release (though this would need an update = based on the IETF-94 discussions)?? > =20 > - Bernie > =20 > From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz = (volz) > Sent: Monday, January 04, 2016 4:45 PM > To: dhcwg@ietf.org > Subject: [dhcwg] WG Session @ IETF-95 (Buenos Aires) Agenda Requests - = Deadline 2/14/2016 > Importance: High > =20 > Hi: > =20 > The scheduling requests for meeting slots for IETF-95 in Buenos Aires = have opened up (we must submit a request before 2/19/2016). > =20 > Our plan for IETF-95 will be the same as we did for IETF-94: > - We are encouraging agenda requests NOW thru = February 14th, 2016 (this will give us a few days to organize the agenda = and decide on the session length request). > - We will submit our time request for IETF-95 = based on the RECEIVED agenda requests (by the February 14th deadline). > - Requests after February 14th will most likely = be REJECTED (once the time slot is filled). In the past we have been = more accommodating, but because of the pressure on IETF meeting time, we = are being asked to justify our time slot request. And meeting time = should be used to discuss and resolve issues, not present overviews of = drafts or status updates. > =20 > Therefore, please submit requests as soon as you can (and well before = 2/14) if you do plan to present at the DHC WG session in Buenos Aires. > =20 > As in the past, please provide: > =20 > Title Of Session: > Presenter: > Related Drafts: > Time Required: > Purpose of Session: > =20 > We do want to remind those requesting time that you should focus on = discussing key issues that need resolution to move a draft forward. > =20 > We are 3 months from that next meeting. > =20 > - Tomek & Bernie > =20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From nobody Tue Jan 26 03:12:32 2016 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 C17281AD06F for ; Tue, 26 Jan 2016 03:12:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, 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 J5bS9ND2QIQf for ; Tue, 26 Jan 2016 03:12:29 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C79B71AD06B for ; Tue, 26 Jan 2016 03:12:28 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id u188so101515923wmu.1 for ; Tue, 26 Jan 2016 03:12:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=UepwSqlQMZoNW0dLa3ZcrE7EyaRdojBNtKsCJp7Qayw=; b=BBNF93BcKfOoAJRi4yJcM0G7w18+m87oCEqSDMYZoznCz2WEGgKNkc2Nd60Oy4F/NV +Qke87kNR50LNY1E19TjRYGDUhc8oGQqhnbwF7dgYKnUQl/lRG/U3cCAK6hfZvA3FYvC LXU9F7LOCVSoR1PmBSkLLrnkfRa2Y/H8AIGLjbylS3VbBzoVD1XnPcSUVRAwSfdVrHdF oKvAn/WSUVtzfphR3Y0u0sJat2TfLAgc/1AELvIBOaFE4ftiJSRBwm9dbeHOQXA7TZkT OCT9QOkeD1NhqwhfELhIj1iinAFsxvGxsnho7RHkEC1CLo9yBn124DcP51DGGdyBrcZw KJaw== 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:from:date :message-id:subject:to:cc:content-type; bh=UepwSqlQMZoNW0dLa3ZcrE7EyaRdojBNtKsCJp7Qayw=; b=YJaKzTbq/iv/VGx0Uee+NzlP5MNlQEiJwLskhnai8DhsVl7Dq1kzj4dyg8z6U9vGfP qtbWtPkVGbwdP9fTvusbPSIvZFgDc3Y4/dnqKwtRrwSQ2zaxTsJzNb27ROqCqAN8qPDK BnoBuxUjWTtHp+UZm5fR15NrPz5zPQM9HoMYorLM9uuWhjoJc4bbszflDrmkrmrf++0s fPfNCyA/JllQtyHtRCu9KiH4I9T4WNBcowMVYTNehv+80NbGNTRXMw2KUmbE8XOrYNvW wvEEDLgmnjSCOW0SEHIo2tUtxTh8Dzv74D0i6mxLZR7CxfJjmjFw2JYmams9QNp8q5py 2mcg== X-Gm-Message-State: AG10YOSxwRIlWZrS9cGNepWcfPuXa6UIH3/DSWNJVLKaWBJKDXfJRfqQtYmUL3Z5S+dLq6y1Dcpga3uepZVDEw== X-Received: by 10.194.114.106 with SMTP id jf10mr26945462wjb.149.1453806747312; Tue, 26 Jan 2016 03:12:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.45.23 with HTTP; Tue, 26 Jan 2016 03:12:07 -0800 (PST) In-Reply-To: References: <20151019214426.26682.1478.idtracker@ietfa.amsl.com> From: Linhui Sun Date: Tue, 26 Jan 2016 19:12:07 +0800 Message-ID: To: Luyuan Fang Content-Type: multipart/alternative; boundary=001a1130cf2ebee6b4052a3ac282 Archived-At: Cc: dhcwg , "Deepak Bansal \(AZURE\)" , Fabio Chiussi Subject: Re: [dhcwg] FW: New Version Notification for draft-fang-dhc-dhcpv4-forcerenew-extensions-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: Tue, 26 Jan 2016 11:12:31 -0000 --001a1130cf2ebee6b4052a3ac282 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I've read this document and think it is a useful solution to a specific problem. I also have some confusing questions, please see the details below= . 1. In the Introduction, there is a statement about the DHCP4o6, "It should be noted that [RFC7341] specifies DHCPv4 over DHCPv6, thus making it possible to use the DHCPv6 reconfigure function to reconfigure parameters in DHCPv4. However, [RFC7341] is only applicable to a IPv6 core network." IMHO, DHCP4o6 transport only makes the DHCPv4 messages could be transmitted in IPv6 environment, I don't understand how to use DHCPv6 reconfigure function to reconfigure a DHCPv4 client. 2. In Section 2.3, "One obvious solution is to forego backward compatibility and have the DHCP server simply abandon the reconfiguration procedure at the end of the DHCPINFOFORCERENEW reconfiguration procedure." I don't know why we need to abandon the backward compatibility. If the client wishes to decline the DHCPFORCEINFORENEW, it makes no difference whether the FORCERENEW is for IP address or for configuration information other than IP address. In another word, if the DHCPINFOFORCERENEW are reverted to DHCPFORCERENEW, the client can still decline the request using the corresponding mechanism designed for DHCPFORCERENEW. Regards, Linhui 2015-10-20 10:02 GMT+08:00 Luyuan Fang : > Hi all, > > We submitted a new version of draft-fang-dhc-dhcpv4-forcerenew-extensions= . > We updated the draft based on Bernie and Christian's very helpful feedbac= k > on 00 version, thanks a lot, Bernie and Christian. > > The intent of the draft is to extend the definition of the DHCPFORCERENEW > message for parameter reconfiguration in DHCPv4. This extension makes the > DHCPFORCERENEW message more suitable to reconfigure configuration > parameters other than IP addresses, and aligns the behavior of the > reconfiguration procedure in DHCPv4 to the corresponding behavior in DHCP= v6. > > We understand the DHC WG focus is on v6, and we are implementing DHCPv6 i= n > our cloud solutions as well. It is a good thing to do. > > In the meantime, we still have full of DHCPv4 in our cloud networks, > cannot go away anytime soon. Our proposal is not calling for a big change= , > but it makes a lot of difference for the customers if we could avoid > service interruption when only updating info without lease renew. So the > proposed change is very important for us in providing reliable Cloud > Services to customers. > > We would very much appreciate your comments. > > Thanks , > Luyuan > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, October 19, 2015 2:44 PM > To: Luyuan Fang ; Fabio Chiussi < > fabiochiussi@gmail.com>; Deepak Bansal (AZURE) > Subject: New Version Notification for > draft-fang-dhc-dhcpv4-forcerenew-extensions-01.txt > > > A new version of I-D, draft-fang-dhc-dhcpv4-forcerenew-extensions-01.txt > has been successfully submitted by Luyuan Fang and posted to the IETF > repository. > > Name: draft-fang-dhc-dhcpv4-forcerenew-extensions > Revision: 01 > Title: Forcerenew Reconfiguration Extensions for DHCPv4 > Document date: 2015-10-19 > Group: Individual Submission > Pages: 7 > URL: > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ie= tf.org%2finternet-drafts%2fdraft-fang-dhc-dhcpv4-forcerenew-extensions-01.t= xt&data=3D01%7c01%7clufang%40microsoft.com%7cf1f62db75ecb45fd763708d2d8ce76= c9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DXWQywRXXFlDEekzeP4L7L39A3= WsU0LQvm23Akt49Go4%3d > Status: > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fdatatr= acker.ietf.org%2fdoc%2fdraft-fang-dhc-dhcpv4-forcerenew-extensions%2f&data= =3D01%7c01%7clufang%40microsoft.com%7cf1f62db75ecb45fd763708d2d8ce76c9%7c72= f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DCVC2iRhJ0JlpX%2fsYLvO75c736QChR2= gNjUUXtv4wjsM%3d > Htmlized: > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2ftools.= ietf.org%2fhtml%2fdraft-fang-dhc-dhcpv4-forcerenew-extensions-01&data=3D01%= 7c01%7clufang%40microsoft.com%7cf1f62db75ecb45fd763708d2d8ce76c9%7c72f988bf= 86f141af91ab2d7cd011db47%7c1&sdata=3D7%2fyJBegjdkEyvzEpSxLR1krKwyr4EeVTBg1w= DKsZP9w%3d > Diff: > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ie= tf.org%2frfcdiff%3furl2%3ddraft-fang-dhc-dhcpv4-forcerenew-extensions-01&da= ta=3D01%7c01%7clufang%40microsoft.com%7cf1f62db75ecb45fd763708d2d8ce76c9%7c= 72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DlRgpr96THN9DT3%2bTJTBRBq9tdRKc= 8rWTDoUjnYcfwSs%3d > > Abstract: > This document extends the definition of the DHCPFORCERENEW message > for parameter reconfiguration in DHCPv4. This extension makes the > DHCPFORCERENEW message more suitable to reconfigure configuration > parameters other than IP addresses, and aligns the behavior of the > reconfiguration procedure in DHCPv4 to the corresponding behavior in > DHCPv6. > > > > > 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 > --001a1130cf2ebee6b4052a3ac282 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I've read this document and thi= nk it is a useful solution to a specific problem. I also have some confusin= g questions, please see the details below.

1. In t= he Introduction, there is a statement about the DHCP4o6,
=C2= =A0 =C2=A0"It should be noted that [RFC7341] specifies DHCPv4 over DHC= Pv6, thus
=C2=A0 =C2=A0making it possible to use the DHCPv6 recon= figure function to
=C2=A0 =C2=A0reconfigure parameters in DHCPv4.= However, [RFC7341] is only
=C2=A0 =C2=A0applicable to a IPv6 cor= e network."
IMHO, DHCP4o6 transport only makes the DHC= Pv4 messages could be transmitted in IPv6 environment, I don't understa= nd how to use DHCPv6 reconfigure function to reconfigure a DHCPv4 client.

2. In Section 2.3,=C2=A0
=C2=A0 =C2= =A0"One obvious solution is to forego backward compatibility and have = the
=C2=A0 =C2=A0DHCP server simply abandon the reconfiguration p= rocedure at the end
=C2=A0 =C2=A0of the DHCPINFOFORCERENEW reconf= iguration procedure."
I don't know why we need to abando= n the backward compatibility. If the client wishes to decline the DHCPFORCE= INFORENEW, it makes no difference whether the FORCERENEW is for IP address = or for configuration information other than IP address. In another word, if= the DHCPINFOFORCERENEW are reverted to DHCPFORCERENEW, the client can stil= l decline the request using the corresponding mechanism designed for DHCPFO= RCERENEW.

Regards,
Linhui


2015-10-20 10:02 GMT+08:00 Luyuan Fang <lufang@microsoft.com>:
Hi all,

We submitted a new version of draft-fang-dhc-dhcpv4-forcerenew-extensions.<= br> We updated the draft based on Bernie and Christian's very helpful feedb= ack on 00 version, thanks a lot, Bernie and Christian.

The intent of the draft is to extend the definition of the DHCPFORCERENEW m= essage for parameter reconfiguration in DHCPv4. This extension makes the DH= CPFORCERENEW message more suitable to reconfigure configuration parameters = other than IP addresses, and aligns the behavior of the reconfiguration pro= cedure in DHCPv4 to the corresponding behavior in DHCPv6.

We understand the DHC WG focus is on v6, and we are implementing DHCPv6 in = our cloud solutions as well. It is a good thing to do.

In the meantime, we still have full of DHCPv4 in our cloud networks, cannot= go away anytime soon. Our proposal is not calling for a big change, but it= makes a lot of difference for the customers if we could avoid service inte= rruption when only updating info without lease renew. So the proposed chang= e is very important for us in providing reliable Cloud Services to customer= s.

We would very much appreciate your comments.

Thanks ,
Luyuan

-----Original Message-----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Monday, October 19, 2015 2:44 PM
To: Luyuan Fang <lufang@microsof= t.com>; Fabio Chiussi <= fabiochiussi@gmail.com>; Deepak Bansal (AZURE) <dbansal@microsoft.com>
Subject: New Version Notification for draft-fang-dhc-dhcpv4-forcerenew-exte= nsions-01.txt


A new version of I-D, draft-fang-dhc-dhcpv4-forcerenew-extensions-01.txt has been successfully submitted by Luyuan Fang and posted to the IETF repos= itory.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-fang-dhc-dhcpv4-forcere= new-extensions
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Forcerenew Reconfiguration Extensi= ons for DHCPv4
Document date:=C2=A0 2015-10-19
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://na01.safelinks.prot= ection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf.org%2finternet-drafts%2fdr= aft-fang-dhc-dhcpv4-forcerenew-extensions-01.txt&data=3D01%7c01%7clufan= g%40microsoft.com%7cf1f62db75ecb45fd763708d2d8ce76c9%7c72f988bf86f141af91ab= 2d7cd011db47%7c1&sdata=3DXWQywRXXFlDEekzeP4L7L39A3WsU0LQvm23Akt49Go4%3d=
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://na01.safelinks.protection.outl= ook.com/?url=3Dhttps%3a%2f%2fdatatracker.ietf.org%2fdoc%2fdraft-fang-dhc-dh= cpv4-forcerenew-extensions%2f&data=3D01%7c01%7clufang%40microsoft.com%7= cf1f62db75ecb45fd763708d2d8ce76c9%7c72f988bf86f141af91ab2d7cd011db47%7c1&am= p;sdata=3DCVC2iRhJ0JlpX%2fsYLvO75c736QChR2gNjUUXtv4wjsM%3d
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://na01.safelinks.protection.outlook.com/?u= rl=3Dhttps%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-fang-dhc-dhcpv4-forcerenew= -extensions-01&data=3D01%7c01%7clufang%40microsoft.com%7cf1f62db75ecb45= fd763708d2d8ce76c9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3D7%2fy= JBegjdkEyvzEpSxLR1krKwyr4EeVTBg1wDKsZP9w%3d
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://na01.safelinks.protect= ion.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf.org%2frfcdiff%3furl2%3ddraft-= fang-dhc-dhcpv4-forcerenew-extensions-01&data=3D01%7c01%7clufang%40micr= osoft.com%7cf1f62db75ecb45fd763708d2d8ce76c9%7c72f988bf86f141af91ab2d7cd011= db47%7c1&sdata=3DlRgpr96THN9DT3%2bTJTBRBq9tdRKc8rWTDoUjnYcfwSs%3d
Abstract:
=C2=A0 =C2=A0This document extends the definition of the DHCPFORCERENEW mes= sage
=C2=A0 =C2=A0for parameter reconfiguration in DHCPv4. This extension makes = the
=C2=A0 =C2=A0DHCPFORCERENEW message more suitable to reconfigure configurat= ion
=C2=A0 =C2=A0parameters other than IP addresses, and aligns the behavior of= the
=C2=A0 =C2=A0reconfiguration procedure in DHCPv4 to the corresponding behav= ior in
=C2=A0 =C2=A0DHCPv6.




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

The IETF Secretariat

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

--001a1130cf2ebee6b4052a3ac282-- From nobody Fri Jan 29 11:30:58 2016 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 0EA961B3240; Fri, 29 Jan 2016 11:30:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.577 X-Spam-Level: * X-Spam-Status: No, score=1.577 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, FRT_BIGGERMEM1=2.555, 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 1fdbOVYJaAIE; Fri, 29 Jan 2016 11:30:53 -0800 (PST) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34C851B3241; Fri, 29 Jan 2016 11:30:53 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id d63so82543010ioj.2; Fri, 29 Jan 2016 11:30:53 -0800 (PST) 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=H52QdEoDSqs9k3XNuKN5EhoWSnF8eXMYLQFHSIehTDc=; b=WeA9FQPNs00IVH89KJfFNTFnmpllB1Boh0d58Q9Ary1qNAvNq9j2dtHvlK35Zq1TIs huSPGOTA9wUqhGHteBfACYVdk6srlwMD/gj4Y8QfAP5MQaaiJ33iGucVAikjMTnqtrxc 1FHJGcbeUtM5M9FQgVlwQNiF8TJY+w8aPy9DBilGfDYby8MM46qRnLiwTtuh9WF0a0FB 8QTZi7GO12+s4ZE2onHSL1zYZvbfhXrF/ubhGDbqBSILFZY5SB++hj1Nw7hvCRsxXRk/ uOEUx4QMqj/vhummjbtE5GAbT26BzTiLfMKtvs8NCmZdHdXrV4lG6icTK3EO+ifeoo5p WtHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=H52QdEoDSqs9k3XNuKN5EhoWSnF8eXMYLQFHSIehTDc=; b=QAqY4kv+7Uvvj8QmmOHk3GVultte7PpgaC3qpnuQxNVcWw5eOolgt41rdX9+wwNh/6 BohR7W+OGn2P2d4UXKgdSno3FHEExc0Ca1VwNy10Seiak6/uCAGsBP28mSOrELBxbOR8 294CVwJwY06IbV5Zb71EI/XBWq8AUjv0F7JY69gmRKU+EWKIwL7UME7MMVJ3RARkd9pJ V1AH6F1QXSO2isIYLGdxXzlP0VvmFqdsYhWL5lHdLf5AhuS7ayGN/DO2l0bjWrbZJT+p DtZ5fmsLT00tbCkgrEWZ8a/S8vGtO7rkW3j0TQuEq2K8k3fut2+b7cv6Gu5+y8bt1jxw I30A== X-Gm-Message-State: AG10YOQnCr4QlhtuFyhMkUPhtXmL3F1OMvEBO2ZIAuz1QaY/mpljk9dvdOug4QMmAbdNVs5DN3rTjfod6le53w== MIME-Version: 1.0 X-Received: by 10.107.137.142 with SMTP id t14mr11148495ioi.172.1454095852551; Fri, 29 Jan 2016 11:30:52 -0800 (PST) Sender: jinmei.tatuya@gmail.com Received: by 10.107.136.90 with HTTP; Fri, 29 Jan 2016 11:30:52 -0800 (PST) In-Reply-To: References: Date: Fri, 29 Jan 2016 11:30:52 -0800 X-Google-Sender-Auth: 9ZS7zDZIY5qRGPaw8km2L7vXISg Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Lishan Li Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "dhcwg@ietf.org" , draft-ietf-dhc-sedhcpv6@ietf.org Subject: Re: [dhcwg] comments on draft-ietf-dhc-sedhcpv6-10.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: Fri, 29 Jan 2016 19:30:56 -0000 At Thu, 21 Jan 2016 23:27:03 +0800, Lishan Li wrote: > > Maybe my points weren't clear enough. First off, I didn't talk about > > timestamp at all; let's focus on the signature option. Secondly, I > > don't see why encryption is not enough in the server-to-client case > > for message integrity. > > > [LS]:In the server-to-client case, the Reply message is transmitted in > cleartext not encryption, which contains the server's certificate > information. > So I think that it is better to contain the signature option for the Repl= y > message integrity check. > Looking forward to your further guidance. I'm still not sure if my point was made clear...so let me be more specific: in the following message exchanges: 1. Information-request from client to server(s) 2. Reply to the Information-request from server(s) to client 3. Encryption-Query from client to server 4. Encryption-Response from server to client did you mean the Reply message of exchange #2? If so, do you at least agree that it makes almost no sense to include the explicit separate signature in messages 3 and 4? > > > [LS]: In the current version, TOFU is out of scope. The client and se= rver > > > use certificates for authentication, not public key. So I think the > > certificate > > > option is enough. The public key option is removed. > > > > I don't understand that. We should still be able to manually > > configure public keys on clients and servers (see also the > > applicability discussion), so simply because we removed the TOFU mode > > shouldn't me we should remove the public key option. > > > > [LS]: If the device is pre-configured with public key not certificate, = it > can > generate the self-signed certificate for authentication. Right, but this argument also holds even if we have TOFU... > So, I think that > the certificate option is enough for authentication. > Looking forward to your further guidance. ...so these don't explain why we should now remove the public key option. One obvious, though possibly relatively minor, drawback of only having a certificate is that it will make the message size even bigger when we actually only need the public key. I'm not necessarily opposed to removing the public key option if we cover all such discussions and reach consensus, but I don't think I've seen it yet. > > >Some specific comments on the draft text follow: > > > > > > > >- Section 4 > > > > > > > > authentication method. However, this method provides little mess= age > > > > integrity or source integrity check, and it protects only the > > > > Reconfigure message. This key is transmitted in plaintext. [...] > > This one still has the same problem. Why does this method > > (=3DReconfigure Key Authentication Protocol) provide little message > > integrity or source integrity? > > > > [LS]: The authentication mechanism defined in RFC3315 can provide for t= he > authentication of the client and server, and for the integrity of message= s > delivered between DHCPv6 clients and servers. > So, how about the following text: > [...] However, this method protects only the Reconfigure message. In > addition, > the key is transmitted in plaintext to the client in earlier exchanges. > [...] I'm not sure if my point was really taken, but I'm okay with removing the text in question anyway. I'd add "...and so this method is vulnerable to active attacks" to the second sentence. > > >- Section 5.4: in general, I think this section is still quite weak > > > > and/or insufficient. [...] [...] > > I'd first like to know whether we (the wg in general including > > yourself) agree on my points and understanding of previous feedback. > > On top of that, I'll probably offer my own proposed text on these. > > > > [LS]: I agree with your proposed point. Looking forward to your propose= d > text on this. Okay, will do separately. > > >- Section 5.4: > > > > > > > > [...] In enterprise network, the security policy is > > > > strict and the clients are stable terminals. The PKI model is us= ed > > > > > > > > What does 'stable' mean? A desktop PC would be considered a "stab= le > > > > terminal", but what about laptops? How about smart phones connect= ed > > > > to the enterprise network based on the BYOD policy? > > > > This point isn't answered. > > > > [LS]: In the secure DHCPv6 deployment draft, we mainly consider two > different > scenario: stable client with strict security policy and roaming client wi= th > loose > security policy. > For the stable clients, such as the desktop PC in enterprise network, the= y > are > pre-configured the trusted servers' certificates or the trusted CAs' > certificates > for server authentication. > For the roaming clients, such as the smart phones in coffee room, it is > difficult > to be pre-configured the trusted certificates for authentication. > What do you think of the scenario classification? I basically just asked the definition of "stable". From the above text it seems to mean DHCP clients like desktop PCs, excluding laptops and smart phones with a BYOD policy. If so, I'd say "In enterprise network, the security policy is strict and the clients are stable terminals" is not a realistic statement. > > >- Section 6 > > > > > > > > non-security options assigned to it. The Option Request option i= n > > > > the Information-request message MUST contain the option code of > > > > certificate option, signature option, timestamp option, and serve= r > > > > identifier option. > > > > > > > > Should we really need to include all of these? The certificate > > > > option should surely be specified, but the need for the others see= m > > > > to be almost automatically derived from the specification. > > > > > > > [LS]: The signature option and timestamp option are used for the mess= age > > > integrity check. The Reply message is transmitted in clear text. So i= n > > > order to protect the Reply message integrity, I think the timestamp > > > and signature option MUST be contained. > > > > We are probably talking about different things. My question and point > > are whether timestamp and signature are specified in the "option > > request option". Your response doesn't seem to answer that point. > > > > [LS]: The certificate option "MUST" be contained, and the signature opt= ion > and timestamp option "SHOULD" be contained. > Have I got what you mean? I'm afraid not. I talked about option request options, but your answer seems to talk about something else. Let's be very specific: according to the original draft text, the initial Information-request message MUST contain an option request option whose codes fields include: 1. code of certificate option 2. code of signature option 3. code of timestamp option What I tried to say is that 2 and 3 are redundant, since requesting a certificate option should imply a request of signature and timestamp option (in this context I'm forgetting the other discussion of whether we really need the signature option). > > > >- Section 6 > > > > > > > > o Upon receiving a SignatureFail error status code, the client M= AY > > > > resend the message following normal retransmission routines > > > > defined in [RFC3315]. > > > > > > > > What's the rationale of this behavior? > > > > > > > > > > [LS]: In the new version, the client will not send the signature opti= on > > and > > > timestamp option. So we will delete these sentence. > > > > Deleting it is probably fine, but it doesn't answer my point. We'll > > still need to answer what the client should do if the server indicates > > a failure in decryption (which is equivalent to SignatureFail). > > > > [LS]: In the current version, we consider the scenario where the server > indicates a failure in authentication. If the message fails certificate > validation, the DHCPv6 server SHOULD reply with an AuthenticationFail > error status code to the client. > So, you suggest to define a new error status code: DecryptionFail error > status code. If the DHCPv6 server fails decryption, the DHCPv6 server > SHOULD reply with an DecryptionFail error status code to the client. > Could you please check whether my understanding is correct? Introducing a new error code is related but a minor point. My question was about what the client should do if it sees that code (or whatever signal that indicates this kind of failure). > > > >- Section 7 > > > > > > > > [...] Depending on server's local policy, the message without a > > > > Timestamp option MAY be acceptable or rejected. If the server > > > > rejects such a message, a TimestampFail error status code, define= d in > > > > Section 10.3, should be sent back to the client. [...] > > > > > > > > To be sure: is the TimestampFail supposed to be returned when a > > > > message from the client doesn't have Timestamp but the server want= ed > > > > it? > > > > > > > [LS]: Yes. Maybe the above sentences are not clear. How about the > > following > > > sentences: > > > [...] Depending on server's local policy, the message without a > > > Timestamp option MAY be accepted or rejected. If the server > > > rejects such a message without Timestamp option, then a TimestampFail > > > error status code, defined in Section 10.3, should be sent > > > back to the client. [...] > > > > Doesn't the original text (also) cover the case where Timestamp is > > included but the check on it fails? If so, the new text now loses its > > original sense. > > > > [LS]: The original text covers the scenario where the timestamp check > fails. But the lack of timestamp and timestamp check failure are two > different scenario. So I don't understand why the new text now loses > its original sense. Looking forward to the further guidance. Let me rephrase my question: consider the following two cases: 1. the client includes the timestamp option but server fails to validate it 2. the client doesn't include the timestamp option but server wanted to have it my original question was whether TimestampFail is included in the response from the server for both cases. I assumed the answer was yes. Am I correct? If I am, your latest text seemed to lose the coverage for case 1 since it only talks about case 2: "If the server rejects such a message without Timestamp option". Is it clearer? > > >- Section 10.1.2 > > > > > > > > Note: if both signature and authentication option are present, > > > > signature option does not protect the Authentication Option. It > > > > > > > > Should we still worry about it? The only possible reason for havi= ng > > > > both that I can see is to allow a newer client implementation to > > > > work with both new and old server implementations. But now that t= he > > > > message is encrypted in a way that older implementations don't > > > > understand, it's completely impossible anymore. I think we can no= w > > > > simply say Authentication Option shouldn't be used with Secure > > > > DHCPv6 (and if it's used the behavior is undefined). > > > > > > > > > > [LS]: I agree. So we replce this section with the following sentences= : > > > If the Secure DHCPv6 is applied, then the Authentication Option shoul= dn't > > > be used. > > > > It should also describe the rationale. Also, we might consider using > > an RFC2119 keyword, either SHOULD NOT or MUST NOT. > > [LS]: How about the following text=EF=BC=9B > If Secure DHCPv6 is used, the DHCPv6 message is encrypted in a way that > the authentication mechanism defined in RFC3315 don't understand. So, the > Authentication option SHOULD NOT be used if Secure DHCPv6 is applied. I'd probably want to suggest something slightly different, but I'd like to first discuss whether we really need a signature option. Depending on the result of it this point may become even more moot. Note also that if we at least don't include the signature option in encrypted message, the coexistence issue doesn't exist in this case in the first place. p.s. there's another bigger open issue I separated from the rest of the discussions: https://mailarchive.ietf.org/arch/msg/dhcwg/-tZBpeMs-EiVyMm0MLBpj3dFYNI -- JINMEI, Tatuya From nobody Fri Jan 29 14:00:04 2016 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 18B991A896C; Fri, 29 Jan 2016 14:00:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160129220001.24650.89875.idtracker@ietfa.amsl.com> Date: Fri, 29 Jan 2016 14:00:01 -0800 Archived-At: Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-anonymity-profile-06.txt 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, 29 Jan 2016 22:00:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Anonymity profile for DHCP clients Authors : Christian Huitema Tomek Mrugalski Suresh Krishnan Filename : draft-ietf-dhc-anonymity-profile-06.txt Pages : 26 Date : 2016-01-29 Abstract: Some DHCP options carry unique identifiers. These identifiers can enable device tracking even if the device administrator takes care of randomizing other potential identifications like link-layer addresses or IPv6 addresses. The anonymity profile is designed for clients that wish to remain anonymous to the visited network. The profile provides guidelines on the composition of DHCP or DHCPv6 requests, designed to minimize disclosure of identifying information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-anonymity-profile/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dhc-anonymity-profile-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-anonymity-profile-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Jan 30 19:35:24 2016 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B48FF1B3EF0; Sat, 30 Jan 2016 19:35:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160131033522.23586.78525.idtracker@ietfa.amsl.com> Date: Sat, 30 Jan 2016 19:35:22 -0800 Archived-At: Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-access-network-identifier-12.txt 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: Sun, 31 Jan 2016 03:35:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Access Network Identifier Option in DHCP Authors : Shwetha Bhandari Sri Gundavelli Mark Grayson Bernie Volz Jouni Korhonen Filename : draft-ietf-dhc-access-network-identifier-12.txt Pages : 20 Date : 2016-01-30 Abstract: This document specifies the format and mechanism that is to be used for encoding access network identifiers in DHCPv4 and DHCPv6 messages by defining new access network identifier options and sub-options. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-access-network-identifier/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dhc-access-network-identifier-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-access-network-identifier-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/