From nobody Fri Jan 1 06:00:15 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E95B1ACCDE for ; Fri, 1 Jan 2016 06:00:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, 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 4zpjrTQJvktM for ; Fri, 1 Jan 2016 06:00:13 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67CDB1ACCDC for ; Fri, 1 Jan 2016 06:00:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1314; q=dns/txt; s=iport; t=1451656813; x=1452866413; h=date:from:message-id:to:subject; bh=+gX61yAnpaUolsQWK3qwl7YbsqK8EnRQC8/jqCfjQ7c=; b=k60MrBjTiOnM0kLdQER1h+2TC6OM/lqMZh17QGq28nby9bdzJrPA8CVl 4c0aGiIYHEH534pHqkpeaw6QDk71luewRFTgMiSejrh4Ps5SRqfE52E4P Lv7pp58pgR+0PmJViOjhsGpogCJvPBqXbVYqqjtYLy9ZqQoYKjbkG1ZV+ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AbAwCuhYZW/4QNJK1egzqKGKRAAY9QA?= =?us-ascii?q?Q2BZIciOBQBAQEBAQEBgQpBEoUdNIkPAZ8boFIBAQgBAQEBAR6QeIQZBY4wiFa?= =?us-ascii?q?BDps+jjogAQFChCuCIYNAAQEB?= X-IronPort-AV: E=Sophos;i="5.20,508,1444694400"; d="scan'208";a="58025816" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Jan 2016 14:00:12 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u01E0Bj4004837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 1 Jan 2016 14:00:12 GMT Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id u01E0B7X025289 for ; Fri, 1 Jan 2016 06:00:11 -0800 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id u01E0BqP025288 for v6ops@ietf.org; Fri, 1 Jan 2016 06:00:11 -0800 Date: Fri, 1 Jan 2016 06:00:11 -0800 From: fred@cisco.com Message-Id: <201601011400.u01E0BqP025288@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Subject: [v6ops] State of play X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jan 2016 14:00:14 -0000 RFC Editor: EDIT 2015-11-23 draft-ietf-v6ops-reducing-ra-energy-consumption 2015-10-26 draft-ietf-v6ops-siit-dc 2015-10-26 draft-ietf-v6ops-siit-dc-2xlat 2015-10-26 draft-ietf-v6ops-siit-eam RFC Editor: In ISE Review 2015-12-17 draft-ietf-v6ops-mobile-device-profile RFC Editor: RFC-EDITOR 2015-10-19 draft-ietf-v6ops-pmtud-ecmp-problem WG: Unupdated WG Document 2015-10-19 draft-ietf-v6ops-design-choices 2015-07-06 draft-ietf-v6ops-dhcpv6-slaac-problem WG: Updated WG Document 2015-12-10 draft-ietf-v6ops-host-addr-availability 2015-11-01 draft-ietf-v6ops-unique-ipv6-prefix-per-host WG: WG Consensus: Waiting for Write-Up 2015-12-11 draft-ietf-v6ops-ipv6-ehs-in-real-world Individual Submission: Unupdated 2015-10-19 draft-jjmb-v6ops-unique-ipv6-prefix-per-host 2015-10-19 draft-xu-v6ops-dslite-redundancy 2015-10-15 draft-gont-v6ops-ipv6-ehs-packet-drops 2015-10-10 draft-bao-v6ops-rfc6145bis 2015-09-21 draft-ybai-v6ops-ipv6-for-openstack 2015-07-06 draft-akira-v6ops-mape-experience 2015-07-06 draft-xcf-v6ops-chinatelecom-deployment 2015-07-05 draft-hui-v6ops-ipv6trans-select-nfv 2015-07-05 draft-xli-v6ops-cernet-deployment 2015-07-05 draft-yang-v6ops-ipv6tran-select Individual Submission: Updated 2015-11-05 draft-templin-v6ops-pdhost From nobody Sun Jan 3 11:00:27 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A83421A000A for ; Sun, 3 Jan 2016 11:00:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -112.612 X-Spam-Level: X-Spam-Status: No, score=-112.612 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, 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 SEjRaW_qsRd6 for ; Sun, 3 Jan 2016 11:00:24 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 864D61A0004 for ; Sun, 3 Jan 2016 11:00:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=244; q=dns/txt; s=iport; t=1451847624; x=1453057224; h=date:from:message-id:to:subject; bh=2maxOI2znjidUxtTX1zI5bz4lEAupTbS8t4eNsMHU6M=; b=dGPVE19IRUomSqBgAcbdiwzfUAYHEYjf0QdY95yCfKv45SR1izrzf1dG loweULyYH6LHOhJskyMMQswZRGmXNdh0KPlXuRHlcuN30VSuJunzCxlJa JaCpac+IQpLbLeoMiRo1SNxIOUky6FMxd+AA8qhbZKoLgI/k7G6etGk6Z U=; X-IronPort-AV: E=Sophos;i="5.20,517,1444694400"; d="scan'208";a="58393445" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Jan 2016 19:00:23 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u03J0NBT012512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Jan 2016 19:00:23 GMT Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id u03J0Lxj009764; Sun, 3 Jan 2016 11:00:21 -0800 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id u03J0LMe009763; Sun, 3 Jan 2016 11:00:21 -0800 Date: Sun, 3 Jan 2016 11:00:21 -0800 From: fred@cisco.com Message-Id: <201601031900.u03J0LMe009763@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Subject: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jan 2016 19:00:26 -0000 And now for something a little different. I'd like to invite focused discussion of draft-ietf-v6ops-unique-ipv6-prefix-per-host, which we adopted at IETF 94 Slides are at https://www.ietf.org/proceedings/94/slides/slides-94-v6ops-4.pdf. From nobody Sun Jan 3 19:16:40 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0061B2A42 for ; Sun, 3 Jan 2016 19:16:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.312 X-Spam-Level: * X-Spam-Status: No, score=1.312 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Qpw3dd4W70li for ; Sun, 3 Jan 2016 19:16:37 -0800 (PST) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C4661B2A40 for ; Sun, 3 Jan 2016 19:16:37 -0800 (PST) Received: by mail-yk0-x22c.google.com with SMTP id a85so158739091ykb.1 for ; Sun, 03 Jan 2016 19:16:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=LPFX/QMnOoOK+8+P5P/WA/yJSmgyxIvbXlmJnAPe+Ys=; b=jQ/HRgJoyh0QXc2Pxe2JH6lhcSctEd5rrTHDhKbErEO4xJLHT7XvV2+L/nMrYtZw4p fXAJtBq3rvSc1l1y1t3IPNEG0idI8SJ5GX70wBoGHk2on0SdOK1qBJRz09q8SRCskoIH sDJ0YIVg1XsKFaPgPiQevA8JqnR3N3+KxzmMEvt0B5vyH+G2pRJf/7AkICZqmVpxGLUT MT72U/i//bzeSjwY+VoG6/ntoDcP6ZNQBonWKNvsuLX8m8ikRVQpj834qa4XHiYVjiWR XBVqNA57+Z/kS0Kcek9VGXG2ka3o0EgCsOARmZ0k2/7skUtAyFyvaFvTKShxCPqn9TCw g9sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=LPFX/QMnOoOK+8+P5P/WA/yJSmgyxIvbXlmJnAPe+Ys=; b=RKcwWVc9oQtKIuTEZplE20ZAfIg8tPZOixqgpFFWvjeqAf0fo8m5xVxjVxSfrhzSfU oByRE8P8C6KWFcMAzUGZGSd6XZstAZZePQycFAm1Qxjfc1Bbqv1hFK/NvUPv7e2pB3qg yDWRltogf8cl6JrHteqxvD0Wlu0j039nFqJiy0H21+QvURq/YtWUYbKJ7A7+LQiS1KbE sXflSHqy9XSdPqSivZ6W1DI3dPw0JUqKwKjE/B1R+ERvMMLDk/8Ypj3hWBq2qVsFp66y j896hqofhk7nJ9wsHA8vAmDa1DKX4vkpqlOD2Cdcl2ClLP7eWNDnDwDxcf/5NNaVQMoC USaQ== X-Gm-Message-State: ALoCoQkwYp6ZI/C8nm4KLOHLle2URONWpblwKCsZkchqi0rqBAB7P1VRizrUDhiWjqwkBD7zRNgO09HqZAUOHX3FpycVsAhtbddjzwhhg3ur7nl2F2LOGns= X-Received: by 10.129.136.196 with SMTP id y187mr61152876ywf.307.1451877396185; Sun, 03 Jan 2016 19:16:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.208.201 with HTTP; Sun, 3 Jan 2016 19:16:16 -0800 (PST) In-Reply-To: <56725836.7070609@umn.edu> References: <20151210151847.2475.78959.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F8786C@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F8B3B5@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F8B8E9@XCH-BLV-504.nw.nos.boeing.com> <56725836.7070609@umn.edu> From: Lorenzo Colitti Date: Mon, 4 Jan 2016 12:16:16 +0900 Message-ID: To: David Farmer Content-Type: multipart/alternative; boundary=001a114f38b47574b20528798ca4 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Calling the question: draft-ietf-v6ops-host-addr-availability-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 03:16:39 -0000 --001a114f38b47574b20528798ca4 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 17, 2015 at 3:37 PM, David Farmer wrote: > On 12/16/15 07:09 , Lorenzo Colitti wrote: > >> Again, let's make sure we're agree on the scope of this document. What >> we're talking about is how the network provides addresses, not how the >> recipient of such addresses behaves. Yes? >> > > Yes, I agree. However, I think the subtly of that distinction is easily > lost on casual readers of the document. That is why earlier I was trying > to suggest you should be more explicit about what is out-of scope. Instead > of what I suggested last time, maybe add something like the following "It > does not specify any changes to protocols or end host behavior" to the end > of the Introduction; > > This document describes the benefits of providing multiple addresses > per host and the problems with not doing so. It recommends that > networks provide general-purpose end hosts with multiple global > addresses when they attach, and lists current options for doing so. > It does not specify any changes to protocols or end host behavior. > > I think that reinforces and clarifies the scope by being explicit about > what is out-of scope. > > Also you seem to frequently stray into talking about things from a host > perspective, instead of clearly a network perspective, this is probably > confusing this issue a bit. > > Generally, hosts "obtain" addresses, networks "provide" addresses, > "assigning" while correct, might be a little passive, I think "providing" > more clearly communicating a network perspective. So, a few specific > suggestions for combating this host vs. network confusion; > > 1. Section 1, "Introduction", the last paragraph starts with "This > document describes the benefits of assigning multiple addresses per > host..." I think "This document describes the benefits of providing > multiple addresses per host..." would be more strongly focused on the > network perspective. > > 2. Section 3 is is titled "Benefits of multiple addresses". "Benefits of > providing multiple addresses" is more clearly projects a network > perspective. > > 3. Section 4 is is titled "Problems with assigning a restricted number of > addresses per host", I think "Problems with restricting the number of > addresses per host" is stronger, but this one is a bit of a coin flip. > > 4. Section 6 is titled "Options for obtaining more than one address", and > starts with "Multiple IPv6 addresses can be obtained in...". This is > clearly confusing the perspective and should be changed to "Options for > providing more than one address", and start with "Multiple IPv6 addresses > can be provided in..." > > 5. Section 9.3 in the middle paragraph; "...However, switching to a DHCPv6 > PD model with one /64 prefix per host resolves these scaling > limitations..." And the last paragraph starts with; "Also, a DHCPv6 PD > model with a dedicated /64 per host makes...". Again these is a little > passive, how about "... However, switching to a DHCPv6 PD model providing > one /64 prefix per host resolves these scaling limitations.." and "Also, a > DHCPv6 PD model providing a dedicated /64 per host makes..." is more > actively about the network. > Thanks. We've applied these suggestions in -04. Yes, this is all true, but most people still have the impression that > DHCPv6 PD is primarily intended for configuring routers or CPE and not > hosts. If you read the introduction RFC 3633, it is easy to see why people > have that impression. Even the example you site is related to Internet > Connection Sharing (ICS) where Windows is basically acting like a CPE > router. I'm not sure what to do about it though, but it probably shouldn't > be ignored. > I added the following text to -04: While [RFC3633] assumes that the DHCPv6 client is a router, DHCPv6 PD itself does not require that the client forward IPv6 packets not addressed to itself, and thus does not require that the client be an IPv6 router as defined in [RFC2460]. Better? --001a114f38b47574b20528798ca4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Dec 17, 2015 at 3:37 PM, David Farmer <farmer@umn.edu> wrot= e:
On 12/16/15 07:09 , Lorenzo Colitti= wrote:
Again, let's make sure we're agree on the scope of this document. W= hat
we're talking about is how the network provides addresses, not how the<= br> recipient of such addresses behaves. Yes?

 Yes, I agree.=C2=A0 However, I think the subtly of that distinction is easi= ly lost on casual readers of the document.=C2=A0 That is why earlier I was = trying to suggest you should be more explicit about what is out-of scope.= =C2=A0 Instead of what I suggested last time, maybe add something like the = following "It does not specify any changes to protocols or end host be= havior" to the end of the Introduction;

=C2=A0 =C2=A0This document describes the benefits of providing multiple add= resses
=C2=A0 =C2=A0per host and the problems with not doing so.=C2=A0 It recommen= ds that
=C2=A0 =C2=A0networks provide general-purpose end hosts with multiple globa= l
=C2=A0 =C2=A0addresses when they attach, and lists current options for doin= g so.
=C2=A0 =C2=A0It does not specify any changes to protocols or end host behav= ior.

I think that reinforces and clarifies the scope by being explicit about wha= t is out-of scope.

Also you seem to frequently stray into talking about things from a host per= spective, instead of clearly a network perspective, this is probably confus= ing this issue a bit.

Generally, hosts "obtain" addresses, networks "provide"= addresses, "assigning" while correct, might be a little passive,= I think "providing" more clearly communicating a network perspec= tive.=C2=A0 So, a few specific suggestions for combating this host vs. netw= ork confusion;

1. Section 1, "Introduction", the last paragraph starts with &quo= t;This document describes the benefits of assigning multiple addresses per = host..." I think "This document describes the benefits of providi= ng multiple addresses per host..." would be more strongly focused on t= he network perspective.

2. Section 3 is is titled "Benefits of multiple addresses". "= ;Benefits of providing multiple addresses" is more clearly projects a = network perspective.

3. Section 4 is is titled "Problems with assigning a restricted number= of addresses per host", I think "Problems with restricting the n= umber of addresses per host" is stronger, but this one is a bit of a c= oin flip.

4. Section 6 is titled "Options for obtaining more than one address&qu= ot;, and starts with "Multiple IPv6 addresses can be obtained in...&qu= ot;.=C2=A0 This is clearly confusing the perspective and should be changed = to "Options for providing more than one address", and start with = "Multiple IPv6 addresses can be provided in..."

5. Section 9.3 in the middle paragraph; "...However, switching to a DH= CPv6 PD model with one /64 prefix per host resolves these scaling limitatio= ns..." And the last paragraph starts with; "Also, a DHCPv6 PD mod= el with a dedicated /64 per host makes...". Again these is a little pa= ssive, how about "... However, switching to a DHCPv6 PD model providin= g one /64 prefix per host resolves these scaling limitations.." and &q= uot;Also, a DHCPv6 PD model providing a dedicated /64 per host makes...&quo= t; is more actively about the network.

= Thanks. We've applied these suggestions in -04.

Yes, this is all true, but most people still have the impress= ion that DHCPv6 PD is primarily intended for configuring routers or CPE and= not hosts. If you read the introduction RFC 3633, it is easy to see why pe= ople have that impression.=C2=A0 Even the example you site is related to In= ternet Connection Sharing (ICS) where Windows is basically acting like a CP= E router. I'm not sure what to do about it though, but it probably shou= ldn't be ignored.

I added the follo= wing text to -04:

=C2=A0 =C2=A0 =C2=A0 While [RFC3= 633] assumes that the DHCPv6 client is a router, DHCPv6
=C2=A0 = =C2=A0 =C2=A0 PD itself does not require that the client forward IPv6 packe= ts
=C2=A0 =C2=A0 =C2=A0 not addressed to itself, and thus does no= t require that the client
=C2=A0 =C2=A0 =C2=A0 be an IPv6 router = as defined in [RFC2460].

Better?
=
--001a114f38b47574b20528798ca4-- From nobody Sun Jan 3 19:16:42 2016 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D43C1B2A43; Sun, 3 Jan 2016 19:16:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> Date: Sun, 03 Jan 2016 19:16:39 -0800 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 03:16:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Host address availability recommendations Authors : Lorenzo Colitti Vint Cerf Stuart Cheshire David Schinazi Filename : draft-ietf-v6ops-host-addr-availability-04.txt Pages : 13 Date : 2016-01-03 Abstract: This document recommends that networks provide general-purpose end hosts with multiple global IPv6 addresses when they attach, and describes the benefits of and the options for doing so. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-host-addr-availability/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-v6ops-host-addr-availability-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-host-addr-availability-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jan 3 19:26:24 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B50961B2A4B for ; Sun, 3 Jan 2016 19:26:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 OWXe82GC3nKq for ; Sun, 3 Jan 2016 19:26:20 -0800 (PST) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 409A11B2A4F for ; Sun, 3 Jan 2016 19:26:19 -0800 (PST) Received: by mail-yk0-x233.google.com with SMTP id x67so235615964ykd.2 for ; Sun, 03 Jan 2016 19:26:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=BpVhtIN++EbJwfvlyeQkOOIfmCAka9Pc7k6dyBgHtYY=; b=NMWTJIE4B3uljbi32Nk7xx7d2Vx5fDsJipR0XH1tkZkbNOtpOnRsTtk2pasZ8zgwGm YJuwcoBpjBZcGgfNPZr05ZT2mpsM3DnQnUVaZ5dFvtIUvIfPMe8xJ2IqzqViNXq/LmYt grDlgG7mddAfQMOXnU+NSPQ+EOF6Kt2lB1iAMGtUwIDdAM5TrRPYUYaMh2YasNe5DslT apPQycwSf8ZjT+v6jXXiwYN6FkswKUcCRPuD0C2LrjT7VINAzkUfDJDUBLCoDDzvrUV2 PCNH+gywg/2kTb1JYjZvphNcfaqnp+MQi1XH7aaXXY99tT3O7yMllUbxw0WOuk8KpahS sDWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=BpVhtIN++EbJwfvlyeQkOOIfmCAka9Pc7k6dyBgHtYY=; b=l50vunzC8th4qBFPKaZEYFZFcfHdIWgnn2AvUgb09vkJteuV72VldiewJlEIXKAVjy Bg7n+957WJ1ezg8TfgH/YmxTm9x8SyqLwVcxgAoK5R8quhyJCfWfP4KyY6lgMEtsgLPE IwtTehfd72JN6sk7AQdt2JOFfOd8QZQLIt0E/cOxHbzLNKD5nv26INTZSjNLIR42Ldt6 S27KNYWE5eTIreDn1pqDFy+G6GVshoQYquPUyRuOsuARpOTE5fLYW1iqNqTG9bQwGP9Q vhQyxeFlCN63e6AiBrkjrCb0UQONiDUPLazrQ4rLS0lgakZusktl+BgLgaugtAkCL1bp lW5Q== X-Gm-Message-State: ALoCoQlVl/TNdw/hn8i+9WSZ1iVDcDHjhRBZrX9GkQcj4yTlNkzVYe4iyVBFT1OFTF17NBSWtuU5IRY09HJG7VA1exvoCaSMzApMcWGPrS/BfqizoSZHonw= X-Received: by 10.13.205.199 with SMTP id p190mr70569662ywd.116.1451877978434; Sun, 03 Jan 2016 19:26:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.208.201 with HTTP; Sun, 3 Jan 2016 19:25:58 -0800 (PST) In-Reply-To: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> From: Lorenzo Colitti Date: Mon, 4 Jan 2016 12:25:58 +0900 Message-ID: To: internet-drafts Content-Type: multipart/alternative; boundary=001a114e5eb629f22f052879afc9 Archived-At: Cc: "v6ops@ietf.org WG" , i-d-announce@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 03:26:21 -0000 --001a114e5eb629f22f052879afc9 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 4, 2016 at 12:16 PM, wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 Operations Working Group of the > IETF. > > Title : Host address availability recommendations > Authors : Lorenzo Colitti > Vint Cerf > Stuart Cheshire > David Schinazi > Filename : draft-ietf-v6ops-host-addr-availability-04.txt > Pages : 13 > Date : 2016-01-03 > > [...] > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-host-addr-availability-04 Summary of the changes in this version : 1. The text about omitting DAD agreed with Fred Templin. 2. The suggestions from David Farmer to clarify the scope of the document: explicitly say that protocol changes and host behaviour are out of scope, reword "assign" to provide", etc. 3. A statement that while RFC 3633 talks about "requesting router", DHCPv6 PD itself doesn't actually require that the client forward packets, and thus does not require that the client be a router as defined in RFC 2460. Cheers, Lorenzo --001a114e5eb629f22f052879afc9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jan 4, 2016 at 12:16 PM, <internet-drafts@ietf.org> wrote:
A New Internet-Draft is available from the o= n-line Internet-Drafts directories.
=C2=A0This draft is a work item of the IPv6 Operations Working Group of the= IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Host address availability recommendations
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Lore= nzo Colitti
=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 Vint Cerf
=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 Stuart Cheshire
=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 David Schinazi
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-v6ops-host-addr-availability-04.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 13
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-01-03

[...]

A diff from the previous version is available at:
https://www.ietf.org/r= fcdiff?url2=3Ddraft-ietf-v6ops-host-addr-availability-04

Summary of the changes in this version :
    The text about omitting DAD agreed with Fred Templin.
  1. The sug= gestions from David Farmer to clarify the scope of the document: explicitly= say that protocol changes and host behaviour are out of scope, reword &quo= t;assign" to provide", etc.
  2. A statement that while RF= C 3633 talks about "requesting router", DHCPv6 PD itself doesn= 9;t actually require that the client forward packets, and thus does not req= uire that the client be a router as defined in RFC 2460.
Cheers,
Lorenzo=C2=A0
--001a114e5eb629f22f052879afc9-- From nobody Sun Jan 3 21:09:25 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52AEA1B2AFF for ; Sun, 3 Jan 2016 21:09:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.664 X-Spam-Level: * X-Spam-Status: No, score=1.664 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 KDvH36njADZ4 for ; Sun, 3 Jan 2016 21:09:23 -0800 (PST) Received: from vaadcmhout02.cable.comcast.com (unknown [96.114.28.76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AA471B2AF7 for ; Sun, 3 Jan 2016 21:09:23 -0800 (PST) X-AuditID: 60721c4c-f79d66d0000078a0-a6-5689fe81a30c Received: from VAADCEX13.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by vaadcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id 2F.A5.30880.18EF9865; Mon, 4 Jan 2016 00:09:21 -0500 (EST) Received: from VAADCEX09.cable.comcast.com (147.191.102.76) by VAADCEX13.cable.comcast.com (147.191.102.80) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Mon, 4 Jan 2016 00:09:20 -0500 Received: from VAADCEX09.cable.comcast.com ([fe80::3aea:a7ff:fe12:e2a0]) by VAADCEX09.cable.comcast.com ([fe80::3aea:a7ff:fe12:e2a0%19]) with mapi id 15.00.1130.005; Mon, 4 Jan 2016 00:09:20 -0500 From: "Brzozowski, John" To: "fred@cisco.com" , "v6ops@ietf.org" Thread-Topic: [v6ops] State of play Thread-Index: AQHRRJzHPy++4YQq5kecsWYXokuy/p7q0uYA Date: Mon, 4 Jan 2016 05:09:20 +0000 Message-ID: References: <201601011400.u01E0BqP025288@irp-lnx1.cisco.com> In-Reply-To: <201601011400.u01E0BqP025288@irp-lnx1.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [96.114.156.7] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOIsWRmVeSWpSXmKPExsWSUOxpodv4rzPMYE6rqcX7dWfYLE4f28vs wOQx5fdGVo8lS34yBTBFcdmkpOZklqUW6dslcGUsPfiCtaBLrKJz6QemBsYDol2MnBwSAiYS O162sUDYYhIX7q1n62Lk4hAS2MIkMfPdGkYIZz+jxIvZ3awgVUICJxglFr7IArHZBGwkXn/4 CVTEwSEi4CEx9bUUSFhYQEli0/N/TCC2iICyxJ1bm1khbCOJvwt+g8VZBFQkzlx/D2bzCthL LGt7ywQx3kZi35eFYDangK3E2SvfwHoZgY77fmoNWJxZQFzi1pP5TBBHC0gs2XOeGcIWlXj5 +B9YvaiAnsTuJ6cYIeI6EmevP4GyDSS2Lt0H9bCCRM+E6cwg5zMLaEqs36UPMd5B4vbZa1Cr FCWmdD9khzhTUOLkzCdQreISh4/sYJ3AKD0LyUWzECbNQjJpFpJJs5BMWsDIuopRriwxMSU5 NyO/tMTASC85MSknVS85Pzc5sbgERG9iBEV3kYzPDsZP0zwOMQpwMCrx8Cb87gwTYk0sK67M PcQowcGsJML7/gRQiDclsbIqtSg/vqg0J7X4EKM0B4uSOG9oqH+YkEB6YklqdmpqQWoRTJaJ g1OqgTFsT8zlyZcMTpVXzTm0WT00+g1HcGuEZep75+pIzyeuc1ruPgiJvWeWkuK+uNjlwWKL Lu01+xclCC00zsr5m861bWJodJDlae7vT3mrZ/5fF5ylre+QJxu5zYfjrv7ut9Emx9WdjNSe XJphdLNWoae12+nO+RdmVoKJ4m9+bt5+6JeZ+pm+5UosxRmJhlrMRcWJAFVr9L3qAgAA Archived-At: Subject: Re: [v6ops] State of play X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 05:09:24 -0000 RnJlZCwNCg0KSnVzdCB0byBiZSBjbGVhciwgdGhlIGZvbGxvd2luZzoNCg0KMjAxNS0xMC0xOQlk cmFmdC1qam1iLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdA0KDQpXaWxsIG5vIGxv bmdlciBiZSB1cGRhdGVkIHNpbmNlIGl0IHdhcyBhY2NlcHRlZCBhcyBhIFdHIGRvY3VtZW50Og0K DQogMjAxNS0xMS0wMQlkcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9z dA0KDQpXZSBwbGFuIHRvIG1ha2UgdXBkYXRlcyBiYXNlZCBvbiB0aGUgbGFzdCBXRyBtZWV0aW5n IGFuZCBlbWFpbCBjb21tZW50cw0KZm9yIHRoZSBuZXh0IElFVEYuDQoNCg0KSm9obg0KKzEtNDg0 LTk2Mi0wMDYwDQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiB2Nm9w cyA8djZvcHMtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEZyZWQgQmFrZXINCjxmcmVk QGNpc2NvLmNvbT4NCkRhdGU6IEZyaWRheSwgSmFudWFyeSAxLCAyMDE2IGF0IDA5OjAwDQpUbzog djZvcHMgPHY2b3BzQGlldGYub3JnPg0KU3ViamVjdDogW3Y2b3BzXSBTdGF0ZSBvZiBwbGF5DQoN Cj5SRkMgRWRpdG9yOiBFRElUDQo+CTIwMTUtMTEtMjMJZHJhZnQtaWV0Zi12Nm9wcy1yZWR1Y2lu Zy1yYS1lbmVyZ3ktY29uc3VtcHRpb24NCj4JMjAxNS0xMC0yNglkcmFmdC1pZXRmLXY2b3BzLXNp aXQtZGMNCj4JMjAxNS0xMC0yNglkcmFmdC1pZXRmLXY2b3BzLXNpaXQtZGMtMnhsYXQNCj4JMjAx NS0xMC0yNglkcmFmdC1pZXRmLXY2b3BzLXNpaXQtZWFtDQo+DQo+UkZDIEVkaXRvcjogSW4gSVNF IFJldmlldw0KPgkyMDE1LTEyLTE3CWRyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9m aWxlDQo+DQo+UkZDIEVkaXRvcjogUkZDLUVESVRPUg0KPgkyMDE1LTEwLTE5CWRyYWZ0LWlldGYt djZvcHMtcG10dWQtZWNtcC1wcm9ibGVtDQo+DQo+V0c6IFVudXBkYXRlZCBXRyBEb2N1bWVudA0K PgkyMDE1LTEwLTE5CWRyYWZ0LWlldGYtdjZvcHMtZGVzaWduLWNob2ljZXMNCj4JMjAxNS0wNy0w NglkcmFmdC1pZXRmLXY2b3BzLWRoY3B2Ni1zbGFhYy1wcm9ibGVtDQo+DQo+V0c6IFVwZGF0ZWQg V0cgRG9jdW1lbnQNCj4JMjAxNS0xMi0xMAlkcmFmdC1pZXRmLXY2b3BzLWhvc3QtYWRkci1hdmFp bGFiaWxpdHkNCj4JMjAxNS0xMS0wMQlkcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZp eC1wZXItaG9zdA0KPg0KPldHOiBXRyBDb25zZW5zdXM6IFdhaXRpbmcgZm9yIFdyaXRlLVVwDQo+ CTIwMTUtMTItMTEJZHJhZnQtaWV0Zi12Nm9wcy1pcHY2LWVocy1pbi1yZWFsLXdvcmxkDQo+DQo+ SW5kaXZpZHVhbCBTdWJtaXNzaW9uOiBVbnVwZGF0ZWQNCj4JMjAxNS0xMC0xOQlkcmFmdC1qam1i LXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdA0KPgkyMDE1LTEwLTE5CWRyYWZ0LXh1 LXY2b3BzLWRzbGl0ZS1yZWR1bmRhbmN5DQo+CTIwMTUtMTAtMTUJZHJhZnQtZ29udC12Nm9wcy1p cHY2LWVocy1wYWNrZXQtZHJvcHMNCj4JMjAxNS0xMC0xMAlkcmFmdC1iYW8tdjZvcHMtcmZjNjE0 NWJpcw0KPgkyMDE1LTA5LTIxCWRyYWZ0LXliYWktdjZvcHMtaXB2Ni1mb3Itb3BlbnN0YWNrDQo+ CTIwMTUtMDctMDYJZHJhZnQtYWtpcmEtdjZvcHMtbWFwZS1leHBlcmllbmNlDQo+CTIwMTUtMDct MDYJZHJhZnQteGNmLXY2b3BzLWNoaW5hdGVsZWNvbS1kZXBsb3ltZW50DQo+CTIwMTUtMDctMDUJ ZHJhZnQtaHVpLXY2b3BzLWlwdjZ0cmFucy1zZWxlY3QtbmZ2DQo+CTIwMTUtMDctMDUJZHJhZnQt eGxpLXY2b3BzLWNlcm5ldC1kZXBsb3ltZW50DQo+CTIwMTUtMDctMDUJZHJhZnQteWFuZy12Nm9w cy1pcHY2dHJhbi1zZWxlY3QNCj4NCj5JbmRpdmlkdWFsIFN1Ym1pc3Npb246IFVwZGF0ZWQNCj4J MjAxNS0xMS0wNQlkcmFmdC10ZW1wbGluLXY2b3BzLXBkaG9zdA0KPg0KPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+djZvcHMgbWFpbGluZyBsaXN0DQo+ djZvcHNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2 b3BzDQo+DQoNCg== From nobody Sun Jan 3 21:37:24 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B08E1A0334 for ; Sun, 3 Jan 2016 21:37:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.511 X-Spam-Level: X-Spam-Status: No, score=0.511 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 uAz1c5oAZuIf for ; Sun, 3 Jan 2016 21:37:20 -0800 (PST) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 347AD1A0318 for ; Sun, 3 Jan 2016 21:37:19 -0800 (PST) Received: by mail-yk0-x22c.google.com with SMTP id v14so144756294ykd.3 for ; Sun, 03 Jan 2016 21:37:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=yHLF2f7cyig3y440hSgfLqqZlIqzQG79KjaGvbtTN3Q=; b=PYQFamEJrpzajJaYtw0qjgfSeqKIz3DQ3oPsTRcTAFs8XfrzJ4SyKWvSdPQI71QZ9L p+rc5SoBm587qm/uKouFzwrnO5m0udX8YQThaz3OCRvZshGB2Opq6QHhKpt7KS6c3QFU VNgcktoIY3iUWHdwwTn/4SHeFX0tcYyTtV8xduuVi/O8h8OMQo39eqZUG4a7OWe8c13u 00w1kLVi12xXb52QJVKzAxFS2DKaZi63UsYPyzccTXxuxNGozPrYBNRsiCnnN2VLLgUn vm1pVgsqE09opLniK1adt90ivxLYHPgMaulJh+JxnQs5F1Rd3OP8TSNHthB1z4rk8DvA DdGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=yHLF2f7cyig3y440hSgfLqqZlIqzQG79KjaGvbtTN3Q=; b=PSiTj+WlrXrGZhEWD7/IyjEBuBNrmUnQfrMdt0HjrYLSLLQSHxEjGcgiMa6oDNXYS9 QczdWnnM1ojTjqQ7wxK2kbcF/ClrRycaiUGp8F9I7uWTTQxNhN4+hzK9AzUcBVMmtA6T hzD0+5TCNgSZGC78KlDw9iSytXBRt2D8QePlK/BqUuh89w7POEMUsp/QONP7leo7P/+q I0O5eFsJ8u07JWYvxh+MDPA9xhE855VO3VqhoBeDuN5zLvbTtnzNe5omVInossieG4Ns BtHT3IZCN8xn7YfkRmlYVG4vWZ77Z+vzJ8XMcB34yU7+EtZM18k8axp+BOMRSUQaLDh4 St7Q== X-Gm-Message-State: ALoCoQmpDxC40zGuokWzr09vAtlnAh8SFzecz5Cz5ignYF8JFZk6IvBBiCfcScR8IcTQT2E0Y7GQLC2V4Fjm8I7oQq7H4qsgBwAhMewaiJReN7dXXDlGfAE= X-Received: by 10.13.205.199 with SMTP id p190mr70874124ywd.116.1451885839030; Sun, 03 Jan 2016 21:37:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.208.201 with HTTP; Sun, 3 Jan 2016 21:36:59 -0800 (PST) In-Reply-To: <201601031900.u03J0LMe009763@irp-lnx1.cisco.com> References: <201601031900.u03J0LMe009763@irp-lnx1.cisco.com> From: Lorenzo Colitti Date: Mon, 4 Jan 2016 14:36:59 +0900 Message-ID: To: draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org Content-Type: multipart/alternative; boundary=001a114e5eb6b11f0b05287b830f Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 05:37:22 -0000 --001a114e5eb6b11f0b05287b830f Content-Type: text/plain; charset=UTF-8 On Mon, Jan 4, 2016 at 4:00 AM, wrote: > And now for something a little different. I'd like to invite focused > discussion of draft-ietf-v6ops-unique-ipv6-prefix-per-host, which we > adopted at IETF 94 > > Slides are at > https://www.ietf.org/proceedings/94/slides/slides-94-v6ops-4.pdf. > As I said before, I think it's a great approach. The alternative/current approach of IPv6 on wifi relies on sharing a /64 between untrusted devices belonging to lots of different customers. That is a security nightmare that ends up in the network having to maintain lots of state and perform lots of layering violations (DAD proxying, ND snooping, etc.) This is much better - everything is plain layer 3 with no hacks, and the user gets a full /64. Comments: The draft is targeted to BCP but it is also a description of a particular solution. That doesn't work well in some places, notably where it says that the solution uses a captive portal. I don't think there will be consensus to say that a captive portal is BCP compared to, say, 802.1x, hotspot 2.0, etc. I think its BCP status should be limited to public wifi networks or in general for networks where subscriber isolation is a strong requirement. This is not applicable to home networks, for example; many home networks don't provide address space in most home networks to support it. I'd like this draft to cite draft-ietf-v6ops-host-addr-availability, since /64 per host is not only simpler for the operator, it's better for hosts as well. On a related note, please remove all mention of the singular "IPv6 address" or "/128 address". Many (all?) common implementations configure both stable and privacy addresses by default, so that text is incorrect. For example, change "to select its /128 unique address" to "form global IPv6 addresses". Also change "it will assign itself a 128 bit IPv6 address using SLAAC" to "it will form one or more IPv6 addresses using SLAAC". This happens in lots of places. The draft should be a bit more explicit on whether communication between devices is allowed (I assume yes?), and if so, how (I assume the packet is tunneled to WLAN-GW and then tunneled back to the other device?). The draft recommends an RA interval of 300s and preferred lifetime of 1800s. But draft-ietf-v6ops-reducing-ra-energy-consumption recommends "approximately 7 RAs per hour", and lifetimes of "roughly 45-90 minutes". The two should be made consistent, or the difference should be justified. We shouldn't be putting out two BCPs with different recommendations. I don't understand the text "To accomodate this the WLAN-GW can periodically perform a Subscriber Host Connectivity Verification (i.e. periodically ping each IPv6 UE...)". It seems to me that the the whole point of this approach is that the WLAN-GW doesn't need to know the individual IPv6 addresses formed by the hosts. Also, there's no guarantee that devices will respond to ping. I think better solutions are: - - The AP could inform the WLAN-GW of when a subscriber disappeared. - The WLAN-GW could time out any GRE interface that had not received any packets in the last X minutes, or if the customer's /64 prefix had not originated any packets in the last X minutes. Again, the "subscriber host connectivity" solution would be fine in an informational document describing a particular solution, but not for a BCP. Cheers, Lorenzo --001a114e5eb6b11f0b05287b830f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jan 4, 2016 at 4:00 AM, <fred@cisco.com> wrote:
And now for something a little different. I'd like to invite = focused
discussion of draft-ietf-v6ops-unique-ipv6-prefix-per-host, which we
adopted at IETF 94

Slides are at
https://www.ietf.org/proceedings/94/= slides/slides-94-v6ops-4.pdf.

As I = said before, I think it's a great approach. The alternative/current app= roach of IPv6 on wifi relies on sharing a /64 between untrusted devices bel= onging to lots of different customers. That is a security nightmare that en= ds up in the network having to maintain lots of state and perform lots of l= ayering violations (DAD proxying, ND snooping, etc.) This is much better - = everything is plain layer 3 with no hacks, and the user gets a full /64.

Comments:

The draft is targ= eted to BCP but it is also a description of a particular solution. That doe= sn't work well in some places, notably where it says that the solution = uses a captive portal. I don't think there will be consensus to say tha= t a captive portal is BCP compared to, say, 802.1x, hotspot 2.0, etc. I thi= nk its BCP status should be limited to public wifi networks or in general f= or networks where subscriber isolation is a strong requirement. This is not= applicable to home networks, for example; many home networks don't pro= vide address space in most home networks to support it.

I'd like this draft to cite draft-ietf-v6ops-host-addr-availabili= ty, since /64 per host is not only simpler for the operator, it's bette= r for hosts as well. On a related note, please remove all mention of the si= ngular "IPv6 address" or "/128 address". Many (all?) co= mmon implementations configure both stable and privacy addresses by default= , so that text is incorrect. For example, change "to select its /128 u= nique address" to "form global IPv6 addresses". Also change = "it will assign itself a 128 bit IPv6 address using SLAAC" to &qu= ot;it will form one or more IPv6 addresses using SLAAC". This happens = in lots of places.

The draft should be a bit more = explicit on whether communication between devices is allowed (I assume yes?= ), and if so, how (I assume the packet is tunneled to WLAN-GW and then tunn= eled back to the other device?).

The draft recomme= nds an RA interval of 300s and preferred lifetime of 1800s. But draft-ietf-= v6ops-reducing-ra-energy-consumption recommends "approximately 7 RAs p= er hour", and lifetimes of "roughly 45-90 minutes". The two = should be made consistent, or the difference should be justified. We should= n't be putting out two BCPs with different recommendations.
<= br>
I don't understand the text "To accomodate this the = WLAN-GW can periodically perform a Subscriber Host Connectivity Verificatio= n (i.e. periodically ping each IPv6 UE...)". It seems to me that the t= he whole point of this approach is that the WLAN-GW doesn't need to kno= w the individual IPv6 addresses formed by the hosts. Also, there's no g= uarantee that devices will respond to ping. I think better solutions are:
  • The AP could inform the WLAN-GW of when a subscri= ber disappeared.
  • The WLAN-GW could time out any GRE interface t= hat had not received any packets in the last X minutes, or if the customer&= #39;s /64 prefix had not originated any packets in the last X minutes.
    • =
Again, the "subscriber host connectivity" solution would be = fine in an informational document describing a particular solution, but not= for a BCP.

Cheers,
Lorenzo
<= /div>
--001a114e5eb6b11f0b05287b830f-- From nobody Sun Jan 3 21:54:25 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 082F51A1B89 for ; Sun, 3 Jan 2016 21:54:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.308 X-Spam-Level: X-Spam-Status: No, score=-4.308 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 2SKZ1jsJkniH for ; Sun, 3 Jan 2016 21:54:23 -0800 (PST) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.119.120]) by ietfa.amsl.com (Postfix) with ESMTP id 863C81A1B8A for ; Sun, 3 Jan 2016 21:54:23 -0800 (PST) Received: from mail-io0-f170.google.com (mail-io0-f170.google.com [209.85.223.170]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128/128); for ; Sun, 3 Jan 2016 23:54:20 -0600 (CST) X-Umn-Remote-Mta: [N] mail-io0-f170.google.com [209.85.223.170] #+LO+TS+TR X-Umn-Classification: local Received: by mail-io0-f170.google.com with SMTP id 1so99907785ion.1 for ; Sun, 03 Jan 2016 21:54:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:from:subject:date:to; bh=ymg9eBDFXb8RzwyeX/wzCnHtOuNB1ncHvI2S6vBcG/4=; b=kSIYKWI5xH27T/gk8EpNQVvA9ldr7qB3bfr/VuT2KY4xwmWDAD0WeJSQZBnD7CnRZi gAkVIWfbV9RR+aNNyEEMCpspPh8OGzgq/hc1leKi+vCIRUu/TGbmEmgfEPEMHXm67gM4 WZ3EhhPpK89VkrOfyyZkOyt4eAOJLGxIDm/hc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:from:subject :date:to; bh=ymg9eBDFXb8RzwyeX/wzCnHtOuNB1ncHvI2S6vBcG/4=; b=QK4YCRUTrRVkbsVaKIDWwMhxZKTcJ9TmRkzxThPUmZYputj1Iddze5N6+NyFJZ8Cr/ jLAOfMXo2NBlkaL+kt1nP2AyHvWd56ZATKj2Xhks8281py5/QjTTREktvh71NAoDx3dB +AfsrnjDQPFxGQQ85sp4+zvb+ij13rZfwhK5Bc7lzqP9euF0kkGLYbc2lAs59IV724y3 7/MOnv1bF9bLRDilxtQKhRgs1DrjztpMAB3xv+wh9TrUMiAI3UwcA+UMZ7YTYjWJ8bGO Q4zVI7vZ12yCk75Jyg+0MV/wvvpmihueE45vZ2ZPXzXzsc/zd2+1bk5tV4xXud9HLq3K 5rXg== X-Gm-Message-State: ALoCoQmlhQOh0Qi23smok+RFs+yESSoCWSTPEvT/AglJ5sRgJ8qAIoAYnQbpmIWOisNLkonDiHp+OkL4GJFrKzPCIgg2961cph0juroa1M/wwS57nLuWCM2t/NQgPVG2JMO9736fCNeeX8QOsy8Idw+SiR0YyV9U3w== X-Received: by 10.107.133.211 with SMTP id p80mr77201663ioi.16.1451886859451; Sun, 03 Jan 2016 21:54:19 -0800 (PST) X-Received: by 10.107.133.211 with SMTP id p80mr77201654ioi.16.1451886859301; Sun, 03 Jan 2016 21:54:19 -0800 (PST) Received: from [10.0.0.7] (c-68-47-68-88.hsd1.mn.comcast.net. [68.47.68.88]) by smtp.gmail.com with ESMTPSA id jc1sm29996335igb.7.2016.01.03.21.54.17 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 03 Jan 2016 21:54:17 -0800 (PST) References: <20151210151847.2475.78959.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F8786C@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F8B3B5@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F8B8E9@XCH-BLV-504.nw.nos.boeing.com> <56725836.7070609@umn.edu> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-CD8B8123-CE67-40BC-9CE2-FF2D02BE647D Message-Id: X-Mailer: iPad Mail (13C75) From: David Farmer Date: Sun, 3 Jan 2016 23:54:15 -0600 To: Lorenzo Colitti Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Calling the question: draft-ietf-v6ops-host-addr-availability-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 05:54:25 -0000 --Apple-Mail-CD8B8123-CE67-40BC-9CE2-FF2D02BE647D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota =20 2218 University Ave SE Phone: +1-612-626-0815 Minneapolis, MN 55414-3029 Cell: +1-612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > On Jan 3, 2016, at 21:16, Lorenzo Colitti wrote: >> On Thu, Dec 17, 2015 at 3:37 PM, David Farmer wrote: >> Yes, this is all true, but most people still have the impression that DHC= Pv6 PD is primarily intended for configuring routers or CPE and not hosts. I= f you read the introduction RFC 3633, it is easy to see why people have that= impression. Even the example you site is related to Internet Connection Sh= aring (ICS) where Windows is basically acting like a CPE router. I'm not sur= e what to do about it though, but it probably shouldn't be ignored. >=20 > I added the following text to -04: >=20 > While [RFC3633] assumes that the DHCPv6 client is a router, DHCPv6 > PD itself does not require that the client forward IPv6 packets > not addressed to itself, and thus does not require that the client > be an IPv6 router as defined in [RFC2460]. >=20 > Better? Yes, that helps a lot. A suggestion, use it if you like, I think what you have is sufficient, I jus= t think this would be even better: While [RFC3633] refers to the DHCPv6 client is a "requesting router", ...= . Also, we should make sure similar clarifying language gets into rfc3315bis w= hich as far as I can tell will incorporate and obsolete RFC3633. Thanks. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota =20 2218 University Ave SE Phone: +1-612-626-0815 Minneapolis, MN 55414-3029 Cell: +1-612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --Apple-Mail-CD8B8123-CE67-40BC-9CE2-FF2D02BE647D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable



-- 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer                 &= nbsp;        Email: fa= rmer@umn.edu
Office of Information Technology
Univer= sity of Minnesota    
2218 University Ave SE   &nbs= p;     Phone: +1-612-626-0815
Minneapolis, MN 55414-3029=   Cell: +1-612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D

On Jan 3, 2016, at 21:= 16, Lorenzo Colitti <lorenzo@google= .com> wrote:
On Thu, Dec 17, 2015 at 3:= 37 PM, David Farmer <farmer@umn.edu> wrote:
Yes, this is all true, but most p= eople still have the impression that DHCPv6 PD is primarily intended for con= figuring routers or CPE and not hosts. If you read the introduction RFC 3633= , it is easy to see why people have that impression.  Even the example y= ou site is related to Internet Connection Sharing (ICS) where Windows is bas= ically acting like a CPE router. I'm not sure what to do about it though, bu= t it probably shouldn't be ignored.

I ad= ded the following text to -04:

     = While [RFC3633] assumes that the DHCPv6 client is a router, DHCPv6
      PD itself does not require that the client forward IP= v6 packets
      not addressed to itself, and thus d= oes not require that the client
      be an IPv6 ro= uter as defined in [RFC2460].

Better?

Yes, that helps a lot.

A sugg= estion, use it if you like, I think what you have is sufficient, I just thin= k this would be even better:

   While [RFC= 3633] refers to the

Also, we should make s= ure similar clarifying language gets into rfc3315bis which as far as I can t= ell will incorporate and obsolete RFC3633.

Thanks.
<= div>-- 
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer    = ;                     &nbs= p;Email: farmer@umn.edu
Office of Infor= mation Technology
University of Minnesota    
2218 University Ave SE=         Phone: +1-612-626-0815
Minneapolis, MN 55414-302= 9   Cell: +1-612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

= --Apple-Mail-CD8B8123-CE67-40BC-9CE2-FF2D02BE647D-- From nobody Mon Jan 4 00:03:50 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAD761A21A0 for ; Mon, 4 Jan 2016 00:03:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 dciAG01T3sLs for ; Mon, 4 Jan 2016 00:03:48 -0800 (PST) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0DCE1A0056 for ; Mon, 4 Jan 2016 00:03:47 -0800 (PST) Received: by mail-yk0-x22d.google.com with SMTP id x67so239750568ykd.2 for ; Mon, 04 Jan 2016 00:03:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5MNX+TqvHiIRHQCiCKma4ld8R/F46lHvHDjm91nVgVA=; b=cM6B0eXdeZZRnHdcHfMp4xQhtRuD0prgHy8yLItrpV2x1HS6qsFOzf918+Fjb9bub7 RZBz7lau9e5C6CLJHVw3jRZIlfyqMxkJQyoxlcUKelp8lhAJoqTKpEoPhycByyDWp3HT oqfORlbkaraFaamHu9+Z7C6UX/MMlXFyLXUU05PVXRr+MrsqJFxuAAJwIELuZS9x6mOe Ei/lqNoFZ8pEBEGiQRSby4poRDryUm0SSGWM0dF5OFmHxm7DH8QOHtsDa0E3NXijXuyu YgMxexFtytrYN4Bs4zW11pXCccW3t8vQkylqAZ2T7FxOj0p0zkTTJ1SK09bph7YvSu5r vqMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=5MNX+TqvHiIRHQCiCKma4ld8R/F46lHvHDjm91nVgVA=; b=C1YS9ZS1SpDi4vuo52e9AnTHtC3x51gzm2ZRBWU2nirLcCxXUzEaxa7fXD0Fgvv8nW LFPwFFt5vctk44mVO7WxsqILktq5tMfrwbXwCPHcBx52Ebk/cIFS+OwHdYhgcdbDBSj3 28+DUxt3XJZ+wWSzxkEIO620iFrRvoUmSUUZysV/PeTEDGhY4d0JIPnsE8OEuYhjzTUU 7uI1kUEC8f392V36XqTKX7UD0zZ7VC+qPgHV4ZGct7VBpJVrsd0omnuACWMdZFZkAAn3 jvYYB+lcXAA9V34I6tpSLnOVW39Qi/zK7IZe9xXJPOl+ZmksttkEK/XPIiNdgpsxWJqj 9Smg== X-Gm-Message-State: ALoCoQmkus95qKGFTfmIyYA9ON2EmeDc5mw2Kot0AE5qZzMaeeQ/2c/mLT8ECdnpuOjDPkKB+twsUgUHcEVoypvPeUjKClX9LmjERjSaG6xz36n3AhkB5fM= X-Received: by 10.129.45.137 with SMTP id t131mr58788527ywt.337.1451894627011; Mon, 04 Jan 2016 00:03:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.208.201 with HTTP; Mon, 4 Jan 2016 00:03:27 -0800 (PST) In-Reply-To: <336255C7-CC6E-43EC-AE53-F771D91703D5@alcatel-lucent.com> References: <201601031900.u03J0LMe009763@irp-lnx1.cisco.com> <336255C7-CC6E-43EC-AE53-F771D91703D5@alcatel-lucent.com> From: Lorenzo Colitti Date: Mon, 4 Jan 2016 17:03:27 +0900 Message-ID: To: "VAN DE VELDE, Gunter (Gunter)" Content-Type: multipart/alternative; boundary=001a1141e9b67f1e7b05287d8f98 Archived-At: Cc: "v6ops@ietf.org WG" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org" Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 08:03:49 -0000 --001a1141e9b67f1e7b05287d8f98 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 4, 2016 at 4:49 PM, VAN DE VELDE, Gunter (Gunter) < gunter.van_de_velde@alcatel-lucent.com> wrote: > > - The AP could inform the WLAN-GW of when a subscriber disappeared. > - The WLAN-GW could time out any GRE interface that had not received > any packets in the last X minutes, or if the customer's /64 prefix had not > originated any packets in the last X minutes. > > <>end snip<> > > Yes, this process is indeed a mistake in added in this text. What is > happening in reality is a ND exchange check if the subscriber is still > alive. > But even for an ND exchange, the WLAN-GW needs to keep state on the IPv6 address(es) used by the client. Which one? It can't use the global addresses, since to find out what they are it would have to resort to ugly hacks like DAD snooping or traffic snooping - and even then there is no reliable way to know if an address has been deleted by the host (e.g., if a privacy address timed out). I suppose it could use the link-local address that was used to send the RS (on the assumption that link-local addresses never change), but if so, the draft should document it explicitly. --001a1141e9b67f1e7b05287d8f98 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jan 4, 2016 at 4:49 PM, VAN DE VELDE, Gunter (Gunter) <gunter.van_de_velde@alcatel-lucent.com> wrote:
  • The AP could inform the WLAN-GW of when = a subscriber disappeared.
  • The WLAN-GW could time out any GRE interface that had not received= any packets in the last X minutes, or if the customer's /64 prefix had= not originated any packets in the last X minutes.
<>end snip<>

Yes, this process is indeed a mistake in added in this text. What is h= appening in reality is a ND exchange check if the subscriber is still alive= .

But even for an ND exchange,= the WLAN-GW needs to keep state on the IPv6 address(es) used by the client= .

Which one? It can't use the global addresses= , since to find out what they are it would have to resort to ugly hacks lik= e DAD snooping or traffic snooping - and even then there is no reliable way= to know if an address has been deleted by the host (e.g., if a privacy add= ress timed out).

I suppose it could use the link-l= ocal address that was used to send the RS (on the assumption that link-loca= l addresses never change), but if so, the draft should document it explicit= ly.
--001a1141e9b67f1e7b05287d8f98-- From nobody Mon Jan 4 04:41:44 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAF8B1A885C for ; Mon, 4 Jan 2016 04:41:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-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 GF9F-BFPtW6F for ; Mon, 4 Jan 2016 04:41:40 -0800 (PST) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E06421A885B for ; Mon, 4 Jan 2016 04:41:39 -0800 (PST) Received: from [2a02:c0:2:1:1194:17:0:1029] (port=40024 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1aG4S7-000503-QM; Mon, 04 Jan 2016 13:41:35 +0100 Date: Mon, 4 Jan 2016 13:41:35 +0100 From: Tore Anderson To: fred@cisco.com Message-ID: <20160104134135.1f1b3711@echo.ms.redpill-linpro.com> In-Reply-To: <201601031900.u03J0LMe009763@irp-lnx1.cisco.com> References: <201601031900.u03J0LMe009763@irp-lnx1.cisco.com> X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.29; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 12:41:42 -0000 * fred@cisco.com > And now for something a little different. I'd like to invite focused > discussion of draft-ietf-v6ops-unique-ipv6-prefix-per-host, which we > adopted at IETF 94 FWIW, I sent some feedback to the list on the 28th of October, which wasn't answered* or incorporated in the new revision of the draft as far as I can tell. I'll therefore repeat them below. * Except for point #2 regarding the draft improperly suggesting that when IA_PD is available the M-flag should be set to 1. This did cause some discussion on whether or not RA flags have any relation to IA_PD availability to begin with, but I don't think there was any disagreement about my initial point about tying IA_PD with the M-flag specifically not being appropriate. Easiest way to fix this in the draft is IMHO just to remove =C2=AB, this flag may be set to 1 in the future if/when DHCPv6 prefix this flag may be set to 1 in the future if/when DHCPv6 prefix)=C2=BB. (Just noticed this will also get rid of an unmatched parenthesis.) Tore ------ 1) Section 4.2 mentions that DAD is used, but it is not clear to me how this will work for LLAs. If two UEs (potentially attached to different APs) are using the same link-local address, how will they see each others DAD messages? Proxy-ND on the WLAN-GW? Or if the WLAN-GW does not relay DAD messages across the split BUM horizon, how will it deal with the possiblity of two unique UEs both using the same LLA? I'm guessing that in a large-scale deployment, the chances of two UEs having statically configured, e.g., fe80::1 is quite likely. 2) Regarding the following text in Section 4.2: > o M-flag =3D 0 (UE/subscriber address is not managed through DHCPv6), > this flag may be set to 1 in the future if/when DHCPv6 prefix > delegation support over Wi-Fi is desired) =20 As I understand it (and I do stress that), the M-flag indicates whether or not *addresses* are available via DHCPv6 (RFC 4861 s4.2). Prefixes (IA_PD) is something different. Therefore, assuming that availability of IA_PD is signalled using RA flags to begin with, then it is "other configuration" and thus signalled with the O-flag, not the M-flag. I know of at least one wireline ISP that has such a deployment, i.e., they support DHCPv6 IA_PD but not IA_NA/IA_TA, and they signal this using M=3D0 + O=3D1. 3) The draft describes tunneling traffic in a stateless manner. I take that to mean that the APs and WLAN-GW will be incapable of performing reassembly at tunnel egress (and by extension that they won't fragment GRE packets on ingress either). That in turn means that you either 1) need to allow for jumbo frames in the transport network between the WLAN-GW and the APs, or 2) provide UEs with a reduced MTU (which implies the RA MTU option should be used and possibly also TCP-MSS clamping at the WLAN-GW). Since this is an operational guidance document I believe this is something that should be discussed. 4) Is UE roaming between APs/BSSIDs supported, and if so how does this work? As I understand it, the WLAN-GW will have 1 GRE interface per AP, so if a UE roams from one AP to another, its MAC address and all of its associated IPv6 addresses will (from the WLAN-GW's POV) move from one GRE interface to another, which would in turn require the WLAN-GW to somehow notice this and move the associated /64 and any NDP entries from the previous GRE interface to the current one. Right? If so, some discussion on how that happens would be appreciated (or at least a statement that "secret vendor sauce is assumed to be applied here" if that is indeed the case). 5) This is just a thought, but regarding the operational consideration in section 5 regarding supporting privacy addresses: Would it be possible for the WLAN-GW to simply send all traffic destined for the UE's dedicated /64 to the UE's MAC address without maintaining ND entries for each address in use? This way, a single UE could use gazillions of IPv6 addresses without risking resource exhaustion in the WLAN-GW. OTOH, maybe that would cause problems for UEs that are providing tethering to downstream hosts using layer-2 bridging? 6) Some editorial nits I noticed (although I wasn't specifically looking for them): Missing =C2=AB.=C2=BB at the end of page 7, s/Lawfull/La= wful/ on page 12. From nobody Mon Jan 4 04:42:24 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09EEA1A8869 for ; Mon, 4 Jan 2016 04:42:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7We-dB0CsZgY for ; Mon, 4 Jan 2016 04:42:21 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AB3F1A8963 for ; Mon, 4 Jan 2016 04:42:10 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u04Cg7M7018358 for ; Mon, 4 Jan 2016 13:42:07 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D0BF4203F5C for ; Mon, 4 Jan 2016 13:49:31 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C8AF7203F55 for ; Mon, 4 Jan 2016 13:49:31 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u04Cg7Qg023233 for ; Mon, 4 Jan 2016 13:42:07 +0100 To: v6ops@ietf.org References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> From: Alexandre Petrescu Message-ID: <568A689F.4060204@gmail.com> Date: Mon, 4 Jan 2016 13:42:07 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 12:42:23 -0000 Le 04/01/2016 04:25, Lorenzo Colitti a écrit : > On Mon, Jan 4, 2016 at 12:16 PM, > wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 Operations Working Group of > the IETF. > > Title : Host address availability recommendations > Authors : Lorenzo Colitti > Vint Cerf > Stuart Cheshire > David Schinazi > Filename : > draft-ietf-v6ops-host-addr-availability-04.txt > Pages : 13 > Date : 2016-01-03 > > [...] > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-host-addr-availability-04 > > > Summary of the changes in this version : > > 1. The text about omitting DAD agreed with Fred Templin. > 2. The suggestions from David Farmer to clarify the scope of the > document: explicitly say that protocol changes and host behaviour > are out of scope, reword "assign" to provide", etc. > 3. A statement that while RFC 3633 talks about "requesting router", > DHCPv6 PD itself doesn't actually require that the client forward > packets, and thus does not require that the client be a router as > defined in RFC 2460. Lorenzo - I noticed earlier emails where a doubt about DHCP-PD RFC relying on these to be Routers, or not. I agree with you the DHCP-PD RFC calls them Routers. It may rightfully not go too deep into requiring them to forward packets or maintain a FIB. It would be too many things to require. Maybe just calling them Routers is sufficient, for brevity. At the same time, certainly DHCP-PD RFC is not specified with Hosts in mind and this is not good. Alex > Cheers, > Lorenzo > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Jan 4 05:39:26 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 986A61A88C4 for ; Mon, 4 Jan 2016 05:39:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.665 X-Spam-Level: * X-Spam-Status: No, score=1.665 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.793, 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 3igxSIFnJzEa for ; Mon, 4 Jan 2016 05:39:22 -0800 (PST) Received: from vaadcmhout01.cable.comcast.com (unknown [96.114.28.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF6701A88C3 for ; Mon, 4 Jan 2016 05:39:21 -0800 (PST) X-AuditID: 60721c4b-f79fb6d00000348f-ef-568a7608ab53 Received: from VAADCEX13.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by vaadcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id 51.73.13455.8067A865; Mon, 4 Jan 2016 08:39:20 -0500 (EST) Received: from VAADCEX09.cable.comcast.com (147.191.102.76) by VAADCEX13.cable.comcast.com (147.191.102.80) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Mon, 4 Jan 2016 08:39:19 -0500 Received: from VAADCEX09.cable.comcast.com ([fe80::3aea:a7ff:fe12:e2a0]) by VAADCEX09.cable.comcast.com ([fe80::3aea:a7ff:fe12:e2a0%19]) with mapi id 15.00.1130.005; Mon, 4 Jan 2016 08:39:19 -0500 From: "Brzozowski, John" To: Lorenzo Colitti , "draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org" Thread-Topic: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host Thread-Index: AQHRRrIDCp+5rU1eFUO36/Fw4pXTKZ7rXTaA Date: Mon, 4 Jan 2016 13:39:19 +0000 Message-ID: References: <201601031900.u03J0LMe009763@irp-lnx1.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [96.115.73.254] Content-Type: multipart/alternative; boundary="_000_D2AFDD531B681Cjohnbrzozowskicablecomcastcom_" MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPIsWRmVeSWpSXmKPExsWSUOxpoctR1hVmsO6llsXBq5fZLNaffsdo cfrYXmYHZo8Fm0o9liz5yeTx5fJntgDmKC6blNSczLLUIn27BK6Mhi2dLAW/tjJWbDzawdjA 2L+RsYuRk0NCwETi+ott7BC2mMSFe+vZuhi5OIQEtjBJPD5wlwXC2c8ocaT3JjOEc4JRYuOM e6wgLWwCNhKvP/xkBEmICKxklLi0ayUbSIJZQENi7u5GMFtYIFziXeNCFhBbRCBC4sTVJYwQ tpHEqTm3weIsAioS7V9OgNm8AvYSH5Y0Q93RzCgx8cRBsEGcAoESl7qOgG1mBDr2+6k1TBDL xCVuPZnPBPGEgMSSPeeZIWxRiZeP/4HViwroSex+cgrqaR2Js9efQNkGEluX7mOBsBUlfs27 AvVAssSuWZ+ZIA4SlDg58wlUjbjE4SM7WCcwSs1CsnoWkpZZSFpmMXIAxTUl1u/ShyhRlJjS /ZB9FjSIWufMhbIdJA7PPcSOrGYBI8cqRrmyxMSU5NyM/NISA0O95MSknFS95Pzc5MTiEhC9 iRGULIpkvHcwrvvpfohRgINRiYdXPLkrTIg1say4MvcQowQHs5IIb0ERUIg3JbGyKrUoP76o NCe1+BCjNAeLkjhvaKh/mJBAemJJanZqakFqEUyWiYNTqoGxV4jn7QOe6A1y/plnv5xe5qr/ 12JnopN5kGhAtLvd0/7/p3fftbK/8NSi0G+RR4B1wlbHX0wz2dkXxb07aV6y/b2L/VKNyw6P Zio+CYx9tVnLLCi8jHuD5nUrKdWry7Vf/kzUczE68m37M4++c9vbb/hz11TF6/f0NFa8OWR9 8/EDnx0b9nUosRRnJBpqMRcVJwIASeDccxIDAAA= Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 13:39:24 -0000 --_000_D2AFDD531B681Cjohnbrzozowskicablecomcastcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpGcm9tOiB2Nm9wcyA8djZvcHMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86djZvcHMtYm91bmNl c0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBMb3JlbnpvIENvbGl0dGkgPGxvcmVuem9AZ29vZ2xl LmNvbTxtYWlsdG86bG9yZW56b0Bnb29nbGUuY29tPj4NCkRhdGU6IE1vbmRheSwgSmFudWFyeSA0 LCAyMDE2IGF0IDAwOjM2DQpUbzogImRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4 LXBlci1ob3N0QHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1p cHY2LXByZWZpeC1wZXItaG9zdEB0b29scy5pZXRmLm9yZz4iIDxkcmFmdC1pZXRmLXY2b3BzLXVu aXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0 Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3RAdG9vbHMuaWV0Zi5vcmc+Pg0KQ2M6 IHY2b3BzIDx2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+Pg0KU3ViamVjdDog UmU6IFt2Nm9wc10gRm9jdXNlZCBkaXNjdXNzaW9uOiBkcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1p cHY2LXByZWZpeC1wZXItaG9zdA0KDQpPbiBNb24sIEphbiA0LCAyMDE2IGF0IDQ6MDAgQU0sIDxm cmVkQGNpc2NvLmNvbTxtYWlsdG86ZnJlZEBjaXNjby5jb20+PiB3cm90ZToNCkFuZCBub3cgZm9y IHNvbWV0aGluZyBhIGxpdHRsZSBkaWZmZXJlbnQuIEknZCBsaWtlIHRvIGludml0ZSBmb2N1c2Vk DQpkaXNjdXNzaW9uIG9mIGRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1o b3N0LCB3aGljaCB3ZQ0KYWRvcHRlZCBhdCBJRVRGIDk0DQoNClNsaWRlcyBhcmUgYXQNCmh0dHBz Oi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk0L3NsaWRlcy9zbGlkZXMtOTQtdjZvcHMtNC5w ZGYuDQoNCkFzIEkgc2FpZCBiZWZvcmUsIEkgdGhpbmsgaXQncyBhIGdyZWF0IGFwcHJvYWNoLiBU aGUgYWx0ZXJuYXRpdmUvY3VycmVudCBhcHByb2FjaCBvZiBJUHY2IG9uIHdpZmkgcmVsaWVzIG9u IHNoYXJpbmcgYSAvNjQgYmV0d2VlbiB1bnRydXN0ZWQgZGV2aWNlcyBiZWxvbmdpbmcgdG8gbG90 cyBvZiBkaWZmZXJlbnQgY3VzdG9tZXJzLiBUaGF0IGlzIGEgc2VjdXJpdHkgbmlnaHRtYXJlIHRo YXQgZW5kcyB1cCBpbiB0aGUgbmV0d29yayBoYXZpbmcgdG8gbWFpbnRhaW4gbG90cyBvZiBzdGF0 ZSBhbmQgcGVyZm9ybSBsb3RzIG9mIGxheWVyaW5nIHZpb2xhdGlvbnMgKERBRCBwcm94eWluZywg TkQgc25vb3BpbmcsIGV0Yy4pIFRoaXMgaXMgbXVjaCBiZXR0ZXIgLSBldmVyeXRoaW5nIGlzIHBs YWluIGxheWVyIDMgd2l0aCBubyBoYWNrcywgYW5kIHRoZSB1c2VyIGdldHMgYSBmdWxsIC82NC4N Cg0KQ29tbWVudHM6DQoNClRoZSBkcmFmdCBpcyB0YXJnZXRlZCB0byBCQ1AgYnV0IGl0IGlzIGFs c28gYSBkZXNjcmlwdGlvbiBvZiBhIHBhcnRpY3VsYXIgc29sdXRpb24uIFRoYXQgZG9lc24ndCB3 b3JrIHdlbGwgaW4gc29tZSBwbGFjZXMsIG5vdGFibHkgd2hlcmUgaXQgc2F5cyB0aGF0IHRoZSBz b2x1dGlvbiB1c2VzIGEgY2FwdGl2ZSBwb3J0YWwuIEkgZG9uJ3QgdGhpbmsgdGhlcmUgd2lsbCBi ZSBjb25zZW5zdXMgdG8gc2F5IHRoYXQgYSBjYXB0aXZlIHBvcnRhbCBpcyBCQ1AgY29tcGFyZWQg dG8sIHNheSwgODAyLjF4LCBob3RzcG90IDIuMCwgZXRjLiBJIHRoaW5rIGl0cyBCQ1Agc3RhdHVz IHNob3VsZCBiZSBsaW1pdGVkIHRvIHB1YmxpYyB3aWZpIG5ldHdvcmtzIG9yIGluIGdlbmVyYWwg Zm9yIG5ldHdvcmtzIHdoZXJlIHN1YnNjcmliZXIgaXNvbGF0aW9uIGlzIGEgc3Ryb25nIHJlcXVp cmVtZW50LiBUaGlzIGlzIG5vdCBhcHBsaWNhYmxlIHRvIGhvbWUgbmV0d29ya3MsIGZvciBleGFt cGxlOyBtYW55IGhvbWUgbmV0d29ya3MgZG9uJ3QgcHJvdmlkZSBhZGRyZXNzIHNwYWNlIGluIG1v c3QgaG9tZSBuZXR3b3JrcyB0byBzdXBwb3J0IGl0Lg0KW2pqbWJdIHBlcmhhcHMgd2UgY2FuIHNl cGFyYXRlIHRoZSBjYXB0aXZlIHBvcnRhbCBwaWVjZXMgb3V0IGluIGEgc2VwYXJhdGUgZG9jdW1l bnQuICBBZnRlciBzcGVha2luZyB0byB5b3UgYW5kIHNldmVyYWwgb3RoZXJzIEJDUGluZyB0aGUg dGVjaG5pY2FsIGJpdHMgYXBwZWFycyB0byBoYXZlIHZhbHVlIGJleW9uZCBwdWJsaWMgV2ktRmkg bmV0d29ya3MsIGVudGVycHJpc2UgZW52aXJvbm1lbnRzIGNvbWUgdG8gbWluZC4NCg0KSSdkIGxp a2UgdGhpcyBkcmFmdCB0byBjaXRlIGRyYWZ0LWlldGYtdjZvcHMtaG9zdC1hZGRyLWF2YWlsYWJp bGl0eSwgc2luY2UgLzY0IHBlciBob3N0IGlzIG5vdCBvbmx5IHNpbXBsZXIgZm9yIHRoZSBvcGVy YXRvciwgaXQncyBiZXR0ZXIgZm9yIGhvc3RzIGFzIHdlbGwuIE9uIGEgcmVsYXRlZCBub3RlLCBw bGVhc2UgcmVtb3ZlIGFsbCBtZW50aW9uIG9mIHRoZSBzaW5ndWxhciAiSVB2NiBhZGRyZXNzIiBv ciAiLzEyOCBhZGRyZXNzIi4gTWFueSAoYWxsPykgY29tbW9uIGltcGxlbWVudGF0aW9ucyBjb25m aWd1cmUgYm90aCBzdGFibGUgYW5kIHByaXZhY3kgYWRkcmVzc2VzIGJ5IGRlZmF1bHQsIHNvIHRo YXQgdGV4dCBpcyBpbmNvcnJlY3QuIEZvciBleGFtcGxlLCBjaGFuZ2UgInRvIHNlbGVjdCBpdHMg LzEyOCB1bmlxdWUgYWRkcmVzcyIgdG8gImZvcm0gZ2xvYmFsIElQdjYgYWRkcmVzc2VzIi4gQWxz byBjaGFuZ2UgIml0IHdpbGwgYXNzaWduIGl0c2VsZiBhIDEyOCBiaXQgSVB2NiBhZGRyZXNzIHVz aW5nIFNMQUFDIiB0byAiaXQgd2lsbCBmb3JtIG9uZSBvciBtb3JlIElQdjYgYWRkcmVzc2VzIHVz aW5nIFNMQUFDIi4gVGhpcyBoYXBwZW5zIGluIGxvdHMgb2YgcGxhY2VzLg0KW2pqbWJdIHdlIHdp bGwgZmFjdG9yIHRoZXNlIGNvbW1lbnRzIGludG8gb3VyIHVwZGF0ZSB0aGF0IGlzIHVuZGVyd2F5 LiAgSSB0aGluayB3ZSBjYW4gYWNjb21tb2RhdGUgdGhlIHNwaXJpdCBvZiB0aGlzIHJlcXVlc3Qu DQoNClRoZSBkcmFmdCBzaG91bGQgYmUgYSBiaXQgbW9yZSBleHBsaWNpdCBvbiB3aGV0aGVyIGNv bW11bmljYXRpb24gYmV0d2VlbiBkZXZpY2VzIGlzIGFsbG93ZWQgKEkgYXNzdW1lIHllcz8pLCBh bmQgaWYgc28sIGhvdyAoSSBhc3N1bWUgdGhlIHBhY2tldCBpcyB0dW5uZWxlZCB0byBXTEFOLUdX IGFuZCB0aGVuIHR1bm5lbGVkIGJhY2sgdG8gdGhlIG90aGVyIGRldmljZT8pLg0KW2pqbWJdIGRl dmljZSB0byBkZXZpY2UgdG8gc3VwcG9ydGVkLCBob3dldmVyLCBJSVJDIHdlIGRvIG5vdCBtYWtl IGFueSBhc3N1bXB0aW9ucyBhcm91bmQgd2hldGhlciB0aGlzIGlzIHN1cHBvcnRlZCBieSBkZWZh dWx0LiAgV2UgY291bGQvc2hvdWxkIGFkZCB0ZXh0IHRoYXQgZGVzY3JpYmVzIGhvdyBvbmUgbWln aHQgcHJldmVudCBkZXZpY2UgdG8gZGV2aWNlIGNvbW11bmljYXRpb25zLCB3aGVyZSBhcHBsaWNh YmxlL3JlcXVpcmVkLiAgU2luY2UgZXZlcnkgaG9zdCBoYXMgaXRzIG93biBwcmVmaXggdGhlIFdM QU4tR1cgbWlnaHQgcGxheSBhIHJvbGUgaW4gbWFuYWdpbmcgZGV2aWNlIHRvIGRldmljZSBjb21t dW5pY2F0aW9ucy4gIE5vdGUg4oCTIHRoZSB0eXBpY2FsIHVzZSBjYXNlIHRoYXQgZXhpc3RzIHdp dGggSVB2NCBkb2VzIG5vdCBuZWNlc3NhcmlseSBhcHBseSB0byBJUHY2LiAgU3BlY2lmaWNhbGx5 IHdoZXJlIGhvc3RzIHNlZSBsaW5rIGxvY2FsIG11bHRpY2FzdCBhbmQgb3RoZXIgY29tbXVuaWNh dGlvbnMgdGhhdCBhbGxvdyBob3N0cyB0byBzZWUgb3RoZXIgaG9zdHMuICBGdXJ0aGVyLCBwcmVm aXggc2Nhbm5pbmcgZm9yIElQdjYgd2hpbGUgcG9zc2libGUgaXMgdW5saWtlbHkuICBJIHdpbGwg Y29uZmVyIHdpdGggR3VudGVyIGFuZCBvdGhlcnMgdG8gc2VlIHdoYXQgd2Ugc2hvdWxkIGFkZCBo ZXJlLg0KDQpUaGUgZHJhZnQgcmVjb21tZW5kcyBhbiBSQSBpbnRlcnZhbCBvZiAzMDBzIGFuZCBw cmVmZXJyZWQgbGlmZXRpbWUgb2YgMTgwMHMuIEJ1dCBkcmFmdC1pZXRmLXY2b3BzLXJlZHVjaW5n LXJhLWVuZXJneS1jb25zdW1wdGlvbiByZWNvbW1lbmRzICJhcHByb3hpbWF0ZWx5IDcgUkFzIHBl ciBob3VyIiwgYW5kIGxpZmV0aW1lcyBvZiAicm91Z2hseSA0NS05MCBtaW51dGVzIi4gVGhlIHR3 byBzaG91bGQgYmUgbWFkZSBjb25zaXN0ZW50LCBvciB0aGUgZGlmZmVyZW5jZSBzaG91bGQgYmUg anVzdGlmaWVkLiBXZSBzaG91bGRuJ3QgYmUgcHV0dGluZyBvdXQgdHdvIEJDUHMgd2l0aCBkaWZm ZXJlbnQgcmVjb21tZW5kYXRpb25zLg0KW2pqbWJdIHlvdSBhbmQgSSBoYXZlIGRpc2N1c3NlZCB0 aGlzIGV4dGVuc2l2ZWx5IG9mZmxpbmUuICBXZSBjYW4gZG8gb3VyIGJlc3QgdG8gaGFybW9uaXpl IGhlcmUsIEkgY2Fubm90IHByb21pc2UgdGhhdCB3aWxsIGJlIHRoZSBjYXNlLiAgTGV04oCZcyB0 YWxrIG9mZmxpbmUgYW5kIHNlZSB3aGF0IHdlIGNhbiBjb21lIHVwIHdpdGguICBBIGdyZWF0IGRl YWwgb2YgdGhvdWdodCBoYXMgZ29uZSBpbnRvIHRoZXNlIHZhbHVlcywgd2hpY2ggaGFzIGluY2x1 ZGVkIHlvdXIgaW5wdXQuICBFbnZpcm9ubWVudHMgbGlrZSBwdWJsaWMgV2ktRmkgaGF2ZSB0byBz dXBwb3J0IGEgd2lkZSByYW5nZSBvZiBkZXZpY2UgdHlwZXMsIGFzIHN1Y2ggd2UgbmVlZCB0byBl bnN1cmUgdGhhdCB2YWx1ZXMgYXJlIHJlY29tbWVuZGVkIHRoYXQgYWxsb3cgZm9yIG1heGltdW0g aW50ZXJvcGVyYWJpbGl0eS4NCg0KSSBkb24ndCB1bmRlcnN0YW5kIHRoZSB0ZXh0ICJUbyBhY2Nv bW9kYXRlIHRoaXMgdGhlIFdMQU4tR1cgY2FuIHBlcmlvZGljYWxseSBwZXJmb3JtIGEgU3Vic2Ny aWJlciBIb3N0IENvbm5lY3Rpdml0eSBWZXJpZmljYXRpb24gKGkuZS4gcGVyaW9kaWNhbGx5IHBp bmcgZWFjaCBJUHY2IFVFLi4uKSIuIEl0IHNlZW1zIHRvIG1lIHRoYXQgdGhlIHRoZSB3aG9sZSBw b2ludCBvZiB0aGlzIGFwcHJvYWNoIGlzIHRoYXQgdGhlIFdMQU4tR1cgZG9lc24ndCBuZWVkIHRv IGtub3cgdGhlIGluZGl2aWR1YWwgSVB2NiBhZGRyZXNzZXMgZm9ybWVkIGJ5IHRoZSBob3N0cy4g QWxzbywgdGhlcmUncyBubyBndWFyYW50ZWUgdGhhdCBkZXZpY2VzIHdpbGwgcmVzcG9uZCB0byBw aW5nLiBJIHRoaW5rIGJldHRlciBzb2x1dGlvbnMgYXJlOg0KW2pqbWJdIHRydWUgYnV0IHRoZSBX TEFOLUdXIHN0aWxsIG5lZWRzIHRvIG1haW50YWluIGl0cyBuZWlnaGJvciB0YWJsZS4gIEkgZm9y Z2V0IHRoZSBjb250ZXh0IGhlcmUsIEkgd2lsbCByZXZpZXcgdGhlIHRleHQgYWdhaW4gYW5kIHNl bmQgbW9yZSBzdWJzdGFudGl2ZSBjb21tZW50cyBpZiByZXF1aXJlZC4NCg0KICAqICAgVGhlIEFQ IGNvdWxkIGluZm9ybSB0aGUgV0xBTi1HVyBvZiB3aGVuIGEgc3Vic2NyaWJlciBkaXNhcHBlYXJl ZC4NCg0KW2pqbWJdIG9uZSBvdmVyYXJjaGluZyBnb2FsIGlzIHRvIG1pbmltaXplIHRoZSBhbW91 bnQgb2YgY29tcGxleGl0eSBpbiB0aGUgQVAgdG8gc3VwcG9ydCBJUHY2Lg0KDQogICogICBUaGUg V0xBTi1HVyBjb3VsZCB0aW1lIG91dCBhbnkgR1JFIGludGVyZmFjZSB0aGF0IGhhZCBub3QgcmVj ZWl2ZWQgYW55IHBhY2tldHMgaW4gdGhlIGxhc3QgWCBtaW51dGVzLCBvciBpZiB0aGUgY3VzdG9t ZXIncyAvNjQgcHJlZml4IGhhZCBub3Qgb3JpZ2luYXRlZCBhbnkgcGFja2V0cyBpbiB0aGUgbGFz dCBYIG1pbnV0ZXMuDQoNCltqam1iXSBGWUkg4oCTIGEgR1JFIHR1bm5lbCBpcyBmb3IgYW4gQVAg d2hpY2ggbWF5IHNlcnZpbmcgbisxIGNsaWVudHMuICBJZiB0aGlzIHdlcmUgdG8gaGFwcGVuIHRo ZW4gb3RoZXIgY2xpZW50cyBtaWdodCBpbmFkdmVydGVudGx5IGJlIGltcGFjdGVkLg0KQWdhaW4s IHRoZSAic3Vic2NyaWJlciBob3N0IGNvbm5lY3Rpdml0eSIgc29sdXRpb24gd291bGQgYmUgZmlu ZSBpbiBhbiBpbmZvcm1hdGlvbmFsIGRvY3VtZW50IGRlc2NyaWJpbmcgYSBwYXJ0aWN1bGFyIHNv bHV0aW9uLCBidXQgbm90IGZvciBhIEJDUC4NCltqam1iXSBJIGRvIG5vdCBkaXNhZ3JlZSwgd2Ug d2lsbCBzZWUgd2hhdCB3ZSBjYW4gY29tZSB1cCB3aXRoLg0KDQpDaGVlcnMsDQpMb3JlbnpvDQo= --_000_D2AFDD531B681Cjohnbrzozowskicablecomcastcom_ Content-Type: text/html; charset="utf-8" Content-ID: <318B808E84E317429646ADC5646476EA@cable.comcast.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx OHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGlnbjps ZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZU OiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBB RERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1S SUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQt d2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj52Nm9wcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnY2b3Bz LWJvdW5jZXNAaWV0Zi5vcmciPnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhh bGYgb2YgTG9yZW56byBDb2xpdHRpICZsdDs8YSBocmVmPSJtYWlsdG86bG9yZW56b0Bnb29nbGUu Y29tIj5sb3JlbnpvQGdvb2dsZS5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdl aWdodDpib2xkIj5EYXRlOiA8L3NwYW4+TW9uZGF5LCBKYW51YXJ5IDQsIDIwMTYgYXQgMDA6MzY8 YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj4mcXVvdDs8YSBo cmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3RA dG9vbHMuaWV0Zi5vcmciPmRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1o b3N0QHRvb2xzLmlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWll dGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0QHRvb2xzLmlldGYub3JnIj5kcmFm dC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdEB0b29scy5pZXRmLm9yZzwv YT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+djZv cHMgJmx0OzxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8L2E+ Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+ UmU6IFt2Nm9wc10gRm9jdXNlZCBkaXNjdXNzaW9uOiBkcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1p cHY2LXByZWZpeC1wZXItaG9zdDxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9S REVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAg NTsiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4 dHJhIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBNb24sIEphbiA0LCAyMDE2IGF0IDQ6 MDAgQU0sIDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmZyZWRAY2lzY28uY29t IiB0YXJnZXQ9Il9ibGFuayI+ZnJlZEBjaXNjby5jb208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJy Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHgg MHB4IDAuOGV4O2JvcmRlci1sZWZ0LXdpZHRoOjFweDtib3JkZXItbGVmdC1jb2xvcjpyZ2IoMjA0 LDIwNCwyMDQpO2JvcmRlci1sZWZ0LXN0eWxlOnNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KQW5k IG5vdyBmb3Igc29tZXRoaW5nIGEgbGl0dGxlIGRpZmZlcmVudC4gSSdkIGxpa2UgdG8gaW52aXRl IGZvY3VzZWQ8YnI+DQpkaXNjdXNzaW9uIG9mIGRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYt cHJlZml4LXBlci1ob3N0LCB3aGljaCB3ZTxicj4NCmFkb3B0ZWQgYXQgSUVURiA5NDxicj4NCjxi cj4NClNsaWRlcyBhcmUgYXQ8YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9wcm9j ZWVkaW5ncy85NC9zbGlkZXMvc2xpZGVzLTk0LXY2b3BzLTQucGRmIiByZWw9Im5vcmVmZXJyZXIi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85NC9zbGlk ZXMvc2xpZGVzLTk0LXY2b3BzLTQucGRmPC9hPi48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj5BcyBJIHNhaWQgYmVmb3JlLCBJIHRoaW5rIGl0J3MgYSBncmVhdCBh cHByb2FjaC4gVGhlIGFsdGVybmF0aXZlL2N1cnJlbnQgYXBwcm9hY2ggb2YgSVB2NiBvbiB3aWZp IHJlbGllcyBvbiBzaGFyaW5nIGEgLzY0IGJldHdlZW4gdW50cnVzdGVkIGRldmljZXMgYmVsb25n aW5nIHRvIGxvdHMgb2YgZGlmZmVyZW50IGN1c3RvbWVycy4gVGhhdCBpcyBhIHNlY3VyaXR5IG5p Z2h0bWFyZSB0aGF0IGVuZHMgdXAgaW4gdGhlIG5ldHdvcmsgaGF2aW5nDQogdG8gbWFpbnRhaW4g bG90cyBvZiBzdGF0ZSBhbmQgcGVyZm9ybSBsb3RzIG9mIGxheWVyaW5nIHZpb2xhdGlvbnMgKERB RCBwcm94eWluZywgTkQgc25vb3BpbmcsIGV0Yy4pIFRoaXMgaXMgbXVjaCBiZXR0ZXIgLSBldmVy eXRoaW5nIGlzIHBsYWluIGxheWVyIDMgd2l0aCBubyBoYWNrcywgYW5kIHRoZSB1c2VyIGdldHMg YSBmdWxsIC82NC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkNvbW1lbnRzOjwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhlIGRyYWZ0IGlzIHRhcmdldGVkIHRvIEJDUCBi dXQgaXQgaXMgYWxzbyBhIGRlc2NyaXB0aW9uIG9mIGEgcGFydGljdWxhciBzb2x1dGlvbi4gVGhh dCBkb2Vzbid0IHdvcmsgd2VsbCBpbiBzb21lIHBsYWNlcywgbm90YWJseSB3aGVyZSBpdCBzYXlz IHRoYXQgdGhlIHNvbHV0aW9uIHVzZXMgYSBjYXB0aXZlIHBvcnRhbC4gSSBkb24ndCB0aGluayB0 aGVyZSB3aWxsIGJlIGNvbnNlbnN1cyB0byBzYXkgdGhhdCBhIGNhcHRpdmUgcG9ydGFsDQogaXMg QkNQIGNvbXBhcmVkIHRvLCBzYXksIDgwMi4xeCwgaG90c3BvdCAyLjAsIGV0Yy4gSSB0aGluayBp dHMgQkNQIHN0YXR1cyBzaG91bGQgYmUgbGltaXRlZCB0byBwdWJsaWMgd2lmaSBuZXR3b3JrcyBv ciBpbiBnZW5lcmFsIGZvciBuZXR3b3JrcyB3aGVyZSBzdWJzY3JpYmVyIGlzb2xhdGlvbiBpcyBh IHN0cm9uZyByZXF1aXJlbWVudC4gVGhpcyBpcyBub3QgYXBwbGljYWJsZSB0byBob21lIG5ldHdv cmtzLCBmb3IgZXhhbXBsZTsgbWFueSBob21lDQogbmV0d29ya3MgZG9uJ3QgcHJvdmlkZSBhZGRy ZXNzIHNwYWNlIGluIG1vc3QgaG9tZSBuZXR3b3JrcyB0byBzdXBwb3J0IGl0LjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bh bj4NCjxkaXY+W2pqbWJdIHBlcmhhcHMgd2UgY2FuIHNlcGFyYXRlIHRoZSBjYXB0aXZlIHBvcnRh bCBwaWVjZXMgb3V0IGluIGEgc2VwYXJhdGUgZG9jdW1lbnQuICZuYnNwO0FmdGVyIHNwZWFraW5n IHRvIHlvdSBhbmQgc2V2ZXJhbCBvdGhlcnMgQkNQaW5nIHRoZSB0ZWNobmljYWwgYml0cyBhcHBl YXJzIHRvIGhhdmUgdmFsdWUgYmV5b25kIHB1YmxpYyBXaS1GaSBuZXR3b3JrcywgZW50ZXJwcmlz ZSBlbnZpcm9ubWVudHMgY29tZSB0byBtaW5kLjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9E WV9TRUNUSU9OIj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9D S1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAg MCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj4NCjxk aXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2PkknZCBsaWtlIHRoaXMgZHJhZnQgdG8gY2l0ZSBkcmFmdC1pZXRm LXY2b3BzLWhvc3QtYWRkci1hdmFpbGFiaWxpdHksIHNpbmNlIC82NCBwZXIgaG9zdCBpcyBub3Qg b25seSBzaW1wbGVyIGZvciB0aGUgb3BlcmF0b3IsIGl0J3MgYmV0dGVyIGZvciBob3N0cyBhcyB3 ZWxsLiBPbiBhIHJlbGF0ZWQgbm90ZSwgcGxlYXNlIHJlbW92ZSBhbGwgbWVudGlvbiBvZiB0aGUg c2luZ3VsYXIgJnF1b3Q7SVB2NiBhZGRyZXNzJnF1b3Q7IG9yICZxdW90Oy8xMjggYWRkcmVzcyZx dW90Oy4NCiBNYW55IChhbGw/KSBjb21tb24gaW1wbGVtZW50YXRpb25zIGNvbmZpZ3VyZSBib3Ro IHN0YWJsZSBhbmQgcHJpdmFjeSBhZGRyZXNzZXMgYnkgZGVmYXVsdCwgc28gdGhhdCB0ZXh0IGlz IGluY29ycmVjdC4gRm9yIGV4YW1wbGUsIGNoYW5nZSAmcXVvdDt0byBzZWxlY3QgaXRzIC8xMjgg dW5pcXVlIGFkZHJlc3MmcXVvdDsgdG8gJnF1b3Q7Zm9ybSBnbG9iYWwgSVB2NiBhZGRyZXNzZXMm cXVvdDsuIEFsc28gY2hhbmdlICZxdW90O2l0IHdpbGwgYXNzaWduIGl0c2VsZiBhIDEyOCBiaXQg SVB2Ng0KIGFkZHJlc3MgdXNpbmcgU0xBQUMmcXVvdDsgdG8gJnF1b3Q7aXQgd2lsbCBmb3JtIG9u ZSBvciBtb3JlIElQdjYgYWRkcmVzc2VzIHVzaW5nIFNMQUFDJnF1b3Q7LiBUaGlzIGhhcHBlbnMg aW4gbG90cyBvZiBwbGFjZXMuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0KPGRpdj5bamptYl0gd2Ugd2lsbCBmYWN0 b3IgdGhlc2UgY29tbWVudHMgaW50byBvdXIgdXBkYXRlIHRoYXQgaXMgdW5kZXJ3YXkuICZuYnNw O0kgdGhpbmsgd2UgY2FuIGFjY29tbW9kYXRlIHRoZSBzcGlyaXQgb2YgdGhpcyByZXF1ZXN0Ljwv ZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxibG9ja3F1b3RlIGlkPSJN QUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNi NWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj4N CjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCjxkaXYg Y2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZSBkcmFmdCBz aG91bGQgYmUgYSBiaXQgbW9yZSBleHBsaWNpdCBvbiB3aGV0aGVyIGNvbW11bmljYXRpb24gYmV0 d2VlbiBkZXZpY2VzIGlzIGFsbG93ZWQgKEkgYXNzdW1lIHllcz8pLCBhbmQgaWYgc28sIGhvdyAo SSBhc3N1bWUgdGhlIHBhY2tldCBpcyB0dW5uZWxlZCB0byBXTEFOLUdXIGFuZCB0aGVuIHR1bm5l bGVkIGJhY2sgdG8gdGhlIG90aGVyIGRldmljZT8pLjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjxkaXY+W2pqbWJd IGRldmljZSB0byBkZXZpY2UgdG8gc3VwcG9ydGVkLCBob3dldmVyLCBJSVJDIHdlIGRvIG5vdCBt YWtlIGFueSBhc3N1bXB0aW9ucyBhcm91bmQgd2hldGhlciB0aGlzIGlzIHN1cHBvcnRlZCBieSBk ZWZhdWx0LiAmbmJzcDtXZSBjb3VsZC9zaG91bGQgYWRkIHRleHQgdGhhdCBkZXNjcmliZXMgaG93 IG9uZSBtaWdodCBwcmV2ZW50IGRldmljZSB0byBkZXZpY2UgY29tbXVuaWNhdGlvbnMsIHdoZXJl IGFwcGxpY2FibGUvcmVxdWlyZWQuICZuYnNwO1NpbmNlDQogZXZlcnkgaG9zdCBoYXMgaXRzIG93 biBwcmVmaXggdGhlIFdMQU4tR1cgbWlnaHQgcGxheSBhIHJvbGUgaW4gbWFuYWdpbmcgZGV2aWNl IHRvIGRldmljZSBjb21tdW5pY2F0aW9ucy4gJm5ic3A7Tm90ZSDigJMgdGhlIHR5cGljYWwgdXNl IGNhc2UgdGhhdCBleGlzdHMgd2l0aCBJUHY0IGRvZXMgbm90IG5lY2Vzc2FyaWx5IGFwcGx5IHRv IElQdjYuICZuYnNwO1NwZWNpZmljYWxseSB3aGVyZSBob3N0cyBzZWUgbGluayBsb2NhbCBtdWx0 aWNhc3QgYW5kIG90aGVyIGNvbW11bmljYXRpb25zDQogdGhhdCBhbGxvdyBob3N0cyB0byBzZWUg b3RoZXIgaG9zdHMuICZuYnNwO0Z1cnRoZXIsIHByZWZpeCBzY2FubmluZyBmb3IgSVB2NiB3aGls ZSBwb3NzaWJsZSBpcyB1bmxpa2VseS4gJm5ic3A7SSB3aWxsIGNvbmZlciB3aXRoIEd1bnRlciBh bmQgb3RoZXJzIHRvIHNlZSB3aGF0IHdlIHNob3VsZCBhZGQgaGVyZS48L2Rpdj4NCjxzcGFuIGlk PSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRU UklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7 IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBk aXI9Imx0ciI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9x dW90ZSI+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGUgZHJhZnQgcmVjb21tZW5kcyBhbiBS QSBpbnRlcnZhbCBvZiAzMDBzIGFuZCBwcmVmZXJyZWQgbGlmZXRpbWUgb2YgMTgwMHMuIEJ1dCBk cmFmdC1pZXRmLXY2b3BzLXJlZHVjaW5nLXJhLWVuZXJneS1jb25zdW1wdGlvbiByZWNvbW1lbmRz ICZxdW90O2FwcHJveGltYXRlbHkgNyBSQXMgcGVyIGhvdXImcXVvdDssIGFuZCBsaWZldGltZXMg b2YgJnF1b3Q7cm91Z2hseSA0NS05MCBtaW51dGVzJnF1b3Q7LiBUaGUgdHdvIHNob3VsZCBiZSBt YWRlIGNvbnNpc3RlbnQsIG9yDQogdGhlIGRpZmZlcmVuY2Ugc2hvdWxkIGJlIGp1c3RpZmllZC4g V2Ugc2hvdWxkbid0IGJlIHB1dHRpbmcgb3V0IHR3byBCQ1BzIHdpdGggZGlmZmVyZW50IHJlY29t bWVuZGF0aW9ucy48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8ZGl2Pltqam1iXSB5b3UgYW5kIEkgaGF2ZSBkaXNj dXNzZWQgdGhpcyBleHRlbnNpdmVseSBvZmZsaW5lLiAmbmJzcDtXZSBjYW4gZG8gb3VyIGJlc3Qg dG8gaGFybW9uaXplIGhlcmUsIEkgY2Fubm90IHByb21pc2UgdGhhdCB3aWxsIGJlIHRoZSBjYXNl LiAmbmJzcDtMZXTigJlzIHRhbGsgb2ZmbGluZSBhbmQgc2VlIHdoYXQgd2UgY2FuIGNvbWUgdXAg d2l0aC4gJm5ic3A7QSBncmVhdCBkZWFsIG9mIHRob3VnaHQgaGFzIGdvbmUgaW50byB0aGVzZSB2 YWx1ZXMsIHdoaWNoIGhhcw0KIGluY2x1ZGVkIHlvdXIgaW5wdXQuICZuYnNwO0Vudmlyb25tZW50 cyBsaWtlIHB1YmxpYyBXaS1GaSBoYXZlIHRvIHN1cHBvcnQgYSB3aWRlIHJhbmdlIG9mIGRldmlj ZSB0eXBlcywgYXMgc3VjaCB3ZSBuZWVkIHRvIGVuc3VyZSB0aGF0IHZhbHVlcyBhcmUgcmVjb21t ZW5kZWQgdGhhdCBhbGxvdyBmb3IgbWF4aW11bSBpbnRlcm9wZXJhYmlsaXR5LjwvZGl2Pg0KPHNw YW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9P S19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBz b2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2IGRpcj0ibHRyIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCjxkaXYgY2xhc3M9Imdt YWlsX3F1b3RlIj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkkgZG9uJ3QgdW5kZXJzdGFuZCB0 aGUgdGV4dCAmcXVvdDtUbyBhY2NvbW9kYXRlIHRoaXMgdGhlIFdMQU4tR1cgY2FuIHBlcmlvZGlj YWxseSBwZXJmb3JtIGEgU3Vic2NyaWJlciBIb3N0IENvbm5lY3Rpdml0eSBWZXJpZmljYXRpb24g KGkuZS4gcGVyaW9kaWNhbGx5IHBpbmcgZWFjaCBJUHY2IFVFLi4uKSZxdW90Oy4gSXQgc2VlbXMg dG8gbWUgdGhhdCB0aGUgdGhlIHdob2xlIHBvaW50IG9mIHRoaXMgYXBwcm9hY2ggaXMgdGhhdCB0 aGUgV0xBTi1HVyBkb2Vzbid0DQogbmVlZCB0byBrbm93IHRoZSBpbmRpdmlkdWFsIElQdjYgYWRk cmVzc2VzIGZvcm1lZCBieSB0aGUgaG9zdHMuIEFsc28sIHRoZXJlJ3Mgbm8gZ3VhcmFudGVlIHRo YXQgZGV2aWNlcyB3aWxsIHJlc3BvbmQgdG8gcGluZy4gSSB0aGluayBiZXR0ZXIgc29sdXRpb25z IGFyZTo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L3NwYW4+DQo8ZGl2Pltqam1iXSB0cnVlIGJ1dCB0aGUgV0xBTi1HVyBzdGls bCBuZWVkcyB0byBtYWludGFpbiBpdHMgbmVpZ2hib3IgdGFibGUuICZuYnNwO0kgZm9yZ2V0IHRo ZSBjb250ZXh0IGhlcmUsIEkgd2lsbCByZXZpZXcgdGhlIHRleHQgYWdhaW4gYW5kIHNlbmQgbW9y ZSBzdWJzdGFudGl2ZSBjb21tZW50cyBpZiByZXF1aXJlZC48L2Rpdj4NCjxzcGFuIGlkPSJPTEtf U1JDX0JPRFlfU0VDVElPTiI+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJ T05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJ Tkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0 ciI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+ DQo8ZGl2Pg0KPHVsPg0KPGxpPlRoZSBBUCBjb3VsZCBpbmZvcm0gdGhlIFdMQU4tR1cgb2Ygd2hl biBhIHN1YnNjcmliZXIgZGlzYXBwZWFyZWQuPC9saT48L3VsPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0KPGRp dj5bamptYl0gb25lIG92ZXJhcmNoaW5nIGdvYWwgaXMgdG8gbWluaW1pemUgdGhlIGFtb3VudCBv ZiBjb21wbGV4aXR5IGluIHRoZSBBUCB0byBzdXBwb3J0IElQdjYuPC9kaXY+DQo8c3BhbiBpZD0i T0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJ QlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQ QURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgZGly PSJsdHIiPg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVv dGUiPg0KPGRpdj4NCjx1bD4NCjxsaT5UaGUgV0xBTi1HVyBjb3VsZCB0aW1lIG91dCBhbnkgR1JF IGludGVyZmFjZSB0aGF0IGhhZCBub3QgcmVjZWl2ZWQgYW55IHBhY2tldHMgaW4gdGhlIGxhc3Qg WCBtaW51dGVzLCBvciBpZiB0aGUgY3VzdG9tZXIncyAvNjQgcHJlZml4IGhhZCBub3Qgb3JpZ2lu YXRlZCBhbnkgcGFja2V0cyBpbiB0aGUgbGFzdCBYIG1pbnV0ZXMuPC9saT48L3VsPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9zcGFuPg0KPGRpdj5bamptYl0gRllJIOKAkyBhIEdSRSB0dW5uZWwgaXMgZm9yIGFuIEFQIHdo aWNoIG1heSBzZXJ2aW5nIG4mIzQzOzEgY2xpZW50cy4gJm5ic3A7SWYgdGhpcyB3ZXJlIHRvIGhh cHBlbiB0aGVuIG90aGVyIGNsaWVudHMgbWlnaHQgaW5hZHZlcnRlbnRseSBiZSBpbXBhY3RlZC48 L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8YmxvY2txdW90ZSBpZD0i TUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAj YjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQo8ZGl2 IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8ZGl2PkFnYWluLCB0aGUgJnF1b3Q7c3Vic2NyaWJlciBo b3N0IGNvbm5lY3Rpdml0eSZxdW90OyBzb2x1dGlvbiB3b3VsZCBiZSBmaW5lIGluIGFuIGluZm9y bWF0aW9uYWwgZG9jdW1lbnQgZGVzY3JpYmluZyBhIHBhcnRpY3VsYXIgc29sdXRpb24sIGJ1dCBu b3QgZm9yIGEgQkNQLjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjxkaXY+W2pqbWJdIEkgZG8gbm90IGRpc2FncmVl LCB3ZSB3aWxsIHNlZSB3aGF0IHdlIGNhbiBjb21lIHVwIHdpdGguPC9kaXY+DQo8c3BhbiBpZD0i T0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJ QlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQ QURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgZGly PSJsdHIiPg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVv dGUiPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Q2hlZXJzLDwvZGl2Pg0KPGRpdj5Mb3Jlbnpv PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9zcGFuPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D2AFDD531B681Cjohnbrzozowskicablecomcastcom_-- From nobody Mon Jan 4 05:46:48 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 504B31A88CA for ; Mon, 4 Jan 2016 05:46:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.664 X-Spam-Level: * X-Spam-Status: No, score=1.664 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 aD0QxDwwSS95 for ; Mon, 4 Jan 2016 05:46:45 -0800 (PST) Received: from vaadcmhout01.cable.comcast.com (unknown [96.114.28.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75D851A88DA for ; Mon, 4 Jan 2016 05:46:45 -0800 (PST) X-AuditID: 60721c4b-f79fb6d00000348f-da-568a77c4d4a7 Received: from VAADCEX10.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by vaadcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id 7E.93.13455.4C77A865; Mon, 4 Jan 2016 08:46:44 -0500 (EST) Received: from VAADCEX09.cable.comcast.com (147.191.102.76) by VAADCEX10.cable.comcast.com (147.191.102.77) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Mon, 4 Jan 2016 08:46:43 -0500 Received: from VAADCEX09.cable.comcast.com ([fe80::3aea:a7ff:fe12:e2a0]) by VAADCEX09.cable.comcast.com ([fe80::3aea:a7ff:fe12:e2a0%19]) with mapi id 15.00.1130.005; Mon, 4 Jan 2016 08:46:43 -0500 From: "Brzozowski, John" To: Tore Anderson , "fred@cisco.com" Thread-Topic: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host Thread-Index: AQHRRu0/Cp+5rU1eFUO36/Fw4pXTKZ7rXtAA Date: Mon, 4 Jan 2016 13:46:43 +0000 Message-ID: References: <201601031900.u03J0LMe009763@irp-lnx1.cisco.com> <20160104134135.1f1b3711@echo.ms.redpill-linpro.com> In-Reply-To: <20160104134135.1f1b3711@echo.ms.redpill-linpro.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [96.114.156.8] Content-Type: text/plain; charset="utf-8" Content-ID: <241A2A70FDCC9440BCEFF5F5E9C8B125@cable.comcast.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsWSUOxpoXukvCvMYOotGYv3686wWWw5eIfR 4vSxvcwOzB5Tfm9k9fjbO5PdY8mSn0wBzFFcNimpOZllqUX6dglcGY8XPWIsWGZb0bjuE0sD 4x3rLkZODgkBE4kjVxrZIWwxiQv31rN1MXJxCAlsYZL42fSRGcLZzyjxc9F5VgjnBKPEjZZr YC1sAjYSrz/8ZASxRQScJB6cXQNUxMHBLKAqMfsPP0hYWCBc4l3jQhaIkgiJE1eXQJUbSRz8 3w9mswioSLxesI8RpJVXwF5i5iFtkLCQQLHE+3dnwEo4BRwl/t1+zQRiMwId+v3UGjCbWUBc 4taT+UwQDwhILNlznhnCFpV4+fgfK4gtKqAnsfvJKUaIuI7E2etPoGwDia1L97FA2AoS2/dv Y4G4XlNi/S59iPEOEuf7jrFA2IoSU7ofgj3OKyAocXLmE6hWcYnDR3awTmCUmYXkolkIk2Yh mTQLyaRZSCYtYGRdxShXlpiYkpybkV9aYmCol5yYlJOql5yfm5xYXAKiNzGCEkGRjPcOxnU/ 3Q8xCnAwKvHwMpV1hQmxJpYVV+YeYpTgYFYS4S0oAgrxpiRWVqUW5ccXleakFh9ilOZgURLn DQ31DxMSSE8sSc1OTS1ILYLJMnFwSjUwaomsto07w95ybHaNjcfd3/+mteSaylqVRt7VvDDj rlvvMrP9f6afSFA1nLG1r1W16YSo6JX65xeuRmY5tPjKpDHUK9y/rMialm/AtWGv38Ns49w5 f2uemJ2dExivvcFlygOjiLaG/i0Ta4VaHrTXzXy38/eDV/Nm7dZkXWryRupZ9t7WGwY8SizF GYmGWsxFxYkAJ1uVUQADAAA= Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 13:46:47 -0000 VG9yZSBhcG9sb2dpZXMsIEkgdGhvdWdodCBJL3dlIHJlcGxpZWQgdG8gYWxsIGNvbW1lbnRzIHRo YXQgcmVxdWlyZWQgYQ0KcmVwbHkuICBXZSBoYXZlIGFsbCB0aGUgZmVlZGJhY2sgYW5kIHdpbGwg ZmFjdG9yIGluIGFzIHBhcnQgb2Ygb3VyIHVwZGF0ZS4NCiBTZWUgYmVsb3cgZm9yIG1vcmUuDQoN CkpvaG4NCisxLTQ4NC05NjItMDA2MA0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogdjZvcHMgPHY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBUb3Jl IEFuZGVyc29uDQo8dG9yZUBmdWQubm8+DQpEYXRlOiBNb25kYXksIEphbnVhcnkgNCwgMjAxNiBh dCAwNzo0MQ0KVG86IEZyZWQgQmFrZXIgPGZyZWRAY2lzY28uY29tPg0KQ2M6IHY2b3BzIDx2Nm9w c0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbdjZvcHNdIEZvY3VzZWQgZGlzY3Vzc2lvbjoNCmRy YWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0DQoNCj4qIGZyZWRAY2lz Y28uY29tDQo+DQo+PiBBbmQgbm93IGZvciBzb21ldGhpbmcgYSBsaXR0bGUgZGlmZmVyZW50LiBJ J2QgbGlrZSB0byBpbnZpdGUgZm9jdXNlZA0KPj4gZGlzY3Vzc2lvbiBvZiBkcmFmdC1pZXRmLXY2 b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdCwgd2hpY2ggd2UNCj4+IGFkb3B0ZWQgYXQg SUVURiA5NA0KPg0KPkZXSVcsIEkgc2VudCBzb21lIGZlZWRiYWNrIHRvIHRoZSBsaXN0IG9uIHRo ZSAyOHRoIG9mIE9jdG9iZXIsIHdoaWNoDQo+d2Fzbid0IGFuc3dlcmVkKiBvciBpbmNvcnBvcmF0 ZWQgaW4gdGhlIG5ldyByZXZpc2lvbiBvZiB0aGUgZHJhZnQgYXMgZmFyDQo+YXMgSSBjYW4gdGVs bC4gSSdsbCB0aGVyZWZvcmUgcmVwZWF0IHRoZW0gYmVsb3cuDQo+DQo+KiBFeGNlcHQgZm9yIHBv aW50ICMyIHJlZ2FyZGluZyB0aGUgZHJhZnQgaW1wcm9wZXJseSBzdWdnZXN0aW5nIHRoYXQNCj4g IHdoZW4gSUFfUEQgaXMgYXZhaWxhYmxlIHRoZSBNLWZsYWcgc2hvdWxkIGJlIHNldCB0byAxLg0K W2pqbWJdIEkgcmVzcGVjdGZ1bGx5IGRpc2FncmVlLCBJIGhhdmUgYnVpbHQgYSB2ZXJ5IGxhcmdl IElQdjYgZGVwbG95bWVudA0KYmFzZWQgb24gdGhpcy4gIEV4cGVyaWVuY2UgdGVsbHMgbWUgaXQg d29ya3MuICBJIChDb21jYXN0IGhhdCBvbikgd2lsbA0KY29udGludWUgdG8gdXNlIHRoZXNlIGJp dCBpbiB0aGlzIG1hbm5lci4NCj5UaGlzIGRpZCBjYXVzZQ0KPiAgc29tZSBkaXNjdXNzaW9uIG9u IHdoZXRoZXIgb3Igbm90IFJBIGZsYWdzIGhhdmUgYW55IHJlbGF0aW9uIHRvIElBX1BEDQo+ICBh dmFpbGFiaWxpdHkgdG8gYmVnaW4gd2l0aCwgYnV0IEkgZG9uJ3QgdGhpbmsgdGhlcmUgd2FzIGFu eQ0KPiAgZGlzYWdyZWVtZW50IGFib3V0IG15IGluaXRpYWwgcG9pbnQgYWJvdXQgdHlpbmcgSUFf UEQgd2l0aCB0aGUgTS1mbGFnDQo+ICBzcGVjaWZpY2FsbHkgbm90IGJlaW5nIGFwcHJvcHJpYXRl Lg0KW2pqbWJdIGxvdHMgb2YgZGlzY3Vzc2lvbiB0aGF0IEkgcmVhZCBhbmQgbGFyZ2VseSBkaXNh Z3JlZWQgd2l0aCwgc2VlDQpjb21tZW50IGFib3ZlLiAgIFRoaXMgc2hpcCBoYXMgc2FpbGVkLCB3 ZSBhbGwgbXVzdCBub3cgYWdyZWUgdG8gZGlzYWdyZWUuDQpMZXTigJlzIG5vdCBzdGFydCBhbm90 aGVyIHRpZGFsIHdhdmUgb2YgZW1haWxzIG9uIHRoaXMgdG9waWMuDQo+DQo+ICBFYXNpZXN0IHdh eSB0byBmaXggdGhpcyBpbiB0aGUgZHJhZnQgaXMgSU1ITyBqdXN0IHRvIHJlbW92ZSDCqywgdGhp cw0KPiAgZmxhZyBtYXkgYmUgc2V0IHRvIDEgaW4gdGhlIGZ1dHVyZSBpZi93aGVuIERIQ1B2NiBw cmVmaXggdGhpcyBmbGFnDQo+ICBtYXkgYmUgc2V0IHRvIDEgaW4gdGhlIGZ1dHVyZSBpZi93aGVu IERIQ1B2NiBwcmVmaXgpwrsuIChKdXN0IG5vdGljZWQNCj4gIHRoaXMgd2lsbCBhbHNvIGdldCBy aWQgb2YgYW4gdW5tYXRjaGVkIHBhcmVudGhlc2lzLikNCltqam1iXSBJIGN1cnJlbnRseSBoYXZl IG5vIGludGVudGlvbiBvZiByZW1vdmluZyByZWZlcmVuY2UgdG8gTS9PIGJpdCA9IDENCmFuZCB0 aGUgdXNlIG9mIHN0YXRlZnVsIERIQ1B2NiBmb3IgUEQuICBUaGlzIGlzIGhvdyB0aGUgc2FtZSB3 aWxsIGJlDQpkZXBsb3llZCwgdGhlIGRvY3VtZW50IHdpbGwgcmVmbGVjdCByZWFsaXR5LiAgSWYg SSBtaXN1bmRlcnN0b29kIHlvdXINCmNvbW1lbnRzIEkgYXBvbG9naXplLg0KPg0KPlRvcmUNCj4N Cj4tLS0tLS0NCj4NCj4xKSBTZWN0aW9uIDQuMiBtZW50aW9ucyB0aGF0IERBRCBpcyB1c2VkLCBi dXQgaXQgaXMgbm90IGNsZWFyIHRvIG1lIGhvdw0KPnRoaXMgd2lsbCB3b3JrIGZvciBMTEFzLiBJ ZiB0d28gVUVzIChwb3RlbnRpYWxseSBhdHRhY2hlZCB0byBkaWZmZXJlbnQNCj5BUHMpIGFyZSB1 c2luZyB0aGUgc2FtZSBsaW5rLWxvY2FsIGFkZHJlc3MsIGhvdyB3aWxsIHRoZXkgc2VlIGVhY2gN Cj5vdGhlcnMgREFEIG1lc3NhZ2VzPyBQcm94eS1ORCBvbiB0aGUgV0xBTi1HVz8gT3IgaWYgdGhl IFdMQU4tR1cgZG9lcw0KPm5vdCByZWxheSBEQUQgbWVzc2FnZXMgYWNyb3NzIHRoZSBzcGxpdCBC VU0gaG9yaXpvbiwgaG93IHdpbGwgaXQgZGVhbA0KPndpdGggdGhlIHBvc3NpYmxpdHkgb2YgdHdv IHVuaXF1ZSBVRXMgYm90aCB1c2luZyB0aGUgc2FtZSBMTEE/IEknbQ0KPmd1ZXNzaW5nIHRoYXQg aW4gYSBsYXJnZS1zY2FsZSBkZXBsb3ltZW50LCB0aGUgY2hhbmNlcyBvZiB0d28gVUVzDQo+aGF2 aW5nIHN0YXRpY2FsbHkgY29uZmlndXJlZCwgZS5nLiwgZmU4MDo6MSBpcyBxdWl0ZSBsaWtlbHku DQo+DQo+MikgUmVnYXJkaW5nIHRoZSBmb2xsb3dpbmcgdGV4dCBpbiBTZWN0aW9uIDQuMjoNCj4N Cj4+ICAgbyAgTS1mbGFnID0gMCAoVUUvc3Vic2NyaWJlciBhZGRyZXNzIGlzIG5vdCBtYW5hZ2Vk IHRocm91Z2ggREhDUHY2KSwNCj4+ICAgICAgdGhpcyBmbGFnIG1heSBiZSBzZXQgdG8gMSBpbiB0 aGUgZnV0dXJlIGlmL3doZW4gREhDUHY2IHByZWZpeA0KPj4gICAgICBkZWxlZ2F0aW9uIHN1cHBv cnQgb3ZlciBXaS1GaSBpcyBkZXNpcmVkKQ0KPg0KPkFzIEkgdW5kZXJzdGFuZCBpdCAoYW5kIEkg ZG8gc3RyZXNzIHRoYXQpLCB0aGUgTS1mbGFnIGluZGljYXRlcyB3aGV0aGVyDQo+b3Igbm90ICph ZGRyZXNzZXMqIGFyZSBhdmFpbGFibGUgdmlhIERIQ1B2NiAoUkZDIDQ4NjEgczQuMikuIFByZWZp eGVzDQo+KElBX1BEKSBpcyBzb21ldGhpbmcgZGlmZmVyZW50LiBUaGVyZWZvcmUsIGFzc3VtaW5n IHRoYXQgYXZhaWxhYmlsaXR5IG9mDQo+SUFfUEQgaXMgc2lnbmFsbGVkIHVzaW5nIFJBIGZsYWdz IHRvIGJlZ2luIHdpdGgsIHRoZW4gaXQgaXMgIm90aGVyDQo+Y29uZmlndXJhdGlvbiIgYW5kIHRo dXMgc2lnbmFsbGVkIHdpdGggdGhlIE8tZmxhZywgbm90IHRoZSBNLWZsYWcuIEkNCj5rbm93IG9m IGF0IGxlYXN0IG9uZSB3aXJlbGluZSBJU1AgdGhhdCBoYXMgc3VjaCBhIGRlcGxveW1lbnQsIGku ZS4sDQo+dGhleSBzdXBwb3J0IERIQ1B2NiBJQV9QRCBidXQgbm90IElBX05BL0lBX1RBLCBhbmQg dGhleSBzaWduYWwgdGhpcw0KPnVzaW5nIE09MCArIE89MS4NCj4NCj4zKSBUaGUgZHJhZnQgZGVz Y3JpYmVzIHR1bm5lbGluZyB0cmFmZmljIGluIGEgc3RhdGVsZXNzIG1hbm5lci4gSSB0YWtlDQo+ dGhhdCB0byBtZWFuIHRoYXQgdGhlIEFQcyBhbmQgV0xBTi1HVyB3aWxsIGJlIGluY2FwYWJsZSBv ZiBwZXJmb3JtaW5nDQo+cmVhc3NlbWJseSBhdCB0dW5uZWwgZWdyZXNzIChhbmQgYnkgZXh0ZW5z aW9uIHRoYXQgdGhleSB3b24ndCBmcmFnbWVudA0KPkdSRSBwYWNrZXRzIG9uIGluZ3Jlc3MgZWl0 aGVyKS4gVGhhdCBpbiB0dXJuIG1lYW5zIHRoYXQgeW91IGVpdGhlciAxKQ0KPm5lZWQgdG8gYWxs b3cgZm9yIGp1bWJvIGZyYW1lcyBpbiB0aGUgdHJhbnNwb3J0IG5ldHdvcmsgYmV0d2VlbiB0aGUN Cj5XTEFOLUdXIGFuZCB0aGUgQVBzLCBvciAyKSBwcm92aWRlIFVFcyB3aXRoIGEgcmVkdWNlZCBN VFUgKHdoaWNoDQo+aW1wbGllcyB0aGUgUkEgTVRVIG9wdGlvbiBzaG91bGQgYmUgdXNlZCBhbmQg cG9zc2libHkgYWxzbyBUQ1AtTVNTDQo+Y2xhbXBpbmcgYXQgdGhlIFdMQU4tR1cpLiBTaW5jZSB0 aGlzIGlzIGFuIG9wZXJhdGlvbmFsIGd1aWRhbmNlDQo+ZG9jdW1lbnQgSSBiZWxpZXZlIHRoaXMg aXMgc29tZXRoaW5nIHRoYXQgc2hvdWxkIGJlIGRpc2N1c3NlZC4NCj4NCj40KSBJcyBVRSByb2Ft aW5nIGJldHdlZW4gQVBzL0JTU0lEcyBzdXBwb3J0ZWQsIGFuZCBpZiBzbyBob3cgZG9lcyB0aGlz DQo+d29yaz8gQXMgSSB1bmRlcnN0YW5kIGl0LCB0aGUgV0xBTi1HVyB3aWxsIGhhdmUgMSBHUkUg aW50ZXJmYWNlIHBlciBBUCwNCj5zbyBpZiBhIFVFIHJvYW1zIGZyb20gb25lIEFQIHRvIGFub3Ro ZXIsIGl0cyBNQUMgYWRkcmVzcyBhbmQgYWxsIG9mIGl0cw0KPmFzc29jaWF0ZWQgSVB2NiBhZGRy ZXNzZXMgd2lsbCAoZnJvbSB0aGUgV0xBTi1HVydzIFBPVikgbW92ZSBmcm9tIG9uZQ0KPkdSRSBp bnRlcmZhY2UgdG8gYW5vdGhlciwgd2hpY2ggd291bGQgaW4gdHVybiByZXF1aXJlIHRoZSBXTEFO LUdXIHRvDQo+c29tZWhvdyBub3RpY2UgdGhpcyBhbmQgbW92ZSB0aGUgYXNzb2NpYXRlZCAvNjQg YW5kIGFueSBORFAgZW50cmllcw0KPmZyb20gdGhlIHByZXZpb3VzIEdSRSBpbnRlcmZhY2UgdG8g dGhlIGN1cnJlbnQgb25lLiBSaWdodD8gSWYgc28sIHNvbWUNCj5kaXNjdXNzaW9uIG9uIGhvdyB0 aGF0IGhhcHBlbnMgd291bGQgYmUgYXBwcmVjaWF0ZWQgKG9yIGF0IGxlYXN0IGENCj5zdGF0ZW1l bnQgdGhhdCAic2VjcmV0IHZlbmRvciBzYXVjZSBpcyBhc3N1bWVkIHRvIGJlIGFwcGxpZWQgaGVy ZSIgaWYNCj50aGF0IGlzIGluZGVlZCB0aGUgY2FzZSkuDQo+DQo+NSkgVGhpcyBpcyBqdXN0IGEg dGhvdWdodCwgYnV0IHJlZ2FyZGluZyB0aGUgb3BlcmF0aW9uYWwgY29uc2lkZXJhdGlvbg0KPmlu IHNlY3Rpb24gNSByZWdhcmRpbmcgc3VwcG9ydGluZyBwcml2YWN5IGFkZHJlc3NlczogV291bGQg aXQgYmUNCj5wb3NzaWJsZSBmb3IgdGhlIFdMQU4tR1cgdG8gc2ltcGx5IHNlbmQgYWxsIHRyYWZm aWMgZGVzdGluZWQgZm9yIHRoZQ0KPlVFJ3MgZGVkaWNhdGVkIC82NCB0byB0aGUgVUUncyBNQUMg YWRkcmVzcyB3aXRob3V0IG1haW50YWluaW5nIE5EDQo+ZW50cmllcyBmb3IgZWFjaCBhZGRyZXNz IGluIHVzZT8gVGhpcyB3YXksIGEgc2luZ2xlIFVFIGNvdWxkIHVzZQ0KPmdhemlsbGlvbnMgb2Yg SVB2NiBhZGRyZXNzZXMgd2l0aG91dCByaXNraW5nIHJlc291cmNlIGV4aGF1c3Rpb24gaW4gdGhl DQo+V0xBTi1HVy4gT1RPSCwgbWF5YmUgdGhhdCB3b3VsZCBjYXVzZSBwcm9ibGVtcyBmb3IgVUVz IHRoYXQgYXJlDQo+cHJvdmlkaW5nIHRldGhlcmluZyB0byBkb3duc3RyZWFtIGhvc3RzIHVzaW5n IGxheWVyLTIgYnJpZGdpbmc/DQo+DQo+NikgU29tZSBlZGl0b3JpYWwgbml0cyBJIG5vdGljZWQg KGFsdGhvdWdoIEkgd2Fzbid0IHNwZWNpZmljYWxseQ0KPmxvb2tpbmcgZm9yIHRoZW0pOiBNaXNz aW5nIMKrLsK7IGF0IHRoZSBlbmQgb2YgcGFnZSA3LCBzL0xhd2Z1bGwvTGF3ZnVsLw0KPm9uIHBh Z2UgMTIuDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj52Nm9wcyBtYWlsaW5nIGxpc3QNCj52Nm9wc0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg0K From nobody Mon Jan 4 08:14:08 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3B11A8A08 for ; Mon, 4 Jan 2016 08:14:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 syz-KM6g7Gy4 for ; Mon, 4 Jan 2016 08:14:05 -0800 (PST) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C27331A8A0B for ; Mon, 4 Jan 2016 08:14:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u04GEAdO028879; Mon, 4 Jan 2016 08:14:10 -0800 Received: from XCH-PHX-413.sw.nos.boeing.com (xch-phx-413.sw.nos.boeing.com [10.57.37.45]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u04GE83c028857 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 4 Jan 2016 08:14:08 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.52]) by XCH-PHX-413.sw.nos.boeing.com ([169.254.13.207]) with mapi id 14.03.0235.001; Mon, 4 Jan 2016 08:14:02 -0800 From: "Templin, Fred L" To: "fred@cisco.com" , "v6ops@ietf.org" Thread-Topic: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host Thread-Index: AQHRRlkOIXy3SoYak0+sBDXuI8e0xp7rhkPw Date: Mon, 4 Jan 2016 16:14:02 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F988DB@XCH-BLV-504.nw.nos.boeing.com> References: <201601031900.u03J0LMe009763@irp-lnx1.cisco.com> In-Reply-To: <201601031900.u03J0LMe009763@irp-lnx1.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: Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 16:14:07 -0000 Hi, I don't see how this discussion should go forward without a comparison with what AERO already provides. AERO has been around for a long time and has a comprehensive specification on how DHCPv6-PD works over tunnels. It includes solutions for mobility, route optimization, reliabilit= y and fault tolerance, security, multiple interfaces and prefix per host considerations. Although the base AERO spec calls for GUE as the default encapsulation, operation over GRE is specified in a companion document: https://datatracker.ietf.org/doc/draft-templin-aeromin/ I think the authors of unique-ipv6-prefix-per-host need to explain why a different approach than AERO is needed. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of fred@cisco.com > Sent: Sunday, January 03, 2016 11:00 AM > To: v6ops@ietf.org > Subject: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-= per-host >=20 > And now for something a little different. I'd like to invite focused > discussion of draft-ietf-v6ops-unique-ipv6-prefix-per-host, which we > adopted at IETF 94 >=20 > Slides are at > https://www.ietf.org/proceedings/94/slides/slides-94-v6ops-4.pdf. >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Jan 4 08:15:42 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637291A8A42; Mon, 4 Jan 2016 08:15:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 od1H7ttpexl4; Mon, 4 Jan 2016 08:15:38 -0800 (PST) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE5D71A8A27; Mon, 4 Jan 2016 08:15:38 -0800 (PST) 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 u04GFgs8020040; Mon, 4 Jan 2016 08:15:42 -0800 Received: from XCH-BLV-203.nw.nos.boeing.com (xch-blv-203.nw.nos.boeing.com [10.57.37.65]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u04GFYSh019665 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 4 Jan 2016 08:15:34 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.52]) by XCH-BLV-203.nw.nos.boeing.com ([169.254.3.11]) with mapi id 14.03.0235.001; Mon, 4 Jan 2016 08:15:29 -0800 From: "Templin, Fred L" To: Lorenzo Colitti , internet-drafts Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt Thread-Index: AQHRRp/P43RcLEo70kWKFjpvsexeA57riL7w Date: Mon, 4 Jan 2016 16:15:29 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> References: <20160104031639.16535.43111.idtracker@ietfa.amsl.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: multipart/alternative; boundary="_000_2134F8430051B64F815C691A62D9831832F98901XCHBLV504nwnosb_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "v6ops@ietf.org WG" , "i-d-announce@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 16:15:40 -0000 --_000_2134F8430051B64F815C691A62D9831832F98901XCHBLV504nwnosb_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTG9yZW56bywNCg0KSSBiZWxpZXZlIHRoaXMgZG9jdW1lbnQgc2hvdWxkIGFsc28gaW5jbHVk ZSBhbiBpbmZvcm1hdGl2ZSByZWZlcmVuY2UgdG8gQUVSTw0KYXMgdGhlIG1ldGhvZCBmb3IgbWFu YWdpbmcgREhDUHY2LVBEIGRlbGVnYXRlZCBwcmVmaXhlcy4NCg0KVGhhbmtzIOKAkyBGcmVkDQpm cmVkLmwudGVtcGxpbkBib2VpbmcuY29tDQoNCkZyb206IHY2b3BzIFttYWlsdG86djZvcHMtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExvcmVuem8gQ29saXR0aQ0KU2VudDogU3VuZGF5 LCBKYW51YXJ5IDAzLCAyMDE2IDc6MjYgUE0NClRvOiBpbnRlcm5ldC1kcmFmdHMNCkNjOiB2Nm9w c0BpZXRmLm9yZyBXRzsgaS1kLWFubm91bmNlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3Y2b3Bz XSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXY2b3BzLWhvc3QtYWRkci1hdmFpbGFiaWxpdHktMDQu dHh0DQoNCk9uIE1vbiwgSmFuIDQsIDIwMTYgYXQgMTI6MTYgUE0sIDxpbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4+IHdyb3RlOg0KQSBOZXcg SW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJh ZnRzIGRpcmVjdG9yaWVzLg0KIFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIElQdjYg T3BlcmF0aW9ucyBXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLg0KDQogICAgICAgIFRpdGxlICAg ICAgICAgICA6IEhvc3QgYWRkcmVzcyBhdmFpbGFiaWxpdHkgcmVjb21tZW5kYXRpb25zDQogICAg ICAgIEF1dGhvcnMgICAgICAgICA6IExvcmVuem8gQ29saXR0aQ0KICAgICAgICAgICAgICAgICAg ICAgICAgICBWaW50IENlcmYNCiAgICAgICAgICAgICAgICAgICAgICAgICAgU3R1YXJ0IENoZXNo aXJlDQogICAgICAgICAgICAgICAgICAgICAgICAgIERhdmlkIFNjaGluYXppDQogICAgICAgIEZp bGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtdjZvcHMtaG9zdC1hZGRyLWF2YWlsYWJpbGl0eS0w NC50eHQNCiAgICAgICAgUGFnZXMgICAgICAgICAgIDogMTMNCiAgICAgICAgRGF0ZSAgICAgICAg ICAgIDogMjAxNi0wMS0wMw0KDQpbLi4uXQ0KDQpBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVy c2lvbiBpcyBhdmFpbGFibGUgYXQ6DQpodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9 ZHJhZnQtaWV0Zi12Nm9wcy1ob3N0LWFkZHItYXZhaWxhYmlsaXR5LTA0DQoNClN1bW1hcnkgb2Yg dGhlIGNoYW5nZXMgaW4gdGhpcyB2ZXJzaW9uIDoNCg0KICAxLiAgVGhlIHRleHQgYWJvdXQgb21p dHRpbmcgREFEIGFncmVlZCB3aXRoIEZyZWQgVGVtcGxpbi4NCiAgMi4gIFRoZSBzdWdnZXN0aW9u cyBmcm9tIERhdmlkIEZhcm1lciB0byBjbGFyaWZ5IHRoZSBzY29wZSBvZiB0aGUgZG9jdW1lbnQ6 IGV4cGxpY2l0bHkgc2F5IHRoYXQgcHJvdG9jb2wgY2hhbmdlcyBhbmQgaG9zdCBiZWhhdmlvdXIg YXJlIG91dCBvZiBzY29wZSwgcmV3b3JkICJhc3NpZ24iIHRvIHByb3ZpZGUiLCBldGMuDQogIDMu ICBBIHN0YXRlbWVudCB0aGF0IHdoaWxlIFJGQyAzNjMzIHRhbGtzIGFib3V0ICJyZXF1ZXN0aW5n IHJvdXRlciIsIERIQ1B2NiBQRCBpdHNlbGYgZG9lc24ndCBhY3R1YWxseSByZXF1aXJlIHRoYXQg dGhlIGNsaWVudCBmb3J3YXJkIHBhY2tldHMsIGFuZCB0aHVzIGRvZXMgbm90IHJlcXVpcmUgdGhh dCB0aGUgY2xpZW50IGJlIGEgcm91dGVyIGFzIGRlZmluZWQgaW4gUkZDIDI0NjAuDQpDaGVlcnMs DQpMb3JlbnpvDQo= --_000_2134F8430051B64F815C691A62D9831832F98901XCHBLV504nwnosb_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxNjA5 NjU3NDc3Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNDEyNDUyOTM2O30NCm9sDQoJe21hcmdp bi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+SGkgTG9yZW56byw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPkkgYmVsaWV2ZSB0aGlzIGRvY3VtZW50IHNob3VsZCBhbHNvIGluY2x1ZGUgYW4g aW5mb3JtYXRpdmUgcmVmZXJlbmNlIHRvIEFFUk88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+YXMgdGhlIG1l dGhvZCBmb3IgbWFuYWdpbmcgREhDUHY2LVBEIGRlbGVnYXRlZCBwcmVmaXhlcy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyDigJMgRnJlZDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5mcmVkLmwudGVtcGxpbkBib2VpbmcuY29tPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gdjZvcHMgW21h aWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Mb3Jlbnpv IENvbGl0dGk8YnI+DQo8Yj5TZW50OjwvYj4gU3VuZGF5LCBKYW51YXJ5IDAzLCAyMDE2IDc6MjYg UE08YnI+DQo8Yj5Ubzo8L2I+IGludGVybmV0LWRyYWZ0czxicj4NCjxiPkNjOjwvYj4gdjZvcHNA aWV0Zi5vcmcgV0c7IGktZC1hbm5vdW5jZUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW3Y2b3BzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXY2b3BzLWhvc3QtYWRkci1hdmFpbGFi aWxpdHktMDQudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBKYW4gNCwgMjAxNiBhdCAxMjoxNiBQTSwg Jmx0OzxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BIE5ldyBJbnRlcm5ldC1EcmFm dCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3Jp ZXMuPGJyPg0KJm5ic3A7VGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgSVB2NiBPcGVy YXRpb25zIFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IFRpdGxlJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDs6IEhvc3QgYWRkcmVzcyBhdmFpbGFiaWxpdHkgcmVjb21tZW5kYXRpb25zPGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEF1dGhvcnMmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7OiBMb3JlbnpvIENvbGl0dGk8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgVmludCBDZXJmPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IFN0dWFydCBDaGVzaGlyZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBE YXZpZCBTY2hpbmF6aTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBGaWxlbmFtZSZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IGRyYWZ0LWlldGYtdjZvcHMtaG9zdC1hZGRyLWF2 YWlsYWJpbGl0eS0wNC50eHQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgUGFnZXMm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogMTM8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgRGF0ZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IDogMjAxNi0wMS0wMzxicj4NCjxicj4NClsuLi5dPGJyPg0KPGJyPg0KQSBkaWZm IGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Ojxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXY2b3BzLWhvc3Qt YWRkci1hdmFpbGFiaWxpdHktMDQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y Zy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi12Nm9wcy1ob3N0LWFkZHItYXZhaWxhYmlsaXR5LTA0 PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+U3VtbWFyeSBvZiB0aGUgY2hhbmdlcyBpbiB0aGlzIHZlcnNpb24gOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPG9sIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KVGhlIHRleHQgYWJvdXQg b21pdHRpbmcgREFEIGFncmVlZCB3aXRoIEZyZWQgVGVtcGxpbi48bzpwPjwvbzpwPjwvbGk+PGxp IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpUaGUgc3VnZ2Vz dGlvbnMgZnJvbSBEYXZpZCBGYXJtZXIgdG8gY2xhcmlmeSB0aGUgc2NvcGUgb2YgdGhlIGRvY3Vt ZW50OiBleHBsaWNpdGx5IHNheSB0aGF0IHByb3RvY29sIGNoYW5nZXMgYW5kIGhvc3QgYmVoYXZp b3VyIGFyZSBvdXQgb2Ygc2NvcGUsIHJld29yZCAmcXVvdDthc3NpZ24mcXVvdDsgdG8gcHJvdmlk ZSZxdW90OywgZXRjLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1s aXN0OmwwIGxldmVsMSBsZm8xIj4NCkEgc3RhdGVtZW50IHRoYXQgd2hpbGUgUkZDIDM2MzMgdGFs a3MgYWJvdXQgJnF1b3Q7cmVxdWVzdGluZyByb3V0ZXImcXVvdDssIERIQ1B2NiBQRCBpdHNlbGYg ZG9lc24ndCBhY3R1YWxseSByZXF1aXJlIHRoYXQgdGhlIGNsaWVudCBmb3J3YXJkIHBhY2tldHMs IGFuZCB0aHVzIGRvZXMgbm90IHJlcXVpcmUgdGhhdCB0aGUgY2xpZW50IGJlIGEgcm91dGVyIGFz IGRlZmluZWQgaW4gUkZDIDI0NjAuPG86cD48L286cD48L2xpPjwvb2w+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGVlcnMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Mb3JlbnpvJm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_2134F8430051B64F815C691A62D9831832F98901XCHBLV504nwnosb_-- From nobody Mon Jan 4 08:24:42 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FBE01A8A4A for ; Mon, 4 Jan 2016 08:24:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.308 X-Spam-Level: X-Spam-Status: No, score=-4.308 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 M0kqBKdx1PDv for ; Mon, 4 Jan 2016 08:24:38 -0800 (PST) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.119.20]) by ietfa.amsl.com (Postfix) with ESMTP id A01E41A8A48 for ; Mon, 4 Jan 2016 08:24:38 -0800 (PST) Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com [209.85.213.175]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128/128); for ; Mon, 4 Jan 2016 10:24:35 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ig0-f175.google.com [209.85.213.175] #+LO+TS+TR X-Umn-Classification: local Received: by mail-ig0-f175.google.com with SMTP id mw1so107236319igb.1 for ; Mon, 04 Jan 2016 08:24:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to; bh=nOu9/F/XO/9ngDW14bVAENDtLZpT1SA8GjiBUiyFu7I=; b=mstsKVFc6JXWaEjF8aL4yY6UaqKzRqFEG9BQh+JTVKEXIya68zGdYQ8aXEhfPRsuug dC+GWGeddm91w6lLLA1JDak2+wIMq+Ljm6WuEZ33dsx8NO4OQGvoYZgt+W2hRD2X0rtn 9m5Je659uni5XHTLnZ+MJijOTfCvhrFwvicZo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:in-reply-to:mime-version:content-type :message-id:content-transfer-encoding:cc:from:subject:date:to; bh=nOu9/F/XO/9ngDW14bVAENDtLZpT1SA8GjiBUiyFu7I=; b=A8KU559BEl2Wb3hlVsQ0Jg07HIYYynlIh9lfz1kmCk0vHiLRYaMYIlbORmvhp/FZiO PC/+9gvC38J6D70fhzt1dvritGUVmtxuER3HMwwUiGjd88oUH5OSVj1YE3Z33RujaJTg aPCdQ1qAaQR6mWt9q7WMVzYWi5TRPzRbasgbZA6tQxfNZTMiExrxq8mN+aLL3PyZZhld u8LqvhbAH0DORkmzkqMBHXJgfimhdbVstCwDkfQ6MgiIdctRD9XFfcGDzhi/yzkQwVNF Hj3TvKn/7YjkJNx7YGfVrwmTAK/1CjrG3KPw4jzwOLiH8uC5ed/4GAo+M5fcO6CaYY+Q cCpQ== X-Gm-Message-State: ALoCoQmlNyk5jLHGl5ixMjYaJ73d1dR6BDVhIIf9zRYp2YYyYBLA4nlPzQ/lcAmJYofpxtNxnQJeRg3wwNbyMBuBmKiFHe4QQCdqmmMp2QNmYC6bD7wCPh9Wn51xH5MRHhHA1i8semU1rJSAKTGG2D8p3Cj1T2MZeQ== X-Received: by 10.50.160.43 with SMTP id xh11mr58840247igb.73.1451924674468; Mon, 04 Jan 2016 08:24:34 -0800 (PST) X-Received: by 10.50.160.43 with SMTP id xh11mr58840239igb.73.1451924674299; Mon, 04 Jan 2016 08:24:34 -0800 (PST) Received: from [10.0.0.7] (c-68-47-68-88.hsd1.mn.comcast.net. [68.47.68.88]) by smtp.gmail.com with ESMTPSA id j136sm10621955ioj.32.2016.01.04.08.24.32 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Jan 2016 08:24:32 -0800 (PST) References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <568A689F.4060204@gmail.com> In-Reply-To: <568A689F.4060204@gmail.com> Mime-Version: 1.0 (1.0) Content-Type: multipart/alternative; boundary=Apple-Mail-9E0CF2CB-6D7F-47E4-91CD-30153BDDFCF1 Message-Id: <9B04B81C-311B-4199-8398-1D4D64F74848@umn.edu> Content-Transfer-Encoding: 7bit X-Mailer: iPad Mail (13C75) From: David Farmer Date: Mon, 4 Jan 2016 10:24:31 -0600 To: Alexandre Petrescu Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 16:24:40 -0000 --Apple-Mail-9E0CF2CB-6D7F-47E4-91CD-30153BDDFCF1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Jan 4, 2016, at 06:42, Alexandre Petrescu wrote: > Le 04/01/2016 04:25, Lorenzo Colitti a =C3=A9crit : >>=20 >> 3. A statement that while RFC 3633 talks about "requesting router", >> DHCPv6 PD itself doesn't actually require that the client forward >> packets, and thus does not require that the client be a router as >> defined in RFC 2460. >=20 > Lorenzo - I noticed earlier emails where a doubt about DHCP-PD RFC relying= on these to be Routers, or not. >=20 > I agree with you the DHCP-PD RFC calls them Routers. It may rightfully no= t go too deep into requiring them to forward packets or maintain a FIB. It w= ould be too many things to require. Maybe just calling them Routers is suff= icient, for brevity. >=20 > At the same time, certainly DHCP-PD RFC is not specified with Hosts in min= d and this is not good. >=20 > Alex In RFC3633, requesting router is defined "the router that acts as a DHCP cli= ent and is requesting prefix(es) to be assigned." In RFC3315, DHCP Client (= or Client) is defined as, "a node that initiates requests on a link to obtai= n configuration parameters from one or more DHCP servers." With the clarifi= cation Lorenzo provides I think it is clear that DHCPv6 PD is just a protoco= l to obtain a prefix as a configuration parameter and makes no requirements t= hat only routers can obtain prefixes. How about the further clarification; While [RFC3633] primarily considers the use case defined in [RFC3769] and= =20 refers to the DHCP client as a "requesting router", DHCPv6 PD itself does= not=20 require that the DHCP client receiving the IPv6 prefix parameter forward=20= IPv6 packets not addressed to itself, and thus does not require that the D= HCP=20 client be an IPv6 router as defined in [RFC2460]. =20 Thanks --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota =20 2218 University Ave SE Phone: +1-612-626-0815 Minneapolis, MN 55414-3029 Cell: +1-612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --Apple-Mail-9E0CF2CB-6D7F-47E4-91CD-30153BDDFCF1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On Jan 4, 2016, at 06:42, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:
Le 04/01/2016 04:25, Lorenzo Colitt= i a =C3=A9crit :
3. A statement that w= hile RFC 3633 talks about "requesting router",
   DHCPv6 PD itself doesn't actual= ly require that the client forward
   packets, and thus does not require that the c= lient be a router as
=    defined in RFC 2460.
=
Lorenzo - I noticed earlier emails where a doubt about DHCP-PD RFC= relying on these to be Routers, or not.

I a= gree with you the DHCP-PD RFC calls them Routers.  It may rightfully no= t go too deep into requiring them to forward packets or maintain a FIB. &nbs= p;It would be too many things to require.  Maybe just calling them Rout= ers is sufficient, for brevity.

At the same= time, certainly DHCP-PD RFC is not specified with Hosts in mind and this is= not good.

Alex
In RFC=
3633, requesting router is defined "the router that acts as a DHCP client an=
d is
                       requesting prefix(es) to be assigned."  <=
/font>In RFC3315, DHCP Client (or=
 Client) is defined as, "a node that initiates requests on a link to obtain c=
onfiguration parameters from one or more DHCP servers."  With the clari=
fication Lorenzo pro=
vides I think it is clear that DHCPv6 PD is just a protocol to obtain a pref=
ix as a configuration parameter and makes no requirements that only routers c=
an obtain prefixes.

How about the further clarification=
;

   While [RFC3633] primarily considers the u=
se case defined in [RFC3769] and 
   refers to the&nb=
sp;DHCP client as a "requesting router", DHCPv6 PD itself does not 
   require that the DH=
CP client receiving the IPv6 prefix parameter forward 
   IPv= 6 packets not addresse= d to itself, and thus does not require that the DHCP 
   clien=
t be an IPv6 router a=
s defined in [RFC2460].  

Thanks

-- 
=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer   &nb=
sp;                     &n=
bsp;Email: farmer@umn.edu
Office of Informatio=
n Technology
University of Minnesota    
2218 University Ave SE      =
;   Phone: +1-612-626-0815
Minneapolis, MN 55414-3029   Cell: +1-612-812-9=
952
=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


= --Apple-Mail-9E0CF2CB-6D7F-47E4-91CD-30153BDDFCF1-- From nobody Mon Jan 4 08:41:00 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB071A8A7E for ; Mon, 4 Jan 2016 08:40:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 7jgfECGuUfrJ for ; Mon, 4 Jan 2016 08:40:57 -0800 (PST) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54F3F1A8A7B for ; Mon, 4 Jan 2016 08:40:57 -0800 (PST) Received: by mail-yk0-x22c.google.com with SMTP id k129so230753539yke.0 for ; Mon, 04 Jan 2016 08:40:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=NaZr9/kWXLLdpQnUW9aejr5EEcJZ1BpXTiwpZVPl988=; b=VH9QS6jT+UMdsDPezKdBfS4YhHF/kMuyUjOhmbwBIwb8FfvKuqCmkR0/sbApwumLMM XRsjTBDaMkTL7YQTNfwW5BJqcL8KFIK+3d5z3EH/3tImcIWskusje1eCEna50sKpPMP9 rn/gUceSkc3p7KqrWevY3wkhIi3UNuJpya5BEJ9f6NdDRh58C2Dt6GPcZ7ABLzSzvSZ8 wQDqU18cY+AYh8H6qunASryvi0Vydbq1rnPxESX/m7GQm16A7mgb3LImSsTEgCDOqx/y 4cO+UIvB3F+1ZLQIxofjeeBsmLRlNF0zRSK/eOYIWzjmps5JyNOHZxCB2J02mXKCWn7V 4jGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=NaZr9/kWXLLdpQnUW9aejr5EEcJZ1BpXTiwpZVPl988=; b=JSe3ue7BoeyxR0edynlFhP5P2bu300uQUGFNfxs/jmfvEAhYyAlR02iqU4k0TarPzK GGRlowqb54kUaDyvkqtYfhO9RTW2fcyBV8s4zpxfQ3Xc1Fe5Nf3NRGVndmn/s2gGMPET pDpwuoHkDMWQcivQUMRRuZi8dEkm5Z+xVH9O7dlOxjeZGnfDDXdVR2w6BHYozGE//R3q JzzUYShpJ1uTI+m411WRnnJ4yBH+RFDTQjJ3AE+r1h6rNz6j9PRTE1U2TwOqh5J1rFkx TnjVM1apSEDDHtWb4BUU+rLXVXEvFKEVk9wWys92WjTeITfbEAjdorQGJPldgTOFBxFX ZJOg== X-Gm-Message-State: ALoCoQlkKKpQpXDk1GqMJ2uMBXjCWaRf2j0KKOzfckTL5YwtPC4+6tABynlOUfU35yR4cbXK5szheaUGVu1VyHd8t2XIcl2Q+R65obh9Yja6R+8MhpEBpBU= X-Received: by 10.129.108.88 with SMTP id h85mr73225485ywc.156.1451925656441; Mon, 04 Jan 2016 08:40:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.208.201 with HTTP; Mon, 4 Jan 2016 08:40:36 -0800 (PST) In-Reply-To: <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> From: Lorenzo Colitti Date: Tue, 5 Jan 2016 01:40:36 +0900 Message-ID: To: "Templin, Fred L" Content-Type: multipart/alternative; boundary=001a114d88f0fecaaf052884c8bd Archived-At: Cc: "v6ops@ietf.org WG" , internet-drafts , "i-d-announce@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 16:40:59 -0000 --001a114d88f0fecaaf052884c8bd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Fred. I do not think it is appropriate to add such a reference. AERO is only one way to use address space delegated by DHCPv6 PD, and there are other, perhaps more obvious ways, such as using the addresses directly without a tunnel. I think providing a taxonomy of the different ways to make DHCPv6 PD work is out of scope for a document whose primary message but "don't limit the number of addresses the network hands out to hosts". Cheers, Lorenzo On Tue, Jan 5, 2016 at 1:15 AM, Templin, Fred L wrote: > Hi Lorenzo, > > > > I believe this document should also include an informative reference to > AERO > > as the method for managing DHCPv6-PD delegated prefixes. > > > > Thanks =E2=80=93 Fred > > fred.l.templin@boeing.com > > > > *From:* v6ops [mailto:v6ops-bounces@ietf.org] *On Behalf Of *Lorenzo > Colitti > *Sent:* Sunday, January 03, 2016 7:26 PM > *To:* internet-drafts > *Cc:* v6ops@ietf.org WG; i-d-announce@ietf.org > *Subject:* Re: [v6ops] I-D Action: > draft-ietf-v6ops-host-addr-availability-04.txt > > > > On Mon, Jan 4, 2016 at 12:16 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 Operations Working Group of the > IETF. > > Title : Host address availability recommendations > Authors : Lorenzo Colitti > Vint Cerf > Stuart Cheshire > David Schinazi > Filename : draft-ietf-v6ops-host-addr-availability-04.txt > Pages : 13 > Date : 2016-01-03 > > [...] > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-host-addr-availabili= ty-04 > > > > Summary of the changes in this version : > > 1. The text about omitting DAD agreed with Fred Templin. > 2. The suggestions from David Farmer to clarify the scope of the > document: explicitly say that protocol changes and host behaviour are = out > of scope, reword "assign" to provide", etc. > 3. A statement that while RFC 3633 talks about "requesting router", > DHCPv6 PD itself doesn't actually require that the client forward pack= ets, > and thus does not require that the client be a router as defined in RF= C > 2460. > > Cheers, > > Lorenzo > --001a114d88f0fecaaf052884c8bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Fred.

I do not think it is appropriate = to add such a reference. AERO is only one way to use address space delegate= d by DHCPv6 PD, and there are other, perhaps more obvious ways, such as usi= ng the addresses directly without a tunnel. I think providing a taxonomy of= the different ways to make DHCPv6 PD work is out of scope for a document w= hose primary message but "don't limit the number of addresses the = network hands out to hosts".

Cheers,
Lorenzo

On Tue, Jan 5, 2016 at 1:15 AM, Templin, Fred L <<= a href=3D"mailto:Fred.L.Templin@boeing.com" target=3D"_blank">Fred.L.Templi= n@boeing.com> wrote:

Hi Lorenzo,

=C2=A0

I believe this document should also i= nclude an informative reference to AERO

as the method for managing DHCPv6-PD = delegated prefixes.

=C2=A0

Thanks =E2=80=93 Fred

fred.l.templin@boeing.com

=C2=A0

From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Lorenzo Colitti
Sent: Sunday, January 03, 2016 7:26 PM
To: internet-drafts
Cc: v6ops@ietf.o= rg WG; i-d-a= nnounce@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availabi= lity-04.txt

=C2=A0

On Mon, Jan 4, 2016 at 12:16 PM, <internet-drafts@ietf.org= > wrote:

A New Internet-Draft is available from the on-line I= nternet-Drafts directories.
=C2=A0This draft is a work item of the IPv6 Operations Working Group of the= IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Host address availability recommendations
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Lore= nzo Colitti
=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 Vint Cerf
=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 Stuart Cheshire
=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 David Schinazi
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-v6ops-host-addr-availability-04.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 13
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-01-03

[...]

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft= -ietf-v6ops-host-addr-availability-04

=C2=A0

Summary of the changes in this version :

  1. The text about omitting DAD agreed with Fred Templin.
    2. The suggestions from David Farmer to clarify the scope of the document: exp= licitly say that protocol changes and host behaviour are out of scope, rewo= rd "assign" to provide", etc.
  2. A statement that while RFC 3633 talks about "requesting router", = DHCPv6 PD itself doesn't actually require that the client forward packe= ts, and thus does not require that the client be a router as defined in RFC= 2460.

Cheers,

Lorenzo=C2=A0


--001a114d88f0fecaaf052884c8bd-- From nobody Mon Jan 4 08:46:06 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCB5F1A8A8A for ; Mon, 4 Jan 2016 08:46:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 x0nsN9esoZRp for ; Mon, 4 Jan 2016 08:46:03 -0800 (PST) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5890B1A8A87 for ; Mon, 4 Jan 2016 08:46:03 -0800 (PST) Received: by mail-yk0-x230.google.com with SMTP id x67so252839604ykd.2 for ; Mon, 04 Jan 2016 08:46:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=IsbPaZP8EiZa9grtK3CH+G63K1wggHWl0ozZIsgBBN8=; b=Q0c/erB1zlITYPSE+A7EyWOgS5mHjS/krn/A4ZKg2GFAweoVjR14w9GD2ivIOMyLx5 WNAb9ZbFCbKbd365GAjTjYycT7+34ZA2B9zV4hMs5G2TrAR1Do+K5p4Ok2yG1AiUhmpY EwLgklSJ3248q60k1zucTA5k88eUOh+syn9punJUoKwEweXl7FwlXBtZ0lwYjbG7u50Q APlewswHlYT7VjKzjlUlafAMreRewPbJ8mAvL4JDhZ3AfrsxhndccitpKRSrD/fSKFQI u7eQpd+qjrJ+pafQ5zuoW2c+lQgfaBte974SaFMIBhNevNt133IhzT+iOS5Res+KbP7r h3Qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=IsbPaZP8EiZa9grtK3CH+G63K1wggHWl0ozZIsgBBN8=; b=X0LOHE5Gj1/qEp73wxh306/n2w6kkvG4ulfRcmY4h5B8sfa+pyTzRAp219TyTeDvBS vT8O13yzZ5HsYzFBuppmCw/WcMy+rZExKlxkur0tKiqZCh7KnqqEj/X2nUPycPa7puLI 5ksxNbeNMNWht+XbDq/fl4X3MQyfNvyomod8LbuGE6uwodSzJVcgIzOEh0zHifPDSj9R M4ua2wAJOlXLXOpNaxXSztLugpCpQrCX3i64rX4Q7n3ynu1wWcV+ugT7KXl2TwJVe9p2 sS/DW+JamQFT1DgyRWJm6j4hr65YWq9AAyb2aBaJJo8oWWDrvreOkvJad9ztkP2TmYWO 7Xpw== X-Gm-Message-State: ALoCoQmSinvoP95epl6zOCJLrFrYTV/YhAeRaOXcfAcY23Ix5RVRNWdHjpESZiFgP5iQKSqKfU7EY/QAo/TXz+XcUKr1EN793ba9F/zmrMDZARvigxugoTw= X-Received: by 10.129.108.88 with SMTP id h85mr73245640ywc.156.1451925962528; Mon, 04 Jan 2016 08:46:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.208.201 with HTTP; Mon, 4 Jan 2016 08:45:43 -0800 (PST) In-Reply-To: <568A689F.4060204@gmail.com> References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <568A689F.4060204@gmail.com> From: Lorenzo Colitti Date: Tue, 5 Jan 2016 01:45:43 +0900 Message-ID: To: Alexandre Petrescu Content-Type: multipart/alternative; boundary=001a114d88f03d0714052884db76 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 16:46:05 -0000 --001a114d88f03d0714052884db76 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 4, 2016 at 9:42 PM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > I agree with you the DHCP-PD RFC calls them Routers. It may rightfully > not go too deep into requiring them to forward packets or maintain a FIB. > It would be too many things to require. Maybe just calling them Routers is > sufficient, for brevity. > Do you disagree with the text that is in the draft now? While [RFC3633] assumes that the DHCPv6 client is a router, DHCPv6 PD itself does not require that the client forward IPv6 packets not addressed to itself, and thus does not require that the client be an IPv6 router as defined in [RFC2460]. That statement seems pretty straightforward to me. --001a114d88f03d0714052884db76 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jan 4, 2016 at 9:42 PM, Alexandre Petrescu <alexandre.petre= scu@gmail.com> wrote:
I agree with you th= e DHCP-PD RFC calls them Routers.=C2=A0 It may rightfully not go too deep i= nto requiring them to forward packets or maintain a FIB.=C2=A0 It would be = too many things to require.=C2=A0 Maybe just calling them Routers is suffic= ient, for brevity.

Do you disagree with= the text that is in the draft now?

=C2=A0 =C2=A0 = =C2=A0 While [RFC3633] assumes that the DHCPv6 client is a router, DHCPv6
=C2=A0 =C2=A0 =C2=A0 PD itself does not require that the client fo= rward IPv6 packets
=C2=A0 =C2=A0 =C2=A0 not addressed to itself, = and thus does not require that the client
=C2=A0 =C2=A0 =C2=A0 be= an IPv6 router as defined in [RFC2460].

That stat= ement seems pretty straightforward to me.
--001a114d88f03d0714052884db76-- From nobody Mon Jan 4 08:49:49 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23BB1A8A9D for ; Mon, 4 Jan 2016 08:49:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NuT-oXvVTci3 for ; Mon, 4 Jan 2016 08:49:46 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD7411A8A9B for ; Mon, 4 Jan 2016 08:49:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11050; q=dns/txt; s=iport; t=1451926185; x=1453135785; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=j1dNYUOZN1x3NKpLQX/VbDI3Hst6KgRSY3itbmD8PS4=; b=MseLdhj04CVLySquVYRufTe9j5MphVR856etNu+xzcKw0qOxGFBTKrlX ySggBp3pqCe8inOQufwfp/aO/a6OOny7QhK+6HW7nkwwL1T+TSawTgKUZ h8RXYmyLciOXc/waIR7F6/r37JN5wQ89GghntNZ56ByW765UEkmeTsw/B A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AAAgDToYpW/4ENJK1egm5MUm0GiFOzd?= =?us-ascii?q?gENgWQkhWsCHIEAOBQBAQEBAQEBgQqENAEBAQQjVhACAQgRAwECKAMCAgIwFAk?= =?us-ascii?q?IAgQOBRuIFA6wEpBhAQEBAQEBAQEBAQEBAQEBAQEBAQEBFASGVgGEfoR3DYJvg?= =?us-ascii?q?UkFlwYBjVCOe445ASABAUKCERyBXXKECIEIAQEB?= X-IronPort-AV: E=Sophos; i="5.20,521,1444694400"; d="scan'208,217"; a="60420441" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Jan 2016 16:49:44 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u04Gni32029556 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 4 Jan 2016 16:49:44 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 4 Jan 2016 11:49:43 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Mon, 4 Jan 2016 11:49:43 -0500 From: "Eric Vyncke (evyncke)" To: Lorenzo Colitti Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt Thread-Index: AQHRRw/pk+sITWQgL0CUhgpxYB2D+w== Date: Mon, 4 Jan 2016 16:49:43 +0000 Message-ID: References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.56.4] Content-Type: multipart/alternative; boundary="_000_D2B05FC56374Cevynckeciscocom_" MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 16:49:47 -0000 --_000_D2B05FC56374Cevynckeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB3YXMgc2lsZW50IGluIGZyb250IG9mIHRoZSBhdmFsYW5jaGUgYWJvdXQgLTAzIGJ1dCBhcyB0 aGluZ3MgYXJlIHF1aWV0ZXIgbm93Og0KDQpUaGlzIGRvY3VtZW50IGlzIG9uIHRoZSBvYnZpb3Vz IHNpZGUgZm9yIHByb2JsZW0gc3RhdGVtZW50IGFuZCBzb2x1dGlvbnMgKGFsbCBzZW5zaWJsZSku DQoNCkkgd291bGQgYXJndWUgdGhhdCBhIGxvdCBvZiB0ZXh0IGNvdWxkIGJlIHJlbW92ZWQgKHN1 Y2ggYXMgdGhlIGRpc2N1c3Npb24gb24gd2h5IG9yZ2FuaXphdGlvbnMgdXNlIERIQ1AgcmF0aGVy IHRoYW4gU0xBQUMgLS0gYnV0IGhleSBteSBvd24gZW1wbG95ZXIgdXNlcyBESENQIDotKSApDQoN ClNvbWUgcXVlc3Rpb25zOg0KDQogICogICBRMSkgVGhlIEktRCBpcyBhYm91dCBtdWx0aXBsZSBh ZGRyZXNzZXMgd2l0aCBhIHByZWZpeCwgYnV0LCBzaG91bGQgaXQgbWVudGlvbiBhcyB3ZWxsIHRo ZSBwb3NzaWJpbGl0eSBvZiBoYXZpbmcgZGlmZmVyZW50IHByZWZpeGVzPyAow6AgbGEgTUlGIG9u IGEgc2luZ2xlIGxpbmspID09PiBzaG91bGQgZXhwbGljaXRlbHkgcmVkdWNlIHRoZSBzY29wZSBv ZiB0aGUgSS1EDQogICogICBRMikgQW55IHJlYXNvbiB3aHkgb25seSBhIC82NCBwZXIgaG9zdCB3 aGVuIHVzaW5nIERIQ1AtUEQ/DQogICogICBRMykgU2hvdWxkIHRoZSBJLUQgd3JpdGUgYW55dGhp bmcgYWJvdXQgdGhlIHN0YWJpbGl0eSBvZiB0aGUgZGVsZWdhdGVkIHByZWZpeD8gSS5lLiBCZWlu ZyBhbHdheXMgdGhlIHNhbWUgZm9yIHRoZSBzYW1lIERVSUQ/IEdvYWw6IGF2b2lkIHJlbnVtYmVy aW5nIHdpdGhpbiB0aGUgaG9zdD8gT2YgY291cnNlICdpZiB0ZWNobmljYWxseSBmZWFzaWJsZScN Cg0KLcOpcmljDQoNCkZyb206IHY2b3BzIDx2Nm9wcy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzp2 Nm9wcy1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIExvcmVuem8gQ29saXR0aSA8bG9y ZW56b0Bnb29nbGUuY29tPG1haWx0bzpsb3JlbnpvQGdvb2dsZS5jb20+Pg0KRGF0ZTogbHVuZGkg NCBqYW52aWVyIDIwMTYgMDQ6MjUNClRvOiBpbnRlcm5ldC1kcmFmdHMgPGludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPj4NCkNjOiAidjZvcHNA aWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPiBXRyIgPHY2b3BzQGlldGYub3JnPG1haWx0 bzp2Nm9wc0BpZXRmLm9yZz4+LCAiaS1kLWFubm91bmNlQGlldGYub3JnPG1haWx0bzppLWQtYW5u b3VuY2VAaWV0Zi5vcmc+IiA8aS1kLWFubm91bmNlQGlldGYub3JnPG1haWx0bzppLWQtYW5ub3Vu Y2VAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFt2Nm9wc10gSS1EIEFjdGlvbjogZHJhZnQtaWV0 Zi12Nm9wcy1ob3N0LWFkZHItYXZhaWxhYmlsaXR5LTA0LnR4dA0KDQpPbiBNb24sIEphbiA0LCAy MDE2IGF0IDEyOjE2IFBNLCA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmc+PiB3cm90ZToNCkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWls YWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCiBUaGlz IGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBJUHY2IE9wZXJhdGlvbnMgV29ya2luZyBHcm91 cCBvZiB0aGUgSUVURi4NCg0KICAgICAgICBUaXRsZSAgICAgICAgICAgOiBIb3N0IGFkZHJlc3Mg YXZhaWxhYmlsaXR5IHJlY29tbWVuZGF0aW9ucw0KICAgICAgICBBdXRob3JzICAgICAgICAgOiBM b3JlbnpvIENvbGl0dGkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgVmludCBDZXJmDQogICAg ICAgICAgICAgICAgICAgICAgICAgIFN0dWFydCBDaGVzaGlyZQ0KICAgICAgICAgICAgICAgICAg ICAgICAgICBEYXZpZCBTY2hpbmF6aQ0KICAgICAgICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1p ZXRmLXY2b3BzLWhvc3QtYWRkci1hdmFpbGFiaWxpdHktMDQudHh0DQogICAgICAgIFBhZ2VzICAg ICAgICAgICA6IDEzDQogICAgICAgIERhdGUgICAgICAgICAgICA6IDIwMTYtMDEtMDMNCg0KWy4u Ll0NCg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtdjZvcHMtaG9zdC1h ZGRyLWF2YWlsYWJpbGl0eS0wNA0KDQpTdW1tYXJ5IG9mIHRoZSBjaGFuZ2VzIGluIHRoaXMgdmVy c2lvbiA6DQoNCiAgMS4gIFRoZSB0ZXh0IGFib3V0IG9taXR0aW5nIERBRCBhZ3JlZWQgd2l0aCBG cmVkIFRlbXBsaW4uDQogIDIuICBUaGUgc3VnZ2VzdGlvbnMgZnJvbSBEYXZpZCBGYXJtZXIgdG8g Y2xhcmlmeSB0aGUgc2NvcGUgb2YgdGhlIGRvY3VtZW50OiBleHBsaWNpdGx5IHNheSB0aGF0IHBy b3RvY29sIGNoYW5nZXMgYW5kIGhvc3QgYmVoYXZpb3VyIGFyZSBvdXQgb2Ygc2NvcGUsIHJld29y ZCAiYXNzaWduIiB0byBwcm92aWRlIiwgZXRjLg0KICAzLiAgQSBzdGF0ZW1lbnQgdGhhdCB3aGls ZSBSRkMgMzYzMyB0YWxrcyBhYm91dCAicmVxdWVzdGluZyByb3V0ZXIiLCBESENQdjYgUEQgaXRz ZWxmIGRvZXNuJ3QgYWN0dWFsbHkgcmVxdWlyZSB0aGF0IHRoZSBjbGllbnQgZm9yd2FyZCBwYWNr ZXRzLCBhbmQgdGh1cyBkb2VzIG5vdCByZXF1aXJlIHRoYXQgdGhlIGNsaWVudCBiZSBhIHJvdXRl ciBhcyBkZWZpbmVkIGluIFJGQyAyNDYwLg0KDQpDaGVlcnMsDQpMb3JlbnpvDQo= --_000_D2B05FC56374Cevynckeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <55705B0BFDDC3E43819511B7A3D3B4D0@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5JIHdhcyBzaWxl bnQgaW4gZnJvbnQgb2YgdGhlIGF2YWxhbmNoZSBhYm91dCAtMDMgYnV0IGFzIHRoaW5ncyBhcmUg cXVpZXRlciBub3c6PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGlzIGRvY3VtZW50 IGlzIG9uIHRoZSBvYnZpb3VzIHNpZGUgZm9yIHByb2JsZW0gc3RhdGVtZW50IGFuZCBzb2x1dGlv bnMgKGFsbCBzZW5zaWJsZSkuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JIHdvdWxk IGFyZ3VlIHRoYXQgYSBsb3Qgb2YgdGV4dCBjb3VsZCBiZSByZW1vdmVkIChzdWNoIGFzIHRoZSBk aXNjdXNzaW9uIG9uIHdoeSBvcmdhbml6YXRpb25zIHVzZSBESENQIHJhdGhlciB0aGFuIFNMQUFD IC0tIGJ1dCBoZXkgbXkgb3duIGVtcGxveWVyIHVzZXMgREhDUCA6LSkgKTwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxkaXY+U29tZSBxdWVzdGlvbnM6PC9kaXY+DQo8dWw+DQo8bGk+UTEpIFRo ZSBJLUQgaXMgYWJvdXQgbXVsdGlwbGUgYWRkcmVzc2VzIHdpdGggYSBwcmVmaXgsIGJ1dCwgc2hv dWxkIGl0IG1lbnRpb24gYXMgd2VsbCB0aGUgcG9zc2liaWxpdHkgb2YgaGF2aW5nIGRpZmZlcmVu dCBwcmVmaXhlcz8gKMOgIGxhIE1JRiBvbiBhIHNpbmdsZSBsaW5rKSA9PSZndDsgc2hvdWxkIGV4 cGxpY2l0ZWx5IHJlZHVjZSB0aGUgc2NvcGUgb2YgdGhlIEktRDwvbGk+PGxpPlEyKSBBbnkgcmVh c29uIHdoeSBvbmx5IGEgLzY0IHBlciBob3N0IHdoZW4gdXNpbmcgREhDUC1QRD8mbmJzcDs8L2xp PjxsaT5RMykgU2hvdWxkIHRoZSBJLUQgd3JpdGUgYW55dGhpbmcgYWJvdXQgdGhlIHN0YWJpbGl0 eSBvZiB0aGUgZGVsZWdhdGVkIHByZWZpeD8gSS5lLiBCZWluZyBhbHdheXMgdGhlIHNhbWUgZm9y IHRoZSBzYW1lIERVSUQ/IEdvYWw6IGF2b2lkIHJlbnVtYmVyaW5nIHdpdGhpbiB0aGUgaG9zdD8g T2YgY291cnNlICdpZiB0ZWNobmljYWxseSBmZWFzaWJsZSc8L2xpPjwvdWw+DQo8ZGl2Pi3DqXJp YzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElP TiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4 dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJP UkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZU OiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7 IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj52Nm9wcyAmbHQ7PGEgaHJlZj0ibWFp bHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmciPnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0 OyBvbiBiZWhhbGYgb2YgTG9yZW56byBDb2xpdHRpICZsdDs8YSBocmVmPSJtYWlsdG86bG9yZW56 b0Bnb29nbGUuY29tIj5sb3JlbnpvQGdvb2dsZS5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxl PSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+bHVuZGkgNCBqYW52aWVyIDIwMTYgMDQ6 MjU8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj5pbnRlcm5l dC1kcmFmdHMgJmx0OzxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPmlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2Vp Z2h0OmJvbGQiPkNjOiA8L3NwYW4+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3Jn Ij52Nm9wc0BpZXRmLm9yZzwvYT4gV0cmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp2Nm9wc0Bp ZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmkt ZC1hbm5vdW5jZUBpZXRmLm9yZyI+aS1kLWFubm91bmNlQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmktZC1hbm5vdW5jZUBpZXRmLm9yZyI+aS1kLWFubm91bmNlQGlldGYu b3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDog PC9zcGFuPlJlOiBbdjZvcHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdjZvcHMtaG9zdC1hZGRy LWF2YWlsYWJpbGl0eS0wNC50eHQ8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJP UkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAw IDU7Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9l eHRyYSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gTW9uLCBKYW4gNCwgMjAxNiBhdCAx MjoxNiBQTSwgPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9h PiZndDs8L3NwYW4+IHdyb3RlOjxicj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIg c3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDtib3JkZXItbGVmdC13aWR0aDoxcHg7Ym9y ZGVyLWxlZnQtY29sb3I6cmdiKDIwNCwyMDQsMjA0KTtib3JkZXItbGVmdC1zdHlsZTpzb2xpZDtw YWRkaW5nLWxlZnQ6MWV4Ij4NCkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9t IHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy48YnI+DQombmJzcDtUaGlz IGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBJUHY2IE9wZXJhdGlvbnMgV29ya2luZyBHcm91 cCBvZiB0aGUgSUVURi48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgVGl0 bGUmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogSG9zdCBhZGRyZXNz IGF2YWlsYWJpbGl0eSByZWNvbW1lbmRhdGlvbnM8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgQXV0aG9ycyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IExvcmVuem8g Q29saXR0aTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBWaW50IENlcmY8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgU3R1YXJ0IENoZXNoaXJlPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IERhdmlkIFNjaGluYXppPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEZpbGVuYW1lJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IDogZHJhZnQtaWV0Zi12Nm9wcy1ob3N0LWFkZHItYXZhaWxhYmlsaXR5LTA0LnR4dDxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBQYWdlcyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiAxMzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBEYXRlJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiAyMDE2LTAx LTAzPGJyPg0KPGJyPg0KWy4uLl08YnI+DQo8YnI+DQpBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMg dmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtdjZvcHMtaG9zdC1hZGRyLWF2YWlsYWJpbGl0eS0w NCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv cmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtdjZvcHMtaG9zdC1hZGRyLWF2YWlsYWJpbGl0eS0wNDwv YT48L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5TdW1tYXJ5IG9mIHRoZSBj aGFuZ2VzIGluIHRoaXMgdmVyc2lvbiA6PC9kaXY+DQo8ZGl2Pg0KPG9sPg0KPGxpPlRoZSB0ZXh0 IGFib3V0IG9taXR0aW5nIERBRCBhZ3JlZWQgd2l0aCBGcmVkIFRlbXBsaW4uPGJyPg0KPC9saT48 bGk+VGhlIHN1Z2dlc3Rpb25zIGZyb20gRGF2aWQgRmFybWVyIHRvIGNsYXJpZnkgdGhlIHNjb3Bl IG9mIHRoZSBkb2N1bWVudDogZXhwbGljaXRseSBzYXkgdGhhdCBwcm90b2NvbCBjaGFuZ2VzIGFu ZCBob3N0IGJlaGF2aW91ciBhcmUgb3V0IG9mIHNjb3BlLCByZXdvcmQgJnF1b3Q7YXNzaWduJnF1 b3Q7IHRvIHByb3ZpZGUmcXVvdDssIGV0Yy48YnI+DQo8L2xpPjxsaT5BIHN0YXRlbWVudCB0aGF0 IHdoaWxlIFJGQyAzNjMzIHRhbGtzIGFib3V0ICZxdW90O3JlcXVlc3Rpbmcgcm91dGVyJnF1b3Q7 LCBESENQdjYgUEQgaXRzZWxmIGRvZXNuJ3QgYWN0dWFsbHkgcmVxdWlyZSB0aGF0IHRoZSBjbGll bnQgZm9yd2FyZCBwYWNrZXRzLCBhbmQgdGh1cyBkb2VzIG5vdCByZXF1aXJlIHRoYXQgdGhlIGNs aWVudCBiZSBhIHJvdXRlciBhcyBkZWZpbmVkIGluIFJGQyAyNDYwLjxicj4NCjwvbGk+PC9vbD4N CjwvZGl2Pg0KPGRpdj5DaGVlcnMsPC9kaXY+DQo8ZGl2PkxvcmVuem8mbmJzcDs8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3Nw YW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D2B05FC56374Cevynckeciscocom_-- From nobody Mon Jan 4 08:55:40 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2A891A8A80; Mon, 4 Jan 2016 08:55:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 Y3P3XrAhCVhS; Mon, 4 Jan 2016 08:55:36 -0800 (PST) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B59AE1A8A7E; Mon, 4 Jan 2016 08:55:36 -0800 (PST) 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 u04GtZkx029106; Mon, 4 Jan 2016 10:55:36 -0600 Received: from XCH-BLV-108.nw.nos.boeing.com (xch-blv-108.nw.nos.boeing.com [130.247.25.137]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u04GtOBG029027 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 4 Jan 2016 10:55:25 -0600 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.52]) by XCH-BLV-108.nw.nos.boeing.com ([169.254.13.112]) with mapi id 14.03.0235.001; Mon, 4 Jan 2016 08:55:24 -0800 From: "Templin, Fred L" To: Lorenzo Colitti Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt Thread-Index: AQHRRw6yg6NBQZxHIk+n1ca7lLlCA57rkfFw Date: Mon, 4 Jan 2016 16:55:22 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: multipart/alternative; boundary="_000_2134F8430051B64F815C691A62D9831832F98A37XCHBLV504nwnosb_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "v6ops@ietf.org WG" , internet-drafts , "i-d-announce@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 16:55:39 -0000 --_000_2134F8430051B64F815C691A62D9831832F98A37XCHBLV504nwnosb_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTG9yZW56bywNCg0KUGVvcGxlIGhhdmUgYXNrZWQgYWJvdXQgaG93IGZhdWx0IHRvbGVyYW5j ZSB3b3JrcywgYW5kIEFFUk8gcHJvdmlkZXMgdGhlIGFuc3dlci4NClBlb3BsZSBoYXZlIGFza2Vk IGFib3V0IGhvdyBtb2JpbGl0eSB3b3JrcywgYW5kIEFFUk8gcHJvdmlkZXMgdGhlIGFuc3dlci4N ClBlb3BsZSBoYXZlIGFza2VkIGhvdyBwYXRoIE1UVSByb2J1c3RuZXNzIHdvcmtzLCBhbmQgQUVS TyBwcm92aWRlcyB0aGUgYW5zd2VyLg0KUGVvcGxlIHNob3VsZCBiZSBhc2tpbmcgaG93IHJvdXRl IG9wdGltaXphdGlvbiB3b3JrcywgYW5kIEFFUk8gcHJvdmlkZXMgdGhlIGFuc3dlci4NCg0KSW4g bXkgZXhwZXJpZW5jZSwgdGhlIElFVEYgbG92ZXMgYSBwcm9ibGVtIGFuZCB3aWxsIG5vdCB0b2xl cmF0ZSBhIHNvbHV0aW9uLiBJbiB0aGlzDQpjYXNlLCBBRVJPIGlzIGEgd2lkZWx5IGFwcGxpY2Fi bGUgc29sdXRpb24gdGhhdCBpcyBiZWluZyBvdmVybG9va2VkIGFuZCBpZ25vcmVkIGluDQp0aGlz IGZhc2hpb24uIFdlIG5lZWQgdG8gYnJlYWsgb3V0IG9mIHRoYXQgbW9sZCBhbmQgZ28gd2l0aCBz b21ldGhpbmcgdGhhdA0Kc3RhbmRzIGEgY2hhbmNlIG9mIHdvcmtpbmcsIGFuZCBBRVJPIGlzIGl0 Lg0KDQpUaGFua3MgLSBGcmVkDQoNCkZyb206IExvcmVuem8gQ29saXR0aSBbbWFpbHRvOmxvcmVu em9AZ29vZ2xlLmNvbV0NClNlbnQ6IE1vbmRheSwgSmFudWFyeSAwNCwgMjAxNiA4OjQxIEFNDQpU bzogVGVtcGxpbiwgRnJlZCBMDQpDYzogaW50ZXJuZXQtZHJhZnRzOyB2Nm9wc0BpZXRmLm9yZyBX RzsgaS1kLWFubm91bmNlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBJLUQgQWN0aW9u OiBkcmFmdC1pZXRmLXY2b3BzLWhvc3QtYWRkci1hdmFpbGFiaWxpdHktMDQudHh0DQoNCkZyZWQu DQoNCkkgZG8gbm90IHRoaW5rIGl0IGlzIGFwcHJvcHJpYXRlIHRvIGFkZCBzdWNoIGEgcmVmZXJl bmNlLiBBRVJPIGlzIG9ubHkgb25lIHdheSB0byB1c2UgYWRkcmVzcyBzcGFjZSBkZWxlZ2F0ZWQg YnkgREhDUHY2IFBELCBhbmQgdGhlcmUgYXJlIG90aGVyLCBwZXJoYXBzIG1vcmUgb2J2aW91cyB3 YXlzLCBzdWNoIGFzIHVzaW5nIHRoZSBhZGRyZXNzZXMgZGlyZWN0bHkgd2l0aG91dCBhIHR1bm5l bC4gSSB0aGluayBwcm92aWRpbmcgYSB0YXhvbm9teSBvZiB0aGUgZGlmZmVyZW50IHdheXMgdG8g bWFrZSBESENQdjYgUEQgd29yayBpcyBvdXQgb2Ygc2NvcGUgZm9yIGEgZG9jdW1lbnQgd2hvc2Ug cHJpbWFyeSBtZXNzYWdlIGJ1dCAiZG9uJ3QgbGltaXQgdGhlIG51bWJlciBvZiBhZGRyZXNzZXMg dGhlIG5ldHdvcmsgaGFuZHMgb3V0IHRvIGhvc3RzIi4NCg0KQ2hlZXJzLA0KTG9yZW56bw0KDQpP biBUdWUsIEphbiA1LCAyMDE2IGF0IDE6MTUgQU0sIFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRl bXBsaW5AYm9laW5nLmNvbTxtYWlsdG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4+IHdyb3Rl Og0KSGkgTG9yZW56bywNCg0KSSBiZWxpZXZlIHRoaXMgZG9jdW1lbnQgc2hvdWxkIGFsc28gaW5j bHVkZSBhbiBpbmZvcm1hdGl2ZSByZWZlcmVuY2UgdG8gQUVSTw0KYXMgdGhlIG1ldGhvZCBmb3Ig bWFuYWdpbmcgREhDUHY2LVBEIGRlbGVnYXRlZCBwcmVmaXhlcy4NCg0KVGhhbmtzIOKAkyBGcmVk DQpmcmVkLmwudGVtcGxpbkBib2VpbmcuY29tPG1haWx0bzpmcmVkLmwudGVtcGxpbkBib2Vpbmcu Y29tPg0KDQpGcm9tOiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRv OnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgTG9yZW56byBDb2xpdHRpDQpT ZW50OiBTdW5kYXksIEphbnVhcnkgMDMsIDIwMTYgNzoyNiBQTQ0KVG86IGludGVybmV0LWRyYWZ0 cw0KQ2M6IHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4gV0c7IGktZC1hbm5v dW5jZUBpZXRmLm9yZzxtYWlsdG86aS1kLWFubm91bmNlQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IFt2Nm9wc10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi12Nm9wcy1ob3N0LWFkZHItYXZhaWxhYmls aXR5LTA0LnR4dA0KDQpPbiBNb24sIEphbiA0LCAyMDE2IGF0IDEyOjE2IFBNLCA8aW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+PiB3cm90ZToN CkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVy bmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRo ZSBJUHY2IE9wZXJhdGlvbnMgV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi4NCg0KICAgICAgICBU aXRsZSAgICAgICAgICAgOiBIb3N0IGFkZHJlc3MgYXZhaWxhYmlsaXR5IHJlY29tbWVuZGF0aW9u cw0KICAgICAgICBBdXRob3JzICAgICAgICAgOiBMb3JlbnpvIENvbGl0dGkNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgVmludCBDZXJmDQogICAgICAgICAgICAgICAgICAgICAgICAgIFN0dWFy dCBDaGVzaGlyZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICBEYXZpZCBTY2hpbmF6aQ0KICAg ICAgICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLXY2b3BzLWhvc3QtYWRkci1hdmFpbGFi aWxpdHktMDQudHh0DQogICAgICAgIFBhZ2VzICAgICAgICAgICA6IDEzDQogICAgICAgIERhdGUg ICAgICAgICAgICA6IDIwMTYtMDEtMDMNCg0KWy4uLl0NCg0KQSBkaWZmIGZyb20gdGhlIHByZXZp b3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlm Zj91cmwyPWRyYWZ0LWlldGYtdjZvcHMtaG9zdC1hZGRyLWF2YWlsYWJpbGl0eS0wNA0KDQpTdW1t YXJ5IG9mIHRoZSBjaGFuZ2VzIGluIHRoaXMgdmVyc2lvbiA6DQoNCiAgMS4gIFRoZSB0ZXh0IGFi b3V0IG9taXR0aW5nIERBRCBhZ3JlZWQgd2l0aCBGcmVkIFRlbXBsaW4uDQogIDIuICBUaGUgc3Vn Z2VzdGlvbnMgZnJvbSBEYXZpZCBGYXJtZXIgdG8gY2xhcmlmeSB0aGUgc2NvcGUgb2YgdGhlIGRv Y3VtZW50OiBleHBsaWNpdGx5IHNheSB0aGF0IHByb3RvY29sIGNoYW5nZXMgYW5kIGhvc3QgYmVo YXZpb3VyIGFyZSBvdXQgb2Ygc2NvcGUsIHJld29yZCAiYXNzaWduIiB0byBwcm92aWRlIiwgZXRj Lg0KICAzLiAgQSBzdGF0ZW1lbnQgdGhhdCB3aGlsZSBSRkMgMzYzMyB0YWxrcyBhYm91dCAicmVx dWVzdGluZyByb3V0ZXIiLCBESENQdjYgUEQgaXRzZWxmIGRvZXNuJ3QgYWN0dWFsbHkgcmVxdWly ZSB0aGF0IHRoZSBjbGllbnQgZm9yd2FyZCBwYWNrZXRzLCBhbmQgdGh1cyBkb2VzIG5vdCByZXF1 aXJlIHRoYXQgdGhlIGNsaWVudCBiZSBhIHJvdXRlciBhcyBkZWZpbmVkIGluIFJGQyAyNDYwLg0K Q2hlZXJzLA0KTG9yZW56bw0KDQo= --_000_2134F8430051B64F815C691A62D9831832F98A37XCHBLV504nwnosb_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo1MjQw OTYyMzE7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNjM3MTYzMjEyO30NCm9sDQoJe21hcmdp bi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+SGkgTG9yZW56byw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPlBlb3BsZSBoYXZlIGFza2VkIGFib3V0IGhvdyBmYXVsdCB0b2xlcmFuY2Ugd29y a3MsIGFuZCBBRVJPIHByb3ZpZGVzIHRoZSBhbnN3ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlBlb3Bs ZSBoYXZlIGFza2VkIGFib3V0IGhvdyBtb2JpbGl0eSB3b3JrcywgYW5kIEFFUk8gcHJvdmlkZXMg dGhlIGFuc3dlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UGVvcGxlIGhhdmUgYXNrZWQgaG93IHBhdGgg TVRVIHJvYnVzdG5lc3Mgd29ya3MsIGFuZCBBRVJPIHByb3ZpZGVzIHRoZSBhbnN3ZXIuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPlBlb3BsZSBzaG91bGQgYmUgYXNraW5nIGhvdyByb3V0ZSBvcHRpbWl6YXRp b24gd29ya3MsIGFuZCBBRVJPIHByb3ZpZGVzIHRoZSBhbnN3ZXIuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JbiBteSBleHBlcmllbmNlLCB0aGUgSUVURiBsb3Zl cyBhIHByb2JsZW0gYW5kIHdpbGwgbm90IHRvbGVyYXRlIGEgc29sdXRpb24uIEluIHRoaXM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+Y2FzZSwgQUVSTyBpcyBhIHdpZGVseSBhcHBsaWNhYmxlIHNvbHV0aW9u IHRoYXQgaXMgYmVpbmcgb3Zlcmxvb2tlZCBhbmQgaWdub3JlZCBpbjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij50aGlzIGZhc2hpb24uIFdlIG5lZWQgdG8gYnJlYWsgb3V0IG9mIHRoYXQgbW9sZCBhbmQgZ28g d2l0aCBzb21ldGhpbmcgdGhhdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5zdGFuZHMgYSBjaGFuY2Ugb2Yg d29ya2luZywgYW5kIEFFUk8gaXMgaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5UaGFua3MgLSBGcmVkDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBMb3JlbnpvIENvbGl0dGkgW21h aWx0bzpsb3JlbnpvQGdvb2dsZS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBKYW51 YXJ5IDA0LCAyMDE2IDg6NDEgQU08YnI+DQo8Yj5Ubzo8L2I+IFRlbXBsaW4sIEZyZWQgTDxicj4N CjxiPkNjOjwvYj4gaW50ZXJuZXQtZHJhZnRzOyB2Nm9wc0BpZXRmLm9yZyBXRzsgaS1kLWFubm91 bmNlQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246 IGRyYWZ0LWlldGYtdjZvcHMtaG9zdC1hZGRyLWF2YWlsYWJpbGl0eS0wNC50eHQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RnJlZC48bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG8gbm90IHRoaW5rIGl0 IGlzIGFwcHJvcHJpYXRlIHRvIGFkZCBzdWNoIGEgcmVmZXJlbmNlLiBBRVJPIGlzIG9ubHkgb25l IHdheSB0byB1c2UgYWRkcmVzcyBzcGFjZSBkZWxlZ2F0ZWQgYnkgREhDUHY2IFBELCBhbmQgdGhl cmUgYXJlIG90aGVyLCBwZXJoYXBzIG1vcmUgb2J2aW91cyB3YXlzLCBzdWNoIGFzIHVzaW5nIHRo ZSBhZGRyZXNzZXMgZGlyZWN0bHkgd2l0aG91dCBhIHR1bm5lbC4gSSB0aGluayBwcm92aWRpbmcN CiBhIHRheG9ub215IG9mIHRoZSBkaWZmZXJlbnQgd2F5cyB0byBtYWtlIERIQ1B2NiBQRCB3b3Jr IGlzIG91dCBvZiBzY29wZSBmb3IgYSBkb2N1bWVudCB3aG9zZSBwcmltYXJ5IG1lc3NhZ2UgYnV0 ICZxdW90O2Rvbid0IGxpbWl0IHRoZSBudW1iZXIgb2YgYWRkcmVzc2VzIHRoZSBuZXR3b3JrIGhh bmRzIG91dCB0byBob3N0cyZxdW90Oy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TG9yZW56bzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEphbiA1LCAyMDE2IGF0IDE6MTUg QU0sIFRlbXBsaW4sIEZyZWQgTCAmbHQ7PGEgaHJlZj0ibWFpbHRvOkZyZWQuTC5UZW1wbGluQGJv ZWluZy5jb20iIHRhcmdldD0iX2JsYW5rIj5GcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBMb3Jl bnpvLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgYmVs aWV2ZSB0aGlzIGRvY3VtZW50IHNob3VsZCBhbHNvIGluY2x1ZGUgYW4gaW5mb3JtYXRpdmUgcmVm ZXJlbmNlIHRvIEFFUk88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5hcyB0aGUgbWV0aG9kIGZvciBtYW5h Z2luZyBESENQdjYtUEQgZGVsZWdhdGVkIHByZWZpeGVzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyDigJMgRnJlZDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxhIGhyZWY9Im1haWx0bzpmcmVkLmwudGVtcGxpbkBib2VpbmcuY29tIiB0YXJnZXQ9Il9i bGFuayI+ZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbTwvYT48L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gdjZvcHMg W21haWx0bzo8YSBocmVmPSJtYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5M b3JlbnpvIENvbGl0dGk8YnI+DQo8Yj5TZW50OjwvYj4gU3VuZGF5LCBKYW51YXJ5IDAzLCAyMDE2 IDc6MjYgUE08YnI+DQo8Yj5Ubzo8L2I+IGludGVybmV0LWRyYWZ0czxicj4NCjxiPkNjOjwvYj4g PGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+djZvcHNAaWV0 Zi5vcmc8L2E+IFdHOw0KPGEgaHJlZj0ibWFpbHRvOmktZC1hbm5vdW5jZUBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPmktZC1hbm5vdW5jZUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFt2Nm9wc10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi12Nm9wcy1ob3N0LWFkZHItYXZh aWxhYmlsaXR5LTA0LnR4dDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIE1vbiwgSmFu IDQsIDIwMTYgYXQgMTI6MTYgUE0sICZsdDs8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRz QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QSBOZXcgSW50ZXJuZXQt RHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVj dG9yaWVzLjxicj4NCiZuYnNwO1RoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIElQdjYg T3BlcmF0aW9ucyBXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLjxicj4NCjxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBUaXRsZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7OiBIb3N0IGFkZHJlc3MgYXZhaWxhYmlsaXR5IHJlY29tbWVuZGF0aW9uczxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBBdXRob3JzJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOzogTG9yZW56byBDb2xpdHRpPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IFZpbnQgQ2VyZjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBTdHVhcnQgQ2hlc2hpcmU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgRGF2aWQgU2NoaW5hemk8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgRmlsZW5h bWUmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiBkcmFmdC1pZXRmLXY2b3BzLWhvc3QtYWRk ci1hdmFpbGFiaWxpdHktMDQudHh0PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFBh Z2VzJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IDEzPGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IERhdGUmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyA6IDIwMTYtMDEtMDM8YnI+DQo8YnI+DQpbLi4uXTxicj4NCjxicj4NCkEg ZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDo8YnI+DQo8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi12Nm9wcy1o b3N0LWFkZHItYXZhaWxhYmlsaXR5LTA0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtdjZvcHMtaG9zdC1hZGRyLWF2YWlsYWJpbGl0 eS0wNDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5TdW1tYXJ5IG9mIHRoZSBjaGFuZ2VzIGluIHRoaXMgdmVyc2lvbiA6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8b2wgc3RhcnQ9IjEiIHR5cGU9IjEiPg0K PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpUaGUgdGV4 dCBhYm91dCBvbWl0dGluZyBEQUQgYWdyZWVkIHdpdGggRnJlZCBUZW1wbGluLjxvOnA+PC9vOnA+ PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NClRo ZSBzdWdnZXN0aW9ucyBmcm9tIERhdmlkIEZhcm1lciB0byBjbGFyaWZ5IHRoZSBzY29wZSBvZiB0 aGUgZG9jdW1lbnQ6IGV4cGxpY2l0bHkgc2F5IHRoYXQgcHJvdG9jb2wgY2hhbmdlcyBhbmQgaG9z dCBiZWhhdmlvdXIgYXJlIG91dCBvZiBzY29wZSwgcmV3b3JkICZxdW90O2Fzc2lnbiZxdW90OyB0 byBwcm92aWRlJnF1b3Q7LCBldGMuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KQSBzdGF0ZW1lbnQgdGhhdCB3aGlsZSBSRkMg MzYzMyB0YWxrcyBhYm91dCAmcXVvdDtyZXF1ZXN0aW5nIHJvdXRlciZxdW90OywgREhDUHY2IFBE IGl0c2VsZiBkb2Vzbid0IGFjdHVhbGx5IHJlcXVpcmUgdGhhdCB0aGUgY2xpZW50IGZvcndhcmQg cGFja2V0cywgYW5kIHRodXMgZG9lcyBub3QgcmVxdWlyZSB0aGF0IHRoZSBjbGllbnQgYmUgYSBy b3V0ZXIgYXMgZGVmaW5lZCBpbiBSRkMgMjQ2MC48bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Mb3JlbnpvJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_2134F8430051B64F815C691A62D9831832F98A37XCHBLV504nwnosb_-- From nobody Mon Jan 4 10:17:37 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA0F21A906B for ; Mon, 4 Jan 2016 10:17:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] 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 HBHZaj2N3DMt for ; Mon, 4 Jan 2016 10:17:34 -0800 (PST) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1D4B1A9066 for ; Mon, 4 Jan 2016 10:17:34 -0800 (PST) Received: by mail-io0-x230.google.com with SMTP id q21so162340519iod.0 for ; Mon, 04 Jan 2016 10:17:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CEHrJVoTFFt3NV3boSnKB5CQYifQQ7xFYxqeadzh8ig=; b=jBpndiYmBaCoKrg1pg39UYsSsVZmXYfGE3FprFcb1Fl8E7Rmn1LAHYg/yckg05TMVw YTFFEDAvnkYP+r9dINufx4hxVpqS0b+TSQPCyvbiS1c2DP+oLVpmPhgF9GKc9dPmpbhD UNbL0TCK40MWk9ixH+bRFupzGMx8Old1+bBVNMtknnzgRvtU0jFyC6Duw1nr5hJiiweH HW8qGu2vuC3DCbz7LmWpL+iGQqOy6UdmVsGq/yLnrMsvaW0vcD1YVz5nl2k6iD42xDm3 y0wcyxSBdtg6x0ZLjeyh/ywqgf0F7PRgyh8jYyGX9XdNgCDGzOXx4uqzhn1BPs180Vpm Yy3w== 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=CEHrJVoTFFt3NV3boSnKB5CQYifQQ7xFYxqeadzh8ig=; b=dSbykhzElSO9WErICyrQUsf5+h+QAwmqLW1WCA2k6LP2y6BjpLdP+fmsdaELGsTyUw +dUiJjfYlW6PSGqurXU8R9zsOuB1y2aT3C9POtjD9Stg442eBpWifxafk27dXE/JrcmT 4tOKR6lQ4/bHejiNsU5tOMgUI35vD5p2wQVQXbX1EXJfKQWoP7va+DkkLHdaZe592aDg P8uD+g3b3aQRVFRC/Q06/8VL/Fku5KWiuDn6FosSGL3BzvVROg7sv7FF5++4RuS5baQj SyXmOXppgJJQ9Y6WamUEgqjFa6jIKhuV1VzWMIHhVHUrSpEns7H4bRv+jQoNJpfV8aS7 HjDA== X-Gm-Message-State: ALoCoQnbwKj38uNLTyCsiQxqtNyWZuEx+bSnZY1d7n8Uqr/wdlxTK4gH5cdb9gDlJ89Ub82Fk9gPykuVjfvojnuV4HdF7suEoQ== MIME-Version: 1.0 X-Received: by 10.107.135.23 with SMTP id j23mr58225619iod.50.1451931453970; Mon, 04 Jan 2016 10:17:33 -0800 (PST) Received: by 10.107.140.150 with HTTP; Mon, 4 Jan 2016 10:17:33 -0800 (PST) In-Reply-To: <201601031900.u03J0LMe009763@irp-lnx1.cisco.com> References: <201601031900.u03J0LMe009763@irp-lnx1.cisco.com> Date: Mon, 4 Jan 2016 10:17:33 -0800 Message-ID: From: Tom Herbert To: "Fred Baker (fred)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 18:17:35 -0000 On Sun, Jan 3, 2016 at 11:00 AM, wrote: > And now for something a little different. I'd like to invite focused > discussion of draft-ietf-v6ops-unique-ipv6-prefix-per-host, which we > adopted at IETF 94 > > Slides are at > https://www.ietf.org/proceedings/94/slides/slides-94-v6ops-4.pdf. > Form the draft: "While this work was originally conceived in the context of large scale Wi-Fi networks, the scope of applicability is much broader." This is completely true, however most of the draft seems to focus on the Wi-Fi application. At Facebook, for instance, we intend to deploy 64-bit prefixes on all host in data center which has nothing to do with Wi-Fi. It might be good if the draft were more generic in this regard (or renamed if it is expressly intended to solve an issue for Wi-Fi). Thanks, Tom > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Jan 4 10:33:14 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7641E1A038C for ; Mon, 4 Jan 2016 10:33:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, 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 xQzvrnkMa-4V for ; Mon, 4 Jan 2016 10:33:10 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3C231A0404 for ; Mon, 4 Jan 2016 10:33:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4555; q=dns/txt; s=iport; t=1451932384; x=1453141984; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=WnzBZtBGCqOTJ0CH2S/Zjegp6xDoejYB/ZR4DT8P9vw=; b=geGs5cpRjoMEbTViLLSmC3GwQT681Ge5TsJX4IGUHtA0tkJ9HGHx1voT Tan9JGAqaW5f9dglxigGoLrD9pQmsjwN4AkRrgMp34O+WkDeE1rlnR/1T s6p9MsiXJ9hUGkQPww+SxH83w3fOLCHd+N+0ZZo5sr7CFe6yrV2K5ynpk A=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DsAgC4uYpW/5BdJa1bA4M6Um0GiFOzd?= =?us-ascii?q?g6BZBgKhW0CgRw4FAEBAQEBAQGBCoQ0AQEBAwEBAQFrCwUHBAIBCBEDAQIBLic?= =?us-ascii?q?LHQgCBA4FDogZCA7BNQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ8FBIhlCIJohCYRA?= =?us-ascii?q?SUaASaDA4EbBY05iU0BgnGBZIh7gVyNH4VYhG+DcgEgAUOECnKDTjqBCAEBAQ?= X-IronPort-AV: E=Sophos;i="5.20,521,1444694400"; d="asc'?scan'208";a="58378607" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Jan 2016 18:33:03 +0000 Received: from XCH-RCD-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u04IX3i1000500 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 4 Jan 2016 18:33:03 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 4 Jan 2016 12:33:02 -0600 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1104.009; Mon, 4 Jan 2016 12:33:02 -0600 From: "Fred Baker (fred)" To: John Brzozowski Thread-Topic: [v6ops] State of play Thread-Index: AQHRRx5YDRz6JMpP006tIIZ8oTK66g== Date: Mon, 4 Jan 2016 18:33:02 +0000 Message-ID: <0494FE57-71F1-4117-98F3-4BF96032D3D2@cisco.com> References: <201601011400.u01E0BqP025288@irp-lnx1.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3112) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.64.124] Content-Type: multipart/signed; boundary="Apple-Mail=_B69A0DE3-D81C-4CC0-921B-E7C80DEA7CF6"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] State of play X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 18:33:12 -0000 --Apple-Mail=_B69A0DE3-D81C-4CC0-921B-E7C80DEA7CF6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii No problem. When you next submit an update for = draft-ietf-v6ops-unique-ipv6-prefix-per-host, the tool will ask you = whether it replaces any existing drafts. If you say "yes, it replaces = draft-jjmb-v6ops-unique-ipv6-prefix-per-host", the individual submission = will drop out of the list the IETF tools give me. There is another option, though. On the list, you discussed excising = some Comcast-specific elements from The WG draft, making that draft be = entirely about the generalized type of service (which seems like a good = idea). One option would be to keep the Comcast-specific parts in = draft-jjmb-v6ops-unique-ipv6-prefix-per-host, which continues to exist. = Another obvious option would be to file those under a new draft name, in = which case I would argue that the WG draft replaces the individual one. Your call. Either way works for me. > On Jan 3, 2016, at 9:09 PM, Brzozowski, John = wrote: >=20 > Fred, >=20 > Just to be clear, the following: >=20 > 2015-10-19 draft-jjmb-v6ops-unique-ipv6-prefix-per-host >=20 > Will no longer be updated since it was accepted as a WG document: >=20 > 2015-11-01 draft-ietf-v6ops-unique-ipv6-prefix-per-host >=20 > We plan to make updates based on the last WG meeting and email = comments > for the next IETF. >=20 >=20 > John > +1-484-962-0060 >=20 >=20 >=20 >=20 > -----Original Message----- > From: v6ops on behalf of Fred Baker > > Date: Friday, January 1, 2016 at 09:00 > To: v6ops > Subject: [v6ops] State of play >=20 >> RFC Editor: EDIT >> 2015-11-23 draft-ietf-v6ops-reducing-ra-energy-consumption >> 2015-10-26 draft-ietf-v6ops-siit-dc >> 2015-10-26 draft-ietf-v6ops-siit-dc-2xlat >> 2015-10-26 draft-ietf-v6ops-siit-eam >>=20 >> RFC Editor: In ISE Review >> 2015-12-17 draft-ietf-v6ops-mobile-device-profile >>=20 >> RFC Editor: RFC-EDITOR >> 2015-10-19 draft-ietf-v6ops-pmtud-ecmp-problem >>=20 >> WG: Unupdated WG Document >> 2015-10-19 draft-ietf-v6ops-design-choices >> 2015-07-06 draft-ietf-v6ops-dhcpv6-slaac-problem >>=20 >> WG: Updated WG Document >> 2015-12-10 draft-ietf-v6ops-host-addr-availability >> 2015-11-01 draft-ietf-v6ops-unique-ipv6-prefix-per-host >>=20 >> WG: WG Consensus: Waiting for Write-Up >> 2015-12-11 draft-ietf-v6ops-ipv6-ehs-in-real-world >>=20 >> Individual Submission: Unupdated >> 2015-10-19 draft-jjmb-v6ops-unique-ipv6-prefix-per-host >> 2015-10-19 draft-xu-v6ops-dslite-redundancy >> 2015-10-15 draft-gont-v6ops-ipv6-ehs-packet-drops >> 2015-10-10 draft-bao-v6ops-rfc6145bis >> 2015-09-21 draft-ybai-v6ops-ipv6-for-openstack >> 2015-07-06 draft-akira-v6ops-mape-experience >> 2015-07-06 draft-xcf-v6ops-chinatelecom-deployment >> 2015-07-05 draft-hui-v6ops-ipv6trans-select-nfv >> 2015-07-05 draft-xli-v6ops-cernet-deployment >> 2015-07-05 draft-yang-v6ops-ipv6tran-select >>=20 >> Individual Submission: Updated >> 2015-11-05 draft-templin-v6ops-pdhost >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >=20 --Apple-Mail=_B69A0DE3-D81C-4CC0-921B-E7C80DEA7CF6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBVoq63UayAOS/EQ8MAQI93BAAvIZOugMN6r34v0jJbkedltVMOB5X5XXo ZMJi0yX/fDdH1W0/R/2Bdp2OBzSIeTsu+EkGg70yQFtTqzaAG1xf566Lsm3B6oEY TBl1F/d3SxNqf+N/dOhEMEBCiRov9GsDBGIE/sVN6clcPR/5dLgcyoZxU7E7+MFK kdPde9CuV/x5p/n/y1FEuxV5ChrdvaP3NS0ZCwigS4XiABidvf1VUKgjIzD3jl75 xGIjb5G/9eHHeLem4YYVQPpvjeUrmHfaUjsq9Y+1kIz64XX2P8e+FJAj8/gegEzV VeYvqA15IGt1gdwFuoaoqDDHYiL/PdAlk5HUghjSZy/oOKwhdXN4cNWzHU1fm/OQ BTsfsTtBDqJAprGqUZ186cLr+QBBWYkcS8LsSiVKXnnjUVf2Bet3RxpSUUuEslBN 3CaZKi/C6kzj1ut9VDx1yARY4JVi+W1911sG8jNYmL/ETOq8XOits5UG2vMZxo8Q zdQ3UF0yFBRFSI7ui4hzii6985VzTB0PFPlm+YIfFDB2jS+aOYNxmDpkF+L9pIXS UvJl56AIWR4h+qpUijX8Vme0jSeEfNmOBR9wUanvtCp1lWTy7Zwu3W6s1TiGWAHO +VrtA+x5onuuP2qBl2vKp71TcAu1/DlXAR44gLYbs7cWLMiUavp9+gJT4NTxKZK5 nKjd50E2BdA= =1J1v -----END PGP SIGNATURE----- --Apple-Mail=_B69A0DE3-D81C-4CC0-921B-E7C80DEA7CF6-- From nobody Mon Jan 4 11:48:30 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2251B1A90E6 for ; Mon, 4 Jan 2016 11:48:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0ShJBWY-4VM for ; Mon, 4 Jan 2016 11:48:21 -0800 (PST) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82CAA1A90DB for ; Mon, 4 Jan 2016 11:48:14 -0800 (PST) Received: by mail-vk0-x231.google.com with SMTP id k1so128031182vkb.2 for ; Mon, 04 Jan 2016 11:48:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xnDdq4fO7JEaQ2r3IlwxiMeZjzzd/PBonRRIMOj2Vks=; b=nh30cZttwzaWRRAMU6Y5XzDdgcmXbHRv7bYGM6EuRSxWuI6pl/1kcmZkEjSMNB2Ni5 TRWefqSx2f0m0fOEojqWA9irSzXurhQWgzPt9dqakwkjfXLFJyyvQcPQOG1eVdAqTbRC Q+DmUteEXESi996yz+ov9LtwgOGApwLVecgk9Ov1xd0dnkTM0zwHEDWG9ZW7E9SVlmju xO3Ut+8qVu6+KXqeDzI/EdUQIPD0/6CtjLndKO+87HoJVoHr2DAfzzv3mKQHycqA1Klw DhZpO38SZBGJM+3xBk0VEcScP2GefftuEgbwz3D4pSd6DhQx43uB3kPUGzkKmzZ4ERVt VDZA== MIME-Version: 1.0 X-Received: by 10.31.107.138 with SMTP id k10mr57931201vki.27.1451936893557; Mon, 04 Jan 2016 11:48:13 -0800 (PST) Received: by 10.103.99.1 with HTTP; Mon, 4 Jan 2016 11:48:13 -0800 (PST) Received: by 10.103.99.1 with HTTP; Mon, 4 Jan 2016 11:48:13 -0800 (PST) In-Reply-To: <201601031900.u03J0LMe009763@irp-lnx1.cisco.com> References: <201601031900.u03J0LMe009763@irp-lnx1.cisco.com> Date: Tue, 5 Jan 2016 06:48:13 +1100 Message-ID: From: Mark Smith To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=001a11478cb8c6e27d05288766c6 Archived-At: Cc: v6ops list Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 19:48:23 -0000 --001a11478cb8c6e27d05288766c6 Content-Type: text/plain; charset=UTF-8 Hi, On 4 Jan 2016 06:00, wrote: > > And now for something a little different. I'd like to invite focused > discussion of draft-ietf-v6ops-unique-ipv6-prefix-per-host, which we > adopted at IETF 94 > > Slides are at > https://www.ietf.org/proceedings/94/slides/slides-94-v6ops-4.pdf. > > I agree with points others have made. The title sounds like a BCP title, however the content reads like a recipe/howto for a specific deployment scenario. I think there are general and non-Wifi specific parts that should be separated. Reflecting on the number and content of recent discussions around hosts using DHCPv6-PD, I think there needs to be an ID on that topic. Fred's draft seems to be mostly there, although multicast/MLD needs to be covered. https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/ Finally, although it in some ways is out of scope, I'd never want to see a BCP of any kind proposing that all of Wifi's security mechanisms are turned off, because WiFi traffic is so easy to packet capture everything when security is switched off. Regards, Mark. _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --001a11478cb8c6e27d05288766c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi,

On 4 Jan 2016 06:00, <f= red@cisco.com> wrote:
>
> And now for something a little different. I'd like to invite focus= ed
> discussion of draft-ietf-v6ops-unique-ipv6-prefix-per-host, which we > adopted at IETF 94
>
> Slides are at
> https://www.ietf.org/proceedings/94/slides/slides-94-v6ops-4.pdf= .
>
>

I agree with points others have made.

The title sounds like a BCP title, however the content reads= like a recipe/howto for a specific deployment scenario.

I think there are general and non-Wifi specific parts that s= hould be separated. Reflecting on the number and content of recent discussi= ons around hosts using DHCPv6-PD, I think there needs to be an ID on that t= opic. Fred's draft seems to be mostly there, although multicast/MLD nee= ds to be covered.

https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/

Finally, although it in some ways is out of scope, I'd n= ever want to see a BCP of any kind proposing that all of Wifi's securit= y mechanisms are turned off, because WiFi traffic is so easy to packet capt= ure everything when security is switched off.

Regards,
Mark.

_______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--001a11478cb8c6e27d05288766c6-- From nobody Mon Jan 4 12:35:58 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 613B21A9173 for ; Mon, 4 Jan 2016 12:35:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.664 X-Spam-Level: * X-Spam-Status: No, score=1.664 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 Vt08BW3ea7vB for ; Mon, 4 Jan 2016 12:35:56 -0800 (PST) Received: from vaadcmhout02.cable.comcast.com (unknown [96.114.28.76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEED81A9240 for ; Mon, 4 Jan 2016 12:35:55 -0800 (PST) X-AuditID: 60721c4c-f79d66d0000078a0-b6-568ad7aac1c2 Received: from VAADCEX10.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by vaadcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id B7.07.30880.AA7DA865; Mon, 4 Jan 2016 15:35:54 -0500 (EST) Received: from VAADCEX09.cable.comcast.com (147.191.102.76) by VAADCEX10.cable.comcast.com (147.191.102.77) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Mon, 4 Jan 2016 15:35:53 -0500 Received: from VAADCEX09.cable.comcast.com ([fe80::3aea:a7ff:fe12:e2a0]) by VAADCEX09.cable.comcast.com ([fe80::3aea:a7ff:fe12:e2a0%19]) with mapi id 15.00.1130.005; Mon, 4 Jan 2016 15:35:53 -0500 From: "Brzozowski, John" To: "Fred Baker (fred)" Thread-Topic: [v6ops] State of play Thread-Index: AQHRRJzHPy++4YQq5kecsWYXokuy/p7q0uYAgAE0YQD//85+AA== Date: Mon, 4 Jan 2016 20:35:53 +0000 Message-ID: References: <201601011400.u01E0BqP025288@irp-lnx1.cisco.com> <0494FE57-71F1-4117-98F3-4BF96032D3D2@cisco.com> In-Reply-To: <0494FE57-71F1-4117-98F3-4BF96032D3D2@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [96.115.73.254] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIIsWRmVeSWpSXmKPExsWSUOxpobvqeleYwfbv6hbv151hszh9bC+z A5PHlN8bWT2WLPnJFMAUxWWTkpqTWZZapG+XwJXxcgNPwSr1ivZz25gaGFeodTFycEgImEj0 T8rtYuQEMsUkLtxbz9bFyMUhJLCFSWJe+xR2CGc/o8SBOdcZIZwTjBKf5u5iB2lhE7CReP3h JyOILSKgIbHhy1FWkKnMAqoSs//wg4SFBZQkNj3/xwRRoixx59ZmVgjbSeLi5D9gNouAikTv h0tANewcvAL2EtsDIDYtZZR41nEJbDqngK3EsS3bWUBsRqBDv59aAzaSWUBc4taT+UwQDwhI LNlznhnCFpV4+fgf2HhRAT2J3U9OMULEdSTOXn8CZRtIbF26jwXCVpT4Ne8KG8T1mhLrd+lD jHeQ2Lf3OiuErSgxpfsh2OO8AoISJ2c+gWoVlzh8ZAfrBEaZWUgumoUwaRaSSbOQTJqFZNIC RtZVjHJliYkpybkZ+aUlBkZ6yYlJOal6yfm5yYnFJSB6EyMo4otkfHYwfprmcYhRgINRiYf3 /6muMCHWxLLiytxDjBIczEoivMnngUK8KYmVValF+fFFpTmpxYcYpTlYlMR5OxYApQTSE0tS s1NTC1KLYLJMHJxSDYwe9zU8P15nurxmpsr2KTHLeuX2qjW5FkzdFiXzvdckU4qhw9MzuqvV o3Cz4FrDds6iWun7P6bURy5dH2yemplRs+z7Rd+zrYG6LVmM7jnfOG8/Uu923PXBJSL/qMMG jxkSZbnu+/NORead77vOFSu17t3uLXLXbh+Wv7RPd5mVyerDbz6FpiqxFGckGmoxFxUnAgD2 8d2R9AIAAA== Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] State of play X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 20:35:57 -0000 SSB3aWxsIGNvbmZlciB3aXRoIEd1bnRlciBhbmQgYWR2aXNlIGJ5IGVtYWlsIHRvIHRoZSBXRy4g IEVpdGhlciB3YXkgYSBuZXcNCkktRCB3aWxsIGxpa2VseSBhcHBlYXIgdG8gY2Fycnkgc29tZSBv ZiB0aGUgY29udGVudCB0aGF0IGlzIGluIHRoZSBjdXJyZW50DQpkcmFmdC4NCg0KSm9obg0KKzEt NDg0LTk2Mi0wMDYwDQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBG cmVkIEJha2VyIDxmcmVkQGNpc2NvLmNvbT4NCkRhdGU6IE1vbmRheSwgSmFudWFyeSA0LCAyMDE2 IGF0IDEzOjMzDQpUbzogSm9obiBKYXNvbiBCcnpvem93c2tpIDxqb2huX2Jyem96b3dza2lAY2Fi bGUuY29tY2FzdC5jb20+DQpDYzogdjZvcHMgPHY2b3BzQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IFt2Nm9wc10gU3RhdGUgb2YgcGxheQ0KDQo+Tm8gcHJvYmxlbS4gV2hlbiB5b3UgbmV4dCBzdWJt aXQgYW4gdXBkYXRlIGZvcg0KPmRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBl ci1ob3N0LCB0aGUgdG9vbCB3aWxsIGFzayB5b3UNCj53aGV0aGVyIGl0IHJlcGxhY2VzIGFueSBl eGlzdGluZyBkcmFmdHMuIElmIHlvdSBzYXkgInllcywgaXQgcmVwbGFjZXMNCj5kcmFmdC1qam1i LXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdCIsIHRoZSBpbmRpdmlkdWFsIHN1Ym1p c3Npb24NCj53aWxsIGRyb3Agb3V0IG9mIHRoZSBsaXN0IHRoZSBJRVRGIHRvb2xzIGdpdmUgbWUu DQo+DQo+VGhlcmUgaXMgYW5vdGhlciBvcHRpb24sIHRob3VnaC4gT24gdGhlIGxpc3QsIHlvdSBk aXNjdXNzZWQgZXhjaXNpbmcgc29tZQ0KPkNvbWNhc3Qtc3BlY2lmaWMgZWxlbWVudHMgZnJvbSBU aGUgV0cgZHJhZnQsIG1ha2luZyB0aGF0IGRyYWZ0IGJlDQo+ZW50aXJlbHkgYWJvdXQgdGhlIGdl bmVyYWxpemVkIHR5cGUgb2Ygc2VydmljZSAod2hpY2ggc2VlbXMgbGlrZSBhIGdvb2QNCj5pZGVh KS4gT25lIG9wdGlvbiB3b3VsZCBiZSB0byBrZWVwIHRoZSBDb21jYXN0LXNwZWNpZmljIHBhcnRz IGluDQo+ZHJhZnQtamptYi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QsIHdoaWNo IGNvbnRpbnVlcyB0byBleGlzdC4NCj5Bbm90aGVyIG9idmlvdXMgb3B0aW9uIHdvdWxkIGJlIHRv IGZpbGUgdGhvc2UgdW5kZXIgYSBuZXcgZHJhZnQgbmFtZSwgaW4NCj53aGljaCBjYXNlIEkgd291 bGQgYXJndWUgdGhhdCB0aGUgV0cgZHJhZnQgcmVwbGFjZXMgdGhlIGluZGl2aWR1YWwgb25lLg0K Pg0KPllvdXIgY2FsbC4gRWl0aGVyIHdheSB3b3JrcyBmb3IgbWUuDQo+DQo+PiBPbiBKYW4gMywg MjAxNiwgYXQgOTowOSBQTSwgQnJ6b3pvd3NraSwgSm9obg0KPj48Sm9obl9Ccnpvem93c2tpQENh YmxlLkNvbWNhc3QuY29tPiB3cm90ZToNCj4+IA0KPj4gRnJlZCwNCj4+IA0KPj4gSnVzdCB0byBi ZSBjbGVhciwgdGhlIGZvbGxvd2luZzoNCj4+IA0KPj4gMjAxNS0xMC0xOQlkcmFmdC1qam1iLXY2 b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdA0KPj4gDQo+PiBXaWxsIG5vIGxvbmdlciBi ZSB1cGRhdGVkIHNpbmNlIGl0IHdhcyBhY2NlcHRlZCBhcyBhIFdHIGRvY3VtZW50Og0KPj4gDQo+ PiAyMDE1LTExLTAxCWRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0 DQo+PiANCj4+IFdlIHBsYW4gdG8gbWFrZSB1cGRhdGVzIGJhc2VkIG9uIHRoZSBsYXN0IFdHIG1l ZXRpbmcgYW5kIGVtYWlsIGNvbW1lbnRzDQo+PiBmb3IgdGhlIG5leHQgSUVURi4NCj4+IA0KPj4g DQo+PiBKb2huDQo+PiArMS00ODQtOTYyLTAwNjANCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IHY2b3BzIDx2Nm9wcy1ib3VuY2VzQGll dGYub3JnPiBvbiBiZWhhbGYgb2YgRnJlZCBCYWtlcg0KPj4gPGZyZWRAY2lzY28uY29tPg0KPj4g RGF0ZTogRnJpZGF5LCBKYW51YXJ5IDEsIDIwMTYgYXQgMDk6MDANCj4+IFRvOiB2Nm9wcyA8djZv cHNAaWV0Zi5vcmc+DQo+PiBTdWJqZWN0OiBbdjZvcHNdIFN0YXRlIG9mIHBsYXkNCj4+IA0KPj4+ IFJGQyBFZGl0b3I6IEVESVQNCj4+PiAJMjAxNS0xMS0yMwlkcmFmdC1pZXRmLXY2b3BzLXJlZHVj aW5nLXJhLWVuZXJneS1jb25zdW1wdGlvbg0KPj4+IAkyMDE1LTEwLTI2CWRyYWZ0LWlldGYtdjZv cHMtc2lpdC1kYw0KPj4+IAkyMDE1LTEwLTI2CWRyYWZ0LWlldGYtdjZvcHMtc2lpdC1kYy0yeGxh dA0KPj4+IAkyMDE1LTEwLTI2CWRyYWZ0LWlldGYtdjZvcHMtc2lpdC1lYW0NCj4+PiANCj4+PiBS RkMgRWRpdG9yOiBJbiBJU0UgUmV2aWV3DQo+Pj4gCTIwMTUtMTItMTcJZHJhZnQtaWV0Zi12Nm9w cy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUNCj4+PiANCj4+PiBSRkMgRWRpdG9yOiBSRkMtRURJVE9S DQo+Pj4gCTIwMTUtMTAtMTkJZHJhZnQtaWV0Zi12Nm9wcy1wbXR1ZC1lY21wLXByb2JsZW0NCj4+ PiANCj4+PiBXRzogVW51cGRhdGVkIFdHIERvY3VtZW50DQo+Pj4gCTIwMTUtMTAtMTkJZHJhZnQt aWV0Zi12Nm9wcy1kZXNpZ24tY2hvaWNlcw0KPj4+IAkyMDE1LTA3LTA2CWRyYWZ0LWlldGYtdjZv cHMtZGhjcHY2LXNsYWFjLXByb2JsZW0NCj4+PiANCj4+PiBXRzogVXBkYXRlZCBXRyBEb2N1bWVu dA0KPj4+IAkyMDE1LTEyLTEwCWRyYWZ0LWlldGYtdjZvcHMtaG9zdC1hZGRyLWF2YWlsYWJpbGl0 eQ0KPj4+IAkyMDE1LTExLTAxCWRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBl ci1ob3N0DQo+Pj4gDQo+Pj4gV0c6IFdHIENvbnNlbnN1czogV2FpdGluZyBmb3IgV3JpdGUtVXAN Cj4+PiAJMjAxNS0xMi0xMQlkcmFmdC1pZXRmLXY2b3BzLWlwdjYtZWhzLWluLXJlYWwtd29ybGQN Cj4+PiANCj4+PiBJbmRpdmlkdWFsIFN1Ym1pc3Npb246IFVudXBkYXRlZA0KPj4+IAkyMDE1LTEw LTE5CWRyYWZ0LWpqbWItdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0DQo+Pj4gCTIw MTUtMTAtMTkJZHJhZnQteHUtdjZvcHMtZHNsaXRlLXJlZHVuZGFuY3kNCj4+PiAJMjAxNS0xMC0x NQlkcmFmdC1nb250LXY2b3BzLWlwdjYtZWhzLXBhY2tldC1kcm9wcw0KPj4+IAkyMDE1LTEwLTEw CWRyYWZ0LWJhby12Nm9wcy1yZmM2MTQ1YmlzDQo+Pj4gCTIwMTUtMDktMjEJZHJhZnQteWJhaS12 Nm9wcy1pcHY2LWZvci1vcGVuc3RhY2sNCj4+PiAJMjAxNS0wNy0wNglkcmFmdC1ha2lyYS12Nm9w cy1tYXBlLWV4cGVyaWVuY2UNCj4+PiAJMjAxNS0wNy0wNglkcmFmdC14Y2YtdjZvcHMtY2hpbmF0 ZWxlY29tLWRlcGxveW1lbnQNCj4+PiAJMjAxNS0wNy0wNQlkcmFmdC1odWktdjZvcHMtaXB2NnRy YW5zLXNlbGVjdC1uZnYNCj4+PiAJMjAxNS0wNy0wNQlkcmFmdC14bGktdjZvcHMtY2VybmV0LWRl cGxveW1lbnQNCj4+PiAJMjAxNS0wNy0wNQlkcmFmdC15YW5nLXY2b3BzLWlwdjZ0cmFuLXNlbGVj dA0KPj4+IA0KPj4+IEluZGl2aWR1YWwgU3VibWlzc2lvbjogVXBkYXRlZA0KPj4+IAkyMDE1LTEx LTA1CWRyYWZ0LXRlbXBsaW4tdjZvcHMtcGRob3N0DQo+Pj4gDQo+Pj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiB2Nm9wcyBtYWlsaW5nIGxpc3QN Cj4+PiB2Nm9wc0BpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdjZvcHMNCj4+PiANCj4+IA0KPg0KDQo= From nobody Mon Jan 4 17:55:57 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFFD01ACE57 for ; Mon, 4 Jan 2016 17:55:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 xeKgd1-81EVl for ; Mon, 4 Jan 2016 17:55:54 -0800 (PST) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.119.120]) by ietfa.amsl.com (Postfix) with ESMTP id 4249A1ACE52 for ; Mon, 4 Jan 2016 17:55:54 -0800 (PST) Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com [209.85.213.177]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128/128); for ; Mon, 4 Jan 2016 19:55:52 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ig0-f177.google.com [209.85.213.177] #+LO+TS+TR X-Umn-Classification: local Received: by mail-ig0-f177.google.com with SMTP id ph11so4722006igc.1 for ; Mon, 04 Jan 2016 17:55:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=reply-to:subject:references:to:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=Lj6cJjuAv6Dc4fsMLbtk8CvXLqOKMmb4uMKis+/jVOg=; b=UvI9FhyneFUnO1uYK9BVRaTIEjIT13RH/2qobbP5guFSXsjWgr9U9v4RxTyHQawfNP SvskmrabG+BJmMOMC5UFmbbVl+/b6CV7hFQsrFHOK9ay6D68AS9U6kpbBaFUctjtkwP2 HLue1SHahfhBOh9VcsNgKotZNX5L6V/QbIp9c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:cc:from :organization:message-id:date:user-agent:mime-version:in-reply-to :content-type:content-transfer-encoding; bh=Lj6cJjuAv6Dc4fsMLbtk8CvXLqOKMmb4uMKis+/jVOg=; b=PN/sTyh+b4R711p0eKXJzGAGy9YBJptQLnomoMpXlc9Lq6zwWmaaDBTirldHULRLCp +mel7eftuGZUf4kJvMISLeNwyGY3806qKRn3p+4KKS3kg2GTeoMum91ruyKgrJrRKEkI wj8jQ1FYovOO5WrpJ83PFoEScIIczowOz7befyvPsPHm4ncLqKPrdM7iiyrLJgouUoxa dOQDm1pfYoKCdgSkr6iaPF4U7q0CCVQ6DskWXFNjDR2drQ4BXwWWLbU1wPFi6gZNMTG1 H9MSylLk3GRwck6qKkLjW10eWG0YdVZT3aoYnLpNv5h6huF2R/DdLroGEkfAyud5u6Ma KwJA== X-Gm-Message-State: ALoCoQmjrou7FFrjJF46GNk1MrmLxGQczNJT0S6Vx8bKbPjz6Oo23U5jGwYBnlFfEXNhf6suaFeABhMmo8byFQCfjCavchLHlPgapkg8/bpCAtkM2fiBko+9FJce6SfJ9ITMI3YfIRIqm4bfF4CmO74qDuyBPlou1g== X-Received: by 10.50.43.228 with SMTP id z4mr1375547igl.43.1451958952092; Mon, 04 Jan 2016 17:55:52 -0800 (PST) X-Received: by 10.50.43.228 with SMTP id z4mr1375530igl.43.1451958951928; Mon, 04 Jan 2016 17:55:51 -0800 (PST) Received: from x-10-104-140-88.uofm-secure.wireless.umn.edu ([2607:ea00:107:2001:8973:3e0a:9b74:2644]) by smtp.gmail.com with ESMTPSA id z6sm538587ign.1.2016.01.04.17.55.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Jan 2016 17:55:49 -0800 (PST) References: <201601031900.u03J0LMe009763@irp-lnx1.cisco.com> To: "Brzozowski, John" , Lorenzo Colitti , "draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org" From: David Farmer Organization: University of Minnesota Message-ID: <568B22A4.50406@umn.edu> Date: Mon, 4 Jan 2016 19:55:48 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 01:55:55 -0000 On 1/4/16 07:39 , Brzozowski, John wrote: > > From: v6ops > on ... > The draft is targeted to BCP but it is also a description of a > particular solution. That doesn't work well in some places, notably > where it says that the solution uses a captive portal. I don't think > there will be consensus to say that a captive portal is BCP compared > to, say, 802.1x, hotspot 2.0, etc. ... > > [jjmb] perhaps we can separate the captive portal pieces out in a > separate document. After speaking to you and several others BCPing the > technical bits appears to have value beyond public Wi-Fi networks, > enterprise environments come to mind. I think that is an excellent idea and there is even a newly chartered (announced today) captive portal working group that is probably a better place for the captive portal pieces anyway. https://datatracker.ietf.org/wg/capport/charter/ -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nobody Mon Jan 4 18:50:32 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB5011ACEC0 for ; Mon, 4 Jan 2016 18:50:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 BkOXL59LpMLM for ; Mon, 4 Jan 2016 18:50:29 -0800 (PST) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E2591ACEBB for ; Mon, 4 Jan 2016 18:50:29 -0800 (PST) Received: by mail-yk0-x232.google.com with SMTP id a85so191224407ykb.1 for ; Mon, 04 Jan 2016 18:50:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=N3EM13SzuW1H0gUfTVMyV5PHqnueQ9odl/u35g2b2MM=; b=eIuZ3R4n7TzU6gueE3qYVe2IoCU/TIzvOb0NnvCuvqpaKuqQkpJOJyFXFiL7z7sTay zgXICY/Xk/isz+WuidIWcbopFHun5asM15qKHJ4d/+uQbhaL/qmxyJtsU5vcCtw+Urze 2CnwoPv71tDRNugrr7t+MAR5InLAOyC0C/eiHYJR+SzKuGUFng1+8OR47itFwxCo/fKk KfutuNcSF9D8ML2h0Ck7QG07Wr7dyvwe3qKGSgc18I+ojl65WZ0LOvdWlGdX8aMutB9S ugPSgfWHx2x6L9oj2JQNzgGjWb0CL67W7/jx8PQM722pfaCI7CXg98EgI0Z4FKadqyVY 4XkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=N3EM13SzuW1H0gUfTVMyV5PHqnueQ9odl/u35g2b2MM=; b=lUhPg1F8zTZGQS9V2ILBqsJEMX1oo8LY0rezyrrXX77Tkal+O+jDvAl9kSs/argjMQ YXa6dv0Bt/R94xLT/0xoP5pZjJlnUgjdRa6RGjtbUA0+fXSMEZdymURJVlQl/tGR8iLQ +nJjsTwMh2PD0+KK8HcGx8/UfoFrEKPsD5yPdiq7VmJf1oz6luJUXGG3eD7enVsws3fN gr6rmNSRbtGWJUwvROyAWGkGMfCGYvsRiyKqYS6GJu8xARU5t8PHQTkQNoYQ9ou+EUgO 9dZpX0UR3vJw+WzxNoVVPun7sB2Ds+n6eOm5bOz9YRQKfkjaCiyrPIMVS+n78sHFoogD RIhg== X-Gm-Message-State: ALoCoQlG6I0vm92coVCetG0+TB8+s0DEg1oaQfSFvho3U1hQx5Iw2DR8vYJ+HonacqjzqCub+kGCVFJskZJqVlnvnYLFIfNJZMeD/5MXE1rEj38k3URba0M= X-Received: by 10.129.108.88 with SMTP id h85mr75417449ywc.156.1451962228517; Mon, 04 Jan 2016 18:50:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.208.201 with HTTP; Mon, 4 Jan 2016 18:50:08 -0800 (PST) In-Reply-To: <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> From: Lorenzo Colitti Date: Tue, 5 Jan 2016 11:50:08 +0900 Message-ID: To: "Templin, Fred L" Content-Type: multipart/alternative; boundary=001a114d88f0dc6ce005288d4c9a Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 02:50:32 -0000 --001a114d88f0dc6ce005288d4c9a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Fred, yes, I know you think AERO provides the answer to all known problems ;-) More seriously: - As an author, I oppose adding a reference for the reasons I gave above (and additionally, I think there is likely a procedural issue with citin= g an experimental RFC from a BCP). - As a host implementer, I would much rather implement DHCPv6 PD without AERO than with AERO. It's much simpler on the client side, and it has no network-side dependencies, so it seems more likely to be deployable. Thi= s is my opinion, and I doubt that I will easily be convinced otherwise. That said: the IETF process is based on rough consensus. From what I've seen so far, you are the only WG participant arguing for a reference to AERO in this document, but if somehow rough consensus emerges that this is the right thing to do (and it emerges quickly; bear in mind that we're well past the end of the supplemental post-WGLC comment period that Fred declared a few weeks ago), then we can re-evaluate. Cheers, Lorenzo On Tue, Jan 5, 2016 at 1:55 AM, Templin, Fred L wrote: > Hi Lorenzo, > > > > People have asked about how fault tolerance works, and AERO provides the > answer. > > People have asked about how mobility works, and AERO provides the answer. > > People have asked how path MTU robustness works, and AERO provides the > answer. > > People should be asking how route optimization works, and AERO provides > the answer. > > > > In my experience, the IETF loves a problem and will not tolerate a > solution. In this > > case, AERO is a widely applicable solution that is being overlooked and > ignored in > > this fashion. We need to break out of that mold and go with something tha= t > > stands a chance of working, and AERO is it. > > > > Thanks - Fred > > > > *From:* Lorenzo Colitti [mailto:lorenzo@google.com] > *Sent:* Monday, January 04, 2016 8:41 AM > *To:* Templin, Fred L > *Cc:* internet-drafts; v6ops@ietf.org WG; i-d-announce@ietf.org > > *Subject:* Re: [v6ops] I-D Action: > draft-ietf-v6ops-host-addr-availability-04.txt > > > > Fred. > > > > I do not think it is appropriate to add such a reference. AERO is only on= e > way to use address space delegated by DHCPv6 PD, and there are other, > perhaps more obvious ways, such as using the addresses directly without a > tunnel. I think providing a taxonomy of the different ways to make DHCPv6 > PD work is out of scope for a document whose primary message but "don't > limit the number of addresses the network hands out to hosts". > > > > Cheers, > > Lorenzo > > > > On Tue, Jan 5, 2016 at 1:15 AM, Templin, Fred L > wrote: > > Hi Lorenzo, > > > > I believe this document should also include an informative reference to > AERO > > as the method for managing DHCPv6-PD delegated prefixes. > > > > Thanks =E2=80=93 Fred > > fred.l.templin@boeing.com > > > > *From:* v6ops [mailto:v6ops-bounces@ietf.org] *On Behalf Of *Lorenzo > Colitti > *Sent:* Sunday, January 03, 2016 7:26 PM > *To:* internet-drafts > *Cc:* v6ops@ietf.org WG; i-d-announce@ietf.org > *Subject:* Re: [v6ops] I-D Action: > draft-ietf-v6ops-host-addr-availability-04.txt > > > > On Mon, Jan 4, 2016 at 12:16 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 Operations Working Group of the > IETF. > > Title : Host address availability recommendations > Authors : Lorenzo Colitti > Vint Cerf > Stuart Cheshire > David Schinazi > Filename : draft-ietf-v6ops-host-addr-availability-04.txt > Pages : 13 > Date : 2016-01-03 > > [...] > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-host-addr-availabili= ty-04 > > > > Summary of the changes in this version : > > 1. The text about omitting DAD agreed with Fred Templin. > 2. The suggestions from David Farmer to clarify the scope of the > document: explicitly say that protocol changes and host behaviour are = out > of scope, reword "assign" to provide", etc. > 3. A statement that while RFC 3633 talks about "requesting router", > DHCPv6 PD itself doesn't actually require that the client forward pack= ets, > and thus does not require that the client be a router as defined in RF= C > 2460. > > Cheers, > > Lorenzo > > > --001a114d88f0dc6ce005288d4c9a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Fred,

yes, I know you think AERO provid= es the answer to all known problems ;-)

More serio= usly:
  • As an author, I oppose adding a reference for the r= easons I gave above (and additionally, I think there is likely a procedural= issue with citing an experimental RFC from a BCP).
  • As a host imple= menter, I would much rather implement DHCPv6 PD without AERO than with AERO= . It's much simpler on the client side, and it has no network-side depe= ndencies, so it seems more likely to be deployable. This is my opinion, and= I doubt that I will easily be convinced otherwise.
Tha= t said: the IETF process is based on rough consensus. From what I've se= en so far, you are the only WG participant arguing for a reference to AERO = in this document, but if somehow rough consensus emerges that this is the r= ight thing to do (and it emerges quickly; bear in mind that we're well = past the end of the supplemental post-WGLC comment period that Fred declare= d a few weeks ago), then we can re-evaluate.

C= heers,
Lorenzo

On Tue, Jan 5, 2016 at 1:55 AM, Templin, Fred L <Fred.L.Templin@boeing.com> wrote:

Hi Lorenzo,

=C2=A0

People have asked about how fault tol= erance works, and AERO provides the answer.

People have asked about how mobility = works, and AERO provides the answer.

People have asked how path MTU robust= ness works, and AERO provides the answer.

People should be asking how route opt= imization works, and AERO provides the answer.

=C2=A0

In my experience, the IETF loves a pr= oblem and will not tolerate a solution. In this

case, AERO is a widely applicable sol= ution that is being overlooked and ignored in

this fashion. We need to break out of= that mold and go with something that

stands a chance of working, and AERO = is it.

=C2=A0

Thanks - Fred

=C2=A0

From: Lorenzo Colitti [mailto:lorenzo@google.com]
Sent: Monday, January 04, 2016 8:41 AM
To: Templin, Fred L
Cc: internet-drafts; v6ops@ietf.org WG; i-d-announce@ietf.org


Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availabi= lity-04.txt

=C2=A0

Fred.

=C2=A0

I do not think it is appropriate to add such a refer= ence. AERO is only one way to use address space delegated by DHCPv6 PD, and= there are other, perhaps more obvious ways, such as using the addresses di= rectly without a tunnel. I think providing a taxonomy of the different ways to make DHCPv6 PD work is out of scope fo= r a document whose primary message but "don't limit the number of = addresses the network hands out to hosts".

=C2=A0

Cheers,

Lorenzo

=C2=A0

On Tue, Jan 5, 2016 at 1:15 AM, Templin, Fred L <= Fred.L.Templ= in@boeing.com> wrote:

Hi Lorenzo,

=C2=A0

I believe this document should also i= nclude an informative reference to AERO

as the method for managing DHCPv6-PD = delegated prefixes.

=C2=A0

Thanks =E2=80=93 Fred

fred.l.templin@boeing.com

=C2=A0

From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Lorenzo Colitti
Sent: Sunday, January 03, 2016 7:26 PM
To: internet-drafts
Cc: v6ops@ietf.o= rg WG; i-d-announce@iet= f.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availabi= lity-04.txt

=C2=A0

On Mon, Jan 4, 2016 at 12:16 PM, <internet-drafts@ietf.org= > wrote:

A New Internet-Draft is available from the on-line I= nternet-Drafts directories.
=C2=A0This draft is a work item of the IPv6 Operations Working Group of the= IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Host address availability recommendations
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Lore= nzo Colitti
=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 Vint Cerf
=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 Stuart Cheshire
=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 David Schinazi
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-v6ops-host-addr-availability-04.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 13
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-01-03

[...]

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft= -ietf-v6ops-host-addr-availability-04

=C2=A0

Summary of the changes in this version :

  1. The text about omitting DAD agreed with Fred Templin.
    2. The suggestions from David Farmer to clarify the scope of the document: exp= licitly say that protocol changes and host behaviour are out of scope, rewo= rd "assign" to provide", etc.
  2. A statement that while RFC 3633 talks about "requesting router", = DHCPv6 PD itself doesn't actually require that the client forward packe= ts, and thus does not require that the client be a router as defined in RFC= 2460.

Cheers,

Lorenzo=C2=A0

=C2=A0


--001a114d88f0dc6ce005288d4c9a-- From nobody Mon Jan 4 19:18:04 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF9F1ACEE5 for ; Mon, 4 Jan 2016 19:18:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 hnQdj5R6IBns for ; Mon, 4 Jan 2016 19:18:02 -0800 (PST) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D5CD1ACEE0 for ; Mon, 4 Jan 2016 19:18:02 -0800 (PST) Received: by mail-yk0-x22e.google.com with SMTP id k129so246749620yke.0 for ; Mon, 04 Jan 2016 19:18:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=RF2afq+dDzDu/fGicntfK/vz638zzMRnZGVziaCID/0=; b=FKeWD+FI4tuz8o6VmmiDTw3dKVLbwf08ozIchXbyG+eRwu/Hcf3fWV4QImB55nkO89 Fbt0RGi8YR4KKnEoeOeZlzevnDP5Wg6fdCcHq8JsJLMQZJURiQeYY+UPkiSUYqIufuxM YyHtwq6ap+0iInThBIfl/9taiQfuhgkUAZzrAhbbllXicRAg4e0JiKQSp2jHxJSoJML6 HcrtpS3BTLa/9dWG9xx1aDdvNtxx+0gjvcVkLaRkR5f7kfm/4Kf1xzo+65d/+xy/oGBo 7YgdH1httptLo07fqQuj2vob0irz0LKuKHuzJrxoVNKKKDau/sYWly1D80EBHYEi7VV3 VlQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=RF2afq+dDzDu/fGicntfK/vz638zzMRnZGVziaCID/0=; b=XRvVWgZOSiIgSV6Nbm/zrkH8ONYmuDfPnNSWnLdBwfBkKK+map+j6nXSIz1F9VeDLT Q0XP8nZJuWLUAXAmDLUjECgxI2+vlK8Bppt16WgO4l2RatbWrb/GUlYodQj9HKUoSCiA 6j4X6BzbhEww9nQffZOyrnyh7Xq5ylo1uf0kQCwMRt2CB18fwBzAWBLv/Zugju0QqIZ6 /9KDFhDR82bYcTB+ExSxJzdkCkLtqIhkMKBXqFOuTQdBOS70c+obssxgNILQfyT6yGSw 7y5omo0cXRElVvdCi26iH0SHb/B6wa5nM2AuXOSECx6PVgkHKTA65bLYQs2KGRdEShd/ ri7w== X-Gm-Message-State: ALoCoQk/YVALWa5PCtVULFi5s6bReMg4DDQnAeP7rkKkjSll/BvWMHxVhcMLVzgDRBFFV4zIj1yOvxnk4Yu1LcoDE0Jwl7kh5CHoLSTGYhFFAeqRXCEW52I= X-Received: by 10.13.205.199 with SMTP id p190mr75168690ywd.116.1451963881316; Mon, 04 Jan 2016 19:18:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.208.201 with HTTP; Mon, 4 Jan 2016 19:17:41 -0800 (PST) In-Reply-To: References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> From: Lorenzo Colitti Date: Tue, 5 Jan 2016 12:17:41 +0900 Message-ID: To: "Eric Vyncke (evyncke)" Content-Type: multipart/alternative; boundary=001a114e5eb65fdcca05288daf0b Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 03:18:03 -0000 --001a114e5eb65fdcca05288daf0b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jan 5, 2016 at 1:49 AM, Eric Vyncke (evyncke) wrote: > > Some questions: > > - Q1) The I-D is about multiple addresses with a prefix, but, should > it mention as well the possibility of having different prefixes? (=C3= =A0 la MIF > on a single link) =3D=3D> should explicitely reduce the scope of the I= -D > > I think that question is out of scope for this document. Addresses from multiple prefixes are orthogonal to the main thrust of the draft, which is "don't restrict the number of addresses". Multihoming with multiple prefixes is actively being worked on elsewhere - Fred's drafts in 6man, homenet, etc. > > - Q2) Any reason why only a /64 per host when using DHCP-PD? > > Section 6 talks about all cases - < /64, /64 and > /64 (but says that /64 is outside the current IPv6 specifications). The recommendation is /64 to balance flexibility (e.g., the ability to be extended downstream) with address space conservation. > > - Q3) Should the I-D write anything about the stability of the > delegated prefix? I.e. Being always the same for the same DUID? Goal: = avoid > renumbering within the host? Of course 'if technically feasible' > > I think that should be out of scope. --001a114e5eb65fdcca05288daf0b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jan 5, 2016 at 1:49 AM, Eric Vyncke (evyncke) <evyncke@cisco.com&g= t; wrote:=C2=A0
Some questions:
  • Q1) The I-D is about multiple addresses with a prefix, but, should it m= ention as well the possibility of having different prefixes? (=C3=A0 la MIF= on a single link) =3D=3D> should explicitely reduce the scope of the I-= D
I think that question is out of scope fo= r this document. Addresses from multiple prefixes are orthogonal to the mai= n thrust of the draft, which is "don't restrict the number of addr= esses". Multihoming with multiple prefixes is actively being worked on= elsewhere - Fred's drafts in 6man, homenet, etc.
  • Q2) Any reason why only a /64 per host whe= n using DHCP-PD?
Section 6 talks about all= cases - < /64, /64 and > /64 (but says that /64 is outside the curre= nt IPv6 specifications). The recommendation is /64 to balance flexibility (= e.g., the ability to be extended downstream) with address space conservatio= n.
  • Q3) Should the I-D= write anything about the stability of the delegated prefix? I.e. Being alw= ays the same for the same DUID? Goal: avoid renumbering within the host? Of= course 'if technically feasible'
= I think that should be out of scope.
--001a114e5eb65fdcca05288daf0b-- From nobody Mon Jan 4 19:53:53 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE121ACF6C for ; Mon, 4 Jan 2016 19:53:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.664 X-Spam-Level: * X-Spam-Status: No, score=1.664 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 SXAHnRHx24hX for ; Mon, 4 Jan 2016 19:53:51 -0800 (PST) Received: from vaadcmhout01.cable.comcast.com (unknown [96.114.28.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D61CB1ACF60 for ; Mon, 4 Jan 2016 19:53:50 -0800 (PST) X-AuditID: 60721c4b-f79fb6d00000348f-49-568b3e4dd367 Received: from VAADCEX13.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by vaadcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id D7.F8.13455.D4E3B865; Mon, 4 Jan 2016 22:53:49 -0500 (EST) Received: from VAADCEX09.cable.comcast.com (147.191.102.76) by VAADCEX13.cable.comcast.com (147.191.102.80) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Mon, 4 Jan 2016 22:53:48 -0500 Received: from VAADCEX09.cable.comcast.com ([fe80::3aea:a7ff:fe12:e2a0]) by VAADCEX09.cable.comcast.com ([fe80::3aea:a7ff:fe12:e2a0%19]) with mapi id 15.00.1130.005; Mon, 4 Jan 2016 22:53:48 -0500 From: "Brzozowski, John" To: "Templin, Fred L" , "fred@cisco.com" , "v6ops@ietf.org" Thread-Topic: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host Thread-Index: AQHRRlkOCp+5rU1eFUO36/Fw4pXTKZ7rhkPwgADGZoA= Date: Tue, 5 Jan 2016 03:53:48 +0000 Message-ID: References: <201601031900.u03J0LMe009763@irp-lnx1.cisco.com> <2134F8430051B64F815C691A62D9831832F988DB@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832F988DB@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [68.87.29.10] Content-Type: text/plain; charset="utf-8" Content-ID: <263EB8112B85C84D828D08B20B7430F9@cable.comcast.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrAIsWRmVeSWpSXmKPExsWSUOxpoetr1x1m8POfksX5U1NYLN6vO8Nm cfrYXmYHZo/fB98we0z5vZHVY8mSn0wBzFFcNimpOZllqUX6dglcGUfXHGQreCBdsXemSQNj i3QXIweHhICJxLJzBV2MnECmmMSFe+vZQGwhgS1MEgcv+EDY+xklfm/M7GLkArJPMEpM/TWJ GSTBJmAj8frDT0YQW0SgUmLLlfUsILawQLjEu8aFLBDxCIkTV5dA1VhJXNu6CayXRUBFouHJ IrBlvAL2Emubv7BBLGhnlNjVPAOsgVMgVGL2tU1MIDYj0HXfT60Bs5kFxCVuPZnPBHG1gMSS PeeZIWxRiZeP/7GC2KICehK7n5xihIjrSJy9/gTKNpDYunQfC4QtL3Fkwj8WUEAwC2hKrN+l DzHeQeL7zZcsELaixJTuh+wQdwpKnJz5BKpVXOLwkR2sExilZyG5aBbCpFlIJs1CMmkWkkkL GFlXMcqVJSamJOdm5JeWGBjqJScm5aTqJefnJicWl4DoTYygeC+S8d7BuO6n+yFGAQ5GJR5e L/PuMCHWxLLiytxDjBIczEoivG1GQCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8p193hQkJpCeW pGanphakFsFkmTg4pRoYUzOE+KaaS17XmrfWOic4PNa1zrBw+VqPLI9zd8L6Mq/NvTrtGUer tIGjXJer3dW6R20zNhwOKL55u40/bnGHYvQzq3U8PUu0p0ydee73joti160s2NasjiyUWTFz 3dnE+yIXdbKVN2Zfl79x5vHq512zFsi2f5Vdsvsyp2g8g70f2+ni+8InlViKMxINtZiLihMB GtZJlvMCAAA= Archived-At: Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 03:53:52 -0000 QUVSTyBtYXkgYWRkcmVzcyBzb21lIG9mIHRoZSBzYW1lIHJlcXVpcmVtZW50cyBhbmQgc29tZSBv ZiB0aGUgdXNlIGNhc2VzDQpob3dldmVyLCB0aGVyZSBhcmUgZGlmZmVyZW5jZXMgaW4gaW1wbGVt ZW50YXRpb24gYW5kIGRlcGxveW1lbnQgbW9kZWxzIGluDQpvdXIgZHJhZnQgdGhhdCBzaW1wbHkg c3VpdCBvdXIgbmVlZHMgYmV0dGVyLiBJIGhhdmUgbm8gcGxhbnMgdG8gcGVyZm9ybSBhDQpjb21w YXJpc29uIGJldHdlZW4gdGhlIHR3byBub3IgaXMgQUVSTyBzb21ldGhpbmcgd2UgYXJlIGNvbnNp ZGVyaW5nLiAgSQ0KcmVzcGVjdCB0aGUgZmFjdCB0aGF0IEFFUk8gaGFzIGJlZW4gYXJvdW5kIGZv ciBzb21lIHRpbWUsIGhvd2V2ZXIsIGl0IGRvZXMNCm5vdCBhcHBlYXIgdG8gYmUgd2lkZWx5IGRl cGxveWVkLiAgUGxlYXNlIGtlZXAgbWUgaG9uZXN0IGlmIHRoaXMgaXMgbm90DQp0aGUgY2FzZS4g IEFsc28gSSBhbSBub3QgYXdhcmUgb2YgZGl2ZXJzZSBpbXBsZW1lbnRhdGlvbnMgb2YgdGhlIHNh bWUuDQpKdXN0IGJlY2F1c2UgaXQgaXMgZXhpc3RzIGRvZXMgbm90IG1lYW4gaXQgaXMgdGhlIGJl c3Qgc29sdXRpb24gZm9yIGV2ZXJ5DQpkZXBsb3ltZW50IG1vZGVsIG9yIHVzZSBjYXNlLg0KDQpX aGF0IGlzIGRvY3VtZW50IGluIG91ciBkcmFmdCBpcyB3aGF0IHdpbGwgYmUgZGVwbG95ZWQuDQoN CkpvaG4NCisxLTQ4NC05NjItMDA2MA0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogdjZvcHMgPHY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBGcmVk IFRlbXBsaW4NCjxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPg0KRGF0ZTogTW9uZGF5LCBKYW51 YXJ5IDQsIDIwMTYgYXQgMTE6MTQNClRvOiBGcmVkIEJha2VyIDxmcmVkQGNpc2NvLmNvbT4sIHY2 b3BzIDx2Nm9wc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbdjZvcHNdIEZvY3VzZWQgZGlzY3Vz c2lvbjoNCmRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0DQoNCj5I aSwgSSBkb24ndCBzZWUgaG93IHRoaXMgZGlzY3Vzc2lvbiBzaG91bGQgZ28gZm9yd2FyZCB3aXRo b3V0IGEgY29tcGFyaXNvbg0KPndpdGggd2hhdCBBRVJPIGFscmVhZHkgcHJvdmlkZXMuIEFFUk8g aGFzIGJlZW4gYXJvdW5kIGZvciBhIGxvbmcgdGltZQ0KPmFuZCBoYXMgYSBjb21wcmVoZW5zaXZl IHNwZWNpZmljYXRpb24gb24gaG93IERIQ1B2Ni1QRCB3b3JrcyBvdmVyDQo+dHVubmVscy4gSXQg aW5jbHVkZXMgc29sdXRpb25zIGZvciBtb2JpbGl0eSwgcm91dGUgb3B0aW1pemF0aW9uLA0KPnJl bGlhYmlsaXR5DQo+YW5kIGZhdWx0IHRvbGVyYW5jZSwgc2VjdXJpdHksIG11bHRpcGxlIGludGVy ZmFjZXMgYW5kIHByZWZpeCBwZXIgaG9zdA0KPmNvbnNpZGVyYXRpb25zLiBBbHRob3VnaCB0aGUg YmFzZSBBRVJPIHNwZWMgY2FsbHMgZm9yIEdVRSBhcyB0aGUgZGVmYXVsdA0KPmVuY2Fwc3VsYXRp b24sIG9wZXJhdGlvbiBvdmVyIEdSRSBpcyBzcGVjaWZpZWQgaW4gYSBjb21wYW5pb24gZG9jdW1l bnQ6DQo+DQo+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGVtcGxpbi1h ZXJvbWluLw0KPg0KPkkgdGhpbmsgdGhlIGF1dGhvcnMgb2YgdW5pcXVlLWlwdjYtcHJlZml4LXBl ci1ob3N0IG5lZWQgdG8gZXhwbGFpbiB3aHkNCj5hIGRpZmZlcmVudCBhcHByb2FjaCB0aGFuIEFF Uk8gaXMgbmVlZGVkLg0KPg0KPlRoYW5rcyAtIEZyZWQNCj5mcmVkLmwudGVtcGxpbkBib2Vpbmcu Y29tDQo+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogdjZvcHMgW21h aWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgZnJlZEBjaXNjby5jb20N Cj4+IFNlbnQ6IFN1bmRheSwgSmFudWFyeSAwMywgMjAxNiAxMTowMCBBTQ0KPj4gVG86IHY2b3Bz QGlldGYub3JnDQo+PiBTdWJqZWN0OiBbdjZvcHNdIEZvY3VzZWQgZGlzY3Vzc2lvbjoNCj4+ZHJh ZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QNCj4+IA0KPj4gQW5kIG5v dyBmb3Igc29tZXRoaW5nIGEgbGl0dGxlIGRpZmZlcmVudC4gSSdkIGxpa2UgdG8gaW52aXRlIGZv Y3VzZWQNCj4+IGRpc2N1c3Npb24gb2YgZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVm aXgtcGVyLWhvc3QsIHdoaWNoIHdlDQo+PiBhZG9wdGVkIGF0IElFVEYgOTQNCj4+IA0KPj4gU2xp ZGVzIGFyZSBhdA0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTQvc2xpZGVz L3NsaWRlcy05NC12Nm9wcy00LnBkZi4NCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+IHY2b3BzIG1haWxpbmcgbGlzdA0KPj4gdjZvcHNA aWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMN Cj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPnY2 b3BzIG1haWxpbmcgbGlzdA0KPnY2b3BzQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPg0KDQo= From nobody Mon Jan 4 19:55:30 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 033481AD074 for ; Mon, 4 Jan 2016 19:55:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.664 X-Spam-Level: * X-Spam-Status: No, score=1.664 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 XTMpnhy31m8K for ; Mon, 4 Jan 2016 19:55:27 -0800 (PST) Received: from vaadcmhout01.cable.comcast.com (unknown [96.114.28.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 680491ACF6C for ; Mon, 4 Jan 2016 19:55:22 -0800 (PST) X-AuditID: 60721c4b-f79fb6d00000348f-84-568b3ea97350 Received: from VAADCEX11.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by vaadcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id 7A.F8.13455.9AE3B865; Mon, 4 Jan 2016 22:55:21 -0500 (EST) Received: from VAADCEX09.cable.comcast.com (147.191.102.76) by VAADCEX11.cable.comcast.com (147.191.102.78) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Mon, 4 Jan 2016 22:55:20 -0500 Received: from VAADCEX09.cable.comcast.com ([fe80::3aea:a7ff:fe12:e2a0]) by VAADCEX09.cable.comcast.com ([fe80::3aea:a7ff:fe12:e2a0%19]) with mapi id 15.00.1130.005; Mon, 4 Jan 2016 22:55:20 -0500 From: "Brzozowski, John" To: Tom Herbert , "Fred Baker (fred)" Thread-Topic: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host Thread-Index: AQHRRxwuCp+5rU1eFUO36/Fw4pXTKZ7sS46A Date: Tue, 5 Jan 2016 03:55:20 +0000 Message-ID: References: <201601031900.u03J0LMe009763@irp-lnx1.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [68.87.29.7] Content-Type: text/plain; charset="utf-8" Content-ID: <6D21649445A60844B139418608D74F11@cable.comcast.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsWSUOxpobvSrjvMYPZcKYv3686wWVy+9IjZ 4vSxvcwOzB5Tfm9k9eidO43VY8mSn0wBzFFcNimpOZllqUX6dglcGSs/lBScEqxY9fkxWwPj BMEuRk4OCQETia3XHjJD2GISF+6tZ+ti5OIQEtjCJPHoxHtWCGc/o8TfPX8ZIZwTjBLr501g B2lhE7CReP3hJyOILSLgLfGxezkbiM0soCJx79IdVhBbWCBc4l3jQhaImgiJE1eXQNUbSfy5 dwLI5uBgAapf0poJEuYVsJc42HyKGWJXM6NE88z1YL2cAoESZ+8eB+tlBDr1+6k1TBC7xCVu PZnPBPGCgMSSPeeh3hGVePn4H9gNogJ6ErufnGKEiOtInL3+BMo2kNi6dB8LhC0nMff1PRaQ e5gFNCXW79KHGO8g0fD2FyOErSgxpfshO8SdghInZz6BahWXOHxkB+sERplZSC6ahTBpFpJJ s5BMmoVk0gJG1lWMcmWJiSnJuRn5pSUGhnrJiUk5qXrJ+bnJicUlIHoTIygVFMl472Bc99P9 EKMAB6MSD6+XeXeYEGtiWXFl7iFGCQ5mJRHeNiOgEG9KYmVValF+fFFpTmrxIUZpDhYlcd7T r7vChATSE0tSs1NTC1KLYLJMHJxSDYwBO3q9Zvfvzikuc/Y681UhQuoe92+T9YKn3Frj+lQW rVLd8tjmDqdrj6WAXvcm2cTLd+3mFKybvPgUt83rCA9pO23H2usvbMsuCORH5x6a2Dxl4RUZ v7en7DPmBl6WT/J7+zLY4QHfLbd7XHdLZc/M8PJzP6DZEbTeZGd9mZ+jgVbO712ss5RYijMS DbWYi4oTAZSx4DQBAwAA Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 03:55:28 -0000 VGhhbmtzIFRvbSB3ZSB3aWxsIGZhY3RvciB0aGlzIGluLCBJIGFncmVlIHRoZSBJLUQgdG9kYXkg aXMgaGVhdnkgb24gdGhlDQpXaS1GaSByZWZlcmVuY2VzLiAgSSBiZWxpZXZlIHdlIGNhbiBtYWtl IHRoZSB0ZWNobmljYWwgYml0cyBtb3JlIGdlbmVyaWMuDQoNCkpvaG4NCisxLTQ4NC05NjItMDA2 MA0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogdjZvcHMgPHY2b3Bz LWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBUb20gSGVyYmVydA0KPHRvbUBoZXJiZXJ0 bGFuZC5jb20+DQpEYXRlOiBNb25kYXksIEphbnVhcnkgNCwgMjAxNiBhdCAxMzoxNw0KVG86IEZy ZWQgQmFrZXIgPGZyZWRAY2lzY28uY29tPg0KQ2M6IHY2b3BzIDx2Nm9wc0BpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBbdjZvcHNdIEZvY3VzZWQgZGlzY3Vzc2lvbjoNCmRyYWZ0LWlldGYtdjZvcHMt dW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0DQoNCj5PbiBTdW4sIEphbiAzLCAyMDE2IGF0IDEx OjAwIEFNLCAgPGZyZWRAY2lzY28uY29tPiB3cm90ZToNCj4+IEFuZCBub3cgZm9yIHNvbWV0aGlu ZyBhIGxpdHRsZSBkaWZmZXJlbnQuIEknZCBsaWtlIHRvIGludml0ZSBmb2N1c2VkDQo+PiBkaXNj dXNzaW9uIG9mIGRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LCB3 aGljaCB3ZQ0KPj4gYWRvcHRlZCBhdCBJRVRGIDk0DQo+Pg0KPj4gU2xpZGVzIGFyZSBhdA0KPj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTQvc2xpZGVzL3NsaWRlcy05NC12Nm9w cy00LnBkZi4NCj4+DQo+Rm9ybSB0aGUgZHJhZnQ6DQo+DQo+IldoaWxlIHRoaXMgd29yayB3YXMg b3JpZ2luYWxseSBjb25jZWl2ZWQgaW4gdGhlIGNvbnRleHQgb2YgbGFyZ2UNCj5zY2FsZSBXaS1G aSBuZXR3b3JrcywgdGhlIHNjb3BlIG9mIGFwcGxpY2FiaWxpdHkgaXMgbXVjaCBicm9hZGVyLiIN Cj4NCj5UaGlzIGlzIGNvbXBsZXRlbHkgdHJ1ZSwgaG93ZXZlciBtb3N0IG9mIHRoZSBkcmFmdCBz ZWVtcyB0byBmb2N1cyBvbg0KPnRoZSBXaS1GaSBhcHBsaWNhdGlvbi4gQXQgRmFjZWJvb2ssIGZv ciBpbnN0YW5jZSwgd2UgaW50ZW5kIHRvIGRlcGxveQ0KPjY0LWJpdCBwcmVmaXhlcyBvbiBhbGwg aG9zdCBpbiBkYXRhIGNlbnRlciB3aGljaCBoYXMgbm90aGluZyB0byBkbw0KPndpdGggV2ktRmku IEl0IG1pZ2h0IGJlIGdvb2QgaWYgdGhlIGRyYWZ0IHdlcmUgbW9yZSBnZW5lcmljIGluIHRoaXMN Cj5yZWdhcmQgKG9yIHJlbmFtZWQgaWYgaXQgaXMgZXhwcmVzc2x5IGludGVuZGVkIHRvIHNvbHZl IGFuIGlzc3VlIGZvcg0KPldpLUZpKS4NCj4NCj5UaGFua3MsDQo+VG9tDQo+DQo+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gdjZvcHMgbWFpbGlu ZyBsaXN0DQo+PiB2Nm9wc0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby92Nm9wcw0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+djZvcHMgbWFpbGluZyBsaXN0DQo+djZvcHNAaWV0Zi5vcmcNCj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+DQoNCg== From nobody Mon Jan 4 19:56:39 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEE491ACF6C for ; Mon, 4 Jan 2016 19:56:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.664 X-Spam-Level: * X-Spam-Status: No, score=1.664 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 ONr2swTeFjbi for ; Mon, 4 Jan 2016 19:56:37 -0800 (PST) Received: from vaadcmhout02.cable.comcast.com (unknown [96.114.28.76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BE1A1AD087 for ; Mon, 4 Jan 2016 19:56:37 -0800 (PST) X-AuditID: 60721c4c-f79d66d0000078a0-45-568b3ef46a4a Received: from VAADCEX15.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by vaadcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id 1E.7D.30880.4FE3B865; Mon, 4 Jan 2016 22:56:36 -0500 (EST) Received: from VAADCEX09.cable.comcast.com (147.191.102.76) by VAADCEX15.cable.comcast.com (147.191.102.82) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Mon, 4 Jan 2016 22:56:35 -0500 Received: from VAADCEX09.cable.comcast.com ([fe80::3aea:a7ff:fe12:e2a0]) by VAADCEX09.cable.comcast.com ([fe80::3aea:a7ff:fe12:e2a0%19]) with mapi id 15.00.1130.005; Mon, 4 Jan 2016 22:56:35 -0500 From: "Brzozowski, John" To: David Farmer , Lorenzo Colitti , "draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org" Thread-Topic: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host Thread-Index: AQHRRrIDCp+5rU1eFUO36/Fw4pXTKZ7rXTaAgAEhnAD//83qAA== Date: Tue, 5 Jan 2016 03:56:35 +0000 Message-ID: References: <201601031900.u03J0LMe009763@irp-lnx1.cisco.com> <568B22A4.50406@umn.edu> In-Reply-To: <568B22A4.50406@umn.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [68.87.29.10] Content-Type: text/plain; charset="utf-8" Content-ID: <5A89031A39698C47A79A698815BC8C5D@cable.comcast.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsWSUOxpofvFrjvMoOmvtMXBq5fZLFp/L2e2 WH/6HaPF6WN7mR1YPBZsKvVYsuQnk8eXy5/ZPK4ubGIPYInisklJzcksSy3St0vgypizXL3g jkjF4jtTWRoYZ4h0MXJySAiYSDz7eIkVwhaTuHBvPVsXIxeHkMAWJondCw9DOfsZJea8OskO 4ZxglFh8Yw8bSAubgI3E6w8/GUESIiCJQx/bWUASzAIaEnN3N4IVCQuES7xrXAgWFxGIkDhx dQkjhO0k8WvXGnYQm0VARWLrnU6wel4Be4kT968yQ2y7xCjxf9NpsASngKrE/v8nwQYxAh37 /dQaJohl4hK3nsxngnhCQGLJnvPMELaoxMvH/8CeExXQk9j95BQjRFxH4uz1J1C2gcTWpftY IGx5iSMT/gHZHEAzNSXW79KHGO8gsWVOLzOErSgxpfshO8SdghInZz6BahWXOHxkB+sERplZ SC6ahTBpFpJJs5BMmoVk0gJG1lWMcmWJiSnJuRn5pSUGRnrJiUk5qXrJ+bnJicUlIHoTIyhB FMn47GD8NM3jEKMAB6MSD6+7eXeYEGtiWXFl7iFGCQ5mJRHeNiOgEG9KYmVValF+fFFpTmrx IUZpDhYlcd7Tr7vChATSE0tSs1NTC1KLYLJMHJxSDYwLvsVuCovVFtuzvuP9gckeTxbHpeaY 7dvsKdHIv3zJ9zKdvknnW8L7csvunH6iaqSumqvoPnl6dTT3G+9lK8V3niqpVpxlvn/9vLMl d1Y263HOLPvV6sSZFhF255KP+p/t7/6bKG817Jv7/Xpo44Wt0R5/trB3OmpcdlDS0DT+ffRK zhbXTkMlluKMREMt5qLiRADLeyE4DAMAAA== Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 03:56:38 -0000 VGhhbmtzIERhdmlkLg0KDQpKb2huDQorMS00ODQtOTYyLTAwNjANCg0KDQoNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IERhdmlkIEZhcm1lciA8ZmFybWVyQHVtbi5lZHU+DQpP cmdhbml6YXRpb246IFVuaXZlcnNpdHkgb2YgTWlubmVzb3RhDQpSZXBseS1UbzogRGF2aWQgRmFy bWVyIDxmYXJtZXJAdW1uLmVkdT4NCkRhdGU6IE1vbmRheSwgSmFudWFyeSA0LCAyMDE2IGF0IDIw OjU1DQpUbzogSm9obiBKYXNvbiBCcnpvem93c2tpIDxqb2huX2Jyem96b3dza2lAY2FibGUuY29t Y2FzdC5jb20+LCBMb3JlbnpvDQpDb2xpdHRpIDxsb3JlbnpvQGdvb2dsZS5jb20+LA0KImRyYWZ0 LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0QHRvb2xzLmlldGYub3JnIg0K PGRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0QHRvb2xzLmlldGYu b3JnPg0KQ2M6IERhdmlkIEZhcm1lciA8ZmFybWVyQHVtbi5lZHU+LCB2Nm9wcyA8djZvcHNAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBGb2N1c2VkIGRpc2N1c3Npb246DQpkcmFmdC1p ZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdA0KDQo+T24gMS80LzE2IDA3OjM5 ICwgQnJ6b3pvd3NraSwgSm9obiB3cm90ZToNCj4+DQo+PiBGcm9tOiB2Nm9wcyA8djZvcHMtYm91 bmNlc0BpZXRmLm9yZyA8bWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbg0KPi4uLg0K Pj4gICAgIFRoZSBkcmFmdCBpcyB0YXJnZXRlZCB0byBCQ1AgYnV0IGl0IGlzIGFsc28gYSBkZXNj cmlwdGlvbiBvZiBhDQo+PiAgICAgcGFydGljdWxhciBzb2x1dGlvbi4gVGhhdCBkb2Vzbid0IHdv cmsgd2VsbCBpbiBzb21lIHBsYWNlcywgbm90YWJseQ0KPj4gICAgIHdoZXJlIGl0IHNheXMgdGhh dCB0aGUgc29sdXRpb24gdXNlcyBhIGNhcHRpdmUgcG9ydGFsLiBJIGRvbid0IHRoaW5rDQo+PiAg ICAgdGhlcmUgd2lsbCBiZSBjb25zZW5zdXMgdG8gc2F5IHRoYXQgYSBjYXB0aXZlIHBvcnRhbCBp cyBCQ1AgY29tcGFyZWQNCj4+ICAgICB0bywgc2F5LCA4MDIuMXgsIGhvdHNwb3QgMi4wLCBldGMu DQo+Li4uDQo+Pg0KPj4gW2pqbWJdIHBlcmhhcHMgd2UgY2FuIHNlcGFyYXRlIHRoZSBjYXB0aXZl IHBvcnRhbCBwaWVjZXMgb3V0IGluIGENCj4+IHNlcGFyYXRlIGRvY3VtZW50LiAgQWZ0ZXIgc3Bl YWtpbmcgdG8geW91IGFuZCBzZXZlcmFsIG90aGVycyBCQ1BpbmcgdGhlDQo+PiB0ZWNobmljYWwg Yml0cyBhcHBlYXJzIHRvIGhhdmUgdmFsdWUgYmV5b25kIHB1YmxpYyBXaS1GaSBuZXR3b3JrcywN Cj4+IGVudGVycHJpc2UgZW52aXJvbm1lbnRzIGNvbWUgdG8gbWluZC4NCj4NCj5JIHRoaW5rIHRo YXQgaXMgYW4gZXhjZWxsZW50IGlkZWEgYW5kIHRoZXJlIGlzIGV2ZW4gYSBuZXdseSBjaGFydGVy ZWQNCj4oYW5ub3VuY2VkIHRvZGF5KSBjYXB0aXZlIHBvcnRhbCB3b3JraW5nIGdyb3VwIHRoYXQg aXMgcHJvYmFibHkgYSBiZXR0ZXINCj5wbGFjZSBmb3IgdGhlIGNhcHRpdmUgcG9ydGFsIHBpZWNl cyBhbnl3YXkuDQo+DQo+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93Zy9jYXBwb3J0L2No YXJ0ZXIvDQo+DQo+DQo+LS0gDQo+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09DQo+RGF2aWQgRmFybWVyICAgICAgICAgICAgICAgRW1haWw6IGZhcm1lckB1 bW4uZWR1DQo+T2ZmaWNlIG9mIEluZm9ybWF0aW9uIFRlY2hub2xvZ3kNCj5Vbml2ZXJzaXR5IG9m IE1pbm5lc290YQ0KPjIyMTggVW5pdmVyc2l0eSBBdmUgU0UgICAgIFBob25lOiAxLTYxMi02MjYt MDgxNQ0KPk1pbm5lYXBvbGlzLCBNTiA1NTQxNC0zMDI5ICBDZWxsOiAxLTYxMi04MTItOTk1Mg0K Pj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPg0KDQo= From nobody Mon Jan 4 19:57:00 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9CE1AD09F for ; Mon, 4 Jan 2016 19:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 TQp75FZWSDvl for ; Mon, 4 Jan 2016 19:56:57 -0800 (PST) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.119.20]) by ietfa.amsl.com (Postfix) with ESMTP id 83BA61AD0A1 for ; Mon, 4 Jan 2016 19:56:56 -0800 (PST) Received: from mail-io0-f181.google.com (mail-io0-f181.google.com [209.85.223.181]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128/128); for ; Mon, 4 Jan 2016 21:56:55 -0600 (CST) X-Umn-Remote-Mta: [N] mail-io0-f181.google.com [209.85.223.181] #+LO+TS+TR X-Umn-Classification: local Received: by mail-io0-f181.google.com with SMTP id 77so144804003ioc.2 for ; Mon, 04 Jan 2016 19:56:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=reply-to:subject:references:to:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=39go1/sz9C8wV4PC8CWy19tCruh6qMwgMi8soeCSecA=; b=QzRv6Oed84NBLu8IOPirMRXrUxcUgkE+pXTn+NSiqEBg0M8maCey6NvHMXUJw+WeQB mbBMOouVCWHJsVA8qMlsijEjJHQqR8t3NPN5FfT/hI94dUYPHlq3T+yANeGVTzBY/LWn QgVU8ITF4s3wwW+ZRKyehiJZqYiGY6xYg26GU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:cc:from :organization:message-id:date:user-agent:mime-version:in-reply-to :content-type:content-transfer-encoding; bh=39go1/sz9C8wV4PC8CWy19tCruh6qMwgMi8soeCSecA=; b=nD0iMIOrtCvyRMiePOgG+UPTYAIO518lV2qjboKIca8rY55rBl5/6pHnbGZsogLVnD VWUwDY1SL2IqD6mkKBEHBshUiaDcWYF4V2WfBkLGz/5V9erEgHz2fnqo+N46Hx/UG9Kg OMz5xUly4MZszPsgpvWMvr9Aft33iK8U83ANvKtSvYls9829ZchXrn8gQLhXjLFV2CQB thI9V5ywqUQEegvXTsgiCSYCnA1eQrW8WigeDk+L06LJIXPIfORmU+XKw+rfX/xL0+n1 Hr/TczI0sJvrSyFvUyLDGh9Fd5JhVVmhFPThpQepYsVWulPB6ArOo0bef9yP7zAGCgal OpCQ== X-Gm-Message-State: ALoCoQmgxm8U3cOSRd89bPC3t7Dlm9XxjsbfXamcBEK/dfQ3I4lwlQgC0Vr82Sn+Q/VDx+Sh0JYAW5+Op1jOOiqTQ+ZV7tgkyatA9WDfBEQZPIu3QauoDlR534Y+F4YanFeTGHOnD5fCvcpdVX89Bc9Ujbcv7t+zvg== X-Received: by 10.107.164.25 with SMTP id n25mr95236850ioe.143.1451966214523; Mon, 04 Jan 2016 19:56:54 -0800 (PST) X-Received: by 10.107.164.25 with SMTP id n25mr95236839ioe.143.1451966214363; Mon, 04 Jan 2016 19:56:54 -0800 (PST) Received: from x-10-104-140-88.uofm-secure.wireless.umn.edu ([2607:ea00:107:2001:8973:3e0a:9b74:2644]) by smtp.gmail.com with ESMTPSA id k16sm677447igf.0.2016.01.04.19.56.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Jan 2016 19:56:53 -0800 (PST) References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> To: Lorenzo Colitti , "Templin, Fred L" From: David Farmer Organization: University of Minnesota Message-ID: <568B3F03.1030506@umn.edu> Date: Mon, 4 Jan 2016 21:56:51 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 03:56:59 -0000 I would oppose such a reference only to AERO. I wouldn't oppose a list of "other solutions", that included AERO, draft-ietf-v6ops-unique-ipv6-prefix-per-host, and others too, maybe added to sections 6 in a small paragraph following the table. However, I think the draft is fine without it currently, especially with only 1 or 2 others to add. On 1/4/16 20:50 , Lorenzo Colitti wrote: > Fred, > > yes, I know you think AERO provides the answer to all known problems ;-) > > More seriously: > > * As an author, I oppose adding a reference for the reasons I gave > above (and additionally, I think there is likely a procedural issue > with citing an experimental RFC from a BCP). > * As a host implementer, I would much rather implement DHCPv6 PD > without AERO than with AERO. It's much simpler on the client side, > and it has no network-side dependencies, so it seems more likely to > be deployable. This is my opinion, and I doubt that I will easily be > convinced otherwise. > > That said: the IETF process is based on rough consensus. From what I've > seen so far, you are the only WG participant arguing for a reference to > AERO in this document, but if somehow rough consensus emerges that this > is the right thing to do (and it emerges quickly; bear in mind that > we're well past the end of the supplemental post-WGLC comment period > that Fred declared a few weeks ago), then we can re-evaluate. > > Cheers, > Lorenzo > > On Tue, Jan 5, 2016 at 1:55 AM, Templin, Fred L > > wrote: > > Hi Lorenzo,____ > > __ __ > > People have asked about how fault tolerance works, and AERO provides > the answer.____ > > People have asked about how mobility works, and AERO provides the > answer.____ > > People have asked how path MTU robustness works, and AERO provides > the answer.____ > > People should be asking how route optimization works, and AERO > provides the answer.____ > > __ __ > > In my experience, the IETF loves a problem and will not tolerate a > solution. In this____ > > case, AERO is a widely applicable solution that is being overlooked > and ignored in____ > > this fashion. We need to break out of that mold and go with > something that____ > > stands a chance of working, and AERO is it.____ > > __ __ > > Thanks - Fred ____ > > __ __ > > *From:*Lorenzo Colitti [mailto:lorenzo@google.com > ] > *Sent:* Monday, January 04, 2016 8:41 AM > *To:* Templin, Fred L > *Cc:* internet-drafts; v6ops@ietf.org WG; > i-d-announce@ietf.org > > > *Subject:* Re: [v6ops] I-D Action: > draft-ietf-v6ops-host-addr-availability-04.txt____ > > __ __ > > Fred.____ > > __ __ > > I do not think it is appropriate to add such a reference. AERO is > only one way to use address space delegated by DHCPv6 PD, and there > are other, perhaps more obvious ways, such as using the addresses > directly without a tunnel. I think providing a taxonomy of the > different ways to make DHCPv6 PD work is out of scope for a document > whose primary message but "don't limit the number of addresses the > network hands out to hosts".____ > > __ __ > > Cheers,____ > > Lorenzo____ > > __ __ > > On Tue, Jan 5, 2016 at 1:15 AM, Templin, Fred L > > > wrote:____ > > Hi Lorenzo,____ > > ____ > > I believe this document should also include an informative > reference to AERO____ > > as the method for managing DHCPv6-PD delegated prefixes.____ > > ____ > > Thanks – Fred____ > > fred.l.templin@boeing.com ____ > -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nobody Mon Jan 4 22:37:15 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 726D91B2BCC for ; Mon, 4 Jan 2016 22:37:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pEAjEZJRiM4 for ; Mon, 4 Jan 2016 22:37:12 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C8ED1B2BBD for ; Mon, 4 Jan 2016 22:37:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5844; q=dns/txt; s=iport; t=1451975832; x=1453185432; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=o0l0GfVbFHvCub4OC18H8cdRASFIQdxQh73008T20MI=; b=WJRjFWidUpYU33PI3/hzKhO5/WQGb5P6tZ+GxgI4NL8TLIluK2o6bhI3 y+Q7NDVL8S7Gcm1oYNSboSS1eIzcoUqsUSoPw1ssiZYW3pQW2assZ6WKE p5yokslFw+Z8txdctzMfQYHXZkeZfTKVhW0T9pImaTsnoU0qkvTbFNAn8 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AlBQBaY4tW/4sNJK1egm5MgT8GiFOzc?= =?us-ascii?q?oFkhg8CHH46EgEBAQEBAQGBCoQ0AQEBBCNWEAIBCAQNAwECKAMCAgIwFAkIAgQ?= =?us-ascii?q?OBYgvsDWQfQEBAQEBAQEBAQEBAQEBAQEBAQEBARiGVgGEfoR3gnyBSQWXCAGNU?= =?us-ascii?q?IFcjSCKTYNyASkDOIQKcoQIgQgBAQE?= X-IronPort-AV: E=Sophos;i="5.20,524,1444694400"; d="scan'208,217";a="224424447" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Jan 2016 06:37:11 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u056bBou017367 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 Jan 2016 06:37:11 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 5 Jan 2016 01:37:10 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Tue, 5 Jan 2016 01:37:10 -0500 From: "Eric Vyncke (evyncke)" To: Lorenzo Colitti Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt Thread-Index: AQHRRw/pk+sITWQgL0CUhgpxYB2D+57slPeAgABIfQA= Date: Tue, 5 Jan 2016 06:37:10 +0000 Message-ID: References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.56.4] Content-Type: multipart/alternative; boundary="_000_D2B122A1637B7evynckeciscocom_" MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 06:37:13 -0000 --_000_D2B122A1637B7evynckeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TG9yZW56bywNCg0KUmVnYXJkaW5nIFExLCBteSBvbmx5IHN1Z2dlc3Rpb24gaXMgdG8gY2xhcmlm eSB0aGUgc2NvcGUgb2YgeW91ciBJLUQgYnkgc3RhdGluZyBzb21ldGhpbmcgYWxvbmcgdGhlIGxp bmUgb2YgJ1RoaXMgdGVjaG5pcXVlIHNob3VsZCBiZSBhcHBsaWVkIHRvIGFsbCBwcmVmaXhlcyBv biB0aGUgbGluaycNCg0KLcOpcmljDQoNCkZyb206IExvcmVuem8gQ29saXR0aSA8bG9yZW56b0Bn b29nbGUuY29tPG1haWx0bzpsb3JlbnpvQGdvb2dsZS5jb20+Pg0KRGF0ZTogbWFyZGkgNSBqYW52 aWVyIDIwMTYgMDQ6MTcNClRvOiBFcmljIFZ5bmNrZSA8ZXZ5bmNrZUBjaXNjby5jb208bWFpbHRv OmV2eW5ja2VAY2lzY28uY29tPj4NCkNjOiAidjZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGll dGYub3JnPiBXRyIgPHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4+DQpTdWJq ZWN0OiBSZTogW3Y2b3BzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXY2b3BzLWhvc3QtYWRkci1h dmFpbGFiaWxpdHktMDQudHh0DQoNCk9uIFR1ZSwgSmFuIDUsIDIwMTYgYXQgMTo0OSBBTSwgRXJp YyBWeW5ja2UgKGV2eW5ja2UpIDxldnluY2tlQGNpc2NvLmNvbTxtYWlsdG86ZXZ5bmNrZUBjaXNj by5jb20+PiB3cm90ZToNClNvbWUgcXVlc3Rpb25zOg0KDQogICogICBRMSkgVGhlIEktRCBpcyBh Ym91dCBtdWx0aXBsZSBhZGRyZXNzZXMgd2l0aCBhIHByZWZpeCwgYnV0LCBzaG91bGQgaXQgbWVu dGlvbiBhcyB3ZWxsIHRoZSBwb3NzaWJpbGl0eSBvZiBoYXZpbmcgZGlmZmVyZW50IHByZWZpeGVz PyAow6AgbGEgTUlGIG9uIGEgc2luZ2xlIGxpbmspID09PiBzaG91bGQgZXhwbGljaXRlbHkgcmVk dWNlIHRoZSBzY29wZSBvZiB0aGUgSS1EDQoNCkkgdGhpbmsgdGhhdCBxdWVzdGlvbiBpcyBvdXQg b2Ygc2NvcGUgZm9yIHRoaXMgZG9jdW1lbnQuIEFkZHJlc3NlcyBmcm9tIG11bHRpcGxlIHByZWZp eGVzIGFyZSBvcnRob2dvbmFsIHRvIHRoZSBtYWluIHRocnVzdCBvZiB0aGUgZHJhZnQsIHdoaWNo IGlzICJkb24ndCByZXN0cmljdCB0aGUgbnVtYmVyIG9mIGFkZHJlc3NlcyIuIE11bHRpaG9taW5n IHdpdGggbXVsdGlwbGUgcHJlZml4ZXMgaXMgYWN0aXZlbHkgYmVpbmcgd29ya2VkIG9uIGVsc2V3 aGVyZSAtIEZyZWQncyBkcmFmdHMgaW4gNm1hbiwgaG9tZW5ldCwgZXRjLg0K --_000_D2B122A1637B7evynckeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <09B826015C121B4489C8329420C403F1@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5Mb3JlbnpvLDwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+UmVnYXJkaW5nIFExLCBteSBvbmx5IHN1Z2dl c3Rpb24gaXMgdG8gY2xhcmlmeSB0aGUgc2NvcGUgb2YgeW91ciBJLUQgYnkgc3RhdGluZyBzb21l dGhpbmcgYWxvbmcgdGhlIGxpbmUgb2YgJ1RoaXMgdGVjaG5pcXVlIHNob3VsZCBiZSBhcHBsaWVk IHRvIGFsbCBwcmVmaXhlcyBvbiB0aGUgbGluayc8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2Pi3DqXJpYzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JP RFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6 MTFwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVt IG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFE RElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAx cHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0K PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5Mb3JlbnpvIENvbGl0 dGkgJmx0OzxhIGhyZWY9Im1haWx0bzpsb3JlbnpvQGdvb2dsZS5jb20iPmxvcmVuem9AZ29vZ2xl LmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwv c3Bhbj5tYXJkaSA1IGphbnZpZXIgMjAxNiAwNDoxNzxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdl aWdodDpib2xkIj5UbzogPC9zcGFuPkVyaWMgVnluY2tlICZsdDs8YSBocmVmPSJtYWlsdG86ZXZ5 bmNrZUBjaXNjby5jb20iPmV2eW5ja2VAY2lzY28uY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHls ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj4mcXVvdDs8YSBocmVmPSJtYWlsdG86djZv cHNAaWV0Zi5vcmciPnY2b3BzQGlldGYub3JnPC9hPiBXRyZxdW90OyAmbHQ7PGEgaHJlZj0ibWFp bHRvOnY2b3BzQGlldGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5 bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogW3Y2b3BzXSBJLUQgQWN0 aW9uOiBkcmFmdC1pZXRmLXY2b3BzLWhvc3QtYWRkci1hdmFpbGFiaWxpdHktMDQudHh0PGJyPg0K PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FU VFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlk OyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0 ciI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+ T24gVHVlLCBKYW4gNSwgMjAxNiBhdCAxOjQ5IEFNLCBFcmljIFZ5bmNrZSAoZXZ5bmNrZSkgPHNw YW4gZGlyPSJsdHIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzpldnluY2tlQGNpc2NvLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmV2eW5ja2VAY2lzY28uY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOiZuYnNw Ow0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHgg MHB4IDAuOGV4O2JvcmRlci1sZWZ0LXdpZHRoOjFweDtib3JkZXItbGVmdC1jb2xvcjpyZ2IoMjA0 LDIwNCwyMDQpO2JvcmRlci1sZWZ0LXN0eWxlOnNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRp diBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQ7Y29sb3I6cmdiKDAsMCwwKTtmb250LXNpemU6 MTRweDtmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWYiPg0KPGRpdj5Tb21lIHF1ZXN0aW9u czo8L2Rpdj4NCjx1bD4NCjxsaT5RMSkgVGhlIEktRCBpcyBhYm91dCBtdWx0aXBsZSBhZGRyZXNz ZXMgd2l0aCBhIHByZWZpeCwgYnV0LCBzaG91bGQgaXQgbWVudGlvbiBhcyB3ZWxsIHRoZSBwb3Nz aWJpbGl0eSBvZiBoYXZpbmcgZGlmZmVyZW50IHByZWZpeGVzPyAow6AgbGEgTUlGIG9uIGEgc2lu Z2xlIGxpbmspID09Jmd0OyBzaG91bGQgZXhwbGljaXRlbHkgcmVkdWNlIHRoZSBzY29wZSBvZiB0 aGUgSS1EPC9saT48L3VsPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PkkgdGhpbmsgdGhh dCBxdWVzdGlvbiBpcyBvdXQgb2Ygc2NvcGUgZm9yIHRoaXMgZG9jdW1lbnQuIEFkZHJlc3NlcyBm cm9tIG11bHRpcGxlIHByZWZpeGVzIGFyZSBvcnRob2dvbmFsIHRvIHRoZSBtYWluIHRocnVzdCBv ZiB0aGUgZHJhZnQsIHdoaWNoIGlzICZxdW90O2Rvbid0IHJlc3RyaWN0IHRoZSBudW1iZXIgb2Yg YWRkcmVzc2VzJnF1b3Q7LiBNdWx0aWhvbWluZyB3aXRoIG11bHRpcGxlIHByZWZpeGVzIGlzIGFj dGl2ZWx5IGJlaW5nIHdvcmtlZCBvbg0KIGVsc2V3aGVyZSAtIEZyZWQncyBkcmFmdHMgaW4gNm1h biwgaG9tZW5ldCwgZXRjLjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D2B122A1637B7evynckeciscocom_-- From nobody Mon Jan 4 22:50:36 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE211B2BD3 for ; Mon, 4 Jan 2016 22:50:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Zd2OCRDkYT_q for ; Mon, 4 Jan 2016 22:50:34 -0800 (PST) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 499AC1B2BD2 for ; Mon, 4 Jan 2016 22:50:34 -0800 (PST) Received: by mail-yk0-x22c.google.com with SMTP id a85so195212732ykb.1 for ; Mon, 04 Jan 2016 22:50:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=qVyDUVQbU29r0JV6b5Dx7KuEcZ2K+zTzwjeWDpzzA/c=; b=TM3+1dwK606HXywxPT+vLnRrzeGMG3YDa7KWBW0rv09uXFMQz6DvJB34CKcAcYSSKz PFYe4F7OAdLI/NtZtPvcEz/cDv2U9L+QvSUtcO1vnwrcQQ9ZusTBw0z8a5/5A7RS9h/S t0CpL8R5LLCHO/s4HYAqVW2I7O2Wj7e2ObubFfP7ms3JcWztBjNnfezyETEY1jaeebuc CXOO9PLd7ur+ZwGIausOXxjEyMrni+psp8F5d31qXtOoOHSuQ14ZI0cFfU2C9yx0kDod htM9yNq6HRxUKDi3mkdOaSyXMENnWB7knDVONYAZ6XhugJvZVw95l7kGUVIYqHYrOvYn dR8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=qVyDUVQbU29r0JV6b5Dx7KuEcZ2K+zTzwjeWDpzzA/c=; b=O/QzDceo8fGIdtjHdRdUUilxdbnImXD9hKZZfR2Gzrn1J6/07oC+xiwRh0aYfgDxfQ oM4s32RFCTKoOGJqzS7OtoroiyJ1O54tAYOpdpR380ZXrLzV6FLJ5lMgL/UaGybeAgGr NmnKEw4FsGU9jByNZUV9ZvIabhUiKUs9uzy4GTRZHL2dcVlm9rEyLYtBQl3wCqHF1n3G j3XHqbcmJdPlsDj8UWil9TAaN4g50z7K21qf8lHvaJYK5NYpCYngSdih4CfYlO/71cj3 0IGlbFlwGYr/NUeXl9B5W1iBqnn4ViNtE5Ymd8h8gfr8YzQwTgl1fL21i1FIRRXCGWE4 7X9w== X-Gm-Message-State: ALoCoQkQGUS13lbQvnB4SzvgiaFM6n7k3xUfOzPIC10XM5GDgPFfRXG3L6mZ3CXFb8ccaz7XqgoqK70fDW5zqyeH8Fn3Fs0H1a4EoeW3Rm7tLtUkhPj4Mj0= X-Received: by 10.129.41.17 with SMTP id p17mr65372671ywp.160.1451976633404; Mon, 04 Jan 2016 22:50:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.208.201 with HTTP; Mon, 4 Jan 2016 22:50:13 -0800 (PST) In-Reply-To: References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> From: Lorenzo Colitti Date: Tue, 5 Jan 2016 15:50:13 +0900 Message-ID: To: "Eric Vyncke (evyncke)" Content-Type: multipart/alternative; boundary=001a11407ee875634c052890a76c Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 06:50:35 -0000 --001a11407ee875634c052890a76c Content-Type: text/plain; charset=UTF-8 On Tue, Jan 5, 2016 at 3:37 PM, Eric Vyncke (evyncke) wrote: > Regarding Q1, my only suggestion is to clarify the scope of your I-D by > stating something along the line of 'This technique should be applied to > all prefixes on the link' > No objections with your intent, but... isn't that obvious? I don't see how it's possible to interpret the text of this document as saying that a network can/should provide unlimited addressing on one prefix but only one address on another prefix. --001a11407ee875634c052890a76c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jan 5, 2016 at 3:37 PM, Eric Vyncke (evyncke) <evyncke@cisco.com&g= t; wrote:
Regarding Q1, my only suggestion is to clarify the scope of your I-D b= y stating something along the line of 'This technique should be applied= to all prefixes on the link'

No objections with your intent, but... isn't that obvious?

I don't see how it's possible to interpret the text= of this document as saying that a network can/should provide unlimited add= ressing on one prefix but only one address on another prefix.
--001a11407ee875634c052890a76c-- From nobody Tue Jan 5 01:30:42 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8401A87CA for ; Tue, 5 Jan 2016 01:30:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4MeY55lX92yb for ; Tue, 5 Jan 2016 01:30:38 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 660441A88A5 for ; Tue, 5 Jan 2016 01:30:38 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u059UZRD022315; Tue, 5 Jan 2016 10:30:36 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3A7BF2023F5; Tue, 5 Jan 2016 10:38:01 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 2E1382025AF; Tue, 5 Jan 2016 10:38:01 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u059UZUF023118; Tue, 5 Jan 2016 10:30:35 +0100 To: David Farmer References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <568A689F.4060204@gmail.com> <9B04B81C-311B-4199-8398-1D4D64F74848@umn.edu> From: Alexandre Petrescu Message-ID: <568B8D3B.1060008@gmail.com> Date: Tue, 5 Jan 2016 10:30:35 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <9B04B81C-311B-4199-8398-1D4D64F74848@umn.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 09:30:40 -0000 Le 04/01/2016 17:24, David Farmer a écrit : > > On Jan 4, 2016, at 06:42, Alexandre Petrescu > > > wrote: >> Le 04/01/2016 04:25, Lorenzo Colitti a écrit : >>> 3. A statement that while RFC 3633 talks about "requesting >>> router", DHCPv6 PD itself doesn't actually require that the >>> client forward packets, and thus does not require that the >>> client be a router as defined in RFC 2460. >> >> Lorenzo - I noticed earlier emails where a doubt about DHCP-PD RFC >> relying on these to be Routers, or not. >> >> I agree with you the DHCP-PD RFC calls them Routers. It may >> rightfully not go too deep into requiring them to forward packets >> or maintain a FIB. It would be too many things to require. Maybe >> just calling them Routers is sufficient, for brevity. >> >> At the same time, certainly DHCP-PD RFC is not specified with >> Hosts in mind and this is not good. >> >> Alex > > In RFC3633, requesting router is defined "the router that acts as a > DHCP client and is requesting prefix(es) to be assigned." In > RFC3315, DHCP Client (or Client) is defined as, "a node that > initiates requests on a link to obtain configuration parameters from > one or more DHCP servers." With the clarification Lorenzo provides I > think it is clear that DHCPv6 PD is just a protocol to obtain a > prefix as a configuration parameter and makes no requirements that > only routers can obtain prefixes. > > > How about the further clarification; > > > While [RFC3633] primarily considers the use case defined in > [RFC3769] ...for fixed routers, and RFC6276 and RFC7148 for mobile routers, > and refers to the DHCP client as a "requesting router", DHCPv6 PD > itself does not require that the DHCP client receiving the IPv6 > prefix parameter forward IPv6 packets not addressed to itself. This reads sufficient. > and thus does not require that the DHCP client be an IPv6 router as > defined in [RFC2460]. This is superfluous. The "thus" does not follow. The rfc2460 definition of a router includes a "Note" which, if understood as I do, makes think that a DHCPv6 PD Host with multiple interfaces is actually a Router. Alex > > > Thanks > > > -- =============================================== David Farmer > Email: farmer@umn.edu Office of Information > Technology University of Minnesota 2218 University Ave SE Phone: > +1-612-626-0815 Minneapolis, MN 55414-3029 Cell: +1-612-812-9952 > =============================================== > > From nobody Tue Jan 5 01:40:45 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89B8B1AD353 for ; Tue, 5 Jan 2016 01:40:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAE1D-0JASCd for ; Tue, 5 Jan 2016 01:40:41 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B1401AD352 for ; Tue, 5 Jan 2016 01:40:41 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u059ecJW028411; Tue, 5 Jan 2016 10:40:38 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 09DA9202387; Tue, 5 Jan 2016 10:48:04 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id F2328200C34; Tue, 5 Jan 2016 10:48:03 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u059ecGM021728; Tue, 5 Jan 2016 10:40:38 +0100 To: Lorenzo Colitti References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <568A689F.4060204@gmail.com> From: Alexandre Petrescu Message-ID: <568B8F96.9090107@gmail.com> Date: Tue, 5 Jan 2016 10:40:38 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 09:40:43 -0000 Le 04/01/2016 17:45, Lorenzo Colitti a écrit : > On Mon, Jan 4, 2016 at 9:42 PM, Alexandre Petrescu > > wrote: > > I agree with you the DHCP-PD RFC calls them Routers. It may > rightfully not go too deep into requiring them to forward packets or > maintain a FIB. It would be too many things to require. Maybe just > calling them Routers is sufficient, for brevity. > > > Do you disagree with the text that is in the draft now? > > While [RFC3633] assumes that the DHCPv6 client is a router, DHCPv6 > PD itself does not require that the client forward IPv6 packets > not addressed to itself, and thus does not require that the client > be an IPv6 router as defined in [RFC2460]. > > That statement seems pretty straightforward to me. The statement is too long. For one, its latter part clashes with some interpretation of rFC2460 by which a Router does forward between its virtual interfaces. I think the intention is to express that DHCP-PD has not been specified as a way for a single-interfaced Host to obtain multiple addresses for itself. If that's the intention then I agree. Because DHCPv6-PD has been specified and implemented mainly for site routers like CPEs, or for (P)MIP Mobile Routers - they all RA the delegated prefixes further down to other computers. This behaviour (send RA containing the delegated prefix) is always in the implementations although the DHCP-PD specs are mostly silent about it, IIRC. This can lead to a problem statement. Because what one wants in this newDHCP-PD Client behaviour is to _not_ RA the delegated prefix to other computers. Alex From nobody Tue Jan 5 01:41:36 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D48281AD374 for ; Tue, 5 Jan 2016 01:41:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bhO-pda2l8oK for ; Tue, 5 Jan 2016 01:41:35 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EAD11AD373 for ; Tue, 5 Jan 2016 01:41:34 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u059fWmG028640 for ; Tue, 5 Jan 2016 10:41:32 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 710382024F7 for ; Tue, 5 Jan 2016 10:48:57 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5E8D1202393 for ; Tue, 5 Jan 2016 10:48:57 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u059fV6A022911 for ; Tue, 5 Jan 2016 10:41:31 +0100 To: v6ops@ietf.org References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> From: Alexandre Petrescu Message-ID: <568B8FCB.8060002@gmail.com> Date: Tue, 5 Jan 2016 10:41:31 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 09:41:36 -0000 Le 04/01/2016 17:49, Eric Vyncke (evyncke) a écrit : > I was silent in front of the avalanche about -03 but as things are > quieter now: > [...] > * Q2) Any reason why only a /64 per host when using DHCP-PD? I have the same question. Alex From nobody Tue Jan 5 01:49:47 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC781B2A4A for ; Tue, 5 Jan 2016 01:49:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-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 TWyni1Na8M4g for ; Tue, 5 Jan 2016 01:49:44 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7564C1B2A49 for ; Tue, 5 Jan 2016 01:49:44 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 876F86037D for ; Tue, 5 Jan 2016 10:49:41 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 4B7BC602C7 for ; Tue, 5 Jan 2016 10:49:41 +0100 (CET) Received: (qmail 7131 invoked by uid 1007); 5 Jan 2016 10:49:41 +0100 Date: Tue, 5 Jan 2016 10:49:41 +0100 From: Gert Doering To: Alexandre Petrescu Message-ID: <20160105094941.GT58491@Space.Net> References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <568B8FCB.8060002@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <568B8FCB.8060002@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 09:49:46 -0000 Hi, On Tue, Jan 05, 2016 at 10:41:31AM +0100, Alexandre Petrescu wrote: > Le 04/01/2016 17:49, Eric Vyncke (evyncke) a écrit : > > I was silent in front of the avalanche about -03 but as things are > > quieter now: > > [...] > > * Q2) Any reason why only a /64 per host when using DHCP-PD? > > I have the same question. At some point the address policy fairy will come and eat you all. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Tue Jan 5 05:08:33 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D920B1A6F8B for ; Tue, 5 Jan 2016 05:08:32 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc" 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 WiVURgBTTzX2 for ; Tue, 5 Jan 2016 05:08:31 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo6-he.hq.phicoh.net [IPv6:2001:470:d16a:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1881A6F3F for ; Tue, 5 Jan 2016 05:08:31 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1aGRLe-0000EhC; Tue, 5 Jan 2016 14:08:26 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> In-reply-to: Your message of "Tue, 5 Jan 2016 11:50:08 +0900 ." Date: Tue, 05 Jan 2016 14:08:21 +0100 Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 13:08:33 -0000 >yes, I know you think AERO provides the answer to all known problems ;-) > >More seriously: > > - As an author, I oppose adding a reference for the reasons I gave above > (and additionally, I think there is likely a procedural issue with citin= >g > an experimental RFC from a BCP). > - As a host implementer, I would much rather implement DHCPv6 PD without > AERO than with AERO. It's much simpler on the client side, and it has no > network-side dependencies, so it seems more likely to be deployable. Thi= >s > is my opinion, and I doubt that I will easily be convinced otherwise. Just my opinion, reclassify as informational and then just include the reference to AERO. >From all the discussion we had, we know: - there are essentially no hosts requesting DHCPv6-PD (I wonder if there are any hosts requesting multiple addresses using DHCPv6 IA_NA). - we know that in the CPE world there are at least two different approaches of doing DHCPv6-PD which does affect how the network provides those addresses. (And also affects client implementations) So in short, there simply is no real practice when it comes to a large part of this document. Which also why Fred can bring up AERO, because there may even be more actual hosts (rather than CPEs) doing AERO than hosts requesting DHCPv6-PD through other means. And we also have to curious word play where a host that uses a prefix obtained through DHCPv6-PD has to be a router from the point of view of ND, and is actually a router in one of the use cases (tethering). And will be a router in many implementations (AREO seems an exception in assigning adresses to the upstream interface), but we insist in calling it a host. So, publish as informational. Actually get some experience deploying exactly what is proposed here. And then write a BCP on what is actually deployed and how that works. I think we need a lot more of 'this is how IPv6 really works' and not these are the 5 different ways you can do stuff. From nobody Tue Jan 5 07:21:42 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB4D1A87B9 for ; Tue, 5 Jan 2016 07:21:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 iQOzqQHGVjvD for ; Tue, 5 Jan 2016 07:21:38 -0800 (PST) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 148621A87BE for ; Tue, 5 Jan 2016 07:21:37 -0800 (PST) Received: by mail-yk0-x22c.google.com with SMTP id v14so191174372ykd.3 for ; Tue, 05 Jan 2016 07:21:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1YOBO06mnYfvcG1raynaS7nE2pUD8UMLUVpm6emPEu8=; b=eS57bPSXKe9wHg6bDYsAAxMuTUcTzwBtIK5mcjW2ba5QJztwMO4JlmviS7YXmqnrSh ucjU2T8rX+Vk+KyZkrUVbd/MH3uTwF7IF1FaS4mpT6XPCn66CHZuqpo5uDDtySYEsiSY UGdBFyjEn3EcPphgOdJ1T1haSx8YJX2FzbTEOY85wSCJg0QlAqEJsc/VzvcE1ibOgOcW BhVsm3ZmEvSMn/OuXHikiNP4B7zbMpEeGcVR862BSfHn79ySS5Qo1IAUdQYXA0BAtI1V etBRbURg6mbnTPFSdWR+FY1DA/1VFKKDxVd48GuCPQMD2iqwHHsXkBdyQGJE7+sTNdR2 vbtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=1YOBO06mnYfvcG1raynaS7nE2pUD8UMLUVpm6emPEu8=; b=mAayeiRe7dlfkMlQWGWpmG37LdhXxcbO2uu7+lRfvffYrXivYfQuVBJxaechWr4gKm SQpJxr5TJ786daCbzCFt6jVLkJ1Oi5LulfnlG7QANXNY07WEd2t/Kj/IVeGV+chRrzdi FkMdjMF30TVopOxdgHEJ71Vp7cr15dFxiAM6+5RBpK/mZ/FirxjCBnWT8DIPDyEb+fvz VmXEFQaeBtIpa83b1qiJMAUCwC8bbViIZkMuTzBPylG0SLPXOKPmdXeXmb5ivFvEGTTF 4yGSa+GU8PjOop1nmoBgcSLV0FHPikGTbYI/uzF8grK8IbeEhaIJ5J2eXtL59Pkp1LOn r16g== X-Gm-Message-State: ALoCoQkYBnnkqcD+P5nNlrze/pVVyq+zqEcoumCAzkKlsTS1015vdaLDT9EZWDsN84chx68rmVWCgVnP7ap2pcB5UFWUrMjsAuRVkLZ0JFKyrgLXBkwKgh0= X-Received: by 10.13.238.194 with SMTP id x185mr75560295ywe.35.1452007297107; Tue, 05 Jan 2016 07:21:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.208.201 with HTTP; Tue, 5 Jan 2016 07:21:17 -0800 (PST) In-Reply-To: References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> From: Lorenzo Colitti Date: Wed, 6 Jan 2016 00:21:17 +0900 Message-ID: To: Philip Homburg Content-Type: multipart/alternative; boundary=94eb2c031094284177052897cba5 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 15:21:40 -0000 --94eb2c031094284177052897cba5 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 5, 2016 at 10:08 PM, Philip Homburg wrote: > - there are essentially no hosts requesting DHCPv6-PD > (I wonder if there are any hosts requesting multiple addresses using > DHCPv6 IA_NA). > - we know that in the CPE world there are at least two different > approaches of > doing DHCPv6-PD which does affect how the network provides those > addresses. (And also affects client implementations) > > So in short, there simply is no real practice when it comes to a large part > of this document. > But it's not a "large part of the document" at all. It's not even a large part of the requirements section. I think what you are disagreeing with is only one of the recommendations, which is "if your network will only allow hosts to connect if they do DHCPv6, then don't hand out an addres via IA_NA, but hand out a prefix via DHCPv6 PD". And we also have to curious word play where a host that uses a prefix > obtained through DHCPv6-PD has to be a router from the point of view of ND, No, that's not true. A router is "a node that forwards packets not explicitly addressed to itself" [RFC2460]. A host that uses a prefix obtained using DHCPv6 PD does not need to do that. > and is actually a router in one of the use cases (tethering). And will be > a router in many implementations (AREO seems an exception in assigning adresses to > the upstream interface), but we insist in calling it a host. > Looks like you're assuming that a node needs to be a router in order to send a packet on one interface with a source address assigned to another interface. That's not true at all. In fact, to give you an idea on how this works I just ran a DHCPv6 PD client on my linux laptop to get a prefix from my home router, picked an address out of the prefix, assigned it to lo, and used it: 1. dhclient -d -6 -D LL -P eth0 # Run PD and note the prefix you get. I got 2400:2410:20c0:4450::/60 2. ip -6 addr add dev lo 2400:2410:20c0:4450::1/128 # Pick an address out of the prefix, assign to lo 3. ping6 -I 2400:2410:20c0:4450::1 www.google.com # Use that address to talk to the Internet via eth0 This all works as expected (and as predicted by the specifications). My laptop sends the packets on eth0 because it's the interface with the default route, both my laptop and my home router do NUD for the link-local address of the other device, and packets flow. My laptop is most certainly a host, and IPv6 forwarding is off. As for tethering - sure, a device with tethering enabled is a router. But that's a minor point. If you were to pick only one of the two, would you say that your phone and your laptop are "hosts" or "routers"? I think it's appropriate to call them "hosts", even though they occasionally act as routers. I suppose the word "node" would be more correct, but it would be much less readable. > So, publish as informational. Actually get some experience deploying > exactly what is proposed here. And then write a BCP on what is actually > deployed and how that works. > Again, I think you're not seeing the forest for the (DHCPv6 PD) tree. The point of this document is not "networks should use DHCPv6 PD". The point of this document is "networks that provide service to general purpose devices should provide those devices with multiple addresses at connection time". As the draft says, that statement is true of the networks used by tens of millions of devices every day: pretty much every home network, all 3GPP networks, and so on. DHCPv6 PD is cited simply because if a network has decided "we will use DHCPv6 and nothing else", then the only possible way to assign enough addresses is to use DHCPv6 PD. But that's a tiny minority of the networks out there, and it's only a small part of the draft. --94eb2c031094284177052897cba5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jan 5, 2016 at 10:08 PM, Philip Homburg <pch-v6ops-4@u-1.ph= icoh.com> wrote:
- there are essentiall= y no hosts requesting DHCPv6-PD
=C2=A0 (I wonder if there are any hosts requesting multiple addresses using=
=C2=A0 DHCPv6 IA_NA).
- we know that in the CPE world there are at least two different approaches= of
=C2=A0 doing DHCPv6-PD which does affect how the network provides those
=C2=A0 addresses. (And also affects client implementations)

So in short, there simply is no real practice when it comes to a large part=
of this document.

But it's not a &q= uot;large part of the document" at all. It's not even a large part= of the requirements section. I think what you are disagreeing with is only= one of the recommendations, which is "if your network will only allow= hosts to connect if they do DHCPv6, then don't hand out an addres via = IA_NA, but hand out a prefix via DHCPv6 PD".

And we also have to curious word play where a host that uses a = prefix
obtained through DHCPv6-PD has to be a router from the point of view of ND,=

No, that's not true. A router is "= ;a node that forwards packets not explicitly addressed to itself" [RFC= 2460]. A host that uses a prefix obtained using DHCPv6 PD does not need to = do that.
=C2=A0
and=C2=A0is actually a rou= ter in one of the use cases (tethering). And will be a router
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex"> in many implementations (AREO seems an exception in assigning adresses to the upstream interface), but we insist in calling it a host.

Looks like you're assuming that a node needs to b= e a router in order to send a packet on one interface with a source address= assigned to another interface. That's not true at all. In fact, to giv= e you an idea on how this works I just ran a DHCPv6 PD client on my linux l= aptop to get a prefix from my home router, picked an address out of the pre= fix, assigned it to lo, and used it:
  1. dhclient -d -6 -D LL= -P eth0 =C2=A0 # Run PD and note the prefix you get. I got 2400:2410:20c0:= 4450::/60
  2. ip -6 addr add dev lo=C2=A02400:2410:20c0:4450::1/128 =C2= =A0 =C2=A0# Pick an address out of the prefix, assign to lo
  3. ping6 -= I=C2=A02400:2410:20c0:4450::1 www.google.= com =C2=A0 # Use that address to talk to the Internet via eth0
    4. This all works as expected (and as predicted by the specifications). = My laptop sends the packets on eth0 because it's the interface with the= default route, both my laptop and my home router do NUD for the link-local= address of the other device, and packets flow. My laptop is most certainly= a host, and IPv6 forwarding is off.

    As for tether= ing - sure, a device with tethering enabled is a router. But that's a m= inor point. If you were to pick only one of the two, would you say that you= r phone and your laptop are "hosts" or "routers"? I thi= nk it's appropriate to call them "hosts", even though they oc= casionally act as routers. I suppose the word "node" would be mor= e correct, but it would be much less readable.
=C2=A0
So, publish as informational. Actually get some experience deploying
exactly what is proposed here. And then write a BCP on what is actually
deployed and how that works.

Again, I t= hink you're not seeing the forest for the (DHCPv6 PD) tree. The point o= f this document is not "networks should use DHCPv6 PD". The point= of this document is "networks that provide service to general purpose= devices should provide those devices with multiple addresses at connection= time". As the draft says, that statement is true of the networks used= by tens of millions of devices every day: pretty much every home network, = all 3GPP networks, and so on.

DHCPv6 PD is cit= ed simply because if a network has decided "we will use DHCPv6 and not= hing else", then the only possible way to assign enough addresses is t= o use DHCPv6 PD. But that's a tiny minority of the networks out there, = and it's only a small part of the draft.
--94eb2c031094284177052897cba5-- From nobody Tue Jan 5 10:44:03 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1061B2B65 for ; Tue, 5 Jan 2016 10:44:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 0iTCSDie6Fes for ; Tue, 5 Jan 2016 10:43:59 -0800 (PST) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 864171A904F for ; Tue, 5 Jan 2016 10:43:59 -0800 (PST) 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 u05IhvwG026961; Tue, 5 Jan 2016 12:43:57 -0600 Received: from XCH-BLV-505.nw.nos.boeing.com (xch-blv-505.nw.nos.boeing.com [130.247.25.195]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u05IhnRB026443 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 5 Jan 2016 12:43:50 -0600 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.52]) by XCH-BLV-505.nw.nos.boeing.com ([169.254.5.220]) with mapi id 14.03.0235.001; Tue, 5 Jan 2016 10:43:50 -0800 From: "Templin, Fred L" To: Lorenzo Colitti Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt Thread-Index: AQHRRw6yg6NBQZxHIk+n1ca7lLlCA57rkfFwgAEtoQCAAII1wA== Date: Tue, 5 Jan 2016 18:43:49 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F99CEE@XCH-BLV-504.nw.nos.boeing.com> References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 18:44:01 -0000 SGkgTG9yZW56bywNCg0KRnJvbTogTG9yZW56byBDb2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29n bGUuY29tXSANClNlbnQ6IE1vbmRheSwgSmFudWFyeSAwNCwgMjAxNiA2OjUwIFBNDQpUbzogVGVt cGxpbiwgRnJlZCBMDQpDYzogdjZvcHNAaWV0Zi5vcmcgV0cNClN1YmplY3Q6IFJlOiBbdjZvcHNd IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdjZvcHMtaG9zdC1hZGRyLWF2YWlsYWJpbGl0eS0wNC50 eHQNCg0KRnJlZCwNCg0KeWVzLCBJIGtub3cgeW91IHRoaW5rIEFFUk8gcHJvdmlkZXMgdGhlIGFu c3dlciB0byBhbGwga25vd24gcHJvYmxlbXMgOy0pDQoNCk1vcmUgc2VyaW91c2x5Og0K4oCiIEFz IGFuIGF1dGhvciwgSSBvcHBvc2UgYWRkaW5nIGEgcmVmZXJlbmNlIGZvciB0aGUgcmVhc29ucyBJ IGdhdmUgYWJvdmUgKGFuZCBhZGRpdGlvbmFsbHksIEkgdGhpbmsgdGhlcmUgaXMgbGlrZWx5IGEg cHJvY2VkdXJhbCBpc3N1ZSB3aXRoIGNpdGluZyBhbiBleHBlcmltZW50YWwgUkZDIGZyb20gYSBC Q1ApLg0KDQpGTFQ+Pj4gVGhlIGNpdGF0aW9uIHdvdWxkIGJlIHRvIOKAnGRyYWZ0LXRlbXBsaW4t YWVyb2xpbmvigJ0gd2hpY2ggaXMgYmVpbmcgcHJvcG9zZWQgYXMgc3RhbmRhcmRzLXRyYWNrLg0K RkxUPj4+IFRoZXJlIGFyZSBwbGVudHkgb2YgZXhhbXBsZXMgb2YgaW5mb3JtYXRpdmUgY2l0YXRp b25zIG9mIHdvcmtzIGluIHByb2dyZXNzIGluIHB1Ymxpc2hlZCBSRkNzLg0KDQrigKIgQXMgYSBo b3N0IGltcGxlbWVudGVyLCBJIHdvdWxkIG11Y2ggcmF0aGVyIGltcGxlbWVudCBESENQdjYgUEQg d2l0aG91dCBBRVJPIHRoYW4gd2l0aCBBRVJPLiBJdCdzIG11Y2ggc2ltcGxlciBvbiB0aGUgY2xp ZW50IHNpZGUsIGFuZCBpdCBoYXMgbm8gbmV0d29yay1zaWRlIGRlcGVuZGVuY2llcywgc28gaXQg c2VlbXMgbW9yZSBsaWtlbHkgdG8gYmUgZGVwbG95YWJsZS4gVGhpcyBpcyBteSBvcGluaW9uLCBh bmQgSSBkb3VidCB0aGF0IEkgd2lsbCBlYXNpbHkgYmUgY29udmluY2VkIG90aGVyd2lzZS4NCg0K RkxUPj4+IFRoYXQgaXMgaW5jb3JyZWN0LiBNeSBBRVJPIERIQ1B2NiBjbGllbnQgY29kZSBpcyBt dWNoIHNpbXBsZXIgdGhhbiwgZS5nLiwgdGhlIElTQyBkaGNsaWVudA0KRkxUPj4+IGNvZGUgdGhh dCBkb2VzIG5vdCBkbyBBRVJPLiBIYXZlIGEgbG9vayBhdCBteSBjb2RlLg0KDQpUaGF0IHNhaWQ6 IHRoZSBJRVRGIHByb2Nlc3MgaXMgYmFzZWQgb24gcm91Z2ggY29uc2Vuc3VzLiBGcm9tIHdoYXQg SSd2ZSBzZWVuIHNvIGZhciwgeW91IGFyZSB0aGUgb25seSBXRyBwYXJ0aWNpcGFudCBhcmd1aW5n IGZvciBhIHJlZmVyZW5jZSB0byBBRVJPIGluIHRoaXMgZG9jdW1lbnQsIGJ1dCBpZiBzb21laG93 IHJvdWdoIGNvbnNlbnN1cyBlbWVyZ2VzIHRoYXQgdGhpcyBpcyB0aGUgcmlnaHQgdGhpbmcgdG8g ZG8gKGFuZCBpdCBlbWVyZ2VzIHF1aWNrbHk7IGJlYXIgaW4gbWluZCB0aGF0IHdlJ3JlIHdlbGwg cGFzdCB0aGUgZW5kIG9mIHRoZSBzdXBwbGVtZW50YWwgcG9zdC1XR0xDIGNvbW1lbnQgcGVyaW9k IHRoYXQgRnJlZCBkZWNsYXJlZCBhIGZldyB3ZWVrcyBhZ28pLCB0aGVuIHdlIGNhbiByZS1ldmFs dWF0ZS4NCg0KRkxUPj4+IEl0IHNlZW1zIGxpa2UgdGhlcmUgaXMgc3RpbGwgZW1lcmdpbmcgY29u c2Vuc3VzIG9uIHRoaXMuIFJlbWVtYmVyIGFsc28gdGhhdA0KRkxUPj4+IG1hbnkgcXVlc3Rpb25z IHdlcmUgYXNrZWQgYW5kIEFFUk8gcHJvdmlkZWQgYW5zd2VycyB0byBlYWNoLiBUaGF0DQpGTFQ+ Pj4gd291bGQgc2VlbSB0byBpbmRpY2F0ZSBhIG5lZWQgZm9yIGFuIGluZm9ybWF0aXZlIHJlZmVy ZW5jZS4NCkZMVD4+Pg0KRkxUPj4+IFRoYW5rcyAtIEZyZWQNCg0KQ2hlZXJzLA0KTG9yZW56bw0K DQpPbiBUdWUsIEphbiA1LCAyMDE2IGF0IDE6NTUgQU0sIFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5M LlRlbXBsaW5AYm9laW5nLmNvbT4gd3JvdGU6DQpIaSBMb3JlbnpvLA0KwqANClBlb3BsZSBoYXZl IGFza2VkIGFib3V0IGhvdyBmYXVsdCB0b2xlcmFuY2Ugd29ya3MsIGFuZCBBRVJPIHByb3ZpZGVz IHRoZSBhbnN3ZXIuDQpQZW9wbGUgaGF2ZSBhc2tlZCBhYm91dCBob3cgbW9iaWxpdHkgd29ya3Ms IGFuZCBBRVJPIHByb3ZpZGVzIHRoZSBhbnN3ZXIuDQpQZW9wbGUgaGF2ZSBhc2tlZCBob3cgcGF0 aCBNVFUgcm9idXN0bmVzcyB3b3JrcywgYW5kIEFFUk8gcHJvdmlkZXMgdGhlIGFuc3dlci4NClBl b3BsZSBzaG91bGQgYmUgYXNraW5nIGhvdyByb3V0ZSBvcHRpbWl6YXRpb24gd29ya3MsIGFuZCBB RVJPIHByb3ZpZGVzIHRoZSBhbnN3ZXIuDQrCoA0KSW4gbXkgZXhwZXJpZW5jZSwgdGhlIElFVEYg bG92ZXMgYSBwcm9ibGVtIGFuZCB3aWxsIG5vdCB0b2xlcmF0ZSBhIHNvbHV0aW9uLiBJbiB0aGlz DQpjYXNlLCBBRVJPIGlzIGEgd2lkZWx5IGFwcGxpY2FibGUgc29sdXRpb24gdGhhdCBpcyBiZWlu ZyBvdmVybG9va2VkIGFuZCBpZ25vcmVkIGluDQp0aGlzIGZhc2hpb24uIFdlIG5lZWQgdG8gYnJl YWsgb3V0IG9mIHRoYXQgbW9sZCBhbmQgZ28gd2l0aCBzb21ldGhpbmcgdGhhdA0Kc3RhbmRzIGEg Y2hhbmNlIG9mIHdvcmtpbmcsIGFuZCBBRVJPIGlzIGl0Lg0KwqANClRoYW5rcyAtIEZyZWQgDQrC oA0KRnJvbTogTG9yZW56byBDb2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29nbGUuY29tXSANClNl bnQ6IE1vbmRheSwgSmFudWFyeSAwNCwgMjAxNiA4OjQxIEFNDQpUbzogVGVtcGxpbiwgRnJlZCBM DQpDYzogaW50ZXJuZXQtZHJhZnRzOyB2Nm9wc0BpZXRmLm9yZyBXRzsgaS1kLWFubm91bmNlQGll dGYub3JnDQoNClN1YmplY3Q6IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdjZv cHMtaG9zdC1hZGRyLWF2YWlsYWJpbGl0eS0wNC50eHQNCsKgDQpGcmVkLg0KwqANCkkgZG8gbm90 IHRoaW5rIGl0IGlzIGFwcHJvcHJpYXRlIHRvIGFkZCBzdWNoIGEgcmVmZXJlbmNlLiBBRVJPIGlz IG9ubHkgb25lIHdheSB0byB1c2UgYWRkcmVzcyBzcGFjZSBkZWxlZ2F0ZWQgYnkgREhDUHY2IFBE LCBhbmQgdGhlcmUgYXJlIG90aGVyLCBwZXJoYXBzIG1vcmUgb2J2aW91cyB3YXlzLCBzdWNoIGFz IHVzaW5nIHRoZSBhZGRyZXNzZXMgZGlyZWN0bHkgd2l0aG91dCBhIHR1bm5lbC4gSSB0aGluayBw cm92aWRpbmcgYSB0YXhvbm9teSBvZiB0aGUgZGlmZmVyZW50IHdheXMgdG8gbWFrZSBESENQdjYg UEQgd29yayBpcyBvdXQgb2Ygc2NvcGUgZm9yIGEgZG9jdW1lbnQgd2hvc2UgcHJpbWFyeSBtZXNz YWdlIGJ1dCAiZG9uJ3QgbGltaXQgdGhlIG51bWJlciBvZiBhZGRyZXNzZXMgdGhlIG5ldHdvcmsg aGFuZHMgb3V0IHRvIGhvc3RzIi4NCsKgDQpDaGVlcnMsDQpMb3JlbnpvDQrCoA0KT24gVHVlLCBK YW4gNSwgMjAxNiBhdCAxOjE1IEFNLCBUZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJv ZWluZy5jb20+IHdyb3RlOg0KSGkgTG9yZW56bywNCsKgDQpJIGJlbGlldmUgdGhpcyBkb2N1bWVu dCBzaG91bGQgYWxzbyBpbmNsdWRlIGFuIGluZm9ybWF0aXZlIHJlZmVyZW5jZSB0byBBRVJPDQph cyB0aGUgbWV0aG9kIGZvciBtYW5hZ2luZyBESENQdjYtUEQgZGVsZWdhdGVkIHByZWZpeGVzLg0K wqANClRoYW5rcyDigJMgRnJlZA0KZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbQ0KwqANCkZyb206 IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExvcmVu em8gQ29saXR0aQ0KU2VudDogU3VuZGF5LCBKYW51YXJ5IDAzLCAyMDE2IDc6MjYgUE0NClRvOiBp bnRlcm5ldC1kcmFmdHMNCkNjOiB2Nm9wc0BpZXRmLm9yZyBXRzsgaS1kLWFubm91bmNlQGlldGYu b3JnDQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXY2b3BzLWhv c3QtYWRkci1hdmFpbGFiaWxpdHktMDQudHh0DQrCoA0KT24gTW9uLCBKYW4gNCwgMjAxNiBhdCAx MjoxNiBQTSwgPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gd3JvdGU6DQpBIE5ldyBJbnRlcm5l dC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGly ZWN0b3JpZXMuDQrCoFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIElQdjYgT3BlcmF0 aW9ucyBXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLg0KDQrCoCDCoCDCoCDCoCBUaXRsZcKgIMKg IMKgIMKgIMKgIMKgOiBIb3N0IGFkZHJlc3MgYXZhaWxhYmlsaXR5IHJlY29tbWVuZGF0aW9ucw0K wqAgwqAgwqAgwqAgQXV0aG9yc8KgIMKgIMKgIMKgIMKgOiBMb3JlbnpvIENvbGl0dGkNCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFZpbnQgQ2VyZg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgU3R1YXJ0IENoZXNoaXJlDQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBEYXZpZCBTY2hpbmF6aQ0KwqAgwqAgwqAgwqAgRmls ZW5hbWXCoCDCoCDCoCDCoCA6IGRyYWZ0LWlldGYtdjZvcHMtaG9zdC1hZGRyLWF2YWlsYWJpbGl0 eS0wNC50eHQNCsKgIMKgIMKgIMKgIFBhZ2VzwqAgwqAgwqAgwqAgwqAgwqA6IDEzDQrCoCDCoCDC oCDCoCBEYXRlwqAgwqAgwqAgwqAgwqAgwqAgOiAyMDE2LTAxLTAzDQoNClsuLi5dDQoNCkEgZGlm ZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vd3d3 LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXY2b3BzLWhvc3QtYWRkci1hdmFpbGFi aWxpdHktMDQNCsKgDQpTdW1tYXJ5IG9mIHRoZSBjaGFuZ2VzIGluIHRoaXMgdmVyc2lvbiA6DQox LiBUaGUgdGV4dCBhYm91dCBvbWl0dGluZyBEQUQgYWdyZWVkIHdpdGggRnJlZCBUZW1wbGluLg0K Mi4gVGhlIHN1Z2dlc3Rpb25zIGZyb20gRGF2aWQgRmFybWVyIHRvIGNsYXJpZnkgdGhlIHNjb3Bl IG9mIHRoZSBkb2N1bWVudDogZXhwbGljaXRseSBzYXkgdGhhdCBwcm90b2NvbCBjaGFuZ2VzIGFu ZCBob3N0IGJlaGF2aW91ciBhcmUgb3V0IG9mIHNjb3BlLCByZXdvcmQgImFzc2lnbiIgdG8gcHJv dmlkZSIsIGV0Yy4NCjMuIEEgc3RhdGVtZW50IHRoYXQgd2hpbGUgUkZDIDM2MzMgdGFsa3MgYWJv dXQgInJlcXVlc3Rpbmcgcm91dGVyIiwgREhDUHY2IFBEIGl0c2VsZiBkb2Vzbid0IGFjdHVhbGx5 IHJlcXVpcmUgdGhhdCB0aGUgY2xpZW50IGZvcndhcmQgcGFja2V0cywgYW5kIHRodXMgZG9lcyBu b3QgcmVxdWlyZSB0aGF0IHRoZSBjbGllbnQgYmUgYSByb3V0ZXIgYXMgZGVmaW5lZCBpbiBSRkMg MjQ2MC4NCkNoZWVycywNCkxvcmVuem/CoA0KwqANCg0K From nobody Tue Jan 5 10:50:45 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A19BD1B2BB0 for ; Tue, 5 Jan 2016 10:50:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 YNuD6oZNzybV for ; Tue, 5 Jan 2016 10:50:33 -0800 (PST) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 972BA1B2BA3 for ; Tue, 5 Jan 2016 10:50:33 -0800 (PST) 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 u05Iobel003999; Tue, 5 Jan 2016 10:50:37 -0800 Received: from XCH-PHX-313.sw.nos.boeing.com (xch-phx-313.sw.nos.boeing.com [130.247.25.175]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u05IoWmU003805 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 5 Jan 2016 10:50:32 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.52]) by XCH-PHX-313.sw.nos.boeing.com ([169.254.13.148]) with mapi id 14.03.0235.001; Tue, 5 Jan 2016 10:50:26 -0800 From: "Templin, Fred L" To: "Brzozowski, John" , "fred@cisco.com" , "v6ops@ietf.org" Thread-Topic: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host Thread-Index: AQHRR+nwI13RUsgT4kOKL/Th7Sw3uA== Date: Tue, 5 Jan 2016 18:50:26 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F99D14@XCH-BLV-504.nw.nos.boeing.com> References: <201601031900.u03J0LMe009763@irp-lnx1.cisco.com> <2134F8430051B64F815C691A62D9831832F988DB@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 18:50:35 -0000 SGkgSm9obiwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCcnpvem93 c2tpLCBKb2huIFttYWlsdG86Sm9obl9Ccnpvem93c2tpQGNhYmxlLmNvbWNhc3QuY29tXQ0KPiBT ZW50OiBNb25kYXksIEphbnVhcnkgMDQsIDIwMTYgNzo1NCBQTQ0KPiBUbzogVGVtcGxpbiwgRnJl ZCBMOyBmcmVkQGNpc2NvLmNvbTsgdjZvcHNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFt2Nm9w c10gRm9jdXNlZCBkaXNjdXNzaW9uOiBkcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZp eC1wZXItaG9zdA0KPiANCj4gQUVSTyBtYXkgYWRkcmVzcyBzb21lIG9mIHRoZSBzYW1lIHJlcXVp cmVtZW50cyBhbmQgc29tZSBvZiB0aGUgdXNlIGNhc2VzDQo+IGhvd2V2ZXIsIHRoZXJlIGFyZSBk aWZmZXJlbmNlcyBpbiBpbXBsZW1lbnRhdGlvbiBhbmQgZGVwbG95bWVudCBtb2RlbHMgaW4NCj4g b3VyIGRyYWZ0IHRoYXQgc2ltcGx5IHN1aXQgb3VyIG5lZWRzIGJldHRlci4gSSBoYXZlIG5vIHBs YW5zIHRvIHBlcmZvcm0gYQ0KPiBjb21wYXJpc29uIGJldHdlZW4gdGhlIHR3byBub3IgaXMgQUVS TyBzb21ldGhpbmcgd2UgYXJlIGNvbnNpZGVyaW5nLiAgSQ0KDQpTbywgeW91IGFyZSBzYXlpbmcg InlvdXIgd2F5IGlzIGJldHRlciIgd2hlbiB5b3UgaGF2ZSBub3QgZXZlbiBsb29rZWQgYXQNCkFF Uk8/DQoNCj4gcmVzcGVjdCB0aGUgZmFjdCB0aGF0IEFFUk8gaGFzIGJlZW4gYXJvdW5kIGZvciBz b21lIHRpbWUsIGhvd2V2ZXIsIGl0IGRvZXMNCj4gbm90IGFwcGVhciB0byBiZSB3aWRlbHkgZGVw bG95ZWQuDQoNClRoYXQgaXMgaXJyZWxldmFudC4NCg0KPiBQbGVhc2Uga2VlcCBtZSBob25lc3Qg aWYgdGhpcyBpcyBub3QNCj4gdGhlIGNhc2UuIEFsc28gSSBhbSBub3QgYXdhcmUgb2YgZGl2ZXJz ZSBpbXBsZW1lbnRhdGlvbnMgb2YgdGhlIHNhbWUuDQo+IEp1c3QgYmVjYXVzZSBpdCBpcyBleGlz dHMgZG9lcyBub3QgbWVhbiBpdCBpcyB0aGUgYmVzdCBzb2x1dGlvbiBmb3IgZXZlcnkNCj4gZGVw bG95bWVudCBtb2RlbCBvciB1c2UgY2FzZS4NCg0KV291bGRuJ3QgaXQgbWFrZSBzZW5zZSB0aGVu IHRvIHRoZW4gdG8gaW52ZXN0aWdhdGUgYSB1c2UgY2FzZSBhbmFseXNpcyBmb3INCnlvdXIgdXNl IGNhc2U/DQoNCj4gV2hhdCBpcyBkb2N1bWVudCBpbiBvdXIgZHJhZnQgaXMgd2hhdCB3aWxsIGJl IGRlcGxveWVkLg0KDQpXb3cgLSBkb2Vzbid0IHNlZW0gbGlrZSBhIHZlcnkgb3Blbi1taW5kZWQg cG9zaXRpb24gYW5kIGlnbm9yZXMNCmVtZXJnaW5nIElFVEYgd29ya3MuIEFyZSB5b3Ugc2F5aW5n IHRoYXQgZXhpc3RpbmcgYW5kIGVtZXJnaW5nDQp3b3JrcyBzaG91bGQgYmUgaWdub3JlZCwgYW5k IGEgbmV3IHNvbHV0aW9uIGJsZXNzZWQgd2l0aCBubyB1c2UNCmNhc2UgYW5hbHlzaXM/DQoNClRo YW5rcyAtIEZyZWQNCmZyZWQubC50ZW1wbGluQGJvZWluZy5jb20NCg0KPiBKb2huDQo+ICsxLTQ4 NC05NjItMDA2MA0KPiANCj4gDQo+IA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gRnJvbTogdjZvcHMgPHY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBGcmVk IFRlbXBsaW4NCj4gPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+DQo+IERhdGU6IE1vbmRheSwg SmFudWFyeSA0LCAyMDE2IGF0IDExOjE0DQo+IFRvOiBGcmVkIEJha2VyIDxmcmVkQGNpc2NvLmNv bT4sIHY2b3BzIDx2Nm9wc0BpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFt2Nm9wc10gRm9jdXNl ZCBkaXNjdXNzaW9uOg0KPiBkcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXIt aG9zdA0KPiANCj4gPkhpLCBJIGRvbid0IHNlZSBob3cgdGhpcyBkaXNjdXNzaW9uIHNob3VsZCBn byBmb3J3YXJkIHdpdGhvdXQgYSBjb21wYXJpc29uDQo+ID53aXRoIHdoYXQgQUVSTyBhbHJlYWR5 IHByb3ZpZGVzLiBBRVJPIGhhcyBiZWVuIGFyb3VuZCBmb3IgYSBsb25nIHRpbWUNCj4gPmFuZCBo YXMgYSBjb21wcmVoZW5zaXZlIHNwZWNpZmljYXRpb24gb24gaG93IERIQ1B2Ni1QRCB3b3JrcyBv dmVyDQo+ID50dW5uZWxzLiBJdCBpbmNsdWRlcyBzb2x1dGlvbnMgZm9yIG1vYmlsaXR5LCByb3V0 ZSBvcHRpbWl6YXRpb24sDQo+ID5yZWxpYWJpbGl0eQ0KPiA+YW5kIGZhdWx0IHRvbGVyYW5jZSwg c2VjdXJpdHksIG11bHRpcGxlIGludGVyZmFjZXMgYW5kIHByZWZpeCBwZXIgaG9zdA0KPiA+Y29u c2lkZXJhdGlvbnMuIEFsdGhvdWdoIHRoZSBiYXNlIEFFUk8gc3BlYyBjYWxscyBmb3IgR1VFIGFz IHRoZSBkZWZhdWx0DQo+ID5lbmNhcHN1bGF0aW9uLCBvcGVyYXRpb24gb3ZlciBHUkUgaXMgc3Bl Y2lmaWVkIGluIGEgY29tcGFuaW9uIGRvY3VtZW50Og0KPiA+DQo+ID5odHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC10ZW1wbGluLWFlcm9taW4vDQo+ID4NCj4gPkkgdGhpbmsg dGhlIGF1dGhvcnMgb2YgdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0IG5lZWQgdG8gZXhwbGFp biB3aHkNCj4gPmEgZGlmZmVyZW50IGFwcHJvYWNoIHRoYW4gQUVSTyBpcyBuZWVkZWQuDQo+ID4N Cj4gPlRoYW5rcyAtIEZyZWQNCj4gPmZyZWQubC50ZW1wbGluQGJvZWluZy5jb20NCj4gPg0KPiA+ PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiB2Nm9wcyBbbWFpbHRvOnY2 b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBmcmVkQGNpc2NvLmNvbQ0KPiA+PiBT ZW50OiBTdW5kYXksIEphbnVhcnkgMDMsIDIwMTYgMTE6MDAgQU0NCj4gPj4gVG86IHY2b3BzQGll dGYub3JnDQo+ID4+IFN1YmplY3Q6IFt2Nm9wc10gRm9jdXNlZCBkaXNjdXNzaW9uOg0KPiA+PmRy YWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0DQo+ID4+DQo+ID4+IEFu ZCBub3cgZm9yIHNvbWV0aGluZyBhIGxpdHRsZSBkaWZmZXJlbnQuIEknZCBsaWtlIHRvIGludml0 ZSBmb2N1c2VkDQo+ID4+IGRpc2N1c3Npb24gb2YgZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2 Ni1wcmVmaXgtcGVyLWhvc3QsIHdoaWNoIHdlDQo+ID4+IGFkb3B0ZWQgYXQgSUVURiA5NA0KPiA+ Pg0KPiA+PiBTbGlkZXMgYXJlIGF0DQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRp bmdzLzk0L3NsaWRlcy9zbGlkZXMtOTQtdjZvcHMtNC5wZGYuDQo+ID4+DQo+ID4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IHY2b3BzIG1haWxp bmcgbGlzdA0KPiA+PiB2Nm9wc0BpZXRmLm9yZw0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+ID4NCj4gPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ID52Nm9wcyBtYWlsaW5nIGxpc3QNCj4gPnY2b3BzQGll dGYub3JnDQo+ID5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+ ID4NCg0K From nobody Tue Jan 5 10:51:45 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68EEC1B2BA3 for ; Tue, 5 Jan 2016 10:51:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 SSj-sfeoA1NW for ; Tue, 5 Jan 2016 10:51:42 -0800 (PST) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73CD31B2BB0 for ; Tue, 5 Jan 2016 10:51:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u05IplN9004736; Tue, 5 Jan 2016 10:51:47 -0800 Received: from XCH-BLV-407.nw.nos.boeing.com (xch-blv-407.nw.nos.boeing.com [130.247.25.165]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u05Ipc7I004637 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 5 Jan 2016 10:51:38 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.52]) by XCH-BLV-407.nw.nos.boeing.com ([169.254.7.99]) with mapi id 14.03.0235.001; Tue, 5 Jan 2016 10:51:32 -0800 From: "Templin, Fred L" To: Mark Smith , "Fred Baker (fred)" Thread-Topic: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host Thread-Index: AQHRRykKI13RUsgT4kOKL/Th7Sw3uJ7tRa7g Date: Tue, 5 Jan 2016 18:51:32 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F99D30@XCH-BLV-504.nw.nos.boeing.com> References: <201601031900.u03J0LMe009763@irp-lnx1.cisco.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: multipart/alternative; boundary="_000_2134F8430051B64F815C691A62D9831832F99D30XCHBLV504nwnosb_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: v6ops list Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 18:51:44 -0000 --_000_2134F8430051B64F815C691A62D9831832F99D30XCHBLV504nwnosb_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFyaywNCg0KSSBhbSBpbiB0aGUgcHJvY2VzcyBvZiB3b3JraW5nIGluIHNvbWUgdGV4dCBv biBtdWx0aWNhc3QvTUxEIGFuZCB3aWxsIHN1Ym1pdCBhbg0KdXBkYXRlIGxhdGVyIHRvZGF5Lg0K DQpUaGFua3MgLSBGcmVkDQoNCkZyb206IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIE1hcmsgU21pdGgNClNlbnQ6IE1vbmRheSwgSmFudWFyeSAwNCwg MjAxNiAxMTo0OCBBTQ0KVG86IEZyZWQgQmFrZXIgKGZyZWQpDQpDYzogdjZvcHMgbGlzdA0KU3Vi amVjdDogUmU6IFt2Nm9wc10gRm9jdXNlZCBkaXNjdXNzaW9uOiBkcmFmdC1pZXRmLXY2b3BzLXVu aXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdA0KDQoNCkhpLA0KDQpPbiA0IEphbiAyMDE2IDA2OjAw LCA8ZnJlZEBjaXNjby5jb208bWFpbHRvOmZyZWRAY2lzY28uY29tPj4gd3JvdGU6DQo+DQo+IEFu ZCBub3cgZm9yIHNvbWV0aGluZyBhIGxpdHRsZSBkaWZmZXJlbnQuIEknZCBsaWtlIHRvIGludml0 ZSBmb2N1c2VkDQo+IGRpc2N1c3Npb24gb2YgZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1w cmVmaXgtcGVyLWhvc3QsIHdoaWNoIHdlDQo+IGFkb3B0ZWQgYXQgSUVURiA5NA0KPg0KPiBTbGlk ZXMgYXJlIGF0DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk0L3NsaWRlcy9z bGlkZXMtOTQtdjZvcHMtNC5wZGYuDQo+DQo+DQoNCkkgYWdyZWUgd2l0aCBwb2ludHMgb3RoZXJz IGhhdmUgbWFkZS4NCg0KVGhlIHRpdGxlIHNvdW5kcyBsaWtlIGEgQkNQIHRpdGxlLCBob3dldmVy IHRoZSBjb250ZW50IHJlYWRzIGxpa2UgYSByZWNpcGUvaG93dG8gZm9yIGEgc3BlY2lmaWMgZGVw bG95bWVudCBzY2VuYXJpby4NCg0KSSB0aGluayB0aGVyZSBhcmUgZ2VuZXJhbCBhbmQgbm9uLVdp Zmkgc3BlY2lmaWMgcGFydHMgdGhhdCBzaG91bGQgYmUgc2VwYXJhdGVkLiBSZWZsZWN0aW5nIG9u IHRoZSBudW1iZXIgYW5kIGNvbnRlbnQgb2YgcmVjZW50IGRpc2N1c3Npb25zIGFyb3VuZCBob3N0 cyB1c2luZyBESENQdjYtUEQsIEkgdGhpbmsgdGhlcmUgbmVlZHMgdG8gYmUgYW4gSUQgb24gdGhh dCB0b3BpYy4gRnJlZCdzIGRyYWZ0IHNlZW1zIHRvIGJlIG1vc3RseSB0aGVyZSwgYWx0aG91Z2gg bXVsdGljYXN0L01MRCBuZWVkcyB0byBiZSBjb3ZlcmVkLg0KDQpodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC10ZW1wbGluLXY2b3BzLXBkaG9zdC8NCg0KRmluYWxseSwgYWx0 aG91Z2ggaXQgaW4gc29tZSB3YXlzIGlzIG91dCBvZiBzY29wZSwgSSdkIG5ldmVyIHdhbnQgdG8g c2VlIGEgQkNQIG9mIGFueSBraW5kIHByb3Bvc2luZyB0aGF0IGFsbCBvZiBXaWZpJ3Mgc2VjdXJp dHkgbWVjaGFuaXNtcyBhcmUgdHVybmVkIG9mZiwgYmVjYXVzZSBXaUZpIHRyYWZmaWMgaXMgc28g ZWFzeSB0byBwYWNrZXQgY2FwdHVyZSBldmVyeXRoaW5nIHdoZW4gc2VjdXJpdHkgaXMgc3dpdGNo ZWQgb2ZmLg0KDQpSZWdhcmRzLA0KTWFyay4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+IHY2b3BzQGlldGYu b3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby92Nm9wcw0K --_000_2134F8430051B64F815C691A62D9831832F99D30XCHBLV504nwnosb_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4u RW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgTWFyayw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgYW0gaW4gdGhlIHByb2Nl c3Mgb2Ygd29ya2luZyBpbiBzb21lIHRleHQgb24gbXVsdGljYXN0L01MRCBhbmQgd2lsbCBzdWJt aXQgYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+dXBkYXRlIGxhdGVyIHRvZGF5LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIC0gRnJlZDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IHY2 b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+ TWFyayBTbWl0aDxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEphbnVhcnkgMDQsIDIwMTYgMTE6 NDggQU08YnI+DQo8Yj5Ubzo8L2I+IEZyZWQgQmFrZXIgKGZyZWQpPGJyPg0KPGI+Q2M6PC9iPiB2 Nm9wcyBsaXN0PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIEZvY3VzZWQgZGlzY3Vz c2lvbjogZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3Q8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cD5IaSw8bzpwPjwvbzpwPjwvcD4NCjxwPk9uIDQgSmFuIDIw MTYgMDY6MDAsICZsdDs8YSBocmVmPSJtYWlsdG86ZnJlZEBjaXNjby5jb20iPmZyZWRAY2lzY28u Y29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsgQW5kIG5vdyBmb3Igc29tZXRo aW5nIGEgbGl0dGxlIGRpZmZlcmVudC4gSSdkIGxpa2UgdG8gaW52aXRlIGZvY3VzZWQ8YnI+DQom Z3Q7IGRpc2N1c3Npb24gb2YgZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVy LWhvc3QsIHdoaWNoIHdlPGJyPg0KJmd0OyBhZG9wdGVkIGF0IElFVEYgOTQ8YnI+DQomZ3Q7PGJy Pg0KJmd0OyBTbGlkZXMgYXJlIGF0PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9wcm9jZWVkaW5ncy85NC9zbGlkZXMvc2xpZGVzLTk0LXY2b3BzLTQucGRmIj5odHRwczov L3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85NC9zbGlkZXMvc2xpZGVzLTk0LXY2b3BzLTQucGRm PC9hPi48YnI+DQomZ3Q7PGJyPg0KJmd0OzxvOnA+PC9vOnA+PC9wPg0KPHA+SSBhZ3JlZSB3aXRo IHBvaW50cyBvdGhlcnMgaGF2ZSBtYWRlLjxvOnA+PC9vOnA+PC9wPg0KPHA+VGhlIHRpdGxlIHNv dW5kcyBsaWtlIGEgQkNQIHRpdGxlLCBob3dldmVyIHRoZSBjb250ZW50IHJlYWRzIGxpa2UgYSBy ZWNpcGUvaG93dG8gZm9yIGEgc3BlY2lmaWMgZGVwbG95bWVudCBzY2VuYXJpby48bzpwPjwvbzpw PjwvcD4NCjxwPkkgdGhpbmsgdGhlcmUgYXJlIGdlbmVyYWwgYW5kIG5vbi1XaWZpIHNwZWNpZmlj IHBhcnRzIHRoYXQgc2hvdWxkIGJlIHNlcGFyYXRlZC4gUmVmbGVjdGluZyBvbiB0aGUgbnVtYmVy IGFuZCBjb250ZW50IG9mIHJlY2VudCBkaXNjdXNzaW9ucyBhcm91bmQgaG9zdHMgdXNpbmcgREhD UHY2LVBELCBJIHRoaW5rIHRoZXJlIG5lZWRzIHRvIGJlIGFuIElEIG9uIHRoYXQgdG9waWMuIEZy ZWQncyBkcmFmdCBzZWVtcyB0byBiZSBtb3N0bHkgdGhlcmUsDQogYWx0aG91Z2ggbXVsdGljYXN0 L01MRCBuZWVkcyB0byBiZSBjb3ZlcmVkLjxvOnA+PC9vOnA+PC9wPg0KPHA+PGEgaHJlZj0iaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGVtcGxpbi12Nm9wcy1wZGhvc3Qv Ij5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC10ZW1wbGluLXY2b3BzLXBk aG9zdC88L2E+PG86cD48L286cD48L3A+DQo8cD5GaW5hbGx5LCBhbHRob3VnaCBpdCBpbiBzb21l IHdheXMgaXMgb3V0IG9mIHNjb3BlLCBJJ2QgbmV2ZXIgd2FudCB0byBzZWUgYSBCQ1Agb2YgYW55 IGtpbmQgcHJvcG9zaW5nIHRoYXQgYWxsIG9mIFdpZmkncyBzZWN1cml0eSBtZWNoYW5pc21zIGFy ZSB0dXJuZWQgb2ZmLCBiZWNhdXNlIFdpRmkgdHJhZmZpYyBpcyBzbyBlYXN5IHRvIHBhY2tldCBj YXB0dXJlIGV2ZXJ5dGhpbmcgd2hlbiBzZWN1cml0eSBpcyBzd2l0Y2hlZCBvZmYuPG86cD48L286 cD48L3A+DQo8cD5SZWdhcmRzLDxicj4NCk1hcmsuPG86cD48L286cD48L3A+DQo8cD5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgdjZvcHMg bWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciPnY2 b3BzQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby92Nm9wcyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby92Nm9wczwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_2134F8430051B64F815C691A62D9831832F99D30XCHBLV504nwnosb_-- From nobody Tue Jan 5 15:11:16 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC7791AC432 for ; Tue, 5 Jan 2016 15:11:14 -0800 (PST) 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, 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 cHG3iIwy3SAn for ; Tue, 5 Jan 2016 15:11:12 -0800 (PST) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF1711AC425 for ; Tue, 5 Jan 2016 15:11:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u05NBC3p007270; Tue, 5 Jan 2016 16:11:12 -0700 Received: from XCH-BLV-402.nw.nos.boeing.com (xch-blv-402.nw.nos.boeing.com [130.247.25.31]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u05NB3f8007209 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Tue, 5 Jan 2016 16:11:04 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.52]) by XCH-BLV-402.nw.nos.boeing.com ([169.254.2.79]) with mapi id 14.03.0235.001; Tue, 5 Jan 2016 15:11:02 -0800 From: "Templin, Fred L" To: v6ops list Thread-Topic: I-D Action: draft-templin-v6ops-pdhost-01.txt Thread-Index: AQHRSA4YedRXrmmwEUqbIjGsI7rqY57tjFUA Date: Tue, 5 Jan 2016 23:11:02 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F9A020@XCH-BLV-504.nw.nos.boeing.com> References: <20160105230854.24894.36877.idtracker@ietfa.amsl.com> In-Reply-To: <20160105230854.24894.36877.idtracker@ietfa.amsl.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: Subject: [v6ops] FW: I-D Action: draft-templin-v6ops-pdhost-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 23:11:15 -0000 Updated from the previous version to address comments. Thanks - Fred fred.l.templin@boeing.com -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of inte= rnet-drafts@ietf.org Sent: Tuesday, January 05, 2016 3:09 PM To: i-d-announce@ietf.org Subject: I-D Action: draft-templin-v6ops-pdhost-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Delegating a Prefix to a Host for Multi-addressin= g Purposes Author : Fred L. Templin Filename : draft-templin-v6ops-pdhost-01.txt Pages : 6 Date : 2016-01-05 Abstract: IPv6 prefixes are typically delegated to requesting routers which then use them to number their downstream-attached links and networks. The requesting router then acts as a router between the downstream- attached hosts and the upstream provider network. The router could also act as a host under the weak end system model, and otherwise behaves as a standard router. This document considers the case when the "requesting router" is actually a host, and receives a prefix that it can use for multi-addressing purposes. The host does not connect any downstream-attached networks, and uses the prefix solely for its own multi-addressing purposes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-templin-v6ops-pdhost-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-templin-v6ops-pdhost-01 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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Tue Jan 5 16:25:00 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A82D1B2DAF for ; Tue, 5 Jan 2016 16:24:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, 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 atTkcJWM3mjx for ; Tue, 5 Jan 2016 16:24:58 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50F261B2DAD for ; Tue, 5 Jan 2016 16:24:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2100; q=dns/txt; s=iport; t=1452039898; x=1453249498; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=rDkvbY1KGFhdokfl+2yMAwSGqlLn9CdR0cosOSzMAGQ=; b=KTXvqg8OOZFCIikpYFZ9TU0Bd597/L/wHIXWZPW3s2Nkic+FL/Ew11we fOw3OzobGkFvx4SrUl5jFmlNU8aIoyr3ZKO1ljgCKJDHg05De+L4B9hZl Lzoyi8YxOXSDKKe/OXUAepyHDGDM2vKco+hExbixpONpR6Eb1P9t5AQjE I=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DFAgACXoxW/4sNJK1egzqBPwaIU7NoD?= =?us-ascii?q?oFkhg8CgSA4FAEBAQEBAQGBCoQ0AQEBAwF5BQsCAQgYLjIlAgQOBQ6IGQjCOgE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBAQ8JiGWCcIghgRsFlwgBgnKBZYh7jnmOQAEgA?= =?us-ascii?q?UOCDIF+cgGEWIEIAQEB?= X-IronPort-AV: E=Sophos;i="5.20,526,1444694400"; d="asc'?scan'208";a="224517530" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Jan 2016 00:24:57 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u060OvwD020115 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Jan 2016 00:24:57 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 5 Jan 2016 18:24:56 -0600 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1104.009; Tue, 5 Jan 2016 18:24:56 -0600 From: "Fred Baker (fred)" To: Fred Templin Thread-Topic: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host Thread-Index: AQHRSBirRO+Tiu5b1E6F3aUR0bRoTQ== Date: Wed, 6 Jan 2016 00:24:56 +0000 Message-ID: <6065AA2A-25BB-4B32-B88B-40A856D0E1EA@cisco.com> References: <201601031900.u03J0LMe009763@irp-lnx1.cisco.com> <2134F8430051B64F815C691A62D9831832F988DB@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F99D14@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832F99D14@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3112) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.123.81] Content-Type: multipart/signed; boundary="Apple-Mail=_F7DE9C5F-55AD-4444-B7EA-D62233BB48E5"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" , John Brzozowski Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 00:24:59 -0000 --Apple-Mail=_F7DE9C5F-55AD-4444-B7EA-D62233BB48E5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jan 5, 2016, at 10:50 AM, Templin, Fred L = wrote: >=20 >> respect the fact that AERO has been around for some time, however, it = does >> not appear to be widely deployed. >=20 > That is irrelevant. I'm sorry, no, it is relevant. We're not talking about IPv5, IPv7, TUBA, = RFC 3053, RFC 5572, ISATAP (which one actually can describe as widely = deployed or having once been widely deployed) or quite a long list of = other technologies. In a draft whose primary purpose (BCP) is to ask network administrators = to not restrict hosts or host interfaces to a single address, discussing = a technology that might or might not have promise but is not widely = received as a common current practice is at best irrelevant. --Apple-Mail=_F7DE9C5F-55AD-4444-B7EA-D62233BB48E5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBVoxe1kayAOS/EQ8MAQI/rw/9FFBWPKczsw9oTpvViGF41tKdmKCl3cHx gRsFkis3whgMHOIfB90atL/E9MWqOfJ3DosoJR5lgwU1Qk3wrn9L2sXMGL0oeJmt kRHsgbAq5IS8Zmi9agiAxzCi5orQmj7JNZmjJ/UEOBrur2pO5Au5FEmsnrjOmOwi p+D+l6idFcGqQVTbojrT09d2znLw9ESKlxLmdHZ2sol82wCto2ZMzXi9xBAvIDdR Uh7wRUVTyV9Nvl9yUpQF4dqMXLOe7lbZFy+a3L4+ZzH10ng6yTbZbscPzjrJ5huc COnAdEMAy0IbwK1lWc4rgeaZ3rtB2x79A80d4vYMtzmz3Ovwm1JR6fcr0cKz79UJ VeiBs34sPbFYpy/LyX90Pb8x2D2d2AzsQUFew+8WGgmumrgAhcSfw7VCWHYTXSTN BEL9wpqPKW3VGimKBjJIIboYBGo/Czs3v3Hgp3OikuC/yQySwD00aNDUpimdeQa8 hltvUXAf0wlyxulnuPg7fLSdRFmdZsS/qFJogWGRRASj8KX0Mt1hDSLg93LV8SSY 6Pc11kqtLrzD4jQwVKs5pM5YJoCMQqLl0sXQGI+gOcPOZ62eWUXW2jLakMrgXytj 6ld2hTxKZX8DuaaZNYjPE3BBftjjSsHsqBd4mRRz/wwljvBIfUe/RSAzRokAF7Ed 75lnGFz7S/I= =wbqi -----END PGP SIGNATURE----- --Apple-Mail=_F7DE9C5F-55AD-4444-B7EA-D62233BB48E5-- From nobody Tue Jan 5 16:35:36 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D7F1B2DBC for ; Tue, 5 Jan 2016 16:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 T8LWSkfCy24X for ; Tue, 5 Jan 2016 16:35:33 -0800 (PST) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE1661B2DBA for ; Tue, 5 Jan 2016 16:35:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u060Zc3a030504; Tue, 5 Jan 2016 16:35:38 -0800 Received: from XCH-PHX-409.sw.nos.boeing.com (xch-phx-409.sw.nos.boeing.com [10.57.37.40]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u060ZYKJ030493 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 5 Jan 2016 16:35:34 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.52]) by XCH-PHX-409.sw.nos.boeing.com ([169.254.9.172]) with mapi id 14.03.0235.001; Tue, 5 Jan 2016 16:35:28 -0800 From: "Templin, Fred L" To: "Fred Baker (fred)" Thread-Topic: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host Thread-Index: AQHRR+nwI13RUsgT4kOKL/Th7Sw3uJ7uJ54A//962WA= Date: Wed, 6 Jan 2016 00:35:27 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F9A0EA@XCH-BLV-504.nw.nos.boeing.com> References: <201601031900.u03J0LMe009763@irp-lnx1.cisco.com> <2134F8430051B64F815C691A62D9831832F988DB@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F99D14@XCH-BLV-504.nw.nos.boeing.com> <6065AA2A-25BB-4B32-B88B-40A856D0E1EA@cisco.com> In-Reply-To: <6065AA2A-25BB-4B32-B88B-40A856D0E1EA@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: Cc: "v6ops@ietf.org" , John Brzozowski Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 00:35:35 -0000 Hi Fred, > -----Original Message----- > From: Fred Baker (fred) [mailto:fred@cisco.com] > Sent: Tuesday, January 05, 2016 4:25 PM > To: Templin, Fred L > Cc: John Brzozowski; v6ops@ietf.org > Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-pre= fix-per-host >=20 >=20 > > On Jan 5, 2016, at 10:50 AM, Templin, Fred L wrote: > > > >> respect the fact that AERO has been around for some time, however, it = does > >> not appear to be widely deployed. > > > > That is irrelevant. >=20 > I'm sorry, no, it is relevant. We're not talking about IPv5, IPv7, TUBA, = RFC 3053, RFC 5572, ISATAP (which one actually can describe as > widely deployed or having once been widely deployed) or quite a long list= of other technologies. To be fair, AERO is about IPv6 and DHCPv6 Prefix Delegation - not some weird new IP protocol version. Likening it to IPv5, IPv7, TUBA, etc. is therefore inappropriate. Thanks - Fred fred.l.templin@boeing.com > In a draft whose primary purpose (BCP) is to ask network administrators t= o not restrict hosts or host interfaces to a single address, > discussing a technology that might or might not have promise but is not w= idely received as a common current practice is at best > irrelevant. From nobody Tue Jan 5 16:40:09 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 249441A0191 for ; Tue, 5 Jan 2016 16:40:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 gWWhHnFtk1AD for ; Tue, 5 Jan 2016 16:40:05 -0800 (PST) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.119.220]) by ietfa.amsl.com (Postfix) with ESMTP id A1BB51A0180 for ; Tue, 5 Jan 2016 16:40:05 -0800 (PST) Received: from mail-io0-f173.google.com (mail-io0-f173.google.com [209.85.223.173]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128/128); for ; Tue, 5 Jan 2016 18:40:00 -0600 (CST) X-Umn-Remote-Mta: [N] mail-io0-f173.google.com [209.85.223.173] #+LO+TS+TR X-Umn-Classification: local Received: by mail-io0-f173.google.com with SMTP id g73so4765272ioe.3 for ; Tue, 05 Jan 2016 16:40:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=reply-to:subject:references:to:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=rheg+WG7pYVt7ACl1KRwUc4lWTH2w9bLiIPtsinFZRo=; b=ad7+WZhGSvZxFvZ+PcuRlPwnvUnj3UpP1+L+LbZ9nyS9tlauGBKbqAA2dx7IwIkUx4 09nWk6VYqH3P6QSzvFF8TDwbIjf/3oxmJFehqQ+02UTBZ1v8qOaRppTax5AJsKNXSklc JefOIDmU9mg8njn7ud34cZlIQn2+1CZlzVLC0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:cc:from :organization:message-id:date:user-agent:mime-version:in-reply-to :content-type:content-transfer-encoding; bh=rheg+WG7pYVt7ACl1KRwUc4lWTH2w9bLiIPtsinFZRo=; b=Xcf3+lrWK5lNVy7Jxf+ySbDDIN2SyXGka+JP10OhWWCvWcjqI9e/Vgs7g6LFdDasyP fKiapxo5ObdoUbx2CkZsK/j7PxMlEAzWEx0C+KamL1DBgjhRURAZNBt1m7h+qOBT9VWu tnnvV+brjL0MCXMH1zWuoclGSobrEBQKx2RuibrUOCZamH0mIyE+wopQGg+wMtDrA5+y BpGJZkcEzGHx0rC4MkHRZAwD/AVZqh1QHvvGqM+T7fZRyeIbvPeSWpEm/eakB23QJJtB dQ3S+qHXQDqk5x2BhipD80vQB2BaQNvDZTIhceGOR2oAtISPdRrbssZtF2n3k8wwTrLg Gx8A== X-Gm-Message-State: ALoCoQnmd7m6cpsqfXgZseOLLNdvHD7XMQlZKcyZelclUVM0dq/UIUurwJnds6PV+XPkJE7AlfzcfWE5F3mX+s+DMbeDwVz9iymRH71SCReb01B/fjaFzeyn+8murdEETYscdzgE7Md2YqGCYGXVfjQ7byzlBFO/fA== X-Received: by 10.107.34.16 with SMTP id i16mr84983109ioi.22.1452040799560; Tue, 05 Jan 2016 16:39:59 -0800 (PST) X-Received: by 10.107.34.16 with SMTP id i16mr84983098ioi.22.1452040799411; Tue, 05 Jan 2016 16:39:59 -0800 (PST) Received: from x-10-104-129-194.uofm-secure.wireless.umn.edu ([2607:ea00:107:2001:18c0:8aaa:160a:f962]) by smtp.gmail.com with ESMTPSA id l10sm2018326igx.18.2016.01.05.16.39.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Jan 2016 16:39:57 -0800 (PST) References: <201601031900.u03J0LMe009763@irp-lnx1.cisco.com> <2134F8430051B64F815C691A62D9831832F988DB@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F99D14@XCH-BLV-504.nw.nos.boeing.com> <6065AA2A-25BB-4B32-B88B-40A856D0E1EA@cisco.com> <2134F8430051B64F815C691A62D9831832F9A0EA@XCH-BLV-504.nw.nos.boeing.com> To: "Templin, Fred L" , "Fred Baker (fred)" From: David Farmer Organization: University of Minnesota Message-ID: <568C625A.80808@umn.edu> Date: Tue, 5 Jan 2016 18:39:54 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <2134F8430051B64F815C691A62D9831832F9A0EA@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" , John Brzozowski Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 00:40:07 -0000 On 1/5/16 18:35 , Templin, Fred L wrote: > Hi Fred, > >> -----Original Message----- >> From: Fred Baker (fred) [mailto:fred@cisco.com] >> Sent: Tuesday, January 05, 2016 4:25 PM >> To: Templin, Fred L >> Cc: John Brzozowski; v6ops@ietf.org >> Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host >> >> >>> On Jan 5, 2016, at 10:50 AM, Templin, Fred L wrote: >>> >>>> respect the fact that AERO has been around for some time, however, it does >>>> not appear to be widely deployed. >>> >>> That is irrelevant. >> >> I'm sorry, no, it is relevant. We're not talking about IPv5, IPv7, TUBA, RFC 3053, RFC 5572, ISATAP (which one actually can describe as >> widely deployed or having once been widely deployed) or quite a long list of other technologies. > > To be fair, AERO is about IPv6 and DHCPv6 Prefix Delegation - not some > weird new IP protocol version. Likening it to IPv5, IPv7, TUBA, etc. is > therefore inappropriate. Doesn't it also include automatic tunneling, and require end client software to support it? > Thanks - Fred > fred.l.templin@boeing.com > >> In a draft whose primary purpose (BCP) is to ask network administrators to not restrict hosts or host interfaces to a single address, >> discussing a technology that might or might not have promise but is not widely received as a common current practice is at best >> irrelevant. What? wait a sec, isn't that draft-ietf-v6ops-host-addr-availability. This is draft-ietf-v6ops-unique-ipv6-prefix-per-host, and is something different, its related, but most definitely different. In my view AERO and this draft are working in slightly overlapping, but different solution spaces. -- -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nobody Tue Jan 5 16:40:41 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C39591A020D for ; Tue, 5 Jan 2016 16:40:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 MOhpxrev1mG1 for ; Tue, 5 Jan 2016 16:40:38 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE7A51A01F4 for ; Tue, 5 Jan 2016 16:40:38 -0800 (PST) Received: from mb-2.local ([IPv6:2601:647:4204:51:9d99:245c:874e:583a]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id u060eVDH026877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 6 Jan 2016 00:40:32 GMT (envelope-from joelja@bogus.com) To: "Fred Baker (fred)" , Fred Templin References: <201601031900.u03J0LMe009763@irp-lnx1.cisco.com> <2134F8430051B64F815C691A62D9831832F988DB@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F99D14@XCH-BLV-504.nw.nos.boeing.com> <6065AA2A-25BB-4B32-B88B-40A856D0E1EA@cisco.com> From: joel jaeggli Message-ID: <568C627F.90801@bogus.com> Date: Tue, 5 Jan 2016 16:40:31 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:43.0) Gecko/20100101 Thunderbird/43.0 MIME-Version: 1.0 In-Reply-To: <6065AA2A-25BB-4B32-B88B-40A856D0E1EA@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Wxght7k9G2TeTjWlB762efp2AelkDVMMs" Archived-At: Cc: "v6ops@ietf.org" , John Brzozowski Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 00:40:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Wxght7k9G2TeTjWlB762efp2AelkDVMMs Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 1/5/16 4:24 PM, Fred Baker (fred) wrote: > > In a draft whose primary purpose (BCP) is to ask network > administrators to not restrict hosts or host interfaces to a single > address, discussing a technology that might or might not have promise > but is not widely received as a common current practice is at best > irrelevant. I tend to concur, if you're going to provide advice to an operator audience that strikes at current practice, relevance involves present usage. joel >=20 >=20 > _______________________________________________ v6ops mailing list=20 > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >=20 --Wxght7k9G2TeTjWlB762efp2AelkDVMMs Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlaMYn8ACgkQ8AA1q7Z/VrIMcgCfa2xN/2aPfv99BSSnbbrv4yVt X0MAn31D+uJkmWFrYtLBmHNdSJTLwH/s =aiIg -----END PGP SIGNATURE----- --Wxght7k9G2TeTjWlB762efp2AelkDVMMs-- From nobody Tue Jan 5 16:47:09 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4461A024E for ; Tue, 5 Jan 2016 16:47:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 1oFhDsqzqWxh for ; Tue, 5 Jan 2016 16:47:06 -0800 (PST) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBB941A024C for ; Tue, 5 Jan 2016 16:47:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u060lBNS016972; Tue, 5 Jan 2016 16:47:11 -0800 Received: from XCH-BLV-108.nw.nos.boeing.com (xch-blv-108.nw.nos.boeing.com [130.247.25.137]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u060l24d016940 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 5 Jan 2016 16:47:02 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.52]) by XCH-BLV-108.nw.nos.boeing.com ([169.254.13.112]) with mapi id 14.03.0235.001; Tue, 5 Jan 2016 16:46:57 -0800 From: "Templin, Fred L" To: David Farmer , "Fred Baker (fred)" Thread-Topic: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host Thread-Index: AQHRR+nwI13RUsgT4kOKL/Th7Sw3uJ7uJ54A//962WCAAIlWAP//enSg Date: Wed, 6 Jan 2016 00:46:56 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F9A12C@XCH-BLV-504.nw.nos.boeing.com> References: <201601031900.u03J0LMe009763@irp-lnx1.cisco.com> <2134F8430051B64F815C691A62D9831832F988DB@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F99D14@XCH-BLV-504.nw.nos.boeing.com> <6065AA2A-25BB-4B32-B88B-40A856D0E1EA@cisco.com> <2134F8430051B64F815C691A62D9831832F9A0EA@XCH-BLV-504.nw.nos.boeing.com> <568C625A.80808@umn.edu> In-Reply-To: <568C625A.80808@umn.edu> 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: Cc: "v6ops@ietf.org" , John Brzozowski Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 00:47:08 -0000 Hi David, > -----Original Message----- > From: David Farmer [mailto:farmer@umn.edu] > Sent: Tuesday, January 05, 2016 4:40 PM > To: Templin, Fred L; Fred Baker (fred) > Cc: David Farmer; v6ops@ietf.org; John Brzozowski > Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-pre= fix-per-host >=20 > On 1/5/16 18:35 , Templin, Fred L wrote: > > Hi Fred, > > > >> -----Original Message----- > >> From: Fred Baker (fred) [mailto:fred@cisco.com] > >> Sent: Tuesday, January 05, 2016 4:25 PM > >> To: Templin, Fred L > >> Cc: John Brzozowski; v6ops@ietf.org > >> Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-= prefix-per-host > >> > >> > >>> On Jan 5, 2016, at 10:50 AM, Templin, Fred L wrote: > >>> > >>>> respect the fact that AERO has been around for some time, however, i= t does > >>>> not appear to be widely deployed. > >>> > >>> That is irrelevant. > >> > >> I'm sorry, no, it is relevant. We're not talking about IPv5, IPv7, TUB= A, RFC 3053, RFC 5572, ISATAP (which one actually can describe > as > >> widely deployed or having once been widely deployed) or quite a long l= ist of other technologies. > > > > To be fair, AERO is about IPv6 and DHCPv6 Prefix Delegation - not some > > weird new IP protocol version. Likening it to IPv5, IPv7, TUBA, etc. is > > therefore inappropriate. >=20 > Doesn't it also include automatic tunneling, and require end client > software to support it? AERO is typically used with automatic tunneling, but the functions can also= be applied to native multi-access links with no tunneling. Yes, client software is use= d for managing prefix delegation server associations, for mobility management, etc. But, s= tandard DHCPv6 PD also requires client-side software, so I'm not sure I see a probl= em? > > Thanks - Fred > > fred.l.templin@boeing.com > > > >> In a draft whose primary purpose (BCP) is to ask network administrator= s to not restrict hosts or host interfaces to a single address, > >> discussing a technology that might or might not have promise but is no= t widely received as a common current practice is at best > >> irrelevant. >=20 > What? wait a sec, isn't that draft-ietf-v6ops-host-addr-availability. >=20 > This is draft-ietf-v6ops-unique-ipv6-prefix-per-host, and is something > different, its related, but most definitely different. >=20 > In my view AERO and this draft are working in slightly overlapping, but > different solution spaces. We don't know that without a use case analysis. Thanks - Fred fred.l.templin@boeing.com > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > David Farmer Email: farmer@umn.edu > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 1-612-626-0815 > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From nobody Tue Jan 5 17:28:15 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52F631A88E8 for ; Tue, 5 Jan 2016 17:28:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 ruAJTpa1bJN2 for ; Tue, 5 Jan 2016 17:28:10 -0800 (PST) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.119.120]) by ietfa.amsl.com (Postfix) with ESMTP id C57761A88DF for ; Tue, 5 Jan 2016 17:28:10 -0800 (PST) Received: from mail-io0-f170.google.com (mail-io0-f170.google.com [209.85.223.170]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128/128); for ; Tue, 5 Jan 2016 19:28:07 -0600 (CST) X-Umn-Remote-Mta: [N] mail-io0-f170.google.com [209.85.223.170] #+LO+TS+TR X-Umn-Classification: local Received: by mail-io0-f170.google.com with SMTP id 77so173893494ioc.2 for ; Tue, 05 Jan 2016 17:28:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=reply-to:subject:references:to:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=9fXXhJH27DcDiLg0+2jOJ18U+I/L4Y4PALfjkff4C9Q=; b=qILcw21sZPm9uA25RNfVd+CHqCt2M5aQ+cwwfi+CXZq/gqF4rKoUTu+FmDgrleTEZA 24qN3exgvqfqmMcwRK2cBq/J51QGI3gHElwQPrB9tic646XYqxmizsb6VEw+mkaMMWF3 n6ZP+Euam4VJXEy1Vw/G8TK0W2FIJM4uVA6W4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:cc:from :organization:message-id:date:user-agent:mime-version:in-reply-to :content-type:content-transfer-encoding; bh=9fXXhJH27DcDiLg0+2jOJ18U+I/L4Y4PALfjkff4C9Q=; b=aZjhv1Rff7bEHb7tKOqvgAlbXctgjfzrO+25tMUK62d+A+J0T6UmfRJR6PNOQ3L1dK HwoLVgTSzQmczxwsts+qz7jwO6jC2ZoZryKFBgvbjS6fQt0Z/Eqj+Uey3VEpbmTH2391 JKutd54FIjG7jg0x18DEndJ4QNfOhnr6JOWRCrHlDhp67U80LsBHuaqP24+zLO1mSotE RfoEFlpbI6Ui3J0jXWNEG+i7e5qszuOs4w44jxkT3xIgWHJoLISE7h+8Lm4kGuhyS1MF 4uFE0s4TzUkUd/AK1kkZ+m8XA0dbq409VkUGImKt7fZ4Z0rMFW9CIPXgL8E7JuRVuQl1 grfA== X-Gm-Message-State: ALoCoQnYO6Y8VZF0WAdDMEKmcMbA36tE7QWQPzPtBkjqLvqGWjuruaqTVrUv9wWDeT2MBLaIY/Ip9d1QC/W4GGgBybgcXfA6LF9hFEfSM0asuEdsn+0mnKmlJ7IqvP2B6kSWxlOh098wKSQAqTPtVWdfk4rMBJVUcw== X-Received: by 10.107.167.18 with SMTP id q18mr83650034ioe.141.1452043686705; Tue, 05 Jan 2016 17:28:06 -0800 (PST) X-Received: by 10.107.167.18 with SMTP id q18mr83650012ioe.141.1452043686543; Tue, 05 Jan 2016 17:28:06 -0800 (PST) Received: from x-10-104-129-194.uofm-secure.wireless.umn.edu ([2607:ea00:107:2001:18c0:8aaa:160a:f962]) by smtp.gmail.com with ESMTPSA id h187sm34659473ioh.4.2016.01.05.17.28.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Jan 2016 17:28:05 -0800 (PST) References: <201601031900.u03J0LMe009763@irp-lnx1.cisco.com> <2134F8430051B64F815C691A62D9831832F988DB@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F99D14@XCH-BLV-504.nw.nos.boeing.com> <6065AA2A-25BB-4B32-B88B-40A856D0E1EA@cisco.com> <2134F8430051B64F815C691A62D9831832F9A0EA@XCH-BLV-504.nw.nos.boeing.com> <568C625A.80808@umn.edu> <2134F8430051B64F815C691A62D9831832F9A12C@XCH-BLV-504.nw.nos.boeing.com> To: "Templin, Fred L" , "Fred Baker (fred)" From: David Farmer Organization: University of Minnesota Message-ID: <568C6DA3.5010102@umn.edu> Date: Tue, 5 Jan 2016 19:28:03 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <2134F8430051B64F815C691A62D9831832F9A12C@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" , John Brzozowski Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 01:28:13 -0000 On 1/5/16 18:46 , Templin, Fred L wrote: > Hi David, > >> -----Original Message----- >> From: David Farmer [mailto:farmer@umn.edu] ... >> In my view AERO and this draft are working in slightly overlapping, but >> different solution spaces. > > We don't know that without a use case analysis. Well as I read this, this doesn't implement DHCPv6 PD. Furthermore, it doesn't need any client software. It uses SLAAC and responds to each IPv6 ND Router Solicitation with a unicast Router Advertisement with different prefix for each client. It provides DNS server info with RADNS and stateless DHCPv6 if the client send a request. The client requirement are just standard SLAAC, and RADNS or stateless DHCPv6, that is it. No DHCPv6 PD client needed, am I missing something? There is a bunch of WiFi parts too, just like AERO has tunnel stuff, but that is fairly standard WiFi infrastructure bits. So, there is a really quick use case analysis for you and I'll reiterate; in my view AERO and this draft are working in slightly overlapping, but different solution spaces. Thanks. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nobody Tue Jan 5 17:42:12 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B52C01A8909 for ; Tue, 5 Jan 2016 17:42:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 I3-OUhheI8Zh for ; Tue, 5 Jan 2016 17:42:10 -0800 (PST) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6280B1A8908 for ; Tue, 5 Jan 2016 17:42:10 -0800 (PST) Received: by mail-yk0-x22d.google.com with SMTP id v14so208300307ykd.3 for ; Tue, 05 Jan 2016 17:42:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=mbkgnQHPi/pFqVUoqxszEMzvHihPfgd17kvJ6HO4tfw=; b=o5QzQLlzaolTiv2oOWQnrp/opyIEO/m3MpCY0YaLhTqB/9xYdWqpnLr7X+kFETgfup LMT/2mCFvLi79MBRFtVnMQSEu07P+YVzdXF66s2mtBUT7S0uFC5c527RegB6b0dSXGs1 99nUPutavAnG0yuDSp/mTo4aMZOUX9RsWXhyv+xfhts9ajHZN5LUCsV5yObSUJOogQH0 lvpo6CBtmzfp7x5R7L8wrpvfEUi5oYVrTca2JvA82OPJhiApgYV0V7WCc5GRZ9JKUcjV 77IBCES8xtVWL2rHRgoiJQLdhi94Qi1dKh0XBIlmXu+hkUzfGluOICHQQ6Kv1RRrWlbm FNpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=mbkgnQHPi/pFqVUoqxszEMzvHihPfgd17kvJ6HO4tfw=; b=CCxe6fUG5SH7woD76UUSATgwsgiE2GtfA3z1L2GK7+60KsFYbPXQhAffsS/hnBj8HX dltNmMskAE0Cm39dZP1M6piTwCK0lVGwMvBcUEruC/FNIWAowrZG5AiHQsYvVR6DemOf CqMYmeJGm6jKmh4uy9r31LvS3/UhRn7OGuaY/ypv4K5K0XhdwCmRye5MTIMm993A9u9y RsnDHW19EtcQXyRcqaw306iIHBNSuQG+reMXW59Nhgs7/tSXcPGib6U0lOx5VVx6eEBv m/+S/JTD0Jt4/3ww/VLfLLhwqqOt/oSJYgFRw6uvdTgRkMKWBBIgpGmCe4az+S8uz/gn LyBg== X-Gm-Message-State: ALoCoQlMVPrQ+DdYXoGLeOwdWg51WfzuwXw2y5hjSsxRGj29UPmFBjKL/oxmwbsYOV7R2pZYU+4HU1jyRED/74Z/2mSb/dXW48Z7w5KEmdOSF6sGuF6luT0= X-Received: by 10.129.41.17 with SMTP id p17mr69334083ywp.160.1452044529517; Tue, 05 Jan 2016 17:42:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.208.201 with HTTP; Tue, 5 Jan 2016 17:41:49 -0800 (PST) In-Reply-To: <2134F8430051B64F815C691A62D9831832F99CEE@XCH-BLV-504.nw.nos.boeing.com> References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F99CEE@XCH-BLV-504.nw.nos.boeing.com> From: Lorenzo Colitti Date: Wed, 6 Jan 2016 10:41:49 +0900 Message-ID: To: "Templin, Fred L" Content-Type: multipart/alternative; boundary=001a11407ee861cb8e0528a0767e Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 01:42:11 -0000 --001a11407ee861cb8e0528a0767e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jan 6, 2016 at 3:43 AM, Templin, Fred L wrote: > FLT>>> The citation would be to =E2=80=9Cdraft-templin-aerolink=E2=80=9D = which is being > proposed as standards-track. > FLT>>> There are plenty of examples of informative citations of works in > progress in published RFCs. > Fair enough, but my earlier concerns (also expressed by David Farmer, IIRC) still stand. > =E2=80=A2 As a host implementer, I would much rather implement DHCPv6 PD = without > AERO than with AERO. It's much simpler on the client side, and it has no > network-side dependencies, so it seems more likely to be deployable. This > is my opinion, and I doubt that I will easily be convinced otherwise. > > FLT>>> That is incorrect. My AERO DHCPv6 client code is much simpler than= , > e.g., the ISC dhclient > FLT>>> code that does not do AERO. Have a look at my code. > I stand by my statement. I don't see how you can argue that implementing DHCPv6 PD plus AERO is simpler than implementing DHCPv6 PD by itself. The fact that your code is simpler than the ISC client doesn't prove that AERO is simpler to implement, it only proves that ISC wrote more complicated code than you did. That said: the IETF process is based on rough consensus. From what I've > seen so far, you are the only WG participant arguing for a reference to > AERO in this document, but if somehow rough consensus emerges that this i= s > the right thing to do (and it emerges quickly; bear in mind that we're we= ll > past the end of the supplemental post-WGLC comment period that Fred > declared a few weeks ago), then we can re-evaluate. > > FLT>>> It seems like there is still emerging consensus on this. It's not my role to declare consensus, but that is very far from my read of the situation. --001a11407ee861cb8e0528a0767e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jan 6, 2016 at 3:43 AM, Templin, Fred L <Fred.L.Templin@boei= ng.com> wrote:
FLT>>> The citation would be to =E2=80=9Cdraft-templin-aero= link=E2=80=9D which is being proposed as standards-track.
FLT>>> There are plenty of examples of informative citations of wo= rks in progress in published RFCs.

Fair= enough, but my earlier concerns (also expressed by David Farmer, IIRC) sti= ll stand.
=C2=A0
=E2=80=A2 As a host implem= enter, I would much rather implement DHCPv6 PD without AERO than with AERO.= It's much simpler on the client side, and it has no network-side depen= dencies, so it seems more likely to be deployable. This is my opinion, and = I doubt that I will easily be convinced otherwise.

FLT>>> That is incorrect. My AERO DHCPv6 client code is much simpl= er than, e.g., the ISC dhclient
FLT>>> code that does not do AERO. Have a look at my code.

I stand by my statement. I don't see how y= ou can argue that implementing DHCPv6 PD plus AERO is simpler than implemen= ting DHCPv6 PD by itself. The fact that your code is simpler than the ISC c= lient doesn't prove that AERO is simpler to implement, it only proves t= hat ISC wrote more complicated code than you did.

That said: the IETF process is based on rough = consensus. From what I've seen so far, you are the only WG participant = arguing for a reference to AERO in this document, but if somehow rough cons= ensus emerges that this is the right thing to do (and it emerges quickly; b= ear in mind that we're well past the end of the supplemental post-WGLC = comment period that Fred declared a few weeks ago), then we can re-evaluate= .

FLT>>> It seems like there is still emerging consensus on t= his.

It's not my role to declare consen= sus, but that is very far from my read of the situation.
<= /div> --001a11407ee861cb8e0528a0767e-- From nobody Tue Jan 5 19:16:56 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 679641A8A87 for ; Tue, 5 Jan 2016 19:16:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 U7M5cBuDlQZD for ; Tue, 5 Jan 2016 19:16:53 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 385D41A8A80 for ; Tue, 5 Jan 2016 19:16:53 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id b14so57126367wmb.1 for ; Tue, 05 Jan 2016 19:16:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=LqWcDDYNnOScPRDqL7czWUynwDkZncRSJnCKZPaV2gU=; b=FgDPUlm7Ax/D9McDu1bh0Lq0SjxxwqUF6rho/vo32XPHWALlOSb/xAJ4sxP54KBW7D Q6/4n1GT7CVjcAQY8cu0YuZJbGf/e+uAYURMQySwxBi1d1WJXMQeo//OOoBEOtT8Laq2 C2WzwS4R2+AcWV0MEIy8H+4dmUNQjv3qtoNFYMoQ2PW3FflfyG9WSOIzAfGM7jDiDDYh MXt/uclPuVo09YLvXxBznam+Ufd+EPNeXnbQ/p26wAY3fFvie81YjKAmmW9/zEI1WtdH PktK45yZzkgGtemLbFvCvrj2d/famKLru+zcT1Q5rRzAnx6OJSMGdMXZzM+4uABMiG2G /Hgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=LqWcDDYNnOScPRDqL7czWUynwDkZncRSJnCKZPaV2gU=; b=bIbwK3umuksKZZjAPlMeSPP4SOPzbJw4k95OxI8kOECYqrSvQ6Tbpu1q2CHH9Zae/z cYuKNIGm1LBLtNUftnC5xSylDnDiavbQT7KSOhxKVf/wvOzERQ5qlZrPo5mOrx+iYYRc TrFzmOoY8/jSbB/uUUoMM9+Zq9q/xlk8M3xGCutRNuIwOyvJIImXm0m9NV09WQ9B3QaI /jG3ysmwYsRjERrvXgc/tBBaF1f1pA9lqir0oJKQWySYAX0SwFQIhxKh4WrKHv5q7OTD uPcuXlpQfHAGsMz/MU7OhrsM43NLUeSpJnzk8QZvG7cluu+6Sq3dBNfSd3m80gn50d5R lwbg== X-Gm-Message-State: ALoCoQmPAGL5ftSGTmN5pqWhVQlNPjVfkwboH0YKROt2xYB6u0nWEhog5FxEunD+s7NW6/ntYIml7pADwtFlf/mqfduvJ4xiwejuYeW7kBfF017vK3n9rhE= X-Received: by 10.28.177.10 with SMTP id a10mr7204379wmf.4.1452050211678; Tue, 05 Jan 2016 19:16:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.154.148 with HTTP; Tue, 5 Jan 2016 19:16:31 -0800 (PST) In-Reply-To: References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> From: Erik Kline Date: Wed, 6 Jan 2016 12:16:31 +0900 Message-ID: To: Philip Homburg Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 03:16:54 -0000 > So in short, there simply is no real practice when it comes to a large part > of this document. Which also why Fred can bring up AERO, because there > may even be more actual hosts (rather than CPEs) doing AERO than hosts > requesting DHCPv6-PD through other means. I think your assertion is false. - The bulk of the document is concerned with important Internet architectural points. - There is obviously considerable experience with SLAAC, a ton of experience with a unique IPv6 prefix per host on 3GPP, and we have a document about unique IPv6 prefix per host on wifi in the queue. - There are (literally) only a handful of references to PD, which seems to be your laser focus here. > And we also have to curious word play where a host that uses a prefix > obtained through DHCPv6-PD has to be a router from the point of view of ND, and > is actually a router in one of the use cases (tethering). And will be a router > in many implementations (AREO seems an exception in assigning adresses to > the upstream interface), but we insist in calling it a host. > > So, publish as informational. Actually get some experience deploying > exactly what is proposed here. And then write a BCP on what is actually > deployed and how that works. I think instead we can publish this as is, and in future v6ops can look at a document describing host PD implementation and network operations experience, if such a document even proves necessary (which I doubt). I don't see any issue here. From nobody Wed Jan 6 04:59:02 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77B6C1B2B48 for ; Wed, 6 Jan 2016 04:59:00 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc" X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7] 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 a8r7405FBGmW for ; Wed, 6 Jan 2016 04:58:58 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 8C24D1B2B47 for ; Wed, 6 Jan 2016 04:58:53 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1aGnfr-0000GGC; Wed, 6 Jan 2016 13:58:47 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> In-reply-to: Your message of "Wed, 6 Jan 2016 00:21:17 +0900 ." Date: Wed, 06 Jan 2016 13:58:42 +0100 Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 12:59:00 -0000 >> - there are essentially no hosts requesting DHCPv6-PD >> (I wonder if there are any hosts requesting multiple addresses using >> DHCPv6 IA_NA). >> - we know that in the CPE world there are at least two different >> approaches of >> doing DHCPv6-PD which does affect how the network provides those >> addresses. (And also affects client implementations) >> >> So in short, there simply is no real practice when it comes to a large part >> of this document. >> > >But it's not a "large part of the document" at all. It's not even a large >part of the requirements section. I think what you are disagreeing with is >only one of the recommendations, which is "if your network will only allow >hosts to connect if they do DHCPv6, then don't hand out an addres via >IA_NA, but hand out a prefix via DHCPv6 PD". We discussed this before. I suggested getting rid of all technical detail and just leave the part that hosts should get multiple addresses. You felt that we have to say something on how how it should be done. So, if the technical details are required then in my opinion we also need to have experience with them. And for general hosts we don't have that for PD. And there are even two different way in which the network can provide PD which impacts hosts as well. So, get rid of the technical details or wait until we have experience with the listed mechanisms. >And we also have to curious word play where a host that uses a prefix >> obtained through DHCPv6-PD has to be a router from the point of view of ND, > > >No, that's not true. A router is "a node that forwards packets not >explicitly addressed to itself" [RFC2460]. A host that uses a prefix >obtained using DHCPv6 PD does not need to do that. If you run a VM on a host and create a virtual ethernet to connect to the VM, then from a networking point of view the host is a router. There may not be any physical wire, but it behaves very much like a router. For the most part a delegated prefix behaves as if it is assigned to a router even if in some cases it may technically be a host. >Looks like you're assuming that a node needs to be a router in order to >send a packet on one interface with a source address assigned to another >interface. That's not true at all. In fact, to give you an idea on how this >works I just ran a DHCPv6 PD client on my linux laptop to get a prefix from >my home router, picked an address out of the prefix, assigned it to lo, and >used it: > > 1. dhclient -d -6 -D LL -P eth0 # Run PD and note the prefix you get. > I got 2400:2410:20c0:4450::/60 > 2. ip -6 addr add dev lo 2400:2410:20c0:4450::1/128 # Pick an address > out of the prefix, assign to lo > 3. ping6 -I 2400:2410:20c0:4450::1 www.google.com # Use that address > to talk to the Internet via eth0 > >This all works as expected (and as predicted by the specifications). My >laptop sends the packets on eth0 because it's the interface with the >default route, both my laptop and my home router do NUD for the link-local >address of the other device, and packets flow. My laptop is most certainly >a host, and IPv6 forwarding is off. Did you look at the ND traffic? Do you expect all traffic from neighboring hosts to 2400:2410:20c0:4450::/60 to go through your router instead of instead of directly to your laptop? If you ping something other than 2400:2410:20c0:4450::1/128 does that end up in a blackhole? Or how does your laptop know to send a destination unreachable ICMP? >As for tethering - sure, a device with tethering enabled is a router. But >that's a minor point. If you were to pick only one of the two, would you >say that your phone and your laptop are "hosts" or "routers"? I think it's >appropriate to call them "hosts", even though they occasionally act as >routers. I suppose the word "node" would be more correct, but it would be >much less readable. I think we should be more clear on the 'almost be not quite router devices'. Or it will come back to bite us. Yes, a phone or a laptop routing packets is a router. And we should figure out how to best make them work as routers. Possibly in a home context, they should just join the homenet routers to create a single coherent view of what is out there. Possibly, the same applies to big wifi networks where hosts roam while providing tethering services. >DHCPv6 PD is cited simply because if a network has decided "we will use >DHCPv6 and nothing else", then the only possible way to assign enough >addresses is to use DHCPv6 PD. But that's a tiny minority of the networks >out there, and it's only a small part of the draft. It is simple, if PD is not needed, remove it. PD causes all kinds of complexity we don't need. If it is just a tiny minority of nework, just write that it doesn't work in all cases. Solves the problem. From nobody Wed Jan 6 05:05:00 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 917DE1B2B56 for ; Wed, 6 Jan 2016 05:04:57 -0800 (PST) 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 mBduEJBWrznX for ; Wed, 6 Jan 2016 05:04:56 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo6-he.hq.phicoh.net [IPv6:2001:470:d16a:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB931B2B55 for ; Wed, 6 Jan 2016 05:04:56 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1aGnlm-0000DNC; Wed, 6 Jan 2016 14:04:54 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> In-reply-to: Your message of "Wed, 6 Jan 2016 12:16:31 +0900 ." Date: Wed, 06 Jan 2016 14:04:54 +0100 Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 13:04:57 -0000 >I think instead we can publish this as is, and in future v6ops can >look at a document describing host PD implementation and network >operations experience, if such a document even proves necessary (which >I doubt). I don't think we should write a BCP and then in a future document describe how it works. That's not what a BCP is for. If the PD part is not required for this document, then just remove it. From nobody Wed Jan 6 05:34:01 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 709521B2B57 for ; Wed, 6 Jan 2016 05:34:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 lA3Kyf4Z9qnC for ; Wed, 6 Jan 2016 05:33:58 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 721EE1ACDB8 for ; Wed, 6 Jan 2016 05:33:58 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id f206so59906868wmf.0 for ; Wed, 06 Jan 2016 05:33:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=0Q0l3C321vNgOydQxwp222BnY3lcA9pqerMX36tri7I=; b=jGSMgNKfcKq4y0UsmL+ye3H4VJ8aJ0mysBpHGXvOMvHjpGVyoOiuor+onhmFxaxp3x tjsNWi8S5Gw9ZqxwkbZEJQj5G5sawtnzRc+ZXpUdkwkEiO26BidB3HVb5zWZoYLb6MAW nTGCOhNnN0l2oKKJEOYp/G78lojgyKRAOCVofOr3zNT8jtQ8zhmBswvIGs4q1rz1hdsO v80oMXXaqdV+p1Es1hdOccYTmKcWqk7maQ/NPUsHX/yZZoH6TYrlBjX4Y22kLjv2unpX GQlKPnHNuf34RnGmkYeVa/W21OxxShBUM5P5XQuS/c8pOr0OPHzRHftJ4hY2RXwy8Uj+ ZekQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=0Q0l3C321vNgOydQxwp222BnY3lcA9pqerMX36tri7I=; b=CIOfR4jWdRJAiL3guvpUzp8mlBkADdu1WC/QUy7+vi8tgGOn+uzrFbs7KxZt1KNaAz 9mTSjHp3aKcmoqGUrrJB4LtqUu3Q5XWMGLsceOZ8GjnrD50915vZ8djzubF7HnGXyj7f bcxLQ7/I3pXWjz6anpaPi2LAsZvKy/Eeq0nUPD01pmd7yGdAMyo/Ygw7BExRd0CNw7qm GwxYggaeIs/eT52ZinpVNI9jWchB5UOfpV5S/e5CidThsgfkbovAwMpEvCnkhtwXKrtD O7USBBHN5JBRpbDW6pSDDuXQGu2aRdhywGFvf/eqGpq5USVyh4cRdBxngRUzQZv25pi7 ofeQ== X-Gm-Message-State: ALoCoQkjgn7UbTem8XIvTdBYH4q5k6xiASqRWYz8Up4/Xnmr6ch908l72ylEp2qi9pvnKGrECMPbD5pD5li0HScKjdzGA6xUQt81ShZXfw+D9i6LstdEOJs= X-Received: by 10.194.62.11 with SMTP id u11mr72872263wjr.172.1452087236962; Wed, 06 Jan 2016 05:33:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.154.148 with HTTP; Wed, 6 Jan 2016 05:33:37 -0800 (PST) In-Reply-To: References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> From: Erik Kline Date: Wed, 6 Jan 2016 22:33:37 +0900 Message-ID: To: Philip Homburg Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 13:34:00 -0000 On 6 January 2016 at 22:04, Philip Homburg wrote: >>I think instead we can publish this as is, and in future v6ops can >>look at a document describing host PD implementation and network >>operations experience, if such a document even proves necessary (which >>I doubt). > > I don't think we should write a BCP and then in a future document > describe how it works. That's not what a BCP is for. > > If the PD part is not required for this document, then just remove it. I disagree. PD is a perfectly valid way of addressing the issue and it needs to be included at some level of description for completeness. From nobody Wed Jan 6 05:37:00 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8FCA1B2B9E for ; Wed, 6 Jan 2016 05:36:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8Q5OUzeotg6 for ; Wed, 6 Jan 2016 05:36:57 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED72E1B2B93 for ; Wed, 6 Jan 2016 05:36:22 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u06DaKvP007536 for ; Wed, 6 Jan 2016 14:36:20 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B73D4202A8C for ; Wed, 6 Jan 2016 14:43:47 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id AE5C6200C0E for ; Wed, 6 Jan 2016 14:43:47 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u06DaK43002777 for ; Wed, 6 Jan 2016 14:36:20 +0100 To: v6ops@ietf.org References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> From: Alexandre Petrescu Message-ID: <568D1854.7000300@gmail.com> Date: Wed, 6 Jan 2016 14:36:20 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 13:36:59 -0000 sidenote... Le 05/01/2016 16:21, Lorenzo Colitti a écrit : > On Tue, Jan 5, 2016 at 10:08 PM, Philip Homburg > > wrote: > > - there are essentially no hosts requesting DHCPv6-PD > (I wonder if there are any hosts requesting multiple addresses using > DHCPv6 IA_NA). > - we know that in the CPE world there are at least two different > approaches of > doing DHCPv6-PD which does affect how the network provides those > addresses. (And also affects client implementations) > > So in short, there simply is no real practice when it comes to a > large part > of this document. > > > But it's not a "large part of the document" at all. It's not even a > large part of the requirements section. I think what you are disagreeing > with is only one of the recommendations, which is "if your network will > only allow hosts to connect if they do DHCPv6, then don't hand out an > addres via IA_NA, but hand out a prefix via DHCPv6 PD". > > And we also have to curious word play where a host that uses a prefix > obtained through DHCPv6-PD has to be a router from the point of view > of ND, > > > No, that's not true. A router is "a node that forwards packets not > explicitly addressed to itself" [RFC2460]. A host that uses a prefix > obtained using DHCPv6 PD does not need to do that. If one reads the Note attached to the router definition in 2460, then one understands that a host that uses a prefix obtained with DHCP-PD does need to forward, and maybe its apps to explicitate the source address. > and is actually a router in one of the use cases (tethering). And > will be a router > > in many implementations (AREO seems an exception in assigning > adresses to > the upstream interface), but we insist in calling it a host. > > > Looks like you're assuming that a node needs to be a router in order to > send a packet on one interface with a source address assigned to another > interface. That's not true at all. In fact, to give you an idea on how > this works I just ran a DHCPv6 PD client on my linux laptop to get a > prefix from my home router, picked an address out of the prefix, > assigned it to lo, and used it: > > 1. dhclient -d -6 -D LL -P eth0 # Run PD and note the prefix you get. > I got 2400:2410:20c0:4450::/60 > 2. ip -6 addr add dev lo 2400:2410:20c0:4450::1/128 # Pick an > address out of the prefix, assign to lo > 3. ping6 -I 2400:2410:20c0:4450::1 www.google.com > # Use that address to talk to the Internet > via eth0 > > This all works as expected (and as predicted by the specifications). My This is not as expected. It is the "unusual" word of 2460. It is unusual in that you had to argument "-I" to that ping6. The usual way is to be able to say just "ping6 google.com" without arguments. Alex > laptop sends the packets on eth0 because it's the interface with the > default route, both my laptop and my home router do NUD for the > link-local address of the other device, and packets flow. My laptop is > most certainly a host, and IPv6 forwarding is off. > > As for tethering - sure, a device with tethering enabled is a router. > But that's a minor point. If you were to pick only one of the two, would > you say that your phone and your laptop are "hosts" or "routers"? I > think it's appropriate to call them "hosts", even though they > occasionally act as routers. I suppose the word "node" would be more > correct, but it would be much less readable. > > So, publish as informational. Actually get some experience deploying > exactly what is proposed here. And then write a BCP on what is actually > deployed and how that works. > > > Again, I think you're not seeing the forest for the (DHCPv6 PD) tree. > The point of this document is not "networks should use DHCPv6 PD". The > point of this document is "networks that provide service to general > purpose devices should provide those devices with multiple addresses at > connection time". As the draft says, that statement is true of the > networks used by tens of millions of devices every day: pretty much > every home network, all 3GPP networks, and so on. > > DHCPv6 PD is cited simply because if a network has decided "we will use > DHCPv6 and nothing else", then the only possible way to assign enough > addresses is to use DHCPv6 PD. But that's a tiny minority of the > networks out there, and it's only a small part of the draft. > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Jan 6 07:23:25 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 591661A872E for ; Wed, 6 Jan 2016 07:23:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 rdhWyiN2Dsbo for ; Wed, 6 Jan 2016 07:23:20 -0800 (PST) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 965E21A8742 for ; Wed, 6 Jan 2016 07:23:15 -0800 (PST) Received: by mail-yk0-x231.google.com with SMTP id v14so225332568ykd.3 for ; Wed, 06 Jan 2016 07:23:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=A3zQpJyWWJNs48g0LbIOO3H+T1SjTglco38ch3paAeU=; b=ClDOaItpwADTZVmlDp9rERPJJ6qfWCijn2+Mer7F29riSiM7z82aaX71OIyLpHEUuz +9kq2Ivh35WVX+wrZHZkhIVoZngxOYMn4BjM9TC3vHiB+rA2EWoBfm+T3N+WOtmE8PvJ AYWldCdvqjBv3hRHCasFg5tfGV0lsb2Rfi3rvi8u7EkimYAhkOpF0J4mAaN5M7A4p3tQ dMlWVUPyNZEuLMDAixl0xDxUGmffgkK2mfkzByZzX3IdO5PwHgn0C8jxqTkMqcnKoKvh TTmo9MQvk1msaAADACAMlRhksZRIfl91BwNZfRpaMytOod4cprTOvCqO5+mALG0LtNcp F3zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=A3zQpJyWWJNs48g0LbIOO3H+T1SjTglco38ch3paAeU=; b=gxkTsybCS94MmJZ2lLhJHGg161wpynL1r9SqUrILhHG5cayOyoDylIVc2D7FHZhY6G HQUxJetzvSKRVWS3WEknzHdC+jMD/fXEc7Cbux15OPcFQBJQffP/NFmz8Bv79gX/rz3Y zlgiL1pGSBCpVT2RQJMxjvM+Zbg47dq4JGLDLQxXrIWPAaKfFu9sG4cDsWBzZ1rbl6Mz mDNUMPFL2WC41i6SKBBtMlDK95OwNALYZCN1ypsBEH6/949XLZGgGme7pdQqskMFcFe1 TwiwaypClDpkFSzUIG+/WYwEg3JavXwIqXUb8gDW3i6TDzA7Tdp0H1TWmWzgMXorbMB2 GLhg== X-Gm-Message-State: ALoCoQnWH/AGGrmL9yL++o8lelKH+FkAJ8GdMbWVdju2sevv6d4ArtXowQCET0QLdybdQhC+hkrqT8O8Vq4ZPbRSPjDnvcRz7bzNVHFZvJgfsRTIxIZzpZI= X-Received: by 10.129.108.88 with SMTP id h85mr83145511ywc.156.1452093794670; Wed, 06 Jan 2016 07:23:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.208.201 with HTTP; Wed, 6 Jan 2016 07:22:54 -0800 (PST) In-Reply-To: References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> From: Lorenzo Colitti Date: Thu, 7 Jan 2016 00:22:54 +0900 Message-ID: To: Philip Homburg Content-Type: multipart/alternative; boundary=001a114d88f0d0aefb0528abeef6 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 15:23:22 -0000 --001a114d88f0d0aefb0528abeef6 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 6, 2016 at 9:58 PM, Philip Homburg wrote: > So, if the technical details are required then in my opinion we also need > to have experience with them. And for general hosts we don't have that > for PD. And there are even two different way in which the network can > provide PD which impacts hosts as well. > Assuming that by "technical details" you mean DHCPv6 PD, then we do have experience with that. As an industry, we do know how to run networks that delegate prefixes via DHCPv6 PD to routers. It is widely deployed, and your previous "how can we possibly deal with failure mode X" questions asked on this list appear to have been answered satisfactorily. So, given that we know how to build networks that delegate space to routers using PD, then what is the concern with having the network behave exactly the same, but have the PD client be a host? I see three possible concerns: 1. We cannot implement the host part correctly. 2. We _can_ correctly implement the host part correctly, but we _shouldn't_ because there is a better solution. 3. We _don't know how_ to implement the host part correctly, and we should hold off on anything until we know. #1 seems hard to believe. As for #2, I see no other solution on the horizon. Are you suggesting we develop a new solution? Why, when we know we can implement DHCPv6 PD correctly and we have experience with it? I think you're claiming #3. In other words, you're not saying that we can't implement PD on hosts, and you're not saying there is a better solution than PD, but we don't know exactly how to implement it. But I'd argue that #3 is not a strong technical argument, for two reasons. First, host behaviour is out of scope for this draft. Because we know how to do the network side, we can put host behaviour in a subsequent draft, or leave it to implementers. (Personally it seems to me that that's not rocket science, since a host is not very different from a router with its LAN interface unplugged. Also, implementers figured out how to do the network side correctly without any RFC to guide them. The deployment scenarios in RFC 3633 certainly doesn't look like the majority of PD networks. Finally, there is already running code that does this in standard Linux distributions.) Second: this document has targeted BCP status and has contained the text on DHCPv6 from the very beginning. It has survived multiple consensus calls in that form, so I think that the WG has always been happy with those points. In the absence if is a solid technical concern that hasn't been thought of before, I would assume that the WG is still happy with them. > >And we also have to curious word play where a host that uses a prefix > >> obtained through DHCPv6-PD has to be a router from the point of view of > ND, > > > >No, that's not true. A router is "a node that forwards packets not > >explicitly addressed to itself" [RFC2460]. A host that uses a prefix > >obtained using DHCPv6 PD does not need to do that. > > If you run a VM on a host and create a virtual ethernet to connect to > the VM, then from a networking point of view the host is a router. > > There may not be any physical wire, but it behaves very much like a > router. > Sure, sometimes VM software routes. Sometimes it bridges. But that's wasn't the point. My point is that your earlier assertion is incorrect. A host can use a prefix obtained through DHCPv6 PD without being a router. The IP addresses in the prefix don't have to be handed out to VMs, they can be assigned to whatever the host feels like - for example to applications, as ILA does. For the most part a delegated prefix behaves as if it is assigned to a > router > even if in some cases it may technically be a host. > What does that mean? A host "behaves", and a router "behaves", but a prefix does not "behave". It's just a set of numbers. > >This all works as expected (and as predicted by the specifications). My > >laptop sends the packets on eth0 because it's the interface with the > >default route, both my laptop and my home router do NUD for the link-local > >address of the other device, and packets flow. My laptop is most certainly > >a host, and IPv6 forwarding is off. > > Did you look at the ND traffic? Do you expect all traffic from neighboring > hosts to 2400:2410:20c0:4450::/60 to go through your router instead of > instead of directly to your laptop? > As for ND - like I said, there's NUD for the link-local address. Traffic from neighbouring hosts will go through the router, of course - from the perspective of the router, my laptop is exactly the same as a subtended CPE router connected to one of its LAN ports, which is a fairly common configuration today. Again - the point is that as far as the network is concerned, it doesn't matter if the requesting node is a host or a router, the behaviour is the same. If you ping something other than 2400:2410:20c0:4450::1/128 does that end > up in a blackhole? Or how does your laptop know to send a destination > unreachable ICMP? > It depends on how you configure the laptop. In this instance I configured things manually, so it won't. But you can configure it to. But again - that's host behaviour, which is out of scope for this draft. > I think we should be more clear on the 'almost be not quite router > devices'. Or it will come back to bite us. > Do we? A node is either a host or a router. Everyone agrees that DHCPv6 PD works for routers. If it works for hosts, and it works for routers, then by definition it works for all nodes. >DHCPv6 PD is cited simply because if a network has decided "we will use > >DHCPv6 and nothing else", then the only possible way to assign enough > >addresses is to use DHCPv6 PD. But that's a tiny minority of the networks > >out there, and it's only a small part of the draft. > > It is simple, if PD is not needed, remove it. PD causes all kinds of > complexity we don't need. > > If it is just a tiny minority of nework, just write that it doesn't work in > all cases. Solves the problem. > We can't do that, because that leaves the problem of what to do on a network that has decided to provide address space only via DHCPv6. It seems to me that there has been pretty strong agreement all along that such networks should also provide sufficient address space to hosts. --001a114d88f0d0aefb0528abeef6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jan 6, 2016 at 9:58 PM, Philip Homburg <pch-v6ops-4@u-1.phico= h.com> wrote:
So, if the technical detail= s are required then in my opinion we also need
to have experience with them. And for general hosts we don't have that<= br> for PD. And there are even two different way in which the network can
provide PD which impacts hosts as well.

Assuming that by "technical details" you mean DHCPv6 PD, then we= do have experience with that. As an industry, we do know how to run networ= ks that delegate prefixes via DHCPv6 PD to routers. It is widely deployed, = and your previous "how can we possibly deal with failure mode X" = questions asked on this list appear to have been answered satisfactorily.

So, given that we know how to build networks that d= elegate space to routers using PD, then what is the concern with having the= network behave exactly the same, but have the PD client be a host? I see t= hree possible concerns:
  1. We cannot implement the host part= correctly.
  2. We _can_ correctly implement the host part correctl= y, but we _shouldn't_ because there is a better solution.
  3. W= e _don't know how_ to implement the host part correctly, and we should = hold off on anything until we know.
#1 seems hard to believe.= As for #2, I see no other solution on the horizon. Are you suggesting we d= evelop a new solution? Why, when we know we can implement DHCPv6 PD correct= ly and we have experience with it?

I think you'= ;re claiming #3. In other words, you're not saying that we can't im= plement PD on hosts, and you're not saying there is a better solution t= han PD, but we don't know exactly how to implement it. But I'd argu= e that #3 is not a strong technical argument, for two reasons.
First, host behaviour is out of scope for this draft. Because = we know how to do the network side, we can put host behaviour in a subseque= nt draft, or leave it to implementers. (Personally it seems to me that that= 's not rocket science, since a host is not very different from a router= with its LAN interface unplugged. Also, implementers figured out how to do= the network side correctly without any RFC to guide them. The deployment s= cenarios in RFC 3633 certainly doesn't look like the majority of PD net= works. Finally, there is already running code that does this in standard Li= nux distributions.)

Second: this document ha= s targeted BCP status and has contained the text on DHCPv6 from the very be= ginning. It has survived multiple consensus calls in that form, so I think = that the WG has always been happy with those points. In the absence if is a= solid technical concern that hasn't been thought of before, I would as= sume that the WG is still happy with them.
=C2=A0
>And we also have to curious word play where= a host that uses a prefix
>> obtained through DHCPv6-PD has to be a router from the point of vi= ew of ND,
>
>No, that's not true. A router is "a node that forwards packets= not
>explicitly addressed to itself" [RFC2460]. A host that uses a pref= ix
>obtained using DHCPv6 PD does not need to do that.

If you run a VM on a host and create a virtual ethernet to connect t= o
the VM, then from a networking point of view the host is a router.

There may not be any physical wire, but it behaves very much like a
router.

Sure, sometimes VM software rou= tes. Sometimes it bridges. But that's wasn't the point. My point is= that your earlier assertion is incorrect. A host can use a prefix obtained= through DHCPv6 PD without being a router. The IP addresses in the prefix d= on't have to be handed out to VMs, they can be assigned to whatever the= host feels like - for example to applications, as ILA does.

=
For the most part a delegated prefix behaves as if i= t is assigned to a router
even if in some cases it may technically be a host.
What does that mean? A host "behaves", and a router = "behaves", but a prefix does not "behave". It's jus= t a set of numbers.
=C2=A0
>This all works as expected (and as predicted by the specifications). M= y
>laptop sends the packets on eth0 because it's the interface with th= e
>default route, both my laptop and my home router do NUD for the link-lo= cal
>address of the other device, and packets flow. My laptop is most certai= nly
>a host, and IPv6 forwarding is off.

Did you look at the ND traffic? Do you expect all traffic from neigh= boring
hosts to 2400:2410:20c0:4450::/60 to go through your router instead of
instead of directly to your laptop?

As = for ND - like I said, there's NUD for the link-local address. Traffic f= rom neighbouring hosts will go through the router, of course - from the per= spective of the router, my laptop is exactly the same as a subtended CPE ro= uter connected to one of its LAN ports, which is a fairly common configurat= ion today. Again - the point is that as far as the network is concerned, it= doesn't matter if the requesting node is a host or a router, the behav= iour is the same.

If you ping somethin= g other than 2400:2410:20c0:4450::1/128 does that end
up in a blackhole? Or how does your laptop know to send a destination
unreachable ICMP?

It depends on how you= configure the laptop. In this instance I configured things manually, so it= won't. But you can configure it to. But again - that's host behavi= our, which is out of scope for this draft.
=C2=A0
I think we should be more clear on the 'almost be not quite rout= er
devices'. Or it will come back to bite us.

Do we? A node is either a host or a router. Everyone agrees that DH= CPv6 PD works for routers. If it works for hosts, and it works for routers,= then by definition it works for all nodes.

>DHCPv6 PD is cited simply because if a network has decided "we wil= l use
>DHCPv6 and nothing else", then the only possible way to assign eno= ugh
>addresses is to use DHCPv6 PD. But that's a tiny minority of the ne= tworks
>out there, and it's only a small part of the draft.

It is simple, if PD is not needed, remove it. PD causes all kinds of=
complexity we don't need.

If it is just a tiny minority of nework, just write that it doesn't wor= k in
all cases. Solves the problem.

We can't do that, because that leaves the problem of what= to do on a network that has decided to provide address space only via DHCP= v6. It seems to me that there has been pretty strong agreement all along th= at such networks should also provide sufficient address space to hosts.
--001a114d88f0d0aefb0528abeef6-- From nobody Wed Jan 6 07:28:05 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2119E1A872E for ; Wed, 6 Jan 2016 07:28:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 MrR1kIXoQCPa for ; Wed, 6 Jan 2016 07:28:01 -0800 (PST) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 823161A8740 for ; Wed, 6 Jan 2016 07:28:01 -0800 (PST) Received: by mail-yk0-x233.google.com with SMTP id k129so296382125yke.0 for ; Wed, 06 Jan 2016 07:28:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=RDEaPI5ehxz+Whc2dwi1Gwp9VRcbDpr6TyA1BNAN4P8=; b=Vcn1sMamcIpvqln4ONrPtuOFkAW+K72iwb8drdngqPvJG9vuCaBq1S47mz4z4x0GuX L48vHk6EFI9DTSJoTzIWWZoB7/MqFQR6ivBHBr3ipGad/jQxizW3d6VU7g2CHJrNgNRt 4Aj0cv+7DCD4WIL+3YA2KWqcP6IUIJw/ahDvTJ8Jcdt4ZpfaikcNjROiPJJjxJzc39DN I24tOn6VZBMbC9rvTP5V/W04GVggFBamkBLy5Fd2S/kAuWGkn6CNnQxQzvUYDA84eqPO ZlofSQtFXWbB8taBABY7lYwxZrtpjfFtRDd1zCsTu1Vjk/LmOqkH3SJW5dC4vACiY4kq EEtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=RDEaPI5ehxz+Whc2dwi1Gwp9VRcbDpr6TyA1BNAN4P8=; b=bWtqA363jNqA4Y9m0Vn0OwQpNBOqu8sjk0rYpAWmo6e+lcROuUqHbURojQhvaPThbJ vvH2Spz+8NcaHJ4rNeAYcLEXHIk7MKDhrrtTFni2zW/JmqWAXUzD+XYlQ8bAKvfU5j6x 4rlyWYx8rGtSrwklS/4L4FR+4r3cQtdbwmij00uILEWVDAi463HFr/Rvgu8d7WKI3FY+ 8P2JUMh0zRUxSxn2Bopgpb5NhRXFj0mTNcYZ7y/mUv4U3gFgggzPJut0nNyiAexoJ/kB yTotF9ccJp/RbfBccBZf6JXPo9qwb0qjgKTKPl9/5q8aPwvxmLbGsw1+41iKQGhbuR2J iMiQ== X-Gm-Message-State: ALoCoQm9F1LcgK5StlwGOiBhz1eXqh6eaZXi1GuzTYklKEkZAC0n4LKzxRpLFG4iobV6nPjVzA+5I7Km0EnDYv17zM8lqTjy3ZspBa9LDmAnHUKR5Ctwuh0= X-Received: by 10.129.45.137 with SMTP id t131mr70107126ywt.337.1452094080740; Wed, 06 Jan 2016 07:28:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.208.201 with HTTP; Wed, 6 Jan 2016 07:27:40 -0800 (PST) In-Reply-To: <568D1854.7000300@gmail.com> References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <568D1854.7000300@gmail.com> From: Lorenzo Colitti Date: Thu, 7 Jan 2016 00:27:40 +0900 Message-ID: To: Alexandre Petrescu Content-Type: multipart/alternative; boundary=001a1141e9b6dd7bbd0528abff71 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 15:28:03 -0000 --001a1141e9b6dd7bbd0528abff71 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 6, 2016 at 10:36 PM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > sidenote... > >> No, that's not true. A router is "a node that forwards packets not >> explicitly addressed to itself" [RFC2460]. A host that uses a prefix >> obtained using DHCPv6 PD does not need to do that. >> > > If one reads the Note attached to the router definition in 2460, then one > understands that a host that uses a prefix obtained with DHCP-PD does need > to forward, and maybe its apps to explicitate the source address. > Why? Consider the ULA use case where a host gets a /64 via DHCPv6 PD and uses this to assign a different IPv6 address to every process on the system. The host does not need to forward any packets to anyone on any interface, and thus is not a router. > This all works as expected (and as predicted by the specifications). My >> > > This is not as expected. It is the "unusual" word of 2460. > The "unusual" word in RFC 2460 refers to a node that forwards packets arriving on some interfaces but not on others. That is not the case here. My laptop was not forwarding packets from any interface to any interface and it was purely a host. > It is unusual in that you had to argument "-I" to that ping6. > > The usual way is to be able to say just "ping6 google.com" without > arguments. > If I had not specified -I, someone would have said "there is no proof that this works, your laptop could have been using another address, one that was not obtained via DHCPv6 PD". :-) --001a1141e9b6dd7bbd0528abff71 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Jan 6, 2016 at 10:36 PM, Alexandre Petrescu <<= a href=3D"mailto:alexandre.petrescu@gmail.com" target=3D"_blank">alexandre.= petrescu@gmail.com> wrote:
= sidenote...
No, that's not true. A router is "a node that forwards= packets not
explicitly addressed to itself" [RFC2460]. A host that uses a prefix obtained using DHCPv6 PD does not need to do that.

If one reads the Note attached to the router definition in 2460, then one u= nderstands that a host that uses a prefix obtained with DHCP-PD does need t= o forward, and maybe its apps to explicitate the source address.

Why? Consider the ULA use case where a host gets = a /64 via DHCPv6 PD and uses this to assign a different IPv6 address to eve= ry process on the system. The host does not need to forward any packets to = anyone on any interface, and thus is not a router.
=C2=A0
This all works as expected (and as predicted by the specifications). My

 This is not as expected.=C2=A0 It is the "unusual" word of 2460.<= br>

The "unusual" word in RFC 246= 0 refers to a node that forwards packets arriving on some interfaces but no= t on others. That is not the case here. My laptop was not forwarding packet= s from any interface to any interface and it was purely a host.
= =C2=A0
It is unusual in that you had to argument "-I" to that ping6.

The usual way is to be able to say just "ping6 google.com" without ar= guments.

If I had not specified -I, som= eone would have said "there is no proof that this works, your laptop c= ould have been using another address, one that was not obtained via DHCPv6 = PD". :-)
--001a1141e9b6dd7bbd0528abff71-- From nobody Wed Jan 6 07:42:38 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1905C1A8788 for ; Wed, 6 Jan 2016 07:42:37 -0800 (PST) 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, 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 Ws8pLGznodra for ; Wed, 6 Jan 2016 07:42:35 -0800 (PST) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 857DB1A8771 for ; Wed, 6 Jan 2016 07:42:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u06FgYZS041036; Wed, 6 Jan 2016 08:42:34 -0700 Received: from XCH-BLV-503.nw.nos.boeing.com (xch-blv-503.nw.nos.boeing.com [130.247.25.192]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u06FgPEQ040936 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 6 Jan 2016 08:42:26 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.52]) by XCH-BLV-503.nw.nos.boeing.com ([169.254.3.54]) with mapi id 14.03.0235.001; Wed, 6 Jan 2016 07:42:25 -0800 From: "Templin, Fred L" To: David Farmer , "Fred Baker (fred)" Thread-Topic: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host Thread-Index: AQHRR+nwI13RUsgT4kOKL/Th7Sw3uJ7uJ54A//962WCAAIlWAP//enSggACTAICAAGZA4A== Date: Wed, 6 Jan 2016 15:42:25 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F9A85C@XCH-BLV-504.nw.nos.boeing.com> References: <201601031900.u03J0LMe009763@irp-lnx1.cisco.com> <2134F8430051B64F815C691A62D9831832F988DB@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F99D14@XCH-BLV-504.nw.nos.boeing.com> <6065AA2A-25BB-4B32-B88B-40A856D0E1EA@cisco.com> <2134F8430051B64F815C691A62D9831832F9A0EA@XCH-BLV-504.nw.nos.boeing.com> <568C625A.80808@umn.edu> <2134F8430051B64F815C691A62D9831832F9A12C@XCH-BLV-504.nw.nos.boeing.com> <568C6DA3.5010102@umn.edu> In-Reply-To: <568C6DA3.5010102@umn.edu> 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: Cc: "v6ops@ietf.org" , John Brzozowski Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 15:42:37 -0000 Hi David, > -----Original Message----- > From: David Farmer [mailto:farmer@umn.edu] > Sent: Tuesday, January 05, 2016 5:28 PM > To: Templin, Fred L; Fred Baker (fred) > Cc: David Farmer; v6ops@ietf.org; John Brzozowski > Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-pre= fix-per-host >=20 > On 1/5/16 18:46 , Templin, Fred L wrote: > > Hi David, > > > >> -----Original Message----- > >> From: David Farmer [mailto:farmer@umn.edu] > ... > >> In my view AERO and this draft are working in slightly overlapping, bu= t > >> different solution spaces. > > > > We don't know that without a use case analysis. >=20 > Well as I read this, this doesn't implement DHCPv6 PD. Furthermore, it > doesn't need any client software. It uses SLAAC and responds to each > IPv6 ND Router Solicitation with a unicast Router Advertisement with > different prefix for each client. It provides DNS server info with > RADNS and stateless DHCPv6 if the client send a request. How would an unmodified client know that the prefix it receives in a unicast RA is in fact uniquely assigned for the client's exclusive use and not advertised to any other client? > The client requirement are just standard SLAAC, and RADNS or stateless > DHCPv6, that is it. No DHCPv6 PD client needed, am I missing something? I think so. An unmodified client receiving a PIO with (A=3D1, L=3D0) would = have no way of knowing that the prefix is being delegated for its own exclusive use and that the prefix would not be advertised to other clients. > There is a bunch of WiFi parts too, just like AERO has tunnel stuff, but > that is fairly standard WiFi infrastructure bits. I thought this work was based on tunneling, too? And, AERO can run fine over WiFi just the same as over any link-layer technology. > So, there is a really quick use case analysis for you and I'll > reiterate; in my view AERO and this draft are working in slightly > overlapping, but different solution spaces. I don't see how multi-addressing in the spirit of "host-addr-availabiity" can be supported on an unmodified client. There would need to be additional specification telling the client what to do when it receives a PIO with (A=3D1,L=3D0). But then, the document becomes a spec and not an informational. And, clients would have to be modified. Thanks - Fred fred.l.templin@boeing.com > Thanks. >=20 >=20 > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > David Farmer Email: farmer@umn.edu > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 1-612-626-0815 > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From nobody Wed Jan 6 07:56:51 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E06A1AC3D9 for ; Wed, 6 Jan 2016 07:56:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 WInEuI5GMXlm for ; Wed, 6 Jan 2016 07:56:47 -0800 (PST) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D76F1A87C6 for ; Wed, 6 Jan 2016 07:56:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u06FuqI8005168; Wed, 6 Jan 2016 07:56:52 -0800 Received: from XCH-BLV-407.nw.nos.boeing.com (xch-blv-407.nw.nos.boeing.com [130.247.25.165]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u06Fufo9004464 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 6 Jan 2016 07:56:41 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.52]) by XCH-BLV-407.nw.nos.boeing.com ([169.254.7.99]) with mapi id 14.03.0235.001; Wed, 6 Jan 2016 07:56:36 -0800 From: "Templin, Fred L" To: Lorenzo Colitti Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt Thread-Index: AQHRRw6yg6NBQZxHIk+n1ca7lLlCA57rkfFwgAEtoQCAAII1wIAA/QmAgABmaMA= Date: Wed, 6 Jan 2016 15:56:36 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F9A897@XCH-BLV-504.nw.nos.boeing.com> References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F99CEE@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: multipart/alternative; boundary="_000_2134F8430051B64F815C691A62D9831832F9A897XCHBLV504nwnosb_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 15:56:49 -0000 --_000_2134F8430051B64F815C691A62D9831832F9A897XCHBLV504nwnosb_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTG9yZW56bywNCg0KU3BlYWtpbmcgb25seSB0byB0aGUgY29tcGxleGl0eSBjb25jZXJuLCB0 aGVyZSBhcmUgbWFqb3IgcGllY2VzIG9mIERIQ1B2NiBjbGllbnQgKGUuZy4sDQpETlMgc2VydmVy IGRpc2NvdmVyeSkgdGhhdCBhcmUgbm90IG5lZWRlZCBieSBBRVJPIGFuZCBoZW5jZSBhcmUgbm90 IGltcGxlbWVudGVkLg0KQUVSTyBpcyBESENQdjYgUEQgb25seSAobm8gSUFfTkEsIElBX1RBLCBl dGMuKSBhbmQgYWRkcyByb3V0ZSBvcHRpbWl6YXRpb24sIGZhdWx0DQp0b2xlcmFuY2UgYW5kIG1v YmlsaXR5IHN1cHBvcnQg4oCTIGFsbCBvZiB3aGljaCBhcmUgb3B0aW9uYWwuIFlvdSBkb27igJl0 IGdldCBzb21ldGhpbmcNCmZvciBub3RoaW5nLCBzbyBpZiB5b3Ugd2FudCB0byBoYXZlLCBlLmcu LCBtb2JpbGl0eSBzdXBwb3J0IGl0IG5lZWRzIHRvIGJlIGltcGxlbWVudGVkDQpidXQgdGhlIGNv ZGUgZm9yIHRoaXMgaXMgbm90IGxhcmdlLiBUaGUgQUVSTyBjbGllbnQgaXMgdGhpbiBpbiB0aGUg c2FtZSB3YXkgdGhhdCBhbGwNCkRIQ1B2NiBjbGllbnRzIHNob3VsZCBiZSB0aGluLiBBcmUgeW91 IGFyZ3VpbmcgdGhhdCBpdCBpcyBub3QgdGhpbiBlbm91Z2g/DQoNClRoYW5rcyDigJMgRnJlZA0K ZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbQ0KDQpGcm9tOiBMb3JlbnpvIENvbGl0dGkgW21haWx0 bzpsb3JlbnpvQGdvb2dsZS5jb21dDQpTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDA1LCAyMDE2IDU6 NDIgUE0NClRvOiBUZW1wbGluLCBGcmVkIEwNCkNjOiB2Nm9wc0BpZXRmLm9yZyBXRw0KU3ViamVj dDogUmU6IFt2Nm9wc10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi12Nm9wcy1ob3N0LWFkZHItYXZh aWxhYmlsaXR5LTA0LnR4dA0KDQpPbiBXZWQsIEphbiA2LCAyMDE2IGF0IDM6NDMgQU0sIFRlbXBs aW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTxtYWlsdG86RnJlZC5MLlRlbXBs aW5AYm9laW5nLmNvbT4+IHdyb3RlOg0KRkxUPj4+IFRoZSBjaXRhdGlvbiB3b3VsZCBiZSB0byDi gJxkcmFmdC10ZW1wbGluLWFlcm9saW5r4oCdIHdoaWNoIGlzIGJlaW5nIHByb3Bvc2VkIGFzIHN0 YW5kYXJkcy10cmFjay4NCkZMVD4+PiBUaGVyZSBhcmUgcGxlbnR5IG9mIGV4YW1wbGVzIG9mIGlu Zm9ybWF0aXZlIGNpdGF0aW9ucyBvZiB3b3JrcyBpbiBwcm9ncmVzcyBpbiBwdWJsaXNoZWQgUkZD cy4NCg0KRmFpciBlbm91Z2gsIGJ1dCBteSBlYXJsaWVyIGNvbmNlcm5zIChhbHNvIGV4cHJlc3Nl ZCBieSBEYXZpZCBGYXJtZXIsIElJUkMpIHN0aWxsIHN0YW5kLg0KDQrigKIgQXMgYSBob3N0IGlt cGxlbWVudGVyLCBJIHdvdWxkIG11Y2ggcmF0aGVyIGltcGxlbWVudCBESENQdjYgUEQgd2l0aG91 dCBBRVJPIHRoYW4gd2l0aCBBRVJPLiBJdCdzIG11Y2ggc2ltcGxlciBvbiB0aGUgY2xpZW50IHNp ZGUsIGFuZCBpdCBoYXMgbm8gbmV0d29yay1zaWRlIGRlcGVuZGVuY2llcywgc28gaXQgc2VlbXMg bW9yZSBsaWtlbHkgdG8gYmUgZGVwbG95YWJsZS4gVGhpcyBpcyBteSBvcGluaW9uLCBhbmQgSSBk b3VidCB0aGF0IEkgd2lsbCBlYXNpbHkgYmUgY29udmluY2VkIG90aGVyd2lzZS4NCg0KRkxUPj4+ IFRoYXQgaXMgaW5jb3JyZWN0LiBNeSBBRVJPIERIQ1B2NiBjbGllbnQgY29kZSBpcyBtdWNoIHNp bXBsZXIgdGhhbiwgZS5nLiwgdGhlIElTQyBkaGNsaWVudA0KRkxUPj4+IGNvZGUgdGhhdCBkb2Vz IG5vdCBkbyBBRVJPLiBIYXZlIGEgbG9vayBhdCBteSBjb2RlLg0KDQpJIHN0YW5kIGJ5IG15IHN0 YXRlbWVudC4gSSBkb24ndCBzZWUgaG93IHlvdSBjYW4gYXJndWUgdGhhdCBpbXBsZW1lbnRpbmcg REhDUHY2IFBEIHBsdXMgQUVSTyBpcyBzaW1wbGVyIHRoYW4gaW1wbGVtZW50aW5nIERIQ1B2NiBQ RCBieSBpdHNlbGYuIFRoZSBmYWN0IHRoYXQgeW91ciBjb2RlIGlzIHNpbXBsZXIgdGhhbiB0aGUg SVNDIGNsaWVudCBkb2Vzbid0IHByb3ZlIHRoYXQgQUVSTyBpcyBzaW1wbGVyIHRvIGltcGxlbWVu dCwgaXQgb25seSBwcm92ZXMgdGhhdCBJU0Mgd3JvdGUgbW9yZSBjb21wbGljYXRlZCBjb2RlIHRo YW4geW91IGRpZC4NCg0KVGhhdCBzYWlkOiB0aGUgSUVURiBwcm9jZXNzIGlzIGJhc2VkIG9uIHJv dWdoIGNvbnNlbnN1cy4gRnJvbSB3aGF0IEkndmUgc2VlbiBzbyBmYXIsIHlvdSBhcmUgdGhlIG9u bHkgV0cgcGFydGljaXBhbnQgYXJndWluZyBmb3IgYSByZWZlcmVuY2UgdG8gQUVSTyBpbiB0aGlz IGRvY3VtZW50LCBidXQgaWYgc29tZWhvdyByb3VnaCBjb25zZW5zdXMgZW1lcmdlcyB0aGF0IHRo aXMgaXMgdGhlIHJpZ2h0IHRoaW5nIHRvIGRvIChhbmQgaXQgZW1lcmdlcyBxdWlja2x5OyBiZWFy IGluIG1pbmQgdGhhdCB3ZSdyZSB3ZWxsIHBhc3QgdGhlIGVuZCBvZiB0aGUgc3VwcGxlbWVudGFs IHBvc3QtV0dMQyBjb21tZW50IHBlcmlvZCB0aGF0IEZyZWQgZGVjbGFyZWQgYSBmZXcgd2Vla3Mg YWdvKSwgdGhlbiB3ZSBjYW4gcmUtZXZhbHVhdGUuDQoNCkZMVD4+PiBJdCBzZWVtcyBsaWtlIHRo ZXJlIGlzIHN0aWxsIGVtZXJnaW5nIGNvbnNlbnN1cyBvbiB0aGlzLg0KDQpJdCdzIG5vdCBteSBy b2xlIHRvIGRlY2xhcmUgY29uc2Vuc3VzLCBidXQgdGhhdCBpcyB2ZXJ5IGZhciBmcm9tIG15IHJl YWQgb2YgdGhlIHNpdHVhdGlvbi4NCg== --_000_2134F8430051B64F815C691A62D9831832F9A897XCHBLV504nwnosb_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIExvcmVuem8sPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5TcGVha2luZyBvbmx5IHRvIHRoZSBjb21wbGV4 aXR5IGNvbmNlcm4sIHRoZXJlIGFyZSBtYWpvciBwaWVjZXMgb2YgREhDUHY2IGNsaWVudCAoZS5n Liw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+RE5TIHNlcnZlciBkaXNjb3ZlcnkpIHRoYXQgYXJlIG5vdCBu ZWVkZWQgYnkgQUVSTyBhbmQgaGVuY2UgYXJlIG5vdCBpbXBsZW1lbnRlZC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+QUVSTyBpcyBESENQdjYgUEQgb25seSAobm8gSUFfTkEsIElBX1RBLCBldGMuKSBhbmQg YWRkcyByb3V0ZSBvcHRpbWl6YXRpb24sIGZhdWx0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnRvbGVyYW5j ZSBhbmQgbW9iaWxpdHkgc3VwcG9ydCDigJMgYWxsIG9mIHdoaWNoIGFyZSBvcHRpb25hbC4gWW91 IGRvbuKAmXQgZ2V0IHNvbWV0aGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5mb3Igbm90aGluZywgc28g aWYgeW91IHdhbnQgdG8gaGF2ZSwgZS5nLiwgbW9iaWxpdHkgc3VwcG9ydCBpdCBuZWVkcyB0byBi ZSBpbXBsZW1lbnRlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5idXQgdGhlIGNvZGUgZm9yIHRoaXMgaXMg bm90IGxhcmdlLiBUaGUgQUVSTyBjbGllbnQgaXMgdGhpbiBpbiB0aGUgc2FtZSB3YXkgdGhhdCBh bGw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+REhDUHY2IGNsaWVudHMgc2hvdWxkIGJlIHRoaW4uIEFyZSB5 b3UgYXJndWluZyB0aGF0IGl0IGlzIG5vdCB0aGluIGVub3VnaD88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyDigJMgRnJlZDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5mcmVkLmwudGVtcGxpbkBib2VpbmcuY29tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gTG9yZW56byBDb2xpdHRpIFtt YWlsdG86bG9yZW56b0Bnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEph bnVhcnkgMDUsIDIwMTYgNTo0MiBQTTxicj4NCjxiPlRvOjwvYj4gVGVtcGxpbiwgRnJlZCBMPGJy Pg0KPGI+Q2M6PC9iPiB2Nm9wc0BpZXRmLm9yZyBXRzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W3Y2b3BzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXY2b3BzLWhvc3QtYWRkci1hdmFpbGFiaWxp dHktMDQudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBKYW4gNiwgMjAxNiBhdCAzOjQzIEFNLCBUZW1w bGluLCBGcmVkIEwgJmx0OzxhIGhyZWY9Im1haWx0bzpGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29t IiB0YXJnZXQ9Il9ibGFuayI+RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkZMVCZndDsmZ3Q7Jmd0OyBUaGUgY2l0YXRpb24gd291bGQgYmUgdG8g4oCcZHJh ZnQtdGVtcGxpbi1hZXJvbGlua+KAnSB3aGljaCBpcyBiZWluZyBwcm9wb3NlZCBhcyBzdGFuZGFy ZHMtdHJhY2suPGJyPg0KRkxUJmd0OyZndDsmZ3Q7IFRoZXJlIGFyZSBwbGVudHkgb2YgZXhhbXBs ZXMgb2YgaW5mb3JtYXRpdmUgY2l0YXRpb25zIG9mIHdvcmtzIGluIHByb2dyZXNzIGluIHB1Ymxp c2hlZCBSRkNzLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+RmFpciBlbm91Z2gsIGJ1dCBteSBlYXJsaWVyIGNvbmNlcm5zIChhbHNv IGV4cHJlc3NlZCBieSBEYXZpZCBGYXJtZXIsIElJUkMpIHN0aWxsIHN0YW5kLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7igKIgQXMg YSBob3N0IGltcGxlbWVudGVyLCBJIHdvdWxkIG11Y2ggcmF0aGVyIGltcGxlbWVudCBESENQdjYg UEQgd2l0aG91dCBBRVJPIHRoYW4gd2l0aCBBRVJPLiBJdCdzIG11Y2ggc2ltcGxlciBvbiB0aGUg Y2xpZW50IHNpZGUsIGFuZCBpdCBoYXMgbm8gbmV0d29yay1zaWRlIGRlcGVuZGVuY2llcywgc28g aXQgc2VlbXMgbW9yZSBsaWtlbHkgdG8gYmUgZGVwbG95YWJsZS4gVGhpcyBpcyBteSBvcGluaW9u LCBhbmQNCiBJIGRvdWJ0IHRoYXQgSSB3aWxsIGVhc2lseSBiZSBjb252aW5jZWQgb3RoZXJ3aXNl Ljxicj4NCjxicj4NCkZMVCZndDsmZ3Q7Jmd0OyBUaGF0IGlzIGluY29ycmVjdC4gTXkgQUVSTyBE SENQdjYgY2xpZW50IGNvZGUgaXMgbXVjaCBzaW1wbGVyIHRoYW4sIGUuZy4sIHRoZSBJU0MgZGhj bGllbnQ8YnI+DQpGTFQmZ3Q7Jmd0OyZndDsgY29kZSB0aGF0IGRvZXMgbm90IGRvIEFFUk8uIEhh dmUgYSBsb29rIGF0IG15IGNvZGUuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHN0YW5kIGJ5IG15IHN0YXRlbWVudC4gSSBkb24n dCBzZWUgaG93IHlvdSBjYW4gYXJndWUgdGhhdCBpbXBsZW1lbnRpbmcgREhDUHY2IFBEIHBsdXMg QUVSTyBpcyBzaW1wbGVyIHRoYW4gaW1wbGVtZW50aW5nIERIQ1B2NiBQRCBieSBpdHNlbGYuIFRo ZSBmYWN0IHRoYXQgeW91ciBjb2RlIGlzIHNpbXBsZXIgdGhhbiB0aGUgSVNDIGNsaWVudCBkb2Vz bid0IHByb3ZlIHRoYXQgQUVSTyBpcyBzaW1wbGVyIHRvDQogaW1wbGVtZW50LCBpdCBvbmx5IHBy b3ZlcyB0aGF0IElTQyB3cm90ZSBtb3JlIGNvbXBsaWNhdGVkIGNvZGUgdGhhbiB5b3UgZGlkLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGF0IHNhaWQ6IHRoZSBJRVRGIHByb2Nlc3MgaXMgYmFzZWQgb24gcm91Z2ggY29uc2Vuc3Vz LiBGcm9tIHdoYXQgSSd2ZSBzZWVuIHNvIGZhciwgeW91IGFyZSB0aGUgb25seSBXRyBwYXJ0aWNp cGFudCBhcmd1aW5nIGZvciBhIHJlZmVyZW5jZSB0byBBRVJPIGluIHRoaXMgZG9jdW1lbnQsIGJ1 dCBpZiBzb21laG93IHJvdWdoIGNvbnNlbnN1cyBlbWVyZ2VzIHRoYXQgdGhpcyBpcyB0aGUgcmln aHQgdGhpbmcgdG8NCiBkbyAoYW5kIGl0IGVtZXJnZXMgcXVpY2tseTsgYmVhciBpbiBtaW5kIHRo YXQgd2UncmUgd2VsbCBwYXN0IHRoZSBlbmQgb2YgdGhlIHN1cHBsZW1lbnRhbCBwb3N0LVdHTEMg Y29tbWVudCBwZXJpb2QgdGhhdCBGcmVkIGRlY2xhcmVkIGEgZmV3IHdlZWtzIGFnbyksIHRoZW4g d2UgY2FuIHJlLWV2YWx1YXRlLjxicj4NCjxicj4NCkZMVCZndDsmZ3Q7Jmd0OyBJdCBzZWVtcyBs aWtlIHRoZXJlIGlzIHN0aWxsIGVtZXJnaW5nIGNvbnNlbnN1cyBvbiB0aGlzLjxvOnA+PC9vOnA+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQncyBu b3QgbXkgcm9sZSB0byBkZWNsYXJlIGNvbnNlbnN1cywgYnV0IHRoYXQgaXMgdmVyeSBmYXIgZnJv bSBteSByZWFkIG9mIHRoZSBzaXR1YXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_2134F8430051B64F815C691A62D9831832F9A897XCHBLV504nwnosb_-- From nobody Wed Jan 6 08:30:12 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB77D1AD0C8 for ; Wed, 6 Jan 2016 08:30:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PeF3X4oIneTp for ; Wed, 6 Jan 2016 08:30:07 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA5E31B2DBD for ; Wed, 6 Jan 2016 08:30:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5932; q=dns/txt; s=iport; t=1452097806; x=1453307406; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Pm6Sr5rjFmvv4uNQqlsCiRelEuKHYMMiAVz2AL6fZoI=; b=bKieneS4XUoa9Ia5KbeeUoprAeMJiggxaQFiEmq7/26UgAYrbrvT7xYm WtdTbnuvhaIQScD3SqieB9Vi2mtlepJ7HfXYA7LxTVAUnGFcvW2Z0pRua 5xo2NNMyiCndTR0TXLXjEJusQCMWE6hmFIg7AVuFV2GJ0LYpbVyybUSxv 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D7AQA+QI1W/5RdJa1egm5MUnOIU7NXA?= =?us-ascii?q?Q2BZIYPAhyBBzgUAQEBAQEBAX8LhDUBAQQjVhACAQgEPgICAjAlAgQOGYgbsTu?= =?us-ascii?q?QXgEBAQEBAQEBAQEBAQEBAQEBAQEBARiGVgGEfodzgUkFlwoBjVSBXI0eilSDc?= =?us-ascii?q?gEgAQFChAqFS4EIAQEB?= X-IronPort-AV: E=Sophos;i="5.20,529,1444694400"; d="scan'208,217";a="224637961" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jan 2016 16:30:05 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u06GU4Kl031369 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Jan 2016 16:30:05 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 6 Jan 2016 11:30:03 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Wed, 6 Jan 2016 11:30:04 -0500 From: "Eric Vyncke (evyncke)" To: "draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org" Thread-Topic: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host Thread-Index: AQHRRrIF7o8qQUloLkyynK24JTNGyJ7vFi6A Date: Wed, 6 Jan 2016 16:30:03 +0000 Message-ID: References: <201601031900.u03J0LMe009763@irp-lnx1.cisco.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.56.4] Content-Type: multipart/alternative; boundary="_000_D2B2F84663BCCevynckeciscocom_" MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 16:30:12 -0000 --_000_D2B2F84663BCCevynckeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QmVsYXRlZCBjb21tZW50cyBvbiB0aGlzIHVzZWZ1bCBkcmFmdC4uLg0KDQpJIGFtIGNvbmZ1c2Vk IGJ5IHRoZSB3b3JkaW5nIG9mICdJUHY2IG9ubHkgZXhwZXJpZW5jZSBldmVuIGlmIElQdjQgc3Vw cG9ydCBpcyBwcmVzZW50Jw0KDQpJdCBhcHBlYXJzIHRvIG1lIHRoYXQgdGhlIHNlY3VyaXR5IGFt b25nIHVzZXJzIG9ubHkgcmVsaWVzIG9uIHRoZSBBUCBpbiBpc29sYXRpb24gbW9kZSAob3Igc3Bs aXQtaG9yaXpvbikuLi4gVGhpcyBtYWtlcyB0aGUgSS1EIG1haW5seSByZWxldmFudCB0byB5b3Vy IHVzZSBjYXNlIDotKA0KDQpJdCBpcyBub3QgY2xlYXIgd2hldGhlciB0aGUgVUUgd2lsbCBhbHdh eXMgcmVjZWl2ZSB0aGUgc2FtZSAvNjQgZXZlbiB3aGVuICdyb2FtaW5nJyB3aXRoaW4gdGhlIGNv bW11bml0eSBXaUZpIGFzIGl0IHdvdWxkIGhhdmUgcHJpdmFjeSBpbXBsaWNhdGlvbnMuDQoNClNl Y3Rpb24gNC4zLjIsIGRvIHdlIGhhdmUgZGF0YSBiYWNraW5nIHRoYXQgbW9zdCBPUyBzdGlsbCBk byBETlMgcmVxdWVzdCBvdmVyIElQdjQ/DQoNClNlY3Rpb24gNSwgSSBtdXN0IGFkbWl0IHRoYXQg SSBkbyBub3QgdW5kZXJzdGFuZCB3aHkgdGhlIEdXIGhhcyB0byBzZW5kIHBlcmlvZGljIHVuc29s aWNpdGVkICh1bmljYXN0IEkgaG9wZSB0byBnZXQgdGhlIFdpRmkgQUNLKSBSQS4uLiBXaHkgbm90 IHdhaXQgZm9yIHRoZSBSUyBieSB0aGUgVUU/DQoNClNlY3Rpb24gNSwgd2hlbiB0aGUgR1cgJ3Bp bmdzJyB0aGUgVUUsIGRvZXMgaXQgdXNlIElDTVA/IE9yIHBsYWluIE5TID8gQ2FuIHRoZSBBUCBs ZXZlcmFnZSBhbnkgV2lGaSBwb2xsaW5nPw0KDQpBIGJpZyAgYWR2YW50YWdlICAod2hpY2ggaXMg bm90IGRlc2NyaWJlZCkgaXMgdGhhdCB0aGVyZSB3aWxsIGJlIGEgbWluaW11bSBvZiBORFAgbXVs dGljYXN0IHRyYWZmaWMgd2hpY2ggaXMgYSBwYWluIG92ZXIgV2lGSSBjZnIgZHJhZnQtdnluY2tl LTZtYW4tbWNhc3Qtbm90LWVmZmljaWVudC0wMQ0KDQpDb3NtZXRpYzoNCg0KICAqICAgQVNDSUkg YXJ0IHRvcG9sb2d5IHdvdWxkIGluY3JlYXNlIHRoZSByZWFkYWJpbGl0eSBvZiBzZWN0aW9uIDMg b3IgbW92ZSB0aGUgQVNDSUkgYXJ0IGZyb20gc2VjdGlvbiA0IGluIHNlY3Rpb24gMyBvciByZW1v dmUgc2VjdGlvbiAzIG9yIC4uLg0KICAqICAgQW55IGNoYW5jZSB0byByZXBsYWNlIHRoZSBIVFRQ IGNhcHRpdmUgcG9ydGFsIGJ5IGEgbW9yZSBzZWN1cmUgSFRUUFMgY2FwdGl2ZSBwb3J0YWwgKGFu ZCBJIGtub3cgdGhlIGlzc3VlIHdpdGggY2VydGlmaWNhdGVzIGFyZSBub3QgZWFzeSkuIE9yIHJl bW92ZSBpdCA9PiB0b28gc3BlY2lmaWMNCg0KSSBhbHNvIGFncmVlIHdpdGg6DQoNCiAgKiAgIExv cmVuem8gJiBUb20gSGVyYmVydDogdGhlIHNjb3BlIGlzIG11Y2ggYnJvYWRlciA9PiB0aGUgSS1E IHNob3VsZCBiZSBtYWRlIGxlc3Mgc3BlY2lmaWMNCiAgKiAgIERhdmlkOiB0aGlzIGhhcyBub3Ro aW5nIHRvIGRvIHdpdGggQUVSTyA6LSkNCg0KRmluYWxseSwgSSBjYW5ub3QgcmVmcmFpbiBmcm9t IHRoaW5raW5nIHRoYXQgdGhlcmUgYXJlIHNldmVyYWwgSS1EIChpbmNsdWRpbmcgdGhpcyBvbmUp IGF0dGVtcHRpbmcgdG8gZml4IE5EUC4uLg0KDQpIb3BlIHRoaXMgaGVscHMNCg0KLcOpcmljDQoN Cg== --_000_D2B2F84663BCCevynckeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5CZWxhdGVkIGNv bW1lbnRzIG9uIHRoaXMgdXNlZnVsIGRyYWZ0Li4uPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGRpdj5JIGFtIGNvbmZ1c2VkIGJ5IHRoZSB3b3JkaW5nIG9mICdJUHY2IG9ubHkgZXhwZXJpZW5j ZSBldmVuIGlmIElQdjQgc3VwcG9ydCBpcyBwcmVzZW50JzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+SXQgYXBwZWFycyB0byBtZSB0aGF0IHRoZSBzZWN1cml0eSBhbW9uZyB1c2VycyBv bmx5IHJlbGllcyBvbiB0aGUgQVAgaW4gaXNvbGF0aW9uIG1vZGUgKG9yIHNwbGl0LWhvcml6b24p Li4uIFRoaXMgbWFrZXMgdGhlIEktRCBtYWlubHkgcmVsZXZhbnQgdG8geW91ciB1c2UgY2FzZSA6 LSg8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pkl0IGlzIG5vdCBjbGVhciB3aGV0aGVy IHRoZSBVRSB3aWxsIGFsd2F5cyByZWNlaXZlIHRoZSBzYW1lIC82NCBldmVuIHdoZW4gJ3JvYW1p bmcnIHdpdGhpbiB0aGUgY29tbXVuaXR5IFdpRmkgYXMgaXQgd291bGQgaGF2ZSBwcml2YWN5IGlt cGxpY2F0aW9ucy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlNlY3Rpb24gNC4zLjIs IGRvIHdlIGhhdmUgZGF0YSBiYWNraW5nIHRoYXQgbW9zdCBPUyBzdGlsbCBkbyBETlMgcmVxdWVz dCBvdmVyIElQdjQ/PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5TZWN0aW9uIDUsIEkg bXVzdCBhZG1pdCB0aGF0IEkgZG8gbm90IHVuZGVyc3RhbmQgd2h5IHRoZSBHVyBoYXMgdG8gc2Vu ZCBwZXJpb2RpYyB1bnNvbGljaXRlZCAodW5pY2FzdCBJIGhvcGUgdG8gZ2V0IHRoZSBXaUZpIEFD SykgUkEuLi4gV2h5IG5vdCB3YWl0IGZvciB0aGUgUlMgYnkgdGhlIFVFPyZuYnNwOzwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+U2VjdGlvbiA1LCB3aGVuIHRoZSBHVyAncGluZ3MnIHRo ZSBVRSwgZG9lcyBpdCB1c2UgSUNNUD8gT3IgcGxhaW4gTlMgPyBDYW4gdGhlIEFQIGxldmVyYWdl IGFueSBXaUZpIHBvbGxpbmc/PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5BIGJpZyAm bmJzcDthZHZhbnRhZ2UgJm5ic3A7KHdoaWNoIGlzIG5vdCBkZXNjcmliZWQpIGlzIHRoYXQgdGhl cmUgd2lsbCBiZSBhIG1pbmltdW0gb2YgTkRQIG11bHRpY2FzdCB0cmFmZmljIHdoaWNoIGlzIGEg cGFpbiBvdmVyIFdpRkkgY2ZyJm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMWVtOyBsaW5l LWhlaWdodDogMHB0OyBmb250LXdlaWdodDogYm9sZDsgd2lkb3dzOiAxOyI+ZHJhZnQtdnluY2tl LTZtYW4tbWNhc3Qtbm90LWVmZmljaWVudC0wMTwvc3Bhbj48L2Rpdj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj5Db3NtZXRpYzo8L2Rpdj4NCjx1bD4NCjxsaT5BU0NJSSBhcnQgdG9w b2xvZ3kgd291bGQgaW5jcmVhc2UgdGhlIHJlYWRhYmlsaXR5IG9mIHNlY3Rpb24gMyBvciBtb3Zl IHRoZSBBU0NJSSBhcnQgZnJvbSBzZWN0aW9uIDQgaW4gc2VjdGlvbiAzIG9yIHJlbW92ZSBzZWN0 aW9uIDMgb3IgLi4uPC9saT48bGk+QW55IGNoYW5jZSB0byByZXBsYWNlIHRoZSBIVFRQIGNhcHRp dmUgcG9ydGFsIGJ5IGEgbW9yZSBzZWN1cmUgSFRUUFMgY2FwdGl2ZSBwb3J0YWwgKGFuZCBJIGtu b3cgdGhlIGlzc3VlIHdpdGggY2VydGlmaWNhdGVzIGFyZSBub3QgZWFzeSkuIE9yIHJlbW92ZSBp dCA9Jmd0OyB0b28gc3BlY2lmaWM8L2xpPjwvdWw+DQo8L2Rpdj4NCjxkaXY+SSBhbHNvIGFncmVl IHdpdGg6PC9kaXY+DQo8dWw+DQo8bGk+TG9yZW56byAmYW1wOyBUb20gSGVyYmVydDogdGhlIHNj b3BlIGlzIG11Y2ggYnJvYWRlciA9Jmd0OyB0aGUgSS1EIHNob3VsZCBiZSBtYWRlIGxlc3Mgc3Bl Y2lmaWM8L2xpPjxsaT5EYXZpZDogdGhpcyBoYXMgbm90aGluZyB0byBkbyB3aXRoIEFFUk8gOi0p PC9saT48L3VsPg0KPGRpdj5GaW5hbGx5LCBJIGNhbm5vdCByZWZyYWluIGZyb20gdGhpbmtpbmcg dGhhdCB0aGVyZSBhcmUgc2V2ZXJhbCBJLUQgKGluY2x1ZGluZyB0aGlzIG9uZSkgYXR0ZW1wdGlu ZyB0byBmaXggTkRQLi4uPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5Ib3BlIHRoaXMg aGVscHM8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pi3DqXJpYzwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D2B2F84663BCCevynckeciscocom_-- From nobody Wed Jan 6 09:33:29 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04E2A1B2DBE for ; Wed, 6 Jan 2016 09:33:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 5oAYjoW2v14d for ; Wed, 6 Jan 2016 09:33:27 -0800 (PST) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.119.20]) by ietfa.amsl.com (Postfix) with ESMTP id 246D71A8A71 for ; Wed, 6 Jan 2016 09:33:27 -0800 (PST) Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com [209.85.213.176]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128/128); for ; Wed, 6 Jan 2016 11:33:25 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ig0-f176.google.com [209.85.213.176] #+LO+TS+TR X-Umn-Classification: local Received: by mail-ig0-f176.google.com with SMTP id z14so15392319igp.1 for ; Wed, 06 Jan 2016 09:33:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=reply-to:subject:references:to:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=RVbq6HcLyLIG/PwOW1fmKu6Ddqrhk+TzKNUJi7k+IFM=; b=GqL5ov8j9XK8UCSzRIpXjfsgwhqi6X8c2YJ37x018rJQtdtp/jvPE8jsFEvTF4kZqk pCSNLCby0g8zW8buB6RZodzs6rf9EMSB91BPKzOkU4/PtLYutlqTN5pelEVGGaHKQXPl PpZFmdwqGjmkI/wWFInfeNva5EQpraLYwRK6I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:cc:from :organization:message-id:date:user-agent:mime-version:in-reply-to :content-type:content-transfer-encoding; bh=RVbq6HcLyLIG/PwOW1fmKu6Ddqrhk+TzKNUJi7k+IFM=; b=lvmf+y56QmJfTgIHQnxIEhRzCK6AcG6rj6tNi4IFDEC0/7k5naxukGP4gXYV+shM4R d2M0i16FC4zKwyAS7FUo7iZoX/3OTRTjGuxO1Keg1gkxtl9fXaLegt664btNDm47LAVQ rk1irrKh16o70wn3dc9gnN+/iIL5YSi5ICQxVVsVjgNPRkui8+UwBycVuyLj7Z0GaiVw D8Syr7CBqjQFQzDwOMQtr8pGmm8MIZJv21Z6h3kkvG/Y+Vm6779Yt/qQG1LHtVE5n735 lm0G9m+46NRxei9ct01Z193Fy/b4SqH9miaNh9Nc4NthJ6L2kSCCbbwtNLhD9W9DCGlH Xy/g== X-Gm-Message-State: ALoCoQmF34b5e8zi1giEslx0BuFOWNB2D4ygD7BNnClGo44jzs7mpadFmqSNDlTX1KtA7aSQ54WECEW/4fh6XeuKelRHx7X1KK1Lhh8D25MUqEuZl9VdCsXHpssyEyr121peCWWByjHYmBvXwe69xGFk5lItMv6Hzw== X-Received: by 10.50.82.97 with SMTP id h1mr9826171igy.67.1452101604966; Wed, 06 Jan 2016 09:33:24 -0800 (PST) X-Received: by 10.50.82.97 with SMTP id h1mr9826154igy.67.1452101604778; Wed, 06 Jan 2016 09:33:24 -0800 (PST) Received: from x-10-104-135-10.uofm-secure.wireless.umn.edu ([2607:ea00:107:2001:3852:be5f:8ef4:4619]) by smtp.gmail.com with ESMTPSA id q5sm3207256igh.6.2016.01.06.09.33.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Jan 2016 09:33:22 -0800 (PST) References: <201601031900.u03J0LMe009763@irp-lnx1.cisco.com> <2134F8430051B64F815C691A62D9831832F988DB@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F99D14@XCH-BLV-504.nw.nos.boeing.com> <6065AA2A-25BB-4B32-B88B-40A856D0E1EA@cisco.com> <2134F8430051B64F815C691A62D9831832F9A0EA@XCH-BLV-504.nw.nos.boeing.com> <568C625A.80808@umn.edu> <2134F8430051B64F815C691A62D9831832F9A12C@XCH-BLV-504.nw.nos.boeing.com> <568C6DA3.5010102@umn.edu> <2134F8430051B64F815C691A62D9831832F9A85C@XCH-BLV-504.nw.nos.boeing.com> To: "Templin, Fred L" , "Fred Baker (fred)" From: David Farmer Organization: University of Minnesota Message-ID: <568D4FE0.9030507@umn.edu> Date: Wed, 6 Jan 2016 11:33:20 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <2134F8430051B64F815C691A62D9831832F9A85C@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" , John Brzozowski Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 17:33:29 -0000 On 1/6/16 09:42 , Templin, Fred L wrote: > Hi David, > >> -----Original Message----- >> From: David Farmer [mailto:farmer@umn.edu] >> Sent: Tuesday, January 05, 2016 5:28 PM >> To: Templin, Fred L; Fred Baker (fred) >> Cc: David Farmer; v6ops@ietf.org; John Brzozowski >> Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host >> >> On 1/5/16 18:46 , Templin, Fred L wrote: >>> Hi David, >>> >>>> -----Original Message----- >>>> From: David Farmer [mailto:farmer@umn.edu] >> ... >>>> In my view AERO and this draft are working in slightly overlapping, but >>>> different solution spaces. >>> >>> We don't know that without a use case analysis. >> >> Well as I read this, this doesn't implement DHCPv6 PD. Furthermore, it >> doesn't need any client software. It uses SLAAC and responds to each >> IPv6 ND Router Solicitation with a unicast Router Advertisement with >> different prefix for each client. It provides DNS server info with >> RADNS and stateless DHCPv6 if the client send a request. > > How would an unmodified client know that the prefix it receives in > a unicast RA is in fact uniquely assigned for the client's exclusive use > and not advertised to any other client? That's the whole point the client doesn't need to know its been uniquely assigned the whole prefix to assign it the whole prefix. The client doesn't actually guarantee the uniqueness anyway. It's perfectly fine for client to be blissfully ignorant of that fact. Don't get me wrong I'm not saying I don't want clients to do DHCPv6 PD, but they just don't have to just to get a whole /64 assigned to them. Are there things the client can do if it knows sure. Should the client know, if it can deal with that knowledge, sure. However, the client doesn't have to know, especially if it doesn't know how to deal with that knowledge anyway. >> The client requirement are just standard SLAAC, and RADNS or stateless >> DHCPv6, that is it. No DHCPv6 PD client needed, am I missing something? > > I think so. An unmodified client receiving a PIO with (A=1, L=0) would have > no way of knowing that the prefix is being delegated for its own exclusive > use and that the prefix would not be advertised to other clients. Why does it have to care? If it cares, it can do DHCPv6 PD, but it doesn't have to. You seem to think it has to care, why? >> There is a bunch of WiFi parts too, just like AERO has tunnel stuff, but >> that is fairly standard WiFi infrastructure bits. > > I thought this work was based on tunneling, too? And, AERO can run fine > over WiFi just the same as over any link-layer technology. The CAPWAP stuff is its own separate thing, already specified. There may be some unique ways it's used here but that's separate, this is the point others have made, and I agree. There is some stuff that needs to be tweezed apart but its a good start. >> So, there is a really quick use case analysis for you and I'll >> reiterate; in my view AERO and this draft are working in slightly >> overlapping, but different solution spaces. > > I don't see how multi-addressing in the spirit of "host-addr-availabiity" > can be supported on an unmodified client. There would need to be > additional specification telling the client what to do when it receives > a PIO with (A=1,L=0). But then, the document becomes a spec and > not an informational. And, clients would have to be modified. I disagree with the first part but agree with at least part of the second part. I'm starting to think that we need a real standards track document not just a BCP, at least for PIO with (A=1, L=0) not because it needs to really fundamentally makes changes. But I'm worried some people will not take this serious without it being standards track. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nobody Wed Jan 6 10:40:18 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 807C41A00C0 for ; Wed, 6 Jan 2016 10:40:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 Cf9NlT6CEbHp for ; Wed, 6 Jan 2016 10:40:10 -0800 (PST) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD7CF1A00BF for ; Wed, 6 Jan 2016 10:40:09 -0800 (PST) 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 u06Ie73k030454; Wed, 6 Jan 2016 12:40:07 -0600 Received: from XCH-BLV-204.nw.nos.boeing.com (xch-blv-204.nw.nos.boeing.com [10.57.37.58]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u06Ie6i1030437 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 6 Jan 2016 12:40:06 -0600 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.52]) by XCH-BLV-204.nw.nos.boeing.com ([169.254.4.253]) with mapi id 14.03.0235.001; Wed, 6 Jan 2016 10:40:06 -0800 From: "Templin, Fred L" To: David Farmer , "Fred Baker (fred)" Thread-Topic: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host Thread-Index: AQHRR+nwI13RUsgT4kOKL/Th7Sw3uJ7uJ54A//962WCAAIlWAP//enSggACTAICAAGZA4IAAp3IA//+GwHA= Date: Wed, 6 Jan 2016 18:40:06 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F9AAF5@XCH-BLV-504.nw.nos.boeing.com> References: <201601031900.u03J0LMe009763@irp-lnx1.cisco.com> <2134F8430051B64F815C691A62D9831832F988DB@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F99D14@XCH-BLV-504.nw.nos.boeing.com> <6065AA2A-25BB-4B32-B88B-40A856D0E1EA@cisco.com> <2134F8430051B64F815C691A62D9831832F9A0EA@XCH-BLV-504.nw.nos.boeing.com> <568C625A.80808@umn.edu> <2134F8430051B64F815C691A62D9831832F9A12C@XCH-BLV-504.nw.nos.boeing.com> <568C6DA3.5010102@umn.edu> <2134F8430051B64F815C691A62D9831832F9A85C@XCH-BLV-504.nw.nos.boeing.com> <568D4FE0.9030507@umn.edu> In-Reply-To: <568D4FE0.9030507@umn.edu> 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: Cc: "v6ops@ietf.org" , John Brzozowski Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 18:40:12 -0000 Hi David, > -----Original Message----- > From: David Farmer [mailto:farmer@umn.edu] > Sent: Wednesday, January 06, 2016 9:33 AM > To: Templin, Fred L; Fred Baker (fred) > Cc: David Farmer; v6ops@ietf.org; John Brzozowski > Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-pre= fix-per-host >=20 > On 1/6/16 09:42 , Templin, Fred L wrote: > > Hi David, > > > >> -----Original Message----- > >> From: David Farmer [mailto:farmer@umn.edu] > >> Sent: Tuesday, January 05, 2016 5:28 PM > >> To: Templin, Fred L; Fred Baker (fred) > >> Cc: David Farmer; v6ops@ietf.org; John Brzozowski > >> Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-= prefix-per-host > >> > >> On 1/5/16 18:46 , Templin, Fred L wrote: > >>> Hi David, > >>> > >>>> -----Original Message----- > >>>> From: David Farmer [mailto:farmer@umn.edu] > >> ... > >>>> In my view AERO and this draft are working in slightly overlapping, = but > >>>> different solution spaces. > >>> > >>> We don't know that without a use case analysis. > >> > >> Well as I read this, this doesn't implement DHCPv6 PD. Furthermore, it > >> doesn't need any client software. It uses SLAAC and responds to each > >> IPv6 ND Router Solicitation with a unicast Router Advertisement with > >> different prefix for each client. It provides DNS server info with > >> RADNS and stateless DHCPv6 if the client send a request. > > > > How would an unmodified client know that the prefix it receives in > > a unicast RA is in fact uniquely assigned for the client's exclusive us= e > > and not advertised to any other client? >=20 > That's the whole point the client doesn't need to know its been uniquely > assigned the whole prefix to assign it the whole prefix. The client > doesn't actually guarantee the uniqueness anyway. It's perfectly fine > for client to be blissfully ignorant of that fact. >=20 > Don't get me wrong I'm not saying I don't want clients to do DHCPv6 PD, > but they just don't have to just to get a whole /64 assigned to them. > Are there things the client can do if it knows sure. Should the client > know, if it can deal with that knowledge, sure. However, the client > doesn't have to know, especially if it doesn't know how to deal with > that knowledge anyway. OK, I see - so, the client (not knowing that the prefix has been delegated for its own exclusive use) autoconfigures addresses from the prefix (because the PIO had A=3D1) and assigns them to the WiFi interface and not to some internal virtual interface. That means that the client needs to send a multicast NS(DAD) over the WiFi interface for every such address that it autoconfigures. That is different than what we have been talking about regarding "host-addr-availability". One thing I see missing in the draft however is that the client also needs to do DAD for its link-local address before it does anything else - right? > >> The client requirement are just standard SLAAC, and RADNS or stateless > >> DHCPv6, that is it. No DHCPv6 PD client needed, am I missing somethin= g? > > > > I think so. An unmodified client receiving a PIO with (A=3D1, L=3D0) wo= uld have > > no way of knowing that the prefix is being delegated for its own exclus= ive > > use and that the prefix would not be advertised to other clients. >=20 > Why does it have to care? If it cares, it can do DHCPv6 PD, but it > doesn't have to. You seem to think it has to care, why? OK, so the base specification calls for the client to do SLAAC autoconfigur= ation of addresses from the advertised prefix and then assign the addresses to th= e WiFi interface after it joins the MLD solicited-node multicast group and se= nds a multicast NS(DAD) for each such address. Again, that is different than wh= at we have been talking about in "host-addr-availability". > >> There is a bunch of WiFi parts too, just like AERO has tunnel stuff, b= ut > >> that is fairly standard WiFi infrastructure bits. > > > > I thought this work was based on tunneling, too? And, AERO can run fine > > over WiFi just the same as over any link-layer technology. >=20 > The CAPWAP stuff is its own separate thing, already specified. There > may be some unique ways it's used here but that's separate, this is the > point others have made, and I agree. There is some stuff that needs to > be tweezed apart but its a good start. >=20 > >> So, there is a really quick use case analysis for you and I'll > >> reiterate; in my view AERO and this draft are working in slightly > >> overlapping, but different solution spaces. > > > > I don't see how multi-addressing in the spirit of "host-addr-availabiit= y" > > can be supported on an unmodified client. There would need to be > > additional specification telling the client what to do when it receives > > a PIO with (A=3D1,L=3D0). But then, the document becomes a spec and > > not an informational. And, clients would have to be modified. >=20 > I disagree with the first part I was referring to the language in "host-addr-availability" that allows the client to assign addresses from the delegated prefix to internal interfaces such as a loopback. For an unmodified client that does not know that it is being granted the entire prefix based on just (A=3D1;L=3D0) in the PIO, that option is not available. So, really, the two documents in question need to be interpreted in a mutually exclusive fashion which I think you indicated in an earlier message. > but agree with at least part of the second part. > I'm starting to think that we need a real standards track > document not just a BCP, at least for PIO with (A=3D1, L=3D0) not because= it > needs to really fundamentally makes changes. But I'm worried some > people will not take this serious without it being standards track. I agree with standards-track, but I thought standards-track documents are out of scope for v6ops? Thanks - Fred fred.l.templin@boeing.com > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > David Farmer Email: farmer@umn.edu > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 1-612-626-0815 > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From nobody Wed Jan 6 10:46:14 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0F01A00E6 for ; Wed, 6 Jan 2016 10:46:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 dSuEOP_XQq_K for ; Wed, 6 Jan 2016 10:45:57 -0800 (PST) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5B881A00E2 for ; Wed, 6 Jan 2016 10:45:57 -0800 (PST) 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 u06Ijv1h021594; Wed, 6 Jan 2016 12:45:57 -0600 Received: from XCH-BLV-502.nw.nos.boeing.com (xch-blv-502.nw.nos.boeing.com [130.247.25.191]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u06IjtCF021578 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 6 Jan 2016 12:45:55 -0600 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.52]) by XCH-BLV-502.nw.nos.boeing.com ([169.254.2.129]) with mapi id 14.03.0235.001; Wed, 6 Jan 2016 10:45:54 -0800 From: "Templin, Fred L" To: David Farmer , "Fred Baker (fred)" Thread-Topic: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host Thread-Index: AQHRR+nwI13RUsgT4kOKL/Th7Sw3uJ7uJ54A//962WCAAIlWAP//enSggACTAICAAGZA4IAAp3IA//+NaAA= Date: Wed, 6 Jan 2016 18:45:54 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F9AB24@XCH-BLV-504.nw.nos.boeing.com> References: <201601031900.u03J0LMe009763@irp-lnx1.cisco.com> <2134F8430051B64F815C691A62D9831832F988DB@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F99D14@XCH-BLV-504.nw.nos.boeing.com> <6065AA2A-25BB-4B32-B88B-40A856D0E1EA@cisco.com> <2134F8430051B64F815C691A62D9831832F9A0EA@XCH-BLV-504.nw.nos.boeing.com> <568C625A.80808@umn.edu> <2134F8430051B64F815C691A62D9831832F9A12C@XCH-BLV-504.nw.nos.boeing.com> <568C6DA3.5010102@umn.edu> <2134F8430051B64F815C691A62D9831832F9A85C@XCH-BLV-504.nw.nos.boeing.com> <568D4FE0.9030507@umn.edu> In-Reply-To: <568D4FE0.9030507@umn.edu> 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: Cc: "v6ops@ietf.org" , John Brzozowski Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 18:46:00 -0000 Hi David, > The CAPWAP stuff is its own separate thing, already specified. You indicated CAPWAP, which is something I asked about a while back. Is the SoftGRE stuff one and the same as CAPWAP, or something different? If different, why not just use CAPWAP? Thanks - Fred fred.l.templin@boeing.com From nobody Wed Jan 6 11:00:21 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 927AA1A00F4 for ; Wed, 6 Jan 2016 11:00:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 qLFL_cMoN_Co for ; Wed, 6 Jan 2016 11:00:17 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EACF1A00EA for ; Wed, 6 Jan 2016 11:00:16 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 988BA60737 for ; Wed, 6 Jan 2016 20:00:14 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id BB1B8602C7 for ; Wed, 6 Jan 2016 20:00:13 +0100 (CET) Received: (qmail 98008 invoked by uid 1007); 6 Jan 2016 20:00:13 +0100 Date: Wed, 6 Jan 2016 20:00:13 +0100 From: Gert Doering To: Lorenzo Colitti Message-ID: <20160106190013.GZ58491@Space.Net> References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 19:00:19 -0000 Hi, On Thu, Jan 07, 2016 at 12:22:54AM +0900, Lorenzo Colitti wrote: > Second: this document has targeted BCP status and has contained the text on > DHCPv6 from the very beginning. It has survived multiple consensus calls in > that form, so I think that the WG has always been happy with those points. I missed that this was intended for BCP, otherwise I would have complained earlier. Haven't seen anyone state that they are deploying DHCPv6-PD to hosts except you, so "CP" is really questionable... For an "Lorenzo does not like DHCPv6 IA_NA" draft, Informational sounds about right. [..] > > Did you look at the ND traffic? Do you expect all traffic from neighboring > > hosts to 2400:2410:20c0:4450::/60 to go through your router instead of > > instead of directly to your laptop? > > > > As for ND - like I said, there's NUD for the link-local address. Traffic > from neighbouring hosts will go through the router, of course - from the > perspective of the router, my laptop is exactly the same as a subtended CPE > router connected to one of its LAN ports, which is a fairly common > configuration today. Again - the point is that as far as the network is > concerned, it doesn't matter if the requesting node is a host or a router, > the behaviour is the same. The network is evolving - especially with homenet, the whole model of cascading DHCPv6-PD CPEs is being abandoned, because there are better ways. > > I think we should be more clear on the 'almost be not quite router > > devices'. Or it will come back to bite us. > > > > Do we? A node is either a host or a router. Most routers are also hosts by necessity of talking IP for their management plane. [..] > We can't do that, because that leaves the problem of what to do on a > network that has decided to provide address space only via DHCPv6. It seems > to me that there has been pretty strong agreement all along that such > networks should also provide sufficient address space to hosts. "just provide multiple addresses with DHCPv6 IA_NA"? Is actually quite a bit easier to roll out than "build a DHCPv6 PD infrastructure"... memory on the DHCPv6 server is cheap, slots on routers are expensive. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Wed Jan 6 11:39:15 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1E71A016E for ; Wed, 6 Jan 2016 11:39:14 -0800 (PST) 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 09AsMtqSiG6n for ; Wed, 6 Jan 2016 11:39:12 -0800 (PST) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EBC01A0173 for ; Wed, 6 Jan 2016 11:39:12 -0800 (PST) Received: by mail-pa0-x231.google.com with SMTP id cy9so238491008pac.0 for ; Wed, 06 Jan 2016 11:39:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=wKbYIPQWh4pXhXU12jekTF9RAscmeRCFuuYFpGQRYgI=; b=kJZJNLh0dR+vpu2aNIn1JS01Rofj5DoiXrF+mP0qG+cnPXi5urkCi9hQ9huWPdS0/b l6mtP7FRDfAjvz0R5SnQ0M67flahl8XeL4RhIlmBHc8Sbw/WW4VnVF0f5hMb4uPgc87x RW9rhm3xdA2zbwEAn+n+T8AJPS6tX57OD8BxFsy7U1DpLOBigCUKHG2ABRUa+mpR+ytI jTZjpXndvizZIeicudd5dBYKnKFGdO+ZlsNNX1hFuG8rRDiCRxDueKLQ1IivFJOVOHjU 8oiz/vA1OGHBGJFtRzNNnQfFUnPlzEUZyHOGv6BVhQTyLBr3y76X4auvhWCCu6dS97uq 9zJA== X-Received: by 10.66.117.199 with SMTP id kg7mr144778649pab.105.1452109151790; Wed, 06 Jan 2016 11:39:11 -0800 (PST) Received: from ?IPv6:2406:e007:4e11:1:28cc:dc4c:9703:6781? ([2406:e007:4e11:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id r83sm75684808pfa.13.2016.01.06.11.39.08 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Jan 2016 11:39:09 -0800 (PST) To: Gert Doering , Lorenzo Colitti References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <20160106190013.GZ58491@Space.Net> From: Brian E Carpenter Organization: University of Auckland Message-ID: <568D6D73.9090109@gmail.com> Date: Thu, 7 Jan 2016 08:39:31 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160106190013.GZ58491@Space.Net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 19:39:14 -0000 On 07/01/2016 08:00, Gert Doering wrote: > Hi, > > On Thu, Jan 07, 2016 at 12:22:54AM +0900, Lorenzo Colitti wrote: >> Second: this document has targeted BCP status and has contained the text on >> DHCPv6 from the very beginning. It has survived multiple consensus calls in >> that form, so I think that the WG has always been happy with those points. > > I missed that this was intended for BCP, otherwise I would have complained > earlier. Haven't seen anyone state that they are deploying DHCPv6-PD to > hosts except you, so "CP" is really questionable... > > For an "Lorenzo does not like DHCPv6 IA_NA" draft, Informational sounds > about right. That seems to be a misunderstanding of the main point of the draft. PD is incidental to that, surely? I agree that PD is far from the only implementation mechanism. Brian > > [..] >>> Did you look at the ND traffic? Do you expect all traffic from neighboring >>> hosts to 2400:2410:20c0:4450::/60 to go through your router instead of >>> instead of directly to your laptop? >>> >> >> As for ND - like I said, there's NUD for the link-local address. Traffic >> from neighbouring hosts will go through the router, of course - from the >> perspective of the router, my laptop is exactly the same as a subtended CPE >> router connected to one of its LAN ports, which is a fairly common >> configuration today. Again - the point is that as far as the network is >> concerned, it doesn't matter if the requesting node is a host or a router, >> the behaviour is the same. > > The network is evolving - especially with homenet, the whole model of > cascading DHCPv6-PD CPEs is being abandoned, because there are better ways. > >>> I think we should be more clear on the 'almost be not quite router >>> devices'. Or it will come back to bite us. >>> >> >> Do we? A node is either a host or a router. > > Most routers are also hosts by necessity of talking IP for their > management plane. > > [..] >> We can't do that, because that leaves the problem of what to do on a >> network that has decided to provide address space only via DHCPv6. It seems >> to me that there has been pretty strong agreement all along that such >> networks should also provide sufficient address space to hosts. > > "just provide multiple addresses with DHCPv6 IA_NA"? > > Is actually quite a bit easier to roll out than "build a DHCPv6 PD > infrastructure"... memory on the DHCPv6 server is cheap, slots on routers > are expensive. > > Gert Doering > -- NetMaster > From nobody Wed Jan 6 11:57:23 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B301A0193 for ; Wed, 6 Jan 2016 11:57:21 -0800 (PST) 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, 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 nvHu2yRgjQ1d for ; Wed, 6 Jan 2016 11:57:20 -0800 (PST) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F11881A0126 for ; Wed, 6 Jan 2016 11:57:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u06JvJuI017936; Wed, 6 Jan 2016 12:57:19 -0700 Received: from XCH-BLV-507.nw.nos.boeing.com (xch-blv-507.nw.nos.boeing.com [130.247.25.197]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u06JvF6i017830 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 6 Jan 2016 12:57:16 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.52]) by XCH-BLV-507.nw.nos.boeing.com ([169.254.7.124]) with mapi id 14.03.0235.001; Wed, 6 Jan 2016 11:57:14 -0800 From: "Templin, Fred L" To: Gert Doering , Lorenzo Colitti Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt Thread-Index: AQHRSLxwfNHq+OP6OEuJ9r9JCuau7A== Date: Wed, 6 Jan 2016 19:57:14 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F9ADA0@XCH-BLV-504.nw.nos.boeing.com> References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <20160106190013.GZ58491@Space.Net> In-Reply-To: <20160106190013.GZ58491@Space.Net> 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: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 19:57:22 -0000 Hi Gert, > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Gert Doering > Sent: Wednesday, January 06, 2016 11:00 AM > To: Lorenzo Colitti > Cc: v6ops@ietf.org WG > Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-= 04.txt >=20 > Hi, >=20 > On Thu, Jan 07, 2016 at 12:22:54AM +0900, Lorenzo Colitti wrote: > > Second: this document has targeted BCP status and has contained the tex= t on > > DHCPv6 from the very beginning. It has survived multiple consensus call= s in > > that form, so I think that the WG has always been happy with those poin= ts. >=20 > I missed that this was intended for BCP, otherwise I would have complaine= d > earlier. Haven't seen anyone state that they are deploying DHCPv6-PD to > hosts except you, so "CP" is really questionable... I have also been talking about PD for hosts: https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/ > For an "Lorenzo does not like DHCPv6 IA_NA" draft, Informational sounds > about right. >=20 > [..] > > > Did you look at the ND traffic? Do you expect all traffic from neighb= oring > > > hosts to 2400:2410:20c0:4450::/60 to go through your router instead o= f > > > instead of directly to your laptop? > > > > > > > As for ND - like I said, there's NUD for the link-local address. Traffi= c > > from neighbouring hosts will go through the router, of course - from th= e > > perspective of the router, my laptop is exactly the same as a subtended= CPE > > router connected to one of its LAN ports, which is a fairly common > > configuration today. Again - the point is that as far as the network is > > concerned, it doesn't matter if the requesting node is a host or a rout= er, > > the behaviour is the same. >=20 > The network is evolving - especially with homenet, the whole model of > cascading DHCPv6-PD CPEs is being abandoned, because there are better way= s. > > > > I think we should be more clear on the 'almost be not quite router > > > devices'. Or it will come back to bite us. > > > > > > > Do we? A node is either a host or a router. >=20 > Most routers are also hosts by necessity of talking IP for their > management plane. >=20 > [..] > > We can't do that, because that leaves the problem of what to do on a > > network that has decided to provide address space only via DHCPv6. It s= eems > > to me that there has been pretty strong agreement all along that such > > networks should also provide sufficient address space to hosts. >=20 > "just provide multiple addresses with DHCPv6 IA_NA"? As we have been saying, this could result in lots of multicast ND messaging on the link over which the IA_NAs are received when clients configure lots of addresses. It is also incompatible withclient mobility,. > Is actually quite a bit easier to roll out than "build a DHCPv6 PD > infrastructure"... memory on the DHCPv6 server is cheap, slots on routers > are expensive. It depends on the service needed by the clients and the deployment of criti= cal infrastructure in the network. If the clients are mobile, they need to be t= racked in some kind of routing system. The best way to do that is to have a delega= ted prefix that travels with the client wherever it goes. If the routing tables= are spread over many routers in the network (i.e., instead of concentrated with= in just one or a few routers) then each router will only need to handle a frac= tion of the mobile client user base, and load balancing and fault tolerance are supported. Thanks - Fred fred.l.templin@boeing.com > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? >=20 > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culema= nn > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Jan 6 12:02:14 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B481A01A9 for ; Wed, 6 Jan 2016 12:02:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 ndDIkN6jnf_q for ; Wed, 6 Jan 2016 12:02:11 -0800 (PST) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F4921A01A2 for ; Wed, 6 Jan 2016 12:01:56 -0800 (PST) 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 u06K1tJx018160; Wed, 6 Jan 2016 14:01:55 -0600 Received: from XCH-PHX-411.sw.nos.boeing.com (xch-phx-411.sw.nos.boeing.com [10.57.37.42]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u06K1qh6018141 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 6 Jan 2016 14:01:52 -0600 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.52]) by XCH-PHX-411.sw.nos.boeing.com ([169.254.11.36]) with mapi id 14.03.0235.001; Wed, 6 Jan 2016 12:01:51 -0800 From: "Templin, Fred L" To: "draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org" Thread-Topic: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host Thread-Index: AQHRRrIFI13RUsgT4kOKL/Th7Sw3uJ7vFi6A///VyTA= Date: Wed, 6 Jan 2016 20:01:51 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F9ADDE@XCH-BLV-504.nw.nos.boeing.com> References: <201601031900.u03J0LMe009763@irp-lnx1.cisco.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: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 20:02:12 -0000 SSBoYXZlIHdoYXQgSSBob3BlIHdpbGwgYmUgYSBzaW1wbGUgcXVlc3Rpb246IHdoYXQgaWYgdHdv IG9yIG1vcmUgVUVzIGNvbmZpZ3VyZQ0KaWRlbnRpY2FsIElQdjYgbGluay1sb2NhbCBhZGRyZXNz ZXMgLSB3aWxsIHRoZSBXTEFOLUdXIGJlIGFibGUgdG8gdGVsbCB0aGVtIGFwYXJ0Pw0KQXNrZWQg YW5vdGhlciB3YXksIHdoYXQga2luZCBvZiB1bmlxdWUgbm9kZSBpZGVudGlmaWVyIGRvZXMgdGhl IFdMQU4tR1cNCmV4cGVjdCBlYWNoIFVFIHRvIHByb3ZpZGUgaW4gdGhlIGluaXRpYWwgUlM/DQoN ClRoYW5rcyAtIEZyZWQNCmZyZWQubC50ZW1wbGluQGJvZWluZy5jb20NCg== From nobody Wed Jan 6 13:21:03 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4821A1A28 for ; Wed, 6 Jan 2016 13:21:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 mmJhYFhLs_3w for ; Wed, 6 Jan 2016 13:21:01 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 404EA1A1A17 for ; Wed, 6 Jan 2016 13:21:00 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 1BE5F60788 for ; Wed, 6 Jan 2016 22:20:59 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id E93B060352 for ; Wed, 6 Jan 2016 22:20:58 +0100 (CET) Received: (qmail 2648 invoked by uid 1007); 6 Jan 2016 22:20:58 +0100 Date: Wed, 6 Jan 2016 22:20:58 +0100 From: Gert Doering To: "Templin, Fred L" Message-ID: <20160106212058.GA58491@Space.Net> References: <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <20160106190013.GZ58491@Space.Net> <2134F8430051B64F815C691A62D9831832F9ADA0@XCH-BLV-504.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Aym+Xj7/WQ8n9Mht" Content-Disposition: inline In-Reply-To: <2134F8430051B64F815C691A62D9831832F9ADA0@XCH-BLV-504.nw.nos.boeing.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 21:21:03 -0000 --Aym+Xj7/WQ8n9Mht Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Jan 06, 2016 at 07:57:14PM +0000, Templin, Fred L wrote: > As we have been saying, this could result in lots of multicast ND messagi= ng > on the link over which the IA_NAs are received when clients configure lots > of addresses. It is also incompatible withclient mobility,. Supposedly multicast is one of the strong points of IPv6, and for mobility, there is mobile IPv6. If we think that these are all historic errors, and the future is IPv6 over GRE (or LISP), maybe we should make this more clear. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --Aym+Xj7/WQ8n9Mht Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVo2FOt9WwGXkzn/FAQKufA/9GaWwhHII1j0MHg9MHSZMryCNts5wGmMg dPAx4tH7UDAV2XW/L+2HrTOzsFJsOrfSImL1Z+ZlOuQMzP11fnmpb9gBDkG1qOx/ O9zZyDFzXcApI5Fad6IoaTp5GsuvI7Lm2NQ4w/sijDcxwi+TXVk7n5rFT3HMgeQK +Vcma4+VwUOQRbffqKGgDvS+PCGf3+puULyLtcn+3Hzl+XlnJFG+b5c5Xi8MpNmo Znx144RapRiwj+JrmnWdqqUNVKZ9m3YG+e38PRDrTo6b+MUxsZZYFEFvu8WZY9TP 4EMEMS6haxuHwdWSoyBiV41cGLl6pUlFr5QTX5fm4OtrQROJH2Ek8coVczoYM6Bt JI2/VA4vjJGk9UvuPextGIUM9msy4xTxzDljx79PwRdbSNFlgyhNhTVUhk3JVYd8 VJTSf1nAgZL/NV1Ggef9iPk6q1HilX64kgcxoOf7yuk90SlA35bsEtV2sw44oByt lwKuXYsw0tcRjsgrRP1KVVoVTcEY/5tdwZIFCVyJmTAbvfMi/Nc/n9EQcEFHCGvb OjvD0za6H2tGVeCqFzjBK/LbTOy2WqLsHOaCzk2TAwyj92SIlrnM6DTcvD9tmZKa YpGlO2u482Y4jdavcq+PLcE1lqdmrrZdLhuZQlR1P+5sF2LmrJ/N5kYPYrM+YWIo v75rGgzGR9I= =tdzU -----END PGP SIGNATURE----- --Aym+Xj7/WQ8n9Mht-- From nobody Wed Jan 6 13:24:16 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9011A1A30 for ; Wed, 6 Jan 2016 13:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.098 X-Spam-Level: X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gaZFEhAEHtdC for ; Wed, 6 Jan 2016 13:24:14 -0800 (PST) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0426D1A1A20 for ; Wed, 6 Jan 2016 13:24:14 -0800 (PST) Received: by mail-vk0-x230.google.com with SMTP id i129so25437327vkb.0 for ; Wed, 06 Jan 2016 13:24:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=bOeAOTH4DdxfcgmTrcD7g3vDXqzz8x/szndK2wVr2+A=; b=bLmd+L8sGIkJgeQbIIPPHl6nj72QPLKw4N8YrdY6H/VfuW/06+MPu9T+GTquP20rbN d8fv9ZbRGFYDP3aJQ8JRVEktu5otVSovZy5a9kc8LM8u932TrOyZPif6YQ41JNPnnRFa HZADZe+7M/f/SBu5IaHDHe4BoulB6dbPhMqkhZLId/lmXj/lXEGbDVzcgAetP9SEeKLe g8QYYgQ13qhKoB3UD9wfa5cTlIKS3KIfjHRQuqwqjjFh2y/zcatTfPuL6PjqBqNsls9N 3wNotnehtp5OrQ7/+Hszm42KkE0FqaQREmo2cXudZXPLC7gFMXqG/UeaHFS5n2SxPYIc fCVw== MIME-Version: 1.0 X-Received: by 10.31.6.143 with SMTP id 137mr71807082vkg.133.1452115453063; Wed, 06 Jan 2016 13:24:13 -0800 (PST) Received: by 10.103.99.1 with HTTP; Wed, 6 Jan 2016 13:24:12 -0800 (PST) Received: by 10.103.99.1 with HTTP; Wed, 6 Jan 2016 13:24:12 -0800 (PST) Date: Thu, 7 Jan 2016 08:24:12 +1100 Message-ID: From: Mark Smith To: Fred L Templin Content-Type: multipart/alternative; boundary=001a1143d338c0b6d80528b0f91c Archived-At: Cc: "v6ops@ietf.org WG" Subject: [v6ops] Routers are hosts too! (Re: I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 21:24:15 -0000 --001a1143d338c0b6d80528b0f91c Content-Type: text/plain; charset=UTF-8 I think people might be getting a bit caught in the trap of thinking the separation between hosts and routers is a much stronger than it is. Routers are universally hosts too. The distinction between a router and a host is that a router will also accept packets not sent to addresses assigned to the devices interfaces. It will then see what to do with them according to the route table, sending the packet where ever the route table says or dropping them. That is all that makes it a router. Routers are hosts too if there is anything at all above the IP layer that locally receives or locally originates packets using the router's IP addresses. So SNMP agents, ssh/telnet daemons and even BGP, OSPF and DHCPv6 processes are host processes. People say there isn't much or any experience with hosts using addresses assigned via DHCPv6-PD. I don't agree, because every residential IPv6 CPE supporting DHCPv6 that is acquiring addresses via DHCPv6-PD, DNS settings, getting time via NTP or providing a web administrative interface is a host too. Take one of these CPE, disable the LAN interface, attach a screen, keyboard and mouse, and run a spreadsheet or web browser on it and you have the type of host being discussed. The only way for a router not to be a host would be if it specially didn't listen for packets addressed to its own addresses, so that all it ever did was forward non-local packets. You have no monitoring of it, no routing protocols, and would have to configure it via a serial cable. Mark. --001a1143d338c0b6d80528b0f91c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I think people might be getting a bit caught in the trap of = thinking the separation between hosts and routers is a much stronger than i= t is.

Routers are universally hosts too. The distinction between a= router and a host is that a router will also accept packets not sent to ad= dresses assigned to the devices interfaces. It will then see what to do wit= h them according to the route table, sending the packet where ever the=C2= =A0 route table says or dropping them. That is all that makes it a router.<= /p>

Routers are hosts too if there is anything at all above the = IP layer that locally receives or locally originates packets using the rout= er's IP addresses. So SNMP agents, ssh/telnet daemons and even BGP, OSP= F and DHCPv6 processes are host processes.

People say there isn't much or any experience with hosts= using addresses assigned via DHCPv6-PD. I don't agree, because every r= esidential IPv6 CPE supporting DHCPv6 that is acquiring addresses via DHCPv= 6-PD, DNS settings, getting time via NTP or providing a web administrative = interface is a host too.

Take one of these CPE, disable the LAN interface, attach a s= creen, keyboard and mouse, and run a spreadsheet or web browser on it and y= ou have the type of host being discussed.

The only way for a router not to be a host would be if it sp= ecially didn't listen for packets addressed to its own addresses, so th= at all it ever did was forward non-local packets. You have no monitoring of= it, no routing protocols, and would have to configure it via a serial cabl= e.

Mark.

--001a1143d338c0b6d80528b0f91c-- From nobody Wed Jan 6 13:47:12 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 215521A1A83 for ; Wed, 6 Jan 2016 13:47:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 gBaHIfe-MTcM for ; Wed, 6 Jan 2016 13:47:10 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 213AC1A1A72 for ; Wed, 6 Jan 2016 13:47:10 -0800 (PST) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u06LkRiK004404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 6 Jan 2016 13:46:28 -0800 (PST) To: Mark Smith , Fred L Templin References: From: Joe Touch Message-ID: <568D8B33.1060301@isi.edu> Date: Wed, 6 Jan 2016 13:46:27 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u06LkRiK004404 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Routers are hosts too! (Re: I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 21:47:11 -0000 +1 (and then some) AFAICT: - a host is an Internet device that sources or sinks packets - a router is an Internet device that *also* relays packets It may be possible to implement a router that never acts as a host, but that requires it never participate actively in routing protocols, IP signalling, etc. Joe On 1/6/2016 1:24 PM, Mark Smith wrote: > Routers are universally hosts too. The distinction between a router and > a host is that a router will also accept packets not sent to addresses > assigned to the devices interfaces. It will then see what to do with > them according to the route table, sending the packet where ever the > route table says or dropping them. That is all that makes it a router. From nobody Wed Jan 6 13:50:30 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0561A1AB6 for ; Wed, 6 Jan 2016 13:50:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 WuAxUOp3LE3Y for ; Wed, 6 Jan 2016 13:50:28 -0800 (PST) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.119.220]) by ietfa.amsl.com (Postfix) with ESMTP id C7CB61A1AB3 for ; Wed, 6 Jan 2016 13:50:27 -0800 (PST) Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com [209.85.213.181]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128/128); for ; Wed, 6 Jan 2016 15:50:24 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ig0-f181.google.com [209.85.213.181] #+LO+TS+TR X-Umn-Classification: local Received: by mail-ig0-f181.google.com with SMTP id mw1so41588464igb.1 for ; Wed, 06 Jan 2016 13:50:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=reply-to:subject:references:to:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=4WV5QUQxsGoRwPSUD/FafLVwSq1qacI3xTSp+h7mPww=; b=j+fiSoA4izAG7e8oazbfr6XYJd/vZkH/+rh9Ypi5ERUWNLphRaYnCT+RVYccAxhHdj OezQx3IJ3mc0AQo7fMP29Zet72DrzOmlswvmxpecMfrwQX2E1Q3dtcYXc6GWHB1TJlNY GO7RtCJSA7WmAogMtV4nLBf0SBqLmaTQTmw5U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:cc:from :organization:message-id:date:user-agent:mime-version:in-reply-to :content-type:content-transfer-encoding; bh=4WV5QUQxsGoRwPSUD/FafLVwSq1qacI3xTSp+h7mPww=; b=H+gZ9HAV5a78QRdkGV7FwStfb+Hk8Us1rSM47/fqvQ70oMqvxYCInZwEu6DVAmj2OG JG55soqVv6HvHcfVDbR9ZqcCzaskFO0MFy2hkt6yDJk6TCVmAx5dgSSzyJi0f8PmG2F7 ptnnGBr12x6Q1F+C8kTXPEpDtYTJ0q4NEcd8/SiBQbUzILa8GNywTOQHI1pp+JT/N1qv mEPknUToPLSKHJVnienZ2BOTBNRPJ8iKvPwlL0YMdoGiSd/4XvLWefPdqDgT/OjQWKyQ HPnDtY6W/mBHGB3RNkXTCQIJDreo8V3d8PboTRRWXP35XPAcbza1oZzR8/1bl6K3dswi HrLw== X-Gm-Message-State: ALoCoQmtT9T685Ks8+F/EtbzNM5fNgMveh4K9ZMNVn7JN/bAXeJatCWPJHvWG/xVthxdAiB2iwy7BVg+i0bAEbgyH4B1QHXBj/QaBwUIn5qZYkPrZzb+Z4NdsNayJ/aY4MtTSy4fGU/pEY1E4TuMX4bAQdKRJdRBSQ== X-Received: by 10.50.102.69 with SMTP id fm5mr11527864igb.24.1452117023913; Wed, 06 Jan 2016 13:50:23 -0800 (PST) X-Received: by 10.50.102.69 with SMTP id fm5mr11527842igb.24.1452117023732; Wed, 06 Jan 2016 13:50:23 -0800 (PST) Received: from x-10-104-143-225.uofm-secure.wireless.umn.edu ([2607:ea00:107:2001:e87a:3657:26ff:7144]) by smtp.gmail.com with ESMTPSA id c67sm29887782iod.5.2016.01.06.13.50.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Jan 2016 13:50:22 -0800 (PST) References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> To: Erik Kline , Philip Homburg From: David Farmer Organization: University of Minnesota Message-ID: <568D8C1C.2020406@umn.edu> Date: Wed, 6 Jan 2016 15:50:20 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 21:50:29 -0000 On 1/6/16 07:33 , Erik Kline wrote: > On 6 January 2016 at 22:04, Philip Homburg wrote: >>> I think instead we can publish this as is, and in future v6ops can >>> look at a document describing host PD implementation and network >>> operations experience, if such a document even proves necessary (which >>> I doubt). >> >> I don't think we should write a BCP and then in a future document >> describe how it works. That's not what a BCP is for. >> >> If the PD part is not required for this document, then just remove it. > > I disagree. PD is a perfectly valid way of addressing the issue and > it needs to be included at some level of description for completeness. I agree DHCPv6 PD needs to be included and should not be removed. However, lets look at the recommendation section. ... If the network requires explicit requests for address space (e.g., if it requires DHCPv6 to connect), it is RECOMMENDED that the network assign a /64 prefix to every host (e.g., via DHCPv6 PD). Using DHCPv6 IA_NA or IA_TA to request a sufficient number of addresses (e.g. 32) would accommodate current clients but sets a limit on the number of addresses available to hosts when they attach and would limit the development of future applications. ... This is could be interpreted as saying that networks SHOULD NOT use Stateful DHCPv6 for which there is a clear and unambiguous specification for Stateful DHCPv6 host behavior, and they should use DHCPv6 PD for which there is NOT a clear and unambiguous specification for DHCPv6 PD host behavior. However, there is a clear and unambiguous specification for DHCPv6 PD router behavior, but the importance of this distinction is debatable. What if the recommendation section was rewritten making the DHCP v6 PD part permissive and not a normative recommendation. 8. Recommendations In order to avoid the problems described above, and preserve the Internet's ability to support new applications that use more than one IPv6 address, it is RECOMMENDED that IPv6 network deployments provide multiple IPv6 addresses from each prefix to general-purpose hosts when they connect to the network. To support future use cases, it is RECOMMENDED to not impose a hard limit on the size of the address pool assigned to a host. If the network requires explicit requests for address space (e.g., if it requires DHCPv6 to connect), the network MAY assign a /64 prefix to every host (e.g., via DHCPv6 PD). Using DHCPv6 IA_NA or IA_TA to request a sufficient number of addresses (e.g. 32) would accommodate current clients but sets a limit on the number of addresses available to hosts when they attach and would limit the development of future applications. Assigning prefixes longer than a /64 will limit the flexibility of the host to further assign addresses to any internal functions, virtual machines, or downstream clients that require address space - for example, by not allowing the use of SLAAC. In some ways I like this better, it more clearly says /64 per host is only an option. The previous language formed as a conditional recommendation, which was confusing in my opinion. What do others think? -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nobody Wed Jan 6 14:32:47 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3AF1A1B17 for ; Wed, 6 Jan 2016 14:32:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 6rLPH5J1u_N5 for ; Wed, 6 Jan 2016 14:32:44 -0800 (PST) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.119.20]) by ietfa.amsl.com (Postfix) with ESMTP id C0BE81A1B0E for ; Wed, 6 Jan 2016 14:32:44 -0800 (PST) Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com [209.85.213.181]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128/128); for ; Wed, 6 Jan 2016 16:32:43 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ig0-f181.google.com [209.85.213.181] #+LO+TS+TR X-Umn-Classification: local Received: by mail-ig0-f181.google.com with SMTP id z14so38628754igp.0 for ; Wed, 06 Jan 2016 14:32:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=reply-to:subject:references:to:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=14yqhI7mDpVkvlM9SLxlJaJHUFIoTYiOgNH96HC3uV4=; b=KBSdEvP8NuKkpgXw4gBrs04zfc1YHuIbFCl3Od4MPQAZNm2EY1akZgeCVMaWQrybVD RH4Ncwl1g4xn2Off5L6CyrZDZJFpwDyDhI2PCqdAXSZwore767MmhqjtBmakgYfSW/Lg yVRaOI3BA3OpTcc2S9muRJOBB83We1fDFDy2Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:cc:from :organization:message-id:date:user-agent:mime-version:in-reply-to :content-type:content-transfer-encoding; bh=14yqhI7mDpVkvlM9SLxlJaJHUFIoTYiOgNH96HC3uV4=; b=VSUNL77iD8TSrDPN35BzfNbOK43BOWJ4oGeawNwUba4cD5JCB7IwrlLWamU2kUuXb5 2/Pc3fp+CmpKjd/iKJ9GBWBwMi8ZYN9dgrt7EIMDllVhiTpkcihaYrU0zArU99QtQADM SEI+B/5QGP8Yb1s6HVQjrq6LGoXfJvHe98JYZPaIntuNVpVwajiaRa4ZWL9YuEiAgQjd FmVRIYM7zoTuQL9yVUzKyXVE5cn6BiHlXlZEAZ8zs4bLYaagBCG1O+YTZiCGWDDq50Aq FTL8Xck/PC96GNVn9UEB8xuc/9qa/LxOuWTMhCinU05WMAWZZCv21QodZ4LDlEHVD9NV aqQg== X-Gm-Message-State: ALoCoQkbN3OTUNtioHr1kb8E80UR2qNQGLSYnQJ+trMsgUsOZHcEjKKE3NUF4H+UN7llQnEe41fWmLdgfLNK6EuaidPtiuSI3PmyG/YfizyiODbcwy2BNLAilfPl8ja0QYJLEQw457nY72zNFzh46n3EdPXi6h3PEw== X-Received: by 10.50.160.43 with SMTP id xh11mr10907219igb.73.1452119562712; Wed, 06 Jan 2016 14:32:42 -0800 (PST) X-Received: by 10.50.160.43 with SMTP id xh11mr10907199igb.73.1452119562556; Wed, 06 Jan 2016 14:32:42 -0800 (PST) Received: from x-10-104-143-225.uofm-secure.wireless.umn.edu ([2607:ea00:107:2001:e87a:3657:26ff:7144]) by smtp.gmail.com with ESMTPSA id j38sm27036683ioi.33.2016.01.06.14.32.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Jan 2016 14:32:40 -0800 (PST) References: <201601031900.u03J0LMe009763@irp-lnx1.cisco.com> <2134F8430051B64F815C691A62D9831832F988DB@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F99D14@XCH-BLV-504.nw.nos.boeing.com> <6065AA2A-25BB-4B32-B88B-40A856D0E1EA@cisco.com> <2134F8430051B64F815C691A62D9831832F9A0EA@XCH-BLV-504.nw.nos.boeing.com> <568C625A.80808@umn.edu> <2134F8430051B64F815C691A62D9831832F9A12C@XCH-BLV-504.nw.nos.boeing.com> <568C6DA3.5010102@umn.edu> <2134F8430051B64F815C691A62D9831832F9A85C@XCH-BLV-504.nw.nos.boeing.com> <568D4FE0.9030507@umn.edu> <2134F8430051B64F815C691A62D9831832F9AB24@XCH-BLV-504.nw.nos.boeing.com> To: "Templin, Fred L" , "Fred Baker (fred)" From: David Farmer Organization: University of Minnesota Message-ID: <568D9606.2070101@umn.edu> Date: Wed, 6 Jan 2016 16:32:38 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <2134F8430051B64F815C691A62D9831832F9AB24@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" , John Brzozowski Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 22:32:46 -0000 On 1/6/16 12:45 , Templin, Fred L wrote: > Hi David, > >> The CAPWAP stuff is its own separate thing, already specified. > > You indicated CAPWAP, which is something I asked about a while back. Is > the SoftGRE stuff one and the same as CAPWAP, or something different? > If different, why not just use CAPWAP? Sorry, I guess I misspoke, right SoftGRE. :) SoftGRE, EoGRE, CAPWAP, etc... are all more or less equivalent in my mind, a tunneling overlay technology of some kind. Personally, I prefer to VXLAN these days, but YMMV. The IPv6 bits are what interested me, and obviously what I paid attention too. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nobody Wed Jan 6 14:54:19 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E11071A1B73 for ; Wed, 6 Jan 2016 14:54:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 G6ALNkqY1VHr for ; Wed, 6 Jan 2016 14:54:15 -0800 (PST) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.119.220]) by ietfa.amsl.com (Postfix) with ESMTP id BC4B01A1B6D for ; Wed, 6 Jan 2016 14:54:15 -0800 (PST) Received: from mail-io0-f172.google.com (mail-io0-f172.google.com [209.85.223.172]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128/128); for ; Wed, 6 Jan 2016 16:54:12 -0600 (CST) X-Umn-Remote-Mta: [N] mail-io0-f172.google.com [209.85.223.172] #+LO+TS+TR X-Umn-Classification: local Received: by mail-io0-f172.google.com with SMTP id q21so233552497iod.0 for ; Wed, 06 Jan 2016 14:54:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=reply-to:subject:references:to:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=M3hvPnPbQ37gv0j3h+AeeoiNsLBcheU27aHQjOgu3YU=; b=cUrhgejqUSVYyXxPaUF/3kUmLr0HFq22egiDDXA9Wdn9g8OzgdBf2DpZPY8FW8GETK 4DZxaHCMJ3uoW6IlXXp1rY3gfo8iJ1bhHornjuE2uPuBabXYGiaMvGBnoXWRl2JKsHzR 13RDHNDor2Bnw/chnhN9OH82QTc1IhhbbOv88= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:cc:from :organization:message-id:date:user-agent:mime-version:in-reply-to :content-type:content-transfer-encoding; bh=M3hvPnPbQ37gv0j3h+AeeoiNsLBcheU27aHQjOgu3YU=; b=ZrVRuf3zEhOSTtKKB8Go3FJBg37RBIlm6b/KzfT8Hm0mDv1huYhjK+z7ggBhriwX74 iPPtkpum7Ez5Vl49vQLaVJQ+1WSLtGzkuxPjVh85B7JZNcOF3i4WIfAA4RdqfPVJt9jF Jol8bjjdLsJA6VxnT2DZdU0Ahj1ZLVto83EqlbuWKsQQOQQIaLi1Ws75yyV/lDl9ks4w kaijuIWbSGmzSmsn9tVgaA8zoKTt6OzZ+VlTDhJQH+p57GRLiZY8I2tOo8FuLwB9FW18 SzBRDIXZv9/3PSwcFJ7rU51BSH9qp3IIrWCJn3Faiw0FQcCSJDeTByMHyG8Kgm4SqmSq 59Yw== X-Gm-Message-State: ALoCoQk4fImbo21NS9eC52PYUNsdgwpyIoisHiAWbn+k+H7eA4Cjs9eucjv57DFw21PlE96kQOraCGhuQ22Mwy0FEAUQnvUgZQhvWpujXQ+VfaYWS6Eki070FrcGsbTdAoJD88wviQSSsaXWH4FFe7eNl0OtRWHMEA== X-Received: by 10.107.2.198 with SMTP id 189mr88181412ioc.173.1452120851681; Wed, 06 Jan 2016 14:54:11 -0800 (PST) X-Received: by 10.107.2.198 with SMTP id 189mr88181400ioc.173.1452120851516; Wed, 06 Jan 2016 14:54:11 -0800 (PST) Received: from x-10-104-143-225.uofm-secure.wireless.umn.edu ([2607:ea00:107:2001:e87a:3657:26ff:7144]) by smtp.gmail.com with ESMTPSA id ax5sm3682346igc.13.2016.01.06.14.54.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Jan 2016 14:54:10 -0800 (PST) References: <201601031900.u03J0LMe009763@irp-lnx1.cisco.com> <2134F8430051B64F815C691A62D9831832F988DB@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F99D14@XCH-BLV-504.nw.nos.boeing.com> <6065AA2A-25BB-4B32-B88B-40A856D0E1EA@cisco.com> <2134F8430051B64F815C691A62D9831832F9A0EA@XCH-BLV-504.nw.nos.boeing.com> <568C625A.80808@umn.edu> <2134F8430051B64F815C691A62D9831832F9A12C@XCH-BLV-504.nw.nos.boeing.com> <568C6DA3.5010102@umn.edu> <2134F8430051B64F815C691A62D9831832F9A85C@XCH-BLV-504.nw.nos.boeing.com> <568D4FE0.9030507@umn.edu> <2134F8430051B64F815C691A62D9831832F9AAF5@XCH-BLV-504.nw.nos.boeing.com> To: "Templin, Fred L" , "Fred Baker (fred)" From: David Farmer Organization: University of Minnesota Message-ID: <568D9B10.6090504@umn.edu> Date: Wed, 6 Jan 2016 16:54:08 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <2134F8430051B64F815C691A62D9831832F9AAF5@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" , John Brzozowski Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 22:54:18 -0000 On 1/6/16 12:40 , Templin, Fred L wrote: > Hi David, > >> -----Original Message----- >> From: David Farmer [mailto:farmer@umn.edu] >> Sent: Wednesday, January 06, 2016 9:33 AM >> To: Templin, Fred L; Fred Baker (fred) >> Cc: David Farmer; v6ops@ietf.org; John Brzozowski >> Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host >> >> On 1/6/16 09:42 , Templin, Fred L wrote: >>> Hi David, >>> >>>> -----Original Message----- >>>> From: David Farmer [mailto:farmer@umn.edu] >>>> Sent: Tuesday, January 05, 2016 5:28 PM >>>> To: Templin, Fred L; Fred Baker (fred) >>>> Cc: David Farmer; v6ops@ietf.org; John Brzozowski >>>> Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host >>>> >>>> On 1/5/16 18:46 , Templin, Fred L wrote: >>>>> Hi David, >>>>> >>>>>> -----Original Message----- >>>>>> From: David Farmer [mailto:farmer@umn.edu] >>>> ... >>>>>> In my view AERO and this draft are working in slightly overlapping, but >>>>>> different solution spaces. >>>>> >>>>> We don't know that without a use case analysis. >>>> >>>> Well as I read this, this doesn't implement DHCPv6 PD. Furthermore, it >>>> doesn't need any client software. It uses SLAAC and responds to each >>>> IPv6 ND Router Solicitation with a unicast Router Advertisement with >>>> different prefix for each client. It provides DNS server info with >>>> RADNS and stateless DHCPv6 if the client send a request. >>> >>> How would an unmodified client know that the prefix it receives in >>> a unicast RA is in fact uniquely assigned for the client's exclusive use >>> and not advertised to any other client? >> >> That's the whole point the client doesn't need to know its been uniquely >> assigned the whole prefix to assign it the whole prefix. The client >> doesn't actually guarantee the uniqueness anyway. It's perfectly fine >> for client to be blissfully ignorant of that fact. >> >> Don't get me wrong I'm not saying I don't want clients to do DHCPv6 PD, >> but they just don't have to just to get a whole /64 assigned to them. >> Are there things the client can do if it knows sure. Should the client >> know, if it can deal with that knowledge, sure. However, the client >> doesn't have to know, especially if it doesn't know how to deal with >> that knowledge anyway. > > OK, I see - so, the client (not knowing that the prefix has been delegated > for its own exclusive use) autoconfigures addresses from the prefix > (because the PIO had A=1) and assigns them to the WiFi interface and > not to some internal virtual interface. That means that the client needs > to send a multicast NS(DAD) over the WiFi interface for every such > address that it autoconfigures. That is different than what we have > been talking about regarding "host-addr-availability". Well not really, what I've been saying all along "host-addr-availability" isn't really about DHCPv6 PD that's just one way to accomplish it's real intent. It is the one way that has everyone in a tizzy, but its only one way. > One thing I see missing in the draft however is that the client also needs > to do DAD for its link-local address before it does anything else - right? > >>>> The client requirement are just standard SLAAC, and RADNS or stateless >>>> DHCPv6, that is it. No DHCPv6 PD client needed, am I missing something? >>> >>> I think so. An unmodified client receiving a PIO with (A=1, L=0) would have >>> no way of knowing that the prefix is being delegated for its own exclusive >>> use and that the prefix would not be advertised to other clients. >> >> Why does it have to care? If it cares, it can do DHCPv6 PD, but it >> doesn't have to. You seem to think it has to care, why? > > OK, so the base specification calls for the client to do SLAAC autoconfiguration > of addresses from the advertised prefix and then assign the addresses to the > WiFi interface after it joins the MLD solicited-node multicast group and sends > a multicast NS(DAD) for each such address. Again, that is different than what > we have been talking about in "host-addr-availability". Yes and No, "host-addr-availability" is BCP telling networks DO NOT limit host to one address, one way to do that is assign each host a /64, this is one way to accomplish that. So yes different, but still related. >>>> There is a bunch of WiFi parts too, just like AERO has tunnel stuff, but >>>> that is fairly standard WiFi infrastructure bits. >>> >>> I thought this work was based on tunneling, too? And, AERO can run fine >>> over WiFi just the same as over any link-layer technology. >> >> The CAPWAP stuff is its own separate thing, already specified. There >> may be some unique ways it's used here but that's separate, this is the >> point others have made, and I agree. There is some stuff that needs to >> be tweezed apart but its a good start. >> >>>> So, there is a really quick use case analysis for you and I'll >>>> reiterate; in my view AERO and this draft are working in slightly >>>> overlapping, but different solution spaces. >>> >>> I don't see how multi-addressing in the spirit of "host-addr-availabiity" >>> can be supported on an unmodified client. There would need to be >>> additional specification telling the client what to do when it receives >>> a PIO with (A=1,L=0). But then, the document becomes a spec and >>> not an informational. And, clients would have to be modified. >> >> I disagree with the first part > > I was referring to the language in "host-addr-availability" that allows > the client to assign addresses from the delegated prefix to internal > interfaces such as a loopback. For an unmodified client that does > not know that it is being granted the entire prefix based on just > (A=1;L=0) in the PIO, that option is not available. So, really, the > two documents in question need to be interpreted in a mutually > exclusive fashion which I think you indicated in an earlier message. I wouldn't go as far as mutually exclusive, but yes they are separate issues, that at least touch each other if not overlap some. :) >> but agree with at least part of the second part. >> I'm starting to think that we need a real standards track >> document not just a BCP, at least for PIO with (A=1, L=0) not because it >> needs to really fundamentally makes changes. But I'm worried some >> people will not take this serious without it being standards track. > > I agree with standards-track, but I thought standards-track documents > are out of scope for v6ops? Yep, we will have to deal with that issue, but lets tweeze things apart first then figure out who needs to do what. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nobody Wed Jan 6 14:55:32 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 315721A1B65 for ; Wed, 6 Jan 2016 14:55:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 9S4pfBrN4f22 for ; Wed, 6 Jan 2016 14:55:29 -0800 (PST) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 698431A1B5A for ; Wed, 6 Jan 2016 14:55:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u06MtY4x032761; Wed, 6 Jan 2016 14:55:34 -0800 Received: from XCH-BLV-308.nw.nos.boeing.com (xch-blv-308.nw.nos.boeing.com [130.247.25.220]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u06MtOtH032536 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 6 Jan 2016 14:55:24 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.52]) by XCH-BLV-308.nw.nos.boeing.com ([169.254.8.111]) with mapi id 14.03.0235.001; Wed, 6 Jan 2016 14:55:18 -0800 From: "Templin, Fred L" To: Gert Doering Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt Thread-Index: AQHRSNVQWbc0Z6FCs0WrUPaN5IHZeA== Date: Wed, 6 Jan 2016 22:55:18 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F9B151@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <20160106190013.GZ58491@Space.Net> <2134F8430051B64F815C691A62D9831832F9ADA0@XCH-BLV-504.nw.nos.boeing.com> <20160106212058.GA58491@Space.Net> In-Reply-To: <20160106212058.GA58491@Space.Net> 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: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 22:55:31 -0000 Hi Gert, > -----Original Message----- > From: Gert Doering [mailto:gert@Space.Net] > Sent: Wednesday, January 06, 2016 1:21 PM > To: Templin, Fred L > Cc: Gert Doering; Lorenzo Colitti; v6ops@ietf.org WG > Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-= 04.txt >=20 > Hi, >=20 > On Wed, Jan 06, 2016 at 07:57:14PM +0000, Templin, Fred L wrote: > > As we have been saying, this could result in lots of multicast ND messa= ging > > on the link over which the IA_NAs are received when clients configure l= ots > > of addresses. It is also incompatible withclient mobility,. >=20 > Supposedly multicast is one of the strong points of IPv6, Many people are saying that it is too harsh for some wireless access techno= logies. > and for mobility, there is mobile IPv6. Mobile IPv6 is about associating a mobile host's home address with a care-of address through the insertion of a mobility extension header (i.e., an encapsulation). It is about a mobile host that goes wandering away from its home link yet wants to be able to still communicate as though it was still at home. It is uni-addressing centric, whereas we want to support mobile devices that need multi-addressing. > If we think that these are all historic errors, and the future is IPv6 > over GRE (or LISP), maybe we should make this more clear. Did I mention that AERO works over GRE: https://datatracker.ietf.org/doc/draft-templin-aeromin/ And, my understanding of LISP is that it requires an online mapping database facility. This is no more or no less of a critical infrastructure requirement than for AERO. Thanks - Fred fred.l.templin@boeing.com > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? >=20 > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culema= nn > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Wed Jan 6 15:31:32 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 835FE1A1BCB for ; Wed, 6 Jan 2016 15:31:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] 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 KrGi0vmCKqNV for ; Wed, 6 Jan 2016 15:31:30 -0800 (PST) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3F291A1BCF for ; Wed, 6 Jan 2016 15:31:29 -0800 (PST) Received: by mail-io0-x234.google.com with SMTP id g73so35982443ioe.3 for ; Wed, 06 Jan 2016 15:31:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9H0MuoxFJF0fChj8/cjjvtR+oXRsSyJcgLCHBhWgCaw=; b=Ab8acDuog3Gr88kJWacPIqcylN+rUYOOXW9ZExGtNUKxyguw51b95juIkNHfKVwziG cR4J4wbq4ArBpvkxUrt0963Lt/fYtMmZUKQvK1YxgOndcPgRvagnL4QA2+fpjz2PMqy0 9iremgxFas76E9dK2yIT6BpDiE7ap856scA+ckpsUUH6EWdYAPswMDisnGVCZmzRTy0O CYXBhVAUlewiZBbwbSYFkMSAJvmgury7p/DqINzrJyKf7XpNDk1CS4nqY5IT7MnKWiB+ gk2UG+DNKQPIAqDxCIvnqgEqg5/v+ZQOJbQ9HRZyGsj68pzXirpzIpCFfPV3hVxewU6l zG3A== 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=9H0MuoxFJF0fChj8/cjjvtR+oXRsSyJcgLCHBhWgCaw=; b=ZxZwG6/zl/vtNIXxGt1MoG2pYqgIdzLC8QYNq/BA6kdIKQBqFBb+N6m/9pGrminK+N DVjBZy0+/S/06LCfn6dp+BOr5BShnkY8MbEwQqqVXU2vlGqIeu5MKgx8HtUXIdec6AKG T/cFVl6ip/RGGkz75vPyb1c+7XUItK/zRL6fuI055Jft3EkQtGVBaWm+HpH86q3ZCiJP pWGZ0Kqu5RX6E0t3gDvGHVf28WwKmUtJV0Ftq5k5c9yx2G2ZrBmGB3s9fQVxZ5BtW1Ly QzEcIf8XqvyAr8FZJCgUGjpk6RBEirPLToEVML7d5W7oXcDAJ09G1ACe77xvWconrFcB sDvA== X-Gm-Message-State: ALoCoQkgK2nSRKArs6rqJzSFVrHwNIyKVlR3+50hI+amDntNcJQXg0GLgGz2wzOmRoTs4XEZLU0fn/RMd5QJSAKnSbPP97Bq3Q== MIME-Version: 1.0 X-Received: by 10.107.135.23 with SMTP id j23mr70241948iod.50.1452123089189; Wed, 06 Jan 2016 15:31:29 -0800 (PST) Received: by 10.107.140.150 with HTTP; Wed, 6 Jan 2016 15:31:29 -0800 (PST) In-Reply-To: <568D8C1C.2020406@umn.edu> References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <568D8C1C.2020406@umn.edu> Date: Wed, 6 Jan 2016 15:31:29 -0800 Message-ID: From: Tom Herbert To: David Farmer Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 23:31:31 -0000 On Wed, Jan 6, 2016 at 1:50 PM, David Farmer wrote: > On 1/6/16 07:33 , Erik Kline wrote: >> >> On 6 January 2016 at 22:04, Philip Homburg >> wrote: >>>> >>>> I think instead we can publish this as is, and in future v6ops can >>>> look at a document describing host PD implementation and network >>>> operations experience, if such a document even proves necessary (which >>>> I doubt). >>> >>> >>> I don't think we should write a BCP and then in a future document >>> describe how it works. That's not what a BCP is for. >>> >>> If the PD part is not required for this document, then just remove it. >> >> >> I disagree. PD is a perfectly valid way of addressing the issue and >> it needs to be included at some level of description for completeness. > > > I agree DHCPv6 PD needs to be included and should not be removed. > > However, lets look at the recommendation section. > > ... > If the network requires explicit requests for address space (e.g., > if it requires DHCPv6 to connect), it is RECOMMENDED that the network > assign a /64 prefix to every host (e.g., via DHCPv6 PD). Using > DHCPv6 IA_NA or IA_TA to request a sufficient number of addresses > (e.g. 32) would accommodate current clients but sets a limit on the > number of addresses available to hosts when they attach and would > limit the development of future applications. > ... > > This is could be interpreted as saying that networks SHOULD NOT use Stateful > DHCPv6 for which there is a clear and unambiguous specification for Stateful > DHCPv6 host behavior, and they should use DHCPv6 PD for which there is NOT a > clear and unambiguous specification for DHCPv6 PD host behavior. However, > there is a clear and unambiguous specification for DHCPv6 PD router > behavior, but the importance of this distinction is debatable. > > What if the recommendation section was rewritten making the DHCP v6 PD part > permissive and not a normative recommendation. > > 8. Recommendations > > In order to avoid the problems described above, and preserve the > Internet's ability to support new applications that use more than one > IPv6 address, it is RECOMMENDED that IPv6 network deployments provide > multiple IPv6 addresses from each prefix to general-purpose hosts > when they connect to the network. To support future use cases, it is > RECOMMENDED to not impose a hard limit on the size of the address > pool assigned to a host. > > If the network requires explicit requests for address space (e.g., > if it requires DHCPv6 to connect), the network MAY assign a /64 > prefix to every host (e.g., via DHCPv6 PD). Using DHCPv6 IA_NA or > IA_TA to request a sufficient number of addresses (e.g. 32) would > accommodate current clients but sets a limit on the number of > addresses available to hosts when they attach and would limit the > development of future applications. Assigning prefixes longer than > a /64 will limit the flexibility of the host to further assign > addresses to any internal functions, virtual machines, or downstream > clients that require address space - for example, by not allowing > the use of SLAAC. > > In some ways I like this better, it more clearly says /64 per host is only > an option. The previous language formed as a conditional recommendation, > which was confusing in my opinion. > > What do others think? For ILA needs I prefer the recommendation of a /64 assignment. While we could alternatively define variable length identifiers and locators I think that would be a significant increase in complexity in both the protocol and implementation. Is there an argument that recommending /64 assignment is too big to be a practical recommendation? Tom > > -- > ================================================ > David Farmer Email: farmer@umn.edu > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 1-612-626-0815 > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > ================================================ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Jan 6 15:38:56 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1A3C1A1BED for ; Wed, 6 Jan 2016 15:38:54 -0800 (PST) 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, 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 BmpLt65E7tya for ; Wed, 6 Jan 2016 15:38:52 -0800 (PST) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59A8F1A1A90 for ; Wed, 6 Jan 2016 15:38:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u06Ncn1Q020059; Wed, 6 Jan 2016 16:38:49 -0700 Received: from XCH-BLV-505.nw.nos.boeing.com (xch-blv-505.nw.nos.boeing.com [130.247.25.195]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u06Nck11020035 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 6 Jan 2016 16:38:46 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.52]) by XCH-BLV-505.nw.nos.boeing.com ([169.254.5.220]) with mapi id 14.03.0235.001; Wed, 6 Jan 2016 15:38:45 -0800 From: "Templin, Fred L" To: Tom Herbert , David Farmer Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt Thread-Index: AQHRSNti4zkWRRXsskWmIANb+5/kxA== Date: Wed, 6 Jan 2016 23:38:45 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F9B2A4@XCH-BLV-504.nw.nos.boeing.com> References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <568D8C1C.2020406@umn.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 23:38:54 -0000 Hi, > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Tom Herbert > Sent: Wednesday, January 06, 2016 3:31 PM > To: David Farmer > Cc: v6ops@ietf.org > Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-= 04.txt >=20 > On Wed, Jan 6, 2016 at 1:50 PM, David Farmer wrote: > > On 1/6/16 07:33 , Erik Kline wrote: > >> > >> On 6 January 2016 at 22:04, Philip Homburg > >> wrote: > >>>> > >>>> I think instead we can publish this as is, and in future v6ops can > >>>> look at a document describing host PD implementation and network > >>>> operations experience, if such a document even proves necessary (whi= ch > >>>> I doubt). > >>> > >>> > >>> I don't think we should write a BCP and then in a future document > >>> describe how it works. That's not what a BCP is for. > >>> > >>> If the PD part is not required for this document, then just remove it= . > >> > >> > >> I disagree. PD is a perfectly valid way of addressing the issue and > >> it needs to be included at some level of description for completeness. > > > > > > I agree DHCPv6 PD needs to be included and should not be removed. > > > > However, lets look at the recommendation section. > > > > ... > > If the network requires explicit requests for address space (e.g., > > if it requires DHCPv6 to connect), it is RECOMMENDED that the networ= k > > assign a /64 prefix to every host (e.g., via DHCPv6 PD). Using > > DHCPv6 IA_NA or IA_TA to request a sufficient number of addresses > > (e.g. 32) would accommodate current clients but sets a limit on the > > number of addresses available to hosts when they attach and would > > limit the development of future applications. > > ... > > > > This is could be interpreted as saying that networks SHOULD NOT use Sta= teful > > DHCPv6 for which there is a clear and unambiguous specification for Sta= teful > > DHCPv6 host behavior, and they should use DHCPv6 PD for which there is = NOT a > > clear and unambiguous specification for DHCPv6 PD host behavior. Howev= er, > > there is a clear and unambiguous specification for DHCPv6 PD router > > behavior, but the importance of this distinction is debatable. > > > > What if the recommendation section was rewritten making the DHCP v6 PD = part > > permissive and not a normative recommendation. > > > > 8. Recommendations > > > > In order to avoid the problems described above, and preserve the > > Internet's ability to support new applications that use more than on= e > > IPv6 address, it is RECOMMENDED that IPv6 network deployments provid= e > > multiple IPv6 addresses from each prefix to general-purpose hosts > > when they connect to the network. To support future use cases, it i= s > > RECOMMENDED to not impose a hard limit on the size of the address > > pool assigned to a host. > > > > If the network requires explicit requests for address space (e.g., > > if it requires DHCPv6 to connect), the network MAY assign a /64 > > prefix to every host (e.g., via DHCPv6 PD). Using DHCPv6 IA_NA or > > IA_TA to request a sufficient number of addresses (e.g. 32) would > > accommodate current clients but sets a limit on the number of > > addresses available to hosts when they attach and would limit the > > development of future applications. Assigning prefixes longer than > > a /64 will limit the flexibility of the host to further assign > > addresses to any internal functions, virtual machines, or downstream > > clients that require address space - for example, by not allowing > > the use of SLAAC. > > > > In some ways I like this better, it more clearly says /64 per host is o= nly > > an option. The previous language formed as a conditional recommendatio= n, > > which was confusing in my opinion. > > > > What do others think? >=20 > For ILA needs I prefer the recommendation of a /64 assignment. While > we could alternatively define variable length identifiers and locators > I think that would be a significant increase in complexity in both the > protocol and implementation. Is there an argument that recommending > /64 assignment is too big to be a practical recommendation? Similarly, AERO would prefer a /64 or shorter (e.g., /60, /56. etc.). I do = not think /64 is too big, and I think cellular operators are already doing this= . Thanks - Fred fred.l.templin@boeing.com > Tom >=20 > > > > -- > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > David Farmer Email: farmer@umn.edu > > Office of Information Technology > > University of Minnesota > > 2218 University Ave SE Phone: 1-612-626-0815 > > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Jan 6 15:55:28 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B03D61A1E0B for ; Wed, 6 Jan 2016 15:55:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 B_4g2cR58TH6 for ; Wed, 6 Jan 2016 15:55:25 -0800 (PST) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.119.120]) by ietfa.amsl.com (Postfix) with ESMTP id 0092A1A1DBE for ; Wed, 6 Jan 2016 15:55:24 -0800 (PST) Received: from mail-io0-f170.google.com (mail-io0-f170.google.com [209.85.223.170]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128/128); for ; Wed, 6 Jan 2016 17:55:23 -0600 (CST) X-Umn-Remote-Mta: [N] mail-io0-f170.google.com [209.85.223.170] #+LO+TS+TR X-Umn-Classification: local Received: by mail-io0-f170.google.com with SMTP id 77so203975634ioc.2 for ; Wed, 06 Jan 2016 15:55:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=reply-to:subject:references:to:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=FUWtlsGj98Pa0KGFf0pfYMZhji7PX6NHCR2FVoUHvaw=; b=hAaF6v+8TgRHgyR+e/SdeREdHWz0mlRf0s9bhliUeMkhDmiRYwGf6/w9Xh82mbN6Uq gKkn/r6QzsE3hizUiW2Nak46odENNVzWuhK+K6wsayviD34AqNHNSg8EP0fWEmIRgbQ8 OPcNdkgVuyC2sTHetrkFP/gMg71j/b5FmQqFc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:cc:from :organization:message-id:date:user-agent:mime-version:in-reply-to :content-type:content-transfer-encoding; bh=FUWtlsGj98Pa0KGFf0pfYMZhji7PX6NHCR2FVoUHvaw=; b=fl0xacjIALniOtC3dK4VLSFRY0zWjt6B/8FAKXvRU1dLc9VvVSp6W/mWJDW/n3/k9D k+RoopFLOm2mwYEPBpvbV/k6WlM4kmaN7n+Xgi6eKQF62Ps/+a+PrQSyJK7F0DVzQlty d8dqBFPeTgGXCpeCL74y78jP8Lud/6N9b+XP8grNyQ7IOE7fx2UN0UoU6aEtr0GVT10t sNslvs8HPetWi+MyRNKRvB3gf0eQ3NylJ0qtarR5X+B6EsBbhY34yTTRZzblLI7p+U7H 8UHCg2lhKAB82O2XzxAS0zE+tNVWGwAPAEkB4jgyItCiUr+0OCL5Tasu/KlBiqmSXjYb 26wA== X-Gm-Message-State: ALoCoQlhDyCsfdnOPAtZV5j0B0dPJFohKNoeXWjlkMMLpwEDIYQqmOokBa33MYq9vA2dTBFw/cukY8l/LVcud0iE0/lRski6eE7ZVI/Guh0NQ0IC9V+ev4ms62C46LOL0FpDhN09ODWAlum5SH2OQweGMt2GdNN5+w== X-Received: by 10.107.170.212 with SMTP id g81mr75694040ioj.44.1452124523064; Wed, 06 Jan 2016 15:55:23 -0800 (PST) X-Received: by 10.107.170.212 with SMTP id g81mr75694024ioj.44.1452124522906; Wed, 06 Jan 2016 15:55:22 -0800 (PST) Received: from x-10-104-143-225.uofm-secure.wireless.umn.edu ([2607:ea00:107:2001:e87a:3657:26ff:7144]) by smtp.gmail.com with ESMTPSA id k16sm3775890igf.0.2016.01.06.15.55.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Jan 2016 15:55:21 -0800 (PST) References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <568D8C1C.2020406@umn.edu> To: Tom Herbert From: David Farmer Organization: University of Minnesota Message-ID: <568DA966.9040407@umn.edu> Date: Wed, 6 Jan 2016 17:55:18 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 23:55:27 -0000 On 1/6/16 17:31 , Tom Herbert wrote: > On Wed, Jan 6, 2016 at 1:50 PM, David Farmer wrote: >> On 1/6/16 07:33 , Erik Kline wrote: >>> >>> On 6 January 2016 at 22:04, Philip Homburg >>> wrote: >>>>> >>>>> I think instead we can publish this as is, and in future v6ops can >>>>> look at a document describing host PD implementation and network >>>>> operations experience, if such a document even proves necessary (which >>>>> I doubt). >>>> >>>> >>>> I don't think we should write a BCP and then in a future document >>>> describe how it works. That's not what a BCP is for. >>>> >>>> If the PD part is not required for this document, then just remove it. >>> >>> >>> I disagree. PD is a perfectly valid way of addressing the issue and >>> it needs to be included at some level of description for completeness. >> >> >> I agree DHCPv6 PD needs to be included and should not be removed. >> >> However, lets look at the recommendation section. >> >> ... >> If the network requires explicit requests for address space (e.g., >> if it requires DHCPv6 to connect), it is RECOMMENDED that the network >> assign a /64 prefix to every host (e.g., via DHCPv6 PD). Using >> DHCPv6 IA_NA or IA_TA to request a sufficient number of addresses >> (e.g. 32) would accommodate current clients but sets a limit on the >> number of addresses available to hosts when they attach and would >> limit the development of future applications. >> ... >> >> This is could be interpreted as saying that networks SHOULD NOT use Stateful >> DHCPv6 for which there is a clear and unambiguous specification for Stateful >> DHCPv6 host behavior, and they should use DHCPv6 PD for which there is NOT a >> clear and unambiguous specification for DHCPv6 PD host behavior. However, >> there is a clear and unambiguous specification for DHCPv6 PD router >> behavior, but the importance of this distinction is debatable. >> >> What if the recommendation section was rewritten making the DHCP v6 PD part >> permissive and not a normative recommendation. >> >> 8. Recommendations >> >> In order to avoid the problems described above, and preserve the >> Internet's ability to support new applications that use more than one >> IPv6 address, it is RECOMMENDED that IPv6 network deployments provide >> multiple IPv6 addresses from each prefix to general-purpose hosts >> when they connect to the network. To support future use cases, it is >> RECOMMENDED to not impose a hard limit on the size of the address >> pool assigned to a host. >> >> If the network requires explicit requests for address space (e.g., >> if it requires DHCPv6 to connect), the network MAY assign a /64 >> prefix to every host (e.g., via DHCPv6 PD). Using DHCPv6 IA_NA or >> IA_TA to request a sufficient number of addresses (e.g. 32) would >> accommodate current clients but sets a limit on the number of >> addresses available to hosts when they attach and would limit the >> development of future applications. Assigning prefixes longer than >> a /64 will limit the flexibility of the host to further assign >> addresses to any internal functions, virtual machines, or downstream >> clients that require address space - for example, by not allowing >> the use of SLAAC. >> >> In some ways I like this better, it more clearly says /64 per host is only >> an option. The previous language formed as a conditional recommendation, >> which was confusing in my opinion. >> >> What do others think? > > For ILA needs I prefer the recommendation of a /64 assignment. While > we could alternatively define variable length identifiers and locators > I think that would be a significant increase in complexity in both the > protocol and implementation. Is there an argument that recommending > /64 assignment is too big to be a practical recommendation? I think you are making my point, the previous language wasn't a straight up recommendation of a /64 either. If the network requires explicit requests for address space (e.g., if it requires DHCPv6 to connect), it is RECOMMENDED that the network assign... That isn't that much different than; If the network requires explicit requests for address space (e.g., if it requires DHCPv6 to connect), the network MAY assign... But, I think the later eliminates the mistaken believe that a /64 or DHCPv6 PD is being recommend in all cases, it's NOT in either case. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nobody Wed Jan 6 23:38:33 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA721A872B for ; Wed, 6 Jan 2016 23:38:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-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 9EvQNGcYf93u for ; Wed, 6 Jan 2016 23:38:29 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0B191A872C for ; Wed, 6 Jan 2016 23:38:29 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 3829A60760 for ; Thu, 7 Jan 2016 08:38:27 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 02FE8600F9 for ; Thu, 7 Jan 2016 08:38:27 +0100 (CET) Received: (qmail 30820 invoked by uid 1007); 7 Jan 2016 08:38:26 +0100 Date: Thu, 7 Jan 2016 08:38:26 +0100 From: Gert Doering To: David Farmer Message-ID: <20160107073826.GC58491@Space.Net> References: <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <568D8C1C.2020406@umn.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <568D8C1C.2020406@umn.edu> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 07:38:31 -0000 Hi, On Wed, Jan 06, 2016 at 03:50:20PM -0600, David Farmer wrote: > If the network requires explicit requests for address space (e.g., > if it requires DHCPv6 to connect), the network MAY assign a /64 > prefix to every host (e.g., via DHCPv6 PD). This is much better. It remains a somewhat unexplained mystery, though, why the recommendation is to delegate a /64. Why not a /96? (Which would still be more addresses than the host could ever configure locally) Why not a /60, so internal virtual subnets on the host could be accomodated, if that is what "we" want? If "we" recommend burning /64s in large scale, has someone done math what this does to the /48 which is typically permitted per site if that site has a large number of users requesting prefixes? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Wed Jan 6 23:40:43 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF2E1A872B for ; Wed, 6 Jan 2016 23:40:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 OLKgmLQjHpSD for ; Wed, 6 Jan 2016 23:40:40 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 901791A871B for ; Wed, 6 Jan 2016 23:40:40 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 0A0166082D for ; Thu, 7 Jan 2016 08:40:39 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id D0B3460740 for ; Thu, 7 Jan 2016 08:40:38 +0100 (CET) Received: (qmail 30991 invoked by uid 1007); 7 Jan 2016 08:40:38 +0100 Date: Thu, 7 Jan 2016 08:40:38 +0100 From: Gert Doering To: "Templin, Fred L" Message-ID: <20160107074038.GD58491@Space.Net> References: <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <568D8C1C.2020406@umn.edu> <2134F8430051B64F815C691A62D9831832F9B2A4@XCH-BLV-504.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2134F8430051B64F815C691A62D9831832F9B2A4@XCH-BLV-504.nw.nos.boeing.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 07:40:41 -0000 Hi, On Wed, Jan 06, 2016 at 11:38:45PM +0000, Templin, Fred L wrote: > Similarly, AERO would prefer a /64 or shorter (e.g., /60, /56. etc.). I do not > think /64 is too big, and I think cellular operators are already doing this. The cellular argument doesn't really apply here - in cellular, hosts are doing SLAAC out of the /64, so it MUST be a /64, no less, no more. In DHCPv6-PD-to-the-host, the mechanism how the host configures addresses out of the prefix delegated is fully unspecified. So the "it has to be a /64" rule for SLAAC does not apply. I think a /64 per user in an enterprise network is needlessly wastive. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Wed Jan 6 23:47:44 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF4FF1A8734 for ; Wed, 6 Jan 2016 23:47:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 6N-zzQVi_v_c for ; Wed, 6 Jan 2016 23:47:42 -0800 (PST) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B76551A8731 for ; Wed, 6 Jan 2016 23:47:42 -0800 (PST) Received: by mail-yk0-x22d.google.com with SMTP id v14so238227469ykd.3 for ; Wed, 06 Jan 2016 23:47:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=0eN+IAC3IiB8plZFlVE/uXYRw8HF11LxTQBOgVW/t+8=; b=ZlAS8p2cje9HAdAcd7z8iDL7Q1zGzGdJ1EGEZQRjcgOSiIaZpbAOzySwvplgNxDYJn ziK3dOr3FSxIbv3wF3JDRqh62Tx+PkZO5huDujvP0oQbWcRDstJ802Q2FMpBCcDLD4ld VHpl3epDqv+EitxpMsVWlNjN1NEnm5ugLV8e3IkWf5hbIBMue0wplIwzfVz/mZJ5Ahie zHT5yWAUqYQoNEK75k92sgSJK4fqDtL9xe62Og6WwdkHgNUqbuI0V+V6M2tUkTIVZN8n lel143exaU59fUgRJXn4HijfF2LkIfZDaQzc+PDtLQy6kAFxiYpfLd+Jdsn99uB7m2Gz LCeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=0eN+IAC3IiB8plZFlVE/uXYRw8HF11LxTQBOgVW/t+8=; b=QKxrKkbd99t/hZNpKl5PW47/OvC98/eBrbFihjs0em5QmExkbrK+xgMb2ME0yIhizO HmOiCQtxjNxXqIUxIK2SupMZHGlq89E7o5Atrys0fyRewFsR96+3R3n+5B4Fsk/87yRE 2aUgFxE1Iv8Q7FIMpGIwi8PBPJerW6jK8xZiwVMTlIRXLS4tM2VTm3YRtzeSqUzxkBCV 9YDbP4oldcxqB/DA4nD8dFkMuCUkilfcMZioAtG23C4i+Ova50zcn7qi75fwGio0qlfc ghu8TCyp7l0s6VjrJ57o/55JoZn4WD1UhynYu+fHiIGxsOqaei+CH54ZDhRayBVeLhh0 f5vg== X-Gm-Message-State: ALoCoQn7776C4HHt057AFKn+nnOC+lCkwJb7650hHFog41OB9qcf7UClYpoWcHwgVZkb7rjBsRHQI/RMtE8NgU8n0SLWEDO3VTrE/ZrS8k3Bs/OU7rxEWJU= X-Received: by 10.129.136.196 with SMTP id y187mr74579676ywf.307.1452152861825; Wed, 06 Jan 2016 23:47:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.208.201 with HTTP; Wed, 6 Jan 2016 23:47:21 -0800 (PST) In-Reply-To: <20160107073826.GC58491@Space.Net> References: <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <568D8C1C.2020406@umn.edu> <20160107073826.GC58491@Space.Net> From: Lorenzo Colitti Date: Thu, 7 Jan 2016 16:47:21 +0900 Message-ID: To: Gert Doering Content-Type: multipart/alternative; boundary=001a114f38b47db85b0528b9af87 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 07:47:43 -0000 --001a114f38b47db85b0528b9af87 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 7, 2016 at 4:38 PM, Gert Doering wrote: > If "we" recommend burning /64s in large scale, has someone done math what > this does to the /48 which is typically permitted per site if that site > has a large number of users requesting prefixes? > The math is in the draft. Have you read it? --001a114f38b47db85b0528b9af87 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 7, 2016 at 4:38 PM, Gert Doering <gert@space.net> wrote= :
If "we" recommend burning /64= s in large scale, has someone done math what
this does to the /48 which is typically permitted per site if that site
has a large number of users requesting prefixes?

<= /div>
The math is in the draft. Have you read it?=C2=A0
--001a114f38b47db85b0528b9af87-- From nobody Wed Jan 6 23:58:26 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5288A1A873D for ; Wed, 6 Jan 2016 23:58:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 2a4_DDMXAjOY for ; Wed, 6 Jan 2016 23:58:23 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A4691A873B for ; Wed, 6 Jan 2016 23:58:22 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 1B490608D6 for ; Thu, 7 Jan 2016 08:58:21 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id D7FF560737 for ; Thu, 7 Jan 2016 08:58:20 +0100 (CET) Received: (qmail 31886 invoked by uid 1007); 7 Jan 2016 08:58:20 +0100 Date: Thu, 7 Jan 2016 08:58:20 +0100 From: Gert Doering To: Lorenzo Colitti Message-ID: <20160107075820.GE58491@Space.Net> References: <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <568D8C1C.2020406@umn.edu> <20160107073826.GC58491@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="i0xbckOs9ckBzXei" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 07:58:24 -0000 --i0xbckOs9ckBzXei Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Jan 07, 2016 at 04:47:21PM +0900, Lorenzo Colitti wrote: > On Thu, Jan 7, 2016 at 4:38 PM, Gert Doering wrote: >=20 > > If "we" recommend burning /64s in large scale, has someone done math wh= at > > this does to the /48 which is typically permitted per site if that site > > has a large number of users requesting prefixes? >=20 > The math is in the draft. Have you read it? I assume you're talking about section 9.2? This is a bit of handwaving and telling us that "this is not a problem because where it might be a problem, people will be using SLAAC, and thus, it is not a problem",=20 right? I do see this is as potential problem for an enterprise that only has=20 a /48 (because that is what a site will get from RIPE), has multiple attachment points, does not want 65k routes in their IGP (so, aggregation= =20 is needed per attachment point) and has couple of 1000 users using this - and then they will come and complain to the RIR of choice that they could not get sufficient address space to do this. Please spell out clearly that using this technology is not RIR-sanctioned and will not entitle them to a single extra IPv6 subnet. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --i0xbckOs9ckBzXei Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVo4anN9WwGXkzn/FAQKgbA/+PZa3CGpKOeqG0iWf2QfU7EpfSkOso7sC sp5mRPNbeHBV2OGm4lfkhd/3AVJdY2OZ/YwNPgMKiGJSh6N40JYQLg0290dKEJpM I+h78uOhjU+81/NJ2jWphOyTgfsmXeRpaOcmxxOOuKiL9hkI2n6PaPZd6VTZCSXj K08Z8c3BHOUwb7zT+qdLoOH6cTsuTcfU/KejecrDS6KMAyzNQGqrp/EDwEy7qEwJ 7pr6SZwAtz4Fs3golY04s1HUruGLTbaLEHIfKuWYwiKHdr3HTIku+IX55FJvRiGW basMFVIzFsZSWkp+Wct+3fLPi11paMoDZXN7zz+6UMDQVyouRO2+SXeokOqwFkm5 RIJqjCyOEy6BOMxnirSpQuEeFb9npSBlDbVOeCF+9d64/a56AjNttzKVlGVHRhQD tkLg8eKUzHlIx0gNI/ujS3EDZ2OD2Tdro6HRAR5mnH9AV6ttmVq81yrg8w7EiSSb bZnwL2Ud3F5QudO5YWeQrddtjiPTYcl3H9YyHjMM+AxUykPczGO3HWbLud+ZZAHW 5nStTDXDQJH+kRWTs2TxKxVaZEEhnMarSjtSgWr0qfb7KTOtKhHnwyu7XHhoo6QX Vh3xTwv/4+6IdF4Nl/8a5ecBHBY+MCvfj87Vv67L7d+AkzUfQPHUPxnvAyqmTXy+ SE7e+Qjl0uE= =ZXbz -----END PGP SIGNATURE----- --i0xbckOs9ckBzXei-- From nobody Thu Jan 7 00:11:59 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC951A8787 for ; Thu, 7 Jan 2016 00:11:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 D-l2DoX-aTtz for ; Thu, 7 Jan 2016 00:11:57 -0800 (PST) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4F7B1A19F2 for ; Thu, 7 Jan 2016 00:11:56 -0800 (PST) Received: by mail-io0-x22b.google.com with SMTP id 1so197743067ion.1 for ; Thu, 07 Jan 2016 00:11:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=mkjTe/Pg4p9hHNdXl7ivDn4jigny9Bm9WGuFRrWpxOY=; b=M4AVj3KwBB+KLRbSS7H8St5OJn9pT7cRxg+RPF3iV2vNfUP8Tt6990qlUffNjGwXAa 1PwlKOIgmzMDG9ncb2BGnmHnhwp/gutVbOYAI2cuB+UNsL2awCiUkI1tle35YwrUzQUP XFf4XGgrTE2Za8qWZC3nGrrO4+LsIWlJMIiL61G1/nnSbYXQc9GFKRb3d11diJBASD40 LVp3q/z2ChiZAAk+3BJ//0b6SHvfmEh8T56aoQGAMN5GktbkVywfAqXuSl9e6WJ2KT9F hktnIYxgOYmVsN4i7zFP7uh9U0WWzbFJpGGUqpIRXrZEzp4s6wCXBb0HfPHgYzz0Fc8U zm5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=mkjTe/Pg4p9hHNdXl7ivDn4jigny9Bm9WGuFRrWpxOY=; b=iuMKof6RexHxKt7pwoXZuLAdvl9i1RpUDiK8KVEJoASOYTGNxtH4ORhA2gLISSQfOJ iOY9dPgj5++wfzLsV0aS+EjAw4Q15admGPzm/nMgSaPQIiMgTpClT8rEGKQWK7QZvV0U YzAz78R5JU+D5xPzpxOSf/qygNM3W/+QCmAxT+p4X2fjOu8GKWjF2JgvGTE3UYshJtrR zzePEmF8RROeZExZOSeT8nDi3Luqz6nSFTPt8CgG/7kJ434yhEhIpa0ZJcciu7IoKAfE +rW4ScjqzLvaqqRHSDtRooAffa2kGHTlK/snZFJJeLb5U44GJKBcBRhjRHqt/UsqhY6s U43A== X-Gm-Message-State: ALoCoQlaZ6RhvOfZVAqAn6XhEzVUJDyZYhFxAXlMO0Kb9QTNGfSS9BalC7CoYAfFl/wzE+SQDKjLMxjd7+XbOBwqKQ2cwtWoiVVpxWT6iQsjQPgSG2WEUmE= X-Received: by 10.107.153.140 with SMTP id b134mr7119301ioe.113.1452154316198; Thu, 07 Jan 2016 00:11:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.26.39 with HTTP; Thu, 7 Jan 2016 00:11:36 -0800 (PST) In-Reply-To: <20160107075820.GE58491@Space.Net> References: <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <568D8C1C.2020406@umn.edu> <20160107073826.GC58491@Space.Net> <20160107075820.GE58491@Space.Net> From: Lorenzo Colitti Date: Thu, 7 Jan 2016 17:11:36 +0900 Message-ID: To: Gert Doering Content-Type: multipart/alternative; boundary=001a1140fbb02d9ef10528ba061a Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 08:11:58 -0000 --001a1140fbb02d9ef10528ba061a Content-Type: text/plain; charset=UTF-8 On Thu, Jan 7, 2016 at 4:58 PM, Gert Doering wrote: > I assume you're talking about section 9.2? This is a bit of handwaving > and telling us that "this is not a problem because where it might be a > problem, people will be using SLAAC, and thus, it is not a problem", > right? > The recommendation is to provide a /64 if the network requires explicit requests for address space. A network that does SLAAC does not require such requests. > I do see this is as potential problem for an enterprise that only has > a /48 (because that is what a site will get from RIPE), has multiple > attachment points, does not want 65k routes in their IGP (so, aggregation > is needed per attachment point) and has couple of 1000 users using this > - and then they will come and complain to the RIR of choice that they > could not get sufficient address space to do this. > I don't buy that. Running out of a /48 with 4000 users means a 95% aggregation loss. You don't need to put 64k routes in your IGP to get much more efficiency than that. > Please spell out clearly that using this technology is not RIR-sanctioned > and will not entitle them to a single extra IPv6 subnet. RIR policies can be changed, and if this document is published, it should not be hard to change them. I cannot imagine anyone at a RIR successfully arguing that assigning a /40 to a medium-sized enterprise is wasteful. --001a1140fbb02d9ef10528ba061a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 7, 2016 at 4:58 PM, Gert Doering <gert@space.net> wrote= :
I assume you're talking about secti= on 9.2?=C2=A0 This is a bit of handwaving
and telling us that "this is not a problem because where it might be a=
problem, people will be using SLAAC, and thus, it is not a problem", right?

The recommendation is to provide= a /64 if the network requires explicit requests for address space. A netwo= rk that does SLAAC does not require such requests.
=C2=A0
I do see this is as potential problem for an e= nterprise that only has
a /48 (because that is what a site will get from RIPE), has multiple
attachment points, does not want 65k routes in their IGP (so, aggregation is needed per attachment point) and has couple of 1000 users using this
- and then they will come and complain to the RIR of choice that they
could not get sufficient address space to do this.
I don't buy that. Running out of a /48 with 4000 users mean= s a 95% aggregation loss. You don't need to put 64k routes in your IGP = to get much more efficiency than that.
=C2=A0
Please spell out clearly that using this technology is not= RIR-sanctioned
and will not entitle them to a single extra IPv6 subnet.
<= br>
RIR policies can be changed, and if this document is publishe= d, it should not be hard to change them. I cannot imagine anyone at a RIR s= uccessfully arguing that assigning a /40 to a medium-sized enterprise is wa= steful.
--001a1140fbb02d9ef10528ba061a-- From nobody Thu Jan 7 00:19:57 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A297C1A8798 for ; Thu, 7 Jan 2016 00:19:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 IkwOI3u83d_f for ; Thu, 7 Jan 2016 00:19:54 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0DC11A8797 for ; Thu, 7 Jan 2016 00:19:54 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 71FDF608D7 for ; Thu, 7 Jan 2016 09:19:52 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id F020360737 for ; Thu, 7 Jan 2016 09:19:51 +0100 (CET) Received: (qmail 33132 invoked by uid 1007); 7 Jan 2016 09:19:51 +0100 Date: Thu, 7 Jan 2016 09:19:51 +0100 From: Gert Doering To: Lorenzo Colitti Message-ID: <20160107081951.GF58491@Space.Net> References: <568D8C1C.2020406@umn.edu> <20160107073826.GC58491@Space.Net> <20160107075820.GE58491@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="//MD+r6UUJvz0X/C" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 08:19:56 -0000 --//MD+r6UUJvz0X/C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Jan 07, 2016 at 05:11:36PM +0900, Lorenzo Colitti wrote: > > Please spell out clearly that using this technology is not RIR-sanction= ed > > and will not entitle them to a single extra IPv6 subnet. > RIR policies can be changed, and if this document is published, it should > not be hard to change them. I cannot imagine anyone at a RIR successfully > arguing that assigning a /40 to a medium-sized enterprise is wasteful. I can see myself in that position. IETF recommendation is "/48 per site", and this is what the RIRs are following. I have a hard time argueing for more than 64k subnets at a single site if that is all virtual in the end. (And knowing RIR communities, you won't find many more people supporting a somewhat conservative approach than "just don't care, out with the bits") Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --//MD+r6UUJvz0X/C Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVo4fp99WwGXkzn/FAQLCdg/9GFbnN6fQBrEAF3uUQgvFrGV+FB+7Ewal 02vMgAc+sgT68E52a+tMN9jKWK3DPhRjjns7S0vW4UnQaRfxYuscL6EzZUbb/IM4 337OJe3tfgaIfV0WnckCUQxFW17gNCgXzKg2cUJi+vosdTEqMD27mG4oeF7GodA5 ricRtqCfGold/rQp4U72yxzGy6dILANmMtFVYfjsCjjPCMIDb/gBcWPLinjQVXkv O6elcaONUpVTak+soPGGEmNGe2GsjX0yQToEMb+tfQDzwtDLZVvm0LwtcoSR0Qo/ I5idYHFIdwUcm9hb91h2ILzTZqX/GfSiNvTcOZ1bj4M+P4jqLImC0uCf/KgHBByK /lvUEzJokqzkHRjzWk7fukugIrcsUeueLmuPgk780HYyq4qZVmzVJXA3sW7gELaU sc1bWGfNf7YPn+KckBCYiyzPlbhSoQ9IYrysOvSH4/sRaC5boMCp5fglmuMP0zsc sA6bZ7tCt8TWEEkiPnHtshmF3hzuClvcqP1CKrzhkCfAUT9k+AMW1h0ZY8HDyE3I XZwI1IKhWlCY+6iFk843kUBGUiYfeOIRr4KfBGnFI+Bvw7IyiVROEPr4mrfLjc12 QeaRrx5J5oVNSj0BwozxyaaMxokeWk1oQtwGr+RrtbdpHhHjkQZvQ4wsqmvnmsjX YB8RXTCJc/E= =8cuZ -----END PGP SIGNATURE----- --//MD+r6UUJvz0X/C-- From nobody Thu Jan 7 00:20:55 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCBE11A8798 for ; Thu, 7 Jan 2016 00:20:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Lz6mSPQAlmHe for ; Thu, 7 Jan 2016 00:20:52 -0800 (PST) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53F051A8797 for ; Thu, 7 Jan 2016 00:20:52 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id g73so46592571ioe.3 for ; Thu, 07 Jan 2016 00:20:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=E57xHh6ULzdT8mmjx70BDMX9KEN1f9Wpj7NBvRWScOY=; b=YKmmKWjHAD8O+lbU8eKcUjensZHevQNSALsOBj3eHMFEJldNR7k6U/1LIx0XiHWzob eMZ211aeplRzdQBX+ksTdFLkIKfv6Xx1y5lmBgrrNRi8Jsp7TSvlTZCuTNkEo3m9ofrK 7SKhU00LlePKmT2kwO007WtFad8nMXg6f64433AH89LuTKFutiJkgL3U/LFGVzMkl+T6 md/fFgSh97PCKeZT5iI4KaCYdyfdRhfE1mWuYGbqv5FKnROKvIXXGH6EZLCjKBh4/rF4 CQSYGC6eOVXkilLqdDtwoCwGvBANGlNz36FwgCxjTSTCaGNVCjF7iT0Pq3jXlcslKYwq W8RQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=E57xHh6ULzdT8mmjx70BDMX9KEN1f9Wpj7NBvRWScOY=; b=k0c8ZMXemr5qyEm8H+O18dv1idP8ckvcAsmm0ZGbgoThHMRVY50CkPtOtaY76EmdAW P4TnbnXMKcPk2YUu2Q/3mSpt2ONmAcTz6+NQ77zn7LeQ6Ol1otFU3wvyT52iyIBqrXtd /mAEVdBBDuvX8j+DAY2mSRObkuoZxZqkkqJnOtUngOVVd+ZadW5kXNIi8bE4zbzKrWxV goEgndRDdUIZrWol6RLdPNiUSh0GeyaGESq6bItq6mE3PBYVHHjZOGQpODOgtaVWWwce BvUqsg5ES8G3+XMXCWy/2Jqb0VM7p2A8S1Z8t/FEK65KEo6VqL1Z2WWC3rJxCg4DV/bB 4nRw== X-Gm-Message-State: ALoCoQniirry/1NtOLNrdy5TChM2P8nQCE8DPAAdT5D8kpptjuusFGKgpM3SMO/tU/7vO5KlByflTnY/SIfR/Vuo+1y5bxI8uVPbn1vYm4DfJL2VJGW0K08= X-Received: by 10.107.153.140 with SMTP id b134mr7155987ioe.113.1452154851567; Thu, 07 Jan 2016 00:20:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.26.39 with HTTP; Thu, 7 Jan 2016 00:20:31 -0800 (PST) In-Reply-To: <20160106190013.GZ58491@Space.Net> References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <20160106190013.GZ58491@Space.Net> From: Lorenzo Colitti Date: Thu, 7 Jan 2016 17:20:31 +0900 Message-ID: To: Gert Doering Content-Type: multipart/alternative; boundary=001a1140fbb016ad8c0528ba2683 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 08:20:53 -0000 --001a1140fbb016ad8c0528ba2683 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 7, 2016 at 4:00 AM, Gert Doering wrote: > The network is evolving - especially with homenet, the whole model of > cascading DHCPv6-PD CPEs is being abandoned, because there are better ways. > Funny - Philip is arguing that this is too new and we don't know how to do it, and you're arguing that it's legacy :-) > > Do we? A node is either a host or a router. > > Most routers are also hosts by necessity of talking IP for their > management plane. > That's a pretty gratuitous objection, given that my point was that PD can work on both hosts and routers. ("Either a host or a router" is also technically true - see RFC 2460.) > > We can't do that, because that leaves the problem of what to do on a > > network that has decided to provide address space only via DHCPv6. It > seems > > to me that there has been pretty strong agreement all along that such > > networks should also provide sufficient address space to hosts. > > "just provide multiple addresses with DHCPv6 IA_NA"? > That point is addressed in the draft in multiple places. > Is actually quite a bit easier to roll out than "build a DHCPv6 PD > infrastructure"... memory on the DHCPv6 server is cheap, slots on routers > are expensive. Actually, as discussed in section 9.3, one prefix per host is much more scalable than one TCAM entry per address. As discussed in section 7, the number of addresses are needed if the host does not do NAT66 can be quite high. Doing that with multiple IA_NA entries is going to hit the last-hop routers much much harder than one /64 per host. Not to mention all the ND traffic that others have mentioned. Gert: a lot of the points you make are already discussed in the draft. If you want to make statements that these recommendations are misguided, then please discuss the text where the draft provides rationale for those recommendations, instead of attacking the recommendations out of context. --001a1140fbb016ad8c0528ba2683 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 7, 2016 at 4:00 AM, Gert Doering <gert@space.net> wrote= :
The network is evolving - especially with homenet, th= e whole model of
cascading DHCPv6-PD CPEs is being abandoned, because there are better ways.=

Funny - Philip is arguing that this is= too new and we don't know how to do it, and you're arguing that it= 's legacy :-)
=C2=A0
&= gt; Do we? A node is either a host or a router.

Most routers are also hosts by necessity of talking IP for their
management plane.

That's a pretty g= ratuitous objection, given that my point was that PD can work on both hosts= and routers. ("Either a host or a router" is also technically tr= ue - see RFC 2460.)
=C2=A0
> We can't do that, because that leaves the problem of what to do o= n a
> network that has decided to provide address space only via DHCPv6. It = seems
> to me that there has been pretty strong agreement all along that such<= br> > networks should also provide sufficient address space to hosts.

"just provide multiple addresses with DHCPv6 IA_NA"?

That point is addressed in the draft in mult= iple places.
=C2=A0
Is actually quite a bi= t easier to roll out than "build a DHCPv6 PD
infrastructure"... memory on the DHCPv6 server is cheap, slots on rout= ers
are expensive.

Actually, as discussed in se= ction 9.3, one prefix per host is much more scalable than one TCAM entry pe= r address. As discussed in section 7, the number of addresses are needed if= the host does not do NAT66 can be quite high. Doing that with multiple IA_= NA entries is going to hit the last-hop routers much much harder than one /= 64 per host. Not to mention all the ND traffic that others have mentioned.<= br>

Gert: a lot of the points you make are already= discussed in the draft. If you want to make statements that these recommen= dations are misguided, then please discuss the text where the draft provide= s rationale for those recommendations, instead of attacking the recommendat= ions out of context.
--001a1140fbb016ad8c0528ba2683-- From nobody Thu Jan 7 00:24:46 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6EE1A8798 for ; Thu, 7 Jan 2016 00:24:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-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 EjgR7tZ4JKFi for ; Thu, 7 Jan 2016 00:24:44 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E7581A8797 for ; Thu, 7 Jan 2016 00:24:44 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id C36A460A99 for ; Thu, 7 Jan 2016 09:24:42 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 7D3D36082D for ; Thu, 7 Jan 2016 09:24:42 +0100 (CET) Received: (qmail 33485 invoked by uid 1007); 7 Jan 2016 09:24:42 +0100 Date: Thu, 7 Jan 2016 09:24:42 +0100 From: Gert Doering To: Lorenzo Colitti Message-ID: <20160107082442.GG58491@Space.Net> References: <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <20160106190013.GZ58491@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NLNSUTh+q3iVrawv" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 08:24:45 -0000 --NLNSUTh+q3iVrawv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Jan 07, 2016 at 05:20:31PM +0900, Lorenzo Colitti wrote: > On Thu, Jan 7, 2016 at 4:00 AM, Gert Doering wrote: >=20 > > The network is evolving - especially with homenet, the whole model of > > cascading DHCPv6-PD CPEs is being abandoned, because there are better w= ays. >=20 > Funny - Philip is arguing that this is too new and we don't know how to do > it, and you're arguing that it's legacy :-) Router-to-router it's legacy, router-to-host I find myself in surprising and unusual agreement with Philip. > > > Do we? A node is either a host or a router. > > > > Most routers are also hosts by necessity of talking IP for their > > management plane. >=20 > That's a pretty gratuitous objection, given that my point was that PD can > work on both hosts and routers. ("Either a host or a router" is also > technically true - see RFC 2460.) Then don't spell it "either...or" - and it isn't. A router is always also a host, unless you throw in funny SDN stuff that does not communicate over IPv6 for the control plane. [..] > > Is actually quite a bit easier to roll out than "build a DHCPv6 PD > > infrastructure"... memory on the DHCPv6 server is cheap, slots on route= rs > > are expensive. >=20 > Actually, as discussed in section 9.3, one prefix per host is much more > scalable than one TCAM entry per address.=20 That very much depends on the architecture of your network and devices. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --NLNSUTh+q3iVrawv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVo4gyt9WwGXkzn/FAQIhww/8C7sIVc0FIpG5ocKBFFoPHHmrhuF+nSAR jJ4qPI2f5xIJPUatZUKwW773HoVBBs18vos4mSbSzmOONCHx9yA/VEs8CuevcnrD 2RPr0eafdFyTpFvqCu/FIDdHV2W672SnNWDRwfGlPwfY16FUYHrZ/IYAqBBuCla6 YNPNkq/j557ftKJywV8OQ8UctYCweAv3adhByJfcFNwje9bZhLHpiGDwAMeD1BWX JbKMeMpzT9LFleIn9kFOuwZJiVY7pH1qjVgRRgZSkhIjWS4tmwlDQ4prBJHeEmlx ivz+HU8W1iVNXj3B4t3j4I63XyldaGoXeJvJuEhWmJhR07J6nriWCtqjIK38Reyg FZS5BxWx7yjsRknr7CPsb2x8B+BBrE5+CQ+nSAHWRBOBiFdcXGVLCWN3Ze/I40YQ j8YTzzCgLmuF6cmp7EXSQObJ7/xox7kaQc9SwWlBJA+TgBWuI3RRpZ8hvOkwv3vF X48yo0sIoJFN7hAE+Iud4DvuNgPEVLum6YEBs8t+vwdQRrckdaeNvLm605vBo7OA ChSwqnLw8HbNn74Zno9rTc4ImKg1R0x1DiPT4Ct27OkZ4dd5bgNCmdycYgfJHhQX 3kfNqTA8qzWa/rcsFgEEhOtQfyZXu+EIUIZALNXh0MdXqzlMt8x2J4v9fX5eUesF cII2xuj375s= =p0kr -----END PGP SIGNATURE----- --NLNSUTh+q3iVrawv-- From nobody Thu Jan 7 00:29:19 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2D91A87A9 for ; Thu, 7 Jan 2016 00:29:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 aMQ9i3Iblta5 for ; Thu, 7 Jan 2016 00:29:16 -0800 (PST) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3E511A87A2 for ; Thu, 7 Jan 2016 00:29:15 -0800 (PST) Received: by mail-io0-x22f.google.com with SMTP id q21so244828687iod.0 for ; Thu, 07 Jan 2016 00:29:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=PVQ9Z3FL6+2B4mXif5+6R1jXRbmWxlhdUoYO0DdlNpM=; b=geTy+04oTRyPEHruVZRrOTONXc2v6Hx3/ERKxwd34klTTkgM8D6n5Rp3wuMinoEQtu bNmzhMHq91oPHeXJo1egij5EdpRd70dGtkFdR59Qi1Gc7UzYbAjpdKY+jpXyPtWPpLlL tBaWDiUViFWNhKkicQ3FT3j84NM8w0E93PenRIvm6G/tx4zTwmfr4MJOETbUqfR7Heum i14PpF/b007UBEy1CqRpgiFyVHtlQzg1zrV+8v29Yx9a6XynT7HQM7a1AMvnH7ozMze6 XN6hc4o3tzczu0bJZm7E1eDndTne+XXi28lMZ7GNxMDMJvKiGVxol2wKmCk/saF+0gSQ G6Iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=PVQ9Z3FL6+2B4mXif5+6R1jXRbmWxlhdUoYO0DdlNpM=; b=is9FpY/zRNuAAJWLBtUTjWm91y23U4C3xOEqiZ7hSiaJwoUPavWnnYnaJUt1pwd174 K1o/osACj9zaNgHEiHAEDyrC4oKEdEebiAPXNmv1nyqKce/177pSrIkUSIaghnDXG35e x7mt2+RvOKyy//BzL6TT94X2Dwt283tMUR7kSSP36tcKpdPZSob0NV5WV/TQo3up2uoC +omz1dBurGaI33Bky7MpLWg5a++ORk1394eAffQLN7D17/e7xl557px1VJTsoXokAaYu FbIgPpJCKN7/7fvWIhEwzQtP6x71gWvGzeDtaGhPMAHd2mK9LeKJBt5UEea3QIcOmRkI 3Wgg== X-Gm-Message-State: ALoCoQli/l/HKjZxg7HhBKWDamCEIDj3vZUkPB+3NbkMYjTHNhr4hpgJ2MehbgrHDIWykiWlu+MeXTBdPzP02dDrHbpo3qUOACbPdqwyO0c9qNBt/34MKNs= X-Received: by 10.107.159.7 with SMTP id i7mr71261231ioe.29.1452155355277; Thu, 07 Jan 2016 00:29:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.26.39 with HTTP; Thu, 7 Jan 2016 00:28:55 -0800 (PST) In-Reply-To: <20160107082442.GG58491@Space.Net> References: <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <20160106190013.GZ58491@Space.Net> <20160107082442.GG58491@Space.Net> From: Lorenzo Colitti Date: Thu, 7 Jan 2016 17:28:55 +0900 Message-ID: To: Gert Doering Content-Type: multipart/alternative; boundary=001a1141bf061c90430528ba4456 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 08:29:17 -0000 --001a1141bf061c90430528ba4456 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 7, 2016 at 5:24 PM, Gert Doering wrote: > > That's a pretty gratuitous objection, given that my point was that PD can > > work on both hosts and routers. ("Either a host or a router" is also > > technically true - see RFC 2460.) > > Then don't spell it "either...or" - and it isn't. A router is always > also a host, unless you throw in funny SDN stuff that does not communicate > over IPv6 for the control plane. > RFC 2460 is not on your side. Take that up with the authors of 2460bis, not with me :-) --001a1141bf061c90430528ba4456 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 7, 2016 at 5:24 PM, Gert Doering <gert@space.net> wrote= :
> That's a pret= ty gratuitous objection, given that my point was that PD can
> work on both hosts and routers. ("Either a host or a router"= is also
> technically true - see RFC 2460.)

Then don't spell it "either...or" - and it isn't.= =C2=A0 A router is always
also a host, unless you throw in funny SDN stuff that does not communicate<= br> over IPv6 for the control plane.

RFC 24= 60 is not on your side. Take that up with the authors of 2460bis, not with = me :-)
--001a1141bf061c90430528ba4456-- From nobody Thu Jan 7 00:33:24 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92E0B1A87AE for ; Thu, 7 Jan 2016 00:33:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-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 jQ0etUzTIz6f for ; Thu, 7 Jan 2016 00:33:22 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FE6A1A87B2 for ; Thu, 7 Jan 2016 00:33:22 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 0B8F960934 for ; Thu, 7 Jan 2016 09:33:21 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id CAAA06029C for ; Thu, 7 Jan 2016 09:33:20 +0100 (CET) Received: (qmail 34115 invoked by uid 1007); 7 Jan 2016 09:33:20 +0100 Date: Thu, 7 Jan 2016 09:33:20 +0100 From: Gert Doering To: Lorenzo Colitti Message-ID: <20160107083320.GH58491@Space.Net> References: <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <20160106190013.GZ58491@Space.Net> <20160107082442.GG58491@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TfggMnVLY53OX7Tb" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 08:33:23 -0000 --TfggMnVLY53OX7Tb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Jan 07, 2016 at 05:28:55PM +0900, Lorenzo Colitti wrote: > On Thu, Jan 7, 2016 at 5:24 PM, Gert Doering wrote: >=20 > > > That's a pretty gratuitous objection, given that my point was that PD= can > > > work on both hosts and routers. ("Either a host or a router" is also > > > technically true - see RFC 2460.) > > > > Then don't spell it "either...or" - and it isn't. A router is always > > also a host, unless you throw in funny SDN stuff that does not communic= ate > > over IPv6 for the control plane. >=20 > RFC 2460 is not on your side. Take that up with the authors of 2460bis, n= ot > with me :-) The fact that some RFC states something obviously silly is no compelling reason to repeat it. Remember this when you ssh to your router next time, and ask yourself, how does the router do this, if it's not a host... :-) Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --TfggMnVLY53OX7Tb Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVo4i0N9WwGXkzn/FAQLx9BAAhHDrpG5HQHlCndOvtbSoWNS10aiBBQTv 51ZepOaGC6VpdVW+bBvnYnLG31Wy+qzpMNHyJZPrcweTr4k3qupvOsVBp6jsCaWw FuHcmV+EX0hqNtUTPMyNCZVtOKnKW8yaE4EpFGjznZP8wmUTfJowNMTFrr0e1UsS vxVlnCZzEUksdwdSrUP8lNy2mjbKR7ss9jxi6p6XunxzpZnIk+AJLN2okk7F9XDG DGc915xj12x7IxI+tqV2bpDNUi0UjpBAlR6/cYmJ1EAaHb3/2wV54fXy+3K508MJ /GkcoERJWWrr7N6W7k3RaUPbR0CikHA0T/XNdOcvLmE06ESLnnnOlGKr35Bygui1 4bB1opfwUgCg2p8mC3zVtyR1pY5ugcHyTcqGa2TcfnPBjW4O0Bobu+TsVB5Z1qDa j0ptFZE8jUn6eUgbBgLnZ72Ww9xkR8hng5ghZinKteEXz6EpRYnXcWNAIeN3uBGM U+gTyV+x5VyydCGMGRjNzzw9RHQTh7io04vcad+1sb0DyDb1o57SJw6vvm+9gnVL yM1oQpuz5O8iRR6OTZE3d2wrZ98s6NyypB8XZ0IIqej4UrHruOSL/an5Af8drJ2p PD3DD0aBOZQ3e3PXUR3E5vxlrexAsULvAvPB9jolZ+OEn2EG8vQT3zi6yVR0OOwZ Lu6Utd2W9Ns= =Js9F -----END PGP SIGNATURE----- --TfggMnVLY53OX7Tb-- From nobody Thu Jan 7 00:41:11 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 180ED1A87BE for ; Thu, 7 Jan 2016 00:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 X3gZuZr3TdQ0 for ; Thu, 7 Jan 2016 00:41:09 -0800 (PST) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19DA51A87BB for ; Thu, 7 Jan 2016 00:41:09 -0800 (PST) Received: by mail-yk0-x236.google.com with SMTP id v14so239298540ykd.3 for ; Thu, 07 Jan 2016 00:41:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=+XJNOzL0V/q7weevQ4xlPBURvJB+4OEJkWRfWRb3P3M=; b=lxOP1jXGmoo9/qRl+gtqoynjZEzRWmH5HVaN8cUFONjQpe4anouFT4ZtW4VOBsQzLK uL9oA3lQ/7UwLq6f5bSTJ9BGuZ33PfbP9Wk8R3XifRSbLXODcGiaqF9tznzQdSI+cwpa 0x4DeFj93E++TdyUXIKAoFHVFBWRfGTgGfxzSIk9cW+PW0tF+Vx1ZiVIe+ibtBJayXVn 0lNRrRwhOxlOpLcMAlDqvOtlnR6+r8u43mnFqxOU61IxXNuoP1h8nyh241rSlUH4iF7q VoELFjcodamSZ41KkTDPs6pwwBYSiX5imeH3WEX8Ly2wK1jJTDrWW4r1SjcoahoJyEty 0NlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=+XJNOzL0V/q7weevQ4xlPBURvJB+4OEJkWRfWRb3P3M=; b=h0dW4WdrU/aBn4lwY4wjbNcF9dR3Ql9nz277eWdRVFeFVIuY3nmU81l+NJjbe7IMSn Cq+Y5aH33iPZAE4CSaBbZ9rf3tgv9oTuQLUZBNXwqBD+4BNW7I1/ZmFywogcNC987ZOH 1MdnoBu9Bd9lWqci2ULurfVvj4aYrtm+4NcpdRA3LSPQwN3uX6Z9WrHr0iL/54sOEvPL fkwbXEXdcvY8AkH3tIOqqw5wgnEzcG4S2XU+zK/29o/55cZL23N+AAQEasniof8gqtdR /Uwx/3bPZLOih1DaPd49nktnxa/B404VLsNOrJPXJOUvSb9AEomSxyZClcApsxFBfgge 49Lg== X-Gm-Message-State: ALoCoQns4FUGJeRODqti9kAvslxTT+hYRmECGsDrVvuewN7Yr1pb93Zq+gRCiEvl7OzKzeRzSDljAMkDgVTlc2eF3MqaIa59yY6/glu31BXhXCdtBGifiUg= X-Received: by 10.129.157.79 with SMTP id u76mr86625382ywg.123.1452156068299; Thu, 07 Jan 2016 00:41:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.208.201 with HTTP; Thu, 7 Jan 2016 00:40:48 -0800 (PST) In-Reply-To: <20160107083320.GH58491@Space.Net> References: <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <20160106190013.GZ58491@Space.Net> <20160107082442.GG58491@Space.Net> <20160107083320.GH58491@Space.Net> From: Lorenzo Colitti Date: Thu, 7 Jan 2016 17:40:48 +0900 Message-ID: To: Gert Doering Content-Type: multipart/alternative; boundary=94eb2c0b61e89c79b60528ba6e44 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 08:41:10 -0000 --94eb2c0b61e89c79b60528ba6e44 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 7, 2016 at 5:33 PM, Gert Doering wrote: > The fact that some RFC states something obviously silly is no compelling > reason to repeat it. > Hey - I'm with you. I think that distinction is completely bogus. But when we write IETF documents, we have to write things that conform to the applicable standards, or what we write cannot be published. --94eb2c0b61e89c79b60528ba6e44 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 7, 2016 at 5:33 PM, Gert Doering <gert@space.net> wrote= :
The fact that some RFC states something= obviously silly is no compelling
reason to repeat it.

Hey - I'm with= you. I think that distinction is completely bogus. But when we write IETF = documents, we have to write things that conform to the applicable standards= , or what we write cannot be published.
--94eb2c0b61e89c79b60528ba6e44-- From nobody Thu Jan 7 00:47:51 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01BCD1A87C4 for ; Thu, 7 Jan 2016 00:47:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.388 X-Spam-Level: X-Spam-Status: No, score=-3.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 iq0_RgXCYO3e for ; Thu, 7 Jan 2016 00:47:48 -0800 (PST) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D6C81A87C1 for ; Thu, 7 Jan 2016 00:47:48 -0800 (PST) Received: by mail-yk0-x229.google.com with SMTP id v14so239434874ykd.3 for ; Thu, 07 Jan 2016 00:47:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=TPjohN/RZcKxSbWyE92rJw3TRe4OaXVTmvR2c96tIjo=; b=iAmg/T/jPzsCT35M+0rBB/EtvZaCM/g1ew57xBmQwJQaiVmQOKo2ciABtSGyp7xAMm 0iAoMVxegqkobJ8kFsqRJ7lbCykSxbYkFOAQyTvLlRBf3ur+RqkslNq3CcJNcBO22PO7 w4QEdn2mDqmtpx7KU+gAsUb1thz8ZKm8ZT711NOnA3kQcKLM+DceCGcvoeJ4X7smmgHm 8VlebFOBOSjKItWEPmp+ISUJTL2MxbKInLLyGLI49YaqDXJk2Wpn5ZD6olgf8iXH/LJk pockP1bpcGENHjST6Yzt6AC42Kv3b5NAECvxu5LGcuEeb7sowmqk2pHg4u0XwQM4cXkC Pdrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=TPjohN/RZcKxSbWyE92rJw3TRe4OaXVTmvR2c96tIjo=; b=Qjby2jy5HpywV2dUnD0VFOGdu2nyNWkB9FMOMhonqerdnCPwMKsFpby5Q/y61WDQU1 3GjKnsZToc9uh1wggZwQylL36TDRtYlt0Z4YY9VHUFUve7O7Zty+yBSGb7fOcsuzkQ2P RcYIHJpkzacWXUSk2c+BpYuTriFBrMeqgTLz8MkVpDc1mp4xBZ91AHmVfQxb6xOSbaS0 XX5jekmi/A1GAL0rZPKqiAMbeo8+c+mxZ2L6/tj3b0eOJNYTOhBd7n5rYdrdRmm1X9DB npthA3/IWORUqvv9lNj4S/3Ays8pE64TsiwIxdOuXXrIg7RfzNbLZFbzv5qL2pvU2fBl lOaA== X-Gm-Message-State: ALoCoQnIGm+/1xP/qK/FMxlRAqn0Lc6mk4koarqSipK/en91vb3unww8ZGPNbOsAiZuJdZDseWTgvUm2pplP70rl7exej8r6wFDYtpYRPri0FJ9rfAGYzQY= X-Received: by 10.129.41.17 with SMTP id p17mr74457359ywp.160.1452156467788; Thu, 07 Jan 2016 00:47:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.208.201 with HTTP; Thu, 7 Jan 2016 00:47:27 -0800 (PST) In-Reply-To: <568D8C1C.2020406@umn.edu> References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <568D8C1C.2020406@umn.edu> From: Lorenzo Colitti Date: Thu, 7 Jan 2016 17:47:27 +0900 Message-ID: To: David Farmer Content-Type: multipart/alternative; boundary=001a11407ee86c36820528ba8646 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 08:47:50 -0000 --001a11407ee86c36820528ba8646 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 7, 2016 at 6:50 AM, David Farmer wrote: > If the network requires explicit requests for address space (e.g., > if it requires DHCPv6 to connect), the network MAY assign a /64 > prefix to every host (e.g., via DHCPv6 PD). And if it doesn't choose to observe the MAY, then what? The network will end up restricting the amount of address space available to the host, right? So it will violate the spirit of this draft, but not the letter? --001a11407ee86c36820528ba8646 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 7, 2016 at 6:50 AM, David Farmer <farmer@umn.edu> wrote= :
=C2=A0 =C2=A0If the network requires ex= plicit requests for address space (e.g.,
=C2=A0 =C2=A0if it requires DHCPv6 to connect), the network MAY assign a /6= 4
=C2=A0 =C2=A0prefix to every host (e.g., via DHCPv6 PD).
<= br>
And if it doesn't choose to observe the MAY, then what? T= he network will end up restricting the amount of address space available to= the host, right? So it will violate the spirit of this draft, but not the = letter?
--001a11407ee86c36820528ba8646-- From nobody Thu Jan 7 00:49:04 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A26E31A87C1 for ; Thu, 7 Jan 2016 00:49:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.61 X-Spam-Level: X-Spam-Status: No, score=-4.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-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 pBvP23o_zzs8 for ; Thu, 7 Jan 2016 00:49:01 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C7811A87BF for ; Thu, 7 Jan 2016 00:49:01 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id EC81B6029C for ; Thu, 7 Jan 2016 09:48:59 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id A86C960737 for ; Thu, 7 Jan 2016 09:48:59 +0100 (CET) Received: (qmail 34977 invoked by uid 1007); 7 Jan 2016 09:48:59 +0100 Date: Thu, 7 Jan 2016 09:48:59 +0100 From: Gert Doering To: Lorenzo Colitti Message-ID: <20160107084859.GI58491@Space.Net> References: <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <568D8C1C.2020406@umn.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 08:49:02 -0000 Hi, On Thu, Jan 07, 2016 at 05:47:27PM +0900, Lorenzo Colitti wrote: > On Thu, Jan 7, 2016 at 6:50 AM, David Farmer wrote: > > > If the network requires explicit requests for address space (e.g., > > if it requires DHCPv6 to connect), the network MAY assign a /64 > > prefix to every host (e.g., via DHCPv6 PD). > > And if it doesn't choose to observe the MAY, then what? The network will > end up restricting the amount of address space available to the host, > right? So it will violate the spirit of this draft, but not the letter? It might just decide that up-to-100 IA_NA fits the restrictions of the local gear better than PD, and does that instead. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Thu Jan 7 01:11:11 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 842EC1A87EB for ; Thu, 7 Jan 2016 01:11:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 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, FROM_LOCAL_NOVOWEL=0.5, GB_I_LETTER=-2, HK_RANDOM_ENVFROM=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 yoOZcMXaIHdH for ; Thu, 7 Jan 2016 01:11:07 -0800 (PST) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A99C41A87E7 for ; Thu, 7 Jan 2016 01:11:07 -0800 (PST) Received: by mail-vk0-x22f.google.com with SMTP id i129so32491315vkb.0 for ; Thu, 07 Jan 2016 01:11:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1nIapT3MG+KRYZZba1uV50lWuNlVzcAYlKGcj/lXYY4=; b=WMA6cmp9DObRLK/1e9JPkt5xonurdGItky2iyF5pRi0xgKzqgyhfub9dnzluZyYV6e 7Tf08Vngsc3nvr8P+iLiraJIBV5ul/t9guebOApsqI6HepGzMRVN8Iifo0C24PQ4Yvt2 PrFIH4cznpsRqZgZFRgXrMMY0iQmb1IZm1us8B2ZzijQ22G4SBA313DwLVzsivMkpHaO nCOwGDDPvF0AePOTyrGj5sqid8zUVgtVOxjuF4945why11sJy1Rf0lsSVJsP2kp56ozs aq6MmSHO1bJ3l2vj7PH65lGDZgncK/sOkZ5MnwltiurngebgQQoxE7RKI+a/RxXPk5gs cZsQ== MIME-Version: 1.0 X-Received: by 10.31.6.143 with SMTP id 137mr73474190vkg.133.1452157866707; Thu, 07 Jan 2016 01:11:06 -0800 (PST) Received: by 10.103.99.1 with HTTP; Thu, 7 Jan 2016 01:11:06 -0800 (PST) Received: by 10.103.99.1 with HTTP; Thu, 7 Jan 2016 01:11:06 -0800 (PST) In-Reply-To: <20160107084859.GI58491@Space.Net> References: <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <568D8C1C.2020406@umn.edu> <20160107084859.GI58491@Space.Net> Date: Thu, 7 Jan 2016 20:11:06 +1100 Message-ID: From: Mark Smith To: Gert Doering Content-Type: multipart/alternative; boundary=001a1143d338cd90630528bad9bf Archived-At: Cc: v6ops list Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 09:11:09 -0000 --001a1143d338cd90630528bad9bf Content-Type: text/plain; charset=UTF-8 On 7 Jan 2016 7:49 PM, "Gert Doering" wrote: > > Hi, > > On Thu, Jan 07, 2016 at 05:47:27PM +0900, Lorenzo Colitti wrote: > > On Thu, Jan 7, 2016 at 6:50 AM, David Farmer wrote: > > > > > If the network requires explicit requests for address space (e.g., > > > if it requires DHCPv6 to connect), the network MAY assign a /64 > > > prefix to every host (e.g., via DHCPv6 PD). > > > > And if it doesn't choose to observe the MAY, then what? The network will > > end up restricting the amount of address space available to the host, > > right? So it will violate the spirit of this draft, but not the letter? > > It might just decide that up-to-100 IA_NA fits the restrictions of the > local gear better than PD, and does that instead. > IOW, some networks might want to do that, others might want to delegate a /64 or greater via DHCPv6-PD. This argument is getting into minutiae about applicability, possibility and parameters of specific methods. That sounds to me like the main and fundamental point is accepted by everyone. So I'd say ship it. > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --001a1143d338cd90630528bad9bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 7 Jan 2016 7:49 PM, "Gert Doering" <gert@space.net> wrote:
>
> Hi,
>
> On Thu, Jan 07, 2016 at 05:47:27PM +0900, Lorenzo Colitti wrote:
> > On Thu, Jan 7, 2016 at 6:50 AM, David Farmer <farmer@umn.edu> wrote:
> >
> > >=C2=A0 =C2=A0 If the network requires explicit requests for a= ddress space (e.g.,
> > >=C2=A0 =C2=A0 if it requires DHCPv6 to connect), the network = MAY assign a /64
> > >=C2=A0 =C2=A0 prefix to every host (e.g., via DHCPv6 PD).
> >
> > And if it doesn't choose to observe the MAY, then what? The n= etwork will
> > end up restricting the amount of address space available to the h= ost,
> > right? So it will violate the spirit of this draft, but not the l= etter?
>
> It might just decide that up-to-100 IA_NA fits the restrictions of the=
> local gear better than PD, and does that instead.
>

IOW, some networks might want to do that, others might want = to delegate a /64 or greater via DHCPv6-PD.

This argument is getting into minutiae about applicability, = possibility and parameters of specific methods. That sounds to me like the = main and fundamental point is accepted by everyone.

So I'd say ship it.

> Gert Doering
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- NetMaster
> --
> have you enabled IPv6 on something today...?
>
> SpaceNet AG=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Vorstand: Sebastian v. Bomhard
> Joseph-Dollinger-Bogen 14=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Aufsichtsr= atsvors.: A. Grundner-Culemann
> D-80807 Muenchen=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0USt-I= dNr.: DE813185279
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--001a1143d338cd90630528bad9bf-- From nobody Thu Jan 7 01:12:42 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31FF01A8820 for ; Thu, 7 Jan 2016 01:12:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 O1qlMfRpqnGl for ; Thu, 7 Jan 2016 01:12:39 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46FAF1A87B8 for ; Thu, 7 Jan 2016 01:12:39 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 8FFF56091B for ; Thu, 7 Jan 2016 10:12:37 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 4FCDC6029C for ; Thu, 7 Jan 2016 10:12:37 +0100 (CET) Received: (qmail 36812 invoked by uid 1007); 7 Jan 2016 10:12:37 +0100 Date: Thu, 7 Jan 2016 10:12:37 +0100 From: Gert Doering To: Mark Smith Message-ID: <20160107091237.GJ58491@Space.Net> References: <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <568D8C1C.2020406@umn.edu> <20160107084859.GI58491@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2dPm0VI6SEKnX4rW" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: v6ops list Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 09:12:41 -0000 --2dPm0VI6SEKnX4rW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Jan 07, 2016 at 08:11:06PM +1100, Mark Smith wrote: > > It might just decide that up-to-100 IA_NA fits the restrictions of the > > local gear better than PD, and does that instead. >=20 > IOW, some networks might want to do that, others might want to delegate a > /64 or greater via DHCPv6-PD. Right. > This argument is getting into minutiae about applicability, possibility a= nd > parameters of specific methods. That sounds to me like the main and > fundamental point is accepted by everyone. >=20 > So I'd say ship it. No. Neither as a BCP, nor with the strong recommendation for DHCPv6-PD, nor with the emphasis on /64 (if DHCPv6-PD). What you say above is about choice, but the draft isn't. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --2dPm0VI6SEKnX4rW Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVo4sBd9WwGXkzn/FAQIamg//WgiGF5NSzuoMyjv+NgRJ9glbT1wfmdnK n83ZrEI3z6lesfAuEm+RPoNMOhVuSecZU+fUv+gKzYPUxmLIS/2P+i5yuD2MkwdB kbOOJfnG1Mqs/4paa6o1tlhW78fjT9TqluV13t7odw4nGDwJdvTBV8J7LrwIbhLT b6A0D87rhNKj+y+9uYBuc0Unka0QsMguAEeFYiBGRaJVxXhnYxJhYTQFNswauPfz cFu4RicL9s3ktl029liJn1QnrGQmEPjH5p+afSFX43w2xBRUamq6BIDf47nydSmS aX9AtWwfPC1wrwshEeKYZEoeYYvDxEroDV75sTwnTztwWTpLxxiSzauBDfx89B8Q UggcS0Dp3rLfDjPbJXRv8gfPbA5BwPYJQW/rrlGGS7p8FMkGcHxvqZLR9A2tHjWt JCjtSDexMEjpK7oomVzSyJn/4H45nns/e02oUiSC8JslNHGPSdCkQA2yQ82+xGRl f8Uv2n2o4D6EvUvb1nCbwQ65fc9seOkjwPQHrf8NeX/ES7jYlpJsmSBdToZU1JpE 5tkF15UcVKyL5eBX9wTXFWgfFrGDiYaAaQby7Jgt2mIDdRCz/fbGkZqKKKLGS7U7 c7cKVDgG9fUzfvvIkSxvamklwVpa8NzpQE5Wax1pf/aGRpe80iiTd2trmgQjuiIt za0WNMIV/xs= =bWUG -----END PGP SIGNATURE----- --2dPm0VI6SEKnX4rW-- From nobody Thu Jan 7 01:40:32 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CADBF1A884B for ; Thu, 7 Jan 2016 01:40:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.111 X-Spam-Level: X-Spam-Status: No, score=-6.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 HJSGYnCo9PAQ for ; Thu, 7 Jan 2016 01:40:29 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 27CB61A8845 for ; Thu, 7 Jan 2016 01:40:28 -0800 (PST) Received: from [IPv6:2620::930:0:ae87:a3ff:fe29:7192] ([IPv6:2620:0:930:0:ae87:a3ff:fe29:7192]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id u079dQIj030942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 7 Jan 2016 01:39:26 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Owen DeLong In-Reply-To: <20160107073826.GC58491@Space.Net> Date: Thu, 7 Jan 2016 01:39:25 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <77D73493-ABAB-4D00-B941-C447A4D9CF31@delong.com> References: <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <568D8C1C.2020406@umn.edu> <20160107073826.GC58491@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 09:40:30 -0000 > On Jan 6, 2016, at 23:38 , Gert Doering wrote: >=20 > Hi, >=20 > On Wed, Jan 06, 2016 at 03:50:20PM -0600, David Farmer wrote: >> If the network requires explicit requests for address space (e.g., >> if it requires DHCPv6 to connect), the network MAY assign a /64 >> prefix to every host (e.g., via DHCPv6 PD). =20 >=20 > This is much better. It remains a somewhat unexplained mystery, = though, > why the recommendation is to delegate a /64. =20 >=20 > Why not a /96? (Which would still be more addresses than the host=20 > could ever configure locally) >=20 > Why not a /60, so internal virtual subnets on the host could be = accomodated, > if that is what "we" want? >=20 > If "we" recommend burning /64s in large scale, has someone done math = what > this does to the /48 which is typically permitted per site if that = site > has a large number of users requesting prefixes? No real need to do so=E2=80=A6 1. The /48 is the minimum amount allowed per site without further = justification by all RIRs currently. 2. Every RIR policy I am familiar with allows for more than a /48 per = site if need can be shown. ARIN policy also defines site in such a way = that each customer in the same site could be considered a =E2=80=9Ctenant = in a multitenant structure=E2=80=9D allowing for each tenant to be considered a = separate site. Owen >=20 From nobody Thu Jan 7 01:45:12 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6461A8850 for ; Thu, 7 Jan 2016 01:45:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.111 X-Spam-Level: X-Spam-Status: No, score=-6.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 A4kCZdsUxr3B for ; Thu, 7 Jan 2016 01:45:08 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id A13181A884D for ; Thu, 7 Jan 2016 01:45:07 -0800 (PST) Received: from [IPv6:2620::930:0:ae87:a3ff:fe29:7192] ([IPv6:2620:0:930:0:ae87:a3ff:fe29:7192]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id u079i3Uo031177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 7 Jan 2016 01:44:03 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Owen DeLong In-Reply-To: <20160107081951.GF58491@Space.Net> Date: Thu, 7 Jan 2016 01:44:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8469944B-C14A-4120-A234-3F4CC5DF2900@delong.com> References: <568D8C1C.2020406@umn.edu> <20160107073826.GC58491@Space.Net> <20160107075820.GE58491@Space.Net> <20160107081951.GF58491@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 09:45:09 -0000 > On Jan 7, 2016, at 00:19 , Gert Doering wrote: >=20 > Hi, >=20 > On Thu, Jan 07, 2016 at 05:11:36PM +0900, Lorenzo Colitti wrote: >>> Please spell out clearly that using this technology is not = RIR-sanctioned >>> and will not entitle them to a single extra IPv6 subnet. >> RIR policies can be changed, and if this document is published, it = should >> not be hard to change them. I cannot imagine anyone at a RIR = successfully >> arguing that assigning a /40 to a medium-sized enterprise is = wasteful. >=20 > I can see myself in that position. IETF recommendation is "/48 per = site", > and this is what the RIRs are following. Unless RIPE tightened things up since the last time I looked, I=E2=80=99m = pretty sure that you can justify more than a /48 for a site _IF_ you have adequate justification. I also believe that the RIPE PDWG would do the needful if this is adopted and there is an issue. > I have a hard time argueing for more than 64k subnets at a single site > if that is all virtual in the end. That=E2=80=99s a different problem and while I=E2=80=99m somewhat = inclined to agree with you, I think for purposes of this particular draft, it=E2=80=99s really a = corner case. > (And knowing RIR communities, you won't find many more people = supporting > a somewhat conservative approach than "just don't care, out with the = bits=E2=80=9D) I=E2=80=99m somewhat familiar with RIR communities and the policies they = produce. I don=E2=80=99t see a genuine problem here. Owen From nobody Thu Jan 7 01:47:09 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC54E1A884E for ; Thu, 7 Jan 2016 01:47:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.308 X-Spam-Level: X-Spam-Status: No, score=-6.308 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 Hafd7FYh3JYD for ; Thu, 7 Jan 2016 01:47:07 -0800 (PST) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.119.20]) by ietfa.amsl.com (Postfix) with ESMTP id 163AD1A884C for ; Thu, 7 Jan 2016 01:47:07 -0800 (PST) Received: from mail-io0-f179.google.com (mail-io0-f179.google.com [209.85.223.179]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128/128); for ; Thu, 7 Jan 2016 03:47:05 -0600 (CST) X-Umn-Remote-Mta: [N] mail-io0-f179.google.com [209.85.223.179] #+LO+TS+TR X-Umn-Classification: local Received: by mail-io0-f179.google.com with SMTP id 1so199865861ion.1 for ; Thu, 07 Jan 2016 01:47:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:from:subject:date:to; bh=C+8k+daZXDw/QKdd9WSWx4FLvpPwA6QzIDkR3Jh+7Sc=; b=f1AWVTE3iVsQ/dIwinHCdEYnngk7MwGotZenlBnn++5WDDCc/d/0qMXG/6i3MqAsnl zO6dwULWaCs4JwiJf8FqN0oMOc/DNSrWytREx7/r/tkHMKBwP3QX5UvmPkTmnmBGjNLD mX9pxuxvU98TS8QDbtrETSNs5EN1vQZf8y3L0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:from:subject :date:to; bh=C+8k+daZXDw/QKdd9WSWx4FLvpPwA6QzIDkR3Jh+7Sc=; b=NFMwHX/BleR2kdD3qauYGphF3t4zgiWpCuygsi8m58fqKTKQXcMuFqZI+JJFHkA57y YEZy2XPyk4d8rELPm1zR4mHIEx35o/ifRvfIqSiAeMTyyfEYC2hYcHhPDPZfSTTR6NFa R9AHi9hJVwLKOFzvODc43CbfKbNyUOtyHklqOFK7EMkspw+dDypnwHIupa+PjQuHwZGx DAoEeGcoeSSc9uOd6FZil/rxxWJ/m/D6l87+MTD6jusUNMY+Fhgdtxdnnhylg9atE+MM 7te+sdo+SMzLWAjsJnlPq4RwUDrhdfNhDlipXgXx1X2STjzZ0Hm5aX7SqFnmLU6a8ZEE Aa3Q== X-Gm-Message-State: ALoCoQnDoknhG4h2wS8y7u863ZrB8SOVvRTLmeBIPu9mc52JkQxRdto1WOrUnNCvdIqcaifGvZBznmR0/k5AJcCUvVe6I+cAT9MxRjzOFXvbLSOONJ2pGnaA5heLIhVHZ99L4m3tgz9iL3pVFEy4W+bpfrkGqNZsPw== X-Received: by 10.107.133.211 with SMTP id p80mr93519504ioi.16.1452160025012; Thu, 07 Jan 2016 01:47:05 -0800 (PST) X-Received: by 10.107.133.211 with SMTP id p80mr93519489ioi.16.1452160024816; Thu, 07 Jan 2016 01:47:04 -0800 (PST) Received: from [10.0.0.7] (c-68-47-68-88.hsd1.mn.comcast.net. [68.47.68.88]) by smtp.gmail.com with ESMTPSA id a5sm4604137iga.7.2016.01.07.01.47.02 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Jan 2016 01:47:03 -0800 (PST) References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <568D8C1C.2020406@umn.edu> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-31115650-D3CE-4910-9C05-09A91A21BBC9 Message-Id: X-Mailer: iPad Mail (13C75) From: David Farmer Date: Thu, 7 Jan 2016 03:47:01 -0600 To: Lorenzo Colitti Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 09:47:08 -0000 --Apple-Mail-31115650-D3CE-4910-9C05-09A91A21BBC9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On Jan 7, 2016, at 02:47, Lorenzo Colitti wrote: >=20 >> On Thu, Jan 7, 2016 at 6:50 AM, David Farmer wrote: >> If the network requires explicit requests for address space (e.g., >> if it requires DHCPv6 to connect), the network MAY assign a /64 >> prefix to every host (e.g., via DHCPv6 PD). >=20 > And if it doesn't choose to observe the MAY, then what? The network will e= nd up restricting the amount of address space available to the host, right? S= o it will violate the spirit of this draft, but not the letter? Are you saying that the use of DHCPv6 IN_NA has to violate the spirit of thi= s draft? And, to meet the spirit you have to use DHCPv6 PD or SLAAC? If you are, then you have to be more clear about that, because that's not ho= w I read even your current text. And if that is the case then you would nee= d a MUST use DHCPv6 PD, not a RECOMMENDED anyway. And, I'm not sure there i= s consensus for a MUST, especially since that would essentially deprecate DH= CPv6 IN_NA. Personally, I'm fine with RECOMMENDED, but even that doesn't mean that use o= f DHCPv6 IN_NA violates the intent of this draft as I read it. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota =20 2218 University Ave SE Phone: +1-612-626-0815 Minneapolis, MN 55414-3029 Cell: +1-612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --Apple-Mail-31115650-D3CE-4910-9C05-09A91A21BBC9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On Jan 7, 2016, at 02:4= 7, Lorenzo Colitti <lorenzo@google.= com> wrote:

On Thu, Jan 7, 201= 6 at 6:50 AM, David Farmer <farmer@umn.edu> wrote:
   If the network requires explicit requests fo= r address space (e.g.,
   if it requires DHCPv6 to connect), the network MAY assign a /64=
   prefix to every host (e.g., via DHCPv6 PD).
And if it doesn't choose to observe the MAY, then what? The net= work will end up restricting the amount of address space available to the ho= st, right? So it will violate the spirit of this draft, but not the letter?<= /div>

Are you saying that the use of DHCPv6 IN_NA has t= o violate t= he spirit of this draft?  And, to meet the spirit you have to use DHCPv= 6 PD or SLAAC?

If you are, then you have to be more= clear about that, because that's not how I read even your current text. &nb= sp;And if that is the case then you would need a MUST use DHCPv6 PD, not a RECOMMENDED anyway.&= nbsp; And, I'm not sure there is consensus for a MUST, especiall= y since that would essentially deprecate DHCPv6 IN_NA.

Personally, I'm fine with RECOMMENDED, but even that doesn't mean= that use of DHCPv6 IN_NA violates the intent of this draft as I r= ead it.

-- 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
David Farmer           &nbs= p;              Email: farmer@umn.edu
Office of Information Technology
University= of Minnesota    
2218 University Ave SE        = ; Phone: +1-612-626-0815
Minneapolis, MN 55414-3029   Cell: +1-612-812-9= 952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


= --Apple-Mail-31115650-D3CE-4910-9C05-09A91A21BBC9-- From nobody Thu Jan 7 02:57:38 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A9D1A86F0 for ; Thu, 7 Jan 2016 02:57:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.388 X-Spam-Level: X-Spam-Status: No, score=-3.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 TiSjRPZbl1jI for ; Thu, 7 Jan 2016 02:57:34 -0800 (PST) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66FDB1A88AC for ; Thu, 7 Jan 2016 02:57:34 -0800 (PST) Received: by mail-yk0-x232.google.com with SMTP id a85so258024702ykb.1 for ; Thu, 07 Jan 2016 02:57:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=s/9aHo3cr3MBEDYDKCVRG+yxVUwxirkQ3g+8gkdVeyk=; b=gekNz2/y5O4XgOjKO0uR6DB5dedXUs2QUSAvor0/BQhOKNIYMo3N9uANW+0R9pxtn5 laRzMgnIAggOIN/Ouio/JaMHJ2eKOH3RQkd98ibXhsxVVrrxYnPk4NFBBv7luHtbMba9 SUgz7umLrzfR1mXkqxJPPM1NDbTTScyrkYlxty28kFIsZdPW5zp1F9XMFQMHzBJg7EXH snuowtt3HoyDX+gMReUVkHrlsKIoOhHpsp9ZlxKA145mHIWSMVwD027uPPots2NhxuhS miiE6epGW4aHUYzEY2UzjpJJx9p9UZ0PRwnIZAOBYmx56xcIOGZFwzhCL7ME136aPI4g CeCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=s/9aHo3cr3MBEDYDKCVRG+yxVUwxirkQ3g+8gkdVeyk=; b=U5xIiGckt11XUqSb+WAVo2k9054bFn8nsWtFd6g331p4ctg9f5Zh/7OkVZDEN8EAlc syBUNHzETXK1B0BCPye54Yyp0nYU8z/Fh/U9swRcI49dPwybWHJVKYITmUjCMh/e9Mlr IJ6EMqUzwFUglcxx4iAWVZmx3TZDSo252rMbUlShjSVTJnMxbQM2DYZluH3XN+BJZ/Yk M5J3opENsAqio9pgZCobz4RfVKA5kBOlvoPQ248Kke3kNAb1Gb5bYqqRstMktfVYAtFp PdvXHTdpMC+3TgjindknT6rjaww+bj95c8cZ311Ezk4/Ci5YKOvDtzIDk86Agskb8AKS gceQ== X-Gm-Message-State: ALoCoQn1zBveHod7iQToLnqZU+sOFdWwEQrGSV/wGG60Ai2w6GwTHIlK4iMm4ply+Tb6E22v2uXpnq4sTIv2K0uieio7F3a6n/6AwEAoWwLFU1B95WcqW/k= X-Received: by 10.129.45.137 with SMTP id t131mr73539800ywt.337.1452164253628; Thu, 07 Jan 2016 02:57:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.208.201 with HTTP; Thu, 7 Jan 2016 02:57:13 -0800 (PST) In-Reply-To: <20160107084859.GI58491@Space.Net> References: <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <568D8C1C.2020406@umn.edu> <20160107084859.GI58491@Space.Net> From: Lorenzo Colitti Date: Thu, 7 Jan 2016 19:57:13 +0900 Message-ID: To: Gert Doering Content-Type: multipart/alternative; boundary=001a1141e9b67ea8a50528bc56bf Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 10:57:36 -0000 --001a1141e9b67ea8a50528bc56bf Content-Type: text/plain; charset=UTF-8 On Thu, Jan 7, 2016 at 5:48 PM, Gert Doering wrote: > > And if it doesn't choose to observe the MAY, then what? The network will > > end up restricting the amount of address space available to the host, > > right? So it will violate the spirit of this draft, but not the letter? > > It might just decide that up-to-100 IA_NA fits the restrictions of the > local gear better than PD, and does that instead. Sigh. We've been over all of this already. There are many problems with that. The first is that the host can't know in advance that network A provides 100 IA_NA, network B provides 8, and network C provides 1. That leaves the choice between three bad options: 1. Start from 256 IA_NA, and if you don't get them, keep asking for smaller numbers until you get what you want. That's not in the draft because I think almost everyone would agree it's silly. 2. Hope that the IETF or the industry agrees on a reasonable minimum number of addresses (where what is "reasonable" is in section 7) that hosts can expect will be widely accepted. That's not in the draft because it seems unlikely. 3. Ask for 1 IA_NA to start with, and whenever you need more, ask again. The problems with this strategy are dealt with in section 4. If you haven't read that, here's a summary: code complexity, high latency, user aggravation when they can't do what they want (e.g., the hotel network they connect to won't allow them to start a VM), and consequent pressure on host implementers to implement NAT66. (I know that's what I would do.) For the reasons that #3 above is bad, the draft recommends that addresses be made available to hosts "when they connect to the network". And here there's another problem: even if the host somehow knew that it can get 100 IA_NA, that won't fit in an IPv6 packet, because an IA_NA is 44 bytes long, so the practical maximum is around 30-35 for a 1280-1500 MTU. (Yes, there is a Fragment header. No, it won't work in practice, and you know it.) When you consider extending the network you have another problem. Every level of hierarchy (tethered device, VM inside a container, etc.) needs to act as a DHCPv6 relay. (Don't say "bridging" because that doesn't work on wifi except using MAC NAT or virtually-impossible-to-deploy WDS.) And so on. From the point of view of a host implementer and of a user, that's a total nightmare. Search the archives for the total nightmare that is implementing ePDG on a split application processor/baseband processor architecture with only one IPv4 address. This is what your phone does when you do wifi calling, and the result is either an unreliable device, or lack of other features because so much software engineering time had to be spent on getting it right. Implementing NAT66 is way easier than that. I think nobody in this working group wants things to go that way, but that's what will happen if we go this route. --001a1141e9b67ea8a50528bc56bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 7, 2016 at 5:48 PM, Gert Doering <gert@space.net> wrote= :
> And if it d= oesn't choose to observe the MAY, then what? The network will
> end up restricting the amount of address space available to the host,<= br> > right? So it will violate the spirit of this draft, but not the letter= ?

It might just decide that up-to-100 IA_NA fits the restrictions= of the
local gear better than PD, and does that instead.

Sigh. We've been over all of this already. There are many proble= ms with that.

The first is that the host can't= know in advance that network A provides 100 IA_NA, network B provides 8, a= nd network C provides 1. That leaves the choice between three bad options:<= /div>
  1. Start from 256 IA_NA, and if you don't get them, keep= asking for smaller numbers until you get what you want. That's not in = the draft because I think almost everyone would agree it's silly.
  2. Hope that the IETF or the industry agrees on a reasonable minimum nu= mber of addresses (where what is "reasonable" is in section 7) th= at hosts can expect will be widely accepted. That's not in the draft be= cause it seems unlikely.
  3. Ask for 1 IA_NA to start with, and wheneve= r you need more, ask again. The problems with this strategy are dealt with = in section 4. If you haven't read that, here's a summary: code comp= lexity, high latency, user aggravation when they can't do what they wan= t (e.g., the hotel network they connect to won't allow them to start a = VM), and consequent pressure on host implementers to implement NAT66. (I kn= ow that's what I would do.)
For the reasons that #3 above= is bad, the draft recommends that addresses be made available to hosts &qu= ot;when they connect to the network".

And her= e there's another problem: even if the host somehow knew that it can ge= t 100 IA_NA, that won't fit in an IPv6 packet, because an IA_NA is 44 b= ytes long, so the practical maximum is around 30-35 for a 1280-1500 MTU. (Y= es, there is a Fragment header. No, it won't work in practice, and you = know it.)

When you consider extending the ne= twork you have another problem. Every level of hierarchy (tethered device, = VM inside a container, etc.) needs to act as a DHCPv6 relay. (Don't say= "bridging" because that doesn't work on wifi except using MA= C NAT or virtually-impossible-to-deploy WDS.)

And = so on. From the point of view of a host implementer and of a user, that'= ;s a total nightmare. Search the archives for the total nightmare that is i= mplementing ePDG on a split application processor/baseband processor archit= ecture with only one IPv4 address. This is what your phone does when you do= wifi calling, and the result is either an unreliable device, or lack of ot= her features because so much software engineering time had to be spent on g= etting it right.

Implementing NAT66 is way easier = than that. I think nobody in this working group wants things to go that way= , but that's what will happen if we go this route.
--001a1141e9b67ea8a50528bc56bf-- From nobody Thu Jan 7 03:10:24 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB031A88C9 for ; Thu, 7 Jan 2016 03:10:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.388 X-Spam-Level: X-Spam-Status: No, score=-3.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 zb8LBGxZJ4zF for ; Thu, 7 Jan 2016 03:10:21 -0800 (PST) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7181F1A88C6 for ; Thu, 7 Jan 2016 03:10:21 -0800 (PST) Received: by mail-yk0-x22d.google.com with SMTP id x67so336043634ykd.2 for ; Thu, 07 Jan 2016 03:10:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=yv6or4FV/ataFm77IqgpKSeZQBbQFarNvzYLIBVGvWw=; b=crLWqLxIpaUvSVcMuDWw1w13EhLGkGcr+lCr0l5/rqyFxYCTWiamEnlzpdmVrI3g+I Ki4IxI4461ir5uTJlGFKEFmr3fJ8Kc0S7aONmYgiYBAdNtjO20I8I+c6xQQlpkaFww1v 7/au0v2+KapB1egXhioD1i2EdFr87voCrdvksdvdQ/E4Eni3963/LqTKqJOeKpJa8EvN pftId94/+GUXIrh6EiXAH0OX1G+zAPAjZG7Fxt3uE9d1ZXmUt/Lh+KHLlTNI2vR06Ex2 nkZO9I/4OzsJZ+sM/pzTBMCDKiJ5Wey2ulB+zh+sPOpJcs6XLXU63wLXnFM7grYTew/f IR6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=yv6or4FV/ataFm77IqgpKSeZQBbQFarNvzYLIBVGvWw=; b=DGK4DeCymvoUMFPbMhrmU1UIDRIP9qcnrbIDtYmryHiXhwGYFBb/HP0W//LqFoc4af ETq5w479xGPVSOmOtdATmwEuGMqHqnYEcxxTqIxhUvB7CfausTbuCcMgw2PD0OYPkAEp Fy3Xv3sMJ7oV2Z21NTy2xLniV/MIP4vSNYvxm6WVmSvxI/WV8qDKCk4RrHwFJDB+s4ks N5noNgYtg/gD/tTDgxD6mzopbYbUtmNwhdUySb0F0EQ6A8P32ADF7BzqCvYsFkXHjF27 X2cCK2T5UjWb2Yy2b0ZuzDE73sMr5qvCHUI5hJfVdnLCsgQuq07Ctcoig2cXToMkLwwL enFQ== X-Gm-Message-State: ALoCoQldnDADhqqxMS6kL0+pAbC/SYQCZYox1J2ibQerNmSeHmVtDZ9vrW37J/0OwZG/RrDPjCJ8hJIav7Yms7h1hsc/GcG4zzAkNk/CXwuyFcv4Rh2ixlg= X-Received: by 10.129.45.137 with SMTP id t131mr73599689ywt.337.1452165020591; Thu, 07 Jan 2016 03:10:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.208.201 with HTTP; Thu, 7 Jan 2016 03:10:00 -0800 (PST) In-Reply-To: References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <568D8C1C.2020406@umn.edu> From: Lorenzo Colitti Date: Thu, 7 Jan 2016 20:10:00 +0900 Message-ID: To: David Farmer Content-Type: multipart/alternative; boundary=001a1141e9b635b0cd0528bc842f Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 11:10:23 -0000 --001a1141e9b635b0cd0528bc842f Content-Type: text/plain; charset=UTF-8 On Thu, Jan 7, 2016 at 6:47 PM, David Farmer wrote: > > On Thu, Jan 7, 2016 at 6:50 AM, David Farmer wrote: > >> If the network requires explicit requests for address space (e.g., >> if it requires DHCPv6 to connect), the network MAY assign a /64 >> prefix to every host (e.g., via DHCPv6 PD). > > > And if it doesn't choose to observe the MAY, then what? The network will > end up restricting the amount of address space available to the host, > right? So it will violate the spirit of this draft, but not the letter? > > > Are you saying that the use of DHCPv6 IN_NA has to violate the spirit of > this draft? And, to meet the spirit you have to use DHCPv6 PD or SLAAC? > > If you are, then you have to be more clear about that, because that's not > how I read even your current text. And if that is the case then you > would need a MUST use DHCPv6 PD, not a RECOMMENDED anyway. And, I'm not > sure there is consensus for a MUST, especially since that would essentially > deprecate DHCPv6 IN_NA. > > Personally, I'm fine with RECOMMENDED, but even that doesn't mean that use > of DHCPv6 IN_NA violates the intent of this draft as I read it. > When you say "IA_NA", do you mean "IA_NA only" or "IA_NA in addition to other address assignment methods"? A network that uses IA_NA in addition to another method such as SLAAC, PD, /64-per-host, AERO, or other non-restrictive address assignment method obviously fulfills the spirit of this draft. There are good reasons to do this. For example, you could use IA_NA to assign a predictable/stable IPv6 address for incoming connections, and other methods for other addresses. As for a network that requires IA_NA in order to connect, I don't know. How do you build such a network in a way that doesn't end up restricting address availability? How would you solve the problems I described to Gert above? --001a1141e9b635b0cd0528bc842f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 7, 2016 at 6:47 PM, David Farmer <farmer@umn.edu> wrote= :
On Thu, Jan 7, 2016 at 6:50 AM, David Farmer = <farmer@umn.edu&= gt; wrote:
=C2=A0 =C2=A0If the net= work requires explicit requests for address space (e.g.,
=C2=A0 =C2=A0if it requires DHCPv6 to connect), the network MAY assign a /6= 4
=C2=A0 =C2=A0prefix to every host (e.g., via DHCPv6 PD).
<= br>
And if it doesn't choose to observe the MAY, then what? T= he network will end up restricting the amount of address space available to= the host, right? So it will violate the spirit of this draft, but not the = letter?

Are you saying that the use of DHCP= v6 IN_NA has to violat= e the spirit of this draft?=C2=A0 And, to meet the spirit you have t= o use DHCPv6 PD or SLAAC?

If you are, then you hav= e to be more clear about that, because that's not how I read even your = current text.=C2=A0 And if that is the case then you would need a MUST use DHCPv6 PD, not a RECOM= MENDED anyway.=C2=A0=C2=A0And, I'm not sure there is consensus f= or a MUST, especially since that would essentially deprecate=C2=A0DHCPv6 IN_NA.
=
Pe= rsonally, I'm fine with RECOMMENDED, but even that doesn't mean tha= t=C2=A0use of DHCPv6 IN_NA=C2=A0violates the intent of this draft as I read= it.

When you say = "IA_NA", do you mean "IA_NA only" or "IA_NA in add= ition to other address assignment methods"?

A= network that uses IA_NA in addition to another method such as SLAAC, PD, = =C2=A0/64-per-host, AERO, or other non-restrictive address assignment metho= d obviously fulfills the spirit of this draft. There are good reasons to do= this. For example, you could use IA_NA to assign a predictable/stable IPv6= address for incoming connections, and other methods for other addresses.

As for a network that requires IA_NA in order to co= nnect, I don't know. How do you build such a network in a way that does= n't end up restricting address availability? How would you solve the pr= oblems I described to Gert above?
--001a1141e9b635b0cd0528bc842f-- From nobody Thu Jan 7 03:46:19 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C741A88F1 for ; Thu, 7 Jan 2016 03:46:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTlKd8TEv0kS for ; Thu, 7 Jan 2016 03:46:16 -0800 (PST) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 754021A890C for ; Thu, 7 Jan 2016 03:45:30 -0800 (PST) Received: by mail-vk0-x235.google.com with SMTP id i129so34285900vkb.0 for ; Thu, 07 Jan 2016 03:45:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DpJpLTwyUzqvapDzzyUcQuyfPIogItruG8JlSOyVDo8=; b=eiSP5LBZelJJH61sRR2DcvhPuWaCG5ES/BjHeuH4SBQit0IN+Z5JYo+CXwtSTlHvpc qprKsvoU9z3OndgofHcVR4Xn/l03BbycP3U3fBXQ4dJndMqdkk9FqE7ymCyxQyK/EWYc 06ZVLLr34/iIzhrw/57Ar5sCYKinWIvQgPUNvlcDGX/42ZpHusFIg/8+F3BLafVQqA5w gIKBj1STKnF/KzK/oFT16lysLAK4NJwHWMEdwXpcJz0pQy6OC1Hbj4SVHzkObUG4nwbE /hE5WvnPGNks7PUovSCgpAdWSQJKgNjy9wZoEGzJT2d1tVs+wF4Qb3U+jjdkrL6bVzzJ ttBA== MIME-Version: 1.0 X-Received: by 10.31.21.210 with SMTP id 201mr74532013vkv.132.1452167129511; Thu, 07 Jan 2016 03:45:29 -0800 (PST) Received: by 10.103.99.1 with HTTP; Thu, 7 Jan 2016 03:45:29 -0800 (PST) Received: by 10.103.99.1 with HTTP; Thu, 7 Jan 2016 03:45:29 -0800 (PST) In-Reply-To: <20160107091237.GJ58491@Space.Net> References: <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <568D8C1C.2020406@umn.edu> <20160107084859.GI58491@Space.Net> <20160107091237.GJ58491@Space.Net> Date: Thu, 7 Jan 2016 22:45:29 +1100 Message-ID: From: Mark Smith To: Gert Doering Content-Type: multipart/alternative; boundary=001a1143b434e8bae50528bd01d4 Archived-At: Cc: v6ops list Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 11:46:17 -0000 --001a1143b434e8bae50528bd01d4 Content-Type: text/plain; charset=UTF-8 On 7 Jan 2016 8:12 PM, "Gert Doering" @ space.net > wrote: > > Hi, > > On Thu, Jan 07, 2016 at 08:11:06PM +1100, Mark Smith wrote: > > > It might just decide that up-to-100 IA_NA fits the restrictions of the > > > local gear better than PD, and does that instead. > > > > IOW, some networks might want to do that, others might want to delegate a > > /64 or greater via DHCPv6-PD. > > Right. > > > This argument is getting into minutiae about applicability, possibility and > > parameters of specific methods. That sounds to me like the main and > > fundamental point is accepted by everyone. > > > > So I'd say ship it. > > No. Neither as a BCP, nor with the strong recommendation for DHCPv6-PD, > nor with the emphasis on /64 (if DHCPv6-PD). > > What you say above is about choice, but the draft isn't. > Who forces you to follow BCPs? Who is saying you MUST use DHCPv6-PD and MUST give hosts /64s? The title itself is stating this is a recommendation, and the abstract describes the methods to do so as options. It's a BCP because hosts lacking addresses in an IPv6 network should never, ever be the reason an application partially or completely fails to operate. It is recommending (but not prescribing) DHCPv6-PD and at least a /64 because it is the only current method of putting a device in charge of a large amount of address space for its own use and management, instead of the other methods where hosts have ask for or generate addresses one at a time. > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 DHCP --001a1143b434e8bae50528bd01d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 7 Jan 2016 8:12 PM, "Gert Doering" <gert@space.net> wrote:
>
> Hi,
>
> On Thu, Jan 07, 2016 at 08:11:06PM +1100, Mark Smith wrote:
> > > It might just decide that up-to-100 IA_NA fits the restricti= ons of the
> > > local gear better than PD, and does that instead.
> >
> > IOW, some networks might want to do that, others might want to de= legate a
> > /64 or greater via DHCPv6-PD.
>
> Right.
>
> > This argument is getting into minutiae about applicability, possi= bility and
> > parameters of specific methods. That sounds to me like the main a= nd
> > fundamental point is accepted by everyone.
> >
> > So I'd say ship it.
>
> No.=C2=A0 Neither as a BCP, nor with the strong recommendation for DHC= Pv6-PD,
> nor with the emphasis on /64 (if DHCPv6-PD).
>
> What you say above is about choice, but the draft isn't.
>

Who forces you to follow BCPs? Who is saying you MUST use DHCPv6-PD and = MUST give hosts /64s?

The title itself is stating this is a recommendation, and the abstract d= escribes the methods to do so as options.

It's a BCP because hosts lacking addresses in an IPv6 network should= never, ever be the reason an application partially or completely fails to = operate.

It is recommending (but not prescribing) DHCPv6-PD and at least a /64 be= cause it is the only current method of putting a device in charge of a larg= e amount of address space for its own use and management, instead of the ot= her methods where hosts have ask for or generate addresses one at a time.

> Gert Doering
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- NetMaster
> --
> have you enabled IPv6 on something today...?
>
> SpaceNet AG=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Vorstand: Sebastian v. Bomhard
> Joseph-Dollinger-Bogen 14=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Aufsichtsr= atsvors.: A. Grundner-Culemann
> D-80807 Muenchen=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0USt-IdNr.: DE813185279
DHCP

--001a1143b434e8bae50528bd01d4-- From nobody Thu Jan 7 03:54:43 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F381A891C for ; Thu, 7 Jan 2016 03:54:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B77kSsrWQUx1 for ; Thu, 7 Jan 2016 03:54:41 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43C1D1A891A for ; Thu, 7 Jan 2016 03:54:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1262; q=dns/txt; s=iport; t=1452167681; x=1453377281; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=fnyTkgrghfPl7GWCM29jsJtbDbiTkLQaPAvT3SCDqYM=; b=WuJQOjRKWWM0C+ov0wrwXdTcvR3DXr305MbuL8rh9CGLnBVAApLvtVXK hNbwLSjir3eZyjpTLicNIPw9wb7pmc2E71n2bIGxwc1wkjpfuwzhz/yFs 70Ww3yHlsVxddt/P7rE6iSkyfT473tBjO5A6dkyQLiYJtEkx21OeiEIXb 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AQCfUY5W/5ldJa1egzpSbQaIU7NTA?= =?us-ascii?q?Q2BZBgKhW0CHIEDOBQBAQEBAQEBgQqENQEBBAEBASAROgsQAgEIGgImAgICJQs?= =?us-ascii?q?VEAIEAQ0FiC8OsGCQYgEBAQEBAQEBAQEBAQEBAQEBAQEBARQEgQGFVQGEfodzg?= =?us-ascii?q?UkBBJcLAY1VjnuOTAEgAQFChApyAYRYgQgBAQE?= X-IronPort-AV: E=Sophos;i="5.20,532,1444694400"; d="scan'208";a="224966879" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jan 2016 11:54:39 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u07BsdNI016799 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Jan 2016 11:54:39 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 7 Jan 2016 06:54:38 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Thu, 7 Jan 2016 06:54:38 -0500 From: "Eric Vyncke (evyncke)" To: "Templin, Fred L" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org" Thread-Topic: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host Thread-Index: AQHRRrIF7o8qQUloLkyynK24JTNGyJ7vFi6AgAAqaYCAARr1gA== Date: Thu, 7 Jan 2016 11:54:38 +0000 Message-ID: References: <201601031900.u03J0LMe009763@irp-lnx1.cisco.com> <2134F8430051B64F815C691A62D9831832F9ADDE@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832F9ADDE@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.56.4] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 11:54:42 -0000 QXMgYWxsIHN1YnNjcmliZXJzIGhhdmUgYSBkZWRpY2F0ZWQgdHVubmVsIHRvIHRoZSBHVywgdGhp cyB0cmFuc2xhdGVzICh0bw0KbWUpIGludG8gZWFjaCBzdWJzY3JpYmVyIGhhcyBpdHMgb3duIGxh eWVyLTIgbGluaywgc28sIG5vIG5lZWQgdG8gZG8gREFEDQphcyB0aGVyZSBpcyBhIHVuaXF1ZSBV RSBwZXIgc3Vic2NyaWJlciAobXkgcmVhZGluZyBidXQgSSBhbSBub3QgMTAwJSBzdXJlKS4NCg0K SWYgbW9yZSB0aGFuIG9uZSBVQSBjYW4gZXhpc3QgcGVyIHR1bm5lbCwgdGhlbiBpbmRlZWQsIEZy ZWQsIHlvdSBhcmUgcmlnaHQNCg0KLcOpcmljDQoNCk9uIDYvMDEvMTYgMjE6MDEsICJ2Nm9wcyBv biBiZWhhbGYgb2YgVGVtcGxpbiwgRnJlZCBMIg0KPHY2b3BzLWJvdW5jZXNAaWV0Zi5vcmcgb24g YmVoYWxmIG9mIEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+IHdyb3RlOg0KDQo+SSBoYXZlIHdo YXQgSSBob3BlIHdpbGwgYmUgYSBzaW1wbGUgcXVlc3Rpb246IHdoYXQgaWYgdHdvIG9yIG1vcmUg VUVzDQo+Y29uZmlndXJlDQo+aWRlbnRpY2FsIElQdjYgbGluay1sb2NhbCBhZGRyZXNzZXMgLSB3 aWxsIHRoZSBXTEFOLUdXIGJlIGFibGUgdG8gdGVsbA0KPnRoZW0gYXBhcnQ/DQo+QXNrZWQgYW5v dGhlciB3YXksIHdoYXQga2luZCBvZiB1bmlxdWUgbm9kZSBpZGVudGlmaWVyIGRvZXMgdGhlIFdM QU4tR1cNCj5leHBlY3QgZWFjaCBVRSB0byBwcm92aWRlIGluIHRoZSBpbml0aWFsIFJTPw0KPg0K PlRoYW5rcyAtIEZyZWQNCj5mcmVkLmwudGVtcGxpbkBib2VpbmcuY29tDQo+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj52Nm9wcyBtYWlsaW5nIGxpc3QN Cj52Nm9wc0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v djZvcHMNCg0K From nobody Thu Jan 7 03:58:01 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0538E1A891D for ; Thu, 7 Jan 2016 03:58:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bo3VvqKpAnQZ for ; Thu, 7 Jan 2016 03:57:58 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A4551A891A for ; Thu, 7 Jan 2016 03:57:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8732; q=dns/txt; s=iport; t=1452167878; x=1453377478; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=hTZH0mzfEoVnVyBbb9re78np+VhgVzJdTK1ub72R6lk=; b=TDwazGJ1jfT0jWVJxwFhNyV/bsOCsps5ujiSt2NqhNi1N/jyjY+PLcF5 vw4kHl7EmawsVioTeDSDXXRKDbZxe4dYOEp57DDHM32MqW+PPXGKNJy9R Dpw0Y/ossQE9Pkbh3s9o2AoiJPDfV8/E4DW+Nb7SBFL1o8VgVTL/NNJhj 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AQDoUY5W/4wNJK1egm5MgT8GiFOzU?= =?us-ascii?q?wENgWSGDwIcgQM4FAEBAQEBAQGBCoQ0AQEBBCNWEAIBCBEDAQIkBAMCAgIfERQ?= =?us-ascii?q?JCAIEAQ0FiBoDErBsjWgNgm0BAQEBAQEBAQEBAQEBAQEBAQEBAQEYhlYBhH6CT?= =?us-ascii?q?4IognyBSQWTCoQBAYtdgXiOe4Zwh1wBIAEBQoIRHB2BQHIBhFiBCAEBAQ?= X-IronPort-AV: E=Sophos; i="5.20,532,1444694400"; d="scan'208,217"; a="64184106" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Jan 2016 11:57:57 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u07BvvOo026160 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Jan 2016 11:57:57 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 7 Jan 2016 06:57:56 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Thu, 7 Jan 2016 06:57:56 -0500 From: "Eric Vyncke (evyncke)" To: Mark Smith , Fred L Templin Thread-Topic: [v6ops] Routers are hosts too! (Re: I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt) Thread-Index: AQHRSMitV7fnMhmxM0KqvFEotlF1cZ7wWE2A Date: Thu, 7 Jan 2016 11:57:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.56.4] Content-Type: multipart/alternative; boundary="_000_D2B410BA63D18evynckeciscocom_" MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Routers are hosts too! (Re: I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 11:58:00 -0000 --_000_D2B410BA63D18evynckeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWFyaywgKzEgaW5kZWVkIG9uIHRoZSBzdGF0ZW1lbnQgdGhhdCByb3V0ZXJzIGFyZSBob3N0cyAo aS5lLiBUaGV5IHJlcGx5IHRvIElDTVAgJiBTTk1QIGFuZCBldmVuIGdlbmVyYXRlIElDTVAgd2l0 aCB0aGVpciBvd24gZ2xvYmFsIGFkZHJlc3NlcyAtLSBlbHNlIFJGQyA3MDE0IC0tTExBLW9ubHkg LS0gc2hvdWxkIGhhdmUgYmVlbiBvYnZpb3VzKQ0KDQpOb3csIEkgcmVzcGVjdGZ1bGx5IGRpc2Fn cmVlIG9uIHRoZSBmYWN0IHdlIGhhdmUgZXhwZXJpZW5jZSB3aXRoIGhvc3QgZG9pbmcgREhDUC1Q RDogZm9yIHN1cmUgYWJvdXQgTGludXggKGFuZCBldmVuIGl0IGlzIHVzZXIgc3BhY2UpIGJ1dCB3 aGF0IGFib3V0IFdpbmRvd3M/IE9yIGlPUyAobG93ZXJjYXNlIDotKSApPyBPciA/Pz8NCg0KLcOp cmljDQoNCkZyb206IHY2b3BzIDx2Nm9wcy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzp2Nm9wcy1i b3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIE1hcmsgU21pdGggPG1hcmt6enpzbWl0aEBn bWFpbC5jb208bWFpbHRvOm1hcmt6enpzbWl0aEBnbWFpbC5jb20+Pg0KRGF0ZTogbWVyY3JlZGkg NiBqYW52aWVyIDIwMTYgMjI6MjQNClRvOiBGcmVkIEwgVGVtcGxpbiA8RnJlZC5MLlRlbXBsaW5A Ym9laW5nLmNvbTxtYWlsdG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4+DQpDYzogInY2b3Bz QGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4gV0ciIDx2Nm9wc0BpZXRmLm9yZzxtYWls dG86djZvcHNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW3Y2b3BzXSBSb3V0ZXJzIGFyZSBob3N0cyB0 b28hIChSZTogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi12Nm9wcy1ob3N0LWFkZHItYXZhaWxhYmls aXR5LTA0LnR4dCkNCg0KDQpJIHRoaW5rIHBlb3BsZSBtaWdodCBiZSBnZXR0aW5nIGEgYml0IGNh dWdodCBpbiB0aGUgdHJhcCBvZiB0aGlua2luZyB0aGUgc2VwYXJhdGlvbiBiZXR3ZWVuIGhvc3Rz IGFuZCByb3V0ZXJzIGlzIGEgbXVjaCBzdHJvbmdlciB0aGFuIGl0IGlzLg0KDQpSb3V0ZXJzIGFy ZSB1bml2ZXJzYWxseSBob3N0cyB0b28uIFRoZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIGEgcm91dGVy IGFuZCBhIGhvc3QgaXMgdGhhdCBhIHJvdXRlciB3aWxsIGFsc28gYWNjZXB0IHBhY2tldHMgbm90 IHNlbnQgdG8gYWRkcmVzc2VzIGFzc2lnbmVkIHRvIHRoZSBkZXZpY2VzIGludGVyZmFjZXMuIEl0 IHdpbGwgdGhlbiBzZWUgd2hhdCB0byBkbyB3aXRoIHRoZW0gYWNjb3JkaW5nIHRvIHRoZSByb3V0 ZSB0YWJsZSwgc2VuZGluZyB0aGUgcGFja2V0IHdoZXJlIGV2ZXIgdGhlICByb3V0ZSB0YWJsZSBz YXlzIG9yIGRyb3BwaW5nIHRoZW0uIFRoYXQgaXMgYWxsIHRoYXQgbWFrZXMgaXQgYSByb3V0ZXIu DQoNClJvdXRlcnMgYXJlIGhvc3RzIHRvbyBpZiB0aGVyZSBpcyBhbnl0aGluZyBhdCBhbGwgYWJv dmUgdGhlIElQIGxheWVyIHRoYXQgbG9jYWxseSByZWNlaXZlcyBvciBsb2NhbGx5IG9yaWdpbmF0 ZXMgcGFja2V0cyB1c2luZyB0aGUgcm91dGVyJ3MgSVAgYWRkcmVzc2VzLiBTbyBTTk1QIGFnZW50 cywgc3NoL3RlbG5ldCBkYWVtb25zIGFuZCBldmVuIEJHUCwgT1NQRiBhbmQgREhDUHY2IHByb2Nl c3NlcyBhcmUgaG9zdCBwcm9jZXNzZXMuDQoNClBlb3BsZSBzYXkgdGhlcmUgaXNuJ3QgbXVjaCBv ciBhbnkgZXhwZXJpZW5jZSB3aXRoIGhvc3RzIHVzaW5nIGFkZHJlc3NlcyBhc3NpZ25lZCB2aWEg REhDUHY2LVBELiBJIGRvbid0IGFncmVlLCBiZWNhdXNlIGV2ZXJ5IHJlc2lkZW50aWFsIElQdjYg Q1BFIHN1cHBvcnRpbmcgREhDUHY2IHRoYXQgaXMgYWNxdWlyaW5nIGFkZHJlc3NlcyB2aWEgREhD UHY2LVBELCBETlMgc2V0dGluZ3MsIGdldHRpbmcgdGltZSB2aWEgTlRQIG9yIHByb3ZpZGluZyBh IHdlYiBhZG1pbmlzdHJhdGl2ZSBpbnRlcmZhY2UgaXMgYSBob3N0IHRvby4NCg0KVGFrZSBvbmUg b2YgdGhlc2UgQ1BFLCBkaXNhYmxlIHRoZSBMQU4gaW50ZXJmYWNlLCBhdHRhY2ggYSBzY3JlZW4s IGtleWJvYXJkIGFuZCBtb3VzZSwgYW5kIHJ1biBhIHNwcmVhZHNoZWV0IG9yIHdlYiBicm93c2Vy IG9uIGl0IGFuZCB5b3UgaGF2ZSB0aGUgdHlwZSBvZiBob3N0IGJlaW5nIGRpc2N1c3NlZC4NCg0K VGhlIG9ubHkgd2F5IGZvciBhIHJvdXRlciBub3QgdG8gYmUgYSBob3N0IHdvdWxkIGJlIGlmIGl0 IHNwZWNpYWxseSBkaWRuJ3QgbGlzdGVuIGZvciBwYWNrZXRzIGFkZHJlc3NlZCB0byBpdHMgb3du IGFkZHJlc3Nlcywgc28gdGhhdCBhbGwgaXQgZXZlciBkaWQgd2FzIGZvcndhcmQgbm9uLWxvY2Fs IHBhY2tldHMuIFlvdSBoYXZlIG5vIG1vbml0b3Jpbmcgb2YgaXQsIG5vIHJvdXRpbmcgcHJvdG9j b2xzLCBhbmQgd291bGQgaGF2ZSB0byBjb25maWd1cmUgaXQgdmlhIGEgc2VyaWFsIGNhYmxlLg0K DQpNYXJrLg0K --_000_D2B410BA63D18evynckeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5NYXJrLCAmIzQz OzEgaW5kZWVkIG9uIHRoZSBzdGF0ZW1lbnQgdGhhdCByb3V0ZXJzIGFyZSBob3N0cyAoaS5lLiBU aGV5IHJlcGx5IHRvIElDTVAgJmFtcDsgU05NUCBhbmQgZXZlbiBnZW5lcmF0ZSBJQ01QIHdpdGgg dGhlaXIgb3duIGdsb2JhbCBhZGRyZXNzZXMgLS0gZWxzZSBSRkMgNzAxNCAtLUxMQS1vbmx5IC0t IHNob3VsZCBoYXZlIGJlZW4gb2J2aW91cyk8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 Pk5vdywgSSByZXNwZWN0ZnVsbHkgZGlzYWdyZWUgb24gdGhlIGZhY3Qgd2UgaGF2ZSBleHBlcmll bmNlIHdpdGggaG9zdCBkb2luZyBESENQLVBEOiBmb3Igc3VyZSBhYm91dCBMaW51eCAoYW5kIGV2 ZW4gaXQgaXMgdXNlciBzcGFjZSkgYnV0IHdoYXQgYWJvdXQgV2luZG93cz8gT3IgaU9TIChsb3dl cmNhc2UgOi0pICk/IE9yID8/PzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+LcOpcmlj PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9O Ij4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0ZXh0 LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9S REVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6 IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsg Qk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHls ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPnY2b3BzICZsdDs8YSBocmVmPSJtYWls dG86djZvcHMtYm91bmNlc0BpZXRmLm9yZyI+djZvcHMtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7 IG9uIGJlaGFsZiBvZiBNYXJrIFNtaXRoICZsdDs8YSBocmVmPSJtYWlsdG86bWFya3p6enNtaXRo QGdtYWlsLmNvbSI+bWFya3p6enNtaXRoQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5 bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5tZXJjcmVkaSA2IGphbnZpZXIgMjAx NiAyMjoyNDxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPkZy ZWQgTCBUZW1wbGluICZsdDs8YSBocmVmPSJtYWlsdG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNv bSI+RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZv bnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnY2b3BzQGll dGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT4gV0cmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp2 Nm9wc0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJm b250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+W3Y2b3BzXSBSb3V0ZXJzIGFyZSBob3N0 cyB0b28hIChSZTogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi12Nm9wcy1ob3N0LWFkZHItYXZhaWxh YmlsaXR5LTA0LnR4dCk8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1M RUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4N CjxkaXY+DQo8ZGl2Pg0KPHAgZGlyPSJsdHIiPkkgdGhpbmsgcGVvcGxlIG1pZ2h0IGJlIGdldHRp bmcgYSBiaXQgY2F1Z2h0IGluIHRoZSB0cmFwIG9mIHRoaW5raW5nIHRoZSBzZXBhcmF0aW9uIGJl dHdlZW4gaG9zdHMgYW5kIHJvdXRlcnMgaXMgYSBtdWNoIHN0cm9uZ2VyIHRoYW4gaXQgaXMuPC9w Pg0KPHAgZGlyPSJsdHIiPlJvdXRlcnMgYXJlIHVuaXZlcnNhbGx5IGhvc3RzIHRvby4gVGhlIGRp c3RpbmN0aW9uIGJldHdlZW4gYSByb3V0ZXIgYW5kIGEgaG9zdCBpcyB0aGF0IGEgcm91dGVyIHdp bGwgYWxzbyBhY2NlcHQgcGFja2V0cyBub3Qgc2VudCB0byBhZGRyZXNzZXMgYXNzaWduZWQgdG8g dGhlIGRldmljZXMgaW50ZXJmYWNlcy4gSXQgd2lsbCB0aGVuIHNlZSB3aGF0IHRvIGRvIHdpdGgg dGhlbSBhY2NvcmRpbmcgdG8gdGhlIHJvdXRlIHRhYmxlLA0KIHNlbmRpbmcgdGhlIHBhY2tldCB3 aGVyZSBldmVyIHRoZSZuYnNwOyByb3V0ZSB0YWJsZSBzYXlzIG9yIGRyb3BwaW5nIHRoZW0uIFRo YXQgaXMgYWxsIHRoYXQgbWFrZXMgaXQgYSByb3V0ZXIuPC9wPg0KPHAgZGlyPSJsdHIiPlJvdXRl cnMgYXJlIGhvc3RzIHRvbyBpZiB0aGVyZSBpcyBhbnl0aGluZyBhdCBhbGwgYWJvdmUgdGhlIElQ IGxheWVyIHRoYXQgbG9jYWxseSByZWNlaXZlcyBvciBsb2NhbGx5IG9yaWdpbmF0ZXMgcGFja2V0 cyB1c2luZyB0aGUgcm91dGVyJ3MgSVAgYWRkcmVzc2VzLiBTbyBTTk1QIGFnZW50cywgc3NoL3Rl bG5ldCBkYWVtb25zIGFuZCBldmVuIEJHUCwgT1NQRiBhbmQgREhDUHY2IHByb2Nlc3NlcyBhcmUg aG9zdCBwcm9jZXNzZXMuPC9wPg0KPHAgZGlyPSJsdHIiPlBlb3BsZSBzYXkgdGhlcmUgaXNuJ3Qg bXVjaCBvciBhbnkgZXhwZXJpZW5jZSB3aXRoIGhvc3RzIHVzaW5nIGFkZHJlc3NlcyBhc3NpZ25l ZCB2aWEgREhDUHY2LVBELiBJIGRvbid0IGFncmVlLCBiZWNhdXNlIGV2ZXJ5IHJlc2lkZW50aWFs IElQdjYgQ1BFIHN1cHBvcnRpbmcgREhDUHY2IHRoYXQgaXMgYWNxdWlyaW5nIGFkZHJlc3NlcyB2 aWEgREhDUHY2LVBELCBETlMgc2V0dGluZ3MsIGdldHRpbmcgdGltZSB2aWEgTlRQIG9yDQogcHJv dmlkaW5nIGEgd2ViIGFkbWluaXN0cmF0aXZlIGludGVyZmFjZSBpcyBhIGhvc3QgdG9vLjwvcD4N CjxwIGRpcj0ibHRyIj5UYWtlIG9uZSBvZiB0aGVzZSBDUEUsIGRpc2FibGUgdGhlIExBTiBpbnRl cmZhY2UsIGF0dGFjaCBhIHNjcmVlbiwga2V5Ym9hcmQgYW5kIG1vdXNlLCBhbmQgcnVuIGEgc3By ZWFkc2hlZXQgb3Igd2ViIGJyb3dzZXIgb24gaXQgYW5kIHlvdSBoYXZlIHRoZSB0eXBlIG9mIGhv c3QgYmVpbmcgZGlzY3Vzc2VkLjwvcD4NCjxwIGRpcj0ibHRyIj5UaGUgb25seSB3YXkgZm9yIGEg cm91dGVyIG5vdCB0byBiZSBhIGhvc3Qgd291bGQgYmUgaWYgaXQgc3BlY2lhbGx5IGRpZG4ndCBs aXN0ZW4gZm9yIHBhY2tldHMgYWRkcmVzc2VkIHRvIGl0cyBvd24gYWRkcmVzc2VzLCBzbyB0aGF0 IGFsbCBpdCBldmVyIGRpZCB3YXMgZm9yd2FyZCBub24tbG9jYWwgcGFja2V0cy4gWW91IGhhdmUg bm8gbW9uaXRvcmluZyBvZiBpdCwgbm8gcm91dGluZyBwcm90b2NvbHMsIGFuZCB3b3VsZCBoYXZl DQogdG8gY29uZmlndXJlIGl0IHZpYSBhIHNlcmlhbCBjYWJsZS4gPC9wPg0KPHAgZGlyPSJsdHIi Pk1hcmsuPGJyPg0KPC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D2B410BA63D18evynckeciscocom_-- From nobody Thu Jan 7 04:40:01 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CDAD1A8952 for ; Thu, 7 Jan 2016 04:39:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1ym1bC6QyOz for ; Thu, 7 Jan 2016 04:39:50 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 525191A8948 for ; Thu, 7 Jan 2016 04:39:50 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u07Cdllu031941 for ; Thu, 7 Jan 2016 13:39:47 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0FD32203714 for ; Thu, 7 Jan 2016 13:47:16 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id EFD85202D1E for ; Thu, 7 Jan 2016 13:47:15 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u07CdlXU003224 for ; Thu, 7 Jan 2016 13:39:47 +0100 To: v6ops@ietf.org References: <568D8B33.1060301@isi.edu> From: Alexandre Petrescu Message-ID: <568E5C93.5050201@gmail.com> Date: Thu, 7 Jan 2016 13:39:47 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <568D8B33.1060301@isi.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Routers are hosts too! (Re: I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 12:39:52 -0000 Le 06/01/2016 22:46, Joe Touch a écrit : > +1 (and then some) > > AFAICT: > > - a host is an Internet device that sources or sinks packets > > - a router is an Internet device that *also* relays packets > > It may be possible to implement a router that never acts as a host, but > that requires it never participate actively in routing protocols, IP > signalling, etc. Yes. And: - a router doesn't use the information received in an RA, a host does. - a router doesn't join the all-hosts multicast address. - a router doesn't use SLAAC to configure an address for self, a Host does. - a router does implement longest-matching algorithms, a Host doesn't. Implementations are obviously less clear cut. But we can talk theory. Alex > > Joe > > On 1/6/2016 1:24 PM, Mark Smith wrote: >> Routers are universally hosts too. The distinction between a router and >> a host is that a router will also accept packets not sent to addresses >> assigned to the devices interfaces. It will then see what to do with >> them according to the route table, sending the packet where ever the >> route table says or dropping them. That is all that makes it a router. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Jan 7 04:41:24 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3361A8955 for ; Thu, 7 Jan 2016 04:41:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 qy1yhgu5Ckn2 for ; Thu, 7 Jan 2016 04:41:22 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E02951A894E for ; Thu, 7 Jan 2016 04:41:21 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 464BF60AC7 for ; Thu, 7 Jan 2016 13:41:20 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id C064E600FD for ; Thu, 7 Jan 2016 13:41:19 +0100 (CET) Received: (qmail 54593 invoked by uid 1007); 7 Jan 2016 13:41:19 +0100 Date: Thu, 7 Jan 2016 13:41:19 +0100 From: Gert Doering To: Lorenzo Colitti Message-ID: <20160107124119.GO58491@Space.Net> References: <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <568D8C1C.2020406@umn.edu> <20160107084859.GI58491@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nXLDPHoFt2cvpIRj" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 12:41:24 -0000 --nXLDPHoFt2cvpIRj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Jan 07, 2016 at 07:57:13PM +0900, Lorenzo Colitti wrote: > The problems with this strategy are dealt with in section 4. If you ha= ven't > read that, here's a summary: code complexity, high latency, user > aggravation when they can't do what they want (e.g., the hotel network= they > connect to won't allow them to start a VM), and consequent pressure on= host > implementers to implement NAT66. (I know that's what I would do.) Actually, the description of all these details makes me wonder why we're not recommending that the VM in question shouldn't just send its own DHCPv6 IA_NA request when it wants an address. Specifying "the network SHOULD add all that complexity" while at the same time not even specifying how that example VM would then end up=20 receiving the address (is the host OS supposed to run SLAAC? DHCPv6?), *and* argueing about implementor complexity while not even giving implementors guidelines how to handle what the network is supposed to be offering them is a bit unsatisfying. [..] > And here there's another problem: even if the host somehow knew that it c= an > get 100 IA_NA, that won't fit in an IPv6 packet, because an IA_NA is 44 > bytes long, so the practical maximum is around 30-35 for a 1280-1500 MTU. > (Yes, there is a Fragment header. No, it won't work in practice, and you > know it.) Which makes a strong argument for having the VM itself request the IA_NA when it wants an address. This DUID stuff *must* be useful for something. > When you consider extending the network you have another problem. Every > level of hierarchy (tethered device, VM inside a container, etc.) needs to > act as a DHCPv6 relay. (Don't say "bridging" because that doesn't work on > wifi except using MAC NAT or virtually-impossible-to-deploy WDS.) With DHCPv6-PD, you need multiple levels of DHCPv6-PD, *and* DHCPv6-IA_NA to the VM, because if you get a /64 from the network, you can't do SLAAC on more than one internal network (and obviously the draft also applies to internal networks, so the VM could rightfully expect DHCPv6-PD to=20 succeed, no?). The "bridging is impossible" is something that needs to be solved - as the draft permits SLAAC, the VM example would totally break without bridiging of some sort, because it won't be able to do SLAAC otherwise. [..] > And so on. From the point of view of a host implementer and of a user, > that's a total nightmare. Search the archives for the total nightmare that > is implementing ePDG on a split application processor/baseband processor > architecture with only one IPv4 address. This is what your phone does when > you do wifi calling, and the result is either an unreliable device, or la= ck > of other features because so much software engineering time had to be spe= nt > on getting it right. Bringing in the poor quality of baseband processor implementations isn't really a strong argument either way... Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --nXLDPHoFt2cvpIRj Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVo5c799WwGXkzn/FAQJO3g//STdNySKX4xO+ncdpCuTbUO0Jut+Q5b6M iU01TJbXrxgx62Di0g2qwLq+na3b2VYzsPb8w3+DCqxEb/MhliKunAqFEqfNlxuY /xMyPUNdNzsJOnjjznFhKtsiUwgc7JKGMkI1TtvTsMtf+A9SrKL2MUTdY9m9dbsZ gkQlT1QgSLUaZiGPjG9sp9MvRS5TnVW/RiS/v6B1jlJOSk4j2ht/yKr97UCCfaS4 eyIKxvu9rEe1nAB5ZOu+jN8qjv7KCQvXLAp/z7S3ncc28iSRWQuITz9en+nDSh+w TPwW+qjGB3rOjPNl5x9lFTxRpiUCokxAsxOZgypklHZn5tRx7L6PvZ1/gjRQhcrd HG8ARpBLn5UrSc8aeIY7ratYbfaTRwfPDObPhfeBbeA7/D9JSo/o1DF2ysyqe5YK qQ4goYOz0IjPy2grtw5QYrbaheGLPaO+Vrf0pFuvaPnldJKT2lxQu3BTEKKPsPm9 FNpQVTl/QHYh96PTQnI+gDtCnb/muskDJAdUbaom6Rm/BzQxx+RJp52mlBkwUJtF w9dN6Yc4Ta0wbSLDfN4YX7Z2sB6satDJZrVG+phCPB9nmJ+dGossbVxowwT8gg2w aw/p0PjtAok+dP3hLAgVjqvn/wliorBppIzVWRNqxAHy3YUa2AgBol53sowD72Q0 4lEGjrwwShw= =hMzD -----END PGP SIGNATURE----- --nXLDPHoFt2cvpIRj-- From nobody Thu Jan 7 04:42:41 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B081A8956 for ; Thu, 7 Jan 2016 04:42:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 ntoMmcsnNFPL for ; Thu, 7 Jan 2016 04:42:39 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6B431A894C for ; Thu, 7 Jan 2016 04:42:38 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 71E3660A56 for ; Thu, 7 Jan 2016 13:42:37 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 25BD9600FD for ; Thu, 7 Jan 2016 13:42:37 +0100 (CET) Received: (qmail 54688 invoked by uid 1007); 7 Jan 2016 13:42:37 +0100 Date: Thu, 7 Jan 2016 13:42:37 +0100 From: Gert Doering To: Alexandre Petrescu Message-ID: <20160107124237.GP58491@Space.Net> References: <568D8B33.1060301@isi.edu> <568E5C93.5050201@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <568E5C93.5050201@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Routers are hosts too! (Re: I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 12:42:40 -0000 Hi, On Thu, Jan 07, 2016 at 01:39:47PM +0100, Alexandre Petrescu wrote: > - a router does implement longest-matching algorithms, a Host > doesn't. Of course hosts do. Why would any implementor not do that? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Thu Jan 7 04:44:59 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 910521A8953 for ; Thu, 7 Jan 2016 04:44:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 RDMUDBYPuw_P for ; Thu, 7 Jan 2016 04:44:56 -0800 (PST) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by ietfa.amsl.com (Postfix) with ESMTP id 965471A894C for ; Thu, 7 Jan 2016 04:44:56 -0800 (PST) Received: from [IPv6:2601:401:3:6a00:dd72:edf2:e3c9:c4f4] (unknown [IPv6:2601:401:3:6a00:dd72:edf2:e3c9:c4f4]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id B918F540A65; Thu, 7 Jan 2016 07:44:54 -0500 (EST) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: text/plain; charset=utf-8 From: Jared Mauch In-Reply-To: <20160107124237.GP58491@Space.Net> Date: Thu, 7 Jan 2016 07:44:54 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <568D8B33.1060301@isi.edu> <568E5C93.5050201@gmail.com> <20160107124237.GP58491@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.3112) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Routers are hosts too! (Re: I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 12:44:57 -0000 > On Jan 7, 2016, at 7:42 AM, Gert Doering wrote: >=20 > Hi, >=20 > On Thu, Jan 07, 2016 at 01:39:47PM +0100, Alexandre Petrescu wrote: >> - a router does implement longest-matching algorithms, a Host >> doesn't. >=20 > Of course hosts do. Why would any implementor not do that? Agreed. I=E2=80=99ve seen junior sysadmin types get caught up with this = at times if a host is multi homed. - Jared= From nobody Thu Jan 7 04:47:08 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ACA61A895D for ; Thu, 7 Jan 2016 04:47:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-WTAfbZ6ZGh for ; Thu, 7 Jan 2016 04:47:04 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A1971A8953 for ; Thu, 7 Jan 2016 04:47:04 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u07Cl2rh004077 for ; Thu, 7 Jan 2016 13:47:02 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id ECEAE203722 for ; Thu, 7 Jan 2016 13:54:30 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id E3F3820317A for ; Thu, 7 Jan 2016 13:54:30 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u07Cl22L025049 for ; Thu, 7 Jan 2016 13:47:02 +0100 To: v6ops@ietf.org References: From: Alexandre Petrescu Message-ID: <568E5E46.3080708@gmail.com> Date: Thu, 7 Jan 2016 13:47:02 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Routers are hosts too! (Re: I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 12:47:06 -0000 Le 06/01/2016 22:24, Mark Smith a écrit : > I think people might be getting a bit caught in the trap of thinking the > separation between hosts and routers is a much stronger than it is. > > Routers are universally hosts too. The distinction between a router and > a host is that a router will also accept packets not sent to addresses > assigned to the devices interfaces. It will then see what to do with > them according to the route table, sending the packet where ever the > route table says or dropping them. That is all that makes it a router. I agree with you about the trap. It may be a trap of the theory, which is good to keep aside as principles, although practice is more nuanced. YEs, mainly a router forwards packets not addressed to self, whereas a Host doesn't . Also, a router with a single real interface and at least one virtual interface forwards packets too; and too, according to the same forwarding mechanisms (route table, longest-prefix match, etc.). The only Host which is not a Router is a Host that has one single real interface and no virtual interfaces. I think the loopback interface is mandatory (or at least its loopback address is mandatory) and hence maybe true Hosts dont really exist. > Routers are hosts too if there is anything at all above the IP layer > that locally receives or locally originates packets using the router's > IP addresses. So SNMP agents, ssh/telnet daemons and even BGP, OSPF and > DHCPv6 processes are host processes. Right. > People say there isn't much or any experience with hosts using addresses > assigned via DHCPv6-PD. I don't agree, because every residential IPv6 > CPE supporting DHCPv6 that is acquiring addresses via DHCPv6-PD, DNS > settings, getting time via NTP or providing a web administrative > interface is a host too. > > Take one of these CPE, disable the LAN interface, attach a screen, > keyboard and mouse, and run a spreadsheet or web browser on it and you > have the type of host being discussed. No - that is a desktop PC, inheriting from the VT100 terminal. It's not a Host. A Host is more like the 1970's mainframe which needs an IMP (Interface Message Processor) to connect to the Internet. > The only way for a router not to be a host would be if it specially > didn't listen for packets addressed to its own addresses, so that all it > ever did was forward non-local packets. You have no monitoring of it, no > routing protocols, and would have to configure it via a serial cable. YEs, and there are many such forwarding-only routers especially in the 'IoT' and 'M2M' worlds. They are very small and simple. Alex > > Mark. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Jan 7 04:47:19 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27411A8966 for ; Thu, 7 Jan 2016 04:47:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 jb9W3qIU10VY for ; Thu, 7 Jan 2016 04:47:15 -0800 (PST) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60A821A895D for ; Thu, 7 Jan 2016 04:47:15 -0800 (PST) Received: by mail-qk0-x236.google.com with SMTP id q19so120330556qke.3 for ; Thu, 07 Jan 2016 04:47:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=19FKj7tT7XRYKLjMavmXjH1Bw2L5ZhWppkqC9tuOzaM=; b=jecYjEZvM+pNlVHAzNRO2eIzwZ9n/P357x6pKFMRnYt9zFKricm093IbapI5ONaZqh AVKRbv3RoBSRe+RH3ZOmkNhGpAoMZvgcktV6ysZSla/JUhJH8UHhtCqXD9cOXjBRSh81 jWJ53BRpwxcnxL3W8kit2fAs9rlEGP44jtskE7MaPiIf3d3mjW+RgYF2LkrFurSKAbKH DWP6kv0mEaIXJf5S934r97hynzLtUI56akmwSsLbIU+3XLvOJCbzYNZv4yxLQtUG4Cmp 6JrBifeCcjcmjAzfGOoZYQn9XnRl419mIBBEehVAK+8KRUPPZ8bVrJgMiAp8vGmc95U6 9JoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=19FKj7tT7XRYKLjMavmXjH1Bw2L5ZhWppkqC9tuOzaM=; b=Uk9ebg7PjT1RhbtltmD5wfZZaz1YoDsCjHEi1uorERDKZfbuguyvQDqGenfhRz/asL O2M/Sy5GqTgYjuxm9LTdIQH1hFztWEAzzicul2DgNix/ZDR5jeV3NilFqGIceuaOO2vr yTVFC0l2D8LPCobgDA/3uw/Rayp7Zp0KjBIEwUKow1sZwc1EgV9dZ6Wsewm61lx2J+pN ILtONuLUvxjyMdih7ux+tn0uVsPXWEN80sh9yikrzxqFFA5WCrbr3Snx5t9F5qYmBNmz rwgFzrlWQIm3gSBCT5EeVKk/UQk+R4DgJtSPA5UrVyIsGKUn2LJy23Lr96/+2a+6WrCo 3Kbw== X-Gm-Message-State: ALoCoQlFS6jX+ZWYTxOpogAU9NzWqLJ5aSdzWNLXLRs01fP3kqSVF1BPr7HeRkiTkYaCvQM5WsHbyBtrMHzMlfEgaNt3lTktV9zmdyfo1vqc38rbBfLFKYw= X-Received: by 10.129.157.79 with SMTP id u76mr87513681ywg.123.1452170834448; Thu, 07 Jan 2016 04:47:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.208.201 with HTTP; Thu, 7 Jan 2016 04:46:54 -0800 (PST) In-Reply-To: References: From: Lorenzo Colitti Date: Thu, 7 Jan 2016 21:46:54 +0900 Message-ID: To: "Eric Vyncke (evyncke)" Content-Type: multipart/alternative; boundary=94eb2c0b61e8be0b490528bdde1e Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Routers are hosts too! (Re: I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 12:47:16 -0000 --94eb2c0b61e8be0b490528bdde1e Content-Type: text/plain; charset=UTF-8 On Thu, Jan 7, 2016 at 8:57 PM, Eric Vyncke (evyncke) wrote: > Now, I respectfully disagree on the fact we have experience with host > doing DHCP-PD: for sure about Linux (and even it is user space) but what > about Windows? Or iOS (lowercase :-) )? Or ??? > Windows has supported DHCPv6 since 2007: https://blogs.technet.microsoft.com/teamdhcp/2007/01/23/dhcpv6-behaviour-in-windows-vista/ As for iOS - two of the authors work for Apple, and both of them write code, so if they are saying that DHCPv6 PD is an option, I'd assume that it's possible to implement it on iOS :-) --94eb2c0b61e8be0b490528bdde1e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 7, 2016 at 8:57 PM, Eric Vyncke (evyncke) <evyncke@cisco.com&g= t; wrote:
Now, I respectfully disagree on the fact we have experience with host = doing DHCP-PD: for sure about Linux (and even it is user space) but what ab= out Windows? Or iOS (lowercase :-) )? Or ???
<= br>

As for iOS - = two of the authors work for Apple, and both of them write code, so if they = are saying that DHCPv6 PD is an option, I'd assume that it's possib= le to implement it on iOS :-)
--94eb2c0b61e8be0b490528bdde1e-- From nobody Thu Jan 7 04:53:07 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5063F1A8951 for ; Thu, 7 Jan 2016 04:53:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EG6-J9PucxYm for ; Thu, 7 Jan 2016 04:53:04 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CB121A88AD for ; Thu, 7 Jan 2016 04:53:04 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u07Cr2a2006376 for ; Thu, 7 Jan 2016 13:53:02 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0F5082012D0 for ; Thu, 7 Jan 2016 14:00:31 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 071432011BD for ; Thu, 7 Jan 2016 14:00:31 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u07Cr2Pj015344 for ; Thu, 7 Jan 2016 13:53:02 +0100 To: v6ops@ietf.org References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <568D8C1C.2020406@umn.edu> From: Alexandre Petrescu Message-ID: <568E5FAE.2090209@gmail.com> Date: Thu, 7 Jan 2016 13:53:02 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <568D8C1C.2020406@umn.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 12:53:06 -0000 Le 06/01/2016 22:50, David Farmer a écrit : > On 1/6/16 07:33 , Erik Kline wrote: >> On 6 January 2016 at 22:04, Philip Homburg >> wrote: >>>> I think instead we can publish this as is, and in future v6ops can >>>> look at a document describing host PD implementation and network >>>> operations experience, if such a document even proves necessary (which >>>> I doubt). >>> >>> I don't think we should write a BCP and then in a future document >>> describe how it works. That's not what a BCP is for. >>> >>> If the PD part is not required for this document, then just remove it. >> >> I disagree. PD is a perfectly valid way of addressing the issue and >> it needs to be included at some level of description for completeness. > > I agree DHCPv6 PD needs to be included and should not be removed. > > However, lets look at the recommendation section. > > ... > If the network requires explicit requests for address space (e.g., > if it requires DHCPv6 to connect), it is RECOMMENDED that the network > assign a /64 prefix to every host (e.g., via DHCPv6 PD). Using > DHCPv6 IA_NA or IA_TA to request a sufficient number of addresses > (e.g. 32) would accommodate current clients but sets a limit on the > number of addresses available to hosts when they attach and would > limit the development of future applications. > ... > > This is could be interpreted as saying that networks SHOULD NOT use > Stateful DHCPv6 for which there is a clear and unambiguous specification > for Stateful DHCPv6 host behavior, and they should use DHCPv6 PD for > which there is NOT a clear and unambiguous specification for DHCPv6 PD > host behavior. However, there is a clear and unambiguous specification > for DHCPv6 PD router behavior, but the importance of this distinction is > debatable. > > What if the recommendation section was rewritten making the DHCP v6 PD > part permissive and not a normative recommendation. > > 8. Recommendations > > In order to avoid the problems described above, and preserve the > Internet's ability to support new applications that use more than one > IPv6 address, it is RECOMMENDED that IPv6 network deployments provide > multiple IPv6 addresses from each prefix to general-purpose hosts > when they connect to the network. To support future use cases, it is > RECOMMENDED to not impose a hard limit on the size of the address > pool assigned to a host. > > If the network requires explicit requests for address space (e.g., > if it requires DHCPv6 to connect), the network MAY assign a /64 > prefix to every host (e.g., via DHCPv6 PD). Using DHCPv6 IA_NA or > IA_TA to request a sufficient number of addresses (e.g. 32) would > accommodate current clients but sets a limit on the number of > addresses available to hosts when they attach and would limit the > development of future applications. Assigning prefixes longer than > a /64 will limit the flexibility of the host to further assign > addresses to any internal functions, virtual machines, or downstream > clients that require address space - for example, by not allowing > the use of SLAAC. Sounds better to me. It is clearer with respect to the /64 point. It could say "not allowing the use of SLAAC/Ethernet" (remark "Ethernet"), because that's an Ethernet limination (Ethernet IID must be 64bit long) not a SLAAC limitation (SLAAC allows arbitrary prefix lenghts). (the Ethernet limitation has been propagated to many other link specs, like 802.15.4 RFC, but all, like IP/USB). When it says "assigning prefixes longer than /64" it begs the question about "assigning prefixes shorter than /64" but is silent in that respect. Alex > > In some ways I like this better, it more clearly says /64 per host is > only an option. The previous language formed as a conditional > recommendation, which was confusing in my opinion. > > What do others think? > From nobody Thu Jan 7 04:57:56 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7E01A8973 for ; Thu, 7 Jan 2016 04:57:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYRjr4GHCJTw for ; Thu, 7 Jan 2016 04:57:53 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CC171A8963 for ; Thu, 7 Jan 2016 04:57:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8090; q=dns/txt; s=iport; t=1452171473; x=1453381073; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=YFkUNcxZnr+Z4632cqKJJha2/sMDYC5bClT72Q9thdQ=; b=IcLbTHWvQ4H74rNotrKL5bo7KEXVybpCmjkmFjoOJy17VHs32Vd3iUdx bbxz5jGB6ywQsfisLbota40ofrImMM/b5hmggjhFIdcQN14bTUdmdvFuo zvWLfvLifWhEqIoLBVQQ2N57fa6nU1AngFyDuF0JSu6qXXfwwKpF4qexy E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AQBxYI5W/5RdJa1egm5MUm0GiFOzV?= =?us-ascii?q?QENgWQkhWsCHIEEOBQBAQEBAQEBgQqENAEBAQQjVhACAQgRAwECJAQDAgICHxE?= =?us-ascii?q?UAwEFCAIEDgWIGgMSDrBljWoNgm0BAQEBAQEBAQEBAQEBAQEBAQEBAQEUBIZWA?= =?us-ascii?q?YR+gk+BbzkNgm+BSQWXCwGFQYYcgXiOe4Zwh1wBIAEBQoJKgUByAYRYgQgBAQE?= X-IronPort-AV: E=Sophos; i="5.20,533,1444694400"; d="scan'208,217"; a="59399783" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jan 2016 12:57:52 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u07Cvq33021469 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Jan 2016 12:57:52 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 7 Jan 2016 07:57:51 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Thu, 7 Jan 2016 07:57:51 -0500 From: "Eric Vyncke (evyncke)" To: Lorenzo Colitti Thread-Topic: [v6ops] Routers are hosts too! (Re: I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt) Thread-Index: AQHRSMitV7fnMhmxM0KqvFEotlF1cZ7wWE2A///87ACAABPOgA== Date: Thu, 7 Jan 2016 12:57:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.56.4] Content-Type: multipart/alternative; boundary="_000_D2B41EA563D4Bevynckeciscocom_" MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Routers are hosts too! (Re: I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 12:57:55 -0000 --_000_D2B41EA563D4Bevynckeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBsaWtlIGl0IHdoZW4gbXkgcGVzc2ltaXN0aWMgdmlldyBpcyBjb3JyZWN0IDotKQ0KDQpPVE9I LCB0aGUgV2luZG93cyBibG9nIHN0YXRlcyAiREhDUHY2IFN0YXRlZnVsIG1vZGUgaXMgd2hlcmUg YSBjbGllbnQgdXNlcyBESENQdjYgdG8gb2J0YWluIGFuIElQdjYgYWRkcmVzcyBmcm9tIHRoZSBE SENQdjYgc2VydmVyIGFsb25nIHdpdGggb3RoZXIgY29uZmlndXJhaXRvbiBwYXJhbWV0ZXJzLiIg c28gbm8gaGludCBhYm91dCBESENQLVBELi4uIFRoaXMgd2FzIG15IGNvbmNlcm4gYWJvdXQgREhD UC1QRCBvbiBob3N0OiBhbiBpc3N1ZSBvZiBpbXBsZW1lbnRhdGlvbiBvbmx5IChmaXhhYmxlKSBh bmQgbm90IGluIHByb3RvY29sIG9yIHJlbGlnaW91cyBob3N0IHZzIHJvdXRlciB3YXMgKHVuZml4 YWJsZSkgOy0pDQoNCi3DqXJpYw0KDQoNCkZyb206IExvcmVuem8gQ29saXR0aSA8bG9yZW56b0Bn b29nbGUuY29tPG1haWx0bzpsb3JlbnpvQGdvb2dsZS5jb20+Pg0KRGF0ZTogamV1ZGkgNyBqYW52 aWVyIDIwMTYgMTM6NDYNClRvOiBFcmljIFZ5bmNrZSA8ZXZ5bmNrZUBjaXNjby5jb208bWFpbHRv OmV2eW5ja2VAY2lzY28uY29tPj4NCkNjOiBNYXJrIFNtaXRoIDxtYXJrenp6c21pdGhAZ21haWwu Y29tPG1haWx0bzptYXJrenp6c21pdGhAZ21haWwuY29tPj4sIEZyZWQgTCBUZW1wbGluIDxGcmVk LkwuVGVtcGxpbkBib2VpbmcuY29tPG1haWx0bzpGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPj4s ICJ2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+IFdHIiA8djZvcHNAaWV0Zi5v cmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbdjZvcHNdIFJvdXRlcnMg YXJlIGhvc3RzIHRvbyEgKFJlOiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXY2b3BzLWhvc3QtYWRk ci1hdmFpbGFiaWxpdHktMDQudHh0KQ0KDQpPbiBUaHUsIEphbiA3LCAyMDE2IGF0IDg6NTcgUE0s IEVyaWMgVnluY2tlIChldnluY2tlKSA8ZXZ5bmNrZUBjaXNjby5jb208bWFpbHRvOmV2eW5ja2VA Y2lzY28uY29tPj4gd3JvdGU6DQpOb3csIEkgcmVzcGVjdGZ1bGx5IGRpc2FncmVlIG9uIHRoZSBm YWN0IHdlIGhhdmUgZXhwZXJpZW5jZSB3aXRoIGhvc3QgZG9pbmcgREhDUC1QRDogZm9yIHN1cmUg YWJvdXQgTGludXggKGFuZCBldmVuIGl0IGlzIHVzZXIgc3BhY2UpIGJ1dCB3aGF0IGFib3V0IFdp bmRvd3M/IE9yIGlPUyAobG93ZXJjYXNlIDotKSApPyBPciA/Pz8NCg0KV2luZG93cyBoYXMgc3Vw cG9ydGVkIERIQ1B2NiBzaW5jZSAyMDA3OiBodHRwczovL2Jsb2dzLnRlY2huZXQubWljcm9zb2Z0 LmNvbS90ZWFtZGhjcC8yMDA3LzAxLzIzL2RoY3B2Ni1iZWhhdmlvdXItaW4td2luZG93cy12aXN0 YS8NCg0KQXMgZm9yIGlPUyAtIHR3byBvZiB0aGUgYXV0aG9ycyB3b3JrIGZvciBBcHBsZSwgYW5k IGJvdGggb2YgdGhlbSB3cml0ZSBjb2RlLCBzbyBpZiB0aGV5IGFyZSBzYXlpbmcgdGhhdCBESENQ djYgUEQgaXMgYW4gb3B0aW9uLCBJJ2QgYXNzdW1lIHRoYXQgaXQncyBwb3NzaWJsZSB0byBpbXBs ZW1lbnQgaXQgb24gaU9TIDotKQ0K --_000_D2B41EA563D4Bevynckeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <77A5B0B8963A07448F9F85C36B724354@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5JIGxpa2UgaXQg d2hlbiBteSBwZXNzaW1pc3RpYyB2aWV3IGlzIGNvcnJlY3QgOi0pJm5ic3A7PC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj5PVE9ILCB0aGUgV2luZG93cyBibG9nIHN0YXRlcyAmcXVvdDs8 c3BhbiBzdHlsZT0iY29sb3I6IHJnYig1MSwgNTEsIDUxKTsgZm9udC1mYW1pbHk6IENhbWJyaWEs IHNlcmlmOyBmb250LXNpemU6IG1lZGl1bTsgbGluZS1oZWlnaHQ6IDIyLjg1NzFweDsgd2lkb3dz OiAxOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij5ESENQdjYgU3RhdGVm dWwgbW9kZSBpcyB3aGVyZSBhIGNsaWVudCB1c2VzIERIQ1B2NiB0byBvYnRhaW4gYW4NCiBJUHY2 IGFkZHJlc3MgZnJvbSB0aGUgREhDUHY2IHNlcnZlciBhbG9uZyB3aXRoIG90aGVyIGNvbmZpZ3Vy YWl0b24gcGFyYW1ldGVycy4mcXVvdDsgc28gbm8gaGludCBhYm91dCBESENQLVBELi4uIFRoaXMg d2FzIG15IGNvbmNlcm4gYWJvdXQgREhDUC1QRCBvbiBob3N0OiBhbiBpc3N1ZSBvZiBpbXBsZW1l bnRhdGlvbiBvbmx5IChmaXhhYmxlKSBhbmQgbm90IGluIHByb3RvY29sIG9yIHJlbGlnaW91cyBo b3N0IHZzIHJvdXRlciB3YXMgKHVuZml4YWJsZSkNCiA7LSk8L3NwYW4+PC9kaXY+DQo8ZGl2Pjxz cGFuIHN0eWxlPSJjb2xvcjogcmdiKDUxLCA1MSwgNTEpOyBmb250LWZhbWlseTogQ2FtYnJpYSwg c2VyaWY7IGZvbnQtc2l6ZTogbWVkaXVtOyBsaW5lLWhlaWdodDogMjIuODU3MXB4OyB3aWRvd3M6 IDE7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPjxicj4NCjwvc3Bhbj48 L2Rpdj4NCjxkaXY+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7IGZvbnQtZmFt aWx5OiBDYW1icmlhLCBzZXJpZjsgZm9udC1zaXplOiBtZWRpdW07IGxpbmUtaGVpZ2h0OiAyMi44 NTcxcHg7IHdpZG93czogMTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU0LCAyNTQpOyI+ LcOpcmljPC9zcGFuPjwvZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYig1MSwgNTEs IDUxKTsgZm9udC1mYW1pbHk6IENhbWJyaWEsIHNlcmlmOyBmb250LXNpemU6IG1lZGl1bTsgbGlu ZS1oZWlnaHQ6IDIyLjg1NzFweDsgd2lkb3dzOiAxOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1 LCAyNTQsIDI1NCk7Ij48YnI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNw YW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNh bGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JE RVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5H LUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JE RVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFE RElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9z cGFuPkxvcmVuem8gQ29saXR0aSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNv bSI+bG9yZW56b0Bnb29nbGUuY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWln aHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPmpldWRpIDcgamFudmllciAyMDE2IDEzOjQ2PGJyPg0KPHNw YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+RXJpYyBWeW5ja2UgJmx0Ozxh IGhyZWY9Im1haWx0bzpldnluY2tlQGNpc2NvLmNvbSI+ZXZ5bmNrZUBjaXNjby5jb208L2E+Jmd0 Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPk1hcmsgU21p dGggJmx0OzxhIGhyZWY9Im1haWx0bzptYXJrenp6c21pdGhAZ21haWwuY29tIj5tYXJrenp6c21p dGhAZ21haWwuY29tPC9hPiZndDssIEZyZWQgTCBUZW1wbGluICZsdDs8YSBocmVmPSJtYWlsdG86 RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbSI+RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTwvYT4m Z3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciPnY2b3BzQGlldGYub3Jn PC9hPg0KIFdHJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciPnY2b3Bz QGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3Vi amVjdDogPC9zcGFuPlJlOiBbdjZvcHNdIFJvdXRlcnMgYXJlIGhvc3RzIHRvbyEgKFJlOiBJLUQg QWN0aW9uOiBkcmFmdC1pZXRmLXY2b3BzLWhvc3QtYWRkci1hdmFpbGFiaWxpdHktMDQudHh0KTxi cj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9P S19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBz b2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2IGRpcj0ibHRyIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCjxkaXYgY2xhc3M9Imdt YWlsX3F1b3RlIj5PbiBUaHUsIEphbiA3LCAyMDE2IGF0IDg6NTcgUE0sIEVyaWMgVnluY2tlIChl dnluY2tlKSA8c3BhbiBkaXI9Imx0ciI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOmV2eW5ja2VAY2lz Y28uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZXZ5bmNrZUBjaXNjby5jb208L2E+Jmd0Ozwvc3Bhbj4g d3JvdGU6PGJyPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2lu OjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0LXdpZHRoOjFweDtib3JkZXItbGVmdC1jb2xv cjpyZ2IoMjA0LDIwNCwyMDQpO2JvcmRlci1sZWZ0LXN0eWxlOnNvbGlkO3BhZGRpbmctbGVmdDox ZXgiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQ7Y29sb3I6cmdiKDAsMCwwKTtm b250LXNpemU6MTRweDtmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWYiPg0KPGRpdj5Ob3cs IEkgcmVzcGVjdGZ1bGx5IGRpc2FncmVlIG9uIHRoZSBmYWN0IHdlIGhhdmUgZXhwZXJpZW5jZSB3 aXRoIGhvc3QgZG9pbmcgREhDUC1QRDogZm9yIHN1cmUgYWJvdXQgTGludXggKGFuZCBldmVuIGl0 IGlzIHVzZXIgc3BhY2UpIGJ1dCB3aGF0IGFib3V0IFdpbmRvd3M/IE9yIGlPUyAobG93ZXJjYXNl IDotKSApPyBPciA/Pz88L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+V2luZG93cyBoYXMgc3VwcG9ydGVkIERIQ1B2NiBzaW5jZSAyMDA3OiZuYnNw OzxhIGhyZWY9Imh0dHBzOi8vYmxvZ3MudGVjaG5ldC5taWNyb3NvZnQuY29tL3RlYW1kaGNwLzIw MDcvMDEvMjMvZGhjcHY2LWJlaGF2aW91ci1pbi13aW5kb3dzLXZpc3RhLyI+aHR0cHM6Ly9ibG9n cy50ZWNobmV0Lm1pY3Jvc29mdC5jb20vdGVhbWRoY3AvMjAwNy8wMS8yMy9kaGNwdjYtYmVoYXZp b3VyLWluLXdpbmRvd3MtdmlzdGEvPC9hPjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+QXMgZm9yIGlPUyAtIHR3byBvZiB0aGUgYXV0aG9ycyB3b3JrIGZvciBBcHBsZSwgYW5k IGJvdGggb2YgdGhlbSB3cml0ZSBjb2RlLCBzbyBpZiB0aGV5IGFyZSBzYXlpbmcgdGhhdCBESENQ djYgUEQgaXMgYW4gb3B0aW9uLCBJJ2QgYXNzdW1lIHRoYXQgaXQncyBwb3NzaWJsZSB0byBpbXBs ZW1lbnQgaXQgb24gaU9TIDotKTwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D2B41EA563D4Bevynckeciscocom_-- From nobody Thu Jan 7 05:02:28 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8AB1A897F for ; Thu, 7 Jan 2016 05:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 K8KYBVAJRf12 for ; Thu, 7 Jan 2016 05:02:24 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61A1D1A899F for ; Thu, 7 Jan 2016 05:01:27 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id n135so176343789qka.2 for ; Thu, 07 Jan 2016 05:01:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9td2dipuMjxGq+2AG6QxQZIxFZ0VxVwtEYOofBFr8Tk=; b=ikHB/peVs9bTb/i/XBBMyuHDVnUhdz1pLT9SyBlwsWT1EFJXjQbKEh5NjSDoV1R9YF POpgz5AHNdysV5NkLuSyiZzIpVlSz79FlF4W5xpYOwOFCQUeCpjZo2nnZSLoZhNxetH4 QYXA3wKJwKbYlH9R/uK2iSjHsRKp8eo0Sy89HIP3fw5KIw9ThdDWybcu3pP9Rr67EpSD yWJTJFIGFLPaYO1+CNbW7tFkyQBVx219ZjqOVbLxBxNrPKiBekwebulht/YR9qsObnFj 5GxDgAZqJTX9zNS8bAluX92Xj6+WAKAGJuwoezQTlp3O0+UMJRHMnP7bswiap9AXNSKQ AEPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=9td2dipuMjxGq+2AG6QxQZIxFZ0VxVwtEYOofBFr8Tk=; b=T5lwLdiKd4i3pdZpWa4JeBxqpT6elOZ0H8GKJRkbUfsIN/fEoTf2H0lpbe2eQr7vJl qPaMgg2RMojvqmrqM0tpReg3XvkNPYABxuPQzZyWb/MA3TawtkYZLvjN2HtDGbC3UmcO 9gh7ChxqpGzmRfVPHLbJ0d5Mzq/1wv6hak+5CK/abb/QAFN/ccx8E3zb5qTtXDIQsBr3 VjYiGBaVpj+iFyyFAyRJP95zmNtZ1Lm2oJjxXix9okwfkeXTf5mYYThYxXhj5IWUMnw4 gpVvPfPjQtDrt8CddYO2WsYhGm2VG220PS3v30UKWSLOEABaN+aPdL0FJa49atxK58/F a3wQ== X-Gm-Message-State: ALoCoQlgmbnotCorujpdg8jZmz0d7ZYgnQuiD+mG1lr/t2j+PPnyrDkIuzNCmykfKRIIidNvnmXmaeYlNcmkzYM4tNGnIzyi1nd+4FYD3JhCAEowSF/tAhQ= X-Received: by 10.129.45.137 with SMTP id t131mr74025248ywt.337.1452171686515; Thu, 07 Jan 2016 05:01:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.208.201 with HTTP; Thu, 7 Jan 2016 05:01:06 -0800 (PST) In-Reply-To: <20160107124119.GO58491@Space.Net> References: <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <568D8C1C.2020406@umn.edu> <20160107084859.GI58491@Space.Net> <20160107124119.GO58491@Space.Net> From: Lorenzo Colitti Date: Thu, 7 Jan 2016 22:01:06 +0900 Message-ID: To: Gert Doering Content-Type: multipart/alternative; boundary=001a1141e9b6879fbe0528be1149 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 13:02:26 -0000 --001a1141e9b6879fbe0528be1149 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 7, 2016 at 9:41 PM, Gert Doering wrote: > Actually, the description of all these details makes me wonder why we're > not recommending that the VM in question shouldn't just send its own > DHCPv6 IA_NA request when it wants an address. > That's the same problem as stated earlier - what if the request is denied? For example, what if the network has decided that the host's MAC address (remember, on wifi the VM's MAC address cannot appear on the wire except if you're using WDS or MAC NAT) has already received too many addresses? There's a reason why vmware implemented NAT66. That's in the draft too, BTW. Consider reading it, BTW. It might save on typing. Specifying "the network SHOULD add all that complexity" while at the > same time not even specifying how that example VM would then end up > receiving the address (is the host OS supposed to run SLAAC? DHCPv6?), > *and* argueing about implementor complexity while not even giving > implementors guidelines how to handle what the network is supposed > to be offering them is a bit unsatisfying. > What the host OS does depends on what the network gives it. Host behaviour is out of scope here, but one simple way to do it is to request a prefix if SLAAC is not available. > And here there's another problem: even if the host somehow knew that it > can > > get 100 IA_NA, that won't fit in an IPv6 packet, because an IA_NA is 44 > > bytes long, so the practical maximum is around 30-35 for a 1280-1500 MTU. > > (Yes, there is a Fragment header. No, it won't work in practice, and you > > know it.) > > Which makes a strong argument for having the VM itself request the IA_NA > when it wants an address. This DUID stuff *must* be useful for something. > Again, please read the draft before making comments that are already addressed there. Using different DUIDs is discussed in section 6. It is not clear that the network will expect the client (as identified by the host's MAC address) to use more than one DUID. > When you consider extending the network you have another problem. Every > > level of hierarchy (tethered device, VM inside a container, etc.) needs > to > > act as a DHCPv6 relay. (Don't say "bridging" because that doesn't work on > > wifi except using MAC NAT or virtually-impossible-to-deploy WDS.) > > With DHCPv6-PD, you need multiple levels of DHCPv6-PD, *and* DHCPv6-IA_NA > to the VM, because if you get a /64 from the network, you can't do SLAAC > on more than one internal network (and obviously the draft also applies > to internal networks, so the VM could rightfully expect DHCPv6-PD to > succeed, no?). The "bridging is impossible" is something that needs to be solved - as > the draft permits SLAAC, the VM example would totally break without > bridiging of some sort, because it won't be able to do SLAAC otherwise. > Nested PD and NA are not necessary. Inside a host, or in a simple tethered topology with no loops, you can simply do bridging or ND proxying and rely on SLAAC. That applies regardless of whether the network provides address space via SLAAC or DHCPv6 PD. That is one of the reasons why the draft recommends assigning a /64. > > And so on. From the point of view of a host implementer and of a user, > > that's a total nightmare. Search the archives for the total nightmare > that > > is implementing ePDG on a split application processor/baseband processor > > architecture with only one IPv4 address. This is what your phone does > when > > you do wifi calling, and the result is either an unreliable device, or > lack > > of other features because so much software engineering time had to be > spent > > on getting it right. > > Bringing in the poor quality of baseband processor implementations isn't > really a strong argument either way... The issue is not quality. The issue is that sharing an IP address without NAT (you can't easily do NAT because the baseband needs to accept unsolicited incoming packets, do IPsec, etc. etc.) is a nightmare. If you're arguing that splitting a phone into a baseband processor and application processor doesn't make sense, you might change your mind if you compare the battery life impact of voip calling with the battery life impact of VoLTE calling. --001a1141e9b6879fbe0528be1149 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 7, 2016 at 9:41 PM, Gert Doering <gert@space.net> wrote= :
Actually, the description of all these details makes = me wonder why we're
not recommending that the VM in question shouldn't just send its own DHCPv6 IA_NA request when it wants an address.

That's the same problem as stated earlier - what if the request= is denied? For example, what if the network has decided that the host'= s MAC address (remember, on wifi the VM's MAC address cannot appear on = the wire except if you're using WDS or MAC NAT) has already received to= o many addresses?

There's a reason why vmware = implemented NAT66. That's in the draft too, BTW. Consider reading it, B= TW. It might save on typing.

Specifyin= g "the network SHOULD add all that complexity" while at the
same time not even specifying how that example VM would then end up
receiving the address (is the host OS supposed to run SLAAC?=C2=A0 DHCPv6?)= ,
*and* argueing about implementor complexity while not even giving
implementors guidelines how to handle what the network is supposed
to be offering them is a bit unsatisfying.

<= div>What the host OS does depends on what the network gives it. Host behavi= our is out of scope here, but one simple way to do it is to request a prefi= x if SLAAC is not available.

> And here there's another problem: even if the host somehow= knew that it can
> get 100 IA_NA, that won't fit in an IPv6 packet, because an IA_NA = is 44
> bytes long, so the practical maximum is around 30-35 for a 1280-1500 M= TU.
> (Yes, there is a Fragment header. No, it won't work in practice, a= nd you
> know it.)

Which makes a strong argument for having the VM itself request the I= A_NA
when it wants an address.=C2=A0 This DUID stuff *must* be useful for someth= ing.

Again, please read the draft befor= e making comments that are already addressed there. Using different DUIDs i= s discussed in section 6. It is not clear that the network will expect the = client (as identified by the host's MAC address) to use more than one D= UID.

> When you co= nsider extending the network you have another problem. Every
> level of hierarchy (tethered device, VM inside a container, etc.) need= s to
> act as a DHCPv6 relay. (Don't say "bridging" because tha= t doesn't work on
> wifi except using MAC NAT or virtually-impossible-to-deploy WDS.)

With DHCPv6-PD, you need multiple levels of DHCPv6-PD, *and* DHCPv6-= IA_NA
to the VM, because if you get a /64 from the network, you can't do SLAA= C
on more than one internal network (and obviously the draft also applies
to internal networks, so the VM could rightfully expect DHCPv6-PD to
succeed, no?).=C2=A0
The "bridging is imp= ossible" is something that needs to be solved - as
the draft permits SLAAC, the VM example would totally break without
bridiging of some sort, because it won't be able to do SLAAC otherwise.=

Nested PD and NA are not necessary. In= side a host, or in a simple tethered topology with no loops, you can simply= do bridging or ND proxying and rely on SLAAC. That applies regardless of w= hether the network provides address space via SLAAC or DHCPv6 PD. That is o= ne of the reasons why the draft recommends assigning a /64.
= =C2=A0
> And so on. From the = point of view of a host implementer and of a user,
> that's a total nightmare. Search the archives for the total nightm= are that
> is implementing ePDG on a split application processor/baseband process= or
> architecture with only one IPv4 address. This is what your phone does = when
> you do wifi calling, and the result is either an unreliable device, or= lack
> of other features because so much software engineering time had to be = spent
> on getting it right.

Bringing in the poor quality of baseband processor implementations i= sn't
really a strong argument either way...

The = issue is not quality. The issue is that sharing an IP address without NAT (= you can't easily do NAT because the baseband needs to accept unsolicite= d incoming packets, do IPsec, etc. etc.) is a nightmare.

If you're arguing that splitting a phone into a baseband process= or and application processor doesn't make sense, you might change your = mind if you compare the battery life impact of voip calling with the batter= y life impact of VoLTE calling.
--001a1141e9b6879fbe0528be1149-- From nobody Thu Jan 7 05:04:10 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69DE51A8973 for ; Thu, 7 Jan 2016 05:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 8Msf-Sbtha9J for ; Thu, 7 Jan 2016 05:04:08 -0800 (PST) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB8B81A8983 for ; Thu, 7 Jan 2016 05:04:07 -0800 (PST) Received: by mail-qk0-x233.google.com with SMTP id n135so176454527qka.2 for ; Thu, 07 Jan 2016 05:04:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ULAwTHEuNjdRipazED3jjGiqJdy6I2gViqSfV1tuseQ=; b=bS2uutcLKM1VieAKBNjNb8ncqi2Gs8rzGU0p92WJfnDZMAp+/EZysqlIF6RhdLqC8g 3CxgqoRshLrF074Qnc9NMj5bRlOzhGtyNmhwkBek4fJQa4j1YM43YMmZR0DZgwweAsNA UILCyPF1w0yWKOKzJTqAqVigv1+f0qESjCYqcgW91fcaCFrFT5zXreEEd4l7TOU+jWIN BwYIqMowGZftUxY4hBQu/Tzb292R1VNEg+w6KDiimtTQST6CqGtnOH74extAE8irySEV 2d+Hg8kXq532+Ez6zWbsZ/DMvrPnpWy4q7hAY6ilYFrFNIaAhcNgBPIm4kXJ24K17CdQ UFuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ULAwTHEuNjdRipazED3jjGiqJdy6I2gViqSfV1tuseQ=; b=O36UnTiuocDmxOnkxBhYY1Rtsf4cEfYvafan9lLAQ5DM8rlIrycAXkNDCeBlU0hgfa BBEg6zCB/eHwu3/U2tuZxbpA5MCuO1MCB6YOqO79yH2b8atWqs2SYVKpe7tkh5Xnl85k ZH5JbSdGusN96saGAwb6Ca4yuYb6/aoyE2WPJsr8Zp/5Cui+aSucG8k6dJmHhasTsGJx 8HFhut7r0YF87VEbUO0Rrg1yk2HiN/GeZ3eF+dqp+0FEWGRGz/wDk946zAvvFxYOXcY6 9+gjYangiWAa7xkE70aq+zx3a9N9VzdddgwxYEcOKhEJAhbRDp+L2hLOhzLGd+afb8kO sTrQ== X-Gm-Message-State: ALoCoQm3q55TIKmbEfhDDuoTVXE/Beh8je6dyc+Sg86r4VCNsrmznkwAGomFH/qP79M4fJEYUmB92K24K+nktJndOqiHl2ak22JZqipwt2yqEpVlUOyXx2A= X-Received: by 10.13.238.194 with SMTP id x185mr84429332ywe.35.1452171846774; Thu, 07 Jan 2016 05:04:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.208.201 with HTTP; Thu, 7 Jan 2016 05:03:47 -0800 (PST) In-Reply-To: References: From: Lorenzo Colitti Date: Thu, 7 Jan 2016 22:03:47 +0900 Message-ID: To: "Eric Vyncke (evyncke)" Content-Type: multipart/alternative; boundary=94eb2c03109414fa1f0528be1b2d Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Routers are hosts too! (Re: I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 13:04:09 -0000 --94eb2c03109414fa1f0528be1b2d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Wrong link, sorry. Here's the right one. https://blogs.technet.microsoft.com/rrasblog/2007/01/23/broadband-connectio= ns-and-dhcpv6-prefix-delegation-in-windows-vista/ On Thu, Jan 7, 2016 at 9:57 PM, Eric Vyncke (evyncke) wrote: > I like it when my pessimistic view is correct :-) > > OTOH, the Windows blog states "DHCPv6 Stateful mode is where a client > uses DHCPv6 to obtain an IPv6 address from the DHCPv6 server along with > other configuraiton parameters." so no hint about DHCP-PD... This was my > concern about DHCP-PD on host: an issue of implementation only (fixable) > and not in protocol or religious host vs router was (unfixable) ;-) > > -=C3=A9ric > > > From: Lorenzo Colitti > Date: jeudi 7 janvier 2016 13:46 > To: Eric Vyncke > Cc: Mark Smith , Fred L Templin < > Fred.L.Templin@boeing.com>, "v6ops@ietf.org WG" > Subject: Re: [v6ops] Routers are hosts too! (Re: I-D Action: > draft-ietf-v6ops-host-addr-availability-04.txt) > > On Thu, Jan 7, 2016 at 8:57 PM, Eric Vyncke (evyncke) > wrote: > >> Now, I respectfully disagree on the fact we have experience with host >> doing DHCP-PD: for sure about Linux (and even it is user space) but what >> about Windows? Or iOS (lowercase :-) )? Or ??? >> > > Windows has supported DHCPv6 since 2007: > https://blogs.technet.microsoft.com/teamdhcp/2007/01/23/dhcpv6-behaviour-= in-windows-vista/ > > As for iOS - two of the authors work for Apple, and both of them write > code, so if they are saying that DHCPv6 PD is an option, I'd assume that > it's possible to implement it on iOS :-) > > --94eb2c03109414fa1f0528be1b2d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Jan 7, 2016 at 9:57 PM, Eric Vyncke (evyncke) <ev= yncke@cisco.com> wrote:
I like it when my pessimistic view is correct :-)=C2=A0

OTOH, the Windows blog states "DHCPv6 Stateful mode is where a client uses DHCPv= 6 to obtain an IPv6 address from the DHCPv6 server along with other configuraiton paramet= ers." so no hint about DHCP-PD... This was my concern about DHCP-PD on= host: an issue of implementation only (fixable) and not in protocol or rel= igious host vs router was (unfixable) ;-)

-=C3=A9ric=


From: Lorenzo Colitti <lorenzo@google.com>=
Date: jeudi 7 janvier 2016 13:46 To: Eric Vyncke <evyncke@cisco.com>
Cc: Mark Smith <markzzzsmith@gmail.com>,= Fred L Templin <Fred.L.Templin@boeing.com>, "v6ops@ietf.org WG" <v6ops@iet= f.org>
Subject: Re: [v6ops] Routers are ho= sts too! (Re: I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt)

On Thu, Jan 7, 2016 at 8:57 PM, Eric Vyncke (evy= ncke) <evyncke@cisco.co= m> wrote:
Now, I respectfully disagree on the fact we have experience with host = doing DHCP-PD: for sure about Linux (and even it is user space) but what ab= out Windows? Or iOS (lowercase :-) )? Or ???


As for iOS - two of the authors work for Apple, and both of them write= code, so if they are saying that DHCPv6 PD is an option, I'd assume th= at it's possible to implement it on iOS :-)

--94eb2c03109414fa1f0528be1b2d-- From nobody Thu Jan 7 05:04:37 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3AE1A8996 for ; Thu, 7 Jan 2016 05:04:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 fbRMFkUs4l73 for ; Thu, 7 Jan 2016 05:04:33 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A36221A898B for ; Thu, 7 Jan 2016 05:04:33 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 2513260AB5 for ; Thu, 7 Jan 2016 14:04:32 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id CF015600FD for ; Thu, 7 Jan 2016 14:04:31 +0100 (CET) Received: (qmail 56190 invoked by uid 1007); 7 Jan 2016 14:04:31 +0100 Date: Thu, 7 Jan 2016 14:04:31 +0100 From: Gert Doering To: Lorenzo Colitti Message-ID: <20160107130431.GS58491@Space.Net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Routers are hosts too! (Re: I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 13:04:35 -0000 Hi, On Thu, Jan 07, 2016 at 09:46:54PM +0900, Lorenzo Colitti wrote: > On Thu, Jan 7, 2016 at 8:57 PM, Eric Vyncke (evyncke) > wrote: > > > Now, I respectfully disagree on the fact we have experience with host > > doing DHCP-PD: for sure about Linux (and even it is user space) but what > > about Windows? Or iOS (lowercase :-) )? Or ??? > > > > Windows has supported DHCPv6 since 2007: > https://blogs.technet.microsoft.com/teamdhcp/2007/01/23/dhcpv6-behaviour-in-windows-vista/ This is not exactly mentioning DHCPv6-PD... only stateless/stateful mode. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Thu Jan 7 05:05:08 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25B661A8990 for ; Thu, 7 Jan 2016 05:05:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfbCAftMkQdI for ; Thu, 7 Jan 2016 05:05:04 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 094ED1A8983 for ; Thu, 7 Jan 2016 05:05:03 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u07D51Xo000443 for ; Thu, 7 Jan 2016 14:05:01 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 409E9203786 for ; Thu, 7 Jan 2016 14:12:30 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 38DBF203785 for ; Thu, 7 Jan 2016 14:12:30 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u07D51DV013529 for ; Thu, 7 Jan 2016 14:05:01 +0100 To: v6ops@ietf.org References: <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <20160106190013.GZ58491@Space.Net> <2134F8430051B64F815C691A62D9831832F9ADA0@XCH-BLV-504.nw.nos.boeing.com> <20160106212058.GA58491@Space.Net> <2134F8430051B64F815C691A62D9831832F9B151@XCH-BLV-504.nw.nos.boeing.com> From: Alexandre Petrescu Message-ID: <568E627D.1000305@gmail.com> Date: Thu, 7 Jan 2016 14:05:01 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <2134F8430051B64F815C691A62D9831832F9B151@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 13:05:07 -0000 Le 06/01/2016 23:55, Templin, Fred L a écrit : > Hi Gert, > >> -----Original Message----- >> From: Gert Doering [mailto:gert@Space.Net] >> Sent: Wednesday, January 06, 2016 1:21 PM >> To: Templin, Fred L >> Cc: Gert Doering; Lorenzo Colitti; v6ops@ietf.org WG >> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt >> >> Hi, >> >> On Wed, Jan 06, 2016 at 07:57:14PM +0000, Templin, Fred L wrote: >>> As we have been saying, this could result in lots of multicast ND messaging >>> on the link over which the IA_NAs are received when clients configure lots >>> of addresses. It is also incompatible withclient mobility,. >> >> Supposedly multicast is one of the strong points of IPv6, > > Many people are saying that it is too harsh for some wireless access technologies. > >> and for mobility, there is mobile IPv6. > > Mobile IPv6 is about associating a mobile host's home address with a > care-of address through the insertion of a mobility extension header > (i.e., an encapsulation). It is about a mobile host that goes wandering > away from its home link yet wants to be able to still communicate as > though it was still at home. It is uni-addressing centric, whereas we > want to support mobile devices that need multi-addressing. Yes, it is a total network-layer centric solution smoothly hiding all address change events from applications. Mobile IPv6 is also about Mobile Routers (NEMO - Network Mobility, RFC3963). Uni-address centric? No, because in NEMO there is also use of DHCPv6-PD between the Mobile Router and the Home Agent. The only aspects that could be considered as disadvantages to Mobile Routers implementing Mobile IPv6/NEMO are: - this totality coverage of address change disruption (some apps dont really need, some deal with it themselves). - lack of coverage of other mobility events (e.g. lack of deal with intermittent reconnection to precisely same network). - lack of securely established optimal routes (the famous RO). - lack of multi-tier edge IP address architectures (a Mobile Router is in theory one CPU with several IP interfaces, whereas in practice Mobile Routers are themselves separated in multiple CPUs tightly bound by some specific interfaces some being IP-enabled others not). >> If we think that these are all historic errors, and the future is IPv6 >> over GRE (or LISP), maybe we should make this more clear. > > Did I mention that AERO works over GRE: > > https://datatracker.ietf.org/doc/draft-templin-aeromin/ > > And, my understanding of LISP is that it requires an online mapping > database facility. This is no more or no less of a critical infrastructure > requirement than for AERO. I agree with this point. Many mobility solutions actually require infrastructure support - LISP, MIP, AERO. Because one of the fundamental principles of the Internet architecture is that one address is valid at one single particular point in the topology (it's not like e.g. the POBox address architecture which says that I can keep my POBox number wherever in the postal address system I am situated). Alex > > Thanks - Fred > fred.l.templin@boeing.com > >> Gert Doering >> -- NetMaster >> -- >> have you enabled IPv6 on something today...? >> >> SpaceNet AG Vorstand: Sebastian v. Bomhard >> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann >> D-80807 Muenchen HRB: 136055 (AG Muenchen) >> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Jan 7 05:07:56 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F14481A8973 for ; Thu, 7 Jan 2016 05:07:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-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 BEFy9WYZIqo8 for ; Thu, 7 Jan 2016 05:07:53 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9FAB1A8984 for ; Thu, 7 Jan 2016 05:07:53 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 754B860A99 for ; Thu, 7 Jan 2016 14:07:51 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 0C17C6010F for ; Thu, 7 Jan 2016 14:07:51 +0100 (CET) Received: (qmail 56447 invoked by uid 1007); 7 Jan 2016 14:07:51 +0100 Date: Thu, 7 Jan 2016 14:07:51 +0100 From: Gert Doering To: Lorenzo Colitti Message-ID: <20160107130750.GT58491@Space.Net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Routers are hosts too! (Re: I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 13:07:55 -0000 Hi, On Thu, Jan 07, 2016 at 10:03:47PM +0900, Lorenzo Colitti wrote: > Wrong link, sorry. Here's the right one. > https://blogs.technet.microsoft.com/rrasblog/2007/01/23/broadband-connections-and-dhcpv6-prefix-delegation-in-windows-vista/ "Only when Internet Connection Sharing is enabled on Windows Vista, where the host needs to act as a router for other clients on a home network does Windows Vista trigger the requesting router behaviour of prefix delegation." So, yes, the code is there - but typically not active on your travelling salesman's laptop (and if it were, it would as likely mess up everyone else's network as ICSs would happily announce Teredo, 6to4 and ISATAP prefixes everywhere...) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Thu Jan 7 05:09:35 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89DFD1A8978 for ; Thu, 7 Jan 2016 05:09:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ka_JBo9l9QVS for ; Thu, 7 Jan 2016 05:09:32 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD3EB1A8973 for ; Thu, 7 Jan 2016 05:09:31 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u07D9TuN011655 for ; Thu, 7 Jan 2016 14:09:29 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C67D1203785 for ; Thu, 7 Jan 2016 14:16:57 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id BE5F9200EC4 for ; Thu, 7 Jan 2016 14:16:57 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u07D9TpB019880 for ; Thu, 7 Jan 2016 14:09:29 +0100 To: v6ops@ietf.org References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <568D8C1C.2020406@umn.edu> From: Alexandre Petrescu Message-ID: <568E6388.3000300@gmail.com> Date: Thu, 7 Jan 2016 14:09:28 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 13:09:34 -0000 Le 07/01/2016 00:31, Tom Herbert a écrit : > On Wed, Jan 6, 2016 at 1:50 PM, David Farmer wrote: >> On 1/6/16 07:33 , Erik Kline wrote: >>> >>> On 6 January 2016 at 22:04, Philip Homburg >>> wrote: >>>>> >>>>> I think instead we can publish this as is, and in future v6ops can >>>>> look at a document describing host PD implementation and network >>>>> operations experience, if such a document even proves necessary (which >>>>> I doubt). >>>> >>>> >>>> I don't think we should write a BCP and then in a future document >>>> describe how it works. That's not what a BCP is for. >>>> >>>> If the PD part is not required for this document, then just remove it. >>> >>> >>> I disagree. PD is a perfectly valid way of addressing the issue and >>> it needs to be included at some level of description for completeness. >> >> >> I agree DHCPv6 PD needs to be included and should not be removed. >> >> However, lets look at the recommendation section. >> >> ... >> If the network requires explicit requests for address space (e.g., >> if it requires DHCPv6 to connect), it is RECOMMENDED that the network >> assign a /64 prefix to every host (e.g., via DHCPv6 PD). Using >> DHCPv6 IA_NA or IA_TA to request a sufficient number of addresses >> (e.g. 32) would accommodate current clients but sets a limit on the >> number of addresses available to hosts when they attach and would >> limit the development of future applications. >> ... >> >> This is could be interpreted as saying that networks SHOULD NOT use Stateful >> DHCPv6 for which there is a clear and unambiguous specification for Stateful >> DHCPv6 host behavior, and they should use DHCPv6 PD for which there is NOT a >> clear and unambiguous specification for DHCPv6 PD host behavior. However, >> there is a clear and unambiguous specification for DHCPv6 PD router >> behavior, but the importance of this distinction is debatable. >> >> What if the recommendation section was rewritten making the DHCP v6 PD part >> permissive and not a normative recommendation. >> >> 8. Recommendations >> >> In order to avoid the problems described above, and preserve the >> Internet's ability to support new applications that use more than one >> IPv6 address, it is RECOMMENDED that IPv6 network deployments provide >> multiple IPv6 addresses from each prefix to general-purpose hosts >> when they connect to the network. To support future use cases, it is >> RECOMMENDED to not impose a hard limit on the size of the address >> pool assigned to a host. >> >> If the network requires explicit requests for address space (e.g., >> if it requires DHCPv6 to connect), the network MAY assign a /64 >> prefix to every host (e.g., via DHCPv6 PD). Using DHCPv6 IA_NA or >> IA_TA to request a sufficient number of addresses (e.g. 32) would >> accommodate current clients but sets a limit on the number of >> addresses available to hosts when they attach and would limit the >> development of future applications. Assigning prefixes longer than >> a /64 will limit the flexibility of the host to further assign >> addresses to any internal functions, virtual machines, or downstream >> clients that require address space - for example, by not allowing >> the use of SLAAC. >> >> In some ways I like this better, it more clearly says /64 per host is only >> an option. The previous language formed as a conditional recommendation, >> which was confusing in my opinion. >> >> What do others think? > > For ILA needs I prefer the recommendation of a /64 assignment. While > we could alternatively define variable length identifiers and locators > I think that would be a significant increase in complexity in both the > protocol and implementation. Is there an argument that recommending > /64 assignment is too big to be a practical recommendation? /64 assigned by DHCP-PD to a computer is not necessarily too big, and can be a practical recommendation. The only inconvenient is that computer will not be able to assign _sub-prefixes_ out of that /64 (e.g. /65s) by using SLAAC/Ethernet to other virtualboxes in that computer, or to other real computers networked to it. Ethernet and similar links are very popular and they all require 64bit Interface IDs. The use of SLAAC is also very popular in IPv6 (much more than DHCPv6). There is no relationship between the 64bit limitation of Ethernet and SLAAC - SLAAC can accommodate /65 prefix lengths. Alex > > Tom > >> >> -- >> ================================================ >> David Farmer Email: farmer@umn.edu >> Office of Information Technology >> University of Minnesota >> 2218 University Ave SE Phone: 1-612-626-0815 >> Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 >> ================================================ >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Jan 7 05:11:54 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3051A8983 for ; Thu, 7 Jan 2016 05:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 bHGixNuRR8vb for ; Thu, 7 Jan 2016 05:11:51 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 558641A89A2 for ; Thu, 7 Jan 2016 05:11:46 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 453B460ACF for ; Thu, 7 Jan 2016 14:11:44 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 175B060A99 for ; Thu, 7 Jan 2016 14:11:44 +0100 (CET) Received: (qmail 56874 invoked by uid 1007); 7 Jan 2016 14:11:43 +0100 Date: Thu, 7 Jan 2016 14:11:43 +0100 From: Gert Doering To: Lorenzo Colitti Message-ID: <20160107131143.GU58491@Space.Net> References: <568D8C1C.2020406@umn.edu> <20160107084859.GI58491@Space.Net> <20160107124119.GO58491@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lV96Kx8RuHJ7ffZU" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 13:11:53 -0000 --lV96Kx8RuHJ7ffZU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Jan 07, 2016 at 10:01:06PM +0900, Lorenzo Colitti wrote: > On Thu, Jan 7, 2016 at 9:41 PM, Gert Doering wrote: >=20 > > Actually, the description of all these details makes me wonder why we're > > not recommending that the VM in question shouldn't just send its own > > DHCPv6 IA_NA request when it wants an address. >=20 > That's the same problem as stated earlier - what if the request is denied? "then you have no IPv6 for that VM" > For example, what if the network has decided that the host's MAC address > (remember, on wifi the VM's MAC address cannot appear on the wire except = if > you're using WDS or MAC NAT) has already received too many addresses? >=20 > There's a reason why vmware implemented NAT66. That's in the draft too, > BTW. Consider reading it, BTW. It might save on typing. No need to go through every individual text block if the conclusion alone is worth objecting to. > Specifying "the network SHOULD add all that complexity" while at the > > same time not even specifying how that example VM would then end up > > receiving the address (is the host OS supposed to run SLAAC? DHCPv6?), > > *and* argueing about implementor complexity while not even giving > > implementors guidelines how to handle what the network is supposed > > to be offering them is a bit unsatisfying. > > >=20 > What the host OS does depends on what the network gives it. Host behaviour > is out of scope here, but one simple way to do it is to request a prefix = if > SLAAC is not available. You're the one argueing that this all needs to be done to avoid implementat= ion complexity in the host OS - by introducing *more* implementation complexity (are you assuming that all networks will support this? What if someone supports SLAAC and IA_NA, but not PD? Yes, another implementation variant) [..] > Again, please read the draft before making comments that are already > addressed there. Using different DUIDs is discussed in section 6. It is n= ot > clear that the network will expect the client (as identified by the host's > MAC address) to use more than one DUID. Wouldn't it be MUCH easier to recommend that networks support multiple DUIDs per client / per MAC? > > The "bridging is impossible" is something that needs to be solved - as > > the draft permits SLAAC, the VM example would totally break without > > bridiging of some sort, because it won't be able to do SLAAC otherwise. >=20 > Nested PD and NA are not necessary. Inside a host, or in a simple tethered > topology with no loops, you can simply do bridging or ND proxying and rely > on SLAAC. That applies regardless of whether the network provides address > space via SLAAC or DHCPv6 PD. That is one of the reasons why the draft > recommends assigning a /64. The VM wouldn't know it's "inside the host". What if it wants multiple addresses? Like, for a nested VM? Why is bridging / ND proxying inside the host suddenly OK then? Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --lV96Kx8RuHJ7ffZU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVo5kD99WwGXkzn/FAQKynBAAr5SivjIheSE9ILtF8VRSDYMelMqnay2X Z96kAVSRWFSph2bsVDnSHczYhNw31OG2ShTQ5lLbgKgFnvfZV8GiMZqMUDsca9Gn nndRdKc14yQdEVu/tGb3/msqnH6wfDFEnrhgoU40ShkIHbZbVqPCQ5URAuRGOj1G fw4UivhjAokMfbSUQsOOJJUGOxjgCc9lYnr20tvHJL9ohXkHyMLFR2FZcdZ8nnn0 iKl1kMR5UbavvBui1+pAcu6svQRJXey+nKZqPUQl7eYWojRrcoqr/dmfyyv7S5nQ kI2uEQqmLPdd3UVqtUb6OOt7HDzwU1PN4+QY+1dQvLEFWVI/Xad7a5fmL4JCADvP wQ+o6bFP0RuBrMtdr1sQ8OTjeIZDRucdESZDZWkgX4t6dOq7PH0PTFdS5iiXr8Gp YWnLAiBHhwMjSmNUlxVtoVBRhVDz+llB5QxF8XGuHDxFCimJHJEQ2TB5taeCVimW C1Ub5pXCt/4GEZxgFzFqbf4QpCeOJl25Ae9mouKWp3aWtdlDxbYFY6IBElB9wrZB 6udTrkE8osAsLEC7yVjKwsd1LBSr9+7eVoWSE0TpcoqGzVTOK3A7ekA4Uaa5plZn VipA82bjWmF0HY8K/lwoSZ6GWAIzmAOPL6hk9wi9U0bsmo3bOPAaT5wlO6qlxgxm sn2paaubrFE= =/f/R -----END PGP SIGNATURE----- --lV96Kx8RuHJ7ffZU-- From nobody Thu Jan 7 05:12:09 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED381A8961 for ; Thu, 7 Jan 2016 05:12:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhLfG0mUSulG for ; Thu, 7 Jan 2016 05:12:05 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36C4D1A8983 for ; Thu, 7 Jan 2016 05:12:05 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u07DC3GU014681 for ; Thu, 7 Jan 2016 14:12:03 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B1CC9203785 for ; Thu, 7 Jan 2016 14:19:31 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A923F203797 for ; Thu, 7 Jan 2016 14:19:31 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u07DC2dj022769 for ; Thu, 7 Jan 2016 14:12:03 +0100 To: v6ops@ietf.org References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <568D8C1C.2020406@umn.edu> <2134F8430051B64F815C691A62D9831832F9B2A4@XCH-BLV-504.nw.nos.boeing.com> From: Alexandre Petrescu Message-ID: <568E6422.5050004@gmail.com> Date: Thu, 7 Jan 2016 14:12:02 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <2134F8430051B64F815C691A62D9831832F9B2A4@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 13:12:08 -0000 Le 07/01/2016 00:38, Templin, Fred L a écrit : > Hi, > >> -----Original Message----- >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Tom Herbert >> Sent: Wednesday, January 06, 2016 3:31 PM >> To: David Farmer >> Cc: v6ops@ietf.org >> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt >> >> On Wed, Jan 6, 2016 at 1:50 PM, David Farmer wrote: >>> On 1/6/16 07:33 , Erik Kline wrote: >>>> >>>> On 6 January 2016 at 22:04, Philip Homburg >>>> wrote: >>>>>> >>>>>> I think instead we can publish this as is, and in future v6ops can >>>>>> look at a document describing host PD implementation and network >>>>>> operations experience, if such a document even proves necessary (which >>>>>> I doubt). >>>>> >>>>> >>>>> I don't think we should write a BCP and then in a future document >>>>> describe how it works. That's not what a BCP is for. >>>>> >>>>> If the PD part is not required for this document, then just remove it. >>>> >>>> >>>> I disagree. PD is a perfectly valid way of addressing the issue and >>>> it needs to be included at some level of description for completeness. >>> >>> >>> I agree DHCPv6 PD needs to be included and should not be removed. >>> >>> However, lets look at the recommendation section. >>> >>> ... >>> If the network requires explicit requests for address space (e.g., >>> if it requires DHCPv6 to connect), it is RECOMMENDED that the network >>> assign a /64 prefix to every host (e.g., via DHCPv6 PD). Using >>> DHCPv6 IA_NA or IA_TA to request a sufficient number of addresses >>> (e.g. 32) would accommodate current clients but sets a limit on the >>> number of addresses available to hosts when they attach and would >>> limit the development of future applications. >>> ... >>> >>> This is could be interpreted as saying that networks SHOULD NOT use Stateful >>> DHCPv6 for which there is a clear and unambiguous specification for Stateful >>> DHCPv6 host behavior, and they should use DHCPv6 PD for which there is NOT a >>> clear and unambiguous specification for DHCPv6 PD host behavior. However, >>> there is a clear and unambiguous specification for DHCPv6 PD router >>> behavior, but the importance of this distinction is debatable. >>> >>> What if the recommendation section was rewritten making the DHCP v6 PD part >>> permissive and not a normative recommendation. >>> >>> 8. Recommendations >>> >>> In order to avoid the problems described above, and preserve the >>> Internet's ability to support new applications that use more than one >>> IPv6 address, it is RECOMMENDED that IPv6 network deployments provide >>> multiple IPv6 addresses from each prefix to general-purpose hosts >>> when they connect to the network. To support future use cases, it is >>> RECOMMENDED to not impose a hard limit on the size of the address >>> pool assigned to a host. >>> >>> If the network requires explicit requests for address space (e.g., >>> if it requires DHCPv6 to connect), the network MAY assign a /64 >>> prefix to every host (e.g., via DHCPv6 PD). Using DHCPv6 IA_NA or >>> IA_TA to request a sufficient number of addresses (e.g. 32) would >>> accommodate current clients but sets a limit on the number of >>> addresses available to hosts when they attach and would limit the >>> development of future applications. Assigning prefixes longer than >>> a /64 will limit the flexibility of the host to further assign >>> addresses to any internal functions, virtual machines, or downstream >>> clients that require address space - for example, by not allowing >>> the use of SLAAC. >>> >>> In some ways I like this better, it more clearly says /64 per host is only >>> an option. The previous language formed as a conditional recommendation, >>> which was confusing in my opinion. >>> >>> What do others think? >> >> For ILA needs I prefer the recommendation of a /64 assignment. While >> we could alternatively define variable length identifiers and locators >> I think that would be a significant increase in complexity in both the >> protocol and implementation. Is there an argument that recommending >> /64 assignment is too big to be a practical recommendation? > > Similarly, AERO would prefer a /64 or shorter (e.g., /60, /56. etc.). I do not > think /64 is too big, and I think cellular operators are already doing this. YEs, cellular operators use DHCPv6-PD between routers in the network infrastructure to assign some prefix lengths; and use RA to announce /64s to the user equipment; and use DHCPv6-address to assign 128bit address(es) to the UE. Yet cellular operators dont provide DHCPv6-PD to the UE. When they do, there will be no problem to move that /64 which was initially in the RA to a DHCPv6 Advertize message. Alex > > Thanks - Fred > fred.l.templin@boeing.com > >> Tom >> >>> >>> -- >>> ================================================ >>> David Farmer Email: farmer@umn.edu >>> Office of Information Technology >>> University of Minnesota >>> 2218 University Ave SE Phone: 1-612-626-0815 >>> Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 >>> ================================================ >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Jan 7 05:14:06 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 662461A8963 for ; Thu, 7 Jan 2016 05:14:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 hVIZNqOwIjdj for ; Thu, 7 Jan 2016 05:14:04 -0800 (PST) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1D8C1A8986 for ; Thu, 7 Jan 2016 05:14:03 -0800 (PST) Received: by mail-qk0-x233.google.com with SMTP id q19so121323847qke.3 for ; Thu, 07 Jan 2016 05:14:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=X/7oFNWBEenKpWGwonMnBMX2JittC3Xf4fq/X4Z6g2Q=; b=OTUBtRbbosyU6XiWxIBc2fJp4AD+WgeggUnIvQMBauAeP3vh9h9BJTCqAog6IN7ssD 9Gj/cx1twx9+vcsX63hzG5rbp+2lMPprYBn117vZ395FUVqZPUHxIHYjT8EQ7g7MekrC yW0MdwVppsFzuad6VOC6bad6Vf02jizDnUtB9PQyAoXUmqmPnoFNXJSndejhRMrarYJG iuTOj0mlHMhwhOsE/3gQ/OdCbc85SaEAftQubjSjalXkoGEDB8kKnyUCxe9EXv2q4TN8 3ITt7pfmprT8yC6p6wrluXl/t473dGhQIzfycqEd2LXyRtMM23ZVh6PlemgtQc0koG2x PP3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=X/7oFNWBEenKpWGwonMnBMX2JittC3Xf4fq/X4Z6g2Q=; b=b2gJWr6pTEDOOBgWrVO3WwSYbwF4Jqa/A9c1ePImMny33o7XUB4Fkui/nK2BwIatxZ xmVr7KEgwsu8d0H5ERu73tuzB5I/JjAkxCaYeZLvYTS3IPGPQcg51ed7higbYR8gkjiK kl/PQe3T4pzCxqDkJS1H3EkB6zrywutX4rQSmXv06DL7znagqWs+2V2dnVaPNNKQRA8c vowEaPL5aECSPmjPo1jwIigBhsqlaGkuEq+CAyVLjL3HFaX/B3mzJcm8/FOrBDfVawpb 0C1BENEcb03jQ1J6W+8hMk6KTXk9iMHDk+e1SWn6PsJ69sqgaiGxI0WYMpbjdj3SIJYE 020w== X-Gm-Message-State: ALoCoQl4C0T30yRTx9Nw9/2pfaORVoKnhh9u/4RMshWaYsQDJiLFlNmI418NguNmI2gIkf0JkSmiJ6edAHoWIJ/iys2P7jtDXEbNuypuuEoaAfXKxnS82hY= X-Received: by 10.129.157.79 with SMTP id u76mr87630119ywg.123.1452172443014; Thu, 07 Jan 2016 05:14:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.208.201 with HTTP; Thu, 7 Jan 2016 05:13:43 -0800 (PST) In-Reply-To: <20160107130750.GT58491@Space.Net> References: <20160107130750.GT58491@Space.Net> From: Lorenzo Colitti Date: Thu, 7 Jan 2016 22:13:43 +0900 Message-ID: To: Gert Doering Content-Type: multipart/alternative; boundary=94eb2c0b61e89ecd740528be3efe Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Routers are hosts too! (Re: I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 13:14:05 -0000 --94eb2c0b61e89ecd740528be3efe Content-Type: text/plain; charset=UTF-8 On Thu, Jan 7, 2016 at 10:07 PM, Gert Doering wrote: > So, yes, the code is there - but typically not active on your travelling > salesman's laptop (and if it were, it would as likely mess up everyone > else's network as ICSs would happily announce Teredo, 6to4 and ISATAP > prefixes everywhere...) People do have it turned on. We know because it was a major cause of IPv6 brokenness in 2011. https://en.wikipedia.org/wiki/IPv6_brokenness_and_DNS_whitelisting IIRC the fix was not to disable ICS, but to stop ICS from sending 6to4 RAs. --94eb2c0b61e89ecd740528be3efe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 7, 2016 at 10:07 PM, Gert Doering <gert@space.net> wrot= e:
So, yes, the code is there - but typically not activ= e on your travelling
salesman's laptop (and if it were, it would as likely mess up everyone<= br> else's network as ICSs would happily announce Teredo, 6to4 and ISATAP prefixes everywhere...)

People do have it t= urned on. We know because it was a major cause of IPv6 brokenness in 2011.<= /div>


IIRC the fix was not to d= isable ICS, but to stop ICS from sending 6to4 RAs.
--94eb2c0b61e89ecd740528be3efe-- From nobody Thu Jan 7 05:17:11 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A83B1A898B for ; Thu, 7 Jan 2016 05:17:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5RECX_-_UWR for ; Thu, 7 Jan 2016 05:17:09 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2CE61A8989 for ; Thu, 7 Jan 2016 05:17:08 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u07DH74n016713; Thu, 7 Jan 2016 14:17:07 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 89A852012D2; Thu, 7 Jan 2016 14:24:35 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 743252010E9; Thu, 7 Jan 2016 14:24:35 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u07DH63T007686; Thu, 7 Jan 2016 14:17:06 +0100 To: Gert Doering References: <568D8B33.1060301@isi.edu> <568E5C93.5050201@gmail.com> <20160107124237.GP58491@Space.Net> From: Alexandre Petrescu Message-ID: <568E6552.9030008@gmail.com> Date: Thu, 7 Jan 2016 14:17:06 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160107124237.GP58491@Space.Net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Routers are hosts too! (Re: I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 13:17:10 -0000 Le 07/01/2016 13:42, Gert Doering a écrit : > Hi, > > On Thu, Jan 07, 2016 at 01:39:47PM +0100, Alexandre Petrescu wrote: >> - a router does implement longest-matching algorithms, a Host >> doesn't. > > Of course hosts do. Why would any implementor not do that? Why would a Host need to look out a nexthop in routing table? To forward to whom? Alex > > Gert Doering > -- NetMaster > From nobody Thu Jan 7 05:21:22 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1089C1A8990 for ; Thu, 7 Jan 2016 05:21:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-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 9Ahb8GQFb6eP for ; Thu, 7 Jan 2016 05:21:19 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 106361A898B for ; Thu, 7 Jan 2016 05:21:19 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 9312860AC8 for ; Thu, 7 Jan 2016 14:21:17 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 2DFF660934 for ; Thu, 7 Jan 2016 14:21:17 +0100 (CET) Received: (qmail 57544 invoked by uid 1007); 7 Jan 2016 14:21:17 +0100 Date: Thu, 7 Jan 2016 14:21:17 +0100 From: Gert Doering To: Alexandre Petrescu Message-ID: <20160107132117.GV58491@Space.Net> References: <568D8B33.1060301@isi.edu> <568E5C93.5050201@gmail.com> <20160107124237.GP58491@Space.Net> <568E6552.9030008@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="P/V1btyD6Sui+5oI" Content-Disposition: inline In-Reply-To: <568E6552.9030008@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Routers are hosts too! (Re: I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 13:21:20 -0000 --P/V1btyD6Sui+5oI Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Jan 07, 2016 at 02:17:06PM +0100, Alexandre Petrescu wrote: > Le 07/01/2016 13:42, Gert Doering a =E9crit : > > On Thu, Jan 07, 2016 at 01:39:47PM +0100, Alexandre Petrescu wrote: > >> - a router does implement longest-matching algorithms, a Host > >> doesn't. > > > > Of course hosts do. Why would any implementor not do that? >=20 > Why would a Host need to look out a nexthop in routing table? To=20 > forward to whom? Well, it needs to send its own packets somewhere, no? And guess=20 what, this is done using the normal routing table which (if you set=20 ip.forwarding=3D1) magically turns into a forwarding table. Hosts can have more than one interface, like "a LAN interface and a VPN tunnel interface". It really helps if they know which packet goes where. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --P/V1btyD6Sui+5oI Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVo5mTN9WwGXkzn/FAQI6/RAAsoUQ2oRZNHQ5gsXvVkFR+77LgwD9b5FQ EcTIc4mpTzZSnwlLkxDW31xzOQWgJaTHcWrselI3k8S8/Cj12dSwb28dBTaJ0OF6 x96BHB1ld0ZeMjaxU3GoIRQzs01f3QWGXKZ0N53hgzHtNaNn7/3bnglVSO/EWu5Z qR8VL689XHu2U+pp5albdX/cIdkU9QDfHToYAtaZZ7mXPtxKOEOVc4zjY2VFJAAg /RbkApmrLpO0tGfS4oyixjYgO0LR9h+Ob5UDx5vdianqRRb20wJ/p46xoCcgmsm1 jxVEPYNm343mNixvlw8Zo0AWkemuJROJNU2RLVWEF3JuCIoOxpBNNwDnWq19fGZo GIw2kP4FLUZVlN8zbCZcOviMLoravMir6efwVQXqv2cZDuHvr5nVCTsy8Cq5HDVm w6d+dAnm/MXNM20K+zzMEPdy8ZL/J4DtRiemwgPPVtYuyCHI0iC7h7pnHBD7Zjm4 o0zixznM4O1gwnL1FhsjWrj8RWpGcAtvxVNRulZHIEzRVLzCJbaSM0ji/lBhv1xE +GqYbcv7AOPkN0AJE16IicgpBKrXZFex21uCFKC7RTjRDXPutb68UuYElfcHRgg8 ImMNcngMwUNXRG2IfhX+J13NzXSsK8a/WX3rjC5l7rHlwKdHAL0sekefG0+l4D0r gCjvXifBQ4g= =j5O3 -----END PGP SIGNATURE----- --P/V1btyD6Sui+5oI-- From nobody Thu Jan 7 05:26:31 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A337F1A899C for ; Thu, 7 Jan 2016 05:26:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2fmQLQ_x8lD for ; Thu, 7 Jan 2016 05:26:29 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EB421A8992 for ; Thu, 7 Jan 2016 05:26:28 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u07DQRAC011505; Thu, 7 Jan 2016 14:26:27 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B049E2037AC; Thu, 7 Jan 2016 14:33:55 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9AE8F2012D0; Thu, 7 Jan 2016 14:33:55 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u07DQQaX017809; Thu, 7 Jan 2016 14:26:27 +0100 To: Gert Doering References: <568D8B33.1060301@isi.edu> <568E5C93.5050201@gmail.com> <20160107124237.GP58491@Space.Net> <568E6552.9030008@gmail.com> <20160107132117.GV58491@Space.Net> From: Alexandre Petrescu Message-ID: <568E6782.1000205@gmail.com> Date: Thu, 7 Jan 2016 14:26:26 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160107132117.GV58491@Space.Net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Routers are hosts too! (Re: I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 13:26:30 -0000 Le 07/01/2016 14:21, Gert Doering a écrit : > Hi, > > On Thu, Jan 07, 2016 at 02:17:06PM +0100, Alexandre Petrescu wrote: >> Le 07/01/2016 13:42, Gert Doering a écrit : >>> On Thu, Jan 07, 2016 at 01:39:47PM +0100, Alexandre Petrescu >>> wrote: >>>> - a router does implement longest-matching algorithms, a Host >>>> doesn't. >>> >>> Of course hosts do. Why would any implementor not do that? >> >> Why would a Host need to look out a nexthop in routing table? To >> forward to whom? > > Well, it needs to send its own packets somewhere, no? YEs, to its router. There's only one - the default. There are no neighbors to distinguish from. > And guess what, this is done using the normal routing table Yes, the 'normal' routing table because that's what we're used with since linux and Ethernet. But a Host using serial to connect to a router (e.g. a UE) does not need a routing table. > which (if > you set ip.forwarding=1) magically turns into a forwarding table. > > Hosts can have more than one interface, like "a LAN interface and a > VPN tunnel interface". It really helps if they know which packet > goes where. YEs, but these are not pure Hosts. They are more like desktop PCs and smartphones. Alex > > Gert Doering -- NetMaster > From nobody Thu Jan 7 05:35:30 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD3A1A89C6 for ; Thu, 7 Jan 2016 05:35:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 MnB1fBfTV89U for ; Thu, 7 Jan 2016 05:35:27 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 882581A89B4 for ; Thu, 7 Jan 2016 05:35:27 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id h11so36401733qke.1 for ; Thu, 07 Jan 2016 05:35:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=0od5a0KgTfN/y9CjSZaMEbpKLiOhaK+lp9mns7oSV/Q=; b=beT+ZWug43Q/IM9OND28tOGQN6U7ltmMwI57saU453Hy8XyGzCpnznWrdkcK+2ebLF 6AfncjdbixHGBApyqSb4A1TUb4YeXSQn+t4cr6s06c4PKSZuKVDk6ob9tbJ1FO9e8Rwo hZuMSNtLGvK+pgsyt/9bEwpjKjbX3ZV5RlYCdTcdpOU4WIBnBmxqzFnuUFUBWwy6g2Rl w9NiiwSNzyHCLxVJAVPJhPwgGWjmAW958xQijM7KiZWr0iqX9wO+7GZFpC82BYuxMLXa XjPAUWgA7xQIfmpJewwzGGd8pvWPYO9g7mbIs9v1z9ix9MX4boriiegCMeDNQAhYq2IH zoHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=0od5a0KgTfN/y9CjSZaMEbpKLiOhaK+lp9mns7oSV/Q=; b=ZFwNeP/WqtVjnD9vAef2sqEtEupwyRLXcir/FKcTyryUj7fE0/0ak6gZOgs4lA3y9K Q3bq2Dy0XHTN1GrIDiMo1elZFq2cUsm5jQADCEbMr9hkDPpxoBs0+nT5alK2L9cuW2Td kSkjQu3qgU4XAXuWyI0Y8PHBJjxqYJysE3nzVGeEEf1i+VqqvHwYb4H5VB36R/x8ySiA LxGxNWUOwBqGf+XWdcE3ps4VWZUaqu6noQ4IuoqFIN4k2KDZhhOadsJrO9YRopGju01o CBqEG3TJUf+fBgJeMQwQHTScZQwnSYjuRn2ui5OyPMm1xv4zpHnfYbteRu9cKOjCQQYN BOPw== X-Gm-Message-State: ALoCoQnLn8lUlDf/oA9rSdhoxBdAO9Hdyy3hSUr0HZBYNx/NsvQ1+BW+1OhZUtRptEEpJtoz+lVYfwRdRsqL/VC8fqsYoBUgoaftj/qqVQwUMeZoMpGPpoo= X-Received: by 10.129.108.88 with SMTP id h85mr87392028ywc.156.1452173726492; Thu, 07 Jan 2016 05:35:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.208.201 with HTTP; Thu, 7 Jan 2016 05:35:06 -0800 (PST) In-Reply-To: <20160107131143.GU58491@Space.Net> References: <568D8C1C.2020406@umn.edu> <20160107084859.GI58491@Space.Net> <20160107124119.GO58491@Space.Net> <20160107131143.GU58491@Space.Net> From: Lorenzo Colitti Date: Thu, 7 Jan 2016 22:35:06 +0900 Message-ID: To: Gert Doering Content-Type: multipart/alternative; boundary=001a114d88f01f31530528be8b30 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 13:35:29 -0000 --001a114d88f01f31530528be8b30 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 7, 2016 at 10:11 PM, Gert Doering wrote: > > > Actually, the description of all these details makes me wonder why > we're > > > not recommending that the VM in question shouldn't just send its own > > > DHCPv6 IA_NA request when it wants an address. > > > > That's the same problem as stated earlier - what if the request is > denied? > > "then you have no IPv6 for that VM" > Right, and on an IPv6-only network, "you have no network for that VM". Why do you think the NAT66 mode exists in vmware? Users don't like to be told what they can't do, and product managers don't like engineers to tell them "we can't implement user-visible feature X on this network because it will break " Is that what you want to have happen everywhere? > What the host OS does depends on what the network gives it. Host behaviour > > is out of scope here, but one simple way to do it is to request a prefix > if > > SLAAC is not available. > > You're the one argueing that this all needs to be done to avoid > implementation > complexity in the host OS - by introducing *more* implementation complexity > (are you assuming that all networks will support this? What if someone > supports SLAAC and IA_NA, but not PD? Yes, another implementation variant) > If a network supports SLAAC but not PD, the host can just use SLAAC. Internally I think it can use pretty much the same code for both. In the PD case the host needs to send an RA, but that's really not hard. > Again, please read the draft before making comments that are already > > addressed there. Using different DUIDs is discussed in section 6. It is > not > > clear that the network will expect the client (as identified by the > host's > > MAC address) to use more than one DUID. > > Wouldn't it be MUCH easier to recommend that networks support multiple > DUIDs per client / per MAC? > Not sure. Not sure it's worth pursuing since I doubt it will be possible to come to an agreement on how many "multiple" is. Bear in mind that the number can't just be a small number like 4 if the numbers in section 7 are to be believed. Do you think it's realistic to come to consensus on, say, "networks SHOULD support 32 DUIDs per MAC address, and hosts MAY ask for 32 DUIDs at connection time"? That seems much less scalable than one prefix, or SLAAC. > Nested PD and NA are not necessary. Inside a host, or in a simple tethered > > topology with no loops, you can simply do bridging or ND proxying and > rely > > on SLAAC. That applies regardless of whether the network provides address > > space via SLAAC or DHCPv6 PD. That is one of the reasons why the draft > > recommends assigning a /64. > > The VM wouldn't know it's "inside the host". What if it wants multiple > addresses? Like, for a nested VM? > > Why is bridging / ND proxying inside the host suddenly OK then? It's much easier to ensure there are no loops, and even if a loop is somehow created it doesn't take down affect other people except the user of the host. Because the host uses software, it scales better than having to put all the MAC addresses inside the TCAM of the first-hop router. --001a114d88f01f31530528be8b30 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 7, 2016 at 10:11 PM, Gert Doering <gert@space.net> wrot= e:
> > Actually, the description= of all these details makes me wonder why we're
> > not recommending that the VM in question shouldn't just send = its own
> > DHCPv6 IA_NA request when it wants an address.
>
> That's the same problem as stated earlier - what if the request is= denied?

"then you have no IPv6 for that VM"
<= br>
Right, and on an IPv6-only network, "you have no network= for that VM".

Why do you think the NAT66 mod= e exists in vmware? Users don't like to be told what they can't do,= and product managers don't like engineers to tell them "we can= 9;t implement user-visible feature X on this network because it will break = <incomprehensible bit about end-to-end that no non-engineer understands&= gt;"

Is that what you want to have happen eve= rywhere?

> What th= e host OS does depends on what the network gives it. Host behaviour
> is out of scope here, but one simple way to do it is to request a pref= ix if
> SLAAC is not available.

You're the one argueing that this all needs to be done to avoid = implementation
complexity in the host OS - by introducing *more* implementation complexity=
(are you assuming that all networks will support this?=C2=A0 What if someon= e
supports SLAAC and IA_NA, but not PD?=C2=A0 Yes, another implementation var= iant)
=C2=A0
If a network supports SLAAC but= not PD, the host can just use SLAAC. Internally I think it can use pretty = much the same code for both. In the PD case the host needs to send an RA, b= ut that's really not hard.

> Again, please read the draft before making comments that are= already
> addressed there. Using different DUIDs is discussed in section 6. It i= s not
> clear that the network will expect the client (as identified by the ho= st's
> MAC address) to use more than one DUID.

Wouldn't it be MUCH easier to recommend that networks support mu= ltiple
DUIDs per client / per MAC?

Not sure. N= ot sure it's worth pursuing since I doubt it will be possible to come t= o an agreement on how many "multiple" is. Bear in mind that the n= umber can't just be a small number like 4 if the numbers in section 7 a= re to be believed. Do you think it's realistic to come to consensus on,= say, "networks SHOULD support 32 DUIDs per MAC address, and hosts MAY= ask for 32 DUIDs at connection time"? That seems much less scalable t= han one prefix, or SLAAC.

> Nested PD and NA are not necessary. Inside a host, or in a simpl= e tethered
> topology with no loops, you can simply do bridging or ND proxying and = rely
> on SLAAC. That applies regardless of whether the network provides addr= ess
> space via SLAAC or DHCPv6 PD. That is one of the reasons why the draft=
> recommends assigning a /64.

The VM wouldn't know it's "inside the host".=C2=A0= What if it wants multiple
addresses?=C2=A0 Like, for a nested VM?

Why is bridging / ND proxying inside the host suddenly OK then?

It's much easier to ensure there are no loops, and even if a = loop is somehow created it doesn't take down affect other people except= the user of the host. Because the host uses software, it scales better tha= n having to put all the MAC addresses inside the TCAM of the first-hop rout= er.
--001a114d88f01f31530528be8b30-- From nobody Thu Jan 7 05:36:59 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3BA1A89B1 for ; Thu, 7 Jan 2016 05:36:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-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 Jq8Gf-GrB7kI for ; Thu, 7 Jan 2016 05:36:57 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C15B1A896A for ; Thu, 7 Jan 2016 05:36:57 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 89F2F6073A for ; Thu, 7 Jan 2016 14:36:55 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 44B2360612 for ; Thu, 7 Jan 2016 14:36:55 +0100 (CET) Received: (qmail 59093 invoked by uid 1007); 7 Jan 2016 14:36:55 +0100 Date: Thu, 7 Jan 2016 14:36:55 +0100 From: Gert Doering To: Alexandre Petrescu Message-ID: <20160107133655.GW58491@Space.Net> References: <568D8B33.1060301@isi.edu> <568E5C93.5050201@gmail.com> <20160107124237.GP58491@Space.Net> <568E6552.9030008@gmail.com> <20160107132117.GV58491@Space.Net> <568E6782.1000205@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="K3csRl7cGJjumTAO" Content-Disposition: inline In-Reply-To: <568E6782.1000205@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Routers are hosts too! (Re: I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 13:36:58 -0000 --K3csRl7cGJjumTAO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Jan 07, 2016 at 02:26:26PM +0100, Alexandre Petrescu wrote: > >> Why would a Host need to look out a nexthop in routing table? To > >> forward to whom? > > > > Well, it needs to send its own packets somewhere, no? >=20 > YEs, to its router. There's only one - the default. There are no=20 > neighbors to distinguish from. My hosts have ethernet neighbours, and there can be any number of routers on these ethernets. The "default gateway" is just the fallback if nothing more specific exists. [..] > But a Host using serial to connect to a router (e.g. a UE) does not need= =20 > a routing table. Of course it does. The moment it also has a wifi connection, and two interfaces are active, the locally connected networks alone require a routing decisions (because you wouldn't send a packet for a host on wifi to the 3G uplink). Very basic routing table, but still. > > which (if > > you set ip.forwarding=3D1) magically turns into a forwarding table. > > > > Hosts can have more than one interface, like "a LAN interface and a > > VPN tunnel interface". It really helps if they know which packet > > goes where. >=20 > YEs, but these are not pure Hosts. They are more like desktop PCs and=20 > smartphones. Now that begs the question what you consider to be a "Host"? A desktop PC, a smartphone - that's what the IETF considers a "host", and those are the largest mass... Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --K3csRl7cGJjumTAO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVo5p999WwGXkzn/FAQJ+6Q/+L7yZT3GIU2eyXUX7g6/8lUm4DmN/CIsl o2kJSV1uHD6DbZEHmKmhXjv1Hhcn3+UpMx343RnvOVNWlVRZMZ7jokJnOq7lL1Ed MW8C9vPCTcqrLvTBXRGKI3SsMAuZ9s2eSnE7N33TxXRprvwxfQXghlGwfH8gPrlP x8nrx6SuEYNX/j9QokZvlb6Sl+OO3XqnNLAHxozT3q3nu0V1e4lt/Oop5Sw5oqEI RJCs+Ile9AuzSlybyfwA0AbdKZVvhs9ISCSiC12fA2zZ29GNiu+qkWJxgToOHs0+ CfjJmuc0tSTsQAE3jz0jEs429E9EcJOywE7GvNl0R9ULpVaufWC90p/xtR9S4HQV xJw3zMeo85HBGYYQRMM8tLn2ZdbywOBodzzqWn+15Aq66bDkEx0uUH5rVwvdwqdq 1uetW6sTrps/mLGmoehB5qHnePBG0xm+pUCWC+J6c1QgRo6Omy0d3a87EIJz4+tE AOvd7LOHv+Kdltwf3b9kIackVtk/aZHoEqBZ3uCL8O8UxxQlDe0fdMC6Y4YXuXOP jdBfLJ5/nY7iISM/y858n03tueFSPmYUaiyzgbS9SXILSM/PruriB/9zYeOZO051 tNa9YfSLAEFJNwVfU/sJm5G7ydt9RdUM52DjBo48H2MySTh7DBoEBs4bXh/e8e1W uLzNTiCVUdU= =AB5L -----END PGP SIGNATURE----- --K3csRl7cGJjumTAO-- From nobody Thu Jan 7 05:40:20 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80E5F1A89C5 for ; Thu, 7 Jan 2016 05:40:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-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 XIU2_KJP008c for ; Thu, 7 Jan 2016 05:40:17 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BDAB1A89F1 for ; Thu, 7 Jan 2016 05:40:15 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 77CDF60AD5 for ; Thu, 7 Jan 2016 14:40:14 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 043CB60733 for ; Thu, 7 Jan 2016 14:40:14 +0100 (CET) Received: (qmail 59449 invoked by uid 1007); 7 Jan 2016 14:40:13 +0100 Date: Thu, 7 Jan 2016 14:40:13 +0100 From: Gert Doering To: Lorenzo Colitti Message-ID: <20160107134013.GX58491@Space.Net> References: <568D8C1C.2020406@umn.edu> <20160107084859.GI58491@Space.Net> <20160107124119.GO58491@Space.Net> <20160107131143.GU58491@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eD+3Znq9qCkGTJDZ" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 13:40:18 -0000 --eD+3Znq9qCkGTJDZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Jan 07, 2016 at 10:35:06PM +0900, Lorenzo Colitti wrote: > It's much easier to ensure there are no loops, and even if a loop is > somehow created it doesn't take down affect other people except the user = of > the host. Because the host uses software, it scales better than having to > put all the MAC addresses inside the TCAM of the first-hop router. Using that scaling argument, you should recommend that people do not=20 use SLAAC either - because wrt scaling the router's ND tables, there is no difference between SLAAC or IA_NA. Scaling ND tables by burdening FIB tables (SLAAC/IA_NA vs. PD) is a local= =20 tradeoff that will look very different depending on the equipment you use. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --eD+3Znq9qCkGTJDZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVo5qvd9WwGXkzn/FAQKICA/8CGbm10QPksT1tsulEi9gWGXvObc41YFb AVlqTtcpPHeTlhmAnn61Fig5ro6EXAwyrcxRk3RZf589fA0Pv0OVq5kg1hvCOna1 +zR/BcTw7rZ8CZdOtu7bti4rNK6E8eZI3d4UkjVOxHXlYRkLIWOj8elUdlGtjrF7 jVv15ETT1tBAYwf9dHWkz6rlHFtwe40kWsXgb4lKcNgNTd0YUUgT45Q7C7R1DRIV 0qOQEJOHOjI0P9Ue4SqGMsvKZAR+ywhBTDhiRIFXgfrQjKXr2A0eOCnzg/Y3OqZX 1leVI/1GusY4CUQe47clfmr2w9V5qIsBkGTUFh44IhXgejC+KPSMqcHA5eGibYm3 ITkVs5AaJcRhGvFrQDqUx+YTeiTP6XX7+hYa6wPQByPrcrk8VmMWqVlrvowBr/Q0 +ZcMv3/Ukzo0wW5K8E8bHxvrkWKmUTn+fCc5CJJjbw/ct1aHW7dmDUqkos6j+rM6 M+1taPox4HhZoyvlfYaTjnBfMI7AxJPatLDtpqqenejx7+GydGKeA/rNWpeY7XOC oM/H2CXlyaDudtSx+cml1TzX8utkfuYUQi11gtOsxyawSnINaE+C7nxWCllrAQ8d fnLrvELjb22huMOMk4mnH18nyae1B1jz8AYue0cVTrShpL8deTBO5ealtDTN6cjw 09OAYwIUZ6g= =HXN+ -----END PGP SIGNATURE----- --eD+3Znq9qCkGTJDZ-- From nobody Thu Jan 7 05:45:36 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0411A89C7 for ; Thu, 7 Jan 2016 05:45:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Py1Apgg8eLNo for ; Thu, 7 Jan 2016 05:45:35 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D5AC1A89E9 for ; Thu, 7 Jan 2016 05:45:34 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u07DjXV9019971; Thu, 7 Jan 2016 14:45:33 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6A90D2036F1; Thu, 7 Jan 2016 14:53:01 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5F3162012CE; Thu, 7 Jan 2016 14:53:01 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u07DjWmF004885; Thu, 7 Jan 2016 14:45:32 +0100 To: Gert Doering References: <568D8B33.1060301@isi.edu> <568E5C93.5050201@gmail.com> <20160107124237.GP58491@Space.Net> <568E6552.9030008@gmail.com> <20160107132117.GV58491@Space.Net> <568E6782.1000205@gmail.com> <20160107133655.GW58491@Space.Net> From: Alexandre Petrescu Message-ID: <568E6BFC.6070808@gmail.com> Date: Thu, 7 Jan 2016 14:45:32 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160107133655.GW58491@Space.Net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Routers are hosts too! (Re: I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 13:45:36 -0000 Le 07/01/2016 14:36, Gert Doering a écrit : > Hi, > > On Thu, Jan 07, 2016 at 02:26:26PM +0100, Alexandre Petrescu wrote: >>>> Why would a Host need to look out a nexthop in routing table? To >>>> forward to whom? >>> >>> Well, it needs to send its own packets somewhere, no? >> >> YEs, to its router. There's only one - the default. There are no >> neighbors to distinguish from. > > My hosts have ethernet neighbours, and there can be any number of routers > on these ethernets. They are not Hosts, they are desktop PCs. Hosts are defined in an RFC. > The "default gateway" is just the fallback if nothing > more specific exists. YEs. >> But a Host using serial to connect to a router (e.g. a UE) does not need >> a routing table. > > Of course it does. The moment it also has a wifi connection, and two > interfaces are active, the locally connected networks alone require a > routing decisions (because you wouldn't send a packet for a host on > wifi to the 3G uplink). Very basic routing table, but still. Yes, but these are smartphones or desktop PCs, not Hosts. Other than that RFC defining a Host, a host is someone or something that receives. And a router is something that makes roads (routes). >>> which (if >>> you set ip.forwarding=1) magically turns into a forwarding table. >>> >>> Hosts can have more than one interface, like "a LAN interface and a >>> VPN tunnel interface". It really helps if they know which packet >>> goes where. >> >> YEs, but these are not pure Hosts. They are more like desktop PCs and >> smartphones. > > Now that begs the question what you consider to be a "Host"? A desktop > PC, a smartphone - that's what the IETF considers a "host", and those are > the largest mass... The Host defined by IETF is in an RFC. Alex > > Gert Doering > -- NetMaster > From nobody Thu Jan 7 06:00:51 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4441A8A43 for ; Thu, 7 Jan 2016 06:00:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 B-vx8JX7LVmQ for ; Thu, 7 Jan 2016 06:00:48 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 508411A8A46 for ; Thu, 7 Jan 2016 06:00:42 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id q19so123170114qke.3 for ; Thu, 07 Jan 2016 06:00:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=RG/SxTpq5EjzTv+n2zXHby9oOtKTLne3C/WyT9P1erw=; b=eC/6hLnZ6ucQSXOuETxruq/0c/LTzR4psmoFtXlCWO5Ot7fviZzh6CH+669gd1dcNc OhB485esyZhy+I/UyGdPCnd2oLYlOkmJF0j0BKarID5pWrO08X9gDo7dVYc8t4KmUmzh Vlzbfh+YhFu+muPgM+CuSedazs1ePeQjS1CwFS/DEFzsZQhY6ltUl6mgGLCWazMzail8 /G6zMFyoM1UCw8ndZJwVdI9U1H4mdDu5OsuQXkTumuV6lus4Mq6rsHq2HumYjdhVb0HZ hlSRMOJ1wyn/mm27HlNArGmAGyZjiwkLgapoM4DkfVebF1TGjx1wfGLSQib2BR4xnjTR L+Ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=RG/SxTpq5EjzTv+n2zXHby9oOtKTLne3C/WyT9P1erw=; b=H1FP5bV/WealoVEQ88PPPMjw0sVy+Vo5lksH+BMfxhKNQdZXhHasrXexikTacVpYrN 8SwaJ98+hE7vm/I7tfv2aFJ1tLnpVFiL4grpLYyEnw4J24oy+K/eJKkZUgWOjS7JDlSC dU16xBIwqyVFThgMScM+4MPyYL9PLbJRE6PT+VW17gWMArEJN1ADhggxNaIklXzhqlnr 9lE1LyLbQT6hqB1Kvad0qWSesXBvBuiTFq8alW2+R5doUxQNkL4Z+b9Rzn5EiJlTUoCX Ot8DX8NX+QZVj8Hv/fAcWMKPazHuMtlL2fmt8z+dBLyHgGTUIBVMgzmH7SqR6pUirXu9 IFwg== X-Gm-Message-State: ALoCoQntuPVghk3yXLIXiqnycg8YgerIka1lDE2ToNczozFVNM3QiBJgBlJGSL+CIeEHf4vE+dY9KQEFSyz5dJlFIuLA8ZR4DXE7zZVshFIMXHurTTQm6D4= X-Received: by 10.129.45.137 with SMTP id t131mr74305026ywt.337.1452175241467; Thu, 07 Jan 2016 06:00:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.208.201 with HTTP; Thu, 7 Jan 2016 06:00:21 -0800 (PST) In-Reply-To: <20160107134013.GX58491@Space.Net> References: <568D8C1C.2020406@umn.edu> <20160107084859.GI58491@Space.Net> <20160107124119.GO58491@Space.Net> <20160107131143.GU58491@Space.Net> <20160107134013.GX58491@Space.Net> From: Lorenzo Colitti Date: Thu, 7 Jan 2016 23:00:21 +0900 Message-ID: To: Gert Doering Content-Type: multipart/alternative; boundary=001a1141e9b66bdddf0528bee5fd Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 14:00:49 -0000 --001a1141e9b66bdddf0528bee5fd Content-Type: text/plain; charset=UTF-8 On Thu, Jan 7, 2016 at 10:40 PM, Gert Doering wrote: > > It's much easier to ensure there are no loops, and even if a loop is > > somehow created it doesn't take down affect other people except the user > of > > the host. Because the host uses software, it scales better than having to > > put all the MAC addresses inside the TCAM of the first-hop router. > > Using that scaling argument, you should recommend that people do not > use SLAAC either - because wrt scaling the router's ND tables, there is > no difference between SLAAC or IA_NA. Yes, from the perspective of the first-hop router, PD does scale better. That's the subject of section 9.3. SLAAC and IA_NA are mostly identical in this respect. (I was trying to answer your "why is it OK to bridge inside the host but not between host and network" question.) --001a1141e9b66bdddf0528bee5fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 7, 2016 at 10:40 PM, Gert Doering <gert@space.net> wrot= e:
> It's much easier to ensure= there are no loops, and even if a loop is
> somehow created it doesn't take down affect other people except th= e user of
> the host. Because the host uses software, it scales better than having= to
> put all the MAC addresses inside the TCAM of the first-hop router.

Using that scaling argument, you should recommend that people do not=
use SLAAC either - because wrt scaling the router's ND tables, there is=
no difference between SLAAC or IA_NA.

Yes, = from the perspective of the first-hop router, PD does scale better. That= 9;s the subject of section 9.3. SLAAC and IA_NA are mostly identical in thi= s respect.

(I was trying to answer your "why = is it OK to bridge inside the host but not between host and network" q= uestion.)
--001a1141e9b66bdddf0528bee5fd-- From nobody Thu Jan 7 07:47:46 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 781201A9009 for ; Thu, 7 Jan 2016 07:47:45 -0800 (PST) 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, 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 7QekQPacafgz for ; Thu, 7 Jan 2016 07:47:44 -0800 (PST) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E34611A8FD6 for ; Thu, 7 Jan 2016 07:47:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u07FlhXb047102; Thu, 7 Jan 2016 08:47:43 -0700 Received: from XCH-PHX-113.sw.nos.boeing.com (xch-phx-113.sw.nos.boeing.com [130.247.25.136]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u07Fldka047062 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 7 Jan 2016 08:47:40 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.52]) by XCH-PHX-113.sw.nos.boeing.com ([169.254.13.35]) with mapi id 14.03.0235.001; Thu, 7 Jan 2016 07:47:39 -0800 From: "Templin, Fred L" To: "VAN DE VELDE, Gunter (Gunter)" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org" Thread-Topic: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host Thread-Index: AQHRRrIFI13RUsgT4kOKL/Th7Sw3uJ7vFi6A///VyTCAAW6RgP//3BOw Date: Thu, 7 Jan 2016 15:47:39 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F9BC14@XCH-BLV-504.nw.nos.boeing.com> References: <201601031900.u03J0LMe009763@irp-lnx1.cisco.com> <2134F8430051B64F815C691A62D9831832F9ADDE@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 15:47:45 -0000 SGkgR3VudGVyLA0KDQpPSywgc28geW91IGFyZSBzYXlpbmcgdGhhdCB0aGUgTUFDIGFkZHJlc3Mg b2YgdGhlIFVFIGlzIHVzZWQgYXMgdGhlIFVFIGlkZW50aWZpZXIuDQpCdXQsIGJvdGggbGluay1s b2NhbCBhbmQgTUFDIGFkZHJlc3NlcyBjYW4gYmUgcmVhZGlseSBzcG9vZmVkIGJ5IGFuIGF0dGFj a2VyLA0KZWl0aGVyIHRvIHN0ZWFsIHRoZSBzZXJ2aWNlIG9mIHRoZSBsZWdpdGltYXRlIG5vZGUg b3IgdG8gZGVueSBzZXJ2aWNlIHRvIHRoZQ0KbGVnaXRpbWF0ZSBub2RlLiBJbiBvcmRlciB0byBh dm9pZCB0aGF0LCB0aGUgVUUgd291bGQgaGF2ZSB0byBoYXZlIHNvbWUgZm9ybQ0Kb2YgaWRlbnRp ZmllciB0aGF0IGNhbm5vdCBiZSBzcG9vZmVkLCBvciBzaWduIGl0cyBtZXNzYWdlcyB1c2luZyBh IGNlcnRpZmljYXRlDQpwcm92aXNpb25lZCBieSB0aGUgc2VydmljZSBwcm92aWRlciAtIGV2ZW4g dGhvdWdoIGNhcHRpdmUgcG9ydGFsIGlzIGJlaW5nDQp1c2VkIHRvIGF1dGhlbnRpY2F0ZSB0aGUg dXNlci4NCg0KVGhhbmtzIC0gRnJlZA0KZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbQ0KDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFZBTiBERSBWRUxERSwgR3VudGVyIChH dW50ZXIpIFttYWlsdG86Z3VudGVyLnZhbl9kZV92ZWxkZUBhbGNhdGVsLWx1Y2VudC5jb21dDQo+ IFNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDA3LCAyMDE2IDE6NTEgQU0NCj4gVG86IFRlbXBsaW4s IEZyZWQgTDsgZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3RAdG9v bHMuaWV0Zi5vcmcNCj4gQ2M6IHY2b3BzQGlldGYub3JnIFdHDQo+IFN1YmplY3Q6IFJlOiBbdjZv cHNdIEZvY3VzZWQgZGlzY3Vzc2lvbjogZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVm aXgtcGVyLWhvc3QNCj4gDQo+IA0KPiBIaSBGcmVkLA0KPiANCj4gDQo+IFRoZSBXTEFOLUdXIHNo b3VsZCBub3QgY2FyZSBhYm91dCBvdmVybGFwIGhlcmUsIHRoZXJlIGlzIGEgc3BsaXQgaG9yaXpv biBmdW5jdGlvbiBhbmQgdGhlIHdsYW4tZ3cgc2hvdWxkIGJlIGFibGUgdG8gaGFuZGxlDQo+IG92 ZXJsYXBwaW5nIElQcy4gTGluay1sb2NhbCBhZGRyZXNzIG1heSBiZSBzdG9yZWQgdG8gZS5nLiB1 c2Ugd2hlbiBzZW5kaW5nIFJBLCBidXQgaXQgc2hvdWxkIG5vdCBiZSB1c2VkIGFzIGEga2V5LCB0 aGF0IGlzIHRoZSByb2xlIG9mDQo+IHRoZSBNQUMgYWRkcmVzcy4gU28gYXMgbG9uZyBhcyBNQUMg YWRkcmVzc2VzIGRvbid0IG92ZXJsYXAgdGhlcmUgc2hvdWxkIG5vdCBiZSBhIHByb2JsZW0gZGlz dGluZ3Vpc2hpbmcgVUVzLg0KPiANCj4gDQo+IFRoYXQgYmVpbmcgc2FpZCwgaXQgd291bGQgYmUg dW5saWtlbHkgdG8gaGFwcGVuIHNpbmNlIGxpbmstbG9jYWwgYWRkcmVzc2VzIGluIGEgV2lGaSBj b250ZXh0IGFyZSBtb3N0bHkgRVVJLTY0IGJhc2VkIGFuZCB0aHVzIGVuY29kZQ0KPiB0aGUgTUFD IGFkZHJlc3Mgd2hpY2ggYXMgc3RhdGVkIHNob3VsZCBiZSB1bmlxdWUuDQo+IA0KPiBLaW5kIFJl Z2FyZHMsDQo+IEcvDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IE9uIDA2LzAxLzE2IDIxOjAx LCAiVGVtcGxpbiwgRnJlZCBMIiA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4gd3JvdGU6DQo+ IA0KPiA+SSBoYXZlIHdoYXQgSSBob3BlIHdpbGwgYmUgYSBzaW1wbGUgcXVlc3Rpb246IHdoYXQg aWYgdHdvIG9yIG1vcmUgVUVzIGNvbmZpZ3VyZQ0KPiA+aWRlbnRpY2FsIElQdjYgbGluay1sb2Nh bCBhZGRyZXNzZXMgLSB3aWxsIHRoZSBXTEFOLUdXIGJlIGFibGUgdG8gdGVsbCB0aGVtIGFwYXJ0 Pw0KPiA+QXNrZWQgYW5vdGhlciB3YXksIHdoYXQga2luZCBvZiB1bmlxdWUgbm9kZSBpZGVudGlm aWVyIGRvZXMgdGhlIFdMQU4tR1cNCj4gPmV4cGVjdCBlYWNoIFVFIHRvIHByb3ZpZGUgaW4gdGhl IGluaXRpYWwgUlM/DQo+ID4NCj4gPlRoYW5rcyAtIEZyZWQNCj4gPmZyZWQubC50ZW1wbGluQGJv ZWluZy5jb20NCg== From nobody Thu Jan 7 07:51:07 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43AAF1A9027 for ; Thu, 7 Jan 2016 07:51:06 -0800 (PST) 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, HTML_MESSAGE=0.001, 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 eWmb_iTpkRFN for ; Thu, 7 Jan 2016 07:51:04 -0800 (PST) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 540081A9028 for ; Thu, 7 Jan 2016 07:50:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u07Fou6o052698; Thu, 7 Jan 2016 08:50:57 -0700 Received: from XCH-PHX-112.sw.nos.boeing.com (xch-phx-112.sw.nos.boeing.com [130.247.25.134]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u07FosSR052657 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 7 Jan 2016 08:50:54 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.52]) by XCH-PHX-112.sw.nos.boeing.com ([169.254.12.159]) with mapi id 14.03.0235.001; Thu, 7 Jan 2016 07:50:53 -0800 From: "Templin, Fred L" To: "Eric Vyncke (evyncke)" , Mark Smith Thread-Topic: [v6ops] Routers are hosts too! (Re: I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt) Thread-Index: AQHRSMitV7fnMhmxM0KqvFEotlF1cZ7wWE2A///cQ0A= Date: Thu, 7 Jan 2016 15:50:53 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F9BC32@XCH-BLV-504.nw.nos.boeing.com> References: 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: multipart/alternative; boundary="_000_2134F8430051B64F815C691A62D9831832F9BC32XCHBLV504nwnosb_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Routers are hosts too! (Re: I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 15:51:06 -0000 --_000_2134F8430051B64F815C691A62D9831832F9BC32XCHBLV504nwnosb_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBoYXZlIGJlZW4gZG9pbmcgREhDUHY2LVBEIHRvIGEgaG9zdCB1c2luZyBBRVJPIG9uIGJvdGgg bGludXggYW5kIEFuZHJvaWQgZm9yDQpxdWl0ZSBzb21lIHRpbWUgbm93Lg0KDQpUaGFua3MgLSBG cmVkDQoNCkZyb206IEVyaWMgVnluY2tlIChldnluY2tlKSBbbWFpbHRvOmV2eW5ja2VAY2lzY28u Y29tXQ0KU2VudDogVGh1cnNkYXksIEphbnVhcnkgMDcsIDIwMTYgMzo1OCBBTQ0KVG86IE1hcmsg U21pdGg7IFRlbXBsaW4sIEZyZWQgTA0KQ2M6IHY2b3BzQGlldGYub3JnIFdHDQpTdWJqZWN0OiBS ZTogW3Y2b3BzXSBSb3V0ZXJzIGFyZSBob3N0cyB0b28hIChSZTogSS1EIEFjdGlvbjogZHJhZnQt aWV0Zi12Nm9wcy1ob3N0LWFkZHItYXZhaWxhYmlsaXR5LTA0LnR4dCkNCg0KTWFyaywgKzEgaW5k ZWVkIG9uIHRoZSBzdGF0ZW1lbnQgdGhhdCByb3V0ZXJzIGFyZSBob3N0cyAoaS5lLiBUaGV5IHJl cGx5IHRvIElDTVAgJiBTTk1QIGFuZCBldmVuIGdlbmVyYXRlIElDTVAgd2l0aCB0aGVpciBvd24g Z2xvYmFsIGFkZHJlc3NlcyAtLSBlbHNlIFJGQyA3MDE0IC0tTExBLW9ubHkgLS0gc2hvdWxkIGhh dmUgYmVlbiBvYnZpb3VzKQ0KDQpOb3csIEkgcmVzcGVjdGZ1bGx5IGRpc2FncmVlIG9uIHRoZSBm YWN0IHdlIGhhdmUgZXhwZXJpZW5jZSB3aXRoIGhvc3QgZG9pbmcgREhDUC1QRDogZm9yIHN1cmUg YWJvdXQgTGludXggKGFuZCBldmVuIGl0IGlzIHVzZXIgc3BhY2UpIGJ1dCB3aGF0IGFib3V0IFdp bmRvd3M/IE9yIGlPUyAobG93ZXJjYXNlIDotKSApPyBPciA/Pz8NCg0KLcOpcmljDQoNCkZyb206 IHY2b3BzIDx2Nm9wcy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYu b3JnPj4gb24gYmVoYWxmIG9mIE1hcmsgU21pdGggPG1hcmt6enpzbWl0aEBnbWFpbC5jb208bWFp bHRvOm1hcmt6enpzbWl0aEBnbWFpbC5jb20+Pg0KRGF0ZTogbWVyY3JlZGkgNiBqYW52aWVyIDIw MTYgMjI6MjQNClRvOiBGcmVkIEwgVGVtcGxpbiA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTxt YWlsdG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4+DQpDYzogInY2b3BzQGlldGYub3JnPG1h aWx0bzp2Nm9wc0BpZXRmLm9yZz4gV0ciIDx2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0 Zi5vcmc+Pg0KU3ViamVjdDogW3Y2b3BzXSBSb3V0ZXJzIGFyZSBob3N0cyB0b28hIChSZTogSS1E IEFjdGlvbjogZHJhZnQtaWV0Zi12Nm9wcy1ob3N0LWFkZHItYXZhaWxhYmlsaXR5LTA0LnR4dCkN Cg0KDQpJIHRoaW5rIHBlb3BsZSBtaWdodCBiZSBnZXR0aW5nIGEgYml0IGNhdWdodCBpbiB0aGUg dHJhcCBvZiB0aGlua2luZyB0aGUgc2VwYXJhdGlvbiBiZXR3ZWVuIGhvc3RzIGFuZCByb3V0ZXJz IGlzIGEgbXVjaCBzdHJvbmdlciB0aGFuIGl0IGlzLg0KDQpSb3V0ZXJzIGFyZSB1bml2ZXJzYWxs eSBob3N0cyB0b28uIFRoZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIGEgcm91dGVyIGFuZCBhIGhvc3Qg aXMgdGhhdCBhIHJvdXRlciB3aWxsIGFsc28gYWNjZXB0IHBhY2tldHMgbm90IHNlbnQgdG8gYWRk cmVzc2VzIGFzc2lnbmVkIHRvIHRoZSBkZXZpY2VzIGludGVyZmFjZXMuIEl0IHdpbGwgdGhlbiBz ZWUgd2hhdCB0byBkbyB3aXRoIHRoZW0gYWNjb3JkaW5nIHRvIHRoZSByb3V0ZSB0YWJsZSwgc2Vu ZGluZyB0aGUgcGFja2V0IHdoZXJlIGV2ZXIgdGhlICByb3V0ZSB0YWJsZSBzYXlzIG9yIGRyb3Bw aW5nIHRoZW0uIFRoYXQgaXMgYWxsIHRoYXQgbWFrZXMgaXQgYSByb3V0ZXIuDQoNClJvdXRlcnMg YXJlIGhvc3RzIHRvbyBpZiB0aGVyZSBpcyBhbnl0aGluZyBhdCBhbGwgYWJvdmUgdGhlIElQIGxh eWVyIHRoYXQgbG9jYWxseSByZWNlaXZlcyBvciBsb2NhbGx5IG9yaWdpbmF0ZXMgcGFja2V0cyB1 c2luZyB0aGUgcm91dGVyJ3MgSVAgYWRkcmVzc2VzLiBTbyBTTk1QIGFnZW50cywgc3NoL3RlbG5l dCBkYWVtb25zIGFuZCBldmVuIEJHUCwgT1NQRiBhbmQgREhDUHY2IHByb2Nlc3NlcyBhcmUgaG9z dCBwcm9jZXNzZXMuDQoNClBlb3BsZSBzYXkgdGhlcmUgaXNuJ3QgbXVjaCBvciBhbnkgZXhwZXJp ZW5jZSB3aXRoIGhvc3RzIHVzaW5nIGFkZHJlc3NlcyBhc3NpZ25lZCB2aWEgREhDUHY2LVBELiBJ IGRvbid0IGFncmVlLCBiZWNhdXNlIGV2ZXJ5IHJlc2lkZW50aWFsIElQdjYgQ1BFIHN1cHBvcnRp bmcgREhDUHY2IHRoYXQgaXMgYWNxdWlyaW5nIGFkZHJlc3NlcyB2aWEgREhDUHY2LVBELCBETlMg c2V0dGluZ3MsIGdldHRpbmcgdGltZSB2aWEgTlRQIG9yIHByb3ZpZGluZyBhIHdlYiBhZG1pbmlz dHJhdGl2ZSBpbnRlcmZhY2UgaXMgYSBob3N0IHRvby4NCg0KVGFrZSBvbmUgb2YgdGhlc2UgQ1BF LCBkaXNhYmxlIHRoZSBMQU4gaW50ZXJmYWNlLCBhdHRhY2ggYSBzY3JlZW4sIGtleWJvYXJkIGFu ZCBtb3VzZSwgYW5kIHJ1biBhIHNwcmVhZHNoZWV0IG9yIHdlYiBicm93c2VyIG9uIGl0IGFuZCB5 b3UgaGF2ZSB0aGUgdHlwZSBvZiBob3N0IGJlaW5nIGRpc2N1c3NlZC4NCg0KVGhlIG9ubHkgd2F5 IGZvciBhIHJvdXRlciBub3QgdG8gYmUgYSBob3N0IHdvdWxkIGJlIGlmIGl0IHNwZWNpYWxseSBk aWRuJ3QgbGlzdGVuIGZvciBwYWNrZXRzIGFkZHJlc3NlZCB0byBpdHMgb3duIGFkZHJlc3Nlcywg c28gdGhhdCBhbGwgaXQgZXZlciBkaWQgd2FzIGZvcndhcmQgbm9uLWxvY2FsIHBhY2tldHMuIFlv dSBoYXZlIG5vIG1vbml0b3Jpbmcgb2YgaXQsIG5vIHJvdXRpbmcgcHJvdG9jb2xzLCBhbmQgd291 bGQgaGF2ZSB0byBjb25maWd1cmUgaXQgdmlhIGEgc2VyaWFsIGNhYmxlLg0KDQpNYXJrLg0K --_000_2134F8430051B64F815C691A62D9831832F9BC32XCHBLV504nwnosb_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4u RW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGhhdmUgYmVlbiBkb2luZyBESENQdjYtUEQg dG8gYSBob3N0IHVzaW5nIEFFUk8gb24gYm90aCBsaW51eCBhbmQgQW5kcm9pZCBmb3I8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+cXVpdGUgc29tZSB0aW1lIG5vdy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyAtIEZyZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBFcmljIFZ5bmNrZSAo ZXZ5bmNrZSkgW21haWx0bzpldnluY2tlQGNpc2NvLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBU aHVyc2RheSwgSmFudWFyeSAwNywgMjAxNiAzOjU4IEFNPGJyPg0KPGI+VG86PC9iPiBNYXJrIFNt aXRoOyBUZW1wbGluLCBGcmVkIEw8YnI+DQo8Yj5DYzo8L2I+IHY2b3BzQGlldGYub3JnIFdHPGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIFJvdXRlcnMgYXJlIGhvc3RzIHRvbyEgKFJl OiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXY2b3BzLWhvc3QtYWRkci1hdmFpbGFiaWxpdHktMDQu dHh0KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPk1hcmssICYjNDM7MSBpbmRlZWQgb24gdGhl IHN0YXRlbWVudCB0aGF0IHJvdXRlcnMgYXJlIGhvc3RzIChpLmUuIFRoZXkgcmVwbHkgdG8gSUNN UCAmYW1wOyBTTk1QIGFuZCBldmVuIGdlbmVyYXRlIElDTVAgd2l0aCB0aGVpciBvd24gZ2xvYmFs IGFkZHJlc3NlcyAtLSBlbHNlIFJGQyA3MDE0DQogLS1MTEEtb25seSAtLSBzaG91bGQgaGF2ZSBi ZWVuIG9idmlvdXMpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPk5vdywgSSByZXNwZWN0ZnVsbHkgZGlzYWdyZWUgb24g dGhlIGZhY3Qgd2UgaGF2ZSBleHBlcmllbmNlIHdpdGggaG9zdCBkb2luZyBESENQLVBEOiBmb3Ig c3VyZSBhYm91dCBMaW51eCAoYW5kIGV2ZW4gaXQgaXMgdXNlciBzcGFjZSkgYnV0IHdoYXQgYWJv dXQgV2luZG93cz8gT3INCiBpT1MgKGxvd2VyY2FzZSA6LSkgKT8gT3IgPz8/PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si Pi3DqXJpYzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+djZvcHMgJmx0OzxhIGhyZWY9Im1haWx0 bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnIj52Nm9wcy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsg b24gYmVoYWxmIG9mIE1hcmsgU21pdGggJmx0OzxhIGhyZWY9Im1haWx0bzptYXJrenp6c21pdGhA Z21haWwuY29tIj5tYXJrenp6c21pdGhAZ21haWwuY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8 L2I+bWVyY3JlZGkgNiBqYW52aWVyIDIwMTYgMjI6MjQ8YnI+DQo8Yj5UbzogPC9iPkZyZWQgTCBU ZW1wbGluICZsdDs8YSBocmVmPSJtYWlsdG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbSI+RnJl ZC5MLlRlbXBsaW5AYm9laW5nLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDs8YSBo cmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciPnY2b3BzQGlldGYub3JnPC9hPiBXRyZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT4mZ3Q7 PGJyPg0KPGI+U3ViamVjdDogPC9iPlt2Nm9wc10gUm91dGVycyBhcmUgaG9zdHMgdG9vISAoUmU6 IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdjZvcHMtaG9zdC1hZGRyLWF2YWlsYWJpbGl0eS0wNC50 eHQpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxl ZnQ6My43NXB0O21hcmdpbi1yaWdodDowaW4iIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9C TE9DS1FVT1RFIj4NCjxkaXY+DQo8ZGl2Pg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij5JIHRoaW5rIHBlb3BsZSBtaWdodCBiZSBnZXR0aW5nIGEgYml0IGNhdWdodCBpbiB0aGUgdHJh cCBvZiB0aGlua2luZyB0aGUgc2VwYXJhdGlvbiBiZXR3ZWVuIGhvc3RzIGFuZCByb3V0ZXJzIGlz IGEgbXVjaCBzdHJvbmdlciB0aGFuIGl0IGlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Um91dGVycyBhcmUgdW5pdmVyc2FsbHkgaG9zdHMg dG9vLiBUaGUgZGlzdGluY3Rpb24gYmV0d2VlbiBhIHJvdXRlciBhbmQgYSBob3N0IGlzIHRoYXQg YSByb3V0ZXIgd2lsbCBhbHNvIGFjY2VwdCBwYWNrZXRzIG5vdCBzZW50IHRvIGFkZHJlc3NlcyBh c3NpZ25lZCB0byB0aGUgZGV2aWNlcyBpbnRlcmZhY2VzLg0KIEl0IHdpbGwgdGhlbiBzZWUgd2hh dCB0byBkbyB3aXRoIHRoZW0gYWNjb3JkaW5nIHRvIHRoZSByb3V0ZSB0YWJsZSwgc2VuZGluZyB0 aGUgcGFja2V0IHdoZXJlIGV2ZXIgdGhlJm5ic3A7IHJvdXRlIHRhYmxlIHNheXMgb3IgZHJvcHBp bmcgdGhlbS4gVGhhdCBpcyBhbGwgdGhhdCBtYWtlcyBpdCBhIHJvdXRlci48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlJvdXRlcnMgYXJlIGhv c3RzIHRvbyBpZiB0aGVyZSBpcyBhbnl0aGluZyBhdCBhbGwgYWJvdmUgdGhlIElQIGxheWVyIHRo YXQgbG9jYWxseSByZWNlaXZlcyBvciBsb2NhbGx5IG9yaWdpbmF0ZXMgcGFja2V0cyB1c2luZyB0 aGUgcm91dGVyJ3MgSVAgYWRkcmVzc2VzLiBTbyBTTk1QIGFnZW50cywgc3NoL3RlbG5ldA0KIGRh ZW1vbnMgYW5kIGV2ZW4gQkdQLCBPU1BGIGFuZCBESENQdjYgcHJvY2Vzc2VzIGFyZSBob3N0IHBy b2Nlc3Nlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPlBlb3BsZSBzYXkgdGhlcmUgaXNuJ3QgbXVjaCBvciBhbnkgZXhwZXJpZW5jZSB3aXRo IGhvc3RzIHVzaW5nIGFkZHJlc3NlcyBhc3NpZ25lZCB2aWEgREhDUHY2LVBELiBJIGRvbid0IGFn cmVlLCBiZWNhdXNlIGV2ZXJ5IHJlc2lkZW50aWFsIElQdjYgQ1BFIHN1cHBvcnRpbmcgREhDUHY2 IHRoYXQgaXMgYWNxdWlyaW5nDQogYWRkcmVzc2VzIHZpYSBESENQdjYtUEQsIEROUyBzZXR0aW5n cywgZ2V0dGluZyB0aW1lIHZpYSBOVFAgb3IgcHJvdmlkaW5nIGEgd2ViIGFkbWluaXN0cmF0aXZl IGludGVyZmFjZSBpcyBhIGhvc3QgdG9vLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+VGFrZSBvbmUgb2YgdGhlc2UgQ1BFLCBkaXNhYmxlIHRo ZSBMQU4gaW50ZXJmYWNlLCBhdHRhY2ggYSBzY3JlZW4sIGtleWJvYXJkIGFuZCBtb3VzZSwgYW5k IHJ1biBhIHNwcmVhZHNoZWV0IG9yIHdlYiBicm93c2VyIG9uIGl0IGFuZCB5b3UgaGF2ZSB0aGUg dHlwZSBvZiBob3N0IGJlaW5nIGRpc2N1c3NlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlRoZSBvbmx5IHdheSBmb3IgYSByb3V0ZXIgbm90 IHRvIGJlIGEgaG9zdCB3b3VsZCBiZSBpZiBpdCBzcGVjaWFsbHkgZGlkbid0IGxpc3RlbiBmb3Ig cGFja2V0cyBhZGRyZXNzZWQgdG8gaXRzIG93biBhZGRyZXNzZXMsIHNvIHRoYXQgYWxsIGl0IGV2 ZXIgZGlkIHdhcyBmb3J3YXJkIG5vbi1sb2NhbCBwYWNrZXRzLg0KIFlvdSBoYXZlIG5vIG1vbml0 b3Jpbmcgb2YgaXQsIG5vIHJvdXRpbmcgcHJvdG9jb2xzLCBhbmQgd291bGQgaGF2ZSB0byBjb25m aWd1cmUgaXQgdmlhIGEgc2VyaWFsIGNhYmxlLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5NYXJrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_2134F8430051B64F815C691A62D9831832F9BC32XCHBLV504nwnosb_-- From nobody Thu Jan 7 07:58:11 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE3F1A9036 for ; Thu, 7 Jan 2016 07:58:10 -0800 (PST) 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, 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 ArGq0EW6pYbl for ; Thu, 7 Jan 2016 07:58:09 -0800 (PST) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF6671A902C for ; Thu, 7 Jan 2016 07:58:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u07Fw8j9040727; Thu, 7 Jan 2016 08:58:08 -0700 Received: from XCH-BLV-507.nw.nos.boeing.com (xch-blv-507.nw.nos.boeing.com [130.247.25.197]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u07Fvv9G040501 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 7 Jan 2016 08:57:57 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.52]) by XCH-BLV-507.nw.nos.boeing.com ([169.254.7.124]) with mapi id 14.03.0235.001; Thu, 7 Jan 2016 07:57:56 -0800 From: "Templin, Fred L" To: Gert Doering , Lorenzo Colitti Thread-Topic: [v6ops] Routers are hosts too! (Re: I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt) Thread-Index: AQHRSMitV7fnMhmxM0KqvFEotlF1cZ7wWE2AgAAvNgCAAAMQgIAAAaiAgAABI4D//6i5YA== Date: Thu, 7 Jan 2016 15:57:56 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F9BC6F@XCH-BLV-504.nw.nos.boeing.com> References: <20160107130750.GT58491@Space.Net> In-Reply-To: <20160107130750.GT58491@Space.Net> 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: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Routers are hosts too! (Re: I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 15:58:10 -0000 Hi, > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Gert Doering > Sent: Thursday, January 07, 2016 5:08 AM > To: Lorenzo Colitti > Cc: v6ops@ietf.org WG > Subject: Re: [v6ops] Routers are hosts too! (Re: I-D Action: draft-ietf-v= 6ops-host-addr-availability-04.txt) >=20 > Hi, >=20 > On Thu, Jan 07, 2016 at 10:03:47PM +0900, Lorenzo Colitti wrote: > > Wrong link, sorry. Here's the right one. > > https://blogs.technet.microsoft.com/rrasblog/2007/01/23/broadband-conne= ctions-and-dhcpv6-prefix-delegation-in-windows- > vista/ >=20 > "Only when Internet Connection Sharing is enabled on Windows Vista, > where the host needs to act as a router for other clients on a home > network does Windows Vista trigger the requesting router behaviour > of prefix delegation." >=20 > So, yes, the code is there - but typically not active on your travelling > salesman's laptop (and if it were, it would as likely mess up everyone > else's network as ICSs would happily announce Teredo, 6to4 and ISATAP > prefixes everywhere...) I am not arguing for ISATAP, but there is no such thing as an "ISATAP prefix". ISATAP can use any global IPv6 prefix, since it operates only within the site. Outside of the site, there is no way to tell for sure whether ISATAP is being used inside the site by examining only the prefix. Thanks - Fred fred.l.templin@boeing.com > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? >=20 > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culema= nn > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Jan 7 08:01:16 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF93C1A9039 for ; Thu, 7 Jan 2016 08:01:14 -0800 (PST) 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, 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 xaq8gSG1__fN for ; Thu, 7 Jan 2016 08:01:11 -0800 (PST) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E17161A9044 for ; Thu, 7 Jan 2016 08:01:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u07G1AA9005279; Thu, 7 Jan 2016 09:01:10 -0700 Received: from XCH-BLV-103.nw.nos.boeing.com (xch-blv-103.nw.nos.boeing.com [130.247.25.118]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u07G1183005196 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 7 Jan 2016 09:01:02 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.52]) by XCH-BLV-103.nw.nos.boeing.com ([169.254.3.127]) with mapi id 14.03.0235.001; Thu, 7 Jan 2016 08:01:01 -0800 From: "Templin, Fred L" To: Alexandre Petrescu , "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt Thread-Index: AQHRSWSaOrESi6NA/UCTjs8TrQcOtg== Date: Thu, 7 Jan 2016 16:01:00 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F9BC85@XCH-BLV-504.nw.nos.boeing.com> References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <568D8C1C.2020406@umn.edu> <568E6388.3000300@gmail.com> In-Reply-To: <568E6388.3000300@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 16:01:15 -0000 Hi Alex, > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandre Petres= cu > Sent: Thursday, January 07, 2016 5:09 AM > To: v6ops@ietf.org > Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-= 04.txt >=20 >=20 >=20 > Le 07/01/2016 00:31, Tom Herbert a =E9crit : > > On Wed, Jan 6, 2016 at 1:50 PM, David Farmer wrote: > >> On 1/6/16 07:33 , Erik Kline wrote: > >>> > >>> On 6 January 2016 at 22:04, Philip Homburg > >>> wrote: > >>>>> > >>>>> I think instead we can publish this as is, and in future v6ops can > >>>>> look at a document describing host PD implementation and network > >>>>> operations experience, if such a document even proves necessary (wh= ich > >>>>> I doubt). > >>>> > >>>> > >>>> I don't think we should write a BCP and then in a future document > >>>> describe how it works. That's not what a BCP is for. > >>>> > >>>> If the PD part is not required for this document, then just remove i= t. > >>> > >>> > >>> I disagree. PD is a perfectly valid way of addressing the issue and > >>> it needs to be included at some level of description for completeness= . > >> > >> > >> I agree DHCPv6 PD needs to be included and should not be removed. > >> > >> However, lets look at the recommendation section. > >> > >> ... > >> If the network requires explicit requests for address space (e.g., > >> if it requires DHCPv6 to connect), it is RECOMMENDED that the netw= ork > >> assign a /64 prefix to every host (e.g., via DHCPv6 PD). Using > >> DHCPv6 IA_NA or IA_TA to request a sufficient number of addresses > >> (e.g. 32) would accommodate current clients but sets a limit on th= e > >> number of addresses available to hosts when they attach and would > >> limit the development of future applications. > >> ... > >> > >> This is could be interpreted as saying that networks SHOULD NOT use St= ateful > >> DHCPv6 for which there is a clear and unambiguous specification for St= ateful > >> DHCPv6 host behavior, and they should use DHCPv6 PD for which there is= NOT a > >> clear and unambiguous specification for DHCPv6 PD host behavior. Howe= ver, > >> there is a clear and unambiguous specification for DHCPv6 PD router > >> behavior, but the importance of this distinction is debatable. > >> > >> What if the recommendation section was rewritten making the DHCP v6 PD= part > >> permissive and not a normative recommendation. > >> > >> 8. Recommendations > >> > >> In order to avoid the problems described above, and preserve the > >> Internet's ability to support new applications that use more than = one > >> IPv6 address, it is RECOMMENDED that IPv6 network deployments prov= ide > >> multiple IPv6 addresses from each prefix to general-purpose hosts > >> when they connect to the network. To support future use cases, it= is > >> RECOMMENDED to not impose a hard limit on the size of the address > >> pool assigned to a host. > >> > >> If the network requires explicit requests for address space (e.g., > >> if it requires DHCPv6 to connect), the network MAY assign a /64 > >> prefix to every host (e.g., via DHCPv6 PD). Using DHCPv6 IA_NA or > >> IA_TA to request a sufficient number of addresses (e.g. 32) would > >> accommodate current clients but sets a limit on the number of > >> addresses available to hosts when they attach and would limit the > >> development of future applications. Assigning prefixes longer tha= n > >> a /64 will limit the flexibility of the host to further assign > >> addresses to any internal functions, virtual machines, or downstre= am > >> clients that require address space - for example, by not allowing > >> the use of SLAAC. > >> > >> In some ways I like this better, it more clearly says /64 per host is = only > >> an option. The previous language formed as a conditional recommendati= on, > >> which was confusing in my opinion. > >> > >> What do others think? > > > > For ILA needs I prefer the recommendation of a /64 assignment. While > > we could alternatively define variable length identifiers and locators > > I think that would be a significant increase in complexity in both the > > protocol and implementation. Is there an argument that recommending > > /64 assignment is too big to be a practical recommendation? >=20 > /64 assigned by DHCP-PD to a computer is not necessarily too big, and > can be a practical recommendation. Agreed. But shorter prefixes (e.g., /60, /56, etc.) should also be possible= . > The only inconvenient is that computer will not be able to assign > _sub-prefixes_ out of that /64 (e.g. /65s) by using SLAAC/Ethernet to > other virtualboxes in that computer, or to other real computers > networked to it. Ethernet and similar links are very popular and they > all require 64bit Interface IDs. The use of SLAAC is also very popular > in IPv6 (much more than DHCPv6). There is no relationship between the > 64bit limitation of Ethernet and SLAAC - SLAAC can accommodate /65 > prefix lengths. Networking with a shorter prefix is possible with full support of SLAAC. There is also RFC7278. Thanks - Fred fred.l.templin@boeing.com > Alex >=20 > > > > Tom > > > >> > >> -- > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> David Farmer Email: farmer@umn.edu > >> Office of Information Technology > >> University of Minnesota > >> 2218 University Ave SE Phone: 1-612-626-0815 > >> Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Jan 7 08:13:59 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94BE91A9061 for ; Thu, 7 Jan 2016 08:13:58 -0800 (PST) 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, 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 OX3yWjWa6CNP for ; Thu, 7 Jan 2016 08:13:57 -0800 (PST) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28E791A8BC4 for ; Thu, 7 Jan 2016 08:13:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u07GDuZZ027470; Thu, 7 Jan 2016 09:13:56 -0700 Received: from XCH-BLV-302.nw.nos.boeing.com (xch-blv-302.nw.nos.boeing.com [130.247.25.214]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u07GDtJA027443 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 7 Jan 2016 09:13:56 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.52]) by XCH-BLV-302.nw.nos.boeing.com ([169.254.2.50]) with mapi id 14.03.0235.001; Thu, 7 Jan 2016 08:13:54 -0800 From: "Templin, Fred L" To: Gert Doering , Lorenzo Colitti Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt Thread-Index: AQHRSWZnUOqRwaVKv0GvQu+ugoAd1A== Date: Thu, 7 Jan 2016 16:13:54 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F9BCDF@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <568D8C1C.2020406@umn.edu> <20160107073826.GC58491@Space.Net> <20160107075820.GE58491@Space.Net> In-Reply-To: <20160107075820.GE58491@Space.Net> 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: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 16:13:58 -0000 Hi, > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Gert Doering > Sent: Wednesday, January 06, 2016 11:58 PM > To: Lorenzo Colitti > Cc: v6ops@ietf.org > Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-= 04.txt >=20 > Hi, >=20 > On Thu, Jan 07, 2016 at 04:47:21PM +0900, Lorenzo Colitti wrote: > > On Thu, Jan 7, 2016 at 4:38 PM, Gert Doering wrote: > > > > > If "we" recommend burning /64s in large scale, has someone done math = what > > > this does to the /48 which is typically permitted per site if that si= te > > > has a large number of users requesting prefixes? > > > > The math is in the draft. Have you read it? >=20 > I assume you're talking about section 9.2? This is a bit of handwaving > and telling us that "this is not a problem because where it might be a > problem, people will be using SLAAC, and thus, it is not a problem", > right? >=20 > I do see this is as potential problem for an enterprise that only has > a /48 (because that is what a site will get from RIPE), has multiple > attachment points, does not want 65k routes in their IGP (so, aggregation > is needed per attachment point) and has couple of 1000 users using this > - and then they will come and complain to the RIR of choice that they > could not get sufficient address space to do this. I want to address the assertion that assigning /64 prefixes from a /48 would cause up to 65k routes being propagated in the IGP. Using the WLAN-GW model documented in "unique-ipv6-prefix-per-host", the WLAN-GW only needs to advertise the /48 in the IGP and not the individual /64s. Instead, the /64s would be maintained in the FIB of the WLAN-GW and do not need to be synchronized among all routers that participate in the IGP. Thanks - Fred fred.l.templin@boeing.com > Please spell out clearly that using this technology is not RIR-sanctioned > and will not entitle them to a single extra IPv6 subnet. >=20 > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? >=20 > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culema= nn > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Thu Jan 7 08:15:08 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B16D01A9074 for ; Thu, 7 Jan 2016 08:15:06 -0800 (PST) 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 oBIEw0SmKul1 for ; Thu, 7 Jan 2016 08:15:04 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3BED1A9072 for ; Thu, 7 Jan 2016 08:15:03 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id f206so131348787wmf.0 for ; Thu, 07 Jan 2016 08:15:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=jkTgyQFNN688FLAcY2sc4rq22JKTraNcW8DIsvAO9OQ=; b=ldLUtGSxWbXhtj1/1Luj6a6JipzNOdawcvqsrKB3Z046R1B75doVD0GFCoIJ5gFjFB QcVkwH9EnDNwbsjmwHfFybgb6B/BPXvQC8vJSEG4CXDHPWgc+KroxqoVOLK0We+ezffZ 5tv4ywdeQxJBZ3JRiNbCp5pBeLsnlOFA9SKz+SGjVm0TqJMaRs1JngKcBSnGMYShq6o9 yOnUf9ZwMjN1GnA8MJYKIN3ZEa8lGKSBHklwHxhi9iEbTCFKvjfs2zH812kKI/OhgZvD VK67/FEwgoyB+hGWbxErxvVvC9EZ9FhsnThZCpOerjE+9/UC27xULG5t6vbPTk14T3CQ GizA== X-Received: by 10.194.9.98 with SMTP id y2mr53690160wja.105.1452183302375; Thu, 07 Jan 2016 08:15:02 -0800 (PST) Received: from ?IPv6:2001:420:4804:1252:8559:b44c:22f0:80ad? ([2001:420:4804:1252:8559:b44c:22f0:80ad]) by smtp.gmail.com with ESMTPSA id df10sm86926137wjb.44.2016.01.07.08.15.00 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 07 Jan 2016 08:15:01 -0800 (PST) From: Andrew Yourtchenko Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <14610834-893D-4225-87BD-2C026580ED46@gmail.com> Date: Thu, 7 Jan 2016 17:15:00 +0100 To: v6ops list Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) X-Mailer: Apple Mail (2.3096.5) Archived-At: Subject: [v6ops] Review of draft-gont-v6ops-ipv6-ehs-packet-drops-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 16:15:06 -0000 Hello all, Below go my notes from reading the = https://www.ietf.org/id/draft-gont-v6ops-ipv6-ehs-packet-drops-01.txt Overall: The document is easy to read. Most of my comments are nits and = suggestions of additional content that I thought might be on-topic. My only bigger question mark is about the last part of section 5 - = covered in more detail in the last comment below. Page 1: "Discussions about the security and operational implications of IPv6 extension headers are a regular feature in IETF working groups and other places. Often in these discussions, important security and operational issues are overlooked. This document tries to raise awareness about the security and operational implications of IPv6 Extension Headers, and presents reasons why some networks drop packets containing IPv6 Extension Headers." =3D=3D> First paragraph reads to me like it makes a rather broad = assertion. I=E2=80=99d rephrase it from the authors=E2=80=99 viewpoint, = something along the lines of: =E2=80=9CThe authors had been involved in numerous discussions about = the IPv6 extension headers: both within IETF and outside of it. They = noticed that a number of security and operational issues were unknown to = the larger audience participating in these discussions. This document = aims to correct this by presenting these issues - so as to explain how = some networks might choose their policy towards the packets containing = IPv6 Extension Headers=E2=80=9D.=20 (the reason for =E2=80=9Ctheir policy=E2=80=9D vs. just =E2=80=9Cdrop=E2=80= =9D is section 5 presents the consequences of dropping, and the way I = read it - implicitly advocates against it). Page 2: Evasion of security controls =3D=3D> Pure L3 ACLs are not affected by EH parsing, are they ? If they = aren=E2=80=99t - putting a qualifier =E2=80=9Csecurity controls aiming = at layers above the network layer=E2=80=9D or something of that kind = could be useful.=20 Page 3: =E2=80=9CThis has presented implementation difficulties, and packet filtering mechanisms on several security devices can be trivially evaded by inserting IPv6 Extension Headers between the main IPv6 header and the upper layer protocol.=E2=80=9D =3D=3D> =E2=80=9Cpacket filtering mechanisms based protocol data above = the network layer=E2=80=9D (the same idea as previous comment - qualify = that pure L3 filtering is not affected if it isn=E2=80=99t. To expose my idea behind these two comments:=20 L4 ACL is an operationally useful and convenient layer violation. In = IPv4 it was reliable and easy and in IPv6 it isn=E2=80=99t. This is a pretty bad feature disparity between the two protocols. But = one can imagine an alternative IPv6-only universe where unikernel-run = apps simply would not have their OS support for any other ports than the = ones they use, thus making the L4 ACLs on intermediate nodes less = relevant. Back on planet Earth, as implemented in iron, IPv6 L3 ACLs do = work and with IPv6 L4 ACLs you can=E2=80=99t be sure - unless you drop = EHs - thus, network architect, beware. Page 4: "4.1.3. ECMP and Hash-based Load-Sharing" =3D=3D> A naive question pops up in the mind while reading this = paragraph - =E2=80=9Cbut, the flow label=E2=80=A6=E2=80=9D - RFC6438 has = nice words on the subject. Not sure if it=E2=80=99s worth it dragging = the flow label here though. Up to you.. "(e.g. Tertiary CAM or RLDRAM)" =3D=3D> I=E2=80=99ve only heard "Ternary CAM" as an established term. = Tertiary is also harder to pronounce. Page 6: "4.2 Route-Processor Protection" =3D=3D> There=E2=80=99s RFC6192 talking about protecting control plane = with ready made examples of L3 and L4 ACLs for two vendors - it might be = useful to reference that. That would make this section talk about the = ACLs, which might also make it worth reordering 4.1.x, e.g.: 4.1.4 then = 4.1.3 then 4.1.1 then 4.1.2 - this way it flows from =E2=80=98how the = hardware performs lookups=E2=80=99 to =E2=80=98some of the lookups = being done=E2=80=99 to =E2=80=98Why we need L4 ACLs=E2=80=99 - and thus = 4.2 would logically glue with the end of 4.1. "Communication between any two systems through to public network" =3D=3D> seems like extraneous =E2=80=9Cto=E2=80=9D here=20 Page 8: [I-D.ietf-6man-deprecate-atomfrag-generation] has recently proposed to deprecate the generation of IPv6 atomic fragments, and update SIIT [RFC6145] such that it does not rely on ICMPv6 atomic fragments. Thus, any of the above mitigations would eliminate the attack vector without any interoperability implications. =3D=3D> I see several issues here: 1. Glancing through deprecate-atomfrag, seems there is a circular = dependency of sorts: ehs-packet-drops document says the blackhole exists = because the atomic fragments are generated/used, and the = deprecate-atomfrag says the problem exists because the atomic fragments = are dropped. My understanding is that the dependency is that first the = EHs are blocked by the network operator(s) for reasons unrelated to = atomic fragments, which creates the blackhole preventable by not sending = atomic fragments while continuing to block the EHs. 2. Really a comment for deprecate-atomfrag, but given the presence of = this paragraph and its wording, I=E2=80=99ll bring it up here: = http://www.arkko.com/tools/allstats/citations-rfc6145.html shows quite a = graph of dependencies that will be shaken upon a 6145 update. I didn=E2=80= =99t go through the list to see if there are protocol dependencies (4rd = and MAP-T come to mind but maybe something else ?) - but a document = proposing changing 6145 and asserting that there will be no = interoperability implications needs to ensure that none of the = dependencies get out of whack. 3. SIIT and friends can appear in different topologies, with some of the = topologies being affected differently from the others, e.g. with MAP-T = the atomic fragments are not ever leaving the service provider network, = so the generation, filtering and processing is within the same admin = domain. The difference in the impact might affect the policy decisions. So I=E2=80=99d probably rephrase and have the paragraph say that full = analysis is being done as part of deprecate-atomfrag, or something of = sorts - or delete it all together. Not sure. So take it FWIW. I=E2=80=99ll= need to carefully read the deprecate-atomfrag document to get a clearer = opinion about the interaction of these two documents. That=E2=80=99s it, HTH! =E2=80=94a From nobody Thu Jan 7 08:16:52 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E88881A9039 for ; Thu, 7 Jan 2016 08:16:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 GD5RalUX1uE4 for ; Thu, 7 Jan 2016 08:16:49 -0800 (PST) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23DFC1A9080 for ; Thu, 7 Jan 2016 08:16:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u07GGIAt018415; Thu, 7 Jan 2016 08:16:18 -0800 Received: from XCH-BLV-102.nw.nos.boeing.com (xch-blv-102.nw.nos.boeing.com [130.247.25.117]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u07GGGXf018402 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 7 Jan 2016 08:16:16 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.52]) by XCH-BLV-102.nw.nos.boeing.com ([169.254.2.41]) with mapi id 14.03.0235.001; Thu, 7 Jan 2016 08:16:10 -0800 From: "Templin, Fred L" To: "VAN DE VELDE, Gunter (Nokia - BE)" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org" Thread-Topic: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host Thread-Index: AQHRRrIFI13RUsgT4kOKL/Th7Sw3uJ7vFi6A///VyTCAAW6RgP//3BOwgACOkQD//3qM8A== Date: Thu, 7 Jan 2016 16:16:09 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F9BD05@XCH-BLV-504.nw.nos.boeing.com> References: <201601031900.u03J0LMe009763@irp-lnx1.cisco.com> <2134F8430051B64F815C691A62D9831832F9ADDE@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F9BC14@XCH-BLV-504.nw.nos.boeing.com> <7B3ACA5B-FB06-45B6-BE6E-B2D1FB26C0B9@alcatel-lucent.com> In-Reply-To: <7B3ACA5B-FB06-45B6-BE6E-B2D1FB26C0B9@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 16:16:51 -0000 U28sIGFyZSB5b3Ugc2F5aW5nIHRoZXJlIGlzIGFuIGV4cGxvaXRhYmxlIHZ1bG5lcmFiaWxpdHkg aW4gdjQgY29tbXVuaXR5IFdpRmkgdGhhdA0KY2FycmllcyBmb3J3YXJkIGludG8gdjY/DQoNClRo YW5rcyAtIEZyZWQNCmZyZWQubC50ZW1wbGluQGJvZWluZy5jb20NCg0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBWQU4gREUgVkVMREUsIEd1bnRlciAoTm9raWEgLSBCRSkg W21haWx0bzpndW50ZXIudmFuX2RlX3ZlbGRlQGFsY2F0ZWwtbHVjZW50LmNvbV0NCj4gU2VudDog VGh1cnNkYXksIEphbnVhcnkgMDcsIDIwMTYgODoxMyBBTQ0KPiBUbzogVGVtcGxpbiwgRnJlZCBM OyBkcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdEB0b29scy5pZXRm Lm9yZw0KPiBDYzogdjZvcHNAaWV0Zi5vcmcgV0cNCj4gU3ViamVjdDogUmU6IFt2Nm9wc10gRm9j dXNlZCBkaXNjdXNzaW9uOiBkcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXIt aG9zdA0KPiANCj4gSGkgRnJlZCwNCj4gDQo+IFRoaXMgc2VlbXMgbm8gZGlmZmVyZW50IGFzIHdp dGggdjQgdGVjaG5vbG9neSBhdCBjb21tdW5pdHkgV2ktRmnigKYNCj4gDQo+IEcvDQo+IA0KPiAN Cj4gDQo+IE9uIDA3LzAxLzE2IDE2OjQ3LCAiVGVtcGxpbiwgRnJlZCBMIiA8RnJlZC5MLlRlbXBs aW5AYm9laW5nLmNvbT4gd3JvdGU6DQo+IA0KPiA+SGkgR3VudGVyLA0KPiA+DQo+ID5PSywgc28g eW91IGFyZSBzYXlpbmcgdGhhdCB0aGUgTUFDIGFkZHJlc3Mgb2YgdGhlIFVFIGlzIHVzZWQgYXMg dGhlIFVFIGlkZW50aWZpZXIuDQo+ID5CdXQsIGJvdGggbGluay1sb2NhbCBhbmQgTUFDIGFkZHJl c3NlcyBjYW4gYmUgcmVhZGlseSBzcG9vZmVkIGJ5IGFuIGF0dGFja2VyLA0KPiA+ZWl0aGVyIHRv IHN0ZWFsIHRoZSBzZXJ2aWNlIG9mIHRoZSBsZWdpdGltYXRlIG5vZGUgb3IgdG8gZGVueSBzZXJ2 aWNlIHRvIHRoZQ0KPiA+bGVnaXRpbWF0ZSBub2RlLiBJbiBvcmRlciB0byBhdm9pZCB0aGF0LCB0 aGUgVUUgd291bGQgaGF2ZSB0byBoYXZlIHNvbWUgZm9ybQ0KPiA+b2YgaWRlbnRpZmllciB0aGF0 IGNhbm5vdCBiZSBzcG9vZmVkLCBvciBzaWduIGl0cyBtZXNzYWdlcyB1c2luZyBhIGNlcnRpZmlj YXRlDQo+ID5wcm92aXNpb25lZCBieSB0aGUgc2VydmljZSBwcm92aWRlciAtIGV2ZW4gdGhvdWdo IGNhcHRpdmUgcG9ydGFsIGlzIGJlaW5nDQo+ID51c2VkIHRvIGF1dGhlbnRpY2F0ZSB0aGUgdXNl ci4NCj4gPg0KPiA+VGhhbmtzIC0gRnJlZA0KPiA+ZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbQ0K PiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IFZBTiBERSBW RUxERSwgR3VudGVyIChHdW50ZXIpIFttYWlsdG86Z3VudGVyLnZhbl9kZV92ZWxkZUBhbGNhdGVs LWx1Y2VudC5jb21dDQo+ID4+IFNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDA3LCAyMDE2IDE6NTEg QU0NCj4gPj4gVG86IFRlbXBsaW4sIEZyZWQgTDsgZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2 Ni1wcmVmaXgtcGVyLWhvc3RAdG9vbHMuaWV0Zi5vcmcNCj4gPj4gQ2M6IHY2b3BzQGlldGYub3Jn IFdHDQo+ID4+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIEZvY3VzZWQgZGlzY3Vzc2lvbjogZHJhZnQt aWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QNCj4gPj4NCj4gPj4NCj4gPj4g SGkgRnJlZCwNCj4gPj4NCj4gPj4NCj4gPj4gVGhlIFdMQU4tR1cgc2hvdWxkIG5vdCBjYXJlIGFi b3V0IG92ZXJsYXAgaGVyZSwgdGhlcmUgaXMgYSBzcGxpdCBob3Jpem9uIGZ1bmN0aW9uIGFuZCB0 aGUgd2xhbi1ndyBzaG91bGQgYmUgYWJsZSB0byBoYW5kbGUNCj4gPj4gb3ZlcmxhcHBpbmcgSVBz LiBMaW5rLWxvY2FsIGFkZHJlc3MgbWF5IGJlIHN0b3JlZCB0byBlLmcuIHVzZSB3aGVuIHNlbmRp bmcgUkEsIGJ1dCBpdCBzaG91bGQgbm90IGJlIHVzZWQgYXMgYSBrZXksIHRoYXQgaXMgdGhlIHJv bGUgb2YNCj4gPj4gdGhlIE1BQyBhZGRyZXNzLiBTbyBhcyBsb25nIGFzIE1BQyBhZGRyZXNzZXMg ZG9uJ3Qgb3ZlcmxhcCB0aGVyZSBzaG91bGQgbm90IGJlIGEgcHJvYmxlbSBkaXN0aW5ndWlzaGlu ZyBVRXMuDQo+ID4+DQo+ID4+DQo+ID4+IFRoYXQgYmVpbmcgc2FpZCwgaXQgd291bGQgYmUgdW5s aWtlbHkgdG8gaGFwcGVuIHNpbmNlIGxpbmstbG9jYWwgYWRkcmVzc2VzIGluIGEgV2lGaSBjb250 ZXh0IGFyZSBtb3N0bHkgRVVJLTY0IGJhc2VkIGFuZCB0aHVzIGVuY29kZQ0KPiA+PiB0aGUgTUFD IGFkZHJlc3Mgd2hpY2ggYXMgc3RhdGVkIHNob3VsZCBiZSB1bmlxdWUuDQo+ID4+DQo+ID4+IEtp bmQgUmVnYXJkcywNCj4gPj4gRy8NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4N Cj4gPj4gT24gMDYvMDEvMTYgMjE6MDEsICJUZW1wbGluLCBGcmVkIEwiIDxGcmVkLkwuVGVtcGxp bkBib2VpbmcuY29tPiB3cm90ZToNCj4gPj4NCj4gPj4gPkkgaGF2ZSB3aGF0IEkgaG9wZSB3aWxs IGJlIGEgc2ltcGxlIHF1ZXN0aW9uOiB3aGF0IGlmIHR3byBvciBtb3JlIFVFcyBjb25maWd1cmUN Cj4gPj4gPmlkZW50aWNhbCBJUHY2IGxpbmstbG9jYWwgYWRkcmVzc2VzIC0gd2lsbCB0aGUgV0xB Ti1HVyBiZSBhYmxlIHRvIHRlbGwgdGhlbSBhcGFydD8NCj4gPj4gPkFza2VkIGFub3RoZXIgd2F5 LCB3aGF0IGtpbmQgb2YgdW5pcXVlIG5vZGUgaWRlbnRpZmllciBkb2VzIHRoZSBXTEFOLUdXDQo+ ID4+ID5leHBlY3QgZWFjaCBVRSB0byBwcm92aWRlIGluIHRoZSBpbml0aWFsIFJTPw0KPiA+PiA+ DQo+ID4+ID5UaGFua3MgLSBGcmVkDQo+ID4+ID5mcmVkLmwudGVtcGxpbkBib2VpbmcuY29tDQo= From nobody Thu Jan 7 08:19:57 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7E71A9041 for ; Thu, 7 Jan 2016 08:19:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 76PfVGEhMN7w for ; Thu, 7 Jan 2016 08:19:53 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 930E01A9039 for ; Thu, 7 Jan 2016 08:19:53 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 433D660AC7 for ; Thu, 7 Jan 2016 17:19:51 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id E2052600FD for ; Thu, 7 Jan 2016 17:19:50 +0100 (CET) Received: (qmail 71302 invoked by uid 1007); 7 Jan 2016 17:19:50 +0100 Date: Thu, 7 Jan 2016 17:19:50 +0100 From: Gert Doering To: "Templin, Fred L" Message-ID: <20160107161950.GG58491@Space.Net> References: <568D8C1C.2020406@umn.edu> <20160107073826.GC58491@Space.Net> <20160107075820.GE58491@Space.Net> <2134F8430051B64F815C691A62D9831832F9BCDF@XCH-BLV-504.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="x8vlSvlJno7Io+at" Content-Disposition: inline In-Reply-To: <2134F8430051B64F815C691A62D9831832F9BCDF@XCH-BLV-504.nw.nos.boeing.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 16:19:55 -0000 --x8vlSvlJno7Io+at Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Jan 07, 2016 at 04:13:54PM +0000, Templin, Fred L wrote: > I want to address the assertion that assigning /64 prefixes from a /48 > would cause up to 65k routes being propagated in the IGP. Using the > WLAN-GW model documented in "unique-ipv6-prefix-per-host", the > WLAN-GW only needs to advertise the /48 in the IGP and not the > individual /64s. Instead, the /64s would be maintained in the FIB > of the WLAN-GW and do not need to be synchronized among all > routers that participate in the IGP. That assumes that the WLAN-GW owns the /48. It doesn't. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --x8vlSvlJno7Io+at Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVo6QJt9WwGXkzn/FAQLiYxAAi1krBrG8I8bB4aYBqgrHqR6/krq8VW6b vPlbvaghLeVf4nJwo1mOPcunQoDzd5SA4ojP7mZaH5k2OKOyTbbbjDCleI7Eq+q6 PIGlpXUmoLadP+yfBwS9DiSH01oi7DPYKnpqQfUI+c/Tzv5eBZymJs1yBU585eph /rZf3Tz/YOkv491IfFGpmDRvTunauV1hQXeEGmYhmID9/TZ4oUCsrg7sGp04jfRa XmjtGy0PSSkJKAL9vIZLFI026zVkSZcCSSzCCuNL1hhbMagbx09mh64ZsUuGnPV2 wYD6TYX6Nh1qHH1HQu+IUeExZqRW5qqMpUBHQfdWQ1l3tKh/KliQFDefelbTM/sW mntmxu+ra6hWmzIBpTkgBZZXGFFWGqiooOwrv+d9pdLydACS9S4RlDnHy229ISsN /makbowzQB8AMF26vFBwZi4BhFLQXHNkW0lSwv4hd9Nkk3nnufgDKMspTFMjE0VL JfzQpBrrAsqBaOrdKJT9BZE+RaPcgaf9k96RQQ94NroG2uc6EFmi1W2eiaWi+yAY cX1G7caMX4UoWnEHoxmdz/UM6p8lJm+b6Sljhrv1IPyw5QKRgI7qpSo6mXyQy8Rp bExwsfz91QW40pEBDMGaDdFnmIvzxDNn6sq4R88kyClFZXdn+y/V4qySI8dxJlKY FrQBVwM2xNA= =73xM -----END PGP SIGNATURE----- --x8vlSvlJno7Io+at-- From nobody Thu Jan 7 08:27:39 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 945861A904C for ; Thu, 7 Jan 2016 08:27:37 -0800 (PST) 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, 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 WcCA_Gk8wZGb for ; Thu, 7 Jan 2016 08:27:36 -0800 (PST) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4458C1A8967 for ; Thu, 7 Jan 2016 08:27:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u07GRZJ1027281; Thu, 7 Jan 2016 09:27:35 -0700 Received: from XCH-BLV-404.nw.nos.boeing.com (xch-blv-404.nw.nos.boeing.com [130.247.25.157]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u07GRT65026844 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 7 Jan 2016 09:27:30 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.52]) by XCH-BLV-404.nw.nos.boeing.com ([169.254.4.69]) with mapi id 14.03.0235.001; Thu, 7 Jan 2016 08:27:29 -0800 From: "Templin, Fred L" To: Gert Doering Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt Thread-Index: AQHRSWhNeptW/wNPHUKOF07aJBw2og== Date: Thu, 7 Jan 2016 16:27:28 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F9BD71@XCH-BLV-504.nw.nos.boeing.com> References: <568D8C1C.2020406@umn.edu> <20160107073826.GC58491@Space.Net> <20160107075820.GE58491@Space.Net> <2134F8430051B64F815C691A62D9831832F9BCDF@XCH-BLV-504.nw.nos.boeing.com> <20160107161950.GG58491@Space.Net> In-Reply-To: <20160107161950.GG58491@Space.Net> 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: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 16:27:37 -0000 Hi Gert, > -----Original Message----- > From: Gert Doering [mailto:gert@Space.Net] > Sent: Thursday, January 07, 2016 8:20 AM > To: Templin, Fred L > Cc: Gert Doering; Lorenzo Colitti; v6ops@ietf.org > Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-= 04.txt >=20 > Hi, >=20 > On Thu, Jan 07, 2016 at 04:13:54PM +0000, Templin, Fred L wrote: > > I want to address the assertion that assigning /64 prefixes from a /48 > > would cause up to 65k routes being propagated in the IGP. Using the > > WLAN-GW model documented in "unique-ipv6-prefix-per-host", the > > WLAN-GW only needs to advertise the /48 in the IGP and not the > > individual /64s. Instead, the /64s would be maintained in the FIB > > of the WLAN-GW and do not need to be synchronized among all > > routers that participate in the IGP. >=20 > That assumes that the WLAN-GW owns the /48. >=20 > It doesn't. The /48 is owned by the "site", and advertised into the global IPv6 BGP routing system by site border BGP routers. Within the site, the /48 can be provisioned to the WLAN-GW through the advertisement of a single /48 that gets populated through the IGP and eventually all paths lead to the WLAN-GW. From there, the /64s show up only in the FIB of the WLAN-GW. That's really all there is to it. Thanks - Fred fred.l.templin@boeing.com > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? >=20 > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culema= nn > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Thu Jan 7 08:29:24 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F841A9088 for ; Thu, 7 Jan 2016 08:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id icxHvt11I_Se for ; Thu, 7 Jan 2016 08:29:21 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B8231A9035 for ; Thu, 7 Jan 2016 08:29:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2530; q=dns/txt; s=iport; t=1452184152; x=1453393752; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=s0bpsG0HtxiWEa9s1sv9bnQcTpML6DhKTJ9DYpxRmv0=; b=RVO+Nb/soSg9DXwwUQ9g5Wcq/8izI6UWHYreqHf3qx7+34RGNE6wwhkH VnPFxTAmECbbee/cEW1xC6zlH5wmuB+70XO1s/pJ/9OzGfnLw55n/gZ1j yI4XHAszlqmJSV9aHy+2P/ZAVVt8CfDZB4cSf3Q6FhnaueDD3C5vk/prr M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CuBACqkY5W/xbLJq1ehAxtBohTtUcYC?= =?us-ascii?q?oVtAhyBUQEBAQEBAYELhDUBAQQBAQEgEToLEAIBCBgCAh8HAgICHwYLFRACBAE?= =?us-ascii?q?NBYgaAxIOsUGNcA2CaAEBAQEBAQEBAQEBAQEBAQEBAQEBARQEgQGFVQGEfoJPg?= =?us-ascii?q?gYYgwaBSQEElwsBi12BeI57hnCHXAFkghYXHYFAcoRZgQgBAQE?= X-IronPort-AV: E=Sophos;i="5.20,533,1444694400"; d="scan'208";a="623311462" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jan 2016 16:29:10 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u07GT9Pa015212 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Jan 2016 16:29:09 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 7 Jan 2016 11:29:08 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Thu, 7 Jan 2016 11:29:08 -0500 From: "Eric Vyncke (evyncke)" To: Alexandre Petrescu , Gert Doering Thread-Topic: [v6ops] Routers are hosts too! (Re: I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt) Thread-Index: AQHRSMitV7fnMhmxM0KqvFEotlF1cZ7vWaSAgAD5mICAAADKgIAACaMAgAABK4CAAAFwAIAAQ8yA Date: Thu, 7 Jan 2016 16:29:08 +0000 Message-ID: References: <568D8B33.1060301@isi.edu> <568E5C93.5050201@gmail.com> <20160107124237.GP58491@Space.Net> <568E6552.9030008@gmail.com> <20160107132117.GV58491@Space.Net> <568E6782.1000205@gmail.com> In-Reply-To: <568E6782.1000205@gmail.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.56.4] Content-Type: text/plain; charset="utf-8" Content-ID: <8A5935CFF34C7E45B63246266BADC6D5@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Routers are hosts too! (Re: I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 16:29:23 -0000 SGV1Li4gVGhlIGRpc2N1c3Npb24gaXMgd2hldGhlciByb3V0ZXJzIGFyZSBhbHNvIGhvc3RzIGFu ZCBOT1Qgb24gd2hldGhlcg0KaG9zdHMgYXJlIHJvdXRlcnMuLi4NCg0KQW5kIGluIHRoZSBzYW1l IHZlaW4sIHJvdXRlcnMgRE8gbGlzdGVuIHRvIFJBIGFuZCBkbyBESENQIGFzIGNsaWVudCAoZm9y DQpleGFtcGxlIHdoZW4gdGhleSBhcmUgYSByZXNpZGVudGlhbCBDUEUpDQoNCi3DqXJpYw0KDQpP biA3LzAxLzE2IDE0OjI2LCAidjZvcHMgb24gYmVoYWxmIG9mIEFsZXhhbmRyZSBQZXRyZXNjdSIN Cjx2Nm9wcy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBhbGV4YW5kcmUucGV0cmVzY3VA Z21haWwuY29tPiB3cm90ZToNCg0KPg0KPg0KPkxlIDA3LzAxLzIwMTYgMTQ6MjEsIEdlcnQgRG9l cmluZyBhIMOpY3JpdCA6DQo+PiBIaSwNCj4+DQo+PiBPbiBUaHUsIEphbiAwNywgMjAxNiBhdCAw MjoxNzowNlBNICswMTAwLCBBbGV4YW5kcmUgUGV0cmVzY3Ugd3JvdGU6DQo+Pj4gTGUgMDcvMDEv MjAxNiAxMzo0MiwgR2VydCBEb2VyaW5nIGEgw6ljcml0IDoNCj4+Pj4gT24gVGh1LCBKYW4gMDcs IDIwMTYgYXQgMDE6Mzk6NDdQTSArMDEwMCwgQWxleGFuZHJlIFBldHJlc2N1DQo+Pj4+IHdyb3Rl Og0KPj4+Pj4gLSBhIHJvdXRlciBkb2VzIGltcGxlbWVudCBsb25nZXN0LW1hdGNoaW5nIGFsZ29y aXRobXMsIGEgSG9zdA0KPj4+Pj4gZG9lc24ndC4NCj4+Pj4NCj4+Pj4gT2YgY291cnNlIGhvc3Rz IGRvLiAgV2h5IHdvdWxkIGFueSBpbXBsZW1lbnRvciBub3QgZG8gdGhhdD8NCj4+Pg0KPj4+IFdo eSB3b3VsZCBhIEhvc3QgbmVlZCB0byBsb29rIG91dCBhIG5leHRob3AgaW4gcm91dGluZyB0YWJs ZT8gIFRvDQo+Pj4gZm9yd2FyZCB0byB3aG9tPw0KPj4NCj4+IFdlbGwsIGl0IG5lZWRzIHRvIHNl bmQgaXRzIG93biBwYWNrZXRzIHNvbWV3aGVyZSwgbm8/DQo+DQo+WUVzLCB0byBpdHMgcm91dGVy LiAgVGhlcmUncyBvbmx5IG9uZSAtIHRoZSBkZWZhdWx0LiAgVGhlcmUgYXJlIG5vDQo+bmVpZ2hi b3JzIHRvIGRpc3Rpbmd1aXNoIGZyb20uDQo+DQo+PiBBbmQgZ3Vlc3Mgd2hhdCwgdGhpcyBpcyBk b25lIHVzaW5nIHRoZSBub3JtYWwgcm91dGluZyB0YWJsZQ0KPg0KPlllcywgdGhlICdub3JtYWwn IHJvdXRpbmcgdGFibGUgYmVjYXVzZSB0aGF0J3Mgd2hhdCB3ZSdyZSB1c2VkIHdpdGgNCj5zaW5j ZSBsaW51eCBhbmQgRXRoZXJuZXQuDQo+DQo+QnV0IGEgSG9zdCB1c2luZyBzZXJpYWwgdG8gY29u bmVjdCB0byBhIHJvdXRlciAoZS5nLiBhIFVFKSBkb2VzIG5vdCBuZWVkDQo+YSByb3V0aW5nIHRh YmxlLg0KPg0KPj4gd2hpY2ggKGlmDQo+PiB5b3Ugc2V0IGlwLmZvcndhcmRpbmc9MSkgbWFnaWNh bGx5IHR1cm5zIGludG8gYSBmb3J3YXJkaW5nIHRhYmxlLg0KPj4NCj4+IEhvc3RzIGNhbiBoYXZl IG1vcmUgdGhhbiBvbmUgaW50ZXJmYWNlLCBsaWtlICJhIExBTiBpbnRlcmZhY2UgYW5kIGENCj4+ IFZQTiB0dW5uZWwgaW50ZXJmYWNlIi4gIEl0IHJlYWxseSBoZWxwcyBpZiB0aGV5IGtub3cgd2hp Y2ggcGFja2V0DQo+PiBnb2VzIHdoZXJlLg0KPg0KPllFcywgYnV0IHRoZXNlIGFyZSBub3QgcHVy ZSBIb3N0cy4gIFRoZXkgYXJlIG1vcmUgbGlrZSBkZXNrdG9wIFBDcyBhbmQNCj5zbWFydHBob25l cy4NCj4NCj5BbGV4DQo+DQo+Pg0KPj4gR2VydCBEb2VyaW5nIC0tIE5ldE1hc3Rlcg0KPj4NCj4N Cj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPnY2b3Bz IG1haWxpbmcgbGlzdA0KPnY2b3BzQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby92Nm9wcw0KDQo= From nobody Thu Jan 7 08:32:47 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE93C1A9032 for ; Thu, 7 Jan 2016 08:32:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-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 ckmwqpQJIrnQ for ; Thu, 7 Jan 2016 08:32:45 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9AE01A8954 for ; Thu, 7 Jan 2016 08:32:44 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 5043860AB5 for ; Thu, 7 Jan 2016 17:32:43 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 12719600FD for ; Thu, 7 Jan 2016 17:32:43 +0100 (CET) Received: (qmail 72139 invoked by uid 1007); 7 Jan 2016 17:32:43 +0100 Date: Thu, 7 Jan 2016 17:32:43 +0100 From: Gert Doering To: "Templin, Fred L" Message-ID: <20160107163242.GH58491@Space.Net> References: <568D8C1C.2020406@umn.edu> <20160107073826.GC58491@Space.Net> <20160107075820.GE58491@Space.Net> <2134F8430051B64F815C691A62D9831832F9BCDF@XCH-BLV-504.nw.nos.boeing.com> <20160107161950.GG58491@Space.Net> <2134F8430051B64F815C691A62D9831832F9BD71@XCH-BLV-504.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kiXVRbKD0rNQpRT/" Content-Disposition: inline In-Reply-To: <2134F8430051B64F815C691A62D9831832F9BD71@XCH-BLV-504.nw.nos.boeing.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 16:32:46 -0000 --kiXVRbKD0rNQpRT/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Jan 07, 2016 at 04:27:28PM +0000, Templin, Fred L wrote: > > On Thu, Jan 07, 2016 at 04:13:54PM +0000, Templin, Fred L wrote: > > > I want to address the assertion that assigning /64 prefixes from a /48 > > > would cause up to 65k routes being propagated in the IGP. Using the > > > WLAN-GW model documented in "unique-ipv6-prefix-per-host", the > > > WLAN-GW only needs to advertise the /48 in the IGP and not the > > > individual /64s. Instead, the /64s would be maintained in the FIB > > > of the WLAN-GW and do not need to be synchronized among all > > > routers that participate in the IGP. > >=20 > > That assumes that the WLAN-GW owns the /48. > >=20 > > It doesn't. >=20 > The /48 is owned by the "site", and advertised into the global IPv6 BGP > routing system by site border BGP routers. Within the site, the /48 can > be provisioned to the WLAN-GW through the advertisement of a single > /48 that gets populated through the IGP and eventually all paths lead > to the WLAN-GW. From there, the /64s show up only in the FIB of the > WLAN-GW. That's really all there is to it. I do understand aggregation, thanks :-) - but people will and do choose different aggregation points in their networks than "the single WLAN-GW". Like, they might have two. Or three. Or a somewhat structured network. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --kiXVRbKD0rNQpRT/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVo6TKt9WwGXkzn/FAQL6rw//VTKGRDm4mnH+u84urf28QwosbwHsjQvf 65AF6CfVqWlv91g/b2WeLduFZdSdzlK0XAoytCaEr73HqnDzb5On6iHOWXzeFA7o PQwRVSAhHt7UPjb1CjkOiS0m1g70+kDXFUTeWw3x2PyheK9DPUdggpA+G6+3AP+H NAH3t/bOkShiM8lz8pRt4wR7nS8B5OvZrZ2xCc1lHq0XW910hgaA0balXfvPqKPE ljRj3Q+OiH4hmheVqg495uYkH/Y0g0SDMfF4iDZlEuZ0IsHP8qaaOYEXoP242H3m PD4kkrqV02fjuJBDxmgLYrMPnLNlZX+9yQlK6PKk4JiZG1LA7omcpR/7Shaqnnyd htK2ThB4+KNF23tzdkWOS7H7a+0qRBA+J2bmCiIuq7MnGY1iQWx+PsFWDwuDVm9T UuOqAccSvSRrwErtJO8lLkvRAQOezu7XnQlVqg4NmVLwspFZYwKUNdOj2ardXQV9 N6tN2DH29N8W5xSu9mdNHOBaOi+pjTejDqHjzxvPdpZGRe/IuzHKqgnYja3CxqLC vQNZ6/F8UQpKvQBD6bgiLP7PBOgXwCtPeuyRSLlyZbatQeelhmE5SXekP7nq3qBg Rmm70FcNWYxy1jrGIPPXfPmymBy2hZcJd0zfMvJRc+vngTtaUSn6u0eMRZBQlYEd +sM96t53P1c= =uyse -----END PGP SIGNATURE----- --kiXVRbKD0rNQpRT/-- From nobody Thu Jan 7 08:40:31 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3E81A90A9 for ; Thu, 7 Jan 2016 08:40:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 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, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] 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 xMhqBwj6Yfn6 for ; Thu, 7 Jan 2016 08:40:28 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 302741A90A8 for ; Thu, 7 Jan 2016 08:40:28 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id u07GeMoN004454; Thu, 7 Jan 2016 16:40:22 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk u07GeMoN004454 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1452184822; bh=t0CbTBfRZWyL8essP0FMZLGzQUA=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=QkqACHJzAuo744z0rhNWLnie073dx+ljw2UGEteQiNOqinAHLUXkdElj+qD2084mu KuExTRV7g9Ha4lEYaF0b/PBZoGj322iXqhUdSsKLA6zz+/+lKlUw/v6EB4t2P90u/f OicYre39tEovO5oOiethI85OmNIWwE4JZ79bLw3I= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id s06GeM3185009764zl ret-id none; Thu, 07 Jan 2016 16:40:22 +0000 Received: from [IPv6:2001:630:d0:ed23:252c:4e6e:b085:62bd] ([IPv6:2001:630:d0:ed23:252c:4e6e:b085:62bd]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id u07GeKeQ002704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jan 2016 16:40:20 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_8FF8C212-AB18-4FEC-929E-A9A0926B1C1B" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Tim Chown In-Reply-To: Date: Thu, 7 Jan 2016 16:40:20 +0000 Message-ID: References: <20160107130750.GT58491@Space.Net> To: Lorenzo Colitti X-Mailer: Apple Mail (2.3112) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=s06GeM318500976400; tid=s06GeM3185009764zl; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=3:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: u07GeMoN004454 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Routers are hosts too! (Re: I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 16:40:30 -0000 --Apple-Mail=_8FF8C212-AB18-4FEC-929E-A9A0926B1C1B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 7 Jan 2016, at 13:13, Lorenzo Colitti wrote: >=20 > On Thu, Jan 7, 2016 at 10:07 PM, Gert Doering > wrote: > So, yes, the code is there - but typically not active on your = travelling > salesman's laptop (and if it were, it would as likely mess up everyone > else's network as ICSs would happily announce Teredo, 6to4 and ISATAP > prefixes everywhere...) >=20 > People do have it turned on. We know because it was a major cause of = IPv6 brokenness in 2011. >=20 > https://en.wikipedia.org/wiki/IPv6_brokenness_and_DNS_whitelisting = >=20 > IIRC the fix was not to disable ICS, but to stop ICS from sending 6to4 = RAs. Happy days. We monitored that over a year and >50% of the time some = Windows host was doing 6to4 like that. Hence the ramond code in advance = of solutions from vendors. Tim --Apple-Mail=_8FF8C212-AB18-4FEC-929E-A9A0926B1C1B Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On 7 Jan 2016, at 13:13, Lorenzo Colitti <lorenzo@google.com> wrote:

On Thu, Jan 7, 2016 at 10:07 PM, Gert Doering <gert@space.net> wrote:
So, yes, the code is there - but typically not active on your travelling
salesman's laptop (and if it were, it would as likely mess up everyone
else's network as ICSs would happily announce Teredo, 6to4 and ISATAP
prefixes everywhere...)

People do have it turned on. We know because it was a major cause of IPv6 brokenness in 2011.


IIRC the fix was not to disable ICS, but to stop ICS from sending 6to4 RAs.

Happy days. We monitored that over a year and >50% of the time some Windows host was doing 6to4 like that.  Hence the ramond code in advance of solutions from vendors.

Tim

--Apple-Mail=_8FF8C212-AB18-4FEC-929E-A9A0926B1C1B-- From nobody Thu Jan 7 08:43:12 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48FE61A9092 for ; Thu, 7 Jan 2016 08:43:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.231 X-Spam-Level: X-Spam-Status: No, score=-1.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] 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 QRMltRrIHGHl for ; Thu, 7 Jan 2016 08:43:06 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03F5E1A90AA for ; Thu, 7 Jan 2016 08:43:05 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id u07GguLx004681; Thu, 7 Jan 2016 16:42:56 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk u07GguLx004681 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1452184977; bh=444E8rRQDE6YqqcQMp1l9paecws=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=bhNuVZCmYb5x5cB///ZEDiG17galNDsoAGQrzC6YhBO47MAxCWttKJI+MPYLZ8yV5 b6SuEaVZsdMMqREWSQxlbGsf7L2cM2owFbDgoEn2wM/oQdnt5wVMKKI7S1ia7FZQEV s8IuoDyq5YMahiEYLV9csBccB747TcZ/HFltPufU= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id s06Ggu3185009779bf ret-id none; Thu, 07 Jan 2016 16:42:57 +0000 Received: from [IPv6:2001:630:d0:ed23:252c:4e6e:b085:62bd] ([IPv6:2001:630:d0:ed23:252c:4e6e:b085:62bd]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id u07GgpE5003139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jan 2016 16:42:51 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Tim Chown In-Reply-To: Date: Thu, 7 Jan 2016 16:42:50 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <568D8B33.1060301@isi.edu> <568E5C93.5050201@gmail.com> <20160107124237.GP58491@Space.Net> <568E6552.9030008@gmail.com> <20160107132117.GV58491@Space.Net> <568E6782.1000205@gmail.com> <2C2E662B-127C-460A-8B40-1A4680B96861@ecs.soton.ac.uk> To: "Eric Vyncke (evyncke)" X-Mailer: Apple Mail (2.3112) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=s06Ggu318500977900; tid=s06Ggu3185009779bf; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=4:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: u07GguLx004681 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Routers are hosts too! (Re: I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 16:43:11 -0000 > On 7 Jan 2016, at 16:29, Eric Vyncke (evyncke) = wrote: >=20 > Heu.. The discussion is whether routers are also hosts and NOT on = whether > hosts are routers... >=20 > And in the same vein, routers DO listen to RA and do DHCP as client = (for > example when they are a residential CPE) So where does the ICS model sit with this? Would the =E2=80=9Chost=E2=80=9D providing the ICS function then serve = (or relay) DHCP-PD requests from =E2=80=9Chosts=E2=80=9D behind it? Tim >=20 > -=C3=A9ric >=20 > On 7/01/16 14:26, "v6ops on behalf of Alexandre Petrescu" > = wrote: >=20 >>=20 >>=20 >> Le 07/01/2016 14:21, Gert Doering a =C3=A9crit : >>> Hi, >>>=20 >>> On Thu, Jan 07, 2016 at 02:17:06PM +0100, Alexandre Petrescu wrote: >>>> Le 07/01/2016 13:42, Gert Doering a =C3=A9crit : >>>>> On Thu, Jan 07, 2016 at 01:39:47PM +0100, Alexandre Petrescu >>>>> wrote: >>>>>> - a router does implement longest-matching algorithms, a Host >>>>>> doesn't. >>>>>=20 >>>>> Of course hosts do. Why would any implementor not do that? >>>>=20 >>>> Why would a Host need to look out a nexthop in routing table? To >>>> forward to whom? >>>=20 >>> Well, it needs to send its own packets somewhere, no? >>=20 >> YEs, to its router. There's only one - the default. There are no >> neighbors to distinguish from. >>=20 >>> And guess what, this is done using the normal routing table >>=20 >> Yes, the 'normal' routing table because that's what we're used with >> since linux and Ethernet. >>=20 >> But a Host using serial to connect to a router (e.g. a UE) does not = need >> a routing table. >>=20 >>> which (if >>> you set ip.forwarding=3D1) magically turns into a forwarding table. >>>=20 >>> Hosts can have more than one interface, like "a LAN interface and a >>> VPN tunnel interface". It really helps if they know which packet >>> goes where. >>=20 >> YEs, but these are not pure Hosts. They are more like desktop PCs = and >> smartphones. >>=20 >> Alex >>=20 >>>=20 >>> Gert Doering -- NetMaster >>>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Jan 7 08:45:30 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3941A90B0 for ; Thu, 7 Jan 2016 08:45:23 -0800 (PST) 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, 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 NbpyPOnOIfjt for ; Thu, 7 Jan 2016 08:45:18 -0800 (PST) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B324D1A90B4 for ; Thu, 7 Jan 2016 08:45:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u07GjHUS016325; Thu, 7 Jan 2016 09:45:18 -0700 Received: from XCH-PHX-213.sw.nos.boeing.com (xch-phx-213.sw.nos.boeing.com [130.247.25.142]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u07GjEte016198 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 7 Jan 2016 09:45:15 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.52]) by XCH-PHX-213.sw.nos.boeing.com ([169.254.13.191]) with mapi id 14.03.0235.001; Thu, 7 Jan 2016 08:45:13 -0800 From: "Templin, Fred L" To: Gert Doering Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt Thread-Index: AQHRSWhNeptW/wNPHUKOF07aJBw2op7wxVyA//96B/A= Date: Thu, 7 Jan 2016 16:45:13 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F9BE32@XCH-BLV-504.nw.nos.boeing.com> References: <568D8C1C.2020406@umn.edu> <20160107073826.GC58491@Space.Net> <20160107075820.GE58491@Space.Net> <2134F8430051B64F815C691A62D9831832F9BCDF@XCH-BLV-504.nw.nos.boeing.com> <20160107161950.GG58491@Space.Net> <2134F8430051B64F815C691A62D9831832F9BD71@XCH-BLV-504.nw.nos.boeing.com> <20160107163242.GH58491@Space.Net> In-Reply-To: <20160107163242.GH58491@Space.Net> 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: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 16:45:23 -0000 Hi Gert, > -----Original Message----- > From: Gert Doering [mailto:gert@Space.Net] > Sent: Thursday, January 07, 2016 8:33 AM > To: Templin, Fred L > Cc: Gert Doering; Lorenzo Colitti; v6ops@ietf.org > Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-= 04.txt >=20 > Hi, >=20 > On Thu, Jan 07, 2016 at 04:27:28PM +0000, Templin, Fred L wrote: > > > On Thu, Jan 07, 2016 at 04:13:54PM +0000, Templin, Fred L wrote: > > > > I want to address the assertion that assigning /64 prefixes from a = /48 > > > > would cause up to 65k routes being propagated in the IGP. Using the > > > > WLAN-GW model documented in "unique-ipv6-prefix-per-host", the > > > > WLAN-GW only needs to advertise the /48 in the IGP and not the > > > > individual /64s. Instead, the /64s would be maintained in the FIB > > > > of the WLAN-GW and do not need to be synchronized among all > > > > routers that participate in the IGP. > > > > > > That assumes that the WLAN-GW owns the /48. > > > > > > It doesn't. > > > > The /48 is owned by the "site", and advertised into the global IPv6 BGP > > routing system by site border BGP routers. Within the site, the /48 can > > be provisioned to the WLAN-GW through the advertisement of a single > > /48 that gets populated through the IGP and eventually all paths lead > > to the WLAN-GW. From there, the /64s show up only in the FIB of the > > WLAN-GW. That's really all there is to it. >=20 > I do understand aggregation, thanks :-) - but people will and do choose > different aggregation points in their networks than "the single WLAN-GW". >=20 > Like, they might have two. Or three. Or hundreds or thousands. > Or a somewhat structured network. AERO explains how this all works. Let's say we had hundreds or thousands of WLAN-GWs and we wanted to network them. Have the WLAN-GWs participate in a private BGP instance that *does* carry all /64 prefixes. When a UE associates with a WLAN-GW, the WLAN-GW injects the UE's /64 into the BGP routing instance. When the UE disassociates with the WLAN-GW, the WLAN-GW withdraws the /64. If the UE pops up at a different WLAN-GW, that new WLAN-GW then injects the route into the BGP routing system. You may worry that this would require all WLAN-GWs to peer with all other WLAN-GWs, but that is not necessary if we introduce a new architectural construct - call lit a WLAN-RELAY. There might be a few 10s of those, and each WLAN-RELAY peers with all WLAN-GWs. So, the WLAN-RELAYS discover all /64 prefix assignments and which WLAN-GW the prefix is currently assigned to. The WLAN-GWs then only need to know about their current working set of /64s, and set default routes to one or more WLAN-RELAYs. The WLAN-RELAYs then advertise the /48 into the IGP or (if the WLAN-RELAYs are also site border routers) into the global Internet BGP routing system. Yes, this means that the WLAN-RELAYs would need to carry up to 65K /64s in the private BGP routing instance. But, we know from experience that public Internet BGP routers can carry hundreds of thousands of routes - maybe even as many as a million. It works, and it scales - this is also explained in AERO. Thanks - Fred fred.l.templin@boeing.com > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? >=20 > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culema= nn > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Thu Jan 7 08:56:50 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC2E71A90CA for ; Thu, 7 Jan 2016 08:56:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 thKVjl8t8YnD for ; Thu, 7 Jan 2016 08:56:48 -0800 (PST) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AE3C1A90C8 for ; Thu, 7 Jan 2016 08:56:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u07Guq5i001085; Thu, 7 Jan 2016 08:56:52 -0800 Received: from XCH-BLV-306.nw.nos.boeing.com (xch-blv-306.nw.nos.boeing.com [130.247.25.218]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u07Gukjt001015 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 7 Jan 2016 08:56:46 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.52]) by XCH-BLV-306.nw.nos.boeing.com ([169.254.6.160]) with mapi id 14.03.0235.001; Thu, 7 Jan 2016 08:56:40 -0800 From: "Templin, Fred L" To: "VAN DE VELDE, Gunter (Nokia - BE)" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org" Thread-Topic: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host Thread-Index: AQHRRrIFI13RUsgT4kOKL/Th7Sw3uJ7vFi6A///VyTCAAW6RgP//3BOwgACOkQD//3qM8AARiNiAABB1ZDA= Date: Thu, 7 Jan 2016 16:56:39 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F9BF23@XCH-BLV-504.nw.nos.boeing.com> References: <201601031900.u03J0LMe009763@irp-lnx1.cisco.com> <2134F8430051B64F815C691A62D9831832F9ADDE@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F9BC14@XCH-BLV-504.nw.nos.boeing.com> <7B3ACA5B-FB06-45B6-BE6E-B2D1FB26C0B9@alcatel-lucent.com> <2134F8430051B64F815C691A62D9831832F9BD05@XCH-BLV-504.nw.nos.boeing.com> <2D68058C-981F-4037-80C4-AFF88D8A2997@alcatel-lucent.com> In-Reply-To: <2D68058C-981F-4037-80C4-AFF88D8A2997@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 16:56:49 -0000 SGkgR3VudGVyLA0KDQpNYXliZSBJIGFtIG5vdCB1bmRlcnN0YW5kaW5nIHlvdSBjb3JyZWN0bHku IFRoZXJlIG1heSBiZSBtYW55IEFQcyAoMTAwJ3MsIDEwMDAncywgZXRjLikNCmFzc29jaWF0ZWQg d2l0aCBhIHNpbmdsZSBXTEFOLUdXIC0gY29ycmVjdD8gQXQgZWFjaCBBUCwgYSBVRSBwcmVzZW50 cyBpdHNlbGYgdXNpbmcgaXRzDQpNQUMgYWRkcmVzcyBhbmQgaW5pdGlhbGx5IHNlbmRzIG91dCBh biBSUyB1c2luZyBhbiBJUHY2IGxpbmstbG9jYWwgYWRkcmVzcyBtb3N0IGxpa2VseQ0KZGVyaXZl ZCBmcm9tIHRoZSBNQUMgYWRkcmVzcy4gVGhlIEFQIChhY3RpbmcgaW4gYnJpZGdlIG1vZGUpIHRo ZW4gZm9yd2FyZHMgdGhlDQpSUyB0byB0aGUgV0xBTi1HVyB3aGljaCBuZWVkcyB0byBoYXZlIHNv bWUgd2F5IG9mIGtub3dpbmcgdGhhdCB0aGUgUlMgY2FtZQ0KZnJvbSBhbiBhdXRoZW50aWMgc291 cmNlLiAoWW91IGhhdmUgc2FpZCB0aGF0IHRoZSBNQUMgYWRkcmVzcyBpcyB0aGUgaWRlbnRpZmll ciBmb3INCnRoZSBVRSAtIGJ1dCwgZG9lcyB0aGUgV0xBTi1HVyBzZWUgdGhlIE1BQyBhZGRyZXNz LCBvciBkb2VzIGl0IG9ubHkgc2VlIHRoZQ0KbGluay1sb2NhbCBhZGRyZXNzPykNCg0KTm93LCBj b25zaWRlciBhIFVFICdBJyBhc3NvY2lhdGVkIHdpdGggQVAgJ1gnIGFuZCBhIFVFICdCJyBhc3Nv Y2lhdGVkIHdpdGggQVAgJ1knLg0KQSBpcyB0aGUgYXV0aGVudGljIG93bmVyIG9mIE1BQyBhZGRy ZXNzICdNJy4gV2hlbiBBIGFzc29jaWF0ZXMgd2l0aCBYLCB0aGUNCldMQU4tR1cgZ29lcyB0aHJv dWdoIHRoZSBhdXRoZW50aWNhdGlvbiBwcm9jZWR1cmVzIGJhc2VkIG9uIHRoZSBNQUMNCmFkZHJl c3MgTSAob3IgdGhlIElQdjYgbGluay1sb2NhbCBhZGRyZXNzIGFzc29jaWF0ZWQgd2l0aCBNQUMg YWRkcmVzcyBNKS4NCkJ1dCBub3csIEIgYXNzb2NpYXRlcyB3aXRoIFkgYW5kIGFsc28gdXNlcyBN QUMgYWRkcmVzcyBNLiAoT3IsIG1heWJlIEINCmFzc29jaWF0ZXMgd2l0aCBZIGJlZm9yZSBBIGFz c29jaWF0ZXMgd2l0aCBYLikgV2hhdCBpcyB0byBzdG9wIEIgZnJvbSBzcG9vZmluZw0KdGhlIE1B QyBhZGRyZXNzIGluIHRoaXMgd2F5IGFuZCBEb1MnaW5nIEE/DQoNClRoYW5rcyAtIEZyZWQNCmZy ZWQubC50ZW1wbGluQGJvZWluZy5jb20NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiBGcm9tOiBWQU4gREUgVkVMREUsIEd1bnRlciAoTm9raWEgLSBCRSkgW21haWx0bzpndW50ZXIu dmFuX2RlX3ZlbGRlQGFsY2F0ZWwtbHVjZW50LmNvbV0NCj4gU2VudDogVGh1cnNkYXksIEphbnVh cnkgMDcsIDIwMTYgODozNyBBTQ0KPiBUbzogVGVtcGxpbiwgRnJlZCBMOyBkcmFmdC1pZXRmLXY2 b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdEB0b29scy5pZXRmLm9yZw0KPiBDYzogdjZv cHNAaWV0Zi5vcmcgV0cNCj4gU3ViamVjdDogUmU6IFt2Nm9wc10gRm9jdXNlZCBkaXNjdXNzaW9u OiBkcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdA0KPiANCj4gDQo+ IA0KPiBJIGFtIHNheWluZyB0aGF0IHRoZXJlIGlzIG5vIGRpZmZlcmVuY2UgYmV0d2VlbiB2NCBh bmQgdjYgYmVoYXZpb3VyIG9uIGEgV2lGaSAob3IgZXZlbiBtb3N0IG90aGVyIEwyIG5ldHdvcmsg dHlwZeKAmXMpIG5ldHdvcmsgd2hlbg0KPiBNQUMgYWRkcmVzcyBjbGFzaC4gSXQgaXMgbm90IGEg bmV3IHByb2JsZW0gYW5kIHNhbWUgdGVjaG5pcXVlcyB1c2VkIGluIHY0IGNhbiBiZSB1c2VkIGlu IHRoZSB2NiByZWFsbS4gQ2xlYXJseSB3aGVuIHR3byBkZXZpY2VzDQo+IGhhdmUgdGhlIHNhbWUg TUFDIGFkZHJlc3Mgb24gdGhlIHNhbWUgTDIgbmV0d29yayBzb21ldGhpbmcgaXMgZ29vZmVkIHVw Lg0KPiANCj4gDQo+IEcvDQo+IA0KPiANCj4gDQo+IDA3LzAxLzE2IDE3OjE2LCAiVGVtcGxpbiwg RnJlZCBMIiA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4gd3JvdGU6DQo+IA0KPiA+U28sIGFy ZSB5b3Ugc2F5aW5nIHRoZXJlIGlzIGFuIGV4cGxvaXRhYmxlIHZ1bG5lcmFiaWxpdHkgaW4gdjQg Y29tbXVuaXR5IFdpRmkgdGhhdA0KPiA+Y2FycmllcyBmb3J3YXJkIGludG8gdjY/DQo+ID4NCj4g PlRoYW5rcyAtIEZyZWQNCj4gPmZyZWQubC50ZW1wbGluQGJvZWluZy5jb20NCj4gPg0KPiA+PiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBWQU4gREUgVkVMREUsIEd1bnRl ciAoTm9raWEgLSBCRSkgW21haWx0bzpndW50ZXIudmFuX2RlX3ZlbGRlQGFsY2F0ZWwtbHVjZW50 LmNvbV0NCj4gPj4gU2VudDogVGh1cnNkYXksIEphbnVhcnkgMDcsIDIwMTYgODoxMyBBTQ0KPiA+ PiBUbzogVGVtcGxpbiwgRnJlZCBMOyBkcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZp eC1wZXItaG9zdEB0b29scy5pZXRmLm9yZw0KPiA+PiBDYzogdjZvcHNAaWV0Zi5vcmcgV0cNCj4g Pj4gU3ViamVjdDogUmU6IFt2Nm9wc10gRm9jdXNlZCBkaXNjdXNzaW9uOiBkcmFmdC1pZXRmLXY2 b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdA0KPiA+Pg0KPiA+PiBIaSBGcmVkLA0KPiA+ Pg0KPiA+PiBUaGlzIHNlZW1zIG5vIGRpZmZlcmVudCBhcyB3aXRoIHY0IHRlY2hub2xvZ3kgYXQg Y29tbXVuaXR5IFdpLUZp4oCmDQo+ID4+DQo+ID4+IEcvDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+ IE9uIDA3LzAxLzE2IDE2OjQ3LCAiVGVtcGxpbiwgRnJlZCBMIiA8RnJlZC5MLlRlbXBsaW5AYm9l aW5nLmNvbT4gd3JvdGU6DQo+ID4+DQo+ID4+ID5IaSBHdW50ZXIsDQo+ID4+ID4NCj4gPj4gPk9L LCBzbyB5b3UgYXJlIHNheWluZyB0aGF0IHRoZSBNQUMgYWRkcmVzcyBvZiB0aGUgVUUgaXMgdXNl ZCBhcyB0aGUgVUUgaWRlbnRpZmllci4NCj4gPj4gPkJ1dCwgYm90aCBsaW5rLWxvY2FsIGFuZCBN QUMgYWRkcmVzc2VzIGNhbiBiZSByZWFkaWx5IHNwb29mZWQgYnkgYW4gYXR0YWNrZXIsDQo+ID4+ ID5laXRoZXIgdG8gc3RlYWwgdGhlIHNlcnZpY2Ugb2YgdGhlIGxlZ2l0aW1hdGUgbm9kZSBvciB0 byBkZW55IHNlcnZpY2UgdG8gdGhlDQo+ID4+ID5sZWdpdGltYXRlIG5vZGUuIEluIG9yZGVyIHRv IGF2b2lkIHRoYXQsIHRoZSBVRSB3b3VsZCBoYXZlIHRvIGhhdmUgc29tZSBmb3JtDQo+ID4+ID5v ZiBpZGVudGlmaWVyIHRoYXQgY2Fubm90IGJlIHNwb29mZWQsIG9yIHNpZ24gaXRzIG1lc3NhZ2Vz IHVzaW5nIGEgY2VydGlmaWNhdGUNCj4gPj4gPnByb3Zpc2lvbmVkIGJ5IHRoZSBzZXJ2aWNlIHBy b3ZpZGVyIC0gZXZlbiB0aG91Z2ggY2FwdGl2ZSBwb3J0YWwgaXMgYmVpbmcNCj4gPj4gPnVzZWQg dG8gYXV0aGVudGljYXRlIHRoZSB1c2VyLg0KPiA+PiA+DQo+ID4+ID5UaGFua3MgLSBGcmVkDQo+ ID4+ID5mcmVkLmwudGVtcGxpbkBib2VpbmcuY29tDQo+ID4+ID4NCj4gPj4gPj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gPj4gRnJvbTogVkFOIERFIFZFTERFLCBHdW50ZXIgKEd1 bnRlcikgW21haWx0bzpndW50ZXIudmFuX2RlX3ZlbGRlQGFsY2F0ZWwtbHVjZW50LmNvbV0NCj4g Pj4gPj4gU2VudDogVGh1cnNkYXksIEphbnVhcnkgMDcsIDIwMTYgMTo1MSBBTQ0KPiA+PiA+PiBU bzogVGVtcGxpbiwgRnJlZCBMOyBkcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1w ZXItaG9zdEB0b29scy5pZXRmLm9yZw0KPiA+PiA+PiBDYzogdjZvcHNAaWV0Zi5vcmcgV0cNCj4g Pj4gPj4gU3ViamVjdDogUmU6IFt2Nm9wc10gRm9jdXNlZCBkaXNjdXNzaW9uOiBkcmFmdC1pZXRm LXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdA0KPiA+PiA+Pg0KPiA+PiA+Pg0KPiA+ PiA+PiBIaSBGcmVkLA0KPiA+PiA+Pg0KPiA+PiA+Pg0KPiA+PiA+PiBUaGUgV0xBTi1HVyBzaG91 bGQgbm90IGNhcmUgYWJvdXQgb3ZlcmxhcCBoZXJlLCB0aGVyZSBpcyBhIHNwbGl0IGhvcml6b24g ZnVuY3Rpb24gYW5kIHRoZSB3bGFuLWd3IHNob3VsZCBiZSBhYmxlIHRvIGhhbmRsZQ0KPiA+PiA+ PiBvdmVybGFwcGluZyBJUHMuIExpbmstbG9jYWwgYWRkcmVzcyBtYXkgYmUgc3RvcmVkIHRvIGUu Zy4gdXNlIHdoZW4gc2VuZGluZyBSQSwgYnV0IGl0IHNob3VsZCBub3QgYmUgdXNlZCBhcyBhIGtl eSwgdGhhdCBpcyB0aGUNCj4gcm9sZSBvZg0KPiA+PiA+PiB0aGUgTUFDIGFkZHJlc3MuIFNvIGFz IGxvbmcgYXMgTUFDIGFkZHJlc3NlcyBkb24ndCBvdmVybGFwIHRoZXJlIHNob3VsZCBub3QgYmUg YSBwcm9ibGVtIGRpc3Rpbmd1aXNoaW5nIFVFcy4NCj4gPj4gPj4NCj4gPj4gPj4NCj4gPj4gPj4g VGhhdCBiZWluZyBzYWlkLCBpdCB3b3VsZCBiZSB1bmxpa2VseSB0byBoYXBwZW4gc2luY2UgbGlu ay1sb2NhbCBhZGRyZXNzZXMgaW4gYSBXaUZpIGNvbnRleHQgYXJlIG1vc3RseSBFVUktNjQgYmFz ZWQgYW5kIHRodXMNCj4gZW5jb2RlDQo+ID4+ID4+IHRoZSBNQUMgYWRkcmVzcyB3aGljaCBhcyBz dGF0ZWQgc2hvdWxkIGJlIHVuaXF1ZS4NCj4gPj4gPj4NCj4gPj4gPj4gS2luZCBSZWdhcmRzLA0K PiA+PiA+PiBHLw0KPiA+PiA+Pg0KPiA+PiA+Pg0KPiA+PiA+Pg0KPiA+PiA+Pg0KPiA+PiA+Pg0K PiA+PiA+Pg0KPiA+PiA+PiBPbiAwNi8wMS8xNiAyMTowMSwgIlRlbXBsaW4sIEZyZWQgTCIgPEZy ZWQuTC5UZW1wbGluQGJvZWluZy5jb20+IHdyb3RlOg0KPiA+PiA+Pg0KPiA+PiA+PiA+SSBoYXZl IHdoYXQgSSBob3BlIHdpbGwgYmUgYSBzaW1wbGUgcXVlc3Rpb246IHdoYXQgaWYgdHdvIG9yIG1v cmUgVUVzIGNvbmZpZ3VyZQ0KPiA+PiA+PiA+aWRlbnRpY2FsIElQdjYgbGluay1sb2NhbCBhZGRy ZXNzZXMgLSB3aWxsIHRoZSBXTEFOLUdXIGJlIGFibGUgdG8gdGVsbCB0aGVtIGFwYXJ0Pw0KPiA+ PiA+PiA+QXNrZWQgYW5vdGhlciB3YXksIHdoYXQga2luZCBvZiB1bmlxdWUgbm9kZSBpZGVudGlm aWVyIGRvZXMgdGhlIFdMQU4tR1cNCj4gPj4gPj4gPmV4cGVjdCBlYWNoIFVFIHRvIHByb3ZpZGUg aW4gdGhlIGluaXRpYWwgUlM/DQo+ID4+ID4+ID4NCj4gPj4gPj4gPlRoYW5rcyAtIEZyZWQNCj4g Pj4gPj4gPmZyZWQubC50ZW1wbGluQGJvZWluZy5jb20NCg== From nobody Thu Jan 7 09:01:14 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B57BB1A90D3 for ; Thu, 7 Jan 2016 09:01:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnYbe7qWcJUa for ; Thu, 7 Jan 2016 09:01:11 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 638111A90D1 for ; Thu, 7 Jan 2016 09:01:11 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u07H16Ds004689; Thu, 7 Jan 2016 18:01:06 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 35607204C47; Thu, 7 Jan 2016 18:08:35 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 26CAD204E6D; Thu, 7 Jan 2016 18:08:35 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u07H16N0032599; Thu, 7 Jan 2016 18:01:06 +0100 To: "Eric Vyncke (evyncke)" , Gert Doering References: <568D8B33.1060301@isi.edu> <568E5C93.5050201@gmail.com> <20160107124237.GP58491@Space.Net> <568E6552.9030008@gmail.com> <20160107132117.GV58491@Space.Net> <568E6782.1000205@gmail.com> From: Alexandre Petrescu Message-ID: <568E99D2.9080203@gmail.com> Date: Thu, 7 Jan 2016 18:01:06 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Routers are hosts too! (Re: I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 17:01:13 -0000 Le 07/01/2016 17:29, Eric Vyncke (evyncke) a écrit : > Heu.. The discussion is whether routers are also hosts and NOT on > whether hosts are routers... > > And in the same vein, routers DO listen to RA By spec, they listen to RA just to be informed about other routers, maybe learn if some other router dies out and log the info. But nothing more. For example, they can't SLAAC an address using the prefix received in an RA, they can't set the MTU of the link, they can't decide they have have experienced a handover by computing the difference between the received prefixes, and so on. > and do DHCP as client (for example when they are a residential CPE) I agree with the behaviour. But. Contrary to ND specs the DHCP specs dont talk Host vs Routers. They talk Client vs Server vs Relay. And there is no defined relationship between Router and Servers, for example. One can't say a Server is a Router. As such one couldnt say that a DHCP Client is necessarily a Host. Alex > > -éric > > On 7/01/16 14:26, "v6ops on behalf of Alexandre Petrescu" > > wrote: > >> >> >> Le 07/01/2016 14:21, Gert Doering a écrit : >>> Hi, >>> >>> On Thu, Jan 07, 2016 at 02:17:06PM +0100, Alexandre Petrescu >>> wrote: >>>> Le 07/01/2016 13:42, Gert Doering a écrit : >>>>> On Thu, Jan 07, 2016 at 01:39:47PM +0100, Alexandre Petrescu >>>>> wrote: >>>>>> - a router does implement longest-matching algorithms, a >>>>>> Host doesn't. >>>>> >>>>> Of course hosts do. Why would any implementor not do that? >>>> >>>> Why would a Host need to look out a nexthop in routing table? >>>> To forward to whom? >>> >>> Well, it needs to send its own packets somewhere, no? >> >> YEs, to its router. There's only one - the default. There are no >> neighbors to distinguish from. >> >>> And guess what, this is done using the normal routing table >> >> Yes, the 'normal' routing table because that's what we're used >> with since linux and Ethernet. >> >> But a Host using serial to connect to a router (e.g. a UE) does not >> need a routing table. >> >>> which (if you set ip.forwarding=1) magically turns into a >>> forwarding table. >>> >>> Hosts can have more than one interface, like "a LAN interface and >>> a VPN tunnel interface". It really helps if they know which >>> packet goes where. >> >> YEs, but these are not pure Hosts. They are more like desktop PCs >> and smartphones. >> >> Alex >> >>> >>> Gert Doering -- NetMaster >>> >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Jan 7 09:04:03 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 786091A90D8 for ; Thu, 7 Jan 2016 09:04:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Yvh1-gIRJ_vc for ; Thu, 7 Jan 2016 09:04:00 -0800 (PST) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B63F1A90D4 for ; Thu, 7 Jan 2016 09:04:00 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id p186so107201643qke.0 for ; Thu, 07 Jan 2016 09:04:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=PMdnWZxr0eGIRpdqyFZRKP5dsHjnhUP9fDHDnIHpzQ0=; b=DE0eCZWmPY17YXm5cUBCf3iAtNWht7ISEACi8pUSZE/8mLokRkzN5iw6/XK91zJTvb lpsgWMzssJvkZDet4ud/J8wZkYR2Q3EBgxovw1Embvgn4CDMKVWR05E6npjVXIgjESr/ tRiyktcY4zL9bYIaoXU0mAQ87olOrgCZHPnGOgz0X0xQB1WNowPHNN9nahUvkASigQhO VOv9H4lGVG9YGch0X8ywy0t7T324rTOljI/JyCq1ws8cdGYjL7o2ptZt7SqKpcgYICMY TvmXtjCl18eUZVdLvcYFpq4qf++bAr8RR8hKbjvnVEmwBwYXKN51Meh2q/45lkAyuJw4 qBEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=PMdnWZxr0eGIRpdqyFZRKP5dsHjnhUP9fDHDnIHpzQ0=; b=a4+0h0bDyWzZ6hITGEgGrjBnaCSaU+vPZW6iCDVOuLeUQY8aYbEJpuN4GWOmbePkaC fFYW8bTBUXdy7PsF4xqkK+mZExi+G/kkJ30t+g1LiOP23gL7Q2Ijrk/2hqUCSvPL1kUY MPBODJ9Gz3bzuNynh/nqMoaUIEOQMq01zmIpR/RWej/6COHSqAZc0E3Sc3RS7yogpOrP kQtGok0YuaJxij68HUsI9lTMBx5D8SFzkwV6IcHDPCkALsAKGEbQOB/Du5Aew0zfvTMm LPxwwihRFagB8j5VuN9YPQKOgbkeY/b62uubakcpfNNOn8TXhVhxjRwRkgNXXaF5SEmF 6VOg== X-Gm-Message-State: ALoCoQnSbbyYUMy1D8LebztzSWLxQXCBgRTS/bMLHJYeBpFAhwbk61UhdPKjiXLf48aigPLhpibIhXMAEjPFmIUVvpS+himJZHnVD6yqUjmBkoSL8udH27k= X-Received: by 10.129.136.196 with SMTP id y187mr76704214ywf.307.1452186239335; Thu, 07 Jan 2016 09:03:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.208.201 with HTTP; Thu, 7 Jan 2016 09:03:39 -0800 (PST) In-Reply-To: <568E99D2.9080203@gmail.com> References: <568D8B33.1060301@isi.edu> <568E5C93.5050201@gmail.com> <20160107124237.GP58491@Space.Net> <568E6552.9030008@gmail.com> <20160107132117.GV58491@Space.Net> <568E6782.1000205@gmail.com> <568E99D2.9080203@gmail.com> From: Lorenzo Colitti Date: Fri, 8 Jan 2016 02:03:39 +0900 Message-ID: To: Alexandre Petrescu Content-Type: multipart/alternative; boundary=001a114f38b4f1d2e00528c174c5 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Routers are hosts too! (Re: I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 17:04:01 -0000 --001a114f38b4f1d2e00528c174c5 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 8, 2016 at 2:01 AM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > And in the same vein, routers DO listen to RA >> > > By spec, they listen to RA just to be informed about other routers, > maybe learn if some other router dies out and log the info. But nothing > more. > Yes, well. Since RFC 2460 was written, they have evolved to do quite a bit more. For example, see the CPE router document (RFC 7084). Those send RSes, listen to RA, use SLAAC, etc. --001a114f38b4f1d2e00528c174c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jan 8, 2016 at 2:01 AM, Alexandre Petrescu <alexandre.petre= scu@gmail.com> wrote:
And in the same vein, routers DO listen to RA

By spec, they listen to RA just to be informed about other routers,
maybe learn if some other router dies out and log the info.=C2=A0 But nothi= ng
more.

Yes, well. Since RFC 2460 was wri= tten, they have evolved to do quite a bit more. For example, see the CPE ro= uter document (RFC 7084). Those send RSes, listen to RA, use SLAAC, etc.
--001a114f38b4f1d2e00528c174c5-- From nobody Thu Jan 7 09:35:07 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9EB1A9110 for ; Thu, 7 Jan 2016 09:35:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 IXsV1Wv3ynsg for ; Thu, 7 Jan 2016 09:35:03 -0800 (PST) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9C5E1A910E for ; Thu, 7 Jan 2016 09:35:03 -0800 (PST) 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 u07HZ2vQ026204; Thu, 7 Jan 2016 11:35:02 -0600 Received: from XCH-BLV-306.nw.nos.boeing.com (xch-blv-306.nw.nos.boeing.com [130.247.25.218]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u07HYwTX026083 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 7 Jan 2016 11:34:59 -0600 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.52]) by XCH-BLV-306.nw.nos.boeing.com ([169.254.6.160]) with mapi id 14.03.0235.001; Thu, 7 Jan 2016 09:34:58 -0800 From: "Templin, Fred L" To: "VAN DE VELDE, Gunter (Nokia - BE)" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org" Thread-Topic: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host Thread-Index: AQHRRrIFI13RUsgT4kOKL/Th7Sw3uJ7vFi6A///VyTCAAW6RgP//3BOwgACOkQD//3qM8AARiNiAABB1ZDD//4agAIAAgaTQ Date: Thu, 7 Jan 2016 17:34:57 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F9BFED@XCH-BLV-504.nw.nos.boeing.com> References: <201601031900.u03J0LMe009763@irp-lnx1.cisco.com> <2134F8430051B64F815C691A62D9831832F9ADDE@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F9BC14@XCH-BLV-504.nw.nos.boeing.com> <7B3ACA5B-FB06-45B6-BE6E-B2D1FB26C0B9@alcatel-lucent.com> <2134F8430051B64F815C691A62D9831832F9BD05@XCH-BLV-504.nw.nos.boeing.com> <2D68058C-981F-4037-80C4-AFF88D8A2997@alcatel-lucent.com> <2134F8430051B64F815C691A62D9831832F9BF23@XCH-BLV-504.nw.nos.boeing.com> <33FC69DB-7389-4AA3-B1D0-DC1016C134DD@alcatel-lucent.com> In-Reply-To: <33FC69DB-7389-4AA3-B1D0-DC1016C134DD@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 17:35:05 -0000 SGkgR3VudGVyLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFZBTiBE RSBWRUxERSwgR3VudGVyIChOb2tpYSAtIEJFKSBbbWFpbHRvOmd1bnRlci52YW5fZGVfdmVsZGVA YWxjYXRlbC1sdWNlbnQuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgSmFudWFyeSAwNywgMjAxNiA5 OjE0IEFNDQo+IFRvOiBUZW1wbGluLCBGcmVkIEw7IGRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlw djYtcHJlZml4LXBlci1ob3N0QHRvb2xzLmlldGYub3JnDQo+IENjOiB2Nm9wc0BpZXRmLm9yZyBX Rw0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBGb2N1c2VkIGRpc2N1c3Npb246IGRyYWZ0LWlldGYt djZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0DQo+IA0KPiANCj4gDQo+IA0KPiANCj4g DQo+IE9uIDA3LzAxLzE2IDE3OjU2LCAiVGVtcGxpbiwgRnJlZCBMIiA8RnJlZC5MLlRlbXBsaW5A Ym9laW5nLmNvbT4gd3JvdGU6DQo+IA0KPiA+SGkgR3VudGVyLA0KPiA+DQo+ID5NYXliZSBJIGFt IG5vdCB1bmRlcnN0YW5kaW5nIHlvdSBjb3JyZWN0bHkuIFRoZXJlIG1heSBiZSBtYW55IEFQcyAo MTAwJ3MsIDEwMDAncywgZXRjLikNCj4gPmFzc29jaWF0ZWQgd2l0aCBhIHNpbmdsZSBXTEFOLUdX IC0gY29ycmVjdD8NCj4gDQo+IEdWPiBZZXAsIHRoZXJlIGNhbiBiZSBpbmRlZWQuIEkgc3RhcnQg dG8gc2VlIHdoZXJlIHRoZSBjb25mdXNpb24gY2FtZSBmcm9tLg0KDQpNQUMgYWRkcmVzcyBzcG9v ZmluZyBpcyBNQUMgYWRkcmVzcyBzcG9vZmluZyAtIHdoZXRoZXIgdGhlcmUgaXMgMSBBUCBvciAx MDAwLA0KYW5kIHdoZXRoZXIgdGhlcmUgaXMgbW9iaWxpdHkgb3Igbm8gbW9iaWxpdHkuIEkgZG9u J3QgdGhpbmsgdGhlcmUgaXMgYW55IGNvbmZ1c2lvbi4NCldoZXJlIEkgYW0gdHJ5aW5nIHRvIHVu ZGVyc3RhbmQgaXMgd2hldGhlciBjb21wbGV0ZWx5IHVubW9kaWZpZWQgYW5kIENPVFMNClVFcyBj YW4gYmUgdXNlZCB3aXRob3V0IHRoZXJlIGJlaW5nIGEgZGFuZ2VyIG9mIE1BQyBhZGRyZXNzIHNw b29maW5nIERvUywNCm9yIHdoZXRoZXIgdGhlIFVFcyBuZWVkIHRvIGJlIGVucm9sbGVkIGluIHRo ZSBzZXJ2aWNlIG9mZmVyZWQgYnkgdGhlDQpjb21tdW5pdHkgV2lGaSBwcm92aWRlci4gQnkgImVu cm9sbGVkIiwgSSBtZWFuIGVudGVyZWQgaW50byB0aGUgcHJvdmlkZXIncw0KUEtJIGFuZCBnaXZl biBhIGNlcnQsIG9yIHNvbWV0aGluZyBsaWtlIHRoYXQuDQoNClRoYW5rcyAtIEZyZWQNCmZyZWQu bC50ZW1wbGluQGJvZWluZy5jb20NCg0KPiA+QXQgZWFjaCBBUCwgYSBVRSBwcmVzZW50cyBpdHNl bGYgdXNpbmcgaXRzDQo+ID5NQUMgYWRkcmVzcyBhbmQgaW5pdGlhbGx5IHNlbmRzIG91dCBhbiBS UyB1c2luZyBhbiBJUHY2IGxpbmstbG9jYWwgYWRkcmVzcyBtb3N0IGxpa2VseQ0KPiA+ZGVyaXZl ZCBmcm9tIHRoZSBNQUMgYWRkcmVzcy4gVGhlIEFQIChhY3RpbmcgaW4gYnJpZGdlIG1vZGUpIHRo ZW4gZm9yd2FyZHMgdGhlDQo+ID5SUyB0byB0aGUgV0xBTi1HVyB3aGljaCBuZWVkcyB0byBoYXZl IHNvbWUgd2F5IG9mIGtub3dpbmcgdGhhdCB0aGUgUlMgY2FtZQ0KPiA+ZnJvbSBhbiBhdXRoZW50 aWMgc291cmNlLiAoWW91IGhhdmUgc2FpZCB0aGF0IHRoZSBNQUMgYWRkcmVzcyBpcyB0aGUgaWRl bnRpZmllciBmb3INCj4gPnRoZSBVRSAtIGJ1dCwgZG9lcyB0aGUgV0xBTi1HVyBzZWUgdGhlIE1B QyBhZGRyZXNzLCBvciBkb2VzIGl0IG9ubHkgc2VlIHRoZQ0KPiA+bGluay1sb2NhbCBhZGRyZXNz PykNCj4gDQo+IEdWPiBBUCBpcyBicmlkZ2luZyBmcm9tIHdpZmkgdG8gR1JFIHR1bm5lbCwgc28g dGhlIFdMQU4tR1cgc2VlcyBNQUMgYWRkcmVzcyBpbmRlZWQNCj4gDQo+ID4NCj4gPk5vdywgY29u c2lkZXIgYSBVRSAnQScgYXNzb2NpYXRlZCB3aXRoIEFQICdYJyBhbmQgYSBVRSAnQicgYXNzb2Np YXRlZCB3aXRoIEFQICdZJy4NCj4gPkEgaXMgdGhlIGF1dGhlbnRpYyBvd25lciBvZiBNQUMgYWRk cmVzcyAnTScuIFdoZW4gQSBhc3NvY2lhdGVzIHdpdGggWCwgdGhlDQo+ID5XTEFOLUdXIGdvZXMg dGhyb3VnaCB0aGUgYXV0aGVudGljYXRpb24gcHJvY2VkdXJlcyBiYXNlZCBvbiB0aGUgTUFDDQo+ ID5hZGRyZXNzIE0gKG9yIHRoZSBJUHY2IGxpbmstbG9jYWwgYWRkcmVzcyBhc3NvY2lhdGVkIHdp dGggTUFDIGFkZHJlc3MgTSkuDQo+ID5CdXQgbm93LCBCIGFzc29jaWF0ZXMgd2l0aCBZIGFuZCBh bHNvIHVzZXMgTUFDIGFkZHJlc3MgTS4gKE9yLCBtYXliZSBCDQo+ID5hc3NvY2lhdGVzIHdpdGgg WSBiZWZvcmUgQSBhc3NvY2lhdGVzIHdpdGggWC4pIFdoYXQgaXMgdG8gc3RvcCBCIGZyb20gc3Bv b2ZpbmcNCj4gPnRoZSBNQUMgYWRkcmVzcyBpbiB0aGlzIHdheSBhbmQgRG9TJ2luZyBBPw0KPiAN Cj4gR1Y+IGJvdGggQVDigJlzIHVzZSB0aGVpciBvd24gZGlmZmVyZW50IFNvZnRHUkUgdHVubmVs IHRvIHRoZSBXTEFOLUdXLCBhbmQgdGhhdCBpcyBob3cgV0xBTi1HVyBmaW5kcyBvdXQgdGhleSBh cmUgZGlmZmVyZW50DQo+IGJlY2F1c2UgdGhlIHR1bm5lbCBjYW4gYmUgcGFydCBvZiB0aGUga2V5 LiBPZmNvdXJzIFVFIG1vYmlsaXR5IGFuZCBvdGhlciBhZHZhbmNlZCBmZWF0dXJlcyBjYW4gYmUg ZW5hYmxlZCBvbiB0aGUgV0xBTi1HVyB1c2luZw0KPiBhbHRlcm5hdGUgYXV0aGVudGljYXRpb24g bWVjaGFuaXNtcywgYnV0IHRoYXQgaXMgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIHBhcnRpY3Vs YXIgZHJhZnQgYXMgdGhhdCBkcml2ZXMgcHJldHR5IGZhciBpbnRvIHZlbmRvcg0KPiBjYXBhYmls aXR5IHRlcnJpdG9yeSBhbmQgaSBiZWxpZXZlIHRoYXQgaXMgYmV5b25kIHY2b3BzIHNjb3BlLg0K PiANCj4gQmUgd2VsbCwNCj4gRy8NCj4gDQo+ID4NCg== From nobody Thu Jan 7 09:55:32 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECE451A9132 for ; Thu, 7 Jan 2016 09:55:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 OlxfAVk-qerN for ; Thu, 7 Jan 2016 09:55:30 -0800 (PST) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F6E21A9131 for ; Thu, 7 Jan 2016 09:55:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u07HtZpU019507; Thu, 7 Jan 2016 09:55:35 -0800 Received: from XCH-BLV-208.nw.nos.boeing.com (xch-blv-208.nw.nos.boeing.com [10.57.37.5]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u07HtVKw019321 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 7 Jan 2016 09:55:31 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.52]) by XCH-BLV-208.nw.nos.boeing.com ([169.254.8.46]) with mapi id 14.03.0235.001; Thu, 7 Jan 2016 09:55:25 -0800 From: "Templin, Fred L" To: "draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org" Thread-Topic: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host Thread-Index: AQHRRrIFI13RUsgT4kOKL/Th7Sw3uJ7vFi6A///VyTCAAW6RgP//3BOwgACOkQD//3qM8AARiNiAABB1ZDD//4agAIAAgaTQgAEA0zA= Date: Thu, 7 Jan 2016 17:55:24 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F9C052@XCH-BLV-504.nw.nos.boeing.com> References: <201601031900.u03J0LMe009763@irp-lnx1.cisco.com> <2134F8430051B64F815C691A62D9831832F9ADDE@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F9BC14@XCH-BLV-504.nw.nos.boeing.com> <7B3ACA5B-FB06-45B6-BE6E-B2D1FB26C0B9@alcatel-lucent.com> <2134F8430051B64F815C691A62D9831832F9BD05@XCH-BLV-504.nw.nos.boeing.com> <2D68058C-981F-4037-80C4-AFF88D8A2997@alcatel-lucent.com> <2134F8430051B64F815C691A62D9831832F9BF23@XCH-BLV-504.nw.nos.boeing.com> <33FC69DB-7389-4AA3-B1D0-DC1016C134DD@alcatel-lucent.com> <2134F8430051B64F815C691A62D9831832F9BFED@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832F9BFED@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 17:55:32 -0000 UGVvcGxlIGhhdmUgYXNrZWQgYWJvdXQgb3ZlcmxhcCBiZXR3ZWVuIHRoaXMgd29yayBhbmQgQUVS Ty4gVGhlIG92ZXJsYXANCmlzIGluIHRoZSB3YXkgU29mdEdSRSB3b3JrcyBpbiBjb21wYXJpc29u IHdpdGggdGhlIEFFUk8gbGluayBtb2RlbC4gU29mdEdSRQ0KdG8gbXkgdW5kZXJzdGFuZGluZyBp cyBqdXN0IGFub3RoZXIgZXhhbXBsZSBvZiBhIE5vbi1Ccm9hZGNhc3QsIE11bHRpcGxlDQpBY2Nl c3MgKE5CTUEpIHR1bm5lbCB2aXJ0dWFsIG92ZXJsYXkgaW4gZXhhY3RseSB0aGUgc2FtZSBmYXNo aW9uIGFzIGZvciBBRVJPLg0KVGhlIEFQIGlzIGFuYWxvZ291cyB0byB0aGUgQUVSTyBDbGllbnQs IGFuZCB0aGUgV0xBTi1HVyBpcyBhbmFsb2dvdXMgdG8NCnRoZSBBRVJPIFNlcnZlci4gVGhhdCB0 aGUgQVBzIGFyZSBicmlkZ2luZyBpbnN0ZWFkIG9mIHByb3ZpZGluZyBhIHRlcm1pbnVzDQpmb3Ig cHJlZml4IGRlbGVnYXRpb24gaXMgdW5pcXVlIHRvIHRoaXMgd29yaywgYW5kIG5vdCBjb3ZlcmVk IGJ5IEFFUk8uIEJ1dCwNCnRoZSB0dW5uZWwgdmlydHVhbCBsaW5rIG1vZGVsIGlzIG9uZSBhbmQg dGhlIHNhbWUuDQoNClRoYXQgc2FpZCwgQUVSTyBjYW4gYmVuZWZpdCB0aGlzIHdvcmsgdGhyb3Vn aCB0aGUgbWFubmVyIGluIHdoaWNoIG11bHRpcGxlDQpXTEFOLUdXcyBjYW4gYmUgbmV0d29ya2Vk IHRvIGNyZWF0ZSBhIGdsb2JhbCByb3V0aW5nIHN5c3RlbSB0aGF0IGNhbg0Kc3VzdGFpbiBVRS10 by1wcmVmaXggYXNzb2NpYXRpb25zIHdoZXJldmVyIHRoZSBVRXMgaGFwcGVuIHRvIHBvcCB1cCBp bg0KdGhlIGdsb2JhbCBjb21tdW5pdHkgV2lGaSByb3V0aW5nIHN0cnVjdHVyZS4gSXQgY2FuIGJl IGhhbmRsZWQgdGhyb3VnaA0KdGhlIGFkZGl0aW9uIG9mIGEgbmV3IGNvbnN0cnVjdCB3aGljaCBJ IGFtIGNhbGxpbmcgdGhlICJXTEFOLVJFTEFZIiwNCndoaWNoIGlzIGFuYWxvZ291cyB0byB0aGUg QUVSTyBSZWxheSwgYW5kIHRocm91Z2ggdGhlIGludHJvZHVjdGlvbiBvZg0KYSBwcml2YXRlIEJH UCBpbnN0YW5jZSB0aGF0IGtlZXBzIHRyYWNrIG9mIGFsbCBVRS10by1XTEFOLUdXIGFzc29jaWF0 aW9ucy4NCiBJIGV4cGxhaW5lZCBob3cgdGhpcyBhbGwgd29ya3MgaW4gbXkgbWVzc2FnZSB0byBH ZXJ0IHNldmVyYWwgbWVzc2FnZXMgYmFjaywNCmFuZCBJIHdvdWxkIGxpa2UgdG8gb2ZmZXIgdGhp cyBhcyBpbnB1dCB0byB0aGUgYXV0aG9ycyBvZiB0aGlzIGRyYWZ0Og0KDQpodHRwczovL21haWxh cmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3Y2b3BzL2pOMHZBbkhQY2hvYnJIVHAyMnRqUWJGakdO NA0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGVtcGxpbi1hZXJvbGlu ay8NCg0KVGhhbmtzIC0gRnJlZA0KZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbQ0K From nobody Thu Jan 7 10:21:13 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFA4C1A9231 for ; Thu, 7 Jan 2016 10:21:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-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 ck1jikLs6vRD for ; Thu, 7 Jan 2016 10:21:10 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F8C31A9218 for ; Thu, 7 Jan 2016 10:21:10 -0800 (PST) Received: from [128.9.184.104] ([128.9.184.104]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u07IKp66017599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 7 Jan 2016 10:20:53 -0800 (PST) To: Alexandre Petrescu , v6ops@ietf.org References: <568D8B33.1060301@isi.edu> <568E5C93.5050201@gmail.com> From: Joe Touch X-Enigmail-Draft-Status: N1110 Message-ID: <568EAC83.4000102@isi.edu> Date: Thu, 7 Jan 2016 10:20:51 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <568E5C93.5050201@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [v6ops] Routers are hosts too! (Re: I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 18:21:12 -0000 On 1/7/2016 4:39 AM, Alexandre Petrescu wrote: > > > Le 06/01/2016 22:46, Joe Touch a écrit : >> +1 (and then some) >> >> AFAICT: >> >> - a host is an Internet device that sources or sinks packets >> >> - a router is an Internet device that *also* relays packets >> >> It may be possible to implement a router that never acts as a host, but >> that requires it never participate actively in routing protocols, IP >> signalling, etc. > > Yes. And: > > - a router doesn't use the information received in an RA, a > host does. A router might have an interface by which it is accessible as a host but for which it does not forward; that interface could use an RA for autoconfiguration. > - a router doesn't join the all-hosts multicast address. There's an "all nodes", which it clearly should join (see RFC4921, Sec. 2.8). There is no "all-hosts" listed here (except for ST, which is obsoleted): http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml > - a router doesn't use SLAAC to configure an address for self, > a Host does. It could where appropriate (e.g., see first item above). > - a router does implement longest-matching algorithms, a Host > doesn't. This is needed for source address selection if the host has more than one address. > Implementations are obviously less clear cut. But we can talk theory. > > Alex > >> >> Joe >> >> On 1/6/2016 1:24 PM, Mark Smith wrote: >>> Routers are universally hosts too. The distinction between a router and >>> a host is that a router will also accept packets not sent to addresses >>> assigned to the devices interfaces. It will then see what to do with >>> them according to the route table, sending the packet where ever the >>> route table says or dropping them. That is all that makes it a router. >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Jan 7 10:22:46 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC271A9240 for ; Thu, 7 Jan 2016 10:22:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-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 wIgsPFOWFysJ for ; Thu, 7 Jan 2016 10:22:44 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A06E1A923E for ; Thu, 7 Jan 2016 10:22:44 -0800 (PST) Received: from [128.9.184.104] ([128.9.184.104]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u07IMRjv018357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 7 Jan 2016 10:22:28 -0800 (PST) To: Alexandre Petrescu , Gert Doering References: <568D8B33.1060301@isi.edu> <568E5C93.5050201@gmail.com> <20160107124237.GP58491@Space.Net> <568E6552.9030008@gmail.com> From: Joe Touch Message-ID: <568EACE4.2070408@isi.edu> Date: Thu, 7 Jan 2016 10:22:28 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <568E6552.9030008@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Routers are hosts too! (Re: I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 18:22:45 -0000 On 1/7/2016 5:17 AM, Alexandre Petrescu wrote: > > > Le 07/01/2016 13:42, Gert Doering a écrit : >> Hi, >> >> On Thu, Jan 07, 2016 at 01:39:47PM +0100, Alexandre Petrescu wrote: >>> - a router does implement longest-matching algorithms, a Host >>> doesn't. >> >> Of course hosts do. Why would any implementor not do that? > > Why would a Host need to look out a nexthop in routing table? To > forward to whom? Source address selection. See RFC1122 Sec 3.3.4.3. Joe From nobody Thu Jan 7 10:38:58 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007481A92BB for ; Thu, 7 Jan 2016 10:38:57 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 2MA1cyEF10sz for ; Thu, 7 Jan 2016 10:38:55 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B56B1A92B8 for ; Thu, 7 Jan 2016 10:38:55 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id f206so109066989wmf.0 for ; Thu, 07 Jan 2016 10:38:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucd-ie.20150623.gappssmtp.com; s=20150623; h=from:date:message-id:to:cc:subject:in-reply-to:references :user-agent:mime-version:content-type:content-transfer-encoding; bh=zropZHkflsW0LJgSTXT+RRENEj5OwhmziACbUNeSO1U=; b=AI0NzhiL0yH3ZX8rvcgQD2BTJqPynpj4MlI6GbpSFXV6Lp2Uj7cnJDt/MEIfyYexrn cSVzkJZMVLZ3QmUc3PUxI0afhObaJHhmhb1N5WR/PXrzEo6B2OwRSOWHrgZw+ahtizBv cqPoMdY9xDEJhyfqA1hTLat1GWfFnn/hjfV23cDSbqhwt00s7WF9Musm/JBLBykr87AM U9hYRgsDlSHw860Wilor02i5yUp+xDSSDAWI8jV053I+pfroTArvu+JKW++45mA0SLeA 0rZVQsF/AS24mdDnf7GH9PgBxqMNnGwwAm+YSbsu46vA91Pj8TGE8tiXzmq9stX65l+v 6AOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:date:message-id:to:cc:subject:in-reply-to :references:user-agent:mime-version:content-type :content-transfer-encoding; bh=zropZHkflsW0LJgSTXT+RRENEj5OwhmziACbUNeSO1U=; b=aomDMPo1OdgfenlGk4zw74oIox22ouqIYDoeap12uE3ZFZG8cO+SNh3e0e3MZCl9uB RCqmKKsDOmKOvQE1+GacuyYGUWErEheAH/L7tx3/OAP1xcu6gzof4WguMxUm+bMzi8Pb kUmOYpPmz3cNeHFQH6w1gI1EkRHRGDq8Xgu94snq3RjPjkxNvw3iufQ4B22r4OjlM+QQ UBnwkm4l9bOlgKhGMlMSbteVXPAbUU5LA0pEmpvwVa7Ce+Pkjgd9OR3GpLFhKNQ2qACn sOoWrCsTb/6eAu7N3xtIOZZa8NSHfPduebgKH3mVyvZ7zWQkBWm/gIrmaur5SPqZYS5O zkEw== X-Gm-Message-State: ALoCoQkf5QpoWUrmJ/UOJbz8RnyulksWe5mL5cszZ19fU9yS6WgEKvbGbtF6LvTwUh7XOxzrFlDB06Twth/zB+3HhyA0GzAX2g== X-Received: by 10.194.222.135 with SMTP id qm7mr115827993wjc.106.1452191933927; Thu, 07 Jan 2016 10:38:53 -0800 (PST) Received: from 162.1.0.10.in-addr.no8.be.ucd.ie ([2001:770:13f:1:382b:8394:64ec:1bce]) by smtp.gmail.com with ESMTPSA id cs4sm102497664wjc.10.2016.01.07.10.38.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Jan 2016 10:38:53 -0800 (PST) From: "Niall O'Reilly" X-Google-Original-From: Niall O'Reilly Date: Thu, 07 Jan 2016 18:38:51 +0000 Message-ID: To: Alexandre Petrescu In-Reply-To: <568E5C93.5050201@gmail.com> References: <568D8B33.1060301@isi.edu> <568E5C93.5050201@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Routers are hosts too! (Re: I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 18:38:57 -0000 On Thu, 07 Jan 2016 12:39:47 +0000, Alexandre Petrescu wrote: >=20 > - a router doesn't join the all-hosts multicast address. Eh? 162(niall)4: for x in 1 2; do ping6 -c3 -I en1 ff02::$x; done PING6(56=3D40+8+8 bytes) fe80::7a31:c1ff:feec:a2c6%en1 --> ff02::1 16 bytes from fe80::7a31:c1ff:feec:a2c6%en1, icmp_seq=3D0 hlim=3D64 time=3D= 0.141 ms 16 bytes from fe80::d6ca:6dff:fe26:e0dd%en1, icmp_seq=3D0 hlim=3D255 time= =3D3.437 ms 16 bytes from fe80::7a31:c1ff:feec:a2c6%en1, icmp_seq=3D1 hlim=3D64 time=3D= 0.220 ms 16 bytes from fe80::d6ca:6dff:fe26:e0dd%en1, icmp_seq=3D1 hlim=3D255 time= =3D3.411 ms 16 bytes from fe80::7a31:c1ff:feec:a2c6%en1, icmp_seq=3D2 hlim=3D64 time=3D= 0.233 ms --- ff02::1 ping6 statistics --- 3 packets transmitted, 3 packets received, +2 duplicates, 0.0% packet loss round-trip min/avg/max/std-dev =3D 0.141/1.488/3.437/1.581 ms PING6(56=3D40+8+8 bytes) fe80::7a31:c1ff:feec:a2c6%en1 --> ff02::2 16 bytes from fe80::d6ca:6dff:fe26:e0dd%en1, icmp_seq=3D0 hlim=3D255 time= =3D5.611 ms 16 bytes from fe80::d6ca:6dff:fe26:e0dd%en1, icmp_seq=3D1 hlim=3D255 time= =3D2.255 ms 16 bytes from fe80::d6ca:6dff:fe26:e0dd%en1, icmp_seq=3D2 hlim=3D255 time= =3D3.372 ms --- ff02::2 ping6 statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/std-dev =3D 2.255/3.746/5.611/1.395 ms 162(niall)4:=20 From nobody Thu Jan 7 10:45:55 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CECA1A92EA for ; Thu, 7 Jan 2016 10:45:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 QVUujyo2XTsT for ; Thu, 7 Jan 2016 10:45:52 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92B071A92E9 for ; Thu, 7 Jan 2016 10:45:52 -0800 (PST) Received: from mb-2.local ([8.18.217.194]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id u07Ijo23041875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 7 Jan 2016 18:45:50 GMT (envelope-from joelja@bogus.com) To: Joe Touch , Alexandre Petrescu , v6ops@ietf.org References: <568D8B33.1060301@isi.edu> <568E5C93.5050201@gmail.com> <568EAC83.4000102@isi.edu> From: joel jaeggli Message-ID: <568EB25D.8030907@bogus.com> Date: Thu, 7 Jan 2016 10:45:49 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:43.0) Gecko/20100101 Thunderbird/43.0 MIME-Version: 1.0 In-Reply-To: <568EAC83.4000102@isi.edu> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5NxQwi0c7m6JMFaHudcRFjEXdQwU9tKef" Archived-At: Subject: Re: [v6ops] Routers are hosts too! (Re: I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 18:45:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5NxQwi0c7m6JMFaHudcRFjEXdQwU9tKef Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 1/7/16 10:20 AM, Joe Touch wrote: >=20 >=20 > On 1/7/2016 4:39 AM, Alexandre Petrescu wrote: >> >> >> Le 06/01/2016 22:46, Joe Touch a =E9crit : >>> +1 (and then some) >>> >>> AFAICT: >>> >>> - a host is an Internet device that sources or sinks packets >>> >>> - a router is an Internet device that *also* relays packets >>> >>> It may be possible to implement a router that never acts as a host, b= ut >>> that requires it never participate actively in routing protocols, IP >>> signalling, etc. >> >> Yes. And: >> >> - a router doesn't use the information received in an RA, a >> host does. >=20 > A router might have an interface by which it is accessible as a host bu= t > for which it does not forward; that interface could use an RA for > autoconfiguration. >=20 >> - a router doesn't join the all-hosts multicast address. >=20 > There's an "all nodes", which it clearly should join (see RFC4921, Sec.= > 2.8). the platonic conception of a router as a device that simply forwards packets maybe not, the router's control plane on the other hand is a host on every subnet where it's addressed and is therefore a node. > There is no "all-hosts" listed here (except for ST, which is obsoleted)= :=20 > http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast= -addresses.xhtml >=20 >> - a router doesn't use SLAAC to configure an address for self,= >> a Host does. >=20 > It could where appropriate (e.g., see first item above). >=20 >> - a router does implement longest-matching algorithms, a Host >> doesn't. >=20 > This is needed for source address selection if the host has more than > one address. >=20 >> Implementations are obviously less clear cut. But we can talk theory.= >> >> Alex >> >>> >>> Joe >>> >>> On 1/6/2016 1:24 PM, Mark Smith wrote: >>>> Routers are universally hosts too. The distinction between a router = and >>>> a host is that a router will also accept packets not sent to address= es >>>> assigned to the devices interfaces. It will then see what to do with= >>>> them according to the route table, sending the packet where ever the= >>>> route table says or dropping them. That is all that makes it a route= r. >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --5NxQwi0c7m6JMFaHudcRFjEXdQwU9tKef Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEUEARECAAYFAlaOsl0ACgkQ8AA1q7Z/VrKzkgCXdZqHB5qyXDEAWuWBDrJH83bt jACfYUMutGeOVNjgUSvk4PD/+Yap9Gk= =qVYy -----END PGP SIGNATURE----- --5NxQwi0c7m6JMFaHudcRFjEXdQwU9tKef-- From nobody Thu Jan 7 10:55:14 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A63F1A9301 for ; Thu, 7 Jan 2016 10:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 GNaRBRfKj10L for ; Thu, 7 Jan 2016 10:55:10 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D38D1A9300 for ; Thu, 7 Jan 2016 10:55:10 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 0EF6D60A99 for ; Thu, 7 Jan 2016 19:55:08 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id B8D1D602C7 for ; Thu, 7 Jan 2016 19:55:07 +0100 (CET) Received: (qmail 77961 invoked by uid 1007); 7 Jan 2016 19:55:07 +0100 Date: Thu, 7 Jan 2016 19:55:07 +0100 From: Gert Doering To: Niall O'Reilly Message-ID: <20160107185507.GK58491@Space.Net> References: <568D8B33.1060301@isi.edu> <568E5C93.5050201@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Routers are hosts too! (Re: I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 18:55:12 -0000 Hi, On Thu, Jan 07, 2016 at 06:38:51PM +0000, Niall O'Reilly wrote: > On Thu, 07 Jan 2016 12:39:47 +0000, > Alexandre Petrescu wrote: > > > > - a router doesn't join the all-hosts multicast address. > > Eh? > > 162(niall)4: for x in 1 2; do ping6 -c3 -I en1 ff02::$x; done > PING6(56=40+8+8 bytes) fe80::7a31:c1ff:feec:a2c6%en1 --> ff02::1 > 16 bytes from fe80::7a31:c1ff:feec:a2c6%en1, icmp_seq=0 hlim=64 time=0.141 ms > 16 bytes from fe80::d6ca:6dff:fe26:e0dd%en1, icmp_seq=0 hlim=255 time=3.437 ms This obviously is not an IETF Router, as we've learned today that real existing devices, like "a PC" or "a smartphone" are not IETF Hosts. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Thu Jan 7 11:07:13 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E81A71ABD3C for ; Thu, 7 Jan 2016 11:07:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 ZP9cdY6xq-UX for ; Thu, 7 Jan 2016 11:07:10 -0800 (PST) Received: from mailer2.psc.edu (mailer2.psc.edu [IPv6:2001:5e8:2:46::6a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B3291ABD3D for ; Thu, 7 Jan 2016 11:07:10 -0800 (PST) Received: from dengue.psc.edu (dengue.psc.edu [IPv6:2001:5e8:1:a0:426c:8fff:fe3d:8d38] (may be forged)) (authenticated bits=0) by mailer2.psc.edu (8.13.8/8.13.8) with ESMTP id u07J741u010934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jan 2016 14:07:06 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael H Lambert In-Reply-To: <568EACE4.2070408@isi.edu> Date: Thu, 7 Jan 2016 14:07:04 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <82D61F7C-C9F1-4281-9DAE-065D5584FF76@psc.edu> References: <568D8B33.1060301@isi.edu> <568E5C93.5050201@gmail.com> <20160107124237.GP58491@Space.Net> <568E6552.9030008@gmail.com> <568EACE4.2070408@isi.edu> To: "v6ops@ietf.org WG" X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [v6ops] Routers are hosts too! (Re: I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 19:07:12 -0000 > On 7 Jan 2016, at 13:22, Joe Touch wrote: >=20 >> Why would a Host need to look out a nexthop in routing table? To >> forward to whom? >=20 > Source address selection. See RFC1122 Sec 3.3.4.3. Yep. Back in the day we had "big iron" listening to RIP on multiple = interfaces to select the best (ie, fastest active) interface. Michael From nobody Thu Jan 7 11:12:02 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D681AC3AE for ; Thu, 7 Jan 2016 11:11:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-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 GQgk4uUybVKb for ; Thu, 7 Jan 2016 11:11:54 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9582A1ABD3E for ; Thu, 7 Jan 2016 11:11:54 -0800 (PST) Received: from [128.9.184.104] ([128.9.184.104]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u07JBHKe013719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 7 Jan 2016 11:11:17 -0800 (PST) To: joel jaeggli , Alexandre Petrescu , v6ops@ietf.org References: <568D8B33.1060301@isi.edu> <568E5C93.5050201@gmail.com> <568EAC83.4000102@isi.edu> <568EB25D.8030907@bogus.com> From: Joe Touch Message-ID: <568EB855.3020406@isi.edu> Date: Thu, 7 Jan 2016 11:11:17 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <568EB25D.8030907@bogus.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [v6ops] Routers are hosts too! (Re: I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 19:12:00 -0000 On 1/7/2016 10:45 AM, joel jaeggli wrote: > On 1/7/16 10:20 AM, Joe Touch wrote: ... >>> - a router doesn't join the all-hosts multicast address. >> >> There's an "all nodes", which it clearly should join (see RFC4921, Sec. >> 2.8). > > the platonic conception of a router as a device that simply forwards > packets maybe not, the router's control plane on the other hand is a > host on every subnet where it's addressed and is therefore a node. RFC4921 Sec 2.8 is very clear to the contrary: A host is required to recognize the following addresses as identifying itself: o Its required Link-Local address for each interface. o Any additional Unicast and Anycast addresses that have been configured for the node's interfaces (manually or automatically). o The loopback address. o The All-Nodes multicast addresses defined in Section 2.7.1. o The Solicited-Node multicast address for each of its unicast and anycast addresses. o Multicast addresses of all other groups to which the node belongs. A router is required to recognize all addresses that a host is ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ required to recognize, plus the following addresses as identifying ^^^^^^^^^^^^^^^^^^^^^ itself: I.e., there may be devices that forward packets that have no addressable control plane but they still need to recognize exactly the same addresses as a host. Joe From nobody Thu Jan 7 11:19:01 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8FEB1A010D for ; Thu, 7 Jan 2016 11:19:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-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 djQe678rrc_p for ; Thu, 7 Jan 2016 11:18:59 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A34D21ABD8F for ; Thu, 7 Jan 2016 11:18:59 -0800 (PST) Received: from [128.9.184.104] ([128.9.184.104]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u07JHraw016183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 7 Jan 2016 11:17:55 -0800 (PST) To: Michael H Lambert , "v6ops@ietf.org WG" References: <568D8B33.1060301@isi.edu> <568E5C93.5050201@gmail.com> <20160107124237.GP58491@Space.Net> <568E6552.9030008@gmail.com> <568EACE4.2070408@isi.edu> <82D61F7C-C9F1-4281-9DAE-065D5584FF76@psc.edu> From: Joe Touch X-Enigmail-Draft-Status: N1110 Message-ID: <568EB9E1.6050000@isi.edu> Date: Thu, 7 Jan 2016 11:17:53 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <82D61F7C-C9F1-4281-9DAE-065D5584FF76@psc.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [v6ops] Routers are hosts too! (Re: I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 19:19:00 -0000 On 1/7/2016 11:07 AM, Michael H Lambert wrote: >> On 7 Jan 2016, at 13:22, Joe Touch wrote: >> >>> Why would a Host need to look out a nexthop in routing table? To >>> forward to whom? >> >> Source address selection. See RFC1122 Sec 3.3.4.3. > > Yep. Back in the day we had "big iron" listening to RIP on multiple interfaces to select the best (ie, fastest active) interface. FWIW, that works great if both interfaces are always up. If one ever fails, you might cut off connections based on the failed interface address even though you could have routed them through the other interface. Our solution to this was to admit that a multihomed host was really better modeled as a virtual internal router with separate internal hosts, one for each IP address: J. Touch, T. Faber, “Dynamic Host Routing for Production Use of Developmental Networks,” in Proc. ICNP ’97, Atlanta, Oct. 1997, pp. 285-292. Joe From nobody Thu Jan 7 11:44:02 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89AD61AC3CE for ; Thu, 7 Jan 2016 11:44:01 -0800 (PST) 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 ta7BgsJIsRZb for ; Thu, 7 Jan 2016 11:44:00 -0800 (PST) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5398C1A92EA for ; Thu, 7 Jan 2016 11:44:00 -0800 (PST) Received: by mail-pa0-x22b.google.com with SMTP id ho8so5329095pac.2 for ; Thu, 07 Jan 2016 11:44:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=9oYjDgH91iYNmcGK0bJoCJ33e/6/5GHldqP1jbPu8qg=; b=JnXhVck6PGqydJgt5PpR2QOWgpCFBm59b+VPOT26us+QmycGeLx3JLI5UyyCMj6G5b +v9ytgONugpbor1rDhYoJ9a37XJFJFkdcZZpyPfZoXphPyJSTA3Uz8WXj+HZDsldHSQ8 lQxy7WTVjLtBb+yLsV0x0L0608r3aJ0MviJIIDkcgXGAW9dx3GA77i2oZ6Ew9yJpUpQ3 Ifua7jnjc9RXtK/zQqN1loErL+za6gK2Jq3CoCAZg9Bz4cElikMWMAa3wfeQgQSxR1G2 KfcHQv7lSR4JNwRdeHH4mrHpHtD1W7tSmjeD/WtLn42lprcyjiyqMfMXVFGeCS0pulSj U6Gw== X-Received: by 10.66.100.198 with SMTP id fa6mr112707705pab.123.1452195839996; Thu, 07 Jan 2016 11:43:59 -0800 (PST) Received: from ?IPv6:2406:e007:4301:1:28cc:dc4c:9703:6781? ([2406:e007:4301:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id d8sm84985884pas.14.2016.01.07.11.43.57 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Jan 2016 11:43:58 -0800 (PST) To: Andrew Yourtchenko , v6ops list References: <14610834-893D-4225-87BD-2C026580ED46@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <568EC018.2080800@gmail.com> Date: Fri, 8 Jan 2016 08:44:24 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <14610834-893D-4225-87BD-2C026580ED46@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Review of draft-gont-v6ops-ipv6-ehs-packet-drops-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 19:44:01 -0000 On 08/01/2016 05:15, Andrew Yourtchenko wrote: > Page 4: >=20 > "4.1.3. ECMP and Hash-based Load-Sharing" >=20 > =3D=3D> A naive question pops up in the mind while reading this paragra= ph - =E2=80=9Cbut, the flow label=E2=80=A6=E2=80=9D - RFC6438 has nice wo= rds on the subject. Not sure if it=E2=80=99s worth it dragging the flow l= abel here though. Up to you.. I don't think it's naive. RFC 6438 and RFC 7098 tackle two aspects of thi= s. The flow label is the fix for this, indeed (by incorporating the layer 4 information in the hash at the source host). Brian From nobody Thu Jan 7 11:58:45 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB12A1A9060 for ; Thu, 7 Jan 2016 11:58:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=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 2lrt0iPQtz-f for ; Thu, 7 Jan 2016 11:58:42 -0800 (PST) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F60E1A9009 for ; Thu, 7 Jan 2016 11:58:42 -0800 (PST) Received: by mail-vk0-x235.google.com with SMTP id a123so149152078vkh.1 for ; Thu, 07 Jan 2016 11:58:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=bbaL71rHB/8Uv82tZN5/vrsbftM6995uHFnf+dqTNh8=; b=dfJUipqgzU2xHKqqjc/YsOKnA1urk0ngTMK662tWGDtUvypaO+X21P+VpbyDtaCZ1n WgNtzMXaN4OMzAnZJBsvyNtTXQ5tejgRWTsQV33pntjdb+VJToeVDq+9CtHaiMBTtpmW C18/mkF2jCq6AQOFQyE83QF1HJd8V2KV70oOX5sP9Yb+p5zTsZASg8DGwxgkl8VOK640 wavH4y3nJwZyOyhMSGKnspFVr/4p92R8rOuCcz2+kggroTx0ypDU+hIlnWceahNFIVNk b2Bl1rFXefv0Pr8IwnClU5ZQU/Zui4ox8iSB/B8/wlHRvCeZRjNVPAJXePSkwr/dVmAx +Dvg== X-Received: by 10.31.159.136 with SMTP id i130mr45140344vke.144.1452196721397; Thu, 07 Jan 2016 11:58:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.99.1 with HTTP; Thu, 7 Jan 2016 11:58:11 -0800 (PST) In-Reply-To: <568E99D2.9080203@gmail.com> References: <568D8B33.1060301@isi.edu> <568E5C93.5050201@gmail.com> <20160107124237.GP58491@Space.Net> <568E6552.9030008@gmail.com> <20160107132117.GV58491@Space.Net> <568E6782.1000205@gmail.com> <568E99D2.9080203@gmail.com> From: Mark Smith Date: Fri, 8 Jan 2016 06:58:11 +1100 Message-ID: To: Alexandre Petrescu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Routers are hosts too! (Re: I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 19:58:44 -0000 On 8 January 2016 at 04:01, Alexandre Petrescu wrote: > > > Le 07/01/2016 17:29, Eric Vyncke (evyncke) a =C3=A9crit : >> >> Heu.. The discussion is whether routers are also hosts and NOT on >> whether hosts are routers... >> >> And in the same vein, routers DO listen to RA > > > By spec, they listen to RA just to be informed about other routers, > maybe learn if some other router dies out and log the info. But nothing > more. > > For example, they can't SLAAC an address using the prefix received in an > RA, they can't set the MTU of the link, they can't decide they have have > experienced a handover by computing the difference between the received > prefixes, and so on. > RFC7084, "Basic Requirements for IPv6 Customer Edge Routers" use RAs for most or all of those things. The Linux kernel was modified to support processing RAs when forwarding was switched on to suit this purpose, which is how the Linux kernel is used in OpenWRT to implement a router. >> and do DHCP as client (for example when they are a residential CPE) > > > I agree with the behaviour. But. > > Contrary to ND specs the DHCP specs dont talk Host vs Routers. They talk > Client vs Server vs Relay. And there is no defined relationship between > Router and Servers, for example. One can't say a Server is a Router. > > As such one couldnt say that a DHCP Client is necessarily a Host. > Agree, as I said, the distinction between a host and a router is a layer 3 function, and limited to whether or not the device will accept and process non-locally destined packets. This Fedora Linux desktop PC is currently a host, as that is it's default setting. [root@opy mark]# echo 1 > /proc/sys/net/ipv4/ip_forward [root@opy mark]# Now it is an IPv4 and IPv6 router (the global forwarding switch being under the IPv4 system settings is a historical artifact) Perhaps less well known is that some implementations can have a mix of routing and non-routing interfaces: [root@opy mark]# echo 1 > /proc/sys/net/ipv4/ip_forward # all interfaces are forwarding interfaces [root@opy mark]# echo 0 > /proc/sys/net/ipv4/conf/enp3s2/forwarding # now enp3s2 won't accept non-local packet destinations [root@opy mark]# This isn't Linux specific, if I recall correctly, I first read about this behaviour and the functional distinction between hosts and routers in Richard Steven's TCP/IP Illustrated Volume 1 many years ago. > Alex > >> >> -=C3=A9ric >> >> On 7/01/16 14:26, "v6ops on behalf of Alexandre Petrescu" >> >> wrote: >> >>> >>> >>> Le 07/01/2016 14:21, Gert Doering a =C3=A9crit : >>>> >>>> Hi, >>>> >>>> On Thu, Jan 07, 2016 at 02:17:06PM +0100, Alexandre Petrescu >>>> wrote: >>>>> >>>>> Le 07/01/2016 13:42, Gert Doering a =C3=A9crit : >>>>>> >>>>>> On Thu, Jan 07, 2016 at 01:39:47PM +0100, Alexandre Petrescu >>>>>> wrote: >>>>>>> >>>>>>> - a router does implement longest-matching algorithms, a >>>>>>> Host doesn't. >>>>>> >>>>>> >>>>>> Of course hosts do. Why would any implementor not do that? >>>>> >>>>> >>>>> Why would a Host need to look out a nexthop in routing table? >>>>> To forward to whom? >>>> >>>> >>>> Well, it needs to send its own packets somewhere, no? >>> >>> >>> YEs, to its router. There's only one - the default. There are no >>> neighbors to distinguish from. >>> >>>> And guess what, this is done using the normal routing table >>> >>> >>> Yes, the 'normal' routing table because that's what we're used >>> with since linux and Ethernet. >>> >>> But a Host using serial to connect to a router (e.g. a UE) does not >>> need a routing table. >>> >>>> which (if you set ip.forwarding=3D1) magically turns into a >>>> forwarding table. >>>> >>>> Hosts can have more than one interface, like "a LAN interface and >>>> a VPN tunnel interface". It really helps if they know which >>>> packet goes where. >>> >>> >>> YEs, but these are not pure Hosts. They are more like desktop PCs >>> and smartphones. >>> >>> Alex >>> >>>> >>>> Gert Doering -- NetMaster >>>> >>> >>> _______________________________________________ v6ops mailing list >>> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Jan 8 02:26:32 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A280A1AD071 for ; Fri, 8 Jan 2016 02:26:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2_cQaqyqZfku for ; Fri, 8 Jan 2016 02:26:29 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C8791AD070 for ; Fri, 8 Jan 2016 02:26:29 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u08AQRJx002470; Fri, 8 Jan 2016 11:26:27 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A14B62012E7; Fri, 8 Jan 2016 11:33:56 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 95BCB200C49; Fri, 8 Jan 2016 11:33:56 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u08AQQ8Z002947; Fri, 8 Jan 2016 11:26:26 +0100 To: Joe Touch , v6ops@ietf.org References: <568D8B33.1060301@isi.edu> <568E5C93.5050201@gmail.com> <568EAC83.4000102@isi.edu> From: Alexandre Petrescu Message-ID: <568F8ED2.6030000@gmail.com> Date: Fri, 8 Jan 2016 11:26:26 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <568EAC83.4000102@isi.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Routers are hosts too! (Re: I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 10:26:31 -0000 Le 07/01/2016 19:20, Joe Touch a écrit : > > > On 1/7/2016 4:39 AM, Alexandre Petrescu wrote: >> >> >> Le 06/01/2016 22:46, Joe Touch a écrit : >>> +1 (and then some) >>> >>> AFAICT: >>> >>> - a host is an Internet device that sources or sinks packets >>> >>> - a router is an Internet device that *also* relays packets >>> >>> It may be possible to implement a router that never acts as a host, but >>> that requires it never participate actively in routing protocols, IP >>> signalling, etc. >> >> Yes. And: >> >> - a router doesn't use the information received in an RA, a >> host does. > > A router might have an interface by which it is accessible as a host but > for which it does not forward; that interface could use an RA for > autoconfiguration. Yes. > >> - a router doesn't join the all-hosts multicast address. > > There's an "all nodes", which it clearly should join (see RFC4921, Sec. > 2.8). Right, I should have said '- a host does not join the all-routers address". > There is no "all-hosts" listed here (except for ST, which is obsoleted): > http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml So I discover ST stands for Internet Stream Protocol RFC1819. I think Ethernet maybe has a 48bit MAC address 33:33::3 address for "all-hosts", but I dont have the IEEE spec at hand to check. >> - a router doesn't use SLAAC to configure an address for self, >> a Host does. > > It could where appropriate (e.g., see first item above). > >> - a router does implement longest-matching algorithms, a Host >> doesn't. > > This is needed for source address selection if the host has more than > one address. But we dont know how source address selection works with this respect. I think there are some RFCs for source address selection but it doesnt say to use longest-matching algorithms IIRC. It could very well be exact match. Alex >> Implementations are obviously less clear cut. But we can talk theory. >> >> Alex >> >>> >>> Joe >>> >>> On 1/6/2016 1:24 PM, Mark Smith wrote: >>>> Routers are universally hosts too. The distinction between a router and >>>> a host is that a router will also accept packets not sent to addresses >>>> assigned to the devices interfaces. It will then see what to do with >>>> them according to the route table, sending the packet where ever the >>>> route table says or dropping them. That is all that makes it a router. >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > From nobody Fri Jan 8 02:28:13 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9721AD082 for ; Fri, 8 Jan 2016 02:28:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntDDf2AD08b7 for ; Fri, 8 Jan 2016 02:28:10 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F21BA1AD080 for ; Fri, 8 Jan 2016 02:28:09 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u08AS8El003186; Fri, 8 Jan 2016 11:28:08 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 07F372012E7; Fri, 8 Jan 2016 11:35:38 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id E4DF4200C49; Fri, 8 Jan 2016 11:35:37 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u08AS8VV004795; Fri, 8 Jan 2016 11:28:08 +0100 To: Joe Touch , Gert Doering References: <568D8B33.1060301@isi.edu> <568E5C93.5050201@gmail.com> <20160107124237.GP58491@Space.Net> <568E6552.9030008@gmail.com> <568EACE4.2070408@isi.edu> From: Alexandre Petrescu Message-ID: <568F8F37.3050708@gmail.com> Date: Fri, 8 Jan 2016 11:28:07 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <568EACE4.2070408@isi.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Routers are hosts too! (Re: I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 10:28:11 -0000 Le 07/01/2016 19:22, Joe Touch a écrit : > > > On 1/7/2016 5:17 AM, Alexandre Petrescu wrote: >> >> >> Le 07/01/2016 13:42, Gert Doering a écrit : >>> Hi, >>> >>> On Thu, Jan 07, 2016 at 01:39:47PM +0100, Alexandre Petrescu wrote: >>>> - a router does implement longest-matching algorithms, a Host >>>> doesn't. >>> >>> Of course hosts do. Why would any implementor not do that? >> >> Why would a Host need to look out a nexthop in routing table? To >> forward to whom? > > Source address selection. See RFC1122 Sec 3.3.4.3. I grepped "match" and it doesnt say whether exact match or longest-match are used. As such I think it's exact match. Alex > > Joe > From nobody Fri Jan 8 02:35:48 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05E6C1AD09A for ; Fri, 8 Jan 2016 02:35:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZdFWW-bSqQq for ; Fri, 8 Jan 2016 02:35:45 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72E0A1AD094 for ; Fri, 8 Jan 2016 02:35:45 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u08AZhwV006349; Fri, 8 Jan 2016 11:35:43 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 09DA7204FAB; Fri, 8 Jan 2016 11:43:13 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id E6733204F9F; Fri, 8 Jan 2016 11:43:12 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u08AZgln013190; Fri, 8 Jan 2016 11:35:42 +0100 To: "Niall O'Reilly" References: <568D8B33.1060301@isi.edu> <568E5C93.5050201@gmail.com> From: Alexandre Petrescu Message-ID: <568F90FE.4000603@gmail.com> Date: Fri, 8 Jan 2016 11:35:42 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Routers are hosts too! (Re: I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 10:35:47 -0000 Le 07/01/2016 19:38, Niall O'Reilly a écrit : > On Thu, 07 Jan 2016 12:39:47 +0000, > Alexandre Petrescu wrote: >> >> - a router doesn't join the all-hosts multicast address. > > Eh? > > 162(niall)4: for x in 1 2; do ping6 -c3 -I en1 ff02::$x; done > PING6(56=40+8+8 bytes) fe80::7a31:c1ff:feec:a2c6%en1 --> ff02::1 > 16 bytes from fe80::7a31:c1ff:feec:a2c6%en1, icmp_seq=0 hlim=64 time=0.141 ms > 16 bytes from fe80::d6ca:6dff:fe26:e0dd%en1, icmp_seq=0 hlim=255 time=3.437 ms > 16 bytes from fe80::7a31:c1ff:feec:a2c6%en1, icmp_seq=1 hlim=64 time=0.220 ms > 16 bytes from fe80::d6ca:6dff:fe26:e0dd%en1, icmp_seq=1 hlim=255 time=3.411 ms > 16 bytes from fe80::7a31:c1ff:feec:a2c6%en1, icmp_seq=2 hlim=64 time=0.233 ms > > --- ff02::1 ping6 statistics --- > 3 packets transmitted, 3 packets received, +2 duplicates, 0.0% packet loss > round-trip min/avg/max/std-dev = 0.141/1.488/3.437/1.581 ms > PING6(56=40+8+8 bytes) fe80::7a31:c1ff:feec:a2c6%en1 --> ff02::2 > 16 bytes from fe80::d6ca:6dff:fe26:e0dd%en1, icmp_seq=0 hlim=255 time=5.611 ms > 16 bytes from fe80::d6ca:6dff:fe26:e0dd%en1, icmp_seq=1 hlim=255 time=2.255 ms > 16 bytes from fe80::d6ca:6dff:fe26:e0dd%en1, icmp_seq=2 hlim=255 time=3.372 ms > > --- ff02::2 ping6 statistics --- > 3 packets transmitted, 3 packets received, 0.0% packet loss > round-trip min/avg/max/std-dev = 2.255/3.746/5.611/1.395 ms > 162(niall)4: Thanks right. I agree with you. The screenshot above means that the router joins the "all-nodes" and "all-routers" groups. But the ambiguity introduced by the term 'node'[*] is maintained: the node that replies to requests is both a router and 'not a router'. It's hard to wrap one's mind around that. Alex [*] rfc2464: a host is any node that is not a router. From nobody Fri Jan 8 03:10:21 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7671AD0C8 for ; Fri, 8 Jan 2016 03:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 LwVNmE0exEnu for ; Fri, 8 Jan 2016 03:10:18 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id BF0921AD0C6 for ; Fri, 8 Jan 2016 03:10:17 -0800 (PST) Received: (qmail 20244 invoked from network); 8 Jan 2016 11:10:15 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 8 Jan 2016 11:10:15 -0000 Date: Fri, 08 Jan 2016 12:10:15 +0100 (CET) Message-Id: <20160108.121015.74737501.sthaug@nethelp.no> To: alexandre.petrescu@gmail.com From: sthaug@nethelp.no In-Reply-To: <568F8F37.3050708@gmail.com> References: <568E6552.9030008@gmail.com> <568EACE4.2070408@isi.edu> <568F8F37.3050708@gmail.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Routers are hosts too! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 11:10:20 -0000 > >>>> - a router does implement longest-matching algorithms, a Host > >>>> doesn't. > >>> > >>> Of course hosts do. Why would any implementor not do that? > >> > >> Why would a Host need to look out a nexthop in routing table? To > >> forward to whom? > > > > Source address selection. See RFC1122 Sec 3.3.4.3. > > I grepped "match" and it doesnt say whether exact match or longest-match > are used. > > As such I think it's exact match. Irrespective of the source address selection issue, normal "host" operating systems that I know of (e.g. FreeBSD) most definitely implement longest match. Think of it this way: If a host *can* be turned into a router by changing a configuration knob, why on earth would you want to implement exact match to be used only for host mode (when longest match is needed in any case for router mode)? Steinar Haug, AS2116 From nobody Fri Jan 8 04:23:30 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71B941A8908 for ; Fri, 8 Jan 2016 04:23:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.125 X-Spam-Level: X-Spam-Status: No, score=-1.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FRT_PROFIT1=3.858, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 tWfy_0n9itMs for ; Fri, 8 Jan 2016 04:23:28 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA2A21A8902 for ; Fri, 8 Jan 2016 04:23:27 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u08CNOUB027034; Fri, 8 Jan 2016 13:23:24 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C84582050B1; Fri, 8 Jan 2016 13:30:53 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id BA8C6202E7D; Fri, 8 Jan 2016 13:30:53 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u08CNNdN017525; Fri, 8 Jan 2016 13:23:23 +0100 To: Lorenzo Colitti References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <568D1854.7000300@gmail.com> From: Alexandre Petrescu Message-ID: <568FAA3B.3050108@gmail.com> Date: Fri, 8 Jan 2016 13:23:23 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 12:23:29 -0000 Le 06/01/2016 16:27, Lorenzo Colitti a écrit : > > On Wed, Jan 6, 2016 at 10:36 PM, Alexandre Petrescu > > wrote: > > sidenote... > > No, that's not true. A router is "a node that forwards packets not > explicitly addressed to itself" [RFC2460]. A host that uses a prefix > obtained using DHCPv6 PD does not need to do that. > > > If one reads the Note attached to the router definition in 2460, > then one understands that a host that uses a prefix obtained with > DHCP-PD does need to forward, and maybe its apps to explicitate the > source address. > > > Why? Consider the ULA use case where a host gets a /64 via DHCPv6 PD and > uses this to assign a different IPv6 address to every process on the > system. The host does not need to forward any packets to anyone on any > interface, and thus is not a router. In that case (ULA prefix for every process on the system), the system would need to forward between processes in that sytem. That makes it a router. > This all works as expected (and as predicted by the > specifications). My > > > This is not as expected. It is the "unusual" word of 2460. > > > The "unusual" word in RFC 2460 refers to a node that forwards packets > arriving on some interfaces but not on others. That is not the case > here. My laptop was not forwarding packets from any interface to any > interface and it was purely a host. > > It is unusual in that you had to argument "-I" to that ping6. > > The usual way is to be able to say just "ping6 google.com > " without arguments. > > > If I had not specified -I, someone would have said "there is no proof > that this works, your laptop could have been using another address, one > that was not obtained via DHCPv6 PD". :-) One can give a proof it works by copy/paste the ping output - it tells the src and dst addresses. One another hand, does that ping work w/o saying -I? I guess not. Alex From nobody Fri Jan 8 05:48:15 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D7E1B29C7 for ; Fri, 8 Jan 2016 05:48:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 hJWUBJUmdLQu for ; Fri, 8 Jan 2016 05:48:12 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3D41B29C8 for ; Fri, 8 Jan 2016 05:48:12 -0800 (PST) Received: from [IPv6:2601:401:3:6a00:685d:4ce:972d:1748] (unknown [IPv6:2601:401:3:6a00:685d:4ce:972d:1748]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id C7655540AF8; Fri, 8 Jan 2016 08:48:10 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Jared Mauch X-Mailer: iPhone Mail (13C75) In-Reply-To: <20160108.121015.74737501.sthaug@nethelp.no> Date: Fri, 8 Jan 2016 08:48:10 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <67D93E4D-714A-4566-A308-D9EFBB71C43B@puck.nether.net> References: <568E6552.9030008@gmail.com> <568EACE4.2070408@isi.edu> <568F8F37.3050708@gmail.com> <20160108.121015.74737501.sthaug@nethelp.no> To: sthaug@nethelp.no Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Routers are hosts too! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 13:48:14 -0000 I've not encountered a device in the past 20+ years that doesn't do longest m= atch.=20 Jared Mauch On Jan 8, 2016, at 6:10 AM, sthaug@nethelp.no wrote: >>>>>> - a router does implement longest-matching algorithms, a Ho= st >>>>>> doesn't. >>>>>=20 >>>>> Of course hosts do. Why would any implementor not do that? >>>>=20 >>>> Why would a Host need to look out a nexthop in routing table? To >>>> forward to whom? >>>=20 >>> Source address selection. See RFC1122 Sec 3.3.4.3. >>=20 >> I grepped "match" and it doesnt say whether exact match or longest-match=20= >> are used. >>=20 >> As such I think it's exact match. >=20 > Irrespective of the source address selection issue, normal "host" > operating systems that I know of (e.g. FreeBSD) most definitely > implement longest match. >=20 > Think of it this way: If a host *can* be turned into a router by > changing a configuration knob, why on earth would you want to > implement exact match to be used only for host mode (when longest > match is needed in any case for router mode)? >=20 > Steinar Haug, AS2116 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Jan 8 06:08:30 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 828961B29EC for ; Fri, 8 Jan 2016 06:08:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.812 X-Spam-Level: X-Spam-Status: No, score=-0.812 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_MIMEOLE=1.899, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 tFwQ1n9sDonl for ; Fri, 8 Jan 2016 06:08:27 -0800 (PST) Received: from rdsmtp.iglou.com (rdsmtp.iglou.com [192.107.41.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A27F1B29E7 for ; Fri, 8 Jan 2016 06:08:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=iglou.com; s=alpha; h=Content-Transfer-Encoding:Content-Type:MIME-Version:To:From:In-Reply-To:Message-ID:Subject:Date; bh=T9kJJd6jNOpLNm6Jg/90pboTTlLsJicrEibN5FdPS6A=; b=K3RRBU0DGN56xnI9w7qnVEcOpGTipHCTQEjfE3jO4xh4scViKqVrP2xyzw990FPi7MVV8N0Lp2WB8vjszBJo/bIvaMBsVscvYW7j0IShkYtOIML3Dl+vYacGjqW9kmKsONUAiNMctBy0f6OGAopXi0trD4nIUb1YVOAmbq1NTXU=; Received: from iglou4.iglou.com ([192.107.41.39]:64513 helo=mail.iglou.com) by rdsmtp.iglou.com with esmtpa (Exim MTA/8.19.3) (envelope-from ) id 1aHXiL-00067i-Bd by authid with igloumta_auth for v6ops@ietf.org; Fri, 08 Jan 2016 09:08:25 -0500 Received: from cpe-74-139-119-34.kya.res.rr.com ([74.139.119.34]:3943 helo=[192.168.0.138]) by smtp.iglou.com with esmtpsa (TLS cipher TLSv1:AES128-SHA:128) (Exim MTA/8.19.3) (envelope-from ) id 1aHXiK-00033H-OH by authid with auth_plain for v6ops@ietf.org; Fri, 08 Jan 2016 09:08:24 -0500 Date: Fri, 08 Jan 2016 09:08:22 -0500 Message-ID: <53d11163-5717-4883-b7d5-13dcf426a8fc@email.android.com> X-Android-Message-ID: <53d11163-5717-4883-b7d5-13dcf426a8fc@email.android.com> In-Reply-To: <67D93E4D-714A-4566-A308-D9EFBB71C43B@puck.nether.net> From: Jeff McAdams To: v6ops@ietf.org Importance: Normal X-Priority: 3 X-MSMail-Priority: Normal MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Originating-IP: 74.139.119.34 X-IgLou-Customer: 0c0a260d80e111167f90f22b5835da5e Archived-At: Subject: Re: [v6ops] Routers are hosts too! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 14:08:28 -0000 VGhhdCB3YXMgZ29pbmcgdG8gYmUgbXkgcG9pbnQgYXMgd2VsbC4KCkFuZCBpZiBJIGRpZCwgSSdk IGltbWVkaWF0ZWx5IHNlbmQgaXQgYmFjayB0byB0aGUgdmVuZG9yIHRlbGxpbmcgdGhlbSBpdCB3 YXMgYnJva2VuIGFuZCBpdHMgSVAgc3RhY2sgd2FzIHVudXNhYmxlLgoKLS0gCkplZmYKCk9uIEph biA4LCAyMDE2IDg6NDggQU0sIEphcmVkIE1hdWNoIDxqYXJlZEBwdWNrLm5ldGhlci5uZXQ+IHdy b3RlOgo+Cj4gSSd2ZSBub3QgZW5jb3VudGVyZWQgYSBkZXZpY2UgaW4gdGhlIHBhc3QgMjArIHll YXJzIHRoYXQgZG9lc24ndCBkbyBsb25nZXN0IG1hdGNoLiAKPgo+IEphcmVkIE1hdWNoIAo+Cj4g T24gSmFuIDgsIDIwMTYsIGF0IDY6MTAgQU0sIHN0aGF1Z0BuZXRoZWxwLm5vIHdyb3RlOiAKPgo+ ID4+Pj4+PsKgwqDCoMKgwqDCoMKgwqDCoMKgIC0gYSByb3V0ZXIgZG9lcyBpbXBsZW1lbnQgbG9u Z2VzdC1tYXRjaGluZyBhbGdvcml0aG1zLCBhIEhvc3QgCj4gPj4+Pj4+wqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgIGRvZXNuJ3QuIAo+ID4+Pj4+IAo+ID4+Pj4+IE9mIGNvdXJzZSBob3N0cyBkby7C oCBXaHkgd291bGQgYW55IGltcGxlbWVudG9yIG5vdCBkbyB0aGF0PyAKPiA+Pj4+IAo+ID4+Pj4g V2h5IHdvdWxkIGEgSG9zdCBuZWVkIHRvIGxvb2sgb3V0IGEgbmV4dGhvcCBpbiByb3V0aW5nIHRh YmxlP8KgIFRvIAo+ID4+Pj4gZm9yd2FyZCB0byB3aG9tPyAKPiA+Pj4gCj4gPj4+IFNvdXJjZSBh ZGRyZXNzIHNlbGVjdGlvbi4gU2VlIFJGQzExMjIgU2VjIDMuMy40LjMuIAo+ID4+IAo+ID4+IEkg Z3JlcHBlZCAibWF0Y2giIGFuZCBpdCBkb2VzbnQgc2F5IHdoZXRoZXIgZXhhY3QgbWF0Y2ggb3Ig bG9uZ2VzdC1tYXRjaCAKPiA+PiBhcmUgdXNlZC4gCj4gPj4gCj4gPj4gQXMgc3VjaCBJIHRoaW5r IGl0J3MgZXhhY3QgbWF0Y2guIAo+ID4gCj4gPiBJcnJlc3BlY3RpdmUgb2YgdGhlIHNvdXJjZSBh ZGRyZXNzIHNlbGVjdGlvbiBpc3N1ZSwgbm9ybWFsICJob3N0IiAKPiA+IG9wZXJhdGluZyBzeXN0 ZW1zIHRoYXQgSSBrbm93IG9mIChlLmcuIEZyZWVCU0QpIG1vc3QgZGVmaW5pdGVseSAKPiA+IGlt cGxlbWVudCBsb25nZXN0IG1hdGNoLiAKPiA+IAo+ID4gVGhpbmsgb2YgaXQgdGhpcyB3YXk6IElm IGEgaG9zdCAqY2FuKiBiZSB0dXJuZWQgaW50byBhIHJvdXRlciBieSAKPiA+IGNoYW5naW5nIGEg Y29uZmlndXJhdGlvbiBrbm9iLCB3aHkgb24gZWFydGggd291bGQgeW91IHdhbnQgdG8gCj4gPiBp bXBsZW1lbnQgZXhhY3QgbWF0Y2ggdG8gYmUgdXNlZCBvbmx5IGZvciBob3N0IG1vZGUgKHdoZW4g bG9uZ2VzdCAKPiA+IG1hdGNoIGlzIG5lZWRlZCBpbiBhbnkgY2FzZSBmb3Igcm91dGVyIG1vZGUp PyAKPiA+IAo+ID4gU3RlaW5hciBIYXVnLCBBUzIxMTYgCj4gPiAKPiA+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIAo+ID4gdjZvcHMgbWFpbGluZyBsaXN0 IAo+ID4gdjZvcHNAaWV0Zi5vcmcgCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3Y2b3BzIAo+Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18gCj4gdjZvcHMgbWFpbGluZyBsaXN0IAo+IHY2b3BzQGlldGYub3JnIAo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMgCg== From nobody Fri Jan 8 06:22:42 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87D6D1B29F1 for ; Fri, 8 Jan 2016 06:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5cT7qOD8CGGd for ; Fri, 8 Jan 2016 06:22:38 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74B801B29F7 for ; Fri, 8 Jan 2016 06:22:38 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u08EMatt020650; Fri, 8 Jan 2016 15:22:36 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 35BEE20509B; Fri, 8 Jan 2016 15:30:06 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 26FC42011C6; Fri, 8 Jan 2016 15:30:06 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u08EMZZe007536; Fri, 8 Jan 2016 15:22:36 +0100 To: Jared Mauch , sthaug@nethelp.no References: <568E6552.9030008@gmail.com> <568EACE4.2070408@isi.edu> <568F8F37.3050708@gmail.com> <20160108.121015.74737501.sthaug@nethelp.no> <67D93E4D-714A-4566-A308-D9EFBB71C43B@puck.nether.net> From: Alexandre Petrescu Message-ID: <568FC62B.2040109@gmail.com> Date: Fri, 8 Jan 2016 15:22:35 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <67D93E4D-714A-4566-A308-D9EFBB71C43B@puck.nether.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Routers are hosts too! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 14:22:40 -0000 Le 08/01/2016 14:48, Jared Mauch a écrit : > I've not encountered a device in the past 20+ years that doesn't do longest match. > > Jared Mauch > > On Jan 8, 2016, at 6:10 AM, sthaug@nethelp.no wrote: > >>>>>>> - a router does implement longest-matching algorithms, a Host >>>>>>> doesn't. >>>>>> >>>>>> Of course hosts do. Why would any implementor not do that? >>>>> >>>>> Why would a Host need to look out a nexthop in routing table? To >>>>> forward to whom? >>>> >>>> Source address selection. See RFC1122 Sec 3.3.4.3. >>> >>> I grepped "match" and it doesnt say whether exact match or longest-match >>> are used. >>> >>> As such I think it's exact match. >> >> Irrespective of the source address selection issue, normal "host" >> operating systems that I know of (e.g. FreeBSD) most definitely >> implement longest match. YEs, I agree. Wherever BSD and linux derivatives are running longest-match is there builtin. But I think there may be a difference between OS understanding of a 'host' and a Host defined in an RFC. Where linux distros may distinguish between "desktop" and "server", an RFC may distinguish between a Host (RFC1122 and RFC1123) and a Router (RFC 1812). Only the latter requires the use of "longest match". As such, a memory-savvy and reduced clock computer Host may benefit from not implementing longest-match and still connect to the Internet. >> Think of it this way: If a host *can* be turned into a router by >> changing a configuration knob, why on earth would you want to >> implement exact match to be used only for host mode (when longest >> match is needed in any case for router mode)? Well, I agree. With a simple knob you get it. Exact match is useful for the search in the ND cache, or for the search in Ethernet-related databases. But I did not mean to compare it to longest-match. I wanted to say that a Host - as defined in RFC - does not implement longest-match. A host as people call a laptop, a smartphone or a tablet does implement it though. Alex >> >> Steinar Haug, AS2116 >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > From nobody Fri Jan 8 06:35:38 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1BB1A89FA for ; Fri, 8 Jan 2016 06:35:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 xOenLM6oByQ3 for ; Fri, 8 Jan 2016 06:35:36 -0800 (PST) Received: from rdsmtp.iglou.com (rdsmtp.iglou.com [192.107.41.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 203461A89F1 for ; Fri, 8 Jan 2016 06:35:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=iglou.com; s=alpha; h=Content-Transfer-Encoding:Content-Type:MIME-Version:To:From:Subject:Date:References:In-Reply-To:Message-ID; bh=OgRsq9+EMTazy6wuPg/ScpXkm0CF6JM6V3xQQ77h7Kw=; b=NsfcObXaQtNp3/AjboCjI2cbUkZVn6STc91qnyo++qE/CCcO9QMz6rMiGl/a0vKNjgv+Otd6j3SPKWgDga1HUGH48Lxr+vUGZ3LfO2PDrO+I2DKFvzFKhkvaJf/Bkj3rp4sjzFR6U53btAhTQuLpPKqYhMnkVw/dfvNKMyTQP4A=; Received: from iglou4.iglou.com ([192.107.41.39]:36989 helo=mail.iglou.com) by rdsmtp.iglou.com with esmtpa (Exim MTA/8.19.3) (envelope-from ) id 1aHY8c-00058C-Ls by authid with igloumta_auth for v6ops@ietf.org; Fri, 08 Jan 2016 09:35:34 -0500 Received: from air.iglou.com ([192.107.41.7]:35673 helo=webmail.iglou.com) by mailmx.iglou.com with esmtpa (Exim MTA/8.19.3) (envelope-from ) id 1aHY8c-00061H-De by authid with auth_login for v6ops@ietf.org; Fri, 08 Jan 2016 09:35:34 -0500 Received: from webmail.iglou.com ([74.139.119.34]) (Webmail authenticated user jeffm) by webmail.iglou.com with HTTP; Fri, 8 Jan 2016 09:35:34 -0500 (EST) Message-ID: <18838.74.139.119.34.1452263734.iglou@webmail.iglou.com> In-Reply-To: <568FC62B.2040109@gmail.com> References: <568E6552.9030008@gmail.com> <568EACE4.2070408@isi.edu> <568F8F37.3050708@gmail.com> <20160108.121015.74737501.sthaug@nethelp.no> <67D93E4D-714A-4566-A308-D9EFBB71C43B@puck.nether.net> <568FC62B.2040109@gmail.com> Date: Fri, 8 Jan 2016 09:35:34 -0500 (EST) From: "Jeff McAdams" To: v6ops@ietf.org User-Agent: IgLou Webmail MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Originating-IP: 192.107.41.7 X-IgLou-Customer: 0c0a260d80e111167f90f22b5835da5e Archived-At: Subject: Re: [v6ops] Routers are hosts too! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 14:35:37 -0000 > As such, a memory-savvy and reduced clock computer Host may benefit from > not implementing longest-match and still connect to the Internet. ... > I wanted to say that a Host - as defined in RFC - does not implement > longest-match. > A host as people call a laptop, a smartphone or a tablet does implement > it though. So, basically, you're saying that, to at least a vanishingly small rounding error, there are no "RFC Hosts" on the Internet today. So what's your point? -- Jeff From nobody Fri Jan 8 07:24:58 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBCA1A8A61 for ; Fri, 8 Jan 2016 07:24:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBPjA-0rS8CU for ; Fri, 8 Jan 2016 07:24:50 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D1EC1A8A46 for ; Fri, 8 Jan 2016 07:24:50 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u08FOmJl028473 for ; Fri, 8 Jan 2016 16:24:48 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 1E60B2012B2 for ; Fri, 8 Jan 2016 16:32:18 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 0CEF82052BF for ; Fri, 8 Jan 2016 16:32:18 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u08FOl7C008816 for ; Fri, 8 Jan 2016 16:24:47 +0100 To: v6ops@ietf.org References: <568E6552.9030008@gmail.com> <568EACE4.2070408@isi.edu> <568F8F37.3050708@gmail.com> <20160108.121015.74737501.sthaug@nethelp.no> <67D93E4D-714A-4566-A308-D9EFBB71C43B@puck.nether.net> <568FC62B.2040109@gmail.com> <18838.74.139.119.34.1452263734.iglou@webmail.iglou.com> From: Alexandre Petrescu Message-ID: <568FD4BF.5080608@gmail.com> Date: Fri, 8 Jan 2016 16:24:47 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <18838.74.139.119.34.1452263734.iglou@webmail.iglou.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Routers are hosts too! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 15:24:57 -0000 Le 08/01/2016 15:35, Jeff McAdams a écrit : > >> As such, a memory-savvy and reduced clock computer Host may benefit from >> not implementing longest-match and still connect to the Internet. > > ... > >> I wanted to say that a Host - as defined in RFC - does not implement >> longest-match. > >> A host as people call a laptop, a smartphone or a tablet does implement >> it though. > > So, basically, you're saying that, to at least a vanishingly small > rounding error, there are no "RFC Hosts" on the Internet today. > > So what's your point? Maybe we should find that small rounding error - what OS does not implement longest-match and yet connects to the Internet? Second, until we ifnd that small rounding error, we may stop talking about Hosts, and declare the Host RFC historic. Or update it with a sentence saying that Hosts too must implement longest-match. Alex > From nobody Fri Jan 8 07:43:06 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C17611A8A9A for ; Fri, 8 Jan 2016 07:43:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 bwd9GUSCOSVt for ; Fri, 8 Jan 2016 07:42:55 -0800 (PST) Received: from rdsmtp.iglou.com (rdsmtp.iglou.com [192.107.41.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CD3A1A8A7D for ; Fri, 8 Jan 2016 07:42:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=iglou.com; s=alpha; h=Content-Transfer-Encoding:Content-Type:MIME-Version:To:From:Subject:Date:References:In-Reply-To:Message-ID; bh=76lmk/35T7iZ1i+cAjQtWNNloJ4Ng1e3BZ2VBwzYXn4=; b=Bgd5zx9Mo9A+SdyHciYPX4R/H6cpV6kCjOhZ/z6V1xokegIYzbcohhFH8eqYa9OydgX9X/ZOymmYq3sjzZkW9PjF4ekFEX0p6jJYRCPaGBKCERcLHUun09cSyee7AG+CInvw/f9oyTdlAMzWQfoQYae4/5gWEZKLjRF/yNIgE5A=; Received: from iglou4.iglou.com ([192.107.41.39]:52216 helo=mail.iglou.com) by rdsmtp.iglou.com with esmtpa (Exim MTA/8.19.3) (envelope-from ) id 1aHZBl-0007Wz-Cn by authid with igloumta_auth for v6ops@ietf.org; Fri, 08 Jan 2016 10:42:53 -0500 Received: from air.iglou.com ([192.107.41.7]:37162 helo=webmail.iglou.com) by mailmx.iglou.com with esmtpa (Exim MTA/8.19.3) (envelope-from ) id 1aHZBk-00068W-Rp by authid with auth_login for v6ops@ietf.org; Fri, 08 Jan 2016 10:42:52 -0500 Received: from webmail.iglou.com ([74.139.119.34]) (Webmail authenticated user jeffm) by webmail.iglou.com with HTTP; Fri, 8 Jan 2016 10:42:52 -0500 (EST) Message-ID: <4129.74.139.119.34.1452267772.iglou@webmail.iglou.com> In-Reply-To: <568FD4BF.5080608@gmail.com> References: <568E6552.9030008@gmail.com> <568EACE4.2070408@isi.edu> <568F8F37.3050708@gmail.com> <20160108.121015.74737501.sthaug@nethelp.no> <67D93E4D-714A-4566-A308-D9EFBB71C43B@puck.nether.net> <568FC62B.2040109@gmail.com> <18838.74.139.119.34.1452263734.iglou@webmail.iglou.com> <568FD4BF.5080608@gmail.com> Date: Fri, 8 Jan 2016 10:42:52 -0500 (EST) From: "Jeff McAdams" To: v6ops@ietf.org User-Agent: IgLou Webmail MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Originating-IP: 192.107.41.7 X-IgLou-Customer: 0c0a260d80e111167f90f22b5835da5e Archived-At: Subject: Re: [v6ops] Routers are hosts too! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 15:43:01 -0000 On Fri, January 8, 2016 10:24, Alexandre Petrescu wrote: > Le 08/01/2016 15:35, Jeff McAdams a écrit : >>> As such, a memory-savvy and reduced clock computer Host may benefit >>> from not implementing longest-match and still connect to the Internet. >>> >> >> ... >> >> >>> I wanted to say that a Host - as defined in RFC - does not implement >>> longest-match. >> >>> A host as people call a laptop, a smartphone or a tablet does >>> implement it though. >> >> So, basically, you're saying that, to at least a vanishingly small >> rounding error, there are no "RFC Hosts" on the Internet today. >> >> So what's your point? > Maybe we should find that small rounding error - what OS does not > implement longest-match and yet connects to the Internet? OK, I (and I suspect most others on this thread) am not convinced they exist at all. Maybe let us know if/when you find some? > Second, until we ifnd that small rounding error, we may stop talking > about Hosts, and declare the Host RFC historic. Or update it with a > sentence saying that Hosts too must implement longest-match. I'm still a bit confused about where this was specified. Can you give me/us a more specific cite than "an RFC" (or have I, perhaps, missed this in the discussion that has happened...I will admit to not having read every message in the thread)? I, for one, would be willing to support this, if there is, indeed, a place where this is specified. -- Jeff From nobody Fri Jan 8 07:50:57 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB3571A8AA9 for ; Fri, 8 Jan 2016 07:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 fZ32Swwa72pR for ; Fri, 8 Jan 2016 07:50:55 -0800 (PST) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0DDE1A8A9B for ; Fri, 8 Jan 2016 07:50:54 -0800 (PST) Received: by mail-yk0-x234.google.com with SMTP id x67so366541100ykd.2 for ; Fri, 08 Jan 2016 07:50:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=bEmhy3p5fKncOyfOLrL3sUX/yvoS5F8ArV0cwRonvcE=; b=L3VXUYadRlzQTP1xaO6Cate7ERuuVzCA0voSKwG3at+DZR5zxqrW0Tqn2bKcOpynmG gAvS53y04UPIFUqQJEGktNQpFwQNYTUGkMQoXYCq9LscN5rY0L9ef9ZkxfFnC8HZpZMF DoNb03BVMoDZ2sbrR9aYXypZ3ZFQZVrtl+N66X4Gu91djeTKI+/7NEGIkyvO9t5Ggp6G 0LIfAq2lOp3ztpjgJh6XHyDSD0LK+ZcIU3ZltWnFh8HUpKAEEH26kqVITFrMjLwOgqro QjMtV+gzCsMWyI5pOwEdbv85XK9PzJDI3tsC+RoP/p9q0fw7yfYq9gLhU2Hjxzpg13Ur RVKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=bEmhy3p5fKncOyfOLrL3sUX/yvoS5F8ArV0cwRonvcE=; b=afX6VAMmVmS6Bpi1/YignBn3G3LFP0Q5AAzZ2tARlH7wS8Zz6x+DQlByhJnkXZwOI0 nc34Z/RfphfeojNe0LK1KNL8+wrbAP0XxaG2Ok7kzEnGBO3sn3kqUoIBVLKUqkTtLLRx ngdEcT3Ov9NvIWpMB9IVdCzdtuE5eRA5ieKKmBnbSTM5dFSuAmJ32kMklV/74blUvObZ d7p7HxY+LGrVM/DaPbVGB2R9xVdYewS1Hx1vwbaY7IGNLSXJcvarJM+ocb6csbvVBTVc p35mg52wo5VOkmUApMAHWujDv1yj1FJbdccX9IhFor+gKY89UDUcBiyd0NCt+XPT4quc 5TRw== X-Gm-Message-State: ALoCoQmSZBMkNrYE8c13deI31PaLr2/lypNyOxvjzU50U5whSsll61o3QpvNPOSnu0QKDrX5NwNx7n8OcCCi+c91ehMOGkuMrPtrF/Um9Iw9ZVo/r6ZNZAQ= X-Received: by 10.129.70.8 with SMTP id t8mr38258928ywa.105.1452268254027; Fri, 08 Jan 2016 07:50:54 -0800 (PST) MIME-Version: 1.0 References: <568E6552.9030008@gmail.com> <568EACE4.2070408@isi.edu> <568F8F37.3050708@gmail.com> <20160108.121015.74737501.sthaug@nethelp.no> <67D93E4D-714A-4566-A308-D9EFBB71C43B@puck.nether.net> In-Reply-To: <67D93E4D-714A-4566-A308-D9EFBB71C43B@puck.nether.net> From: Warren Kumari Date: Fri, 08 Jan 2016 15:50:44 +0000 Message-ID: To: Jared Mauch , sthaug@nethelp.no Content-Type: multipart/alternative; boundary=001a114d71a86690870528d48d5d Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Routers are hosts too! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 15:50:56 -0000 --001a114d71a86690870528d48d5d Content-Type: text/plain; charset=UTF-8 On Fri, Jan 8, 2016 at 8:48 AM Jared Mauch wrote: > I've not encountered a device in the past 20+ years that doesn't do > longest match. > > Actually, I suspect that you have, as have I, as have all of us -- there are many small embedded widgets which have *tiny* IP stacks which are incredibly simple, and don't really seem to understand the concept of more than one route - in fact, often it is even simpler than that - they don't really understand a "subnet", all packets get sent to the router. The uIP stack is (unless I'm very mistaken and routing was added later) an example of a stack that doesn't seem to implement longest-match, largely because it doesn't really seem to understand "routes" - if a destination is within the local subnet it will ARP and send the packet there, otherwise everything goes to "the default router": If the destination IP address is not on the local network, the IP address of the default router is used instead."v - http://www.cs.tut.fi/kurssit/OHJ-4301/harjoitustyo/btweb/uip-0_9-refman.pdf This stack still seems to be used in things like some petrol / fuel pumps, and in some of the coffee machines in Burger King (it's fascinating what you can pull off ROM / flash from discarded devices :-)) These are "devices", but possibly not "hosts"... W > Jared Mauch > > On Jan 8, 2016, at 6:10 AM, sthaug@nethelp.no wrote: > > >>>>>> - a router does implement longest-matching algorithms, a > Host > >>>>>> doesn't. > >>>>> > >>>>> Of course hosts do. Why would any implementor not do that? > >>>> > >>>> Why would a Host need to look out a nexthop in routing table? To > >>>> forward to whom? > >>> > >>> Source address selection. See RFC1122 Sec 3.3.4.3. > >> > >> I grepped "match" and it doesnt say whether exact match or longest-match > >> are used. > >> > >> As such I think it's exact match. > > > > Irrespective of the source address selection issue, normal "host" > > operating systems that I know of (e.g. FreeBSD) most definitely > > implement longest match. > > > > Think of it this way: If a host *can* be turned into a router by > > changing a configuration knob, why on earth would you want to > > implement exact match to be used only for host mode (when longest > > match is needed in any case for router mode)? > > > > Steinar Haug, AS2116 > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a114d71a86690870528d48d5d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri= , Jan 8, 2016 at 8:48 AM Jared Mauch <jared@puck.nether.net> wrote:
I've not encountered a device in the past 20+ years that doesn= 't do longest match.


Actually, I suspect that you have, as = have I, as have all of us -- there are many small embedded widgets which ha= ve *tiny* IP stacks which are incredibly simple, and don't really seem = to understand the concept of more than one route - in fact, often it is eve= n simpler than that - they don't really understand a "subnet"= , all packets get sent to the router.

The uIP stac= k is (unless I'm very mistaken and routing was added later) an example = of a stack that doesn't seem to implement longest-match, largely becaus= e it doesn't really seem to understand "routes" - if a destin= ation is within the local subnet it will ARP and send the packet there, oth= erwise everything goes to "the default router":
If the = destination IP address is not on the local network, the IP address of the d= efault router is used instead."v -=C2=A0http://www.cs.tut= .fi/kurssit/OHJ-4301/harjoitustyo/btweb/uip-0_9-refman.pdf
This stack still seems to be used in things like some petrol /= fuel pumps, and in some of the coffee machines in Burger King (it's fa= scinating what you can pull off ROM / flash from discarded devices :-))

These are "devices", but possibly not "= ;hosts"...
W
=C2=A0
Jared Mauch

On Jan 8, 2016, at 6:10 AM, sthaug@nethelp.no wrote:

>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- a router= does implement longest-matching algorithms, a Host
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0doe= sn't.
>>>>>
>>>>> Of course hosts do.=C2=A0 Why would any implementor no= t do that?
>>>>
>>>> Why would a Host need to look out a nexthop in routing tab= le?=C2=A0 To
>>>> forward to whom?
>>>
>>> Source address selection. See RFC1122 Sec 3.3.4.3.
>>
>> I grepped "match" and it doesnt say whether exact match = or longest-match
>> are used.
>>
>> As such I think it's exact match.
>
> Irrespective of the source address selection issue, normal "host&= quot;
> operating systems that I know of (e.g. FreeBSD) most definitely
> implement longest match.
>
> Think of it this way: If a host *can* be turned into a router by
> changing a configuration knob, why on earth would you want to
> implement exact match to be used only for host mode (when longest
> match is needed in any case for router mode)?
>
> Steinar Haug, AS2116
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org=
> https://www.ietf.org/mailman/listinfo/v6ops

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--001a114d71a86690870528d48d5d-- From nobody Fri Jan 8 08:05:13 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8FD51B2A1C for ; Fri, 8 Jan 2016 08:05:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4yVWZ5AM7H2S for ; Fri, 8 Jan 2016 08:05:11 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D6F41B2A20 for ; Fri, 8 Jan 2016 08:05:10 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u08G58XB000949 for ; Fri, 8 Jan 2016 17:05:08 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B490F205310 for ; Fri, 8 Jan 2016 17:12:38 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id ACA8D205273 for ; Fri, 8 Jan 2016 17:12:38 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u08G58xQ017150 for ; Fri, 8 Jan 2016 17:05:08 +0100 To: v6ops@ietf.org References: <568E6552.9030008@gmail.com> <568EACE4.2070408@isi.edu> <568F8F37.3050708@gmail.com> <20160108.121015.74737501.sthaug@nethelp.no> <67D93E4D-714A-4566-A308-D9EFBB71C43B@puck.nether.net> <568FC62B.2040109@gmail.com> <18838.74.139.119.34.1452263734.iglou@webmail.iglou.com> <568FD4BF.5080608@gmail.com> <4129.74.139.119.34.1452267772.iglou@webmail.iglou.com> From: Alexandre Petrescu Message-ID: <568FDE34.1060003@gmail.com> Date: Fri, 8 Jan 2016 17:05:08 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <4129.74.139.119.34.1452267772.iglou@webmail.iglou.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Routers are hosts too! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 16:05:12 -0000 Le 08/01/2016 16:42, Jeff McAdams a écrit : > On Fri, January 8, 2016 10:24, Alexandre Petrescu wrote: >> Le 08/01/2016 15:35, Jeff McAdams a écrit : > >>>> As such, a memory-savvy and reduced clock computer Host may benefit >>>> from not implementing longest-match and still connect to the Internet. >>>> >>> >>> ... >>> >>> >>>> I wanted to say that a Host - as defined in RFC - does not implement >>>> longest-match. >>> >>>> A host as people call a laptop, a smartphone or a tablet does >>>> implement it though. >>> >>> So, basically, you're saying that, to at least a vanishingly small >>> rounding error, there are no "RFC Hosts" on the Internet today. >>> >>> So what's your point? > > >> Maybe we should find that small rounding error - what OS does not >> implement longest-match and yet connects to the Internet? > > OK, I (and I suspect most others on this thread) am not convinced they > exist at all. Maybe let us know if/when you find some? > >> Second, until we ifnd that small rounding error, we may stop talking >> about Hosts, and declare the Host RFC historic. Or update it with a >> sentence saying that Hosts too must implement longest-match. > > I'm still a bit confused about where this was specified. Can you give > me/us a more specific cite than "an RFC" (or have I, perhaps, missed this > in the discussion that has happened...I will admit to not having read > every message in the thread)? I, for one, would be willing to support > this, if there is, indeed, a place where this is specified. RFC1122 "Reqs for Internet Hosts -- Communication Layers" does not mention longest-prefix match. RFC1812 "Reqs for IPv6 Routers" requires a router to use longest-matching network prefix when forwarding, to use a forwarding table (aka rt table) etc. Alex > From nobody Fri Jan 8 08:34:44 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA6A1B2A2C for ; Fri, 8 Jan 2016 08:34:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 RYFsXoJyYrVE for ; Fri, 8 Jan 2016 08:34:40 -0800 (PST) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3A481B2A2B for ; Fri, 8 Jan 2016 08:34:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u08GYjKq026925; Fri, 8 Jan 2016 08:34:45 -0800 Received: from XCH-BLV-303.nw.nos.boeing.com (xch-blv-303.nw.nos.boeing.com [130.247.25.215]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u08GYfPS026883 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 8 Jan 2016 08:34:41 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.52]) by XCH-BLV-303.nw.nos.boeing.com ([169.254.3.173]) with mapi id 14.03.0235.001; Fri, 8 Jan 2016 08:34:35 -0800 From: "Templin, Fred L" To: Alexandre Petrescu , "v6ops@ietf.org" Thread-Topic: [v6ops] Routers are hosts too! Thread-Index: AQHRSi5iJXFYcFFmSEqxTvTi5RbzV57x0EkQ Date: Fri, 8 Jan 2016 16:34:34 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F9D16D@XCH-BLV-504.nw.nos.boeing.com> References: <568E6552.9030008@gmail.com> <568EACE4.2070408@isi.edu> <568F8F37.3050708@gmail.com> <20160108.121015.74737501.sthaug@nethelp.no> <67D93E4D-714A-4566-A308-D9EFBB71C43B@puck.nether.net> <568FC62B.2040109@gmail.com> <18838.74.139.119.34.1452263734.iglou@webmail.iglou.com> <568FD4BF.5080608@gmail.com> <4129.74.139.119.34.1452267772.iglou@webmail.iglou.com> <568FDE34.1060003@gmail.com> In-Reply-To: <568FDE34.1060003@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] Routers are hosts too! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 16:34:42 -0000 Hi, > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandre Petres= cu > Sent: Friday, January 08, 2016 8:05 AM > To: v6ops@ietf.org > Subject: Re: [v6ops] Routers are hosts too! >=20 >=20 >=20 > Le 08/01/2016 16:42, Jeff McAdams a =E9crit : > > On Fri, January 8, 2016 10:24, Alexandre Petrescu wrote: > >> Le 08/01/2016 15:35, Jeff McAdams a =E9crit : > > > >>>> As such, a memory-savvy and reduced clock computer Host may benefit > >>>> from not implementing longest-match and still connect to the Interne= t. > >>>> > >>> > >>> ... > >>> > >>> > >>>> I wanted to say that a Host - as defined in RFC - does not implement > >>>> longest-match. > >>> > >>>> A host as people call a laptop, a smartphone or a tablet does > >>>> implement it though. > >>> > >>> So, basically, you're saying that, to at least a vanishingly small > >>> rounding error, there are no "RFC Hosts" on the Internet today. > >>> > >>> So what's your point? > > > > > >> Maybe we should find that small rounding error - what OS does not > >> implement longest-match and yet connects to the Internet? > > > > OK, I (and I suspect most others on this thread) am not convinced they > > exist at all. Maybe let us know if/when you find some? > > > >> Second, until we ifnd that small rounding error, we may stop talking > >> about Hosts, and declare the Host RFC historic. Or update it with a > >> sentence saying that Hosts too must implement longest-match. > > > > I'm still a bit confused about where this was specified. Can you give > > me/us a more specific cite than "an RFC" (or have I, perhaps, missed th= is > > in the discussion that has happened...I will admit to not having read > > every message in the thread)? I, for one, would be willing to support > > this, if there is, indeed, a place where this is specified. >=20 > RFC1122 "Reqs for Internet Hosts -- Communication Layers" does not > mention longest-prefix match. RFC4191 does mention longest-prefix match for what it calls "Type C" hosts. Thanks - Fred fred.l.templin@boeing.com > RFC1812 "Reqs for IPv6 Routers" requires a router to use > longest-matching network prefix when forwarding, to use a forwarding > table (aka rt table) etc. >=20 > Alex > > >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Jan 8 08:56:58 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 714CB1B2A58 for ; Fri, 8 Jan 2016 08:56:56 -0800 (PST) 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, 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 Fn6ZKkS3-r7Z for ; Fri, 8 Jan 2016 08:56:54 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 732D11B2A53 for ; Fri, 8 Jan 2016 08:56:54 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u08GuosJ003579 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Jan 2016 16:56:50 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.local Message-ID: <568FEA50.6000701@foobar.org> Date: Fri, 08 Jan 2016 16:56:48 +0000 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Warren Kumari References: <568E6552.9030008@gmail.com> <568EACE4.2070408@isi.edu> <568F8F37.3050708@gmail.com> <20160108.121015.74737501.sthaug@nethelp.no> <67D93E4D-714A-4566-A308-D9EFBB71C43B@puck.nether.net> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Routers are hosts too! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 16:56:56 -0000 Warren Kumari wrote: > These are "devices", but possibly not "hosts"... this sounds like we're considering perfectly spherical ipv6 hosts in a vacuum. Nick From nobody Fri Jan 8 09:01:40 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0271B2A5C for ; Fri, 8 Jan 2016 09:01:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 fF6ElnU-TYod for ; Fri, 8 Jan 2016 09:01:37 -0800 (PST) Received: from rdsmtp.iglou.com (rdsmtp.iglou.com [192.107.41.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A3321B2A5E for ; Fri, 8 Jan 2016 09:01:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=iglou.com; s=alpha; h=Content-Transfer-Encoding:Content-Type:MIME-Version:To:From:Subject:Date:References:In-Reply-To:Message-ID; bh=0Bb8Bl93skdXq0HiBBw/F4pS74l7POk/X83FN3eBUK0=; b=Ze/9h1/CaLnBsgD/ETDU/67cIZVdVp8e8GA39rMuuvkGPQFFSepTkQDPvEn+mrLBAKmwcnSKbCDXFfsbjqg8th4fPfLODvwmouAJyoZYpktcAzssj4+1mulUGq97wA9M5YLrnHnQ2QLzGruZvQHNR/saeSGXlVuqXCe5Z0+DJ4A=; Received: from iglou4.iglou.com ([192.107.41.39]:36337 helo=mail.iglou.com) by rdsmtp.iglou.com with esmtpa (Exim MTA/8.19.3) (envelope-from ) id 1aHaPv-0007kA-Rw by authid with igloumta_auth for v6ops@ietf.org; Fri, 08 Jan 2016 12:01:35 -0500 Received: from air.iglou.com ([192.107.41.7]:45186 helo=webmail.iglou.com) by mailmx.iglou.com with esmtpa (Exim MTA/8.19.3) (envelope-from ) id 1aHaPv-0007e6-BF by authid with auth_login for v6ops@ietf.org; Fri, 08 Jan 2016 12:01:35 -0500 Received: from webmail.iglou.com ([74.139.119.34]) (Webmail authenticated user jeffm) by webmail.iglou.com with HTTP; Fri, 8 Jan 2016 12:01:35 -0500 (EST) Message-ID: <4281.74.139.119.34.1452272495.iglou@webmail.iglou.com> In-Reply-To: <568FDE34.1060003@gmail.com> References: <568E6552.9030008@gmail.com> <568EACE4.2070408@isi.edu> <568F8F37.3050708@gmail.com> <20160108.121015.74737501.sthaug@nethelp.no> <67D93E4D-714A-4566-A308-D9EFBB71C43B@puck.nether.net> <568FC62B.2040109@gmail.com> <18838.74.139.119.34.1452263734.iglou@webmail.iglou.com> <568FD4BF.5080608@gmail.com> <4129.74.139.119.34.1452267772.iglou@webmail.iglou.com> <568FDE34.1060003@gmail.com> Date: Fri, 8 Jan 2016 12:01:35 -0500 (EST) From: "Jeff McAdams" To: v6ops@ietf.org User-Agent: IgLou Webmail MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Originating-IP: 192.107.41.7 X-IgLou-Customer: 0c0a260d80e111167f90f22b5835da5e Archived-At: Subject: Re: [v6ops] Routers are hosts too! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 17:01:39 -0000 On Fri, January 8, 2016 11:05, Alexandre Petrescu wrote: > RFC1122 "Reqs for Internet Hosts -- Communication Layers" does not > mention longest-prefix match. > RFC1812 "Reqs for IPv6 Routers" requires a router to use > longest-matching network prefix when forwarding, to use a forwarding table > (aka rt table) etc. 1122? Wow, ancient days. So, there are copious examples of RFCs that post-date 1122 where wording wrt hosts at the very least presumes longest-match behavior...even if not explicitly stated as such. I see someone else already posted one, I turned up RFC3442 with only a few minutes of looking. (And, really, I usually pretty much only lurk on the periphery of IETF activity...I'm sure others that have been more involved over the years can find even better examples) -- Jeff From nobody Fri Jan 8 09:14:14 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B86B1B2A82 for ; Fri, 8 Jan 2016 09:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 bc__lV16bicZ for ; Fri, 8 Jan 2016 09:14:09 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 029E31A9097 for ; Fri, 8 Jan 2016 09:14:08 -0800 (PST) Received: (qmail 27181 invoked from network); 8 Jan 2016 17:14:07 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 8 Jan 2016 17:14:07 -0000 Date: Fri, 08 Jan 2016 18:14:07 +0100 (CET) Message-Id: <20160108.181407.74727795.sthaug@nethelp.no> To: nick@foobar.org From: sthaug@nethelp.no In-Reply-To: <568FEA50.6000701@foobar.org> References: <67D93E4D-714A-4566-A308-D9EFBB71C43B@puck.nether.net> <568FEA50.6000701@foobar.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Routers are hosts too! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 17:14:12 -0000 > > These are "devices", but possibly not "hosts"... > > this sounds like we're considering perfectly spherical ipv6 hosts in a > vacuum. And continuing in this vein, pretty soon we'll assume a spherical cow of uniform density? :-) Let's get back to discussing IPv6, though. Personally I would prefer if all "hosts" (servers, PCs, whatever) could simply use DHCPv6 PD and be done with it. Steinar Haug, AS2116 From nobody Fri Jan 8 09:15:14 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4F91A9097 for ; Fri, 8 Jan 2016 09:15:06 -0800 (PST) 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, 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 xt6wc7f_R8Zw for ; Fri, 8 Jan 2016 09:15:04 -0800 (PST) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3BF11B2A8B for ; Fri, 8 Jan 2016 09:14:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u08HEwW9063967; Fri, 8 Jan 2016 10:14:58 -0700 Received: from XCH-BLV-202.nw.nos.boeing.com (xch-blv-202.nw.nos.boeing.com [10.57.37.69]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u08HEqcJ063936 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 8 Jan 2016 10:14:53 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.52]) by XCH-BLV-202.nw.nos.boeing.com ([169.254.2.106]) with mapi id 14.03.0235.001; Fri, 8 Jan 2016 09:14:51 -0800 From: "Templin, Fred L" To: Jeff McAdams , "v6ops@ietf.org" Thread-Topic: [v6ops] Routers are hosts too! Thread-Index: AQHRSjY7JXFYcFFmSEqxTvTi5RbzV57x2x2w Date: Fri, 8 Jan 2016 17:14:51 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F9D23E@XCH-BLV-504.nw.nos.boeing.com> References: <568E6552.9030008@gmail.com> <568EACE4.2070408@isi.edu> <568F8F37.3050708@gmail.com> <20160108.121015.74737501.sthaug@nethelp.no> <67D93E4D-714A-4566-A308-D9EFBB71C43B@puck.nether.net> <568FC62B.2040109@gmail.com> <18838.74.139.119.34.1452263734.iglou@webmail.iglou.com> <568FD4BF.5080608@gmail.com> <4129.74.139.119.34.1452267772.iglou@webmail.iglou.com> <568FDE34.1060003@gmail.com> <4281.74.139.119.34.1452272495.iglou@webmail.iglou.com> In-Reply-To: <4281.74.139.119.34.1452272495.iglou@webmail.iglou.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: Subject: Re: [v6ops] Routers are hosts too! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 17:15:06 -0000 Hi, > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Jeff McAdams > Sent: Friday, January 08, 2016 9:02 AM > To: v6ops@ietf.org > Subject: Re: [v6ops] Routers are hosts too! >=20 >=20 > On Fri, January 8, 2016 11:05, Alexandre Petrescu wrote: > > RFC1122 "Reqs for Internet Hosts -- Communication Layers" does not > > mention longest-prefix match. >=20 > > RFC1812 "Reqs for IPv6 Routers" requires a router to use > > longest-matching network prefix when forwarding, to use a forwarding ta= ble > > (aka rt table) etc. >=20 > 1122? Wow, ancient days. >=20 > So, there are copious examples of RFCs that post-date 1122 where wording > wrt hosts at the very least presumes longest-match behavior...even if not > explicitly stated as such. >=20 > I see someone else already posted one, I turned up RFC3442 with only a fe= w > minutes of looking. (And, really, I usually pretty much only lurk on the > periphery of IETF activity...I'm sure others that have been more involved > over the years can find even better examples) Another is RFC6434 which (perhaps wisely) represents itself a "node require= ments" and not host/route requirements. Thanks - Fred fred.l.templin@boeing.com =20 > -- > Jeff >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Jan 8 09:59:44 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFD171A90FC for ; Fri, 8 Jan 2016 09:59:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7NneJHXnmP1 for ; Fri, 8 Jan 2016 09:59:32 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65A731B2AA9 for ; Fri, 8 Jan 2016 09:59:32 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u08HxQS2011513; Fri, 8 Jan 2016 18:59:26 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9DA192053FE; Fri, 8 Jan 2016 19:06:56 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 91DD92011CD; Fri, 8 Jan 2016 19:06:56 +0100 (CET) Received: from [132.166.84.69] ([132.166.84.69]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u08HxP2a021584; Fri, 8 Jan 2016 18:59:26 +0100 To: "Templin, Fred L" , "v6ops@ietf.org" References: <568E6552.9030008@gmail.com> <568EACE4.2070408@isi.edu> <568F8F37.3050708@gmail.com> <20160108.121015.74737501.sthaug@nethelp.no> <67D93E4D-714A-4566-A308-D9EFBB71C43B@puck.nether.net> <568FC62B.2040109@gmail.com> <18838.74.139.119.34.1452263734.iglou@webmail.iglou.com> <568FD4BF.5080608@gmail.com> <4129.74.139.119.34.1452267772.iglou@webmail.iglou.com> <568FDE34.1060003@gmail.com> <2134F8430051B64F815C691A62D9831832F9D16D@XCH-BLV-504.nw.nos.boeing.com> From: Alexandre Petrescu Message-ID: <568FF8FD.10903@gmail.com> Date: Fri, 8 Jan 2016 18:59:25 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <2134F8430051B64F815C691A62D9831832F9D16D@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Routers are hosts too! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 17:59:37 -0000 Le 08/01/2016 17:34, Templin, Fred L a écrit : > Hi, > >> -----Original Message----- >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandre Petrescu >> Sent: Friday, January 08, 2016 8:05 AM >> To: v6ops@ietf.org >> Subject: Re: [v6ops] Routers are hosts too! >> >> >> >> Le 08/01/2016 16:42, Jeff McAdams a écrit : >>> On Fri, January 8, 2016 10:24, Alexandre Petrescu wrote: >>>> Le 08/01/2016 15:35, Jeff McAdams a écrit : >>> >>>>>> As such, a memory-savvy and reduced clock computer Host may benefit >>>>>> from not implementing longest-match and still connect to the Internet. >>>>>> >>>>> >>>>> ... >>>>> >>>>> >>>>>> I wanted to say that a Host - as defined in RFC - does not implement >>>>>> longest-match. >>>>> >>>>>> A host as people call a laptop, a smartphone or a tablet does >>>>>> implement it though. >>>>> >>>>> So, basically, you're saying that, to at least a vanishingly small >>>>> rounding error, there are no "RFC Hosts" on the Internet today. >>>>> >>>>> So what's your point? >>> >>> >>>> Maybe we should find that small rounding error - what OS does not >>>> implement longest-match and yet connects to the Internet? >>> >>> OK, I (and I suspect most others on this thread) am not convinced they >>> exist at all. Maybe let us know if/when you find some? >>> >>>> Second, until we ifnd that small rounding error, we may stop talking >>>> about Hosts, and declare the Host RFC historic. Or update it with a >>>> sentence saying that Hosts too must implement longest-match. >>> >>> I'm still a bit confused about where this was specified. Can you give >>> me/us a more specific cite than "an RFC" (or have I, perhaps, missed this >>> in the discussion that has happened...I will admit to not having read >>> every message in the thread)? I, for one, would be willing to support >>> this, if there is, indeed, a place where this is specified. >> >> RFC1122 "Reqs for Internet Hosts -- Communication Layers" does not >> mention longest-prefix match. > > RFC4191 does mention longest-prefix match for what it calls "Type C" hosts. So that 'Updates' RFC1122, and it should say so on the RFC1122 page in the section "Updated by:" https://tools.ietf.org/html/rfc1122 (currently several RFCs update rfc1122 and rfc4191 is not included). Alex > > Thanks - Fred > fred.l.templin@boeing.com > >> RFC1812 "Reqs for IPv6 Routers" requires a router to use >> longest-matching network prefix when forwarding, to use a forwarding >> table (aka rt table) etc. >> >> Alex >>> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > From nobody Fri Jan 8 10:01:07 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC4EB1B2AA9 for ; Fri, 8 Jan 2016 10:01:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVHe9YBTOeDB for ; Fri, 8 Jan 2016 10:00:56 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABC731B2AAC for ; Fri, 8 Jan 2016 10:00:53 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u08I0p03030953 for ; Fri, 8 Jan 2016 19:00:51 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BDD15205421 for ; Fri, 8 Jan 2016 19:08:21 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A96C02053FE for ; Fri, 8 Jan 2016 19:08:21 +0100 (CET) Received: from [132.166.84.69] ([132.166.84.69]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u08I0olv022439 for ; Fri, 8 Jan 2016 19:00:51 +0100 To: v6ops@ietf.org References: <568E6552.9030008@gmail.com> <568EACE4.2070408@isi.edu> <568F8F37.3050708@gmail.com> <20160108.121015.74737501.sthaug@nethelp.no> <67D93E4D-714A-4566-A308-D9EFBB71C43B@puck.nether.net> <568FC62B.2040109@gmail.com> <18838.74.139.119.34.1452263734.iglou@webmail.iglou.com> <568FD4BF.5080608@gmail.com> <4129.74.139.119.34.1452267772.iglou@webmail.iglou.com> <568FDE34.1060003@gmail.com> <4281.74.139.119.34.1452272495.iglou@webmail.iglou.com> From: Alexandre Petrescu Message-ID: <568FF952.2090508@gmail.com> Date: Fri, 8 Jan 2016 19:00:50 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <4281.74.139.119.34.1452272495.iglou@webmail.iglou.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Routers are hosts too! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 18:01:00 -0000 Le 08/01/2016 18:01, Jeff McAdams a écrit : > > On Fri, January 8, 2016 11:05, Alexandre Petrescu wrote: >> RFC1122 "Reqs for Internet Hosts -- Communication Layers" does not >> mention longest-prefix match. > >> RFC1812 "Reqs for IPv6 Routers" requires a router to use >> longest-matching network prefix when forwarding, to use a forwarding table >> (aka rt table) etc. > > 1122? Wow, ancient days. > > So, there are copious examples of RFCs that post-date 1122 where wording > wrt hosts at the very least presumes longest-match behavior...even if not > explicitly stated as such. > > I see someone else already posted one, I turned up RFC3442 with only a few > minutes of looking. (And, really, I usually pretty much only lurk on the > periphery of IETF activity...I'm sure others that have been more involved > over the years can find even better examples) In that sense, I dont know what makes a Host be a Host and not a Router. What particular characteristic of Host is not a characteristic of a Router too? Alex > From nobody Fri Jan 8 10:07:59 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC0E11B2AC1 for ; Fri, 8 Jan 2016 10:07:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_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 IS_RWM5ASxor for ; Fri, 8 Jan 2016 10:07:47 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0721.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::721]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60CCE1B2AC0 for ; Fri, 8 Jan 2016 10:07:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IcfuV7+oggAEfiTiN8sXBYglXMGUsL2yKBFNkj3vofo=; b=Ejqv/UZ9kJOP2G+rvwdPkpYCppuu3Ec8YLfbDsZScCc2+24cjb7ozmEO7669KI2GLJawwGIAntA1/UdGkWohQcDAAUK7WleI0+RCPnlqzkx/us196jwOuLU8649B4mPlsqR/8f5tsHv/OloW8Blk55BV03/rn9vhZV1o3hMFkEc= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (86.185.87.133) by DBXPR07MB064.eurprd07.prod.outlook.com (10.242.147.24) with Microsoft SMTP Server (TLS) id 15.1.361.13; Fri, 8 Jan 2016 18:07:29 +0000 Message-ID: <007701d14a3f$16965100$4001a8c0@gateway.2wire.net> From: t.petch To: , References: <67D93E4D-714A-4566-A308-D9EFBB71C43B@puck.nether.net> <568FEA50.6000701@foobar.org> <20160108.181407.74727795.sthaug@nethelp.no> Date: Fri, 8 Jan 2016 18:04:50 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.185.87.133] X-ClientProxiedBy: DB4PR06CA0031.eurprd06.prod.outlook.com (25.160.40.159) To DBXPR07MB064.eurprd07.prod.outlook.com (10.242.147.24) X-Microsoft-Exchange-Diagnostics: 1; DBXPR07MB064; 2:cm/QgRZtZqO4roCXI3vrDKIsdLQmFhd4ig+I4bhbSvI/4AyhEX+pWkRDS48rkqLyrqi5j4mad7lTAVLm9oPE+bO0JDw6EJ0t0dQuWNnZrzhv0J9Dbm7W+OBSjgxRm4ZuVh5MOEia4nKYd7Ja2kIK5w==; 3:tMSG3BP/YmabHyHs/HWGFiPlskzx4b0kZP6UTFV5RGzN0l5or622oksiMJhVHPsubx91cmj7mlEdU3C3pyz6K88F5diMuisY8qITaPTxG6c9U8vOidj/vrXl9ERwCFDL; 25:JRpTZF8NETpFtJv68xGRBQj8N+WPzkHm7RMA2Z05MgLIcn1CujvlUFxIyPCBrezXuZnPhdnmEowtncJC34JyYnK3i1g63lQcLBpQlnO+wscn5cdbdmcin5NfDIlFEoMsb4+Xgr6xlCotoOknT7PW4KBPfI1ENyEwem/Iz0VsFSd5ICCcnEabvRcjmFStbyS0ZCdQHNGdb3w//bCF5y7KxB2PLsObqale8+3CZl3iAtIRUYJwnljfz8TZkcw9lVQv; 4:vU8gbKj6wb68yuS6mjSFGm9M3O1a4UDQGP3u7RfjNQ+0maYldyUTPcgWCXAKMK84asK9cXcdr+8+eA60D3ZeuQS2rpsB/n84B0SqlNFv7mWlE2V7as2GfcnHd17TK6yO/bAgrUWfpeiWm/lOmNKQ96hQfqida4poM65db6zF7KkWggnl8FTWOrYJD8gv+uX/0Bp/v5BpM2CkxgKOfSbKkJlNn1S59k9cJClWCRLIHzZRt8fGiKOqyHLGXCKTK34SIUMytbTaDqht+DiWWnlhiOcVmCbN1DGljBJ5/aJxFINaA3rPVGbWs0QDIfTNbzTx6i/nhX29UKgNZpvF8IinfrHeqCGn2xX34p3Q1xo/pXKoZt/oF+EQaWnTua+xpCi5 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB064; X-MS-Office365-Filtering-Correlation-Id: c66df3c2-1cfb-4c60-3dd9-08d3185692c5 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(10201501046)(3002001); SRVR:DBXPR07MB064; BCL:0; PCL:0; RULEID:; SRVR:DBXPR07MB064; X-Forefront-PRVS: 0815F8251E X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(199003)(13464003)(189002)(44736004)(5008740100001)(5001960100002)(77096005)(1456003)(23756003)(15975445007)(14496001)(6116002)(50466002)(44716002)(5001770100001)(76176999)(50986999)(230700001)(33646002)(93886004)(84392002)(87976001)(2906002)(81816999)(42186005)(66066001)(4326007)(189998001)(19580395003)(116806002)(105586002)(92566002)(62236002)(97736004)(86362001)(3846002)(226693001)(19580405001)(1556002)(50226001)(40100003)(47776003)(106356001)(101416001)(61296003)(81156007)(5004730100002)(1096002)(81686999)(122386002)(586003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB064; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DBXPR07MB064; 23:fwianP2WeZv09n3FRIVMWil7JieuU6EERC7pMCSI?= =?iso-8859-1?Q?ehD4EXvpKaaZuiWaJUNExLM2CX59pKedBe53xdGeP5IBpsx0Doi0MnQ24U?= =?iso-8859-1?Q?farM6pssNRjcpLQu4U0fgu2lQ9DKJYXl5optgMmqnBffdvHsD2e0O9gZlf?= =?iso-8859-1?Q?HeWoeRb2urAIFRiLu5awwYyptsRAOPFcOWrMU8pCKQ9i+Iv37S0Ovgo5dU?= =?iso-8859-1?Q?4PY5qqai2Xlt0PHVKvBFcFOLTad/hdKc1dRZQNH+tWf/DKZ/32kOAHfyLS?= =?iso-8859-1?Q?SGnh4dRseSPDhmJib0oZwIfdiyyzNNGAWiScagZXTPmyxOByvAJ4+ZyqRW?= =?iso-8859-1?Q?V0Sz3UtsTSWL7nPdFY9LtKOJEXtBZrHn7En0CjylxzHJFaku6YlUKKkbfm?= =?iso-8859-1?Q?LtfLOWhQf8eJ2QVwzbGpeVP/4SfsIIKlmxWrgGNwdqXEtUbL5HShyIaARf?= =?iso-8859-1?Q?UCrxlYSeD+c0mvFyZjzQK/sQ+tfylvebD6rdq6lxkYueWy8lcqhXuIijHW?= =?iso-8859-1?Q?NJCPXEBmH8g3psmlzu9lNHdXrxdhc2yxsi940EcG1KgK3BuJaQf95wVneq?= =?iso-8859-1?Q?Jf9icCzE+AyYUHSownMCggZzgr5qvV4WGx/Zn8LQwxTYrY92bomXkV+LKb?= =?iso-8859-1?Q?866TsnM40E5vHclmIQ8mU1aIGg2VGfoUXsnEe3EZBP3rtY/Sn9AOFf3xjL?= =?iso-8859-1?Q?0cn9IlIZ1zdO+IP1GjYA3LJRLqo3PCKZ52Q/OXeWm9ud4RdWCYpkcrWRgg?= =?iso-8859-1?Q?lebQy3uQ3ZcV9A8kuvEbP0/3fAFD4AKwV126A6rT3xqkDdAVvKbkt24UCr?= =?iso-8859-1?Q?DUpQBUDDCsklLjwHGjIv7tz1HxJSKcjtArp28jm/tdtGJ9D3Cc1SZsGINF?= =?iso-8859-1?Q?BHS4wyLbJNBxoa8QAU049otYezF5GbPqpRs2ruWDWeDYf6S1ChhqxBls1O?= =?iso-8859-1?Q?W/AJGq6kbv6SBwoFk5OQRfDOsDVeHAJyiOGG89K74CrjbqBaoveP2zKr8v?= =?iso-8859-1?Q?n6ZWlZwdLAz0mx9zTXdCQ0XUJotyOXfVxd1HwoWkX3I7i52nn5YTlyXjMS?= =?iso-8859-1?Q?OSoa1YT6ecN0jBp8t2qpOryM1BMYPWCP3i/zx5g8y6FWch5ycAVc1hl1mk?= =?iso-8859-1?Q?Zsa76P+Mffyis8Lz1h3cqhVMoIhZcwYOVPkYtNLGo4CA0qJUOq4jZ8qJfr?= =?iso-8859-1?Q?sTTxwGf2NaleUb4c1kmDAECzUnUw57pL+AwU0yXgjSVoqbhUSkulbW7GT1?= =?iso-8859-1?Q?wqMYHEAK0maEAKyNRL/zzjP3x7OlXN2f6xmVoiHskO9easQk3WcXiG+L9A?= =?iso-8859-1?Q?G4noc4/1aRzY0Ezuz3GorCTddKiMWT8cKxzcfXWEOYNeHsbizZhNQdj30P?= =?iso-8859-1?Q?Pq1s81Jjk0fi/3dSwcutrVBHc9iHYyy9JUq5bJjv5IHC0PkYZf4TrjJCyQ?= =?iso-8859-1?Q?MKxIPmrGGc/ZE=3D?= X-Microsoft-Exchange-Diagnostics: 1; DBXPR07MB064; 5:/Irb+N2/w1dJgnHbLby6dkTA8QtRd+QjOouxVxClL+DIUMUb+v8LglSQbigb+G3vYKcUIVvJm2zZ/LnUkgyjhAoOOl554ychVjirgR3nDrPtaGfMBTl7tKFlPpsaQMLPewuqF6aFTfhq6aq6NXmiCg==; 24:zBlxnzJkshQVnzwZOta2XrG4aEFnnVFdL4IgkP9aSZ6FdPTXgWJojSdrJW332B0STKv4acDhWJj3jyMs7/hcqTJE5l1tDfi8/mSGrdy7/aE= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jan 2016 18:07:29.6153 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB064 Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Routers are hosts too! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 18:07:54 -0000 ----- Original Message ----- From: To: Cc: Sent: Friday, January 08, 2016 5:14 PM > > > These are "devices", but possibly not "hosts"... > > > > this sounds like we're considering perfectly spherical ipv6 hosts in a > > vacuum. > > And continuing in this vein, pretty soon we'll assume a spherical cow > of uniform density? :-) I love the way that this thread was originally 'Focused Discussion' and is now, well, the usual, focused, I suppose. There is something about IPv6 that causes this to happen, and I suspect that whatever it is is not conducive to the progress of either the IETF or of the use of IPv6. For myself, I have an existence proof, of the non-existence of IPv6 in my own neck of the woods, and track this list against the day when it exists and I have an interest. If and when that day comes, I might understand how it is that IPv6 Operations generates more discussion with less apparent consensus than anything else I see in the IETF, a process which I find more interesting than the technical details of, say, M and O, SLAAC, DHCPv6-PD etc- at least, at present. Tom Petch > > Let's get back to discussing IPv6, though. Personally I would prefer > if all "hosts" (servers, PCs, whatever) could simply use DHCPv6 PD and > be done with it. > > Steinar Haug, AS2116 > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Jan 8 10:15:43 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0B9A1B2ACD for ; Fri, 8 Jan 2016 10:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 AJ41vABc5BJt for ; Fri, 8 Jan 2016 10:15:33 -0800 (PST) Received: from rdsmtp.iglou.com (rdsmtp.iglou.com [192.107.41.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68F771B2ACB for ; Fri, 8 Jan 2016 10:15:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=iglou.com; s=alpha; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Cc:To:From:Subject:Date:References:In-Reply-To:Message-ID; bh=hvIpbdEfu1i84w4/Wj/4vl0gQqqPzPqXtD3iaStHupA=; b=Y8aKv9GFux2W4rKnTQfCtmsoVYehrNf8B8jcbnQjAK/HvYRTCdaz1wk+YzaUtRkvNznURwjAQhPP0E3lVotas+tCk5vMJ/g+fWPyil7J5E7mBUWihaoXiihRi65l4kuoZeUxSoW15GoTtOaOiAES74S2cmDVM9/qWtnzqoCxeIM=; Received: from iglou4.iglou.com ([192.107.41.39]:51846 helo=mail.iglou.com) by rdsmtp.iglou.com with esmtpa (Exim MTA/8.19.3) (envelope-from ) id 1aHbZT-0000Hy-Lq by authid with igloumta_auth for v6ops@ietf.org; Fri, 08 Jan 2016 13:15:31 -0500 Received: from air.iglou.com ([192.107.41.7]:49392 helo=webmail.iglou.com) by mailmx.iglou.com with esmtpa (Exim MTA/8.19.3) (envelope-from ) id 1aHbZT-0000Dj-6X by authid with auth_login; Fri, 08 Jan 2016 13:15:31 -0500 Received: from webmail.iglou.com ([74.139.119.34]) (Webmail authenticated user jeffm) by webmail.iglou.com with HTTP; Fri, 8 Jan 2016 13:15:31 -0500 (EST) Message-ID: <7459.74.139.119.34.1452276931.iglou@webmail.iglou.com> In-Reply-To: <568FF952.2090508@gmail.com> References: <568E6552.9030008@gmail.com> <568EACE4.2070408@isi.edu> <568F8F37.3050708@gmail.com> <20160108.121015.74737501.sthaug@nethelp.no> <67D93E4D-714A-4566-A308-D9EFBB71C43B@puck.nether.net> <568FC62B.2040109@gmail.com> <18838.74.139.119.34.1452263734.iglou@webmail.iglou.com> <568FD4BF.5080608@gmail.com> <4129.74.139.119.34.1452267772.iglou@webmail.iglou.com> <568FDE34.1060003@gmail.com> <4281.74.139.119.34.1452272495.iglou@webmail.iglou.com> <568FF952.2090508@gmail.com> Date: Fri, 8 Jan 2016 13:15:31 -0500 (EST) From: "Jeff McAdams" To: "Alexandre Petrescu" User-Agent: IgLou Webmail MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Originating-IP: 192.107.41.7 X-IgLou-Customer: 0c0a260d80e111167f90f22b5835da5e Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Routers are hosts too! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 18:15:38 -0000 On Fri, January 8, 2016 13:00, Alexandre Petrescu wrote: > In that sense, I dont know what makes a Host be a Host and not a Router. > What particular characteristic of Host is not a characteristic of a > Router too? So, I'm still not sure what you're trying to accomplish out of this discussion, but ok.... I think you have it backwards. At least in my mind and the working definitions I've always used, a router is a device that forwards packets between network interface using Layer 3 addressing information. A device that *doesn't* forward traffic would thus *just* be a host. I've never worked up a good working definition in my mind to decide whether routers are hosts or not...mostly because, in 20+ years of my career, it has never been something I've had to even think about. Thus my questioning of what this whole discussion is really all about. We're - in my mind - well into the territory of angels dancing on the head of a pin, much ado about nothing, and a huge heaping dose of bikeshedding. If you find an example of a system that *doesn't* do longest match, then let's talk about it. (Yes, I saw the example of uIP, I would argue it does do longest match as it chooses between localnet destinations and 0.0.0.0/0...it just has an *extremely* constrained routing table capacity - 2 entries, and a very unusual internal representation of that routing table) -- Jeff From nobody Fri Jan 8 10:21:57 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CAB21B2ABD for ; Fri, 8 Jan 2016 10:21:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 qT7shABtdqta for ; Fri, 8 Jan 2016 10:21:46 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F9EE1B2AC7 for ; Fri, 8 Jan 2016 10:21:45 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id DDD84608E1 for ; Fri, 8 Jan 2016 19:21:43 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id A4A3A600FC for ; Fri, 8 Jan 2016 19:21:43 +0100 (CET) Received: (qmail 61546 invoked by uid 1007); 8 Jan 2016 19:21:43 +0100 Date: Fri, 8 Jan 2016 19:21:43 +0100 From: Gert Doering To: Alexandre Petrescu Message-ID: <20160108182143.GQ58491@Space.Net> References: <568F8F37.3050708@gmail.com> <20160108.121015.74737501.sthaug@nethelp.no> <67D93E4D-714A-4566-A308-D9EFBB71C43B@puck.nether.net> <568FC62B.2040109@gmail.com> <18838.74.139.119.34.1452263734.iglou@webmail.iglou.com> <568FD4BF.5080608@gmail.com> <4129.74.139.119.34.1452267772.iglou@webmail.iglou.com> <568FDE34.1060003@gmail.com> <4281.74.139.119.34.1452272495.iglou@webmail.iglou.com> <568FF952.2090508@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <568FF952.2090508@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Routers are hosts too! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 18:21:48 -0000 Hi, On Fri, Jan 08, 2016 at 07:00:50PM +0100, Alexandre Petrescu wrote: > In that sense, I dont know what makes a Host be a Host and not a Router. > > What particular characteristic of Host is not a characteristic of a > Router too? "not forwarding IP packets not destined to one of its own addresses" iow, ip.forwarding=0 -> host ip.forwarding=1 -> router done Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Fri Jan 8 11:10:28 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DEA11B2B18 for ; Fri, 8 Jan 2016 11:10:26 -0800 (PST) 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, 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 ep6Gsfo7QOTK for ; Fri, 8 Jan 2016 11:10:18 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 482C81AC398 for ; Fri, 8 Jan 2016 11:10:17 -0800 (PST) Received: from [192.168.0.102] (unknown [190.49.61.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 1A4AE206891; Fri, 8 Jan 2016 14:10:08 -0500 (EST) To: Andrew Yourtchenko , v6ops list References: <14610834-893D-4225-87BD-2C026580ED46@gmail.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56900933.7050709@si6networks.com> Date: Fri, 8 Jan 2016 16:08:35 -0300 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <14610834-893D-4225-87BD-2C026580ED46@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Review of draft-gont-v6ops-ipv6-ehs-packet-drops-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 19:10:26 -0000 Hi, Andrew, Thanks so much for your feedback! -- Please find my responses in-line... On 01/07/2016 01:15 PM, Andrew Yourtchenko wrote: > Hello all, > > Below go my notes from reading the > https://www.ietf.org/id/draft-gont-v6ops-ipv6-ehs-packet-drops-01.txt > > Overall: > > The document is easy to read. Most of my comments are nits and > suggestions of additional content that I thought might be on-topic. Thanks! > Page 1: > > > "Discussions about the security and operational implications of IPv6 > extension headers are a regular feature in IETF working groups and > other places. Often in these discussions, important security and > operational issues are overlooked. > > This document tries to raise awareness about the security and > operational implications of IPv6 Extension Headers, and presents > reasons why some networks drop packets containing IPv6 Extension > Headers." > > ==> First paragraph reads to me like it makes a rather broad > assertion. I’d rephrase it from the authors’ viewpoint, something > along the lines of: > > “The authors had been involved in numerous discussions about the IPv6 > extension headers: both within IETF and outside of it. They noticed > that a number of security and operational issues were unknown to the > larger audience participating in these discussions. This document > aims to correct this by presenting these issues - so as to explain > how some networks might choose their policy towards the packets > containing IPv6 Extension Headersâ€. > > (the reason for “their policy†vs. just “drop†is section 5 presents > the consequences of dropping, and the way I read it - implicitly > advocates against it). Not sure I follow. What we're trying to say is that some ops have concrete and valid reasons for dropping packets with EHs, even if we don't like that. > Page 2: > > Evasion of security controls > > ==> Pure L3 ACLs are not affected by EH parsing, are they ? If they > aren’t - putting a qualifier “security controls aiming at layers > above the network layer†or something of that kind could be useful. Do you mean just filter on IP addresses, or do you consider "upper protocol type" to be part of such l3 ACLs? If the former, you're absolutely right. If the later, you're not. :-) > > Page 3: > > “This has presented implementation difficulties, and packet filtering > mechanisms on several security devices can be trivially evaded by > inserting IPv6 Extension Headers between the main IPv6 header and the > upper layer protocol.†> > ==> “packet filtering mechanisms based protocol data above the > network layer†(the same idea as previous comment - qualify that pure > L3 filtering is not affected if it isn’t. > > To expose my idea behind these two comments: > > L4 ACL is an operationally useful and convenient layer violation. In > IPv4 it was reliable and easy and in IPv6 it isn’t. This is a pretty > bad feature disparity between the two protocols. But one can imagine > an alternative IPv6-only universe where unikernel-run apps simply > would not have their OS support for any other ports than the ones > they use, thus making the L4 ACLs on intermediate nodes less > relevant. Back on planet Earth, as implemented in iron, IPv6 L3 ACLs > do work and with IPv6 L4 ACLs you can’t be sure - unless you drop EHs > - thus, network architect, beware. Agreed. Also, please see my comment regarding "upper protocol type" above. > Page 4: > > "4.1.3. ECMP and Hash-based Load-Sharing" > > ==> A naive question pops up in the mind while reading this paragraph > - “but, the flow label…†- RFC6438 has nice words on the subject. Not > sure if it’s worth it dragging the flow label here though. Up to > you.. This was on our todo list. We'll certainly point to RFC6438. A second question is what's the situation regarding: * hosts setting the flow label * load balancers being able to do anything useful with it > Page 6: > > "4.2 Route-Processor Protection" > > ==> There’s RFC6192 talking about protecting control plane with ready > made examples of L3 and L4 ACLs for two vendors - it might be useful > to reference that. Will do. > That would make this section talk about the ACLs, > which might also make it worth reordering 4.1.x, e.g.: 4.1.4 then > 4.1.3 then 4.1.1 then 4.1.2 - this way it flows from ‘how the > hardware performs lookups’ to ‘some of the lookups being done’ to > ‘Why we need L4 ACLs’ - and thus 4.2 would logically glue with the > end of 4.1. I'll come back to you regarding this one. > "Communication between any two systems through to public network" > > ==> seems like extraneous “to†here I'll s/to/the/ > Page 8: > > [I-D.ietf-6man-deprecate-atomfrag-generation] has recently proposed > to deprecate the generation of IPv6 atomic fragments, and update > SIIT [RFC6145] such that it does not rely on ICMPv6 atomic > fragments. Thus, any of the above mitigations would eliminate the > attack vector without any interoperability implications. > > ==> I see several issues here: > > 1. Glancing through deprecate-atomfrag, seems there is a circular > dependency of sorts: ehs-packet-drops document says the blackhole > exists because the atomic fragments are generated/used, The intent, at least, was to say that: * widespread filtering of EHs means that packets with EHs may get blackholed * Atomic fragments represent probably the only case in which an attacker can remotely trigger the use of EHs for a third party connection * Hence, an attacker can trigger atomic fragments, such that the widespread filtering of EHs essentially blackholes the target traffic. > and the > deprecate-atomfrag says the problem exists because the atomic > fragments are dropped. My understanding is that the dependency is > that first the EHs are blocked by the network operator(s) for reasons > unrelated to atomic fragments, Agreed. > which creates the blackhole > preventable by not sending atomic fragments while continuing to block > the EHs. Agreed. > 2. Really a comment for deprecate-atomfrag, but given the presence of > this paragraph and its wording, I’ll bring it up here: > http://www.arkko.com/tools/allstats/citations-rfc6145.html shows > quite a graph of dependencies that will be shaken upon a 6145 update. > I didn’t go through the list to see if there are protocol > dependencies (4rd and MAP-T come to mind but maybe something else ?) > - but a document proposing changing 6145 and asserting that there > will be no interoperability implications needs to ensure that none of > the dependencies get out of whack. RFC6145 itself notes that atomic fragments are not reliable, and proposes a workaround for that -- the big question, to me, is why such workaround wasn't made "on by default". (RFC6145 itself contains stats regarding how bad atomic fragments fail to be generated.). Some implementations never generated them. Others, such as Linux, have removed support for atomic fragments for a while now. Some FreeBSD versions generate them, other's don't. Bottom line: Can you rely on IPv6 atomic fragments, even in "controlled environments"? -- No. Then have your protocol use something that can be relied upon. And, if you read atomfrag-deprecation, you'll see that the concrete negative impact (security, performance, and reliability) outweighs the possible benefits. > 3. SIIT and friends can appear in different topologies, with some of > the topologies being affected differently from the others, e.g. with > MAP-T the atomic fragments are not ever leaving the service provider > network, so the generation, filtering and processing is within the > same admin domain. The difference in the impact might affect the > policy decisions. The question here is why you wouldn't design a protocol that is robust, rather than one that works only in specific scenarios. > So I’d probably rephrase and have the paragraph say that full > analysis is being done as part of deprecate-atomfrag, or something of > sorts - or delete it all together. I can leave with tweaking the text. Will get back to you regarding this one. > Not sure. So take it FWIW. I’ll > need to carefully read the deprecate-atomfrag document to get a > clearer opinion about the interaction of these two documents. Please send any further comments whenever you have them. Thanks so much! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Jan 8 14:34:01 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD7491B2C51 for ; Fri, 8 Jan 2016 14:33:57 -0800 (PST) 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 NzAiZFbHeoDx for ; Fri, 8 Jan 2016 14:33:55 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB3E01B2C4B for ; Fri, 8 Jan 2016 14:33:53 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id l65so151031599wmf.1 for ; Fri, 08 Jan 2016 14:33:53 -0800 (PST) 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=da+BL6KKxeHVc20oFMhfBbMzhmDgtIxP7X2NdDNbdM8=; b=CCRDn90JyitWhYvOC1kkz2ACfP6Xki+eGt5HUn9vo0OSFUI6XfFdf0lqY42gmBHzdE M7dzUjNiNqFy3KJzxOAO9QAcsudMC1sKyO9OqekFgyuHvgpb6u8iYxdpAUv7JWsCXp+b 4TrDxb1iSU/Ppynn2YdV+/AepFTwWoKgz9f9ZDlGv+a4TVle3AOUR6hLK3INYBn830Rd DNq2rQz1Xz566RP3MKqAxaB1n6BHMYN92r2JU4Toej0+9UvFcV7iO+ZxHJBkGvFE+SxM HkZYBWqA1U/UTOMAqdBCUfKGT0Ns8SUTPHVZQdpqCk4jx1Ku1GFsQ+okbthLMMnuLzxy jf2w== X-Received: by 10.28.174.77 with SMTP id x74mr1041468wme.99.1452292432504; Fri, 08 Jan 2016 14:33:52 -0800 (PST) Received: from [10.83.39.138] ([188.189.76.199]) by smtp.gmail.com with ESMTPSA id x10sm73544434wjx.8.2016.01.08.14.33.44 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Jan 2016 14:33:51 -0800 (PST) Content-Type: text/plain; charset=windows-1251 Mime-Version: 1.0 (1.0) From: =?utf-8?Q?Andrew_=F0=9F=91=BD_Yourtchenko?= X-Mailer: iPhone Mail (13C75) In-Reply-To: <56900933.7050709@si6networks.com> Date: Fri, 8 Jan 2016 23:33:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <68B44469-5BEA-4B6E-91CF-BC9DB53F2685@gmail.com> References: <14610834-893D-4225-87BD-2C026580ED46@gmail.com> <56900933.7050709@si6networks.com> To: Fernando Gont Archived-At: Cc: v6ops list Subject: Re: [v6ops] Review of draft-gont-v6ops-ipv6-ehs-packet-drops-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 22:33:57 -0000 Hi Fernando, > On 08 Jan 2016, at 20:08, Fernando Gont wrote: >=20 > Hi, Andrew, >=20 > Thanks so much for your feedback! -- Please find my responses in-line... >=20 >> On 01/07/2016 01:15 PM, Andrew Yourtchenko wrote: >> Hello all, >>=20 >> Below go my notes from reading the >> https://www.ietf.org/id/draft-gont-v6ops-ipv6-ehs-packet-drops-01.txt >>=20 >> Overall: >>=20 >> The document is easy to read. Most of my comments are nits and >> suggestions of additional content that I thought might be on-topic. >=20 > Thanks! >=20 >=20 >=20 >> Page 1: >>=20 >>=20 >> "Discussions about the security and operational implications of IPv6=20 >> extension headers are a regular feature in IETF working groups and=20 >> other places. Often in these discussions, important security and=20 >> operational issues are overlooked. >>=20 >> This document tries to raise awareness about the security and=20 >> operational implications of IPv6 Extension Headers, and presents=20 >> reasons why some networks drop packets containing IPv6 Extension=20 >> Headers." >>=20 >> =3D=3D> First paragraph reads to me like it makes a rather broad >> assertion. I=92d rephrase it from the authors=92 viewpoint, something >> along the lines of: >>=20 >> =93The authors had been involved in numerous discussions about the IPv6 >> extension headers: both within IETF and outside of it. They noticed >> that a number of security and operational issues were unknown to the >> larger audience participating in these discussions. This document >> aims to correct this by presenting these issues - so as to explain >> how some networks might choose their policy towards the packets >> containing IPv6 Extension Headers=94. >>=20 >> (the reason for =93their policy=94 vs. just =93drop=94 is section 5 prese= nts >> the consequences of dropping, and the way I read it - implicitly >> advocates against it). >=20 > Not sure I follow. What we're trying to say is that some ops have > concrete and valid reasons for dropping packets with EHs, even if we > don't like that. >=20 Dropping EH then leads to a potential DoS, did I not get this right ? As suc= h, that scenario implicitly advocates against dropping EHs. >=20 >=20 >=20 >> Page 2: >>=20 >> Evasion of security controls >>=20 >> =3D=3D> Pure L3 ACLs are not affected by EH parsing, are they ? If they >> aren=92t - putting a qualifier =93security controls aiming at layers >> above the network layer=94 or something of that kind could be useful. >=20 > Do you mean just filter on IP addresses, or do you consider "upper > protocol type" to be part of such l3 ACLs? >=20 > If the former, you're absolutely right. If the later, you're not. :-) >=20 Just addresses. Upper protocol type is one EH before the ports so has the sa= me problems. >=20 >>=20 >> Page 3: >>=20 >> =93This has presented implementation difficulties, and packet filtering >> mechanisms on several security devices can be trivially evaded by >> inserting IPv6 Extension Headers between the main IPv6 header and the >> upper layer protocol.=94 >>=20 >> =3D=3D> =93packet filtering mechanisms based protocol data above the >> network layer=94 (the same idea as previous comment - qualify that pure >> L3 filtering is not affected if it isn=92t. >>=20 >> To expose my idea behind these two comments: >>=20 >> L4 ACL is an operationally useful and convenient layer violation. In >> IPv4 it was reliable and easy and in IPv6 it isn=92t. This is a pretty >> bad feature disparity between the two protocols. But one can imagine >> an alternative IPv6-only universe where unikernel-run apps simply >> would not have their OS support for any other ports than the ones >> they use, thus making the L4 ACLs on intermediate nodes less >> relevant. Back on planet Earth, as implemented in iron, IPv6 L3 ACLs >> do work and with IPv6 L4 ACLs you can=92t be sure - unless you drop EHs >> - thus, network architect, beware. >=20 > Agreed. Also, please see my comment regarding "upper protocol type" above.= >=20 >=20 >=20 >=20 >> Page 4: >>=20 >> "4.1.3. ECMP and Hash-based Load-Sharing" >>=20 >> =3D=3D> A naive question pops up in the mind while reading this paragraph= >> - =93but, the flow label=85=94 - RFC6438 has nice words on the subject. N= ot >> sure if it=92s worth it dragging the flow label here though. Up to >> you.. >=20 > This was on our todo list. We'll certainly point to RFC6438. A second > question is what's the situation regarding: >=20 > * hosts setting the flow label > * load balancers being able to do anything useful with it >=20 >=20 No idea... But as usual - if someone really wants it, they will get the vend= ors to implement it.. (Whether nudging in this direction is ops is another q= uestion though, I don't know..) >=20 >=20 >> Page 6: >>=20 >> "4.2 Route-Processor Protection" >>=20 >> =3D=3D> There=92s RFC6192 talking about protecting control plane with rea= dy >> made examples of L3 and L4 ACLs for two vendors - it might be useful >> to reference that. >=20 > Will do. >=20 >=20 >=20 >> That would make this section talk about the ACLs, >> which might also make it worth reordering 4.1.x, e.g.: 4.1.4 then >> 4.1.3 then 4.1.1 then 4.1.2 - this way it flows from =91how the >> hardware performs lookups=92 to =91some of the lookups being done=92 to >> =91Why we need L4 ACLs=92 - and thus 4.2 would logically glue with the >> end of 4.1. >=20 > I'll come back to you regarding this one. >=20 >=20 >=20 >> "Communication between any two systems through to public network" >>=20 >> =3D=3D> seems like extraneous =93to=94 here >=20 > I'll s/to/the/ >=20 >=20 >=20 >> Page 8: >>=20 >> [I-D.ietf-6man-deprecate-atomfrag-generation] has recently proposed=20 >> to deprecate the generation of IPv6 atomic fragments, and update >> SIIT [RFC6145] such that it does not rely on ICMPv6 atomic >> fragments. Thus, any of the above mitigations would eliminate the >> attack vector without any interoperability implications. >>=20 >> =3D=3D> I see several issues here: >>=20 >> 1. Glancing through deprecate-atomfrag, seems there is a circular >> dependency of sorts: ehs-packet-drops document says the blackhole >> exists because the atomic fragments are generated/used, >=20 > The intent, at least, was to say that: >=20 > * widespread filtering of EHs means that packets with EHs may get blackhol= ed > * Atomic fragments represent probably the only case in which an attacker > can remotely trigger the use of EHs for a third party connection > * Hence, an attacker can trigger atomic fragments, such that the > widespread filtering of EHs essentially blackholes the target traffic. >=20 >=20 Ok thanks! >> and the >> deprecate-atomfrag says the problem exists because the atomic >> fragments are dropped. My understanding is that the dependency is >> that first the EHs are blocked by the network operator(s) for reasons >> unrelated to atomic fragments, >=20 > Agreed. >=20 >=20 >> which creates the blackhole >> preventable by not sending atomic fragments while continuing to block >> the EHs. >=20 > Agreed. >=20 >=20 >=20 >> 2. Really a comment for deprecate-atomfrag, but given the presence of >> this paragraph and its wording, I=92ll bring it up here: >> http://www.arkko.com/tools/allstats/citations-rfc6145.html shows >> quite a graph of dependencies that will be shaken upon a 6145 update. >> I didn=92t go through the list to see if there are protocol >> dependencies (4rd and MAP-T come to mind but maybe something else ?) >> - but a document proposing changing 6145 and asserting that there >> will be no interoperability implications needs to ensure that none of >> the dependencies get out of whack. >=20 > RFC6145 itself notes that atomic fragments are not reliable, and > proposes a workaround for that -- the big question, to me, is why such > workaround wasn't made "on by default". (RFC6145 itself contains stats > regarding how bad atomic fragments fail to be generated.). Some > implementations never generated them. Others, such as Linux, have > removed support for atomic fragments for a while now. Some FreeBSD > versions generate them, other's don't. >=20 > Bottom line: Can you rely on IPv6 atomic fragments, even in "controlled > environments"? -- No. Then have your protocol use something that can be > relied upon. In controlled environment you absolutely can. E.g. If you control map-t CPE w= hich sends the atomic frags and BR which receives them. We actually had to e= nable just this in one of the environments to make an application that uses I= P IDs work. >=20 > And, if you read atomfrag-deprecation, you'll see that the concrete > negative impact (security, performance, and reliability) outweighs the > possible benefits. >=20 >=20 Didn't do it yet - I suppose this means I just volunteered myself to read th= e doc - will do and write on 6man. >=20 >> 3. SIIT and friends can appear in different topologies, with some of >> the topologies being affected differently from the others, e.g. with >> MAP-T the atomic fragments are not ever leaving the service provider >> network, so the generation, filtering and processing is within the >> same admin domain. The difference in the impact might affect the >> policy decisions. >=20 > The question here is why you wouldn't design a protocol that is robust, > rather than one that works only in specific scenarios. >=20 >=20 I think same reason why people won't just write software that works perfectl= y - oversights, and limitations caused by the legacy.. >=20 >> So I=92d probably rephrase and have the paragraph say that full >> analysis is being done as part of deprecate-atomfrag, or something of >> sorts - or delete it all together. >=20 > I can leave with tweaking the text. Will get back to you regarding this on= e. >=20 >=20 >=20 >> Not sure. So take it FWIW. I=92ll >> need to carefully read the deprecate-atomfrag document to get a >> clearer opinion about the interaction of these two documents. >=20 > Please send any further comments whenever you have them. >=20 Oki - will send on 6man when I read it! Thanks for all the replies! --a > Thanks so much! >=20 > Best regards, > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 From nobody Fri Jan 8 14:49:07 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98FD11B2C6D for ; Fri, 8 Jan 2016 14:49:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=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 xQJQL6LmKXl4 for ; Fri, 8 Jan 2016 14:49:04 -0800 (PST) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B8A41B2C6C for ; Fri, 8 Jan 2016 14:49:04 -0800 (PST) Received: by mail-vk0-x232.google.com with SMTP id a123so168659230vkh.1 for ; Fri, 08 Jan 2016 14:49:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=fXzgxLMC7Kvr7nPM1T58ewjemZN3P6+WwhHs2hgz3HY=; b=gkuZbGEQcO6Z3DXTBHZOWQPe4T11JRLPQU6JMsk6ZCKP6AXc+X6as9hFB/4xr2CSGG 4xLB5Qga+JS+ZuTX74gloAcx19zAlmgHkIKVOF9TG/vFyxnaQ0lrBipVShFsOHp+1vYe 1xSAa6TT3/ViCcbW86pHZvc2K0FNMqZOuupGLug124Ng3rUh24laKIXBLnxAcLhSvlBX PN8LLNMHEf7+rjWTcLC40fSKXnB2USL2ku32i4qOFb868GNjW+qwzw+7dRdYJwUSU/rb Lvf3Qvw5KpxV6SRKW6h+gvCQihw7+ry7i0Lk5aa6G1pu063RMNoOFWAeaMn/EJTdcNf/ H1AA== X-Received: by 10.31.156.129 with SMTP id f123mr46689771vke.40.1452293343592; Fri, 08 Jan 2016 14:49:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.99.1 with HTTP; Fri, 8 Jan 2016 14:48:34 -0800 (PST) In-Reply-To: <568FC62B.2040109@gmail.com> References: <568E6552.9030008@gmail.com> <568EACE4.2070408@isi.edu> <568F8F37.3050708@gmail.com> <20160108.121015.74737501.sthaug@nethelp.no> <67D93E4D-714A-4566-A308-D9EFBB71C43B@puck.nether.net> <568FC62B.2040109@gmail.com> From: Mark Smith Date: Sat, 9 Jan 2016 09:48:34 +1100 Message-ID: To: Alexandre Petrescu Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: v6ops list Subject: Re: [v6ops] Routers are hosts too! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 22:49:05 -0000 On 9 January 2016 at 01:22, Alexandre Petrescu wrote: > > > > > Well, I agree. With a simple knob you get it. > > Exact match is useful for the search in the ND cache, or for the search in > Ethernet-related databases. But I did not mean to compare it to > longest-match. > > I wanted to say that a Host - as defined in RFC - does not implement > longest-match. > > A host as people call a laptop, a smartphone or a tablet does implement it > though. > I think that is probably because in part because either it has become a common convention to do that (I'd say Windows is an example), or that the OSes have origins of when routers were general purpose computers running general purpose OSes that could be used as routers with the flick of a switch. For example, looking at the text network Richard Steven's used in his TCP/IP Illustrated book, all of the routers in his network are Unix "hosts" with exception to one Cisco router. True "host only" processing might have been implemented on low end OSes for embedded devices, although Moore's law, and the corresponding explosion of the use of CPUs as they've got cheaper might have been making it cheaper to use more powerful embedded devices and a general purpose and much more widely used and supported OS, instead of less powerful embedded devices and a more specific and limited OS (i.e., the costs incurred of using more powerful hardware are mitigated by the savings made from using a widely used and supported OS). Regards, Mark. From nobody Fri Jan 8 15:31:02 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 920581B2C9A for ; Fri, 8 Jan 2016 15:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=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 PQcfT-jBiO5w for ; Fri, 8 Jan 2016 15:30:59 -0800 (PST) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58AA01B2C99 for ; Fri, 8 Jan 2016 15:30:59 -0800 (PST) Received: by mail-vk0-x233.google.com with SMTP id n1so45616242vkb.3 for ; Fri, 08 Jan 2016 15:30:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=m9xl/8CxDT5cLf1wYFUlQEqzT8BendE8eX8zpN9rqJ4=; b=z7xc8VM8/55U3/20q5LgscbDBoMCVl1tL+4DgtObvZ4epxT2dPn8mrgwCBcNDuz4dO Oe+3+/Vp+PEGs058V7nawMWmwrMzu+epNcJai0G5lyjq6svJ1BNh81DbsOrpm53F/h15 78A+cmwhClIbDnvox7KfhGt3dgGUAJ2FW/53Q9sGmMse2UFYdQxn6ELYuSH49tuTwAYz SG9fxmE0YM9K6+oqJie2JgdotZme+WhkktjsN66/XNh2/njlCXFLGWgM7VgXVSYJLdwI 9SzQm/Vq8LLCsFA+d+PwezD4LLvHSDllmEpp/v4AyzLsmYzxOYCGfi6jo8wWxYoS3g62 kqyw== X-Received: by 10.31.163.197 with SMTP id m188mr80806284vke.89.1452295858521; Fri, 08 Jan 2016 15:30:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.99.1 with HTTP; Fri, 8 Jan 2016 15:30:28 -0800 (PST) In-Reply-To: <568FD4BF.5080608@gmail.com> References: <568E6552.9030008@gmail.com> <568EACE4.2070408@isi.edu> <568F8F37.3050708@gmail.com> <20160108.121015.74737501.sthaug@nethelp.no> <67D93E4D-714A-4566-A308-D9EFBB71C43B@puck.nether.net> <568FC62B.2040109@gmail.com> <18838.74.139.119.34.1452263734.iglou@webmail.iglou.com> <568FD4BF.5080608@gmail.com> From: Mark Smith Date: Sat, 9 Jan 2016 10:30:28 +1100 Message-ID: To: Alexandre Petrescu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: v6ops list Subject: Re: [v6ops] Routers are hosts too! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 23:31:00 -0000 On 9 January 2016 at 02:24, Alexandre Petrescu wrote: > > > Le 08/01/2016 15:35, Jeff McAdams a =C3=A9crit : >> >> >> >> So what's your point? > > > Maybe we should find that small rounding error - what OS does not impleme= nt > longest-match and yet connects to the Internet? > > Second, until we ifnd that small rounding error, we may stop talking abou= t > Hosts, and declare the Host RFC historic. Or update it with a sentence > saying that Hosts too must implement longest-match. > So I think that might be missing the fundamental point I was making. The distinction between a host and a router is a functional one, purely related to what a device does when it receives a packet with a non-local address, rather than being an fixed attribute of a particular box of electronics. For example, a box of electronics having multiple physical interfaces doesn't always make it a router, or a box of electronics that only has a single physical interface doesn't always make it a host. I think the simple question to ask to determine whether the device is performing a host or a router function for a particular packet is "does the destination address in the packet match one of the receiving device's addresses?". If the destination address does, then the packet has reached its final destination, and the receiving device is a host and will process the complete packet. Another question to answer (which is more or less a rephrasing of the previous question), is "where is the packet payload care/don't care boundary?" If the device doesn't care what the packet payload is, it is a forwarding device i.e. a router. If the device does care what the payload is, because it is going to be processing the payload, then it is a host, and that means that the packet has reached the destination indicated in the destination address field. In the end-to-end argument, it is the ends that are processing payloads. A more specific version of that question is "does payload encryption matter to the device or not?". If payload encryption doesn't matter, then the device is a forwarding device/router, if payload encryption does matter, meaning that the receiving device needs to be in a position to decrypt the payload, then the device is a host, and the destination address in the packet matches one of the host's addresses. Regards, Mark. From nobody Fri Jan 8 15:47:19 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F18D71B2CAA for ; Fri, 8 Jan 2016 15:47:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 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, FREEMAIL_REPLY=1, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=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 xkSQbHHGRsgM for ; Fri, 8 Jan 2016 15:47:17 -0800 (PST) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E39D31B2CA9 for ; Fri, 8 Jan 2016 15:47:16 -0800 (PST) Received: by mail-vk0-x22b.google.com with SMTP id k1so200067763vkb.2 for ; Fri, 08 Jan 2016 15:47:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=dBsuVDkpEi8gUTLVYHocl3IirdpuUCOHvsAYl9eU3Jo=; b=DBtBLedltuhtM3Zl4YzudUUPAwlU6kjAONXtwTS1k1QSAqCBd2QDdg6r4Ytnps1rLz omM5AHPnB3ffRf7AGZpuwbOqihAak5wW3Aw0O2UoQUXVgOgwwd55QLjeyE2P46fvBkWk FZQTgqdr2T8mlNbpL3YyEiOAI2uQ4cy8uG13E9tuO85UeuK1oArSuiU6wl+PoPyPodAL aWYzy87Xw92zJ56P34y091TjZgb9pgxiqAdiOxP7Eq5UbH80r+wm1v60Xh4Z8kSvj3Ea xkEGGXid7Uxv9SflW4G3b69yfa/QuI9uL0BtzfF6ZWseV87zmi6lDgOBxffdBDP+0NPw CxkA== X-Received: by 10.31.163.197 with SMTP id m188mr80840838vke.89.1452296836086; Fri, 08 Jan 2016 15:47:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.99.1 with HTTP; Fri, 8 Jan 2016 15:46:46 -0800 (PST) In-Reply-To: <568FAA3B.3050108@gmail.com> References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <568D1854.7000300@gmail.com> <568FAA3B.3050108@gmail.com> From: Mark Smith Date: Sat, 9 Jan 2016 10:46:46 +1100 Message-ID: To: Alexandre Petrescu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 23:47:18 -0000 On 8 January 2016 at 23:23, Alexandre Petrescu wrote: > > > Le 06/01/2016 16:27, Lorenzo Colitti a =C3=A9crit : >> >> >> On Wed, Jan 6, 2016 at 10:36 PM, Alexandre Petrescu >> > >> wrote: >> >> >> Why? Consider the ULA use case where a host gets a /64 via DHCPv6 PD and >> uses this to assign a different IPv6 address to every process on the >> system. The host does not need to forward any packets to anyone on any >> interface, and thus is not a router. > > > In that case (ULA prefix for every process on the system), the system wou= ld > need to forward between processes in that sytem. That makes it a router. >> So if the definition of a router is forwarding between interfaces, then any host that implements the Weak Host Model (RFC1122, "Weak ES Model"), then it is not a host, it is a router, despite the name. I think the distinction between a router and a host is different. It isn't at the level of whether or not a packet received on one interface is conceptually sent to another interface inside the device. I think it is a simpler question - what does the device do with a packet who's destination address doesn't match one of its own? Drop it, making it a host, or see what the route table says to do with it, making it a router. From nobody Fri Jan 8 15:57:44 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796711B2CB9 for ; Fri, 8 Jan 2016 15:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, 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 dAHL6uzmjdam for ; Fri, 8 Jan 2016 15:57:40 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCD471B2CB1 for ; Fri, 8 Jan 2016 15:57:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4539; q=dns/txt; s=iport; t=1452297459; x=1453507059; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=PyQf1g3wh3FFiHGGEUHIFgRBVH4QfolEof5HxFOQi/A=; b=X9yeksDOuaNVciWUTJZXqzEj3RkBhU5LTjGtITEkWrsJCNFRrm3CnWsW rG+ufHMq4AvjmsFytj/9BW2EbAlQ77RonCrOYCtUC9Z+tkvJTdY8TZl8Q OBWXJWns9wpX2bM0Hnc6P3YH1AnsPKQ+Yz3Vo1ujZ224pGEKW3+5kaMld E=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAwBmTJBW/40NJK1UCoM6gUWIU7NLD?= =?us-ascii?q?oFkhg8CgRw4FAEBAQEBAQF/C4Q1AQEEeRACAU4yJQIEDhMGiBvCEwEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQ8JiGUIgWSFMIN1gRsFlw0BgnOBZYh/jnuOTQEgAUOCE?= =?us-ascii?q?RyBXYUIJB+BCAEBAQ?= X-IronPort-AV: E=Sophos;i="5.20,541,1444694400"; d="asc'?scan'208";a="225523191" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Jan 2016 23:57:39 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u08NvcAJ006801 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Jan 2016 23:57:39 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 8 Jan 2016 17:57:38 -0600 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1104.009; Fri, 8 Jan 2016 17:57:38 -0600 From: "Fred Baker (fred)" To: "v6ops@ietf.org" Thread-Topic: draft-ietf-v6ops-host-addr-availability and BCP status Thread-Index: AQHRSnBagwWzXwrP50eD3hdMg24VKA== Date: Fri, 8 Jan 2016 23:57:38 +0000 Message-ID: <554065B5-A26A-4703-BD75-CE392DB13A55@cisco.com> References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F99CEE@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3112) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.64.115] Content-Type: multipart/signed; boundary="Apple-Mail=_EF2CAF82-CE30-45E3-A3C2-B0B1EF5C654A"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: [v6ops] draft-ietf-v6ops-host-addr-availability and BCP status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 23:57:41 -0000 --Apple-Mail=_EF2CAF82-CE30-45E3-A3C2-B0B1EF5C654A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Speaking as chair, and hoping to guide this discussion. I am seeing a lot of discussion here that I think is pretty far afield = of what the working group said it wanted a working group BCP draft to = describe. That purpose was, in essence, to ask network operators, = mobile, enterprise, and ISP, to permit hosts in their networks to have = multiple addresses from the same prefix in use on an interface, = consistent with RFC 4291 section 2.1. Operationally, we have a *lot* of experience with the allocation of = multiple temporary and permanent addresses from the prefix used in a LAN = subnet to a physical or virtual host, using SLAAC; where this draft = started out, I understood it to ask that the same thing be possible and = supported using DHCP or other address allocation technologies, and for = operators provisioning networks to act accordingly. That is actually an = important point, one I had to clarify with a Cisco colleague from a = product perspective just this week. If virtual machines or containers are in view, I'm not sure I see a lot = of difference between a physical router in a data center infrastructure = and a virtual router located in the physical host the virtual machines = are in, and therefore between the use of DHCP-PD in a router that is = physical vs one that is virtual. I see a lot of stuff floating around = reinventing the wheel for virtual systems; I tend to think we can = simplify a lot of that by conceptually erasing the distinction - a = router is a router, and a host is a host, whether physical or virtual, = and (whatever the implementation issues might be) the specifications we = write for them should be the same. =46rom that perspective, if we have = experience with DHCP-PD on routers, the expansion to virtual routers in = the physical host is a very small step, and I don't see what the hubbub = is about. What we don't have a lot of experience with is assigning a prefix to a = host and using addresses from it to identify (clusters of) application = instances without the container/virtual machine context. We don't need to tell the host what to do with the prefix assigned to = it, or (IMHO) even what size that prefix should be... This is about = network provisioning. So it seems to me that the experience question devolves to wanting to = let the technology that erases the virtual machine/container and simply = applies addresses to applications percolate, but make a comment on that = which we in fact have experience on - the use of DHCP-PD by routers = (physical or virtual), and the allocation of multiple addresses in the = same prefix to a host. This entire discussion seems to me to be trending far afield of the = initial purpose of the document, to the point that we have substantive = calls to reduce its proposed status from BCP to Informational and refer = to technologies that are at experimental status and not widely deployed = by operators in this community. I think the working group's consensus in = adopting the draft is better served if we can identify those factors = that are in fact describable as "Best Current Practice", and make the = draft target those. --Apple-Mail=_EF2CAF82-CE30-45E3-A3C2-B0B1EF5C654A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBVpBM8EayAOS/EQ8MAQL92A//WbTJ74TO3gCMFyuK0Z3AugcSs9yRoAm8 oRX6wcJu4LRZFygZE+pQUHvZBwGLxra38Io4whaRchCSh6WlP+ORQWcOubDx+2se EumpCg52wEGVfGuTcRaCG2IYov9WTnITefh8WBtI75jvDKZSnlDLsJ01+zadWCuP 2dhKA7N4RCLG89bI5txkmWujBBmrE0RrIPCpepea05L4ZPJ1Nz9/tLEoPUQ2XOsr Xy11bU3cVbke4yAne61lgPrFnLrDMcnvemzQjsFYlAhAfzn3/gUzls5+wpLJPv7b cVDYV1tDNRDzVOsfif2/DcgAFWAsMC+cgwTV5PAZYo3vT10Jib2/qthQTvrvpRyW N8Up/DAW7OaCDB/izz1coxcjJRxzlr0lQTNcmIl7xk/TNTmbmEiP8BjIm/l7Vlg0 swWrs9gOSBuT3hkWr6EgDPB8VYff56PneKbCQVikdU30Uz33Qq2y5dXn9Eh4MpZ0 qtdhgMyP8Z+UVv3tZer9xq7rMaX7G/2EurbdQ9w1irywPWSHd3jAkN6hWYyTGIY8 BUDeJT1iryV1fAgPR6ZMBtmJIa2MCD+yzccT3p2x5a9X5BpXhzuQu8w73AAP0cIp +/dXJr+4Vs5AVqdhbeMV8puT9Ierl7+w6ali8pR8afIbDOkb6xfxmr2yARbBDxbT O/pp6Zxpo7A= =YK2u -----END PGP SIGNATURE----- --Apple-Mail=_EF2CAF82-CE30-45E3-A3C2-B0B1EF5C654A-- From nobody Fri Jan 8 18:17:39 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 003ED1A00AE for ; Fri, 8 Jan 2016 18:17:38 -0800 (PST) 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 87zYBbOrKYHz for ; Fri, 8 Jan 2016 18:17:36 -0800 (PST) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 397271A00AC for ; Fri, 8 Jan 2016 18:17:36 -0800 (PST) Received: by mail-pa0-x231.google.com with SMTP id uo6so273436751pac.1 for ; Fri, 08 Jan 2016 18:17:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=kFhVyYH/M75rpBgkU4Fj77ZJOmEEmOr2PGzt+qQwZms=; b=LtkFMQmOkc0vWoLxbav6oKZfeADNbci/Lz9UI28MrPgv/2EwpBYrPOmuZgPV8acLL2 nkfNyfYKVPyDYY0n+IDB4JODsiqW/Mb6dY9RZR+7PO1zLaD/q8kWAwP4nmkwAwLHFmsb Nl1iLOefjJr3/LjgZMcNtHKXnPPGEXkuAmIy2Zj3zIrC8hGDJEszmVPpmlh1ZMiHBf3v 7tColSc/UbuTTfw2o3WACUyWwcTMyaRZ5YDtX8BfM5AZXJYn3qjzmFfeyoHyL9KLlUab Kmbjk1zH1J6Z2hL40wXfPpJ/+Ghpv+vnkq+v5ZPGOtGguezxv0Z1xXSTe9V+YSfrwR2R GQyQ== X-Received: by 10.66.161.133 with SMTP id xs5mr161759409pab.70.1452305855903; Fri, 08 Jan 2016 18:17:35 -0800 (PST) Received: from ?IPv6:2406:e007:4492:1:28cc:dc4c:9703:6781? ([2406:e007:4492:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id by2sm115859517pab.6.2016.01.08.18.17.31 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Jan 2016 18:17:34 -0800 (PST) To: "Fred Baker (fred)" , "v6ops@ietf.org" References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F99CEE@XCH-BLV-504.nw.nos.boeing.com> <554065B5-A26A-4703-BD75-CE392DB13A55@cisco.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56906DD9.8040909@gmail.com> Date: Sat, 9 Jan 2016 15:18:01 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <554065B5-A26A-4703-BD75-CE392DB13A55@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability and BCP status X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2016 02:17:38 -0000 Fred, IMHO you are 100% correct, and most of the recent discussion is way off the point. Brian On 09/01/2016 12:57, Fred Baker (fred) wrote: > Speaking as chair, and hoping to guide this discussion. > > I am seeing a lot of discussion here that I think is pretty far afield of what the working group said it wanted a working group BCP draft to describe. That purpose was, in essence, to ask network operators, mobile, enterprise, and ISP, to permit hosts in their networks to have multiple addresses from the same prefix in use on an interface, consistent with RFC 4291 section 2.1. > > Operationally, we have a *lot* of experience with the allocation of multiple temporary and permanent addresses from the prefix used in a LAN subnet to a physical or virtual host, using SLAAC; where this draft started out, I understood it to ask that the same thing be possible and supported using DHCP or other address allocation technologies, and for operators provisioning networks to act accordingly. That is actually an important point, one I had to clarify with a Cisco colleague from a product perspective just this week. > > If virtual machines or containers are in view, I'm not sure I see a lot of difference between a physical router in a data center infrastructure and a virtual router located in the physical host the virtual machines are in, and therefore between the use of DHCP-PD in a router that is physical vs one that is virtual. I see a lot of stuff floating around reinventing the wheel for virtual systems; I tend to think we can simplify a lot of that by conceptually erasing the distinction - a router is a router, and a host is a host, whether physical or virtual, and (whatever the implementation issues might be) the specifications we write for them should be the same. From that perspective, if we have experience with DHCP-PD on routers, the expansion to virtual routers in the physical host is a very small step, and I don't see what the hubbub is about. > > What we don't have a lot of experience with is assigning a prefix to a host and using addresses from it to identify (clusters of) application instances without the container/virtual machine context. > > We don't need to tell the host what to do with the prefix assigned to it, or (IMHO) even what size that prefix should be... This is about network provisioning. > > So it seems to me that the experience question devolves to wanting to let the technology that erases the virtual machine/container and simply applies addresses to applications percolate, but make a comment on that which we in fact have experience on - the use of DHCP-PD by routers (physical or virtual), and the allocation of multiple addresses in the same prefix to a host. > > > This entire discussion seems to me to be trending far afield of the initial purpose of the document, to the point that we have substantive calls to reduce its proposed status from BCP to Informational and refer to technologies that are at experimental status and not widely deployed by operators in this community. I think the working group's consensus in adopting the draft is better served if we can identify those factors that are in fact describable as "Best Current Practice", and make the draft target those. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Fri Jan 8 21:15:46 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B32E1A066C for ; Fri, 8 Jan 2016 21:15:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.47 X-Spam-Level: ** X-Spam-Status: No, score=2.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FRT_PROFIT1=3.858, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 6NDtC_zpAymT for ; Fri, 8 Jan 2016 21:15:43 -0800 (PST) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E61231A0469 for ; Fri, 8 Jan 2016 21:15:42 -0800 (PST) Received: by mail-yk0-x233.google.com with SMTP id a85so306504272ykb.1 for ; Fri, 08 Jan 2016 21:15:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=TR9vSVR0rb4jF0ISSsUIn9PqeLQsMSvPvZZCOzBzFk0=; b=dvUjiuzX9GsnZLUn1Sf8z8OagfFWDg7LvnDChmGsypmHxJdQe6wfuRb1QDJLbJbpLI RSGCwjaos5vAmAX7IbgfcaX2sE8EiDTslTAQ20Qof8yy+ptmJFt6nZtuj9eYLF8oRtK5 Ojua3Rk8aiOQNYOF6Z+hBp/8WhPhLnYuzMuQIwAGTYpFejnqc2+jRsTB3cfp1CW8W8ry G0XPOhhTsDhRkE/JIWhSOWVy7E4afa9rt1Q5x6jLZPY18MhoIhbtasdxz57aJRZwp0AB fA2C44fZszNA8fcrX21+CC34VZvnStbzeQVk29DckBa3rxesZrHwhq6vByNsz/LQAacI wwSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=TR9vSVR0rb4jF0ISSsUIn9PqeLQsMSvPvZZCOzBzFk0=; b=NVDPMfgcYXZ0M4XKgC3vNI1FqfDK1dqJ4mrIluwpeOUZKaFg1RqxqX6CbdhLcLe/Hv IEYW2Yze86pm/JuLmIIZqAlr+vH8v4xgpiaEJfNHFVnJgrSzN7VPuAPvEKC0xscliaJv ZD04iHcl1YL1xp9VIWwbohqOrH/4sRPuweGWy6j3C2NR4uQJnI90X80IN7vD4Kg2yCfA qdbH2W5vCmqJ80rWciXIBLtToOIJJvEWuwxLOASaaTAWomNHj8DRmOlz9Vr9dVh0j2Py 8vROdHQscXzLZDSoZjqunYAe+DImADLxhTNLMhVzY5X0jYF/WLZoa/Fwb+BgjzL8FrBC zUQQ== X-Gm-Message-State: ALoCoQlPv3fLLAM9uFrd5OGWntqXdiGZpCfFuuyGHDfPM/A2eb1s8lOERs95OFWXjBKTWua8zqtJa1ZD3zkat65m7x6jjYmNEAxGp/aupPcfCbq7n50hEfo= X-Received: by 10.129.41.17 with SMTP id p17mr83052396ywp.160.1452316541956; Fri, 08 Jan 2016 21:15:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.208.201 with HTTP; Fri, 8 Jan 2016 21:15:21 -0800 (PST) In-Reply-To: <568FAA3B.3050108@gmail.com> References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <568D1854.7000300@gmail.com> <568FAA3B.3050108@gmail.com> From: Lorenzo Colitti Date: Sat, 9 Jan 2016 14:15:21 +0900 Message-ID: To: Alexandre Petrescu Content-Type: multipart/alternative; boundary=001a11407ee89639180528dfcb21 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2016 05:15:44 -0000 --001a11407ee89639180528dfcb21 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 8, 2016 at 9:23 PM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > Why? Consider the ULA use case where a host gets a /64 via DHCPv6 PD and >> uses this to assign a different IPv6 address to every process on the >> system. The host does not need to forward any packets to anyone on any >> interface, and thus is not a router. >> > > In that case (ULA prefix for every process on the system), the system > would need to forward between processes in that sytem. That makes it a > router. > No: even in the RFC 2460 definition of router, a node is a router if it forwards packets "not addressed to itself". All these packets are addressed to different applications on the node itself. If I had not specified -I, someone would have said "there is no proof >> that this works, your laptop could have been using another address, one >> that was not obtained via DHCPv6 PD". :-) >> > > One can give a proof it works by copy/paste the ping output - it tells the > src and dst addresses. > > One another hand, does that ping work w/o saying -I? I guess not. > It does work, but it would have preferred one of the addresses assigned to eth0 instead of the address I manually assigned to lo. If I didn't have an address on eth0 via SLAAC, it would have worked and chosen the lo address. --001a11407ee89639180528dfcb21 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jan 8, 2016 at 9:23 PM, Alexandre Petrescu <alexandre.petre= scu@gmail.com> wrote:
Why? Consider the ULA use case w= here a host gets a /64 via DHCPv6 PD and
uses this to assign a different IPv6 address to every process on the
system. The host does not need to forward any packets to anyone on any
interface, and thus is not a router.

In that case (ULA prefix for every process on the system), the system would= need to forward between processes in that sytem.=C2=A0 That makes it a rou= ter.

No: even in the RFC 2460 definitio= n of router, a node is a router if it forwards packets "not addressed = to itself". All these packets are addressed to different applications = on the node itself.

If I had not specified -I, some= one would have said "there is no proof
that this works, your laptop could have been using another address, one
that was not obtained via DHCPv6 PD". :-)

One can give a proof it works by copy/paste the ping output - it tells the = src and dst addresses.

One another hand, does that ping work w/o saying -I?=C2=A0 I guess not.
=

It does work, but it would have preferred = one of the addresses assigned to eth0 instead of the address I manually ass= igned to lo. If I didn't have an address on eth0 via SLAAC, it would ha= ve worked and chosen the lo address.
--001a11407ee89639180528dfcb21-- From nobody Fri Jan 8 22:19:26 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27B191A1A69 for ; Fri, 8 Jan 2016 22:19:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-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 allP_sP_Btcv for ; Fri, 8 Jan 2016 22:19:23 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1473B1A1A67 for ; Fri, 8 Jan 2016 22:19:23 -0800 (PST) Received: from [75.211.99.83] (83.sub-75-211-99.myvzw.com [75.211.99.83]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u096Iit1028328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 8 Jan 2016 22:18:47 -0800 (PST) To: Mark Smith , Alexandre Petrescu References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <568D1854.7000300@gmail.com> <568FAA3B.3050108@gmail.com> From: Joe Touch Message-ID: <5690A640.1020009@isi.edu> Date: Fri, 8 Jan 2016 22:18:40 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2016 06:19:24 -0000 On 1/8/2016 3:46 PM, Mark Smith wrote: > So if the definition of a router is forwarding between interfaces, Forwarding between interfaces involves receiving a packet on one interface and emitting it on another. > then any host that implements the Weak Host Model (RFC1122, "Weak ES > Model"), then it is not a host, it is a router, despite the name. The weak host model involves receiving a packet on one interface and interpreting that as receiving the packet on another interface. There's no emitting going on. The weak model simply interprets addresses as belonging to the host rather than the interface. FWIW, most Internet stacks implement a strong link layer and a weak network layer, but there are notable exceptions to both. (Fred: though I agree this is afield from the original thread, I find it hard to understand how a coherent discussion about host addressing can occur given the confusion about what a host is on this list) Joe From nobody Fri Jan 8 22:27:22 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B820B1A1A7C for ; Fri, 8 Jan 2016 22:27:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-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 wbnbDrx9scLT for ; Fri, 8 Jan 2016 22:27:18 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9ADB1A1A8B for ; Fri, 8 Jan 2016 22:27:18 -0800 (PST) Received: from [75.211.99.83] (83.sub-75-211-99.myvzw.com [75.211.99.83]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u096QtJN000308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 8 Jan 2016 22:26:57 -0800 (PST) To: Alexandre Petrescu , v6ops@ietf.org References: <568E6552.9030008@gmail.com> <568EACE4.2070408@isi.edu> <568F8F37.3050708@gmail.com> <20160108.121015.74737501.sthaug@nethelp.no> <67D93E4D-714A-4566-A308-D9EFBB71C43B@puck.nether.net> <568FC62B.2040109@gmail.com> <18838.74.139.119.34.1452263734.iglou@webmail.iglou.com> <568FD4BF.5080608@gmail.com> <4129.74.139.119.34.1452267772.iglou@webmail.iglou.com> <568FDE34.1060003@gmail.com> From: Joe Touch X-Enigmail-Draft-Status: N1110 Message-ID: <5690A82F.5020007@isi.edu> Date: Fri, 8 Jan 2016 22:26:55 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <568FDE34.1060003@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [v6ops] Routers are hosts too! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2016 06:27:19 -0000 On 1/8/2016 8:05 AM, Alexandre Petrescu wrote: > RFC1122 "Reqs for Internet Hosts -- Communication Layers" does not > mention longest-prefix match. Section 3.3.2.3 (source address selection) refers to Section 3.3.1, which includes a set of mechanisms in Section 3.3.1.2 for selecting among multiple gateways. Note that this algorithm involves using a route cache with ICMP redirects that help the system learn the "best" (quote from the RFC) next-hop. Those entries are described in terms of host routes, but there is a discussion about aggregating those entries in 3.3.1.3. The net result of that aggregation is effectively longest-prefix matching. So you're strictly correct - RFC1122 does not require longest prefix, but a large number of entries in the route cache is more effectively handled as such. Joe From nobody Sat Jan 9 05:07:38 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2E71A870E for ; Sat, 9 Jan 2016 05:07:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 52Ir8NpZzEYX for ; Sat, 9 Jan 2016 05:07:34 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0096.outbound.protection.outlook.com [104.47.1.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 564451A870B for ; Sat, 9 Jan 2016 05:07:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/5GbA1o9eSfoyT79Wop9TbHpp/VGylOP5zew3Eogrz0=; b=JjW3NBGQ7hZATiK7GbFAGqBseSWM4/B0BHG98sjsnKmzoDfeoJmzXq5Q5m8UkEsq+jGSMv/QQdyISgsXw2FmnI76LH7ywJr03Tyapan+94XDM1FHmZFLnIelCaIX1t+K9CTwLIXBbB0/F5hZMqS37kE0WbjCEUH66kmW9tM/jB0= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (86.185.87.133) by DBXPR07MB061.eurprd07.prod.outlook.com (10.242.147.14) with Microsoft SMTP Server (TLS) id 15.1.361.13; Sat, 9 Jan 2016 13:07:30 +0000 Message-ID: <03a301d14ade$57cb6e40$4001a8c0@gateway.2wire.net> From: t.petch To: Alexandre Petrescu , , Joe Touch References: <568E6552.9030008@gmail.com> <568EACE4.2070408@isi.edu> <568F8F37.3050708@gmail.com> <20160108.121015.74737501.sthaug@nethelp.no> <67D93E4D-714A-4566-A308-D9EFBB71C43B@puck.nether.net> <568FC62B.2040109@gmail.com> <18838.74.139.119.34.1452263734.iglou@webmail.iglou.com> <568FD4BF.5080608@gmail.com> <4129.74.139.119.34.1452267772.iglou@webmail.iglou.com> <568FDE34.1060003@gmail.com> <5690A82F.5020007@isi.edu> Date: Sat, 9 Jan 2016 13:04:41 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.185.87.133] X-ClientProxiedBy: DB3PR05CA0026.eurprd05.prod.outlook.com (25.160.41.154) To DBXPR07MB061.eurprd07.prod.outlook.com (10.242.147.14) X-Microsoft-Exchange-Diagnostics: 1; DBXPR07MB061; 2:P+LG1nJ5RwvgmXdMTDSCGZ7Ezhfp0CR0j/X4uSNrd5a+RV5sPsusSkErZdjYxZyYj0GT+w+O6Wi2F83g9ihRmIm1eHdicDgUcqqtQXKZtD/WTkpsbjFgfo64PAf9XjgnepD0k2krEHZmdNcK/FhWuA==; 3:AaJbkgqT2A/N7xoSXZW3m6y3z5/WgW3yIHjh9+g0Mol2C6RMv1aOqNcrcuwhP5eyPDfOyyZmbdaBx+4jQzBbSIY6eQVS8z1KL2hXv1l0Z6dGuqMaodNvL6nDWUNM3xqk; 25:X4rw1SyT0hVPUlHrs+8idx6kZecTjIk5wHXBYdLZY2wO/BbU+1RCFcYCoxktLjK3cqtRFQ/RGZpKu48KK4msUaQsODLIafWS+75pKWL7D56Xpee5JLCFY6CivJLbdsdpEFmL8Oa/9KzDNGaC0qF/RBqYFh5BV7AFMFfjOqT2KHrHYlScngFP7sOIiIBJs5PWyg/5DTGTxTioeT3xIb8s7sbQOsj7/S9E9hsaSMuxtMl0R3YFILWvosYmCK7Pih+/; 4:DhyhCTV5uDWkwGivKUraXFD9tKA6KDl6mIsuk90pClgsvjMZ1512/VGsxWYU+ADDBLCz2EfLXzOkh5OQ8oh6vEqdRC2nhJfLlI9LLmUAYivSMqV1RS6SIijGwWMxcSinNN8sYFVji5q88l7RsvTJMN07uhfY3Zvv1GZjU5M3+kJE14/P9m3kp82LO1Jx9ff3gZd7IfuwW72m18b2ra9/ZuPpPsHK1EbJZrJ2TPcUuC/hsG8LTpalKDsyzLSVwHPkAos+/VxTa9av2O4Yqfv9dcdnhW/0oC6GjDV1h807W79RhZiY6G5CftyoVRUwLmQkSCCDCwOoMnzDwz6hktPBNqBlrmhkt599KlQB7TVa0lv6XUhxDSCNd4XK7vRxU6to X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB061; X-MS-Office365-Filtering-Correlation-Id: 1e24a509-df6c-49ce-ed85-08d318f5d4b5 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(3002001)(10201501046); SRVR:DBXPR07MB061; BCL:0; PCL:0; RULEID:; SRVR:DBXPR07MB061; X-Forefront-PRVS: 0816F1D86E X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(13464003)(24454002)(377454003)(199003)(189002)(84392002)(5001960100002)(61296003)(19580395003)(106356001)(1456003)(76176999)(62236002)(81816999)(3846002)(105586002)(81686999)(1096002)(230700001)(33646002)(50466002)(44736004)(107886002)(77096005)(66066001)(5008740100001)(2906002)(6116002)(2171001)(19580405001)(586003)(44716002)(47776003)(97736004)(23756003)(40100003)(5001770100001)(189998001)(86362001)(50986999)(50226001)(1556002)(116806002)(5004730100002)(87976001)(42186005)(14496001)(92566002)(101416001)(226693001)(93886004)(81156007)(122386002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB061; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DBXPR07MB061; 23:1igoDdCsr1+BJv6/SvPb3HxrKxPHyX84Z3+EchkI?= =?iso-8859-1?Q?nJgBE51s5eewekQs9wLwWUTZGckpszi2sqTUgEQntNgFmqGCxbVla2PsLn?= =?iso-8859-1?Q?2kYNAMWpk4F3A8rlMiVqrcTH1eb0Ae5mFB5OdS0FH50dU7IMl4x3Qc7ibe?= =?iso-8859-1?Q?OaaYapjKTFbT4Pjp5P3bB1sF/IWjoht6bonlGfeecHQVm6dV7soMtIE7XB?= =?iso-8859-1?Q?d37+8fodnFZfOypiaa54zNbqUQP8mHj38e6ObEkICVDeIDJBjVo4ArJMSM?= =?iso-8859-1?Q?5JwdbVl8ayWi4/yBC0SGZ0WmTSUJzGm/4idHAVcqgih7g3idkK/z65wri2?= =?iso-8859-1?Q?sn6BBEUm3qRCsICvHtyACdNRvub5V1TB0Bn6Tzd+8eECkQHYpGyEsSo7+y?= =?iso-8859-1?Q?V8ulKysiNSY0cG6ntOwVVtQNTavF42X4K4bw9wk7xuYXr+dAyINeS2peXx?= =?iso-8859-1?Q?VY8cGpy0iMPGHQ6mUx/lIjOl9QiqlD/sU+vQmkXFYKi9cCbrGBWgwMqClk?= =?iso-8859-1?Q?oHniUIUyR4QvZr3SQYSJlG5lyfqvZQIiYiUmhLUokwFIUkW0Gg4Zw3CtlP?= =?iso-8859-1?Q?yevX7D0caL6x/NRlbJopvqPcL+4+CD0cZQwg7Z1OCxBK6T5+ezaYJPbx1k?= =?iso-8859-1?Q?8mSaZVSJMEYii3QQRSbqXitIi9oSukI2VhEha4YWwbMSbrV8h4oNGLUo66?= =?iso-8859-1?Q?bONvEVmlnNXeS9+Q5RNN7ZkxsEiv9qnJmiyjWCfGyPKq1K+WgG0uE93PWB?= =?iso-8859-1?Q?cy4kz2NER2SgXJx85u9Xk5qkKVkpB6plJGVmcjeZhPBn2QsBy6dXPBX1c5?= =?iso-8859-1?Q?c3RNYBbk3VDADoeEon9ymJQt/C0CZiZH1G2R0rlvQyVM0S6XrPRO8ZrQTi?= =?iso-8859-1?Q?T1KkNHf3yKGz+lozlMTREVMeMQLoJK3KYjLbYDqSNuRib2SKRAP2qbI3/I?= =?iso-8859-1?Q?AUYpDZwZvMSCitDHbcKTRHcPKfvZT7g/WWDmmE/gdnTvVQCz+ZJzP61ooE?= =?iso-8859-1?Q?VuM1yhrrRk9J7/xn2Aua3UHk4Bt3fT/UvmsHCFhe37WQJuh6L91DSZ5Wzd?= =?iso-8859-1?Q?bz2r9OgFLAT4n3X6KYxs5tPJQpN2gvDbnzZYaYuVzKulYmwL/N5BM9Y6NF?= =?iso-8859-1?Q?XypkpwARduIbYgjg6PJNs4WHIjI5t8/zlKYnGjkFHCf2Ty9xDD91bqxQsc?= =?iso-8859-1?Q?Ix9FaByhIvK0usAZRiCmi7tEx682f59E59PjCK9ltc7Qh8QB83HHOgoAhs?= =?iso-8859-1?Q?lmtp2fphmeq0bOOoKXmJiW93aPenXwzsPQ/qmWxuKFNcpdCCUUzJG+o1W7?= =?iso-8859-1?Q?SzKyeNBczMdIHzc0AjzbFjvIBm37EIKBvZhcFIZQ/kladPqWOaRzERoflD?= =?iso-8859-1?Q?m2PAdGaH01GaBlVJvY02ZBRKc5kqrTKuFQJR8/y7SnPBu/WmaSgwAg3qWB?= =?iso-8859-1?Q?SMnLaVTo6ZmzPr7R5M4NX7vf7B8eJVmGXRqFcv1R/k6BbZ6BhkCkK8tA?= =?iso-8859-1?Q?=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; DBXPR07MB061; 5:3qACwHQAJHKQ+8cT3Nrp74tkHYvlWVvTEB0rx91ElhFOtni9pQLplrsKO8tuoSswWKv4YFnXZRoD3tTd8z8nHfTSkfUSLth2c7VJ3z1BIHGPkL1E+3Kgjh0nqW0IPFW7g73ZAMdidqw281jbYtM48Q==; 24:79Rq+lzARPcSKGtiCO5Bl1tDvMJU6Ama4tq9euZqAP2wRxdedeODtkeLGx4JVRk3EKsUkjLbRYO0Rqreew285zbr4McqpLZiE6avClWj8Ek= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jan 2016 13:07:30.2090 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB061 Archived-At: Subject: Re: [v6ops] Routers are hosts too! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2016 13:07:37 -0000 ----- Original Message ----- From: "Joe Touch" To: "Alexandre Petrescu" ; Sent: Saturday, January 09, 2016 6:26 AM > On 1/8/2016 8:05 AM, Alexandre Petrescu wrote: > > RFC1122 "Reqs for Internet Hosts -- Communication Layers" does not > > mention longest-prefix match. > > Section 3.3.2.3 (source address selection) refers to Section 3.3.1, > which includes a set of mechanisms in Section 3.3.1.2 for selecting > among multiple gateways. > > Note that this algorithm involves using a route cache with ICMP > redirects that help the system learn the "best" (quote from the RFC) > next-hop. Those entries are described in terms of host routes, but there > is a discussion about aggregating those entries in 3.3.1.3. > > The net result of that aggregation is effectively longest-prefix matching. > > So you're strictly correct - RFC1122 does not require longest prefix, > but a large number of entries in the route cache is more effectively > handled as such. But then RFC1122 does not mention classless addressing or Variable Length Subnet Masks - as I recall, they did not exist at that time. Rather, RFC1122 deals with 32 bit Host addresses and Classful Networks, ie 8 or 16 or 24 bit addresses, so while you might have more than one entry in the cache for a given destination, they will all be the same length so the concept of longest-prefix (and of course, the term prefix has no meaning at that date) match does not come into consideration. Tom Petch > Joe > From nobody Sat Jan 9 08:20:21 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E70301A888A for ; Sat, 9 Jan 2016 08:20:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.31 X-Spam-Level: X-Spam-Status: No, score=-6.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-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 ngDVQass-kGW for ; Sat, 9 Jan 2016 08:20:18 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5CA11A8887 for ; Sat, 9 Jan 2016 08:20:18 -0800 (PST) Received: from [10.213.221.183] (mobile-166-170-051-011.mycingular.net [166.170.51.11] (may be forged)) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u09GJq4R003521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 9 Jan 2016 08:20:03 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPhone Mail (13C75) In-Reply-To: <03a301d14ade$57cb6e40$4001a8c0@gateway.2wire.net> Date: Sat, 9 Jan 2016 08:19:52 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <568E6552.9030008@gmail.com> <568EACE4.2070408@isi.edu> <568F8F37.3050708@gmail.com> <20160108.121015.74737501.sthaug@nethelp.no> <67D93E4D-714A-4566-A308-D9EFBB71C43B@puck.nether.net> <568FC62B.2040109@gmail.com> <18838.74.139.119.34.1452263734.iglou@webmail.iglou.com> <568FD4BF.5080608@gmail.com> <4129.74.139.119.34.1452267772.iglou@webmail.iglou.com> <568FDE34.1060003@gmail.com> <5690A82F.5020007@isi.edu> <03a301d14ade$57cb6e40$4001a8c0@gateway.2wire.net> To: "t.petch" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Routers are hosts too! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2016 16:20:20 -0000 > On Jan 9, 2016, at 5:04 AM, t.petch wrote: >=20 > ----- Original Message ----- > From: "Joe Touch" > To: "Alexandre Petrescu" ; > > Sent: Saturday, January 09, 2016 6:26 AM >=20 >>> On 1/8/2016 8:05 AM, Alexandre Petrescu wrote: >>> RFC1122 "Reqs for Internet Hosts -- Communication Layers" does not >>> mention longest-prefix match. >>=20 >> Section 3.3.2.3 (source address selection) refers to Section 3.3.1, >> which includes a set of mechanisms in Section 3.3.1.2 for selecting >> among multiple gateways. >>=20 >> Note that this algorithm involves using a route cache with ICMP >> redirects that help the system learn the "best" (quote from the RFC) >> next-hop. Those entries are described in terms of host routes, but > there >> is a discussion about aggregating those entries in 3.3.1.3. >>=20 >> The net result of that aggregation is effectively longest-prefix > matching. >>=20 >> So you're strictly correct - RFC1122 does not require longest prefix, >> but a large number of entries in the route cache is more effectively >> handled as such. >=20 > But then RFC1122 does not mention classless addressing or Variable > Length Subnet Masks - That was introduced 200 RFCs later. =20 > as I recall, they did not exist at that time. > Rather, RFC1122 deals with 32 bit Host addresses and Classful Networks, > ie 8 or 16 or 24 bit addresses, so while you might have more than one > entry in the cache for a given destination, they will all be the same > length so the concept of longest-prefix (and of course, the term prefix > has no meaning at that date) match does not come into consideration. You can still do longest match for classful routing. =20 Where the gist aggregates these route chache entries and how is up to them, b= ut the alternative is a nonscalable set of host routes=20 Joe >=20 > Tom Petch >=20 >> Joe >>=20 From nobody Sat Jan 9 17:24:17 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5550B1A6EFB for ; Sun, 3 Jan 2016 23:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.011 X-Spam-Level: X-Spam-Status: No, score=-5.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 2FlPJ6wqJoMS for ; Sun, 3 Jan 2016 23:49:11 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AADFB1A6EF9 for ; Sun, 3 Jan 2016 23:49:11 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id CB488F3AF4879; Mon, 4 Jan 2016 07:49:07 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u047n9OE011356 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Jan 2016 08:49:09 +0100 Received: from FR711WXCHMBA06.zeu.alcatel-lucent.com ([169.254.2.12]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Mon, 4 Jan 2016 08:49:09 +0100 From: "VAN DE VELDE, Gunter (Gunter)" To: Lorenzo Colitti , "draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org" Thread-Topic: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host Thread-Index: AQHRRrIE1AJWfg9CNUOFmoSBK+04DZ7q+2OA Date: Mon, 4 Jan 2016 07:49:08 +0000 Message-ID: <336255C7-CC6E-43EC-AE53-F771D91703D5@alcatel-lucent.com> References: <201601031900.u03J0LMe009763@irp-lnx1.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: multipart/alternative; boundary="_000_336255C7CC6E43ECAE53F771D91703D5alcatellucentcom_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Sat, 09 Jan 2016 17:24:15 -0800 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 07:49:13 -0000 --_000_336255C7CC6E43ECAE53F771D91703D5alcatellucentcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PD5zbmlwPD4NCkkgZG9uJ3QgdW5kZXJzdGFuZCB0aGUgdGV4dCAiVG8gYWNjb21vZGF0ZSB0aGlz IHRoZSBXTEFOLUdXIGNhbiBwZXJpb2RpY2FsbHkgcGVyZm9ybSBhIFN1YnNjcmliZXIgSG9zdCBD b25uZWN0aXZpdHkgVmVyaWZpY2F0aW9uIChpLmUuIHBlcmlvZGljYWxseSBwaW5nIGVhY2ggSVB2 NiBVRS4uLikiLiBJdCBzZWVtcyB0byBtZSB0aGF0IHRoZSB0aGUgd2hvbGUgcG9pbnQgb2YgdGhp cyBhcHByb2FjaCBpcyB0aGF0IHRoZSBXTEFOLUdXIGRvZXNuJ3QgbmVlZCB0byBrbm93IHRoZSBp bmRpdmlkdWFsIElQdjYgYWRkcmVzc2VzIGZvcm1lZCBieSB0aGUgaG9zdHMuIEFsc28sIHRoZXJl J3Mgbm8gZ3VhcmFudGVlIHRoYXQgZGV2aWNlcyB3aWxsIHJlc3BvbmQgdG8gcGluZy4gSSB0aGlu ayBiZXR0ZXIgc29sdXRpb25zIGFyZToNCg0KICAqDQogICogICBUaGUgQVAgY291bGQgaW5mb3Jt IHRoZSBXTEFOLUdXIG9mIHdoZW4gYSBzdWJzY3JpYmVyIGRpc2FwcGVhcmVkLg0KICAqICAgVGhl IFdMQU4tR1cgY291bGQgdGltZSBvdXQgYW55IEdSRSBpbnRlcmZhY2UgdGhhdCBoYWQgbm90IHJl Y2VpdmVkIGFueSBwYWNrZXRzIGluIHRoZSBsYXN0IFggbWludXRlcywgb3IgaWYgdGhlIGN1c3Rv bWVyJ3MgLzY0IHByZWZpeCBoYWQgbm90IG9yaWdpbmF0ZWQgYW55IHBhY2tldHMgaW4gdGhlIGxh c3QgWCBtaW51dGVzLg0KDQo8PmVuZCBzbmlwPD4NCg0KWWVzLCB0aGlzIHByb2Nlc3MgaXMgaW5k ZWVkIGEgbWlzdGFrZSBpbiBhZGRlZCBpbiB0aGlzIHRleHQuIFdoYXQgaXMgaGFwcGVuaW5nIGlu IHJlYWxpdHkgaXMgYSBORCBleGNoYW5nZSBjaGVjayBpZiB0aGUgc3Vic2NyaWJlciBpcyBzdGls bCBhbGl2ZS4gSXQgd2FzIG9ubHkgbGlzdCBvZiBjb3JyZWN0aW9ucyB0byBtYWtlIGluIHRoZSBu ZXh0IHJldmlzaW9uIG9mIHRoZSB0ZXh0Lg0KV2l0aCBESENQdjYgd2UgaGF2ZSB0aGUgQWRkcmVz cyBsaWZldGltZSBhcyBhZGRpdGlvbmFsIHBhcmFtZXRlciwgYnV0IHdlIGFyZSBub3Qgc3BlYWtp bmcgYWJvdXQgREhDUHY2IGluIHRoaXMgZHJhZnQgZHVlIHRvIGxhY2sgb2Ygc3VwcG9ydCBmb3Ig Y3JpdGljYWwgbWFzcyBvZiBVRSdzLg0KDQpUaGUgQVAgaXMgc2ltcGxlIGRldmljZSB3aXRoIGxp dHRsZSBjb250cm9sIGxvZ2lj4oCmIG1vc3QgY29tbW9ubHkgaXQgaXMgZm9yIGNvbW11bml0eSBX aWZpIHNpbXBseSBicmlkZ2luZyBmcm9tIFdpcmVsZXNzIHRvIGEgdHVubmVsICggdG8gYSBHUkUp IGFuZCB0aGUgV2lyZWxlc3MgTGFuIGNvbnRyb2xsZXIgZG9lcyBhbGwgdGhlIHNtYXJ0bmVzcyBv ZiB0aGUgc3Vic2NyaWJlciBtYW5hZ2VtZW50LiBUaGF0IHdheSB0aGUgd2lyZWxlc3MgTEFOIGNv bnRyb2xsZXIgZG9lIG5vdCBoYXZlIHRvIHJlbHkgdXBvbiBmYW5jeSBmZWF0dXJlcyBhdmFpbGFi bGUgb24gdGhlIEFQLg0KDQpHLw0K --_000_336255C7CC6E43ECAE53F771D91703D5alcatellucentcom_ Content-Type: text/html; charset="utf-8" Content-ID: <7404A70243B5A442A5B36B2AD7EB04E6@exchange.lucent.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PiZsdDsmZ3Q7c25pcCZsdDsmZ3Q7PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHNwYW4gaWQ9 Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7 IGZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsg d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KSSBk b24ndCB1bmRlcnN0YW5kIHRoZSB0ZXh0ICZxdW90O1RvIGFjY29tb2RhdGUgdGhpcyB0aGUgV0xB Ti1HVyBjYW4gcGVyaW9kaWNhbGx5IHBlcmZvcm0gYSBTdWJzY3JpYmVyIEhvc3QgQ29ubmVjdGl2 aXR5IFZlcmlmaWNhdGlvbiAoaS5lLiBwZXJpb2RpY2FsbHkgcGluZyBlYWNoIElQdjYgVUUuLi4p JnF1b3Q7LiBJdCBzZWVtcyB0byBtZSB0aGF0IHRoZSB0aGUgd2hvbGUgcG9pbnQgb2YgdGhpcyBh cHByb2FjaCBpcyB0aGF0IHRoZSBXTEFOLUdXIGRvZXNuJ3QNCiBuZWVkIHRvIGtub3cgdGhlIGlu ZGl2aWR1YWwgSVB2NiBhZGRyZXNzZXMgZm9ybWVkIGJ5IHRoZSBob3N0cy4gQWxzbywgdGhlcmUn cyBubyBndWFyYW50ZWUgdGhhdCBkZXZpY2VzIHdpbGwgcmVzcG9uZCB0byBwaW5nLiBJIHRoaW5r IGJldHRlciBzb2x1dGlvbnMgYXJlOjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAw LCAwKTsgZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDog MHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBh dXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+ DQo8dWw+DQo8bGk+PC9saT48bGk+VGhlIEFQIGNvdWxkIGluZm9ybSB0aGUgV0xBTi1HVyBvZiB3 aGVuIGEgc3Vic2NyaWJlciBkaXNhcHBlYXJlZC48YnI+DQo8L2xpPjxsaT5UaGUgV0xBTi1HVyBj b3VsZCB0aW1lIG91dCBhbnkgR1JFIGludGVyZmFjZSB0aGF0IGhhZCBub3QgcmVjZWl2ZWQgYW55 IHBhY2tldHMgaW4gdGhlIGxhc3QgWCBtaW51dGVzLCBvciBpZiB0aGUgY3VzdG9tZXIncyAvNjQg cHJlZml4IGhhZCBub3Qgb3JpZ2luYXRlZCBhbnkgcGFja2V0cyBpbiB0aGUgbGFzdCBYIG1pbnV0 ZXMuPC9saT48L3VsPg0KPC9kaXY+DQo8L3NwYW4+DQo8ZGl2PiZsdDsmZ3Q7ZW5kIHNuaXAmbHQ7 Jmd0OzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+WWVzLCB0aGlzIHByb2Nlc3MgaXMg aW5kZWVkIGEgbWlzdGFrZSBpbiBhZGRlZCBpbiB0aGlzIHRleHQuIFdoYXQgaXMgaGFwcGVuaW5n IGluIHJlYWxpdHkgaXMgYSBORCBleGNoYW5nZSBjaGVjayBpZiB0aGUgc3Vic2NyaWJlciBpcyBz dGlsbCBhbGl2ZS4gSXQgd2FzIG9ubHkgbGlzdCBvZiBjb3JyZWN0aW9ucyB0byBtYWtlIGluIHRo ZSBuZXh0IHJldmlzaW9uIG9mIHRoZSB0ZXh0LjwvZGl2Pg0KPGRpdj5XaXRoIERIQ1B2NiB3ZSBo YXZlIHRoZSBBZGRyZXNzIGxpZmV0aW1lIGFzIGFkZGl0aW9uYWwgcGFyYW1ldGVyLCBidXQgd2Ug YXJlIG5vdCBzcGVha2luZyBhYm91dCBESENQdjYgaW4gdGhpcyBkcmFmdCBkdWUgdG8gbGFjayBv ZiBzdXBwb3J0IGZvciBjcml0aWNhbCBtYXNzIG9mIFVFJ3MuPC9kaXY+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj5UaGUgQVAgaXMgc2ltcGxlIGRldmljZSB3aXRoIGxpdHRsZSBjb250cm9sIGxv Z2lj4oCmIG1vc3QgY29tbW9ubHkgaXQgaXMgZm9yIGNvbW11bml0eSBXaWZpIHNpbXBseSBicmlk Z2luZyBmcm9tIFdpcmVsZXNzIHRvIGEgdHVubmVsICggdG8gYSBHUkUpIGFuZCB0aGUgV2lyZWxl c3MgTGFuIGNvbnRyb2xsZXIgZG9lcyBhbGwgdGhlIHNtYXJ0bmVzcyBvZiB0aGUgc3Vic2NyaWJl ciBtYW5hZ2VtZW50LiBUaGF0IHdheSB0aGUgd2lyZWxlc3MgTEFODQogY29udHJvbGxlciBkb2Ug bm90IGhhdmUgdG8gcmVseSB1cG9uIGZhbmN5IGZlYXR1cmVzIGF2YWlsYWJsZSBvbiB0aGUgQVAu PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5HLzwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_336255C7CC6E43ECAE53F771D91703D5alcatellucentcom_-- From nobody Sat Jan 9 17:24:18 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 981691A885F for ; Thu, 7 Jan 2016 01:51:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.858 X-Spam-Level: X-Spam-Status: No, score=-5.858 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_IMAGE_SPAM_HTML=0.81, DC_IMAGE_SPAM_TEXT=0.242, DC_PNG_UNO_LARGO=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 NSsW6Ah5bc1W for ; Thu, 7 Jan 2016 01:51:03 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C61811A885B for ; Thu, 7 Jan 2016 01:51:01 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 81C232857731A; Thu, 7 Jan 2016 09:50:57 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u079owQc025530 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Jan 2016 10:50:59 +0100 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.213]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Thu, 7 Jan 2016 10:50:58 +0100 From: "VAN DE VELDE, Gunter (Gunter)" To: "Templin, Fred L" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org" Thread-Topic: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host Thread-Index: AQHRRrIF1AJWfg9CNUOFmoSBK+04DZ7vFi6A///F1ICAAPhpgA== Date: Thu, 7 Jan 2016 09:50:57 +0000 Message-ID: References: <201601031900.u03J0LMe009763@irp-lnx1.cisco.com> <2134F8430051B64F815C691A62D9831832F9ADDE@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832F9ADDE@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: multipart/mixed; boundary="_002_E0AC9F635C234E798B5F63E3168AE162alcatellucentcom_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Sat, 09 Jan 2016 17:24:15 -0800 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 09:51:04 -0000 --_002_E0AC9F635C234E798B5F63E3168AE162alcatellucentcom_ Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 DQpIaSBGcmVkLA0KDQoNClRoZSBXTEFOLUdXIHNob3VsZCBub3QgY2FyZSBhYm91dCBvdmVybGFw IGhlcmUsIHRoZXJlIGlzIGEgc3BsaXQgaG9yaXpvbiBmdW5jdGlvbiBhbmQgdGhlIHdsYW4tZ3cg c2hvdWxkIGJlIGFibGUgdG8gaGFuZGxlIG92ZXJsYXBwaW5nIElQcy4gTGluay1sb2NhbCBhZGRy ZXNzIG1heSBiZSBzdG9yZWQgdG8gZS5nLiB1c2Ugd2hlbiBzZW5kaW5nIFJBLCBidXQgaXQgc2hv dWxkIG5vdCBiZSB1c2VkIGFzIGEga2V5LCB0aGF0IGlzIHRoZSByb2xlIG9mIHRoZSBNQUMgYWRk cmVzcy4gU28gYXMgbG9uZyBhcyBNQUMgYWRkcmVzc2VzIGRvbid0IG92ZXJsYXAgdGhlcmUgc2hv dWxkIG5vdCBiZSBhIHByb2JsZW0gZGlzdGluZ3Vpc2hpbmcgVUVzLg0KDQoNClRoYXQgYmVpbmcg c2FpZCwgaXQgd291bGQgYmUgdW5saWtlbHkgdG8gaGFwcGVuIHNpbmNlIGxpbmstbG9jYWwgYWRk cmVzc2VzIGluIGEgV2lGaSBjb250ZXh0IGFyZSBtb3N0bHkgRVVJLTY0IGJhc2VkIGFuZCB0aHVz IGVuY29kZSB0aGUgTUFDIGFkZHJlc3Mgd2hpY2ggYXMgc3RhdGVkIHNob3VsZCBiZSB1bmlxdWUu DQoNCktpbmQgUmVnYXJkcywNCkcvDQoNCg0KDQoNCg0KDQpPbiAwNi8wMS8xNiAyMTowMSwgIlRl bXBsaW4sIEZyZWQgTCIgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+IHdyb3RlOg0KDQo+SSBo YXZlIHdoYXQgSSBob3BlIHdpbGwgYmUgYSBzaW1wbGUgcXVlc3Rpb246IHdoYXQgaWYgdHdvIG9y IG1vcmUgVUVzIGNvbmZpZ3VyZQ0KPmlkZW50aWNhbCBJUHY2IGxpbmstbG9jYWwgYWRkcmVzc2Vz IC0gd2lsbCB0aGUgV0xBTi1HVyBiZSBhYmxlIHRvIHRlbGwgdGhlbSBhcGFydD8NCj5Bc2tlZCBh bm90aGVyIHdheSwgd2hhdCBraW5kIG9mIHVuaXF1ZSBub2RlIGlkZW50aWZpZXIgZG9lcyB0aGUg V0xBTi1HVw0KPmV4cGVjdCBlYWNoIFVFIHRvIHByb3ZpZGUgaW4gdGhlIGluaXRpYWwgUlM/DQo+ DQo+VGhhbmtzIC0gRnJlZA0KPmZyZWQubC50ZW1wbGluQGJvZWluZy5jb20NCg== --_002_E0AC9F635C234E798B5F63E3168AE162alcatellucentcom_ Content-Type: image/png; name="default.png" Content-Description: default.png Content-Disposition: attachment; filename="default.png"; size=163423; creation-date="Thu, 07 Jan 2016 09:50:57 GMT"; modification-date="Thu, 07 Jan 2016 09:50:57 GMT" Content-ID: <87CA553640E96C4A9C53046E16F01865@exchange.lucent.com> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAmsAAAJvCAYAAAAk3ZbyAAAAAXNSR0IArs4c6QAAQABJREFUeAHs nQdgFVX69p+be9NvOi2hhSYdQaoN0MUCiooKdl0bKH9d3c91V3fdXdFdXXXVtSJY14KKXRBdO4qC Aor0DqEFCCmk59bvec/cSW5CKMEASXgPJDNz5tTfOTPnmfecmTiCdFCnBJSAElACSkAJKAEl0CAJ RDTIUmmhlIASUAJKQAkoASWgBAwBFWvaEZSAElACSkAJKAEl0IAJqFhrwI2jRVMCSkAJKAEloASU gIo17QNKQAkoASWgBJSAEmjABFSsNeDG0aIpASWgBJSAElACSkDFmvYBJaAElIASUAJKQAk0YAIq 1hpw42jRlIASUAJKQAkoASWgYk37gBJQAkpACSgBJaAEGjABFWsNuHG0aEpACSgBJaAElIASULGm fUAJKAEloASUgBJQAg2YgIq1Btw4WjQloASUgBJQAkpACahY0z6gBJSAElACSkAJKIEGTEDFWgNu HC2aElACSkAJKAEloARUrGkfUAJKQAkoASWgBJRAAyagYq0BN44WTQkoASWgBJSAElACKta0DygB JaAElIASUAJKoAETcDXgsjWaoi18ayHkH5azyD2A/j37o3+P/o2m/FpQJaAElIASUAJKoOESULH2 K9pm6ltTMWXSVPy0jEItzBmZNrY/poydgv7cqlMCSkAJKAEloASUwMEScATpDjby0RxvwrgJELEm rn8vYOHS2mmM//t4TLl7Su0n1VcJKAEloASUgBJQAvshoGvW9gOottP9ew2oFGrHccpThNr4seMh uld+pky3xFn/iP6YSsubCDt1SkAJKAEloASUgBI4GAIq1upITYSXTHuKSBMn++NpOROBJiJu4fLQ 2jWeW9jdBDHCzrbCWT76WwkoASWgBJSAElACB0ZAp0EPjJMJJUJsQM8B1WKIRU2Emj0tKpa1ARR0 CzlFKtOjWE7LW8Ba06YzztXQ6YESUAJKQAkoASVwAATUsnYAkOwgU++21qjZVjXZTnlzfKXlTNan GbdiqpkWRff+CIasa+I/4W6dDrUA6W8loASUgBJQAkrgQAmoWDtQUgxnPs/BrT0NOpUWtYUrOB3K T3YY4cbpULG+yRq2he9Y1jSHfMqDa9eMk097qFMCSkAJKAEloASUQB0IqFirA6xgmNgawO+oybfU +nenKKMgsz/fMZXfXBMnU5/y/TVxtnXNFnvGU38pASWgBJSAElACSuAACOh31g4AkgQRi5ljhRXY WNFCb3xOuGiqmQa1v6e2MDTVaU+VUs5hgXwwly5c7Fkp6W8loASUgBJQAkpACeybgFrW9s2n8qz5 iwQXWIcT+FKBOFmDZr/lKR/AFWdkGac9xdImU6DibKubfWz56m8loASUgBJQAkpACeyfgIq1/TOq DGFbxhYGF5rvp8k31Cpdz8o9Tov+RHuaOFrV5FMeISdWNnV1JOArwC/ff4+1BT4Tcff6Rfhu0XpY R3VMS4M3LAI12vawFm5/ee/v/GEtrGamBJTA0U5AxVodesCE0Nue5kO3Mt3Zy1H18kB4OkuDGD99 AcaH1rLZEk0+83E0uJ+evxPX/2MWiiorW4z/PTAB1z00C2VhfjMmTcC/v9hc6VPrTtka3P673+Hd tcXm9Ob/3Yabb5wRlnatsQ6vZ3k2PvzPn3H6gAEYEPoZcf4VePKL9Ye3HHXIbdvXk3HFlfdgoYW1 Wsx10yfh4nvfP/SMa7RttULs86C2/mRHyMEbv7+8zv3Kjl25PeiyVaagO0pACSiBeiOgYq0OKMf3 rBJbsiat//LjsJBWNHH2H24Xf/meGr+uhglieeOx2NZM+KPk74QmR+fh5w9ex2pbCBStxbS3FuDn tz/DRtskVrQCT8xYiMj0FMNvr79ckUhHEDGRVojIqAQEkxPQYBZbli3DH046G/e8+ilSLvoTJj83 Gff+aSKOpRn2tZ9z91qtup3wYcWs1/DG3P0I2zok2qpje6xY/iGeqykog5vx3wc/RH7LTCTUIb2D ClqjbQ88DTcyWwOL3nwU3++qHsu76lP8+9uVyOjYvPqJmkf7y3t/52ump8dKQAkogUNIQMVaXeDS UrYgsMDEkHVo5i1PWtHEmb9cINulC8wUqXwY1ziGEyef+ThaXNuBI/g2xQrMX2eptbKsn7AMDjj8 32Lp5nKDIW/xl8iNGIDTO7r3i6WEcRuqWzXtcXzN8vX+v+fw5u1jMbDvQIwcew0efm8hPruhdz0V 24cFf3sYtyypL/EHRLQbit91C+B7isz8sFKWLfsMs1ifiaPki86HyPl81jS2K+6gM+h6+qVIZclf /np1tTR+fv8F+Jtdgd90iKnmX9tBrf2qHspWW17qpwSUgBL4NQRUrNWRXn8HP4QbEl72iwOSxAT+ ZQOxpDkcjmofvxWL2oJlCyotb3XMrlEGj+x4LIbTGvbeD2tN+bMX/VBZj19W5pj9FZ+/ibKBZ6KL GVOLMWfyrZVTiOMe/3y/U3CWgc5n4vU74x6ssDQgULQaz946pjKtYf/vGay0LXwoxkyeu33a5/jf fy63wgw8Hx+uz8HK9yZVxvnr24sqy7vPHVqh3pm8gOJgHP5xdd89grrdlmDwbJqF88/4MxZXK8cI THzbFhp2uWbjq8kTQuU4DU9+Y1nSVr16Bx5DBNpOvd1Mtf4hFG/Hj6/hwtC0a98LOKUZWtcHqeed Y3DTi7Pwxp0jmN5pmFuZt11MN8686lxEbngOn2+w4fFlmHeehLfDdRjaRmyXPvzAKW17ancAWT35 jT21u+8y27lU3xbjq/+wfkOGYAjLfev9LxkRXxWmDv2gxWDc2D+Axc99jB12At7VmP5WAfpcNxIt jV8d0iOzfZcN2DtvuwC6VQJKQAkcGgIq1g6Cq6w9EwEmQkx+xIn9bKr9FwpCa9nkcx5iUbOnSE3A o+FXZDsMPymI7Z/9xDVqPiz+ZD5aXjQR56cE8fpCGexzMHuGA0PP7m+mM5dOvgG3vrAJd/z3PXzw 7F0IvHwH/vjBvqf8RAb9PPm3uPX5ObjhwRvRXTwonh455WI8MzcT9zGt91/7FwYueRaXjXgQWaHp 15JdWfjqkTtw26qBeHzyvzAyOQv3jBuJy+7Pxt2TH8fNLPesB5/B4ir9svcWK87FKp5tcf7p4Kzc Xp0/Nwub8laiJCxEXlYe5ueVVvpY5boNv/+8Ne6f/DB+2y0PL/7xdWxliDZDxxnxG3vGb/HPyZNx 1YkZ8K56C2dNfBSZd0zGxzP+i+sDH+Ca61+uFLklm7Mw76m/YVLFhZj0r/vQ0dKNlfnJTosh56In RfVzny2x/DmlO43tcsLlp8OanC5HQXEK7pw8DTNmTMPNJ2bhhT/NqBRH+ypztYxCB0ufvwG3v7oQ v33gv3hv+mT03PpjtWB16wcxGHbJRXDuegWz1liNVfTzLFo5U3Hl8GNMunVJb39l2x/vahXRAyWg BJRAPRNQsXaQQEWAyZSnvHQg4k2Emb0ubXz36zHljSlYwJcMjjqhZnjGoPewoXBl/YgVOesxZ6UD o0eNxDAKocQ5K7B50y94l1Nt5/VLBygQJj+/gla2C9Av1YWIZpn8xnAQc977plJ4VG8iNwJuDxa8 dw+uf34lrnpiBiYca61Pkim8abRAXTX1Xpzesy3adB2B+x+dCIdvOj5YVmCSqaBiKh72J8ydfAtO 4HTt5Rd3R9B5Ol795hmcPfAEXHrddXAEd6LEXltXPfPqR6GFcwmh9XThJ4sLcih0QoovMtqcigoP wP3UsOMK7lf0nIj/vfM3nDZwGEadOYDTxvOwiRax+HbHYVDbIOLa98XAgQPRO92NVV9OAxzdMeq4 VihHIgZccDIiN87E0pAFza7nj4/cgLNGDETLUFnDsgQSeuHq0UHsev49bOSJop9m4gdHe1wyrGMo mBtn3PJHXDCwI1JSWqBTZjtE+BZgvZ0HQ+2tzKEEqja0er00eQWcV03GTb/pibYdB+L6Jx9Dph2i zv2A/AafjcHsK1M/sNaNzp32Mip6jccJzZhoXdLbX9mY3P5429XQrRJQAkrgUBCo7RZ+KPJpsmma NzzHsnry1w24pk2dRaBtn+FwBP6BT2e8j68pAC7umo72A86Ac+Z3ePfdRQi6xqFfK3a/Ii8noIDY Hx/FRaMfDeFzIG2vy5nizdTd7/8JBCKvwG+Pp+Cr5lJwTMsqM5IzseZ5oF3vHmGL54vha9cZbUJR fKhdWFXLwj4ICbriYq/tE9oW482xZ+BJ53h888kNoZch4lnnqmCSXV7VIcTsln7u4ND0HeAVtYV4 WALPR0Emzs6nGD99l0VLYgT+OG6MOQPawoLOXqHwllf1eoaCVdu4MPiCm+CY8TQ+WXYzus18E6WD /oaByXYgmUb8J62Xn9EjxawRE4FYKTr3WWY7jdC2vJT2VKCtO0zZ+rysobXmE9yvWz9gYrE9cdXY ZMx7ayZWXRmH1+bwoeCRkxArWdYlvf2VjSU7EN6SrToloASUwKEgEDZ8HIrkj6I0VahVa+yIdn0w igPx209PN9aXTuxpSd0GIzX4GV55Feg4/lpLmPCtO3nFIPq8h/HdXcOqpVH7wQ6T3otXF+GGP7yC M//RBZ/fNcoaoL1in8rHxjyqKBGCdP6y7WYb/svhsUWP5RsRshSFhzmg/YRM/KZbEI+//Di+ueIV DK0UOYCbi6YCFSFZI+XiCxdbd/kwQNaClWXhx82OapY1ya9muWqWoUCqZ5wbvU9sj+CaTLzxw6Po YnvX2O4vPQke2/M0nI+n8NxVV/IoApc8caLFkkdlP79ihNpNL3+O3/ZIxqZXJ+D8x6qmbiX+geQh 4WxHbV7lKKgqF/nXuR9YyfQ77wY43noAN132KfIiBuLmQSFxfhDp7bVs7KEHwruqYrqnBJSAEqhf AjoNWr88NTWbANetnXSatfKp24nHmTVQEe16YEjIknLy4JDEoHXkxmu7o+L923DfB4s4dViMXZtX 4/vvV1tvDNrphW1dO/lFlOG34J1Joxnvbxjxj8/N99tiu/3GrO166oGXsCSnGCU5yzDl3qdocToZ p3UNU1Jhae1711qoP/S2t/YyJZuMsXfcZoTY70+/Ae8s2ozi8nJUFGzDrhLrDVYxvkWntTfZfPbZ d9iwbDb+cPKV+JrTwIn7ztyc9ZjfLiS0oLHo1elYyHqVM9Fep15q3q695i+vYR39iguy+fHg+dgR svYdQNJWEEdbXHDrAO7nG07n9mteGbVoN0HTebjdvv57PPefBTwqYRvtOxOrzCZq1a+EzhhFYZv7 7D14Y/5qbFj0Of7vlBvM9KuxZR5EP5DEI7sOx9UpAeTzldaYcy7EANuoWpf09lc25lNvvKuI6J4S UAJK4IAJNGmxJn8Kqn8vGYgsJ8f2n4ey/fa1lT/Ebv8x9trCyTlJz/5shx1GjuVPUSHsrxfY5+pz a/KozwTrNS0Xep10sklxxOBMK2UKuEFctxbkJztOCBNPvW58Bv+59iS8e+91GDF8OM4ccymuf3V+ 5Qd0ZaosKtKylEVGW+/5iVxof9bf8eZfRLDdgSunzqeZ6Bjc9+4TOGPbs7h65HAMG3kVns85Aw+9 c7/1AoJVihq/ZQ1cDS9Oztkub2UWdm+q+ryv7W9vY3tdhi/5IsPw1vNx/3Vj+GLFSThxxKV4kZaz dl1TIdohot0J+MtJnK576jaMveo2OH7/V1zNNWiFdiK1bCOjWWsHp3xNtbmY/lpOV/o/xQTW6/FF BRQpY/HR079Hy/9x+ph+w0eMxjW3Po/N+9ZRteQEdD19rFk71nLseehjix2GbNH/EoxhOafefCnO Hvc7xE28EpnBTfjjubdjTS35VC9zzazcuOiRKeaFjn/feCnGXncHmk283uRrGwz31w9qpmgdN8fZ E88wu1eOrrrWxWN/6VX1q/2XrT55W+XW30pACSiBAyfg4AdcQ4tGDjxSYwkpn9GQRf/ytzzH80WA KeOm4qceCzHl7immCkaMUVDJOXHmmO919mcceTFgwLgB/Lhtf4y/my8Q8FicEYDiyxcKJPyEtyZg wd20OIRNgxqxxrymTK+KJ352GkbcdeeHdPkZEDtN2dp/4cAWlPax/HkrCSv58fW9ynSkfvJWqjg7 bXPQSH/5ymk14gov+RcTY4mzg6uKD8Whxf0xbjdTO3hX9OMDGHZLDL6Ye0voDcm9p1WQk40yihiX KxYJKcmoWYVyWg19rhi4a57Ye5LVz/hoQePitep18qGgoJh5Mt3Qp0KqR/q1RxZLV4zb1MfPOpS5 XKxDmKqrUxZWeeFyI9lde8vUXz+wCnbg6e2/bPI5k0PLu04wNbASUAJHCYEmbVmTNpRPZ0xdNtU0 pwg1WyBN4EdrRYzJORFBU5dPxXj++SOzf7dlLROhtnAFrXE8FidWOlugGUElwknCdJcPd4S5Zdxn XuFOrGBGpNFT0lt4j3VeyjCF32czQoznpFymDLTYyb44CTugt8OUb8BFAyvDyjmTVujDu3LcmJ0I AhEBv06oCQGKCYo0+aldDhwopXJ8zsX1I/8xer9CTVJMbp6O9PR0NG++p1CT8yKyDlqoSQIUOHvW yYXk5ORDJNRMpiZPW186TR0OVqhZ6Ul59ybUTIh66weSGrEdcHoWy32VTfrWoeVtlVl/KwEloATC Cfy6sSw8pQa2L3+/03xKgxYx+w+wG6EWsoCJ2Ao3KhoL2lLLwmZPL8ofYZ/w9ynG4iXhB1zID+LS Kif7IqgkjljU+q8IbUXM8XMexvo1qQaQd3h8t+Vn/rg740kaUjYTJxQ8vFxGHLIMC0WMdR+PhRSe IuCm0o9fbzMx7A/0hqLrpl4JxGDMlM9hv29Zr0lrYkpACSgBJaAEDpBAk7WsieAyf+KJU4gOCjYR QeC+OPlLA/bHbG1OYvWSaUX5EaEnziHCjmJKnAgm8RcBZVm8KKKsU0awiZ/8RQPberYwNG1qBzF/ mip0MCB0TlKw9+WUKSO3koeUQ9Iz05siCENxrSnaypxDvrpRAkpACSgBJaAEmiqBJivWpMHGU0A5 XJxKFKFGt1DWiFF8Tflb/2rCSs5NuIjTkbSaibXNXtNmW+TkvFjlZA2ZWMFMmOn84C2nQSU9EWhi 4ar8s1KcBuXkKPi3dGp1C1keI7oqJZgVzP5D8XYelZa/kGCUULJ+Dctt6VZr8uqpBJSAElACSkAJ NCECzrvpmlB9TFXEAraNi71F9NwtLw/0zLCmLZtnm/3+PUcje3k2pn5tTWdm8Hz2sv7IzpmKmUxh xtNTMbrHaGQMz8AU7jv4NYP+w2mdC4WfybgZORRNLZju13xBYaI1fZrRPMPkn+3IZryZTC8bM5fJ NgMDmPfdLJcjhxa0r2dixvQZsMJNxbOSLq1oo8eyXPw3U+KGyjd6+GjM5Ec/ZbpV9rNnsw50Up5J kyaZ8BlMX+qgTgkoASWgBJSAEmh6BJqkWEMLChsKH1s8iRVLxEyGbFuIv3VemjPDYQmd8RNFKPGY VqwBfNNT4ks8EWpiPZPj8TzO5nEGBVcGxZJMUZp0QyJN0hMn+Q7geUhYCrr+zHs0rXKO5rS37ZxJ ITfFhDHhbmQaK1gGlkMEmBFkUhLJg/Hssput5MO6ZVxohR89brQpm4hKu65WCfS3ElACSkAJKAEl 0FQINOlPdzSVRtJ6KAEloASUgBJQAkcvgSa9Zu3obVatuRJQAkpACSgBJdBUCKhYayotqfVQAkpA CSgBJaAEmiQBFWtNslm1UkpACSgBJaAElEBTIaBiram0pNZDCSgBJaAElIASaJIEVKw1yWbVSikB JaAElIASUAJNhYCKtabSkloPJaAElIASUAJKoEkSULHWJJtVK6UElIASUAJKQAk0FQIq1ppKS2o9 lIASUAJKQAkogSZJQMVak2xWrZQSUAJKQAkoASXQVAioWGsqLan1UAJKQAkoASWgBJokARVrTbJZ tVJKQAkoASWgBJRAUyGgYq2ptKTWQwkoASWgBJSAEmiSBFSsNclm1UopASWgBJSAElACTYWAirWm 0pJaDyWgBJSAElACSqBJElCx1iSbVSulBJSAElACSkAJNBUCKtaaSktqPZSAElACSkAJKIEmSUDF WpNsVq2UElACSkAJKAEl0FQIqFhrKi2p9VACSkAJKAEloASaJAFXY65VeXk55Mfn8yEYDDbmqmjZ lYASUAJKQAkoASVQK4FGK9aKi4tRWlpaa6XUUwkoASWgBJSAElACTYVAo5wGFWuaCrWm0gW1HkpA CSgBJaAElMC+CDRKy1pZWZlOe+6rVfWcElACSkAJKAEl0GQINEqx5vF4VKw1mS6oFVECSkAJKAEl oAT2RaBRToMeLS8T5Obm7qvt9NxRSED7xFHY6FplJaAEjnoCjdKydrSINemdR1Ndj/qr8QABaJ84 QFAaTAkoASXQRAioWGvgDakDcwNvoCNQPO0TRwC6ZqkElIASOIIEGuU06BHkpVkrASWgBJSAElAC SuCwElDL2mHFXffM1IpSd2ZNPYb2iabewlo/JaAElEB1AirWqvNocEc6MDe4JjniBdI+ccSbQAug BJSAEjisBFSsHVbcdc9MB+a6M2vqMbRPNPUW1vopASWgBKoT0DVr1XnokRJQAkpACSgBJaAEGhQB taw1qObYszBqRdmTydHuo33iaO8BWn8loASONgIq1hp4i+vA3MAb6AgUT/vEEYCuWSoBJaAEjiAB nQY9gvAPR9aewjzk5OWhsLAUfjtDfw5mf/AZtlbYHnvZHmi48Oj7ieOoKEWelKd0f5mHJ9o09wN5 K/D+x4tR3jSrp7VSAkpACSiBeiJwlFrWSjHr/y7Hx6c+gCcu6BJCWYr3r74COX96Edd3S6wnvL8+ mYO1ojhKNuDlf/0BH6xwVBXC0QF3//ch9A5uw+MvP4O/jBiBjKiq0zX3HGUHFi483r7i7PhhGv7v oXcrgyddcC+ev6R75fHB7lQsfwmX3uPAC29chaSDTcTEK8VHf70CL1YyS8CI6/6I68/sDuevSrf2 yJ7seXj5JQeGn9kb0bUHqdX3YPtErYmppxJQAkpACTR4AkepWAuiIujAdo837M85BeFhc8lA2JAG w4MrSw5euOoPmJk0HPdMuR49U6NRUZqHDSu3IiWK9fO60MrRUior//fuIqxwroj9hAtPIRRnj7SD 2Xj9oXfQ/6ZHccewtijL2YDN5Wn1wjq6/Sjcf48P8VKf8LLUeZ99gH+OtfCM2zH9is5Y8+EzeOC5 B9Hv+BcwqA76Pbj+A4y74zvc+8qD6LYPFRZwRrKEDjjrWO6D6xN1hqERlIASUAJKoIEQaJRirb7Y uSPDqx8NGTorHafzPn36QTz7zUbjNfDKO/G70cchBqX49P6/I+f4s1D49pP4cocDA679Gy6Mnoc7 nv6UY28H/O7hu3Fy2zjAn433Hvgzpv1cjEDS8fjrg7egb+qhsNFUltrslK+ejVkUAbf86yYKNetc dFwquh0XOvBWDx/cuQTP3DPJ1AUUcZfe+ReM6ZdeGWjT3Lfx6FNvopA+J157D24WSxPr9sqkP+PD FcUmXJ+L78SfLzgO4UQrE5Advw8y8bl7VwGnY9sitnkHHGMH2Asn7/qP8eeXC3Bmz4145q2tuHxU HL6MuQKPXdzbxKxY/jbGvww8PDEeU2iwm/SndMTzTO7ij/HQvS9gHfeDjh64+6VJ6BVXgV/eehj/ mP4zfRNw6d//jTG9QjxMalW/2rgTkBSdikGnDgcYft3OUgwsX7cXRqX4iv1hw8AzsGvKM/j5rBvR 76NXmJgDf718LHpfeR/+2j8H99z1KJYWSR4JuODPD+Difs3lQJ0SUAJKQAkogf0S2OvYut+YRzDA r7csBBEZCxS9ORX/zm4Fh1k+VYHlRQ4MNdYmH3589AY8s+kcPPLS/WhRsBCTbr0f9yU+hklDk1CS uwHvP/UyLp70OB7Nm4nfP3YP5nYcg8eeeQxLHvsdnvpqLU66ogfTuAnPxd6MD6YPQ9YHt+O2B/6H 1/81koLvwN3B1HXrL/MQSB6D49L2YhELmdMk7SAtXs/83yQsHH07XryiP4p/mo6b7/sdEh5/HSOS g4gL7sBz7+bjnqeegXv1TNz+2N/QtecrODPdiZ7n3Ykxk7oguHgarvnn61h+Vj9OsVq2LSvtsHo6 2+DSW043rMbN6oeJf5qAU7uIWPLvlRO8Jdi47F280Hw8/jN5IuK3f4RXJ72MFeeJxaoCs194Hc7j 70d80XxsXOQwVjrHztm4gUKt1xV/xbOnHwN/YSGiaU3MnfME7n0nEf9+fTparvsQV/z1MfSadjc6 V9POVtlLS8pQUrINX734LIIRQ3BypwI8M652Rr9pFUQB+8PHU6bhykmPYEL7Fijrtg7zH56HGx54 CEMykuApDOLsO57C37o0x/JpN+GvT8/G2VMvoEVN+Egb1M0ieDB9IqwldFcJKAEloAQaGYGjVqx5 ygBP93445eSu8HGFt8tVCN+8n9h8HDi9W/H1Dw6c+ddz0S6W72DEDsT481rgtlmLUHbyUCAPGHzn QxjTLQWOksFIdCzGxLsvRltOefm6cnrR7zJpzGUa0a2+x+Qnl8CXlQXXlp0o58C8j5mxPbrPwQzM wWAZaxFZTQQE8ldi1v+2oN+YEWgTmiuUtANbl+JLJOLO8wdSmAFx/c7BpQnv4rNFWfjNMNCOmIC7 7rsWPWgoRLMzccpjM7C5uJwiphn6dCzDnA/fRnb+dlNur4/sQq+sGAESyseuVMYJ1+GVLidh+pMP 4Zm/3IA5V0zCX8+Mx145BT0IOk/DYzf+BsYGlvIbnBJ8F+8u3o0/d1+FZ7OScPtdnRHcvsBkIXlu XvQdy9APV5zdi7Wia9aMv8rx8+y5cATSMWPykxTnm+AI5iKvnOWVelU6S8T7Prkfv/2EUY87C395 /CKkb/12r4xOPYPtLf3h9odwFvuDuJhkbh1xaJGeglhZE9isMzqXLcEnb3+OnGyKytggvCwrZ5eN M6ys3QP6LeHVKQEloASUwNFDoFGKtfpqnrTe/dGvt/2CQQU2JTyFHJO4D9RyaBU2TRrkHKmj3Gve qJRZxMTYkEmG645kvHeEXrX0mfjyy5r2a3vCUIzi9GOF/zcYFZ0Gd+X5Q7fToueJcL71MRbnX4Dj Lf0Az/af8cp7X6DNORRrIUFlSuljiSksIsMtTLQ6lnhDNal5TiIRQPn6Gbjqzldx6jV34KwhzfD5 rHcOqEJRzbvh8knPY/Dbf8Rfpn2BrWeOMtOjtXESzsEEd5i4bY5Rl2Xi1nc+wzd9fkB5/yvQj4rM a2nFsPxrTGnzjIfTkt4Ow3DqqD4Ua36cOjraiOuwSGZXRLxz9F2Ydrk11Sqe3k37ZmT6Q0KVBPcL IHGhPrHpw7/j9mnluOpPN+D4Vrn4YJV379PFVkz9rQSUgBJQAkqgkkDYsF3p1+B3LKsNrSK0MBz0 D2sZ4fGFxffBIwYLSdPZFqd2C+KdN2ejQKwYxWsw460dOOaMY2l9kjxD4cy+ZeWoKgcQEOsc0xg6 KIisRdsQ26ErunbtiozUuLD89l92aYiqdPcf3g4b3/kEnMAVZg9Peg6r8mgFYzm9UkwKLzuMnbar TQ/0D27Hq1+tMefK1s/GtJ0OjDi2rTmWadBv522Aj2kUrZ6Lryh6urSIw6Z5n7KOQ3Hu6X3hLssx 69mCzETSt9O28zJbXx4WL96AYrG+BYW7hEpAzL44+QJwFFevd/sTL0S79dPx5PtZuHLcAFqneJ7h jEWU+637HE8L2jy8/cUaU+bSvJ3MMwp9Th6MyA0/oji+rWmLLhmp1sJ+iR/+w5TcLlpGw/z2x4hB mb31sorEi4rmO6nBEuwul3qW4KcPVqB0yDkY2bctyrdlSaMay1p4ucPz29c+c6pWtn2F1XM12jas TZWNstE+oH2gMfWBRmlZE8C/znFAZQIBmpOq0pKJQ3sgjMCJf/gnVv/lLky4+CWTVerQ63Hf6W0Y vhSRNKXZjcwdc95lBgJOp/LIYfYjMGjiY7jiX7filsveMmF86WPx0iPnm0XwxuMAflWV7wAC20G4 Puz/nr4b7gfuxt9u/Mz25fRgX8SYNzu5Fo2+pg5og5vuux5//vNduPhFK+jx19+Ls1tHIchpQnEb PvoHLnvaepFgyMQHcXKzCASHXYyMDx7HLRd/g9jug9Ezfgfuu/0dvPifHlVphzWTw7Mdr/9zEtZb WRBSS1xz7zlI4bzp3jg5nZwy5BsDVjmtiP6U3jj32CCe2jkGQ9vFWufCwvmbD8Vjv8/GLY/ehe+n Mo4jE3967n70PWEi7tz0KO6/+SorIfrfRf+eNaZBpV/EVesXEnwfjGr2Bwne9jhc0P5FTt9ehunj 7sWdV5+G1594HBfPBboNHoyk3e/jj28ei//027N+En1/7qD6xP4S1fNKQAkoASXQYAlQV/xq5XPY K7dmzZrDlmdFqXxMNhpxceHzhHXL3krDyTSqpsoOJAWPx4OoKJEPB+9KC/M5zeiE0xWNxH3m70cp P1TrjI5DdFhV/X4/nE4nP/1RCL8zEdWS8FdAvm1r6uUvRamPnMIj71Fs5lFYwilhLgNMSdzjRYuD 5bRHNuJhysaWi4ur9o00Pz/KK/nX9K81jT08a2e0R7CQRwXhuAhMcJp8KWOFX4B9yluD897SqOlf H32iZpp6rASUgBJQAg2bQKMUa6tXr27YVOupdF6vF5GRYu9TpwQsAtontCcoASWgBI4+AkfpNGjj aehGaPhsPHAbaUm1TzTShtNiKwEloAQOkoCKtYMEd7ii6cB8uEg3nny0TzSettKSKgEloATqg0Cj fBu0PiquaSgBJaAElIASUAJKoDEQUMtaA28ltaI08AY6AsXTPnEEoGuWSkAJKIEjSEDF2hGEfyBZ 68B8IJSOrjDaJ46u9tbaKgEloAT4ebCwj2E1Eh4Oh/V3IBtJcQ+6mFJPdUognID2iXAauq8ElIAS ODoINErLWkxMDL8JVnp0tJDWUgkoASWgBJSAEjiqCTRKsZacnIySkpKjuuG08kpACSgBJaAElMDR QaBRvg0qYq1Zs2ZHRwtpLZWAElACSkAJKIGjmoAjEAg0vkVroSYrKChAfn6+mRJtjGvvjuqep5VX AkpACSgBJaAEDohAoxZrB1RDDaQElIASUAJKQAkogUZMoFFOgzZi3lp0JaAElIASUAJKQAnUiYCK tTrh0sBKQAkoASWgBJSAEji8BFSsHV7empsSUAJKQAkoASWgBOpEQMVanXBpYCWgBJSAElACSkAJ HF4CKtYOL2/NTQkoASWgBJSAElACdSKgYq1OuDSwElACSkAJKAEloAQOLwEVa4eXt+amBJSAElAC SkAJKIE6EVCxVidcGlgJKAEloASUgBJQAoeXgEu//H94gWtuSkAJKAEloASUgBKoC4FG+Yfc7Qry T2XB7/dDtuqUgBJQAkpACSgBJdAUCTRasebz+SA/6pSAElACSkAJKAEl0JQJNMo1a2JNU6HWlLul 1k0JKAEloASUgBKwCTRKsebxeOzy61YJKAEloASUgBJQAk2aQKMUa026RbRySkAJKAEloASUgBII I9AoxZrD4Qirgu4qASWgBJSAElACSqDpEmiUYq3pNofWTAkoASWgBJSAElAC1QmoWKvOQ4+UgBJQ AkpACSgBJdCgCKhYa1DNoYVRAkpACSgBJaAElEB1AirWqvPQIyWgBJSAElACSkAJNCgCjfajuPui OGXKlH2d1nNKQAkoASWgBJSAEqgzgQkTJtQ5Tn1E0L8NWh8UNQ0loASUgBJQAkpACRwiAjoNeojA arJKQAkoASWgBJSAEqgPAirW6oOipqEElIASUAJKQAkogUNEQMXaIQKrySoBJaAElIASUAJKoD4I qFirD4qahhJQAkpACSgBJaAEDhEBFWuHCKwmqwSUgBJQAkpACSiB+iDQJD/dUR9gaqaR2iYTSd6d 2LCjtPKUK60z+ndrCUdJLtauXoldVacqw+iOElACSkAJKAEloAR+DYEmKdaCweBembg7DMHoUwcg PSkKnvJi5G/6CdNnLoB3rzHkRCKGjh2DDlu+wSPTF5iQEW2HYeLY/nB6yuGPikG7wA68+UteWCqR 6DrsbAzt3Q4JUUB58W5sWvg5Zi7cEhamPnbjMGjMeWi783u8893G+khQ01ACSkAJKAEloAQaEIEm KdYCgUCtiIPx/XD5mBMQV7YVP36zEbHtu6NH+/ZIDPyInFpj2J5B+DyAz+eFnXbXAb3h9GXhucff QoEdLGzb7ISxOKt/KxRmLcI31Gcde/VGx06tEJi/KSxUfew60bJdK7RzJFWWrT5S1TSUgBJQAkpA CSiBhkGgSX4U1xZUNRG7O3ZGHDz46vnXMF+mLOd9h49rBqr12BZ/wUpB5IWfIf2ooDC0z4ZHbdu+ OdXderzy5qco4Yl5330KRHKntsDhEeu8n4/3Hn6wzrE0ghJQAkpACSgBJdA4CDRRy5oIqT2dP+ij ZxQye7bGDz/saeEKJHfDJZefgw5uJ8N5sPLT1/H+T9u4H4A1sSpizY+u50/EeR1i6d8RN9z2R5Su +RhPvb+Ix1XOKUm4ktE5wY+fd4f8K6rOp/Y9C5ef2Yfika5sCz566RUsMeGSceb4a5GZ8wuyEo/F selOLF6Wi17tivDaU9OxNZRE6oBxuHZoNN57YgY6X30tOmV/gadmWGVI6zUC558+EGmcfhVXsfZj PPq2nIvHoPMvx6nHpBr/wo3f4r9vzDFi0njoLyWgBJSAElACSqDBEWiSljW/v3bzVeFPc7F+WCd0 POUy3NptGWbNnIUVOzm/Kc6RgYuv57q0XYvx0nNfIvnEi3De6Zfg+DUPYk5BKD2uhZO0N87+BIuS x6BvWgG+fP9b5BduNv5WQtbvhd8vxPHnD8IZN/4RPX/5Ah/OnI/8UABn5kiMp1Db+t07eHJ+Gc6+ 7nKcdflZWPv4DBRTGEbFRiG560DEbv4Js2ZtwZaiVujTcxCO7x6DN5eKSTAeJ53YCRHbv8Sq8gD6 uKPgjnOaMji7jMT1Zx8H7F6HGa99iZzIlkiPzTXnuo+9hkLNj69ffQpLonrj2nFDcekpG/HM53sK 1/C66L4SUAJKQAkoASVw5Ag0Tcuav3bLGrAerz30BE4edxGGd+uJ86/via3z3sYLny5HdP+T0YnW sNVLlyGQkIBdm2hRG5iOLp3S8M2PPsuyRrEWYNrF2auQVQT0TS3EqmXLKkVYeDOWLv0E/8rZhisv GoUOx56OiccOwpyXn8dXG0vQa0gvBt2JxSsLkJ7gxZLl29BjUDf0THwPc/MDMFa5XT/gwRf/F0oy BYvLBqHPkBMQ+OV/8HU4GT1o2Fvw1Q8sj9uUzR8qW6/+3RmnDJ8/9yoWlTi4n21Z4xyZGHSMG9jx A9YXxyA+cis2lAE92mQwjQ2hfHSjBJSAElACSkAJNDQCTVKs+ffygoEFPxdfv/E0vkztiauuHotO Qy7EhZsewqzQC6Sdho+jaHPCSVHm93tQ4qmAPyCiRxwta6G0bdudrI/bmzRE9iL89z+LkDFgNC4/ uz9OuuISbJg0lbYzmQ9tgZHX/pZxqRCZj99TxPVvVen7CvMr8wJy8f2P29BnWB/0d81CYHhfoHQp Zm9g2ayJ1MqyUepxrdwmLC9iWqHJW55EIDUDXEUHNBuAq64fYAShx+OHL64lkliH8PdYJZg6JaAE lIASUAJKoGEQaJJibW8vGFRDvmsJXnrcjbv+MhKJKbEIVFhqbfm0u/HWGluc2TFSQrKn6gUDy8M6 toWbHbrmdsuPH+DV9EyM798Mmc38KHBGU/dtw+S/P0O7V00Xvj6uKuWtc+Yhf9j5OH7MhUBbJ7Z+ 9jV2G+FYI3yQ0tHVEp1dfszzhNUjd7N547VV1izc89L8mpnqsRJQAkpACSgBJdBACTRJsebz1W7r iukzAqNa5GH2vKXILQaOHdkHlE3IzSlE/rIvsGZkF/Qedz02vvga5m7yoGWnrkgtWYUV20OCKBjg 5zustGkEM87PY3ltobpzY+iYMxFY8QN+Wb8ZhY62GMjpVAS3Yu22ANZ9+wtGZw7ElZedhhde/wTb 4Ea3Xh1QuHQJsj175mXS9i3E3M0jMap7bx7uwKyvskP5Vg+/cO5SjOk8EKdddz62v/ohxWBL9OoS j59/WIkfVhThgu6jMG5QDt7+fh0iU9uiYwtOw67cXr34eqQElIASUAJKQAk0GAJNUqztzbIWiG2N Aaeewp8LKhsg+4f3MW0xF6ChCM8++jbGT7gQo2+4E6NDIda99yCWZVdZuOy0+eU1Tl8GEaR1q+ps KJLDhdbd+qH3wH4YZefkL8CcadOwSqxhy97FEx85cc1ZJ+Pmu08OhSjCx6sWYWtFVWp2XnYS3321 FGdcORDFv3yLJcaqxjOO6uEDTHvKp/H47en9cM0f+llRS5ZjzdzlmP/fJ5BwzXicfvY16HW2dap8 1Uf4hWvm1CkBJaAElIASUAINk4DD4/GEbEQNs4C1lcrr3fffG5g0aVJt0YxfMDoB6a1S4eY3zwo2 Z2FX2Oc07EjutHQk8NMd+bm5KLc9D2Ir6aS54/l5tRJsycquJa1opKXzMxqeYuTmimCsT8d6prvh Lc7DrqLqlQwmpKEZP+vhYb5FNc7VZwk0LSWgBJSAElACTYnA3//+9yNSnSZpWdvXn5tCeSGyNxbu E3bRrm20s/16Z9LZta90yrFr26GyahVi27a91LNwF/ZZrH0VWc8pASWgBJSAElACh5VAk/zO2mEl qJkpASWgBJSAElACSuAQEog4hGlr0kpACSgBJaAElIASUAK/koCKtV8JUKMrASWgBJSAElACSuBQ ElCxdijpatpKQAkoASWgBJSAEviVBJrkCwZjxoz5lVg0uhJQAkpACSgBJaAEGgYBR0VF6NP9DaM8 B1QKn2/Pz9CGRywv/zUf3AhPSfeVgBJQAkpACSgBJWARiImJOSIomqRl7UjBPCItqJkqASWgBJSA ElACTZqArllr0s2rlVMCSkAJKAEloAQaO4EmaVmLi4tr7O2i5VcCSkAJKAEloAQaGIHS0tIjUqJG aVnb518oOCIYNVMloASUgBJQAkpACRwaAvoXDA4NV01VCSgBJaAElIASUAL1QqBRWtbqpeaaiBJQ AkpACSgBJaAEGgEBFWuNoJG0iEpACSgBJaAElMDRS0DF2tHb9lpzJaAElIASUAJKoBEQULHWCBpJ i6gElIASUAJKQAkcvQRUrB29ba81VwJKQAkoASWgBBoBARVrjaCRtIhKQAkoASWgBJTA0UtAP91x 9La91lwJKAEloASUgBJoBASa5F8wqC/uXQaPQiAQQHl5hUkyJj4WUVHR8Pg8xi/C50WEIwj5SG8g GIDf70cwEDRhjV+Af3A+WMbz3JgwVtiq8gUhDeCQH4cDjgiHCSfneWROOIJOOIISwnKSjqTH4CaO 7EQ4neakSYPHEsbelxMRASuu+EXwxxFR3aBqh42gv5wXF2AazlA4Sc/HetpOimPi8Lxsgyy3lDHC YR2b9BlH4tku6HAiEOEiT/EPmDpIfpKdpMHfoK/Zt/zpJ/F5TriIY2jzzz5fc2vCuUyC1epRWSe2 pQPkaZfT5Mt0Q/WIkHrwn2EUCmP8uG9vrfJWr7+T/K06WO3sd7GkpsxMzRSnej2tbKVOVltK3axw El7CkmnAStOuuykZ/U1ZmbZshbfL5WKfjEJsbCwSEhKRkJgA+QsescEK5H77DXLf/QQZhUVw+UvZ 1xgvEIliRCLX6YA7UMw+a3WOCGeE6cOmHkxX2j6SbRUhbcLf0mPkt9UG1u9I+BnGx/M8J4xYPtl3 kYfdd6KlCeknTtrXzzawu4VVZ7+pu6Rv6ignQ9eQBJTcA5JrqA8IH3HSh8zWDmuOrF9OF68HO1Px CoWRusmVYurD8yY/HkttXD5ew+w7PgbgVYtyn/xmGJZX4vtM6a16Sv2kOFIWthL/hfp0iKUVUc6H F4Jxqy4HE2SPXw7JyyTMjRNFAT+KWM9CVjnXX475BTlY5C017ZTqjMTg5AwcE4xFTJkHrvgoeGKc 2M6Pq39dnIWlLrYtk+pQEYFRKW3RKzYNZbt3oyQyAWu9hVhYvBU7wHgsU+uoGHSOT0W018/6OOGP cWOjtxhzi3ZhV1Da2Gl4B9hnYqSNowKIdUXC4fPDx3ujMEhh/2kTGY+2sYkI0n+3x4MdjJsbGYEd njKU8NhFaDFkGeeKQnR0CspZl6CnGG2iYtHaFY1oFrg46ENJFPs0++mK0lzscnoQ8AXgImupT1SQ +QSjkeSOhdfhgbesHNEsk9xH41j/5MhIpEfF87brxSZGcDqjUFxSghTWSdrJEefE5rJ87AqUw1MR RAHLCH8QrSPjUEbWO1GOCjZUFGvV2uli2aKQnJmJ0rQ0/Lx0LVq4knDWBeeh45Be5vqIZLk8Hi9/ PNi0aTO2b88212FJSTFKS0qZd7EZQ5g1UtNSkZaahg4dO8DtdsPn9WLDxo34ds53yM3LxbbsbNNn +h3bF9lMJz8/H+PGjUPb1q2xfPlybNmyBTHRMUhOSUb7du1ZtwgTf+HCxfCSkVx/5RUVZBuNtm3a IJPlTk5ORps26dzGITIyBstXrcFXX89BBess92Mf+1tyaiocpSXYXVSE3WTlYfsNG3oSbrl5AjlH Y9XyJfj5p5+wbOlybM/ebu4Z/Y47Dpdeeik6si7xcbEoyC9BWRG55ubi69lfo6yiHInJSZi/YCEK CgrQJrMdBp44GMf2OhYt0lqhsGA3fua5lmkpvNd58NWXn+G7HxdgZ0ERkpOS0btXTwzsfxxSk1Mw 48MPsXD+fBQXl7DMkSyzHwGvDz65RllnLznKOC3Xm1xj1hgp16T1Y19nfn+Rvdsot46ysrL93UIa XMVEFNW8EYYXsr7+3FTfU8eaZOWikYZ3RUeZwdHn95kLFBRtDl7gUhbTMeSKpAvdvnnj5Y0gyI4k ncYMUrxA7C39RODxNihjtkSSXib/LWHAwVIOHLw5yWBiO8nHOHpJPua/hKWryUSO5Uc6sAkbCmPE C/3DnR3W3so5E5fhpPwyOtkiLUw7SiBzPoKDix1XtnY5bb+g3Gyltkyr8hzTNKVgePnH+4c5FrFn +YfKHQpnxKDZZ51Cda4sp8ThOWYhAI1YMHlLykxfEpR6yPAa7oz4kTCSLsPZQi1cnEn4yrwrw0gc 5inHoa3sS918HNRMehKRfraT81U/VlxTw6ogoaAMJ9LKhBevUDyWMbx8kraEEWHk4uAZHRNtbuYx sTFIoGCMz9mBnbM+h3PVKiR6K8yAFqT49zg4sFPQuCkAGN24UK8yfdLed1Cgm9OhdpEGEoHiinCa 6yCSMWMp1kQciZYPilgRxtyXFhQuUUxAWEpG0vdla10Lplqh60dEtNTN1NSkJenYBQswHdsdiFiz hZ3pIyZNFksEm6TJ//RCJOtg+IbydfFSDbAAfmYlDyYyYBkn1zd3vHLdyh7/O1kHSduqVqhHyXmp X5iT9MNdjcPwU6F9u3xkxeupgqyLKF52M91cCpslxXnIoqBzUqBHUFilOKPRLDIa8XyAdFCkbMrb gWW+Eg5eFUiJjkV6dCLiKCTSE5ORlJCEvOICrC0uRB7FUywFZ2pcghHw5aXFcMfGwcU0qFmxo6wM WRRRORQgZSxHOcO6yC+K/JzsWy5fKcVUkMILSHTFIpb9LsgH1zjCSXXGojAa2MU8CiikythnvAaa PKwFUeGjuKJISPa7EEmxQX2FNvGJSKVYq6C4KZMwkU6KsCC2lBcil7ErKJQD9BMBLf0skQ8baexz yWyANEcMkhzkwXutk3Fj6Z8SFUeB58OWKCdK2X7bCwvYH4EU5pHM/h/HfP28d8/hg3Qp2znI8aRF TDzrEoNcTylyvGUUZTEYmNICzRhxG/kv8VdgG+vSrVN3jDhnJIKRQSMK8z1yDVnX/a5du8xDU6tW rcz1IQLOR1HhZ9lKKILkzxRxvGXePrYR5T/Llp9fgJWrV6GkuNgIHUkrJibGXMeZHTJxySWXwM2H r40bNiA+3o20ZmnYSIG3c+dOCqQCFBYVYt36TejQoSNatmxh0tiVswsVFG0VngojfNq0yUBFeQn7 bwTWbdiIopJy8wAUSeF3zDE9MGTI8fjovTexMzcfXrk+KFJbtGyO80aPwoDj+lAssj4slwi2H3/4 0RgqduXmUQCmoHu37khPz0AbCkpKPyz65RfzwHjS0BMRExdvROaPFFpZm7KQnZODJPbFDpmd4S33 4ITBgzFwQF/WN5L1W4cnnp6M2d99Dz/FVwSvz9SUFAjLNavXoJAPGp4Krxkj7DFE7ucieH1iJAnd Lxyha1wu9JBX5XVWX2LtSP25KbWsVTblnjsuXtTSIeQmG8unBxc7cZAHcgsOOPlUaT18m4tOeoYR A6GBRUI52OGcvNmZziWdJzRgSDi/pCs3eHli574MuNLpAiLwGJde/DE2BSOSqkonudPJRgpmwkoZ rRuGvZUgtgsadVUVxopnn7W29gUg8cXJVgYkKac5lotYMuV/GYjDBZsRfwxkXzB2WiZeKB2pqdTV VMykKBHsHdmyfKFEzWBOH1MXEQx8QjZBJXuGsctoxzaDs4yTDCSMzSDNtrMEVsjiwxu7XMiWcJCY TIzH/M30JKL4ycbaCfCJM0JUhxWC9a0K42O7SZ0jJD63IkIsEWWVU4SpMOcpxg6VXVIKHYcyNeUU 8SE/plxSAHFMlz2kMg3xEuudQJcbroMDto+jqtVG9GNZpd/4OGCWcUBwFbloQXEhhULf1aUztq5f Dw9vjlEBL4JRUg5aS7xSZrZlSGTblirpotI/TRkkQJizmkf6LluTDyxCi2Mo0xNBJuXiVpqYA6AM UNKOXhGuLJ8toCSMUJU+YqVu9X/Zl2wlS2EmdTPnJUKYs8tpe0m6tjXb9pNj48/07OhyHOBgK/El RRoieG0Kd8t2WBmQZRYnvlJOuxwO9icpH+FY17sEMm3HepqySstUd/b1YPtKWvtyVn4MIeVmZvJY EcP28bPvRUbHI5aWkR5MwklRlUOLzbbSQmzylCAyJgIVbPccDsi5sV70ofVsaHwGMmJTsKliNxYV 5yDPV4hdFGrycNjFnYyeUSloE0FrE/vVOkqiDRVFKKIVbDfFx87yIg7aQWREu2llisS2YDktYxT7 ZFhOMdOSDNNo2WsTm0xR6KaI8iIvUISo+DgKQS/WFxcxP48R7TF8iIijmJKa+yk8Zc9NDm2Yr99J ZtKBKISiKBwQHUm7lg9FFHq0CyIuKpKCg/2a12GAcSJJWBiXspOJZTGBDx3JzhjuxzAv9jXeXxwU a9srymhp8mJXWSm8kVHwiflQ+mA079+8l3AOhGKKDzkeK00/ryd3rBvNYxJRXkCroLecDyG8d/Ma K6NwcwZdcPq9iIqNRGxyPFLbtUKz1GT0SGqBrII8I8BEjImFpzVFi+wXFxXzmA/z7CPSrmm0zDVv 3pzWLT5U0fLloZjaXViIefN+oBApNNY/uRajKdTkXiC9sE/vY7F1azZWLl9KkZOEk04+Cb169qTA OgZ5eXlYxYewJUuWIC4+wVyzPpaxRYtmFDnJpv5FtJQV0qq+fMVylFM4x8TEGsEoipzdHhUUiFvW r8VmxsnftYN9qJwGCbYDGyuXYvCtt9815cts3xZdMtvAS65njjyT4iwd69dvwPwfF2I+hdju3UXo kJmJ1q3SEMk2O/e80WhO4ShW+379jkM7WgF30XL46adf4tNPPsOyRSuQ4OYMAMsjD3pdunREi/TW OOGEE4y4k/tLUSHLtnkLsrK2GH4+puVnGwbFEsq+Kfdc+bEs9XJdWz8yplZdZtLrxEkLNH6nYm0f bZhPk644L5+QYvj06OSNxUz30GoRkJxeXFkAAEAASURBVE4jcyYcwUzHkeM9nJwTT2vwkQtE9uXy lfuHXBS8Lo2LotVOOrc8FXt5w/PJE58IlZoCJxTedEj+soY06aBWHlZq1u/KwYEdWXqwGSC5NaKy esDwI7Nvd/7KE1IP5i3ZUwPI9WIdMz0j1ri1znJDJ/HtrfAxQ58InnAn4sOkyS39Izgw2M6UVQ5C USR5GWhFmMgAK2mKMyKAuwHewI3Y441d4gbIkr8Zlm1EyGKhlLSCFCrCTNpR/G2haRILZWYJAmk7 yUu4ykBtMRYRZqZyWSApmjCW/ERsG5FIPxEFwltELZMwTjYyqEsXkGnjqvaw07VEG0+YNK1oJgcJ auoreUkfknJJ/c1NPSApMs0Q7wAtXX4KKZ/XBQ8DR6Ymwd+hA7b9vBTxLJff6aUACCCRM/slHJxl kDNCyyTCdETocN8ISDKUohpRI4Uw4lUgMgDzEcIydeRluGg+yJjpQcFKoWjUENOSAVSuFYePtkIR nMIm5ISPpGXyo59kYUQuPeWcHIuz+cu+LcxMu9vnOPjW5kx/4Sl5aDKCnDwkLQIKPYSw40j+9BMx IH3UYGSdWFLjJ/UXJ/nJQMAqWawZRgLb150I95rOiN4wT/thpNIrlHblcWjHSol9ivnFmH4l04J+ JPL6cLIf+z2cUnPGIxAfRNbuHcjeWUghEwl3RBSG0pp2fEprtPbFcEoxgN0U5xsDZdi52xJbJ0Yl 4Ni4Zkjy0rIq1w3FdCKtSiWl+VhJi0w5WaVR4PSISaHFLMFMvwaKvdjMPiMiKZJiJ8kdR8tWPBIC nLqkZvfTWuWkkNxGAZnno7VKHjjJUwSun9zKKH5i2J7JrEtCpJvToLSE8V4gFqZ4ToF62T82lnKK tsJDS5cH0ZyWLXVHIZ71FNFURCsUo1Lk0apHRrv50CH3ZAeXpUSwLIUElkdxJFYxL8O5KBgiKcYi vLx386G6iGGDFH3xbKNmcUloHh0HmZ538z6bGyw1ZfGS1dqSXdjiowUnggKR/kWltEwx42g/lw5w qs7lc8NfXkZrVj6ngoPIZmlENElZZKpVrGbxtCaVl5ejWfNmaN++vRFmO3bsYL8NmOlAeSCX6Uzp O/mcHpRpS0uIBGk5i8cxXbtiN6cIZTnD9u3bKda2Uai5kdkhk2KvGcR6t2nzZiO6EhIS0KN7dxzb rx/LVIQ1a9YYK1QZRbv06/RWLdGR8co4Vb1lSzbWrl3LchAg8xZLqJdTlbk7yvDFJx9RRLLPk5Wf DGV8ctBqm1+QDw8tuDt35WPJop+QkhBLYbYbJ554Irp164o+ffpg9aq1+OijT7Bq5Qps2BBAs7Rm +O77eejdpxenehO4RCfCMMqiRS+GVtjBA4YYMVuwOx9ffvkl5s79HoOGDMSgQQORxOnPjpwu3cI6 l7D/eMUCyXudn/cMue7kVwT7ilxXZkyRevDHvgczBJ0EtC4suX/INW28zLnG/UvF2j7ar4QmZml6 GVyLizjw8KKMpKiSzuHjvt0LrBs2p0NCN1/ztB7qSJKAnLdUiTWwS2cycUyn4mAtNwROW4j1RC54 3t54XoY5huTTaFCsFJIb05QLzTjGsdKVwTWUsXXGDL724G2VLXSCG9vfWPakXHS8v0kh5XfleYln Xwjh/qZQUrdQlma9GsNWDZ6hNFk+Oy+TcFjacix5mjRMdeRXKEE5SWfqxq0Z0C0fMrAuTrlQzeAp cQSSJGa2ZCGJ8qI21ZEkGVaGfrlLmTrJ9JaMwPSy0pAd3tglgoTn1pTGJGDzMC3B+kgAi7vNhx6m nlJXUy7Gs8SaFEnCi7PEh4g1I96Yjj2FKmclLTuuCAc5ti1eoUIxj1D5Q1tbGFrCUqopbCSMSZGD MAcqsUWwv8Z07ICdq9bR6sZBiFaLBN5AHbwBFlOSyM1UfkSQUdKY7IS5lCGZ5YzilJVYmGXqj7dN 3iyFrRCiJZg3Tg/7pof/pI9GcWpLauri07KkKeJORJCM3dJ2Ukdxkj4La8SmnZekLs0iLkhBYtpA 8jIpWvGssyyiHdCErX7ODmOLOjkO8hoSMMKc/7nLKTn2A7GQyo1fmtX0demzEl76D/MQAS7n5Old ys6gho/UQEoW6lmShYlnHoKYj1RPnOlTjGOLNttKbZ01eCSQHdykX1VvyYXtyepJW8i0LUvBsghr tgtvNhW8V3jl/iDl508y14udnkDrjSMa2x3lWFmYg2W0qgmhYyhSYrhGK4kWVU9JGXKYa3aMB9to MVtLobSDaxrFIhxPS1haWgskcV2YWFIiinajNSsuwm2bWJmY2m62u59xnC4Kda4Fy6OAySrLQx77 Xznr4+aatFjhRWESw4K5OU0by20CLWzxZM9WwC5WzMOwO0qKzPSm8I+lcKP5iqKL06ecooyiwE+l 5a6UDx/lbK94saSxHoEKWrEoQHPIYkf+NmPZqxDuYrVi+pEUQPEB5kU2MkUs68qiInxoTwHqLvdx +lamTBmefUHWpxEqdlKAlbFMxQwnzz/GQkNusXExcFMYR1BYBSluYlmnbRQ9K1eWYzGnassoApOS kpDN9WYinhIS3LRutTQiLZIP9zIdKRYu2YrVLZpr4BIZzkMrXAmtoZs3bTbTinGx8cjg+QoKVrGA nTL8VPTkui05n7NjG9avW2+mP6MopFu3zkDnLl2wguvYUmmx27F9B0rZF8RaddZZZzH/Flw/twnf Uwit37DedM44ikhBJA9yssbZR0u7MJDrz0cLYCQNENFcK+ijyTlIMewrozDntGsUmfbu3QfHD+iF vB1bsZpTkv996RWWoQ0Gcxozg1Ogffv2pVVsCEXZDmNpe2P6m7SifYp27dvhRFrLJOM1K1cx3BCM HjXaWFhlKdG3383BokU/Y/bXs/E9LYyd2rcxFsm1a3ivIge/PJiw3xC5EbRSVnnwk2vRvl/a9xT7 mmJT08lVJM7ecremocCcb1y/dM3aPtoro+sgdhRLKMk8voM3SKds2cnNdCX7Qrhlxgw4vMHLTV5u sNJXRDzIzV9uRuafuePLHs/xR27AcsN282KSxeLlFIFiIpdpJOmcYva185IEmVSY4wE92KXD/Jic DDImH7lOWGaWIdyZgYn+4WUPPy/7MrCZLcOZuoif5SGJmsHBeMh5+lvriqw0K8PzXHVX/bhaVRgw SMtAuLN4WnFknw/1xpkcuW8sQqE8LOEl+ctAy+FAymX/VDuWeAzHwc+ymkk4q71MeN60mEBlMSR5 QWnXSSjIYG878Ze8TF1MGzN9tmM4cuEtKRrLmoRl/oxUmWZlOSWtEHdJwKpfqC8xflV5GVfim7JY UMLTYDKMzjKwr4pgSuL0RtHCRdj58yLE0SwTw2mnePYrL8NIHiLUZIpLFnFbVjThF4EWtEzEMw1Z WyQ2T1l/5pLw7LMyTSdixcMBTm68cp3I9EoUrWpG+DG+WNhEqHBXzC/mRwYLOS9QTV7cFRyGo6kP 90MdQ2om4lCE4r5cuDCrLZyUU8SV5CPtLslJi8nCdT85SH4Otplct8LA5M8w0k4+5i9izTw6ieqR +nBj0ec+E5P+JlYw27pm9z0JKGWzxZpEr+akHBJfEmReEeQnTg6Nk3JxR/qNOFlLJ1Oi1AcopNda TxF+KdyFEgrq5mktUc6po0xae5wpiVi+azPyaSVJ4hqyDgmp6JTSEr7CUqwp5AJx9nEnrTXZXAe3 bjen8VinNK7RahvlRnEphVckpyBZp3jeh7omtKJFhNN25LWT04qrirdjDa3TGYyf5oyjFSgPJay7 n23NWUVy4pQtubo50KYxXmtOLyZywJfF4BW8p/k41SnTk5vKCs29K5bWMoeJyzQoYJKYr5u9rVms k+KfopTCZWPJbq6f4z1RqNPiU0CR5qf1K5qWvmheWS6KVyc5R5FTelQSUinymlH0uZwBVDDNGK5h k3tpojseO/jSQjbX423jCxQ7qcrKZOBn/VMj+fIY0yhk2lLO1hFx6EChGMtz5byGVlQUwEfh17NT Nww841REJLt5DXHtJ+tWyOnMLz7/3Kz5i+PaP7FIiTiTaU8RcJ06djICqmvXY5DEBf8iwGT6sJwi d826DVi2YiVatWiFDnyoEuuYrNMaMniIsdCVkVX3bp0r05KXGJYsWWymC+UlhU6dOiMlJRWZHTry Qb+ULxfxJY92bSkgEzmOeJDH9dYLFsw34m3psmXGaicvRBirlcdnrJht2kr4GIgFUNb6lXDtoNiW I8hk6Kmn4drrrsYxHVtztrqcYXYy/6X44osvsWH9BiMse/XsjYsvuYjr3JJoeStm3X7EnG/mUNit 4nRxGsPE4IwzzsDxJ53ClwRKWeY25OOjwJTp4iJa2L7Cq69OY9pbKRw5s0RhXkGLHi9NudOIljb3 YPNgyvaxHpxCNwlzZVT94iNk1UGNPT+tvvXhdM1afVCs5zRk2sa6TfJmEMmnEd6I/DL9IwMPL2y5 qYfLJDPgcGDz84Zjbua8eURyYJexyQwA9DWDF28dMoCLUJNpKz6QoqScdg4GlIFBBj+5TVuDe2i9 UqhusuZD8hEnC1TFvC5P3+FOBk570Jd8ZHixYlihTDlDaVgjBf0ZLtzZgk624kx8iVMtnPjyvPGX UFInjjv8kTzsuHJGjiVYNVctLalP9TJIpn7hbHJnPSiWKx2DGslrsmdeDCfCxCRBJkG2QaWrdswy GvOWnLWEkFiKLF6SDssq7RUqrAg5eeuqqi4i1CVzk7tVL8mL4S1xFWpjBql0lWHFR+IxH1On8Hys drWfGEUsWX1FhJ5VzmpJCheD3+IqYaTgxk/KwjqJ0Jf1Y16u1YntnAlwka+fa1E8vPv5OI0TkH7C ChvRJAMey0T5ZuoroqyA6csgHU3hyCXsnMri0zdZRrGVrSuDZWOhorh+SBbEywAq14iHT+bi5Mbp pCCUNwyFoVTZCBnuiNVFLE3C1eozPG+CWK0t8e1rJkJ4hzkRqnVxwlquNbHYmTozulix5ZqW9ZDy YGSWXLNMURRzkbQuSfsKf3lU85GR6ZssBotIHzpTBIu9HEqrSl2k30hYCWf3ITkvTsJUczy040h+ ctcQZ4eStjRxJF36RxOU8OP75bxYHOgRmYiWCVF8+aCCQiQZO9kGn23fyjf6+FYh69uefgNbZKKZ WH84+LncMfBHt8M3Ozdi+c7NRly1p1gaFtccLeISsZvW/BUV2xHBabxdFGQtklO5To4PUFzv1Jxv ekbxRYCV5btMn9nJdUq5wWL2eebE6XQnb0JOirQk9qAovoGZyGnRVLZ7KsuU4OBaNFp4c/nCwPrC XDONyUdQvrDggIfWLwenOYV5M4qhTlyAHllUhkgPxW8iXxTgOrg4vqTlp1Uvn+1QIfdLc4GSCftF sghV5tOC4iyG/i6WoRXfim6RxLdN2Tm3lRRiA9f2ZRfnI1Ag1jzmzPtIMJr9tYyWP3IUQS7WvxZ8 izSfsym7/WV8C9SNnvEt+X5YOTaReIDLBkSMN2ddBrXphJbH9UDOrjzk8EFIpjUHDBhg2lvaPItW LRFr8hakTBvK9KN9b5A1axJG+l9SYiKngkWCcnqYL4DExsSZNx5bZ7Q167xSuMBe+mtcnAu/LFrE N0bz+AJDnFkzJlOm3bp1M4v+Z340ywi2jIwMDBg40FjDNqzfSLG02rwIdxzf3LzwgnPx5ddf48MP ZiJry1a+6MFrkyIqwIexM885F6eeMgQrKRoXzJvHNXLLkJOTi0QKviEDj0PzVHnDl+HloY3COiMj HX2PPZZimNPNrM8ilk1eIBg4pC+GDxuOM888A8dyivSlF1/CDr49upMC76UXXsT3C5dh2PCT+WDE t4njorF18yasWbWadViAMq6fK+W0s1i75Z5vpiDIyawzZrsLJxnrguxn5l7MtjCOYfZ09hW055nG 7KOWtX20XptuQ3jjlXU7vAmwU8qTttyIjUiS2yg7lbwBZwYcdiRx9kVpDhjWJU+x7FCShjyBS4ez P7UhA7M1vDEdhrV/jGlXOioTkQvZ/JNjesiFHp6HxHHwBhYaPbjlAMMLXMKIn1jlaoo5OWOclaC1 z3RsZw8yZit5yj9zoUgZRGjQmcKZk9ynHwc52cpgUpsTbzvd2s6Ln5/TN+FO+JqBmZElVTNksfCS jvknW7aJvW+F4KDHupswcp4/4ceCxfKrblmzrVbG6lUjXnh8yYuP95KV6QuyI+KNUfhTlW94Pezz 4id5yxuHko/UyUSULZ0RMqGyV8tTEmfomn5WHU1Uk67kL/Uw4WTLMsqkk1hkIjnVEVixFvlz5nKf 62siOUnKNZeSpwknebALiwiTH9aE66W4wF1u0GbfwYXiEeBElbG6RHOwEX8nrRNSDl4FhkeQicn6 H3m9Xvqhg4OplMFFZlGMI2+Sil0yYJ6c5eYrYWg9k14u5WdalkiTGssAydktKViYk/qFOyPUwz1q 7Is2lxQkPWk36cFiRbN4GoMfuKTefIqCq8JoiaG9huUQK5bUQ9bkyXVueDO25G7ty1bajQwYTkSl 5CHn5IS0BaFYXOgvC6fDHa94hrfCSjx5sDMFtAOFQMhGztOQxJ0IlFMcyRuSQlY+YSBvjOZTfC/O zcb/yuXx0Zrq69UsHW0pnFLp4+aaWw+tEj8VVWAxP8mRx0RTWM+BiRnIdHDqkW+K/lK2HWUUMsdE pnGKkWu2mEv7+GSklXPKnG25KFCI1ZyejOB6N6mLWS5JwStrz9zMtm10AtrxR24FhaVFZjo0gdas cj58birMww6uR6vg26s+9il/RTEtvFz/RuubTJvG8f4ay6m5HqnN0JpLQlaXFWEtxd1GTpPKfVM+ Y1LAzuAj10hOt0ufcdO/PdeTyWdJOqQ0p6XYhx3ltMKxf+/kyxQVFG7yNmmhXAvMM5a3yUwKsg7x SUijuFtQmE8LG9/QpCDLiE+hyInC5qI81ocvClCcNqcVL0C2udSr68p2oyWPT0zNRM/Bg3DSxMux hSIwa91WMzbI8pUOmR0o0PIt4cSpSllzJv7yJqd80iIrK8sIuBy+FSlr3cTaWFLMt0PJIYYvsEm/ SeEblqNGncWpx17mcyDdunejhazIXEsyLmzbtg3Tpk3j25dt+GIB196xDVev2UCrViu+DdrS5CmW PnmhoT8/fSF93M3PnKSlxqCgUD7LEcCzL/wXm7Zw2jYpDX34mRARSJ3apfNTGf3Qo2sXzP3mW3zD n7yCQgqnCIbpj67HZHINXDPpgPiZ4szJRj7n3HPg5ssNi39Zys+BfIkVq5ey+wZx3HH9EcsXFdq3 a4cRpw7HN7PnYPLTT/Ft5d0UnrG0EqbgwvPPQQ75fPThDGzbsh0efmrFy75dRlEm1j25/xCH/Oa1 JwYSGWetPidjnuRjxtOwcYuFYzwZC3m+Fufnm8j14Y6UZc3BjGuvWX3U6hClYVsf9pZ8fX26o13v k2nlksGEFgVeyF52GtM3zE2UPYkH0nFEEIm1zUlhVjmQ8CYtFjKzKFAiyd1WSPOmIQOFvCUqo1KA SkoGBumIkpa80SN52k46q3Rc021N7+UAKTcfqyebYDLQmZ5tR+LWvD3IMPJkJtYVYxkIOy9PLGK5 k63lpIySm2y45U+4E1kpYsAE4AkjKHlgDUz05lMWD6QkobhMz05aEuI5kx+TNWOOnK6WhRzIU6cJ bMJbolVStJw9HSRhrDIKb7ussuUFzPpYg7DlL+H2OGY9RDBbcbkvYUzdWEZRB8xS4tjx7PzttKLE 8mIcw5utVIb/han844Jry58njZ8dWrahPKQOsm9VuJKbxZP+HDStOlpbCW2Xt1IUSnOw3CaOlUUo jMThlCVTdXJRulh6xfLhpjVk0+dfwJHNAYY3LqmyLFgX5GLXkV4nfvKZBq41Zhmku8r0qGVV45hl pp1i+DQeRwYyuZTExowU4cZw0p9Ftsk/L68JDx8idjOMtIkIkSiuOZI3+sxbfQLIPABQJDGelML8 MK/KejOIyJdIpmVcCKpVYiFSzTt0tOdG+llle/C0iSeAWC7DjnzEChOkgJQlA5FccyfiMsByGbHG csr1I1EkvCkn622XU9rFWP9YTpNeqAjmQYMZm8GFfpXXYFifsEtrysRyiJN92ZO6mzzMMfsE43mZ v599g3eLkHjj2jUK3h0UP5v5iYoFHNQS4txcHM9vUlFotE9MQzrFST7XKi7O24Yi3l+iOdA2czej GKAIo9WqhGYjL0VLOqcs+/LbbZl8cWA3P02xIGcr13Cx7rTAbOaUajYFWJz0D1qXKDVQyh+Zqmrr ikN7vpHZmvlSWZAhhSlFXAHFUxbXtuVQpPnZZ1x8GHNwqjeC96RYZzmnLBPMpzdcvHfK9ZfeKh0+ Tt3tyNmOxd48Wjuta4XLp+CJ5rph3kyDfNJJ4MszsnZJpuM7Ot3ontCCli++xVqaxzdXy5DLdpMV xeksh0xvu/jpiwpabZrzpYg05p9OAZtOS+JcfmdQPodSQk4yXSxW4Vxa1ZirsdjJOjt5MPfx3uZh mVNYjnYM56L4aTd0CCL4eQs3p5jT+OZjEkVmZrtMsz4umi84iNV29ca12LRhvfm2Wq9evTjFJzk4 sJRvcH49e7aZysyngGGTmHu+i58aiabIiYqJQufOndCJP5dcdgm6dezE9Wqb8N1332ERlzKwWrj6 6t+a/rBs2XL88ssyVjSCLyd05qL/XnyDttyEXTB/AcM4aPXri1NOGUxrWT5ef+M9rNu4hW+dxuP0 kaNw8+9uoijjJ12WL8IH77/HT2qUI4rMrr3uegq+VHz22deYPftbis0c9OzZ3byJKgJx5MgzzBo7 eSmukNPvZkp39TI88vAj2E5LWizX4N048QaMGPEbjosOPPTvBzDrky/NixE0WfBFjDjDo6SohEKU jHntyUOREBJhZu4NvO7MA5/UWCotjmsKeRkYF7qErYPQb14d1Y7tA7l2Alz+UR9OxVodKB4usdaq 54mmVPLJjmh+X0g6keQtT5L2pwnMTZahZCpJvn9k3nhjZxLBJQubxXQuHcUsLg7FF/Enb0rJDVkG NjEvW+nwJsMbmzH38iYhzogyc1YGC4bjwGCt9ZEYoVgccCWcPVCIEBGxJsdG8LDMUgb5ESd+sm+H l5uTSc2kYYLs8Uu+QSUXhzgrLRlIrGP5LdNg4iF1knFbnKRrHDeSgyw2N5HEm/mLGAp38uFccaZc rKsMblbJ7FASX/5b6VhWNetY4pjkGcMWWZYfyyS8zXkRutaaQ/GTH2O9k3My4HIrYs3sh86bsjB7 Ow0TL5SWXVbxE2czDvJVf6uKVv1t7iaQ/GLxbWeXy24Pkx/PB6RPhOUTnr/UXwSIOc+87XDWVlI2 hMxvsWyJ1dPJASyeFoPARi5U/uJLpPJJNsi1SbLeJ4I/Iug4BrI3Uhxx8JQf+bQCE2dcmR7lD0+K uIvkcRSviVjGkQFMPrHgpniLYR4iY9nShEGbMftZPgc6WRsW4IOLrN+UqottTcSQtUaM0yvSylJX nmNtQvWx+r5o50jpqzwnToQfs6k6pp9F2Zyu9Zewqi0MkzIJSXuLtUem1cQKLemLddGypIuVkD9s Ymll0+d4XsJZIt/qX2a9mkmw1iJUepqHMuZTm5M3J8VJPnIlGCsnC///2XuzZ8+O4zCz7r5vva/o HSux7yRBgqDERZQ9IiUNJcumxhHjGDvCkv8BPczTxDxMTPjBM56YmAhPhMWRKIqmJEqQaBAkSIAg sYMAuhuNRm/o5d6++74v831Zp27/+rK7JTkgimCgun/3nFOnTi1ZWVlZmVlZPlsWRYa0z8aY0ly0 pbNuc/TtHOrQyyRqY1fdAOq/4WV2ASLZmcOP1QRMlH6/DiPBOrxtd2ru6k1vDVxKx8YwTodhO4gE 7aNb9qatC+w6bXMncVN6c2o8/fXwmTRAJzSAI7dgoL+P3ZxjK0jYZsbShAsK6NxhHNxuCykZvs+2 9yGRQxI1OJDG5qYx4GcRAC2yyU20RSa/CwnVFlTl7VxbwY9uNkbMQO/eQ0X6HrtSZ2jdJCrZLr7r o/XixAwT/gT0dBFmq5NNDar457F50nmtsFEKKr1A6Ji6wPlufgddqCBoaUBy18QO01YcR3fiNmON 9mpX9hNdn7BomeHbZnbksN8/GF/2Uofbmx7KX2LsTKs+Bwd2kd8RJEndSLRmutrTIRzHnkdC9s75 C+y2HU9dtGPXlh1pc293uuOuO1LHps7k7sZe3G704iD2+LET6ccvvMCGg+k0xndnz73Huz7GQnM6 cfIE9mw9oXocGRthA4IGCLjYob4Hdh9AWteXHkTFqXuQhx56CAivIv36ITZo48wt9enjH/84Urfz +Fx7h7Y2pv3sRN0B8zuIOvO5Z3+AdO8YbWiEIcI9y8RsevzTn8HO7LfT3ffcEvg9Oz6MqvUn6TtP PR1lWMe7kbo98shHmUsasSt7Oj31ne9g0ziLS5E7sUH7DLtCHwl6evnyEDtBz6Q3Xns5XbxwiZqx eQX15+j4SLoLP22/9sVfhV6tpP/lf/5fgceh9OKLL6YRfMQFlktnnBfpO4Ue2czIZxAZnLmadsrU ZxMLPr5OcFT8dDCfD5m1n4bLP3iMA0fifr3wfknW9t79OEwXkwxlKfaNCTXIZC45GzyKbDJmqDzR 5+ucVOKhAafY1uREIaKAfHElVnsgg+1Q8hXU2OdIgxTM9omsfJsnMSYO8jDCVbyMmGX4znizMERa 4mQYi6rV906KmQHMk2Jt2rgPsk/+5hmFUucNEwpKHl9HebZb5iGqZAZ8v0qZuYZkU254k1saicx5 PVgv61sbchk5zncbqkBScrOO/mpyC+aKt1lyl/MtzE2BSXkO2FF3n/0VXDKdz1Y+JuRSDldD+a6k 82ooz/FQ/QETqv7K8FqXqJT3tF0Q2YcG88j9m+99xkbapsY7/lb15SrDzgtVe7ls4WGc7angwntz 9nunulVwV+mVu+B62Nbf/8MX0szp0+zYW+JkA9rGJMpcizTEcsEvKiezptTXTrae9aRhbo587VPz bQJejaRxB2EXE1lPXUNi31yoSt2Bpz3cCszBCszaIuNI1ZnMhejK/EK+7g7E5o1cufBlVe+oe4nL zBpRkUbAydOIY37zdwlUPeBdm7bAXBympYG/sWiyybQ9zBv8jrYrYQt4VxnksoEJNbAugVviM+27 UbCPbsSs2ed2moxfwJxHmVWZNl/ZYtsS98QbQu0Mo6nTXmnOHGUI3xX6XEbkbyYupDexuepcbkyf 7TqY7tiyCeZsIb09fCm9h8qvhf6RSVFFuAeXHm3QsJWm5dTPTtCjM+OcAoBHfCRp23G7sBXJ2wRM 2v76trQG43MB5vAS0ixrdHjnTcFcjTNBn8FwfgZQaPDfhOq1Cbh0Uc42JG8ya3AHOG3uSC3snLxE fidHLrOTFDUYwFymgfUg2p66DvCVdDxvhjnrhgG9iCr19AynGiCxVUZiv9QrBaXOnmKwBZXq5sXG tIldr7vZNbppB6we5Y7i+f7ixAgbJPD/hgRxRX2yyAzAJ8FZd7c26H6EHp1nRSLe9/LUB5O3hIRs AMYJnWp6AL91n0AiuQajMdfTnnpgRGZRD77+7jvBlMJLprH+oXDuqz86OccWvs87RLel3bv2pA52 bCqZOX78OL8TaXPfFiS5LUGzf+ULn0+PfeKxdAm7w8npqfTqa6+E3dn48GQw2tIIfbTdxe7M21CP PvaJT4Q9mMzaJMxVC7ap+/br520yvfnGm9jSXQSW7OZEqjdBv3zzm3+B1GsYqVp7uvm229OXfv2L aTubGfbs3ZnGYa7fpk6f/5XPciJKK98fDcP/t4+/E05v23GRsmkTp1xQ/gswnLoUUdV6z733pM9+ 5jPpKJsXzp09k/7FV74Smwh0lPw3334SqdzT6WL/Weq1N515tz+NjLDrlk0s2qUpTdNEpNBH56hg 1rgWenj1wHVcOK/eKFQDY0MS8/uQWdsAlJ/FY5lgr1fW+8WsPfi53w4bA3dpykgtuZ0YzkhjR3eR iVxXyCiSNRgWVSgSXEXeMZkyEYgo/nOycrdZk0a7pAn1KQSW20jjNOZuOaV2ZB7Ni/ydUMiDv6Rl ioCoOWkH4Y53GRKW56+J+sqseS+s+BNX84g6VYxKuTff8s6cYvKxUjWBjdzxZDrzdIDFhEJdrJNS mPhnpXgXQ4Y84sqXTkCNtMkyDebjrzYACR5tW46lhbWv+UgpUW5jpFt/K5T4iJlNAm4Ztb/SHuNi Qo5rhk/tu3xvFfzezMvVKBki6mb5MnW+zYmi32uf0b2st29DC+K7TJxyI4VhwBRYrNeZVGE7lzNd LyfDO9ejMGu5Tjku1yfX2bbEj/5YsZ5UuRX4NKEea4FgHnvm2dTLJCZT1iyOMEEto8b39AUZs0a5 NwmjHHPpEO5tTzArpFM6zEogJF8dSCY6+a6Hib2Tlbi7SLVPawOf/Z5RAHbj2gGdT9jskb1taGei cUcft5n5CZiTt+UIbwpsZKz5bIh0TLBiVtSDuGvBOBJXf0TJjSHGB/VyUSI+A4ZcHjmbu/UNY2eu 8X2VR+CsfcU/x+D6GCAPJXM3CjIWZdF0rUrruS7wLHJnfK2XU8EjyqzurS+FiSfL/gCG9Z1qQFIJ E+K5ND/CrcVLOMVdgOnY0dSTDjduZoMBricmL8GMLqZ9PZvSPtR4TYyr8/j2eo/dhO4SncQ+qx/1 ZSebBPb37UwTC7Pp6PgldpE2pMM7dqWHFrvTJGrV+e6O9PrwxXRBxgQVXh27DDsBpApK5UJ2UAdS HneDtiIR2tvZnfbBnKjleg2J0EV2sk5QD+vvDkzhvpv3+EhKj873pV5spCY9Ng2Gbpq6jaPqHGKB MQiuTrHTU2zspe434VpjP7Zyh/u2pw4WDRNIzaZhMk83zKQBXHKMK5EDVtLNJiRz26G/29ks0bTY lC7CvJ3n1AcXWMpsZpA2LyEFaqaSbSCoOKgK11MTHujsS/fBOGpThwY5jTDG9v7+v0zDMKc7jhzm iKihNDc2nbZidzYI81MHs/bqqy+F01t3ZWpLpsTK0wv0xu+8so1doGBS7Bb9vd/7t/hdmwdHltPe /fuQrrEDlvnmwtmL6etf/3q4+BgcGgw7uHLE3IEDB9hdeWu6/8EHsAdrSc8//wMkdPja++gj2OC5 w3MoffvbT6Vnn302mKPDhw+n3/5nv5PeOn40vfzKS+D9EirSx9PM6Hj63f/hK+ngwYNRr4lxYbKW nn7qu+nP/uwvcGo7HO++8IVfTbfgY03G7pvf/GY6euxYaodxP3jwUPrK7/4uR0yh2mZjSm9PZzjo bqCfvv71P0z/13/8P9LIOO2WQXP+BL7iejBr4G2MK/AlFjPgfZkbyrWMq2yTVp6udaVjrhHM50Nm 7RqA+YeO+lkxa4/92r+M3Tyeryazphdoj/BwS7QM1TJbn2XcZLoy6eQvg1si6nvdBKhC8lund9g7 qCurI3T+TnQaB2s86RcawIJOGJ1mtx0ya7JrTkj5sysIHGVYjnmD6E7KhhLvBCLjSESU5wRRgkhb 0nk1lOfqIZ79/kq8+bGadmLzX5Wf72PCou6uVosfKacy5y3JKblHO+oZnB4J44Tm5BeDsCo/kvFH poLxS5tlBJUo5DYXlg9Sy0sT5HpH3WOKj5o726PAyHZDpe5RR+BTngVVYWSMq22n8SVduVY5r8f7 XDv5m06ia1j/BmaChwx72iIUDL43aEeSIZPjvI9+ibdVXNVEccNJxg9K/l417rafLSeufFveG+cr 1eU6A1Y6JDPtyQVK17qQbJx79fW0/NbbuEnAloxJAT6NSZM+oCzV0W4ccP+zBZf6e1fuJbTRSQC9 gTbiUzPYeezcw2O9dm1KeLeTTKbN5oDx0Vv6bWuU2eMbd4U6JgwyibYl/8vtE/9ZKsX35hE/2+UH vAtICp8bhZz9VSkCVva37eW9k4e5Ud2oo/DVMTWsZbS5lKuj6iJ1tp7BvFMfR68Cm6hPVZ3sl+9K sYIsA5A8apGoShKOtqu2RXlUrMDCJCFVL3WsvpfBs7Pd4aiZQZ02r0yIk8D+IrtB3mFyb21Gzcjz q+MX0gT0ZSt2UY/u2JP2wVh3s7Bglk/vQYt+dPEckiukbaS9rXtbOti9JZ3GncK5lYnUzM7FNdwu 9JK+u6UnJKRYxaV3OWfzPIzREowJAjkkeNgx0shu7K62sLPTM1cXcQWh+4Y2nNiOIzG6hHq1nwbK jLbwawZ6fTAWXdiSIddLvTBSH2ndmU7ODqXXJi4mnGYEzNUQTPPdVDMMPnDSb1wT/bYFlz/725H6 AKNhVJsjsTkCOkVfiRrakGon2QZe7+vdzAIBJg/HuIOoVk8grbuABNGTDfy3SCcqEe4GvihMKRm4 cq/0t5PFSx/lcvJouLxYRtW66cGH0qF77k678Yk2yEkEjz7waNq7c1c6+sYbaWCwPxgn6YNnfc4x fzz33A/TsaPHkTCxkYG6i5r15KPT9QMwaPosux9D/8ceewzp2kQ4jR0eHA+3Gr+KDzXdbpjXt771 rWD+dLexeQtMKhK7TZt70pHDB9NnP/fLSTch+kTzlIG3jr6No9oX046dO9IO7OzU5nzs44+me+6/ Oz3/w+fSt//rt7Hpm0v3szFAZmzrlm1xlJS7WV955bV0x+234+R3K5sInqH+z4U7kk8g1evq6kh/ /ud/GSpl1aCtqIdvPXJz+t3f/Qo7SLekd08eT9/682+k8xdOp9Mn304Tc/hxc1VkqMZcCCyc65ww xGVexNxgmmsEbW9rw8a0+bkqozYh9x8yaxsA8rN4/Fkxaw9/4XdiYt/JatLBpPjardiufpzYZ3Eu KQMXB8qCHxJ+/wUjB/ELjBQRYyIAWbiXnGuAKhWR2XOaz6J8pkZsSpa0WVNqB0Ep4mEn3fLsZCZj 18RkqITHsj1mqCCtk5D3hfHgQWq1/uy7MqmXq6i9Eb3LZOz8Yp3r62EwyTueuLpBwvZajgzPGoTP POLcQlQd8AOx0vdbp5xw7MuKWYmjcAhCFfCILKPOCnNsq4O2We6BusrM+i1/+KGoYOLPbVuf+axd nnT5XulkaVepa3nO37miy/X2qj2Gk6DvcnqlJVckJqFapYTcdK6kte+EYy3MSxmRSVVH70s63xvy 1bLyc0Re40/pD1Plel/53jxiruZa8jUL7/2ZXjWjXzSS0DiN0mPDAPVWArY8Npkufu97aW1kHJUP cGdHXB2ToLZrIBiMh8yaEq1cE8vzrtTLzLV1azJTYuM4Lu6Ej+qk4kh3ExNDC2qqNvLsROrRRsXc UaoHeb/UL5dTlnUtP26re3vWdPapDJHxmVEzbalMPbh3w+BEsF7xa6QUbgWvHKLASHcdbpLQfkko 5M0aMr7gGIuVYKyoSzDKjgE+09dX6Q+yNJu/VyjjvXwU/VkeuF5Rj2a4CA+bJmMpO2vd2mEwF2js AnVbgE5MMrlfhgl/Bee4x5cmSIX0k37bh3RoCwxSU1sz0qvVdAGJzyjG5SABR5I1cE5mY5rFH9kW bKoOdm/liKnm8IR/fAj1aTenrfDNEFKraSbPecbqDJIi29/DZoNbu9tSO/i0iR2WW7s2pzF8b51H DdePn6sxgLIIE9XO993QiS1IxVpw1NsHs6GvSdXk51HRDnsSAu2bYYEhresFh1x4zFDWECrarjVU 70gMh3CQO08/tQPwbt676UAVaZtG+svshEVSt4TrEk0BtANdhOHqnxiKHaqjfDcMc2Z9mlY4M5S2 +30zkq0DjZ1pDxKiaSRDx4cHwixhX08XtnbYIc/PplnonycnLPJdE4zMNJsOODcAXEddTJmSiT17 diPxuo/jlA7j4f8EjnRPcBboZHoDRm6GuUO6ucT42LNHVx17U//FC5xQgBNj6qV/tk0cafVJmCKZ zdtgmI4cOZL+5m++HfTeMf7II4+wueAnsRv09Jkz2KudJO0Stmpbg+nbvn0nzN4LnAhwOT348GMw Yp/jZIFb07nTp5H4vYjj2m8Hjv7Gb/wmu1B7wpZM5mzb1m3pM5/9XBplB+vHPvZxdqbeBl6wYYRD 1i9eupR+CMP25JNPxkHz+/cfSL//734fr0Dn0v/+7/+3NMOOU08u+DzfN8PA/7//6f+h3xaRCnI2 KqdqeBpBaCbAA7VIjiOlaY6pTE9vPGi0vS1jrNBWwL4ezOt64UNm7XqQ+QeM/1kxa7d89FfCr426 +g62oLvRQIatlD/NinFe3zCFWaoodDAjEE2DhtVZD88EoCQNJHWl5VVGC4cg4asGDAynkDIbTl/O LkrEnJocmLEGA4+1nRPZjfMnwuuBWkJvngWRi7Ql4qImjDfKqP35vc9hl1OluXKB2hjI07zrUDeE 1MM8oET5W4ijNiMQnQaIaZxth0i8CUeWnum3yMDUZqQZSaKTykqs+pfC/iKLwpkMIVaK+l3tLTBw bbet1RGrhJMXlG27nKgz65BrBlNA/dcDkUAgpzMxocCitDnX2Ym/1P8aV4hSSKTMo4JPMAk8B+Nm 1tTtekF4l+9ME8+RWNhXdaIMEkXs9f5Ev0S7ZYzjw6i3xZuRE3O+FSpX4BJ9A2PjCQYAjolHZidL XTyKx7MTPfMQbVhaYuV79pVX0jbeNzEB1jFxYeEIo0dfMkE0qga1PVVZlsdTPHo13yZ0mmLrKpK7 wFrSCmfxVqatnS9ckHjIdw/qpx4Yti7etJNOaYWSIfvNQHUJGY8D13gSSq6m6amq/dzl5MRVQfjc IJhvhtDViWxarjVSQVxKiE8BS17IqDmRLoKTGq+3ApPoE77IJxpUtXZW5ufmi0bGayxyrlOfK7hw dT2u91Q1c/21rTRr2x/ugKw/z6ZzoSN+eg6m/dC2qFNbpFDU7VzzcjqzOBmnUTA40xBuLYZwSrvU 3ozEzaOaJvHh1oCaEqkT9kxvjw+kcZilLezoe7h3R9o1yw5MDOuH8eVyHPcg38MYXTcZ3TAvLqYW 2NEHVtGXmHYxWe6HoTqAVA0DpzTKwnaAUxCmkfZ5dJBMUw8MzV7SyZxJ44Q9thvp4thQGuOQ+AVp AR0vA7YNh7Y91K1ViR4OVsegIaewcRtEPToNIPCAFvi1HWzas9qEE15OamBhPcrO1e1bt6RpaPM5 jPnHUeWqfm+gP9sAWAf9yUmY6SLnno6DX61NlMMOySn8Xa6ym/K23u3pQHtXGsf+6yg+2hap70Ob dqRHOT90M/rSYRbWg+TXTz36bj6SPvL5X0onhwfTPIznyDDpkVRdQgK2iLrYc0ql/WJhAzZkHoLe jS84j2Zy49oTn/4lJFm9aGzwoAfunT51MmzR+vth3jgCTK+Gnsd54MCBUFk6vm5DFbnIYv/1n7wR myd0DbLMQv/ll3+c3j2FfzXUziKH9qLbd+5J/+O//r30yU8+HCYyp2Hqnn/2B5DWtXRw/wHUpE9z Nmtduh9fcW5K+C/f+C8wZf2xkH38k5/ClcjncJrbly7196ezZ8/xOxu7P0XG06dOhbTv4YcfZIPB ixw/9Q7tbICRQ/3OMVfznjYB4x5zIMs0j9aSpgSDFoxaZtY20hkyuWYICTbtNzgPbwwfMmsbIfKP /FyYpetV4/2yWbvp3idii3E+XDczR5btoe4yTXP4BVpiwMjMSOiLUb/MR2HgdCbos6RdxiQzGBAt JgPjG/h5+K1IpqQtVhrBsEmCYT746wRS2izj44rMbx208Z3MGvUqK3OZp7J6cfCv28mQV0ykfFcY GK8k9sVV4DSdIb43j8x7xtQas4MVo17hRgRYNDIJW2YTK/ZG6rgcoh1UbDhxbGUCgEONb53o3JUm QxtqVdphW3yegxATyaHjeJqG8Oi7yoKdrK2NRVof66ZRsRIwV/gGJ3cZPudOQ2mf6cu939XhFNMk cc835RoMMM+yGIVZW48TRlWewSTVMGvmbR4GyzLYD6UvfF/iSz1cpdaeghAfbfhje0rdS/7BwFR1 ySXldtZ+WspgwU8jYcoAj85H3TiwiHQNMS52z7gWgIi342/r9Asvpvr+S0glgJ19Ii4wMdaxc6yR nVduTKgNmfEhhmihZXVi12SOin7IxtpAkjT1TNwyZU30TQew7QR2/rQtaqGzPBVBApzzM8/yi9zj XT3SFXE02k9b1utQpb26hkRuCBULtiE2P9pltkFD7Hw6A3jEc7gegRFxkpZZE4b+i/7nA/HOcvMz 0xNwbmJFYv1jPHkx45qQzSVqIjbcBqNXxZlvwaGSLMriQSY5YFs13J3a3obqlj5ugXNr00iL2Gmk paMckqn6rBV+obmtK12EKX+ZjQFvTMBc0C87kIAdQG21hPRjCs1BOxKrNlRc40iU9rWjyqTEOSRV JzDSH0XluVCHWpWrZv67yO8mxnf9gj7NltNp7N06GPt9MGJj2IONo2JfUhoFLNxk0MNJCV0sBO7o wvifDQanqMNZpG5TwFMNRCPvWlGHbqG8Hhq8H/9pouQ5bKYGmPSVoi1BJ0agCWPgt23W7nE/Lptv beewdGzK3PRwAZu7Cdw8oCmlj+w56AW0ODZKsGjY17MlDZHPT0YH0sAqUmVVsNCoadTEHvGno90t fCW9GgSObv64CSbzdvyv7UbLMAdTtgQj2dLFYfN93enApz6e7sOdRRv2am+8/lbYZbmzf5rTFzSV OY5UTVcawzjS9UgpNRDOBbv33pQ+8clPhPG+bi50mzGMvZsM0WXG5Ssvv4xrkF1xnJXnggrHblTS j370o+lmVI6qNl/mdJJZmMO77v4IwoWmdObsqfS1r32NkxIugIQeDs/mgO27kbZ9BPcbtyBF60qT 2Kj903/yT1IvdnhnceUxOnmZXaPPpTfefCvg8OX//rdgKofTCz9+EYZxNB06cgjV7MeCCfOM0iM8 gzrBFB7Dbu37zzydXn/xBzBx+NIDF4aR2MMLhkDCDSPSdXeialoAYQOijh9pNz/e8Ye6irM3DlLa Mq4KXa394heaWZuZmXGcf6BCmcSuV+n3i1k7/PDnEOly5AjIrsRClx1zqAo04BdhPL9M+zVRr4kz 3+pVqcVkF/gYk8CajJS2CSCo6tEg+KJpxazVV8yfjMYiKxFXIBnhzFUpE1+AxBJu73XOW5A11I/E e/h7YdbEd9PEgHBQkL/5cRv5FDVijAziogwGdN6QIETJQeJW/ZSI+XGcJGBFzNNkBBksg8yNUrWY XEKtCGMmQ8KE3ATj1oyNTB11UsoWcKROZuVMZzlZDclOQsTvqoBnNMJlRTqFzYQ2fDK84foB4up7 7d5UBWv3pM2T3+tZ2/KrKskBZFhTVjBkFBdMDyJ5iw4JFEymMMx1sL5OgtYJSFft54YPifOruFJt 8zY+/v80s+aUbX8YTGff1+JsMGoVgxeJIuH6n4iSKFMSP/KvcCrXyZicZzxz738KiLQRRz2dxJzc W+A8VIU6oa8iVUOo5rRFnzEprrDqPXch9bO7q4uJBUdjwag0IEV10gz7EBgVsy+d7v36czzEUzUh 8i7yB45UQIZijX5qpv7atWkDpIPbNp7bYY6aqU8X9XQnX9SJvL2K51Q3rrlg8YUIfkqVDOWan376 b4CjijYvaxmfxn1AMPIUtvGOlzkdXC4RLB9gMviBUDJrnqXqOArcoE3m5XRj8K/MWmygidysKg3b EMxzPeRPebT0HIIZ5VZm0WCSUkLtfdj20aeWEC2JvgYnqGcLXHobjIQfTiGwmkXSxhtmVWWYwrQ5 nUEa9D1swS4ycdbBeHjaAIpNpNmr6QgbDm5ZZDHKAvI8LjpexTfbJHnMKxljvCx1tKS+mTYOa4ep 4ZudSN9wPkHOSJvQbR/Fb9kojKHOhYVHJ322CRcdfUiQPH9yjh2qy0h9tnD2aD+2ZcMweONInVpR ifaghmxfbU6b2fnpAVer0FaPQetfmEyX2IgwQ6fDo3HuJ5M+7VcquILKFtFV6oJB3UzrHFb6TVMy twP7uU2tPZTLCQqk6UDVt4JqzoPOp6ExwuPcIg6iqZcDw12vbtRo4PvdwGSP/umQtF3EBQlENRjI JiSFDeDCKkRAmd5WYDbHAmiazRZ773sgbT6wH5yBCYPBeoSzM+up8DPfe4bjns5zksEpdmheirNE PS9UnPbA9zrU+MvAbNu2rdia3ZKOHDoU5762wrDade2cbiD9uIwT2R8+/zwM0Xwc0+R8kp3jbko7 du9On/nML2Pbdil95+lvp1deezUc0+pmY4G8z5zHZx4SVYYcB8a3pyc+8Xj65/hwczfq+Ph0Ovnu CVSmP4Kx09yHc1dx3Kv69vbb7wg/arrt8GSGnbt3pU998pOcYHBX2o9bkilOHjhz+kw6zm7Q//s/ /vs0NAjLDj+2gAsY7dNkdsPOk4Z4pm2YBEkkDHamDaz5Ba767johD438N9PUqxMal/Oria+KW2Vn 8vsR/tH8rH3IrF2/+w498LnUgUqvGeNYD7R1U4Cqy1YYMweahyhPokLQS7VGokSCjCBlJo8wAk5S MF8iI3jptahARVoHm4yO2+fn2biwUInBryCvE0gmymYhM+HxHroHUf1YJGaK2WUkNdKU6VKyJrOg JE8Vos4xJepKioJRIM+YyW16EH0mV25lgGyD9ech2qghtEzOEuV7QHeud548C0OiU1RnT3fIUgjl mbETWs4nS/r4lrz9F2/JsxUCroTScrUd237bPRAW7RvmUy9+hS6cv8DKDbs+mOPwW4fB7RL2Igv4 V1qFiYOLoxTK5OcJC5Evq1/hFwwacfUSeGLix5/mGMzRHQGLSBdwkdDDAEJIYtKOP8CiXK17lUlI m7gPxsgWmaY2QKwlGplwUJuqzJIk0gun6jNAnKFiAcZZVsDQPxliUVbUIX8kI5STxt/IOj73j2/i mhkfc4h3tC/+8SAzsVi3kDbPYrD8wx+nBYj8Wh0LD22EqH87ogTLjEIi99ryqgjqINMUJQID2R5d XnjN/3gnPpJIlaj7icuvGWZRfOpmYKgSVc3ocVYamzPSAh/N175UxZcZmWosmHtVbiTZ8GcDuGlH jMBgsoU1WUa9dfabT1Rg3MrlV33mOLLegc8m5yNPDFDatt7nwsbAxbiQdFU4mF8Yz3iqAkXC7GTb 0thcQASYFnlH20grbKqOt4pmwFU8sg7GWKaQvTrEs/Xhv+4yHAvG+ddR4X1s7CGPKdSXg/xOoRYc YGxN0AfvYZTvovGezq3pMG45umFAOji4/QKSrOfZBXqaczQd4zs5vmoRM5ADKLX72ASgc+h+VKKz jN/p9iZOGxiDUePgckp14dSDhPYgzNIu7N1249cNE7L0zsRAGPQvwnDZry6WtrGTsxOhejs4oSf+ Ecb5Bc7wHEcd6e5kHRNDKdjcgA1aW2ewhqdQ4w4w/pcoRzro6Rq9/DzeymOrWsm3iQXBFsp19+W7 Y4PYp8EYShMp112hSlLHYBimWQRuxkatA8Z1GmngMozoXtSd25DSTUBbz84O456mPt3fg0oYadoU 9Rpld6qdtMqicpb8pylvFSnXJC49FjlaCxFg2tHeR4fgzoONB73Yvw0NDrM5YAAGazenDXBuKDtv 77/vXuzXpsK85tIlNlOwK3d2BkextNmNaE888QTOgj0YvjXovmdregZoC2W8+uqrcf7mKLsst2zb k7btRBmM+463TxzH9KQhfemL/xS16WNpRWbtzNn0h//5P1PWdOpHxdmBEMJ67N69J7lZ4KUXX0Na 93A40FX69e6pUzCXJ7GzYxMSzN0O7Opa0ZJ8/5ln0oVzZ9OBg/vSQw8+gD+3m7IN2189mfovj8JE zgQddQw5V3r1nyFL0vJ9RGz4I/OfMXbDiw2PhZ56lWZfFRzHVXnGBw0zhrSa4bwf4R+LWctLovej Bb+AeSxC0FTDzXMunYRJZk3XG567KLMEJkJCUDlIHNhRpWRtEQSdn9MBJYSZiUsv7sFUibQgzPpq XOStjuukAABAAElEQVTh+2CARGPuiaqIcmY8BKnfKMY3SPxFTpmcNhhImUQHhJK0BRgc/SxJ+Auj Zrl8EMQ6k2xzcbAw6ZHO/OJHjChvKYHq1oNvZe6sk5/ITPlsAplQGSzLUTIRrkLwJ2QwzRIqNttm rvENGcPDZsaReNWetkt1qIyYzJzX4aHLMKP4NnIVD/wk5K0wc52I/WVQG9PuyGMY25BZCJzGpgus fCVeSthWWX3Xs3LPw1cGoTAOMmCZCXNKjAEOc2EdbH+Bb5AViCS8Cm12UqT+XLMaxWchVJEe4WLI Ufm++mvUjULAlLpRJYuJEA6DrY8Z5gRVFrm8XHqpg7C06EjN33jgM59zHv4tIaejNUE4wTP7UdiA AwtMhlvxfH56Yjg1zINLlC3jERIGUllOCQGHmrpZQjyKn6Rbx20fohMiRbDT3jGFWyo/2WtqyMeq GcNo2ELoiwA+18zY20byokPcaVx4YvOKEHUrT/FQ3vjVlWAWTMrCJ/CbtzJn2mFqw6T0T6Y8cIEx u4x7CDWvglBiL7iUHBc/avaI3zMKApeiF2rgUgquVcnYzyH59Yaf9csqfO5pnyBk0AVMfPCxBL8z BL56jacrVx9Nb1/Zb94H+Ks4LjYk2tIOA7XdBR+LmlbssS5C4zb1bGWhiLoSty6DnXXpfAd2VZwv OjiJe1tgs5NNBmOkneRIqltRS9663IINWztqQA4xh90+jvQNR/zYmukXDUcsuA+ZR9XqmB9ZUcWI OnZuJE1PYL/GUVDTtEd/btvqWtIONhhsRoK1irr2NLZoF4bOsimCk1qhmzoq1hZ2OwzfgRbUsfOo P5FyDbANQQe5+VgzYMY/YdkI7djavYkTClBTwpS8Mj+aOnFdUgc9CvtDINeLtF/GbHNLS5rc1ILL Cs5ChSELH3Vgh+faisdjnAgh3Z+m88dBhlCH0v5GjmnjtC12jbqJoTXtQLI4xZFRe7E5W0EFupUd ljPUeQVmcOTC5TTMUVHTMkgDl6FVLKqB0RDqxSUWm/duuzsYK5nGX/rlX6KTHohjqE7BKL2CLana mu9+73u4jMIujsXr/v0H0uOPf4p+7Evnz7+HWvNuNgB8ND33o7fS+f5BVJScxsBCdgoBQh+q2Xm+ 84zPNuYLkC/91pd/i1MHdnD807OhZn2djQ6nTp+ODQ+eOfrwww/ABGKeAGO4dctW8pmCJqP6xubv VQ5nvwlHuwfxl/buiaPpRz98Pr2DancnDKpM3cDAIO3USwL9AK6Jb8Ix/tHfRmWMLdjr898exPnr hcKIXf3++umvTvfBe6r7ULJ2/U7beetDwQhlgg1hBuOUBDWzqim2Z0p+mnjuxGBUezInlRk3HjBQ tMkS2YoULSYICEsgMO9kWsJmB6IUdlwSikBOEK5CUoluMFZMJjJGOiVskzFkgM+xyjV/fe7kVYxT EQSbfEvw2xWYGMl5Ru4ywVSMGgyRRN6dZiShbtbPtJn5opqZ4ULy4feqax15Sodsn0yragY9bTfI UDER6EtHZlWVayN1M+NliK8qXldtV+pK5pbFX+ewJQx8W3DIKIPnVnSZNnfKCtt2Di5uwF6kE19N Mmu6UOnB5kW4zSGRXATeM9jU1EGgVZsuQ/DrmIgbYL5kD2QIqDJ1wjaFeik5ETb2heU7UfteexXZ Cl4ZK/CDSQdaJgomwsk93gqHnDCeyx+dvdovhdCUa3nv1fZG4BoMRGRvfSwmw6RKkZNV5cQ770kY tTBt9c6E3lvXzIB6b7qcxiLFocAn0inVXWVC6oZhu4A9zQLGwx2oy/xmCemKB7iLGyXUlmNc5Gfe 3EcZVcJcTikz10F1VkjVMBZvZCLXaa67/FqAtycftNLn+luzTKVrTmDRH+Tpgij/ow8tyTZTL8sx 3j68KtTAw3iZLFOoGlaaaX/IKDbCJIXa1YyAgTtCxWnHpVGG0uZFKqMEuwTLXK+LMCc/Vb21YWO9 FlT7kESMs8+lFRk3qBjtdXFhuRmW5BntqNpn2si81CyXFG2p2issch7528BvCvKLgBk3nqoCN4XT 2rU0zP0UzINOUBfI/wwM1Xl2gMqgDGIu0IWB/XbsjNZQi9WxGUGpazNj8nAd9AcP/u/B6CmhOwUz Msck3YlUbjcuNDoocREpVv/iFJKsBegDKnXwqhXuTZV3G4yijmD7yHsHjNgsac8hvTvL6QVxggjp epGKbcIerp0WdWtGQeMv4sR3EKnXRGyEobWI5qR0nunpYq0BG0Pt4mBN6EMYRpjEHhjyXUgE62Ge gq2j/Aa+81ily/gaOY8B/ExI7qBhlDVPH+l7bBsala0tnekyqsPJ+kV2ozalPdS3HfBxYibpqBB5 KXFs4ND5TS0dVKQ1de7dm3Z95CPp8AP3BUzePPom0rLJcIGhuw57SNLa3t7KJgMgRT4d2EB7AsHB AwdCrRiaCMaHh7XPQOOf/MsnoYVZKtvJRjfVmC5qn3ji07Ej860T59MIR8l5pmkrkrXLl3UTwq5M 6OPBQwfTR+64g7NXG9OXv/wbgbVvYZemHfbX/+RPYLIu4+D2AuXgHw4zFN103HzzLdSJzRXYL/qt 883Q4CUObH85/URnuxcvUofOOFZK9x5udDCESZBjLcYBOA5clawRkZEwMJj76wQxPY+MKwmK9uZK TMZln8vYrH2ncKU25LrktB90ydqHzFptz26479t/R0iNgtA5aTM4/QUTAkGDugfxbWVgtyNWbmAA yeS4SnOFIVouYj8SUjOQNggxhMsVtyssGZ82J37URNoJaJ8VzNo6wjuHVMQ5EB7igARKVaeEOBCZ ayuMkvcyaQW5VdvK0MXEA5GN8ZNrULWyml5JI92BJAeT5KThjBa1pc0hraHOpjDIeMqolTYp/XKD RIMEGGZVhtV6hPoSeLRjaCy8ZNaWIdyqJCQ8ivljgwEVEw4OqmUZO8t3uuIq0+e3zcDX3bhNzXoy 5zgb1AQCvhfnjwvkJcOmpG8JBq0D+xp3qE1PjIXB9ApxUDFazuqYtCFKpr15YwTTLW2xyLC74z7c REDWrY/9J/iL9NGHYCr5oOACSfg+w8Z7g8yaofRFIRgRyR/zXQ9OoPGPaxSWCYv5Xyusl0smkcb6 xb+cusQZ63972dqZxnvfFybAI4QwEeKZY6dYQV9+7oXUMTkLPjDRsY20FbqnfdR6Tfh2/b6qnM+R p3kbZ724CFf/ZUYLFXrAVhu6zJQ0069xpqgMAB/oAwsTK9TUqkr5DpiGFJs4mbycW77aV+KsIcrM t+t/AwbVU/QiaQPGJA5mzXfEqcIN2Pge/In7qt6qDSN44bdEYtVxUY+qb0repmMpQ1urb+LDXGZ1 yxsYmCxPFLsY505LMIaBZ96jkqVRZm1NVBvbjmgfaa4XYgFY1ce0jtzoc+Kin/nU+NL3MmsMEcrF DQbDWhVeEyrvBSb5lxdH0kvTw9iVURvGXBfMxz5Y58MwVJ3YT61wDNU7/Ui+mJun6LQzGM97wLvM 9RYOSPc0DF1OdC5qIrKSzuJs9r1lGDna5RFQ+xm/2zl4XRXqcOtaGh1EwsTYnGORiivYGHN9qBm7 2YTQi+3UHPa+4+GaA2kW9G3Vccb/FqRA7ags1WAMIQHTRYm7dlX/9oBXfSwat3JaghsqBGgDeQ2z O3QS294ZNRHkIROhX7dBFrKeYKBj4GYYxCmYwRVwsof69rKw0/xjivNCd0DL7u/bhV/COlS9qj5Z WAM7d6OSGZtlGtMM+U9RXttNN6WVPqSFeP3XSS7knN2VuP/AvcnmzVsx8ehJ+/btheHC/QfnuU5C q6Sr4pN0uw/vA/fecy8LX+DN7spzZy9Vu0ATxz1NcbboG0jMRmGocDyLnfMUFiGrjIkWmWLqPosU 1N2ganuUorciTNiNPdznP/+5tGvX7pAITiI1XcD+Trccb+Fv8fjxt9KLL70U/t+a2Z3bDrP20Y9+ LD3xqU+lvXv3oQrFV9yl99IrqF6/+kdfSydPncF0R5MVdroC0xhzwFJUle6Jkt6HdJlrhcjcXD/k UWDiHIIGXwP3Y1xYwLXCLzCz9qEa9FodXsVpkCjTIeMgITcEUoIomRA6qUCiIViuauoZ0D6bXsZN 1Z1Gxa7yZE7CiD+QTyKMuBgio6RMEX4TqzwRO3bkgXCqIYv6I5ec/4rAMjcSeYP1yVK8isEgXru2 kLaRrhax/eTKcybhRPi/GlgkqCapapqIQZa/yRAo3xdGUGZNhsrP3CY+z4rccpYl+Kxs9VfVDPMi TBohjjIkqpw8XzIGI+2MHUK0ZQlJS08PRsCsrGX4ppBQyiwqCVuCKC3MstOIFeAcREbYraFSEUYS C6hUSAjWsBPR7UeL6+Q2tozTL9gUQwTxqk4edaz251D3rNCvkkclEW6e0IhcljQ70mTCs89lCoBN MAbcCDElIoZaQuJ9gYvXSFjBujZd/nLD30hHfvwzf/96X/I0tXn6vDFEmviK7/yY4CVUt1VNzc86 W3vVE76LJ/OkxcqKfN+Dqrl3z940884pJA8Zl4RP1MbvSOOf2lpEXH5TsSEkIdLU1o1ujrdiDt3M GFK6EfMtV+9pJx/IQOkQ2Xf+Qq7F96ouZdyER/7KEmV0IgX35O8r+qk2ZGaUlOZRAzdx1PwLrPwm 6mCeTjD8k0ny+/gZk4skn/y+tpyACu9LGTL1tSE+5btcf2suBCyL8UF8tJsPHBuOZ+lAZrR0d0J5 VNQ8gtEy3Xp9zKXqiahgLtUYcuWN8LesHKyV9+alrzE2REdNlGLKFAv5VcZJR4xljlwC7m1IqjV6 r+Mg+FU2n3TPuQUBRqm+NZ3EXmwclfksdd7HTtLbOC90P79xVI7vwTyNMV4nlHiz+FTKpsNk5esu UFdgQKZgzs7DoAwzfh13PTCFW1aQgKEO1aRkHGnWZSRDg4zVGRZ5Hme2leOudiMhU5J/GWZkYg2f lzAHHFwUPtPsHQ9eb2aTQBduODzzdoo6TOMKZHUOWAhb6ruFsnTQOw9j1QWDOYpTXAgqOAXtop3L Su0AlM+zwGSeq4pRmZ/LuBaZYrEsc+ceDvjNoH2t0Nut2Ma5GJyCNrUhEWyGKXqPNoxAa2SslmDU hPr45AQ0rjsW2DuwMfvkJx9LUzBs2pGdPn2ajQjnYjH79HefjsWsuNHbvR0J2eGwbdvXsYcdnbfj zPZHOKj9cRztNIfErxmXSd2c+DAyOEi/QefsS34PPvIozFlbOnXsjfTVP/xq2AIrwZOm/Ot/8z+l w4cOELc13fGR2+Loqe889Z10AcZy7OIFzgl9ijqdSZ947BNp394d6eTJ4+kF1KH9/QPUeYrFiwsY MFGEDuRzvgHP4gdWGe8LES+CifzdONSO26CnN0h+ZeyVQhgl1W0t3SzpbpDVz/2rD5m1G3SRzEeD y28GrITKICGUvIXRM6Na1YDMmjsyoSQxeEPyBrOmpEk7ipDqOIAY6KsMLIOIrO3XCs4dnbaUVint cZeRwRWRxEV1TUFwGUGZIxmUIo2SqHhQdpFSmafYqkRNQ32DO5KsUzAglJEnFQkYOfuH9L6LkvxD jb3ENBPjjWm9ZgCYwiAzo62ZzOEKkpEGGCJte1wFU2QwqIu0O+pIOe4KkjGTOSouP2IHLaITRf8r MHN9m7aSM/UnzSo7klwBt7OSlvi4claCtozqbh6btWXs1ZwfA3bEr7EqhwUORm4B4hg9JYNIHZtZ 8Te2Q0wWWjnAvI1VMdI46qMUTuImU2d7ZaptKuCIFbh52N9KiMpmg3AlQZpaAuC9vyAQ5lFRjBJH 8ivBdDwFvI3lJsBLvNxHkf6UPMq1ZLBeLmWIH/HeT0uZVc7UiHzLP6S89InqRxsnM7LMvfTU75bp ty5W+xMS+8kxRcJRKSfBjA3U0PrVBBkt1Tj8j2Abcmm5XNNHnJ9yF/hEGpPnnzkLN3HNnwrr6plv /Nb4nIt31D3yye/i60jnuytBBt8QfWIOZUwRDTrFz8yrWoKXtN9yrQEJmoCFUo8ol+cMb9vqN1fC ej9cibrhnbgUgcFhWctKARiXulORHqwg9bI/LVksVIKomtZgi2xvpgc8lL6gUlfViVcZZpQQ8M/v rbvfKp3yqCS03LEwdKfukqJNOnFnc1e6kzqcQvW2tbktfGQNTbO7D0P7pa7W9B42ZSdgyIaAp/DS 99leXHtsi6URRv7siJyGMXmb8YTzHdxotKWdtEBGZ5oxMQyNHIKBW4MGdND2Tr53QbsZR7rakDUj oX9vns0Fy7i7gH6pVdjCmN4Eo9aNRLYOZm8EZnCEcT/JuJXxlNl0c4R9qP3jBNL71XkkxcS5SFzk 2k6+e/p2pEXcZmj56rGB9vYcEnppt7AMGFaAFFZN9EkrtFlG1Q03vewO7cAWTlMOJWhubPBTlpOx 8FzUCTASQTdJ1GPr1Qftn2lFtYq6d2TkJeh2ppOqbDXyf/vEiXR5CH92uC3ZsX1bMKH33Y8DXXy2 6c1gAIbo2PFj1I3dprjD+Nqf/Gn4QrvzrtvCUa6Mvf3MLMLOXY53Q4qnTzd3yC+LR/xTg9GIG5Zf /80vp9nRT3Lw+w/S97CBO3/+PJIyTx/YiZrzI2GLdvFCvzwrqtJ/FtI1D1tXXfrSiz/mAPqjSNd2 sZP1PU4juMC8AoxDEmgpVgK8CppHPzD2hB/gIVQA9TbCNZ5royKzkvbG1zL2aq/SMaa3CN778335 3TjHn/+32BPXQuvnv8I/yxrmFTq9L72nYPEgcEH6aQSEAIrHgOfRF8ASgT03quRwCMjORZkg00p8 6lHzxTmNAXMIr5I3DF6lxyL/lZAR3udAQK72k/c3CjJqDh8ZOWwRM5JSeB2Tg0ynjJWFOT9Y12hN 5JmRmoTB+PDFelnRTMu+qn750xgEwCAYR4hEPYyRLjRC0ghQGpnwmjBYlTl0u76rMCelaCsZK33T B49MX6g4IK5L2JYoXdO4dnYOySZt0V5NeyK/ayW/RQkF38sEx65QCIUOi1c1CkbKJkPrW3fxqm5a 4BDmiOObFfQaS5TT0o7tH+oBmTV3mC7yU7oQ3mSpuxPdIvUV4jKqMXnCRWlTs4bE0L4wz9InwsK2 BUwgpLWhpClxpRfLVRiLIwWHbNs61ak+Mm/zWccD+y2AUOXC/VXvyJAa2ZPRhrjSnpVYfPCOyU8p QhOrDppDe3nGhqaNg6Anjk+lDvpLaYSTeOCJFYycqgrFxTJz+fGXJLL8edxQFnW0OKFhvDkoaXb4 WLOA13r+pf0BivyHD8ze7yy7amn1bHyOK+8jGX+EQw70B2liuBLlkz8XWiZxtMQP/ItxTEWVcMUi KRZqjJWSVW2+9oPP8beqWalcVfK1LoHn6y+oCzAPhop+QfbOJGvZ1JO8xLnAJWrsQiHXlXgbY6AO /it1yJEZ1saKHoI2p7Afql6g8bGZhXw9gkmILFGY42/bMht61nrS9k7UkKjBxnBxcQa/aedRA763 MprOzY+xKxZXHI3L6SYkbl2YwrbOzqfh5pV0EfcTA5x9OcR4BVWxX6tnY0BHwh8vtmOckgCDpSRM vG5j3GxG1tbb0Rv2vqrkRpGyTc4Mhz3YGnRjL+rSVqRguhDRt9p5DPXnoQe6e1GFfhMqSiWVI9Db AVSXOuOV1Np/qqR34D+sEynbJVS1M8T146JjHpVsA+PfPJeo75ZGJGDuEFSNx78AmneOE+JlSEUU JZDdqEm3wlR6WoYMJpiRurC/nITxrMNZ8Pwqh9e7uQnaMjc+lE4892ya7OSIPhg4x6108KY9+9Je pNdbOfFglo0S7v4/d+5cOvnOieg+bdSOHDmCH7Q+mKO97BbtCq3BhQuTzCWcAgGjNDKKjdmlC+nY MR3fquet55D0AxzA/hnaMZ9ee/F5jnZ6J81VdmQLXF2o72NzwAP3P5C2bNmcTp06zVFQJ9M3/vQb cVj7E088wekJA+mRRx9Nt956a3UCwl3pWdqgg9xL/RfT+Uvng17r1HY1VpPgDDDnb8BI++CgN7QV kBGAp+9qQ4z1moicsCbCW7/7Owa/L3mI8IRCax07hR7/HXP7uU/2oWTtBl3UzKokJh7wIEuuRL5M JOMzDGMNgSeBNHlyFGnXUOUpHtbOxeAKcBnRhsxb2LNJ0VB9zsCchLQIIleQWwJbQiAf5YdULJgQ 6kLaTMjLdEUdnG/4o9hctI0fhFEabSoR14HGpqt4ZwmRBzcOukhFQxSdM4dEo2JeL+lp35WJQYDw XbSPNvO9ftBUT2X/cVntqw1OqFmoUwOEzWy1AYErikHl94IH0kgk79g5xhYkJmjUoex+CgYJwtjC jis3LzTQH25Zn8OWzQ0MwUKx+0x/YM0wiasQXX0orQHTcO4KdmtDaNcsQRjzxgYmRr5X1Wr7w/gc YlyHnYZq2jocwVqpUEPbJ0GcrLRwsshoQNTffO0f7bMM3kd/AcAM2/yd9z8VMtJE3/hWpiR6IZJa N+KsH+lq8yr55HemscwSK27aJv5KGKNfqzoRbxkySzZEBn6ZfmmiXxrsAzp7jl/nnh1ppv8SqiMm VuAgo8DbqKezv9UzJoq0CG5yiny1DSYKWFD/0nQlH35r8Op4kuldz9Ab//vSEO02in/RwGhZflel 9cHkAfO4q16vX6KW0W/WSyxzSgm1N1ehpbQ6WBbLY/zI1Mg0xRijjo67UI8TJ6NnyNIt61M9BwRy WZFgwx/LMQSe8InjwFyVLi/HuMGnmPWBE7P9MhyOVTfFZFu4XAclTdHffu+935jxeuDjSENEVC3+ xFspk5EoAmDMMq6Zxv7zqDg+TJ3zOK5dYgGJ8ZkOqZvd6YjE6ASG/WfcbQ7D4k7KR3ua0i2d2/Bt hpsIjp86Vw/TgbRpFmn21ubetBtgu8sWL9ccF8XOSpiIeaQ9uhVxcbAVJi6kiYxlGcJRTldYlBAQ 9rTi2R/btpW1uWDcBubG2aSwBGuXnepuaWdnOGN6fH4KW7L5cKarKjUabLn0ocxcA5KxCZxr614J VIdjRO3JGI8TPZR6weQpPWPvQPSvsIz+BfZKn9tZRNsfc0jqpOUzmMQMUhd3246jR1bmuQQz2In0 TWmZDp+XV2ewtevEYTDwxSXOzPRCGsBAbgGmSl+TYxwwf/jQkbQd+7Gdu+5kEdoGs3YGu7S3kVpd wH5tCjcYz4emYseOHenuu+9GNbmdll9E4nYQBm8CB7g/hmm7iHH/ZeiZC++W9OCD93PKwGehsctp z7ZN6dS7J9nleTYNjEzEIvkE7jcWJofT7l270lf+xT9PZ86dT0ffOorU7EXyeyX98R//MRJAHOe4 2AcVpLFqGPQx6uJ7ES3EAuJYyaE0PhYUjJM4QpCr48ExJN7aE9cfj7ysDaS/Kki3IoerYjc8VN/E BXwO2iuNM1me58SFWpqb67Mhmw/g44fM2g06rRihmwS2gkEbtDAQI5CBSVmimQ3QRRSRRMpAyNgD Ygf6Rjp3i0moQx1hGrGf407c5q2ftDwBZ8QzT4m7hqPm4GoufKuRh0RFHI2dNhVimqYBwmC8+Viv woRJuIzT71ATDI+TXxxALyPih7yzhTJWaxC6mOSJcgEVLgvIVCeqMlcReNamTEIfhN9GKSWgHXFM D0RbKZiGuvqWEhaK7UMNCuENkTkfy1ha32AwyaMZrsFt5lNIdRbYQTWL3YyM2OwsGxVwDBmTlytr Vsba5DnHaBto7aGs9M9S3k1KeTJm7lBdgGCHygBDWDcitOEqIBTTqmpcmdJ24ePqU2mTxseAnJ+7 FolTikYJMnUy2QJFcPkL+FM/+ykz9ablW3/UoYR1uFURqlO1jcuSK+AQJVQva74zJvCsfBf9lONM plTGxlvWenm+8Jn4YLZ5BMy5DNL7OiZov43+hzGwLvS/ksqGNpyk7t3DuY/4csKSXEe2bkQIQgxw nBjFaSc96y1+Gsg2fj6ZU9TJ+6iOKcV9S6A+kUaVZybOli4TJUy8yiAqWYqmmIaqcqkCN0HUa6J8 fyUBOVwdlCaKuebt8so6uBAwLo9XmKK87grmyMnacRGSLhcU0UbrUVXCukV5PmfYRf6kCzzgW+Fv yGxWvjfTPPZN7fhWWoxkV7wiK5kh4SWMY1IEAMpwxFcdG6t683uZNvtAJjLsEAOSlgGMxVnLJktr lmP9a10pFSJWRyHWYCGiwHk2GESfMP5WcVPYgpR6juPiljA006VHH0yJTmZnybsFQPUutbLzDzcc 5DnQsIB/tfFwx3GgZ1s61Lo59SzhMByp7VtTA+kiEq1F6tuLOrAepsc+XqDNOhQfRFq2AhPUAYL2 wUhBVHAJ0pHmaMAAkqcZNwdRly40An0wQZ496oaEGezQZlBP2q/tvCOK9rKA4xkFHScnsBOcPUh9 MBo9/JpglDqw6ZrDgas0QImWuDBNojromBsk5qRp1LOROup0t5PvPJweS1eeyQt60w2TOYsdWjdg 1UxFNx+wcmmCIwdnYRw9cgwNLKQIDQOL3hbnAiS0cEGxK76VHbQjo4Op5QwMH9eeTfhho8ydO/bi d20Pmw82YyN2Og1iijDOeaovcTJBFwxTDxLvxfnN6fZbbsa2tCudOnMONelY6sBOTtvERfzkvXOU UxNgqvbetB83IL/MDs/+9AYM2Y9+/EL6sz/5amzQ+uKXvpjGcAbcBox3Ibn7GGrqPQf2o+bk2Lkz b6e/fupblPmj9Pjjn8ImbSY9/fR30yCnJujgNhzaAmM3VUhPqfY6fnkvfolDxoqAYp64elXY8Og3 1wuFnpWr6YIWmiefxcKHEqMk44wmPs95V3It35frlTcfvLu66enpnwLhB6EZNwL++3WCwfYDt4EA IATIEKo+MKIwUYExjkMGrT8ZjpDGQHhFoIxYGR0FsCoz7bLEqDDIDIRjBQixEcG0L7gqBP6JgQ4B iIibBvhlFZ90TemQg4hKECwjHPdSjzJYyjsqyFvF9zAlMjUiOW2SsMcGCQicNlsG26FKhOky2kEL +c+kAQHym5h2iXLythwZonz0E0fUQBS1QdOmwe3cDRA4HTsuU0d9V63A2Og/zXrFiohybE/Z4SoD 1rtjX1po7GBFiAEzxr86KG9lhc+J04COOgOrqYlxiMYSZwuyhR1VyQIEUWWRE1xTkyvCrvC95qaC aSR1sxj5ml44d2GX48aRBSYRnQXbfo/DamAlrbp0dQXfeqvsTYMwSWwkCsE4CEKBbLthcpzkAy8o s1EOT2gR59UDp38q1NAl1VCZWROfrryovQ/8+alMrkQIi5LG72q/9V6GhyQRAj+Ji/6ryjONh7bL DMDKUx8YNSa7RtrTxoxz4eiJVPfe+dRCf2mQbn85GWpy6YTv2aKS52XgZ8h/xZbCxnDlG/MO5our UiIZ7Cbq1YT01I0gnA4Z0l53i7aAm24okP3WlsqVpN+6e9H6yggx2tYngRrIRR2u90fmJzNq+UrV g2HTC773mbMBJymnGcbdnX1NhTFzfNHn7kwVdP58tj6yPI51o5TPxS5V2uGz0py4xl8iCDLXMdZx SqttpTzGAjgo0+pCgH2D9APjjw/FaINHPQkXhZCq5lxoNVGGOGlcLFhIV+DvosWwjhvxlOvirXUy 5Ct1tR02irqRXX7DzYJjll2Uo0jM3uNszGnsopZh5M8gSeviSLl2jOTPDlwKuLYzNrU/89zXTagK W5D2DHK26NuoTYdRUXZAFzbhZHcVmjCBzVr/HCpNSuLAqbQZ/NmNFN0GXZzATxhpFqlLJ4ySDJFu kRhg+PDi/FHim2GmOrFha2R3qmcJLwPoURjKEeo5x/gTf9zFuZPNCrtIM4G0ak7mjTxCOwL+amMr nWpiK/QYPhoHcIQ7Q1kr1KEBhtHzbLuB4ywM5zS9tIO27aZt7ljWVEL/b3XQPRe+m3HUW49bEx35 ykxyTgMq3wXaz4YEaN4UDJ5jZBN2affee286sHsPfu162HTAMVvn34OOu4jmXFPUo5p/SEs3AQ/n A+3adEm0hnRPR6w9qEeXoD3Hjr2dDt98c/rNL/924NSbuNQ4e+Z0bJz4pU9/Ot11152xkBzF79rJ d04CA843ZVfpJNcd27bHofAyhLfdflu6D6e8s9MzMGnPpq/90R+R/hQ9AywYGFMs2NRAFBOdOOca zrgICUAaECljjRjLVyLQeig4uB7xt9wEHpLG74JWcR/zKs+GWAhV4yIi+LNxIVziy7Xk6dWzU9+P 8KFT3PcDiu9zHuH+gk6WyGrnIoMUkySDMiZr0DMoHIRd43fjwgaFtEU8mxEWZDMpeYXLCvILks7V M0TNxMlExiDibQdp+YRnJwl9UiFRkmGDoRFBlxm8MpD+1idj4pVaqQ41ZGmPvIXMUSbioZalnqEy lUZX/2KnKmUq+nciVXrhNBLSBOLLIfSB/NRTdZr1cvIRLk3O6OTl4PWfUr6WkIBh0ks7WZxRESz6 +DZUxBABmR7r785MKoSmgrNWG/GV1sYzea+wCm7G7qMbv0IN7LCaR0o2pUsOVpBNENdwKEzeEjQV EwArmMNuiJ6OHfUErni/he1oa0wgSiR6cAGygCHuGroKmTuZxTgOy/KUODBR13Eg9BrqwWDQIU6w maE+Ahg00X6yT+xk/wNX6m48b/kxydKu2iAurNM005DcUAjJRqJmfHmXU17vryXmUPLwO++tAbxV BPGl5Oe7SMObUEWKeXwjc2AXKRltxr6mm51qU6haVlAZM21Ki/mOq+3kZ1oZZ20CgUZ+Jk5Gw2ch 4TeBDeJ+jvFzoo31L3X1n+nEC/9ZBP98G45xLY9vDZHeBISqhLjPuVe317hEvnxtvfO/qFrgLkNZ CCAl0b8ctqYwrTJxrUzOjiJlK6sySVQymDHicteXWpnGGuT2cGOKiHEsF3gba5BJL8FUquLWwMGQ BEML7DdTSG+sm8erKfmM4cK975cBsrup/UlvZGi9F+610gzzLz9urwq5FhZwVXQwRDLiLSw4ltnx 2QpT09mGuxyYomYOc99O3P83h5p8CLtGPr2nb2c63NjDBoEODjK/kC4tsfEHlx0zMEjbWWTd1Lw5 fIXNTeELkaEyydhTGq9LGCXajfzGULGOs3gaQZLWhgaBw65w6rqFNq+kkbERGAbpF21EM6DT1qaW doYYh73jFNx+E07ierSVdAu8G2HHaN0MMGFcN7Kg0+7VvtBBrdK1NZhID6NXDW0/8TKXA0CU1sdC Fn9rzdCnNuhhH/Z1vcRPw/DEOEHFW8/O9/m6+bQwLYPJKQtID93tWkcdV2H0tFl2Q4I+A5UAzuKT 7DJX1Yzdmzal/dDz8DvJIvHUqVOxwNy+fTvnfe5MvdAw7dZuhim7cL4/HUVyNgP9e+2111i8tqW7 77svHTi0H5qJG5Gpg+nWm4/gf3KYHaLPpRc473f//v2R3+OPP54OHT6E2nSI0w7eSV/96h+mV195 Cbu0HenAgX1IGyeR1vWkuz5yV3r54MthC+cGCJoTOOd51UoG3RQSc55wFlyBNv6t/V2NS3/fJ/vn qmBBhHXa5UOVpqQtV18ZStr89Iv190M16A360+nDgaw61N2Iqgkd1yKMqwsJaKbceQqQcRF5IpqE 3gUJD3x2RpLYGgP+i/BQGImQc7vfqkaMiR0klfSaN3K3KFfpjcxPK6vbBVZuTq9KjtZQC2ZJlcyL KyLr4MDKDQtkhmBZqBNpkPRYfVM7mTvrwzUYRdoY7SVfV1ROVNFg6iEzF4wm7ZbZCIYLshXHXEHQ 6ihb24Y6mRuJoSVhJNyIaifgZE7AT+Yor5Ai54BFwLN6b33n8Tkng7GCPUsdRNUB2IxaZoIdoBJo pQpt2Ht0s7p34nK16VWmA8iSBj9hwGiZ/fUL7KQyrgUiKkwWqd8ik2I9k0IXq2/PwlO6pg3cElI1 1Qq22/r7XyaijnMyAVLAKVbnzg7Czdrb30rSFKVEsA7lPsf4TW0wb5niYJrie/OoYQJJ/LcTHfPM zMBVeZNPfMs1NyDnnWFTk6/lioSEkPiAizJeEuZZ6tuyeVOq274zTcydo2kwMsSFSl84+E186R+/ u9I+oSeeyThQQkBJ0AS+E2/bjfcT2xwSRl6We/P1Z47GlSsAi+/M2/Nbjec2Qq5R9XCNi+9lyAJv Ldd/Xi2fn/i5AG7GOII5bcQWtRWdVguTtCoyYeL4VKIYTAH1VUpo+f6iP70nL58rsFZwyOX4IktT c3qS2Rk8UDskw9ZFCVowzsRDCqiXeC2z5iKRNpNxMHGOW97LzLYwnmwYSSkCKQ1MgjXzHzXnr/Wy sHwVfhkORq7XPH9huUB/ha2iQSdodwODTXWeUvwljkKqR4LUQlko+tJWGNpu3Pl7BujEChKsNo6u 4rihBUwQjmzexdFM3amNNIOoUY+NXEyjSNWUWnY3tMfibQZm51IDSyEc6+ouRluzPhg8DecvTY3z baYVnSy0ejkvdDqYOnaDwqA4cXXCHHVx/FQDEqxF4jw43U1Lq8CkmR3knjqjhGoK6dkMtEkgqVnw rGe1DPbiPGpN/HjwLo8/d+QuwJwrEZZWaAJQB40dQzo/vuLh5MCMb+EcgXUDDCnlw2T2AE6PUBuD oZrg+8tIFqcRCWu71w5T9sg993Ak1DYY8/p07KQ7QYfCr1sXvtJuPnILkrU96S0YsjYYsbMc4i4N lWmbkxY2UAaSyYELA2nfoVviMPbzF8+nP/uLbyJNa0k78d326GMfo02cPDE8kr733e+iwvwOmwm2 wpRtDxyXKdRl0eOc6ykuPfvss+n//A//Id2JA98HH3wo/fiFZ9Mzz3yfhSz0kUWztCDbvgIa+jMQ TBwSf7zyV5zNT1wi1ut/ezA/8dVCXBD7i37iWfxzQZPLzGVEet6VuL+dZv631+3n4csPpBrUzrEj rxfeLzXo3oO3ZcSpCpKwB/ETY71h1SkD4oOPwWBASCOQ1rssyaK+DFLx2YnC/yKWP9MEkwf1NVtX dIF0FkFErEAhAvpjc7u1InxVAh4vpWrUcpWcyQSZRimTwW+FU0hVeJeZuKpc1+KUw1OklRGL+vFN 2MaRj36BYhKW0WOSgCRHXn4io6GfqBhM1sGK05BW1CNOMHPsEBNS7sZ0lWo+MSmSSGmVMHPFmw1a Mxysi2rTvl2sCFFPrEBcJ1C5tKDrccB6luCcTBZ1UYrZDtMqoaMWMFkQ7m6Oo4FY6X9Nw1i3xOcD 4Reinp14DBc284uc/Qcx1ZHx5r5NwFAGlTwg9B5KnHALUseuNaV37mB1NSlhouIZVrRVqMVGCpgY EvDWPgUAvAjG13YSHyFg4z0/7w22ARiUPirExlfGlfhyX559b/A58jPPDaGklanwd1Woyi/5eri7 6j4hsIxkdElU5qfasRV494xMpvOvv5HWkAi0MHHBsYUq277V+7+zfpaSWIqNj89pXm6DtVSqGtIN Xjo9KhF1AmsB/5QqtcHJtRhPvykd0j4rftxrjxWqPuKialW+WYJkmVHqNaCQ35W/qkHpyegTWkHv INGmrsa5UHLX3zQFOCG4ILHeqjVlLNr4tSDRiTNlZdZ8R4KoGynFDevjaJKBMMb2x497Q2GWQh0L PBwjwjDqwr0TY4wn6InSOxkq6YZSI53Lxq5E6Qz5BtNJpWWALbOZsRGS8KA7MGu8yM6EZZtNQ41o qzXxan9xiV/BXets3qaxWxdjg4HtCkibLOzq3N07z7h4exIGpK839c+Op2FOPMBjbhpHklUPjnge pq5PnPBbMYFw2TbEmBvj8Hh7sY9zQJdwZtsPvk3A0OgQVxXqVqRl9cBfh7PzaD63INluQ1rXxTFO o5g9TMFUCTfb1g5NUXLucX6e4qLd2DzAmGQMq75tIY3SsDbSywDasHbGu87D5/DduOiuVODnAmCB tnk26Dxts67Sl05UvqqX9V+J4Unaw87YbdAycWAWuitDvcLisQFgNsHYr7CBog0nvS3Y23oMlidD nKO+qrXpHU5g4CSBmw6EfdjBO29Ps3TEZaRgy27iIZ/Lg0NUhrFDH99z9z2hzvSkghGOeTp29Bgw wiURcPIg9n/3+/8WZ7X3hWrzL//qL+L0gW4Y09tvvT38pA2Rl3a/+/bv59ujIWUbGR1J+27aG0dW /Xe/9mtce+Ng+T/4gz+Isz9Vvc7OsYEk6J1zhhofAOSKgCB9EjcMIV0TeMSR0pjqJ375fCUUWmRM oXGF9tTGXfkiw8Bn0znX1TJr1m8ZdXdtMN/avMt9SVPK8/qhGrRA5Rfw6oHteSIWITLCFeRwUlZS VhDW9xI8iXgEniW6oV4E1eMsURK5OhDzRR6DxsVKLKIcXwTCe/WtU0Fm6HQF4pl6EhNXSX4eGwKI MycnB6VcTjgOehk3kd366ueoDl9K3MKUOBlBNiFiYXtAXKmyJTpZad9lYplI6+Fq1FMKPG5H+wUZ wGi/Ey+Mnvk1QeBcFaoSDSkhnxpnfXXH4SCX2Pqt7eUOpoh6MEnH5E5etkOmMphtVAWL05yBymxt G+YhJhLodspwFS0zNYqKxG3kqkUamRga2F3bqgQNRQr0mitMLKvido5z0XB5wokYo6sGbFrcXapv uMU4r48JEYItnPTZ5CQXklQrxHMAjskjU3geqaN9oxrHxPaScLdEdxR6RmkAlXrnyd+MImlINbwP KU4FeNtX8KHgl2lqg+9LOvtX6aklG+9PuP59QywSYBSK4Ty3wTi4onbX7hITRuuuHeyqQ/LBbjB3 CDpRxaRPYfabnUbSCD4WnBKGwsB34nb+53NOnePLO65VPlfSE+G35pE/qb7MvRBFb4iPD67xp0qW YU9mQsqxacbr+RMhLsmOOaqt6ZLMEndtwFvnrmE6QLzqX9Nke7HMqJmd+druao4L2EQxxBnybrlc m/grrjmGGItiV/Q9cTHpAet68KwZ2y1NIKxvLPyinzMcVxEJ6kdsFSmgeRhW2UWpdEymhtFHjNKp Cvd4yi2r6kC8sHUsZtbOCJjO2HBAe2mQOTi+PQrMBUgHjOtd7MhcRdrVikH8wPBUOjZ2mYVTS3pg 8950yzI2Wi0N6RQnIVzE1k22tAem60DXDtSOHOQ+fInTDxIS27mQ1vbVsaMBgE0iTVtEis5qi2Om OIqJ3Q1KuJRAyUzpU60F328y+fN8O4YjWfFeZj7sz/jOka9ZiSBahGHS/rAOmrEArZhGKl/HLxa/ MLgyAfoncwf58oJ0yfFMa/lYhqwJJHdB0ka765DUT85OACvoKy2qk3lHWtgGjV1pg3FchhHEfm3c na0wjBcZL/qZc7NWEzDTjck2pHlHduxO506fQV08kGaRnN15+LZ06MDNuNU4EK6W+vsvpddef42T WXpDTakPNE+EeO3Y6aB/uxiLr732CnVnh+3oUHro/vvTbb/zW+nkiVPsIv1heuqpp2DENqVf//Uv pV2c2akrECV2Tz7515xQcAzQspsXezj9uQ1h4qB5wyJtRWMNjDJ9Fh8MUmP7LsYHVxfZgSzcizGB KBKCCOVaPZbYkhnP9lUJ4rmh0DPfZZqW6aDx0jNpaknjswvkjaHkVfLb+P4X6bmOw1qvDemf81ba udcL75dk7a57HspFgDwCSYQJ5Kiepf6hFoN4O/lWOEhK0vOBX1VoHRNbMD+8FTm19xJ/4xgVv4+P JYtXgmUGIsNUhAQvyhWhJfD8IFB+JuHRnk3GQLh45FMwmuaPem+BX/5eZgxi4/cQnPCQ7kCBcSHD YKZkLhtQL+i9fD6Ys6gF6WFMykoL6i/jpfGvZ8xZdyUC3utywFW1+bjrSKfAMnj6RtMeKjM1eaC6 I1UoCaMIELxGnGx24MCyiZlw/PIFiKJ+giArqFPqOLrKw5Pd4bnMqtfJU65M/24N7CZzI4O7R+2n OdIIAyVtnuXaAWHVMLSxHSJNXs0Q/h52U7l69oSJRSRqU6h4VnX9AXGXMMQmAyqmrZs+7LwKcPva g6YtJzgXYHHl3Einw8o1CWlloEkU/2nqlVDT0cKvlpiZqDxnXBFfZFpyuvzOfszxwifqUn0XuERf qbq8Klh/QvluEfVaMwxzqBVlqpnvlbw0MEk1O3lBjBuQNg6/+WZawyC5GRseGQkwBsbN8We/iLO5 HCdOmbV1qRLl6fJZdj6kUYyXZuFIOzSSV+rRThlK1vSfpeRNqZrHTsXZoaTx29hgYL35t553PBNH mTJ6tSHaXxOh+lHplMxSXHmn6lNrUd14uOtzHmZcuyPP7wyJG1gJeKgjeM1Y6eZ7d0lqf2Sd6sEP FbNZwkY68pJZcGHjRFfqGlXL4ImypQn5n/DL4yjccQALnZk6ruw3u0omRGmWmxCUstkuJ9wGGAXb ssD4XFLtRz4uzqJfV3EUTXnSBxk2RkbANepMuvWxRukGv7Z663Umje2KPHgRal/qYtl5Y8xq6ofe zOtHkiYcG73MWZ146QAevZxisLWuNQ2zfWB4BfUi3/fwvA01njurRzlL7I3ZoXQJteG2BiRVMHzz TMhDGNDPqXpmN9EBjrbaDK04OcUB7PzzqLFujqdSxTlFeyfZdakkDUBjB8YucSRoK9I4ynfHqjtm baQWh7BS0TZbmGlFHkPGhuSb9MYLy1VNHSIAf3Fc+AOJVmxeNytVC9jJNMIIuuBlNSNs59ic4BFp 2vbpu22cPMeADVa8wL+JzQrLOPRt4JSG9nTX/Q+GH8PLugeC5q5xTtTkyDi2gO0cA7UrYKxWwI0G Hv104fx7kLeG1NG7NX3600+kF378PBsAjqdudoS6Q/S+e+9On37iCWjYUjpz5mzaikuQSxcvppPv nkrb8OV26NBBmMDZdMstN8sD4zPtG+n73/8+8Yej/a9xdJR0Q7u9Jex0aXDgkBu+SnC+UHq5BD2N DgUwZXNTXjDS+EByLhvoTSzoI73fZNiXOGnWdYP9EbQ1Z1xlX9E/yqsJG8d6zau4LbTO6wdesva3 NXZj438engX8zyJ0w2wIH5kgr7U/y1e4EUba1buIA5dyusy8OaeJeKJY9ksTqXIaiIqTl8TabyRO EvL4X8oT2Z0QbXI0G7LKA1GUTwW4Lx74HQAepeKunUUkIZYZkjw/JD/f69Fa6ZXPURMuMiL1qjP5 TuKgRExiD10MtZeMXjMMkQNXWAQ8uFdNWPrCnYUGmTUlf6pnLCHqwnOcSFC1yW/8aS9msO2GNlSZ DS3dccyLvtAcXKuoGEiKE9uuYL6UxMlc8RUHDCtp62ASaeRsVs4JhUhOsYNU1wSdbkxgVaqRr8e5 TIzJQHEeYBNlyJSQpo2NDGFPR5tDAkoTZHwNsUKnYGG8CMOlx3fdl7hxIo66glDbHaEm5fs1GRki hBUg4oX9T5/yLNxtb7STpham3XIMBYb56eq/fhP5VN+bNhO6DDNTFwY4I0iVPqB/dV4/9QQ8XDnL rElnnbDlfNzNattU1+gLqofNBpNTSEnwHRW9bNFySNbJfzyb3knPEBOhEdbdZ+79Lj4Lgs5d/p/j eO+7CN47Hnzwj/mUUHtfxVmN9W9LnDE1kY4+H+MXr5gMfPbeOvLguZaamhuct9QCrSBacs5YQQXV RCJtubR9lGmLPoj2ZSbQLne6JxV1Fn72N31VUxHLNFgPg2ksUfrgb0UbJ74NG9mol18o9ZK5VfZl X/GXNI5/1dhrVHwJHJ1nTGgG4KHp4oNjNDYzkG6FeqxvQKDPoqe55PLpmWgH0ZQjM7skjkUqUgaO 5Dp7/Jfwbq1jMdbEJgxS3duDHzAWdyMwlG+zm/P1tVFgt5Ru6tqUburcjHoNh7qoS8fgfCexZ+uF hbqle1c6jbuJGeo8JT0BID0cAt9C/ngnyG4w3BDkWKdu455YgnTN45/cbFFPG3ExhtoTZ7gwem6G YADTdmgO/ZQ3Q1lnxmjADQYLZldg2z7bIBGQ2RC2jinh3gT8YvMS75oY57OAn+UbC16cm0OLZKQt X3ZcNasHxi/5HacbWBd3zk6ABCv2A8L1Nr5vg5Z2s5Dsge6+9fqrae7MO2mivSltR+J1x02H06Hd +yhnKZ3FOa6mLY6dj330Y+nI4cM4rn0HFx7YybHrtr29IZ04dhRcZffr4Cw75ZvTN0+9m04efzvt 2bcfadkD2LLdwYaEI2woOJye/Ksnk0dW3XnnnbTJ3e3LaZAdqNvYlXrixNvBoEk/w50Ru3nTGqe6 ULZtFHJqcgzOPeJ6eC1wgQpu6YIp0CgSRDL+FKwuz34rFuWQxxl5i1vEF3pY6Js46LtCC8t740wT Ie6t3/VD+b6k2Phc4j+I1zq28/40lH/OW2IH5Anr2hV9vyRr/+pf/RsQHcYH6YvG8+GFH2SVAfLn cVRZLQhhZBIKpAKxRHrvJcBKe3gKwihCl3QSlbjnTUFYO6Lk4Tdxb1x1H+l4ltYIg8zEScIhOZQT 7j2QJqma5GMIdp4E9B/UhIQrbNy4N0jwyTbStrC9vIEdUx5PNYd43tW7hHwOQqt9mrUv6k4KjfpI RGWcWrBTsy4qV1Utqkp0B5HSusZQIzsZZRSzzbbBQWzdo33c69KkHkLbxQ6wTVt2pGlWih4JMzk2 FDZPlt3ZheqFidKDi2cwlFWN29e7Kdeb9DrOdWfUMpOAeXv+3ja8dV/svxAqBjlr1aG95K9N3ewM TjJl8PgG8kqfeSgxu0epq+ond3EJKskNkMwMkW0WfEwy9q0wFoxKe2JXL+3zG1eqEfy+hmAJ78zo mk8FA/IJokZaoRQTt/m6EiAUYlN7LfcBSwokOYE/cbVa9phSH6/eca3KK2mIhhGHSWHm8mfF43QN GshnwYoqOWmkLa3Y30y8jRuBCxdSm1IFMlEqJTDqQ8LG5z4TLM/3/jUodQjJZDXJtdrf1C8kVpTS ijiuhbLjUHe+yTZrTIB8q5ox7Nysnv9IZ66ZTb5SZtVsi8shAyTuhYXtFJrirFcnbHtIu7XsVob2 MOGrUpyHQVNdhwwl3geTTokd9K3SwWZwsQ28b1UVRh4hTbM93LPcEYyBD3lURq2jzrxmopcWAB3H PjCXqdL9gy3RfMACbKPt002H7x1jSrXDRyG4GaZEfBEuPrjaG/oec0HhWO1Abep0Fpt9uJqXjJ5S IHFZXCv2dnlkW0eZV3CedlhD8zatbaA5gauxOYJ3SqXa4L6FKee14y+N8U7KRWxI3xobSCdw19GO jdb25h5sy1rSWMNyen2iP03CkOzCXm0vUjZ32r7NaQVj0Jp6GB1LUpo3i73aDFInJVR7m3pCmqY/ NX2nWV6Z/GMBZU2opxIt7S4173DhwYAL+stACgY7NwSmj1LsHGmz9ChMNVQWwCnqH60FhlOn28LN /nHjhnaELjyrZSf9J3OWh1kzeK9q2J3i2rVpc6l0L2wjKacRaZqHzdejlraFbWv0ADS2dce21LOP M3ihkxOjE6mvpy9tQ2VJSaEBmIE2nTx5JmjnAr7mVlANN9Xp7ZC+BifsIftmyTNIyU8BQDuL3E42 YMwxT6kp6FGNClMmdpw7dyZN4YxXG2QXq85n4lOY0gArd+CLf2s0zDJi5DKuG9nR2oFrJO37dIxb j0p5FBu6GRa+Mn5BJKhLhgZAIYRkjbbHk31hAN6RL9dg0iJK+BPrb0Owj6WnvgnV64b3xNIOIECf W1dD7FL3iUfJcsTxzrEUtI97y15i4f9+hA9dd7wfUHyf87j5liPBjIUdFoMiGDSZNRkSiKM7Z7LR Y77KqHgWZsQFQycTB6HxG55VrWXGBRQSiSEaOsQtyGz1jQ8ErxBZ9xL+Ir56H4xCdR87P8lHtNXV hcyWzM16npYD0+TAczepK13rUyZ8d055tFNzAytbBmgzK0FVKpankElGyjrbNomkhvjzqB3MX1Wq k0HYnSHm10auDkLQiKuMci6q3y7Rdt1zrLD6DOkcz/IHBgnsihwQ5SyksZiM3Kgwi38k3UY0ka/q 1UbUJsv4R6uDYLVR3062m/dt3sZExQS7xJEysekCxos+aUKdsoDx3HYWrgAAQABJREFU7sDlwTSB c12nmM3sbtzEdvk6/EAtYVXczs41N2w0t0CKyXcWuxR9za3RNgAU7ZcIKOXQRYirfPtFiaNHZNmf wkO6YXw7MDOJ9076Ug7hLBxtakwSPKsmM10QHGd/+OowoiVfV7V+I0OnOCqImwSHPIwPhpnnCDAX 4kFhBr0Xk0zrZBPkrkpq+sLoZHYhYphQcoKYCLm1G4yR2TW0oBpaRQ+2Bpxat2NzNDqOOAP1FhOv dlJxfm1FHMUHQzDhufQcQf+bxGqbq2UpgRJUtBB4ASPuQ5oWbc0JaUaeCnjMefPXG9PEtyWeh43B wsxgPWSGxBKNLb/MmDCBUw16P6QmMi25prmOCm2MmQdWCFv41kmAFDLTIHHc88c0MgQkqcm/tNPy 7VLKJ2EwjfYTfS5jb57anNl3+vEyT3OxG2TqZa60/fRjt+6YmW0wnWyI50H6T1cXTroulDzbVCZu 3nFnueSvmtoPLVH1tP7uQo5MPn5v3bkNKTIXgh8QwIG8WaViJMnPdM1K6LmXaVsDJw7jB2xXfQ/2 anNpgB2eCxzEPou0yVMJdEo7gTrtHGN1FhrSh8r0wOa+NMLB5nNM/mNsNliBdqyq4gX/hxY4Y4Cx nhc1qHKhD8GsgE8AAwafcQu8pBHRJ7aAd7bBxcFSjIGM7S68ZMyts8G2mC6kYkSKj2vAXZXsEnnL rC7AxGV1KG0kvf0rgy/dyrQTeIMTTv/hOAhYuMBQZU5Fg7GHHILeMnH0G5J3dI2pvv8Svt2w1wMe HpGlendkdCA1tTakiekpGEalXDCNbDzo6m5LwyMjYae7lZ2kv/GbX0pDw4Pp+R8+lwYuXkhz+JDc DB38jd/6TVSsD6Rnvv9s+tZf/3XavWd3+sIXPk9tVtLTT/1NevedE2nwwiXs0zIjusDiS3xYBCj1 MKgyeNJNnYJLj7XJ04WKZ5I2Qh9dtHsag+cte7pMHQsa+1uAakqTA9+5yis4I37zE1bSTOld0Kgq /urxWWXhhffRUV5LXjWv8zjI9ZSWmidFEBx90j2XIFe+NE2MK/HmAx6yzucD3oh/qOrr00yciZ1g gQJiBQTViZEXHmVkcCIthvcSX8XwMmwyKUpc4h4mYGOcE/6ijljJLxiayCczeGH8LYIxAEIiRZpa iZ3lWgeDc3tGyFyvjOzGWVt+EJLJUQ7n5inILNgt0ksIdf0xAyXSU7nvnfxXl1kROgIgltqvtWFE q1rA/Fz5zDOINdqVdKvmnGegrxDXxDaurNKFsCHJa4aBqeeqakYfSYAiwyoy4r4wrxRlvVRKDI2N cYfyQRGCsah5lK4ssIVd/00yXkrzOjFC7sIZpWrXOfwpzUH0GjhLqx5jZndDATWMcvPZrDJDShZd Gba2r0J4ZoJBUp3q6k1YhBpEokLavLID3sDcOrrzyyBIXEGHgTnfOvVLrCRGqo61ZxIeOrmUSIkT 1sN7+1o8Eb7CXWCG1MTyIIymDCaf700HAGDOaLndIF6AC3mS8FN7lfyruIyLPlf979voeGBoBgQ/ yfaV5mO08TnPgkeRMNLmeMleYVI7tm5Oq6PbkGqeS00wBLLplr8xbMxLnJXPsDfzRppcF6fYUKtt zOAf4dlW5J6ybtbLa2bbrLimAfy1xvHPdsvnOqlr7ybuyiDkfDLTY34ZwrQ/UvCevOjJ+CYkC7zx vFwnSJkJcTDjn4xVxXCTj2pO3XsYo3uIWODw3oWPnSl8tYGKWsq8gHeqCmOBACJkdlDJoHUkF77V l1zYoJFnMGnkYTt8Ku2MvqR9Bc9COhv9k/s92g0+axundKuFtAAr7EqHOZppmsXZHnaH7uTUEFmi QaQ0syxme9t6GIeY7oPfc5w7in1/LBBXgPMUkm4Xte7M1N7VWoVJAuNCVxz1SA61D/W0Eo+dapBp 458Izsiq/omfwE35KHmvw8h7gnCyzfMxPpE6Uud6uXKDiyAu2kkqw1LtaR1c/vom+ot7ewPqwZuc X54J4MeURDkv8EL3GyswaVE/I4QP4rkldnV2I4l0EaiUqrOzJW3Z2kuB2M2y6JydnWJn5+708EP3 px88O5mGh0YCJ5955hl2uY+mUTYo1KH+7YLBY598+vpX/1P6s2/+KeuouTTOCQU/en4kvfnGa+S9 glPwCeC0lrbpq7Kzne6RqV9LU9DTERZe89gPakscbnnADwY89WVOmELixmkVPX09qbN3B1ekccxh Q5cvQm9ZtAkXFywRhIJgBr/Iu/xcXBrKc+01XlzzT8a3a74iskL5oN+eqqDEWa1SUdNmqZsQt9/o Z2myY0Wa+gEPLNoyoD/g7fgHqX5BtpK5k6GhxOdHCINLqCpsREjhmyfbzISJWErqnJg1PncF5UQe jBxx2l3J7EVcvFdSp/8g02XVSJmUy1UaUMrlBoTO9Yw46qX0LhgEEFgCb3oZEtOtwKQtk78qQMmV 6sUFGLOcnsExz0qXHVUrrqj4poWdl0pWJOktrLocHGucj9fE9nHVEq7C3NDgincesbPzucNGMbrM rZOYAyj8jDGY9Q0X0iqYljrE+W4G0OP2LMQkJg6Yo/+fvTdr0iTJzvMi932rpaurqpeZ6emebgCD IQACFEDRYBIoijSaZNSdTBfShX6B7vRTqHtJRpnMJJlWoyQKlGTgkCAJYTBrz9LTWy1dVVm5Z365 63leD8+M78vszKqungESKK/6MiI83I8fP769cdz9uBsdtvgqP6SDcr2Y8E2bSxP8ou1z+pN1GZbL BMfSwEamrpW7gPEGu9au8xW/ggmKIfiIppKvSNXZO3xljjDXtceX/B5aABe726Gl26dpwGpkpdbC nsJB3PIQlNl0zMsY0z255zn5knMjwojg1ndHDEz211kTh0CUpdPSAjZ51KaTsusxvXHA17i23VyU rTtm5JCeICJ9JAW4z5d/qVcFVFrWCWPh4jKQIm/TyTuuDt7FeLNh9C/1pIYxnPf1meQoL8sPfzdp vH632VljV9zyCsfaomeAzJ6VpuOk0XWWt05thrTkwX/WCwHPl+H6U+yneNG705BwJGgicHhDNpkS RBZmz/WWkZdvCWTzKkdYldwlHgEFUVJIcO5UnOqKlPH33viEcehwkKQCcG9ZUp8AD54zqabM9iUY UYOhnStJuWbSkx6kYwjrqXBBMFaoOsxSrvwLPcK5FlM57wIKZM932oNDfwe/5Z1pZVclfv7TRW61 LiSWwikDXg0DB9B0CpMPWu61xm+7n6dNvzWjId0DjNNuNT+hTzvGcOwctsJuL77SPGUqbRnQ4Y5N TegA99hJuYmGrayT0uSHsxdqGXWe0Ywg+EkfbU/StR3Tf0FDuahBsW24/tIJX/sbZw3o/CJn67p8 y6saCnM5wXSs2mUWcqStKcdoz0JHTZqbO4o8jGFsQaDSESSokZ3gj3JQuNJWHhN+oFqupG3ozCYg GyRPeVH6tPF9zGm4TniCKd8Zdqff//hxgN0tloLcfOfNZm7hRvOn//pfkbchlmywqWL3fvPgwack jczor2aZBbnOJoNRZgVMY+3RGstHWAMIYBth89Q8GxUm0N49ZjftGHzMLMxF26pMrbujmFsZZabl 00dPqYhqX63pUiKf8G5NOmZh4PjEIs+YZsHUSNmFTy7g13DW+/KHq7eJrwysF209sr7bYJ7RDfYf g9GszzOYbPKDXblMs2N9k/p0svSkGwH+6hhp6V1191KzdkEJdgcvg1WQVqNEJZtKYK3FcbERd52q 4XIcUQF0tTLmmspEA6YyF01aGXiteK4tKKCtTLm6lsLFoII4/U+nXAuwiz/voi0KqKCR0PlncPSz XSd/dnC18dCQBFr5OqEBZ1CiQy7nv9EoaXCHgKAcgo5xW4HIwaTr9+z46eIZLBxsFIEGbG1IY8S3 j/TL3g7Tgcj1JAGfdNpqquQmDZpOnUABuyN0XCNTTGNiYoQZHLbFOyU72Sxd8/w7Ok6+0ofGtYuG 9o7RcIf5tGXOz+sBuNYEEOTL467mF0ajJXQHk3kfR6PnTlnNbIyhJVSL5XTwNMYs9R+i86O3YreT XJWOxekU+y7LKL+AN+7NLv4aAFaDqFZOLcAu06qHhwx8ADK/lh0urRvyrRYjV56dyhGsCYTd9ZUN FtCcZper1snXQpevRAdn6wQcBQzaeUJEcFfWjzAQKAOAtv4a9N1Bi+h9ADh8OXCoDTUt/QMe8fND oYYrlvnNdymPeq2gz0E9mlJ4V486yS60SSysb6xtoF0jDVGJffwlznwIUBzUoMi/4rzW+9br5GJf 3+3w6z0MRS7mr7ozoK8lWlMyv6fpnN7V+F71lUcB18k9jAtPyhBrudr58wPZ+M/sm3Z+7X3No4OD gK9osxymoUUY7yrAOkCuTtcZLpiAtN0d7m5ZNzG4Zsq6qIbV1BOftkehgjhICYAiiCltGj0P99QQ 0izaBDVRWXdFm1QLlLNOoS0v5lENse1X8KOMilFfygk+olnX33wa3gj88V/abp7LoKx2+Yg66DpE 492FWz6ZmgfYVlvm/M0PdzebRbTN88qOcBqo3aI9T9K+mRnk50coGmnaqG0zsxGmBa2yacD2xZID /AxTZInclAN5dd2hQFINX46kglVbzz59r2EsJ9dEKkB7YX/Wn7uAkVmAx4wGdNH0PUKj9YiTFHrK hbTm+UAdZzfoNs9bgBzbVlb+sfbQzSf7XN3wEbBrP6gjsQP6aTd/WA6uY0s5cl80otYb/Nj4NH7E rn0AY2wOgn/Mx9A+h9pvcooLZyG/8/bbnM3JsVQ/e8Tud6fHySPpmucJ+hHPAnXjhT2YcrG3pXfM B98OINm2r700N44d5WNW0MtsieUFf1vrK/RdTOTav1i5/KLSEY8M0s9hgB0F2xh98RDr5oSvI6zD o8cLdrbSWm8SxUIZcJbZl++QN+3Bj+5J+s15dvS7MWOfsrNmW/8qT6m7lJ1t8aT/+PIZ+qVRZK1v W0C/tCRfPKFfluDrAPd5HJ/Wz/aOS9VIlTjIlgbddafiLnHshrsloK9lUn/GNU4dhAO+aNQCumpX LYv6nXblZ0fnsyY7XDzqGrojtHc2HAGgnaK7QU/o0ZmUQcpOhITatEu6LR882I4dFPa3XfSKB4y6 CzWNw87dzolGb8cYzZQNKh1UGc3tYg1jJ5o8kGvXc9CTAXpo/Oy73+BMyj2+lAIoSGKUL6jjXQYf Bp1ZVP4TLKIdx8+8afdN4CRw9DiZDFrwsYVxzl3y3WPNjMBuH7o7HLQ8PtYj3wJS5IEstMwOO9HU +VUuLTvAUTt+5UMYtaAQjqxs+A4B9j8BYHnWT7CkEV3ekWcBoMKp298tzwBREnC9lvn1vFSnajVG KWhbYi2dBnk1B7LPBoo9wqrpmGAaXq2tawitizH6SxxBXw8ArHFky9yNIXNzsxBvsnZPjaGmMKZI p4BJoBaysQ6ouZGe9cAPCeuQU/DWB+tcvUor1gySRafpXJuELT3WzuyiWdu79xD7Y4a62ClB5RxJ ejUN5BN7dIlvAgrmrCudLP6pk74nLPkYDC2Fritl1foQmOg463IolBd9RHiAyXIqhzzaIgqvBpZ/ n6XrqSP+S5sxH+HG/JT3Ti2GNIml/ksAFxYSXllQFgRyKNsT7NsGlQXtx6k2NyrQSjM9N0adMq6A znrnbmQ34yhP7a4FqELLdkiNJk1gHfd+pKi19dD0HBkEFeu4Hzp+dCqLnKkLzRj9pa2681M2kl7L cXkyfyUH+WtknGvhBCo+5cOVG7/+51nE5saTHrzf5exMFM/kEUOwvXVAxwbrwrDXxoahHeqtNs1c N3Xj2o1mm3a7usMZm6xbc9lC+irq5jB58SPHI49cf+aHlx+KQCLkQkmQf0timHe0lMjCfthdvAJS zcS4aWgKP0+JuEa7emXhWvPVY84sZWOSplK2+PCZPF5vbpDuGBqpfGwBkFyX/DH9k+eVHhCfTy1k J3BMprNZRglE3shDrbvLZ3TycASNoq0zgm1MXvlHe/MQ+TE+gtWtjrCxYmQYQMj7p0/uNR99+qj5 1m//bnP37huU+XcyjJiOfNlveCbzITMBh7R/jYnbH04D/Fh6S3+336yurCNftbKkYz0ArLFSA3k4 K0I9AWTuoclPRYLP6GdbwGY62plU3o4ZM5y17IaaXfr+VWzqHbG+cB+Nno4snzjrXXfcGhynffcs znj+7Iv6nP7k31mX+fml5vq1V5qHDx8qFfLP7ATyUID1Y7PGfdZ0a/i/qNeXmrXnKJnBymezK79T IoNhhupcSBtksL6eLtAsARwoqJNpULlJ/S6NoKbSX/kMwOBBPCt3HWwFZAFzdOgHe+U+RyoB5lxL 4QCdK409Wjr9uRfsZUOFgCX0iiYmX16mk9TK1yqPGUS8+mXrz05MZZVrSrJjzXe6euWW9oYrwM08 2nGolZt0q9U6R8kIbHi/y9TIGl/lseXF+4lJttazrkOwRo9IZ8xXJJ09uCSdu6L2q1UmZjHbMcOX l0dO0XoBQ0x5OrXKGjh3jU70sGZOZyTPbjBw2sU1Hukt7SQoKAeAsmgW7xNZIBf/8eyXvk4NFX/T AXv1y9RBxTC60QPXzDEEkz8HnXE6Vjt8p6cFbZaTu1K32FQhuHLHoYBungHNcwSdmvaomBmArFbY 1Zjusu7O8vQcP2k6AAvGNEysMUxtzE2jabRMnVbO6Q3ISgDhNLVAdJgvdTu2aPlIzyl4eTZswL2G xujAh0EWwE97+mYEnubYvba6spqjv5TRhS5lTffP1ZAF5HjPE2lR9PH3ubaNInmp6hcCuR9sa4ao bpCLwecazmtJq4UlJOo/MujfE1f8Str6d381UMIbr41raUu1Omk4+FZnvgxDTaF+lym3Peqqux3d KKNsMtVJRR7lWY2LO2XVhNRNBoK5IUCIdK1jOvscP5TycYlA/ahSz6OtOjk64p3PQ9TB6H3Js21c QOj4LBVDWp8FX6ZlH2PurS+WcclrfMiwnCqTtj/gIc9p/Gqt4JGRZYp6+dbRXHOHj8VPj3rNz0Y4 M5Q1Z7aPPQZ+I8UMB/lYQctj6tNjbACyD6JNFF2mHxlOSJpH46pVRl78yj+4sA8xD9D1w0v+ZGUO ORp2BnC3QFu4gxbmTaYZ91i/O+/U3toTDOWuNHPEe216ofnGK68V23+kM0l8zzH+kF3if7T8oOnx EbgF+IywWHcGFI45FBOuSyT8qNTOmxrNbTTdAf3Q8Tg6d9PKozKLnJUvbfOIPoHswbdtkylNP+4J v8FZqv/s23+MOaMF3tNerR3ka5K2PTZFf4KRXcvOnMeEi19W9AFjk2jAAWQur9lho4fAzP7Unazu Rlb7pnAEndPQ2KNuYAKYMH7IyqE7YuEJ2nas+6xps29axuzHtjtBWWMoL4jcxJMnc6WzztSxKfUn gfLquf7UuKnPxKz9qEla7+27dgD2a/SXm8xImLprlwPw7P9xVWlSPryUvbGvtnsJ1p6j/AaBWKmq /ZVgMEytvCbju8H3g5XIxlXDlvpVntv2cPKuS9fuv7xoL6RT1uCURmTnaPiTaVEavQ3AATmdNqAl 05R0HgWwuZbOezRzDNzRvDiFSQe6x/SXX/QBdLQcG4m03B2nNkpng7I7x5v7ck0Hmg6nNGgHuDQ8 O/6AOwYkbrI9nw7EBuluuV2mJdTC+OXoWYJ2IsYb5nPdXAvqPNLKbfE5hD1f4WOY9VjERthstGqL 7FIjGdaSANCYZtAYr1q0Hvn1hUZ295gOcLGvX+qaa7ADIlnyZfmSYNsRKUe1moIq/QRz5UQDwE/7 7Kyz/VTkApFhwNwwX33ZiKDmjTT2SPMGhisFidusm1thDUsOUCZedu4NY04TUB05mDbyUEOyxZeu GyRWAWlOg9avSDeIOF1WjaNG00Lao2pYMpBjmBPNpOW8jaHMdPLQFbAXPpEjnb12+gR7MT7Mjs8j 0jxYY2E460N67ualU5/guJqpV643O+ww86DrixyiOHHeK79crR/KDlkfO62Iv+2phO/8VfyXuBL6 NFCK7PSx3A0EkovKSyqUY7yyhweBlM57Xf6Sb10lk2uXt+59wkm/hCebuJI3aZq2dTgHtBMvCmYq jbsDJROjwdzxSYUZC7SZlKsfPqFAGNtxBnwC6yuo8QPINY6CvgiVj5Qhytr+ZJr4++7sJYM5CorB XxBjfcy6N+Kq4cMToAanEFM23PLAtdNv6acolJVt3Kw5xieLenpPAD+cJnlG700uOMWAdVR30aDd Y23oU7TevOacY9a/4nrtlJ0fHS6T8JQBD3g/tp0R13ppPxJNYlJSowcYJVHzrjbTZ7X3+qnbnrTu k8dxNHuLTGXewUzPJJugph88aW6S1SXk/Samf5YAcUvEdMrTuE4jjiO7CYzeHqDFnOA0ho/5YPo+ a+62oOlUpZpPpz95MLPEgAfauADSfOkEC2rCh+hD685hpWS7UzbmMdPQ5hHtGjWCPNibuYZX+aMl R8t+NLYfI7j21cCpTNfa/2x4nqko+wCQzsYq+aAjZGpwElAOmKWftm5YL8ZGiDvB+jnAV2YzLE/S n52Za46xdanJ3xGMErsbdB+gtsHH6yHr31LCaPEmANjybF+BOhCadpCUTICR9zCrk+lc2uc8Pfuf 7thY+yLroTv9i4Nvy5r6vMrOdGpJZgqG1SyyfnqbEyqO8gFu+5Iv2O3U3ULj6v59Cdaeo+ysi5R9 x/U9dPzLbamyp2GMXxH/aeDT9/p1K2xpA1IplZTLyXsbfXUCMxmrcdPRWqntwbj65amj/+tz8eWP u70EHKaU7hdGK5izkwjIo6FmipUBQK2dB6UL4lxLZ8cAksi9IC7r7QgjjWoklwTgmO6G96HpoEM6 GTBbRo44nNL06Wr4wnU9D6BQQELHd0gnsoMpgABCwQcdoYOPmToGAB0D2JgvwCClU4weecO2eqY8 D+iU93ftjJw+pCPG/pGd1gRzAseH7KUCjMhnwA2DxRAg1Y43X2R2viThT3BW+KXj48s106TprBCa MoJviBBO+0xtvrgKpmL+hPd23ubPKZBdz+JDfna8bp1fZxt+DwDngJUf/PZ6ljL/oOvAuhtgxbQZ 1y1+xve9aSQd4ipP5e/AIbizPARy8ReU884zW+Vf0OqXvOXp1LFpuJHF6ySD2AzreFhqRDkw7UzH OMxuAoq7GcfC+gzatR20a0OraEiUj4gknXgqEQOFla84hzA1O8VZC6xn5aqfzzplk3eUq0Vb7rly r2svufdd9zmen/MndHxnBB/i2hvrPs91mFV7oVPLU9uTAayVGZagYfj8kHXWq/ksk+0741su8TJu 0pWC8cpf8x9TG8ahgh0pe8I6Fc6xmZlyc+n4HlrxHoNtABnxmdFi4OTjhfCCEz9uLGM/pA4ASdbl bEwgruVq+DEMzHoI/R4gzXL3o2LCRfsgswP8s+MZ/8Iz9OAxII5waptTv8hE6U6EAMmIf0mlLTPv k/8SzulIojdbAAnt9bmTcBFgMcKJBuMM+E+Y8is70NsTCvho2WGqLh8WgKRRnp0qtlxc15d0aAfW K8tIXgVNiIpyAkxwPwUD16iwt6bmmhsAkdWn95vrGNOexX+K6chXx2cw1rvUzFAEU2jgZph6nCIR eUVwpIfMqKgHfK0JMEmOjTQNNvaGmznCUBQIfzzTqSytRclH+vQ79g0BLoIIPqJSVtyn4yCKVwE4 UQCeRSPnc2kTpZz4+iQvJGZfDi8zaNyHhtlFCwCbR7tmPzExOQ4Y4yQWwEtmAaAgp8rAqWO1jkfw 6lSp5oUobPjypAvaPJVrCuDJwl9+1i+09di12+Aj7ID1aMMCOmSxizH1A9Rw7o4NfOQj89GDB5ky laYgL23Ewk2plPrsvaVjen3OzlM/ruZ/8LWeaWeJZrjyrDmpKcxN2R/tcJasdEPbK/JxuYk7Y5Xn e++9h5mme/RN7CTmGJYoKmSCsNIOC+TmqruB4fuqZ+dL5t+vlT5XOqDqZSUYdIOVtTtMlbCDkfqf z9C0sqUGn6Z0Moi0XjEtEDKVlpWUl63fCc36OvFK4/F22E/l0hP3p1UbENcsNKdBOhjUhnMCvALM irataubKFCuggU63+PG+BQtOcwgU7ICkUbR00KU9Sd/BI+YRuE96pkvDE0ClyfkeNb9h4gA1cfau 9EeHTOmtrd/jY5PvZAaqLTrsCaZEXdfglES0iIyInoHqbthhtttn+76C4vM6Gh/TMq+kEeBGJyVo taMYYkqHlwildACFDzpdRm7f+3XnGiMCZBD2dAenckteAFF0lNLV3tQGC42jNWAwU3PgwOiU6S6g ylw5PSzYs/MSUEpD/rWnF0OgpKO9u7IjGW2MAI33HvyMJDJgO2hbZi429ovVjRvKWGxlueonmLU8 +JMB88ny02Z8vQzMToGb7ghgd4wTDbRdPwQ/C6wxPPzOD2I484gBOIANmViVrFJjanMIHSCMh525 MrFiBqBwhbNSn9o3ShSWEspKbGjlK3hQHsWvHaR9qYusy61/T2t28TONgCrCRwvUxks9bqNp5d/q 5NS600ppPICAOPyVpgZWzI/rywQP6h4cdAUQDHXck0MzXjgNH+YlmjWu1OzCqnH4OahLyXTNt1VK 6VUAKB1NNo8gf1lx/BWg5HgjeBRkVE2z5ZP1WYIuyiYojTDKXvuEJux766HnWBI1HxXyHpAIbTkX IKnpM6fWYXk2Tfl1elQdUEqSe9d6mV37I3l2qu1Q8E+5q512A8ocNLe4bglCCfwamprrnLT6Z8dl 9+IRIMUPhQAOgI/rjgrNImPlmj2V8G3KVOWAKHlwXZVmlSbwm4eHr8wuNO9iZmJ8dbuZ3DpgsL8G aJvHiC9r5Hg/x8fMNFd3f4+wU3XUDxfaolpK6cUUC89PAY0b8LGF3wrvNnb2m5scazGP3NxVOwUv o8jSqVIZ34e+mklaTsrIOrRBeXhCg+tPXeYxSUH5qZbp7Iy6giN4gMbBNh9YmPIYdskDGRw9YDMG H1R8WjYbJLFDmWokfAzzG1/72jvNn3J+qB/LlqknxTgLsoe23N3F9j2ylX4LHgRWasL88Nvapr+l z0ME6XO2WcvrUVWGp7T4Ob4J6FhWwUaCETR+WgHeevKUMGxuYObDGqGsrL0Cw1K5KQDc4NgXT/7Y p5W+j/A60hdg69yQpRF71/162oydkvwI5N2g5uarGc6i1RqAwOyQujxEmGvX5rPT1bXCnz38hBmU 7awT3pWu2mD+VWVAqTmFxyR6Rf+8BGsXFhy16oXdII3B58EE+t9n4On3Goxgze/zs3EMukGA1//e 5kFK0OkLF7L+0b/SLE27xqe/iKsNtV5tnH5xChT8BXxxVbMT8GYH1GqHsstV4MY7gZtTgwKHbIiQ Dn7ScgoiWrnQlmZJI7S9p2NyUbFb40OLkdIzRXeesjZFzZraNwcw5NOjM7Szi+zIt35Zn0OH4ACX BdVk2f5Iez7qHVxk76AS8ODAR5q8pYsjPM/00fELCODZXseux3V0HoFlRweHhKbzQhYjTCs6BZrw UoKe8tdmkP5quARrBWBpu00eTb9Mc5RdvXRK8kF67hyUBzVuGhA9QiMmzVJGhmOQgbblaRloYNi0 s6mCtLSdp9bGwewQNcLebqFt+ZmufAgKPeFilGml62+82ayzEHrrKYdCE8DFyyZW8kr3TqcpgDnr zvM7G8ohtAwMcKxsiWbMWsd4Wdxl5HivDGpwiRSZnKZZSRjG8k3Yk0CUnXKEifwsy9ocCG/Y7q/S OqXevQvleCScj51xpL61nuWePwIgwxg+SmzuLJMseK+BeEnVJpBt1aGXQR8NdBztR0CSXaXw7fui OQZecO/u60MyZD1StoINybokwAFPYQ3zLkASJJUpPsK709V/ulZiYVoaJZ5aPs/wZLoKvOjHyBxT 7IueenI02jwc2Wl+vsO6I9rEgVpx0rD+mdYGKMYyd7pQMKa2MWKinloPPAVjjvslTkC4DgxaBHHe BWBcR2M9TaZuzs+jZQOYEmaC8vIUgRE3HASskAfC2DYjPrMA0fwjnV3MX2yw/MLJWgwGsWN0qHmb pRQ71P8tF7djbmSedpC1cD0kTZNaQ4u/B5j6zqNPm3v0XWqse/ymAHnKUbQ9icymQcJqVG3bCxjo HgPE7WDocnRmPCe4bLgWFR6GMFLOxCxAzk0YGvbm4+4Bi+kpdzcjuQMSks0wG4v8gHCjhh9pllXy ZJa417lxZAvwuolhW9/ax/gu2U64wp9xBUIiUGcPInEAmh8ypQJaP2COn31Zcb7zd3opD2ZZ8Ff4 iQmjgMH6lvfWH8u7XaZxwhf+1kXHBcHawuKCgRNewAkDzTrGlLMJhCw+Zj2dzviOFdyd0M2MCPXu L4N7uRv0L0MpDuTBSjvozvOrYQoQK41Yv/PC2uwL1dJoaC9xaceJU567f2tnkcaTFzZeOn0HAxpx aUgMDoIx/LMhwkEoYINpGzpW/QQWWS/HfaZ8CF/DRDunlq6NE22ZAwv0PeQ6mgee9/ki9nSCQ3t9 MhJTHfLAT6BWwBqNHU3cMYNL6URKo1ecAVLwPSLwovPLxgNHk7g2P9AiRvKSqYIITGjGDZ2SHZw7 UqskZc4FyZlmtkM3PokNMx1s5yZPAiT96jV8QkE6puUAbDyEGW2lci2aSr+C7bxlEJpoDOwU9XAK xUXb2RjBewcTu1+vHk3m/jR5OkSF5HE8AYNSYUBUezjGuZAaB9X0yOidm+wSQwuHbMcYiEacZoZm NIkMcsyuPLdLBw8fp/Wnn4T+itZ04gj7oq6UkhLFQVjSdQekfuSq5Mu8pdxfPE2T6jpFJSTqcyQT ecAZEslbQbflTzXJJgK+LzL4y9EQU5u0JgihdcHDM03VirlWzbojhb3YPyQjyi30jWndM3Ou/UKH CE21LNGUWbckiZ9XajhAENrWUWiUaCHEO17IqTI0LIBpHE3NNNrfTbQl1qd5NEi/itmMazNsE4XQ D1i833OdVGIbV1rmljS5HdZcBfSmoe05oNp0u85H2G1ORrgOKNvl/Mwp1rNep15/hfZwmwF+3nYB n8cM+Oir2LQDIdKGgZJX82Iabrs27ySkplPTQzc5fm+OX9YF8m4f7U+PdujpEU/3VwFvk80tNHYe TTdHm9oDwC4D1raxe7axtsyShqfNOkJx88gN0lgj6R6aZ491u6Y5DHJ6AAi6w5Fad9g0xPaf5mGP ac6D2WYdbdYugKlMfNMWkf02bVXNsuX14NFnAWy2ScuUS96dtBXLgxzpUgaWg9lGBj7br+Vj07rg C1wpMzVqxoEgzr45HvE0bf2Ft5aF98StCaXM2/rDm+rkZJINT7FLiaxq2jVdr348enUMsH+yP5O/ fIzQp2+wOQq1adkBi1Z2d8++mSUugFP7ZKdKHR8EdhAi6bb+wJ/hTLPkyXp5tZ01+qX7Sy4BK+1l rlTs03Bn4tDRSKb6l+GstNfq15eGbTkRDFPperVBlpBDrp9oXegRx4ZbGjPdAvd27kWbRgdH4/Tr O+tzaNwF3OFPZ+bB7wKQupMs06xOtwoE+UXbxHPsTvlMA7fDk4ZA0Xs7iT03MfBOHlx7pks+2nt9 jui4AmA67+3YzZ1ZLkCtSKjIQG2Ez23eqmwIr1HfaG24JjLxsxaPQckp2xyxU9MhvGGkmR20AXOu xavgsgVK5MMRtHwlMwgRDgboUgGByWuRSbQr0FZGDh51PWV21JpRBg7IwIc5M2mmzKQNCHYh+x6/ 4RsYzXyy2PQePspg5C4zp0O1Rn8kinB0j4NG+d8+dy4K7cQpJTtcPPD2cp5rX5/36qzf5xHphBQa nHBh4vBU0/Baf50o59/WSPWtz7j2Uh7av8XvvDd9wcAtyBGenDqWy33AS+ouwZzCtBMXzziYqg8R lPmsiQxKkF2lblBgEwF1Xe1nwBaaIdula9aUeHZREsbytv4pAjU2AqhMyANY2mpFfXXbAJow+FG7 Fg1bm41SbqRA2mVId/qPxexs7tljKk97gIsu6uelJjv2OS/U6fyP2HSw4kcEBHbhfxbgr2mOPbS8 uwAqpxw9k/QWbeLrHBD/+jhnjBJ2f4Pd4AC3V64vNK9C73WOp5sJ8NltdgSutGvrvG2EqOEpbdUm AfosbSlVDTwiqHUXqVozeirjIQEPtvdIrT36Igx9NJPQvMEsgGeKTtqXwJvAeJ0NDG/Dw+HYTHON vLi/9TaHpD8YP0LbttUsYI/x7aX5ZpkzP1dZrjBLmAVmAa5NAmY5eeXh2k4zDrhZ5zxV1w3SA6CZ ZFcs09qWi7XIWYfUBfJueZALfoRFZtaJ0nfqf+oMRgknk9F4Uh4Kg2z5wv/4lL6pxPdDL8RLAMPl Wd/aTvQsP+mk3HlWntIIiIcnp2Mrj4bxff3wLDMmpS7Lv8szNEHkhgJ/UheEraw8jUZ/P+vR0L5S dzVr5Ae6P13SzR1/CjPIRF7aD9SanRrmCl5fgrU/50Kzkr2ou4zGYAOu4UvSpl8aqnzUd4M8WfG7 bjCcHX+f47GGqde+9zz0+5dGji/+NWS5qfy333VpjNXPawFaAC86V8/h86swIIwrN7l3c4Rgbo8V xGnkTrm2jd31W4K3PBvXDlhgx/sC9kqHknRI44COrqbpVZe+gD8CNbVKfqUH47RyME/pAL3aaSWC AwnABhp2zP4vOfbWd4YtgLJfVnZ/ADkGcX9Oh5X3dtwygwztm/3xZ4yNDc5+up5F8wKuYfEEBqeM k4Y8qjbJFJeaQZkzcZktHAUAkAlzG+OdeNuls2q5mcZQ7gqbDfaZsnHaU16kYHnpUnUKmTzXvOgV jQHXdOonAU2lRfSJ0f+nG7+8Mb2SVq0XfTE6aff7W2tLvBhCJtki88K7YLaslSNUCq0QKlM65xOV jxK0jWOCJQmI96Xe0ix+oU/+c4QOEQxao+UuceWXMJTpIQBGKUXbxZUayU/wxkBJfUKPlnKyPPgs YdCHL4CzU9/jIBI/kyQZPRMDqgZXBevStz76UaP9t0A5CDs9GVmQKNUkoP0YROigbEmZtvS8qnkU HPqLfTjiTKIF0iTNBus0t1kj6jrbaXh9lbZ0PALAQvP1wdFW84S4m8QbBYWq6VOLxqWZh/Jb2Fi8 y+D7q9jYmmSu8Jg1TgsM8LfwX4TeFPyO0Y5H1QIxjZqTDdjJqK1JlzC4S1Umo0XlmjxJ3388W3BZ d6hkYR4poDWj3zCHpKsJjGtz6Pcgc8zmhCN4dqrTyE7LzvDB+Gszizliaxn+1+hjXkND97PxneZP Vu81oyyA/3XA3BN2tj842G7eZf3nbejuHGHQGiC7ITCxzmGEltYZmuNs0BjhrFCnH22zLouQ1QMR YutcNiEAsq/S1WttC4asH1wpIQmYYX72L/ZhfthZd/XOxyb3Bew4k0A4ZaKzfiFrf9HQUS/KVVrl nVdtzbkzfY1TYyRq/6GTlvehSTiXwsjvHKaW4tLfyISBSZUw1WyUODW8CuwEbCxl2WRjVvU7yS9x pa+Wzv6vxCvkr/Lfl2DtKpfeC/NeOikbMnU7FVySVvQXdZWG13JvV3DawSSFgWTOJlvCV/98rYWx ErHSTiMlqO3cNSrpWOiETvzpxNUWCQgO2AHqVYCWKwOY93YY/o4YSPy55s0zGQU42bVJi48pE/wE KxXouWkicaVR7+nY7MAytUtYe1e7OnMjT3V6zaw42Do9wjDhYzpi85FBjliGT2659jm1K/iZr2ji EoqQSYSQ0I286KzU3gleza8GRikReJajsps0U65owdTWldSgG75JA0JlbRJaOzrPmDJpQZULmjUz Mrm01Exh2Hd//7NmhEFkpNPJkmQybxSzYN5KhgqrPJUXyWSenv+PcaU9KKMLKCkDpS6SzHjLU4Eq RAo9ZOCVDAhSNAdRXa2PkXX15FrKikjGexancFpMGpBGmeEzSPaUki8lzn9Lz2Rc1O+9C9V9PcSU YylZS5e6RjkW8Fby53Sui9iHD7Xr5cBZ8k/U0CtSUePm0gHahjWAekEjAQS5i5oTQUyLdJ0yJ4HI jRABMcrQgvaDxc0KKXOAixsOJpkCfAzAWmcB/y7aJ7O+CFihGpE4k6/YOpvY32keYNfL0wc0YDvP q7ujs81X2OH5JsZZx11IvrXWXB+ZbG6woWCeXZMeKD8KkBm1fltH4TlVgXv/uWFELV3ph4Sx5rV8 UHmFzZL5XCLkMK5mzbBlUwU3vDqKNo68thV7kw1JCYfWDYVYjOoKLO8gp21Q3Tz5c1lDw/mos0yT foNlFgfjI80yVJfQCF5TE8dygkXysMW5np+uoKF+9ZWAMrVCo5g8GQbkUVBoBwFxAl3lC2+Ws32A Zk4Ecbq0W9/nqfwxf5aXxZW6yx+nH+2vpFL6I6mZbeSXcPQFpFHOxVWu9pttn0oAwZr2Iv3I1cC4 wCi7zpWL7/m5ccCNEIJlw8deHP7yKLiUnvfyan9K0mhfy0dyzY+Vw2UbaoBLf495GtKU/zFouYZW 7Zt8V0AoRXk3XEqZtBHflXcvwdqVL8IXzwB1Hpc/aRAvTvEcCnYAA94l3QHPCx4dNLudUAlqR1KI +86OlR6G/7ROeihBk5sM0tMmAp2avUKiFI5s6PmCo4H7BRubcYbxP9e6Tk7NnCDHczwFP1XzFlMl PEc7xzuN9p5o63wW9NEp6SfQyxo1OvdMQ0LPd7mH18IHaTrQyJfvBFzyBv9KQNZ8X+UngCrAzYFK nvkrLUTgeiWUKaVjxm9YK+n2y/jHzhNE7OSO6TylkQ7R1/7QHihLzUp4zqJXE40Ghqt5MSl3qy7d vdM8WF1hEEMjYDoQgEWSgQ9oSTAaCW/x4z8e8umV3y/RKaMycDNQm2f+OVWcQZc1d8rVqTP+Km2u /n7xLoMhyUQ+XAuPp+kGWIAgxU7KPVcFaVm3wWJ5vr13TVaGY+q0ZRbDuYRVw6bIPWfXszHV0ur0 T4HQRBgiS1wHc/zV50wwKAv8phCQPNoWsiSAumzb9LgnfxZu0o4cSQeyxvfcXw4DaFYBYwejnhLg hh/OukSTNIddr2MGfC3lX0P7/VNWiI1Scd+avNZ8a+Fmc4f4DYvKJ2hLS/Mzzesszp9DAAKA2KuD Z6ffPVB+iPhquoxiHQtQ4NEpev0E5/Jj/TTIicOjlDc+vMsfwvoRo+xraGUvACT39A3U9by1DglK 6R9Ym8dML+39qHlK3M1Mdc42N5kKXuBjcQYQ+sYUsoCRQzSNw8jEKdw32QD1/bWVZo0pwJHFG8Rn OnbmevOrX50J4Pnss4ccr7eFGZRiyiKL6Wl7lqs7JS0TZW8F7ubL+txmiKoCALNewHc+WK3nCW+G T/OY01IoD2cY7IM8SUNTSq4frKDJUyZ8J3B6hZNN7n2KiQ/6PvvjMTSe85z1rBmlladPMUC8VvoX WdHJJy59D1dPXbFSW1Y6NWLmyZLaB9zLWjFXgrRLhrIRyzVxUrLv1RXebBK0CeqKpz0IJDVAftXd S7B21UvwS+HfRkplbhtB2uwL1m2jt1TDod1HJV9Zro2uPl92ZZwpRE8ChipPpYu18x1LJ1DTcrCl E0v4duBluid88Cc+6dxagnSiR/xkvMtbOsEEKZTS0dgZ0NHJk1OsquoFdQ64DiCu6QqY4z5H/gDa 1MKVnZpqunhPByPos1Mva+pOAaADULR3xLNDVCuW9Bwgee6ZvjnzP7+AUvrdaPQcjSLvZKTNp5go AcNrOjXoGFKesynBjrzG018Z8YuZDa4HgjWcHSmPxGXAQl4CNO1CTV+/1mzdv5f1RWpfHBAdEY3l zzj8LwzLt/f5G988df+U912fF7s/SUVGcNYXmRpikM2AS76G2YAigInVf95HxuEe9U+3roRC+XNK 99QzpE8f27x2PM65FTYGlFupJMrP8tCVR6mWsi0+bb3graDMMBnA5VcgzP+Y4QC1U0MTSohh+Vke nnDgECegt25I3Z/5LDoXc1/KzxKkyqI9wgfQJu3SRgBMyMxw7nK03vMqU4SmnaqID8fTZ0OC5/Nu aw8LVeDxFHG8wuskwG0MuS+xTvIOBk6nAGO9jbXmdaYRJ7Ci75mirzPw3wTwTVJmAsYh2tMwU4+u yfNoLddTxvQImxbAP+kLXLs3oraRdsRNPhjU8vnhIKPJr9dUBp6KAMgbfCGfUjMEENwLDs0bkbVq YXWYYR1ViWTeactMT/NJht3HoeYJuzj/mJ2lK4CrkQ2mfJm2m5y7wfQvsqC/QH9I2z9o5ncBqbSh BTRps/h/zFFRzexNkpxubr/+XvOf/ef/SbPMxoL/+X/6H5vvf/97zdOVcqZnD3MdFoqbJKJFN0vK hZ/MJSv4WWfkSg/9/B3R76SgLCx8rHceju705Ra7TdXizXFaiTYdc84yMnPdn0tMPHVlmp2vKyvL xIOyZY6spimf4yOPzTvK6Qg3rt/EFtpqs/S1a813v/td+rjSdwnQ7G+8ukNf8x37sQnp+jO1dIHS Mcw9yTKLbQDqJptQfGd65k8tniDRPtLwgjXrfrJu7Qb4JZ/wZiUcJV9X3b0EaxeWoMV9kUtNvyDA Ze+pUwNJWNkudmcDnIKJ82OWTvX8d/qGhTbh3POnLxXedZt+oVSHkfJkvJDgT654hFaHUH9e++NL JeELufP/SrgTyHyVRxtxiZIBz1s/f+lwO8knQKZ9vGtfhItKEz8HMV2VqcHUGhRXrslf6+NFo7yF YOlI4gdD0vBXp0SjVaOzy05LBpqAMTob/QPauK+GS90xFuO2dJbdHa+ZkjVcABadnwOEtOiUQp97 Oy1eRwY1a77X02fX9tk5O8ClXBMI3hUiWYxUufVRF1EW35IfQZ1C4Cv42EGSAC6+nsMi/MZnHDqN SZJRBm5yhTzpYgzKH4e12CUz7fxrEykJhBeT9Me4XX76KsdO+hLkdcJxOWU0D2f/mB/L1QGZcS3x kkfrR5vJDOoMxiMAG3ewMn4YIzJgiCcuUyrUA6fZQoF4+suHBFMn2voo70WyeWuI4pKPek+Y1KuW HtLSKQpLSbYEFAUmhAN9A4KMkUSJYr7Mi34MVaGS9Wvko9blVAXeS1fJVX81xGNqMgrzAa0KnU+J 0HHo1Ln5QH5MQ23tMlBoHFmNiVygpkV5QZ9mRahc+CBnUNMhqEgDs8eApymYmAOMzKFxWd7bxH5Y D2OzGKsmvFP+0xibnaGu7GKZv8dap5sYed1hYf4c51x+dQl7aXOTHA6P5sxBnoQUnVO+bi6QM6ob ZUvK8M8l9VN20o6VO3WOTyhkXvzGaCeHTKUqEf/7J5plM8nPYq4AvgRQxoBS6zWgMOCI68zeRLMx wlozgOdTDOLeGcEI79AU5khGmu/tbzd/wlmn786+0rxKO+n1WNd5sIVtNEENgI4vmjE0bROHAFWA JCdFcfQVV8z29NbWm7Hrc83Y/Fjzzjfeam79jW82v/Hea83/8r//4+a//9/+SfPznz9sRtBGTpIv p8CL0W/ASzWfk3zazv3Ig3c7hDafXjJLYT7JlVOOGvMe95SJ115rfv7BB9RDco//K7duA7hWAGw7 lI2nnRSt2Y3rt2jnaA7Rmo2hFZydXmxGltDwQXON6dyVp2vNh0Mfc0rMbvPmm19lk8RU6tWxVrUt H+VNn+R3ySibKybYZLGBVvGYDV75GIRH1+LduH6jWaF+aRj3wCkCmCc76TuzCQF5mT/LTK1cPmyR SRkbyL9fC6Q3gbmVq+5egrUXLsG0gBemckpgkN7gsyEH/aipL+jOUEgH/vlE5aAbx+A+hzMe7Nr8 X8mUsIN89z+XMBel2R++K4eajgNTnzuJUqj7N3dtYgEdJ2GkmO67T8IZnztEE6f7nEGX7gcmBt8Z rPpl4OjES0dKJ2oHUwCWnVd59rzILPQGmPkugI3OrS7I9XxPwV45FowvdMII+DR3EhCIsUhPb8i6 FABiDBLz3jTrGj01EZUHNXcZyQrDyX+mknmOtscOnyDyWvFK1suRLkNgwo+xFmf25vVm7eNPssj7 mPQC6FIXBA/SEFAwgNCBWlb0/WhDGNzrs++i0ShhLaby4zn3ylieOnXLh0ucRVyLud7napmFsgGk wzO88L8AORhU85ZBjbApat7p5KPQMp4xcHq0rnJlOF2RG755UfKjfw3nvQNPQAa+J9kiQFoUiSMd g3UcxFthCFIclMskZwnX/dtSkTJhCtS0LCyXFD+BK1fGq/fy5xmeTC5CAm0cGTFO1loSUb3aPmDD MhVtFjt7lCtAjE+J2HGzfKcYTDVMqwxX2dxyXdbZKCBwmMVg9Q2A1z6gYYuBe5w6OzxXbJldw5ba BLQ0Y+E0rHk8BkBacqlH0DEfWZOJLIYtM4TOgQks3C/aag8eHwWciX5jPJgcjBZFDjFLXUx9V8bQ 8Cf9LLIv2eJJf3xph9k5bX3wHWcWb3KMXW+TqVs+WPYAnp8y1Xtfy/ugw9cnZptfYa2ac6NLiNAj rVzruUBBe3bxGuvetlj/1RO8AJAEYTtorWYWsO229RSgstOMLEw17771ZvPGf/ofc+TUfPNf/aP/ oXnI+rXRve3w6GYKp0OP1XLKO2UkCFYT5nNcLqTtA/LUuftUbdrONut08fKjbobF/pvYe1vn7E2n EC37119/I0Zol5+oTaMsOSpsgY0evZ29aLncYHREni1cj6rbZFrzIdO2S2jb11bXMpXu1Gr6OUEX RDyFxnKa96B4NKj7xN/iPFPrvx+ShulhNy/x7av0t3Hi5MFdxBRK/IapV56L7OkO9lHFERbePY5s p50mbV9cycuVtLN2JSX9kum/tBIo04JlgDgvk7WzVO1v5+Szv0wD0Mn0uzJw7vtFaO9kx57wDuRq 4PiyF9ABxALi6JjUrvmVG9MldEpZO8cgkKkFAFNAHf6aTnCzgcZv1drtql0QCDJV61SGWrsAM2nS OVaNYr7M5UH/gEkXB8McHbPmORwoo9VjwJi8Ree88rjsDGV6ygHAbGTgYwAh++XJK32pRyrZ/WYq jht345GUY36/41k69ScdwxlMv8tcDWP48isDrbyrvdpVtVYpMQaoW5KHuoNQ/Y2QtPy4J+8abM0/ wpV8EegCV3kwSPe+PjtIObC49kpuBEGKOQAO/2gBFRZ+NR++K1DZ8hF0yFGpO5nGs7ykKy2IGT2D YchQHr7krf6mFcLxyovUvSO0Yy40V4tqkGjaIOI6RyafmiNAuqA72lvqk6kEDMonFcCnMdQ/ao7m oTHF9Ql19gb+h2iOR7DKu0jbmAHkuJlhmhmr0WMkTv3kmEs2Q2hWxnSL3JNjwCHclzKK8ElMVaRp Ui5+GrjVQjMPgoJDjMwGBoDu8tlAXZ5QNghA3vPjnc9+PFgGSlLZQhK6BNLRTpRzmicC28W0xjpt y6nza0cTWR/60Viv+fajezH34S7Xvc1VtM63mkkAqbLYoszUgqoJ3EIV9QFLM+6vPm7uoZFe480B dXFvn3Vr2Gsb2llvdnoc6TZyDWB7DKidaf7Df+8fNLdvvt78F//wHzb3PvwpaVJ+qgyRg1wXgCaT yosyIwMCt+rsg5xCtD27vvbundeaJ+7mpn9w2nIHgDSOdtP69vjx40wzvnrzFuBsLmcY20c4FbrE GcHrTFV7TN5TwOX8/BSnwtC/YMevmg3aZkrV9Z9DgMYhgN8oZezmldRwr4D2IxYy7vaQCSBOLl0n N4Rm1p2k7va0X8qaUurgBMa4/SjVKPAIQMw8mEG1gGrPYmaGMso6PuQ9v3AN8MlGFED0VXeDI8VV z89L/v8KSUAQY8fz5+8EVJ/PhTwO8tn163/nAIEWgY6t6wwT0OZiMNywi3NwNff6+j7TAAFVDEBq 1vyyZlARsLnOo9iiA8AB1nb4BcjRSbvOzoPhfS5gTzDnebCEYbCsILGkQTp0iA4Nowy02qByIDyC nvMg1+7cbrZ/9mEGOosn+cuNgMc0cZIAAEAASURBVMCBkMGDnyBJ4OB9ASjCDLvxFqBGEmWcrOJN Pomjk2TkzvUiV+OehlHGyJCf+hnf568DdLRoeJA/B+hK2nCZliRwsStW3qUcE58/l7jwYV4Nx0Md /+OPl/4OqgFpBmnvGe8DYuUl4IoIueevvBiv5Ei21fqYG/mVkoO3gES5ex+ogz9Xnl3krgyrPLKY PgwKK0r8nImZew4SZ8CMxoa6pdZlH03HJhoRTiVClkyNkp5lKn/aeAMqZYf2FJmYJs1rDKoLAIVl eFslXevRMDb+bjJPOgYam4ZPtWjyppDMiZsGMu2Ij4Q1tOuUdpnOL3IzP8orIIq4ysw8ScbsuHN1 nQ+aNTQ+11j4PgnYmGB9VTIvTXiJVopwRf5FcxhTNKYLNdOw1A0beZPeLpVC7fY0JzPsTo82HwNf f8LU38PDneZd1pt9jZ2r19Baab9R48AyIzTeRnbrlMVPt9ebP8Wo9CPWt23B/A7Aci/av8Omt/qk 2V75rPmMo9/eev0ubRD4uY3GHMXUu9/41ebf/IN/t/mv/9GTZp/F+1lXmnZOAuTHjNePK7kvuzq9 8xXlQjpquraYut0AEGmWZJw8CJDIXmT5rV//daZbf56pTqccle+YhmkBSh9/9GF2ewoM/XDZYZfv zt5azjHNmj7yYpntYT9vgV2wTvOOuOuCna8sQWMtHOZKiGt/8PTpY+olII1+yPIQaI17NCD/BGa1 z3FaVMAng5MAsxkMIts/Wb+nAJeL1683b79ys7kJsHz11dtM4d5qZtkx7GYHTRZdddc/Ilz13PyC +bfSXOYyMF0W6M/pfZe3em+WHDS6WaONvbDLUNbSsdGd6wa9v0DC55VJzZtpnnnfzeglTFU6Z2jY +5O3msfu+xpnkHQN49Uw3XDVr8bJ+/rgNXJyoCgdrV4eJVTEW6QbXnwhAvIFher6nTZyKwfCWt78 8SfcEojZ4QnG1LIJ1GKXiuceX7pOq+622+/dIh8wR3jDDbHNfkjQR8e8zc91dGN0yOOjk83jlc3m gHUrrjFSAzgOiHM9i4CnnDFZWSVfLU/yXTjGI3fl4lMcL82tz+bDsCV8eV3/mreuK4vHi4+yzbAr ACCYQWNbCyawoQrA4MrP5ch7LoQyHQYygYfTfsYZFkwwQDnVFB78M+AIVoh7ad95ta3p4bXkpfwV oEI0ZaYpFrU7oQ6DiUc05RR7cKSadAspBkWhRHHSLdXTWN4X8CcAqTIrEIz0GdxNk4wkrDFMQ41P QByVSZBnxD20N6B/1lkRVnTtM+/cFek0uEdJQRAzGsoFecGIBmTHWaguUJtFy+q5nJq1WGJK8CMA zlY0LIBCBukeQEos4/orF6A5lRrAlvTVGuMNq1WzaTCBqVU894A+F8MLXmcEBcksuefZzSLbFO42 030/31huPmFz4TyL52+xEzXnfJK2oFLl6hA0q5xEEGFHluBD/E5lQHtDuiSsTbtDdrJO7SEvjN9+ NL3X/NG9D5qlW3cwK3K9Gdnaa35z+kYzMUV+PLZJMAXBTXj6BBMlP2At2A+3Vpr7yFV5B+SQx6Qv IuPIq+V7HzX/x//5R2wGYUfo1m6zz7TjP//2Hzc/+PBnzbIAavEOU6GULe2w7FCFR/gstQbhoO22 nEKTdKt232UUArgFjtFaXtZ8L+vlFuabO3fvNk+Xl9PuBUGTTGm6gN/jncYASz7bvpzidNpRW2qj rEl0ivyAxrENaFPzJogbHUezjqbN8IsAq034HCbs6Bj6dPK7z8dg+iEStx+SB/n1aEBCpo8UmI+h jVOz5lTnMDtqb9++27zJUXdvvPEGYGymuc66tjnoa6tt3LIn284i9Pj5AbrGCRdO61519xKsXfUS tH7TCJ/VnRvWVvLsJJ4tqS+b3rOlmlB2AAE8yMX753IEt6M7V04todCUrOPcly64kkhm5bqMf242 zuEgYckD/FV3OrxXH66MjuMs8nZqE0FZkSKvkj/BHAOiAA7QFvMlADjtzjlt6kYIPqWbIQaQDQai DdbP7DmNwULkadbc3MGO1nf/6I+axS2OhWGU9Wgiv6QdbAVHmnNwb507+9SoqD1xoM5gjB/DSimD th7JS83OoCgue+7kOKUVWZDfQo8nBjOPp99TBi0xBwd3Fvso+PC4ogA2/IXJ1g95PXXeD3Jy+tY7 gZQhcuWPUCDP+Jm/UpsoA+nWtLkv73yLDIhQQKLpl3iCLtduCW4EJ3GEM55lWbSWPPNK6gGpvuPn VFep60oFmiVpky8JGgP5OJRmMwvKj3FkIM6zLhwBgpy8UmM3QZ48h/MIVD7N8xJgYIppT7UqUwy0 vptlTdoCa9OOjnsxgUMqGN/lsHc/ALhPXQQVOY1mGqmLMGW2lIsy4xV1ifCArIBJXupftIrQAGSY p/rOXakar90EBH6yvUx80l7/rHkDDdi7r9xtXmEN2ARg0A0Tbi4REJuaBqf3yZ+0BXyHaJU4JavZ 4kPFKeAD8rPKTtVpoP19NFJ/uP5J83gCELex1bw1utCMcAD8g6F1+ACwoI3yCKzP0LD9azYa/JSl CCvkcxtwso+MSAKgieaKNN0h6g5rF9vvsuj+X/6zf9F85Y1vNNdu3EXztc8h8ezY3B1u5q7fbW6/ +5vN8ve+3Xz8ww3aO3TkXPbT+Es+rHDKQ1n6TsCmUVnXg7k5ZOnaEksXVmPnbZq1aAmHDD+592k+ 4hYWme5Ee7dHXifQeGnbzI8Vpz+9CpK0QbkISP3gxz8lK7RxdnlGm6e86BPW6Ud6CG/h2kJOfDgG xOfDA75G2YXKVx8ytsYCypDtNCBs8dp1Dmxfam7dfAUer/HMD62ZINFfpnKJYT78wPz03gN4cs3u Ydb5baA13ELuPQCbswpX3b0Ea1e9BF/yfyUlkEGo5bwMlv3ZaIfcfs/OUwb8zvP5t3bWn+8Y6lpA Vzv50lmaNn0oOyMZPFgXwvczHbAdfaHn1UHV96N0jJ4asefXtO9VP/AVO/r2O3yd07n/i+9kimWH HW6Z2uALWu1FRg3CCzCG2SXo7sFo3kjXcYYUMp3mQKO2RIayPotbx1IuIZHr52fxc98IuDKoSJe7 EfIxzqC5x/Moi7QFIK5/EYSYmuucHJj4to8GZjQAogAceXgmR0BFpJRTftxL3V9cgII0S7gUQvvK 8EYmCO8LUPOV3q4trHEiOwjiFZe0eBao1TTNb0AfIYqWTQ6kwZU0PM1CLRa1I7Jxk0g1Kp1tlwAu aQngNNehok2F7iSymUPzIZicJ/5NpDVF/RnmFIFxGFMj6Tmd8+wMHO+tNQfYH3O632n0DerFNu9n kH82nCh3QJ4LxOVOWQgs3Tyg9wgZnJigTnJPwcAvzwCCaEnjpQbMZ+JAYRzas2h13lzEJAYaNtfd 3cJchB8rw6C50IWYLSF5F6CS0B514gDau/yeYnJklQ+RZebxPK9zlzq/P8GZoRx59fBgs7lPijMY 7x23kLgfQwvF3uish5wi7BzatzX4+REfOZ+w1o0tkjSXMm0sUDOjfrBkZ2fAKq0ADdiP//m3m/+S g9j/zn/wHzVvfv2d5rd+7280t15/pRniaK2VHfL46IPm4QfK3XIhL/BtGaemeckPQXGFjbyjyWUa dBtgOcbaM4GQ9tDWAZ2CXjVmTx49zlTnq6++CjB3nSsmVChvd43OL8yR3lDz2cOHTDOOA5J6zeo6 U6ikEZBGOu7fGJ+cbjYAawLJIWzrOQV8TJl6jOAI75xKn2OjwvUbt2Kr7fadVzN9eZ0pTU2HFKb5 LmSThZrTDQ+23+U01UfLAYvatHMzQ9axcb9P+TgD4Lo364ybEOyv6vpbCF5Z9xKsXdmie8n4VZVA BT1d/s8DbN33g/cOvi/qAsBCxN6cbpEB44Q3OricdZBXwhoBQEm0fME7iLJ+hvnCERaDTzHCZWE3 QQ6xhTXNFMjf+gd/v7n3Z3xp0/mrNclAiKFPB90YH6ZDZzIGKjoGYSgaxnSSEgOWKVdwYedbAZsD j87BoQTOY/5cJstC2zT4x+Am0OBDP4AGxRH5BkCYN15oEFZNjRoVw6tNGwbpKIrCp/f6wkjL0ykn Z+8GgwRs1GBFEMinpFWkXl9aPtybYf67/kxaAlwSzx9vlZ+8RS7c6+fPMAnK1XxIy3R0ylSApTNN 744D2Chh4wGcHOSTfzyc7gIS4IGGzTqjxpRIHtZ+nV19w2iS5gEs10BxGskVSA0x/1emNgVufAAI sNBQjTutxvstQAnW15hSp4x5Hg8it7wZ9OHPNZbuBM2h8JiKcMp6hPoh2BRQ83gCQNWKmgmPgxqF j7Ec80B9hvep6evRtMxjE2yN6cktpvhz1inhrTfuaxCEsYozAM61oT3Sdffqg+3N5gkgYBVN8h6A QxB3xJTdp8fraJwmmzcmX21uA0iuoRXa2Vptemw33SPf963lnBjRYOZjF+0c+mw2C6ABgs3YdYSe 0g2ARluYKXbak7XKsplgR+jP/r9/2bz/jW+Wo7o4Z/SD97/f3LzxWvPBx0+arc8+REt51Ny+cwcN 2UrWmAVUpzZYqchcW9FSVykT19nNskZtBw3nxvomgIvNQZTFDqBLWd65fbt5/OgRWrHtLH2YnZ0F rHFYPc+baKxWmVrU2Tbc+JBpT6a3p2j3Tj1abuZA7aRLI/y5u/Xmq4KyG80CU66LgsSFG80iBoBn 0G46Da6GTmC2CSh7vHKP3aEAY9IUgKnl32KatdirLLve3SDhNK3LM9J3MT2vxk2/fFBan/j5/qq7 l2DtghJ0MOo6O6t+5zO18sQNPvt24H3tRds4Np7nc+ek0U0CYoOD1cnATtTSFZcUkx/8jN4lYQqD XOl3kUtDoVHEDeSxePLuEiKXvC6NscPEYD7rq+p/AjzqC699o6Meg6n6rDSQVEY0www6BzfC8TuV m/EGaQ3GK8/nhRrktebhfArP6Hsmr/3xKvhKHW0z4gBhvsxeOVIHabTlmUEdEj763nqVweaELJR4 N8zibU2PzNExv/23/2bzo3/8fzdzrFIfQwuxR48jqPO8Q51daFrZSZ2BQBJQmmVdXgYxwlVwYTxd KQODw0jHnZA68TOHZtBwXrsO4IG350TWOi9onGDkcMDx/EvX3Ak2W7ZCJTyhZcjAKk14CGSQl5Nk 9MFfxvmfBfEtncqzsvCfcmd4yeJ9tUE6QWq5yyN/7JEKoPXeeJaBvMi8ycpHoeeDfuEq6ftsHi07 vMt9nhOTu5LmkHkmpuuoXJ/lhgLzkNIQSAEM9I95BQDtEPJxClTN1RyDpFN5M9BQ+6hso6oivps3 pDENXGElVOi6YcEpxXUpZh0caRO2BwAE84UHp9xdg6SMpgRqACXXPaoxEyy4VjKgTT/XNcGTa6Uw 09ask/4YiG2I+jeCOskld2rrjpjC+5RdrivstLR8zYvlYzmbdo/BfQrA6vo6zzNdBSxuwP8G+dqG xjEba3pMVy6zON+D5q8rIzRIvaPdgLqtMYAa06BPAD8PjnezMH8DQ7LbgI7HAJJDpoJ34P8Qu2hT VjR4t6TAaikXi9RS8BXH3TdvvXm7+YO/9m6zzkL5feT1AbJevDbT3MU8yOO9uWb1STmLcxjw6G7v YsICAaYSQ5u8WVf90PCkhQCf7Q00ZzNMIzJNyOHyNziF4AhZ7zKluIvWM7UH2XyCKR5rnssfnKIU uGuWxfbn8XXuBHepg3homCnSuaWFZg5wt3TjBov9bzbfePc9QCufP8j/BhsAJviY8wOumB86bB49 fkJ6D3jusbKCaUtk5iaGHcrI8hWQKQ+SI52Srv42SPlx/awbqcyr2v591tJqBiU8owHNelzK6qq7 l6Y7LixBq0jH2dD7XKpQx2fw2VddGue970R/ptvnp+E0ReGiy0up/OeBgmRzIK/5gr+Av1Cm8RQ3 EFlPO2v+/aLdefnpT3OQh4FnewT4rDnxpp+mHnQEbTjf1Q6kdLiGP4ldkh5IQs9BWVRAVCIMpll9 T6/nkDx9yZ0gwIH7QteW12mo9q71pzssLnn11u6vXOvFxegnLknWMPgzzTP5t36rGfve+830zx/w 2cw0CguDHLKdTuQBkEQnijxr1TDpSK8VYeHolEPT8qmWSeQPva4blKUUC+zplkutj4VfDftWJ1hz fdpJaAYEBwafpW1Mv9pbMSFr/cgPlunbtwGWik3pGM97hw/jOH76812AFWm7C5P5OEQBJV+2rmrQ TFNKgh85q1o9wU+e2yhaQzNkQLfvHNQSqeTTPZ6+908JV67e11RjuoInAZnnv6rpqm+logEKVi4W DMYbaU6Q7ixyGgV8eAi7U6TboCYBm+DTqUst7Zu/KfI7NcS6K9dmOcYClDbRXO0DEkYZyMEBpepa rLAvaBlB8zMGEPGII0W1B4jIcVdOU0J8h0hbmL5YXV9BQ8ORTmjOFgFY2n+z/9vZ3G7mmHaTL9eI 9cjBRwzoa2pm4GkEcDfqeZ4gjn0AYY90RinjbYDdFgZ6N9HWCa6k1wM8HcD7FmBiBfkuUc+XSG+c UxfWMBx7iNpvGQCxCj8rgDdBneXxlN2dgsBdZBroAKg1i/LkFKaZtgzSNuhD1D6LWAWYM08eNT/6 7/7bZuhrbzYPkemTBw9y4sHaylOO8NoCCKOVBHztAbIm4PmYjQ9jw5NoJN0wVMCMk+iHrC21xGZZ Z6ahW8O7K1TwplHanGQCf05vjgDEPBNUHDTCGrFh1xqSX3kd54NsjLKaZarymlOWmNSYnl3M+rXZ mdlmBu2i2rBZbKjdv38/i/xfvX0Hup8122jO1JZpM1JgmU0I5Ny0BX4n0/pwmvZG/bG9RbuKn+Da sne6V3Mx7ijWJJG8jfqhwb39QjZPUQe815bcVXcvNWtXvQSfhX96ALvbPlc9eOeg0XWOW4N4o/v+ 5X2/BOwM/OnK1S73IleFf1GYv4jvBAb9TnDSdYNAaeL6zebN3/2d5qP7/2uzlDVCDHgQcTeYdu8F f10KkV8ry0p3kGaVte9rZ17Dnnft0u++r7ybKweDrpNuTcerxjhDJ7wzYNBIwjvhBvkrdAjtO+uG V9KosvPqsGx8tUja9nIgdbbu5JxL38lXQgI4GKDLGZvWMdssPMGD0Mz2671OLgv9koY8O/0I+4AW Bz3lnZwknPyl/UM/FAwgWsJTvu0HBI+Rs/HwEGzrFJkDpqYWNBMjgNpDa+NGE/M+iubKqcfs/gXs qNkxvku9tX3WY7BWK+bsgsBQ8LaDJsvF5wFxcOSic88QzS5CmBK89uDnQKDDWjjlo+ZP3YuGcrX/ 5YAvEBhiSnZuXzkjpRnWdEF3AuS2x8KwP1v5BPtm8MK02puzSxirZZsAWqFxMvUJ2rZHfFi4m3Ed cOO0qGvWBIS7gB8PFd87YGoOFLPPmqtN0r8PnSeHxRyF4HCbvLCSKmBXWVmS2jYsWkDLQAHnP29K iViEkAJ08MebRCR/GPSdh9773/5/mkc/WWiWAUkznhv6+ClgEA0Ua7j2t7BHBijzMPhDeFRz5YYZ 68ocB6ovrwPoUnbWXYAt6+4EYdo5E1qPT3G0FEBSvoaZ0nXn6hBy1wae9sum2W25yM7Ra6xtc0OB 2rFJpjYnmDq1fWgLbc/8wcMy694eYTx3k2ljeRKYeXbop/c+SThrmjnOxhhkmytScK1cXXYQLTQg zLK1HgrE5Pu43ezkx4p+0rZuemi89zvIwTwvLCxGu6idtnHMhbzyyq0izyv89yVYu8KF96yspzMe DGy/qx9/cu2893nQr/P65e2ABLqDenqKduDsD3b1JZohpR1DzFue+zOZjrPrtUuHf+O3f6P5+Dvf a7a//1N2CfKFDOrgO5iB0UqolqbfdcGPsq3yraF8rmECIqTTcYPhO6+e67ZoEWpaXE+KsL0ZSHeQ eLhKHskmV9uhAK2ScUDNHKYDFgBAbYtGgh2UCpArYC3aNYiZPlgIWi2wIryTt9LVJ/QBNzrTEIh5 Zq2GfWtZKXfvw0NLK4e8w0Ol4aDgvdb3CVp44a8KUEFhjORSbnlJOHcXqv1aQ9PE8A5/pAK9YTUc 5hs+3PFbpi4BMhAVj+yAFvZAZQJMFFvNGsDB9WBOq7pW7BCgFX6tA9wfo7VzMAdzBDxbd0bR5uUQ czPEsweHx4Yg2pufssNxCC3aEAP5Khok14+t88GwDli7x8LzTVRWynuUjK1wmvru1nqz3NuCD3eO Uk97aNt4f4x2Sd1YgCXP5tbdzQIZ1XwaxcVQDZLgkfzCHum6ZsobeUVm0PMg9IBLPIVFrvVz84xH mKlvTvlxTflCJwQhsYUV4Q/W7jOdN9R8urzebGaZwRQgmWneafhafUpbopyQjWu+BKpZtycB/Ld2 tjn1gOOemMbM8jj5sPx4PeTOTsKMcOTT1NJsgNgCa8s0baJWbIZ1beMAM49yElTbJoq5HzRxbJR4 sgpIJP+mfUD5OeWoZkw5ROMF/+/9yq829x8+gC/Wm1HQyslpS7V+0kxYnkMbcKcE9XPq2w0obhbY xLiuO0BdD/n06XLu5W/t6aMY4h1jycWQmz7IK9kJ//YDTpO6sck6etXdS7D2JZeglaw66sovxPWn 8WKJDMbOc7Jwmo8AkIGclC6p63lKSf4yYJ56dQN+afddOUi0O4i/aCKl7EoGuunEnz/drJ3k10RT /t239pf9z3Rl6Ywqj18EXORrsxI452rp9afaH6g/B/3vuk/dcjafXVl0w33ePcYBmoOF2earf/D7 zc8+fthMrG0gEIYqFyTZreb/53PaJ9s2kct4OPveXJzW5zPy5tWgX7cuSe+EZipAeY7/52Xc3NV2 0IZR5ubUYUPr+prp3Gfwc+G8Bmx9K9ZyEA+7psXP8A7y/ldq4Y2rlEaIUOhaq9TM6esffjjhgZqa ssaeAdS6mzzwUtnDo0AixnDxCA/8rRo31/KFDTEgoML3yjJXtS/gFV8NM224w0C9ysA6grZNSAhx 8iJ/ACLAl9PLnkWqgVqVdxpSLkdXycoxpix2m5kD7HZhsuLgqAzSh/LL+iw1LfItsAgARRDyIGAZ g4lRXkwBPDwrc4Twwwzs26wb+1er95onrFdzenOPNVPb8LkNYCAV1rFBhCnLFYy5os5retTLHrbX 9pWJ2khEKEAW8MmvZ6likIKTFtA2kUcCYd4FPonnrlFl5mHuOne/kiV+TsMVGVHKKT9DKDPD6/zr mkDBnXITDGazD/e+AwNhRLiAyilmMW/Ms9if2vN4A+C2od4Q6ZH+MPYNm0kAJhXrm9/8ZvPee7/S /PCHP2y+9/3vQYNyAZyOsMFhDI2kWrERpntfuXm7uYnWaeb6bd6x7o2p4PBhnSFOD/C3tQEAAoy5 iSCmfChnr5Zv8mj6yN2fBSJY7gGW1ZS5vlCju065clxF1qPVtuQaOIHfLqAs9Qm6muEYQ6Pph8HG 5jqbIOaQBQAfO2+C+skJZCgYRaOXHbQtX0fwuQDAtI5sanWXqxpAP3ycAnVK9qq7l2DtF1iC1uW2 Pf7CUhkcEM5LyC/RM44GYEdw+q4wq5/u1N+nZ89IbYg2mpNBQRK/BPcssriMjcK/Ajuff9/4pVxd zW9NOwOKHXXXGekS97yysrN/EefgaAd5kTPMizo3IOwweMy985Vm+t23m60//R5TY9C1Yyf5F81H 5HYJm4Ova1mZt1p+58m/+uUKzw4aiVMul/6t8RPQOgMj1gz9rUNDruFCMyNZgZvTZ3s0PHU0gjgB SoE6RkX7QnynBbOrMkQd2tHgSMvRjWtZb0Y4mJWyNPRTcyN908p6RuObIWjqFzkQv0xJcaXzCoAg QIEMRmzbBFdd/ooeoaE5BpRfAWvuprVk5Q4vFV5gIjh14CRfLvDXcxee3VmKbif9zQY5X3bBPYQ2 RpgSZcpLO24ad3bgFzR5Bqa5UY5qt6JZY4pwlEF7DFQzvosWD/ruBtxzsT1alQ96TBdCZx/ZHaK5 4dhwgAdp54MB4AG4GMGwLeoXaBMOPlldKef5C1KJP2wk3XKCQwHbgkf2HhIS8x6EsryCk6kvHqHm hoU48qs0UvWLB3+lr5aZsiesVCwvtWKCZAGR5TG3yyYHQOS16bnmNyewO3b9jWb9xlLzJ+zWXOIY LefHyxo6jmAib24yeMr+gB3u/+bf+febifkbzcOPf4aWyd2WPY6JWkJbhU6RDRTf/LVfB0DBJVPG yhjUDReUCfLyyKlJ/Dyl5ACw4xTrNkDInMinoKy0JcoCkHcAKC51njwBwjY4W1Sw9gHA7e/+3b/H ktXN5g//6R8C3LbJuhKDdQC2ANF4ahtHAcFpEZSVZSQd1xKajuY5xtGSWubaosvGEIWtnOHviPdu jLDOKTtpWg+M+1KzhlBeur/4ErBjO+Os0bi2302HW5/TCedt+4ewdaDqel90n266TcNwaZpnCPdT sFF1XWn4XZ+rcV93+lVuz+bDgeA0r4P5rvEuvF4iywvjti/LUHpBSMu9w+cFIS945QDFOqPpieaN f/v3mu+ws2yWtTajTEcdjLUamAti++oLyadDM6I6qeidF+2teRyoemcDDYR5Hp5Mv/KQ+wApBiqA xxiAZWIcbYTmTwgXq/gCCX8wxSWDuRoCV/i5y9Z7R315yJmLnbw5OPqh5YCbNic6sAzxdOAPJwbg reOcdVOeBAfeeNEGVrRxxMuqQvyN4SBqWEFTzGXIH4NipsDEXwyMAqwxBk07loA11q1xA4gogBTd D5ozbK+RuIOzJx+w6ol8sI4KWawLUKG7how21OQwdSmYMazAVnMd9mca2h1nQPc5PCEoD2g3nSGU KHI6iT2wVycXmnsAFE68bCZZs3ZLo667BUQ9gvI4fM4fjjTXWbM2jTbuCWvP7h9tY0QXYAMt5Zyd htATmGm2Zow48jwMYFBz6TTyPvdmNFPIlg+uSMs7OW6BX+70K0K1XxUKCgTtFZTDSWxf+p587wDs NZNzk6m/KbRPH92731x/7TZAZqGZnpto1tBC7d9/0Lz51bebr7/zLsdfsch/BmO/XH/39/82R1J9 Ey3WXvPTn76PlsmzO9nwwAkjmi5Z4PzM97711zGTwWQuMt/WmGx+G/Hb4aSEnuvB0I45zSoQKmCI fKuxo85dZy0baAn5lCnvY8Bgb4f1Yi7sR7v405/8KABwl6nybXaeOjWptkt7bgHO1BmnPE1fIGi8 0QlM6LBeb5QNHsOCbfg/5iQH5eP5pTPIQiCn/TU1gP40PSLo3BsvRnB7bFqZwdCv6Vx193I36FUv wRfgn37AviDOBtB9br2/+AWCfQMaxM+Cln7ytZuqvqedXfW5Gte+fMPyZfk2V904hu8+n5/rWmLn v30W38vT6OfrWWgOhslUH9qMfQDJxNc4hudb7zXb/9cfowlx6oiBzi/pdnAbjFufn4XPGvbcK/Lk /4k7j955ficRvGl5VOpf1Lk+pwAph28oMTA7m6YuwzVEM1wzeBPIo4fUHwlUBC8EBTwU8BSNA0O7 /u6gkyenMr3uAFcCwngAxyR+gB+0PUBbBZIwLs488RNs1B3MvhEOJX2BCqFNx6DSPQI4sIe3xJcp /dBq7TBgOgXmhgl36ElHrRlKqWjonOqdEI0wIHv8lCvt1PQJ9tTEqS8THG2TkEZlNU68K88ARwFj tILQRvdETNe/ITuRLI5bE8lUnZRN27V1M2iBxudnmtemF5uhHhLnsPBrzBFOzLDbEzms7wABAQlq sobRHu05nemcI7yo5YpDNmQ6edDMyAR8LQHqFnh/pNV812kJXsho1binLGBKG2N+uBVK1nMpO81Z gJtvlJRATTmf/FPe5gH/TJUCSqfMO2Bqo/cpZTMBQFtq/hprwWa/8vVm4fp88/77P2o2OL7qq6/f bf6df+v3myl2ZxaIrKYReR1g0HftaY6D+uCDnwQYbQF4HrA78ynrzlbYgGA+1Jxtbm6gbdvOJoQD wLeGZz2MXTmYR82cuBZMbdX2FuvhAFYPemjRfEeeXVvm8Vqou8gfOSEjP/7Bd1NXPUnggA81j8tT C+ZHhR8RGsdVO+f6tBxlRx2ZxtSJ4Yfgf0TtGuVtXfacT+Na/XLmJx891hMYoh5TBykXp1cnh1nj RgpOh3rqwlV3L6dBX6AEbVJtk+5Q6frY5C5zhhmMc/pc0jh9voza877vH6RIzc7ly0jO3h1CXVKl az3l0O/Ni92gbC4O/UXeni/fluvzktfP36DrCi3xOjkfoHNe9C45y6R2/F3/7v3JVFbX80u+768b X5A4nfwUnSvf5M0mX8pf+b3faX7yvZ83x58+5GuZwZJO3XpRpRXtBc+2LKriuaL+Ipz0yZyyGsxb f009m0L4Oevd51OL2bAlP8WnpF1zWPNKGF7o668M6iWkg5CDdEAaL73Pj3BOKwuknPp0IMyP+iIQ 854VPwW8SES6/NPMgVL2twPOUgeUNUaGqYDHdBKDKw3TFXQODvoVwEgp8ZB4aKK4SWh5j5YMjYgJ x/5Whkj4I4pBzQfqDlKHJrceLSYY8qdGymk77bTpzINp7zP4HmgCBF4Cn8hvGOG9/QZ6We7MibJ2 SOY9YaQ5xsDvmaTWrU3Ojxpnuu/ro/Ps9uS4J0AF+iQOAeeAb5DrFuvX1gETO2jT1ADvMDXaKyjp hEcz7j+PRiunVsIKefK0gH3CC/IE3UbTWbfMhzbNuJRfeZO/etS+z3CGN5jtQP5P66Y5I13oT5PV V9nVeA2zJNeGJpob7Jp9B43TW++81RwtTjdba4+bWewYjju1y0kLexsAL+ynbaIV22HRfQ+zHp99 9qD58MMPArA0gbLBmrc1pion0EDe//R+0nWt2R7Gbw8wOwL2SZ6cMp1iR6jaV7VhGp2d4PQETa24 xwJ0xJml2rsreXEtWd044e7NIyqBO4R3AFgatJW+Rnj3AIsgMGizE5d1akfUhTH6CGuKAhqlXgje Ig/WIeqtzMfRlLlzVUPAo+xcHR5n6hN/pequUDecaD7EkxU09KtW7eVxU23V+6t7sZHZzKqjy7AH 7nNtC+7z6z70tWZeGL5Dgw7Evu7E8fpZNDUn4S+4qZ1CpVfSKYlVvxr9jPbjTLbOeNB3S0uZlBwV HUChaGi/lqvz1sOf+1xY6WReQpe4y0Ic8pXadaWTP01Dw5kxg3CSdkJ0o9C/nJOKvOXHxbjkXRmG 5TyfkmDsyIB46tN/dw71/gA8jZzHQzcURDToepFTu9F1tT5Uv1OpVJ+zV4FJn+urrJaxwIKUMIJ7 zOByfPvVZvp3v9U8/idrzfzqOlHVsMCnHTxxHd+GQQt2vPuMFi4wH8naotNUBvkUuFzolMVgEP2M 1JaNxw91XQBGx8P4F8lDfjVHUl3WkSnf0KcN8yI736BTig6fAYLuoowjjFnKTsrIM7GLJ/Uz0dq4 pQcSzJW0XaqdIqlFS3x3dQqchBC7LC63HTpVVAGbpAIaAEhy4M5Hnw9BIIFEALEDaUgL8kzHhIeI nefkh7DhkjxYjkPsoDSs9Ap9S9rdl2rmynovNYmb2Nm7gejnaBSHlPMY8WPKBLB1xLuYMyEv9hXW DY+TUhNzaN0IdDItpkeh5Ts3MKini6bOqUPsnsV2HR8MPUDGNsdSfKZWBgv87kZ1faCGaHfZ+SmY 1ETKITI2PXUxyWtAF1NzaNHczLDGjtEVeNoGgNiGzJcy3SduLOezlks7fSe7dhGUso+MbQ/kQ9no lE3tDKLhy3ORZQEgRefmBO82MtocmmwW+E1h/+b9//efYqNipFldnG1++OOfYEturXn/u3/WrD1+ zM5XTIegJdPArUBphA0FThNvs9h/GvBycAw41QAt4Wx7w5zla6lqpJdZTeSI/pQytd/3KLlR6gsi pyAEp4fYymOBP6BITg89MJ1p0hF2jfph4EYM5TAEIbVktPoALjcUWDnN+jFCN35xfGQQ34PiXY/G C+RHGMuTemDbnJ2cjbDcFDE94xo3QBt5Mrw7Ve0TRnk3v+AWEM5llQ5uhN2su0z1JnJ8ru6fl5q1 L7XsbHptK/xS6f5iiVnRB8HZZSk+ay4NZ/NMp3QZ0Rd8/6w8XZRMOB0kdBkYkGCKvpS/nZ4kap7P kOMNIv9cl1eDkQZClzQuCnRBAtCif/6lOAelAB86V+vBAdMRX/2d32jWfvQjBpetZhLNhoZ1AzYc yMwSvBlPFkvXflE+z2ZjsLg+L6vKoKQhjYvTKCV6Nq3qI51TWsXXONan+PundeWW9AaSHIzf//70 bY1W61lpXcXXgbHrXGMVUJYCZ0E+0EIZe2qA8Q1t+xdIHKH2kmeBZ56rP+EtwzrV6k7JErf8PQTM 2H9IS3A3xFmbBWwLf8r0ppl1sEEvmAFfzbEAKxpB6E+rReHjIgaB4dVwjuVqrJgFgz4/EnAIlroN qEDb9mW0YZAGgGmEdofT4feGmZpNRYKLYSzzQ2SLcNbBLcCHmzh0BVSFqqg1tFNvIc0DGh4YIUlr sFN9qpt2AZI7gBigQuTpFLUAWBMlYZbwWX8GnxJN/yo9tU+SPXF6dn7SJ4DRap5dP6eGsoeGqzlY BbCxx3prmanL4+bb/829Zg/7Z9uAn+2tXrN1DJB8inFbd1oaPkIbaWY4jH2adWKeNaodO8scLJtd osdo0Y7wk0cBnaZEnGo3b/Ig/wfunIVP65LTn27KyFQoAawzatLG0Wj6IZqy4b0aTh+d8pTeJFqw MerdISBLYDYFaDSv0gGlI1uAr/LDpd5ydZ3hEBrR2J6jbFSw6TTG68YH5TRLOtUVbngSEevsdyLM 8niV/57m8grlwor20l0tCdgEXWt84vAozfLE55dyYwfVdXbKfjh/vht8KdeDfjV2myM6NDswO7pU VTvMjiv1t9+v8/qZbkuXfwENXl3UTIx5Rlv6TCk/X6DCA9wqEwTibsfZuZnmq7/9m80PHy0344/W WaOE9oBOWkv5GoWN/Yo2GQe89PjPkexgvs3rucKgfCyxAI3auT9jOuan60yj/qq/X/9dd3m/NTiQ h/MTEr4dDNHWuJMwg2mevGhvoq2rAqU8oi3jnUCk0q40LS8lVIAYvKDhMA/HTFW5CNw1RJkONOct Lacwo8mzrKE6CQA74OB3y1RFL0NvwNd26DqmFjm6Xim7Y6kDTv4JGlwfppM3lyTp5DKwKqAHUGEQ +FAL44YMedbEhGv53EFZNaYm46TpPmWiNs1w1n/JtslAV3Ao+MIfGr63JacKyhfoUWOx1Xad8QRp ypAZW+4ApkzzCSjlR26VnbJS/1broG+I4msjxdWa4mPrVV7w9whw5DmkrgB7sL/Nuj6mIgmkDDc+ 22pGWbQ/hp00NXTl3F6AGABomJMVat4EaVscw3SAlmkcYOxOT0GU/aHrCd0QYBw3vBjHqXDXqcni JMBKLZnAN/7cq80SzOnGAIFOO4ukrB9qOAVnE9BTLsrRMpwApKk9zMcb8VyLVjMbcMhjNJJ6E88y 4kLBWQo4/njUmZpVa4nrDeOdwEg/1/52Wd4n2JX/cyXB2pWX+l/wDFjnayP/MlgtgxQtkP8nztbX fT558cVvvgjJ2kmepioVf9XJZPdZ/wHG88ifCI1OxE7OjoaRxPFaeQ66thsa9D55PifKyTtv6A7P cNUfQD76fM48lHI59ZbnL93BRKEKPwyCORqI9SrXf+W9ZurHP2sO1n7YjLPLLFb2CehAiWImA4UW +52Stqt/HjcIpKBK9LPCsMMPc7x6XlkMhg91yFWZnyfLwTjn5kmwWl0RXH0K7W6p+3pQNmfzfhI9 N4KGyqNXP1SUTil6ZY0Ha6R0SV52GHi9r+xo08vpwUgVT0u4TNbph4d1H3Axzs9F9kcgAs+ONK3y YeQasUJPIKRzYXqMwwoc8PR8UQx/EZ4dl2pyCGPYIVEbSajtkkuBkIAt6csL0TzAPcAMQKE4BQry pNbNmeZRaLhGzun5AAL5JZRpRLPTCuhEy0SuPHZLXWS0TdJrnf6a+kg2SNuo9a2aJsFJjzVaJwDF NPgpOyMZ1ufqYAsa0IMn/a3/OdSeTB4gd40Ib8oHcgLtUFQAU9alTYxqsgPzGUxBetzWKNoolx1o CsNNHB5k7i5fQZZReUleTAONFjIccfpaJviTKgjQ0lCz/AnU/OdL+YvMoZcPA3mFB9tSjo3i2RMU zJlA/JBNBgcc9O6OUWW8nwKPtKJRc3OKgjDPhohcyDu3JCd3/nSmQDm1G0DUtFnXq1yNL+CzX+w6 26F5IHTX+0revwRrz1Fsg53teR3yZeTOVJpL6tCZNAjfx4c18TndGZrnxM/WfCt6Sz8NIc/Fg7bR 52q4Pk8euvktzeY0xCDr3bCGGgzfl2/fn5PoYJjT1MpdOqSu55l86NHlDK4GwvS9TmjDE84OxOfw 5Z1+5CK9cYcmnUwfUeU6QNQt8Be6MNUfpiuOQZYvpNW+VHZd+Q3SOE/el9I1bxByIHYActprn6/6 vYWh5tZf/63msw8fNrv30RSko1ViDGSELfLgiqhcUP+s7jKwUumc5KWS7givX6olRoEx5Y1pnMRv CfompLg5L35N98LrZRHz/nRoL3ntH5y65Wdalc96LUxa/YR9/msTlXlvkb0nFOiiwcAv+fVVfPV3 spP4xDFaAWrlXvWZ0astOMZbQ7YDqcCk1U5BzbgCCQhy5YHGqZ95MJ7Izolbzw6tdufCBYjB9Vxq 6VxpJn2jy1VsykmEdxMAEwkKeJzqzPoznj3HVNAxwhFLTtvtk36PacMtAIhHSaVpQVVZCLYCCgEV 8jAJCDIP5kotm7Ak0mqFY640yTLN+qmZsUnWmQFk1FoRTroF9jrFiLPOyQh5MZ5aSqeHzVPeG4Tf NH3IGLbndllIJyxyAb9gVuBque6xu3JM7TR8yYvruDSjonZxlzV7KeusI1PTxjQkNIYAkopJ+m4U sLvZd4Eg/xFH3jmtm2YhX8oQPgThpuQv05bEd/2ZdFjqhy8fZLG/Rh5Io5xuwFpEjRwjrz00e3uA OU3MzLvJgynpeY6y8pgw+4AeO1F9T9BsChDwmUfTtT7uU7nkqdRzy6HIgBuqHpGsT/hVV+u9/F11 R/09zdhVz8xfSf4tvl9QTSx1g0ba0q91pTaA55I3fA6y2VmPHVJ+Ff+i3TPtoqQzfBFnx3ua20rr NPfl/WkKSe709emLC++kW2kb8DwC5/l9PtFavp8XwvfPW/YOHg5F4i2/ggVsrh1Sq7H09jvN5tvf b55iUmBqy117dPCES3cboQglnq1SlA78fM6pwbw4ldWgVAafz6WSBKDiSPY5ziAvUnVOOTw/AaXR 55DhRfz0hb3soSVtGk7aOeianLnNsVOd+GqcfFmmQJWswC0xEmqIwhawpeQkY71x+io0zWVqRN6H Pj4ldgEtqWOCnNQ3QqNqVavgofROq9khSVsu1Q7Jc7AeHUrAE3xrC83pOMsjZUJc65/ZNJVpFp7v M223yk5Jp03dtagdr5z3SRjp5RQC6RNPSBgtoQTIv34FcPEoT7o2z9PsQlxgt+QwzJqW2jjBjVFd gycqzTSyNCzDvJEI6Zg3fgdoFMcBVjNMHc6AFuVnigTc0SsJbZKZHpOfaNoANuvrzcTcQj5sXFM2 ifkMd4L60a1BW88XHcOuoR+BR2jnRuBxjN2lw7vIloxocHaG0wK0c2Z+hgC67uK2vQq4pkjPczZN X3A10m4G2GdzwRGatSn4dENTNjQw5erZoWrx1uHLg+IXFxeigVvmqKinHD6vBtA1Z++++43m7Xfe aZZYU7f6+LPm/R9+r3ny5GnKeAf7eErFNW2euKBm9IgTDLoua9k6Htod7DrL6bSAum+u3v1LzdrV K7MryrGN5jLW05NdFujF3p/0rIXMIPg4HXJeJBnz0c3s4DN90QD5weeq3h8IdvrYJR9fPU6p+HQm yGnsEmNAFgOvz31M53fum+I5+J6P8TLo+josAtYYOA/pyEfQsL32b/xms/zph83+x581k7uuE2Lg ZYCp2rQvpzy6kil8nkqqPP9F+HtZeX0RHgfLI8AK8CAoyDgGUZU7SbsVyrAaFPwLkDJGcZW/TIkR WSAiBKsqMXBHnsRyApBybSOTnqVQtT+CBg+Ad+egWntpWNby66/oy/CGvJq8uDDAO6dUQWBVeydd KfvaeJlOow5pBKJkqbwXIBnOkw+mQU17aKY2ABuCriN2QR6hVRNUOdy7ftJ7wYA0rccS087XMMDT HatlfWArHRI3iEZ2h6HLdkzAGh6u1ROQCSIIoMYrX7/kW7A7BpBRs6bZCp25UJvkrtPxHP/ELmoA CuvvMcSrgAGkyh6gowbLNZ1jbHbwgPk9bKM1mMHQIoEHp99Cvh9/9CFmc+AVjdMoAOoYG22jmOp4 862vN5sYp12Ev7uv3uBYqp80d197Pflbfvq0meMg9LffeS9HRQncFqcxA4x8HnBqwi5ayF/75q+l /H7McVZq1pYAY0fs5n3y5EkM3i4szOec0E/vfZrynAUc34KnRUDZj374I+zCvU/+D5sf/OgHzU9+ 9pMcwr6xDojD7EgAptOjVih+ngF645WbMRkCLuxziCJSq54qACyH6hBP6lB9vsrXl2Dtyyy9bi35 onStXF06g89flG433jPS7LJhdJ8H/bpkL7sv3WkNBaXS0qoH1+ejbqc+CLY6xM697efBIHbkXeeT Avo81x/680J1/QepnaGAx2AYO/Ku6/+e5E3/a7IhkVNPB+AzYboEfd0J76vLZFmCn6ZRyqv7fJam g5xaNflnXDCVsOVZkowvzczrt5pbv/5u8/jxyv/P3ps2a5Ych3nn7mvvyyyYfTCY4QyGWImFlkTJ pm1J4QiFPjj8wX9L4X+hsEOSQ2JQomSGKFEQLcomAQIDYAazL93Ty+2+++bnyTx53nrPvX1nBgBJ N6Or+77nVFVWVlZWVlWerK075Nwlp6r4aI+F25bp81hbA6NWFDBPU2N+uHE5M/QL/oo5ZeW0PE5j d5b082fzQPoHFOPypao0RJ/yMq5jLSVOM8uTUtLEGvJCeq1Zc/2ZOk6Xqf74G2NkL4RazeJcOEZC 13g5uMqTGBh98tJSFnGBiR+EQLUkLrHnGQf2MtjzH4UCXOQf6TkfLaRG3Gp9OH+jKiHI/J2OjAXy UfPWTkAEHZEEBSUOcIVGnwqh11UtoOjs7aLYHHJm2cJKd7zKafkHy93+1l0UOM4MIxOL6jEgKk2e 56VTeXONmoOmZ40to3htcC6ZljCbnztFPVIHm1IoV4fginPnVCzlELikMsqOV2VVRTUsRiguusAt PuJcZ3YX69I+C/GXaAgr4LYudlHsPGIkmC6/oMyPn12VPKZf73ObwV/85C/ihH8yQBFCAUKhO2JH 7CIWt8vXrnWXrl6N969xSPW5lcXuo49uda9+9fXuJ2+8QRm5fJ33PXaAelPC+QsXut987dXuFz97 o7vNkSeXr15hk9C57v333+fw3XWq9Kh7+913uqWV+e4pFD7v+vzxGz+OM85efuWVuIT97bff7n7B 3zLWvCtXrnRf+8bXOZD3w+69997vPr7xSexe9Vy8Q3amyiPLr/KsPG4Tdufe3TgAd3aGGxEa14vk EJL36ipx6ax3eTYJqZiH7znz6aefPnTlcJ67zlE5jeUejPfrcP/kn/xvyE02kGiN0VNMMDuQTDEP qeihA0ghcZF069r4DLcBj1zhCSkzfiySDbwdgVuDGieZJg3aeRmR3XcuARGpsqvtaSdYGg0LWnsw r3URaaWazpHwaEQVC9oAaKFM3MRLXuQ++fE0+7Oc61GmMFo3Y5wtAMhGXjrr6TzG6YOoKZBRjREX 29N7QrNmphI4IoyKMU13du5jmNafa29aJGM65/uOu4WZ4qgDcgxeEwgH6tZpxZpyWBzsHINn/By7 gLlnoOhih1v4+3TxmBbwGlgLrzvBTCtoJKXz1PDgdLRK3OoRg937H3Y/+qf/ojv6ize78+xYc+XN PqPwPnxUCj1EtXXT3AQXFRL4+TGPskpGfoQ5iMdg2SCZ5qex022srXXp9wwwXeDkt/hSKFsSpSXL PMFi2Ge6QJo5FKwYqryuf5QfklpQFWdwhUW7DwQqUtZPD6XiwyAYZQ14/CTKtZa8h1JCbF848ZnS NVSBuy/ErIuTIi7jEy6VGZUkraL+Kzp8d3G7li2dU+D3QPGjvXvdTTT21xcudBcJX6dc2zBuiWnP A7QWeSptsWMU2TUfvIFX3Nb6Ip2w5zNae+4k3maKbxOFUMXq8i4TkMtM5SFzTjcuIM8qinf5FHjv 7qfdJdZRXV29ENcybdG//fzuJ90Huxtg9aYCFudjibp/vNvdZrflJrS70SGmBeWjZQInJ89EH7RI HktagdhpuYDm6aYAz2m7J+9UvOCpH2Bxbhy4qhzydg+rnqx104TrwJT3JaYdF2CX5TpCiakzKBGB 4KPTkYsoZk6x7lLacCCdW1nr5rBezZxbJ0+sg5su8PfYkgMULK6m4mYD15J5SOx5YI6Y/t3iwNzV xTUUpkNuObjbXUGRc1frJmefOf14GeVqlynQra37oYCtra8yvXkXP/eEMpVsn+Haw7l+g4MWP5VZ py+9FcErqpY5VFfFft+jQ6hDD+r1ei8VwS3y+ZCrsra27hDnRHY5ucIfdZ1dF8/x1xtltC6qncC+ 3pEJ/yudgQfc4vDrcNL71+FU5B+5B3BAoQqnsFj35R/gEZRBODJwDNL3a0OKkKDGl0gVyt6FbKZw hgDSsGkKFRtCibY1+H2pSqy8FdgQX8GgfUy3HdmYDgevwOozXlxLkc7m4FlKrRtfjOu6j9advkB+ Qrdv0xjxjwitM3cK70BjBficQhJDWRs7ZhVlm66w6UG7Txo9af8e/GjoJr/FWDgzySb5NfGHUWDi 5W2SPoOniI4BYExXTQMWmjGGBXv9xk37iCBgfECzndrEUc+t1wjSRB0QLmweTUkg/AjOCm/naLzv IlCJb1zu7poEuGj4pDNx7xiIVjiR/JmvvNS98+6HcdH2AqIkhDIXmw2mcPRyWsl9MiAExp4JPvTX U+qdympdq1TKe7/kdaPiZLsn3CkeNIeA8acpQYSFvw+MvPnpyRmek5cBzfRLk6YiogyEV92pllAF 4Uraqw8yXxfe2/Z8V7a14lRa6zY208HXlNlUcoI/KGryRHhTtC6Xrbchid+Q7GsS3gXecqgUfsk0 nyyD6xF7OKC8LsozyTxs10Xvs/DX2xv3gMlbDgjH74A/g9I+oVR85E91+XS5f9yIALB07zDYc14s dLFui+NA7KcMd+p9j/BtFrhv7Wx0Ty+c777EAvd1MaBxsQy/W+Qe0cc47mIWY8AKx41gF+tucoXC bT4cNrDyeEbbBrJ2HyYeUPA4xiMZgEUIZY4y7PKnZVCr2RKn56/SV9hd2EfHuW4qarwrsaG8InDe jOA/qM3ygHOBStVipcx5ZMg++R/ITKc/wXeIMrWD1W2JHbOHxAfPhGcq9HgHNZG7eGfYIbqE4eLc ucVQflXG3ExwPE/uWOdUuFSm5NEW1rB7KGrnWI/mhe3etxl9ATz8lLVkNnWnc8330xs3KSPlZDpU BU2y9sA7Dx2rqxxCO4OCy7q0S5cuc9MBFksUtBufMD2K8nuJM+FCkQPXBjcobG3tRJ5a6vb2tpja 7ccRkKb1NWUGdoUg1XQxvnAhC32kcpxjCMC9rBVUD/5QP2qcf6gL8ZdF/FwM2r2wkMncSElyrn6i 0iBLNjoEt5zrQjgw+0xnV9IkARYc9sYIW+RMY3Z9xuCIUkDL+b546DfcSWcq6RkrJJF+giITNlkY oPWndbOjUSyjJzC5xHcaySQWTHraAMs31aByWqDNMxkwCVFfbFkBk+JfQYg+Fz9XCM82T4OnSTxB gwwbJ2kTScPStF4KDrvfiYut9hPvpC4r7JSylzWoQNAOhldfemkYwqI6mrJoQZniZ+QhXYVnjME+ kcDrAABAAElEQVSBe5puqyM4annweH9n7LAyPPJykLYTJW38OQw2zAAmrCADlbzUeqM+LC09UBUC xJc2g9pdUMxzQO7SEqfMM0R6mKc5qVjYFFzYPTgIOYSuKedia1yQyDMXvlOSRoan2gA4CtZ0cqgs riVfw7Pn32BdMgFu3D7EV/wvjg+ZVGaj/iMQNT+VvoIGmkmfFCObfZkCJcIYipvV1Sc61hpJ3SjF pomPpohXQSPMecNQF1CGeNdn3UZ6kAX+kTyPW4Rrxej4Mo2FxWpW//TaRsLhibRk4EDfsxKaUYzw eNPAPMqVtWc3qfVoiQF/zRP6me1SXYtpLJQJ+T3wx3fgo5TkIQ+sL9dvrSEz6CKh5H2yQr+onKLo 3Nrd7m4cbGJl2u1ev/Sl7lmun9oi71mUlRnWl7nLc2lhqbvE9LzK+xx9u8rCU1iENpfOdzeZ0rzF h8V79+90t7BSeVbbDo3Qxf3k0BcNxUxOUBhZtHPItD4fVYe0gRksbs7vK/9Ob3JcbayLW0HZukAb ADwUNHe4qny6uUGZdFrv3iqjDG1iD+VIXPvSbByFdnf1EmVnq0DwyLhDLjP3PLI5rnCaRWFbYKp3 AW2u8lah0tq1yQYEL1Q3fAkr3ZMvv8J06EfQ2XWX1y+jOLEOjjzdzOA6P/nhnZwqd5E/NDvl6U5O z1Db2saCdsSuTsqpsqwFyns5L6KgeU2VljrX6BmmIjtL/t75KT9cn3eedXJ37qjs9n2K7UXhxMXv 5CfC4kfGARNyTrySUf9MlLIbCSdpHtK37OUeUuL/ssleufNpZGEnUdWtbAxOIRk8/UsB9t7q9Ats EMQ+QOWixRGyGfmRpx5M+q2iFIN605mq2C3ujTRCkiXNvlTOk2cMqE14vZbSYba9raJPBC3xST7B MXScfdCMg3IQnwFZ7sIsGV52PD3IjnFMzS+CZhy/wCelX+3loox0xoODkak0DiHk28QT3PJaKGPb fETf+oUZXCWmozzV9cELdGothOAxCPaJgu6mHAafHBCnm+aYphaf6TO+Kasj2BQVWVZhdca6y27s gl89D5aoMyGCVMNqhI73xDdlvSN8rKzFWqE2E5gh7TUV7FlQRwwG7vQ7f/Fc98mnnzAFg9WFQccl BNJ5yNRW65h5mXJ77HQj66GmS88dWie8AP0DXfAiFJhEkv7MxHddDqf5Hr+tAlnBvVxESggybbX/ xFPYKsH006VilqNc1bF1onxYDw5G4XrFLzA26QKy4qBHuQhLW6+wxRozEKhgODVZzjyi7vkdUzn2 y/9K6dPlC0p8yLXpqQDzLPplyww7EUNhA96+ZY9+bYHzx+Zpv95eoFVtxXKA/Bz3Xq55RANhRZNK V7UB8Vmd8kOFXBrkj3WkkuACfy+T1/J1h0NkbzF9t4UVag0l4hvPvdpdRKGb3WAqCwUmlG7pp/9a 4JqAVS2sIPfKM/Ehht0Wlr81aLqI7eviOaZwUWCcot8l8udbG4DnNKeEuGjeTQS2C6cYXR7i8R+7 yKjWJ2L5c5oWZ17IkTswvcWDqFhBkfJDvw9fnJmeZ+ONL278OARO/J7+H1ZsC3+4KwWkdY0dV1Kx lOAYi5WWQnTOmNL05oB9lNI4+BaFSUXq0sXLHJPhx9FBd6E/RsMlRmtsBnj55Ze7n/3sZ7He7Cvs 1gSoe/PNn8Enr4SSLhVGi4DVDxyxRAJ+q5QFDhTCW1wsvwg+nQriNlOv3g/qXZ3CuFxJOtxNqsJo 3S1iidtB2bTmlZ+o/+iADIrCim5wAWN4CAtpBAlvpq32NyR4iF+YpVDsH7nTOPDx//UHEVydhF+s U84v/BIkInzNziWh6I+6xcZ6Yeo4V6hBMkeDV+jLRYcX2SSm6IpG8W2dGeW6jdalkBMCQUmxHXCP hMfw3iYK8B46CzLESh9tcsoV5gpc4HOyz6GC+ie5GRGmIMs6gWrfBfZbO6jrQYK1vBe9NrxA9UAc AAyf9WLMzsRn5eWw0roKH8Lo8MZh+oMGMo8vZhb8Tkho3xMLfU66KEf8DOh9ccBspz3lZVpDiATc KR/OGJ9KM8aSVZ71FYBjgBhqipApVL2HwWhaByJj4bWW4eS1L71sKUG9gBMokX2GUUkmSKfFrXXe xZqgCe/Ari5hmH+L1gcnsjuErzEFs3b1cnf7XdbCEG7b8DPEy8un3ChPdUixV7C8jH8GhiN9KK/l n5CfdYufNIJbzz6DxvBXmmle1odNxWZWCTPgkYfJzZ6XCVVpfA7c4gOslMxJfMZGqh5wyFcx7uug yh2EW/IoSw5W8qFc4In66flDwigtEVHXfdxJKhNDhAuL4uC7g2s6rC68Vk7Ju+RjKW3DE5pV1rzZ YBEkiygsHnWxCq5l+spDlDUX6AtlCSJPMsnq63MAR1jaCFePn3FeEOeVTPcpyMYcd1WifG3cvd/d 3LvP1Ohu98La1e7bjz3TrewedJvb97rdJacdcSQ95qtAfDHdqx8+hPJBWOz6RA5X+juvVmadUkRq 4d0hyt5Ta5di04EX0u+iqN1H0fC6K9eUafXyonitbVqj4iBfCnTMuKGC5liww/jrFK1l1jq2Y/8D 7iUVWHgx6+XskOmU4yz4I5zdnHJXlW/nAKWM9yV3lZJH3I+KwnNu/WJ3/UvPcGX9HLw47r709JPd z3/+c3ZWrnfPP/9C98Ybb7AZ4EuxSUBl7Tvf/nbH+vVQoJ599tnu2rXrKGdvdhdYU/b1r3+D5Qk7 3SeffIgit9oZ/+677wXzLl++1L3zzjsoWLvdV156hXVw57ofs9PT8l65fDk2InzwwQehtL380lcI z00V9zlPbZF618pm/nfv3KEi51gftxr++6yHU5FT1uawelpRHi8C0xB7lWv7lZKQkEYFkrqzU4M7 xA0dAiF/E9z05/vfhBL9Gstw8JMfnYktVYu+AwEy175U94KfqOgEeyzGzNuTNc5t4MpVCJfhCNwU RAyWUyHANAgQ4uPYIz4Jqy/YChF/4I102YlWnM8swaQchg306MHN9jvE0nfyd+GYNRINYQNOMo9/ vbJmYdN/EoeTCBYu6YXYGoVMw18OMUlb4qjBYoJrGMwqKFACB7pkw1hZc5RJzIFT9WC00DDZZqxf vrkrS/TJowyv7Hweus/eQuT/Nipw0OdOO8sXITxNg9DMMO3SOr/OWzf+xhrXV+Y9Xda+ons0DE7H 4+Y/TdiBF69LkMiiQqmDILQPy0xasmJwawNcQ6UL+gINHS1IAg2/Thn77l2Vyui5y1e7+xwdcMB6 mmW/EGgfgxwEppM/IRtBX0pdkBy0ZS4pRhlXqQ0TzlAlq1zwPyiqkHw6NJ7lMs8sp+9xiGhkL59J 6TuK6pQznD/VY1/llM+JKz4RQlLjpCJ5SUCPLtI08Zm+x0RBUzYSV24vyLioW1/5c4orakL4UVkz vflm3+Sdj2btQaVRbmQzYKKqiVHpCzw9rUVzEmZgKsfA2B+KzZ2XczBKnSiueeqZUR/KkdRMcebp eWiS6QG30nNI4CbKyydobzf4CrmJNW0WBeM8ytW3Lz3fvXTpenfEWqx978EEt4qm67ZUOw+cGoYW FR1fLcs+tLjGbZ9+y1s3CCav3JUpJ8PCTznPu3GCmttDU9QetDe3zFEZrF1DUdulDW9w5MUuiWNj Afg41qy7h0VxAwuTZTB8D6XMY0TcSKBlbo6NELuqe2zA8OPH/sDlCIDCNyySeyj2PF3zpmXrCQ7f VcbiMFmhUOC2Pvqk2+AKqqvPv9g9j1J26fEnY8rT3Zry7xZt7Gtf+zpToR6Vcdi9+tpr3R//x//A wv/t7umnnwlFSivcVTYbPPHE490nH75H7p6xdg6FbiWUNtfAbWzwYYVieYxC7LSqNMpLlbVlpjr3 e0ubweJTKXbq1Hf/rly5GmV58sknWYPHxgQUOPNzLd2Njz/udrDGXWX3qha7t956s/vg7Z91O2xO WMA6J4zOmxbI0bfY8BAfjBDi2KulH3Iizt+H2Y1764e5LL922ldo7K1rrSGGe5J0COc00KCg+aXs tuvWOfa0zjOD7Amis0OQPcuml64E80urTcB7649pANZQtK461wrLTlbBBn+buABOeY7h+MY7BWoS 5M5BO7Gxkxb/cjiy45GKKPAYlNDe8hYwQNnKTA+kOIZpoj7ewzeNG5z5mMHIGZQ8AZfmzsaFDkQn LaaAS22kgcjXQMuPneI8hKTfspx0saaH4MzzZHxYHgJBxmVnkvB2MLrgUb7G73h6MU0ZTe7xOvE3 6Bss7SuDQ2XWBjfvWg+SwxIl7npOgIr2ChnVCMHIjUmLYXoGP50pg2FizvBlLAKXrj3e3bq/xaJq FzBj7/iswvTWvxi9ixCfVZdjInsYrSfm7U/RzfDHvyx3lbZg+mTxGJMUi+T7DzFVGltLtZhIb6px IoKUceGP+EDIQWeADvlpZchiiDPCBAPfUET80hty4bN3rmvSRUlJ7NRylTUj+pYZyktvYRpZMsMq JpNIb8nmYjs0GEOQHRDBwV/IPfk5ILd0S+ekVEEMSpH5Jm2z9JHqsZEuiY3CSGeWiTfoE4v5HGpt 8SOA01y5yYgdm8fs1jzobqEc3eTE/k8PtlhrddC9yJlj37z2bPf0HGu0bm0wfYmChDnPunKn5TzL APZo0PYI0uLOSjcsqEC5wSd7CgtNJuTBG/kChQJgr2yZXMesJS6mRQk9Zt1bHKxLkj2Ujxt8SHsz wi5/myhFhywnWURJPAfsEcqKCuGefBQneGJJITl5ZdQBbWMfi9oufZb16Deg+e+AQ1pUJBdkHHl6 X+kK04paiI+ZNj1i/dgmx2IsspZsY3uz+/Fb7/C+0N29u8EasxXWlS12b771VljSnPZ8D+uYtWuc 07XyeW1tvXvmmWdDodq4faO7cPE81sqN7u23fxGK333aqGvQnE6/dOlKHICrdc5Dc7WKqbzpvLR9 n/LvoAjOOy0Kbp15OOWpsrizzac6dfoYeBaXVpl+dT3bSvf4letY9y52ly9dYmr21e6T997qPvjw w5AvFdbNTaa4OfLH3a17/jFmq9ipyMWRKMiK+IV92N0jZe2MGjwx/TLqdFTGCBqcwheuCRvpUXwJ YUFo3PGxxngavr1upevRCDZDY5+hUZYzqrKJMALGFpKWpoDpv4hD2WyyKZyTjJuQERI70jOd0f3A kHB2iol5CHZQDTynEkFcX054EYPMUFA7bQcD/kgf3SRI/coceBaZ0smNB5qeiBo8cuv3hJ8qX2YT 5EtWDPx2hRMXJJtrvsRXfFJhqlMcnVe4HmnQ24BFGXpcBgsW5WvyGPSPSkfZWzcT087T+Rd9CSev 2hS+TwfEWU1jkMbvvYyDC/mULz1vQktwoBogKMNJVznWgF80Gm6YFpE4IZ934xz8LtJB7/Dlv/Pp DdbgiLOwnMSfIdAUslK09UQNDJCyhtBIBKyC2aOOoTiI0q4kHujpC+TD8bRgI/noJ7ICpkcXseYo ph7N1JsAxYuo2kjb028kLsmfpE74zMF3Y6Qxqoan8Fq7Whf1I28NBGBWgW+c4RECER5xoX+qixI/ oWHtVUHCxaG5PU7jnNYPGoQzf+oim24+wwoVBETy+CkFXJqH3Z4xp2lysPpBJKT5w0hVJ/vOWaxo 6DlYj7B88XePtW0fY9VxA8Ama7KOUFQuYN169sLl7lvnVmJ68O7G7VCgjhAmr4IiR5Qbl4+Yg/Z8 JxRVlJxGrC1fWPmAW6AtV3z095YPNmiH9OmEJ6oAU6GUlbgjFCmVF1mlpXCdXaV+r+8SF7tWSScX nf73OI9FynaEdshKsFhvFpers+h+j4rdwAp4QLnQhmPzgVbR6xcuAc8ULwfazvCB7C7U+2yc8KNm aZbjMdh5eZEdrU6hbmts4My1C49fi6nbq1ix7t+/H1a1FRTZG+zq3MT/zjvvoqy9Ze2FNey9d98N 5eoeuzU9H+1P/8t/6e7c+ihuMLhy5TKK2Hb3M6ZU11bXWXu2yO7aVJBc4qCS5I0HTnGqIGmp0y3h X+BPOlWmrmEti/VqKFJej6UMrq1fQOFc725wg4GzQ5evXIs692osd6suk/6pp59HiWQXL8eOfOWl lzlq5Hbg2UZhU/Hz1gOtebHrFyV1B1q3e/qCkIf455GydkblcR3blLORta462woLv71P7+xI3ZkU 3U4fPONnW+OcEtKZNpNOx2NWEMHgmtchzMWwuiZr3htqxR3NQZgmfMBgFplP4h/lgveEfa/NTDyB dpIuoiNfwgymnLKz5dkEWgSCyIM+1GfP/wgyrvUHUhIBFrSLIJLQUfYoDCoFOnEwGIWurFLX8wz+ tjBBZSiNEyTiD1/gp4MGx8BPYyagZhnWN59huam4ehqBqzzTB4qWaONjBK/YyXOA63kxiRm/SaG8 GGVcYIafiGoDHLhR1iofoxg1EyI8YicwQ0Q7eWvfU0mqHYR+lEhTcNQRnemvaAIDKqZGPdvp2mPd R0xbHbILzvVsRltjUSZ9fbsppYCogGnJTeg+IgV0kCGBK8t4+tODyrmUg1ReMobfQi7cKXyNOo2y xfgaOdp8Q9IibZ9JjzDRVdi03ApSMT341KPixFHtwhS1q7WAI77HFB+ERjSyFUo0NMfMfzCTFElY oZhYvPoQj5Koj7ew7JNOeooncTtCX1NDHQzYMnulwjVdcSUU73GnJ8qN/Uxkr7KGP955ap1xAFdx 88LwQ+p/E7o/RJl5a3+7u4XVbJ7wp2dXu29ffrJ78cKVbu3+3e6TzQ2O3ECBoM0uM123SIX471DF D8VC1Uxr2oyyHUVPZYos8UNPiq+lCwXMKTYhju0jJE4FDTrimCGeOgfViIJPnHhGK+LIC3Zlur1g mxinSXdQUlzLFmehuRwBdNElgWIba5ofonkI7ny3yuq6FXZtul7rEhsWNCKcY73cRaxNN7i+6Ri/ 10fd3b2PEjjHNCu8YN3aY5yrdshBv5co21XWk92+oxJ03L32yldCYfopGwgWsMo998wz3XkOBr59 +3b0S5+wI1RLlevgPv7g/e6Dd99GAcJayY5a16a5CeDJJ7/EGWxMh2LNW166EVasZ555uvP2g5// /GdhDdNKd/2x692PfshyIta6+Rk0z+5a5e/jj2/Qzkm/zvlu1MMGh95e5IquC4xl1x97IsK93mpl xUN0L3P22yWsfE93l7EC2jcqt25acMeqFjTbnhbXHRTUsKThVyn0zDetegfw9GF3j5S1M2pwDiFo nVMAuhhsbJhlQWmA/AKdOMXTrsGmnq7vfiYgnCqdDghxFuAAIb4TgUOsL97JFo7WLqQp/BJNdE7q +N1YzvAsR4XYKWUupiZuqgwJld1xpbCPmsahNWKShxTnvwirH/BW+YPOvnMrrAw1NLrex7PojDD8 0hBJ6KgTzMAMi4HC8OhE4YMZ8OcatsCjH54Ep3gPa2XPrwQOVBkeJESCRELZsjS9N9ZIZBmlqQau SMYPZAz0tUUMuZEoURf6StT7iz9FU0WncpdA4jxmXU4sgu4BIqxBKg2pJkChkZm00PGEd45IugTm pepUYHlp9yDHQsPlNeWZAFyPkE5zcICKMUUjw0P+G5Ch7ZA+yWJAVC6Eoe6i/ExvXbh8jbVr97o7 Nz/hy5tTzeU5gpB2j5STKD8JnT4MBw7RSJIykzwjzIx6ektyquhOehqb5QQKfFVPMYArI5E+gCY/ PesmAbyBqBSi4GQDoz/VgEmKoi+5LhV9Oy4Q8SVxERK4+w+zkmOz8E/5tODxrPQ+2/rBa7qx9U2w yKbhk2HlxuUPBa0iZXRPZLVTFdSiy+fYWVsqKTskWDE5/ewhmwJ2mQNc2qeGnZJFGQklHdlwpg87 FNYxzksj3SHyscF6qfe5mugDNqfcxpo1h5Xt5dVLKGrXu6dIv7B5o/sYPX+b740jELgbUudZaC7m d1G+a9G0btX5b07JOy0qM4SWxn34JyV2if5lPYopay0O5cXnTEAvvTSTrEdlWWugbcADe53m2+e5 hzq3C817KClbKKX3YYibE3YpE6oGU7suB+m68xzrcRFlahm4FSxYru9bRnHzvLWVee7iZMfnMkrd PHwDPBRAp1a34NMiO1EfI48reyiMNz7tLl9/rFv+6pfJY7v7yZ/+affHf/RH3QEK3jmmHWdYQ9ft rqKceVgu556xzm4F696dozvd5gbnr7F+1N2yLsWYpU/wmA4VrE3WBd5GWfSonQU2AbyDUifzrj/+ WKwjfOKJJ2KzwLMvPEslHHcXOErl0qVr3HbwcXdncyemOVdQqq+wqeje/dtscNhgfdqT3euvv8aU 6zrWsxU2RCxzz6nn5bEphQOO3RSlPNp2/FtY5gotnjJA2Z89XguLnufBecRPtAfgxzIMoQ+de3SR +xlVZgOYdjY7GqnCEU6BmUDYwNoB1C4rFQxF5iQ2U9oVRLqIF8EEX8SfnqwBSsFNAaaToENIBUVa oNUBcITTrs88y9EnRUcU/r6jqbh8TrqoCq+BZvCbrsEZGbSZFGD/lKQWfBR9hjc7zwQoDD7rXRba WeYgrKJWZPjeq2uRPFJMkiVKf4MHlrmJhGBrs8Kq8Rduk5WrzqT8U09RNmin4qY8ZwH1cY4e5YKQ xk8mdq5Fp6QP75Xmgc/En/AOW/r5G5SBjA+5UnjKKW71Xs9+sCtvcnAi860lKAZ54G1lc3xRX3zy se4u51od8zUf65lisCCHvpg+Yo1i76888nlqYEQVjfEU7LRKnEb2+XzgamUkEhFW6CvfQjbuE076 TascpktWp19csVCeZxyEKwgZlbKotxwsHZzDV8uZzy8TAwoGwxYD2U6i4s3YUFwQEPuJcR6WQ6sS E4Zxnlh0UCTyqA2XOngqPls8w+o2x0zEkbvusR7tLc51t4j6iOmtGywydw3YDlP115km++q5x7qv rl/pLqGo7RztdB/tcabaAeupyEf6oh/o35Ulbwo4UDFDWdJZR8qztEm/9ahs5ZS47wZmmPDCGOSf NRJ+fmIdqMj6MDcBaBf2c1m2yX0/a12bpj7KZVeR+aJ+3ueBj8Nvgxgsf/hdZzjLNKCgfqQ5Pati JbZ1bmCYg1f7wqHAbQN7wDEhayivq1iVzqFEzX50o5v50Y+7y8/9drfDAdTf+eZ3u907O90//+N/ 1/3sw/e7S5gdPe/M89H88/7O8+fOY4m73a8pczMDyiYWKqcy3Q0qeVqwtja3mE79OC5nv/HeezHl 6JSnx3N8yAYBpzjj0nbqaH9rjmnLLdr0bndv5xBFEQs6V1dp7bvGRoZ//I/+cffqq69zs8Ey1jv6 HRRrratKk2v9og+IpS855rkpxmlXLW2xphdQ1zLa8/udGbvufbc+skqslofWPbKsfYGqSw0+FbZU VlQKFKZ0U9NeEZQdax/bQ00/Eo8CVUpVm0ZY46bTTPvMXwUtO8VYpGxLinSJc5y+HQAmuKocp2WW ys8EllLTOUy7cTr9bdjYP536L8tXZY8yl+dXyCxK0eOxExgPRIEaoCq58VnHZ2c6DXNanRfGs/G0 sS1t7XsLc/Z70RGljg66hQ+KHsDTKs9p+UYSeSeX9MQfmH0i/mEnw+qxeOl8d+Gxa929tzl6FE1u ntPSmQMLMAc+hs5+EG2p+ut5ny5vDsxji+u4ZU+kJGm2BaZClv5xO5Vf41ZX1joVi9PqY0zDtKom yyPVF2JabVqoRNZD66Z99hXTIZZB5SXWbGnDUkv3f0bE4OtasH3OC1OpWWAKcJv491iX9C7Tnh8x cN/ForYCN15eWO1+CyXthWUOWmVgv8802E2m7HYYtGcW5LjWIPmWSpIDuTt1Y2MAfZjhOlU6y6XP XzdNqADEjIHvEWNZ+IOWTCXNfXoifIspuR6Hfi+Siuu3mIUJCEjSUuihtwssZnMZzBoKjYfZop7G blHzCoXYzKJ+sq14GbvTnItY3OIoEBbrOx24MJPnDG5zy6JHhTj9twb+q7SXS8CvcMfn7J/9eXfl d7/VHTz7eLd28anusStPdbPXr3T/+7/4p1wAf6/buZs7OaX5Yy5rX+K2gVCEoCE2EUCzNO688VOO 8LgR8YCSF9dVYY3zGBLbrbs0XdqwTfgdljG4Ru3QKV2mRHeZFt4/uI0yyi5zdul6xtvzzz3Xfftb X+uefOJad/3a1W6VHaTKZExbonE5nql0HR05DczYC/9i5zJ05Y7e/CBVKfa8Nsi0yqPulLv2z6iH 2T1S1r5A7fXd4VSKcV839gvchrXvxtkeJ03f93F3bIcTImjkqU6BVMDzWSCBGM9pac1DvCedHcok xeTN/vQsNx4EErZo0PfZ5TgL/xeJi6/oB9D7gODPjb5K9FmDXNXHGLF1pBunn/ZL5bh+rONIaWpf PtMVznp+ZoLPATAtrydbhHkN8ujwNSLV+PqL7EosIjwn7GOajRHNU9/Po6wdsg5mi6tw3A0366JD PxSE558D7CiLQBt5ODxWhRnav/s4PY1D+SRurCyJ4rNclf2z4Iwf0+AdkuOwoll4SxrKQyWOZkyK 3sJ6Gid6PcgU6Vp+VNgXfcL7KTfF5EmMddC6kn3BVS9cExx1DZjKidYbLUSHDOKLWtawrm4Rdwur 0g12KH6IInaH+E244Lq5F5n2/J3lq91rnpiGEv/B8SZr2Diw1rbDNss9Vu9rVfQ8N/6n1Q7lCDbD slTG7O9kibSpJIUiRoCL49MiRih5DrRTpoDvC8bUFGn6tkoZYi8xSqMiKpxXapnDkU/ra1TDUX6U Ng8DxjYWeqvpwlLE0/c9sHpG2wwKn8eauMbOjQghreTpkSL+34O2PfhytMxmBRKeg651IpawiM1w afo7/+bfdl9+6n/t9jnS4wJryf6Xf/iPu2exXt+4/XH3n//wB92f//kPu8evX49NAfdYL+ZGARm4 Q3rYQf2wJozF+q4vm2cq2sN551EcZajHjXimYtwLyhrBOSx0KmkqryrLseiftruDMjm7hG0QlmnU fObZp7vffP3Vbg2asXVC7Q51gyJLfLSl4F+uxXT6/lhLG7yIOF7lm+95vhzLI3rlGbZFuHH1Z9jD 7B4pa2fUnpWsy44f6bHFNy7Wp8XnYAWOYbTC0TNEk0uYHmUlQGgzD3GPO7cEihY+wJ94QeqTrMQj /hbPqL/sk5tigldf7OIKOu1a0jkYxqDIw2G0dW0ehkcaGpn5GZcNJN9PpyHjWpxDxlOBE884T2MM G8LlhYXpnYPt2AIYB3k2MAUbCSPxdDmNDz4MgCpN1HPvLGflb3LfB/71xFR8pfFZstWGFZzJCkfF D2sEe9oLtuJPe7a0GT9Oo/UgXP/oyc2wPqJAMlBe+9YTEZyp94SI2Co38e6nqXxTnvr0JhNu+Mtw g2NwI9x0CyxAPscuNnegedWO6ozrZ4RTSRGnKML1zwnvGJipKq0XQzl4jxoSNtpOJe5RRL4OuaKf xFUZEur035bfY4uWKYouKWj94Rl+Jnn2YEMMFEEXlFkmQwG13QZe3hN/kx4Qwypfk8isaYgI/cwf y1Yyq4LRuin8RESePcMrjfwrHqqIeAdo1CJ1sB/HK6BkMbDPcdUUN5QDy5QZfet7WMneY52Vx3Ls Ue/u4HwCa9qL5y91r3PMyzPupseyc/twu7vJ9Cd7JCHA40VQBqDE0qrLqpw5nahVyx2hMaj38hN9 RNALvLJCGSyhFrgsK+vOgFWdiz7FMgIgXtgf7/LVVScqU8ZZR35IiEMX/CNMxBkSwaGcDReJqFmD 0/yFyqlT1riBU1UuQlFG5lCKPHrEtqDKtighpNLq5tVsKp1mlYcLJ7bZ/c3u7p/8sNv81hvd3De+ FtiussD/v//u3+4+XmQH5b392OH53AvPd6+99tXuB3/yn9kBehsrW551dgUlzrLfvvVJd4wyfYD1 Tu7usoPOzQzeVJBLR8mfLIuPMsMeVQuk56rZIPfh1SKbF5559pnuS089geXOXbhsw4h7VaVeDkXN BTOiHQYfQVzKWF9fFiSg9fcyNpY5/SV7IH5o3SNl7ddadX6BTRC2g3qFliCVv224FdY+Pyvez7Xx cRVt+tPfJfIzMdNostl8HtjonSKzaDpNtuX/7PyaRJ/rtW2AxeuG/dRFdnADsr5ypsNV8KCt4gZg X05p5GTQ1qFp286g4lo6plCe4qlyFB5JmV77SCJp1BVie+PB4/sprqfNmKJzgCp8Q8DnffmC9djn U2UcytGHp8XWQol30k1LjSBeqn3+ySe6Tznh/GDjDsORH0ABGknOosb0iZnf3hNHUARuP3IydZKS cqAcSasxFW92n8sNxAwvU8kcfHVkEbhtXzFqRl1Koh92k7QqYklbJIuEEcuPT61s4SqJz8wiwz/n b8nsWeAF43OcRfj79iOOkN8TUI7TPW9plhhrAkLr1aY7D5nvXGad0iEL6ndQPm5s77JBYLv7kGM5 7rBOy7PF1sH9wvJa9+r5690ri9w5ybEYu9jRfoHt6R6K3AHWnWWYuwvTdjn2P+4fhTiVGo/NcK3X ItZa/daFio5UuJuzn/C0EoIu219eOaWCoY5AudHGanOGPYt1U5/i+uVMwPGu0z8vkAyiTCp7Huvh v4hX0+udCkkYjTKKUGkiKem5Zgif7/xBi4rPPMAY5CiTT+hSYcMvyvrcNP0eMnXIKM9kZLdw5373 89/7g+7FZx7vNlGwZu6xM5Vdku/Ob8XF7eucj2b9PvmlJ7t/eO0fhBXtn/2zf969/c4vut9AgfuN V1/r/tMf/WH35ht/ETca7GEl81ovz3hbwDLmva7eJXrkvark7WG5db6Zsn2MX+vcHIraNQ6+/Z/+ 0T/qXvzyi5TFspOCv+zH4VDxgfLIQvnno8JTiTaSwMZVsgoKea1EFfiQPh8pa79SxdkcznLE87Xw +dxI6oZEDwofAE4IbI4AxCvlIekNbLwa3oq1ebT+gq+8aTz1OkRNB3juVxJC+AAszt4/DV5Yfq1P c1MRs8GfbJ8VPl1ndqB2ZaFMmGiwlGb46XyZkG1nMFGEmkI2rxPofKs0Fa5fN8FTMZNnkNbgTByT +PFbDAlTtCX+gos8T5WNgvj1PcsSEzwGbesPUYEOh00HrBwqVVJSdlRYjtZWuivPcDXOjzbY9ccp 5z1poUwN9XUGvZbTqhVnPPv6Ns++txek2NGw+QykXzzKc+0inz5P5S5G+x6V00pTFjnJVrMrJ0ss An+9EcYChKsmV89KMn5ONXsiS/bGcK2/YIZn9BUTLlV4pSllpOrb8FLUhD1gkN9lB+E+ppjF5SUW y69imeEIBmxtt7GS3cJq8wFXT91HAdvkYGQH/ysoYq9wFMXX1i52L3DEw0XCtrG23UJZuwHMMeuz lrhFYAFF5ghrzxHK3xIKggv34zomeO106BK7KmWgSpVKm6XQWKMtqpRppCP46xM9ROrpJewpAjBK r1KUMUqsQOLMMKN8Fbu3EvieccCgZNmz1IHUtgVVMTcbCC82N/dHesyAPrEdRj07lYqOG8q+67jC yupUI5WqPEi/NyBIs5s1fBfGjSjH8GOFqc37f/bD7uhf/5tu5gWuorq9zRqymW6DOcd1rpX6H//B 3+/WOQh3lk0J51hjpjwusdhfDXBj41537vzF7vvf/20Orj3fbW/e6978xdvd+5yJdp6L2r/z3e/R Lve7HzKVevPmzSDYWQytqC76D975MULYKpsX/t7v/m73jW99M3aRHlvH3G/qzlkpzloRxcBkXjO0 jqkiNtwJ2as0U/HBzT7k4X1Uv/fwluCvjHKb2LQ7TQSmZaXpaPuk0/HT+E73mcvY9UJcwXjbEDvz s5ydy9AgAMzOpg3pU4uUjiC/adocTsNuWSNB/0zuBC0WOryJqVKPyfysHCpdPW2oqeAYkvWTZUnF zNBS3up9zBvzLDqibspjgsBJBzOMcEnhtGVOuH7wz8KmrjqFR5ixawEmJS/5OEEnIG2YikfrP4md BD1M8qjNT2jjx6nkofU4hh3DfQ5/4aZAvsbAXYUzue/GkZ1xdtGo2EaMyCKU9TFrV65059gxtv3x R2FRmGWQ0nA6KC3ixBXlPuvdcPOI6ZSiyzAjcEFfPHOgCNjwF8Q071PGTDlxmZeDK/lEskrLM7oB nlgewpMAPVyDA2a0n3bBs0l0vMWqCVD1ohZhbTlH4J/Le2LAOyVVldmnBxnL3aFZNJw2RgUhaJfn 0kqYg7UL1rW8uPjcgceavsuZYHe4JH2BHb+7WNIOWAx/i+nQdxm45eYC9fwU056vcsjtqxya+gRK yEV2OboL9AZpMQ5BDwvtwei0qheaz6OxujHBz8e0qvHEH1dboSx47IT0RLUAo5PvwVuelsF0oWDx 43FA8psSRGFCIcavU5lW8RNf8tE3XJRbRSx7ES1fxqikqVSlRVlA86WkMrPHGWEoSOI21QIF0aIW VrWgzrVwTB3y7vKIXfiF7hrr/Ty7zgN6d7F4eTSIipuWwwM0wPNennp7v/vR7/9B99Tf/3vdFgfQ 7nH/1fzBMjtAL3BEBocIs5NTMu5xM4C7Qc9xa8GXnn6amwfmu7fe/Hl3lSM1XnnlZW4c2ARms/v4 9t1uhU0Br3Nd1RPXuH0Epe8HP/hPcfWVa94+5WgPN3N4Tp4H4S5wGO8Lv/FK9/3vfgfauXmCO0Kd EGc7CYxAWUPpjl2c0OyHyxxTpPJHeQJNNHheU77wjttIrfXLWpSTxdR6GvZwukdHd5xRb+ObAwpU YSlnIy5/TcVVXD6nhWTqy7kBTBzTykwTPfXaZB+ieEyj9BT4Etw2R2FbfyFqO+jAx49fefkevwGa aaWr7dqAjR6rsMkDuyXSWRD/YIz/dPkLbkAijywsg61p0pmzjbR10uif5fJPXo9dxhuaaQukz4J0 SXeldYBvXaxh69Mm/XbxA5Z4yzzkgWVzMLJrN7/MM37jCh4xQ3NlrhdX9eK7uEwXO4en4gjrcQY+ voqnXeY1CRv7JzG+BQmCDINAwff1CBnHjBhpwSoapa3KJhZ50ThQJJYeV7GpBxkGIDJPFlCnwPje p4jyl5wZHupR3xlHHRMWaE0gHiBm4e0R018XOLzzPtOhM1yls8Rg7dEPwu5XGt4VS3kcz8oVv5hE aYJ8mjLplPOhYGRMjK5RF+YfwCYUyuT+y0D9EaIXOct1halyykUvrTZXafE5yHePM9OLo3V9JEHj eGNKzAYogOKdZ8APEYkz5W2CP/ky8Q/0N0HZRFAT+kZjGl2ljbPI8EfdkqkSFWuSoCSOTtDKjmah PHg8Bpf/hEKxwyaBQxUfLie/MrvUnTu81/1i/163BYJLuwzoWNN24NlHM9Qs6Z5iTdVTWH6+s34V a9pat4bmIQ2fcqvLTRS+exCqMjIffU9asPK6WxDS0I+i7QPEOxNy7JrERoVi49o4NzJYJ7qsU5XQ lJOakhPCYzSMzzVrIRrhjz6J+HnaqRAlHTY3scrDCIOG6lHs3lQm5Jc4dcq/x9eYTvuTib3vc2KJ tF93kX7Csicy5NsNBEqXztK5OcOm6w5brg6F50wFk0jFzYX/Tj9GObnI/t6HpPjRW931r7N2zR3W JL3L4cGf3LoRuzrtM+f4QFrhmI/v/a3fjmM4VjkWZJnjN8i82+aS9Y85ONdpTqdo9zY+7d75yQ+7 te4r3cvPP9tdWOUGBqa2d7CS/st/9XuyvFtHofvv/tvf4Ry16xyo+wSbH7iC69NPsILCYxTzRT9k YqMF2ykcy/jnWOn5eB7/EXeJUh5bV9ufzkGTbTRFlYL0PCmYkOGMDF49zD+PLGu/ZO1NBCQRlFJw El02qEn42E9MBFV4PSsFAqgMDo74BsRXO4bYrtMrbDHoIaA5aDXAA47RC4UZxNyCneJOKmfTQHYE wZPCJJpRI7FLC0d4NabCEh1JefrneKAZRU95i0XirbrwedIKNpUsSEyqHsCDYIy8JB2ACavHP7vd L+aybkgT+MSWGONpmC7qoDwZdPK30p2MGUIGkMhsCM6XjAylcYArkMp7Ol0Obg1wVngkqhRBuyDE ObDm4BUBAadyHB8ssC7qivIHxj5NvCekSIJNGgSOGMSXr1/uVq9f7Xbf+yCmilQGHNQZZQcuRlLT EZzkidH6i1bSwEEAQEl3yuMEi+n7mMDjdBiwoBJGC4dliKFDRcFwpniUN3Mzxn/llHutG01QRX2h Z/HzQYnMMUs5DZEl6cPwiKd1U/FEyBXD6k/YwEu6gOUnUPQAWqDkR6g/DKiuYdJ2tQNv7qPMbLtD k4NXnY68vHoe4LnufTYN7DPQO+V3n2lPTsVFaUEROGKQp75fY9rzW5cf754+mu+e5fqkdZQMFeLb 4PrEi8o5R4wJtiCEHKEQjUCinGrDRf3rJc5g6WPMNybr1vowWYRk+XpvKJnRsivA0vOeeHyNjEJ+ Q5bxq+C5u9GDlE2mcuWzbqgJVIFD+Ze/4gDOP9IGRtpGhqmsTSSo5MrYaE/g8SDfsk4uWpZQZHhK RByYHahQuuSA/6gRzG9u5pjhWq73/+uPu9VLj3WHbN6ZvcCxJ6wVnHeNmWvQpAecC9SBh++eWzvX nePmATdmeNCsNwXMsAt0GSuZF7G78/Nd1rWpoF29drk7d87wS2HBXGEadfM+116Bz0vhv/zii9QD 7Yk698gP+bTdK2Rk2M0ushOUdap1PIm3cy+CX4ufSpvWUYub/Twy53Ed+AmJ/+IzrlzUD/42rOIe tucjZe0vtcYQGnv2wWW3MnjrxZYcQpYNvILzWd9PbehEGPsuoY0MwZwMNtnwWoBfRnAb+W9RTb1X I6+8pyI/h2ecbhhUhuIOLxNsBvEXnG2IpL/BnTZ0TZLmm51T1pGo7NbGLnIF94S+whsxZE6azLBP 2oePETWxmUvllbitl0keD0j8OYOjHIU+nifl4HOiGsBE86CStXUV8gWgz4C3XnzhGdalxi/OUEL6 XAKMwHgS5k65HdYgeVDqPBaba6y1eefWzW7rPgd0Mri53iXXS/YIfJDeTtsqUS4ijz7ad5WsoA0Y KYzBUFqly3ieVQ8VprUjI0mbI0JPd1rSMjKynpTHzHSJNt9/xd9C+SA0RXfFn/D3fKl4KZ4SXSKs D9PFn/4hLFMtYt4LOoTr40Jxhm+sHuNqp6OwpG2zvnCbtUgqccsMwGssalch+JT7It882u42HPSp i13y4v4CNgcAh3L3FBawvzt7vnvxcIm7NbmpiEycCt8kzmul7qGwqaiFBSxJil8tMjoV8yh3aJHI AvXlBejWtUq36lTQH9D9T/GFthzyQbAWLy1YhmgNFm+lxRv4xBt8Cj89TvGE2PgPDcGjIRutdJOM lc9QwMSGMhrWSqIFkQ77sKQcP4gMByp2u6r0mf8yge5yXSC9F7u7Y3YJc5a3PWhZ04lrByPaHu1o gR0Hyyi/mz97u7vKLs8Pua5rhZsj/JDy/k1vKHB3p8dtbN251929wd2qTF97uG2ecWb7mu1eee11 Nh78Zqxr8y5QD8w9ZB3hzg4bQziLzWnvQ9rsLIrdNgriux980F17/Alwc+0Xf/JTHs/RtrSgzais QcfiItPl8+4OtaRYCIlzM4O0eWRI1Cdh1re8t42Gcgu8u36tsQqPsltZfwPcI2Xtl6zEbAKTxMrI 6TIxLSghS5NkvNlI7WCm4SYghE9FTXki/edTSiYYfatByPfo2HzBtUKeIZ/v14ZnZ/PLpo+8o1s7 PT/ZkytATsbH6pOIz4Zb/Mg66QfZIVkpWhlgPcrRqfqc8ghnl4GjolpeTVKZ4EQiU4SrNPI869pg 4StnOxfDjM885OWZrpI/CIj4yZAE3gfBnRE+zSmpE+N0xlGCHrl1lF+yILWg/ul8lN/y9Vii0AFD Z9uDBnz85CAm5/2a9ovfznn5/IXu2tPPdB//5CdYahigYuonMhhoCwqRRy0x4SpvPEKKM6ZaCM+U +UtE8N8080756NcTeCZKmeuLzMPIePLatmvfAyLKljgKzmS/kguCTsdgHiVrBdFTWl6G/ml3Ep54 6acQgY9f07Tlm8N64/dNhEOPU2xOBnq0igen3mWachdFzWnNc9yJuc6GgBmsI1tAvb290b3PWqfb wN8hg3tuBmAXwDJWn7W94+6lhbXu9QtPdN9hWf0qy5hUbLjOnOul9ro7h5zxhRJygDz4rz1TKxTo pmhRLrUbXAz6fd90gDVPerV0qiioyyQUgC1vjY8+mXwCRn4ou1nuUJyANx+TGe5z8g486XsJjHhh sh9LwEhDQLR1+09oMyxczHcj3OHMI+l13WVOm2a+5sehGSh0WvbS2uaBu8tkvA8sBshQsLT43YNv 7g51+nKWC47vvX+jW+Xg4SeefqLb5c4rD9Pd3Nnv7vOn8rPCAbdra+dDSdzhuI5dlGRvMXBKcn19 naujtKKdizVrS2wUkZmu79tk88GHH37Qvf/+eyhyq9xq4F2nXfcXP/kpH13sBOXWgrXVFaZZl7s1 1sl5v6jLeOwjvOfUzRHHKGdxFkjPXy9md92bh/VKmzctuCEh7ozlOY+SquEUKYw6yL4227ksHMu5 YQ+be6SsfYEay26LBNGiEK6hZYnEr7lEhsxlAzS0/7LJmIqvZh3y2afLxBMcwuCiw+nfI8BOwPDs sCTCfwT09CSe05Sx08ICZaCb5BEdkIVoXNFVQaPoCFZhS1ddVPrafIN4ElfjaeNi3QXZVsmi1fkT pFQ5Lfo0bXH7A1lZcr9MA0OAmE91eIYLkzQmjsTjFEGC+zumnaG98gsmkEEmC3wjTx929qPQ1Y5H oQ2r9WP6iz++lxvoICB5nYQYfgK+MqnEkUbm0Mn3caVgC3JqnRsRXI2X/i0YnAH8tspZ0AFJQhSL zKr1x3BkpDSLJQCzVoY0xCgDUVMALbgFDj/DDI/57rFnnu9uvfuBq6C7lYP57j7WAsalyChS8h57 /QyLsoKtngYxMMQho+BTD6Pv5y+nz4iecpGMkPqYkuYY4If8CjxKEx5pkfZU77IcltYyfRF3ok5N 3KCIHCfZBuqRd+BL5SvOKZixH0DjCyqsQDKh4HxlYJQHrgdy1s3F7FrU9lCoVNJ2YeUyA/1lBuIV pjEP2RBwa5d1TljFPj5mtyd92iZXQW0wgm+zDXIBJe8S06DfWrnYfXf9se6ZpfPd0s4d8GNVYafi p6x1u32wG5egH1B3IXPkXwqadZt/k7arImd7CitUyA10A3fg7kxp511oyxkL/vty87An9xHxbkwQ xjBD/VNedIYkpNViDVPrBBitDGSdZ39TcPp8j7qVkBBc+6hE6m90+T3mDCUQv+n80NC6FeXlXVj7 P/MyTimODQW82WxU4JRt6ZulMNwCCr+xGPKcQwG6/9M3uue/+lz3KesDVbQ3uazdp7t1d+HhkZfC o9zNLaE8zy0H7/3Q8bDbTz69yS0Fd7keajVuKFhkunqf6e17hN1n48A+9f788893W9d3sLphrUMp u8WGg52dLa6zOtddvnRRarGkcdUV9TyLFc7y+KGU054etpLlVda0mrlpwbwtvzcrqDhq0RNHrF9j ALB+SiYmR4dMOEmmD6V7pKydUW1+KbZOIdXZaGgxir9v0fjjhR9kaMpNFJg2WAWg9ed7tN1ofNNx kd90EL4EFE0uFI+XpKWnswS27fQN+8t2bZlPsxAVPdLi+xSdFlYSiStaJ+WfvFWcZZl0mX1d2OLp BE8rauVtuun4z8uXFm+mCVqi0xWr9DzYWcfmO8nNAP9XyOmp7XRK/gK7SHretWVqc255JFEJl/gr v6yrB8hjlKTo6jFH8sIRbB4oF8KYjM0ytn4Bk4akPRPyrtfEvgZzMiyDULusS9Y5eSviPorZ0dpi d+G5F7q7f/GTbg7rjevZElcOsOIK9vSj6hyDjSfeW+Ya6MWtm/CIPE9x1pdO5cQ8kk5hU+r66Iys kveJHDRzEDW6z5vXcg+qt4ofPyd5TWJa2Te0EcMAClKaoulv8QR8GyCOpmwRRSLhfJdfXv2kX57s e7wGypTTZPLH64aeXHR9k5eVH3EEx3Z3h5sHPkXZuissg/N9wrl0CCTs7OSmgReA/VurV7tvspHg IjsEFljItsOl3cyIdbeYUjPdDvnGsQ70u65zi8x6eiZ1aPjE+eFmfbvpIboESuCgH1OavgOaZfU3 y+dTJduneaRCF56w8lHEPs4wFQhq2ECc0DN+HOI3PxXdPmp4WubgJc9Y/F7pfEJn2W9TWiMQ2SeN 6fCaliKFCzyC9H/SE+kAzDCXDti/EkPYCrzTvwCNTiGvUw8f/vQn3fwbL3RXv/F9lg2yU3bucuy0 VXZjGhPl6Aily+2mrh1bReFaZrOAVi0V4urrvVbKj6nFpfXu8cdYB4dCb9w+FjKvdtWa5xaQeba2 hpXceqHZOt2qYuaO0XkUrkUsZyphrk/TIirhYUkE3n9qo7njU4s757pBX5aP2xOQwy2sfzFNSp9Q GzXsN6f6zmTfQ/f7aDfoGVWmELQum+4kZBw/iVHG/Pqh6YxwCBM7Jwkf48s44wXyvw07fo2auIj3 J53w5cvdjRXzcD3tjKocvp/q7AX9C8iCTsgp35SnxfRAzC3Qr/R+1iDswGLHOeWiOKPAEVD7hSj+ GBjo4OI9cI7Sm0Eb1ONTVpI+O/9UlEthm06gz38TF4OifK3A4LGeSWBkIz09kP4os37+h9UiAyOd 9FRVOrWmJSAaAJ29CpamLwfVGdYxHbBzzTU39Pvd+W9+tbt173a39eGnWAnyo8qBOaZTgO8/r33r BxUy4r+cKx7Y+YdfmCAiwB/wI2wUoX9OyhgJQiYzac/qDDZNZt3zPWH8PUtOTouv/AuDfpCUN56h xzQh4zzKalQg43jDIx/rpRxyVnXoQHuPNWkHLOzeZ0G51hNJ0JLm0Q8O6Me7R90dFo/fYL3aR9zh eQvtapMj9x3zj9nd6Ro1L2p/mrr96sI5rGlXupfm17rz3EbARBtKg1N2s9091rbdw1K3AwMPVchx kpW2ypDeCHvQj1Nv2mYcvJn7DKuaA73Kvda0UsQsbylxll4lVBmRV1rn/Fd8Fdb6LBfHwegJuORT xAEjfv/CNWlCSYMHJX01TsjjOMbDON4jCTyK3PFoHjAsrl3q37NtmAMxQVgvlxDa29MizulJJhsB kymUHaVJ1XDWevxPf9p96fu/282eW2NKmiuhiD/yvJBoKCZBuYN/cYQGvFTxCVpViORt5JC3EizQ Zuewks3FFIdxtF8atnxy56fpDsnzCA3uiLqVv0sobAtY7tyo4A5q8VvbmdpyyfV0GsCTX5ST8HXP gaNcXm1lH3nApfTeU+r7PjuGre+kdaiJQvXQPR9Z1s6oslm++Fqn7LZu7G/jfA+F7QEykgJHlzGR w0ieOPuG2jeEEUjCkbBO0452QaiKmoJ5WgcciR6CnyrriNVJeQyIQhAbAAU9LlifOuDHcQ9KM4b7 Ffx0ECdc1EuFnkbDqMQjwbBeW+cAEn0vjIjhZAQfsEM2pI14ceRAoIwEDkJSZqR5Wljt+wsm8JnW l/iJ7BNvHzjIHX4l2EGpB00/6XV+gJBp4PGhP+5ORN7jiaLGqB+d9xHPI9a3LC+f71Y4lPN4HavN +iLHOBx0S+tL3Z/8H/+iu3Z3G/xQahnBZccdI24Vh7BoUZGlGfZ09EXRJx1nOUuSqQTmL3Bkogm2 jMr4xBa4BY8kA4aIHPiVoCd+x/HWx1iyputnKNqA6wSOSSkSBpKmcJBH1A+xRW0pF/sMrloyPsXq scsUmtNSqyxGP4e1ZYlF5Fpi7nJ59w3WN92F0vu0g7u0QRWuO9SXljankz11/3ku8v7u+rXuW8sX uuusz1qmzve5Lso1TbObu3F11CaL0r1gzB2e6hgz3iEFc8NiVcQNJT35Yu2EYoFcxQ5V6JMfJvVX WlJJS2QRw6vprN5cmwhMD29C60CATMG73vL44gc6YQb5nJVwOZNeFQAAQABJREFU8+LXABWo+Kgg xLxrt2hkKKSAEY5yFHKLAgIOeZ0yrIqVDlsm+NJK1gcNj8gPYgMfCQ4Zy5aoD5XXA+7u3JGz4H/M ozveere7+8ab3Vf/9ve7PY5V2UDBnlnFeubUomOKeYswLGm8940lZSuoinxV6JRQNzkI4hSlDDv2 KBfyjWu1qIulUBSpZ5BmW9VmisU06LN8WNPIN8tPerXn4KDwWi7hh3QZSp1ax+aJKY11dtyGSuZR z9DttKl/9bFLkofWTWsjD20x/nIIj/UaDepeRoeQsX+IaF7y/LE2QLHtv5YMVuJOcSmM0eROBWma iKLdC2i0c7DZWLKh2lhbOhXiamyTbBN24j/tzS+U6iZOi/+ssGpwE7i++yGA/P3tleOT9PVpNL3Y a1QnRMHG7BNnBWbZxxCmyXIUbwpL6VgRbzL/zKvPvh7Z+ehL3D22ij7lOaEhOzhAInMxZEbjPKJz bDBZh4HF+jPcwctn/Phi56WHvwqjk4swE1OO+AthEMBdY8SbEV6HFHpL3rO82h2o8UzC0ymJ4IuE kk7ydV6sbB7DP8P9CifE/0fWqUoYeI/oVA9glp32kR06X+GHTIEc87fAAuV5Lu5eWuM0e7b+z+M3 bJbpsF0GjbquZp90ewz8c0cL3ZXf+mZ39OM3upk//iF0svCcTvyYztw7EdNCgQIAfMi8ZYU2yYvS Bx+y3OHvy2OZTnPDpgIw1PBbSWStmJUD+dJ7A028G85LP2RHuD+VfggYvYTSVIzu4cdpxv7J6qcR MrxJl0vR+3ferH8HY0vlWWleCXSEhUv2yK8jeLqHJcRF/lsMjNusZbrNmWj7rP1aX1vuFs6toKQd d7e2NroNFqjfIfwma6N2wLVP+D3q45Zp+ZM/V1AXvryw3v3t8+e6l1ibdpW5TrYfgBcL3cpCdzcW uW+h5Mkzr/YOyXTkHwqkxMmbKM9QFl5owJYtLGI8vZLJMM9K26ccrqvzQF9xitVDdKPWogKz/gIB cXLIYO+2Fad/uqhDPTJIB95y0bYrvK+3yKkIBVCYUBCHZ+JQMYlMIr0lVG6FD0riJdBEfln2zIrQ yjMIybTZh5rYMjpCqNolIdrUVmh7ociyjGCVWx0+/D//Vbf8tS93iy883a0er3E0CootCxJVqPbZ BOLl6rGxBJRa0xwL5LN1moYHwiDW9uf0o4YK19aFpQwcoSxZGAQ0zkxzmpP+wM1DLuMJvpDW9XLu Ds0z8qhL/KadQxGzHLEjVTy8W7Yj0oTDK44FyrLENK3Hf+g3L/N5pKwlm/7G/n4eZW2qncCJkKOG I+N4m0t29wV0ur5sc3RwjMZQoP0zmxwe+4nIwMYxASpFrUJiQMaj8OrqGR5+Ugkzp9aN/aZTYUv4 Nj9TjcvZYhre7f2nnM0vS+PvA5W0IQ1Q9KCFRQ75JVsuwntCCibWPRQAz8yNlx5gUEArQR8VuA2j MylYfOFqsfngD6aU75TnmDkyL/LLskS5m/xPwRD129abi6vlXsgApTKL6Kblh7jgtY98NT7z0l+O tfnhElJe9rwNnpJG5Rhao9pkHH/JbX7NkL9QvIgSh/TFEReEm59/235IsN1+RguZ1rJ1jm/gq30J hWyRhcmzXCE0S+dq/Bzb+eNKHTLcY2zeMU/KaZjOg0mHM6lYzHyPTvyl3/3d7uZ/fiNayv7+FlcK YbmRDoiND31H3MATKIIf+cZvMKMv3xD4gBdwVBntF+K9B40s/CnmNk9fzd6/Cu6TZeDg8UWoxikn lKec6cc4xv5SVCpN1EPvEd10HllntatS+fH90DbGdPMOI6tK1AED4taOJ16xJg0L2ipTnhvszLyP 4nCwe7+b3drn9gHWo0HrXaa6tshom8H+rhY1lOhN6tK7OZ/EwvK3Vlibdu5q9yTqm9ZRJr4ok+dn LXYb3ge6f59pVhQ7FrNLq7InCzyIOuQweMTATViwp+eZ7Tin8yMVFjoOWkVuXDvlcK6c7jNw22XK BnFGeU0PIuXaAb3amNOkxJBx8shX44Qp2TasnHH+hTUpAtOf9ZFtwYx5C4tWTM8BZzksmPSIV254 TI0uy8tLT3D4eTc2bFXA5z/xTrvwixRnq05/jjzimUMLFY8fQR4SfO69t7o3/u3vdS8+/j+zuO0q mwmW4BnK0QxWNupZRT6JJRFEi9qjc9JJIOU1HxQtI12jVk6+OH3pPRNaX/e1mPa0CWN8OOHAcQBt 8sIp9012Dt/duNvdvXM3Dtm1HO5Itb4X+IhTEYvdviqfhK3ysXeBWxT8W0JOY9coMOJ72N2Eow97 Sf6a6C85e3D2JdAFMfafIkT9YFkpkN9p1yZxQP0MNzSGB8LRSIaeoYAmX4yGTMppftNxxg9Kj54H udNojbLwY6/VlutBOD4jfFzWsX/caKuDb9Fmxy9PcvBq4wiM8DZsnEcb5zvdzlRQ8JI6zaKTB0rw CfcZncth3TkbcNllR6dMPerTInLkSmxkKdnayIkEkG5niSf/NUD4wW5n4NqSFAV36UlVdnQz7NDK 62+ofeDjvCpgwzpBZ3jMGUkuUD7iUMtZLGQLWsiWma5cvxz3P+pfQEmbYW3KDIPRIX8OZDGKQqGW q30zhsy8jcNy4AwiQx4xQBlkkfdcyM3C8ytPPtYdf+/17q0f/N/dBaZ0YgULcaxbhweZNk+fF8PE nZCDSdSpb9ZxUkH0pDE0sDFUBc1DTj2fSz6G9E2qs14rXcHYRAbcfeAJnEFnpUh4kjWOhWMwxpMh xGUVH/cDrPlhC8EGwyCJMrbFmVkO5FbLOlbOCwso2cjTz1nIvYsF7C6bBmK6msXn3jKhBB1xVoRX QW0gVHeYttxDti9goXmRGwu+zwXsX1291F1mEF7yNgFG8EOmxDgSt9vY32TH6A67RDmXDYXviLp1 EXscr4GCBDB0jEtvUULqkeGc4rSsWqnqeIu4VJwCHIAPpNHNFBZsNmHlIslEYdDTOPG1shLWKAWw D7et6ayHkBFoFL6sOe4mTdp7PKYFRouTT6Oj6yM88vI3ymtTIEz4XikyXmd9VL4Z8lm/4mlppL7g fSiStnf+caRd9/4f/Ifupd/6Xnf01XNYwGmj/O2i9Dp1KrTtSBqkKWQFOosfVeaixHgVV586n6FY gbOU4oozrX9uMoipT4nt3QpLIK5euxpKnopXWcgqPxW3wmvY2JlHpRnHPWz+R8rar1BjvRxOYTgh LzFf34CckCe/kUaub+DRMmzJJ9xpYSeAhoCgs1EIfplNCKWMWb5UZmIkH/L47BdpPqusX6xMD8pv rPiMrWDjBn1aHTqElcJ2Mh862FHRxzhJPJ1snElfp3YkI8ghXXbjg/fES3R0kZif6O0dLCEsZCet DA69OcVlPryrCeF8mn7B7Xb67bD5i+MsUKgdDHSHKGixK4x3FR+nko6cVmCKYRZL2CxTDosra93y OorZhXWsZljKWFN2xLqX42XiSb9L5yy6PTpir7/Ja2/o7Mlavs3FVzsAxOl36M3jVtJv4igrIESG y84eaVqa52qdo+7xv/ed7me/eLPrPtrojlnvxGkRTJ0CShkX3aTIiBk3HfTlGteXwX2VZAan/Ba/ fUbdjOu4TyMuowALOBVheRj1UIw9BX8ERZo2Ul60/qjhqYCBN31o6x8lDf4pB7qQCOhk0iksl1qf nO7cYb3SptYUDk1doe+6zMn2a1hA56hrr4365N4Guzu5suhoL9akxZSeirwWOawmuyhFN9g8sEMO yyhpT2JPeXXxXPfNtcvdM/OL3SoKYCzvJ0PFb4sPig13inIv6I4KF9ZVCz3Q3jNTf1/9kn/CZTx8 hg6taQsoI/OknUcp8gqm4KPKX6UkwT6Kpy1Anom7ybWHEqt/5p3ySAvo5TSpyZ2JiSMAhbW++acS UYqXft2UCAA35MCL6YIe0/IXu1h5qjy3LqdMC2Mb86B3y28GRVtyIansy0GdX7x1v3vzn/1+9/yX HuuOuBbqAGunlreFI9q8bX8+y17KVptbtakoO+XQVVjByY+yPBpXSlTBBTesC+KGsOa9ZFs8vitv Nd3ZxlXa4D+ZG1fxRcvD+Hy0G/RXrbW2l1dGW7+4w0p2MpMSqLEyMYFEdGlfdiMp+pMYw1vXt402 aOo94hs6Ku8poOg2bCQV2maS4aWwFUTrP4umbCggblH2SJIWM7W8pwBUZkJMiBtCx8pZRbS0VZjP cR6n4xRy0kGOcY1xCN3iMb71G/9F3cmBYzoPrU1WVrJE3uJH9qLD6xWgeeo8uv9eJqVJDgtqzDIn meu0ZMWaMkIPUZoYZWIB7yaWsRm30vN1O8/fuXPrYTHzfdEwFpc73eFGF9ei0aczAKOQ8X7IgEkW xDVf1+QV8BAgj6TFaRPGAwD9D98ikHKgEefABhKdD2FEC3121F59Y5n2nr7WPfmt3+zu//4PuuMd wllA7VojuRFOnBa6d5V3AxH0VPwDnz2OwNS8J2bVoJ7+HkFPMr4o2Qm0PXUWK+irhf0DIBFaHMv5 ZrW3biyLkzyB0hN1nryudH4/GnJE3amkee2Tl37vsntuF6sYK9E5I221uz6z0p2f4ewsmH4Da9r7 3DrwCRPbt6mz+6RT0Tum0p32jGM5kLs9rGkq9Uxud6/Nr3ff40iOryyudxcJm0OJO+ZPBW9mZrnb pWy3OXvNM9R2Y7qSNUwoVCq2ym0M7soPZYiwXo4tR/CO8HgPOScM3qhULFKuZfs7yuU6Ru8BjbtA e8u+cFq8XG8pO/0LjpBvvkcAedgHDLERWPwuyGrn0bZIrwuYJA0cgxTGW6RrM8kUUU/KqCiOsTzG p5WEWkbbEq4wFc4h7ymqA3Tqx+x6cgKH76a1D/C/zxmU5VX6g5s/+NPuqb/73W7+yoXuAMXZsLCr cV9rzb6Ytv4qo1K8ao3Y2KpWcPWUR8JEmSQDnK5P80PNuOJzKVzCVh4Vp6XNd9OWK5gKa3EVzMP6 fGRZO6PmWkFo5GGSIjoPv4V617aKCmsGfYMESRdNZUrQKiafE8jp8LFvIqjjmPKX4D7In+EKvW82 xIKsp3FNOftgFSXDT8InwMk0bZkqn2yYds8PRFRkjJ7VaNvgtqztewvzed7tNCcuy6k/O5cTDBo6 DfO0Qy7ZOQkZSBLPJIMTb1PZD7GEBrO9Bic7utzRBgAKjNYp7Ar89bnGPCB+06iQARbx+K2bHeBm 6ZBnWDPWYaVaPI91TEUMpUxl7LyWMhb/uyuMA5FCkVMJ2qPj3HPqTMWu8urf5I+0R4wvLBzz3Vcl yNiaGsILTpQGAITR5XgsdKYJi1SJnsH8CSOf6dZJyxQXU6rPfPPr3Q//68+67d2P4b2DnfkxAJC2 VXjEq4v6ibfMeaKaR+CJn4E+BaP3JJUJap1XxPAWcOmzClp4U6WsJC3W62QTQ+Hk2STytfEGUOs3 u560AS4sX/Co0nrWlfJgrRyyS04lbX/Pa4G0SM11F7lt4CLHN6xgVZnnzLM7TDPdjmM4trsb2Hju MZje5GgHlfJZLGeH+zNY2Pa7u1jktuH1IXHX0da/jqL236xe716aZScvU/aHzKk7Lb+MAM2jNO1A 0wb3hd4nLqyuLhRHppTneSpNcbaO6mMsytk0SnmnLqMs9KoNcsW0HGHYfXmn9qExLzZHeQ/epCwK IyqnQXW8Dq59j7Y+FZt1NgDzcloflHSTFzSGFaxPkLghuCopwg2dBAQM6QxKGe4T9w9lWut0fN9Q +KAxwacBG19ATbJoYswmE6/B833qcJlD9H78z3+/+82vfrlbubbYLbOR5z6cOqTRRs8i30d/Iqww y54fUn4G2O04PmSa4ktE8KNiVXHxVCpHsJXGp3GVRhwFW/h8lnJnnO40mIh4CH8eKWtnVNohHZOG 89z9kg38DPDTo+xRBse39+DNl5SpB7SkSCfcZ8XbdH89rr6eprGdlX9CnlTMpjHYJU7j1p8dZTRI TAYzDBCtM/wsVw2yhalGbdhnpW/T1fvpOI1Nhc1h7zSyTFf5CTP4+06j8PuUmwXbhg/v4jqF5SUJ ojyic3Vgi4GXL+84O4rBKaYtAWDYggpGPJVszy9C6ZphfdA8FzIvc9RC7La8dIEng/LaWje3wr1+ KGROQx0xaHrwqbpYbNCgw9V6Bgfotslb+niXRuuURwySKmHkFpVqGEDE5YCoP8J8jquViHGQfuFU 5NKygp/3SEsFxD/8oYwwEi9wGvqz3/tm9/N//Ydddzcm94KWoBW401zKijEiPg2iCRsT2ES1r0O9 AT+g5MXk0ty6qDuFSUAeKkwtRMpZG9Kmzvc2hZAYksL5riFJa59BfTAWLA4nRUE74HiNQ6/0YY2Z 09/rnGC/imysYJVaRHG6D8wH+/e6T1m75uXpW1h7vLqI5WkcbEs65Qq6d5j2VFnTe4581ljh9HdW LnTfYW3ak1jllojb5zqpXfR9PzBmWUw4s3vYcY49OFlozpT5IUpflJLKLlq9ekmNrdqJSoX1Xy5l KEsfaaOkKa9pC0r5PECx2eXvgARz7EyGTKZHE4vHRmTa9I/bvtibLCvrqWfRV4GFI2XL8pyNQ3lp IcxPi5/OX1jDUwh5lHWpwsZr8L9onCpHDyuOcsJNObwVopy503MP5izQR9x846fdu7SjF/7B/9Ad UHcHTIUfahntpcgyqhT515bf8PavjswonpQi1dLRwltCy9+GFf6ymIU1rhcE4Sq+cLZ5jOMK5mF9 PpTK2l9VJZTQZKd5WhXb9BWv1rX+6nom8XWURwilyU+kn8Dmm0DVrMZx+tv8Tov/nGH2foGKn18C ZX0BV24nlTe6Czruwdm79xlNK3EDxImGOImZvFlHY5fyIe9Pc8H00yKGsNNxGp04jzXXtK4noTqP 6hjL34JO3k/SPcSNBu0KrxRKwyEKmIO7ytMhFhEtHQfuumTa0l2Vs8soYGsXu+W1FY7DYPoSKxmH ELHr0vVmKMXAHGBBsQoOmIeMaUy647qjz0HmmCmxKLEZ8uKAocUivuqDKDrXfmAJL7hKUqUrq+aU eqiCCMNolQNvn7aJy5SUizAVR5bMBH6tbTo7d0O8WHwHq83111/u3vzzP+v2t9kVyp2HThXnPZKk L8Ii5a//p9A35AfvBiknonZdVu41ACmv/nmsROFJmJKk9Im7eGVIwI7mRSu9T/kXSrbTgSgs5ucO 2h2mO49Zn7aM8rK+ysYBprPXWE/mfhTvf/zoaL+7wzVDN5me3EAZ20a+dpQvkHq35jHHPXh/o2Eb wO7C3BXiXuJj67fOPdZ9jY0IV/AvzSEFIoXSWabTbDdbpN9FEdzASqdVVzwqmHPOzSow4PRDxE+N 4AthwVP4E9OnYAtnAXE+VMiFcTBzY4HKmnxn5R3WIqyA/Llg3qnQOflsfpDm8TFnuUHxPgMo+5pp gApL+qfjxr5UT7IwQU1PUlEmSwIfT0sZEhF9ZzFgWkYCfyVuMiuamiDkg9xtf/EPrpFui7WIi2jk 7/3+v++e+cor3e5LL8RmIDua2GAgEE5Z8q/6Sp+toiTM2D+moVW8hK94n4VXHOX3Oc6z4EzfOmH9 +5vkHkpl7a+qAvgOVIKiQzg9T1p9NJyMVYzbBp5Ny84qXYg5wpfinmFnYU8Im9RZTnwtRFAxncDo NtPp2IkPOKdibMDTTion5ai4bLfQ5yc8Pe6YisDSN+4TfKTjtEOlSQdtcRTFGY2rKGrzKDp8RjZG ikNP4erzr/TukrQ02b2bu1SUL9/aAVHcFkw0Ec7TwSFdT41eIyuYAcfsp0kQlnwGROlXYCLZ8BSM EHgqlb6HdYngGJSQtxmnIbGEzHjyNyd4LzFlucbC/hmeC5x95R18BHKsPCdYhaWMb2KmCv1y9qyz 2v03KD3k5bsdY2wy5T124VGOKLx0QK4KT/BA0nExoEaXT3SCRPmUlBIhMbSuTyorwsV4zpvhBhXP Kr7CzbfeI6HcYaCXRDcRcHB5d29tofvy7/x295Ob/5K1a3ehlYku1lBF1ZgYV/SYT3I+Q06TeeH7 ZPHUEpZhkTjDCiYA/Umsmc5W0+cYUTnwZBy4oT/+wbBoYdkgQFFU1jOyjfyyAtIfv5WmD3JXpvit A6eJtYR5d+cuVqw9nttMCLpwfR3ZuIiStsoO2gXyc/3fFjcSfMqtA+9yEbvXR+0wBbpHRWo9c6OI 90ruKCBMc+5B+y6V5zQ2Gwm7l1bXu7+zeq37Bmd0XQCesyHMPU6+X0a+VMo2sdjd5hqDTfAf8YEA JmD4AHBnJAqcvDtS2KnUPCpCgGytMWBTsOIdMSFrKWdgoT+Js8AyeaRTufMQVVu8ikZVhSxLtgHc sDhxTwKiTloAM51yQAx1lRGFI6k2bJSHANNBQ5nMOcm0R89ePeSUPExmedKlVNlmrWct2iF1RXrA lQcAXitleHos9VBOtKCbi7vMtYB2H97s3vujP+muP/1Exx1TJOtbC7gLc7wRngsyKjSxRn0RF32K aflT0dKNlajym4PjgHkFvfwUH82L4MAjjlZJq/SGVx6+p+zE29+In0fK2pnVOFFAlP+xtciBv+08 Q1yVqMHRCPpuwSAFLptEAmQDauGHhMOL4p3fiUPQ1Iupp7JMMZ+CMWf/K+CtkBdQ0EGvl08RQmmj hAo3vhC9rhkpHK4bqQE6w+hQogPo6ROfHXHjoulGx2L/PB0XYH1c0S18m0c0ZAIiqWUj/gSWHkcC mR4sgSSaf6TINPmbGz6MS+cz/uQffyataYqIYJBI3hpn7eJCebXc+DIgsZiWf3aOikVGGUi6WGXP QMugFmcfoVzNaO1AITtkJ55Tla4jW+K5wHTVLoeKznqQLH+hkHHFC6uz43wsr2RKC1kO3EFS5J00 Zb5R20aRX9QE9DPI5ijWhxdMPmNNFQpQOVNpFW3rxDjxy6t0kVt5ssz6Kp7ozH0AGV4CDz6NMwOW gu/Tq0DOwbMtjg65u4ql6Pknu7UXn+t2b/+wm9eChOIQbTfkpFpSyoooEo0WQwao8FlDvEVExpq5 FioHBWl1gA4FoNITLn0esJ/rznpqDTctcTqHNdtJKBH4xREp4bnPvhoYsJQH4eMn0uaPmCb8l8jC XUC7yJJnpGlF2qbseygre0x3xkDPFOclevzzyNT6PNdDYYM6RIG7jzXtFhaVWyhqd8B/F35qidNy Kx4tVLsoWV4TtQeRGxC3AL+XUPCeQtF6AQvub6yc754/Xu7WMb8dhzXN8lh4FDUseJtYaW+5Rg2K D5iHZA9IVHzs0uU1ygEt6Jrad5EfVADTk5ftSP7I23JaTOPrAVpnUQI8f88apAnAV5REGYhz0XrA UQ5VnKENAxdH0fRwATz6kbsnOdwCSd+EJmMgw4rzrV76whmGMziiLFcmT0ojtoftQ4TDHStYuBiN CJNHAeEPftuAGYORiL4fN0HvpClYid8kwvm0tzKp7yppVskC8rKIRRV2dR/9x//SXf7a693c99hs oFWe9aez1JFT1PHBF3LKCEddzZLBIUr42NlmaswpK1nBqFhVfMV5wHIobABJd/T9JrBoPMoY2ipo Rg8OeWidacKdUc8F8v/35yNl7YwaKmVjABlVeAxUIe4JUYI/wMfLIC7hs0m1btrXxtQ7LfMz3Fhw q3FUMoU+so2XCp08p8Xb9u+gNg6dwPs2jQr1w85z5GJqNILtFmj9fkEPjm4wsiAcGAf8Ub83QPoS oCezINyOLEa7hJombOgoikfLeynyqWA4AFBS8NqZ6eJsssjNDo1cpSv+GesXOlacBUw5EQWfyG9W ZQskxYIoZeAFHrjIi44tBnn8B/Su+/rhh+eXcbpjKGZzWMkWsHYselHyed55xsGxKGccy80UJnD8 HZHGgTbOanK9GpQpmnbiMQbamRvA/xOu4c+UnABbPDINZJ6SPAo9jXKUR4tjGjB9U3meBjAO6+mV nsERNuTDe5Tbr3bKPcv9lM99m80GP3+n627uctF7pgz5NF2UalK6lB7qI0yK5tDk1AukRQzFwaf/ epqETTlK3pkyoqAl4GJkiVAikKZYm6XE+i9piVjolg4l07xUPqjc8EjC0C4M75U1ZamsOuZW5TpA +LxKaIvpyW2UMHcWLqPGXEI5uzDPekXMYPPSxaC4yVTnPTYZ3MKKdpPF5fe8hoh8vX3A86scOJ36 3EFBc2PBJk+VJHfbLjEV+gr3eX5t9WL3wtJadzGGfs5nW+ZEfCy/cyhJeQcna9xYH7eB1c7jPI6J M+8sKY9yUfBJG6quVkiS+b//8UV+wcFQ1IhRgeDfHEqgaJLDOW0bR8UAdzzUhbwSm09gh7rEM3Yg s/2e7czxNJfhnuJ/qiNfxxf7jKR6AiVNph5I46WlU/iBLAClse1ZJ5gmbwWfVBk+eYs4f3pBS/6w O/jWre6n//4/dC8/90Q388yTcdSJbIw7QoEPDNCGWp99m3JPxVUbr2dNXU6VATgVNONapS3S97S1 MmBekujmhdY5ldq6oD0KNAlt852EPnxvj5S1s+qspKWBOSWoif3s13Hj/WXOPGtzUS7tuFpXjaTC HFziq10FYegBKpYnLWEk301k/zoqeNNdJICjVrTe6aSZnUOT1oLphpb52tEyMAExpqH1n4J6yCjX y1E2QiYDKe8NzVXuo7CgyDGUHDonv9b9uk+LCFSOM4piNaUFdtYF1f6jzE69ZB8HYIzcrJPxImQY 7rSlF1Afc9/hMQrWDM85LyxGoZhDEXOx/xxrypy+nF1d62ZiTRlWNE7e9pDKGdPSGR3wdPrSk+V9 zng0AZdla4GADAsaWQe/DEIc4hqopvwyq3jge8sb/bo2PkOmf09LMw0hjhMhUwGfB8dUAj0jpEVn PXc0LTBizaFZeF3N4uOXu/Ovv9jd+uN73dou53rBByflZJaSKMuUOP3idhG39WV4OHnYC0KE9WWK DR2kt5qPsYQqsQ5U6AooDv6YMCQDXOSDN2j0CeKiN1KBQ6u7LVcrhs6HqXUqbLYLfROZVm4TOOSX eC2oyoU0eObXXawb+xxYq0K0gjKwqpLGAvFzPL2Gy4vStZLd92oolSisbxvgvA+xW+S1j3/fxeaU ZZ+yuVNzC+q3409r20z3LPEvrp1HUbvUvQjWS1juFki/j7Lk9V6piDJVCj33UBjv7e2Ay4JAL/Uz j6WtL7Kh4aLU/Min4AH5hkIafjg9koGcEpSxWW/eJRnTqeBQeRFfrFXDE8fIRFjWurH54WRun+XG lJ4NP56RGENXOaodRLGi8BPIiJPeCEda+rJXmgnkr+9N65jy48eomwlmkKPZfY5q+bP/t3vu//lK t3TxfLflRe/wzpsLXBeoXIb8R/+pdbr4O6HL8o7LXOUwXIWtrGqmauOML/+AkbDWqei1rmfZEGQb DaEaQh7el0fK2hl1V0JWICcEpyL656jNjWJ/Oa/NIZWZB6efFt/sqFroGJ5Co1CwpxuUNJt+Goci frI0bcg0vLmZooUwLF22L7rwtqE5qPXgllHKTk/d4+ARyR8A1G5wKJAsBR0zCeMPHFsLvakefjig mmlOjea7ypeWMssXg7LvEJoDBzVB5798hHWLSFfdeYfdoQM31/DEJdQoUrvn4HG/83IJJWyONR+z KGYLHCDrFKbTl24EcIrz2CMxUMg80f/AJ/S4G3MWy0hc8mzesoDO1LUh0qZxxfPQYjqVqNArqtAB e0pdBBIj08mPz5Lngv11Pn9d+WadKhNYfxhcZlmcNaclCGI3OZD36jde6+5wQfXMJmoaFqRY3B+i n4zKzwdLloOO69sypv+lXlM4zMPjSngCoSKQU4Q5xejOStdFWTdxrp1KQ6AAtlfgsv74jfzNU1wq Z+3Hi/U52bxhvO3C9aCiUwHXaraH3GacgyoQDLDewbmPwuTi/7vz+x0HsHRX55e7q1zJtYo8epbd LgjuHDMNiSXtPgrsPaxpG+S4BU3b5LAH1gMK5xq3bXBuEXeP6Uw3D1h+L+m+BC0XZle7v8vfU0x9 XuAjYo5Dbg9YNCV9C6xlW2Qb8R4M0Iq2QZzKWqyVpAzaQDyWY0bNEppaF2tWyb9nXZQxayJ5laVu UkgUAPaNonJHq2vxxFD9iTcjaAkktyxDj1D+yfmypvN6qssWfmrUEFg0DgGjl5PKm9RAd8jXCLj1 ilhCKU+103q2YF/kPfvnpDj52VIv3/LPzUaug5tn6nrx7l1uNvh33XNffqFbeOnF6Afto6y9XCvn Tlsta4TRL5aTVttmOf1Ffz3JLmD0q7Dpsl0rc/lnmPH6eYSr9C3+jBlYVl7SZPsZAh7il0fK2hes vEb+lKJBgB6ExkGhdWPRmY61aU6ccfrtfM52KegFM4Z2/UY2RCHAWpmCPBqwmVRL6JGM6aa1ACJ0 JOqhmkfTuJrQTBP5m60Z9Q4a7GgHB9HZrQ4hKCHEkyTJ7Yku2v8/9t68ybIbO/BD7pmVWVk7iywW ySquTfbGntY2kj1yeImwHeG/JvyHP4Q/myMm7LAjJI0ljbVY3VpCssI9Y3VLrV5IFmuv3F6u/v0O 7nkP7+bLfJVksbtTUci8DxfAwcEBcACce7ABlo12FMMBsKMzklJzQaM3b13+DudcgWNH45cgLwwQ nnSu7ZeigpeHhUYQkGou4itcLRfuKAPCC1qyQ6clFbwUxjhEdIH1ZPNozJYuqUFDQ+bdl4tMafJ+ yPqzuCRbLRkjW2j0SN50xGvnqfYx+IveUL0ZHjyWUc1T8o6dlAOkRpqjI4tcBWh9E1EFCbhJP5M6 u0lwZ/HrirmJEhXRuCErMjnmNeaYVK8CZDxtUeT0iYewLlJ/Lu1xV+wWwsLqK1fLja9/UB599rTM PmFpvBKtdazmB9s2IW8EBxLkfaJRXFFseIg/0uQd2A0AnVLbR8gZoJHa86JrIahPB5o4hFWhHfAU +2o28dCAI6qStIP46hv+1musU9MGpXSYdpgghR8FJ0I2XY+IUOYF1q7HiqlKpiSFN0+vc63TFTaX XMZmRpKk0JqhLXuIwPoY4ekRcTYRTLcpLM/Z8/7VPWjyHsZDhV0S3ySdxxCyERsI2KeCWuwGJfXR 8tXy7tr18vGAcgPwcI5pVuC8YkzJZx5hbR5p2WNfNhjot5hK5Rg2PixqG8q8tc2+y2XNKnVk3qN+ idfVSAXB3RrhxEdBRPkvoLmO/oJCV5iwdnbinT4AgdO+pmpGiWIlWR8twhPeg+eAjeQnCFiyVWtq nbc+9R0UnQmOSwc25ShfmsYIqAmvrxmWmiR5TqosIzFG+Gnxaw6GeI2nxq7LWZSXrOn3hbwYIfDJ CtPXgx/+uHz+V39brt98tRxybZwrSaLvlm4bnfxDf+QUZeZDu52irG225tP3gOvozzxFHrq8JJ4M yzjxIWRZARd10+Uo4/rxEqEADOtC+GH5D4vg3L28vMHgDFWWDHOGKGcGjU6IWM/TkYyQt1/o+o5z JuLICLR5C4YfBx2GTvKOxkFANvAh8HO92AH0O6peKj1nbBVv8tILPpaqZWY/XEuPF/6jQ4rGWhus A5hKRsHUoqlxmWOQNaJ+WwhhAzRe7rgMbZnryRDKPO5iCa2Ywtg+HdYSjxqzGewZpjL30ZAV15Ox wnk+VsSjYSBdB4Y4xZ+O/qATPk1LMbLSkLSQvnT58KN2IgCgKbvlWssd8finwQcT3Wv3FlZGr44v 8Gtn13Zyvwj+P4lM066db7Wrm3fqL0RyaPWeUjVrLlMbQPgrH35Qnv7wZ2X7P22WlX30LLBf5EGh oBZaFXJM1HoivoK5R2iE0I47jn5A3fSQKaE9hI9DhDXjKhh42v4SR6h4krrCv4NWoIpfftrCw8k4 EsZ6lw6n7eSE3FDgbK4sIhYfBQ73MmqMu0XETQJ8P+AgWyRHNK1otJhWXIEvL/K8cQBO8O6Q9v1Z D7HlaqidbaYiB6E5u8+5WdtEcrOA5aRwpkbNjQZqCeOeTmhSgycLMjlfbvJx8i3OTvvuyo1y82iR s9gU8+Bf4roZJpYDwPfy+xbEPUIodOen9WEZyL9myBI+ZL1bXf/X7wsim8MfwI11ulGysBxJwRPU LAvjWWLeHWteFJBt2UNcUc9dVQ09T0gGZGrfpFu+mAZ+ApbwlmdAcaIJvozQU4Ca2MIfI2haIk38 LBNyFr4DOM2a8k8veQ9xi48Ygje2yk/+9Hvl0rvvlbWP3mODyFJsOhHO89miW1Nj2mVQ2lLImqQx E64V5Np4SaJ+PsaPvBIQeM0j9Z5xYg2bsF1Em2E4pFtYPAg+vfC7uL/q1uRR/Fed6l8Qfe3Umkmq Uk3G0S0/9E0yUd//JHd/DVvAwaBnMS6wbk0wZ+PhFEbl2MazY2qtytfjuZmUD2E1NuO+URSbbpwI ac1xPG2o79mZVP9Ro+zDte6kJLFnPdp2WTgGTr+2O+GJ9TxqvQpTRgtoyfYuIJxxQOwC68oW0Iwt ckaZzyxHZSioeXH1zgpDA1/ynv+l5s0DN52WtEO3s8iBQ5qkwYHNnHjZtMUkGfkYHmUnLt6zaONd N3EV0vp1Osco0pbGCL7iEW8kq32SOcY3EauBpvRbxE3I6LUfZxRS36Yi6Ec45rbNJR31XTcPQoZf 0vK3Jewjq3uyvqPsDGfLXf74a2X7s5+X/XvbCEddhhNZFHaNu0uY8RX2fPeeyh00VltMGXrsBef8 R8EuIaAtI8wvwzMLzL8pKLjJZFJZt30FaElN7NYltPF4b2XWYmhIlQzgAgWMyA98FeuIQK9Wb5t0 uE2LaV3WfWEvc+jsJXh1nc0nqwiMiwhO89D6DGHpPusq75PeA4TU2DBgwjCnwp4aOhSDCGlMoZKQ 69N2xI+qyuM52JbBuWkL5QqFeXfuQvmAncfvoK27gkB3gUnTg2XWLZFvtrzEZ6DCnmvVNoj/kNiu cXNBv+ug5kjD41ksavupyCLdQPhJ0wkGMmt7OCG8lpRCs+VY69Wa7PSdsXaRk9widlzq7hv5FK/E +KawOdVYtzY+44YqbxQjaAh16cjvtDcFmKnTnxMQyEfZH2u3bUBhRl6RfwIm6e3hifxmvrHjL7JV C2HAByafqFGv8okHwptv/xSC93/8s/LJn/xFef/WK+Vo6WqsT1SY87uUzm+YWtKZQpbClO8KZ+Y/ hTjzoL/GOP1H/2w/wlW85AJ8icfwEPqwh+v6+GiwXsJYVvluuZxz81KzdkoFJrOMQOTM1oyLKMEk Q05p4U5+dyqmb2I3GB1NfmWfhrLGPgkiOzFSaJg1F08P0wVJSwU8jkmcNvPq1DYsQ/QeOvyCCYBx XCnYKSAdxeL+iDX2k00qt/GP8Nuhjly+maPqhcs8NQ3S5H3CLz736MgIV7CaoxHb6Ledslxk6pKd lwcMcnPrl7iA/CIL/b1i6UJZX2HAY72ZuzRjY4CHzzIIxmAOLgebA1T/oU2g82FWKjQQ87ybuDxz wLEG2tIaA4UChaQGcQ5YToWOeKeeAQVuInQg7LYzI5rqk7xQ/cRlqXXQUUTVPSyuRJQRJtk9mOxo E7SyTAtkQq07IU+zg7jTACaEjdKoNNRyFVABLf46QS3KmfeY+iIpXuMoD9f27VLnK3dfL1fuvFE2 Hj4qB65rQ6iOjl2+AJ+DkW1wQNxdNFUKZgMKcZO1XWqf1IZ63RZcUhbhiWXOrYtLwiMd0xKP683Q TMWwWbMTPYU8kYbEYkAi/RpDGyPBkaOaRwX+0HTBMF6VtB8L/hEVoWdPBuHg2Qs863xUXEKTuy5N DoasDdvjaIyfzAxih+djNGmP4btN8O3AbwMES9cieZSJZ57tI3g5/amg5sYCrxTaQhjZJ7/oipn2 RJu2dLl8i40EryJ4LQy2OK6DMuJk4rl9pvT5UzOnPsax+hkbFh6BewON2i5CqJpGDzGeIzA4PdIm FpsQaD2UprkeN63bkiPKRJOlKg4H6xj0yavtyDDr040mh5S1xl/ryP7CcDXX+p6En8DOVIoqNF7E D2RNcMWYHuKejNUPxjqejAtstX+sglamk7ZYfQ9+J+22fYorOAhbsiqejjw9qPc0xq8zDIaP+o3A AL0BSWHGtyQ8IYy3PVTNbsV5YWe/fP43f1fWP3q3XLjya/UgbkpwkQL148gPltikQ7pJZ80v9UE7 iHYqn1JfmoTx3bDID3Gty4yXYQkrnVLvtWi+myen70dZJdS8jxn8RkUxFnLeHC81a6fUWL+Oj7lt JA1vGJ4Ci+8GxZfkMA18+0iOeXSNHauidiAYNzJsa2a4w681SVMyeYRF0l3iXXQtHxtndjI1SLjK 5Mn8wfBd5gKGRaWBzc6J/8UBGinjkLjhKXj4Hm7CPLLC/tMcisrzeiKlmlzZmdshzI6CDpjB1rN7 5mb43rMQwTtPb2LeYwccb66FcTANLRmIo6HHamMWVbNW7AitWUEbNrd6sSwikHkMxtFrl2O3pVoy F/gjxTGAsDuN+NLprkE7qUq3ZUDaPOHjK38OQtIT5RZCmtA1rPpVXNaDHYp0GUVjVgOan2En0/Um CnQWTBRzAmtrADZumogSiDp8FWs60pXgYY/xw1hIdWRdjwe1qUa2x4OnuiqRJ6U9KU3X8EwywVuE xR/lqju/1KM+cMeiZ+wB9cLNRmjXVsv6tz4sD//pp2X+8ycRZ4dql/NcX7WP9sjrkx67pJ5dkkhH 6gvgtblyCd5YQiBaYGp8jQJX0JN3GXeHdSEtCgf+puZM6oVjRnIEyKuaL43sHOsjeT+KHdLEJ18L h2h2AXGaMrRcCD4eVstptiEUrsLrVzlP7zLT8Rfn2N2J20vYd9iMojbt6f5W+WfeQxCDCC9g3yNN hT7PS1P+V2jYAa/nne0S308Kr12SP/2wuYz9GxD/FpthXmet5TU0dAuo3zzGz1kAz15bQDD0WA41 fX54eHDuY26M0O2uZzWdlodTrLYrtV+xgYD05CZLoZZZvAArXC1XbWHEADpga5njFTR2StP4+FFT GjsTieBZe64DjbtriejaxTSyU2xC6TykwhbafggmbG2ThFciLLCgp7Y/iGtMhRmlY5B5OWbwtJxr 2HF48UhRPQqK2F2a9j1CR9vhJdtK+kU/EflGABZWRMT1T5g0ka5BHQVZwtZ5l0JZouAjTvwQH+SV W4mH3xx8MPvpvfL0j79XXmWzwe4b1+nPEYhpJ6zQhQ+d9HZdr308fbf9sPihKduptn2hT/oHUPdj eLvuLeMPbcLVYLhsINKArgNVe12eDaZDgCZzVtOOF98bfki/82aPj/LnjfqvmN7KyKNERt1G9Qve GQWP3mSaYHrtfMng8Qafvmn3D5uNhpaBQ7vFKZXjOLNRS0Q0im70r41fWBkcK5HbuLrORMzB9NHw a4KCzdmLdsbGW3HHb6BzkBHfqMxqhxFTRPjbiOc9dNXGBu4QTGhAmRMHkXVGN3e/2bkaOxo/8E5t zXDS+q6DLBHiWh4X+DN1eYTANcfgtYimbI6jL+avrnF4P1oyhLMZF/gz6Hi3nRsCZhDK9jlZ3fTt 3JwG8r0aEsHoby5aM/SJgqlwGR4u4rS+tbi7vEVYF96gHSabqYEggmvhMni1GBn82wjEqXWUVEy2 R51zDR+V9mT4r8JXXgwebOy2sPo0jni3oyaLgcLJaU9DhLNTDrsDzc0WEQXeUlDmv1x87dVyhc0G n/z533Du2m4cFLuNJuhglwXwCCKeI3aIBL4Ary2zRnEZAWQNYX+JNlEvBafk4JU0VpFphMDBYCGv mo8+7cM6s2KJEAKFLxE3mg2uqmky/jaDH2IQNwewAQCh64D1cdx/XtYQzC7Dy1cRHC8poDiVTyMZ KKR5mC0DpWvqnnGY6QYDJsqGuh6NdPb4wHFLDXs2g989gmOX8AENyR2b+st4S7zfJr/vLlwo/+rC crnCDQcrwCxRgPNk2D8nfWMApyuIvLMDehsa3WG6YyNFA1lz1/2CN6YlbeftYBnBLaR12+HEhtmj D7DHqVAgUijRDQEZPYRqhEaPkTC29W16HgTszto0xrRPqbngRQRdmzVmmtDaEq36VejqqrkXzrcx 02uXY2Gdo1JuvKA8eDLhgjb4z+ZuCc/SeQhVNVUK/aTYozUpSDtw4TBmjY3PWGBNLYq2vna/lR4d 3X6lLl5tW1ECpK1g5LToAtL3o3/4h3KfzQZXXvk35Qk3huzRbo6o+1m02LFRgrpTUIsPZxsfRvp1 p8l2Mup7M6Ta+k8Ki40P4DSddie1sK7/jDT5uPEDLtayATvENcrqeGLnyPVyGvSUyrJDao1XmrTG xjVmosFUn+BT3R3DJlz9hk0X4b1G5b1408y4QEfz7KXRj5+5iKSCJiDadAEYouj8o+MSEW692q/Q CsI3b4TVhrXNQbF2FFJfd1rSgMBrJ2TH40Aa+iUixX2FYFV49Atd20X4CwcrNEKna7zrEoUCjd7T +9V8uaNyj3N+5jgK48IaAhnTlj6LCGaeW+ZBsofcdbnB6BbXMYGTYQjNAmkw+OZp5ReY6rK8Tiqz k/xBdaLpdyxfBEcfOWSPmeM4ewBj0JMdw448g8fZ2ZHhKzHSnvSnPUxI3mvamQNEazJM/kvhLHEE j4Lb6G0aaoqikwaR/gN4Z/btt8qTH/6oDH70z2VmS10aWhiY0ynyVT4E1liDthjr0NgwAD7PJEN2 imMm1InEWV2UF0FRThadQ0YIagweTgX6nkVo+vlupFjupHAZ8aq2PKbDcav5Et8zPiR2ECYPESSd XrrEB8ZlPkCu8DGyyqLuJT5kPJ5koGYMQe2xtwJwhtmjwwFr0ZgGteggRLnJM848rmMATR7L4Ro8 p2mfkad6cTp4KAV30q4Q7zXK4OPV6+UDpj0vIjIuUd4L5Iv9CGUxBC3ba82/92z6wbTFtOvmzg74 bbO0bqYeLQfNMO86zFz3wagzyqNa6Qx77Me0LCxMLbPKCWTD7z0EXzZWoGpwfagQcU4icdzQo7Bq 52R8vIZG7/im7DyNE8gTIiRRAo2LX4/kwJW8l1GEe16T/USLY3hskNiDP8ZKLlAP4bvE8iMg8ybe IczzEjMFztmNbHuxbhJemfEcvY0n5ZP/+6/KzQ8/LCvvvV6ecrfsDB/Z87tAsxDRac5oexNoSv9M WpqzTPTL6dL0085p04yTYek2TvqJT+E2NXeTcGa882i/1KydUms27tb0m5Fanr4f/BUNJxa12xc0 XxQtrnw/1tijV8/QyfaYQEeCtWsZwSbzpo9p2LAzrbQzPBp91zMaFg8/gcf84LfDQBK9dQCbb9Pl L3o0gSit6PxotAwqDlyWj3EVwPxipFmBgs6UAfKQRr1Lh+AaGbbTxZTkRuGQWNaRzbMwfIav+5Ur 67yznoyprEXuvpy9gLaMQYsRNvA42HkTgOdEhcBHGnHmE3nxS1rjmjFP3PZrLKjCnZ2EjXo4jVbB v1Cnd6y8u7LsUH4haxrOfvjzJHKsQ+/qchi3x/DZWWe49T1mes6xsM6R5Xss7S68739SvqRF2P4T nTV1bXW3YX5Z77Jua3t7u2w83SibW0/LU7Suu/88W26gEZJv97meSk3a+iHTnbC3Mkmczo5AEJNW MerD1vBJFcwq0bJ6pKcGSLrijzB4K4swFl7jn0UkvJosNbfSGefz4WavQNzZuY8UsnGwGQv2r3lG GjuML9EuPCdtyfTRnjFDi8aNKUcEunt7m+WBmjW01eJ1+k9RxHQVyrZ4BuRxG7yuSRtEfISzQ7Qh uPeJ59G018npu2gRv3nxSrnNDQcXmE4NAQ0a3UDgovM4nQE7lwq4K3Xg1VE7inuUBWvaDHNKtgqs tVwIGhpIGTPJS1FedAFRnl3hBWgHbx9i1mzPFTuwwC1SJm728Ko0N1/Y99jPuHbQna1x7xRYbYrG Fx1FT6h1qwO/8NTRGj2FpZ6MpYQKcM0R9RCRAiR+DD3NZLj4Aifxx3kcasiDon2kxE8viVGalTQy 0ME2Cbd0jeNvgM7wGjjMvn8SxIfNEQflLsNoW//pH8onf/yn5ebr/0N5sGzlzZZVluIMr+EjnZzO bJNs6RKn7j7draDVwvfxZFhfmHOqXmVG+os/nxbHeXx/KaydUmt2EDZwG6vGjmnM0BFm+xn5V9ih 245kzERXMfQxfjLe0PMML+PYTo44pBN62gZijDoQKQDV+AHLe+QuCsEOzvPMbWAKXt1chF9fwNmW 52mwypnG9avbL221WXbiUYi+A6+QNotA5vTkAkLYMsLY8vp6rCebuX69zPG5PMsJ/jNMqRzwJadg 5zqVHfC6jq0urNfhAFq7UNO0U7F7XYhKovPDUwFxxtEQf8vJLncX7VsKEDHQ1womdLJ5nrrpl+dk TOO+k+JkWlNIGkf0JVyTaBhDR7mfaihjyz3NJHxZ1hlmZ9wa85xhrf+kd+H6j3BRj/IZtKjdGXA2 1MbmZtni2Rmg+WHez80iN7/2Xtl5ul1W/+mTskzbdVrdDnCZaceY4IuRHFhIVCtruxCr6xjlncxp +AKT7nrVGrT54aEnA0b2FTm9pHvTZmMezDN/e2jIdpiK3SV9BcKbnI12DS3xVXZerjHVOd+11V0E rW2EqCdohe/Dz8+Y6nlEe9yAOI/YsIlK8Ax5j3PT8Hf92Cbxt8inQtuuWi8A/fMwXYbWcguh9Tur V8rXSe86tM+gnVOIvYBAp3bRaWHpV1PntLyr+ewDnnBm2w7aP/PtDRtVSCOEd0mJ2zOi5HDoNt0g srr99SYE+wUFsLpInP6h6yuPkNBCHAF/TGUDowbKac/obCjMRQREj2CtyyzAAi5p86gVcbtJIzRn JINXUCMJOPHH9p2H/2PGWQBpi1kB4Xms/1pr4zGkf8zIAxrrjhiuuYs0w28cNtt7qAojEVIg7fjQ j1igSeKJn/Dia03AdB7Zp2U7yzgtvO81P9Xuh+nOuvA9cJDoEXy3SN0sb26Vx3/9t+Xqb327XL3x zbJFfeSa54ir0A7dreClf5qkqW/XvNcyyrht3vLdePmY39ZfQc2w9Es700oazqP9chr0lFqTbaIN BYyNsC941fAxFDYuTDJHv2GNwXYOGSqZb1J462c3Nj4NSmhNsgUbe7fTCANcR104q1ZMP79IMTZI LLqL+FMgikaD3zIDnrtwBHKaKc4OwxUDFx1U7G5EGNtn6tJnzylMBC7vapxDSzbPGpiltSvlAoLZ Mjsw5zmfzMvJj1iHo2ZNAW+PkUENQTvlas9qp1pnKHjBYW5yIA1/fCJfBMQBmOGonZ6XShsa+TMe l01n3eAcNmrfNc9TD21842SH4LsmO8rqev7f5APL+JdhrPXW2KG3ph8eYV0UaR/R38aq7/0yayH6 Yf3yNDz9Mh3j+14HJ2QVBJkdpuS2tjhagkFFjdoBQpBnoK3Ae8vw25UlhA3mCj/5/HGZ2x6UCwpp DKoL8Jg3FFQDTrId2UIg0Pi+2DFQcJ8yA0H2Bjb34ZKBgA3fYUkazfgKEpt2IdLMRoYDL5knfeWT C0y/XmSK/32O4lhDk8beZcWSmMLfYqrzsRes725z0TpHcbBoa5tNCR486/Smgsm8wg3aJNcObS35 WeVBuOwEVSAFxgN866YNIiGgXkBw85qo765cK+8hqF0Ezs07ti2n2BQSXcrgsg9bj1qSPdq4Z5c9 3d4oz6DN1RrywxECZ9QJNNjKotwim/lW2xStAt+RsVwsXaEsg1l2UEfBj0A6mitc1W6ST2A9MkVt Y5wBZucgf4AtaA2JrL4f49cUGCWF5Ey3NbmuLiiXnwkc9p3hMp1xMwqv/pEnmYIEgmehLUyHrzoM lgDgumD9hU9nxBVs6COE0RKiuvNX/wyL+hAXfoFzQpyAbzLTT6dfdrHhi7Kek1cox6c/+0n5we// n+VbLC+YWb0Ej8FpVEjSLV0pOJqWfWJq25LO1vY94xpPk/H0T7/sW1u/jBeR+FHAT5NppPs82y+F tVNqz/UP2TQqv493OHbBE1ZDEGcAAEAASURBVI2RMuKIbyaC+hXlV0ky3DTmgm1h3IYOCBuOM10K 4mqZH8fEtPWPtA0FxCYiudFlGEanGLuM8Jxl4bHTDAM67lifwhqXENAYDOcRuI5YRzbPHZcXLq6X hYtrZfmyAtlFpi6rsDbDgHRAnCOFOFKIg0t5V4Ph4OiOzmV7z0pAfNHbD/vl7BeuORjQGQwX3nd+ EaF7t1jUNAgsfBgLR42ciPF0LdA0k3UxDe6k8Gnxp9WxeKfhqAV1EgVfzL9P13QaajrCnQR7kv9p FE6Ko58dtnY+dv4KZnsIPgprgx1vFnBh/j7rmRbL6iqbBTg7bxGBxKuIluC25XfeLDtff7c8/P7f cW4YQhFfB2qa9tuDv2AV/scMh7R0btKHh0JYYdCyPQZsF6H6EJ/2o+ZpH2HGNWlxThpMr6AGkWUe Ddkabecy7eMyay/X0DZfZt2PmiyOr+Uids5LQ1DznLRHbBxwt+cmDLwJFa5HE6ftVEHRNmQ79k7H J7QuF9hvEt+1bR7PIfd73Igao1UEtw8WL5bvolF785CjTSg7L+RQUFmknSi4AlqFNQUsHN5VuwO+ J7toK+1/2LCT5WPXYluTmjTSMuo5q29bp8LzGTjkGd+jj4KG0MBhR2eE9xCrXgij7jSdRzvu1V5q BzU2aXtip0Dd3Vs/z6LFGxyoybqJVmA9MUPc1Xns13Cfmj+D21zqBl0gru/+Cjs0Fs5JJuqvBp4G dlL0Sf6WuQvtpbItb9/7abTh4ppWFnENH1McrgQ+cDHnAcsLfvAfy5M/+6ty5Xd+pzxiXSiJjpHV 708inQ4mw9KuNIIfQn1P+mzX+uWTfYC4fPdjTGN4VSxMpyEinMOf7IHOIelfPcl2ynBBfeL1lMb3 BcmpTDkS2GS6acbuaGics+lFSUYXV7xPwFmzRacqDE9d81Kx0l9HJ3RIQ1FF7xU9D1dYzM9CZ++0 XEIztnLlCtOYF8vK+mU0Zuy6ZKEpCwUQxjwGA5tnn6kcBbrYYUkavEZ7zsXA0j08aJKB5lCprTMO oIYTu3YkOPPgWaEqJJ2QYP5oIHzRCxR9xct80ILB4JSpnno0Zadfz2TZ9bxPdfbr7Hlw9OP0E5iO o8tzP2LjnoajT0PfPSn+JD+T1N8nv3yTjJPgM7xvJ57WX7rS3w46H69+2mUnotNoexxeq/DmzjUP NF5Eq+sNA9GZw3fzfBi4i/Jgfblc+uZ75emPf1aOfvYY4YAPEBdpsf5L43g+ZobFTP4q04Vg4NqY ylP481dP5Ze76nScRwo4Fafg5Jlf2jsIawuU0UWmZK/yQfMK5/pdZirSIzlmPHwXPt4kDYW0hwho D8jbY4QkD5mNIzjAHRoyxsqYnqwpE+auTzcTIFAhrOwiwCrQKcA4vKqnE36VD67fXVgr7128WC6R 5gowy9AoTbMIbjOUT/CAl3iTWXRsCIDcnKDAuLtVnrJO7WiJj7SxJpQFNPK0S1KQPNnY51BWpB1l 12ldLFGFH8syBDgRCKdFHcfGJWAXQvsoHOIZ5Rwfe/Zh8gGPSydMP+srugfJkdSmgqVzzPRIFjxy hz/o4z1zO4wHvX2T7SjsUbGMgdWpzuplbr+MyfQsS4015/+o7emPR2MSNr362UicGW59zAlEQQzY AbrHmsf9T+6Vn/3RX5QbH32zzLx5gwTH08i4aWffIO58ksa0+7B9//4GBsPbhw5gLKcZv5+fTOc8 2S81a6fUVmWo44w+ipLMWRuJ/vmWjUEBZczEuUojH/rFztCq+Yql/+p4vo3YMfewMdamV5mUhuOB UbCoa8aCVWkMdraBCHwLMcUBiJ0ilov61WRVEKcMXItCenylxAXjCGVepbTEmrLVS+tlic597/JV jsRgkT8DzSw7L12fIg4FsWc2YqcboxEiLDn48MRdfCRimThd4jatOQZNJaxsYLGzCVLVnoVQJyxP /IJPeketr5Z34OMnGiAwCWKn7PUnwkdnHYjoZPCIV+3ouSPKxJ8v0qizQ0iEXwRHxtUOfP3eswUI mBNGgR5c6zxGVy2UIUh/XVHWRAJknaX7mG3HOT6STwAZT/Q4TQ0O+anDIN5Yv9SlcahAwrqpXYQc NWtijXO3OMplnnWPix7pwqDtAOGgfIgAFMdLwOcLN26WS197vzz4/PtsLmBaByFHgSeEAdtQkNi1 YPwt6RAKsPV1yj6MdYTAI3cpEvnm+rYd2sIA1zbCllOx0urxFzdZwH+FIziucRvGJYQ0D59VSDw8 QtCEjs9Zo/nIw2xZZ7eBgLcJIR7WO4BmzyxzejN3jiKTkZZtue703MQVy/33l2Pd1o7dB3QsALgG 7Dvzq+WDKzfLN9muuUon47VPzvLOq1HDT4Eu1piaNTJsM/KcuKcIak/YcbrB2jq+1hCILaDIff1x cIx6GnnmHZwNVG2rjUfbZuQ7a1qSa9GKS5elzR95DG0feYm1agSpJbSvlN2sD/uOA6Q2vIgqgDA6 RqZiIx3CfB9xV4WJXesjcNIVrx7CitKIIMU/vBvYfE1+Tlv/JCPjGDv6R8uSjk/ertpI0fPeRUj4 mhgu0tWkNo9eNtwJ50dMpJsehFrOXbRKh7gJjySSMOHEhH/mrAkyRJagPLCjzz/geBs4nh0vj3/w g/LDP/7Dcvt//O/KA3bqL23vlyWE/m2+Dlxz7NEz1pXn3CHjVfrEZTn2TKXVsqkZ0E4BzzDzlzDR riNv1HmDy7tyM7+RKfOkRwPTS/bcOF9q1k6pqqHGBlatdW0HMjI2sGpCpBgG2BH4H8wmhzem4mkY VT7iz85eE+GMLhWiMm6mIr4ZeyhCQ+ZRIMJ1wNe3kwKkqDwUO2G8s88Ozy5wD4nQwyzVTB0gbPnM IJDNczaZh8NeXLtUVi9eQjjjWiW0ZUcMKIcMKHto0Q4QyvZldtbCePdfmLRxZE7clWVWqxsi6HQq bGfV7FGShnV+WX64K+Ya0KXS+Q2REqmLWKMTPmrY4QWoA0w1HS4lWEzibBt2+Dd5CcAJP9HYJ/g/ r9dZ4id92WGfnMZ4WZwM9/whmfZ4jF46lYHHQTpXlPEp4ZMimWabbvue8NlJx5SnAhCCjOvTFNSk LrRpfGgsIKTNI6Qt+NFBvfpU/HUtlRpW9zfOcmXY2jtvl3s//Key/dOfl1V2NR6iMZJLZEk/HJJN Haxt3fWIBTlQes2pDwNIuG2DTnciWMFvGwhn3oTgB8oKa8yuzLNejnVztxAe19jNvEz7XkQa8gy0 bSp6AyxPDnbKz7nMcgtt4TYCnno+j53xjLQqpNVDfhUqPQjaNundlzsIoZ6dtgMOS0MNWuEg6Vna n4PjdfqB7166XD5evlxeQ95aYGunwoq7PD2aw486+4a6ttODTS2DRdr6YXnAOrlHCI7es3rErR8h HCjFubK/Z6o4k55i6ZmgK0q41gu0grBKAR1opN3F9PvSsq7LHoCVr8iTmx7olWodQRe9HXXDRyjB ToEGHZSp9R7BDRmAYKwz6DBP4a4/Qa9JGAaAbs90k3N8rz1pBystxK88Vv3yV7/WjHX/RBNPhai2 3WQIo1aKRtT1rSMGR4czaCM0F//rHekZEGA1Zs37EIsh8ehv3i32fv8St6gMIdu4eGIs2dAWsxRl Hm30IoyoRnaPNYyf/eX3ylv/6mtl76P3uemDdsQgdMApys7WePKeadmGomu27DBZTn07ArufNh+t 0GawfYDhas59fA/NOuNVXdM9EuLMTVdEHebzac1nYZ1P8r9aqvsVrA5q3ADR42udw+ZIsPfjpbGR dN1JenENDDvBusZouAOFHW6ghQFn6TmcyHMUqeeT2eDsYIHgf5aOeYWTz+u6GGCQ4nZYGxZaMgau GQSzvcusIUM7toowtnKJtWRME80uMnWJoLbAehSPJz8k0RmmF2xUe45Q4sBdz/RhwIAOaQ/TNbjq 6H5tkV3wmH/jyHw2Xl/61Ub6Ik0fnzRP8jtLmpPi9/2O4XvB+TqG/7k8jpftVLqfC+8IyPL1L3nL FE0j0unKwMHJ65YGCFW7HFuhJs1NLnbgTncucPyG0yMKabNMvx/bth8fOCO8Cj8r1y6X2994v/z0 /mccTcHUHu3JtHPQsiFGG+x+Of0sBhs1t0sAOoh79ppXK3k8xg4+u9B0AH0OVivk6wpt7BrPJTRS FxdYk4a/WpF98vOM9rSBlt1Lzx/tb5enXOfkGWh+dsVuavC7rtN0B+BXi2Y2YskCA9UAhzs+tw03 bWy1elvzewiCh9w8cFTuzq6Wj65cK3dI/zJxZ7wmjT81zcoGfsjxQzu36dKv2A/Rz6DnK08GCGpc AB+CGgeeBgQ4FIzjgwufk0zU5VhXKeFAi9+0unodanJxHyLYtkaBUeKiVqSdsnWd2oL1m/6gU1Dz o1ke8SJ6sbjRwr/4Xm2R9t5jyrXxs3TsgzWSC6FBc2qyLKr0Cxtn+Onfmcxbui1PjXAjWNMhZ7GB xY9c+9YOBvjo4TuPpCP6IULCLUJMxqmu8d+k46Q+t7a6UZzhtGxHpOGtkar8SPGjX16LsQo+fPbz T8s//oc/L7ffZnnBHp8eHDsT9xlQGdax45abEqz+1iSN6Re0AhO0NcDRR3TuNj/Gt1+wvdsX+NQP OzA08U24n1ameZ7sl9Ogp9TWbHxijwD6DFw/FbpvFVpO8mLaNqaBhxRh9KvDAXa0uK5boPMJZ4TK qXY8NOYQxozBNIp+MNwBsK4H86s6DnqVSfla32F6xfPJFhXGLrLLkouXXdi/iIDmyf4D1NMzLApW GKsXj9NVKJjZkYiLT/ADtG82LNN1Oogemezxpd7RPpXZuw7YvE4yY41nEsAX8JtK0wSc0+iYitMq itqcgPwEr6k4J8WbUp6Torx4v8qZifcL5SMjn2KLt/+4sNg1aQ7AuwhnTnl6LIf8aqe8zIeGgprv 87QB6zXrtk4HOa6O8Dq0WaT8hiZjH03x6hu3ysxrN8rjf/55WUfGMrcKSk6bMn5GO/XWgRhYqXe1 N+L00jOFggEwmzSUTYSjATcJHDKlucoU0HXWd97gI+gaWrRLPA5Us+TF4208SuMZQpq3DsTmAY7B 2ERQ8Wqoeo2aAptr3Xi0wR/noiGM5AL6AXR43lrcRgCMk8AOjuZtFk3bZd4/XrnEsRzXyi0+Fpe4 /X1ukQGWadHIHLQr5Cj4yc1RLrz7jeaOz0cIjhscf3KIkBZTgbUEok8wxlQD7ZAyMlE31WsooBFa QfyFbuqwNVVUrmVvzhTQloBRYOswBW0hvOKjlvLA/jrqz9jTKbW87Oc0UgEr4ZS/wit+rG9Dxeir WPWT12rYeDrVbxRfITJg8bLfF9qzH8UatPISn8HwgGGZNCABE3bQIHhNczxFEZ1usl0klPH1G8dT XX3fjJMKhD0+Vg5RCOwr7cP3oWV7tl1+9qffL9e//etl9dc+KD+bg9cJu3jAeEM61ovToUdV7Zso o/zasgyazDD/6Z/ArVs42722bT0fYfTPsIyrLex5N+Mt5Lzn5gXTn1u5W7R2H2mOvD4pmnEdRGxq VcEEy9MIVW/vzTmRUf/kQhtpXYxMHBh+4YAvSJnOR2EMnrL/sNNQSPML0xP5XSvG6MQZZBfYbcnC fnZarqyvsZj6Qtnl8NgFhLU5F/967QeaMhckbxPPBcuz4KDtMHVaNQ+x7gRa69qS6OKhCy1cl7Xo VGhYXsfkFEll8xfP7Dau1vQbVD+8hZ303o8/CeasOIUfw2u9Ri2OsI+F4z0tjWnhlnQfpp+Gqfdh 9DvNjMNHKmPgx9MYr58x4M7R4mzjp3/rZxT900/sMZ1hh8ugpjCmkOamAbVnsbMTP9kkNGfwf9hM d8bXNG3GIx3cAdcaO29SGnrFUCsS0og0+fXuzZUra+X2r31c/v7hk3LpwWaljYFIgcLjY1xrY8tV UPCbyynIHdbhOEW4DYxXVe2zs3OGaaFLaLEveiUU7fAG56VdQkjyUNk55kbVeUnRA8SqZwhpD9Gm feZaMOh0bZuiiAdJh3YMGj0rzDTUrJlm3OuJ34AwhSlvJYiL57GdevU8Qb6648PqbfC8Rd/wEcLa TehbUcD1dgM6gH2PVoBW16yqn1Jrrlxl3+DNA3HuG/BxvwP9iNezqVWKUghtuz1c7Z+GhXvSi+zV GV/dWW5FhqYFjNZDGr8NO/ElvSoE8HF/MPlGLGe9moeaMFBH/YCOeJbeLgKqO1+ddlPQFpt9avLg EGnzkmHCAx1Ppcn6SmNIkE04of6bNv128nHaGSPxpltcxpWPAr88yKOGUuymZpyulKNtVP/IQsTJ 9pI4n8fu09XGIblIr/WTGGn0L81YLdkeCLD8zY3swIJHyuOwLG4jaD58Wn7+h/9XefvDW6wJRUnA mDPLcU/O2Gj4nAp+bnGar7a8ohysc9t1E5b5b23LL0oNeIUzje3e/kQ7BbbaFzgGVpgAPKc/L4W1 UyquZawACyb3m7qaUB3DtPGFKjMHkykEyRjGPixLgtOZ2ikKF12/nSAMRbfDVAqXi8NIsRYF5j/k qAF3Vs6hEVvkfLJlzrBZWoH50Y75zPDFfsS0zyxTG051qpLeW6XTDtwdQ0qTPVlnQt1PkN/fTjcA KjGkX80sC71m9mEF6KwL8GlkQOumdYYJTV8H/7xWNq6T4cE/ZpKi6jlUzXcwozWCY5GGjkkdVJ+G tnMYRjzlpdbpOF2ngL+QIEuln+JZ6Z5OyKRUpsc6DSLLP2mV7/pdZPAiSGLDQHSuaNDoYBV6FM60 dYtDYSKnON2Y4oaB2KBCfMOyQ870Km2Vp9Kv2vC13gySDp5qmFjFGdNQS6++gobt9XLw8B+ixap8 mmMkYjgCvg7crtU8YDG1uzWfIrV5a4CHzHrUxWUGpWsLK+UGmr5LC3NllY0Drklzu4Fpc9pbrCfb QvN2jzjPmCZ9zEXoG+ASb/QVfPOpydthYFObpqZMQU3hQzd7MGN3p8Kaa9xCmKuZjZP8LwC7xOB1 i7Wn/9XscrlmX0HZLqExd2OEvOQgq0bHMrQd1cOlySd9jlPHO5T9UzYSmMbRkn2BNUdM/uu0oq+W ColZiNqdSYEn3WGPgu1qwBGROhAH/AYg8Y4hIA6dpt2PZ3wtIDzGFWBECwWacShfl9ApzHpwsF2t i0ais40U2jTMEsCY5I1w8BM9IWUjSeMxqpCVfYhhecZl+olDfNlP9HFnN2zKwtgi6sggD+sJvfaz DhCYgO+IsOYkqy5FieDn/jmJPjNoHZr0mCEPYY4FVG9rL8iNtmGe4U9+XLe2pPDKuYUP//bvyvpf f1Qu/xe/WQZ8jLiUxjqiQcdHBYo2suv4iB//1od0pkBVU8Ifv3xs4z7GyXIWzo87TSuE+QGX+U74 1i8inOOfl9Ogp1ReCGFtuI2K/zR2esLI+rVROnGIH52fYH47zcd6GDtuGiXaMbVncaUSgtY8U5P7 dLDecbnAdUrecTm3vhpTmDNoyWb4Wi+sdTliQIAr43wz7Totato2dP/9esa2IWHbmREStrTGZbvC wfDZFoVL40JkhTEFNY/McN1O/EXrFDUDYwOf8abZ0Sg7IBtR654cd1oihmcOJmPo+05Psx/juPtF 4DiOdYqPHdqvhDmdjkllEzE6+rMjTiyegRbri7B998BWtWm5YNgs2wG7aDi0Z3TourPzzs4YjxP5 KWnSNl1/FYbkfxuIHwEO8A4W3pZx+5tfL/f+8Wdl99lWXDvlomgUWPEhNIDxB2huFNu2ECS30fiJ Yx36bqDlfnVxrVyfXSnr4PIEEJMwf05RukPzGTs93VG5wbEXDwjzvDIFojiKowKDDuII86BbTj0L QTIEMsJ38I/z0iDIa6UU3GyPCq0KZKvAvIaA+N5lpjyZfn3/GZIfGjVO4ojNNk5ZKai5G1Xtmz2D 2vJoRl1fsoN7g3PftilTDjEL/PyEyT7F/k2v0KhkYAWJ3w585COuMTMOYS5OM9JoH6ZoMc8sQZ0C 5SgWykr/oAXb8+ucAXAdYt2pSOlQZ3X2wvjTTe27gYNkqnZEGQKUf15MLt+pzYkpTMvPZ4IZ8mcX luV2DDrKEx6Ov1pWwa/mm3qpea/VNCGZL+3lx5JtKNoVGZdnpQWfoV+bCArZCHOc8BBm8xNLdGJg iLMEytyzp+XHv/dH5Tc/+LDMXbnK2mnisC7Ptrfrrme+PvhWiPxFG+0KJWjoaGnTjDKnLDRtuWb7 1r/fN9hnGG6/45OwbXzjnUdD0b00J5dAr4nZAdV2VaPIYHoEQ9EJIogd0LEorM3wHCKcHS1xrRID wiK7K2c5RX1pjfsuPSjWNTfsyNxXSHMjgB0CnOz1TG4KqI0cjRnMF+toSDEaU5e+DYWuKtKfRy1X vW1s1Ti4VOr16Xyxqp+YNPXXA0FrtxGewzAPQrR3/iJfdoH9hA6tpjLpl1bdmBfRwLKxJtqz4uzH Tzxftf3LSLd2i/2cVR7p++o25Bid1jlP+gdM13E6ILggeB8BLYQ2BkP9NB674Q0ZCiF2wP0vYnkw 606cQz6fwGPxNS8NwElHwPPjDkkFNX1sX2plFIaWL18uax+8WX78dz+IMFc3uD5sB1gvS3eNmVO0 ahGu8uF0nU0Dr7A78irr0dZos3aiClxuHBgAs8noFGelkdenaNG2iLvNgrcd8oXowQMNZNtNEk6Q 7oPf9Ty7iFUurHCjguekmX4Idthq2GzxdXk933CU3SXWx91Fi/bRynp5Ey3G5QFr0xTSEAj9kIzr 1ii3OdoxM6A89iVOwSnQqJVnMxIatSccJqxweUQ/ZOnMVomMPNmf1D4lfjst+6j0Ieh5jHXQaY4E t1upGvxR5OzBhj7UTQz0zM8uUMZLCKTOqClMQZLUhkNhzfVqaqEk22ANr1NNClLyvV17xdvEtS/u sFS8pGraUS6T0SePZqh0Gtcn0vDdhBt3OEgrNJgASk/Ah50UBNQL+4n2aWbgAVNLutPuJ2Rb0bie 2XVq8kks3cFfHkZ1UA53WMH5o5+WB3/y1+X6f//flA2WDMyRLw9kPlAjAHPnx5ttPI1p5tP30519 ySTa0i/auXxmnjpjH6LRL9Ptgs6l9VJYm1JttV3RkGAo2SCeYDTcdHgzdiJua2c9zTwC2Tznky2y dmWZq5QKwtjg0lWUY4azwN8pTE/7d/qSznQrFvDaBYOXzqyuY4BxSVQGs2OmG4+BI5kyKKCDog3U jlQCvURXJLy6vVpjZ1hpF2/HtBEimLQbgwiY2jdLh2ljBU47DRqxgXpWUME7c8wjA8JuG40eukd5 GAN9boftMDu85440BdCu1PL4lTJmtG/6fi+6IEivDittWUygI+mCnmFo96KPX+zWdQhF2B58qtZs n6MsPLzW9ZLZccoPbg6oU5x1R1fwICS0vJIURTLgbMOSnLSDhki/EhW0WL84IS3ymAJbtDyC9lnj uf7B2+XoJz8t2/c20NSwoQGBZwN9zaaCJc1nlY+rG0x3vsmyhVePENRoI8vmj/ywNzWmJzdolxsI Dg+d6kQIeka+N80/6bu2rG5QgA4cCnYKTrtq7mJa1nKq053bwCqoqV0yjvGl1WbJqlNuYjgq1+h7 3l27XN5nmcQtaLi8s8c1Umj/Fvnos3MAxnVCswys2vYAsoxH+tAjhHDjMSHPOAJFAdM+KZp9JGSb wNSuBHheEKIhJZ4qzOnS2C/me/UBHXHH/QIf3vqStdD8Vej6m+HpJ87QfELPEtoZb6OajQqEGukF UAHN+07VrFVBrfadanI04xRUvzYdw3WHXxDNm44uYoR17Uw+io+ACh1w8qHRBJmUlikO/e2PiSvO NOLUw9s1NPbJIdTqzRgjtKUbQAHR/zF9MdZUWtx9yL478Ndo0V5jahwESWEXhLuaWuKVnriPlYCE MV+Wv5tbFx5vlh//wZ+WK9/5dpl5+7WI7MfCHh8Tcwhvtpe4lYA4nofYCm1tv9DSq/9Jbd6woA1i ojyJKGzCi98nw1q85+395TToKTV2QIfoejIX2h7YmTFtWRC4Fui4XVM2c+EyGjK0ZQhnLvSfxU+N 2SxrymJxruc+cVaZgp5fJjJ1dIjapmsD9oVH5rKfjLPdgDWA7pqXznQNO+D1ApH4NDN09hVfOEVC CH96CkKHViFreKwV8PO2MyNG7vAFMsnyhZ6vcye89nFtW5tCC/ki3y2vETG1QY6n24abcjbaE6kA Xc1nhZgKL86GhhPxnjXgrDjPCi898MW4GZWl/hVl49dPw+hRXkPgiBPlB6xlb+fpE/fHdnb6mYa8 N0+7qlOctC1p8r+hrX03zrB+Onr6daxsop+Uhx20dDGNA697ObiDbR1w+RDi3Rbk+WhbfPLPsmln /Y075Wef/i2wTjnuh1bgKnfJ3prjtgGEoHWEtVXEniWahEWxjdShoLbHAv6H+N0nqQ01VUyV5r2c CmmRLvADoBUUba0HCHVcm05c16URBj37bDzY5v0Zg7ZaNm9c8Nsrpvrwm0cKuQTcGyyN+HBllXs9 V8tlpmbnoNd7GZ8hdC7vUaaOmhJoPxCdgPmkzVoUiHouxXjGLtQnTM3uAHbkZgJs7xcNmBAs8EDC Iwo/9iZmBCi6DVCNmSocNl70N033UmkhuOLqanMMQJwROkRygLbRTR2LhKxAzyLCc6WNekRwdPer a/sGSLNxvhp+JuTHZfRs1nXkaogyCDcnGuWjKKImOF7HyYg09Q/6iJQ9qf14xO/syJ081fCx8dJp ujW9GsF3jbb50o4VetSx7cV1hPJy9NXOQU4wlRZrRmFGwjN3vBJX03kPQ0KOxz9EQRK1NoSspVXL sPpVX9Pwr9JozRMJh/FrOSMM8Setc562srNVyj/9Y/nJv/+DcuPuv2UKf7EscFDzjjCzcDW85gdE 3e2tBpj+wLE16Q2etTSqsSyEMdx3TSvg+SFoeJZ72jW2xdCVAzDn3bzUrJ1SgzNvvctUJVOYTDXM I4zNMY05i/YsBDM1ZGrLYgqTKU+EulhLhu30gh+WasX8Ij1uajPrWkkTLGPJVNhYNppgxIQwOEx0 nemoUUauwDB0DuMMfSr6lncDpvUYwdambBLj4dEI2gZAo+g3lBGWX5036T6NzmnhtP4Xn5mvAucX ofIUOqK+CRck3uXOeGcgUwChI83HcB/d2pa3HXJ+5QZP28FCY8CeSuv08lYYyjRFle8jWzo6/44m w6RvDy3YLrcGDFivdsCa0V3XinIJ/BU+zK7zYXaTqc4bHI1zlQ0GMf1jPNJwqnMLgWKTNWmbCD0P WfP1lIAtBT3KYxcpKw6vbejZZUq0CoyUGZlX2NgFn3EG0PLYkRX3LF92bB+K/sM1arFJgLDr6Mg+ ZrPRHZZSvI7Ae5mBasE1gIzA3tcbm4w6FZr6M3GpSXOS0AHWTz+1dJvk+QlnqLmhwXMZawmTLvCC 1vO/AE4DrcJED2DmMTVO9SO7IVTUkO43pITWJ2o74mXcNjQKtfFAViERdhqqfSFq/ZQ1V+QD3pEM NWpuRvE9cCZi7Dg8vNf1Os0YEoakWAGk0QOpeSS4bxSahW8BLK6aqxG0fDXWvwgjUBrex4qmw2Fw 4lK7lufOHcU5nS2CUdmbaRUBo1DSblyZZMU8crVvAQ8Cp84tjKTVctYkbu2gmxdDHIFqGBiCDuoD 7bm3FxxxWPUP/8OflbV//e2y8v7X4DMKjxmoFBBn2dTix1ru3HRTUa4LtPw0lmG+a+d7lm2Ga9uv tO5A8C/w56WwdkqlXvqt34HH+DKg01ZbpjDm3ZdxkXmwKwuP5VR6kzgGI5gWFoZ5NDJ8dICnpPHL CErG/zJpR5PqGtaXwfNVx1WT0ZrYFPJl6J4Qt3ZabSpne38R9fE8KU6jU+GlNdkBVvpqh+l70mtR hPBBvFZQy3jadsquR9PWnUb+CVzp0diJv3oFpzWhx18TPvB19eP7iCbjSDf0oj1yKtaBYsCgsrG5 UbY2EVy2duJg/rtM3zz7m78v7yAYvYZAdMEBnTMIl1kcHUeLkIUtBLUnaMYesZ7tMdqwp4eD0KTt oS1y/c4emi0FCjcxKCBVrZFTn9CESsbtCn7IuR5ti7LzUF3DtumNF8CxGGobjwjxGqwjbkEo5SaH X39rkbPTWJ92EdoWEdKcFlR7VIdoypjhcH++W+xNHHdRWuSh3UMocxH+Jhq1DaY+9xQ82L1aaWNw HK96C+yYsT+zXMfaEPgd8MfWpAH3ZY3kucxpabkO8u4mNX3lLW0/jr1qy93wCqSWglPukR/i6e6b WAMntUp/YYAGTL70b6oBeAxr0DIeK3m/59vFM3Y/pUpDwlu+Ci5hh8Ra21iGaw8ptXLt30Jasl7M dQpRbYzj78K57CZMlEFNU24F0bEIbb4ztOaGGJJBDA9qd8bFOlh48LT85H/5/fLt//lO+WydjzWF TuEscIy0LnBOYuz+hpfnCLePECbqg/Asy7Zfyvji8F2YNAmf7rRbmPQ7j/bLadBTam3/lZvxdey5 RnZQzC/IytHA8egYy+6yYxj8agPQTXOAL+0+TjPTGKnPkKfhOktYy/TGm0ZHH/ek+K3fWfH18T+P 2/IdXQlmjFHDzfgtTdWvdhYZ3rel+3icHlTX4fR8v7BzanpfGPNJEStvjuqo49XIV33PmNKW68+i 5HQTGDTzklot4cWXX7np1k9hLcs1S/+0PB8Py1hiPW4SXnv4OHAzkB0yuh8iDEm1Qtoed1zucBPC 5uZW2dzY5kw37u1kQ8+VazfLW2/eKh9dv1E+W10vc9/7+/LaALEKQWywiGCHsLTLoOil6o+8ZJ3p zodoEp7Svj1OIxZgI/G4QWC41gx6HLgUzsyBU3eGxQYCQrZ434E2z1qzl1g84Co4ALfUgrHpxw/B VQSudzmO49srV8t72FdZQ3dE+nZH4q51iKDGYOeOz0OFtSwukCp/ewSI06weG+Idn04jMjJGmoI+ j6AGWC1bypVucMzU3HU8YYhtqIGI3lC5AFqUQyOsBWhg83UeCXOZemGlE6WWKUSOw6U+zR2z+2iE qnaw9rRV55ZYxvuD4BO9LGwNBaVoE1D+9GkSTrobk7yWXspKY6YHX+tHCJGP05Px+jj196Mi6zZz r7/U1lJIwQyclANFHnaW/eSUxHDcmM6cYxuZkZYRzQlbyynJz2KKJAGptm0fzSf8cYTG+Qp8tvX9 vy/3/ubvyuHvfocPC+/FUEAEuiujWLuG4OyyCNP1AyoF1SyTtKVEuhTcWhpTkDNM/wxr85BTpZmb 82q/1KydVnPdFIHM6YAlj9XzxmgyMEb9qq3rPWyL0UDszICLd37snFrTMlHr3763MMmAGW7YaeEJ 19otfOt/2rvpvmjTx9muPaCAo6GdlubxfFAHlHea4+GWVa/3TOCv0O7n8ytMaoi6pjkqCzmwXx4B YznHwGFUOzhtyz7tWg8KYcY3TvsEVAXu4oCl48lMb7hzM+MTKTtZ459maj5Og7AtVppaqPTTjkOf sUPTQufugO505zYapc2NKqQNWFe2tLhSrl+7Ud566065e/ftcuONV8otdmp/yBmGf/H//lM53H4Y OzV3EMoek5ct1qZtsMPzERq5Z0xdbiFMeR2Th8zGdVWmbbrdY5EqVNhPKIRtMzCpefM+TwW1OAQX GAU8d9apVfNu0X2mjeYRJK6wE/KjxdXyMTcRvMGmhlWnqhT9YOm6E4+BjrQ9F86DYr0pwSknjwlS kHFYZ/a2ng/HDRAbHpECvBomey9A6tQWLwodyh21u+p1Wvhrop5dD9e9x0v3E+VP+vGn5moMBbzY tdNgM+K0mjhRGE+Nl0KKxvVzy9zhauuVdyxX2zJUR5+qRm2H/HiQr0u6Yk0wyMWfafSFUNMIk11C 0IuP5UGQJAdER2vAQk4c6JtxwnP0M9LSjfx8y7aQdq9AxoBHMNU78kn+FWZcPmDcSrvKAN9HRv/a 3kZ++UapQwcunsx7Zs1RK3diBzwwQUdEMEpN03imJ5r8zfQN0T/drkWLzw7axSLtZOHJZvnB//F7 5VvfeZ9z8jjImfVqfiSo0JBfrFfTVKPmWGDdp5CaYZGqee7gdfuuyfEjeK/z07/v1q9fxvqdN/NS WDulxmL3URcO/1HhdQFuZVy7TY/YSDaujAsb4tcxMQyUjHxKMl8qSCZM5v1SiH7ZkS3HpsFNIsd8 to2un+9++KgbmYRtsp8ktGkch7JGx2u1T8fxOL8In3GapHGcLjvu2gFLjWHDp3oM3akty3JIPGkL bphVxttQm5btIuNpO8hmOkL3TYuzH6a7ho/nLfGlbaft17NCWvopDDjYeZeoQtqzZxtlY2OTc91Y V4Mwduv118s7b79bbt9+o9x69bVy6eKlssdBabv7O+Xmu3fKK9/5Rvn5H/9JOdyd4d7OvXIPbcEG Qto28b0yyiugnPZx8FOTpYih5iAFNf1j8wHlo4DmVGQchEvcel4amiHhCY+PPsIRPUJgWQXZG0x1 fnPxYvnawmq56tFuLM4ezLriDBjWBVnu7honwxISdmh5GCSdCHW36RE78LY84w0th5fCq4EKwSNi g4ForQmngtaXND20kFgFsCHacI5LP9FT4h82gMvkcQn67U+lKD56Ibi6KCsGeoVdb14wPYUL+S3C U/PX7M8apj32YiyLzn7FgHCNQVTcBhFmWZ/BjNpIR59ojD+GxnLolQ8+86yFHsC3HulSs1FplMeO UynSxgzxJ/VTY4yTBKpYM0eesy0ndmtAasdrr+YrNsOIiel7PyZm0QLv/OAfyv0//Ivywb/5z8sD Tz+gDG2rmih9SEvBLAVf263Gdq0gl21av2P0gK/WX5TssfBaBzXM+OfZvJwGPaX22s7M6g5BLDsH eVK2jbl4GwVMQ4Q4UDYiZkPps/UpCXZBMt9J5rSwFxnnJFwv0n9aXvrhNry+X5+eaeF9+LO7qZtT 6ufs+F5MjOn5tlOT9Mpb2sMHEvr+k6iKjo+AUQdIq7BD7/zaOKYyOsZjlGYL43um2/dPdw2v8dNP O2hHIlI7cMCgENoXBvAQ0tCEea/oFlOdzzY2eLbjaqgVNhDcvfNWuXP3TnkL++YrN8oqB1I7BTTL lOc+EtUOmwA+Y2Lyld/9jfKnf/X9sss1VDvbataYAgWnAlYcpSEv8hcaI4U3wt0M4MCrgOpwo0Dn tVH6u17sidoS6HXaM4Q9wjX2EAxtLM7m7DSkknc5x+07Fy6Vd2a4tgqV0R4D9pZXRTF4LXI93ay7 RNGezdL3eGaa2yb9kKRUyhq7PT2TzTMbnzhdy+YHBcUFNkpUbYopVmO9aWL477ophaL0r6HP9ytP mBG5IbRfbTTDWiOcC50aU7kIf2C9PuwCWwsX0cDMUrahTcJfAVh+0/KQVc9Xs0ySB/XXBBh2Dv7h 6Q9FFH4kHekhZWe6tVlYn0PoF/KStIgsyqhrf6chj1kcyiCnBCkA4lJ7XZFlPhOHfDiGdghghKhd M3yqQYwnfAQkn2ZcNX2iDH4PmPqR0bFMxQvjqOHdRYPmxfRuXmEfQbm6MSif/q9/VN7noNyjN18j rPm4490yiXIRP5lQQFtijbgCm1fOqWnziA9hsq8Qpo1TCajlm/7p18Km33m1X2rWTqk5FwkPDa9D px2kxsYvC+uOJzyCWSsA/eiw4aTP6XYyZELVNBs6CDgOMx6ecdPuw6f/aXaf6U+DnRhmvk8na2o+ ptEd6IeVUqmYFmcirY1n1Od0wpsYZ6+PscgvyNHPd99tMvqp+eElOt/0S9isc+1JfvpPqlJhW/hI w3bR8H4L02Z5kn/SMaKvG0E7fFKvcBbTJkyDedaWxgN33dm5va0m7RmatI2AubB6GeHsdrlz9065 o5B28wZHIHL0Dm3W+j5gk8CM05pMkT7bZZr04YMy2H1anrx2pXz2+T00BOAmM3sIR3GHJvFINfJc 9WIey6GwVrnHNWJxrATChGvctuko1K55AbtKMLVcMW0HzZaoGjK2MJW30Hx9uHqlfH15vdwiy8us p9ufIyb+Ci4KEgtMNbkn0rOrHGDte6TJ3ad+KC7usf4HLeATjlB4wGaCAQN9bJACHm+mSxU1G0O4 pecgGnbQ1ISf4TX4BizmacRhIujxzRgBpN2lEWsjnRpDmxKH4OrfMZFCljhNw+rezXrHPRTKOjaJ aKZJ2JjppAupqUIbQgj4hRpNyxqKIT3799Ykna3ftPfAKyqFH2mNv2mxgCd/ToHK0zHNCT1mJ9uZ GIJOXyBsvLz1zPCsiyF0DTz2O547BcVDP3ogm+roylIcwlW7llx16cOBPBz87IcDPL4ARQhVF57x 8fKPPy8//JM/L6s3/ltOVFgNXovkqY9200fkAfQKajE1usx0PvnXrdDlo7Feg9esO96zTGKDQkD8 y/x5KaydUq85xTkCqQydJ1D7VetXRDCw3KoRxM9TTfpVV/wmY6WXjH26EaCmexJc1581wRX+WGfV QLSvzwN3nO5xwvvh5j2madqEprz3cRwrm4nFMO45ThUJjgdP8phCVS+Ywj6G8hjIOES/fPv57EWf 6Ewc0+JmuHYVmkboFHD6JuH7/qaXT4ZZtvq1caI0DCDLvhtW+bG+Z9yR39CnwzOqscSbtpAxuLkW JvA6zYlQogYtbL6+0YRZ2rtMVW5uIWw92+ThPH6+8lcvXClvvPFmeff9u+XNN2+Xq9eulmXPSGSN kjjUvnnO2h7TmwPuNnz86EH59N5n5R4C2tN798r+K1fL41WWOnDMxRwHotmsvY5tj7hqj6pRaGJA cr0Nfp6ZtkMZbTKu5Lo0L19X0+b5Zl7Vw0mMcS/oHtNF3ixwg1y+xeXv/xlTsa9yNNAqefNaJU99 d82bZce+AQQMypiB05QVulynFgaAee6XOkBT9IABfov1affRJh6h2lhkOs11trk+KXDUWKPfpqE5 HLbnCIYQZzJdNclBWWM19Y6GwFZDqk9CRQA066684ZvpeOTIYYie8hoCKHWJjFBWPPdN4RN4b50w nt1sXbPmLQ9oLikPzyWTPwIEKI3uNMFHONNPwSkFO9+P0AKBFERQTLrGHHvwc91jTsWK1/A05iFz n/5hg1NB2vdscU0RZ/TTbRB7cK0CyIBpwyVsiijyahk59a5bI192r+GutFAuJFrfVRoYAXd6BOTo p21z+npQ7yzT0J4HGOkQz6hi1DbvmupX3w/4qvFmDcU2x0U39xyh9b1Aq7j3v/9eef83v1Pmv3Y3 tMvzXBTqbT92SV6DdgjcPki9IcE+xvapvQD/SptuHwW2dGvrtoyyr8p86E6jX+tO//Nmv5wGPaXG YPfx0M45ZAO4uOGJaPNGqOzMi/DJ1QZ8AfN8jDZOJ7w5NJOYdJLfMMIXfWnSFEU04mFBPR/SvnAx 3Fp+WvR+um2FnBbvtLC2ACfAZYeQQV9JeSbyzs40tfN9DMR8G6YndhVuxgunH0+6W9rbd9H03Ynb sDRWcdZbiz/pbP0yTobprtVVBcCETTvgI1E6aDpqH4WOfdZhKWQpsO1y+fjG1nZ5/ORprElztfna 2pVy587b5f13P0BIe6tcvsrB1Xyl27Grsdjb7e4j5X0HLdyjx4/KZ/ful/uffFIe3r8PPu4uII1Z 1OIXXr1R7j3dKEsMmOYzBg1KOQZhJR9FCgYYBYgBA5vaM+/Y3NEPWz2WgmNUDPAKHO4K3QeWm3/L q3QQH3Mcx7cuXi232MAwj8CicVVPXLzOlKf1kFq0Q6UW0vDsNRuZbYRiwbBuDwnm04OtsstuV+88 tR/KxdxChPATNOs6bqzLuGKKMkyjcGiCUQ3xVl3pk3VVeaXyJr0ikD4jQxYw/gADvbHGEG1fLRrz RwqUsZdxLUOjmssApMylyXuQFT4sz13UPS57IvqQshGvJqUmR3o4k1bFP6dfs392/VfST+WGfwpZ FUZhAH9UpRa7YXNsehjmTNydIwWnpCPxmLZ++Vfp6ZeOZdMzkk5BybNmwzPMZrm3VSHWj2DTs5a0 Q0vb0UFR1fQiTXGasnASG4HhI25cQ9PvayMWEV0iYBllOWU9m3Hp6pIFD22CQlKIDMqsHIy3f/gJ s/x4t/wIge3D2/8Tc6PXyvxe/YhQC21dq9lW9FY0TqEsys188CiQyTNOjar1SwEtEjEdwqSx0pe+ 0E+8fynmpWbtS9ZkMvFJaPrhfWbqh/fxCN+H6ePox/lVcNtm+3Sfla4vG39yem0XNRnirL5npfOs 8EmP8eJJj9bOMGzN86TR56O+u0WfOPull+mkPYQ7hY6Ebe18jzRJxEFOv3jYBWkHHutYYvExgpGL /dGkPXnymDVpm3TSs+Uyl0e/9dbd8sH7H5TXX79drl27zlotNwEZ3ynS3cChwLbD4u2HDx+Vzz// PDRpjx49LltPnqGhY40X6e0grM2gebvwyrVSfv5JGWwNkHbUdGE5QtIuHZy8XUDt1w6L/7cddgDY RSBgaGXoUevmsOfUpRIVmkAFRt6YDCpvo0377tr18v7yalmHJrVsmkBfX4lb3ZaH72oe1JQJGuvn EPrcGbkPLc92OS+OcnFxuoO8pi3X1CpFwBl+Wr4YynpkImiyHNAqksWhGU0pDr3GwsMX7WYd6Gu+ FNYc6Jc5aHzZA1TV6MRfCgSWNw9/ajaPyHNfwJCe1hjfaeK4c1P81gbxTDhwQ7NCmAaZJMossqFf vIix0hczKOPoI17/x/K2vGq51xyOwcjT4dEg64HJy61ZoC53+ajwekMF+AD3BxRiifrBLd9E3oCp ppZgxdakF3HG0+iwdvFGsX0Tvxo2TVAf6VoumU4EHfvJ8ChF8v3kz/62bP/2b5T5374YO5QvsP5S bdoWU6YrqJ49X3AfQSx5dozvoCEP1rYfEEZ3wqQ93LzQlUHWxzHizqHHuRTWsjJ/2eU9iY5kmqSt DzMtPOOdZPfjnwT3y/bv5/t56OnnLTU2zxNXmNO7jsQy3mml71nsPp1nzetZ4aXNOFIeNu99kzjT NrxP5zS3a2Na0y//FnfCpZ92vhuW7tZP/6RhFK7vCD4GoA5XHL2hMORUJ351Tdo+x28w1cn6Mnd3 eu/ttWuvlrfffqe8//575e7dO2V9/SIDrwOmcXdCmIjjO/gq3+Z2gidPniCk3SuffvppefToUUyf euDtHheaH3ATwQDBzinF2HHIIDV/9UrZ+pwT1ZzioYgcy9VLqE1z7dSAZ5MFYYMYLQVRmKqPV0o5 Ber616MFpj3Rft1iyvIbi+vlty6/imYNKYF1codMeUbp1yTqO/HShNCn9ocBTW3UvgIaga5/U6P3 hPLYYefrAseRuCA7T4WPoxAUUDBZ9uE4w08Mut3YLotYFyH0UBBype+JO8Mo+jGjsC2egAVXXYdl rtR8MBAj8C0wFbbKzTCL4JtjIZ5kuz5PKcTyJJHYLLHL0SeZbiYySUCUFk2kGfFNqdKgv8pJs5Xh lpLCm7itZAVC5abErWZ3mglY45iefCxSydDGBN36V6dZwnSBnV/sxOzeIxTtkPfneg0aL0N4+aBG N1e8N2ginw2O/muNMfLNafL0URCuOORjBF01bHI9tFt3Cr7TjIJ1GvnjxuPt8uN/9/vl7fdeL/s3 b0Z7VhOuwIa6jLInRXEjnJpO1p+2/vkYrsCmJtmDdZ0qzY+T1LgJq8m44TjnP+dSWPtFlXkyy0np JUNkeN+tfx/HJPekeImzb/fjG35a/ArftGLg+zhOi99PP93TcPTDjXfWdPo4psWPDpCGfbqZFn48 dj/dPl3HY4z7OFC1po/PsD5OYTI/2oa3MO174m79jN9PJzu0hO/bpwlnLe6Ml34n2QmXtnCRry4v Ga8Nr5sGWDTPwGS4B9oqrO2g8XqK5uspU5LbW2iP0JhdvXodLdqH5aMPPyq333i9XFxfA79x0aDF tEid7txjob4H4SqkffbZZyGkPXz4MAQ3O30ftW6HCGqOGw5OG9tb5SmbFPaebseutoOVJY7t4G5D BjGnz9Qz7CKRIArGuWk70Mq1nDF6hlKLSnPazlP2vZ3AIzM8kf8u4se/uXCjfJez09bQgu3PDFib hthF3BkGLodIMhGDr4OiQ7PzfdGCEdZAxdQSU4H4qIV4NNguT6FVHllgt6s6PAU1By3zoSCi6fNC eD7nj3hCUAVeTg68pK+ddVopJjCSwxVnl0kV8Aq5nUlhRmHXZqEd65SAcRPFMoP2HHXHXkhQVayx iYKMW+4KxrG5gPJKmhJ32klLphvCGGUprbEZrGuOTrsp1Ac8frWkqq2WL+hTA2gZGoc0k2ezPJOf TTuEjABMSka29WbJ9Y3+UZ7Qd6KhPBa5QWcPHpXmGcpIYwzLL6Y4/VDo0AdN4RBCEUuhd2RqvZnh Jk3rqHFGORGllg4BgUr9J/FMp4FNzJGPJqDlDfEs0n62/+YHZfC9/6fM/ddrfNxcQEif53aQeiDv rhpj1rkF71IwIeBnveFWgHQKVOEsNl/w8TWgXatN0681/frJemthztv7yzVrp9VYx/wngsjDLcOf CDgKmMQ0Q6aegOus+Ecp0aZqDzGVxky/jXte36dV2VnzNaFPOiuK6NuyLowszhavNLfhwuARfunf 54P0D1h+DO/DZNjz2n2c6U67xaNf6993J2z6BywZjQHWuABUvzqIyvoKi3a8dtLaClBOSz5jDdnT p3WKchHN0eu3b5f33nu/vPvOe5yTdrtcXLvIdv9FhDQFL6Yx/epGwHMDwfbOZnny+Fn5/P6D8tmn n5X7rEnb3NwMmCqoKQwC78jMl/qA3WcKag9Ic4Np1sKRHh56ceHyOpoALj5HEFII2EUTNEDDw1BR dnC7bkitjPqjONNMbRBCo9fNqSlaJD/f4oDb31x/pXyN6Z9FjhXZXgEHEhzHu5VVblTfW6AsunpU VKllZ0ExJEOfa99ivRsChBe+P2G93uNOUFtaWnbZlbFiQKslXPki6+KL2kEHeM23y9m0HTQdgP3X ZHq+62/9yo/GHQo7BmIMqzEoMCUgfxmk3aG7APxcp5abwXbi0+VPTg2qSXJDyT5rCY05TDzex38i zZrQsF0cax+kZZmCuqM/chT0y49BmvRbJ2zWOHSTiYWsCbJr/kJ7SSz9Mg1lpzS1/GqYKQTuLtCS MlwzjNsC4G9S82qemPbLuhDWWDUmv+KojuChTrwHome6tKJeDOrSivIKZ1AoVRFRWx9N/JouZRAb D3j340UT8OIGKOGH2rkujbJ0WK6ivf75v/vD8t43vsZRHty5zXfKwSaH2SyzWpF24kYI236lD2Ea PmvLJwRiYMz/Evd2a1zSsME5ihe4u3vRO7ubPKbgl34R4Zz+vNSsfZmKi/bRtZAvg+dXMO5Xwdxn xXlW+OcrxrPX19ljHKckO2JDzFcf56S8pl/aLdYWn/59dwub75PwZJh2Pzzd2j6ZRrozbt+d/onT cDMclkKHL0NTO2c7aLVhCk4OfnbAcfwGQs0AjZed8O037iCgvYugVoW09fVLgUtBZsB6rX2O4Ij4 aOO2tzaZ4nxY7t1jTRrPgwcPA59TqSkM7iOcSZRavAFf/btMJW4h2D14ymYF17cxICwy/TPvtMsK g8DahbL92Aum3BHK+jPePLKDc3NjQK1TlIoX1AeCxgX81xm6LhF699KV8ttz6+U6U6BzHC+yh6C2 sQgmYJa4qHOJldb7sTvRuA544nQgrGKJEsUh4QcM2q6Nu88O1ccDJDzu91xG6+LEFLOINTLWizRR 712dOVDH4nQI1z8GzxRgukSzdrOejZPCgCByv2v9hmIAAtMi01lrHFY8Tz24dskNBTHG8xPrxRjI 44w66ip243ZCQj+f0hSti7KwDHVn2kNBq4skBZ2uKKjSW0FD+tWcise/UFpFpvwR68jIq2nkK7Wh X8RkWUVZ9xCo5TuiXSywwWBAndNKYjo08tqlN5YqdSVf6TfW1Bq8kc4wbkA2obUc0sMyCIQ5fFv5 AABAAElEQVRROvgCHnxgftU8Bp4ooGiPhluOmhoXNzAbczvl6hwbX/6/H5dnf/SX5eq/vV4O19Y4 U2+57KL6sz0ZT9h8Agk/uuU1nzbMMl8Dh3ZdJsEHEjC5vk3YfynmpbD2JWoyB6ETUci055RZsvM4 MW9TAibl+6w4zwo/haQuuHYqzwcLlPV3Uo/33EhEMZ7uae627ITrw5qsHVJr2jjp34/Xdydc2v1w 3enXvgs/zZ04w7avj2dUBq6RsYOt055o0uxsEZC2WFO2yflom1ywrvCmJs3roN5HQHv7nbfLG2++ Xjzc1pmgI4QycXhOWuwUZSDfQYhxitONA58y5fnwwQMua9+M6RI1aRW+pq2Qto/wtk2cR5tPy9b9 x2Xn6WbZYnryEC3GLIvdYzqPU2UfzyDMhUZLml3gzIYHMqdAF7sSGR0PUTvF4MQv2xrKFQS9dxGk Pl6/zkXsi+UGexRmuPOzXPD8qEFZBn7uaJ6NBfPcP8q0JRshoqDsN4ivNqlOhFJu+LlPVEHtEWX0 FK3aIXGWOIrEgdOz4Dy+w3PZXrypgyc5j3wHXV2/Znlqkk9q2kF90BVhlsqYQIewFgNzJ4xSdjEQ sVbwEM2lvJG7UBV9XT+oxnEXrdquWlDKxXLOzQE1TYoIgU46bAtRD5AWcJ3koiDQmiAdLV3isUkN OTTiAm0bMNIwoMVQ0zS9VpM2DjHuqrhGyKQo4ovjJAE0Gg8kwK/mITR5wKt1gqEIULQcGctALXXk lqRCgAR+zHRu8fnX5XII0vpFGUZIhRVxXRNKSJdOpb0TtgTAyC9DPNAx4PyZDdrqlb2l8sn/9sdl +VsflYNvvs1NFXwIsUN7zhsOImbt37KPy/LRLb+lW1Df/dBzGlQtmh95ui2jPExXuHH+1Of8mZfT oKfUmW3kNNPn/2Owxu+1kWMw4VGBsqNpYfo0TE2TyMfjTMkIRL5oZp6M73Q6+nT3cTxP3tuy872P 86w4+jT08eu2w2hNP07fLewkv8QxaQCclkbGfV7b9BNn0pJ24tCdfmkb1r5Pco/i8+ZYTrVb87mI 2QXUqQHzQFvXWHmQ7ZPu+I19NGlO6735xp1y5+7bnJPGERxv3C6ra0ybsHhepPsM3AfeKKCmjAHc Lf0egnuPc9I+/fQTpjsfcJzHk5hGdc1aTq04DWvaTpE6zeqUqMd+PHz8uGw8eoJEVI9IsOHOsMPz gPnNLQaIHeCl07tAXTs1rHEEgRjsGUi8zmmOvK1A4XV27n3zIgfcXrxcrg0OygXodOXQHlOnh2j0 XJO1yCJ6Lyo/ZJDeYQrUQhJvxc1vSBPVZTFuIcQ8YDB6wjO7vMA6JhdlM23IWG1d1snBCg94mP4g nP4n2TENqyqnM/mmHUM1tIaQgEu/ePqNrMtB4ujbDuGeOTcn7cRdxF5DczqP1DvPzQvmx3V5aieV 2mrOEHCtO5EhlKnpSdoSfxUqzH8NqXm3fnQr3CQkLgU7nJarQpovupXrwghLmeYfL8hENdC40XaI oB3vXTRxaGLHMHZ1V0p8Fx+JE0dXTRgU9d0g/2oyeoZJbZ3FPEedH+4qNA+xJVilHW/jVzz8CoZJ cc4U0wijGZZbxuv8DR+GAaerxqEsayK0aQQjaPGOWnyB6gQ2w3OtJe+mtFRYdwfI/gz38tI2f/zv /7Dcfv1yObz2Cps9iO+3ilPc4FPzaoacZjVuTLeSl1qS2MBY7vaVCmn2A5oVPl4GtOsBHzRCK8S1 9RNA5/TnpWbt1IrrOP1EGNnoy5qKI9oeqORxm8VJRrjjzNeHn0Z3H/tx+ONp9ON8Fe4+HePuyXmf Rsc4jtPKdhqmDO8LK+k/sulS+smOAo8JOxmUeLMjauugfU/41s646XcavLAtfL63/umX+Nqw9NOu /r50vrIi78P4dNgxZUInfoBmy/5c4UqBacAJ+x418ZT1JlubTGPuccbW8hqC2S12d74bz61br7Jx YBFtmmuy6MgVzOiYja8Atkv8zS2mLtGgubtTjdqzZ2jJWG/m8R4ppMXXNh27nfuAacgthLSnTHe6 G1QhcXsbwQ+Bz45/mUboEQmHrnlj3VnQvYNAxdTngCk7j8rwz0NpM9uup/J4jktk/+35lfL1tcvl Nlq1y+R5bpaF0AsMsDHYW0Csz8Fyk4C3D9SbFNDy4efQ5ACrEGEduovUdWrb5PchU7sbDk6sz1Oo oUBIsw6EFno90yopAkEY0xuZEcUjv/5bJ5M03h1OhVF82xQi9fEkgOg8HLvDNQ6gQHRIOc8htC7y XOaoDraGoBn0iFy0K5TvPls1Y7dmjNmc5E+kHXjpECF4Rp7i77ARKiMFyipp0632R1P9qigbHvyE CEC4YREOrfEOj7VtJ8L0M08KfZGnijdxRRvoHG1cvWLxP5jFEHUab/or8JAmwkg9Ow8hB/Q+s41U meJSoAdeOuTR+KCLdqykbsSOAKxONg1SpcfUU1gzTFD5Bm//O9M5OjzJVWmPgEflI24FNDVoakpZ Udfhs9KqkBXIpZOXld2VqNetRag5Qnv+139Zjj7mkvdfZxpz6TL5sn7Z+Q0NfhCZATXbc2i2Z+AN 24kfExq1bFnWw74Gfz/ClvigY6tK1z/wYQOs06Ln3Zz/HJz3GjhGf9dajvmf7NEy6ySoaeGT4nw1 fqOu4Yvi/7J5+bLxpTs7icxDH2ffnXCt3Yfpu/tptHGf572Pr41jWD76J2xr+540tP4tnohrvxzV aofsGiAGUjwcTKo3AwVCjsapzkOElwGbBnwUlraYgnTtmFObb3HLwN2775R32Dhw67XbsRbFrfmK NXUzQJ3G9F2BTa2YU56ffPozNGr3ykPWqIlXAU5tmlOVatKkJac8t1iQrwbuCZo017FJw4DbDxxc 7NR9nH5VMDQfpuOztLvEAMIQghotDmhFkjCHtlbLaZm01imLV7nT8q2l1XIJwfNowI0KTpZ6UwED 8CyCXx288SLePEIKYxHx68AWmiRwGBarqQhUUNtBe+El8jtM7SioWSZO+1rWQnb/vDNQ62hMN7Y1 Pqe/jseusNZra8ZdbUi+C2EugrSw2x9D3FCg4OcZYqte/UUaObxbqg7/gUGJhky4AzTOVyOO2FW8 RPaxNKMUR+76Nv6bfO0HRH8tW+ANCSp5X59qLAN39HbMnt7H7GwrGVDFQekzV7VMMiztpH1ow3cJ GTRF7hIavmEn9MBpcHmA8jtu5F18KTfTzTwnnEHTjPFaU+lJ35qT1JR7cK6H9sp9CpJWTJ8PxeXH TeBB6DL8kN3dP/qDPym/9tb75eitK2Ub4dvd0yGIBhbzZoOAH6yXKEHEw66d2u7a8o53yw7/3DGa Sx+IfO7Ny2nQc1+F9h+9hgWztqYf3oZNeu83gkkwX8xvnM5pOKSjNWfNh3FfBI6Whknvfbr67ueJ kzBJb9rp/0XsSXTol/592zT6fuGm2oYs1lZJ+Nc6HcazE1YoC0HJERUhDeHHR0Fqkw0DatG0FdJW uSvwzlu3EdDe5nm3vPoqmrSLa8Mv4aMjBTWmIMWBkObUpVozBbNPP/k0tGlPnj4OwU2NWb3UHQER eIcWB+U9zh9T4PJid+M9iClSDsHd3Am8stlcN+ilBk66Ix/mhcdLqmOk6b7uQ6fAWLKA0LGEKuAW 623ev7hebnAJ+0XW37ixYJkBxh1xh1zb4yCWa6OiCCm2GHRIPIY+Ctg1Z7EEyTIjrpsJBgyCT9hB t8tANu9UIZolBbWgj4EslEvVGX6tAKNH1ksNPN4e0v80u4+j1vgoRp9XDc9hPe0+jEO6zwrT3QuU z2wI9JYMsS1j3hSmDtVk4t6h3vesU6XbUBP1qSDCFGM+Yu0c9dbSE6mBLjBalqRb81zT8L3WN3UJ DaeZY2XVsc1pcaaF9XHKh2pW5VXz0esma9mB9Fi8aQk14Vlv6UUVNKYfKi9DFDA0N+gReCxCxFVA m+ODQ00irM6RHaxT/Y8/Kc84yuPijetl7/KKolnkaY52FcKd6lV24nquICmwW9jfkbFt1jKwHKog F36A2L7cmGQ5KbSdd/NSs/YrVoPRMfRb3yk0fpkGeRLas9JQ8dg4xxvSOP7jjXc8/Hy4LJtpZT4p fGxwAEffZHh2PP3ws7gnpd/S3X8Xt36mnXEriea1l3LjTjzxhY1/dOFEsLMMLZo2a7Q8fmOLK6G8 t1MBiW60XFhZLa/feqO8866atHfKq6/dREhbjakQNw54VpqaMYUs791UU7YVOzy5GuozD7T9JKY+ PeS2rj/LzQNoxSJ97bqBYAdhx639auFG2jSOC/BLv2trxtGM8j/6wtdvwPq14G/yGdNz8PoK2rgr +L7F1O3X1tfZRMBxAgwmKyz895BX9QKAxDlrxl1g0LGF5MAXAgDuaqDFAQ8cIajhucm6PI/moCTK zNICA2HVlBjPssm1TIlBO/OTfpmfdJ/VPj4sT8eQLGJc3/u9gvR796l7WFfQLuYC+ZgoRLg9oLyF MaZj8x78MPDIDuLUid9MYTotkyBiWp61UaG0scwbExTDCtaFvN+xR+QkFtF34NFOBZhiEnu/Xoxm 3VijfWPdjpvEUn1dJzbHtJ7arKohrP7BF+Abhx7HNHQdT7YG4Z9nrA1heRFcvH58aIL2bDvyoh87 AElbTIECXOswwOMHEY16RwjrGsACa1OXn2yVH//Rn5V3vn6nLFx6D6GMKUxwOaXqWsNZhFIPzfXT y37GHc+Gp6Catn4+8SEjXbYjBLTk/6rxG9FyHt9eCmu/4FpL5slkT2rEzxuecL9su/ZbJ/UAlbrs +JLWSXnPsBdl98u7jzfDp9GScGn38Txv/IzXh2/dptFPpw1PHCfZ/bgtvva9jS/+Np51FVqIALKb 1kgXv1HNta4d3Bxc9FPgEYcdqI/HDGy6zgqN1jbCmndoXuSy8tuvv1Hu3n27vH1XTdpNbhxYZ9qC dTh09F4L5eYBBbC4IgphbWd7tzxm2tIDbX0ePnyA4LcRWraaFkIh6eXmAelwIHM6VC2cB+k+4mop r5fKM9bavDqsJO2Wg08KbzXf5A2Zwk0BRwwwHuK6hNbrleWV8hFnp703t8JNBGjSoH1GIU0ctXjA 49hl+XnWWsUWLsIt4zot6rDGVB/TbAwvaB5myjN2iz6m7Fw2PROLpLtBUtUFMBrLPNKqQdUvfkc/ 0/hmvBwqZgUk6al1y6ApoWc0IW508UYUV7xiZgkfgho7YcHrpFmWl1q0/FNoM48xBYpvvfi9imuB aQpZVZCpQJmHPKzX3YIO4AFjbhOXxHbv6RVx8c/yMI4CjaBBoPYJxrjxWKgY07Fsw4gzkFha+iZM TghXsElp2ObUrinAWIemUSkKhIk+U+oQjSwX8KvZjDSHma95jIyJRlq7MCkTtuWX9t1lA9KpX/14 40YKpmtbQ0j8SamyslqyeT7CHv/0J+Wz732/3Hr9lbJ4/ZXAY1uepX7kB7hDQqLsPDTXtpl0iT/S 7PoeGkR8JGV7NryF1X1ezUth7Ves5toG8GJJGzXiaXij4dv4zmRqR3NalDZvXyyN07B/ubCWtva9 xZr+/cafbsN90t3GneTXhifu1m/aexsn8aefdl/gEF8bfgy//W3jKQtU+JGvA4J+LZ5IBz+nKhWy 1HZ5svizjWcci8FGAISw9YsXY3enU5137t5hTdotpkDX6NDrxdgKaF6eXjcOOG3JaefgefLUq6HY PMCU5/37n8d6MzcOOK0hDdWuU63SkWvM6pQrB+Ky6+wxZ6M98+YDdpw69VrzlZ24A1DNdJunphji NRaBOzWDZsGpu/ffvVv+y298o8z94Eflyk/vl3XyXcdj2oH4ukFOOSqnbnI9fLQUYBTs1OAoyzkQ usHAu0OfuK4ObeQR7wsMyFVjEEPlkLcCR5/IF+SOcjhjAll2kmD2uyKtFCUuPK0jy8R7UJepe4dz y0WBjcKImEd4+LePZnQWzdse5R5rmQhOvILme01k8m8rsCVEtBWT6ozkWQ9112j69uzMQ8+778x2 2PcfuY8joscgM/YbQo2H62fN943lPQdvHMVHTdX6mnaF7OCBsYxOpCkC+5g7d5NuYBVlr8DH8RIY xPJJw6t5UhPqx0Rq47zvtWrtnPKv2tUZJJC5g0G5/xd/VW5yE8nKCrpqNgjsUh8K6R6NU0vAFZpd vjoSLYPIs/kOONJFyBvuxCU8NW5dlHNtvVyz9itYfW3Hd1byZNrJ8Xst7ayIp8BnYzkZbDTAnwzz iw9p6bbcJpWdfgmXdktpxkm7DfPdOG28SXCtXwvbx5Vu4ds4+qc7w1JY6+MLuOhQE1tn6wfe1hg3 8dn157u4fdd2HY+aLAU0NVcu4HdtmWaNM8be4NiNt+9yBMd775SbrElbvbCCJo2BhqTUnjldoZC3 55NCGkJWXLLOURz3H9xH2HoaZyhVYYt0EXT8gq/CGrcGoIHz2UGbt4NQJh0equsGgk2mXgdMhaaA l3lMO/Obee2XV4STx1lGlleuXyvf+bVfL7/+r79b3r1yiSM35jnyg4NynyBcOefZjSd1iFEQoe6j SB1EMqU6rgnrWjn1Kg4yO7gfcb7cwPU1aBXU/HhkgYOUs7Bq6HKnZoNqhPSX9BY8Af1pvOXAPKVx 5yPUd2N9hVueWShLCBuerKV2McoIsCrwMsiS50OntbAV2qKMDCe6GL5s/lOASBqfxzZNecO/0Gji 7vOQeFr+qeHmgr8kelRUgh8zas1i0wnwmeb/z955ANZRXOv/U6+Wbbn3gguuYGMbbDDFiWmml7yE QGghpLxUXvi/vBQCCSmkQEIS4CW0UEInhBcDJoRiMNgY446xwTYucpMl2ZLV773/883elVZXV8Wy JVnSN/bV3d2ZOXPmN7O7556ZnQ0mokxPnv21PmGnoNPDGSZ+OVaGyxvMeBDbfj2ZxZUVbT1fRDDe P8YCmZb/2dqcCsFvnqcuvenNp5vZqvYyAzOk7L229vqOMB/AyduNHW8sxZjBo5DcKwdl9maPKjPk uKYeZSbT0+Z1jjrMWWc/OO5WltMiCpus3A+EQDo/fUf7lmetNVuMZ8tBhtiT352YNWd508Lip2/i 6hAjNr6MmET1dg/uEtqyMuoVesgHqAdD7HdQsLsI2AF3wbG28NP6aYL7flo/rjnfwfxMz/2m5MTm 8Y0n/7j/Xad8qyovnq7KcbpEbB6m4zHePNzQhqece7LSWyvNM5boseJSGJyXRq8XL6A5OT3t6c5h GDpiNEbbC9b79O3jHhxIsgni9J7xtUFuIVsaemZk0bgrM4/SfltGY4950LgMB18NVWLeuXJ7/yXX OPOGOb2xRBpezlizvNX2GqAyW3uMC2Jy2JMeOebji955rLKSy3zwIl4/+HXmKcb6kjuPefzdrcft p9kyHEcNH4lTZ59qr8qZgNRuac4T2HvMSFR8vAUVNtTLl7SzFNafxgfXEOOtxPM02KKgXIDV9mm8 uG8zxqrtZsThvkqbYJ9vD16UW32S3AKf5nE0XdwSD1ZlvrYqYlZQiONHjQU/urnXHqbz8zQmNxAX m9z1kWC86VoTyDNagFPJbtBckyvD5ibx5mOmhmNRkz6Qmi8Pr7C+x4cs6Nn0TDjmsUDQHMdrIHgG sqW18mLPJY9+TEaTV6u1bdm+qWnBtl2E1SPKlPXx6lwrKRpVU5ZfvivF8rN/udROVqBsd9zvb1ZU lJ2ZGJaHZg1DbCYvfdjmg9Jo5HwuN8/Pfiz4daU+zMVvflyIFVMT4Seo/fb0iEqICmskuSeeugcS 8YeIe8evaeIt+mJYLZ4caHhVWbtyBqs5TpFVFkHBqnXYsXI1hp403c4B8yjbQzth+7AHJZrhx+b2 qmBCfE727dfZZ+fH8TiP+fG1teuYWzLWGmm3msaPpmmy0dkRA52V/Ym/mGtCTDyPR/tcTRJuBMuh DgerR2z6OsKdfFdK4DDLCOzaZlCGu9AEK1Y3qdvz0tcKCdYhTvJ2O0SjJhiC9eRx6h3UPRjPbf8T lBH8defLCMZzO1ZObHywzNj03Ge8LyOog7ftctTEcy8YavLVrbr7xRlM5+vgy3frWbEP82P9mDcQ N2nfecAqnIFUYl4rGmvlZRW2SGsGevbsjyGDh5kn7SiMGjUafftn2zppOe5XNOWEzUgLm0HCOWY0 uPipMIOKw5X0pO0yTxq/9xXtc14yetCqzZDx283zItBItDXWzAtXboZZeZm9XsqWAKFHjcYaDTR+ KsrN22ZPZvIJ0YaMNb/+ru68B7jzlX2ANz7vV32PHt0x0daDmvOpT9m7SIe4JRw4ZJZm3qGU3H7I mDIFRbsK0d08gPR8cTiTw3y0q7jAa9g2qs3Y4FNySXZD5XH6y+xWizJLW2jDQwXVthSD6ZliRiGt BL/N3BIiNDioqFU+gXc2P9hxE1pjRPBOxocfGOjkcyktCb8DuVx8nT/s89E0bGXOC+I/F1hGIDAl zaZgoBHjGzI8zhSewr6xwdpaoIfFPnxhe7btJpvHzFu6xHKQtetoltXSJNpiuHwC0K1tZ+V58fTK 2LpbrgzLw/TBELzWMk2M7uxLPMa6sb2jVN0+eftP6zplrU7cr609e7/lZJlk7so1IyKawPO0EYQX Q2PNiwr+ZSbKoAg7zv/uy/7YMZc1mp9S2OctxqLsmxu2552jlBE4me3BFXqlnYaWkcYwczmD0TK6 f4HklMTAMlwBvmyXkgctmB487D6WsEZPF+n/cRL8HS9x7Z6TxmU97KrhflixDT3vmD2wY/MzXb1s gd9UE876pO3dhd2L3kCPCQORkj0c6fYOXS5CzTd78H2xIXMvJ4btR4wZgeTtSjdGNOrcvqVhn6BH j5zcjyYnO0bPgI4daVPG2iG0ljvBrTPUhKb6RFPxFBQQF1duvPiahM3b4PWgjtpN6BWbvjmlxLJx F7nmZDyENM0pozlpgirwpPfzuG+y86/QwYStvO17zlgM9aCXiRdUto0L1i8a6xp+smhqL0ugbjxA uV5dTT4F239v6NBuU7xY2i/hSlseg54rvg7qgBlGFea1ooHRu09fM9KG46iRY7wlOPoNQGamLcGR UuounJQTNNCcJ80MKsrhUho7duxwhhqHLWl0cUjT1dP0cMMpTjfPk0dZ9MI5PehJO2CLztocL+ah XG9IlIagZ6Q5VsGKx9n2bp5W4ShEnh/JdhMYOHAgTjppNmbMmIweuT3cUCSH0PhUGofy6CnsZU+z VozaaK+qKnQGh43guHlqvJ1wiQLOoaEBw+NuyM/y8yECeo32m8dwr9XlgHlJspPtxdSuTRz6Wi19 nWileI5FF1evve2AK9Pvn7bPdvc/tQJjt5jCu/m5PhCMZj9zlpbJsW1n7MQUzNzBQHbk6I5bXRM4 Lmr1t07lFhtOM64pUbG+wcT8lsIyeUYCh38rbbvSDCzvPaKe4VxjBJnIGDW88igjJnh92jvo16FO kmgFrEiTaf9McK1eMbWjktYOMUc9XZgvarVGkdUphvpalWqDD8pvVJfAZLjjXjIvuW/g+VmDQuyY pedkfBqjXObCUkf1j0nnZ49+c4FZpqjVlXtezVkNjzV51NKIEdHkLvMm2i8HekY5nM2lZxKcAUcW UX+bFet0tjmrZRs/xp7FyzC0Rx97F6/3VgtvsWfYAsr80UMNo8GHyW9T1m9nlsltXm9osMX+mPaz d7RvzVk7xBbzO0itmJquVHsosOX3r9pDPEGCwfIHEtWT751PwQwHv924inHl1dMjbqqDO3i4ZVJe UzJj492FyE7uYAimCW4zLa8U7juYIWY7mCcmqsHd2Dzx9v1jXvfgBcrE+d3Hvv3NeIX4eYNxPOb+ UWA0M49xeNE3DnnB48ctv2FGGtdIo/eKHraUlHT069sPgwYNxpgxY+yNA7YEh81Jy8jIdBfIiHnE /Pw0sPihMcUP57VxmHOHLcFBTxqf9qSR5havtXT0hjFQNepDOZ6RZh4086IxP58w5Ry1ygrPiPPT +AYb0/NYvLoHOXjtaTcUS+v/Gs+0eXXjxh2NM848A6NH2TwaGlzW/gn2FKgzWEwneq8q7Vd8Rs8c 9J98ND7auglJu/chy9xrXCOqytxrXHaAw6BJzmoz2iYjZMZKmeXfZ/oV2PAxJ893sydL+ZSp64m8 6Vrwupt3jH9dXO2dNViFmm1v8dCa5vSMbssYbd6adDUbBMyCLHi9wXZ9Y68mkcVZfVx/odeN7rBG giExIdaPKJHcrK7kwWFhzlPjU6AJ1rz+eUS5/rYvlhPLqywf11bzaFh6PzLKIOjNc1ExetFDeLDB Z95QPtaKmvh9iiVQd1cHt13bQNTXT2ebcQOZ879fN5+D+6ahy1zmeQ0GP41/jCVy0eUw16ozzn57 +vFOCBUNhKAMz0PpGdJMEu1pgdQt22TdXL+1Sjgj1tqZ57J3zP5G+50vna+aSt1v0xfeXAaMm4jk cdnmqbb3hpKDvT83y95VVZzu5fPz8jrlX2Moh/M8g3E81lQbME1HCPKsHUIrNacT+B3HL6Z+Hv80 9VLwt07wvOK1tH6Ie7B+sgaO8GSpWwrP77p6xGatr3dsiqb3Y8s4HDKDpVJeS2Q2lcfXO/Y7WHZw uyl5TOvL4na89LHHeFHy0jKD5Xc3VN7kmD++DJch8KeeTLtw8lidDy9+9mF5fEKTC82Wl3IJDi6/ wacpbdgiJc2MskH24MBQe7n6Ue7hgb79+tqrotLMG2UXVtMpZHkrbfkJGmz0dNFw8ueU+a+G4ovW +SYBvlWAr3pyF91o2f5J4D1hasYiXxFlxhmNNHrjaDBSLr1mXBKE276xxnJYnm9wBhA0vGmWl/OY Gde+tkDntOnHYd68M82bZi+QMr7J9qveTht7ws12zZjifLtKK9u1iuVJHzkYuZPHofCN5UiyBy1o nJTbo45VlseWfLVlO7xzrtreAcoHCfZYmoKyA3Z3sScizTPJITe2A9uVK+VbEgve39pv22riPGUu U9Fl4TfPc/YPBn75Et0B/w8TWITfP+KWQYvA1zFGBz+fL47CXJmWzn0bCxps9pZGWyg40S17wjl4 jYVKA8Ih0ErzOHLYyw/U38tZPz+va3VCbTZ32BvirpPC24kKNRUdL+dqsmP15PlZaQRGZTuZ3HZ1 JW32CMtpSepr6Avwvl17WzlMRxXcJ8DW27eIGEGx7cPi+YlYX3KL9vLaEJBjUfUChw39YWSv/aKF NJGvnqDggVg9Lc4TZz9euG2GFMvi0+H0qbF+wWBXHaTx2ZrN27HttUUYZudUeTqNLztHQnYy8VeP LWbj9zf/muh/U5b/Y4uMuO2nDZbTUbdlrDXScrENHXuScD+YJjaeoutek2J6c5yy66aPk6CeTP+E iJ+2WUdNrWA9mCfer+tmyQokipUZiKpXXjDO347lGSvPsQog5aUyNsRee2Jl8mbvLhrRK0dsvH/y U65fvv/tlxWbp6l4X1ZsOl+eH1933/YC1at/4/Evfbw5BxIGhVBENM7dVui1iO57hk30V6p5tTis WFrONcr43sxyy2cvYk7NsGHBvjbMOdo8aUfbmweGo0ePnvbS9VT7RWuXY3OX0EgL8QlPk+2W4rB1 yZwsM67cq6FsuJNDnnwnpzPSbBiQT4OyfLYFf3kz0BiioUaPXrm9DopvPOBDA3zCk8YY5bMu1Isf 7vteO8+I8+Q4YTF//Pbir3CWSyONMtKtHiNGDMPZZqRNmjTR6kXzwtPJv5FbMrfILctOsptixNaH c0+4dc9Cn2MnYf8HW1FenIdUw0HPknuikbOqOa/IOiPfRLDXPJQc+kSqeZh4A3PGjAm2ZNSD7Uz5 ft+r068tztc/plpul9mdHPuKinLfLpLyrSxv2wyK6MlB+R5L71zwj3sJKc4y2n93xzWsUQl+dL1v Lz/JMVNtVr6rPsPqm+oqWS9bjT6MqbC0ZexL9u170NwQMmWyn1gajq7anv1xGtbTiwZCs4MJ4jCo C9yO6h6b36sTS69rbJAfQ+1fX5g7XOePn5acuM06uG+/PXisZtvLWrvvtZW/z28OfFJjr2yTZhvM zn33if7x81Cif95z28mIlsf92v7m9ZEg3SCX2nTMRQ3iBJZtgfkYz7KYj555GuHBPBE7RoPNfh2i YMVKZK+bjMg087AlZphnOwNlbtk274XtTmZU5yBPv448r7nt7zN9Rw8aBj3EFmy6M0R76yGW05rZ 3UkXVNPOoOBJebjK9k+q5sqLTV9/3yQF9Y4nOHg1YPJ4NwrWN3ri+99xRcVcHPw0vDAcbKAecXWJ CqoX10Q9qVqszFgZft1qDCIryzd6PGMp5IYiueyFM9LMUKLBlG5DdH1693EvVj/66HE2L22UM9JS U82T5n4t0xvnG12eR41LcXBR3Eqb5E8jje/upJG2e89uG0otdeXS++UNVXr8qC+HQamTmx9n5R+w Ydf99uYD6kNvGg0/1zsDbcFlQ/i0qO/Ba057+L+63bCJSeT7KadOnYqLLrrQnlzt7fSiYUPNaESG okYOhzGdkWZniDOmOFHabjpVNgyV1r8vBkydiK178hE2g5JDknwQwcxBVFq+/dZG+fYgxX6uJ5di vgVaB9aurLf70UDjz7bplWG3pQePc9sY+Je3Nv6IcmkC9XcJon/8F11zl13GN3Riuw+z17nZ2j77 R7zzvqa/+AxMx0aDQSM3Dt4xJefr8WO9BZnGivPVgsHvlzzGbdbPXhzm3olqZrzJqDV8mNX7mPYs hIzti5veAW54oa4p4B+N812jjyfLUTC5riQnOJgnQI28alULJGJery6Bg65erFtTwctdmyrIh0cp w+8D7tuOMY/7uB8eXrzfx1ki4/w8PmM75Hh7D0d4aXisNlAOKXjGo5PBbSetNpW/xfi6oe4Rx5Ud z0LIftjxPOXyHebTdmU4I9zcRzz/q3fuwvqXX8HkiSMRcW/vsPUb7c0gqdahqb/PhDKC9eE+68kQ TOcfcxEd9I88awfRcO3R4H6nbEzN2PM/ej40mMXVo7FrBk/QWKF2OrV3iDpdDkmNWBm82PqM/e9g AfU51GcTmyZWTmw85fvH/O9gmUQdiz9uujqZ4si066Kfz31H29UZM1ZAlRlLPM5fuf7aZDSI6PGi EZVkT3f279MLw4YNs/lb4+zpzlHo1asX0s2w4RwZk24XVi5ka140ezLTW9CWnrWQM6w4D63AHh7Y nrfd5qXl27Ic+1wcPWDe5P+odyzat6gLZdEg4wMEbp00e9nzvv0H3MME3sWdd0evLzI9P548z/Dj fnMC09FQ4w2tpz3t+anTZuPkk09FVnamefr4YncaaXan5vAluRlLtivT8wbD/H47M13IEiSnZSDn 6KOQvGE99m/YjAwzIt08NMtXajLyKu1BAuNKbxr5efN4TFsrhjaBPzToD6E5Q8vyWWmuxpy7wz0G v541njJ31I6zWSxYtprA7Zr9aD3cMasDjURWkF4O935H5mKFAyG2jEBU3E3efqklP54kM3BN9zRb kiTNJpcnWf/w3HR1s9fUycovM2PNepIZq8amVlBNBqd/LQ4rx/5FjUkmYhYaco0Fj2o0hWsAbjee J1ae3wdqctVF5/pIsF6x+ePuO2OElTNtTHCsceT6ZTSjK5/tx7TWhszgTwFgXz3UUMMoWi+Wx2Ox OrGceMeC5fv6kAe92XxjCduMiyAzbwofPLBzieZ5sk1rKF+3CbtfseHQT3/arWdIo87n7cpznCwn IUUDt1lO8Nvn76fpqN8y1g6i5dqr0YOdMZ66sXo1nb6+lEB/d5HBC1/91G1zJOaeYYXWvRJ6Otee qM3Ryt3vAgl9VvzmJ5Ylk8Yei90PiIu72VB6d9yqxHo2VdeGZMQWyHTBCywvfu5YtBBnWPCC6D62 5IUNyXE9smKb2Os/OJCWno4B/Qdi8NBROHrcBIwYORx9bZ20zMx0N9xpJpXdEOxWat4s/hp266aZ EULPFif/81VQe3bbWmm7dmKXPUBAo80NTZqnyD1AYEOj9IbxAk1dnU40+MyIow7FNi+Nc9m4nAeH Pyts+Q2GFLvZ+xOU+e0tyUFD0ZvHUlPPWChx9tnWHL7lGxXOPvtMTBg7wm52ZkjQaDFvWZgT6c1K 8NrFbnr2sIDfR9jjnEfO3Ry9/sHbDZ/uzLAFPftNHY/1O2wotKjKLWZLL1G+GZ97zPuYlp5qNyWT YHP/kqIGL/skezZpMNT26NotFxH949rXjAt+k2EweO3vHXHSLNqTWnvMrwfnNzlZToS1gyXkUKOb GhQUGt128+lMdz6d2VTw9aJoflLMQE2zIWPOXUuygtwDonGE+EPhZs7bP9OdrKLByfKLjmeH1DlW m8/PH/sd1NHsAAuWp8lsTFBLlCyjOd137InM9vCDS2u7jrl/MPrtyYnKil6kKNq1VYxSbtjepLg4 S0TTmOqzPpTNPux+DJn3iv205lruiY8pOf6uZxiZNKc+/1CyCbADLDe2DhTtmei18qyVa3cowfL6 PCjDPRThTDOvH3O5Fr7tI9HOC/bFjN32Y+9fizF40jGIDB+MFJsOUW1r4fj1DgrnsaAxyDi/rGC6 jrwtY62R1gucZ42kajzK+lDdwI5uN0o+as1vdnpvzox3QvA4h3S8OUCWNqiEJWGnDAZGB48xmhPE mZ8nL+cmUAa3ebHlBTq2s1OG96EO0QtEtBivfJ4IdiB6jDcylsMhMp4gTMM6sEwe48Wijt41Cnty eKNleW6Sq52VlM2LC/Pzxs2bMj0sTm/yssRO58DF2Ml3LKg8lY5ysJPdDSkFdOXN19eHcqgz5XNp Bq6/xWPUp0aQ05fc3Eb0uL9d/yLA/MHgl+Ufi913+lpkTZEuYU1hfrYGv+vJC6Rkf/LjOfHe+3ge Kx6nF41zyehJ44vV9xfbCv9mrNEwycjMRK/c3u6pzon2KqVRo0ebJ603Us2oYRXd4rhmlFGG/9YB LmhLY43eMA6fcrhz+/Y8M9J2otAMLq6Fxv7Mssnaa1fPgORN35rbyeI8tBKbj+a8cTafzVvCw/wr rn+YEWXnhctrM/z99uM+P/QkeG0Yn6G1uMVbH7B/XOuMaXPt7QOzTzoRc0+fi0wzTjn26F/snSFr +jIf+w4D87CPO2eNFVPl+qv1YZ5TltbNt2F97CnSnkcfjZzNeTbvZi0SzCtYUrIfJaEyZGd0cx6m BJ6f1vf87uy0Nr7ubQeuLFckz1hvI/rNdLxi+IEa1p9byqPRwA1L7nSuOWZ5KMJ0plHmlREtKSq6 7i3W0jgBJsz+e1S8Elxy3lVjAk1r+keYOtl2OH8vOynVHi5wY1xmuhpHtrsdp/eQLZNE95ntcMX6 cru+8P0XHD42NV3f8drG+jOXzeAxau6pYdu1OgTPRarGNNHaOX2cwckjjLOnR50hw7Z1qSjH4qLA mM/UccE3eHjMHxb2IqJl+8pEdWLtTToV5QYluesd8zAJ9eQ/rzHsQDSdXxVfHM8bv34uvSV1w5Z+ fl+eE+Hp4uaCcW0/66NumxIo0PvvF1E7645lUCmnGb9NHaea++N2PB08+eTP4GXxtOIh9k1XZ6PJ EOiJ3r6dHzXBMjgGVhBl859b19Ae9OFDSXywN7PCvOx2Hm1/5U0M/ex55l1Ltb5j5431D3pqmd95 Xa29uLac88xZpw7Ox6sprxNsyFhr9UZ0XbpOKezY7GgVdqPjnB/+yuSNwC3caU9BuYuFy2YpeWbw RGOmaHC70ShGMEmi9W4aUbzR8ATlMf/GmGTv4OMNLdXes+fEuD+eMF+8t2cnnhXFT22ZTOyV4V/Y GO9+sVkMDSw+yceLGi8svKjyZKGI+sFkWWauTE5vCLepr+Vy+vMGVlVWhdRUe1w7qiNlMrBMb5iG p7UFuxLzGLe9E90rkfseAy+S+jERL1zJxoFMnHFs+fluPaNkH48VLxYMfpnuQsm6sKDDGJz+7k/z hVIHX594uVycR8aloxHkpycfGtGc/F9iBlWxvW+T79zkorFMw6U2cnvanLQRR9nE+qkYM3qMLW5r Dw6YDeP4Mb/1H394xTeQPCPNjCzzhO21BWG359nDAzbkSSONxpt764DLa8NZVr5fZRppJEqjr8xe 0n6gxHuQgXPbqBeX5GB+tiP7k18PlksO7Du+Dj4Lpmko0GPGuw8NtbTUFFuKY4QtyfFpHDN5kpW9 34ZRy6w72VBdkr32xs5H5zWzcqxo1+eoA71gLJs6kSXLS7QbgzOGncFCXW1o2dRIyu6GfuMn4OO1 G1BcWmydrxzdsjOcl83uRFE17dvkMfAvP57BwCMNh5pael01epOtTe/f0HmEMt25UZOJB70yqb8z WFwql9D+MD1vul4ad8D+1Mh0cswAM00944UH6qZlHt+gSjTj3F4qBluUxIY/jafrk9Ey3E3aM+l4 u05wd13bMs4228/+WQVNNL0zRGYpastyRQYrZfGB9qe+rLcVYX+tPZiTBhgPcJvoowaZO+BSs7ia mrq2Zmp+6sgmd88a9QRHy3UkyNbnG5DJMrySvW9PrpXl0hpLXvOZKBq847X188t3+cgxWoYzuv1M gW/m54cMaFh6P56jdbF0zO7qyiKixXD5mCTmc+1iOa1ehskLTB9N531Fd5wUTwR1839IuPZk+X6y WjHRLebxyuAB6sLAMnkvSDCPYIJdG+xMRMjmvW5+czH6Hz8VkaOH2b0yxb16io938Hrt3gNKvW2b 7xutdOdFTMFR2a6QDvwnYc2aNfVrdoRXaNCgQc770pCameYhUBABERABERABERCBw0mAUzXaI0R/ n7VH0SpTBERABERABERABESgKQIy1poipHgREAEREAEREAERaEcCMtbaEb6KFgEREAEREAEREIGm CGhR3KYIKV4EREAEREAEREAE2pFAsvfkSTtqoKJFQAREQAREQAREQAQaJKBh0AbRKEIEREAEREAE REAE2p+AjLX2bwNpIAIiIAIiIAIiIAINEtCctQbRKEIEREAEREAEREAE2p+APGvt3wbSQAREQARE QAREQAQaJCBjrUE0ihABERABERABERCB9icgY63920AaiIAIiIAIiIAIiECDBDrli9zb691dDVJW hAiIgAiIgAiIgAi0kIA8ay0Ep2wiIAIiIAIiIAIi0BYE9DRoW1BWGSIgAiIgAiIgAiLQQgLyrLUQ nLKJgAiIgAiIgAiIQFsQ6JDGWiQSaQs2KkMEREAEREAEREAE2p1AhzTW2p2aFBABERABERABERCB NiIgY62NQKsYERABERABERABEWgJARlrLaGmPCIgAiIgAiIgAiLQRgT0NGgbgVYxIiACIiACIiAC ItASAvKstYSa8oiACIiACIiACIhAGxGQsdZGoFWMCIiACIiACIiACLSEgIy1llBTHhEQAREQAREQ ARFoIwIy1toItIoRAREQAREQAREQgZYQkLHWEmrKIwIiIAIiIAIiIAJtREDGWhuBVjEiIAIiIAIi IAIi0BICMtZaQk15REAEREAEREAERKCNCMhYayPQKkYEREAEREAEREAEWkJAxlpLqCmPCIiACIiA CIiACLQRARlrbQRaxYiACIiACIiACIhASwjIWGsJNeURAREQAREQAREQgTYiIGOtjUCrGBEQAREQ AREQARFoCQEZay2hpjwiIAIiIAIiIAIi0EYEktuonDYt5p577mnT8lSYCIiACIiACIhA5ydw/fXX t0sl5VlrF+wqVAREQAREQAREQASaR0DGWvM4KZUIiIAIiIAIiIAItAsBGWvtgl2FioAIiIAIiIAI iEDzCMhYax4npRIBERABERABERCBdiEgY61dsKtQERABERABERABEWgeARlrzeOkVCIgAiIgAiIg AiLQLgRkrB027JkYNGoU+memHDaJh0dQU3o1FX94tJAUERABERABERCBlhHolOusRSKRODQyMePc CzCyfC0ee3l5THwOZl1yDnI2/BsvrtgZE9e83XD3cbj43JOx5/UH8Oh7Bc3L1AapmtKrqfg2UFFF iIAIiIAIiIAINEKgUxpr4XA4TpVLsCuUjZMmzcTkhcuwvLQ2SWjoNJwwtD9WLdmN+Hlr0za0Fams QoVFVlehxTIakl33eHdMnDkekU0rsGZnoBJ1E9XsNaVXU/E1grQhAiIgAiIgAiLQLgS6kLEGbHjj PVQcfQqmTh+EZa9urQE+YcpYs7I24u2NlYhn5tUkbGQjEo4gifGRcKsaa5HUEZh74onYXboMq/Ka 1rYpvSIVZl22gd5eIforAiIgAiIgAiJwsAQ6qbEWis+h4F2s2ncKpk2YipxXNqOIqRKGYsroDJQs W4qCMPNlYcZFl2POmFwnY//mhXjwsTdxwO0BucfOw+VnTkYm98u24Z8PPGQyaaNFh16dseaV33fa +fjsp8e7tFX7dqMwqQdSP3kFdz/vDcM2JIui+860vKd4eYES/PuuO7FkXw/Mu/o0ZxQOmPNV3DjH jv/vn+x4wzrX1ysLsy69HCcf5dWvcNsOpLHAgN6N6cWkXuiBM79yLYZve8nqszp6LAUnXf41HFPy Gv7wcjW+dP2nsW/NBuRMmYze1Ztx/6+fwtBLr8GpVrYzbFGGDQufwdNvbYnmj9VtGxL69sKuF+/H s2sNciNtE8maiC999dPYu2QpUibNxohsS162Ay89+gDe3xMVry8REAEREAER6IAEOqWxFgo15HGq wNIlmzFt7lhMH5SMF7dUIm3yNAxCJV5/ez1CoQSMM2NizpgQXnv4j1iVOgnXfuZkXHbaZtz9ry1I Gn4WvmSG2va3nsYf3i3DOV+8HPMun4ePfv88iqPGWsSMHpafNPosXGOGWulHb+AvL61C76nzcMHM vqjOTPLiG5OVNgmXmqEWWj0fd/xrEwaPGYKSEsotwJJFazD+rMnYv+Z1LNiwB3sLwhjTiM6+sebr Ne7CK81Qy8Dq+Q/jte1mXJ1zHo61juvHN1bHkjodvAAbt1fi2AmzMOrvK/GhxYX6zcDMwRnY9NzH CIXHICM1A73MUNu0aAEW5RciP5SB0dV78MbT87F2ZxVmfe5qTJl5Ivq8sRmcKTjJ6kHdPljwOF7c UIXZ512AaSajOC3ZMWusbSLhNGQkZWDMzNnIX/MGHtuYjDPPnYVPnXIMlj7+fh3NtSMCIiACIiAC HYlApzTWwqEGPGvWMnveWYo9c4dj4gnjMH/TMkydNgrYvxqL99rwZcJwzBhjLpldi7GxJB1ZKdux qQwYP3ggwqFNlmeiSdiNleuKMKBbFVatzcP4GUdjQs6zWFTle9ZCljaEicdZ2kgennj0NeywXDte fhqjj7sB4+3hBxffmKzSSpRbnj6Dx+Cobh9j+dLaByK2f7AFFWaslXyyGuvXmG8wYTjOa0TnSCig V7g/jhvbHZGN/4dnl260EoB//PUVjPl/55iuUb0b0evtwgSXx/+zauF7OH/8KTj+uFx8sGQPJsye jqTqTXh1RQHC2V65u968Fw//e7ufBa8+/rjbzsrKwpp1uzFlRgRlxovsp1o9qje+hKfeoekHzH/0 NYz3dQsPabRt/HrmL/0b7pq/wXJnYdIZszA+McnxpjwFERABERABEeiIBDqlsRaK+4CB3zxmmG0+ D+eMmoyBKfswZUASdr28BKWWJ5w7EH2YrPc0XHndNCTZWF1lZci8Yf3QnfHuEYK+OOvaqxDiQF6o 0v4Xo8K8atXRJ1D5JCrLd769ylLst23PdPRQh+DH83GE+LLCZavx0FODcfWFJ+Dca7+OecWb8Px9 D+L9Qnt4IZLshhAjyeZtaobO+QG9qroPQn9Tu/hAlcvLqoZNDkOt3g3rFfKHel0O+7PjLbxXdApm HD8DocXv48SxGSh6+3Vsp15WrhWFiuLimrKAVMy44HKccexQJFWW2SBohjH8yM3xq4qyrzhQWpM+ qFtV98bbhvVkeaV5u6L5k8Ga+bxtU0EEREAEREAEOiSBTmmsNfVE59K3VuKc4dNwwZXz0NNmrj23 eKsZDNZ+e7eC05v6fzIftzzwbr0GHZFks7vMW3bXTXc7b1kwQbib78EyQ8WEJdNySE1Flm3nM2FC DnJTuWGeNRffsCymKlo5H7fbZ9CUs3GFGW3nXXA83rv3bcsbLaeq3MlpSuea9DY8G6koBZ8fzbRh RZ8R46mq/2BEciN1ZLK6oRyvv7MJM84cj/+4aAD6oxjPLdxosvlErM+jtqz0KRfibDPUVj3+Wzxp XsGqSVfg55dE4/fuBBc86ZOVXqNbda8eNfPpml1PMz69ull9nbIe77p6a08EREAEREAEOg6BTmms VVc3PAzqmmbt2/igbBrGDeyByLZXsbjUT/8RFn9QjIvHnY3PzNiDpxZ9jJTcIRjZ14Y81+3E4oUr cO7w6fjC5+fivr+9iDxk4+iJI2wUdRW2Vztfmtk8YbD8999ZY2mn4OpvXIE315Zg3IlTnNeuosqL b0xWXtpRmHt8L6x5Zwk+WboWe81YG2IyKTdcbd48q0S3/sNsf69tNa5zOKBXqHAV1hVdhJljZmLO qM1YUT0SF11+ljOIqqJ6N6bXjsr6Hbtw4ZvYceYVGDcpA9WfLMDiIo9lsFy/PRLS+ChDCJWJKUjr Mx6Xzh1tRmwRRqVXY1HJB1iyoQzn21y/r1zSAxttJuGJk4e6Ap1uVc2vp1de1FgzI9Uvv772OiIC IiACIiACRz6BTmms+V6jhvHnYdHyXRg3sx/WLlpU48lh+ncfvBPdrvkSTj/nGky0qVwM5R/+Eyts flp4zTO4859JuGbebHz9x7O9SPMmvfDhcmw1N061HamOerxKlz+BO83b9vnTJuLkk82kemMB8qed jnHJnqencVm5mDbnfMyxjwuVu/DC/73r6blvGd7cNAenz7gYP5txFl741S14vTGd6+hVjmf++ncM /9oFOPULX8epJjxv5VocmDweyTaMSG6N6bW9vO6cNU+5tXjLDNxLxmXivQVv1rCkYy3Ig2kLly/G plNH4rhLv47jzGjbYmXv7zEe59xwFdbddD/evvd2ZH7hSpwyYQb6hvKx4MkFOOHS05EW1a3Rtokt L8Eznllu0/2BqRREQAREQARE4MgkkLBy5Uq7zXWsMGTIEBthdGOKcRW/+eab4x4/mIORbr3Q24qo rCxBcTHncQVDGnoNsKUvLG7v3uJgRMPbCaPwrV9ch+4rnsTNjy4NpGtYVnavXuhmKXfspQetbmBc emUl8m1OmB8a19lPxe80DDD9E0oKkFevbn66hvXyU7T0u9eAAagq2IH9hjW11wDkVBZYPWIZA4nT r7Rh0vF47/4f4ol1tW695tezpRoqnwiIgAiIgAjUJ3DTTTfVP9gGRzqlZy3+66YOkub+fG+uWdxs 5cjPy4sb4x8M956DW2+ci6KP12H7gRSMmjwGOeaFm//iEpvMH/RQNSyrOD/fcsQPceMa1Tkopxx5 Tehv/sQm6xiUeDDbQXYV+XluniDz55x8PX5wVi7Wr9uKsvS+OOao/vb47hK88EFFdP5ZtJRm1/Ng tFJaERABERABETgyCXRKY+1IQJ24dwVefKsvJg7ui4F9k5G/8i088dxzWF8cNNSOBE2PHB2K1r6D xSOmY1D3vshJrsD7rzyBZ19a6pYxOXK0lCYiIAIiIAIi0LYEOqSxdlg8Z63NObIXbz33GN5q7XI6 kfzE/BV4+sEVnahGqooIiIAIiIAIHDqBxEMXIQkiIAIiIAIiIAIiIAKtRUDGWmuRlVwREAEREAER EAEROAwEOuQwaFP1vvDCC5tKongREAEREAEREAER6BAEOqWxNnbs2A4BX0qKgAiIgAiIgAiIQFME OqWxlp6e3lS9FS8CIiACIiACIiACHYKA5qx1iGaSkiIgAiIgAiIgAl2VQKf0rGVmZnbV9lS9RUAE REAEREAEWolAaWlpK0luXKw8a43zUawIiIAIiIAIiIAIJN3GVwAAPa1JREFUtCsBGWvtil+Fi4AI iIAIiIAIiEDjBGSsNc5HsSIgAiIgAiIgAiLQrgRkrLUrfhUuAiIgAiIgAiIgAo0TkLHWOB/FioAI iIAIiIAIiEC7EpCx1q74VbgIiIAIiIAIiIAINE5AxlrjfBQrAiIgAiIgAiIgAu1KQMZau+JX4SIg AiIgAiIgAiLQOAEZa43zUawIiIAIiIAIiIAItCuBTvkGg4MlyhWJ9+/fj4qKCoRCoYPNrvQiIAIi IAIiIAKtTCApKQlpaWnIyclBV3tTUZc31goKCpCXl4cNGzZg27ZtqK6ubuXuJvEiIAIiIAIiIAIH SyA5ORmDBw/G6NGjMXDgQOTm5h6siA6bvksba2VlZc5Qe/XVV2WkddguLMVFQAREQAS6AgE6UzZv 3uwcK6eddhoyMjLcpyvUvUvPWSssLHQeNXnTukJXVx1FQAREQAQ6AwHeszkaxnt4Vwld2ljjHDVa 6QoiIAIiIAIiIAIdhwDv3byHd5XQpY21SCTSVdpZ9RQBERABERCBTkWgK93Du7Sx1ql6rSojAiIg AiIgAiLQKQnIWOuUzapKiYAIiIAIiIAIdBYCMtbavCUzMWjUKPTPTGnzkhsvsCm9mopvXLpiRUAE REAEREAEWkagSy/dQWT1x7wzMePcCzCyfC0ee3l5DNUczLrkHORs+DdeXLEzJq55u+Hu43DxuSdj z+sP4NH3CpqXqQ1SNaVXU/FtoKKKEAEREAEREIEuSaDLG2vhcDim4UuwK5SNkybNxOSFy7C8tDY6 NHQaThjaH6uW7Eb9fLXpGtuKVFaBz69UV6HFMhqTXxvXHRNnjkdk0wqs2RmoRG2COltN6dVUfB1h 2hEBERABERABEThsBGSs1TPWgA1vvIeKo0/B1OmDsOzVrTWwJ0wZa1bWRry9sRKxJl5NoiY2IuEI kpgmEm5VYy2SOgJzTzwRu0uXYVVe09o2pVekwqzLNtDbK0R/RUAEREAEugKBN954o0XVPPnkk1uU r6NmkrEWjvMu0IJ3sWrfKZg2YSpyXtmMIrZuwlBMGZ2BkmVLUeDyZGHGRZdjzhjvdRf7Ny/Eg4+9 iQPRnpB77DxcfuZkZHK/bBv++cBDJpM2WnS5EGeseWX3nXY+Pvvp8S5t1b7dKEzqgdRPXsHdz3vD sA3Joui+My3vKV5eoAT/vutOLNnXA/OuPs0ZhQPmfBU3zrHj//snO96wzvX1ysKsSy/HyUd59Svc tgNpLDCgd2N6MakXeuDMr1yL4dtesvqsjh5LwUmXfw3HlLyGP7xcjS9d/2nsW7MBOVMmo3f1Ztz/ 66cw9NJrcKqV7QxblGHDwmfw9FtbovljdduGhL69sOvF+/HsWoOMRuqZNRFf+uqnsXfJUqRMmo0R 2Za8bAdeevQBvL8nKl5fIiACIiACRzSBcLx79xGt8aEp1+WNtVAontepAkuXbMa0uWMxfVAyXtxS ibTJ0zAIlXj97fX2svcEjDNjYs6YEF57+I9YlToJ137mZFx22mbc/a8tSBp+Fr5khtr2t57GH94t wzlfvBzzLp+Hj37/PIqjxlrEjB6WnTT6LFxjhlrpR2/gLy+tQu+p83DBzL6ozkzy4huTlTYJl5qh Flo9H3f8axMGjxmCkhLKLcCSRWsw/qzJ2L/mdSzYsAd7C8IY04jOvrHm6zXuwivNUMvA6vkP47Xt Zlydcx6Otb7mxzdWx5I6fbIAG7dX4tgJszDq7yvxocWF+s3AzMEZ2PTcxwiFxyAjNQO9zFDbtGgB FuUXIj+UgdHVe/DG0/OxdmcVZn3uakyZeSL6vLEZnCk4yepB3T5Y8Dhe3FCF2eddgGkmozgt2TFr rG0i4TRkJGVgzMzZyF/zBh7bmIwzz52FT51yDJY+/n4dzbUjAiIgAiLQugRmzpzZogLi37tbJKpD ZOryxlo4FMezZk23552l2DN3OCaeMA7zNy3D1GmjgP2rsXivDV8mDMeMMeaS2bUYG0vSkZWyHZvK gPGDByIc2mR5JpqE3Vi5rggDulVh1do8jJ9xNCbkPItFVb5nLWRpQ5h4nKWN5OGJR1/DDsu14+Wn Mfq4GzDeFux18Y3JKq1EueXpM3gMjur2MZYvrX0gYvsHW1BhxlrJJ6uxfo35BhOG47xGdI6EAnqF ++O4sd0R2fh/eHbpRisB+MdfX8GY/3eO6RrVuxG93i5McHn8P6sWvofzx5+C44/LxQdL9mDC7OlI qt6EV1cUIJztlbvrzXvx8L+3+1nw6uOPu+2srCysWbcbU2ZEUGa8yH6q1aN640t46h2afsD8R1/D eF+38JBG28avZ/7Sv+Gu+RssdxYmnTEL4xOTHG/KUxABERABERCBI4lAlzfWQnHmrHkNZIbZ5vNw zqjJGJiyD1MGJGHXy0tQaunDuQPRh4l6T8OV101Dko3VVVaGzBvWD90Z7x4h6Iuzrr0KIQ7khSrt fzEqzKtWHX1rAp9CZdnOr1dZiv227ZmNXpOE4MfzcYT4ssJlq/HQU4Nx9YUn4Nxrv455xZvw/H0P 4n17XVo4kuyGECPJ5m1qhs75Ab2qug9Cf1O7+ECVy8uqhk0OQ63eDesV8od6XQ77s+MtvFd0CmYc PwOhxe/jxLEZKHr7dWynXlauFYWK4uKasoBUzLjgcpxx7FAkVZbZIGiGMfzIzfGrirKvOFBakz6o W1X3xtuG9WR5pXm7ovmTwZr5vG1TQQREQAREQASOKAJd3lhr7KnOpW+txDnDp+GCK+ehp81ce27x VjMYrP32bgWnN/X/ZD5ueeDdeg06Islmd5m37K6b7nbesmCCcDffg2WGiglLpuWQmoos285nwoQc 5KZywzxrLr5hWUxVtHI+brfPoCln4woz2s674Hi8d+/bljdaTlW5k9OUzjXpbXg2UlEKPj+aacOK Ph/GU1X/wYjkRurIZHVDOV5/ZxNmnDke/3HRAPRHMZ5buNFk84lYn0dtWelTLsTZZqitevy3eNK8 glWTrsDPL4nG790JLnjSJyu9RrfqXj1q5tM1u55mfHp1s/o6ZT3edfXWngiIgAiIgAi0P4Eub6xV V8cfBnVNs/ZtfFA2DeMG9kBk26tYXOqn/QiLPyjGxePOxmdm7MFTiz5GSu4QjOxrQ57rdmLxwhU4 d/h0fOHzc3Hf315EHrJx9MQRNoq6CturnS/NbJ4wWPb776yxtFNw9TeuwJtrSzDuxCnOa1dR5cU3 Jisv7SjMPb4X1ryzBJ8sXYu9ZqwNMZmUG642b55Volv/Yba/17Ya1zkc0CtUuArrii7CzDEzMWfU ZqyoHomLLj/LGURVUb0b02tHZf2OXbjwTew48wqMm5SB6k8WYHGRxzJYrt8WCWl8lCGEysQUpPUZ j0vnjjYjtgij0quxqOQDLNlQhvNtrt9XLumBjTaT8MTJQ12BTreq5tfTKy9qrJmR6pdfX3sdEQER EAEREIH2I9DljTXfcxS/CfKwaPkujJvZD2sXLarx5DDtuw/eiW7XfAmnn3MNJtpULobyD/+JFTY/ LbzmGdz5zyRcM282vv7j2V6keZNe+HA5tpobp9qOVEc9XqXLn8Cd5m37/GkTwSeRP3pjAfKnnY5x yZ6np3FZuZg253zMsY8Llbvwwv+96+m5bxne3DQHp8+4GD+bcRZe+NUteL0xnevoVY5n/vp3DP/a BTj1C1/HqSY8b+VaHJg8Hsk2jEhmjem1vbzunDVPubV4ywzcS8Zl4r0Fb9awpGMtyINpC5cvxqZT R+K4S7+O48xo22Jl7+8xHufccBXW3XQ/3r73dmR+4UqcMmEG+obyseDJBTjh0tORFtWt0baJLS/B M55ZbuN9gSkUREAEREAERKDtCSSsXLnSbl8dKwwePBhpzvsSX+/MTLdgRvzIwNGNGzfinnvuCRw5 +M1It17obcOWlZUlKC7mPK5gSEOvAbb0hcXt3VscjGh4O2EUvvWL69B9xZO4+dGlgXQNy8ru1Qvd LOWOvfSg1Q2MS6+sRL7NCfND4zr7qfidhgGmf0JJAfLq1c1P17BefoqWfvcaMABVBTuw37Cm9hqA nMoCq0csYyBx+pU2TDoe793/Qzyxrtat1/x6tlRD5RMBERABEWgvAtdffz1GjhzZpsWXlja9yHxr KNTlPWv1Xzd1kJj353tzzeJmK0d+Xl7cGP9guPcc3HrjXBR9vA7bD6Rg1OQxyDEv3PwXl9hk/qCH qmFZxfn5liN+iBvXqM5BOeXIa0J/8yc2WcegxIPZDrKryM9z8wSZP+fk6/GDs3Kxft1WlKX3xTFH 9bfHd5fghQ8qovPPoqU0u54Ho5XSioAIiIAIiEDbEuiQxtohG1hty7jR0hL3rsCLb/XFxMF9MbBv MvJXvoUnnnsO64uDhlqjIrpcZNHad7B4xHQM6t4XOckVeP+VJ/DsS0vdMiZdDoYqLAIiIAIi0OkJ dEhjrVO1SmQv3nruMbzVqSrVupVJzF+Bpx9c0bqFSLoIiIAIiIAIHCEEEo8QPaSGCIiACIiACIiA CIhAHAIy1uJA0SEREAEREAEREAEROFIIdPlh0AsvvPBIaQvpIQIiIAIiIAIiIAL1CHR5Y23s2LH1 oOiACIiACIiACIjAkU2gqMjee91FQpc31nJzbR00BREQAREQAREQgQ5FoCsZa5qz1qG6ppQVAREQ AREQARHoagRkrHW1Fld9RUAEREAEREAEOhQBGWsdqrmkrAiIgAiIgAiIQFcjIGOtq7W46isCIiAC IiACItChCMhY61DNJWVFQAREQAREQAS6GgEZa12txVVfERABERABERCBDkVAxlqHai4pKwIiIAIi IAIi0NUIyFjrai2u+oqACIiACIiACHQoAjLWOlRzSVkREAEREAEREIGuRkDGWldrcdVXBERABERA BESgQxGQsdahmkvKioAIiIAIiIAIdDUCMta6WourviIgAiIgAiIgAh2KgIy1DtVcUlYEREAEREAE RKCrEZCx1tVaXPUVAREQAREQARHoUARkrHWo5pKyIiACIiACIiACXY2AjLWu1uKqrwiIgAiIgAiI QIciIGOtQzWXlBUBERABERABEehqBGSsdbUWV31FQAREQAREQAQ6FAEZax2quaSsCIiACIiACIhA VyMgY62rtbjqKwIiIAIiIAIi0KEIyFjrUM0lZUVABERABERABLoaARlrXa3FVV8REAEREAEREIEO RSC5Q2nbQZWNRCIoqtyFXaWbUFpdhKpweQetidQWAREQAREQgfoEUhLTkZncA/0yR6BHaj8kJCTU T6QjLSYgY63F6JqXkYba1uI12FO1EVlZaeiemmqdOK15mZVKBERABERABDoAAd7rqir3Y2PJEvRJ GYkh3SbIYDuM7SZj7TDCjBUVDodRWL7TGWo9emap48YC0r4IiIAIiECnIEBPWmpaClJSk7Gn0JwT Zbnomd4fiYmabXU4GlgUDwfFODL4KyMUCiHvwHrnUZNLOA4kHRIBERABEehUBHiv4ygS7328B/Je qHDoBGSsHTrDehLYOelVq6qqQll4n/ulUS+RDoiACIiACIhAJyRA7xrvfbwH8l4og+3QG1nG2qEz jCuBvygqKipgZpuGP+MS0kEREAEREIHOSIDeNd77eA/kvVDh0AnIWDt0hvUk+EOglZWV9eJ0QARE QAREQAS6AgHeAzUUenhaWg8YHB6OdaT4w6DV1dWACNdhox0REAEREIGOQ2Dj8nxsXL4HJYUVTuns nmkYeWwf+/RushK8B2oYtElMzUogU6JZmA4+ke9dk7F28OyUQwREQAREoH0JlJVUYfHzm7FvV6lT xH9I7kBRJVa9th1bPijE8ecOR0Z2SoOKyqvWIJqDjpCxdtDImpeBxho/rR2qQ9UoLN6L/Qf24UD5 AZRVlLpJnUhIREpyMjLSM5GVnoWczO7o2S0XyUlq8tZuE8kXAREQgY5O4J3nNmLcyGMw67JZ+M1v flOnOjfccAMWLVqEd55bgdM+P7ZOXHCnre6DwTI767bmrHXQlq2qqsDWXZuxbMN7WL15Fbbl55nB Voxqm8yZmJyEhKQEhMLVKD6wHzss7oNP1mLFR+9j254tqKrWXLoO2uxSWwREQARancCG93Zhz7Z9 mDVrliuLxhmf7OSH2wyMYxqmVWh9Ah3SzdIWHqvWR9/yEvYU7caWnZtRVLoPSYkJSEpItu9EW3ww wZ48NUPNf81Honn27EGccCSEhHDEed4+2r4e+YW7MbjfMPTu3qflSiinCIiACIhApySwbsl2cL7Z T3/6U/zgBz9wdfzv//7vOnVlHAPTjj6uX5047Rx+AvKsHX6mrSpxy65PsPrjVSgsKfQMtcQUJJkn LSkp0fZtO8UMN9tPtk9KQooNe1ocj7t4b7uotBBrN65xXrZWVVbCRUAEREAEOhyBwt0lzlijwfbj H/+4nv48xjh+mFah9Ql0SM9a62M5Mkv4xIY9P9z8AaejmUGWjETzqCWaF818aWaMmZFmXjVzr7lj sGNwK92YEWdDowlhNrU9nRpKQNiMuBCq8OEnH9q8OmBI36FHZoWllQiIgAiIQJsToBHWWGgqvrG8 imsZAXnWWsatzXPtLNjpDLVIghleZq3RSONwJ4c+ExOT3CchOdF50hLNaEtyHjXzsDHOtl0aGndM z7w05hLD2PDJOuwu1JyDNm9QFSgCIiACRyiBzO4pNXPU/OHOoKo85s9hY1qF1icgY631GR9yCRWV 5Vi/8QNUc+4ZDTUb0qSh5n3MELMhT74slwYZ4zn06Qw27oPDo148jTln4Pl5Lc4c2Vi/6UOwDAUR EAEREAERGH/CEDfE+ctf/rIGBh8s8B8u4EHG0cPGtAqtT0DGWuszPuQSNm7diH0V+9zApvOImUQO cnoPFHDL9ullo2lmxhofMnDGm23zwQPnR3Pxls4MPeZ2uaJ/iiv3Y9O2TU7OofypKNqHPXv2YX9R OQdcj/hQSn13cMmTg1e1aPm7eGnRnoPP2Mwc4T0b8Y+n1qMp1RpOF8L6vy/Eu1s7+5O/HbOerd1/ 6nWz6gK88cjb2N5Uh6qXUQe6IoHJJw1HzwHZeOGFF1z1v/nNb9bMUeM2A+OYhmkVWp+AjLXWZ3xI JVRUVmDLDhpSNrms5i+3khAJe0Zb1FzjQTfESUvMGWlRD5qfKjslF587+gfISct1+V2G6J+tOz5B pZXVkpBQvB2PfPm7uGLurfja2bfii3N/hMtm3I5VJZ5mLZHZnDybHvkjPjP9xsDn51hWU2Yl/vXt 7+KSM/6B/Bhh1PfRK76Lq6jvebfi6tk34o6nNh6UgZn/+uP41VuFMZIP327VttV46Ffr4hprFe// A5ce/w8UWXENp6vCe7f+A+/srDp8Sh2RkjpmPVu7/8Q2VUJZPv5wx7PYVd2652RsudrvuATOvXYG lqx8C1/72tdqDDV60vjhMcYxjULbENADBm3DucWl5O3KQ3m4zM1BqxESvd6a4wwRW54jEuFLc73A ZU0SbS9illw4ujCv7SE7uTtOH/ZFl+j8sV/HMx/cjoKy3Z6HzY5WRMqQtzsPwwePiEpq5lekAA/M uQPP507Fj+dfjIl9UlFRsg+bVu5Cz3Rfq2bKOthk9pLgSOLx+PUr89DTTYhNRma2V2Zi3lr875v0 Nr6JBWvOwGUT0jzppu8jF9+Bp3Jm4/ZX52FYdhJ2L3oZ//nNu1Ga9V38z1nNXM7EDN6eNgew1YI9 1cvGSY9TQProk/Cz+0LItrhQNF28WSMpPYG01NQ4EjrToUT0tFGY4ngAjuBqptsC1T1LWrH/xNbd HkgaCOsQCiLQTALdemTgihvnYNlrH+H91z9Cwa5ilzO3XzdMOWUUpp46qpmSlOxwEGjDq8XhULdr yQjb2mhb87Y4pxq9aGaTmcvMjBFuJ4XMs2ZmWbXtpPKAGWd2d0+0b5orkbAZcGashUxGZnIOTh9y bR14F437Nv687Hs060yel2dr3nYMHTjcDa/WSdzITsWa9/BPK/c/H7jMDDXPUErL7o6jZ3WP5qrE yvv+ip/etd72M/DZP30HF0334grMSLrxmy9jv8VM+PYXcdNlY4Cy7fjd5a9g8jdGYMF/PY+PLe6M W76Da8/qH5UX/CpHaEguBmWn13ur15on56Nq3BScEVmGhx5dic/cOt2lob5/L8zEfz1yvhlqnr59 Z83Fz659F9/78RvYedbF6LVxOX7+5Uex2hxnlePPwiMPnoasYLG2zRMnqWI75v/PA3jg5XIr63j8 5DcXGAN7IrdqD/5+45149M1yhHMn4vsPfx5T7HhVA3IjO9bjgRsfxgvrvDGqCx74CS42+ZHu1Xj/ 70/j9lsXm+E2AF967Cv49Mh0VO5ag3vuBW7+bZ869U4o3IjbTr8LPX73P7huVgZSzZor3bQUv//u M3izMAGDz7sQ//O9meidXIllv/szfvHwJ65WabPn4te3zUW/Bo+X47Vv/wmbTpmJ/FufwZIrvoIn vzHS5eWftXf/FncnnIPfX2/tZ6Fi+cu4/nbgjgfnIvTuq/jJV19Anh2vHjoR3/vDZzF9AA3ISqx5 5GncfMf7zILc08/CD394GgaZdbr1yQfxQMEYTFr3DB7+4DT85cWz0cOliv4J8M0aOgAHtibgbD8+ EFfLvsq8rD/D3WsS0N3M36xuQEnJIHz76SsxKbuiwf7pi+S3p9N4nLDrZfz5+SKknH4ubr0sHXdc 9aSr2xm/sD76KfbRhvp77fFwz54YXFiEnC/6JdTG1Zwj0yrxwMV3IvsX38clY9Kwb9F8XHvzPvz6 uc9heHoI79/yOyyd+0VcOWy76XAfllr7ps0+C7f/9jTwjY2xDO999mi/MPsuwfxv34aXRnwOv/nG OCTHZZZUT0a9dghI1GbnJUCjTIZZ+7evhkHbvw0a1CBsS24UFRfRNrObtRkW9iQoPWYRO+K9xoN2 m5lbZpC5l+Wa0RUKhVFl33yTQSgcMkOtWz1DjeKeWvNbT1bUuDPTAPtLCsAyDybkLVmFcK9T7Qbs GT6xeQtffgw/uScLt719Gx66/1Q89rVHsMGGYhLz3sWXzVD7j2duxZP//jISbv8zntpYhYTqCuzc shp3fXcVznv8+/jF98fgxR8vcUN+sbLpd0reshyPP7kQzz/yMv69vMBLUrUdTz5ciHN/cAmu+fLx 6LbgX1hWREsXoL6hXifhmKhh6WUAhp803ZY3WY+8kjCW3/kw3pp9GR599zb89dfTEfXJ+UnddyS1 O8JPPI9Pjr8Kd8//Ji4teQf/c9MSG0oNYclNt+GezHNd/l99IR83/9ciG84MxZcb2YP/Pe/PeLrP aebp+ykenP/fOGMYTcEUJBa8iV+8lIGfz/8uvnpiHn7xtBnuFsL7i/HJIu9Xrtu3X8BJdsP9nRlq H15xjRlqngclxSzMRT97B2NuuxH/+8hlCP/jWfzyn96TvznT5+LOhbfhyQVfRK+FL2P+h94QeEPH 9+XvwAu3voij/3wD/nLNYKeH/+eo44/Gznv/iQ/KybgSb/5mARJOHYPcvOX4ihlqE3/9HWNxC348 Nx+3XfAYtlkq9oub79iMbz9zC/628Lv41Afzcf3333VD0dX2+rRVf3kWm069Dvc8NqeuoWZ53/+5 tcvWE3D7wp/j9p+fZB4jPzTEPh2zb7oBdz3yXfzhkf/AqC0FKOrWG33MWG+of/oS/W9Ppyfx3vhL 8KfHL0OfBc/jxqvfxX9YH731W8Pw4veXuT7akLyC157GT+8uxrf+8RM8+sRlmDGk9nyJmyfUC6OH leHxF2lQm3H211etP7yPpVvsalC1DQ8+vxMTRlXi7vPvQ/W3b8AT79rUgz3z8aOntjuV4zGMJKQj wwzyt/7nZtz3wQn4IQ21BvurGddNtIPPRt8iIAKtT4B3BYUjlAANr/JIOW/bdJw5z1rEzGsaZgn2 4EDYDiaYdy1k7wflpZ9eMrdEh8VzDI1Dn3OHXFOvdhwCLarYYzJp9Fk+Dpfav/JwhTP2kg9qSKnc ctbNwEnv85/ZhSlXHofN81eZjrn458/+hoTynVZYEQrMgbR9yVqn17v3P4X1OIDVpm/PvTYZfoA5 1yzmuue+hplmAFaX2q3YbIC6JQSqZHxQaY8zmK1RGZ2eVfj6G1idMALndguhIn2s3cyX4Kl/bcOM SwZZRs97FZAQs5mEwaeMRfdbH8VN6YX4wlUnI96b7xIq9yFyxRfxlfNHuvznfGUinv1hIQ6Y0fTO y0Dm0BW455aPULVhJ1LWF1qp8eVGNn6EV6yCX/n2KeYhtMbNzjX/I6tTZUO8U3DPXWeD/pqksT3R szJ6utaBYQseFyzHL//jBaw77wt4yG7Afqgyu2z2n76KM4+ludkHV859GD/7ZJ9t98OoGQOxesFC /HtLoSsvoYqPhGQ1cNyeKjZZx//mBpx7bI4vvuY77dgT8KnIq3h6SQl+OGUj7llnnss7h2PXWwvM A3wqLjmlv/MAHnPlBRh0791YtrECvaxfRK64DjOHcKA3HRfechqevOZdbC43D6g9mbzvvCvw7fM9 T11NQdww43bh88BZfzJe6ebFHHMM5vR8AtaznEczPnugR4/uRoCGyl1YmDgJtz1MrrbfQP90Y8yU GQ0JTqer8d+XUKdynNQzgoLbrsXMkWnWR0e4VCkmb3lceSEULliGyOXXYdYAtsUwnHxOTzzr1hKt xNq4eZIw8ZKpwHfWYe/VaXjjvVzMOq4Qr7+1A2cdWIotw87ClLINuMP6Tu+XF+CP76Zg27oErJ98 wOni6RtgaCdVZmQH/v69n+K9tSfgjpfOdh44eoEbYlZPhpOsPyIgAu1BQMZae1BvZpk01hISPIMq 7J7mNAPNHF8JNk+te3JPfHbSjXhm3R04YIaDjYfa2FyyGUb2i9ju+d3sYQJ/jlqwuGfWmaFWboYa PWpmpNHg4ycSMqvN1l1jmQcT+k45Fkl3vYkVe07HrKi3qmrbOvz1L4sx8PPTzOQwI2r8NJz22TFI KA3ZS3/TMNTmsu23GxsShmP2xbPQuyqEOefNRa9RvHEz9ER/G6piaNzPZ0+dDpuOiz9/mt3u/VCC hX9aZjwS8MfzfoSinhnobo6m/b96BzsvuRgDnb5L8WHJ6ZgaHQZlzh0rzHhIHIOBdqz/BdfhrtHL 8Y87n8EPz34B1z3zCzN6DWog0LQJp9X63GxRlWisGYi2Nej0aTj7pByUVx2PeZk93L2/Rxy5p0Zz pcY5EyM9uyOKoZGHH0g4Dd3Ni1axYhO2VU/C8KgsI4zsjFq9zW/plVb2CW45+Q8o/Mx5+MbFE1F5 70KnMxo6brkoq1tObX09QdG/Cbk4+1sD8PV7F+GNmatRevI5mNojgh2llYjY+GUd29KylJRVItOM h3BaMIbbNFE9HXNYoXjB3mtLvt0y4wCz3tIQe/aklb/7NX73r4H43oIrMSo6n7Kh/hlbNNs7p3tt /TmQ6xaZNvbBPhpfXjXeNadvzrDa/C579E/8PDbPdPJxGBR+BM/ctxsfnnEO/vjZrfjiDW/gicXL MPHa/2fDlxuchBPOn41Z3SOoOu94XNfPftxY8PSNZZiBtIweSCzcgo+3VmHwEDJvmBkfzGmwHViI ggiIQJsRqL2St1mRKqi5BMI0nGz40w2YRA0rLoqbYzPHaagxXHT0t5BlQ3Ih85KFqqts+LMamUk5 OGvEl+oVQ8OuqGyPe/CAssM2341GGv/ZlvOyuTLr5Wz4QNbEqTgJpfj1V57Ch3t4S/duFN7U+FQc c/YkpH6wGge6DcC4Y0dizLDu5mMyY2bGsWZQbcbGfd3c8XET+yErcP/lDaw5IcG8E3Vulh+/j4e3 ZuK/X/0V/mLDmE8tuBn3P3CpGbGL8eLyA6AXaB4K8OPvLsCuqJOtaPlCG5LbiZHfnGbelhB2rt+O pAnH4urbr8VRpsTmnfT11Q1JqelIeGYpPi5i6SV47+lVKPn0QHRP6Y9T5gJbbFmPzLEjXd0G9c20 NPHlpowchU8Z+/vMuM23O2zIHs7YW2IyDUACH/eMF4JwbDuUOxpffsjmNu1fiP+a97QZbF4mzll7 e/5yNzyXUPwJXn8ZOHZCH1SsW+M8medffjKOsjlb68xASjA5DR2vVSEquPZAzdawuXMxfO3LuPPe Hbjq+snOkzb4+KlI3Psa/r3GuZCw5aVXkJcwHLPGdsMxZ45B0r2vYJ2LKseb9y5A+bQTMLqph1JS emHSEODpe5cYrxDyXv8XHrb5Ws54apA9sOnJ+/DTh4twxf3XmSFZjYpy9tWG+2dNxRrY8Hp6bGRD 8lIxbEZP7L/vdawrqkT5xlX44102Z83Zbg3lsdOj21Ccc1wpXn54PU6dNxo9xk7AaBsKfcG8bBfM 7gO/7yy1uY7D7dwad+ww9OrW8CW9zH7SnHXLN/GDz5fhjxf9FK9vtX7WCLPY2mlfBESg/QgEbo/t p4RKjk/APSBQYUObGWZYmcMhwV4VRcPt81O+XycDDTZ6zIptLbbu6Tk456iv1onnDoc+C82jxidE w/bkJF/u7rxqZuTx224NCFdyTpwzDevlb/CAXez/c/5X0O07d5kXanFtsoQxNj/GfGRzP4sffPwg fnreD7w4myj/w39/B5MGTscffr3HnsL8hT2g4IWz//wTXD2WU6zrBnpn4od0RLLrduF1T7+M4jMu quM1Cw88Bl867gnc8dBaXHXsdFz17/9E5Mo/4OuzzXqJBj5I8LvLhtleOd7/yR2434aUGMqnzcW3 psR6KFyUIduCn8/9nntAIpx7Au68wwxQCzN+dCOu/tZt+PpMT371sLl46KnZ8eUmZOGapz+PXRc/ gq/anDIGcvicOT2C9a5Ty2CcbSeYZReyqfOX/fMGVM77Df7z2hz85cHZTlblqjfxpelPuu2e530G v/1UT6RVTccFQ17Fn86zOVw9h+Ok4zLw8ld/j5kvXxf3+Amvfsc9rOCENPAn3HcsLjgpgt9vPQ2n 2oR4hoShM/Hr7+fhv666BQ+5Iz1x9QNf9zx/F3wO31j5e/zoNO9HR/XQqbjt3pnOyEui5RXfGrKI dJz0k4vw4lXP4qszn0do6HCY7RYNSQ2wn4lVf1tvaRLwUI0uAB/kuKyh/hnwulJ4rE5UMdVpy9ja tmqov0++9POY939/wI/mrrbUPTGhVumGzxF7cGbCmROBZQdw0hQ7K1IG4FPHRbAq61SMd/r1sb7z Bdxx8X247C9ef+32xS/j3utH1tOXOvK8KitPwtRv/hduqPg1fnPxPTaf82sNMJsbVwblKIiACLQ9 gYSVK1ce5N257ZWMLXHgwIHIyIi9pdemysykJ6PpsHHjRowcObLphAeZImST9EtLS1FQUICd6cvQ p2/3g5TgJS/edwD/eOVZpPX03kzA10TxzQS9svrhC9N+VE/mU2t/i0vGfyfu8X02R43eN+dRs7FU 921GWsiMtoh7GCGMCvMSnTvnAnRraAiqnuS6B7jIrC0yYqOxqeie7XwdNQlC5eWoMMdMauyTmzas VVoeRmJ6OtLrWCQ1WVttg/rSV7T1tdftics3ndE16orL8KNvHIsUp2+iLQVStx61yoQsr9XVrIr9 RWFk9qj/RGpFCR8rqCvD41D3mCfT+kxJ1eHlYJ4ne52FWZw2B8zGxuu2iVdeprUHvX6l5s3z6trQ 8dqaH/RWtI3rtT1LbpJzA6WZzP32MEg87swRj30DktzhBvtnY5kaiYsvz9gWlSExOztuX4+fp5FC aqK8NovYZNMszuNrYThYZi0sRtm6CIE9u/ehf/lU5ObmgvdkvgLxcIfWuoc3pifv7e0R2vj22B5V 7LhlurcShNLsgYJKe3DA5vjYjd9ew469B3bhr0tvqWewxTPUHl/1K+yrzHcPE4TNSKPjjN98SMEN fXI4lN4286wlVKe6NyG0lFimTeJuyExOMmMsbpwZdpk2XNcegfoyTLjgPPzlnDn48LVVKBw6ypv/ 1pC+NYrSUGNIRU4Dnr80ZwjVZHAbDXIwwy/T1nw7rIGGGoPVpf7PhWB5zdn2RLXobyNt3DCPJkoy mQ1xZ8547BuT2GI9GhAaX55x7tFwZ4+fp4EC6hwOtl+diIPaOVhmByVciUVABA6JQMMTHA5JrDIf DgJ8B2hWijfFnMtz8KEAM7Pcd4EZbA+awdZYeGzlL1FYtguhKhsmi3rPQuZtqdm2YzTZ3DCoyWdZ LLNLhuRsjP30TJwwpuGbaZfkokqLgAiIgAi0O4Euemdud+7NUiDJDKd+vfqjvMCWceA/84BxuQ0a Vxy+LCjZaQbbzXFlPfz+rcg3g47LevAJTxppYRpqnKvmZHhrtrn12UxeWUGlK4tlKoiACIiACIiA CBw5BHRnPnLaop4mNJyGDBto65N58/OcsWYGW7UZVxy6pOG11wy2+5fcVCfvX5f+xA2Vhu3pUOdJ C9NgszlWbq5awGBzw6L01NnUayuDZclYq4NSOyIgAiIgAiLQ7gRkrLV7EzSsQKJNyORk//49BuHA bm/ZBBpsCfSM0fCybXrZ9pbuxH2Lf+gE3b/kR2bA7bAHCOyFu27oMzrs6TxqzMO8nnfOzVkzQ42y WQbLYpkKIiACIiACIiACRw4BPWBw5LRFPU0SE+19f+mpGDN+JHa/sQtVJaXI6J5ujxl4NrZ7WN/+ 8Lu4rBC/e/0/bceeGE2MNitfUcXABGbY8RXvDDxqa8a6+Wpl+8qRWp6NMTNGurJYpoIIiIAIiIAI iMCRQ0DG2pHTFnE1SU5JRm7v7hhli6eu/nC1rX1UhaysbCT7Blk0F58TpQHGJ0hpjNHkoq0Wtj/2 wgMzzKL7LtYWrrWh0fIDJSjflYiJY0e5MliWggiIgAiIgAiIwJFFQHfnI6s96mlDT1d6RhqOOnoo DhSXYcPGDxEeUoweubZMBp8UNePsoIJ52EqrilFcZJ+t1fay6LFONsuQV+2gSCqxCIiACIiACLQJ ARlrbYL50ApJTklCdk4mxk8Z5eabffzJRlv0Mx99h9hyG6k5yLRPc0Jp5X57j+h+7N66F5V7k3HU sNFOJmWzDAUREAEREAEREIEjj4CMtSOvTeppxKHN1DR7K0DPbph4nL3GKTMdH63bhE17d6Nbv73o PaCXM9rSU7KQlpxhQ6TeqvvVtphuRXWZvUz8gDPS8nfsRfGuELol9MDEcSNw1LihTiZlswwFERAB ERABERCBI4+AjLUjr03iauQ/bNAjtxvGThqBXn174ON1W7B9y0589MkupPfIR1q3BKRkJSExzTO8 wvZe0aoDIVQUR1Bur5LKSMjGiKH93bBn7349nbeOhpqGP+Mi10EREAEREAEROCIIyFg7IpqheUr4 BhvfscanRGm4cS5b3pbd2Lu7EPu2FaOouBQV5d5bsJkmu1umvZutG3qN64mBQ/u6PFl2jHPUOPQp j1rz2CuVCIiACIiACLQXARlr7UW+heXSuEpJTUaSvfeRxhgNr9w+3c1Aq0JVZRWq+aYCe2MBA18d lWzpUlJTLG2KGz5lHj71KW9aCxtA2URABERABESgjQnIWGtj4IerOBpbqWkpzvDKyEzzXinFl7Lb hwvnMtCwo8HGtxLwwwVvZaQdrhaQHBEQAREQARFoGwIy1tqGc6uVQuOLi+Amp7RaERIsAiIgAiIg AiLQjgT0uql2hK+iRUAEREAEREAERKApAjLWmiKkeBEQAREQAREQARFoRwIy1lobvr0Dyp9D1tpF Sb4IiIAIiIAItDcBd8/j+w8VDhsBGWuHDWUDgipS7SnN6gYidVgEREAEREAEOhcBd8+ze5/C4SMg Y+3wsawjiU9iuk9xNxw4UCHvWh062hEBERABEeiMBOhV4z0vwe59/n2wM9azreukp0FbiTg7KRev Ta7MQknefivlALKy0twaaYxTEAEREAEREIHOQoBGGj1qNNQO5Nn7rKuy3D1Q97vD08Iy1g4PxzpS 2DkTE7kgbTLS0tJQnJ+Nvfv2o7hXKVKzgSR5h+vw0o4IiIAIiEDHJhCyF+dUlthnr933QtlI621v ybF7IO+FMtgOvW1lrB06w3oS2DHpVUtNTUVGRoZ51LJQva8aJR+X2RsGqt2QqB46qIdNB0RABERA BDogAd7z+KFx5u553bPcN++BvBfKWDv0Ru2QxlpHMHTc+zvNq+YMNTPQGFJSUlBZWWlvGwhpDtuh 911JEAEREAEROAIIBB0UmZmZyMnJcfc+jizxXqhw6AQ6pLF26NVuXQnsuHT90jijsRb8xRE01jqC 0dm6pCRdBERABESgIxPg/S1orNGzlp2dDRptvAdqGPTwtK6MtcPDsZ4Uv/Pyl0XQcOMwaDhs7/C0 j4IIiIAIiIAIdHQCvMfxw2FQDn3yvkdDTUOgh69lZawdPpb1JPm/KPxOzF8cwSFQedbqIdMBERAB ERCBDkSAjgkG30HB+x2NNP/+14GqckSrKmOtlZuHHZidlh/fOPO/W7loiRcBERABERCBNiEQNNpY oL/fJoV3gUJkrLVBI/ud1v9ugyJVhAiIgAiIgAiIQCchoDcYdJKGVDVEQAREQAREQAQ6JwEZa52z XVUrERABERABERCBTkJAxlonaUhVQwREQAREQAREoHMSkLHWOdtVtRIBERABERABEegkBGSsdZKG VDVEQAREQAREQAQ6JwEZa52zXVUrERABERABERCBTkJAxlonaUhVQwREQAREQAREoHMSkLHWOdtV tRIBERABERABEegkBGSsdZKGVDVEQAREQAREQAQ6JwEZa52zXVUrERABERABERCBTkJAxlonaUhV QwREQAREQAREoHMSkLHWOdtVtRIBERABERABEegkBGSsdZKGVDVEQAREQAREQAQ6JwEZa52zXVUr ERABERABERCBTkJAxlonaUhVQwREQAREQAREoHMSkLHWOdtVtRIBERABERABEegkBGSsdZKGVDVE QAREQAREQAQ6JwEZa52zXVUrERABERABERCBTkJAxlonaUhVQwREQAREQAREoHMSkLHWOdtVtRIB ERABERABEegkBGSsdZKGVDVEQAREQAREQAQ6JwEZa52zXVUrERABERABERCBTkJAxlonaUhVQwRE QAREQAREoHMSkLHWOdtVtRIBERABERABEegkBGSsdZKGVDVEQAREQAREQAQ6JwEZa52zXVUrERAB ERABERCBTkJAxlonaUhVQwREQAREQAREoHMSkLHWOdtVtRIBERABERABEegkBLq0sZaQkIBIJNJJ mlLVEAEREAEREIGuQYD3bt7Du0ro0sZaWloaysrKukpbq54iIAIiIAIi0CkI8N7Ne3hXCV3aWOvZ sycKCwvlXesqvV31FAEREAER6PAE6FXjvZv38K4SurSxlpGRAX7y8vJQWloqo62r9HrVUwREQARE oMMRoJHGezXv2f79u8NVooUKJ7cwX7tmO5zzzHJzc13j79+/H3v27EEoFGrXuqlwERABERABERCB +gSSkpLc0Cc9apmZmfUTdOIjHdJYO9ztwUbvag1/uBlKngiIgAiIgAiIQOsQ6NLDoK2DVFJFQARE QAREQARE4PARkLF2+FhKkgiIgAiIgAiIgAgcdgIy1g47UgkUAREQARH4/+3dfWxV9R3H8c99bO8N t1gsGTE4E4GZGRTFrKMkGmZ0KAMzdNU0og5EMW7B/TEQ50CmGUQXEx8iLtbY+BBqivWh0QajiYrx gSyRpU4g4uZ0mV1XxAhyue3t7fWc21rp5SFt7++053fP+yRt73n4fc/vvH6nySe/09uLAAIImBMg rJmzpBICCCCAAAIIIGBcgLBmnJSCCCCAAAIIIICAOQHCmjlLKiGAAAIIIIAAAsYFCGvGSSmIAAII IIAAAgiYEyCsmbOkEgIIIIAAAgggYFyAsGaclIIIIIAAAggggIA5AcKaOUsqIYAAAggggAACxgUI a8ZJKYgAAggggAACCJgTIKyZs6QSAggggAACCCBgXICwZpyUgggggAACCCCAgDkBwpo5SyohgAAC CCCAAALGBQhrxkkpiAACCCCAAAIImBMgrJmzpBICCCCAAAIIIGBcgLBmnJSCCCCAAAIIIICAOQHC mjlLKiGAAAIIIIAAAsYFCGvGSSmIAAIIIIAAAgiYE4iaK+WfSul02j+doScIIIAAAggggEAJAsys lYBHUwQQQAABBBBAwGsBwprXwtRHAAEEEEAAAQRKECCslYBHUwQQQAABBBBAwGsBwprXwtRHAAEE EEAAAQRKECCslYBHUwQQQAABBBBAwGsBwprXwtRHAAEEEEAAAQRKECCslYBHUwQQQAABBBBAwGsB wprXwtRHAAEEEEAAAQRKECCslYBHUwQQQAABBBBAwGsBwprXwtRHAAEEEEAAAQRKECCslYBHUwQQ QAABBBBAwGsBwprXwtRHAAEEEEAAAQRKELA2rOVyuRIum6YIIIAAAggggIAdAlaGNTeo9fX12SFM LxFAAAEEEEAAgRIErAxrmUymENay2WwJl05TBBBAAAEEEEDA/wJR/3fx2B6m02nF4/HCjv7+fkWj UUUikWMPZAsCCCCAAAIIIGC5gJVhzX0MeujQISUSiUJo45Go5Xch3UcAAQQQQACBEwpYGdbcq+nt 7ZUb2mKxmMLhsEKh0Akvkh0IIIAAAggggICtAtaGNRfcDWvuFwsCCCCAAAIIIFCuAla+waBcB4Pr QgABBBBAAAEEigUIa8UirCOAAAIIIIAAAj4SIKz5aDDoCgIIIIAAAgggUCxAWCsWYR0BBBBAAAEE EPCRAGHNR4NBVxBAAAEEEEAAgWIBwlqxCOsIIIAAAggggICPBAhrPhoMuoIAAggggAACCBQLENaK RVhHAAEEEEAAAQR8JGD1P8WtrKxUMpkc+pxQH7nSFQQQQAABBBBAwIiAtWEtlUoVgpqrkM/njWBQ BAEEEEAAAQQQ8JuAlY9Bv5tR8xsm/UEAAQQQQAABBEwLWDmzlkgkAjWbtn//ftXU1Jgee+ohgAAC CCCAgAUCVoa1aDQaqLDm3kc86rXgt4kuIoAAAggg4IGAlWEtiMEliNfswf1OSQQQQAABBKwTIKxZ MmSENUsGim4igAACCCBgWMDKNxgYNqAcAggggAACCCDgWwFm1nw7NMM7xszacA/WEEAAAQQQCIoA Yc2SkSasWTJQdBMBBBBAAAHDAoQ1w6BelSOseSVLXQQQQAABBPwtwN+s+Xt86B0CCCCAAAIIBFyA mTVLbgBm1iwZKLqJAAIIIICAYQHCmmFQr8oR1rySpS4CCCCAAAL+FghQWEvrlfXXqWlPaHBEUrpk 5VrddNmPFSkao1CmQ8uX3a1bnnpOtcminRO0SlibIHhOiwACCCCAwAQLBCis5dX7pXRw4Rq1XDdT +9r+qnsfv0/n1z2h2qrho5CvmKH1d9+n6nje+Zin4fsmao2wNlHynBcBBBBAAIGJFQjcGwymT0pp csUU1V68wJE/pH/+P63P2+/XPc++rhc2/UpX3dSsg5kutW95QZ19B9Sydrme+seBoVH6eNsG3dG6 R/kv3tWfVtSrvt79WqFnd3UPHtOjj9obB7fX65fr2tTZ0awrVzfqv7mBQ0KZfbr3xrXa0T24Yag6 LxBAAAEEEEAAgeECgZpZcy89ffiIDh/+Qm80NSofnqcLZyTUs6tTHa3vK7Vqgx77zQxV5T/Tnq5/ qa6vWnPmJLWu8W3VP3CFKvs+VXPLbp276YfqjUa0eN0j2jBrqnZv/a3Wb3lLix+7Sj3vPKyNTTvV sP5BLfrRZB08kNGpVV2a3nmX2ndfrZWzq9S1o0V/S5+nVTXhEX9AOzNrw29c1hBAAAEEEAiKQKDC Wiwh9W3frF9vl2rm/kJ3PnSNTnOec37ae0TfLPi9Vl88uzDu+czA8LsB6ayFDYq++KB2fr1EF+x9 WR9GFmu1E/BimqmZRz7U9udeV3dnSPlEXlmn4d/fel+ZC27WktnTCn8LVzPNOamqdcOF/brnmZ26 cXOtXmncpbm/W+mEQucx6wjvNMLaCKE4DAEEEEAAgTITCFRY6zkihRffqa3LzhkaRjcEZZ3ElEpN +n6Wy9nmLu6+XPVc3XBGXs+/9qb+t3OHzl71QCFkfd62UWuaM7p+7S2q+8GXemlvryLO8SG3aT6q sPP66CA2Z8kKxW5v07b2f6s9fL42/aTm+/MVznbyb4S1k/uwFwEEEEAAgXIVCFRYcwcxFYseE5Lc UBVyw5XzVVgGf7rr+Xxc869epCf/8qhaQ2drY+00Z9thfdC2R+l5t+ny86Zrd+tnTrMpTuiLa/ZF P1Xlw0/r1U/O0c9nVOmr7oOqmlqtyOl1apjapOYnu3TK0rt0ZtitPXC6kXwf6ttIDuYYBBBAAAEE ECgbgUC9wSDuDFvSCWvFSzRWvMU57qhNVedepPnOPNkpi5bqrAp3R1J1yy9V8r2H1NCwTNv+M02T v35Rt7fs1ZT5t2rN5dPV9MdbC/tu3vyGBp6qVmnBtZc4bSfp2p/NOqo6LxFAAAEEEEAAgRMLhDo6 OkYxv3PiQuO5p6KikJjG85THPVeuJ60eJ7glne70p9PKViRVMfhP2wr7chEl3Z2Dy77W2/SHDxbp 6T8vVOV3G0fwM5vNKhY7TqIcQVsOQQABBBBAAAG7BY6dZrLgevzySDAcTyjhzLi5jzNDiYTig69d woF9A3/35q6HMp9oS2u3LtswTxXu41V34ygWv1zzKLrMoQgggAACCCBgQMDKmTU7Z5lySqdzzkyb +zB2dEsul1MkUvw5C6OrwdEIIIAAAgggYKeAlTNrdlK7j0QJXHaOHb1GAAEEEEBg4gSsDGtBfCQY xGueuF8LzowAAggggIB/BAhr/hmLk/aEsHZSHnYigAACCCBQtgJWhrX+/n6FQqGyHZTjXRhh7Xgq bEMAAQQQQKD8BawMawSX8r8xuUIEEEAAAQQQGBAI1D/FZdARQAABBBBAAAHbBKycWXORmV2z7Vaj vwgggAACCCAwFgFm1saiRhsEEEAAAQQQQGCcBAhr4wTNaRBAAAEEEEAAgbEIENbGokYbBBBAAAEE EEBgnAQIa+MEzWkQQAABBBBAAIGxCBDWxqJGGwQQQAABBBBAYJwEvgUmZ4yGYSK0egAAAABJRU5E rkJggg== --_002_E0AC9F635C234E798B5F63E3168AE162alcatellucentcom_-- From nobody Sat Jan 9 17:24:20 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0DB31A9041 for ; Thu, 7 Jan 2016 08:12:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 E8ouqbYnmniJ for ; Thu, 7 Jan 2016 08:12:42 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBE7E1A8BC4 for ; Thu, 7 Jan 2016 08:12:41 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 7F41232893B36; Thu, 7 Jan 2016 16:12:37 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u07GCduM006023 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Jan 2016 17:12:39 +0100 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.213]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Thu, 7 Jan 2016 17:12:39 +0100 From: "VAN DE VELDE, Gunter (Nokia - BE)" To: "Templin, Fred L" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org" Thread-Topic: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host Thread-Index: AQHRRrIF1AJWfg9CNUOFmoSBK+04DZ7vFi6A///F1ICAAPhpgIAAUuaAgAAXvYA= Date: Thu, 7 Jan 2016 16:12:38 +0000 Message-ID: <7B3ACA5B-FB06-45B6-BE6E-B2D1FB26C0B9@alcatel-lucent.com> References: <201601031900.u03J0LMe009763@irp-lnx1.cisco.com> <2134F8430051B64F815C691A62D9831832F9ADDE@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F9BC14@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832F9BC14@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="utf-8" Content-ID: <3C604F6ADEBF8B4FA6DBEEB4CD13C014@exchange.lucent.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Sat, 09 Jan 2016 17:24:15 -0800 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 16:12:43 -0000 SGkgRnJlZCwNCg0KVGhpcyBzZWVtcyBubyBkaWZmZXJlbnQgYXMgd2l0aCB2NCB0ZWNobm9sb2d5 IGF0IGNvbW11bml0eSBXaS1GaeKApiANCg0KRy8NCg0KDQoNCk9uIDA3LzAxLzE2IDE2OjQ3LCAi VGVtcGxpbiwgRnJlZCBMIiA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4gd3JvdGU6DQoNCj5I aSBHdW50ZXIsDQo+DQo+T0ssIHNvIHlvdSBhcmUgc2F5aW5nIHRoYXQgdGhlIE1BQyBhZGRyZXNz IG9mIHRoZSBVRSBpcyB1c2VkIGFzIHRoZSBVRSBpZGVudGlmaWVyLg0KPkJ1dCwgYm90aCBsaW5r LWxvY2FsIGFuZCBNQUMgYWRkcmVzc2VzIGNhbiBiZSByZWFkaWx5IHNwb29mZWQgYnkgYW4gYXR0 YWNrZXIsDQo+ZWl0aGVyIHRvIHN0ZWFsIHRoZSBzZXJ2aWNlIG9mIHRoZSBsZWdpdGltYXRlIG5v ZGUgb3IgdG8gZGVueSBzZXJ2aWNlIHRvIHRoZQ0KPmxlZ2l0aW1hdGUgbm9kZS4gSW4gb3JkZXIg dG8gYXZvaWQgdGhhdCwgdGhlIFVFIHdvdWxkIGhhdmUgdG8gaGF2ZSBzb21lIGZvcm0NCj5vZiBp ZGVudGlmaWVyIHRoYXQgY2Fubm90IGJlIHNwb29mZWQsIG9yIHNpZ24gaXRzIG1lc3NhZ2VzIHVz aW5nIGEgY2VydGlmaWNhdGUNCj5wcm92aXNpb25lZCBieSB0aGUgc2VydmljZSBwcm92aWRlciAt IGV2ZW4gdGhvdWdoIGNhcHRpdmUgcG9ydGFsIGlzIGJlaW5nDQo+dXNlZCB0byBhdXRoZW50aWNh dGUgdGhlIHVzZXIuDQo+DQo+VGhhbmtzIC0gRnJlZA0KPmZyZWQubC50ZW1wbGluQGJvZWluZy5j b20NCj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBWQU4gREUgVkVM REUsIEd1bnRlciAoR3VudGVyKSBbbWFpbHRvOmd1bnRlci52YW5fZGVfdmVsZGVAYWxjYXRlbC1s dWNlbnQuY29tXQ0KPj4gU2VudDogVGh1cnNkYXksIEphbnVhcnkgMDcsIDIwMTYgMTo1MSBBTQ0K Pj4gVG86IFRlbXBsaW4sIEZyZWQgTDsgZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVm aXgtcGVyLWhvc3RAdG9vbHMuaWV0Zi5vcmcNCj4+IENjOiB2Nm9wc0BpZXRmLm9yZyBXRw0KPj4g U3ViamVjdDogUmU6IFt2Nm9wc10gRm9jdXNlZCBkaXNjdXNzaW9uOiBkcmFmdC1pZXRmLXY2b3Bz LXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdA0KPj4gDQo+PiANCj4+IEhpIEZyZWQsDQo+PiAN Cj4+IA0KPj4gVGhlIFdMQU4tR1cgc2hvdWxkIG5vdCBjYXJlIGFib3V0IG92ZXJsYXAgaGVyZSwg dGhlcmUgaXMgYSBzcGxpdCBob3Jpem9uIGZ1bmN0aW9uIGFuZCB0aGUgd2xhbi1ndyBzaG91bGQg YmUgYWJsZSB0byBoYW5kbGUNCj4+IG92ZXJsYXBwaW5nIElQcy4gTGluay1sb2NhbCBhZGRyZXNz IG1heSBiZSBzdG9yZWQgdG8gZS5nLiB1c2Ugd2hlbiBzZW5kaW5nIFJBLCBidXQgaXQgc2hvdWxk IG5vdCBiZSB1c2VkIGFzIGEga2V5LCB0aGF0IGlzIHRoZSByb2xlIG9mDQo+PiB0aGUgTUFDIGFk ZHJlc3MuIFNvIGFzIGxvbmcgYXMgTUFDIGFkZHJlc3NlcyBkb24ndCBvdmVybGFwIHRoZXJlIHNo b3VsZCBub3QgYmUgYSBwcm9ibGVtIGRpc3Rpbmd1aXNoaW5nIFVFcy4NCj4+IA0KPj4gDQo+PiBU aGF0IGJlaW5nIHNhaWQsIGl0IHdvdWxkIGJlIHVubGlrZWx5IHRvIGhhcHBlbiBzaW5jZSBsaW5r LWxvY2FsIGFkZHJlc3NlcyBpbiBhIFdpRmkgY29udGV4dCBhcmUgbW9zdGx5IEVVSS02NCBiYXNl ZCBhbmQgdGh1cyBlbmNvZGUNCj4+IHRoZSBNQUMgYWRkcmVzcyB3aGljaCBhcyBzdGF0ZWQgc2hv dWxkIGJlIHVuaXF1ZS4NCj4+IA0KPj4gS2luZCBSZWdhcmRzLA0KPj4gRy8NCj4+IA0KPj4gDQo+ PiANCj4+IA0KPj4gDQo+PiANCj4+IE9uIDA2LzAxLzE2IDIxOjAxLCAiVGVtcGxpbiwgRnJlZCBM IiA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4gd3JvdGU6DQo+PiANCj4+ID5JIGhhdmUgd2hh dCBJIGhvcGUgd2lsbCBiZSBhIHNpbXBsZSBxdWVzdGlvbjogd2hhdCBpZiB0d28gb3IgbW9yZSBV RXMgY29uZmlndXJlDQo+PiA+aWRlbnRpY2FsIElQdjYgbGluay1sb2NhbCBhZGRyZXNzZXMgLSB3 aWxsIHRoZSBXTEFOLUdXIGJlIGFibGUgdG8gdGVsbCB0aGVtIGFwYXJ0Pw0KPj4gPkFza2VkIGFu b3RoZXIgd2F5LCB3aGF0IGtpbmQgb2YgdW5pcXVlIG5vZGUgaWRlbnRpZmllciBkb2VzIHRoZSBX TEFOLUdXDQo+PiA+ZXhwZWN0IGVhY2ggVUUgdG8gcHJvdmlkZSBpbiB0aGUgaW5pdGlhbCBSUz8N Cj4+ID4NCj4+ID5UaGFua3MgLSBGcmVkDQo+PiA+ZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbQ0K From nobody Sat Jan 9 17:24:21 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CFB91A90A0 for ; Thu, 7 Jan 2016 08:37:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 V_ARbSbDUH4m for ; Thu, 7 Jan 2016 08:37:07 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 294B71A909F for ; Thu, 7 Jan 2016 08:37:07 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 0C38CD33FD33F; Thu, 7 Jan 2016 16:37:02 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u07Gb3r2031850 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Jan 2016 17:37:04 +0100 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.213]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Thu, 7 Jan 2016 17:37:04 +0100 From: "VAN DE VELDE, Gunter (Nokia - BE)" To: "Templin, Fred L" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org" Thread-Topic: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host Thread-Index: AQHRRrIF1AJWfg9CNUOFmoSBK+04DZ7vFi6A///F1ICAAPhpgIAAUuaAgAAXvYD///A6gIAAFpqA Date: Thu, 7 Jan 2016 16:37:03 +0000 Message-ID: <2D68058C-981F-4037-80C4-AFF88D8A2997@alcatel-lucent.com> References: <201601031900.u03J0LMe009763@irp-lnx1.cisco.com> <2134F8430051B64F815C691A62D9831832F9ADDE@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F9BC14@XCH-BLV-504.nw.nos.boeing.com> <7B3ACA5B-FB06-45B6-BE6E-B2D1FB26C0B9@alcatel-lucent.com> <2134F8430051B64F815C691A62D9831832F9BD05@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832F9BD05@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="utf-8" Content-ID: <8E0E4D309BF8364A83722477611648E4@exchange.lucent.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Sat, 09 Jan 2016 17:24:15 -0800 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 16:37:09 -0000 DQoNCkkgYW0gc2F5aW5nIHRoYXQgdGhlcmUgaXMgbm8gZGlmZmVyZW5jZSBiZXR3ZWVuIHY0IGFu ZCB2NiBiZWhhdmlvdXIgb24gYSBXaUZpIChvciBldmVuIG1vc3Qgb3RoZXIgTDIgbmV0d29yayB0 eXBl4oCZcykgbmV0d29yayB3aGVuIE1BQyBhZGRyZXNzIGNsYXNoLiBJdCBpcyBub3QgYSBuZXcg cHJvYmxlbSBhbmQgc2FtZSB0ZWNobmlxdWVzIHVzZWQgaW4gdjQgY2FuIGJlIHVzZWQgaW4gdGhl IHY2IHJlYWxtLiBDbGVhcmx5IHdoZW4gdHdvIGRldmljZXMgaGF2ZSB0aGUgc2FtZSBNQUMgYWRk cmVzcyBvbiB0aGUgc2FtZSBMMiBuZXR3b3JrIHNvbWV0aGluZyBpcyBnb29mZWQgdXAuIA0KDQoN CkcvDQoNCg0KDQowNy8wMS8xNiAxNzoxNiwgIlRlbXBsaW4sIEZyZWQgTCIgPEZyZWQuTC5UZW1w bGluQGJvZWluZy5jb20+IHdyb3RlOg0KDQo+U28sIGFyZSB5b3Ugc2F5aW5nIHRoZXJlIGlzIGFu IGV4cGxvaXRhYmxlIHZ1bG5lcmFiaWxpdHkgaW4gdjQgY29tbXVuaXR5IFdpRmkgdGhhdA0KPmNh cnJpZXMgZm9yd2FyZCBpbnRvIHY2Pw0KPg0KPlRoYW5rcyAtIEZyZWQNCj5mcmVkLmwudGVtcGxp bkBib2VpbmcuY29tDQo+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTog VkFOIERFIFZFTERFLCBHdW50ZXIgKE5va2lhIC0gQkUpIFttYWlsdG86Z3VudGVyLnZhbl9kZV92 ZWxkZUBhbGNhdGVsLWx1Y2VudC5jb21dDQo+PiBTZW50OiBUaHVyc2RheSwgSmFudWFyeSAwNywg MjAxNiA4OjEzIEFNDQo+PiBUbzogVGVtcGxpbiwgRnJlZCBMOyBkcmFmdC1pZXRmLXY2b3BzLXVu aXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdEB0b29scy5pZXRmLm9yZw0KPj4gQ2M6IHY2b3BzQGll dGYub3JnIFdHDQo+PiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBGb2N1c2VkIGRpc2N1c3Npb246IGRy YWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0DQo+PiANCj4+IEhpIEZy ZWQsDQo+PiANCj4+IFRoaXMgc2VlbXMgbm8gZGlmZmVyZW50IGFzIHdpdGggdjQgdGVjaG5vbG9n eSBhdCBjb21tdW5pdHkgV2ktRmnigKYNCj4+IA0KPj4gRy8NCj4+IA0KPj4gDQo+PiANCj4+IE9u IDA3LzAxLzE2IDE2OjQ3LCAiVGVtcGxpbiwgRnJlZCBMIiA8RnJlZC5MLlRlbXBsaW5AYm9laW5n LmNvbT4gd3JvdGU6DQo+PiANCj4+ID5IaSBHdW50ZXIsDQo+PiA+DQo+PiA+T0ssIHNvIHlvdSBh cmUgc2F5aW5nIHRoYXQgdGhlIE1BQyBhZGRyZXNzIG9mIHRoZSBVRSBpcyB1c2VkIGFzIHRoZSBV RSBpZGVudGlmaWVyLg0KPj4gPkJ1dCwgYm90aCBsaW5rLWxvY2FsIGFuZCBNQUMgYWRkcmVzc2Vz IGNhbiBiZSByZWFkaWx5IHNwb29mZWQgYnkgYW4gYXR0YWNrZXIsDQo+PiA+ZWl0aGVyIHRvIHN0 ZWFsIHRoZSBzZXJ2aWNlIG9mIHRoZSBsZWdpdGltYXRlIG5vZGUgb3IgdG8gZGVueSBzZXJ2aWNl IHRvIHRoZQ0KPj4gPmxlZ2l0aW1hdGUgbm9kZS4gSW4gb3JkZXIgdG8gYXZvaWQgdGhhdCwgdGhl IFVFIHdvdWxkIGhhdmUgdG8gaGF2ZSBzb21lIGZvcm0NCj4+ID5vZiBpZGVudGlmaWVyIHRoYXQg Y2Fubm90IGJlIHNwb29mZWQsIG9yIHNpZ24gaXRzIG1lc3NhZ2VzIHVzaW5nIGEgY2VydGlmaWNh dGUNCj4+ID5wcm92aXNpb25lZCBieSB0aGUgc2VydmljZSBwcm92aWRlciAtIGV2ZW4gdGhvdWdo IGNhcHRpdmUgcG9ydGFsIGlzIGJlaW5nDQo+PiA+dXNlZCB0byBhdXRoZW50aWNhdGUgdGhlIHVz ZXIuDQo+PiA+DQo+PiA+VGhhbmtzIC0gRnJlZA0KPj4gPmZyZWQubC50ZW1wbGluQGJvZWluZy5j b20NCj4+ID4NCj4+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+PiBGcm9tOiBW QU4gREUgVkVMREUsIEd1bnRlciAoR3VudGVyKSBbbWFpbHRvOmd1bnRlci52YW5fZGVfdmVsZGVA YWxjYXRlbC1sdWNlbnQuY29tXQ0KPj4gPj4gU2VudDogVGh1cnNkYXksIEphbnVhcnkgMDcsIDIw MTYgMTo1MSBBTQ0KPj4gPj4gVG86IFRlbXBsaW4sIEZyZWQgTDsgZHJhZnQtaWV0Zi12Nm9wcy11 bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3RAdG9vbHMuaWV0Zi5vcmcNCj4+ID4+IENjOiB2Nm9w c0BpZXRmLm9yZyBXRw0KPj4gPj4gU3ViamVjdDogUmU6IFt2Nm9wc10gRm9jdXNlZCBkaXNjdXNz aW9uOiBkcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdA0KPj4gPj4N Cj4+ID4+DQo+PiA+PiBIaSBGcmVkLA0KPj4gPj4NCj4+ID4+DQo+PiA+PiBUaGUgV0xBTi1HVyBz aG91bGQgbm90IGNhcmUgYWJvdXQgb3ZlcmxhcCBoZXJlLCB0aGVyZSBpcyBhIHNwbGl0IGhvcml6 b24gZnVuY3Rpb24gYW5kIHRoZSB3bGFuLWd3IHNob3VsZCBiZSBhYmxlIHRvIGhhbmRsZQ0KPj4g Pj4gb3ZlcmxhcHBpbmcgSVBzLiBMaW5rLWxvY2FsIGFkZHJlc3MgbWF5IGJlIHN0b3JlZCB0byBl LmcuIHVzZSB3aGVuIHNlbmRpbmcgUkEsIGJ1dCBpdCBzaG91bGQgbm90IGJlIHVzZWQgYXMgYSBr ZXksIHRoYXQgaXMgdGhlIHJvbGUgb2YNCj4+ID4+IHRoZSBNQUMgYWRkcmVzcy4gU28gYXMgbG9u ZyBhcyBNQUMgYWRkcmVzc2VzIGRvbid0IG92ZXJsYXAgdGhlcmUgc2hvdWxkIG5vdCBiZSBhIHBy b2JsZW0gZGlzdGluZ3Vpc2hpbmcgVUVzLg0KPj4gPj4NCj4+ID4+DQo+PiA+PiBUaGF0IGJlaW5n IHNhaWQsIGl0IHdvdWxkIGJlIHVubGlrZWx5IHRvIGhhcHBlbiBzaW5jZSBsaW5rLWxvY2FsIGFk ZHJlc3NlcyBpbiBhIFdpRmkgY29udGV4dCBhcmUgbW9zdGx5IEVVSS02NCBiYXNlZCBhbmQgdGh1 cyBlbmNvZGUNCj4+ID4+IHRoZSBNQUMgYWRkcmVzcyB3aGljaCBhcyBzdGF0ZWQgc2hvdWxkIGJl IHVuaXF1ZS4NCj4+ID4+DQo+PiA+PiBLaW5kIFJlZ2FyZHMsDQo+PiA+PiBHLw0KPj4gPj4NCj4+ ID4+DQo+PiA+Pg0KPj4gPj4NCj4+ID4+DQo+PiA+Pg0KPj4gPj4gT24gMDYvMDEvMTYgMjE6MDEs ICJUZW1wbGluLCBGcmVkIEwiIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPiB3cm90ZToNCj4+ ID4+DQo+PiA+PiA+SSBoYXZlIHdoYXQgSSBob3BlIHdpbGwgYmUgYSBzaW1wbGUgcXVlc3Rpb246 IHdoYXQgaWYgdHdvIG9yIG1vcmUgVUVzIGNvbmZpZ3VyZQ0KPj4gPj4gPmlkZW50aWNhbCBJUHY2 IGxpbmstbG9jYWwgYWRkcmVzc2VzIC0gd2lsbCB0aGUgV0xBTi1HVyBiZSBhYmxlIHRvIHRlbGwg dGhlbSBhcGFydD8NCj4+ID4+ID5Bc2tlZCBhbm90aGVyIHdheSwgd2hhdCBraW5kIG9mIHVuaXF1 ZSBub2RlIGlkZW50aWZpZXIgZG9lcyB0aGUgV0xBTi1HVw0KPj4gPj4gPmV4cGVjdCBlYWNoIFVF IHRvIHByb3ZpZGUgaW4gdGhlIGluaXRpYWwgUlM/DQo+PiA+PiA+DQo+PiA+PiA+VGhhbmtzIC0g RnJlZA0KPj4gPj4gPmZyZWQubC50ZW1wbGluQGJvZWluZy5jb20NCg== From nobody Sat Jan 9 17:24:22 2016 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 13C231A90CC; Thu, 7 Jan 2016 08:59:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160107165938.14456.19735.idtracker@ietfa.amsl.com> Date: Thu, 07 Jan 2016 08:59:38 -0800 Archived-At: X-Mailman-Approved-At: Sat, 09 Jan 2016 17:24:15 -0800 Cc: v6ops@ietf.org, v6ops-chairs@ietf.org, fred.baker@cisco.com Subject: [v6ops] v6ops - New Meeting Session Request for IETF 95 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 16:59:38 -0000 A new meeting session request has just been submitted by Fred Baker, a Chair of the v6ops working group. --------------------------------------------------------- Working Group Name: IPv6 Operations Area Name: Operations and Management Area Session Requester: Fred Baker Number of Sessions: 2 Length of Session(s): 2 Hours, 2 Hours Number of Attendees: 150 Conflicts to Avoid: First Priority: opsec softwire homenet pcp sunset4 6man aqm dnsop isis opsawg ospf tsvwg Second Priority: tsvarea intarea mif lmap Third Priority: rtgwg Special Requests: --------------------------------------------------------- From nobody Sat Jan 9 17:24:27 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F77C1A90F4 for ; Thu, 7 Jan 2016 09:14:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 PK9phWbGRQc9 for ; Thu, 7 Jan 2016 09:13:58 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD92E1A90CE for ; Thu, 7 Jan 2016 09:13:58 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id E14499806A942; Thu, 7 Jan 2016 17:13:53 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u07HDt9i018802 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Jan 2016 18:13:55 +0100 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.213]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Thu, 7 Jan 2016 18:13:55 +0100 From: "VAN DE VELDE, Gunter (Nokia - BE)" To: "Templin, Fred L" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org" Thread-Topic: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host Thread-Index: AQHRRrIF1AJWfg9CNUOFmoSBK+04DZ7vFi6A///F1ICAAPhpgIAAUuaAgAAXvYD///A6gIAAFpqA///0toAAArLGAA== Date: Thu, 7 Jan 2016 17:13:54 +0000 Message-ID: <33FC69DB-7389-4AA3-B1D0-DC1016C134DD@alcatel-lucent.com> References: <201601031900.u03J0LMe009763@irp-lnx1.cisco.com> <2134F8430051B64F815C691A62D9831832F9ADDE@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F9BC14@XCH-BLV-504.nw.nos.boeing.com> <7B3ACA5B-FB06-45B6-BE6E-B2D1FB26C0B9@alcatel-lucent.com> <2134F8430051B64F815C691A62D9831832F9BD05@XCH-BLV-504.nw.nos.boeing.com> <2D68058C-981F-4037-80C4-AFF88D8A2997@alcatel-lucent.com> <2134F8430051B64F815C691A62D9831832F9BF23@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832F9BF23@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Sat, 09 Jan 2016 17:24:15 -0800 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 17:14:01 -0000 DQoNCg0KDQoNCk9uIDA3LzAxLzE2IDE3OjU2LCAiVGVtcGxpbiwgRnJlZCBMIiA8RnJlZC5MLlRl bXBsaW5AYm9laW5nLmNvbT4gd3JvdGU6DQoNCj5IaSBHdW50ZXIsDQo+DQo+TWF5YmUgSSBhbSBu b3QgdW5kZXJzdGFuZGluZyB5b3UgY29ycmVjdGx5LiBUaGVyZSBtYXkgYmUgbWFueSBBUHMgKDEw MCdzLCAxMDAwJ3MsIGV0Yy4pDQo+YXNzb2NpYXRlZCB3aXRoIGEgc2luZ2xlIFdMQU4tR1cgLSBj b3JyZWN0PyANCg0KR1Y+IFllcCwgdGhlcmUgY2FuIGJlIGluZGVlZC4gSSBzdGFydCB0byBzZWUg d2hlcmUgdGhlIGNvbmZ1c2lvbiBjYW1lIGZyb20uDQoNCj5BdCBlYWNoIEFQLCBhIFVFIHByZXNl bnRzIGl0c2VsZiB1c2luZyBpdHMNCj5NQUMgYWRkcmVzcyBhbmQgaW5pdGlhbGx5IHNlbmRzIG91 dCBhbiBSUyB1c2luZyBhbiBJUHY2IGxpbmstbG9jYWwgYWRkcmVzcyBtb3N0IGxpa2VseQ0KPmRl cml2ZWQgZnJvbSB0aGUgTUFDIGFkZHJlc3MuIFRoZSBBUCAoYWN0aW5nIGluIGJyaWRnZSBtb2Rl KSB0aGVuIGZvcndhcmRzIHRoZQ0KPlJTIHRvIHRoZSBXTEFOLUdXIHdoaWNoIG5lZWRzIHRvIGhh dmUgc29tZSB3YXkgb2Yga25vd2luZyB0aGF0IHRoZSBSUyBjYW1lDQo+ZnJvbSBhbiBhdXRoZW50 aWMgc291cmNlLiAoWW91IGhhdmUgc2FpZCB0aGF0IHRoZSBNQUMgYWRkcmVzcyBpcyB0aGUgaWRl bnRpZmllciBmb3INCj50aGUgVUUgLSBidXQsIGRvZXMgdGhlIFdMQU4tR1cgc2VlIHRoZSBNQUMg YWRkcmVzcywgb3IgZG9lcyBpdCBvbmx5IHNlZSB0aGUNCj5saW5rLWxvY2FsIGFkZHJlc3M/KQ0K DQpHVj4gQVAgaXMgYnJpZGdpbmcgZnJvbSB3aWZpIHRvIEdSRSB0dW5uZWwsIHNvIHRoZSBXTEFO LUdXIHNlZXMgTUFDIGFkZHJlc3MgaW5kZWVkDQoNCj4NCj5Ob3csIGNvbnNpZGVyIGEgVUUgJ0En IGFzc29jaWF0ZWQgd2l0aCBBUCAnWCcgYW5kIGEgVUUgJ0InIGFzc29jaWF0ZWQgd2l0aCBBUCAn WScuDQo+QSBpcyB0aGUgYXV0aGVudGljIG93bmVyIG9mIE1BQyBhZGRyZXNzICdNJy4gV2hlbiBB IGFzc29jaWF0ZXMgd2l0aCBYLCB0aGUNCj5XTEFOLUdXIGdvZXMgdGhyb3VnaCB0aGUgYXV0aGVu dGljYXRpb24gcHJvY2VkdXJlcyBiYXNlZCBvbiB0aGUgTUFDDQo+YWRkcmVzcyBNIChvciB0aGUg SVB2NiBsaW5rLWxvY2FsIGFkZHJlc3MgYXNzb2NpYXRlZCB3aXRoIE1BQyBhZGRyZXNzIE0pLg0K PkJ1dCBub3csIEIgYXNzb2NpYXRlcyB3aXRoIFkgYW5kIGFsc28gdXNlcyBNQUMgYWRkcmVzcyBN LiAoT3IsIG1heWJlIEINCj5hc3NvY2lhdGVzIHdpdGggWSBiZWZvcmUgQSBhc3NvY2lhdGVzIHdp dGggWC4pIFdoYXQgaXMgdG8gc3RvcCBCIGZyb20gc3Bvb2ZpbmcNCj50aGUgTUFDIGFkZHJlc3Mg aW4gdGhpcyB3YXkgYW5kIERvUydpbmcgQT8NCg0KR1Y+IGJvdGggQVDigJlzIHVzZSB0aGVpciBv d24gZGlmZmVyZW50IFNvZnRHUkUgdHVubmVsIHRvIHRoZSBXTEFOLUdXLCBhbmQgdGhhdCBpcyBo b3cgV0xBTi1HVyBmaW5kcyBvdXQgdGhleSBhcmUgZGlmZmVyZW50IGJlY2F1c2UgdGhlIHR1bm5l bCBjYW4gYmUgcGFydCBvZiB0aGUga2V5LiBPZmNvdXJzIFVFIG1vYmlsaXR5IGFuZCBvdGhlciBh ZHZhbmNlZCBmZWF0dXJlcyBjYW4gYmUgZW5hYmxlZCBvbiB0aGUgV0xBTi1HVyB1c2luZyBhbHRl cm5hdGUgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtcywgYnV0IHRoYXQgaXMgYmV5b25kIHRoZSBz Y29wZSBvZiB0aGlzIHBhcnRpY3VsYXIgZHJhZnQgYXMgdGhhdCBkcml2ZXMgcHJldHR5IGZhciBp bnRvIHZlbmRvciBjYXBhYmlsaXR5IHRlcnJpdG9yeSBhbmQgaSBiZWxpZXZlIHRoYXQgaXMgYmV5 b25kIHY2b3BzIHNjb3BlLg0KDQpCZSB3ZWxsLA0KRy8NCg0KPg0K From nobody Sun Jan 10 04:45:19 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 015EB1ACCF2 for ; Sun, 10 Jan 2016 04:45:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.972] 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 F31J-yhUsz49 for ; Sun, 10 Jan 2016 04:45:15 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4041E1A7113 for ; Sun, 10 Jan 2016 04:45:15 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u0ACjC5m020119; Sun, 10 Jan 2016 13:45:12 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 16739201431; Sun, 10 Jan 2016 13:52:45 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 0AC4820080A; Sun, 10 Jan 2016 13:52:45 +0100 (CET) Received: from [132.166.84.25] ([132.166.84.25]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u0ACjBBY014464; Sun, 10 Jan 2016 13:45:11 +0100 To: Jeff McAdams References: <568E6552.9030008@gmail.com> <568EACE4.2070408@isi.edu> <568F8F37.3050708@gmail.com> <20160108.121015.74737501.sthaug@nethelp.no> <67D93E4D-714A-4566-A308-D9EFBB71C43B@puck.nether.net> <568FC62B.2040109@gmail.com> <18838.74.139.119.34.1452263734.iglou@webmail.iglou.com> <568FD4BF.5080608@gmail.com> <4129.74.139.119.34.1452267772.iglou@webmail.iglou.com> <568FDE34.1060003@gmail.com> <4281.74.139.119.34.1452272495.iglou@webmail.iglou.com> <568FF952.2090508@gmail.com> <7459.74.139.119.34.1452276931.iglou@webmail.iglou.com> From: Alexandre Petrescu Message-ID: <56925257.4070507@gmail.com> Date: Sun, 10 Jan 2016 13:45:11 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <7459.74.139.119.34.1452276931.iglou@webmail.iglou.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Routers are hosts too! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jan 2016 12:45:17 -0000 Le 08/01/2016 19:15, Jeff McAdams a écrit : > > On Fri, January 8, 2016 13:00, Alexandre Petrescu wrote: >> In that sense, I dont know what makes a Host be a Host and not a Router. > > >> What particular characteristic of Host is not a characteristic of a >> Router too? > > So, I'm still not sure what you're trying to accomplish out of this > discussion, but ok.... The Host-Router distinction is omnipresent in RFCs. Whenever writing text one has to be careful about it. There are many RFCs exclusively dedicated to Routers, others exclusively dedicated to Hosts. > I think you have it backwards. At least in my mind and the working > definitions I've always used, a router is a device that forwards packets > between network interface using Layer 3 addressing information. A device > that *doesn't* forward traffic would thus *just* be a host. This is a definition I can agree with. There is more to it, however, especially when it comes to the presence of the rt table and algorithms. > I've never worked up a good working definition in my mind to decide > whether routers are hosts or not...mostly because, in 20+ years of my > career, it has never been something I've had to even think about. Thus my > questioning of what this whole discussion is really all about. We're - in > my mind - well into the territory of angels dancing on the head of a pin, > much ado about nothing, and a huge heaping dose of bikeshedding. > > If you find an example of a system that *doesn't* do longest match, then > let's talk about it. (Yes, I saw the example of uIP, I would argue it > does do longest match as it chooses between localnet destinations and > 0.0.0.0/0...it just has an *extremely* constrained routing table capacity > - 2 entries, and a very unusual internal representation of that routing > table) It's maybe about finding such a system, or about writing one. In an IP stack the operations needing most computing power are at longest-match and at the CRC computation. Their elimination can lead to very performant stacks - for Hosts. I mean stacks that must run in constrained CPUs and still react very fast. It is maybe researchy angels on top of trees... or maybe go the right WGs needing it. Alex > From nobody Sun Jan 10 04:48:25 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B13D1ACCFB for ; Sun, 10 Jan 2016 04:48:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.972] 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 TdBc90domTXc for ; Sun, 10 Jan 2016 04:48:23 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 083381ACCFA for ; Sun, 10 Jan 2016 04:48:22 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u0ACmLgR020549; Sun, 10 Jan 2016 13:48:21 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 1274820147B; Sun, 10 Jan 2016 13:55:54 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id F1399201434; Sun, 10 Jan 2016 13:55:53 +0100 (CET) Received: from [132.166.84.25] ([132.166.84.25]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u0ACmKi0016085; Sun, 10 Jan 2016 13:48:20 +0100 To: Gert Doering References: <568F8F37.3050708@gmail.com> <20160108.121015.74737501.sthaug@nethelp.no> <67D93E4D-714A-4566-A308-D9EFBB71C43B@puck.nether.net> <568FC62B.2040109@gmail.com> <18838.74.139.119.34.1452263734.iglou@webmail.iglou.com> <568FD4BF.5080608@gmail.com> <4129.74.139.119.34.1452267772.iglou@webmail.iglou.com> <568FDE34.1060003@gmail.com> <4281.74.139.119.34.1452272495.iglou@webmail.iglou.com> <568FF952.2090508@gmail.com> <20160108182143.GQ58491@Space.Net> From: Alexandre Petrescu Message-ID: <56925314.9000000@gmail.com> Date: Sun, 10 Jan 2016 13:48:20 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160108182143.GQ58491@Space.Net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Routers are hosts too! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jan 2016 12:48:24 -0000 Le 08/01/2016 19:21, Gert Doering a écrit : > Hi, > > On Fri, Jan 08, 2016 at 07:00:50PM +0100, Alexandre Petrescu wrote: >> In that sense, I dont know what makes a Host be a Host and not a Router. >> >> What particular characteristic of Host is not a characteristic of a >> Router too? > > "not forwarding IP packets not destined to one of its own addresses" > > iow, > > ip.forwarding=0 -> host > ip.forwarding=1 -> router > > done Yes, I agree. But when ip.forwarding=0 the Host still does forwarding between self issuing a packet and a next-hop that is looked-up. Most Hosts on the market do this forwarding, even if they dont need to. Alex > > Gert Doering > -- NetMaster > From nobody Sun Jan 10 04:53:03 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3D3C1ACCFC for ; Sun, 10 Jan 2016 04:53:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.876 X-Spam-Level: X-Spam-Status: No, score=-1.876 tagged_above=-999 required=5 tests=[DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, J_CHICKENPOX_15=0.6, NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.972] 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 u3wmoDK4rfVy for ; Sun, 10 Jan 2016 04:52:59 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03E8A1ACCF5 for ; Sun, 10 Jan 2016 04:52:58 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u0ACqsc6030894; Sun, 10 Jan 2016 13:52:54 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 549D520144B; Sun, 10 Jan 2016 14:00:27 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 4653E200DFC; Sun, 10 Jan 2016 14:00:27 +0100 (CET) Received: from [132.166.84.25] ([132.166.84.25]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u0ACqsad018611; Sun, 10 Jan 2016 13:52:54 +0100 To: "t.petch" , v6ops@ietf.org, Joe Touch References: <568E6552.9030008@gmail.com> <568EACE4.2070408@isi.edu> <568F8F37.3050708@gmail.com> <20160108.121015.74737501.sthaug@nethelp.no> <67D93E4D-714A-4566-A308-D9EFBB71C43B@puck.nether.net> <568FC62B.2040109@gmail.com> <18838.74.139.119.34.1452263734.iglou@webmail.iglou.com> <568FD4BF.5080608@gmail.com> <4129.74.139.119.34.1452267772.iglou@webmail.iglou.com> <568FDE34.1060003@gmail.com> <5690A82F.5020007@isi.edu> <03a301d14ade$57cb6e40$4001a8c0@gateway.2wire.net> From: Alexandre Petrescu Message-ID: <56925425.4070502@gmail.com> Date: Sun, 10 Jan 2016 13:52:53 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <03a301d14ade$57cb6e40$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Routers are hosts too! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jan 2016 12:53:00 -0000 Le 09/01/2016 14:04, t.petch a écrit : > ----- Original Message ----- > From: "Joe Touch" > To: "Alexandre Petrescu" ; > > Sent: Saturday, January 09, 2016 6:26 AM > >> On 1/8/2016 8:05 AM, Alexandre Petrescu wrote: >>> RFC1122 "Reqs for Internet Hosts -- Communication Layers" does not >>> mention longest-prefix match. >> >> Section 3.3.2.3 (source address selection) refers to Section 3.3.1, >> which includes a set of mechanisms in Section 3.3.1.2 for selecting >> among multiple gateways. >> >> Note that this algorithm involves using a route cache with ICMP >> redirects that help the system learn the "best" (quote from the RFC) >> next-hop. Those entries are described in terms of host routes, but > there >> is a discussion about aggregating those entries in 3.3.1.3. >> >> The net result of that aggregation is effectively longest-prefix > matching. >> >> So you're strictly correct - RFC1122 does not require longest prefix, >> but a large number of entries in the route cache is more effectively >> handled as such. > > But then RFC1122 does not mention classless addressing or Variable > Length Subnet Masks - as I recall, they did not exist at that time. > Rather, RFC1122 deals with 32 bit Host addresses and Classful Networks, > ie 8 or 16 or 24 bit addresses, so while you might have more than one > entry in the cache for a given destination, they will all be the same > length so the concept of longest-prefix (and of course, the term prefix > has no meaning at that date) match does not come into consideration. DO you mean that the longest-prefix match operation was not there since the earliest days of Internet? Alex > > Tom Petch > >> Joe >> > > From nobody Sun Jan 10 06:07:10 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9095D1ACD6F for ; Sun, 10 Jan 2016 06:07:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 vm-uM_UFyuTo for ; Sun, 10 Jan 2016 06:07:07 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id EF5B31ACD6E for ; Sun, 10 Jan 2016 06:07:06 -0800 (PST) Received: (qmail 45208 invoked from network); 10 Jan 2016 14:07:04 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 10 Jan 2016 14:07:04 -0000 Date: Sun, 10 Jan 2016 15:07:04 +0100 (CET) Message-Id: <20160110.150704.74724334.sthaug@nethelp.no> To: alexandre.petrescu@gmail.com From: sthaug@nethelp.no In-Reply-To: <56925425.4070502@gmail.com> References: <5690A82F.5020007@isi.edu> <03a301d14ade$57cb6e40$4001a8c0@gateway.2wire.net> <56925425.4070502@gmail.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Routers are hosts too! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jan 2016 14:07:09 -0000 > > But then RFC1122 does not mention classless addressing or Variable > > Length Subnet Masks - as I recall, they did not exist at that time. > > Rather, RFC1122 deals with 32 bit Host addresses and Classful Networks, > > ie 8 or 16 or 24 bit addresses, so while you might have more than one > > entry in the cache for a given destination, they will all be the same > > length so the concept of longest-prefix (and of course, the term prefix > > has no meaning at that date) match does not come into consideration. > > DO you mean that the longest-prefix match operation was not there since > the earliest days of Internet? Reading up on the history of the Internet is recommended. See for instance https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing Steinar Haug, AS2116 From nobody Sun Jan 10 10:39:34 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2197F1A894E for ; Sun, 10 Jan 2016 10:39:33 -0800 (PST) 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 JXr_P4ddydhO for ; Sun, 10 Jan 2016 10:39:31 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAC741A8951 for ; Sun, 10 Jan 2016 10:39:31 -0800 (PST) Received: from [192.168.1.28] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u0AId853017553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 10 Jan 2016 10:39:10 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPhone Mail (13C75) In-Reply-To: <20160110.150704.74724334.sthaug@nethelp.no> Date: Sun, 10 Jan 2016 10:39:08 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5690A82F.5020007@isi.edu> <03a301d14ade$57cb6e40$4001a8c0@gateway.2wire.net> <56925425.4070502@gmail.com> <20160110.150704.74724334.sthaug@nethelp.no> To: sthaug@nethelp.no X-MailScanner-ID: u0AId853017553 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Routers are hosts too! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jan 2016 18:39:33 -0000 On Jan 10, 2016, at 6:07 AM, sthaug@nethelp.no wrote: >>> But then RFC1122 does not mention classless addressing or Variable >>> Length Subnet Masks - as I recall, they did not exist at that time. >>> Rather, RFC1122 deals with 32 bit Host addresses and Classful Networks, >>> ie 8 or 16 or 24 bit addresses, so while you might have more than one >>> entry in the cache for a given destination, they will all be the same >>> length so the concept of longest-prefix (and of course, the term prefix >>> has no meaning at that date) match does not come into consideration. >>=20 >> DO you mean that the longest-prefix match operation was not there since=20= >> the earliest days of Internet? >=20 > Reading up on the history of the Internet is recommended. See for > instance >=20 > https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing Yes, but classless routing has nothing to do with longest prefix.=20 Longest prefix is relevant only if the route cache has overlapping rules. Th= at won't happen with host redirects. It only could happen with subnet redire= cts or manual entries (on a host / on a router, routing protocol entries wou= ld also be included.).=20 Joe From nobody Sun Jan 10 10:43:01 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0D721ACE85 for ; Sun, 10 Jan 2016 10:42:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 wvAyCy6dqaWi for ; Sun, 10 Jan 2016 10:42:57 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E23C1ACE8A for ; Sun, 10 Jan 2016 10:42:57 -0800 (PST) Received: from [192.168.1.28] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u0AIgVta010309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 10 Jan 2016 10:42:41 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPhone Mail (13C75) In-Reply-To: <56925314.9000000@gmail.com> Date: Sun, 10 Jan 2016 10:42:31 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <699C3268-C1EB-41C7-911F-07ABC14A547B@isi.edu> References: <568F8F37.3050708@gmail.com> <20160108.121015.74737501.sthaug@nethelp.no> <67D93E4D-714A-4566-A308-D9EFBB71C43B@puck.nether.net> <568FC62B.2040109@gmail.com> <18838.74.139.119.34.1452263734.iglou@webmail.iglou.com> <568FD4BF.5080608@gmail.com> <4129.74.139.119.34.1452267772.iglou@webmail.iglou.com> <568FDE34.1060003@gmail.com> <4281.74.139.119.34.1452272495.iglou@webmail.iglou.com> <568FF952.2090508@gmail.com> <20160108182143.GQ58491@Space.Net> <56925314.9000000@gmail.com> To: Alexandre Petrescu X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Routers are hosts too! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jan 2016 18:42:59 -0000 On Jan 10, 2016, at 4:48 AM, Alexandre Petrescu wrote: >> iow, >>=20 >> ip.forwarding=3D0 -> host >> ip.forwarding=3D1 -> router >>=20 >> done >=20 > Yes, I agree. But when ip.forwarding=3D0 the Host still does forwarding b= etween self issuing a packet and a next-hop that is looked-up. Most Hosts o= n the market do this forwarding, even if they dont need to. The do this and it is required.=20 It is a next hop lookup but it's not called forwarding because the packet wa= s generated internally - it literally Isn't being "forwarded" on behalf of a= nother device.=20 Joe=20= From nobody Tue Jan 12 02:47:01 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 071711A876E for ; Tue, 12 Jan 2016 02:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_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 OhViMmPusoM4 for ; Tue, 12 Jan 2016 02:46:57 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0759.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::759]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB83D1A876B for ; Tue, 12 Jan 2016 02:46:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7ESOQaE5yRFWb0AAQYE5zGhi9haI7PtQur3JwAO6Mro=; b=j52CY6+SlAdrdXWsjkQQo7MYCzN9tZVCCa5I0iZwKf2Hce5JummGMJTyXZHc8I33khnsAViNhQDOLOK6l38HL/Tm8gCiux/pebt4I3LTzkblEvRU59i3KeHU9WcgLZ25o2dGi/YAQYci3DyW7HnEFNGoUqtrenSl+8Dej7vz0oc= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (86.185.87.133) by DBXPR07MB061.eurprd07.prod.outlook.com (10.242.147.14) with Microsoft SMTP Server (TLS) id 15.1.361.13; Tue, 12 Jan 2016 10:46:33 +0000 Message-ID: <019a01d14d26$243f9de0$4001a8c0@gateway.2wire.net> From: t.petch To: , References: <5690A82F.5020007@isi.edu><03a301d14ade$57cb6e40$4001a8c0@gateway.2wire.net><56925425.4070502@gmail.com> <20160110.150704.74724334.sthaug@nethelp.no> Date: Tue, 12 Jan 2016 10:43:48 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.185.87.133] X-ClientProxiedBy: DB4PR05CA0020.eurprd05.prod.outlook.com (25.160.40.30) To DBXPR07MB061.eurprd07.prod.outlook.com (10.242.147.14) X-Microsoft-Exchange-Diagnostics: 1; DBXPR07MB061; 2:hzBLm9rGw360XGl0A/0T8zpOmsqNv2ts+uZq2Oj4jBvJbNs9wpFv3yJ9hZKPPCksEMBoFYVkOruRo2X8d22HywoJ2rt2ndJMYtWmIWs2T40EIsQlBCr2Poxi38JM4J5dKSU1KefRHeCj2rmpHnypKg==; 3:FxqCqHPoHSI2xXkAeZECPctcvR0ZzvZ5mTy3xiWTtVxM2faspXgEIzrMAX4PrUQYSqJ2HiouIEESqYxOi8y3Rb92lwEcZAVFzg6f0QWumlLKG1C5kJe/aZTpx46uULfh; 25:UCHa66gnLvJPwogngghpq7hGzlx9w+C//rqckG/P8VBqmnHVVX6qK+ulIIKkkivFD9WqJ7NgZjG8zW4mN4PWTpJSEfOxftAdVmIxOzQipLEtiK8JrEQh3cudGu+cjhsrzhNtbnscCptYQhrtzoJnf6804Y05itjtOROHERiOQcOCGxOsM5/qCWbjU26c5COctNDQuGYK8hFn+iXjNpynnMtSbh6+v4KH9khTglF6AASh+jxiqCGARjxAnwf21X3z X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB061; X-MS-Office365-Filtering-Correlation-Id: b0b9a7a7-2dc4-43c4-2528-08d31b3da336 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(178726229863574); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:DBXPR07MB061; BCL:0; PCL:0; RULEID:; SRVR:DBXPR07MB061; X-Microsoft-Exchange-Diagnostics: 1; DBXPR07MB061; 4:C0kTcjzRZLzo/HjZxcG09I13TIOyp029EznFZUVIJA1Ofge9UOFvdt890d7aa+hxiF1n1sHgcXa5KIVpHABbVICsp3pi/DOTRTqbxpQcLlwu9h3yJtPZzqpC20Iyvoz3HvT2Yygk0Jv/CRzLnbq+WWu8LpzfwiroHBvXMtUbCUJLPLSK+8Rmfz9WLElHInJT2Ck2qKROW/yjpBXyI3kMolinB5no+I/y9kcAgSrSER6+GB07Q2DR1plsmdx8qehcfpCWIdwM2n+w8kovkaI5cgj7duiZNd0C0mGbgrURCLso+NTzhYoOdk2ECfJnPRdytS2nlU504if5kVXcOSpiF2oMdj84xIByyakDqe2fZZYTifgh2Q2OkMriXztfS9Qq0+yTjbjS/Jn8+hPsA/DQqRS3JKxFCLmalRdrRftEkBa9Ytlp7g+KxEs7j1nKfeK6 X-Forefront-PRVS: 081904387B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(199003)(189002)(106356001)(5001960100002)(19580395003)(33646002)(47776003)(50466002)(19580405001)(230700001)(61296003)(76176999)(66066001)(1096002)(5008740100001)(81816999)(6116002)(77096005)(44736004)(1456003)(586003)(81686999)(44716002)(2906002)(15975445007)(3846002)(189998001)(50226001)(1556002)(226693001)(62236002)(105586002)(93886004)(97736004)(84392002)(5001770100001)(86362001)(81156007)(116806002)(40100003)(87976001)(14496001)(5004730100002)(92566002)(122386002)(42186005)(101416001)(4326007)(23756003)(50986999)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB061; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DBXPR07MB061; 23:qpdbG8Uv8jmBd38bH29CkQs2mZZZE6cTMAKAZ4dm?= =?iso-8859-1?Q?9rcMDqytA7W/VDpzayZdDsNq9wH8ZmRWTcmBQFBOHw044MFx4dtkdh9u7n?= =?iso-8859-1?Q?OWgrLXRBgehVBV0DVkFDuBGpgms31aVRyR6yFfh2hPZdn6It3DwuNiqBwU?= =?iso-8859-1?Q?fMxB+VD8MVRMjqfausYiYTyYp/zdFuT6/Z/gE2a4ky89nvnL7uudDYuxgY?= =?iso-8859-1?Q?mky79yMdJk5wcE7Fq6REzKv2Klc8IS1TPMJOLonnghIsnQHTv1fQSL0Cza?= =?iso-8859-1?Q?HyCCjJP09YuuVo+8ON0stQw5B1vvo9OV5zG8EuP/XdQMRZagasPhGLpdBm?= =?iso-8859-1?Q?+yEExi+C0OCNF+zRI69DEeBVwNu4jANUIa0xAIErH6mTBLBf2QXPn49B1x?= =?iso-8859-1?Q?CARIj10523TBGKccmjLNplCKcvjYka+qfjPfq0wqWnHD2FrBSEYzXvHa0D?= =?iso-8859-1?Q?HD7s7A9XQmdgRgOb9FCxW0D28tJbso7pFSNI2EpMdobKq9u6mPDNVqLXcx?= =?iso-8859-1?Q?d6KZ54TlpvvLkHJegrrd5UhuJLELhCFOk6Fcg4g6Id4LOFc8j7do/uSRbq?= =?iso-8859-1?Q?Oqy/c2D9u3I5yma79E4OnNl2i1oHwSIInhyzmrwik7POkhT1HYz2ckoso/?= =?iso-8859-1?Q?CIcb00okd0/Pksz6RCKlzdidip9UjLw/6KV63tba5q2Mv4IRt+p8t4kXXE?= =?iso-8859-1?Q?36rgZ4lbT+a86EAqFDXKjnFJKMiepLq9+pslhurHdM3eg2tMSsARZwREAe?= =?iso-8859-1?Q?MP7mKeuod2/8wWVjhNxoH1DM5JwLJcYztu0dzrEYaUynNitiqdLhNe7GoH?= =?iso-8859-1?Q?zn0iE8UC6nK6ZAUb30HVIdFMn/5AKjkOpegCUAQvWJKFotEfMRzxtUTYN4?= =?iso-8859-1?Q?dH7+BkXRm4Mz3J9H4ZudVwMAnUcYgRCocfXZPoJpyKz0hmP/luim/ymow5?= =?iso-8859-1?Q?oeU4rE69K3IVP5lziqopgIHEw9PcpjDvxWtZTX4CdEwALkK4VIB2O5Bmgn?= =?iso-8859-1?Q?uE5iwy7Uirqn8dmnDd1fnv3G71TSQaHw1j4Y0jTkoSqRekuPo4FeminH8w?= =?iso-8859-1?Q?7P6u8bcXZD3j+NNwMcgT4BU5YzXDgU7D8DhcCH8TlCSPNbtGJKbnMo1+1R?= =?iso-8859-1?Q?ua4T7GgaFMV1sJQcB8TE/V8K3NJHqPSYnrThyzgL8yvSpCS8R+HR0WeCKW?= =?iso-8859-1?Q?KE2FrPGltfuQMjU1MyJESwBITOzcgYd14xjE69wzGN24QwekpR/lvJ/jdx?= =?iso-8859-1?Q?yUxSFFD+lhz/HrZ9KmtL1hk70+wZw9Yrm/MRNO0CsAtGu+33VZY6809BZ0?= =?iso-8859-1?Q?B6/PuaEJnTSWPw96hyq3optWgGBSSQpQkOA/djUmbE34ClVsIByZnm2mOw?= =?iso-8859-1?Q?vASBEKycczRDZnG7FBSml9EgLqGJte2gXB//BPcQilLGDuR8/voghuC3+w?= =?iso-8859-1?Q?s24Bo8jrSil7M=3D?= X-Microsoft-Exchange-Diagnostics: 1; DBXPR07MB061; 5:Ri6lUhZpbRZ1R/hMP1V5tMEjAvuoFRiBanzzydmI6gutHwXsoOBZ8vJ1uSsPpWOZ1N8ajGcPiaEcbvRY0OOuKCxdOYFXdrGLl91MwtUiD9zuLcfyWIiJG1FfUi8cRg78K8llJdfDGsKKi/yIfzkAcQ==; 24:QtpvxgV4PR1gy5QzwtmDqCQQxSCrfRLKzj3tHs9STXKNdw0/9mCBJ7l1GTDb06UePljreeEbbRPKwjw2BA+Sc8GuGliR7/VnabvLtIzwC1E= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jan 2016 10:46:33.2377 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB061 Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Routers are hosts too! X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 10:47:00 -0000 ----- Original Message ----- From: To: Cc: ; ; Sent: Sunday, January 10, 2016 2:07 PM > > > But then RFC1122 does not mention classless addressing or Variable > > > Length Subnet Masks - as I recall, they did not exist at that time. > > > Rather, RFC1122 deals with 32 bit Host addresses and Classful Networks, > > > ie 8 or 16 or 24 bit addresses, so while you might have more than one > > > entry in the cache for a given destination, they will all be the same > > > length so the concept of longest-prefix (and of course, the term prefix > > > has no meaning at that date) match does not come into consideration. > > > > DO you mean that the longest-prefix match operation was not there since > > the earliest days of Internet? > > Reading up on the history of the Internet is recommended. See for > instance > > https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing Well, may be:-) When I got involved with TCP/IP in 1992, subnets were fixed length across any one network and longest match does not figure in any description of routing at that time (Perlman, Interconnections, 1992; IBM, TCP/IP Tutorial, 1989). Before then, subnets did not exist - they first appeared in RFC in 1984 (RFC950, 1985) so routing was purely based on the network address, Class A, B, C. Even in 1992, commercial products may not have had subnet support so when designing an IP network, I had to check vendor literature for subnet support before using it in a design. Variable length subnets meant that the routing protocols had to carry the length of the mask with the advertisement and you see this in RIPv2 (RFC1388, 1993) and this, coupled with CIDR, introduced me to the idea of longest match in the forwarding algorithm. I know of that from RFC1349 (1992) and it will have been around earlier, but not by much - as I say, it would have been alien to most at that time, certainly in the commercial world, as opposed to the more academic/research oriented IETF. Does the history matter? Well yes, if you are citing documents such as RFC written at that time, ones which have not been superseded or updated in that regard, such as RFC1122. Host versus Router is one such, but another is gateway (the term router is relatively recent if you look at the RFC series as a whole) while the definition of the Network layer generates divergent opinions on some IETF list; and then, when did the Internet start? April 1995 is my date, but I recognise that that depends on your definition of Internet. Best practice is to put in, or cite, a definition so others are clear what you (think:-) you are talking about. Tom Petch > Steinar Haug, AS2116 From nobody Tue Jan 12 06:53:27 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A50601B2A75 for ; Tue, 12 Jan 2016 06:53:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, 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 JH1b06x_hXYe for ; Tue, 12 Jan 2016 06:53:24 -0800 (PST) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E4B61B2A73 for ; Tue, 12 Jan 2016 06:53:24 -0800 (PST) Received: by mail-ig0-x22b.google.com with SMTP id mw1so131761923igb.1 for ; Tue, 12 Jan 2016 06:53:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=iBK58vHBnVLx1mJwbueznmjU71ZgFad2noHvIY1c2cU=; b=oc6TcmHRq8crF7oe98YsR68gYP2ajUmpTUfPD1Mx521IMBlK6RQIr6KxnoN1Z7J/Tn rp/0mhE2qFKiMBY5Jh0LOGgykI6ioYyTGat/qOv37zc4HMr0Jlkh0Kp5cG/Z4D/ZQK0w BnP1s6MeztYc+ae9YXufJt9ekaaFgAQAmd+efzo5jWYNo1qk/yXFJeLVtsnWzRzTApVw zXRdnQYuIs5N0ns7ekGAgtkZiPYnarcFvSjkM8Dd5Y2FAGaVxJd+8ViMtscBaW8bvJPU fOOv/H/qw9pN2vcE2Q+bsa+nVLuuQF5R3je6BRtVTiGSvMEyNv6Y9uXCl3hXZnV3VGss SRMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=iBK58vHBnVLx1mJwbueznmjU71ZgFad2noHvIY1c2cU=; b=m/9YV/nmKaTAWsOIGV5Q2i0YtRKJZsSr3TtjnpZaUV4ainkp6Y3mj5asVP6t7/NOSW sgSyGZNcvJiqedy4dJgzsPCr4dUgGVgQOA5ytsIhot0hgmLx7Xaqpu5DzGdeNL1DEp8w GAcCGuJ+APdEKMMVzWnjiW3yYWURnNrmCSYp/CZICcr3d5Oj8lWKPZHIUdj/1652GtWy krkCorxFaJ6zvv0HiO/3gknC2wRqpSZQiwtY1AUsh2lDGqHRJthVb9ET0SFuxsOGx9FG tt9ZgWh+V5KBPWJYtfJvOh7x8PNp2/wuuRJ9A/ZAU2P7lXBL3yx+azeQz/ZA5sDkOyJP TOwA== X-Gm-Message-State: ALoCoQl2RHk1dt6EDsgiPfVsjSoRGNO8GY73wmxEUIFX3+UuNfh17n724KCJ7yL45TgikT0w++G2S/VfPh/JvlZAPMczCf/Le7IIrPWYg47Uj5s7msG0Cdc= X-Received: by 10.50.73.199 with SMTP id n7mr17091815igv.1.1452610403976; Tue, 12 Jan 2016 06:53:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.31.36 with HTTP; Tue, 12 Jan 2016 06:53:04 -0800 (PST) In-Reply-To: <5690A640.1020009@isi.edu> References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <568D1854.7000300@gmail.com> <568FAA3B.3050108@gmail.com> <5690A640.1020009@isi.edu> From: Erik Kline Date: Tue, 12 Jan 2016 23:53:04 +0900 Message-ID: To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org WG" , Philip Homburg Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 14:53:25 -0000 > (Fred: though I agree this is afield from the original thread, I find it > hard to understand how a coherent discussion about host addressing can > occur given the confusion about what a host is on this list) Somewhat similarly, I find it hard to understand where things stand with this document at this moment. Let me propose two things: [1] Is it important that we, as IPv6 folk, can make a Best Practices statement about ensuring that the bounty of IPv6 addresses be shared far and wide, avoiding incentives for NAT66. As such, I favour some document with BCP status. [2] Perhaps we can resolve people's concerns with the "C" in BCP by simply adding a few statements to the effect of: "[WRT to the set of multiple address solutions] Outside of SLAAC there is currently little experience with either DHCPv6 multiple IA_NA or IA_PD in host OSes. Nevertheless, these are the only currently standardized solutions theoretically capable of fulfilling the requirements [ref = Section 7]." ...or something worded more intelligently by someone not minutes from sleep. Would this work? From nobody Tue Jan 12 07:39:01 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4741B2AB9 for ; Tue, 12 Jan 2016 07:38:57 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc" X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] 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 pB2Ca4-pDbNg for ; Tue, 12 Jan 2016 07:38:50 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo6-he.hq.phicoh.net [IPv6:2001:470:d16a:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 00BF71B2A9F for ; Tue, 12 Jan 2016 07:38:49 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1aJ11z-0000FUC; Tue, 12 Jan 2016 16:38:47 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <568D1854.7000300@gmail.com> <568FAA3B.3050108@gmail.com> <5690A640.1020009@isi.edu> In-reply-to: Your message of "Tue, 12 Jan 2016 23:53:04 +0900 ." Date: Tue, 12 Jan 2016 16:38:44 +0100 Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 15:38:57 -0000 In your letter dated Tue, 12 Jan 2016 23:53:04 +0900 you wrote: >Let me propose two things: > > [1] Is it important that we, as IPv6 folk, can make a Best >Practices statement about ensuring that the bounty of IPv6 addresses >be shared far and wide, avoiding incentives for NAT66. As such, I >favour some document with BCP status. I fully agree that it would be absurd if address shortage would cause people if deploy NAT66. However, why do we need a BCP now? By and large we don't have a problem in networks that use SLAAC. And I'm not aware of any developments that suggest that it will be a problem in the near future. Of course SLAAC is sub-optimal if the device has a complex desk area network behind it (or has a complex VM/container configuration) We may have a problem in networks that use DHCPv6 IA_NA. But that is exactly the configuration where we cannot give any advice based on experience. So why not add some DHCPv6 IA_NA (that requests multiple address) or IA_PD support to a popular host platform, encourage a big DHCPv6 site to support it and then publish a BCP based on that experience. Maybe have DHCP-only networks at IETF (or RIR) meetings to see if devices properly support DHCPv6 or not. From nobody Tue Jan 12 07:48:10 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BECE61B2ABF for ; Tue, 12 Jan 2016 07:48:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 sGdbyYMTb3oB for ; Tue, 12 Jan 2016 07:48:06 -0800 (PST) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.119.20]) by ietfa.amsl.com (Postfix) with ESMTP id 960511B2ABB for ; Tue, 12 Jan 2016 07:48:06 -0800 (PST) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128/128); for ; Tue, 12 Jan 2016 09:48:05 -0600 (CST) X-Umn-Remote-Mta: [N] mail-pa0-f48.google.com [209.85.220.48] #+LO+TS+TR X-Umn-Classification: local Received: by mail-pa0-f48.google.com with SMTP id ho8so80833516pac.2 for ; Tue, 12 Jan 2016 07:48:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=reply-to:subject:references:to:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=U/hZIBKaDrGjrKnvjGpPWdoATlO3zbrXfD2e31lDbQA=; b=Z4ryFCTS9DyNFCXOqiLkoCYbV9Js/2LPhj10ZurwoY1rZPF16w0eHWhRucLfnk/CaH ySDcxB0F7+EwvvOh9UAXAKVUGHf+0mPUdN9mm/+DDy8g9emkKHM4vaKt+LB3wMHrYvA8 awIFiIfN2IrImJCQsUmCf4br7JOcZANNNi9lQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:cc:from :organization:message-id:date:user-agent:mime-version:in-reply-to :content-type:content-transfer-encoding; bh=U/hZIBKaDrGjrKnvjGpPWdoATlO3zbrXfD2e31lDbQA=; b=du3wcc5mNNxNMSbPCwZTnUeb5+7V2TJ2L9dDM3uUpzCu720MRYwO5uWHeZkAe6rtVU ey5DSMXUkkbZ2n044vnSg0HiwQCNbfB42aEnVAJKU/gweRhqvJ0VZyCEgxJaWq7YlC1K c6tHd0t3j0XO+ZRv/M4Lg4wJRcyaQf6Bpv5Wc/YTQZH4jjoukR52Wgab2Yd7nqNvcX4r zjkAebaH+FGrgB88teMpgakQrQl+o+5WFzq5pm+158eLmtSMJXSf90ne+8Lu0q5+8sp2 JEfDXW2G4W6h43OrVDyRQ4/QCVNLVNV8gdry9+Mqx9CvVXBDQX6QqT/mKRpyN1hqmHMu P5+Q== X-Gm-Message-State: ALoCoQnm9L929bXIE4ygGnOFzuJx8cTXbhp0SSqtSgW0ZYm2eeTuQkR+v47dqrcivAb/7EphMoXEIWBWCR02YnSSRU1zNBWUT6U2icqNcLMYWE5FcNUH9sTKe6AcYgFDEM8Z0Te5cgH/CVfLYMTV+jXu9ACA+gWxhA== X-Received: by 10.66.65.203 with SMTP id z11mr190674821pas.152.1452613684643; Tue, 12 Jan 2016 07:48:04 -0800 (PST) X-Received: by 10.66.65.203 with SMTP id z11mr190674801pas.152.1452613684504; Tue, 12 Jan 2016 07:48:04 -0800 (PST) Received: from x-134-84-2-193.vpn.umn.edu ([2607:ea00:103:4803::1e]) by smtp.gmail.com with ESMTPSA id n27sm31325223pfb.53.2016.01.12.07.48.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Jan 2016 07:48:02 -0800 (PST) References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <568D1854.7000300@gmail.com> <568FAA3B.3050108@gmail.com> <5690A640.1020009@isi.edu> To: Erik Kline From: David Farmer Organization: University of Minnesota Message-ID: <5695202F.5010206@umn.edu> Date: Tue, 12 Jan 2016 09:47:59 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 15:48:08 -0000 On 1/12/16 08:53 , Erik Kline wrote: >> (Fred: though I agree this is afield from the original thread, I find it >> hard to understand how a coherent discussion about host addressing can >> occur given the confusion about what a host is on this list) > > Somewhat similarly, I find it hard to understand where things stand > with this document at this moment. > > Let me propose two things: > > [1] Is it important that we, as IPv6 folk, can make a Best > Practices statement about ensuring that the bounty of IPv6 addresses > be shared far and wide, avoiding incentives for NAT66. As such, I > favour some document with BCP status. > > [2] Perhaps we can resolve people's concerns with the "C" in BCP > by simply adding a few statements to the effect of: > > "[WRT to the set of multiple address solutions] Outside of > SLAAC there is currently little experience with either DHCPv6 multiple > IA_NA or IA_PD in host OSes. Nevertheless, these are the only > currently standardized solutions theoretically capable of fulfilling > the requirements [ref = Section 7]." > > ...or something worded more intelligently by someone not minutes from sleep. > > Would this work? I agree with both points! And, not so clearly and concisely I think it says that already. So yes, I support that language or something very much like it. Additionally, I think DHCPv6 with multiple IA_NA is a viable solution to the issue and if the authors do not, they need to more clearly explain why not. Personally, I'm OK with recommending DHCPv6 IA_PD over multiple IA_NA, I think there are definite advantages to DHCPv6 IA_PD. However, without a stronger explanation why DHCPv6 with multiple IA_NA is not a viable solution, it should not be implied that multiple IA_NA is not a viable solution. I think it needs to be more clearly stated that DHCPv6 with multiple IA_NA is a viable solution, even if it is not the recommended solution. Further, I think it should be clearly stated that DHCPv6 with a single IA_NA does not meet the requirements of the draft. Thanks. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nobody Tue Jan 12 08:00:15 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A685F1B2AE9 for ; Tue, 12 Jan 2016 08:00:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.502 X-Spam-Level: X-Spam-Status: No, score=-114.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, 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 25dvRoZnZeTy for ; Tue, 12 Jan 2016 08:00:12 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F8231B2AD8 for ; Tue, 12 Jan 2016 08:00:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2839; q=dns/txt; s=iport; t=1452614412; x=1453824012; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=VFvRUKEVuTYh7pI+r1qIenzDnBLsxwyS5I98hN98rJU=; b=Hi43eq4Xg8PLHfpcJJIXLkEnIFwrL8EjbDzB0glLcFqTerWKH+EaC96i AnQK7IWzRJx2ve5pkdVNoks7k6v8Bmbc0VOPoTg15G8CjeoDrFD1dCH3T CChf898kX+sa2DobeibypfShne4uSDaBc+AS70LKEMgpMjnqf/DsxvFOt I=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BCBQAiIpVW/5JdJa1egzpSbQaIU7Mzg?= =?us-ascii?q?WYYCoVtAoEnORMBAQEBAQEBgQqENAEBAQMBAQEBawsFCwIBCA4KLicLJQIEDgU?= =?us-ascii?q?ODYgLCA6/fQEBAQEBAQEBAQEBAQEBAQEBAQEBEAUEiGUIgmiIIoEbBZMQhAMBg?= =?us-ascii?q?nOBZYkAjnyOUgEkAT+ECnKFKYEIAQEB?= X-IronPort-AV: E=Sophos;i="5.20,558,1444694400"; d="asc'?scan'208";a="226483147" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jan 2016 16:00:11 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u0CG0AAA007471 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 12 Jan 2016 16:00:10 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 12 Jan 2016 10:00:10 -0600 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1104.009; Tue, 12 Jan 2016 10:00:10 -0600 From: "Fred Baker (fred)" To: Erik Kline Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt Thread-Index: AQHRTVJQo4PYD8iOdkK2B1uVxjfgbg== Date: Tue, 12 Jan 2016 16:00:09 +0000 Message-ID: <5FBF41F4-9119-40F2-A3D9-5E138011AE82@cisco.com> References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <568D1854.7000300@gmail.com> <568FAA3B.3050108@gmail.com> <5690A640.1020009@isi.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3112) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.64.115] Content-Type: multipart/signed; boundary="Apple-Mail=_2868779F-2891-4305-A181-3EF4A94D2E04"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org WG" , Philip Homburg Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 16:00:13 -0000 --Apple-Mail=_2868779F-2891-4305-A181-3EF4A94D2E04 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jan 12, 2016, at 6:53 AM, Erik Kline wrote: >=20 >> (Fred: though I agree this is afield from the original thread, I find = it >> hard to understand how a coherent discussion about host addressing = can >> occur given the confusion about what a host is on this list) >=20 > Somewhat similarly, I find it hard to understand where things stand > with this document at this moment. >=20 > Let me propose two things: >=20 > [1] Is it important that we, as IPv6 folk, can make a Best > Practices statement about ensuring that the bounty of IPv6 addresses > be shared far and wide, avoiding incentives for NAT66. As such, I > favour some document with BCP status. On that I strongly agree. > [2] Perhaps we can resolve people's concerns with the "C" in BCP > by simply adding a few statements to the effect of: >=20 > "[WRT to the set of multiple address solutions] Outside of > SLAAC there is currently little experience with either DHCPv6 multiple > IA_NA or IA_PD in host OSes. Nevertheless, these are the only > currently standardized solutions theoretically capable of fulfilling > the requirements [ref =3D Section 7]." That would encapsulate what I understand to have been agreed to. > ...or something worded more intelligently by someone not minutes from = sleep. >=20 > Would this work? >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_2868779F-2891-4305-A181-3EF4A94D2E04 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBVpUjCUayAOS/EQ8MAQKvOBAAtOAh+a2QqSRfjkRHUgjHSQur5m+wsU/U axgKPmkh/d2b5WFb21IzFKQ83NyGxlgGspgxFL3CvRfnTdbeGBw6qKC+35umVqaD vYyIl9cv34ybqbG/1eCj0DU3LHce0gvAJO2PgXigzuoxaPtyz9w2gciNNpV6PwDL /ki8MHeBh7ul0MIcctLhgbAw9KCOa57J8Ts7wO4m8qGAWN11TFnHpsadMp46rZ0h NIn8hJQkEPT8u8o8UM3YDG2ITg5aQRLblniEq5bRWrrbovHGOK/4XOf7VjImwIlj 6luYXBHj4um+EyFAwPYkj6tIwQ+QL7axTHbWvgdi77gRBcyYXpAboSLBGI7l8z7F 9PomPPVqIIEkIiGpWFhe1NqpYHz+S4BgjGvIw+ec+qZq2AF2SUYn5/7i1ycfpSWo DZf2fCMosklPoPlQna1yh1iJCp2QSjoLeqEkT7rjh+FvQe6150tdU814+5A1E7KO FZdSHa4N1lXw6z4a1ZleECKWg+JSh+9DPtjsSsSNOKKCt9DeIAnCoLVdTtO2ZImF zgBlkTwhMRPJfhWmt3t1otTeKo2LJhzk6XpWSE8Yojev1K1a4RwJM3rx8dz5nYSM 7GI+o/C2YvpQouYEntrKugEKItPiS/y4CjHyyHZlGeJ11659GPRcobymigFUynup xFoLe5EC4fE= =EF0T -----END PGP SIGNATURE----- --Apple-Mail=_2868779F-2891-4305-A181-3EF4A94D2E04-- From nobody Tue Jan 12 08:22:14 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75DAD1B2B13 for ; Tue, 12 Jan 2016 08:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpTTHhw80J2q for ; Tue, 12 Jan 2016 08:22:11 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id D7C361B2B17 for ; Tue, 12 Jan 2016 08:22:10 -0800 (PST) Received: (qmail 25926 invoked from network); 12 Jan 2016 16:22:09 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 12 Jan 2016 16:22:09 -0000 Date: Tue, 12 Jan 2016 17:22:09 +0100 (CET) Message-Id: <20160112.172209.74729517.sthaug@nethelp.no> To: farmer@umn.edu From: sthaug@nethelp.no In-Reply-To: <5695202F.5010206@umn.edu> References: <5690A640.1020009@isi.edu> <5695202F.5010206@umn.edu> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 16:22:13 -0000 > Additionally, I think DHCPv6 with multiple IA_NA is a viable solution to > the issue and if the authors do not, they need to more clearly explain > why not. Personally, I'm OK with recommending DHCPv6 IA_PD over > multiple IA_NA, I think there are definite advantages to DHCPv6 IA_PD. Fully agreed. > However, without a stronger explanation why DHCPv6 with multiple IA_NA > is not a viable solution, it should not be implied that multiple IA_NA > is not a viable solution. I think it needs to be more clearly stated > that DHCPv6 with multiple IA_NA is a viable solution, even if it is not > the recommended solution. Further, I think it should be clearly stated > that DHCPv6 with a single IA_NA does not meet the requirements of the > draft. We can certainly recommend DHCPv6 IA_PD as a better solution - but DHCPv6 with multiple IA_NA *will* happen. I see nothing wrong with it. Steinar Haug, AS2116 From nobody Tue Jan 12 08:46:30 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43FCA1AD357 for ; Tue, 12 Jan 2016 08:46:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIdtBR9bl0D5 for ; Tue, 12 Jan 2016 08:46:28 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5CE61A8919 for ; Tue, 12 Jan 2016 08:46:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1968; q=dns/txt; s=iport; t=1452617187; x=1453826787; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=bh69HjSy6AfEshSVllkF7nK0sowOEms0ZzsqWf9UIkg=; b=m7pV4rHktYk1ILCJ6Su/2RzBlZQwhAXguWhD6mS7QuM1LsOA12l67S+z GkbMhSWapU5ih7YUec+I+IZCyVYYvqOvQjfdoUzfF6jsTZarNCeyjNPTi LIsuGOGapcDr9qLzhxErXpZYaH5KwaBcVIrbU+hb+1MN/7wVo9UXtsJJk A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AaAgDiLJVW/5JdJa1eDoMsUm0GiFOzJ?= =?us-ascii?q?QENgWQYCoVtAhyBDDgUAQEBAQEBAYEKhDUBAQQBAQEgEToLEAIBCA4MAiYCAgI?= =?us-ascii?q?lCxUQAgQBDQUbiBMOr1GQLQEBAQEBAQEBAQEBAQEBAQEBAQEBARQEgQGFVQGEf?= =?us-ascii?q?oRVGIMHgUkBBJcTAY1YjnyOUgEgAQFCg0w+coU8gQgBAQE?= X-IronPort-AV: E=Sophos;i="5.20,558,1444694400"; d="scan'208";a="60844582" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jan 2016 16:46:26 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u0CGkQML007527 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 12 Jan 2016 16:46:26 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 12 Jan 2016 11:46:25 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Tue, 12 Jan 2016 11:46:26 -0500 From: "Eric Vyncke (evyncke)" To: Erik Kline , Joe Touch Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt Thread-Index: AQHRTVjGbWaGzyher06gzQpgQ9qScg== Date: Tue, 12 Jan 2016 16:46:25 +0000 Message-ID: References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <568D1854.7000300@gmail.com> <568FAA3B.3050108@gmail.com> <5690A640.1020009@isi.edu> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.56.4] Content-Type: text/plain; charset="utf-8" Content-ID: <624D0A0C25525242956585507D3C6C27@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org WG" , Philip Homburg Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 16:46:29 -0000 KzIgKDEgcGVyIGJ1bGxldCkNCg0KT24gMTIvMDEvMTYgMTU6NTMsICJ2Nm9wcyBvbiBiZWhhbGYg b2YgRXJpayBLbGluZSIgPHY2b3BzLWJvdW5jZXNAaWV0Zi5vcmcNCm9uIGJlaGFsZiBvZiBla0Bn b29nbGUuY29tPiB3cm90ZToNCg0KPj4gKEZyZWQ6IHRob3VnaCBJIGFncmVlIHRoaXMgaXMgYWZp ZWxkIGZyb20gdGhlIG9yaWdpbmFsIHRocmVhZCwgSSBmaW5kIGl0DQo+PiBoYXJkIHRvIHVuZGVy c3RhbmQgaG93IGEgY29oZXJlbnQgZGlzY3Vzc2lvbiBhYm91dCBob3N0IGFkZHJlc3NpbmcgY2Fu DQo+PiBvY2N1ciBnaXZlbiB0aGUgY29uZnVzaW9uIGFib3V0IHdoYXQgYSBob3N0IGlzIG9uIHRo aXMgbGlzdCkNCj4NCj5Tb21ld2hhdCBzaW1pbGFybHksIEkgZmluZCBpdCBoYXJkIHRvIHVuZGVy c3RhbmQgd2hlcmUgdGhpbmdzIHN0YW5kDQo+d2l0aCB0aGlzIGRvY3VtZW50IGF0IHRoaXMgbW9t ZW50Lg0KPg0KPkxldCBtZSBwcm9wb3NlIHR3byB0aGluZ3M6DQo+DQo+ICAgIFsxXSBJcyBpdCBp bXBvcnRhbnQgdGhhdCB3ZSwgYXMgSVB2NiBmb2xrLCBjYW4gbWFrZSBhIEJlc3QNCj5QcmFjdGlj ZXMgc3RhdGVtZW50IGFib3V0IGVuc3VyaW5nIHRoYXQgdGhlIGJvdW50eSBvZiBJUHY2IGFkZHJl c3Nlcw0KPmJlIHNoYXJlZCBmYXIgYW5kIHdpZGUsIGF2b2lkaW5nIGluY2VudGl2ZXMgZm9yIE5B VDY2LiAgQXMgc3VjaCwgSQ0KPmZhdm91ciBzb21lIGRvY3VtZW50IHdpdGggQkNQIHN0YXR1cy4N Cj4NCj4gICAgWzJdIFBlcmhhcHMgd2UgY2FuIHJlc29sdmUgcGVvcGxlJ3MgY29uY2VybnMgd2l0 aCB0aGUgIkMiIGluIEJDUA0KPmJ5IHNpbXBseSBhZGRpbmcgYSBmZXcgc3RhdGVtZW50cyB0byB0 aGUgZWZmZWN0IG9mOg0KPg0KPiAgICAgICAgIltXUlQgdG8gdGhlIHNldCBvZiBtdWx0aXBsZSBh ZGRyZXNzIHNvbHV0aW9uc10gT3V0c2lkZSBvZg0KPlNMQUFDIHRoZXJlIGlzIGN1cnJlbnRseSBs aXR0bGUgZXhwZXJpZW5jZSB3aXRoIGVpdGhlciBESENQdjYgbXVsdGlwbGUNCj5JQV9OQSBvciBJ QV9QRCBpbiBob3N0IE9TZXMuICBOZXZlcnRoZWxlc3MsIHRoZXNlIGFyZSB0aGUgb25seQ0KPmN1 cnJlbnRseSBzdGFuZGFyZGl6ZWQgc29sdXRpb25zIHRoZW9yZXRpY2FsbHkgY2FwYWJsZSBvZiBm dWxmaWxsaW5nDQo+dGhlIHJlcXVpcmVtZW50cyBbcmVmID0gU2VjdGlvbiA3XS4iDQo+DQo+Li4u b3Igc29tZXRoaW5nIHdvcmRlZCBtb3JlIGludGVsbGlnZW50bHkgYnkgc29tZW9uZSBub3QgbWlu dXRlcyBmcm9tDQo+c2xlZXAuDQo+DQo+V291bGQgdGhpcyB3b3JrPw0KPg0KPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+djZvcHMgbWFpbGluZyBsaXN0 DQo+djZvcHNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3Y2b3BzDQoNCg== From nobody Tue Jan 12 11:33:19 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B24E1A874E for ; Tue, 12 Jan 2016 11:33:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 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, FROM_LOCAL_NOVOWEL=0.5, GB_I_LETTER=-2, HK_RANDOM_ENVFROM=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 DIIyZML-RbEY for ; Tue, 12 Jan 2016 11:33:16 -0800 (PST) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B5401A876F for ; Tue, 12 Jan 2016 11:33:15 -0800 (PST) Received: by mail-vk0-x22d.google.com with SMTP id k1so248913259vkb.2 for ; Tue, 12 Jan 2016 11:33:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rclwZ9x9F+8ErapQdOVZ7ovqL4fb5Z9+gmWCXruuDLk=; b=Pc2ihzuz2umrME0eBdukbZFkU3wPS3A/J9Hfcc95a/U592CStZ//N4i8C8ckoe7ZRT +n015JTjastYM3U7NTM+jjvYGU+o3HqPPUbXUpa9Zjx+ImtE3Xq4fyM43q8kwiPNLcp1 1DdNXFrmU/FBHzfxxwUpKl40NNU8xz7sLRn4++lMA5TqwCVa9OtOlT07xL66KSjDX3MX IjyeejCuaF2Kz4NUYws0cPG0UOFyQcbbRJBmvBC+FZ94o/Ycp1odYM5Dzebg3iqZ9QhZ CF/1MyOBrruUVz/EoY/Yu1EgQxs4y7UTEIqbCG74cdpESTNFOxRRVMvH7xg5Q7F9f/lY bpYQ== MIME-Version: 1.0 X-Received: by 10.31.107.138 with SMTP id k10mr86980360vki.27.1452627194341; Tue, 12 Jan 2016 11:33:14 -0800 (PST) Received: by 10.103.99.1 with HTTP; Tue, 12 Jan 2016 11:33:13 -0800 (PST) Received: by 10.103.99.1 with HTTP; Tue, 12 Jan 2016 11:33:13 -0800 (PST) In-Reply-To: References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <568D1854.7000300@gmail.com> <568FAA3B.3050108@gmail.com> <5690A640.1020009@isi.edu> Date: Wed, 13 Jan 2016 06:33:13 +1100 Message-ID: From: Mark Smith To: Philip Homburg Content-Type: multipart/alternative; boundary=001a11478cb8e8eed20529281f63 Archived-At: Cc: v6ops list Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 19:33:18 -0000 --001a11478cb8e8eed20529281f63 Content-Type: text/plain; charset=UTF-8 On 13 Jan 2016 02:39, "Philip Homburg" wrote: > > In your letter dated Tue, 12 Jan 2016 23:53:04 +0900 you wrote: > >Let me propose two things: > > > > [1] Is it important that we, as IPv6 folk, can make a Best > >Practices statement about ensuring that the bounty of IPv6 addresses > >be shared far and wide, avoiding incentives for NAT66. As such, I > >favour some document with BCP status. > > I fully agree that it would be absurd if address shortage would cause people > if deploy NAT66. > > However, why do we need a BCP now? > I think the "now" is not so much 2016, I think it is more about being proactive, and trying to make a strong statement that IPv4's address conservatism mentality is not only unnecessary but also will be limiting in an IPv6 context. I'm not sure what motivated the authors to start writing this, however it feels like the right time to me for a variety of reasons - VMs and containers, IoT and RIRs running out of IPv4 addresses are all going to be bringing the need for more addresses to the forefronts of peoples' minds. I think the need to deploy IPv6 will become more obvious to those people if it isn't already. To some extent this is more of a BCP on what not to do (artificially and unnecessarily limit addresses) rather than what to do, as, as you observe, there probably isn't much address limiting going on right now (although I wouldn't be all that surprised if some mobile carriers try it on given their tethering history,). > By and large we don't have a problem in networks that use SLAAC. And I'm not > aware of any developments that suggest that it will be a problem in the > near future. Of course SLAAC is sub-optimal if the device has a complex > desk area network behind it (or has a complex VM/container configuration) > > We may have a problem in networks that use DHCPv6 IA_NA. But that is > exactly the configuration where we cannot give any advice based on experience. > > So why not add some DHCPv6 IA_NA (that requests multiple address) or IA_PD > support to a popular host platform, encourage a big DHCPv6 site to support > it and then publish a BCP based on that experience. > > Maybe have DHCP-only networks at IETF (or RIR) meetings to see if devices > properly support DHCPv6 or not. > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --001a11478cb8e8eed20529281f63 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 13 Jan 2016 02:39, "Philip Homburg" <pch-v6ops-4@u-1.phicoh.com> wrote:
>
> In your letter dated Tue, 12 Jan 2016 23:53:04 +0900 you wrote:
> >Let me propose two things:
> >
> >=C2=A0 =C2=A0 [1] Is it important that we, as IPv6 folk, can make = a Best
> >Practices statement about ensuring that the bounty of IPv6 address= es
> >be shared far and wide, avoiding incentives for NAT66.=C2=A0 As su= ch, I
> >favour some document with BCP status.
>
> I fully agree that it would be absurd if address shortage would cause = people
> if deploy NAT66.
>
> However, why do we need a BCP now?
>

I think the "now" is not so much 2016, I think it = is more about being proactive, and trying to make a strong statement that I= Pv4's address conservatism mentality is not only unnecessary but also w= ill be limiting in an IPv6 context.

I'm not sure what motivated the authors to start writing= this, however it feels like the right time to me for a variety of reasons = - VMs and containers, IoT and RIRs running out of IPv4 addresses are all go= ing to be bringing the need for more addresses to the forefronts of peoples= ' minds. I think the need to deploy IPv6 will become more obvious to th= ose people if it isn't already.

To some extent this is more of a BCP on what not to do (arti= ficially and unnecessarily limit addresses) rather than what to do, as, as = you observe, there probably isn't much address limiting going on right = now (although I wouldn't be all that surprised if some mobile carriers = try it on given their tethering history,).

> By and large we don't have a problem in networks th= at use SLAAC. And I'm not
> aware of any developments that suggest that it will be a problem in th= e
> near future. Of course SLAAC is sub-optimal if the device has a comple= x
> desk area network behind it (or has a complex VM/container configurati= on)
>
> We may have a problem in networks that use DHCPv6 IA_NA. But that is > exactly the configuration where we cannot give any advice based on exp= erience.
>
> So why not add some DHCPv6 IA_NA (that requests multiple address) or I= A_PD
> support to a popular host platform, encourage a big DHCPv6 site to sup= port
> it and then publish a BCP based on that experience.
>
> Maybe have DHCP-only networks at IETF (or RIR) meetings to see if devi= ces
> properly support DHCPv6 or not.
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--001a11478cb8e8eed20529281f63-- From nobody Tue Jan 12 20:40:23 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00A681A90EB for ; Tue, 12 Jan 2016 20:40:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 evvTGkjiXb9J for ; Tue, 12 Jan 2016 20:40:20 -0800 (PST) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEE111A6FC6 for ; Tue, 12 Jan 2016 20:40:19 -0800 (PST) Received: by mail-yk0-x234.google.com with SMTP id x67so477385177ykd.2 for ; Tue, 12 Jan 2016 20:40:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=58er00hteufPLWLKeKQd9vMNjhLkVMcPuBm8QXcXZVw=; b=AFSCXm91rvUP76PUltv5JDYVVmf4JghCePZchpXOjw9JQKmqV7L7SH0k52976Q6cHp qPu6Or0BI9RY/XJdCYj5wfhr8+lXnVQqTkluDQB/EGH8N8qB5RyC7GlXrnvKdIe63/Zg gfkKfY301x3fn3633hKy2YDMxd3RcqEg4frlZsKpLSbtecZBrEv+arlZ2Yo0lZhkBkJ9 ycpzdzcvckr0G/RPtxtI9PS+qPYdVS11vzqs8vSoYDEfCbc/NaiA5gcPjFyuYq8Nbwm5 5OrUiDIDIkaFRgjsKH8d4QRUV7OWB6eTpYAXT8AeSw7/EXyNe8kwGDYFG2K7Tz1q9/Y/ i53A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=58er00hteufPLWLKeKQd9vMNjhLkVMcPuBm8QXcXZVw=; b=C9+v/Qq/OmU54JwfQlcdnYb5MuEtH4EbuDltCr/TajWEifawwVp8WV7tKTpD2JWUHv seODnfxYWJtRz9bxAj/LKxDxyzQ4vYJ8gvA1BZr8bjbFSCZ9dGpSaoAz/L335z2WMMm9 NqLcoYfE/FPe/ye5RSeSIWX80vEM3T9VmXk3buV6p5UOxZ7Q9hSe9RzIn5zJhbITJUZd 9abUQ+sYpffayLGT7lkC/qr9kVW7KPDw22sBhJnuyzAyBu1qP+hD6cOSO+ZXxTTs819d mZ1zlaO+kwMVx27ybzvBB9Xzn6Xi4lf+a+pKE60J5TqG3tDNQEsGOMLf0f5o80UBYNN8 NvPg== X-Gm-Message-State: ALoCoQlYMZGOlBWomKSr3jjTXjqTBjYtk/Ke4SET8QRtoGIRNd4S3K3JkTWYvkaBWz7q6Kn3TTOSs7PQA3woHB4yYem8BjbdzErfTliDVwMygcHGdFwgDyw= X-Received: by 10.13.205.199 with SMTP id p190mr111802080ywd.116.1452660019181; Tue, 12 Jan 2016 20:40:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.208.201 with HTTP; Tue, 12 Jan 2016 20:39:58 -0800 (PST) In-Reply-To: <5695202F.5010206@umn.edu> References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <568D1854.7000300@gmail.com> <568FAA3B.3050108@gmail.com> <5690A640.1020009@isi.edu> <5695202F.5010206@umn.edu> From: Lorenzo Colitti Date: Wed, 13 Jan 2016 13:39:58 +0900 Message-ID: To: David Farmer Content-Type: multipart/alternative; boundary=001a114e5eb66cd8f605292fc456 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 04:40:22 -0000 --001a114e5eb66cd8f605292fc456 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 13, 2016 at 12:47 AM, David Farmer wrote: > "[WRT to the set of multiple address solutions] Outside of >> SLAAC there is currently little experience with either DHCPv6 multiple >> IA_NA or IA_PD in host OSes. Nevertheless, these are the only >> currently standardized solutions theoretically capable of fulfilling >> the requirements [ref = Section 7]." >> [...] >> > > I agree with both points! > > And, not so clearly and concisely I think it says that already. So yes, I > support that language or something very much like it. > Ok, then. How about putting this at the end of section 6: It should be noted that while providing multiple addresses via SLAAC is well understood, there is currently limited experience in host operating systems with DHCPv6 PD, and little or no experience providing multiple addresses via multiple IA_NA options or multiple DUIDs per host. However, these are the only currently standardized options that can provide multiple addresses on networks that do not use SLAAC. And leaving the current recommendations section as is, like so? [...] If the network requires explicit requests for address space (e.g., if it requires DHCPv6 to connect), it is RECOMMENDED that the network assign a /64 prefix to every host (e.g., via DHCPv6 PD). Using DHCPv6 IA_NA or IA_TA to request a sufficient number of addresses (e.g. 32) would accommodate current clients but sets a limit on the number of addresses available to hosts when they attach and would limit the development of future applications. Assigning prefixes longer than a /64 will limit [...] > Additionally, I think DHCPv6 with multiple IA_NA is a viable solution to > the issue and if the authors do not, they need to more clearly explain why > not. Personally, I'm OK with recommending DHCPv6 IA_PD over multiple > IA_NA, I think there are definite advantages to DHCPv6 IA_PD. However, > without a stronger explanation why DHCPv6 with multiple IA_NA is not a > viable solution, it should not be implied that multiple IA_NA is not a > viable solution. I think it needs to be more clearly stated that DHCPv6 > with multiple IA_NA is a viable solution, even if it is not the recommended > solution. Further, I think it should be clearly stated that DHCPv6 with a > single IA_NA does not meet the requirements of the draft. > It seems to me that the text already addresses the points you raise. It does not say or imply that multiple IA_NA is not viable, it just recommends IA_PD over IA_NA for the reason that it is more future-proof and more extensible. Also, I think it is already pretty clear that a single IA_NA does not meet the requirements, because the text says "it is RECOMMENDED that IPv6 network deployments provide multiple IPv6 addresses [...]", and "multiple" obviously cannot mean one. As for multiple IA_NA, yes - it is much more limited. Without using fragmentation (and it seems like a pretty bad idea to rely on fragmentation for DHCPv6 packets), the practical limit to the number of addresses that can be assigned is about 30, less if lengthy options such as long domain search lists are used. So, what do you do downstream? Because the draft recommends that addresses be provided to hosts "when they connect to the network", what is a host supposed to do if it gets 20 IA_NA and the user starts a VM? How many should it provide to that VM? 10? What if the user starts two more VMs, does the third one start IPv4-only? At what point is the host - which to its VMs acts as the "network" be forced to violate the spirit of this draft because it simply didn't get enough space from the upstream to provide enough addresses to the VMs? This is a very important consideration, but it does not really belong here because host behaviour is out of scope for this draft. I think that the current text recommending DHCPv6 PD is a reasonable compromise. As the draft says, /64 has none of these problems because it provides 17 orders of magnitude more space. Cheers, Lorenzo --001a114e5eb66cd8f605292fc456 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jan 13, 2016 at 12:47 AM, David Farmer <farmer@umn.edu> wro= te:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0"[WRT to the set of multiple address solutions] Outside of
SLAAC there is currently little experience with either DHCPv6 multiple
IA_NA or IA_PD in host OSes.=C2=A0 Nevertheless, these are the only
currently standardized solutions theoretically capable of fulfilling
the requirements [ref =3D Section 7]."
[...]
=C2=A0
 I agree with both points!

And, not so clearly and concisely I think it says that already.=C2=A0 So ye= s, I support that language or something very much like it.
=

Ok, then. How about putting this at the end of section = 6:

=C2=A0 =C2=A0It should be noted that while= providing multiple addresses via SLAAC is
=C2=A0 =C2=A0well unde= rstood, there is currently limited experience in host operating
= =C2=A0 =C2=A0systems with DHCPv6 PD, and little or no experience providing = multiple
=C2=A0 =C2=A0addresses via multiple IA_NA options or mul= tiple DUIDs per host. However,
=C2=A0 =C2=A0these are the only=C2= =A0currently standardized=C2=A0options that can provide multiple
= =C2=A0 =C2=A0addresses on networks that do not use SLAAC.
<= br>
And leaving the current recommendations section as is, like s= o?

=C2=A0 =C2=A0[...] If the network requires expl= icit requests
=C2=A0 =C2=A0for address space (e.g., if it require= s DHCPv6 to connect), it is
=C2=A0 =C2=A0RECOMMENDED that the net= work assign a /64 prefix to every host (e.g.,
=C2=A0 =C2=A0via DH= CPv6 PD).=C2=A0 Using DHCPv6 IA_NA or IA_TA to request a sufficient
=C2=A0 =C2=A0number of addresses (e.g. 32) would accommodate current cli= ents but
=C2=A0 =C2=A0sets a limit on the number of addresses ava= ilable to hosts when they
=C2=A0 =C2=A0attach and would limit the= development of future applications.
=C2=A0 =C2=A0Assigning prefi= xes longer than a /64 will limit [...]
=C2=A0
Additionally, I think DHCPv6 with multiple IA_NA is a viable solution to= the issue and if the authors do not, they need to more clearly explain why= not.=C2=A0 Personally, I'm OK with recommending DHCPv6 IA_PD over mult= iple IA_NA, I think there are definite advantages to DHCPv6 IA_PD. However,= without a stronger explanation why DHCPv6 with multiple IA_NA is not a via= ble solution, it should not be implied that multiple IA_NA is not a viable = solution.=C2=A0 I think it needs to be more clearly stated that DHCPv6 with= multiple IA_NA is a viable solution, even if it is not the recommended sol= ution.=C2=A0 Further, I think it should be clearly stated that DHCPv6 with = a single IA_NA does not meet the requirements of the draft.

It seems to me that the text already addresses the poi= nts you raise. It does not say or imply that multiple IA_NA is not viable, = it just recommends IA_PD over IA_NA for the reason that it is more future-p= roof and more extensible. Also, I think it is already pretty clear that a s= ingle IA_NA does not meet the requirements, because the text says "it = is RECOMMENDED that IPv6 network deployments provide multiple IPv6 addresse= s [...]", and "multiple" obviously cannot mean one.

As for multiple IA_NA, yes - it is much more limited. With= out using fragmentation (and it seems like a pretty bad idea to rely on fra= gmentation for DHCPv6 packets), the practical limit to the number of addres= ses that can be assigned is about 30, less if lengthy options such as long = domain search lists are used. So, what do you do downstream? Because the dr= aft recommends that addresses be provided to hosts "when they connect = to the network", what is a host supposed to do if it gets 20 IA_NA and= the user starts a VM? How many should it provide to that VM? 10? What if t= he user starts two more VMs, does the third one start IPv4-only? At what po= int is the host - which to its VMs acts as the "network" be force= d to violate the spirit of this draft because it simply didn't get enou= gh space from the upstream to provide enough addresses to the VMs?

This is a very important consideration, but it does not re= ally belong here because host behaviour is out of scope for this draft. I t= hink that the current text recommending DHCPv6 PD is a reasonable compromis= e. As the draft says, /64 has none of these problems because it provides 17= orders of magnitude more space.

Cheers,
Lorenzo
--001a114e5eb66cd8f605292fc456-- From nobody Tue Jan 12 23:22:55 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2E91A903C for ; Tue, 12 Jan 2016 23:22:54 -0800 (PST) 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 pmvGTDDQt2pv for ; Tue, 12 Jan 2016 23:22:52 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D1F61A00A5 for ; Tue, 12 Jan 2016 23:22:51 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 5C65560A99 for ; Wed, 13 Jan 2016 08:22:48 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 1C81C600F9 for ; Wed, 13 Jan 2016 08:22:48 +0100 (CET) Received: (qmail 86353 invoked by uid 1007); 13 Jan 2016 08:22:48 +0100 Date: Wed, 13 Jan 2016 08:22:48 +0100 From: Gert Doering To: Lorenzo Colitti Message-ID: <20160113072248.GF58491@Space.Net> References: <568D1854.7000300@gmail.com> <568FAA3B.3050108@gmail.com> <5690A640.1020009@isi.edu> <5695202F.5010206@umn.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 07:22:54 -0000 Hi, On Wed, Jan 13, 2016 at 01:39:58PM +0900, Lorenzo Colitti wrote: > Because the draft > recommends that addresses be provided to hosts "when they connect to the > network", what is a host supposed to do if it gets 20 IA_NA and the user > starts a VM? How many should it provide to that VM? 10? What if the user > starts two more VMs, does the third one start IPv4-only? At what point is > the host - which to its VMs acts as the "network" be forced to violate the > spirit of this draft because it simply didn't get enough space from the > upstream to provide enough addresses to the VMs? I actually think that this is a tremendously silly recommendation, for the reasons that you describe. Leaving out the DHCP discussion for the moment, even with SLAAC "grabbing all the addresses that this host might *potentially* need at network connection time" is madness - how many to grab? 10, 100, 1000, with associated DAD? > This is a very important consideration, but it does not really belong here > because host behaviour is out of scope for this draft. I think that the > current text recommending DHCPv6 PD is a reasonable compromise. As the > draft says, /64 has none of these problems because it provides 17 orders of > magnitude more space. Except that it totally ignores the recursive behaviour of the VM example - what if there is a VM inside the VM? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Tue Jan 12 23:29:56 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D72C1A0045 for ; Tue, 12 Jan 2016 23:29:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 yYa_GmmSyCxR for ; Tue, 12 Jan 2016 23:29:53 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F8ED1A0035 for ; Tue, 12 Jan 2016 23:29:53 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 9551260934 for ; Wed, 13 Jan 2016 08:29:51 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 4AA2F600F8 for ; Wed, 13 Jan 2016 08:29:51 +0100 (CET) Received: (qmail 86729 invoked by uid 1007); 13 Jan 2016 08:29:51 +0100 Date: Wed, 13 Jan 2016 08:29:51 +0100 From: Gert Doering To: Erik Kline Message-ID: <20160113072951.GG58491@Space.Net> References: <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <568D1854.7000300@gmail.com> <568FAA3B.3050108@gmail.com> <5690A640.1020009@isi.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+DdorAa6Vvp/ZpQm" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "v6ops@ietf.org WG" , Philip Homburg Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 07:29:55 -0000 --+DdorAa6Vvp/ZpQm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Jan 12, 2016 at 11:53:04PM +0900, Erik Kline wrote: > > (Fred: though I agree this is afield from the original thread, I find it > > hard to understand how a coherent discussion about host addressing can > > occur given the confusion about what a host is on this list) >=20 > Somewhat similarly, I find it hard to understand where things stand > with this document at this moment. >=20 > Let me propose two things: >=20 > [1] Is it important that we, as IPv6 folk, can make a Best > Practices statement about ensuring that the bounty of IPv6 addresses > be shared far and wide, avoiding incentives for NAT66. As such, I > favour some document with BCP status. >=20 > [2] Perhaps we can resolve people's concerns with the "C" in BCP > by simply adding a few statements to the effect of: >=20 > "[WRT to the set of multiple address solutions] Outside of > SLAAC there is currently little experience with either DHCPv6 multiple > IA_NA or IA_PD in host OSes. Nevertheless, these are the only > currently standardized solutions theoretically capable of fulfilling > the requirements [ref =3D Section 7]." >=20 > ...or something worded more intelligently by someone not minutes from sle= ep. >=20 > Would this work? This is something I can happily live with and agree to. I will continue to object to anything that claims it's a BCP to RECOMMEND deployment of DHCPv6-PD to hosts, without at least explaining what the host is supposed to do with it. If you want a DHCPv6-PD-to-hosts-document, please write one, that explains how this is supposed to work on both sides of the equation - with all the examples that clearly explains to a network administrator why they want to add the additional complexity to their network (assign a sufficiently-large IPv6 subnet pool, monitor it, figure out how to solve first-hop security with their vendor's gear, etc.), and how to make positive use of it, not only pay the price. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --+DdorAa6Vvp/ZpQm Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVpX8799WwGXkzn/FAQKgSRAApydaFefeOHLdt0/T4OFJZZNObJiwJ1cW GERPtCL0OLP1pmqFtBbpf4hl4590dkJAewzfhl7QK4cC9ElLOADdqx9WMjTQUdnq jEpR6iOsJUblqn+yKAIF4VMGsjTZFTq1c2baPQa/L6snINd20Ow0LQDvMMeJjEVc YbHhK27xt3BV97NbkTCFx4Dqi48oVcG0leFMSjOXdqfXqLdC4zgHLepHzozUqT4q R8E3yWIMdwrQ9+Z+FJxtmTFKh93lvRf1g/04CzBlphgjjDnA3ACpDf2x21kC+2Po 5pzQ/3ReI1l1NuWipfhsRsKqcfxcQkF2EF2MG8jUhZuHf7Vw8fUXpSIdSgMc8fg6 SoCXtirwYOt8blxf7s/gw6HLZD9KFcVL5JPD+A3e7roObOLM3LKctvpU5g9biE+8 FfA4T7tuJm8rx87bl54ozQOmuPTIa1dyMEZBxsC2JU/90+tyPZ7ZH/desuSE+PIq w2phADIEgZgcCc/7a/DcxChs7KrBGrkgf3aYWS85ET4gv8lvi6gfdPS8BL9IrHkl 1/FmbihYHacC6SlhDLA3fvCkYiqHUMbe4UNsYhnEP9VdJeSG8Jf0g0xdsKiprL9h /EImxK0jrleuwkKprRw5zDX3omdzrGiIAfFyXbV76BqD97ejswLptQRCWG7wZBXl NEsn2Va7CWo= =qXlz -----END PGP SIGNATURE----- --+DdorAa6Vvp/ZpQm-- From nobody Tue Jan 12 23:42:24 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86B31A92AD for ; Tue, 12 Jan 2016 23:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 3tAmCs_8Fkmv for ; Tue, 12 Jan 2016 23:42:21 -0800 (PST) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41BC31A9250 for ; Tue, 12 Jan 2016 23:42:21 -0800 (PST) Received: by mail-yk0-x22e.google.com with SMTP id k129so457164131yke.0 for ; Tue, 12 Jan 2016 23:42:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=R70VzNa3t6KgbcJPicB6NTNFdpm4EpCuQdRmWAtGLGo=; b=C4U0dWicmJ+dO+yPbi3c40VdHnPZRB5ZXfh8udqSnawioIVmnynkcNuUNVJb3fV8Jm 5LFZegjPuiLFAT76z6H3lOhz59NAKy96tRLcwzXq6msEra3Gg68ujoz9FU0yY4ERQyvL OnZyh1Ft8l2SzY/17lY36rhpH4EjHSCRu7b8fOlIFQ4plH4sXHarv3Uo+lOHX5HnR+Nf u+FfpoaKmoYYfh56QNoyI8JLSFD2tnD3O5Q9H0BxWGmSFdeaTgulTyxb2+WGJblcEZXp kK6ku0mWHMYc9S64hTDmXsq4sjMMEynUrF6Vp/T85LCvOnOXbZvbwwEe0Dk1uuAQDVg0 iycg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=R70VzNa3t6KgbcJPicB6NTNFdpm4EpCuQdRmWAtGLGo=; b=Da9/98xdxQZbYTXsbKxtd3UN0gJFpdC/UN8WReYW4eIrjgMOFC4VCrlYeslTeU8G+d GzagqdTh6CSc88ukiMeALUqJH4O0jsTtTT9hWMpK8505peh1mHxpyRZD0I0nVx9TLFQO 2IiaK7gEOrCJ/mcr8MKwxuDyo/cTurpoKWr16YVNBRFcFADjaWnkrNoMwLIIN0Ep5aWL AAPXQB76HpEpy9rcFIaTJeigsTml+QpVrFdsXHrzcvc9MsY+e5R0lpyaMZgGQFSF7Xsm xObjQAKg3UZODD1NzMAGgECQ+gnJ0tBfLQLZ6rX0r8pC3KYnpqsfX1oVtl2HeYjYsbKX K4ng== X-Gm-Message-State: ALoCoQkMlTFn7RrioYco2a5nhRLvSVC4usIxJQC3t1TxVVWcPFQuUMo3C5GF0MXHuE31zpCk7oHvsdP1Ld1HLHqrcODRYGbK9ROpjWpRPhR0IG5iTYRgRBs= X-Received: by 10.129.41.17 with SMTP id p17mr98576031ywp.160.1452670940449; Tue, 12 Jan 2016 23:42:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.208.201 with HTTP; Tue, 12 Jan 2016 23:42:00 -0800 (PST) In-Reply-To: <20160113072248.GF58491@Space.Net> References: <568D1854.7000300@gmail.com> <568FAA3B.3050108@gmail.com> <5690A640.1020009@isi.edu> <5695202F.5010206@umn.edu> <20160113072248.GF58491@Space.Net> From: Lorenzo Colitti Date: Wed, 13 Jan 2016 16:42:00 +0900 Message-ID: To: Gert Doering Content-Type: multipart/alternative; boundary=001a11407ee8621e160529324f23 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 07:42:23 -0000 --001a11407ee8621e160529324f23 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 13, 2016 at 4:22 PM, Gert Doering wrote: > > Because the draft > > recommends that addresses be provided to hosts "when they connect to the > > network", what is a host supposed to do if it gets 20 IA_NA and the user > > starts a VM? How many should it provide to that VM? 10? What if the user > > starts two more VMs, does the third one start IPv4-only? At what point is > > the host - which to its VMs acts as the "network" be forced to violate > the > > spirit of this draft because it simply didn't get enough space from the > > upstream to provide enough addresses to the VMs? > > I actually think that this is a tremendously silly recommendation, for the > reasons that you describe. Leaving out the DHCP discussion for the moment, > even with SLAAC "grabbing all the addresses that this host might > *potentially* need at network connection time" is madness - how many to > grab? 10, 100, 1000, with associated DAD? > The recommendation is that the network provide them, not that the host do something with them. SLAAC provides a /64 prefix with A=1, which allows the host to form an unspecified number of addresses at any time in the future. The question of a host forming unreasonable number of addresses is discussed in section 9.3. > This is a very important consideration, but it does not really belong here > > because host behaviour is out of scope for this draft. I think that the > > current text recommending DHCPv6 PD is a reasonable compromise. As the > > draft says, /64 has none of these problems because it provides 17 orders > of > > magnitude more space. > > Except that it totally ignores the recursive behaviour of the VM example - > what if there is a VM inside the VM? Possible ways the host can choose to make that space available to downstream hosts are provided in the DHCPv6 PD bullet in section 6. As explained in section 1, exact behaviour is out of scope. --001a11407ee8621e160529324f23 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jan 13, 2016 at 4:22 PM, Gert Doering <gert@space.net> wrot= e:
> Because the draft
> recommends that addresses be provided to hosts "when they connect= to the
> network", what is a host supposed to do if it gets 20 IA_NA and t= he user
> starts a VM? How many should it provide to that VM? 10? What if the us= er
> starts two more VMs, does the third one start IPv4-only? At what point= is
> the host - which to its VMs acts as the "network" be forced = to violate the
> spirit of this draft because it simply didn't get enough space fro= m the
> upstream to provide enough addresses to the VMs?

I actually think that this is a tremendously silly recommendation, f= or the
reasons that you describe.=C2=A0 Leaving out the DHCP discussion for the mo= ment,
even with SLAAC "grabbing all the addresses that this host might
*potentially* need at network connection time" is madness - how many t= o
grab?=C2=A0 10, 100, 1000, with associated DAD?

The recommendation is that the network provide them, not that the = host do something with them. SLAAC provides a /64 prefix with A=3D1, which = allows the host to form an unspecified number of addresses at any time in t= he future.

The question of a host forming= unreasonable number of addresses is discussed in section 9.3.
<= div>
> This is a very importa= nt consideration, but it does not really belong here
> because host behaviour is out of scope for this draft. I think that th= e
> current text recommending DHCPv6 PD is a reasonable compromise. As the=
> draft says, /64 has none of these problems because it provides 17 orde= rs of
> magnitude more space.

Except that it totally ignores the recursive behaviour of the VM exa= mple -
what if there is a VM inside the VM?

Possib= le ways the host can choose to make that space available to downstream host= s are provided in the DHCPv6 PD bullet in section 6. As explained in sectio= n 1, exact behaviour is out of scope.
--001a11407ee8621e160529324f23-- From nobody Tue Jan 12 23:45:46 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A17B1A92B6 for ; Tue, 12 Jan 2016 23:45:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, 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 8XXee6YUIXPD for ; Tue, 12 Jan 2016 23:45:43 -0800 (PST) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5906A1A92AF for ; Tue, 12 Jan 2016 23:45:43 -0800 (PST) Received: by mail-io0-x235.google.com with SMTP id 77so378832440ioc.2 for ; Tue, 12 Jan 2016 23:45:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=VIDNDh8fTj5TwgW3NALBFQqfArYcjHp9ieJy+DMZL8k=; b=KMP9PrfF0SqXUd4AlvfLTpwV7iITIKiDbPPKvWeoBVeRepkBPH3kqd00wck/e33EfZ pSZv1kgD6ypDU//eiI4b2p1W91G+tEcxrZs+1QY4dXj1LSA3ACD2TnLpYEoWY7omCLTG y02NjVrneOs6so+m5xlILP43nOXTyEO9a1QUxfSnaCZDPTbCeQPrWo/QWEJPkCTZEP+2 6t5+syCYYh0GsI1zUKEv0c7+fSciEhtrouMxhhk1c283Ny2PHV1GZJTzltDmSThVq7F9 7w0TdNbcGvHgOoHxGeqQdafynZE28qA4FZPKkdZvrC1FJud6wUE+iQ0EWeJaa/1WGCCN WuyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=VIDNDh8fTj5TwgW3NALBFQqfArYcjHp9ieJy+DMZL8k=; b=McE0htB9gbCClsCCa00Etw4K76yVvbFiZvZymyxzNuW6IlSwQgcG92MWeo6s+R304H TNvU2jtG4zipQWHvkTC+5SzYsTkrCaOUD0ThkenN0yUH8o8CW9mU8ppwFHdAfYTUHZJ8 jATRbCdXE7VUbJv+jcN334CVnyoKqNvmcNMTYxNM73QvPMEEQv3sOU/xlHSG7rQkLoio 40r3tdaOPkOj8b33uDWrMc5JV3nRgNuDtIFaYFKjXQZVkKwWB/18YFoGrx2PCyUtjVO7 RSLauSuLMWg0GxevD9JfIxNNddUlE9Stf1urYn2BpTuNkm1x0tDpbpgSmD6XVmfto8wn 22ZA== X-Gm-Message-State: ALoCoQkzuz4QeRzD59fmIGZttB1zfCeQeiFq0BH+shf+JoBRmVnV+t/DTjMvSQN+SfsB89ZOgvPlsB/LQKrwSbgeSKuWdb9JNXn1VFXSHyQ3u9nTsByx6IU= X-Received: by 10.107.133.12 with SMTP id h12mr109499379iod.79.1452671142460; Tue, 12 Jan 2016 23:45:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.31.36 with HTTP; Tue, 12 Jan 2016 23:45:22 -0800 (PST) In-Reply-To: <20160113072951.GG58491@Space.Net> References: <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <568D1854.7000300@gmail.com> <568FAA3B.3050108@gmail.com> <5690A640.1020009@isi.edu> <20160113072951.GG58491@Space.Net> From: Erik Kline Date: Wed, 13 Jan 2016 16:45:22 +0900 Message-ID: To: Gert Doering Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org WG" , Philip Homburg Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 07:45:44 -0000 On 13 January 2016 at 16:29, Gert Doering wrote: > Hi, > > On Tue, Jan 12, 2016 at 11:53:04PM +0900, Erik Kline wrote: >> > (Fred: though I agree this is afield from the original thread, I find it >> > hard to understand how a coherent discussion about host addressing can >> > occur given the confusion about what a host is on this list) >> >> Somewhat similarly, I find it hard to understand where things stand >> with this document at this moment. >> >> Let me propose two things: >> >> [1] Is it important that we, as IPv6 folk, can make a Best >> Practices statement about ensuring that the bounty of IPv6 addresses >> be shared far and wide, avoiding incentives for NAT66. As such, I >> favour some document with BCP status. >> >> [2] Perhaps we can resolve people's concerns with the "C" in BCP >> by simply adding a few statements to the effect of: >> >> "[WRT to the set of multiple address solutions] Outside of >> SLAAC there is currently little experience with either DHCPv6 multiple >> IA_NA or IA_PD in host OSes. Nevertheless, these are the only >> currently standardized solutions theoretically capable of fulfilling >> the requirements [ref = Section 7]." >> >> ...or something worded more intelligently by someone not minutes from sleep. >> >> Would this work? > > This is something I can happily live with and agree to. > > I will continue to object to anything that claims it's a BCP to RECOMMEND > deployment of DHCPv6-PD to hosts, without at least explaining what the > host is supposed to do with it. > > If you want a DHCPv6-PD-to-hosts-document, please write one, that explains > how this is supposed to work on both sides of the equation - with all the > examples that clearly explains to a network administrator why they want to > add the additional complexity to their network (assign a sufficiently-large > IPv6 subnet pool, monitor it, figure out how to solve first-hop security > with their vendor's gear, etc.), and how to make positive use of it, not > only pay the price. Nothing in Section 8 ("Recommendations") recommends DHCPv6-PD. At best it says at one point "e.g., via DHCPv6 PD" and certainly never elevates PD above any other solution. At the risk of sounding like a Scarfolk Council poster (http://scarfolk.blogspot.jp/), "for more information please reread". From nobody Tue Jan 12 23:57:02 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 345A11A92E0 for ; Tue, 12 Jan 2016 23:57:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 LvxyyHOA_off for ; Tue, 12 Jan 2016 23:56:59 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BC0C1A92E2 for ; Tue, 12 Jan 2016 23:56:58 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 6637A60AC7 for ; Wed, 13 Jan 2016 08:56:56 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 1B0B06010F for ; Wed, 13 Jan 2016 08:56:56 +0100 (CET) Received: (qmail 88139 invoked by uid 1007); 13 Jan 2016 08:56:56 +0100 Date: Wed, 13 Jan 2016 08:56:56 +0100 From: Gert Doering To: Erik Kline Message-ID: <20160113075656.GI58491@Space.Net> References: <568D1854.7000300@gmail.com> <568FAA3B.3050108@gmail.com> <5690A640.1020009@isi.edu> <20160113072951.GG58491@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VlzON83CwBK3K2mt" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "v6ops@ietf.org WG" , Philip Homburg Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 07:57:01 -0000 --VlzON83CwBK3K2mt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Jan 13, 2016 at 04:45:22PM +0900, Erik Kline wrote: > Nothing in Section 8 ("Recommendations") recommends DHCPv6-PD. At > best it says at one point "e.g., via DHCPv6 PD" and certainly never > elevates PD above any other solution. "it is RECOMMENDED that the network assign a /64 prefix to every host (e.g., via DHCPv6 PD)." since there is no other mechanism that could do this, argueing that this would *not* be recommending DHCPv6-PD is a bit weird. But if this is not about recommending DHCPv6-PD, and it's just an example, I would be happy to see that "(e.g. via DHCPv6 PD)" clause go away, and also remove all references to "DHCPv6 PD" in 9.3 - keeping the=20 discussion about the routing model as alternative to burdening the ND layer is fine, but if you don't want to recommend DHCPv6 PD, then don't=20 mention it as a particular technology. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --VlzON83CwBK3K2mt Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVpYDR99WwGXkzn/FAQIOxhAArI8a+Cz6j+yGtVoK6oJaV5Wn8i67XTWc s2E4hIuYur4FBsddRBrgXr9+tTKaFx8vDrSwm0IS/Z9DBaMwvggLHb4rMzEThfRa flV6kla/fhS0iVu6HqNCHRc2c83ukJxCEsPY1u8HsbcBtrPuIMaIXVkmwDMsMTbJ E2V/+DmicL/pSTCfdUx+VhqGo5Z6t5kAQ8fxD6mdcL/GTqYqApBVHZqzffS98qGL I76GwfZHTS5B9St0SZvFNCUOAQhvebBmZMT6EkR86IL8X9CTw8F1zVvE4IRf8xiV sVfwpBaY3wio4ROTM9Boy5P/eLt3fH1LW5mulbFzSA+6+Kelg4jqn03R3+hEZeH8 FSBcQNK9xp+dPTZbC4JW1iJhA85Kif7U4tkmto3JI3ElKnQfsSWczqt3kzBINigp ++2pGQQwEtibdZRMFX+7y0LEbtK5Qj732ogVfoTTeqv11g6pvdCT/yHeOK5ny0j/ HrtwFfj0uTDhgSpLWkR6ygbkerLivWMiKrUXv082OJP+9zlqBB1iBWL4RiiSiQZU 8a2Jqz1WzI1H9nWUpipZQpWuNkldMHLWF3PoY8Svt5Q6daV7NYPAnSSuvMiO/EaF RYdtwQr3nOvRDoLXBFRmbwt2nftEoBU6gtwBpnjQrnRMdHXPwzv5cEIUNmB+/Hgw X+4oYZ8rT8Q= =cwLv -----END PGP SIGNATURE----- --VlzON83CwBK3K2mt-- From nobody Wed Jan 13 00:29:22 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFA411AC3D8 for ; Wed, 13 Jan 2016 00:29:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, 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 8cTt0gfyMpM2 for ; Wed, 13 Jan 2016 00:29:15 -0800 (PST) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCDE61AC3D3 for ; Wed, 13 Jan 2016 00:29:14 -0800 (PST) Received: by mail-ig0-x232.google.com with SMTP id z14so162872807igp.0 for ; Wed, 13 Jan 2016 00:29:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Ew1O6ZmLtTdAkIc72MpgZORwygu3SHamM/3Y3LDlSns=; b=DlMctcR01upCrt4cnGOOSZa7f6+OdThnJK+VvIrBqP3hceNxHgPVvH5RhlIAQU6/5Z amZm9Wn0AuAVO+wdSAwmI2zOq5ufObGt4rNxqMhfBbp136HoHiMMpagxU+zJaJFM61Nl hTKvh815yR1ZpEnnhWrPn7eM4gxt096XnJypgMJaygo3ueFAqIlV2yhhb4vPJzfOQxug sHJxxTe/JfwyxF77h9lzO7kV2iKSGh8/SZ4zCSBiWrLxmaESRCdfCXoNUfR0Y9y1+mz/ dAc5fG94KxbW9cjpFFBxvdOegdbp+omE70lQSnXd2vF9nOX9EOQwYviSM01lv4ofEBe4 cOmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Ew1O6ZmLtTdAkIc72MpgZORwygu3SHamM/3Y3LDlSns=; b=lKdp4UDyLttjlX5H/EL/qeRl2EZxSmjZov5gmB/jq+F55VrXCTtyx3yzPu8moplztv eXwYdcaQKa5XNObWTgg21R4fn4yr4u5nTbxAXTaLK68ZDKrKegG/iMkbSmUAsI504Edv I2dwXXw4HgM3kGkpiGu1Pe93vxr+SKDPF/BFq7aFQ30HHM2D6j+W63T0PPgIscIlin84 dzPtZzpV6cQ7zgpnYIdKQThrZxPdHr0S60dTmovJAL19ahOoWSr5zNzNvGG5LMclMKMy idN6P2umgA4eaJ52bnHE+iyh1p0D44rCBP5x4tn3qlrs2D9I7zLbmpjIhHSKpYrcdDpt UvDg== X-Gm-Message-State: ALoCoQmGY/wsVOt1o1xEDW+Cca4ThN1hWijNUovsGxGJ36CAbEZXljizREjcIrIODwpP4znv4sH04t6k5Z2kEROEbuKF2TagcorzRMQ+3tUzuUPmkcNBmBQ= X-Received: by 10.50.150.66 with SMTP id ug2mr20963911igb.33.1452673754174; Wed, 13 Jan 2016 00:29:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.31.36 with HTTP; Wed, 13 Jan 2016 00:28:54 -0800 (PST) In-Reply-To: <20160113075656.GI58491@Space.Net> References: <568D1854.7000300@gmail.com> <568FAA3B.3050108@gmail.com> <5690A640.1020009@isi.edu> <20160113072951.GG58491@Space.Net> <20160113075656.GI58491@Space.Net> From: Erik Kline Date: Wed, 13 Jan 2016 17:28:54 +0900 Message-ID: To: Gert Doering Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 08:29:16 -0000 On 13 January 2016 at 16:56, Gert Doering wrote: > Hi, > > On Wed, Jan 13, 2016 at 04:45:22PM +0900, Erik Kline wrote: >> Nothing in Section 8 ("Recommendations") recommends DHCPv6-PD. At >> best it says at one point "e.g., via DHCPv6 PD" and certainly never >> elevates PD above any other solution. > > "it is RECOMMENDED that the network assign a /64 prefix to every host (e.g., > via DHCPv6 PD)." > > since there is no other mechanism that could do this, argueing that this > would *not* be recommending DHCPv6-PD is a bit weird. > > But if this is not about recommending DHCPv6-PD, and it's just an example, > I would be happy to see that "(e.g. via DHCPv6 PD)" clause go away, > and also remove all references to "DHCPv6 PD" in 9.3 - keeping the > discussion about the routing model as alternative to burdening the ND > layer is fine, but if you don't want to recommend DHCPv6 PD, then don't > mention it as a particular technology. I think we need to keep text about the universe of currently available solutions. All of those listed are workable. It should be easy for us as a group to recommend that network operators choose (at least) one solution out of the currently available universe of solutions. That's the meat of what's being said here, with a side salad of motivation and considerations[*]. I continue to not see a controversy here. -ek [*] apologies to vegetarians From nobody Wed Jan 13 01:01:34 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A461A1B4B for ; Wed, 13 Jan 2016 01:01:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsZWea1anDeU for ; Wed, 13 Jan 2016 01:01:30 -0800 (PST) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48A011AC42C for ; Wed, 13 Jan 2016 01:01:30 -0800 (PST) Received: by mail-vk0-x235.google.com with SMTP id i129so119574828vkb.0 for ; Wed, 13 Jan 2016 01:01:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pdNYkQPUFT+5FAcafIUqxRWXg7AXARWIaYH/nQH16YE=; b=YVGImbEKYH9eZGAs42PIKYZPItW4WANFTeo+fHINMNfTm6pLb29litWabC+VyOyZ+f kWv3gvy2mrca795Gg9u7ciSqcJ9oFaC0K5AwVri3XgReqO/3lM0qhX2dm2lIUOh4KpAC CnQpFZaRFwEfYRdwWIyk3k0u8mBgnvs5AXacU2dmCfuUH7vdrqp6aKzYhBqZ8rrVOZvZ 9jEf3Mtxw/UZSF9PrxHjVVZGuhOTIOTZrTe94frUpfRY6LkA2vYxsP+tcSWXr5c19qT7 jiDbN+AqC0qbRq8Dx1rXR3hDwOmK1bHnLwaJ8ZPY94J0nFwFPlXnNYH8GBFbiwwiSwyM yi4Q== MIME-Version: 1.0 X-Received: by 10.31.15.4 with SMTP id 4mr86379633vkp.10.1452675689362; Wed, 13 Jan 2016 01:01:29 -0800 (PST) Received: by 10.103.99.1 with HTTP; Wed, 13 Jan 2016 01:01:28 -0800 (PST) Received: by 10.103.99.1 with HTTP; Wed, 13 Jan 2016 01:01:28 -0800 (PST) In-Reply-To: <20160113072951.GG58491@Space.Net> References: <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <568D1854.7000300@gmail.com> <568FAA3B.3050108@gmail.com> <5690A640.1020009@isi.edu> <20160113072951.GG58491@Space.Net> Date: Wed, 13 Jan 2016 20:01:28 +1100 Message-ID: From: Mark Smith To: Gert Doering Content-Type: multipart/alternative; boundary=001a11433da870461a0529336a80 Archived-At: Cc: "v6ops@ietf.org WG" , Philip Homburg Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 09:01:32 -0000 --001a11433da870461a0529336a80 Content-Type: text/plain; charset=UTF-8 On 13 Jan 2016 18:30, "Gert Doering" wrote: > > Hi, > > On Tue, Jan 12, 2016 at 11:53:04PM +0900, Erik Kline wrote: > > > (Fred: though I agree this is afield from the original thread, I find it > > > hard to understand how a coherent discussion about host addressing can > > > occur given the confusion about what a host is on this list) > > > > Somewhat similarly, I find it hard to understand where things stand > > with this document at this moment. > > > > Let me propose two things: > > > > [1] Is it important that we, as IPv6 folk, can make a Best > > Practices statement about ensuring that the bounty of IPv6 addresses > > be shared far and wide, avoiding incentives for NAT66. As such, I > > favour some document with BCP status. > > > > [2] Perhaps we can resolve people's concerns with the "C" in BCP > > by simply adding a few statements to the effect of: > > > > "[WRT to the set of multiple address solutions] Outside of > > SLAAC there is currently little experience with either DHCPv6 multiple > > IA_NA or IA_PD in host OSes. Nevertheless, these are the only > > currently standardized solutions theoretically capable of fulfilling > > the requirements [ref = Section 7]." > > > > ...or something worded more intelligently by someone not minutes from sleep. > > > > Would this work? > > This is something I can happily live with and agree to. > > I will continue to object to anything that claims it's a BCP to RECOMMEND > deployment of DHCPv6-PD to hosts, without at least explaining what the > host is supposed to do with it. > > If you want a DHCPv6-PD-to-hosts-document, please write one, "Delegating a Prefix to a Host for Multi-addressing Purposes" https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/ that explains > how this is supposed to work on both sides of the equation - with all the > examples that clearly explains to a network administrator why they want to > add the additional complexity to their network (assign a sufficiently-large > IPv6 subnet pool, monitor it, figure out how to solve first-hop security > with their vendor's gear, etc.), and how to make positive use of it, not > only pay the price. > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a11433da870461a0529336a80 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 13 Jan 2016 18:30, "Gert Doering" <gert@space.net> wrote:
>
> Hi,
>
> On Tue, Jan 12, 2016 at 11:53:04PM +0900, Erik Kline wrote:
> > > (Fred: though I agree this is afield from the original threa= d, I find it
> > > hard to understand how a coherent discussion about host addr= essing can
> > > occur given the confusion about what a host is on this list)=
> >
> > Somewhat similarly, I find it hard to understand where things sta= nd
> > with this document at this moment.
> >
> > Let me propose two things:
> >
> >=C2=A0 =C2=A0 =C2=A0[1] Is it important that we, as IPv6 folk, can= make a Best
> > Practices statement about ensuring that the bounty of IPv6 addres= ses
> > be shared far and wide, avoiding incentives for NAT66.=C2=A0 As s= uch, I
> > favour some document with BCP status.
> >
> >=C2=A0 =C2=A0 =C2=A0[2] Perhaps we can resolve people's concer= ns with the "C" in BCP
> > by simply adding a few statements to the effect of:
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"[WRT to the set of multipl= e address solutions] Outside of
> > SLAAC there is currently little experience with either DHCPv6 mul= tiple
> > IA_NA or IA_PD in host OSes.=C2=A0 Nevertheless, these are the on= ly
> > currently standardized solutions theoretically capable of fulfill= ing
> > the requirements [ref =3D Section 7]."
> >
> > ...or something worded more intelligently by someone not minutes = from sleep.
> >
> > Would this work?
>
> This is something I can happily live with and agree to.
>
> I will continue to object to anything that claims it's a BCP to RE= COMMEND
> deployment of DHCPv6-PD to hosts, without at least explaining what the=
> host is supposed to do with it.
>
> If you want a DHCPv6-PD-to-hosts-document, please write one,

"Delegating a Prefix to a Host for Multi-addressing Pur= poses"
ht= tps://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/


<= /p>

that explains
> how this is supposed to work on both sides of the equation - with all = the
> examples that clearly explains to a network administrator why they wan= t to
> add the additional complexity to their network (assign a sufficiently-= large
> IPv6 subnet pool, monitor it, figure out how to solve first-hop securi= ty
> with their vendor's gear, etc.), and how to make positive use of i= t, not
> only pay the price.
>
> Gert Doering
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- NetMaster
> --
> have you enabled IPv6 on something today...?
>
> SpaceNet AG=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Vorstand: Sebastian v. Bomhard
> Joseph-Dollinger-Bogen 14=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Aufsichtsr= atsvors.: A. Grundner-Culemann
> D-80807 Muenchen=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0USt-I= dNr.: DE813185279
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops
>

--001a11433da870461a0529336a80-- From nobody Wed Jan 13 01:02:31 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 487D71ACCD9 for ; Wed, 13 Jan 2016 01:02:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bu0wD3gC8JN9 for ; Wed, 13 Jan 2016 01:02:28 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5365B1ACC8A for ; Wed, 13 Jan 2016 01:02:28 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u0D92QZD026774 for ; Wed, 13 Jan 2016 10:02:26 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BF52620199E for ; Wed, 13 Jan 2016 10:10:02 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id B76CD20118B for ; Wed, 13 Jan 2016 10:10:02 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u0D92P68021858 for ; Wed, 13 Jan 2016 10:02:25 +0100 To: v6ops@ietf.org References: <568D1854.7000300@gmail.com> <568FAA3B.3050108@gmail.com> <5690A640.1020009@isi.edu> <20160113072951.GG58491@Space.Net> <20160113075656.GI58491@Space.Net> From: Alexandre Petrescu Message-ID: <569612A1.7050603@gmail.com> Date: Wed, 13 Jan 2016 10:02:25 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160113075656.GI58491@Space.Net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 09:02:30 -0000 Le 13/01/2016 08:56, Gert Doering a écrit : > Hi, > > On Wed, Jan 13, 2016 at 04:45:22PM +0900, Erik Kline wrote: >> Nothing in Section 8 ("Recommendations") recommends DHCPv6-PD. At >> best it says at one point "e.g., via DHCPv6 PD" and certainly never >> elevates PD above any other solution. > > "it is RECOMMENDED that the network assign a /64 prefix to every host (e.g., > via DHCPv6 PD)." > > since there is no other mechanism that could do this, Right, there is no other Stds Track RFC that could do this (other than DHCP-PD), but there is Prefix Delegation extension to ND protocol - an individual Internet Draft: https://tools.ietf.org/html/draft-kaiser-nd-pd-02 Alex > argueing that this > would *not* be recommending DHCPv6-PD is a bit weird. > > But if this is not about recommending DHCPv6-PD, and it's just an example, > I would be happy to see that "(e.g. via DHCPv6 PD)" clause go away, > and also remove all references to "DHCPv6 PD" in 9.3 - keeping the > discussion about the routing model as alternative to burdening the ND > layer is fine, but if you don't want to recommend DHCPv6 PD, then don't > mention it as a particular technology. > > Gert Doering > -- NetMaster > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Jan 13 01:36:23 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36A9A1ACD54 for ; Wed, 13 Jan 2016 01:36:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U_ui5ITscYZj for ; Wed, 13 Jan 2016 01:36:20 -0800 (PST) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E5E41ACD53 for ; Wed, 13 Jan 2016 01:36:20 -0800 (PST) Received: by mail-vk0-x22f.google.com with SMTP id n1so103780660vkb.3 for ; Wed, 13 Jan 2016 01:36:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WvySrXRcpprtMNyN2IFipMatL9rpaliA153ljOn2bIA=; b=M/V2Qp+N0Q21D3LqSVTQQkN9JbftCkePIVmLBz2NWKskmlyrUFTE0aKGYVeS8dzM6u MrOlAPxmsy2nrXKnO5IVStivkvNFEixDwAXHmh4SJVsujtg/bo9SlSEXyir16Cxx1ZFN rBnjX3l2yZewS+OGIVvbwSEEsh5RZPZp0jE2KDQkZWcKHQaYZqstyTeukr+UVJ+lt1bh AUQT8dutE5pyTn+XySZ6u6fIniP7S5ldY4PvuGdxxJvxsuS9O3YEL06pG362eWDSPTmw 9f5ewZvi4EWzUVYRxEfdaAY2BPPqyJ41XJexySCY5yxwvkz9B2bhVsUYRHzDfa8+H2pq y/JQ== MIME-Version: 1.0 X-Received: by 10.31.21.210 with SMTP id 201mr96904130vkv.132.1452677779190; Wed, 13 Jan 2016 01:36:19 -0800 (PST) Received: by 10.103.99.1 with HTTP; Wed, 13 Jan 2016 01:36:18 -0800 (PST) Received: by 10.103.99.1 with HTTP; Wed, 13 Jan 2016 01:36:18 -0800 (PST) In-Reply-To: <569612A1.7050603@gmail.com> References: <568D1854.7000300@gmail.com> <568FAA3B.3050108@gmail.com> <5690A640.1020009@isi.edu> <20160113072951.GG58491@Space.Net> <20160113075656.GI58491@Space.Net> <569612A1.7050603@gmail.com> Date: Wed, 13 Jan 2016 20:36:18 +1100 Message-ID: From: Mark Smith To: Alexandre Petrescu Content-Type: multipart/alternative; boundary=001a1143b43400779f052933e704 Archived-At: Cc: v6ops list Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 09:36:22 -0000 --001a1143b43400779f052933e704 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 13 Jan 2016 20:02, "Alexandre Petrescu" wrote: > > > > Le 13/01/2016 08:56, Gert Doering a =C3=A9crit : >> >> Hi, >> >> On Wed, Jan 13, 2016 at 04:45:22PM +0900, Erik Kline wrote: >>> >>> Nothing in Section 8 ("Recommendations") recommends DHCPv6-PD. At >>> best it says at one point "e.g., via DHCPv6 PD" and certainly never >>> elevates PD above any other solution. >> >> >> "it is RECOMMENDED that the network assign a /64 prefix to every host (e.g., >> via DHCPv6 PD)." >> >> since there is no other mechanism that could do this, > > > Right, there is no other Stds Track RFC that could do this (other than DHCP-PD), but there is Prefix Delegation extension to ND protocol - an individual Internet Draft: > https://tools.ietf.org/html/draft-kaiser-nd-pd-02 There is no need for a standards track RFC, the protocol is already defined, and there is nothing in the protocol that demands that the delegated prefix MUST be used as a routed prefix on a router. RFC7084 says that the receiving CPE is to use one of the delegated /64s for its own host traffic if there is no global prefix on the WAN interface in WAA-7, so there is already an RFC describing the use of a DHCPV6-PD delegated prefix for host traffic to/from a device. (This apparent obsession with classifying protocols as "can be run on a router" or "can only run on a host" is getting tiring. How do people explain BGP looking glasses if BGP MUST be run on a device that forwards packets? How do people explain Cisco routers that accept the "no ip forwarding" command, stopping them forwarding packets, and can act as terminal servers, originating telnet sessions a host "only" protocol. They're all just computers, the only thing special about high end "routers" is that they're optimised to perform packet forwarding using hardware and do that by default.) > Alex > > >> argueing that this >> would *not* be recommending DHCPv6-PD is a bit weird. >> >> But if this is not about recommending DHCPv6-PD, and it's just an example, >> I would be happy to see that "(e.g. via DHCPv6 PD)" clause go away, >> and also remove all references to "DHCPv6 PD" in 9.3 - keeping the >> discussion about the routing model as alternative to burdening the ND >> layer is fine, but if you don't want to recommend DHCPv6 PD, then don't >> mention it as a particular technology. >> >> Gert Doering >> -- NetMaster >> >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --001a1143b43400779f052933e704 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 13 Jan 2016 20:02, "Alexandre Petrescu" <alexandre.petrescu@gmail.com> wrote: >
>
>
> Le 13/01/2016 08:56, Gert Doering a =C3=A9crit :
>>
>> Hi,
>>
>> On Wed, Jan 13, 2016 at 04:45:22PM +0900, Erik Kline wrote:
>>>
>>> Nothing in Section 8 ("Recommendations") recommends = DHCPv6-PD.=C2=A0 At
>>> best it says at one point "e.g., via DHCPv6 PD" and = certainly never
>>> elevates PD above any other solution.
>>
>>
>> "it is RECOMMENDED that the network assign a /64 prefix to ev= ery host (e.g.,
>> =C2=A0 =C2=A0 via DHCPv6 PD)."
>>
>> since there is no other mechanism that could do this,
>
>
> Right, there is no other Stds Track RFC that could do this (other than= DHCP-PD), but there is Prefix Delegation extension to ND protocol - an ind= ividual Internet Draft:
> https://= tools.ietf.org/html/draft-kaiser-nd-pd-02

There is no need for a standards track RFC, the protocol is = already defined, and there is nothing in the protocol that demands that the= delegated prefix MUST be used as a routed prefix on a router.

RFC7084 says that the receiving CPE is to use one of the del= egated /64s for its own host traffic if there is no global prefix on the WA= N interface in WAA-7, so there is already an RFC describing the use of a DH= CPV6-PD delegated prefix for host traffic to/from a device.

(This apparent obsession with classifying protocols as "= ;can be run on a router" or "can only run on a host" is gett= ing tiring. How do people explain BGP looking glasses if BGP MUST be run on= a device that forwards packets? How do people explain Cisco routers that a= ccept the "no ip forwarding" command, stopping them forwarding pa= ckets, and can act as terminal servers, originating telnet sessions a host = "only" protocol.

They're all just computers, the only thing special about= high end "routers" is that they're optimised to perform pack= et forwarding using hardware and do that by default.)

> Alex
>
>
>> argueing that this
>> would *not* be recommending DHCPv6-PD is a bit weird.
>>
>> But if this is not about recommending DHCPv6-PD, and it's just= an example,
>> I would be happy to see that "(e.g. via DHCPv6 PD)" clau= se go away,
>> and also remove all references to "DHCPv6 PD" in 9.3 - k= eeping the
>> discussion about the routing model as alternative to burdening the= ND
>> layer is fine, but if you don't want to recommend DHCPv6 PD, t= hen don't
>> mention it as a particular technology.
>>
>> Gert Doering
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- NetMaster
>>
>>
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://ww= w.ietf.org/mailman/listinfo/v6ops
>>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--001a1143b43400779f052933e704-- From nobody Wed Jan 13 01:58:51 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9AD1A0095 for ; Wed, 13 Jan 2016 01:58:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 lG6o380rYyv5 for ; Wed, 13 Jan 2016 01:58:48 -0800 (PST) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D8731A0092 for ; Wed, 13 Jan 2016 01:58:48 -0800 (PST) Received: by mail-yk0-x234.google.com with SMTP id a85so404834210ykb.1 for ; Wed, 13 Jan 2016 01:58:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=GM+rcIRQKIC1vmdaNA7YWgy6Qml49CtJv414tfxR3Jc=; b=Na0etXBP/6tNy3xV3oAiZ61baWOE6A5weJhHUwamOROc/gftseg0uVpocNVJ801aWv mmJ304T6j7vGp/4Djc+IwJuj/1kTeDIJx6wnqSwBeINbpJfpA2f9WT9HjWRzXpbTxSQ4 d4dEAttK+05XEuhSwcz/jklIlfdThYWRA9mVnBtblINzbNpy5Xw93DlbRWBBodRmhk1r X/ZZmv+sdl4j9uPv5g2y3V0iLqo0h0h8HXHTj5aQi6OoTiq4MS+/kRlGmdquCMYqLLAq IheAZ/PvEFnFFf9QTnoP0IQ9aeM9189HG5GmWW9NmDnQMCljMN+H+t8ZApPCcsPSD/ps c8zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=GM+rcIRQKIC1vmdaNA7YWgy6Qml49CtJv414tfxR3Jc=; b=DM1etc//l4gpyLMgUbTi/CsFjYnIgJAwQvFII6vE7dRf2uWJiSoWC7cRSQiEty/iSN PEn23jAOa+CpKzrG2Lj+vJ+dW/3VrxjxSoKDNfGNp4R3hOk13zUS7Iwi2ar6QYEULnyn w/JQ8lBxl77P22aOc1O/S6mF9RV85YjLHSKjK6KyTMdEz6+W/5wo2eGA3Rp2Nvi2Lbrx wlTcmU5hHT7TNBArcdySMyrBmyE5/Bl3VaYw7i0VUuKAiPQNvaqDWNSIvo+qDo+8BeNL e9pd3FL/GnfLK1iUHqp/XJSDSzh9N5tPK4IV706J3No2cHucDRAJL/b6t9AOa+XysDiX zTbA== X-Gm-Message-State: ALoCoQnUfXg5MrpXVPJ2LlK9OgIhzLWAsVUJZHGL7GbmrBlmDY63gVZ2/QMP4sFNhlB3V5H5ZUJUK/9kWgQEqCq+y139RNZd/EQK+vGIbGiGUPFCfEbWU6w= X-Received: by 10.129.41.17 with SMTP id p17mr98922642ywp.160.1452679127762; Wed, 13 Jan 2016 01:58:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.208.201 with HTTP; Wed, 13 Jan 2016 01:58:27 -0800 (PST) In-Reply-To: <20160113072951.GG58491@Space.Net> References: <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <568D1854.7000300@gmail.com> <568FAA3B.3050108@gmail.com> <5690A640.1020009@isi.edu> <20160113072951.GG58491@Space.Net> From: Lorenzo Colitti Date: Wed, 13 Jan 2016 18:58:27 +0900 Message-ID: To: Gert Doering Content-Type: multipart/alternative; boundary=001a11407ee86278df05293437d1 Archived-At: Cc: "v6ops@ietf.org WG" , Philip Homburg Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 09:58:50 -0000 --001a11407ee86278df05293437d1 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 13, 2016 at 4:29 PM, Gert Doering wrote: > I will continue to object to anything that claims it's a BCP to RECOMMEND > deployment of DHCPv6-PD to hosts, without at least explaining what the > host is supposed to do with it. > Not sure what your point is. Are you saying that a host is so different from a router that it can't reasonably implement RFC 3633? If you want a DHCPv6-PD-to-hosts-document, please write one, that explains > how this is supposed to work on both sides of the equation - with all the > examples that clearly explains to a network administrator why they want to > add the additional complexity to their network (assign a sufficiently-large > IPv6 subnet pool, monitor it, figure out how to solve first-hop security > with their vendor's gear, etc.), and how to make positive use of it, not > only pay the price. Gert, please don't mischaracterize things. This is not a DHCPv6-PD-to-hosts document. This is a document that recommends that networks assign multiple addresses to hosts. DHCPv6 PD is only one of the options. On a network that has decided to use DHCPv6 as the only address provisioning protocol, there are two alternatives: multiple IA_NA and PD. The document cites reasons why PD is more extensible and more future-proof than IA_NA and as such recommends that. Please do note that in terms of number of devices, such networks are a small minority - they are dwarfed by residential and mobile networks, which use other provisioning protocols either instead of or in addition to DHCPv6, and which assign multiple addresses to hosts as a matter of course. In any case, nobody says that anyone must follow that recommendation. As with all IETF recommendations, operators are free to ignore it as long as they weigh the implications of doing so. In your network, you're still free to disable SLAAC, use DHCPv6 only, and assign one address per device, if that's what you want. Is it? --001a11407ee86278df05293437d1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jan 13, 2016 at 4:29 PM, Gert Doering <gert@space.net> wrot= e:
I will continue to object to anything = that claims it's a BCP to RECOMMEND
deployment of DHCPv6-PD to hosts, without at least explaining what the
host is supposed to do with it.

Not sur= e what your point is. Are you saying that a host is so different from a rou= ter that it can't reasonably implement RFC 3633?

If you want a DHCPv6-PD-to-hosts-document, please write one, that explains<= br> how this is supposed to work on both sides of the equation - with all the examples that clearly explains to a network administrator why they want to<= br> add the additional complexity to their network (assign a sufficiently-large=
IPv6 subnet pool, monitor it, figure out how to solve first-hop security with their vendor's gear, etc.), and how to make positive use of it, no= t
only pay the price.

Gert, please don't = mischaracterize things. This is not a DHCPv6-PD-to-hosts document. This is = a document that recommends that networks assign multiple addresses to hosts= .

DHCPv6 PD is only one of the options. On a netwo= rk that has decided to use DHCPv6 as the only address provisioning protocol= , there are two alternatives: multiple IA_NA and PD. The document cites rea= sons why PD is more extensible and more future-proof than IA_NA and as such= recommends that. Please do note that in terms of number of devices, such n= etworks are a small minority - they are dwarfed by residential and mobile n= etworks, which use other provisioning protocols either instead of or in add= ition to DHCPv6, and which assign multiple addresses to hosts as a matter o= f course.

In any case, nobody says that anyone mus= t follow that recommendation. As with all IETF recommendations, operators a= re free to ignore it as long as they weigh the implications of doing so. In= your network, you're still free to disable SLAAC, use DHCPv6 only, and= assign one address per device, if that's what you want. Is it?
--001a11407ee86278df05293437d1-- From nobody Wed Jan 13 04:30:28 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF141ACD93 for ; Wed, 13 Jan 2016 04:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.983 X-Spam-Level: X-Spam-Status: No, score=-6.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5VN7qwhLLbG for ; Wed, 13 Jan 2016 04:30:24 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94B361A88BC for ; Wed, 13 Jan 2016 04:30:24 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u0DCUMnJ015992 for ; Wed, 13 Jan 2016 13:30:22 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 82D4B206473 for ; Wed, 13 Jan 2016 13:37:58 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 7A983200B5A for ; Wed, 13 Jan 2016 13:37:58 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u0DCULe0029320 for ; Wed, 13 Jan 2016 13:30:21 +0100 To: v6ops@ietf.org References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <568D1854.7000300@gmail.com> <568FAA3B.3050108@gmail.com> <5690A640.1020009@isi.edu> From: Alexandre Petrescu Message-ID: <5696435D.1060605@gmail.com> Date: Wed, 13 Jan 2016 13:30:21 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 12:30:26 -0000 Le 12/01/2016 16:38, Philip Homburg a écrit : > In your letter dated Tue, 12 Jan 2016 23:53:04 +0900 you wrote: >> Let me propose two things: >> >> [1] Is it important that we, as IPv6 folk, can make a Best >> Practices statement about ensuring that the bounty of IPv6 addresses >> be shared far and wide, avoiding incentives for NAT66. As such, I >> favour some document with BCP status. > > I fully agree that it would be absurd if address shortage would cause people > if deploy NAT66. > > However, why do we need a BCP now? > > By and large we don't have a problem in networks that use SLAAC. > And I'm not > aware of any developments that suggest that it will be a problem in the > near future. Of course SLAAC is sub-optimal if the device has a complex > desk area network behind it (or has a complex VM/container configuration) Not only sub-optimal - it's worse - it's hardly working at all. > We may have a problem in networks that use DHCPv6 IA_NA. But that is > exactly the configuration where we cannot give any advice based on experience. > > So why not add some DHCPv6 IA_NA (that requests multiple address) or IA_PD > support to a popular host platform, encourage a big DHCPv6 site to support > it and then publish a BCP based on that experience. I agree, it's a good step. Some 'host' platform includes 'M2M' platforms of some popular manufacturer of chips for cellular UEs. > Maybe have DHCP-only networks at IETF (or RIR) meetings to see if devices > properly support DHCPv6 or not. Good point. At the last IETF there was initiative to go towards DHCP-PD test on the IETF WiFi network - not sure where it stands now. Additionally, some cellular network operators in v6ops may be able to offer DHCP-PD to UEs. Alex > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Jan 13 04:30:38 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 740A51ACDA0 for ; Wed, 13 Jan 2016 04:30:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 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, 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 mzVb5sSVfSCY for ; Wed, 13 Jan 2016 04:30:32 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0AEF1ACD93 for ; Wed, 13 Jan 2016 04:30:31 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id A1EDAA2; Wed, 13 Jan 2016 13:30:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1452688228; bh=4q0C0eYThamLWcB9LOGQcvOQQ6H6ZaLr2bqyJgZAww0=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=jhVcD1KqsHhjlCpmXqwll3eoAlcmCLUjyhlhJjbZ8xH0muoP3VsFCHZ+jGPZeQdq5 exzZBjaenX/K4BQ3wVhYxQI/oYqNYEg6a35OVxGB7+TBFHBDQnEr2Jc22/XKnX/KBx PwdpNPSJcKvzThBvbjIyqmBXb4J5yyDMUMpp3B+Q= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 9C24FA1; Wed, 13 Jan 2016 13:30:28 +0100 (CET) Date: Wed, 13 Jan 2016 13:30:28 +0100 (CET) From: Mikael Abrahamsson To: Lorenzo Colitti In-Reply-To: Message-ID: References: <568D1854.7000300@gmail.com> <568FAA3B.3050108@gmail.com> <5690A640.1020009@isi.edu> <5695202F.5010206@umn.edu> <20160113072248.GF58491@Space.Net> 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: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 12:30:34 -0000 On Wed, 13 Jan 2016, Lorenzo Colitti wrote: > The recommendation is that the network provide them, not that the host > do something with them. SLAAC provides a /64 prefix with A=1, which > allows the host to form an unspecified number of addresses at any time > in the future. I have come to form the opinion that there should be some kind of BCP on how many IPv6 addresses the host can expect to form (that works) using A=1. There should have been some kind of option for the network to advertise the per-MAC maximum supported by the network, because I'd venture to say that the host using 1B addresses would never have worked, neither on new or old hardware. Looking at some deployments in the Wifi space, it looks like at least one vendor has chosen a default to support a max of 8 addresses per MAC, which is a value that I can understand why they came to considering a lot of different parameters (one can always discuss if it should be 8 non-LL and 1 LL, or if it should be 7 non-LL and 1 LL address, but... oh well. So while I really would like to see PD supported by hosts, I also think that giving hints to the host how much working A=1 based addresses it can form would be good as well. Anyone else think this would be a good idea? In that case I guess we'd need to communicate this to 6man. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Jan 13 04:34:16 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48A3C1ACDA1 for ; Wed, 13 Jan 2016 04:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.983 X-Spam-Level: X-Spam-Status: No, score=-6.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id St9Eu7CBkugd for ; Wed, 13 Jan 2016 04:34:13 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06C5E1ACD9A for ; Wed, 13 Jan 2016 04:34:12 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u0DCYA0X001988 for ; Wed, 13 Jan 2016 13:34:10 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D1F2420649D for ; Wed, 13 Jan 2016 13:41:47 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C97CC202F47 for ; Wed, 13 Jan 2016 13:41:47 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u0DCYAfk031809 for ; Wed, 13 Jan 2016 13:34:10 +0100 To: v6ops@ietf.org References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <568D1854.7000300@gmail.com> <568FAA3B.3050108@gmail.com> <5690A640.1020009@isi.edu> From: Alexandre Petrescu Message-ID: <56964442.4030007@gmail.com> Date: Wed, 13 Jan 2016 13:34:10 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 12:34:15 -0000 Le 12/01/2016 20:33, Mark Smith a écrit : > > On 13 Jan 2016 02:39, "Philip Homburg" > wrote: >> >> In your letter dated Tue, 12 Jan 2016 23:53:04 +0900 you wrote: >>> Let me propose two things: >>> >>> [1] Is it important that we, as IPv6 folk, can make a Best >>> Practices statement about ensuring that the bounty of IPv6 >>> addresses be shared far and wide, avoiding incentives for NAT66. >>> As such, I favour some document with BCP status. >> >> I fully agree that it would be absurd if address shortage would >> cause > people >> if deploy NAT66. >> >> However, why do we need a BCP now? >> > > I think the "now" is not so much 2016, I think it is more about being > proactive, and trying to make a strong statement that IPv4's address > conservatism mentality is not only unnecessary but also will be > limiting in an IPv6 context. > > I'm not sure what motivated the authors to start writing this, > however it feels like the right time to me for a variety of reasons - > VMs and containers, IoT and RIRs running out of IPv4 addresses ... and cellular networks to which vehicular networks connect. > are all going to be bringing the need for more addresses to the > forefronts of peoples' minds. I think the need to deploy IPv6 will > become more obvious to those people if it isn't already. Using IPv4 in vehicular networks is straighforward. Using IPv6 needs DHCPv6-PD, or otherwise NAT66 which is a real risk. Alex > To some extent this is more of a BCP on what not to do (artificially > and unnecessarily limit addresses) rather than what to do, as, as you > observe, there probably isn't much address limiting going on right > now (although I wouldn't be all that surprised if some mobile > carriers try it on given their tethering history,). > >> By and large we don't have a problem in networks that use SLAAC. >> And > I'm not >> aware of any developments that suggest that it will be a problem in >> the near future. Of course SLAAC is sub-optimal if the device has a >> complex desk area network behind it (or has a complex VM/container >> configuration) >> >> We may have a problem in networks that use DHCPv6 IA_NA. But that >> is exactly the configuration where we cannot give any advice based >> on > experience. >> >> So why not add some DHCPv6 IA_NA (that requests multiple address) >> or > IA_PD >> support to a popular host platform, encourage a big DHCPv6 site to >> > support >> it and then publish a BCP based on that experience. >> >> Maybe have DHCP-only networks at IETF (or RIR) meetings to see if >> devices properly support DHCPv6 or not. >> >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Jan 13 09:31:16 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC3221B2F9B for ; Wed, 13 Jan 2016 09:31:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hX69iw2Cihu5 for ; Wed, 13 Jan 2016 09:31:13 -0800 (PST) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C48131B2F9F for ; Wed, 13 Jan 2016 09:31:11 -0800 (PST) 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 u0DHVABR031307; Wed, 13 Jan 2016 11:31:10 -0600 Received: from XCH-PHX-209.sw.nos.boeing.com (xch-phx-209.sw.nos.boeing.com [130.247.25.29]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u0DHV80e031180 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 13 Jan 2016 11:31:08 -0600 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.52]) by XCH-PHX-209.sw.nos.boeing.com ([169.254.9.213]) with mapi id 14.03.0235.001; Wed, 13 Jan 2016 09:31:07 -0800 From: "Templin, Fred L" To: Gert Doering Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt Thread-Index: AQHRTigvrBJl7bbOOkulVVfNz2tyew== Date: Wed, 13 Jan 2016 17:31:07 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832FA6A74@XCH-BLV-504.nw.nos.boeing.com> References: <568D8C1C.2020406@umn.edu> <20160107073826.GC58491@Space.Net> <20160107075820.GE58491@Space.Net> <2134F8430051B64F815C691A62D9831832F9BCDF@XCH-BLV-504.nw.nos.boeing.com> <20160107161950.GG58491@Space.Net> <2134F8430051B64F815C691A62D9831832F9BD71@XCH-BLV-504.nw.nos.boeing.com> <20160107163242.GH58491@Space.Net> <2134F8430051B64F815C691A62D9831832F9BE32@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832F9BE32@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 17:31:15 -0000 Hi Gert, Did this answer your question (from last week)? If so, can we agree that ro= uting scaling should not be an issue for delegating lots of prefixes to lots of h= osts? Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Templin, Fred L > Sent: Thursday, January 07, 2016 8:45 AM > To: Gert Doering > Cc: v6ops@ietf.org > Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-= 04.txt >=20 > Hi Gert, >=20 > > -----Original Message----- > > From: Gert Doering [mailto:gert@Space.Net] > > Sent: Thursday, January 07, 2016 8:33 AM > > To: Templin, Fred L > > Cc: Gert Doering; Lorenzo Colitti; v6ops@ietf.org > > Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availabilit= y-04.txt > > > > Hi, > > > > On Thu, Jan 07, 2016 at 04:27:28PM +0000, Templin, Fred L wrote: > > > > On Thu, Jan 07, 2016 at 04:13:54PM +0000, Templin, Fred L wrote: > > > > > I want to address the assertion that assigning /64 prefixes from = a /48 > > > > > would cause up to 65k routes being propagated in the IGP. Using t= he > > > > > WLAN-GW model documented in "unique-ipv6-prefix-per-host", the > > > > > WLAN-GW only needs to advertise the /48 in the IGP and not the > > > > > individual /64s. Instead, the /64s would be maintained in the FIB > > > > > of the WLAN-GW and do not need to be synchronized among all > > > > > routers that participate in the IGP. > > > > > > > > That assumes that the WLAN-GW owns the /48. > > > > > > > > It doesn't. > > > > > > The /48 is owned by the "site", and advertised into the global IPv6 B= GP > > > routing system by site border BGP routers. Within the site, the /48 c= an > > > be provisioned to the WLAN-GW through the advertisement of a single > > > /48 that gets populated through the IGP and eventually all paths lead > > > to the WLAN-GW. From there, the /64s show up only in the FIB of the > > > WLAN-GW. That's really all there is to it. > > > > I do understand aggregation, thanks :-) - but people will and do choose > > different aggregation points in their networks than "the single WLAN-GW= ". > > > > Like, they might have two. Or three. >=20 > Or hundreds or thousands. >=20 > > Or a somewhat structured network. >=20 > AERO explains how this all works. Let's say we had hundreds or thousands > of WLAN-GWs and we wanted to network them. Have the WLAN-GWs > participate in a private BGP instance that *does* carry all /64 prefixes. > When a UE associates with a WLAN-GW, the WLAN-GW injects the UE's > /64 into the BGP routing instance. When the UE disassociates with the > WLAN-GW, the WLAN-GW withdraws the /64. If the UE pops up at a > different WLAN-GW, that new WLAN-GW then injects the route into > the BGP routing system. >=20 > You may worry that this would require all WLAN-GWs to peer with all > other WLAN-GWs, but that is not necessary if we introduce a new > architectural construct - call lit a WLAN-RELAY. There might be a few > 10s of those, and each WLAN-RELAY peers with all WLAN-GWs. So, > the WLAN-RELAYS discover all /64 prefix assignments and which > WLAN-GW the prefix is currently assigned to. The WLAN-GWs then > only need to know about their current working set of /64s, and > set default routes to one or more WLAN-RELAYs. The WLAN-RELAYs > then advertise the /48 into the IGP or (if the WLAN-RELAYs are > also site border routers) into the global Internet BGP routing system. >=20 > Yes, this means that the WLAN-RELAYs would need to carry up > to 65K /64s in the private BGP routing instance. But, we know from > experience that public Internet BGP routers can carry hundreds > of thousands of routes - maybe even as many as a million. It > works, and it scales - this is also explained in AERO. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > > Gert Doering > > -- NetMaster > > -- > > have you enabled IPv6 on something today...? > > > > SpaceNet AG Vorstand: Sebastian v. Bomhard > > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Cule= mann > > D-80807 Muenchen HRB: 136055 (AG Muenchen) > > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Jan 13 09:53:09 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C98E81B2FEA for ; Wed, 13 Jan 2016 09:53:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4yOwAb6Qm6q for ; Wed, 13 Jan 2016 09:53:07 -0800 (PST) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B76C1B2FE3 for ; Wed, 13 Jan 2016 09:53:06 -0800 (PST) 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 u0DHrBud005838; Wed, 13 Jan 2016 09:53:11 -0800 Received: from XCH-BLV-102.nw.nos.boeing.com (xch-blv-102.nw.nos.boeing.com [130.247.25.117]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u0DHr3DU005761 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 13 Jan 2016 09:53:03 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.52]) by XCH-BLV-102.nw.nos.boeing.com ([169.254.2.41]) with mapi id 14.03.0235.001; Wed, 13 Jan 2016 09:52:58 -0800 From: "Templin, Fred L" To: Alexandre Petrescu , "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt Thread-Index: AQHRTdQ4rBJl7bbOOkulVVfNz2tye575lyoAgAADOwCAABJMgIAADIjQ Date: Wed, 13 Jan 2016 17:52:58 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832FA6B3E@XCH-BLV-504.nw.nos.boeing.com> References: <568D1854.7000300@gmail.com> <568FAA3B.3050108@gmail.com> <5690A640.1020009@isi.edu> <20160113072951.GG58491@Space.Net> <20160113075656.GI58491@Space.Net> <569612A1.7050603@gmail.com> In-Reply-To: <569612A1.7050603@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 17:53:09 -0000 Hi Alex, > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandre Petres= cu > Sent: Wednesday, January 13, 2016 1:02 AM > To: v6ops@ietf.org > Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-= 04.txt >=20 >=20 >=20 > Le 13/01/2016 08:56, Gert Doering a =E9crit : > > Hi, > > > > On Wed, Jan 13, 2016 at 04:45:22PM +0900, Erik Kline wrote: > >> Nothing in Section 8 ("Recommendations") recommends DHCPv6-PD. At > >> best it says at one point "e.g., via DHCPv6 PD" and certainly never > >> elevates PD above any other solution. > > > > "it is RECOMMENDED that the network assign a /64 prefix to every host (= e.g., > > via DHCPv6 PD)." > > > > since there is no other mechanism that could do this, >=20 > Right, there is no other Stds Track RFC that could do this (other than > DHCP-PD), but there is Prefix Delegation extension to ND protocol - an > individual Internet Draft: > https://tools.ietf.org/html/draft-kaiser-nd-pd-02 What would be the operational advantage for an ND-based prefix delegation extension? AFAICT, it would require either new messages or extensions to existing messages, and would still need to manage some sort of lease database and the routing system. The draft indicated that it could provide a "faster and less resource consuming way", but I don't see how it could get around managing the same sort of state as for DHCPv6 nor how the message exchanges could be made more efficient? Thanks - Fred fred.l.templin@boeing.com > Alex >=20 >=20 > > argueing that this > > would *not* be recommending DHCPv6-PD is a bit weird. > > > > But if this is not about recommending DHCPv6-PD, and it's just an examp= le, > > I would be happy to see that "(e.g. via DHCPv6 PD)" clause go away, > > and also remove all references to "DHCPv6 PD" in 9.3 - keeping the > > discussion about the routing model as alternative to burdening the ND > > layer is fine, but if you don't want to recommend DHCPv6 PD, then don't > > mention it as a particular technology. > > > > Gert Doering > > -- NetMaster > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Jan 13 11:04:03 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FCF71B30DE for ; Wed, 13 Jan 2016 11:04:02 -0800 (PST) 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 MA7rQN2_0XlS for ; Wed, 13 Jan 2016 11:04:00 -0800 (PST) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF9321B30DD for ; Wed, 13 Jan 2016 11:04:00 -0800 (PST) Received: by mail-pf0-x22f.google.com with SMTP id q63so88217308pfb.1 for ; Wed, 13 Jan 2016 11:04:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=ZbN5FEyzoJAKnpUqCuKt8Cciw0XfzlSYITiUCoeIrUI=; b=FeH/SRkzcN7k3jNcynlmFaSojynhQYZvkLYdriUuRVKndI0fBTLj5ZvQMvcgVhPw0h NmwFNYW1jzaLJgX1AeXfnuqIk+rQS7kaqy+IYCa+gZ35Khn4Tf89+DKQ0pePYfHt6po+ YGim1nS4DAb9hU9lO0IgOnNOugL+zpkW0x9VFkdxa9t1VK2MdqyNEBDdylhtoLlTsYY5 TNcb4+MPw2/Dp/AIZNXg05PETeDJmsuZ7KhvqYr1gLGeTX+MdnYExiz6LtrsvGQ5TLf0 ePgCnu2dUdMEZegS4TDiTatpLJ6t+VPN40weZKjNy6Gal5gtsjjIgjgweHYeX1U278qm f0VA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=ZbN5FEyzoJAKnpUqCuKt8Cciw0XfzlSYITiUCoeIrUI=; b=MRBewd0guaqQd48UWCwDjuZY/gPDKztBha47YAkYiixwRuYbM/KYx6qooEaevAGZOD 0YYs85IuI2xMVmFHY/NrgQXcz3KCI8Ag4xgwjnK9Z2JqcHwQq8ALeXNL58jT0dCV1zwo jskZ6tx07u0+kITshuQe+W7FUB8HrsT99KzpIXzn30KrJC6PCIVPC3igyqchQFU2pMfB HC0ItfnQegoikS6SOLfJtJ1uQ3hUFc8NKkQpnlwuKENZ05SMlXnxGMBeZCdIU+4Er1nl PzCZNlKrZW025xZU7Er1yPa6+8qJ78h7km21lrRTLZ6lJJUC82Dpru82RR6CgZVOhfkj M53w== X-Gm-Message-State: ALoCoQm4umxHTctQXKO89qTh/jibnZA/gmPlwDWtCI9ELe34tCdOmZ19CVAl+iWIsHbPo6viDId7ZMa7B1X24nWYrEBAZ6ng4A== X-Received: by 10.98.43.88 with SMTP id r85mr44302989pfr.7.1452711840369; Wed, 13 Jan 2016 11:04:00 -0800 (PST) Received: from ?IPv6:2406:e007:7472:1:28cc:dc4c:9703:6781? ([2406:e007:7472:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id c86sm4244528pfd.75.2016.01.13.11.03.56 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Jan 2016 11:03:58 -0800 (PST) To: Erik Kline , Gert Doering References: <568D1854.7000300@gmail.com> <568FAA3B.3050108@gmail.com> <5690A640.1020009@isi.edu> <20160113072951.GG58491@Space.Net> <20160113075656.GI58491@Space.Net> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56969FA1.9020606@gmail.com> Date: Thu, 14 Jan 2016 08:04:01 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 19:04:02 -0000 On 13/01/2016 21:28, Erik Kline wrote: > On 13 January 2016 at 16:56, Gert Doering wrote: >> Hi, >> >> On Wed, Jan 13, 2016 at 04:45:22PM +0900, Erik Kline wrote: >>> Nothing in Section 8 ("Recommendations") recommends DHCPv6-PD. At >>> best it says at one point "e.g., via DHCPv6 PD" and certainly never >>> elevates PD above any other solution. >> >> "it is RECOMMENDED that the network assign a /64 prefix to every host (e.g., >> via DHCPv6 PD)." >> >> since there is no other mechanism that could do this, argueing that this >> would *not* be recommending DHCPv6-PD is a bit weird. If you want to be clear about the normative intent, this sentence should be: "It is RECOMMENDED that the network assign a /64 prefix to every host. This MAY be done via DHCPv6 PD." I happen to be a co-author of draft-ietf-anima-prefix-management, which is as far from current practice as you can get, but does prove the point that there will be various ways to meet the recommendation. Mentioning one of them as an actual or implied MAY doesn't dilute the recommendation. Brian >> >> But if this is not about recommending DHCPv6-PD, and it's just an example, >> I would be happy to see that "(e.g. via DHCPv6 PD)" clause go away, >> and also remove all references to "DHCPv6 PD" in 9.3 - keeping the >> discussion about the routing model as alternative to burdening the ND >> layer is fine, but if you don't want to recommend DHCPv6 PD, then don't >> mention it as a particular technology. > > I think we need to keep text about the universe of currently available > solutions. All of those listed are workable. > > It should be easy for > us as a group to recommend that network operators choose (at least) > one solution out of the currently available universe of solutions. > > That's the meat of what's being said here, with a side salad of > motivation and considerations[*]. > > I continue to not see a controversy here. > -ek > > > [*] apologies to vegetarians > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Jan 13 11:54:39 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 727861B3165 for ; Wed, 13 Jan 2016 11:54:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=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 AjVI5VUSbZYH for ; Wed, 13 Jan 2016 11:54:37 -0800 (PST) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0CC21B3164 for ; Wed, 13 Jan 2016 11:54:36 -0800 (PST) Received: by mail-vk0-x232.google.com with SMTP id k1so267816330vkb.2 for ; Wed, 13 Jan 2016 11:54:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=TChvdEsx0jbzxzyjvm1nKKR0S+xqbBXG9nn5QvlQusI=; b=qI1cJJco6V1tqT3E6srdnNZFXtQBVHUZM848mwCHylUZplnCTHOPN2xiSAKRbyghVS xTYkAF22pTKUu7t/aG0HmRAn9ylIIqAuU4GkwEhZx/6w+Ba+57fY1FOLh+x5SKFqrv+S WpijtGeh/XMPF0Ht2ZtoD5CietL1pRBFWHFwyiRNWX+0JDEAout5qPdCGrTMEDrZaBI9 0GDWCoUJ0QHm9Qx3WG0KGqRQt+CjWjspHQCUzfWYzYwALFeQhq5eiBtdR9f64oAbqwj2 +AoIcgeXvXj6Lajlm1/PqbLgkh7FXYhdrEhYdwfpNV0pXL0Ofkbl/Krh3RCdzEcAD31v QG9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=TChvdEsx0jbzxzyjvm1nKKR0S+xqbBXG9nn5QvlQusI=; b=RmPtx1TMh6Uvx4/0r3g4W5orsI0MlrPH3MQL7IQSwNKQJfCTU7h8IefoYxjUD+TWIl cRHiKZUtcpHSW6BQoc2Dr9MxQMshd2tLincm2ig72l8YPZh2aPuQS+KcDQJRBz3kLKx3 8qBsNoPZ5cXNT/1oodXcb1sxMOkVVSdieQvjMn7mT4gr7vpFaMu8d83AaDu6a1pcAIAJ SPnEGu5KRI9FItn5jLFRjl/Mu4oIrQdRP9yY0A8O+nGc+sWxo93Gyb1RgZAPMi3HyKqz Jxy8882FH8OUtm4kcnkkgdleWgptqVI0VgHb1cj0I6ISLP2YkSR5dKg5bZW0Fi/tZRNm yRJg== X-Gm-Message-State: ALoCoQmAhYSEmOaaI+oC1IlwCOrpDYRzWrySRJvbzNdLra64h4L6fVOHERc/tN0GxapciFPN2ldPklQ9cNM28MyHltnQ7ErgKw== X-Received: by 10.31.107.138 with SMTP id k10mr7289vki.27.1452714875878; Wed, 13 Jan 2016 11:54:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.99.1 with HTTP; Wed, 13 Jan 2016 11:54:06 -0800 (PST) In-Reply-To: References: <568D1854.7000300@gmail.com> <568FAA3B.3050108@gmail.com> <5690A640.1020009@isi.edu> <5695202F.5010206@umn.edu> <20160113072248.GF58491@Space.Net> From: Mark Smith Date: Thu, 14 Jan 2016 06:54:06 +1100 Message-ID: To: Mikael Abrahamsson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 19:54:38 -0000 On 13 January 2016 at 23:30, Mikael Abrahamsson wrote: > On Wed, 13 Jan 2016, Lorenzo Colitti wrote: > >> The recommendation is that the network provide them, not that the host do >> something with them. SLAAC provides a /64 prefix with A=1, which allows the >> host to form an unspecified number of addresses at any time in the future. > > > I have come to form the opinion that there should be some kind of BCP on how > many IPv6 addresses the host can expect to form (that works) using A=1. > There should have been some kind of option for the network to advertise the > per-MAC maximum supported by the network, because I'd venture to say that > the host using 1B addresses would never have worked, neither on new or old > hardware. > > Looking at some deployments in the Wifi space, it looks like at least one > vendor has chosen a default to support a max of 8 addresses per MAC, which > is a value that I can understand why they came to considering a lot of > different parameters (one can always discuss if it should be 8 non-LL and 1 > LL, or if it should be 7 non-LL and 1 LL address, but... oh well. > > So while I really would like to see PD supported by hosts, I also think that > giving hints to the host how much working A=1 based addresses it can form > would be good as well. > > Anyone else think this would be a good idea? In that case I guess we'd need > to communicate this to 6man. > A couple of brief points (because I need to have breakfast!). What is or are the motivations for limiting numbers of addresses? I think enumerating them would be useful. "Security" is probably one of them, however, as with DHCP DUIDs, and likely easier, the people who you want to secure excess address consumption against are the same sort of people who are very likely to know how to create and use multiple MAC addresses to overcome those limits (the first thing that comes to my mind on how to do this is the 'macvlan' interfaces under Linux). Regarding the max of 8 addresses example you mentioned, it would be interesting to know how that interacts with Windows, because (from memory), I think they generate in the order of 16 addresses related to a form of privacy addressing, although I can't remember if they're all preferred/valid. Regards, Mark. > -- > Mikael Abrahamsson email: swmike@swm.pp.se > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Jan 13 17:21:04 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15FD31AD0C5 for ; Wed, 13 Jan 2016 17:21:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 GSqw05ucab19 for ; Wed, 13 Jan 2016 17:21:01 -0800 (PST) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.119.220]) by ietfa.amsl.com (Postfix) with ESMTP id EF3381A87E2 for ; Wed, 13 Jan 2016 17:21:00 -0800 (PST) Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128/128); for ; Wed, 13 Jan 2016 19:20:53 -0600 (CST) X-Umn-Remote-Mta: [N] mail-pa0-f47.google.com [209.85.220.47] #+LO+TS+TR X-Umn-Classification: local Received: by mail-pa0-f47.google.com with SMTP id yy13so274785410pab.3 for ; Wed, 13 Jan 2016 17:20:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=reply-to:subject:references:to:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=Y3wnIH9qaruOcJ5b6HiW0ttBj8qzQMsALvI/+Ij6hHY=; b=jI5R1l0/i9mdynbeg5VQJwmEJ/iF+vqu2rAv/FNBm/RgfoebeOIz9HGC0IgrrrOuWi gQPAufqa1QP0z1p9lON83dXqmcTq2Ce0kgf4eN/s7zU28uHL2sqRIW0kw/SWn+ipTCMb gXDW2sn1KUJkl+h7g4cBXuMM06pMYeE4lWfg4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:cc:from :organization:message-id:date:user-agent:mime-version:in-reply-to :content-type:content-transfer-encoding; bh=Y3wnIH9qaruOcJ5b6HiW0ttBj8qzQMsALvI/+Ij6hHY=; b=ke4GOlF4NicXQL50dJVSzSPvBRWT1ylZTaYGWw2mBG++IQdsE8Qm9Qx2QeFBqaKtGi u11RFYxdTVVCbrEXTeEG2cvDjYJJUoqxGaCW3YuTTZ/pR4mB5/ZH7CHf6TJaE+sbk8K6 msZwEYrn7DpULuzq/8uvNQZdGQgVOXSXyatwcQH333xAzOOr5wN4303g/Y9SerY4Kx6l c2fNBdeHpUOFeFRIeeTlI3mZttPnGIYxlB7okxsSoc4FcZ12wd89kQLTiB8DgsyMjFRL QzdiMhx1IU4a5ky1vWn1CgJvjkCOT7J3r/w0H3OP/StUdtUvdbQpRdfPHBZDiO+LfHyi 1NXg== X-Gm-Message-State: ALoCoQkPjiUYGjelSZoDuSX6XgLgnfIUzJ5hxPzah2nWLlGjFCzNDpJ8gineB1F784zrulOBzTp97TJCYJ5EG11dSopsxqRV2KrKpAjuR2IN6Nr1zXHRRA7+a8Ka7pbmgUtCgu03WQjTz2ckj4rVVYTwslpfhz5sDw== X-Received: by 10.66.100.135 with SMTP id ey7mr1871839pab.108.1452734449425; Wed, 13 Jan 2016 17:20:49 -0800 (PST) X-Received: by 10.66.100.135 with SMTP id ey7mr1871826pab.108.1452734449246; Wed, 13 Jan 2016 17:20:49 -0800 (PST) Received: from x-10-104-140-24.uofm-secure.wireless.umn.edu ([2607:ea00:107:2001:e965:1694:a582:4c99]) by smtp.gmail.com with ESMTPSA id n8sm5214642pfj.46.2016.01.13.17.20.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Jan 2016 17:20:47 -0800 (PST) References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <568D1854.7000300@gmail.com> <568FAA3B.3050108@gmail.com> <5690A640.1020009@isi.edu> <5695202F.5010206@umn.edu> To: Lorenzo Colitti From: David Farmer Organization: University of Minnesota Message-ID: <5696F7EA.9020409@umn.edu> Date: Wed, 13 Jan 2016 19:20:42 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 01:21:03 -0000 On 1/12/16 22:39 , Lorenzo Colitti wrote: > On Wed, Jan 13, 2016 at 12:47 AM, David Farmer > wrote: > > "[WRT to the set of multiple address solutions] Outside of > SLAAC there is currently little experience with either DHCPv6 > multiple > IA_NA or IA_PD in host OSes. Nevertheless, these are the only > currently standardized solutions theoretically capable of fulfilling > the requirements [ref = Section 7]." > [...] > > I agree with both points! > > And, not so clearly and concisely I think it says that already. So > yes, I support that language or something very much like it. > > > Ok, then. How about putting this at the end of section 6: > > It should be noted that while providing multiple addresses via SLAAC is > well understood, there is currently limited experience in host operating > systems with DHCPv6 PD, and little or no experience providing multiple > addresses via multiple IA_NA options or multiple DUIDs per host. > However, > these are the only currently standardized options that can provide > multiple > addresses on networks that do not use SLAAC. Erik characterized things as "little experience" with both PD and multiple IA_NA. Where as you characterize things as "little experience" with PD and "little or no experience" with multiple IA_NA. I'm probably being overly sensitive here, but that is the kind of thing I was referring too, there seems to be an implication there. My suggestion, characterize things as "little experience" for both PD and multiple IA_NA to avoid any bias or implication. > And leaving the current recommendations section as is, like so? > > [...] If the network requires explicit requests > for address space (e.g., if it requires DHCPv6 to connect), it is > RECOMMENDED that the network assign a /64 prefix to every host (e.g., > via DHCPv6 PD). Using DHCPv6 IA_NA or IA_TA to request a sufficient > number of addresses (e.g. 32) would accommodate current clients but > sets a limit on the number of addresses available to hosts when they > attach and would limit the development of future applications. > Assigning prefixes longer than a /64 will limit [...] > > Additionally, I think DHCPv6 with multiple IA_NA is a viable > solution to the issue and if the authors do not, they need to more > clearly explain why not. Personally, I'm OK with recommending > DHCPv6 IA_PD over multiple IA_NA, I think there are definite > advantages to DHCPv6 IA_PD. However, without a stronger explanation > why DHCPv6 with multiple IA_NA is not a viable solution, it should > not be implied that multiple IA_NA is not a viable solution. I > think it needs to be more clearly stated that DHCPv6 with multiple > IA_NA is a viable solution, even if it is not the recommended > solution. Further, I think it should be clearly stated that DHCPv6 > with a single IA_NA does not meet the requirements of the draft. > > > It seems to me that the text already addresses the points you raise. It > does not say or imply that multiple IA_NA is not viable, it just > recommends IA_PD over IA_NA for the reason that it is more future-proof > and more extensible. Also, I think it is already pretty clear that a > single IA_NA does not meet the requirements, because the text says "it > is RECOMMENDED that IPv6 network deployments provide multiple IPv6 > addresses [...]", and "multiple" obviously cannot mean one. Months ago, I initially read this as saying "don't use multiple IA_NA", and that concerned me. I convinced myself that it only intended to recommend IA_PD over multiple IA_NA as you say. But then your comments from the following thread, flipped me back around to thinking it really intends to say "don't use multiple IA_NA", and without more rationale I'm not OK with that. https://mailarchive.ietf.org/arch/msg/v6ops/8gsFMoSzZsYGLwBoVZkNyA3RGeM > As for multiple IA_NA, yes - it is much more limited. Without using > fragmentation (and it seems like a pretty bad idea to rely on > fragmentation for DHCPv6 packets), the practical limit to the number of > addresses that can be assigned is about 30, less if lengthy options such > as long domain search lists are used. So, what do you do downstream? > Because the draft recommends that addresses be provided to hosts "when > they connect to the network", what is a host supposed to do if it gets > 20 IA_NA and the user starts a VM? How many should it provide to that > VM? 10? What if the user starts two more VMs, does the third one start > IPv4-only? At what point is the host - which to its VMs acts as the > "network" be forced to violate the spirit of this draft because it > simply didn't get enough space from the upstream to provide enough > addresses to the VMs? > > This is a very important consideration, but it does not really belong > here because host behaviour is out of scope for this draft. I think that > the current text recommending DHCPv6 PD is a reasonable compromise. As > the draft says, /64 has none of these problems because it provides 17 > orders of magnitude more space. This was helpful context to rationalize the recommendation to do DHCPv6 PD over multiple IA_NA. I would feel much better about the current recommendation text if these issues were added as an appendix or something. Without it, I feel there there is a little too much of "you'll be better off if you just do what we tell you to do" going on. Thanks -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nobody Wed Jan 13 18:11:08 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 566431B2A07 for ; Wed, 13 Jan 2016 18:11:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 R2VMNg8f-Toy for ; Wed, 13 Jan 2016 18:11:04 -0800 (PST) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A5D11B2A04 for ; Wed, 13 Jan 2016 18:11:04 -0800 (PST) Received: by mail-yk0-x235.google.com with SMTP id a85so433048350ykb.1 for ; Wed, 13 Jan 2016 18:11:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=uEkqCTuBXW/Cp4bQff7ls+iS+ct/nJ7vJrYaNQB2jSg=; b=OAcTdimZCGMsowLS7s39nNPZpD/5WLabXGxWEHKeyN9dgs1NDIa33dUh8VE4yRnHqS /bH4OfsBMd4BcFtT3AkxLbNPIx6nQJgX58/VI5c/OdeN7JFlztodWCYcqDFj+IQLhvUK h1U79Ci0heO70tQTA6pqKsFDQzhbn/QwuJN6Rr/B5+EvBKDCrqlbmpQp3xgo+vwETF72 Y7wEppWYTJ7IVKLTqAUXlk0uwHkdxUCB2yAlD5OCmYvW/igwOdgfXC00fV5YlnEmAHqS 9t5LaQCcmuPFdzuzUT3ptTUteTHenBax2h9BoAekq+lVUGUQdqE+7wnbTpEva9X5PrW3 6isA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=uEkqCTuBXW/Cp4bQff7ls+iS+ct/nJ7vJrYaNQB2jSg=; b=aoB2jOTjn2Mjx/LIRVrUYURGvXnHJ+HBCVeoUE/HA4HJF5YkMjyvproqcJsY021md2 aPLeqBKNxPnvE8pSHB+ow6ZFs/ktUawja5kQv+xi+wKfc/0WCqVmjCxAD7YeN39qo5lx 5VWxx7QZxvvfdIHIS5GyqKiFbZlFyrHwolVgJXr1gaFiUWjKOmEFKECmH2Ki+nvrpOKx DezMEdwvsuadmlyp9TgWNE9k/cjKYlxdfojIXEJz+SiCqCmgmleMbppoDCrQ8WBzgrXf GQeJ+YlNMg3L1ZucJ0k3RwIPgIBMWoX6F0kZqnqmKDdxG8dLFEY6506bB+rSEOO8VZgn 5oPg== X-Gm-Message-State: ALoCoQmlultxUqnT9SBAStxNvXvvAIeda5vjGaH2qzGcp9ETDdDuePkRDdgToH1CvAoXBWU07XEGNlOPD3vrDhdybpaJfqBfkWVN0wItCr3d0hJ5IbgsNRo= X-Received: by 10.129.41.17 with SMTP id p17mr1297482ywp.160.1452737463473; Wed, 13 Jan 2016 18:11:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.208.201 with HTTP; Wed, 13 Jan 2016 18:10:43 -0800 (PST) In-Reply-To: <5696F7EA.9020409@umn.edu> References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <568D1854.7000300@gmail.com> <568FAA3B.3050108@gmail.com> <5690A640.1020009@isi.edu> <5695202F.5010206@umn.edu> <5696F7EA.9020409@umn.edu> From: Lorenzo Colitti Date: Thu, 14 Jan 2016 11:10:43 +0900 Message-ID: To: David Farmer Content-Type: multipart/alternative; boundary=001a11407ee876d1eb052941cc14 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 02:11:06 -0000 --001a11407ee876d1eb052941cc14 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 14, 2016 at 10:20 AM, David Farmer wrote: > Erik characterized things as "little experience" with both PD and multiple > IA_NA. Where as you characterize things as "little experience" with PD and > "little or no experience" with multiple IA_NA. I'm probably being overly > sensitive here, but that is the kind of thing I was referring too, there > seems to be an implication there. > > My suggestion, characterize things as "little experience" for both PD and > multiple IA_NA to avoid any bias or implication. > The text was only intended to reflect my understanding of reality. I am not aware of any DHCPv6 client that requests multiple IA_NA options, but I am aware of several popular DHCPv6 PD implementations that run on host operating systems (at least the Windows implementation, plus dibbler, ISC DHCP, and dhcpcd). > Months ago, I initially read this as saying "don't use multiple IA_NA", > and that concerned me. I convinced myself that it only intended to > recommend IA_PD over multiple IA_NA as you say. But then your comments > from the following thread, flipped me back around to thinking it really > intends to say "don't use multiple IA_NA", and without more rationale I'm > not OK with that. > > https://mailarchive.ietf.org/arch/msg/v6ops/8gsFMoSzZsYGLwBoVZkNyA3RGeM > > As for multiple IA_NA, yes - it is much more limited. Without using >> fragmentation (and it seems like a pretty bad idea to rely on >> fragmentation for DHCPv6 packets), the practical limit to the number of >> addresses that can be assigned is about 30, less if lengthy options such >> as long domain search lists are used. So, what do you do downstream? >> Because the draft recommends that addresses be provided to hosts "when >> they connect to the network", what is a host supposed to do if it gets >> 20 IA_NA and the user starts a VM? How many should it provide to that >> VM? 10? What if the user starts two more VMs, does the third one start >> IPv4-only? At what point is the host - which to its VMs acts as the >> "network" be forced to violate the spirit of this draft because it >> simply didn't get enough space from the upstream to provide enough >> addresses to the VMs? >> >> This is a very important consideration, but it does not really belong >> here because host behaviour is out of scope for this draft. I think that >> the current text recommending DHCPv6 PD is a reasonable compromise. As >> the draft says, /64 has none of these problems because it provides 17 >> orders of magnitude more space. >> > > This was helpful context to rationalize the recommendation to do DHCPv6 PD > over multiple IA_NA. I would feel much better about the current > recommendation text if these issues were added as an appendix or something. > I think most of those considerations are already in the draft where it talks about multiple IA_NA as an option for providing multiple addresses. The ones that are not are the MTU issue and the behaviour with respect to downstream clients / functions. Can we just add those to the text that talks about multiple IA_NA? --001a11407ee876d1eb052941cc14 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 14, 2016 at 10:20 AM, David Farmer <farmer@umn.edu> wro= te:
Erik characterized things as "little experienc= e" with both PD and multiple IA_NA.=C2=A0 Where as you characterize th= ings as "little experience" with PD and "little or no experi= ence" with multiple IA_NA.=C2=A0 I'm probably being overly sensiti= ve here, but that is the kind of thing I was referring too, there seems to = be an implication there.

My suggestion, characterize things as "little experience" for bot= h PD and multiple IA_NA to avoid any bias or implication.
<= div>
The text was only intended to reflect my understanding o= f reality. I am not aware of any DHCPv6 client that requests multiple IA_NA= options, but I am aware of several popular DHCPv6 PD implementations that = run on host operating systems (at least the Windows implementation, plus di= bbler, ISC DHCP, and dhcpcd).
=C2=A0
Months ago, I initially read this as saying "don't use multiple IA= _NA", and that concerned me.=C2=A0 I convinced myself that it only int= ended to recommend IA_PD over multiple IA_NA as you say.=C2=A0 But then you= r comments from the following thread, flipped me back around to thinking it= really intends to say "don't use multiple IA_NA", and withou= t more rationale I'm not OK with that.

https://mailarchive.ietf.org/= arch/msg/v6ops/8gsFMoSzZsYGLwBoVZkNyA3RGeM

As for multiple IA_NA, yes - it is much more limited. Without using
fragmentation (and it seems like a pretty bad idea to rely on
fragmentation for DHCPv6 packets), the practical limit to the number of
addresses that can be assigned is about 30, less if lengthy options such as long domain search lists are used. So, what do you do downstream?
Because the draft recommends that addresses be provided to hosts "when=
they connect to the network", what is a host supposed to do if it gets=
20 IA_NA and the user starts a VM? How many should it provide to that
VM? 10? What if the user starts two more VMs, does the third one start
IPv4-only? At what point is the host - which to its VMs acts as the
"network" be forced to violate the spirit of this draft because i= t
simply didn't get enough space from the upstream to provide enough
addresses to the VMs?

 This is a very important consideration, but it does not really belong
here because host behaviour is out of scope for this draft. I think that the current text recommending DHCPv6 PD is a reasonable compromise. As
the draft says, /64 has none of these problems because it provides 17
orders of magnitude more space.

This was helpful context to rationalize the recommendation to do DHCPv6 PD = over multiple IA_NA.=C2=A0 I would feel much better about the current recom= mendation text if these issues were added as an appendix or something.
<= /blockquote>

I think most of those considerations are al= ready in the draft where it talks about multiple IA_NA as an option for pro= viding multiple addresses. The ones that are not are the MTU issue and the = behaviour with respect to downstream clients / functions. Can we just add t= hose to the text that talks about multiple IA_NA?
--001a11407ee876d1eb052941cc14-- From nobody Wed Jan 13 22:11:22 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF6C1A92F2 for ; Wed, 13 Jan 2016 22:11:21 -0800 (PST) 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 XEonUUJKXTt3 for ; Wed, 13 Jan 2016 22:11:19 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AFD41ABC10 for ; Wed, 13 Jan 2016 22:11:18 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 3EBE0A2; Thu, 14 Jan 2016 07:11:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1452751876; bh=ZG5GV+yEciLn46KcwDZNOkyajjrbaGMQYmeD1sSJQZc=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=eMA+5/PxeT9+XZVP1ZeSog4SvdTZrfe46E26yFSKpeIVtBcsV0/7ibITVau7RhbcG gS9K8bMYqfqs0WxT4NjTMTaFwruGvIgm7DmdJYEvEw7mUp+swX+zEbOEJWIMbWREEG gHfLR2qH+MKVLgdTgyC6jkD7RAMV+y42WQkCU6Js= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 31364A1; Thu, 14 Jan 2016 07:11:16 +0100 (CET) Date: Thu, 14 Jan 2016 07:11:16 +0100 (CET) From: Mikael Abrahamsson To: Mark Smith In-Reply-To: Message-ID: References: <568D1854.7000300@gmail.com> <568FAA3B.3050108@gmail.com> <5690A640.1020009@isi.edu> <5695202F.5010206@umn.edu> <20160113072248.GF58491@Space.Net> 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: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 06:11:21 -0000 On Thu, 14 Jan 2016, Mark Smith wrote: > What is or are the motivations for limiting numbers of addresses? I > think enumerating them would be useful. Mostly it has to do with hardware resources, for instance TCAM or similar tables. Devices might have a few (tens of) thousands of these entries. So it makes sense to stop a device from using a lot of addresses. > Regarding the max of 8 addresses example you mentioned, it would be > interesting to know how that interacts with Windows, because (from > memory), I think they generate in the order of 16 addresses related to a > form of privacy addressing, although I can't remember if they're all > preferred/valid. >From what I've seen in the wild, a device will (over a week) for a standard SLAAC A=1 deployment, have 1 LL address, 1 EUI-64 address, and up to 7 privacy extension addresses (lifetime a week, an changed daily). Then of course it might allocate itself other addresses, but this is what I have seen in Windows and Linux with no special applications running. With wifi clients that typically come and go, you seldom get these many privacy addresses of course, but instead the network might suffer more because some OSes allocate new privacy address every time it connects to the wifi network. In the specific deployment that I heard a talk about, when you try to use your 9th address, this address will not work, if I remember correctly. Silently, no error message from the network. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Jan 13 22:56:13 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9201B2B88 for ; Wed, 13 Jan 2016 22:56:12 -0800 (PST) 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 RR5gfZQL5d_J for ; Wed, 13 Jan 2016 22:56:10 -0800 (PST) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F4B91B2B87 for ; Wed, 13 Jan 2016 22:56:10 -0800 (PST) Received: from [2a02:c0:2:1:1194:17:0:1029] (port=34524 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1aJbpE-0004dR-6N; Thu, 14 Jan 2016 07:56:04 +0100 Date: Thu, 14 Jan 2016 07:56:02 +0100 From: Tore Anderson To: Lorenzo Colitti Message-ID: <20160114075602.1130c032@echo.ms.redpill-linpro.com> In-Reply-To: References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <568D1854.7000300@gmail.com> <568FAA3B.3050108@gmail.com> <5690A640.1020009@isi.edu> <5695202F.5010206@umn.edu> <5696F7EA.9020409@umn.edu> X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.29; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 06:56:12 -0000 * Lorenzo Colitti > I am not aware of any DHCPv6 client that requests multiple IA_NA > options Try using dibbler-client with the following config file: iface "foo" { ia ia ia ia # [...] } Key log excerpts from when doing so on my Homenet with OpenWrt 15.05: [...] 2016.01.14 07:51:23 Client Info Creating SOLICIT message with 4 IA(s), no TA and 0 PD(s) on p17p1/2 interface. [...] 2016.01.14 07:51:24 Client Info Received REPLY on p17p1/2,trans-id=0xfef1b, 10 opts: 2 1 23 24 20 11 3 3 3 3 [...] 2016.01.14 07:51:24 Client Notice Address 2a02:fe0:c410:4835::32d/128 added to p17p1/2 interface. 2016.01.14 07:51:24 Client Debug RENEW(IA_NA) will be sent (T1) after 21600, REBIND (T2) after 34560 seconds. 2016.01.14 07:51:24 Client Notice Address 2a02:fe0:c410:4835::385/128 added to p17p1/2 interface. 2016.01.14 07:51:24 Client Debug RENEW(IA_NA) will be sent (T1) after 21600, REBIND (T2) after 34560 seconds. 2016.01.14 07:51:24 Client Notice Address 2a02:fe0:c410:4835::8c4/128 added to p17p1/2 interface. 2016.01.14 07:51:24 Client Debug RENEW(IA_NA) will be sent (T1) after 21600, REBIND (T2) after 34560 seconds. 2016.01.14 07:51:24 Client Notice Address 2a02:fe0:c410:4835::6f0/128 added to p17p1/2 interface. 2016.01.14 07:51:24 Client Debug RENEW(IA_NA) will be sent (T1) after 21600, REBIND (T2) after 34560 seconds. [...] Just Works. Tore From nobody Wed Jan 13 23:02:28 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB0531B2BB0 for ; Wed, 13 Jan 2016 23:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 Z_tRVoKDUW7X for ; Wed, 13 Jan 2016 23:02:25 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CEC81B2BAC for ; Wed, 13 Jan 2016 23:02:24 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id p186so202735707qke.0 for ; Wed, 13 Jan 2016 23:02:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=aj6Hh4Jm5huyZSxMep5XupoYPOPN2TtVPin+paLGvjM=; b=NXNuzzsTMwKM7i5H8RbM3DldZRTtMgACS7hKc9mKcKucb3fpBh6vUunvTJXc86+YE3 3ZlSjtNtPKQBIbIYKRxGrNrKkhdtd0RnTmuTGWQ0atMSv06/iXDbJ31UKwzD0Ja1sRCZ hhSu++mYLIGb5ZZfnS67qUld5kMs2/+D4POBr778NiQ2k4MfoQg3/sxDxX8wAs7Gj/NF DKLeZHVhgqrnWDU8AN4axpu3Qb50nBgihQWWYS4ynPhqjMGhKUg6WUoOfRhRwki1VEKU ciZNAH4xLaJELxbovt+OfuofVojIvuTMqpKiv9H1k1M0hG0tDkv90IJtgUFJv0lqe+os BQrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=aj6Hh4Jm5huyZSxMep5XupoYPOPN2TtVPin+paLGvjM=; b=N+dXOx2KS4vVPjXpITuQ2PUbD3fuws2176PM8Cc54Tx5lUiRKgsatZahoNPghGAGoG xjUf1i72oGykhARr/Ypqv0ii0B1YWCG69DYX6SVGVYyemQN/wLHnMc62U0Z+UPR7/r+Z fzr1fzRvaXsWMRetFqD1q9KG6+KoE16mdLMzYBrQVOBxhvTMbd+9P8Ojcb2vboryau71 eO+t0mW83u6kgrSTUEedvIGsCVa+hNrjRa+lBKCVcbyxYMcenpbPFXI591+nnQPGt27y rU5zbceLJQbjSRMsZ6dDE6m8lTXTSQ0tNDTQbhwOLdAktJJias9AOeN+8oBqizv7VtbC eqNQ== X-Gm-Message-State: ALoCoQk7mlhwlv5slQxJ5l3Mt8jLuR6tk3Ajx2MCSJ1DbXl7BSaPT56XmfCrBHtq6J2VfHSwfMw3J5vCb+COsIwLYv07EvrRGUAVqEXLO5Iffk9ezGCcce8= X-Received: by 10.129.108.88 with SMTP id h85mr2015008ywc.156.1452754943975; Wed, 13 Jan 2016 23:02:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.208.201 with HTTP; Wed, 13 Jan 2016 23:02:04 -0800 (PST) In-Reply-To: <20160114075602.1130c032@echo.ms.redpill-linpro.com> References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98901@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <568D1854.7000300@gmail.com> <568FAA3B.3050108@gmail.com> <5690A640.1020009@isi.edu> <5695202F.5010206@umn.edu> <5696F7EA.9020409@umn.edu> <20160114075602.1130c032@echo.ms.redpill-linpro.com> From: Lorenzo Colitti Date: Thu, 14 Jan 2016 16:02:04 +0900 Message-ID: To: Tore Anderson Content-Type: multipart/alternative; boundary=001a114d88f06238e9052945de71 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 07:02:26 -0000 --001a114d88f06238e9052945de71 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 14, 2016 at 3:56 PM, Tore Anderson wrote: > > I am not aware of any DHCPv6 client that requests multiple IA_NA > > options > > Try using dibbler-client with the following config file: > True. It's likely that dibbler is almost (?) never configured like this by default, wheres it's configured to do pd by default very often (on CPEs), but point taken. iface "foo" { > ia > ia > ia > ia > # [...] > } > Unfortunately I can't test dibbler because the version packaged on my system segfaults on startup. :-( How many "ia" can you get this way? If you specify more than 30, does it fragment? --001a114d88f06238e9052945de71 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 14, 2016 at 3:56 PM, Tore Anderson <tore@fud.no> wrote:
> I am not aware of any DHCPv6 client that reque= sts multiple IA_NA
> options

Try using dibbler-client with the following config file:

True. It's likely that dibbler is almost (?) n= ever configured like this by default, wheres it's configured to do pd b= y default very often (on CPEs), but point taken.

iface "foo" {
=C2=A0 ia
=C2=A0 ia
=C2=A0 ia
=C2=A0 ia
=C2=A0 # [...]
}


Unfortunately I can= 9;t test dibbler because the version packaged on my system segfaults on sta= rtup. :-( How many "ia" can you get this way? If you specify more= than 30, does it fragment?
--001a114d88f06238e9052945de71-- From nobody Wed Jan 13 23:27:12 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1219F1B2C40 for ; Wed, 13 Jan 2016 23:27:11 -0800 (PST) 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 QBmigBGAHlhA for ; Wed, 13 Jan 2016 23:27:09 -0800 (PST) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEC361B2C3F for ; Wed, 13 Jan 2016 23:27:08 -0800 (PST) Received: from [2a02:c0:2:1:1194:17:0:1029] (port=35972 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1aJcJE-0005N5-AU; Thu, 14 Jan 2016 08:27:04 +0100 Date: Thu, 14 Jan 2016 08:27:03 +0100 From: Tore Anderson To: Lorenzo Colitti Message-ID: <20160114082703.09976d83@echo.ms.redpill-linpro.com> In-Reply-To: References: <20160104031639.16535.43111.idtracker@ietfa.amsl.com> <2134F8430051B64F815C691A62D9831832F98A37@XCH-BLV-504.nw.nos.boeing.com> <568D1854.7000300@gmail.com> <568FAA3B.3050108@gmail.com> <5690A640.1020009@isi.edu> <5695202F.5010206@umn.edu> <5696F7EA.9020409@umn.edu> <20160114075602.1130c032@echo.ms.redpill-linpro.com> X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.29; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 07:27:11 -0000 * Lorenzo Colitti > True. It's likely that dibbler is almost (?) never configured like this by > default, wheres it's configured to do pd by default very often (on CPEs), > but point taken. On my Fedora node the default client config file requests a single IA_NA plus DNS server and search list, no PD. It uses this exact file by default: https://github.com/tomaszmrugalski/dibbler/blob/master/doc/examples/client.conf So while both the the multi-IA_NA and IA_PD approaches work in a Homenet, both would require manual config (at least in the Dibbler on Fedora use case). Of course, SLAAC also works here so that point is probably moot. > Unfortunately I can't test dibbler because the version packaged on my > system segfaults on startup. :-( How many "ia" can you get this way? If you > specify more than 30, does it fragment? I tried with 64. It got all addresses it wanted and configured them fine, but it seems it had to split the request into multiple packets. The client did that itself, at least I don't see any IPv6 fragments in the PCAP at least. In case you're insterested in having a closer look, I uploaded the client log and a PCAP file here: http://filebin.redpill-linpro.com/57mxq4hsfs (Note: This is just meant to help the discussion with some neutral facts, not take it as an opinion about whether your draft should say this or that.) Tore From nobody Thu Jan 14 04:47:33 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D521B3430 for ; Thu, 14 Jan 2016 04:47:32 -0800 (PST) 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 JmVPLpS9Ankk for ; Thu, 14 Jan 2016 04:47:30 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BB9C1B342A for ; Thu, 14 Jan 2016 04:47:29 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 6A4946077C for ; Thu, 14 Jan 2016 13:47:27 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 31A9D600F9 for ; Thu, 14 Jan 2016 13:47:27 +0100 (CET) Received: (qmail 7242 invoked by uid 1007); 14 Jan 2016 13:47:27 +0100 Date: Thu, 14 Jan 2016 13:47:27 +0100 From: Gert Doering To: Brian E Carpenter Message-ID: <20160114124727.GW58491@Space.Net> References: <568FAA3B.3050108@gmail.com> <5690A640.1020009@isi.edu> <20160113072951.GG58491@Space.Net> <20160113075656.GI58491@Space.Net> <56969FA1.9020606@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Vl4HEc3NGO3Rz0w4" Content-Disposition: inline In-Reply-To: <56969FA1.9020606@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 12:47:32 -0000 --Vl4HEc3NGO3Rz0w4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Jan 14, 2016 at 08:04:01AM +1300, Brian E Carpenter wrote: > If you want to be clear about the normative intent, this sentence should = be: >=20 > "It is RECOMMENDED that the network assign a /64 prefix to every host. > This MAY be done via DHCPv6 PD." >=20 > I happen to be a co-author of draft-ietf-anima-prefix-management, > which is as far from current practice as you can get, but does prove > the point that there will be various ways to meet the recommendation. > Mentioning one of them as an actual or implied MAY doesn't dilute the > recommendation. Now the remaining question is, of course, why the recommendation is for=20 a /64 per host. Why not a /60, or a /96? Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --Vl4HEc3NGO3Rz0w4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVpeY3t9WwGXkzn/FAQKxrQ//Tu77ZrPVEUiOUxc6YAb9tiNaqBryIVPN uDu4N8pRM3Jk2TwCfsKSI5CK5z33pRPjYOHIvqyL5OdKhylyJ79J+/qmtYIA6UIN jPkxNpr5uJyRxMUcCiC/dEA6IWwH+8aynqGPxBZhFxnnDLJHjDHWIr8jOPtGAzFr mI3MnOgDvIa2Gw3GZIwBgYqlr3b68kx9rxuO2JQrAXSe92W0D/4zDAlB97WWoLfu sTIFYjitXfIqFex058RzEMDS5zaGZE+WjkbgPuJRid0RwxSxsTbLd1sFRYSVUy8J OvUe8iO59D0zGkRbcT8jnrTHby6sZtr/MumlKqAZ7b+OxUugqLiJ75nD0vVwfhML r/AYCwhO/atmkudZawWYNZnGMq9uBCkYuMScRn8t5tx5F1dzaWNADzfXbwamz8Ac HA3s1SLoGqO4acwXqOu62xf+CjLdU3Skf3CF+uppp3LViidb6Fzw90uGGy16SfGx VgYaGEobGYxBhIkVSiFdWzbQPJgm0rZO/JSDZ+VgP+q06+WgTbdWMyo4Y0j8tHF3 rNtLNqr3r+jTzz3kvZCBl62+SRzbw3FLmDCTIlNmhFbpo04GQ86fTjJLCBClnwJw Q5JICtwY+lUC7/WWIhyo3wzEaBsz0IMg9vtQWN1kZ+tpH2gmq0LWYi1PCdaEizjS o69AbusMbuY= =Qrqq -----END PGP SIGNATURE----- --Vl4HEc3NGO3Rz0w4-- From nobody Thu Jan 14 06:01:36 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27BDB1ACE28 for ; Thu, 14 Jan 2016 06:01:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 m8tthsv0s4Uy for ; Thu, 14 Jan 2016 06:01:30 -0800 (PST) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A415C1ACE24 for ; Thu, 14 Jan 2016 06:01:30 -0800 (PST) Received: by mail-qg0-x235.google.com with SMTP id 6so402090764qgy.1 for ; Thu, 14 Jan 2016 06:01:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=TKqaS/jijaSgpKDPeRP4QELE2DtuSq7kGufdcbqSAgs=; b=FPgGeXxTYDMfGIGqQBNzydtS0BKsqK/q0tx28x0qxerpv05kdWzRuYLSoi0s7gXjmF cRKFKkdJ+vB1DnvZnqfO/aN4xDoL6oAPGJj6qBsPm9yKNa7cW8qWIzcGeaUonvQimWIP aPGEqxF333SZTZhEzDoHyT2M3rpuCQREbE62iQC61FvT2FChQXFBqBqkOYy6HBaIsuoq HpAqOShZvUe0z03lk2J1DyhS02pPqHvyU6OWXYBetU5Uyecg5AlGFvZwYVT5wm6H6B7L 6BURF9UaKRWdesvmoDWP3Bba2PDW9V4RicrK/rTfuc1HrCXi7pBhEKXtVcqrEQURIFaH Frsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=TKqaS/jijaSgpKDPeRP4QELE2DtuSq7kGufdcbqSAgs=; b=ki4Cz7V3BXFamJnFG07fdPdbZ5n7spzAzxNYa/rhuyGGNaMfczAD6oqhCe+WeeeSOf Jh7E4/z2E5THbllzGYubJrgIlrYaTvvudYXYCV29HG++gBO0BdvPpw3ykCbizrPnj6jN Q+O5uxQlnY0i21PzHrXekG7GMDixFWPAs2K75d9xiskBNYCMguQAP1LywA9vnzzG9E71 wqNTHujIMTAJ34LFr8Z2RYloDm2FAufnRazzmzZCbN/+xinqL8NV/tPIzUOgRqY1WnqL vcngTNkTGHtlhMg3tWnRQ0M9tDg5Uje5/fdlvOgzFcFPIHd38hmgrKY1xYemSZ/f039E nXvg== X-Gm-Message-State: ALoCoQlnYxnzfBM4rkX5GLZRDAgCsrVf5Ls3CUwLjn0yA8CaWu8eA9Jayh30tT1touESvV2mtxhMiWjqmTlBzCY6p3AVBJKNChSpx7AvHe7PpIEDhD5Sy3Y= X-Received: by 10.13.205.199 with SMTP id p190mr3037775ywd.116.1452780089221; Thu, 14 Jan 2016 06:01:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.208.201 with HTTP; Thu, 14 Jan 2016 06:01:09 -0800 (PST) In-Reply-To: <20160114124727.GW58491@Space.Net> References: <568FAA3B.3050108@gmail.com> <5690A640.1020009@isi.edu> <20160113072951.GG58491@Space.Net> <20160113075656.GI58491@Space.Net> <56969FA1.9020606@gmail.com> <20160114124727.GW58491@Space.Net> From: Lorenzo Colitti Date: Thu, 14 Jan 2016 23:01:09 +0900 Message-ID: To: Gert Doering Content-Type: multipart/alternative; boundary=001a114e5eb6283e3c05294bb97e Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 14:01:35 -0000 --001a114e5eb6283e3c05294bb97e Content-Type: text/plain; charset=UTF-8 On Thu, Jan 14, 2016 at 9:47 PM, Gert Doering wrote: > Now the remaining question is, of course, why the recommendation is for > a /64 per host. Why not a /60, or a /96? This is discussed in section 6. A /64 is recommended because prefixes longer than /64 are outside the IPv6 specifications [RFC 7421], and because a /64 can be easily extended via L2 bridging, ND proxying or /64 sharing without impacting the network. This makes it possible for the host to provide "unlimited" addressing to internal and subtended functions and devices. The address space requirements are discussed in section 9.2, which shows that with a /64 per host, a /40 can address enough devices as an IPv4 /8 with one IPv4 address per host. The draft states that networks that are big enough to use substantial parts of a /8 can easily get an IPv6 /40. You disputed that assertion, but several others disagree with you. My reading of RIPE-655 section 5.4.2 says that a site can get more than a /48 if it justifies it. The cost in terms of routing slots is the same as IPv4. Just as you don't put the IPv4 /32s of individual hosts in your IGP, but instead route aggregates (/24, /21, whatever), you wouldn't put the IPv6 /64s of individual hosts in the IGP, but would instead route aggregates of corresponding size. --001a114e5eb6283e3c05294bb97e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 14, 2016 at 9:47 PM, Gert Doering <gert@space.net> wrot= e:
Now the remaining question is, of course, why the re= commendation is for
a /64 per host.=C2=A0 =C2=A0Why not a /60, or a /96?

<= /div>
This is discussed in section 6. A /64 is recommended because pref= ixes longer than /64 are outside the IPv6 specifications [RFC 7421], and be= cause a /64 can be easily extended via L2 bridging, ND proxying or /64 shar= ing without impacting the network. This makes it possible for the host to p= rovide "unlimited" addressing to internal and subtended functions= and devices.

The address space requirements a= re discussed in section 9.2, which shows that with a /64 per host, a /40 ca= n address enough devices as an IPv4 /8 with one IPv4 address per host. The = draft states that networks that are big enough to use substantial parts of = a /8 can easily get an IPv6 /40. You disputed that assertion, but several o= thers disagree with you. My reading of RIPE-655 section 5.4.2 says that a s= ite can get more than a /48 if it justifies it.

Th= e cost in terms of routing slots is the same as IPv4. Just as you don't= put the IPv4 /32s of individual hosts in your IGP, but instead route aggre= gates (/24, /21, whatever), you wouldn't put the IPv6 /64s of individua= l hosts in the IGP, but would instead route aggregates of corresponding siz= e.
--001a114e5eb6283e3c05294bb97e-- From nobody Thu Jan 14 06:03:15 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 714471ACE3D for ; Thu, 14 Jan 2016 06:03:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 C6bj94DcEF_u for ; Thu, 14 Jan 2016 06:03:08 -0800 (PST) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14E2B1ACE36 for ; Thu, 14 Jan 2016 06:03:08 -0800 (PST) Received: by mail-qk0-x233.google.com with SMTP id q19so244156009qke.3 for ; Thu, 14 Jan 2016 06:03:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=HPIQVJOIpRoReNUeWL6YCFF//Wa++J820Dfv8Hi1hqU=; b=kXxPlP3suP8x5fhWG4m8A59/I47d7Tnv65qu9P6agGeexK+7kabsjQ14utpCSCxVtv PdCvzh8bdlVUZbkFfxVZG/4nVcXrq+TFByB2JqprLbw0MNrvJm7mcLurfdsigC0z5PAn aR5H3o4BGiSb232wORwGmFb5WB0s7o6HtNZ8YadrAgnUjYJvceN+B/3cH0zrCjCsp8lG Q8WYF9zFQ8VZcUtjXjdBc3UZPZbeTpKAcnhxAVt5jb0bTeBXfk4SD1ky1JV1bA4AizCO qbE/IHEyySR5TLOJ1DQuWfyyAkoKBhS5QW8dV77KK3M9WDwzTihc3bwVOM1DusSxoZv5 A7rA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=HPIQVJOIpRoReNUeWL6YCFF//Wa++J820Dfv8Hi1hqU=; b=nJDjJVBqM00ahv0vNeBYlT/hU12xAbbLX+9NM3v/xXohiulg4L6J0MnllOofYWRDz0 bAjLoBc2ruH5mVc6+i7MAd+1IvcqdDX4XXAUr1WTOdZjDJrx5wjP415U8pt5imgv5TBX zveVF13sL0idFo60zC8zLuxl3HrzAlRaYw+xz9wzfoJSVCXb2cVmq0EnqYUXp5/lvmI9 RqkGWBoXWx7aRPF1YfbnUVei+DEn/tuHEnBkZmw4s7FP6AltHVEeC8SF15Na7+wb42sp YuKnIqowI6wB8cZ8/vdULJDEegNQFqQmVNo+WZKOAtoZqERYK1SNyG+siBvj5QYC51TN JVgg== X-Gm-Message-State: ALoCoQkRaIumyIoRclCR2LsezSSdwnqgm4O7Ocg7byQlTkP0g5twxDhuOmXmnOydlr4Yms4SoIiT+/HY3nkVPROMjybCFcyJGptgaXNH72n4MHSgRP4HASI= X-Received: by 10.129.41.17 with SMTP id p17mr2895109ywp.160.1452780187162; Thu, 14 Jan 2016 06:03:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.208.201 with HTTP; Thu, 14 Jan 2016 06:02:47 -0800 (PST) In-Reply-To: References: <568FAA3B.3050108@gmail.com> <5690A640.1020009@isi.edu> <20160113072951.GG58491@Space.Net> <20160113075656.GI58491@Space.Net> <56969FA1.9020606@gmail.com> <20160114124727.GW58491@Space.Net> From: Lorenzo Colitti Date: Thu, 14 Jan 2016 23:02:47 +0900 Message-ID: To: Gert Doering Content-Type: multipart/alternative; boundary=001a11407ee8fea65705294bbe1d Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 14:03:12 -0000 --001a11407ee8fea65705294bbe1d Content-Type: text/plain; charset=UTF-8 On Thu, Jan 14, 2016 at 11:01 PM, Lorenzo Colitti wrote: > On Thu, Jan 14, 2016 at 9:47 PM, Gert Doering wrote: > >> Now the remaining question is, of course, why the recommendation is for >> a /64 per host. Why not a /60, or a /96? > > > A /64 is recommended because prefixes longer than /64 are outside the IPv6 > specifications > Forgot to mention: yes, the draft could be updated to say "at least a /64" instead of "a /64". We did not see any need to do so, however. --001a11407ee8fea65705294bbe1d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 14, 2016 at 11:01 PM, Lorenzo Colitti <lorenzo@google.com>= wrote:
On Thu, Jan 1= 4, 2016 at 9:47 PM, Gert Doering <gert@space.net> wrote:
Now the remaining question is, of course, why the recommendat= ion is for
a /64 per host.=C2=A0 =C2=A0Why not a /60, or a /96?

<= /div>
A /64 is recommended because prefixes longer than /64 are = outside the IPv6 specifications
Forgot to mention: yes, the draft could be updated to say &quo= t;at least a /64" instead of "a /64". We did not see any nee= d to do so, however.
--001a11407ee8fea65705294bbe1d-- From nobody Thu Jan 14 06:07:13 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC0331ACE6E for ; Thu, 14 Jan 2016 06:07:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8AR9CNBaxbW9 for ; Thu, 14 Jan 2016 06:07:07 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B67C1ACE5A for ; Thu, 14 Jan 2016 06:07:06 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u0EE71YT000753; Thu, 14 Jan 2016 15:07:01 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 625AE206B86; Thu, 14 Jan 2016 15:14:40 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 55744206B83; Thu, 14 Jan 2016 15:14:40 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u0EE71IG032728; Thu, 14 Jan 2016 15:07:01 +0100 To: "Templin, Fred L" , "v6ops@ietf.org" References: <568D1854.7000300@gmail.com> <568FAA3B.3050108@gmail.com> <5690A640.1020009@isi.edu> <20160113072951.GG58491@Space.Net> <20160113075656.GI58491@Space.Net> <569612A1.7050603@gmail.com> <2134F8430051B64F815C691A62D9831832FA6B3E@XCH-BLV-504.nw.nos.boeing.com> From: Alexandre Petrescu Message-ID: <5697AB85.9040001@gmail.com> Date: Thu, 14 Jan 2016 15:07:01 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <2134F8430051B64F815C691A62D9831832FA6B3E@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 14:07:11 -0000 Hi Fred, Le 13/01/2016 18:52, Templin, Fred L a écrit : > Hi Alex, > >> -----Original Message----- From: v6ops >> [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandre Petrescu >> Sent: Wednesday, January 13, 2016 1:02 AM To: v6ops@ietf.org >> Subject: Re: [v6ops] I-D Action: >> draft-ietf-v6ops-host-addr-availability-04.txt >> >> >> >> Le 13/01/2016 08:56, Gert Doering a écrit : >>> Hi, >>> >>> On Wed, Jan 13, 2016 at 04:45:22PM +0900, Erik Kline wrote: >>>> Nothing in Section 8 ("Recommendations") recommends DHCPv6-PD. >>>> At best it says at one point "e.g., via DHCPv6 PD" and >>>> certainly never elevates PD above any other solution. >>> >>> "it is RECOMMENDED that the network assign a /64 prefix to every >>> host (e.g., via DHCPv6 PD)." >>> >>> since there is no other mechanism that could do this, >> >> Right, there is no other Stds Track RFC that could do this (other >> than DHCP-PD), but there is Prefix Delegation extension to ND >> protocol - an individual Internet Draft: >> https://tools.ietf.org/html/draft-kaiser-nd-pd-02 > > What would be the operational advantage for an ND-based prefix > delegation extension? The operational advantage would be related to performing software implementations. > AFAICT, it would require either new messages or extensions to > existing messages, and would still need to manage some sort of lease > database and the routing system. The draft indicated that it could > provide a "faster and less resource consuming way", but I don't see > how it could get around managing the same sort of state as for DHCPv6 > nor how the message exchanges could be made more efficient? Less resource consuming on the UE mainly (the "Host")- because it would be small extensions of existing software (ND parts in kernel and userspace), rather than adding new software suite (DHCPv6 daemon in userspace). This is relevant in some UE chipsets allowing only 150mb free ram after the ND parts are already there. Indeed state must be managed at ND server (DHCP Server equivalent). But that is a large computer in the network - it can afford much memory and fast clock. The message exchange can be more efficient because ND typically involves 2 messages (Solicitation/Advertisement) whereas DHCP typically involves 4 messages (Solicit/Advertize/Request/Response) although exceptions exist. Yours, Alex > > Thanks - Fred fred.l.templin@boeing.com > >> Alex >> >> >>> argueing that this would *not* be recommending DHCPv6-PD is a bit >>> weird. >>> >>> But if this is not about recommending DHCPv6-PD, and it's just an >>> example, I would be happy to see that "(e.g. via DHCPv6 PD)" >>> clause go away, and also remove all references to "DHCPv6 PD" in >>> 9.3 - keeping the discussion about the routing model as >>> alternative to burdening the ND layer is fine, but if you don't >>> want to recommend DHCPv6 PD, then don't mention it as a >>> particular technology. >>> >>> Gert Doering -- NetMaster >>> >>> >>> >>> _______________________________________________ v6ops mailing >>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>> >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Jan 14 06:08:18 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6581ACE5A for ; Thu, 14 Jan 2016 06:08:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5R0Vbc8GFCs for ; Thu, 14 Jan 2016 06:08:14 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDC1C1ACE2B for ; Thu, 14 Jan 2016 06:08:13 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u0EE87NY007408; Thu, 14 Jan 2016 15:08:07 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 419B6206B91; Thu, 14 Jan 2016 15:15:46 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 3376D206B33; Thu, 14 Jan 2016 15:15:46 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u0EE87YK001797; Thu, 14 Jan 2016 15:08:07 +0100 To: Alexandre Petrescu , "Templin, Fred L" , "v6ops@ietf.org" References: <568D1854.7000300@gmail.com> <568FAA3B.3050108@gmail.com> <5690A640.1020009@isi.edu> <20160113072951.GG58491@Space.Net> <20160113075656.GI58491@Space.Net> <569612A1.7050603@gmail.com> <2134F8430051B64F815C691A62D9831832FA6B3E@XCH-BLV-504.nw.nos.boeing.com> <5697AB85.9040001@gmail.com> From: Alexandre Petrescu Message-ID: <5697ABC7.6020006@gmail.com> Date: Thu, 14 Jan 2016 15:08:07 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <5697AB85.9040001@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 14:08:17 -0000 Le 14/01/2016 15:07, Alexandre Petrescu a écrit : > Hi Fred, > > Le 13/01/2016 18:52, Templin, Fred L a écrit : >> Hi Alex, >> >>> -----Original Message----- From: v6ops >>> [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandre Petrescu >>> Sent: Wednesday, January 13, 2016 1:02 AM To: v6ops@ietf.org >>> Subject: Re: [v6ops] I-D Action: >>> draft-ietf-v6ops-host-addr-availability-04.txt >>> >>> >>> >>> Le 13/01/2016 08:56, Gert Doering a écrit : >>>> Hi, >>>> >>>> On Wed, Jan 13, 2016 at 04:45:22PM +0900, Erik Kline wrote: >>>>> Nothing in Section 8 ("Recommendations") recommends DHCPv6-PD. >>>>> At best it says at one point "e.g., via DHCPv6 PD" and >>>>> certainly never elevates PD above any other solution. >>>> >>>> "it is RECOMMENDED that the network assign a /64 prefix to every >>>> host (e.g., via DHCPv6 PD)." >>>> >>>> since there is no other mechanism that could do this, >>> >>> Right, there is no other Stds Track RFC that could do this (other >>> than DHCP-PD), but there is Prefix Delegation extension to ND >>> protocol - an individual Internet Draft: >>> https://tools.ietf.org/html/draft-kaiser-nd-pd-02 >> >> What would be the operational advantage for an ND-based prefix >> delegation extension? > > The operational advantage would be related to performing software > implementations. > >> AFAICT, it would require either new messages or extensions to >> existing messages, and would still need to manage some sort of lease >> database and the routing system. The draft indicated that it could >> provide a "faster and less resource consuming way", but I don't see >> how it could get around managing the same sort of state as for DHCPv6 >> nor how the message exchanges could be made more efficient? > > Less resource consuming on the UE mainly (the "Host")- because it would > be small extensions of existing software (ND parts in kernel and > userspace), rather than adding new software suite (DHCPv6 daemon in > userspace). This is relevant in some UE chipsets allowing only 150mb > free ram after the ND parts are already there. I meant 92mb free after ND is already there in a total of 150mb ram. Alex > > Indeed state must be managed at ND server (DHCP Server equivalent). But > that is a large computer in the network - it can afford much memory and > fast clock. > > The message exchange can be more efficient because ND typically involves > 2 messages (Solicitation/Advertisement) whereas DHCP typically involves > 4 messages (Solicit/Advertize/Request/Response) although exceptions > exist. > > Yours, > > Alex > >> >> Thanks - Fred fred.l.templin@boeing.com >> >>> Alex >>> >>> >>>> argueing that this would *not* be recommending DHCPv6-PD is a bit >>>> weird. >>>> >>>> But if this is not about recommending DHCPv6-PD, and it's just an >>>> example, I would be happy to see that "(e.g. via DHCPv6 PD)" >>>> clause go away, and also remove all references to "DHCPv6 PD" in >>>> 9.3 - keeping the discussion about the routing model as >>>> alternative to burdening the ND layer is fine, but if you don't >>>> want to recommend DHCPv6 PD, then don't mention it as a >>>> particular technology. >>>> >>>> Gert Doering -- NetMaster >>>> >>>> >>>> >>>> _______________________________________________ v6ops mailing >>>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>>> >>> >>> _______________________________________________ v6ops mailing list >>> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> From nobody Thu Jan 14 06:28:43 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E89C1ACE9E for ; Thu, 14 Jan 2016 06:28:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3QPtSRGPSMq for ; Thu, 14 Jan 2016 06:28:40 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B4581ACE5D for ; Thu, 14 Jan 2016 06:28:39 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u0EEScFB009727 for ; Thu, 14 Jan 2016 15:28:38 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D3EBF206AD1 for ; Thu, 14 Jan 2016 15:36:16 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id CA6D3200D22 for ; Thu, 14 Jan 2016 15:36:16 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u0EEScad021781 for ; Thu, 14 Jan 2016 15:28:38 +0100 To: v6ops@ietf.org References: <568FAA3B.3050108@gmail.com> <5690A640.1020009@isi.edu> <20160113072951.GG58491@Space.Net> <20160113075656.GI58491@Space.Net> <56969FA1.9020606@gmail.com> <20160114124727.GW58491@Space.Net> From: Alexandre Petrescu Message-ID: <5697B096.70305@gmail.com> Date: Thu, 14 Jan 2016 15:28:38 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 14:28:42 -0000 Hi, Le 14/01/2016 15:01, Lorenzo Colitti a écrit : > On Thu, Jan 14, 2016 at 9:47 PM, Gert Doering > wrote: > > Now the remaining question is, of course, why the recommendation is for > a /64 per host. Why not a /60, or a /96? > > > This is discussed in section 6. A /64 is recommended because prefixes > longer than /64 are outside the IPv6 specifications [RFC 7421], Ok for no prefixes longer than /64 because some IPv6 spec [RFC7421]. But why not a prefix _shorter_ than /64, like a /60? (it's not clear to me whether the explanation you provide below, or section 9.2, answers this question). Alex [*] note that other IPv6 specs (RFC4862, RFC7608) say that any prefix lengths are ok for SLAAC and for forwarding. and > because a /64 can be easily extended via L2 bridging, ND proxying or /64 > sharing without impacting the network. This makes it possible for the > host to provide "unlimited" addressing to internal and subtended > functions and devices. > > The address space requirements are discussed in section 9.2, which shows > that with a /64 per host, a /40 can address enough devices as an IPv4 /8 > with one IPv4 address per host. The draft states that networks that are > big enough to use substantial parts of a /8 can easily get an IPv6 /40. > You disputed that assertion, but several others disagree with you. My > reading of RIPE-655 section 5.4.2 says that a site can get more than a > /48 if it justifies it. > > The cost in terms of routing slots is the same as IPv4. Just as you > don't put the IPv4 /32s of individual hosts in your IGP, but instead > route aggregates (/24, /21, whatever), you wouldn't put the IPv6 /64s of > individual hosts in the IGP, but would instead route aggregates of > corresponding size. > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Jan 14 06:30:18 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 852061A8849 for ; Thu, 14 Jan 2016 06:30:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahhL_rVzPc8C for ; Thu, 14 Jan 2016 06:30:16 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBE641A86E0 for ; Thu, 14 Jan 2016 06:30:15 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u0EEUDBE016472 for ; Thu, 14 Jan 2016 15:30:13 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 448F7206BF9 for ; Thu, 14 Jan 2016 15:37:52 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 35781206BD3 for ; Thu, 14 Jan 2016 15:37:52 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u0EEUDIF023360 for ; Thu, 14 Jan 2016 15:30:13 +0100 To: v6ops@ietf.org References: <568FAA3B.3050108@gmail.com> <5690A640.1020009@isi.edu> <20160113072951.GG58491@Space.Net> <20160113075656.GI58491@Space.Net> <56969FA1.9020606@gmail.com> <20160114124727.GW58491@Space.Net> From: Alexandre Petrescu Message-ID: <5697B0F5.3050608@gmail.com> Date: Thu, 14 Jan 2016 15:30:13 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 14:30:17 -0000 at least _one_ /64? (i.e. better would _two_ distinct /64s) or plen value at least 64? (i.e. better would be 63) Alex Le 14/01/2016 15:02, Lorenzo Colitti a écrit : > On Thu, Jan 14, 2016 at 11:01 PM, Lorenzo Colitti > wrote: > > On Thu, Jan 14, 2016 at 9:47 PM, Gert Doering > wrote: > > Now the remaining question is, of course, why the recommendation > is for > a /64 per host. Why not a /60, or a /96? > > > A /64 is recommended because prefixes longer than /64 are outside > the IPv6 specifications > > > Forgot to mention: yes, the draft could be updated to say "at least a > /64" instead of "a /64". We did not see any need to do so, however. > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Jan 14 07:44:59 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A53EE1A0076 for ; Thu, 14 Jan 2016 07:44:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0bLfYhO-o2d for ; Thu, 14 Jan 2016 07:44:56 -0800 (PST) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C1781A0062 for ; Thu, 14 Jan 2016 07:44:55 -0800 (PST) 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 u0EFiteZ027400; Thu, 14 Jan 2016 09:44:55 -0600 Received: from XCH-BLV-501.nw.nos.boeing.com (xch-blv-501.nw.nos.boeing.com [130.247.25.190]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u0EFilcv027363 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 14 Jan 2016 09:44:47 -0600 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.52]) by XCH-BLV-501.nw.nos.boeing.com ([169.254.1.120]) with mapi id 14.03.0235.001; Thu, 14 Jan 2016 07:44:46 -0800 From: "Templin, Fred L" To: Lorenzo Colitti , Gert Doering Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt Thread-Index: AQHRTsm5rBJl7bbOOkulVVfNz2tye577kJKA//+VaJA= Date: Thu, 14 Jan 2016 15:44:45 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832FA7487@XCH-BLV-504.nw.nos.boeing.com> References: <568FAA3B.3050108@gmail.com> <5690A640.1020009@isi.edu> <20160113072951.GG58491@Space.Net> <20160113075656.GI58491@Space.Net> <56969FA1.9020606@gmail.com> <20160114124727.GW58491@Space.Net> 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: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 15:44:57 -0000 SGkgTG9yZW56bywNCg0KPiBUaGUgY29zdCBpbiB0ZXJtcyBvZiByb3V0aW5nIHNsb3RzIGlzIHRo ZSBzYW1lIGFzIElQdjQuIEp1c3QgYXMgeW91IGRvbid0IHB1dCB0aGUgSVB2NCAvMzJzIG9mIGlu ZGl2aWR1YWwgaG9zdHMgaW4geW91ciBJR1AsIGJ1dCBpbnN0ZWFkIHJvdXRlIGFnZ3JlZ2F0ZXMg KC8yNCwgLzIxLCA+IHdoYXRldmVyKSwgeW91IHdvdWxkbid0IHB1dCB0aGUgSVB2NiAvNjRzIG9m IGluZGl2aWR1YWwgaG9zdHMgaW4gdGhlIElHUCwgYnV0IHdvdWxkIGluc3RlYWQgcm91dGUgYWdn cmVnYXRlcyBvZiBjb3JyZXNwb25kaW5nIHNpemUuDQoNClRoYXQgaXMgcGVyIG15IHJlcGx5IHRv IEdlcnQgYW5kIGFsc28gYXMgZG9jdW1lbnRlZCBpbiBBRVJPLiBDYWxsIGl0ICJzY2FsYWJsZSBk ZS1hZ2dyZWdhdGlvbiIsDQphbmQgaXQgc2hvdWxkIGJlIE9LLCBlLmcuLCB0byBzZXJ2aWNlIDRC IC82NHMgdGFrZW4gZnJvbSBhIC8zMi4gTWFuYWdpbmcgcm91dGluZyBmb3IgNEIgbW9iaWxlDQpu b2RlcyBuZWVkIG5vdCBpbXBhY3QgdGhlIElHUCwgd2hlcmUgb25seSB0aGUgLzMyIG9yIGEgZmV3 IHNsaWdodGx5IGxvbmdlciBwcmVmaXhlcyBuZWVkIHRvDQpiZSBhZHZlcnRpc2VkLg0KDQpUaGFu a3MgLSBGcmVkDQpmcmVkLmwudGVtcGxpbkBib2VpbmcuY29tDQo= From nobody Thu Jan 14 07:46:39 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB2AB1A009B for ; Thu, 14 Jan 2016 07:46:36 -0800 (PST) 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, HTML_MESSAGE=0.001, 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 DEw8D_XLZJq6 for ; Thu, 14 Jan 2016 07:46:29 -0800 (PST) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B51831A009C for ; Thu, 14 Jan 2016 07:46:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u0EFkTiL015898; Thu, 14 Jan 2016 08:46:29 -0700 Received: from XCH-PHX-213.sw.nos.boeing.com (xch-phx-213.sw.nos.boeing.com [130.247.25.142]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u0EFkRkR015772 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 14 Jan 2016 08:46:28 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.52]) by XCH-PHX-213.sw.nos.boeing.com ([169.254.13.191]) with mapi id 14.03.0235.001; Thu, 14 Jan 2016 07:46:26 -0800 From: "Templin, Fred L" To: Lorenzo Colitti , Gert Doering Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt Thread-Index: AQHRTsm5rBJl7bbOOkulVVfNz2tye577kJKAgAAAdYD//5PREA== Date: Thu, 14 Jan 2016 15:46:26 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832FA749E@XCH-BLV-504.nw.nos.boeing.com> References: <568FAA3B.3050108@gmail.com> <5690A640.1020009@isi.edu> <20160113072951.GG58491@Space.Net> <20160113075656.GI58491@Space.Net> <56969FA1.9020606@gmail.com> <20160114124727.GW58491@Space.Net> 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: multipart/alternative; boundary="_000_2134F8430051B64F815C691A62D9831832FA749EXCHBLV504nwnosb_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 15:46:37 -0000 --_000_2134F8430051B64F815C691A62D9831832FA749EXCHBLV504nwnosb_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTG9yZW56bywNCg0KSSB3b3VsZCBsaWtlIHRvIHNlZSBpdCBzYXkg4oCcYXQgbGVhc3QgYSAv NjTigJ0uIEZvciBleGFtcGxlLCBob3N0cyB3aXRoIHZlcnkgY29tcGxleA0KaW50ZXJuYWwgdmly dHVhbCBuZXR3b3JrcyBtaWdodCB3YW50IHRvIHByb2N1cmUgYSAvNjAsIC81NiwgZXRjLg0KDQpU aGFua3Mg4oCTIEZyZWQNCmZyZWQubC50ZW1wbGluQGJvZWluZy5jb20NCg0KRnJvbTogdjZvcHMg W21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTG9yZW56byBDb2xp dHRpDQpTZW50OiBUaHVyc2RheSwgSmFudWFyeSAxNCwgMjAxNiA2OjAzIEFNDQpUbzogR2VydCBE b2VyaW5nDQpDYzogdjZvcHNAaWV0Zi5vcmcgV0cNClN1YmplY3Q6IFJlOiBbdjZvcHNdIEktRCBB Y3Rpb246IGRyYWZ0LWlldGYtdjZvcHMtaG9zdC1hZGRyLWF2YWlsYWJpbGl0eS0wNC50eHQNCg0K T24gVGh1LCBKYW4gMTQsIDIwMTYgYXQgMTE6MDEgUE0sIExvcmVuem8gQ29saXR0aSA8bG9yZW56 b0Bnb29nbGUuY29tPG1haWx0bzpsb3JlbnpvQGdvb2dsZS5jb20+PiB3cm90ZToNCk9uIFRodSwg SmFuIDE0LCAyMDE2IGF0IDk6NDcgUE0sIEdlcnQgRG9lcmluZyA8Z2VydEBzcGFjZS5uZXQ8bWFp bHRvOmdlcnRAc3BhY2UubmV0Pj4gd3JvdGU6DQpOb3cgdGhlIHJlbWFpbmluZyBxdWVzdGlvbiBp cywgb2YgY291cnNlLCB3aHkgdGhlIHJlY29tbWVuZGF0aW9uIGlzIGZvcg0KYSAvNjQgcGVyIGhv c3QuICAgV2h5IG5vdCBhIC82MCwgb3IgYSAvOTY/DQoNCkEgLzY0IGlzIHJlY29tbWVuZGVkIGJl Y2F1c2UgcHJlZml4ZXMgbG9uZ2VyIHRoYW4gLzY0IGFyZSBvdXRzaWRlIHRoZSBJUHY2IHNwZWNp ZmljYXRpb25zDQoNCkZvcmdvdCB0byBtZW50aW9uOiB5ZXMsIHRoZSBkcmFmdCBjb3VsZCBiZSB1 cGRhdGVkIHRvIHNheSAiYXQgbGVhc3QgYSAvNjQiIGluc3RlYWQgb2YgImEgLzY0Ii4gV2UgZGlk IG5vdCBzZWUgYW55IG5lZWQgdG8gZG8gc28sIGhvd2V2ZXIuDQo= --_000_2134F8430051B64F815C691A62D9831832FA749EXCHBLV504nwnosb_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgTG9y ZW56byw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgd291bGQg bGlrZSB0byBzZWUgaXQgc2F5IOKAnGF0IGxlYXN0IGEgLzY04oCdLiBGb3IgZXhhbXBsZSwgaG9z dHMgd2l0aCB2ZXJ5IGNvbXBsZXg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+aW50ZXJuYWwgdmlydHVhbCBu ZXR3b3JrcyBtaWdodCB3YW50IHRvIHByb2N1cmUgYSAvNjAsIC81NiwgZXRjLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIOKAkyBGcmVkPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPmZyZWQubC50ZW1wbGluQGJvZWluZy5jb208bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiB2Nm9wcyBbbWFp bHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkxvcmVuem8g Q29saXR0aTxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSmFudWFyeSAxNCwgMjAxNiA2OjAz IEFNPGJyPg0KPGI+VG86PC9iPiBHZXJ0IERvZXJpbmc8YnI+DQo8Yj5DYzo8L2I+IHY2b3BzQGll dGYub3JnIFdHPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246IGRy YWZ0LWlldGYtdjZvcHMtaG9zdC1hZGRyLWF2YWlsYWJpbGl0eS0wNC50eHQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biBUaHUsIEphbiAxNCwgMjAxNiBhdCAxMTowMSBQTSwgTG9yZW56byBDb2xpdHRpICZsdDs8YSBo cmVmPSJtYWlsdG86bG9yZW56b0Bnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+bG9yZW56b0Bn b29nbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgSmFuIDE0LCAyMDE2IGF0IDk6NDcgUE0sIEdlcnQg RG9lcmluZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdlcnRAc3BhY2UubmV0IiB0YXJnZXQ9Il9ibGFu ayI+Z2VydEBzcGFjZS5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Tm93IHRoZSByZW1haW5pbmcgcXVlc3Rpb24gaXMsIG9mIGNvdXJzZSwgd2h5IHRoZSBy ZWNvbW1lbmRhdGlvbiBpcyBmb3I8YnI+DQphIC82NCBwZXIgaG9zdC4mbmJzcDsgJm5ic3A7V2h5 IG5vdCBhIC82MCwgb3IgYSAvOTY/PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BIC82NCBpcyByZWNvbW1lbmRlZCBiZWNhdXNlIHBy ZWZpeGVzIGxvbmdlciB0aGFuIC82NCBhcmUgb3V0c2lkZSB0aGUgSVB2NiBzcGVjaWZpY2F0aW9u czxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3Jnb3QgdG8gbWVudGlvbjog eWVzLCB0aGUgZHJhZnQgY291bGQgYmUgdXBkYXRlZCB0byBzYXkgJnF1b3Q7YXQgbGVhc3QgYSAv NjQmcXVvdDsgaW5zdGVhZCBvZiAmcXVvdDthIC82NCZxdW90Oy4gV2UgZGlkIG5vdCBzZWUgYW55 IG5lZWQgdG8gZG8gc28sIGhvd2V2ZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_2134F8430051B64F815C691A62D9831832FA749EXCHBLV504nwnosb_-- From nobody Thu Jan 14 07:54:22 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 035801A0231 for ; Thu, 14 Jan 2016 07:54:21 -0800 (PST) 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, 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 bm5hUaONVfpK for ; Thu, 14 Jan 2016 07:54:19 -0800 (PST) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B0CA1A014D for ; Thu, 14 Jan 2016 07:54:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u0EFsIiR031939; Thu, 14 Jan 2016 08:54:18 -0700 Received: from XCH-BLV-406.nw.nos.boeing.com (xch-blv-406.nw.nos.boeing.com [130.247.25.162]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u0EFsBOu031464 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 14 Jan 2016 08:54:12 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.52]) by XCH-BLV-406.nw.nos.boeing.com ([169.254.6.72]) with mapi id 14.03.0235.001; Thu, 14 Jan 2016 07:54:11 -0800 From: "Templin, Fred L" To: Alexandre Petrescu , "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt Thread-Index: AQHRTuPOIURUB1r0/06taHPsKrc92Q== Date: Thu, 14 Jan 2016 15:54:10 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832FA74C6@XCH-BLV-504.nw.nos.boeing.com> References: <568D1854.7000300@gmail.com> <568FAA3B.3050108@gmail.com> <5690A640.1020009@isi.edu> <20160113072951.GG58491@Space.Net> <20160113075656.GI58491@Space.Net> <569612A1.7050603@gmail.com> <2134F8430051B64F815C691A62D9831832FA6B3E@XCH-BLV-504.nw.nos.boeing.com> <5697AB85.9040001@gmail.com> In-Reply-To: <5697AB85.9040001@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 15:54:21 -0000 Hi Alex, > -----Original Message----- > From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] > Sent: Thursday, January 14, 2016 6:07 AM > To: Templin, Fred L; v6ops@ietf.org > Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-= 04.txt >=20 > Hi Fred, >=20 > Le 13/01/2016 18:52, Templin, Fred L a =E9crit : > > Hi Alex, > > > >> -----Original Message----- From: v6ops > >> [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandre Petrescu > >> Sent: Wednesday, January 13, 2016 1:02 AM To: v6ops@ietf.org > >> Subject: Re: [v6ops] I-D Action: > >> draft-ietf-v6ops-host-addr-availability-04.txt > >> > >> > >> > >> Le 13/01/2016 08:56, Gert Doering a =E9crit : > >>> Hi, > >>> > >>> On Wed, Jan 13, 2016 at 04:45:22PM +0900, Erik Kline wrote: > >>>> Nothing in Section 8 ("Recommendations") recommends DHCPv6-PD. > >>>> At best it says at one point "e.g., via DHCPv6 PD" and > >>>> certainly never elevates PD above any other solution. > >>> > >>> "it is RECOMMENDED that the network assign a /64 prefix to every > >>> host (e.g., via DHCPv6 PD)." > >>> > >>> since there is no other mechanism that could do this, > >> > >> Right, there is no other Stds Track RFC that could do this (other > >> than DHCP-PD), but there is Prefix Delegation extension to ND > >> protocol - an individual Internet Draft: > >> https://tools.ietf.org/html/draft-kaiser-nd-pd-02 > > > > What would be the operational advantage for an ND-based prefix > > delegation extension? >=20 > The operational advantage would be related to performing software > implementations. I'm not sure what you mean by that but, taking the AERO implementation for example, the code to do DHCPv6 PD is no more performance-intensive than that to do IPv6 ND messaging. In fact, the DHCPv6 PD client can be written in about 1k lines of code. > > AFAICT, it would require either new messages or extensions to > > existing messages, and would still need to manage some sort of lease > > database and the routing system. The draft indicated that it could > > provide a "faster and less resource consuming way", but I don't see > > how it could get around managing the same sort of state as for DHCPv6 > > nor how the message exchanges could be made more efficient? >=20 > Less resource consuming on the UE mainly (the "Host")- because it would > be small extensions of existing software (ND parts in kernel and > userspace), rather than adding new software suite (DHCPv6 daemon in > userspace). This is relevant in some UE chipsets allowing only 150mb > free ram after the ND parts are already there. If you open up the kernel to hack it, you might just as well insert DHCPv6 = PD messaging - there is no law that says the client has to be implemented as a user level daemon. > Indeed state must be managed at ND server (DHCP Server equivalent). But > that is a large computer in the network - it can afford much memory and > fast clock. Right; same as for DHCPv6 server. > The message exchange can be more efficient because ND typically involves > 2 messages (Solicitation/Advertisement) whereas DHCP typically involves > 4 messages (Solicit/Advertize/Request/Response) although exceptions exist= . AERo uses the 2-message exchange option for DHCPv6 PD. Thanks - Fred fred.l.templin@boeing.com > Yours, >=20 > Alex >=20 > > > > Thanks - Fred fred.l.templin@boeing.com > > > >> Alex > >> > >> > >>> argueing that this would *not* be recommending DHCPv6-PD is a bit > >>> weird. > >>> > >>> But if this is not about recommending DHCPv6-PD, and it's just an > >>> example, I would be happy to see that "(e.g. via DHCPv6 PD)" > >>> clause go away, and also remove all references to "DHCPv6 PD" in > >>> 9.3 - keeping the discussion about the routing model as > >>> alternative to burdening the ND layer is fine, but if you don't > >>> want to recommend DHCPv6 PD, then don't mention it as a > >>> particular technology. > >>> > >>> Gert Doering -- NetMaster > >>> > >>> > >>> > >>> _______________________________________________ v6ops mailing > >>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > >>> > >> > >> _______________________________________________ v6ops mailing list > >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From nobody Fri Jan 15 14:29:33 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC191B333F for ; Fri, 15 Jan 2016 14:29:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, 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 e975F_JihW7n for ; Fri, 15 Jan 2016 14:29:30 -0800 (PST) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.119.220]) by ietfa.amsl.com (Postfix) with ESMTP id D1FC51B3339 for ; Fri, 15 Jan 2016 14:29:29 -0800 (PST) Received: from mail-pf0-f174.google.com (mail-pf0-f174.google.com [209.85.192.174]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128/128); for ; Fri, 15 Jan 2016 16:29:28 -0600 (CST) X-Umn-Remote-Mta: [N] mail-pf0-f174.google.com [209.85.192.174] #+LO+TS+TR X-Umn-Classification: local Received: by mail-pf0-f174.google.com with SMTP id n128so124157813pfn.3 for ; Fri, 15 Jan 2016 14:29:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to; bh=c7mJbeo7lLZuMW0e0SmLqm+0FqFGWaFLww+0hEOrjlg=; b=go8s9PqEEJn6pG0oyPYzX8PIss5CS1QybHQgZoKxzTyjKrCRbc5Mp0QgJRULyUwqpf odODwC0YLfThy4w7OP/LK8qqxIdEz+Dyr5TM0sZ9RoFKZjBJIPib0ojnqZC3pzXpBKNk XS7N1SDVNqk2a2k2kxEqXHFCWBfX9m343w4fA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:in-reply-to:mime-version:content-type :message-id:content-transfer-encoding:cc:from:subject:date:to; bh=c7mJbeo7lLZuMW0e0SmLqm+0FqFGWaFLww+0hEOrjlg=; b=Cgin7dq5nbHd+z2yi4g/QkgD7M9Sy1jq0U6FBeDfgay5PnH8Cbf5yhCet5jQoAJ/A/ DSaeKx+vDDMRVDuCIqjs7vczrpR1GUQTPlzL8EOPIjv/+JhL2eYMUg10cE7njUImR4jm ekTxlfRJZ0cKXrL6quCH5XBPefDoZ/rSeE3aCr/8T0COrioeH+IRhj4eqzen5fzu2Hka 7lACFd80sPpVHDk7Ku5BP71R8fbyp3psw1tS3NoIK9ZKAkJ6Le0a88LTBGL18G1CczI3 ZuUJFeFUvMLWFEUXc6E7QOmFP8UY8al15+sEiXjJ2QiwHqFscO/7XCb0QRt0j376syEm odnA== X-Gm-Message-State: ALoCoQnUVhQoLcvmKxi90Dw2boDBPK1OsTTWmVMr6QVT82XsGbf4dT9letLP3Wk6x+Sx7RJUZZP9bJkJm8JfUOQCJHwzybcOz9/hsYnVuGZa0Sn5wXYUDphlS5HH2NiKttH+qV8L8/23KrlOCMJ+PRl7jt/Fa+1LcQ== X-Received: by 10.98.67.135 with SMTP id l7mr18499053pfi.148.1452896967958; Fri, 15 Jan 2016 14:29:27 -0800 (PST) X-Received: by 10.98.67.135 with SMTP id l7mr18499041pfi.148.1452896967818; Fri, 15 Jan 2016 14:29:27 -0800 (PST) Received: from [10.104.133.131] (x-131-212-250-173.uofm-secure.wireless.umn.edu. [131.212.250.173]) by smtp.gmail.com with ESMTPSA id k74sm17624134pfb.30.2016.01.15.14.29.25 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Jan 2016 14:29:25 -0800 (PST) References: <568FAA3B.3050108@gmail.com> <5690A640.1020009@isi.edu> <20160113072951.GG58491@Space.Net> <20160113075656.GI58491@Space.Net> <56969FA1.9020606@gmail.com> <20160114124727.GW58491@Space.Net> <5697B0F5.3050608@gmail.com> In-Reply-To: <5697B0F5.3050608@gmail.com> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=utf-8 Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (13C75) From: David Farmer Date: Fri, 15 Jan 2016 16:29:24 -0600 To: Alexandre Petrescu Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 22:29:31 -0000 I agree a prefix length shorter than /64 can sometimes be useful, but it is n= ot always necessary, and it is probably not necessary even most of the time f= or the situation under consideration in this draft. Specifying that a /63 s= hould always be assigned would be wasteful in many, if not most situations, a= nd is therefore not acceptable to me.=20 Furthermore, while IIDs shorter 64 bits or prefixes longer than /64 are allo= wed by the IPv6 architecture and therefore theoretically possible, there is n= o current specification providing for such prefixes, other than RFC6164 for /= 127 point to point router links. Making a new exception and specifying pref= ixes longer than /64 is not within the scope of this document. So, the current recommendation of "a /64 prefix" is the proper recommendatio= n in my opinion, adding "or a shorter prefix if requested" would be a small i= mprovement. Assigning more than a /64 without an explicit request seems was= teful to me for an individual host. An actual site, even a home, is another= thing, but that not the situation considered in this draft. > On Jan 14, 2016, at 08:30, Alexandre Petrescu wrote: >=20 > at least _one_ /64? (i.e. better would _two_ distinct /64s) >=20 > or plen value at least 64? (i.e. better would be 63) >=20 > Alex >=20 > Le 14/01/2016 15:02, Lorenzo Colitti a =C3=A9crit : >> On Thu, Jan 14, 2016 at 11:01 PM, Lorenzo Colitti > > wrote: >>=20 >> On Thu, Jan 14, 2016 at 9:47 PM, Gert Doering > > wrote: >>=20 >> Now the remaining question is, of course, why the recommendation >> is for >> a /64 per host. Why not a /60, or a /96? >>=20 >>=20 >> A /64 is recommended because prefixes longer than /64 are outside >> the IPv6 specifications >>=20 >>=20 >> Forgot to mention: yes, the draft could be updated to say "at least a >> /64" instead of "a /64". We did not see any need to do so, however. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota =20 2218 University Ave SE Phone: +1-612-626-0815 Minneapolis, MN 55414-3029 Cell: +1-612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From nobody Sat Jan 16 13:37:16 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2E681ACC72 for ; Sat, 16 Jan 2016 13:37:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.202 X-Spam-Level: * X-Spam-Status: No, score=1.202 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkzDpGWYaGaL for ; Sat, 16 Jan 2016 13:37:13 -0800 (PST) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B792F1ACAD5 for ; Sat, 16 Jan 2016 13:37:12 -0800 (PST) Received: by mail-vk0-x22c.google.com with SMTP id n1so160742090vkb.3 for ; Sat, 16 Jan 2016 13:37:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=liXY2ysk4dyDk9xSIFGXVOOA5qArq6EnongGwFll+4M=; b=ijtw7ritke7diws9PdppTr8U1CdhKDEGYVHWeVOVYLxIzP/7Lxa0pwhYuPgNbSMuIm 53I0F3yxSrAlLGwWcEM9z/OuSD2L+07XSavp5hHH401ZLHYRlTXQagcGrC8x9/FxbrCQ 9zeyyA78UK3nGp7wtxl9ThQnsst1KmjXwdReo5eXm1CJPJnowe149j7eQMfPUvmIaApl 1M4oEwN6mjIMLQtXyoE19B2gaR1VXLaNDizvEtJ4ltVdTlMLB/ugGU84NY0KdW1cNsA1 hZu3i27YCwCLhUONUHABmJGVRKWEtwBQo0hLgbcy+5I0KcToAfQ40phBU17HsnAjwikN 8dfA== 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=liXY2ysk4dyDk9xSIFGXVOOA5qArq6EnongGwFll+4M=; b=Y2Kw6Bm9rkt/VSeqVlaSzVZUjVqMe3M/zB4sixql859Ojj11mpICDNxuT/OCxGqRwx 8TCo9uZR6rn1ta/37OdoX9qBcNCM4L7cdMxFFs5O1enoOyqUdMh8ahxhWWLYD7XMED2b 61B4DEQVRc3qeGY0uyiH+4x4xrYO3bezW9tOoV05ZN9KEgRa3VoD8J06OuBlxbGaajBM dfPyy2GWi8i2FODxIDtPI7bvvIkZfbraLZ0qH/rLOl+BuRDt9iCTVGC+DS69p54ma1Q8 UJ9bHESc95JWJqzm7NBQ9uFh8J+AnhmCF0bHxq7ZxvvaN85UdlQ6mTdGOFZxJQ/wn3qv EJGg== X-Gm-Message-State: ALoCoQnFMjAFrNygY81brzSwTJOBgnIzPIUkYaIcj872bxauWX2isEf0BBHYhDbNkIJFO+EkHEQrrKEpphR8aqKTe9yM90/TpQ== MIME-Version: 1.0 X-Received: by 10.31.15.4 with SMTP id 4mr11439650vkp.10.1452980231880; Sat, 16 Jan 2016 13:37:11 -0800 (PST) Received: by 10.103.99.1 with HTTP; Sat, 16 Jan 2016 13:37:11 -0800 (PST) Received: by 10.103.99.1 with HTTP; Sat, 16 Jan 2016 13:37:11 -0800 (PST) In-Reply-To: References: <568FAA3B.3050108@gmail.com> <5690A640.1020009@isi.edu> <20160113072951.GG58491@Space.Net> <20160113075656.GI58491@Space.Net> <56969FA1.9020606@gmail.com> <20160114124727.GW58491@Space.Net> <5697B0F5.3050608@gmail.com> Date: Sun, 17 Jan 2016 08:37:11 +1100 Message-ID: From: Mark Smith To: David Farmer Content-Type: multipart/alternative; boundary=001a11433da89646a105297a5224 Archived-At: Cc: v6ops list Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2016 21:37:15 -0000 --001a11433da89646a105297a5224 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 16 Jan 2016 09:29, "David Farmer" wrote: > > I agree a prefix length shorter than /64 can sometimes be useful, but it is not always necessary, and it is probably not necessary even most of the time for the situation under consideration in this draft. Specifying that a /63 should always be assigned would be wasteful in many, if not most situations, and is therefore not acceptable to me. > > Furthermore, while IIDs shorter 64 bits or prefixes longer than /64 are allowed by the IPv6 architecture and therefore theoretically possible, there is no current specification providing for such prefixes, other than RFC6164 for /127 point to point router links. Making a new exception and specifying prefixes longer than /64 is not within the scope of this document. > > So, the current recommendation of "a /64 prefix" is the proper recommendation in my opinion, adding "or a shorter prefix if requested" would be a small improvement. Assigning more than a /64 without an explicit request seems wasteful to me for an individual host. An actual site, even a home, is another thing, but that not the situation considered in this draft. > +1 We don't need to constantly demonstrate that prefix lengths other than /64s are supported by constantly not using /64s. We try to provide flexibility but we also try to provide default parameter values that work for most cases. Not providing common case defaults would create too many decisions to make for the operators of these protocols. Most would use what others are using, so conventions would arise over time. Providing reasonable defaults is providing automated expected conventions. I can't think of anything close to a common case where a host would need more than a /64 of addresses for its own application use. If there are any obscure ones, it can be facilitated with a multiple /64 delegated prefix using DHCPv6-PD, which the host would then turn into flat space for its own use. > > On Jan 14, 2016, at 08:30, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > > > > at least _one_ /64? (i.e. better would _two_ distinct /64s) > > > > or plen value at least 64? (i.e. better would be 63) > > > > Alex > > > > Le 14/01/2016 15:02, Lorenzo Colitti a =C3=A9crit : > >> On Thu, Jan 14, 2016 at 11:01 PM, Lorenzo Colitti >> > wrote: > >> > >> On Thu, Jan 14, 2016 at 9:47 PM, Gert Doering >> > wrote: > >> > >> Now the remaining question is, of course, why the recommendatio= n > >> is for > >> a /64 per host. Why not a /60, or a /96? > >> > >> > >> A /64 is recommended because prefixes longer than /64 are outside > >> the IPv6 specifications > >> > >> > >> Forgot to mention: yes, the draft could be updated to say "at least a > >> /64" instead of "a /64". We did not see any need to do so, however. > > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > David Farmer Email: farmer@umn.edu > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: +1-612-626-0815 > Minneapolis, MN 55414-3029 Cell: +1-612-812-9952 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --001a11433da89646a105297a5224 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 16 Jan 2016 09:29, "David Farmer" <farmer@umn.edu> wrote:
>
> I agree a prefix length shorter than /64 can sometimes be useful, but = it is not always necessary, and it is probably not necessary even most of t= he time for the situation under consideration in this draft.=C2=A0 Specifyi= ng that a /63 should always be assigned would be wasteful in many, if not m= ost situations, and is therefore not acceptable to me.
>
> Furthermore, while IIDs shorter 64 bits or prefixes longer than /64 ar= e allowed by the IPv6 architecture and therefore theoretically possible, th= ere is no current specification providing for such prefixes, other than RFC= 6164 for /127 point to point router links.=C2=A0 Making a new exception and= specifying prefixes longer than /64 is not within the scope of this docume= nt.
>
> So, the current recommendation of "a /64 prefix" is the prop= er recommendation in my opinion, adding "or a shorter prefix if reques= ted" would be a small improvement.=C2=A0 Assigning more than a /64 wit= hout an explicit request seems wasteful to me for an individual host.=C2=A0= An actual site, even a home, is another thing, but that not the situation = considered in this draft.
>

+1

We don't need to constantly demonstrate that prefix leng= ths other than /64s are supported by constantly not using /64s.

We try to provide flexibility but we also try to provide def= ault parameter values that work for most cases. Not providing common case d= efaults would create too many decisions to make for the operators of these = protocols. Most would use what others are using, so conventions would arise= over time. Providing reasonable defaults is providing automated expected c= onventions.

I can't think of anything close to a common case where a= host would need more than a /64 of addresses for its own application use. = If there are any obscure ones, it can be facilitated with a multiple /64 de= legated prefix using DHCPv6-PD, which the host would then turn into flat sp= ace for its own use.

> > On Jan 14, 2016, at 08:30, Alexandre Petrescu <= alexandre.petrescu@gmail.co= m> wrote:
> >
> > at least _one_ /64? (i.e. better would _two_ distinct /64s)
> >
> > or plen value at least 64? (i.e. better would be 63)
> >
> > Alex
> >
> > Le 14/01/2016 15:02, Lorenzo Colitti a =C3=A9crit :
> >> On Thu, Jan 14, 2016 at 11:01 PM, Lorenzo Colitti <lorenzo@google.com
> >> <mailto:lorenzo@goog= le.com>> wrote:
> >>
> >>=C2=A0 =C2=A0 On Thu, Jan 14, 2016 at 9:47 PM, Gert Doering &l= t;gert@space.net
> >>=C2=A0 =C2=A0 <mailto:ger= t@space.net>> wrote:
> >>
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Now the remaining question is, of = course, why the recommendation
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 is for
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 a /64 per host.=C2=A0 =C2=A0Why no= t a /60, or a /96?
> >>
> >>
> >>=C2=A0 =C2=A0 A /64 is recommended because prefixes longer tha= n /64 are outside
> >>=C2=A0 =C2=A0 the IPv6 specifications
> >>
> >>
> >> Forgot to mention: yes, the draft could be updated to say &qu= ot;at least a
> >> /64" instead of "a /64". We did not see any ne= ed to do so, however.
>
> --
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > David Farmer=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 Email: farmer@umn.edu
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Phone: +1-612-= 626-0815
> Minneapolis, MN 55414-3029=C2=A0 =C2=A0Cell: +1-612-812-9952
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--001a11433da89646a105297a5224-- From nobody Tue Jan 19 09:10:42 2016 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8811B32B0; Tue, 19 Jan 2016 09:10:41 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.12.1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160119171041.10006.41496.idtracker@ietfa.amsl.com> Date: Tue, 19 Jan 2016 09:10:41 -0800 Archived-At: Cc: v6ops@ietf.org, draft-ietf-v6ops-ipv6-ehs-in-real-world@ietf.org, v6ops-chairs@ietf.org, draft-ietf-v6ops-ipv6-ehs-in-real-world.all@tools.ietf.org, joelja@gmail.com Subject: [v6ops] Last Call: (Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 17:10:41 -0000 The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-02-02. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document presents real-world data regarding the extent to which packets with IPv6 extension headers are dropped in the Internet (as originally measured in August 2014 and later in June 2015, with similar results), and where in the network such dropping occurs. The aforementioned results serve as a problem statement that is expected to trigger operational advice on the filtering of IPv6 packets carrying IPv6 Extension Headers, so that the situation improves over time. This document also explains how the aforementioned results were obtained, such that the corresponding measurements can be reproduced by other members of the community and repeated over time to observe changes in the handling of packets with IPv6 extension headers. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-ehs-in-real-world/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-ehs-in-real-world/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Jan 22 10:51:34 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2BAB1B2BE7; Fri, 22 Jan 2016 10:51:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.903 X-Spam-Level: X-Spam-Status: No, score=-106.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 Wy6A2spuofSC; Fri, 22 Jan 2016 10:51:31 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 6836A1AD36B; Fri, 22 Jan 2016 10:51:31 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 0F208180206; Fri, 22 Jan 2016 10:50:13 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20160122185013.0F208180206@rfc-editor.org> Date: Fri, 22 Jan 2016 10:50:13 -0800 (PST) Archived-At: Cc: v6ops@ietf.org, rfc-editor@rfc-editor.org Subject: [v6ops] RFC 7690 on Close Encounters of the ICMP Type 2 Kind (Near Misses with ICMPv6 Packet Too Big (PTB)) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 18:51:32 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7690 Title: Close Encounters of the ICMP Type 2 Kind (Near Misses with ICMPv6 Packet Too Big (PTB)) Author: M. Byerly, M. Hite, J. Jaeggli Status: Informational Stream: IETF Date: January 2016 Mailbox: suckawha@gmail.com, mhite@hotmail.com, joelja@gmail.com Pages: 9 Characters: 19061 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-pmtud-ecmp-problem-06.txt URL: https://www.rfc-editor.org/info/rfc7690 DOI: http://dx.doi.org/10.17487/RFC7690 This document calls attention to the problem of delivering ICMPv6 type 2 "Packet Too Big" (PTB) messages to the intended destination (typically the server) in ECMP load-balanced or anycast network architectures. It discusses operational mitigations that can be employed to address this class of failures. This document is a product of the IPv6 Operations Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Sun Jan 31 11:00:08 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 575AB1B2BDA for ; Sun, 31 Jan 2016 11:00:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.802 X-Spam-Level: X-Spam-Status: No, score=-111.802 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, 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 Wn_vaDOcUBfA for ; Sun, 31 Jan 2016 11:00:06 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE96D1B2BD8 for ; Sun, 31 Jan 2016 11:00:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=371; q=dns/txt; s=iport; t=1454266805; x=1455476405; h=date:from:message-id:to:subject; bh=1qvgVpC0Ghebhdeq5FR3ZUsdLmgbpjcQRX1Ew+AYzRU=; b=iCR+a06BG+snn2PRxeEmiTD8beJgBWPTt+WluzHPQLtPpBxpCC28mty4 DyoywNQb81T4oJnpYqMPm5VnHFvd0kqgdzLg0XzxEi9ie0o6KDWW9mEcF xxaOo6ndY9adjUfBtOR+8lekgug4XSIbXCxtaDgj+C1TSHLzCP0TjQTQV s=; X-IronPort-AV: E=Sophos;i="5.22,376,1449532800"; d="scan'208";a="233255666" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Jan 2016 19:00:04 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u0VJ03Eo012479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 31 Jan 2016 19:00:04 GMT Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id u0VJ025d011205; Sun, 31 Jan 2016 11:00:03 -0800 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id u0VJ02AT011204; Sun, 31 Jan 2016 11:00:02 -0800 Date: Sun, 31 Jan 2016 11:00:02 -0800 From: fred@cisco.com Message-Id: <201601311900.u0VJ02AT011204@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Subject: [v6ops] Focused discussion: draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2016 19:00:07 -0000 We seem to have been fairly successful getting focused discussion in January. I'd like to try this one more time before IETF 95. Could we all read draft-gont-v6ops-ipv6-ehs-packet-drops and comment on it? Andrew Yourtchenko reviewed it on January 11, and there was a breif discussion between him, Fernando, and Brian Carpenter. Are there other opinions out there? From nobody Sun Jan 31 12:35:41 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBF61B2CB9 for ; Sun, 31 Jan 2016 12:35:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.094 X-Spam-Level: X-Spam-Status: No, score=0.094 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_NL=0.55, HOST_EQ_NL=1.545, 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 KNtekrnkvzST for ; Sun, 31 Jan 2016 12:35:37 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79FEF1A88B6 for ; Sun, 31 Jan 2016 12:35:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 069E14E for ; Sun, 31 Jan 2016 21:35:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:date:date:in-reply-to:from:from :subject:subject:mime-version:content-type:content-type:received :received; s=mail; t=1454272533; bh=nA5DgDgHHczSE2lllg0zt6QujM5P BJc6e4GW2QPoxIY=; b=ktbE/V/l6umsRWcZS75+lFaYuMJcJoSschfEaf1F9CFf LCqABnlg5i6//FI4WZ+xZWGg4bQQZP9UIWe3i+JuKXDT6WhMdOfJQgs1WtHghj4p U0b4QmA1HoUf8TwcMxZUzYNaE66jP/LoFsONw/Zqz3EUt4lyo06vSiQAfMg08t8= X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 9rvELzJ-ak4B for ; Sun, 31 Jan 2016 21:35:33 +0100 (CET) Received: from [IPv6:2a00:8640:1::8de8:96cd:7a10:b9ed] (unknown [IPv6:2a00:8640:1:0:8de8:96cd:7a10:b9ed]) by mail.sintact.nl (Postfix) with ESMTPSA id 31FB84A for ; Sun, 31 Jan 2016 21:35:32 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_05967C4B-CC9B-4A4C-97AA-7F49968C247E"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Pgp-Agent: GPGMail 2.6b2 X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann In-Reply-To: <201601311900.u0VJ02AT011204@irp-lnx1.cisco.com> Date: Sun, 31 Jan 2016 21:35:32 +0100 Message-Id: References: <201601311900.u0VJ02AT011204@irp-lnx1.cisco.com> To: v6ops list X-Mailer: Apple Mail (2.3112) Archived-At: Subject: Re: [v6ops] Focused discussion: draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2016 20:35:39 -0000 --Apple-Mail=_05967C4B-CC9B-4A4C-97AA-7F49968C247E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, > We seem to have been fairly successful getting focused discussion > in January. I'd like to try this one more time before IETF 95. Could > we all read draft-gont-v6ops-ipv6-ehs-packet-drops and comment on it? > Andrew Yourtchenko reviewed it on January 11, and there was a breif > discussion between him, Fernando, and Brian Carpenter. Are there other > opinions out there? I discussed the draft with Fernando over Skype. Mostly textual stuff and = clarifications feedback. I think it is a very useful draft that = documents the current operational effects of extension headers. Cheers, Sander --Apple-Mail=_05967C4B-CC9B-4A4C-97AA-7F49968C247E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEbBAEBCAAGBQJWrnAUAAoJEKAtA7D+JBO5gUUH+LytEhp3jtYOHFLgCbVuts3y oVvTgIq5eonxImgMGM9S+smWhK7Qi6aXVMUPGDxy+rV0sgfdvTNsKzvG4oq7OBj9 amt0ewkENIPb0jrcHjQX8QeHcjQTrYdDHx8qGonCGo56qlwBxRelsy6p1iVZ2MSX M5fu0LXT5IbNjUGJFRopEbwBbW2lIFA82j1QBXJ//ZLtEIBOKy5vIi5blB+0fQf0 jHdNLscMlesHSQbDQB6Ukok7u1dY7v9nbTJRnTRkWDD04b5wHeyorWFbPNwaD34F 3n10Tdu3mJ0UIF54pjpGMsBCY6dfI6rm+IRongT4G7qt9Cxo2avdfTWUDxjFug== =Ed4l -----END PGP SIGNATURE----- --Apple-Mail=_05967C4B-CC9B-4A4C-97AA-7F49968C247E-- From nobody Sun Jan 31 22:12:30 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A81E1A002D for ; Sun, 31 Jan 2016 22:12:29 -0800 (PST) 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 NgWIHBRab5kW for ; Sun, 31 Jan 2016 22:12:28 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2C261A005A for ; Sun, 31 Jan 2016 22:12:27 -0800 (PST) Received: from mb-2.local ([IPv6:2601:647:4204:51:a8fc:d6dc:8732:faaf]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id u116CN0R021382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 1 Feb 2016 06:12:24 GMT (envelope-from joelja@bogus.com) To: fred@cisco.com, v6ops@ietf.org References: <201601311900.u0VJ02AT011204@irp-lnx1.cisco.com> From: joel jaeggli X-Enigmail-Draft-Status: N1110 Message-ID: <56AEF747.5080400@bogus.com> Date: Sun, 31 Jan 2016 22:12:23 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:44.0) Gecko/20100101 Thunderbird/44.0 MIME-Version: 1.0 In-Reply-To: <201601311900.u0VJ02AT011204@irp-lnx1.cisco.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="T9xfEjpfsOoJBXEL1HqIF0L3IvBKccWEf" Archived-At: Subject: Re: [v6ops] Focused discussion: draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 06:12:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --T9xfEjpfsOoJBXEL1HqIF0L3IvBKccWEf Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 1/31/16 11:00 AM, fred@cisco.com wrote: > We seem to have been fairly successful getting focused discussion > in January. I'd like to try this one more time before IETF 95. Could > we all read draft-gont-v6ops-ipv6-ehs-packet-drops and comment on it? > Andrew Yourtchenko reviewed it on January 11, and there was a breif > discussion between him, Fernando, and Brian Carpenter. Are there other > opinions out there? a Hop-by-Hop Options header will typically go through the slow forwarding path, and be processed by the router's CPU. Sometimes a slow forwarding path is not an option e.g. the options are fast path or no path. in 4.1.2 - https://tools.ietf.org/html/draft-ietf-idr-flow-spec-v6-06 recently experired but as noted any pracactical impelementation of flowspec for v6 would require the ability to parse far enough to find the l4 header. joel > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --T9xfEjpfsOoJBXEL1HqIF0L3IvBKccWEf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlau90cACgkQ8AA1q7Z/VrLiFgCfY+CrnE6ZCuOuhLQRoXSYeX7v 0OIAnjRo4sMc29GPyfXa+ebsY6betFK6 =l7Dg -----END PGP SIGNATURE----- --T9xfEjpfsOoJBXEL1HqIF0L3IvBKccWEf--