From nobody Tue Jul 1 07:12:14 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 507981A050E; Tue, 1 Jul 2014 07:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctBgUMlQaGII; Tue, 1 Jul 2014 07:12:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D4F441A0339; Tue, 1 Jul 2014 07:12:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140701141208.25003.58467.idtracker@ietfa.amsl.com> Date: Tue, 01 Jul 2014 07:12:08 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/VE0roTJ35EIFfjcEMY2MmyGvbJ8 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-v4configuration-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: Tue, 01 Jul 2014 14:12:10 -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 : Provisioning IPv4 Configuration Over IPv6 Only Networks Authors : Branimir Rajtar Ian Farrer Filename : draft-ietf-dhc-v4configuration-06.txt Pages : 17 Date : 2014-07-01 Abstract: As IPv6 becomes more widely adopted, some service providers are choosing to deploy IPv6 only networks without dual-stack functionality for IPv4. However, as access to IPv4 based services will continue to be a requirement for the foreseeable future, IPv4 over IPv6 mechanisms, such as softwire tunnels are being developed. In order to provision end-user's hosts with the IPv4 configuration necessary for such mechanisms, a number of different approaches have been proposed. This memo discusses each of the proposals, identifies the benefits and drawbacks and recommends approaches to be used as the basis for future deployment and development. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-v4configuration/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-v4configuration-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-v4configuration-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 Tue Jul 1 08:31:10 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 862B01B2806 for ; Tue, 1 Jul 2014 08:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 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.651, 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 1gGIV2Ny95-P for ; Tue, 1 Jul 2014 08:31:07 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7886B1B2817 for ; Tue, 1 Jul 2014 08:31:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13093; q=dns/txt; s=iport; t=1404228666; x=1405438266; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=PpcatykDP/jauxOyjoI8ICXt6RU9d2306epXYtMl2AI=; b=fsAFmHmWTul0uMIShQtekfSn5sHAXo/mXuEXV9o/PryQLfF8L4V4o9sR BFnajqUGyswJJIzbmXnsWvfx53Shn+DbcgV8mvh85vxu2vvaqtlscgiTC Mjd18ft6x5++R2FOP7u6BJbAaOckQYr7LIcsfH2fTGKzBvTcsG4wem0Lo Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnYFAI7TslOtJV2b/2dsb2JhbABagkZHUlqrMQEBAQEHmkUBgQ0WdYQDAQEBBC1cAgEIEQQBAQsdBzIUCQgCBBMIAYg5DchqF4VvhgyCczcBgy2BFgWuaINCbIFE X-IronPort-AV: E=Sophos; i="5.01,582,1400025600"; d="scan'208,217"; a="57467918" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-3.cisco.com with ESMTP; 01 Jul 2014 15:31:05 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s61FV5WH022939 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 1 Jul 2014 15:31:05 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.176]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Tue, 1 Jul 2014 10:31:05 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: [dhcwg] Reminder - Need Agenda Items for Toronto (IETF-90, July 20-25) Thread-Index: AQHPlUF5qu1mQ9oGlUaRaZZKZSVQgA== Date: Tue, 1 Jul 2014 15:31:05 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1B5E230E@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E1B5C38A3@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1B5D3ADA@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1B5D3ADA@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.70.117] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1B5E230Exmbrcdx04ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/PVfsLYNte5pELhwLnnB_OM3tbXQ Subject: Re: [dhcwg] Reminder - Need Agenda Items for Toronto (IETF-90, July 20-25) 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, 01 Jul 2014 15:31:08 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E1B5E230Exmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just another reminder for agenda items. Current draft agenda is at http://www.ietf.org/proceedings/90/agenda/agenda= -90-dhc. - Bernie From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz) Sent: Monday, June 16, 2014 8:40 AM To: dhcwg@ietf.org Subject: [dhcwg] Reminder - Need Agenda Items for Toronto (IETF-90, July 20= -25) Hi: Please send us (dhc-chairs@tools.ietf.org= ) requests for sessions for the DHC WG meeting in Toronto. Include: Name of session: Name of draft(s): Time requested: Presenter name(s): Brief description of what issues need discussing and what you hope to accom= plish by presenting: More details about the Toronto IETF can be found at http://www.ietf.org/mee= ting/90/index.html. - Tomek & Bernie --_000_489D13FBFA9B3E41812EA89F188F018E1B5E230Exmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just another reminder = for agenda items.

 

Current draft agenda i= s at http://www.ietf.org/proceedings/90/agenda/agenda-90-dhc.

 

-&nb= sp;         Bernie

 

From: dhcwg [m= ailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz)
Sent: Monday, June 16, 2014 8:40 AM
To: dhcwg@ietf.org
Subject: [dhcwg] Reminder - Need Agenda Items for Toronto (IETF-90, = July 20-25)

 

Hi:

 =

Please send us (dhc-chair= s@tools.ietf.org) requests for sessions for the DHC WG meeting i= n Toronto. Include:

 =

Name of session:

Name of draft(s):

Time requested:

Presenter name(s):<= /o:p>

Brief description of wha= t issues need discussing and what you hope to accomplish by presenting:

 =

More details about the T= oronto IETF can be found at http://www.ietf.org/meeting/90/index.html.

 =

- = ;         Tomek & Bern= ie

--_000_489D13FBFA9B3E41812EA89F188F018E1B5E230Exmbrcdx04ciscoc_-- From nobody Wed Jul 2 06:17:47 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15F4D1A00B6; Wed, 2 Jul 2014 06:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79Uf04awJKhV; Wed, 2 Jul 2014 06:17:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2C31A0080; Wed, 2 Jul 2014 06:17:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140702131743.12536.63909.idtracker@ietfa.amsl.com> Date: Wed, 02 Jul 2014 06:17:43 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/RQ-nyeGlnDSnq1Sjc_a3FeFMIuc Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dynamic-shared-v4allocation-01.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, 02 Jul 2014 13:17: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 : Dynamic Allocation of Shared IPv4 Addresses Authors : Yong Cui Qiong Sun Ian Farrer Yiu L. Lee Qi Sun Mohamed Boucadair Filename : draft-ietf-dhc-dynamic-shared-v4allocation-01.txt Pages : 13 Date : 2014-07-02 Abstract: This memo describes the dynamic allocation of shared IPv4 addresses to clients using DHCPv4. Address sharing allows a single IPv4 address to be allocated to multiple, active clients simultaneously, each client being differentiated by a unique set of transport source port numbers. The necessary changes to existing DHCPv4 client and server behavior are described and a new DHCPv4 option for provisioning clients with shared IPv4 addresses is included. Due to the nature of IP addresses sharing, some limitations to their applicability are necessary. This memo describes these limitations and recommends suitable architectures and technologies where address sharing may be utilized. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dynamic-shared-v4allocation/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dynamic-shared-v4allocation-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dynamic-shared-v4allocation-01 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 Jul 2 06:19:38 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1331A00B6 for ; Wed, 2 Jul 2014 06:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, 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 0l2Zom6mh07S for ; Wed, 2 Jul 2014 06:19:35 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E7531A0080 for ; Wed, 2 Jul 2014 06:19:35 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id fp1so11961694pdb.30 for ; Wed, 02 Jul 2014 06:19:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:references:to:message-id :mime-version; bh=ShO7pqsUaGTv2wCFsCNlXp/YoborwVDxLIYZGYy/Euo=; b=ioOLVFSDrEl9ps5YdjDFSmjq4jiQIrnxaRgzFH2/Dm9HQm2S4L1qWlUxnXUd/g5MWf YBQjqWy56+zLceNHIudoa22WjZaN3nplCXk44dTancRcm3ol9RYhpmoByp5b+ij9foSa XAxnM5MgAtocOeCa+oFvFWRQPixtBOPq9WqUombgy8CwWRl/Unlnxby0c7Z0RR310ItM eup+WNzGq7sctzh57QJFSR12tzeKCinW1m0Jxevxgh3x3FeeLpN8Og0T/2XED1kNtlAp G0klpLBjvwu3Yxl2wGG/VmbsI2g1ucfEEJacwL6VSEc3arhtp1C2YSDYt09qRoC2E4sP YLNA== X-Received: by 10.66.252.35 with SMTP id zp3mr3949856pac.40.1404307175188; Wed, 02 Jul 2014 06:19:35 -0700 (PDT) Received: from [192.168.2.204] ([166.111.68.231]) by mx.google.com with ESMTPSA id pr8sm37282488pbc.74.2014.07.02.06.19.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Jul 2014 06:19:34 -0700 (PDT) From: Qi Sun Content-Type: multipart/alternative; boundary="Apple-Mail=_86319096-E623-4444-A548-1032A34BEFD4" Date: Wed, 2 Jul 2014 21:19:29 +0800 References: <20140702131743.12536.63909.idtracker@ietfa.amsl.com> To: DHC WG Message-Id: <2710C059-5827-4F8C-812F-578A8571D901@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/cSKa8sjAvqwmN76VO-sPwoIztrI Subject: [dhcwg] Fwd: I-D Action: draft-ietf-dhc-dynamic-shared-v4allocation-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: Wed, 02 Jul 2014 13:19:37 -0000 --Apple-Mail=_86319096-E623-4444-A548-1032A34BEFD4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dear all, We have submitted an updated version of = draft-ietf-dhc-dynamic-shared-v4allocation.=20 Here is a list of the major changes: 1) Specify the logic of the DHCP 4o6 Server when allocating a shared = IPv4 address 2) Make it clear about which interface to use the configuration 3) Require the server to implement a well-known-port reserving mechanism 4) Add some text about the client=92s behaviour if it runs with a server = that doesn=92t support address sharing. 5) Rearrange some sections 6) Clean up the text throughout the document =20 7) Fix some inaccurate description in the section of Client-Server = Interaction, according to RFC2131 Please can you review the document. Comments/suggestions are always = appreciated. Thanks, Qi Begin forwarded message: > From: internet-drafts@ietf.org > Subject: [dhcwg] I-D Action: = draft-ietf-dhc-dynamic-shared-v4allocation-01.txt > Date: July 2, 2014 at 9:17:43 PM GMT+8 > To: i-d-announce@ietf.org > Cc: dhcwg@ietf.org >=20 >=20 > 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. >=20 > Title : Dynamic Allocation of Shared IPv4 Addresses > Authors : Yong Cui > Qiong Sun > Ian Farrer > Yiu L. Lee > Qi Sun > Mohamed Boucadair > Filename : = draft-ietf-dhc-dynamic-shared-v4allocation-01.txt > Pages : 13 > Date : 2014-07-02 >=20 > Abstract: > This memo describes the dynamic allocation of shared IPv4 addresses > to clients using DHCPv4. Address sharing allows a single IPv4 > address to be allocated to multiple, active clients simultaneously, > each client being differentiated by a unique set of transport source > port numbers. The necessary changes to existing DHCPv4 client and > server behavior are described and a new DHCPv4 option for > provisioning clients with shared IPv4 addresses is included. >=20 > Due to the nature of IP addresses sharing, some limitations to their > applicability are necessary. This memo describes these limitations > and recommends suitable architectures and technologies where address > sharing may be utilized. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-dhc-dynamic-shared-v4allocatio= n/ >=20 > There's also a htmlized version available at: > = http://tools.ietf.org/html/draft-ietf-dhc-dynamic-shared-v4allocation-01 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dynamic-shared-v4allocat= ion-01 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg --Apple-Mail=_86319096-E623-4444-A548-1032A34BEFD4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Dear = all,

We have submitted an updated version = of draft-ietf-dhc-dynamic-shared-v4allocation. 

Here is a list of the = major changes:

1) Specify the logic of the DHCP 4o6 Server when allocating a = shared IPv4 address
2) Make it clear about which interface to use the = configuration
3) Require the server to implement a well-known-port reserving = mechanism
4) = Add some text about the client=92s behaviour if it runs with a server = that doesn=92t support address sharing.
5) Rearrange some sections
6) = Clean up the text throughout the document  
7) Fix some = inaccurate description in the section of Client-Server Interaction, = according to RFC2131

Please can you review the document. = Comments/suggestions are always appreciated.

Thanks,
Qi


Begin forwarded = message:

From: = internet-drafts@ietf.org
<= /span>
Subject: = [dhcwg] I-D = Action: = draft-ietf-dhc-dynamic-shared-v4allocation-01.txt
Date: July 2, 2014 at 9:17:43 PM = GMT+8


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 =           : Dynamic = Allocation of Shared IPv4 Addresses
=        Authors =         : Yong Cui
=             &n= bsp;           &nbs= p;Qiong Sun
=             &n= bsp;           &nbs= p;Ian Farrer
=             &n= bsp;           &nbs= p;Yiu L. Lee
=             &n= bsp;           &nbs= p;Qi Sun
=             &n= bsp;           &nbs= p;Mohamed Boucadair
Filename =        : = draft-ietf-dhc-dynamic-shared-v4allocation-01.txt
Pages =           : = 13
= Date =            : = 2014-07-02

Abstract:
  This memo describes the = dynamic allocation of shared IPv4 addresses
  to clients = using DHCPv4.  Address sharing allows a single IPv4
=   address to be allocated to multiple, active clients = simultaneously,
  each client being differentiated by a = unique set of transport source
  port numbers.  The = necessary changes to existing DHCPv4 client and
  server = behavior are described and a new DHCPv4 option for
=   provisioning clients with shared IPv4 addresses is = included.

  Due to the nature of IP addresses sharing, = some limitations to their
  applicability are necessary. =  This memo describes these limitations
  and = recommends suitable architectures and technologies where address
=   sharing may be utilized.


The IETF datatracker = status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dhc-dynamic-shared= -v4allocation/

There's also a htmlized version available = at:
http://tools.ietf.org/html/draft-ietf-dhc-dynamic-shared-v4allocati= on-01

A diff from the previous version is available = at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dynamic-shared-v4= allocation-01


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

Internet-Drafts are also = available by anonymous FTP = at:
ftp://ftp.ietf.org/internet-drafts/

________________________= _______________________
dhcwg mailing = list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg
<= /div>
= --Apple-Mail=_86319096-E623-4444-A548-1032A34BEFD4-- From nobody Wed Jul 2 11:48:55 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 250E61A03C3 for ; Wed, 2 Jul 2014 11:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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.651, 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 My2ZHKTl2I8h for ; Wed, 2 Jul 2014 11:48:50 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAE231A0395 for ; Wed, 2 Jul 2014 11:48:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1644; q=dns/txt; s=iport; t=1404326930; x=1405536530; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=aFcXEPRu4G7pQdWO6OndqxUn7419v/08u0zZCg1sPDE=; b=D5ZrtFgrYKLKzD4TTL6MAWDdf/+Ccphb++tLsir7c0hhr91z/7muOWo3 L/QSIpPYTVdW09r9OEKbSxYZlykGijimiPXsfBG/6J8Ec7dmlZqbvliI+ s21ynxIpfxnJrIceswyzSJyL+w0jORqQQ+H3eZ3SpW0x45mr5xG4iJnye o=; X-IronPort-AV: E=Sophos;i="5.01,589,1400025600"; d="scan'208";a="57829350" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-5.cisco.com with ESMTP; 02 Jul 2014 18:48:50 +0000 Received: from [161.44.70.112] ([161.44.70.112]) (authenticated bits=0) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s62ImlJH019422 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 2 Jul 2014 18:48:49 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Kim Kinnear In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1B5E230E@xmb-rcd-x04.cisco.com> Date: Wed, 2 Jul 2014 14:48:47 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <489D13FBFA9B3E41812EA89F188F018E1B5C38A3@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1B5D3ADA@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1B5E230E@xmb-rcd-x04.cisco.com> To: Bernie Volz (volz) X-Mailer: Apple Mail (2.1510) X-Authenticated-User: kkinnear Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/poE_dCl_OfiFrdAvkaJHXhdtQTM Cc: "dhcwg@ietf.org" , Kim Kinnear Subject: Re: [dhcwg] Reminder - Need Agenda Items for Toronto (IETF-90, July 20-25) 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, 02 Jul 2014 18:48:52 -0000 Bernie, Tomek, If you have a 5 minute time-slot, I'd be happy to report on the progress of turning the DHCPv6 Failover Design draft into two drafts, a smaller Design draft and a Protocol draft. I have made some progress in this effort, and could share the current table of contents of each draft to give people some idea of the approach that we are taking. And, of course, collect any feedback that is offered. As a status update, this isn't high priority, so if time is (or gets to be) short, we could easily skip it. Regards -- Kim On Jul 1, 2014, at 11:31 AM, Bernie Volz (volz) wrote: > Just another reminder for agenda items. > =20 > Current draft agenda is at = http://www.ietf.org/proceedings/90/agenda/agenda-90-dhc. > =20 > - Bernie > =20 > From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz = (volz) > Sent: Monday, June 16, 2014 8:40 AM > To: dhcwg@ietf.org > Subject: [dhcwg] Reminder - Need Agenda Items for Toronto (IETF-90, = July 20-25) > =20 > Hi: > =20 > Please send us (dhc-chairs@tools.ietf.org) requests for sessions for = the DHC WG meeting in Toronto. Include: > =20 > Name of session: > Name of draft(s): > Time requested: > Presenter name(s): > Brief description of what issues need discussing and what you hope to = accomplish by presenting: > =20 > More details about the Toronto IETF can be found at = http://www.ietf.org/meeting/90/index.html. > =20 > - Tomek & Bernie > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From nobody Wed Jul 2 15:03:51 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67BF31B2AE3 for ; Wed, 2 Jul 2014 15:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 lMP1DPWO3PHV for ; Wed, 2 Jul 2014 15:03:46 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B3E81B2ADE for ; Wed, 2 Jul 2014 15:03:46 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKU7SBwmycVS30nx+JacI21YhOyfUIAhdM@postini.com; Wed, 02 Jul 2014 15:03:46 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 0D2391B82FC for ; Wed, 2 Jul 2014 15:03:46 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id DF409190077; Wed, 2 Jul 2014 15:03:45 -0700 (PDT) Received: from [192.168.43.232] (198.228.194.73) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 2 Jul 2014 15:03:40 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: Date: Wed, 2 Jul 2014 18:03:27 -0400 Content-Transfer-Encoding: 7bit Message-ID: <26CC0B29-4EB5-44DD-AF3C-F6E06F3D0719@nominum.com> References: <489D13FBFA9B3E41812EA89F188F018E1B5C38A3@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1B5D3ADA@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1B5E230E@xmb-rcd-x04.cisco.com> To: Kim Kinnear X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [198.228.194.73] Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/mlWD2bA2ZYTBltaUzEEPiNe9gFU Cc: "dhcwg@ietf.org" , Bernie Volz Subject: Re: [dhcwg] Reminder - Need Agenda Items for Toronto (IETF-90, July 20-25) 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, 02 Jul 2014 22:03:48 -0000 On Jul 2, 2014, at 2:48 PM, Kim Kinnear wrote: > As a status update, this isn't high priority, so if time is (or gets > to be) short, we could easily skip it. I would like to hear it! :) From nobody Thu Jul 3 05:29:53 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC4EE1B2796 for ; Thu, 3 Jul 2014 05:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g21PG7GeKLeF for ; Thu, 3 Jul 2014 05:29:51 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A27B1A0AA6 for ; Thu, 3 Jul 2014 05:29:51 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w61so162999wes.15 for ; Thu, 03 Jul 2014 05:29:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=piJC/UAozgf4lcTI7DNL/dVkruLk3SoIQpw9SZqbsVg=; b=miBzpRM2P/Djxl+wbhxBzPjE4Ti5psGeQXf/8EBoA9lucnw2wa78duxOFkVSMm4hcw Pu2SWjdvCFuq66g04Q43pe22gPF4ZhqUaBK8rrotnSiRdHaZNZ0yuJkW88zs8wtyvg7C 1FG0nNEuX2NImUJG/9abYGrN93uzlU1YN3j61FrX6TAMTW5okgOItqqTvbiXeAjrRour OUpI9OoIEThp/oJyh3KejGSDplWX0Fs+gfpWLr2sXqGtxAO5YdJ2gh1sbSC0X8P43gL3 PD50IaktPhUVwYV/ZiJ/Y+4oSgtwUPSjpvi4yEZDPKrLcwSqymwA4+IGcM4/XPoDCDTx l3DQ== X-Received: by 10.180.79.168 with SMTP id k8mr50696285wix.35.1404390590318; Thu, 03 Jul 2014 05:29:50 -0700 (PDT) Received: from [10.0.0.100] (109107011157.gdansk.vectranet.pl. [109.107.11.157]) by mx.google.com with ESMTPSA id l8sm61778165wje.15.2014.07.03.05.29.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Jul 2014 05:29:49 -0700 (PDT) Message-ID: <53B54CB5.40407@gmail.com> Date: Thu, 03 Jul 2014 14:29:41 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dhcwg@ietf.org References: <489D13FBFA9B3E41812EA89F188F018E1B5C38A3@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1B5D3ADA@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1B5E230E@xmb-rcd-x04.cisco.com> <26CC0B29-4EB5-44DD-AF3C-F6E06F3D0719@nominum.com> In-Reply-To: <26CC0B29-4EB5-44DD-AF3C-F6E06F3D0719@nominum.com> X-Enigmail-Version: 1.5.2 X-TagToolbar-Keys: D20140703142941740 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/QmZHWT1bmBLE8fGEtJl0GlbuZfk Subject: Re: [dhcwg] Reminder - Need Agenda Items for Toronto (IETF-90, July 20-25) 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, 03 Jul 2014 12:29:53 -0000 On 03.07.2014 00:03, Ted Lemon wrote: > On Jul 2, 2014, at 2:48 PM, Kim Kinnear wrote: >> As a status update, this isn't high priority, so if time is (or gets >> to be) short, we could easily skip it. > > I would like to hear it! :) Definitely +1 to this. You have a slot. 5 mins for now, but let me know if you need more. Tomek From nobody Thu Jul 3 09:27:52 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F411B2945 for ; Thu, 3 Jul 2014 09:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrgWoiCHy9yh for ; Thu, 3 Jul 2014 09:27:49 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA0A01B2B13 for ; Thu, 3 Jul 2014 09:27:48 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id r20so2630262wiv.16 for ; Thu, 03 Jul 2014 09:27:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=Lsj4HaPVl3ScIvdX6mVoaPrwkwgCJNdetPrCIkKlJkw=; b=JGTGtbxSif2csRWgW9rMp8NGOHsbOC7F/xkx7KVzC4hAdxuhbyuWiE64QVIg0GhUFI fXccu4seJjpke1GcOJ2QkLRu0mcy86bAQf9IlrDuHV3wR4tekywOK2JXGeFKw7vg7zPo m0S/ODyFpR/RpjtS3F8r3G2dovLtNkls7WVCEOltQl0ZI5SD/SQc5r05TZjJddrI+vPD Kf6y7QLTU6w0Y8OwNjYEabSJeZdfTna4qu0jx0JySBxNgUA3Y7N12EjZUAuARJ8KhFrw zqOHAB9/XjNXYAl1HW03Own3a1VQztVOd4cfRKes+qpBPvur2ilyl20Bia6JNrZNeo63 wY8w== MIME-Version: 1.0 X-Received: by 10.180.221.133 with SMTP id qe5mr12179211wic.79.1404404867372; Thu, 03 Jul 2014 09:27:47 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.63.211 with HTTP; Thu, 3 Jul 2014 09:27:47 -0700 (PDT) In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1B5E03D1@xmb-rcd-x04.cisco.com> References: <20140630163351.4191.69719.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E1B5E03D1@xmb-rcd-x04.cisco.com> Date: Thu, 3 Jul 2014 09:27:47 -0700 X-Google-Sender-Auth: PmQs80nx-KZfvJ9e5cJfwfCmGug Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: "Bernie Volz (volz)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/NotThLrFOUksl0hd0u4Sa-wmJ48 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.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, 03 Jul 2014 16:27:51 -0000 At Mon, 30 Jun 2014 16:55:59 +0000, "Bernie Volz (volz)" wrote: > There is one outstanding issue that we'd like to get feedback on from fol= ks (as well as of course the other changes made). We can discuss on the mai= ling list but will also discuss at the Toronto IETF DHC WG Session. > > This is the issue of which status codes Renew and Rebind should use when = a server is unable to provide "leases" for a binding. Presently the text sa= ys to use NoBinding and part of that reason was that this is consistent wit= h what is currently written in RFC 3315. But it may be better to use NoAddr= sAvail/NoPrefixAvail instead of NoBinding. Marcin and I debated this some a= nd here is some data regarding this issue: Many points are discussed after these paragraphs, and I cannot easily say which is the best with confidence. But I figure out that it's at least incompatible with existing client implementations if the server returns something other than NoBinding. According to RFC 3315, the client will subsequently send a Request for the IA to (re-)establish the binding. If the server doesn't return NoBinding, and if the client doesn't regard it as the need for some recovery action (sending Request or Solicit), then the binding for the IA will eventually expire (from a quick look at the code, this seems to be what would happen with the WIDE DHCPv6 client implementation: http://sourceforge.net/projects/wide-dhcpv6/). It doesn't seem to be a good idea to break backward compatibility this way unless there's a strong reason for that. BTW, as I read the entire draft it occurred to me that this draft should probably describe what a client should do upon receiving a Reply (in response to various types of messages) more specifically, and with specific proposed text to revise Section 18.1.8 of RFC 3315. Discussions on the client behavior on receiving a Reply will also be related to the question on NoBinding vs others. -- JINMEI, Tatuya From nobody Thu Jul 3 11:26:14 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAA2E1B298B for ; Thu, 3 Jul 2014 11:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.852 X-Spam-Level: X-Spam-Status: No, score=-14.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 wSgvQGi7U15J for ; Thu, 3 Jul 2014 11:26:12 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61BE31B294D for ; Thu, 3 Jul 2014 11:26:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4784; q=dns/txt; s=iport; t=1404411972; x=1405621572; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=QHu/qPJ9lmepLU0yok3EFAdhdN6YLLRK8pJjw0pXI+w=; b=PFu2Ix0k7GnBopKg7DhREfgJ8QxcjTHk6PEAkPPBlvW5rur1SJ2S/OsI 1Xa+HromgCLLFFqh0f8HyG5lilZuOh5yxsRrNJ7pFv+k6xnFAD+y0bxGT KxjtOYK7FCc/7NcH81CEMfFvEhQ8g2O4qb3VzoptCtk75HjSCjlfSBklL w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAFKftVOtJA2E/2dsb2JhbABagw1SWoJvwywBGXMWdYQDAQEBAwEjEToLBQcEAgEIEQQBAQMCBh0DAgICHxEUAQgIAgQOBQiIJgMJCA2tY5R4DYZmF4EsiDmDFYF3FhsHBoJxNoEWBZh2g0iML4YUg0OCMA X-IronPort-AV: E=Sophos;i="5.01,596,1400025600"; d="scan'208";a="58138729" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-3.cisco.com with ESMTP; 03 Jul 2014 18:26:11 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s63IQBAj003104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Jul 2014 18:26:11 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.176]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Thu, 3 Jul 2014 13:26:11 -0500 From: "Bernie Volz (volz)" To: =?utf-8?B?56We5piO6YGU5ZOJ?= Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.txt Thread-Index: AQHPlIEus6CA5H78HkuHLmw+Sv8Eh5uJ3xfAgAUDK4D//8m40A== Date: Thu, 3 Jul 2014 18:26:10 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1B5E859E@xmb-rcd-x04.cisco.com> References: <20140630163351.4191.69719.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E1B5E03D1@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.242.223] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/GqxEC1UTc8RFfgT6EMBPEEPraBQ Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.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, 03 Jul 2014 18:26:14 -0000 SGkgSmlubWVpOg0KDQpZZXMsIHRoYXQgaXMgdGhlIG9uZSBpc3N1ZSB3aXRoIGNoYW5naW5nIHRo ZSBzdGF0dXMgY29kZXMgLSBpdCBicmVha3MgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkuIEhvd2V2 ZXIsIHdlIGFscmVhZHkgaGF2ZSBjaGFuZ2VzIHRoYXQgdGVjaG5pY2FsbHkgYnJlYWsgdGhpcyAo c3VjaCBhcyB0aGUgQWR2ZXJ0aXNlIHN0YXR1cyBjb2RlcykuIFRoZSByaXNrIGZvciB0aGVzZSBj aGFuZ2VzIHNob3VsZCBiZSBmYWlybHkgc21hbGwgYXMgKDEpIGNsaWVudHMgYXJlIGhvcGVmdWxs eSByb2J1c3QgZW5vdWdoIHRoYXQgdGhleSB3aWxsIGhhbmRsZSB1bmtub3duL3VuZXhwZWN0ZWQg c3RhdHVzIGNvZGVzIGFuZCBlaXRoZXIgJ2lnbm9yZScgdGhlIGJpbmRpbmcgKHNpbmNlIGl0IGNv bnRhaW5zIG5vIGFkZHJlc3Nlcy9wcmVmaXhlcykgb3IgcmVzdGFydCBhdCBTb2xpY2l0IGFuZCAo MikgdGhlc2UgYXJlIGVkZ2UgY2FzZXMgdGhhdCBtYXkgbm90IGhhdmUgYmVlbiB3ZWxsIHRlc3Rl ZCBpbiBhbGwgY2FzZXMgYW5kIGFyZSBsaWtlbHkgdG8gb2NjdXIgcmFyZWx5IChpLmUuLCBtb3N0 bHkgaW1wYWN0IFJlYmluZHMgd2hlbiAnbmV3JyBiaW5kaW5ncyBhcHBlYXIgd2hpY2ggYXJlIHBy b2JhYmx5IG5vdCB0aGF0IGNvbW1vbikuDQoNClRoZXNlIGFyZSBjbGVhcmx5IGNvbmNlcm5zIHdl IGhhdmUgYW5kIGl0IHdvdWxkIGJlIGdyZWF0IHRvIGhlYXIgZnJvbSBjbGllbnQgaW1wbGVtZW50 ZXJzIHRvIHVuZGVyc3RhbmQgd2hldGhlciB0aGVyZSBhcmUgYW55IHBvdGVudGlhbCBuYXN0eSBp bXBhY3RzLiBJdCBtYXkgYWxzbyBiZSBhbiBpbnRlcmVzdGluZyBhcmVhIHRvIHBlcmZvcm0gc29t ZSB0ZXN0cyBvbiBhICd1cGRhdGVkJyBzZXJ2ZXIgdG8gc2VlIGhvdyBhIHNhbXBsaW5nIG9mIGNs aWVudCBpbXBsZW1lbnRhdGlvbnMgaGFuZGxlIHRoZXNlIHNpdHVhdGlvbnMuDQoNClJlZ2FyZGlu ZyByZXZpc2luZyBTZWN0aW9uIDE4LjEuOCBhbmQgcHJvdmlkaW5nIHRoZSB0ZXh0IGluIHRoZSBk cmFmdCwgaWYgSSByZWNhbGwgdGhhdCB3YXMgcGxhbiBhbmQgcGFydCBvZiB0aGUgcmVhc29uIHRv IGhvbGQgb2ZmIG9uIG1ha2luZyB0aGlzIGNoYW5nZSAtIHRoZXJlIHdhc24ndCBzdWZmaWNpZW50 IHRpbWUgdG8gZG8gdGhpcyAncHJvcGVybHknIGJlZm9yZSB0aGUgZGVhZGxpbmUuDQoNClRoYW5r cyBmb3IgeW91ciByZXZpZXcgYW5kIGNvbW1lbnRzISEhDQoNCi0gQmVybmllDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBqaW5tZWkudGF0dXlhQGdtYWlsLmNvbSBbbWFpbHRv Omppbm1laS50YXR1eWFAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgPz8/Pw0KU2VudDogVGh1cnNk YXksIEp1bHkgMDMsIDIwMTQgMTI6MjggUE0NClRvOiBCZXJuaWUgVm9seiAodm9seikNCkNjOiBk aGN3Z0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtkaGN3Z10gSS1EIEFjdGlvbjogZHJhZnQtaWV0 Zi1kaGMtZGhjcHY2LXN0YXRlZnVsLWlzc3Vlcy0wNi50eHQNCg0KQXQgTW9uLCAzMCBKdW4gMjAx NCAxNjo1NTo1OSArMDAwMCwNCiJCZXJuaWUgVm9seiAodm9seikiIDx2b2x6QGNpc2NvLmNvbT4g d3JvdGU6DQoNCj4gVGhlcmUgaXMgb25lIG91dHN0YW5kaW5nIGlzc3VlIHRoYXQgd2UnZCBsaWtl IHRvIGdldCBmZWVkYmFjayBvbiBmcm9tIGZvbGtzIChhcyB3ZWxsIGFzIG9mIGNvdXJzZSB0aGUg b3RoZXIgY2hhbmdlcyBtYWRlKS4gV2UgY2FuIGRpc2N1c3Mgb24gdGhlIG1haWxpbmcgbGlzdCBi dXQgd2lsbCBhbHNvIGRpc2N1c3MgYXQgdGhlIFRvcm9udG8gSUVURiBESEMgV0cgU2Vzc2lvbi4N Cj4NCj4gVGhpcyBpcyB0aGUgaXNzdWUgb2Ygd2hpY2ggc3RhdHVzIGNvZGVzIFJlbmV3IGFuZCBS ZWJpbmQgc2hvdWxkIHVzZSB3aGVuIGEgc2VydmVyIGlzIHVuYWJsZSB0byBwcm92aWRlICJsZWFz ZXMiIGZvciBhIGJpbmRpbmcuIFByZXNlbnRseSB0aGUgdGV4dCBzYXlzIHRvIHVzZSBOb0JpbmRp bmcgYW5kIHBhcnQgb2YgdGhhdCByZWFzb24gd2FzIHRoYXQgdGhpcyBpcyBjb25zaXN0ZW50IHdp dGggd2hhdCBpcyBjdXJyZW50bHkgd3JpdHRlbiBpbiBSRkMgMzMxNS4gQnV0IGl0IG1heSBiZSBi ZXR0ZXIgdG8gdXNlIE5vQWRkcnNBdmFpbC9Ob1ByZWZpeEF2YWlsIGluc3RlYWQgb2YgTm9CaW5k aW5nLiBNYXJjaW4gYW5kIEkgZGViYXRlZCB0aGlzIHNvbWUgYW5kIGhlcmUgaXMgc29tZSBkYXRh IHJlZ2FyZGluZyB0aGlzIGlzc3VlOg0KDQpNYW55IHBvaW50cyBhcmUgZGlzY3Vzc2VkIGFmdGVy IHRoZXNlIHBhcmFncmFwaHMsIGFuZCBJIGNhbm5vdCBlYXNpbHkgc2F5IHdoaWNoIGlzIHRoZSBi ZXN0IHdpdGggY29uZmlkZW5jZS4gIEJ1dCBJIGZpZ3VyZSBvdXQgdGhhdCBpdCdzIGF0IGxlYXN0 IGluY29tcGF0aWJsZSB3aXRoIGV4aXN0aW5nIGNsaWVudCBpbXBsZW1lbnRhdGlvbnMgaWYgdGhl IHNlcnZlciByZXR1cm5zIHNvbWV0aGluZyBvdGhlciB0aGFuIE5vQmluZGluZy4gIEFjY29yZGlu ZyB0byBSRkMgMzMxNSwgdGhlIGNsaWVudCB3aWxsIHN1YnNlcXVlbnRseSBzZW5kIGEgUmVxdWVz dCBmb3IgdGhlIElBIHRvIChyZS0pZXN0YWJsaXNoIHRoZSBiaW5kaW5nLiAgSWYgdGhlIHNlcnZl ciBkb2Vzbid0IHJldHVybiBOb0JpbmRpbmcsIGFuZCBpZiB0aGUgY2xpZW50IGRvZXNuJ3QgcmVn YXJkIGl0IGFzIHRoZSBuZWVkIGZvciBzb21lIHJlY292ZXJ5IGFjdGlvbiAoc2VuZGluZyBSZXF1 ZXN0IG9yIFNvbGljaXQpLCB0aGVuIHRoZSBiaW5kaW5nIGZvciB0aGUgSUEgd2lsbCBldmVudHVh bGx5IGV4cGlyZSAoZnJvbSBhIHF1aWNrIGxvb2sgYXQgdGhlIGNvZGUsIHRoaXMgc2VlbXMgdG8g YmUgd2hhdCB3b3VsZCBoYXBwZW4gd2l0aCB0aGUgV0lERSBESENQdjYgY2xpZW50IGltcGxlbWVu dGF0aW9uOg0KaHR0cDovL3NvdXJjZWZvcmdlLm5ldC9wcm9qZWN0cy93aWRlLWRoY3B2Ni8pLiAg SXQgZG9lc24ndCBzZWVtIHRvIGJlIGEgZ29vZCBpZGVhIHRvIGJyZWFrIGJhY2t3YXJkIGNvbXBh dGliaWxpdHkgdGhpcyB3YXkgdW5sZXNzIHRoZXJlJ3MgYSBzdHJvbmcgcmVhc29uIGZvciB0aGF0 Lg0KDQpCVFcsIGFzIEkgcmVhZCB0aGUgZW50aXJlIGRyYWZ0IGl0IG9jY3VycmVkIHRvIG1lIHRo YXQgdGhpcyBkcmFmdCBzaG91bGQgcHJvYmFibHkgZGVzY3JpYmUgd2hhdCBhIGNsaWVudCBzaG91 bGQgZG8gdXBvbiByZWNlaXZpbmcgYSBSZXBseSAoaW4gcmVzcG9uc2UgdG8gdmFyaW91cyB0eXBl cyBvZiBtZXNzYWdlcykgbW9yZSBzcGVjaWZpY2FsbHksIGFuZCB3aXRoIHNwZWNpZmljIHByb3Bv c2VkIHRleHQgdG8gcmV2aXNlIFNlY3Rpb24gMTguMS44IG9mIFJGQyAzMzE1Lg0KRGlzY3Vzc2lv bnMgb24gdGhlIGNsaWVudCBiZWhhdmlvciBvbiByZWNlaXZpbmcgYSBSZXBseSB3aWxsIGFsc28g YmUgcmVsYXRlZCB0byB0aGUgcXVlc3Rpb24gb24gTm9CaW5kaW5nIHZzIG90aGVycy4NCg0KLS0N CkpJTk1FSSwgVGF0dXlhDQo= From nobody Fri Jul 4 04:59:59 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A60B41B288C; Fri, 4 Jul 2014 04:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sD_yJT-WfU8J; Fri, 4 Jul 2014 04:59:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E921C1B288B; Fri, 4 Jul 2014 04:59:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704115950.9640.38887.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 04:59:50 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/iU4W6Jn17Dc3vyG8oSC24o0gBV0 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-topo-conf-02.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, 04 Jul 2014 11:59:53 -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 : Customizing DHCP Configuration on the Basis of Network Topology Authors : Ted Lemon Tomek Mrugalski Filename : draft-ietf-dhc-topo-conf-02.txt Pages : 15 Date : 2014-07-04 Abstract: DHCP servers have evolved over the years to provide significant functionality beyond that which is described in the DHCP base specifications. One aspect of this functionality is support for context-specific configuration information. This memo describes some such features and makes recommendations as to how they can be used. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-topo-conf/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-topo-conf-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-topo-conf-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 4 05:05:59 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A654C1B2D15 for ; Fri, 4 Jul 2014 05:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCWBsXSR_XUc for ; Fri, 4 Jul 2014 05:05:48 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 669341B2874 for ; Fri, 4 Jul 2014 05:05:48 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hi2so3717825wib.13 for ; Fri, 04 Jul 2014 05:05:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Uw0qQwcm1TftxIP9by8VksPgt7mH4CCLmPH7bg8/0wc=; b=PTS4trcujEvnt+2rVmB6W8Iic4sXjZWzSxMZFAP8nTRjVDQUtgpfjmQDbNBQYfPoKb 13H8kqUs3bYzn0CrtuCcAMEXLodfxqq/7Kwj8/7yJP9AN1R3u03SHW2jF8gRTzJc5JQ8 Dzuynvbp+EkaqHEFkDCD8/2WqSZGF5SUnbS7HDP0rS6iJbPL5TSEHOndugmKpm+pLo+n Fo3FKzYPELqvxCaF8V2SaU9ZVu+kHQ5/hZA5L7pHAivmrt9zWQMoP5lwTeZSvKKl8KHy EWpuKh1ZNbEF8rojFcAUSKKSVqmNBzlSLDCpPbhdY6BcLXHO+uPiWBb/Lf9mkKkUModB pRFA== X-Received: by 10.180.92.65 with SMTP id ck1mr17784807wib.48.1404475542812; Fri, 04 Jul 2014 05:05:42 -0700 (PDT) Received: from [10.0.0.100] (109107011157.gdansk.vectranet.pl. [109.107.11.157]) by mx.google.com with ESMTPSA id hi2sm68618708wjb.29.2014.07.04.05.05.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 04 Jul 2014 05:05:41 -0700 (PDT) Message-ID: <53B6988E.40503@gmail.com> Date: Fri, 04 Jul 2014 14:05:34 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dhcwg@ietf.org References: <20140704115950.9640.38887.idtracker@ietfa.amsl.com> In-Reply-To: <20140704115950.9640.38887.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.2 X-TagToolbar-Keys: D20140704140534254 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/9Ehf-fFs66rb2b2w_w2VCB8r6gM Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-topo-conf-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 12:05:51 -0000 This is an updated version that hopefully addresses all raised comments. Thanks a lot to all those who took time and reviewed it. Changes since -01: - The doc is now informational; - Terminology fixed and expanded (also covers some Microsoft terminology); - Added a reference when an option is mentioned for the first time; - Added explanation that clients are never exposed to relay-forward or relay-reply messages; - examples rewritten (they are now properly formatted JSON and use IP test ranges from RFC5737; - Clarified that name resolution does not pick up changes instantly, but is subject to DNS caching mechanism; - Merged 2 sections about relays; - All references are now informative (normative is not allowed in informational); - I-D is now idnits clean. Tomek On 04.07.2014 13:59, internet-drafts@ietf.org wrote: > > 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 : Customizing DHCP Configuration on the Basis of Network Topology > Authors : Ted Lemon > Tomek Mrugalski > Filename : draft-ietf-dhc-topo-conf-02.txt > Pages : 15 > Date : 2014-07-04 > > Abstract: > DHCP servers have evolved over the years to provide significant > functionality beyond that which is described in the DHCP base > specifications. One aspect of this functionality is support for > context-specific configuration information. This memo describes some > such features and makes recommendations as to how they can be used. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dhc-topo-conf/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-dhc-topo-conf-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-topo-conf-02 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > From nobody Fri Jul 4 09:23:40 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C97631B2DB0; Fri, 4 Jul 2014 09:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4_auQk0vpyvq; Fri, 4 Jul 2014 09:23:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3191B2D93; Fri, 4 Jul 2014 09:23:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704162333.13251.42099.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 09:23:33 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/7v9b5VLPukZq2vQc73jBzKkiywo Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-load-balancing-02.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, 04 Jul 2014 16:23:35 -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 : Load Balancing for DHCPv6 Author : Andre Kostur Filename : draft-ietf-dhc-dhcpv6-load-balancing-02.txt Pages : 6 Date : 2014-07-04 Abstract: This document proposes a method of algorithmic load balancing for IPv6 Dynamic Host Configuration Protocol (DHCPv6) traffic. It enables multiple, cooperating servers to decide which one should service a client, without necessarily exchanging any information between the servers. The server selection is based on the servers hashing client DHCP Unique Identifiers (DUIDs) when multiple DHCPv6 servers are available to service DHCPv6 clients. The proposed technique provides for efficient server selection when multiple DHCPv6 servers offer services on a network without requiring any changes to existing DHCPv6 clients. This algorithm is an extension of an already defined and proven algorithm used for DHCPv4, as described in RFC 3074. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-load-balancing/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-load-balancing-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv6-load-balancing-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 4 09:26:53 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8788F1B2DBD for ; Fri, 4 Jul 2014 09:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable 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 ywHeRV3ySjRO for ; Fri, 4 Jul 2014 09:26:51 -0700 (PDT) Received: from na3sys010aog106.obsmtp.com (na3sys010aog106.obsmtp.com [74.125.245.80]) by ietfa.amsl.com (Postfix) with SMTP id 19AAF1B2DC7 for ; Fri, 4 Jul 2014 09:26:48 -0700 (PDT) Received: from mail-ve0-f173.google.com ([209.85.128.173]) (using TLSv1) by na3sys010aob106.postini.com ([74.125.244.12]) with SMTP ID DSNKU7bVyIh+riKWk0jBBax1wjqQ8ma5OJ5G@postini.com; Fri, 04 Jul 2014 09:26:49 PDT Received: by mail-ve0-f173.google.com with SMTP id db11so1845374veb.32 for ; Fri, 04 Jul 2014 09:26:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MSG9Q9Aa8+lsAEb7h5VmLcKl7HT6FFuqa8iWc5HlR3I=; b=LC1dbakOdfft5IPf90KW6YY9r2Hty5Lo21P4zkM008IHSKRYAnh+g/1+hFDLQpE1Ef w6oOCfXcP3yuaooFox+0c0zNzMEScjpi+kwXStvqkjtjNNNEeY8qeU27WkkBy8r3mtZY jW02UbH8Nwu2FaST8uV8/V/XY9wCNIX5SyBspRYPlVWNmi9cEu3GLWguNqWxV9gjqk5b dNxpRwsQXO9CgsvP4FnG3Udmjm/+I+CMZJ5CrRd2WRdJS/KAYW1BDt9NEqgTFvIK/syI yLAk5UcoLYngY46QOWLwcMX6VXgVL+9q8Ideo2sySngNiqM+vVHdlAeUkN6esmovyWF2 UhFw== X-Gm-Message-State: ALoCoQnrE8Evyuzcc8DFlCzCAkbo2LhiJVl5zxUHVgMUKtMlk8Ar4I9Hnldk/Yn1AQdLM3y93c/yz+1jFIH1gwGAI72bj5knWiSAQQ6ZjVK3jFU6YSR8QGX8zmv7o5BsLRUlSq3trUYs X-Received: by 10.58.234.103 with SMTP id ud7mr10482798vec.24.1404491208034; Fri, 04 Jul 2014 09:26:48 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.58.234.103 with SMTP id ud7mr10482793vec.24.1404491207918; Fri, 04 Jul 2014 09:26:47 -0700 (PDT) Received: by 10.220.147.79 with HTTP; Fri, 4 Jul 2014 09:26:47 -0700 (PDT) In-Reply-To: <20140704162333.13251.42099.idtracker@ietfa.amsl.com> References: <20140704162333.13251.42099.idtracker@ietfa.amsl.com> Date: Fri, 4 Jul 2014 09:26:47 -0700 Message-ID: From: Andre Kostur To: internet-drafts@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/IMGdXYrbAg3H3k_hG2hVXdGNbDw Cc: "dhcwg@ietf.org" , i-d-announce@ietf.org Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-load-balancing-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 16:26:52 -0000 Changes from -01: - Title changed to the simpler "Load Balancing for DHCPv6" - Lease Queries are no longer load balanced - Changed on draft reference from Informative to Normative On Fri, Jul 4, 2014 at 9:23 AM, wrote: > > 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 : Load Balancing for DHCPv6 > Author : Andre Kostur > Filename : draft-ietf-dhc-dhcpv6-load-balancing-02.txt > Pages : 6 > Date : 2014-07-04 > > Abstract: > This document proposes a method of algorithmic load balancing for > IPv6 Dynamic Host Configuration Protocol (DHCPv6) traffic. It > enables multiple, cooperating servers to decide which one should > service a client, without necessarily exchanging any information > between the servers. The server selection is based on the servers > hashing client DHCP Unique Identifiers (DUIDs) when multiple DHCPv6 > servers are available to service DHCPv6 clients. The proposed > technique provides for efficient server selection when multiple > DHCPv6 servers offer services on a network without requiring any > changes to existing DHCPv6 clients. This algorithm is an extension > of an already defined and proven algorithm used for DHCPv4, as > described in RFC 3074. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-load-balancing/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-load-balancing-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv6-load-balancing-02 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg -- Andre Kostur From nobody Fri Jul 4 11:01:22 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 314B51B2B0A for ; Fri, 4 Jul 2014 11:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qwakFZ9S3TD for ; Fri, 4 Jul 2014 11:01:02 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB09F1A04B8 for ; Fri, 4 Jul 2014 11:01:01 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id x48so1961742wes.39 for ; Fri, 04 Jul 2014 11:01:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=iAF59YX5xsZQfvc5mdTj1EtmfHB6aOCtMuc+CrC05aY=; b=uPYBxqdNcmbJb1TcPhFLrHzJYE6OJYBYqMZvRKjR0H9eL2PrUWAhimiJ6aCRO4S9eF x7rNg7+Zi6tZO1n/uiwvyVwSGgHdywHlMmdjrsZsH+339L82vAlmLV9FDgyxMULELbuQ OmpPDurvrTc1x/o1AvYTyjuY20iT2nGR+f3uw+rXMx+nBOfU4957jui2OfPr/VbAMwXQ 4c0spy23TaAWWrv4tEOl382J3g8C3O+RFeDmxVcV4b6OPxSONvVV8UZZLfiQtSBtO9jR Nx6Ik8nMjNv+dfPvUDN4xg3lAnINJMKn53yjnjsuJ7MzBtB//aqdmiNSvEvgevHK2hVu mixw== X-Received: by 10.180.20.112 with SMTP id m16mr19874383wie.6.1404496860594; Fri, 04 Jul 2014 11:01:00 -0700 (PDT) Received: from [10.0.0.100] (109107011157.gdansk.vectranet.pl. [109.107.11.157]) by mx.google.com with ESMTPSA id h3sm70403039wjz.48.2014.07.04.11.00.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 04 Jul 2014 11:00:59 -0700 (PDT) Message-ID: <53B6EBD6.6090509@gmail.com> Date: Fri, 04 Jul 2014 20:00:54 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dhcwg References: <20140704171020.22117.76924.idtracker@ietfa.amsl.com> In-Reply-To: <20140704171020.22117.76924.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.2 X-TagToolbar-Keys: D20140704200053989 X-Forwarded-Message-Id: <20140704171020.22117.76924.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/U6aDTA41gGsAtA4N2o8k2nvI-VY Subject: [dhcwg] New Version Notification for draft-dhcwg-dhc-rfc3315bis-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: Fri, 04 Jul 2014 18:01:10 -0000 We managed to upload rfc3315bis-02 before the deadline. There are too many changes to mention here, so we're keeping a changelog. See appendices A (changes since RFC3315) and B (changes since RFC3633). The lists now mention 30 changes. In general, we managed to merge around 80% of the RFC3633 text. The outstanding text will likely be affected by the stateful-issues, so we're waiting for this discussion to be resolved first. You can see the progress here: http://wiki.tools.ietf.org/group/dhcpv6bis/roadmap The changes will be briefly presented in Toronto, but we'll focus more on unresolved issues. Thanks a lot to everyone who helped move this effort forward. Andrew, Bernie, Marcin, Michael, Sheng, Ted and Tomek (the DHCPv6bis team) -------- Original Message -------- Subject: New Version Notification for draft-dhcwg-dhc-rfc3315bis-02.txt Date: Fri, 04 Jul 2014 10:10:20 -0700 From: internet-drafts@ietf.org To: Andrew Yourtchenko , "Bernie Volz" , "Tomek Mrugalski" , Bernie Volz , Marcin Siodelski , Michael C. Richardson , "Sheng Jiang" , Ted Lemon , "Andrew Yourtchenko" , Tomek Mrugalski , Sheng Jiang , "Marcin Siodelski" , "Michael Richardson" , "Ted Lemon" A new version of I-D, draft-dhcwg-dhc-rfc3315bis-02.txt has been successfully submitted by Tomek Mrugalski and posted to the IETF repository. Name: draft-dhcwg-dhc-rfc3315bis Revision: 02 Title: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) bis Document date: 2014-07-04 Group: Individual Submission Pages: 119 URL: http://www.ietf.org/internet-drafts/draft-dhcwg-dhc-rfc3315bis-02.txt Status: https://datatracker.ietf.org/doc/draft-dhcwg-dhc-rfc3315bis/ Htmlized: http://tools.ietf.org/html/draft-dhcwg-dhc-rfc3315bis-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-dhcwg-dhc-rfc3315bis-02 Abstract: The Dynamic Host Configuration Protocol for IPv6 (DHCP) enables DHCP servers to pass configuration parameters such as IPv6 network addresses to IPv6 nodes. It offers the capability of automatic allocation of reusable network addresses and additional configuration flexibility. This protocol is a stateful counterpart to "IPv6 Stateless Address Autoconfiguration" (RFC 4862), and can be used separately or concurrently with the latter to obtain configuration parameters. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Fri Jul 4 14:35:32 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA2511A006D; Fri, 4 Jul 2014 14:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X_4kkhjFXR3Z; Fri, 4 Jul 2014 14:35:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B4BFE1A0033; Fri, 4 Jul 2014 14:35:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704213527.23309.9969.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 14:35:27 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/wj6WZRpsLR3t2kH2ndhi8e_sVXw Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-access-network-identifier-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: Fri, 04 Jul 2014 21:35:29 -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 Jouni Korhonen Mark Grayson Filename : draft-ietf-dhc-access-network-identifier-03.txt Pages : 19 Date : 2014-07-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: http://tools.ietf.org/html/draft-ietf-dhc-access-network-identifier-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-access-network-identifier-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 Mon Jul 7 02:56:00 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D85A1B2802 for ; Mon, 7 Jul 2014 02:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 hTD8MLV5hbcm for ; Mon, 7 Jul 2014 02:55:56 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38B741B2800 for ; Mon, 7 Jul 2014 02:55:56 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJS04044; Mon, 07 Jul 2014 09:55:54 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 7 Jul 2014 10:55:20 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.249]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Mon, 7 Jul 2014 17:55:12 +0800 From: Sheng Jiang To: "Bernie Volz (volz)" , "dhcwg@ietf.org" Thread-Topic: New Version Notification for draft-ietf-dhc-addr-registration-05.txt Thread-Index: AQHPj3NvBf4tyNHnxkyDrQ6e74mlpJt/yBiAgAUbM+CAD4whYA== Date: Mon, 7 Jul 2014 09:55:12 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AEC847B@nkgeml512-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AEB5A83@nkgeml512-mbx.china.huawei.com> <489D13FBFA9B3E41812EA89F188F018E1B5DB79F@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1B5DB79F@xmb-rcd-x04.cisco.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/rsD1r7Qw73voGAjqTHx_yNkBlyA Subject: Re: [dhcwg] New Version Notification for draft-ietf-dhc-addr-registration-05.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, 07 Jul 2014 09:55:58 -0000 SGksIEJlcm5pZSwNCg0KVGhhbmtzIHNvIG11Y2ggZm9yIHlvdXIgY2FyZWZ1bCByZXZpZXcuIFdl IHdpbGwgYXBwbHkgeW91ciBjb21tZW50cyBpbiB0aGUgbmV4dCB1cGRhdGUsIHByb2JhYmx5IGJl Zm9yZSBESEMgc2Vzc2lvbiBpbiBUb3JvbnRvLiBTb21lIHJlcGxpZXMgcmVnYXJkaW5nIHRvIHBv aW50IDUgYmVsb3cuDQoNCj41LiBIYXZlIHlvdSBjb25maXJtZWQgdGhhdCB0aGUgSS1ELmlldGYt ZGhjLXNlZGhjcHY2IGNhbiBpbmRlZWQgYmUgdXNlZCBmb3INCj50aGlzIHNldCBvZiByZXF1ZXN0 cz8gKFRoYXQgYWN0dWFsbHkgcG9pbnRzIG91dCBhbiBpbnRlcmVzdGluZyBpc3N1ZSBpbiB0aGF0 IHRoZQ0KPnNlZGhjcHY2IGRvY3VtZW50IG1lbnRpb25zIG5vdGhpbmcgU29saWNpdCB3L1JhcGlk IENvbW1pdCBhbmQgd2hldGhlciBpdA0KPmNhbiBvciBjYW4ndCBiZSB1c2VkLiBBbmQsIHRoZXJl J3MgdGV4dCBpbiBzZWN0aW9uIDYuMSBvZiB0aGF0IGRvY3VtZW50IHRoYXQNCj5zYXlzICIgSWYg dGhlIHNlbmRlciBpcyBhIERIQ1B2NiBjbGllbnQsIGluIHRoZSBmYWlsdXJlIGNhc2VzLCBpdCBy ZWNlaXZlcyBhIFJlcGx5DQo+bWVzc2FnZSB3aXRoIGFuIGVycm9yIHN0YXR1cyBjb2RlLiIgLi4u IHdoYXQgYWJvdXQgYSBTb2xpY2l0ICh3L28gUmFwaWQNCj5Db21taXQpIGFuZCBhbiBBZHZlcnRp c2UgcmVwbHkuKQ0KDQpBcyBhdXRob3Igb2Ygc2VESENQdjYsIEkgZG9uJ3Qgc2VlIGFueSByZWFz b24sIGl0IGNhbm5vdCBiZSB1c2VkIGZvciB0aGlzIHJlcXVlc3QuIFdlIGRvIG5vdCBtZW50aW9u IGFueSBzcGVjaWZpYyB0eXBlcyBvZiBtZXNzYWdlcyBpbiBzZWRoY3B2Niwgc2luY2Ugd2UgdGhp bmsgYWxsIHR5cGVzIG9mIG1lc3NhZ2VzIGNhbiB1c2UgdGhlIHNlY3VyZSBtb2RlbC4NCg0KQmVz dCByZWdhcmRzLA0KDQpTaGVuZw0KDQo+LSBCZXJuaWUNCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPkZyb206IGRoY3dnIFttYWlsdG86ZGhjd2ctYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIFNoZW5nIEppYW5nDQo+U2VudDogVHVlc2RheSwgSnVuZSAyNCwgMjAxNCAyOjE2 IEFNDQo+VG86IGRoY3dnQGlldGYub3JnDQo+U3ViamVjdDogW2RoY3dnXSBGVzogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvcg0KPmRyYWZ0LWlldGYtZGhjLWFkZHItcmVnaXN0cmF0aW9uLTA1 LnR4dA0KPg0KPkhpLCBhbGwsDQo+DQo+VGhlIGF1dGhvcnMgaGF2ZSBzdWJtaXR0ZWQgYW4gdXBk YXRlIHZlcnNpb24uIFdlIGJlbGlldmUgYWxsIHJlY2VpdmVkDQo+Y29tbWVudHMgaGF2ZSBiZWVu IGFkZHJlc3NlZC4gTW9kaWZpY2F0aW9ucyBhcmUgc3VtbWFyaXplZCBhcyBiZWxvdzoNCj4NCj4g LSBNYW5kYXRlZCBzZXJ2ZXIncyByZXNwb25zZSBmb3IgZXJyb3IgY29kZS4NCj4gLSBBZGRlZCBy ZWNvbW1lbmRhdGlvbiBmb3Igb25seSBvbmUgcmVnaXN0cmF0aW9uIHNlcnZlciBvdXQgb2YgbXVs dGlwbGUNCj5ESENQdjYgc2VydmVycy4NCj4gLSBBZGRlZCBzcGVjaWZpY2F0aW9uIHRoYXQgdGhl IHJlZ2lzdHJhdGlvbiBzZXJ2ZXIgc2hvdWxkIHJlY29yZCB0aGUgYmluZGluZw0KPmluZm9ybWF0 aW9uLg0KPiAtIEFsbG93ZWQgbXVsdGlwbGUgSUFfTkEuDQo+IC0gQ2xhcmlmaWVkIHRoYXQgdGhl IEFERFItUkVHSVNUUkFUSU9OLVJFUVVFU1QgbWVzc2FnZSBpcyBkZWRpY2F0ZWQgZm9yDQo+Y2xp ZW50cyB0byBpbml0aWF0ZSBhbiBhZGRyZXNzIHJlZ2lzdHJhdGlvbiByZXF1ZXN0LiBTbywgY2xp ZW50cyBNVVNUIE5PVA0KPmluY2x1ZGUgYW55IE9STy4NCj4NCj5Nb3JlIHJldmlld3MgYW5kIGNv bW1lbnRzIGFyZSBhcHByZWNpYXRlZC4NCj4NCj5CZXN0IHJlZ2FyZHMsDQo+DQo+U2hlbmcNCj4N Cj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+RnJvbTogaW50ZXJuZXQtZHJhZnRzQGll dGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KPj5TZW50OiBUdWVzZGF5 LCBKdW5lIDI0LCAyMDE0IDI6MTMgUE0NCj4+VG86IFN1cmVzaCBLcmlzaG5hbjsgUmFqaXYgQXNh dGk7IEdhbmcgQ2hlbjsgU2hlbmcgSmlhbmc7IFN1cmVzaA0KPj5LcmlzaG5hbjsgU2hlbmcgSmlh bmc7IEdhbmcgQ2hlbjsgUmFqaXYgQXNhdGkNCj4+U3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvcg0KPj5kcmFmdC1pZXRmLWRoYy1hZGRyLXJlZ2lzdHJhdGlvbi0wNS50eHQNCj4+ DQo+Pg0KPj5BIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi1kaGMtYWRkci1yZWdpc3Ry YXRpb24tMDUudHh0DQo+PmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgU2hlbmcg SmlhbmcgYW5kIHBvc3RlZCB0byB0aGUgSUVURg0KPj5yZXBvc2l0b3J5Lg0KPj4NCj4+TmFtZToJ CWRyYWZ0LWlldGYtZGhjLWFkZHItcmVnaXN0cmF0aW9uDQo+PlJldmlzaW9uOgkwNQ0KPj5UaXRs ZToJCVJlZ2lzdGVyaW5nIFNlbGYtZ2VuZXJhdGVkIElQdjYgQWRkcmVzc2VzIGluIEROUyB1c2lu ZyBESENQdjYNCj4+RG9jdW1lbnQgZGF0ZToJMjAxNC0wNi0yMw0KPj5Hcm91cDoJCWRoYw0KPj5Q YWdlczoJCTgNCj4+VVJMOg0KPj5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC1pZXRmLWRoYy1hZGRyLXJlZ2lzdHJhdGlvbi0wNQ0KPj4udHh0DQo+PlN0YXR1czoNCj4+ aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kaGMtYWRkci1yZWdp c3RyYXRpb24vDQo+Pkh0bWxpemVkOg0KPj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLWRoYy1hZGRyLXJlZ2lzdHJhdGlvbi0wNQ0KPj5EaWZmOg0KPj5odHRwOi8vd3d3Lmll dGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWRoYy1hZGRyLXJlZ2lzdHJhdGlvbi0wNQ0K Pj4NCj4+QWJzdHJhY3Q6DQo+PiAgIEluIG5ldHdvcmtzIHRoYXQgYXJlIGNlbnRyYWxseSBtYW5h Z2VkLCBzZWxmLWdlbmVyYXRlZCBhZGRyZXNzZXMNCj4+ICAgY2F1c2Ugc29tZSB0cmFjZWFiaWxp dHkgaXNzdWVzIGR1ZSB0byB0aGVpciBkZWNlbnRyYWxpemVkIG5hdHVyZS4NCj4+ICAgT25lIG9m IHRoZSBtb3N0IGltcG9ydGFudCBpc3N1ZXMgaW4gdGhpcyByZWdhcmQgaXMgdGhlIGluYWJpbGl0 eSB0bw0KPj4gICByZWdpc3RlciBzdWNoIGFkZHJlc3NlcyBpbiBETlMuICBUaGlzIGRvY3VtZW50 IGRlZmluZXMgYSBtZWNoYW5pc20gdG8NCj4+ICAgcmVnaXN0ZXIgc2VsZi1nZW5lcmF0ZWQgYW5k IHN0YXRpY2FsbHkgY29uZmlndXJlZCBhZGRyZXNzZXMgaW4gRE5TDQo+PiAgIHRocm91Z2ggYSBE SENQdjYgc2VydmVyLg0KPj4NCj4+DQo+Pg0KPj4NCj4+UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkg dGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4+c3VibWlzc2lvbiB1 bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xz LmlldGYub3JnLg0KPj4NCj4+VGhlIElFVEYgU2VjcmV0YXJpYXQNCj4NCj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPmRoY3dnIG1haWxpbmcgbGlzdA0K PmRoY3dnQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9k aGN3Zw0K From nobody Mon Jul 7 05:30:27 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3AE1B283E; Mon, 7 Jul 2014 05:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.343 X-Spam-Level: X-Spam-Status: No, score=-2.343 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 sDhYrqNQM1R0; Mon, 7 Jul 2014 05:30:21 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64E1A1B282C; Mon, 7 Jul 2014 05:30:21 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id s67CUJpA016215; Mon, 7 Jul 2014 21:30:19 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id s67CUJm0023508; Mon, 7 Jul 2014 21:30:19 +0900 (JST) Received: from ovp2.toshiba.co.jp [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id XAA23507; Mon, 7 Jul 2014 21:30:19 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id s67CUIVe006800; Mon, 7 Jul 2014 21:30:18 +0900 (JST) Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id s67CUI57027140; Mon, 7 Jul 2014 21:30:18 +0900 (JST) Received: from [133.196.16.134] (ncg-dhcp134.isl.rdc.toshiba.co.jp [133.196.16.134]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id B36EE97D4B; Mon, 7 Jul 2014 21:30:18 +0900 (JST) Message-ID: <53BA92D9.3000606@toshiba.co.jp> Date: Mon, 07 Jul 2014 21:30:17 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Routing Over Low power and Lossy networks , dhcwg@ietf.org References: <20140701155803.14047.81610.idtracker@ietfa.amsl.com> In-Reply-To: <20140701155803.14047.81610.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/mlx0_WNUeuFyVQAYoYWXi_BEmlU Subject: [dhcwg] MPL config draft (Re: [Roll] I-D Action: draft-ietf-roll-mpl-parameter-configuration-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: Mon, 07 Jul 2014 12:30:24 -0000 Hi, I've updated the proposal to control MPL parameter over DHCPv6 option. I believe this feature is required to use MPL over mesh networks in the wild, e.g. long-standing smart meter network etc. This proposal is a short one and I appreciate your review. Thanks! Yusuke (2014-07-02 00:58), internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. > > Title : MPL Parameter Configuration Option for DHCPv6 > Authors : Yusuke Doi > Matthew Gillmore > Filename : draft-ietf-roll-mpl-parameter-configuration-01.txt > Pages : 9 > Date : 2014-07-01 > > Abstract: > This draft defines a way to configure MPL parameter set via DHCPv6 > option. MPL has a set of parameters to control its behavior, and the > parameter set is often configured as a network-wide parameter because > the parameter set should be identical for each MPL forwarder in an > MPL domain. Using the MPL Parameter Configuration Option defined in > this document, a network can be configured with a single set of MPL > parameter easily. From nobody Mon Jul 7 09:32:32 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4F61A0366 for ; Mon, 7 Jul 2014 09:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable 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 jdu0U8aXauqE for ; Mon, 7 Jul 2014 09:32:27 -0700 (PDT) Received: from na3sys010aog108.obsmtp.com (na3sys010aog108.obsmtp.com [74.125.245.84]) by ietfa.amsl.com (Postfix) with SMTP id EB0281A035E for ; Mon, 7 Jul 2014 09:32:26 -0700 (PDT) Received: from mail-vc0-f173.google.com ([209.85.220.173]) (using TLSv1) by na3sys010aob108.postini.com ([74.125.244.12]) with SMTP ID DSNKU7rLmhaq84xC5iegTiTlBo5mv8h9CXrH@postini.com; Mon, 07 Jul 2014 09:32:27 PDT Received: by mail-vc0-f173.google.com with SMTP id lf12so4218854vcb.32 for ; Mon, 07 Jul 2014 09:32:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=uIE0TQjrG355JSj7CHdsl3SclKo/KBJ27ZttyJ0WMnc=; b=MQmkRsHubizMNyVyEPjcmqxaANR23sNtVSyjQQjAyCgQjoPw4KvIe2IdY+NRylJN1Y SljsiUqmc+aAJYcOWZudMvsfQfd94shZUR0zSRyqry9IJV76HkU6g8iijfrEJJsAGuyr uVB7aWLWaJJR9oEqDf275drA1FcSJfsBtOI3jDNgvbnyKTNZVWjmOwD00BPQFx/40qXI JUma7rwNO3RA5itfhgUySffVXzECYZmCQtOzsXg4wXjYjXLaxc8k1DcYgiexkZkD8KFK t5AXANO/Joknbjin9IAgnAaHarVT9cO0xl1byiDyTXJMyS9PoJ2HCYzwy8H64OAjMXHo cdCA== X-Gm-Message-State: ALoCoQnWz+Lr30y0SUw9MhRLj93Qo08CWjjf6VTzYFWRQ+p49MEIw6/RdEtwUDj2JJYcVSlvCgSZry/pofuZdHZGCVAZNPFwrt1W1LKgkuHxDAHm3KubBX/0t4u2zmFTLzaeCzoe9Txq X-Received: by 10.58.210.168 with SMTP id mv8mr28632822vec.12.1404750745834; Mon, 07 Jul 2014 09:32:25 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.58.210.168 with SMTP id mv8mr28632813vec.12.1404750745730; Mon, 07 Jul 2014 09:32:25 -0700 (PDT) Received: by 10.220.147.79 with HTTP; Mon, 7 Jul 2014 09:32:25 -0700 (PDT) In-Reply-To: <53BA92D9.3000606@toshiba.co.jp> References: <20140701155803.14047.81610.idtracker@ietfa.amsl.com> <53BA92D9.3000606@toshiba.co.jp> Date: Mon, 7 Jul 2014 09:32:25 -0700 Message-ID: From: Andre Kostur To: Yusuke DOI Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/Rw1ICTF_IoL1pot_X-zr8zATW4U Cc: "dhcwg@ietf.org" , Routing Over Low power and Lossy networks Subject: Re: [dhcwg] MPL config draft (Re: [Roll] I-D Action: draft-ietf-roll-mpl-parameter-configuration-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: Mon, 07 Jul 2014 16:32:29 -0000 A couple of quick thoughts (keeping in mind RFC 7227 - Guidelines for Creating New DHCPv6 Options): - An encoded option is frowned upon. Split all of those into separate options, and the "Reserved" parts simply disappear. A "sub-optioned" option is also frowned upon (section 9, RFC 7227). - Why add the additional complexity of the floating point? Why not use a 32-bit unsigned integer representing milliseconds which gets you a little over 40 days? Not the 18 weeks that you currently can represent, but is there a practical use for timers over a month long in MPL? - If you do go with separate options, consider what it would mean if certain options don't exist. ietf-roll-trickle-mcast appears to define defaults, perhaps reference that draft to say that if an option is missing, the client is to use the default defined in that draft? - Speaking of RFC 7227... I-D.ietf-dhc-option-guidelines got published in May -- Andre Kostur From nobody Mon Jul 7 10:19:17 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 373F81A014C; Mon, 7 Jul 2014 10:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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.651, 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 tuI2pZwEpIcT; Mon, 7 Jul 2014 10:19:12 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AB611A02EF; Mon, 7 Jul 2014 10:19:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2168; q=dns/txt; s=iport; t=1404753552; x=1405963152; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=9B0EsN0ekVZokkeaJiz2S9FHwNZb8jvNoX1FT+zWCRo=; b=YTSnOUEy6b8wXu8hY3ivom4WHGOCFXXI+DdGM7RrqIk6IWNeBsHISwzd Gs3Z4ZjfYIRqNC3o5WfsgVskNuAV86Q6/PhGn27SaNVJBRjWm3KOo+J4W dY1zlcwiWynyQpRIVJtSdswBvN6SNzUbQ2BKtYYAAlhwWEyrEyfYwlrT6 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFANnVulOtJV2d/2dsb2JhbABagw5SWr52h0UBgRkWdYQDAQEBBAEBATc0CwwEAgEIDgMEAQELFAUEBycLFAkIAgQBDQUIiDoNyWwTBI5UHTEHBoMngRYFrwKCAYFCgjA X-IronPort-AV: E=Sophos;i="5.01,619,1400025600"; d="scan'208";a="58876672" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-7.cisco.com with ESMTP; 07 Jul 2014 17:19:11 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s67HJBYM031148 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Jul 2014 17:19:11 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.176]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Mon, 7 Jul 2014 12:19:11 -0500 From: "Bernie Volz (volz)" To: Andre Kostur , Yusuke DOI Thread-Topic: [dhcwg] MPL config draft (Re: [Roll] I-D Action: draft-ietf-roll-mpl-parameter-configuration-01.txt) Thread-Index: AQHPmgEd2TBAYfQHIEyalFuCcQCzlpuU2QvA Date: Mon, 7 Jul 2014 17:19:11 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1B5E9CA7@xmb-rcd-x04.cisco.com> References: <20140701155803.14047.81610.idtracker@ietfa.amsl.com> <53BA92D9.3000606@toshiba.co.jp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/Yn03Cjwm2kGU1n70HpE4osFq0oU Cc: "dhcwg@ietf.org" , Routing Over Low power and Lossy networks Subject: Re: [dhcwg] MPL config draft (Re: [Roll] I-D Action: draft-ietf-roll-mpl-parameter-configuration-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: Mon, 07 Jul 2014 17:19:14 -0000 Hi: Not sure I'd suggest adding 10 (or 11) options for this? But I certainly would suggest, as Andre did, much simpler values - flags an= d "compressed" data just make for much more complex and error prone process= ing on both client and server. A structure which would have all these value= s but in a much more standard set of data formats would be better. Perhaps there is a middle grown to have groups of values (i.e., have 3-4 op= tions)? I'm really not that familiar with MPL, but perhaps there are some l= ogical groupings that make sense (seems that there are data and control mes= sages would could be one logical separation). Might also be nice in the Abstract to define MPL?=20 - Bernie -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Andre Kostur Sent: Monday, July 07, 2014 12:32 PM To: Yusuke DOI Cc: dhcwg@ietf.org; Routing Over Low power and Lossy networks Subject: Re: [dhcwg] MPL config draft (Re: [Roll] I-D Action: draft-ietf-ro= ll-mpl-parameter-configuration-01.txt) A couple of quick thoughts (keeping in mind RFC 7227 - Guidelines for Creat= ing New DHCPv6 Options): - An encoded option is frowned upon. Split all of those into separate opti= ons, and the "Reserved" parts simply disappear. A "sub-optioned" option is also frowned upon (section 9, RFC 7227). - Why add the additional complexity of the floating point? Why not use a 32-bit unsigned integer representing milliseconds which gets you a li= ttle over 40 days? Not the 18 weeks that you currently can represent, but = is there a practical use for timers over a month long in MPL? - If you do go with separate options, consider what it would mean if certai= n options don't exist. ietf-roll-trickle-mcast appears to define defaults,= perhaps reference that draft to say that if an option is missing, the clie= nt is to use the default defined in that draft? - Speaking of RFC 7227... I-D.ietf-dhc-option-guidelines got published in = May -- Andre Kostur _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From nobody Mon Jul 7 10:54:48 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2851A02EC for ; Mon, 7 Jul 2014 10:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 xEJ47yaVBwtN for ; Mon, 7 Jul 2014 10:54:44 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C018D1A0198 for ; Mon, 7 Jul 2014 10:54:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s67Hsiu4029263; Mon, 7 Jul 2014 10:54:44 -0700 Received: from XCH-PHX-212.sw.nos.boeing.com (xch-phx-212.sw.nos.boeing.com [130.247.25.141]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s67HshmL029251 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Mon, 7 Jul 2014 10:54:43 -0700 Received: from XCH-BLV-503.nw.nos.boeing.com (2002:82f7:19c0::82f7:19c0) by XCH-PHX-212.sw.nos.boeing.com (2002:82f7:198d::82f7:198d) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 7 Jul 2014 10:54:42 -0700 Received: from XCH-BLV-505.nw.nos.boeing.com ([169.254.5.55]) by XCH-BLV-503.nw.nos.boeing.com ([169.254.3.62]) with mapi id 14.03.0181.006; Mon, 7 Jul 2014 10:54:42 -0700 From: "Templin, Fred L" To: "dhcwg@ietf.org" Thread-Topic: Informational IPv6 prefix option for DHCPv6 Thread-Index: Ac+aDIcGSEduQ/YyTKOMsGQeKGSdbA== Date: Mon, 7 Jul 2014 17:54:41 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CB79A3@XCH-BLV-505.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/imnR5NTyV4zv5Ijd1bQF20EyvEk Subject: [dhcwg] Informational IPv6 prefix option for DHCPv6 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, 07 Jul 2014 17:54:46 -0000 Hi, I am looking for a DHCPv6 option that a server can use to report an IPv6 prefix to a client. This *would not* be used as a replacement for Router Advertisement Prefix Information Options (PIOs), and the client *would not* use the prefix for SLAAC. A DHCPv6 option that specifically returned an IPv6 prefix (along with prefix length) would be preferred. A DHCPv6 option that returned opaque data could also be used as a kludge but I would rather not have to do that. Is there a DHCPv6 option that would meet these requirements? Thanks - Fred fred.l.templin@boeing.com From nobody Mon Jul 7 11:22:50 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3B2E1A03C0 for ; Mon, 7 Jul 2014 11:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ff_tavzAMEJe for ; Mon, 7 Jul 2014 11:22:47 -0700 (PDT) Received: from na3sys010aog102.obsmtp.com (na3sys010aog102.obsmtp.com [74.125.245.72]) by ietfa.amsl.com (Postfix) with SMTP id 408341A02D5 for ; Mon, 7 Jul 2014 11:22:47 -0700 (PDT) Received: from mail-ve0-f173.google.com ([209.85.128.173]) (using TLSv1) by na3sys010aob102.postini.com ([74.125.244.12]) with SMTP ID DSNKU7rlduhh2E0QEZj+o8PFj2iwflWkk+Ld@postini.com; Mon, 07 Jul 2014 11:22:47 PDT Received: by mail-ve0-f173.google.com with SMTP id db11so4453514veb.4 for ; Mon, 07 Jul 2014 11:22:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=n/gn2Zm+HR8mhmTsMkvcQoD4qwELvjv7s4/cLPpN8tU=; b=Op6EpnYbNR1iXppnLsvHdRVo6k+iYKnPSeQ2VbIf+R9san2XK3o8i+op2VCQdGLJqn vAABvce1kI13W8A8JmsrBmifG0Sc0hfNmduFE4VAjQSuOeZK4eWmPgmuye40aSKCUFzx ulxf6sF1q2e/CcpsHA2J8XmePueVItGVah+5p8BoESrRqPQSFHtBOvacX5q8H0/TuXn6 F3Z2gvd+IrqYLlUUMwvG7Mhz8yCuQCZES7LegT+iTQjW+02P/PPvWbPReXJwXsubbdXn fI4DVexiwIf1IXoBZVLyVFHp2zpCA80YslRdEbAiX+EppSSgA00MqtcTF+00oRu/d2Dz 1zXw== X-Gm-Message-State: ALoCoQk/g0bygEDX440699K6XzX5X5qnbfOavA12kJprGDVGS3fdAOyqQWDFgS8ScmWlZSbc4gDxcBGycLqko1fdgbl8qaO9oNFLp5KQt2S0lf64kpfHYd51KLB4kX2T9XFVYp9OGEre X-Received: by 10.58.69.76 with SMTP id c12mr14160278veu.35.1404757366254; Mon, 07 Jul 2014 11:22:46 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.58.69.76 with SMTP id c12mr14160271veu.35.1404757366162; Mon, 07 Jul 2014 11:22:46 -0700 (PDT) Received: by 10.220.147.79 with HTTP; Mon, 7 Jul 2014 11:22:46 -0700 (PDT) In-Reply-To: <2134F8430051B64F815C691A62D9831832CB79A3@XCH-BLV-505.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832CB79A3@XCH-BLV-505.nw.nos.boeing.com> Date: Mon, 7 Jul 2014 11:22:46 -0700 Message-ID: From: Andre Kostur To: "Templin, Fred L" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/JmwljJSREkw6l17XCIrLqm9t_Ic Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Informational IPv6 prefix option for DHCPv6 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, 07 Jul 2014 18:22:49 -0000 Isn't that Prefix Delegation? RFC 3633. Nutshell is that the client can specifically ask the server for a prefix. Part of the plan is for routers deployed out at the edge, and they can ask the DHCP server for a prefix that the router will then manage on its further downstream links. On Mon, Jul 7, 2014 at 10:54 AM, Templin, Fred L wrote: > Hi, > > I am looking for a DHCPv6 option that a server can use to report an IPv6 > prefix to a client. This *would not* be used as a replacement for Router > Advertisement Prefix Information Options (PIOs), and the client *would > not* use the prefix for SLAAC. > > A DHCPv6 option that specifically returned an IPv6 prefix (along with > prefix length) would be preferred. A DHCPv6 option that returned opaque > data could also be used as a kludge but I would rather not have to do > that. Is there a DHCPv6 option that would meet these requirements? > > Thanks - Fred > fred.l.templin@boeing.com > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg -- Andre Kostur Distinguished Software Architect & Engineer P: 604-678-2864 E: akostur@incognito.com Toll-Free: 1-800-877-1856 F: 604-678-2864 VoIP: sip:864@sip.incognito.com From nobody Mon Jul 7 11:31:06 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 189241A02D5 for ; Mon, 7 Jul 2014 11:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LD5xMoGaixYp for ; Mon, 7 Jul 2014 11:31:04 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E17841A0305 for ; Mon, 7 Jul 2014 11:31:03 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id y10so68033wgg.22 for ; Mon, 07 Jul 2014 11:31:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=HvMpa1lfU5RnpcyRxZK7piTfsIwgYCM20Onabbd6oyk=; b=sQCVl9MlxVrc06Dto0fmeh9aM1BYO7+ISDDw0OpCBhgKIG2LUp3STWy2qU5pGWk3Is C95/mjkvcM3kg6IaPy9GUxKEnJ/oanYZbjVJcPhEjwtPnRp5TjXBn1Dd11XOv7wOaf3x mdAD/E+anQooMTlnHRDLlvo1lVoLcAwcDavCPFNOtkeKnlRJDs/wG2+ojR6Ece3DKSc6 RA4M2D7/JDTdyijmgwP0Vf77dHbX1ekzfLd6eqzfp686sILR3NU/2q6TceFGm5iSoVtC YvnIiuVOAPtKPzWVE8SfBqfsOT+nw91Un72Y/l9Mc/FV0iq88OZg+jU82CAdinT1QMER r9AA== MIME-Version: 1.0 X-Received: by 10.194.185.238 with SMTP id ff14mr34913549wjc.9.1404757862401; Mon, 07 Jul 2014 11:31:02 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.63.211 with HTTP; Mon, 7 Jul 2014 11:31:02 -0700 (PDT) In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1B5E859E@xmb-rcd-x04.cisco.com> References: <20140630163351.4191.69719.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E1B5E03D1@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1B5E859E@xmb-rcd-x04.cisco.com> Date: Mon, 7 Jul 2014 11:31:02 -0700 X-Google-Sender-Auth: KSDCaA3IKMndykHcnRY4D2c4zJA Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: "Bernie Volz (volz)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/--nRKePpz4N3LcZGVlqmD19N_0U Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.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, 07 Jul 2014 18:31:05 -0000 At Thu, 3 Jul 2014 18:26:10 +0000, "Bernie Volz (volz)" wrote: > Yes, that is the one issue with changing the status codes - it breaks bac= kwards compatibility. However, we already have changes that technically bre= ak this (such as the Advertise status codes). The risk for these changes sh= ould be fairly small as (1) clients are hopefully robust enough that they w= ill handle unknown/unexpected status codes and either 'ignore' the binding = (since it contains no addresses/prefixes) or restart at Solicit and (2) the= se are edge cases that may not have been well tested in all cases and are l= ikely to occur rarely (i.e., mostly impact Rebinds when 'new' bindings appe= ar which are probably not that common). I've thought this original behavior of RFC3315 intended recovery from a server crash. If a server crashes due to unexpected power cycle, a serious implementation bug, etc, and forgets all bindings it assigned before the crash, then the server will eventually receive a Renew (or Rebind) from clients that it previously served but "the server cannot find a client entry" (quoting 18.2.3 of RFC3315). With the original behavior, the server returns NoBindng, and the client will react to it by sending a Request. The server would probably be able to create the same binding(s) for the Request as it previously did, in which case the server crash is almost an opaque event for the client('s user). If the server returns NoAddrsAvail, and the client behaves similar to WIDE DHCPv6, however, the client will just ignore the Renew (and subsequently Rebind), and end up with using the "dangling" binding for much longer, increasing the risk of letting that binding be assigned to some other client. A server crash would be a rare event, but shouldn't be that rare that we cannot ignore IMO. So I'd be more careful if we change how to handle such cases. -- JINMEI, Tatuya From nobody Mon Jul 7 11:52:34 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E48D91B285D for ; Mon, 7 Jul 2014 11:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 L0PzMuEyk2rj for ; Mon, 7 Jul 2014 11:52:31 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61B391B27ED for ; Mon, 7 Jul 2014 11:52:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s67IqUAu016922; Mon, 7 Jul 2014 11:52:30 -0700 Received: from XCH-PHX-210.sw.nos.boeing.com (xch-phx-210.sw.nos.boeing.com [130.247.25.65]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s67IqL4D016400 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 7 Jul 2014 11:52:22 -0700 Received: from XCH-BLV-408.nw.nos.boeing.com (2002:82f7:19a6::82f7:19a6) by XCH-PHX-210.sw.nos.boeing.com (2002:82f7:1941::82f7:1941) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 7 Jul 2014 11:52:21 -0700 Received: from XCH-BLV-505.nw.nos.boeing.com ([169.254.5.55]) by XCH-BLV-408.nw.nos.boeing.com ([169.254.8.228]) with mapi id 14.03.0181.006; Mon, 7 Jul 2014 11:52:21 -0700 From: "Templin, Fred L" To: Andre Kostur Thread-Topic: [dhcwg] Informational IPv6 prefix option for DHCPv6 Thread-Index: Ac+aDIcGSEduQ/YyTKOMsGQeKGSdbAAPpiMAAA3A+WA= Date: Mon, 7 Jul 2014 18:52:21 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CB7ACC@XCH-BLV-505.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832CB79A3@XCH-BLV-505.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/vIJaeELuyl9D7jNc4N6Z_YbYY5I Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Informational IPv6 prefix option for DHCPv6 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, 07 Jul 2014 18:52:33 -0000 SGkgQW5kcmUsDQoNCk5vLCB0aGlzIGlzIG5vdCBQcmVmaXggRGVsZWdhdGlvbi4gRm9yIFBELCB0 aGUgREhDUHY2IHNlcnZlcg0KcmV0dXJucyBhbiBJUHY2IHByZWZpeCB0aGF0IHRoZSBjbGllbnQg dGhlbiB1c2VzIHRvIG51bWJlciBpdHMNCmRvd25zdHJlYW0tYXR0YWNoZWQgbGlua3MuIFdoYXQg SSB3YW50IGlzIGFuIGluZm9ybWF0aW9uYWwNCm9wdGlvbiB0aGF0IHBlcnRhaW5zIHRvIHRoZSBs aW5rIG92ZXIgd2hpY2ggdGhlIGNsaWVudCBjb250YWN0cw0KdGhlIHNlcnZlciwgYW5kIHRvIG15 IHVuZGVyc3RhbmRpbmcgUEQgY2Fubm90IGJlIHVzZWQgZm9yIHRoYXQuDQoNClRoYW5rcyAtIEZy ZWQNCmZyZWQubC50ZW1wbGluQGJvZWluZy5jb20NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBBbmRyZSBLb3N0dXIgW21haWx0bzpha29zdHVyQGluY29nbml0by5jb21d DQo+IFNlbnQ6IE1vbmRheSwgSnVseSAwNywgMjAxNCAxMToyMyBBTQ0KPiBUbzogVGVtcGxpbiwg RnJlZCBMDQo+IENjOiBkaGN3Z0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW2RoY3dnXSBJbmZv cm1hdGlvbmFsIElQdjYgcHJlZml4IG9wdGlvbiBmb3IgREhDUHY2DQo+IA0KPiBJc24ndCB0aGF0 IFByZWZpeCBEZWxlZ2F0aW9uPyBSRkMgMzYzMy4gIE51dHNoZWxsIGlzIHRoYXQgdGhlIGNsaWVu dA0KPiBjYW4gc3BlY2lmaWNhbGx5IGFzayB0aGUgc2VydmVyIGZvciBhIHByZWZpeC4gIFBhcnQg b2YgdGhlIHBsYW4gaXMgZm9yDQo+IHJvdXRlcnMgZGVwbG95ZWQgb3V0IGF0IHRoZSBlZGdlLCBh bmQgdGhleSBjYW4gYXNrIHRoZSBESENQIHNlcnZlciBmb3INCj4gYSBwcmVmaXggdGhhdCB0aGUg cm91dGVyIHdpbGwgdGhlbiBtYW5hZ2Ugb24gaXRzIGZ1cnRoZXIgZG93bnN0cmVhbQ0KPiBsaW5r cy4NCj4gDQo+IE9uIE1vbiwgSnVsIDcsIDIwMTQgYXQgMTA6NTQgQU0sIFRlbXBsaW4sIEZyZWQg TA0KPiA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4gd3JvdGU6DQo+ID4gSGksDQo+ID4NCj4g PiBJIGFtIGxvb2tpbmcgZm9yIGEgREhDUHY2IG9wdGlvbiB0aGF0IGEgc2VydmVyIGNhbiB1c2Ug dG8gcmVwb3J0IGFuIElQdjYNCj4gPiBwcmVmaXggdG8gYSBjbGllbnQuIFRoaXMgKndvdWxkIG5v dCogYmUgdXNlZCBhcyBhIHJlcGxhY2VtZW50IGZvciBSb3V0ZXINCj4gPiBBZHZlcnRpc2VtZW50 IFByZWZpeCBJbmZvcm1hdGlvbiBPcHRpb25zIChQSU9zKSwgYW5kIHRoZSBjbGllbnQgKndvdWxk DQo+ID4gbm90KiB1c2UgdGhlIHByZWZpeCBmb3IgU0xBQUMuDQo+ID4NCj4gPiBBIERIQ1B2NiBv cHRpb24gdGhhdCBzcGVjaWZpY2FsbHkgcmV0dXJuZWQgYW4gSVB2NiBwcmVmaXggKGFsb25nIHdp dGgNCj4gPiBwcmVmaXggbGVuZ3RoKSB3b3VsZCBiZSBwcmVmZXJyZWQuIEEgREhDUHY2IG9wdGlv biB0aGF0IHJldHVybmVkIG9wYXF1ZQ0KPiA+IGRhdGEgY291bGQgYWxzbyBiZSB1c2VkIGFzIGEg a2x1ZGdlIGJ1dCBJIHdvdWxkIHJhdGhlciBub3QgaGF2ZSB0byBkbw0KPiA+IHRoYXQuIElzIHRo ZXJlIGEgREhDUHY2IG9wdGlvbiB0aGF0IHdvdWxkIG1lZXQgdGhlc2UgcmVxdWlyZW1lbnRzPw0K PiA+DQo+ID4gVGhhbmtzIC0gRnJlZA0KPiA+IGZyZWQubC50ZW1wbGluQGJvZWluZy5jb20NCj4g Pg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4gZGhjd2cgbWFpbGluZyBsaXN0DQo+ID4gZGhjd2dAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dnDQo+IA0KPiANCj4gDQo+IC0tDQo+IEFu ZHJlIEtvc3R1cg0KPiBEaXN0aW5ndWlzaGVkIFNvZnR3YXJlIEFyY2hpdGVjdCAmIEVuZ2luZWVy DQo+IFA6IDYwNC02NzgtMjg2NA0KPiBFOiBha29zdHVyQGluY29nbml0by5jb20NCj4gVG9sbC1G cmVlOiAxLTgwMC04NzctMTg1Ng0KPiANCj4gDQo+IEY6IDYwNC02NzgtMjg2NA0KPiBWb0lQOiBz aXA6ODY0QHNpcC5pbmNvZ25pdG8uY29tDQo= From nobody Mon Jul 7 12:18:37 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D74A1B285D for ; Mon, 7 Jul 2014 12:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.852 X-Spam-Level: X-Spam-Status: No, score=-14.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 rpIE4Ue4uML8 for ; Mon, 7 Jul 2014 12:18:32 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95DEE1A0357 for ; Mon, 7 Jul 2014 12:18:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7378; q=dns/txt; s=iport; t=1404760712; x=1405970312; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=mp4FcyFRiTUEQnVdRqjEgIVezUvLzT8ro7m2Kc29oEA=; b=mNohjPgpJVR8Z6deSLIWjbZsxmq2suvHVbeqMn2YKSau/yJF7OCe2MLj d7FjtMYtvO9fR9QMeK4BEg+TNZ0vZasn5JuaWUJICaHJrNd22/tmqVUtl G2QhTRNfFGYYf79FY7bKdcBcOMMd2nuyMB4N4bzd1WvcSJTmGve/Qbjiv A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAE/xulOtJV2d/2dsb2JhbABZgw6BLIJvw00BGYECFnWEAwEBAQMBIxFFBQcEAgEIEQQBAQMCBh0DAgICHxEUAQgIAgQOBQgTiBMDCQiwCZNFDYV9F4Esi06BWh0WGwcGgnE2gRYBBJYWgmCPeIYUg0OCMA X-IronPort-AV: E=Sophos;i="5.01,620,1400025600"; d="scan'208";a="338291303" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 07 Jul 2014 19:18:31 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s67JIVHW030584 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Jul 2014 19:18:31 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.176]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Mon, 7 Jul 2014 14:18:31 -0500 From: "Bernie Volz (volz)" To: =?utf-8?B?56We5piO6YGU5ZOJ?= Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.txt Thread-Index: AQHPlIEus6CA5H78HkuHLmw+Sv8Eh5uJ3xfAgAUDK4D//8m40IAGogoA//+yrVA= Date: Mon, 7 Jul 2014 19:18:31 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1B5EA937@xmb-rcd-x04.cisco.com> References: <20140630163351.4191.69719.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E1B5E03D1@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1B5E859E@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.243.80] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/xkzvjaWpjpiMWEkMGEaymuqTPJ8 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.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, 07 Jul 2014 19:18:34 -0000 VGhpcyBpcyBpbmRlZWQgYW4gaW50ZXJlc3RpbmcgY2FzZSB0byBjb25zaWRlci4NCg0KRmlyc3Qs IG15IG93biBmZWVsaW5nIGlzIHRoYXQgYXQgbGVhc3QgZm9yIGEgUmVuZXcsIGlmIHRoZSBzZXJ2 ZXIgaGFzIG5vIHJlY29yZCBvZiB0aGUgY2xpZW50IGF0IGFsbCBbb24gdGhhdCBwYXJ0aWN1bGFy IGxpbmtdLCBJIHRoaW5rIGl0IHNob3VsZCBkZWZpbml0ZWx5IHJldHVybiBOb0JpbmRpbmcuIFRo ZSBpbnRlbnQgd2l0aCB0aGUgYmVpbmcgYWJsZSB0byBhZGQgYSAnbmV3JyBiaW5kaW5nIHRvIGFu IGV4aXN0aW5nIHNldCBpbiB0aGUgUmVuZXcgd2FzIG5vdCB0byBhbGxvdyBhIGNsaWVudCB0byBl c3NlbnRpYWxseSAnc3RhcnQgYXQgUmVuZXcnLiBJIGRpZG4ndCBjaGVjayB0aGUgbGF0ZXN0IFN0 YXRlZnVsIElzc3VlcyB0ZXh0IGJ1dCBpZiB3ZSBkb24ndCBoYXZlIHRoYXQgdGhlcmUsIHdlIGRv IG5lZWQgdG8gY2xlYW4gdGhpcyB1cCB0byBhZGQgaXQuIFRoaXMgd291bGQgSSB0aGluayBzb2x2 ZSB0aGlzIGlzc3VlIGZvciBSZW5ldy4gTm90ZSBhbHNvIHRoYXQgZm9yIGFueSBhZGRyZXNzZXMv cHJlZml4ZXMgdGhhdCB0aGUgY2xpZW50IGNsYWltcyBpdCBpcyB1c2luZyAoaS5lLiwgYnkgcHJv dmlkaW5nIHRoZW0gaW4gdGhlIFJlbmV3KSBidXQgdGhlIHNlcnZlciBkb2VzIG5vdCBoYXZlLCB0 aGUgc2VydmVyIG11c3QgZWl0aGVyICgxKSBhc3NpZ24gdGhlIGFkZHJlc3MvcHJlZml4IGlmIHRo ZXJlIGlzIG5vIGNvbmZsaWN0IG9yICgyKSByZXR1cm4gMCBsaWZldGltZXMgaWYgdGhlcmUgaXMg YSBjb25mbGljdC4NCg0KUmViaW5kIGluIHRoaXMgcGFydGljdWxhciBjYXNlIGlzIG1vcmUgZGlm ZmljdWx0LCBzaW5jZSB0aGUgc2VydmVyIGRvZXNuJ3Qga25vdyB3aGV0aGVyIHRoZSBiaW5kaW5n cyBhcmUgJ2V4aXN0aW5nJyBvciAnYWRkaXRpb25hbCcgKGV4Y2VwdCBwZXJoYXBzIHdoZXRoZXIg YW55IGFkZHJlc3Nlcy9wcmVmaXhlcyBhcmUgcHJlc2VudCBpbiB0aGUgUmViaW5kKS4gQnV0IGlu IHRoaXMgY2FzZSB3ZSdyZSBub3QgcmVhbGx5IGluIHRyb3VibGUgYXQgYWxsIHNpbmNlIHRoZSBz ZXJ2ZXIgU0hPVUxEIGJlIGFzc2lnbmluZyB0aGUgY2xpZW50IGFueSBleGlzdGluZyBhZGRyZXNz ZXMgb3IgcHJlZml4ZXMgaW4gdGhlIFJlYmluZCByZXF1ZXN0IC0gdW5sZXNzIGl0IGlzIHVuYWJs ZSB0byBkbyBzbyBiZWNhdXNlIGl0IGhhcyBjb25mbGljdGluZyBpbmZvcm1hdGlvbi4gVGhlIE5v QWRkckF2YWlsL05vUHJlZml4QXZhaWwgaXMgb25seSBpbiB0aGUgY2FzZSB3aGVyZSB0aGUgYmlu ZGluZyBoYXMgbm8gbGVhc2VzIGFuZCB0aGUgc2VydmVyIGlzIHVuYWJsZSB0byBhbGxvY2F0ZSBv bmVzLg0KDQpUaGUgaW1wb3J0YW50IHBvaW50IGhlcmUgaXMgdGhhdCBSZWJpbmQgaXMgYWx3YXlz IGFzc3VtZWQgdG8gYXNzaWduIHRoZSBhZGRyZXNzZXMvcHJlZml4ZXMgdGhlIGNsaWVudCBjbGFp bXMgaXQgaXMgY3VycmVudGx5IHVzaW5nIChvZiBjb3Vyc2UgaWYgdGhlIHNlcnZlciBoYXMgY29u ZmxpY3RpbmcgaW5mb3JtYXRpb24sIGl0IGNhbiByZXR1cm4gdGhlIGFkZHJlc3Nlcy9wcmVmaXhl cyB3aXRoIDAgbGlmZXRpbWVzKS4NCg0KVGhlIHBvaW50cyB0aGF0IGFyZSBpbXBvcnRhbnQgaGVy ZToNCi0gRm9yIGEgU29saWNpdCBhbmQgUmVxdWVzdCwgdGhlIHNlcnZlciBhc3N1bWVzIHRoYXQg dGhlIGNsaWVudCBpcyBOT1QgcHJlc2VudGx5IHVzaW5nIGFueSBvZiB0aGUgYWRkcmVzc2VzL3By ZWZpeGVzIHNwZWNpZmllZC4gVGhlcmVmb3JlLCBpdCBpcyBtdWNoIGZyZWVyIHRvIGlnbm9yZSB0 aGVzZSAoaS5lLiwgdHJlYXQgdGhlbSBhcyB2ZXJ5ICJtaWxkIiBoaW50cykuDQotIEZvciBhIFJl bmV3IGFuZCBSZWJpbmQsIHRoZSBzZXJ2ZXIgTVVTVCBhc3N1bWUgdGhhdCB0aGUgY2xpZW50IGlz IHByZXNlbnRseSB1c2luZyBhbnkgb2YgdGhlIGFkZHJlc3Nlcy9wcmVmaXhlcyBzcGVjaWZpZWQg KGV4Y2VwdGluZyBhIGhpbnQgd2l0aCAwOjowKS4gVGhlIHNlcnZlciBNVVNUIGVpdGhlciBhbGxv Y2F0ZSB0aGUgYWRkcmVzcy9wcmVmaXggKGlmIG5vdCBhbHJlYWR5IGV4aXN0aW5nKSBvciBtdXN0 IHJldHVybiAwIGxpZmV0aW1lcyB0byBpbmRpY2F0ZSB0byB0aGUgY2xpZW50IHRvIHN0b3AgdXNp bmcgdGhlIGFkZHJlc3Nlcy9wcmVmaXhlcy4NCg0KTm90ZSBhbHNvIHRoYXQgaXQgaXMgaW1wb3J0 YW50IGZvciBhIGNsaWVudCB0byBzZW5kIGl0cyBjdXJyZW50IGFkZHJlc3Nlcy9wcmVmaXhlcyB3 aGVuIHNlbmRpbmcgYSBSZW5ldy9SZWJpbmQuDQoNCg0KU28sIEkgZG9uJ3QgdGhpbmsgdGhlcmUg YXJlIGFueSBpc3N1ZSB3aXRoIHRoaXMgY2FzZSBpZiBvbiB0aGVSZW5ldy9SZWJpbmQgdGhlIHNl cnZlciBzZW5kcyB0aGUgTm9BZGRyc0F2YWlsL05vUHJlZml4QXZhaWwgZm9yIGEgJ25ldycgYmlu ZGluZyB0aGF0IGhhcyBubyAnaW4tdXNlJyBhZGRyZXNzL3ByZWZpeCBwcmVzZW50IGJ5IHRoZSBj bGllbnQuDQoNCg0KTm90ZTogVGhpcyBzaXR1YXRpb24gaXMgYSBiaXQgdHJpY2t5IGFueXdheSBz aW5jZSB0aGVyZSBpcyBubyB3YXkgZm9yIHRoZSBzZXJ2ZXIgdG8ga25vdyB3aGF0IGFkZHJlc3Nl cy9wcmVmaXhlcyBhcmUgaW4gdXNlLiBBbmQgdGhlIHNlcnZlciBtYXkgd2VsbCBhc3NpZ24gYSBj bGllbnQgdGhhdCBzZW5kcyBhIFNvbGljaXQgKC9SZXF1ZXN0KSBhbiBhZGRyZXNzIG9yIHByZWZp eCB0aGF0IGlzIGFscmVhZHkgaW4gdXNlIGJ5IGFub3RoZXIgY2xpZW50LCBiZWZvcmUgdGhhdCBv dGhlciBjbGllbnQgc2VuZHMgYSBSZW5ldy9SZWJpbmQuIChUaGlzIGlzIG9uZSBvZiB0aGUgcmVh c29ucyB0aGF0IEZhaWxvdmVyIGhhcyB3b3JrZWQgb3V0IHdlbGwgaW4gREhDUHY0IC0gc2luY2Ug aXQgcHJvdmlkZXMgYW5vdGhlciBwbGFjZSBmb3IgdGhlIGRhdGEgdG8gYmUgc3RvcmVkIHRvIGF2 b2lkIGxvc3Mgb2Ygc3RhdGUpLiBJIGd1ZXNzIG9uZSAic29sdXRpb24iIG1pZ2h0IGJlIHRvIG5v dCBhbGxvdyBuZXcgYWRkcmVzc2VzL3ByZWZpeGVzIHRvIGJlIGFzc2lnbmVkIGZvciB3aGF0ZXZl ciBsaWZldGltZSB3b3VsZCBhc3N1cmUgYXQgbGVhc2UgYSBSZW5ldyAoaS5lLiwgPjUwJSBvZiB0 aGUgbGVhc2UgdGltZSkuIEJ1dCB0aGF0IGlzIG5vdCBuaWNlIHRvIG5ldyBjbGllbnRzIGVpdGhl ciA6KS4NCg0KLSBCZXJuaWUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGpp bm1laS50YXR1eWFAZ21haWwuY29tIFttYWlsdG86amlubWVpLnRhdHV5YUBnbWFpbC5jb21dIE9u IEJlaGFsZiBPZiA/Pz8/DQpTZW50OiBNb25kYXksIEp1bHkgMDcsIDIwMTQgMjozMSBQTQ0KVG86 IEJlcm5pZSBWb2x6ICh2b2x6KQ0KQ2M6IGRoY3dnQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2Ro Y3dnXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWRoYy1kaGNwdjYtc3RhdGVmdWwtaXNzdWVzLTA2 LnR4dA0KDQpBdCBUaHUsIDMgSnVsIDIwMTQgMTg6MjY6MTAgKzAwMDAsDQoiQmVybmllIFZvbHog KHZvbHopIiA8dm9sekBjaXNjby5jb20+IHdyb3RlOg0KDQo+IFllcywgdGhhdCBpcyB0aGUgb25l IGlzc3VlIHdpdGggY2hhbmdpbmcgdGhlIHN0YXR1cyBjb2RlcyAtIGl0IGJyZWFrcyBiYWNrd2Fy ZHMgY29tcGF0aWJpbGl0eS4gSG93ZXZlciwgd2UgYWxyZWFkeSBoYXZlIGNoYW5nZXMgdGhhdCB0 ZWNobmljYWxseSBicmVhayB0aGlzIChzdWNoIGFzIHRoZSBBZHZlcnRpc2Ugc3RhdHVzIGNvZGVz KS4gVGhlIHJpc2sgZm9yIHRoZXNlIGNoYW5nZXMgc2hvdWxkIGJlIGZhaXJseSBzbWFsbCBhcyAo MSkgY2xpZW50cyBhcmUgaG9wZWZ1bGx5IHJvYnVzdCBlbm91Z2ggdGhhdCB0aGV5IHdpbGwgaGFu ZGxlIHVua25vd24vdW5leHBlY3RlZCBzdGF0dXMgY29kZXMgYW5kIGVpdGhlciAnaWdub3JlJyB0 aGUgYmluZGluZyAoc2luY2UgaXQgY29udGFpbnMgbm8gYWRkcmVzc2VzL3ByZWZpeGVzKSBvciBy ZXN0YXJ0IGF0IFNvbGljaXQgYW5kICgyKSB0aGVzZSBhcmUgZWRnZSBjYXNlcyB0aGF0IG1heSBu b3QgaGF2ZSBiZWVuIHdlbGwgdGVzdGVkIGluIGFsbCBjYXNlcyBhbmQgYXJlIGxpa2VseSB0byBv Y2N1ciByYXJlbHkgKGkuZS4sIG1vc3RseSBpbXBhY3QgUmViaW5kcyB3aGVuICduZXcnIGJpbmRp bmdzIGFwcGVhciB3aGljaCBhcmUgcHJvYmFibHkgbm90IHRoYXQgY29tbW9uKS4NCg0KSSd2ZSB0 aG91Z2h0IHRoaXMgb3JpZ2luYWwgYmVoYXZpb3Igb2YgUkZDMzMxNSBpbnRlbmRlZCByZWNvdmVy eSBmcm9tIGEgc2VydmVyIGNyYXNoLiAgSWYgYSBzZXJ2ZXIgY3Jhc2hlcyBkdWUgdG8gdW5leHBl Y3RlZCBwb3dlciBjeWNsZSwgYSBzZXJpb3VzIGltcGxlbWVudGF0aW9uIGJ1ZywgZXRjLCBhbmQg Zm9yZ2V0cyBhbGwgYmluZGluZ3MgaXQgYXNzaWduZWQgYmVmb3JlIHRoZSBjcmFzaCwgdGhlbiB0 aGUgc2VydmVyIHdpbGwgZXZlbnR1YWxseSByZWNlaXZlIGEgUmVuZXcgKG9yDQpSZWJpbmQpIGZy b20gY2xpZW50cyB0aGF0IGl0IHByZXZpb3VzbHkgc2VydmVkIGJ1dCAidGhlIHNlcnZlciBjYW5u b3QgZmluZCBhIGNsaWVudCBlbnRyeSIgKHF1b3RpbmcgMTguMi4zIG9mIFJGQzMzMTUpLiAgV2l0 aCB0aGUgb3JpZ2luYWwgYmVoYXZpb3IsIHRoZSBzZXJ2ZXIgcmV0dXJucyBOb0JpbmRuZywgYW5k IHRoZSBjbGllbnQgd2lsbCByZWFjdCB0byBpdCBieSBzZW5kaW5nIGEgUmVxdWVzdC4gIFRoZSBz ZXJ2ZXIgd291bGQgcHJvYmFibHkgYmUgYWJsZSB0byBjcmVhdGUgdGhlIHNhbWUgYmluZGluZyhz KSBmb3IgdGhlIFJlcXVlc3QgYXMgaXQgcHJldmlvdXNseSBkaWQsIGluIHdoaWNoIGNhc2UgdGhl IHNlcnZlciBjcmFzaCBpcyBhbG1vc3QgYW4gb3BhcXVlIGV2ZW50IGZvciB0aGUgY2xpZW50KCdz IHVzZXIpLg0KDQpJZiB0aGUgc2VydmVyIHJldHVybnMgTm9BZGRyc0F2YWlsLCBhbmQgdGhlIGNs aWVudCBiZWhhdmVzIHNpbWlsYXIgdG8gV0lERSBESENQdjYsIGhvd2V2ZXIsIHRoZSBjbGllbnQg d2lsbCBqdXN0IGlnbm9yZSB0aGUgUmVuZXcgKGFuZCBzdWJzZXF1ZW50bHkgUmViaW5kKSwgYW5k IGVuZCB1cCB3aXRoIHVzaW5nIHRoZSAiZGFuZ2xpbmciIGJpbmRpbmcgZm9yIG11Y2ggbG9uZ2Vy LCBpbmNyZWFzaW5nIHRoZSByaXNrIG9mIGxldHRpbmcgdGhhdCBiaW5kaW5nIGJlIGFzc2lnbmVk IHRvIHNvbWUgb3RoZXIgY2xpZW50Lg0KDQpBIHNlcnZlciBjcmFzaCB3b3VsZCBiZSBhIHJhcmUg ZXZlbnQsIGJ1dCBzaG91bGRuJ3QgYmUgdGhhdCByYXJlIHRoYXQgd2UgY2Fubm90IGlnbm9yZSBJ TU8uICBTbyBJJ2QgYmUgbW9yZSBjYXJlZnVsIGlmIHdlIGNoYW5nZSBob3cgdG8gaGFuZGxlIHN1 Y2ggY2FzZXMuDQoNCi0tDQpKSU5NRUksIFRhdHV5YQ0K From nobody Mon Jul 7 12:27:34 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16B0F1B2870 for ; Mon, 7 Jul 2014 12:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WF62C6lnS498 for ; Mon, 7 Jul 2014 12:27:30 -0700 (PDT) Received: from na3sys010aog105.obsmtp.com (na3sys010aog105.obsmtp.com [74.125.245.78]) by ietfa.amsl.com (Postfix) with SMTP id 34B9F1B286D for ; Mon, 7 Jul 2014 12:27:29 -0700 (PDT) Received: from mail-vc0-f179.google.com ([209.85.220.179]) (using TLSv1) by na3sys010aob105.postini.com ([74.125.244.12]) with SMTP ID DSNKU7r0oSGbrZap3wuC0NLM3wi6XugjUKCy@postini.com; Mon, 07 Jul 2014 12:27:30 PDT Received: by mail-vc0-f179.google.com with SMTP id id10so4404690vcb.38 for ; Mon, 07 Jul 2014 12:27:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Hz5NH+FiOPd3Ciq3qGPcZ5AXKImPEJUbXLRyNSOB3nY=; b=WERGx+rtGyj1J72AuFQ2wC0XFaWLuVDH0aIoLrPkreLMjUYWwv2jpw5b1Rn6o62SWu 70VynOBc+TZzwp9OjReUa2lLTAz9nb47mD/pzP90E4V+jDLOLInS4whufM3ryagLwGvx CTH9TOi7vt8KI1LLBqUJE4/R+71HSNejml/6lcUX0esFe7VT6BXLIJuNlTMeQXhfsdEK eiMlG20a4rImU+JtjoOdqZIVJyFMPvOdAzqK3No89XrVxUuuRo12hGVuMDVn9so17itI hp+K33SJmhGNvsxOhlHzOW8Qb5jnVC7Sqb+YieBKgaZZlYCpySyZbzwxCNbubzLij9Ay rRTQ== X-Gm-Message-State: ALoCoQkPamQlW9UxqBHp+4ZBo2d38jwPdPEPPFstVuI7gk7xDuLQATRSm3lOU0T3AnRwRsPK/bgVa2LO9nsAnJdSJJnZ06tzJbalUZEI5tvyYcMJak1OVaiGqMeyYhPXae6RxlVG4vli X-Received: by 10.52.189.161 with SMTP id gj1mr24579221vdc.2.1404761249055; Mon, 07 Jul 2014 12:27:29 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.52.189.161 with SMTP id gj1mr24579216vdc.2.1404761248966; Mon, 07 Jul 2014 12:27:28 -0700 (PDT) Received: by 10.220.147.79 with HTTP; Mon, 7 Jul 2014 12:27:28 -0700 (PDT) In-Reply-To: <2134F8430051B64F815C691A62D9831832CB7ACC@XCH-BLV-505.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832CB79A3@XCH-BLV-505.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CB7ACC@XCH-BLV-505.nw.nos.boeing.com> Date: Mon, 7 Jul 2014 12:27:28 -0700 Message-ID: From: Andre Kostur To: "Templin, Fred L" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/hsgp1wFUvK5ekicB1GKJvsiRZBc Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Informational IPv6 prefix option for DHCPv6 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, 07 Jul 2014 19:27:33 -0000 Then I'm not sure of the purpose of this information. The client got an IPv6 address from somewhere, so it should be able to know its prefix from that. What's the client supposed to do with this information that it's getting from DHCP? On Mon, Jul 7, 2014 at 11:52 AM, Templin, Fred L wrote: > Hi Andre, > > No, this is not Prefix Delegation. For PD, the DHCPv6 server > returns an IPv6 prefix that the client then uses to number its > downstream-attached links. What I want is an informational > option that pertains to the link over which the client contacts > the server, and to my understanding PD cannot be used for that. > > Thanks - Fred > fred.l.templin@boeing.com > >> -----Original Message----- >> From: Andre Kostur [mailto:akostur@incognito.com] >> Sent: Monday, July 07, 2014 11:23 AM >> To: Templin, Fred L >> Cc: dhcwg@ietf.org >> Subject: Re: [dhcwg] Informational IPv6 prefix option for DHCPv6 >> >> Isn't that Prefix Delegation? RFC 3633. Nutshell is that the client >> can specifically ask the server for a prefix. Part of the plan is for >> routers deployed out at the edge, and they can ask the DHCP server for >> a prefix that the router will then manage on its further downstream >> links. >> >> On Mon, Jul 7, 2014 at 10:54 AM, Templin, Fred L >> wrote: >> > Hi, >> > >> > I am looking for a DHCPv6 option that a server can use to report an IPv6 >> > prefix to a client. This *would not* be used as a replacement for Router >> > Advertisement Prefix Information Options (PIOs), and the client *would >> > not* use the prefix for SLAAC. >> > >> > A DHCPv6 option that specifically returned an IPv6 prefix (along with >> > prefix length) would be preferred. A DHCPv6 option that returned opaque >> > data could also be used as a kludge but I would rather not have to do >> > that. Is there a DHCPv6 option that would meet these requirements? >> > >> > Thanks - Fred >> > fred.l.templin@boeing.com >> > >> > _______________________________________________ >> > dhcwg mailing list >> > dhcwg@ietf.org >> > https://www.ietf.org/mailman/listinfo/dhcwg >> >> >> >> -- >> Andre Kostur -- Andre Kostur From nobody Mon Jul 7 12:44:30 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C98E1B28A5 for ; Mon, 7 Jul 2014 12:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 Pcz2H8fT1c0I for ; Mon, 7 Jul 2014 12:44:27 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 894631A0A88 for ; Mon, 7 Jul 2014 12:44:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s67JiQYN020402; Mon, 7 Jul 2014 14:44:26 -0500 Received: from XCH-PHX-112.sw.nos.boeing.com (xch-phx-112.sw.nos.boeing.com [130.247.25.134]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s67JiKFu020365 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 7 Jul 2014 14:44:21 -0500 Received: from XCH-BLV-104.nw.nos.boeing.com (2002:82f7:1978::82f7:1978) by XCH-PHX-112.sw.nos.boeing.com (2002:82f7:1986::82f7:1986) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 7 Jul 2014 12:44:19 -0700 Received: from XCH-BLV-505.nw.nos.boeing.com ([169.254.5.55]) by XCH-BLV-104.nw.nos.boeing.com ([169.254.4.243]) with mapi id 14.03.0181.006; Mon, 7 Jul 2014 12:44:19 -0700 From: "Templin, Fred L" To: Andre Kostur Thread-Topic: [dhcwg] Informational IPv6 prefix option for DHCPv6 Thread-Index: Ac+aDIcGSEduQ/YyTKOMsGQeKGSdbAAPpiMAAA3A+WD//6QLAIAAdDfg Date: Mon, 7 Jul 2014 19:44:18 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CB7B59@XCH-BLV-505.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832CB79A3@XCH-BLV-505.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CB7ACC@XCH-BLV-505.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/u3JcsvWAiWkIDBK_T7Br9W7VZU0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Informational IPv6 prefix option for DHCPv6 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, 07 Jul 2014 19:44:29 -0000 SGkgQW5kcmUsDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQW5kcmUg S29zdHVyIFttYWlsdG86YWtvc3R1ckBpbmNvZ25pdG8uY29tXQ0KPiBTZW50OiBNb25kYXksIEp1 bHkgMDcsIDIwMTQgMTI6MjcgUE0NCj4gVG86IFRlbXBsaW4sIEZyZWQgTA0KPiBDYzogZGhjd2dA aWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtkaGN3Z10gSW5mb3JtYXRpb25hbCBJUHY2IHByZWZp eCBvcHRpb24gZm9yIERIQ1B2Ng0KPiANCj4gVGhlbiBJJ20gbm90IHN1cmUgb2YgdGhlIHB1cnBv c2Ugb2YgdGhpcyBpbmZvcm1hdGlvbi4gIFRoZSBjbGllbnQgZ290DQo+IGFuIElQdjYgYWRkcmVz cyBmcm9tIHNvbWV3aGVyZSwgc28gaXQgc2hvdWxkIGJlIGFibGUgdG8ga25vdyBpdHMNCj4gcHJl Zml4IGZyb20gdGhhdC4gIFdoYXQncyB0aGUgY2xpZW50IHN1cHBvc2VkIHRvIGRvIHdpdGggdGhp cw0KPiBpbmZvcm1hdGlvbiB0aGF0IGl0J3MgZ2V0dGluZyBmcm9tIERIQ1A/DQoNCkl0IGlzIGZv ciBhIGxpbmsgdHlwZSBvbiB3aGljaCB0aGVyZSBpcyBubyBub24tbGluay1sb2NhbCBJUHY2IHBy ZWZpeA0KYXNzaWduZWQuIFRoZSBsaW5rIGNvbm5lY3RzIGEgYnVuY2ggb2Ygcm91dGVycyB0aGF0 IG9ubHkgY29uZmlndXJlIGENCmxpbmstbG9jYWwgYWRkcmVzcyBvbiB0aGUgbGluay4gVGhlIHJv dXRlcnMgYWxzbyBhY3QgYXMgREhDUHY2IGNsaWVudHMsDQphbmQgYWN0IGFzIHJlcXVlc3Rpbmcg cm91dGVycyB1c2luZyBESENQdjYgUEQgdG8gZ2V0IGEgcHJlZml4IHRvIGFzc2lnbg0KdG8gdGhl aXIgZG93bnN0cmVhbSBhdHRhY2hlZCBsaW5rcy4NCg0KVGhlIElQdjYgcHJlZml4IEkgd2FudCB0 byBpbmNsdWRlIGluIHRoZSBESENQdjYgb3B0aW9uIEkgYW0gYXNraW5nIGZvcg0KaXMgdGhlIGFn Z3JlZ2F0ZWQgcHJlZml4IGZyb20gd2hpY2ggY2xpZW50IHByZWZpeGVzIGFyZSBkZWxlZ2F0ZWQu IFNvLA0KaWYgdGhlIGFnZ3JlZ2F0ZWQgcHJlZml4IGlzIDIwMDE6ZGI4OjovMzIsIHRoZW4gdGhl IGNsaWVudHMgd291bGQgYmUNCmRlbGVnYXRlZCBsb25nZXIgcHJlZml4ZXMgc3VjaCBhcyAyMDAx OmRiODo0MDAwOjovNDgsIDIwMDE6ZGI4OjE6Oi81NiwNCjIwMDE6ZGI4OjIxOjMxOjovNjQsIGV0 Yy4NCg0KU28sIHRoZSBhZ2dyZWdhdGVkIHByZWZpeCBpcyBub3QgYXNzaWduZWQgKnRvKiB0aGUg bGluaywgYnV0IHJhdGhlcg0KdGVsbHMgdGhlIHNldCBvZiBwcmVmaXhlcyB0aGF0IGNhbiBiZSBy ZWFjaGVkICp0aHJvdWdoKiB0aGUgbGluay4NClRoaXMgaXMgaW1wb3J0YW50IGluZm9ybWF0aW9u IHRoYXQgSSB3YW50IHRvIHByb3ZpZGUgdG8gdGhlIGNsaWVudHMNCnZpYSBhIERIQ1B2NiBvcHRp b24uDQoNClRoYW5rcyAtIEZyZWQNCmZyZWQubC50ZW1wbGluQGJvZWluZy5jb20NCg0KPiBPbiBN b24sIEp1bCA3LCAyMDE0IGF0IDExOjUyIEFNLCBUZW1wbGluLCBGcmVkIEwNCj4gPEZyZWQuTC5U ZW1wbGluQGJvZWluZy5jb20+IHdyb3RlOg0KPiA+IEhpIEFuZHJlLA0KPiA+DQo+ID4gTm8sIHRo aXMgaXMgbm90IFByZWZpeCBEZWxlZ2F0aW9uLiBGb3IgUEQsIHRoZSBESENQdjYgc2VydmVyDQo+ ID4gcmV0dXJucyBhbiBJUHY2IHByZWZpeCB0aGF0IHRoZSBjbGllbnQgdGhlbiB1c2VzIHRvIG51 bWJlciBpdHMNCj4gPiBkb3duc3RyZWFtLWF0dGFjaGVkIGxpbmtzLiBXaGF0IEkgd2FudCBpcyBh biBpbmZvcm1hdGlvbmFsDQo+ID4gb3B0aW9uIHRoYXQgcGVydGFpbnMgdG8gdGhlIGxpbmsgb3Zl ciB3aGljaCB0aGUgY2xpZW50IGNvbnRhY3RzDQo+ID4gdGhlIHNlcnZlciwgYW5kIHRvIG15IHVu ZGVyc3RhbmRpbmcgUEQgY2Fubm90IGJlIHVzZWQgZm9yIHRoYXQuDQo+ID4NCj4gPiBUaGFua3Mg LSBGcmVkDQo+ID4gZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbQ0KPiA+DQo+ID4+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IEFuZHJlIEtvc3R1ciBbbWFpbHRvOmFrb3N0 dXJAaW5jb2duaXRvLmNvbV0NCj4gPj4gU2VudDogTW9uZGF5LCBKdWx5IDA3LCAyMDE0IDExOjIz IEFNDQo+ID4+IFRvOiBUZW1wbGluLCBGcmVkIEwNCj4gPj4gQ2M6IGRoY3dnQGlldGYub3JnDQo+ ID4+IFN1YmplY3Q6IFJlOiBbZGhjd2ddIEluZm9ybWF0aW9uYWwgSVB2NiBwcmVmaXggb3B0aW9u IGZvciBESENQdjYNCj4gPj4NCj4gPj4gSXNuJ3QgdGhhdCBQcmVmaXggRGVsZWdhdGlvbj8gUkZD IDM2MzMuICBOdXRzaGVsbCBpcyB0aGF0IHRoZSBjbGllbnQNCj4gPj4gY2FuIHNwZWNpZmljYWxs eSBhc2sgdGhlIHNlcnZlciBmb3IgYSBwcmVmaXguICBQYXJ0IG9mIHRoZSBwbGFuIGlzIGZvcg0K PiA+PiByb3V0ZXJzIGRlcGxveWVkIG91dCBhdCB0aGUgZWRnZSwgYW5kIHRoZXkgY2FuIGFzayB0 aGUgREhDUCBzZXJ2ZXIgZm9yDQo+ID4+IGEgcHJlZml4IHRoYXQgdGhlIHJvdXRlciB3aWxsIHRo ZW4gbWFuYWdlIG9uIGl0cyBmdXJ0aGVyIGRvd25zdHJlYW0NCj4gPj4gbGlua3MuDQo+ID4+DQo+ ID4+IE9uIE1vbiwgSnVsIDcsIDIwMTQgYXQgMTA6NTQgQU0sIFRlbXBsaW4sIEZyZWQgTA0KPiA+ PiA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4gd3JvdGU6DQo+ID4+ID4gSGksDQo+ID4+ID4N Cj4gPj4gPiBJIGFtIGxvb2tpbmcgZm9yIGEgREhDUHY2IG9wdGlvbiB0aGF0IGEgc2VydmVyIGNh biB1c2UgdG8gcmVwb3J0IGFuIElQdjYNCj4gPj4gPiBwcmVmaXggdG8gYSBjbGllbnQuIFRoaXMg KndvdWxkIG5vdCogYmUgdXNlZCBhcyBhIHJlcGxhY2VtZW50IGZvciBSb3V0ZXINCj4gPj4gPiBB ZHZlcnRpc2VtZW50IFByZWZpeCBJbmZvcm1hdGlvbiBPcHRpb25zIChQSU9zKSwgYW5kIHRoZSBj bGllbnQgKndvdWxkDQo+ID4+ID4gbm90KiB1c2UgdGhlIHByZWZpeCBmb3IgU0xBQUMuDQo+ID4+ ID4NCj4gPj4gPiBBIERIQ1B2NiBvcHRpb24gdGhhdCBzcGVjaWZpY2FsbHkgcmV0dXJuZWQgYW4g SVB2NiBwcmVmaXggKGFsb25nIHdpdGgNCj4gPj4gPiBwcmVmaXggbGVuZ3RoKSB3b3VsZCBiZSBw cmVmZXJyZWQuIEEgREhDUHY2IG9wdGlvbiB0aGF0IHJldHVybmVkIG9wYXF1ZQ0KPiA+PiA+IGRh dGEgY291bGQgYWxzbyBiZSB1c2VkIGFzIGEga2x1ZGdlIGJ1dCBJIHdvdWxkIHJhdGhlciBub3Qg aGF2ZSB0byBkbw0KPiA+PiA+IHRoYXQuIElzIHRoZXJlIGEgREhDUHY2IG9wdGlvbiB0aGF0IHdv dWxkIG1lZXQgdGhlc2UgcmVxdWlyZW1lbnRzPw0KPiA+PiA+DQo+ID4+ID4gVGhhbmtzIC0gRnJl ZA0KPiA+PiA+IGZyZWQubC50ZW1wbGluQGJvZWluZy5jb20NCj4gPj4gPg0KPiA+PiA+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+ID4gZGhjd2cg bWFpbGluZyBsaXN0DQo+ID4+ID4gZGhjd2dAaWV0Zi5vcmcNCj4gPj4gPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dnDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IC0t DQo+ID4+IEFuZHJlIEtvc3R1cg0KPiANCj4gLS0NCj4gQW5kcmUgS29zdHVyDQo= From nobody Mon Jul 7 12:57:32 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB571B28A8 for ; Mon, 7 Jul 2014 12:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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.651, 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 e4F1GqX9v7HQ for ; Mon, 7 Jul 2014 12:57:29 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17B521B289C for ; Mon, 7 Jul 2014 12:57:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4144; q=dns/txt; s=iport; t=1404763049; x=1405972649; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=OUMLvh5DUl1/knh6OqEIgFEwPsXghULgRLEItPpJfn0=; b=GnVKQDWKnal9KRNCBt/+ppYRyjR6U2rS2SKONamu7ofAxG10fgnZJ7ax sUssKpWNmokNkJH7Z8B09HLW6ZIWhMf29y+4Se6ePbJrRzuhHYKaDZX96 4Ei+ISmr0lPcH9WMXIl4xdKapax8BdEfFHx5teWJGG1mtKtP4p8hRQX2j o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAHb6ulOtJV2R/2dsb2JhbABZgw5SWr54h0UBgRsWdYQDAQEBAwEBAQE3NAsFBwQCAQgRBAEBAQoUCQcnCxQJCAEBBAENBQiIMggNyVsXjnEGKwcCBIMngRYFnD6SRINDbIFE X-IronPort-AV: E=Sophos;i="5.01,620,1400025600"; d="scan'208";a="58861948" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-1.cisco.com with ESMTP; 07 Jul 2014 19:57:28 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s67JvSrn002876 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Jul 2014 19:57:28 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.176]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Mon, 7 Jul 2014 14:57:28 -0500 From: "Bernie Volz (volz)" To: "Templin, Fred L" , Andre Kostur Thread-Topic: [dhcwg] Informational IPv6 prefix option for DHCPv6 Thread-Index: Ac+aDIcGSEduQ/YyTKOMsGQeKGSdbAAPpiMAAA3A+WD//6QLAIAAdDfggADiReA= Date: Mon, 7 Jul 2014 19:57:27 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1B5EAA24@xmb-rcd-x04.cisco.com> References: <2134F8430051B64F815C691A62D9831832CB79A3@XCH-BLV-505.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CB7ACC@XCH-BLV-505.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CB7B59@XCH-BLV-505.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832CB7B59@XCH-BLV-505.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.255.44] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/wiIgIlmH0KyQyhdge6t1MYuF5lE Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Informational IPv6 prefix option for DHCPv6 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, 07 Jul 2014 19:57:31 -0000 There was a draft to do something like this. But I think it died. See http:= //tools.ietf.org/html/draft-ietf-dhc-dhcpv6-prefix-pool-opt - Bernie -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Templin, Fred L Sent: Monday, July 07, 2014 3:44 PM To: Andre Kostur Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Informational IPv6 prefix option for DHCPv6 Hi Andre, > -----Original Message----- > From: Andre Kostur [mailto:akostur@incognito.com] > Sent: Monday, July 07, 2014 12:27 PM > To: Templin, Fred L > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] Informational IPv6 prefix option for DHCPv6 >=20 > Then I'm not sure of the purpose of this information. The client got=20 > an IPv6 address from somewhere, so it should be able to know its=20 > prefix from that. What's the client supposed to do with this=20 > information that it's getting from DHCP? It is for a link type on which there is no non-link-local IPv6 prefix assig= ned. The link connects a bunch of routers that only configure a link-local = address on the link. The routers also act as DHCPv6 clients, and act as req= uesting routers using DHCPv6 PD to get a prefix to assign to their downstre= am attached links. The IPv6 prefix I want to include in the DHCPv6 option I am asking for is t= he aggregated prefix from which client prefixes are delegated. So, if the a= ggregated prefix is 2001:db8::/32, then the clients would be delegated long= er prefixes such as 2001:db8:4000::/48, 2001:db8:1::/56, 2001:db8:21:31::/6= 4, etc. So, the aggregated prefix is not assigned *to* the link, but rather tells t= he set of prefixes that can be reached *through* the link. This is important information that I want to provide to the clients via a D= HCPv6 option. Thanks - Fred fred.l.templin@boeing.com > On Mon, Jul 7, 2014 at 11:52 AM, Templin, Fred L=20 > wrote: > > Hi Andre, > > > > No, this is not Prefix Delegation. For PD, the DHCPv6 server returns=20 > > an IPv6 prefix that the client then uses to number its=20 > > downstream-attached links. What I want is an informational option=20 > > that pertains to the link over which the client contacts the server,=20 > > and to my understanding PD cannot be used for that. > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > >> -----Original Message----- > >> From: Andre Kostur [mailto:akostur@incognito.com] > >> Sent: Monday, July 07, 2014 11:23 AM > >> To: Templin, Fred L > >> Cc: dhcwg@ietf.org > >> Subject: Re: [dhcwg] Informational IPv6 prefix option for DHCPv6 > >> > >> Isn't that Prefix Delegation? RFC 3633. Nutshell is that the=20 > >> client can specifically ask the server for a prefix. Part of the=20 > >> plan is for routers deployed out at the edge, and they can ask the=20 > >> DHCP server for a prefix that the router will then manage on its=20 > >> further downstream links. > >> > >> On Mon, Jul 7, 2014 at 10:54 AM, Templin, Fred L=20 > >> wrote: > >> > Hi, > >> > > >> > I am looking for a DHCPv6 option that a server can use to report=20 > >> > an IPv6 prefix to a client. This *would not* be used as a=20 > >> > replacement for Router Advertisement Prefix Information Options=20 > >> > (PIOs), and the client *would > >> > not* use the prefix for SLAAC. > >> > > >> > A DHCPv6 option that specifically returned an IPv6 prefix (along=20 > >> > with prefix length) would be preferred. A DHCPv6 option that=20 > >> > returned opaque data could also be used as a kludge but I would=20 > >> > rather not have to do that. Is there a DHCPv6 option that would meet= these requirements? > >> > > >> > Thanks - Fred > >> > fred.l.templin@boeing.com > >> > > >> > _______________________________________________ > >> > dhcwg mailing list > >> > dhcwg@ietf.org > >> > https://www.ietf.org/mailman/listinfo/dhcwg > >> > >> > >> > >> -- > >> Andre Kostur >=20 > -- > Andre Kostur _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From nobody Mon Jul 7 13:11:20 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80E691B28EB for ; Mon, 7 Jul 2014 13:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 rUpp1XD74r_F for ; Mon, 7 Jul 2014 13:11:07 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C3DE1B28E6 for ; Mon, 7 Jul 2014 13:10:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s67KA3ER020818; Mon, 7 Jul 2014 15:10:03 -0500 Received: from XCH-PHX-309.sw.nos.boeing.com (xch-phx-309.sw.nos.boeing.com [130.247.25.163]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s67K9w6o020652 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 7 Jul 2014 15:09:59 -0500 Received: from XCH-BLV-103.nw.nos.boeing.com (2002:82f7:1976::82f7:1976) by XCH-PHX-309.sw.nos.boeing.com (2002:82f7:19a3::82f7:19a3) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 7 Jul 2014 13:09:57 -0700 Received: from XCH-BLV-505.nw.nos.boeing.com ([169.254.5.55]) by XCH-BLV-103.nw.nos.boeing.com ([169.254.3.209]) with mapi id 14.03.0181.006; Mon, 7 Jul 2014 13:09:57 -0700 From: "Templin, Fred L" To: "Bernie Volz (volz)" , Andre Kostur Thread-Topic: [dhcwg] Informational IPv6 prefix option for DHCPv6 Thread-Index: Ac+aDIcGSEduQ/YyTKOMsGQeKGSdbAAPpiMAAA3A+WD//6QLAIAAdDfggADiReCAAcK3gA== Date: Mon, 7 Jul 2014 20:09:57 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CB7BE8@XCH-BLV-505.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832CB79A3@XCH-BLV-505.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CB7ACC@XCH-BLV-505.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CB7B59@XCH-BLV-505.nw.nos.boeing.com> <489D13FBFA9B3E41812EA89F188F018E1B5EAA24@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1B5EAA24@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/C849xtRVkel0GQ-ufzZay7wPxoI Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Informational IPv6 prefix option for DHCPv6 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, 07 Jul 2014 20:11:12 -0000 Hi Bernie, Thanks. At first glance, this looks like it is too tightly wrapped around DHCPv6 PD for what I am after. I want something very simple that is somehow related to PD but at the same time independent of PD. So again, to my link model, I have a link on which there are one or more delegating routers and lots and lots of requesting routers. To get the information I am looking for, I could set the delegating routers to include the aggregated prefix in RA PIOs with the 'A' and 'L' bits set to 0. But, that means that I would need to set up some manual configuration on each of the delegating routers and I really don't want to have to do that. Much better would be to have the DHCPv6 server include the aggregated prefix in a simple informative DHCPv6 option as a single administrative touch point. The delegating routers are then simpler and less prone to misconfigurations, and the requesting routers get the PD and aggregated prefix information they need in a single DHCPv6 request. I think a while back there was some discussion about including PIOs in DHCPv6 messages. Did that hit some kind of roadblock? Because, I think I now have an interesting use case for it. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: Bernie Volz (volz) [mailto:volz@cisco.com] > Sent: Monday, July 07, 2014 12:57 PM > To: Templin, Fred L; Andre Kostur > Cc: dhcwg@ietf.org > Subject: RE: [dhcwg] Informational IPv6 prefix option for DHCPv6 >=20 > There was a draft to do something like this. But I think it died. See > http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-prefix-pool-opt >=20 > - Bernie >=20 > -----Original Message----- > From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Templin, Fred L > Sent: Monday, July 07, 2014 3:44 PM > To: Andre Kostur > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] Informational IPv6 prefix option for DHCPv6 >=20 > Hi Andre, >=20 > > -----Original Message----- > > From: Andre Kostur [mailto:akostur@incognito.com] > > Sent: Monday, July 07, 2014 12:27 PM > > To: Templin, Fred L > > Cc: dhcwg@ietf.org > > Subject: Re: [dhcwg] Informational IPv6 prefix option for DHCPv6 > > > > Then I'm not sure of the purpose of this information. The client got > > an IPv6 address from somewhere, so it should be able to know its > > prefix from that. What's the client supposed to do with this > > information that it's getting from DHCP? >=20 > It is for a link type on which there is no non-link-local IPv6 prefix ass= igned. The link connects a > bunch of routers that only configure a link-local address on the link. Th= e routers also act as DHCPv6 > clients, and act as requesting routers using DHCPv6 PD to get a prefix to= assign to their downstream > attached links. >=20 > The IPv6 prefix I want to include in the DHCPv6 option I am asking for is= the aggregated prefix from > which client prefixes are delegated. So, if the aggregated prefix is 2001= :db8::/32, then the clients > would be delegated longer prefixes such as 2001:db8:4000::/48, 2001:db8:1= ::/56, 2001:db8:21:31::/64, > etc. >=20 > So, the aggregated prefix is not assigned *to* the link, but rather tells= the set of prefixes that can > be reached *through* the link. > This is important information that I want to provide to the clients via a= DHCPv6 option. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > > On Mon, Jul 7, 2014 at 11:52 AM, Templin, Fred L > > wrote: > > > Hi Andre, > > > > > > No, this is not Prefix Delegation. For PD, the DHCPv6 server returns > > > an IPv6 prefix that the client then uses to number its > > > downstream-attached links. What I want is an informational option > > > that pertains to the link over which the client contacts the server, > > > and to my understanding PD cannot be used for that. > > > > > > Thanks - Fred > > > fred.l.templin@boeing.com > > > > > >> -----Original Message----- > > >> From: Andre Kostur [mailto:akostur@incognito.com] > > >> Sent: Monday, July 07, 2014 11:23 AM > > >> To: Templin, Fred L > > >> Cc: dhcwg@ietf.org > > >> Subject: Re: [dhcwg] Informational IPv6 prefix option for DHCPv6 > > >> > > >> Isn't that Prefix Delegation? RFC 3633. Nutshell is that the > > >> client can specifically ask the server for a prefix. Part of the > > >> plan is for routers deployed out at the edge, and they can ask the > > >> DHCP server for a prefix that the router will then manage on its > > >> further downstream links. > > >> > > >> On Mon, Jul 7, 2014 at 10:54 AM, Templin, Fred L > > >> wrote: > > >> > Hi, > > >> > > > >> > I am looking for a DHCPv6 option that a server can use to report > > >> > an IPv6 prefix to a client. This *would not* be used as a > > >> > replacement for Router Advertisement Prefix Information Options > > >> > (PIOs), and the client *would > > >> > not* use the prefix for SLAAC. > > >> > > > >> > A DHCPv6 option that specifically returned an IPv6 prefix (along > > >> > with prefix length) would be preferred. A DHCPv6 option that > > >> > returned opaque data could also be used as a kludge but I would > > >> > rather not have to do that. Is there a DHCPv6 option that would me= et these requirements? > > >> > > > >> > Thanks - Fred > > >> > fred.l.templin@boeing.com > > >> > > > >> > _______________________________________________ > > >> > dhcwg mailing list > > >> > dhcwg@ietf.org > > >> > https://www.ietf.org/mailman/listinfo/dhcwg > > >> > > >> > > >> > > >> -- > > >> Andre Kostur > > > > -- > > Andre Kostur > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From nobody Mon Jul 7 13:15:25 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C2D1B28A9 for ; Mon, 7 Jul 2014 13:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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.651, 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 CPK8BOVLMugt for ; Mon, 7 Jul 2014 13:15:19 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDE6A1A0A88 for ; Mon, 7 Jul 2014 13:15:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6806; q=dns/txt; s=iport; t=1404764118; x=1405973718; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=SwOsXcG/aXqAVIZ038fy6mJAzW0dNU19PW8S0TX4Qo4=; b=ABVaH5szjBLUxT8T1qnuAbX8byKMW/4FHJi4KgAH8tSThpnzeSP0hvJj 295CG268KJFU5+EX/aNK/9qePgvZoUjf/qG1ZQh4ZjhUuIvmNDdciKoJ4 pV84XaaetAWwiptj4TIWvw3NSOQwI+xnqKxThPD5GNbZEQlcBtnHeOdf0 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAKX+ulOtJV2Z/2dsb2JhbABZgw5SWr54h0UBgRsWdYQDAQEBBAEBATc0CwwEAgEIEQQBAQEKFAkHJwsUCQgCBAENBQgBiDkNyVgXjnEGKwcCBIMngRYFgViaZpJEg0NsgUQ X-IronPort-AV: E=Sophos;i="5.01,620,1400025600"; d="scan'208";a="58910718" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-6.cisco.com with ESMTP; 07 Jul 2014 20:15:18 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s67KFIP8002470 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Jul 2014 20:15:18 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.176]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Mon, 7 Jul 2014 15:15:17 -0500 From: "Bernie Volz (volz)" To: "Templin, Fred L" , Andre Kostur Thread-Topic: [dhcwg] Informational IPv6 prefix option for DHCPv6 Thread-Index: Ac+aDIcGSEduQ/YyTKOMsGQeKGSdbAAPpiMAAA3A+WD//6QLAIAAdDfggADiReCAAcK3gIADgkEg Date: Mon, 7 Jul 2014 20:15:17 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1B5EAA78@xmb-rcd-x04.cisco.com> References: <2134F8430051B64F815C691A62D9831832CB79A3@XCH-BLV-505.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CB7ACC@XCH-BLV-505.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CB7B59@XCH-BLV-505.nw.nos.boeing.com> <489D13FBFA9B3E41812EA89F188F018E1B5EAA24@xmb-rcd-x04.cisco.com> <2134F8430051B64F815C691A62D9831832CB7BE8@XCH-BLV-505.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832CB7BE8@XCH-BLV-505.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.255.44] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/XICR2YOxpKf4yRMC0ExOsO44IkY Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Informational IPv6 prefix option for DHCPv6 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, 07 Jul 2014 20:15:21 -0000 See http://tools.ietf.org/html/draft-sarikaya-dhc-dhcpv6-raoptions-sadr-00 = as I this just got resurrected (there were several other documents in the p= ast that attempted to do this or something close to it). Nothing exists as an IETF standard for what you want. Whether you can use s= omething that others are working on or not, I cannot say. I find these docu= ments by googling :). The options ones that presently exist are at: http://www.iana.org/assignmen= ts/dhcpv6-parameters/dhcpv6-parameters.xml, and I don't think anything ther= e works for what you want. You could always use Vendor Options (option 17). - Bernie -----Original Message----- From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20 Sent: Monday, July 07, 2014 4:10 PM To: Bernie Volz (volz); Andre Kostur Cc: dhcwg@ietf.org Subject: RE: [dhcwg] Informational IPv6 prefix option for DHCPv6 Hi Bernie, Thanks. At first glance, this looks like it is too tightly wrapped around D= HCPv6 PD for what I am after. I want something very simple that is somehow = related to PD but at the same time independent of PD. So again, to my link model, I have a link on which there are one or more de= legating routers and lots and lots of requesting routers. To get the information I am looking for, I could set the delegating routers= to include the aggregated prefix in RA PIOs with the 'A' and 'L' bits set = to 0. But, that means that I would need to set up some manual configuration= on each of the delegating routers and I really don't want to have to do th= at. Much better would be to have the DHCPv6 server include the aggregated prefi= x in a simple informative DHCPv6 option as a single administrative touch po= int. The delegating routers are then simpler and less prone to misconfigura= tions, and the requesting routers get the PD and aggregated prefix informat= ion they need in a single DHCPv6 request. I think a while back there was some discussion about including PIOs in DHCPv6 messages. Did that hit some kind of roadblock? Because, I think I no= w have an interesting use case for it. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: Bernie Volz (volz) [mailto:volz@cisco.com] > Sent: Monday, July 07, 2014 12:57 PM > To: Templin, Fred L; Andre Kostur > Cc: dhcwg@ietf.org > Subject: RE: [dhcwg] Informational IPv6 prefix option for DHCPv6 >=20 > There was a draft to do something like this. But I think it died. See=20 > http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-prefix-pool-opt >=20 > - Bernie >=20 > -----Original Message----- > From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Templin, Fred=20 > L > Sent: Monday, July 07, 2014 3:44 PM > To: Andre Kostur > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] Informational IPv6 prefix option for DHCPv6 >=20 > Hi Andre, >=20 > > -----Original Message----- > > From: Andre Kostur [mailto:akostur@incognito.com] > > Sent: Monday, July 07, 2014 12:27 PM > > To: Templin, Fred L > > Cc: dhcwg@ietf.org > > Subject: Re: [dhcwg] Informational IPv6 prefix option for DHCPv6 > > > > Then I'm not sure of the purpose of this information. The client=20 > > got an IPv6 address from somewhere, so it should be able to know its=20 > > prefix from that. What's the client supposed to do with this=20 > > information that it's getting from DHCP? >=20 > It is for a link type on which there is no non-link-local IPv6 prefix=20 > assigned. The link connects a bunch of routers that only configure a=20 > link-local address on the link. The routers also act as DHCPv6=20 > clients, and act as requesting routers using DHCPv6 PD to get a prefix to= assign to their downstream attached links. >=20 > The IPv6 prefix I want to include in the DHCPv6 option I am asking for=20 > is the aggregated prefix from which client prefixes are delegated. So,=20 > if the aggregated prefix is 2001:db8::/32, then the clients would be=20 > delegated longer prefixes such as 2001:db8:4000::/48, 2001:db8:1::/56, 20= 01:db8:21:31::/64, etc. >=20 > So, the aggregated prefix is not assigned *to* the link, but rather=20 > tells the set of prefixes that can be reached *through* the link. > This is important information that I want to provide to the clients via a= DHCPv6 option. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > > On Mon, Jul 7, 2014 at 11:52 AM, Templin, Fred L=20 > > wrote: > > > Hi Andre, > > > > > > No, this is not Prefix Delegation. For PD, the DHCPv6 server=20 > > > returns an IPv6 prefix that the client then uses to number its=20 > > > downstream-attached links. What I want is an informational option=20 > > > that pertains to the link over which the client contacts the=20 > > > server, and to my understanding PD cannot be used for that. > > > > > > Thanks - Fred > > > fred.l.templin@boeing.com > > > > > >> -----Original Message----- > > >> From: Andre Kostur [mailto:akostur@incognito.com] > > >> Sent: Monday, July 07, 2014 11:23 AM > > >> To: Templin, Fred L > > >> Cc: dhcwg@ietf.org > > >> Subject: Re: [dhcwg] Informational IPv6 prefix option for DHCPv6 > > >> > > >> Isn't that Prefix Delegation? RFC 3633. Nutshell is that the=20 > > >> client can specifically ask the server for a prefix. Part of the=20 > > >> plan is for routers deployed out at the edge, and they can ask=20 > > >> the DHCP server for a prefix that the router will then manage on=20 > > >> its further downstream links. > > >> > > >> On Mon, Jul 7, 2014 at 10:54 AM, Templin, Fred L=20 > > >> wrote: > > >> > Hi, > > >> > > > >> > I am looking for a DHCPv6 option that a server can use to=20 > > >> > report an IPv6 prefix to a client. This *would not* be used as=20 > > >> > a replacement for Router Advertisement Prefix Information=20 > > >> > Options (PIOs), and the client *would > > >> > not* use the prefix for SLAAC. > > >> > > > >> > A DHCPv6 option that specifically returned an IPv6 prefix=20 > > >> > (along with prefix length) would be preferred. A DHCPv6 option=20 > > >> > that returned opaque data could also be used as a kludge but I=20 > > >> > would rather not have to do that. Is there a DHCPv6 option that wo= uld meet these requirements? > > >> > > > >> > Thanks - Fred > > >> > fred.l.templin@boeing.com > > >> > > > >> > _______________________________________________ > > >> > dhcwg mailing list > > >> > dhcwg@ietf.org > > >> > https://www.ietf.org/mailman/listinfo/dhcwg > > >> > > >> > > >> > > >> -- > > >> Andre Kostur > > > > -- > > Andre Kostur > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From nobody Mon Jul 7 13:29:55 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB4B1B28EB for ; Mon, 7 Jul 2014 13:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 aKnH1b8jSFHf for ; Mon, 7 Jul 2014 13:29:50 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BB181B28EA for ; Mon, 7 Jul 2014 13:29:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s67KTnqt032156; Mon, 7 Jul 2014 15:29:49 -0500 Received: from XCH-PHX-209.sw.nos.boeing.com (xch-phx-209.sw.nos.boeing.com [130.247.25.29]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s67KTkgp031965 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 7 Jul 2014 15:29:47 -0500 Received: from XCH-BLV-107.nw.nos.boeing.com (2002:82f7:197b::82f7:197b) by XCH-PHX-209.sw.nos.boeing.com (2002:82f7:191d::82f7:191d) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 7 Jul 2014 13:29:45 -0700 Received: from XCH-BLV-505.nw.nos.boeing.com ([169.254.5.55]) by XCH-BLV-107.nw.nos.boeing.com ([169.254.7.91]) with mapi id 14.03.0181.006; Mon, 7 Jul 2014 13:29:44 -0700 From: "Templin, Fred L" To: "Bernie Volz (volz)" , Andre Kostur Thread-Topic: [dhcwg] Informational IPv6 prefix option for DHCPv6 Thread-Index: Ac+aDIcGSEduQ/YyTKOMsGQeKGSdbAAPpiMAAA3A+WD//6QLAIAAdDfggADiReCAAcK3gIADgkEggAcBdJA= Date: Mon, 7 Jul 2014 20:29:44 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CB7C6B@XCH-BLV-505.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832CB79A3@XCH-BLV-505.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CB7ACC@XCH-BLV-505.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CB7B59@XCH-BLV-505.nw.nos.boeing.com> <489D13FBFA9B3E41812EA89F188F018E1B5EAA24@xmb-rcd-x04.cisco.com> <2134F8430051B64F815C691A62D9831832CB7BE8@XCH-BLV-505.nw.nos.boeing.com> <489D13FBFA9B3E41812EA89F188F018E1B5EAA78@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1B5EAA78@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/j3vASSE-vqZM2uLCXwnkHxFc_iw Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Informational IPv6 prefix option for DHCPv6 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, 07 Jul 2014 20:29:52 -0000 Hi Bernie, > -----Original Message----- > From: Bernie Volz (volz) [mailto:volz@cisco.com] > Sent: Monday, July 07, 2014 1:15 PM > To: Templin, Fred L; Andre Kostur > Cc: dhcwg@ietf.org > Subject: RE: [dhcwg] Informational IPv6 prefix option for DHCPv6 >=20 > See http://tools.ietf.org/html/draft-sarikaya-dhc-dhcpv6-raoptions-sadr-0= 0 as I this just got > resurrected (there were several other documents in the past that attempte= d to do this or something > close to it). Thanks; that too looks like overkill for what I need. =20 > Nothing exists as an IETF standard for what you want. Whether you can use= something that others are > working on or not, I cannot say. I find these documents by googling :). I will try to do a better job of googling. > The options ones that presently exist are at: http://www.iana.org/assignm= ents/dhcpv6- > parameters/dhcpv6-parameters.xml, and I don't think anything there works = for what you want. Right, I took a look there and didn't see anything. > You could always use Vendor Options (option 17). OK, that would satisfy what I was meaning when I said: "A DHCPv6 option that returned opaque data could also be used as a kludge but I would rather not have to do that." But, maybe it wouldn't be so bad, plus (correct me if I am wrong) it has the distinct advantage that it is already implemented in widely-deployed DHCPv6 implementations, right? Thanks again for the help, Fred fred.l.templin@boeing.com > - Bernie >=20 > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > Sent: Monday, July 07, 2014 4:10 PM > To: Bernie Volz (volz); Andre Kostur > Cc: dhcwg@ietf.org > Subject: RE: [dhcwg] Informational IPv6 prefix option for DHCPv6 >=20 > Hi Bernie, >=20 > Thanks. At first glance, this looks like it is too tightly wrapped around= DHCPv6 PD for what I am > after. I want something very simple that is somehow related to PD but at = the same time independent of > PD. >=20 > So again, to my link model, I have a link on which there are one or more = delegating routers and lots > and lots of requesting routers. > To get the information I am looking for, I could set the delegating route= rs to include the aggregated > prefix in RA PIOs with the 'A' and 'L' bits set to 0. But, that means tha= t I would need to set up some > manual configuration on each of the delegating routers and I really don't= want to have to do that. >=20 > Much better would be to have the DHCPv6 server include the aggregated pre= fix in a simple informative > DHCPv6 option as a single administrative touch point. The delegating rout= ers are then simpler and less > prone to misconfigurations, and the requesting routers get the PD and agg= regated prefix information > they need in a single DHCPv6 request. >=20 > I think a while back there was some discussion about including PIOs in > DHCPv6 messages. Did that hit some kind of roadblock? Because, I think I = now have an interesting use > case for it. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > > -----Original Message----- > > From: Bernie Volz (volz) [mailto:volz@cisco.com] > > Sent: Monday, July 07, 2014 12:57 PM > > To: Templin, Fred L; Andre Kostur > > Cc: dhcwg@ietf.org > > Subject: RE: [dhcwg] Informational IPv6 prefix option for DHCPv6 > > > > There was a draft to do something like this. But I think it died. See > > http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-prefix-pool-opt > > > > - Bernie > > > > -----Original Message----- > > From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Templin, Fred > > L > > Sent: Monday, July 07, 2014 3:44 PM > > To: Andre Kostur > > Cc: dhcwg@ietf.org > > Subject: Re: [dhcwg] Informational IPv6 prefix option for DHCPv6 > > > > Hi Andre, > > > > > -----Original Message----- > > > From: Andre Kostur [mailto:akostur@incognito.com] > > > Sent: Monday, July 07, 2014 12:27 PM > > > To: Templin, Fred L > > > Cc: dhcwg@ietf.org > > > Subject: Re: [dhcwg] Informational IPv6 prefix option for DHCPv6 > > > > > > Then I'm not sure of the purpose of this information. The client > > > got an IPv6 address from somewhere, so it should be able to know its > > > prefix from that. What's the client supposed to do with this > > > information that it's getting from DHCP? > > > > It is for a link type on which there is no non-link-local IPv6 prefix > > assigned. The link connects a bunch of routers that only configure a > > link-local address on the link. The routers also act as DHCPv6 > > clients, and act as requesting routers using DHCPv6 PD to get a prefix = to assign to their downstream > attached links. > > > > The IPv6 prefix I want to include in the DHCPv6 option I am asking for > > is the aggregated prefix from which client prefixes are delegated. So, > > if the aggregated prefix is 2001:db8::/32, then the clients would be > > delegated longer prefixes such as 2001:db8:4000::/48, 2001:db8:1::/56, = 2001:db8:21:31::/64, etc. > > > > So, the aggregated prefix is not assigned *to* the link, but rather > > tells the set of prefixes that can be reached *through* the link. > > This is important information that I want to provide to the clients via= a DHCPv6 option. > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > > > On Mon, Jul 7, 2014 at 11:52 AM, Templin, Fred L > > > wrote: > > > > Hi Andre, > > > > > > > > No, this is not Prefix Delegation. For PD, the DHCPv6 server > > > > returns an IPv6 prefix that the client then uses to number its > > > > downstream-attached links. What I want is an informational option > > > > that pertains to the link over which the client contacts the > > > > server, and to my understanding PD cannot be used for that. > > > > > > > > Thanks - Fred > > > > fred.l.templin@boeing.com > > > > > > > >> -----Original Message----- > > > >> From: Andre Kostur [mailto:akostur@incognito.com] > > > >> Sent: Monday, July 07, 2014 11:23 AM > > > >> To: Templin, Fred L > > > >> Cc: dhcwg@ietf.org > > > >> Subject: Re: [dhcwg] Informational IPv6 prefix option for DHCPv6 > > > >> > > > >> Isn't that Prefix Delegation? RFC 3633. Nutshell is that the > > > >> client can specifically ask the server for a prefix. Part of the > > > >> plan is for routers deployed out at the edge, and they can ask > > > >> the DHCP server for a prefix that the router will then manage on > > > >> its further downstream links. > > > >> > > > >> On Mon, Jul 7, 2014 at 10:54 AM, Templin, Fred L > > > >> wrote: > > > >> > Hi, > > > >> > > > > >> > I am looking for a DHCPv6 option that a server can use to > > > >> > report an IPv6 prefix to a client. This *would not* be used as > > > >> > a replacement for Router Advertisement Prefix Information > > > >> > Options (PIOs), and the client *would > > > >> > not* use the prefix for SLAAC. > > > >> > > > > >> > A DHCPv6 option that specifically returned an IPv6 prefix > > > >> > (along with prefix length) would be preferred. A DHCPv6 option > > > >> > that returned opaque data could also be used as a kludge but I > > > >> > would rather not have to do that. Is there a DHCPv6 option that = would meet these > requirements? > > > >> > > > > >> > Thanks - Fred > > > >> > fred.l.templin@boeing.com > > > >> > > > > >> > _______________________________________________ > > > >> > dhcwg mailing list > > > >> > dhcwg@ietf.org > > > >> > https://www.ietf.org/mailman/listinfo/dhcwg > > > >> > > > >> > > > >> > > > >> -- > > > >> Andre Kostur > > > > > > -- > > > Andre Kostur > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www.ietf.org/mailman/listinfo/dhcwg From nobody Mon Jul 7 13:52:36 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD7F1B28E9 for ; Mon, 7 Jul 2014 13:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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.651, 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 6sDDgcSTIoHh for ; Mon, 7 Jul 2014 13:52:29 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E448D1B28F7 for ; Mon, 7 Jul 2014 13:52:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8516; q=dns/txt; s=iport; t=1404766349; x=1405975949; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=6bNn/aVnLwR6k/QzhlFUVPpjtwotMHqFsamHRzYwIEE=; b=C/DDbU8gIRYGziLJ1h8kJf63kxa+e1ASxreAWZhgZvcgt74NC7OUkVsn BAKIcVvDjgG25lllF5q0VNosEfM2M+dBu8QRCrTXIpxz73cotVFyKZT1w 5JkNhuWUCwnpRUM1XoWwMZI5bjkajoqUxRGfEVMY3jrlIy970lAcqRGU4 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAJcHu1OtJA2F/2dsb2JhbABZgw5SWr54h0UBgRsWdYQDAQEBAwEBAQE3NAsFBwQCAQgRBAEBAQoUCQcnCxQJCAIEAQ0FCAGIMQgNyTkXjnEGKwcCBIMngRYFnD6SRINDbIFE X-IronPort-AV: E=Sophos;i="5.01,620,1400025600"; d="scan'208";a="338315283" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-6.cisco.com with ESMTP; 07 Jul 2014 20:52:28 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s67KqR9u017846 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Jul 2014 20:52:27 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.176]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Mon, 7 Jul 2014 15:52:27 -0500 From: "Bernie Volz (volz)" To: "Templin, Fred L" , Andre Kostur Thread-Topic: [dhcwg] Informational IPv6 prefix option for DHCPv6 Thread-Index: Ac+aDIcGSEduQ/YyTKOMsGQeKGSdbAAPpiMAAA3A+WD//6QLAIAAdDfggADiReCAAcK3gIADgkEggAcBdJCADfq0IA== Date: Mon, 7 Jul 2014 20:52:27 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1B5EAB30@xmb-rcd-x04.cisco.com> References: <2134F8430051B64F815C691A62D9831832CB79A3@XCH-BLV-505.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CB7ACC@XCH-BLV-505.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CB7B59@XCH-BLV-505.nw.nos.boeing.com> <489D13FBFA9B3E41812EA89F188F018E1B5EAA24@xmb-rcd-x04.cisco.com> <2134F8430051B64F815C691A62D9831832CB7BE8@XCH-BLV-505.nw.nos.boeing.com> <489D13FBFA9B3E41812EA89F188F018E1B5EAA78@xmb-rcd-x04.cisco.com> <2134F8430051B64F815C691A62D9831832CB7C6B@XCH-BLV-505.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832CB7C6B@XCH-BLV-505.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.255.44] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/7YBdZDix4wEYX2t3j3rRtOILbCg Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Informational IPv6 prefix option for DHCPv6 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, 07 Jul 2014 20:52:33 -0000 >But, maybe it wouldn't be so bad, plus (correct me if I am wrong) it has t= he distinct advantage that it is already implemented in widely-deployed DHC= Pv6 implementations, right? I would expect that this is widely implemented. - Bernie -----Original Message----- From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20 Sent: Monday, July 07, 2014 4:30 PM To: Bernie Volz (volz); Andre Kostur Cc: dhcwg@ietf.org Subject: RE: [dhcwg] Informational IPv6 prefix option for DHCPv6 Hi Bernie, > -----Original Message----- > From: Bernie Volz (volz) [mailto:volz@cisco.com] > Sent: Monday, July 07, 2014 1:15 PM > To: Templin, Fred L; Andre Kostur > Cc: dhcwg@ietf.org > Subject: RE: [dhcwg] Informational IPv6 prefix option for DHCPv6 >=20 > See=20 > http://tools.ietf.org/html/draft-sarikaya-dhc-dhcpv6-raoptions-sadr-00=20 > as I this just got resurrected (there were several other documents in the= past that attempted to do this or something close to it). Thanks; that too looks like overkill for what I need. =20 > Nothing exists as an IETF standard for what you want. Whether you can=20 > use something that others are working on or not, I cannot say. I find the= se documents by googling :). I will try to do a better job of googling. > The options ones that presently exist are at:=20 > http://www.iana.org/assignments/dhcpv6- > parameters/dhcpv6-parameters.xml, and I don't think anything there works = for what you want. Right, I took a look there and didn't see anything. > You could always use Vendor Options (option 17). OK, that would satisfy what I was meaning when I said: "A DHCPv6 option that returned opaque data could also be used as a kludge but I would rather not have to do that." But, maybe it wouldn't be so bad, plus (correct me if I am wrong) it has th= e distinct advantage that it is already implemented in widely-deployed DHCP= v6 implementations, right? Thanks again for the help, Fred fred.l.templin@boeing.com > - Bernie >=20 > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > Sent: Monday, July 07, 2014 4:10 PM > To: Bernie Volz (volz); Andre Kostur > Cc: dhcwg@ietf.org > Subject: RE: [dhcwg] Informational IPv6 prefix option for DHCPv6 >=20 > Hi Bernie, >=20 > Thanks. At first glance, this looks like it is too tightly wrapped=20 > around DHCPv6 PD for what I am after. I want something very simple=20 > that is somehow related to PD but at the same time independent of PD. >=20 > So again, to my link model, I have a link on which there are one or=20 > more delegating routers and lots and lots of requesting routers. > To get the information I am looking for, I could set the delegating=20 > routers to include the aggregated prefix in RA PIOs with the 'A' and=20 > 'L' bits set to 0. But, that means that I would need to set up some manua= l configuration on each of the delegating routers and I really don't want t= o have to do that. >=20 > Much better would be to have the DHCPv6 server include the aggregated=20 > prefix in a simple informative > DHCPv6 option as a single administrative touch point. The delegating=20 > routers are then simpler and less prone to misconfigurations, and the=20 > requesting routers get the PD and aggregated prefix information they need= in a single DHCPv6 request. >=20 > I think a while back there was some discussion about including PIOs in > DHCPv6 messages. Did that hit some kind of roadblock? Because, I think=20 > I now have an interesting use case for it. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > > -----Original Message----- > > From: Bernie Volz (volz) [mailto:volz@cisco.com] > > Sent: Monday, July 07, 2014 12:57 PM > > To: Templin, Fred L; Andre Kostur > > Cc: dhcwg@ietf.org > > Subject: RE: [dhcwg] Informational IPv6 prefix option for DHCPv6 > > > > There was a draft to do something like this. But I think it died.=20 > > See http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-prefix-pool-opt > > > > - Bernie > > > > -----Original Message----- > > From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Templin,=20 > > Fred L > > Sent: Monday, July 07, 2014 3:44 PM > > To: Andre Kostur > > Cc: dhcwg@ietf.org > > Subject: Re: [dhcwg] Informational IPv6 prefix option for DHCPv6 > > > > Hi Andre, > > > > > -----Original Message----- > > > From: Andre Kostur [mailto:akostur@incognito.com] > > > Sent: Monday, July 07, 2014 12:27 PM > > > To: Templin, Fred L > > > Cc: dhcwg@ietf.org > > > Subject: Re: [dhcwg] Informational IPv6 prefix option for DHCPv6 > > > > > > Then I'm not sure of the purpose of this information. The client=20 > > > got an IPv6 address from somewhere, so it should be able to know=20 > > > its prefix from that. What's the client supposed to do with this=20 > > > information that it's getting from DHCP? > > > > It is for a link type on which there is no non-link-local IPv6=20 > > prefix assigned. The link connects a bunch of routers that only=20 > > configure a link-local address on the link. The routers also act as=20 > > DHCPv6 clients, and act as requesting routers using DHCPv6 PD to get=20 > > a prefix to assign to their downstream > attached links. > > > > The IPv6 prefix I want to include in the DHCPv6 option I am asking=20 > > for is the aggregated prefix from which client prefixes are=20 > > delegated. So, if the aggregated prefix is 2001:db8::/32, then the=20 > > clients would be delegated longer prefixes such as 2001:db8:4000::/48, = 2001:db8:1::/56, 2001:db8:21:31::/64, etc. > > > > So, the aggregated prefix is not assigned *to* the link, but rather=20 > > tells the set of prefixes that can be reached *through* the link. > > This is important information that I want to provide to the clients via= a DHCPv6 option. > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > > > On Mon, Jul 7, 2014 at 11:52 AM, Templin, Fred L=20 > > > wrote: > > > > Hi Andre, > > > > > > > > No, this is not Prefix Delegation. For PD, the DHCPv6 server=20 > > > > returns an IPv6 prefix that the client then uses to number its=20 > > > > downstream-attached links. What I want is an informational=20 > > > > option that pertains to the link over which the client contacts=20 > > > > the server, and to my understanding PD cannot be used for that. > > > > > > > > Thanks - Fred > > > > fred.l.templin@boeing.com > > > > > > > >> -----Original Message----- > > > >> From: Andre Kostur [mailto:akostur@incognito.com] > > > >> Sent: Monday, July 07, 2014 11:23 AM > > > >> To: Templin, Fred L > > > >> Cc: dhcwg@ietf.org > > > >> Subject: Re: [dhcwg] Informational IPv6 prefix option for=20 > > > >> DHCPv6 > > > >> > > > >> Isn't that Prefix Delegation? RFC 3633. Nutshell is that the=20 > > > >> client can specifically ask the server for a prefix. Part of=20 > > > >> the plan is for routers deployed out at the edge, and they can=20 > > > >> ask the DHCP server for a prefix that the router will then=20 > > > >> manage on its further downstream links. > > > >> > > > >> On Mon, Jul 7, 2014 at 10:54 AM, Templin, Fred L=20 > > > >> wrote: > > > >> > Hi, > > > >> > > > > >> > I am looking for a DHCPv6 option that a server can use to=20 > > > >> > report an IPv6 prefix to a client. This *would not* be used=20 > > > >> > as a replacement for Router Advertisement Prefix Information=20 > > > >> > Options (PIOs), and the client *would > > > >> > not* use the prefix for SLAAC. > > > >> > > > > >> > A DHCPv6 option that specifically returned an IPv6 prefix=20 > > > >> > (along with prefix length) would be preferred. A DHCPv6=20 > > > >> > option that returned opaque data could also be used as a=20 > > > >> > kludge but I would rather not have to do that. Is there a=20 > > > >> > DHCPv6 option that would meet these > requirements? > > > >> > > > > >> > Thanks - Fred > > > >> > fred.l.templin@boeing.com > > > >> > > > > >> > _______________________________________________ > > > >> > dhcwg mailing list > > > >> > dhcwg@ietf.org > > > >> > https://www.ietf.org/mailman/listinfo/dhcwg > > > >> > > > >> > > > >> > > > >> -- > > > >> Andre Kostur > > > > > > -- > > > Andre Kostur > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www.ietf.org/mailman/listinfo/dhcwg From nobody Mon Jul 7 14:02:33 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5ED11A0456 for ; Mon, 7 Jul 2014 14:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 NaRfXkrxbVTF for ; Mon, 7 Jul 2014 14:02:29 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00F5E1B28E9 for ; Mon, 7 Jul 2014 14:02:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s67L2Rme018454; Mon, 7 Jul 2014 16:02:27 -0500 Received: from XCH-PHX-513.sw.nos.boeing.com (xch-phx-513.sw.nos.boeing.com [10.57.37.30]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s67L2PII018450 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 7 Jul 2014 16:02:26 -0500 Received: from XCH-BLV-301.nw.nos.boeing.com (130.247.25.213) by XCH-PHX-513.sw.nos.boeing.com (10.57.37.30) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 7 Jul 2014 14:02:25 -0700 Received: from XCH-BLV-505.nw.nos.boeing.com ([169.254.5.55]) by XCH-BLV-301.nw.nos.boeing.com ([169.254.1.114]) with mapi id 14.03.0181.006; Mon, 7 Jul 2014 14:02:25 -0700 From: "Templin, Fred L" To: "Bernie Volz (volz)" , Andre Kostur Thread-Topic: [dhcwg] Informational IPv6 prefix option for DHCPv6 Thread-Index: Ac+aDIcGSEduQ/YyTKOMsGQeKGSdbAAPpiMAAA3A+WD//6QLAIAAdDfggADiReCAAcK3gIADgkEggAcBdJCADfq0IIAb8rcQ Date: Mon, 7 Jul 2014 21:02:25 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832CB7CC0@XCH-BLV-505.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832CB79A3@XCH-BLV-505.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CB7ACC@XCH-BLV-505.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832CB7B59@XCH-BLV-505.nw.nos.boeing.com> <489D13FBFA9B3E41812EA89F188F018E1B5EAA24@xmb-rcd-x04.cisco.com> <2134F8430051B64F815C691A62D9831832CB7BE8@XCH-BLV-505.nw.nos.boeing.com> <489D13FBFA9B3E41812EA89F188F018E1B5EAA78@xmb-rcd-x04.cisco.com> <2134F8430051B64F815C691A62D9831832CB7C6B@XCH-BLV-505.nw.nos.boeing.com> <489D13FBFA9B3E41812EA89F188F018E1B5EAB30@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1B5EAB30@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/a1RNvWR9AqHH1hAHe1qS5n4i_ZU Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] Informational IPv6 prefix option for DHCPv6 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, 07 Jul 2014 21:02:30 -0000 > I would expect that this is widely implemented. Meets my requirements, then. Many thanks. Fred From nobody Mon Jul 7 22:48:53 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18DB31B28F0 for ; Mon, 7 Jul 2014 22:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.853 X-Spam-Level: X-Spam-Status: No, score=-104.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 PuMkmdJ1Kp88 for ; Mon, 7 Jul 2014 22:48:51 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id A5A591A007C for ; Mon, 7 Jul 2014 22:48:51 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 5B8B718001B; Mon, 7 Jul 2014 22:48:25 -0700 (PDT) To: stevea@lachman.com, droms@bucknell.edu, brian@innovationslab.net, ted.lemon@nominum.com, volz@cisco.com, tomasz.mrugalski@gmail.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20140708054825.5B8B718001B@rfc-editor.org> Date: Mon, 7 Jul 2014 22:48:25 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/4eUvcarCDMz5qI-LmWIkkQHA6n0 Cc: dhcwg@ietf.org, sus-e@ubiquitous.co.jp, rfc-editor@rfc-editor.org Subject: [dhcwg] [Editorial Errata Reported] RFC1533 (4045) 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, 08 Jul 2014 05:48:53 -0000 The following errata report has been submitted for RFC1533, "DHCP Options and BOOTP Vendor Extensions". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=1533&eid=4045 -------------------------------------- Type: Editorial Reported by: Susumu Endoh Section: 3.10 Original Text ------------- The code for the log server option is 8. Corrected Text -------------- The code for the cookie server option is 8. Notes ----- Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC1533 (no draft string recorded) -------------------------------------- Title : DHCP Options and BOOTP Vendor Extensions Publication Date : October 1993 Author(s) : S. Alexander, R. Droms Category : PROPOSED STANDARD Source : Dynamic Host Configuration Area : Internet Stream : IETF Verifying Party : IESG From nobody Tue Jul 8 02:11:11 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A631B27A2; Tue, 8 Jul 2014 02:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.343 X-Spam-Level: X-Spam-Status: No, score=-2.343 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 yd0u-t3TiLbU; Tue, 8 Jul 2014 02:11:04 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8F5F1A0154; Tue, 8 Jul 2014 02:11:03 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id s689B17i026893; Tue, 8 Jul 2014 18:11:01 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id s689B1C5029576; Tue, 8 Jul 2014 18:11:01 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id UAA29571; Tue, 8 Jul 2014 18:11:01 +0900 Received: from mx11.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id s689B0WT000522; Tue, 8 Jul 2014 18:11:00 +0900 (JST) Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id s689B0GL016702; Tue, 8 Jul 2014 18:11:00 +0900 (JST) Received: from [133.199.18.253] (ivpn-3-253.mobile.toshiba.co.jp [133.199.18.253]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id 1CF6097D24; Tue, 8 Jul 2014 18:11:00 +0900 (JST) Message-ID: <53BBA43B.3080207@toshiba.co.jp> Date: Tue, 08 Jul 2014 16:56:43 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Bernie Volz (volz)" , Andre Kostur References: <20140701155803.14047.81610.idtracker@ietfa.amsl.com> <53BA92D9.3000606@toshiba.co.jp> <489D13FBFA9B3E41812EA89F188F018E1B5E9CA7@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1B5E9CA7@xmb-rcd-x04.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/K-1cfpSW8NHPbc9DwLqAHyZV0uk Cc: "dhcwg@ietf.org" , Routing Over Low power and Lossy networks Subject: Re: [dhcwg] MPL config draft (Re: [Roll] I-D Action: draft-ietf-roll-mpl-parameter-configuration-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, 08 Jul 2014 09:11:06 -0000 Hi Bernie, Thank you for comments, (2014-07-08 2:19), Bernie Volz (volz) wrote: > Not sure I'd suggest adding 10 (or 11) options for this? > > But I certainly would suggest, as Andre did, much simpler values - > flags and "compressed" data just make for much more complex and > error prone processing on both client and server. A structure which > would have all these values but in a much more standard set of data > formats would be better. -2 for compressed data. I'd like to make 'uncompressed' version and check if it's acceptable for roll-ish network. > Perhaps there is a middle grown to have groups of values (i.e., have > 3-4 options)? I'm really not that familiar with MPL, but perhaps > there are some logical groupings that make sense (seems that there > are data and control messages would could be one logical > separation). Ah, so your suggestion is to have (for example) three options?: 1) MPL Base configuration (P, SE_LIFETIME, {MPL Domain}) 2) MPL Control channel configuration (C_K, C_MIN, C_MAX, C_T_EXP, {MPL Domain}) 3) MPL Data channel configuration (D_K, D_MIN, D_MAX, D_T_EXI, {MPL Domain}) For me, duplication of MPL domain (128bit address x 3) seems to be wasteful. > Might also be nice in the Abstract to define MPL? Thanks, I'll add a definition. Yusuke From nobody Tue Jul 8 02:14:07 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D50A1B27A8; Tue, 8 Jul 2014 02:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.877 X-Spam-Level: X-Spam-Status: No, score=-2.877 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FF_IHOPE_YOU_SINK=2.166, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 IiWnxEdz02-Q; Tue, 8 Jul 2014 02:14:04 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B73011B27A3; Tue, 8 Jul 2014 02:14:03 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id s689E2af002095; Tue, 8 Jul 2014 18:14:02 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id s689E2us020337; Tue, 8 Jul 2014 18:14:02 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id UAA20336; Tue, 8 Jul 2014 18:14:02 +0900 Received: from mx9.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id s689E1tH017473; Tue, 8 Jul 2014 18:14:01 +0900 (JST) Received: from mx.toshiba.co.jp by toshiba.co.jp id s689CvWS005136; Tue, 8 Jul 2014 18:12:57 +0900 (JST) Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id s689AuBT012979; Tue, 8 Jul 2014 18:10:56 +0900 (JST) Received: from [133.199.18.253] (ivpn-3-253.mobile.toshiba.co.jp [133.199.18.253]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id C810397D24; Tue, 8 Jul 2014 18:10:56 +0900 (JST) Message-ID: <53BBA3EF.9040609@toshiba.co.jp> Date: Tue, 08 Jul 2014 16:55:27 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Andre Kostur References: <20140701155803.14047.81610.idtracker@ietfa.amsl.com> <53BA92D9.3000606@toshiba.co.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/QgRUyNsfb_mKKHsE2dn4AsKM1x4 Cc: "dhcwg@ietf.org" , Routing Over Low power and Lossy networks Subject: Re: [dhcwg] MPL config draft (Re: [Roll] I-D Action: draft-ietf-roll-mpl-parameter-configuration-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, 08 Jul 2014 09:14:05 -0000 Hi Andre, Thank you for the comments. I think I need to explain background more. 1) Typical MAC we're expecting is 50k-200kbps mesh network with 5+ hops. I think a compact option format is more suitable for the case. 2) A parameter set is bound for an MPL domain. A network may have multiple MPL domains. I think it is much simpler to handle all parameters as a set. (2014-07-08 01:32), Andre Kostur wrote: > A couple of quick thoughts (keeping in mind RFC 7227 - Guidelines for > Creating New DHCPv6 Options): > > - An encoded option is frowned upon. Split all of those into separate > options, and the "Reserved" parts simply disappear. A "sub-optioned" > option is also frowned upon (section 9, RFC 7227). As described above, the parameters are considered as a set. I could not find recommended design for parameter sets. More than one parameter set will be configured. To make them separated I think each option should be with MPL domain (= IPv6 address). > - Why add the additional complexity of the floating point? Why not > use a 32-bit unsigned integer representing milliseconds which gets you > a little over 40 days? Not the 18 weeks that you currently can > represent, but is there a practical use for timers over a month long > in MPL? The motivation behind the floating point is to reduce message length as much as possible. As MPL has 7 timers, it will reduce 14 bytes. Though, usually 40 days should be enough and this is just a tradeoff (I'm not insisting on the floating point format). > - If you do go with separate options, consider what it would mean if > certain options don't exist. ietf-roll-trickle-mcast appears to > define defaults, perhaps reference that draft to say that if an option > is missing, the client is to use the default defined in that draft? If the draft goes with separate options, I agree it should be the default values. > - Speaking of RFC 7227... I-D.ietf-dhc-option-guidelines got published in May Thank you. Yusuke From nobody Tue Jul 8 10:44:30 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4931A0368 for ; Tue, 8 Jul 2014 10:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 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.651, 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 USgjdTyEU-9i for ; Tue, 8 Jul 2014 10:44:24 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF0B61A0370 for ; Tue, 8 Jul 2014 10:44:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16146; q=dns/txt; s=iport; t=1404841464; x=1406051064; h=from:to:cc:subject:date:message-id:mime-version; bh=M4clYZeuKsPErN1jHPdgsP+YptuodkFD4g0oALMrWjw=; b=l2/9Of97AFoUZPKnZ7adQzARhLBI3B9SDlzoZ6n7NW5ATH24gUEhqe1+ 5jWJmqNMyFjYLV3cYFkoY+DDcIRDtHaTyIQR/Oi00wNL+Xeu/rKRnyoBJ 15FTZx5ZZGlgKnDjUSItpfsZx78TR2EalFnIunXOkpbGxeo3q0+yk4ur5 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAD0tvFOtJV2b/2dsb2JhbABZgkdHUlrGTAGBGBZ1hAUBBC1MEgEqViYBBA4NDIguyEAXjxExgzSBFgWWXJgmg0OCMA X-IronPort-AV: E=Sophos;i="5.01,626,1400025600"; d="scan'208,217";a="338567292" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 08 Jul 2014 17:44:23 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s68HiMgK004963 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Jul 2014 17:44:22 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.176]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Tue, 8 Jul 2014 12:44:22 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: Rechartering DHC Thread-Index: Ac+a05n8XkU/Hj48QOawc8gptzAesg== Date: Tue, 8 Jul 2014 17:44:21 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1B5EB66A@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.70.117] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1B5EB66Axmbrcdx04ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/Mpzyhpv1EMT2NrSus49aYWrP7ZI Cc: "int-ads@tools.ietf.org" Subject: [dhcwg] Rechartering DHC 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, 08 Jul 2014 17:44:27 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E1B5EB66Axmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello: We are proposing to update the DHC WG charter. This update is fairly minor = in that the current charter (07) is revised as follows: 1. Updates the list of items being worked on (in bullet 1) - removing= those items that we have completed and adding those items adopted by the W= G. 2. Removing #2 (NTP option update). 3. Removing #3 (option guidelines). 4. Fixing a typo in old #8 (problems replaced with specifications) - = this is now #6. The updated proposed charter text is below. Please comment to the WG and ADs. We will quickly cover this charter update= at the Toronto IETF. - Bernie and Tomek Charter for Working Group The Dynamic Host Configuration working group (DHC WG) has developed DHCP for automated allocation, configuration and management of IP addresses and TCP/IP protocol stack parameters. DHCPv4 is currently a Draft Standard and is documented in RFC 2131 and RFC 2132. DHCPv6 is currently a Proposed Standard and is documented in RFC 3315. Subsequent RFCs document additional options and other enhancements to the specifications. The DHC WG is responsible for defining DHCP protocol extensions. Definitions of new DHCP options that are delivered using standard mechanisms with documented semantics are not considered a protocol extension and thus are outside of scope for the DHC WG. Such options should be defined within their respective WGs and reviewed by the DHCP Directorate. However, if such options require protocol extensions or new semantics, the protocol extension work must be done in the DHC WG. The DHC WG has the following main objectives: 1. Develop extensions to the DHCPv6 infrastructure as required to meet new applications and deployments of DHCP. The topics currently in development are: - DHCPv6 Stateful issues - DHCPv6 Failover - DHCPv6 Load Balancing - Extending DHCPv6 to work with multiple provisioning domains - DHCP provisioning of IPv4 clients over IPv6 networks - Access Network Identifier options - DNS registration for SLAAC - Active leasequery - Secure DHCPv6 with Public Key - Dynamic Allocation of Shared IPv4 Addresses Additional topics may only be added with approval from the responsible Area Director or by re-chartering. 2. Develop documents that help explain operational considerations for the wider community. 3. Issue updated versions of the DHCP base specifications-- RFC 3315 (DHCPv6), RFC 3633 (DHCPv6 Prefix Delegation) and RFC 3736 (Stateless DHCPv6) so as to fix errata and bring the documents to the point where they can advance along the IETF Standards Track. 4. In the process of updating the DHCP base specifications, in cases where time is of the essence, issue corrections and clarifications of the specifications in order to quickly address interoperability problems. 5. Write analyses and interoperability reports on existing DHC documents, including base specs. 6. When serious interoperability problems are found in other DHCP specifications, issue updated versions of those specifications to address the interoperability problems. --_000_489D13FBFA9B3E41812EA89F188F018E1B5EB66Axmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello:

 

We are proposing to update the DHC WG charter. This = update is fairly minor in that the current charter (07) is revised as follo= ws:

 

1.     &= nbsp; Updates the list of items being worked on (in bulle= t 1) – removing those items that we have completed and adding those i= tems adopted by the WG.

2.     &= nbsp; Removing #2 (NTP option update).

3.     &= nbsp; Removing #3 (option guidelines).

4.     &= nbsp; Fixing a typo in old #8 (problems replaced with spe= cifications) – this is now #6.

 

The updated proposed charter text is below.

 

Please comment to the WG and ADs. We will quickly co= ver this charter update at the Toronto IETF.

 

-     &= nbsp;    Bernie and Tomek

 

 

Charter for Working Group

 

The Dynamic Host Configuration working group (DHC WG= ) has developed DHCP

for automated allocation, configuration and manageme= nt of IP addresses

and TCP/IP protocol stack parameters. DHCPv4 is curr= ently a Draft

Standard and is documented in RFC 2131 and RFC 2132.= DHCPv6 is currently

a Proposed Standard and is documented in RFC 3315. S= ubsequent RFCs

document additional options and other enhancements t= o the specifications.

 

The DHC WG is responsible for defining DHCP protocol= extensions.

Definitions of new DHCP options that are delivered u= sing standard

mechanisms with documented semantics are not conside= red a protocol

extension and thus are outside of scope for the DHC = WG. Such options

should be defined within their respective WGs and re= viewed by the DHCP

Directorate. However, if such options require protoc= ol extensions or new

semantics, the protocol extension work must be done = in the DHC WG.

 

The DHC WG has the following main objectives:

 

1. Develop extensions to the DHCPv6 infrastructure a= s required to meet

new applications and deployments of DHCP. The topics= currently in

development are:

- DHCPv6 Stateful issues

- DHCPv6 Failover

- DHCPv6 Load Balancing

- Extending DHCPv6 to work with multiple provisionin= g domains

- DHCP provisioning of IPv4 clients over IPv6 networ= ks

- Access Network Identifier options

- DNS registration for SLAAC

- Active leasequery

- Secure DHCPv6 with Public Key

- Dynamic Allocation of Shared IPv4 Addresses

 

Additional topics may only be added with approval fr= om the responsible

Area Director or by re-chartering.

 

2. Develop documents that help explain operational c= onsiderations for

the wider community.

 

3. Issue updated versions of the DHCP base specifica= tions--

RFC 3315 (DHCPv6), RFC 3633 (DHCPv6 Prefix Delegatio= n) and

RFC 3736 (Stateless DHCPv6) so as to fix errata and = bring

the documents to the point where they can advance al= ong the

IETF Standards Track.

 

4. In the process of updating the DHCP base specific= ations, in

cases where time is of the essence, issue correction= s and

clarifications of the specifications in order to qui= ckly address

interoperability problems.

 

5. Write analyses and interoperability reports on ex= isting DHC

documents, including base specs.

 

6. When serious interoperability problems are found = in other DHCP

specifications, issue updated versions of those spec= ifications to

address the interoperability problems.

--_000_489D13FBFA9B3E41812EA89F188F018E1B5EB66Axmbrcdx04ciscoc_-- From nobody Tue Jul 8 11:09:28 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6713A1A0370 for ; Tue, 8 Jul 2014 11:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IC8uCucu1fB for ; Tue, 8 Jul 2014 11:09:22 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 891421A0165 for ; Tue, 8 Jul 2014 11:09:21 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id n3so1451784wiv.15 for ; Tue, 08 Jul 2014 11:09:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=KTuNreh1fgxITXLsM3VAoyFBtBHFB2QYXd0lw92ZtIM=; b=qnWbEIiU5BQ5wnROC0SJtxIXhrzDhzycEe6EDuhUTrwmRHrdvR13DFyeliA1nKb0ET GA4+/t6zYP1VglkEX7HFaeuNFC/CqkT54FIQWxiCNNKfo9cXAgpYtulcy2NJ8iOCzMCR r5thSf48s6FT6uHEDjniRo1ferdRum/mfNr31ckpDHcSGYnVk7wQKY2FifDJB1xrTfUC UAKo+wSpYHFIBtYUF2aJ2aNK24UppzeA9/BVZtP/ZL0yH9jmIb5CjVpxe+3y19F39f8J WFoU9D5aKIyPBb6j/3pccCyHHdYiB6JtzypA+SH/R/FqJvUn85sijmk+Sru9khTweOgz Q0jA== MIME-Version: 1.0 X-Received: by 10.194.185.238 with SMTP id ff14mr42680816wjc.9.1404842960038; Tue, 08 Jul 2014 11:09:20 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.63.211 with HTTP; Tue, 8 Jul 2014 11:09:19 -0700 (PDT) In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1B5E03D1@xmb-rcd-x04.cisco.com> References: <20140630163351.4191.69719.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E1B5E03D1@xmb-rcd-x04.cisco.com> Date: Tue, 8 Jul 2014 11:09:19 -0700 X-Google-Sender-Auth: 95z7XUxkGLbzbq41vf7PDXpwmD4 Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: "Bernie Volz (volz)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/5qpkL1cCZ-VV3Mns9uzRDe8idjM Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.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, 08 Jul 2014 18:09:23 -0000 On Mon, Jun 30, 2014 at 9:55 AM, Bernie Volz (volz) wrote: > Anyway, give the current draft a read and if there are concerns or questions (or you have a view on the issue), please send mail to the list ASAP. Now, I'm going to make my complete review comments on the draft. I'll begin with a set of overall comments at a higher level. I'll send specific comments on the draft text separately. With the understanding that this draft intends to specify the general case of using multiple types of IAs including yet-to-define future ones, I think it will need to discuss many more points. For example: - (forgetting IA_TA for now) it seems to assume all IAs have the concept of "T1" and "T2", and it always (or at least generally) makes sense to use the same T1/T2 values for all IAs for a specific DHCPv6 session. Can we safely assume that? May or may not be so, but even if so, I think such an assumption is explicitly noted. - likewise, it seems to assume all IAs have the concept of "lifetimes". Same discussion as the first bullet applies here. - there seems to be some implicit assumption on the normal case operation, e.g.: in normal cases, a set of IAs that can be bound by servers is the same for all available servers; otherwise, the following case will cause a suboptimal situation for the client: + the client would like bindings for IA1 and IA2 + server A can provide a binding for IA1 but not for IA2 + server B can provide a binding for IA2 but not for IA1 According to the approach described in the draft, the client should have a single DHCPv6 session for both IAs and choose either server A or B. In either case the client can only get a binding for one of the two IAs; if the client can have separate DHCPv6 sessions for these IAs, it can get bindings for both IAs. I'm not necessarily saying we shouldn't impose this assumption. In fact, such an assumption would probably be reasonable in many cases in practice (would be certainly so for the mix of IA_NA and IA_PD). But the assumption isn't obvious, so IMO we should explicitly clarify that (and, ideally, how we should consider when the assumption isn't met; whether we should declare it as out of scope, whether we should explicitly prohibit it using an RFC2119 keyword, etc). - Similarly, it seems to be assumed that when a server could provide bindings for IA1 and IA2: + the server can provide bindings for both IA1 and IA2, or, + it can provide a binding for neither IA1 nor IA2. Otherwise, the following case will become suboptimal for the client: + the client would like bindings for IA1 and IA2 + the server provides binding for IA1. a binding for IA2 is temporarily unavailable. + the client will need to wait until T1 expires to get a binding for IA2, even if the binding is actually available immediately after the Request-Reply exchange. And then there's the point of how to handle IA_TA. In addition to the mere fact that it doesn't have T1 and T2 (see above about the assumptions), I suspect its nature of non-renewability makes the situation complicated in more fundamental way. Suppose a client wants to get IA_TA and IA_NA (or any other IA_xx than IA_TA). According to the draft the client will have a single DHCPv6 session for both IAs and (hopefully) get bindings for them. Then, at time T1 (of IA_NA), specifically what should the client do? Just excluding IA_TA in the renew message? Maybe this is okay, but then what should it do when the binding for IA_TA (is about to) expires? In practice the client should need another temporary address before the expiration, but should the client now request another IA_TA binding in the existing DHCPv6 session? If so, how? If not, should it start a separate DHCPv6 session for the new IA_TA? But in that case it breaks the proposed model where the client should have a single session for all IAs. As long as we include IA_TA in the discussion, I don't think we can leave these questions open. One option would be to completely exclude IA_TA from the discussion and declare that we only consider IAs that have the concept of T1 and T2. That will make the discussion a lot easier and simpler, and would make sense especially if we even consider deprecate the concept of IA_TA (as briefly mentioned, IIRC, in the discussion on the previous version of the draft). Finally, and also somehow related to the points discussed above, I think this document will have to clarify the relationship between a DHCPv6 session and state of IAs in more detail. A simple diagram of state transition of IA based on RFC3315 would look like this: http://gyazo.com/40653139343151e40e25cc0937c192f1 (a png image) The stateful-issues draft would introduce another state named something like "unbound" since a DHCPv6 session can conceptually include an IA that is not yet assigned by the server. Also, the stateful-issues draft specifically discusses the case with multiple IAs for a single DHCPv6 session, so conceptually we need to think about multiple these diagrams and how they affect the DHCPv6 session. Right now, it only shows how a client (and server) should do focusing on DHCPv6 message handling (just following RFC3315), but the concept is now more complicated and it seems to me that we need some more architectural description...I know this comment may sound vague. I'm not sure specifically how I'd suggest addressing it at the moment, but at least I'd feel there are too many open points in the current shape draft if I were to try to implement it and would need something more specific. -- JINMEI, Tatuya From nobody Tue Jul 8 11:44:23 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1A6F1A0409 for ; Tue, 8 Jul 2014 11:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.852 X-Spam-Level: X-Spam-Status: No, score=-14.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 r8hFhKcv0lfz for ; Tue, 8 Jul 2014 11:44:21 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9C341A02FE for ; Tue, 8 Jul 2014 11:44:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11360; q=dns/txt; s=iport; t=1404845061; x=1406054661; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=yb4+nUmqp6msdNQ/RQ02cyxwSytkrUPEXP5w8YhCDnc=; b=YipcZFAzWvOzBjg0T8BMVjdd9VhG0MU2Xx9tkSsSsYHH9fwAkAw5G7Fv Zv9r/dSlysO8n//3KSxHOsDmeWIaT9nN9kINNQSuxcX109aOLl1lUUkcv e+9CWi2jd9X4rx+CX3QrTJQ4MMGwjnu4ywZKbTUzucSk8daGTjG7WO915 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhM4ABA7vFOtJV2b/2dsb2JhbABagw5SWoF0e7wdh0EBGX8WdYQDAQEBAwEjET4HBQcEAgEIEQQBAQMCBh0DAgICHxEUAQgIAgQOBQiIJgMJCA2STpwWkzQNhX0XgSyGbYR/gUgKBgIBHhYQCwcGgnE2gRYFmHaDSIwwhhSDQ3B+Bx0e X-IronPort-AV: E=Sophos;i="5.01,626,1400025600"; d="scan'208";a="338576056" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 08 Jul 2014 18:44:20 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s68IiJmx015157 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Jul 2014 18:44:19 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.176]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Tue, 8 Jul 2014 13:44:19 -0500 From: "Bernie Volz (volz)" To: =?utf-8?B?56We5piO6YGU5ZOJ?= Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.txt Thread-Index: AQHPlIEus6CA5H78HkuHLmw+Sv8Eh5uJ3xfAgAz7MYD//7IjoA== Date: Tue, 8 Jul 2014 18:44:19 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1B5EC22D@xmb-rcd-x04.cisco.com> References: <20140630163351.4191.69719.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E1B5E03D1@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.70.117] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/w5C0nFnpwtGDcr5sn95sEOAfqOI Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.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, 08 Jul 2014 18:44:23 -0000 SGkgSmlubWVpOg0KDQpodHRwOi8vZ3lhem8uY29tLzQwNjUzMTM5MzQzMTUxZTQwZTI1Y2MwOTM3 YzE5MmYxIGRpZG4ndCB3b3JrIGZvciBtZS4NCg0KUmVnYXJkaW5nIElBX1RBLCB5ZXMgSSBnZW5l cmFsbHkgYWdyZWUgd2l0aCB5b3UgdGhhdCB0aGVzZSBhcmUgcHJvYmFibHkgbW9zdGx5IGluZGVw ZW5kZW50IHRyYW5zYWN0aW9ucy4gSXQgbWF5IHN0YXJ0IG91dCB0aGF0IHRoZSBmaXJzdCBTb2xp Y2l0L1JlcXVlc3QgY3ljbGUgaW5jbHVkZXMgdGhlIElBX1RBLCBidXQgcHJvYmFibHkgdGhlc2Ug bGlmZXRpbWVzIGFuZCBjbGllbnQgdXNhZ2Ugb2YgdGhlbSwgd291bGQgbWVhbiB0aGF0IGZ1dHVy ZSBJQV9UQSBSZXF1ZXN0cyB3b3VsZCBsaWtlbHkgYmUgc2VwYXJhdGUuIEFsc28sIEkgdGhpbmsg dGhlIG1vZGVsIGZvciBJQV9UQSBpcyB0aGF0IGEgY2xpZW50IG1pZ2h0IGdldCB0aGVtIG9ubHkg d2hlbiBpdCBuZWVkcyB0aGVtIChpLmUuLCBzb21lIGFwcGxpY2F0aW9uIHN0YXJ0cyB0aGF0IHdh bnRzIGEgcHJpdmFjeSBhZGRyZXNzKS4gUmVuZXdhbHMgd291bGQgb25seSBiZSBuZWVkZWQgZm9y IHRoZXNlIGlmIHRoZSBhcHBsaWNhdGlvbiB3YW50ZWQgdG8gKGhvcGVmdWxseSkgY29udGludWUg IHVzaW5nIHRoZSB0ZW1wb3JhcnkgYWRkcmVzcyB3aGVuIHRoZSBsaWZldGltZSBpcyBuZWFyIGV4 cGlyYXRpb24gLSBoZW5jZSBpdCBpcyBhIHNlcGFyYXRlIHNldCBvZiB0cmFuc2FjdGlvbnMuDQoN CkkgdGhpbmsgSSBzYWlkIHNvIGluIGFuIGVhcmxpZXIgZW1haWwsIGJ1dCBtaWdodCBiZSBhbiBp bnRlcmVzdGluZyBxdWVzdGlvbiBhcyB0byB3aGV0aGVyIHRvIERFUFJFQ0FURSBJQV9UQXMuIFRo ZWlyIHZhbHVlIGlzIGxpbWl0ZWQgaW4gYSBESENQdjYgZW52aXJvbm1lbnQuIFRoYXQgaXMgcHJv YmFibHkgYSBnb29kIGlzc3VlIHRvIGFkZCB0byB0aGUgVG9yb250byBkaXNjdXNzaW9uLg0KDQpX ZSBwcm9iYWJseSBuZWVkIHRvIGFkZCB3b3JkcyB0aGF0IGV4cGxhaW4gYXNzdW1wdGlvbj8gQWdh aW4gd2UgZG9uJ3Qgd2FudCB0byBwcmVjbHVkZSB0aGVtIGJlaW5nIGluY2x1ZGVkIChpLmUuIGlu IGluaXRpYWwgZXhjaGFuZ2UpLCBidXQgSUFfVEEgd2lsbCBsaWtlbHkgcmVxdWlyZSBhIGNsaWVu dCB0byBoYXZlIHNlcGFyYXRlIHRyYW5zYWN0aW9ucyB3aXRoIHRoZSBzZXJ2ZXIgLSBidXQgYWdh aW4sIHRoaXMgZGVwZW5kcyBvbiB0aGUgY2xpZW50J3MgbW9kZWwgYW5kIHNlcnZpY2VzLiBUaGVy ZSBpc24ndCBhbnl0aGluZyB0aGF0IHdvdWxkIHByb2hpYml0IGEgY2xpZW50IHRvIHNlbmQgYSBS ZW5ldyB3aGVuIHRoZSBJQV9UQSBuZWVkcyB0byBiZSByZW5ld2VkIC8gcmVmcmVzaGVkIHRoYXQg aW5jbHVkZXMgdGhlIElBX05BIGFuZCBJQV9QRCBhbmQgaGF2aW5nIHRoZW0gYWxsIHJlbmV3ZWQu KQ0KDQpBIGZldyBtb3JlIGNvbW1lbnRzIGlubGluZSBiZWxvdyAoQlY+KS4NCg0KLSBCZXJuaWUN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGppbm1laS50YXR1eWFAZ21haWwu Y29tIFttYWlsdG86amlubWVpLnRhdHV5YUBnbWFpbC5jb21dIE9uIEJlaGFsZiBPZiA/Pz8/DQpT ZW50OiBUdWVzZGF5LCBKdWx5IDA4LCAyMDE0IDI6MDkgUE0NClRvOiBCZXJuaWUgVm9seiAodm9s eikNCkNjOiBkaGN3Z0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtkaGN3Z10gSS1EIEFjdGlvbjog ZHJhZnQtaWV0Zi1kaGMtZGhjcHY2LXN0YXRlZnVsLWlzc3Vlcy0wNi50eHQNCg0KT24gTW9uLCBK dW4gMzAsIDIwMTQgYXQgOTo1NSBBTSwgQmVybmllIFZvbHogKHZvbHopIDx2b2x6QGNpc2NvLmNv bT4gd3JvdGU6DQoNCj4gQW55d2F5LCBnaXZlIHRoZSBjdXJyZW50IGRyYWZ0IGEgcmVhZCBhbmQg aWYgdGhlcmUgYXJlIGNvbmNlcm5zIG9yIHF1ZXN0aW9ucyAob3IgeW91IGhhdmUgYSB2aWV3IG9u IHRoZSBpc3N1ZSksIHBsZWFzZSBzZW5kIG1haWwgdG8gdGhlIGxpc3QgQVNBUC4NCg0KTm93LCBJ J20gZ29pbmcgdG8gbWFrZSBteSBjb21wbGV0ZSByZXZpZXcgY29tbWVudHMgb24gdGhlIGRyYWZ0 LiAgSSdsbCBiZWdpbiB3aXRoIGEgc2V0IG9mIG92ZXJhbGwgY29tbWVudHMgYXQgYSBoaWdoZXIg bGV2ZWwuICBJJ2xsIHNlbmQgc3BlY2lmaWMgY29tbWVudHMgb24gdGhlIGRyYWZ0IHRleHQgc2Vw YXJhdGVseS4NCg0KV2l0aCB0aGUgdW5kZXJzdGFuZGluZyB0aGF0IHRoaXMgZHJhZnQgaW50ZW5k cyB0byBzcGVjaWZ5IHRoZSBnZW5lcmFsIGNhc2Ugb2YgdXNpbmcgbXVsdGlwbGUgdHlwZXMgb2Yg SUFzIGluY2x1ZGluZyB5ZXQtdG8tZGVmaW5lIGZ1dHVyZSBvbmVzLCBJIHRoaW5rIGl0IHdpbGwg bmVlZCB0byBkaXNjdXNzIG1hbnkgbW9yZSBwb2ludHMuICBGb3IgZXhhbXBsZToNCg0KLSAoZm9y Z2V0dGluZyBJQV9UQSBmb3Igbm93KSBpdCBzZWVtcyB0byBhc3N1bWUgYWxsIElBcyBoYXZlIHRo ZQ0KICBjb25jZXB0IG9mICJUMSIgYW5kICJUMiIsIGFuZCBpdCBhbHdheXMgKG9yIGF0IGxlYXN0 IGdlbmVyYWxseSkNCiAgbWFrZXMgc2Vuc2UgdG8gdXNlIHRoZSBzYW1lIFQxL1QyIHZhbHVlcyBm b3IgYWxsIElBcyBmb3IgYSBzcGVjaWZpYw0KICBESENQdjYgc2Vzc2lvbi4gIENhbiB3ZSBzYWZl bHkgYXNzdW1lIHRoYXQ/ICBNYXkgb3IgbWF5IG5vdCBiZSBzbywNCiAgYnV0IGV2ZW4gaWYgc28s IEkgdGhpbmsgc3VjaCBhbiBhc3N1bXB0aW9uIGlzIGV4cGxpY2l0bHkgbm90ZWQuDQoNCg0KQlY+ IFRoYXQgaXMgd2hhdCB0aGUgU3RhdGVmdWwgRHJhZnQgc2F5cyB0byBkby4gVGhlIHNlcnZlciBT SE9VTEQgc2VuZCBvbmUgc2V0IG9mIHZhbHVlcyAoc2FtZSBpbiBlYWNoIElBX05BL0lBX1BEKS4g QnV0IGFzIHNlcnZlcnMgbWlnaHQgbm90IHlldCBiZSB1cGRhdGVkLCB0aGUgY2xpZW50IHNob3Vs ZCB1c2UgdGhlICdzaG9ydGVzdCcgc2V0IG9mIFQxL1QyIHZhbHVlcyBhY3Jvc3MgdGhlIElBX05B L0lBX1BEcy4NCg0KLSBsaWtld2lzZSwgaXQgc2VlbXMgdG8gYXNzdW1lIGFsbCBJQXMgaGF2ZSB0 aGUgY29uY2VwdCBvZg0KICAibGlmZXRpbWVzIi4gIFNhbWUgZGlzY3Vzc2lvbiBhcyB0aGUgZmly c3QgYnVsbGV0IGFwcGxpZXMgaGVyZS4NCi0gdGhlcmUgc2VlbXMgdG8gYmUgc29tZSBpbXBsaWNp dCBhc3N1bXB0aW9uIG9uIHRoZSBub3JtYWwgY2FzZQ0KICBvcGVyYXRpb24sIGUuZy46IGluIG5v cm1hbCBjYXNlcywgYSBzZXQgb2YgSUFzIHRoYXQgY2FuIGJlIGJvdW5kDQogIGJ5IHNlcnZlcnMg aXMgdGhlIHNhbWUgZm9yIGFsbCBhdmFpbGFibGUgc2VydmVyczsgb3RoZXJ3aXNlLCB0aGUNCiAg Zm9sbG93aW5nIGNhc2Ugd2lsbCBjYXVzZSBhIHN1Ym9wdGltYWwgc2l0dWF0aW9uIGZvciB0aGUg Y2xpZW50Og0KICArIHRoZSBjbGllbnQgd291bGQgbGlrZSBiaW5kaW5ncyBmb3IgSUExIGFuZCBJ QTINCiAgKyBzZXJ2ZXIgQSBjYW4gcHJvdmlkZSBhIGJpbmRpbmcgZm9yIElBMSBidXQgbm90IGZv ciBJQTINCiAgKyBzZXJ2ZXIgQiBjYW4gcHJvdmlkZSBhIGJpbmRpbmcgZm9yIElBMiBidXQgbm90 IGZvciBJQTENCiAgQWNjb3JkaW5nIHRvIHRoZSBhcHByb2FjaCBkZXNjcmliZWQgaW4gdGhlIGRy YWZ0LCB0aGUgY2xpZW50IHNob3VsZA0KICBoYXZlIGEgc2luZ2xlIERIQ1B2NiBzZXNzaW9uIGZv ciBib3RoIElBcyBhbmQgY2hvb3NlIGVpdGhlciBzZXJ2ZXIgQQ0KICBvciBCLiAgSW4gZWl0aGVy IGNhc2UgdGhlIGNsaWVudCBjYW4gb25seSBnZXQgYSBiaW5kaW5nIGZvciBvbmUgb2YNCiAgdGhl IHR3byBJQXM7IGlmIHRoZSBjbGllbnQgY2FuIGhhdmUgc2VwYXJhdGUgREhDUHY2IHNlc3Npb25z IGZvcg0KICB0aGVzZSBJQXMsIGl0IGNhbiBnZXQgYmluZGluZ3MgZm9yIGJvdGggSUFzLiAgSSdt IG5vdCBuZWNlc3NhcmlseQ0KICBzYXlpbmcgd2Ugc2hvdWxkbid0IGltcG9zZSB0aGlzIGFzc3Vt cHRpb24uICBJbiBmYWN0LCBzdWNoIGFuDQogIGFzc3VtcHRpb24gd291bGQgcHJvYmFibHkgYmUg cmVhc29uYWJsZSBpbiBtYW55IGNhc2VzIGluIHByYWN0aWNlDQogICh3b3VsZCBiZSBjZXJ0YWlu bHkgc28gZm9yIHRoZSBtaXggb2YgSUFfTkEgYW5kIElBX1BEKS4gIEJ1dCB0aGUNCiAgYXNzdW1w dGlvbiBpc24ndCBvYnZpb3VzLCBzbyBJTU8gd2Ugc2hvdWxkIGV4cGxpY2l0bHkgY2xhcmlmeSB0 aGF0DQogIChhbmQsIGlkZWFsbHksIGhvdyB3ZSBzaG91bGQgY29uc2lkZXIgd2hlbiB0aGUgYXNz dW1wdGlvbiBpc24ndCBtZXQ7DQogIHdoZXRoZXIgd2Ugc2hvdWxkIGRlY2xhcmUgaXQgYXMgb3V0 IG9mIHNjb3BlLCB3aGV0aGVyIHdlIHNob3VsZA0KICBleHBsaWNpdGx5IHByb2hpYml0IGl0IHVz aW5nIGFuIFJGQzIxMTkga2V5d29yZCwgZXRjKS4NCg0KQlY+IFllcywgSSBiZWxpZXZlIHRoYXQg aGFzICdhbHdheXMnIGJlZW4gdGhlIGFzc3VtcHRpb24uIFRoZXJlIGlzbid0IGFuIGlzc3VlIGlm IGEgY2xpZW50IHdhbnRlZCB0byBtYWludGFpbiBzZXBhcmF0ZSBzZXRzIG9mIHRyYW5zYWN0aW9u cywgYnV0IGluIGdlbmVyYWwgd2UgZG9uJ3QgZmVlbCBjbGllbnRzIG5lZWQgKG9yIHdhbnQpIHRo YXQgY29tcGxleGl0eS4NCg0KLSBTaW1pbGFybHksIGl0IHNlZW1zIHRvIGJlIGFzc3VtZWQgdGhh dCB3aGVuIGEgc2VydmVyIGNvdWxkIHByb3ZpZGUNCiAgYmluZGluZ3MgZm9yIElBMSBhbmQgSUEy Og0KICArIHRoZSBzZXJ2ZXIgY2FuIHByb3ZpZGUgYmluZGluZ3MgZm9yIGJvdGggSUExIGFuZCBJ QTIsIG9yLA0KICArIGl0IGNhbiBwcm92aWRlIGEgYmluZGluZyBmb3IgbmVpdGhlciBJQTEgbm9y IElBMi4NCiAgT3RoZXJ3aXNlLCB0aGUgZm9sbG93aW5nIGNhc2Ugd2lsbCBiZWNvbWUgc3Vib3B0 aW1hbCBmb3IgdGhlIGNsaWVudDoNCiAgKyB0aGUgY2xpZW50IHdvdWxkIGxpa2UgYmluZGluZ3Mg Zm9yIElBMSBhbmQgSUEyDQogICsgdGhlIHNlcnZlciBwcm92aWRlcyBiaW5kaW5nIGZvciBJQTEu ICBhIGJpbmRpbmcgZm9yIElBMiBpcw0KICAgIHRlbXBvcmFyaWx5IHVuYXZhaWxhYmxlLg0KICAr IHRoZSBjbGllbnQgd2lsbCBuZWVkIHRvIHdhaXQgdW50aWwgVDEgZXhwaXJlcyB0byBnZXQgYSBi aW5kaW5nDQogICAgZm9yIElBMiwgZXZlbiBpZiB0aGUgYmluZGluZyBpcyBhY3R1YWxseSBhdmFp bGFibGUgaW1tZWRpYXRlbHkNCiAgICBhZnRlciB0aGUgUmVxdWVzdC1SZXBseSBleGNoYW5nZS4N CkJWPiBUaGVyZSBpcyBhbHdheXMgdGhlIFJlY29uZmlndXJlIGZyb20gdGhlIHNlcnZlciB0aGF0 IGNvdWxkIGJlIHVzZWQgYnkgdGhlIHNlcnZlci4NCkJWPiBUaGVyZSBjb3VsZCBiZSBvdGhlciBh Y3Rpb25zIGJ5L29uIHRoZSBjbGllbnQgdGhhdCBjb3VsZCB0cmlnZ2VyIGFuIGVhcmxpZXIgZXhj aGFuZ2UsIGJ1dCB5ZXMgaW4gZ2VuZXJhbCB0aGF0IHdvdWxkIGJlIHRoZSBjYXNlLg0KDQpBbmQg dGhlbiB0aGVyZSdzIHRoZSBwb2ludCBvZiBob3cgdG8gaGFuZGxlIElBX1RBLiAgSW4gYWRkaXRp b24gdG8gdGhlIG1lcmUgZmFjdCB0aGF0IGl0IGRvZXNuJ3QgaGF2ZSBUMSBhbmQgVDIgKHNlZSBh Ym92ZSBhYm91dCB0aGUgYXNzdW1wdGlvbnMpLCBJIHN1c3BlY3QgaXRzIG5hdHVyZSBvZiBub24t cmVuZXdhYmlsaXR5IG1ha2VzIHRoZSBzaXR1YXRpb24gY29tcGxpY2F0ZWQgaW4gbW9yZSBmdW5k YW1lbnRhbCB3YXkuICBTdXBwb3NlIGEgY2xpZW50IHdhbnRzIHRvIGdldCBJQV9UQSBhbmQgSUFf TkEgKG9yIGFueSBvdGhlciBJQV94eCB0aGFuIElBX1RBKS4gIEFjY29yZGluZyB0byB0aGUgZHJh ZnQgdGhlIGNsaWVudCB3aWxsIGhhdmUgYSBzaW5nbGUgREhDUHY2IHNlc3Npb24gZm9yIGJvdGgg SUFzIGFuZCAoaG9wZWZ1bGx5KSBnZXQgYmluZGluZ3MgZm9yIHRoZW0uICBUaGVuLCBhdCB0aW1l IFQxIChvZiBJQV9OQSksIHNwZWNpZmljYWxseSB3aGF0IHNob3VsZCB0aGUgY2xpZW50IGRvPyAg SnVzdCBleGNsdWRpbmcgSUFfVEEgaW4gdGhlIHJlbmV3IG1lc3NhZ2U/ICBNYXliZSB0aGlzIGlz IG9rYXksIGJ1dCB0aGVuIHdoYXQgc2hvdWxkIGl0IGRvIHdoZW4gdGhlIGJpbmRpbmcgZm9yIElB X1RBIChpcyBhYm91dCB0bykgZXhwaXJlcz8gIEluIHByYWN0aWNlIHRoZSBjbGllbnQgc2hvdWxk IG5lZWQgYW5vdGhlciB0ZW1wb3JhcnkgYWRkcmVzcyBiZWZvcmUgdGhlIGV4cGlyYXRpb24sIGJ1 dCBzaG91bGQgdGhlIGNsaWVudCBub3cgcmVxdWVzdCBhbm90aGVyIElBX1RBIGJpbmRpbmcgaW4g dGhlIGV4aXN0aW5nDQpESENQdjYgc2Vzc2lvbj8gIElmIHNvLCBob3c/ICBJZiBub3QsIHNob3Vs ZCBpdCBzdGFydCBhIHNlcGFyYXRlDQpESENQdjYgc2Vzc2lvbiBmb3IgdGhlIG5ldyBJQV9UQT8g IEJ1dCBpbiB0aGF0IGNhc2UgaXQgYnJlYWtzIHRoZSBwcm9wb3NlZCBtb2RlbCB3aGVyZSB0aGUg Y2xpZW50IHNob3VsZCBoYXZlIGEgc2luZ2xlIHNlc3Npb24gZm9yIGFsbCBJQXMuICBBcyBsb25n IGFzIHdlIGluY2x1ZGUgSUFfVEEgaW4gdGhlIGRpc2N1c3Npb24sIEkgZG9uJ3QgdGhpbmsgd2Ug Y2FuIGxlYXZlIHRoZXNlIHF1ZXN0aW9ucyBvcGVuLg0KDQpPbmUgb3B0aW9uIHdvdWxkIGJlIHRv IGNvbXBsZXRlbHkgZXhjbHVkZSBJQV9UQSBmcm9tIHRoZSBkaXNjdXNzaW9uIGFuZCBkZWNsYXJl IHRoYXQgd2Ugb25seSBjb25zaWRlciBJQXMgdGhhdCBoYXZlIHRoZSBjb25jZXB0IG9mIFQxIGFu ZCBUMi4gIFRoYXQgd2lsbCBtYWtlIHRoZSBkaXNjdXNzaW9uIGEgbG90IGVhc2llciBhbmQgc2lt cGxlciwgYW5kIHdvdWxkIG1ha2Ugc2Vuc2UgZXNwZWNpYWxseSBpZiB3ZSBldmVuIGNvbnNpZGVy IGRlcHJlY2F0ZSB0aGUgY29uY2VwdCBvZiBJQV9UQSAoYXMgYnJpZWZseSBtZW50aW9uZWQsIElJ UkMsIGluIHRoZSBkaXNjdXNzaW9uIG9uIHRoZSBwcmV2aW91cyB2ZXJzaW9uIG9mIHRoZSBkcmFm dCkuDQoNCkZpbmFsbHksIGFuZCBhbHNvIHNvbWVob3cgcmVsYXRlZCB0byB0aGUgcG9pbnRzIGRp c2N1c3NlZCBhYm92ZSwgSSB0aGluayB0aGlzIGRvY3VtZW50IHdpbGwgaGF2ZSB0byBjbGFyaWZ5 IHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiBhIERIQ1B2NiBzZXNzaW9uIGFuZCBzdGF0ZSBvZiBJ QXMgaW4gbW9yZSBkZXRhaWwuICBBIHNpbXBsZSBkaWFncmFtIG9mIHN0YXRlIHRyYW5zaXRpb24g b2YgSUEgYmFzZWQgb24gUkZDMzMxNSB3b3VsZCBsb29rIGxpa2UgdGhpczoNCmh0dHA6Ly9neWF6 by5jb20vNDA2NTMxMzkzNDMxNTFlNDBlMjVjYzA5MzdjMTkyZjEgKGEgcG5nIGltYWdlKSBUaGUg c3RhdGVmdWwtaXNzdWVzIGRyYWZ0IHdvdWxkIGludHJvZHVjZSBhbm90aGVyIHN0YXRlIG5hbWVk IHNvbWV0aGluZyBsaWtlICJ1bmJvdW5kIiBzaW5jZSBhIERIQ1B2NiBzZXNzaW9uIGNhbiBjb25j ZXB0dWFsbHkgaW5jbHVkZSBhbiBJQSB0aGF0IGlzIG5vdCB5ZXQgYXNzaWduZWQgYnkgdGhlIHNl cnZlci4gIEFsc28sIHRoZSBzdGF0ZWZ1bC1pc3N1ZXMgZHJhZnQgc3BlY2lmaWNhbGx5IGRpc2N1 c3NlcyB0aGUgY2FzZSB3aXRoIG11bHRpcGxlIElBcyBmb3IgYSBzaW5nbGUgREhDUHY2IHNlc3Np b24sIHNvIGNvbmNlcHR1YWxseSB3ZSBuZWVkIHRvIHRoaW5rIGFib3V0IG11bHRpcGxlIHRoZXNl IGRpYWdyYW1zIGFuZCBob3cgdGhleSBhZmZlY3QgdGhlIERIQ1B2NiBzZXNzaW9uLg0KUmlnaHQg bm93LCBpdCBvbmx5IHNob3dzIGhvdyBhIGNsaWVudCAoYW5kIHNlcnZlcikgc2hvdWxkIGRvIGZv Y3VzaW5nIG9uIERIQ1B2NiBtZXNzYWdlIGhhbmRsaW5nIChqdXN0IGZvbGxvd2luZyBSRkMzMzE1 KSwgYnV0IHRoZSBjb25jZXB0IGlzIG5vdyBtb3JlIGNvbXBsaWNhdGVkIGFuZCBpdCBzZWVtcyB0 byBtZSB0aGF0IHdlIG5lZWQgc29tZSBtb3JlIGFyY2hpdGVjdHVyYWwgZGVzY3JpcHRpb24uLi5J IGtub3cgdGhpcyBjb21tZW50IG1heSBzb3VuZCB2YWd1ZS4gIEknbSBub3Qgc3VyZSBzcGVjaWZp Y2FsbHkgaG93IEknZCBzdWdnZXN0IGFkZHJlc3NpbmcgaXQgYXQgdGhlIG1vbWVudCwgYnV0IGF0 IGxlYXN0IEknZCBmZWVsIHRoZXJlIGFyZSB0b28gbWFueSBvcGVuIHBvaW50cyBpbiB0aGUgY3Vy cmVudCBzaGFwZSBkcmFmdCBpZiBJIHdlcmUgdG8gdHJ5IHRvIGltcGxlbWVudCBpdCBhbmQgd291 bGQgbmVlZCBzb21ldGhpbmcgbW9yZSBzcGVjaWZpYy4NCg0KQlY+IFllYWgsIGJ1dCBJIHdvdWxk IGhvcGUgd2UgYXJlIG1vdmluZyBmb3J3YXJkIChtdWNoIGJldHRlciB0aGFuIGN1cnJlbnQgc3Rh dGUgb2YgMzMxNS8zNjMzKSB3aGljaCBwZW9wbGUgc2VlbSB0byBoYXZlIHdvcmtlZCBhcm91bmQg ZmFpcmx5IHdlbGwuDQoNCi0tDQpKSU5NRUksIFRhdHV5YQ0K From nobody Tue Jul 8 11:44:57 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAFF31A0416 for ; Tue, 8 Jul 2014 11:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.852 X-Spam-Level: X-Spam-Status: No, score=-14.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 msOHSJRYdoub for ; Tue, 8 Jul 2014 11:44:54 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B742D1A0403 for ; Tue, 8 Jul 2014 11:44:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11820; q=dns/txt; s=iport; t=1404845099; x=1406054699; h=from:to:cc:subject:date:message-id:references: content-transfer-encoding:mime-version; bh=7KjChrzeMG/DZUAOE1fZDRrMGroe1/u1tVyoULAw9X8=; b=hunbnSi3azgP0NIEjK+fx8+cMKWNncK8BMmd5/ofLMJl3qNy0o6Zj79Q 5XW/Ru79XbNJp3jA3G0On7tOFzjwCmmoddZSMGdqxrE8m7jM6EPymu6rP EWFeD4RYekbOIZRNvWT0hX8KKCZsoAcBDbPajo3ji0enXQf4cyy131S8j U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQ4AMM7vFOtJA2D/2dsb2JhbABagw5SWoF0e7wdh0EBGX8WdYQDAQEBAwEjET4HBQcEAgEGAhEEAQEDAgYdAwICAh8RFAEICAIEDgUIiCYDCQgNkkERnBaTNA2FfReBLIZthH+BSAoGAgEeFhALDYJxNoEWBZh2g0iMMIYUg0NwfgcdHg X-IronPort-AV: E=Sophos;i="5.01,626,1400025600"; d="scan'208";a="59221807" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-7.cisco.com with ESMTP; 08 Jul 2014 18:44:58 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s68IiqLj005234 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Jul 2014 18:44:52 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.176]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Tue, 8 Jul 2014 13:44:52 -0500 From: "Bernie Volz (volz)" To: =?utf-8?B?56We5piO6YGU5ZOJ?= Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.txt Thread-Index: AQHPlIEus6CA5H78HkuHLmw+Sv8Eh5uJ3xfAgAz7MYD//7IjoIAAA99w Date: Tue, 8 Jul 2014 18:44:51 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1B5EC249@xmb-rcd-x04.cisco.com> References: <20140630163351.4191.69719.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E1B5E03D1@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.70.117] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/xjJRQwejB9n6TTPtuMpgqzh7FVc Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.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, 08 Jul 2014 18:44:55 -0000 T2ggLi4uIHRoZSBsaW5rIGZpbmFsbHkgZGlkIHdvcmsgLS0ganVzdCB0b29rIGEgd2hpbGUgKGl0 IGNvbXBsZXRlZCB3aGlsZSBJIHdhcyB3cml0aW5nIHRoZSBlbWFpbCBiZWxvdykuDQoNCi0gQmVy bmllDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBCZXJuaWUgVm9seiAodm9s eikgDQpTZW50OiBUdWVzZGF5LCBKdWx5IDA4LCAyMDE0IDI6NDQgUE0NClRvOiAn56We5piO6YGU 5ZOJJw0KQ2M6IGRoY3dnQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW2RoY3dnXSBJLUQgQWN0aW9u OiBkcmFmdC1pZXRmLWRoYy1kaGNwdjYtc3RhdGVmdWwtaXNzdWVzLTA2LnR4dA0KDQpIaSBKaW5t ZWk6DQoNCmh0dHA6Ly9neWF6by5jb20vNDA2NTMxMzkzNDMxNTFlNDBlMjVjYzA5MzdjMTkyZjEg ZGlkbid0IHdvcmsgZm9yIG1lLg0KDQpSZWdhcmRpbmcgSUFfVEEsIHllcyBJIGdlbmVyYWxseSBh Z3JlZSB3aXRoIHlvdSB0aGF0IHRoZXNlIGFyZSBwcm9iYWJseSBtb3N0bHkgaW5kZXBlbmRlbnQg dHJhbnNhY3Rpb25zLiBJdCBtYXkgc3RhcnQgb3V0IHRoYXQgdGhlIGZpcnN0IFNvbGljaXQvUmVx dWVzdCBjeWNsZSBpbmNsdWRlcyB0aGUgSUFfVEEsIGJ1dCBwcm9iYWJseSB0aGVzZSBsaWZldGlt ZXMgYW5kIGNsaWVudCB1c2FnZSBvZiB0aGVtLCB3b3VsZCBtZWFuIHRoYXQgZnV0dXJlIElBX1RB IFJlcXVlc3RzIHdvdWxkIGxpa2VseSBiZSBzZXBhcmF0ZS4gQWxzbywgSSB0aGluayB0aGUgbW9k ZWwgZm9yIElBX1RBIGlzIHRoYXQgYSBjbGllbnQgbWlnaHQgZ2V0IHRoZW0gb25seSB3aGVuIGl0 IG5lZWRzIHRoZW0gKGkuZS4sIHNvbWUgYXBwbGljYXRpb24gc3RhcnRzIHRoYXQgd2FudHMgYSBw cml2YWN5IGFkZHJlc3MpLiBSZW5ld2FscyB3b3VsZCBvbmx5IGJlIG5lZWRlZCBmb3IgdGhlc2Ug aWYgdGhlIGFwcGxpY2F0aW9uIHdhbnRlZCB0byAoaG9wZWZ1bGx5KSBjb250aW51ZSAgdXNpbmcg dGhlIHRlbXBvcmFyeSBhZGRyZXNzIHdoZW4gdGhlIGxpZmV0aW1lIGlzIG5lYXIgZXhwaXJhdGlv biAtIGhlbmNlIGl0IGlzIGEgc2VwYXJhdGUgc2V0IG9mIHRyYW5zYWN0aW9ucy4NCg0KSSB0aGlu ayBJIHNhaWQgc28gaW4gYW4gZWFybGllciBlbWFpbCwgYnV0IG1pZ2h0IGJlIGFuIGludGVyZXN0 aW5nIHF1ZXN0aW9uIGFzIHRvIHdoZXRoZXIgdG8gREVQUkVDQVRFIElBX1RBcy4gVGhlaXIgdmFs dWUgaXMgbGltaXRlZCBpbiBhIERIQ1B2NiBlbnZpcm9ubWVudC4gVGhhdCBpcyBwcm9iYWJseSBh IGdvb2QgaXNzdWUgdG8gYWRkIHRvIHRoZSBUb3JvbnRvIGRpc2N1c3Npb24uDQoNCldlIHByb2Jh Ymx5IG5lZWQgdG8gYWRkIHdvcmRzIHRoYXQgZXhwbGFpbiBhc3N1bXB0aW9uPyBBZ2FpbiB3ZSBk b24ndCB3YW50IHRvIHByZWNsdWRlIHRoZW0gYmVpbmcgaW5jbHVkZWQgKGkuZS4gaW4gaW5pdGlh bCBleGNoYW5nZSksIGJ1dCBJQV9UQSB3aWxsIGxpa2VseSByZXF1aXJlIGEgY2xpZW50IHRvIGhh dmUgc2VwYXJhdGUgdHJhbnNhY3Rpb25zIHdpdGggdGhlIHNlcnZlciAtIGJ1dCBhZ2FpbiwgdGhp cyBkZXBlbmRzIG9uIHRoZSBjbGllbnQncyBtb2RlbCBhbmQgc2VydmljZXMuIFRoZXJlIGlzbid0 IGFueXRoaW5nIHRoYXQgd291bGQgcHJvaGliaXQgYSBjbGllbnQgdG8gc2VuZCBhIFJlbmV3IHdo ZW4gdGhlIElBX1RBIG5lZWRzIHRvIGJlIHJlbmV3ZWQgLyByZWZyZXNoZWQgdGhhdCBpbmNsdWRl cyB0aGUgSUFfTkEgYW5kIElBX1BEIGFuZCBoYXZpbmcgdGhlbSBhbGwgcmVuZXdlZC4pDQoNCkEg ZmV3IG1vcmUgY29tbWVudHMgaW5saW5lIGJlbG93IChCVj4pLg0KDQotIEJlcm5pZQ0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogamlubWVpLnRhdHV5YUBnbWFpbC5jb20gW21h aWx0bzpqaW5tZWkudGF0dXlhQGdtYWlsLmNvbV0gT24gQmVoYWxmIE9mID8/Pz8NClNlbnQ6IFR1 ZXNkYXksIEp1bHkgMDgsIDIwMTQgMjowOSBQTQ0KVG86IEJlcm5pZSBWb2x6ICh2b2x6KQ0KQ2M6 IGRoY3dnQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2RoY3dnXSBJLUQgQWN0aW9uOiBkcmFmdC1p ZXRmLWRoYy1kaGNwdjYtc3RhdGVmdWwtaXNzdWVzLTA2LnR4dA0KDQpPbiBNb24sIEp1biAzMCwg MjAxNCBhdCA5OjU1IEFNLCBCZXJuaWUgVm9seiAodm9seikgPHZvbHpAY2lzY28uY29tPiB3cm90 ZToNCg0KPiBBbnl3YXksIGdpdmUgdGhlIGN1cnJlbnQgZHJhZnQgYSByZWFkIGFuZCBpZiB0aGVy ZSBhcmUgY29uY2VybnMgb3IgcXVlc3Rpb25zIChvciB5b3UgaGF2ZSBhIHZpZXcgb24gdGhlIGlz c3VlKSwgcGxlYXNlIHNlbmQgbWFpbCB0byB0aGUgbGlzdCBBU0FQLg0KDQpOb3csIEknbSBnb2lu ZyB0byBtYWtlIG15IGNvbXBsZXRlIHJldmlldyBjb21tZW50cyBvbiB0aGUgZHJhZnQuICBJJ2xs IGJlZ2luIHdpdGggYSBzZXQgb2Ygb3ZlcmFsbCBjb21tZW50cyBhdCBhIGhpZ2hlciBsZXZlbC4g IEknbGwgc2VuZCBzcGVjaWZpYyBjb21tZW50cyBvbiB0aGUgZHJhZnQgdGV4dCBzZXBhcmF0ZWx5 Lg0KDQpXaXRoIHRoZSB1bmRlcnN0YW5kaW5nIHRoYXQgdGhpcyBkcmFmdCBpbnRlbmRzIHRvIHNw ZWNpZnkgdGhlIGdlbmVyYWwgY2FzZSBvZiB1c2luZyBtdWx0aXBsZSB0eXBlcyBvZiBJQXMgaW5j bHVkaW5nIHlldC10by1kZWZpbmUgZnV0dXJlIG9uZXMsIEkgdGhpbmsgaXQgd2lsbCBuZWVkIHRv IGRpc2N1c3MgbWFueSBtb3JlIHBvaW50cy4gIEZvciBleGFtcGxlOg0KDQotIChmb3JnZXR0aW5n IElBX1RBIGZvciBub3cpIGl0IHNlZW1zIHRvIGFzc3VtZSBhbGwgSUFzIGhhdmUgdGhlDQogIGNv bmNlcHQgb2YgIlQxIiBhbmQgIlQyIiwgYW5kIGl0IGFsd2F5cyAob3IgYXQgbGVhc3QgZ2VuZXJh bGx5KQ0KICBtYWtlcyBzZW5zZSB0byB1c2UgdGhlIHNhbWUgVDEvVDIgdmFsdWVzIGZvciBhbGwg SUFzIGZvciBhIHNwZWNpZmljDQogIERIQ1B2NiBzZXNzaW9uLiAgQ2FuIHdlIHNhZmVseSBhc3N1 bWUgdGhhdD8gIE1heSBvciBtYXkgbm90IGJlIHNvLA0KICBidXQgZXZlbiBpZiBzbywgSSB0aGlu ayBzdWNoIGFuIGFzc3VtcHRpb24gaXMgZXhwbGljaXRseSBub3RlZC4NCg0KDQpCVj4gVGhhdCBp cyB3aGF0IHRoZSBTdGF0ZWZ1bCBEcmFmdCBzYXlzIHRvIGRvLiBUaGUgc2VydmVyIFNIT1VMRCBz ZW5kIG9uZSBzZXQgb2YgdmFsdWVzIChzYW1lIGluIGVhY2ggSUFfTkEvSUFfUEQpLiBCdXQgYXMg c2VydmVycyBtaWdodCBub3QgeWV0IGJlIHVwZGF0ZWQsIHRoZSBjbGllbnQgc2hvdWxkIHVzZSB0 aGUgJ3Nob3J0ZXN0JyBzZXQgb2YgVDEvVDIgdmFsdWVzIGFjcm9zcyB0aGUgSUFfTkEvSUFfUERz Lg0KDQotIGxpa2V3aXNlLCBpdCBzZWVtcyB0byBhc3N1bWUgYWxsIElBcyBoYXZlIHRoZSBjb25j ZXB0IG9mDQogICJsaWZldGltZXMiLiAgU2FtZSBkaXNjdXNzaW9uIGFzIHRoZSBmaXJzdCBidWxs ZXQgYXBwbGllcyBoZXJlLg0KLSB0aGVyZSBzZWVtcyB0byBiZSBzb21lIGltcGxpY2l0IGFzc3Vt cHRpb24gb24gdGhlIG5vcm1hbCBjYXNlDQogIG9wZXJhdGlvbiwgZS5nLjogaW4gbm9ybWFsIGNh c2VzLCBhIHNldCBvZiBJQXMgdGhhdCBjYW4gYmUgYm91bmQNCiAgYnkgc2VydmVycyBpcyB0aGUg c2FtZSBmb3IgYWxsIGF2YWlsYWJsZSBzZXJ2ZXJzOyBvdGhlcndpc2UsIHRoZQ0KICBmb2xsb3dp bmcgY2FzZSB3aWxsIGNhdXNlIGEgc3Vib3B0aW1hbCBzaXR1YXRpb24gZm9yIHRoZSBjbGllbnQ6 DQogICsgdGhlIGNsaWVudCB3b3VsZCBsaWtlIGJpbmRpbmdzIGZvciBJQTEgYW5kIElBMg0KICAr IHNlcnZlciBBIGNhbiBwcm92aWRlIGEgYmluZGluZyBmb3IgSUExIGJ1dCBub3QgZm9yIElBMg0K ICArIHNlcnZlciBCIGNhbiBwcm92aWRlIGEgYmluZGluZyBmb3IgSUEyIGJ1dCBub3QgZm9yIElB MQ0KICBBY2NvcmRpbmcgdG8gdGhlIGFwcHJvYWNoIGRlc2NyaWJlZCBpbiB0aGUgZHJhZnQsIHRo ZSBjbGllbnQgc2hvdWxkDQogIGhhdmUgYSBzaW5nbGUgREhDUHY2IHNlc3Npb24gZm9yIGJvdGgg SUFzIGFuZCBjaG9vc2UgZWl0aGVyIHNlcnZlciBBDQogIG9yIEIuICBJbiBlaXRoZXIgY2FzZSB0 aGUgY2xpZW50IGNhbiBvbmx5IGdldCBhIGJpbmRpbmcgZm9yIG9uZSBvZg0KICB0aGUgdHdvIElB czsgaWYgdGhlIGNsaWVudCBjYW4gaGF2ZSBzZXBhcmF0ZSBESENQdjYgc2Vzc2lvbnMgZm9yDQog IHRoZXNlIElBcywgaXQgY2FuIGdldCBiaW5kaW5ncyBmb3IgYm90aCBJQXMuICBJJ20gbm90IG5l Y2Vzc2FyaWx5DQogIHNheWluZyB3ZSBzaG91bGRuJ3QgaW1wb3NlIHRoaXMgYXNzdW1wdGlvbi4g IEluIGZhY3QsIHN1Y2ggYW4NCiAgYXNzdW1wdGlvbiB3b3VsZCBwcm9iYWJseSBiZSByZWFzb25h YmxlIGluIG1hbnkgY2FzZXMgaW4gcHJhY3RpY2UNCiAgKHdvdWxkIGJlIGNlcnRhaW5seSBzbyBm b3IgdGhlIG1peCBvZiBJQV9OQSBhbmQgSUFfUEQpLiAgQnV0IHRoZQ0KICBhc3N1bXB0aW9uIGlz bid0IG9idmlvdXMsIHNvIElNTyB3ZSBzaG91bGQgZXhwbGljaXRseSBjbGFyaWZ5IHRoYXQNCiAg KGFuZCwgaWRlYWxseSwgaG93IHdlIHNob3VsZCBjb25zaWRlciB3aGVuIHRoZSBhc3N1bXB0aW9u IGlzbid0IG1ldDsNCiAgd2hldGhlciB3ZSBzaG91bGQgZGVjbGFyZSBpdCBhcyBvdXQgb2Ygc2Nv cGUsIHdoZXRoZXIgd2Ugc2hvdWxkDQogIGV4cGxpY2l0bHkgcHJvaGliaXQgaXQgdXNpbmcgYW4g UkZDMjExOSBrZXl3b3JkLCBldGMpLg0KDQpCVj4gWWVzLCBJIGJlbGlldmUgdGhhdCBoYXMgJ2Fs d2F5cycgYmVlbiB0aGUgYXNzdW1wdGlvbi4gVGhlcmUgaXNuJ3QgYW4gaXNzdWUgaWYgYSBjbGll bnQgd2FudGVkIHRvIG1haW50YWluIHNlcGFyYXRlIHNldHMgb2YgdHJhbnNhY3Rpb25zLCBidXQg aW4gZ2VuZXJhbCB3ZSBkb24ndCBmZWVsIGNsaWVudHMgbmVlZCAob3Igd2FudCkgdGhhdCBjb21w bGV4aXR5Lg0KDQotIFNpbWlsYXJseSwgaXQgc2VlbXMgdG8gYmUgYXNzdW1lZCB0aGF0IHdoZW4g YSBzZXJ2ZXIgY291bGQgcHJvdmlkZQ0KICBiaW5kaW5ncyBmb3IgSUExIGFuZCBJQTI6DQogICsg dGhlIHNlcnZlciBjYW4gcHJvdmlkZSBiaW5kaW5ncyBmb3IgYm90aCBJQTEgYW5kIElBMiwgb3Is DQogICsgaXQgY2FuIHByb3ZpZGUgYSBiaW5kaW5nIGZvciBuZWl0aGVyIElBMSBub3IgSUEyLg0K ICBPdGhlcndpc2UsIHRoZSBmb2xsb3dpbmcgY2FzZSB3aWxsIGJlY29tZSBzdWJvcHRpbWFsIGZv ciB0aGUgY2xpZW50Og0KICArIHRoZSBjbGllbnQgd291bGQgbGlrZSBiaW5kaW5ncyBmb3IgSUEx IGFuZCBJQTINCiAgKyB0aGUgc2VydmVyIHByb3ZpZGVzIGJpbmRpbmcgZm9yIElBMS4gIGEgYmlu ZGluZyBmb3IgSUEyIGlzDQogICAgdGVtcG9yYXJpbHkgdW5hdmFpbGFibGUuDQogICsgdGhlIGNs aWVudCB3aWxsIG5lZWQgdG8gd2FpdCB1bnRpbCBUMSBleHBpcmVzIHRvIGdldCBhIGJpbmRpbmcN CiAgICBmb3IgSUEyLCBldmVuIGlmIHRoZSBiaW5kaW5nIGlzIGFjdHVhbGx5IGF2YWlsYWJsZSBp bW1lZGlhdGVseQ0KICAgIGFmdGVyIHRoZSBSZXF1ZXN0LVJlcGx5IGV4Y2hhbmdlLg0KQlY+IFRo ZXJlIGlzIGFsd2F5cyB0aGUgUmVjb25maWd1cmUgZnJvbSB0aGUgc2VydmVyIHRoYXQgY291bGQg YmUgdXNlZCBieSB0aGUgc2VydmVyLg0KQlY+IFRoZXJlIGNvdWxkIGJlIG90aGVyIGFjdGlvbnMg Ynkvb24gdGhlIGNsaWVudCB0aGF0IGNvdWxkIHRyaWdnZXIgYW4gZWFybGllciBleGNoYW5nZSwg YnV0IHllcyBpbiBnZW5lcmFsIHRoYXQgd291bGQgYmUgdGhlIGNhc2UuDQoNCkFuZCB0aGVuIHRo ZXJlJ3MgdGhlIHBvaW50IG9mIGhvdyB0byBoYW5kbGUgSUFfVEEuICBJbiBhZGRpdGlvbiB0byB0 aGUgbWVyZSBmYWN0IHRoYXQgaXQgZG9lc24ndCBoYXZlIFQxIGFuZCBUMiAoc2VlIGFib3ZlIGFi b3V0IHRoZSBhc3N1bXB0aW9ucyksIEkgc3VzcGVjdCBpdHMgbmF0dXJlIG9mIG5vbi1yZW5ld2Fi aWxpdHkgbWFrZXMgdGhlIHNpdHVhdGlvbiBjb21wbGljYXRlZCBpbiBtb3JlIGZ1bmRhbWVudGFs IHdheS4gIFN1cHBvc2UgYSBjbGllbnQgd2FudHMgdG8gZ2V0IElBX1RBIGFuZCBJQV9OQSAob3Ig YW55IG90aGVyIElBX3h4IHRoYW4gSUFfVEEpLiAgQWNjb3JkaW5nIHRvIHRoZSBkcmFmdCB0aGUg Y2xpZW50IHdpbGwgaGF2ZSBhIHNpbmdsZSBESENQdjYgc2Vzc2lvbiBmb3IgYm90aCBJQXMgYW5k IChob3BlZnVsbHkpIGdldCBiaW5kaW5ncyBmb3IgdGhlbS4gIFRoZW4sIGF0IHRpbWUgVDEgKG9m IElBX05BKSwgc3BlY2lmaWNhbGx5IHdoYXQgc2hvdWxkIHRoZSBjbGllbnQgZG8/ICBKdXN0IGV4 Y2x1ZGluZyBJQV9UQSBpbiB0aGUgcmVuZXcgbWVzc2FnZT8gIE1heWJlIHRoaXMgaXMgb2theSwg YnV0IHRoZW4gd2hhdCBzaG91bGQgaXQgZG8gd2hlbiB0aGUgYmluZGluZyBmb3IgSUFfVEEgKGlz IGFib3V0IHRvKSBleHBpcmVzPyAgSW4gcHJhY3RpY2UgdGhlIGNsaWVudCBzaG91bGQgbmVlZCBh bm90aGVyIHRlbXBvcmFyeSBhZGRyZXNzIGJlZm9yZSB0aGUgZXhwaXJhdGlvbiwgYnV0IHNob3Vs ZCB0aGUgY2xpZW50IG5vdyByZXF1ZXN0IGFub3RoZXIgSUFfVEEgYmluZGluZyBpbiB0aGUgZXhp c3RpbmcNCkRIQ1B2NiBzZXNzaW9uPyAgSWYgc28sIGhvdz8gIElmIG5vdCwgc2hvdWxkIGl0IHN0 YXJ0IGEgc2VwYXJhdGUNCkRIQ1B2NiBzZXNzaW9uIGZvciB0aGUgbmV3IElBX1RBPyAgQnV0IGlu IHRoYXQgY2FzZSBpdCBicmVha3MgdGhlIHByb3Bvc2VkIG1vZGVsIHdoZXJlIHRoZSBjbGllbnQg c2hvdWxkIGhhdmUgYSBzaW5nbGUgc2Vzc2lvbiBmb3IgYWxsIElBcy4gIEFzIGxvbmcgYXMgd2Ug aW5jbHVkZSBJQV9UQSBpbiB0aGUgZGlzY3Vzc2lvbiwgSSBkb24ndCB0aGluayB3ZSBjYW4gbGVh dmUgdGhlc2UgcXVlc3Rpb25zIG9wZW4uDQoNCk9uZSBvcHRpb24gd291bGQgYmUgdG8gY29tcGxl dGVseSBleGNsdWRlIElBX1RBIGZyb20gdGhlIGRpc2N1c3Npb24gYW5kIGRlY2xhcmUgdGhhdCB3 ZSBvbmx5IGNvbnNpZGVyIElBcyB0aGF0IGhhdmUgdGhlIGNvbmNlcHQgb2YgVDEgYW5kIFQyLiAg VGhhdCB3aWxsIG1ha2UgdGhlIGRpc2N1c3Npb24gYSBsb3QgZWFzaWVyIGFuZCBzaW1wbGVyLCBh bmQgd291bGQgbWFrZSBzZW5zZSBlc3BlY2lhbGx5IGlmIHdlIGV2ZW4gY29uc2lkZXIgZGVwcmVj YXRlIHRoZSBjb25jZXB0IG9mIElBX1RBIChhcyBicmllZmx5IG1lbnRpb25lZCwgSUlSQywgaW4g dGhlIGRpc2N1c3Npb24gb24gdGhlIHByZXZpb3VzIHZlcnNpb24gb2YgdGhlIGRyYWZ0KS4NCg0K RmluYWxseSwgYW5kIGFsc28gc29tZWhvdyByZWxhdGVkIHRvIHRoZSBwb2ludHMgZGlzY3Vzc2Vk IGFib3ZlLCBJIHRoaW5rIHRoaXMgZG9jdW1lbnQgd2lsbCBoYXZlIHRvIGNsYXJpZnkgdGhlIHJl bGF0aW9uc2hpcCBiZXR3ZWVuIGEgREhDUHY2IHNlc3Npb24gYW5kIHN0YXRlIG9mIElBcyBpbiBt b3JlIGRldGFpbC4gIEEgc2ltcGxlIGRpYWdyYW0gb2Ygc3RhdGUgdHJhbnNpdGlvbiBvZiBJQSBi YXNlZCBvbiBSRkMzMzE1IHdvdWxkIGxvb2sgbGlrZSB0aGlzOg0KaHR0cDovL2d5YXpvLmNvbS80 MDY1MzEzOTM0MzE1MWU0MGUyNWNjMDkzN2MxOTJmMSAoYSBwbmcgaW1hZ2UpIFRoZSBzdGF0ZWZ1 bC1pc3N1ZXMgZHJhZnQgd291bGQgaW50cm9kdWNlIGFub3RoZXIgc3RhdGUgbmFtZWQgc29tZXRo aW5nIGxpa2UgInVuYm91bmQiIHNpbmNlIGEgREhDUHY2IHNlc3Npb24gY2FuIGNvbmNlcHR1YWxs eSBpbmNsdWRlIGFuIElBIHRoYXQgaXMgbm90IHlldCBhc3NpZ25lZCBieSB0aGUgc2VydmVyLiAg QWxzbywgdGhlIHN0YXRlZnVsLWlzc3VlcyBkcmFmdCBzcGVjaWZpY2FsbHkgZGlzY3Vzc2VzIHRo ZSBjYXNlIHdpdGggbXVsdGlwbGUgSUFzIGZvciBhIHNpbmdsZSBESENQdjYgc2Vzc2lvbiwgc28g Y29uY2VwdHVhbGx5IHdlIG5lZWQgdG8gdGhpbmsgYWJvdXQgbXVsdGlwbGUgdGhlc2UgZGlhZ3Jh bXMgYW5kIGhvdyB0aGV5IGFmZmVjdCB0aGUgREhDUHY2IHNlc3Npb24uDQpSaWdodCBub3csIGl0 IG9ubHkgc2hvd3MgaG93IGEgY2xpZW50IChhbmQgc2VydmVyKSBzaG91bGQgZG8gZm9jdXNpbmcg b24gREhDUHY2IG1lc3NhZ2UgaGFuZGxpbmcgKGp1c3QgZm9sbG93aW5nIFJGQzMzMTUpLCBidXQg dGhlIGNvbmNlcHQgaXMgbm93IG1vcmUgY29tcGxpY2F0ZWQgYW5kIGl0IHNlZW1zIHRvIG1lIHRo YXQgd2UgbmVlZCBzb21lIG1vcmUgYXJjaGl0ZWN0dXJhbCBkZXNjcmlwdGlvbi4uLkkga25vdyB0 aGlzIGNvbW1lbnQgbWF5IHNvdW5kIHZhZ3VlLiAgSSdtIG5vdCBzdXJlIHNwZWNpZmljYWxseSBo b3cgSSdkIHN1Z2dlc3QgYWRkcmVzc2luZyBpdCBhdCB0aGUgbW9tZW50LCBidXQgYXQgbGVhc3Qg SSdkIGZlZWwgdGhlcmUgYXJlIHRvbyBtYW55IG9wZW4gcG9pbnRzIGluIHRoZSBjdXJyZW50IHNo YXBlIGRyYWZ0IGlmIEkgd2VyZSB0byB0cnkgdG8gaW1wbGVtZW50IGl0IGFuZCB3b3VsZCBuZWVk IHNvbWV0aGluZyBtb3JlIHNwZWNpZmljLg0KDQpCVj4gWWVhaCwgYnV0IEkgd291bGQgaG9wZSB3 ZSBhcmUgbW92aW5nIGZvcndhcmQgKG11Y2ggYmV0dGVyIHRoYW4gY3VycmVudCBzdGF0ZSBvZiAz MzE1LzM2MzMpIHdoaWNoIHBlb3BsZSBzZWVtIHRvIGhhdmUgd29ya2VkIGFyb3VuZCBmYWlybHkg d2VsbC4NCg0KLS0NCkpJTk1FSSwgVGF0dXlhDQo= From nobody Tue Jul 8 13:59:24 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 159281A0076; Tue, 8 Jul 2014 13:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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.651, 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 cadLlR9LfvXg; Tue, 8 Jul 2014 13:59:10 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28C851A005D; Tue, 8 Jul 2014 13:59:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2546; q=dns/txt; s=iport; t=1404853152; x=1406062752; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=MbdbfHrGgvfl6F8aEVP8N9CiNyKA/89mp6jyvO4EFho=; b=CiZXvE9fj8aUCS+9UGSjpXPwhrnlU2LtZyziQh2McuEWg3jdOKpDi/hU 4CgbSavCYUZNEtvRYNmVBwQUwySeOMtqQoTnWolAT06bu3sNnJdFnxkFq YSlS3VrClQwW3WEfkN+XC08+MIOdFcqQwsD2JTKq6WgKmDqaI7cVh6FJV I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFACdbvFOtJA2M/2dsb2JhbABagw6BLMZQAYEaFnWEAwEBAQMBOj8FBwQCAQgRBAEBAQoUBQQHMhQJCAIEAQ0FCIgyCMd6F4l6hGUVHSYLBwaDJ4EWAQSvAoIBgUKCMA X-IronPort-AV: E=Sophos;i="5.01,627,1400025600"; d="scan'208";a="59255687" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-5.cisco.com with ESMTP; 08 Jul 2014 20:59:12 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s68Kx9do031698 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Jul 2014 20:59:09 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.176]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Tue, 8 Jul 2014 15:59:09 -0500 From: "Bernie Volz (volz)" To: Yusuke DOI , Andre Kostur Thread-Topic: [dhcwg] MPL config draft (Re: [Roll] I-D Action: draft-ietf-roll-mpl-parameter-configuration-01.txt) Thread-Index: AQHPmgEd2TBAYfQHIEyalFuCcQCzlpuU2QvAgAFLFYCAAIOPsA== Date: Tue, 8 Jul 2014 20:59:08 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1B5EC66C@xmb-rcd-x04.cisco.com> References: <20140701155803.14047.81610.idtracker@ietfa.amsl.com> <53BA92D9.3000606@toshiba.co.jp> <489D13FBFA9B3E41812EA89F188F018E1B5E9CA7@xmb-rcd-x04.cisco.com> <53BBA43B.3080207@toshiba.co.jp> In-Reply-To: <53BBA43B.3080207@toshiba.co.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.70.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/L_DDI9NP9FJ3JpwdrSvRsXAj-z0 Cc: "dhcwg@ietf.org" , Routing Over Low power and Lossy networks Subject: Re: [dhcwg] MPL config draft (Re: [Roll] I-D Action: draft-ietf-roll-mpl-parameter-configuration-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, 08 Jul 2014 20:59:12 -0000 Hi: I don't have a great answer for you as I have no idea what the typical usag= es are likely to be. If there are likely to be many instances and the desir= e to configure most of the values (and for multiple domains), then one sing= le option for each domain with all of the values is certainly a better idea= . I think the main points here are to: - avoid compressing the data / developing new data types and use more stand= ard elements (i.e., 16 or 32-bit integers) - see RFC 7227. - group things logically (i.e., alignment of the data, while making the pic= ture easier to draw, is not a requirement [of course we assume it is octet = (byte) aligned]). There are many ways to format this data, each with pros and cons. Making th= ose tradeoffs is something I am not in a good position to help you with. - Bernie -----Original Message----- From: Yusuke DOI [mailto:yusuke.doi@toshiba.co.jp]=20 Sent: Tuesday, July 08, 2014 3:57 AM To: Bernie Volz (volz); Andre Kostur Cc: dhcwg@ietf.org; Routing Over Low power and Lossy networks Subject: Re: [dhcwg] MPL config draft (Re: [Roll] I-D Action: draft-ietf-ro= ll-mpl-parameter-configuration-01.txt) Hi Bernie, Thank you for comments, (2014-07-08 2:19), Bernie Volz (volz) wrote: > Not sure I'd suggest adding 10 (or 11) options for this? > > But I certainly would suggest, as Andre did, much simpler values -=20 > flags and "compressed" data just make for much more complex and error=20 > prone processing on both client and server. A structure which would=20 > have all these values but in a much more standard set of data formats=20 > would be better. -2 for compressed data. I'd like to make 'uncompressed' version and check i= f it's acceptable for roll-ish network. > Perhaps there is a middle grown to have groups of values (i.e., have > 3-4 options)? I'm really not that familiar with MPL, but perhaps there=20 > are some logical groupings that make sense (seems that there are data=20 > and control messages would could be one logical separation). Ah, so your suggestion is to have (for example) three options?: 1) MPL Base configuration (P, SE_LIFETIME, {MPL Domain}) 2) MPL Control channel configuration (C_K, C_MIN, C_MAX, C_T_EXP, {MPL Domain}) 3) MPL Data channel configuration (D_K, D_MIN, D_MAX, D_T_EXI, {MPL Domain}) For me, duplication of MPL domain (128bit address x 3) seems to be wasteful= . > Might also be nice in the Abstract to define MPL? Thanks, I'll add a definition. Yusuke From nobody Wed Jul 9 09:38:58 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D4D1A020B for ; Wed, 9 Jul 2014 09:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sIotVBFMjaym for ; Wed, 9 Jul 2014 09:38:53 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DB2A1A0067 for ; Wed, 9 Jul 2014 09:38:53 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id cc10so3108446wib.12 for ; Wed, 09 Jul 2014 09:38:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=2AP4LQj0innJuMRtseUSxu7mNW9LB/EYDeGq0j4ZJNQ=; b=cvmewkU23v4Me3x7aM60iFFPLkWhi7OL/etEidLmASaA8DDqugh7XoIkblgts7Gb2v AjLKdXDx7dgYNX9dxZdVMdMfk1mm6GEJNGWW/AXSCvSwQSchFbL3G0lhY0oPcD8kg5qO TWN0sAxKLhFzzwFjxwQseP9psLmi7S6dFgTaw1Ov2q1C+pzvYoSTDMK2TdST6yFL73G5 vc6zEUvcwBQBRMbfvErKOwI0T/nfe+MaOuPFR+4aYCD/8OUmTlUvBXDFeImqAm6eciFa QfF/Rd1jd7CHl2v93IOQaI81ml5d11+EclKcJHENqxVdq+AIkx9smW8UICwt1IvuetZ0 DHVA== MIME-Version: 1.0 X-Received: by 10.180.80.70 with SMTP id p6mr13042737wix.22.1404923932312; Wed, 09 Jul 2014 09:38:52 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.63.211 with HTTP; Wed, 9 Jul 2014 09:38:52 -0700 (PDT) In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1B5E170B@xmb-rcd-x04.cisco.com> References: <20140630163351.4191.69719.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E1B5E03D1@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1B5E170B@xmb-rcd-x04.cisco.com> Date: Wed, 9 Jul 2014 09:38:52 -0700 X-Google-Sender-Auth: LyZXQ3HP4uhYGK5K7e-EzITLsZ0 Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: "Bernie Volz (volz)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/Jx7gLF5KiP-4AFYIoLUHR_yiHGA Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.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, 09 Jul 2014 16:38:54 -0000 At Mon, 30 Jun 2014 18:19:37 +0000, "Bernie Volz (volz)" wrote: > But because we're making changes to the specifications (i.e., revised sec= tions of 3315, 3633, and even in some cases providing text for possible use= in the 3315bis work), we are indeed trying to cover all IA_* options (whil= e we hope it includes future possible IA_* options, that is more difficult = to achieve as we don't know what those might be). > > >Can I assume that this draft tries to provide a generalized specificatio= n for all current and possible IA_xx [...] > Bottom line is that yes we are trying to accommodate all (existing) IA_* = types. And, in general we've assumed that 3315 has handled IA_NA/IA_TA co-e= xistence sufficiently, so the revised text focuses on included IA_PD handli= ng. The nuance is subtle here, so please let me be sure: which one is (more) correct? 1. this draft excludes the applicability to future possible IA_XXs (i.e., it only covers IA_NA, IA_TA, and IA_PD, and the main motivation is the concurrent use of IA_NA and IA_PD). 2. this draft intends to be applicable to future possible IA_XXs, even if this is currently just a hope (since we don't know the future possibilities right now) and may turn out to be infeasible. My initial interpretation was #2. Am I correct? -- JINMEI, Tatuya From nobody Wed Jul 9 10:07:46 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4673F1A0174 for ; Wed, 9 Jul 2014 10:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.852 X-Spam-Level: X-Spam-Status: No, score=-14.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 QMdzF8VxkU5p for ; Wed, 9 Jul 2014 10:07:42 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C081E1A020B for ; Wed, 9 Jul 2014 10:07:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3450; q=dns/txt; s=iport; t=1404925684; x=1406135284; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=idCti/pBjXLA3XQvwtxsSbXz1U/fg5iscFLZzRYQnAY=; b=UEGFwxvMKOjECfXN/+PRzRw+y8mvQ7VjhisuGbBmCLGglFFtXUF7qdEb 2Fds+cNLDV2SuvoXhx2ywkXtYgRTyIknfuPgvRoHF+wwBXxfPY9cNMKMO X/Pd/eKNxsKqYWCflcoZbpt0x6OCACEab0jOc1iKwObijgT/Y8TCtk+Qd k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAJd1vVOtJA2B/2dsb2JhbABZgw6BLIJvw3IBGXcWdYQDAQEBAwEjEUUFBwQCAQgRBAEBAwIGHQMCAgIfERQBCAgCBA4FCIgmAwkIrnmSdQ2HAReBLItsgXkWEAsHBoJxNoEWBZh2j3iGFINDgjA X-IronPort-AV: E=Sophos;i="5.01,632,1400025600"; d="scan'208";a="59496928" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-3.cisco.com with ESMTP; 09 Jul 2014 17:08:03 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s69H7fJA022424 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Jul 2014 17:07:41 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.176]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Wed, 9 Jul 2014 12:07:40 -0500 From: "Bernie Volz (volz)" To: =?utf-8?B?56We5piO6YGU5ZOJ?= Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.txt Thread-Index: AQHPlIEus6CA5H78HkuHLmw+Sv8Eh5uJ3xfAgABnIoD//6zhMIAOYD0A//+yLrA= Date: Wed, 9 Jul 2014 17:07:40 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1B5EE425@xmb-rcd-x04.cisco.com> References: <20140630163351.4191.69719.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E1B5E03D1@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1B5E170B@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.70.117] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/ZoMkL05Pk5CO2Z-E2TcAv-xLlrA Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.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, 09 Jul 2014 17:07:43 -0000 SGkgSmlubWVpOg0KDQpZZXMsICMyIGlzIG91ciBob3BlLg0KDQotLQ0KDQpJdCBvY2N1cnMgdG8g bWUgdGhhdCBpZiB0aGlzIGFzIHRoaXMgaXMgdGhlIGludGVudCwgd2UgbWlnaHQgd2FudCB0byBk aXNjdXNzIHdoZXRoZXIgdG8gYWRkIGEgbmV3ICJPUFRJT05fVDFUMiIgKG9yIHNvbWUgb3RoZXIg bmFtZSkuIFJlYXNvbnMgd291bGQgYmU6DQoxLiBJdCB3b3VsZCBiZSBhIGdvb2Qgd2F5IGZvciBz ZXJ2ZXJzIHRvIGtub3cgaWYgdGhlIGNsaWVudCBoYXMgYmVlbiB1cGxpZnRlZCBhcyBpbmNsdWRp bmcgdGhpcyBvcHRpb24gY29kZSBpbiB0aGUgT1JPIHdvdWxkIHRlbGwgdGhlIHNlcnZlciB0aGF0 Lg0KMi4gU2VydmVycyB3b3VsZCByZXR1cm4gdGhlIFQxL1QyIGZvciBhbGwgKHJlbmV3YWJsZSkg YmluZGluZ3MgaW4gdGhpcyBvcHRpb24gKGFzIHdlbGwgYXMgc2V0dGluZyB0aGVzZSB2YWx1ZXMg aW4gdGhlIGV4aXN0aW5nIElBX05BL0lBX1BEIG9wdGlvbnMgLSBzZXJ2ZXJzIENPVUxEIHNldCB0 aGVzZSBmaWVsZHMgdG8gMCBpbiB0aGUgSUFfTkEvSUFfUEQgb3B0aW9uIGlmIHJldHVybmluZyB0 aGUgb3B0aW9uIGFzIHJlcXVlc3RlZCBieSB0aGUgY2xpZW50KS4NCjMuIENsaWVudHMgd291bGQg a25vdyBpZiB0aGUgc2VydmVyIHdhcyB1cGxpZnRlZCAoaWYgaXQgcmV0dXJuZWQgdGhpcyBvcHRp b24pLg0KNC4gSXQgd291bGQgcmVtb3ZlIHRoZSBuZWVkIGZvciB0aGVzZSBmaWVsZHMgaW4gYW55 IGZ1dHVyZSBJQV8qIHR5cGUgb3B0aW9ucy4NCg0KSSB0aGluayB0aGlzIGlkZWEgd2FzIHJhaXNl ZCBieSBzb21lb25lIGVsc2UgKE1hcmNpbj8pIGF0IG9uZSB0aW1lICh0aG91Z2ggdGhhdCBtYXkg bm90IGhhdmUgYmVlbiBvbiB0aGUgbGlzdCkuDQoNCi0gQmVybmllDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBqaW5tZWkudGF0dXlhQGdtYWlsLmNvbSBbbWFpbHRvOmppbm1l aS50YXR1eWFAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgPz8/Pw0KU2VudDogV2VkbmVzZGF5LCBK dWx5IDA5LCAyMDE0IDEyOjM5IFBNDQpUbzogQmVybmllIFZvbHogKHZvbHopDQpDYzogZGhjd2dA aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbZGhjd2ddIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtZGhj LWRoY3B2Ni1zdGF0ZWZ1bC1pc3N1ZXMtMDYudHh0DQoNCkF0IE1vbiwgMzAgSnVuIDIwMTQgMTg6 MTk6MzcgKzAwMDAsDQoiQmVybmllIFZvbHogKHZvbHopIiA8dm9sekBjaXNjby5jb20+IHdyb3Rl Og0KDQo+IEJ1dCBiZWNhdXNlIHdlJ3JlIG1ha2luZyBjaGFuZ2VzIHRvIHRoZSBzcGVjaWZpY2F0 aW9ucyAoaS5lLiwgcmV2aXNlZCBzZWN0aW9ucyBvZiAzMzE1LCAzNjMzLCBhbmQgZXZlbiBpbiBz b21lIGNhc2VzIHByb3ZpZGluZyB0ZXh0IGZvciBwb3NzaWJsZSB1c2UgaW4gdGhlIDMzMTViaXMg d29yayksIHdlIGFyZSBpbmRlZWQgdHJ5aW5nIHRvIGNvdmVyIGFsbCBJQV8qIG9wdGlvbnMgKHdo aWxlIHdlIGhvcGUgaXQgaW5jbHVkZXMgZnV0dXJlIHBvc3NpYmxlIElBXyogb3B0aW9ucywgdGhh dCBpcyBtb3JlIGRpZmZpY3VsdCB0byBhY2hpZXZlIGFzIHdlIGRvbid0IGtub3cgd2hhdCB0aG9z ZSBtaWdodCBiZSkuDQo+DQo+ID5DYW4gSSBhc3N1bWUgdGhhdCB0aGlzIGRyYWZ0IHRyaWVzIHRv IHByb3ZpZGUgYSBnZW5lcmFsaXplZCBzcGVjaWZpY2F0aW9uIGZvciBhbGwgY3VycmVudCBhbmQg cG9zc2libGUgSUFfeHgNClsuLi5dDQo+IEJvdHRvbSBsaW5lIGlzIHRoYXQgeWVzIHdlIGFyZSB0 cnlpbmcgdG8gYWNjb21tb2RhdGUgYWxsIChleGlzdGluZykgSUFfKiB0eXBlcy4gQW5kLCBpbiBn ZW5lcmFsIHdlJ3ZlIGFzc3VtZWQgdGhhdCAzMzE1IGhhcyBoYW5kbGVkIElBX05BL0lBX1RBIGNv LWV4aXN0ZW5jZSBzdWZmaWNpZW50bHksIHNvIHRoZSByZXZpc2VkIHRleHQgZm9jdXNlcyBvbiBp bmNsdWRlZCBJQV9QRCBoYW5kbGluZy4NCg0KVGhlIG51YW5jZSBpcyBzdWJ0bGUgaGVyZSwgc28g cGxlYXNlIGxldCBtZSBiZSBzdXJlOiB3aGljaCBvbmUgaXMNCihtb3JlKSBjb3JyZWN0Pw0KMS4g dGhpcyBkcmFmdCBleGNsdWRlcyB0aGUgYXBwbGljYWJpbGl0eSB0byBmdXR1cmUgcG9zc2libGUg SUFfWFhzDQogICAoaS5lLiwgaXQgb25seSBjb3ZlcnMgSUFfTkEsIElBX1RBLCBhbmQgSUFfUEQs IGFuZCB0aGUgbWFpbg0KICAgbW90aXZhdGlvbiBpcyB0aGUgY29uY3VycmVudCB1c2Ugb2YgSUFf TkEgYW5kIElBX1BEKS4NCjIuIHRoaXMgZHJhZnQgaW50ZW5kcyB0byBiZSBhcHBsaWNhYmxlIHRv IGZ1dHVyZSBwb3NzaWJsZSBJQV9YWHMsDQogICBldmVuIGlmIHRoaXMgaXMgY3VycmVudGx5IGp1 c3QgYSBob3BlIChzaW5jZSB3ZSBkb24ndCBrbm93IHRoZQ0KICAgZnV0dXJlIHBvc3NpYmlsaXRp ZXMgcmlnaHQgbm93KSBhbmQgbWF5IHR1cm4gb3V0IHRvIGJlIGluZmVhc2libGUuDQoNCk15IGlu aXRpYWwgaW50ZXJwcmV0YXRpb24gd2FzICMyLiAgQW0gSSBjb3JyZWN0Pw0KDQotLQ0KSklOTUVJ LCBUYXR1eWENCg== From nobody Wed Jul 9 12:02:07 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF631B278D for ; Wed, 9 Jul 2014 12:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5WqOdE9Bk8H for ; Wed, 9 Jul 2014 12:02:01 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B65491A0426 for ; Wed, 9 Jul 2014 12:01:52 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id n12so965465wgh.21 for ; Wed, 09 Jul 2014 12:01:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=7yHEGeXZVxVskr9YQgWXticgwA48018ujvgEVsRERbg=; b=UIpM2cQM4mOGUfqAeMi/UwDUURLKNnbmadGjNXwnUAWAJnlxHwWMdg+UYAojVQWLDB /VouBzabPdxt63pfXni5fz/9J/wM5jTVLcFMvWCpomvbfHgxTbDsYrfzvJOCrW+pveUo uWhkAgUoUrqCj+QaYEM3piWAxOmzTcmYJizcFOPM4TcEjPiJ650j5HuHBfnPU3v4499L ryHdLdXEwes9OUm/BO1ckuTI6DU8gxTiRrQun2/jLj+hmb7q7s6bCZazhgrdWJtOfqvU 5dQNr5MGmbkijWXvX7PL5zUv/AXz4Czl/janUnGecJCOM8++m/8AuvAnd0ybHWT361Dx OWtA== MIME-Version: 1.0 X-Received: by 10.194.89.138 with SMTP id bo10mr50468962wjb.22.1404932511168; Wed, 09 Jul 2014 12:01:51 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.63.211 with HTTP; Wed, 9 Jul 2014 12:01:51 -0700 (PDT) In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1B5EE425@xmb-rcd-x04.cisco.com> References: <20140630163351.4191.69719.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E1B5E03D1@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1B5E170B@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1B5EE425@xmb-rcd-x04.cisco.com> Date: Wed, 9 Jul 2014 12:01:51 -0700 X-Google-Sender-Auth: tmUPRoYtYBkcjYKDm3y-Sjq3PXQ Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: "Bernie Volz (volz)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/k8y0ITtpSk-4V75DTkn9pIlTmHw Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.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, 09 Jul 2014 19:02:03 -0000 At Wed, 9 Jul 2014 17:07:40 +0000, "Bernie Volz (volz)" wrote: > Yes, #2 is our hope. >> The nuance is subtle here, so please let me be sure: which one is >> (more) correct? >> 2. this draft intends to be applicable to future possible IA_XXs, >> even if this is currently just a hope (since we don't know the >> future possibilities right now) and may turn out to be infeasible. Okay, on top of that, this is my comments on the draft body (finally): - Title: maybe we should change it from "issues", since it's not an issue statement (anymore) but actually proposes specific protocols. - General: as briefly discussed separately, I think this document should also describe how the client should handle a Reply to various types of messages based on the revised behavior, with specific revised text against Section 18.1.8 of RFC 3315. I now understand it's included in the plan but is not simply realized in this version, but I'm explicitly mentioning it here so it won't be forgotten. (it would be a good idea to have an "open issues" appendix section for such stuff) - General: as we discussed separately, some of the updates proposed in the draft break backward compatibility. It may or may not be justified (I myself am not really sure about it; I'll need to think about it more), but at least I think the draft should summarize incompatible changes with discussion of how it's justified. - General: the generalization attempt doesn't seem to be complete; in some cases the proposed revised text still only talks about addresses or prefixes, rather than general "resources". I'll point out some of such cases below, but they are not comprehensive. - Introduction: I'd suggest clarifying the intended coverage (the '#2' above) in the introduction section. - Introduction (or in some new section): as discussed separately, this draft imposes some assumption on the definition and usage of (especially future) IAs: + they should have T1/T2 values (with the only exception of IA_TA) + all IAs should share the same set of T1/T2. This also means that it's less likely that we can define a (future) IA that expects extremely shorter/longer T1/T2 (e.g. years or microseconds) in usual operations than other IAs + resources managed in an IA should have some kind of "lifetime". I'd suggest clarifying these assumptions more explicitly somewhere in the document. - Section 1: as long as we choose to include IA_TA in the consideration, this sentence looks awkward to me: IA_TA also has limited value when DHCPv6 is used for address assignment, as the privacy issues identified for IPv6 stateless address assignment ([RFC4941]) do not apply to DHCPv6 assignments. What is stated may (or may not) be true itself, but seems to be an orthogonal topic (it would be very relevant, on the other hand, if we are excluding IA_TA and try to justify it). - Section 3: as I read the draft I felt a bit confused about the difference between "resource" and "stateful options". In some cases I saw the former (latter) is used where the latter (former) may be a better choice. Maybe we can unify these? I'll point out some specific cases where I felt the confusion below. - Section 3: s/An example/Examples/ or s/are/is/ stateful options. An example of the resources are: IPv6 address or an - Section 3: I don't understand what this refers to: (see "identity association for temporary addresses"). - Section 4.1: this is not necessarily accurate, since NoBinding is used for all current IAs (and could also be used for future ones as its concept is quite generic): While a Status Code option is implicitly bound to a specific type of IA, - Section 4.1: s/addresses/some stateful option types/ so the description is generic? With the introduction of multiple IA option types, there might be a case where a server is not willing to offer addresses, but might be willing to offer other stateful option types. BTW, I wonder whether "resources" may be better than "stateful option (types)" in this context (see above). - Section 4.1: this sentence should probably be generalized: Clients MUST be prepared to handle each of the following Advertise messages formats when there are no addresses available (even when no IA_PD was in the Solicit): e.g. by avoiding to use "addresses" or "IA_PD". - Section 4.2: this text should probably be generalized (not hardcoding "address" etc) With (this includes the changes made by [RFC7083]): The client MUST ignore any Advertise message that contains no addresses (IAADDR options encapsulated in IA_NA or IA_TA options) [...] - Section 4.2: maybe this should be generalized: It is important to note that the receipt of an Advertise message without any addresses and delegated prefixes does not imply that the client should restart the Solicit retransmissions timers. - Section 4.3: regarding this behavior: Proposed solution: [...] To deal with the case where servers have not yet been updated to do that, clients MUST use the shortest (explicit or implicit) T1/T2 timer (larger than 0) in any IA options in the Reply. Longer T1/T2 timers are ignored. what should happen if we have two sets of T1/T2? - T1a = 10, T2a = 20 - T1b = 0, T2b = 5 If we pick up the shortests (> 0), T1 would be 10 and T2 would be 5, which is an invalid combination. - Section 4.4.1: this change seems to be too substantial. I'm not necessarily opposed to it, but I cannot be immediately sure if this doesn't have any unexpected bad effect. Besides, what if the server finds it can't create any such binding? Should it return NoBinding just like the old RFC 3315? Replace Section 18.2.3 of RFC 3315: [...] With: If the server cannot find a client entry for the IA the server creates the bindings for that client according to the server's policy and configuration information and returns the IAs and other information requested by the client. - Section 4.4.3: this paragraph is awkward in this context as it describes the server behavior in the context of describing the client behavior (Creation and Transmission of Renew): The server controls the time at which the client contacts the server to extend the lifetimes on client's bindings through the T1 and T2 [...] - Section 4.4.3: why SHOULD? can't (shouldn't) this be a MUST? The server SHOULD assign the same T1 and T2 value to each binding assigned to the client. In this case the - Section 4.4.3: this paragraph seems to say that a client may send a Renew/Rebind for IA_TA. Is that intent? If so, is it a good idea? If T1 or T2 is set to 0 by the server for all IA_NA and IA_PD options, or there are no T1 or T2 times (for an IA_TA), the client may send Renew or Rebind message, respectively, at the client's discretion. - Section 4.4.3: I don't understand why (and actually I'm not really sure what this sentence really tries to say): The client constructing a Renew message SHOULD NOT include resources in IA options that the client does not have. - Section 4.4.3: this paragraph assumes resource for any (future) IAs has *multiple* lifetimes. While it would probably be reasonable to assume resource for an IA generally has "a" lifetime, I'm not so sure if it always have multiple lifetimes (for IA_NA, they are valid and preferred lifetimes. They are very specific to the nature of IPv6 addresses). The same comment applies to some other parts of the draft, but basically I won't repeat it. If the server finds that any resource sent by the client is not appropriate, according to the server's configuration information, the server sends back the IA with the corresponding IA Address (for inappropriate address), IA Prefix option (for inappropriate prefix) or other option appropriate for the type of the resource, with lifetimes set to 0. The client which receives the option with lifetimes set to 0 MUST NOT use the corresponding resource. - Section 4.5.1: is it okay for the Rebind case? Rebind can be handled multiple servers, so multiple servers could end up with creating bindings. If the server cannot find a client entry for the IA and the IA is empty (i.e. contains no addresses), the server MAY assign the addresses to this IA and send a Reply message to the client with this IA containing allocated addresses with lifetimes and T1/T2 times. (BTW: "addresses" should probably be generalized) - Section 4.5.2: this should probably be generalized (and we might revisit the term "*valid* lifetimes", see the next bullet). Also, what if there are multiple IAs? Should this continue until all resource lifetimes of all IAs expire? Or should it stop when all resource lifetimes of some of the IAs expire (maybe the first time it happens)? MRD Remaining time until valid lifetimes of all addresses or prefixes in the IA have expired - Section 4.5.2: this even assumes resource for any (future) IA has a "valid" lifetime. Isn't it too specific for a generic specification? The message exchange is terminated when the valid lifetimes of all the resources assigned to the IA expire, at which time the client has several alternative actions to choose from; for example: - Section 4.5.2: related to the comment about the MRD above, what if the client has multiple IAs? - The client may choose to use a Solicit message to locate a new DHCP server and send a Request for the expired IA to the new server. If the client does this for one IA while (resources of) other IAs still not expired and keeps sending Rebinding for them, doesn't the client end up having multiple DHCPv6 sessions (which this draft tries to avoid)? - Section 4.5.4: maybe "of RFC 3315" should be appended, to be consistent with other part of the text: The server includes other options containing configuration information to be returned to the client as described in section 18.2. - Section 4.7: just wondering: does this describe some specific existing client implementation? Some clients will send a Release message for other bindings they may have received after they determine a conflict and have correctly sent a Decline message for the conflicting address(es). -- JINMEI, Tatuya From nobody Thu Jul 10 10:48:53 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F068F1B2939 for ; Thu, 10 Jul 2014 10:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 i9BeiaZtc_Pd for ; Thu, 10 Jul 2014 10:48:45 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CABE1B2927 for ; Thu, 10 Jul 2014 10:48:44 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id f8so102460wiw.11 for ; Thu, 10 Jul 2014 10:48:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=UGdcf5z5UwofEgiKFGash6YWgB1fkGtczWqccLiCGwE=; b=R3qU0hA7XlGzuTSNmUEE9AGujjQT1rCGMfhylP2PhMu0mK0qo8k+YuCmzMEcHW+PF8 eliEW2fqlH5AR/oWic5YBhxV2tpF7Izz2SIyfxQa6ARb7ibeP0BpD/zJ/vAmzdVzILVk skm5H2VjO/6bEgKskU3PBrP8XgIJC5Z1/Y/bgJaaahp9zOpPd8hCxW1IdwIGqKsXf/3r 9e6ZNAZsF77ALHUujqkdCHYHBGGeIVyZXIrfAz6NNVfAZQYnYl/dmF/HYYX+fZ8W10IB 5UpK48nfBjW0xV82bHoUW6TSM0ab+FGPRqA9wVDLW/4OuTWueKx3DTz/6XZJhikelWD2 YK6Q== X-Received: by 10.180.205.141 with SMTP id lg13mr21275803wic.21.1405014521140; Thu, 10 Jul 2014 10:48:41 -0700 (PDT) Received: from [192.168.8.100] ([5.174.96.239]) by mx.google.com with ESMTPSA id q11sm602374wib.14.2014.07.10.10.48.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Jul 2014 10:48:40 -0700 (PDT) Message-ID: <53BED1F4.8010807@gmail.com> Date: Thu, 10 Jul 2014 19:48:36 +0200 From: Marcin Siodelski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: =?UTF-8?B?56We5piO6YGU5ZOJ?= , "Bernie Volz (volz)" References: <20140630163351.4191.69719.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E1B5E03D1@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1B5E170B@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1B5EE425@xmb-rcd-x04.cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/usMwdhatg9Q61QYBHSFs_IWqh6E Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.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, 10 Jul 2014 17:48:48 -0000 Jinmei, Thanks for the thorough and careful review. I can answer some of the points you raised (see below). Some of them Bernie or Ole may want to address, so I left them not answered. Marcin On 09/07/14 21:01, 神明達哉 wrote: > At Wed, 9 Jul 2014 17:07:40 +0000, > "Bernie Volz (volz)" wrote: > >> Yes, #2 is our hope. > >>> The nuance is subtle here, so please let me be sure: which one is >>> (more) correct? >>> 2. this draft intends to be applicable to future possible IA_XXs, >>> even if this is currently just a hope (since we don't know the >>> future possibilities right now) and may turn out to be infeasible. > > Okay, on top of that, this is my comments on the draft body (finally): > > - Title: maybe we should change it from "issues", since it's not an > issue statement (anymore) but actually proposes specific protocols. > > - General: as briefly discussed separately, I think this document > should also describe how the client should handle a Reply to various > types of messages based on the revised behavior, with specific > revised text against Section 18.1.8 of RFC 3315. I now understand > it's included in the plan but is not simply realized in this > version, but I'm explicitly mentioning it here so it won't be > forgotten. (it would be a good idea to have an "open issues" > appendix section for such stuff) > > - General: as we discussed separately, some of the updates proposed in > the draft break backward compatibility. It may or may not be > justified (I myself am not really sure about it; I'll need to think > about it more), but at least I think the draft should summarize > incompatible changes with discussion of how it's justified. > > - General: the generalization attempt doesn't seem to be complete; in > some cases the proposed revised text still only talks about > addresses or prefixes, rather than general "resources". I'll point > out some of such cases below, but they are not comprehensive. The "stateful-issues" draft is meant to update the RFC3315 and RFC3633 respectively. That's why it refers to the term "address" where it updates RFC3315 and "prefix" where it updates RFC3633. The RFC3315bis work is conducted in parallel to this work and one of the goals is to merge the RFC3633 and RFC3315 and provide the unified text for different IA types. Since, the "stateful-issues" draft addresses various aspects of coexistence of different IA types we thought it may be useful to also include the unified text that can be directly (or easily) ported to the RFC3315bis document. That's why there are separate sections including a unified text for RFC3315bis and in those sections the items carried in the IA options are called "resources". For example: sections 4.1 and 4.2 provide the updates to RFC3315 and RFC3633 respectively and use the term "address"/"prefix". Sections 4.3 and 4.4. present the unified text to be included in the RFC3315bis document and use the term "resources". > > - Introduction: I'd suggest clarifying the intended coverage (the '#2' > above) in the introduction section. > > - Introduction (or in some new section): as discussed separately, this > draft imposes some assumption on the definition and usage of > (especially future) IAs: > + they should have T1/T2 values (with the only exception of IA_TA) > + all IAs should share the same set of T1/T2. This also means that > it's less likely that we can define a (future) IA that expects > extremely shorter/longer T1/T2 (e.g. years or microseconds) in > usual operations than other IAs > + resources managed in an IA should have some kind of "lifetime". > I'd suggest clarifying these assumptions more explicitly somewhere > in the document. > > - Section 1: as long as we choose to include IA_TA in the > consideration, this sentence looks awkward to me: > > IA_TA also has limited value when DHCPv6 is used for address > assignment, as the privacy issues identified for IPv6 stateless > address assignment ([RFC4941]) do not apply to DHCPv6 assignments. > > What is stated may (or may not) be true itself, but seems to be an > orthogonal topic (it would be very relevant, on the other hand, if > we are excluding IA_TA and try to justify it). > > - Section 3: as I read the draft I felt a bit confused about the > difference between "resource" and "stateful options". In some cases > I saw the former (latter) is used where the latter (former) may be a > better choice. Maybe we can unify these? I'll point out some > specific cases where I felt the confusion below. The "stateful option" is a DHCP option (such as IA_NA or IA_PD) which is carrying a resource (e.g. address or prefix). Resource is content carried in the stateful option. I'll go over the document and try to unify it according to the meaning meant. > > - Section 3: s/An example/Examples/ or s/are/is/ > stateful options. An example of the > resources are: IPv6 address or an Ok, thanks. > > - Section 3: I don't understand what this refers to: > (see "identity association > for temporary addresses"). This is the reference to the section 22.5. of RFC3315. And it was copy-pasted from the terminology in RFC3315 which includes exactly the same reference. But, I think it can be improved. For example, the following statement in terminology: " In addition to the terminology defined in [RFC3315], [RFC3633], and [RFC7227], the following terminology is used in this document:" doesn't seem to be true because IA defined here is not "additional" but rather replaces the definition in RFC3315. > > - Section 4.1: this is not necessarily accurate, since NoBinding is > used for all current IAs (and could also be used for future ones as > its concept is quite generic): > > While a Status Code option is implicitly bound to a specific type of > IA, > > - Section 4.1: s/addresses/some stateful option types/ so the > description is generic? > > With the introduction of multiple IA option > types, there might be a case where a server is not willing to offer > addresses, but might be willing to offer other stateful option types. > > BTW, I wonder whether "resources" may be better than "stateful > option (types)" in this context (see above). Probably "resources" would be better. > > - Section 4.1: this sentence should probably be generalized: > > Clients MUST be prepared to handle each of the following Advertise > messages formats when there are no addresses available (even when no > IA_PD was in the Solicit): The reason why it explicitly speaks about "addresses" is that for the Advertise the NoAddrsAvail is included in the global scope when the server doesn't allocate at least one address (see RFC3315). For IA_PD (and hopefully for future IA types) the status code is always in the IA_PD option. So, it is very specific to addresses and shouldn't be generalized. > > e.g. by avoiding to use "addresses" or "IA_PD". > > - Section 4.2: this text should probably be generalized (not > hardcoding "address" etc) > > With (this includes the changes made by [RFC7083]): > > The client MUST ignore any Advertise message that contains no > addresses (IAADDR options encapsulated in IA_NA or IA_TA options) > [...] > > - Section 4.2: maybe this should be generalized: > > It is important to note that the receipt of an Advertise message > without any addresses and delegated prefixes does not imply that the > client should restart the Solicit retransmissions timers. > > - Section 4.3: regarding this behavior: > > Proposed solution: [...] To deal > with the case where servers have not yet been updated to do that, > clients MUST use the shortest (explicit or implicit) T1/T2 timer > (larger than 0) in any IA options in the Reply. Longer T1/T2 timers > are ignored. > > what should happen if we have two sets of T1/T2? > - T1a = 10, T2a = 20 > - T1b = 0, T2b = 5 > If we pick up the shortests (> 0), T1 would be 10 and T2 would be > 5, which is an invalid combination. > > - Section 4.4.1: this change seems to be too substantial. I'm not > necessarily opposed to it, but I cannot be immediately sure if this > doesn't have any unexpected bad effect. Besides, what if the server > finds it can't create any such binding? Should it return NoBinding > just like the old RFC 3315? > > Replace Section 18.2.3 of RFC 3315: > [...] > With: > > If the server cannot find a client entry for the IA the server > creates the bindings for that client according to the server's > policy and configuration information and returns the IAs and other > information requested by the client. Yes, if the server doesn't create a binding (e.g. it is not configured to create bindings when processing Renew/Rebind) it should send NoBinding. We were also considering the possibility for the server to return other status codes in certain cases (NoAddrsAvail/NoPrefixAvail etc.) and it seems that it has been briefly discussed between you and Bernie. However, this is currently not included in the draft. In the current version of the draft, it is NoBinding that can be returned if the bindings are not created. > > - Section 4.4.3: this paragraph is awkward in this context as it > describes the server behavior in the context of describing the > client behavior (Creation and Transmission of Renew): > > The server controls the time at which the client contacts the server > to extend the lifetimes on client's bindings through the T1 and T2 > [...] I don't disagree. I will come up with some proper split of this paragraph between server/client specific sections. > > - Section 4.4.3: why SHOULD? can't (shouldn't) this be a MUST? > > The server SHOULD assign the same T1 and > T2 value to each binding assigned to the client. In this case the The RFC3315 introduces no requirement for the T1/T2 times to be synchronized between the IAs for the same client. We wanted to give a strong recommendation for the server to send the same T1/T2 timers across all IAs. However, there will be cases when the server doesn't do that because it is not yet updated to the current specification. We want the clients to deal with that and that's why we add paragraphs what the client should do if it gets different T1/T2 times, which only really makes sense if it is not the absolute requirement (MUST). I may not have enough knowledge where the MUST vs SHOULD apply but in my opinion "SHOULD" well conveys the message that there may be cases in which server will respond with different T1/T2 timers and the client has to be prepared for this. > > - Section 4.4.3: this paragraph seems to say that a client may send > a Renew/Rebind for IA_TA. Is that intent? If so, is it a good > idea? > > If T1 or T2 is set to 0 by the server for all IA_NA and IA_PD > options, or there are no T1 or T2 times (for an IA_TA), the client > may send Renew or Rebind message, respectively, at the client's > discretion. This is the exact paragraph from the original document. See 18.1.3. Creation and Transmission of Renew Messages in RFC3315. > > - Section 4.4.3: I don't understand why (and actually I'm not really > sure what this sentence really tries to say): > The client constructing a Renew message SHOULD NOT include resources > in IA options that the client does not have. The intent here is that the client should not stick addresses or prefixes into the IA options that the client didn't obtain from the DHCP server. In order words, if the client has an address and sends Renew/Rebind it should only stick this address to the IA_NA option it is sending to the server. It should not put any address into the IA_NA that it never obtained from the DHCP server. Or, if the client has the address and not a prefix and the client wants the prefix be allocated (with the Renew/Rebind) it should put an empty IA_PD option, and not put any prefixes into it (e.g. as hints to the server). > > - Section 4.4.3: this paragraph assumes resource for any (future) IAs > has *multiple* lifetimes. While it would probably be reasonable to > assume resource for an IA generally has "a" lifetime, I'm not so > sure if it always have multiple lifetimes (for IA_NA, they are valid > and preferred lifetimes. They are very specific to the nature of > IPv6 addresses). The same comment applies to some other parts of > the draft, but basically I won't repeat it. > > If the server finds that any resource sent by the client is not > appropriate, according to the server's configuration information, the > server sends back the IA with the corresponding IA Address (for > inappropriate address), IA Prefix option (for inappropriate prefix) > or other option appropriate for the type of the resource, with > lifetimes set to 0. The client which receives the option with > lifetimes set to 0 MUST NOT use the corresponding resource. While I concur that it would be better to avoid "valid" and "preferred" because it may not apply to resources defined in the future, the single lifetime is a special case of multiple lifetimes and changing it to "a lifetime" would suggest that resources come with only one lifetime value. Also, we already have multiple lifetimes for existing resources. > > - Section 4.5.1: is it okay for the Rebind case? Rebind can be > handled multiple servers, so multiple servers could end up with > creating bindings. > > If the server cannot find a client entry for the IA and the IA is > empty (i.e. contains no addresses), the server MAY assign the > addresses to this IA and send a Reply message to the client with > this IA containing allocated addresses with lifetimes and T1/T2 > times. > (BTW: "addresses" should probably be generalized) This is similar to the issue that is already in the RFC3315 when the client sends the Solicit with Rapid Commit option. I'd assume that the server implementation would provide a configuration knob to enable/disable this behavior. If you don't want to deal with this issue, don't enable it (just like for Rapid Commit). If you do enable, you may need to adjust the lifetimes for assigned leases so as you don't end up with unused leases dangling for a long time. > > - Section 4.5.2: this should probably be generalized (and we might > revisit the term "*valid* lifetimes", see the next bullet). Also, > what if there are multiple IAs? Should this continue until all > resource lifetimes of all IAs expire? Or should it stop when all > resource lifetimes of some of the IAs expire (maybe the first time > it happens)? > > MRD Remaining time until valid lifetimes of all addresses or > prefixes in the IA have expired > > - Section 4.5.2: this even assumes resource for any (future) IA has a > "valid" lifetime. Isn't it too specific for a generic specification? > > The message exchange is terminated when the valid lifetimes of all > the resources assigned to the IA expire, at which time the client has > several alternative actions to choose from; for example: > > - Section 4.5.2: related to the comment about the MRD above, what if the > client has multiple IAs? > - The client may choose to use a Solicit message to locate a new > DHCP server and send a Request for the expired IA to the new > server. > If the client does this for one IA while (resources of) other IAs > still not expired and keeps sending Rebinding for them, doesn't the > client end up having multiple DHCPv6 sessions (which this draft > tries to avoid)? Did you really mean 4.5.2 from the datatracker: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-stateful-issues/ ? The 4.5.2 doesn't seem to be relevant here. > > - Section 4.5.4: maybe "of RFC 3315" should be appended, to be > consistent with other part of the text: > > The server includes other options containing configuration > information to be returned to the client as described in section > 18.2. It could. > > - Section 4.7: just wondering: does this describe some specific > existing client implementation? > > Some clients will send a Release message for other bindings they may > have received after they determine a conflict and have correctly sent > a Decline message for the conflicting address(es). > I'd let Bernie or Ole explain but I'd be opposed to putting any specific server implementations here. Marcin From nobody Thu Jul 10 11:44:10 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF7461A0B12 for ; Thu, 10 Jul 2014 11:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.852 X-Spam-Level: X-Spam-Status: No, score=-14.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 CYawzUCEgQZ9 for ; Thu, 10 Jul 2014 11:44:04 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB4681A0B0E for ; Thu, 10 Jul 2014 11:44:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25368; q=dns/txt; s=iport; t=1405017849; x=1406227449; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=8bf4y/QoKR+fOGSeozkP1iBOmmNaLBR6uJzYHQY/2ik=; b=iB1LR94bJnYmKjkAMlVeQ2JCcb968mPSgYapxbMscxwXZ1F7OqSYG35s tsPLNfQZvpNp4QO2nDfLIXzjX+OWd6/0qTQIoIJHhwNgmA2gtRlbW/aDk P1HTiXv3g9LOLfXdLMOUbG7BYOA94QDJqUmNDBunkuxJttGRPr+CSoYhP 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAILevlOtJA2D/2dsb2JhbABQCYMOUlqCb6pWkyiHQgEZdRZ1hAMBAQEEIxEzEgwEAgEGAg4DBAEBAQICBh0DAgICHxEUAQgIAgQBDQUIE4gTAxENkgGcJ5IIDYcYEwSBLIttgVADJxYQCwcGgnE2gRYBBJYgRoIakAGGFINDgW4kHg X-IronPort-AV: E=Sophos;i="5.01,639,1400025600"; d="scan'208";a="339101309" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-7.cisco.com with ESMTP; 10 Jul 2014 18:44:07 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6AIi2PN028127 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 10 Jul 2014 18:44:02 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.176]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Thu, 10 Jul 2014 13:44:02 -0500 From: "Bernie Volz (volz)" To: Marcin Siodelski , =?utf-8?B?56We5piO6YGU5ZOJ?= Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.txt Thread-Index: AQHPlIEus6CA5H78HkuHLmw+Sv8Eh5uJ3xfAgABnIoD//6zhMIAOYD0A//+yLrCAAHXFgIABfd4A//+4yoA= Date: Thu, 10 Jul 2014 18:44:01 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1B5F35BE@xmb-rcd-x04.cisco.com> References: <20140630163351.4191.69719.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E1B5E03D1@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1B5E170B@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1B5EE425@xmb-rcd-x04.cisco.com> <53BED1F4.8010807@gmail.com> In-Reply-To: <53BED1F4.8010807@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.70.117] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/e__2oHoT7nfdPp1FtmAelv8ZGAA Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.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, 10 Jul 2014 18:44:08 -0000 SGF2ZW4ndCB5ZXQgcHJvY2Vzc2VkIHRoaXMgdGhyZWFkIGNvbXBsZXRlbHkgLi4uIGJ1dCB3aWxs IHJlc3BvbmQgdG8gb25lIGlzc3VlOg0KDQo+PiAtIFNlY3Rpb24gNC43OiBqdXN0IHdvbmRlcmlu ZzogZG9lcyB0aGlzIGRlc2NyaWJlIHNvbWUgc3BlY2lmaWMNCj4+ICAgZXhpc3RpbmcgY2xpZW50 IGltcGxlbWVudGF0aW9uPw0KPj4gDQo+PiAgICBTb21lIGNsaWVudHMgd2lsbCBzZW5kIGEgUmVs ZWFzZSBtZXNzYWdlIGZvciBvdGhlciBiaW5kaW5ncyB0aGV5IG1heQ0KPj4gICAgaGF2ZSByZWNl aXZlZCBhZnRlciB0aGV5IGRldGVybWluZSBhIGNvbmZsaWN0IGFuZCBoYXZlIGNvcnJlY3RseSBz ZW50DQo+PiAgICBhIERlY2xpbmUgbWVzc2FnZSBmb3IgdGhlIGNvbmZsaWN0aW5nIGFkZHJlc3Mo ZXMpLg0KPj4gDQo+DQo+SSdkIGxldCBCZXJuaWUgb3IgT2xlIGV4cGxhaW4gYnV0IEknZCBiZSBv cHBvc2VkIHRvIHB1dHRpbmcgYW55IHNwZWNpZmljIHNlcnZlciBpbXBsZW1lbnRhdGlvbnMgaGVy ZS4NCg0KWWVzLCBpdCBkb2VzIGRlc2NyaWJlIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucy4gVGhp cyBpcyBhbiBpc3N1ZSB0aGF0IFRpbSBXaW50ZXJzIHJhaXNlZC4gSSBkb24ndCBiZWxpZXZlIEkg aGF2ZSBkZXRhaWxzIG9uIHdoaWNoIHNwZWNpZmljIENMSUVOVCBpbXBsZW1lbnRhdGlvbnMgbWln aHQgYmUgZG9pbmcgdGhpcy4gQnV0IGluIGFueSBjYXNlLCBJIGRvbid0IHRoaW5rIGl0IGlzIGFw cHJvcHJpYXRlIHRvIHNwZWNpZnkgd2hpY2ggaW1wbGVtZW50YXRpb25zIGluIGEgZG9jdW1lbnQg c3VjaCBhcyB0aGlzLg0KDQpBcmUgeW91IHN1Z2dlc3Rpbmcgd2UgcmVtb3ZlIHRoZSBmaXJzdCBw YXJhZ3JhcGggYW5kIGp1c3Qgc2ltcGxlIGxlYXZlIHRoZSBzZWNvbmQ/IEJ1dCBJIGRvIHRoaW5r IGl0IGFkZHMgdmFsdWUgdG8gZXhwbGFpbiB0aGF0IHRoaXMgbWlnaHQgYmUgJ2luIHRoZSBmaWVs ZCcgYmVoYXZpb3IuIElzIHRoZXJlIGJldHRlciB3b3JkaW5nIHlvdSB3YW50IHVzZWQgKG90aGVy IHRoYW4gbmFtaW5nICdzb21lIGltcGxlbWVudGF0aW9ucycpLiBXb3VsZCAiU29tZSBjbGllbnQg aW1wbGVtZW50YXRpb25zIGFyZSBbaGF2ZSBiZWVuXSBrbm93biB0byAuLi4iIGJlIGJldHRlciB3 b3JkaW5nPw0KDQotIEJlcm5pZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog TWFyY2luIFNpb2RlbHNraSBbbWFpbHRvOm1zaW9kZWxza2lAZ21haWwuY29tXSANClNlbnQ6IFRo dXJzZGF5LCBKdWx5IDEwLCAyMDE0IDE6NDkgUE0NClRvOiDnpZ7mmI7pgZTlk4k7IEJlcm5pZSBW b2x6ICh2b2x6KQ0KQ2M6IGRoY3dnQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2RoY3dnXSBJLUQg QWN0aW9uOiBkcmFmdC1pZXRmLWRoYy1kaGNwdjYtc3RhdGVmdWwtaXNzdWVzLTA2LnR4dA0KDQpK aW5tZWksDQoNClRoYW5rcyBmb3IgdGhlIHRob3JvdWdoIGFuZCBjYXJlZnVsIHJldmlldy4gSSBj YW4gYW5zd2VyIHNvbWUgb2YgdGhlIHBvaW50cyB5b3UgcmFpc2VkIChzZWUgYmVsb3cpLiBTb21l IG9mIHRoZW0gQmVybmllIG9yIE9sZSBtYXkgd2FudCB0byBhZGRyZXNzLCBzbyBJIGxlZnQgdGhl bSBub3QgYW5zd2VyZWQuDQoNCk1hcmNpbg0KDQpPbiAwOS8wNy8xNCAyMTowMSwg56We5piO6YGU 5ZOJIHdyb3RlOg0KPiBBdCBXZWQsIDkgSnVsIDIwMTQgMTc6MDc6NDAgKzAwMDAsDQo+ICJCZXJu aWUgVm9seiAodm9seikiIDx2b2x6QGNpc2NvLmNvbT4gd3JvdGU6DQo+IA0KPj4gWWVzLCAjMiBp cyBvdXIgaG9wZS4NCj4gDQo+Pj4gVGhlIG51YW5jZSBpcyBzdWJ0bGUgaGVyZSwgc28gcGxlYXNl IGxldCBtZSBiZSBzdXJlOiB3aGljaCBvbmUgaXMNCj4+PiAobW9yZSkgY29ycmVjdD8NCj4+PiAy LiB0aGlzIGRyYWZ0IGludGVuZHMgdG8gYmUgYXBwbGljYWJsZSB0byBmdXR1cmUgcG9zc2libGUg SUFfWFhzLA0KPj4+ICAgIGV2ZW4gaWYgdGhpcyBpcyBjdXJyZW50bHkganVzdCBhIGhvcGUgKHNp bmNlIHdlIGRvbid0IGtub3cgdGhlDQo+Pj4gICAgZnV0dXJlIHBvc3NpYmlsaXRpZXMgcmlnaHQg bm93KSBhbmQgbWF5IHR1cm4gb3V0IHRvIGJlIGluZmVhc2libGUuDQo+IA0KPiBPa2F5LCBvbiB0 b3Agb2YgdGhhdCwgdGhpcyBpcyBteSBjb21tZW50cyBvbiB0aGUgZHJhZnQgYm9keSAoZmluYWxs eSk6DQo+IA0KPiAtIFRpdGxlOiBtYXliZSB3ZSBzaG91bGQgY2hhbmdlIGl0IGZyb20gImlzc3Vl cyIsIHNpbmNlIGl0J3Mgbm90IGFuDQo+ICAgaXNzdWUgc3RhdGVtZW50IChhbnltb3JlKSBidXQg YWN0dWFsbHkgcHJvcG9zZXMgc3BlY2lmaWMgcHJvdG9jb2xzLg0KPiANCj4gLSBHZW5lcmFsOiBh cyBicmllZmx5IGRpc2N1c3NlZCBzZXBhcmF0ZWx5LCBJIHRoaW5rIHRoaXMgZG9jdW1lbnQNCj4g ICBzaG91bGQgYWxzbyBkZXNjcmliZSBob3cgdGhlIGNsaWVudCBzaG91bGQgaGFuZGxlIGEgUmVw bHkgdG8gdmFyaW91cw0KPiAgIHR5cGVzIG9mIG1lc3NhZ2VzIGJhc2VkIG9uIHRoZSByZXZpc2Vk IGJlaGF2aW9yLCB3aXRoIHNwZWNpZmljDQo+ICAgcmV2aXNlZCB0ZXh0IGFnYWluc3QgU2VjdGlv biAxOC4xLjggb2YgUkZDIDMzMTUuICBJIG5vdyB1bmRlcnN0YW5kDQo+ICAgaXQncyBpbmNsdWRl ZCBpbiB0aGUgcGxhbiBidXQgaXMgbm90IHNpbXBseSByZWFsaXplZCBpbiB0aGlzDQo+ICAgdmVy c2lvbiwgYnV0IEknbSBleHBsaWNpdGx5IG1lbnRpb25pbmcgaXQgaGVyZSBzbyBpdCB3b24ndCBi ZQ0KPiAgIGZvcmdvdHRlbi4gIChpdCB3b3VsZCBiZSBhIGdvb2QgaWRlYSB0byBoYXZlIGFuICJv cGVuIGlzc3VlcyINCj4gICBhcHBlbmRpeCBzZWN0aW9uIGZvciBzdWNoIHN0dWZmKQ0KPiANCj4g LSBHZW5lcmFsOiBhcyB3ZSBkaXNjdXNzZWQgc2VwYXJhdGVseSwgc29tZSBvZiB0aGUgdXBkYXRl cyBwcm9wb3NlZCBpbg0KPiAgIHRoZSBkcmFmdCBicmVhayBiYWNrd2FyZCBjb21wYXRpYmlsaXR5 LiAgSXQgbWF5IG9yIG1heSBub3QgYmUNCj4gICBqdXN0aWZpZWQgKEkgbXlzZWxmIGFtIG5vdCBy ZWFsbHkgc3VyZSBhYm91dCBpdDsgSSdsbCBuZWVkIHRvIHRoaW5rDQo+ICAgYWJvdXQgaXQgbW9y ZSksIGJ1dCBhdCBsZWFzdCBJIHRoaW5rIHRoZSBkcmFmdCBzaG91bGQgc3VtbWFyaXplDQo+ICAg aW5jb21wYXRpYmxlIGNoYW5nZXMgd2l0aCBkaXNjdXNzaW9uIG9mIGhvdyBpdCdzIGp1c3RpZmll ZC4NCj4gDQo+IC0gR2VuZXJhbDogdGhlIGdlbmVyYWxpemF0aW9uIGF0dGVtcHQgZG9lc24ndCBz ZWVtIHRvIGJlIGNvbXBsZXRlOyBpbg0KPiAgIHNvbWUgY2FzZXMgdGhlIHByb3Bvc2VkIHJldmlz ZWQgdGV4dCBzdGlsbCBvbmx5IHRhbGtzIGFib3V0DQo+ICAgYWRkcmVzc2VzIG9yIHByZWZpeGVz LCByYXRoZXIgdGhhbiBnZW5lcmFsICJyZXNvdXJjZXMiLiAgSSdsbCBwb2ludA0KPiAgIG91dCBz b21lIG9mIHN1Y2ggY2FzZXMgYmVsb3csIGJ1dCB0aGV5IGFyZSBub3QgY29tcHJlaGVuc2l2ZS4N Cg0KVGhlICJzdGF0ZWZ1bC1pc3N1ZXMiIGRyYWZ0IGlzIG1lYW50IHRvIHVwZGF0ZSB0aGUgUkZD MzMxNSBhbmQgUkZDMzYzMyByZXNwZWN0aXZlbHkuIFRoYXQncyB3aHkgaXQgcmVmZXJzIHRvIHRo ZSB0ZXJtICJhZGRyZXNzIiB3aGVyZSBpdCB1cGRhdGVzIFJGQzMzMTUgYW5kICJwcmVmaXgiIHdo ZXJlIGl0IHVwZGF0ZXMgUkZDMzYzMy4NCg0KVGhlIFJGQzMzMTViaXMgd29yayBpcyBjb25kdWN0 ZWQgaW4gcGFyYWxsZWwgdG8gdGhpcyB3b3JrIGFuZCBvbmUgb2YgdGhlIGdvYWxzIGlzIHRvIG1l cmdlIHRoZSBSRkMzNjMzIGFuZCBSRkMzMzE1IGFuZCBwcm92aWRlIHRoZSB1bmlmaWVkIHRleHQg Zm9yIGRpZmZlcmVudCBJQSB0eXBlcy4NCg0KU2luY2UsIHRoZSAic3RhdGVmdWwtaXNzdWVzIiBk cmFmdCBhZGRyZXNzZXMgdmFyaW91cyBhc3BlY3RzIG9mIGNvZXhpc3RlbmNlIG9mIGRpZmZlcmVu dCBJQSB0eXBlcyB3ZSB0aG91Z2h0IGl0IG1heSBiZSB1c2VmdWwgdG8gYWxzbyBpbmNsdWRlIHRo ZSB1bmlmaWVkIHRleHQgdGhhdCBjYW4gYmUgZGlyZWN0bHkgKG9yIGVhc2lseSkgcG9ydGVkIHRv IHRoZSBSRkMzMzE1YmlzIGRvY3VtZW50LiBUaGF0J3Mgd2h5IHRoZXJlIGFyZSBzZXBhcmF0ZSBz ZWN0aW9ucyBpbmNsdWRpbmcgYSB1bmlmaWVkIHRleHQgZm9yIFJGQzMzMTViaXMgYW5kIGluIHRo b3NlIHNlY3Rpb25zIHRoZSBpdGVtcyBjYXJyaWVkIGluIHRoZSBJQSBvcHRpb25zIGFyZSBjYWxs ZWQgInJlc291cmNlcyIuDQoNCkZvciBleGFtcGxlOiBzZWN0aW9ucyA0LjEgYW5kIDQuMiBwcm92 aWRlIHRoZSB1cGRhdGVzIHRvIFJGQzMzMTUgYW5kDQpSRkMzNjMzIHJlc3BlY3RpdmVseSBhbmQg dXNlIHRoZSB0ZXJtICJhZGRyZXNzIi8icHJlZml4Ii4gU2VjdGlvbnMgNC4zIGFuZCA0LjQuIHBy ZXNlbnQgdGhlIHVuaWZpZWQgdGV4dCB0byBiZSBpbmNsdWRlZCBpbiB0aGUgUkZDMzMxNWJpcyBk b2N1bWVudCBhbmQgdXNlIHRoZSB0ZXJtICJyZXNvdXJjZXMiLg0KDQo+IA0KPiAtIEludHJvZHVj dGlvbjogSSdkIHN1Z2dlc3QgY2xhcmlmeWluZyB0aGUgaW50ZW5kZWQgY292ZXJhZ2UgKHRoZSAn IzInDQo+ICAgYWJvdmUpIGluIHRoZSBpbnRyb2R1Y3Rpb24gc2VjdGlvbi4NCj4gDQo+IC0gSW50 cm9kdWN0aW9uIChvciBpbiBzb21lIG5ldyBzZWN0aW9uKTogYXMgZGlzY3Vzc2VkIHNlcGFyYXRl bHksIHRoaXMNCj4gICBkcmFmdCBpbXBvc2VzIHNvbWUgYXNzdW1wdGlvbiBvbiB0aGUgZGVmaW5p dGlvbiBhbmQgdXNhZ2Ugb2YNCj4gICAoZXNwZWNpYWxseSBmdXR1cmUpIElBczoNCj4gICArIHRo ZXkgc2hvdWxkIGhhdmUgVDEvVDIgdmFsdWVzICh3aXRoIHRoZSBvbmx5IGV4Y2VwdGlvbiBvZiBJ QV9UQSkNCj4gICArIGFsbCBJQXMgc2hvdWxkIHNoYXJlIHRoZSBzYW1lIHNldCBvZiBUMS9UMi4g IFRoaXMgYWxzbyBtZWFucyB0aGF0DQo+ICAgICBpdCdzIGxlc3MgbGlrZWx5IHRoYXQgd2UgY2Fu IGRlZmluZSBhIChmdXR1cmUpIElBIHRoYXQgZXhwZWN0cw0KPiAgICAgZXh0cmVtZWx5IHNob3J0 ZXIvbG9uZ2VyIFQxL1QyIChlLmcuIHllYXJzIG9yIG1pY3Jvc2Vjb25kcykgaW4NCj4gICAgIHVz dWFsIG9wZXJhdGlvbnMgdGhhbiBvdGhlciBJQXMNCj4gICArIHJlc291cmNlcyBtYW5hZ2VkIGlu IGFuIElBIHNob3VsZCBoYXZlIHNvbWUga2luZCBvZiAibGlmZXRpbWUiLg0KPiAgIEknZCBzdWdn ZXN0IGNsYXJpZnlpbmcgdGhlc2UgYXNzdW1wdGlvbnMgbW9yZSBleHBsaWNpdGx5IHNvbWV3aGVy ZQ0KPiAgIGluIHRoZSBkb2N1bWVudC4NCj4gDQo+IC0gU2VjdGlvbiAxOiBhcyBsb25nIGFzIHdl IGNob29zZSB0byBpbmNsdWRlIElBX1RBIGluIHRoZQ0KPiAgIGNvbnNpZGVyYXRpb24sIHRoaXMg c2VudGVuY2UgbG9va3MgYXdrd2FyZCB0byBtZToNCj4gDQo+ICAgIElBX1RBIGFsc28gaGFzIGxp bWl0ZWQgdmFsdWUgd2hlbiBESENQdjYgaXMgdXNlZCBmb3IgYWRkcmVzcw0KPiAgICBhc3NpZ25t ZW50LCBhcyB0aGUgcHJpdmFjeSBpc3N1ZXMgaWRlbnRpZmllZCBmb3IgSVB2NiBzdGF0ZWxlc3MN Cj4gICAgYWRkcmVzcyBhc3NpZ25tZW50IChbUkZDNDk0MV0pIGRvIG5vdCBhcHBseSB0byBESENQ djYgYXNzaWdubWVudHMuDQo+IA0KPiAgIFdoYXQgaXMgc3RhdGVkIG1heSAob3IgbWF5IG5vdCkg YmUgdHJ1ZSBpdHNlbGYsIGJ1dCBzZWVtcyB0byBiZSBhbg0KPiAgIG9ydGhvZ29uYWwgdG9waWMg KGl0IHdvdWxkIGJlIHZlcnkgcmVsZXZhbnQsIG9uIHRoZSBvdGhlciBoYW5kLCBpZg0KPiAgIHdl IGFyZSBleGNsdWRpbmcgSUFfVEEgYW5kIHRyeSB0byBqdXN0aWZ5IGl0KS4NCj4gDQo+IC0gU2Vj dGlvbiAzOiBhcyBJIHJlYWQgdGhlIGRyYWZ0IEkgZmVsdCBhIGJpdCBjb25mdXNlZCBhYm91dCB0 aGUNCj4gICBkaWZmZXJlbmNlIGJldHdlZW4gInJlc291cmNlIiBhbmQgInN0YXRlZnVsIG9wdGlv bnMiLiAgSW4gc29tZSBjYXNlcw0KPiAgIEkgc2F3IHRoZSBmb3JtZXIgKGxhdHRlcikgaXMgdXNl ZCB3aGVyZSB0aGUgbGF0dGVyIChmb3JtZXIpIG1heSBiZSBhDQo+ICAgYmV0dGVyIGNob2ljZS4g IE1heWJlIHdlIGNhbiB1bmlmeSB0aGVzZT8gIEknbGwgcG9pbnQgb3V0IHNvbWUNCj4gICBzcGVj aWZpYyBjYXNlcyB3aGVyZSBJIGZlbHQgdGhlIGNvbmZ1c2lvbiBiZWxvdy4NCg0KVGhlICJzdGF0 ZWZ1bCBvcHRpb24iIGlzIGEgREhDUCBvcHRpb24gKHN1Y2ggYXMgSUFfTkEgb3IgSUFfUEQpIHdo aWNoIGlzIGNhcnJ5aW5nIGEgcmVzb3VyY2UgKGUuZy4gYWRkcmVzcyBvciBwcmVmaXgpLiBSZXNv dXJjZSBpcyBjb250ZW50IGNhcnJpZWQgaW4gdGhlIHN0YXRlZnVsIG9wdGlvbi4NCg0KSSdsbCBn byBvdmVyIHRoZSBkb2N1bWVudCBhbmQgdHJ5IHRvIHVuaWZ5IGl0IGFjY29yZGluZyB0byB0aGUg bWVhbmluZyBtZWFudC4NCg0KPiANCj4gLSBTZWN0aW9uIDM6IHMvQW4gZXhhbXBsZS9FeGFtcGxl cy8gb3Igcy9hcmUvaXMvDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3Rh dGVmdWwgb3B0aW9ucy4gIEFuIGV4YW1wbGUgb2YgdGhlDQo+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgcmVzb3VyY2VzIGFyZTogSVB2NiBhZGRyZXNzIG9yIGFuDQoNCk9rLCB0 aGFua3MuDQoNCj4gDQo+IC0gU2VjdGlvbiAzOiBJIGRvbid0IHVuZGVyc3RhbmQgd2hhdCB0aGlz IHJlZmVycyB0bzoNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoc2VlICJp ZGVudGl0eSBhc3NvY2lhdGlvbg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGZvciB0ZW1wb3JhcnkgYWRkcmVzc2VzIikuDQoNClRoaXMgaXMgdGhlIHJlZmVyZW5jZSB0byB0 aGUgc2VjdGlvbiAyMi41LiBvZiBSRkMzMzE1LiBBbmQgaXQgd2FzIGNvcHktcGFzdGVkIGZyb20g dGhlIHRlcm1pbm9sb2d5IGluIFJGQzMzMTUgd2hpY2ggaW5jbHVkZXMgZXhhY3RseSB0aGUgc2Ft ZSByZWZlcmVuY2UuIEJ1dCwgSSB0aGluayBpdCBjYW4gYmUgaW1wcm92ZWQuIEZvciBleGFtcGxl LCB0aGUgZm9sbG93aW5nIHN0YXRlbWVudCBpbiB0ZXJtaW5vbG9neToNCg0KIiBJbiBhZGRpdGlv biB0byB0aGUgdGVybWlub2xvZ3kgZGVmaW5lZCBpbiBbUkZDMzMxNV0sIFtSRkMzNjMzXSwgYW5k DQogICBbUkZDNzIyN10sIHRoZSBmb2xsb3dpbmcgdGVybWlub2xvZ3kgaXMgdXNlZCBpbiB0aGlz IGRvY3VtZW50OiINCg0KZG9lc24ndCBzZWVtIHRvIGJlIHRydWUgYmVjYXVzZSBJQSBkZWZpbmVk IGhlcmUgaXMgbm90ICJhZGRpdGlvbmFsIiBidXQgcmF0aGVyIHJlcGxhY2VzIHRoZSBkZWZpbml0 aW9uIGluIFJGQzMzMTUuDQoNCj4gDQo+IC0gU2VjdGlvbiA0LjE6IHRoaXMgaXMgbm90IG5lY2Vz c2FyaWx5IGFjY3VyYXRlLCBzaW5jZSBOb0JpbmRpbmcgaXMNCj4gICB1c2VkIGZvciBhbGwgY3Vy cmVudCBJQXMgKGFuZCBjb3VsZCBhbHNvIGJlIHVzZWQgZm9yIGZ1dHVyZSBvbmVzIGFzDQo+ICAg aXRzIGNvbmNlcHQgaXMgcXVpdGUgZ2VuZXJpYyk6DQo+IA0KPiAgICBXaGlsZSBhIFN0YXR1cyBD b2RlIG9wdGlvbiBpcyBpbXBsaWNpdGx5IGJvdW5kIHRvIGEgc3BlY2lmaWMgdHlwZSBvZg0KPiAg ICBJQSwNCj4gDQo+IC0gU2VjdGlvbiA0LjE6IHMvYWRkcmVzc2VzL3NvbWUgc3RhdGVmdWwgb3B0 aW9uIHR5cGVzLyBzbyB0aGUNCj4gICBkZXNjcmlwdGlvbiBpcyBnZW5lcmljPw0KPiANCj4gICAg V2l0aCB0aGUgaW50cm9kdWN0aW9uIG9mIG11bHRpcGxlIElBIG9wdGlvbg0KPiAgICB0eXBlcywg dGhlcmUgbWlnaHQgYmUgYSBjYXNlIHdoZXJlIGEgc2VydmVyIGlzIG5vdCB3aWxsaW5nIHRvIG9m ZmVyDQo+ICAgIGFkZHJlc3NlcywgYnV0IG1pZ2h0IGJlIHdpbGxpbmcgdG8gb2ZmZXIgb3RoZXIg c3RhdGVmdWwgb3B0aW9uIHR5cGVzLg0KPiANCj4gICBCVFcsIEkgd29uZGVyIHdoZXRoZXIgInJl c291cmNlcyIgbWF5IGJlIGJldHRlciB0aGFuICJzdGF0ZWZ1bA0KPiAgIG9wdGlvbiAodHlwZXMp IiBpbiB0aGlzIGNvbnRleHQgKHNlZSBhYm92ZSkuDQoNClByb2JhYmx5ICJyZXNvdXJjZXMiIHdv dWxkIGJlIGJldHRlci4NCg0KPiANCj4gLSBTZWN0aW9uIDQuMTogdGhpcyBzZW50ZW5jZSBzaG91 bGQgcHJvYmFibHkgYmUgZ2VuZXJhbGl6ZWQ6DQo+IA0KPiAgICBDbGllbnRzIE1VU1QgYmUgcHJl cGFyZWQgdG8gaGFuZGxlIGVhY2ggb2YgdGhlIGZvbGxvd2luZyBBZHZlcnRpc2UNCj4gICAgbWVz c2FnZXMgZm9ybWF0cyB3aGVuIHRoZXJlIGFyZSBubyBhZGRyZXNzZXMgYXZhaWxhYmxlIChldmVu IHdoZW4gbm8NCj4gICAgSUFfUEQgd2FzIGluIHRoZSBTb2xpY2l0KToNCg0KVGhlIHJlYXNvbiB3 aHkgaXQgZXhwbGljaXRseSBzcGVha3MgYWJvdXQgImFkZHJlc3NlcyIgaXMgdGhhdCBmb3IgdGhl IEFkdmVydGlzZSB0aGUgTm9BZGRyc0F2YWlsIGlzIGluY2x1ZGVkIGluIHRoZSBnbG9iYWwgc2Nv cGUgd2hlbiB0aGUgc2VydmVyIGRvZXNuJ3QgYWxsb2NhdGUgYXQgbGVhc3Qgb25lIGFkZHJlc3Mg KHNlZSBSRkMzMzE1KS4gRm9yIElBX1BEIChhbmQgaG9wZWZ1bGx5IGZvciBmdXR1cmUgSUEgdHlw ZXMpIHRoZSBzdGF0dXMgY29kZSBpcyBhbHdheXMgaW4gdGhlIElBX1BEIG9wdGlvbi4gU28sIGl0 IGlzIHZlcnkgc3BlY2lmaWMgdG8gYWRkcmVzc2VzIGFuZCBzaG91bGRuJ3QgYmUgZ2VuZXJhbGl6 ZWQuDQo+IA0KPiAgIGUuZy4gYnkgYXZvaWRpbmcgdG8gdXNlICJhZGRyZXNzZXMiIG9yICJJQV9Q RCIuDQo+IA0KPiAtIFNlY3Rpb24gNC4yOiB0aGlzIHRleHQgc2hvdWxkIHByb2JhYmx5IGJlIGdl bmVyYWxpemVkIChub3QNCj4gICBoYXJkY29kaW5nICJhZGRyZXNzIiBldGMpDQo+IA0KPiAgICBX aXRoICh0aGlzIGluY2x1ZGVzIHRoZSBjaGFuZ2VzIG1hZGUgYnkgW1JGQzcwODNdKToNCj4gDQo+ ICAgICAgVGhlIGNsaWVudCBNVVNUIGlnbm9yZSBhbnkgQWR2ZXJ0aXNlIG1lc3NhZ2UgdGhhdCBj b250YWlucyBubw0KPiAgICAgIGFkZHJlc3NlcyAoSUFBRERSIG9wdGlvbnMgZW5jYXBzdWxhdGVk IGluIElBX05BIG9yIElBX1RBIG9wdGlvbnMpDQo+ICAgICAgWy4uLl0NCj4gDQo+IC0gU2VjdGlv biA0LjI6IG1heWJlIHRoaXMgc2hvdWxkIGJlIGdlbmVyYWxpemVkOg0KPiANCj4gICAgSXQgaXMg aW1wb3J0YW50IHRvIG5vdGUgdGhhdCB0aGUgcmVjZWlwdCBvZiBhbiBBZHZlcnRpc2UgbWVzc2Fn ZQ0KPiAgICB3aXRob3V0IGFueSBhZGRyZXNzZXMgYW5kIGRlbGVnYXRlZCBwcmVmaXhlcyBkb2Vz IG5vdCBpbXBseSB0aGF0IHRoZQ0KPiAgICBjbGllbnQgc2hvdWxkIHJlc3RhcnQgdGhlIFNvbGlj aXQgcmV0cmFuc21pc3Npb25zIHRpbWVycy4NCj4gDQo+IC0gU2VjdGlvbiA0LjM6IHJlZ2FyZGlu ZyB0aGlzIGJlaGF2aW9yOg0KPiANCj4gICAgUHJvcG9zZWQgc29sdXRpb246IFsuLi5dICBUbyBk ZWFsDQo+ICAgIHdpdGggdGhlIGNhc2Ugd2hlcmUgc2VydmVycyBoYXZlIG5vdCB5ZXQgYmVlbiB1 cGRhdGVkIHRvIGRvIHRoYXQsDQo+ICAgIGNsaWVudHMgTVVTVCB1c2UgdGhlIHNob3J0ZXN0IChl eHBsaWNpdCBvciBpbXBsaWNpdCkgVDEvVDIgdGltZXINCj4gICAgKGxhcmdlciB0aGFuIDApIGlu IGFueSBJQSBvcHRpb25zIGluIHRoZSBSZXBseS4gIExvbmdlciBUMS9UMiB0aW1lcnMNCj4gICAg YXJlIGlnbm9yZWQuDQo+IA0KPiAgIHdoYXQgc2hvdWxkIGhhcHBlbiBpZiB3ZSBoYXZlIHR3byBz ZXRzIG9mIFQxL1QyPw0KPiAgIC0gVDFhID0gMTAsIFQyYSA9IDIwDQo+ICAgLSBUMWIgPSAwLCBU MmIgPSA1DQo+ICAgSWYgd2UgcGljayB1cCB0aGUgc2hvcnRlc3RzICg+IDApLCBUMSB3b3VsZCBi ZSAxMCBhbmQgVDIgd291bGQgYmUNCj4gICA1LCB3aGljaCBpcyBhbiBpbnZhbGlkIGNvbWJpbmF0 aW9uLg0KPiANCj4gLSBTZWN0aW9uIDQuNC4xOiB0aGlzIGNoYW5nZSBzZWVtcyB0byBiZSB0b28g c3Vic3RhbnRpYWwuICBJJ20gbm90DQo+ICAgbmVjZXNzYXJpbHkgb3Bwb3NlZCB0byBpdCwgYnV0 IEkgY2Fubm90IGJlIGltbWVkaWF0ZWx5IHN1cmUgaWYgdGhpcw0KPiAgIGRvZXNuJ3QgaGF2ZSBh bnkgdW5leHBlY3RlZCBiYWQgZWZmZWN0LiAgQmVzaWRlcywgd2hhdCBpZiB0aGUgc2VydmVyDQo+ ICAgZmluZHMgaXQgY2FuJ3QgY3JlYXRlIGFueSBzdWNoIGJpbmRpbmc/ICBTaG91bGQgaXQgcmV0 dXJuICBOb0JpbmRpbmcNCj4gICBqdXN0IGxpa2UgdGhlIG9sZCBSRkMgMzMxNT8NCj4gDQo+ICAg IFJlcGxhY2UgU2VjdGlvbiAxOC4yLjMgb2YgUkZDIDMzMTU6DQo+ICAgIFsuLi5dDQo+ICAgIFdp dGg6DQo+IA0KPiAgICAgICBJZiB0aGUgc2VydmVyIGNhbm5vdCBmaW5kIGEgY2xpZW50IGVudHJ5 IGZvciB0aGUgSUEgdGhlIHNlcnZlcg0KPiAgICAgICBjcmVhdGVzIHRoZSBiaW5kaW5ncyBmb3Ig dGhhdCBjbGllbnQgYWNjb3JkaW5nIHRvIHRoZSBzZXJ2ZXIncw0KPiAgICAgICBwb2xpY3kgYW5k IGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24gYW5kIHJldHVybnMgdGhlIElBcyBhbmQgb3RoZXIN Cj4gICAgICAgaW5mb3JtYXRpb24gcmVxdWVzdGVkIGJ5IHRoZSBjbGllbnQuDQoNClllcywgaWYg dGhlIHNlcnZlciBkb2Vzbid0IGNyZWF0ZSBhIGJpbmRpbmcgKGUuZy4gaXQgaXMgbm90IGNvbmZp Z3VyZWQgdG8gY3JlYXRlIGJpbmRpbmdzIHdoZW4gcHJvY2Vzc2luZyBSZW5ldy9SZWJpbmQpIGl0 IHNob3VsZCBzZW5kIE5vQmluZGluZy4NCg0KV2Ugd2VyZSBhbHNvIGNvbnNpZGVyaW5nIHRoZSBw b3NzaWJpbGl0eSBmb3IgdGhlIHNlcnZlciB0byByZXR1cm4gb3RoZXIgc3RhdHVzIGNvZGVzIGlu IGNlcnRhaW4gY2FzZXMgKE5vQWRkcnNBdmFpbC9Ob1ByZWZpeEF2YWlsIGV0Yy4pIGFuZCBpdCBz ZWVtcyB0aGF0IGl0IGhhcyBiZWVuIGJyaWVmbHkgZGlzY3Vzc2VkIGJldHdlZW4geW91IGFuZCBC ZXJuaWUuDQpIb3dldmVyLCB0aGlzIGlzIGN1cnJlbnRseSBub3QgaW5jbHVkZWQgaW4gdGhlIGRy YWZ0Lg0KDQpJbiB0aGUgY3VycmVudCB2ZXJzaW9uIG9mIHRoZSBkcmFmdCwgaXQgaXMgTm9CaW5k aW5nIHRoYXQgY2FuIGJlIHJldHVybmVkIGlmIHRoZSBiaW5kaW5ncyBhcmUgbm90IGNyZWF0ZWQu DQoNCg0KPiANCj4gLSBTZWN0aW9uIDQuNC4zOiB0aGlzIHBhcmFncmFwaCBpcyBhd2t3YXJkIGlu IHRoaXMgY29udGV4dCBhcyBpdA0KPiAgIGRlc2NyaWJlcyB0aGUgc2VydmVyIGJlaGF2aW9yIGlu IHRoZSBjb250ZXh0IG9mIGRlc2NyaWJpbmcgdGhlDQo+ICAgY2xpZW50IGJlaGF2aW9yIChDcmVh dGlvbiBhbmQgVHJhbnNtaXNzaW9uIG9mIFJlbmV3KToNCj4gDQo+ICAgIFRoZSBzZXJ2ZXIgY29u dHJvbHMgdGhlIHRpbWUgYXQgd2hpY2ggdGhlIGNsaWVudCBjb250YWN0cyB0aGUgc2VydmVyDQo+ ICAgIHRvIGV4dGVuZCB0aGUgbGlmZXRpbWVzIG9uIGNsaWVudCdzIGJpbmRpbmdzIHRocm91Z2gg dGhlIFQxIGFuZCBUMg0KPiAgICBbLi4uXQ0KDQpJIGRvbid0IGRpc2FncmVlLiBJIHdpbGwgY29t ZSB1cCB3aXRoIHNvbWUgcHJvcGVyIHNwbGl0IG9mIHRoaXMgcGFyYWdyYXBoIGJldHdlZW4gc2Vy dmVyL2NsaWVudCBzcGVjaWZpYyBzZWN0aW9ucy4NCg0KPiANCj4gLSBTZWN0aW9uIDQuNC4zOiB3 aHkgU0hPVUxEPyAgY2FuJ3QgKHNob3VsZG4ndCkgdGhpcyBiZSBhIE1VU1Q/DQo+IA0KPiAgICBU aGUgc2VydmVyIFNIT1VMRCBhc3NpZ24gdGhlIHNhbWUgVDEgYW5kDQo+ICAgIFQyIHZhbHVlIHRv IGVhY2ggYmluZGluZyBhc3NpZ25lZCB0byB0aGUgY2xpZW50LiAgSW4gdGhpcyBjYXNlIHRoZQ0K DQpUaGUgUkZDMzMxNSBpbnRyb2R1Y2VzIG5vIHJlcXVpcmVtZW50IGZvciB0aGUgVDEvVDIgdGlt ZXMgdG8gYmUgc3luY2hyb25pemVkIGJldHdlZW4gdGhlIElBcyBmb3IgdGhlIHNhbWUgY2xpZW50 LiBXZSB3YW50ZWQgdG8gZ2l2ZSBhIHN0cm9uZyByZWNvbW1lbmRhdGlvbiBmb3IgdGhlIHNlcnZl ciB0byBzZW5kIHRoZSBzYW1lIFQxL1QyIHRpbWVycyBhY3Jvc3MgYWxsIElBcy4gSG93ZXZlciwg dGhlcmUgd2lsbCBiZSBjYXNlcyB3aGVuIHRoZSBzZXJ2ZXIgZG9lc24ndCBkbyB0aGF0IGJlY2F1 c2UgaXQgaXMgbm90IHlldCB1cGRhdGVkIHRvIHRoZSBjdXJyZW50IHNwZWNpZmljYXRpb24uIFdl IHdhbnQgdGhlIGNsaWVudHMgdG8gZGVhbCB3aXRoIHRoYXQgYW5kIHRoYXQncyB3aHkgd2UgYWRk IHBhcmFncmFwaHMgd2hhdCB0aGUgY2xpZW50IHNob3VsZCBkbyBpZiBpdCBnZXRzIGRpZmZlcmVu dCBUMS9UMiB0aW1lcywgd2hpY2ggb25seSByZWFsbHkgbWFrZXMgc2Vuc2UgaWYgaXQgaXMgbm90 IHRoZSBhYnNvbHV0ZSByZXF1aXJlbWVudCAoTVVTVCkuDQoNCkkgbWF5IG5vdCBoYXZlIGVub3Vn aCBrbm93bGVkZ2Ugd2hlcmUgdGhlIE1VU1QgdnMgU0hPVUxEIGFwcGx5IGJ1dCBpbiBteSBvcGlu aW9uICJTSE9VTEQiIHdlbGwgY29udmV5cyB0aGUgbWVzc2FnZSB0aGF0IHRoZXJlIG1heSBiZSBj YXNlcyBpbiB3aGljaCBzZXJ2ZXIgd2lsbCByZXNwb25kIHdpdGggZGlmZmVyZW50IFQxL1QyIHRp bWVycyBhbmQgdGhlIGNsaWVudCBoYXMgdG8gYmUgcHJlcGFyZWQgZm9yIHRoaXMuDQoNCg0KPiAN Cj4gLSBTZWN0aW9uIDQuNC4zOiB0aGlzIHBhcmFncmFwaCBzZWVtcyB0byBzYXkgdGhhdCBhIGNs aWVudCBtYXkgc2VuZA0KPiAgIGEgUmVuZXcvUmViaW5kIGZvciBJQV9UQS4gIElzIHRoYXQgaW50 ZW50PyAgSWYgc28sIGlzIGl0IGEgZ29vZA0KPiAgIGlkZWE/DQo+IA0KPiAgICBJZiBUMSBvciBU MiBpcyBzZXQgdG8gMCBieSB0aGUgc2VydmVyIGZvciBhbGwgSUFfTkEgYW5kIElBX1BEDQo+ICAg IG9wdGlvbnMsIG9yIHRoZXJlIGFyZSBubyBUMSBvciBUMiB0aW1lcyAoZm9yIGFuIElBX1RBKSwg dGhlIGNsaWVudA0KPiAgICBtYXkgc2VuZCBSZW5ldyBvciBSZWJpbmQgbWVzc2FnZSwgcmVzcGVj dGl2ZWx5LCBhdCB0aGUgY2xpZW50J3MNCj4gICAgZGlzY3JldGlvbi4NCg0KVGhpcyBpcyB0aGUg ZXhhY3QgcGFyYWdyYXBoIGZyb20gdGhlIG9yaWdpbmFsIGRvY3VtZW50LiBTZWUgMTguMS4zLg0K Q3JlYXRpb24gYW5kIFRyYW5zbWlzc2lvbiBvZiBSZW5ldyBNZXNzYWdlcyBpbiBSRkMzMzE1Lg0K DQo+IA0KPiAtIFNlY3Rpb24gNC40LjM6IEkgZG9uJ3QgdW5kZXJzdGFuZCB3aHkgKGFuZCBhY3R1 YWxseSBJJ20gbm90IHJlYWxseQ0KPiAgIHN1cmUgd2hhdCB0aGlzIHNlbnRlbmNlIHJlYWxseSB0 cmllcyB0byBzYXkpOg0KPiAgICBUaGUgY2xpZW50IGNvbnN0cnVjdGluZyBhIFJlbmV3IG1lc3Nh Z2UgU0hPVUxEIE5PVCBpbmNsdWRlIHJlc291cmNlcw0KPiAgICBpbiBJQSBvcHRpb25zIHRoYXQg dGhlIGNsaWVudCBkb2VzIG5vdCBoYXZlLg0KDQpUaGUgaW50ZW50IGhlcmUgaXMgdGhhdCB0aGUg Y2xpZW50IHNob3VsZCBub3Qgc3RpY2sgYWRkcmVzc2VzIG9yIHByZWZpeGVzIGludG8gdGhlIElB IG9wdGlvbnMgdGhhdCB0aGUgY2xpZW50IGRpZG4ndCBvYnRhaW4gZnJvbSB0aGUgREhDUCBzZXJ2 ZXIuDQoNCkluIG9yZGVyIHdvcmRzLCBpZiB0aGUgY2xpZW50IGhhcyBhbiBhZGRyZXNzIGFuZCBz ZW5kcyBSZW5ldy9SZWJpbmQgaXQgc2hvdWxkIG9ubHkgc3RpY2sgdGhpcyBhZGRyZXNzIHRvIHRo ZSBJQV9OQSBvcHRpb24gaXQgaXMgc2VuZGluZyB0byB0aGUgc2VydmVyLiBJdCBzaG91bGQgbm90 IHB1dCBhbnkgYWRkcmVzcyBpbnRvIHRoZSBJQV9OQSB0aGF0IGl0IG5ldmVyIG9idGFpbmVkIGZy b20gdGhlIERIQ1Agc2VydmVyLg0KDQpPciwgaWYgdGhlIGNsaWVudCBoYXMgdGhlIGFkZHJlc3Mg YW5kIG5vdCBhIHByZWZpeCBhbmQgdGhlIGNsaWVudCB3YW50cyB0aGUgcHJlZml4IGJlIGFsbG9j YXRlZCAod2l0aCB0aGUgUmVuZXcvUmViaW5kKSBpdCBzaG91bGQgcHV0IGFuIGVtcHR5IElBX1BE IG9wdGlvbiwgYW5kIG5vdCBwdXQgYW55IHByZWZpeGVzIGludG8gaXQgKGUuZy4gYXMgaGludHMg dG8gdGhlIHNlcnZlcikuDQoNCj4gDQo+IC0gU2VjdGlvbiA0LjQuMzogdGhpcyBwYXJhZ3JhcGgg YXNzdW1lcyByZXNvdXJjZSBmb3IgYW55IChmdXR1cmUpIElBcw0KPiAgIGhhcyAqbXVsdGlwbGUq IGxpZmV0aW1lcy4gIFdoaWxlIGl0IHdvdWxkIHByb2JhYmx5IGJlIHJlYXNvbmFibGUgdG8NCj4g ICBhc3N1bWUgcmVzb3VyY2UgZm9yIGFuIElBIGdlbmVyYWxseSBoYXMgImEiIGxpZmV0aW1lLCBJ J20gbm90IHNvDQo+ICAgc3VyZSBpZiBpdCBhbHdheXMgaGF2ZSBtdWx0aXBsZSBsaWZldGltZXMg KGZvciBJQV9OQSwgdGhleSBhcmUgdmFsaWQNCj4gICBhbmQgcHJlZmVycmVkIGxpZmV0aW1lcy4g IFRoZXkgYXJlIHZlcnkgc3BlY2lmaWMgdG8gdGhlIG5hdHVyZSBvZg0KPiAgIElQdjYgYWRkcmVz c2VzKS4gIFRoZSBzYW1lIGNvbW1lbnQgYXBwbGllcyB0byBzb21lIG90aGVyIHBhcnRzIG9mDQo+ ICAgdGhlIGRyYWZ0LCBidXQgYmFzaWNhbGx5IEkgd29uJ3QgcmVwZWF0IGl0Lg0KPiANCj4gICAg SWYgdGhlIHNlcnZlciBmaW5kcyB0aGF0IGFueSByZXNvdXJjZSBzZW50IGJ5IHRoZSBjbGllbnQg aXMgbm90DQo+ICAgIGFwcHJvcHJpYXRlLCBhY2NvcmRpbmcgdG8gdGhlIHNlcnZlcidzIGNvbmZp Z3VyYXRpb24gaW5mb3JtYXRpb24sIHRoZQ0KPiAgICBzZXJ2ZXIgc2VuZHMgYmFjayB0aGUgSUEg d2l0aCB0aGUgY29ycmVzcG9uZGluZyBJQSBBZGRyZXNzIChmb3INCj4gICAgaW5hcHByb3ByaWF0 ZSBhZGRyZXNzKSwgSUEgUHJlZml4IG9wdGlvbiAoZm9yIGluYXBwcm9wcmlhdGUgcHJlZml4KQ0K PiAgICBvciBvdGhlciBvcHRpb24gYXBwcm9wcmlhdGUgZm9yIHRoZSB0eXBlIG9mIHRoZSByZXNv dXJjZSwgd2l0aA0KPiAgICBsaWZldGltZXMgc2V0IHRvIDAuICBUaGUgY2xpZW50IHdoaWNoIHJl Y2VpdmVzIHRoZSBvcHRpb24gd2l0aA0KPiAgICBsaWZldGltZXMgc2V0IHRvIDAgTVVTVCBOT1Qg dXNlIHRoZSBjb3JyZXNwb25kaW5nIHJlc291cmNlLg0KDQpXaGlsZSBJIGNvbmN1ciB0aGF0IGl0 IHdvdWxkIGJlIGJldHRlciB0byBhdm9pZCAidmFsaWQiIGFuZCAicHJlZmVycmVkIg0KYmVjYXVz ZSBpdCBtYXkgbm90IGFwcGx5IHRvIHJlc291cmNlcyBkZWZpbmVkIGluIHRoZSBmdXR1cmUsIHRo ZSBzaW5nbGUgbGlmZXRpbWUgaXMgYSBzcGVjaWFsIGNhc2Ugb2YgbXVsdGlwbGUgbGlmZXRpbWVz IGFuZCBjaGFuZ2luZyBpdCB0byAiYSBsaWZldGltZSIgd291bGQgc3VnZ2VzdCB0aGF0IHJlc291 cmNlcyBjb21lIHdpdGggb25seSBvbmUgbGlmZXRpbWUgdmFsdWUuIEFsc28sIHdlIGFscmVhZHkg aGF2ZSBtdWx0aXBsZSBsaWZldGltZXMgZm9yIGV4aXN0aW5nIHJlc291cmNlcy4NCg0KPiANCj4g LSBTZWN0aW9uIDQuNS4xOiBpcyBpdCBva2F5IGZvciB0aGUgUmViaW5kIGNhc2U/ICBSZWJpbmQg Y2FuIGJlDQo+ICAgaGFuZGxlZCBtdWx0aXBsZSBzZXJ2ZXJzLCBzbyBtdWx0aXBsZSBzZXJ2ZXJz IGNvdWxkIGVuZCB1cCB3aXRoDQo+ICAgY3JlYXRpbmcgYmluZGluZ3MuDQo+IA0KPiAgICAgIElm IHRoZSBzZXJ2ZXIgY2Fubm90IGZpbmQgYSBjbGllbnQgZW50cnkgZm9yIHRoZSBJQSBhbmQgdGhl IElBIGlzDQo+ICAgICAgZW1wdHkgKGkuZS4gY29udGFpbnMgbm8gYWRkcmVzc2VzKSwgdGhlIHNl cnZlciBNQVkgYXNzaWduIHRoZQ0KPiAgICAgIGFkZHJlc3NlcyB0byB0aGlzIElBIGFuZCBzZW5k IGEgUmVwbHkgbWVzc2FnZSB0byB0aGUgY2xpZW50IHdpdGgNCj4gICAgICB0aGlzIElBIGNvbnRh aW5pbmcgYWxsb2NhdGVkIGFkZHJlc3NlcyB3aXRoIGxpZmV0aW1lcyBhbmQgVDEvVDINCj4gICAg ICB0aW1lcy4NCj4gICAoQlRXOiAiYWRkcmVzc2VzIiBzaG91bGQgcHJvYmFibHkgYmUgZ2VuZXJh bGl6ZWQpDQoNClRoaXMgaXMgc2ltaWxhciB0byB0aGUgaXNzdWUgdGhhdCBpcyBhbHJlYWR5IGlu IHRoZSBSRkMzMzE1IHdoZW4gdGhlIGNsaWVudCBzZW5kcyB0aGUgU29saWNpdCB3aXRoIFJhcGlk IENvbW1pdCBvcHRpb24uIEknZCBhc3N1bWUgdGhhdCB0aGUgc2VydmVyIGltcGxlbWVudGF0aW9u IHdvdWxkIHByb3ZpZGUgYSBjb25maWd1cmF0aW9uIGtub2IgdG8gZW5hYmxlL2Rpc2FibGUgdGhp cyBiZWhhdmlvci4gSWYgeW91IGRvbid0IHdhbnQgdG8gZGVhbCB3aXRoIHRoaXMgaXNzdWUsIGRv bid0IGVuYWJsZSBpdCAoanVzdCBsaWtlIGZvciBSYXBpZCBDb21taXQpLiBJZiB5b3UgZG8gZW5h YmxlLCB5b3UgbWF5IG5lZWQgdG8gYWRqdXN0IHRoZSBsaWZldGltZXMgZm9yIGFzc2lnbmVkIGxl YXNlcyBzbyBhcyB5b3UgZG9uJ3QgZW5kIHVwIHdpdGggdW51c2VkIGxlYXNlcyBkYW5nbGluZyBm b3IgYSBsb25nIHRpbWUuDQoNCj4gDQo+IC0gU2VjdGlvbiA0LjUuMjogdGhpcyBzaG91bGQgcHJv YmFibHkgYmUgZ2VuZXJhbGl6ZWQgKGFuZCB3ZSBtaWdodA0KPiAgIHJldmlzaXQgdGhlIHRlcm0g Iip2YWxpZCogbGlmZXRpbWVzIiwgc2VlIHRoZSBuZXh0IGJ1bGxldCkuICBBbHNvLA0KPiAgIHdo YXQgaWYgdGhlcmUgYXJlIG11bHRpcGxlIElBcz8gIFNob3VsZCB0aGlzIGNvbnRpbnVlIHVudGls IGFsbA0KPiAgIHJlc291cmNlIGxpZmV0aW1lcyBvZiBhbGwgSUFzIGV4cGlyZT8gIE9yIHNob3Vs ZCBpdCBzdG9wIHdoZW4gYWxsDQo+ICAgcmVzb3VyY2UgbGlmZXRpbWVzIG9mIHNvbWUgb2YgdGhl IElBcyBleHBpcmUgKG1heWJlIHRoZSBmaXJzdCB0aW1lDQo+ICAgaXQgaGFwcGVucyk/DQo+IA0K PiAgICAgICBNUkQgICAgIFJlbWFpbmluZyB0aW1lIHVudGlsIHZhbGlkIGxpZmV0aW1lcyBvZiBh bGwgYWRkcmVzc2VzIG9yDQo+ICAgICAgICAgICAgICAgcHJlZml4ZXMgaW4gdGhlIElBIGhhdmUg ZXhwaXJlZA0KPiANCj4gLSBTZWN0aW9uIDQuNS4yOiB0aGlzIGV2ZW4gYXNzdW1lcyByZXNvdXJj ZSBmb3IgYW55IChmdXR1cmUpIElBIGhhcyBhDQo+ICAgInZhbGlkIiBsaWZldGltZS4gIElzbid0 IGl0IHRvbyBzcGVjaWZpYyBmb3IgYSBnZW5lcmljIHNwZWNpZmljYXRpb24/DQo+IA0KPiAgICBU aGUgbWVzc2FnZSBleGNoYW5nZSBpcyB0ZXJtaW5hdGVkIHdoZW4gdGhlIHZhbGlkIGxpZmV0aW1l cyBvZiBhbGwNCj4gICAgdGhlIHJlc291cmNlcyBhc3NpZ25lZCB0byB0aGUgSUEgZXhwaXJlLCBh dCB3aGljaCB0aW1lIHRoZSBjbGllbnQgaGFzDQo+ICAgIHNldmVyYWwgYWx0ZXJuYXRpdmUgYWN0 aW9ucyB0byBjaG9vc2UgZnJvbTsgZm9yIGV4YW1wbGU6DQo+IA0KPiAtIFNlY3Rpb24gNC41LjI6 IHJlbGF0ZWQgdG8gdGhlIGNvbW1lbnQgYWJvdXQgdGhlIE1SRCBhYm92ZSwgd2hhdCBpZiB0aGUN Cj4gICBjbGllbnQgaGFzIG11bHRpcGxlIElBcz8NCj4gICAgLSAgVGhlIGNsaWVudCBtYXkgY2hv b3NlIHRvIHVzZSBhIFNvbGljaXQgbWVzc2FnZSB0byBsb2NhdGUgYSBuZXcNCj4gICAgICAgREhD UCBzZXJ2ZXIgYW5kIHNlbmQgYSBSZXF1ZXN0IGZvciB0aGUgZXhwaXJlZCBJQSB0byB0aGUgbmV3 DQo+ICAgICAgIHNlcnZlci4NCj4gICBJZiB0aGUgY2xpZW50IGRvZXMgdGhpcyBmb3Igb25lIElB IHdoaWxlIChyZXNvdXJjZXMgb2YpICBvdGhlciBJQXMNCj4gICBzdGlsbCBub3QgZXhwaXJlZCBh bmQga2VlcHMgc2VuZGluZyBSZWJpbmRpbmcgZm9yIHRoZW0sIGRvZXNuJ3QgdGhlDQo+ICAgY2xp ZW50IGVuZCB1cCBoYXZpbmcgbXVsdGlwbGUgREhDUHY2IHNlc3Npb25zICh3aGljaCB0aGlzIGRy YWZ0DQo+ICAgdHJpZXMgdG8gYXZvaWQpPw0KDQpEaWQgeW91IHJlYWxseSBtZWFuIDQuNS4yIGZy b20gdGhlIGRhdGF0cmFja2VyOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1kaGMtZGhjcHY2LXN0YXRlZnVsLWlzc3Vlcy8NCj8NCg0KVGhlIDQuNS4yIGRvZXNu J3Qgc2VlbSB0byBiZSByZWxldmFudCBoZXJlLg0KDQo+IA0KPiAtIFNlY3Rpb24gNC41LjQ6IG1h eWJlICJvZiBSRkMgMzMxNSIgc2hvdWxkIGJlIGFwcGVuZGVkLCB0byBiZQ0KPiAgIGNvbnNpc3Rl bnQgd2l0aCBvdGhlciBwYXJ0IG9mIHRoZSB0ZXh0Og0KPiANCj4gICAgVGhlIHNlcnZlciBpbmNs dWRlcyBvdGhlciBvcHRpb25zIGNvbnRhaW5pbmcgY29uZmlndXJhdGlvbg0KPiAgICBpbmZvcm1h dGlvbiB0byBiZSByZXR1cm5lZCB0byB0aGUgY2xpZW50IGFzIGRlc2NyaWJlZCBpbiBzZWN0aW9u DQo+ICAgIDE4LjIuDQoNCkl0IGNvdWxkLg0KDQo+IA0KPiAtIFNlY3Rpb24gNC43OiBqdXN0IHdv bmRlcmluZzogZG9lcyB0aGlzIGRlc2NyaWJlIHNvbWUgc3BlY2lmaWMNCj4gICBleGlzdGluZyBj bGllbnQgaW1wbGVtZW50YXRpb24/DQo+IA0KPiAgICBTb21lIGNsaWVudHMgd2lsbCBzZW5kIGEg UmVsZWFzZSBtZXNzYWdlIGZvciBvdGhlciBiaW5kaW5ncyB0aGV5IG1heQ0KPiAgICBoYXZlIHJl Y2VpdmVkIGFmdGVyIHRoZXkgZGV0ZXJtaW5lIGEgY29uZmxpY3QgYW5kIGhhdmUgY29ycmVjdGx5 IHNlbnQNCj4gICAgYSBEZWNsaW5lIG1lc3NhZ2UgZm9yIHRoZSBjb25mbGljdGluZyBhZGRyZXNz KGVzKS4NCj4gDQoNCkknZCBsZXQgQmVybmllIG9yIE9sZSBleHBsYWluIGJ1dCBJJ2QgYmUgb3Bw b3NlZCB0byBwdXR0aW5nIGFueSBzcGVjaWZpYyBzZXJ2ZXIgaW1wbGVtZW50YXRpb25zIGhlcmUu DQoNCk1hcmNpbg0K From nobody Thu Jul 10 12:58:15 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B85BD1B29AB for ; Thu, 10 Jul 2014 12:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMlw-PQZYmS2 for ; Thu, 10 Jul 2014 12:58:12 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 746741A0545 for ; Thu, 10 Jul 2014 12:58:12 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id m15so72241wgh.27 for ; Thu, 10 Jul 2014 12:58:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=dPP51nC3U+QoCwQPYeeaSHUqaMyFxVwrFrm7A8LWNik=; b=GGJdc1U5EFnsyLrfIgNiqVC9GBCorMuiitR/6HJr0zszGvtADkFi4MDklQ6G03EQVG h9fmlCE56roNoO1ktK6igdaYlRIAzwiocsF+iIj+6v+1JlBDYdQHZWNnlsqJpzelMVJE D9Ur1xiv89gPz8EbrJz7Zt9KGvt2ilC//MCKdSSHIfPDgdrFVrNNeItEcYvxzBpB8X5m +TND0RzxiCUHsqfiIfJPUHh5shMfdk3CI+/C8PBsjbDo4xZEf4l6mRf+vPq4P2/LUXg3 5Tv+Jf33syoWGy3W9hymjz0nXNkRGz3fBk0D4i/uNJPFewq+inB8Nm4JNH3yOSodKcqI cXSA== MIME-Version: 1.0 X-Received: by 10.194.172.167 with SMTP id bd7mr1515708wjc.74.1405022291081; Thu, 10 Jul 2014 12:58:11 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.63.211 with HTTP; Thu, 10 Jul 2014 12:58:11 -0700 (PDT) In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1B5F35BE@xmb-rcd-x04.cisco.com> References: <20140630163351.4191.69719.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E1B5E03D1@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1B5E170B@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1B5EE425@xmb-rcd-x04.cisco.com> <53BED1F4.8010807@gmail.com> <489D13FBFA9B3E41812EA89F188F018E1B5F35BE@xmb-rcd-x04.cisco.com> Date: Thu, 10 Jul 2014 12:58:11 -0700 X-Google-Sender-Auth: vnlzxJmNySAw8siEKbi1vDpaeqk Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: "Bernie Volz (volz)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/xxKhq_hXhNY5zguXgwQucyDPTfY Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.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, 10 Jul 2014 19:58:13 -0000 At Thu, 10 Jul 2014 18:44:01 +0000, "Bernie Volz (volz)" wrote: > >> - Section 4.7: just wondering: does this describe some specific > >> existing client implementation? > >> > >> Some clients will send a Release message for other bindings they ma= y > >> have received after they determine a conflict and have correctly se= nt > >> a Decline message for the conflicting address(es). > >> > > > >I'd let Bernie or Ole explain but I'd be opposed to putting any specific= server implementations here. > > Yes, it does describe existing implementations. This is an issue that Tim= Winters raised. I don't believe I have details on which specific CLIENT im= plementations might be doing this. But in any case, I don't think it is app= ropriate to specify which implementations in a document such as this. > > Are you suggesting we remove the first paragraph and just simple leave th= e second? But I do think it adds value to explain that this might be 'in th= e field' behavior. Is there better wording you want used (other than naming= 'some implementations'). Would "Some client implementations are [have been= ] known to ..." be better wording? I didn't intend to suggest anything (that's why I said "just wondering"). It was just not very clear to me whether this is about some actual implementation or it states something general. Now that I understand it's the former, "Some client implementations are [have been] known to ..." sounds clearer to me, but that's not a strong opinion. -- JINMEI, Tatuya From nobody Thu Jul 10 17:10:53 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDF1D1A0168; Thu, 10 Jul 2014 17:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.994 X-Spam-Level: X-Spam-Status: No, score=-3.994 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 OrwlzVNDnOI6; Thu, 10 Jul 2014 17:10:43 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD93B1A0123; Thu, 10 Jul 2014 17:10:25 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id s6B0ANf1025672; Fri, 11 Jul 2014 09:10:23 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id s6B0ANFR017263; Fri, 11 Jul 2014 09:10:23 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id KAA17260; Fri, 11 Jul 2014 09:10:23 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id s6B0AMkL029277; Fri, 11 Jul 2014 09:10:23 +0900 (JST) Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id s6B0AMf2024245; Fri, 11 Jul 2014 09:10:22 +0900 (JST) Received: from [133.199.147.10] (ivpn-7-10.mobile.toshiba.co.jp [133.199.147.10]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id 74B5E97D1C; Fri, 11 Jul 2014 09:10:22 +0900 (JST) Message-ID: <53BE21E8.60007@toshiba.co.jp> Date: Thu, 10 Jul 2014 14:17:28 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Bernie Volz (volz)" , Andre Kostur References: <20140701155803.14047.81610.idtracker@ietfa.amsl.com> <53BA92D9.3000606@toshiba.co.jp> <489D13FBFA9B3E41812EA89F188F018E1B5E9CA7@xmb-rcd-x04.cisco.com> <53BBA43B.3080207@toshiba.co.jp> <489D13FBFA9B3E41812EA89F188F018E1B5EC66C@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1B5EC66C@xmb-rcd-x04.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/74erUaQ17qIyoVePunWI1arufik Cc: "dhcwg@ietf.org" , Routing Over Low power and Lossy networks Subject: Re: [dhcwg] MPL config draft (Re: [Roll] I-D Action: draft-ietf-roll-mpl-parameter-configuration-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: Fri, 11 Jul 2014 00:10:48 -0000 Hi Bernie, (2014-07-09 5:59), Bernie Volz (volz) wrote: > Hi: > > I don't have a great answer for you as I have no idea what the > typical usages are likely to be. If there are likely to be many > instances and the desire to configure most of the values (and for > multiple domains), then one single option for each domain with all > of the values is certainly a better idea. Thanks, I'll add some note to describe expected use case. The options are likely to be used as a set and I think open single option is easier to implement. > I think the main points here are to: - avoid compressing the data / > developing new data types and use more standard elements (i.e., 16 > or 32-bit integers) - see RFC 7227. - group things logically (i.e., > alignment of the data, while making the picture easier to draw, is > not a requirement [of course we assume it is octet (byte) aligned]). I agree. In addition, I noticed 8bit common exponent (in other words, unit time of timers) for all timers will be much much simpler. > There are many ways to format this data, each with pros and cons. > Making those tradeoffs is something I am not in a good position to > help you with. Your comments are very helpful for me, thanks! Regards, Yusuke From nobody Thu Jul 10 20:18:30 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE271A020A; Thu, 10 Jul 2014 20:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.008 X-Spam-Level: X-Spam-Status: No, score=-1.008 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, RP_MATCHES_RCVD=-0.651] 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 0dr4uVgj37F2; Thu, 10 Jul 2014 20:18:26 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CEF91A01C6; Thu, 10 Jul 2014 20:18:26 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 25D021B8504; Thu, 10 Jul 2014 20:18:26 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id CF96E190068; Thu, 10 Jul 2014 20:18:25 -0700 (PDT) Received: from [10.0.10.40] (71.233.43.215) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 10 Jul 2014 20:18:25 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: <53BBA3EF.9040609@toshiba.co.jp> Date: Thu, 10 Jul 2014 16:48:57 -0400 Content-Transfer-Encoding: 7bit Message-ID: <43CF020C-1007-40A9-8F58-0B4F64672736@nominum.com> References: <20140701155803.14047.81610.idtracker@ietfa.amsl.com> <53BA92D9.3000606@toshiba.co.jp> <53BBA3EF.9040609@toshiba.co.jp> To: Yusuke DOI X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/pEnVdQjsgn5PwLH9KJnk3sLJkrA Cc: "dhcwg@ietf.org" , Routing Over Low power and Lossy networks , Andre Kostur Subject: Re: [dhcwg] MPL config draft (Re: [Roll] I-D Action: draft-ietf-roll-mpl-parameter-configuration-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: Fri, 11 Jul 2014 03:18:27 -0000 On Jul 8, 2014, at 3:55 AM, Yusuke DOI wrote: > 1) Typical MAC we're expecting is 50k-200kbps mesh network with 5+ hops. > I think a compact option format is more suitable for the case. This doesn't sound like something you'd configure with DHCP. From nobody Fri Jul 11 21:14:39 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 314B21B29F1; Fri, 11 Jul 2014 21:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 58KFAaF2dnq9; Fri, 11 Jul 2014 21:14:29 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id C07E51B29E5; Fri, 11 Jul 2014 21:14:29 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 3773E18000E; Fri, 11 Jul 2014 21:13:51 -0700 (PDT) To: sus-e@ubiquitous.co.jp, stevea@lachman.com, droms@bucknell.edu X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20140712041351.3773E18000E@rfc-editor.org> Date: Fri, 11 Jul 2014 21:13:51 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/KyWM3iyddQiQuIeeFgpw_Hs7FH0 Cc: dhcwg@ietf.org, rfc-editor@rfc-editor.org, ted.lemon@nominum.com, iesg@ietf.org Subject: [dhcwg] [Errata Rejected] RFC1533 (4045) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2014 04:14:32 -0000 The following errata report has been rejected for RFC1533, "DHCP Options and BOOTP Vendor Extensions". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=1533&eid=4045 -------------------------------------- Status: Rejected Type: Editorial Reported by: Susumu Endoh Date Reported: 2014-07-07 Rejected by: Ted Lemon (IESG) Section: 3.10 Original Text ------------- The code for the log server option is 8. Corrected Text -------------- The code for the cookie server option is 8. Notes ----- --VERIFIER NOTES-- RFC 1533 was obsoleted by RFC 2132. -------------------------------------- RFC1533 (no draft string recorded) -------------------------------------- Title : DHCP Options and BOOTP Vendor Extensions Publication Date : October 1993 Author(s) : S. Alexander, R. Droms Category : PROPOSED STANDARD Source : Dynamic Host Configuration Area : Internet Stream : IETF Verifying Party : IESG From nobody Sat Jul 12 05:37:06 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 549181B286A; Sat, 12 Jul 2014 05:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xiR0oJayD82; Sat, 12 Jul 2014 05:37:02 -0700 (PDT) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00A9B1B2866; Sat, 12 Jul 2014 05:37:01 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id s7so63134qap.23 for ; Sat, 12 Jul 2014 05:37:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dTZY3HCOQARl4SuH4Ux6WOdoDOIBfsyNesa+46xWDbY=; b=BlW6m2UtBkXpUh9fzA9llkCvPxfsKDgI4TK7mrfLGMolODsjSLpmD0VYMPcSoFSQ1P 4gTueJvlSLOcaPu0+uUKqH4qu5sSPnfvO1XX8pO47w9Y9iUKm4mGeU8yKg6a+7DueHWM 0jIqHMuS5QAkPI7M410KWKGiqSZmGtrO/sgMSma+/SYUZ+uyNfb5mMJP8Pgt7xfZ6qy+ u7/iMR35+6gwSkPhIyRAPrGWzOlh1SYCcauxbihz8omdnwTTDnqVGVatMblRN0SSmpLr hw3KH3d2JQ5B3MoDbukEpRLo/GOCHjFHvVPMfOod7AbUrD7pVc200L9Tq6kbny3XjL2n e1Jw== X-Received: by 10.224.3.201 with SMTP id 9mr4947569qao.73.1405168620020; Sat, 12 Jul 2014 05:37:00 -0700 (PDT) Received: from [172.20.10.3] (mobile-198-228-204-049.mycingular.net. [198.228.204.49]) by mx.google.com with ESMTPSA id 94sm5261082qgu.20.2014.07.12.05.36.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 12 Jul 2014 05:36:58 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ralph Droms In-Reply-To: <43CF020C-1007-40A9-8F58-0B4F64672736@nominum.com> Date: Sat, 12 Jul 2014 08:36:56 -0400 Content-Transfer-Encoding: 7bit Message-Id: <3C9237BF-BF7F-43BF-8A12-35CB9BE6E7F1@gmail.com> References: <20140701155803.14047.81610.idtracker@ietfa.amsl.com> <53BA92D9.3000606@toshiba.co.jp> <53BBA3EF.9040609@toshiba.co.jp> <43CF020C-1007-40A9-8F58-0B4F64672736@nominum.com> To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/PsUQjcBGKj96EMYQNuNkgIEdNSw Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] [Roll] MPL config draft (Re: I-D Action: draft-ietf-roll-mpl-parameter-configuration-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: Sat, 12 Jul 2014 12:37:03 -0000 On Jul 10, 2014, at 4:48 PM 7/10/14, Ted Lemon wrote: > On Jul 8, 2014, at 3:55 AM, Yusuke DOI wrote: >> 1) Typical MAC we're expecting is 50k-200kbps mesh network with 5+ hops. >> I think a compact option format is more suitable for the case. > > This doesn't sound like something you'd configure with DHCP. Ted - what does "this" refer to? MPL in general? - Ralph From nobody Sat Jul 12 09:32:05 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531431B2B94; Sat, 12 Jul 2014 09:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 GFxCedjfnUPF; Sat, 12 Jul 2014 09:32:00 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED94E1B2B92; Sat, 12 Jul 2014 09:31:59 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 9A3561B860F; Sat, 12 Jul 2014 09:31:59 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 73B80190068; Sat, 12 Jul 2014 09:31:59 -0700 (PDT) Received: from [10.0.10.40] (71.233.43.215) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 12 Jul 2014 09:31:53 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <3C9237BF-BF7F-43BF-8A12-35CB9BE6E7F1@gmail.com> Date: Sat, 12 Jul 2014 12:31:50 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20140701155803.14047.81610.idtracker@ietfa.amsl.com> <53BA92D9.3000606@toshiba.co.jp> <53BBA3EF.9040609@toshiba.co.jp> <43CF020C-1007-40A9-8F58-0B4F64672736@nominum.com> <3C9237BF-BF7F-43BF-8A12-35CB9BE6E7F1@gmail.com> To: Ralph Droms X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/pe4Tn3WyLE9avEAxkue__pkGiu4 Cc: "dhcwg@ietf.org" , Routing Over Low power and Lossy networks Subject: Re: [dhcwg] [Roll] MPL config draft (Re: I-D Action: draft-ietf-roll-mpl-parameter-configuration-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: Sat, 12 Jul 2014 16:32:04 -0000 On Jul 12, 2014, at 8:36 AM, Ralph Droms wrote: > Ted - what does "this" refer to? MPL in general? Using DHCP to push a big chunk of information about the state of a mesh = network seems like a suboptimal approach. The fact that compression is = desired suggests that you are using the wrong tool for the job. From nobody Mon Jul 14 02:09:28 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE7FF1A0070 for ; Mon, 14 Jul 2014 02:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-_ZONRZBtEu for ; Mon, 14 Jul 2014 02:09:24 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC3181A0051 for ; Mon, 14 Jul 2014 02:09:24 -0700 (PDT) Received: from BY2PR05MB237.namprd05.prod.outlook.com (10.242.41.146) by BY2PR05MB238.namprd05.prod.outlook.com (10.242.41.153) with Microsoft SMTP Server (TLS) id 15.0.980.8; Mon, 14 Jul 2014 09:09:22 +0000 Received: from BY2PR05MB237.namprd05.prod.outlook.com ([169.254.15.77]) by BY2PR05MB237.namprd05.prod.outlook.com ([169.254.15.77]) with mapi id 15.00.0985.008; Mon, 14 Jul 2014 09:09:22 +0000 From: Sunil Gandhewar To: Tomek Mrugalski , dhcwg , "dhcpv6bis@etf.org" Thread-Topic: [dhcwg] New Version Notification for draft-dhcwg-dhc-rfc3315bis-02 Thread-Index: AQHPl7H5+nczx3/upEqtjXwMsyvafZud6sBg Date: Mon, 14 Jul 2014 09:09:21 +0000 Message-ID: References: <20140704171020.22117.76924.idtracker@ietfa.amsl.com> <53B6EBD6.6090509@gmail.com> In-Reply-To: <53B6EBD6.6090509@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.19] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02723F29C4 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(377424004)(377454003)(189002)(19580395003)(76176999)(2656002)(83072002)(79102001)(19580405001)(85852003)(76482001)(85306003)(86362001)(83322001)(21056001)(74502001)(46102001)(107046002)(99286002)(15202345003)(87936001)(92566001)(50986999)(81542001)(77096002)(66066001)(106116001)(81342001)(105586002)(15975445006)(54356999)(74662001)(33646001)(31966008)(99396002)(106356001)(95666004)(80022001)(74316001)(101416001)(64706001)(20776003)(4396001)(77982001)(76576001)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB238; H:BY2PR05MB237.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/WUiC1_YE-qEAGwsz410HuZ1wHsU Subject: Re: [dhcwg] New Version Notification for draft-dhcwg-dhc-rfc3315bis-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: Mon, 14 Jul 2014 09:09:27 -0000 Hi, I have following comments: 1. Need to include Universal DUID in section 24.5 2. The following text from Section 22.6 should be removed: An IA Address option may appear only in an IA_NA option or an IA_TA option. Because RFC 5007 DHCPv6 Leasequery and 5460 DHCPv6 Bulk Leasequery uses thi= s option inside OPTION_LQ_QUERY (section 4.1.2.1 RFC 5007), OPTION_CLIENT_D= ATA (section 4.1.2.2 of RFC 5007). Section 4.4.2 of RFC 5007 explains the u= se. Regards, Sunil Gandhewar -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek Mrugalski Sent: Friday, July 04, 2014 11:31 PM To: dhcwg Subject: [dhcwg] New Version Notification for draft-dhcwg-dhc-rfc3315bis-02 We managed to upload rfc3315bis-02 before the deadline. There are too many = changes to mention here, so we're keeping a changelog. See appendices A (ch= anges since RFC3315) and B (changes since RFC3633). The lists now mention 30 changes. In general, we managed to merge around 80% of the RFC3633 text. The outstan= ding text will likely be affected by the stateful-issues, so we're waiting = for this discussion to be resolved first. You can see the progress here: http://wiki.tools.ietf.org/group/dhcpv6bis/roadmap The changes will be briefly presented in Toronto, but we'll focus more on u= nresolved issues. Thanks a lot to everyone who helped move this effort forward. Andrew, Bernie, Marcin, Michael, Sheng, Ted and Tomek (the DHCPv6bis team) -------- Original Message -------- Subject: New Version Notification for draft-dhcwg-dhc-rfc3315bis-02.txt Date: Fri, 04 Jul 2014 10:10:20 -0700 From: internet-drafts@ietf.org To: Andrew Yourtchenko , "Bernie Volz" , "Tomek Mrugalski" , Bernie Vo= lz , Marcin Siodelski , Michael C. Ri= chardson , "Sheng Jiang" , Ted Lemon , "Andrew Yourtch= enko" , Tomek Mrugalski , S= heng Jiang , "Marcin Siodelski" , "Michael Richardson" , "Ted Lemon" A new version of I-D, draft-dhcwg-dhc-rfc3315bis-02.txt has been successful= ly submitted by Tomek Mrugalski and posted to the IETF repository. Name: draft-dhcwg-dhc-rfc3315bis Revision: 02 Title: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) bis Document date: 2014-07-04 Group: Individual Submission Pages: 119 URL: http://www.ietf.org/internet-drafts/draft-dhcwg-dhc-rfc3315bis-02.txt Status: https://datatracker.ietf.org/doc/draft-dhcwg-dhc-rfc3315bis= / Htmlized: http://tools.ietf.org/html/draft-dhcwg-dhc-rfc3315bis-02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-dhcwg-dhc-rfc3315bis-02 Abstract: The Dynamic Host Configuration Protocol for IPv6 (DHCP) enables DHCP servers to pass configuration parameters such as IPv6 network addresses to IPv6 nodes. It offers the capability of automatic allocation of reusable network addresses and additional configuration flexibility. This protocol is a stateful counterpart to "IPv6 Stateless Address Autoconfiguration" (RFC 4862), and can be used separately or concurrently with the latter to obtain configuration parameters. Please note that it may take a couple of minutes from the time of 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 From nobody Mon Jul 14 02:13:59 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F141A0070 for ; Mon, 14 Jul 2014 02:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, 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 4ZhNEknH7h4b for ; Mon, 14 Jul 2014 02:13:53 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCC8A1A0091 for ; Mon, 14 Jul 2014 02:13:53 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id va2so1887285obc.26 for ; Mon, 14 Jul 2014 02:13:53 -0700 (PDT) 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=DpahMyMxMyrwFEA2e20M7PX8HVm6QHmr+Q4igjaL+wo=; b=U6Y18yuDT29ppo5AWp8wBa4e1+w/d8hfkeud1Vjn9o3M/Zp+81xCns08WtOC6fHeUs JH6x+Cu69EqsnXm3NzHSbpw/BdnAz4pq1BOKKLqGGkCRPi6Y8M08iathY3xBuGTxNygl 6e6dVHY9CqTNn7Dxgnt4GQry1pU4d1Yd+gA1vUVBFBPNz+lBBdbOkDGBmph4UCGqO4db WbXU7hRvOQQWdzTlQTdMsZyRe5QQIBOmW7rmLJDaByMtAtzdSTYNxQ9uuq9saR7qcIyI Efs3F9rQLSESmN0kAjim2cP2wmVEaHuT62d0IafSkUsu7SipC8rQfzx/fdrlWttYypmF +Cuw== X-Received: by 10.182.97.97 with SMTP id dz1mr16562167obb.13.1405329233104; Mon, 14 Jul 2014 02:13:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.85.210 with HTTP; Mon, 14 Jul 2014 02:13:33 -0700 (PDT) In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1B5E03D1@xmb-rcd-x04.cisco.com> References: <20140630163351.4191.69719.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E1B5E03D1@xmb-rcd-x04.cisco.com> From: Cong Liu Date: Mon, 14 Jul 2014 17:13:33 +0800 Message-ID: To: "Bernie Volz (volz)" Content-Type: multipart/alternative; boundary=047d7b2e4386bb54e804fe23b5f9 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/Cknj1BxvbD2KXk6BTvAIckeCR5A Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.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, 14 Jul 2014 09:13:57 -0000 --047d7b2e4386bb54e804fe23b5f9 Content-Type: text/plain; charset=UTF-8 Hi, I have a question on section 4: "Proposed solution: the client should keep *a single session* with the server and include the missing options on subsequent messages (Request, Renew, and Rebind) to the server. My understanding is that it implicitly objects to "create separate DHCP sessions for each IA option type" in the previous paragraph. If there are two servers: server_A only replies IA_NA and server_P only replies IA_PD. The client sends Solicit message requesting both IA_NA and IA_PD, and receives Advertise messages from both servers. Will the client only keep a single session with just one of the servers, or two sessions with both servers? For the former case, the client will unlikely get both IA_NA and IA_PD although it continue requesting both IA_NA and IA_PD in subsequent messages. If it is the latter case, what would be in the client's IA_NA in subsequent Request, Renew, and Rebind messages to the server_P? Does the IA_NA to server_P contains the IA_NA address from server_A's Advertise (that's what the client gets), or no address (that's what server_P has replied) ? Best Regards, Cong 2014-07-01 0:55 GMT+08:00 Bernie Volz (volz) : > Hi: > > A new version of this document has been posted. Sorry for the long delay > but there were some significant changes to make and thanks to Marcin for > joining the authors to make some of those changes. > > The major differences are: > 1. Sections 4.1 and 4.2 (Advertise Message and Placement of Status Code) > were swapped. The reason for this is because we decided to use the Reply > formatting for the status codes in Advertise too. It turns out that there > are server implementations that did already use this formatting and there > have been no reported issues. So, client implementations must be handling > this acceptable. This is a better long term solution since it doesn't > special case the IA_NA/IA_TA handling in Advertise. > 2. The 4.4 Renew and 4.5 Rebind sections have had major changes and rework > (that to Marcin). > 3. The 4.6 Confirm section was changed to remove use of Confirm for IA_PD > (Rebind is mandated). For IA_NA and/or IA_TA only, Confirm can be used. If > IA_PD exists, Rebind should be used (not Confirm). > 4. Replaced 4.7. Release Message with a 4.7 Decline Should Not > Necessarily Trigger a Release (an issue reported by Tim Winters). > 5. There are other minor edits (such as referencing RFC 7084 instead of > RFC 6204). > > There is one outstanding issue that we'd like to get feedback on from > folks (as well as of course the other changes made). We can discuss on the > mailing list but will also discuss at the Toronto IETF DHC WG Session. > > This is the issue of which status codes Renew and Rebind should use when a > server is unable to provide "leases" for a binding. Presently the text says > to use NoBinding and part of that reason was that this is consistent with > what is currently written in RFC 3315. But it may be better to use > NoAddrsAvail/NoPrefixAvail instead of NoBinding. Marcin and I debated this > some and here is some data regarding this issue: > > 1. A Request never returns NoBinding. It uses NoAddrsAvail/NoPrefixAvail. > So, if we wanted to make Renew (and Rebind) more closely aligned ... > 2. Existing servers (that follow 3315) will return NoBinding. Thus, > returning this would provide a client no information as to whether the > server was new or not - and whether to initiate a Solicit/... cycle. On the > flip side, existing clients handle NoBinding so that could avoid issues > with unexpected status results? > 3. We have 4 possible responses for an IA for a Renew/Rebind when no > 'resources' are assigned: > 3.a. Return NoBinding. > 3.b. Return NoAddrsAvail/NoPrefixAvail. > 3.c. Return an 'empty' IA (no IAADDR or IAPREFIX options). > 3.d. Don't return the IA. (I'm not a fan of this one as it might imply to > the client that the server doesn't know that IA.) 4. Is there any value in > returning additional information to a client for a Rebind? For a Rebind, > there are two possibilities as to why the server didn't assign > addresses/prefixes: > 4.a. The server has no resources available at the present time. > 4.b. The server is not able to assign resources because it is not > configured to support "rapid commit". > So, should we consider whether these should be handled differently? For > 4.a., if the client retries (i.e., Renew, Solicit) it may get a resource > but may not - depends on why it isn't available and whether something has > happened to make a resource available. For 4.b, if the client retries > (i.e., Renew, Solicit) it would likely get the resource. > 5. There is one other condition to consider - my original assumption for > Renew was that the server could 'refuse' to service the client if the > server had no record of the client (i.e., no bindings). In this case, > returning NoBinding for all of the IA_* would be appropriate - to force the > client to Solicit/... > > (If we do 'drop' NoBinding from Renew/Rebind, then this status code would > only be used for Release/Decline Replies.) > > My feeling is that for Renew/Rebind: > - We should return NoAddrsAvail/NoPrefixAvail when the server cannot > provide the requested resources but would if it 'could'. > - We should reserve NoBinding to trigger the client to go back to > Solicit/... or Request. Therefore, this should only be used in conditions > where the server wants (needs) the client to do that. > > If would be nice if the status codes (or empty or missing IA) had > consistent meanings for 'all' messages and thus triggered consistent client > actions. > > Putting NoAddrsAvail into the IA carried in the Reply to Renew/Rebind > shouldn't cause problems in the clients that really follow the current > RFC3315 as in the section 18.1.8 it clearly specifies what to do with IAs > that contain NoAddrsAvail in the Reply message and it doesn't > differentiate between the types of messages in response to which the Reply > has been received. The following paragraph: > > "When the client receives a Reply message in response to a Renew or > Rebind message, the client examines each IA independently. For each > IA in the original Renew or Rebind message, the client: > > - sends a Request message if the IA contained a Status Code option > with the NoBinding status (and does not send any additional > Renew/Rebind messages) > > - sends a Renew/Rebind if the IA is not in the Reply message > > - otherwise accepts the information in the IA " > may be a source of trouble for clients which implementers ignored the > preceding paragraph and simply made an assumption that NoAddrsAvail is not > returned for Renew/Rebind. On the other hand the client shouldn't fall over > just because it gets the unexpected status code. > > So in principle it seems to be fine to use NoAddrsAvail/NoPrefixAvail in > the Reply messages sent as a response to Renew/Rebind. > > > Anyway, give the current draft a read and if there are concerns or > questions (or you have a view on the issue), please send mail to the list > ASAP. > > - Bernie > > -----Original Message----- > From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Monday, June 30, 2014 12:34 PM > To: i-d-announce@ietf.org > Cc: dhcwg@ietf.org > Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.txt > > > 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 : Issues with multiple stateful DHCPv6 options > Authors : Ole Troan > Bernie Volz > Marcin Siodelski > Filename : draft-ietf-dhc-dhcpv6-stateful-issues-06.txt > Pages : 20 > Date : 2014-06-30 > > Abstract: > Dynamic Host Configuration Protocol for IPv6 (DHCPv6) was not written > with the expectation that additional stateful DHCPv6 options would be > developed. IPv6 Prefix Options for Dynamic Host Configuration > Protocol (DHCP) version 6 shoe-horned the new options for Prefix > Delegation into DHCPv6. Implementation experience of the CPE model > described in RFC 7084 has shown multiple issues with the DHCPv6 > protocol in supporting multiple stateful options. This document > updates RFC 3315 and RFC 3633. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-stateful-issues/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-stateful-issues-06 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv6-stateful-issues-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/ > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > --047d7b2e4386bb54e804fe23b5f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I have a question on section 4:
=C2=A0 =C2=A0"Proposed solution: the client should keep a si= ngle session with the
=C2=A0 =C2=A0server and include the mis= sing options on subsequent messages
=C2=A0 =C2=A0(Request, Renew, and Rebind) to the server.
My understanding is that it implicitly objects to "create = separate DHCP sessions for each IA option type" in the previous paragr= aph.

If there are two servers: server_A only replies IA_NA a= nd server_P only replies IA_PD. The client sends=C2=A0Solicit message requesting both IA_NA and IA_PD, = and receives Advertise messages from both se= rvers. Will the client only keep a single session with just one of the serv= ers, or two sessions with both servers? For the former case, the client wil= l unlikely get both IA_NA and IA_PD although it continue requesting both IA= _NA and IA_PD in=C2=A0subsequent messages.

= If it is the latter case, what would be in the client's IA_NA in=C2=A0<= /font>subsequent Request, Renew, and Rebind messages to the server_P? Does = the IA_NA to server_P contains the IA_NA address from server_A's Advert= ise (that's what the client gets), or no address (that's what serve= r_P has replied) ?

Best Regards,
Cong

=


2014-07-01 0:= 55 GMT+08:00 Bernie Volz (volz) <volz@cisco.com>:
Hi:

A new version of this document has been posted. Sorry for the long delay bu= t there were some significant changes to make and thanks to Marcin for join= ing the authors to make some of those changes.

The major differences are:
1. Sections 4.1 and 4.2 (Advertise Message and Placement of Status Code) we= re swapped. The reason for this is because we decided to use the Reply form= atting for the status codes in Advertise too. It turns out that there are s= erver implementations that did already use this formatting and there have b= een no reported issues. So, client implementations must be handling this ac= ceptable. This is a better long term solution since it doesn't special = case the IA_NA/IA_TA handling in Advertise.
2. The 4.4 Renew and 4.5 Rebind sections have had major changes and rework = (that to Marcin).
3. The 4.6 Confirm section was changed to remove use of Confirm for IA_PD (= Rebind is mandated). For IA_NA and/or IA_TA only, Confirm can be used. If I= A_PD exists, Rebind should be used (not Confirm).
4. Replaced 4.7. =C2=A0Release Message with a 4.7 =C2=A0Decline Should Not = Necessarily Trigger a Release (an issue reported by Tim Winters).
5. There are other minor edits (such as referencing RFC 7084 instead of RFC= 6204).

There is one outstanding issue that we'd like to get feedback on from f= olks (as well as of course the other changes made). We can discuss on the m= ailing list but will also discuss at the Toronto IETF DHC WG Session.

This is the issue of which status codes Renew and Rebind should use when a = server is unable to provide "leases" for a binding. Presently the= text says to use NoBinding and part of that reason was that this is consis= tent with what is currently written in RFC 3315. But it may be better to us= e NoAddrsAvail/NoPrefixAvail instead of NoBinding. Marcin and I debated thi= s some and here is some data regarding this issue:

1. A Request never returns NoBinding. It uses NoAddrsAvail/NoPrefixAvail. S= o, if we wanted to make Renew (and Rebind) more closely aligned ...
2. Existing servers (that follow 3315) will return NoBinding. Thus, returni= ng this would provide a client no information as to whether the server was = new or not - and whether to initiate a Solicit/... cycle. On the flip side,= existing clients handle NoBinding so that could avoid issues with unexpect= ed status results?
3. We have 4 possible responses for an IA for a Renew/Rebind when no 'r= esources' =C2=A0are assigned:
3.a. Return NoBinding.
3.b. Return NoAddrsAvail/NoPrefixAvail.
3.c. Return an 'empty' IA (no IAADDR or IAPREFIX options).
3.d. Don't return the IA. (I'm not a fan of this one as it might im= ply to the client that the server doesn't know that IA.) 4. Is there an= y value in returning additional information to a client for a Rebind? For a= Rebind, there are two possibilities as to why the server didn't assign= addresses/prefixes:
4.a. The server has no resources available at the present time.
4.b. The server is not able to assign resources because it is not configure= d to support "rapid commit".
So, should we consider whether these should be handled differently? For 4.a= ., if the client retries (i.e., Renew, Solicit) it may get a resource but m= ay not - depends on why it isn't available and whether something has ha= ppened to make a resource available. For 4.b, if the client retries (i.e., = Renew, Solicit) it would likely get the resource.
5. There is one other condition to consider - my original assumption for Re= new was that the server could 'refuse' to service the client if the= server had no record of the client (i.e., no bindings). In this case, retu= rning NoBinding for all of the IA_* would be appropriate - to force the cli= ent to Solicit/...

(If we do 'drop' NoBinding from Renew/Rebind, then this status code= would only be used for Release/Decline Replies.)

My feeling is that for Renew/Rebind:
- We should return NoAddrsAvail/NoPrefixAvail when the server cannot provid= e the requested resources but would if it 'could'.
- We should reserve NoBinding to trigger the client to go back to Solicit/.= .. or Request. Therefore, this should only be used in conditions where the = server wants (needs) the client to do that.

If would be nice if the status codes (or empty or missing IA) had consisten= t meanings for 'all' messages and thus triggered consistent client = actions.

Putting NoAddrsAvail into the IA carried in the Reply to Renew/Rebind shoul= dn't cause problems in the clients that really follow the current RFC33= 15 as in the section 18.1.8 it clearly specifies what to do with IAs that c= ontain NoAddrsAvail in the Reply message =C2=A0and it doesn't different= iate between the types of messages in response to which the Reply has been = received. The following paragraph:

"When the client receives a Reply message in response to a Renew or =C2=A0 =C2=A0Rebind message, the client examines each IA independently. =C2= =A0For each
=C2=A0 =C2=A0IA in the original Renew or Rebind message, the client:

=C2=A0 =C2=A0- =C2=A0sends a Request message if the IA contained a Status C= ode option
=C2=A0 =C2=A0 =C2=A0 with the NoBinding status (and does not send any addit= ional
=C2=A0 =C2=A0 =C2=A0 Renew/Rebind messages)

=C2=A0 =C2=A0- =C2=A0sends a Renew/Rebind if the IA is not in the Reply mes= sage

=C2=A0 =C2=A0- =C2=A0otherwise accepts the information in the IA "
may be a source of trouble for clients which implementers ignored the prece= ding paragraph and simply made an assumption that NoAddrsAvail is not retur= ned for Renew/Rebind. On the other hand the client shouldn't fall over = just because it gets the unexpected status code.

So in principle it seems to be fine to use NoAddrsAvail/NoPrefixAvail in th= e Reply messages sent as a response to Renew/Rebind.


Anyway, give the current draft a read and if there are concerns or question= s (or you have a view on the issue), please send mail to the list ASAP.

- Bernie

-----Original Message-----
From: dhcwg [mailto:dhcwg-bounces= @ietf.org] On Behalf Of int= ernet-drafts@ietf.org
Sent: Monday, June 30, 2014 12:34 PM
To: i-d-announce@ietf.org
Cc: dhcwg@ietf.org
Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Dynamic Host Configuration Working G= roup of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Issu= es with multiple stateful DHCPv6 options
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Ole Troan=
=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 Bernie Volz
=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 Marcin Siodelski
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-iet= f-dhc-dhcpv6-stateful-issues-06.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 20 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 2014-06-30

Abstract:
=C2=A0 =C2=A0Dynamic Host Configuration Protocol for IPv6 (DHCPv6) was not = written
=C2=A0 =C2=A0with the expectation that additional stateful DHCPv6 options w= ould be
=C2=A0 =C2=A0developed. =C2=A0IPv6 Prefix Options for Dynamic Host Configur= ation
=C2=A0 =C2=A0Protocol (DHCP) version 6 shoe-horned the new options for Pref= ix
=C2=A0 =C2=A0Delegation into DHCPv6. =C2=A0Implementation experience of the= CPE model
=C2=A0 =C2=A0described in RFC 7084 has shown multiple issues with the DHCPv= 6
=C2=A0 =C2=A0protocol in supporting multiple stateful options. =C2=A0This d= ocument
=C2=A0 =C2=A0updates RFC 3315 and RFC 3633.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dhc-= dhcpv6-stateful-issues/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-sta= teful-issues-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-iet= f-dhc-dhcpv6-stateful-issues-06


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg

--047d7b2e4386bb54e804fe23b5f9-- From nobody Mon Jul 14 06:05:50 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B64A1A03D7 for ; Mon, 14 Jul 2014 06:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 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.651, 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 mAhDx6XSR1w7 for ; Mon, 14 Jul 2014 06:03:16 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0724F1A03C5 for ; Mon, 14 Jul 2014 06:02:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=43106; q=dns/txt; s=iport; t=1405342976; x=1406552576; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=rGAMh38UQNXYAyjCjcBtXxd//boFYDy2UkEYMDKlbqs=; b=AMvQl107+VRFPBenASkD54a2RFzDtF6jA7Zu4Gccw35qZkzccZWkGcUJ /wF1bthsjXHWw2cOexQGtK9c/j/acfffdhR0zPM6Wutohl+8CLs367cxc QBG3usPDxKN5XtqIT8FZXWUvN2yAIsQN6crVP2gqc1LyR7Jxvofwz9JLh g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8KAJrUw1OtJV2b/2dsb2JhbABZgkdHUlMHgnGqdZIKgVYBC4dBARl9FnWEAwEBAQQBAQEgCjoHCwwEAgEIDgMEAQELFgcDAgICHwYLFAkIAgQOBQgBEogTAxEIBbAZkB4NhygXiX6DIIFcAQEeDwcQBwQGAQYDgm42gRYFmQ6DSow9hheDRIF3OQ X-IronPort-AV: E=Sophos; i="5.01,658,1400025600"; d="scan'208,217"; a="60631643" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-3.cisco.com with ESMTP; 14 Jul 2014 13:02:55 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s6ED2sCh022545 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Jul 2014 13:02:54 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.176]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Mon, 14 Jul 2014 08:02:54 -0500 From: "Bernie Volz (volz)" To: Cong Liu Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.txt Thread-Index: AQHPlIEus6CA5H78HkuHLmw+Sv8Eh5uJ3xfAgBXTfYD//+iMgA== Date: Mon, 14 Jul 2014 13:02:54 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1B5F6A45@xmb-rcd-x04.cisco.com> References: <20140630163351.4191.69719.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E1B5E03D1@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.244.233] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1B5F6A45xmbrcdx04ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/9efsS3wpQrzuQfHzCCCescg2skQ X-Mailman-Approved-At: Mon, 14 Jul 2014 06:05:42 -0700 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.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, 14 Jul 2014 13:03:24 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E1B5F6A45xmbrcdx04ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGk6DQoNClRoaXMgaXMg4oCcc2hvdWxk4oCdLiBUaGF0IGFsbG93cyBmb3IgY2FzZXMgd2hlcmUg YSBjbGllbnQgbWF5IHdhbnQgdG8gdXNlIG11bHRpcGxlIHNlc3Npb25zIHRvIGRpZmZlcmVudCBz ZXJ2ZXJzLiBUaGlzIG1pZ2h0IHdlbGwgYmUgdGhlIGNhc2UgaWYgbXVsdGlwbGUgcHJvdmlzaW9u aW5nIGRvbWFpbnMgd2VyZSBpbiBwbGF5IOKAkyBzZWUgc2VjdGlvbiA0LjguIEJ1dCB0aGlzIGlz IGFuICBhcmVhIG9mIHBvdGVudGlhbCBmdXR1cmUgd29yayDigKYNCg0KSWYgYSBjbGllbnQgZGVj aWRlcyB0byBzdGFydCBtdWx0aXBsZSBzZXNzaW9ucywgd2h5IHdvdWxkIGl0IHRoZW4gY29tYmlu ZSB0aGUgdHdvIHNlcGFyYXRlIHNlc3Npb25zPyBJIHRoaW5rIGl0IHNob3VsZCBrZWVwIHRoZSB0 cmFuc2FjdGlvbnMgY29tcGxldGVseSBzZXBhcmF0ZSAoZXZlbiB3aGVuIHJlYWNoaW5nIHRoZSBS ZWJpbmQg4oCYc3RhdGXigJkpLiBJZiBpdCBkb2VzbuKAmXQga2VlcCB0aGluZ3Mgc2VwYXJhdGUs IGl0IGNvdWxkIHZlcnkgd2VsbCBlbmQgdXAgd2l0aCBjb25mbGljdGluZyBhbnN3ZXJzIOKAkyBp dCBhbGwgZGVwZW5kcyBvbiB3aGF0IGVhY2ggc2VydmVyIGtub3dzIGFib3V0IHdoYXQgdGhlIG90 aGVyIGhhcyBhbmQgaG93IGl0IHJlc3BvbmRzIChyZXNwb25kIHdpdGgg4oCcTm9CaW5kaW5n4oCd LCByZXNwb25kIHdpdGggMCBsaWZldGltZXMsIHJlc3BvbmQgd2l0aCDigJxOb3RPbkxpbmvigJ0s IOKApikuDQoNCldlIGRvIE5PVCBjb3ZlciB0aGlzIHNpbmNlIHdlIGRvIE5PVCBleHBlY3QgY2xp ZW50cyB3aWxsIGdlbmVyYWxseSB3YW50IHRvIGRvIHRoaXMuIEJ1dCB0aGVyZSBpcyBub3RoaW5n IHRoYXQgcHJvaGliaXRzIHRoaXMgYmFzZWQgb24gUkZDIDMzMTUgYW5kIHRoaXMgZHJhZnQuDQoN CkkgZG9u4oCZdCBrbm93IGlmIHlvdSBhcmUgc3VnZ2VzdGluZyBhbnkgY2hhbmdlcyB0byB0aGUg dGV4dCwgaWYgc28sIHBsZWFzZSBwcm92aWRlIHRob3NlIHN1Z2dlc3Rpb25zLg0KDQoNCi0gICAg ICAgICAgQmVybmllDQoNCkZyb206IENvbmcgTGl1IFttYWlsdG86Z25vY3VpbEBnbWFpbC5jb21d DQpTZW50OiBNb25kYXksIEp1bHkgMTQsIDIwMTQgNToxNCBBTQ0KVG86IEJlcm5pZSBWb2x6ICh2 b2x6KQ0KQ2M6IGRoY3dnQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2RoY3dnXSBJLUQgQWN0aW9u OiBkcmFmdC1pZXRmLWRoYy1kaGNwdjYtc3RhdGVmdWwtaXNzdWVzLTA2LnR4dA0KDQpIaSwNCg0K SSBoYXZlIGEgcXVlc3Rpb24gb24gc2VjdGlvbiA0Og0KICAgIlByb3Bvc2VkIHNvbHV0aW9uOiB0 aGUgY2xpZW50IHNob3VsZCBrZWVwIGEgc2luZ2xlIHNlc3Npb24gd2l0aCB0aGUNCiAgIHNlcnZl ciBhbmQgaW5jbHVkZSB0aGUgbWlzc2luZyBvcHRpb25zIG9uIHN1YnNlcXVlbnQgbWVzc2FnZXMN CiAgIChSZXF1ZXN0LCBSZW5ldywgYW5kIFJlYmluZCkgdG8gdGhlIHNlcnZlci4NCg0KTXkgdW5k ZXJzdGFuZGluZyBpcyB0aGF0IGl0IGltcGxpY2l0bHkgb2JqZWN0cyB0byAiY3JlYXRlIHNlcGFy YXRlIERIQ1Agc2Vzc2lvbnMgZm9yIGVhY2ggSUEgb3B0aW9uIHR5cGUiIGluIHRoZSBwcmV2aW91 cyBwYXJhZ3JhcGguDQoNCklmIHRoZXJlIGFyZSB0d28gc2VydmVyczogc2VydmVyX0Egb25seSBy ZXBsaWVzIElBX05BIGFuZCBzZXJ2ZXJfUCBvbmx5IHJlcGxpZXMgSUFfUEQuIFRoZSBjbGllbnQg c2VuZHMgU29saWNpdCBtZXNzYWdlIHJlcXVlc3RpbmcgYm90aCBJQV9OQSBhbmQgSUFfUEQsIGFu ZCByZWNlaXZlcyBBZHZlcnRpc2UgbWVzc2FnZXMgZnJvbSBib3RoIHNlcnZlcnMuIFdpbGwgdGhl IGNsaWVudCBvbmx5IGtlZXAgYSBzaW5nbGUgc2Vzc2lvbiB3aXRoIGp1c3Qgb25lIG9mIHRoZSBz ZXJ2ZXJzLCBvciB0d28gc2Vzc2lvbnMgd2l0aCBib3RoIHNlcnZlcnM/IEZvciB0aGUgZm9ybWVy IGNhc2UsIHRoZSBjbGllbnQgd2lsbCB1bmxpa2VseSBnZXQgYm90aCBJQV9OQSBhbmQgSUFfUEQg YWx0aG91Z2ggaXQgY29udGludWUgcmVxdWVzdGluZyBib3RoIElBX05BIGFuZCBJQV9QRCBpbiBz dWJzZXF1ZW50IG1lc3NhZ2VzLg0KDQpJZiBpdCBpcyB0aGUgbGF0dGVyIGNhc2UsIHdoYXQgd291 bGQgYmUgaW4gdGhlIGNsaWVudCdzIElBX05BIGluIHN1YnNlcXVlbnQgUmVxdWVzdCwgUmVuZXcs IGFuZCBSZWJpbmQgbWVzc2FnZXMgdG8gdGhlIHNlcnZlcl9QPyBEb2VzIHRoZSBJQV9OQSB0byBz ZXJ2ZXJfUCBjb250YWlucyB0aGUgSUFfTkEgYWRkcmVzcyBmcm9tIHNlcnZlcl9BJ3MgQWR2ZXJ0 aXNlICh0aGF0J3Mgd2hhdCB0aGUgY2xpZW50IGdldHMpLCBvciBubyBhZGRyZXNzICh0aGF0J3Mg d2hhdCBzZXJ2ZXJfUCBoYXMgcmVwbGllZCkgPw0KDQpCZXN0IFJlZ2FyZHMsDQpDb25nDQoNCg0K MjAxNC0wNy0wMSAwOjU1IEdNVCswODowMCBCZXJuaWUgVm9seiAodm9seikgPHZvbHpAY2lzY28u Y29tPG1haWx0bzp2b2x6QGNpc2NvLmNvbT4+Og0KSGk6DQoNCkEgbmV3IHZlcnNpb24gb2YgdGhp cyBkb2N1bWVudCBoYXMgYmVlbiBwb3N0ZWQuIFNvcnJ5IGZvciB0aGUgbG9uZyBkZWxheSBidXQg dGhlcmUgd2VyZSBzb21lIHNpZ25pZmljYW50IGNoYW5nZXMgdG8gbWFrZSBhbmQgdGhhbmtzIHRv IE1hcmNpbiBmb3Igam9pbmluZyB0aGUgYXV0aG9ycyB0byBtYWtlIHNvbWUgb2YgdGhvc2UgY2hh bmdlcy4NCg0KVGhlIG1ham9yIGRpZmZlcmVuY2VzIGFyZToNCjEuIFNlY3Rpb25zIDQuMSBhbmQg NC4yIChBZHZlcnRpc2UgTWVzc2FnZSBhbmQgUGxhY2VtZW50IG9mIFN0YXR1cyBDb2RlKSB3ZXJl IHN3YXBwZWQuIFRoZSByZWFzb24gZm9yIHRoaXMgaXMgYmVjYXVzZSB3ZSBkZWNpZGVkIHRvIHVz ZSB0aGUgUmVwbHkgZm9ybWF0dGluZyBmb3IgdGhlIHN0YXR1cyBjb2RlcyBpbiBBZHZlcnRpc2Ug dG9vLiBJdCB0dXJucyBvdXQgdGhhdCB0aGVyZSBhcmUgc2VydmVyIGltcGxlbWVudGF0aW9ucyB0 aGF0IGRpZCBhbHJlYWR5IHVzZSB0aGlzIGZvcm1hdHRpbmcgYW5kIHRoZXJlIGhhdmUgYmVlbiBu byByZXBvcnRlZCBpc3N1ZXMuIFNvLCBjbGllbnQgaW1wbGVtZW50YXRpb25zIG11c3QgYmUgaGFu ZGxpbmcgdGhpcyBhY2NlcHRhYmxlLiBUaGlzIGlzIGEgYmV0dGVyIGxvbmcgdGVybSBzb2x1dGlv biBzaW5jZSBpdCBkb2Vzbid0IHNwZWNpYWwgY2FzZSB0aGUgSUFfTkEvSUFfVEEgaGFuZGxpbmcg aW4gQWR2ZXJ0aXNlLg0KMi4gVGhlIDQuNCBSZW5ldyBhbmQgNC41IFJlYmluZCBzZWN0aW9ucyBo YXZlIGhhZCBtYWpvciBjaGFuZ2VzIGFuZCByZXdvcmsgKHRoYXQgdG8gTWFyY2luKS4NCjMuIFRo ZSA0LjYgQ29uZmlybSBzZWN0aW9uIHdhcyBjaGFuZ2VkIHRvIHJlbW92ZSB1c2Ugb2YgQ29uZmly bSBmb3IgSUFfUEQgKFJlYmluZCBpcyBtYW5kYXRlZCkuIEZvciBJQV9OQSBhbmQvb3IgSUFfVEEg b25seSwgQ29uZmlybSBjYW4gYmUgdXNlZC4gSWYgSUFfUEQgZXhpc3RzLCBSZWJpbmQgc2hvdWxk IGJlIHVzZWQgKG5vdCBDb25maXJtKS4NCjQuIFJlcGxhY2VkIDQuNy4gIFJlbGVhc2UgTWVzc2Fn ZSB3aXRoIGEgNC43ICBEZWNsaW5lIFNob3VsZCBOb3QgTmVjZXNzYXJpbHkgVHJpZ2dlciBhIFJl bGVhc2UgKGFuIGlzc3VlIHJlcG9ydGVkIGJ5IFRpbSBXaW50ZXJzKS4NCjUuIFRoZXJlIGFyZSBv dGhlciBtaW5vciBlZGl0cyAoc3VjaCBhcyByZWZlcmVuY2luZyBSRkMgNzA4NCBpbnN0ZWFkIG9m IFJGQyA2MjA0KS4NCg0KVGhlcmUgaXMgb25lIG91dHN0YW5kaW5nIGlzc3VlIHRoYXQgd2UnZCBs aWtlIHRvIGdldCBmZWVkYmFjayBvbiBmcm9tIGZvbGtzIChhcyB3ZWxsIGFzIG9mIGNvdXJzZSB0 aGUgb3RoZXIgY2hhbmdlcyBtYWRlKS4gV2UgY2FuIGRpc2N1c3Mgb24gdGhlIG1haWxpbmcgbGlz dCBidXQgd2lsbCBhbHNvIGRpc2N1c3MgYXQgdGhlIFRvcm9udG8gSUVURiBESEMgV0cgU2Vzc2lv bi4NCg0KVGhpcyBpcyB0aGUgaXNzdWUgb2Ygd2hpY2ggc3RhdHVzIGNvZGVzIFJlbmV3IGFuZCBS ZWJpbmQgc2hvdWxkIHVzZSB3aGVuIGEgc2VydmVyIGlzIHVuYWJsZSB0byBwcm92aWRlICJsZWFz ZXMiIGZvciBhIGJpbmRpbmcuIFByZXNlbnRseSB0aGUgdGV4dCBzYXlzIHRvIHVzZSBOb0JpbmRp bmcgYW5kIHBhcnQgb2YgdGhhdCByZWFzb24gd2FzIHRoYXQgdGhpcyBpcyBjb25zaXN0ZW50IHdp dGggd2hhdCBpcyBjdXJyZW50bHkgd3JpdHRlbiBpbiBSRkMgMzMxNS4gQnV0IGl0IG1heSBiZSBi ZXR0ZXIgdG8gdXNlIE5vQWRkcnNBdmFpbC9Ob1ByZWZpeEF2YWlsIGluc3RlYWQgb2YgTm9CaW5k aW5nLiBNYXJjaW4gYW5kIEkgZGViYXRlZCB0aGlzIHNvbWUgYW5kIGhlcmUgaXMgc29tZSBkYXRh IHJlZ2FyZGluZyB0aGlzIGlzc3VlOg0KDQoxLiBBIFJlcXVlc3QgbmV2ZXIgcmV0dXJucyBOb0Jp bmRpbmcuIEl0IHVzZXMgTm9BZGRyc0F2YWlsL05vUHJlZml4QXZhaWwuIFNvLCBpZiB3ZSB3YW50 ZWQgdG8gbWFrZSBSZW5ldyAoYW5kIFJlYmluZCkgbW9yZSBjbG9zZWx5IGFsaWduZWQgLi4uDQoy LiBFeGlzdGluZyBzZXJ2ZXJzICh0aGF0IGZvbGxvdyAzMzE1KSB3aWxsIHJldHVybiBOb0JpbmRp bmcuIFRodXMsIHJldHVybmluZyB0aGlzIHdvdWxkIHByb3ZpZGUgYSBjbGllbnQgbm8gaW5mb3Jt YXRpb24gYXMgdG8gd2hldGhlciB0aGUgc2VydmVyIHdhcyBuZXcgb3Igbm90IC0gYW5kIHdoZXRo ZXIgdG8gaW5pdGlhdGUgYSBTb2xpY2l0Ly4uLiBjeWNsZS4gT24gdGhlIGZsaXAgc2lkZSwgZXhp c3RpbmcgY2xpZW50cyBoYW5kbGUgTm9CaW5kaW5nIHNvIHRoYXQgY291bGQgYXZvaWQgaXNzdWVz IHdpdGggdW5leHBlY3RlZCBzdGF0dXMgcmVzdWx0cz8NCjMuIFdlIGhhdmUgNCBwb3NzaWJsZSBy ZXNwb25zZXMgZm9yIGFuIElBIGZvciBhIFJlbmV3L1JlYmluZCB3aGVuIG5vICdyZXNvdXJjZXMn ICBhcmUgYXNzaWduZWQ6DQozLmEuIFJldHVybiBOb0JpbmRpbmcuDQozLmIuIFJldHVybiBOb0Fk ZHJzQXZhaWwvTm9QcmVmaXhBdmFpbC4NCjMuYy4gUmV0dXJuIGFuICdlbXB0eScgSUEgKG5vIElB QUREUiBvciBJQVBSRUZJWCBvcHRpb25zKS4NCjMuZC4gRG9uJ3QgcmV0dXJuIHRoZSBJQS4gKEkn bSBub3QgYSBmYW4gb2YgdGhpcyBvbmUgYXMgaXQgbWlnaHQgaW1wbHkgdG8gdGhlIGNsaWVudCB0 aGF0IHRoZSBzZXJ2ZXIgZG9lc24ndCBrbm93IHRoYXQgSUEuKSA0LiBJcyB0aGVyZSBhbnkgdmFs dWUgaW4gcmV0dXJuaW5nIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gdG8gYSBjbGllbnQgZm9yIGEg UmViaW5kPyBGb3IgYSBSZWJpbmQsIHRoZXJlIGFyZSB0d28gcG9zc2liaWxpdGllcyBhcyB0byB3 aHkgdGhlIHNlcnZlciBkaWRuJ3QgYXNzaWduIGFkZHJlc3Nlcy9wcmVmaXhlczoNCjQuYS4gVGhl IHNlcnZlciBoYXMgbm8gcmVzb3VyY2VzIGF2YWlsYWJsZSBhdCB0aGUgcHJlc2VudCB0aW1lLg0K NC5iLiBUaGUgc2VydmVyIGlzIG5vdCBhYmxlIHRvIGFzc2lnbiByZXNvdXJjZXMgYmVjYXVzZSBp dCBpcyBub3QgY29uZmlndXJlZCB0byBzdXBwb3J0ICJyYXBpZCBjb21taXQiLg0KU28sIHNob3Vs ZCB3ZSBjb25zaWRlciB3aGV0aGVyIHRoZXNlIHNob3VsZCBiZSBoYW5kbGVkIGRpZmZlcmVudGx5 PyBGb3IgNC5hLiwgaWYgdGhlIGNsaWVudCByZXRyaWVzIChpLmUuLCBSZW5ldywgU29saWNpdCkg aXQgbWF5IGdldCBhIHJlc291cmNlIGJ1dCBtYXkgbm90IC0gZGVwZW5kcyBvbiB3aHkgaXQgaXNu J3QgYXZhaWxhYmxlIGFuZCB3aGV0aGVyIHNvbWV0aGluZyBoYXMgaGFwcGVuZWQgdG8gbWFrZSBh IHJlc291cmNlIGF2YWlsYWJsZS4gRm9yIDQuYiwgaWYgdGhlIGNsaWVudCByZXRyaWVzIChpLmUu LCBSZW5ldywgU29saWNpdCkgaXQgd291bGQgbGlrZWx5IGdldCB0aGUgcmVzb3VyY2UuDQo1LiBU aGVyZSBpcyBvbmUgb3RoZXIgY29uZGl0aW9uIHRvIGNvbnNpZGVyIC0gbXkgb3JpZ2luYWwgYXNz dW1wdGlvbiBmb3IgUmVuZXcgd2FzIHRoYXQgdGhlIHNlcnZlciBjb3VsZCAncmVmdXNlJyB0byBz ZXJ2aWNlIHRoZSBjbGllbnQgaWYgdGhlIHNlcnZlciBoYWQgbm8gcmVjb3JkIG9mIHRoZSBjbGll bnQgKGkuZS4sIG5vIGJpbmRpbmdzKS4gSW4gdGhpcyBjYXNlLCByZXR1cm5pbmcgTm9CaW5kaW5n IGZvciBhbGwgb2YgdGhlIElBXyogd291bGQgYmUgYXBwcm9wcmlhdGUgLSB0byBmb3JjZSB0aGUg Y2xpZW50IHRvIFNvbGljaXQvLi4uDQoNCihJZiB3ZSBkbyAnZHJvcCcgTm9CaW5kaW5nIGZyb20g UmVuZXcvUmViaW5kLCB0aGVuIHRoaXMgc3RhdHVzIGNvZGUgd291bGQgb25seSBiZSB1c2VkIGZv ciBSZWxlYXNlL0RlY2xpbmUgUmVwbGllcy4pDQoNCk15IGZlZWxpbmcgaXMgdGhhdCBmb3IgUmVu ZXcvUmViaW5kOg0KLSBXZSBzaG91bGQgcmV0dXJuIE5vQWRkcnNBdmFpbC9Ob1ByZWZpeEF2YWls IHdoZW4gdGhlIHNlcnZlciBjYW5ub3QgcHJvdmlkZSB0aGUgcmVxdWVzdGVkIHJlc291cmNlcyBi dXQgd291bGQgaWYgaXQgJ2NvdWxkJy4NCi0gV2Ugc2hvdWxkIHJlc2VydmUgTm9CaW5kaW5nIHRv IHRyaWdnZXIgdGhlIGNsaWVudCB0byBnbyBiYWNrIHRvIFNvbGljaXQvLi4uIG9yIFJlcXVlc3Qu IFRoZXJlZm9yZSwgdGhpcyBzaG91bGQgb25seSBiZSB1c2VkIGluIGNvbmRpdGlvbnMgd2hlcmUg dGhlIHNlcnZlciB3YW50cyAobmVlZHMpIHRoZSBjbGllbnQgdG8gZG8gdGhhdC4NCg0KSWYgd291 bGQgYmUgbmljZSBpZiB0aGUgc3RhdHVzIGNvZGVzIChvciBlbXB0eSBvciBtaXNzaW5nIElBKSBo YWQgY29uc2lzdGVudCBtZWFuaW5ncyBmb3IgJ2FsbCcgbWVzc2FnZXMgYW5kIHRodXMgdHJpZ2dl cmVkIGNvbnNpc3RlbnQgY2xpZW50IGFjdGlvbnMuDQoNClB1dHRpbmcgTm9BZGRyc0F2YWlsIGlu dG8gdGhlIElBIGNhcnJpZWQgaW4gdGhlIFJlcGx5IHRvIFJlbmV3L1JlYmluZCBzaG91bGRuJ3Qg Y2F1c2UgcHJvYmxlbXMgaW4gdGhlIGNsaWVudHMgdGhhdCByZWFsbHkgZm9sbG93IHRoZSBjdXJy ZW50IFJGQzMzMTUgYXMgaW4gdGhlIHNlY3Rpb24gMTguMS44IGl0IGNsZWFybHkgc3BlY2lmaWVz IHdoYXQgdG8gZG8gd2l0aCBJQXMgdGhhdCBjb250YWluIE5vQWRkcnNBdmFpbCBpbiB0aGUgUmVw bHkgbWVzc2FnZSAgYW5kIGl0IGRvZXNuJ3QgZGlmZmVyZW50aWF0ZSBiZXR3ZWVuIHRoZSB0eXBl cyBvZiBtZXNzYWdlcyBpbiByZXNwb25zZSB0byB3aGljaCB0aGUgUmVwbHkgaGFzIGJlZW4gcmVj ZWl2ZWQuIFRoZSBmb2xsb3dpbmcgcGFyYWdyYXBoOg0KDQoiV2hlbiB0aGUgY2xpZW50IHJlY2Vp dmVzIGEgUmVwbHkgbWVzc2FnZSBpbiByZXNwb25zZSB0byBhIFJlbmV3IG9yDQogICBSZWJpbmQg bWVzc2FnZSwgdGhlIGNsaWVudCBleGFtaW5lcyBlYWNoIElBIGluZGVwZW5kZW50bHkuICBGb3Ig ZWFjaA0KICAgSUEgaW4gdGhlIG9yaWdpbmFsIFJlbmV3IG9yIFJlYmluZCBtZXNzYWdlLCB0aGUg Y2xpZW50Og0KDQogICAtICBzZW5kcyBhIFJlcXVlc3QgbWVzc2FnZSBpZiB0aGUgSUEgY29udGFp bmVkIGEgU3RhdHVzIENvZGUgb3B0aW9uDQogICAgICB3aXRoIHRoZSBOb0JpbmRpbmcgc3RhdHVz IChhbmQgZG9lcyBub3Qgc2VuZCBhbnkgYWRkaXRpb25hbA0KICAgICAgUmVuZXcvUmViaW5kIG1l c3NhZ2VzKQ0KDQogICAtICBzZW5kcyBhIFJlbmV3L1JlYmluZCBpZiB0aGUgSUEgaXMgbm90IGlu IHRoZSBSZXBseSBtZXNzYWdlDQoNCiAgIC0gIG90aGVyd2lzZSBhY2NlcHRzIHRoZSBpbmZvcm1h dGlvbiBpbiB0aGUgSUEgIg0KbWF5IGJlIGEgc291cmNlIG9mIHRyb3VibGUgZm9yIGNsaWVudHMg d2hpY2ggaW1wbGVtZW50ZXJzIGlnbm9yZWQgdGhlIHByZWNlZGluZyBwYXJhZ3JhcGggYW5kIHNp bXBseSBtYWRlIGFuIGFzc3VtcHRpb24gdGhhdCBOb0FkZHJzQXZhaWwgaXMgbm90IHJldHVybmVk IGZvciBSZW5ldy9SZWJpbmQuIE9uIHRoZSBvdGhlciBoYW5kIHRoZSBjbGllbnQgc2hvdWxkbid0 IGZhbGwgb3ZlciBqdXN0IGJlY2F1c2UgaXQgZ2V0cyB0aGUgdW5leHBlY3RlZCBzdGF0dXMgY29k ZS4NCg0KU28gaW4gcHJpbmNpcGxlIGl0IHNlZW1zIHRvIGJlIGZpbmUgdG8gdXNlIE5vQWRkcnNB dmFpbC9Ob1ByZWZpeEF2YWlsIGluIHRoZSBSZXBseSBtZXNzYWdlcyBzZW50IGFzIGEgcmVzcG9u c2UgdG8gUmVuZXcvUmViaW5kLg0KDQoNCkFueXdheSwgZ2l2ZSB0aGUgY3VycmVudCBkcmFmdCBh IHJlYWQgYW5kIGlmIHRoZXJlIGFyZSBjb25jZXJucyBvciBxdWVzdGlvbnMgKG9yIHlvdSBoYXZl IGEgdmlldyBvbiB0aGUgaXNzdWUpLCBwbGVhc2Ugc2VuZCBtYWlsIHRvIHRoZSBsaXN0IEFTQVAu DQoNCi0gQmVybmllDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBkaGN3ZyBb bWFpbHRvOmRoY3dnLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmRoY3dnLWJvdW5jZXNAaWV0Zi5v cmc+XSBPbiBCZWhhbGYgT2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmc+DQpTZW50OiBNb25kYXksIEp1bmUgMzAsIDIwMTQgMTI6MzQgUE0N ClRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmc8bWFpbHRvOmktZC1hbm5vdW5jZUBpZXRmLm9yZz4N CkNjOiBkaGN3Z0BpZXRmLm9yZzxtYWlsdG86ZGhjd2dAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbZGhj d2ddIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtZGhjLWRoY3B2Ni1zdGF0ZWZ1bC1pc3N1ZXMtMDYu dHh0DQoNCg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxp bmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KIFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0 ZW0gb2YgdGhlIER5bmFtaWMgSG9zdCBDb25maWd1cmF0aW9uIFdvcmtpbmcgR3JvdXAgb2YgdGhl IElFVEYuDQoNCiAgICAgICAgVGl0bGUgICAgICAgICAgIDogSXNzdWVzIHdpdGggbXVsdGlwbGUg c3RhdGVmdWwgREhDUHY2IG9wdGlvbnMNCiAgICAgICAgQXV0aG9ycyAgICAgICAgIDogT2xlIFRy b2FuDQogICAgICAgICAgICAgICAgICAgICAgICAgIEJlcm5pZSBWb2x6DQogICAgICAgICAgICAg ICAgICAgICAgICAgIE1hcmNpbiBTaW9kZWxza2kNCiAgICAgICAgRmlsZW5hbWUgICAgICAgIDog ZHJhZnQtaWV0Zi1kaGMtZGhjcHY2LXN0YXRlZnVsLWlzc3Vlcy0wNi50eHQNCiAgICAgICAgUGFn ZXMgICAgICAgICAgIDogMjANCiAgICAgICAgRGF0ZSAgICAgICAgICAgIDogMjAxNC0wNi0zMA0K DQpBYnN0cmFjdDoNCiAgIER5bmFtaWMgSG9zdCBDb25maWd1cmF0aW9uIFByb3RvY29sIGZvciBJ UHY2IChESENQdjYpIHdhcyBub3Qgd3JpdHRlbg0KICAgd2l0aCB0aGUgZXhwZWN0YXRpb24gdGhh dCBhZGRpdGlvbmFsIHN0YXRlZnVsIERIQ1B2NiBvcHRpb25zIHdvdWxkIGJlDQogICBkZXZlbG9w ZWQuICBJUHY2IFByZWZpeCBPcHRpb25zIGZvciBEeW5hbWljIEhvc3QgQ29uZmlndXJhdGlvbg0K ICAgUHJvdG9jb2wgKERIQ1ApIHZlcnNpb24gNiBzaG9lLWhvcm5lZCB0aGUgbmV3IG9wdGlvbnMg Zm9yIFByZWZpeA0KICAgRGVsZWdhdGlvbiBpbnRvIERIQ1B2Ni4gIEltcGxlbWVudGF0aW9uIGV4 cGVyaWVuY2Ugb2YgdGhlIENQRSBtb2RlbA0KICAgZGVzY3JpYmVkIGluIFJGQyA3MDg0IGhhcyBz aG93biBtdWx0aXBsZSBpc3N1ZXMgd2l0aCB0aGUgREhDUHY2DQogICBwcm90b2NvbCBpbiBzdXBw b3J0aW5nIG11bHRpcGxlIHN0YXRlZnVsIG9wdGlvbnMuICBUaGlzIGRvY3VtZW50DQogICB1cGRh dGVzIFJGQyAzMzE1IGFuZCBSRkMgMzYzMy4NCg0KDQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0 dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtZGhjLWRoY3B2Ni1zdGF0ZWZ1bC1pc3N1ZXMvDQoNClRoZXJlJ3MgYWxz byBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1kaGMtZGhjcHY2LXN0YXRlZnVsLWlzc3Vlcy0wNg0KDQpBIGRpZmYg ZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQpodHRwOi8vd3d3Lmll dGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWRoYy1kaGNwdjYtc3RhdGVmdWwtaXNzdWVz LTA2DQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVz IGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBh bmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnPGh0dHA6Ly90b29scy5pZXRm Lm9yZz4uDQoNCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3Vz IEZUUCBhdDoNCmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpkaGN3ZyBtYWlsaW5nIGxp c3QNCmRoY3dnQGlldGYub3JnPG1haWx0bzpkaGN3Z0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2cNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCmRoY3dnIG1haWxpbmcgbGlzdA0KZGhjd2dAaWV0Zi5v cmc8bWFpbHRvOmRoY3dnQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9kaGN3Zw0KDQo= --_000_489D13FBFA9B3E41812EA89F188F018E1B5F6A45xmbrcdx04ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJ bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0K CWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgs IGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1w cmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdp bi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjt9DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5CYWxs b29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9u dC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoyNjA0 NTk4MTc7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjEy MDI3NjIwMTAgLTE3MTgzNDE5NDIgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEg Njc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJ e21zby1sZXZlbC1zdGFydC1hdDo3Ow0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxp YnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGww OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30N CnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+SGk6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGlzIGlzIOKAnHNob3VsZOKAnS4gVGhhdCBhbGxvd3Mg Zm9yIGNhc2VzIHdoZXJlIGEgY2xpZW50IG1heSB3YW50IHRvIHVzZSBtdWx0aXBsZSBzZXNzaW9u cyB0byBkaWZmZXJlbnQgc2VydmVycy4gVGhpcyBtaWdodCB3ZWxsIGJlIHRoZSBjYXNlIGlmIG11 bHRpcGxlIHByb3Zpc2lvbmluZw0KIGRvbWFpbnMgd2VyZSBpbiBwbGF5IOKAkyBzZWUgc2VjdGlv biA0LjguIEJ1dCB0aGlzIGlzIGFuICZuYnNwO2FyZWEgb2YgcG90ZW50aWFsIGZ1dHVyZSB3b3Jr IOKApjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+SWYgYSBjbGllbnQgZGVjaWRlcyB0byBzdGFydCBtdWx0aXBsZSBzZXNz aW9ucywgd2h5IHdvdWxkIGl0IHRoZW4gY29tYmluZSB0aGUgdHdvIHNlcGFyYXRlIHNlc3Npb25z PyBJIHRoaW5rIGl0IHNob3VsZCBrZWVwIHRoZSB0cmFuc2FjdGlvbnMgY29tcGxldGVseSBzZXBh cmF0ZQ0KIChldmVuIHdoZW4gcmVhY2hpbmcgdGhlIFJlYmluZCDigJhzdGF0ZeKAmSkuIElmIGl0 IGRvZXNu4oCZdCBrZWVwIHRoaW5ncyBzZXBhcmF0ZSwgaXQgY291bGQgdmVyeSB3ZWxsIGVuZCB1 cCB3aXRoIGNvbmZsaWN0aW5nIGFuc3dlcnMg4oCTIGl0IGFsbCBkZXBlbmRzIG9uIHdoYXQgZWFj aCBzZXJ2ZXIga25vd3MgYWJvdXQgd2hhdCB0aGUgb3RoZXIgaGFzIGFuZCBob3cgaXQgcmVzcG9u ZHMgKHJlc3BvbmQgd2l0aCDigJxOb0JpbmRpbmfigJ0sIHJlc3BvbmQgd2l0aA0KIDAgbGlmZXRp bWVzLCByZXNwb25kIHdpdGgg4oCcTm90T25MaW5r4oCdLCDigKYpLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2UgZG8g Tk9UIGNvdmVyIHRoaXMgc2luY2Ugd2UgZG8gTk9UIGV4cGVjdCBjbGllbnRzIHdpbGwgZ2VuZXJh bGx5IHdhbnQgdG8gZG8gdGhpcy4gQnV0IHRoZXJlIGlzIG5vdGhpbmcgdGhhdCBwcm9oaWJpdHMg dGhpcyBiYXNlZCBvbiBSRkMgMzMxNSBhbmQgdGhpcyBkcmFmdC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgZG9u4oCZ dCBrbm93IGlmIHlvdSBhcmUgc3VnZ2VzdGluZyBhbnkgY2hhbmdlcyB0byB0aGUgdGV4dCwgaWYg c28sIHBsZWFzZSBwcm92aWRlIHRob3NlIHN1Z2dlc3Rpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlz dFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEg bGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0i Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3Nw YW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5C ZXJuaWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IENvbmcgTGl1 IFttYWlsdG86Z25vY3VpbEBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBK dWx5IDE0LCAyMDE0IDU6MTQgQU08YnI+DQo8Yj5Ubzo8L2I+IEJlcm5pZSBWb2x6ICh2b2x6KTxi cj4NCjxiPkNjOjwvYj4gZGhjd2dAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtk aGN3Z10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1kaGMtZGhjcHY2LXN0YXRlZnVsLWlzc3Vlcy0w Ni50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSw8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBhIHF1ZXN0aW9uIG9u IHNlY3Rpb24gNDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyAmbmJzcDsmcXVvdDtQcm9wb3NlZCBzb2x1dGlvbjogdGhlIGNsaWVudCBz aG91bGQga2VlcCA8aT5hIHNpbmdsZSBzZXNzaW9uPC9pPiB3aXRoIHRoZTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO3NlcnZl ciBhbmQgaW5jbHVkZSB0aGUgbWlzc2luZyBvcHRpb25zIG9uIHN1YnNlcXVlbnQgbWVzc2FnZXM8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OyAmbmJzcDsoUmVxdWVzdCwgUmVuZXcsIGFuZCBSZWJpbmQpIHRvIHRoZSBzZXJ2ZXIuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk15IHVuZGVy c3RhbmRpbmcgaXMgdGhhdCBpdCBpbXBsaWNpdGx5IG9iamVjdHMgdG8gJnF1b3Q7Y3JlYXRlIHNl cGFyYXRlIERIQ1Agc2Vzc2lvbnMgZm9yIGVhY2ggSUEgb3B0aW9uIHR5cGUmcXVvdDsgaW4gdGhl IHByZXZpb3VzIHBhcmFncmFwaC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SWYgdGhlcmUgYXJlIHR3byBzZXJ2ZXJzOiBzZXJ2ZXJfQSBvbmx5 IHJlcGxpZXMgSUFfTkEgYW5kIHNlcnZlcl9QIG9ubHkgcmVwbGllcyBJQV9QRC4gVGhlIGNsaWVu dCBzZW5kcyZuYnNwOzxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+U29saWNpdCBtZXNzYWdlIHJl cXVlc3RpbmcgYm90aCBJQV9OQSBhbmQgSUFfUEQsIGFuZCByZWNlaXZlcyBBZHZlcnRpc2UgbWVz c2FnZXMgZnJvbSBib3RoIHNlcnZlcnMuIFdpbGwgdGhlDQogY2xpZW50IG9ubHkga2VlcCBhIHNp bmdsZSBzZXNzaW9uIHdpdGgganVzdCBvbmUgb2YgdGhlIHNlcnZlcnMsIG9yIHR3byBzZXNzaW9u cyB3aXRoIGJvdGggc2VydmVycz8gRm9yIHRoZSBmb3JtZXIgY2FzZSwgdGhlIGNsaWVudCB3aWxs IHVubGlrZWx5IGdldCBib3RoIElBX05BIGFuZCBJQV9QRCBhbHRob3VnaCBpdCBjb250aW51ZSBy ZXF1ZXN0aW5nIGJvdGggSUFfTkEgYW5kIElBX1BEIGluJm5ic3A7PC9zcGFuPnN1YnNlcXVlbnQg bWVzc2FnZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SWYgaXQgaXMgdGhlIGxhdHRlciBjYXNl LCB3aGF0IHdvdWxkIGJlIGluIHRoZSBjbGllbnQncyBJQV9OQSBpbiZuYnNwOzwvc3Bhbj5zdWJz ZXF1ZW50IFJlcXVlc3QsIFJlbmV3LCBhbmQgUmViaW5kIG1lc3NhZ2VzIHRvIHRoZSBzZXJ2ZXJf UD8gRG9lcyB0aGUgSUFfTkEgdG8gc2VydmVyX1AgY29udGFpbnMgdGhlIElBX05BIGFkZHJlc3Mg ZnJvbSBzZXJ2ZXJfQSdzIEFkdmVydGlzZQ0KICh0aGF0J3Mgd2hhdCB0aGUgY2xpZW50IGdldHMp LCBvciBubyBhZGRyZXNzICh0aGF0J3Mgd2hhdCBzZXJ2ZXJfUCBoYXMgcmVwbGllZCkgPzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0IFJl Z2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5Db25nPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yMDE0LTA3LTAxIDA6NTUgR01UJiM0 MzswODowMCBCZXJuaWUgVm9seiAodm9seikgJmx0OzxhIGhyZWY9Im1haWx0bzp2b2x6QGNpc2Nv LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZvbHpAY2lzY28uY29tPC9hPiZndDs6PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaTo8YnI+DQo8YnI+DQpBIG5ldyB2ZXJzaW9uIG9m IHRoaXMgZG9jdW1lbnQgaGFzIGJlZW4gcG9zdGVkLiBTb3JyeSBmb3IgdGhlIGxvbmcgZGVsYXkg YnV0IHRoZXJlIHdlcmUgc29tZSBzaWduaWZpY2FudCBjaGFuZ2VzIHRvIG1ha2UgYW5kIHRoYW5r cyB0byBNYXJjaW4gZm9yIGpvaW5pbmcgdGhlIGF1dGhvcnMgdG8gbWFrZSBzb21lIG9mIHRob3Nl IGNoYW5nZXMuPGJyPg0KPGJyPg0KVGhlIG1ham9yIGRpZmZlcmVuY2VzIGFyZTo8YnI+DQoxLiBT ZWN0aW9ucyA0LjEgYW5kIDQuMiAoQWR2ZXJ0aXNlIE1lc3NhZ2UgYW5kIFBsYWNlbWVudCBvZiBT dGF0dXMgQ29kZSkgd2VyZSBzd2FwcGVkLiBUaGUgcmVhc29uIGZvciB0aGlzIGlzIGJlY2F1c2Ug d2UgZGVjaWRlZCB0byB1c2UgdGhlIFJlcGx5IGZvcm1hdHRpbmcgZm9yIHRoZSBzdGF0dXMgY29k ZXMgaW4gQWR2ZXJ0aXNlIHRvby4gSXQgdHVybnMgb3V0IHRoYXQgdGhlcmUgYXJlIHNlcnZlciBp bXBsZW1lbnRhdGlvbnMgdGhhdCBkaWQgYWxyZWFkeQ0KIHVzZSB0aGlzIGZvcm1hdHRpbmcgYW5k IHRoZXJlIGhhdmUgYmVlbiBubyByZXBvcnRlZCBpc3N1ZXMuIFNvLCBjbGllbnQgaW1wbGVtZW50 YXRpb25zIG11c3QgYmUgaGFuZGxpbmcgdGhpcyBhY2NlcHRhYmxlLiBUaGlzIGlzIGEgYmV0dGVy IGxvbmcgdGVybSBzb2x1dGlvbiBzaW5jZSBpdCBkb2Vzbid0IHNwZWNpYWwgY2FzZSB0aGUgSUFf TkEvSUFfVEEgaGFuZGxpbmcgaW4gQWR2ZXJ0aXNlLjxicj4NCjIuIFRoZSA0LjQgUmVuZXcgYW5k IDQuNSBSZWJpbmQgc2VjdGlvbnMgaGF2ZSBoYWQgbWFqb3IgY2hhbmdlcyBhbmQgcmV3b3JrICh0 aGF0IHRvIE1hcmNpbikuPGJyPg0KMy4gVGhlIDQuNiBDb25maXJtIHNlY3Rpb24gd2FzIGNoYW5n ZWQgdG8gcmVtb3ZlIHVzZSBvZiBDb25maXJtIGZvciBJQV9QRCAoUmViaW5kIGlzIG1hbmRhdGVk KS4gRm9yIElBX05BIGFuZC9vciBJQV9UQSBvbmx5LCBDb25maXJtIGNhbiBiZSB1c2VkLiBJZiBJ QV9QRCBleGlzdHMsIFJlYmluZCBzaG91bGQgYmUgdXNlZCAobm90IENvbmZpcm0pLjxicj4NCjQu IFJlcGxhY2VkIDQuNy4gJm5ic3A7UmVsZWFzZSBNZXNzYWdlIHdpdGggYSA0LjcgJm5ic3A7RGVj bGluZSBTaG91bGQgTm90IE5lY2Vzc2FyaWx5IFRyaWdnZXIgYSBSZWxlYXNlIChhbiBpc3N1ZSBy ZXBvcnRlZCBieSBUaW0gV2ludGVycykuPGJyPg0KNS4gVGhlcmUgYXJlIG90aGVyIG1pbm9yIGVk aXRzIChzdWNoIGFzIHJlZmVyZW5jaW5nIFJGQyA3MDg0IGluc3RlYWQgb2YgUkZDIDYyMDQpLjxi cj4NCjxicj4NClRoZXJlIGlzIG9uZSBvdXRzdGFuZGluZyBpc3N1ZSB0aGF0IHdlJ2QgbGlrZSB0 byBnZXQgZmVlZGJhY2sgb24gZnJvbSBmb2xrcyAoYXMgd2VsbCBhcyBvZiBjb3Vyc2UgdGhlIG90 aGVyIGNoYW5nZXMgbWFkZSkuIFdlIGNhbiBkaXNjdXNzIG9uIHRoZSBtYWlsaW5nIGxpc3QgYnV0 IHdpbGwgYWxzbyBkaXNjdXNzIGF0IHRoZSBUb3JvbnRvIElFVEYgREhDIFdHIFNlc3Npb24uPGJy Pg0KPGJyPg0KVGhpcyBpcyB0aGUgaXNzdWUgb2Ygd2hpY2ggc3RhdHVzIGNvZGVzIFJlbmV3IGFu ZCBSZWJpbmQgc2hvdWxkIHVzZSB3aGVuIGEgc2VydmVyIGlzIHVuYWJsZSB0byBwcm92aWRlICZx dW90O2xlYXNlcyZxdW90OyBmb3IgYSBiaW5kaW5nLiBQcmVzZW50bHkgdGhlIHRleHQgc2F5cyB0 byB1c2UgTm9CaW5kaW5nIGFuZCBwYXJ0IG9mIHRoYXQgcmVhc29uIHdhcyB0aGF0IHRoaXMgaXMg Y29uc2lzdGVudCB3aXRoIHdoYXQgaXMgY3VycmVudGx5IHdyaXR0ZW4gaW4gUkZDDQogMzMxNS4g QnV0IGl0IG1heSBiZSBiZXR0ZXIgdG8gdXNlIE5vQWRkcnNBdmFpbC9Ob1ByZWZpeEF2YWlsIGlu c3RlYWQgb2YgTm9CaW5kaW5nLiBNYXJjaW4gYW5kIEkgZGViYXRlZCB0aGlzIHNvbWUgYW5kIGhl cmUgaXMgc29tZSBkYXRhIHJlZ2FyZGluZyB0aGlzIGlzc3VlOjxicj4NCjxicj4NCjEuIEEgUmVx dWVzdCBuZXZlciByZXR1cm5zIE5vQmluZGluZy4gSXQgdXNlcyBOb0FkZHJzQXZhaWwvTm9QcmVm aXhBdmFpbC4gU28sIGlmIHdlIHdhbnRlZCB0byBtYWtlIFJlbmV3IChhbmQgUmViaW5kKSBtb3Jl IGNsb3NlbHkgYWxpZ25lZCAuLi48YnI+DQoyLiBFeGlzdGluZyBzZXJ2ZXJzICh0aGF0IGZvbGxv dyAzMzE1KSB3aWxsIHJldHVybiBOb0JpbmRpbmcuIFRodXMsIHJldHVybmluZyB0aGlzIHdvdWxk IHByb3ZpZGUgYSBjbGllbnQgbm8gaW5mb3JtYXRpb24gYXMgdG8gd2hldGhlciB0aGUgc2VydmVy IHdhcyBuZXcgb3Igbm90IC0gYW5kIHdoZXRoZXIgdG8gaW5pdGlhdGUgYSBTb2xpY2l0Ly4uLiBj eWNsZS4gT24gdGhlIGZsaXAgc2lkZSwgZXhpc3RpbmcgY2xpZW50cyBoYW5kbGUgTm9CaW5kaW5n DQogc28gdGhhdCBjb3VsZCBhdm9pZCBpc3N1ZXMgd2l0aCB1bmV4cGVjdGVkIHN0YXR1cyByZXN1 bHRzPzxicj4NCjMuIFdlIGhhdmUgNCBwb3NzaWJsZSByZXNwb25zZXMgZm9yIGFuIElBIGZvciBh IFJlbmV3L1JlYmluZCB3aGVuIG5vICdyZXNvdXJjZXMnICZuYnNwO2FyZSBhc3NpZ25lZDo8YnI+ DQozLmEuIFJldHVybiBOb0JpbmRpbmcuPGJyPg0KMy5iLiBSZXR1cm4gTm9BZGRyc0F2YWlsL05v UHJlZml4QXZhaWwuPGJyPg0KMy5jLiBSZXR1cm4gYW4gJ2VtcHR5JyBJQSAobm8gSUFBRERSIG9y IElBUFJFRklYIG9wdGlvbnMpLjxicj4NCjMuZC4gRG9uJ3QgcmV0dXJuIHRoZSBJQS4gKEknbSBu b3QgYSBmYW4gb2YgdGhpcyBvbmUgYXMgaXQgbWlnaHQgaW1wbHkgdG8gdGhlIGNsaWVudCB0aGF0 IHRoZSBzZXJ2ZXIgZG9lc24ndCBrbm93IHRoYXQgSUEuKSA0LiBJcyB0aGVyZSBhbnkgdmFsdWUg aW4gcmV0dXJuaW5nIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gdG8gYSBjbGllbnQgZm9yIGEgUmVi aW5kPyBGb3IgYSBSZWJpbmQsIHRoZXJlIGFyZSB0d28gcG9zc2liaWxpdGllcyBhcyB0byB3aHkN CiB0aGUgc2VydmVyIGRpZG4ndCBhc3NpZ24gYWRkcmVzc2VzL3ByZWZpeGVzOjxicj4NCjQuYS4g VGhlIHNlcnZlciBoYXMgbm8gcmVzb3VyY2VzIGF2YWlsYWJsZSBhdCB0aGUgcHJlc2VudCB0aW1l Ljxicj4NCjQuYi4gVGhlIHNlcnZlciBpcyBub3QgYWJsZSB0byBhc3NpZ24gcmVzb3VyY2VzIGJl Y2F1c2UgaXQgaXMgbm90IGNvbmZpZ3VyZWQgdG8gc3VwcG9ydCAmcXVvdDtyYXBpZCBjb21taXQm cXVvdDsuPGJyPg0KU28sIHNob3VsZCB3ZSBjb25zaWRlciB3aGV0aGVyIHRoZXNlIHNob3VsZCBi ZSBoYW5kbGVkIGRpZmZlcmVudGx5PyBGb3IgNC5hLiwgaWYgdGhlIGNsaWVudCByZXRyaWVzIChp LmUuLCBSZW5ldywgU29saWNpdCkgaXQgbWF5IGdldCBhIHJlc291cmNlIGJ1dCBtYXkgbm90IC0g ZGVwZW5kcyBvbiB3aHkgaXQgaXNuJ3QgYXZhaWxhYmxlIGFuZCB3aGV0aGVyIHNvbWV0aGluZyBo YXMgaGFwcGVuZWQgdG8gbWFrZSBhIHJlc291cmNlIGF2YWlsYWJsZS4NCiBGb3IgNC5iLCBpZiB0 aGUgY2xpZW50IHJldHJpZXMgKGkuZS4sIFJlbmV3LCBTb2xpY2l0KSBpdCB3b3VsZCBsaWtlbHkg Z2V0IHRoZSByZXNvdXJjZS48YnI+DQo1LiBUaGVyZSBpcyBvbmUgb3RoZXIgY29uZGl0aW9uIHRv IGNvbnNpZGVyIC0gbXkgb3JpZ2luYWwgYXNzdW1wdGlvbiBmb3IgUmVuZXcgd2FzIHRoYXQgdGhl IHNlcnZlciBjb3VsZCAncmVmdXNlJyB0byBzZXJ2aWNlIHRoZSBjbGllbnQgaWYgdGhlIHNlcnZl ciBoYWQgbm8gcmVjb3JkIG9mIHRoZSBjbGllbnQgKGkuZS4sIG5vIGJpbmRpbmdzKS4gSW4gdGhp cyBjYXNlLCByZXR1cm5pbmcgTm9CaW5kaW5nIGZvciBhbGwgb2YgdGhlIElBXyogd291bGQNCiBi ZSBhcHByb3ByaWF0ZSAtIHRvIGZvcmNlIHRoZSBjbGllbnQgdG8gU29saWNpdC8uLi48YnI+DQo8 YnI+DQooSWYgd2UgZG8gJ2Ryb3AnIE5vQmluZGluZyBmcm9tIFJlbmV3L1JlYmluZCwgdGhlbiB0 aGlzIHN0YXR1cyBjb2RlIHdvdWxkIG9ubHkgYmUgdXNlZCBmb3IgUmVsZWFzZS9EZWNsaW5lIFJl cGxpZXMuKTxicj4NCjxicj4NCk15IGZlZWxpbmcgaXMgdGhhdCBmb3IgUmVuZXcvUmViaW5kOjxi cj4NCi0gV2Ugc2hvdWxkIHJldHVybiBOb0FkZHJzQXZhaWwvTm9QcmVmaXhBdmFpbCB3aGVuIHRo ZSBzZXJ2ZXIgY2Fubm90IHByb3ZpZGUgdGhlIHJlcXVlc3RlZCByZXNvdXJjZXMgYnV0IHdvdWxk IGlmIGl0ICdjb3VsZCcuPGJyPg0KLSBXZSBzaG91bGQgcmVzZXJ2ZSBOb0JpbmRpbmcgdG8gdHJp Z2dlciB0aGUgY2xpZW50IHRvIGdvIGJhY2sgdG8gU29saWNpdC8uLi4gb3IgUmVxdWVzdC4gVGhl cmVmb3JlLCB0aGlzIHNob3VsZCBvbmx5IGJlIHVzZWQgaW4gY29uZGl0aW9ucyB3aGVyZSB0aGUg c2VydmVyIHdhbnRzIChuZWVkcykgdGhlIGNsaWVudCB0byBkbyB0aGF0Ljxicj4NCjxicj4NCklm IHdvdWxkIGJlIG5pY2UgaWYgdGhlIHN0YXR1cyBjb2RlcyAob3IgZW1wdHkgb3IgbWlzc2luZyBJ QSkgaGFkIGNvbnNpc3RlbnQgbWVhbmluZ3MgZm9yICdhbGwnIG1lc3NhZ2VzIGFuZCB0aHVzIHRy aWdnZXJlZCBjb25zaXN0ZW50IGNsaWVudCBhY3Rpb25zLjxicj4NCjxicj4NClB1dHRpbmcgTm9B ZGRyc0F2YWlsIGludG8gdGhlIElBIGNhcnJpZWQgaW4gdGhlIFJlcGx5IHRvIFJlbmV3L1JlYmlu ZCBzaG91bGRuJ3QgY2F1c2UgcHJvYmxlbXMgaW4gdGhlIGNsaWVudHMgdGhhdCByZWFsbHkgZm9s bG93IHRoZSBjdXJyZW50IFJGQzMzMTUgYXMgaW4gdGhlIHNlY3Rpb24gMTguMS44IGl0IGNsZWFy bHkgc3BlY2lmaWVzIHdoYXQgdG8gZG8gd2l0aCBJQXMgdGhhdCBjb250YWluIE5vQWRkcnNBdmFp bCBpbiB0aGUgUmVwbHkgbWVzc2FnZQ0KICZuYnNwO2FuZCBpdCBkb2Vzbid0IGRpZmZlcmVudGlh dGUgYmV0d2VlbiB0aGUgdHlwZXMgb2YgbWVzc2FnZXMgaW4gcmVzcG9uc2UgdG8gd2hpY2ggdGhl IFJlcGx5IGhhcyBiZWVuIHJlY2VpdmVkLiBUaGUgZm9sbG93aW5nIHBhcmFncmFwaDo8YnI+DQo8 YnI+DQomcXVvdDtXaGVuIHRoZSBjbGllbnQgcmVjZWl2ZXMgYSBSZXBseSBtZXNzYWdlIGluIHJl c3BvbnNlIHRvIGEgUmVuZXcgb3I8YnI+DQombmJzcDsgJm5ic3A7UmViaW5kIG1lc3NhZ2UsIHRo ZSBjbGllbnQgZXhhbWluZXMgZWFjaCBJQSBpbmRlcGVuZGVudGx5LiAmbmJzcDtGb3IgZWFjaDxi cj4NCiZuYnNwOyAmbmJzcDtJQSBpbiB0aGUgb3JpZ2luYWwgUmVuZXcgb3IgUmViaW5kIG1lc3Nh Z2UsIHRoZSBjbGllbnQ6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOy0gJm5ic3A7c2VuZHMgYSBS ZXF1ZXN0IG1lc3NhZ2UgaWYgdGhlIElBIGNvbnRhaW5lZCBhIFN0YXR1cyBDb2RlIG9wdGlvbjxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IHdpdGggdGhlIE5vQmluZGluZyBzdGF0dXMgKGFuZCBk b2VzIG5vdCBzZW5kIGFueSBhZGRpdGlvbmFsPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgUmVu ZXcvUmViaW5kIG1lc3NhZ2VzKTxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDstICZuYnNwO3NlbmRz IGEgUmVuZXcvUmViaW5kIGlmIHRoZSBJQSBpcyBub3QgaW4gdGhlIFJlcGx5IG1lc3NhZ2U8YnI+ DQo8YnI+DQombmJzcDsgJm5ic3A7LSAmbmJzcDtvdGhlcndpc2UgYWNjZXB0cyB0aGUgaW5mb3Jt YXRpb24gaW4gdGhlIElBICZxdW90Ozxicj4NCm1heSBiZSBhIHNvdXJjZSBvZiB0cm91YmxlIGZv ciBjbGllbnRzIHdoaWNoIGltcGxlbWVudGVycyBpZ25vcmVkIHRoZSBwcmVjZWRpbmcgcGFyYWdy YXBoIGFuZCBzaW1wbHkgbWFkZSBhbiBhc3N1bXB0aW9uIHRoYXQgTm9BZGRyc0F2YWlsIGlzIG5v dCByZXR1cm5lZCBmb3IgUmVuZXcvUmViaW5kLiBPbiB0aGUgb3RoZXIgaGFuZCB0aGUgY2xpZW50 IHNob3VsZG4ndCBmYWxsIG92ZXIganVzdCBiZWNhdXNlIGl0IGdldHMgdGhlIHVuZXhwZWN0ZWQN CiBzdGF0dXMgY29kZS48YnI+DQo8YnI+DQpTbyBpbiBwcmluY2lwbGUgaXQgc2VlbXMgdG8gYmUg ZmluZSB0byB1c2UgTm9BZGRyc0F2YWlsL05vUHJlZml4QXZhaWwgaW4gdGhlIFJlcGx5IG1lc3Nh Z2VzIHNlbnQgYXMgYSByZXNwb25zZSB0byBSZW5ldy9SZWJpbmQuPGJyPg0KPGJyPg0KPGJyPg0K QW55d2F5LCBnaXZlIHRoZSBjdXJyZW50IGRyYWZ0IGEgcmVhZCBhbmQgaWYgdGhlcmUgYXJlIGNv bmNlcm5zIG9yIHF1ZXN0aW9ucyAob3IgeW91IGhhdmUgYSB2aWV3IG9uIHRoZSBpc3N1ZSksIHBs ZWFzZSBzZW5kIG1haWwgdG8gdGhlIGxpc3QgQVNBUC48YnI+DQo8c3BhbiBzdHlsZT0iY29sb3I6 Izg4ODg4OCI+PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+LSBCZXJuaWU8L3NwYW4+PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+ DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IGRoY3dnIFttYWlsdG86PGEg aHJlZj0ibWFpbHRvOmRoY3dnLWJvdW5jZXNAaWV0Zi5vcmciPmRoY3dnLWJvdW5jZXNAaWV0Zi5v cmc8L2E+XSBPbiBCZWhhbGYgT2YNCjxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmciPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT48YnI+DQpTZW50OiBNb25kYXksIEp1 bmUgMzAsIDIwMTQgMTI6MzQgUE08YnI+DQpUbzogPGEgaHJlZj0ibWFpbHRvOmktZC1hbm5vdW5j ZUBpZXRmLm9yZyI+aS1kLWFubm91bmNlQGlldGYub3JnPC9hPjxicj4NCkNjOiA8YSBocmVmPSJt YWlsdG86ZGhjd2dAaWV0Zi5vcmciPmRoY3dnQGlldGYub3JnPC9hPjxicj4NClN1YmplY3Q6IFtk aGN3Z10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1kaGMtZGhjcHY2LXN0YXRlZnVsLWlzc3Vlcy0w Ni50eHQ8YnI+DQo8YnI+DQo8YnI+DQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUg ZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuPGJyPg0KJm5ic3A7 VGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgRHluYW1pYyBIb3N0IENvbmZpZ3VyYXRp b24gV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgVGl0bGUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IElz c3VlcyB3aXRoIG11bHRpcGxlIHN0YXRlZnVsIERIQ1B2NiBvcHRpb25zPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IEF1dGhvcnMgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDog T2xlIFRyb2FuPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEJlcm5pZSBW b2x6PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IE1hcmNpbiBTaW9kZWxz a2k8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgRmlsZW5hbWUgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7OiBkcmFmdC1pZXRmLWRoYy1kaGNwdjYtc3RhdGVmdWwtaXNzdWVzLTA2 LnR4dDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBQYWdlcyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogMjA8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgRGF0ZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogMjAxNC0w Ni0zMDxicj4NCjxicj4NCkFic3RyYWN0Ojxicj4NCiZuYnNwOyAmbmJzcDtEeW5hbWljIEhvc3Qg Q29uZmlndXJhdGlvbiBQcm90b2NvbCBmb3IgSVB2NiAoREhDUHY2KSB3YXMgbm90IHdyaXR0ZW48 YnI+DQombmJzcDsgJm5ic3A7d2l0aCB0aGUgZXhwZWN0YXRpb24gdGhhdCBhZGRpdGlvbmFsIHN0 YXRlZnVsIERIQ1B2NiBvcHRpb25zIHdvdWxkIGJlPGJyPg0KJm5ic3A7ICZuYnNwO2RldmVsb3Bl ZC4gJm5ic3A7SVB2NiBQcmVmaXggT3B0aW9ucyBmb3IgRHluYW1pYyBIb3N0IENvbmZpZ3VyYXRp b248YnI+DQombmJzcDsgJm5ic3A7UHJvdG9jb2wgKERIQ1ApIHZlcnNpb24gNiBzaG9lLWhvcm5l ZCB0aGUgbmV3IG9wdGlvbnMgZm9yIFByZWZpeDxicj4NCiZuYnNwOyAmbmJzcDtEZWxlZ2F0aW9u IGludG8gREhDUHY2LiAmbmJzcDtJbXBsZW1lbnRhdGlvbiBleHBlcmllbmNlIG9mIHRoZSBDUEUg bW9kZWw8YnI+DQombmJzcDsgJm5ic3A7ZGVzY3JpYmVkIGluIFJGQyA3MDg0IGhhcyBzaG93biBt dWx0aXBsZSBpc3N1ZXMgd2l0aCB0aGUgREhDUHY2PGJyPg0KJm5ic3A7ICZuYnNwO3Byb3RvY29s IGluIHN1cHBvcnRpbmcgbXVsdGlwbGUgc3RhdGVmdWwgb3B0aW9ucy4gJm5ic3A7VGhpcyBkb2N1 bWVudDxicj4NCiZuYnNwOyAmbmJzcDt1cGRhdGVzIFJGQyAzMzE1IGFuZCBSRkMgMzYzMy48YnI+ DQo8YnI+DQo8YnI+DQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBk cmFmdCBpczo8YnI+DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLWRoYy1kaGNwdjYtc3RhdGVmdWwtaXNzdWVzLyIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZGhjLWRoY3B2Ni1zdGF0 ZWZ1bC1pc3N1ZXMvPC9hPjxicj4NCjxicj4NClRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNp b24gYXZhaWxhYmxlIGF0Ojxicj4NCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtZGhjLWRoY3B2Ni1zdGF0ZWZ1bC1pc3N1ZXMtMDYiIHRhcmdldD0iX2JsYW5r Ij5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRoYy1kaGNwdjYtc3RhdGVm dWwtaXNzdWVzLTA2PC9hPjxicj4NCjxicj4NCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJz aW9uIGlzIGF2YWlsYWJsZSBhdDo8YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC1pZXRmLWRoYy1kaGNwdjYtc3RhdGVmdWwtaXNzdWVzLTA2IiB0YXJn ZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1k aGMtZGhjcHY2LXN0YXRlZnVsLWlzc3Vlcy0wNjwvYT48YnI+DQo8YnI+DQo8YnI+DQpQbGVhc2Ug bm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBv ZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFp bGFibGUgYXQNCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PnRvb2xzLmlldGYub3JnPC9hPi48YnI+DQo8YnI+DQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28g YXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6PGJyPg0KPGEgaHJlZj0iZnRwOi8vZnRwLmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy8iIHRhcmdldD0iX2JsYW5rIj5mdHA6Ly9mdHAuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzLzwvYT48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmRoY3dnIG1haWxpbmcgbGlzdDxicj4NCjxh IGhyZWY9Im1haWx0bzpkaGN3Z0BpZXRmLm9yZyI+ZGhjd2dAaWV0Zi5vcmc8L2E+PGJyPg0KPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaGN3ZyIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2c8L2E+ PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpkaGN3ZyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86ZGhjd2dAaWV0 Zi5vcmciPmRoY3dnQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2ciIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dnPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_489D13FBFA9B3E41812EA89F188F018E1B5F6A45xmbrcdx04ciscoc_-- From nobody Mon Jul 14 11:06:20 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54E601A0011 for ; Mon, 14 Jul 2014 11:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbCpQ8h5X6ou for ; Mon, 14 Jul 2014 11:06:05 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B1FE1A000F for ; Mon, 14 Jul 2014 11:06:05 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id q58so1066906wes.35 for ; Mon, 14 Jul 2014 11:06:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=T6xu2emvZE/8GtHsWvbOsabZ+lxra9ut9hWuabfFyZI=; b=glp4vw1ECK4DBezTd7CDzB3B2kvnjsC1Q40qUF05G1u+pjh+TDDD0nloyZCw+ywlwO zRz0UaalUlwcg+9IblCj1lJglcMZ/awFUYfX9z0+w7O/VbMJ13VZZ+hD3uvIDYE3nQ2r LFxaD9gwwEziWv52seCxWt2iX3a26mMAajepqzHgNDiJHtR/6/B70gZ5zAcxe9ZKrMbn ItqOSBzU0rotIbjehdwIaamMBukPtjA/LO8YEW1HHGf9Jf6zU16ypypM+bq2ycf6cL28 4vHc/fwdKYf1bP34BvbXvWMQ/dgJwCCU1P2YGHB8lJ9MRN5GxYzKPZ2iziJrhXJRyOzS FwoQ== MIME-Version: 1.0 X-Received: by 10.194.133.1 with SMTP id oy1mr21006308wjb.87.1405361163914; Mon, 14 Jul 2014 11:06:03 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.108.166 with HTTP; Mon, 14 Jul 2014 11:06:03 -0700 (PDT) In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1B5F6A45@xmb-rcd-x04.cisco.com> References: <20140630163351.4191.69719.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E1B5E03D1@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1B5F6A45@xmb-rcd-x04.cisco.com> Date: Mon, 14 Jul 2014 11:06:03 -0700 X-Google-Sender-Auth: ROvbIL9NNwrhfa-gJhVVyO5oSWY Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: "Bernie Volz (volz)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/KYULSy-k5HNY88jZhFM6ZqzOvtA Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.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, 14 Jul 2014 18:06:11 -0000 At Mon, 14 Jul 2014 13:02:54 +0000, "Bernie Volz (volz)" wrote: > This is =E2=80=9Cshould=E2=80=9D. That allows for cases where a client ma= y want to use multiple sessions to different servers. This might well be th= e case if multiple provisioning domains were in play =E2=80=93 see section = 4.8. But this is an area of potential future work =E2=80=A6 My understanding of the question is that it's more related to the undocumented operational assumption I raised in a prior comment: http://www.ietf.org/mail-archive/web/dhcwg/current/msg15657.html >> - Similarly, it seems to be assumed that when a server could provide >> bindings for IA1 and IA2: >> + the server can provide bindings for both IA1 and IA2, or, >> + it can provide a binding for neither IA1 nor IA2. If my understanding is correct, what I think should be done for this document is: - get a consensus on the validity of this assumption. (Personally, I think it's reasonable for the case of IA_NA + IA_PD; I'm not so sure about the general IA1 and IA2) - assuming we have the consensus, explicitly clarify the operational assumption on which this document is based, and also clarify what's excluded from the scope of considerations. Perhaps the assumption was so obvious to the authors, but the fact we have this discussion now would suggest that it's not that trivial to others and worth documenting explicitly. -- JINMEI, Tatuya From nobody Tue Jul 15 11:52:06 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA2B71B28B2 for ; Tue, 15 Jul 2014 11:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, 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 QgmTlFx79l1p for ; Tue, 15 Jul 2014 11:52:03 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 616991A0AC0 for ; Tue, 15 Jul 2014 11:52:03 -0700 (PDT) Received: by mail-ob0-f170.google.com with SMTP id wp4so4300378obc.29 for ; Tue, 15 Jul 2014 11:52:01 -0700 (PDT) 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=xyR8fE4/CJSq2gQRaJunBKxrh60/GKerj4LjxqQx4aU=; b=haNF0LigdrjFeBnh+AyJelgoUwdgy+9Y4/uBwzmKocdBNwqnqKjnCNspj7AKcazMKE RRa//lzbynljRGY+9/Kh+el17ac3LLd1+wIWmn1Pt/aeHeoMFrHLQ0RUYhQmv31CeeoT In9ToA59oT7l2No99n/y5KgV+o32TdYpPkwG59OoVVJwY/FXpcGof1StIThpQgk4CGJ7 PpXulfqrOi0Nn2dKIqBSss8pk5aZJMwZ57kXK/e+C2ZC/ewHqGQQYEWpRnnK2JnhxZ2E Blazy9VCesHpZ3f1mf0IhkWAjDMpmCj18OGNbUlHiE1HDEXud3Xqi1UER6GBzw+e8eb9 0+2Q== X-Received: by 10.60.15.37 with SMTP id u5mr26849230oec.12.1405450321324; Tue, 15 Jul 2014 11:52:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.85.210 with HTTP; Tue, 15 Jul 2014 11:51:41 -0700 (PDT) In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1B5F6A45@xmb-rcd-x04.cisco.com> References: <20140630163351.4191.69719.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E1B5E03D1@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1B5F6A45@xmb-rcd-x04.cisco.com> From: Cong Liu Date: Wed, 16 Jul 2014 02:51:41 +0800 Message-ID: To: "Bernie Volz (volz)" Content-Type: multipart/alternative; boundary=089e013cbd82271a7a04fe3fe7b8 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/aRpWCndKUdisucT2SZvtvLias_k Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.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, 15 Jul 2014 18:52:05 -0000 --089e013cbd82271a7a04fe3fe7b8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Bernie, 2014-07-14 21:02 GMT+08:00 Bernie Volz (volz) : > Hi: > > > > This is =E2=80=9Cshould=E2=80=9D. That allows for cases where a client ma= y want to use > multiple sessions to different servers. This might well be the case if > multiple provisioning domains were in play =E2=80=93 see section 4.8. But= this is > an area of potential future work =E2=80=A6 > > > If a client decides to start multiple sessions, why would it then combine > the two separate sessions? I think it should keep the transactions > completely separate (even when reaching the Rebind =E2=80=98state=E2=80= =99). > Agree. > If it doesn=E2=80=99t keep things separate, it could very well end up wit= h > conflicting answers =E2=80=93 it all depends on what each server knows ab= out what > the other has and how it responds (respond with =E2=80=9CNoBinding=E2=80= =9D, respond with 0 > lifetimes, respond with =E2=80=9CNotOnLink=E2=80=9D, =E2=80=A6). > > > > We do NOT cover this since we do NOT expect clients will generally want t= o > do this. But there is nothing that prohibits this based on RFC 3315 and > this draft. > > > > I don=E2=80=99t know if you are suggesting any changes to the text, if so= , please > provide those suggestions. > I didn't pay much attention to section 4.8 and it solves my question. I think it would be better to move section 4.8 before the IA-related discussions in section 4, to clarify the scope and assumptions clearer as Jinmei suggested. Best Regards, Cong --089e013cbd82271a7a04fe3fe7b8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Bernie,

2014-07-14 21:02 GMT+08:00 Bernie Volz (volz) &= lt;volz@cisco.com&g= t;:

Hi:

=C2=A0

This is =E2=80=9Cshould=E2=80=9D. That allow= s for cases where a client may want to use multiple sessions to different s= ervers. This might well be the case if multiple provisioning domains were in play =E2=80=93 see section 4.8. But this is an =C2=A0area = of potential future work =E2=80=A6=C2=A0

=C2=A0

If a client decides to start multiple sessio= ns, why would it then combine the two separate sessions? I think it should = keep the transactions completely separate (even when reaching the Rebind =E2=80=98state=E2=80=99).

=
Agree.=C2=A0

If it doesn=E2=80=99t keep things separate, it could very well = end up with conflicting answers =E2=80=93 it all depends on what each serve= r knows about what the other has and how it responds (respond with =E2=80= =9CNoBinding=E2=80=9D, respond with 0 lifetimes, respond with =E2=80=9CNotOnLink=E2=80=9D, =E2=80=A6).<= u>

=C2=A0

We do NOT cover this since we do NOT expect = clients will generally want to do this. But there is nothing that prohibits= this based on RFC 3315 and this draft.

=C2=A0

I don=E2=80=99t know if you are suggesting a= ny changes to the text, if so, please provide those suggestions.

=
I didn't pay much attention to section 4.8 and it sol= ves my question. I think it would be better to move section 4.8 before the= =C2=A0IA-related discussions= in section 4, to=C2= =A0clarify=C2=A0the scope and=C2=A0assumptions=C2=A0clearer as Jinmei suggested.

<= span style=3D"color:rgb(0,0,0);font-size:1em">Best Regards,
Cong
--089e013cbd82271a7a04fe3fe7b8-- From nobody Wed Jul 16 16:11:18 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BAA41A03A2 for ; Wed, 16 Jul 2014 16:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 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.651, 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 sMy0p6trAeXH for ; Wed, 16 Jul 2014 16:11:05 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 745781A039F for ; Wed, 16 Jul 2014 16:11:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6057; q=dns/txt; s=iport; t=1405552265; x=1406761865; h=from:to:subject:date:message-id:mime-version; bh=9GXpB34pijDEBU6nU++CipCi1N+3Mcu1Epr6ep7Ah8U=; b=WCi/PJMINDgzROvEZaEws64WxfgIejvHc3svPHHgxlkpdN1zAdPI4rao KLuBlWAgC/YAzaH2aH8cOngcYI2chDTc6hAv/oHfnWVJ7zJZJNndB2l6P Fw5PgENI/Ufzv8CRqTWaw7qo+qwoKhXjpXzQBWlV7o6I7vs80eJ2zs4aT M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAFIGx1OtJA2F/2dsb2JhbABZgkdHUlcEwzSHQgGBCxZ2hAUBBC1eASpWFBIBBBMIAYg5DaNNpnsXjByCfoNlgRYFr0mDRGyBRQ X-IronPort-AV: E=Sophos; i="5.01,674,1400025600"; d="scan'208,217"; a="61462847" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-5.cisco.com with ESMTP; 16 Jul 2014 23:11:03 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s6GNB3m5026135 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 16 Jul 2014 23:11:03 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.176]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Wed, 16 Jul 2014 18:11:03 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: Toronto (IETF-90, July 20-25) - DHC WG Session Agenda / Slides Requested Thread-Index: Ac+hSzXgG8DtmukqTHOxNdl93Oc2qQ== Date: Wed, 16 Jul 2014 23:11:02 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1B5FFF92@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.244.161] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1B5FFF92xmbrcdx04ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/hEgNLxUGFqjVXREajJBVt_nPK_M Subject: [dhcwg] Toronto (IETF-90, July 20-25) - DHC WG Session Agenda / Slides Requested 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, 16 Jul 2014 23:11:12 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E1B5FFF92xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi: The current agenda is at http://www.ietf.org/proceedings/90/agenda/agenda-9= 0-dhc. Please get in touch with the chairs if you thought you requested ti= me but we missed it or if you see other issues. Also, please send your presentation slides so that they can be uploaded (se= nd to dhc-chairs@tools.ietf.org). Thanks and see you in Toronto! - Tomek & Bernie --_000_489D13FBFA9B3E41812EA89F188F018E1B5FFF92xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi:

 

The current agenda is at http://www.ietf.org/proceedings/90/agenda/agenda-90-dhc.  Please g= et in touch with the chairs if you thought you requested time but we missed= it or if you see other issues.

 

Also, please send your presentation slides so that t= hey can be uploaded (send to dhc-chairs@tools.ietf.org).

 

Thanks and see you in Toronto!

 

-       = ;   Tomek & Bernie

--_000_489D13FBFA9B3E41812EA89F188F018E1B5FFF92xmbrcdx04ciscoc_-- From nobody Sat Jul 19 13:27:56 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 744F61B2988; Sat, 19 Jul 2014 13:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] 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 j8HVnHcOats3; Sat, 19 Jul 2014 13:27:46 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B980B1B27B5; Sat, 19 Jul 2014 13:27:46 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id CF2EB2002B; Sat, 19 Jul 2014 16:29:13 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 015AF63B0E; Sat, 19 Jul 2014 16:27:44 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id DF2C563AED; Sat, 19 Jul 2014 16:27:44 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: <20140701155803.14047.81610.idtracker@ietfa.amsl.com> <53BA92D9.3000606@toshiba.co.jp> <53BBA3EF.9040609@toshiba.co.jp> <43CF020C-1007-40A9-8F58-0B4F64672736@nominum.com> <3C9237BF-BF7F-43BF-8A12-35CB9BE6E7F1@gmail.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/tJIngr0_FapOHRNhjt7wTLg1FOY Cc: "dhcwg@ietf.org" , Ralph Droms , Ted Lemon Subject: Re: [dhcwg] [Roll] MPL config draft (Re: I-D Action: draft-ietf-roll-mpl-parameter-configuration-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: Sat, 19 Jul 2014 20:27:51 -0000 --=-=-= Ted Lemon wrote: >> Ted - what does "this" refer to? MPL in general? > Using DHCP to push a big chunk of information about the state of a mesh > network seems like a suboptimal approach. The fact that compression is > desired suggests that you are using the wrong tool for the job. It's not state about the network, it's configuration parameters about the (multicast) routing protocol. Ideally, the parameters need to be the same across the mesh (but we have validated that mismatches in certain directions and within certain tolerances are acceptable; usually causing excess energy use, rather than network in-operation), but over time the operator will want to tune the parameters to optimize energy. As such we need a protocol that assigns lifetimes to parameters and facilitates expiring old values. DHCP seems ideal for this; it's also not RPL specific, as MPL is not tied to RPL. -- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU8rUvoCLcPvd0N1lAQIjKwgAwRjNXEvxE0tbsHjxJLmakv1uYgs5TUud Qqxm8SNPUatC7jGhXiUDY7uwLFBK7ewMEcVXy6KQ1SUnP15Y55g0AxuM5GvvSjes YsT0wITrVrIdSWvJ1wCUJJt/ImGx88klYW7kVqonaqBvv3cWQt/MX78qzOJgakXg XMD7QzCA1xO/c7LftXM7qU+ReQoF0F8gYNei+itIg8lrTzwUO8hIdqeZGzieO5/i Ag+hT7O6BGyg2uLf1iLSAk8VnS8GqpUdx/pRmUWiDjuCpDSAwr4mxXwRI7fJjvbL p4MHepritDi+VYBMQjFhLKwaInbKrcfz/T9rcAnE8IghmniHCDBE3Q== =SezO -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Jul 19 14:21:01 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 390C41B2A13; Sat, 19 Jul 2014 14:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHT_jx9nGijK; Sat, 19 Jul 2014 14:20:53 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF8A91B2A0A; Sat, 19 Jul 2014 14:20:53 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 4A516F804A; Sat, 19 Jul 2014 14:20:53 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id EAA76190060; Sat, 19 Jul 2014 14:20:52 -0700 (PDT) Received: from [192.168.0.10] (99.232.25.196) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 19 Jul 2014 14:20:47 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <7303.1405801664@sandelman.ca> Date: Sat, 19 Jul 2014 17:20:44 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20140701155803.14047.81610.idtracker@ietfa.amsl.com> <53BA92D9.3000606@toshiba.co.jp> <53BBA3EF.9040609@toshiba.co.jp> <43CF020C-1007-40A9-8F58-0B4F64672736@nominum.com> <3C9237BF-BF7F-43BF-8A12-35CB9BE6E7F1@gmail.com> <7303.1405801664@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [99.232.25.196] Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/XT9w1PX41ADZESUfreWgP5ZuhZ0 Cc: "dhcwg@ietf.org" , Routing Over Low power and Lossy networks , Ralph Droms Subject: Re: [dhcwg] [Roll] MPL config draft (Re: I-D Action: draft-ietf-roll-mpl-parameter-configuration-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: Sat, 19 Jul 2014 21:20:58 -0000 Okay, thanks. I think compressing is saving three bytes; this is = noise. Please don't do that. We need to define a fragment type for = unsigned short floating point; that should be a quick, simple DHCP = document. The rest of the document looks fine at first glance, but as = you've no doubt detected, I didn't read it before asking about the = previous thing and I still haven't read it closely, so don't take that = as a claim that I won't comment further later when I have more time = (whenever that magic day comes). From nobody Sun Jul 20 12:19:28 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF611B29B0; Sun, 20 Jul 2014 12:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNILaO7AB1Sh; Sun, 20 Jul 2014 12:19:24 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 472DF1B2CF8; Sun, 20 Jul 2014 12:19:24 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id u56so6587583wes.14 for ; Sun, 20 Jul 2014 12:19:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Ur8UabHdFtHWfRr2EAuufwxpOwMs15nxelxQRC94Bzk=; b=Pz9vLB5hZ4hf5wX6SycXp3Pz5RSWEfDOVFtGIfeU/2pn2ax2TcOYXGy+WfXmiMusgt prtjlxzvZNzQkS/luv4ITmY/m7Nkcp92ekfA8we8JJipr6Se8SrEkbDICx0/UHElhXpV RKs9RASMQULUlcJsQ8ROEMVEIUFFRqhFtu5gKV/0kfV6U5U/f33gje8rSWZuEYKQL/sR nzmD3LInrn9BZMx24VWg0fqO8c4t2xOT9kLtRMPtu3hOw0QwqB8wG+UmbcvanlUlNtnD qjcBl7xi35iPnvDITUiE449DfOwdGLV0vZvrk3bRkrmE5marAoegVevFmsYjwCdowXMo b4cA== X-Received: by 10.180.210.167 with SMTP id mv7mr45392264wic.72.1405883962857; Sun, 20 Jul 2014 12:19:22 -0700 (PDT) Received: from dhcp-a568.meeting.ietf.org (dhcp-a568.meeting.ietf.org. [31.133.165.104]) by mx.google.com with ESMTPSA id je17sm23525104wic.22.2014.07.20.12.19.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 20 Jul 2014 12:19:22 -0700 (PDT) Message-ID: <53CC1637.3010801@gmail.com> Date: Sun, 20 Jul 2014 15:19:19 -0400 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dhcpv6bis@ietf.org, dhcwg@ietf.org References: <53BC4F20.5060905@gmail.com> <53CBDEF0.9060000@gmail.com> In-Reply-To: <53CBDEF0.9060000@gmail.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/Wp7Zaa0FQjJ6fMXkz-3QEVYcFHc Subject: [dhcwg] DHCPv6bis meeting in Toronto (July 21st, 13:00-15:00) 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, 20 Jul 2014 19:19:27 -0000 The DHCPv6bis team will meet there and discuss outstanding issues from the tracker. Date: Mon, 2014-07-21 13:00-15:00 Room: Confederation 3 Proposed agenda 1. Agenda bashing 2. How to organize the bis document (#100, #102) 3. How to best express that DHCPv6 should not be directly used for IPv4 configuration (#115) 4. Do we want to include changes (what has changed?) from RFC6221 that updates 3315 (#116) 5. What to do with bakeoff tickets (#69, #72, #73, #74, #75, #76, #78, #79, #80, #81, #82, #68, #70, #71)? 6. Key rollover clarification? 7. Any follow ups for #117 (Tomek will ask Ted for guidance first) 8. Schedule for addressing non-blocked tickets (some tickets are blocked by other processes, mostly stateful-issues), milestones update 9. Target adoption date? 10. Any other business Just a reminder, the link to the issue tracker: http://wiki.tools.ietf.org/group/dhcpv6bis/ See you tomorrow, Bernie and Tomek From nobody Sun Jul 20 12:24:31 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 364F61B29BD; Sun, 20 Jul 2014 12:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.393 X-Spam-Level: X-Spam-Status: No, score=-4.393 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 QLD1_ts4OHKO; Sun, 20 Jul 2014 12:24:24 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 389381B29BE; Sun, 20 Jul 2014 12:24:24 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id s6KJOMKM019501; Mon, 21 Jul 2014 04:24:22 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id s6KJOMr6012759; Mon, 21 Jul 2014 04:24:22 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id EAA12758; Mon, 21 Jul 2014 04:24:22 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id s6KJOMYl002294; Mon, 21 Jul 2014 04:24:22 +0900 (JST) Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id s6KJOMJ5001756; Mon, 21 Jul 2014 04:24:22 +0900 (JST) Received: from [133.199.16.43] (ivpn-1-43.mobile.toshiba.co.jp [133.199.16.43]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id 4FA4C97D10; Mon, 21 Jul 2014 04:24:21 +0900 (JST) Message-ID: <53CC1763.3010309@toshiba.co.jp> Date: Mon, 21 Jul 2014 04:24:19 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Routing Over Low power and Lossy networks , Michael Richardson References: <20140701155803.14047.81610.idtracker@ietfa.amsl.com> <53BA92D9.3000606@toshiba.co.jp> <53BBA3EF.9040609@toshiba.co.jp> <43CF020C-1007-40A9-8F58-0B4F64672736@nominum.com> <3C9237BF-BF7F-43BF-8A12-35CB9BE6E7F1@gmail.com> <7303.1405801664@sandelman.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/6JWnxKiRaWhzMluuPIucMTzPP9M Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] [Roll] MPL config draft (Re: I-D Action: draft-ietf-roll-mpl-parameter-configuration-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: Sun, 20 Jul 2014 19:24:27 -0000 Hi Ted, Thanks for your suggestion. As I wrote to Bernie, I'll update the draft with standard data types. Regards, Yusuke (2014-07-20 6:20), Ted Lemon wrote: > Okay, thanks. I think compressing is saving three bytes; this is noise. Please don't do that. We need to define a fragment type for unsigned short floating point; that should be a quick, simple DHCP document. The rest of the document looks fine at first glance, but as you've no doubt detected, I didn't read it before asking about the previous thing and I still haven't read it closely, so don't take that as a claim that I won't comment further later when I have more time (whenever that magic day comes). > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From nobody Sun Jul 20 13:43:26 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB221B2806; Sun, 20 Jul 2014 13:43:23 -0700 (PDT) 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 Ce5HCkwbUKBD; Sun, 20 Jul 2014 13:43:22 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AA421A0B05; Sun, 20 Jul 2014 13:43:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1366; q=dns/txt; s=iport; t=1405889003; x=1407098603; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=fs9ay7fAy6P68ad5f9PW/JuotIO57DBqT2ModWB5WYU=; b=SHuC2S6JX5abCeeMMYXo7YHAgITDtoWcSIzrq5KH7OFbaoZ4YuKlHCT+ Z3rXTtWPs3otGCLvTAnSfpvI5jOoxhY3EqeXugTRff1YcRr3KNcgWp38Q 4TCNO5/CibbLb+lJbsu2qBCQvr1Nm+g6fyTT7sfJa86sv4fC2pzefqgFN 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAHMpzFOtJA2D/2dsb2JhbABZgw5SxW0KhnFTAYEGFnaEAwEBAQMBAQEBNzQLBQsCAQgOBgQeECEGCyUCBA4FiC4DCQgNuHoNhyMXjByBAoFoEjMHgy6BGAWFcohRil+CA4FNjB0phhyDRGwB X-IronPort-AV: E=Sophos;i="5.01,697,1400025600"; d="scan'208";a="341492536" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-3.cisco.com with ESMTP; 20 Jul 2014 20:43:22 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6KKhL7D016160 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 20 Jul 2014 20:43:21 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.176]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Sun, 20 Jul 2014 15:43:21 -0500 From: "Bernie Volz (volz)" To: Tomek Mrugalski Thread-Topic: [Dhcpv6bis] DHCPv6bis meeting in Toronto (July 21st, 15:00-17:00) Thread-Index: AQHPpFs+w1VTrLIVgESGtVX+VLw3ow== Date: Sun, 20 Jul 2014 20:43:21 +0000 Message-ID: References: <53BC4F20.5060905@gmail.com> <53CBDEF0.9060000@gmail.com>,<53CC1637.3010801@gmail.com> In-Reply-To: <53CC1637.3010801@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/2y_l7ekHFaK7BWEM7iXSo-W1yMw Cc: "dhcwg@ietf.org" , "dhcpv6bis@ietf.org" Subject: Re: [dhcwg] [Dhcpv6bis] DHCPv6bis meeting in Toronto (July 21st, 15:00-17:00) 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, 20 Jul 2014 20:43:24 -0000 Time is actually 1500-1700 (3 to 5 pm). Sorry for the confusion. - Bernie & Tomek > On Jul 20, 2014, at 3:19 PM, "Tomek Mrugalski" wrote: >=20 > The DHCPv6bis team will meet there and discuss outstanding issues from > the tracker. >=20 > Date: Mon, 2014-07-21 13:00-15:00 > Room: Confederation 3 >=20 > Proposed agenda > 1. Agenda bashing > 2. How to organize the bis document (#100, #102) > 3. How to best express that DHCPv6 should not be directly used for > IPv4 configuration (#115) > 4. Do we want to include changes (what has changed?) from RFC6221 that > updates 3315 (#116) > 5. What to do with bakeoff tickets (#69, #72, #73, #74, #75, #76, #78, > #79, #80, #81, #82, #68, #70, #71)? > 6. Key rollover clarification? > 7. Any follow ups for #117 (Tomek will ask Ted for guidance first) > 8. Schedule for addressing non-blocked tickets (some tickets are > blocked by other processes, mostly stateful-issues), milestones > update > 9. Target adoption date? > 10. Any other business >=20 > Just a reminder, the link to the issue tracker: > http://wiki.tools.ietf.org/group/dhcpv6bis/ >=20 > See you tomorrow, > Bernie and Tomek >=20 > _______________________________________________ > Dhcpv6bis mailing list > Dhcpv6bis@ietf.org > https://www.ietf.org/mailman/listinfo/dhcpv6bis From nobody Sun Jul 20 20:09:10 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F365A1B2B24; Sun, 20 Jul 2014 20:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPr4vT-jvGrS; Sun, 20 Jul 2014 20:09:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C69721B2ACD; Sun, 20 Jul 2014 20:09:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140721030905.25016.17626.idtracker@ietfa.amsl.com> Date: Sun, 20 Jul 2014 20:09:05 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/TaYpePJLRymina94Y85H0BXKoEc Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-addr-registration-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: Mon, 21 Jul 2014 03:09:07 -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 : Registering Self-generated IPv6 Addresses in DNS using DHCPv6 Authors : Sheng Jiang Gang Chen Suresh Krishnan Rajiv Asati Filename : draft-ietf-dhc-addr-registration-06.txt Pages : 9 Date : 2014-07-20 Abstract: In networks that are centrally managed, self-generated addresses cause some traceability issues due to their decentralized nature. One of the most important issues in this regard is the inability to register such addresses in DNS. This document defines a mechanism to register self-generated and statically configured addresses in DNS through a DHCPv6 server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-addr-registration/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-addr-registration-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 Mon Jul 21 03:48:48 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B76E51B2B8E; Mon, 21 Jul 2014 03:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.693 X-Spam-Level: X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 oLu5o43mlgCF; Mon, 21 Jul 2014 03:48:44 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A77AA1B2D4C; Mon, 21 Jul 2014 03:48:43 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id s6LAmeoU018789; Mon, 21 Jul 2014 19:48:40 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id s6LAmeLd020015; Mon, 21 Jul 2014 19:48:40 +0900 (JST) Received: from ovp2.toshiba.co.jp [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id VAA20014; Mon, 21 Jul 2014 19:48:40 +0900 Received: from mx11.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id s6LAmeC7020114; Mon, 21 Jul 2014 19:48:40 +0900 (JST) Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id s6LAmenw008201; Mon, 21 Jul 2014 19:48:40 +0900 (JST) Received: from [133.199.17.23] (ivpn-2-23.mobile.toshiba.co.jp [133.199.17.23]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id C0C6597CF0; Mon, 21 Jul 2014 19:48:38 +0900 (JST) Message-ID: <53CCF001.7050400@toshiba.co.jp> Date: Mon, 21 Jul 2014 19:48:33 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Routing Over Low power and Lossy networks , "dhcwg@ietf.org" References: <20140701155803.14047.81610.idtracker@ietfa.amsl.com> <53BA92D9.3000606@toshiba.co.jp> <53BBA3EF.9040609@toshiba.co.jp> <43CF020C-1007-40A9-8F58-0B4F64672736@nominum.com> <3C9237BF-BF7F-43BF-8A12-35CB9BE6E7F1@gmail.com> <7303.1405801664@sandelman.ca> <53CC1763.3010309@toshiba.co.jp> In-Reply-To: <53CC1763.3010309@toshiba.co.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/VwNMM5UavBhbNJtMp8ZCNBPdvoo Subject: [dhcwg] Updated to -02 MPL config draft (Re: I-D Action: draft-ietf-roll-mpl-parameter-configuration-02.txt) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 10:48:46 -0000 Hi, With valuable inputs from DHC working group, I updated the format and removed the tricky short float values. ---- A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : MPL Parameter Configuration Option for DHCPv6 Authors : Yusuke Doi Matthew Gillmore Filename : draft-ietf-roll-mpl-parameter-configuration-02.txt Pages : 9 Date : 2014-07-21 Abstract: This draft defines a way to configure a parameter set of MPL (Multicast Protocol for Low power and Lossy Networks) via DHCPv6 option. MPL has a set of parameters to control its behavior, and the parameter set is often configured as a network-wide parameter because the parameter set should be identical for each MPL forwarder in an MPL domain. Using the MPL Parameter Configuration Option defined in this document, a network can be configured with a single set of MPL parameter easily. ---- Thanks, Yusuke From nobody Wed Jul 23 06:54:05 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4FB1B2960 for ; Wed, 23 Jul 2014 06:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.252 X-Spam-Level: X-Spam-Status: No, score=-0.252 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, 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 KQ82x0x77Z1D for ; Wed, 23 Jul 2014 06:54:01 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B25541B298D for ; Wed, 23 Jul 2014 06:54:01 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 0B364A1; Wed, 23 Jul 2014 15:54:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1406123640; bh=78zhlpFU+ic2y3djpft3RHJT5DEZ0rQYi7jLpe+2iTQ=; h=Date:From:To:Subject:From; b=YSAMpc5odE2PGInCr8DNNUqq0Z+hdD1wweKH/s0eoVr2uOv3Ef/TQJ444r4XowAm3 sjG9mJUWzgXGvdf0of5O/KhkVOpvE/pcK2+h/9nv+GPi2dTRTIbOlejnw0D3Wrz+vG cqPdqAsP94qoNymBgbU1SU0wtXzgWmizuXf+AHzg= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0736C9F for ; Wed, 23 Jul 2014 15:54:00 +0200 (CEST) Date: Wed, 23 Jul 2014 15:53:59 +0200 (CEST) From: Mikael Abrahamsson To: dhcwg@ietf.org Message-ID: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/aq9ZpERFy81QONLJTavC3d6EkxI Subject: [dhcwg] renumbering event request either from CPE or from server 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, 23 Jul 2014 13:54:03 -0000 Hi, just writing down what I said at the mic (and more...) I would like the following use-cases to be supported and would like to see guidance how it should be done. Since I am no DHCP expert, I am going to write in generic terms as to confuse less by getting the DHC terms wrong. User goes into the CPE web-gui and: * presses the "Emergency renumber NOW" button, and the CPE and network (after some signalling) drops the current prefix/address, and CPE requests a new one and gets it. This might be because the user is receiving unwanted traffic and wants to renumber. This probably needs signaling from the CPE on intent to not want current prefix. * presses the "renumber" button, the CPE indicates that it wants a second prefix with intent of not wanting the existing one again after an overlap time. CPE initiates renumbering event, local hosts connected to it de-prefer the original prefix, and after a while, deprecates, it and CPE and network drops it. This might be because of privacy reasons. * The CPE gets a /60 and then discovers that it needs more because of its local networks has more than 16 subnetworks. Do we need additional information to the server as to "why" the client requests additional space? Is there a difference from wanting more prefixes with the intent to renumber (and thus will drop the existing one in a short while), or wanting more because it needs more permanently? We also need to handle the use-case of the server enforcing policy that the CPE must renumber once every day for instance, without the user doing anything. Can the server indicate to the CPE that after the lease time of the current prefix expires, it won't get it back and it should ask for a new one before the current prefix expires, and in the mean time initiate a renumbering event? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Jul 23 07:24:04 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 857531B29F9; Wed, 23 Jul 2014 07:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9yOoSkr0fWX; Wed, 23 Jul 2014 07:23:58 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D57EB1B29FB; Wed, 23 Jul 2014 07:23:57 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hi2so7937004wib.4 for ; Wed, 23 Jul 2014 07:23:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:subject:date:mime-version:content-type :content-transfer-encoding:thread-index:content-language; bh=8NGDbCOoxOP9SdnNPdF144r+cRpxCq/jg3AoACsaI8E=; b=wkYtyTqCqjAGx/DubvR4bngeW2/MbJSu3GiSUItoQfkoUVPhP04AU64Z4o6n+FDnuO 6ADL8AjO6t5qOIqRAUOAWIYnKEA1hTdUIAReMsldTOCm7LBkmD4VpYJADg4xmT7p2yNt h1bEiFsrAv9wrW3gwRyy3ISSwvUmNM6YwY9Y8QkBi9awo+9h7taOEEqQqmOCAW06eESa FiIEsKv2jQDkRGhogpm8Tj/JBmIR2oIPc1QN/fH9CyNPQA2fM4VSmGnhYW8+e6NMrL5R jjjGQJt87o06HGVN5STHlcOibrHe51Xgd4MXh5I6nJ7xJuZwNBfuJrg1QyCBTBvjlWDV 0unQ== X-Received: by 10.180.20.105 with SMTP id m9mr3907737wie.6.1406125435885; Wed, 23 Jul 2014 07:23:55 -0700 (PDT) Received: from PC ([2001:67c:370:176:4c44:c0bb:9e17:9aff]) by mx.google.com with ESMTPSA id pq9sm6644346wjc.35.2014.07.23.07.23.54 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 23 Jul 2014 07:23:55 -0700 (PDT) Message-ID: <53cfc57b.c9dbc20a.1861.1fd9@mx.google.com> X-Google-Original-Message-ID: <004f01cfa681$94ce8c30$be6ba490$@yeh.sdo@gmail.com> From: "Leaf Yeh" To: "'dhcpv6bis'" Date: Wed, 23 Jul 2014 22:22:47 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac+mgYzZbi07B6pgSXqslL8lahARNg== Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/Ulsui7NbP6jsOUzhZXNpZuBtV-o Cc: dhcwg@ietf.org Subject: [dhcwg] More thing about Confirm 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, 23 Jul 2014 14:23:59 -0000 Hi Folks, We have text on DAD after request->reply message exchange in section 18.1.8 of RFC3315: The client SHOULD perform duplicate address detection [17] on each of the addresses in any IAs it receives in the Reply message before using that address for traffic. Would you like add more text on DAD for Confirm' before using that address for traffic ' while the link-up event always happens in the following cases: o The client reboots. o The client is physically connected to a wired connection. o The client returns from sleep mode. o The client using a wireless technology changes access points. mentioned in section 18.1.2 of RFC3315 ? Best Regards, Leaf From nobody Wed Jul 23 08:03:57 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6281B28CF; Wed, 23 Jul 2014 08:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAu7wge0Wz_a; Wed, 23 Jul 2014 08:03:47 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB1041B27D1; Wed, 23 Jul 2014 08:03:46 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id f8so7906721wiw.0 for ; Wed, 23 Jul 2014 08:03:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:subject:date:mime-version:content-type :content-transfer-encoding:thread-index:content-language; bh=L8OEyfygssZ19PNxThXziTtju1stBJxb9NTSW1/rBLU=; b=pq27vktz0GJaeNEi0pWDpsyQOpGQe8PD6bo03hAf69wGpG7g9aXuRPqNSjCOeIVWpL AogDJqBbqpGfYp3jdPRhxxfTz14fVPOmLnAp1tdDMEZz5eF1mULx2gj/50YBXRtns+yz bG988nz4fsQBJA5WjY+tGaE5BlHmZxCk/Q7QsxVuiRxg0/mdNNUXn1023AwqHWOT9dQs 5Nu0eBzPSLYkbjMkqBNsZ7K0XfpkXZVPfCme1E73/4GxtWNlfJ+t7xKGt/IPz+4Aj/iN ONS6MmLVd3u1vs/yrnu/Eh1Gyw7eMxPs8Pmm8mJe4GZVY0X4xxWvo5P8BlskclZzfgSm OTNg== X-Received: by 10.194.22.201 with SMTP id g9mr2741400wjf.98.1406127825110; Wed, 23 Jul 2014 08:03:45 -0700 (PDT) Received: from PC ([2001:67c:370:176:4c44:c0bb:9e17:9aff]) by mx.google.com with ESMTPSA id pj6sm6936168wjb.21.2014.07.23.08.03.43 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 23 Jul 2014 08:03:44 -0700 (PDT) Message-ID: <53cfced0.6686c20a.0c63.3085@mx.google.com> X-Google-Original-Message-ID: <007001cfa687$24e64420$6eb2cc60$@yeh.sdo@gmail.com> From: "Leaf Yeh" To: "'dhcpv6bis'" Date: Wed, 23 Jul 2014 23:02:35 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac+mhx/cErmJdjy/QNyqvI+MpC2htg== Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/ErESpPlPt-LLm5DbT6wouP_g8UY Cc: dhcwg@ietf.org Subject: [dhcwg] Question on Link-address 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, 23 Jul 2014 15:03:53 -0000 I missed the question on Link-Address in the slides of 'DHCPv6bis update' this morning. "Link-addr field is used by the server to identify the link/subnet the client is connected to. Can it be ::?" I guess the example in RFC6221 permit '::' to be the link-addr: The link-address parameter MUST be set to the unspecified address. @ section 5.1 of RFC6221 When an LDRA receives a Relay-Reply message with an Interface-ID option present and link-address unspecified, the LDRA MUST relay the decapsulated message to the client on the interface identified in the Interface-ID option. @ section 5.3.2 of RFC6221 The LDRA MUST set the link-address field of the Relay-Forward message to the Unspecified Address (::) and MUST include the Interface-ID option in all DHCP Relay-Forward messages. @ section 6.1 of RFC6221 the link-address is the Unspecified Address when no IP address is configured on the LDRA. @ section 6.2 of RFC6221 Best Regards, Leaf From nobody Wed Jul 23 09:38:52 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E34B1A0146 for ; Wed, 23 Jul 2014 09:38:51 -0700 (PDT) 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 rxMiuck6n0Yl for ; Wed, 23 Jul 2014 09:38:49 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55ABB1A00F0 for ; Wed, 23 Jul 2014 09:38:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3473; q=dns/txt; s=iport; t=1406133529; x=1407343129; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=gb/pwYqchWc6gH+UBeIjF2G5yGQzzokxpCmlqX1rAGI=; b=fQYGgQwe409q54yjGcrQqIgHjLZh7DvVZRT+gQyPdaokkiwm0wh9Q9+m Jyrn/M7skdT0YckFo8rJ0w5hwYe0Bw4OxqGS4L8DZwn62NH6ofF0adpEa UPEKKO78dGI3YR9ZtTQGOmjxYbSx/r7Kru8Rbfu9xJzAfHDIPG+kGLeRJ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFAELkz1OtJA2I/2dsb2JhbABZgw5SV8dfCodFAYELFnaEAwEBAQMBAQEBNzEDCwULAgEIDgoeECcLJQIEDgWIOggNwFQTBI5pEQEdMweDLoEYBZstlECDSGyBDA X-IronPort-AV: E=Sophos;i="5.01,718,1400025600"; d="scan'208";a="342248069" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-2.cisco.com with ESMTP; 23 Jul 2014 16:38:48 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s6NGcmsS016947 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Jul 2014 16:38:48 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.176]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Wed, 23 Jul 2014 11:38:48 -0500 From: "Bernie Volz (volz)" To: Mikael Abrahamsson Thread-Topic: [dhcwg] renumbering event request either from CPE or from server Thread-Index: AQHPpn2VIdeN0uYHkkyKeCWMKx2fRJut3CsI Date: Wed, 23 Jul 2014 16:38:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/5Gla5gaipK9se9sGmG3wYDanCq4 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] renumbering event request either from CPE or from server 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, 23 Jul 2014 16:38:51 -0000 I think all of these can be handled within what exists today. If a client wants a completely new prefix (whether or not it wants to keep = the old), it can always initiate this by Requesting it (IA_PD option with d= ifferent IAID). Stateful issues will make this easier as client can do in R= enew. If old prefix is no longer desired, client can always release (either immed= iately or after its own steps to deprecate it - i.e., using shorter lifetim= es than what server granted). Thus,=20 Case 1 - emergency renumber - request new PD (different IAID), release old = after getting new. Case 2 - same, but keep old for a while (this could include renewing it). R= elease when deprecated (either using servers lifetimes or shorter ones). Case 3 - same, but keep renewing old. So I don't think new options are really needed. Note: the above fails if server takes steps to prevent a client from obtain= ing multiple prefixes, but that is hopefully not often the case (though som= e limits may exist to prevent using too many). The final case is handled by the server simply not renewing a lease and, ho= pefully, providing a new one. A server is allowed to add more prefixes on a= ny renewal. - Bernie (from iPad) > On Jul 23, 2014, at 9:54 AM, "Mikael Abrahamsson" wrot= e: >=20 >=20 > Hi, >=20 > just writing down what I said at the mic (and more...) >=20 > I would like the following use-cases to be supported and would like to se= e guidance how it should be done. Since I am no DHCP expert, I am going to = write in generic terms as to confuse less by getting the DHC terms wrong. >=20 > User goes into the CPE web-gui and: >=20 > * presses the "Emergency renumber NOW" button, and the CPE and network (a= fter some signalling) drops the current prefix/address, and CPE requests a = new one and gets it. This might be because the user is receiving unwanted t= raffic and wants to renumber. This probably needs signaling from the CPE on= intent to not want current prefix. >=20 > * presses the "renumber" button, the CPE indicates that it wants a second= prefix with intent of not wanting the existing one again after an overlap = time. CPE initiates renumbering event, local hosts connected to it de-prefe= r the original prefix, and after a while, deprecates, it and CPE and networ= k drops it. This might be because of privacy reasons. >=20 > * The CPE gets a /60 and then discovers that it needs more because of its= local networks has more than 16 subnetworks. Do we need additional informa= tion to the server as to "why" the client requests additional space? Is the= re a difference from wanting more prefixes with the intent to renumber (and= thus will drop the existing one in a short while), or wanting more because= it needs more permanently? >=20 > We also need to handle the use-case of the server enforcing policy that t= he CPE must renumber once every day for instance, without the user doing an= ything. Can the server indicate to the CPE that after the lease time of the= current prefix expires, it won't get it back and it should ask for a new o= ne before the current prefix expires, and in the mean time initiate a renum= bering event? >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From nobody Wed Jul 23 13:14:59 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE471A03BC for ; Wed, 23 Jul 2014 13:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGJ6cuwkqugn for ; Wed, 23 Jul 2014 13:14:55 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [81.174.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id B3DD71A0313 for ; Wed, 23 Jul 2014 13:14:54 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [192.168.1.4] (88-111-161-27.dynamic.dsl.as9105.com [88.111.161.27]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 994931BC3F for ; Wed, 23 Jul 2014 20:14:50 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Simon Hobson In-Reply-To: Date: Wed, 23 Jul 2014 21:14:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3A3A8DF3-F03D-413D-B1F7-E23AD981556E@thehobsons.co.uk> References: To: "dhcwg@ietf.org" X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/SDNmXymiG0FVJjo-LiQiU7dw7Vc Subject: Re: [dhcwg] renumbering event request either from CPE or from server 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, 23 Jul 2014 20:14:57 -0000 Mikael Abrahamsson wrote: > We also need to handle the use-case of the server enforcing policy = that the CPE must renumber once every day for instance, without the user = doing anything. Over on the ISC DHCP users list, there have been a number of threads = along the lines of "how can we make clients change address every = " - usually because "management" have decided it's the way to = prevent users running servers. The response has generally been along the lines of "start looking for a = new job, because your customers will go elsewhere when you p**s them = off". This is in the IPv4 space, it's hard to see why the arguments should be = any different in the IPv6 space. From nobody Wed Jul 23 14:31:33 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E4D1A03DE for ; Wed, 23 Jul 2014 14:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfR_R1e4DRhQ for ; Wed, 23 Jul 2014 14:31:30 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EB011A02F7 for ; Wed, 23 Jul 2014 14:31:30 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 3B2031B8440 for ; Wed, 23 Jul 2014 14:31:30 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 0C9E6190052; Wed, 23 Jul 2014 14:31:30 -0700 (PDT) Received: from nat64.meeting.ietf.org (31.130.238.69) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 23 Jul 2014 14:31:29 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <3A3A8DF3-F03D-413D-B1F7-E23AD981556E@thehobsons.co.uk> Date: Wed, 23 Jul 2014 17:31:26 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <6F5C5A98-26BE-4FAA-8AE0-3E817595BD93@nominum.com> References: <3A3A8DF3-F03D-413D-B1F7-E23AD981556E@thehobsons.co.uk> To: Simon Hobson X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [31.130.238.69] Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/74s_rQ1y7tyWMEY_Llb2DiLi12I Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] renumbering event request either from CPE or from server 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, 23 Jul 2014 21:31:31 -0000 On Jul 23, 2014, at 4:14 PM, Simon Hobson = wrote: > This is in the IPv4 space, it's hard to see why the arguments should = be any different in the IPv6 space. It's a little less bad in the IPv6 space if you just make the customer = renumber. And there are privacy advantages to renumbering. So it's = not a completely bad thing to enable mandatory renumbering; what's = important is that it be done in a way that doesn't blow up people's = multi-hour flows. You probably aren't going to win with multi-day = flows. From nobody Thu Jul 24 04:35:07 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E10111A017E for ; Thu, 24 Jul 2014 04:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkHGKsYs77TC for ; Thu, 24 Jul 2014 04:35:05 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A81221A0179 for ; Thu, 24 Jul 2014 04:35:05 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 623EA1B831E for ; Thu, 24 Jul 2014 04:35:04 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 21F1B190052 for ; Thu, 24 Jul 2014 04:35:04 -0700 (PDT) Received: from [192.168.0.10] (99.232.25.196) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 24 Jul 2014 04:35:04 -0700 From: Ted Lemon Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <174682F2-FFA5-46AB-8AE6-863148BC4C21@nominum.com> Date: Thu, 24 Jul 2014 07:35:01 -0400 To: dhcwg MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [99.232.25.196] Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/L4pdmxZy3P5DgOIYsliIfdHHrdU Subject: [dhcwg] Use case for client authentication... 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, 24 Jul 2014 11:35:07 -0000 I don't know if this is a use case that would actually get used, but in = l'esprit d'escalier, I will repeat it, since it's one that crossed my = mind at some point in the past when I was discussing this with Sheng. The use case is that you run a Wifi hotspot network. Subscribers have = registered devices, which present keys known to the infrastructure. = When such a key is presented, the subscriber gets immediate access = without having to authenticate to the captive portal. The flow is like = this: This flow would require additional work: the current spec does not = provide everything that's required, and some of what's required probably = isn't DHCP stuff. But this is the sort of thing you can do with client = authentication, at least in principle. Why not just use 802.1X? Because 802.1X requires a pre-established = trust relationship, which hasn't been established in the first phase. From nobody Thu Jul 24 07:21:03 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAC131A004A for ; Thu, 24 Jul 2014 07:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.952 X-Spam-Level: X-Spam-Status: No, score=-3.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, 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 7txk76SB1A6y for ; Thu, 24 Jul 2014 07:20:57 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2F8F1A0012 for ; Thu, 24 Jul 2014 07:20:57 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 358A7A1; Thu, 24 Jul 2014 16:20:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1406211655; bh=Tr/Iq3fGCIYS02kak1oSTMgrnK43OpqZB+JojuI086M=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=alR+rXftcog+rRrpmoGKJTXtJfudeH1MpRY3w/K9ju+jRxxQeLTnUs7tydwCfTdB8 2dZeRFdeNJw5gkhJMNYoA+3hEOk5xVsDjp3kVQ4jEfnEnIHutA+9XIM43Dmgdm3qem x/Y6Z/yKtwhTf2FeTaOdRu2T+g0SNWIFHrqqIPmg= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2C4DD9F; Thu, 24 Jul 2014 16:20:55 +0200 (CEST) Date: Thu, 24 Jul 2014 16:20:55 +0200 (CEST) From: Mikael Abrahamsson To: Simon Hobson In-Reply-To: <3A3A8DF3-F03D-413D-B1F7-E23AD981556E@thehobsons.co.uk> Message-ID: References: <3A3A8DF3-F03D-413D-B1F7-E23AD981556E@thehobsons.co.uk> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/Kod1yl3mJ8gpsIjjv7rtYZe0L6E Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] renumbering event request either from CPE or from server 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, 24 Jul 2014 14:21:00 -0000 On Wed, 23 Jul 2014, Simon Hobson wrote: > Over on the ISC DHCP users list, there have been a number of threads > along the lines of "how can we make clients change address every > " - usually because "management" have decided it's the way to > prevent users running servers. There are markets where part of the customer base demands to be renumbered regularily. You might think they're stupid, but ISPs in those markets lose customers if they don't have this functionality. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Jul 24 07:34:37 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8FB21A034B for ; Thu, 24 Jul 2014 07:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRPGyNyk_BaF for ; Thu, 24 Jul 2014 07:34:34 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B8B51A03BC for ; Thu, 24 Jul 2014 07:34:19 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id DFDCC1B845A for ; Thu, 24 Jul 2014 07:34:18 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id CD0CE190052 for ; Thu, 24 Jul 2014 07:34:18 -0700 (PDT) Received: from [192.168.0.10] (99.232.25.196) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 24 Jul 2014 07:34:18 -0700 From: Ted Lemon Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: Date: Thu, 24 Jul 2014 10:34:14 -0400 To: dhcwg MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [99.232.25.196] Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/lWUXZb1umG7r1e7YPdQ0krDQaa4 Subject: [dhcwg] Another use case for sedhcp (in this case, server auth/leap of faith) 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, 24 Jul 2014 14:34:36 -0000 =46rom draft-ietf-dnssd-requirements-03: 6.5. Privacy Considerations Mobile devices such as smart phones that can expose the location of their owners by registering services in arbitrary zones pose a risk to privacy. Such devices must not register their services in arbitrary zones without the approval ("opt-in") of their users. However, it should be possible to configure one or more "safe" zones in which mobile devices may automatically register their services. There's no way to do this securely if you don't have a way to = authenticate the network. sedhcp or SeND would be obvious ways to do = this. SeND would probably be preferable, but sedhcp would work and may = be easier to actually get working in practice. From nobody Thu Jul 24 09:01:39 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACD751A0176 for ; Thu, 24 Jul 2014 09:01:37 -0700 (PDT) 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 FvSoG7h1edn1 for ; Thu, 24 Jul 2014 09:01:28 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44C3A1A02D0 for ; Thu, 24 Jul 2014 09:01:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=983; q=dns/txt; s=iport; t=1406217688; x=1407427288; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=t1gXW6PvpBNvCkFWSCh4Aae6lb/sS7/EuWqBlSq+aME=; b=fpnMIAKeK4j5BdsW0tlhbKqsyX/PylVgS78paSrkJWgbw44Rkuhj9KBd PMOXnFM18kjzL3BxKHOGTrJgfbbgr+g+yvprfDX6YwKkje1kl7RKwKvg0 ceTwnhyeSagjjxHf2Q4HZNFeC7npdNAdHKhvyXVS7kdncUP3qnBkh/G+I 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFANos0VOtJV2Z/2dsb2JhbABYgw5SV8kuCodFAYENFneEAwEBAQMBAQEBNzQLBQsCAQgOCh4QJwslAgQOBYg6CA3AFhMEjmkRAR0zB4MugRgFmzOUQoNIbIEM X-IronPort-AV: E=Sophos;i="5.01,725,1400025600"; d="scan'208";a="342533362" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 24 Jul 2014 16:01:27 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s6OG1Rdh004478 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Jul 2014 16:01:27 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.176]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Thu, 24 Jul 2014 11:01:27 -0500 From: "Bernie Volz (volz)" To: Mikael Abrahamsson Thread-Topic: [dhcwg] renumbering event request either from CPE or from server Thread-Index: AQHPpn2VIdeN0uYHkkyKeCWMKx2fRJuubFwAgAEvcID//8hEPA== Date: Thu, 24 Jul 2014 16:01:26 +0000 Message-ID: <73713B0E-64A3-4D95-AA11-B29D6BF7D289@cisco.com> References: <3A3A8DF3-F03D-413D-B1F7-E23AD981556E@thehobsons.co.uk>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/Q71wCLGhiZSaXfZx2ysGyHTDXqU Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] renumbering event request either from CPE or from server 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, 24 Jul 2014 16:01:37 -0000 This should all be possible and work through existing DHCPv6 operations. Se= rver can add new address and deprecate old one when client renews. - Bernie (from iPad) > On Jul 24, 2014, at 10:21 AM, "Mikael Abrahamsson" wro= te: >=20 >> On Wed, 23 Jul 2014, Simon Hobson wrote: >>=20 >> Over on the ISC DHCP users list, there have been a number of threads alo= ng the lines of "how can we make clients change address every " - u= sually because "management" have decided it's the way to prevent users runn= ing servers. >=20 > There are markets where part of the customer base demands to be renumbere= d regularily. You might think they're stupid, but ISPs in those markets los= e customers if they don't have this functionality. >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From nobody Thu Jul 24 10:13:15 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E451A0A9F for ; Thu, 24 Jul 2014 10:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.952 X-Spam-Level: X-Spam-Status: No, score=-3.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, 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 h5sJhp4spMpA for ; Thu, 24 Jul 2014 10:13:10 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D9461A0444 for ; Thu, 24 Jul 2014 10:12:41 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 6C3E8A1; Thu, 24 Jul 2014 19:12:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1406221959; bh=PsJOI32A9Xfx97X769x8BwxqKAxq8f4xmPeFgzmTFaw=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Pqh93VZvIrksayqX3l2WMVpR/RTeGvEXcRXgcReqVJbN9c0/vXvEokn8FK/le8kog KEHTEOe6S2kZOO/QlRTZXPbbOmkOXg8K8dx2//DGqcb+g+QUJG1jpXdjV7pqIal5Pc EUlSPazRf3MFrqiIMtoCONF0KgQu1ssD6f5SJXQY= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 67CEE9F; Thu, 24 Jul 2014 19:12:39 +0200 (CEST) Date: Thu, 24 Jul 2014 19:12:39 +0200 (CEST) From: Mikael Abrahamsson To: "Bernie Volz (volz)" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/KSMWe2L47qN513hLb6wZORrET1I Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] renumbering event request either from CPE or from server 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, 24 Jul 2014 17:13:14 -0000 On Wed, 23 Jul 2014, Bernie Volz (volz) wrote: > I think all of these can be handled within what exists today. > > If a client wants a completely new prefix (whether or not it wants to keep the old), it can always initiate this by Requesting it (IA_PD option with different IAID). Stateful issues will make this easier as client can do in Renew. > > If old prefix is no longer desired, client can always release (either immediately or after its own steps to deprecate it - i.e., using shorter lifetimes than what server granted). > > Thus, > > Case 1 - emergency renumber - request new PD (different IAID), release old after getting new. > Case 2 - same, but keep old for a while (this could include renewing it). Release when deprecated (either using servers lifetimes or shorter ones). > Case 3 - same, but keep renewing old. > > So I don't think new options are really needed. Depends if the operator only wants the customer to have a single DHCPv6-PD prefix at any given time, then the combination of this requirement and above wouldn't seem to work for Case 1? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Jul 24 11:16:01 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F129D1A0353 for ; Thu, 24 Jul 2014 11:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2kQM9ZBOiXX for ; Thu, 24 Jul 2014 11:15:56 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C52DD1A0142 for ; Thu, 24 Jul 2014 11:15:55 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id b13so3120909wgh.18 for ; Thu, 24 Jul 2014 11:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=tB1P4e3Ztd6h/A0kWWuOyYQ/zAm/7fW7cgPPRxKe9pQ=; b=pEQU3b67fkxkr1WiVlrwfTIoRGJVSeE7ZQZ1eWG28XB1mST9xzU40jj1ujHkVskntf UKX+zYu68xJr1zwE7dSBbdM5AHvwlK1ymRgJAp6cw6DwNLcHRF4yEOTU8a3jhKLbmdhP jXWHJmigNKZQaGEJIDadwkj7icv9nzgol6wJSbKmug+hAUwkjLD/nDAjNM0ZLcpvoaT9 QLmz3790vxHxYRht3BkFd4Q6XDdJqBwal/RKRwyJNc/hnMAW1F+GYc5OlKYoG0jn6BMm 3F/kzHe8C8Flfkr8HJF1k8ARuhlidVLjUZZXkPeqIOEQzPg+XjQToojGVGm5BxifPChj +8bQ== MIME-Version: 1.0 X-Received: by 10.180.96.169 with SMTP id dt9mr15085728wib.62.1406225753828; Thu, 24 Jul 2014 11:15:53 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.108.166 with HTTP; Thu, 24 Jul 2014 11:15:53 -0700 (PDT) In-Reply-To: <174682F2-FFA5-46AB-8AE6-863148BC4C21@nominum.com> References: <174682F2-FFA5-46AB-8AE6-863148BC4C21@nominum.com> Date: Thu, 24 Jul 2014 11:15:53 -0700 X-Google-Sender-Auth: fYEqpQy8BD_IV741mAV6ptqBqeI Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Ted Lemon Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/CnhqWrfLKxRXvi3WK1_2T--8OTU Cc: dhcwg Subject: Re: [dhcwg] Use case for client authentication... 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, 24 Jul 2014 18:15:57 -0000 At Thu, 24 Jul 2014 07:35:01 -0400, Ted Lemon wrote: > > > > > Do you mean, for example, the client/server public key used in SeDHCPv6 by "credentials"? And, in the above example, would the client send the Solicit without a public key or certificate option? I thought SeDHCPv6 intended to start a DHCPv6 session from a Solicit with one of these options. Section 6.1 of sedhcpv6-03 says: A Secure DHCPv6 message, except for Relay-forward and Relay-reply messages, MUST contain either a Public Key or a Certificate option, which MUST be constructed as explained in Section 5.1 or Section 5.2. -- JINMEI, Tatuya From nobody Thu Jul 24 11:32:25 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 471851B27E7 for ; Thu, 24 Jul 2014 11:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-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 WS-5QfSmffF4 for ; Thu, 24 Jul 2014 11:32:20 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80BF21B27E5 for ; Thu, 24 Jul 2014 11:32:20 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 485CB1B8522 for ; Thu, 24 Jul 2014 11:32:20 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 22DD9190052; Thu, 24 Jul 2014 11:32:20 -0700 (PDT) Received: from nat64.meeting.ietf.org (31.130.238.225) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 24 Jul 2014 11:32:13 -0700 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Thu, 24 Jul 2014 14:32:09 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <174682F2-FFA5-46AB-8AE6-863148BC4C21@nominum.com> To: =?utf-8?B?56We5piO6YGU5ZOJ?= X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [31.130.238.225] Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/9PrPhy68N9TyfkPETlaJDCLOxSk Cc: dhcwg Subject: Re: [dhcwg] Use case for client authentication... 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, 24 Jul 2014 18:32:21 -0000 On Jul 24, 2014, at 2:15 PM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = wrote: > Do you mean, for example, the client/server public key used in > SeDHCPv6 by "credentials"? And, in the above example, would the > client send the Solicit without a public key or certificate option? I think from a privacy perspective it can be argued that sending the = client certificate in the Solicit isn't a good idea. As for the server = cert, I think it's useful to be able to have a single organizational = signing key that signs multiple infrastructure keys, so I think there = does need to be a cert; I'm agnostic as to how that would be done. From nobody Thu Jul 24 13:23:50 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA231B27B0 for ; Thu, 24 Jul 2014 13:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBEwZb1VMjF5 for ; Thu, 24 Jul 2014 13:23:46 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E84B1B285C for ; Thu, 24 Jul 2014 13:23:46 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 25b61d35.2b3b9938a940.1921404.00-2482.4887664.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 24 Jul 2014 20:23:46 +0000 (UTC) X-MXL-Hash: 53d16b5247b0cdeb-b40aa533d0ad4de804628b19539480091a4ce489 Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 15b61d35.0.1921398.00-2384.4887621.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 24 Jul 2014 20:23:46 +0000 (UTC) X-MXL-Hash: 53d16b526c285717-6af4c765576d14480d0c9edbf9bc68d71b2779f6 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6OKNhZ6003394; Thu, 24 Jul 2014 16:23:43 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6OKNaAC003328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Jul 2014 16:23:40 -0400 Received: from GAALPA1MSGHUB9C.ITServices.sbc.com (GAALPA1MSGHUB9C.itservices.sbc.com [130.8.36.89]) by alpi133.aldc.att.com (RSA Interceptor); Thu, 24 Jul 2014 20:23:17 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.28]) by GAALPA1MSGHUB9C.ITServices.sbc.com ([130.8.36.89]) with mapi id 14.03.0174.001; Thu, 24 Jul 2014 16:23:17 -0400 From: "STARK, BARBARA H" To: Mikael Abrahamsson , "Bernie Volz (volz)" Thread-Topic: [dhcwg] renumbering event request either from CPE or from server Thread-Index: AQHPpn2W2wxERxrZC02vstHe44S/Q5uuHzmAgAGby4D//+yx8A== Date: Thu, 24 Jul 2014 20:23:17 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130E0CC41@GAALPA1MSGUSRBF.ITServices.sbc.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.75.159] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=Y+xPRGiN c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=-cvETLn9oN4A:10 a=ofMgfj31e3cA:10 a=pM5qkzznwcAA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=Dbqwg7TzjZZTaTVsGR0A:9 a=CjuIK1q_8ugA:10 a=bvd0Md] X-AnalysisOut: [hqHQKswxv2:21 a=Aq8F1GRwid6Xdxke:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/jAQ_Uym3Iuy4yNSBjc8P57sk7vE Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] renumbering event request either from CPE or from server 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, 24 Jul 2014 20:23:48 -0000 > > I think all of these can be handled within what exists today. > > > > If a client wants a completely new prefix (whether or not it wants to k= eep > the old), it can always initiate this by Requesting it (IA_PD option with > different IAID). Stateful issues will make this easier as client can do i= n Renew. > > > > If old prefix is no longer desired, client can always release (either > immediately or after its own steps to deprecate it - i.e., using shorter > lifetimes than what server granted). In many access networks, stable addressing is achieved by associating the p= refix with the access link (customer). If this has been done, then release = and renew will always result in the same prefix; and it's often not allowed= (per policy) to have multiple prefixes. Associating the prefix with the cu= stomer allows the prefix to be stable across power outages. A strong message has been given to ISPs that stable addressing is recommend= ed as standard behavior for IPv6. Therefore, I don't think either of these methods is sufficient to signal to= an ISP that a different prefix is desired. Alternately, there could be a recommendation that release/renew implies "I = want a different address/prefix". But I don't think that would be popular, = because so many DHCPv4 servers today do everything they can to give a devic= e the same assignment every time. In my home router I have to manually clea= r out the DHCPv4 assignments to force new IPv4 addresses. The router mainta= ins a memory of MAC address to IPv4 address. Barbara From nobody Fri Jul 25 09:49:35 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 544721B27D8 for ; Fri, 25 Jul 2014 09:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTTLoDEsgbav for ; Fri, 25 Jul 2014 09:49:32 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B29F1B2864 for ; Fri, 25 Jul 2014 09:49:32 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id f8so1324712wiw.12 for ; Fri, 25 Jul 2014 09:49:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=abIP/lMVCVmLJZfXbU1hAp9TtRJ2AAPNcz81oqNeyXY=; b=Mi5G/MCstctcNjFQxZBwN8RT5cjNS5FSaApFPqWbvslqt6Tg8Zud2VvevfDVgvYqgo wG7sKobHImZWd3ihb/P7zmgi0YRwst3fzXWOibV/cQJbsUgbYScq44tnBgDWby0lysa/ qlbKA8UsXUTWcO9RkWY24EBYMTLFvFaiMwfqC80zVrPkf25O8d8/0sG4Lj95nTP5IuLC C354B+XwJG9CM1220G47m3P34zCCDLqQjuHCuktTxoLxtLKSLs4dr2cRQhiPNS+P2cHE oh/cxeGxHrwy8pEA+T7+GW8M2VZOx8IYpDLiEz4pqmr8BPD2yP3cp6R3gM/iWtQQdk3o we3A== MIME-Version: 1.0 X-Received: by 10.194.63.228 with SMTP id j4mr23894383wjs.7.1406306970589; Fri, 25 Jul 2014 09:49:30 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.108.166 with HTTP; Fri, 25 Jul 2014 09:49:30 -0700 (PDT) In-Reply-To: References: <174682F2-FFA5-46AB-8AE6-863148BC4C21@nominum.com> Date: Fri, 25 Jul 2014 09:49:30 -0700 X-Google-Sender-Auth: ZedHq7g5ANUrWeZ2ttWR28B-Zx4 Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Ted Lemon Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/9vHa9nvi6whxl6sRx9ep8HWQ-88 Cc: dhcwg Subject: Re: [dhcwg] Use case for client authentication... 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, 25 Jul 2014 16:49:33 -0000 At Thu, 24 Jul 2014 14:32:09 -0400, Ted Lemon wrote: > > Do you mean, for example, the client/server public key used in > > SeDHCPv6 by "credentials"? And, in the above example, would the > > client send the Solicit without a public key or certificate option? > > I think from a privacy perspective it can be argued that sending the client certificate in the Solicit isn't a good idea. Hmm, then I suspect it will require a substantial protocol change to sedhcpv6 (which is not necessarily bad, depending on how we should consider the possible privacy concern to be critical). -- JINMEI, Tatuya