From nobody Wed Jul 1 02:35:29 2015 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 4F9951B2B83 for ; Wed, 1 Jul 2015 02:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.937 X-Spam-Level: X-Spam-Status: No, score=0.937 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, 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 MZu4gqe0-zSY for ; Wed, 1 Jul 2015 02:35:16 -0700 (PDT) Received: from ctxmailhub.t-mobile.cz (ctxmailhub.t-mobile.cz [93.153.104.87]) (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 ED69F1B2C05 for ; Wed, 1 Jul 2015 02:35:15 -0700 (PDT) From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Alexandru Petrescu , "holger.metschulat@telekom.de" , "v6ops@ietf.org" Thread-Topic: [v6ops] Apple and IPv6, a few clarifications - 64share Thread-Index: AQHQsm3eGmkYJhNvCEmzMRDqcmE/QJ3GXFmQ Date: Wed, 1 Jul 2015 09:35:09 +0000 Message-ID: References: <5587EFDD.6030807@gmail.com> <558AA4F1.8080503@gmail.com> <88CAA5385EB5404392BF93106C8C53F89620073E87@HE111507.emea1.cds.t-internal.com> <55914517.4050602@gmail.com> In-Reply-To: <55914517.4050602@gmail.com> Accept-Language: en-GB, cs-CZ, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.254.150.191] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Archived-At: Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share 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, 01 Jul 2015 09:35:19 -0000 > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandru > Petrescu > Sent: Monday, June 29, 2015 3:16 PM > To: holger.metschulat@telekom.de; v6ops@ietf.org > Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share > > > > Le 29/06/2015 14:51, holger.metschulat@telekom.de a =E9crit : > The modem and chipsets on LTE that I have tried do forward DHCPv6 > requests. For example it transmits the DHCPv6 Request and then receives = an > DHCPv6 Ack from the cellular network containing an IPv6 address. But if = I > make a DHCPv6 Prefix Delegation request then that is not answered. The current 3GPP specs do not contain DHCPv6 based IPv6 prefix allocation, so I would be surprised by an LTE network doing so. The DHCPv6 server could be run by the dongle and providing that RA provided prefix via DHCPv6 to the host. > I guess that hardware which blocks DHCPv6-PD also blocks DHCPv6. > Otherwise it would be an intentional blocking of DHCPv6-PD... > > Alex Ales Z=E1sady komunikace, kter=E9 spole=E8nost T-Mobile Czech Republic a.s. u=BE= =EDv=E1 p=F8i sjedn=E1v=E1n=ED smluv, jsou uvedeny zde. Nen=ED-li v z= =E1sad=E1ch uvedeno jinak, nep=F8edstavuje tato zpr=E1va kone=E8n=FD n=E1vr= h na uzav=F8en=ED =E8i zm=ECnu smlouvy ani p=F8ijet=ED takov=E9ho n=E1vrhu.= The communication principles which T-Mobile Czech Republic a.s. applies wh= en negotiating contracts are defined here. Unless otherwise stated in t= he principles, this message does not constitute the final offer to contract= or an amendment of a contract or acceptance of such offer. From nobody Wed Jul 1 05:19:14 2015 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 71B391A1DBC for ; Wed, 1 Jul 2015 05:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.683 X-Spam-Level: X-Spam-Status: No, score=-4.683 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AwEfyruEPBn8 for ; Wed, 1 Jul 2015 05:19:09 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CB6C1A0373 for ; Wed, 1 Jul 2015 05:19:08 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t61CJ7lV024078; Wed, 1 Jul 2015 14:19:07 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4A5592040F8; Wed, 1 Jul 2015 14:22:13 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 35B942051AD; Wed, 1 Jul 2015 14:22:13 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t61CJ595031710; Wed, 1 Jul 2015 14:19:06 +0200 To: =?UTF-8?B?VsOtemRhbCBBbGXFoQ==?= , "holger.metschulat@telekom.de" , "v6ops@ietf.org" References: <5587EFDD.6030807@gmail.com> <558AA4F1.8080503@gmail.com> <88CAA5385EB5404392BF93106C8C53F89620073E87@HE111507.emea1.cds.t-internal.com> <55914517.4050602@gmail.com> From: Alexandru Petrescu Message-ID: <5593DAB9.1010202@gmail.com> Date: Wed, 1 Jul 2015 14:19:05 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=iso-8859-2; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share 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, 01 Jul 2015 12:19:12 -0000 Le 01/07/2015 11:35, Vízdal Aleš a écrit : >> -----Original Message----- From: v6ops >> [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandru Petrescu >> Sent: Monday, June 29, 2015 3:16 PM To: >> holger.metschulat@telekom.de; v6ops@ietf.org Subject: Re: [v6ops] >> Apple and IPv6, a few clarifications - 64share >> >> >> >> Le 29/06/2015 14:51, holger.metschulat@telekom.de a écrit : > >> The modem and chipsets on LTE that I have tried do forward DHCPv6 >> requests. For example it transmits the DHCPv6 Request and then >> receives an DHCPv6 Ack from the cellular network containing an IPv6 >> address. But if I make a DHCPv6 Prefix Delegation request then >> that is not answered. > > The current 3GPP specs do not contain DHCPv6 based IPv6 prefix > allocation, so I would be surprised by an LTE network doing so. 'Prefix Allocation' or Prefix Delegation? Because Section 5.3.1.2.6. or this 3GPP/ETSI spec does tell DHCPv6 Prefix Delegation, between the LTE network and the UE. http://www.etsi.org/deliver/etsi_ts/123400_123499/123401/10.03.00_60/ts_123401v100300p.pdf http://www.etsi.org/deliver/etsi_ts/123400_123499/123401/12.06.00_60/ts_123401v120600p.pdf (in this way one can see the history of it). > The DHCPv6 server could be run by the dongle and providing that RA > provided prefix via DHCPv6 to the host. If that is a question, the answer is no, the DHCPv6 server is not running by the dongle, because the IP address provided by DHCP is different than the IP address formed from the RA: both the prefix and the IID. The DNS server provided by RA is different than the DNS server provided by DHCP. The DNS server provided by DHCP works fine whereas the one provided by RA does not work. (So I end up with a situation where I must use both DHCP and RA, which is a burden) After having queried the operator in question I continue to think DHCPv6-PD is not provided by the network, although DHCPv6 for addresses _is_. Alex > >> I guess that hardware which blocks DHCPv6-PD also blocks DHCPv6. >> Otherwise it would be an intentional blocking of DHCPv6-PD... >> >> Alex > > Ales > > Zásady komunikace, které společnost T-Mobile Czech Republic a.s. > užívá při sjednávání smluv, jsou uvedeny > zde. > Není-li v zásadách uvedeno jinak, nepředstavuje tato zpráva konečný > návrh na uzavření či změnu smlouvy ani přijetí takového návrhu. The > communication principles which T-Mobile Czech Republic a.s. applies > when negotiating contracts are defined > here. > Unless otherwise stated in the principles, this message does not > constitute the final offer to contract or an amendment of a contract > or acceptance of such offer. > From nobody Wed Jul 1 06:22:37 2015 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 583F71A8864 for ; Wed, 1 Jul 2015 06:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.962 X-Spam-Level: X-Spam-Status: No, score=-0.962 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, 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 2ZsQmyn-kyNj for ; Wed, 1 Jul 2015 06:22:34 -0700 (PDT) Received: from ctxmailhub.t-mobile.cz (ctxmailhub.t-mobile.cz [93.153.104.87]) (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 F0B131A8858 for ; Wed, 1 Jul 2015 06:22:33 -0700 (PDT) From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Alexandru Petrescu , "holger.metschulat@telekom.de" , "v6ops@ietf.org" Thread-Topic: [v6ops] Apple and IPv6, a few clarifications - 64share Thread-Index: AQHQsm3eGmkYJhNvCEmzMRDqcmE/QJ3GXFmQgAANgoCAADJC8A== Date: Wed, 1 Jul 2015 13:22:29 +0000 Message-ID: <28c8cdc26b954001aa10a36b9e9baa66@srvhk403.rdm.cz> References: <5587EFDD.6030807@gmail.com> <558AA4F1.8080503@gmail.com> <88CAA5385EB5404392BF93106C8C53F89620073E87@HE111507.emea1.cds.t-internal.com> <55914517.4050602@gmail.com> <5593DAB9.1010202@gmail.com> In-Reply-To: <5593DAB9.1010202@gmail.com> Accept-Language: en-GB, cs-CZ, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.254.150.191] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Archived-At: Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share 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, 01 Jul 2015 13:22:36 -0000 > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Wednesday, July 01, 2015 2:19 PM > To: V=EDzdal Ale=B9; holger.metschulat@telekom.de; v6ops@ietf.org > Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share > > > > Le 01/07/2015 11:35, V=EDzdal Ale=B9 a =E9crit : > >> -----Original Message----- From: v6ops > >> [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandru Petrescu > >> Sent: Monday, June 29, 2015 3:16 PM To: > >> holger.metschulat@telekom.de; v6ops@ietf.org Subject: Re: [v6ops] > >> Apple and IPv6, a few clarifications - 64share > >> > >> > >> > >> Le 29/06/2015 14:51, holger.metschulat@telekom.de a =E9crit : > > > >> The modem and chipsets on LTE that I have tried do forward DHCPv6 > >> requests. For example it transmits the DHCPv6 Request and then > >> receives an DHCPv6 Ack from the cellular network containing an IPv6 > >> address. But if I make a DHCPv6 Prefix Delegation request then that > >> is not answered. > > > > The current 3GPP specs do not contain DHCPv6 based IPv6 prefix > > allocation, so I would be surprised by an LTE network doing so. > > 'Prefix Allocation' or Prefix Delegation? Because Section 5.3.1.2.6. > or this 3GPP/ETSI spec does tell DHCPv6 Prefix Delegation, between the LT= E > network and the UE. Initial Prefix Allocation (/64), I am not talking about PD. > http://www.etsi.org/deliver/etsi_ts/123400_123499/123401/10.03.00_60/ts > _123401v100300p.pdf > > http://www.etsi.org/deliver/etsi_ts/123400_123499/123401/12.06.00_60/ts > _123401v120600p.pdf > > (in this way one can see the history of it). > > > The DHCPv6 server could be run by the dongle and providing that RA > > provided prefix via DHCPv6 to the host. > > If that is a question, the answer is no, the DHCPv6 server is not running= by the > dongle, because the IP address provided by DHCP is different than the IP > address formed from the RA: both the prefix and the IID. > > The DNS server provided by RA is different than the DNS server provided b= y > DHCP. The DNS server provided by DHCP works fine whereas the one provide= d > by RA does not work. (So I end up with a situation where I must use both > DHCP and RA, which is a burden) It looks that the dongle is acting as a router then. > After having queried the operator in question I continue to think DHCPv6-= PD is > not provided by the network, although DHCPv6 for addresses _is_. > > Alex Ales Z=E1sady komunikace, kter=E9 spole=E8nost T-Mobile Czech Republic a.s. u=BE= =EDv=E1 p=F8i sjedn=E1v=E1n=ED smluv, jsou uvedeny zde. Nen=ED-li v z= =E1sad=E1ch uvedeno jinak, nep=F8edstavuje tato zpr=E1va kone=E8n=FD n=E1vr= h na uzav=F8en=ED =E8i zm=ECnu smlouvy ani p=F8ijet=ED takov=E9ho n=E1vrhu.= The communication principles which T-Mobile Czech Republic a.s. applies wh= en negotiating contracts are defined here. Unless otherwise stated in t= he principles, this message does not constitute the final offer to contract= or an amendment of a contract or acceptance of such offer. From nobody Wed Jul 1 06:35:36 2015 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 36CBD1A88DC for ; Wed, 1 Jul 2015 06:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.683 X-Spam-Level: X-Spam-Status: No, score=-4.683 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQbUYmiHqcIo for ; Wed, 1 Jul 2015 06:35:32 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C89EF1A88C0 for ; Wed, 1 Jul 2015 06:35:31 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t61DZTCB000573; Wed, 1 Jul 2015 15:35:29 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 1F980205223; Wed, 1 Jul 2015 15:38:36 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 11F2B205222; Wed, 1 Jul 2015 15:38:36 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t61DZRH7018146; Wed, 1 Jul 2015 15:35:29 +0200 To: =?UTF-8?B?VsOtemRhbCBBbGXFoQ==?= , "holger.metschulat@telekom.de" , "v6ops@ietf.org" References: <5587EFDD.6030807@gmail.com> <558AA4F1.8080503@gmail.com> <88CAA5385EB5404392BF93106C8C53F89620073E87@HE111507.emea1.cds.t-internal.com> <55914517.4050602@gmail.com> <5593DAB9.1010202@gmail.com> <28c8cdc26b954001aa10a36b9e9baa66@srvhk403.rdm.cz> From: Alexandru Petrescu Message-ID: <5593EC9F.6060700@gmail.com> Date: Wed, 1 Jul 2015 15:35:27 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <28c8cdc26b954001aa10a36b9e9baa66@srvhk403.rdm.cz> Content-Type: text/plain; charset=iso-8859-2; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share 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, 01 Jul 2015 13:35:35 -0000 Le 01/07/2015 15:22, Vízdal Aleš a écrit : >> -----Original Message----- >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >> Sent: Wednesday, July 01, 2015 2:19 PM >> To: Vízdal Aleš; holger.metschulat@telekom.de; v6ops@ietf.org >> Subject: Re: [v6ops] Apple and IPv6, a few clarifications - 64share >> >> >> >> Le 01/07/2015 11:35, Vízdal Aleš a écrit : >>>> -----Original Message----- From: v6ops >>>> [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandru Petrescu >>>> Sent: Monday, June 29, 2015 3:16 PM To: >>>> holger.metschulat@telekom.de; v6ops@ietf.org Subject: Re: [v6ops] >>>> Apple and IPv6, a few clarifications - 64share >>>> >>>> >>>> >>>> Le 29/06/2015 14:51, holger.metschulat@telekom.de a écrit : >>> >>>> The modem and chipsets on LTE that I have tried do forward DHCPv6 >>>> requests. For example it transmits the DHCPv6 Request and then >>>> receives an DHCPv6 Ack from the cellular network containing an IPv6 >>>> address. But if I make a DHCPv6 Prefix Delegation request then that >>>> is not answered. >>> >>> The current 3GPP specs do not contain DHCPv6 based IPv6 prefix >>> allocation, so I would be surprised by an LTE network doing so. >> >> 'Prefix Allocation' or Prefix Delegation? Because Section 5.3.1.2.6. >> or this 3GPP/ETSI spec does tell DHCPv6 Prefix Delegation, between the LTE >> network and the UE. > > Initial Prefix Allocation (/64), I am not talking about PD. Ok. My interest is in DHCPv6 PD to UE, and waiting for it to come up in the operator network. I agree there is also DHCPv6-PD in the core of LTE between various entities of the LTE network, and further deep in the Internet. That is also specified and implemented in some deployments. But I do not know what more precisely is meant by Prefix Allocation - who allocates to whom, and by what protocol. >> http://www.etsi.org/deliver/etsi_ts/123400_123499/123401/10.03.00_60/ts >> _123401v100300p.pdf >> >> http://www.etsi.org/deliver/etsi_ts/123400_123499/123401/12.06.00_60/ts >> _123401v120600p.pdf >> >> (in this way one can see the history of it). >> >>> The DHCPv6 server could be run by the dongle and providing that RA >>> provided prefix via DHCPv6 to the host. >> >> If that is a question, the answer is no, the DHCPv6 server is not running by the >> dongle, because the IP address provided by DHCP is different than the IP >> address formed from the RA: both the prefix and the IID. >> >> The DNS server provided by RA is different than the DNS server provided by >> DHCP. The DNS server provided by DHCP works fine whereas the one provided >> by RA does not work. (So I end up with a situation where I must use both >> DHCP and RA, which is a burden) > > It looks that the dongle is acting as a router then. No, I do not understand why would one think so. I have the feeling the LTE dongle is not even a bridge. It's more like a modem connected by a serial line to the computer. It has a single MAC address printed on it (not 2 as a router would), sysadmin uses qmicli or mmcli with parameters such as USB driver name to control it (not ssh or SNMP involving IP addresses), etc. Why do you think the USB dongle is a router? Alex > >> After having queried the operator in question I continue to think DHCPv6-PD is >> not provided by the network, although DHCPv6 for addresses _is_. >> >> Alex > > Ales > > > Zásady komunikace, které společnost T-Mobile Czech Republic a.s. užívá při sjednávání smluv, jsou uvedeny zde. Není-li v zásadách uvedeno jinak, nepředstavuje tato zpráva konečný návrh na uzavření či změnu smlouvy ani přijetí takového návrhu. The communication principles which T-Mobile Czech Republic a.s. applies when negotiating contracts are defined here. Unless otherwise stated in the principles, this message does not constitute the final offer to contract or an amendment of a contract or acceptance of such offer. > From nobody Wed Jul 1 13:35:36 2015 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 E1DF21A894A for ; Wed, 1 Jul 2015 13:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGyboPy4CfbY for ; Wed, 1 Jul 2015 13:35:32 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (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 C3BDE1A899D for ; Wed, 1 Jul 2015 13:35:26 -0700 (PDT) Received: from [186.137.82.224] (helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZAOj3-00034m-96; Wed, 01 Jul 2015 22:35:21 +0200 Message-ID: <55944EFF.8020207@si6networks.com> Date: Wed, 01 Jul 2015 17:35:11 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "v6ops@ops.ietf.org" References: <20150701202921.11226.39596.idtracker@ietfa.amsl.com> In-Reply-To: <20150701202921.11226.39596.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20150701202921.11226.39596.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-gont-v6ops-ipv6-ehs-packet-drops@tools.ietf.org Subject: [v6ops] Operational Implications of IPv6 Packets with Extension (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-00.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, 01 Jul 2015 20:35:35 -0000 Folks, A group of us published a new I-D trying to summarize the operational and security implications. It is meant to summarize the reasons for which operators may intentionally drop IPv6 packets containing IPv6 extension headers. The I-D is available at: As far as this I-D is concerned, think of us co-authors as the messengers. The I-D doesn't argue itself whether you should (or should not) drop packets with EHs, but simply discusses the challenge they represent in some scenarios. Comments will be more than welcome. Thanks! Best regards, Fernando -------- Forwarded Message -------- Subject: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-00.txt Date: Wed, 01 Jul 2015 13:29:21 -0700 From: internet-drafts@ietf.org To: Gert Doering , Nick Hilliard , Shucheng LIU (Will) , Gert Doering , Warren Kumari , Will Liu (Shucheng) , Fernando Gont , Nick Hilliard , Fernando Gont , Warren Kumari A new version of I-D, draft-gont-v6ops-ipv6-ehs-packet-drops-00.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Name: draft-gont-v6ops-ipv6-ehs-packet-drops Revision: 00 Title: Operational Implications of IPv6 Packets with Extension Headers Document date: 2015-07-01 Group: Individual Submission Pages: 13 URL: https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-drops-00.txt Status: https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-packet-drops/ Htmlized: https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-00 Abstract: This document summarizes the security and operational implications of IPv6 extension headers, and attempts to analyze reasons why packets with IPv6 extension headers may be dropped in the public Internet. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Thu Jul 2 04:47:06 2015 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 D58D61A8741 for ; Thu, 2 Jul 2015 04:47:04 -0700 (PDT) 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 QwcU2keQ-2xX for ; Thu, 2 Jul 2015 04:47:03 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE15F1A873E for ; Thu, 2 Jul 2015 04:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=138; q=dns/txt; s=iport; t=1435837623; x=1437047223; h=date:from:message-id:to:subject:cc; bh=wsRZy3J7DnT6e2uYIDNsLlW0vgrnXuITmUaBK0UXqpU=; b=dWtELRfrZwheR1mfs/4BrLvHVyB17Z3Vso6GjQou0tPTNh/SK6ONJyoa 4cjgYBwGJCotqIRw0we44BEBvBjXPICllHqtQ2Qlb20GFq+stPlHjsjAj FyymQ94k2Zr1JWMQcPcLYJDVOQEHMeHTzpfgD3/cKfI+7FA4mzIWLdqzg g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CrMAANJJVV/51dJa1bgxJUYK5MAY5lCYFuhW8JgU04FAEBAQEBAQGBCkEBAgEBg199PDSJDwENzEIBAQEHAQEBAQEdi0qFBh2EFQWNBocMhGGIP0SDUJJ7JoQagxcBAQE X-IronPort-AV: E=Sophos;i="5.15,392,1432598400"; d="scan'208";a="6465593" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 02 Jul 2015 11:47:03 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t62Bl2fC014157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Jul 2015 11:47:03 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 t62Bl24g009956; Thu, 2 Jul 2015 04:47:02 -0700 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id t62Bl2O8009953; Thu, 2 Jul 2015 04:47:02 -0700 Date: Thu, 2 Jul 2015 04:47:02 -0700 From: fred@cisco.com Message-Id: <201507021147.t62Bl2O8009953@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Cc: draft-gont-v6ops-ipv6-ehs-packet-drops@tools.ietf.org Subject: [v6ops] new draft: 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: Thu, 02 Jul 2015 11:47:05 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops. Please take a look at it and comment. From nobody Thu Jul 2 06:53:26 2015 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 9F15A1A8784 for ; Mon, 29 Jun 2015 01:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 1wWZfiJLJPSg for ; Mon, 29 Jun 2015 01:13:16 -0700 (PDT) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AEB51A8781 for ; Mon, 29 Jun 2015 01:13:14 -0700 (PDT) Received: from CAS21.d.ethz.ch (172.31.51.111) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 29 Jun 2015 10:13:11 +0200 Received: from MBX114.d.ethz.ch ([fe80::4875:1a61:8b1c:148]) by CAS21.d.ethz.ch ([fe80::55ba:c4a5:d8a7:ab62%10]) with mapi id 14.03.0195.001; Mon, 29 Jun 2015 10:13:12 +0200 From: "Valenkamp Derk-Jan (ID NET)" To: 'Mark ZZZ Smith' , "v6ops@ietf.org" Thread-Topic: [v6ops] new draft: draft-vyncke-v6ops-ipv6-only-thin-clients Thread-Index: AQHQsM8Cr1YAViQEYUWVbzB756GP+53CoNGAgAB5wUA= Date: Mon, 29 Jun 2015 08:13:11 +0000 Message-ID: References: <201506271147.t5RBl19P016483@irp-lnx1.cisco.com> <521433567.1631702.1435544349087.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <521433567.1631702.1435544349087.JavaMail.yahoo@mail.yahoo.com> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.132.243.46] Content-Type: multipart/alternative; boundary="_000_E31607B6A0D84647BE15CC3D6C476C592B14B3BDMBX114dethzch_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Thu, 02 Jul 2015 06:53:25 -0700 Cc: "draft-vyncke-v6ops-ipv6-only-thin-clients@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-vyncke-v6ops-ipv6-only-thin-clients 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, 29 Jun 2015 08:13:18 -0000 --_000_E31607B6A0D84647BE15CC3D6C476C592B14B3BDMBX114dethzch_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClNlZSBteSBjb21tZW50cyBpbmxpbmUuDQoNClJlZ2FyZHMNCg0KRGVyaw0KDQpGcm9t OiBNYXJrIFpaWiBTbWl0aCBbbWFpbHRvOm1hcmt6enpzbWl0aEB5YWhvby5jb20uYXVdDQpTZW50 OiBNb250YWcsIDI5LiBKdW5pIDIwMTUgMDQ6MTkNClRvOiB2Nm9wc0BpZXRmLm9yZw0KQ2M6IGRy YWZ0LXZ5bmNrZS12Nm9wcy1pcHY2LW9ubHktdGhpbi1jbGllbnRzQHRvb2xzLmlldGYub3JnDQpT dWJqZWN0OiBSZTogW3Y2b3BzXSBuZXcgZHJhZnQ6IGRyYWZ0LXZ5bmNrZS12Nm9wcy1pcHY2LW9u bHktdGhpbi1jbGllbnRzDQoNCkhpLA0KDQpTb21lIHRob3VnaHRzL2NvbW1lbnRzOg0KDQoNCg0K UmVnYXJkaW5nIFdvTCwgYXQgbGVhc3Qgb25lIG9mIG15IFdpZmkgTklDcyBzdXBwb3J0cyBpdCwg c28gaXQgaXNuJ3QgZXhjbHVzaXZlIHRvIHdpcmVkIGxpbmtzLiBJIGRvbid0IGtub3cgbXVjaCBh Ym91dCBpdCwgSSd2ZSBkaXNjb3ZlcmVkIGl0IGJlY2F1c2UgSSd2ZSB3YW50ZWQgdG8gc2F2ZSBk ZXZpY2UgcG93ZXIgYW5kIHRoZXJlZm9yZSBzd2l0Y2ggaXQgb2ZmLiBBY2NvcmRpbmcgdG8gc29t ZSBJbnRlcm5ldCBzZWFyY2hpbmcgaXQgaXMgbW9yZSBnZW5lcmFsbHkga25vd24gYXMgIldha2Ug b24gV2lyZWxlc3MgTEFOIiBvciAiV29XTEFOIi4NCg0KDQoiMS4zLiAgTWl0aWdhdGlvbiINCg0K IkZvciBleGFtcGxlLCB0byByZWFjaCBhbGwgbm9kZXMgaW4gMjAwMTpkYjg6Oi82NCwgbGV0J3MN CiAgIGNvbmZpZ3VyZSBhIHN0YXRpYyBOZWlnaGJvciBDYWNoZSBlbnRyeSBmb3IgMjAwMTpkYjg6 OmNhZmU6YzA6ZmZlZSBhcw0KICAgZmYtZmYtZmYtZmYtZmYtZmYuIg0KDQpJIHRoaW5rIGl0IHdv dWxkIGJlIGJldHRlciB0byB1c2UgdGhlIElQdjYgbGluay1sYXllciAiYWxsIG5vZGVzIiBtdWx0 aWNhc3QgYWRkcmVzcyBvZiAzMzozMzowMDowMDowMDowMSBmb3IgdGhpcy4gSWRlYWxseSwgaW4g YW4gSVB2NiBvbmx5IG5ldHdvcmssIE5JQ3MgY291bGQgZHJvcCBsaW5rLWxheWVyIGJyb2FkY2Fz dHMgYW5kIHBlcmZvcm0gYW4gYW1vdW50IG9mIG11bHRpY2FzdCBhZGRyZXNzIGZpbHRlcmluZy4N Cg0KLi4uDQpEZXJrOiBZZXMsIEkgZ3Vlc3MgZm9yIElQdjYgb25seSAzMzozMzowMDowMDowMDow MSB3aWxsIGJlIHRoZSBiZXR0ZXIgY2hvaWNlLiBJ4oCZdmUgbm8gZXhwZXJpZW5jZSBob3cgYSBM YXllciAyIHN3aXRjaCBoYW5kbGUgYSBwYWNrZXQgd2l0aCBldGhlcnR5cGUg4oCYSVB2NuKAmSBh bmQgZGVzdGluYXRpb24gZmY6ZmY6ZmY6ZmY6ZmY6ZmYsIHdoaWNoIGlzIGluIG15IG9waW5pb24g aWxsZWdhbCBwYWNrZXQuDQoNCiIyLiAgb3BlbmluZyBhIGRvb3IgdG8gYSBkZW5pYWwgb2Ygc2Vy dmljZSBhdHRhY2s6IGEgcmVtb3RlIGhvc3RpbGUNCiAgICAgICBwYXJ0eSBjb3VsZCBrZWVwIHNl bmRpbmcgcGFja2V0cyB0aGlzIGlzIHNwZWNpZmljIHVuaWNhc3QgYWRkcmVzcw0KICAgICAgIGZv cmNpbmcgYWxsIGhvc3RzIHRvIHN0YXkgYXdha2UsIGhlbmNlIHdhc3RpbmcgZWxlY3RyaWNhbCBl bmVyZ3kuDQogICAgICAgQXMgdGhpcyBhZGRyZXNzIGlzIGEgdW5pY2FzdCBhZGRyZXNzIHdoaWNo IGRvZXMgbm90IGJlbG9uZyB0byBhbnkNCiAgICAgICBwaHlzaWNhbCBob3N0IG9uIHRoZSBsYXll ci0yIGRvbWFpbiwgdGhlbiBhbGwgbm9kZXMgd2lsbCBzaWxlbnRseQ0KICAgICAgIGRpc2NhcmQg dGhpcyBwYWNrZXQgYXQgdGhlIGxheWVyLTMuIg0KDQpUaGlzIHJlYWRzIHRvIG1lIGFzIHRob3Vn aCBpdCBpcyBiZWluZyBzZWVuIGFzIGFuIElQdjYgc3BlY2lmaWMgdGhyZWF0LCB3aGVyZSBhcyBJ J2QgY29uc2lkZXIgaXQgdG8gYWxzbyBiZSBhIHRocmVhdCBpbiBhbiBJUHY0IG5ldHdvcmsuIElm IGl0IGlzIG5vdCBzZWVuIGFzIGFuIElQdjQgdGhyZWF0IGJlY2F1c2Ugb2YgUkZDMTkxOCBhZGRy ZXNzZXMsIHRoZW4gSSB0aGluayB0aGUgZXF1aXZhbGVudCBtaXRpZ2F0aW9uIGZvciBJUHY2IHdv dWxkIGJlIHRvIGxpbWl0IHRoZSBhYmlsaXR5IHRvIHdha2UgZGV2aWNlcyBieSBvbmx5IGFsbG93 aW5nL3VzaW5nIFVMQSBhZGRyZXNzZXMgZm9yIFdvTCBtYWdpYyBkZXN0aW5hdGlvbnMgKGkuZS4s IGRldmljZXMgd291bGQgc3RpbGwgaGF2ZSBnbG9iYWwgYWRkcmVzc2VzLCBidXQgYSBnbG9iYWwg YWRkcmVzcyB3b3VsZCBub3QgYmUgYSBtYWdpYyBXb0wgYWRkcmVzcy4pDQoNCkRlcms6IFRoZSB0 aHJlYXQgZXhpc3QgYWxzbyBpbiBJUHY0IG5ldHdvcmtzLiBUaGF04oCZcyB3aHkgdXN1YWxseSBk aXJlY3RlZCBicm9hZGNhc3QgYXJlIG9ubHkgZW5hYmxlZCB3aXRoIGFjY2Vzcy1saXN0LCB0byBh bGxvdyB0aGUgZGlyZWN0ZWQgYnJvYWRjYXN0IG9ubHkgZnJvbSBjZXJ0YWluIHNvdXJjZSBJUOKA mXMuICBJbiBvdXIgdW5pdmVyc2l0eSBuZXR3b3JrICBvbmx5IGFsbG93aW5nL3VzaW5nIFVMQSBh ZGRyZXNzZXMgZm9yIFdvTCB3b3VsZCBub3Qgc29sdmUgdGhlIHRocmVhdC4NCg0KUmVnYXJkcywN Ck1hcmsuDQoNCg0KDQo= --_000_E31607B6A0D84647BE15CC3D6C476C592B14B3BDMBX114dethzch_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K c3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46 NzAuODVwdCA3MC44NXB0IDIuMGNtIDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJERS1DSCIgbGluaz0iIzA1 NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPlNlZSBteSBjb21tZW50cyBpbmxpbmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj5SZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij5EZXJrPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IE1hcmsgWlpaIFNt aXRoIFttYWlsdG86bWFya3p6enNtaXRoQHlhaG9vLmNvbS5hdV0NCjxicj4NCjxiPlNlbnQ6PC9i PiBNb250YWcsIDI5LiBKdW5pIDIwMTUgMDQ6MTk8YnI+DQo8Yj5Ubzo8L2I+IHY2b3BzQGlldGYu b3JnPGJyPg0KPGI+Q2M6PC9iPiBkcmFmdC12eW5ja2UtdjZvcHMtaXB2Ni1vbmx5LXRoaW4tY2xp ZW50c0B0b29scy5pZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3Y2b3BzXSBuZXcg ZHJhZnQ6IGRyYWZ0LXZ5bmNrZS12Nm9wcy1pcHY2LW9ubHktdGhpbi1jbGllbnRzPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgaWQ9Inl1aV8zXzE2XzBfMV8xNDM1NTM5NTIw NjkxXzIxMTA3Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBp ZD0ieXVpXzNfMTZfMF8xXzE0MzU1Mzk1MjA2OTFfMjExMDciPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJ5dWlfM18xNl8wXzFfMTQzNTUzOTUyMDY5 MV8yMTEwNyI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj5Tb21lIHRob3VnaHRzL2NvbW1lbnRzOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdiBpZD0ieXVpXzNfMTZfMF8xXzE0MzU1Mzk1MjA2OTFfMjExMDciPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJ5dWlfM18x Nl8wXzFfMTQzNTUzOTUyMDY5MV8yMTEwNyI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Inl1aV8zXzE2XzBfMV8xNDM1NTM5NTIwNjkxXzIxMTA3Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ieXVpXzNf MTZfMF8xXzE0MzU1Mzk1MjA2OTFfMjExMDciPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+UmVnYXJkaW5nIFdvTCwgYXQgbGVhc3Qg b25lIG9mIG15IFdpZmkgTklDcyBzdXBwb3J0cyBpdCwgc28gaXQgaXNuJ3QgZXhjbHVzaXZlIHRv IHdpcmVkIGxpbmtzLiBJIGRvbid0IGtub3cgbXVjaCBhYm91dCBpdCwgSSd2ZSBkaXNjb3ZlcmVk IGl0IGJlY2F1c2UNCiBJJ3ZlIHdhbnRlZCB0byBzYXZlIGRldmljZSBwb3dlciBhbmQgdGhlcmVm b3JlIHN3aXRjaCBpdCBvZmYuIEFjY29yZGluZyB0byBzb21lIEludGVybmV0IHNlYXJjaGluZyBp dCBpcyBtb3JlIGdlbmVyYWxseSBrbm93biBhcyAmcXVvdDtXYWtlIG9uIFdpcmVsZXNzIExBTiZx dW90OyBvciAmcXVvdDtXb1dMQU4mcXVvdDsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2IGlkPSJ5dWlfM18xNl8wXzFfMTQzNTUzOTUyMDY5MV8yMTEwNyI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Inl1aV8zXzE2XzBfMV8xNDM1 NTM5NTIwNjkxXzIxMTA3Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdiBpZD0ieXVpXzNfMTZfMF8xXzE0MzU1Mzk1MjA2OTFfMjExMDciPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+JnF1b3Q7 MS4zLiAmbmJzcDtNaXRpZ2F0aW9uJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2IGlkPSJ5dWlfM18xNl8wXzFfMTQzNTUzOTUyMDY5MV8yMTEwNyI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Inl1aV8zXzE2XzBfMV8xNDM1 NTM5NTIwNjkxXzIxMTA3Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPiZxdW90O0ZvciBleGFtcGxlLCB0byByZWFjaCBhbGwgbm9k ZXMgaW4gMjAwMTpkYjg6Oi82NCwgbGV0J3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXYgaWQ9Inl1aV8zXzE2XzBfMV8xNDM1NTM5NTIwNjkxXzIxMTA3Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyAm bmJzcDtjb25maWd1cmUgYSBzdGF0aWMgTmVpZ2hib3IgQ2FjaGUgZW50cnkgZm9yIDIwMDE6ZGI4 OjpjYWZlOmMwOmZmZWUgYXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9 Inl1aV8zXzE2XzBfMV8xNDM1NTM5NTIwNjkxXzIxMTA3Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDtmZi1m Zi1mZi1mZi1mZi1mZi4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYg aWQ9Inl1aV8zXzE2XzBfMV8xNDM1NTM5NTIwNjkxXzIxMTA3Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ieXVpXzNfMTZfMF8xXzE0MzU1Mzk1MjA2 OTFfMjExMDciPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+SSB0aGluayBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gdXNlIHRoZSBJUHY2 IGxpbmstbGF5ZXIgJnF1b3Q7YWxsIG5vZGVzJnF1b3Q7IG11bHRpY2FzdCBhZGRyZXNzIG9mIDMz OjMzOjAwOjAwOjAwOjAxIGZvciB0aGlzLiBJZGVhbGx5LCBpbiBhbiBJUHY2IG9ubHkgbmV0d29y aywgTklDcw0KIGNvdWxkIGRyb3AgbGluay1sYXllciBicm9hZGNhc3RzIGFuZCBwZXJmb3JtIGFu IGFtb3VudCBvZiBtdWx0aWNhc3QgYWRkcmVzcyBmaWx0ZXJpbmcuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJ5dWlfM18xNl8wXzFfMTQzNTUzOTUyMDY5MV8yMTEwNyI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Inl1aV8z XzE2XzBfMV8xNDM1NTM5NTIwNjkxXzIxMTA3Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPi4uLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkRlcms6IFllcywgSSBndWVzcyBm b3IgSVB2NiBvbmx5IDMzOjMzOjAwOjAwOjAwOjAxIHdpbGwgYmUgdGhlIGJldHRlciBjaG9pY2Uu IEnigJl2ZSBubyBleHBlcmllbmNlIGhvdyBhIExheWVyIDIgc3dpdGNoIGhhbmRsZQ0KIGEgcGFj a2V0IHdpdGggZXRoZXJ0eXBlIOKAmElQdjbigJkgYW5kIGRlc3RpbmF0aW9uIGZmOmZmOmZmOmZm OmZmOmZmLCB3aGljaCBpcyBpbiBteSBvcGluaW9uIGlsbGVnYWwgcGFja2V0LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ieXVpXzNfMTZfMF8xXzE0MzU1Mzk1MjA2OTFf MjExMDciPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdiBpZD0ieXVpXzNfMTZfMF8xXzE0MzU1Mzk1MjA2OTFfMjExMDciPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPiZxdW90OzIuICZuYnNwO29wZW5pbmcgYSBkb29yIHRvIGEgZGVuaWFsIG9mIHNl cnZpY2UgYXR0YWNrOiBhIHJlbW90ZSBob3N0aWxlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2IGlkPSJ5dWlfM18xNl8wXzFfMTQzNTUzOTUyMDY5MV8yMTEwNyI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cGFydHkgY291bGQga2VlcCBzZW5k aW5nIHBhY2tldHMgdGhpcyBpcyBzcGVjaWZpYyB1bmk8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5jYXN0 IGFkZHJlc3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Inl1aV8zXzE2 XzBfMV8xNDM1NTM5NTIwNjkxXzIxMTA3Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O2ZvcmNpbmcgYWxsIGhvc3RzIHRvIHN0YXkgYXdha2UsIGhlbmNlIHdhc3RpbmcgZWxlY3RyaWNh bCBlbmVyZ3kuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJ5dWlfM18x Nl8wXzFfMTQzNTUzOTUyMDY5MV8yMTEwNyI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtBcyB0aGlzIGFkZHJlc3MgaXMgYSB1bmljYXN0IGFkZHJlc3Mgd2hpY2ggZG9lcyBub3QgYmVs b25nIHRvIGFueTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ieXVpXzNf MTZfMF8xXzE0MzU1Mzk1MjA2OTFfMjExMDciPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7cGh5c2ljYWwgaG9zdCBvbiB0aGUgbGF5ZXItMiBkb21haW4sIHRoZW4gYWxsIG5vZGVzIHdp bGwgc2lsZW50bHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Inl1aV8z XzE2XzBfMV8xNDM1NTM5NTIwNjkxXzIxMTA3Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO2Rpc2NhcmQgdGhpcyBwYWNrZXQgYXQgdGhlIGxheWVyLTMuJnF1b3Q7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJ5dWlfM18xNl8wXzFfMTQzNTUzOTUyMDY5MV8y MTEwNyI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9 Inl1aV8zXzE2XzBfMV8xNDM1NTM5NTIwNjkxXzIxMTA3Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlRoaXMgcmVhZHMgdG8gbWUg YXMgdGhvdWdoIGl0IGlzIGJlaW5nIHNlZW4gYXMgYW4gSVB2NiBzcGVjaWZpYyB0aHJlYXQsIHdo ZXJlIGFzIEknZCBjb25zaWRlciBpdCB0byBhbHNvIGJlIGEgdGhyZWF0IGluIGFuIElQdjQgbmV0 d29yay4gSWYgaXQgaXMgbm90DQogc2VlbiBhcyBhbiBJUHY0IHRocmVhdCBiZWNhdXNlIG9mIFJG QzE5MTggYWRkcmVzc2VzLCB0aGVuIEkgdGhpbmsgdGhlIGVxdWl2YWxlbnQgbWl0aWdhdGlvbiBm b3IgSVB2NiB3b3VsZCBiZSB0byBsaW1pdCB0aGUgYWJpbGl0eSB0byB3YWtlIGRldmljZXMgYnkg b25seSBhbGxvd2luZy91c2luZyBVTEEgYWRkcmVzc2VzIGZvciBXb0wgbWFnaWMgZGVzdGluYXRp b25zIChpLmUuLCBkZXZpY2VzIHdvdWxkIHN0aWxsIGhhdmUgZ2xvYmFsIGFkZHJlc3NlcywNCiBi dXQgYSBnbG9iYWwgYWRkcmVzcyB3b3VsZCBub3QgYmUgYSBtYWdpYyBXb0wgYWRkcmVzcy4pPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJ5dWlfM18xNl8wXzFfMTQzNTUz OTUyMDY5MV8yMTEwNyI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkRlcms6IFRoZSB0aHJlYXQgZXhpc3QgYWxzbyBp biBJUHY0IG5ldHdvcmtzLiBUaGF04oCZcyB3aHkgdXN1YWxseSBkaXJlY3RlZCBicm9hZGNhc3Qg YXJlIG9ubHkgZW5hYmxlZCB3aXRoIGFjY2Vzcy1saXN0LCB0bw0KIGFsbG93IHRoZSBkaXJlY3Rl ZCBicm9hZGNhc3Qgb25seSBmcm9tIGNlcnRhaW4gc291cmNlIElQ4oCZcy4gJm5ic3A7SW4gb3Vy IHVuaXZlcnNpdHkgbmV0d29yayAmbmJzcDtvbmx5IGFsbG93aW5nL3VzaW5nIFVMQSBhZGRyZXNz ZXMgZm9yIFdvTCB3b3VsZCBub3Qgc29sdmUgdGhlIHRocmVhdC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Inl1aV8zXzE2XzBfMV8xNDM1NTM5NTIwNjkxXzIx MTA3Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlk PSJ5dWlfM18xNl8wXzFfMTQzNTUzOTUyMDY5MV8yMTEwNyI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5NYXJrLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ieXVpXzNfMTZfMF8xXzE0MzU1Mzk1MjA2OTFf MjExMDciPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlk PSJ5dWlfM18xNl8wXzFfMTQzNTUzOTUyMDY5MV8yMTQwMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Inl1aV8zXzE2XzBfMV8xNDM1NTM5NTIwNjkx XzIwOTkwIj4NCjxkaXYgaWQ9Inl1aV8zXzE2XzBfMV8xNDM1NTM5NTIwNjkxXzIwOTg5Ij4NCjxk aXYgaWQ9Inl1aV8zXzE2XzBfMV8xNDM1NTM5NTIwNjkxXzIwOTg4Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_E31607B6A0D84647BE15CC3D6C476C592B14B3BDMBX114dethzch_-- From nobody Thu Jul 2 06:53:28 2015 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 CCB4E1AD23D; Mon, 29 Jun 2015 10:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.889 X-Spam-Level: X-Spam-Status: No, score=-0.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, 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 0taq4CXCNcWU; Mon, 29 Jun 2015 10:48:30 -0700 (PDT) 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 108771AD218; Mon, 29 Jun 2015 10:48:30 -0700 (PDT) Received: from mb-aye.local ([8.18.217.2]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t5THmQjh056569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 29 Jun 2015 17:48:27 GMT (envelope-from joelja@bogus.com) From: joel jaeggli X-Enigmail-Draft-Status: N1110 Message-ID: <559184E7.1020008@bogus.com> Date: Mon, 29 Jun 2015 10:48:23 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EUu1LWmxKSreda0JHMsb6k0mDXaldHKAq" Archived-At: X-Mailman-Approved-At: Thu, 02 Jul 2015 06:53:25 -0700 Subject: [v6ops] OPS working groups, getting to be that time again. 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, 29 Jun 2015 17:48:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EUu1LWmxKSreda0JHMsb6k0mDXaldHKAq Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable We're 20 days out from IETF 93. If you find yourself wanting to meet with me prior to that or you have anything that needs special handling in the interim please let me know. Draft submission deadline and initial agenda deadline both come due on Monday 7/6. Thanks and see you at IETF 93. Joel --EUu1LWmxKSreda0JHMsb6k0mDXaldHKAq 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.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlWRhOcACgkQ8AA1q7Z/VrKNCQCeLycsWoqvFuy80aFV9plGX/1G scwAn1MxgQB9LSKZ2O3uFvhfb9qeXnpk =l3hB -----END PGP SIGNATURE----- --EUu1LWmxKSreda0JHMsb6k0mDXaldHKAq-- From nobody Sat Jul 4 04:47:07 2015 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 2F6BC1A882F for ; Sat, 4 Jul 2015 04:47:06 -0700 (PDT) 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 ST5jW5m7ARfT for ; Sat, 4 Jul 2015 04:47:05 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01B8E1A7017 for ; Sat, 4 Jul 2015 04:47:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=126; q=dns/txt; s=iport; t=1436010424; x=1437220024; h=date:from:message-id:to:subject:cc; bh=NQr7k/qhvgV+dl2VUi5zMzgIgXmPcMXGVAsDEdxs8LA=; b=iGyx0tUHOBVkFSvXzc92VsDz0egR4LR9gsw7IcoXK2HzX+NdD8Z3IY8h IMPrausteV78Pjc6EMgkFgEsL/mTAf1ZvECImMAcWJZoDoRBXNheJbfu/ OtwcJncTaFqLjHhomCpdhDlpo7+EeJblUwdUAqK7wCt89eckyAKoRWcrW 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DwGgBkxpdV/5RdJa1cgxJUYa5hAY5vgW6FbgmBJjoSAQEBAQEBAYEKQQECAoNgfTw0iQ8BDcZuAQEBAQYBAQEBAQEci0uFBh2EFQWNCIcNhGKIQESDUZMHJoQbgxoBAQE X-IronPort-AV: E=Sophos;i="5.15,405,1432598400"; d="scan'208";a="8865726" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-6.cisco.com with ESMTP; 04 Jul 2015 11:47:04 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t64Bl3fG026388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 4 Jul 2015 11:47: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 t64Bl3Rk005717; Sat, 4 Jul 2015 04:47:03 -0700 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id t64Bl2oR005661; Sat, 4 Jul 2015 04:47:02 -0700 Date: Sat, 4 Jul 2015 04:47:02 -0700 From: fred@cisco.com Message-Id: <201507041147.t64Bl2oR005661@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Cc: draft-bao-v6ops-rfc6145bis@tools.ietf.org Subject: [v6ops] new draft: draft-bao-v6ops-rfc6145bis 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, 04 Jul 2015 11:47:06 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-bao-v6ops-rfc6145bis. Please take a look at it and comment. From nobody Sat Jul 4 13:23:53 2015 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 4E4DE1A0046; Sat, 4 Jul 2015 13:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFIhCs5v5pUt; Sat, 4 Jul 2015 13:23:51 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::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 2B3581A0039; Sat, 4 Jul 2015 13:23:48 -0700 (PDT) Received: by pacgz10 with SMTP id gz10so76929pac.3; Sat, 04 Jul 2015 13:23:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=GgaOtmKnrPd60Mq0j3imo42Q+yK+OMM28sdw78Tcic0=; b=0CHB8THsKyaYkBEmoG8pH5okep+2fC9QGHLt91TyN8yFiwlFeK1aW0ig9AFiog0PJX QNh1JH+4turbEXqP9xbPw39Dh9caQ38and5cX+NGQ0ZFnnbNqrxYTtzhEFz2h8WY3DWd QqZHZkDkgchfPtReDeJiirjwxE1rFS/53k35c+a5JcmG/+toeYZKQw+DUr3VfghgunAk yHVWkI1cdtCzJjLogg8XEBpTOPq/Xp8oAg3o1bkGG4S5NOx4EDG/snpfiYim9gC3+6R9 Q5wP1T/za8gvufZtW6/47khZWPegdINAtbYoIxizrucdhaKwPBxDcyaNrid2A297BHPo +tgQ== X-Received: by 10.68.185.37 with SMTP id ez5mr90375825pbc.74.1436041427841; Sat, 04 Jul 2015 13:23:47 -0700 (PDT) Received: from ?IPv6:2406:e007:597c:1:28cc:dc4c:9703:6781? ([2406:e007:597c:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id z6sm10673299pdk.83.2015.07.04.13.23.44 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 Jul 2015 13:23:46 -0700 (PDT) Message-ID: <559840C1.30004@gmail.com> Date: Sun, 05 Jul 2015 08:23:29 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: IPv6 Operations , draft-bao-v6ops-rfc6145bis@ietf.org References: <20150704074712.9480.20007.idtracker@ietfa.amsl.com> In-Reply-To: <20150704074712.9480.20007.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-bao-v6ops-rfc6145bis-00.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, 04 Jul 2015 20:23:52 -0000 Hi, The content looks good except for section 6.2 (hairpinning) which seems superficial and includes a broken reference. There are nits: > This document updates RFC 6145. Surely that should be "obsoletes" (if not, it isn't a "bis" document). IMHO, unless you have explicit permission from the author of RFC 2765, you still need the boilerplate. A short "Changes from RFC6145" appendix would be useful. Regards Brian From nobody Mon Jul 6 02:56:54 2015 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 BA9651AC432; Mon, 6 Jul 2015 02:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3qgXUMImZfP; Mon, 6 Jul 2015 02:56:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A542D1AC43B; Mon, 6 Jul 2015 02:56:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706095650.25896.73989.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 02:56:50 -0700 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-dhcpv6-slaac-problem-05.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, 06 Jul 2015 09:56:52 -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 : DHCPv6/SLAAC Interaction Problems on Address and DNS Configuration Authors : Bing Liu Sheng Jiang Xiangyang Gong Wendong Wang Enno Rey Filename : draft-ietf-v6ops-dhcpv6-slaac-problem-05.txt Pages : 22 Date : 2015-07-06 Abstract: The IPv6 Neighbor Discovery (ND) Protocol includes an ICMPv6 Router Advertisement (RA) message. The RA message contains three flags, indicating the availability of address auto-configuration mechanisms and other configuration. These are the M, O, and A flags. These flags by definition are advisory, not prescriptive. This document describes divergent host behaviors observed in popular operating systems. It also discusses operational problems that divergent behaviors might cause. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-dhcpv6-slaac-problem-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 6 03:15:30 2015 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 1975E1ACCE0 for ; Mon, 6 Jul 2015 03:15:30 -0700 (PDT) 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 5RonO23zhR9Q for ; Mon, 6 Jul 2015 03:15:28 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14AEC1ACCD8 for ; Mon, 6 Jul 2015 03:15:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYJ73819; Mon, 06 Jul 2015 10:15:26 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 6 Jul 2015 11:15:25 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.135]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Mon, 6 Jul 2015 18:15:19 +0800 From: "Liubing (Leo)" To: "v6ops@ietf.org" Thread-Topic: DHCPv6/SLAAC Interaction Problem-05 (DNS test added)//RE: [v6ops] I-D Action: draft-ietf-v6ops-dhcpv6-slaac-problem-05.txt Thread-Index: AQHQt9IeYwgM/O9lo0Or8fYADMUNW53ONQdA Date: Mon, 6 Jul 2015 10:15:18 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C21E0E18@nkgeml506-mbx.china.huawei.com> References: <20150706095650.25896.73989.idtracker@ietfa.amsl.com> In-Reply-To: <20150706095650.25896.73989.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [v6ops] DHCPv6/SLAAC Interaction Problem-05 (DNS test added)//RE: I-D Action: draft-ietf-v6ops-dhcpv6-slaac-problem-05.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, 06 Jul 2015 10:15:30 -0000 Hi Dear all, We're happy to tell you that this new version included the DNS configuratio= n test cases of RFC6106 & DHCPv6. (Thanks for our new co-author Enno Rey wh= o contributed the test cases, details are recorded in the Annex "Test Set 2= ".) The analysis and the divergent behaviors text was also updated accordin= gly. In a nutshell, the DNS configuration interaction between RA and DHCPv6 also= invokes divergent behaviors, even more complicated than the address config= uration situations. Comments are welcomed. Best regards, Bing > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Monday, July 06, 2015 5:57 PM > To: i-d-announce@ietf.org > Cc: v6ops@ietf.org > Subject: [v6ops] I-D Action: draft-ietf-v6ops-dhcpv6-slaac-problem-05.txt >=20 >=20 > 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 IE= TF. >=20 > Title : DHCPv6/SLAAC Interaction Problems on > Address and DNS Configuration > Authors : Bing Liu > Sheng Jiang > Xiangyang Gong > Wendong Wang > Enno Rey > Filename : draft-ietf-v6ops-dhcpv6-slaac-problem-05.txt > Pages : 22 > Date : 2015-07-06 >=20 > Abstract: > The IPv6 Neighbor Discovery (ND) Protocol includes an ICMPv6 Router > Advertisement (RA) message. The RA message contains three flags, > indicating the availability of address auto-configuration mechanisms > and other configuration. These are the M, O, and A flags. These > flags by definition are advisory, not prescriptive. >=20 > This document describes divergent host behaviors observed in popular > operating systems. It also discusses operational problems that > divergent behaviors might cause. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem-05 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-dhcpv6-slaac-problem= -05 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Jul 6 03:51:42 2015 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 98FFD1A00BC for ; Mon, 6 Jul 2015 03:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 OuG2zJg7M_vn for ; Mon, 6 Jul 2015 03:51:38 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id 69E1E1A007C for ; Mon, 6 Jul 2015 03:51:37 -0700 (PDT) Received: from [10.235.142.188] (unknown [58.200.235.35]) by centos (Coremail) with SMTP id AQAAf3ArzwaLXZpVp8fcAA--.15083S2; Mon, 06 Jul 2015 18:50:52 +0800 (CST) Message-ID: <559A5DB6.4090602@cernet.edu.cn> Date: Mon, 06 Jul 2015 18:51:34 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: v6ops@ietf.org References: <201507041147.t64Bl2oR005661@irp-lnx1.cisco.com> In-Reply-To: <201507041147.t64Bl2oR005661@irp-lnx1.cisco.com> Content-Type: multipart/alternative; boundary="------------080808070001080104090300" X-CM-TRANSID: AQAAf3ArzwaLXZpVp8fcAA--.15083S2 X-Coremail-Antispam: 1UD129KBjvJXoW7CFWrJw1kXr1DAr45Wry8Xwb_yoW8Xw43pa 95Xw45Grn8Jr1rJa1kWw1Iqw1rA34fW3yUtF13Jw1YyFZ8tF109FnYkrsIvrWjqF95JFZr Xr4I9ry5GrnIqrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUqYb7Iv0xC_Zr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Jr0_ Gr1l84ACjcxK6I8E87Iv67AKxVWUJVW8JwA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_Jr0_Gr 1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG6I8vx48I62xC7I0kMcIj6I8E87Iv67AK xVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41l7480Y4vEI4kI2Ix0rV Aqx4xJMxkIecxEwVAFwVW8twCF04k20xvY0x0EwIxGrwC20s026c02F40E14v26r106r1r MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr4 1lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1l IxAIcVCF04k26cxKx2IYs7xG6rW3Jr0E3s1lIxAIcVC2z280aVAFwI0_Gr0_Cr1lIxAIcV C2z280aVCY1x0267AKxVW8JVW8JrUvcSsGvfC2KfnxnUUI43ZEXa7IU1uT5PUUUUU== X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/ Archived-At: Cc: draft-bao-v6ops-rfc6145bis@tools.ietf.org Subject: Re: [v6ops] new draft: draft-bao-v6ops-rfc6145bis 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, 06 Jul 2015 10:51:40 -0000 This is a multi-part message in MIME format. --------------080808070001080104090300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit fred@cisco.com ??: > A new draft has been posted, at http://tools.ietf.org/html/draft-bao-v6ops-rfc6145bis. Please take a look at it and comment. > We have submitted this draft to look for v6ops' comments. The changes compared with RFC6145 are: (1) From the erratum report http://www.rfc-editor.org/errata_search.php?rfc=6145 (2) From 6man's document concerning "Deprecating the Generation of IPv6 Atomic Fragments" https://datatracker.ietf.org/doc/draft-ietf-6man-deprecate-atomfrag-generation/ Ntote that RFC6145 already has this mechanism, but it is just an option. The rfc6145bis makes this mechanism the default and the only one. (3) Refer to RFC6791 for "Stateless Source Address Mapping for ICMPv6 Packets" https://datatracker.ietf.org/doc/rfc6791/ (4) Include EAM address mapping algoritm which is the current work of v6ops, "Explicit Address Mappings for Stateless IP/ICMP Translation" https://datatracker.ietf.org/doc/draft-ietf-v6ops-siit-eam/ There are some discussions concerning this issue, since EAM is an address mapping algorithm (RFC6052's alternative), not a protocol mapping algorithm. We include EAM in RFC6145bis because it is just a static configuration and simple. If additional details, for example hairpinning, needs to be included, I think those details should be in another document. We are looking for the comments. xing > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --------------080808070001080104090300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit fred@cisco.com 写道: 
A new draft has been posted, at http://tools.ietf.org/html/draft-bao-v6ops-rfc6145bis. Please take a look at it and comment.

We have submitted this draft to look for v6ops' comments.

The changes compared with RFC6145 are:

(1)  From the erratum report
      http://www.rfc-editor.org/errata_search.php?rfc=6145

(2)  From 6man's document concerning "Deprecating the Generation of IPv6 Atomic Fragments"
      https://datatracker.ietf.org/doc/draft-ietf-6man-deprecate-atomfrag-generation/
      Ntote that RFC6145 already has this mechanism, but it is just an option. The rfc6145bis makes this mechanism the default and the only one.

(3)  Refer to RFC6791 for "Stateless Source Address Mapping for ICMPv6 Packets"
      https://datatracker.ietf.org/doc/rfc6791/

(4)  Include EAM address mapping algoritm which is the current work of v6ops, "Explicit Address Mappings for Stateless IP/ICMP Translation"
      https://datatracker.ietf.org/doc/draft-ietf-v6ops-siit-eam/
      There are some discussions concerning this issue, since EAM is an address mapping algorithm (RFC6052's alternative), not a protocol mapping algorithm.  We  include EAM in RFC6145bis because it is just a static configuration and simple. If additional details, for example hairpinning, needs to be included, I think those details should be in another document.

We are looking for the comments.

xing


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

--------------080808070001080104090300-- From nobody Mon Jul 6 03:58:59 2015 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 36BD51A017D; Mon, 6 Jul 2015 03:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YpdC6td1E2Mh; Mon, 6 Jul 2015 03:58:57 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8DB1A007E; Mon, 6 Jul 2015 03:58:56 -0700 (PDT) Received: from [10.235.142.188] (unknown [58.200.235.35]) by centos (Coremail) with SMTP id AQAAf3Db3+80X5pV68fcAA--.17976S2; Mon, 06 Jul 2015 18:57:56 +0800 (CST) Message-ID: <559A5F5F.1010706@cernet.edu.cn> Date: Mon, 06 Jul 2015 18:58:39 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Brian E Carpenter References: <20150704074712.9480.20007.idtracker@ietfa.amsl.com> <559840C1.30004@gmail.com> In-Reply-To: <559840C1.30004@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID: AQAAf3Db3+80X5pV68fcAA--.17976S2 X-Coremail-Antispam: 1UD129KBjvdXoW5Kw1DCF43CryxJFyfJryUtrb_yoWxWrb_tw 1vyayfCr4UGrnrtanrtayxCw15KF9Yyr4ru34Fq3y7uFy8Cr4kuwn2k39xZ3WxGr1DKw1a gFn8AayDu347ujkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUbnkYjsxI4VWxJwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8EF7xvwVC0I7IYx2IY67AKxVWUJVWUCwA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVWUJVW8 JwA2z4x0Y4vEx4A2jsIE14v26r1j6r4UM28EF7xvwVC2z280aVCY1x0267AKxVWUJVW8Jw AS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IY x2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4 x0Y48IcVAKI48JMxkIecxEwVAFwVW8twCF04k20xvY0x0EwIxGrwC20s026c02F40E14v2 6r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_JF1lIxkGc2 Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_ Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rWUJVWrZr1UMIIF0xvEx4A2jsIE14v26r4j6F 4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVjvjDU0xZFpf9x07jeNtxU UUUU= X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/ Archived-At: Cc: IPv6 Operations , draft-bao-v6ops-rfc6145bis@ietf.org Subject: Re: [v6ops] I-D Action: draft-bao-v6ops-rfc6145bis-00.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, 06 Jul 2015 10:58:58 -0000 Thanks for the comments. Some issues (hairpinn) are under discussion and we will address your comments in the next version. xing Brian E Carpenter 写道: > Hi, > > The content looks good except for section 6.2 (hairpinning) which seems superficial > and includes a broken reference. > > There are nits: > > >> This document updates RFC 6145. >> > > Surely that should be "obsoletes" (if not, it isn't a "bis" document). > > IMHO, unless you have explicit permission from the author of RFC 2765, > you still need the boilerplate. > > A short "Changes from RFC6145" appendix would be useful. > > Regards > Brian > > > From nobody Mon Jul 6 04:00:16 2015 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 2E6541A00E3 for ; Mon, 6 Jul 2015 04:00:15 -0700 (PDT) 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 ijgl5j_xEG2A for ; Mon, 6 Jul 2015 04:00:13 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id AE8201A00BC for ; Mon, 6 Jul 2015 04:00:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D9DC22CFDD for ; Mon, 6 Jul 2015 14:00:10 +0300 (EEST) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZcrhZlW1SaZ for ; Mon, 6 Jul 2015 14:00:10 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 1C1772CFDC for ; Mon, 6 Jul 2015 14:00:10 +0300 (EEST) (envelope-from jari.arkko@piuha.net) From: Jari Arkko X-Pgp-Agent: GPGMail 2.5 Content-Type: multipart/signed; boundary="Apple-Mail=_F42F7F08-3760-4FDA-B5D4-966D0AE943D7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Mon, 6 Jul 2015 14:00:08 +0300 Message-Id: To: v6ops@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [v6ops] an IPv6 experience and thoughts on sudden changes 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, 06 Jul 2015 11:00:15 -0000 --Apple-Mail=_F42F7F08-3760-4FDA-B5D4-966D0AE943D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I recently had a good experience with IPv6 being available for large = number of consumers in Finland. The country went from minimal (to be honest, = embarrassing) level of IPv6 deployment to quite decent numbers in a matter of weeks, = and the trend seems to continue. This inspired me to think about changes in the Internet and when they = take long and when they can be sudden. Here are my thoughts on the topic: http://www.ietf.org/blog/2015/07/sudden-changes-and-ipv6-for-everyone/ Jari --Apple-Mail=_F42F7F08-3760-4FDA-B5D4-966D0AE943D7 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 - https://gpgtools.org iQIcBAEBCgAGBQJVml+5AAoJEM80gCTQU46qozoP/1rFaj09HHa+CoELfW/000Vy kVu9dgtq7pwTxL8MO5IC+GnUby4bGJx1Isqoge3MylsVL2RRT3SpId3VK69GDjC7 xu6cJAwTUgaos4ZaxPEUsNPZggibOSzu6qmz7G0V38m7vqOMM8YMZvqVqyzstahY yM9hgkhq6RihJflFOBzLx9WcGNQLcAzNHz1gSI9ygTqueE3xP/UDxh5lj+B7QjUl qkVZTaIe8r132xPNkTx6Mt8vB4ZLB3Y8lrIduQWAZipti6h8cwbhlOrgWFg2uJW0 1aJEjHfwvGZBMfMT/Z6f51iuMCqhHWZzBhQ/VTl2TK2CeAjaE6Qez5HBWFyGc6ht XPeQjLj2bUuJeoXFBxtFsupoJTE+lJY3AKbK2+alBpgm7X+VFGGoN6pl5yK56lyV KGGWti0ydsIiZ5YQnw2jvfNAECcWbZy0KNpMFq/vHG7ZRBHd2PKSJD+oWCmM6IOH C+IfP1AZ6rS4uHgz5G6arrMd4Bfi817+2sYbKg43vQXrbm8hzDJ1dlGVhxZXkbRi FaQn0k5ChyUvQ8HZXRVIamyaXVz/2YlOQ8Ck86JmHWv5/s01zkumwH1y3s9Kl/mY KBeYznLy7kl27KeXKBDuFTonZvFakYpSlnEYUjG0O0Gg/HIqiqLtTbEIgRZ8zSDD VA9Rq953eT9CX15yFL+s =8zRL -----END PGP SIGNATURE----- --Apple-Mail=_F42F7F08-3760-4FDA-B5D4-966D0AE943D7-- From nobody Mon Jul 6 04:47:05 2015 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 6675C1A8AD6 for ; Mon, 6 Jul 2015 04:47:04 -0700 (PDT) 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 27tJ-IdVBlK9 for ; Mon, 6 Jul 2015 04:47:03 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37F861A8A9A for ; Mon, 6 Jul 2015 04:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=139; q=dns/txt; s=iport; t=1436183223; x=1437392823; h=date:from:message-id:to:subject:cc; bh=pdVeFHo3IxG5ao4Dqwyk9hNkULDGsWnCVlf1umwX/MA=; b=E9S3eO17puYBlg7VDMDxAHZkiHQP0p8XeD7X+yk7q73LcEP4aPfvLmkM zuUhBTqYwuuSMXVMYDUTVnx4gidRdJkoibhUxIjz2LwloMBN8FqrwVtoa a9dujBpqriRshCsGG/OiYA/W7xqeEeIclzKTpJG8EOPQVDyi+hVQ5nG8j E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AEHADdaZpV/4MNJK1cgxJUYa5vAY5mCYFuhW4JgTA4FAEBAQEBAQGBCkEBAgKDYH08NIkOAQ3IWwEBAQcBAQEBAR2LS4UGHYQVBY0Ihw2EYohARINRkwcmhBuDGgEBAQ X-IronPort-AV: E=Sophos;i="5.15,414,1432598400"; d="scan'208";a="12941050" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-2.cisco.com with ESMTP; 06 Jul 2015 11:47:02 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t66Bl2JY006158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Jul 2015 11:47:02 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 t66Bl1dV028333; Mon, 6 Jul 2015 04:47:01 -0700 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id t66Bl10n028320; Mon, 6 Jul 2015 04:47:01 -0700 Date: Mon, 6 Jul 2015 04:47:01 -0700 From: fred@cisco.com Message-Id: <201507061147.t66Bl10n028320@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Cc: draft-xcf-v6ops-chinatelecom-deployment@tools.ietf.org Subject: [v6ops] new draft: draft-xcf-v6ops-chinatelecom-deployment 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, 06 Jul 2015 11:47:04 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-xcf-v6ops-chinatelecom-deployment. Please take a look at it and comment. From nobody Mon Jul 6 04:47:11 2015 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 544111A8A9A for ; Mon, 6 Jul 2015 04:47:05 -0700 (PDT) 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 1PBuYE38mRkG for ; Mon, 6 Jul 2015 04:47:04 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D23B91A8AAD for ; Mon, 6 Jul 2015 04:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=142; q=dns/txt; s=iport; t=1436183223; x=1437392823; h=date:from:message-id:to:subject:cc; bh=WFNXt3EiVhdIO2WhGGsHUhyecyFhAe8ot89jmYPW3cI=; b=KHnY5uhB+5Zk9pVHOqffWODLqO+MLAesSlUZzYT7ckZkhQKNq0sndrLM wHo5vpN2ITHqGoBdjUBvZJZaWbGJzE20h461OdBZ/1B7uiPAu5hvz1JER CZCjCBJvnKxIAOx5RgY2ZWaFDH8qHYXLGmztvFWPIK0OLxZ/MFIZozAdK A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AEHABmaZpV/4YNJK1cgxJUYa5vAY5mCYFuhW4JgTA4FAEBAQEBAQGBCkEBAgKDYH08NIkOAQ3IWAEBAQEBBQEBAQEBARyLS4UGHYMBgRQFjQiHDYRiiEBEg1GTByaEG4MaAQEB X-IronPort-AV: E=Sophos;i="5.15,414,1432598400"; d="scan'208";a="165886658" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-4.cisco.com with ESMTP; 06 Jul 2015 11:47:03 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t66Bl2jp017402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Jul 2015 11:47:03 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 t66Bl28g028341; Mon, 6 Jul 2015 04:47:02 -0700 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id t66Bl1AE028312; Mon, 6 Jul 2015 04:47:01 -0700 Date: Mon, 6 Jul 2015 04:47:01 -0700 From: fred@cisco.com Message-Id: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Cc: draft-colitti-v6ops-host-addr-availability@tools.ietf.org Subject: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability 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, 06 Jul 2015 11:47:05 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-colitti-v6ops-host-addr-availability. Please take a look at it and comment. From nobody Mon Jul 6 04:47:12 2015 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 803141A8AA0 for ; Mon, 6 Jul 2015 04:47:05 -0700 (PDT) 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 yPgbyG3U2KZF for ; Mon, 6 Jul 2015 04:47:04 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF2921A8998 for ; Mon, 6 Jul 2015 04:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=136; q=dns/txt; s=iport; t=1436183223; x=1437392823; h=date:from:message-id:to:subject:cc; bh=bUzwM6jORs+2gEXrb6lP9szEQI7uNH+rw9c3trLTMpU=; b=AHVhZNnheY8NhF0/ukDA/KRVcn05nRWR9HcfhRJNDehEaZ24DWDus2ZE h8kNTqvny1suM0F6m7vKZZwuJZHecWRTeqVmpYPww/clOwRZKt4UMczkl QP049zOWCvZN/jaZsj267HwIkZXYEk1xCtcsPI9kzLVMyJ8iGggAlJ16C 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AEHACeaZpV/4ENJK1cgxJUYa5vAY5mCYFuhW4JgTA4FAEBAQEBAQGBCkEBAgKDYH08NIkOAQ3IXAEBCAEBAQEBHYtLhQYdhBUFjQiHDYRiiEBEg1GTByaEG4MaAQEB X-IronPort-AV: E=Sophos;i="5.15,414,1432598400"; d="scan'208";a="9201422" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-5.cisco.com with ESMTP; 06 Jul 2015 11:47:03 +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 t66Bl2an010293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Jul 2015 11:47:03 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 t66Bl1LE028328; Mon, 6 Jul 2015 04:47:01 -0700 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id t66Bl1Ep028316; Mon, 6 Jul 2015 04:47:01 -0700 Date: Mon, 6 Jul 2015 04:47:01 -0700 From: fred@cisco.com Message-Id: <201507061147.t66Bl1Ep028316@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Cc: draft-hui-v6ops-ipv6trans-select-nfv@tools.ietf.org Subject: [v6ops] new draft: draft-hui-v6ops-ipv6trans-select-nfv 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, 06 Jul 2015 11:47:05 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-hui-v6ops-ipv6trans-select-nfv. Please take a look at it and comment. From nobody Mon Jul 6 04:47:14 2015 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 372411A8F44 for ; Mon, 6 Jul 2015 04:47:10 -0700 (PDT) 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 jLww37VY_9Rq for ; Mon, 6 Jul 2015 04:47:06 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2CC51A8AD1 for ; Mon, 6 Jul 2015 04:47:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=133; q=dns/txt; s=iport; t=1436183226; x=1437392826; h=date:from:message-id:to:subject:cc; bh=GJM8iufn9nCQJ+jDClFWSx0o1rEUt/E+xRpo3eES8Y4=; b=fj60w6UVCsthu1idljRMx9TpWV5VPiwUou96NLfn2AmJE6d8peBkTgAs s361AWZAQk5gLyjTrUjdymEDcbnkVLLyKJQLWXkWRrVydQbFYuv6ja6hs Q/SwzdMOB5zoK/oE26IWu82YYK8Vlxtnrik80idW0dZrq0TC1eS3//jZO g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AEHACIappV/4wNJK1cgxJUYa5vAY5mCYFuhW4JgTA4FAEBAQEBAQGBCkEBAgKDYH08NIkOAQ3IWwEBAQcBAQEBAR2LS4UGHYQVBY0Ihw2EYohARINRkwcmhBuDGgEBAQ X-IronPort-AV: E=Sophos;i="5.15,414,1432598400"; d="scan'208";a="9202780" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-6.cisco.com with ESMTP; 06 Jul 2015 11:47:03 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t66Bl2FM024903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Jul 2015 11:47:03 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 t66Bl2oC028342; Mon, 6 Jul 2015 04:47:02 -0700 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id t66Bl1l8028324; Mon, 6 Jul 2015 04:47:01 -0700 Date: Mon, 6 Jul 2015 04:47:01 -0700 From: fred@cisco.com Message-Id: <201507061147.t66Bl1l8028324@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Cc: draft-xli-v6ops-cernet-deployment@tools.ietf.org Subject: [v6ops] new draft: draft-xli-v6ops-cernet-deployment 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, 06 Jul 2015 11:47:10 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-xli-v6ops-cernet-deployment. Please take a look at it and comment. From nobody Mon Jul 6 05:33:42 2015 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 A8CC81ACEBE for ; Mon, 6 Jul 2015 05:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 H0Wed-BMLu2V for ; Mon, 6 Jul 2015 05:33:40 -0700 (PDT) Received: from mail-qk0-f169.google.com (mail-qk0-f169.google.com [209.85.220.169]) (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 B35E91ACEC2 for ; Mon, 6 Jul 2015 05:33:38 -0700 (PDT) Received: by qkeo142 with SMTP id o142so115650465qke.1 for ; Mon, 06 Jul 2015 05:33:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=VsE8x5PDxB4nQKgqnKFpwYlUNV+mjtrsZQOm+s6a5+0=; b=mEmHvjO5LAj6DIJCKPTO02pIq1I6x7dC5p8PDERCMXviQxoublmVVUbhgJkzJw2jHZ 9XTrGmWKDQvcjzokl+Hgmtt2IeXnVxxMKh1NLZxzQtt24BzMStkCXEHckc7hD22wsTby YpZOq0Wax/nL3YvFyUU5CGbBI2Uvs8nV4xPuUlglhMDEsp8wnbQOMy2sb1c2xnT7WWVO AKK3T8gBMdLV/sJjokXwej6dthwCN4/uyxFaIVfFbfe4lc3xMqEWNqBpLOwL3RTap4fG gbUhQhJZL2CI06G8WPjx9V36wJcl86bBc6m/VfOvzcasb5wBaXsqhMexUGyEa7hzwrAW E8bw== X-Gm-Message-State: ALoCoQleIUOBjSqp0rpdV20oEISfQjIOyOgUSiwqXqlozaEjuhadhxHmKzwQOKVj/gcxw2Ob4Qt5 X-Received: by 10.55.22.161 with SMTP id 33mr93550464qkw.11.1436186018009; Mon, 06 Jul 2015 05:33:38 -0700 (PDT) Received: from [192.168.1.44] ([24.53.47.130]) by mx.google.com with ESMTPSA id q22sm9171743qkq.4.2015.07.06.05.33.36 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Jul 2015 05:33:37 -0700 (PDT) Message-ID: <559A759F.3080201@jive.com> Date: Mon, 06 Jul 2015 08:33:35 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: fred@cisco.com, v6ops@ietf.org References: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> In-Reply-To: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-colitti-v6ops-host-addr-availability@tools.ietf.org Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability 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, 06 Jul 2015 12:33:41 -0000 Le 2015-07-06 07:47, fred@cisco.com a écrit : > A new draft has been posted, at http://tools.ietf.org/html/draft-colitti-v6ops-host-addr-availability. Please take a look at it and comment. +1000 Simon From nobody Mon Jul 6 05:46:41 2015 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 B866E1ACF19 for ; Mon, 6 Jul 2015 05:46:39 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains text/plain,.exe X-Spam-Flag: NO X-Spam-Score: 1.993 X-Spam-Level: * X-Spam-Status: No, score=1.993 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 krqp5EISMyRn for ; Mon, 6 Jul 2015 05:46:38 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4A161ACEC5 for ; Mon, 6 Jul 2015 05:46:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 6B50A37; Mon, 6 Jul 2015 14:46:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:content-transfer-encoding:date :date:in-reply-to:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=mail; t= 1436186793; bh=HS/d51jl3PKJg8QkIofmHtm1/0LSD9hxXKrZLUL5jyQ=; b=E DeAK7izalgVmGpU6iaYice0tSmGm5CFRmOCjbonehk4qonp1LF0maZwj6EUrR4TJ sCyU5UyPF33sFW0dTGuM652tq57ImIbMfEpL4dJYI72Au1uO35EtyvmKnVwImyvl hYf/0wNcF8ChILUzL3NKMCx5+Kp2LkZVIV9co8m3DM= 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 3bGEaY5Dhu6P; Mon, 6 Jul 2015 14:46:33 +0200 (CEST) Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTPSA id 3BCD234; Mon, 6 Jul 2015 14:46:33 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann In-Reply-To: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> Date: Mon, 6 Jul 2015 14:46:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <627F6AA0-C41E-4F9B-9569-FE8E2AF304F0@steffann.nl> References: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> To: draft-colitti-v6ops-host-addr-availability@tools.ietf.org X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability 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, 06 Jul 2015 12:46:39 -0000 Hi, > A new draft has been posted, at = http://tools.ietf.org/html/draft-colitti-v6ops-host-addr-availability. = Please take a look at it and comment. Nice draft, and very much needed. I only have a few comments on 8.2. = Address space management: > In IPv4, all but the world's largest IPv4 networks can be addressed > using RFC 1918 space. The total size of net 10 is roughly 2^24 (16 > million) endpoints, with each endpoint receiving one IPv4 address. > In IPv6, that is equivalent to assigning one /64 per host out of a > /40. Under current RIR policies, a /40 is easy to obtain for an > enterprise network. I wouldn=E2=80=99t say that a /40 is easy to obtain for enterprise = networks. The usual size is a /48. Of course the networks that actually = use all of 10/8 would should no problem getting a /40, but that isn=E2=80=99= t true for all enterprises. Suggested new text: """ In IPv4, all but the world's largest IPv4 networks can be addressed using RFC 1918 space. Many networks can be numbered with e.g. 192.168.0.0/16 which has roughly 2^16 (65536) endpoints, with each endpoint receiving one IPv4 address. In IPv6, that is equivalent to assigning one /64 per host out of a /48. Under current RIR policies, a /48 is easy to obtain for an enterprise network. Networks that need a bigger block of RFC 1918 space use 10.0.0.0/8=20 which is is roughly 2^24 (16 million) endpoints. The equivalent in IPv6 would be assigning a /64 per host out of a /40. Enterprises of such size can easily obtain a /40 under current RIR policies. """ or something similar. > In other words, assigning a single IPv6 /64 per > host is as feasible as assigning a single IPv4 address per host. >=20 > Currently, residential users receive one IPv4 address and a /56 or > /60 IPv6 prefix. I know lots of ISPs that give residential users a /48. I'm afraid this = text might suggest giving them small(er) sizes. Maybe change it to: """ Currently, residential users often receive one IPv4 address and a /48, a /56 or even something as tiny as a /60 IPv6 prefix. """ Ok, maybe leave the "even something as tiny as" bit out ;) But that's = the message I would like to give to the reader. > While such networks do not have enough space to > assign a /64 per device, today such networks almost universally use > SLAAC. >=20 > Unlike IPv4 where addresses came at a premium, in all these networks, > there is enough IPv6 address space to supply clients with multiple > IPv6 addresses. +1000 Cheers, Sander From nobody Mon Jul 6 14:01:13 2015 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 A108D1B327F for ; Mon, 6 Jul 2015 14:01:11 -0700 (PDT) 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 lJa8_z1OXxvd for ; Mon, 6 Jul 2015 14:01:09 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A40F71B3265 for ; Mon, 6 Jul 2015 14:01:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6211; q=dns/txt; s=iport; t=1436216469; x=1437426069; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=NViG7Fe1t8dbd8mWX44tZnUr9oI8CwOUh+/zKV9t62s=; b=YZVO1qgvggUaB9k0XDGBSyfJG1fM83g3eSDAOJovxHStnaUczyyTFQh4 hvD/xqVN2jLfuULMBhEkh4MVGape10u26u0tSjRWUI6MZkoB+GphPTXDU HfXTkDuAq0Ay58hZZd7AHtCn2ujMQswUc3kEA3PgFqEayWM0oTdnw6TN/ k=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C+AwCw65pV/5RdJa1CGoMSVGAGvVcJgXCFdQKBOzgUAQEBAQEBAYEKhCMBAQEDAXkFCwIBCBguMiUCBA4FCQWIGAgNOrdLk1ABAQEBAQEBAQEBAQEBAQEBAQEBAQEXi0uFBgeDF4EUBZQVAYIqgVKHa5hWJoN7bwGBRoEEAQEB X-IronPort-AV: E=Sophos;i="5.15,417,1432598400"; d="asc'?scan'208";a="166082356" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Jul 2015 21:01:08 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t66L18WJ009549 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 Jul 2015 21:01:08 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.49]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Mon, 6 Jul 2015 16:01:08 -0500 From: "Fred Baker (fred)" To: Jari Arkko Thread-Topic: [v6ops] an IPv6 experience and thoughts on sudden changes Thread-Index: AQHQuC7hvspRw4sjWEmwxwR6XMiTcg== Date: Mon, 6 Jul 2015 21:01:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.123] Content-Type: multipart/signed; boundary="Apple-Mail=_DD22BAD0-42C1-45F4-BECF-26815FB167CF"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] an IPv6 experience and thoughts on sudden changes 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, 06 Jul 2015 21:01:11 -0000 --Apple-Mail=_DD22BAD0-42C1-45F4-BECF-26815FB167CF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jul 6, 2015, at 4:00 AM, Jari Arkko wrote: >=20 > I recently had a good experience with IPv6 being available for large = number of > consumers in Finland. The country went from minimal (to be honest, = embarrassing) > level of IPv6 deployment to quite decent numbers in a matter of weeks, = and > the trend seems to continue. Rather a spike in = https://www.vyncke.org/ipv6status/project.php?metric=3Dp&timeforward=3D&ti= mebackward=3D&country=3Dfi > This inspired me to think about changes in the Internet and when they = take > long and when they can be sudden. Here are my thoughts on the topic: >=20 > http://www.ietf.org/blog/2015/07/sudden-changes-and-ipv6-for-everyone/ >=20 > Jari Thanks. We're actually seeing sudden changes in a couple of other = countries as well. Looking at Google data = (https://www.vyncke.org/ipv6status/project.php?metric=3Dp&country=3Dus), = during the past quarter US access to Google using IPv6 has moved from = 16% to 22%, Poland has had a spike = (https://www.vyncke.org/ipv6status/project.php?metric=3Dp&timeforward=3D&t= imebackward=3D&country=3Dpl), Saudi Arabia has had a depand there are = others. More generally, you might want to glance through the following. Belgium = gets a gold star, and several countries either show a recent spike or = are now seeing in excess of 10% of their accesses to Google using IPv6. = https://www.vyncke.org/ipv6status/project.php?metric=3Dp&timeforward=3D&ti= mebackward=3D&country=3Dat = https://www.vyncke.org/ipv6status/project.php?metric=3Dp&timeforward=3D&ti= mebackward=3D&country=3Dau = https://www.vyncke.org/ipv6status/project.php?metric=3Dp&timeforward=3D&ti= mebackward=3D&country=3Dax = https://www.vyncke.org/ipv6status/project.php?metric=3Dp&timeforward=3D&ti= mebackward=3D&country=3Dba = https://www.vyncke.org/ipv6status/project.php?metric=3Dp&timeforward=3D&ti= mebackward=3D&country=3Dbe = https://www.vyncke.org/ipv6status/project.php?metric=3Dp&timeforward=3D&ti= mebackward=3D&country=3Dbg = https://www.vyncke.org/ipv6status/project.php?metric=3Dp&timeforward=3D&ti= mebackward=3D&country=3Dbo = https://www.vyncke.org/ipv6status/project.php?metric=3Dp&timeforward=3D&ti= mebackward=3D&country=3Dbr = https://www.vyncke.org/ipv6status/project.php?metric=3Dp&timeforward=3D&ti= mebackward=3D&country=3Dch = https://www.vyncke.org/ipv6status/project.php?metric=3Dp&timeforward=3D&ti= mebackward=3D&country=3Dcz = https://www.vyncke.org/ipv6status/project.php?metric=3Dp&timeforward=3D&ti= mebackward=3D&country=3Dde = https://www.vyncke.org/ipv6status/project.php?metric=3Dp&timeforward=3D&ti= mebackward=3D&country=3Dec = https://www.vyncke.org/ipv6status/project.php?metric=3Dp&timeforward=3D&ti= mebackward=3D&country=3Dee = https://www.vyncke.org/ipv6status/project.php?metric=3Dp&timeforward=3D&ti= mebackward=3D&country=3Dfi = https://www.vyncke.org/ipv6status/project.php?metric=3Dp&timeforward=3D&ti= mebackward=3D&country=3Dfr = https://www.vyncke.org/ipv6status/project.php?metric=3Dp&timeforward=3D&ti= mebackward=3D&country=3Dgr = https://www.vyncke.org/ipv6status/project.php?metric=3Dp&timeforward=3D&ti= mebackward=3D&country=3Dhu = https://www.vyncke.org/ipv6status/project.php?metric=3Dp&timeforward=3D&ti= mebackward=3D&country=3Die = https://www.vyncke.org/ipv6status/project.php?metric=3Dp&timeforward=3D&ti= mebackward=3D&country=3Djp = https://www.vyncke.org/ipv6status/project.php?metric=3Dp&timeforward=3D&ti= mebackward=3D&country=3Dkr = https://www.vyncke.org/ipv6status/project.php?metric=3Dp&timeforward=3D&ti= mebackward=3D&country=3Dlu = https://www.vyncke.org/ipv6status/project.php?metric=3Dp&timeforward=3D&ti= mebackward=3D&country=3Dmy = https://www.vyncke.org/ipv6status/project.php?metric=3Dp&timeforward=3D&ti= mebackward=3D&country=3Dnl = https://www.vyncke.org/ipv6status/project.php?metric=3Dp&timeforward=3D&ti= mebackward=3D&country=3Dno = https://www.vyncke.org/ipv6status/project.php?metric=3Dp&timeforward=3D&ti= mebackward=3D&country=3Dnz = https://www.vyncke.org/ipv6status/project.php?metric=3Dp&timeforward=3D&ti= mebackward=3D&country=3Dpe = https://www.vyncke.org/ipv6status/project.php?metric=3Dp&timeforward=3D&ti= mebackward=3D&country=3Dpl = https://www.vyncke.org/ipv6status/project.php?metric=3Dp&timeforward=3D&ti= mebackward=3D&country=3Dpt = https://www.vyncke.org/ipv6status/project.php?metric=3Dp&timeforward=3D&ti= mebackward=3D&country=3Dsa = https://www.vyncke.org/ipv6status/project.php?metric=3Dp&timeforward=3D&ti= mebackward=3D&country=3Dse = https://www.vyncke.org/ipv6status/project.php?metric=3Dp&timeforward=3D&ti= mebackward=3D&country=3Dsg = https://www.vyncke.org/ipv6status/project.php?metric=3Dp&timeforward=3D&ti= mebackward=3D&country=3Dus --Apple-Mail=_DD22BAD0-42C1-45F4-BECF-26815FB167CF 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 iQIVAwUBVZrskkayAOS/EQ8MAQLFpw//XTB7dCxSb9Bglb4MIEokmQ1bSwUyJ4bV Iwp1E44iBI9itBxlm6dDiytEuDI9Mgr6EM+BLyE2cFguF5OulDy8QUAFtrAn/ao5 YagikGVFH3e8AVvQaLJNpIOPsU6yC/a+a1aM7MbNASbAE7lRIw6bulDL3PVLmeqw f1Zl9jgj4Csc3XjKTPfe+1eEz/3+x0P5eGYsFunLaE7B9N6ta+Dwgdb07W1yPaQn UpDE3pbhZy3TzR+j2llJ5EFsYwz1+vYieJUbu18HQ2Tolgx0EpfZiWhZEX8IQTYl 48GUr28YFUqoHae6sEerdjMbhVUUxzGYIu8sNhGWDHmc0eH1PBAKehPqFIe05qTH JPGZhLs7b6gdWr5NcpohCpQ0kaSIB8Yg+VoP2o0afet6TsosDPDZvnxxRjaUUy1d vt0s1/OiDSjycF6eQgLuma2EZAtzviucRrXkM6FbnHSYrQ4kHZzzVBoSnws4Vh3c ewJ2GJjOAKnF36s/HDBmZ/kpOGAd41EelkEouUKjcsPnJFKLoee4aCFD2C5nbj6P 6/lFKzQSRbkijbrdsY3Z1wj0nOXACp6qui2t+fLIBskf7W3jMr7GPOFKuxmEeXD+ 3Ny+d9FI0xJoUUMzSNqx5TYis0i14QoPNdI3YTYtaLyXZWfkUyByWg4o39DSr2aS kABtqpDSaxQ= =xXlA -----END PGP SIGNATURE----- --Apple-Mail=_DD22BAD0-42C1-45F4-BECF-26815FB167CF-- From nobody Mon Jul 6 14:25:13 2015 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 DB92D1A0063; Mon, 6 Jul 2015 14:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ziH37OvIPfS3; Mon, 6 Jul 2015 14:25:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3306E1A00A4; Mon, 6 Jul 2015 14:25:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706212506.2640.97532.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 14:25:06 -0700 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-08.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, 06 Jul 2015 21:25:10 -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 : Some Design Choices for IPv6 Networks Authors : Philip Matthews Victor Kuarsingh Filename : draft-ietf-v6ops-design-choices-08.txt Pages : 21 Date : 2015-07-06 Abstract: This document presents advice on certain routing-related design choices that arise when designing IPv6 networks (both dual-stack and IPv6-only). The intended audience is someone designing an IPv6 network who is knowledgeable about best current practices around IPv4 network design, and wishes to learn the corresponding practices for IPv6. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-v6ops-design-choices-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-design-choices-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 6 14:38:39 2015 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 4A9D31A0282 for ; Mon, 6 Jul 2015 14:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wF3ZHolOgugy for ; Mon, 6 Jul 2015 14:38:36 -0700 (PDT) Received: from tor-smtp-02.primus.ca (mail20.primus.ca [216.254.141.187]) by ietfa.amsl.com (Postfix) with ESMTP id BAE8D1A0020 for ; Mon, 6 Jul 2015 14:38:36 -0700 (PDT) Received: from [24.114.81.200] (helo=[172.20.10.4]) by tor-smtp-02.primus.ca with esmtpa (Exim 4.84) (envelope-from ) id 1ZCE60-0007Mo-1e; Mon, 06 Jul 2015 17:38:36 -0400 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Philip Matthews In-Reply-To: <20150706212506.2640.97532.idtracker@ietfa.amsl.com> Date: Mon, 6 Jul 2015 17:38:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <23C53E8B-6029-4782-8567-3A9984D556AC@magma.ca> References: <20150706212506.2640.97532.idtracker@ietfa.amsl.com> To: v6ops list X-Mailer: Apple Mail (2.1085) X-Authenticated: philip_matthews - ([172.20.10.4]) [24.114.81.200] Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-08.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, 06 Jul 2015 21:38:38 -0000 Folks: Victor and I have just submitted a new revision of the Design Choices = draft. There are two main changes: 1. A new section called "Addresses" that discusses the pros and cons of = using PI vs. PA vs. Private addresses in your IPv6 or dual-stack = network. This addresses some comments we got during the WG Last Call = about using ULAs in certain situations. We consider this a significant = addition to the draft. 2. Added EIGRP to the section on IGP Choice. Some of you will recall = the discussion around this on the mailing list a couple of months ago. Victor and I have plans for more revisions to address other WG comments. = In particular, as you may remember, Victor and I have been gathering = hard data from operators around the IGPs that are actually used in = production networks. Unfortunately, Victor and I both got hit with other = stuff in the last few weeks, so we didn't have time to add this data to = the draft, or make some other planned changes. So consider this still a = work-in-progress with other changes coming. - Philip= From nobody Mon Jul 6 14:39:42 2015 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 96D561A0282 for ; Mon, 6 Jul 2015 14:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 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, 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 Tm64W2pYHsPg for ; Mon, 6 Jul 2015 14:39:40 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::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 A0AAA1A0020 for ; Mon, 6 Jul 2015 14:39:39 -0700 (PDT) Received: by wgck11 with SMTP id k11so151621813wgc.0 for ; Mon, 06 Jul 2015 14:39:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pAnubSZgkm+RwbR63w0nQffOEI/iPVWA5TWglYapezg=; b=GfftxBc8JBgE0Ad9wo5hjK3necGkTP0RVhiUMhWdrmXNe40mBTJY8zPP0CzG++N5fy HqBIYAdcg6JytAYUw25jqxRyhRdPwYOV9o7KxdBLTqogMSHWspBwl1kxj5bIGbavuuGS C7Zvh3jVS2c4Oi/a4ncTdzWuE7TALmvjEvQrJ4PKR0D5Mry0cnFNTc8rFchndZv7umZd x3cWfn2HgoDi841DZpcwbvyUhWSjmamAZFmenTvrrGSM762yJjtOLZLBRkTlPI3PyTbA 6XiFwIRZq9AYduK4of0xQd7tfmQOf1Bd+ATe1cdVKNALgogSxY4bFkKFIemVoVzrx5t5 VwUA== X-Received: by 10.194.2.68 with SMTP id 4mr1871403wjs.82.1436218778403; Mon, 06 Jul 2015 14:39:38 -0700 (PDT) Received: from [192.168.2.76] (254.56.223.213.rev.sfr.net. [213.223.56.254]) by mx.google.com with ESMTPSA id nb9sm30583253wic.10.2015.07.06.14.39.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 Jul 2015 14:39:37 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Andrew Yourtchenko X-Mailer: iPhone Mail (12H143) In-Reply-To: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> Date: Mon, 6 Jul 2015 23:39:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9290D0D1-062A-4DE0-A437-9A5F5045ACAC@gmail.com> References: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> To: "fred@cisco.com" Archived-At: Cc: "v6ops@ietf.org" , "draft-colitti-v6ops-host-addr-availability@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability 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, 06 Jul 2015 21:39:41 -0000 I read the draft and absolutely agree with the spirit.=20 Unfortunately, I think it won't work: As soon as the devices work "good enough" with a single address, appealing t= o increase the amount of work by administrators in the name of humanity is g= oing to fall on deaf ears. The only way I see to solve this is to always use SLAAC on the devices: eith= er 'externally' from the prefix received within the RA, or 'internally' from= within the prefix received via DHCP-PD, and provide a mandatory registratio= n mechanism for name-to-IP mapping.=20 If neither of the above works, as a backup effort the device can try getting= N addresses via DHCP IA_NA and release those that it does not need immediat= ely - and displaying a big yellow warning "This network may restrict IPv6 fu= nctionality and eat your kittens, contact your system administrator". Becaus= e ND is not going to happen on these 'extra' addresses, forwarding wise ther= e will be no impact, just some more DHCP traffic after attachment (the "limi= ted functionality" of course would need just one address and can start immed= iately). Those who want tracking can track the upper 64bits or use IA_NA and filter o= ut the addresses that are shortly lived. Of course to avoid being a religious crusade such an effort need to produce s= omething pragmatic - namely, a userland cross-platform API that would allow getting new addresses on dem= and by application and if needs to - implementing custom transport protocols= on top of those on a per-app-per-address basis. The above conjecture however is even less realistic than politely asking the= inconveniences away, so the logical conclusion from that is I fully support= this draft. --a > On 06 Jul 2015, at 13:47, fred@cisco.com wrote: >=20 > A new draft has been posted, at http://tools.ietf.org/html/draft-colitti-v= 6ops-host-addr-availability. Please take a look at it and comment. >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Jul 6 17:02:09 2015 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 6D8491A1DBE for ; Mon, 6 Jul 2015 17:02:07 -0700 (PDT) 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 CHcrNRZx4j0v for ; Mon, 6 Jul 2015 17:02:05 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DF181A1BE0 for ; Mon, 6 Jul 2015 17:02:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4974; q=dns/txt; s=iport; t=1436227326; x=1437436926; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=r4rJEzuFWxGdJwT2oPCZolbp5aHxs9TpUlVTNHGcXr0=; b=E+ZEAPFR9P0US2suzDrky+Ls5wMArte62j/UE+3b2ZCkcT/Dfz27+o1s BfPQWx5wWWm8HHfwtlXO/P/i2NwOMI1o7aCJMgSyOMVWSFIFM324+KL5R op9Pq8Xh8Ribxfb8qklyKXiUzXtBdVwbsCI/bqXrMjezGZFn0qtvkLrnK Q=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DAAwD9FZtV/4wNJK1cgxJUYAaxCYxOCYFkCoV3AoFAOBQBAQEBAQEBgQqEIwEBAQMBAQEBawsFCwIBCA4KLiEGCyUCBA4FDogLAwoIDcUdDYVuAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tLgk2BTQgLWQeDF4EUBYVchj2HfAGCKoFSBWCFIYFlgTpEg1GDD4hbg0CDXSaCBwUcVAF+b4EEJB+BBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,418,1432598400"; d="asc'?scan'208";a="165998377" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-6.cisco.com with ESMTP; 07 Jul 2015 00:02:05 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t670248r021504 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Jul 2015 00:02:04 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.49]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.03.0195.001; Mon, 6 Jul 2015 19:02:03 -0500 From: "Fred Baker (fred)" To: Andrew Yourtchenko Thread-Topic: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability Thread-Index: AQHQuEgnsal/sN+flU+Nn0z6zYUySg== Date: Tue, 7 Jul 2015 00:02:03 +0000 Message-ID: <39F63B55-977F-4B84-8B55-52E2F0B1A851@cisco.com> References: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> <9290D0D1-062A-4DE0-A437-9A5F5045ACAC@gmail.com> In-Reply-To: <9290D0D1-062A-4DE0-A437-9A5F5045ACAC@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.123] Content-Type: multipart/signed; boundary="Apple-Mail=_808DB5DF-D140-46B4-A452-E2E44DD78E11"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" , "draft-colitti-v6ops-host-addr-availability@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability 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, 07 Jul 2015 00:02:07 -0000 --Apple-Mail=_808DB5DF-D140-46B4-A452-E2E44DD78E11 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks. One question. Chair hat off. Section 2 identifies the current deployment model - each interface has a = link-local address, a SLAAC address, and one or more temporary = addresses. I haven't heard anyone complaining about that. Section 3 goes = on to discuss virtual machines/containers, which might each have = additional addresses, and the model Facebook is reportedly using, which = gives individual addresses to processes. It also mentions = draft-herbert-nvo3-ila, which is not a stupid model - I still have some = comments on it in a multi-administration environment or for running = applications in an "inside" and an "outside" address ("NAT has = well-known drawbacks"), but it at least gets rid of the random = encapsulations predominant in data centers today. In other words, we already assign multiple addresses, by some means, to = each interface in a network. You mention SLAAC. Lorenzo mentions that in section 7. He also mentions = DHCP address and prefix allocation. The statement that I don't see in the document, which would help me = personally, is a problem statement. I would guess that the problem = statement is "we think some networks are limiting host interfaces to a = single IPv6 address." I'd want a little more detail, but I'll bet that's = the crux of it. So my question is: "precisely what problem are we solving here?". > On Jul 6, 2015, at 2:39 PM, Andrew Yourtchenko = wrote: >=20 > I read the draft and absolutely agree with the spirit. >=20 > Unfortunately, I think it won't work: >=20 > As soon as the devices work "good enough" with a single address, = appealing to increase the amount of work by administrators in the name = of humanity is going to fall on deaf ears. >=20 > The only way I see to solve this is to always use SLAAC on the = devices: either 'externally' from the prefix received within the RA, or = 'internally' from within the prefix received via DHCP-PD, and provide a = mandatory registration mechanism for name-to-IP mapping. >=20 > If neither of the above works, as a backup effort the device can try = getting N addresses via DHCP IA_NA and release those that it does not = need immediately - and displaying a big yellow warning "This network may = restrict IPv6 functionality and eat your kittens, contact your system = administrator". Because ND is not going to happen on these 'extra' = addresses, forwarding wise there will be no impact, just some more DHCP = traffic after attachment (the "limited functionality" of course would = need just one address and can start immediately). >=20 > Those who want tracking can track the upper 64bits or use IA_NA and = filter out the addresses that are shortly lived. >=20 > Of course to avoid being a religious crusade such an effort need to = produce something pragmatic - namely, > a userland cross-platform API that would allow getting new addresses = on demand by application and if needs to - implementing custom transport = protocols on top of those on a per-app-per-address basis. >=20 > The above conjecture however is even less realistic than politely = asking the inconveniences away, so the logical conclusion from that is I = fully support this draft. >=20 > --a >=20 >> On 06 Jul 2015, at 13:47, fred@cisco.com wrote: >>=20 >> A new draft has been posted, at = http://tools.ietf.org/html/draft-colitti-v6ops-host-addr-availability. = Please take a look at it and comment. >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_808DB5DF-D140-46B4-A452-E2E44DD78E11 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 iQIVAwUBVZsW+UayAOS/EQ8MAQLyAg//QnPUNtFYPeSl/JVzsT5eNAqPmEqz0Eun CZKh8OcU/iZ3tJM8E55r6oEDSWRmcshsCFSPGaf75s63q4ZdKGW4aSkavOpChRfC b/9k/vUs0xPmXHR1kM3Zjsbz76H7Vv97RcjzT5jzYd9P6Cun2Rq3/e26/LmvCdax 9yf50e6NkuN5fSsJTvopNwnbi8m1fKEaF0sK/hXqn6e8ddgPTipliZ7PepazjElE HIZEXW0+EoKcjSVnsWiHUYaDQgNewll23ZjMk1BGYGPWQxhz5bLiefpBAPO1nfuY DeSuW0TsuPInrda8M0qMTKzuQecv5amrI7DqPszNUVPMyQajaRKBsdFVF3V/tTh+ nvTJL0NeK9jWEROiGDlb01ese/PruWMHgPILC+NEY1y1/84aBSm/ZoweENP+LTNd 9JnlQ7yrdfI5nIrku1gL+Pt4nqrOEM7c+b3j2jHUESTkjLua9qtUOXmiBSP8JcO5 ddTlSvAbPmN5qV1b1O1pimdwsnkC0uj5b/5vq6H1A4Kh//hn28WMltirgW+961xt kQBP/asAx7Ah/LjOK2FLFsBw8HLHr6MaFJ7BiHz5pg1khLSE1zL0pJSNJVVqQcwg +7U5C+maEEfjb2rCndH2KqgJ9K+vzkq8nfZFGSPuZ4wE5+pLkyJZUKOcULZEKPc3 zOyvvWYEh+c= =fwzl -----END PGP SIGNATURE----- --Apple-Mail=_808DB5DF-D140-46B4-A452-E2E44DD78E11-- From nobody Mon Jul 6 18:19:40 2015 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 BF0F51A887B for ; Mon, 6 Jul 2015 18:19:38 -0700 (PDT) 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 vQjocQwei8au for ; Mon, 6 Jul 2015 18:19:37 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::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 633361A8837 for ; Mon, 6 Jul 2015 18:19:37 -0700 (PDT) Received: by oiyy130 with SMTP id y130so130946625oiy.0 for ; Mon, 06 Jul 2015 18:19:36 -0700 (PDT) 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=2seCD2FJr69DTjHP5A9VdGkQ0kU+R10Ry/iZvWl87HQ=; b=F9D5DEtlNbaIU9EBmSon/IndGIltqp4TZNP4t/ngtYIxi/rT8Kx0QiEtOejaYpALa9 24zRSaatEBzIDypt65ibSqo3Ctlqz7HgLaiuGf0jRRGeoiF1NhubYwJlfpJtz1D3z4hO RavUkb5jEQQm+QY8BPo3ICfMdwJnq8Yvuq4Xihn0kb78OVi+OlhixeXmJ1Fey5sgD+0e 3FkqGa2+046H5aHOyd1ET8pZpGVYdvPIjvJ6njosPt9pfEFbMSh3lPJ9UjLL/Vlzb5Rc 2WtsMBeMo64EHxTb8vHTiZxU35mrdDtNw7Ousdx5ft3mqbzcwogNEwbfkuPePdKulVtw J+XQ== 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=2seCD2FJr69DTjHP5A9VdGkQ0kU+R10Ry/iZvWl87HQ=; b=nHeCque2yJ0k/BiKM0epuxk5ESJh8lJa4dQHJgx3DLjTHG3A0WUEldDjcMUXfOrEW4 HUrz3/Ohnx5wDrgVFMcVBY/cdlJPDpwG9vZUYm2IyZzT2OdymCCjdkFysQAaOpG6QwM5 SEjZy7ya5LXPNgVoFrT01UX4Zk1D5WquwyMU/5mtnp0BQMxT7DFpWM91eu2KzuWa2oUn Qi1RWkppd7NF+qYmoYx2eS1ET4ezojXfKLdxwXJJUa8XMwSRcWvJEpbS92llpxau1kiV vn/u7k4S/ij7h9jCogtGAVKGPWQ0Dg/bkLkiTUt6yGjAAkqT73FI3YI2HUlv+tjsihJN GXKw== X-Gm-Message-State: ALoCoQnu5uiWASkuvWZE54Pw7nghYwnMwRXJ+TatIUfP4sZfB6UgLfCumvhbD9S63esPKf0frwih X-Received: by 10.60.174.39 with SMTP id bp7mr1548345oec.70.1436231976622; Mon, 06 Jul 2015 18:19:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.134.198 with HTTP; Mon, 6 Jul 2015 18:19:16 -0700 (PDT) In-Reply-To: <39F63B55-977F-4B84-8B55-52E2F0B1A851@cisco.com> References: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> <9290D0D1-062A-4DE0-A437-9A5F5045ACAC@gmail.com> <39F63B55-977F-4B84-8B55-52E2F0B1A851@cisco.com> From: Lorenzo Colitti Date: Tue, 7 Jul 2015 10:19:16 +0900 Message-ID: To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=089e01184684c86505051a3ed015 Archived-At: Cc: "draft-colitti-v6ops-host-addr-availability@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability 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, 07 Jul 2015 01:19:38 -0000 --089e01184684c86505051a3ed015 Content-Type: text/plain; charset=UTF-8 On Tue, Jul 7, 2015 at 9:02 AM, Fred Baker (fred) wrote: > The statement that I don't see in the document, which would help me > personally, is a problem statement. I would guess that the problem > statement is "we think some networks are limiting host interfaces to a > single IPv6 address." I'd want a little more detail, but I'll bet that's > the crux of it. > Not necessarily "are limiting" today, but "will limit" in the future. Suppose that all operating systems of interest to a given network support DHCPv6 and it is thus possible to run a network without SLAAC and without IPv4 without denying service to substantial percentages of users. Let's consider what would happen in such a DHCPv6-only network. How many addresses would be available to each host? Because DHCPv6 requires an explicit request to the network before an address can be used, the answer is, by definition, "as many as the network administrators decide to make available". In some of these networks, the "as many as the network administrators decided to make available" may equate to just one. There could be lots of reasons for this: technical reasons such as "our IPAM and logging systems support only one address per host and it's tied into our legal intercept system so we can only give out one address per host", "we only have enough TCAM entries for one address per host", "one address per host is what we do in IPv4, and we want to be consistent with that". If that sounds unreasonable, now consider what would happen in a hotel network that charges $5 per device. How many addresses would be available to hosts on such a network? At best, one for every $5 paid. More likely, if the billing system does not support more than one IPv6 address (why would it?), the answer would become "one per MAC address". I hope we agree that such networks provide suboptimal service, and that there are a number of things that users would like to do that require either the availability of more than one IPv6 address. If we are able to agree on that, then it is a useful statement to make, for two reasons: 1. The network administrators might listen to the statement. 2. Client and server implementations can implement network configuration protocols such as DHCPv6 in a way that does not lead to this suboptimal scenario. Cheers, Lorenzo --089e01184684c86505051a3ed015 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 7, 2015 at 9:02 AM, Fred Baker (fred) <fred@cisco.com> = wrote:
The statement that I don't see in the docume= nt, which would help me personally, is a problem statement. I would guess t= hat the problem statement is "we think some networks are limiting host= interfaces to a single IPv6 address." I'd want a little more deta= il, but I'll bet that's the crux of it.

Not necessarily "are limiting" today, but "will lim= it" in the future.

Suppose that all operating= systems of interest to a given network support DHCPv6 and it is thus possi= ble to run a network without SLAAC and without IPv4 without denying service= to substantial percentages of users.

Let'= s consider what would happen in such a DHCPv6-only network. How many addres= ses would be available to each host? Because DHCPv6 requires an explicit re= quest to the network before an address can be used, the answer is, by defin= ition, "as many as the network administrators decide to make available= ".

In some of these networks, the "as ma= ny as the network administrators decided to make available" may equate= to just one. There could be lots of reasons for this: technical reasons su= ch as "our IPAM and logging systems support only one address per host = and it's tied into our legal intercept system so we can only give out o= ne address per host", "we only have enough TCAM entries for one a= ddress per host", "one address per host is what we do in IPv4, an= d we want to be consistent with that".

If tha= t sounds unreasonable, now consider what would happen in a hotel network th= at charges $5 per device. How many addresses would be available to hosts on= such a network? At best, one for every $5 paid. More likely, if the billin= g system does not support more than one IPv6 address (why would it?), the a= nswer would become "one per MAC address".

I hope we agree that such networks provide suboptimal service, and that t= here are a number of things that users would like to do that require either= the availability of more than one IPv6 address.

I= f we are able to agree on that, then it is a useful statement to make, for = two reasons:
1. The network administrators might listen to the st= atement.
2. Client and server implementations can implement netwo= rk configuration protocols such as DHCPv6 in a way that does not lead to th= is suboptimal scenario.

Cheers,
Lorenzo<= /div>
--089e01184684c86505051a3ed015-- From nobody Mon Jul 6 19:09:10 2015 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 BCF5B1A21AD for ; Mon, 6 Jul 2015 19:09:08 -0700 (PDT) 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 3t8VDKSHTH6i for ; Mon, 6 Jul 2015 19:09:07 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::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 20D3A1A21A9 for ; Mon, 6 Jul 2015 19:09:07 -0700 (PDT) Received: by wibdq8 with SMTP id dq8so169039427wib.1 for ; Mon, 06 Jul 2015 19:09:05 -0700 (PDT) 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:content-transfer-encoding; bh=fjwXffxL5ZxLLtcjmp8i6G4kq/J4BFZL7NQiGtzxAbc=; b=LvVV7UPke5Omb2h7dyx8ZhndEr4sWPO/7LKrygXUHuOr5vWldpJtFVB4AMMss6eRsy fw7bZv9JbZewnydpiMxCKvvpogB3W0hGt0Jwh9Ak9tvYqV+lvzKur8tDqZYLEYmPzisq nKN8lkxFmYOCbLrlzrb8Csvgq07pAKIaHeORRKIZSvA4byGG73U0wOaNfxH8Kki2QmxV PQLtAV6JJnsfva71zLaO+AITCT4NWxbz0Q8TPWVjQIKLYoD/CG90PL+Et5NT1Vfur4fv PdZXOKAH0ghpuy/5rHSTi9EXrx8eZxQW1H4jchg/RRHAX2nH5tNl9b5mG7a8tMmBRXdg eYcw== 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:content-transfer-encoding; bh=fjwXffxL5ZxLLtcjmp8i6G4kq/J4BFZL7NQiGtzxAbc=; b=ijuoqGkaEhE2/dWzPkRyG5lWWFP8F8pGTv0hhhcm9oIt5ZZbs+LyQ6qWpIgSn2pa4T 7c3zjrzmXUDIBXIOhnzEcmsSiMpQnF4wArklVWGbnES01SVeZ2BvI/Vukzk4MawXFjaF 4aiPbvkptPWKT5hmzabulY+e8KotA1RrdBNtAQFkkQ5V6aPGb7RVtpTGM68LCrIWggEy SasLNBdvDObPM9dchTB232nnoUg+cs8ytKBRZRVHTeA2OoD501pXUo9srY1c0otelg36 eeniFBmwELfn/W4FvFGnaMcWdhQqxDrkMrg6LWCZ/vUxYKqh588hxU5DEdVFRHz8Xje6 mfYw== X-Gm-Message-State: ALoCoQkNi3xTlMIbBkErkjThW245buSMRCOLFAa3mLeu8D++hWAWmwhczs8kVuWl/QexpqKsoxpd X-Received: by 10.180.78.136 with SMTP id b8mr56647024wix.89.1436234945838; Mon, 06 Jul 2015 19:09:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.138.203 with HTTP; Mon, 6 Jul 2015 19:08:46 -0700 (PDT) In-Reply-To: <39F63B55-977F-4B84-8B55-52E2F0B1A851@cisco.com> References: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> <9290D0D1-062A-4DE0-A437-9A5F5045ACAC@gmail.com> <39F63B55-977F-4B84-8B55-52E2F0B1A851@cisco.com> From: Erik Kline Date: Tue, 7 Jul 2015 11:08:46 +0900 Message-ID: To: "Fred Baker (fred)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "draft-colitti-v6ops-host-addr-availability@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability 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, 07 Jul 2015 02:09:08 -0000 Some of this could also serve as input to motivate a SAVI document defining a basic logging protocol. I still believe that if there where a trivially deployable logging methodology that captured {IP address, timestamp, rfc7039#section-3.2 binding context} tuples, or even the full data structure entry described in rfc6620#section-3.1, then the auditing objectives could be well and truly met. I think this is still one large unmet need. (not necessarily a v6ops matter, perhaps) On 7 July 2015 at 09:02, Fred Baker (fred) wrote: > Thanks. One question. Chair hat off. > > Section 2 identifies the current deployment model - each interface has a = link-local address, a SLAAC address, and one or more temporary addresses. I= haven't heard anyone complaining about that. Section 3 goes on to discuss = virtual machines/containers, which might each have additional addresses, an= d the model Facebook is reportedly using, which gives individual addresses = to processes. It also mentions draft-herbert-nvo3-ila, which is not a stupi= d model - I still have some comments on it in a multi-administration enviro= nment or for running applications in an "inside" and an "outside" address (= "NAT has well-known drawbacks"), but it at least gets rid of the random enc= apsulations predominant in data centers today. > > In other words, we already assign multiple addresses, by some means, to e= ach interface in a network. > > You mention SLAAC. Lorenzo mentions that in section 7. He also mentions D= HCP address and prefix allocation. > > The statement that I don't see in the document, which would help me perso= nally, is a problem statement. I would guess that the problem statement is = "we think some networks are limiting host interfaces to a single IPv6 addre= ss." I'd want a little more detail, but I'll bet that's the crux of it. > > So my question is: "precisely what problem are we solving here?". > >> On Jul 6, 2015, at 2:39 PM, Andrew Yourtchenko wrot= e: >> >> I read the draft and absolutely agree with the spirit. >> >> Unfortunately, I think it won't work: >> >> As soon as the devices work "good enough" with a single address, appeali= ng to increase the amount of work by administrators in the name of humanity= is going to fall on deaf ears. >> >> The only way I see to solve this is to always use SLAAC on the devices: = either 'externally' from the prefix received within the RA, or 'internally'= from within the prefix received via DHCP-PD, and provide a mandatory regis= tration mechanism for name-to-IP mapping. >> >> If neither of the above works, as a backup effort the device can try get= ting N addresses via DHCP IA_NA and release those that it does not need imm= ediately - and displaying a big yellow warning "This network may restrict I= Pv6 functionality and eat your kittens, contact your system administrator".= Because ND is not going to happen on these 'extra' addresses, forwarding w= ise there will be no impact, just some more DHCP traffic after attachment (= the "limited functionality" of course would need just one address and can s= tart immediately). >> >> Those who want tracking can track the upper 64bits or use IA_NA and filt= er out the addresses that are shortly lived. >> >> Of course to avoid being a religious crusade such an effort need to prod= uce something pragmatic - namely, >> a userland cross-platform API that would allow getting new addresses on = demand by application and if needs to - implementing custom transport proto= cols on top of those on a per-app-per-address basis. >> >> The above conjecture however is even less realistic than politely asking= the inconveniences away, so the logical conclusion from that is I fully su= pport this draft. >> >> --a >> >>> On 06 Jul 2015, at 13:47, fred@cisco.com wrote: >>> >>> A new draft has been posted, at http://tools.ietf.org/html/draft-colitt= i-v6ops-host-addr-availability. Please take a look at it and comment. >>> >>> _______________________________________________ >>> 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 Mon Jul 6 21:48:53 2015 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 C558C1A89BB; Mon, 6 Jul 2015 21:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRa-BfD7c0Vn; Mon, 6 Jul 2015 21:48:50 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::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 788DE1A89B9; Mon, 6 Jul 2015 21:48:47 -0700 (PDT) Received: by pactm7 with SMTP id tm7so106534009pac.2; Mon, 06 Jul 2015 21:48:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=aB0HCb/7WXV9tMuZ4Sneerwf/n5RIkKBjOQuhVhuXYQ=; b=QUrQN2Xoy49QJ7QKWsSqoVfPJ7r8RJhRbQKFTKzSkTvWXy3MSVc4x3JhLucY8KVKDn qH6DEIgLH/zlhVUDkGGhMKyMrYM56ctRSX3Y3/8GwbPuCkTwJGGDsH/PLl0pVAYx3EC2 Pa2DsnIhEeMQjCodUwcuuIOl9e/plPaOiSfq7c2Ecc7VcXxUxgiu/+KZ1HvOG4Mo6k0A hXB7etARR/qJKJfCzH38eOt4JrnepqekRyb2KJMuBp2CSFyXSepZacw8XXAQt4TYvQYe RpUws/oNzcyzE/UQOoShECkZjK3kkyCmrFoE9caJA9WLI4W8u9MmD+uDw1Jjg2zYyXyy ltdA== X-Received: by 10.68.112.195 with SMTP id is3mr4869956pbb.92.1436244527140; Mon, 06 Jul 2015 21:48:47 -0700 (PDT) Received: from ?IPv6:2406:e007:42f0:1:28cc:dc4c:9703:6781? ([2406:e007:42f0:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id vz2sm16293877pbc.71.2015.07.06.21.48.43 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Jul 2015 21:48:45 -0700 (PDT) Message-ID: <559B5A2C.6090204@gmail.com> Date: Tue, 07 Jul 2015 16:48:44 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: draft-ietf-v6ops-design-choices@ietf.org References: <20150706212506.2640.97532.idtracker@ietfa.amsl.com> In-Reply-To: <20150706212506.2640.97532.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-08.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, 07 Jul 2015 04:48:51 -0000 Hi, I don't understand why you mention RFC 1918 in a document about IPv6 deployment. In the table in 2.1.1, I object strongly to the comment against private (i.e. ULA) addresses "Will probably require some sort of NAT on links to the Internet." That isn't the architecture. The architecture is that nodes have multiple addresses, and only use ULAs for internal traffic, and use PA or PI addresses for Internet traffic. We shouldn't be documenting any other usage of ULAs. We shouldn't be making statements like this: "For an enterprise, the use of private address space is reasonable, but the enterprise will need to use NAT44 and/or NPT[RFC6296] on links to the Internet." We clearly can't pretend that NAT44 isn't widely used, but IMHO it should be completely out of scope in this document, and NPTv6 is an experimental RFC that we should never recommend. ULAs should *only* be used in parallel with PA or PI. That isn't an afterthought; that is the basic intention behind ULAs. Stepping back slightly in the text: "In this case, the use of PI space is the best option, as it gives the most flexibility in the future. However, some organizations may be unable or unwilling to obtain PI space - in this case PA space is the next-best choice." What size of enterprise are you addressing? Whatever the current RIR policy is, it remains irresponsible to hand out PI prefixes like candy. Please tune this language to make it clear that it applies to hundreds or thousands of large customers, probably not to small/medium enterprises, and definitely not to millions of SOHO customers, who will inevitably get PA. Stepping back to the first sentence of the Introduction: "This document discusses certain choices that arise when designing a IPv6-only or dual-stack network." This really needs to specify the classes of customer it is addressing. You split some of the later material into "ISP" and "Enterprise" but that (and customers that are not covered) needs to be made clear at the beginning, and even in the Abstract. Nit: "2.4.3. RIP A protocol option described in the table in this section is RIP [RFC2080]." Don't you mean "*not* described in the table"? And its name is RIPng. Regards Brian From nobody Mon Jul 6 22:57:13 2015 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 7432A1A9006 for ; Mon, 6 Jul 2015 22:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VP2S6p_tN7-Q for ; Mon, 6 Jul 2015 22:57:10 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::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 72E351A9004 for ; Mon, 6 Jul 2015 22:57:10 -0700 (PDT) Received: by iebmu5 with SMTP id mu5so127531582ieb.1 for ; Mon, 06 Jul 2015 22:57:10 -0700 (PDT) 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=rsMEI5KQmsdaH6+TcKgLrSC+v0/ae82vpIZ3cppDeLg=; b=hIx2l+wGSSjii04WZBN55I6tZPrQRcWthqnhtQB/TRo/0j/8wlvq1Ldwik6ZjLQDYg 3CSm93N02uZFHxztyYoE14DVRCXwvXP5KgIF2+n5foKd0rPd7V5nkQOtPNlhxnvT+hFC kZrzBWvaVl7sV1NWfRklrV1Lt5JZZREq3ElnTzo1mcXhpm/JbJ5gJQgVhOgRA6JeCG1L 4Un0viarS9bPg37Gfjt0HVJlZaVM1jCvDiJV9Ww7UT+S7ohiJkdtKwlrRSgreWrS1FxE GaJGEdVwja2vaNz6ICOyXGFGnmOTKrcjgG57VpEw/4LKsgxS/ctJeDUhvty0lvgOrzwU d5Iw== MIME-Version: 1.0 X-Received: by 10.107.33.146 with SMTP id h140mr3752689ioh.1.1436248629872; Mon, 06 Jul 2015 22:57:09 -0700 (PDT) Received: by 10.107.47.14 with HTTP; Mon, 6 Jul 2015 22:57:09 -0700 (PDT) In-Reply-To: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> References: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> Date: Mon, 6 Jul 2015 22:57:09 -0700 Message-ID: From: Yury Shefer To: fred@cisco.com Content-Type: multipart/alternative; boundary=001a1140a3c0649795051a42b115 Archived-At: Cc: v6ops@ietf.org, draft-colitti-v6ops-host-addr-availability@tools.ietf.org Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability 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, 07 Jul 2015 05:57:12 -0000 --001a1140a3c0649795051a42b115 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello authors, +1 and thanks for the draft! Since you mentioned 3GPP, maybe it would be useful to mention Broadband Forum (BBF) as well? BBF End-to-End Architecture technical reports recommend the following: 1. TR-177 - IPv6 in the context of TR-101 (Nov 2010) 1.1 - Addressing recommendations - paragraph 4.2: "From a routed RG perspective, the following IPv6 addresses may be provided by the Service Provider=E2=80=99s network: - A /64 prefix for the WAN link GUA (optional, only done in the case of the numbered WAN model) - A delegated prefix for use within the home network (mandatory). The Broadband Forum suggests a size for the delegated prefix of at least a /60 for home network or SOHO environments, with a recommended prefix length of /56. The delegated prefix may be extended to a /48 for larger organizations." 1.2 - IPv6 Prefix Delegation (DHCPv6-PD) - paragraph 4.2.1: "A different prefix (with a maximum length of 64 bits, and a recommended length of 56 bits) is delegated per access loop". 2. TR-187 issue 2 - IPv6 for PPP Broadband Access (Feb 2013) DHCPv6-PD is a mandatory requirement and it must be supported together with DHCPv6 /128 WAN address assignment. Here is a few BNG requirements - chapter 9.1: "R-22 The BNG, when acting as DHCPv6 Server, MUST be able to assign a single IPv6 /128 address to the WAN interface of the RG when using DHCPv6 for address assignment. R-23 The BNG MUST be able to support DHCPv6-Prefix Delegation, RFC 3633 [16], to delegate a prefix to the RG." On Mon, Jul 6, 2015 at 4:47 AM, wrote: > A new draft has been posted, at > http://tools.ietf.org/html/draft-colitti-v6ops-host-addr-availability. > Please take a look at it and comment. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --=20 Best regards, Yury. --001a1140a3c0649795051a42b115 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello authors,

+1 and thanks f= or the draft!

Since you mentioned 3GPP, maybe it w= ould be useful to mention Broadband Forum (BBF) as well? BBF End-to-End Arc= hitecture technical reports recommend the following:

1. TR-177 - IPv= 6 in the context of TR-101 (Nov 2010)
1.1 - Addressing recommendations -= paragraph 4.2:
"From=C2=A0 a=C2=A0 routed=C2=A0 RG=C2=A0 perspecti= ve,=C2=A0 the=C2=A0 following=C2=A0 IPv6=C2=A0 addresses=C2=A0 may=C2=A0 be= =C2=A0 provided=C2=A0 by=C2=A0 the=C2=A0 Service
Provider=E2=80=99s net= work:
- A /64 prefix for the WAN link GUA (optional, only done in the ca= se of the numbered WAN
model)
- A=C2=A0 delegated=C2=A0 prefix=C2=A0= for=C2=A0 use=C2=A0 within=C2=A0 the=C2=A0 home=C2=A0 network=C2=A0 (manda= tory).=C2=A0 The=C2=A0 Broadband=C2=A0 Forum
suggests=C2=A0 a=C2=A0 siz= e=C2=A0 for=C2=A0 the=C2=A0 delegated=C2=A0 prefix=C2=A0 of=C2=A0 at=C2=A0 = least=C2=A0 a=C2=A0 /60=C2=A0 for=C2=A0 home=C2=A0 network=C2=A0 or=C2=A0 S= OHO
environments,=C2=A0 with=C2=A0 a=C2=A0 recommended=C2=A0 prefix=C2= =A0 length=C2=A0 of=C2=A0 /56.=C2=A0 The=C2=A0 delegated=C2=A0 prefix=C2=A0= may=C2=A0 be
extended to a /48 for larger organizations."

= 1.2 - IPv6 Prefix Delegation (DHCPv6-PD) - paragraph 4.2.1:
"A diff= erent prefix (with a maximum length of 64 bits, and a recommended length of= 56 bits) is
delegated per access loop".


2. TR-18= 7 issue 2 - IPv6 for PPP Broadband Access (Feb 2013)
DHCPv6-PD is a mand= atory requirement and it must be supported together with DHCPv6 /128 WAN ad= dress assignment. Here is a few BNG requirements - chapter 9.1:
"R-= 22=C2=A0=C2=A0=C2=A0 The BNG, when acting as DHCPv6 Server, MUST be able to= assign a single IPv6 /128
=C2=A0=C2=A0=C2=A0 address to the WAN interf= ace of the RG when using DHCPv6 for address assignment.
R-23=C2=A0=C2=A0= =C2=A0 The=C2=A0 BNG MUST=C2=A0 be=C2=A0 able=C2=A0 to=C2=A0 support=C2=A0 = DHCPv6-Prefix=C2=A0 Delegation,=C2=A0 RFC=C2=A0 3633 [16],
=C2=A0=C2=A0= =C2=A0 to delegate a prefix to the RG."
=
On Mon, Jul 6, 2015 at 4:47 AM, <fred@cisco= .com> wrote:
A new draft has been posted, at http://tools.ietf.org/html/draft-colitti-v6ops-host-addr-availability= . Please take a look at it and comment.

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



--
Best regards,
Yury.
--001a1140a3c0649795051a42b115-- From nobody Tue Jul 7 02:08:55 2015 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 A1C551A7D85 for ; Tue, 7 Jul 2015 02:08:54 -0700 (PDT) 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_40=-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 pS85euoFMbtG for ; Tue, 7 Jul 2015 02:08:52 -0700 (PDT) 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 D36691A7D82 for ; Tue, 7 Jul 2015 02:08:51 -0700 (PDT) Received: from [2a02:c0:2:4:6666:17:0:1001] (port=53689 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1ZCOrv-0006DS-Ex; Tue, 07 Jul 2015 11:08:47 +0200 Date: Tue, 7 Jul 2015 11:08:47 +0200 From: Tore Anderson To: v6ops@ietf.org Message-ID: <20150707110847.5119162d@echo.ms.redpill-linpro.com> In-Reply-To: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> References: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: draft-colitti-v6ops-host-addr-availability@tools.ietf.org Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability 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, 07 Jul 2015 09:08:54 -0000 * fred@cisco.com > A new draft has been posted, at > http://tools.ietf.org/html/draft-colitti-v6ops-host-addr-availability. > Please take a look at it and comment. I read this draft. I strongly agree with its recommendation, and would support WG adoption. I have some feedback and suggestions, see below: 1) The abstract and section 6: What exactly is meant by "multiple"? Would a network conform to the recommendation by allowing 2 global addresses per host (given the current wording, I think so)? Or should it be 20? 200? I'd like to see a specific number, or at least a ballpark number, or failing that some text that explains why no attempt is being made to quantify what is OK and what is not. (I know this is a tough one. Sorry..) 2) Section 1.1: Includes the RFC 2119 key words but doesn't appear to make use o f them anywhere. Maybe s/recommended/RECOMMENDED/ in section 6? 3) Section 2 makes a reference to RFC 6433 section 5.9.4. I think there must be a typo on the RFC number; RFC6433 doesn't contain a section 5.9.4. 4) In Section 2: =C2=ABDHCPv6 [RFC7217]=C2=BB. s/7217/3315/, surely? 5) In Section 2: =C2=ABIPv6 hosts have the ability to configure additional IPv6 addresses from the on-link prefix without explicit requests to the network=C2=BB isn't 100% correct, the hosts need to perform DAD first. Furthermore, that mechanism could be (ab)used by the network to block the host from obtaining additional addresses. 6) Nit: In section 3, some of the bullet points terminate with a full stop, some do not. Looks inconsistent. 7) Section 4: Just like to note that an address-unrestricted network will still be subject to the first three problems listed thanks to DAD. (Except DHCPv6-PD.) 8) Section 5: =C2=ABthe problems listed in section without disabling=C2=BB = is missing a reference to (I assume) section 4. 9) Section 7: =C2=ABIf the prefix is a /64, it can also reshare that prefix with any downstream clients via [RFC7278] /64 sharing=C2=BB. I think the reference to RFC7278 is improper. First, RFC7278 is 3GPP specific while DHCPv6-PD is not. Second, it discusses how to take a /64 that is a link prefix on an upstream interface and re-use it on a downstream interface. If you receive a delegated prefix (regardless of what its length is), that prefix is *not* a link prefix on your upstream interface and can simply be used on your downstream (or loopback) interfaces without restrictions. I suggest rewriting something like this: =C2=ABThe delegated prefix can also be reshared with any downstream clients, cf. [RFC3633] section 5.=C2=BB 10) Table 1: Mentions that SLAAC provides "unlimited" addressing. I think that's a bit of a stretch, given hardware limitations. You can buy devices today that can only handle a very limited amount IPv6 neighbours (Juniper EX45x0 for example: 1000 NDP entries according to the datasheet). Given that each node needs at least two addresses (LLA+GUA), you won't need many nodes with multiple addresses before you start hitting some hard limitations. 11) Table 1: Might want to say "IA_NA/IA_TA" instead of just "IA_NA". 12) Table 1: The table says DHCPv6 IA_NA gives "unlimited" addressing while DHCPv6 PD does not. I think maybe it was meant to be the other way around? 13) Table 1: What's the difference between the rows =C2=ABStateful, request-based=C2=BB and =C2=ABRequest-based=C2=BB supposed to be? (You migh= t want to take into account DAD for SLAAC in one of them, cf. point #4.) 14) Section 7 / Table 1: I think you should discuss whether or not an approach can be cascaded, or at least easily so. As an example, consider a 3GPP mobile network. It provides a /64, so it conforms with the recommendation in this document. However, if you use RFC7278 to create a tethering wireless network, a tethered host on that network cannot easily share that network further using because RFC7278 requires the upstream interface to be a point-to-point one, which the wirel ess network is not. 15) Section 8.1: =C2=ABy large enterprise networks, including the enterprise networks of the authors, are fully dual-stack but do not use or support DHCPv6.=C2=BB. Not that there's anything wrong with this statement, it left me wondering: 1) How do you communicate DNS servers to your Windows hosts, assuming you have any? (Maybe you meant to say =C2=ABdoes not use or support DHCPv6 *address assignment*=C2=BB?) 2) What happens if you try to configure a gazillion addresses on your host when connected to this network? Does it actually work, does the network break, are (some of) the addresses rendered unusable and if so is it due to simultaneous addresses per host being limited somehow (hardware or policy) and if so what is that limitation exactly? 16) Section 8.2: =C2=ABThe total size of net 10 is roughly 2^24=C2=BB. Roug= hly? Isn't it *exactly* 2^24? 17) Section 8.2: The reference to RFC1918 should probably be, well, an (actual) reference. 18) Section 8.2: Echoing what Sander said, a /40 isn't easy to get as an enterprise (end-user), you'll need something like 128 sites for that or become your own LIR. I don't think saying you want to assign a /64 per host provides adequate justification for more than the standard /48 per site, at least not in the RIPE region. (But it is of course possible to do something about that.) 19) Section 8.2: =C2=ABCurrently, residential users receive one IPv4 address=C2=BB - except that more and more of them are receiving *less than* one IPv4 address nowadays... 20) Sections 10, 11, A: Text that appears to be from a RFC template is left over. Tore From nobody Tue Jul 7 04:47:05 2015 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 D05A81ABD3F for ; Tue, 7 Jul 2015 04:47:04 -0700 (PDT) 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 ZTVCzOYQrZ7U for ; Tue, 7 Jul 2015 04:47:03 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 949B61ABD3C for ; Tue, 7 Jul 2015 04:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=135; q=dns/txt; s=iport; t=1436269623; x=1437479223; h=date:from:message-id:to:subject:cc; bh=hnfOEWg8LhxnnNmEEPUUN4JuJxoGCJeK18fmv7ZR64g=; b=Z0lFyytFpV+PNXoEyNNhJIr6xK4TQKGSnCTAFKbeWjFIWpv7Mb7MLD9f pnTkHm+4HNehGZHf/JKRcZDIQ2YOOmcJmhy/ErGhbEnzIXQSBgSRcs2sf Wdyn+/RkTF9DjOhQ481qH1r1PDF9s6nq16nJYI2rzfbtg3ujUkQrL7S5n U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BOIgBcu5tV/4YNJK1cgxJUYa8DAZBehW4JgVU7EQEBAQEBAQGBCkEBAgKDYH08NIkOAQ3KTwEBAQcBAQEBAR2LS4UGHYQVBY0Lhw2EYohBRYNSkwkmhBuDGgEBAQ X-IronPort-AV: E=Sophos;i="5.15,422,1432598400"; d="scan'208";a="166180265" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-8.cisco.com with ESMTP; 07 Jul 2015 11:47:02 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t67Bl2DC017446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Jul 2015 11:47:02 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 t67Bl2wH009354; Tue, 7 Jul 2015 04:47:02 -0700 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id t67Bl13m009348; Tue, 7 Jul 2015 04:47:01 -0700 Date: Tue, 7 Jul 2015 04:47:01 -0700 From: fred@cisco.com Message-Id: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Cc: draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org Subject: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 07 Jul 2015 11:47:05 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-yc-v6ops-solicited-ra-unicast. Please take a look at it and comment. From nobody Tue Jul 7 04:47:12 2015 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 DB0A31ABD3F for ; Tue, 7 Jul 2015 04:47:05 -0700 (PDT) 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 F12LhsqAUjMI for ; Tue, 7 Jul 2015 04:47:03 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CA881ABD3B for ; Tue, 7 Jul 2015 04:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=133; q=dns/txt; s=iport; t=1436269623; x=1437479223; h=date:from:message-id:to:subject:cc; bh=VsaB1sIQro63H4NDtm9UwuS2bNYvaiGyNc8ADB8F7Fg=; b=N2T/HX2Y4YPFIeGAVeSvfcaxpIdoZxC0+Mw9jPu4adsM6I7c7YajfvzO cDMzTaqKrac9Kyege5GUfKTB27jV/mazVHVQtH6aWxml6RnphheuQVtGm I5s7QG3v5mgbhrD59AAjAVcC8DI8nY8A9ciPlc8Z98pliDBPxGluPEss4 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BHIgCPu5tV/4QNJK1cgxJUYa8DAY5vgW+FbgmBVjoSAQEBAQEBAYEKQQECAoNgfTw0iQ4BDcpPAQEBBwEBAQEBHYtLhQYdhBUFjQuHDYRiiEFFg1KTCSaEG4MaAQEB X-IronPort-AV: E=Sophos;i="5.15,422,1432598400"; d="scan'208";a="9535639" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-5.cisco.com with ESMTP; 07 Jul 2015 11:47:02 +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 t67Bl2cX010955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Jul 2015 11:47:02 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 t67Bl2vV009352; Tue, 7 Jul 2015 04:47:02 -0700 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id t67Bl1VL009344; Tue, 7 Jul 2015 04:47:01 -0700 Date: Tue, 7 Jul 2015 04:47:01 -0700 From: fred@cisco.com Message-Id: <201507071147.t67Bl1VL009344@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Cc: draft-akira-v6ops-mape-experience@tools.ietf.org Subject: [v6ops] new draft: draft-akira-v6ops-mape-experience 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, 07 Jul 2015 11:47:06 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-akira-v6ops-mape-experience. Please take a look at it and comment. From nobody Tue Jul 7 05:38:48 2015 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 8E5E51A00BC for ; Tue, 7 Jul 2015 05:38:46 -0700 (PDT) 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 Ak2uuTwsTTVM for ; Tue, 7 Jul 2015 05:38:45 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::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 648491A0097 for ; Tue, 7 Jul 2015 05:38:45 -0700 (PDT) Received: by wiclp1 with SMTP id lp1so49443647wic.0 for ; Tue, 07 Jul 2015 05:38:43 -0700 (PDT) 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=UNqTYbqg6McqO0GI4l3Bx6Lm74/tep0x0ZFl/Za9rNU=; b=F96lFvskSejRDUFvKjajArsO+oRR/oGWmD7VF7fj3+cK9dXxWG1UU6/wqQ+QGwjMjE 6PtyVYPhHfs3ujAWmfRpc+qWVqsaoPz5QZe9UrNDp3vwk9acod3G0XcvrJlFOCy3NSnh smavKWvgLHgRL/c5yHb9rbt7p78F+K/wb4E/UlackX5AfDqdTq/j0SfMVjFatxosbNH3 sbTeM+Yz4I5rmKT758gcZuF5u+tPBUuAkjX2qeERJRF6Z05SMcB7ebn4DssOt8234BsH gb1X76lVdcZJLlXC+f1L/0CIZ/4c57IM85G/7ufAG/MT2RpKy48EwsCtX4AegVddcxJ2 fG3w== 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=UNqTYbqg6McqO0GI4l3Bx6Lm74/tep0x0ZFl/Za9rNU=; b=UWx6l8QV/+LZ7gnzlpr/p9dgsR6/IhHpj9XpL/Xprx8xGx2B3jS7YY6y5lg9fTErd1 faRqF6SXeIY4rWLxKciIhScB10UMfuwHC/8fVYtCrY+s1TtVBFrgeX9vyqSYwxSdisjl mCvRreP2DKS+XRPCwPFRTmosbrjERSSVqgLGdQZOTqtvsIeoXPRSOlvEchTe0a7iSJJe 1uskbm3KmfMkkBB5it1m4udv6f2h/wc/INOO67ufVJvPyD5pQzt2/+4IT3lTaezLUZS3 RnaLh+ZC/bhic1mkkhRVoD/lZxooxHyyOvl/SwscSUkbX4HBz3iREJUOvK7ZIKerzOMt wDuA== X-Gm-Message-State: ALoCoQnsT7kLAkjeYm9dV0/eAngzKk5XWSPFsHXJ9HVnBH9EdWwDVPVwhniW6fwU0HqGOExazqCA X-Received: by 10.181.27.131 with SMTP id jg3mr96900806wid.89.1436272723735; Tue, 07 Jul 2015 05:38:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.138.203 with HTTP; Tue, 7 Jul 2015 05:38:24 -0700 (PDT) In-Reply-To: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> From: Erik Kline Date: Tue, 7 Jul 2015 21:38:24 +0900 Message-ID: To: Fred Baker Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org, "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 07 Jul 2015 12:38:46 -0000 +1 I would include some text to the effect that a router may additionally transmit a unicast RA toward at virtually any time, not just in response to RSes. These could be on a schedule of course, but more importantly, if a router knows it has a queue of packets to send to a node it is free to push a unicast RS onto the front of that queue as a way to assist the client keeping RA data fresh. On 7 July 2015 at 20:47, wrote: > A new draft has been posted, at http://tools.ietf.org/html/draft-yc-v6ops-solicited-ra-unicast. Please take a look at it and comment. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Jul 7 05:49:25 2015 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 EDCED1A01CB for ; Tue, 7 Jul 2015 05:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 BJwZUfStVrCL for ; Tue, 7 Jul 2015 05:49:20 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 21A7A1A01AA for ; Tue, 7 Jul 2015 05:49:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 48E7F400E1; Tue, 7 Jul 2015 14:49:19 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVTGOOwOyq_P; Tue, 7 Jul 2015 14:49:17 +0200 (CEST) Received: from Rays-iMac.local (unknown [IPv6:2001:470:1f15:73a:483:f00c:db00:800]) (Authenticated sender: v6ops@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id DCC0640093; Tue, 7 Jul 2015 14:49:16 +0200 (CEST) Message-ID: <559BCACB.3000106@globis.net> Date: Tue, 07 Jul 2015 14:49:15 +0200 From: Ray Hunter User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Lorenzo Colitti References: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> <9290D0D1-062A-4DE0-A437-9A5F5045ACAC@gmail.com> <39F63B55-977F-4B84-8B55-52E2F0B1A851@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070309070607050005050707" Archived-At: Cc: "v6ops@ietf.org" , "draft-colitti-v6ops-host-addr-availability@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability 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, 07 Jul 2015 12:49:23 -0000 This is a multi-part message in MIME format. --------------070309070607050005050707 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Lorenzo Colitti wrote: > On Tue, Jul 7, 2015 at 9:02 AM, Fred Baker (fred) > wrote: > > The statement that I don't see in the document, which would help > me personally, is a problem statement. I would guess that the > problem statement is "we think some networks are limiting host > interfaces to a single IPv6 address." I'd want a little more > detail, but I'll bet that's the crux of it. > > > Not necessarily "are limiting" today, but "will limit" in the future. > > Suppose that all operating systems of interest to a given network > support DHCPv6 and it is thus possible to run a network without SLAAC > and without IPv4 without denying service to substantial percentages of > users. > > Let's consider what would happen in such a DHCPv6-only network. How > many addresses would be available to each host? Because DHCPv6 > requires an explicit request to the network before an address can be > used, the answer is, by definition, "as many as the network > administrators decide to make available". > > In some of these networks, the "as many as the network administrators > decided to make available" may equate to just one. There could be lots > of reasons for this: technical reasons such as "our IPAM and logging > systems support only one address per host and it's tied into our legal > intercept system so we can only give out one address per host", "we > only have enough TCAM entries for one address per host", "one address > per host is what we do in IPv4, and we want to be consistent with that". > > If that sounds unreasonable, now consider what would happen in a hotel > network that charges $5 per device. How many addresses would be > available to hosts on such a network? At best, one for every $5 paid. > More likely, if the billing system does not support more than one IPv6 > address (why would it?), the answer would become "one per MAC address". > > I hope we agree that such networks provide suboptimal service, and > that there are a number of things that users would like to do that > require either the availability of more than one IPv6 address. > > If we are able to agree on that, then it is a useful statement to > make, for two reasons: > 1. The network administrators might listen to the statement. > 2. Client and server implementations can implement network > configuration protocols such as DHCPv6 in a way that does not lead to > this suboptimal scenario. > > Cheers, > Lorenzo If I might add some comment to the "problem statement" I'd like apps and users to be able to enjoy privacy from the "bad guys", and also be shielded from general attack and casual scans. However, I'd also like the "good guys" to be able to track security relationships at some abstract level for audit and security purposes. IMVHO That's still very much an area of "work to be completed" and is also the main reason why network operators want to limit the addresses in use (rather than the $5 per address reason cited). As an example, inbound sessions can be clearly directed to a particular stable/well known destination address e.g. using DNS. And application daemons can generally be configured to listen only on particular addresses. But has anyone tried to force apps to use a particular source address as a source for related sessions, or "mirror at L7" outbound sessions to use the same source address as the destination address of the inbound message? In OSI speak that's the session layer, and we don't really have one. So the problem isn't just a matter of supporting multiple addresses at the network adapter layer; it's a matter of how those addresses are bound to apps, and how/when they are selected. As one example, I recently came across an app that bound quite happily to a particular address on a VM adapter for inbound sessions/messages, but defaulted to using the first address configured on the underlying VM for all outbound sessions (rendering any stateful firewall pretty much useless, because the 1st underlying address was at the mercy of the cloud operator, who could shift load around between physical machines at will). As another example, I've also come across plenty of firewalls or proxies that use NTLM or some other L7 protocol to identify a "user", but are then stuck to IP authentication for further follow up sessions, because NTLM or equivalent mechanism is either too slow, or not supported on that particular app. You also have the "https first" problem. In some cases/countries it is illegal to intercept/break https encryption (e.g. using fake certs). So if a user first connects to a proxy for a site that uses https, there's no way of authenticating them, and they are blocked until they use a standard http session (to another site). In short: Is there any intention to include a shim (containing some sort of nonce) to allow (legitimate) tracking and authentication (within an AS)? equivalent of http cookie at the network layer? That could even be stripped when leaving an AS/site boundary to alleviate privacy concerns. Or at least some more clarification on socket binding? I fear that this isn't as trivial a problem as the draft seems to suggest. regards, --------------070309070607050005050707 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Lorenzo Colitti wrote:
On Tue, Jul 7, 2015 at 9:02 AM, Fred Baker (fred) <fred@cisco.com> wrote:
The statement that I don't see in the document, which would help me personally, is a problem statement. I would guess that the problem statement is "we think some networks are limiting host interfaces to a single IPv6 address." I'd want a little more detail, but I'll bet that's the crux of it.

Not necessarily "are limiting" today, but "will limit" in the future.

Suppose that all operating systems of interest to a given network support DHCPv6 and it is thus possible to run a network without SLAAC and without IPv4 without denying service to substantial percentages of users.

Let's consider what would happen in such a DHCPv6-only network. How many addresses would be available to each host? Because DHCPv6 requires an explicit request to the network before an address can be used, the answer is, by definition, "as many as the network administrators decide to make available".

In some of these networks, the "as many as the network administrators decided to make available" may equate to just one. There could be lots of reasons for this: technical reasons such as "our IPAM and logging systems support only one address per host and it's tied into our legal intercept system so we can only give out one address per host", "we only have enough TCAM entries for one address per host", "one address per host is what we do in IPv4, and we want to be consistent with that".

If that sounds unreasonable, now consider what would happen in a hotel network that charges $5 per device. How many addresses would be available to hosts on such a network? At best, one for every $5 paid. More likely, if the billing system does not support more than one IPv6 address (why would it?), the answer would become "one per MAC address".

I hope we agree that such networks provide suboptimal service, and that there are a number of things that users would like to do that require either the availability of more than one IPv6 address.

If we are able to agree on that, then it is a useful statement to make, for two reasons:
1. The network administrators might listen to the statement.
2. Client and server implementations can implement network configuration protocols such as DHCPv6 in a way that does not lead to this suboptimal scenario.

Cheers,
Lorenzo

If I might add some comment to the "problem statement"

I'd like apps and users to be able to enjoy privacy from the "bad guys", and also be shielded from general attack and casual scans.

However, I'd also like the "good guys" to be able to track security relationships at some abstract level for audit and security purposes.



IMVHO That's still very much an area of "work to be completed" and is also the main reason why network operators want to limit the addresses in use (rather than the $5 per address reason cited).

As an example, inbound sessions can be clearly directed to a particular stable/well known destination address e.g. using DNS. And application daemons can generally be configured to listen only on particular addresses. But has anyone tried to force apps to use a particular source address as a source for related sessions, or "mirror at L7" outbound sessions to use the same source address as the destination address of the inbound message?

In OSI speak that's the session layer, and we don't really have one.

So the problem isn't just a matter of supporting multiple addresses at the network adapter layer; it's a matter of how those addresses are bound to apps, and how/when they are selected.

As one example, I recently came across an app that bound quite happily to a particular address on a VM adapter for inbound sessions/messages, but defaulted to using the first address configured on the underlying VM for all outbound sessions (rendering any stateful firewall pretty much useless, because the 1st underlying address was at the mercy of the cloud operator, who could shift load around between physical machines at will).

As another example, I've also come across plenty of firewalls or proxies that use NTLM or some other L7 protocol to identify a "user", but are then stuck to IP authentication for further follow up sessions, because NTLM or equivalent mechanism is either too slow, or not supported on that particular app.

You also have the "https first" problem. In some cases/countries it is illegal to intercept/break https encryption (e.g. using fake certs). So if a user first connects to a proxy for a site that uses https, there's no way of authenticating them, and they are blocked until they use a standard http session (to another site).

In short: Is there any intention to include a shim (containing some sort of nonce) to allow (legitimate) tracking and authentication (within an AS)?
equivalent of http cookie at the network layer?

That could even be stripped when leaving an AS/site boundary to alleviate privacy concerns.

Or at least some more clarification on socket binding?

I fear that this isn't as trivial a problem as the draft seems to suggest.

regards,
--------------070309070607050005050707-- From nobody Tue Jul 7 05:59:01 2015 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 5F08C1A034F for ; Tue, 7 Jul 2015 05:59:00 -0700 (PDT) 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 tVj8qjpnlqJS for ; Tue, 7 Jul 2015 05:58:58 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::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 07C9F1A02F1 for ; Tue, 7 Jul 2015 05:58:57 -0700 (PDT) Received: by wgjx7 with SMTP id x7so167160178wgj.2 for ; Tue, 07 Jul 2015 05:58:56 -0700 (PDT) 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=cuMac06x+RZRc1nauDJXDKeUf+2ohMhOGIGAJ4iGYaA=; b=VuH/anHFaxWUM2ZjxhV2eXBNKElfXTTW/JxpYOtCAC443kwd77pvy5N2L+MZGNaEdc gK+d7gEUYwyurk1Qdx7EM6PlJGueRRlVIiOHReL0HgtRBI0Aei2OLklf8m0dRMdWN60V uKKN6Ccmmjju2OMDEA5ShisgS4POEBY5GO576QSGgWnTMqZbGiL7KuDGd15cLN9cqo7y 4DGSJaryXDuuDOPxUWnMuRc48i53NU/22+AL2xILZm3U7e4Y1WFLf8L/46hYRUA1Ax9F d4GyLaq/zYAoWAkPf1Es4pmzBKojUD8eSd5nIXr77ZAXeaL+Xp7OleapJDfwogPEILGK ws8w== 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=cuMac06x+RZRc1nauDJXDKeUf+2ohMhOGIGAJ4iGYaA=; b=dcGX/IRgWHbeeOx2hOifLoWsC4To2m3STW/a3uBL9RaD+zcls0milvM8Os9NSYM8F2 I2S7s9Xdm5/jf0AEuyiKx0qeiOfR/yTF7nD3F2p6BpZ5hhG13xcSCWRvpfxGdftzeRCu JqlP9znlVpl1fZ65mfc3oRUKo1acs63D+bgzoSugkSq42tENb/LxLptAeMQLwJVAOT3M DzWDjS32u32YLVTZjLCOT+t0OUysr1Hlpjhbxnl+OVlTZvmzzKFmaiTcTwEi94tvuSRG vihrr1TcQrG+RTwTUeTtFzFoN+zDOrDpwpxmRrQczjzkQQrf8uPzdlSoemZYf0loryEQ wiDg== X-Gm-Message-State: ALoCoQnA1F9+EDX9t3SxqyfxFE/udPdL6R0D+z1RUyuFm+tMaYTea69iSxxVTrvRE7kOncsZN3VX X-Received: by 10.180.85.194 with SMTP id j2mr8024590wiz.11.1436273936559; Tue, 07 Jul 2015 05:58:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.138.203 with HTTP; Tue, 7 Jul 2015 05:58:36 -0700 (PDT) In-Reply-To: <559BCACB.3000106@globis.net> References: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> <9290D0D1-062A-4DE0-A437-9A5F5045ACAC@gmail.com> <39F63B55-977F-4B84-8B55-52E2F0B1A851@cisco.com> <559BCACB.3000106@globis.net> From: Erik Kline Date: Tue, 7 Jul 2015 21:58:36 +0900 Message-ID: To: Ray Hunter Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" , "draft-colitti-v6ops-host-addr-availability@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability 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, 07 Jul 2015 12:59:00 -0000 I think it's solvable with the logging I mentioned in an earlier post. Certainly when Google built such a system internally it seems to have kept the audit folks happy. On 7 July 2015 at 21:49, Ray Hunter wrote: > > > Lorenzo Colitti wrote: > > On Tue, Jul 7, 2015 at 9:02 AM, Fred Baker (fred) wrote: >> >> The statement that I don't see in the document, which would help me >> personally, is a problem statement. I would guess that the problem statement >> is "we think some networks are limiting host interfaces to a single IPv6 >> address." I'd want a little more detail, but I'll bet that's the crux of it. > > > Not necessarily "are limiting" today, but "will limit" in the future. > > Suppose that all operating systems of interest to a given network support > DHCPv6 and it is thus possible to run a network without SLAAC and without > IPv4 without denying service to substantial percentages of users. > > Let's consider what would happen in such a DHCPv6-only network. How many > addresses would be available to each host? Because DHCPv6 requires an > explicit request to the network before an address can be used, the answer > is, by definition, "as many as the network administrators decide to make > available". > > In some of these networks, the "as many as the network administrators > decided to make available" may equate to just one. There could be lots of > reasons for this: technical reasons such as "our IPAM and logging systems > support only one address per host and it's tied into our legal intercept > system so we can only give out one address per host", "we only have enough > TCAM entries for one address per host", "one address per host is what we do > in IPv4, and we want to be consistent with that". > > If that sounds unreasonable, now consider what would happen in a hotel > network that charges $5 per device. How many addresses would be available to > hosts on such a network? At best, one for every $5 paid. More likely, if the > billing system does not support more than one IPv6 address (why would it?), > the answer would become "one per MAC address". > > I hope we agree that such networks provide suboptimal service, and that > there are a number of things that users would like to do that require either > the availability of more than one IPv6 address. > > If we are able to agree on that, then it is a useful statement to make, for > two reasons: > 1. The network administrators might listen to the statement. > 2. Client and server implementations can implement network configuration > protocols such as DHCPv6 in a way that does not lead to this suboptimal > scenario. > > Cheers, > Lorenzo > > > If I might add some comment to the "problem statement" > > I'd like apps and users to be able to enjoy privacy from the "bad guys", and > also be shielded from general attack and casual scans. > > However, I'd also like the "good guys" to be able to track security > relationships at some abstract level for audit and security purposes. > > > > IMVHO That's still very much an area of "work to be completed" and is also > the main reason why network operators want to limit the addresses in use > (rather than the $5 per address reason cited). > > As an example, inbound sessions can be clearly directed to a particular > stable/well known destination address e.g. using DNS. And application > daemons can generally be configured to listen only on particular addresses. > But has anyone tried to force apps to use a particular source address as a > source for related sessions, or "mirror at L7" outbound sessions to use the > same source address as the destination address of the inbound message? > > In OSI speak that's the session layer, and we don't really have one. > > So the problem isn't just a matter of supporting multiple addresses at the > network adapter layer; it's a matter of how those addresses are bound to > apps, and how/when they are selected. > > As one example, I recently came across an app that bound quite happily to a > particular address on a VM adapter for inbound sessions/messages, but > defaulted to using the first address configured on the underlying VM for all > outbound sessions (rendering any stateful firewall pretty much useless, > because the 1st underlying address was at the mercy of the cloud operator, > who could shift load around between physical machines at will). > > As another example, I've also come across plenty of firewalls or proxies > that use NTLM or some other L7 protocol to identify a "user", but are then > stuck to IP authentication for further follow up sessions, because NTLM or > equivalent mechanism is either too slow, or not supported on that particular > app. > > You also have the "https first" problem. In some cases/countries it is > illegal to intercept/break https encryption (e.g. using fake certs). So if a > user first connects to a proxy for a site that uses https, there's no way of > authenticating them, and they are blocked until they use a standard http > session (to another site). > > In short: Is there any intention to include a shim (containing some sort of > nonce) to allow (legitimate) tracking and authentication (within an AS)? > equivalent of http cookie at the network layer? > > That could even be stripped when leaving an AS/site boundary to alleviate > privacy concerns. > > Or at least some more clarification on socket binding? > > I fear that this isn't as trivial a problem as the draft seems to suggest. > > regards, > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue Jul 7 06:44:58 2015 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 A724D1A902A for ; Tue, 7 Jul 2015 06:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 Q7iNwiziKYfW for ; Tue, 7 Jul 2015 06:44:56 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c: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 1CF831A8AD9 for ; Tue, 7 Jul 2015 06:44:56 -0700 (PDT) Received: by wgjx7 with SMTP id x7so168379638wgj.2 for ; Tue, 07 Jul 2015 06:44:54 -0700 (PDT) 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=j9TsrbUDHjQKML559M3M4ImvaArMuyTKr2jREXYpRc0=; b=hOYnvWhjIq277zvxYGjKSnZPNn6HyZ9BUBezVGcl0jkkyfehX7mBIKrfO85Vhj9IlD GKnQtMdzBJT9bV+lZy84D55kTZS212XhJD9vcuiJXpieu3LITvtK0OfFSkJV8pTqk3Em xckxOU4bXHIoqoe0rD/XDApn9n7G5+ef2zcyjYAm05Y990qS2kUJ9CDlazMgVH/qqJ3t 5BduZSGLwfom4REuKJovpwV+A2e5iqQjPGXBsXZlgcUNtvgb0hQq/bi9r6pAmL7SQU7+ qLMnfvJP0iiSx+dTtU0tlvtjwK+nClC03f9Q4Xw3qOmQ+H11GLsxhk8GgebuzXj5C4qO lr9w== MIME-Version: 1.0 X-Received: by 10.194.10.165 with SMTP id j5mr9138951wjb.147.1436276694809; Tue, 07 Jul 2015 06:44:54 -0700 (PDT) Received: by 10.194.191.232 with HTTP; Tue, 7 Jul 2015 06:44:54 -0700 (PDT) In-Reply-To: <201507071147.t67Bl1VL009344@irp-lnx1.cisco.com> References: <201507071147.t67Bl1VL009344@irp-lnx1.cisco.com> Date: Tue, 7 Jul 2015 06:44:54 -0700 Message-ID: From: Ca By To: "fred@cisco.com" Content-Type: multipart/alternative; boundary=e89a8f642b06318243051a493a44 Archived-At: Cc: "v6ops@ietf.org" , "draft-akira-v6ops-mape-experience@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-akira-v6ops-mape-experience 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, 07 Jul 2015 13:44:57 -0000 --e89a8f642b06318243051a493a44 Content-Type: text/plain; charset=UTF-8 On Tuesday, July 7, 2015, wrote: > A new draft has been posted, at > http://tools.ietf.org/html/draft-akira-v6ops-mape-experience. Please take > a look at it and comment. > > Thanks for writing this. It would benefit by going into more detail about the is the scale. Was this evaluation in a lab? 10 users? 10,000 users? How much IPv4 addresses space was used? How many ports per subscriber ? It says MAP-E failed to provide a good experience for some games, h323, and active ftp. Can you please provide one chart with all the applications tested and the result ? Thanks CB > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --e89a8f642b06318243051a493a44 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tuesday, July 7, 2015, <fr= ed@cisco.com> wrote:
A new draft h= as been posted, at http://tools.ietf.org/html/draft-akira-v= 6ops-mape-experience. Please take a look at it and comment.


Thanks for writing this.=C2=A0

It would benefit by going into more detail about the is t= he=C2=A0scale. Was this evaluation=C2=A0in a lab? 10 users? 10,000 users? H= ow much IPv4 addresses space was used? How many ports per subscriber ?

It says MAP-E failed to provide a good experience for = some games, h323, and active ftp. Can you please provide one chart with all= the applications tested and the result ?

Thanks= =C2=A0

CB=C2=A0
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops
--e89a8f642b06318243051a493a44-- From nobody Tue Jul 7 07:22:00 2015 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 A49631AC3F7 for ; Tue, 7 Jul 2015 07:21:58 -0700 (PDT) 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 mpAklidYl26a for ; Tue, 7 Jul 2015 07:21:57 -0700 (PDT) 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 74DAE1AC3F6 for ; Tue, 7 Jul 2015 07:21:57 -0700 (PDT) Received: from [2a02:c0:2:1:1194:17:0:1029] (port=57733 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1ZCTkw-0005ij-5q; Tue, 07 Jul 2015 16:21:54 +0200 Date: Tue, 7 Jul 2015 16:21:53 +0200 From: Tore Anderson To: v6ops@ietf.org Message-ID: <20150707162153.5b8629c1@envy.fud.no> In-Reply-To: <20150707110847.5119162d@echo.ms.redpill-linpro.com> References: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> <20150707110847.5119162d@echo.ms.redpill-linpro.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-colitti-v6ops-host-addr-availability@tools.ietf.org Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability 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, 07 Jul 2015 14:21:58 -0000 * Tore Anderson > I have some feedback and suggestions, see below: Forgot one: 21) Section 12: Reference [QUIC IETF slides] (from section 5) is nowhere to be seen. Tore From nobody Tue Jul 7 07:55:59 2015 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 014F21ACD25 for ; Tue, 7 Jul 2015 07:55:58 -0700 (PDT) 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 0A91Oj9uj9qS for ; Tue, 7 Jul 2015 07:55:56 -0700 (PDT) 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 7D8501AC41C for ; Tue, 7 Jul 2015 07:55:56 -0700 (PDT) Received: from [2a02:c0:2:1:1194:17:0:1029] (port=57855 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1ZCUHo-0006ep-ER; Tue, 07 Jul 2015 16:55:52 +0200 Date: Tue, 7 Jul 2015 16:55:51 +0200 From: Tore Anderson To: v6ops@ietf.org Message-ID: <20150707165551.6b90a7a3@envy.fud.no> In-Reply-To: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 07 Jul 2015 14:55:58 -0000 * fred@cisco.com > A new draft has been posted, at > http://tools.ietf.org/html/draft-yc-v6ops-solicited-ra-unicast. > Please take a look at it and comment. Support WG adoption. Comments: 1) Nit: Abstract: s/network/networks/ (Or so I think. I'm not a native speaker.) 2) Section 2, second bullet: Would like to add that the lost connectivity (due to default route expiring) persists after the device has woken back up again. This is another big reason for a network operator to send RAs frequently, to ensure that a device re-gains its connectivity as soon as the user starts interacting with his device. Furthermore, a reference to draft-ietf-6man-rs-refresh might be prudent here. 3) Section 3: Did you consider recommending making unicast the default behaviour for solicited RAs on all networks, not just the ones with sleepy devices? I was thinking about it for a while and I couldn't immediately see any big issue with that, but I might be missing something. If the recommended approach isn't also suitable for, say, an enterprise wired LAN with desktop PCs, or a data centre server LAN, maybe include some text describing why not? 4) Section 3: I think that for a complete solution you should also recommend that hosts MUST not ignore multicast RAs when they're sleeping. Otherwise, you're missing a big part of the solution - the hosts I discussed in #2 still lost their connectivity while sleeping and after waking back up, and the way to combat that would still be for the network to send unsolicited (multicast) RAs frequently. Tore From nobody Tue Jul 7 08:33:59 2015 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 3F2091A88F4 for ; Tue, 7 Jul 2015 08:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrFRlagnfmZA for ; Tue, 7 Jul 2015 08:33:55 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A638C1A88F3 for ; Tue, 7 Jul 2015 08:33:55 -0700 (PDT) Received: by igcsj18 with SMTP id sj18so264652339igc.1 for ; Tue, 07 Jul 2015 08:33:55 -0700 (PDT) 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=N8LiLmkNLGHuGILYDEDhO+kysP31uso+XJSQCbCN8gI=; b=VCxKHphBTSX/OUC/x/HfLbKM1kxK+dx6jOtzgSKUYW1pERAURcu82+dCj0qXer3zs8 J5N1+Su/9Ia/9yXPvrzOfNIK6GjKcn1Bx0w/4gfC9LxwJjDIHMMsK8Y2mpBXweWM2lMN 5NZgMuQiEBv+p6N4D0xeMRnTonb7cq2tBxYfVe5BAfnjc4mkKsX+4stdr2kRFUMeOQou k0hNJUjD5i5laOqXjtz501oAohcqW+BzhE30+3uwyti+dRJKjSqertazyEWZ42GXfP62 d2XLuJEQTTbCqvgfXRijulOVXlgfhCsWSMpTwYsxYZMyh2xNQRUJrrMqixQ5esffIEno VcGg== MIME-Version: 1.0 X-Received: by 10.107.13.201 with SMTP id 192mr7438731ion.70.1436283233588; Tue, 07 Jul 2015 08:33:53 -0700 (PDT) Received: by 10.107.182.7 with HTTP; Tue, 7 Jul 2015 08:33:53 -0700 (PDT) In-Reply-To: <39F63B55-977F-4B84-8B55-52E2F0B1A851@cisco.com> References: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> <9290D0D1-062A-4DE0-A437-9A5F5045ACAC@gmail.com> <39F63B55-977F-4B84-8B55-52E2F0B1A851@cisco.com> Date: Tue, 7 Jul 2015 17:33:53 +0200 Message-ID: From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= To: "Fred Baker (fred)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" , "draft-colitti-v6ops-host-addr-availability@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability 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, 07 Jul 2015 15:33:57 -0000 On 7/7/15, Fred Baker (fred) wrote: > Thanks. One question. Chair hat off. > > Section 2 identifies the current deployment model - each interface has a > link-local address, a SLAAC address, and one or more temporary addresses. I > haven't heard anyone complaining about that. Section 3 goes on to discuss > virtual machines/containers, which might each have additional addresses, and > the model Facebook is reportedly using, which gives individual addresses to > processes. It also mentions draft-herbert-nvo3-ila, which is not a stupid > model - I still have some comments on it in a multi-administration > environment or for running applications in an "inside" and an "outside" > address ("NAT has well-known drawbacks"), but it at least gets rid of the > random encapsulations predominant in data centers today. > > In other words, we already assign multiple addresses, by some means, to each > interface in a network. > > You mention SLAAC. Lorenzo mentions that in section 7. He also mentions DHCP > address and prefix allocation. Lorenzo already commented on the "problem definition" so I will reply just to this part: Yes, we both mention them - but I'm arguing the usage of them should be proactively monitored by the devices themselves. Preferably along with the tangible benefits provided to the apps when the device is on a network allowing for more than one address. (Though that is outside of the "ops" domain). --a > > The statement that I don't see in the document, which would help me > personally, is a problem statement. I would guess that the problem statement > is "we think some networks are limiting host interfaces to a single IPv6 > address." I'd want a little more detail, but I'll bet that's the crux of > it. > > So my question is: "precisely what problem are we solving here?". > >> On Jul 6, 2015, at 2:39 PM, Andrew Yourtchenko >> wrote: >> >> I read the draft and absolutely agree with the spirit. >> >> Unfortunately, I think it won't work: >> >> As soon as the devices work "good enough" with a single address, appealing >> to increase the amount of work by administrators in the name of humanity >> is going to fall on deaf ears. >> >> The only way I see to solve this is to always use SLAAC on the devices: >> either 'externally' from the prefix received within the RA, or >> 'internally' from within the prefix received via DHCP-PD, and provide a >> mandatory registration mechanism for name-to-IP mapping. >> >> If neither of the above works, as a backup effort the device can try >> getting N addresses via DHCP IA_NA and release those that it does not need >> immediately - and displaying a big yellow warning "This network may >> restrict IPv6 functionality and eat your kittens, contact your system >> administrator". Because ND is not going to happen on these 'extra' >> addresses, forwarding wise there will be no impact, just some more DHCP >> traffic after attachment (the "limited functionality" of course would need >> just one address and can start immediately). >> >> Those who want tracking can track the upper 64bits or use IA_NA and filter >> out the addresses that are shortly lived. >> >> Of course to avoid being a religious crusade such an effort need to >> produce something pragmatic - namely, >> a userland cross-platform API that would allow getting new addresses on >> demand by application and if needs to - implementing custom transport >> protocols on top of those on a per-app-per-address basis. >> >> The above conjecture however is even less realistic than politely asking >> the inconveniences away, so the logical conclusion from that is I fully >> support this draft. >> >> --a >> >>> On 06 Jul 2015, at 13:47, fred@cisco.com wrote: >>> >>> A new draft has been posted, at >>> http://tools.ietf.org/html/draft-colitti-v6ops-host-addr-availability. >>> Please take a look at it and comment. >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops > > From nobody Tue Jul 7 09:28:02 2015 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 07F161ACE26 for ; Tue, 7 Jul 2015 09:28:00 -0700 (PDT) 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 EyFaoCWG_geI for ; Tue, 7 Jul 2015 09:27:54 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7929F1ACE29 for ; Tue, 7 Jul 2015 09:27:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3679; q=dns/txt; s=iport; t=1436286474; x=1437496074; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zY9QiJAE5ykWk2cLZLv2c8qefq4uMSxu1wwvkNu1kfo=; b=TINtdplJWjsGRgyKxGCG4QCO8q9BIhuqkMLWaniXooqlQGfQ2+xyzTXD hJ0vBR1tW4SeT33391siTE9JUthbIMtsuaRV/Xmrbf1XkhAin3vW6o47J sDVl3ifD3L6s305AaBgELMJKGAX9N/xTChRD5Fn0cUVtzpD5hKQmoaF1z 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BtAwB5/ZtV/5FdJa1bgxKBNAa9ZgmHZgKBVTgUAQEBAQEBAYEKhCMBAQEEOj8MBAIBCBEEAQELFAkHMhQJCAIEAQ0FCIgmzFUBAQEBAQEBAQEBAQEBAQEBAQEBAQEXi0uEIjMxBwaDEYEUBYVcjjwBhAGJIYQXgw+PeiaCDByBU2+BBCQfgQQBAQE X-IronPort-AV: E=Sophos;i="5.15,424,1432598400"; d="scan'208";a="13357860" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-2.cisco.com with ESMTP; 07 Jul 2015 16:27:53 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t67GRras019242 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Jul 2015 16:27:53 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.34]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Tue, 7 Jul 2015 11:27:53 -0500 From: "Hemant Singh (shemant)" To: "Fred Baker (fred)" , Andrew Yourtchenko Thread-Topic: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability Thread-Index: AQHQt+GUs8uYiRy2iUusolpZfA8qWp3PTI+AgAAnzoCAALsP8A== Date: Tue, 7 Jul 2015 16:27:53 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B89168B353B@xmb-rcd-x06.cisco.com> References: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> <9290D0D1-062A-4DE0-A437-9A5F5045ACAC@gmail.com> <39F63B55-977F-4B84-8B55-52E2F0B1A851@cisco.com> In-Reply-To: <39F63B55-977F-4B84-8B55-52E2F0B1A851@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.131.71.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" , "draft-colitti-v6ops-host-addr-availability@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability 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, 07 Jul 2015 16:28:00 -0000 Seeing Fred's response, I do agree with him. My comments are included bel= ow. 1. The IPv6 node requirements document does not block any host from using m= ultiple addresses. So why write a new draft whose abstract says "use multi= ple addresses for hosts"? Thus more problem definition is needed in the ab= stract.=20 2. In section 3 and other places in the document, using a /64 die tethering= is a hack even if the IETF has an RFC covering the hack. Use the DHCPv6-P= D for tethering.=20 3. In section 3, "running virtual machines on hosts" is obvious and falls o= ut from the fact that each virtual machine needs it IPv6 address and mac-ad= dress. This problem does not relate to a host with one mac-address using m= ultiple IPv6 addresses. 4. Section 7. SLAAC as defined in RFC4862 supports only one IPv6 global ad= dress if one prefix is advertised in the RA to the host. Thus the text in = this section can be improved. If the RA includes multiple prefixes, then t= he host can generate a global IPv6 address using SLAAC. =20 5. Section 8.1. SAVI for a non-DHCPv6 network also needs a DAD Proxy. Jus= t add a DAD Proxy to the router and the DAD Proxy programs the dataplane's = SAVI. Also, anywhere the document says DHCPv6 is the only means for admins= at universities or corporate deployments to track host sources is question= able. The router can add DAD Proxy support and then the admin grabs data = from the routers DAD proxy for host sources. I have already made such a st= atement to v6ops in another thread. =20 6. Please read the IPv6 CE router documents which describer use of an IPv6= loopback address and interface. Such a loopback interface can serve any a= pp that needs a stable address. In summary, I have not seen enough of a problem statement nor do I agree wi= th many technical statements in the document to support this version of the= document for WG adoption. Thanks, Hemant -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker (fred) Sent: Monday, July 06, 2015 8:02 PM To: Andrew Yourtchenko Cc: v6ops@ietf.org; draft-colitti-v6ops-host-addr-availability@tools.ietf.o= rg Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability Thanks. One question. Chair hat off. Section 2 identifies the current deployment model - each interface has a li= nk-local address, a SLAAC address, and one or more temporary addresses. I h= aven't heard anyone complaining about that. Section 3 goes on to discuss vi= rtual machines/containers, which might each have additional addresses, and = the model Facebook is reportedly using, which gives individual addresses to= processes. It also mentions draft-herbert-nvo3-ila, which is not a stupid = model - I still have some comments on it in a multi-administration environm= ent or for running applications in an "inside" and an "outside" address ("N= AT has well-known drawbacks"), but it at least gets rid of the random encap= sulations predominant in data centers today. In other words, we already assign multiple addresses, by some means, to eac= h interface in a network. You mention SLAAC. Lorenzo mentions that in section 7. He also mentions DHC= P address and prefix allocation. The statement that I don't see in the document, which would help me persona= lly, is a problem statement. I would guess that the problem statement is "w= e think some networks are limiting host interfaces to a single IPv6 address= ." I'd want a little more detail, but I'll bet that's the crux of it. So my question is: "precisely what problem are we solving here?". From nobody Tue Jul 7 09:51:42 2015 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 0813F1ACE98 for ; Tue, 7 Jul 2015 09:51:41 -0700 (PDT) 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 YUUs4ekhu8Dw for ; Tue, 7 Jul 2015 09:51:39 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 545831ACE99 for ; Tue, 7 Jul 2015 09:51:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1295; q=dns/txt; s=iport; t=1436287900; x=1437497500; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=hs/zyKHeUb3lYe1pm784KdM8Y1KKIq+QC4pw6C68vhc=; b=PCSeyLcqNFMIX+7pVM/39+F6GXyUWfha6FVNf7q8gbPedEoKQdeA/ehe rHkcSW59WkacXMI5N7vYthm6yCmaDuZk/I/MXKERituyUdILUP+8SY505 9MivkoM0aIVyEbgqXAKvIvQhkBW0KtOajuEc23eL6ydfOkXCUYw0z77Lw c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BwAwADA5xV/5NdJa1bgxJUYAa9ZgmBZQqFdwKBWDgUAQEBAQEBAYEKhCMBAQEEAQEBNzQLDAQCAQgRBAEBCxQJBycLFAkIAgQBDQUIiCYNzFUBAQEBAQEBAQEBAQEBAQEBAQEBAQEXi0uEIxEBIDEHBoMRgRQFlBgBhGGIQUWDUpMJJoN7b4ENOoEEAQEB X-IronPort-AV: E=Sophos;i="5.15,424,1432598400"; d="scan'208";a="166026028" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-2.cisco.com with ESMTP; 07 Jul 2015 16:51:39 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t67GpcCG026606 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Jul 2015 16:51:38 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.34]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Tue, 7 Jul 2015 11:51:38 -0500 From: "Hemant Singh (shemant)" To: "Fred Baker (fred)" , "v6ops@ietf.org" Thread-Topic: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability Thread-Index: AQHQt+GUs8uYiRy2iUusolpZfA8qWp3QOISA Date: Tue, 7 Jul 2015 16:51:37 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B89168B3599@xmb-rcd-x06.cisco.com> References: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> In-Reply-To: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.131.71.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-colitti-v6ops-host-addr-availability@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability 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, 07 Jul 2015 16:51:41 -0000 Perhaps this will help focus the problem statement. Cable broadband standards for IPv6 already cover multiple IPv6 addresses fo= r hosts. DSL broadband should also cover multiple IPv6 addresses. Thus t= he gross networks one is left with is corporate (includes universities) wir= ed and wireless and cellular. For IOT and sensors one already has other do= cuments covering their IPv6 behavior. Additionally, do you want such sens= ors to also support more than one IPv6 global address? =20 Sorry for the typo in my other email related to multiple prefixes in the RA= . It's when multiple prefixes are included in the RA, the host can assign = a global address per prefix. =20 Thanks, Hemant -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker (fred) Sent: Monday, July 06, 2015 7:47 AM To: v6ops@ietf.org Cc: draft-colitti-v6ops-host-addr-availability@tools.ietf.org Subject: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability A new draft has been posted, at http://tools.ietf.org/html/draft-colitti-v6= ops-host-addr-availability. Please take a look at it and comment. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Jul 7 13:41:54 2015 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 734B61A903E for ; Tue, 7 Jul 2015 13:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqXYziOXyL-S for ; Tue, 7 Jul 2015 13:41:52 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::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 6707C1A8F50 for ; Tue, 7 Jul 2015 13:41:52 -0700 (PDT) Received: by pddu5 with SMTP id u5so44326547pdd.3 for ; Tue, 07 Jul 2015 13:41:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=edr+YeSPSWp7cSX4Chdcdwzq4Xy/52Aj6Q55Fw6c8g4=; b=w0H+OCLK6rkDkZIHmGj98MEceALQ6TTlJAku2GW2Z8u5Imp2KeMIUXDTVhnKu/VtzS /Dil/I2xZLBbKc+X4DDo48k0qkpqktAVG62nwvQk0uyiIsd8UZrGKoJ9H1J7WtKVm/Hr JvN0MLKWUapQv1YfnnC4j9mFq9teKShL1cNAS5Ayza9hn8mVAiVUs6TS03yfYr8ZbMws JTSrs8E7Xfe+pvC5lgLT0pyTUUFehjAbBeldcgdprpPs8boqMweyPK5KGFzd4Fn6A6I8 imb7u6bkXQC8fu0c3ZO6PSW2ntrUW+pd8B8WJ7Sj5EdOLe1PjCnitfFYYZJlmbC2/h/f Kk3g== X-Received: by 10.68.129.134 with SMTP id nw6mr12459995pbb.109.1436301711928; Tue, 07 Jul 2015 13:41:51 -0700 (PDT) Received: from [10.1.237.170] ([131.203.247.181]) by mx.google.com with ESMTPSA id om10sm22798750pbb.58.2015.07.07.13.41.47 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Jul 2015 13:41:50 -0700 (PDT) Message-ID: <559C394D.5090902@gmail.com> Date: Wed, 08 Jul 2015 08:40:45 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Hemant Singh (shemant)" , "Fred Baker (fred)" , Andrew Yourtchenko References: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> <9290D0D1-062A-4DE0-A437-9A5F5045ACAC@gmail.com> <39F63B55-977F-4B84-8B55-52E2F0B1A851@cisco.com> <75B6FA9F576969419E42BECB86CB1B89168B353B@xmb-rcd-x06.cisco.com> In-Reply-To: <75B6FA9F576969419E42BECB86CB1B89168B353B@xmb-rcd-x06.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" , "draft-colitti-v6ops-host-addr-availability@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability 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, 07 Jul 2015 20:41:53 -0000 On 08/07/2015 04:27, Hemant Singh (shemant) wrote: ... > 4. Section 7. SLAAC as defined in RFC4862 supports only one IPv6 global address if one prefix is advertised in the RA to the host. It does? I don't see anything in 4862 that prevents a host from generating N separate IIDs and performing SLAAC N times for the same prefix. Now we are getting rid of Modified EUI-64 as the default IID, that becomes an obvious thing to do. Brian From nobody Tue Jul 7 13:49:30 2015 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 27BEB1A90ED for ; Tue, 7 Jul 2015 13:49:28 -0700 (PDT) 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 Azgu1xZ__3ka for ; Tue, 7 Jul 2015 13:49:27 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B5BB1ACD98 for ; Tue, 7 Jul 2015 13:48:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2116; q=dns/txt; s=iport; t=1436302084; x=1437511684; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=o6Qq7Sp+xa1+BXon5CyGC8eXO73xNtAeeLcO6tcSse8=; b=QRnIfrwgz1OprcKCvGIBFzO4Z7ubfOiJxgnmyo6mqU2mCI7HsaQrAX3C ctXs22ot7oj0ElmO6i4dGPLM3SpQ9PJ1I4AZZGdv6QcU9X+KXs4B9CZyQ v3RQkzrqHONAi5Bve+K5TY9xTysa4B2EZOb/k+fXveKDH79wZwffe7m7l 8=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CaAwDdOZxV/5ldJa1bgxKBNAa9ZwmHZgKBYTgUAQEBAQEBAYEKhCMBAQEDAXkFCwIBCBguIRElAgQOBQ6ICwMKCMclDYVmAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tLgk2COQeDF4EUAQSUGAGCKoFShgeBZZE9hx0mggwcgVNvAYFGgQQBAQE X-IronPort-AV: E=Sophos; i="5.15,426,1432598400"; d="asc'?scan'208"; a="7788630" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 07 Jul 2015 20:48:03 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t67Km3lu002147 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Jul 2015 20:48:03 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.49]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Tue, 7 Jul 2015 15:48:03 -0500 From: "Fred Baker (fred)" To: Brian E Carpenter Thread-Topic: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability Thread-Index: AQHQuPY3BHauQbVBCEu6ODF/i9HGsQ== Date: Tue, 7 Jul 2015 20:48:03 +0000 Message-ID: <3014DAAD-757C-41E1-893F-CA5242BB3FD7@cisco.com> References: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> <9290D0D1-062A-4DE0-A437-9A5F5045ACAC@gmail.com> <39F63B55-977F-4B84-8B55-52E2F0B1A851@cisco.com> <75B6FA9F576969419E42BECB86CB1B89168B353B@xmb-rcd-x06.cisco.com> <559C394D.5090902@gmail.com> In-Reply-To: <559C394D.5090902@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.123] Content-Type: multipart/signed; boundary="Apple-Mail=_1E3CFA34-9FB1-4A45-BB30-6547E7CF479D"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "draft-colitti-v6ops-host-addr-availability@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability 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, 07 Jul 2015 20:49:28 -0000 --Apple-Mail=_1E3CFA34-9FB1-4A45-BB30-6547E7CF479D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jul 7, 2015, at 1:40 PM, Brian E Carpenter = wrote: >=20 > On 08/07/2015 04:27, Hemant Singh (shemant) wrote: > ... >> 4. Section 7. SLAAC as defined in RFC4862 supports only one IPv6 = global address if one prefix is advertised in the RA to the host. >=20 > It does? I don't see anything in 4862 that prevents a host from = generating N separate > IIDs and performing SLAAC N times for the same prefix. Now we are = getting rid > of Modified EUI-64 as the default IID, that becomes an obvious thing = to do. Well, yes, but the present algorithm starts from the MAC address on an = interface. There's only one such MAC address on any given interface. To = do what you said, we need to (see a certain draft) change that = algorithm. --Apple-Mail=_1E3CFA34-9FB1-4A45-BB30-6547E7CF479D 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 iQIVAwUBVZw6/UayAOS/EQ8MAQJmJxAAqKvktHrCV50fUCGz92I6+KrMSWG3K7n9 JVMDavGsTgaC03cLFfFCVE41/2Wzo9XplTLzSvgshwyrkWf4VrLiAs/LPO4C5dmw zOYpTK5p1lUSUZAfZ3ej1Tdx0GxHGzxmi/eecTXnac7MlXUsqnuZVJulozh8OQiv MkdqjbEzaCGh9VCVCtP/CCu1cMTnOYc4kJ/ryvP2iFwKoTa16qV8uBZB7yeiQFIi lpJb9xd2AdFsQhVUJU9NHa+OMJbE4MNO3tgU+ijORTSrFByw9l2YvUcXO7qGEiGu BDk5gkpMJAwJXFYyk29ZwIFQgHgMY0NAjSHq676EuthKZi/79gJV8o3eN9nTTE4K 2EdZ1O6YVaEVAdyLYtk4XdfK/KuLogR6zhpAjL9MxtnhjpXEiLuDlOJeeM4VhydH yQdmXaE2VNEWhn0eF+TyThkvPggac/zGo9qJ9oS+Q6oTttHwAt3cTNpwXnSzWbL4 aTlhejDD0vI4YACNFnsJ4b9L+OtaOEmL+P+En0d9zejwfgEjCZlqLHnGCxTXXxsa ZbUbmuXSFYsl4UNJc5oU1QKOo3VlC4oXTJ3U52p3yuvWe/lEuqJhQ1qkLMrXLGv9 4sy8T8h9oOPfH7ge65tcxXUsflGRVZQjITl0JSwBq1raqpkbP0wLyOGGYWPgB7Za ZRA2akOeR7M= =MfdC -----END PGP SIGNATURE----- --Apple-Mail=_1E3CFA34-9FB1-4A45-BB30-6547E7CF479D-- From nobody Tue Jul 7 14:08:30 2015 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 B99E91ACDB9 for ; Tue, 7 Jul 2015 14:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqS_9pRIozx9 for ; Tue, 7 Jul 2015 14:08:26 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::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 809511ACDB3 for ; Tue, 7 Jul 2015 14:08:26 -0700 (PDT) Received: by pactm7 with SMTP id tm7so119044055pac.2 for ; Tue, 07 Jul 2015 14:08:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=mkl0bdYK8Z5WFXi5JjwcfgcQUuAtoWzX7ESiSfebilo=; b=doR8wlogFA90JuKpNq7RT5OHy0la+jSeK9LBtCCcbiuIHlu5tQLEUR8U5aZy4bGJEn uWQON3RoMiYFGikCYwVN4FE/2U/Lej9HBmJKw8aCMMGlSUQ5I/3xF2oFfH3NPEkt7R6J m9DGJ7SUGO4f/bDfWIpVKRRravJQW8QI1/r+sKc2Axe1Zg7mJFnyPfM8TuAmRx4otbPA wgA5NXVZ9kTeRP/R5rTG5dnL0FapWxmYpjjddHbDaXAR8AB/60/4TS+udhTNVlMHrnoy uZcisP3ofnad2akTOnGMqhwt5zkgvVFM7H+YExbeYcjph0oyJoYVMmHW0fs+/UjAVbzz drPA== X-Received: by 10.70.8.131 with SMTP id r3mr12902052pda.62.1436303306194; Tue, 07 Jul 2015 14:08:26 -0700 (PDT) Received: from [10.1.237.170] ([131.203.247.181]) by smtp.gmail.com with ESMTPSA id kp2sm47215pab.12.2015.07.07.14.08.21 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Jul 2015 14:08:25 -0700 (PDT) Message-ID: <559C3FC7.1050402@gmail.com> Date: Wed, 08 Jul 2015 09:08:23 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Fred Baker (fred)" References: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> <9290D0D1-062A-4DE0-A437-9A5F5045ACAC@gmail.com> <39F63B55-977F-4B84-8B55-52E2F0B1A851@cisco.com> <75B6FA9F576969419E42BECB86CB1B89168B353B@xmb-rcd-x06.cisco.com> <559C394D.5090902@gmail.com> <3014DAAD-757C-41E1-893F-CA5242BB3FD7@cisco.com> In-Reply-To: <3014DAAD-757C-41E1-893F-CA5242BB3FD7@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-colitti-v6ops-host-addr-availability@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability 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, 07 Jul 2015 21:08:28 -0000 On 08/07/2015 08:48, Fred Baker (fred) wrote: > >> On Jul 7, 2015, at 1:40 PM, Brian E Carpenter wrote: >> >> On 08/07/2015 04:27, Hemant Singh (shemant) wrote: >> ... >>> 4. Section 7. SLAAC as defined in RFC4862 supports only one IPv6 global address if one prefix is advertised in the RA to the host. >> >> It does? I don't see anything in 4862 that prevents a host from generating N separate >> IIDs and performing SLAAC N times for the same prefix. Now we are getting rid >> of Modified EUI-64 as the default IID, that becomes an obvious thing to do. > > Well, yes, but the present algorithm starts from the MAC address on an interface. There's only one such MAC address on any given interface. To do what you said, we need to (see a certain draft) change that algorithm. Agreed. But IMHO we don't need to change 4862, so Hemant's comment is not quite right. Brian From nobody Tue Jul 7 14:12:31 2015 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 CAC751ACDF2 for ; Tue, 7 Jul 2015 14:12:29 -0700 (PDT) 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 UwMO1CR820lV for ; Tue, 7 Jul 2015 14:12:28 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E0A11ACDEF for ; Tue, 7 Jul 2015 14:12:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1676; q=dns/txt; s=iport; t=1436303548; x=1437513148; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=y54QFY/rod5wayUz+msYfK44Wn57FwvzqX8CG/pXpq8=; b=bgZCjYBBycCif1foLtCNEiPyPQ8DijBl3UGxXe60ZiMRJLvC5uBr/98e VFg9125urP8C+6Tg+XNfQ/LyYvDUwr4vPHVYt3ZYNt8vgvi4pCMOdcNvo Qug5erT2vHeMgQy6kHT3ypcUgtbxfXUYsVTwhoiBauME1j+UTGw/+dvju s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C+AwBDQJxV/4oNJK1bgxKBNAaDGrpNCYdmAhyBRzgUAQEBAQEBAYEKhCMBAQEEIxFFDAQCAQgRBAEBAwIGHQMCAgIfERQBCAgCBAENBQiIEQMStkyQVA2FZgEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIYoqgk2CCDEHBoJiL4EUAQSUGAGKA5Mihx0mggwcgVNvAYFGgQQBAQE X-IronPort-AV: E=Sophos;i="5.15,426,1432598400"; d="scan'208";a="9695747" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-5.cisco.com with ESMTP; 07 Jul 2015 21:12:27 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t67LCRIr010080 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Jul 2015 21:12:27 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.34]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Tue, 7 Jul 2015 16:12:26 -0500 From: "Hemant Singh (shemant)" To: Brian E Carpenter , "Fred Baker (fred)" , Andrew Yourtchenko Thread-Topic: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability Thread-Index: AQHQt+GUs8uYiRy2iUusolpZfA8qWp3PTI+AgAAnzoCAALsP8IAAnweA//+v2rA= Date: Tue, 7 Jul 2015 21:12:26 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B89168B37BC@xmb-rcd-x06.cisco.com> References: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> <9290D0D1-062A-4DE0-A437-9A5F5045ACAC@gmail.com> <39F63B55-977F-4B84-8B55-52E2F0B1A851@cisco.com> <75B6FA9F576969419E42BECB86CB1B89168B353B@xmb-rcd-x06.cisco.com> <559C394D.5090902@gmail.com> In-Reply-To: <559C394D.5090902@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.131.71.107] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" , "draft-colitti-v6ops-host-addr-availability@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability 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, 07 Jul 2015 21:12:30 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJyaWFuIEUgQ2FycGVudGVyIFttYWls dG86YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tXSANClNlbnQ6IFR1ZXNkYXksIEp1bHkgMDcs IDIwMTUgNDo0MSBQTQ0KVG86IEhlbWFudCBTaW5naCAoc2hlbWFudCk7IEZyZWQgQmFrZXIgKGZy ZWQpOyBBbmRyZXcgWW91cnRjaGVua28NCkNjOiB2Nm9wc0BpZXRmLm9yZzsgZHJhZnQtY29saXR0 aS12Nm9wcy1ob3N0LWFkZHItYXZhaWxhYmlsaXR5QHRvb2xzLmlldGYub3JnDQpTdWJqZWN0OiBS ZTogW3Y2b3BzXSBuZXcgZHJhZnQ6IGRyYWZ0LWNvbGl0dGktdjZvcHMtaG9zdC1hZGRyLWF2YWls YWJpbGl0eQ0KDQo+SXQgZG9lcz8gSSBkb24ndCBzZWUgYW55dGhpbmcgaW4gNDg2MiB0aGF0IHBy ZXZlbnRzIGEgaG9zdCBmcm9tIGdlbmVyYXRpbmcgTiBzZXBhcmF0ZSBJSURzIGFuZCBwZXJmb3Jt aW5nIFNMQUFDIE4gdGltZXMgZm9yIHRoZSBzYW1lIHByZWZpeC4gTm93IHdlIGFyZSBnZXR0aW5n IHJpZCBvZiBNb2RpZmllZCA+RVVJLTY0IGFzIHRoZSBkZWZhdWx0IElJRCwgdGhhdCBiZWNvbWVz IGFuIG9idmlvdXMgdGhpbmcgdG8gZG8uDQoNClJGQzQ4NjIgaGFzIG5vIGd1aWRhbmNlIGZvciB3 aGF0IHNwZWNpZmljIElJRCB0byB1c2UuICBIb3dldmVyLCBSRkM0ODYyIGRvZXMgcmVmZXJlbmNl IFJGQzQyOTEgaW4gdGhlIGNvbnRleHQgb2YgSUlEIGFuZCBSRkM0MjkxIGRvZXMgaW5jbHVkZSB0 aGUgTW9kaWZpZWQgRVVJLTQyIElJRCBmb3JtYXQgd2hpY2ggdXNlcyB0aGUgaG9zdCdzIG1hYy1h ZGRyZXNzLiAgIFRoYW5rcywgRnJlZCwgZm9yIHJlcGx5aW5nIGFzIHdlbGwuICANCg0KSSBhbSBv bmx5IGRpc2N1c3NpbmcgUkZDNDg2MiB3aXRoIGl0cyBNb2RpZmllZCBFVUktNjQgZm9ybWF0IGZv ciBnZW5lcmF0aW5nIGEgZ2xvYmFsIElQdjYgYWRkcmVzcy4gIFRoZSByZWFzb24gaXMgYmVjYXVz ZSBzZWN0aW9uIDcgb2YgdGhlIGNvbGl0dGkgZG9jdW1lbnQsIGluIHRoZSBmaXJzdCBidWxsZXQs IHNwZWFrcyBvZiBSRkM0ODYyLiAgDQoNClN1cmUsIGlmIG9uZSBkZXByZWNhdGVzIHRoZSBNb2Rp ZmllZCBFVUktNjQgZm9ybWF0IGFuZCB1c2VzLCBzYXksIHByaXZhY3kgZXh0ZW5zaW9ucywgdGhl biBvbmUgcHJlZml4IGNhbiBiZSB1c2VkIGJ5IHRoZSBob3N0IHRvIGdlbmVyYXRlIG11bHRpcGxl IElQdjYgZ2xvYmFscy4gDQoNCkhlbWFudA0K From nobody Wed Jul 8 08:02:03 2015 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 603421A0011 for ; Wed, 8 Jul 2015 08:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nozC8nsBZ_Q6 for ; Wed, 8 Jul 2015 08:01:55 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.z120.zixworks.com [199.30.235.120]) (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 7FF981A000D for ; Wed, 8 Jul 2015 08:01:55 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id 1D916103173 for ; Wed, 8 Jul 2015 10:01:54 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id AC4AB1217DA; Wed, 8 Jul 2015 10:01:53 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 8BF722F70BC; Wed, 8 Jul 2015 10:55:09 -0400 (EDT) Received: from pwn401ea100.ent.corp.bcbsm.com (unknown [10.64.80.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by imsva2.bcbsm.com (Postfix) with ESMTP id 7A9472F709B; Wed, 8 Jul 2015 10:55:09 -0400 (EDT) Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA100.ent.corp.bcbsm.com ([::1]) with mapi id 14.01.0438.000; Wed, 8 Jul 2015 11:01:47 -0400 From: "Ackermann, Michael" To: Philip Matthews , v6ops list Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-08.txt Thread-Index: AQHQuDJV+Hpx49dFOEuzsXSTRDyQUZ3POuEAgADYyyA= Date: Wed, 8 Jul 2015 15:01:51 +0000 Deferred-Delivery: Tue, 7 Jul 2015 21:00:00 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0CE24B25@PWN401EA160.ent.corp.bcbsm.com> References: <20150706212506.2640.97532.idtracker@ietfa.amsl.com> <23C53E8B-6029-4782-8567-3A9984D556AC@magma.ca> In-Reply-To: <23C53E8B-6029-4782-8567-3A9984D556AC@magma.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-VPM-MSG-ID: caa4903a-aa49-40bc-94e8-21212d24742c X-VPM-HOST: vmvpm01.z120.zixworks.com X-VPM-GROUP-ID: 9c9b93e6-660a-4bfe-a193-56eb7ffc9bef X-VPM-ENC-REGIME: Plaintext X-VPM-CERT-FLAG: 0 X-VPM-IS-HYBRID: 0 Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-08.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, 08 Jul 2015 15:02:02 -0000 Thanks for the great document that Enterprises considering the serious = deployment of IPv6 will find very valuable. =20 The initial sections are good in pointing out what this document does and = does not address. Also pointing out RFC's where information on areas NOT = addressed can be found.=20 In Section 2.1.1 the reference to RFC1918 addresses seems to suggest this = is the IPv4 equivalent to ULA's. Is this a commonly accepted concept? = =20 In the Chart, under Tunneled, it says private addresses are likely a = better option. Why? A subsequent paragraph says something about these = addresses having limited visibility. Is that the rationale? The = paragraph goes on to describe reasons why PI space is the next best = option, but the discourse seems to suggest it may be the better option. = So I come away unclear of which would be =22Best=22. =20 Is Section 2.2 intended to address end hosts, as well as Routers = (Middleboxes)? Could the answer be different in certain situations? = Also, is option =22a.=22 Dual Stack? Is there a reason this term is = avoided? =20 Section 2.2.2, seems to answer a question I have had. IPAM can/should = ignore Link Local addresses. Is this the intended conclusion? =20 In general, this section has a great deal of useful information regarding = the use of Link-Local-Only addresses. =20 Section 2.4.1, the IGP Choice chart shows 4 Multiple Known Deployments, = but the following paragraph says 3. Other than that, the chart = contains a lot of relevant information and should be a helpful decision = tool. I also thank you for including EIGRP and RIP, which I recall was = difficult and controversial. =20 Thanks again for the effort, content and quality put into this document=21 Mike=20 =20 -----Original Message----- From: v6ops =5Bmailto:v6ops-bounces=40ietf.org=5D On Behalf Of Philip = Matthews Sent: Monday, July 06, 2015 5:39 PM To: v6ops list Subject: Re: =5Bv6ops=5D I-D Action: draft-ietf-v6ops-design-choices-08.txt Folks: Victor and I have just submitted a new revision of the Design Choices = draft. There are two main changes: 1. A new section called =22Addresses=22 that discusses the pros and cons = of using PI vs. PA vs. Private addresses in your IPv6 or dual-stack = network. This addresses some comments we got during the WG Last Call about = using ULAs in certain situations. We consider this a significant addition = to the draft. 2. Added EIGRP to the section on IGP Choice. Some of you will recall the = discussion around this on the mailing list a couple of months ago. Victor and I have plans for more revisions to address other WG comments. = In particular, as you may remember, Victor and I have been gathering hard = data from operators around the IGPs that are actually used in production = networks. Unfortunately, Victor and I both got hit with other stuff in the = last few weeks, so we didn't have time to add this data to the draft, or = make some other planned changes. So consider this still a work-in-progress = with other changes coming. - Philip _______________________________________________ v6ops mailing list v6ops=40ietf.org https://www.ietf.org/mailman/listinfo/v6ops The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From nobody Wed Jul 8 11:17:59 2015 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 DDFFC1A6F29 for ; Wed, 8 Jul 2015 11:17:49 -0700 (PDT) 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 LQpDgRYl7Syi for ; Wed, 8 Jul 2015 11:17:48 -0700 (PDT) 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 F3A601A6F2B for ; Wed, 8 Jul 2015 11:17:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 0257045; Wed, 8 Jul 2015 20:17:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:content-transfer-encoding:date :date:in-reply-to:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=mail; t= 1436379462; bh=PPUE2LbRU82cagg82IJS8ytAdDLAOu4WYqgyMiWhVDA=; b=X 8dCHaBswVxMJvaZIXfNU1gsCpG8OFavUo0AUkQiv5NSDZLAh2J4w5fd9Jkmv5UO7 hwR152y/L4VpAv3xCzQo+jQwLyMHRug4O2ChnU4yDHMJDSIRFyeUrYTQXfbmySu8 FpUh/Li9YEKZhDI/g7p8g+KcOYwv0VE2nh0/y9pb/Y= 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 HcpsfAe5c7Yf; Wed, 8 Jul 2015 20:17:42 +0200 (CEST) Received: from [IPv6:2a00:8640:1::3444:768f:8c07:6fc] (unknown [IPv6:2a00:8640:1:0:3444:768f:8c07:6fc]) by mail.sintact.nl (Postfix) with ESMTPSA id F22D834; Wed, 8 Jul 2015 20:17:41 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann In-Reply-To: Date: Wed, 8 Jul 2015 20:17:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <521C7217-12C3-48D9-897F-B3EC4D2C30EA@steffann.nl> References: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> <9290D0D1-062A-4DE0-A437-9A5F5045ACAC@gmail.com> <39F63B55-977F-4B84-8B55-52E2F0B1A851@cisco.com> To: Erik Kline X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "draft-colitti-v6ops-host-addr-availability@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability 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, 08 Jul 2015 18:17:50 -0000 Hi, > Some of this could also serve as input to motivate a SAVI document > defining a basic logging protocol. >=20 > I still believe that if there where a trivially deployable logging > methodology that captured >=20 > {IP address, timestamp, rfc7039#section-3.2 binding context} >=20 > tuples, or even the full data structure entry described in > rfc6620#section-3.1, then the auditing objectives could be well and > truly met. >=20 > I think this is still one large unmet need. (not necessarily a v6ops > matter, perhaps) I agree. Having such a logging mechanism would take away one of the = arguments against SLAAC, which would be a good thing. Cheers, Sander From nobody Wed Jul 8 11:39:10 2015 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 49E861A700B for ; Wed, 8 Jul 2015 11:39:09 -0700 (PDT) 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 UUQroD3HI7A6 for ; Wed, 8 Jul 2015 11:39:08 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D31071A700A for ; Wed, 8 Jul 2015 11:39:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3081; q=dns/txt; s=iport; t=1436380747; x=1437590347; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Q02jG2qXQK8UlaPdnNu1zZR2zZeybDwaMeUW3IWvcQw=; b=W8ak/MUtts6+7OlCzfiYuFV9gCA1lS36UWFBDSYaJGAOKfFbU1r6X4X0 RTqgXZ29fZuthNSeyoxFYIP8IKEElxkNN70j1pZRxW4PcJvZN4ziDqnYU 8OCO7x6gTRW+BeMID5kxiLW64FwLImdduJLMwWuH40kF3b5PJgEWAZzw7 4=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D9BADZbZ1V/5RdJa1cgxKBNAbFOgKBXDsRAQEBAQEBAYEKhCMBAQEDAXkFCwIBCA4KLjIlAgQOBQ6IGAjODQEBAQEBAQEBAQEBAQEBAQEBAQEBAReLS4UGB4MXgRQBBJQjAYIsgVSHfZhiJoN7b4FHgQQBAQE X-IronPort-AV: E=Sophos;i="5.15,433,1432598400"; d="asc'?scan'208";a="13738891" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-2.cisco.com with ESMTP; 08 Jul 2015 18:39:06 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t68Id6o2019836 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Jul 2015 18:39:06 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.49]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Wed, 8 Jul 2015 13:39:06 -0500 From: "Fred Baker (fred)" To: Erik Kline Thread-Topic: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability Thread-Index: AQHQua1ern+gb4bVAkKw0CKjGdvjkg== Date: Wed, 8 Jul 2015 18:39:06 +0000 Message-ID: <51DCD124-F170-426E-BFB2-D734E89640F0@cisco.com> References: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> <9290D0D1-062A-4DE0-A437-9A5F5045ACAC@gmail.com> <39F63B55-977F-4B84-8B55-52E2F0B1A851@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.123] Content-Type: multipart/signed; boundary="Apple-Mail=_5C28523E-1C96-49B0-BB77-BC7AE21AC6A3"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "draft-colitti-v6ops-host-addr-availability@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability 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, 08 Jul 2015 18:39:09 -0000 --Apple-Mail=_5C28523E-1C96-49B0-BB77-BC7AE21AC6A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jul 6, 2015, at 7:08 PM, Erik Kline wrote: >=20 > Some of this could also serve as input to motivate a SAVI document > defining a basic logging protocol. >=20 > I still believe that if there where a trivially deployable logging > methodology that captured >=20 > {IP address, timestamp, rfc7039#section-3.2 binding context} >=20 > tuples, or even the full data structure entry described in > rfc6620#section-3.1, then the auditing objectives could be well and > truly met. >=20 > I think this is still one large unmet need. (not necessarily a v6ops > matter, perhaps) Operational requirements for such could be a v6ops project, and probably = a quick one. You're correct that a protocol development probably belongs = in a protocol WG. Calling out the binding anchor makes sense, but some = of those (the port on an Ethernet switch to which a host attaches, the = security association between a host and the base station on wireless = links) don't have obvious portable names (if I say that a given security = association is number 27 in the AP's table, that's meaningful to the AP, = but I'm not sure it's meaningful to an operator coming in after the = fact). I find myself wondering whether this might get rolled up with some other = logging operation, such as for stateful NATs. It begins to sound a lot = like a record that associates a set of elements together (a 3-tuple or = 5-tuple for a session with a MAC Address and a port number and a time = stamp, logged only if the source IP address isn't mapped to the MAC = address of interest, perhaps) that is emitted for a reason beyond "it = was seen". Would IPFIX, in some incarnation, address this? I'll let you write that :-) --Apple-Mail=_5C28523E-1C96-49B0-BB77-BC7AE21AC6A3 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 iQIVAwUBVZ1uSEayAOS/EQ8MAQKDEg/8DNXmmAsga5z5ye9/iM6CaqcHpIZUpbvr 5oVpWzeJ9LvjFojTUKI9GWrNWUVoH4BuRmj/9U+aWk7vnd/D5U1gaNKH55UEbyxh cPTmb7+K3nLAXiKRk7WtYYzsSRR9SFYeliGifPI9ybn+O1bYDuqQSDi3GZL5Ip+O QylsGZAn1neByun8fayzVts8oJjrWu5xKiZwIVDwOQhHrUPdl56+aCuvRsOerqoQ OUMNAqBrVXcpUaLENGQ4tEHzkRYnop1h18eyHPLXVrDqrbHhVbWGkEOaf8TLQ3Jt EkFb7+ewsTRSRyLx0SR1ZsGsQuEodOhbRoOyHIMcERPW6n0DxYqrLo7lxGfwc2Fw Kpw+wxkMDWrZGiLKAT48GMmGp/4/ihaZm+5yrdF2tHjBfJ9dEpVPNjjpGsUXo+wz NctTa4gqs7lXtvFh6+iOjIhj0v4E9ug/vvTnlnUcKRpIWYPtBIOV60I23md/HDsZ f6FAx0StGZ+KvXCfrqVGW/Bfgm+x2raHTqvg/MyaZwu0HZjAhHuajdQ+TdhPflV/ jaJgBwSg4JbYZL/euu6t0QApyJPTP2jMx/vezA7hi/rNwR/InCMkk956qrKlkb9W S8SLyAQOHZuSeBHBZEL6ePoeS5rccTRDR1D++EkeSsCmCkjVM6y1VzOGiJAP3nGT tM8+dc57apY= =jYZc -----END PGP SIGNATURE----- --Apple-Mail=_5C28523E-1C96-49B0-BB77-BC7AE21AC6A3-- From nobody Wed Jul 8 12:09:29 2015 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 75E151A8700 for ; Wed, 8 Jul 2015 12:09:27 -0700 (PDT) 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 1zAAmISraEcU for ; Wed, 8 Jul 2015 12:09:25 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB1CB1A86FD for ; Wed, 8 Jul 2015 12:09:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3716; q=dns/txt; s=iport; t=1436382566; x=1437592166; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=cI7jbwS70PRT2zwCiY+/2x76jvFt4c/kwJl8j9vgnJE=; b=DV5pFEg5OBIZi6oTz59LqACCJgWzyLu091RuQLQXraI7BOP8Jv4P1OzC o3ai5RPGO1X18fc/uTM/HZo7UFl7l9zjvpWx3BTctdDA68TPfLbdHgtlT lxdf7wPWl+kMArT0nG78lXVK0HpFUcLHXS1s/tYV25vvO/nGQbaSvgYqM 0=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BcAwBvdJ1V/5FdJa1cgxKBOr1LCYdmAoFcOBQBAQEBAQEBgQqEJAEBBHkQAgEIRjIlAgQOE4ggzhoBAQEBAQEBAQEBAQEBAQEBAQEBAQEXi0uFBgeDF4EUBZE9gmYBgiyBVId9gTuEGI8wg18mggwcgVOCNoEEAQEB X-IronPort-AV: E=Sophos;i="5.15,433,1432598400"; d="asc'?scan'208";a="166790606" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-5.cisco.com with ESMTP; 08 Jul 2015 19:09:25 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t68J9Odm012470 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Jul 2015 19:09:24 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.49]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Wed, 8 Jul 2015 14:09:24 -0500 From: "Fred Baker (fred)" To: "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" Thread-Topic: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast Thread-Index: AQHQubGaJQ06k0kTHEW5THWdn9BT9A== Date: Wed, 8 Jul 2015 19:09:24 +0000 Message-ID: <51672618-A36C-4162-A4E1-7E7D57F6326D@cisco.com> References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> In-Reply-To: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.123] Content-Type: multipart/signed; boundary="Apple-Mail=_2EBA5662-25D3-41E7-9682-7BA15690A5EC"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: v6ops list Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 08 Jul 2015 19:09:27 -0000 --Apple-Mail=_2EBA5662-25D3-41E7-9682-7BA15690A5EC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Lorenzo and Andrew: I'm trying to figure out how to unjam the Prague agenda, and I wonder if = this (very simple) draft can be sorted out on the list before the event. = We already have two supportive comments. I'll note that what you = describe for IPv6 is pretty common in IPv4 today - and I have it in my = head it is common in IPv6 today. What I think you're saying is "please = make it common if it's not". RFC 4861, section 6.2.6, says: In addition to sending periodic, unsolicited advertisements, a router sends advertisements in response to valid solicitations received on an advertising interface. A ROUTER MAY CHOOSE TO UNICAST THE RESPONSE DIRECTLY TO THE SOLICITING HOST'S ADDRESS (if the solicitation's source address is not the unspecified address), but the usual case is to multicast the response to the all-nodes group. In the latter case, the interface's interval timer is reset to a new random value, as if an unsolicited advertisement had just been sent (see Section 6.2.4). emphasis mine. Your draft says, if I may summarize in two sentences, "routers that = don't send unicast RAs in response to an RS cost the network and its = hosts a lot of resources" and "please send RAs unicast unless there is a = good reason not to, such as a periodic RA". Correct? If I were to give you an agenda slot, did I just say everything (modulo = perhaps a supporting graphic) that you would say? Presuming the answer to be "yes", let me propose a short-circuit = process. I would invite immediate discussion - do we agree with this? Is = there an alternative viewpoint we're missing? Are there other cases the = draft should address (it's primarily about mobile, but I would submit it = is relevant to any shared L2 infrastructure, which could describe data = centers and WiFi networks)? BTW, chair hat off, I would suggest that your proposed configuration = knob default to "send unicast", not "send multicast". Take that as you = see fit. I have been wrong before. Given an avalanche of "yes, and let's make it a WG document, but here's = a comment", I'd suggest that - I don't give the authors a meeting slot - We accept this as a working group document - The authors post the updated draft as = draft-ietf-v6ops-solicited-ra-unicast in August - I run a WGLC in September - we ship it --Apple-Mail=_2EBA5662-25D3-41E7-9682-7BA15690A5EC 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 iQIVAwUBVZ11YkayAOS/EQ8MAQKMdA/+PsoeutNpGbJjtDaCGTZoXTpDD1AkEkDJ J+/3Tq1eF9KYQMaqNaUUDZvZnYk4s27OLiTSuRE3nzBQMe4IsfZ6fkSJh5muAnwM kmKBtFyl00OE3a1NfCoGI6xD0OEnX9VhQYPu3jIxtvjYO0vtjcTC+VGf7X/Izw8w Q/Zpi8hCRj0eEJDB1sW2Rl10OSbFfjgsKvTxBX6svSvzZzLygzPnfZbTK7cCLb6h vPwijUcxvMwc2hmwFL0wM4SqUlP3lvzpHsSFG4kmk1PPnY8OoUMxOlzW9Seu5gKT jEa5LDG4PpPB9UWrKaZ5HuJlrU9yNeQCTHQnQL7M/0enXXAQk9GJ8ewj/ogOqf1D M2Gzbi3VKls19tXk1Ejt9KuHXUYO0bHghdtrwlrrMcP3tkc7Nvkczkct4ZVG3az0 rXG5GeS8Hfj+kGlBG3JCQ6T2clGLax8Is92lKtE+1m2bf+tW4/+xPrzcT5A2WQO+ B0JGvXicjI3/RdBShepiC4xRV6qPjy+P60usmcrXm4JZtbJOE5OqkM9GQv4pvInb aOeJbyE0Lx29A/f4Q7PAwlM6xTRKZitIcIT+gGZnRwwANwvdinUtdZICBRcQyTpB xr7EdBDlC+MIY8OpKmIEjd/0CyZOwwVKd40cBqYsHYlRcYQb0+wXbx6MQBLkbqKw ikXiPJ85Y68= =yiYh -----END PGP SIGNATURE----- --Apple-Mail=_2EBA5662-25D3-41E7-9682-7BA15690A5EC-- From nobody Wed Jul 8 16:10:48 2015 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 71E091A19F8 for ; Wed, 8 Jul 2015 16:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0etpVzQhDsB for ; Wed, 8 Jul 2015 16:10:45 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::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 B21C11A0046 for ; Wed, 8 Jul 2015 16:10:45 -0700 (PDT) Received: by iecuq6 with SMTP id uq6so165930866iec.2 for ; Wed, 08 Jul 2015 16:10:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=4S1AvlU9Y4acmsZArj/TVbtzxrCshNnCpqlavnHAkxg=; b=e4zau30r3whIXuKh+3laBZxjBEKIZ/nimuIbAj3/wc6f1JglbeqKRAJ8NoMqATqj8b b3IqdU3oXgsIXQ7A1I0L/3D3bqYmU0Qa9gsRpCOyCaGCQuszm8F3aki7hIfYPL3jKgmi D5IOu+n64xc124AKVs40Ed344jgfn7Mw7QixAm8YraDcoLjvhokp0aOo68t9YVIUczwb YsaU/oE4aJ+qLfQ91NxyA19ekrRbHK93rUNLEHlnHA7GWCtMJ2rQvoWhbA7V/m8azdEW p2FLl8VbJ23CtgF5RQjFK9eU9+c7uy5YxgGqf1vB+FEExJaGFGuJRynz3Sf/sve1QM/o jOng== X-Received: by 10.50.17.104 with SMTP id n8mr8847881igd.21.1436397045118; Wed, 08 Jul 2015 16:10:45 -0700 (PDT) Received: from [192.168.1.135] (dsl-173-206-132-76.tor.primus.ca. [173.206.132.76]) by smtp.gmail.com with ESMTPSA id 76sm2881006iom.12.2015.07.08.16.10.43 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Jul 2015 16:10:44 -0700 (PDT) To: "Fred Baker (fred)" , Erik Kline References: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> <9290D0D1-062A-4DE0-A437-9A5F5045ACAC@gmail.com> <39F63B55-977F-4B84-8B55-52E2F0B1A851@cisco.com> <51DCD124-F170-426E-BFB2-D734E89640F0@cisco.com> From: Tom Taylor Message-ID: <559DADF2.2070202@gmail.com> Date: Wed, 8 Jul 2015 19:10:42 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <51DCD124-F170-426E-BFB2-D734E89640F0@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" , "draft-colitti-v6ops-host-addr-availability@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability 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, 08 Jul 2015 23:10:47 -0000 On 08/07/2015 2:39 PM, Fred Baker (fred) wrote: > >> On Jul 6, 2015, at 7:08 PM, Erik Kline wrote: >> >> Some of this could also serve as input to motivate a SAVI document >> defining a basic logging protocol. >> >> I still believe that if there where a trivially deployable logging >> methodology that captured >> >> {IP address, timestamp, rfc7039#section-3.2 binding context} >> >> tuples, or even the full data structure entry described in >> rfc6620#section-3.1, then the auditing objectives could be well and >> truly met. >> >> I think this is still one large unmet need. (not necessarily a v6ops >> matter, perhaps) > > Operational requirements for such could be a v6ops project, and probably a quick one. You're correct that a protocol development probably belongs in a protocol WG. Calling out the binding anchor makes sense, but some of those (the port on an Ethernet switch to which a host attaches, the security association between a host and the base station on wireless links) don't have obvious portable names (if I say that a given security association is number 27 in the AP's table, that's meaningful to the AP, but I'm not sure it's meaningful to an operator coming in after the fact). > > I find myself wondering whether this might get rolled up with some other logging operation, such as for stateful NATs. It begins to sound a lot like a record that associates a set of elements together (a 3-tuple or 5-tuple for a session with a MAC Address and a port number and a time stamp, logged only if the source IP address isn't mapped to the MAC address of interest, perhaps) that is emitted for a reason beyond "it was seen". > > Would IPFIX, in some incarnation, address this? > > I'll let you write that :-) > > We have both SYSLOG and IPFIX drafts in progress for NATs. They've been held up waiting for the NAT MIB to be finished. (The latter is now in the RFCEd Q.) We could look at adding these logs if you want, subject to your requirements. Tom Taylor > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Jul 8 22:09:31 2015 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 C057C1A901F for ; Wed, 8 Jul 2015 22:09:29 -0700 (PDT) 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, 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 UY4Fpf1JoNwG for ; Wed, 8 Jul 2015 22:09:28 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::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 A6E351A9006 for ; Wed, 8 Jul 2015 22:09:28 -0700 (PDT) Received: by ieru20 with SMTP id u20so26270373ier.0 for ; Wed, 08 Jul 2015 22:09:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=weXtT+2jV/IKKVdSXmE18WlNQAjKOn1PRoJPwKyLraY=; b=s2KitJ6uKUy3qsUqSyDJ7lruejxc9c/lmb52B2F/O/W/kG9kd6tct1rhLnUOuCGjBF nGHdDEc0z3Ro6ECvSSTUgVtPgmGfFqHdgJ9SOGzeDk5gj2DJPSOekw7NA+pfg7tudi/p k/g0SFSei0eIK5G+ToHt8kSPM4Y4e2fewEy30rHtmUS4YYh6E9g3dYoR+JyuPUdj72r2 Brb0xzF0G65e8BqcDuALfkTgIsU+ocVG7130NE9KLn8KavAhwqTkCte79wmQQC5zt/Uo EfaVQ3+byPGsQ30oJo/fuD2VzL+sItf7iZ3L9Qv8zhWgGpYFhCtQctUiuoYIH6ShR5+O Pixg== X-Received: by 10.50.102.68 with SMTP id fm4mr67259319igb.25.1436418568080; Wed, 08 Jul 2015 22:09:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.205.5 with HTTP; Wed, 8 Jul 2015 22:08:58 -0700 (PDT) In-Reply-To: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> From: Mark Smith Date: Thu, 9 Jul 2015 15:08:58 +1000 Message-ID: To: fred@cisco.com Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org, v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 09 Jul 2015 05:09:29 -0000 Hi, I support the adoption of this draft. One thought I have though is that I wonder if just changing solicited RAs from multlicast to unicasts would result in an increase in the number of multicast RSes? It was my understanding that the idea behind multicasting solicited RAs was to also update hosts who were soon going to be issuing multicast RSes, which would then reduce the volume of multicast RSes. If those hosts are now not going to receive the multicast solicited RAs, then they I think they would now be issuing multicast RSes more often where as in the past they wouldn't. As a side note, the radvd RA daemon already supports a UnicastOnly option: -- UnicastOnly on|off Indicates that the interface link type only supports unicast. This will prevent unsolicited advertisements from being sent, and will cause solicited advertisements to be unicast to the soliciting node. This option is necessary for non-broadcast, multiple-access links, such as ISATAP. Default: off -- The issue of increased numbers of multicast RSes would be avoided on e.g., ISATAP networks because hosts using that use static, DHCPv4 or DNS lookups to discover routers instead of multicast RSes. Regards, Mark. On 7 July 2015 at 21:47, wrote: > A new draft has been posted, at http://tools.ietf.org/html/draft-yc-v6ops-solicited-ra-unicast. Please take a look at it and comment. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Jul 8 22:38:48 2015 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 69C961A9093 for ; Wed, 8 Jul 2015 22:38:47 -0700 (PDT) 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 A9tmUjXdhByB for ; Wed, 8 Jul 2015 22:38:46 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3453B1A907A for ; Wed, 8 Jul 2015 22:38:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1648; q=dns/txt; s=iport; t=1436420326; x=1437629926; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=SI8lAHav8IjVF6JZVI3ddm6/1cpicxbeWNGjJc70o2s=; b=kzO3y6G0BWeEz2seAW/I9wkqtujFU6lqAQLMOZwcosU0V0UTiiJdklD8 3wXHiD3wrcfXXaoiRk5eb5kxpiQ7zK9Bn/zAXnZSP9qOPvxMeOPOjs2Ll UDoTitYrjY05G0qDKk+fuBt0G96ANMyiCKzfKMMQqTwBNrF7tEv7wYy0w A=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BdAwDjB55V/5RdJa1bgxKBNAa7FwmHZwKBVjgUAQEBAQEBAYEKhCMBAQEDAXkFCwIBCBguIRElAgQOBQ6ICwMKCMgKDYVTAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tLgk2COQeDF4EUBZQsAYIsgVSGGYFmAZFChyImg3tvgUeBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,437,1432598400"; d="asc'?scan'208";a="13876864" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-3.cisco.com with ESMTP; 09 Jul 2015 05:38:45 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t695cj7t020034 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Jul 2015 05:38:45 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.49]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Thu, 9 Jul 2015 00:38:45 -0500 From: "Fred Baker (fred)" To: Mark Smith Thread-Topic: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast Thread-Index: AQHQugmFi8gF5iKSsEaI0kgNcCQvLg== Date: Thu, 9 Jul 2015 05:38:44 +0000 Message-ID: References: <201507071147.t67Bl13m009348@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-originating-ip: [10.19.64.123] Content-Type: multipart/signed; boundary="Apple-Mail=_9C6C7FF6-0378-477B-A004-5CF85CC7881E"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" , v6ops list Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 09 Jul 2015 05:38:47 -0000 --Apple-Mail=_9C6C7FF6-0378-477B-A004-5CF85CC7881E Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > On Jul 8, 2015, at 10:08 PM, Mark Smith wrote: > > One thought I have though is that I wonder if just changing solicited > RAs from multlicast to unicasts would result in an increase in the > number of multicast RSes? Sounds like you have a tool that you could use to simulate that and find out? --Apple-Mail=_9C6C7FF6-0378-477B-A004-5CF85CC7881E 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 iQIVAwUBVZ4I40ayAOS/EQ8MAQIceBAAjNyn5QI9ASeQI5LjWv4A7P6c8nPSN6Xj Yqg/6wL0AmVc4FHqMgO4TZw/X2VMSmN364ra2JjvDsVu5NioE5M6hCTNtQ+oRTuI 9IxCKzb4+dzZbNGgMTmsgiDVIbuQ9rEO7EGpAA2QLiU6RGuwDEFsgnre49FH1nL3 4B88LfuhvMrbpZ/J+lH/ybP32yKZiN4pb4QxWMupOjeb4ez9mn9JPox9j/Mi9Du4 npF3wgV+uVeLiWKPmREfJeYpl9dXFnsx0OsGGeTd1+iCHzRPFzK5xXYOpQovWTtQ qlPrzHs2TBX7bI8t/c/qncwnt3Gc8IZiwkVpe2H/rOcmss2B5JnNEAfSn9l0yN3H WThzmICZ8ZGLPc4vQkdT11Kpjgr6AHDo9JTPzpAiRuQBhrl4tALYERcgHw1fxqDa aHbo/wsURQ2GgrlJT43KD2jloz4akwAEX3xsPoMxKmUdQqbj+1j9ibbdzSm32gEY 4VbAQc0buRznX9kca8mr2fF/hZeIYCXbf1YRUyNL5ExVMPwzTjRTHRj6Ia4E7iVg PA4hFFzq/qXMjXJAm45aJX0Lo3PV1+DrdDtvMIhaygFAqWFWY6n/49AFR0UTfiS7 OwxfSEpR6J/WO9qui6EeYyhvpLDJ7KP7n7HcTsDk2XfsNRDzmaJing0sIKFn6N/e /ea0wLmW25I= =E7Bk -----END PGP SIGNATURE----- --Apple-Mail=_9C6C7FF6-0378-477B-A004-5CF85CC7881E-- From nobody Wed Jul 8 23:21:23 2015 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 2D1BB1A9176 for ; Wed, 8 Jul 2015 23:21:22 -0700 (PDT) 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, 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 OkMml1jrtwd3 for ; Wed, 8 Jul 2015 23:21:21 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001: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 E3B1E1A916E for ; Wed, 8 Jul 2015 23:21:20 -0700 (PDT) Received: by igcqs7 with SMTP id qs7so73027794igc.0 for ; Wed, 08 Jul 2015 23:21:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=JXNVJBfuydQtY8Gn+0a4Ppb5TefGMubACQXQbzThW3s=; b=la/m+o9lyCXBpeizHCfdv+x6cwmvyhLyuQCgo4YeBVczdxpsoCQLmTR72VHzS93jIO wW4plVokLoTYojm7h1vX3FziLQWz93iqg0EKgcYUdKpRbQ78FEjyIujyE13EezPoI3bF OjzcKTdH4m27BMN3Y0agIAUroKrc76w88SWVpRkz+podHRO9xBVqPaNwJwk+TWyXDaFx 8gE/axZ1vDSY1jU8ZbOBO4hK57T/9uTFDtsRCJtePxPPmyoqUhz5EV5j9JBLFWcA+Ycs FQU/EC/kk8sYso2a4awki9V7yeVpz/jgLtb0xTB/szC0AUoiCaAOp2S8LYvgMxcpT0tH o9Nw== X-Received: by 10.50.18.43 with SMTP id t11mr95627214igd.25.1436422880358; Wed, 08 Jul 2015 23:21:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.205.5 with HTTP; Wed, 8 Jul 2015 23:20:51 -0700 (PDT) In-Reply-To: References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> From: Mark Smith Date: Thu, 9 Jul 2015 16:20:51 +1000 Message-ID: To: "Fred Baker (fred)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" , v6ops list Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 09 Jul 2015 06:21:22 -0000 On 9 July 2015 at 15:38, Fred Baker (fred) wrote: > >> On Jul 8, 2015, at 10:08 PM, Mark Smith wrote: >> >> One thought I have though is that I wonder if just changing solicited >> RAs from multlicast to unicasts would result in an increase in the >> number of multicast RSes? > > Sounds like you have a tool that you could use to simulate that and find out? Ok, I'll set something up. From nobody Thu Jul 9 01:25:37 2015 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 C417F1ACC89; Thu, 9 Jul 2015 01:25:35 -0700 (PDT) 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, 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 mgW-IG7pbkK8; Thu, 9 Jul 2015 01:25:34 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::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 A4DBD1ACAD4; Thu, 9 Jul 2015 01:25:34 -0700 (PDT) Received: by ieru20 with SMTP id u20so28648803ier.0; Thu, 09 Jul 2015 01:25:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=b41fVN5M/2/QFXo+XKBpfSBf/qrn1ZxuRwpaG14gvfU=; b=sSTj7eslQHE7X9M22g0AbDNaWevvxzUpb9kzH52oXhqjhnMv7GB6smINrErdwdCJ8z ZYsxbo6BgLphJSxoLBJrIXMG9TcJSKkJCuSEPbgHkQLhRrqxBfjd9at2xXIa+RxgQTLR wOcg4J05ysNfZIh3r5a6TR65YGPcjFZ+oe7ztTKp3gEV5KM9Pf4aGODinv0qsBVaylSR JFI3JPcIyOJE6MY4akRpQAsu/dJxYQrRDiPROBGuqP0kOQCCwPPHB8oMbNSMVzWqhVOK fp503r7EXS3M20jZdIJv2dqFjgf29iMyGhye+VGx081/a+0h4OHW3Q0GuT331nSBYXRh hVXw== X-Received: by 10.107.136.153 with SMTP id s25mr25735295ioi.65.1436430334099; Thu, 09 Jul 2015 01:25:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.205.5 with HTTP; Thu, 9 Jul 2015 01:25:04 -0700 (PDT) In-Reply-To: <559B5A2C.6090204@gmail.com> References: <20150706212506.2640.97532.idtracker@ietfa.amsl.com> <559B5A2C.6090204@gmail.com> From: Mark Smith Date: Thu, 9 Jul 2015 18:25:04 +1000 Message-ID: To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-v6ops-design-choices@ietf.org, IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-08.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, 09 Jul 2015 08:25:35 -0000 On 7 July 2015 at 14:48, Brian E Carpenter wrote: > Hi, > > I don't understand why you mention RFC 1918 in a document about > IPv6 deployment. > > In the table in 2.1.1, I object strongly to the comment against > private (i.e. ULA) addresses > "Will probably require some sort of NAT on links to the Internet." > > That isn't the architecture. The architecture is that nodes have multiple > addresses, and only use ULAs for internal traffic, and use PA or PI addresses > for Internet traffic. I agree. Unless you're using link-locals only in your network (and that isn't really possible for the edge networks), there is always an address selection process going on between the always present link-locals and the other address or addresses that are available. Perhaps it isn't that common knowledge that link-local addresses are quite valid to be used by/for applications, as per RFC4007, and are normally preferred over all other address types if they're available to the application, excepting the loopback prefix, because link-locals have the second smallest scope (and the smallest scope is preferred). In other words, most IPv6 networks are multi-prefix even if their operators think they aren't because they "only" have a single GUA. This is probably worth more visibly highlighting or emphasising in this draft, because it seems to be something that is commonly forgotten or not completely realised. > We shouldn't be documenting any other usage of > ULAs. We shouldn't be making statements like this: > > "For an enterprise, the use of private address space is > reasonable, but the enterprise will need to use NAT44 and/or > NPT[RFC6296] on links to the Internet." > > We clearly can't pretend that NAT44 isn't widely used, but IMHO it should > be completely out of scope in this document, and NPTv6 is an experimental > RFC that we should never recommend. ULAs should *only* be used in parallel > with PA or PI. That isn't an afterthought; that is the basic intention behind > ULAs. > I've thought that if it is unacceptable for devices inside your network to have global addresses, then your security requirements are probably so stringent that NPTv6 devices, packet filters and stateful firewalls would be too simple to achieve and implement them. Instead, you'd use application layer proxies for specific applications you permit, that act on behalf of and completely or near completely hide the identity of the devices inside your network, and prevent any possible reachability to those devices, inherent in ULA addressing, unless the application layer proxy itself is compromised. If using per-application application layer proxies is considered too onerous or costly, then I think the security measures you'd have in place (e.g., host firewalls, network perimeter firewalls/packet filters) would mean there is less risk to deploying global addresses internally compared to the benefits of having them. Regards, Mark. From nobody Thu Jul 9 11:40:38 2015 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 D61221B2B23 for ; Thu, 9 Jul 2015 11:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImhBTG_BT981 for ; Thu, 9 Jul 2015 11:40:34 -0700 (PDT) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::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 776DC1A1EF5 for ; Thu, 9 Jul 2015 11:40:34 -0700 (PDT) Received: by pdrg1 with SMTP id g1so37806525pdr.2 for ; Thu, 09 Jul 2015 11:40:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=5mADPpBjzWmEafRZNJuh4fDg5I9m9ofOO5mr/uKlP5U=; b=k9gmaCk15iUZTO3d9qHHUtWD9LVbZfMT/GNP/ohetGLZzIt6sa2hw0FCtcncz/1mF3 /5Yeubddb7d0PQEYP/O7KdVPAJQA+qrY7tapfqM80+fz7enmaZdkswDgoLXo0NIGhcRO HAqA13AGq1g4rA3r0cONqq7X4vTYJhNNiCDJfbxsaAcsYARNXs4n6SK3BufkfeRkM5ua gg3xfhq2JmhAFR5kY9K1UM+g2P/2PL6S2tUvd6ZP/TQ7T3q/ias/ArrZzNeVa4pYtYTw QN1lO6p7fyQpjwVrw0Bl3XzbP2xZV2azW2dYRmx1vTGrdBWkn3USGIfrThYVKVwmKKFO BnyA== X-Received: by 10.68.65.34 with SMTP id u2mr34218944pbs.118.1436467234135; Thu, 09 Jul 2015 11:40:34 -0700 (PDT) Received: from [10.16.11.210] ([216.31.219.19]) by smtp.googlemail.com with ESMTPSA id xf2sm6766859pab.25.2015.07.09.11.40.32 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Jul 2015 11:40:33 -0700 (PDT) Message-ID: <559EC01F.2000303@gmail.com> Date: Thu, 09 Jul 2015 11:40:31 -0700 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: fred@cisco.com, v6ops@ietf.org References: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> In-Reply-To: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-colitti-v6ops-host-addr-availability@tools.ietf.org Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability 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, 09 Jul 2015 18:40:36 -0000 Nice draft.. While I agree the (should be obvious to everyone) content of this draft I got few nits: Section 2 mentions on-link prefixes when generating additional addresses. There is no reason why this would not apply to off-link prefixes as well. Section 3 points out ePDG as one case, which would benefit from multiple addresses. It would be useful here to say that this is about IPsec handling/implementation and give a pointer to an appropriate spec (TS24.302 I presume). - Jouni 7/6/2015, 4:47 AM, fred@cisco.com kirjoitti: > A new draft has been posted, at http://tools.ietf.org/html/draft-colitti-v6ops-host-addr-availability. Please take a look at it and comment. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Jul 9 15:00:44 2015 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 5D35D1A1A47 for ; Thu, 9 Jul 2015 15:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 ueN1c2vPIo1t for ; Thu, 9 Jul 2015 15:00:42 -0700 (PDT) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B1101A1A42 for ; Thu, 9 Jul 2015 15:00:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1436479241; x=2300392841; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=JpIrW4VWKlelviJ4x5FHgsN43Oev2rp0XZicttti+HY=; b=KGx85oasapNP1EJ00iLRzvX5zwkCaQ+6u7KA6hEtrEY0cltRCL7YjShNmF0Vb8Oa c8Dc4DLmTHkBBfvOCqMgsGPB1M6Kg1vbZ7c+ee8XqXX8yG8bUI3tmoEd0sXEeYu3 AgTdQjIpJiOqwTRyrE5HrFjzqWGyBCtqznhrs3oF38Z7GWpmQ3u4eZAiZXfxwz33 qghlwvRAjjkMvPvscx8QXGKTcRDk02ALMoaFeNwDxqPXUAbfhCYqN/9WNcCUurhA 3aIDStV8L+MIpN4r0n7in9gmQEpkAd6pYgOrxQ5mqXlXsSw5pRREqNKmE6yB6Al1 P9BUcAF5SAnH2sifPdNdnA==; Received: from relay4.apple.com (relay4.apple.com [17.128.113.87]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 7E.89.12430.90FEE955; Thu, 9 Jul 2015 15:00:41 -0700 (PDT) X-AuditID: 11973e13-f79d56d00000308e-9b-559eef09c33e Received: from koseret (koseret.apple.com [17.151.62.39]) (using TLS with cipher DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id DC.56.11814.90FEE955; Thu, 9 Jul 2015 15:00:41 -0700 (PDT) Received: from da0602a-dhcp109.apple.com (da0602a-dhcp109.apple.com [17.226.23.109]) by koseret.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NR800JXYQH4DU50@koseret.apple.com> for v6ops@ietf.org; Thu, 09 Jul 2015 15:00:41 -0700 (PDT) From: David Schinazi Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Date: Thu, 09 Jul 2015 15:00:40 -0700 Message-id: To: v6ops@ietf.org MIME-version: 1.0 (Mac OS X Mail 9.0 \(3067\)) X-Mailer: Apple Mail (2.3067) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUi2FAYrsv5fl6owY/Pehanj+1ldmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRvO0jawF/aIVu68+Y2xgvCTQxcjJISFgIvGhfyMLhC0mceHe ejYQW0hgL6PE1SuMXYwcYDXN63y7GLmAwp1MEmt6f7FCOOuYJBZPXsQMUsQmoCVxYI0RSC8z kLl+53EmCFtb4sm7C6wgtrCAhsT3E9fAbBYBVYnTz/eA7eUVsJH4PuMTG0S9lcSjziVgvSIC QhI7njUxQdToSXSvmckEcaesxMb7fxlBbpAQuMoqsePse8YJjIKzkOyehWT3LCT9CxiZVzEK 5SZm5uhm5pnqJRYU5KTqJefnbmIEBeV0O+EdjKdXWR1iFOBgVOLh1dg+N1SINbGsuDL3EKM0 B4uSOO+fK/NChQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTAuiD5qtcnyqK3AjmmGF0+yTRSO LH/WpVB+dfPCY0sNPk/7wNWgJpFgP29ZNdfvCCPRkt/BmulfzrWIVFf80ohf9k/nVbb9vl9z kk6/rv7L6Lqfp6o2v/bsFzYuEybWut21+jc2BWQ+SnS+cv1d16YnWzxVkg52ZDlv2a418+5i ibY9DwqDDgcosRRnJBpqMRcVJwIAonaTZisCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphluLIzCtJLcpLzFFi42IRnG6nrsv5fl6owYQtOhanj+1ldmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRvO0jawF/aIVu68+Y2xgvCTQxcjBISFgItG8zreLkRPIFJO4 cG89WxcjF4eQQCeTxJreX6wQzjomicWTFzGDNLAJaEkcWGME0sAMZK7feZwJwtaWePLuAiuI LSygIfH9xDUwm0VAVeL08z0sIDavgI3E9xmf2CDqrSQedS4B6xUREJLY8ayJCaJGT6J7zUwm iINkJTbe/8s4gZFvFpJ1s5Csm4WkZQEj8ypGgaLUnMRKE73EgoKcVL3k/NxNjKAwaigM38H4 b5nVIUYBDkYlHl6N7XNDhVgTy4orcw8xSnAwK4nwpr6eFyrEm5JYWZValB9fVJqTWnyIUZqD RUmcV3PKlFAhgfTEktTs1NSC1CKYLBMHp1QDo8jZbS+us31rlb3+P69XJVH2ea9WYu/8+433 P9gd432/niuF+8ObaR3yjz8LHdpyaQ/r4+dPQpIcVOqCetImrdxw/tnRR3rH1ThSVSVsFXa3 tFd9l9hcVmWw9t4fA8f9e878Kd3j+yDx1PUaV5WqIs3p+5s1uTsv1lg3vozo+nogMs9Ms6lS T4mlOCPRUIu5qDgRAGvTa74fAgAA Archived-At: Cc: Paul Saab Subject: [v6ops] Apple and IPv6 - Happy Eyeballs 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, 09 Jul 2015 22:00:43 -0000 Hi everyone, Today Apple released the first public seeds of iOS 9 and OS X El = Capitan. These seeds (and the third developer seeds released yesterday) include = an improved version of Happy Eyeballs. Based on our testing, this makes our Happy Eyeballs implementation go = from roughly 50/50 IPv4/IPv6 in iOS 8 and Yosemite to ~99% IPv6 in iOS 9 and El Capitan betas. While our previous implementation from four years ago was designed to = select the connection with lowest latency no matter what, we agree that the Internet has changed since then and = reports indicate that biasing towards IPv6 is now beneficial for our customers: IPv6 is now mainstream instead of being an = exception, there are less broken IPv6 tunnels, IPv4 carrier-grade NATs are increasing in numbers, and throughput may = even be better on average over IPv6. The updated implementation performs the following: - Query the DNS resolver for A and AAAA. If the DNS records are not in the cache, the requests are sent back = to back on the wire, AAAA first. - If the first reply we get is AAAA, we send out the v6 SYN immediately - If the first reply we get is A and we're expecting a AAAA, we start a = 25ms timer - If the timer fires, we send out the v4 SYN - If we get the AAAA during that 25ms window, we move on to address = selection - When we have a list of IP addresses (either from the DNS cache or by = receiving them close together with v4 before v6), we perform our own address selection algorithm to sort them. This = algorithm uses historical RTT data to prefer addresses that have lower latency - but has a 25ms leeway: if the historical = RTT of two compared address are within 25ms of each other, we use RFC3484 to pick the best one. - Once the list is sorted, we send out the SYN for the first address and = start timers based on average and variance of the historical TCP RTT. Roughly speaking, we start the second address = around the same time we send out a SYN retransmission for the first address. - The first address to reply with a SYN-ACK wins the race, we then = cancel the other TCP connection attempts. If this behavior proves successful during the beta period, you should = expect more IPv6 traffic from Apple products in the future. Note however that this only describes the current beta and all these = details are subject to change. Please test this out if you have the means to, we'd love to see test = results and receive feedback! I would like to personally thank Jason Fesler and Paul Saab for their = help investigating these issues and testing this. Thanks, David Schinazi CoreOS Networking Engineer= From nobody Fri Jul 10 00:38:10 2015 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 55F821A8927 for ; Fri, 10 Jul 2015 00:38:10 -0700 (PDT) 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 zZ0E2lc0QqdE for ; Fri, 10 Jul 2015 00:38:09 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::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 0E1A91A8925 for ; Fri, 10 Jul 2015 00:38:08 -0700 (PDT) Received: by wgjx7 with SMTP id x7so241854990wgj.2 for ; Fri, 10 Jul 2015 00:38:07 -0700 (PDT) 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=Fum2jmKhPjzSFUnH9pDHmHYTkQrb+Mu4fAxHE0w+tZc=; b=nGjSw3GAyXddCpYRef6tV5wUVtPtuER6XIZ/yNR2So7PYuYUR9CiBJcnCK+/kzd6Vg 1sGCXwQfD9zO8RZ4wfNRd12CvJO1SdqHKDedomHnz99uUOvQbx1IjMmBy95f2QFGA73I sPohrYrELhFkh4mrXbGZayY+ZkWGxiYl09H24dRw7I343IlRlJsy93sWZ47JAxXBmg+P Rp1t+p66bQi4PHTNTU/NFjyuPVwjJvS0OLfbd2SRPvenfQktDizS7HZB0559MVpQpiIn MogF3Tjb0t0pqA7lk0jyKpHzueyJDtSyxdR2vgc5J/toWn3zWenP9qnZnZLiGzVZPthk avJw== 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=Fum2jmKhPjzSFUnH9pDHmHYTkQrb+Mu4fAxHE0w+tZc=; b=ewDMWhNvH+fiKl4Yhbc5dL1Rq0vyeKy6lHcttmXe8iqcQV7XcBKwMKIZlbSbW3jhGM RTIMJ1o8KO9nfp63IP59To0QBacVIzrzKcZRRJmSBYzXbKmL07thopFjGnGBBsBL2xkf Vraj/P7JmaW6sfP8nai64SgObkBczuIqaSb3zZK9eQ4DKrlPOfvM6YUmX4SPdMjEzHs5 sKm3VOyHK3tHRgiL46NNZ1iM9H6fTZZ3NYwKzEBoStY5hX3uRH8fiEHolDyO31NZvmy7 W6VTq18CdhnKQO+x1sfUxnpaJfvg5huT3d0UJ2cQxbeuNBOmosPaB67/ow6VZrwFR/uT M++A== X-Gm-Message-State: ALoCoQlzi6mMTrvIsFEz2HYd9S42nTfxU0oJe5jIQkJ9DWxn2ehp7W3KXhyAjeiSR3z+1LshxyPK X-Received: by 10.180.76.193 with SMTP id m1mr3566611wiw.11.1436513887463; Fri, 10 Jul 2015 00:38:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.138.203 with HTTP; Fri, 10 Jul 2015 00:37:47 -0700 (PDT) In-Reply-To: <559DADF2.2070202@gmail.com> References: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> <9290D0D1-062A-4DE0-A437-9A5F5045ACAC@gmail.com> <39F63B55-977F-4B84-8B55-52E2F0B1A851@cisco.com> <51DCD124-F170-426E-BFB2-D734E89640F0@cisco.com> <559DADF2.2070202@gmail.com> From: Erik Kline Date: Fri, 10 Jul 2015 16:37:47 +0900 Message-ID: To: Tom Taylor Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" , "draft-colitti-v6ops-host-addr-availability@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability 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, 10 Jul 2015 07:38:10 -0000 On 9 July 2015 at 08:10, Tom Taylor wrote: > On 08/07/2015 2:39 PM, Fred Baker (fred) wrote: >> >> >>> On Jul 6, 2015, at 7:08 PM, Erik Kline wrote: >>> >>> Some of this could also serve as input to motivate a SAVI document >>> defining a basic logging protocol. >>> >>> I still believe that if there where a trivially deployable logging >>> methodology that captured >>> >>> {IP address, timestamp, rfc7039#section-3.2 binding context} >>> >>> tuples, or even the full data structure entry described in >>> rfc6620#section-3.1, then the auditing objectives could be well and >>> truly met. >>> >>> I think this is still one large unmet need. (not necessarily a v6ops >>> matter, perhaps) >> >> >> Operational requirements for such could be a v6ops project, and probably a >> quick one. You're correct that a protocol development probably belongs in a >> protocol WG. Calling out the binding anchor makes sense, but some of those >> (the port on an Ethernet switch to which a host attaches, the security >> association between a host and the base station on wireless links) don't >> have obvious portable names (if I say that a given security association is >> number 27 in the AP's table, that's meaningful to the AP, but I'm not sure >> it's meaningful to an operator coming in after the fact). >> >> I find myself wondering whether this might get rolled up with some other >> logging operation, such as for stateful NATs. It begins to sound a lot like >> a record that associates a set of elements together (a 3-tuple or 5-tuple >> for a session with a MAC Address and a port number and a time stamp, logged >> only if the source IP address isn't mapped to the MAC address of interest, >> perhaps) that is emitted for a reason beyond "it was seen". >> >> Would IPFIX, in some incarnation, address this? >> >> I'll let you write that :-) >> >> > > We have both SYSLOG and IPFIX drafts in progress for NATs. They've been held > up waiting for the NAT MIB to be finished. (The latter is now in the RFCEd > Q.) We could look at adding these logs if you want, subject to your > requirements. Sounds good to me. :-) I think that as long as the format of the binding anchor is extensible and a minimally useful version is readily available that should suffice to get started. I don't know what's normal here: either extensible within an existing type (i.e. adding fields to a mythical 802Dot11BindingAnchor format) or extensible by creating new types (i.e. 802Dot11BindingAnchorWithRfc5841PacketMood). From nobody Fri Jul 10 05:40:03 2015 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 949681A9300 for ; Fri, 10 Jul 2015 05:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.494 X-Spam-Level: * X-Spam-Status: No, score=1.494 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_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 oe9geKF2SMWi for ; Fri, 10 Jul 2015 05:40:00 -0700 (PDT) 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 E484F1A92FC for ; Fri, 10 Jul 2015 05:39:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 6F66545; Fri, 10 Jul 2015 14:39:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:content-transfer-encoding:date :date:in-reply-to:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=mail; t= 1436531994; bh=sfGvDvQ37k3ffrPyrwQ/b2zECmYalUepCP8gh/iIyiE=; b=q Dge7laI4pNjLmjvIqRNxHkk9mAP3+xumfoFdYr8kBxy/dhoNzRSyZ/sqa0SGxoO5 boDoWVmY7JH04wU+FQCDl+dpS6QR59itWxblqQxnxmjAGfhh+0xKyX45Cu0kyzxV OYlW7/yaFnQp0+WLTrMxk8us35RZwqTDRayv89pmQ4= 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 M016RSsN8yBL; Fri, 10 Jul 2015 14:39:54 +0200 (CEST) Received: from [IPv6:2a00:8640:1::1491:7bec:f773:fb31] (unknown [IPv6:2a00:8640:1:0:1491:7bec:f773:fb31]) by mail.sintact.nl (Postfix) with ESMTPSA id 14F4543; Fri, 10 Jul 2015 14:39:53 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann In-Reply-To: Date: Fri, 10 Jul 2015 14:39:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <18856726-137E-4118-B50F-627AA611E891@steffann.nl> References: To: David Schinazi X-Mailer: Apple Mail (2.2102) Archived-At: Cc: Paul Saab , v6ops@ietf.org Subject: Re: [v6ops] Apple and IPv6 - Happy Eyeballs 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, 10 Jul 2015 12:40:01 -0000 Hi David, > Today Apple released the first public seeds of iOS 9 and OS X El = Capitan. > These seeds (and the third developer seeds released yesterday) include = an improved version of Happy Eyeballs. >=20 > Based on our testing, this makes our Happy Eyeballs implementation go = from roughly 50/50 IPv4/IPv6 in iOS 8 and Yosemite to ~99% IPv6 in iOS 9 = and El Capitan betas. Very glad to hear that! > While our previous implementation from four years ago was designed to = select the connection with lowest latency no matter what, we agree that = the Internet has changed since then and reports indicate that biasing = towards IPv6 is now beneficial for our customers: IPv6 is now mainstream = instead of being an exception, there are less broken IPv6 tunnels, IPv4 = carrier-grade NATs are increasing in numbers, and throughput may even be = better on average over IPv6. >=20 > The updated implementation performs the following: > - Query the DNS resolver for A and AAAA. > If the DNS records are not in the cache, the requests are sent back = to back on the wire, AAAA first. > - If the first reply we get is AAAA, we send out the v6 SYN = immediately > - If the first reply we get is A and we're expecting a AAAA, we start = a 25ms timer > - If the timer fires, we send out the v4 SYN > - If we get the AAAA during that 25ms window, we move on to address = selection > - When we have a list of IP addresses (either from the DNS cache or by = receiving them close together with v4 before v6), we perform our own = address selection algorithm to sort them. This algorithm uses historical = RTT data to prefer addresses that have lower latency - but has a 25ms = leeway: if the historical RTT of two compared address are within 25ms of = each other, we use RFC3484 to pick the best one. RFC 3484 or 6724? > - Once the list is sorted, we send out the SYN for the first address = and start timers based on average and variance of the historical TCP = RTT. Roughly speaking, we start the second address around the same time = we send out a SYN retransmission for the first address. > - The first address to reply with a SYN-ACK wins the race, we then = cancel the other TCP connection attempts. That sounds like a reasonable algorithm. Thanks! Sander From nobody Mon Jul 13 00:24:58 2015 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 E0D2E1AD0BC for ; Mon, 13 Jul 2015 00:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 V5M1o4bVT27V for ; Mon, 13 Jul 2015 00:24:55 -0700 (PDT) Received: from mta05.svc.cra.dublin.eircom.net (mta05.svc.cra.dublin.eircom.net [159.134.118.221]) by ietfa.amsl.com (Postfix) with SMTP id D1D1C1A1BBC for ; Mon, 13 Jul 2015 00:24:54 -0700 (PDT) Received: (qmail 28072 messnum 16653419 invoked from network[213.94.190.14/avas02.vendorsvc.cra.dublin.eircom.net]); 13 Jul 2015 07:24:53 -0000 Received: from avas02.vendorsvc.cra.dublin.eircom.net (213.94.190.14) by mta05.svc.cra.dublin.eircom.net (qp 28072) with SMTP; 13 Jul 2015 07:24:53 -0000 Received: from [192.168.1.2] ([95.44.35.164]) by avas02.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id rjQp1q00N3YUviP01jQstR; Mon, 13 Jul 2015 08:24:52 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ross Chandler In-Reply-To: <6536E263028723489CCD5B6821D4B21303ECF46F@UK30S005EXS06.EEAD.EEINT.CO.UK> Date: Mon, 13 Jul 2015 08:24:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <226673AF-5978-4CFC-B087-841C0F6AFA2B@eircom.net> References: <1599CF94-9B35-4858-AD52-6FADC8F25671@apple.com> <6536E263028723489CCD5B6821D4B21303ECB135@UK30S005EXS06.EEAD.EEINT.CO.UK> <30B46C6D-5676-4E12-88FE-D6EBFA0D6793@apple.com> <378DC402-7760-4846-8AA5-D3D88339FB30@eircom.net> <6536E263028723489CCD5B6821D4B21303ECF275@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B21303ECF46F@UK30S005EXS06.EEAD.EEINT.CO.UK> To: IPv6 Ops WG , David Schinazi X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Vividh Siddha Subject: Re: [v6ops] Apple and IPv6, a few clarifications 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, 13 Jul 2015 07:24:57 -0000 Hi David, Could you look at supporting this common handset/hotspot APN case with = IPv6 & IPv4 APN protocol on two separate bearers with the latter only = brought up when hotspot is on.=20 Like Nick indicates there are unpalatable business implications that = effectively block iOS deployment with IPv6-only. Until the business = starts asking for IPv6 we need ways of making the transition that are = minimally disruptive.=20 Ross > On 2 Jul 2015, at 08:40, Heatley, Nick wrote: >=20 > I don't know what a mobile operator with a common Internet APN = strategy can do about tethering/hotspot then? > Other than redefining all the business logic that leads to a common = Internet APN. >=20 > (I hope you agree, the ability to services all device types on the = wifi is mandatory - even iOS customers might have laptops of various OS = in their home or business.) > Nick >=20 >=20 > -----Original Message----- > From: David Schinazi [mailto:dschinazi@apple.com]=20 > Sent: 01 July 2015 23:29 > To: Heatley, Nick > Cc: Ross Chandler; Vividh Siddha > Subject: Re: [v6ops] Apple and IPv6, a few clarifications >=20 > Nick, Ross, >=20 > Sorry about the delay. >=20 > As far as I know, this is not currently supported: >=20 >> Does/could iOS allow this? >>=20 >> Handset APN name =3D Hotspot APN name >>=20 >> but with >>=20 >> Handset APN protocol =3D IPv6-only & Hotspot APN protocol =3D = IPv4-only >=20 >=20 > David From nobody Mon Jul 13 00:40:58 2015 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 AA0901AD1A3 for ; Mon, 13 Jul 2015 00:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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 tql4ug5h9BFS for ; Mon, 13 Jul 2015 00:40:55 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.140]) (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 477261AD1A6 for ; Mon, 13 Jul 2015 00:40:54 -0700 (PDT) Received: from [85.158.136.3] by server-4.bemta-5.messagelabs.com id CD/18-19186-58B63A55; Mon, 13 Jul 2015 07:40:53 +0000 X-Env-Sender: nick.heatley@ee.co.uk X-Msg-Ref: server-7.tower-123.messagelabs.com!1436773252!2385840!1 X-Originating-IP: [149.254.241.76] X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15264 invoked from network); 13 Jul 2015 07:40:53 -0000 Received: from unknown (HELO smtpml01.ee.co.uk) (149.254.241.76) by server-7.tower-123.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Jul 2015 07:40:53 -0000 Received: from EEUKWV0941.EEAD.EEINT.CO.UK (Not Verified[10.246.209.218]) by smtpml01.ee.co.uk with MailMarshal (v7, 2, 3, 6978) id ; Mon, 13 Jul 2015 08:40:51 +0100 Received: from UK31S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.27]) by EEUKWV0941.EEAD.EEINT.CO.UK with MailMarshal (v7, 2, 3, 6978) id ; Mon, 13 Jul 2015 08:40:52 +0100 Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK31S005EXS02.EEAD.EEINT.CO.UK ([2002:1ef6:d01b::1ef6:d01b]) with mapi id 14.03.0195.001; Mon, 13 Jul 2015 08:40:52 +0100 From: "Heatley, Nick" To: Ross Chandler , IPv6 Ops WG , "David Schinazi" Thread-Topic: [v6ops] Apple and IPv6, a few clarifications Thread-Index: AQHQqtmCDp4NuF4LXEi+0Lv8nVYebZ27NLQAgAAYrgCAA8tTAIAA6TYAgAbnALCAAEtQgIAAqSMwgBE2JICAABTO4A== Date: Mon, 13 Jul 2015 07:40:51 +0000 Message-ID: <6536E263028723489CCD5B6821D4B21303EE3B61@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <1599CF94-9B35-4858-AD52-6FADC8F25671@apple.com> <6536E263028723489CCD5B6821D4B21303ECB135@UK30S005EXS06.EEAD.EEINT.CO.UK> <30B46C6D-5676-4E12-88FE-D6EBFA0D6793@apple.com> <378DC402-7760-4846-8AA5-D3D88339FB30@eircom.net> <6536E263028723489CCD5B6821D4B21303ECF275@UK30S005EXS06.EEAD.EEINT.CO.UK> <6536E263028723489CCD5B6821D4B21303ECF46F@UK30S005EXS06.EEAD.EEINT.CO.UK> <226673AF-5978-4CFC-B087-841C0F6AFA2B@eircom.net> In-Reply-To: <226673AF-5978-4CFC-B087-841C0F6AFA2B@eircom.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.246.208.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Vividh Siddha Subject: Re: [v6ops] Apple and IPv6, a few clarifications 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, 13 Jul 2015 07:40:56 -0000 Agree. Each market must make tariffing decisions independent of IP protoc= ol choice. -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Ross Chandler Sent: 13 July 2015 08:25 To: IPv6 Ops WG; David Schinazi Cc: Vividh Siddha Subject: Re: [v6ops] Apple and IPv6, a few clarifications Hi David, Could you look at supporting this common handset/hotspot APN case with IP= v6 & IPv4 APN protocol on two separate bearers with the latter only broug= ht up when hotspot is on.=20 Like Nick indicates there are unpalatable business implications that effe= ctively block iOS deployment with IPv6-only. Until the business starts as= king for IPv6 we need ways of making the transition that are minimally di= sruptive.=20 Ross > On 2 Jul 2015, at 08:40, Heatley, Nick wrote: >=20 > I don't know what a mobile operator with a common Internet APN strategy= =20can do about tethering/hotspot then? > Other than redefining all the business logic that leads to a common Int= ernet APN. >=20 > (I hope you agree, the ability to services all device types on the=20 > wifi is mandatory - even iOS customers might have laptops of various=20 > OS in their home or business.) Nick >=20 >=20 > -----Original Message----- > From: David Schinazi [mailto:dschinazi@apple.com] > Sent: 01 July 2015 23:29 > To: Heatley, Nick > Cc: Ross Chandler; Vividh Siddha > Subject: Re: [v6ops] Apple and IPv6, a few clarifications >=20 > Nick, Ross, >=20 > Sorry about the delay. >=20 > As far as I know, this is not currently supported: >=20 >> Does/could iOS allow this? >>=20 >> Handset APN name =3D Hotspot APN name >>=20 >> but with >>=20 >> Handset APN protocol =3D IPv6-only & Hotspot APN protocol =3D IPv4-on= ly >=20 >=20 > David _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops NOTICE AND DISCLAIMER This e-mail (including any attachments) is intended for the above-named p= erson(s). If you are not the intended recipient, notify the sender immed= iately, delete this email from your system and do not disclose or use for= =20any purpose. =20 =20 We may monitor all incoming and outgoing emails in line with current legi= slation. We have taken steps to ensure that this email and attachments ar= e free from any virus, but it remains your responsibility to ensure that = viruses do not adversely affect you.=20 EE Limited Registered in England and Wales Company Registered Number: 02382161 Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfor= dshire, AL10 9BW. From nobody Mon Jul 13 06:04:44 2015 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 069521B2A6B for ; Mon, 13 Jul 2015 06:04:43 -0700 (PDT) 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 bdgd1fvhMbOl for ; Mon, 13 Jul 2015 06:04:41 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44C661B2A69 for ; Mon, 13 Jul 2015 06:04:41 -0700 (PDT) Received: from [192.168.178.14] (5356AFE1.cm-6-7c.dynamic.ziggo.nl [83.86.175.225]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id t6DD3NCn000717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 13 Jul 2015 15:03:24 +0200 (CEST) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Iljitsch van Beijnum In-Reply-To: <90744458-CA06-4347-A96B-D649800855D3@muada.com> Date: Mon, 13 Jul 2015 15:04:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1F573B83-6D87-468B-8436-3167DC82D287@muada.com> References: <90744458-CA06-4347-A96B-D649800855D3@muada.com> To: "v6ops@ietf.org WG" X-Mailer: Apple Mail (2.2098) Archived-At: Subject: Re: [v6ops] Happy eyeballs suggestions, was: Re: Apple and IPv6, a few clarifications 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, 13 Jul 2015 13:04:43 -0000 On 22 Jun 2015, at 16:33, Iljitsch van Beijnum = wrote: > About the test DNS64/NAT64 implementation: > Obviously the test network isn't a "real" NAT64 test network when = there's no native IPv6 present. And obviously there's no easy way to = have native IPv6 materialize out of thin air. But someone who wants to = test more thoroughly may want to get native IPv6 or set up a tunnel = broker tunnel. It would be nice if the test NAT64 setup could work with = that, so the devices on the test network can connect to IPv6 = destinations over IPv6 and IPv4 destinations through the NAT64. > Basically, what's needed for this is that if the interface in question = is configured with "real" IPv6 addresses, those are kept and the prefix = in question is advertised in RAs. See here for a workaround, although I can't seem to figure out these = disappearing default routes: = http://www.muada.com/2015/07-13-taking-apples-nat64-implementation-for-a-s= pin.html From nobody Wed Jul 15 08:07:18 2015 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 4A4DD1ACD4F for ; Wed, 15 Jul 2015 08:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRYhT4DNhPeB for ; Wed, 15 Jul 2015 08:07:15 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6C401ACD3D for ; Wed, 15 Jul 2015 08:07:14 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6FF7CS1019490 for ; Wed, 15 Jul 2015 17:07:12 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 733FE203876 for ; Wed, 15 Jul 2015 17:10:38 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 6B3DA203859 for ; Wed, 15 Jul 2015 17:10:38 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6FF7ABV029729 for ; Wed, 15 Jul 2015 17:07:12 +0200 To: v6ops@ietf.org References: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> <9290D0D1-062A-4DE0-A437-9A5F5045ACAC@gmail.com> <39F63B55-977F-4B84-8B55-52E2F0B1A851@cisco.com> From: Alexandru Petrescu Message-ID: <55A6771E.30805@gmail.com> Date: Wed, 15 Jul 2015 17:07:10 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <39F63B55-977F-4B84-8B55-52E2F0B1A851@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability 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, 15 Jul 2015 15:07:17 -0000 Le 07/07/2015 02:02, Fred Baker (fred) a écrit : > Thanks. One question. Chair hat off. > > Section 2 identifies the current deployment model - each interface > has a link-local address, a SLAAC address, and one or more temporary > addresses. I haven't heard anyone complaining about that. Section 3 > goes on to discuss virtual machines/containers, which might each have > additional addresses, and the model Facebook is reportedly using, > which gives individual addresses to processes. It also mentions > draft-herbert-nvo3-ila, which is not a stupid model - I still have > some comments on it in a multi-administration environment or for > running applications in an "inside" and an "outside" address ("NAT > has well-known drawbacks"), but it at least gets rid of the random > encapsulations predominant in data centers today. > > In other words, we already assign multiple addresses, by some means, > to each interface in a network. > > You mention SLAAC. Lorenzo mentions that in section 7. He also > mentions DHCP address and prefix allocation. > > The statement that I don't see in the document, which would help me > personally, is a problem statement. I would guess that the problem > statement is "we think some networks are limiting host interfaces to > a single IPv6 address." I'd want a little more detail, but I'll bet > that's the crux of it. > > So my question is: "precisely what problem are we solving here?". One problem I see is when operators deliver a single global /64 prefix, and that /64 is understood as a single IPv6 global address. Forming multiple IPv6 addresses out of a single /64 is possible for multiple apps running on that device, so that may not be a problem. There may be some privacy concerns though, in that an attacker can identify there is a single device there (the /64 is unique). But 'sharing' these IPv6 addresses with some other devices (64share) has more serious drawbacks, typically in the number of subnets - only one subnet is possible. (to that, one should add an explanation of why operators deliver a single /64 to a device - accounting) Alex > >> On Jul 6, 2015, at 2:39 PM, Andrew Yourtchenko >> wrote: >> >> I read the draft and absolutely agree with the spirit. >> >> Unfortunately, I think it won't work: >> >> As soon as the devices work "good enough" with a single address, >> appealing to increase the amount of work by administrators in the >> name of humanity is going to fall on deaf ears. >> >> The only way I see to solve this is to always use SLAAC on the >> devices: either 'externally' from the prefix received within the >> RA, or 'internally' from within the prefix received via DHCP-PD, >> and provide a mandatory registration mechanism for name-to-IP >> mapping. >> >> If neither of the above works, as a backup effort the device can >> try getting N addresses via DHCP IA_NA and release those that it >> does not need immediately - and displaying a big yellow warning >> "This network may restrict IPv6 functionality and eat your >> kittens, contact your system administrator". Because ND is not >> going to happen on these 'extra' addresses, forwarding wise there >> will be no impact, just some more DHCP traffic after attachment >> (the "limited functionality" of course would need just one address >> and can start immediately). >> >> Those who want tracking can track the upper 64bits or use IA_NA >> and filter out the addresses that are shortly lived. >> >> Of course to avoid being a religious crusade such an effort need >> to produce something pragmatic - namely, a userland cross-platform >> API that would allow getting new addresses on demand by application >> and if needs to - implementing custom transport protocols on top >> of those on a per-app-per-address basis. >> >> The above conjecture however is even less realistic than politely >> asking the inconveniences away, so the logical conclusion from >> that is I fully support this draft. >> >> --a >> >>> On 06 Jul 2015, at 13:47, fred@cisco.com wrote: >>> >>> A new draft has been posted, at >>> http://tools.ietf.org/html/draft-colitti-v6ops-host-addr-availability. >>> >>> >>> >>> Please take a look at it and comment. >>> >>> _______________________________________________ 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 Jul 15 13:58:09 2015 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 6A0E61B2C2B for ; Wed, 15 Jul 2015 13:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id caoQkGhrDf4S for ; Wed, 15 Jul 2015 13:58:04 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003: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 8ECC91B2C2A for ; Wed, 15 Jul 2015 13:58:04 -0700 (PDT) Received: by oihq81 with SMTP id q81so37284074oih.2 for ; Wed, 15 Jul 2015 13:58:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=UE3mzrC4zkJZvw7z3yvmMewG6Zjte2ixx4owbgGlC+c=; b=wkwcJLkeqmShkg9z1+o5OvEjTyygofTQJZsJ7GVhhcHU4kMLahn7siIwt2tkK92BzA vlpaGV8J+eiGwMJHx+924682kHCU3Xi5AeBmQU8lCm9GAoX0pAHf7KPOOoCXehPsH3eZ KliK5jrlJ8pb/St1dW4A6kTRkqlroGW4mqpcY/oeIHGvud9pwug1FBy4YjOgyGK3FXLs xk6sMY4lpkHShYBl/tqikB1yVI2sctYaiNJuO61wNCCcCZAK7Kz0meNFBtAY4c/TdT+f 9zuOmqp96VNHVxhwhjNIXXM8vOOqrPB5Vsr415X0XigTaq85xMC4pHmUGFsyWWsHZ+Dn fGtg== X-Received: by 10.60.136.131 with SMTP id qa3mr5392838oeb.34.1436993884035; Wed, 15 Jul 2015 13:58:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.16.70 with HTTP; Wed, 15 Jul 2015 13:57:24 -0700 (PDT) In-Reply-To: <55A6771E.30805@gmail.com> References: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> <9290D0D1-062A-4DE0-A437-9A5F5045ACAC@gmail.com> <39F63B55-977F-4B84-8B55-52E2F0B1A851@cisco.com> <55A6771E.30805@gmail.com> From: "Mukom Akong T." Date: Wed, 15 Jul 2015 21:57:24 +0100 Message-ID: To: IPv6 Operations Content-Type: multipart/alternative; boundary=047d7b414f2a00c42e051af036ee Archived-At: Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability 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, 15 Jul 2015 20:58:08 -0000 --047d7b414f2a00c42e051af036ee Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable When you read the entire draft, it makes sense and I'd go with the spirit. And I agree with Fred that the problem statement needs to be more succinct. Question to Authors: For addresses that belong to the same interface, is there a requirement for them to belong to different prefixes? If not, then for any address gotten from DHCPv6 IA_NA, perhaps a SLAAC address (or many) can be generated from that prefix. You=E2=80=99d already = get similar behaviour if you used DHCPv6 and configured an IP address from the same DHCPv6 scope (but in exclude list) statically on the interface towards the hosts (assuming the default behaviour of some platforms to send our PIOs in RAs for any addresses manually configured on them). On 15 July 2015 at 16:07, Alexandru Petrescu wrote: > > > Le 07/07/2015 02:02, Fred Baker (fred) a =C3=A9crit : > >> Thanks. One question. Chair hat off. >> >> Section 2 identifies the current deployment model - each interface >> has a link-local address, a SLAAC address, and one or more temporary >> addresses. I haven't heard anyone complaining about that. Section 3 >> goes on to discuss virtual machines/containers, which might each have >> additional addresses, and the model Facebook is reportedly using, >> which gives individual addresses to processes. It also mentions >> draft-herbert-nvo3-ila, which is not a stupid model - I still have >> some comments on it in a multi-administration environment or for >> running applications in an "inside" and an "outside" address ("NAT >> has well-known drawbacks"), but it at least gets rid of the random >> encapsulations predominant in data centers today. >> >> In other words, we already assign multiple addresses, by some means, >> to each interface in a network. >> >> You mention SLAAC. Lorenzo mentions that in section 7. He also >> mentions DHCP address and prefix allocation. >> >> The statement that I don't see in the document, which would help me >> personally, is a problem statement. I would guess that the problem >> statement is "we think some networks are limiting host interfaces to >> a single IPv6 address." I'd want a little more detail, but I'll bet >> that's the crux of it. >> >> So my question is: "precisely what problem are we solving here?". >> > > One problem I see is when operators deliver a single global /64 prefix, > and that /64 is understood as a single IPv6 global address. > > Forming multiple IPv6 addresses out of a single /64 is possible for > multiple apps running on that device, so that may not be a problem. > There may be some privacy concerns though, in that an attacker can > identify there is a single device there (the /64 is unique). > > But 'sharing' these IPv6 addresses with some other devices (64share) has > more serious drawbacks, typically in the number of subnets - only one > subnet is possible. > > (to that, one should add an explanation of why operators deliver a > single /64 to a device - accounting) > > Alex > > > > > >> On Jul 6, 2015, at 2:39 PM, Andrew Yourtchenko >>> wrote: >>> >>> I read the draft and absolutely agree with the spirit. >>> >>> Unfortunately, I think it won't work: >>> >>> As soon as the devices work "good enough" with a single address, >>> appealing to increase the amount of work by administrators in the >>> name of humanity is going to fall on deaf ears. >>> >>> The only way I see to solve this is to always use SLAAC on the >>> devices: either 'externally' from the prefix received within the >>> RA, or 'internally' from within the prefix received via DHCP-PD, >>> and provide a mandatory registration mechanism for name-to-IP >>> mapping. >>> >>> If neither of the above works, as a backup effort the device can >>> try getting N addresses via DHCP IA_NA and release those that it >>> does not need immediately - and displaying a big yellow warning >>> "This network may restrict IPv6 functionality and eat your >>> kittens, contact your system administrator". Because ND is not >>> going to happen on these 'extra' addresses, forwarding wise there >>> will be no impact, just some more DHCP traffic after attachment >>> (the "limited functionality" of course would need just one address >>> and can start immediately). >>> >>> Those who want tracking can track the upper 64bits or use IA_NA >>> and filter out the addresses that are shortly lived. >>> >>> Of course to avoid being a religious crusade such an effort need >>> to produce something pragmatic - namely, a userland cross-platform >>> API that would allow getting new addresses on demand by application >>> and if needs to - implementing custom transport protocols on top >>> of those on a per-app-per-address basis. >>> >>> The above conjecture however is even less realistic than politely >>> asking the inconveniences away, so the logical conclusion from >>> that is I fully support this draft. >>> >>> --a >>> >>> On 06 Jul 2015, at 13:47, fred@cisco.com wrote: >>>> >>>> A new draft has been posted, at >>>> http://tools.ietf.org/html/draft-colitti-v6ops-host-addr-availability. >>>> >>>> >>>> >>>> >>>> Please take a look at it and comment. > >> >>>> _______________________________________________ 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 > --=20 Mukom Akong T. http://about.me/perfexcellence | twitter: @perfexcellent ---------------------------------------------------------------------------= --------------------------------------------------------------- =E2=80=9CWhen you work, you are the FLUTE through whose lungs the whisperin= g of the hours turns to MUSIC" - Kahlil Gibran ---------------------------------------------------------------------------= ---------------------------------------------------------------- --047d7b414f2a00c42e051af036ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
When you read the entire draft, it makes sense and I'd= go with the spirit. And I agree with Fred that the problem statement needs= to be more succinct.=C2=A0


Question to A= uthors: =C2=A0For addresses that belong to the same interface, is there a r= equirement for them to belong to different prefixes?=C2=A0

If not, then for any address gotten from DHCPv6 IA_NA, perhaps a S= LAAC address (or many) can be generated from that prefix. You=E2=80=99d alr= eady get similar behaviour if you used DHCPv6 and configured an IP address = from the same DHCPv6 scope (but in exclude list) statically on the interfac= e towards the hosts (assuming the default behaviour of some platforms to se= nd our PIOs in RAs for any addresses manually configured on them).

On 15 July= 2015 at 16:07, Alexandru Petrescu <alexandru.petrescu@gmail.co= m> wrote:
=

Le 07/07/2015 02:02, Fred Baker (fred) a =C3=A9crit :
Thanks. One question. Chair hat off.

Section 2 identifies the current deployment model - each interface
has a link-local address, a SLAAC address, and one or more temporary
addresses. I haven't heard anyone complaining about that. Section 3
goes on to discuss virtual machines/containers, which might each have
additional addresses, and the model Facebook is reportedly using,
which gives individual addresses to processes. It also mentions
draft-herbert-nvo3-ila, which is not a stupid model - I still have
some comments on it in a multi-administration environment or for
running applications in an "inside" and an "outside" ad= dress ("NAT
has well-known drawbacks"), but it at least gets rid of the random
encapsulations predominant in data centers today.

In other words, we already assign multiple addresses, by some means,
to each interface in a network.

You mention SLAAC. Lorenzo mentions that in section 7. He also
mentions DHCP address and prefix allocation.

The statement that I don't see in the document, which would help me
personally, is a problem statement. I would guess that the problem
statement is "we think some networks are limiting host interfaces to a single IPv6 address." I'd want a little more detail, but I'l= l bet
that's the crux of it.

So my question is: "precisely what problem are we solving here?".=

One problem I see is when operators deliver a single global /64 prefix,
and that /64 is understood as a single IPv6 global address.

Forming multiple IPv6 addresses out of a single /64 is possible for
multiple apps running on that device, so that may not be a problem.
There may be some privacy concerns though, in that an attacker can
identify there is a single device there (the /64 is unique).

But 'sharing' these IPv6 addresses with some other devices (64share= ) has
more serious drawbacks, typically in the number of subnets - only one
subnet is possible.

(to that, one should add an explanation of why operators deliver a
single /64 to a device - accounting)

Alex





On Jul 6, 2015, at 2:39 PM, Andrew Yourtchenko
<ayourtch@gmail.= com> wrote:

I read the draft and absolutely agree with the spirit.

Unfortunately, I think it won't work:

As soon as the devices work "good enough" with a single address,<= br> appealing to increase the amount of work by administrators in the
name of humanity is going to fall on deaf ears.

The only way I see to solve this is to always use SLAAC on the
devices: either 'externally' from the prefix received within the RA, or 'internally' from within the prefix received via DHCP-PD, and provide a mandatory registration mechanism for name-to-IP
mapping.

If neither of the above works, as a backup effort the device can
try getting N addresses via DHCP IA_NA and release those that it
does not need immediately - and displaying a big yellow warning
"This network may restrict IPv6 functionality and eat your
kittens, contact your system administrator". Because ND is not
going to happen on these 'extra' addresses, forwarding wise there will be no impact, just some more DHCP traffic after attachment
(the "limited functionality" of course would need just one addres= s
and can start immediately).

Those who want tracking can track the upper 64bits or use IA_NA
and filter out the addresses that are shortly lived.

Of course to avoid being a religious crusade such an effort need
to produce something pragmatic - namely, a userland cross-platform
API that would allow getting new addresses on demand by application
and if needs to - implementing custom transport protocols on top
of those on a per-app-per-address basis.

The above conjecture however is even less realistic than politely
asking the inconveniences away, so the logical conclusion from
that is I fully support this draft.

--a

On 06 Jul 2015, at 13:47, fred@cisco.com wrote:

A new draft has been posted, at
http://tools.ietf.org/html/draf= t-colitti-v6ops-host-addr-availability.




Please take a look at it and comment.

_______________________________________________ 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



--
=

Mukom Akong T.

http://about.me/perfexcellence | =C2=A0twitter: @perfexcellent
-------------------------------= ---------------------------------------------------------------------------= --------------------------------
=E2=80=9CWhen you work, you are the FLU= TE through whose lungs the whispering of the hours turns to MUSIC" - K= ahlil Gibran
-----------------------------------------------------------= ---------------------------------------------------------------------------= -----
--047d7b414f2a00c42e051af036ee-- From nobody Wed Jul 15 14:50:45 2015 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 2C5691B2D45 for ; Wed, 15 Jul 2015 14:50:44 -0700 (PDT) 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 NqnIrJIogYQd for ; Wed, 15 Jul 2015 14:50:42 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F6A11B2D44 for ; Wed, 15 Jul 2015 14:50:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2418; q=dns/txt; s=iport; t=1436997042; x=1438206642; h=from:to:cc:subject:date:message-id:mime-version; bh=zfUhrC63rNpVhT8M081H0AohRJZHzclFHI20DitGl7E=; b=GI91wwj550J3y9NLxpJrYKXE0mMjeFX1+hvuTHT47KICegYpgM5OmW/Y XhW8Sn4Pc/Gjs9oDTZhSoLlXMHc8XRep0sIC0OnZFBdj27nyIdNpn1Kht L0ndrA9QD2U0Nr8lL7kSvxDFfeAXdSZ40ruax3SGBlLXiPuG8IK6qwHly 8=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AqAwAv1aZV/5BdJa1agxNUb7ssCYF2hXeBQjgUAQEBAQEBAYEKhCYEeRIBgQAnBA4TiCAN0DkBAQEBAQEBAQEBAQEBAQEBAQEBAQETBJBSgx6BFAWUPQGCMIFUiAmBQIQYkx4mg3yCNoEEAQEB X-IronPort-AV: E=Sophos;i="5.15,483,1432598400"; d="asc'?scan'208";a="15771035" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-1.cisco.com with ESMTP; 15 Jul 2015 21:50:41 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t6FLof28027782 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Jul 2015 21:50:41 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.49]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Wed, 15 Jul 2015 16:50:41 -0500 From: "Fred Baker (fred)" To: v6ops list Thread-Topic: Final v6ops agenda Thread-Index: AQHQv0hKbZ/IhQbyS0iGgt+tLUfDNg== Date: Wed, 15 Jul 2015 21:50:40 +0000 Message-ID: <645EB110-7CBD-41DC-9BEE-BD4EEA7BB955@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.61.168.50] Content-Type: multipart/signed; boundary="Apple-Mail=_365B41D4-0A29-40A7-9967-077519C93A7D"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: [v6ops] Final v6ops agenda 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, 15 Jul 2015 21:50:44 -0000 --Apple-Mail=_365B41D4-0A29-40A7-9967-077519C93A7D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii at least until we bash it... https://www.ietf.org/proceedings/93/agenda/agenda-93-v6ops On this agenda, I have listed: sunset4: draft-ietf-sunset4-gapanalysis draft-ietf-sunset4-nat64-port-allocation v6ops old business: draft-ietf-v6ops-design-choices draft-ietf-v6ops-siit-dc draft-ietf-v6ops-siit-dc-2xlat v6ops new drafts: draft-yc-v6ops-solicited-ra-unicast draft-vyncke-v6ops-ipv6-only-thin-clients draft-colitti-v6ops-host-addr-availability draft-bao-v6ops-rfc6145bis We also have talks from Apple and OTE, and a charter discussion. The authors of the three v6ops working group documents each tell me that = they may not use their whole slot. If that happens, I'll move topics = from the Friday agenda to the Tuesday agenda in real time. So, folks, = please be prepared. Slots are about 20 minutes in length, and the chairs = would prefer that a significant subset of that be discussion from the = floor. I need any and all slides, ppt, pptx, or pdf, by Saturday evening = please, so I can post them. --Apple-Mail=_365B41D4-0A29-40A7-9967-077519C93A7D 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 iQIVAwUBVabVrkayAOS/EQ8MAQL2+w/+Poj82Md2OeZOEj1QEZvybOdC8IZAE9ZH aRJyHFVROVVZ60PuYgPKWkTNm4/mpWDACbyBjd6v4AOL7w+NwJyUyZvHOJSuGi0N niHMuVJkWgbigAiaocAGdWSdqOsOSowR24LrNdk/IuKZNBHv3oOv4+8ZFYejS9Oy 7QDuFCwiTaqlYnADBaHamwkr4v9fy/Oa7ecpCVdRSALn/kdMURJ1xsgHaakDplg1 KTxioaeBkaMdB8y1v7WKnxw3P6U3HFdSSSCq22AE86G/GvYudV+jR3Tzh5/EZpI2 ADsanzlWO6GvFKTNuDzAtS7BFkeAGPycDIK3OhtjbPtzJcytVbKKV6O3EoW0Jgl+ Fi1RyK5y/sYd+Byfoi1sIsQoflSPQ1D+Qjg8ybYfL0yxoEeEKZOM1gZg4VEWAUQv pitKRPV1yocx+joT+WkZu7ewaDVIjaWRwesbIlnle0sCcMZ5BQn8qNRS69Qf+aN6 RlhZr9BuN+zKMqhnKis6iLP6gdyqhythhPoz0y9ki7y1vBaxg0JUw8cEl//yV4FX cu++24CxorXr+iEYqECmKAjuofR5McWV0L0OtbN1GXfiY34WVM+ZvsITGfKco7rL Kna1mqUK8NYGC9GFjNh7FRIsGuL0Ba8WkoW6m9O0v8ucmyzeE8tRLrMEUDtv23qB H5Yl94kSys4= =Ip6u -----END PGP SIGNATURE----- --Apple-Mail=_365B41D4-0A29-40A7-9967-077519C93A7D-- From nobody Thu Jul 16 01:16:11 2015 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 252681B3755 for ; Thu, 16 Jul 2015 01:16:07 -0700 (PDT) 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, 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 N2-EVhIydvrX for ; Thu, 16 Jul 2015 01:16:05 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::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 67D241B3754 for ; Thu, 16 Jul 2015 01:16:05 -0700 (PDT) Received: by igvi1 with SMTP id i1so7989975igv.1 for ; Thu, 16 Jul 2015 01:16:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=nkBuhq+FezYuxAcpgRwGRiGu1/aHrQJNjs9QjC32HcA=; b=y5iya7wAKkMj2n/ArE3q6dXjuSo9hpYL89OFLX7Qbx94rJUt2F0T2JKtcWZLUkkWS7 sFsZhy/YZ992/4aPJPTPWdDls3JeFZWbsMl4uNu7cZi1YzT7Awlloa/+OhW2umVFQg5f wcMSZWPBWe5B4wIUs7pA4ka4hUmQmeldXvByvVK+aCuWtQZZkQ6sjrmKHiQR51KTrIa5 EFeh2+aJnxZMpw6mM0ZFCZKO1wiLQ7uSIlfF2u2ocPkHdW1ny/CwfCeuxlEv7NHPGfgZ gSCKcJNxYKr+PW9O2HGTYEFIlGkPGHWXBdBEi8kuVRiYcI7B+s3xFWY8WlpDWyENACnT Zpzw== X-Received: by 10.107.10.96 with SMTP id u93mr9381715ioi.172.1437034564851; Thu, 16 Jul 2015 01:16:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.205.5 with HTTP; Thu, 16 Jul 2015 01:15:35 -0700 (PDT) In-Reply-To: References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> From: Mark Smith Date: Thu, 16 Jul 2015 18:15:35 +1000 Message-ID: To: "Fred Baker (fred)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" , v6ops list Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 16 Jul 2015 08:16:07 -0000 Hi, On 9 July 2015 at 15:38, Fred Baker (fred) wrote: > >> On Jul 8, 2015, at 10:08 PM, Mark Smith wrote: >> >> One thought I have though is that I wonder if just changing solicited >> RAs from multlicast to unicasts would result in an increase in the >> number of multicast RSes? > > Sounds like you have a tool that you could use to simulate that and find out? So thought about this a bit more, and realised that my thinking wasn't quite right. Hosts don't issue periodic multicast RSes, such that receiving a solicited multicast RA a short period before a periodic multicast RS would have been sent would suppress the multicast RS. Periodic unsolicited multicast RAs keep hosts' knowledge of default routers fresh, so hosts would only issue a multicast RS when they need to discover routers "now" i.e., when an interface comes up. I think this means that unicasting solicited RAs on certain link types would usefully reduce multicasts. It does raise the question as to why solicited RAs were multicast in the first place. The only other benefit I can see of mulicasting solicited RAs is that it would keep all of the receiving hosts' default router knowledge more accurate and the aging of the default router information more synchronised across all nodes over the periodic unsolicited multicast RAs. I'm not sure if it would matter if the loss of this increased default router accuracy and aging synchronisation would matter if solicited RAs were unicast instead of being multicast. Out of interest, I also captured RSes and RAs on my home Wifi LAN (all hosts were variants of Linux), and also looked up some Windows boot packet captures I have. Here's what I found and some thoughts. o RSes with a :: source address Windows XP sends some early RSes with a source address of the unspecified address. These RSes didn't have the Source Link-Layer Address Option (because :: shouldn't be added to the neighbor cache). This is permitted by RFC4861. It later sends RSes using a link-local source address, now containing the Source Link-Layer Address Option. Later versions of Windows didn't issue RSes with :: source addresses i.e., they waited until they had a link-local address to use (and included the Source Link-Layer Address Option). It isn't possible to use the :: address as a destination address for the solicited RA per RFC4291, so it seems the only choice for the IPv6 destination address is FF02::1. However, if the link-layer header source address of the RS is available to the RA process, then it could link-layer unicast the multicast RA, as per RFC6085, "Address Mapping of IPv6 Multicast Packets on Ethernet". I think it is necessary to describe how to handle these :: source address RSes in this draft, as they're valid and could appear on a "solicited unicast RA only" link. o RSes with a link-local source addresses, but no Source Link-Layer Address Option Some of my Linux hosts issued RSes with a link-local source address, but without the Source Link-Layer Address Option. This also seems permitted by RFC4861. These hosts were Fedora 22 hosts, using the user space Network manager package to perform/handle RS/RA processing in user space, verses other hosts (Android, Chrome OS) which are probably using the Linux kernel's RS/RA facilities. I dug into the Network manager code and found that it was using the libndp.org NDP library, and was using a single call that builds a generic RS without the SLLA option. RFC4861 is pretty clear about what to do when there is an SLLA option in an RS - create or update a neighbor cache entry for the RS source address with the SLLA option value, and set it to STALE. However, I don't find the text about when there is no SLLA option that clear: "If there is no existing Neighbor Cache entry and no Source Link-Layer Address option was present in the solicitation, the router may respond with either a multicast or a unicast router advertisement. Whether or not a Source Link-Layer Address option is provided, if a Neighbor Cache entry for the solicitation's sender exists (or is created) the entry's IsRouter flag MUST be set to FALSE." It seems to be strongly implying that a neighbor cache entry could be created even if there is no SLLA option, because it says it is possible to respond with a unicast RA. However, to be able to use the RS's source IPv6 address to unicast the RA, I think a NS/NA transaction would need to occur first for the RS's source address, before the unicast RA is sent. The implementation could use the link-layer source address from the frame the RS arrived in to send a link-layer unicast solicited unicast RA (i.e., don't use the neighbor cache to resolve the link-layer destination address, use the RS frame's source address). In that case, I think the frame's link-layer source address should only be used for this unicast solicited RA. An entry in the neighbor cache would be created for the RS's source address, and then an NS/NA transaction to verify its reachability independent of sending the RA. Alternatively, the method of link-layer unicasting a multicast solicited RA could be used, although there is probably more broader value in the triggering an NS/NA transaction method. o At least one common IPv6 RA implementation isn't rate limiting sending solicited RAs This is for the current version of OpenWRT, sending way more than one RA per 3 seconds if I solicit them quickly. So it may be worth observing in the ID that RA rate limits may not have been implemented, and unicasting RAs in that case will have the benefit of avoiding sending these RAs to nodes that didn't solicit them. 17:14:47.312209 IP6 fe80::dc61:ccff:fexx:xxxx > ff02::2: ICMP6, router solicitation, length 8 17:14:47.313398 IP6 fe80::dc61:ccff:fexx:xxxx > ff02::2: ICMP6, router solicitation, length 8 17:14:47.314363 IP6 fe80::dc61:ccff:fexx:xxxx > ff02::2: ICMP6, router solicitation, length 8 17:14:47.315563 IP6 fe80::dc61:ccff:fexx:xxxx > ff02::2: ICMP6, router solicitation, length 8 17:14:47.316739 IP6 fe80::dc61:ccff:fexx:xxxx > ff02::2: ICMP6, router solicitation, length 8 17:14:47.529880 IP6 fe80::224e:7fff:fexx:xxxx > ff02::1: ICMP6, router advertisement, length 192 17:14:47.533531 IP6 fe80::224e:7fff:fexx:xxxx > ff02::1: ICMP6, router advertisement, length 192 17:14:47.536100 IP6 fe80::224e:7fff:fexx:xxxx > ff02::1: ICMP6, router advertisement, length 192 17:14:47.538672 IP6 fe80::224e:7fff:fexx:xxxx > ff02::1: ICMP6, router advertisement, length 192 17:14:47.541194 IP6 fe80::224e:7fff:fexx:xxxx > ff02::1: ICMP6, router advertisement, length 192 Regards, Mark. From nobody Thu Jul 16 01:16:38 2015 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 30D601B3760 for ; Thu, 16 Jul 2015 01:16:36 -0700 (PDT) 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 17wLYtSw6Ai8 for ; Thu, 16 Jul 2015 01:16:35 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 049531B375F for ; Thu, 16 Jul 2015 01:16:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1392; q=dns/txt; s=iport; t=1437034595; x=1438244195; h=from:to:subject:date:message-id:mime-version; bh=adqNAVNLiySbZMm98nNytPMJIIaMbGKhMuRbfjx94OY=; b=FRqmIxmbqnk7C2Tfv0BPfYpBqxaeq/l3nWSYhervEUEhsMliC9GvTwFN O2zOvwfuUYgDg1xg2ilNJEHBMf8e/MEDHYlht7iatQ9fBY3fi+nL5Ycom WG7mRw51r0+YJ8UQ7u1a+IUBKnu27aeSqbSuyOuR6wyd+HgQTX+PnV/9X U=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A+AwBcZ6dV/5hdJa1agxOBQ7s8CYkwOBQBAQEBAQEBgQqEKoELAYEAJwQhiCCpQ6YHAQEBAQEFAQEBAQEBAQEak3CBFAWURgGCMYFUiBKBQ4QZkyMmg3yCNoEEAQEB X-IronPort-AV: E=Sophos;i="5.15,486,1432598400"; d="asc'?scan'208";a="169117669" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-6.cisco.com with ESMTP; 16 Jul 2015 08:16:34 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t6G8GYOo017280 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 16 Jul 2015 08:16:34 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.49]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Thu, 16 Jul 2015 03:16:34 -0500 From: "Fred Baker (fred)" To: v6ops list Thread-Topic: Needed for Tuesday and Friday v6ops meetings Thread-Index: AQHQv5+6XZmeVrWWrEuKBrAUIppmJA== Date: Thu, 16 Jul 2015 08:16:33 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.61.170.27] Content-Type: multipart/signed; boundary="Apple-Mail=_045750BA-9A2F-4680-86A3-BEFA15B01441"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: [v6ops] Needed for Tuesday and Friday v6ops meetings 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, 16 Jul 2015 08:16:36 -0000 --Apple-Mail=_045750BA-9A2F-4680-86A3-BEFA15B01441 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Need one or more note-takers, and a jabber scribe, for each session, please. --Apple-Mail=_045750BA-9A2F-4680-86A3-BEFA15B01441 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 iQIVAwUBVadoX0ayAOS/EQ8MAQIANw/9Gkcvkeou6GB8iR2m7ZN9UhsNw/D2lfu2 8SQ2fAIg9S9XCvkNYori4kNQctj35NVmSFl6bk7ZJnzbsLGSR1wOge9x8gUy1zAP geeDU8TgevxCA/vSR9AuFzY9LZ5OdMCc1YnqSwOZZfXJObSdTHKa1Ovft/JwJmRM VuR41RB3rMB0rOS2CGLL0m9V9VhjQfKvwxxfJE6JFtHVI2juPIPk+lReu/rIyJ1D iYZjSw9KCLdGV+OoQ/YQv6S/xag6Al2O6zdJ6RFNZ8Pky+1VwseBLDElFNs7tmnP Jpsk3nyed8KoVYt/Wpift+aVQp8rnZg3pCCWixYbTHI/PFVWU7iKyWkgf79lRGMY B6AIqtHoa73w696YkFk4SU5rBlVyY7i0zgrRx/JWFZubkZy6cOgj+Tb08qnrCfhs 7JrJCWi7rY+qxury+kEwAjxRSaONiw5NYy+V/Mw/VLuo2qacbz7XbZ57OM+ANccI DbouUzzAdqyfKu7BlyseZIDCxJ7Mnf2hecPo+NBkAz3kWG3GyVxHp0iOctpyY8nr Y18aCJ9EWnFyY/hdrBBRYymUKkqx1ZkxMqcrZLf9bcBIFM5UIQPjo6tZLvSCVuAv moEk3Qwx8m947GJVYTnQwgFtQBilyCJoEQeUFzcTINY+fCiODsXlNYdKDJkRnyAl cd8ERwwPsWw= =FQ4U -----END PGP SIGNATURE----- --Apple-Mail=_045750BA-9A2F-4680-86A3-BEFA15B01441-- From nobody Thu Jul 16 01:23:55 2015 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 69E5E1B376D for ; Thu, 16 Jul 2015 01:23:54 -0700 (PDT) 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 YDM5LZtaL9wo for ; Thu, 16 Jul 2015 01:23:53 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCAB81B3769 for ; Thu, 16 Jul 2015 01:23:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1753; q=dns/txt; s=iport; t=1437035032; x=1438244632; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Uo31aI7voBiouxQv17X28QyT2Rmm2rr2svI+AGT/8dc=; b=lnd/yfFUCxz/pXkn19FWVnVfRSMTieFSHW1X8V1oeTZrlzA2OhOInNis v2oeisvrqe+mZ6TSMfwKFulyRF5H9hnU+xa8+9Fh/zXWcJ34Dx2Rib+MA 7RXQy1u3omcBFehtPmxidBtBK9Vw0vGSSbqwHBEVcLUzKJsXrsPhNXs2j E=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A4AwDwaadV/5JdJa1agxOBPQa7PAmHbQKBQTgUAQEBAQEBAYEKhCMBAQEDAXkFCwIBCBguIRElAgQOBQ6ICwMKCMl/DYVAAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tMgk2COQeDF4EUBZFSgnQBgjGBVIYsgWaBQ5AVg0aDYSaDfG+BR4EEAQEB X-IronPort-AV: E=Sophos;i="5.15,486,1432598400"; d="asc'?scan'208";a="169070798" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-3.cisco.com with ESMTP; 16 Jul 2015 08:23:30 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t6G8NUtp026274 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Jul 2015 08:23:30 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.49]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Thu, 16 Jul 2015 03:23:29 -0500 From: "Fred Baker (fred)" To: Mark Smith Thread-Topic: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast Thread-Index: AQHQv6Cxre0/wvxW/kiE3lGfJ3uvtw== Date: Thu, 16 Jul 2015 08:23:29 +0000 Message-ID: <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> References: <201507071147.t67Bl13m009348@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-originating-ip: [10.61.170.27] Content-Type: multipart/signed; boundary="Apple-Mail=_9B812086-C68B-4BA6-8F53-5C930762AC5C"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" , v6ops list Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 16 Jul 2015 08:23:54 -0000 --Apple-Mail=_9B812086-C68B-4BA6-8F53-5C930762AC5C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jul 16, 2015, at 10:15 AM, Mark Smith = wrote: >=20 > I think this means that unicasting solicited RAs on certain link types > would usefully reduce multicasts. It does raise the question as to why > solicited RAs were multicast in the first place. Not sure. RFC 826, which is the obvious predecessor, calls for the = response to an ARP request to be unicast. Thanks for your note. --Apple-Mail=_9B812086-C68B-4BA6-8F53-5C930762AC5C 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 iQIVAwUBVadp/kayAOS/EQ8MAQIf+Q//fJr4PkiN874gjH0YjGaRqkhqCQWEP1WH 9Niyo92PL5vFRUbrWbXrKt1Y4j86ZrAYHePYhYE/Dt8loErFiPUpya1RrT5C3qIg tgnTr35rQ1Vjs0CVzYLf/+zJ6vEIQTP4v2yeME/eqfsdzkkcSA1++Ap6owV3ig5n 7iquuIjUn6noAZRrqMN4Hab3T5s/SjHnlmwU56TU/2ue+F/SlfDr9KYWA1TJROHa D4rFyakMiOpNm/b41Tg9+0ijNvMyf1NFXtkTk8jgvfeJj3zhyVuqNTrjdjEsDhJB 8y6EIeI2Sn65F9vBa9jUy6BExHBnIrYIxWJaCqPh1oGz+J/FnlsTWnYNd6PtSNdF mQXu3Hd3E2EnC1PbzxXxdQjBpqQiUc1M4JiDbuF5tfIFQ16S2mmTYfMeVKwuVGGo 1b0F/edRGhuYkVuZSgM4ps93ZjBvPhq8FL9yWGbfTnefs2shxEwJXNnYIEBDI+TN iTEr3TpliMdJGWSPSOeteHX5RF1xh0qmP4R3jIUPqkpo6voUpdTHXeeRJNAeJX2C gNIgdn5czTylQgpFEgJfgGu5Ex0qVfzpUsZ3t6F6qpSU5Lp2ld9xJtOXs5Oc6yGG uiXD+DFhPjf5x9moike2f/N+b9G3j4IbY5SgrjRA+WXWNqCzj4lmZqkEwExXYvXk HxwQWJQ8zvA= =ztpW -----END PGP SIGNATURE----- --Apple-Mail=_9B812086-C68B-4BA6-8F53-5C930762AC5C-- From nobody Thu Jul 16 02:01:11 2015 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 3CC491A0372 for ; Thu, 16 Jul 2015 02:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, 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 9mRjZL5soAXW for ; Thu, 16 Jul 2015 02:01:07 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FE0D1A0367 for ; Thu, 16 Jul 2015 02:01:07 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id EBFFA625B; Thu, 16 Jul 2015 02:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=5cqDi7l49MXLuQulYxs2gjXNxog=; b= ZeS45A+TK/53SYmtFjPfUkktVwLbJLXIovBmt+GkdvEZOpPNidVIoN73rKBun/y9 vlAoA6tVOWMOVSPoePphp3Yeo870NMx/+uwtXXO/WyOOPcNXCQ4T7sJPhwK8Dhq5 qPwTR7x5Fmt1CeAhDzXf1XjyUgSef3QVjRJkpeZm8gQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=SOVfq0mkW1qaiKdUhWmh4hlF07 OaPbTqS6vA6RS2XLaVpyeauHUoYl51lOcZyvrkPwGmS3yfc0QS7hbDv2mLzo4dU4 2Ag1KBujAqZNjkrpU2PZ3ADOlstUYMWDp/kU1saDTqLUsyu9ISt+ttdzV3jsF9+t Y9pwSicA+8ol/Vnmc= Received: from gomlefisk.localdomain (unknown [173.38.220.41]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id B62F261CE; Thu, 16 Jul 2015 02:01:05 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by gomlefisk.localdomain (Postfix) with ESMTP id 566A64927D08; Thu, 16 Jul 2015 11:01:03 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Content-Type: multipart/signed; boundary="Apple-Mail=_36108C5F-A718-41DA-80A9-D87DD59641D3"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5 From: Ole Troan In-Reply-To: <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> Date: Thu, 16 Jul 2015 11:01:02 +0200 Message-Id: <2D55FD9C-6DE5-4C50-8E75-74CF66E07AAF@employees.org> References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> To: "Fred Baker (fred)" X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" , v6ops list Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 16 Jul 2015 09:01:09 -0000 --Apple-Mail=_36108C5F-A718-41DA-80A9-D87DD59641D3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> I think this means that unicasting solicited RAs on certain link = types >> would usefully reduce multicasts. It does raise the question as to = why >> solicited RAs were multicast in the first place. >=20 > Not sure. RFC 826, which is the obvious predecessor, calls for the = response to an ARP request to be unicast. I believe it was thought of as an optimisation. cheers, Ole --Apple-Mail=_36108C5F-A718-41DA-80A9-D87DD59641D3 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 - https://gpgtools.org iQIcBAEBCgAGBQJVp3LPAAoJEL7aWKiYQt92mQkP/R8sqeV/v4kPIVgEwE9UJ0us EMe1mIvXINvZPqN+z8gTmNXkzV5bHcJqEnZbft7U+VoSP5lKgbq1xtoJQJyJRBdR usAhZiK5DKzMNZBDbuPcMQkhHBkFxzVRRHsG7vvgIwJ11VwSrdHCO90MZBwLcUEY kqelMVoueqoErGNeU/fJac3rjdu1WQzMjvQ8SDDqay99r+TmybO0spQ82x4C4Z1P V4IgQxdOV1l3NYcUrPyzhZrq926OJbruPFYtNGyWyV3ADIhZzz/wwSqGENTvIFC3 +2JdhTlZUS9GFJWr4Sa0HcWilPzE8Gwg1LvatjSuaadPG2W0qZzCGzu6JREQR4tq ORIasJVN4KNJ/n4q3/XTHCBpnxarLAjBrEIjRZa1O9imgLIPwEwMu56VmzJ6Nfct MMA0vY3SpTRR9YokM+oc5Kmdx1AidPEFZCvf3pCW7aJ7gKoPAQv01MNoXa6Q1KI6 hGHPuJnRdW5rCzhxyXU1dZAPi4X4Yx+uCflq2tuVScY95nQrcKLuv03Vt4ekbrLR pWvvFaokpauNdpq7jFUnUzMl322EmoI8YOjrizS3/F3AbwsqYETVjBfhlwz0WIUS dHY3sJ/qwKjzgqhf3u6LBpdIOBUpK8sZ7gWvDRbk+1ncMCpT4XNygFvNSwJIuo2D weGmhtr3UeFmcyG9Qx0h =/Vue -----END PGP SIGNATURE----- --Apple-Mail=_36108C5F-A718-41DA-80A9-D87DD59641D3-- From nobody Thu Jul 16 02:19:21 2015 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 7CF401A8716 for ; Thu, 16 Jul 2015 02:19:20 -0700 (PDT) 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, 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 K7P-tAyIgivu for ; Thu, 16 Jul 2015 02:19:19 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::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 7CFD01A8714 for ; Thu, 16 Jul 2015 02:19:19 -0700 (PDT) Received: by ietj16 with SMTP id j16so51755635iet.0 for ; Thu, 16 Jul 2015 02:19:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=BtLRwz+2bLhJt9yrumF0L3DC5V1IyVIBRiJGWVQFVQ0=; b=AkyvKbNKumAON0abPxE2N52ugWur/oUVk2V2hd+v1+uXeeCT/U38ZyLRCs6t/r9s3T YsJm9KmCyqi+bT4G8BCSIsJEh0QJBePShC7HRyJmn7Q9MtiunzYjbNaR9BuPMwqqzphI 3b1ZFClXADN3FSuJ0fJxMZTgL7irjcXBTt9gOypBuJ5ZpvwbIYxP04P352nIZ6MmTQj6 urkKoalZu7OPeHdzaNqtMItFBt/lo7HSzfcxqJB41M3OWnqiXeVgh/3e7ezdO4FIup0y icpiktZQl/OwSYXY0LKNYszkImoukiX05rTBW5ZUZQnBMsQwkAuSHz15GbtVuyvutNV1 56HQ== X-Received: by 10.50.61.130 with SMTP id p2mr3054335igr.9.1437038358969; Thu, 16 Jul 2015 02:19:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.205.5 with HTTP; Thu, 16 Jul 2015 02:18:49 -0700 (PDT) In-Reply-To: <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> From: Mark Smith Date: Thu, 16 Jul 2015 19:18:49 +1000 Message-ID: To: "Fred Baker (fred)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" , v6ops list Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 16 Jul 2015 09:19:20 -0000 Hi Fred, On 16 July 2015 at 18:23, Fred Baker (fred) wrote: > >> On Jul 16, 2015, at 10:15 AM, Mark Smith wrote: >> >> I think this means that unicasting solicited RAs on certain link types >> would usefully reduce multicasts. It does raise the question as to why >> solicited RAs were multicast in the first place. > > Not sure. RFC 826, which is the obvious predecessor, calls for the response to an ARP request to be unicast. > Now you've mentioned an old RFC, it has reminded me of RC1256, "ICMP Router Discovery Messages", which I came across again fairly recently. It describes RS/RAs for IPv4, and somewhat surprisingly implementations of it seem to be fairly available - Cisco and Juniper call it IRDP, and e.g., my Fedora 22 host has a client for it installed by default ('rdisc'). It says that RAs can be unicast, multicast or broadcast. It seems to give a bit of a clue as to why multicast solicited RAs would be useful: "A unicast response may be delayed, and a multicast response must be delayed, for a small random interval not greater than MAX_RESPONSE_DELAY, in order to prevent synchronization with other responding routers, and to allow multiple, closely-spaced solicitations to be answered with a single multicast advertisement." In 1991, hosts were pretty much mains powered, fixed location and wired, so they could all rush to send multicast RSes after a mains power outage or the 10BASE2 cable broke and was then fixed, and they wouldn't have come and gone much from the link either. A single multicast RA in response to the first RS in a flood of them could have caused a lot of later RSes to be suppressed. > Thanks for your note. No worries. Regards, Mark. From nobody Thu Jul 16 02:50:19 2015 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 B1A8E1A87F1 for ; Thu, 16 Jul 2015 02:50:18 -0700 (PDT) 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, 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 ixDWJFrXdPEi for ; Thu, 16 Jul 2015 02:50:17 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::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 522391A6FF2 for ; Thu, 16 Jul 2015 02:50:17 -0700 (PDT) Received: by ieik3 with SMTP id k3so52439995iei.3 for ; Thu, 16 Jul 2015 02:50:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Zl9JQgnADIm4qOj/R42ug/aQxKg7otFLeCFToM3smDo=; b=EB02r00ndMR5osHInHfwa0dGcc2mJE83mOnIDaSIT9SPb4/Y5S05wfY7O3qpNQ/glB L5yoeNSCPBmjUE97bK+laYqf3tmU5DJPrrMOI+9LwLjZPbhZ8Ce9XxR4iaIZ2txoY3tq jrn5XMUVNnhXlBbnb9OzLlYKeKSP846iyldEb29+Ogct4kD9ATaQl/ZJPYnybEo2AMWt mGX+NIWr4ishdi/ExGrZuw6EVxJpXsCZqyJNh3UhwW4SfbNEPQwPdULt7pZmRao9heA7 zNtmw4r1lrrKYm7cocMGVRJxXTm34aR5TthPWGrwR9yL0DApvXZwiHlKhQPIwMtzoLuP YUBw== X-Received: by 10.50.109.138 with SMTP id hs10mr2958953igb.48.1437040216854; Thu, 16 Jul 2015 02:50:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.205.5 with HTTP; Thu, 16 Jul 2015 02:49:47 -0700 (PDT) In-Reply-To: References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> From: Mark Smith Date: Thu, 16 Jul 2015 19:49:47 +1000 Message-ID: To: "Fred Baker (fred)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" , v6ops list Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 16 Jul 2015 09:50:18 -0000 On 16 July 2015 at 19:18, Mark Smith wrote: > Hi Fred, > > On 16 July 2015 at 18:23, Fred Baker (fred) wrote: >> >>> On Jul 16, 2015, at 10:15 AM, Mark Smith wrote: >>> > > "A unicast response may be delayed, and a multicast > response must be delayed, for a small random interval not greater > than MAX_RESPONSE_DELAY, in order to prevent synchronization with > other responding routers, and to allow multiple, closely-spaced > solicitations to be answered with a single multicast advertisement." > > In 1991, hosts were pretty much mains powered, fixed location and > wired, so they could all rush to send multicast RSes after a mains > power outage or the 10BASE2 cable broke and was then fixed, and they > wouldn't have come and gone much from the link either. A single > multicast RA in response to the first RS in a flood of them could have > caused a lot of later RSes to be suppressed. > So the next logical thing to do would be to have the router default to unicast Router Advertisements, measure the rate of received Router Solicitations, and switch to multicast RA mode past a certain threshold to cover this sort of situation. Once the number of RSes falls, it switches back to unicast RA mode. That would get rid of the configuration knob proposed in this ID, and is behaviour that I think could be universal for all link types, rather than just for the case of wireless ones with mobile devices. From nobody Fri Jul 17 00:34:17 2015 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 9B2121B309C for ; Fri, 17 Jul 2015 00:34:15 -0700 (PDT) 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 n2ri85WAUNsq for ; Fri, 17 Jul 2015 00:34:14 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DC0A1B3084 for ; Fri, 17 Jul 2015 00:34:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2272; q=dns/txt; s=iport; t=1437118454; x=1438328054; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jTiePh3xY11QQ1nnWqYTEkBRlbj3NCA1LQfPKlS2qJo=; b=INgSZUgPxrCB4uZdfpMAwRp8MAMsDte/JgkwjDsLCaNTi3dItCn5KeH8 fwN+kcpvaFOUV9+E6bz4BVbe6tBBE/Om2Xgxwg7+e/SZuANQZq41pCxll O0USwS//zsGf1WAHCAl92O1zseDgZUWMq5vYwmbJ19jUiwXcGwOWh1ZCQ I=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ANBQBRr6hV/5JdJa1agxOBQ7teh2wCgUQ6EgEBAQEBAQGBCoQkAQEDAXkQAgEIRjIlAgQOE4gYCM98AQEBAQEBAQEBAQEBAQEBAQEBARmLTIUGB4MXgRQFlE0BgjKBVIgWmQMmgg0cgVOCNoEEAQEB X-IronPort-AV: E=Sophos;i="5.15,494,1432598400"; d="asc'?scan'208";a="12498919" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-6.cisco.com with ESMTP; 17 Jul 2015 07:34:13 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t6H7YDSc028201 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Jul 2015 07:34:13 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.49]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Fri, 17 Jul 2015 02:34:13 -0500 From: "Fred Baker (fred)" To: Mark Smith Thread-Topic: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast Thread-Index: AQHQwGL6nNDuJQe3hUu/qRAw6bXwVQ== Date: Fri, 17 Jul 2015 07:34:13 +0000 Message-ID: <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.61.71.21] Content-Type: multipart/signed; boundary="Apple-Mail=_193A281E-1488-4601-A1CA-FFD676A2FC7A"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" , v6ops list Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 17 Jul 2015 07:34:15 -0000 --Apple-Mail=_193A281E-1488-4601-A1CA-FFD676A2FC7A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >=20 > So the next logical thing to do would be to have the router default to > unicast Router Advertisements, measure the rate of received Router > Solicitations, and switch to multicast RA mode past a certain > threshold to cover this sort of situation. Once the number of RSes > falls, it switches back to unicast RA mode. >=20 > That would get rid of the configuration knob proposed in this ID, and > is behaviour that I think could be universal for all link types, > rather than just for the case of wireless ones with mobile devices. If it were me implementing it, I think I would go about this in a little = different way, hopefully simpler. I would want to send at most one = (e.g., either zero or one) RA per some interval (a second?). In the = normal case, that is sent unicast. However, having sent a unicast RA at = time t, if I now receive another RS before t+1, I send the next one (at = time t+1) as a multicast. --Apple-Mail=_193A281E-1488-4601-A1CA-FFD676A2FC7A 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 iQIVAwUBVaiv8kayAOS/EQ8MAQLzahAAiPLqkgbOwUOLPxJzXCOk8FRD1Vorf8aa DCQCEmhVL819nEkqeGKX7R5TK7ZbGAqBN03jtQn6ZJBkihXb+8LSB95BK22BqY3p TENCjUd+hnB4haD49DzsuuFopruP67u34V51CipXYLZvIr4767hcoVZkNtDgJhNe eK9AhW/fs4yft7CE4a+sP51+8kmBcZDNbEZvjbf6fyXq5gqmNv1TRltNi+5JoolJ TAJNJvRS6svj4K2sWgEjR+9rQ6FVz8Ib2LvfLVGDHOhMESsT1VZeRtPGrd+LM2YB oOdFASi1SP4MxnQT5TNU41B+bcYIU9UKIVXIBiIj9cJgy1Yd04Za5uP0+Fptxkcx tcxLkMPo8UuHQgRtIbSODWBus1pwwMJrhcx9Cds4uHgLF118oq+TMj1rw34DNDcu tYNHd6HwFYnT/1HkwOBdgL/ua31GzRMOU1PPKku6U+eGESfEe2fmMrbobjhGzymQ eOsHLg04OD1NzOWHaI/R+OeqoIVie5qclSi4s1C//TxogPSn2vEBPjiu4p9KqEMK J4hC2HFjaXAh6PwSqoEax4Tw7jlXbjgrPL/tDgSWbfacHCYN20rKyxGvAFkcgQ1N hykwvsLQrzImhxQ9KpU3aa/64pVlP3BRBvPrCTcbKLWL0E/HT6sTl3mSOFHynJ4l MzpnlKRKJO8= =mJ2J -----END PGP SIGNATURE----- --Apple-Mail=_193A281E-1488-4601-A1CA-FFD676A2FC7A-- From nobody Fri Jul 17 00:59:51 2015 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 AB98E1B3123 for ; Fri, 17 Jul 2015 00:59:50 -0700 (PDT) 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 SJ5oCfP64COa for ; Fri, 17 Jul 2015 00:59:49 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450: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 14C971B3120 for ; Fri, 17 Jul 2015 00:59:49 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so32322246wib.0 for ; Fri, 17 Jul 2015 00:59:47 -0700 (PDT) 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:content-transfer-encoding; bh=V6GFhSOM6VWLqzK7ocS85KnlLvsRAhMtgESgTDcKl+4=; b=RcFRXD0OVKM62v/ihbSxXemKmhnje3DctWCTpeDPJ2s5/+LTRAFVmk/JWUxN/M46mm afXOzvrR+WGlIMDtYadZLiktMoXS5jZfuC9962PCaKyma0vP1oHsnOVw+EOQXRkNCaM9 WGxmZ9vNo5UWBjm/uta61xOkSHmSS7DN5CJnUoOsywYXpL0Zk7bjTA/kPJ37M3+XpbUv fAzgaI8kWTo8mMval8WKze6gH0Mn93+m/8io2YeQ78amLMi18BX65leB5jpS9kNaypua RpXLUNUoC26OVzldqROpogLvEjbd3BT0EwFxauPtg2wMdhXAjOmZFdhU0yexl4IKa/Kz UGBw== 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:content-transfer-encoding; bh=V6GFhSOM6VWLqzK7ocS85KnlLvsRAhMtgESgTDcKl+4=; b=SxzlU+kJOFfOP+SGzh94PrPDqLV20SHPx4UI9UiL6NzQnvehE/N2Q/selqH9vSgUxa SbF8JPMHyND35vu68lSMHeprm5skNqa8nG+Jf7q4qR5bPYfu6ZgcKv190C33Y0mYAsC8 oYd7KDEnjPJWqQ7kOM9lVZ8eSRPjTufSRHdgDLivIQLsf6m1s9sVDPTwe3B/iyKj7nWD w1JENX8er97tnLUXZRDlNfcJ7Kcol58GR5st6zXMXLnPfg4zm3XbArj4yHwI1+jHdSNU gtlw0pya7XxnsaDbdU/fusXZwAaHzxm02kL0FNt/qTipDmduE+sWLQayIRqD7YuWcPPA dKzg== X-Gm-Message-State: ALoCoQlt68+O/xuI+aska+JEskFmvML/QhEfcilRMRhbmcOSz1adPTIwcKTfdfKdqc1PDxPsG5Uk X-Received: by 10.180.86.6 with SMTP id l6mr12779503wiz.91.1437119987806; Fri, 17 Jul 2015 00:59:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.138.203 with HTTP; Fri, 17 Jul 2015 00:59:27 -0700 (PDT) In-Reply-To: <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> From: Erik Kline Date: Fri, 17 Jul 2015 16:59:27 +0900 Message-ID: To: "Fred Baker (fred)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" , v6ops list Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 17 Jul 2015 07:59:50 -0000 On 17 July 2015 at 16:34, Fred Baker (fred) wrote: >> >> So the next logical thing to do would be to have the router default to >> unicast Router Advertisements, measure the rate of received Router >> Solicitations, and switch to multicast RA mode past a certain >> threshold to cover this sort of situation. Once the number of RSes >> falls, it switches back to unicast RA mode. >> >> That would get rid of the configuration knob proposed in this ID, and >> is behaviour that I think could be universal for all link types, >> rather than just for the case of wireless ones with mobile devices. > > If it were me implementing it, I think I would go about this in a little = different way, hopefully simpler. I would want to send at most one (e.g., e= ither zero or one) RA per some interval (a second?). In the normal case, th= at is sent unicast. However, having sent a unicast RA at time t, if I now r= eceive another RS before t+1, I send the next one (at time t+1) as a multic= ast. Like what happened with the Happy Eyeballs draft, I think many strategies will be possible. It may be best to simply document the considerations, along with a baseline recommendation that unicast options of some kind SHOULD be available. I'd leave it at roughly: - multicast RA at least once every max_ra is still a MUST (iirc) - unicast RAs MAY be sent at any time, whether solicited or not - unicast RAs SHOULD be considered for link layers where this helps efficiency The exact strategy for Happy Hosts / Happy Routers (Happy Nodes?) will likely depend on link layers and use cases, some of which have yet to be defined. From nobody Fri Jul 17 09:57:42 2015 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 ED64E1AC3D6 for ; Fri, 17 Jul 2015 09:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLktWUKn_qIy for ; Fri, 17 Jul 2015 09:57:39 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::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 41CF41ABD3F for ; Fri, 17 Jul 2015 09:57:39 -0700 (PDT) Received: by wibud3 with SMTP id ud3so43838985wib.1 for ; Fri, 17 Jul 2015 09:57:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pyQuxi7PHUtES/S1BjjKCeIRky6MyHExb+56fsCe5Y8=; b=OJ2zwxtxQFrAIIXctky67KktNJzeQgR8iPIlFcxBs21Ef30mL3yhW/6Ua8QLA4l7wg Kj9Up9Bi6Y53VEwtSLtdaqcr5HwBHWTxaL0L7XygLUw+T/fCozUDdCVpMw9YlylxkzXn PES5F6xq7XgfntX4SFc/budme9h0s+nTmnYu2rlxZiPCEhRW5ceszMYvT9w/n8AfdydR 1MNTxJ9SJUROganS5TVG38o9ZwJeYkaU7i7ibJuGpcVZWxE5wB4FvQR1eYFxdXgXTLCc 5FeIAC8A9Vj2qH8DtdyfVjiIDaPN9sgu+8MVAyVtm6l1KtCN+zOA757NudoztnSi6h5g tHIg== X-Received: by 10.180.211.10 with SMTP id my10mr18532264wic.41.1437152258012; Fri, 17 Jul 2015 09:57:38 -0700 (PDT) Received: from [10.79.142.123] ([188.188.83.126]) by smtp.gmail.com with ESMTPSA id fo17sm19115420wjc.46.2015.07.17.09.57.35 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 Jul 2015 09:57:36 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Andrew Yourtchenko X-Mailer: iPhone Mail (12H143) In-Reply-To: <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> Date: Fri, 17 Jul 2015 18:57:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <331D6E02-167D-4E7F-9682-F63C6674BD24@gmail.com> References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> To: "Fred Baker (fred)" Archived-At: Cc: "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" , v6ops list Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 17 Jul 2015 16:57:41 -0000 On 17 Jul 2015, at 09:34, Fred Baker (fred) wrote: >>=20 >> So the next logical thing to do would be to have the router default to >> unicast Router Advertisements, measure the rate of received Router >> Solicitations, and switch to multicast RA mode past a certain >> threshold to cover this sort of situation. Once the number of RSes >> falls, it switches back to unicast RA mode. >>=20 >> That would get rid of the configuration knob proposed in this ID, and >> is behaviour that I think could be universal for all link types, >> rather than just for the case of wireless ones with mobile devices. >=20 > If it were me implementing it, I think I would go about this in a little d= ifferent way, hopefully simpler. I would want to send at most one (e.g., eit= her zero or one) RA per some interval (a second?). In the normal case, that i= s sent unicast. However, having sent a unicast RA at time t, if I now receiv= e another RS before t+1, I send the next one (at time t+1) as a multicast. values of T less than 3 seconds would make performance worse than today. There are many things to optimize for: - wireless airtime - bandwidth used by RAs - CPU usage sending unicast RAs by router - energy consumption on devices for more than one medium Some of them are orthogonal, some of them contradict each other, some of the= m align. People may want to optimize differently. I'd opt for simplicity - and use the text Erik Kline posted in another email= . This would allow the developers to adapt for individual use cases on the spo= t. --a > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Jul 17 16:51:39 2015 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 87EB61A903B for ; Fri, 17 Jul 2015 16:51:38 -0700 (PDT) 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, 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 l8HfshdMFeHF for ; Fri, 17 Jul 2015 16:51:37 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::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 28BDB1A87A6 for ; Fri, 17 Jul 2015 16:51:37 -0700 (PDT) Received: by iehx8 with SMTP id x8so6726725ieh.3 for ; Fri, 17 Jul 2015 16:51:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=nN/oB+PagahRyY9C4s7Jn/TDSVeWMYj0Ii1p9fUA3mM=; b=zxokB0wIrwB3YqSNrXYITLF5iy7VquQFUNJAk1URdPVTkgVoE9O4N7UVvtLaJKPi0d 7FcDZD53mvlCrAL5/G10VDCQkR4yPPNSV/fruSzg0pRfZUmAs3fG4YyFwujhrqB5hwpi figzEeDViGswpxFmJj6Cmw0se2iikysf/I/zvkok3j0lBE+0DMUOOjBFoAoLrbtEO3j5 qjPPye9f085F/gcVhgwp8vjy4W7V501jPaWO0dyndhDdoa90vm1+g7I7JcPyD9A3tmgA +nCcybDq8oGFz+R3sl21lDRj11xFBteA4XhzjfdC2c4OuaJTlhtuvlYqNO/0WoEWWiKJ PIvg== X-Received: by 10.50.30.197 with SMTP id u5mr77080igh.9.1437177096577; Fri, 17 Jul 2015 16:51:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.205.5 with HTTP; Fri, 17 Jul 2015 16:51:06 -0700 (PDT) In-Reply-To: <331D6E02-167D-4E7F-9682-F63C6674BD24@gmail.com> References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> <331D6E02-167D-4E7F-9682-F63C6674BD24@gmail.com> From: Mark Smith Date: Sat, 18 Jul 2015 09:51:06 +1000 Message-ID: To: Andrew Yourtchenko Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" , v6ops list Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 17 Jul 2015 23:51:38 -0000 On 18 July 2015 at 02:57, Andrew Yourtchenko wrote: > > On 17 Jul 2015, at 09:34, Fred Baker (fred) wrote: > >>> >>> So the next logical thing to do would be to have the router default to >>> unicast Router Advertisements, measure the rate of received Router >>> Solicitations, and switch to multicast RA mode past a certain >>> threshold to cover this sort of situation. Once the number of RSes >>> falls, it switches back to unicast RA mode. >>> >>> That would get rid of the configuration knob proposed in this ID, and >>> is behaviour that I think could be universal for all link types, >>> rather than just for the case of wireless ones with mobile devices. >> >> If it were me implementing it, I think I would go about this in a little= different way, hopefully simpler. I would want to send at most one (e.g., = either zero or one) RA per some interval (a second?). In the normal case, t= hat is sent unicast. However, having sent a unicast RA at time t, if I now = receive another RS before t+1, I send the next one (at time t+1) as a multi= cast. > > values of T less than 3 seconds would make performance worse than today. > > There are many things to optimize for: > > - wireless airtime > - bandwidth used by RAs > - CPU usage sending unicast RAs by router > - energy consumption on devices for more than one medium > > Some of them are orthogonal, some of them contradict each other, some of = them align. People may want to optimize differently. > > I'd opt for simplicity - and use the text Erik Kline posted in another em= ail. > > This would allow the developers to adapt for individual use cases on the = spot. > I think specifically calling out the above optimisation considerations would be good to do in this draft. While providing flexibility is useful to cover the unexpected, I also think it is also important to have consistency. Specific case optimisations can be beneficial, but they're also variations and exceptions. The more variations and exceptions there are, the more things people have to try to understand and remember, which makes then makes configuration and troubleshooting harder. So, for example, it would be good to have a consistent default behaviour for all Wifi links (likely unicast solicited RAs, because hosts (PCs, laptops, smartphones) come and go regularly), and a consistent default behaviour for all wired links (likely multicast solicited RAs, because hosts (servers) don't come and go regularly, so the recovery from power outage scenario flood of RSes is the likely common scenario for solicited RAs). Regards, Mark. > --a > >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops From nobody Sat Jul 18 15:53:41 2015 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 3884F1A1A9D for ; Sat, 18 Jul 2015 15:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.001 X-Spam-Level: X-Spam-Status: No, score=-102.001 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_NONE=-0.0001, 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 IIWbkEcu_uEp for ; Sat, 18 Jul 2015 15:53:37 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0148.outbound.protection.outlook.com [65.55.169.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 782E91A1A9C for ; Sat, 18 Jul 2015 15:53:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=NwJW4ngnUQLV0fMg2/R2YwPJG1iVaS9qHx1OqLM7/M0=; b=iKowRrynnBtM+gkiniAeCXa0gliczzOm3gyDzp13lVJmCSztC542jkOHUWBGhBO37yHQm3ITSAvS6EeFgYhkL9GiBdt2n5/FrlsPx7d4u1dniVuM8AX4MAXxLy87Y+PEfXyC4V2qcWExIcQLuE3YBvnallibHqM+GnCinVn8g84= Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB410.namprd03.prod.outlook.com (10.141.141.16) with Microsoft SMTP Server (TLS) id 15.1.225.13; Sat, 18 Jul 2015 22:53:34 +0000 Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.01.0225.013; Sat, 18 Jul 2015 22:53:34 +0000 From: Dave Thaler To: "v6ops@ietf.org" Thread-Topic: RE: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability Thread-Index: AdDBq5y8+UNlBhumQ4edKSHosFy5wg== Date: Sat, 18 Jul 2015 22:53:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [12.11.109.228] x-microsoft-exchange-diagnostics: 1; BY2PR03MB410; 5:ClF2sTyNyu7yscRsQDZRSFbVQ4brnJvT47myzrcpxDqG3Bdm/TsCeVS1eWv7gWczKWz1sBolHwWbMqtwk2z07Y5iJgyFdKBFaVJpQxq4Tlm/V8DXqR46+3kCv8aybtpWnW5KhaUh4/d+Ekuh9mdK7A==; 24:KD07RE9gWQo5qkH2rwBZeG7H/TUZXlNjX3mcJbe1Q/sKEws6MF3JnslSk6/fUxiWYn4YdQK5a0/eCRx7Bw9mJ9smlwZInoi70L0cQ5Ge6SA=; 20:ySruIh1kdCgxiMxyM//Ld9HS0ms/VBJqKVe6KvsdUH1Hhn4O+tsZHbgOvKXcQ8Qg+14kJFfuqtK2dP2XrIfT4A== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB410; by2pr03mb410: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB410; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB410; x-forefront-prvs: 0641678E68 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(74316001)(19300405004)(19580395003)(86362001)(86612001)(50986999)(87936001)(2656002)(66066001)(40100003)(450100001)(62966003)(77156002)(122556002)(15975445007)(77096005)(102836002)(92566002)(230783001)(46102003)(2501003)(5001920100001)(5002640100001)(110136002)(107886002)(5001960100002)(19625215002)(33656002)(54356999)(189998001)(2351001)(99286002)(5003600100002)(16236675004)(76576001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB410; H:BY2PR03MB412.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4126E1E7880C296826D7AEBA3870BY2PR03MB412namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jul 2015 22:53:34.6040 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB410 Archived-At: Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability 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, 18 Jul 2015 22:53:40 -0000 --_000_BY2PR03MB4126E1E7880C296826D7AEBA3870BY2PR03MB412namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I read this draft and have a comment on its discussion (or lack thereof) of= privacy issues... Section 8.1 mentions tracking for "protection from liability for copyright = infringement or other illegal activity", but doesn't say anything about what they actually need to track that DHCP p= rovides. For example, is this referring to MAC address or host name? If so, just add a reference to dra= ft-ietf-dhc-anonymity-profile for why that will be problematic anyway. If they want to force users to identify themselves at a higher level, then = DHCP doesn't provide that and instead they'd be using a captive portal (and see the capport bof...) Also section 11 (security considerations) is currently content free. I'd suggest referencing the above discussions or even moving the discussion= of identity determination/tracking to sec 11. Other possibly relevant references in = that discussion include draft-huitema-6man-random-addresses and draft-huitema-privsec-harmfulname. Dave --_000_BY2PR03MB4126E1E7880C296826D7AEBA3870BY2PR03MB412namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I read this draf= t and have a comment on its discussion (or lack thereof) of privacy issues&= #8230;

 

Section 8.1 ment= ions tracking for "protection from liability for copyright infringemen= t or other illegal activity",

but doesn’= t say anything about what they actually need to track that DHCP provides.&n= bsp; For example, is this

referring to MAC= address or host name?   If so, just add a reference to draft-iet= f-dhc-anonymity-profile

for why that will be problematic anyway.=

 

If they want to force users to identify thems= elves at a higher level, then DHCP doesn’t provide that

and instead they’d be using a captive p= ortal (and see the capport bof…)

 

Also section 11 = (security considerations) is currently content free. 

I’d sugges= t referencing the above discussions or even moving the discussion of identi= ty

determination/tr= acking to sec 11.    Other possibly relevant references in t= hat discussion include

draft-huitema-6m= an-random-addresses and draft-huitema-privsec-harmfulname.

 

Dave<= /span>

 

 

 

 

--_000_BY2PR03MB4126E1E7880C296826D7AEBA3870BY2PR03MB412namprd_-- From nobody Sun Jul 19 02:20:46 2015 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 CE52E1A8F42 for ; Sun, 19 Jul 2015 02:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 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, 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 31xQAAASSwKw for ; Sun, 19 Jul 2015 02:20:41 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39AB71A8885 for ; Sun, 19 Jul 2015 02:20:40 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 9D0DDA1; Sun, 19 Jul 2015 11:20:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1437297638; bh=NhXAz8OjGFM4xbiOh896ZqNliaKXhkt4FVeOyM7458w=; h=Date:From:To:Subject:In-Reply-To:References:From; b=GNeZsWSz4vRFig60vvID5NOVxnn1K+IlLqP4e/orHm/f5e12sWDb/2FP0rxMJ5Lqh 20cIE+zF02VKZTLly5oFTIwWP4oIshGOsl3lzPaVxyG2akUBr6v+sNHSUtZPxndwd4 xZ0knoHaZw/zmts3bh+sMK5TAc7k0iBE06UV7180= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 9520D9F for ; Sun, 19 Jul 2015 11:20:38 +0200 (CEST) Date: Sun, 19 Jul 2015 11:20:38 +0200 (CEST) From: Mikael Abrahamsson To: v6ops@ietf.org In-Reply-To: <559A759F.3080201@jive.com> Message-ID: References: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> <559A759F.3080201@jive.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-281431701-1437297638=:11810" Archived-At: Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability 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, 19 Jul 2015 09:20:44 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-281431701-1437297638=:11810 Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8BIT On Mon, 6 Jul 2015, Simon Perreault wrote: > Le 2015-07-06 07:47, fred@cisco.com a écrit : >> A new draft has been posted, at http://tools.ietf.org/html/draft-colitti-v6ops-host-addr-availability. Please take a look at it and comment. > > +1000 Me too. There are some thing that we need to discuss and some things to iron out exact details on, but the document is extremely useful and I would like to see it adopted as WG document. Personally I would like to see (at least) /64 given to each device that it can use locally. Having lots of addresses on the same subnet means (usually) multicast traffic increases, so the best solution would be to just PD /64 (or larger) to each device and let it figure it out. IPv6 for me is 2^64 networks, not 2^128 addresses, and I would prefer if each device got its own /64 for substantial number of deployment scenarios, especially when devices are run by different entities which includes the ISP (regardless if it's campus network or some other Internet service provider). -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-281431701-1437297638=:11810-- From nobody Sun Jul 19 16:07:38 2015 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 9F18D1B2C4D for ; Sun, 19 Jul 2015 16:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 9Jv2cBbueEGp for ; Sun, 19 Jul 2015 16:07:35 -0700 (PDT) Received: from mta05.svc.cra.dublin.eircom.net (mta05.svc.cra.dublin.eircom.net [159.134.118.221]) by ietfa.amsl.com (Postfix) with SMTP id BB22D1B2B81 for ; Sun, 19 Jul 2015 16:07:34 -0700 (PDT) Received: (qmail 6554 messnum 16650426 invoked from network[213.94.190.12/avas01.vendorsvc.cra.dublin.eircom.net]); 19 Jul 2015 23:07:32 -0000 Received: from avas01.vendorsvc.cra.dublin.eircom.net (213.94.190.12) by mta05.svc.cra.dublin.eircom.net (qp 6554) with SMTP; 19 Jul 2015 23:07:32 -0000 Received: from [192.168.1.3] ([86.43.35.194]) by avas01.vendorsvc.cra.dublin.eircom.net with Cloudmark Gateway id uP7U1q00Z4BK5ly01P7YW5; Mon, 20 Jul 2015 00:07:32 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ross Chandler In-Reply-To: Date: Mon, 20 Jul 2015 00:07:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <68C67D2C-CACF-4D1A-A0D9-19ADC596CDC8@eircom.net> References: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> <559A759F.3080201@jive.com> To: IPv6 Ops WG X-Mailer: Apple Mail (2.2098) Archived-At: Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability 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, 19 Jul 2015 23:07:36 -0000 > On 19 Jul 2015, at 10:20, Mikael Abrahamsson wrote: >=20 > Personally I would like to see (at least) /64 given to each device = that it can use locally. Having lots of addresses on the same subnet = means (usually) multicast traffic increases, so the best solution would = be to just PD /64 (or larger) to each device and let it figure it out. >=20 > IPv6 for me is 2^64 networks, not 2^128 addresses, and I would prefer = if each device got its own /64 for substantial number of deployment = scenarios, especially when devices are run by different entities which = includes the ISP (regardless if it=92s campus network or some other = Internet service provider). +1 to this & the draft. IA_ looks unduly parsimonious. It=92s a pity it exists. As the draft = illustrates is not adding much if any value over SLAAC. AFAIK in ISP networks when DHCPv6 /128 WAN addresses are assigned at all = they=92re in practise coming from a unique /64 per IA. As the draft notes /64 in 3GPP to every device is a successful interim = stage to DHCPv6 PD. Ross From nobody Mon Jul 20 01:42:13 2015 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 F05211A1A58 for ; Mon, 20 Jul 2015 01:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.523 X-Spam-Level: X-Spam-Status: No, score=0.523 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, HK_RANDOM_FROM=1, MALFORMED_FREEMAIL=0.001, MISSING_HEADERS=1.021, 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 IpoUUPukxXq8 for ; Mon, 20 Jul 2015 01:42:11 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::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 658681A1A3C for ; Mon, 20 Jul 2015 01:42:11 -0700 (PDT) Received: by ietj16 with SMTP id j16so113090196iet.0 for ; Mon, 20 Jul 2015 01:42:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc :content-type; bh=8hz+o6lVlODhkQNLuLyXqK1cET61GV2lpImJtAUkxmk=; b=Ezhjl4oevRJnbcDaaZf4C50raaLZkV+lj+xO/trUTnxsIsBiPMcEa5eM8foBcXiLdD CTuQOUmjBYlHFy6E+D6QgTsL4s5of3GXswSK7xFj6Oz8dmkDpFlUNhWax1rY+JMiEPPF 1YXjoWfcbsw/0LKdyHKrZykNUVjLCWySU3YL0+t9V1YIa8ODaM8Ni4G60wF5oe8aUGha JOgC8cEr54BrbWzOb0UqqtVtnf9hNlQ3R7OV6df1PMsVD+1MfxzwaLPIRi2MrwvCNojB fxdXXRHjJZzzWw0CFxkeZ+235I8/279ND9C/MWjfg/mnZV/cgsI5Bk+mHltSy8TQRWdF nbOg== X-Received: by 10.107.10.96 with SMTP id u93mt25094242ioi.172.1437381730829; Mon, 20 Jul 2015 01:42:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.205.5 with HTTP; Mon, 20 Jul 2015 01:41:41 -0700 (PDT) In-Reply-To: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> References: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> From: Mark Smith Date: Mon, 20 Jul 2015 18:41:41 +1000 Message-ID: Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: v6ops list , draft-colitti-v6ops-host-addr-availability@tools.ietf.org Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability 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, 20 Jul 2015 08:42:13 -0000 Hi, Firstly, I would support the WG adoption of this draft. Some thoughts and comments, Abstract & Intro ~~~~~~~~~~~ I think stating that it also describes benefits would create a bit more of an interest in reading it e.g., "This document recommends that networks provide general-purpose end hosts with multiple global addresses, and describes *the benefits and * options for doing so." 3. Benefits of multiple addresses ~~~~~~~~~~~~~~~~~~~~~~~~ Another benefit : o Increased robustness. RFC6724 prefers smaller scope addresses over larger ones, meaning link-local source and destination addresses are preferred over ULAs, which are preferred over GAUs. As link-local addresses can be used by applications [RFC4007], this means that communications robustness is increased when link-local addresses are used by applications, because the application can continue to operate regardless of the presence of one or more routers on the link and other larger scope addresses. Similarly, when an application is using ULA addresses, it is robust against events that would disrupt the network's GUA addressing, such as a GUA renumbering event. o Future applications (e.g., per-application IPv6 addresses). - I think "Transient addressing for related processes: Improved firewalling by using IPv6 and multiple addresses per host." by Peter M. Gleitz and Steven M. Bellovin would be an excellent example to reference: https://www.cs.columbia.edu/~smb/papers/tarp.pdf 5. Overcoming limits using Network Address Translation ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A reference to RFC2993, "Architectural Implications of NAT", somewhere would be good. 7. Options for obtaining more than one address ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "If the prefix is a /64, it can also reshare that prefix with any downstream clients via [RFC7278] /64 sharing." I'm not sure RFC7278 should be suggested as a general purpose method, as there were a number of kludges/limitations in that method specific to dealing with the lack of DHCPv6-PD support on the 3GPP devices e.g., switching from a /64 numbered upstream link to a link-local upstream link (while the carrier device still thinks the /64 is on the link) so the /64 could be used on the downstream link. Its basically presenting methods that are a half way between routing and bridging between the upstream and downstream links, and that created issues because it wasn't completely one or the other. 8.1. Stateful addressing and host tracking ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I think it is also worth pointing out that network layer and link-layer device identifiers/numbers/addresses are not a very reliable identifier or analogue of people, or more specifically attackers, because the identifiers/numbers/addresses can change, can be changed and may not be globally unique, in particularly quite easily if the attacker is using their own device. Identifying the individual accessing the network using user/human authentication methods such as 802.1X and one or more of the what you have, what you are, or what you know, could provide a audit record of the much tighter coupling between a human and the network identifiers they use during the authenticated session. Nits etc. 2. Common IPv6 deployment model ~~~~~~~~~~~~~~~~~~~~~~~~~~ There seems to be a reference error here, as RFC6433 is "Requirements for a Working Group Milestones Tool" and doesn't have a 5.9.4 section. Regards, Mark. From nobody Mon Jul 20 07:23:32 2015 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 1D0031A21B2 for ; Mon, 20 Jul 2015 07:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 yvmL-OZ-xVoI for ; Mon, 20 Jul 2015 07:23:30 -0700 (PDT) Received: from mail-vn0-x233.google.com (mail-vn0-x233.google.com [IPv6:2607:f8b0:400c:c0f::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 E8D471A8974 for ; Mon, 20 Jul 2015 07:23:29 -0700 (PDT) Received: by vnds125 with SMTP id s125so23442120vnd.1 for ; Mon, 20 Jul 2015 07:23:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=rZAuejMaCGqo3ffeTSqlh/6b62GpL6TTsGlzPT/moxY=; b=EJKaGjRrxKsCvKzkCGMHplH0r5nIHZvDBAUvsszOEelElkXk8d4nUHHI/VGz00M+i8 MMOrnJNrr4sN0sKFqWSu6yGtQ+M+uejdTtT/RI8EWem0U3Viy2o4vkGRld6Ga8HF/Rw7 B0NbPhCYdmG7HJBh9X25jikdQjcPMJiT96Taio/vVw7l7PaddjoGCEVBxCXwVgizs/St GqMdHcmiFDyJWlbnbCWRBtaQ7m7eAGMvELZNJI9i+0tRnXLJxqvzzePk3+3fpWH0s9AA Zned8NRN4Vk3yU47yOPC2mWq/IinfCOVeUiizXT0LLdGvGjOokWJzmndndEjopdS0CKq mfXg== X-Received: by 10.52.94.115 with SMTP id db19mr16697069vdb.92.1437402209145; Mon, 20 Jul 2015 07:23:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.189.83 with HTTP; Mon, 20 Jul 2015 07:23:09 -0700 (PDT) In-Reply-To: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> From: Jen Linkova Date: Mon, 20 Jul 2015 16:23:09 +0200 Message-ID: To: "Fred Baker (fred)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org, "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 20 Jul 2015 14:23:31 -0000 On Tue, Jul 7, 2015 at 1:47 PM, wrote: > A new draft has been posted, at http://tools.ietf.org/html/draft-yc-v6ops-solicited-ra-unicast. Please take a look at it and comment. A bit late but...I fully support the draft. Very useful work. One comment: Lorenzo, Andrew - do you think it worth mentioning the difference in how reliable multicast and unicasts are on wifi? -- SY, Jen Linkova aka Furry From nobody Mon Jul 20 09:29:32 2015 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 A035B1A8AA8 for ; Mon, 20 Jul 2015 09:29:30 -0700 (PDT) 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 FLnuXYZ8v9Nj for ; Mon, 20 Jul 2015 09:29:29 -0700 (PDT) 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 3B53A1A8974 for ; Mon, 20 Jul 2015 09:29:29 -0700 (PDT) Received: by ykdu72 with SMTP id u72so142900632ykd.2 for ; Mon, 20 Jul 2015 09:29:28 -0700 (PDT) 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=pbFhHV/m7j7AXuhbKDv0pUmBz58nRKssHfyXu/AgyLA=; b=Z0Ye6Cb56K0ZskbJZ4/+CT/ayj4UWRuadzT6b7ij8O8VR2kBCORSmoTEYb+yWP3lb+ Gte9bPrgxkcHZd2KU04RXTyV+DfBiv8B+lot1HP8z6luwmwGZxErkVEtLbFKPoR45aYm 6yAlwZUnprMdIVHlVDc6AyKEqYMptGx3zJDo31aG8z69HBC/HcxNyxk1I6fTptOs7BRx TFy4Rj+tvsLzGuiecQlY9K0RqbZweBgjNfrEI05MrUCAQORdp7kEOPRzhfg8eD3uouqJ JVVbR+CIIg2LaP8oZAZEDntlG/l2M96LL+wySHdHttQz6rpTXkkRfsCkbHptpodAan7a 7+kg== 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=pbFhHV/m7j7AXuhbKDv0pUmBz58nRKssHfyXu/AgyLA=; b=W5SWB/5y4BaUMA/+L6AkyIz1HVGMSdhuvYj0UhZ6FZwuWb/IA/uLTwTU3dZ4xd00rK qyAoliX5BEDzOSxsQvJntH3wBtFE/59bZoY50MIxZtFuQ5JnEajZLELRFpHYXNjxesoQ AoEUurLTFP0t1z7cQYz5jPcrK1PBogZuJ+tE9aRax8hI1ildAl/N88rwgP0OvCoOWrHl 8W5SnKHN6h+uCpNUsWYggqErBP7kA9r5J39ihH1wFC/Q4HxudBaS1cgdpffAOobE+SeB sgXdmwlLzA6Cz0qs1eBvzno1FezkUgzmBD4pk33to5UuOUzfVfxkyq/jH59MRHbATvOK StzA== X-Gm-Message-State: ALoCoQkCaM2D33za+cjEmBKEa/Rv2h8W8t1+h9e8TgNow0DKOBWxHOOQAKXlziyPO0pItUngCAsY X-Received: by 10.170.40.20 with SMTP id 20mr1555988yki.47.1437409768571; Mon, 20 Jul 2015 09:29:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.8.201 with HTTP; Mon, 20 Jul 2015 09:29:08 -0700 (PDT) In-Reply-To: References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> From: Lorenzo Colitti Date: Mon, 20 Jul 2015 18:29:08 +0200 Message-ID: To: Mark Smith Content-Type: multipart/alternative; boundary=001a1137aa94a76be7051b510ac2 Archived-At: Cc: draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org, "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 20 Jul 2015 16:29:30 -0000 --001a1137aa94a76be7051b510ac2 Content-Type: text/plain; charset=UTF-8 On Thu, Jul 9, 2015 at 7:08 AM, Mark Smith wrote: > It was my understanding that the idea behind multicasting solicited > RAs was to also update hosts who were soon going to be issuing > multicast RSes, which would then reduce the volume of multicast RSes. > If those hosts are now not going to receive the multicast solicited > RAs, then they I think they would now be issuing multicast RSes more > often where as in the past they wouldn't. > Yes. In the (rare) case where a large number of nodes joins the network at the same time, sending a single multicast RA would likely be more efficient. That would need to be weighed against the power implications on the nodes that are already connected, so it probably only makes sense if the router is seeing large enough numbers of RS packets that it believes that it cannot handle them efficiently. We could put something in the draft saying that "routers configured in this mode MAY send solicited RAs multicast in conditions where it is likely that doing so will be more efficient (e.g., if a large number of clients is sending RS packets at the same time and the packets are being dropped due to control plane limiting). As a side note, the radvd RA daemon already supports a UnicastOnly option: > > -- > UnicastOnly on|off > Indicates that the interface link type only supports unicast. This > will prevent unsolicited advertisements from being sent, and will > cause solicited advertisements to be unicast to the soliciting node. > This option is necessary for non-broadcast, multiple-access links, > such as ISATAP. > That doesn't help because it doesn't do unsolicited advertisements. --001a1137aa94a76be7051b510ac2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jul 9, 2015 at 7:08 AM, Mark Smith <markzzzsmith@gmail.com>= ; wrote:
It was my understanding t= hat the idea behind multicasting solicited
RAs was to also update hosts who were soon going to be issuing
multicast RSes, which would then reduce the volume of multicast RSes.
If those hosts are now not going to receive the multicast solicited
RAs, then they I think they would now be issuing multicast RSes more
often where as in the past they wouldn't.

Yes. In the (rare) case where a large number of nodes joins the netw= ork at the same time, sending a single multicast RA would likely be more ef= ficient. That would need to be weighed against the power implications on th= e nodes that are already connected, so it probably only makes sense if the = router is seeing large enough numbers of RS packets that it believes that i= t cannot handle them efficiently.

We could put som= ething in the draft saying that "routers configured in this mode MAY s= end solicited RAs multicast in conditions where it is likely that doing so = will be more efficient (e.g., if a large number of clients is sending RS pa= ckets at the same time and the packets are being dropped due to control pla= ne limiting).

As a sid= e note, the radvd RA daemon already supports a UnicastOnly option:

--
UnicastOnly on|off
Indicates that the interface link type only supports unicast. This
will prevent unsolicited advertisements from being sent, and will
cause solicited advertisements to be unicast to the soliciting node.
This option is necessary for non-broadcast, multiple-access links,
such as ISATAP.

That doesn't help b= ecause it doesn't do unsolicited advertisements.
--001a1137aa94a76be7051b510ac2-- From nobody Mon Jul 20 09:35:44 2015 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 CB0311A8F40 for ; Mon, 20 Jul 2015 09:35:42 -0700 (PDT) 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 zPXOiSX6rjdT for ; Mon, 20 Jul 2015 09:35:42 -0700 (PDT) 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 DBDF51A8856 for ; Mon, 20 Jul 2015 09:35:41 -0700 (PDT) Received: by ykdu72 with SMTP id u72so143050377ykd.2 for ; Mon, 20 Jul 2015 09:35:41 -0700 (PDT) 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=y9Q5PsqSLy59y6fqZ7dQpVCDR98GoT0qHNV2tiNj/kI=; b=fYHJro4IYL4oE0I/SjQ31erhNcYxPW9MFpsHVXnTsNoVudex4gsS0aW42MwOLU1H07 TMkuZ3z9AH5DehvTPKXmdTWkta5/3ZXmZQz+029hnQVzunu83WbLje8k+lxRBqQpIgdn oaWOodDdsS3H2PZYpBt30qlsGeDxs56xgdsPKh3WoO93EDvgMiGDdD9OPvqCzLYtrSAI LtS5G2Xwh0FAxMLHj394/XkOiTp+jA3VRhJuT80hcvyR4JIxAGPCiZCK8i50xD94QHeT nYL1uE4B1cVvL+US0fNdalpoCoDJxZ2lv7pZCSC/TFge+yDwOmamd+zcDbLETXHVsxh/ +50Q== 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=y9Q5PsqSLy59y6fqZ7dQpVCDR98GoT0qHNV2tiNj/kI=; b=YEb7GAbQStctDuJGwnyOU/814qMg353rGEmPV03I3nh6bCb5giSC/bj6O3L/l3jkK3 r6q/0ZE2vFHzaZuWuwi/j1qPae5qrdoXWkEUshRHAlq/TJSZjAakyjndJjOcZBocH1eh qW8TUFG8YPDrdNHJUXpJc2AHd4ix0V0201iZ9ZZZcRbItDQSKtDay7S2JfgcncPgm6tk jkXgHmAygtqafFJpO32JCLom/ND+E/xdvch8gAjk1p/C7jRMjuxGBXDhfOUGbJufJ6mP PXQSS8zCvRp0Qlc8YhAPG2kaw3dSpOLw3R5axrNW0GiWjU82HuUmMhiMQXyx5+lCuN8Y FV4w== X-Gm-Message-State: ALoCoQm5qy2bZzcEscsWGLzJWAKSGbaoAeEpe01EoEi3iOjzr2APMmHzlkWPhrDNoOT0YVnA0hx7 X-Received: by 10.13.255.2 with SMTP id p2mr11988277ywf.149.1437410141235; Mon, 20 Jul 2015 09:35:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.8.201 with HTTP; Mon, 20 Jul 2015 09:35:21 -0700 (PDT) In-Reply-To: References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> From: Lorenzo Colitti Date: Mon, 20 Jul 2015 18:35:21 +0200 Message-ID: To: Erik Kline Content-Type: multipart/alternative; boundary=94eb2c0888f6ddbb22051b5120f1 Archived-At: Cc: "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" , v6ops list Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 20 Jul 2015 16:35:42 -0000 --94eb2c0888f6ddbb22051b5120f1 Content-Type: text/plain; charset=UTF-8 On Fri, Jul 17, 2015 at 9:59 AM, Erik Kline wrote: > I'd leave it at roughly: > > - multicast RA at least once every max_ra is still a MUST (iirc) > Do we need to repeat this? It should already be clearly stated by RFC 4862. > - unicast RAs MAY be sent at any time, whether solicited or not > What's the use case for a unicast unsolicited RA? They can only reach nodes for which the router knows the IPv6 addresses, and so pretty much require that routers keep a lot of state. - unicast RAs SHOULD be considered for link layers where this > helps efficiency > I think we also need to provide a clear recommendation to do this on common types of links where this is beneficial, i.e., Wi-Fi. --94eb2c0888f6ddbb22051b5120f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jul 17, 2015 at 9:59 AM, Erik Kline <ek@google.com> wrote:
I'd leave it at roughly:

=C2=A0 =C2=A0 - multicast RA at least once every max_ra is still a MUST (ii= rc)

Do we need to repeat this? It shoul= d already be clearly stated by RFC 4862.
=C2=A0
=C2=A0 =C2=A0 - unicast RAs MAY be sent at any time, whether solicited or n= ot

What's the use case for a unicas= t unsolicited RA? They can only reach nodes for which the router knows the = IPv6 addresses, and so pretty much require that routers keep a lot of state= .

=C2=A0 =C2=A0 - unicast RAs SHOULD be considered for link layers where this=
helps efficiency

I think we also need t= o provide a clear recommendation to do this on common types of links where = this is beneficial, i.e., Wi-Fi.
--94eb2c0888f6ddbb22051b5120f1-- From nobody Mon Jul 20 10:04:38 2015 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 0259A1B2C65 for ; Mon, 20 Jul 2015 10:04:36 -0700 (PDT) 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 soITyIPUfSVk for ; Mon, 20 Jul 2015 10:04:36 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450: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 F073F1B2C64 for ; Mon, 20 Jul 2015 10:04:35 -0700 (PDT) Received: by wicmv11 with SMTP id mv11so20373391wic.0 for ; Mon, 20 Jul 2015 10:04:34 -0700 (PDT) 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=wZ739pZO1P3pluWVCIibSc1G0wbaRcd4j5XLW35MoFI=; b=RXSQUyiUakMf8YsbuxcI4RJmOzQtW7LNU61DXUPX3xjZY9RNaITzAe0ygPevmC8h8g GpcSnxuFS2VzyqXzkHMdCoLhK4HGJ0X/HyvZeyHFAmSvo6whxx2d+SYt9G3qroNXERL5 hBptZ8xuJvAVF/mCjjpYKvR8Gys90mLoS6LABhI+cCLdyWgRWVzQTUj5RcGaiPANj8nG XKwPE8iHnn6W+D0HduMC2Cjuf2DfRqWBWDkzLEqoZbM1tk2L8bX751GF0+IFKn0q+id8 eGYpDsqB9OHNI1Cpwlk00JfYbKNbI/1lvAyD5/N9rHXkkuAQTtULrzKqOUJ64i3dP7g9 REiw== 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=wZ739pZO1P3pluWVCIibSc1G0wbaRcd4j5XLW35MoFI=; b=dKY1N8Tl36kw11TTYoMogaNpjW/82UOXJaeLL3+4PvPFNhW/MVYgrlqAM+W5q6uCpC JR+KT+N1CnRz0/eurwH+W1gSEkBfBY4YPkAnckEpLs+Vn2KxVlGJ+jqbvcpRrDm5UmY2 jGO5oerjhV2RJGgZqouONSS0Iy1dw1Bde96/59KdgYabsZ/9Z4TcO+gJZsNX1Ff5AvDb oD4DlJfRVOIeWotoNzzrWl6H82J0bfVJWQPobTdXeVY0Sn9sPUDZXglQHmzzVf/E/dtD 0rkVDMi4KX0o39k4nUJ130LsaBcZU0PanVChdmj7xYHRklrnlpNzayqZABHjYjktStXL 59nQ== X-Gm-Message-State: ALoCoQnMImSNr55eHaSvFaR90k8wuhFzzWXxJNNx75pLx3dwPSxlBM5ctTr7Eskz8/rPIIJ6ONs+ X-Received: by 10.194.78.210 with SMTP id d18mr57458766wjx.34.1437411874477; Mon, 20 Jul 2015 10:04:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.138.203 with HTTP; Mon, 20 Jul 2015 10:04:14 -0700 (PDT) In-Reply-To: References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> From: Erik Kline Date: Mon, 20 Jul 2015 19:04:14 +0200 Message-ID: To: Lorenzo Colitti Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" , v6ops list Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 20 Jul 2015 17:04:37 -0000 >> - unicast RAs MAY be sent at any time, whether solicited or not > > > What's the use case for a unicast unsolicited RA? They can only reach nodes > for which the router knows the IPv6 addresses, and so pretty much require > that routers keep a lot of state. Yes, and these routers exist. The M2M stuff I scanned in 3GPP has nodes that sleep on a schedule and the network knows when they're supposed to wake up (and they have to wake up periodically if only to sync their clocks with the network). From nobody Mon Jul 20 10:19:15 2015 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 F2B0F1B2CCD for ; Mon, 20 Jul 2015 10:19:13 -0700 (PDT) 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 cVmlVPs1xLeW for ; Mon, 20 Jul 2015 10:19:13 -0700 (PDT) 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 6030E1B2CAE for ; Mon, 20 Jul 2015 10:18:04 -0700 (PDT) Received: by ykax123 with SMTP id x123so144464652yka.1 for ; Mon, 20 Jul 2015 10:18:03 -0700 (PDT) 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=PE98svo08nscQFeqSk50NGyUNmd7z8X62p/O2Y2K0FI=; b=pp9EyZP165EoHh7Vw9yJ/rGPwyeCputz8Pbs56pdzdm0oPH7iEtzFZPo0J+nZdu4hZ znr2PGRrKtTnIl5y/NXOEI3hakrQAlRzxlmS/H4AuceOY2mLWf3EXBTv7JlWgIzbfhXy Vzh9ReiSRr/KRhFXrFDR1wvAu+uZsRWLVeL/GxA0u7mMLXeQgAwq9Cuy1Q9bGgUbbH53 EY1MsjOPiFqACK4AoUnCpfTblcBA2i7e/4Hs8oaowi9mqRfxukkfmww6hvvsYwzCrD5e exCbdagjkF7PAr0kiDEJ34wT+ZUia3rA6xaNgXUzLQj9aSJzJOoVTejV28r9/mLe7LzH tZMw== 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=PE98svo08nscQFeqSk50NGyUNmd7z8X62p/O2Y2K0FI=; b=QdGszfeNppX7jG0sYCIPQhf6UQiGySvQGTjDOzoaw/RCDrWReZ83baVDCylkjH0rfM go14haSO35FHRYbfgNegyDO8BJyT3tNQ9ce3FL+GV+Lar1FfVLEvzjB1/d0O5mRCT16n ZM68yUYICfeXlIfdZ2jX44Q5IL0sip8iwfLn1PPuf1uJoV7Gpcim6+PmbCzxprXVss4Y v51QLRN8D2t5l5IvhcRqOjdVQR60bKAbCho/4SvKs7ma+uING4syNaYpMCYSmzPpdaMr ITyNyKuAuc67IQu9w+u9Xt2RBRbEZxPfZkVpROf4H4d9xJA1AAkgsil0rDNRkiGPSVa9 5oCQ== X-Gm-Message-State: ALoCoQnQco6tB2qpkivdaliFF7Hjrwq4hJRXS+C4Fj5aTxWEXTrkQQqFcN2WLvftTe1IOJ3+SeO6 X-Received: by 10.129.77.213 with SMTP id a204mr30120056ywb.40.1437412683774; Mon, 20 Jul 2015 10:18:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.8.201 with HTTP; Mon, 20 Jul 2015 10:17:44 -0700 (PDT) In-Reply-To: References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> From: Lorenzo Colitti Date: Mon, 20 Jul 2015 19:17:44 +0200 Message-ID: To: Erik Kline Content-Type: multipart/alternative; boundary=001a1140c55269d35c051b51b84e Archived-At: Cc: "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" , v6ops list Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 20 Jul 2015 17:19:14 -0000 --001a1140c55269d35c051b51b84e Content-Type: text/plain; charset=UTF-8 On Mon, Jul 20, 2015 at 7:04 PM, Erik Kline wrote: > Yes, and these routers exist. The M2M stuff I scanned in 3GPP has > nodes that sleep on a schedule and the network knows when they're > supposed to wake up (and they have to wake up periodically if only to > sync their clocks with the network). > That's a very different use case from this draft as currently written, though. Are you suggesting that this document should be extended to cover both and provide separate advice to both? We can do that, but I don't think we should make this document into a generic document that only says "do the right thing for your link type". The reason we have this problem is that vendors and operators do not necessarily know what the right thing for their link type is. --001a1140c55269d35c051b51b84e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jul 20, 2015 at 7:04 PM, Erik Kline <ek@google.com> wrote:
Yes, and these routers exist.=C2=A0 The M2= M stuff I scanned in 3GPP has
nodes that sleep on a schedule and the network knows when they're
supposed to wake up (and they have to wake up periodically if only to
sync their clocks with the network).

That's a very d= ifferent use case from this draft as currently written, though.

Are you suggestin= g that this document should be extended to cover both and provide separate = advice to both? We can do that, but I don't think we should make this d= ocument into a generic document that only says "do the right thing for= your link type". The reason we have this problem is that vendors and = operators do not necessarily know what the right thing for their link type = is.
--001a1140c55269d35c051b51b84e-- From nobody Mon Jul 20 11:18:27 2015 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 AB0C21B2A81 for ; Mon, 20 Jul 2015 11:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 lNTF398fdqjG for ; Mon, 20 Jul 2015 11:18:25 -0700 (PDT) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (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 806BF1B2A80 for ; Mon, 20 Jul 2015 11:18:25 -0700 (PDT) Received: from [130.129.5.149] (dhcp-hotel-wired-5-95.meeting.ietf.org [130.129.5.149] (may be forged)) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t6KIIEme025178 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 20 Jul 2015 11:18:17 -0700 To: "Fred Baker (fred)" , Mark Smith References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> From: Erik Nordmark Message-ID: <55AD3B64.5070400@acm.org> Date: Mon, 20 Jul 2015 20:18:12 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVbArd0O464AVQjlJw4Vhauvpkt5lvyVPmDcp6is4X7guduc8bWqT1FQ3xla9ayJRGTTp98qTmOpXVboVf/CBBfb X-Sonic-ID: C;zFKrrwsv5RGvPIM848vClw== M;qmuFsQsv5RGvPIM848vClw== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Archived-At: Cc: "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" , v6ops list Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 20 Jul 2015 18:18:26 -0000 On 7/17/15 9:34 AM, Fred Baker (fred) wrote: >> So the next logical thing to do would be to have the router default to >> unicast Router Advertisements, measure the rate of received Router >> Solicitations, and switch to multicast RA mode past a certain >> threshold to cover this sort of situation. Once the number of RSes >> falls, it switches back to unicast RA mode. >> >> That would get rid of the configuration knob proposed in this ID, and >> is behaviour that I think could be universal for all link types, >> rather than just for the case of wireless ones with mobile devices. > If it were me implementing it, I think I would go about this in a little different way, hopefully simpler. I would want to send at most one (e.g., either zero or one) RA per some interval (a second?). In the normal case, that is sent unicast. However, having sent a unicast RA at time t, if I now receive another RS before t+1, I send the next one (at time t+1) as a multicast. First of all I support this document as a WG document. But in terms of implementation, isn't it simpler to always(*) respond to a RS with a unicast RA? As background, the text in RFC4861 comes from the old concern that all devices might boot at the same time when the power is re-established after a building power failure; that doesn't happen since most devices (laptops, smartphones, IoT devices) have batteries today. In that case it might have made sense to sending fewer RA messages by using multicast. (*) the only case in RFC 4861 when I think a multicast response might be considered is when the source IPv6 address in the RS is the unspecified address. Further, an implementation which rate limits received RS packets (e.g., CoPP in a router) might also want to detect when the rate limit might have dropped RS packets and multicast an RA in that case. I do wonder why implementations haven't already changed to send unicast solicited RA, and whether it would make a difference if we have an informational document asking them to do this. Alternatively we could have a proposed standard which updates section 6.2.6 to change the "MAY unicast" to a "SHOULD unicast". FWIW the draft incorrectly refers to section 6.2.4 instead of 6.2.6. Thanks, Erik > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Jul 20 12:01:28 2015 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 CA2DD1B2B82 for ; Mon, 20 Jul 2015 12:01:27 -0700 (PDT) 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 nyxM-rEN9dYI for ; Mon, 20 Jul 2015 12:01:26 -0700 (PDT) Received: from valgus.lanparty.ee (valgus.lanparty.ee [194.126.124.108]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D40FD1B2B58 for ; Mon, 20 Jul 2015 12:01:04 -0700 (PDT) Received: from 89-44-71-217.dyn.internet.emt.ee ([217.71.44.89] helo=[10.129.128.89]) by valgus.lanparty.ee with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1ZHGJC-0005Ev-3m for v6ops@ietf.org; Mon, 20 Jul 2015 22:01:02 +0300 To: v6ops@ietf.org References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> From: Tarko Tikan Message-ID: <55AD455C.2030809@lanparty.ee> Date: Mon, 20 Jul 2015 22:00:44 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 217.71.44.89 X-SA-Exim-Mail-From: tarko@lanparty.ee X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:57:07 +0000) X-SA-Exim-Scanned: Yes (on valgus.lanparty.ee) Archived-At: Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 20 Jul 2015 19:01:28 -0000 hey, > What's the use case for a unicast unsolicited RA? They can only reach > nodes for which the router knows the IPv6 addresses, and so pretty much > require that routers keep a lot of state. Another use case, not directly relevant to this draft, is targeting specific nodes for which RA should be injected. This is required in shared L2 environments where you don't want to enable ipv6 for all nodes. This requires router to keep some sort of state or use external lookup (radius). -- tarko From nobody Mon Jul 20 13:34:22 2015 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 1435E1B31B9 for ; Mon, 20 Jul 2015 13:34:21 -0700 (PDT) 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 WM_LzNCjhvyM for ; Mon, 20 Jul 2015 13:34:18 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74A1B1B31A9 for ; Mon, 20 Jul 2015 13:34:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5005; q=dns/txt; s=iport; t=1437424458; x=1438634058; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jBYlC7l4xClgPfURoRKicTbnbOxsxwn4T8bcDxhmjEs=; b=ZNuIZlQ5elxZa9TfKPRi9+Vc2wb+MZwUX4xHAsdlliwiNaKGRhmvAW4D KsaPa8l8xosHvS+uvF1c2przBvpMPkLOZ0C4FhS8XG2N8KKp0zbvIwPPO nBr5bdD+9Cge+GN2UJL3Vcurg8Pm47EZ66Qc/Ma4Db9qiFXZdk73A/kBQ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AcAwDcWa1V/4sNJK1cgkZNgT0Gu2gJh3YCgTA4FAEBAQEBAQGBCoQjAQEBBHkQAgEIBA0DAQIoBzIUCQgCBAENBYguyRABAQEBAQEBAQEBAQEBAQEBAQEBAQEXi0yEdREHhCsFlFIBjCCBQ5Njg2Emgg0cgVNvgUeBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,510,1432598400"; d="scan'208,217";a="170666394" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jul 2015 20:34:17 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t6KKYHOI024385 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Jul 2015 20:34:17 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.38]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Mon, 20 Jul 2015 15:34:17 -0500 From: "Sri Gundavelli (sgundave)" To: Lorenzo Colitti , Erik Kline Thread-Topic: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast Thread-Index: AQHQwwoRV5WE5H8C40euPLXoQlwU+53k6fMAgAADxQD//8GNgA== Date: Mon, 20 Jul 2015 20:34:16 +0000 Message-ID: References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@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.1.150515 x-originating-ip: [10.24.133.228] Content-Type: multipart/alternative; boundary="_000_D1D2A8321B7D8Fsgundaveciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" , v6ops list Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 20 Jul 2015 20:34:21 -0000 --_000_D1D2A8321B7D8Fsgundaveciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Did you guys look at RFC-6085 ? We published this clarification mainly to s= upport per-MN prefix model on shared links, by the use of L2 unicast RA's. = Is that not sufficient ? From: Lorenzo Colitti > Date: Monday, July 20, 2015 10:17 AM To: Erik Kline > Cc: "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" >, v6ops list > Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast On Mon, Jul 20, 2015 at 7:04 PM, Erik Kline > wrote: Yes, and these routers exist. The M2M stuff I scanned in 3GPP has nodes that sleep on a schedule and the network knows when they're supposed to wake up (and they have to wake up periodically if only to sync their clocks with the network). That's a very different use case from this draft as currently written, thou= gh. Are you suggesting that this document should be extended to cover both and = provide separate advice to both? We can do that, but I don't think we shoul= d make this document into a generic document that only says "do the right t= hing for your link type". The reason we have this problem is that vendors a= nd operators do not necessarily know what the right thing for their link ty= pe is. --_000_D1D2A8321B7D8Fsgundaveciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <1A55F8A716ECD747831F18A17822205E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Did you guys look at RFC-6085 ? We published this clarification mainly= to support per-MN prefix model on shared links, by the use of L2 unicast R= A's. Is that not sufficient ?




From: Lorenzo Colitti <lorenzo@google.com>
Date: Monday, July 20, 2015 10:17 A= M
To: Erik Kline <ek@google.com>
Cc: "draft-yc-v6ops-solicited-ra-un= icast@tools.ietf.org" <draft-yc-v6ops-solicited-ra-unicast@tools.iet= f.org>, v6ops list <v6ops@ietf.org> Subject: Re: [v6ops] new draft: dra= ft-yc-v6ops-solicited-ra-unicast

On Mon, Jul 20, 2015 at 7:04 PM, Erik Kline <ek@google.com>= ; wrote:
Yes, and these routers exist.  The M2M stuff I scanned in 3GPP has
nodes that sleep on a schedule and the network knows when they're
supposed to wake up (and they have to wake up periodically if only to
sync their clocks with the network).

That's a very different use case from this draft= as currently written, though.

Are you suggesting that this document should be = extended to cover both and provide separate advice to both? We can do that,= but I don't think we should make this document into a generic document tha= t only says "do the right thing for your link type". The reason we have this problem is that vendors and = operators do not necessarily know what the right thing for their link type = is.
 --_000_D1D2A8321B7D8Fsgundaveciscocom_-- From nobody Tue Jul 21 02:33:51 2015 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 F0AEC1B2BFB for ; Tue, 21 Jul 2015 02:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljMf-rGHLYWo for ; Tue, 21 Jul 2015 02:33:48 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::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 6E0141A044D for ; Tue, 21 Jul 2015 02:33:48 -0700 (PDT) Received: by iebmu5 with SMTP id mu5so137255679ieb.1 for ; Tue, 21 Jul 2015 02:33:48 -0700 (PDT) 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=Nx0JpWBFa6NJeoKcoi9EP9lm7Xqj7kXktsKg549gsw4=; b=wMBZ/SnxniBv0XShIcAWVTOOdejS04+SeQto0b17hi2FXpMi0ga6bfR9fXxIjOUsOB 555I/iIcCw779iakZRJ3fZZ3QxnALv3kRUFRyLLNRk6C07e34eEBXtuQ6FHpyBNm3Ccj /6nfoUnoFJ0iC6/uewk78QHYbo9xBmZZRhklkHtvgfLFCaH0Rl3oguvJZDaqT8e53pWP dcehk3Cek+Ikh54Bdg0W9gZgwquw1KdaKD1gVrXlbVgbyGPnP7OzZmzK86+8r3uxdk/s pyTCKdNEMLFN9ZxTuQtYITJ6qq06ha7pN3tl6GEfGKz9GkLBsokvE8bLf0ZupNbYiDBa Wwzg== MIME-Version: 1.0 X-Received: by 10.107.137.154 with SMTP id t26mr43224827ioi.13.1437471227901; Tue, 21 Jul 2015 02:33:47 -0700 (PDT) Received: by 10.107.182.7 with HTTP; Tue, 21 Jul 2015 02:33:47 -0700 (PDT) In-Reply-To: <55AD3B64.5070400@acm.org> References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> <55AD3B64.5070400@acm.org> Date: Tue, 21 Jul 2015 11:33:47 +0200 Message-ID: From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= To: Erik Nordmark Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" , v6ops list Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 21 Jul 2015 09:33:50 -0000 On 7/20/15, Erik Nordmark wrote: > On 7/17/15 9:34 AM, Fred Baker (fred) wrote: >>> So the next logical thing to do would be to have the router default to >>> unicast Router Advertisements, measure the rate of received Router >>> Solicitations, and switch to multicast RA mode past a certain >>> threshold to cover this sort of situation. Once the number of RSes >>> falls, it switches back to unicast RA mode. >>> >>> That would get rid of the configuration knob proposed in this ID, and >>> is behaviour that I think could be universal for all link types, >>> rather than just for the case of wireless ones with mobile devices. >> If it were me implementing it, I think I would go about this in a little >> different way, hopefully simpler. I would want to send at most one (e.g., >> either zero or one) RA per some interval (a second?). In the normal case, >> that is sent unicast. However, having sent a unicast RA at time t, if I >> now receive another RS before t+1, I send the next one (at time t+1) as a >> multicast. > > First of all I support this document as a WG document. > > But in terms of implementation, isn't it simpler to always(*) respond to > a RS with a unicast RA? Yes. I did not respond on-list yet - but from operational perspective "always send solRA unicast" / "always send solRA multicast" definitely wins in my book, and I'd avoid premature optimizations (but maybe we can say the implementers are explicitly free to do their own optimizations if they see fit) That said, will be very interesting to hear data from folks who will run "all-unicast solRA", in real networks and then compare the effect of their proposal optimizations on their real-world scenarios. > As background, the text in RFC4861 comes from the old concern that all > devices might boot at the same time when the power is re-established > after a building power failure; that doesn't happen since most devices > (laptops, smartphones, IoT devices) have batteries today. In that case > it might have made sense to sending fewer RA messages by using multicast. > > (*) the only case in RFC 4861 when I think a multicast response might be > considered is when the source IPv6 address in the RS is the unspecified > address. Further, an implementation which rate limits received RS > packets (e.g., CoPP in a router) might also want to detect when the rate > limit might have dropped RS packets and multicast an RA in that case. > > > I do wonder why implementations haven't already changed to send unicast > solicited RA, and whether it would make a difference if we have an TBH that's my concern as well. I think we should tweak the text in 4861 to encourage a bit more consideration on the implementer's side. > informational document asking them to do this. Alternatively we could > have a proposed standard which updates section 6.2.6 to change the "MAY > unicast" to a "SHOULD unicast". Yeah, I actually have had the different text aimed for 6man, but Lorenzo's concern was 6man would say "there is no protocol update here, go away", so he rewrote it for v6ops. We should probably discuss this at the mic and get the opinion of the 6man chairs - if there is no outright "no" on this, a normative doc would be a better way to convince the implementers ? > > FWIW the draft incorrectly refers to section 6.2.4 instead of 6.2.6. Nice catch, thanks! --a > > Thanks, > Erik > >> >> >> _______________________________________________ >> 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 Tue Jul 21 02:36:12 2015 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 73E071A89EB for ; Tue, 21 Jul 2015 02:36:11 -0700 (PDT) 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 6uzeo19m0e6z for ; Tue, 21 Jul 2015 02:36:10 -0700 (PDT) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 040411A87F0 for ; Tue, 21 Jul 2015 02:36:10 -0700 (PDT) Received: by ykax123 with SMTP id x123so161064648yka.1 for ; Tue, 21 Jul 2015 02:36:09 -0700 (PDT) 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=P2ECDvXjr8VWa9Z+DFCapFDg1La3u97ZGAORoD4TNQg=; b=FtYaZSJqSuPZJ51liyL3V0WgTT+oIjP9tR/oCPn7HiS7X/NSSEy1qo4oLDC02lTQ6P B7FCgsAg6mLfnJsCisPlqmPRh0Ti+S6zOe5lf4HBV7FeQgTr+KD18TzUBvXDtk+3Y3Li yQL6AsBylHw5TMtMMC9HuhyvKu9ybQKfyFYO5MR6OvaH+q/sGy4fhEUBwXB11Eu47wsi 7iR0OeDaGxQqL4m3iSv1NS6Hm+aGiVplx4HRcJKUqDTaBvOGX8AUh0DoDSO5Ky7kXk6y fP8VIfPgWkEvZBnq8ua/xZ+j4sU8nExB+T2iwTaWWFjz39AtSDutU3KNMErT3ImjwYxw Wodw== 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=P2ECDvXjr8VWa9Z+DFCapFDg1La3u97ZGAORoD4TNQg=; b=KTYDTBaBlPG9p4AsQ+1vVKrBxHxsrM9VRU09FYs9CN1Bi3v9wyop0/q0gzyQLaC4iI RxU+st2aJmTH0asH+rePLLHK8mpUkZSY7nq74+ZRxDTmjBSpJMj5X++zgW52qP54G3gS a/r76h8Jd1WydxOZb9lUUI+xudbUhvreKizFaC2EWPUQp0SZ1UK7MsJJtv0oS2axqBhf NoixWR4i/SgSPrFpgBgBI10GJBaBlYzFcY7G9OSUnMamiGye95lKIen7XVchqKn+KfNA YBf7BHnSQ5kTqCC3BcX5pLznsSE9zsb2CR1pJ16TkNwegtSknr7rdh7vtKmtRtFQFWfn bFdg== X-Gm-Message-State: ALoCoQnOO/L29g/2sAZ/YgPZyUQ5YSiPwNHKOTH3ucq8H8kxlGC+/iBjn7KjqATQutpy2hOm4Z2s X-Received: by 10.170.43.193 with SMTP id 184mr32475280ykl.119.1437471369377; Tue, 21 Jul 2015 02:36:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.8.201 with HTTP; Tue, 21 Jul 2015 02:35:49 -0700 (PDT) In-Reply-To: <55AD3B64.5070400@acm.org> References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> <55AD3B64.5070400@acm.org> From: Lorenzo Colitti Date: Tue, 21 Jul 2015 11:35:49 +0200 Message-ID: To: Erik Nordmark Content-Type: multipart/alternative; boundary=001a11378f34591e53051b5f6284 Archived-At: Cc: "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" , v6ops list Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 21 Jul 2015 09:36:11 -0000 --001a11378f34591e53051b5f6284 Content-Type: text/plain; charset=UTF-8 On Mon, Jul 20, 2015 at 8:18 PM, Erik Nordmark wrote: > But in terms of implementation, isn't it simpler to always(*) respond to a > RS with a unicast RA? > It would be simpler to document, yes, but I don't know that we should make a one-size-fits all recommendation, because there might be link types or environments where this is more expensive. As background, the text in RFC4861 comes from the old concern that all > devices might boot at the same time when the power is re-established after > a building power failure; that doesn't happen since most devices (laptops, > smartphones, IoT devices) have batteries today. In that case it might have > made sense to sending fewer RA messages by using multicast. > This sort of thing can still happen. If lots of devices join at once, (e.g., if something happens at a large-scale event when hundreds of people pull their phones out of their pockets and turn them on at the same time), it may well be cheaper for the network to send one multicast RA. I'm not opposed to changing the standards as well, but I think respinning RFC 4861 would require much more careful consideration than simply publishing an operational guidance document such as this one. Perhaps we can just recommend in this document that 6man consider this operational need and consider modifying the protocol? --001a11378f34591e53051b5f6284 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jul 20, 2015 at 8:18 PM, Erik Nordmark <nordmark@acm.org>= wrote:
B= ut in terms of implementation, isn't it simpler to always(*) respond to= a RS with a unicast RA?

It would be simpler to document, yes, but I don't know that we should = make a one-size-fits all recommendation, because there might be link types = or environments where this is more expensive.

As background, the te= xt in RFC4861 comes from the old concern that all devices might boot at the= same time when the power is re-established after a building power failure;= that doesn't happen since most devices (laptops, smartphones, IoT devi= ces) have batteries today. In that case it might have made sense to sending= fewer RA messages by using multicast.
<= div>
This sort of thing can still happen. If lots of devices = join at once, (e.g., if something happens at a large-scale event when hundr= eds of people pull their phones out of their pockets and turn them on at th= e same time), it may well be cheaper for the network to send one multicast = RA.

I'm not opposed to changing the standa= rds as well, but I think respinning RFC 4861 would require much more carefu= l consideration than simply publishing an operational guidance document suc= h as this one. Perhaps we can just recommend in this document that 6man con= sider this operational need and consider modifying the protocol?
--001a11378f34591e53051b5f6284-- From nobody Tue Jul 21 02:38:42 2015 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 BEE051B2BC6 for ; Tue, 21 Jul 2015 02:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.3 X-Spam-Level: *** X-Spam-Status: No, score=3.3 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FSL_MY_NAME_IS=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 sdKbqvbove6s for ; Tue, 21 Jul 2015 02:38:39 -0700 (PDT) Received: from mailrelay22.naist.jp (mailrelay22.naist.jp [IPv6:2001:200:16a:50::91]) by ietfa.amsl.com (Postfix) with ESMTP id 316621A87F0 for ; Tue, 21 Jul 2015 02:38:39 -0700 (PDT) Received: from mailpost22.naist.jp (mailscan22.naist.jp [163.221.80.59]) by mailrelay22.naist.jp (Postfix) with ESMTP id 3CDF0101D for ; Tue, 21 Jul 2015 18:38:37 +0900 (JST) Received: from naist.jp (webmail21-a.naist.jp [163.221.80.53]) by mailpost22.naist.jp (Postfix) with ESMTP id 2836D101C for ; Tue, 21 Jul 2015 18:38:37 +0900 (JST) Received: from [127.0.0.1] (Forwarded-For: ::ffff:88.101.100.89) by webmail21-a.naist.jp (mshttpd); Tue, 21 Jul 2015 11:38:37 +0200 From: "GEORGESCU LIVIU MARIUS" To: v6ops@ietf.org Message-ID: <6b70808ed8b8.55ae2f3d@naist.jp> Date: Tue, 21 Jul 2015 11:38:37 +0200 X-Mailer: Oracle Communications Messenger Express 7.0.5.35.0 64bit (built Mar 31 2015) MIME-Version: 1.0 Content-Language: en X-Accept-Language: en Priority: normal In-Reply-To: <6b90c0438a9b.55ae125b@naist.jp> References: <6bc0a7cad94b.55ae1063@naist.jp> <6b60a266b1be.55ae10a4@naist.jp> <6c008646d9c6.55ae10e1@naist.jp> <6b70d62cc7d4.55ae111f@naist.jp> <6b70ec8ff3c6.55ae115e@naist.jp> <6b60bc74fb89.55ae119d@naist.jp> <6c00c7c8a2f3.55ae11db@naist.jp> <6c30ef8caa58.55ae121d@naist.jp> <6b90c0438a9b.55ae125b@naist.jp> Content-Type: multipart/alternative; boundary="--5df6e7fc41742bc358" X-TM-AS-MML: No X-TM-AS-Product-Ver: IMSS-7.1.0.1392-8.0.0.1202-21692.004 X-TM-AS-Result: No--4.395-5.0-31-10 X-imss-scan-details: No--4.395-5.0-31-10 X-TMASE-MatchedRID: gy3+2pVsCzk7MwFDNigBPl4t42nqFS2wUVgiFITrCuDfzk9HCNclHyjE 4qI6P7a+yNkakgF4d95vq25H9uAt2PqZGJlZc2fLRfmFzyKgHb4RfjliohTl1A1qiBJ7H03Vw12 cUqFAgv414qQM/4tPGy5GHw/w3ZCyzWJ/C6Qvs59Q3OD8q9D1sCZwbAOvTT7qOZKSAowPGEb3nG au2W+h9j9Q4rCkf3uUL4+sB3yBscmdNwtHz5PMSqMLUT/MIQiv7KBBZ2QBUyzDy0IrzE3/OR7QG FLhq2nncEtyVJvCz8WeAiCmPx4NwGmRqNBHmBve1B0Hk1Q1KyK9sWt6j5RrVfAXcWxgcD5yfAyG RKH7r8b6C0ePs7A07bq2gGRAFp5A5aoa4TO0B6uyrzvwbfEq8zgbzx5YPVQ3aorxYRE/bHT0WHH P/2Op7EmeLqk27VpEdX+nqP7c+E5EkEiExzREFX5t5eqOd1+CetkGeSswqiAF7N7DYyuaZUijg7 hf4xtUESZGAQBEwuSKzIF+biimZytfwz/h9PQLCvyeVgu3P5xMOM5BzG9izH5CgMCM7W1O Archived-At: Subject: [v6ops] Benchmarking Methodology for IPv6 Transition Technologies I-D 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, 21 Jul 2015 09:38:40 -0000 This is a multi-part message in MIME format. ----5df6e7fc41742bc358 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello v6ops members=2C My name is Marius Georgescu=C2=A0and I have been working on a draft aimi= ng to benchmark the performance of IPv6 transition technologies under di= fferent implementations=2C namely=C2=A0https=3A//tools=2Eietf=2Eorg/html= /draft-georgescu-bmwg-ipv6-tran-tech-benchmarking-01=C2=A0=2E The draft = has been discussed so far in the Benchmarking Working Group (BMWG) start= ing IETF91=2E If time allows you=2C I would really appreciate your feedb= ack on this document=2E Best regards=2C Marius Georgescu (=E3=83=9E=E3=83=AA=E3=82=A6=E3=82=B9 =E3=82=B8=E3=83=A7=E3=83= =AB=E3=82=B8=E3=82=A7=E3=82=B9=E3=82=AF) = Internet Engineering Laboratory = = Nara Institute of Science and Technology = = mailto=3A liviumarius-g=40is=2Enaist=2Ejp = = IPv6NET Project=3A http=3A//www=2Eipv6net=2Ero/ ----5df6e7fc41742bc358 Content-Type: text/html; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello v6ops members=2C=3Cdiv=3E=3Cbr /=3E=3C/div=3E=3Cdiv=3EMy name is M= arius Georgescu=C2=A0and I have been working on a draft aiming to benchm= ark the performance of IPv6 transition technologies under different impl= ementations=2C namely=C2=A0=3Ca href=3D=22https=3A//tools=2Eietf=2Eorg/h= tml/draft-georgescu-bmwg-ipv6-tran-tech-benchmarking-01=22=3Ehttps=3A//t= ools=2Eietf=2Eorg/html/draft-georgescu-bmwg-ipv6-tran-tech-benchmarking-= 01=3C/a=3E=C2=A0=2E The draft has been discussed so far in the Benchmark= ing Working Group (BMWG) starting IETF91=2E If time allows you=2C I woul= d really appreciate your feedback on this document=2E=3C/div=3E=3Cdiv=3E= =3Cbr /=3E=3C/div=3E=3Cdiv=3EBest regards=2C=3C/div=3E=3Cp class=3D=22Ms= oNormal=22=3E=3Ca name=3D=22=5FMailAutoSig=22=3E=3Cspan style=3D=22mso-a= scii-font-family=3A Calibri=3Bmso-fareast-font-family=3A=26quot=3BMS PGothic=26quot=3B=3Bmso= -hansi-font-family=3ACalibri=3B mso-bidi-font-family=3A=26quot=3BMS PGothic=26quot=3B=3Bcolor=3A=231F497= D=3Bmso-no-proof=3Ayes=22=3EMarius Georgescu =3C/span=3E=3C/a=3E=3Cspan style=3D=22mso-ascii-font-family=3A= Calibri=3Bmso-fareast-font-family=3A=26quot=3BMS PGothic=26quot=3B=3B mso-hansi-font-family=3ACalibri=3Bmso-bidi-font-family=3A=26quot=3BMS PG= othic=26quot=3B=3Bcolor=3A=231F497D=3B mso-no-proof=3Ayes=22=3E(=3C/span=3E=3Cspan lang=3D=22JA=22 style=3D=22f= ont-family=3A=26quot=3BMS Mincho=26quot=3B=3Bmso-bidi-font-family=3A=26q= uot=3BMS PGothic=26quot=3B=3B color=3A=231F497D=3Bmso-no-proof=3Ayes=22=3E=E3=83=9E=E3=83=AA=E3=82=A6=E3= =82=B9 =E3=82=B8=E3=83=A7=E3=83=AB=E3=82=B8=E3=82=A7=E3=82=B9=E3=82=AF=3C= /span=3E=3Cspan style=3D=22mso-ascii-font-family=3ACalibri=3B mso-fareast-font-family=3A=26quot=3BMS PGothic=26quot=3B=3Bmso-hansi-fon= t-family=3ACalibri=3Bmso-bidi-font-family=3A =26quot=3BMS PGothic=26quot=3B=3Bcolor=3A=231F497D=3Bmso-no-proof=3Ayes=22= =3E)=3Co=3Ap=3E=3C/o=3Ap=3E=3C/span=3E=3C/p=3E =3Cp class=3D=22MsoNormal=22=3E=3Cspan style=3D=22mso-ascii-font-family=3A= Calibri=3Bmso-fareast-font-family=3A=26quot=3BMS PGothic=26quot=3B=3B mso-hansi-font-family=3ACalibri=3Bmso-bidi-font-family=3A=26quot=3BMS PG= othic=26quot=3B=3Bcolor=3A=231F497D=3B mso-no-proof=3Ayes=22=3EInternet Engineering Laboratory =3Co=3Ap=3E=3C/o= =3Ap=3E=3C/span=3E=3C/p=3E =3Cp class=3D=22MsoNormal=22=3E=3Cspan style=3D=22mso-ascii-font-family=3A= Calibri=3Bmso-fareast-font-family=3A=26quot=3BMS PGothic=26quot=3B=3B mso-hansi-font-family=3ACalibri=3Bmso-bidi-font-family=3A=26quot=3BMS PG= othic=26quot=3B=3Bcolor=3A=231F497D=3B mso-no-proof=3Ayes=22=3ENara Institute of Science and Technology =3Co=3A= p=3E=3C/o=3Ap=3E=3C/span=3E=3C/p=3E =3Cp class=3D=22MsoNormal=22=3E=3Cspan style=3D=22mso-ascii-font-family=3A= Calibri=3Bmso-fareast-font-family=3A=26quot=3BMS PGothic=26quot=3B=3B mso-hansi-font-family=3ACalibri=3Bmso-bidi-font-family=3A=26quot=3BMS PG= othic=26quot=3B=3Bcolor=3A=231F497D=3B mso-no-proof=3Ayes=22=3Emailto=3A =3C/span=3E=3Ca href=3D=22mailto=3Aliv= iumarius-g=40is=2Enaist=2Ejp=22=3E=3Cspan style=3D=22mso-ascii-font-fami= ly=3ACalibri=3Bmso-fareast-font-family=3A=26quot=3BMS PGothic=26quot=3B=3B= mso-hansi-font-family=3ACalibri=3Bmso-bidi-font-family=3A=26quot=3BMS PG= othic=26quot=3B=3Bcolor=3Ablue=3B mso-no-proof=3Ayes=22=3Eliviumarius-g=40is=2Enaist=2Ejp=3C/span=3E=3C/a=3E= =3Cspan style=3D=22mso-ascii-font-family=3ACalibri=3Bmso-fareast-font-fa= mily=3A=26quot=3BMS PGothic=26quot=3B=3B mso-hansi-font-family=3ACalibri=3Bmso-bidi-font-family=3A=26quot=3BMS PG= othic=26quot=3B=3Bcolor=3A=231F497D=3B mso-no-proof=3Ayes=22=3E =3Co=3Ap=3E=3C/o=3Ap=3E=3C/span=3E=3C/p=3E =3Cdiv=3E=3Cspan style=3D=22color=3A rgb(31=2C 73=2C 125)=3B=22=3EIPv6NE= T Project=3A =3C/span=3E=3Ca href=3D=22http=3A//www=2Eipv6net=2Ero/=22=3E= =3Cspan style=3D=22mso-ascii-font-family=3ACalibri=3Bmso-fareast-font-fa= mily=3A =26quot=3BMS PGothic=26quot=3B=3Bmso-hansi-font-family=3ACalibri=3Bmso-b= idi-font-family=3A=26quot=3BMS PGothic=26quot=3B=3B color=3Ablue=3Bmso-no-proof=3Ayes=22=3Ehttp=3A//www=2Eipv6net=2Ero/=3C/s= pan=3E=3C/a=3E=C2=A0=3C/div=3E ----5df6e7fc41742bc358-- From nobody Tue Jul 21 02:48:16 2015 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 A6B8E1A8A10 for ; Tue, 21 Jul 2015 02:48:15 -0700 (PDT) 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 5CP9PPfpo5Xo for ; Tue, 21 Jul 2015 02:48:13 -0700 (PDT) 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 B28B21A87F0 for ; Tue, 21 Jul 2015 02:48:13 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 88A2562CA4 for ; Tue, 21 Jul 2015 11:48:11 +0200 (CEST) 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 3C6C560AB2 for ; Tue, 21 Jul 2015 11:48:11 +0200 (CEST) Received: (qmail 54302 invoked by uid 1007); 21 Jul 2015 11:48:11 +0200 Date: Tue, 21 Jul 2015 11:48:11 +0200 From: Gert Doering To: Lorenzo Colitti Message-ID: <20150721094811.GB90924@Space.Net> References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> <55AD3B64.5070400@acm.org> 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 list , "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 21 Jul 2015 09:48:15 -0000 Hi, On Tue, Jul 21, 2015 at 11:35:49AM +0200, Lorenzo Colitti wrote: > This sort of thing can still happen. If lots of devices join at once, > (e.g., if something happens at a large-scale event when hundreds of people > pull their phones out of their pockets and turn them on at the same time), > it may well be cheaper for the network to send one multicast RA. I've been told that on a *Wifi* network, multicast never comes cheap (so in the end your AP might just turn the multicast RA into unicast-to-all-stations anyway). So I find that particular argument less than convincing. 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 Jul 21 02:51:14 2015 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 185F41B2C73 for ; Tue, 21 Jul 2015 02:51:12 -0700 (PDT) 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, 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 Q491B4WHd8Ou for ; Tue, 21 Jul 2015 02:51:11 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001: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 0E5721B2C97 for ; Tue, 21 Jul 2015 02:51:11 -0700 (PDT) Received: by ietj16 with SMTP id j16so137989784iet.0 for ; Tue, 21 Jul 2015 02:51:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=QzIApqBYNgfC+Avpw6O4+e29x3v0y3Gaoj1NIcNUons=; b=ha+qumOTjVEzVNZ7iwHaAOqDJ2Ze/8GzdCPbPBQHQ6x8N6p2UisJTjEH01Ja71ExEJ 4s13iKikR9GGv/IDVCRMYougfTH3kZdVe+/PUOHYUJEhNl9b+y5flTTmDmKWHPk+m4Zz o5YkZz2OWA9xRBJopjE0pf5jHszVQdOGThDbzatLEqG9S6m5zyrZOcz//Jni9uFlmFs8 D4FCcTXZoW+F/j0WzJxsFL+zjD0fyytv/8GLtKkWc5z74ruwG8nvm0k7zwSBk05YKMBa VbHVWAywV8/xC88OmnNnOEotzKHHYkgqcNc8Or3yYHXoLZclpt5o37/bvGaDmtMwjbIL Qb9g== X-Received: by 10.50.93.33 with SMTP id cr1mr7098414igb.35.1437472270495; Tue, 21 Jul 2015 02:51:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.169.143 with HTTP; Tue, 21 Jul 2015 02:50:40 -0700 (PDT) In-Reply-To: References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> <55AD3B64.5070400@acm.org> From: Mark Smith Date: Tue, 21 Jul 2015 19:50:40 +1000 Message-ID: To: Lorenzo Colitti Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: v6ops list , "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 21 Jul 2015 09:51:12 -0000 On 21 July 2015 at 19:35, Lorenzo Colitti wrote: > On Mon, Jul 20, 2015 at 8:18 PM, Erik Nordmark wrote: >> >> But in terms of implementation, isn't it simpler to always(*) respond to a >> RS with a unicast RA? > > > It would be simpler to document, yes, but I don't know that we should make a > one-size-fits all recommendation, because there might be link types or > environments where this is more expensive. > >> As background, the text in RFC4861 comes from the old concern that all >> devices might boot at the same time when the power is re-established after a >> building power failure; that doesn't happen since most devices (laptops, >> smartphones, IoT devices) have batteries today. In that case it might have >> made sense to sending fewer RA messages by using multicast. > > > This sort of thing can still happen. If lots of devices join at once, (e.g., > if something happens at a large-scale event when hundreds of people pull > their phones out of their pockets and turn them on at the same time), it may > well be cheaper for the network to send one multicast RA. > Actually I've witnessed these sorts of events in recent times - when 1000s or 10s of 1000s of residential broadband subscribers come back on-line after the BRAS/BNG has booted either due to failure or maintenance, or the backhaul infrastructure between the BRAS/BNG and subscribers has failed and recovered. Unicast RAs in the specific scenarios I've seen it in though may not have helped, as the subscribers were attached via individual PPPoE sessions, so multicasting a single RA to many/all of them efficiently might not be possible, unless there was some fancy hardware/firmware that meant the control plane didn't have to do it. However, if single link/multi-access methods of attaching subscribers are used e.g., TR-101 N:1 VLAN, then solicited multicast RAs would help significantly reduce the number of multicast RSes from CPE during these events. > I'm not opposed to changing the standards as well, but I think respinning > RFC 4861 would require much more careful consideration than simply > publishing an operational guidance document such as this one. Perhaps we can > just recommend in this document that 6man consider this operational need and > consider modifying the protocol? From nobody Tue Jul 21 03:47:00 2015 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 42E331A0021 for ; Tue, 21 Jul 2015 03:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, 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 zxOCvmEqhcxn for ; Tue, 21 Jul 2015 03:46:58 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 231B21A001A for ; Tue, 21 Jul 2015 03:46:57 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 4FB3861CA; Tue, 21 Jul 2015 03:46:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=IEpVBHMXT1iwE/k+Xat9Ux4WHxQ=; b= gzZOYLM4aizf4XdKC20VzdKYWMX5Hu6XTEMPleeGauB95ztlmJ84ql5LlERHFUaQ e97Ib/MEC/9zcLNgvicsrP1GzQuV4570ioT476SwEOAz1GfArPDQK1rf1kAzEVl4 ZdHRpA/wqurUjvxm+OchH0CmltLMIz5JY5NqNIs/8iM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=mnV53KDFvI4EcoZ71ocLMaVvhC dPu0uau3GFVD1x/pxQ0yFnaaBZEJCIDzsJnkjXw4MGJh0TlbV7QficOXVr75HCtl EEexBujPFwfAkgswZMEnRvOIR391jBiELtM5d45LoCkyNFbgP4/9a2Na5yZzrtlj VS3xQp/prmrPu8sjs= Received: from gomlefisk.localdomain (dhcp-aa75.meeting.ietf.org [31.133.170.117]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 0B6AA61C9; Tue, 21 Jul 2015 03:46:56 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by gomlefisk.localdomain (Postfix) with ESMTP id 5CEC74967B8E; Tue, 21 Jul 2015 12:47:12 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Content-Type: multipart/signed; boundary="Apple-Mail=_AB9E6B76-B00F-40AE-B800-DABEBE677289"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5 From: Ole Troan In-Reply-To: <55AD3B64.5070400@acm.org> Date: Tue, 21 Jul 2015 12:47:11 +0200 Message-Id: References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> <55AD3B64.5070400@acm.org> To: Erik Nordmark X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" , v6ops list Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 21 Jul 2015 10:46:59 -0000 --Apple-Mail=_AB9E6B76-B00F-40AE-B800-DABEBE677289 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > But in terms of implementation, isn't it simpler to always(*) respond = to a RS with a unicast RA? > As background, the text in RFC4861 comes from the old concern that all = devices might boot at the same time when the power is re-established = after a building power failure; that doesn't happen since most devices = (laptops, smartphones, IoT devices) have batteries today. In that case = it might have made sense to sending fewer RA messages by using = multicast. in addition to Mark=E2=80=99s points. - what happens when the router reboots, will not all the hosts then try = to actively reconnect? that router could server thousands of users. - while this is intended for WIFI networks, in common deployments the = WIFI interface is not integrated in the router. for the router=E2=80=99s = perspective this just looks like another wired interface. either this = has to be made configurable and not the default, or considerations of = large flat wired L2 networks must also be considered. cheers, Ole --Apple-Mail=_AB9E6B76-B00F-40AE-B800-DABEBE677289 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 - https://gpgtools.org iQIcBAEBCgAGBQJVriMwAAoJEL7aWKiYQt92I1cP/Ry3WmCY1+rw/jC2ulgHOJ8j SjfSJGmpRnoxQFKDNpZF1ETmhbcfxP02rsHM0HztzGTQmdtjNNMetWcV5q9mpaPK /kbsjVoR2XFB4gHWeyQMfunP65PaJMwZXQ9iO+j7d/NglQ1jRMmPk6V7yJKCLMOy O0QE5elvhpbZnhsTR0nz3SWhfisU5R3kIN+ihVejmSXayXanJqXLSJguaw8G2FPL 2nQyeywa6xivcQgPGsE9apXqJWVU4fTVEQe+yRi63dEW6ZiryI6DiqHvRFb0xWAp /+oh9TU3Ovrl5Q0wigz902Sop+/tJP1uvIRn68bREgLI83znMbdO3cseTI69u50r /WvFHWMf3UUjnnKZLGo2LK+P9W3QW8dnzuas4A3+b+nrw0TWAAjrYIjaVGz4d7kZ MMD9ZJFKFWMnRBZTDY0ZfrgbmM7LMHQT6i0Vws+GlnW90ndVM1Gjt7mTRsZ066pB BLTnzdlLYO6AORjmAoN0DyrH6LnbkC7BMueOPVRh/PikRD8601fygilV+DXC+d6l oAbVmfkQkHk+KIgnxebN0htOFMijSW2U/y7S6Apzyi1TmqQQBtCnvpSjp1x6q4VN 9Dz/MeoCux2Rd4bRcbTlhqEvkMqIA5zYxgd9dpY360vuj3yCmDBvD0Qkw90e8mpz w9NG5VE2ybzaCzzwxATS =4f1I -----END PGP SIGNATURE----- --Apple-Mail=_AB9E6B76-B00F-40AE-B800-DABEBE677289-- From nobody Tue Jul 21 04:03:02 2015 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 7086F1A00A8 for ; Tue, 21 Jul 2015 04:03:01 -0700 (PDT) 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 ln4JDovmMYtP for ; Tue, 21 Jul 2015 04:03:00 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c: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 74E271A00A4 for ; Tue, 21 Jul 2015 04:02:57 -0700 (PDT) Received: by wgkl9 with SMTP id l9so152855722wgk.1 for ; Tue, 21 Jul 2015 04:02:56 -0700 (PDT) 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=3Lc6mIjLZbj8jHqrVoBaLNqm/2E6LXvHLfYXUIF4jXU=; b=ffKtjV6q8TIyVP4cXaJP+1AhG4zH+JOK5TpSHFnXozjXSwE3Ovd27vF2mpxMm1RxWe avZszY800ylfMqg7/hhIvOee8cDbJ1OUvZ/raEw5v/Bvf6QjAKFxgKNqv0ascYdSRymD i4TFn31jGJnqVEuvc2dBP+2N/yD/t3IHk7YZ5Hd+Qkdh6qlPBZIORc8jjbdkl41d3WiF JeTpDle59RLNqflrBEl/35C8mS8Sx5elQS5ckvOACyGqwSawGS3JGwywlEvAKTmhYh2i H8C/TiUeLyWzCppWrjKa4qnltoyCZAp6IYjoqac4msIwwcD7Zp/cBnceXRGiSwlv6Y8d Vtnw== 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=3Lc6mIjLZbj8jHqrVoBaLNqm/2E6LXvHLfYXUIF4jXU=; b=MAdRijJ6WtAZysRFXWwagrFGkmYAzihxeQUtzXnnLunMXI5z+3DA3UTc5hVb3m9Fq3 A+0PnQNdWkOfvy5xkBbWpyTH7CS7pGOiq70fd8Ew06YEF3ilQesRonfpdBCmAx3wNbBL +0exOsp2f2O3657AHAZ4uBsD0Je4NWl5RSxkJ77tH4PiBkLoekzWxt0Gn+oT60eb3ajj nsWhFLzfuhXaNukRhNlzC2xEFSn4h5iYaXn700tf+XwVzE9yC6AD7GrVDzPwXwx4+QF+ KfGomSx5Mnyb/UL1tRO/id8omLcaf8HKh6QUtNDF4aA3TdTH9STDoq6cU2rBR7vhXzS+ 7Zkw== X-Gm-Message-State: ALoCoQn+Ho9HBQaZJ72AhvBb1LV1ZzzRz+GZjosXjTqD3vxz5y6P48NyhXYY4zyXLRaoYyln5vW8 X-Received: by 10.180.76.193 with SMTP id m1mr30322236wiw.11.1437476576209; Tue, 21 Jul 2015 04:02:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.138.203 with HTTP; Tue, 21 Jul 2015 04:02:34 -0700 (PDT) In-Reply-To: References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> From: Erik Kline Date: Tue, 21 Jul 2015 13:02:34 +0200 Message-ID: To: "Sri Gundavelli (sgundave)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" , v6ops list Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 21 Jul 2015 11:03:01 -0000 On 20 July 2015 at 22:34, Sri Gundavelli (sgundave) wrote: > Did you guys look at RFC-6085 ? We published this clarification mainly to > support per-MN prefix model on shared links, by the use of L2 unicast RA's. > Is that not sufficient ? http://tools.ietf.org/html/rfc6085 seems useful and it should be referenced. But I would not say it's sufficient, if only from an "explicit clarity" standpoint. I think explicit mention of RAs and the other discussion is helpful for implementors not inclined to dig to great depths or just seeking explicit confirmation. From nobody Tue Jul 21 04:16:50 2015 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 B40231A00B0 for ; Tue, 21 Jul 2015 04:16:49 -0700 (PDT) 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 LmDkb1LkQ10h for ; Tue, 21 Jul 2015 04:16:48 -0700 (PDT) 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 C38031A0099 for ; Tue, 21 Jul 2015 04:16:47 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id DFE5962CA3 for ; Tue, 21 Jul 2015 13:16:45 +0200 (CEST) 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 A6EB460140 for ; Tue, 21 Jul 2015 13:16:45 +0200 (CEST) Received: (qmail 62114 invoked by uid 1007); 21 Jul 2015 13:16:45 +0200 Date: Tue, 21 Jul 2015 13:16:45 +0200 From: Gert Doering To: Ole Troan Message-ID: <20150721111645.GD90924@Space.Net> References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> <55AD3B64.5070400@acm.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AJu7IxIPovG6hMTN" 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 , "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 21 Jul 2015 11:16:49 -0000 --AJu7IxIPovG6hMTN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Jul 21, 2015 at 12:47:11PM +0200, Ole Troan wrote: > - what happens when the router reboots, will not all the hosts then try = to actively reconnect? Sending periodic unsolicited multicast RAs sounds still useful, like "at bo= ot" or "interface down/up events"... 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 --AJu7IxIPovG6hMTN Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVa4qHd9WwGXkzn/FAQJPcxAAr6sJ4+pchmyQO0m7YphcK4S6wadC9T1A bNDKGDVy7k8PLIlQ2J4KDYJr16JH4tjrnDX3ZWlbp/q/pyY+056ctRG+Vbty15DU 0jWVwqBnqW1Ih5nW0LFhQSZC46mQ4fh1NU6o8FwiV9ACM0P1VgDg/CcNLhP0HvqB pze3Z93HQQHF8mdifRNCskCr8EVsC9yv4JiERSKcv7cqkKrW2hRm2QjFuSaokgKv CKtp18GnTusAB9aCoIxsoTE9pDTM6qU7IgW2XTK1ywnc7Wul6YyHhRFPURKzqO0F rszM3KTifEaNFPNrnFCaw9iirmhWN1couQonmS2dxVPT/QYNvkSPoeQi8DzknD+S t/cEj9LiyNyoHV/RxYVpmmCIokpPTNG9JwvY93y+CiApqtKhK1toR+SzQukeLYsH aU4PB09NfA8c5UWNs9mUvm93sBd0UOxFjSpUGePLB1ogtZ1n9Om29VNofs/9Cc1w 2u9iZAl88E9+Uiqk5YzX50IJi07pREl7XKfDNNFYjlDFnm2e4EW8ugTLAyFb79d1 PDGwi5ewHdpZX/4lNMA1hZjuXauanCK9mffsznPosp1lL4pZp9obPKDj+ixuuUQC QYmA3r7Na96RkVvVw/MQi2mVBvsc20IL8AUyfKxshqzPoCUrbc0z688KRfgtiGH1 w6yeWDFd+CE= =NUwW -----END PGP SIGNATURE----- --AJu7IxIPovG6hMTN-- From nobody Tue Jul 21 04:25:51 2015 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 82E9C1A00B2 for ; Tue, 21 Jul 2015 04:25:49 -0700 (PDT) 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, 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 h10hHsLEB-nN for ; Tue, 21 Jul 2015 04:25:48 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::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 61E421A004C for ; Tue, 21 Jul 2015 04:25:48 -0700 (PDT) Received: by ietj16 with SMTP id j16so139664914iet.0 for ; Tue, 21 Jul 2015 04:25:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=oiNjv5FgkBKNb63xNFFvr93RcNafvaUgcNPVgfJDmy4=; b=oCuNH3Sm4vnUJUdb6Bq6D6gjWenfabSD2MIFLK7BJlWGmyAuMZpIodYMp1KCkMSgie WmoOZd6DYqU581D5UE03yZ6ePF0+/G3FPs/evYLdWkvEEqOp+n8J8IvadwKT3/vPpmbi 4STg+QyiOrd7R7hHoBkaLe92MblqZ7GeN3v9tmrYAY4KYk1StRO8EJryk9beBxOkaMNw QwfwBqIaxrxy9pHRb+jUJYlQ5hS12vzGWxUUFwhOAaYfZmPPEYU4WApA1KyoMAk0foU6 dk6iy8vTFtFg8l3s8gAAJZUWwGlb9y7Pc5aVUYNL9jn+qYbJaXzNKpliYvwmIIaSw03k 2wKg== X-Received: by 10.50.3.6 with SMTP id 6mr21701908igy.28.1437477947798; Tue, 21 Jul 2015 04:25:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.169.143 with HTTP; Tue, 21 Jul 2015 04:25:18 -0700 (PDT) In-Reply-To: References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> From: Mark Smith Date: Tue, 21 Jul 2015 21:25:18 +1000 Message-ID: To: Erik Kline Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" , v6ops list Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 21 Jul 2015 11:25:49 -0000 On 21 July 2015 at 21:02, Erik Kline wrote: > On 20 July 2015 at 22:34, Sri Gundavelli (sgundave) wrote: >> Did you guys look at RFC-6085 ? We published this clarification mainly to >> support per-MN prefix model on shared links, by the use of L2 unicast RA's. >> Is that not sufficient ? > > http://tools.ietf.org/html/rfc6085 seems useful and it should be referenced. > I thought that could be an option, however I encountered RSes without the Source Link Layer Option, which means if RFC6085 is to be used, the link-layer header has to be available to get the source link-layer address from. After I wondered about the efficiency benefit of using multicasts for solicited RAs, Fred asked me to do some testing/investigation. I wrote up what I found here, the few unusual RS cases I saw the following, which I put down some thoughts about handling via e.g., RFC6085. o RSes with a :: source address o RSes with a link-local source addresses, but no Source Link-Layer Address Option https://www.ietf.org/mail-archive/web/v6ops/current/msg22464.html https://www.ietf.org/mail-archive/web/v6ops/current/msg22464.html > But I would not say it's sufficient, if only from an "explicit > clarity" standpoint. I think explicit mention of RAs and the other > discussion is helpful for implementors not inclined to dig to great > depths or just seeking explicit confirmation. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Jul 21 04:38:17 2015 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 D7C111A0364 for ; Tue, 21 Jul 2015 04:38:15 -0700 (PDT) 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 qdtijD7hB-Gw for ; Tue, 21 Jul 2015 04:38:14 -0700 (PDT) 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 AEB4E1A01AA for ; Tue, 21 Jul 2015 04:38:14 -0700 (PDT) Received: by ykdu72 with SMTP id u72so162675834ykd.2 for ; Tue, 21 Jul 2015 04:38:14 -0700 (PDT) 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=BPoW84hrsFwWXaDo26kV7dpej8luz+5uDBuPv4xhoQo=; b=LWc9ZtOhNBvGbOtUSNBNWRMelWYZiQAOpj/EKuqS6xxLf8u9KcQoX+huitBo93T8PO 928/Dxf/f427zR0dYG9QsSBh4ntOGaw1skdz+nWfyIx8mBuHx/emqZxEaeHvHtVZneUx kGRr0AqqrwoGPu0IRKwigfn0ZKcN4AZyXec5TU7SP1JJx9F+CQgbRVDVnmeT3vcUUAEl IBUyTm9396KJpFAqZQqMQgN5xsQvzF2pYT13HZtEfRQsVlfnfu+1SSTAd0b8YonnGG5J 8dM4UQLAtJT/lZRjg6NdVRaDI7r3wWC8q8wsRRPoK8U0BryODbZzl9oALR5Ps5VBVZb0 kvEA== 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=BPoW84hrsFwWXaDo26kV7dpej8luz+5uDBuPv4xhoQo=; b=UOCWmk3QtdbE4F/v11Bps4bdNRU9FOILBu3mN9uYqZ4wuhIYGIyK2LN1UhFgSPUzxj m3Y6qVafQLVIY97YiG3UQa2/UfgZZAH+KHAMiCgAKE6aXbn8MCv73Pu7CePuFfcD1lHe j9inZffkqMiVQzND0J3Gjt6ckqvrHKPfEXOJk81KmBCsh9Eqjvy4ZiDHUUImNkJtEM5u LnBMJyLwG8IS6HKbhafOltpbeFWB2ZnDm8cZ2y4QjaXGYJAU0ifgWG/sirqq2VdJ8SsS SEN6szjZKMBIl8rYe+fdOygAH3tb2Qdbw9lidtqu89wb4rHyJSOGCXoHjAeZ0Xt6tpR2 E9qQ== X-Gm-Message-State: ALoCoQmPylE7qFLaCgQ/IoXNnxcQmWv9kq2vEpba+Cqmp2nnZ26i6Jz0eGiN4+vn9CZV5KzPlX0C X-Received: by 10.13.255.2 with SMTP id p2mr15815467ywf.149.1437478693992; Tue, 21 Jul 2015 04:38:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.8.201 with HTTP; Tue, 21 Jul 2015 04:37:54 -0700 (PDT) In-Reply-To: References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> <55AD3B64.5070400@acm.org> From: Lorenzo Colitti Date: Tue, 21 Jul 2015 13:37:54 +0200 Message-ID: To: Ole Troan Content-Type: multipart/alternative; boundary=94eb2c0888f6edd3cf051b6116de Archived-At: Cc: "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" , v6ops list Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 21 Jul 2015 11:38:16 -0000 --94eb2c0888f6edd3cf051b6116de Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jul 21, 2015 at 12:47 PM, Ole Troan wrote: > - what happens when the router reboots, will not all the hosts then try > to actively reconnect? > It depends on whether the router is also the wifi access point. In general, in the large wifi networks to which this draft is targeted, that is not the case. > - while this is intended for WIFI networks, in common deployments the > WIFI interface is not integrated in the router. for the router=E2=80=99s > perspective this just looks like another wired interface. either this has > to be made configurable and not the default, or considerations of large > flat wired L2 networks must also be considered. > The router wouldn't need to know this, only the network administrator. If the network administrator knew that a particular interface was providing service to a network with a large number of mobile nodes, then the administrator could configure that interface to send solicited RAs unicast. --94eb2c0888f6edd3cf051b6116de Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 21, 2015 at 12:47 PM, Ole Troan <otroan@employees.org> wrote:
=C2=A0- what happens when th= e router reboots, will not all the hosts then try to actively reconnect?

It depends on whether the router is also = the wifi access point. In general, in the large wifi networks to which this= draft is targeted, that is not the case.
=C2=A0
=C2=A0- while this is intended for WIFI networks, in co= mmon deployments the WIFI interface is not integrated in the router. for th= e router=E2=80=99s perspective this just looks like another wired interface= . either this has to be made configurable and not the default, or considera= tions of large flat wired L2 networks must also be considered.

The router wouldn't need to know this, only the= network administrator. If the network administrator knew that a particular= interface was providing service to a network with a large number of mobile= nodes, then the administrator could configure that interface to send solic= ited RAs unicast.
--94eb2c0888f6edd3cf051b6116de-- From nobody Tue Jul 21 04:41:13 2015 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 63E6D1A016C for ; Tue, 21 Jul 2015 04:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvKcLlPDAhce for ; Tue, 21 Jul 2015 04:41:10 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450: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 166CA1A00A1 for ; Tue, 21 Jul 2015 04:41:10 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so117940069wib.0 for ; Tue, 21 Jul 2015 04:41:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=E0Wppg98TvYTR9PUjkAz56L0nrBcFraJ75xcYGk5Yf8=; b=Px/sHmGRCUSHYRIpuyFKkUaOnAWWEwr4Q7vJnm4j/5DOSp1EoTdoJbdzpkosZE/DDz WdDmHnreHc36QpqAKEI55avI2hXBGScCvgtPtO5StBs0kuy0pIB/Bu/MtlI1RNE9Jbpg asOxNgCdvEruBXxHlpfqDMYwe0COsIb4USH0SUP3Z06hp0VShzCrPQ9KpChU/NVKFm0I TEhiUQxP5NWTXRIgrNFp1FJoN0aV4Q7LD25ztGiK/SG4P9IuyHAe/Y3M0T0htm5c8HmI KoydQGEOGEHyhpHL8hRxShgk4srkMnPP0hVLoIG7saqV5qdXB2rnfDygm+uhh2eVsPNm xAyQ== X-Received: by 10.180.75.78 with SMTP id a14mr30919607wiw.43.1437478868848; Tue, 21 Jul 2015 04:41:08 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:28cc:dc4c:9703:6781? ([2001:67c:370:176:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id eu2sm16431773wic.8.2015.07.21.04.41.07 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Jul 2015 04:41:07 -0700 (PDT) Message-ID: <55AE2FD6.4060405@gmail.com> Date: Tue, 21 Jul 2015 23:41:10 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: IPv6 Operations Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [v6ops] draft-ietf-v6ops-design-choices-08 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, 21 Jul 2015 11:41:11 -0000 In section 2.1.1. Choice of Addresses in the Core > For an enterprise, the use of private address space is > reasonable, but the enterprise will need to use NAT44 and/or > NPT[RFC6296] on links to the Internet. If the network has no > connection to the Internet, then obviously this is not a problem. Try For an enterprise, the use of private address space is reasonable. In the case of IPv4 [RFC1918] the enterprise will need to use NAT44. In the case of IPv6 ULA addresses [RFC4193], the preferred solution is to use private addresses only for internal traffic. Hosts requiring external connections should be given normal PA or PI addresses as well as ULA addresses. If the network has no connection to the Internet, then obviously this is not needed. The experimental mechanism Network Prefix Translation [RFC6296] is not recommended. Regards Brian From nobody Tue Jul 21 05:35:05 2015 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 9505B1A0406 for ; Tue, 21 Jul 2015 05:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 X-I8NrdRUA9W for ; Tue, 21 Jul 2015 05:35:01 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id EA2EA1A1A43 for ; Tue, 21 Jul 2015 05:35:00 -0700 (PDT) Received: from [IPv6:2001:67c:370:176:396c:eaca:24f3:f201] (unknown [IPv6:2001:67c:370:176:396c:eaca:24f3:f201]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 02A205408D1; Tue, 21 Jul 2015 08:33:21 -0400 (EDT) From: Jared Mauch Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Jul 2015 08:33:21 -0400 To: "v6ops@ietf.org WG" Message-Id: <1847F15E-ADF6-41D2-BEDA-EDD212705CA0@puck.nether.net> Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3067\)) X-Mailer: Apple Mail (2.3067) Archived-At: Subject: [v6ops] draft-yc-v6ops-solicited-ra-unicast-00/ipv6 nd ra solicited unicast 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, 21 Jul 2015 12:35:02 -0000 Regarding: = https://tools.ietf.org/html/draft-yc-v6ops-solicited-ra-unicast-00 Does anyone know if/when this support appeared in IOS-XR? It does not = appear to be there.. RP/0/RSP0/CPU0:Router(config-if)#ipv6 nd ra ? - Jared= From nobody Tue Jul 21 05:38:44 2015 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 507F91A1B83 for ; Tue, 21 Jul 2015 05:38:35 -0700 (PDT) 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 MkLcvc7KpTvV for ; Tue, 21 Jul 2015 05:38:34 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFEE1A1B6E for ; Tue, 21 Jul 2015 05:38:34 -0700 (PDT) Received: by puck.nether.net (Postfix, from userid 162) id BF6F35408CF; Tue, 21 Jul 2015 08:38:33 -0400 (EDT) Date: Tue, 21 Jul 2015 08:38:33 -0400 From: Jared Mauch To: "v6ops@ietf.org WG" Message-ID: <20150721123833.GA5337@puck.nether.net> References: <1847F15E-ADF6-41D2-BEDA-EDD212705CA0@puck.nether.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1847F15E-ADF6-41D2-BEDA-EDD212705CA0@puck.nether.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [v6ops] draft-yc-v6ops-solicited-ra-unicast-00/ipv6 nd ra solicited unicast 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, 21 Jul 2015 12:38:35 -0000 On Tue, Jul 21, 2015 at 08:33:21AM -0400, Jared Mauch wrote: > Regarding: https://tools.ietf.org/html/draft-yc-v6ops-solicited-ra-unicast-00 > > Does anyone know if/when this support appeared in IOS-XR? It does not appear to be there.. > > RP/0/RSP0/CPU0:Router(config-if)#ipv6 nd ra ? Baah, insufficent output in paste. hoplimit IPv6 ND RA hoplimit mtu IPv6 ND RA mtu option configuration -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From nobody Tue Jul 21 05:42:38 2015 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 D64CE1A1BFA for ; Tue, 21 Jul 2015 05:42:36 -0700 (PDT) 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 C5fXOxHq4jW5 for ; Tue, 21 Jul 2015 05:42:35 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F3F41A1BC2 for ; Tue, 21 Jul 2015 05:42:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1456; q=dns/txt; s=iport; t=1437482538; x=1438692138; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=jyugXg56QbrNPkmKolcKhea9wKLcqbOWlPb4X47+NjU=; b=ZhWABI81xWWzuVAGzkxK8eDubPacJa6agOgzNf+YgEKb7PYHTcyGyAZu BlH33CWbqas647LNV1D4qmn8U9xRga9Yh2MRsk1pyC3sxmy3WGb+PoT7e AZS79U/igmaU+lKDc/NsRFosrA26805u1dzc+Z+ViOsXstlty+cYzuk07 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AcAwCAPa5V/5RdJa1cgxOBPQa8CAmHdgKBOjgUAQEBAQEBAYEKhCMBAQEEOj8MBAIBCBEEAQELFAkHMhQJCAIEAQ0FCIgmykEBAQEBAQEBAQEBAQEBAQEBAQEBAQEXi0yEVTEHBoMRgRQBBJRTAaU3JoN8b4FHgQQBAQE X-IronPort-AV: E=Sophos;i="5.15,516,1432598400"; d="scan'208";a="13584728" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-6.cisco.com with ESMTP; 21 Jul 2015 12:42:17 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t6LCgHlg029101 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jul 2015 12:42:17 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.34]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Tue, 21 Jul 2015 07:42:17 -0500 From: "Hemant Singh (shemant)" To: Mark Smith , Lorenzo Colitti Thread-Topic: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast Thread-Index: AQHQuKqsqRfQEspPAk2owBq9mqkZ5Z3S7TQAgAAIUgCACywkgIAAAjWAgAAPdoCAAAingIABbHSAgAVq7ACAAQBhgIAABCYA///a+0A= Date: Tue, 21 Jul 2015 12:42:16 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B89168BB2C4@xmb-rcd-x06.cisco.com> References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> <55AD3B64.5070400@acm.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.243.174] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" , v6ops list Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 21 Jul 2015 12:42:37 -0000 IPv6 ND and DHCPv6 do support randomizing sending of messages for the use c= ase below. Also, if a DSL modem is reset because its L2 headend reloade= d, the hosts behind the modem will likely not reset. Thus the number of ho= sts reset is less. Hemant -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Mark Smith Sent: Tuesday, July 21, 2015 5:51 AM To: Lorenzo Colitti Cc: v6ops list; draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast Actually I've witnessed these sorts of events in recent times - when 1000s = or 10s of 1000s of residential broadband subscribers come back on-line afte= r the BRAS/BNG has booted either due to failure or maintenance, or the back= haul infrastructure between the BRAS/BNG and subscribers has failed and rec= overed. Unicast RAs in the specific scenarios I've seen it in though may not have h= elped, as the subscribers were attached via individual PPPoE sessions, so m= ulticasting a single RA to many/all of them efficiently might not be possib= le, unless there was some fancy hardware/firmware that meant the control pl= ane didn't have to do it. However, if single link/multi-access methods of attaching subscribers are u= sed e.g., TR-101 N:1 VLAN, then solicited multicast RAs would help signific= antly reduce the number of multicast RSes from CPE during these events. From nobody Tue Jul 21 05:43:26 2015 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 A99721A1B46 for ; Tue, 21 Jul 2015 05:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 6Q3awQk9C5zX for ; Tue, 21 Jul 2015 05:43:22 -0700 (PDT) Received: from mx1.ernw.net (mx1.ernw.net [62.159.96.78]) (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 7EFB91A0404 for ; Tue, 21 Jul 2015 05:43:22 -0700 (PDT) Received: from mh1.ernw.net (unknown [IPv6:fd00:2001:0:d001::10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mh1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx1.ernw.net (Postfix) with ESMTPS id 1B20E15EC2C for ; Tue, 21 Jul 2015 14:45:35 +0200 (CEST) Received: from ws25.ernw.net (ws25.ernw.net [172.31.100.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "ws25.ernw.net", Issuer "ernw ca1" (verified OK)) by mh1.ernw.net (Postfix) with ESMTPS id EC306168 for ; Tue, 21 Jul 2015 14:43:20 +0200 (CEST) Received: by ws25.ernw.net (Postfix, from userid 1001) id CCCB2C4A0C; Tue, 21 Jul 2015 14:43:20 +0200 (CEST) Date: Tue, 21 Jul 2015 14:43:20 +0200 From: Enno Rey To: v6ops@ietf.org Message-ID: <20150721124320.GC36111@ernw.de> References: <1847F15E-ADF6-41D2-BEDA-EDD212705CA0@puck.nether.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1847F15E-ADF6-41D2-BEDA-EDD212705CA0@puck.nether.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [v6ops] draft-yc-v6ops-solicited-ra-unicast-00/ipv6 nd ra solicited unicast 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, 21 Jul 2015 12:43:24 -0000 Hi, afaik it's not (yet? any guys from the vendor willing to comment?) in IOS-XR, only in plain IOS (since 15.4(2)T). best Enno On Tue, Jul 21, 2015 at 08:33:21AM -0400, Jared Mauch wrote: > Regarding: https://tools.ietf.org/html/draft-yc-v6ops-solicited-ra-unicast-00 > > Does anyone know if/when this support appeared in IOS-XR? It does not appear to be there.. > > RP/0/RSP0/CPU0:Router(config-if)#ipv6 nd ra ? > > - Jared > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From nobody Tue Jul 21 06:01:52 2015 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 4BE641A90CD for ; Tue, 21 Jul 2015 06:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eokYX5hawemm for ; Tue, 21 Jul 2015 06:01:44 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B21981A88CA for ; Tue, 21 Jul 2015 06:01:29 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6LD1Q35028638 for ; Tue, 21 Jul 2015 15:01:26 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3F1A320237B for ; Tue, 21 Jul 2015 15:05:00 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 2F9BF20237A for ; Tue, 21 Jul 2015 15:05:00 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.35]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6LD1OX3028923 for ; Tue, 21 Jul 2015 15:01:25 +0200 To: "v6ops@ietf.org" From: Alexandru Petrescu Message-ID: <55AE42A4.8020908@gmail.com> Date: Tue, 21 Jul 2015 15:01:24 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [v6ops] ref Hosts dont MLD to join LL groups 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, 21 Jul 2015 13:01:46 -0000 Hi, Regarding the mic discussion about unicast RAs a SHOULD. I have been directed that the reference saying that Hosts dont MLD to join multicast groups is RFC3810: " The link-scope all-nodes multicast address, (FF02::1), is handled as a special case. On all nodes -- that is all hosts and routers, including multicast routers -- listening to packets destined to the all-nodes multicast address, from all sources, is permanently enabled on all interfaces on which multicast listening is supported. No MLD messages are ever sent regarding neither the link-scope all-nodes multicast address, nor any multicast address of scope 0 (reserved) or 1 (node-local)." Alex From nobody Tue Jul 21 06:10:15 2015 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 E47A51A86E0 for ; Tue, 21 Jul 2015 06:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHkulAs6Mkrq for ; Tue, 21 Jul 2015 06:10:07 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A72E61A3BA1 for ; Tue, 21 Jul 2015 06:10:06 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6LDA4Ue030124 for ; Tue, 21 Jul 2015 15:10:04 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BDF77202199 for ; Tue, 21 Jul 2015 15:13:38 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A97BB2020B4 for ; Tue, 21 Jul 2015 15:13:38 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.35]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6LDA3sr005442 for ; Tue, 21 Jul 2015 15:10:04 +0200 To: "v6ops@ietf.org" From: Alexandru Petrescu Message-ID: <55AE44AA.7070304@gmail.com> Date: Tue, 21 Jul 2015 15:10:02 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [v6ops] unicast RA to save battery: link-layer joining multicast groups 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, 21 Jul 2015 13:10:13 -0000 On another hand, IEEE 802.11bgn multicast groups (33::1 etc) are 'joined' at MAC layer by setting filters. (maybe even by MAC messaging for joining MAC multicast groups). Maybe we can request the Hosts to set local filters to not receive multicast RAs. Or request the Hosts short on energy to express interest in these IPv6 multicast groups. Alex From nobody Tue Jul 21 06:24:37 2015 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 886501B2BA6 for ; Tue, 21 Jul 2015 06:24:35 -0700 (PDT) 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 HZ70E2qzp1Ct for ; Tue, 21 Jul 2015 06:24:33 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::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 E18151B29C1 for ; Tue, 21 Jul 2015 06:24:32 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so120688353wib.0 for ; Tue, 21 Jul 2015 06:24:31 -0700 (PDT) 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=s9YftuHaiHJBgL6EH414ArRIA8MJsnkx/mAM7HVaQDk=; b=nG6muzsVYflcgOT305hUj6R4jnhbzi+ExxXcsnTXh6IVpE6rRi7bnqzPwcW+HzqDz9 vTX6AivKaPPaSSLZ5v1rUmWodWuuD0ltwwwCBC552+sflnvY2yMQ+6fS+yQ7VdSTZax1 TYYb4Rv2X2K4Xt7rKwguMA0H+x4BjK7DNgZDQ+wG5Yvq+/tTygDIyiIs0wBt9yjPbfX7 OwJ0CPlq9q02GROAJnn9xM9u1l2UTE2kPG+ePo1p7wCAciQ3gNEf+Ov/16pgda78E2Su JEnvKKZgtdGRNe3Z1I3yz6z5u5v8d+btzLDzvNUw0M8oeGvZZvwdpJI9cBuDeHPh04tT VGdA== 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=s9YftuHaiHJBgL6EH414ArRIA8MJsnkx/mAM7HVaQDk=; b=b6NDqxih6XktRpMXsO6SKymgSO+TtohljZKNMQlwZWkRDy5mMu+n/RFmSa7gELhGsH Jg6CMnaCBLuG/vHGLF2OL/JMFoXhh9lXB/7HTTPgN2/lUgG2tNI/lKmMRAfeWNQCK8iP r6AFlAfhbc55VO76+mrLfxdsqkm7WFw2H+/F9Ve0U+9LwSZ8tHWNQY8WqjMWd9f2Uo1r HODGinADxyDgTQ0MtNV5wZR1vHlSMJCKMbXx6VhWIyWhAsJ7SVnBSYJE9Db74rnyhIPa H2//mS2Wm+MteGKdOutfeubgFv3y0s8M3jC9GO6GgnpRNJcMR2egHZRZLTQmoYF2keUR D0Fg== X-Gm-Message-State: ALoCoQkTccm9bywzwcbEfVJiI4Swa6ERLIS6ie+dULxqKxW4IojOm0tQvRtojnTG2eXIu1jXTZBt X-Received: by 10.180.78.136 with SMTP id b8mr30449997wix.89.1437485071660; Tue, 21 Jul 2015 06:24:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.138.203 with HTTP; Tue, 21 Jul 2015 06:24:11 -0700 (PDT) In-Reply-To: <55AE2FD6.4060405@gmail.com> References: <55AE2FD6.4060405@gmail.com> From: Erik Kline Date: Tue, 21 Jul 2015 15:24:11 +0200 Message-ID: To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-design-choices-08 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, 21 Jul 2015 13:24:35 -0000 On 21 July 2015 at 13:41, Brian E Carpenter wrote: > In section 2.1.1. Choice of Addresses in the Core > >> For an enterprise, the use of private address space is >> reasonable, but the enterprise will need to use NAT44 and/or >> NPT[RFC6296] on links to the Internet. If the network has no >> connection to the Internet, then obviously this is not a problem. > > Try > > For an enterprise, the use of private address space is reasonable. > In the case of IPv4 [RFC1918] the enterprise will need to use NAT44. > In the case of IPv6 ULA addresses [RFC4193], the preferred solution > is to use private addresses only for internal traffic. Hosts > requiring external connections should be given normal PA or PI > addresses as well as ULA addresses. If the network has no connection > to the Internet, then obviously this is not needed. The > experimental mechanism Network Prefix Translation [RFC6296] is > not recommended. +1 From nobody Tue Jul 21 07:02:21 2015 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 8D0BD1B2E2D for ; Tue, 21 Jul 2015 07:02:18 -0700 (PDT) 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 ZQ4dYnzxk8x1 for ; Tue, 21 Jul 2015 07:02:12 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2010F1B2E2E for ; Tue, 21 Jul 2015 07:02:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1770; q=dns/txt; s=iport; t=1437487332; x=1438696932; h=from:to:subject:date:message-id:mime-version; bh=LbyyhqjGYu8kMGMAP0IKUfM/BNzOQHMTZEb1zTk43a8=; b=dFjT+9gZvVsfWNBh2WRd1F/KE75EioNPKGaeFwbiDhoJNyfSFQV0JCJx 1pR+wtUvVLx9Q84I1bKx3Y+oPEe3kVqkIvm4jdDGjr6bqjPDxAKwli4qA nenSVH79ERYSx/UUM8Aqe4ogigXmrdWfUl0GwOnTHscThSphL5m1pemmg k=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AiAwC/T65V/5FdJa1cgxNUb7wKCYF1hz04FAEBAQEBAQGBCoQqgQsBgQAnBAEgiCANyyEBAQEBAQEBAQEBAQEBAQEBARcEk3CBFAWUUwGCNYFXaIc1mQ4mg3yCNoEEAQEB X-IronPort-AV: E=Sophos;i="5.15,516,1432598400"; d="asc'?scan'208";a="170748785" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-7.cisco.com with ESMTP; 21 Jul 2015 14:02:11 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t6LE2BpH017747 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jul 2015 14:02:11 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.49]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Tue, 21 Jul 2015 09:02:11 -0500 From: "Fred Baker (fred)" To: v6ops list , Erik Kline , "lorenzo@google.com" Thread-Topic: Discussion of draft-ietf-v6ops-ula-usage-recommendations Thread-Index: AQHQw73WnPgrOvjAyEyawMXgVWiTmg== Date: Tue, 21 Jul 2015 14:02:10 +0000 Message-ID: <6153A91F-7E9A-4579-BA06-72964568D343@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.61.91.41] Content-Type: multipart/signed; boundary="Apple-Mail=_9928B609-9149-4431-A27B-E64C24D7C48F"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: [v6ops] Discussion of draft-ietf-v6ops-ula-usage-recommendations 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, 21 Jul 2015 14:02:18 -0000 --Apple-Mail=_9928B609-9149-4431-A27B-E64C24D7C48F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii https://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations "Considerations For Using Unique Local Addresses", Bing Liu, Sheng Jiang, 2015-05-03 This draft came up from the floor this afternoon. I think we need some = concentrated constructive conversation regarding it - we have had a lot = of the other kind. What issues do we need to address to complete it. and what specific = recommendations would that include? --Apple-Mail=_9928B609-9149-4431-A27B-E64C24D7C48F 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 iQIVAwUBVa5Q4UayAOS/EQ8MAQIl0g/+Ksli9qBbIHspn5BHOCTwOArwDEI3B9/g EggR0JxmBHdjy+VLrjiey2tH5jDSsEXj2WVxYUZmPiRDUndCp3syq/x/YlOdiQWp rUvwG/ZSso85Iwn4PAPp1JiYS/JnNz/DNYgE2/pAXp5/BT1J7YyPzdCPItRHNohj nJFUoCM2CYjSQ1M5vGzjU4XM6dcazh4VCezyuOcgtGPn7uNd5JI8kXv1L2T75oEa 3iKWV94RQ+aEVC+ay7JgcJu7TahFR6FSMuU6OT+TwUBRWjxOgtyFfAoG//HBLUbP dkmlUn2FuN2oJHzJQ8PZUR5q3Lmx9aA3yjtW3Zd9RHu2PHBsVaQ1BGYzpUmcmXh0 OYwpzyyL0C8UCjO7g342PCLxXm+yVIMwOHn+qy9gxzHlA4F7kpMETBl+xsEIq6xI u0312BhhpGSV+YsUX0KOVH6P3HLG2/+s6wo1neo9EkQYQbvvXFYoTKrt2Q2CG1Or MSBZ42uKInprWJg5ec3mhJSzQPRwYrZuX4TDwOxU57LGAWTdopLMEjy0bQot97SD izQlOoRprd0vCwDyqiTDxRkC1iAI7yZNO3Njqd++DfX+wQbqxYupNxHoxQolC+Di x2rGntpI/B1rLLNPW4fa+ojFDjx0c8g+OmxcziSV/yNjYj8zi/y0RQ7cJhuoMHzG fgHL3fSne5c= =hYEx -----END PGP SIGNATURE----- --Apple-Mail=_9928B609-9149-4431-A27B-E64C24D7C48F-- From nobody Tue Jul 21 07:09:30 2015 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 843081B2E65 for ; Tue, 21 Jul 2015 07:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PpQLGecAVUE7 for ; Tue, 21 Jul 2015 07:09:25 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BB641B2E4C for ; Tue, 21 Jul 2015 07:08:51 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6LE8oia027397 for ; Tue, 21 Jul 2015 16:08:50 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2A2252023BD for ; Tue, 21 Jul 2015 16:12:24 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 228D52020D9 for ; Tue, 21 Jul 2015 16:12:24 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.35]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6LE8n6l001645 for ; Tue, 21 Jul 2015 16:08:49 +0200 To: v6ops@ietf.org References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> <331D6E02-167D-4E7F-9682-F63C6674BD24@gmail.com> From: Alexandru Petrescu Message-ID: <55AE5270.8000301@gmail.com> Date: Tue, 21 Jul 2015 16:08:48 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <331D6E02-167D-4E7F-9682-F63C6674BD24@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 21 Jul 2015 14:09:28 -0000 Le 17/07/2015 18:57, Andrew Yourtchenko a écrit : > > On 17 Jul 2015, at 09:34, Fred Baker (fred) wrote: > >>> >>> So the next logical thing to do would be to have the router default to >>> unicast Router Advertisements, measure the rate of received Router >>> Solicitations, and switch to multicast RA mode past a certain >>> threshold to cover this sort of situation. Once the number of RSes >>> falls, it switches back to unicast RA mode. >>> >>> That would get rid of the configuration knob proposed in this ID, and >>> is behaviour that I think could be universal for all link types, >>> rather than just for the case of wireless ones with mobile devices. >> >> If it were me implementing it, I think I would go about this in a little different way, hopefully simpler. I would want to send at most one (e.g., either zero or one) RA per some interval (a second?). In the normal case, that is sent unicast. However, having sent a unicast RA at time t, if I now receive another RS before t+1, I send the next one (at time t+1) as a multicast. > > values of T less than 3 seconds would make performance worse than today. > > There are many things to optimize for: > > - wireless airtime > - bandwidth used by RAs > - CPU usage sending unicast RAs by router > - energy consumption on devices for more than one medium and: - fast handovers: on some links the more frequent the multicast RAs the faster the handovers are, i.e. less packet loss for end nodes, less glitches in the video conference stream. Alex > > Some of them are orthogonal, some of them contradict each other, some of them align. People may want to optimize differently. > > I'd opt for simplicity - and use the text Erik Kline posted in another email. > > This would allow the developers to adapt for individual use cases on the spot. > > --a > >> _______________________________________________ >> 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 Tue Jul 21 07:09:47 2015 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 1FD171B2E70 for ; Tue, 21 Jul 2015 07:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E33lyavtSfUq for ; Tue, 21 Jul 2015 07:09:32 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B21D1B2E53 for ; Tue, 21 Jul 2015 07:09:00 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6LE8wAk027446 for ; Tue, 21 Jul 2015 16:08:58 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id CF8802020D9 for ; Tue, 21 Jul 2015 16:12:32 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id BE34E2023E9 for ; Tue, 21 Jul 2015 16:12:32 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.35]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6LE8wP3001714 for ; Tue, 21 Jul 2015 16:08:58 +0200 To: v6ops@ietf.org References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> From: Alexandru Petrescu Message-ID: <55AE5279.8000608@gmail.com> Date: Tue, 21 Jul 2015 16:08:57 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.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] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 21 Jul 2015 14:09:44 -0000 Le 20/07/2015 16:23, Jen Linkova a écrit : > On Tue, Jul 7, 2015 at 1:47 PM, wrote: >> A new draft has been posted, at http://tools.ietf.org/html/draft-yc-v6ops-solicited-ra-unicast. Please take a look at it and comment. > > A bit late but...I fully support the draft. Very useful work. I agree. Alex > > One comment: Lorenzo, Andrew - do you think it worth mentioning the > difference in how reliable multicast and unicasts are on wifi? > From nobody Tue Jul 21 07:19:14 2015 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 C464C1A8868 for ; Tue, 21 Jul 2015 07:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwkYAj2Fowza for ; Tue, 21 Jul 2015 07:19:04 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6CEE1A887E for ; Tue, 21 Jul 2015 07:19:02 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6LEJ1NY031412 for ; Tue, 21 Jul 2015 16:19:01 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 589D720239F for ; Tue, 21 Jul 2015 16:22:35 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5006F201FCB for ; Tue, 21 Jul 2015 16:22:35 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.35]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6LEIx1T011806 for ; Tue, 21 Jul 2015 16:19:01 +0200 To: v6ops@ietf.org References: <6153A91F-7E9A-4579-BA06-72964568D343@cisco.com> From: Alexandru Petrescu Message-ID: <55AE54D3.7070502@gmail.com> Date: Tue, 21 Jul 2015 16:18:59 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <6153A91F-7E9A-4579-BA06-72964568D343@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Discussion of draft-ietf-v6ops-ula-usage-recommendations 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, 21 Jul 2015 14:19:05 -0000 1. Brian suggested to recommend that globals should be there on the machines having ULAs as well, if I understand correctly. But I think so only on some Hosts, mainly the Hosts of end users. 2. the ULA RFC suggests a ULA prefix can be generated out of a MAC address. That sixxs implementation does it. Except it takes it too serious: it does not accept a MAC address which is not a real MAC address - in that oui.txt. And random MAC addresses (for privacy) certainly are not in that oui.txt. I think this is an undesirable situation to be in: unable to generate ULAs because the only tool out there (sixxs) can't refuses a copy paste a MAC address from the widely used windows 7 laptops. I am not sure what the problem is, but it's very good to have a very easy way to generate ULAs. 3. in an enterprise deployment there was a problem of ULAs deployed in a intra-network and another ULA space in another intra-network, of the same enterprise. So we wanted to make sure two things: the two ULA spaces are distinct, or otherwise make sure the gateway router does not route between the two intranets' ULAs (but yes, route between their respective GUAs). I am not sure how to translate that into advice, because I am not sure how it will unfold in the near future. Alex Le 21/07/2015 16:02, Fred Baker (fred) a écrit : > https://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations > > "Considerations For Using Unique Local Addresses", Bing Liu, Sheng > Jiang, 2015-05-03 > > This draft came up from the floor this afternoon. I think we need > some concentrated constructive conversation regarding it - we have > had a lot of the other kind. > > What issues do we need to address to complete it. and what specific > recommendations would that include? > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue Jul 21 07:53:59 2015 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 178421B2E5F for ; Tue, 21 Jul 2015 07:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5F0sN8WoMW2 for ; Tue, 21 Jul 2015 07:53:54 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450: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 B110B1B2E65 for ; Tue, 21 Jul 2015 07:53:53 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so59819743wib.1 for ; Tue, 21 Jul 2015 07:53:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Pm51yYzaNibq5K6vvlCiv6Pq8xOsvPyMAsEek7ywPAg=; b=yeSA2sLr3GKxAImOrHZaiWPpNwGgskYZoHjZx0drzKBAtAtsHCFezTMX3+oFa/npr1 06qSOF3ZKqUyOAX645NpcVm/loiWZqAYGzqh6Mzt8B9MTRrN6uU6V1xUl/81uS/5UKkC LxOe/CAPcJkuvO8+rDzjvftpiwQOZrACABwePq1FV5cgBB1nGmyy/TZaidoh8KRxADlD fPNylUzLu2zk6U8oE/ZggwCVPWBAUnaIOBCl04XRJXjYR86SgV148YDcKCQFtp0VTqRc 953tucLx05wMgqv2lqzQboLj3KS3avw+FMW9yjo7EYHMZmddX3QBdeKrzbstY1fvxuyG zN4Q== X-Received: by 10.194.23.106 with SMTP id l10mr71936986wjf.1.1437490432525; Tue, 21 Jul 2015 07:53:52 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:28cc:dc4c:9703:6781? ([2001:67c:370:176:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id x10sm37420772wjr.25.2015.07.21.07.53.51 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Jul 2015 07:53:51 -0700 (PDT) Message-ID: <55AE5D01.5090309@gmail.com> Date: Wed, 22 Jul 2015 02:53:53 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Alexandru Petrescu , v6ops@ietf.org References: <6153A91F-7E9A-4579-BA06-72964568D343@cisco.com> <55AE54D3.7070502@gmail.com> In-Reply-To: <55AE54D3.7070502@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Discussion of draft-ietf-v6ops-ula-usage-recommendations 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, 21 Jul 2015 14:53:58 -0000 On 22/07/2015 02:18, Alexandru Petrescu wrote: > 1. Brian suggested to recommend that globals should be there on the > machines having ULAs as well, if I understand correctly. >=20 > But I think so only on some Hosts, mainly the Hosts of end users. All hosts that need external communication. >=20 > 2. the ULA RFC suggests a ULA prefix can be generated out of a MAC > address. That sixxs implementation does it. Except it takes it too > serious: it does not accept a MAC address which is not a real MAC > address - in that oui.txt. And random MAC addresses (for privacy) > certainly are not in that oui.txt. >=20 > I think this is an undesirable situation to be in: unable to generate > ULAs because the only tool out there (sixxs) can't refuses a copy paste= > a MAC address from the widely used windows 7 laptops. That isn't a standards issue, but I agree that operationally, there needs= to be a viable way for anyone to generate a random number. Wait a minute,= that doesn't seem hard. >=20 > I am not sure what the problem is, but it's very good to have a very > easy way to generate ULAs. >=20 > 3. in an enterprise deployment there was a problem of ULAs deployed in = a > intra-network and another ULA space in another intra-network, of the > same enterprise. So we wanted to make sure two things: the two ULA > spaces are distinct, or otherwise make sure the gateway router does not= > route between the two intranets' ULAs (but yes, route between their > respective GUAs).=20 Why not? ULA to ULA routing on a private link might be desired (e.g. after two networks merge without renumbering). From a routing PoV there is nothing special about a ULA prefix; we just need to configure carefully where it is routed and where it is not routed. Anyway - I'd like to see the draft progress. Has it already had a WGLC? Brian > I am not sure how to translate that into advice, > because I am not sure how it will unfold in the near future. >=20 > Alex >=20 > Le 21/07/2015 16:02, Fred Baker (fred) a =C3=A9crit : >> https://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations= >> >> > "Considerations For Using Unique Local Addresses", Bing Liu, Sheng >> Jiang, 2015-05-03 >> >> This draft came up from the floor this afternoon. I think we need >> some concentrated constructive conversation regarding it - we have >> had a lot of the other kind. >> >> What issues do we need to address to complete it. and what specific >> recommendations would that include? >> >> >> >> _______________________________________________ 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 From nobody Tue Jul 21 08:26:45 2015 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 0B7441B2E85 for ; Tue, 21 Jul 2015 08:26:44 -0700 (PDT) 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 1OetERgCArk3 for ; Tue, 21 Jul 2015 08:26:38 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEE781B2F4D for ; Tue, 21 Jul 2015 08:24:42 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id C76C43493BE; Tue, 21 Jul 2015 15:24:36 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 15346160086; Tue, 21 Jul 2015 15:25:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id F1F0A160079; Tue, 21 Jul 2015 15:25:32 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id XW7d5L3Ui1cO; Tue, 21 Jul 2015 15:25:32 +0000 (UTC) Received: from rock.dv.isc.org (unknown [31.133.138.45]) by zmx1.isc.org (Postfix) with ESMTPSA id 999F5160052; Tue, 21 Jul 2015 15:25:32 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 096C3338A4AD; Wed, 22 Jul 2015 01:24:34 +1000 (EST) To: Alexandru Petrescu From: Mark Andrews References: <6153A91F-7E9A-4579-BA06-72964568D343@cisco.com> <55AE54D3.7070502@gmail.com> In-reply-to: Your message of "Tue, 21 Jul 2015 16:18:59 +0200." <55AE54D3.7070502@gmail.com> Date: Wed, 22 Jul 2015 01:24:34 +1000 Message-Id: <20150721152434.096C3338A4AD@rock.dv.isc.org> Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Discussion of draft-ietf-v6ops-ula-usage-recommendations 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, 21 Jul 2015 15:26:44 -0000 In message <55AE54D3.7070502@gmail.com>, Alexandru Petrescu writes: > 1. Brian suggested to recommend that globals should be there on the > machines having ULAs as well, if I understand correctly. > > But I think so only on some Hosts, mainly the Hosts of end users. > > 2. the ULA RFC suggests a ULA prefix can be generated out of a MAC > address. That sixxs implementation does it. Except it takes it too > serious: it does not accept a MAC address which is not a real MAC > address - in that oui.txt. And random MAC addresses (for privacy) > certainly are not in that oui.txt. This is a ULA generator. You do not need a MAC. % dd if=/dev/random bs=7 count=1 | od -t x1 | awk '/0000/ {print "fd" $2 ":" $3 $4 ":" $5 $6 ; exit}' 1+0 records in 1+0 records out 7 bytes transferred in 0.000024 secs (293601 bytes/sec) fd61:cb66:8851 % > ULAs because the only tool out there (sixxs) can't refuses a copy paste > a MAC address from the widely used windows 7 laptops. *All* you need is 7 bytes of random numbers. Many modern CPU's will do this for you today. If you don't have that then you can use the pseudo random number generator in the rfc. The algorithm is for CPE devices without a good source of randomness. > I am not sure what the problem is, but it's very good to have a very > easy way to generate ULAs. > > 3. in an enterprise deployment there was a problem of ULAs deployed in a > intra-network and another ULA space in another intra-network, of the > same enterprise. So we wanted to make sure two things: the two ULA > spaces are distinct, or otherwise make sure the gateway router does not > route between the two intranets' ULAs (but yes, route between their > respective GUAs). I am not sure how to translate that into advice, > because I am not sure how it will unfold in the near future. > > Alex > > Le 21/07/2015 16:02, Fred Baker (fred) a =E9crit : > > https://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations > > > > > "Considerations For Using Unique Local Addresses", Bing Liu, Sheng > > Jiang, 2015-05-03 > > > > This draft came up from the floor this afternoon. I think we need > > some concentrated constructive conversation regarding it - we have > > had a lot of the other kind. > > > > What issues do we need to address to complete it. and what specific > > recommendations would that include? > > > > > > > > _______________________________________________ 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Jul 21 08:38:26 2015 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 0CE651A8A3E for ; Tue, 21 Jul 2015 08:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.811 X-Spam-Level: X-Spam-Status: No, score=-0.811 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, MIME_8BIT_HEADER=0.3, 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 kzqx1Tz7maAB for ; Tue, 21 Jul 2015 08:38:19 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 94FAA1A8A3D for ; Tue, 21 Jul 2015 08:38:19 -0700 (PDT) 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.2) with ESMTP id t6LFc5er006663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Jul 2015 08:38:05 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Owen DeLong In-Reply-To: Date: Tue, 21 Jul 2015 08:38:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> <55AD3B64.5070400@acm.org> To: =?utf-8?Q?Andrew_=F0=9F=91=BD_Yourtchenko?= X-Mailer: Apple Mail (2.2098) Archived-At: Cc: v6ops list , "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 21 Jul 2015 15:38:21 -0000 It seems to me that the following algorithm would be relatively easy to = implement and provide reasonable network optimization=E2=80=A6 On receipt of an RS: if(multicast_ra_time_remaining > 15 seconds) { Send_Unicast_ra } else { Send_Multicast_ra reset_multicast_timer } In this way, if the timing is reasonably close, you multicast a packet = you were about to send anyway, but if the timing isn=E2=80=99t close, you=E2=80=99re not = wasting multicast bandwidth answering a single node where nobody else cares. Overall, I=E2=80=99ve always thought that multicast response to RS was = kind of silly. It=E2=80=99s probably most harmful on WiFi. Owen > On Jul 21, 2015, at 02:33 , Andrew =F0=9F=91=BD Yourtchenko = wrote: >=20 > On 7/20/15, Erik Nordmark wrote: >> On 7/17/15 9:34 AM, Fred Baker (fred) wrote: >>>> So the next logical thing to do would be to have the router default = to >>>> unicast Router Advertisements, measure the rate of received Router >>>> Solicitations, and switch to multicast RA mode past a certain >>>> threshold to cover this sort of situation. Once the number of RSes >>>> falls, it switches back to unicast RA mode. >>>>=20 >>>> That would get rid of the configuration knob proposed in this ID, = and >>>> is behaviour that I think could be universal for all link types, >>>> rather than just for the case of wireless ones with mobile devices. >>> If it were me implementing it, I think I would go about this in a = little >>> different way, hopefully simpler. I would want to send at most one = (e.g., >>> either zero or one) RA per some interval (a second?). In the normal = case, >>> that is sent unicast. However, having sent a unicast RA at time t, = if I >>> now receive another RS before t+1, I send the next one (at time t+1) = as a >>> multicast. >>=20 >> First of all I support this document as a WG document. >>=20 >> But in terms of implementation, isn't it simpler to always(*) respond = to >> a RS with a unicast RA? >=20 > Yes. I did not respond on-list yet - but from operational perspective > "always send solRA unicast" / "always send solRA multicast" definitely > wins in my book, and I'd avoid premature optimizations (but maybe we > can say the implementers are explicitly free to do their own > optimizations if they see fit) >=20 > That said, will be very interesting to hear data from folks who will > run "all-unicast solRA", in real networks and then compare the effect > of their proposal optimizations on their real-world scenarios. >=20 >> As background, the text in RFC4861 comes from the old concern that = all >> devices might boot at the same time when the power is re-established >> after a building power failure; that doesn't happen since most = devices >> (laptops, smartphones, IoT devices) have batteries today. In that = case >> it might have made sense to sending fewer RA messages by using = multicast. >>=20 >> (*) the only case in RFC 4861 when I think a multicast response might = be >> considered is when the source IPv6 address in the RS is the = unspecified >> address. Further, an implementation which rate limits received RS >> packets (e.g., CoPP in a router) might also want to detect when the = rate >> limit might have dropped RS packets and multicast an RA in that case. >>=20 >>=20 >> I do wonder why implementations haven't already changed to send = unicast >> solicited RA, and whether it would make a difference if we have an >=20 > TBH that's my concern as well. I think we should tweak the text in > 4861 to encourage a bit more consideration on the implementer's side. >=20 >> informational document asking them to do this. Alternatively we could >> have a proposed standard which updates section 6.2.6 to change the = "MAY >> unicast" to a "SHOULD unicast". >=20 > Yeah, I actually have had the different text aimed for 6man, but > Lorenzo's concern was 6man would say "there is no protocol update > here, go away", so he rewrote it for v6ops. >=20 > We should probably discuss this at the mic and get the opinion of the > 6man chairs - if there is no outright "no" on this, a normative doc > would be a better way to convince the implementers ? >=20 >>=20 >> FWIW the draft incorrectly refers to section 6.2.4 instead of 6.2.6. >=20 > Nice catch, thanks! >=20 > --a >=20 >>=20 >> Thanks, >> Erik >>=20 >>>=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 >>=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Jul 21 09:13:32 2015 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 8523E1B2F74 for ; Tue, 21 Jul 2015 09:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Tkx9HmgA5hJx for ; Tue, 21 Jul 2015 09:13:22 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 59D3A1B2F72 for ; Tue, 21 Jul 2015 09:13:22 -0700 (PDT) Received: by puck.nether.net (Postfix, from userid 162) id 114FD540936; Tue, 21 Jul 2015 12:13:22 -0400 (EDT) Date: Tue, 21 Jul 2015 12:13:21 -0400 From: Jared Mauch To: "v6ops@ietf.org WG" Message-ID: <20150721161321.GA18672@puck.nether.net> References: <1847F15E-ADF6-41D2-BEDA-EDD212705CA0@puck.nether.net> <20150721123833.GA5337@puck.nether.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150721123833.GA5337@puck.nether.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [v6ops] draft-yc-v6ops-solicited-ra-unicast-00/ipv6 nd ra solicited unicast 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, 21 Jul 2015 16:13:23 -0000 On Tue, Jul 21, 2015 at 08:38:33AM -0400, Jared Mauch wrote: > On Tue, Jul 21, 2015 at 08:33:21AM -0400, Jared Mauch wrote: > > Regarding: https://tools.ietf.org/html/draft-yc-v6ops-solicited-ra-unicast-00 > > > > Does anyone know if/when this support appeared in IOS-XR? It does not appear to be there.. > > > > RP/0/RSP0/CPU0:Router(config-if)#ipv6 nd ra ? > > Baah, insufficent output in paste. > > hoplimit IPv6 ND RA hoplimit > mtu IPv6 ND RA mtu option configuration Cisco has been kind enough to open CSCuv42292 for this in IOS-XR. - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From nobody Tue Jul 21 09:23:36 2015 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 27CCC1A88B8 for ; Tue, 21 Jul 2015 09:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0mtRl6kxGC5 for ; Tue, 21 Jul 2015 09:23:25 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE9801B2FB1 for ; Tue, 21 Jul 2015 09:23:23 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6LGNLHo007859; Tue, 21 Jul 2015 18:23:21 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id AEDF9202532; Tue, 21 Jul 2015 18:26:55 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A366320251D; Tue, 21 Jul 2015 18:26:55 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.35]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6LGNJXl006371; Tue, 21 Jul 2015 18:23:21 +0200 To: Brian E Carpenter , v6ops@ietf.org References: <6153A91F-7E9A-4579-BA06-72964568D343@cisco.com> <55AE54D3.7070502@gmail.com> <55AE5D01.5090309@gmail.com> From: Alexandru Petrescu Message-ID: <55AE71F7.8000107@gmail.com> Date: Tue, 21 Jul 2015 18:23:19 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55AE5D01.5090309@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Discussion of draft-ietf-v6ops-ula-usage-recommendations 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, 21 Jul 2015 16:23:30 -0000 Le 21/07/2015 16:53, Brian E Carpenter a ĂŠcrit : > On 22/07/2015 02:18, Alexandru Petrescu wrote: >> 1. Brian suggested to recommend that globals should be there on >> the machines having ULAs as well, if I understand correctly. >> >> But I think so only on some Hosts, mainly the Hosts of end users. > > All hosts that need external communication. I agree, all hosts that need external communication. >> 2. the ULA RFC suggests a ULA prefix can be generated out of a MAC >> address. That sixxs implementation does it. Except it takes it >> too serious: it does not accept a MAC address which is not a real >> MAC address - in that oui.txt. And random MAC addresses (for >> privacy) certainly are not in that oui.txt. >> >> I think this is an undesirable situation to be in: unable to >> generate ULAs because the only tool out there (sixxs) can't refuses >> a copy paste a MAC address from the widely used windows 7 laptops. > > That isn't a standards issue, but I agree that operationally, there > needs to be a viable way for anyone to generate a random number. Wait > a minute, that doesn't seem hard. It's easily done centrally, but in a distributed manner it's harder - how am I sure the network I connect to has ULAs generated such that they dont clash with mine? >> I am not sure what the problem is, but it's very good to have a >> very easy way to generate ULAs. >> >> 3. in an enterprise deployment there was a problem of ULAs deployed >> in a intra-network and another ULA space in another intra-network, >> of the same enterprise. So we wanted to make sure two things: the >> two ULA spaces are distinct, or otherwise make sure the gateway >> router does not route between the two intranets' ULAs (but yes, >> route between their respective GUAs). > > Why not? ULA to ULA routing on a private link might be desired (e.g. > after two networks merge without renumbering). From a routing PoV > there is nothing special about a ULA prefix; we just need to > configure carefully where it is routed and where it is not routed. Yes, private routing should be ok, but only if these ULAs are unique. If people on different networks use different generation methods then it's dubious to be sure of the uniqueness. Maybe I choose fd00:1::/64 being sure that no random generator will make it, and it happens my neighbors does the same. That leads to conflict on fd00:1::/64 and we dont want routing enabled between the two. > Anyway - I'd like to see the draft progress. Has it already had a > WGLC? I agree, it already has advice in it worth progressing. Alex > > Brian > >> I am not sure how to translate that into advice, because I am not >> sure how it will unfold in the near future. >> >> Alex >> >> Le 21/07/2015 16:02, Fred Baker (fred) a ĂŠcrit : >>> https://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations >>> >>> >> >>> "Considerations For Using Unique Local Addresses", Bing Liu, Sheng >>> Jiang, 2015-05-03 >>> >>> This draft came up from the floor this afternoon. I think we >>> need some concentrated constructive conversation regarding it - >>> we have had a lot of the other kind. >>> >>> What issues do we need to address to complete it. and what >>> specific recommendations would that include? >>> >>> >>> >>> _______________________________________________ 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 Tue Jul 21 09:26:31 2015 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 D19A81A8F4E for ; Tue, 21 Jul 2015 09:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7v4XPaHV1sg for ; Tue, 21 Jul 2015 09:26:26 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E804D1A0233 for ; Tue, 21 Jul 2015 09:26:25 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6LGQOb9001184; Tue, 21 Jul 2015 18:26:24 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 64A7920266A; Tue, 21 Jul 2015 18:29:58 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 58E3720251D; Tue, 21 Jul 2015 18:29:58 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.35]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6LGQNXS008215; Tue, 21 Jul 2015 18:26:23 +0200 To: Mark Andrews References: <6153A91F-7E9A-4579-BA06-72964568D343@cisco.com> <55AE54D3.7070502@gmail.com> <20150721152434.096C3338A4AD@rock.dv.isc.org> From: Alexandru Petrescu Message-ID: <55AE72AF.4030609@gmail.com> Date: Tue, 21 Jul 2015 18:26:23 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150721152434.096C3338A4AD@rock.dv.isc.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Discussion of draft-ietf-v6ops-ula-usage-recommendations 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, 21 Jul 2015 16:26:28 -0000 Le 21/07/2015 17:24, Mark Andrews a écrit : > > In message <55AE54D3.7070502@gmail.com>, Alexandru Petrescu writes: >> 1. Brian suggested to recommend that globals should be there on the >> machines having ULAs as well, if I understand correctly. >> >> But I think so only on some Hosts, mainly the Hosts of end users. >> >> 2. the ULA RFC suggests a ULA prefix can be generated out of a MAC >> address. That sixxs implementation does it. Except it takes it too >> serious: it does not accept a MAC address which is not a real MAC >> address - in that oui.txt. And random MAC addresses (for privacy) >> certainly are not in that oui.txt. > > This is a ULA generator. You do not need a MAC. > > % dd if=/dev/random bs=7 count=1 | od -t x1 | awk '/0000/ {print "fd" $2 ":" $3 $4 ":" $5 $6 ; exit}' > 1+0 records in > 1+0 records out > 7 bytes transferred in 0.000024 secs (293601 bytes/sec) > fd61:cb66:8851 > % Are we sure that if I use this generator it will not clash with somebody else using other generator? >> ULAs because the only tool out there (sixxs) can't refuses a copy paste >> a MAC address from the widely used windows 7 laptops. > > *All* you need is 7 bytes of random numbers. Many modern CPU's > will do this for you today. If you don't have that then you can > use the pseudo random number generator in the rfc. I agree. But we want to make sure randomness is ensured. > The algorithm is for CPE devices without a good source of randomness. Ok. Alex > >> I am not sure what the problem is, but it's very good to have a very >> easy way to generate ULAs. >> >> 3. in an enterprise deployment there was a problem of ULAs deployed in a >> intra-network and another ULA space in another intra-network, of the >> same enterprise. So we wanted to make sure two things: the two ULA >> spaces are distinct, or otherwise make sure the gateway router does not >> route between the two intranets' ULAs (but yes, route between their >> respective GUAs). I am not sure how to translate that into advice, >> because I am not sure how it will unfold in the near future. >> >> Alex >> >> Le 21/07/2015 16:02, Fred Baker (fred) a =E9crit : >>> https://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations >>> >>> >> "Considerations For Using Unique Local Addresses", Bing Liu, Sheng >>> Jiang, 2015-05-03 >>> >>> This draft came up from the floor this afternoon. I think we need >>> some concentrated constructive conversation regarding it - we have >>> had a lot of the other kind. >>> >>> What issues do we need to address to complete it. and what specific >>> recommendations would that include? >>> >>> >>> >>> _______________________________________________ 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 Tue Jul 21 09:28:48 2015 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 F099E1B2F8B for ; Tue, 21 Jul 2015 09:28:45 -0700 (PDT) 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 Hj7tZ9aLQm0R for ; Tue, 21 Jul 2015 09:28:44 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BCE71B2F6A for ; Tue, 21 Jul 2015 09:28:44 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 988BB3493CD; Tue, 21 Jul 2015 16:28:41 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id EF96E160052; Tue, 21 Jul 2015 16:29:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id CA6E0160079; Tue, 21 Jul 2015 16:29:37 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Lf8ynbw-udtz; Tue, 21 Jul 2015 16:29:37 +0000 (UTC) Received: from rock.dv.isc.org (89.100.broadband6.iol.cz [88.101.100.89]) by zmx1.isc.org (Postfix) with ESMTPSA id 31CB9160052; Tue, 21 Jul 2015 16:29:37 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 26A9F338B4ED; Wed, 22 Jul 2015 02:28:35 +1000 (EST) To: Alexandru Petrescu From: Mark Andrews References: <6153A91F-7E9A-4579-BA06-72964568D343@cisco.com> <55AE54D3.7070502@gmail.com> <55AE5D01.5090309@gmail.com> <55AE71F7.8000107@gmail.com> In-reply-to: Your message of "Tue, 21 Jul 2015 18:23:19 +0200." <55AE71F7.8000107@gmail.com> Date: Wed, 22 Jul 2015 02:28:35 +1000 Message-Id: <20150721162835.26A9F338B4ED@rock.dv.isc.org> Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Discussion of draft-ietf-v6ops-ula-usage-recommendations 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, 21 Jul 2015 16:28:46 -0000 In message <55AE71F7.8000107@gmail.com>, Alexandru Petrescu writes: > > > Le 21/07/2015 16:53, Brian E Carpenter a crit : > > On 22/07/2015 02:18, Alexandru Petrescu wrote: > >> 1. Brian suggested to recommend that globals should be there on > >> the machines having ULAs as well, if I understand correctly. > >> > >> But I think so only on some Hosts, mainly the Hosts of end users. > > > > All hosts that need external communication. > > I agree, all hosts that need external communication. > > > >> 2. the ULA RFC suggests a ULA prefix can be generated out of a MAC > >> address. That sixxs implementation does it. Except it takes it > >> too serious: it does not accept a MAC address which is not a real > >> MAC address - in that oui.txt. And random MAC addresses (for > >> privacy) certainly are not in that oui.txt. > >> > >> I think this is an undesirable situation to be in: unable to > >> generate ULAs because the only tool out there (sixxs) can't refuses > >> a copy paste a MAC address from the widely used windows 7 laptops. > > > > That isn't a standards issue, but I agree that operationally, there > > needs to be a viable way for anyone to generate a random number. Wait > > a minute, that doesn't seem hard. > > It's easily done centrally, but in a distributed manner it's harder - > how am I sure the network I connect to has ULAs generated such that they > dont clash with mine? *YOU* generate you ULA properly. > >> I am not sure what the problem is, but it's very good to have a > >> very easy way to generate ULAs. > >> > >> 3. in an enterprise deployment there was a problem of ULAs deployed > >> in a intra-network and another ULA space in another intra-network, > >> of the same enterprise. So we wanted to make sure two things: the > >> two ULA spaces are distinct, or otherwise make sure the gateway > >> router does not route between the two intranets' ULAs (but yes, > >> route between their respective GUAs). > > > > Why not? ULA to ULA routing on a private link might be desired (e.g. > > after two networks merge without renumbering). From a routing PoV > > there is nothing special about a ULA prefix; we just need to > > configure carefully where it is routed and where it is not routed. > > Yes, private routing should be ok, but only if these ULAs are unique. > If people on different networks use different generation methods then > it's dubious to be sure of the uniqueness. Maybe I choose fd00:1::/64 > being sure that no random generator will make it, and it happens my > neighbors does the same. That leads to conflict on fd00:1::/64 and we > dont want routing enabled between the two. Generate. Don't choose. If you generate then you should be ok. > > Anyway - I'd like to see the draft progress. Has it already had a > > WGLC? > > I agree, it already has advice in it worth progressing. > > Alex > > > > > Brian > > > >> I am not sure how to translate that into advice, because I am not > >> sure how it will unfold in the near future. > >> > >> Alex > >> > >> Le 21/07/2015 16:02, Fred Baker (fred) a crit : > >>> https://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations > >>> > >>> > >> > >>> > "Considerations For Using Unique Local Addresses", Bing Liu, Sheng > >>> Jiang, 2015-05-03 > >>> > >>> This draft came up from the floor this afternoon. I think we > >>> need some concentrated constructive conversation regarding it - > >>> we have had a lot of the other kind. > >>> > >>> What issues do we need to address to complete it. and what > >>> specific recommendations would that include? > >>> > >>> > >>> > >>> _______________________________________________ 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Jul 21 09:33:01 2015 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 335EA1B2FF7 for ; Tue, 21 Jul 2015 09:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xs2tl6F8LNFs for ; Tue, 21 Jul 2015 09:32:50 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3844A1B2FF3 for ; Tue, 21 Jul 2015 09:32:50 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6LGWlOr014149; Tue, 21 Jul 2015 18:32:48 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 22B6720251D; Tue, 21 Jul 2015 18:36:22 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 14FE8201108; Tue, 21 Jul 2015 18:36:22 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.35]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6LGWlki012068; Tue, 21 Jul 2015 18:32:47 +0200 To: Mark Andrews References: <6153A91F-7E9A-4579-BA06-72964568D343@cisco.com> <55AE54D3.7070502@gmail.com> <55AE5D01.5090309@gmail.com> <55AE71F7.8000107@gmail.com> <20150721162835.26A9F338B4ED@rock.dv.isc.org> From: Alexandru Petrescu Message-ID: <55AE742E.9040301@gmail.com> Date: Tue, 21 Jul 2015 18:32:46 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150721162835.26A9F338B4ED@rock.dv.isc.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Discussion of draft-ietf-v6ops-ula-usage-recommendations 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, 21 Jul 2015 16:32:56 -0000 Le 21/07/2015 18:28, Mark Andrews a écrit : > > In message <55AE71F7.8000107@gmail.com>, Alexandru Petrescu writes: >> >> >> Le 21/07/2015 16:53, Brian E Carpenter a crit : >>> On 22/07/2015 02:18, Alexandru Petrescu wrote: >>>> 1. Brian suggested to recommend that globals should be there on >>>> the machines having ULAs as well, if I understand correctly. >>>> >>>> But I think so only on some Hosts, mainly the Hosts of end users. >>> >>> All hosts that need external communication. >> >> I agree, all hosts that need external communication. >> >> >>>> 2. the ULA RFC suggests a ULA prefix can be generated out of a MAC >>>> address. That sixxs implementation does it. Except it takes it >>>> too serious: it does not accept a MAC address which is not a real >>>> MAC address - in that oui.txt. And random MAC addresses (for >>>> privacy) certainly are not in that oui.txt. >>>> >>>> I think this is an undesirable situation to be in: unable to >>>> generate ULAs because the only tool out there (sixxs) can't refuses >>>> a copy paste a MAC address from the widely used windows 7 laptops. >>> >>> That isn't a standards issue, but I agree that operationally, there >>> needs to be a viable way for anyone to generate a random number. Wait >>> a minute, that doesn't seem hard. >> >> It's easily done centrally, but in a distributed manner it's harder - >> how am I sure the network I connect to has ULAs generated such that they >> dont clash with mine? > > *YOU* generate you ULA properly. You for single or plural? Until now I was saying to my peers: I take 192.168.1.1 please take something else and I'll route to you. Now I am saying: generate ULA properly, make it truly random. But how? >>>> I am not sure what the problem is, but it's very good to have a >>>> very easy way to generate ULAs. >>>> >>>> 3. in an enterprise deployment there was a problem of ULAs deployed >>>> in a intra-network and another ULA space in another intra-network, >>>> of the same enterprise. So we wanted to make sure two things: the >>>> two ULA spaces are distinct, or otherwise make sure the gateway >>>> router does not route between the two intranets' ULAs (but yes, >>>> route between their respective GUAs). >>> >>> Why not? ULA to ULA routing on a private link might be desired (e.g. >>> after two networks merge without renumbering). From a routing PoV >>> there is nothing special about a ULA prefix; we just need to >>> configure carefully where it is routed and where it is not routed. >> >> Yes, private routing should be ok, but only if these ULAs are unique. >> If people on different networks use different generation methods then >> it's dubious to be sure of the uniqueness. Maybe I choose fd00:1::/64 >> being sure that no random generator will make it, and it happens my >> neighbors does the same. That leads to conflict on fd00:1::/64 and we >> dont want routing enabled between the two. > > Generate. Don't choose. If you generate then you should be ok. Ok. But it's much easier to choose. We want simple ULA addresses, simple to remember, simple to type, ideally based on a dictionary. This is something everybody building even the simplest IPv6 network has to do: what simple ULA IPv6 addresses to put there to not break something. Alex > >>> Anyway - I'd like to see the draft progress. Has it already had a >>> WGLC? >> >> I agree, it already has advice in it worth progressing. >> >> Alex >> >>> >>> Brian >>> >>>> I am not sure how to translate that into advice, because I am not >>>> sure how it will unfold in the near future. >>>> >>>> Alex >>>> >>>> Le 21/07/2015 16:02, Fred Baker (fred) a crit : >>>>> https://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations >>>>> >>>>> >>>> >>>>> >> "Considerations For Using Unique Local Addresses", Bing Liu, Sheng >>>>> Jiang, 2015-05-03 >>>>> >>>>> This draft came up from the floor this afternoon. I think we >>>>> need some concentrated constructive conversation regarding it - >>>>> we have had a lot of the other kind. >>>>> >>>>> What issues do we need to address to complete it. and what >>>>> specific recommendations would that include? >>>>> >>>>> >>>>> >>>>> _______________________________________________ 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 Tue Jul 21 09:41:09 2015 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 64C731A8F40 for ; Tue, 21 Jul 2015 09:41:07 -0700 (PDT) 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 0fFzr6aFPrhQ for ; Tue, 21 Jul 2015 09:41:05 -0700 (PDT) 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 545911A8AA8 for ; Tue, 21 Jul 2015 09:41:05 -0700 (PDT) Received: from dhcp-b3b7.meeting.ietf.org ([IPv6:2001:67c:370:176:80ea:5653:9df6:4f0c]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t6LGf0Ta063122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 21 Jul 2015 16:41:02 GMT (envelope-from joelja@bogus.com) To: Alexandru Petrescu , Mark Andrews References: <6153A91F-7E9A-4579-BA06-72964568D343@cisco.com> <55AE54D3.7070502@gmail.com> <55AE5D01.5090309@gmail.com> <55AE71F7.8000107@gmail.com> <20150721162835.26A9F338B4ED@rock.dv.isc.org> <55AE742E.9040301@gmail.com> From: joel jaeggli X-Enigmail-Draft-Status: N1110 Message-ID: <55AE761A.3020500@bogus.com> Date: Tue, 21 Jul 2015 18:40:58 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0 MIME-Version: 1.0 In-Reply-To: <55AE742E.9040301@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tbHXSC0LPSio5MklEGE4qCPCdIpB1a9W2" Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Discussion of draft-ietf-v6ops-ula-usage-recommendations 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, 21 Jul 2015 16:41:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tbHXSC0LPSio5MklEGE4qCPCdIpB1a9W2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 7/21/15 6:32 PM, Alexandru Petrescu wrote: >=20 >=20 > Le 21/07/2015 18:28, Mark Andrews a =E9crit : >> >> In message <55AE71F7.8000107@gmail.com>, Alexandru Petrescu writes: >>> >>> >>> Le 21/07/2015 16:53, Brian E Carpenter a crit : >>>> On 22/07/2015 02:18, Alexandru Petrescu wrote: >>>>> 1. Brian suggested to recommend that globals should be there on >>>>> the machines having ULAs as well, if I understand correctly. >>>>> >>>>> But I think so only on some Hosts, mainly the Hosts of end users. >>>> >>>> All hosts that need external communication. >>> >>> I agree, all hosts that need external communication. >>> >>> >>>>> 2. the ULA RFC suggests a ULA prefix can be generated out of a MAC >>>>> address. That sixxs implementation does it. Except it takes it >>>>> too serious: it does not accept a MAC address which is not a real >>>>> MAC address - in that oui.txt. And random MAC addresses (for >>>>> privacy) certainly are not in that oui.txt. >>>>> >>>>> I think this is an undesirable situation to be in: unable to >>>>> generate ULAs because the only tool out there (sixxs) can't refuses= >>>>> a copy paste a MAC address from the widely used windows 7 laptops. >>>> >>>> That isn't a standards issue, but I agree that operationally, there >>>> needs to be a viable way for anyone to generate a random number. Wai= t >>>> a minute, that doesn't seem hard. >>> >>> It's easily done centrally, but in a distributed manner it's harder -= >>> how am I sure the network I connect to has ULAs generated such that t= hey >>> dont clash with mine? >> >> *YOU* generate you ULA properly. >=20 > You for single or plural? >=20 > Until now I was saying to my peers: I take 192.168.1.1 please take > something else and I'll route to you. that's to of dramatically underselling the amount of coordination required to use rc1918 space between administrative domains. > Now I am saying: generate ULA properly, make it truly random. But how?= >=20 >>>>> I am not sure what the problem is, but it's very good to have a >>>>> very easy way to generate ULAs. >>>>> >>>>> 3. in an enterprise deployment there was a problem of ULAs deployed= >>>>> in a intra-network and another ULA space in another intra-network, >>>>> of the same enterprise. So we wanted to make sure two things: the >>>>> two ULA spaces are distinct, or otherwise make sure the gateway >>>>> router does not route between the two intranets' ULAs (but yes, >>>>> route between their respective GUAs). >>>> >>>> Why not? ULA to ULA routing on a private link might be desired (e.g.= >>>> after two networks merge without renumbering). From a routing PoV >>>> there is nothing special about a ULA prefix; we just need to >>>> configure carefully where it is routed and where it is not routed. >>> >>> Yes, private routing should be ok, but only if these ULAs are unique.= >>> If people on different networks use different generation methods then= >>> it's dubious to be sure of the uniqueness. Maybe I choose fd00:1::/6= 4 >>> being sure that no random generator will make it, and it happens my >>> neighbors does the same. That leads to conflict on fd00:1::/64 and w= e >>> dont want routing enabled between the two. >> >> Generate. Don't choose. If you generate then you should be ok. >=20 > Ok. >=20 > But it's much easier to choose. >=20 > We want simple ULA addresses, simple to remember, simple to type, > ideally based on a dictionary. Wierdly when you go to an RIR you don't get to pick what your prefix is..= =2E if you don't see your selection with randomness your probability of a collision within your organzation is going to go way up. > This is something everybody building even the simplest IPv6 network has= > to do: what simple ULA IPv6 addresses to put there to not break somethi= ng. I don't have any ula in in my production networks. > Alex >=20 >> >>>> Anyway - I'd like to see the draft progress. Has it already had a >>>> WGLC? >>> >>> I agree, it already has advice in it worth progressing. >>> >>> Alex >>> >>>> >>>> Brian >>>> >>>>> I am not sure how to translate that into advice, because I am not >>>>> sure how it will unfold in the near future. >>>>> >>>>> Alex >>>>> >>>>> Le 21/07/2015 16:02, Fred Baker (fred) a crit : >>>>>> https://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendat= ions >>>>>> >>>>>> >>>>>> >>>>> >>>>>> >>> "Considerations For Using Unique Local Addresses", Bing Liu, Sheng >>>>>> Jiang, 2015-05-03 >>>>>> >>>>>> This draft came up from the floor this afternoon. I think we >>>>>> need some concentrated constructive conversation regarding it - >>>>>> we have had a lot of the other kind. >>>>>> >>>>>> What issues do we need to address to complete it. and what >>>>>> specific recommendations would that include? >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ 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 >> >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --tbHXSC0LPSio5MklEGE4qCPCdIpB1a9W2 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 iEYEARECAAYFAlWudhoACgkQ8AA1q7Z/VrIfbgCdHrn2QfqNtF4jCAGb9XVdtGOt xe4An0qHBOz6M6raQuplB/+nwnq1HLRV =m5on -----END PGP SIGNATURE----- --tbHXSC0LPSio5MklEGE4qCPCdIpB1a9W2-- From nobody Tue Jul 21 11:05:21 2015 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 87A291A8935 for ; Tue, 21 Jul 2015 11:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZ2nIbo8bZqy for ; Tue, 21 Jul 2015 11:05:18 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450: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 126131A888F for ; Tue, 21 Jul 2015 11:05:18 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so129796552wib.0 for ; Tue, 21 Jul 2015 11:05:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=DOjsl1gxv6Xm1aBCD05cq/jgVVkZF/3W6q6klhQZt34=; b=qR9Vs5oCaNy3WGuto74c6RdCAJor3q9sFfuVIdcpfBXkzwsC0TvnSDRk9b1TyRUQS6 R0LQuFBIv63mIvu4/TGYZZezVKROVLhLjeHQb0+0RuhAQkfL6tnIToTw093jpQrT4Ar5 /zhqDaLHK+dSxb37NR+lg5J27Ls7XwHaPiW6d5u9MTq5UEkFIeqsWxkVxxzRZqkoptEI 0ggw5w44YZnszeEc8BQrk++Iq8jSFhSoLwR0IjJ3DjP/pp8tX7SVUvCItueaVIuduLcf MRiNkvqRKWNWrpv0e6JlWPFtWXQrsFE4Hs4l5KlmPc/nH3rUXoweTKnVAu0CvJQDONxs wyIA== X-Received: by 10.194.109.97 with SMTP id hr1mr68027645wjb.95.1437501916744; Tue, 21 Jul 2015 11:05:16 -0700 (PDT) Received: from ?IPv6:2001:67c:370:136:28cc:dc4c:9703:6781? ([2001:67c:370:136:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id s5sm17995299wik.2.2015.07.21.11.05.15 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Jul 2015 11:05:16 -0700 (PDT) Message-ID: <55AE89DE.60701@gmail.com> Date: Wed, 22 Jul 2015 06:05:18 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Alexandru Petrescu References: <6153A91F-7E9A-4579-BA06-72964568D343@cisco.com> <55AE54D3.7070502@gmail.com> <55AE5D01.5090309@gmail.com> <55AE71F7.8000107@gmail.com> <20150721162835.26A9F338B4ED@rock.dv.isc.org> <55AE742E.9040301@gmail.com> In-Reply-To: <55AE742E.9040301@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Discussion of draft-ietf-v6ops-ula-usage-recommendations 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, 21 Jul 2015 18:05:19 -0000 On 22/07/2015 04:32, Alexandru Petrescu wrote: ... > Now I am saying: generate ULA properly, make it truly random. But how? This is not the place to debate the philosophical question whether the phrase "truly random" has any meaning. The (im)probability of collisions is thoroughly covered in RFC 4193, section 3.2.3. I would advise using something better than rand(); you can even read RFC 4086, but really this is all very old news. Brian From nobody Tue Jul 21 11:43:50 2015 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 0281C1ACD8A for ; Tue, 21 Jul 2015 11:43:49 -0700 (PDT) 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 zv3ztn5RbsVa for ; Tue, 21 Jul 2015 11:43:47 -0700 (PDT) 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 12E2C1ACD7E for ; Tue, 21 Jul 2015 11:43:46 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 9712362AA4 for ; Tue, 21 Jul 2015 20:43:44 +0200 (CEST) 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 58ABF60152 for ; Tue, 21 Jul 2015 20:43:44 +0200 (CEST) Received: (qmail 91855 invoked by uid 1007); 21 Jul 2015 20:43:44 +0200 Date: Tue, 21 Jul 2015 20:43:44 +0200 From: Gert Doering To: Alexandru Petrescu Message-ID: <20150721184344.GH90924@Space.Net> References: <6153A91F-7E9A-4579-BA06-72964568D343@cisco.com> <55AE54D3.7070502@gmail.com> <55AE5D01.5090309@gmail.com> <55AE71F7.8000107@gmail.com> <20150721162835.26A9F338B4ED@rock.dv.isc.org> <55AE742E.9040301@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55AE742E.9040301@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] Discussion of draft-ietf-v6ops-ula-usage-recommendations 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, 21 Jul 2015 18:43:49 -0000 Hi, On Tue, Jul 21, 2015 at 06:32:46PM +0200, Alexandru Petrescu wrote: > We want simple ULA addresses, simple to remember, simple to type, > ideally based on a dictionary. Go away. DNS exists. 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 Jul 21 13:14:17 2015 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 77A521B300D for ; Tue, 21 Jul 2015 13:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZXVQFmIE6vA for ; Tue, 21 Jul 2015 13:14:14 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2E861B2FED for ; Tue, 21 Jul 2015 13:14:13 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6LKEBBw019453; Tue, 21 Jul 2015 22:14:11 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4ACD420252A; Tue, 21 Jul 2015 22:17:46 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 3367F200CCD; Tue, 21 Jul 2015 22:17:46 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.163]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6LKEAvw017010; Tue, 21 Jul 2015 22:14:11 +0200 To: Gert Doering References: <6153A91F-7E9A-4579-BA06-72964568D343@cisco.com> <55AE54D3.7070502@gmail.com> <55AE5D01.5090309@gmail.com> <55AE71F7.8000107@gmail.com> <20150721162835.26A9F338B4ED@rock.dv.isc.org> <55AE742E.9040301@gmail.com> <20150721184344.GH90924@Space.Net> From: Alexandru Petrescu Message-ID: <55AEA803.8070504@gmail.com> Date: Tue, 21 Jul 2015 22:13:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150721184344.GH90924@Space.Net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Discussion of draft-ietf-v6ops-ula-usage-recommendations 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, 21 Jul 2015 20:14:15 -0000 Le 21/07/2015 20:43, Gert Doering a écrit : > Hi, > > On Tue, Jul 21, 2015 at 06:32:46PM +0200, Alexandru Petrescu wrote: >> We want simple ULA addresses, simple to remember, simple to type, >> ideally based on a dictionary. > > Go away. DNS exists. Of course, DNS exists and has its role in giving good names to addresses. Yet ULA gives a certain freedom in the hextets after fd00::, and I would not waste it by generating a fd00:ca10:8fa3 which has no logic. fd00:cafe:: is a random prefix, easier to pronounce, to remember and to tell on the phone. Alex > > Gert Doering > -- NetMaster > From nobody Tue Jul 21 13:14:23 2015 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 802331B300C for ; Tue, 21 Jul 2015 13:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBbL1EdgchKA for ; Tue, 21 Jul 2015 13:14:19 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D94511B3016 for ; Tue, 21 Jul 2015 13:14:18 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6LKEGAq011090; Tue, 21 Jul 2015 22:14:16 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id AE02520252A; Tue, 21 Jul 2015 22:17:50 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 96C79200CCD; Tue, 21 Jul 2015 22:17:50 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.163]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6LKEEqf017019; Tue, 21 Jul 2015 22:14:15 +0200 To: Brian E Carpenter References: <6153A91F-7E9A-4579-BA06-72964568D343@cisco.com> <55AE54D3.7070502@gmail.com> <55AE5D01.5090309@gmail.com> <55AE71F7.8000107@gmail.com> <20150721162835.26A9F338B4ED@rock.dv.isc.org> <55AE742E.9040301@gmail.com> <55AE89DE.60701@gmail.com> From: Alexandru Petrescu Message-ID: <55AEA816.1020308@gmail.com> Date: Tue, 21 Jul 2015 22:14:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55AE89DE.60701@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Discussion of draft-ietf-v6ops-ula-usage-recommendations 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, 21 Jul 2015 20:14:22 -0000 Le 21/07/2015 20:05, Brian E Carpenter a ĂŠcrit : > On 22/07/2015 04:32, Alexandru Petrescu wrote: > > ... >> Now I am saying: generate ULA properly, make it truly random. But how? > > This is not the place to debate the philosophical question whether the > phrase "truly random" has any meaning. The (im)probability of collisions is > thoroughly covered in RFC 4193, section 3.2.3. Yes. > I would advise using something better than rand(); you can even read > RFC 4086, but really this is all very old news. I am not telling the old news about how good the randomness may be. But that's ok, next time I will no longer take advices like sixxs. Alex > > Brian > From nobody Tue Jul 21 13:23:11 2015 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 67B581B301F for ; Tue, 21 Jul 2015 13:23:10 -0700 (PDT) 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 cJZzyj-1L2iK for ; Tue, 21 Jul 2015 13:23:08 -0700 (PDT) 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 550451B301E for ; Tue, 21 Jul 2015 13:23:08 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 64E94600DF for ; Tue, 21 Jul 2015 22:23:06 +0200 (CEST) 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 3386D602FE for ; Tue, 21 Jul 2015 22:23:06 +0200 (CEST) Received: (qmail 95454 invoked by uid 1007); 21 Jul 2015 22:23:06 +0200 Date: Tue, 21 Jul 2015 22:23:06 +0200 From: Gert Doering To: Alexandru Petrescu Message-ID: <20150721202306.GI90924@Space.Net> References: <6153A91F-7E9A-4579-BA06-72964568D343@cisco.com> <55AE54D3.7070502@gmail.com> <55AE5D01.5090309@gmail.com> <55AE71F7.8000107@gmail.com> <20150721162835.26A9F338B4ED@rock.dv.isc.org> <55AE742E.9040301@gmail.com> <20150721184344.GH90924@Space.Net> <55AEA803.8070504@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1GFpsN+DA+8qGtn4" Content-Disposition: inline In-Reply-To: <55AEA803.8070504@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] Discussion of draft-ietf-v6ops-ula-usage-recommendations 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, 21 Jul 2015 20:23:10 -0000 --1GFpsN+DA+8qGtn4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Jul 21, 2015 at 10:13:55PM +0200, Alexandru Petrescu wrote: > Yet ULA gives a certain freedom in the hextets after fd00::, and I would= =20 > not waste it by generating a fd00:ca10:8fa3 which has no logic. >=20 > fd00:cafe:: is a random prefix, easier to pronounce, to remember and to= =20 > tell on the phone. I encourage all my competitors to use "easy to pronounce and remember" ULA prefixes. Their address collisions are my saved OPEX. 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 --1GFpsN+DA+8qGtn4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVa6qKd9WwGXkzn/FAQL2yg/+NpVR+AMc6/BZ34EYF7H4jY3lOrudQbIO jVt8uwWSPJ2cboNU465kXbLW1himYFL7Ol2LAj9mefxgowjgx61HuYVxJOtec998 N/VrusHvjB6hA4fA78KNEUH0QXtNt4SP0hEDEh22JQrXAqpsJCTjV5J8w558HORx MuaYuD829kR8kIhfs+BIhJL45V2HMr3Kc++9Ut0N912xPr3UZcNnuT3dY7N1Ejqn olIXSRkgF+FBV7frOxpLzTNVmrfvc9QKlkAy5LpcsSv9vn/mmwHH8XePItlShsrX j3Uw1WSn0Bm5r8ml2hZqNcIxiZJC6ZkmyXxu37oYE9h0DuvSub+9rowoMPd+9LKQ KTC/Mmck3Br8z4kk6vHTZ8HTAioFq8Dmpo9HJC9fJnsAe6OftXWuona6zDRIoJ6g iEfu0d07fvtbZRfbschj6EWwLCBM0EPVetEbv1oWoMaAdkxpR/4b9VuluoqqLbb5 GKO2DO7Njnh9W/7BWUfS2z11qnpMFHgqY5fV8lKGHFwWIBNnzb/BSlpIcj1fUNv/ aZBRl+vtyg3SkDpGxA+8aTVlYTdIWj9KpccW8MwTLUBQUO5VdjchKQqYrjYUX14a ATMSuoO+NteXq6zyfeL66LLDMeW1AgB8rklX4ls1UrG9101QRxIE1MwKg1WRu7G7 ToiVg5+vLKM= =AR4z -----END PGP SIGNATURE----- --1GFpsN+DA+8qGtn4-- From nobody Tue Jul 21 13:27:12 2015 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 E70F41B3042 for ; Tue, 21 Jul 2015 13:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 320vE9Z5b1NV for ; Tue, 21 Jul 2015 13:27:09 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A4E31B3044 for ; Tue, 21 Jul 2015 13:26:49 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6LKQlHX021665; Tue, 21 Jul 2015 22:26:47 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 18D0320242A; Tue, 21 Jul 2015 22:30:22 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 0127C2020B4; Tue, 21 Jul 2015 22:30:22 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.163]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6LKQkbO024678; Tue, 21 Jul 2015 22:26:47 +0200 To: Gert Doering References: <6153A91F-7E9A-4579-BA06-72964568D343@cisco.com> <55AE54D3.7070502@gmail.com> <55AE5D01.5090309@gmail.com> <55AE71F7.8000107@gmail.com> <20150721162835.26A9F338B4ED@rock.dv.isc.org> <55AE742E.9040301@gmail.com> <20150721184344.GH90924@Space.Net> <55AEA803.8070504@gmail.com> <20150721202306.GI90924@Space.Net> From: Alexandru Petrescu Message-ID: <55AEAB06.4000306@gmail.com> Date: Tue, 21 Jul 2015 22:26:46 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150721202306.GI90924@Space.Net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Discussion of draft-ietf-v6ops-ula-usage-recommendations 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, 21 Jul 2015 20:27:11 -0000 Le 21/07/2015 22:23, Gert Doering a écrit : > Hi, > > On Tue, Jul 21, 2015 at 10:13:55PM +0200, Alexandru Petrescu wrote: >> Yet ULA gives a certain freedom in the hextets after fd00::, and I would >> not waste it by generating a fd00:ca10:8fa3 which has no logic. >> >> fd00:cafe:: is a random prefix, easier to pronounce, to remember and to >> tell on the phone. > > I encourage all my competitors to use "easy to pronounce and remember" > ULA prefixes. Their address collisions are my saved OPEX. Ok for competitors. But for friends? Alex > > Gert Doering > -- NetMaster > From nobody Tue Jul 21 13:29:45 2015 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 488AA1B304D for ; Tue, 21 Jul 2015 13:29:43 -0700 (PDT) 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 IfIWP9vfWkDj for ; Tue, 21 Jul 2015 13:29:42 -0700 (PDT) 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 116451B304B for ; Tue, 21 Jul 2015 13:29:41 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 0B79362CAA for ; Tue, 21 Jul 2015 22:29:40 +0200 (CEST) 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 B3F8B60146 for ; Tue, 21 Jul 2015 22:29:39 +0200 (CEST) Received: (qmail 95627 invoked by uid 1007); 21 Jul 2015 22:29:39 +0200 Date: Tue, 21 Jul 2015 22:29:39 +0200 From: Gert Doering To: Alexandru Petrescu Message-ID: <20150721202939.GJ90924@Space.Net> References: <6153A91F-7E9A-4579-BA06-72964568D343@cisco.com> <55AE54D3.7070502@gmail.com> <55AE5D01.5090309@gmail.com> <55AE71F7.8000107@gmail.com> <20150721162835.26A9F338B4ED@rock.dv.isc.org> <55AE742E.9040301@gmail.com> <20150721184344.GH90924@Space.Net> <55AEA803.8070504@gmail.com> <20150721202306.GI90924@Space.Net> <55AEAB06.4000306@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WP/lS5xSWAOC+/uo" Content-Disposition: inline In-Reply-To: <55AEAB06.4000306@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] Discussion of draft-ietf-v6ops-ula-usage-recommendations 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, 21 Jul 2015 20:29:43 -0000 --WP/lS5xSWAOC+/uo Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Jul 21, 2015 at 10:26:46PM +0200, Alexandru Petrescu wrote: > Le 21/07/2015 22:23, Gert Doering a =E9crit : > > > > On Tue, Jul 21, 2015 at 10:13:55PM +0200, Alexandru Petrescu wrote: > >> Yet ULA gives a certain freedom in the hextets after fd00::, and I wou= ld > >> not waste it by generating a fd00:ca10:8fa3 which has no logic. > >> > >> fd00:cafe:: is a random prefix, easier to pronounce, to remember and to > >> tell on the phone. > > > > I encourage all my competitors to use "easy to pronounce and remember" > > ULA prefixes. Their address collisions are my saved OPEX. >=20 > Ok for competitors. >=20 > But for friends? Isn't that implicitely clear? Be a good netizen, follow RFC4193 when generating ULAs - or use GUAs instead. And totally forget about "easy to pronouce, remember, tell on phone" (and learn about DNS and network automatization). 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 --WP/lS5xSWAOC+/uo Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVa6rs99WwGXkzn/FAQK+tw//dlBXPbFO3fdgZd6q+HrnvB+HFwETwU12 cPGeWryVf60SeIy1t56tYEuDtPirEbz5afOfvDoln5LYphS41n7fXodiWqYoPSkT F6GehiXDR1+fQHTCGmL4Nu/Fi7j0wxBGBgH1v3P7AtBkNoXCZt+RQNVGuXhgAska nNcfCQFd1tRl5UfHOu2SPIQkBwQxpMSKN8G1T8VwIkMlIN/FaUQ92VCPSQTyigGH Qix2AawFkpZBZmdm9o7bYIEivwQbSBQmVlufUKirxSrlihlmXAAMo2uRNGpizafv 4FWNEaWBMwN9l7JVslx9iN+0Wp1O/E7srwV/EvRbMxzMXHm9m8EKvdEtKAKGSahc cqMAB0qA54Q9BWyrnlNLksOPn0Cja7GkvNelZMtO4Hyg1l3Gz4oYtRNa211aOGrf H4kFrC7g9NwMlqLAItrCCiQMZlauCo+ibsGkvldNeZIKDcPcS6dbBdedCxGlKG9g FCD8QACKz2J/L5XptYxVUMhy1VxOxDpOwxpayrgWSdikN4LVJjYx1SDWs5XcFhN2 Ea6IOfVKf3lXSDc3QLiwuDomErPxnD1qsHKdw0hTFMl4YNbE4QfarBisxJ0jzidU 1BExBSUrIUPBhdLPf21cQqdf/4AO+DsaIpz9AYZqax3B7ymX7Ckb+aHoEeCXw/Aj 4I0NZbs2Bls= =VK8r -----END PGP SIGNATURE----- --WP/lS5xSWAOC+/uo-- From nobody Tue Jul 21 15:41:49 2015 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 B80851A887C for ; Tue, 21 Jul 2015 15:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 8Hk7aewNWQ5h for ; Tue, 21 Jul 2015 15:41:45 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::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 B3E501A6FCB for ; Tue, 21 Jul 2015 15:41:44 -0700 (PDT) Received: by lbbyj8 with SMTP id yj8so125445510lbb.0 for ; Tue, 21 Jul 2015 15:41:43 -0700 (PDT) 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=j/6wyGqN8bvgwP09wQIl0DdRvZQn0Rf9/ajNXy8BBAk=; b=R3JkP3UFo/A4droha53UPOAVz/C/Dd94LsyRog0Sd5G5jjl1PO3+TX8vWE41mjHhyf 5p/GEKHhY1EGLxANcFY5adKxsvNxr60RRYMbTBllpG/wEaIrUaJRhvqip59UhuJxAFr/ U2Uuv1eRIeCHlKIO+KMXVK+JFsHrF1R0RnrvmhB/AWW4gbRRbzUA3bNsVdQEepGMYCR6 7xd0FJSwM3Mggk/tkyNE1kzdvg4M9wCRuiChsoirKsqXddBt1LV2CKgTsG71yLUTq7PQ KpHkEplM5RT6GJ7KlKpH5hy0IkI+1/40emxkGIo3OjttJJ0x9S/nsZHisLI9OiS9XXIW ytiA== MIME-Version: 1.0 X-Received: by 10.112.161.40 with SMTP id xp8mr35011823lbb.71.1437518503162; Tue, 21 Jul 2015 15:41:43 -0700 (PDT) Received: by 10.25.41.146 with HTTP; Tue, 21 Jul 2015 15:41:43 -0700 (PDT) In-Reply-To: References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> <55AD3B64.5070400@acm.org> Date: Tue, 21 Jul 2015 23:41:43 +0100 Message-ID: From: Nabil Benamar To: Owen DeLong Content-Type: multipart/alternative; boundary=001a11c25f52bd3ad0051b6a5b26 Archived-At: Cc: "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" , v6ops list Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 21 Jul 2015 22:41:47 -0000 --001a11c25f52bd3ad0051b6a5b26 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Folks, I support this document which is very informative, useful and its implementation will certainly reduce energy consumption due to excessive Multicast RA sent. The proposed algorithm seems to be suitable for this end ! Best regards On Tue, Jul 21, 2015 at 4:38 PM, Owen DeLong wrote: > It seems to me that the following algorithm would be relatively easy to > implement > and provide reasonable network optimization=E2=80=A6 > > > On receipt of an RS: > > if(multicast_ra_time_remaining > 15 seconds) > { > Send_Unicast_ra > } > else > { > Send_Multicast_ra > reset_multicast_timer > } > > In this way, if the timing is reasonably close, you multicast a packet yo= u > were about to send > anyway, but if the timing isn=E2=80=99t close, you=E2=80=99re not wasting= multicast > bandwidth answering a single > node where nobody else cares. > > Overall, I=E2=80=99ve always thought that multicast response to RS was ki= nd of > silly. It=E2=80=99s probably most > harmful on WiFi. > > Owen > > > On Jul 21, 2015, at 02:33 , Andrew =F0=9F=91=BD Yourtchenko > wrote: > > > > On 7/20/15, Erik Nordmark wrote: > >> On 7/17/15 9:34 AM, Fred Baker (fred) wrote: > >>>> So the next logical thing to do would be to have the router default = to > >>>> unicast Router Advertisements, measure the rate of received Router > >>>> Solicitations, and switch to multicast RA mode past a certain > >>>> threshold to cover this sort of situation. Once the number of RSes > >>>> falls, it switches back to unicast RA mode. > >>>> > >>>> That would get rid of the configuration knob proposed in this ID, an= d > >>>> is behaviour that I think could be universal for all link types, > >>>> rather than just for the case of wireless ones with mobile devices. > >>> If it were me implementing it, I think I would go about this in a > little > >>> different way, hopefully simpler. I would want to send at most one > (e.g., > >>> either zero or one) RA per some interval (a second?). In the normal > case, > >>> that is sent unicast. However, having sent a unicast RA at time t, if= I > >>> now receive another RS before t+1, I send the next one (at time t+1) > as a > >>> multicast. > >> > >> First of all I support this document as a WG document. > >> > >> But in terms of implementation, isn't it simpler to always(*) respond = to > >> a RS with a unicast RA? > > > > Yes. I did not respond on-list yet - but from operational perspective > > "always send solRA unicast" / "always send solRA multicast" definitely > > wins in my book, and I'd avoid premature optimizations (but maybe we > > can say the implementers are explicitly free to do their own > > optimizations if they see fit) > > > > That said, will be very interesting to hear data from folks who will > > run "all-unicast solRA", in real networks and then compare the effect > > of their proposal optimizations on their real-world scenarios. > > > >> As background, the text in RFC4861 comes from the old concern that all > >> devices might boot at the same time when the power is re-established > >> after a building power failure; that doesn't happen since most devices > >> (laptops, smartphones, IoT devices) have batteries today. In that case > >> it might have made sense to sending fewer RA messages by using > multicast. > >> > >> (*) the only case in RFC 4861 when I think a multicast response might = be > >> considered is when the source IPv6 address in the RS is the unspecifie= d > >> address. Further, an implementation which rate limits received RS > >> packets (e.g., CoPP in a router) might also want to detect when the ra= te > >> limit might have dropped RS packets and multicast an RA in that case. > >> > >> > >> I do wonder why implementations haven't already changed to send unicas= t > >> solicited RA, and whether it would make a difference if we have an > > > > TBH that's my concern as well. I think we should tweak the text in > > 4861 to encourage a bit more consideration on the implementer's side. > > > >> informational document asking them to do this. Alternatively we could > >> have a proposed standard which updates section 6.2.6 to change the "MA= Y > >> unicast" to a "SHOULD unicast". > > > > Yeah, I actually have had the different text aimed for 6man, but > > Lorenzo's concern was 6man would say "there is no protocol update > > here, go away", so he rewrote it for v6ops. > > > > We should probably discuss this at the mic and get the opinion of the > > 6man chairs - if there is no outright "no" on this, a normative doc > > would be a better way to convince the implementers ? > > > >> > >> FWIW the draft incorrectly refers to section 6.2.4 instead of 6.2.6. > > > > Nice catch, thanks! > > > > --a > > > >> > >> Thanks, > >> Erik > >> > >>> > >>> > >>> _______________________________________________ > >>> 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 > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a11c25f52bd3ad0051b6a5b26 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Folks,

I support this document which is = very informative, useful and its implementation will certainly reduce energ= y consumption due to excessive Multicast RA sent. The proposed algorithm se= ems to be suitable for this end !


Best regards


On Tue, Jul 21, 2015 at 4:38 PM, Owen DeLong= <owen@delong.com> wrote:
It= seems to me that the following algorithm would be relatively easy to imple= ment
and provide reasonable network optimization=E2=80=A6


On receipt of an RS:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 if(multicast_ra_time_remaining > 15 seconds)=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Send_Unicast_ra
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 else
=C2=A0 =C2=A0 =C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Send_Multicast_ra
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 reset_multicast_timer
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }

In this way, if the timing is reasonably close, you multicast a packet you = were about to send
anyway, but if the timing isn=E2=80=99t close, you=E2=80=99re not wasting m= ulticast bandwidth answering a single
node where nobody else cares.

Overall, I=E2=80=99ve always thought that multicast response to RS was kind= of silly. It=E2=80=99s probably most
harmful on WiFi.

Owen

> On Jul 21, 2015, at 02:33 , Andrew =F0=9F=91=BD Yourtchenko <ayourtch@gmail.com> wrote:
>
> On 7/20/15, Erik Nordmark <nord= mark@acm.org> wrote:
>> On 7/17/15 9:34 AM, Fred Baker (fred) wrote:
>>>> So the next logical thing to do would be to have the route= r default to
>>>> unicast Router Advertisements, measure the rate of receive= d Router
>>>> Solicitations, and switch to multicast RA mode past a cert= ain
>>>> threshold to cover this sort of situation. Once the number= of RSes
>>>> falls, it switches back to unicast RA mode.
>>>>
>>>> That would get rid of the configuration knob proposed in t= his ID, and
>>>> is behaviour that I think could be universal for all link = types,
>>>> rather than just for the case of wireless ones with mobile= devices.
>>> If it were me implementing it, I think I would go about this i= n a little
>>> different way, hopefully simpler. I would want to send at most= one (e.g.,
>>> either zero or one) RA per some interval (a second?). In the n= ormal case,
>>> that is sent unicast. However, having sent a unicast RA at tim= e t, if I
>>> now receive another RS before t+1, I send the next one (at tim= e t+1) as a
>>> multicast.
>>
>> First of all I support this document as a WG document.
>>
>> But in terms of implementation, isn't it simpler to always(*) = respond to
>> a RS with a unicast RA?
>
> Yes. I did not respond on-list yet - but from operational perspective<= br> > "always send solRA unicast" / "always send solRA multic= ast" definitely
> wins in my book, and I'd avoid premature optimizations (but maybe = we
> can say the implementers are explicitly free to do their own
> optimizations if they see fit)
>
> That said, will be very interesting to hear data from folks who will > run "all-unicast solRA", in real networks and then compare t= he effect
> of their proposal optimizations on their real-world scenarios.
>
>> As background, the text in RFC4861 comes from the old concern that= all
>> devices might boot at the same time when the power is re-establish= ed
>> after a building power failure; that doesn't happen since most= devices
>> (laptops, smartphones, IoT devices) have batteries today. In that = case
>> it might have made sense to sending fewer RA messages by using mul= ticast.
>>
>> (*) the only case in RFC 4861 when I think a multicast response mi= ght be
>> considered is when the source IPv6 address in the RS is the unspec= ified
>> address. Further, an implementation which rate limits received RS<= br> >> packets (e.g., CoPP in a router) might also want to detect when th= e rate
>> limit might have dropped RS packets and multicast an RA in that ca= se.
>>
>>
>> I do wonder why implementations haven't already changed to sen= d unicast
>> solicited RA, and whether it would make a difference if we have an=
>
> TBH that's my concern as well. I think we should tweak the text in=
> 4861 to encourage a bit more consideration on the implementer's si= de.
>
>> informational document asking them to do this. Alternatively we co= uld
>> have a proposed standard which updates section 6.2.6 to change the= "MAY
>> unicast" to a "SHOULD unicast".
>
> Yeah, I actually have had the different text aimed for 6man, but
> Lorenzo's concern was 6man would say "there is no protocol up= date
> here, go away", so he rewrote it for v6ops.
>
> We should probably discuss this at the mic and get the opinion of the<= br> > 6man chairs - if there is no outright "no" on this, a normat= ive doc
> would be a better way to convince the implementers ?
>
>>
>> FWIW the draft incorrectly refers to section 6.2.4 instead of 6.2.= 6.
>
> Nice catch, thanks!
>
> --a
>
>>
>> Thanks,
>>=C2=A0 =C2=A0 Erik
>>
>>>
>>>
>>> _______________________________________________
>>> v6ops mailing list
>>> v6ops@ietf.org
>>> https://www.ietf.org/mailman/listinfo/v6ops<= /a>
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops<= br> >>
>
> _______________________________________________
> 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

--001a11c25f52bd3ad0051b6a5b26-- From nobody Tue Jul 21 18:47:15 2015 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 BCE1C1A8972 for ; Tue, 21 Jul 2015 18:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.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, GB_I_LETTER=-2, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=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 t8Dw0_OS2sNU for ; Tue, 21 Jul 2015 18:47:11 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::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 ACE1A1A8967 for ; Tue, 21 Jul 2015 18:47:11 -0700 (PDT) Received: by igbij6 with SMTP id ij6so124900125igb.1 for ; Tue, 21 Jul 2015 18:47:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=UJNGD1SmiB2SJYZatDvixHqadcjDRH3gvhT3oENQghA=; b=ZHw0z36cf5/rzKrvoY8SzDrlR7lQOlcZ7RVsgIDL+6Uh4cyGignaVjkW0gLykYwhiI LFbQ98ocOBHcxuEkO3qmVDaYd5hya2zMqJW7EQqPIBXc+1acw/IUVyTE6DmK5Rn0Dent 4AFQf3awchhIAVgSDx93/mHsYBFRuzuOqGtS1pS7AcJTCE19L8el2Sfrm/Ew0YvWLkri ZqOl8pAWiWlNA+x2vKYASmsihaeWevB7qR77+Mbfyxvkkin4qKP2lAZqWvHnKnFxMnyT fe+/WBSG9p1/2Adv7y7XmOfsqv8y6FjJZE6wH38reR9qdj03JA3Oy1U/YBb2tTvQqlbw PSQg== X-Received: by 10.107.132.157 with SMTP id o29mr47426494ioi.104.1437529631093; Tue, 21 Jul 2015 18:47:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.169.143 with HTTP; Tue, 21 Jul 2015 18:46:41 -0700 (PDT) In-Reply-To: <55AEAB06.4000306@gmail.com> References: <6153A91F-7E9A-4579-BA06-72964568D343@cisco.com> <55AE54D3.7070502@gmail.com> <55AE5D01.5090309@gmail.com> <55AE71F7.8000107@gmail.com> <20150721162835.26A9F338B4ED@rock.dv.isc.org> <55AE742E.9040301@gmail.com> <20150721184344.GH90924@Space.Net> <55AEA803.8070504@gmail.com> <20150721202306.GI90924@Space.Net> <55AEAB06.4000306@gmail.com> From: Mark Smith Date: Wed, 22 Jul 2015 11:46:41 +1000 Message-ID: To: Alexandru Petrescu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: v6ops list Subject: Re: [v6ops] Discussion of draft-ietf-v6ops-ula-usage-recommendations 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, 22 Jul 2015 01:47:13 -0000 On 22 July 2015 at 06:26, Alexandru Petrescu wrote: > > > Le 21/07/2015 22:23, Gert Doering a =C3=A9crit : >> >> Hi, >> >> On Tue, Jul 21, 2015 at 10:13:55PM +0200, Alexandru Petrescu wrote: >>> >>> Yet ULA gives a certain freedom in the hextets after fd00::, and I woul= d >>> not waste it by generating a fd00:ca10:8fa3 which has no logic. >>> >>> fd00:cafe:: is a random prefix, easier to pronounce, to remember and to >>> tell on the phone. >> >> >> I encourage all my competitors to use "easy to pronounce and remember" >> ULA prefixes. Their address collisions are my saved OPEX. > > > Ok for competitors. > > But for friends? > Your friends usually do the right thing too or can be encouraged to. But even if they don't, but you do, you won't have a ULA address space collision. If you both choose the same ULA value, you've both failed to learn from history and will both will pay the price. RFC3879 describes the prices you'll effectively be paying. You would also be surprised at how easy it is to remember a random value if you use it enough e.g., type it in enough. I was assigned a random 6 letter character/number username at an employer in 1998, that I used up until the end of 1999. I suspect it was so that usernames weren't guessable, as a further security measure. I can still very easily remember it today, despite not having used it regularly since then. Regards, Mark. > Alex > >> >> Gert Doering >> -- NetMaster >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Jul 21 20:09:36 2015 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 70C371ACD0E for ; Tue, 21 Jul 2015 20:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, 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 AQOAxEoT5d8F for ; Tue, 21 Jul 2015 20:09:32 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C59721ACD2C for ; Tue, 21 Jul 2015 20:09:31 -0700 (PDT) Received: by igbpg9 with SMTP id pg9so79171089igb.0 for ; Tue, 21 Jul 2015 20:09:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=qlPAygV6V+d6piHENj0CXfv+IL8+FHV+RSBUWDY7Hyo=; b=eRXINWo2QoaARp8VlqsqR5vF6XYE8Zqe9nTe1kR+a+YoQA/4dsTwpC5MP1eXSPYfOe O2OGBAyiA68gSLOtCopwnu/tlmiaKCNn2DgxQjEtfhmlibC+1fuNyt356l2T0og8QLOv pvf5oLK0pVztFF3/bkvrVwyblrHyvSLb6KT96s1FcJynqMWaOFNdZf5MTX0yRFB3VMsK 2myyZF41AlKXZLkCZd7I/dEXajYN1acus14zZdGta9kth0XJUBAbzPxmbMTENdZXwGje VenE76rerU69P/sZyWa+bLUZmV7IetLSLghiPkQDftgIahIWlz++oJo+/K7jTjt+pxs+ bbDg== X-Received: by 10.50.40.39 with SMTP id u7mr1505898igk.71.1437534571204; Tue, 21 Jul 2015 20:09:31 -0700 (PDT) Received: from [10.16.18.112] ([142.55.0.11]) by smtp.googlemail.com with ESMTPSA id 69sm54405ioz.10.2015.07.21.20.09.28 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Jul 2015 20:09:29 -0700 (PDT) To: v6ops@ietf.org References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> <55AD3B64.5070400@acm.org> From: Alejandro Acosta Message-ID: <55AF0964.1060006@gmail.com> Date: Tue, 21 Jul 2015 22:39:24 -0430 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------050007020208010703050102" Archived-At: Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 22 Jul 2015 03:09:34 -0000 This is a multi-part message in MIME format. --------------050007020208010703050102 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi There, I also support this document, it's very positive to see that this algorithm will save energy. Regards, Alejandro, El 7/21/2015 a las 6:11 PM, Nabil Benamar escribió: > Hi Folks, > > I support this document which is very informative, useful and its > implementation will certainly reduce energy consumption due to > excessive Multicast RA sent. The proposed algorithm seems to be > suitable for this end ! > > > Best regards > > > > On Tue, Jul 21, 2015 at 4:38 PM, Owen DeLong > wrote: > > It seems to me that the following algorithm would be relatively > easy to implement > and provide reasonable network optimization… > > > On receipt of an RS: > > if(multicast_ra_time_remaining > 15 seconds) > { > Send_Unicast_ra > } > else > { > Send_Multicast_ra > reset_multicast_timer > } > > In this way, if the timing is reasonably close, you multicast a > packet you were about to send > anyway, but if the timing isn’t close, you’re not wasting > multicast bandwidth answering a single > node where nobody else cares. > > Overall, I’ve always thought that multicast response to RS was > kind of silly. It’s probably most > harmful on WiFi. > > Owen > > > On Jul 21, 2015, at 02:33 , Andrew 👽 Yourtchenko > > wrote: > > > > On 7/20/15, Erik Nordmark > wrote: > >> On 7/17/15 9:34 AM, Fred Baker (fred) wrote: > >>>> So the next logical thing to do would be to have the router > default to > >>>> unicast Router Advertisements, measure the rate of received > Router > >>>> Solicitations, and switch to multicast RA mode past a certain > >>>> threshold to cover this sort of situation. Once the number of > RSes > >>>> falls, it switches back to unicast RA mode. > >>>> > >>>> That would get rid of the configuration knob proposed in this > ID, and > >>>> is behaviour that I think could be universal for all link types, > >>>> rather than just for the case of wireless ones with mobile > devices. > >>> If it were me implementing it, I think I would go about this > in a little > >>> different way, hopefully simpler. I would want to send at most > one (e.g., > >>> either zero or one) RA per some interval (a second?). In the > normal case, > >>> that is sent unicast. However, having sent a unicast RA at > time t, if I > >>> now receive another RS before t+1, I send the next one (at > time t+1) as a > >>> multicast. > >> > >> First of all I support this document as a WG document. > >> > >> But in terms of implementation, isn't it simpler to always(*) > respond to > >> a RS with a unicast RA? > > > > Yes. I did not respond on-list yet - but from operational > perspective > > "always send solRA unicast" / "always send solRA multicast" > definitely > > wins in my book, and I'd avoid premature optimizations (but maybe we > > can say the implementers are explicitly free to do their own > > optimizations if they see fit) > > > > That said, will be very interesting to hear data from folks who will > > run "all-unicast solRA", in real networks and then compare the > effect > > of their proposal optimizations on their real-world scenarios. > > > >> As background, the text in RFC4861 comes from the old concern > that all > >> devices might boot at the same time when the power is > re-established > >> after a building power failure; that doesn't happen since most > devices > >> (laptops, smartphones, IoT devices) have batteries today. In > that case > >> it might have made sense to sending fewer RA messages by using > multicast. > >> > >> (*) the only case in RFC 4861 when I think a multicast response > might be > >> considered is when the source IPv6 address in the RS is the > unspecified > >> address. Further, an implementation which rate limits received RS > >> packets (e.g., CoPP in a router) might also want to detect when > the rate > >> limit might have dropped RS packets and multicast an RA in that > case. > >> > >> > >> I do wonder why implementations haven't already changed to send > unicast > >> solicited RA, and whether it would make a difference if we have an > > > > TBH that's my concern as well. I think we should tweak the text in > > 4861 to encourage a bit more consideration on the implementer's > side. > > > >> informational document asking them to do this. Alternatively we > could > >> have a proposed standard which updates section 6.2.6 to change > the "MAY > >> unicast" to a "SHOULD unicast". > > > > Yeah, I actually have had the different text aimed for 6man, but > > Lorenzo's concern was 6man would say "there is no protocol update > > here, go away", so he rewrote it for v6ops. > > > > We should probably discuss this at the mic and get the opinion > of the > > 6man chairs - if there is no outright "no" on this, a normative doc > > would be a better way to convince the implementers ? > > > >> > >> FWIW the draft incorrectly refers to section 6.2.4 instead of > 6.2.6. > > > > Nice catch, thanks! > > > > --a > > > >> > >> Thanks, > >> Erik > >> > >>> > >>> > >>> _______________________________________________ > >>> 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 > > _______________________________________________ > 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 --------------050007020208010703050102 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Hi There,
  I also support this document, it's very positive to see that this algorithm will save energy.

Regards,

Alejandro,

El 7/21/2015 a las 6:11 PM, Nabil Benamar escribiĂł:
Hi Folks,

I support this document which is very informative, useful and its implementation will certainly reduce energy consumption due to excessive Multicast RA sent. The proposed algorithm seems to be suitable for this end !


Best regards



On Tue, Jul 21, 2015 at 4:38 PM, Owen DeLong <owen@delong.com> wrote:
It seems to me that the following algorithm would be relatively easy to implement
and provide reasonable network optimization…


On receipt of an RS:

        if(multicast_ra_time_remaining > 15 seconds)
        {
          Send_Unicast_ra
        }
        else
        {
          Send_Multicast_ra
          reset_multicast_timer
        }

In this way, if the timing is reasonably close, you multicast a packet you were about to send
anyway, but if the timing isn’t close, you’re not wasting multicast bandwidth answering a single
node where nobody else cares.

Overall, I’ve always thought that multicast response to RS was kind of silly. It’s probably most
harmful on WiFi.

Owen

> On Jul 21, 2015, at 02:33 , Andrew 👽 Yourtchenko <ayourtch@gmail.com> wrote:
>
> On 7/20/15, Erik Nordmark <nordmark@acm.org> wrote:
>> On 7/17/15 9:34 AM, Fred Baker (fred) wrote:
>>>> So the next logical thing to do would be to have the router default to
>>>> unicast Router Advertisements, measure the rate of received Router
>>>> Solicitations, and switch to multicast RA mode past a certain
>>>> threshold to cover this sort of situation. Once the number of RSes
>>>> falls, it switches back to unicast RA mode.
>>>>
>>>> That would get rid of the configuration knob proposed in this ID, and
>>>> is behaviour that I think could be universal for all link types,
>>>> rather than just for the case of wireless ones with mobile devices.
>>> If it were me implementing it, I think I would go about this in a little
>>> different way, hopefully simpler. I would want to send at most one (e.g.,
>>> either zero or one) RA per some interval (a second?). In the normal case,
>>> that is sent unicast. However, having sent a unicast RA at time t, if I
>>> now receive another RS before t+1, I send the next one (at time t+1) as a
>>> multicast.
>>
>> First of all I support this document as a WG document.
>>
>> But in terms of implementation, isn't it simpler to always(*) respond to
>> a RS with a unicast RA?
>
> Yes. I did not respond on-list yet - but from operational perspective
> "always send solRA unicast" / "always send solRA multicast" definitely
> wins in my book, and I'd avoid premature optimizations (but maybe we
> can say the implementers are explicitly free to do their own
> optimizations if they see fit)
>
> That said, will be very interesting to hear data from folks who will
> run "all-unicast solRA", in real networks and then compare the effect
> of their proposal optimizations on their real-world scenarios.
>
>> As background, the text in RFC4861 comes from the old concern that all
>> devices might boot at the same time when the power is re-established
>> after a building power failure; that doesn't happen since most devices
>> (laptops, smartphones, IoT devices) have batteries today. In that case
>> it might have made sense to sending fewer RA messages by using multicast.
>>
>> (*) the only case in RFC 4861 when I think a multicast response might be
>> considered is when the source IPv6 address in the RS is the unspecified
>> address. Further, an implementation which rate limits received RS
>> packets (e.g., CoPP in a router) might also want to detect when the rate
>> limit might have dropped RS packets and multicast an RA in that case.
>>
>>
>> I do wonder why implementations haven't already changed to send unicast
>> solicited RA, and whether it would make a difference if we have an
>
> TBH that's my concern as well. I think we should tweak the text in
> 4861 to encourage a bit more consideration on the implementer's side.
>
>> informational document asking them to do this. Alternatively we could
>> have a proposed standard which updates section 6.2.6 to change the "MAY
>> unicast" to a "SHOULD unicast".
>
> Yeah, I actually have had the different text aimed for 6man, but
> Lorenzo's concern was 6man would say "there is no protocol update
> here, go away", so he rewrote it for v6ops.
>
> We should probably discuss this at the mic and get the opinion of the
> 6man chairs - if there is no outright "no" on this, a normative doc
> would be a better way to convince the implementers ?
>
>>
>> FWIW the draft incorrectly refers to section 6.2.4 instead of 6.2.6.
>
> Nice catch, thanks!
>
> --a
>
>>
>> Thanks,
>>    Erik
>>
>>>
>>>
>>> _______________________________________________
>>> 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

_______________________________________________
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

--------------050007020208010703050102-- From nobody Tue Jul 21 20:32:03 2015 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 2A3FF1B2A5F for ; Tue, 21 Jul 2015 20:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 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, HK_RANDOM_FROM=1, J_CHICKENPOX_22=0.6, 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 3fWnjb8dnyIO for ; Tue, 21 Jul 2015 20:32:00 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001: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 BB72F1B2A49 for ; Tue, 21 Jul 2015 20:31:52 -0700 (PDT) Received: by igr7 with SMTP id 7so57789520igr.0 for ; Tue, 21 Jul 2015 20:31:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=JfhmVys7CZU0SMhnN37FShK9kVYbRoSoCfEXF1zILVw=; b=Max/hoTT7IVzMM4YQtiWQcKoosQP0Ijqa2JP2q1eRg+baypUamH9N/AfuvHPD823vR F3/5/2PM2TaI6iqWoR/X5ked3YYpKkNiWgeHrtaAoqbRfjhggztMgN+2zKeOuS7sPo0i 196eRqo28Ooe1Ic0GRzbWxrx09PZS4P5x6R5eJkf00POHdgr4rdTVLv8xLAY30pPF3CW tgEAfCL6RoslxNr8abPLx5zP6fz2Ean1XrnDkImcCg+Ctjrdtv/tK02ARU56wZMjA652 mSO6hLGh7GilzDDlsz2rDWVvAVwd0EBMn96Rt9sFsE4V3y8v6XimwKl4xLgtM7gDwH+c reiQ== X-Received: by 10.107.18.28 with SMTP id a28mr528468ioj.106.1437535912190; Tue, 21 Jul 2015 20:31:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.169.143 with HTTP; Tue, 21 Jul 2015 20:31:22 -0700 (PDT) In-Reply-To: <55AE54D3.7070502@gmail.com> References: <6153A91F-7E9A-4579-BA06-72964568D343@cisco.com> <55AE54D3.7070502@gmail.com> From: Mark Smith Date: Wed, 22 Jul 2015 13:31:22 +1000 Message-ID: To: Alexandru Petrescu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: v6ops list Subject: Re: [v6ops] Discussion of draft-ietf-v6ops-ula-usage-recommendations 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, 22 Jul 2015 03:32:02 -0000 On 22 July 2015 at 00:18, Alexandru Petrescu wrote: > 1. Brian suggested to recommend that globals should be there on the > machines having ULAs as well, if I understand correctly. > > But I think so only on some Hosts, mainly the Hosts of end users. > > 2. the ULA RFC suggests a ULA prefix can be generated out of a MAC > address. That sixxs implementation does it. Except it takes it too > serious: it does not accept a MAC address which is not a real MAC > address - in that oui.txt. And random MAC addresses (for privacy) > certainly are not in that oui.txt. > > I think this is an undesirable situation to be in: unable to generate > ULAs because the only tool out there (sixxs) can't refuses a copy paste > a MAC address from the widely used windows 7 laptops. > sixxs is not the only ULA generator out there. Here's 4 others that showed up when I did a search for "ula generator" http://unique-local-ipv6.com/ https://www.ultratools.com/tools/rangeGenerator http://www.simpledns.com/private-ipv6.aspx http://www.kame.net/~suz/gen-ula.html I'm using random local MAC addresses on all of this host's interfaces, yet a number of the above links generated an automatic ULA prefix for me without issue (and I can't tell if they're IPv6 accessible and might have used my IPv6 IID as a MAC address after removing FF:FE etc.) > I am not sure what the problem is, but it's very good to have a very > easy way to generate ULAs. > > 3. in an enterprise deployment there was a problem of ULAs deployed in a > intra-network and another ULA space in another intra-network, of the > same enterprise. So we wanted to make sure two things: the two ULA > spaces are distinct, or otherwise make sure the gateway router does not > route between the two intranets' ULAs (but yes, route between their > respective GUAs). I am not sure how to translate that into advice, > because I am not sure how it will unfold in the near future. > RFC4193 recommends that by default ULA addressed packets and routes are not leaked outside of the ULA /48 assigned site. https://tools.ietf.org/html/rfc4193#section-4.3 > Alex > > Le 21/07/2015 16:02, Fred Baker (fred) a =C3=A9crit : >> >> https://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations >> >> > "Considerations For Using Unique Local Addresses", Bing Liu, Sheng >> >> Jiang, 2015-05-03 >> >> This draft came up from the floor this afternoon. I think we need >> some concentrated constructive conversation regarding it - we have >> had a lot of the other kind. >> >> What issues do we need to address to complete it. and what specific >> recommendations would that include? >> >> >> >> _______________________________________________ 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 Tue Jul 21 23:52:44 2015 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 A04091ACDEE for ; Tue, 21 Jul 2015 23:52:42 -0700 (PDT) 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 EW-yxfPUNRXD for ; Tue, 21 Jul 2015 23:52:40 -0700 (PDT) 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 839D51ACDEC for ; Tue, 21 Jul 2015 23:52:40 -0700 (PDT) Received: from dhcp-b3b7.meeting.ietf.org (dhcp-b3b7.meeting.ietf.org [31.133.179.183]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t6M6qZZb067733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 22 Jul 2015 06:52:37 GMT (envelope-from joelja@bogus.com) To: Alexandru Petrescu , Gert Doering References: <6153A91F-7E9A-4579-BA06-72964568D343@cisco.com> <55AE54D3.7070502@gmail.com> <55AE5D01.5090309@gmail.com> <55AE71F7.8000107@gmail.com> <20150721162835.26A9F338B4ED@rock.dv.isc.org> <55AE742E.9040301@gmail.com> <20150721184344.GH90924@Space.Net> <55AEA803.8070504@gmail.com> From: joel jaeggli Message-ID: <55AF3DB2.7060606@bogus.com> Date: Wed, 22 Jul 2015 08:52:34 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0 MIME-Version: 1.0 In-Reply-To: <55AEA803.8070504@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KbMNI9DLxIL7M0GdGpOpCj1ADx4XFx4NW" Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Discussion of draft-ietf-v6ops-ula-usage-recommendations 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, 22 Jul 2015 06:52:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KbMNI9DLxIL7M0GdGpOpCj1ADx4XFx4NW Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 7/21/15 10:13 PM, Alexandru Petrescu wrote: >=20 >=20 > Le 21/07/2015 20:43, Gert Doering a =E9crit : >> Hi, >> >> On Tue, Jul 21, 2015 at 06:32:46PM +0200, Alexandru Petrescu wrote: >>> We want simple ULA addresses, simple to remember, simple to type, >>> ideally based on a dictionary. >> >> Go away. DNS exists. >=20 > Of course, DNS exists and has its role in giving good names to addresse= s. >=20 > Yet ULA gives a certain freedom in the hextets after fd00::, and I woul= d > not waste it by generating a fd00:ca10:8fa3 which has no logic. >=20 > fd00:cafe:: is a random prefix, easier to pronounce, to remember and to= > tell on the phone. stop, please. No document with a discussion that looks this is coming out of the IETF so long as I am in a position to prevent it. > Alex >=20 >> >> Gert Doering >> -- NetMaster >> >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --KbMNI9DLxIL7M0GdGpOpCj1ADx4XFx4NW 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 iEYEARECAAYFAlWvPbIACgkQ8AA1q7Z/VrL7JgCggakYYAzfX+P0uuxdElMSRSeX zVwAn3AA5eaLYbgdNl7HlBRn2QGFEOFY =loAE -----END PGP SIGNATURE----- --KbMNI9DLxIL7M0GdGpOpCj1ADx4XFx4NW-- From nobody Wed Jul 22 00:20:41 2015 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 4D9831ACEC4 for ; Wed, 22 Jul 2015 00:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyoeANlyKy0m for ; Wed, 22 Jul 2015 00:20:38 -0700 (PDT) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::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 D68A71ACDF0 for ; Wed, 22 Jul 2015 00:20:37 -0700 (PDT) Received: by igr7 with SMTP id 7so60979827igr.0 for ; Wed, 22 Jul 2015 00:20:37 -0700 (PDT) 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:content-transfer-encoding; bh=qL9wrtkhxF9BaV4IN7XtiEeV2B16LctCLhzeOpLgMOU=; b=mtoh2xJHIhOyCnxStSqVx5a2ReKF626OkPZ61WYo6AbmqcN26l1xukT1S5WJTLYkA/ cjo9JwZ8q+ZiI9Pr4DKOE++xjFvVrYIiiNY5VeOncDuzir+J4SJKMZt9aJRMtrp0OKao I7vWC0ZFiTOlc2tO6N5KVCSVZyrz8iNvxgmoI1z4kyaiuJclhBrCScWw/LqX35MEH4O8 OxpGyyK+V5hJMEo0nmQheuYOvU8si/j0fp59oHdduI+Q/5Si9r6j/iWsUpc2xb9L5gwl mt14N/8Jp5Ac0jRZQ+Y/W/3ndf2XY23zPxeZuM5ivZRMsoggtzb4LoMFX3p6yFN+MWpi S+Tw== MIME-Version: 1.0 X-Received: by 10.50.178.133 with SMTP id cy5mr29603812igc.5.1437549637305; Wed, 22 Jul 2015 00:20:37 -0700 (PDT) Received: by 10.107.182.7 with HTTP; Wed, 22 Jul 2015 00:20:37 -0700 (PDT) In-Reply-To: <55AE5270.8000301@gmail.com> References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> <331D6E02-167D-4E7F-9682-F63C6674BD24@gmail.com> <55AE5270.8000301@gmail.com> Date: Wed, 22 Jul 2015 09:20:37 +0200 Message-ID: From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= To: Alexandru Petrescu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 22 Jul 2015 07:20:39 -0000 > On 21 Jul 2015, at 16:08, Alexandru Petrescu wrote: > > > > Le 17/07/2015 18:57, Andrew Yourtchenko a =C3=A9crit : >> >> On 17 Jul 2015, at 09:34, Fred Baker (fred) wrote: >> >>>> >>>> So the next logical thing to do would be to have the router default to >>>> unicast Router Advertisements, measure the rate of received Router >>>> Solicitations, and switch to multicast RA mode past a certain >>>> threshold to cover this sort of situation. Once the number of RSes >>>> falls, it switches back to unicast RA mode. >>>> >>>> That would get rid of the configuration knob proposed in this ID, and >>>> is behaviour that I think could be universal for all link types, >>>> rather than just for the case of wireless ones with mobile devices. >>> >>> If it were me implementing it, I think I would go about this in a littl= e different way, hopefully simpler. I would want to send at most one (e.g.,= either zero or one) RA per some interval (a second?). In the normal case, = that is sent unicast. However, having sent a unicast RA at time t, if I now= receive another RS before t+1, I send the next one (at time t+1) as a mult= icast. >> >> values of T less than 3 seconds would make performance worse than today. >> >> There are many things to optimize for: >> >> - wireless airtime >> - bandwidth used by RAs >> - CPU usage sending unicast RAs by router >> - energy consumption on devices for more than one medium > > and: > > - fast handovers: on some links the more frequent the multicast RAs the > faster the handovers are, i.e. less packet loss for end nodes, less > glitches in the video conference stream. > If the network sends the periodic RAs frequently enough to avoid the glitches of the video stream, this is explicitly *NOT* the network we are concerned about in this draft. Also, we wanted to be very focused what we talk about in this document, to be able to ship it quicker. We can say "does not apply to 802.11p, applies to 802.11(a|b|g|n|ac). Applicability to other networks is left at readers' discretion". Or something along these lines of that - feel free to propose the text if the above is not what you had in mind. --a > Alex > >> >> Some of them are orthogonal, some of them contradict each other, some of= them align. People may want to optimize differently. >> >> I'd opt for simplicity - and use the text Erik Kline posted in another e= mail. >> >> This would allow the developers to adapt for individual use cases on the= spot. >> >> --a >> >>> _______________________________________________ >>> 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 Wed Jul 22 01:19:28 2015 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 B8DEF1A0137 for ; Wed, 22 Jul 2015 01:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3oCavQn8L1M for ; Wed, 22 Jul 2015 01:19:25 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::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 DA2721A0104 for ; Wed, 22 Jul 2015 01:19:23 -0700 (PDT) Received: by iggf3 with SMTP id f3so127685253igg.1 for ; Wed, 22 Jul 2015 01:19:23 -0700 (PDT) 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:content-transfer-encoding; bh=y/L4CI8hZJxaOkMxoUx00i/z56adJQfL9q07N4WjvZA=; b=OUCI0XEtaYB6cEgSith6GBFaG7Pp3IGAZ+huOEjPm9Vd8y+K4fycl9mYnFNFMKGfiq 2+tulMNdT9uoaZQ17sz++0MgcHpjJOE2k14cRUE/JtAPN/YAaF8jv6LJnCFNMeDW3qlc yxjbpud60CNESJJbCkvZA77AkaGkjg9T7PylJH1VEoWOuYRU/Koo8kA6xPFzuH1QGslR 8w7Fkk7cm+ETvfnipjjUnbXXDI8p83DnALrgUpxAdmpUv1uZxUyIno+s3PkgfztNuvg1 EQ2SAMo0005pR5xJcUwuudMtgC9/9HrUdTGr+xf+tVcO4i/x2kchiyXlkx0sQWb5sNqE PtMg== MIME-Version: 1.0 X-Received: by 10.107.128.214 with SMTP id k83mr2209330ioi.7.1437553163330; Wed, 22 Jul 2015 01:19:23 -0700 (PDT) Received: by 10.107.182.7 with HTTP; Wed, 22 Jul 2015 01:19:22 -0700 (PDT) In-Reply-To: References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> <55AD3B64.5070400@acm.org> Date: Wed, 22 Jul 2015 10:19:22 +0200 Message-ID: From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= To: Owen DeLong Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: v6ops list , "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 22 Jul 2015 08:19:26 -0000 My brain can not compile this pseudocode... reset_multicast_timer resets multicast_ra_time_remaining to what value ? In the large-scale WiFi networks I operate I send multicast RA once in 30 minutes, and an immediate unicast solicited RA upon RS. If the "reset" is done to the MinRtrAdvInterval...MaxRtrAdvInterval, then this algorithm would optimize last 15 seconds of these 30 minutes ? --a On 7/21/15, Owen DeLong wrote: > It seems to me that the following algorithm would be relatively easy to > implement > and provide reasonable network optimization=E2=80=A6 > > > On receipt of an RS: > > if(multicast_ra_time_remaining > 15 seconds) > { > Send_Unicast_ra > } > else > { > Send_Multicast_ra > reset_multicast_timer > } > > In this way, if the timing is reasonably close, you multicast a packet yo= u > were about to send > anyway, but if the timing isn=E2=80=99t close, you=E2=80=99re not wasting= multicast > bandwidth answering a single > node where nobody else cares. > > Overall, I=E2=80=99ve always thought that multicast response to RS was ki= nd of > silly. It=E2=80=99s probably most > harmful on WiFi. > > Owen > >> On Jul 21, 2015, at 02:33 , Andrew =F0=9F=91=BD Yourtchenko >> wrote: >> >> On 7/20/15, Erik Nordmark wrote: >>> On 7/17/15 9:34 AM, Fred Baker (fred) wrote: >>>>> So the next logical thing to do would be to have the router default t= o >>>>> unicast Router Advertisements, measure the rate of received Router >>>>> Solicitations, and switch to multicast RA mode past a certain >>>>> threshold to cover this sort of situation. Once the number of RSes >>>>> falls, it switches back to unicast RA mode. >>>>> >>>>> That would get rid of the configuration knob proposed in this ID, and >>>>> is behaviour that I think could be universal for all link types, >>>>> rather than just for the case of wireless ones with mobile devices. >>>> If it were me implementing it, I think I would go about this in a >>>> little >>>> different way, hopefully simpler. I would want to send at most one >>>> (e.g., >>>> either zero or one) RA per some interval (a second?). In the normal >>>> case, >>>> that is sent unicast. However, having sent a unicast RA at time t, if = I >>>> now receive another RS before t+1, I send the next one (at time t+1) a= s >>>> a >>>> multicast. >>> >>> First of all I support this document as a WG document. >>> >>> But in terms of implementation, isn't it simpler to always(*) respond t= o >>> a RS with a unicast RA? >> >> Yes. I did not respond on-list yet - but from operational perspective >> "always send solRA unicast" / "always send solRA multicast" definitely >> wins in my book, and I'd avoid premature optimizations (but maybe we >> can say the implementers are explicitly free to do their own >> optimizations if they see fit) >> >> That said, will be very interesting to hear data from folks who will >> run "all-unicast solRA", in real networks and then compare the effect >> of their proposal optimizations on their real-world scenarios. >> >>> As background, the text in RFC4861 comes from the old concern that all >>> devices might boot at the same time when the power is re-established >>> after a building power failure; that doesn't happen since most devices >>> (laptops, smartphones, IoT devices) have batteries today. In that case >>> it might have made sense to sending fewer RA messages by using >>> multicast. >>> >>> (*) the only case in RFC 4861 when I think a multicast response might b= e >>> considered is when the source IPv6 address in the RS is the unspecified >>> address. Further, an implementation which rate limits received RS >>> packets (e.g., CoPP in a router) might also want to detect when the rat= e >>> limit might have dropped RS packets and multicast an RA in that case. >>> >>> >>> I do wonder why implementations haven't already changed to send unicast >>> solicited RA, and whether it would make a difference if we have an >> >> TBH that's my concern as well. I think we should tweak the text in >> 4861 to encourage a bit more consideration on the implementer's side. >> >>> informational document asking them to do this. Alternatively we could >>> have a proposed standard which updates section 6.2.6 to change the "MAY >>> unicast" to a "SHOULD unicast". >> >> Yeah, I actually have had the different text aimed for 6man, but >> Lorenzo's concern was 6man would say "there is no protocol update >> here, go away", so he rewrote it for v6ops. >> >> We should probably discuss this at the mic and get the opinion of the >> 6man chairs - if there is no outright "no" on this, a normative doc >> would be a better way to convince the implementers ? >> >>> >>> FWIW the draft incorrectly refers to section 6.2.4 instead of 6.2.6. >> >> Nice catch, thanks! >> >> --a >> >>> >>> Thanks, >>> Erik >>> >>>> >>>> >>>> _______________________________________________ >>>> 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 Wed Jul 22 01:35:27 2015 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 67FBD1ACE63 for ; Wed, 22 Jul 2015 01:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AeHbIfkGYOJF for ; Wed, 22 Jul 2015 01:35:24 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::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 1E68E1A8A90 for ; Wed, 22 Jul 2015 01:34:53 -0700 (PDT) Received: by iebmu5 with SMTP id mu5so161569206ieb.1 for ; Wed, 22 Jul 2015 01:34:52 -0700 (PDT) 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=+PMwQZDtX32b7653ASGcv5R3yH/3frV884001PmQqM4=; b=CYSUecVAlNKKnxBTdw1yI4dCGPBC1mfWy5eo9U5hOx0vNKTX1xfbJ3DBuisOLla6Zi tNiTVIhQ6c7NmQA8zCluSjMuoHpNjWwFw/sGQuiYpCwCAS1hlf+/CcZKfyTbGjSgkAmR 3ge/milGu4/YRvX2M4QdEoF806AkSIoBnNWsjLNYPRG5ahuYmIgnGNLmCpZXW+kJfHK9 hPA3xcLhZ9pO6XwPzjqsJ3gyTnKoMpw3F5crR//bsozE5W+qT7cacTSvz6dSvOcSIgeR RBC4E6XjKFxnr4eZjB85TVmGGb1Ti/MU6qqT7l6QtZW8fUULxEnktPNvpPKSRioHz36i AJtQ== MIME-Version: 1.0 X-Received: by 10.50.17.104 with SMTP id n8mr32198589igd.21.1437554092567; Wed, 22 Jul 2015 01:34:52 -0700 (PDT) Received: by 10.107.182.7 with HTTP; Wed, 22 Jul 2015 01:34:52 -0700 (PDT) In-Reply-To: <55AE44AA.7070304@gmail.com> References: <55AE44AA.7070304@gmail.com> Date: Wed, 22 Jul 2015 10:34:52 +0200 Message-ID: From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= To: Alexandru Petrescu Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] unicast RA to save battery: link-layer joining multicast groups 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, 22 Jul 2015 08:35:25 -0000 This is what some phones do today and is exactly the problem we are trying to solve. https://code.google.com/p/android/issues/detail?id=32662 --a On 7/21/15, Alexandru Petrescu wrote: > On another hand, > > IEEE 802.11bgn multicast groups (33::1 etc) are 'joined' at MAC layer by > setting filters. (maybe even by MAC messaging for joining MAC multicast > groups). > > Maybe we can request the Hosts to set local filters to not receive > multicast RAs. Or request the Hosts short on energy to express interest > in these IPv6 multicast groups. > > Alex > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Jul 22 03:04:10 2015 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 DA15F1ACD3F for ; Wed, 22 Jul 2015 03:04:08 -0700 (PDT) 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 MhrbpiwjnBS3 for ; Wed, 22 Jul 2015 03:04:08 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::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 C68BB1ACD25 for ; Wed, 22 Jul 2015 03:04:07 -0700 (PDT) Received: by wibud3 with SMTP id ud3so164290452wib.0 for ; Wed, 22 Jul 2015 03:04:06 -0700 (PDT) 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=czjgTITKJc/3DFSNHKDf4AZ8vQgXlOU+VQB//g6/aFM=; b=jnP4ZRCF1ZWPWXvFwbAA5auhtcnxWUGQYfR9HTeBy65dpsTD4VUSSs3EAq1RCUNO2a n0Q9iaOfjJunbAGMsy+AHVYJX/1sE+LPr7dymrDcgD/5F5pQkXuHR7srPs7WJcIok2Mo z3WuQbksGYkjEdRYWYFs8AyOvaOfuq8WCK7cujZ8bjU6A8EvEqYa8Smp6ACYgvPyXYN+ gvsr8b/u/KfYTmlQj0jnQZKhELNFzTEZMB2bGJkQlHuZrL5L/D/MChh0YFlQxdmBpls3 5ZU5rfKh4UNjIk4fO09wtwROFe655gWKKFu74I9kjbcALGd9Kq0tKLGA2c3yVHa+Fbap QbOg== 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=czjgTITKJc/3DFSNHKDf4AZ8vQgXlOU+VQB//g6/aFM=; b=Y1xeSeqxcG5Yi9xlhkdAhhMhIvUSGSlFy+6//R0mvyLQoo7AgfX5mCPZoN7744qPXZ opgvxx1kFxnq2hkmL8uq7ott/Gp3TQly6pPlu9kN8wtK0stcyY9tSWa8feBem5TVIinT JodiMmSloHteBGz74wu1l465nn5l4X8vX14Z6b8pWxeSE5x2WByPtWEsoT+wNR1vbbph sylqFFnY7bNftIQpSC44fD/fciWNVE8eO+Sk0XbTYnXYsMdQXNTJxuTR41WLfpkO8RKp 7kJuy8yZ9pQkiBBUd1TFjpdDdVU3DMCBEzEYFwCmGPjdCM0w0+ss0s+2qkeactUEFqbv hXow== X-Gm-Message-State: ALoCoQnoA/cLhvef624XppQeBO2tbTOB3lCw8hdESl5dhHffyYLfwwGx0tsSJ2UPW28CY2QnCkIl X-Received: by 10.180.85.194 with SMTP id j2mr4797319wiz.11.1437559446449; Wed, 22 Jul 2015 03:04:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.138.203 with HTTP; Wed, 22 Jul 2015 03:03:46 -0700 (PDT) In-Reply-To: <55AF3DB2.7060606@bogus.com> References: <6153A91F-7E9A-4579-BA06-72964568D343@cisco.com> <55AE54D3.7070502@gmail.com> <55AE5D01.5090309@gmail.com> <55AE71F7.8000107@gmail.com> <20150721162835.26A9F338B4ED@rock.dv.isc.org> <55AE742E.9040301@gmail.com> <20150721184344.GH90924@Space.Net> <55AEA803.8070504@gmail.com> <55AF3DB2.7060606@bogus.com> From: Erik Kline Date: Wed, 22 Jul 2015 12:03:46 +0200 Message-ID: To: joel jaeggli Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Discussion of draft-ietf-v6ops-ula-usage-recommendations 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, 22 Jul 2015 10:04:09 -0000 >> Yet ULA gives a certain freedom in the hextets after fd00::, and I would >> not waste it by generating a fd00:ca10:8fa3 which has no logic. >> >> fd00:cafe:: is a random prefix, easier to pronounce, to remember and to >> tell on the phone. > > stop, please. > > No document with a discussion that looks this is coming out of the IETF > so long as I am in a position to prevent it. (hug) From nobody Wed Jul 22 03:23:03 2015 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 6146D1AD1A6 for ; Wed, 22 Jul 2015 03:23:01 -0700 (PDT) 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 rpE5mLTy8sS3 for ; Wed, 22 Jul 2015 03:22:58 -0700 (PDT) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CE341AD16B for ; Wed, 22 Jul 2015 03:22:58 -0700 (PDT) Received: by ykfw194 with SMTP id w194so108527580ykf.0 for ; Wed, 22 Jul 2015 03:22:58 -0700 (PDT) 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=y1PP+OwROsoVZaSiOH0OS87o0U2PYJyAV0UyiJOAwyM=; b=GuiBS81aTrfkg8c23n99up++Yaz6fXXXsmcQ9BZH4lU8HHwT7EmLtFD41TII+jYwj5 YokFOlUqoTVgzH4Kl1esimgKx7Wi8tLzuP6CXCHZRzRpcqwjvUzcZ7ZfHzIePxlZMwtd YtTTOqFzibBOPCn1DePm8/rZHwscQVOwLziYpk4H2V+/xFsnn8lC6xn8nu9twYBd54oG ukYkLF0L/PmURhz69M3M/OfLJMYXL68G3lJ/NhIZ/GFwNwQdaXWSewg0wq7zyMC+hk44 7f82cq6sCwPe+Sx2NET7cTwwp+Ph9UOvjCKf5MYfwQ2SpNJ6vp7O6/7mwW531GxH0HVn o7Yg== 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=y1PP+OwROsoVZaSiOH0OS87o0U2PYJyAV0UyiJOAwyM=; b=NJSKon2CIsWypgr1o5aUwCaCHSAr+ZNudDWYZfzxG1OFaUtujvwM6o2byCzzCEFUHg CZBK1KIUrycRNbjZLpkntFMS+fTpHOrs7izIcBgplvEtETSMKQ5WzRCAcXlg4tJoYaUs 5b7hCyfugf/k/anpr0FdGXlyIoizufO//VX8tomKfw9JWMTjSrhelkYxsm8XvohayBKX GgR7LnAZYy5EgIddWiCVf+BGyh7HqoAAaT4McaqOxKTjjQdrj/5dTm0O1rsC1YgQJwmP wrjAA9iWKmsDLXh5+TpysbwYF3hykd1q80vfgAF8KAUWQD+xdkBQUaEx5bMO0lWiZEeB kl9Q== X-Gm-Message-State: ALoCoQkmgOFKVU277oIoi1q6v8S/3IMrKZ9HvfgBqYC7mWzrA+nbPMFVvvBWQ/lF8OEwsxvTGXtl X-Received: by 10.129.77.213 with SMTP id a204mr1683222ywb.40.1437560577736; Wed, 22 Jul 2015 03:22:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.8.201 with HTTP; Wed, 22 Jul 2015 03:22:38 -0700 (PDT) In-Reply-To: <55AF0964.1060006@gmail.com> References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> <55AD3B64.5070400@acm.org> <55AF0964.1060006@gmail.com> From: Lorenzo Colitti Date: Wed, 22 Jul 2015 12:22:38 +0200 Message-ID: To: Alejandro Acosta Content-Type: multipart/alternative; boundary=001a1140c55294cc40051b742713 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 22 Jul 2015 10:23:01 -0000 --001a1140c55294cc40051b742713 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for all the feedback. We have posted a -01 addressing some of the feedback we got. The new version also contains a new recommendation not to send periodic RAs too frequently, so we have changed the title to "Reducing battery impact of Router Advertisements". https://tools.ietf.org/html/draft-yc-v6ops-solicited-ra-unicast-01 If there are no objections, we will upload this as a WG document in the next few days. On Wed, Jul 22, 2015 at 5:09 AM, Alejandro Acosta < alejandroacostaalamo@gmail.com> wrote: > Hi There, > I also support this document, it's very positive to see that this > algorithm will save energy. > > Regards, > > Alejandro, > > El 7/21/2015 a las 6:11 PM, Nabil Benamar escribi=C3=B3: > > Hi Folks, > > I support this document which is very informative, useful and its > implementation will certainly reduce energy consumption due to excessive > Multicast RA sent. The proposed algorithm seems to be suitable for this e= nd > ! > > > Best regards > > > > On Tue, Jul 21, 2015 at 4:38 PM, Owen DeLong wrote: > >> It seems to me that the following algorithm would be relatively easy to >> implement >> and provide reasonable network optimization=E2=80=A6 >> >> >> On receipt of an RS: >> >> if(multicast_ra_time_remaining > 15 seconds) >> { >> Send_Unicast_ra >> } >> else >> { >> Send_Multicast_ra >> reset_multicast_timer >> } >> >> In this way, if the timing is reasonably close, you multicast a packet >> you were about to send >> anyway, but if the timing isn=E2=80=99t close, you=E2=80=99re not wastin= g multicast >> bandwidth answering a single >> node where nobody else cares. >> >> Overall, I=E2=80=99ve always thought that multicast response to RS was k= ind of >> silly. It=E2=80=99s probably most >> harmful on WiFi. >> >> Owen >> >> > On Jul 21, 2015, at 02:33 , Andrew =F0=9F=91=BD Yourtchenko >> wrote: >> > >> > On 7/20/15, Erik Nordmark < nordmark@acm.org> wrote: >> >> On 7/17/15 9:34 AM, Fred Baker (fred) wrote: >> >>>> So the next logical thing to do would be to have the router default >> to >> >>>> unicast Router Advertisements, measure the rate of received Router >> >>>> Solicitations, and switch to multicast RA mode past a certain >> >>>> threshold to cover this sort of situation. Once the number of RSes >> >>>> falls, it switches back to unicast RA mode. >> >>>> >> >>>> That would get rid of the configuration knob proposed in this ID, a= nd >> >>>> is behaviour that I think could be universal for all link types, >> >>>> rather than just for the case of wireless ones with mobile devices. >> >>> If it were me implementing it, I think I would go about this in a >> little >> >>> different way, hopefully simpler. I would want to send at most one >> (e.g., >> >>> either zero or one) RA per some interval (a second?). In the normal >> case, >> >>> that is sent unicast. However, having sent a unicast RA at time t, i= f >> I >> >>> now receive another RS before t+1, I send the next one (at time t+1) >> as a >> >>> multicast. >> >> >> >> First of all I support this document as a WG document. >> >> >> >> But in terms of implementation, isn't it simpler to always(*) respond >> to >> >> a RS with a unicast RA? >> > >> > Yes. I did not respond on-list yet - but from operational perspective >> > "always send solRA unicast" / "always send solRA multicast" definitely >> > wins in my book, and I'd avoid premature optimizations (but maybe we >> > can say the implementers are explicitly free to do their own >> > optimizations if they see fit) >> > >> > That said, will be very interesting to hear data from folks who will >> > run "all-unicast solRA", in real networks and then compare the effect >> > of their proposal optimizations on their real-world scenarios. >> > >> >> As background, the text in RFC4861 comes from the old concern that al= l >> >> devices might boot at the same time when the power is re-established >> >> after a building power failure; that doesn't happen since most device= s >> >> (laptops, smartphones, IoT devices) have batteries today. In that cas= e >> >> it might have made sense to sending fewer RA messages by using >> multicast. >> >> >> >> (*) the only case in RFC 4861 when I think a multicast response might >> be >> >> considered is when the source IPv6 address in the RS is the unspecifi= ed >> >> address. Further, an implementation which rate limits received RS >> >> packets (e.g., CoPP in a router) might also want to detect when the >> rate >> >> limit might have dropped RS packets and multicast an RA in that case. >> >> >> >> >> >> I do wonder why implementations haven't already changed to send unica= st >> >> solicited RA, and whether it would make a difference if we have an >> > >> > TBH that's my concern as well. I think we should tweak the text in >> > 4861 to encourage a bit more consideration on the implementer's side. >> > >> >> informational document asking them to do this. Alternatively we could >> >> have a proposed standard which updates section 6.2.6 to change the "M= AY >> >> unicast" to a "SHOULD unicast". >> > >> > Yeah, I actually have had the different text aimed for 6man, but >> > Lorenzo's concern was 6man would say "there is no protocol update >> > here, go away", so he rewrote it for v6ops. >> > >> > We should probably discuss this at the mic and get the opinion of the >> > 6man chairs - if there is no outright "no" on this, a normative doc >> > would be a better way to convince the implementers ? >> > >> >> >> >> FWIW the draft incorrectly refers to section 6.2.4 instead of 6.2.6. >> > >> > Nice catch, thanks! >> > >> > --a >> > >> >> >> >> Thanks, >> >> Erik >> >> >> >>> >> >>> >> >>> _______________________________________________ >> >>> 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 >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > > > _______________________________________________ > v6ops mailing listv6ops@ietf.orghttps://www.ietf.org/mailman/listinfo/v6o= ps > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --001a1140c55294cc40051b742713 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for all the feedback. We have posted a -01 addressi= ng some of the feedback we got. The new version also contains a new recomme= ndation not to send periodic RAs too frequently, so we have changed the tit= le to "Reducing battery impact of Router Advertisements".

If there are no objections, w= e will upload this as a WG document in the next few days.

On Wed, Jul 22, 2015 at= 5:09 AM, Alejandro Acosta <alejandroacostaalamo@gmail.com> wrote:
=20 =20 =20
Hi There,
=C2=A0 I also support this document, it's very positive to see th= at this algorithm will save energy.

Regards,

Alejandro,

El 7/21/2015 a las 6:11 PM, Nabil Benamar escribi=C3=B3:
Hi Folks,

I support this document which is very informative, useful and its implementation will certainly reduce energy consumption due to excessive Multicast RA sent. The proposed algorithm seems to be suitable for this end !


Best regards



On Tue, Jul 21, 2015 at 4:38 PM, O= wen DeLong <owen@delong.com> wrote:
It seems to me that the following algorithm would be relatively easy to implement
and provide reasonable network optimization=E2=80=A6


On receipt of an RS:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 if(multicast_ra_time_remaining >= 15 seconds)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Send_Unicast_ra
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 else
=C2=A0 =C2=A0 =C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Send_Multicast_ra
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 reset_multicast_timer
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }

In this way, if the timing is reasonably close, you multicast a packet you were about to send
anyway, but if the timing isn=E2=80=99t close, you=E2=80=99re n= ot wasting multicast bandwidth answering a single
node where nobody else cares.

Overall, I=E2=80=99ve always thought that multicast response to= RS was kind of silly. It=E2=80=99s probably most
harmful on WiFi.

Owen

> On Jul 21, 2015, at 02:33 , Andrew =F0=9F=91=BD Yourtc= henko <ayourtch@gmail.com> wrote:
>
> On 7/20/15, Erik Nordmark <nordmark@acm.org> wrote:
>> On 7/17/15 9:34 AM, Fred Baker (fred) wrote:
>>>> So the next logical thing to do would be to have the router default to
>>>> unicast Router Advertisements, measure the rate of received Router
>>>> Solicitations, and switch to multicast RA mode past a certain
>>>> threshold to cover this sort of situation. Once the number of RSes
>>>> falls, it switches back to unicast RA mode.
>>>>
>>>> That would get rid of the configuration knob proposed in this ID, and
>>>> is behaviour that I think could be universal for all link types,
>>>> rather than just for the case of wireless ones with mobile devices.
>>> If it were me implementing it, I think I would go about this in a little
>>> different way, hopefully simpler. I would want to send at most one (e.g.,
>>> either zero or one) RA per some interval (a second?). In the normal case,
>>> that is sent unicast. However, having sent a unicast RA at time t, if I
>>> now receive another RS before t+1, I send the next one (at time t+1) as a
>>> multicast.
>>
>> First of all I support this document as a WG document.
>>
>> But in terms of implementation, isn't it simpler to always(*) respond to
>> a RS with a unicast RA?
>
> Yes. I did not respond on-list yet - but from operational perspective
> "always send solRA unicast" / "always s= end solRA multicast" definitely
> wins in my book, and I'd avoid premature optimizations (but maybe we
> can say the implementers are explicitly free to do their own
> optimizations if they see fit)
>
> That said, will be very interesting to hear data from folks who will
> run "all-unicast solRA", in real networks an= d then compare the effect
> of their proposal optimizations on their real-world scenarios.
>
>> As background, the text in RFC4861 comes from the old concern that all
>> devices might boot at the same time when the power is re-established
>> after a building power failure; that doesn't happen since most devices
>> (laptops, smartphones, IoT devices) have batteries today. In that case
>> it might have made sense to sending fewer RA messages by using multicast.
>>
>> (*) the only case in RFC 4861 when I think a multicast response might be
>> considered is when the source IPv6 address in the RS is the unspecified
>> address. Further, an implementation which rate limits received RS
>> packets (e.g., CoPP in a router) might also want to detect when the rate
>> limit might have dropped RS packets and multicast an RA in that case.
>>
>>
>> I do wonder why implementations haven't alread= y changed to send unicast
>> solicited RA, and whether it would make a difference if we have an
>
> TBH that's my concern as well. I think we should tweak the text in
> 4861 to encourage a bit more consideration on the implementer's side.
>
>> informational document asking them to do this. Alternatively we could
>> have a proposed standard which updates section 6.2.6 to change the "MAY
>> unicast" to a "SHOULD unicast".
>
> Yeah, I actually have had the different text aimed for 6man, but
> Lorenzo's concern was 6man would say "there i= s no protocol update
> here, go away", so he rewrote it for v6ops.
>
> We should probably discuss this at the mic and get the opinion of the
> 6man chairs - if there is no outright "no" o= n this, a normative doc
> would be a better way to convince the implementers ?
>
>>
>> FWIW the draft incorrectly refers to section 6.2.4 instead of 6.2.6.
>
> Nice catch, thanks!
>
> --a
>
>>
>> Thanks,
>>=C2=A0 =C2=A0 Erik
>>
>>>
>>>
>>> _______________________________________________
>>> v6ops mailing list
>>> v6ops@ietf.org
>>> https://www.ietf.org/mailman= /listinfo/v6ops
>>
>> _______________________________________________ >> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/lis= tinfo/v6ops
>>
>
> _______________________________________________
> v6ops mailing list
> v6= ops@ietf.org
> https://www.ietf.org/mailman/listinf= o/v6ops

_______________________________________________
v6ops mailing list
v6ops@i= etf.org
https://www.ietf.org/mailman/listinfo/v6o= ps



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


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


--001a1140c55294cc40051b742713-- From nobody Wed Jul 22 05:01:09 2015 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 18CC01B2AEB for ; Wed, 22 Jul 2015 05:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.683 X-Spam-Level: X-Spam-Status: No, score=-4.683 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVOmcxVRfk9u for ; Wed, 22 Jul 2015 05:01:06 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AE951A03A3 for ; Wed, 22 Jul 2015 05:00:58 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6MC0tmG018052; Wed, 22 Jul 2015 14:00:55 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A761020286B; Wed, 22 Jul 2015 14:04:30 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9BE33202725; Wed, 22 Jul 2015 14:04:30 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.215]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6MC0r6F017640; Wed, 22 Jul 2015 14:00:55 +0200 To: =?UTF-8?Q?Andrew_=f0=9f=91=bd_Yourtchenko?= References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> <331D6E02-167D-4E7F-9682-F63C6674BD24@gmail.com> <55AE5270.8000301@gmail.com> From: Alexandru Petrescu Message-ID: <55AF85F5.7070407@gmail.com> Date: Wed, 22 Jul 2015 14:00:53 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.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] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 22 Jul 2015 12:01:08 -0000 Le 22/07/2015 09:20, Andrew 👽 Yourtchenko a écrit : >> On 21 Jul 2015, at 16:08, Alexandru Petrescu wrote: >> >> >> >> Le 17/07/2015 18:57, Andrew Yourtchenko a écrit : >>> >>> On 17 Jul 2015, at 09:34, Fred Baker (fred) wrote: >>> >>>>> >>>>> So the next logical thing to do would be to have the router default to >>>>> unicast Router Advertisements, measure the rate of received Router >>>>> Solicitations, and switch to multicast RA mode past a certain >>>>> threshold to cover this sort of situation. Once the number of RSes >>>>> falls, it switches back to unicast RA mode. >>>>> >>>>> That would get rid of the configuration knob proposed in this ID, and >>>>> is behaviour that I think could be universal for all link types, >>>>> rather than just for the case of wireless ones with mobile devices. >>>> >>>> If it were me implementing it, I think I would go about this in a little different way, hopefully simpler. I would want to send at most one (e.g., either zero or one) RA per some interval (a second?). In the normal case, that is sent unicast. However, having sent a unicast RA at time t, if I now receive another RS before t+1, I send the next one (at time t+1) as a multicast. >>> >>> values of T less than 3 seconds would make performance worse than today. >>> >>> There are many things to optimize for: >>> >>> - wireless airtime >>> - bandwidth used by RAs >>> - CPU usage sending unicast RAs by router >>> - energy consumption on devices for more than one medium >> >> and: >> >> - fast handovers: on some links the more frequent the multicast RAs the >> faster the handovers are, i.e. less packet loss for end nodes, less >> glitches in the video conference stream. >> > > If the network sends the periodic RAs frequently enough to avoid the > glitches of the video stream, this is explicitly *NOT* the network we > are concerned about in this draft. But mentioning 'mobile' for the nodes, makes think so. Because fast address auto-configuration is a characteristic of mobile nodes. One wants to spend as little time as possible waiting for RAs. For that reason the multicast RAs period was reduced to milliseconds. > Also, we wanted to be very focused what we talk about in this > document, to be able to ship it quicker. I agree. > We can say "does not apply to 802.11p, applies to 802.11(a|b|g|n|ac). > Applicability to other networks is left at readers' discretion". I agree. It should also say it does not apply to LTE. BEcause in LTE an RA is sent on only one ptp link, there is no risk of waking up somebody. > Or something along these lines of that - feel free to propose the text > if the above is not what you had in mind. On a scale MUST NOT, MAY, SHOULD - SHOULD is the right term. "SHOULD [...] unless the network is of type LTE or 802.11p". Or: "SHOULD [...] unless there is an interest in as numerous RAs as possible to help in fast address auto-configuration to large number of mobiles". or "SHOULD [...] unless the Hosts are allowed to explicitely express interest in the multicast group dst of RA". or "SHOULD [...] unless RFC-MLD is updated to require Hosts to express interest in the multicast group dst of RA". Alex > > --a > >> Alex >> >>> >>> Some of them are orthogonal, some of them contradict each other, some of them align. People may want to optimize differently. >>> >>> I'd opt for simplicity - and use the text Erik Kline posted in another email. >>> >>> This would allow the developers to adapt for individual use cases on the spot. >>> >>> --a >>> >>>> _______________________________________________ >>>> 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 Wed Jul 22 05:06:47 2015 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 1C72B1A00DD for ; Wed, 22 Jul 2015 05:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.683 X-Spam-Level: X-Spam-Status: No, score=-4.683 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2YuCvGgpeCms for ; Wed, 22 Jul 2015 05:06:44 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B48C1A0099 for ; Wed, 22 Jul 2015 05:06:44 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6MC6guS020775; Wed, 22 Jul 2015 14:06:42 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2C08C20281E; Wed, 22 Jul 2015 14:10:17 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 153CB2027AA; Wed, 22 Jul 2015 14:10:17 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.215]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6MC6dRP018145; Wed, 22 Jul 2015 14:06:41 +0200 To: =?UTF-8?Q?Andrew_=f0=9f=91=bd_Yourtchenko?= References: <55AE44AA.7070304@gmail.com> From: Alexandru Petrescu Message-ID: <55AF874F.5000807@gmail.com> Date: Wed, 22 Jul 2015 14:06:39 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.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] unicast RA to save battery: link-layer joining multicast groups 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, 22 Jul 2015 12:06:46 -0000 Thanks for the pointer, but that's a long discussion, it's hard to draw quickly a conclusion on it. I would think to argue that if Android has a problem in this then it's an Android problem. If it's a particular driver problem (dependent on the card of that samsung phone) then fix that problem. Maybe it's not so. But I am sure the linux devices I use dont consume more power when receiving more RAs, on wifi. And even if they did, I have enough batteries and enough other sources of energy to provide them in order to be able to make handovers fast enough to not loose 1 single packet. Not sure whether the goal here is to save energy? Alex Le 22/07/2015 10:34, Andrew 👽 Yourtchenko a écrit : > This is what some phones do today and is exactly the problem we are > trying to solve. > > https://code.google.com/p/android/issues/detail?id=32662 > > --a > > On 7/21/15, Alexandru Petrescu wrote: >> On another hand, >> >> IEEE 802.11bgn multicast groups (33::1 etc) are 'joined' at MAC layer by >> setting filters. (maybe even by MAC messaging for joining MAC multicast >> groups). >> >> Maybe we can request the Hosts to set local filters to not receive >> multicast RAs. Or request the Hosts short on energy to express interest >> in these IPv6 multicast groups. >> >> Alex >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > From nobody Wed Jul 22 05:07:53 2015 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 117F01A00EE for ; Wed, 22 Jul 2015 05:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntG-lTzebfRl for ; Wed, 22 Jul 2015 05:07:46 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 276621A0161 for ; Wed, 22 Jul 2015 05:07:45 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6MC7hs7021101 for ; Wed, 22 Jul 2015 14:07:43 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0952A2027B5 for ; Wed, 22 Jul 2015 14:11:19 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id F31D6200C4C for ; Wed, 22 Jul 2015 14:11:18 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.215]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6MC7hbA019053 for ; Wed, 22 Jul 2015 14:07:43 +0200 To: v6ops@ietf.org References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> <55AD3B64.5070400@acm.org> <55AF0964.1060006@gmail.com> From: Alexandru Petrescu Message-ID: <55AF878E.1090200@gmail.com> Date: Wed, 22 Jul 2015 14:07:42 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 22 Jul 2015 12:07:52 -0000 "Reducing battery impact of RAs on Androids"? Alex Le 22/07/2015 12:22, Lorenzo Colitti a écrit : > Thanks for all the feedback. We have posted a -01 addressing some of the > feedback we got. The new version also contains a new recommendation not > to send periodic RAs too frequently, so we have changed the title to > "Reducing battery impact of Router Advertisements". > > https://tools.ietf.org/html/draft-yc-v6ops-solicited-ra-unicast-01 > > If there are no objections, we will upload this as a WG document in the > next few days. > > On Wed, Jul 22, 2015 at 5:09 AM, Alejandro Acosta > > > wrote: > > Hi There, > I also support this document, it's very positive to see that this > algorithm will save energy. > > Regards, > > Alejandro, > > El 7/21/2015 a las 6:11 PM, Nabil Benamar escribió: >> Hi Folks, >> >> I support this document which is very informative, useful and its >> implementation will certainly reduce energy consumption due to >> excessive Multicast RA sent. The proposed algorithm seems to be >> suitable for this end ! >> >> >> Best regards >> >> >> >> On Tue, Jul 21, 2015 at 4:38 PM, Owen DeLong > > wrote: >> >> It seems to me that the following algorithm would be >> relatively easy to implement >> and provide reasonable network optimization… >> >> >> On receipt of an RS: >> >> if(multicast_ra_time_remaining > 15 seconds) >> { >> Send_Unicast_ra >> } >> else >> { >> Send_Multicast_ra >> reset_multicast_timer >> } >> >> In this way, if the timing is reasonably close, you multicast >> a packet you were about to send >> anyway, but if the timing isn’t close, you’re not wasting >> multicast bandwidth answering a single >> node where nobody else cares. >> >> Overall, I’ve always thought that multicast response to RS was >> kind of silly. It’s probably most >> harmful on WiFi. >> >> Owen >> >> > On Jul 21, 2015, at 02:33 , Andrew 👽 Yourtchenko >> > wrote: >> > >> > On 7/20/15, Erik Nordmark >> <nordmark@acm.org >> > wrote: >> >> On 7/17/15 9:34 AM, Fred Baker (fred) wrote: >> >>>> So the next logical thing to do would be to have the >> router default to >> >>>> unicast Router Advertisements, measure the rate of >> received Router >> >>>> Solicitations, and switch to multicast RA mode past a certain >> >>>> threshold to cover this sort of situation. Once the >> number of RSes >> >>>> falls, it switches back to unicast RA mode. >> >>>> >> >>>> That would get rid of the configuration knob proposed in >> this ID, and >> >>>> is behaviour that I think could be universal for all link >> types, >> >>>> rather than just for the case of wireless ones with >> mobile devices. >> >>> If it were me implementing it, I think I would go about >> this in a little >> >>> different way, hopefully simpler. I would want to send at >> most one (e.g., >> >>> either zero or one) RA per some interval (a second?). In >> the normal case, >> >>> that is sent unicast. However, having sent a unicast RA at >> time t, if I >> >>> now receive another RS before t+1, I send the next one (at >> time t+1) as a >> >>> multicast. >> >> >> >> First of all I support this document as a WG document. >> >> >> >> But in terms of implementation, isn't it simpler to >> always(*) respond to >> >> a RS with a unicast RA? >> > >> > Yes. I did not respond on-list yet - but from operational >> perspective >> > "always send solRA unicast" / "always send solRA multicast" >> definitely >> > wins in my book, and I'd avoid premature optimizations (but >> maybe we >> > can say the implementers are explicitly free to do their own >> > optimizations if they see fit) >> > >> > That said, will be very interesting to hear data from folks >> who will >> > run "all-unicast solRA", in real networks and then compare >> the effect >> > of their proposal optimizations on their real-world scenarios. >> > >> >> As background, the text in RFC4861 comes from the old >> concern that all >> >> devices might boot at the same time when the power is >> re-established >> >> after a building power failure; that doesn't happen since >> most devices >> >> (laptops, smartphones, IoT devices) have batteries today. >> In that case >> >> it might have made sense to sending fewer RA messages by >> using multicast. >> >> >> >> (*) the only case in RFC 4861 when I think a multicast >> response might be >> >> considered is when the source IPv6 address in the RS is the >> unspecified >> >> address. Further, an implementation which rate limits >> received RS >> >> packets (e.g., CoPP in a router) might also want to detect >> when the rate >> >> limit might have dropped RS packets and multicast an RA in >> that case. >> >> >> >> >> >> I do wonder why implementations haven't already changed to >> send unicast >> >> solicited RA, and whether it would make a difference if we >> have an >> > >> > TBH that's my concern as well. I think we should tweak the >> text in >> > 4861 to encourage a bit more consideration on the >> implementer's side. >> > >> >> informational document asking them to do this. >> Alternatively we could >> >> have a proposed standard which updates section 6.2.6 to >> change the "MAY >> >> unicast" to a "SHOULD unicast". >> > >> > Yeah, I actually have had the different text aimed for 6man, but >> > Lorenzo's concern was 6man would say "there is no protocol >> update >> > here, go away", so he rewrote it for v6ops. >> > >> > We should probably discuss this at the mic and get the >> opinion of the >> > 6man chairs - if there is no outright "no" on this, a >> normative doc >> > would be a better way to convince the implementers ? >> > >> >> >> >> FWIW the draft incorrectly refers to section 6.2.4 instead >> of 6.2.6. >> > >> > Nice catch, thanks! >> > >> > --a >> > >> >> >> >> Thanks, >> >> Erik >> >> >> >>> >> >>> >> >>> _______________________________________________ >> >>> 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 >> >> _______________________________________________ >> 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 > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Jul 22 05:11:17 2015 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 5A0071A8AA7 for ; Wed, 22 Jul 2015 05:11:16 -0700 (PDT) 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 SloJKixPsb_X for ; Wed, 22 Jul 2015 05:11:13 -0700 (PDT) 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 A48821A0173 for ; Wed, 22 Jul 2015 05:10:51 -0700 (PDT) Received: by ykfw194 with SMTP id w194so110382351ykf.0 for ; Wed, 22 Jul 2015 05:10:51 -0700 (PDT) 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=r1VLqlYImEAylunvIUz8RS4jgc+D5N6GrYm+oaBXhSs=; b=YK5+s7464Lq/LHgA+p0ODXGuFYe8/Wx5oPdZqF9y0x0tO/UzG/E3HLQ5aqxC7jOW3N YdUpD8YxUAiho1YD8z3pNSk/PqQLHvY+GfLJmQ9QQxqKck87IOAp9P9Wf4ejVlY+DePn 29dcMVVgRpMIsDaeFhF4yjl51ncxl33CNMYKfKXMB0ynn7Xpx0qglpHtvOBaXzIoMqTK 9xDEgVjSpOLeLfuQOvfAoLy/uz6v6qPfjagnNxnAspl28L2MzWoFOQ7rH3VQsGqaVXQV whaTMmhnlVkH23//0HsbePt18ja1ufSCvztOs0zWzfhb15TVqy/XQnuKjQtNdQZLvZPe GKAA== 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=r1VLqlYImEAylunvIUz8RS4jgc+D5N6GrYm+oaBXhSs=; b=Kd+5Eq8o+FQRbJGr8UcPD5wM07qibGiCkutqEG8pAtzcF+rpDFV4ezAr8r4gAS/wH+ LJLenclBunzpP1vwtmF4N50BiMOA5ozsRGD/tE6gLJ2MzsbC+XjA73uTlXKkXNWuTuzZ 0HBOZFjYpXPMFML/gq/fbK9wBP+uczwPlYqOjrIbewKiAIbz/J/W7Zfnt6DksO0hmrMw G249vMbxkA7GRVZ8Wv7FXQALH+FhB2097TaYjFlGx6WJhmZOFVJFN4gcAnLiqMPbHvTj uf8dvl3FwUAZNZ1yB+Tf3QjsZkE5Eid/4iDSiCMsXHEl7qoueYL6esQje0rA8kcmhDO0 y1qA== X-Gm-Message-State: ALoCoQneHSuZy204njMkOsVTi3iubrolBe2J/3Vt3Ot4K4Pw3RcGAYzPzuIjWH97ycd+wpKYqeXe X-Received: by 10.13.255.2 with SMTP id p2mr1937575ywf.149.1437567050985; Wed, 22 Jul 2015 05:10:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.8.201 with HTTP; Wed, 22 Jul 2015 05:10:31 -0700 (PDT) In-Reply-To: <55AF878E.1090200@gmail.com> References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> <55AD3B64.5070400@acm.org> <55AF0964.1060006@gmail.com> <55AF878E.1090200@gmail.com> From: Lorenzo Colitti Date: Wed, 22 Jul 2015 14:10:31 +0200 Message-ID: To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=94eb2c0888f66a9424051b75a97a Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 22 Jul 2015 12:11:16 -0000 --94eb2c0888f66a9424051b75a97a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm told the problem affects iPhones as well. On Wed, Jul 22, 2015 at 2:07 PM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > "Reducing battery impact of RAs on Androids"? > > Alex > > Le 22/07/2015 12:22, Lorenzo Colitti a =C3=A9crit : > >> Thanks for all the feedback. We have posted a -01 addressing some of the >> feedback we got. The new version also contains a new recommendation not >> to send periodic RAs too frequently, so we have changed the title to >> "Reducing battery impact of Router Advertisements". >> >> https://tools.ietf.org/html/draft-yc-v6ops-solicited-ra-unicast-01 >> >> If there are no objections, we will upload this as a WG document in the >> next few days. >> >> On Wed, Jul 22, 2015 at 5:09 AM, Alejandro Acosta >> > >> wrote: >> >> Hi There, >> I also support this document, it's very positive to see that this >> algorithm will save energy. >> >> Regards, >> >> Alejandro, >> >> El 7/21/2015 a las 6:11 PM, Nabil Benamar escribi=C3=B3: >> >>> Hi Folks, >>> >>> I support this document which is very informative, useful and its >>> implementation will certainly reduce energy consumption due to >>> excessive Multicast RA sent. The proposed algorithm seems to be >>> suitable for this end ! >>> >>> >>> Best regards >>> >>> >>> >>> On Tue, Jul 21, 2015 at 4:38 PM, Owen DeLong >> > wrote: >>> >>> It seems to me that the following algorithm would be >>> relatively easy to implement >>> and provide reasonable network optimization=E2=80=A6 >>> >>> >>> On receipt of an RS: >>> >>> if(multicast_ra_time_remaining > 15 seconds) >>> { >>> Send_Unicast_ra >>> } >>> else >>> { >>> Send_Multicast_ra >>> reset_multicast_timer >>> } >>> >>> In this way, if the timing is reasonably close, you multicast >>> a packet you were about to send >>> anyway, but if the timing isn=E2=80=99t close, you=E2=80=99re n= ot wasting >>> multicast bandwidth answering a single >>> node where nobody else cares. >>> >>> Overall, I=E2=80=99ve always thought that multicast response to= RS was >>> kind of silly. It=E2=80=99s probably most >>> harmful on WiFi. >>> >>> Owen >>> >>> > On Jul 21, 2015, at 02:33 , Andrew =F0=9F=91=BD Yourtchenko >>> > wrote: >>> > >>> > On 7/20/15, Erik Nordmark >>> <nordmark@acm.org >>> >>> > wrote: >>> >> On 7/17/15 9:34 AM, Fred Baker (fred) wrote: >>> >>>> So the next logical thing to do would be to have the >>> router default to >>> >>>> unicast Router Advertisements, measure the rate of >>> received Router >>> >>>> Solicitations, and switch to multicast RA mode past a >>> certain >>> >>>> threshold to cover this sort of situation. Once the >>> number of RSes >>> >>>> falls, it switches back to unicast RA mode. >>> >>>> >>> >>>> That would get rid of the configuration knob proposed in >>> this ID, and >>> >>>> is behaviour that I think could be universal for all link >>> types, >>> >>>> rather than just for the case of wireless ones with >>> mobile devices. >>> >>> If it were me implementing it, I think I would go about >>> this in a little >>> >>> different way, hopefully simpler. I would want to send at >>> most one (e.g., >>> >>> either zero or one) RA per some interval (a second?). In >>> the normal case, >>> >>> that is sent unicast. However, having sent a unicast RA at >>> time t, if I >>> >>> now receive another RS before t+1, I send the next one (at >>> time t+1) as a >>> >>> multicast. >>> >> >>> >> First of all I support this document as a WG document. >>> >> >>> >> But in terms of implementation, isn't it simpler to >>> always(*) respond to >>> >> a RS with a unicast RA? >>> > >>> > Yes. I did not respond on-list yet - but from operational >>> perspective >>> > "always send solRA unicast" / "always send solRA multicast" >>> definitely >>> > wins in my book, and I'd avoid premature optimizations (but >>> maybe we >>> > can say the implementers are explicitly free to do their own >>> > optimizations if they see fit) >>> > >>> > That said, will be very interesting to hear data from folks >>> who will >>> > run "all-unicast solRA", in real networks and then compare >>> the effect >>> > of their proposal optimizations on their real-world scenarios= . >>> > >>> >> As background, the text in RFC4861 comes from the old >>> concern that all >>> >> devices might boot at the same time when the power is >>> re-established >>> >> after a building power failure; that doesn't happen since >>> most devices >>> >> (laptops, smartphones, IoT devices) have batteries today. >>> In that case >>> >> it might have made sense to sending fewer RA messages by >>> using multicast. >>> >> >>> >> (*) the only case in RFC 4861 when I think a multicast >>> response might be >>> >> considered is when the source IPv6 address in the RS is the >>> unspecified >>> >> address. Further, an implementation which rate limits >>> received RS >>> >> packets (e.g., CoPP in a router) might also want to detect >>> when the rate >>> >> limit might have dropped RS packets and multicast an RA in >>> that case. >>> >> >>> >> >>> >> I do wonder why implementations haven't already changed to >>> send unicast >>> >> solicited RA, and whether it would make a difference if we >>> have an >>> > >>> > TBH that's my concern as well. I think we should tweak the >>> text in >>> > 4861 to encourage a bit more consideration on the >>> implementer's side. >>> > >>> >> informational document asking them to do this. >>> Alternatively we could >>> >> have a proposed standard which updates section 6.2.6 to >>> change the "MAY >>> >> unicast" to a "SHOULD unicast". >>> > >>> > Yeah, I actually have had the different text aimed for 6man, >>> but >>> > Lorenzo's concern was 6man would say "there is no protocol >>> update >>> > here, go away", so he rewrote it for v6ops. >>> > >>> > We should probably discuss this at the mic and get the >>> opinion of the >>> > 6man chairs - if there is no outright "no" on this, a >>> normative doc >>> > would be a better way to convince the implementers ? >>> > >>> >> >>> >> FWIW the draft incorrectly refers to section 6.2.4 instead >>> of 6.2.6. >>> > >>> > Nice catch, thanks! >>> > >>> > --a >>> > >>> >> >>> >> Thanks, >>> >> Erik >>> >> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> 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 >>> >>> _______________________________________________ >>> 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 >> >> >> >> >> _______________________________________________ >> 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 > --94eb2c0888f66a9424051b75a97a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm told the problem affects iPhones as well.

On Wed, Jul 22, 2015= at 2:07 PM, Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:
"Reducing batte= ry impact of RAs on Androids"?

Alex

Le 22/07/2015 12:22, Lorenzo Colitti a =C3=A9crit :
Thanks for all the feedback. We have posted a -01 addressing some of the feedback we got. The new version also contains a new recommendation not
to send periodic RAs too frequently, so we have changed the title to
"Reducing battery impact of Router Advertisements".

https://tools.ietf.org/html/draft-= yc-v6ops-solicited-ra-unicast-01

If there are no objections, we will upload this as a WG document in the
next few days.

On Wed, Jul 22, 2015 at 5:09 AM, Alejandro Acosta
<ale= jandroacostaalamo@gmail.com <mailto:alejandroacostaalamo@gmail.com>&= gt;
wrote:

=C2=A0 =C2=A0 Hi There,
=C2=A0 =C2=A0 =C2=A0 =C2=A0I also support this document, it's very posi= tive to see that this
=C2=A0 =C2=A0 algorithm will save energy.

=C2=A0 =C2=A0 Regards,

=C2=A0 =C2=A0 Alejandro,

=C2=A0 =C2=A0 El 7/21/2015 a las 6:11 PM, Nabil Benamar escribi=C3=B3:
=C2=A0 =C2=A0 Hi Folks,

=C2=A0 =C2=A0 I support this document which is very informative, useful and= its
=C2=A0 =C2=A0 implementation will certainly reduce energy consumption due t= o
=C2=A0 =C2=A0 excessive Multicast RA sent. The proposed algorithm seems to = be
=C2=A0 =C2=A0 suitable for this end !


=C2=A0 =C2=A0 Best regards



 =C2=A0 =C2=A0 On Tue, Jul 21, 2015 at 4:38 PM, Owen DeLong <owen@delong.com
 =C2=A0 =C2=A0 <mailto:owen@delong.com>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 It seems to me that the following algorithm wou= ld be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 relatively easy to implement
=C2=A0 =C2=A0 =C2=A0 =C2=A0 and provide reasonable network optimization=E2= =80=A6


=C2=A0 =C2=A0 =C2=A0 =C2=A0 On receipt of an RS:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if(multicast_ra_tim= e_remaining > 15 seconds)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Send_Unicast= _ra
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 else
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Send_Multica= st_ra
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 reset_multic= ast_timer
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }

=C2=A0 =C2=A0 =C2=A0 =C2=A0 In this way, if the timing is reasonably close,= you multicast
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a packet you were about to send
=C2=A0 =C2=A0 =C2=A0 =C2=A0 anyway, but if the timing isn=E2=80=99t close, = you=E2=80=99re not wasting
=C2=A0 =C2=A0 =C2=A0 =C2=A0 multicast bandwidth answering a single
=C2=A0 =C2=A0 =C2=A0 =C2=A0 node where nobody else cares.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Overall, I=E2=80=99ve always thought that multi= cast response to RS was
=C2=A0 =C2=A0 =C2=A0 =C2=A0 kind of silly. It=E2=80=99s probably most
=C2=A0 =C2=A0 =C2=A0 =C2=A0 harmful on WiFi.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Owen

=C2=A0 =C2=A0 =C2=A0 =C2=A0 > On Jul 21, 2015, at 02:33 , Andrew =F0=9F= =91=BD Yourtchenko
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <ayourtch@gmail.com <mailto:ayourtch@gmail.com>> wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > On 7/20/15, Erik Nordmark
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <<mailto:nordmark@acm.org>nordmark@acm.org

=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:nordmark@acm.org>> wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >> On 7/17/15 9:34 AM, Fred Baker (fred) = wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>> So the next logical thing to d= o would be to have the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 router default to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>> unicast Router Advertisements,= measure the rate of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 received Router
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>> Solicitations, and switch to m= ulticast RA mode past a certain
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>> threshold to cover this sort o= f situation. Once the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 number of RSes
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>> falls, it switches back to uni= cast RA mode.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>> That would get rid of the conf= iguration knob proposed in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 this ID, and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>> is behaviour that I think coul= d be universal for all link
=C2=A0 =C2=A0 =C2=A0 =C2=A0 types,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>> rather than just for the case = of wireless ones with
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mobile devices.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >>> If it were me implementing it, I t= hink I would go about
=C2=A0 =C2=A0 =C2=A0 =C2=A0 this in a little
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >>> different way, hopefully simpler. = I would want to send at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 most one (e.g.,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >>> either zero or one) RA per some in= terval (a second?). In
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the normal case,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >>> that is sent unicast. However, hav= ing sent a unicast RA at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 time t, if I
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >>> now receive another RS before t+1,= I send the next one (at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 time t+1) as a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >>> multicast.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >> First of all I support this document a= s a WG document.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >> But in terms of implementation, isn= 9;t it simpler to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 always(*) respond to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >> a RS with a unicast RA?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > Yes. I did not respond on-list yet - but f= rom operational
=C2=A0 =C2=A0 =C2=A0 =C2=A0 perspective
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > "always send solRA unicast" / &q= uot;always send solRA multicast"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 definitely
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > wins in my book, and I'd avoid prematu= re optimizations (but
=C2=A0 =C2=A0 =C2=A0 =C2=A0 maybe we
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > can say the implementers are explicitly fr= ee to do their own
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > optimizations if they see fit)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > That said, will be very interesting to hea= r data from folks
=C2=A0 =C2=A0 =C2=A0 =C2=A0 who will
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > run "all-unicast solRA", in real= networks and then compare
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the effect
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > of their proposal optimizations on their r= eal-world scenarios.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >> As background, the text in RFC4861 com= es from the old
=C2=A0 =C2=A0 =C2=A0 =C2=A0 concern that all
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >> devices might boot at the same time wh= en the power is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 re-established
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >> after a building power failure; that d= oesn't happen since
=C2=A0 =C2=A0 =C2=A0 =C2=A0 most devices
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >> (laptops, smartphones, IoT devices) ha= ve batteries today.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 In that case
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >> it might have made sense to sending fe= wer RA messages by
=C2=A0 =C2=A0 =C2=A0 =C2=A0 using multicast.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >> (*) the only case in RFC 4861 when I t= hink a multicast
=C2=A0 =C2=A0 =C2=A0 =C2=A0 response might be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >> considered is when the source IPv6 add= ress in the RS is the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 unspecified
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >> address. Further, an implementation wh= ich rate limits
=C2=A0 =C2=A0 =C2=A0 =C2=A0 received RS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >> packets (e.g., CoPP in a router) might= also want to detect
=C2=A0 =C2=A0 =C2=A0 =C2=A0 when the rate
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >> limit might have dropped RS packets an= d multicast an RA in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 that case.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >> I do wonder why implementations haven&= #39;t already changed to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 send unicast
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >> solicited RA, and whether it would mak= e a difference if we
=C2=A0 =C2=A0 =C2=A0 =C2=A0 have an
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > TBH that's my concern as well. I think= we should tweak the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 text in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > 4861 to encourage a bit more consideration= on the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 implementer's side.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >> informational document asking them to = do this.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Alternatively we could
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >> have a proposed standard which updates= section 6.2.6 to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 change the "MAY
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >> unicast" to a "SHOULD unicas= t".
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > Yeah, I actually have had the different te= xt aimed for 6man, but
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > Lorenzo's concern was 6man would say &= quot;there is no protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 update
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > here, go away", so he rewrote it for = v6ops.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > We should probably discuss this at the mic= and get the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 opinion of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > 6man chairs - if there is no outright &quo= t;no" on this, a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 normative doc
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > would be a better way to convince the impl= ementers ?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >> FWIW the draft incorrectly refers to s= ection 6.2.4 instead
=C2=A0 =C2=A0 =C2=A0 =C2=A0 of 6.2.6.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > Nice catch, thanks!
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > --a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >> Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 Erik
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >>> __________________________________= _____________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >>> v6ops mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >>> v6ops@ietf.org <mailto:v6ops@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >>> https://www.ietf= .org/mailman/listinfo/v6ops
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >> ______________________________________= _________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >> v6ops mailing list
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >> v6ops@ietf.org <mailto:v6ops@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >> https://www.ietf.org= /mailman/listinfo/v6ops
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > __________________________________________= _____
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > v6ops mailing list
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > v6ops@ietf.org <mailto:v6ops@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > https://www.ietf.org/mai= lman/listinfo/v6ops

=C2=A0 =C2=A0 =C2=A0 =C2=A0 _______________________________________________=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 v6ops mailing list
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 v6ops@ietf.org <mailto:v6ops@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/= listinfo/v6ops




=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 v6ops mailing list
 =C2=A0 =C2=A0 v6ops@iet= f.org <mailto:v6= ops@ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/v6o= ps


=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 v6ops mailing list
=C2=A0 =C2=A0 v6ops@iet= f.org <mailto:v6= ops@ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/v6o= ps




_______________________________________________
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

--94eb2c0888f66a9424051b75a97a-- From nobody Wed Jul 22 05:12:25 2015 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 549021A0390 for ; Wed, 22 Jul 2015 05:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8-HnWrz4XYJ for ; Wed, 22 Jul 2015 05:12:19 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 601771A0173 for ; Wed, 22 Jul 2015 05:12:18 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6MCCGE6022761; Wed, 22 Jul 2015 14:12:16 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 584652027AA; Wed, 22 Jul 2015 14:15:51 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 4A5E22027A8; Wed, 22 Jul 2015 14:15:51 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.215]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6MCCFIh022549; Wed, 22 Jul 2015 14:12:15 +0200 To: Lorenzo Colitti References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> <55AD3B64.5070400@acm.org> <55AF0964.1060006@gmail.com> <55AF878E.1090200@gmail.com> From: Alexandru Petrescu Message-ID: <55AF889F.6080206@gmail.com> Date: Wed, 22 Jul 2015 14:12:15 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.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] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 22 Jul 2015 12:12:24 -0000 "... on Androids and iPhones"? But not on huawei E392. Alex Le 22/07/2015 14:10, Lorenzo Colitti a écrit : > I'm told the problem affects iPhones as well. > > On Wed, Jul 22, 2015 at 2:07 PM, Alexandru Petrescu > > wrote: > > "Reducing battery impact of RAs on Androids"? > > Alex > > Le 22/07/2015 12:22, Lorenzo Colitti a écrit : > > Thanks for all the feedback. We have posted a -01 addressing > some of the > feedback we got. The new version also contains a new > recommendation not > to send periodic RAs too frequently, so we have changed the title to > "Reducing battery impact of Router Advertisements". > > https://tools.ietf.org/html/draft-yc-v6ops-solicited-ra-unicast-01 > > If there are no objections, we will upload this as a WG document > in the > next few days. > > On Wed, Jul 22, 2015 at 5:09 AM, Alejandro Acosta > > >> > wrote: > > Hi There, > I also support this document, it's very positive to see > that this > algorithm will save energy. > > Regards, > > Alejandro, > > El 7/21/2015 a las 6:11 PM, Nabil Benamar escribió: > > Hi Folks, > > I support this document which is very informative, > useful and its > implementation will certainly reduce energy consumption > due to > excessive Multicast RA sent. The proposed algorithm > seems to be > suitable for this end ! > > > Best regards > > > > On Tue, Jul 21, 2015 at 4:38 PM, Owen DeLong > > >> wrote: > > It seems to me that the following algorithm would be > relatively easy to implement > and provide reasonable network optimization… > > > On receipt of an RS: > > if(multicast_ra_time_remaining > 15 seconds) > { > Send_Unicast_ra > } > else > { > Send_Multicast_ra > reset_multicast_timer > } > > In this way, if the timing is reasonably close, you > multicast > a packet you were about to send > anyway, but if the timing isn’t close, you’re not > wasting > multicast bandwidth answering a single > node where nobody else cares. > > Overall, I’ve always thought that multicast > response to RS was > kind of silly. It’s probably most > harmful on WiFi. > > Owen > > > On Jul 21, 2015, at 02:33 , Andrew 👽 Yourtchenko > > >> wrote: > > > > On 7/20/15, Erik Nordmark > < >nordmark@acm.org > > > >> wrote: > >> On 7/17/15 9:34 AM, Fred Baker (fred) wrote: > >>>> So the next logical thing to do would be to > have the > router default to > >>>> unicast Router Advertisements, measure the rate of > received Router > >>>> Solicitations, and switch to multicast RA mode > past a certain > >>>> threshold to cover this sort of situation. > Once the > number of RSes > >>>> falls, it switches back to unicast RA mode. > >>>> > >>>> That would get rid of the configuration knob > proposed in > this ID, and > >>>> is behaviour that I think could be universal > for all link > types, > >>>> rather than just for the case of wireless ones > with > mobile devices. > >>> If it were me implementing it, I think I would > go about > this in a little > >>> different way, hopefully simpler. I would want > to send at > most one (e.g., > >>> either zero or one) RA per some interval (a > second?). In > the normal case, > >>> that is sent unicast. However, having sent a > unicast RA at > time t, if I > >>> now receive another RS before t+1, I send the > next one (at > time t+1) as a > >>> multicast. > >> > >> First of all I support this document as a WG > document. > >> > >> But in terms of implementation, isn't it simpler to > always(*) respond to > >> a RS with a unicast RA? > > > > Yes. I did not respond on-list yet - but from > operational > perspective > > "always send solRA unicast" / "always send solRA > multicast" > definitely > > wins in my book, and I'd avoid premature > optimizations (but > maybe we > > can say the implementers are explicitly free to > do their own > > optimizations if they see fit) > > > > That said, will be very interesting to hear data > from folks > who will > > run "all-unicast solRA", in real networks and > then compare > the effect > > of their proposal optimizations on their > real-world scenarios. > > > >> As background, the text in RFC4861 comes from > the old > concern that all > >> devices might boot at the same time when the > power is > re-established > >> after a building power failure; that doesn't > happen since > most devices > >> (laptops, smartphones, IoT devices) have > batteries today. > In that case > >> it might have made sense to sending fewer RA > messages by > using multicast. > >> > >> (*) the only case in RFC 4861 when I think a > multicast > response might be > >> considered is when the source IPv6 address in > the RS is the > unspecified > >> address. Further, an implementation which rate > limits > received RS > >> packets (e.g., CoPP in a router) might also want > to detect > when the rate > >> limit might have dropped RS packets and > multicast an RA in > that case. > >> > >> > >> I do wonder why implementations haven't already > changed to > send unicast > >> solicited RA, and whether it would make a > difference if we > have an > > > > TBH that's my concern as well. I think we should > tweak the > text in > > 4861 to encourage a bit more consideration on the > implementer's side. > > > >> informational document asking them to do this. > Alternatively we could > >> have a proposed standard which updates section > 6.2.6 to > change the "MAY > >> unicast" to a "SHOULD unicast". > > > > Yeah, I actually have had the different text > aimed for 6man, but > > Lorenzo's concern was 6man would say "there is no > protocol > update > > here, go away", so he rewrote it for v6ops. > > > > We should probably discuss this at the mic and > get the > opinion of the > > 6man chairs - if there is no outright "no" on this, a > normative doc > > would be a better way to convince the implementers ? > > > >> > >> FWIW the draft incorrectly refers to section > 6.2.4 instead > of 6.2.6. > > > > Nice catch, thanks! > > > > --a > > > >> > >> Thanks, > >> Erik > >> > >>> > >>> > >>> _______________________________________________ > >>> 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 > > _______________________________________________ > 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 > > > > > _______________________________________________ > 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 Jul 22 05:14:30 2015 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 D77901B2FFC for ; Wed, 22 Jul 2015 05:14:28 -0700 (PDT) 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 sAXPMJ_Grn3I for ; Wed, 22 Jul 2015 05:14:24 -0700 (PDT) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD7851B301A for ; Wed, 22 Jul 2015 05:14:12 -0700 (PDT) Received: by ykdu72 with SMTP id u72so190547741ykd.2 for ; Wed, 22 Jul 2015 05:14:12 -0700 (PDT) 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=/CEcQsn0rCnJgR0BX1BWWTzsE0LOJHwfyVrHBZBQVEk=; b=b5aYnyEcpoLJsRVdkLyhBb85UgDtISeQL69oNLDZ5LF5Kvss4xQrqTVpp3He00J9bg Yc/NUhYhIoX7MC1TNckWixWIiwj+/bq1srB+WKsezPLlFXCPl6WOYWUlxjBJRFh84Mmi sjSg7l/q0SClBWJwGp1Jidw/9KJdj4TcxVWOt62j8+mzDbMXglF29+JervMH2J+qKjzT kVvgpVq+jJPXdyoIKx6vDkO5rv6+w1BmHYiCXGnHQhJzRBArUFjwuqkfubs+tpM2A6hx V0n8Fj7pr5tySbSZIf9hUuUv/ZOlaDY6IMvBlpy/+bFRRdhxo5qEO+iWKSJorcWztUpu nAew== 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=/CEcQsn0rCnJgR0BX1BWWTzsE0LOJHwfyVrHBZBQVEk=; b=WhBABBfd69ahQCvb5oqFIcS3jJFeZ6LwxIE1yQ0tAm9Zvg82WiPkKudhpeNDkdDMD6 Q63dHlacK+IWZM445x6Xh5M+AO6H2bAaz5PVOd7rYMqpHbIo/kev564LYAmZ7AGC5o3g mD4kdZMik4zxNpMS64Tm7eP+JT/rFjxpEJNdWz21k8i/Vh8K56qb4bdxsnGalfuRhNHS hahGdCav0JW/wFYkWY9FuIBaxtj/eUJimT5GaSZUdkIO1l2c9paFsYgrJ5dPIKjpFELb Y7q/yI9zRtefgexQUV5RtEvu+4MW+ET+zobggE0T6TULhkJq/ASaKi/dsnKZpif2cHoY HxkA== X-Gm-Message-State: ALoCoQkgPF3YZjjXiQFF9+QonKzRNRLUIuCzTBqK0DUgh0N2p2nECWwR3BWbWIPc8+JPyG1nNq/R X-Received: by 10.13.247.3 with SMTP id h3mr2134187ywf.142.1437567252077; Wed, 22 Jul 2015 05:14:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.8.201 with HTTP; Wed, 22 Jul 2015 05:13:52 -0700 (PDT) In-Reply-To: <55AF889F.6080206@gmail.com> References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> <55AD3B64.5070400@acm.org> <55AF0964.1060006@gmail.com> <55AF878E.1090200@gmail.com> <55AF889F.6080206@gmail.com> From: Lorenzo Colitti Date: Wed, 22 Jul 2015 14:13:52 +0200 Message-ID: To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=94eb2c0802a066f5fd051b75b539 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 22 Jul 2015 12:14:29 -0000 --94eb2c0802a066f5fd051b75b539 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm sure that the huawei E392 obeys the laws of physics as well. On Wed, Jul 22, 2015 at 2:12 PM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > "... on Androids and iPhones"? > > But not on huawei E392. > > Alex > > > Le 22/07/2015 14:10, Lorenzo Colitti a =C3=A9crit : > >> I'm told the problem affects iPhones as well. >> >> On Wed, Jul 22, 2015 at 2:07 PM, Alexandru Petrescu >> > >> wrote: >> >> "Reducing battery impact of RAs on Androids"? >> >> Alex >> >> Le 22/07/2015 12:22, Lorenzo Colitti a =C3=A9crit : >> >> Thanks for all the feedback. We have posted a -01 addressing >> some of the >> feedback we got. The new version also contains a new >> recommendation not >> to send periodic RAs too frequently, so we have changed the titl= e >> to >> "Reducing battery impact of Router Advertisements". >> >> >> https://tools.ietf.org/html/draft-yc-v6ops-solicited-ra-unicast-01 >> >> If there are no objections, we will upload this as a WG document >> in the >> next few days. >> >> On Wed, Jul 22, 2015 at 5:09 AM, Alejandro Acosta >> > >> > >> >> wrote: >> >> Hi There, >> I also support this document, it's very positive to see >> that this >> algorithm will save energy. >> >> Regards, >> >> Alejandro, >> >> El 7/21/2015 a las 6:11 PM, Nabil Benamar escribi=C3=B3: >> >> Hi Folks, >> >> I support this document which is very informative, >> useful and its >> implementation will certainly reduce energy consumption >> due to >> excessive Multicast RA sent. The proposed algorithm >> seems to be >> suitable for this end ! >> >> >> Best regards >> >> >> >> On Tue, Jul 21, 2015 at 4:38 PM, Owen DeLong >> >> >> >> wrote: >> >> It seems to me that the following algorithm would b= e >> relatively easy to implement >> and provide reasonable network optimization=E2=80= =A6 >> >> >> On receipt of an RS: >> >> if(multicast_ra_time_remaining > 15 seconds= ) >> { >> Send_Unicast_ra >> } >> else >> { >> Send_Multicast_ra >> reset_multicast_timer >> } >> >> In this way, if the timing is reasonably close, you >> multicast >> a packet you were about to send >> anyway, but if the timing isn=E2=80=99t close, you= =E2=80=99re not >> wasting >> multicast bandwidth answering a single >> node where nobody else cares. >> >> Overall, I=E2=80=99ve always thought that multicast >> response to RS was >> kind of silly. It=E2=80=99s probably most >> harmful on WiFi. >> >> Owen >> >> > On Jul 21, 2015, at 02:33 , Andrew [image: =F0=9F= =91=BD] >> Yourtchenko >> >> >> >> wrote: >> > >> > On 7/20/15, Erik Nordmark >> <> >nordmark@acm.org >> >> >> > >> wrote: >> >> On 7/17/15 9:34 AM, Fred Baker (fred) wrote: >> >>>> So the next logical thing to do would be to >> have the >> router default to >> >>>> unicast Router Advertisements, measure the rat= e >> of >> received Router >> >>>> Solicitations, and switch to multicast RA mode >> past a certain >> >>>> threshold to cover this sort of situation. >> Once the >> number of RSes >> >>>> falls, it switches back to unicast RA mode. >> >>>> >> >>>> That would get rid of the configuration knob >> proposed in >> this ID, and >> >>>> is behaviour that I think could be universal >> for all link >> types, >> >>>> rather than just for the case of wireless ones >> with >> mobile devices. >> >>> If it were me implementing it, I think I would >> go about >> this in a little >> >>> different way, hopefully simpler. I would want >> to send at >> most one (e.g., >> >>> either zero or one) RA per some interval (a >> second?). In >> the normal case, >> >>> that is sent unicast. However, having sent a >> unicast RA at >> time t, if I >> >>> now receive another RS before t+1, I send the >> next one (at >> time t+1) as a >> >>> multicast. >> >> >> >> First of all I support this document as a WG >> document. >> >> >> >> But in terms of implementation, isn't it simpler >> to >> always(*) respond to >> >> a RS with a unicast RA? >> > >> > Yes. I did not respond on-list yet - but from >> operational >> perspective >> > "always send solRA unicast" / "always send solRA >> multicast" >> definitely >> > wins in my book, and I'd avoid premature >> optimizations (but >> maybe we >> > can say the implementers are explicitly free to >> do their own >> > optimizations if they see fit) >> > >> > That said, will be very interesting to hear data >> from folks >> who will >> > run "all-unicast solRA", in real networks and >> then compare >> the effect >> > of their proposal optimizations on their >> real-world scenarios. >> > >> >> As background, the text in RFC4861 comes from >> the old >> concern that all >> >> devices might boot at the same time when the >> power is >> re-established >> >> after a building power failure; that doesn't >> happen since >> most devices >> >> (laptops, smartphones, IoT devices) have >> batteries today. >> In that case >> >> it might have made sense to sending fewer RA >> messages by >> using multicast. >> >> >> >> (*) the only case in RFC 4861 when I think a >> multicast >> response might be >> >> considered is when the source IPv6 address in >> the RS is the >> unspecified >> >> address. Further, an implementation which rate >> limits >> received RS >> >> packets (e.g., CoPP in a router) might also want >> to detect >> when the rate >> >> limit might have dropped RS packets and >> multicast an RA in >> that case. >> >> >> >> >> >> I do wonder why implementations haven't already >> changed to >> send unicast >> >> solicited RA, and whether it would make a >> difference if we >> have an >> > >> > TBH that's my concern as well. I think we should >> tweak the >> text in >> > 4861 to encourage a bit more consideration on the >> implementer's side. >> > >> >> informational document asking them to do this. >> Alternatively we could >> >> have a proposed standard which updates section >> 6.2.6 to >> change the "MAY >> >> unicast" to a "SHOULD unicast". >> > >> > Yeah, I actually have had the different text >> aimed for 6man, but >> > Lorenzo's concern was 6man would say "there is no >> protocol >> update >> > here, go away", so he rewrote it for v6ops. >> > >> > We should probably discuss this at the mic and >> get the >> opinion of the >> > 6man chairs - if there is no outright "no" on >> this, a >> normative doc >> > would be a better way to convince the implementer= s >> ? >> > >> >> >> >> FWIW the draft incorrectly refers to section >> 6.2.4 instead >> of 6.2.6. >> > >> > Nice catch, thanks! >> > >> > --a >> > >> >> >> >> Thanks, >> >> Erik >> >> >> >>> >> >>> >> >>> _______________________________________________ >> >>> 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 >> >> _______________________________________________ >> 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 >> >> >> >> >> _______________________________________________ >> 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 >> >> >> > --94eb2c0802a066f5fd051b75b539 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+SSYjMzk7bSBzdXJlIHRoYXQgdGhlIGh1YXdlacKgRTM5MiBvYmV5cyB0 aGUgbGF3cyBvZiBwaHlzaWNzIGFzIHdlbGwuPC9kaXY+PGRpdiBjbGFzcz0iZ21haWxfZXh0cmEi Pjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gV2VkLCBKdWwgMjIsIDIwMTUgYXQgMjox MiBQTSwgQWxleGFuZHJ1IFBldHJlc2N1IDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFp bHRvOmFsZXhhbmRydS5wZXRyZXNjdUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5hbGV4YW5k cnUucGV0cmVzY3VAZ21haWwuY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj48YmxvY2txdW90 ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVm dDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4mcXVvdDsuLi4gb24gQW5kcm9pZHMg YW5kIGlQaG9uZXMmcXVvdDs/PGJyPg0KPGJyPg0KQnV0IG5vdCBvbiBodWF3ZWkgRTM5Mi48YnI+ DQo8YnI+DQpBbGV4PHNwYW4gY2xhc3M9IiI+PGJyPg0KPGJyPg0KPGJyPg0KTGUgMjIvMDcvMjAx NSAxNDoxMCwgTG9yZW56byBDb2xpdHRpIGEgw6ljcml0IDo8YnI+DQo8L3NwYW4+PGJsb2NrcXVv dGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxl ZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+PHNwYW4gY2xhc3M9IiI+DQpJJiMz OTttIHRvbGQgdGhlIHByb2JsZW0gYWZmZWN0cyBpUGhvbmVzIGFzIHdlbGwuPGJyPg0KPGJyPg0K T24gV2VkLCBKdWwgMjIsIDIwMTUgYXQgMjowNyBQTSwgQWxleGFuZHJ1IFBldHJlc2N1PGJyPjwv c3Bhbj48c3BhbiBjbGFzcz0iIj4NCiZsdDs8YSBocmVmPSJtYWlsdG86YWxleGFuZHJ1LnBldHJl c2N1QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFsZXhhbmRydS5wZXRyZXNjdUBnbWFpbC5j b208L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmFsZXhhbmRydS5wZXRyZXNjdUBnbWFp bC5jb20iIHRhcmdldD0iX2JsYW5rIj5hbGV4YW5kcnUucGV0cmVzY3VAZ21haWwuY29tPC9hPiZn dDsmZ3Q7IHdyb3RlOjxicj4NCjxicj4NCsKgIMKgICZxdW90O1JlZHVjaW5nIGJhdHRlcnkgaW1w YWN0IG9mIFJBcyBvbiBBbmRyb2lkcyZxdW90Oz88YnI+DQo8YnI+DQrCoCDCoCBBbGV4PGJyPg0K PGJyPg0KwqAgwqAgTGUgMjIvMDcvMjAxNSAxMjoyMiwgTG9yZW56byBDb2xpdHRpIGEgw6ljcml0 IDo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCBUaGFua3MgZm9yIGFsbCB0aGUgZmVlZGJhY2suIFdl IGhhdmUgcG9zdGVkIGEgLTAxIGFkZHJlc3Npbmc8YnI+DQrCoCDCoCDCoCDCoCBzb21lIG9mIHRo ZTxicj4NCsKgIMKgIMKgIMKgIGZlZWRiYWNrIHdlIGdvdC4gVGhlIG5ldyB2ZXJzaW9uIGFsc28g Y29udGFpbnMgYSBuZXc8YnI+DQrCoCDCoCDCoCDCoCByZWNvbW1lbmRhdGlvbiBub3Q8YnI+DQrC oCDCoCDCoCDCoCB0byBzZW5kIHBlcmlvZGljIFJBcyB0b28gZnJlcXVlbnRseSwgc28gd2UgaGF2 ZSBjaGFuZ2VkIHRoZSB0aXRsZSB0bzxicj4NCsKgIMKgIMKgIMKgICZxdW90O1JlZHVjaW5nIGJh dHRlcnkgaW1wYWN0IG9mIFJvdXRlciBBZHZlcnRpc2VtZW50cyZxdW90Oy48YnI+DQo8YnI+DQrC oCDCoCDCoCDCoCA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteWMt djZvcHMtc29saWNpdGVkLXJhLXVuaWNhc3QtMDEiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC15Yy12Nm9wcy1zb2xpY2l0 ZWQtcmEtdW5pY2FzdC0wMTwvYT48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCBJZiB0aGVyZSBhcmUg bm8gb2JqZWN0aW9ucywgd2Ugd2lsbCB1cGxvYWQgdGhpcyBhcyBhIFdHIGRvY3VtZW50PGJyPg0K wqAgwqAgwqAgwqAgaW4gdGhlPGJyPg0KwqAgwqAgwqAgwqAgbmV4dCBmZXcgZGF5cy48YnI+DQo8 YnI+DQrCoCDCoCDCoCDCoCBPbiBXZWQsIEp1bCAyMiwgMjAxNSBhdCA1OjA5IEFNLCBBbGVqYW5k cm8gQWNvc3RhPGJyPg0KwqAgwqAgwqAgwqAgJmx0OzxhIGhyZWY9Im1haWx0bzphbGVqYW5kcm9h Y29zdGFhbGFtb0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5hbGVqYW5kcm9hY29zdGFhbGFt b0BnbWFpbC5jb208L2E+PGJyPg0KwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWls dG86YWxlamFuZHJvYWNvc3RhYWxhbW9AZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+YWxlamFu ZHJvYWNvc3RhYWxhbW9AZ21haWwuY29tPC9hPiZndDs8YnI+PC9zcGFuPg0KwqAgwqAgwqAgwqAg Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86YWxlamFuZHJvYWNvc3RhYWxhbW9AZ21haWwuY29t IiB0YXJnZXQ9Il9ibGFuayI+YWxlamFuZHJvYWNvc3RhYWxhbW9AZ21haWwuY29tPC9hPjxzcGFu IGNsYXNzPSIiPjxicj4NCsKgIMKgIMKgIMKgICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmFs ZWphbmRyb2Fjb3N0YWFsYW1vQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFsZWphbmRyb2Fj b3N0YWFsYW1vQGdtYWlsLmNvbTwvYT4mZ3Q7Jmd0OyZndDs8YnI+DQrCoCDCoCDCoCDCoCB3cm90 ZTo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoEhpIFRoZXJlLDxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIEkgYWxzbyBzdXBwb3J0IHRoaXMgZG9jdW1lbnQsIGl0JiMzOTtzIHZl cnkgcG9zaXRpdmUgdG8gc2VlPGJyPg0KwqAgwqAgwqAgwqAgdGhhdCB0aGlzPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqBhbGdvcml0aG0gd2lsbCBzYXZlIGVuZXJneS48YnI+DQo8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoFJlZ2FyZHMsPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqBB bGVqYW5kcm8sPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqBFbCA3LzIxLzIwMTUgYSBs YXMgNjoxMSBQTSwgTmFiaWwgQmVuYW1hciBlc2NyaWJpw7M6PGJyPg0KPGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqBIaSBGb2xrcyw8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoEkgc3VwcG9ydCB0aGlzIGRvY3VtZW50IHdoaWNoIGlzIHZlcnkgaW5mb3JtYXRpdmUs PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgdXNlZnVsIGFuZCBpdHM8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoGltcGxlbWVudGF0aW9uIHdpbGwgY2VydGFpbmx5IHJlZHVjZSBlbmVyZ3kg Y29uc3VtcHRpb248YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCBkdWUgdG88YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoGV4Y2Vzc2l2ZSBNdWx0aWNhc3QgUkEgc2VudC4gVGhlIHByb3Bvc2Vk IGFsZ29yaXRobTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIHNlZW1zIHRvIGJlPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqBzdWl0YWJsZSBmb3IgdGhpcyBlbmQgITxicj4NCjxicj4NCjxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgQmVzdCByZWdhcmRzPGJyPg0KPGJyPg0KPGJy Pg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBPbiBUdWUsIEp1bCAyMSwgMjAxNSBh dCA0OjM4IFBNLCBPd2VuIERlTG9uZzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgICZsdDs8YSBocmVm PSJtYWlsdG86b3dlbkBkZWxvbmcuY29tIiB0YXJnZXQ9Il9ibGFuayI+b3dlbkBkZWxvbmcuY29t PC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpvd2VuQGRlbG9uZy5jb20iIHRhcmdldD0i X2JsYW5rIj5vd2VuQGRlbG9uZy5jb208L2E+Jmd0Ozxicj48L3NwYW4+PHNwYW4gY2xhc3M9IiI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm93 ZW5AZGVsb25nLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm93ZW5AZGVsb25nLmNvbTwvYT4gJmx0O21h aWx0bzo8YSBocmVmPSJtYWlsdG86b3dlbkBkZWxvbmcuY29tIiB0YXJnZXQ9Il9ibGFuayI+b3dl bkBkZWxvbmcuY29tPC9hPiZndDsmZ3Q7Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoEl0IHNlZW1zIHRvIG1lIHRoYXQgdGhlIGZvbGxvd2luZyBh bGdvcml0aG0gd291bGQgYmU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHJl bGF0aXZlbHkgZWFzeSB0byBpbXBsZW1lbnQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoGFuZCBwcm92aWRlIHJlYXNvbmFibGUgbmV0d29yayBvcHRpbWl6YXRpb27igKY8YnI+ DQo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoE9uIHJlY2VpcHQg b2YgYW4gUlM6PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqBpZihtdWx0aWNhc3RfcmFfdGltZV9yZW1haW5pbmcgJmd0OyAxNSBzZWNvbmRzKTxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgezxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgU2VuZF9VbmljYXN0 X3JhPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB9PGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBlbHNlPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB7PGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBTZW5kX011bHRpY2FzdF9y YTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgcmVz ZXRfbXVsdGljYXN0X3RpbWVyPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqB9PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBJ biB0aGlzIHdheSwgaWYgdGhlIHRpbWluZyBpcyByZWFzb25hYmx5IGNsb3NlLCB5b3U8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCBtdWx0aWNhc3Q8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoGEgcGFja2V0IHlvdSB3ZXJlIGFib3V0IHRvIHNlbmQ8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoGFueXdheSwgYnV0IGlmIHRoZSB0aW1pbmcgaXNu4oCZdCBjbG9z ZSwgeW914oCZcmUgbm90PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgd2FzdGluZzxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgbXVsdGljYXN0IGJhbmR3aWR0aCBhbnN3ZXJpbmcg YSBzaW5nbGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoG5vZGUgd2hlcmUg bm9ib2R5IGVsc2UgY2FyZXMuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqBPdmVyYWxsLCBJ4oCZdmUgYWx3YXlzIHRob3VnaHQgdGhhdCBtdWx0aWNhc3Q8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCByZXNwb25zZSB0byBSUyB3YXM8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoGtpbmQgb2Ygc2lsbHkuIEl04oCZcyBwcm9iYWJseSBtb3N0PGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBoYXJtZnVsIG9uIFdpRmkuPGJyPg0KPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBPd2VuPGJyPg0KPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAmZ3Q7IE9uIEp1bCAyMSwgMjAxNSwgYXQgMDI6MzMg LCBBbmRyZXcgPGltZyBnb29tb2ppPSIxZjQ3ZCIgc3R5bGU9Im1hcmdpbjowIDAuMmV4O3ZlcnRp Y2FsLWFsaWduOm1pZGRsZTttYXgtaGVpZ2h0OjI0cHgiIGFsdD0i8J+RvSI+IFlvdXJ0Y2hlbmtv PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAmbHQ7PGEgaHJlZj0ibWFpbHRv OmF5b3VydGNoQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmF5b3VydGNoQGdtYWlsLmNvbTwv YT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86YXlvdXJ0Y2hAZ21haWwuY29tIiB0YXJnZXQ9 Il9ibGFuayI+YXlvdXJ0Y2hAZ21haWwuY29tPC9hPiZndDs8YnI+PC9zcGFuPjxkaXY+PGRpdiBj bGFzcz0iaDUiPg0KwqAgwqAgwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86 YXlvdXJ0Y2hAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+YXlvdXJ0Y2hAZ21haWwuY29tPC9h PiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpheW91cnRjaEBnbWFpbC5jb20iIHRhcmdldD0i X2JsYW5rIj5heW91cnRjaEBnbWFpbC5jb208L2E+Jmd0OyZndDsmZ3Q7IHdyb3RlOjxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgJmd0Ozxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgJmd0OyBPbiA3LzIwLzE1LCBFcmlrIE5vcmRtYXJrPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAmbHQ7Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86 bm9yZG1hcmtAYWNtLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5vcmRtYXJrQGFjbS5vcmc8L2E+PGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86bm9yZG1hcmtA YWNtLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5vcmRtYXJrQGFjbS5vcmc8L2E+Jmd0OyZndDs8YSBo cmVmPSJtYWlsdG86bm9yZG1hcmtAYWNtLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5vcmRtYXJrQGFj bS5vcmc8L2E+PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWls dG86bm9yZG1hcmtAYWNtLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5vcmRtYXJrQGFjbS5vcmc8L2E+ Jmd0Ozxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgJmx0O21haWx0 bzo8YSBocmVmPSJtYWlsdG86bm9yZG1hcmtAYWNtLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5vcmRt YXJrQGFjbS5vcmc8L2E+PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVm PSJtYWlsdG86bm9yZG1hcmtAYWNtLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5vcmRtYXJrQGFjbS5v cmc8L2E+Jmd0OyZndDsmZ3Q7IHdyb3RlOjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgJmd0OyZndDsgT24gNy8xNy8xNSA5OjM0IEFNLCBGcmVkIEJha2VyIChmcmVkKSB3cm90 ZTo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCZndDsmZ3Q7Jmd0OyZndDsg U28gdGhlIG5leHQgbG9naWNhbCB0aGluZyB0byBkbyB3b3VsZCBiZSB0bzxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIGhhdmUgdGhlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBy b3V0ZXIgZGVmYXVsdCB0bzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgJmd0 OyZndDsmZ3Q7Jmd0OyB1bmljYXN0IFJvdXRlciBBZHZlcnRpc2VtZW50cywgbWVhc3VyZSB0aGUg cmF0ZSBvZjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgcmVjZWl2ZWQgUm91 dGVyPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAmZ3Q7Jmd0OyZndDsmZ3Q7 IFNvbGljaXRhdGlvbnMsIGFuZCBzd2l0Y2ggdG8gbXVsdGljYXN0IFJBIG1vZGU8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCBwYXN0IGEgY2VydGFpbjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgJmd0OyZndDsmZ3Q7Jmd0OyB0aHJlc2hvbGQgdG8gY292ZXIgdGhpcyBzb3J0IG9m IHNpdHVhdGlvbi48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCBPbmNlIHRoZTxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgbnVtYmVyIG9mIFJTZXM8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCZndDsmZ3Q7Jmd0OyZndDsgZmFsbHMsIGl0IHN3aXRjaGVzIGJh Y2sgdG8gdW5pY2FzdCBSQSBtb2RlLjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg Jmd0OyZndDsmZ3Q7Jmd0OyBUaGF0IHdvdWxkIGdldCByaWQgb2YgdGhlIGNvbmZpZ3VyYXRpb24g a25vYjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIHByb3Bvc2VkIGluPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqB0aGlzIElELCBhbmQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCZndDsmZ3Q7Jmd0OyZndDsgaXMgYmVoYXZpb3VyIHRoYXQgSSB0aGluayBj b3VsZCBiZSB1bml2ZXJzYWw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCBmb3IgYWxsIGxpbms8YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHR5cGVzLDxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgJmd0OyZndDsmZ3Q7Jmd0OyByYXRoZXIgdGhhbiBqdXN0IGZv ciB0aGUgY2FzZSBvZiB3aXJlbGVzcyBvbmVzPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgd2l0aDxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgbW9iaWxlIGRldmljZXMuPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAmZ3Q7Jmd0OyZndDsgSWYgaXQgd2VyZSBt ZSBpbXBsZW1lbnRpbmcgaXQsIEkgdGhpbmsgSSB3b3VsZDxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IGdvIGFib3V0PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB0aGlzIGluIGEg bGl0dGxlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAmZ3Q7Jmd0OyZndDsg ZGlmZmVyZW50IHdheSwgaG9wZWZ1bGx5IHNpbXBsZXIuIEkgd291bGQgd2FudDxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIHRvIHNlbmQgYXQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoG1vc3Qgb25lIChlLmcuLDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg Jmd0OyZndDsmZ3Q7IGVpdGhlciB6ZXJvIG9yIG9uZSkgUkEgcGVyIHNvbWUgaW50ZXJ2YWwgKGE8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCBzZWNvbmQ/KS4gSW48YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoHRoZSBub3JtYWwgY2FzZSw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCZndDsmZ3Q7Jmd0OyB0aGF0IGlzIHNlbnQgdW5pY2FzdC4gSG93ZXZlciwg aGF2aW5nIHNlbnQgYTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIHVuaWNhc3QgUkEgYXQ8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHRpbWUgdCwgaWYgSTxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgJmd0OyZndDsmZ3Q7IG5vdyByZWNlaXZlIGFub3RoZXIg UlMgYmVmb3JlIHQrMSwgSSBzZW5kIHRoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIG5leHQgb25l IChhdDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgdGltZSB0KzEpIGFzIGE8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCZndDsmZ3Q7Jmd0OyBtdWx0aWNh c3QuPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAmZ3Q7Jmd0Ozxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgJmd0OyZndDsgRmlyc3Qgb2YgYWxsIEkgc3Vw cG9ydCB0aGlzIGRvY3VtZW50IGFzIGEgV0c8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCBkb2N1bWVu dC48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCZndDsmZ3Q7PGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAmZ3Q7Jmd0OyBCdXQgaW4gdGVybXMgb2YgaW1w bGVtZW50YXRpb24sIGlzbiYjMzk7dCBpdCBzaW1wbGVyIHRvPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqBhbHdheXMoKikgcmVzcG9uZCB0bzxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgJmd0OyZndDsgYSBSUyB3aXRoIGEgdW5pY2FzdCBSQT88YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCZndDs8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCZndDsgWWVzLiBJIGRpZCBub3QgcmVzcG9uZCBvbi1saXN0IHlldCAt IGJ1dCBmcm9tPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgb3BlcmF0aW9uYWw8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHBlcnNwZWN0aXZlPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAmZ3Q7ICZxdW90O2Fsd2F5cyBzZW5kIHNvbFJBIHVuaWNhc3QmcXVv dDsgLyAmcXVvdDthbHdheXMgc2VuZCBzb2xSQTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIG11bHRp Y2FzdCZxdW90Ozxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgZGVmaW5pdGVs eTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgJmd0OyB3aW5zIGluIG15IGJv b2ssIGFuZCBJJiMzOTtkIGF2b2lkIHByZW1hdHVyZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIG9w dGltaXphdGlvbnMgKGJ1dDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgbWF5 YmUgd2U8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCZndDsgY2FuIHNheSB0 aGUgaW1wbGVtZW50ZXJzIGFyZSBleHBsaWNpdGx5IGZyZWUgdG88YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCBkbyB0aGVpciBvd248YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCZn dDsgb3B0aW1pemF0aW9ucyBpZiB0aGV5IHNlZSBmaXQpPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAmZ3Q7PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAm Z3Q7IFRoYXQgc2FpZCwgd2lsbCBiZSB2ZXJ5IGludGVyZXN0aW5nIHRvIGhlYXIgZGF0YTxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIGZyb20gZm9sa3M8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoHdobyB3aWxsPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAm Z3Q7IHJ1biAmcXVvdDthbGwtdW5pY2FzdCBzb2xSQSZxdW90OywgaW4gcmVhbCBuZXR3b3JrcyBh bmQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCB0aGVuIGNvbXBhcmU8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoHRoZSBlZmZlY3Q8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCZndDsgb2YgdGhlaXIgcHJvcG9zYWwgb3B0aW1pemF0aW9ucyBvbiB0aGVpcjxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIHJlYWwtd29ybGQgc2NlbmFyaW9zLjxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgJmd0Ozxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgJmd0OyZndDsgQXMgYmFja2dyb3VuZCwgdGhlIHRleHQgaW4gUkZDNDg2MSBjb21l cyBmcm9tPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgdGhlIG9sZDxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgY29uY2VybiB0aGF0IGFsbDxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgJmd0OyZndDsgZGV2aWNlcyBtaWdodCBib290IGF0IHRoZSBzYW1lIHRp bWUgd2hlbiB0aGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCBwb3dlciBpczxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgcmUtZXN0YWJsaXNoZWQ8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCZndDsmZ3Q7IGFmdGVyIGEgYnVpbGRpbmcgcG93ZXIgZmFpbHVy ZTsgdGhhdCBkb2VzbiYjMzk7dDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIGhhcHBlbiBzaW5jZTxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgbW9zdCBkZXZpY2VzPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAmZ3Q7Jmd0OyAobGFwdG9wcywgc21hcnRwaG9u ZXMsIElvVCBkZXZpY2VzKSBoYXZlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgYmF0dGVyaWVzIHRv ZGF5Ljxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgSW4gdGhhdCBjYXNlPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAmZ3Q7Jmd0OyBpdCBtaWdodCBoYXZl IG1hZGUgc2Vuc2UgdG8gc2VuZGluZyBmZXdlciBSQTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIG1l c3NhZ2VzIGJ5PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB1c2luZyBtdWx0 aWNhc3QuPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAmZ3Q7Jmd0Ozxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgJmd0OyZndDsgKCopIHRoZSBvbmx5IGNh c2UgaW4gUkZDIDQ4NjEgd2hlbiBJIHRoaW5rIGE8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCBtdWx0 aWNhc3Q8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHJlc3BvbnNlIG1pZ2h0 IGJlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAmZ3Q7Jmd0OyBjb25zaWRl cmVkIGlzIHdoZW4gdGhlIHNvdXJjZSBJUHY2IGFkZHJlc3MgaW48YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCB0aGUgUlMgaXMgdGhlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB1 bnNwZWNpZmllZDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgJmd0OyZndDsg YWRkcmVzcy4gRnVydGhlciwgYW4gaW1wbGVtZW50YXRpb24gd2hpY2ggcmF0ZTxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIGxpbWl0czxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg cmVjZWl2ZWQgUlM8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCZndDsmZ3Q7 IHBhY2tldHMgKGUuZy4sIENvUFAgaW4gYSByb3V0ZXIpIG1pZ2h0IGFsc28gd2FudDxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIHRvIGRldGVjdDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgd2hlbiB0aGUgcmF0ZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg Jmd0OyZndDsgbGltaXQgbWlnaHQgaGF2ZSBkcm9wcGVkIFJTIHBhY2tldHMgYW5kPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgbXVsdGljYXN0IGFuIFJBIGluPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqB0aGF0IGNhc2UuPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAmZ3Q7Jmd0Ozxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgJmd0OyZn dDs8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCZndDsmZ3Q7IEkgZG8gd29u ZGVyIHdoeSBpbXBsZW1lbnRhdGlvbnMgaGF2ZW4mIzM5O3QgYWxyZWFkeTxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIGNoYW5nZWQgdG88YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oHNlbmQgdW5pY2FzdDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgJmd0OyZn dDsgc29saWNpdGVkIFJBLCBhbmQgd2hldGhlciBpdCB3b3VsZCBtYWtlIGE8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCBkaWZmZXJlbmNlIGlmIHdlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqBoYXZlIGFuPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAmZ3Q7 PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAmZ3Q7IFRCSCB0aGF0JiMzOTtz IG15IGNvbmNlcm4gYXMgd2VsbC4gSSB0aGluayB3ZSBzaG91bGQ8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCB0d2VhayB0aGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHRleHQg aW48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCZndDsgNDg2MSB0byBlbmNv dXJhZ2UgYSBiaXQgbW9yZSBjb25zaWRlcmF0aW9uIG9uIHRoZTxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgaW1wbGVtZW50ZXImIzM5O3Mgc2lkZS48YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCZndDs8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCZndDsmZ3Q7IGluZm9ybWF0aW9uYWwgZG9jdW1lbnQgYXNraW5nIHRoZW0gdG8gZG8g dGhpcy48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoEFsdGVybmF0aXZlbHkg d2UgY291bGQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCZndDsmZ3Q7IGhh dmUgYSBwcm9wb3NlZCBzdGFuZGFyZCB3aGljaCB1cGRhdGVzIHNlY3Rpb248YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCA2LjIuNiB0bzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg Y2hhbmdlIHRoZSAmcXVvdDtNQVk8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCZndDsmZ3Q7IHVuaWNhc3QmcXVvdDsgdG8gYSAmcXVvdDtTSE9VTEQgdW5pY2FzdCZxdW90Oy48 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCZndDs8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCZndDsgWWVhaCwgSSBhY3R1YWxseSBoYXZlIGhhZCB0aGUg ZGlmZmVyZW50IHRleHQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCBhaW1lZCBmb3IgNm1hbiwgYnV0 PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAmZ3Q7IExvcmVuem8mIzM5O3Mg Y29uY2VybiB3YXMgNm1hbiB3b3VsZCBzYXkgJnF1b3Q7dGhlcmUgaXMgbm88YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCBwcm90b2NvbDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg dXBkYXRlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAmZ3Q7IGhlcmUsIGdv IGF3YXkmcXVvdDssIHNvIGhlIHJld3JvdGUgaXQgZm9yIHY2b3BzLjxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgJmd0Ozxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgJmd0OyBXZSBzaG91bGQgcHJvYmFibHkgZGlzY3VzcyB0aGlzIGF0IHRoZSBtaWMgYW5k PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgZ2V0IHRoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgb3BpbmlvbiBvZiB0aGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCZndDsgNm1hbiBjaGFpcnMgLSBpZiB0aGVyZSBpcyBubyBvdXRyaWdodCAmcXVvdDtu byZxdW90OyBvbiB0aGlzLCBhPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBu b3JtYXRpdmUgZG9jPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAmZ3Q7IHdv dWxkIGJlIGEgYmV0dGVyIHdheSB0byBjb252aW5jZSB0aGUgaW1wbGVtZW50ZXJzID88YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCZndDs8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCZndDsmZ3Q7PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAmZ3Q7Jmd0OyBGV0lXIHRoZSBkcmFmdCBpbmNvcnJlY3RseSByZWZlcnMgdG8gc2VjdGlv bjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIDYuMi40IGluc3RlYWQ8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoG9mIDYuMi42Ljxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgJmd0Ozxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgJmd0OyBO aWNlIGNhdGNoLCB0aGFua3MhPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAm Z3Q7PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAmZ3Q7IC0tYTxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgJmd0Ozxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgJmd0OyZndDs8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCZndDsmZ3Q7IFRoYW5rcyw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCZndDsmZ3Q7wqAgwqAgRXJpazxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg Jmd0OyZndDs8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCZndDsmZ3Q7Jmd0 Ozxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgJmd0OyZndDsmZ3Q7PGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCZndDsmZ3Q7Jmd0OyB2Nm9wcyBtYWlsaW5nIGxpc3Q8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86 djZvcHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52Nm9wc0BpZXRmLm9yZzwvYT4gJmx0O21h aWx0bzo8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52Nm9w c0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPjwvZGl2PjwvZGl2Pg0KwqAgwqAgwqAgwqAgwqAgwqAgJmx0 O21haWx0bzo8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52 Nm9wc0BpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj52Nm9wc0BpZXRmLm9yZzwvYT4mZ3Q7Jmd0OzxzcGFuIGNsYXNz PSIiPjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgJmd0OyZndDsmZ3Q7IDxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMiIHJlbD0i bm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdjZvcHM8L2E+PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAm Z3Q7Jmd0Ozxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgJmd0OyZndDsgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCZndDsmZ3Q7IHY2b3BzIG1haWxpbmcgbGlzdDxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgJmd0OyZndDsgPGEgaHJlZj0ibWFpbHRv OnY2b3BzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+djZvcHNAaWV0Zi5vcmc8L2E+ICZsdDtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+djZv cHNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj48L3NwYW4+DQrCoCDCoCDCoCDCoCDCoCDCoCAmbHQ7bWFp bHRvOjxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnY2b3Bz QGlldGYub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPnY2b3BzQGlldGYub3JnPC9hPiZndDsmZ3Q7PHNwYW4gY2xhc3M9IiI+ PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAmZ3Q7Jmd0OyA8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzIiByZWw9Im5vcmVmZXJy ZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3Y2b3BzPC9hPjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgJmd0OyZndDs8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCZndDs8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCZn dDsgdjZvcHMgbWFpbGluZyBsaXN0PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAmZ3Q7IDxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnY2 b3BzQGlldGYub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPnY2b3BzQGlldGYub3JnPC9hPiZndDs8YnI+PC9zcGFuPg0KwqAg wqAgwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj52Nm9wc0BpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJt YWlsdG86djZvcHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52Nm9wc0BpZXRmLm9yZzwvYT4m Z3Q7Jmd0OzxzcGFuIGNsYXNzPSIiPjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2 b3BzIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzPC9hPjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHY2b3BzIG1haWxpbmcg bGlzdDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIDxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPnY2b3BzQGlldGYub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9 Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnY2b3BzQGlldGYub3JnPC9h PiZndDs8YnI+PC9zcGFuPg0KwqAgwqAgwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJt YWlsdG86djZvcHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52Nm9wc0BpZXRmLm9yZzwvYT4g Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij52Nm9wc0BpZXRmLm9yZzwvYT4mZ3Q7Jmd0OzxzcGFuIGNsYXNzPSIiPjxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v djZvcHMiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHM8L2E+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgdjZvcHMg bWFpbGluZyBsaXN0PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgPGEgaHJlZj0ibWFpbHRvOnY2b3Bz QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+djZvcHNAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86 PGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+djZvcHNAaWV0 Zi5vcmc8L2E+Jmd0Ozxicj48L3NwYW4+DQrCoCDCoCDCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxh IGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnY2b3BzQGlldGYu b3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPnY2b3BzQGlldGYub3JnPC9hPiZndDsmZ3Q7PHNwYW4gY2xhc3M9IiI+PGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby92Nm9wcyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wczwvYT48YnI+DQo8YnI+DQo8YnI+DQo8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqB2Nm9wcyBtYWlsaW5nIGxp c3Q8YnI+PC9zcGFuPg0KwqAgwqAgwqAgwqAgPGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+djZvcHNAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0i bWFpbHRvOnY2b3BzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+djZvcHNAaWV0Zi5vcmc8L2E+ Jmd0OyAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPnY2b3BzQGlldGYub3JnPC9hPjxzcGFuIGNsYXNzPSIiPjxicj4NCsKgIMKgIMKgIMKg ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+djZvcHNAaWV0Zi5vcmc8L2E+Jmd0OyZndDs8YnI+DQrCoCDCoCDCoCDCoCA8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzIiByZWw9Im5vcmVmZXJy ZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3Y2b3BzPC9hPjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KwqAgwqAgwqAg wqAgdjZvcHMgbWFpbGluZyBsaXN0PGJyPg0KwqAgwqAgwqAgwqAgPGEgaHJlZj0ibWFpbHRvOnY2 b3BzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+djZvcHNAaWV0Zi5vcmc8L2E+ICZsdDttYWls dG86PGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+djZvcHNA aWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCsKgIMKgIMKgIMKgIDxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHM8L2E+PGJy Pg0KPGJyPg0KPGJyPg0KwqAgwqAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQrCoCDCoCB2Nm9wcyBtYWlsaW5nIGxpc3Q8YnI+DQrCoCDCoCA8YSBo cmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52Nm9wc0BpZXRmLm9y ZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj52Nm9wc0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KwqAgwqAgPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcyIgcmVsPSJub3JlZmVycmVyIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9w czwvYT48YnI+DQo8YnI+DQo8YnI+DQo8L3NwYW4+PC9ibG9ja3F1b3RlPg0KPGJyPg0KPC9ibG9j a3F1b3RlPjwvZGl2Pjxicj48L2Rpdj4NCg== --94eb2c0802a066f5fd051b75b539-- From nobody Wed Jul 22 05:18:24 2015 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 387CE1B308A for ; Wed, 22 Jul 2015 05:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmxQckqbUn6x for ; Wed, 22 Jul 2015 05:18:21 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450: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 5151B1B2FFC for ; Wed, 22 Jul 2015 05:18:21 -0700 (PDT) Received: by wibud3 with SMTP id ud3so169538798wib.0 for ; Wed, 22 Jul 2015 05:18:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=V8FFuKBpNaisQeCN0cYWm/qQGbVn53FvFSYijv48glo=; b=nbJADMu+DWLCOp5u14n2Bqyfzs2LDzKFZcHACYLzxpK/4VztucpNMBp492yTkURweX 0SzBb+J8hX0EdwYTvBvBenoETUwwb8ZbIBA5Jc7BLLeWqdJI13VP9lYJkK4baLOepE64 SQ6DcU0V+6DOBA9lX2O69Ueb/Th0VkUeY+NojnuVidN0hcEPk2NFyUKc0LhT+1xu+S5G 4giv6weMGUN9jE16H4u8MWqmiuTD2SpqJ9SPiZx4Z1rzHDjyqcKlUvg8kty76z29YAjx xIN4lAuf/smybHNQkKHKq7pPDw34+ddRn+g6ctgZQIgJSEFj2cJNyHiU6FVPmWzCkj9K 3tkA== X-Received: by 10.181.13.195 with SMTP id fa3mr5976285wid.7.1437567500068; Wed, 22 Jul 2015 05:18:20 -0700 (PDT) Received: from ?IPv6:2001:67c:1231:998:9900:5b6f:6e05:7e42? ([2001:67c:1231:998:9900:5b6f:6e05:7e42]) by smtp.gmail.com with ESMTPSA id bq7sm2126658wjc.31.2015.07.22.05.18.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Jul 2015 05:18:18 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Andrew Yourtchenko X-Mailer: iPhone Mail (12H143) In-Reply-To: <55AF874F.5000807@gmail.com> Date: Wed, 22 Jul 2015 14:18:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <069FB97F-6828-4CD6-8AC0-55AC564B668A@gmail.com> References: <55AE44AA.7070304@gmail.com> <55AF874F.5000807@gmail.com> To: Alexandru Petrescu Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] unicast RA to save battery: link-layer joining multicast groups 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, 22 Jul 2015 12:18:23 -0000 You proposed dropping all multicast RAs when device is I standby. I commente= d that the devices are already doing it and it is exactly a problem that we a= re trying to solve with the draft, thus the suggestion is unhelpful.=20 Makes sense ? --a Sent from my iPhone > On 22 Jul 2015, at 14:06, Alexandru Petrescu wrote: >=20 > Thanks for the pointer, but that's a long discussion, it's hard to draw qu= ickly a conclusion on it. >=20 > I would think to argue that if Android has a problem in this then it's an A= ndroid problem. >=20 > If it's a particular driver problem (dependent on the card of that samsung= phone) then fix that problem. >=20 > Maybe it's not so. >=20 > But I am sure the linux devices I use dont consume more power when receivi= ng more RAs, on wifi. >=20 > And even if they did, I have enough batteries and enough other sources of e= nergy to provide them in order to be able to make handovers fast enough to n= ot loose 1 single packet. >=20 > Not sure whether the goal here is to save energy? >=20 > Alex >=20 > Le 22/07/2015 10:34, Andrew =F0=9F=91=BD Yourtchenko a =C3=A9crit : >> This is what some phones do today and is exactly the problem we are >> trying to solve. >>=20 >> https://code.google.com/p/android/issues/detail?id=3D32662 >>=20 >> --a >>=20 >>> On 7/21/15, Alexandru Petrescu wrote: >>> On another hand, >>>=20 >>> IEEE 802.11bgn multicast groups (33::1 etc) are 'joined' at MAC layer by= >>> setting filters. (maybe even by MAC messaging for joining MAC multicast= >>> groups). >>>=20 >>> Maybe we can request the Hosts to set local filters to not receive >>> multicast RAs. Or request the Hosts short on energy to express interest= >>> in these IPv6 multicast groups. >>>=20 >>> Alex >>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Wed Jul 22 05:26:57 2015 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 5F61C1B30FE for ; Wed, 22 Jul 2015 05:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQAWcDGxadkV for ; Wed, 22 Jul 2015 05:26:52 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F5C51B3198 for ; Wed, 22 Jul 2015 05:26:49 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6MCQkCa008779; Wed, 22 Jul 2015 14:26:46 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 38A622028C4; Wed, 22 Jul 2015 14:30:22 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 2A0AA202868; Wed, 22 Jul 2015 14:30:22 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.215]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6MCQjjR012325; Wed, 22 Jul 2015 14:26:46 +0200 To: Lorenzo Colitti References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> <55AD3B64.5070400@acm.org> <55AF0964.1060006@gmail.com> <55AF878E.1090200@gmail.com> <55AF889F.6080206@gmail.com> From: Alexandru Petrescu Message-ID: <55AF8C05.8060603@gmail.com> Date: Wed, 22 Jul 2015 14:26:45 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.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] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 22 Jul 2015 12:26:55 -0000 Hmm, it's different hardware, different drivers, different brand names. They have different energy consumption, I measured that. For the laws of physics: I am interested in asking, and give opinion, about how much energy it takes to send or receive one 1280 MTU IPv6 packet. I looked at the presentation in 6man titled "Preliminary RA power observations on wifi". There was a RG called EERG which died recently and seemed to discuss this as well. But we dont have an agreement about how much energy packets take, and whether or not it's worth trying to make protocols more or less energy-aware. Alex Le 22/07/2015 14:13, Lorenzo Colitti a écrit : > I'm sure that the huawei E392 obeys the laws of physics as well. > > On Wed, Jul 22, 2015 at 2:12 PM, Alexandru Petrescu > > wrote: > > "... on Androids and iPhones"? > > But not on huawei E392. > > Alex > > > Le 22/07/2015 14:10, Lorenzo Colitti a écrit : > > I'm told the problem affects iPhones as well. > > On Wed, Jul 22, 2015 at 2:07 PM, Alexandru Petrescu > > >> wrote: > > "Reducing battery impact of RAs on Androids"? > > Alex > > Le 22/07/2015 12:22, Lorenzo Colitti a écrit : > > Thanks for all the feedback. We have posted a -01 > addressing > some of the > feedback we got. The new version also contains a new > recommendation not > to send periodic RAs too frequently, so we have changed > the title to > "Reducing battery impact of Router Advertisements". > > https://tools.ietf.org/html/draft-yc-v6ops-solicited-ra-unicast-01 > > If there are no objections, we will upload this as a WG > document > in the > next few days. > > On Wed, Jul 22, 2015 at 5:09 AM, Alejandro Acosta > > > > > >>> > wrote: > > Hi There, > I also support this document, it's very > positive to see > that this > algorithm will save energy. > > Regards, > > Alejandro, > > El 7/21/2015 a las 6:11 PM, Nabil Benamar escribió: > > Hi Folks, > > I support this document which is very informative, > useful and its > implementation will certainly reduce energy > consumption > due to > excessive Multicast RA sent. The proposed > algorithm > seems to be > suitable for this end ! > > > Best regards > > > > On Tue, Jul 21, 2015 at 4:38 PM, Owen DeLong > > > > >>> wrote: > > It seems to me that the following > algorithm would be > relatively easy to implement > and provide reasonable network optimization… > > > On receipt of an RS: > > if(multicast_ra_time_remaining > > 15 seconds) > { > Send_Unicast_ra > } > else > { > Send_Multicast_ra > reset_multicast_timer > } > > In this way, if the timing is reasonably > close, you > multicast > a packet you were about to send > anyway, but if the timing isn’t close, > you’re not > wasting > multicast bandwidth answering a single > node where nobody else cares. > > Overall, I’ve always thought that multicast > response to RS was > kind of silly. It’s probably most > harmful on WiFi. > > Owen > > > On Jul 21, 2015, at 02:33 , Andrew 👽 > Yourtchenko > > > >>> wrote: > > > > On 7/20/15, Erik Nordmark > < > >>nordmark@acm.org > > > > > > >>> wrote: > >> On 7/17/15 9:34 AM, Fred Baker (fred) > wrote: > >>>> So the next logical thing to do would > be to > have the > router default to > >>>> unicast Router Advertisements, > measure the rate of > received Router > >>>> Solicitations, and switch to > multicast RA mode > past a certain > >>>> threshold to cover this sort of > situation. > Once the > number of RSes > >>>> falls, it switches back to unicast RA > mode. > >>>> > >>>> That would get rid of the > configuration knob > proposed in > this ID, and > >>>> is behaviour that I think could be > universal > for all link > types, > >>>> rather than just for the case of > wireless ones > with > mobile devices. > >>> If it were me implementing it, I think > I would > go about > this in a little > >>> different way, hopefully simpler. I > would want > to send at > most one (e.g., > >>> either zero or one) RA per some > interval (a > second?). In > the normal case, > >>> that is sent unicast. However, having > sent a > unicast RA at > time t, if I > >>> now receive another RS before t+1, I > send the > next one (at > time t+1) as a > >>> multicast. > >> > >> First of all I support this document as > a WG > document. > >> > >> But in terms of implementation, isn't > it simpler to > always(*) respond to > >> a RS with a unicast RA? > > > > Yes. I did not respond on-list yet - but > from > operational > perspective > > "always send solRA unicast" / "always > send solRA > multicast" > definitely > > wins in my book, and I'd avoid premature > optimizations (but > maybe we > > can say the implementers are explicitly > free to > do their own > > optimizations if they see fit) > > > > That said, will be very interesting to > hear data > from folks > who will > > run "all-unicast solRA", in real > networks and > then compare > the effect > > of their proposal optimizations on their > real-world scenarios. > > > >> As background, the text in RFC4861 > comes from > the old > concern that all > >> devices might boot at the same time > when the > power is > re-established > >> after a building power failure; that > doesn't > happen since > most devices > >> (laptops, smartphones, IoT devices) have > batteries today. > In that case > >> it might have made sense to sending > fewer RA > messages by > using multicast. > >> > >> (*) the only case in RFC 4861 when I > think a > multicast > response might be > >> considered is when the source IPv6 > address in > the RS is the > unspecified > >> address. Further, an implementation > which rate > limits > received RS > >> packets (e.g., CoPP in a router) might > also want > to detect > when the rate > >> limit might have dropped RS packets and > multicast an RA in > that case. > >> > >> > >> I do wonder why implementations haven't > already > changed to > send unicast > >> solicited RA, and whether it would make a > difference if we > have an > > > > TBH that's my concern as well. I think > we should > tweak the > text in > > 4861 to encourage a bit more > consideration on the > implementer's side. > > > >> informational document asking them to > do this. > Alternatively we could > >> have a proposed standard which updates > section > 6.2.6 to > change the "MAY > >> unicast" to a "SHOULD unicast". > > > > Yeah, I actually have had the different text > aimed for 6man, but > > Lorenzo's concern was 6man would say > "there is no > protocol > update > > here, go away", so he rewrote it for v6ops. > > > > We should probably discuss this at the > mic and > get the > opinion of the > > 6man chairs - if there is no outright > "no" on this, a > normative doc > > would be a better way to convince the > implementers ? > > > >> > >> FWIW the draft incorrectly refers to > section > 6.2.4 instead > of 6.2.6. > > > > Nice catch, thanks! > > > > --a > > > >> > >> Thanks, > >> Erik > >> > >>> > >>> > >>> > _______________________________________________ > >>> 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 > > > _______________________________________________ > 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 > > > > > _______________________________________________ > 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 Jul 22 05:27:29 2015 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 6D2EC1B31C9 for ; Wed, 22 Jul 2015 05:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 wlFPHsOVwF-Q for ; Wed, 22 Jul 2015 05:27:25 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 071091B30FE for ; Wed, 22 Jul 2015 05:27:25 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id C2CFB61E1; Wed, 22 Jul 2015 05:27:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=1Bk6yzElTYhBwSyaNDeTjgbSpGM=; b= m/QaA7kDlejgBi9qn9aeSrO/lvHxWGpXzxEqpjwkmEyfKcERYqnQKqj+zzvAUYWu 7T0rbsHvcQ5Ef43XQsf36ZD6l56LvyWAAAIMKCTudegyctIbbfXSne5PX6YnASyv dsDr5c8F9yYKhJSXRz57QAZDCvh3PYgh/0tobS2Cb1M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=l/8+nv8MKOs4NJrnExKWNrHfmc 2H6v6ExfNFULX3BIJWJE/B3s4LCxv4Q2OSxOkSlhLFZXA7J5vJTqVkeCKz0cAyTX 2bIkXJ5yRA84uXbk1e60PtSU5vL65iVZBDKxntv/ECU5sCzI01qaY96TA7ZYajVo l572YeL8mCentCfns= Received: from gomlefisk.localdomain (dhcp-aa75.meeting.ietf.org [31.133.170.117]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 9398A61D0; Wed, 22 Jul 2015 05:27:23 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by gomlefisk.localdomain (Postfix) with ESMTP id 3D8EA497E29E; Wed, 22 Jul 2015 14:27:43 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Content-Type: multipart/signed; boundary="Apple-Mail=_BD0CC326-745E-479C-9CC0-1CC977358D72"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5 From: Ole Troan In-Reply-To: <55AE42A4.8020908@gmail.com> Date: Wed, 22 Jul 2015 14:27:42 +0200 Message-Id: <5CD05758-D7B7-476D-9936-E5A1D0614AF8@employees.org> References: <55AE42A4.8020908@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ref Hosts dont MLD to join LL groups 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, 22 Jul 2015 12:27:26 -0000 --Apple-Mail=_BD0CC326-745E-479C-9CC0-1CC977358D72 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Regarding the mic discussion about unicast RAs a SHOULD. >=20 > I have been directed that the reference saying that Hosts dont MLD to = join multicast groups is RFC3810: >=20 > " The link-scope all-nodes multicast address, (FF02::1), is handled = as > a special case. On all nodes -- that is all hosts and routers, > including multicast routers -- listening to packets destined to the > all-nodes multicast address, from all sources, is permanently = enabled > on all interfaces on which multicast listening is supported. No MLD > messages are ever sent regarding neither the link-scope all-nodes > multicast address, nor any multicast address of scope 0 (reserved) = or > 1 (node-local).=E2=80=9D I do wonder if we should expand that exception to all link-scope = multicast addresses. the bridge implementors I speak to tell me that they don=E2=80=99t have = enough state to do MLD snooping for link-local scoped multicast = addresses anyway... cheers, Ole --Apple-Mail=_BD0CC326-745E-479C-9CC0-1CC977358D72 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 - https://gpgtools.org iQIcBAEBCgAGBQJVr4w+AAoJEL7aWKiYQt92ZRsP/RKfJrjT3q3BeDbQtzTdwlyW bOjGLtt8/8/+YwgEnK9HyVqsUgv5oN70foIJ5bGdmcv5HmMiVxHNruE/PdgvFT3F LQz/qBMJG4ctkAHncQ8craLnujX81EOwAuxOnOLP1PdvI5e84ceanR1hGiCGgIOo sbWNWjlbyvWhNkyw4Wiza4nLrttvgT84EUyZKWwGqQQm5C70g+bQpcH9cDnpRT7l BYGFDOxSKBgKXDxBhMKI6yDSMjR5Cz9pOWgHlaR3f1Ycu2/KPgZ8uT5Npop47jxk lNFGo7grc2WIxqbzZgC9eqtd5bPz8oUflg0oQV2Fl9CuTAd0gNKg1oKDq1tzukvv nklbIfuwSZZath4YaMhPSbeMAbNKD9SOJpAYJEL6vZxeJrOYKWnJURXCEC3QQ8Jp tus1mcumez5frgM0UWsQve/f9chPvL0Qi41tOnQ8PTd0YfUmOTeEvYWrsSIJ5xi/ vOJO6Er+CJFA6bn7CCyiY4TnsA5k5zyD5WKDpUEnZ/6mhalatej4QbcY6vI8hqdw SvjLXYeW7LbnK9nbmN5yVKherkY7hOCMt6leZXizLOHXH1c5CjNe9SLy1uBPByMC jd+YEe6C38Xg5GVZvzYYPh1FyLTefl5L++tTE1+JK0hboUNvW/BjT8OxGBJvc9iE g9lYIZCeC9LRtAHzuFQC =Slft -----END PGP SIGNATURE----- --Apple-Mail=_BD0CC326-745E-479C-9CC0-1CC977358D72-- From nobody Wed Jul 22 05:32:17 2015 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 CFE631B324E for ; Wed, 22 Jul 2015 05:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 O8mZb2rf2_YE for ; Wed, 22 Jul 2015 05:32:05 -0700 (PDT) Received: from mail-vn0-x22f.google.com (mail-vn0-x22f.google.com [IPv6:2607:f8b0:400c:c0f::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 608371B31BF for ; Wed, 22 Jul 2015 05:31:56 -0700 (PDT) Received: by vnav141 with SMTP id v141so47508427vna.0 for ; Wed, 22 Jul 2015 05:31:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=G4ft/2caJEBuOEk0L5Q/z7naulHrn+1TJ/X/oNpNKR8=; b=Mw26OZy7UJobDIQvj4rFizqEc/F1j/1i5o+yizeBLEsADYDvGTeO+Rm/tSwaRs0jtw vRC0a3BdwAkyzicxD6IufGMudQO1iQpujVLH4+nieRc8Jttf4nMEhLA9X/Qg9T/zJoCg xXqZYdfw8PjM//tvhcaQZqmkQlRKrV2Ys1oZ4ZuDJ2e0bE5Tqf0/97AIDmlJov9beyCs 8QHpqXEAnhHI2FtLItv/17ur5UwWAokZbx/OgrEOjQSM71K80mcf/ul/y49e8MgcFMCr Pl/z/o+M73jVZV+2mkM+42b6Jvq6thU4+I4hUA24Oyby3page6PXZs6bXnNupPGTko9t D+Lg== X-Received: by 10.52.139.176 with SMTP id qz16mr2650416vdb.71.1437568315671; Wed, 22 Jul 2015 05:31:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.189.83 with HTTP; Wed, 22 Jul 2015 05:31:36 -0700 (PDT) In-Reply-To: <55AF889F.6080206@gmail.com> References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> <55AD3B64.5070400@acm.org> <55AF0964.1060006@gmail.com> <55AF878E.1090200@gmail.com> <55AF889F.6080206@gmail.com> From: Jen Linkova Date: Wed, 22 Jul 2015 14:31:36 +0200 Message-ID: To: Alexandru Petrescu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 22 Jul 2015 12:32:09 -0000 On Wed, Jul 22, 2015 at 2:12 PM, Alexandru Petrescu wrote: > > "... on Androids and iPhones"? > > But not on huawei E392. I'm not sure what the fact that huawei E392 is not affected by a particular issue proves. So far we know that - there are platforms affected; - there is one unaffected platform. Therefore I believe it is perfectly find for the title to be 'Reducing battery impact of Router Advertisements'. If a particular network and its devices are not affected - good, the network administrators MAY (or SHOULD?) ignore the draft and not apply the recommendations. > Le 22/07/2015 14:10, Lorenzo Colitti a =C3=A9crit : >> >> I'm told the problem affects iPhones as well. >> >> On Wed, Jul 22, 2015 at 2:07 PM, Alexandru Petrescu >> > wro= te: >> >> "Reducing battery impact of RAs on Androids"? >> >> Alex >> >> Le 22/07/2015 12:22, Lorenzo Colitti a =C3=A9crit : >> >> Thanks for all the feedback. We have posted a -01 addressing >> some of the >> feedback we got. The new version also contains a new >> recommendation not >> to send periodic RAs too frequently, so we have changed the titl= e to >> "Reducing battery impact of Router Advertisements". >> >> https://tools.ietf.org/html/draft-yc-v6ops-solicited-ra-unicast-= 01 >> >> If there are no objections, we will upload this as a WG document >> in the >> next few days. >> >> On Wed, Jul 22, 2015 at 5:09 AM, Alejandro Acosta >> > >> > >> >> wrote: >> >> Hi There, >> I also support this document, it's very positive to see >> that this >> algorithm will save energy. >> >> Regards, >> >> Alejandro, >> >> El 7/21/2015 a las 6:11 PM, Nabil Benamar escribi=C3=B3: >> >> Hi Folks, >> >> I support this document which is very informative, >> useful and its >> implementation will certainly reduce energy consumption >> due to >> excessive Multicast RA sent. The proposed algorithm >> seems to be >> suitable for this end ! >> >> >> Best regards >> >> >> >> On Tue, Jul 21, 2015 at 4:38 PM, Owen DeLong >> >> >> wrot= e: >> >> It seems to me that the following algorithm would b= e >> relatively easy to implement >> and provide reasonable network optimization=E2=80= =A6 >> >> >> On receipt of an RS: >> >> if(multicast_ra_time_remaining > 15 seconds= ) >> { >> Send_Unicast_ra >> } >> else >> { >> Send_Multicast_ra >> reset_multicast_timer >> } >> >> In this way, if the timing is reasonably close, you >> multicast >> a packet you were about to send >> anyway, but if the timing isn=E2=80=99t close, you= =E2=80=99re not >> wasting >> multicast bandwidth answering a single >> node where nobody else cares. >> >> Overall, I=E2=80=99ve always thought that multicast >> response to RS was >> kind of silly. It=E2=80=99s probably most >> harmful on WiFi. >> >> Owen >> >> > On Jul 21, 2015, at 02:33 , Andrew Yourtchenko >> >> >> wro= te: >> > >> > On 7/20/15, Erik Nordmark >> <> >nordmark@acm.org >> >> >> > >> wrote: >> >> On 7/17/15 9:34 AM, Fred Baker (fred) wrote: >> >>>> So the next logical thing to do would be to >> have the >> router default to >> >>>> unicast Router Advertisements, measure the rat= e of >> received Router >> >>>> Solicitations, and switch to multicast RA mode >> past a certain >> >>>> threshold to cover this sort of situation. >> Once the >> number of RSes >> >>>> falls, it switches back to unicast RA mode. >> >>>> >> >>>> That would get rid of the configuration knob >> proposed in >> this ID, and >> >>>> is behaviour that I think could be universal >> for all link >> types, >> >>>> rather than just for the case of wireless ones >> with >> mobile devices. >> >>> If it were me implementing it, I think I would >> go about >> this in a little >> >>> different way, hopefully simpler. I would want >> to send at >> most one (e.g., >> >>> either zero or one) RA per some interval (a >> second?). In >> the normal case, >> >>> that is sent unicast. However, having sent a >> unicast RA at >> time t, if I >> >>> now receive another RS before t+1, I send the >> next one (at >> time t+1) as a >> >>> multicast. >> >> >> >> First of all I support this document as a WG >> document. >> >> >> >> But in terms of implementation, isn't it simpler= to >> always(*) respond to >> >> a RS with a unicast RA? >> > >> > Yes. I did not respond on-list yet - but from >> operational >> perspective >> > "always send solRA unicast" / "always send solRA >> multicast" >> definitely >> > wins in my book, and I'd avoid premature >> optimizations (but >> maybe we >> > can say the implementers are explicitly free to >> do their own >> > optimizations if they see fit) >> > >> > That said, will be very interesting to hear data >> from folks >> who will >> > run "all-unicast solRA", in real networks and >> then compare >> the effect >> > of their proposal optimizations on their >> real-world scenarios. >> > >> >> As background, the text in RFC4861 comes from >> the old >> concern that all >> >> devices might boot at the same time when the >> power is >> re-established >> >> after a building power failure; that doesn't >> happen since >> most devices >> >> (laptops, smartphones, IoT devices) have >> batteries today. >> In that case >> >> it might have made sense to sending fewer RA >> messages by >> using multicast. >> >> >> >> (*) the only case in RFC 4861 when I think a >> multicast >> response might be >> >> considered is when the source IPv6 address in >> the RS is the >> unspecified >> >> address. Further, an implementation which rate >> limits >> received RS >> >> packets (e.g., CoPP in a router) might also want >> to detect >> when the rate >> >> limit might have dropped RS packets and >> multicast an RA in >> that case. >> >> >> >> >> >> I do wonder why implementations haven't already >> changed to >> send unicast >> >> solicited RA, and whether it would make a >> difference if we >> have an >> > >> > TBH that's my concern as well. I think we should >> tweak the >> text in >> > 4861 to encourage a bit more consideration on the >> implementer's side. >> > >> >> informational document asking them to do this. >> Alternatively we could >> >> have a proposed standard which updates section >> 6.2.6 to >> change the "MAY >> >> unicast" to a "SHOULD unicast". >> > >> > Yeah, I actually have had the different text >> aimed for 6man, but >> > Lorenzo's concern was 6man would say "there is no >> protocol >> update >> > here, go away", so he rewrote it for v6ops. >> > >> > We should probably discuss this at the mic and >> get the >> opinion of the >> > 6man chairs - if there is no outright "no" on thi= s, a >> normative doc >> > would be a better way to convince the implementer= s ? >> > >> >> >> >> FWIW the draft incorrectly refers to section >> 6.2.4 instead >> of 6.2.6. >> > >> > Nice catch, thanks! >> > >> > --a >> > >> >> >> >> Thanks, >> >> Erik >> >> >> >>> >> >>> >> >>> _______________________________________________ >> >>> 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 >> >> _______________________________________________ >> 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 >> >> >> >> >> _______________________________________________ >> 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 --=20 SY, Jen Linkova aka Furry From nobody Wed Jul 22 05:37:01 2015 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 162351B32D0 for ; Wed, 22 Jul 2015 05:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QThyYSlwLFMd for ; Wed, 22 Jul 2015 05:36:55 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::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 278031B32CC for ; Wed, 22 Jul 2015 05:36:55 -0700 (PDT) Received: by wibud3 with SMTP id ud3so170313890wib.0 for ; Wed, 22 Jul 2015 05:36:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=F7M3OYkY4EnIAbxED/wRsTvyhOMP533UnVhnHXiRML4=; b=vz5JunMokMEGppplJU3W3VAywQt55IMyapot6zk+iUWJ3aSeFAUih5PSsns4u8Mw8T gNEhI1qM+3+aYWOygZtXyJoHJlQokNqR/cQt413ICKrNFcEBoPrkBwG6IwN8FPZqyCvD MkpOQ4RgSWc0n5jD7VWfHNWgQDjcDE9jYG8SzmK3TSsTxEdkRDXI/J6qS/oH0+lini5k euW5Bucy16PNr3R07LaW9txDn3MauR58VlJURUr9xgpSuuHzE+5hm09yk3HlmwrAY1jz /AhjeXDPlv11IlPWxXHyjbbZ0aBJYk8auS4yIc8H6PfjA6ofk3rqwrLpazUbjoqWTsKy 2fEQ== X-Received: by 10.180.82.230 with SMTP id l6mr39880569wiy.61.1437568613864; Wed, 22 Jul 2015 05:36:53 -0700 (PDT) Received: from ?IPv6:2001:67c:1231:998:9900:5b6f:6e05:7e42? ([2001:67c:1231:998:9900:5b6f:6e05:7e42]) by smtp.gmail.com with ESMTPSA id x6sm21881240wiy.6.2015.07.22.05.36.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Jul 2015 05:36:52 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: =?utf-8?Q?Andrew_=F0=9F=91=BD_Yourtchenko?= X-Mailer: iPhone Mail (12H143) In-Reply-To: <55AF85F5.7070407@gmail.com> Date: Wed, 22 Jul 2015 14:36:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8EC4AA93-24C6-48F1-B3F1-B8F55B7FDD7D@gmail.com> References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> <331D6E02-167D-4E7F-9682-F63C6674BD24@gmail.com> <55AE5270.8000301@gmail.com> <55AF85F5.7070407@gmail.com> To: Alexandru Petrescu Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 22 Jul 2015 12:36:57 -0000 > On 22 Jul 2015, at 14:00, Alexandru Petrescu wrote: >=20 >=20 >=20 > Le 22/07/2015 09:20, Andrew =F0=9F=91=BD Yourtchenko a =C3=A9crit : >>> On 21 Jul 2015, at 16:08, Alexandru Petrescu wrote: >>>=20 >>>=20 >>>=20 >>> Le 17/07/2015 18:57, Andrew Yourtchenko a =C3=A9crit : >>>>=20 >>>> On 17 Jul 2015, at 09:34, Fred Baker (fred) wrote: >>>>=20 >>>>>>=20 >>>>>> So the next logical thing to do would be to have the router default t= o >>>>>> unicast Router Advertisements, measure the rate of received Router >>>>>> Solicitations, and switch to multicast RA mode past a certain >>>>>> threshold to cover this sort of situation. Once the number of RSes >>>>>> falls, it switches back to unicast RA mode. >>>>>>=20 >>>>>> That would get rid of the configuration knob proposed in this ID, and= >>>>>> is behaviour that I think could be universal for all link types, >>>>>> rather than just for the case of wireless ones with mobile devices. >>>>>=20 >>>>> If it were me implementing it, I think I would go about this in a litt= le different way, hopefully simpler. I would want to send at most one (e.g.,= either zero or one) RA per some interval (a second?). In the normal case, t= hat is sent unicast. However, having sent a unicast RA at time t, if I now r= eceive another RS before t+1, I send the next one (at time t+1) as a multica= st. >>>>=20 >>>> values of T less than 3 seconds would make performance worse than today= . >>>>=20 >>>> There are many things to optimize for: >>>>=20 >>>> - wireless airtime >>>> - bandwidth used by RAs >>>> - CPU usage sending unicast RAs by router >>>> - energy consumption on devices for more than one medium >>>=20 >>> and: >>>=20 >>> - fast handovers: on some links the more frequent the multicast RAs the >>> faster the handovers are, i.e. less packet loss for end nodes, less >>> glitches in the video conference stream. >>=20 >> If the network sends the periodic RAs frequently enough to avoid the >> glitches of the video stream, this is explicitly *NOT* the network we >> are concerned about in this draft. >=20 > But mentioning 'mobile' for the nodes, makes think so. Because fast addre= ss auto-configuration is a characteristic of mobile nodes. One wants to spe= nd as little time as possible waiting for RAs. For that reason the multicas= t RAs period was reduced to milliseconds. Yes. We made changes in the newly submitted -01 to make it clearer which net= works it will apply to, hopefully it clarifies the scope enough. --a >=20 >> Also, we wanted to be very focused what we talk about in this >> document, to be able to ship it quicker. >=20 > I agree. >=20 >> We can say "does not apply to 802.11p, applies to 802.11(a|b|g|n|ac). >> Applicability to other networks is left at readers' discretion". >=20 > I agree. It should also say it does not apply to LTE. BEcause in LTE an R= A is sent on only one ptp link, there is no risk of waking up somebody >=20 >> Or something along these lines of that - feel free to propose the text >> if the above is not what you had in mind. >=20 > On a scale MUST NOT, MAY, SHOULD - SHOULD is the right term. >=20 > "SHOULD [...] unless the network is of type LTE or 802.11p". >=20 > Or: >=20 > "SHOULD [...] unless there is an interest in as numerous RAs as possible t= o help in fast address auto-configuration to large number of mobiles". >=20 > or >=20 > "SHOULD [...] unless the Hosts are allowed to explicitely express interest= in the multicast group dst of RA". >=20 > or >=20 > "SHOULD [...] unless RFC-MLD is updated to require Hosts to express intere= st in the multicast group dst of RA". >=20 > Alex >=20 >>=20 >> --a >>=20 >>> Alex >>>=20 >>>>=20 >>>> Some of them are orthogonal, some of them contradict each other, some o= f them align. People may want to optimize differently. >>>>=20 >>>> I'd opt for simplicity - and use the text Erik Kline posted in another e= mail. >>>>=20 >>>> This would allow the developers to adapt for individual use cases on th= e spot. >>>>=20 >>>> --a >>>>=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 >>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Wed Jul 22 05:42:04 2015 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 9030D1B32BE for ; Wed, 22 Jul 2015 05:42:02 -0700 (PDT) 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 cHmXaxWxV7jZ for ; Wed, 22 Jul 2015 05:42:01 -0700 (PDT) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::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 789001A89A0 for ; Wed, 22 Jul 2015 05:42:01 -0700 (PDT) Received: by ykax123 with SMTP id x123so191682166yka.1 for ; Wed, 22 Jul 2015 05:42:00 -0700 (PDT) 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=aNDRkbDXac1/GrtgXo148iWQIWCGmuEBJ8R4CMBQzyo=; b=Xz1GFufXn8/byneLWm9YmElgIIe0AyZ1PIQVMw8x9tPuVxkUVogIkeFmWDzV3u/SC4 EftbNU9ALAuEJ3alvMvm7s8aZXf0rbdd8B3uyeyyiuSmHxW0DJMnyOIj9RdmDigwZP/a C/07MyMBzvLbLxnpKL7Lv8kVqVCELG93JslAWp0L8NR8REz1WDmCIb+5sW473vBEceW/ cMAtSYEFsRDRb9Ah1VofeuFzSWU3tUf8Wbkk14Q4qQqngKRgdUSDkvfISE+7xW6UOtDK GWnzJvECH0sCG3OgkCm5VfUeMd0k8qUprYyeRxizReoKWKs0+Lfv0WFbkH+ykQvxwVJ7 HQCA== 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=aNDRkbDXac1/GrtgXo148iWQIWCGmuEBJ8R4CMBQzyo=; b=Uc5nig+vQqrxfUQu42ATQ/ci1cFQ2P+uTTDEHNoI0+L3B6qsJ77nGXX9j2I0AkPNEU hCPFEh6xF2ObJbdWFlcBdnHLkjGG87JzVN/sGJwolRIqQ1N9SIiZO7360aokuKDjfi/+ NwbumVJwvAkMOzBi7y0eEAJW6h4Z7IpB7OnS8KV6m6vISJJISKLzWO/dpB0Q3RqNIOVl A/8cLNDkKcywcZlWoafYj8hrqxVIInUKFBD01SeAWq5l3c7PPy+22yxUdUWX77MQ0s0W vBRZAHaaQv8lqigH5G6Hjt2DRZ6Tn7cWtmcnk1njb7U+63R4ppjKNZBmTWClk8QGJ30Z GkXg== X-Gm-Message-State: ALoCoQn15TAZ5avdYJs6KAwR/mHpRFa9JEYJ2b6JHMhqPbRnZknFNqJS+NwUQjOyzlQ9XtF1iJbz X-Received: by 10.170.91.3 with SMTP id i3mr2176238yka.25.1437568920815; Wed, 22 Jul 2015 05:42:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.8.201 with HTTP; Wed, 22 Jul 2015 05:41:41 -0700 (PDT) In-Reply-To: References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> <55AD3B64.5070400@acm.org> <55AF0964.1060006@gmail.com> <55AF878E.1090200@gmail.com> <55AF889F.6080206@gmail.com> From: Lorenzo Colitti Date: Wed, 22 Jul 2015 14:41:41 +0200 Message-ID: To: Jen Linkova Content-Type: multipart/alternative; boundary=001a113a05e8ddef58051b7618ba Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 22 Jul 2015 12:42:02 -0000 --001a113a05e8ddef58051b7618ba Content-Type: text/plain; charset=UTF-8 On Wed, Jul 22, 2015 at 2:31 PM, Jen Linkova wrote: > I'm not sure what the fact that huawei E392 is not affected by a > particular issue proves. > We don't know if the huawei E392 is affected by this issue until someone with access to that hardware (Alexandru?) can determine which of the three behaviours in section 3 it exhibits. Until we know that, we cannot use that as a basis for discussion. --001a113a05e8ddef58051b7618ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 22, 2015 at 2:31 PM, Jen Linkova <furry13@gmail.com>= wrote:
I'm not sure what the fact that huawei E392= is not affected by a
particular issue proves.

We don't k= now if the=C2=A0huawei E392 is affected by this issue until someone with ac= cess to that hardware (Alexandru?) can determine which of the three behavio= urs in section 3 it exhibits.

Until we know that, = we cannot use that as a basis for discussion.
--001a113a05e8ddef58051b7618ba-- From nobody Wed Jul 22 05:46:19 2015 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 510E01A038D for ; Wed, 22 Jul 2015 05:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.983 X-Spam-Level: X-Spam-Status: No, score=-3.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, 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 eppDonA-UKKJ for ; Wed, 22 Jul 2015 05:46:14 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 224861A21A0 for ; Wed, 22 Jul 2015 05:46:06 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6MCk3Ek017836; Wed, 22 Jul 2015 14:46:03 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2C93C2028CE; Wed, 22 Jul 2015 14:49:39 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 1EDAB202868; Wed, 22 Jul 2015 14:49:39 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.215]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6MCk3jw016139; Wed, 22 Jul 2015 14:46:03 +0200 To: Lorenzo Colitti , Jen Linkova References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> <55AD3B64.5070400@acm.org> <55AF0964.1060006@gmail.com> <55AF878E.1090200@gmail.com> <55AF889F.6080206@gmail.com> From: Alexandru Petrescu Message-ID: <55AF908A.4010906@gmail.com> Date: Wed, 22 Jul 2015 14:46:02 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.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] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 22 Jul 2015 12:46:15 -0000 Le 22/07/2015 14:41, Lorenzo Colitti a ĂŠcrit : > On Wed, Jul 22, 2015 at 2:31 PM, Jen Linkova > wrote: > > I'm not sure what the fact that huawei E392 is not affected by a > particular issue proves. > > > We don't know if the huawei E392 is affected by this issue until someone > with access to that hardware (Alexandru?) can determine which of the > three behaviours in section 3 it exhibits. > > Until we know that, we cannot use that as a basis for discussion. Ok, that could be measured, but it's an LTE USB key. Let me try another USB WiFi dongle (maybe a tp-link). Would this apply? Alex From nobody Wed Jul 22 05:48:58 2015 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 3A2E21A1A38 for ; Wed, 22 Jul 2015 05:48:57 -0700 (PDT) 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 WB3Fujj1K5Kc for ; Wed, 22 Jul 2015 05:48:56 -0700 (PDT) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 503871A039F for ; Wed, 22 Jul 2015 05:48:56 -0700 (PDT) Received: by ykfw194 with SMTP id w194so111169150ykf.0 for ; Wed, 22 Jul 2015 05:48:55 -0700 (PDT) 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=LSM6QxdQvneaJa8TCt9o1u713t+CZmWgJIZcGKSpLDw=; b=iedbon9IXWVuOdt3y1w9PkwJpiE8apetuyZ0h/3Uul0+k/ucBiGs0wXj6oTKCxNrki 21GXbF6GKl/J9M9CESp56CdBjSYpKivSXdHQq2Bghv+XGv/FZXXMTXw6B5qJfAUjeFfa /T1HW7m/QPlex60jDVYbyheF3y0KQUBmxSgjBOtec7JKjno9A4UUzvqW6BNEDtqJL79P VobmriZIqY8Ph7rCytagX6WAHoLDR+FK/Mqps7M6w3Ypu81t5fEdg5MpwQ7pXScVYk0L Pzl+YoqClhre3wMBpXSSJNbY6d02UMoGeR/cRjivMwQIPNPs/Yikjqghq+6sjsmyeiNB /IwQ== 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=LSM6QxdQvneaJa8TCt9o1u713t+CZmWgJIZcGKSpLDw=; b=j5NPVPeAzV4RrgQMcPsojwMqUb0FFcoe7SSqFG91c9N2ZkFExelIOvppPhvgt0zylC F5iaQbPNdymJSwFOA1/EjZblfTpE92CntjVQvroR0dg5fKGt+jfeJOecyMNO814PhXEg HwWe9s/jgLjclk73Rl+sTSQX3j2vbmlb/KcqjcYIJfuX6jmATRTyATT579if2XOYejry LvDaxEu9dN7NKBaPojEVRAgUZVs3z9J2KI7Z27nbmm2ByTkwzmRNo+2oTlIfJ7X+ANvQ TikIHcGfGDtckpOqefFNT0kLMw9pMuoRMD4llrA3Jkpxq/GFYJ8LO5FwVM4z8yBUeIoa uR3g== X-Gm-Message-State: ALoCoQnkA6OhP8evLGlVnPjXD3LQT8dCYIsBUD6SDiit+68YroxoTSBuTaZlXF/2p7s+3B263wCV X-Received: by 10.13.249.198 with SMTP id j189mr2184576ywf.170.1437569335718; Wed, 22 Jul 2015 05:48:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.8.201 with HTTP; Wed, 22 Jul 2015 05:48:35 -0700 (PDT) In-Reply-To: <55AF908A.4010906@gmail.com> References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> <55AD3B64.5070400@acm.org> <55AF0964.1060006@gmail.com> <55AF878E.1090200@gmail.com> <55AF889F.6080206@gmail.com> <55AF908A.4010906@gmail.com> From: Lorenzo Colitti Date: Wed, 22 Jul 2015 14:48:35 +0200 Message-ID: To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=94eb2c080b9698d085051b763155 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 22 Jul 2015 12:48:57 -0000 --94eb2c080b9698d085051b763155 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 22, 2015 at 2:46 PM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Ok, that could be measured, but it's an LTE USB key. > > Let me try another USB WiFi dongle (maybe a tp-link). Would this apply? > Those aren't battery-powered devices. --94eb2c080b9698d085051b763155 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 22, 2015 at 2:46 PM, Alexandru Petrescu <alexandru.petr= escu@gmail.com> wrote:
Ok, = that could be measured, but it's an LTE USB key.

Let me try another USB WiFi dongle (maybe a tp-link).=C2=A0 Would this appl= y?

Those aren't battery-powered dev= ices.=C2=A0
--94eb2c080b9698d085051b763155-- From nobody Wed Jul 22 05:50:59 2015 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 F24771B32EF for ; Wed, 22 Jul 2015 05:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 pMwS4MHq80bB for ; Wed, 22 Jul 2015 05:50:48 -0700 (PDT) Received: from mx1.ernw.net (mx1.ernw.net [62.159.96.78]) (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 503241B32E6 for ; Wed, 22 Jul 2015 05:50:48 -0700 (PDT) Received: from mh1.ernw.net (unknown [172.31.1.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mh1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx1.ernw.net (Postfix) with ESMTPS id E3EB815EC2E for ; Wed, 22 Jul 2015 14:52:59 +0200 (CEST) Received: from ws25.ernw.net (ws25.ernw.net [172.31.100.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "ws25.ernw.net", Issuer "ernw ca1" (verified OK)) by mh1.ernw.net (Postfix) with ESMTPS id 96F6E64A for ; Wed, 22 Jul 2015 14:50:46 +0200 (CEST) Received: by ws25.ernw.net (Postfix, from userid 1001) id 707FDC4876; Wed, 22 Jul 2015 14:50:46 +0200 (CEST) Date: Wed, 22 Jul 2015 14:50:46 +0200 From: Enno Rey To: v6ops@ietf.org Message-ID: <20150722125046.GB47052@ernw.de> References: <55AE42A4.8020908@gmail.com> <5CD05758-D7B7-476D-9936-E5A1D0614AF8@employees.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5CD05758-D7B7-476D-9936-E5A1D0614AF8@employees.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [v6ops] ref Hosts dont MLD to join LL groups 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, 22 Jul 2015 12:50:56 -0000 On Wed, Jul 22, 2015 at 02:27:42PM +0200, Ole Troan wrote: > > Regarding the mic discussion about unicast RAs a SHOULD. > > > > I have been directed that the reference saying that Hosts dont MLD to join multicast groups is RFC3810: > > > > " The link-scope all-nodes multicast address, (FF02::1), is handled as > > a special case. On all nodes -- that is all hosts and routers, > > including multicast routers -- listening to packets destined to the > > all-nodes multicast address, from all sources, is permanently enabled > > on all interfaces on which multicast listening is supported. No MLD > > messages are ever sent regarding neither the link-scope all-nodes > > multicast address, nor any multicast address of scope 0 (reserved) or > > 1 (node-local).??? > > I do wonder if we should expand that exception to all link-scope multicast addresses. > > the bridge implementors I speak to tell me that they don???t have enough state to do MLD snooping for link-local scoped multicast addresses anyway... I can confirm that many switches do not apply MLD snooping/the subsequent "limited forwarding" to link-local MC groups, namely solicited-node. Read: they send those out an all ports, even with MLD snooping enabled. [see also https://www.troopers.de/media/filer_public/7c/35/7c35967a-d0d4-46fb-8a3b-4c16df37ce59/troopers15_ipv6secsummit_atlasis_rey_salazar_mld_considered_harmful_final.pdf] There's also https://tools.ietf.org/html/draft-pashby-magma-simplify-mld-snooping-01. best Enno > > cheers, > Ole > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From nobody Wed Jul 22 05:54:16 2015 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 074561B3312 for ; Wed, 22 Jul 2015 05:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wujc_tyNkSvj for ; Wed, 22 Jul 2015 05:54:12 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EABD1A1A39 for ; Wed, 22 Jul 2015 05:54:02 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6MCrwfC021087; Wed, 22 Jul 2015 14:53:58 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4BB2C202891; Wed, 22 Jul 2015 14:57:34 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 348C4202911; Wed, 22 Jul 2015 14:57:34 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.215]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6MCrwEc022062; Wed, 22 Jul 2015 14:53:58 +0200 To: Lorenzo Colitti References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> <55AD3B64.5070400@acm.org> <55AF0964.1060006@gmail.com> <55AF878E.1090200@gmail.com> <55AF889F.6080206@gmail.com> <55AF908A.4010906@gmail.com> From: Alexandru Petrescu Message-ID: <55AF9265.9070608@gmail.com> Date: Wed, 22 Jul 2015 14:53:57 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.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] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 22 Jul 2015 12:54:14 -0000 Le 22/07/2015 14:48, Lorenzo Colitti a ĂŠcrit : > On Wed, Jul 22, 2015 at 2:46 PM, Alexandru Petrescu > > wrote: > > Ok, that could be measured, but it's an LTE USB key. > > Let me try another USB WiFi dongle (maybe a tp-link). Would this apply? > > > Those aren't battery-powered devices. They are battery-powered devices, except the batteries are bigger. So maybe "various size battery devices"? Alex From nobody Wed Jul 22 05:59:50 2015 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 EE73D1B332B for ; Wed, 22 Jul 2015 05:59:45 -0700 (PDT) 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 XE06HnmUZuS1 for ; Wed, 22 Jul 2015 05:59:44 -0700 (PDT) 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 C94201B332C for ; Wed, 22 Jul 2015 05:59:43 -0700 (PDT) Received: by ykay190 with SMTP id y190so191425678yka.3 for ; Wed, 22 Jul 2015 05:59:43 -0700 (PDT) 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=A3XHaV5kjmdlPobveL7FFai9NEXVIEbjTzLoEiV6PoA=; b=Y21QX/WFnXztTpVyGiHReA1x5gtAaaVDwYGAS08hrCG4aUR8LDryRYIHw/GRZqNND/ 7MvwEWtutVpw+WwwHR5rZWig4PnxNy6h+jsUNoIpXimfpnFP82suM8Ttlp1GaTTr+yJ2 pxCh1xWpi1ZYkyuhhxNX7ZzF7ZQbNRw8uku7syE0RkBJF7wQsg2hMWpFTs92WOy/brt2 qITfxtBrQPdRssCYaQTXIlv/Cwz1+ZhQXGYQ5rab3TtStjS82hHjjIph7S2xmjJDsCzi nsC6+VAaJzMPVOivx4kNT4xFFl+putY/CrqOKwxGNS+HnI2lcQCca/cyTF3WagWDszX8 toiQ== 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=A3XHaV5kjmdlPobveL7FFai9NEXVIEbjTzLoEiV6PoA=; b=btcTaUXwIaVVULuvULToYSaxctyvlsnYF4mIZ0VQuQVypyBbuKvHX0cDneMuhk6d8c D9305rk0+7dhk2mhSmgouel1cq9vGYYZ6TjDnURQUFIwIP/vzpUQrLASOKhy3Q19Uiam HEYH/JbKn1qckIzFsvS8lMweQ2RijqXyMJjgYIQjz/ib5QpEZsQ7i1e20QvUZ73vjOYy nTjpKbT817PwW0vn6Hgivo8BIr2ABy5h9q7kAHPSmaSyCxXI+s2FI8ttMmELQCsscTHb GxY/AormV/oW4FMZtVoPPJ9DLGTZy4SwBOiSkqPrD6P/2nqzry/2JolTFEItmRf9nU+E UuFA== X-Gm-Message-State: ALoCoQneETJ5SW7KQFPkEvxKPglZCDZrYR8EZd6MPDx6WEb+BLc6WZSMj6o/EoPfgfc6FgbfGJNH X-Received: by 10.129.75.214 with SMTP id y205mr2323257ywa.65.1437569983142; Wed, 22 Jul 2015 05:59:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.8.201 with HTTP; Wed, 22 Jul 2015 05:59:23 -0700 (PDT) In-Reply-To: <55AF9265.9070608@gmail.com> References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> <55AD3B64.5070400@acm.org> <55AF0964.1060006@gmail.com> <55AF878E.1090200@gmail.com> <55AF889F.6080206@gmail.com> <55AF908A.4010906@gmail.com> <55AF9265.9070608@gmail.com> From: Lorenzo Colitti Date: Wed, 22 Jul 2015 14:59:23 +0200 Message-ID: To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=001a113f3d0a2fb183051b7658ae Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 22 Jul 2015 12:59:46 -0000 --001a113f3d0a2fb183051b7658ae Content-Type: text/plain; charset=UTF-8 On Wed, Jul 22, 2015 at 2:53 PM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Those aren't battery-powered devices. >> > > They are battery-powered devices, except the batteries are bigger. So > maybe "various size battery devices"? > Ok, we can change "battery-powered" to "exclusively battery-powered" in the next revision of the draft. --001a113f3d0a2fb183051b7658ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 22, 2015 at 2:53 PM, Alexandru Petrescu <alexandru.petr= escu@gmail.com> wrote:
Those aren't battery-powere= d devices.

They are battery-powered devices, except the batteries are bigger.=C2=A0 So= maybe "various size battery devices"?

<= /div>
Ok, we can change "battery-powered" to "exclusivel= y battery-powered" in the next revision of the draft.
--001a113f3d0a2fb183051b7658ae-- From nobody Wed Jul 22 06:02:54 2015 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 DCA5E1B331E for ; Wed, 22 Jul 2015 06:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79gDz1sX01tb for ; Wed, 22 Jul 2015 06:02:49 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE0781B3312 for ; Wed, 22 Jul 2015 06:02:47 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6MD2hFn008711; Wed, 22 Jul 2015 15:02:43 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id CD2F62028D7; Wed, 22 Jul 2015 15:06:18 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id BEC842028F5; Wed, 22 Jul 2015 15:06:18 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.215]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6MD2gCX029020; Wed, 22 Jul 2015 15:02:43 +0200 To: Jen Linkova References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> <55AD3B64.5070400@acm.org> <55AF0964.1060006@gmail.com> <55AF878E.1090200@gmail.com> <55AF889F.6080206@gmail.com> From: Alexandru Petrescu Message-ID: <55AF9472.9010209@gmail.com> Date: Wed, 22 Jul 2015 15:02:42 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.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] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 22 Jul 2015 13:02:52 -0000 Le 22/07/2015 14:31, Jen Linkova a écrit : > On Wed, Jul 22, 2015 at 2:12 PM, Alexandru Petrescu > wrote: >> >> "... on Androids and iPhones"? >> >> But not on huawei E392. > > I'm not sure what the fact that huawei E392 is not affected by a > particular issue proves. > So far we know that > - there are platforms affected; > - there is one unaffected platform. I think we discuss here a smartphone world. Android and smartphones in general are great things that happened to Internet, but there is more to it: raspberry pis, and various other small yet non-smartphone platforms. Alex > > Therefore I believe it is perfectly find for the title to be 'Reducing > battery impact of Router Advertisements'. If a particular network and > its devices are not affected - good, the network administrators MAY > (or SHOULD?) ignore the draft and not apply the recommendations. > >> Le 22/07/2015 14:10, Lorenzo Colitti a écrit : >>> >>> I'm told the problem affects iPhones as well. >>> >>> On Wed, Jul 22, 2015 at 2:07 PM, Alexandru Petrescu >>> > wrote: >>> >>> "Reducing battery impact of RAs on Androids"? >>> >>> Alex >>> >>> Le 22/07/2015 12:22, Lorenzo Colitti a écrit : >>> >>> Thanks for all the feedback. We have posted a -01 addressing >>> some of the >>> feedback we got. The new version also contains a new >>> recommendation not >>> to send periodic RAs too frequently, so we have changed the title to >>> "Reducing battery impact of Router Advertisements". >>> >>> https://tools.ietf.org/html/draft-yc-v6ops-solicited-ra-unicast-01 >>> >>> If there are no objections, we will upload this as a WG document >>> in the >>> next few days. >>> >>> On Wed, Jul 22, 2015 at 5:09 AM, Alejandro Acosta >>> >> >>> >> >> >>> wrote: >>> >>> Hi There, >>> I also support this document, it's very positive to see >>> that this >>> algorithm will save energy. >>> >>> Regards, >>> >>> Alejandro, >>> >>> El 7/21/2015 a las 6:11 PM, Nabil Benamar escribió: >>> >>> Hi Folks, >>> >>> I support this document which is very informative, >>> useful and its >>> implementation will certainly reduce energy consumption >>> due to >>> excessive Multicast RA sent. The proposed algorithm >>> seems to be >>> suitable for this end ! >>> >>> >>> Best regards >>> >>> >>> >>> On Tue, Jul 21, 2015 at 4:38 PM, Owen DeLong >>> >>> >> wrote: >>> >>> It seems to me that the following algorithm would be >>> relatively easy to implement >>> and provide reasonable network optimization… >>> >>> >>> On receipt of an RS: >>> >>> if(multicast_ra_time_remaining > 15 seconds) >>> { >>> Send_Unicast_ra >>> } >>> else >>> { >>> Send_Multicast_ra >>> reset_multicast_timer >>> } >>> >>> In this way, if the timing is reasonably close, you >>> multicast >>> a packet you were about to send >>> anyway, but if the timing isn’t close, you’re not >>> wasting >>> multicast bandwidth answering a single >>> node where nobody else cares. >>> >>> Overall, I’ve always thought that multicast >>> response to RS was >>> kind of silly. It’s probably most >>> harmful on WiFi. >>> >>> Owen >>> >>> > On Jul 21, 2015, at 02:33 , Andrew Yourtchenko >>> >>> >> wrote: >>> > >>> > On 7/20/15, Erik Nordmark >>> <>> >nordmark@acm.org >>> >>> >>> >> >> wrote: >>> >> On 7/17/15 9:34 AM, Fred Baker (fred) wrote: >>> >>>> So the next logical thing to do would be to >>> have the >>> router default to >>> >>>> unicast Router Advertisements, measure the rate of >>> received Router >>> >>>> Solicitations, and switch to multicast RA mode >>> past a certain >>> >>>> threshold to cover this sort of situation. >>> Once the >>> number of RSes >>> >>>> falls, it switches back to unicast RA mode. >>> >>>> >>> >>>> That would get rid of the configuration knob >>> proposed in >>> this ID, and >>> >>>> is behaviour that I think could be universal >>> for all link >>> types, >>> >>>> rather than just for the case of wireless ones >>> with >>> mobile devices. >>> >>> If it were me implementing it, I think I would >>> go about >>> this in a little >>> >>> different way, hopefully simpler. I would want >>> to send at >>> most one (e.g., >>> >>> either zero or one) RA per some interval (a >>> second?). In >>> the normal case, >>> >>> that is sent unicast. However, having sent a >>> unicast RA at >>> time t, if I >>> >>> now receive another RS before t+1, I send the >>> next one (at >>> time t+1) as a >>> >>> multicast. >>> >> >>> >> First of all I support this document as a WG >>> document. >>> >> >>> >> But in terms of implementation, isn't it simpler to >>> always(*) respond to >>> >> a RS with a unicast RA? >>> > >>> > Yes. I did not respond on-list yet - but from >>> operational >>> perspective >>> > "always send solRA unicast" / "always send solRA >>> multicast" >>> definitely >>> > wins in my book, and I'd avoid premature >>> optimizations (but >>> maybe we >>> > can say the implementers are explicitly free to >>> do their own >>> > optimizations if they see fit) >>> > >>> > That said, will be very interesting to hear data >>> from folks >>> who will >>> > run "all-unicast solRA", in real networks and >>> then compare >>> the effect >>> > of their proposal optimizations on their >>> real-world scenarios. >>> > >>> >> As background, the text in RFC4861 comes from >>> the old >>> concern that all >>> >> devices might boot at the same time when the >>> power is >>> re-established >>> >> after a building power failure; that doesn't >>> happen since >>> most devices >>> >> (laptops, smartphones, IoT devices) have >>> batteries today. >>> In that case >>> >> it might have made sense to sending fewer RA >>> messages by >>> using multicast. >>> >> >>> >> (*) the only case in RFC 4861 when I think a >>> multicast >>> response might be >>> >> considered is when the source IPv6 address in >>> the RS is the >>> unspecified >>> >> address. Further, an implementation which rate >>> limits >>> received RS >>> >> packets (e.g., CoPP in a router) might also want >>> to detect >>> when the rate >>> >> limit might have dropped RS packets and >>> multicast an RA in >>> that case. >>> >> >>> >> >>> >> I do wonder why implementations haven't already >>> changed to >>> send unicast >>> >> solicited RA, and whether it would make a >>> difference if we >>> have an >>> > >>> > TBH that's my concern as well. I think we should >>> tweak the >>> text in >>> > 4861 to encourage a bit more consideration on the >>> implementer's side. >>> > >>> >> informational document asking them to do this. >>> Alternatively we could >>> >> have a proposed standard which updates section >>> 6.2.6 to >>> change the "MAY >>> >> unicast" to a "SHOULD unicast". >>> > >>> > Yeah, I actually have had the different text >>> aimed for 6man, but >>> > Lorenzo's concern was 6man would say "there is no >>> protocol >>> update >>> > here, go away", so he rewrote it for v6ops. >>> > >>> > We should probably discuss this at the mic and >>> get the >>> opinion of the >>> > 6man chairs - if there is no outright "no" on this, a >>> normative doc >>> > would be a better way to convince the implementers ? >>> > >>> >> >>> >> FWIW the draft incorrectly refers to section >>> 6.2.4 instead >>> of 6.2.6. >>> > >>> > Nice catch, thanks! >>> > >>> > --a >>> > >>> >> >>> >> Thanks, >>> >> Erik >>> >> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> 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 >>> >>> _______________________________________________ >>> 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 >>> >>> >>> >>> >>> _______________________________________________ >>> 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 Wed Jul 22 06:04:44 2015 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 9B4471B333E for ; Wed, 22 Jul 2015 06:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvNvrVoPZbdc for ; Wed, 22 Jul 2015 06:04:37 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A7821B333F for ; Wed, 22 Jul 2015 06:04:36 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6MD4X4C024928; Wed, 22 Jul 2015 15:04:33 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A2E7C2028FD; Wed, 22 Jul 2015 15:08:08 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 8AFFE20277B; Wed, 22 Jul 2015 15:08:08 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.215]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6MD4Wmp030816; Wed, 22 Jul 2015 15:04:32 +0200 To: Lorenzo Colitti References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> <55AD3B64.5070400@acm.org> <55AF0964.1060006@gmail.com> <55AF878E.1090200@gmail.com> <55AF889F.6080206@gmail.com> <55AF908A.4010906@gmail.com> <55AF9265.9070608@gmail.com> From: Alexandru Petrescu Message-ID: <55AF94E0.5050802@gmail.com> Date: Wed, 22 Jul 2015 15:04:32 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.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] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 22 Jul 2015 13:04:41 -0000 Le 22/07/2015 14:59, Lorenzo Colitti a écrit : > On Wed, Jul 22, 2015 at 2:53 PM, Alexandru Petrescu > > wrote: > > Those aren't battery-powered devices. > > > They are battery-powered devices, except the batteries are bigger. > So maybe "various size battery devices"? > > > Ok, we can change "battery-powered" to "exclusively battery-powered" in > the next revision of the draft. No, I didnt mean that. Maybe "exclusively li-ion 7.2V 700maH batteries". Alex From nobody Wed Jul 22 06:16:00 2015 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 D93F11A905A for ; Wed, 22 Jul 2015 06:15:59 -0700 (PDT) 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 w3Cqfl5B4I-l for ; Wed, 22 Jul 2015 06:15:54 -0700 (PDT) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 346201B335E for ; Wed, 22 Jul 2015 06:15:54 -0700 (PDT) Received: by ykay190 with SMTP id y190so191824983yka.3 for ; Wed, 22 Jul 2015 06:15:53 -0700 (PDT) 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=OBA0z1yyqNvafQ5PqE1hKzs9XzU8Bqmlgdstr+uLmSU=; b=X/R9QyfoHIezdhfHKU2+EXJCccryDxXuCk8jvQtPXGXnWZu5MFyxDxkUVKB2hDY4KW s/uOXqbB3/kuiHHz+GYwUPzQ/FzxehKvFYCPUTBZHmCPT9oIVmdGXDnaytqSOqRIsNYi S2CvX2GNFS8bHMdXtE31so3pse3jZzyZoAms0KZFT3Sb1eOz6DC1USsXnNoVBylSRiFR BRIlcAlno4hxZF2LFHL7Nj46oetHLxI9OyzcmJmPt+w/vXJBaHvKoU56g/HHS2Ae/xKJ iTfyL12I8xLsP3jsMQG9YkxuXLlSR/NzxUHwXw4ys/XcONDUV+3Pglc+X8KdIE3YMPpf 1uWw== 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=OBA0z1yyqNvafQ5PqE1hKzs9XzU8Bqmlgdstr+uLmSU=; b=nMI9HL5WNLwzOhYT80s6mnNBCDLGZ0woAudIURAc7ecBAW+eiKyDxW3nV6bY0KZJkS INWWSQ/mHzuKsh/n6iQlPTpTmI7Buh2X9jxjNgUyT+2th+P5QVsN4XYSlIXsytx9H+yA JhsuQnPPU/MUapdeJMlPsXjEY0r9I3qxYNnG8CO6+4g21U8XSmbY/LOFOcWAEW1/Xih8 dt5mmp0E6HAAxp9+fyJE2tYFFdfZvoxDBlJgDa0GOcAdF/br3KACBLljZV5brJRqol8F jue0Go9QjucIVSMD28qLznn6wai7PPpkiW0LRfwO+DpESpGCVM4tTP1PcGWbySkUZ1r2 b3Sg== X-Gm-Message-State: ALoCoQnxAMSnlfNFrCdvyRfXx0NrleNybeK41ab4UWaXFwm+qddMurw55aReOjnfeKbfByOWEtJq X-Received: by 10.170.40.20 with SMTP id 20mr2331290yki.47.1437570953574; Wed, 22 Jul 2015 06:15:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.8.201 with HTTP; Wed, 22 Jul 2015 06:15:33 -0700 (PDT) In-Reply-To: <55AF94E0.5050802@gmail.com> References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> <55AD3B64.5070400@acm.org> <55AF0964.1060006@gmail.com> <55AF878E.1090200@gmail.com> <55AF889F.6080206@gmail.com> <55AF908A.4010906@gmail.com> <55AF9265.9070608@gmail.com> <55AF94E0.5050802@gmail.com> From: Lorenzo Colitti Date: Wed, 22 Jul 2015 15:15:33 +0200 Message-ID: To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=001a1137aa94073058051b76927d Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 22 Jul 2015 13:16:00 -0000 --001a1137aa94073058051b76927d Content-Type: text/plain; charset=UTF-8 On Wed, Jul 22, 2015 at 3:04 PM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Ok, we can change "battery-powered" to "exclusively battery-powered" in >> the next revision of the draft. >> > > No, I didnt mean that. > > Maybe "exclusively li-ion 7.2V 700maH batteries". > "Devices where network communication has non-negligible affect on battery life" --001a1137aa94073058051b76927d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 22, 2015 at 3:04 PM, Alexandru Petrescu <alexandru.petr= escu@gmail.com> wrote:
Ok, we can change "battery= -powered" to "exclusively battery-powered" in
the next revision of the draft.

No, I didnt mean that.

Maybe "exclusively li-ion 7.2V 700maH batteries".

"Devices where network communication has non-negl= igible affect on battery life"
--001a1137aa94073058051b76927d-- From nobody Wed Jul 22 06:40:02 2015 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 A78F71A8BC3 for ; Wed, 22 Jul 2015 06:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnGtdvVuswxA for ; Wed, 22 Jul 2015 06:39:59 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450: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 DDF731B33E7 for ; Wed, 22 Jul 2015 06:38:08 -0700 (PDT) Received: by wibud3 with SMTP id ud3so173031592wib.0 for ; Wed, 22 Jul 2015 06:38:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nkitxnewx56WPBDUMJph1a1isRaauSMr+Jj12TkjRKw=; b=s3wklyejtdVUhkmsYjW7rOP9jrjUSuptQjV/XMpIwKRxXlfv3wvH3Z81U48srpparq TUJpjY6aUF7gZqrD1bu0GkmMu5zx5LKOuIPlTeqSSdcyQmgld5w+RMM9pSGL/2uhsOkK O37/0HvxQyMgY/wgqJShoh3qWHXCzoIVgO/68m9A7fAB+q9vP1cJ0oSfMETFhNN+iGnJ lK8I/zvFtGeBY3QJP/xuA8Zdbk40aGN2rHs9qDjJC3Ef6VCHjJBVeM9Q8wn06XQwz1Ne m7I+f4cgqeTE9BzDp5LUI7XrRAAFU3JddIJ2pK938BafCyrI6rK2o3uspjPcnZmdjTTV zNSw== X-Received: by 10.194.185.180 with SMTP id fd20mr5058403wjc.16.1437572287437; Wed, 22 Jul 2015 06:38:07 -0700 (PDT) Received: from ?IPv6:2001:67c:1231:998:f953:417a:1305:9948? ([2001:67c:1231:998:f953:417a:1305:9948]) by smtp.gmail.com with ESMTPSA id l2sm3483823wib.11.2015.07.22.06.38.05 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Jul 2015 06:38:06 -0700 (PDT) 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 (12H143) In-Reply-To: <5CD05758-D7B7-476D-9936-E5A1D0614AF8@employees.org> Date: Wed, 22 Jul 2015 15:38:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55AE42A4.8020908@gmail.com> <5CD05758-D7B7-476D-9936-E5A1D0614AF8@employees.org> To: Ole Troan Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ref Hosts dont MLD to join LL groups 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, 22 Jul 2015 13:40:00 -0000 On 22 Jul 2015, at 14:27, Ole Troan wrote: >> Regarding the mic discussion about unicast RAs a SHOULD. >>=20 >> I have been directed that the reference saying that Hosts dont MLD to joi= n multicast groups is RFC3810: >>=20 >> " The link-scope all-nodes multicast address, (FF02::1), is handled as >> a special case. On all nodes -- that is all hosts and routers, >> including multicast routers -- listening to packets destined to the >> all-nodes multicast address, from all sources, is permanently enabled >> on all interfaces on which multicast listening is supported. No MLD >> messages are ever sent regarding neither the link-scope all-nodes >> multicast address, nor any multicast address of scope 0 (reserved) or >> 1 (node-local).=94 >=20 > I do wonder if we should expand that exception to all link-scope multicast= addresses. >=20 > the bridge implementors I speak to tell me that they don=92t have enough s= tate to do MLD snooping for link-local scoped multicast addresses anyway... I hear similar, but in my interpretation they say this in the context of sol= icited node multicast groups, not in general about link-local groups. OTOH it is easy to just flood link-local groups, right ? If so - getting rid= of MLD seems like extra work to get something already possible ? (Also, add= ing complexity of dealing with the "pre" and "post" hosts) --a >=20 > cheers, > Ole > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Jul 22 07:27:14 2015 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 BA33A1A7D82 for ; Wed, 22 Jul 2015 07:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 8AxvuCvHdYG6 for ; Wed, 22 Jul 2015 07:27:12 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 670841A0178 for ; Wed, 22 Jul 2015 07:27:12 -0700 (PDT) Received: by puck.nether.net (Postfix, from userid 162) id BA009540AB0; Wed, 22 Jul 2015 10:27:11 -0400 (EDT) Date: Wed, 22 Jul 2015 10:27:11 -0400 From: Jared Mauch To: Lorenzo Colitti Message-ID: <20150722142711.GA23678@puck.nether.net> References: <55AF889F.6080206@gmail.com> <55AF908A.4010906@gmail.com> <55AF9265.9070608@gmail.com> <55AF94E0.5050802@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23+102 (2ca89bed6448) (2014-03-12) Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 22 Jul 2015 14:27:13 -0000 On Wed, Jul 22, 2015 at 03:15:33PM +0200, Lorenzo Colitti wrote: > On Wed, Jul 22, 2015 at 3:04 PM, Alexandru Petrescu < > alexandru.petrescu@gmail.com> wrote: > > > Ok, we can change "battery-powered" to "exclusively battery-powered" in > >> the next revision of the draft. > >> > > > > No, I didnt mean that. > > > > Maybe "exclusively li-ion 7.2V 700maH batteries". > > > > "Devices where network communication has non-negligible affect on battery > life" While this is clearly obvious on devices that require sipping power that they are not working right, it may exist in other devices or poorly implemented hardware on wired devices which are asleep. Dave Thaler talked yesterday about the logo requirements for MSFT in the hardware to do ARP and NDP offload. I suspect instead of arguging about the nits here some generic text would be most constructive. Call it "Green" to use lower power by having unicast vs multicast/broadcast traffic. - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From nobody Wed Jul 22 07:48:48 2015 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 48D751B2E02 for ; Wed, 22 Jul 2015 07:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_IMAGE_ONLY_32=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 K2c3vY1lzcPI for ; Wed, 22 Jul 2015 07:48:45 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::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 A409A1B2DFB for ; Wed, 22 Jul 2015 07:48:45 -0700 (PDT) Received: by lagw2 with SMTP id w2so139462888lag.3 for ; Wed, 22 Jul 2015 07:48:44 -0700 (PDT) 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=sLzku+kvEm/jgpF7GDwIm6BFKiTTPPDT/r7xgU4yDmw=; b=N0W2JW3KvbrJNsU0g4fINVkLRUD925muq6RGiQwJymw4EvggM+FhWeWxNgjMMLuR50 jf1Tbc28IqcqShzXR16FxRhHTLUFqMxLuBi0zmDrlvHmmZqrmQejReABXvnfYrMQnhgd 7JJLFcGf0Z1RVjwmWzUUqvZmzsKpFIlBR6+0h+OG3QKj/BqzheSyoO0oK+N5CoY+tfEC mD/T3CPla3s8a/5pnjgSW+HNzIgEtUVuZpKyYbYgoXB4OsTMQ8igbM5V7+qy7iqy6rj7 4dx+90q7uOPYvJ4DZ9sqeyg4rT6t1KEhQT6tsyz3aFiG4t0z35bCpH6JDCLSgb3jxsHE FKaw== MIME-Version: 1.0 X-Received: by 10.152.20.138 with SMTP id n10mr2727489lae.115.1437576523984; Wed, 22 Jul 2015 07:48:43 -0700 (PDT) Received: by 10.25.41.146 with HTTP; Wed, 22 Jul 2015 07:48:43 -0700 (PDT) In-Reply-To: <20150722142711.GA23678@puck.nether.net> References: <55AF889F.6080206@gmail.com> <55AF908A.4010906@gmail.com> <55AF9265.9070608@gmail.com> <55AF94E0.5050802@gmail.com> <20150722142711.GA23678@puck.nether.net> Date: Wed, 22 Jul 2015 15:48:43 +0100 Message-ID: From: Nabil Benamar To: Jared Mauch Content-Type: multipart/alternative; boundary=089e0149414c0cb6f3051b77de05 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 22 Jul 2015 14:48:47 -0000 --089e0149414c0cb6f3051b77de05 Content-Type: text/plain; charset=UTF-8 another title alternative could be: "Towards an eco-friendly Router Advertisements" Best regards On Wed, Jul 22, 2015 at 3:27 PM, Jared Mauch wrote: > On Wed, Jul 22, 2015 at 03:15:33PM +0200, Lorenzo Colitti wrote: > > On Wed, Jul 22, 2015 at 3:04 PM, Alexandru Petrescu < > > alexandru.petrescu@gmail.com> wrote: > > > > > Ok, we can change "battery-powered" to "exclusively battery-powered" in > > >> the next revision of the draft. > > >> > > > > > > No, I didnt mean that. > > > > > > Maybe "exclusively li-ion 7.2V 700maH batteries". > > > > > > > "Devices where network communication has non-negligible affect on battery > > life" > > While this is clearly obvious on devices that require sipping > power that they are not working right, it may exist in other devices > or poorly implemented hardware on wired devices which are asleep. Dave > Thaler talked yesterday about the logo requirements for MSFT in the > hardware > to do ARP and NDP offload. > > I suspect instead of arguging about the nits here some generic > text would be most constructive. Call it "Green" to use lower power > by having unicast vs multicast/broadcast traffic. > > - Jared > > -- > Jared Mauch | pgp key available via finger from jared@puck.nether.net > clue++; | http://puck.nether.net/~jared/ My statements are only > mine. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --089e0149414c0cb6f3051b77de05 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
another title alternative could b= e: "Towards an eco-friendly Router Advertisements"

Best regards

<= img src=3D"https://docs.google.com/uc?export=3Ddownload&id=3D0B329i1SzX= WWvODU0TFdSTldVcDQ&revid=3D0B329i1SzXWWvVmRzRWs4SFFUTXNEcTVvMzgrSFRTenp= IelB3PQ" width=3D"96" height=3D"52">

On Wed, Jul 22, 2015 at 3:27 PM, Jared Mauch= <jared@puck.nether.net> wrote:
On Wed, Jul 22, 2015 at 03:15:33PM +0200, Lorenz= o Colitti wrote:
> On Wed, Jul 22, 2015 at 3:04 PM, Alexandru Petrescu <
> alexandru.petrescu@gmail.com> wrote:
>
> > Ok, we can change "battery-powered" to "exclusivel= y battery-powered" in
> >> the next revision of the draft.
> >>
> >
> > No, I didnt mean that.
> >
> > Maybe "exclusively li-ion 7.2V 700maH batteries".
> >
>
> "Devices where network communication has non-negligible affect on= battery
> life"

=C2=A0 =C2=A0 =C2=A0 =C2=A0 While this is clearly obvious on devices= that require sipping
power that they are not working right, it may exist in other devices
or poorly implemented hardware on wired devices which are asleep.=C2=A0 Dav= e
Thaler talked yesterday about the logo requirements for MSFT in the hardwar= e
to do ARP and NDP offload.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I suspect instead of arguging about the nits he= re some generic
text would be most constructive.=C2=A0 Call it "Green" to use low= er power
by having unicast vs multicast/broadcast traffic.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 - Jared

--
Jared Mauch=C2=A0 | pgp key available via finger from jared@puck.nether.net
clue++;=C2=A0 =C2=A0 =C2=A0 | http://puck.nether.net/~jared/=C2=A0= My statements are only mine.

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

--089e0149414c0cb6f3051b77de05-- From nobody Wed Jul 22 08:25:46 2015 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 5F6811A037C for ; Wed, 22 Jul 2015 08:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7N8F9wQE1mz for ; Wed, 22 Jul 2015 08:25:42 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B48DC1A0100 for ; Wed, 22 Jul 2015 08:25:41 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6MFPcqZ003087; Wed, 22 Jul 2015 17:25:38 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2721F2029FC; Wed, 22 Jul 2015 17:29:14 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 17EFE2027C0; Wed, 22 Jul 2015 17:29:14 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.215]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6MFPbbW021543; Wed, 22 Jul 2015 17:25:38 +0200 To: Jared Mauch , Lorenzo Colitti References: <55AF889F.6080206@gmail.com> <55AF908A.4010906@gmail.com> <55AF9265.9070608@gmail.com> <55AF94E0.5050802@gmail.com> <20150722142711.GA23678@puck.nether.net> From: Alexandru Petrescu Message-ID: <55AFB5F1.4030904@gmail.com> Date: Wed, 22 Jul 2015 17:25:37 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150722142711.GA23678@puck.nether.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 22 Jul 2015 15:25:43 -0000 I agree, 'green devices' is right. But dont make it that multicast is expensive in terms of energy. Actually multicast is a tool to make devices save on energy. Alex Le 22/07/2015 16:27, Jared Mauch a écrit : > On Wed, Jul 22, 2015 at 03:15:33PM +0200, Lorenzo Colitti wrote: >> On Wed, Jul 22, 2015 at 3:04 PM, Alexandru Petrescu < >> alexandru.petrescu@gmail.com> wrote: >> >>> Ok, we can change "battery-powered" to "exclusively battery-powered" in >>>> the next revision of the draft. >>>> >>> >>> No, I didnt mean that. >>> >>> Maybe "exclusively li-ion 7.2V 700maH batteries". >>> >> >> "Devices where network communication has non-negligible affect on battery >> life" > > While this is clearly obvious on devices that require sipping > power that they are not working right, it may exist in other devices > or poorly implemented hardware on wired devices which are asleep. Dave > Thaler talked yesterday about the logo requirements for MSFT in the hardware > to do ARP and NDP offload. > > I suspect instead of arguging about the nits here some generic > text would be most constructive. Call it "Green" to use lower power > by having unicast vs multicast/broadcast traffic. > > - Jared > From nobody Wed Jul 22 08:26:50 2015 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 93FB11A0100 for ; Wed, 22 Jul 2015 08:26:47 -0700 (PDT) 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 5DIWm79lMbL6 for ; Wed, 22 Jul 2015 08:26:45 -0700 (PDT) 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 CCC311A064C for ; Wed, 22 Jul 2015 08:26:44 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 58CC562CE4 for ; Wed, 22 Jul 2015 17:26:43 +0200 (CEST) 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 22B5462CDB for ; Wed, 22 Jul 2015 17:26:43 +0200 (CEST) Received: (qmail 60786 invoked by uid 1007); 22 Jul 2015 17:26:43 +0200 Date: Wed, 22 Jul 2015 17:26:43 +0200 From: Gert Doering To: Alexandru Petrescu Message-ID: <20150722152643.GQ90924@Space.Net> References: <55AF908A.4010906@gmail.com> <55AF9265.9070608@gmail.com> <55AF94E0.5050802@gmail.com> <20150722142711.GA23678@puck.nether.net> <55AFB5F1.4030904@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55AFB5F1.4030904@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] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 22 Jul 2015 15:26:47 -0000 Hi, On Wed, Jul 22, 2015 at 05:25:37PM +0200, Alexandru Petrescu wrote: > But dont make it that multicast is expensive in terms of energy. > Actually multicast is a tool to make devices save on energy. Read up on how multicast on wifi works. 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 Jul 22 08:52:35 2015 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 2C57E1A1C00 for ; Wed, 22 Jul 2015 08:52:35 -0700 (PDT) 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 qIdFeDJTJ3Nw for ; Wed, 22 Jul 2015 08:52:30 -0700 (PDT) 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 B4DBE1A1C04 for ; Wed, 22 Jul 2015 08:52:30 -0700 (PDT) Received: by ykfw194 with SMTP id w194so115872807ykf.0 for ; Wed, 22 Jul 2015 08:52:30 -0700 (PDT) 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=1vSbK2YIS15sjsE2wXXm2Av/J+D29z9lxW1oDQMoSfA=; b=A92G1t0epAe9G4ezTQqfwRr8zewLijn4oRji7a061rqfNvIKZOExWIkRNYbrbj3Xmu lY3JK6sUv/fyQPEPGwqO9GwVO+gv6SDYE9SmRLAwi7pEOV0gP3ceJIisU3hOw+k+Z3BH N7eW02q8xGU64MA2txEsqzip82jlSNz+IwtvkED/kOOeKnWlXeAxiYBptk2TYCFG64lq jBYmrBY09l70FzwtEiTNpjCKE2UV6alwbe/QK7nRNtqwzy+t0IbY674V/fOy8/5/ndE5 Gjz7VbYSPXYzmNtGQNkgE9DA/ddkoXog4w5yPkwd7Wj0nhX9y+vKGNAFyAyOLOMjl7ff xEZg== 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=1vSbK2YIS15sjsE2wXXm2Av/J+D29z9lxW1oDQMoSfA=; b=aS1oftx6n/YcmEP1UYJtv6wSUoxVu5BM8x1t1x8c5MsiyoXX2mT15TqRGJPw1xKyu7 bz7Md5vgv9B7czY8NqHUwMRMLhCOeIcOrnaGTtYhUFgBidqSVd3kVqWUDnPmMvCm9euP yVcgwuuMVi3fZcIyjwmhUyz31Q2YDCcGvbSBjRzpovH+gxdHJQdyha9dlQxLp5yw9SbN yi7mnY8YJWwuq1LJQFDQDeFhb1LIA0aVZ+omaGrEtYWqvYO4rhvPKyqz9cAt3Fi+FnuO d0ciyNcFevN+6xrh9pjNbvPexOUtoPiEN0dHJ2RHfF3yk5bgtpgd57/hyT3XvQX322Bs TcGQ== X-Gm-Message-State: ALoCoQnjCdmZ2nkIx5t7746LI/lCzQAol3Rmx59yPFP06jRlsCPR0V5inFIixDikhTzr8XB4xeEk X-Received: by 10.13.255.2 with SMTP id p2mr3025350ywf.149.1437580350065; Wed, 22 Jul 2015 08:52:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.8.201 with HTTP; Wed, 22 Jul 2015 08:52:10 -0700 (PDT) In-Reply-To: <20150722152643.GQ90924@Space.Net> References: <55AF908A.4010906@gmail.com> <55AF9265.9070608@gmail.com> <55AF94E0.5050802@gmail.com> <20150722142711.GA23678@puck.nether.net> <55AFB5F1.4030904@gmail.com> <20150722152643.GQ90924@Space.Net> From: Lorenzo Colitti Date: Wed, 22 Jul 2015 17:52:10 +0200 Message-ID: To: Gert Doering Content-Type: multipart/alternative; boundary=94eb2c0888f61a62ac051b78c24d Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 22 Jul 2015 15:52:35 -0000 --94eb2c0888f61a62ac051b78c24d Content-Type: text/plain; charset=UTF-8 On Wed, Jul 22, 2015 at 5:26 PM, Gert Doering wrote: > > But dont make it that multicast is expensive in terms of energy. > > Actually multicast is a tool to make devices save on energy. > > Read up on how multicast on wifi works. Make sure you look at http://www.slideshare.net/ArubaNetworks/atoz-design-guide-for-the-allwireless-workplace slide 20, which says that unicast can negatively affect battery life. --94eb2c0888f61a62ac051b78c24d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 22, 2015 at 5:26 PM, Gert Doering <gert@space.net> wrot= e:
> But dont make it that multicas= t is expensive in terms of energy.
> Actually multicast is a tool to make devices save on energy.

Read up on how multicast on wifi works.

<= div>Make sure you look at http://www.slideshare.ne= t/ArubaNetworks/atoz-design-guide-for-the-allwireless-workplace slide 2= 0, which says that unicast can negatively affect battery life.
<= /div>
--94eb2c0888f61a62ac051b78c24d-- From nobody Wed Jul 22 09:41:01 2015 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 EE5291B2AF6 for ; Wed, 22 Jul 2015 09:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 MhL3qLAaIdEj for ; Wed, 22 Jul 2015 09:40:59 -0700 (PDT) Received: from smtpcmd02111.aruba.it (smtpcmd02111.aruba.it [62.149.158.111]) by ietfa.amsl.com (Postfix) with ESMTP id 023001B2ACF for ; Wed, 22 Jul 2015 09:39:46 -0700 (PDT) Received: from dell-tcastaldi ([31.130.224.109]) by smtpcmd02.ad.aruba.it with bizsmtp id vUfl1q00L2NEPrz01Ufmsm; Wed, 22 Jul 2015 18:39:46 +0200 Date: Wed, 22 Jul 2015 18:39:47 +0200 (CEST) From: Meetecho Team To: v6ops@ietf.org Message-ID: <1437446480.7.1437583187030.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_6_422120303.1437583187029" Archived-At: Subject: [v6ops] Meetecho recordings of V6OPS WG session 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, 22 Jul 2015 16:41:00 -0000 ------=_Part_6_422120303.1437583187029 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the V6OPS WG session at IETF 93 is available at the following URL: http://ietf93.conf.meetecho.com/index.php/Recorded_Sessions#V6OPS In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team ------=_Part_6_422120303.1437583187029-- From nobody Wed Jul 22 10:12:01 2015 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 52CFA1A1B66 for ; Wed, 22 Jul 2015 10:12:00 -0700 (PDT) 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 xB0d_CDWziKg for ; Wed, 22 Jul 2015 10:11:59 -0700 (PDT) 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 087221A8547 for ; Wed, 22 Jul 2015 10:11:56 -0700 (PDT) Received: by ykay190 with SMTP id y190so197873984yka.3 for ; Wed, 22 Jul 2015 10:11:56 -0700 (PDT) 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=Enn6SpUd61gtgR2E6h8HTJ+MSrODj7qjJ7mjAFuqSjw=; b=OqBz36w6hy8uLrMG3ECsM3SdGVaBWtAZkaUBuSP+zGYaenoQLOhOVMfpvhwvvK831F /UTznhvPaiJfJOItYDLOXGDqv2KhfxlPEVEciKaq1xy6vHOCO1HCU6Y5BPBXMvrSoKUh 3TO5TMa8N55I4+LvhOo1VOPaF3CZYydDccLcaERF9G1pzkDmBneNn3N9Yax6oMazJc9C bVghG3USaurgcHuj869X8x310l0P/qcdKPh/Z4fTCPoHRTeM0p0HdA5Y52n3V2yAwuLw QWlFIjqfb3rFhG89FIPy0KoNr3wNi5kO8bkdiBIAenVJ9n94ucKdMVJHnNiDjqYP1ytA uJ4Q== 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=Enn6SpUd61gtgR2E6h8HTJ+MSrODj7qjJ7mjAFuqSjw=; b=PsvfnIw5VoBXm91/rz7EemmIDBpOUOVwyFGCj1ojblQel8Dp8B9Du6YxnU7gCUe0ql 9ZSMz30YtdpZ9Otflaod3rPzoBw2iBPSSGiA+QhVTZtTOfIk9MCK4DwA2zASb1tgpT0G IWCYVFkZPYe/eMh1/sl1JTHUbAXdZ+3p0GSDWJHWhhTH8vWt/DfybyjPH8b1P8TtSY88 h1BToXfbMG1aW5tZBvgJcVfNq0WLLIWSn80+kCBuFaf312y1VlJAkwBDRwMopdyc4kx5 UiKZqPqtCouxt7wXGPeyDzXzbgZFUQdELPtPFJuvCVk/sLPskPyPPnr0ZCYmHpuOPI6J gj/g== X-Gm-Message-State: ALoCoQkNMQMvEsfd+FmYCcJ7tbMLpnE4xQWOteOofv76n9UgOd+qSQ7cdf/rOUzlKoJtz9DEHgho X-Received: by 10.170.40.20 with SMTP id 20mr3514483yki.47.1437585116341; Wed, 22 Jul 2015 10:11:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.8.201 with HTTP; Wed, 22 Jul 2015 10:11:36 -0700 (PDT) In-Reply-To: References: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> From: Lorenzo Colitti Date: Wed, 22 Jul 2015 19:11:36 +0200 Message-ID: To: Yury Shefer Content-Type: multipart/alternative; boundary=001a1137aa943205dd051b79de00 Archived-At: Cc: "v6ops@ietf.org WG" , draft-colitti-v6ops-host-addr-availability@tools.ietf.org Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability 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, 22 Jul 2015 17:12:00 -0000 --001a1137aa943205dd051b79de00 Content-Type: text/plain; charset=UTF-8 On Tue, Jul 7, 2015 at 7:57 AM, Yury Shefer wrote: > Since you mentioned 3GPP, maybe it would be useful to mention Broadband > Forum (BBF) as well? BBF End-to-End Architecture technical reports > recommend the following: > [...] > I looked at TR-177, but I couldn't find a reference to what is supposed to happen downstream of the residential gateway, so it didn't seem to directly support the statement in the paragraph that hosts "have the ability to configure additional IPv6 addresses from the on-link prefix without explicit requests to the network". Is there a BBF document that has a statement along those lines somewhere? --001a1137aa943205dd051b79de00 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 7, 2015 at 7:57 AM, Yury Shefer <shefys@gmail.com> wr= ote:
Since you mentioned 3GP= P, maybe it would be useful to mention Broadband Forum (BBF) as well? BBF E= nd-to-End Architecture technical reports recommend the following:
= [...]

I looked at TR-177, b= ut I couldn't find a reference to what is supposed to happen downstream= of the residential gateway, so it didn't seem to directly support the = statement in the paragraph that hosts "have the ability to configure a= dditional IPv6 addresses from the on-link prefix without explicit requests = to the network". Is there a BBF document that has a statement along th= ose lines somewhere?
--001a1137aa943205dd051b79de00-- From nobody Wed Jul 22 10:28:13 2015 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 DBFED1B2BE9 for ; Wed, 22 Jul 2015 10:28:08 -0700 (PDT) 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 sIKTAbYUcOSC for ; Wed, 22 Jul 2015 10:28:07 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id A2E931ACDB3 for ; Wed, 22 Jul 2015 10:28:06 -0700 (PDT) Received: from [31.133.180.130] (dhcp-b482.meeting.ietf.org [31.133.180.130]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 152DA4032E for ; Wed, 22 Jul 2015 13:28:08 -0400 (EDT) From: "Marc Blanchet" To: v6ops@ietf.org Date: Wed, 22 Jul 2015 19:27:54 +0200 Message-ID: <069F4F98-67B5-4597-B76F-3704B127AE0B@viagenie.ca> References: <1612687302.5.1437583180864.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Subject: [v6ops] Fwd: [sunset4] Meetecho recordings of SUNSET4 WG session 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, 22 Jul 2015 17:28:09 -0000 FYI, this is the joint sunset4-v6ops, where most of the session was v6ops, hence this forward. Regards, Marc. Forwarded message: > From: Meetecho Team > To: sunset4@ietf.org > Subject: [sunset4] Meetecho recordings of SUNSET4 WG session > Date: Wed, 22 Jul 2015 18:39:40 +0200 (CEST) > > Dear all, > > the full recording (synchronized video, audio, slides and jabber room) > of the > SUNSET4 WG session at IETF 93 is available at the following URL: > http://ietf93.conf.meetecho.com/index.php/Recorded_Sessions#SUNSET4 > > In case of problems with the playout, just drop an e-mail to > ietf-support@meetecho.com. > > For the chair(s): please feel free to put the link to the recording in > the minutes, > if you think this might be useful. > > Cheers, > the Meetecho Team > > > _______________________________________________ > sunset4 mailing list > sunset4@ietf.org > https://www.ietf.org/mailman/listinfo/sunset4 From nobody Wed Jul 22 13:31:59 2015 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 12F761A8791 for ; Wed, 22 Jul 2015 13:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.811 X-Spam-Level: X-Spam-Status: No, score=-0.811 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, MIME_8BIT_HEADER=0.3, 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 zTB8ZwgczuLi for ; Wed, 22 Jul 2015 13:31:56 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 603B51B2B38 for ; Wed, 22 Jul 2015 13:31:44 -0700 (PDT) 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.2) with ESMTP id t6MKVUHc026955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Jul 2015 13:31:31 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Owen DeLong In-Reply-To: Date: Wed, 22 Jul 2015 13:31:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <77D742C8-C295-4813-8392-DE272EAEA39E@delong.com> References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> <55AD3B64.5070400@acm.org> To: =?utf-8?Q?Andrew_=F0=9F=91=BD_Yourtchenko?= X-Mailer: Apple Mail (2.2098) Archived-At: Cc: v6ops list , "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 22 Jul 2015 20:31:58 -0000 > On Jul 22, 2015, at 01:19 , Andrew =F0=9F=91=BD Yourtchenko = wrote: >=20 > My brain can not compile this pseudocode... >=20 > reset_multicast_timer resets multicast_ra_time_remaining to what value = ? To whatever value it would get reset to when a multicast_ra is = transmitted normally. Why is this difficult to comprehend? > In the large-scale WiFi networks I operate I send multicast RA once in > 30 minutes, and an immediate unicast solicited RA upon RS. Seems reasonable. >=20 > If the "reset" is done to the MinRtrAdvInterval...MaxRtrAdvInterval, > then this algorithm would optimize last 15 seconds of these 30 minutes > ? Yep. If you think the 15s mark should be increased, I=E2=80=99ve got no = problem with that=E2=80=A6 If you think it should be configurable, I=E2=80=99m OK with that, too. If you think it should be computed as a fraction of some value related = to {Min,Max}RtrAdvInterval, then propose something, I=E2=80=99m probably OK with that as well. The point is it seems to me if you=E2=80=99re reasonably close to = transmitting a multicast, then it makes sense to answer the solicitation with a multicast and reset the = multicast timer. Otherwise, send a unicast RA. If this seems like a good idea other than arguing about the value of = =E2=80=9Creasonably close=E2=80=9D, then I think we=E2=80=99re in general agreement and I=E2=80=99m mostly willing = to let others pick the value or formula for determining =E2=80=9Creasonably close=E2=80=9D. Owen >=20 > --a >=20 > On 7/21/15, Owen DeLong wrote: >> It seems to me that the following algorithm would be relatively easy = to >> implement >> and provide reasonable network optimization=E2=80=A6 >>=20 >>=20 >> On receipt of an RS: >>=20 >> if(multicast_ra_time_remaining > 15 seconds) >> { >> Send_Unicast_ra >> } >> else >> { >> Send_Multicast_ra >> reset_multicast_timer >> } >>=20 >> In this way, if the timing is reasonably close, you multicast a = packet you >> were about to send >> anyway, but if the timing isn=E2=80=99t close, you=E2=80=99re not = wasting multicast >> bandwidth answering a single >> node where nobody else cares. >>=20 >> Overall, I=E2=80=99ve always thought that multicast response to RS = was kind of >> silly. It=E2=80=99s probably most >> harmful on WiFi. >>=20 >> Owen >>=20 >>> On Jul 21, 2015, at 02:33 , Andrew =F0=9F=91=BD Yourtchenko = >>> wrote: >>>=20 >>> On 7/20/15, Erik Nordmark wrote: >>>> On 7/17/15 9:34 AM, Fred Baker (fred) wrote: >>>>>> So the next logical thing to do would be to have the router = default to >>>>>> unicast Router Advertisements, measure the rate of received = Router >>>>>> Solicitations, and switch to multicast RA mode past a certain >>>>>> threshold to cover this sort of situation. Once the number of = RSes >>>>>> falls, it switches back to unicast RA mode. >>>>>>=20 >>>>>> That would get rid of the configuration knob proposed in this ID, = and >>>>>> is behaviour that I think could be universal for all link types, >>>>>> rather than just for the case of wireless ones with mobile = devices. >>>>> If it were me implementing it, I think I would go about this in a >>>>> little >>>>> different way, hopefully simpler. I would want to send at most one >>>>> (e.g., >>>>> either zero or one) RA per some interval (a second?). In the = normal >>>>> case, >>>>> that is sent unicast. However, having sent a unicast RA at time t, = if I >>>>> now receive another RS before t+1, I send the next one (at time = t+1) as >>>>> a >>>>> multicast. >>>>=20 >>>> First of all I support this document as a WG document. >>>>=20 >>>> But in terms of implementation, isn't it simpler to always(*) = respond to >>>> a RS with a unicast RA? >>>=20 >>> Yes. I did not respond on-list yet - but from operational = perspective >>> "always send solRA unicast" / "always send solRA multicast" = definitely >>> wins in my book, and I'd avoid premature optimizations (but maybe we >>> can say the implementers are explicitly free to do their own >>> optimizations if they see fit) >>>=20 >>> That said, will be very interesting to hear data from folks who will >>> run "all-unicast solRA", in real networks and then compare the = effect >>> of their proposal optimizations on their real-world scenarios. >>>=20 >>>> As background, the text in RFC4861 comes from the old concern that = all >>>> devices might boot at the same time when the power is = re-established >>>> after a building power failure; that doesn't happen since most = devices >>>> (laptops, smartphones, IoT devices) have batteries today. In that = case >>>> it might have made sense to sending fewer RA messages by using >>>> multicast. >>>>=20 >>>> (*) the only case in RFC 4861 when I think a multicast response = might be >>>> considered is when the source IPv6 address in the RS is the = unspecified >>>> address. Further, an implementation which rate limits received RS >>>> packets (e.g., CoPP in a router) might also want to detect when the = rate >>>> limit might have dropped RS packets and multicast an RA in that = case. >>>>=20 >>>>=20 >>>> I do wonder why implementations haven't already changed to send = unicast >>>> solicited RA, and whether it would make a difference if we have an >>>=20 >>> TBH that's my concern as well. I think we should tweak the text in >>> 4861 to encourage a bit more consideration on the implementer's = side. >>>=20 >>>> informational document asking them to do this. Alternatively we = could >>>> have a proposed standard which updates section 6.2.6 to change the = "MAY >>>> unicast" to a "SHOULD unicast". >>>=20 >>> Yeah, I actually have had the different text aimed for 6man, but >>> Lorenzo's concern was 6man would say "there is no protocol update >>> here, go away", so he rewrote it for v6ops. >>>=20 >>> We should probably discuss this at the mic and get the opinion of = the >>> 6man chairs - if there is no outright "no" on this, a normative doc >>> would be a better way to convince the implementers ? >>>=20 >>>>=20 >>>> FWIW the draft incorrectly refers to section 6.2.4 instead of = 6.2.6. >>>=20 >>> Nice catch, thanks! >>>=20 >>> --a >>>=20 >>>>=20 >>>> Thanks, >>>> Erik >>>>=20 >>>>>=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 >>>>=20 >>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 From nobody Wed Jul 22 13:36:33 2015 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 4D6A11B2B5B for ; Wed, 22 Jul 2015 13:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, 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 q_hfEZrLHd2B for ; Wed, 22 Jul 2015 13:36:30 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 839971B2B0A for ; Wed, 22 Jul 2015 13:36:30 -0700 (PDT) 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.2) with ESMTP id t6MKaQkm027606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Jul 2015 13:36:27 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_EA0394C8-4E98-4BFB-8B7B-53687CE56D16" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Owen DeLong In-Reply-To: Date: Wed, 22 Jul 2015 13:36:26 -0700 Message-Id: References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> <55AD3B64.5070400@acm.org> <55AF0964.1060006@gmail.com> <55AF878E.1090200@gmail.com> <55AF889F.6080206@gmail.com> <55AF908A.4010906@gmail.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 22 Jul 2015 20:36:31 -0000 --Apple-Mail=_EA0394C8-4E98-4BFB-8B7B-53687CE56D16 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 22, 2015, at 05:48 , Lorenzo Colitti = wrote: >=20 > On Wed, Jul 22, 2015 at 2:46 PM, Alexandru Petrescu = > = wrote: > Ok, that could be measured, but it's an LTE USB key. >=20 > Let me try another USB WiFi dongle (maybe a tp-link). Would this = apply? >=20 > Those aren't battery-powered devices.=20 They are a lot of the time=E2=80=A6 Much of the time, they are plugged = into laptops not necessarily plugged into the wall. In those cases, yes, they are running on (admittedly fairly large) = batteries. Therefore, even for those cases, reducing battery consumption of RAs may = be helpful. Owen --Apple-Mail=_EA0394C8-4E98-4BFB-8B7B-53687CE56D16 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jul 22, 2015, at 05:48 , Lorenzo Colitti <lorenzo@google.com> = wrote:

On Wed, Jul 22, 2015 at 2:46 PM, Alexandru = Petrescu <alexandru.petrescu@gmail.com> wrote:
Ok, that could be = measured, but it's an LTE USB key.

Let me try another USB WiFi dongle (maybe a tp-link).  Would this = apply?

Those aren't battery-powered = devices. 

They are a lot of the time=E2=80=A6 Much of the time, = they are plugged into laptops not necessarily plugged into the = wall.

In those cases, yes, they are = running on (admittedly fairly large) batteries.

Therefore, even for those cases, reducing battery = consumption of RAs may be helpful.

Owen

= --Apple-Mail=_EA0394C8-4E98-4BFB-8B7B-53687CE56D16-- From nobody Wed Jul 22 13:37:12 2015 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 000EC1B2B8B for ; Wed, 22 Jul 2015 13:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, 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 1k1I-CkLbOlv for ; Wed, 22 Jul 2015 13:37:10 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id EE7541B2B0A for ; Wed, 22 Jul 2015 13:37:09 -0700 (PDT) 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.2) with ESMTP id t6MKaQkn027606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Jul 2015 13:37:05 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_0419561E-3F73-4B69-A378-37EEAA3E32E2" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Owen DeLong In-Reply-To: Date: Wed, 22 Jul 2015 13:37:05 -0700 Message-Id: References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> <55AD3B64.5070400@acm.org> <55AF0964.1060006@gmail.com> <55AF878E.1090200@gmail.com> <55AF889F.6080206@gmail.com> <55AF908A.4010906@gmail.com> <55AF9265.907060! 8@gmail.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 22 Jul 2015 20:37:11 -0000 --Apple-Mail=_0419561E-3F73-4B69-A378-37EEAA3E32E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Please don=E2=80=99t. Alexandru seems to be the only one who cares about = this nit and I really don=E2=80=99t think his argument is all that valid. Owen > On Jul 22, 2015, at 05:59 , Lorenzo Colitti = wrote: >=20 > On Wed, Jul 22, 2015 at 2:53 PM, Alexandru Petrescu = > = wrote: > Those aren't battery-powered devices. >=20 > They are battery-powered devices, except the batteries are bigger. So = maybe "various size battery devices"? >=20 > Ok, we can change "battery-powered" to "exclusively battery-powered" = in the next revision of the draft. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_0419561E-3F73-4B69-A378-37EEAA3E32E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Please don=E2=80=99t. Alexandru seems to be the only one who = cares about this nit and I really don=E2=80=99t think his argument
is all that valid.

Owen

On = Jul 22, 2015, at 05:59 , Lorenzo Colitti <lorenzo@google.com> = wrote:

On Wed, Jul 22, 2015 at 2:53 PM, Alexandru = Petrescu <alexandru.petrescu@gmail.com> wrote:
Those aren't battery-powered = devices.

They are battery-powered devices, except the batteries are bigger.  = So maybe "various size battery devices"?

Ok, we can change = "battery-powered" to "exclusively battery-powered" in the next revision = of the draft.
_______________________________________________
v6ops = mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

= --Apple-Mail=_0419561E-3F73-4B69-A378-37EEAA3E32E2-- From nobody Wed Jul 22 15:22:12 2015 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 A0B891B2F46 for ; Wed, 22 Jul 2015 15:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 on2YjRWVcPCD for ; Wed, 22 Jul 2015 15:22:08 -0700 (PDT) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (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 487331B2F44 for ; Wed, 22 Jul 2015 15:22:08 -0700 (PDT) Received: from [31.133.138.67] (dhcp-8943.meeting.ietf.org [31.133.138.67] (may be forged)) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t6MMLpoQ007415 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 22 Jul 2015 15:21:53 -0700 To: Mark Smith , Erik Kline References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> From: Erik Nordmark Message-ID: <55B0177F.8050703@acm.org> Date: Thu, 23 Jul 2015 00:21:51 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVY98wPbqrdhMAKsA+PGp8SM89Duok6WL/ueJ0qM273efGZIzKHMQq2mc/NTrVjXnklcteYdg46m844UUh4VJdv1 Archived-At: Cc: "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" , v6ops list Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 22 Jul 2015 22:22:09 -0000 On 7/21/15 1:25 PM, Mark Smith wrote: > > I thought that could be an option, however I encountered RSes without > the Source Link Layer Option, which means if RFC6085 is to be used, > the link-layer header has to be available to get the source link-layer > address from. > > After I wondered about the efficiency benefit of using multicasts for > solicited RAs, Fred asked me to do some testing/investigation. I wrote > up what I found here, the few unusual RS cases I saw the following, > which I put down some thoughts about handling via e.g., RFC6085. > > o RSes with a :: source address > > o RSes with a link-local source addresses, but no Source Link-Layer > Address Option Yes, both of those are important (I had forgotten about the second one). As you say, an implementation might be able to use the link-layer header and unicast back a packet. If the source was :: then that approach would rely on sending to the multicast ff02::1 while the link-layer destination is unicast. If not, then the implementation needs to multicast the RA. Erik > > https://www.ietf.org/mail-archive/web/v6ops/current/msg22464.html > > > > > https://www.ietf.org/mail-archive/web/v6ops/current/msg22464.html > >> But I would not say it's sufficient, if only from an "explicit >> clarity" standpoint. I think explicit mention of RAs and the other >> discussion is helpful for implementors not inclined to dig to great >> depths or just seeking explicit confirmation. >> > > > >> _______________________________________________ >> 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 Jul 22 15:31:31 2015 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 9A0651A6EE8 for ; Wed, 22 Jul 2015 15:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 AHyZhFsd3imh for ; Wed, 22 Jul 2015 15:31:28 -0700 (PDT) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (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 915E71A1BD1 for ; Wed, 22 Jul 2015 15:31:28 -0700 (PDT) Received: from [31.133.138.67] (dhcp-8943.meeting.ietf.org [31.133.138.67] (may be forged)) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t6MMVJQG017907 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 22 Jul 2015 15:31:20 -0700 To: Lorenzo Colitti , Erik Nordmark References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> <55AD3B64.5070400@acm.org> From: Erik Nordmark Message-ID: <55B019B7.4030805@acm.org> Date: Thu, 23 Jul 2015 00:31:19 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVZcK3LX88Tms4YOvq16pMjWshIKDMuLzaSJ9YC0XRGDaNASGC7IJi5hcj6zsdTEUkkNKuxHCYt9fXePo7UFiLsV X-Sonic-ID: C;6ASoX8Ew5RGg/4wFrKU7pA== M;iipTYMEw5RGg/4wFrKU7pA== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Archived-At: Cc: "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" , v6ops list Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 22 Jul 2015 22:31:29 -0000 On 7/21/15 11:35 AM, Lorenzo Colitti wrote: > On Mon, Jul 20, 2015 at 8:18 PM, Erik Nordmark > wrote: > > But in terms of implementation, isn't it simpler to always(*) > respond to a RS with a unicast RA? > > > It would be simpler to document, yes, but I don't know that we should > make a one-size-fits all recommendation, because there might be link > types or environments where this is more expensive. I don't think we should be too prescriptive, but it sounds like we should at least require that routers have support for unicast solicated RAs. One could also argue that the default should be to unicast solicited RAs. > > As background, the text in RFC4861 comes from the old concern that > all devices might boot at the same time when the power is > re-established after a building power failure; that doesn't happen > since most devices (laptops, smartphones, IoT devices) have > batteries today. In that case it might have made sense to sending > fewer RA messages by using multicast. > > > This sort of thing can still happen. If lots of devices join at once, > (e.g., if something happens at a large-scale event when hundreds of > people pull their phones out of their pockets and turn them on at the > same time), it may well be cheaper for the network to send one > multicast RA. > > I'm not opposed to changing the standards as well, but I think > respinning RFC 4861 would require much more careful consideration than > simply publishing an operational guidance document such as this one. > Perhaps we can just recommend in this document that 6man consider this > operational need and consider modifying the protocol? But the draft sort of does in suggesting the operator to enable a knob (unicast solicited RAs) which does not exist in many implementations because it isn't required. Hence you are placing requirements on implementations. If a v6ops informational document gets the work done (i.e., get those implementations updated) then we're ok. But if we need a more forceful message ... then a short document which updates section 6.2.6 in RFC 4861 isn't that difficult. Regards, Erik From nobody Wed Jul 22 15:39:30 2015 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 60B7B1B2F3B for ; Wed, 22 Jul 2015 15:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 e9Ljp2BfJLGD for ; Wed, 22 Jul 2015 15:39:27 -0700 (PDT) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (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 8B4EB1ACD36 for ; Wed, 22 Jul 2015 15:39:27 -0700 (PDT) Received: from [31.133.138.67] (dhcp-8943.meeting.ietf.org [31.133.138.67] (may be forged)) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t6MMdIfI026642 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 22 Jul 2015 15:39:19 -0700 To: Ole Troan References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> <55AD3B64.5070400@acm.org> From: Erik Nordmark Message-ID: <55B01B96.8090205@acm.org> Date: Thu, 23 Jul 2015 00:39:18 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Sonic-CAuth: UmFuZG9tSVb8rZbpWcil2qDQ737U1lMpjoUuu5cQW+tRY3K27X2JHbRsVJZvH+JlO26fVDLQfVbHsRxTvCriTMhmPySDib1V X-Sonic-ID: C;pkcpfcIw5RG8TYwFrKU7pA== M;LG/VfcIw5RG8TYwFrKU7pA== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Archived-At: Cc: "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" , v6ops list Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 22 Jul 2015 22:39:29 -0000 On 7/21/15 12:47 PM, Ole Troan wrote: >> But in terms of implementation, isn't it simpler to always(*) respond to a RS with a unicast RA? >> As background, the text in RFC4861 comes from the old concern that all devices might boot at the same time when the power is re-established after a building power failure; that doesn't happen since most devices (laptops, smartphones, IoT devices) have batteries today. In that case it might have made sense to sending fewer RA messages by using multicast. > in addition to Mark’s points. > - what happens when the router reboots, will not all the hosts then try to actively reconnect? > that router could server thousands of users. > - while this is intended for WIFI networks, in common deployments the WIFI interface is not integrated in the router. for the router’s perspective this just looks like another wired interface. either this has to be made configurable and not the default, or considerations of large flat wired L2 networks must also be considered. > Ole, Even on a flat wired L2 network I don't think it is harmful to default to unicast solicited RAs. If we take a worst case of 10000 hosts on the L2 network all rebooting/initializing at the same time, we will see: - 10000 DAD probes for link-local address - 10000 MLD joins for the solicited node MC for their link-locals - 10000 RS messages(*) - 1/10000 RA messages - 10000 DAD probes for global addresses (N x 10000 if N prefixes on-link) - N x 10000 mDNS etc type packets (*) RFC 4861 suggests receiving an RA before an RS is sent, thus under some timing conditions some RS messages might be avoided. But at best we seem to be talking about saving 20% of the packet during the boot of the 10000 hosts. Erik From nobody Wed Jul 22 16:14:16 2015 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 4A96D1B2D2B for ; Wed, 22 Jul 2015 16:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, 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 opeKdJHR-N0D for ; Wed, 22 Jul 2015 16:14:12 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 861EA1B2D12 for ; Wed, 22 Jul 2015 16:14:12 -0700 (PDT) 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.2) with ESMTP id t6MNE7cC017458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Jul 2015 16:14:07 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Owen DeLong In-Reply-To: <55B01B96.8090205@acm.org> Date: Wed, 22 Jul 2015 16:14:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> <55AD3B64.5070400@acm.org> <55B01B96.8090205@acm.org> To: Erik Nordmark X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" , v6ops list Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 22 Jul 2015 23:14:14 -0000 > On Jul 22, 2015, at 15:39 , Erik Nordmark wrote: >=20 > On 7/21/15 12:47 PM, Ole Troan wrote: >>> But in terms of implementation, isn't it simpler to always(*) = respond to a RS with a unicast RA? >>> As background, the text in RFC4861 comes from the old concern that = all devices might boot at the same time when the power is re-established = after a building power failure; that doesn't happen since most devices = (laptops, smartphones, IoT devices) have batteries today. In that case = it might have made sense to sending fewer RA messages by using = multicast. >> in addition to Mark=E2=80=99s points. >> - what happens when the router reboots, will not all the hosts then = try to actively reconnect? >> that router could server thousands of users. >> - while this is intended for WIFI networks, in common deployments = the WIFI interface is not integrated in the router. for the router=E2=80=99= s perspective this just looks like another wired interface. either this = has to be made configurable and not the default, or considerations of = large flat wired L2 networks must also be considered. >>=20 >=20 > Ole, >=20 > Even on a flat wired L2 network I don't think it is harmful to default = to unicast solicited RAs. >=20 > If we take a worst case of 10000 hosts on the L2 network all = rebooting/initializing at the same time, we will see: > - 10000 DAD probes for link-local address > - 10000 MLD joins for the solicited node MC for their link-locals As was pointed out earlier, we shouldn=E2=80=99t see MLD joins for LL = solicited nodes or any other LinkScoped group, unless I am badly = misunderstanding things. > - 10000 RS messages(*) > - 1/10000 RA messages I think you mean 1 to 10000 because I don=E2=80=99t think fractional = messages are possible. > - 10000 DAD probes for global addresses (N x 10000 if N prefixes = on-link) > - N x 10000 mDNS etc type packets >=20 > (*) RFC 4861 suggests receiving an RA before an RS is sent, thus under = some timing conditions some RS messages might be avoided. >=20 > But at best we seem to be talking about saving 20% of the packet = during the boot of the 10000 hosts. True=E2=80=A6 However, even if this is an actual concern, we could = consider a threshold in PPS where we send an RA Mcast response. e.g. if more than 10 RS received in 1 second, send a multicast RA. In fact, we could probably get away with delaying an RA response to RS = for 250ms. If another RS arrives during that delay, respond multicast, = else unicast. That probably still eliminates most of the RA traffic, may eliminate = many of those 10000 RS messages, and could provide kind of the best of = both worlds. I=E2=80=99m not sure how hard it would be to implement in silicon, = however. Owen From nobody Wed Jul 22 16:52:42 2015 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 0E58C1B2FB8 for ; Wed, 22 Jul 2015 16:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMMOzc4HAGSc for ; Wed, 22 Jul 2015 16:52:40 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450: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 2B4BE1B2FB4 for ; Wed, 22 Jul 2015 16:52:40 -0700 (PDT) Received: by wibud3 with SMTP id ud3so194838767wib.0 for ; Wed, 22 Jul 2015 16:52:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xkbMThrq6egFP6lHyxZDed1o0yZSrrrvlCqLMyGA/Ig=; b=WyaUOG5FDYg8xumLOe2QgvKiJx18kEreX4r8AQxJGiA5C9xH35FLCzDat5iOJhvfj5 987rxo+MQ1rYpG38HF+Ya7OUh443sKMlzjac9SKoyw/TzeM54IypzX2dHVWA8m8wZaD/ /DuXuEl6UMjpFAfPvG+QL8BrYbix/fywbz0dE96riJDH+AjhpdYX8OfzcZtRC5vPcp4v +JXIVElvFQ6r+j+rRSQMblypBrLtJhSWj0nYNzjApQwWVVjhVtsvKJenrNG7iFbgmFMV 8atnt9eKbO40/mtjET/DJMeIeI9+gCEKtL6xE5gtXb9woKwQ108hN5mtma3H6AljsZ7P zH1Q== X-Received: by 10.194.2.161 with SMTP id 1mr9378945wjv.143.1437609158953; Wed, 22 Jul 2015 16:52:38 -0700 (PDT) Received: from [10.77.152.93] ([188.188.93.64]) by smtp.gmail.com with ESMTPSA id r6sm24349579wiy.13.2015.07.22.16.52.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Jul 2015 16:52:38 -0700 (PDT) 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 (12H143) In-Reply-To: Date: Thu, 23 Jul 2015 01:52:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <75B2DB50-4B68-43DE-BF17-013F4BCAE72A@gmail.com> References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> <55AD3B64.5070400@acm.org> <55B01B96.8090205@acm.org> To: Owen DeLong Archived-At: Cc: v6ops list , "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 22 Jul 2015 23:52:42 -0000 > On 23 Jul 2015, at 01:14, Owen DeLong wrote: >=20 >=20 >> On Jul 22, 2015, at 15:39 , Erik Nordmark wrote: >>=20 >> On 7/21/15 12:47 PM, Ole Troan wrote: >>>> But in terms of implementation, isn't it simpler to always(*) respond t= o a RS with a unicast RA? >>>> As background, the text in RFC4861 comes from the old concern that all d= evices might boot at the same time when the power is re-established after a b= uilding power failure; that doesn't happen since most devices (laptops, smar= tphones, IoT devices) have batteries today. In that case it might have made s= ense to sending fewer RA messages by using multicast. >>> in addition to Mark=92s points. >>> - what happens when the router reboots, will not all the hosts then try t= o actively reconnect? >>> that router could server thousands of users. >>> - while this is intended for WIFI networks, in common deployments the WI= FI interface is not integrated in the router. for the router=92s perspective= this just looks like another wired interface. either this has to be made co= nfigurable and not the default, or considerations of large flat wired L2 net= works must also be considered. >>=20 >> Ole, >>=20 >> Even on a flat wired L2 network I don't think it is harmful to default to= unicast solicited RAs. >>=20 >> If we take a worst case of 10000 hosts on the L2 network all rebooting/in= itializing at the same time, we will see: >> - 10000 DAD probes for link-local address >> - 10000 MLD joins for the solicited node MC for their link-locals >=20 > As was pointed out earlier, we shouldn=92t see MLD joins for LL solicited n= odes or any other LinkScoped group, unless I am badly misunderstanding thing= s. You will see MLD for anything that is not ff02::1. Unlike in IPv4, which doe= s not require LL joins. RFC3810 talks about this I think. --a >=20 >> - 10000 RS messages(*) >> - 1/10000 RA messages >=20 > I think you mean 1 to 10000 because I don=92t think fractional messages ar= e possible. >=20 >> - 10000 DAD probes for global addresses (N x 10000 if N prefixes on-link)= >> - N x 10000 mDNS etc type packets >>=20 >> (*) RFC 4861 suggests receiving an RA before an RS is sent, thus under so= me timing conditions some RS messages might be avoided. >>=20 >> But at best we seem to be talking about saving 20% of the packet during t= he boot of the 10000 hosts. >=20 > True=85 However, even if this is an actual concern, we could consider a th= reshold in PPS where we send an RA Mcast response. >=20 > e.g. if more than 10 RS received in 1 second, send a multicast RA. >=20 > In fact, we could probably get away with delaying an RA response to RS for= 250ms. If another RS arrives during that delay, respond multicast, else uni= cast. >=20 > That probably still eliminates most of the RA traffic, may eliminate many o= f those 10000 RS messages, and could provide kind of the best of both worlds= . > I=92m not sure how hard it would be to implement in silicon, however. >=20 > Owen >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Jul 22 17:37:38 2015 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 3ED9C1B3002 for ; Wed, 22 Jul 2015 17:37:37 -0700 (PDT) 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, 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 duNwIS7qCkCh for ; Wed, 22 Jul 2015 17:37:36 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F39A1B2FE0 for ; Wed, 22 Jul 2015 17:37:35 -0700 (PDT) Received: by igbpg9 with SMTP id pg9so1481329igb.0 for ; Wed, 22 Jul 2015 17:37:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=JpG/udKX0rmHtmwOSO9WHBjUl/mFKw1nGLjZgoZZIts=; b=fMDGuepskrGFoYpqTGZpUmQR/S97p7T1rqvE0K0X6mkpUe5bTeVDKjUs9DzbakMG8Y TIiFE7ZOFDLGa7rNkEAq7BHdvVdoM0osrYXCilElwL4a2kZOc3cOnlweKKfs2di72sRM N35PVKDOvAu69MNVU0hfhXSZa9va4jMjqAj1NKFIyzlMwGdf5Fns7pD6j6P6zwVHiZrt UyJ1E/taNhyHTjNkyeCza5jQIxABB5cmiIZs97CN86Hq0bzL5n9lLIXSbtZzEw3pxDLO s5LPxferdghdEr2+tEQy0wNSJb+RPOv+ByY5YwwNwLiFCDgmyMHaXKp5vwjv10QpbXL5 A07Q== X-Received: by 10.107.29.209 with SMTP id d200mr8726171iod.94.1437611855096; Wed, 22 Jul 2015 17:37:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.169.143 with HTTP; Wed, 22 Jul 2015 17:37:05 -0700 (PDT) In-Reply-To: <55B0177F.8050703@acm.org> References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> <55B0177F.8050703@acm.org> From: Mark Smith Date: Thu, 23 Jul 2015 10:37:05 +1000 Message-ID: To: Erik Nordmark Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: v6ops list , "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 23 Jul 2015 00:37:37 -0000 Hi Erik, On 23 July 2015 at 08:21, Erik Nordmark wrote: > On 7/21/15 1:25 PM, Mark Smith wrote: >> >> >> I thought that could be an option, however I encountered RSes without >> the Source Link Layer Option, which means if RFC6085 is to be used, >> the link-layer header has to be available to get the source link-layer >> address from. >> >> After I wondered about the efficiency benefit of using multicasts for >> solicited RAs, Fred asked me to do some testing/investigation. I wrote >> up what I found here, the few unusual RS cases I saw the following, >> which I put down some thoughts about handling via e.g., RFC6085. >> >> o RSes with a :: source address >> >> o RSes with a link-local source addresses, but no Source Link-Layer >> Address Option > > > Yes, both of those are important (I had forgotten about the second one). > > As you say, an implementation might be able to use the link-layer header and > unicast back a packet. If the source was :: then that approach would rely on > sending to the multicast ff02::1 while the link-layer destination is > unicast. > > If not, then the implementation needs to multicast the RA. > I was wondering if instead the implementation could trigger an ND/NS transaction for the RS source address at that point, and then unicast the RA when that completes. RFC4861 seems to be a bit vague about being able to do that. It says that if the SLLO is not present, the router still can unicast the RA. As RFC4861 is pre RFC6085, then performing a ND/NS first would be the only way to do that. The last sentence also seems to be permitting NC entries to be created when there is no SLLO ("or not a Source Link-Layer is provided" ... "Neighbor Cache entry" ... "(or is created)"). "If there is no existing Neighbor Cache entry and no Source Link-Layer Address option was present in the solicitation, the router may respond with either a multicast or a unicast router advertisement. Whether or not a Source Link-Layer Address option is provided, if a Neighbor Cache entry for the solicitation's sender exists (or is created) the entry's IsRouter flag MUST be set to FALSE." Performing an NS/ND to resolve the source address of the RS without a SLLO would seem consistent with the corresponding RS SLLO handling - to load the Neighbor Cache with entries for nodes that have sent RSes. Regards, Mark. > Erik > >> >> https://www.ietf.org/mail-archive/web/v6ops/current/msg22464.html >> >> >> >> >> https://www.ietf.org/mail-archive/web/v6ops/current/msg22464.html >> >>> But I would not say it's sufficient, if only from an "explicit >>> clarity" standpoint. I think explicit mention of RAs and the other >>> discussion is helpful for implementors not inclined to dig to great >>> depths or just seeking explicit confirmation. >>> >> >> >> >>> _______________________________________________ >>> 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 Jul 23 00:17:03 2015 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 9E9611ACAD8 for ; Thu, 23 Jul 2015 00:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 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, 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 zjpGPT3X1y_G for ; Thu, 23 Jul 2015 00:16:59 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC1491B2A1C for ; Thu, 23 Jul 2015 00:13:27 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 63572A1; Thu, 23 Jul 2015 09:13:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1437635606; bh=Zu4ljlfSSdACx0mD5JZCtRZ3PNn3qc5MJLiS4dQqQTU=; h=Date:From:To:Subject:From; b=Rl9yj2xn57iIZyxF1nJ0mhxtcuwoSlCqj48QYmBoOSYocNZGHh8H3ttcQFLq2XEgP Kbc/1ZDbO9bXEb7n+GhnpiD3cMeB+GIZPnDslfz3rbtFxnxfnMDAPSGrrsoF/8eGrL Wh9r+EYZO/ee38T5FkW6seYGlwR/hB+pk2wcqUXk= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 5895C9F for ; Thu, 23 Jul 2015 09:13:26 +0200 (CEST) Date: Thu, 23 Jul 2015 09:13:26 +0200 (CEST) From: Mikael Abrahamsson To: v6ops@ietf.org Message-ID: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Subject: [v6ops] NAT64/DNS64 and DNSSEC 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, 23 Jul 2015 07:17:01 -0000 Hi, as far as I know, DNS64 and DNSSEC are fundamentally incompatible, because modifying A records into AAAA records breaks DNSSEC. Since we now have implementations (from what I understand at least APple does this) that do bump-in-the-API, would it make sense to work on a document that recommends to just use DNS64 just to discover the NAT64 prefix, and then do bump-in-the-API synthesis to do the A-to-AAAA NAT64-mapping? I really care about DNSSEC and I don't want this to be broken for a prolonged amount of time just because people are doing NAT64+DNS64. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Jul 23 00:42:52 2015 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 307661A87F1 for ; Thu, 23 Jul 2015 00:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6u_8X-_8M3QN for ; Thu, 23 Jul 2015 00:42:49 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::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 BB2F61A8706 for ; Thu, 23 Jul 2015 00:42:48 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so135722446wib.1 for ; Thu, 23 Jul 2015 00:42:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=hniAsQPx2/Jn5HF0wzRlua5cOmqQBjiG/l+baIov3YM=; b=wg3gy41rOrgrBpndb2ybP7gR+bL7Gge1VZimOqTaIreBEXMc1yKCij2ccAfc/5n4Tc Fy9VtqjBisGR/ND1AyphwJfi/C5LWnxZkzYXg6rK45LIE603lshsykoS29ClDzkVJjo+ 4MsdSE1Ocu7LsEC9N+djqfWYwqu+hdoxjOIb/IuJyyBe0pUY6DRvaS7FTeSrRauW9LQB ziyiRiYvGJ9p3rRr57xgC8o5ChapGL1zYhcIvfKCSLS51dzzCjQDEsnl263/nvricoRM cI0ed/xejDJ6WPXuApZJqHB8vNmiudT3rpqUMua/fANecqxZ27kghNse6IkcObCtil6L YFog== X-Received: by 10.194.85.130 with SMTP id h2mr14003494wjz.2.1437637367541; Thu, 23 Jul 2015 00:42:47 -0700 (PDT) Received: from [31.133.177.248] (dhcp-b1f8.meeting.ietf.org. [31.133.177.248]) by smtp.gmail.com with ESMTPSA id x10sm6108207wjr.25.2015.07.23.00.42.46 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Jul 2015 00:42:46 -0700 (PDT) Message-ID: <55B09AE5.4040609@gmail.com> Date: Thu, 23 Jul 2015 19:42:29 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Mikael Abrahamsson , v6ops@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] NAT64/DNS64 and DNSSEC 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, 23 Jul 2015 07:42:50 -0000 Read RFC 6147 - it covers this issue, and points out that "The main drawback of this mode is its deployability, since it requires changes in the end hosts." Regards Brian On 23/07/2015 19:13, Mikael Abrahamsson wrote: > > Hi, > > as far as I know, DNS64 and DNSSEC are fundamentally incompatible, because modifying A records into AAAA records breaks DNSSEC. > > Since we now have implementations (from what I understand at least APple does this) that do bump-in-the-API, would it make sense > to work on a document that recommends to just use DNS64 just to discover the NAT64 prefix, and then do bump-in-the-API synthesis > to do the A-to-AAAA NAT64-mapping? > > I really care about DNSSEC and I don't want this to be broken for a prolonged amount of time just because people are doing > NAT64+DNS64. > From nobody Thu Jul 23 00:55:21 2015 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 27E671A89B4 for ; Thu, 23 Jul 2015 00:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 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, 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 6oe9yrn3tUJq for ; Thu, 23 Jul 2015 00:55:19 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 216A11A8951 for ; Thu, 23 Jul 2015 00:55:19 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id AF04BA1; Thu, 23 Jul 2015 09:55:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1437638116; bh=ICmoVG6HefeU0E32tOboZhtxvHZ8WdW6iy1Vmc6210c=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=b62VmfIx9HhX+e6SCsRUtSyS/ABN7aSioo1tvvskYC2I8HLLAgijC6GhCY52JtoBe LmTSJ+xitslIorsEXfumW2QjHzz+LcPehPQ6hzfIds7WK69iDHS08KGNfz1z9AB0bb ZxUTXhTQkVnuX3ZeJNQAGIr1aFqqdfV5Ryzb53W4= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A7A179F; Thu, 23 Jul 2015 09:55:16 +0200 (CEST) Date: Thu, 23 Jul 2015 09:55:16 +0200 (CEST) From: Mikael Abrahamsson To: Brian E Carpenter In-Reply-To: <55B09AE5.4040609@gmail.com> Message-ID: References: <55B09AE5.4040609@gmail.com> 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 Subject: Re: [v6ops] NAT64/DNS64 and DNSSEC 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, 23 Jul 2015 07:55:20 -0000 On Thu, 23 Jul 2015, Brian E Carpenter wrote: > Read RFC 6147 - it covers this issue, and points out that > "The main drawback of this mode is its > deployability, since it requires changes in the end hosts." So you see no use for a document that gives guidance on this issue now that NAT64+DNS64 seems to be gaining traction, primarily in the mobile world? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Jul 23 01:18:02 2015 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 7F8EA1A8AC6 for ; Thu, 23 Jul 2015 01:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.637 X-Spam-Level: X-Spam-Status: No, score=-1.637 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, 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 SY2g1peaGlFV for ; Thu, 23 Jul 2015 01:17:57 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.112]) (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 B126F1A8A05 for ; Thu, 23 Jul 2015 01:17:56 -0700 (PDT) Received: from [194.106.220.35] by server-8.bemta-14.messagelabs.com id E6/7E-32733-333A0B55; Thu, 23 Jul 2015 08:17:55 +0000 X-Env-Sender: nick.heatley@ee.co.uk X-Msg-Ref: server-10.tower-91.messagelabs.com!1437639474!25531691!1 X-Originating-IP: [149.254.241.76] X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19274 invoked from network); 23 Jul 2015 08:17:54 -0000 Received: from unknown (HELO smtpml01.ee.co.uk) (149.254.241.76) by server-10.tower-91.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Jul 2015 08:17:54 -0000 Received: from EEUKWV0940.EEAD.EEINT.CO.UK (Not Verified[10.246.209.217]) by smtpml01.ee.co.uk with MailMarshal (v7, 2, 3, 6978) id ; Thu, 23 Jul 2015 09:17:42 +0100 Received: from UK31S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.27]) by EEUKWV0940.EEAD.EEINT.CO.UK with MailMarshal (v7, 2, 3, 6978) id ; Thu, 23 Jul 2015 09:17:54 +0100 Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK31S005EXS02.EEAD.EEINT.CO.UK ([2002:62c:2a56::62c:2a56]) with mapi id 14.03.0195.001; Thu, 23 Jul 2015 09:17:54 +0100 From: "Heatley, Nick" To: Mikael Abrahamsson , "v6ops@ietf.org" Thread-Topic: [v6ops] NAT64/DNS64 and DNSSEC Thread-Index: AQHQxRedzQPAv9hMVUOUvlQI6TNowp3otHHQ Date: Thu, 23 Jul 2015 08:17:54 +0000 Message-ID: <6536E263028723489CCD5B6821D4B21303EEA63D@UK30S005EXS06.EEAD.EEINT.CO.UK> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.246.208.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] NAT64/DNS64 and DNSSEC 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, 23 Jul 2015 08:18:01 -0000 >a document that recommends to just use DNS64 just to discover the NAT64 = prefix, and then do bump-in-the-API synthesis to do the A-to-AAAA NAT64-m= apping? What does this mean for wifi tethering/mobile hotspot? NOTICE AND DISCLAIMER This e-mail (including any attachments) is intended for the above-named p= erson(s). If you are not the intended recipient, notify the sender immed= iately, delete this email from your system and do not disclose or use for= =20any purpose. =20 =20 We may monitor all incoming and outgoing emails in line with current legi= slation. We have taken steps to ensure that this email and attachments ar= e free from any virus, but it remains your responsibility to ensure that = viruses do not adversely affect you.=20 EE Limited Registered in England and Wales Company Registered Number: 02382161 Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfor= dshire, AL10 9BW. From nobody Thu Jul 23 01:42:25 2015 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 7637B1A8ABD for ; Thu, 23 Jul 2015 01:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.6 X-Spam-Level: X-Spam-Status: No, score=-4.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 Fa4xzjxXlJEE for ; Thu, 23 Jul 2015 01:42:22 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 116201A1BE4 for ; Thu, 23 Jul 2015 01:41:30 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1ZIC4H-0000CdC; Thu, 23 Jul 2015 10:41:29 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com In-reply-to: Your message of "Thu, 23 Jul 2015 09:13:26 +0200 (CEST) ." Date: Thu, 23 Jul 2015 10:41:28 +0200 Archived-At: Subject: Re: [v6ops] NAT64/DNS64 and DNSSEC 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, 23 Jul 2015 08:42:24 -0000 In your letter dated Thu, 23 Jul 2015 09:13:26 +0200 (CEST) you wrote: >as far as I know, DNS64 and DNSSEC are fundamentally incompatible, because >modifying A records into AAAA records breaks DNSSEC. My conclusion is that essentially you have to do 464XLAT if the network does NAT64. That way you can have IPv4 literals and you can run unmodified DNS. From nobody Thu Jul 23 02:58:45 2015 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 7065D1A0149 for ; Thu, 23 Jul 2015 02:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8_s4uHcn0RZ4 for ; Thu, 23 Jul 2015 02:58:33 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AD531A0107 for ; Thu, 23 Jul 2015 02:58:33 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6N9wU2X016839; Thu, 23 Jul 2015 11:58:30 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 445E2204920; Thu, 23 Jul 2015 12:02:07 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 3CBC62048D0; Thu, 23 Jul 2015 12:02:07 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.151]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6N9wTxm016119; Thu, 23 Jul 2015 11:58:30 +0200 To: Andrew Yourtchenko References: <55AE44AA.7070304@gmail.com> <55AF874F.5000807@gmail.com> <069FB97F-6828-4CD6-8AC0-55AC564B668A@gmail.com> From: Alexandru Petrescu Message-ID: <55B0BAC5.1030706@gmail.com> Date: Thu, 23 Jul 2015 11:58:29 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <069FB97F-6828-4CD6-8AC0-55AC564B668A@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] unicast RA to save battery: link-layer joining multicast groups 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, 23 Jul 2015 09:58:39 -0000 If in addition to battery, one problems is: Router drops incoming facetime call to a standby smartphone. The drop is because Router does not buffer the call during its search for the smartphone's MAC address (NS/NA). A call made of two sequenced packets would suffice, two hammers hitting a bell. But the smartphone could also periodically send an unsolicited NA just before standing by. Of course, provided that I understand the problem in addition to the battery problem. And y es, let us discuss f2f tomorrow. Alex Le 22/07/2015 14:18, Andrew Yourtchenko a écrit : > You proposed dropping all multicast RAs when device is I standby. I > commented that the devices are already doing it and it is exactly a > problem that we are trying to solve with the draft, thus the > suggestion is unhelpful. > > Makes sense ? > > --a > > Sent from my iPhone > >> On 22 Jul 2015, at 14:06, Alexandru Petrescu >> wrote: >> >> Thanks for the pointer, but that's a long discussion, it's hard to >> draw quickly a conclusion on it. >> >> I would think to argue that if Android has a problem in this then >> it's an Android problem. >> >> If it's a particular driver problem (dependent on the card of that >> samsung phone) then fix that problem. >> >> Maybe it's not so. >> >> But I am sure the linux devices I use dont consume more power when >> receiving more RAs, on wifi. >> >> And even if they did, I have enough batteries and enough other >> sources of energy to provide them in order to be able to make >> handovers fast enough to not loose 1 single packet. >> >> Not sure whether the goal here is to save energy? >> >> Alex >> >> Le 22/07/2015 10:34, Andrew 👽 Yourtchenko a écrit : >>> This is what some phones do today and is exactly the problem we >>> are trying to solve. >>> >>> https://code.google.com/p/android/issues/detail?id=32662 >>> >>> --a >>> >>>> On 7/21/15, Alexandru Petrescu >>>> wrote: On another hand, >>>> >>>> IEEE 802.11bgn multicast groups (33::1 etc) are 'joined' at MAC >>>> layer by setting filters. (maybe even by MAC messaging for >>>> joining MAC multicast groups). >>>> >>>> Maybe we can request the Hosts to set local filters to not >>>> receive multicast RAs. Or request the Hosts short on energy to >>>> express interest in these IPv6 multicast groups. >>>> >>>> Alex >>>> >>>> _______________________________________________ v6ops mailing >>>> list v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >> > From nobody Thu Jul 23 03:08:39 2015 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 883B51A026A for ; Thu, 23 Jul 2015 03:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.965 X-Spam-Level: X-Spam-Status: No, score=-0.965 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 ghMEoe3PZPjK for ; Thu, 23 Jul 2015 03:08:36 -0700 (PDT) Received: from mailin.tpsa.pl (mailout.tpsa.pl [212.160.172.10]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6E381A0461 for ; Thu, 23 Jul 2015 03:08:35 -0700 (PDT) Received: from 10.236.62.151 (EHLO OPE10HT01.tp.gk.corp.tepenet) ([10.236.62.151]) by mailin.tpsa.pl (MOS 4.4.2a-FCS FastPath queued) with ESMTP id DWC49906; Thu, 23 Jul 2015 12:08:19 +0200 (CEST) From: =?iso-8859-2?Q?Czerwonka_Micha=B3_1_-_Hurt?= To: Philip Homburg , "v6ops@ietf.org" Thread-Topic: [v6ops] NAT64/DNS64 and DNSSEC Thread-Index: AQHQxSNdhanHpTIC20amYveYP8eqwZ3o08wQ Date: Thu, 23 Jul 2015 10:08:09 +0000 Message-ID: <2D29C51862222E49B991EF64EEB0B5B745FC2D21@OPE10MB05.tp.gk.corp.tepenet> References: Your message of "Thu, 23 Jul 2015 09:13:26 +0200 (CEST) ." In-Reply-To: Accept-Language: pl-PL, en-US Content-Language: pl-PL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [126.13.107.45] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2015.7.23.91817:17:7.944, ip=, rules=__HAS_FROM, FROM_NAME_PHRASE, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __IMS_MSGID, __HAS_MSGID, __SANE_MSGID, __IN_REP_TO, WEBMAIL_XOIP, __HAS_XOIP, __CT, __CT_TEXT_PLAIN, __CTE, __MIME_VERSION, WEBMAIL_X_IP_HDR, __ANY_URI, __HTTPS_URI, __URI_NO_PATH, __SUBJ_ALPHA_NEGATE, __URI_IN_BODY, __FORWARDED_MSG, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_800_899, __MIME_TEXT_ONLY, __URI_NS, HTML_00_01, HTML_00_10, BODY_SIZE_5000_LESS, WEBMAIL_SOURCE, BODY_SIZE_1000_LESS, BODY_SIZE_2000_LESS, BODY_SIZE_7000_LESS, SINGLE_URI_IN_BODY X-Junkmail-Status: score=10/50, host=mailin.tpsa.pl X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0C0205.55B0BD13.03EF, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32, mode=multiengine X-Junkmail-IWF: false X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0C0205.55B0BD13.03EF, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d6734786eeedf6031ca1d577d0998c30 Archived-At: Subject: Re: [v6ops] NAT64/DNS64 and DNSSEC 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, 23 Jul 2015 10:08:37 -0000 +1 no DNS64 when NAT64+CLAT (464XLAT) but one domain must be dns64 - "ipv4only.arpa" BR, Mcz -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Philip Homburg Sent: Thursday, July 23, 2015 10:41 AM To: v6ops@ietf.org Subject: Re: [v6ops] NAT64/DNS64 and DNSSEC In your letter dated Thu, 23 Jul 2015 09:13:26 +0200 (CEST) you wrote: >as far as I know, DNS64 and DNSSEC are fundamentally incompatible,=20 >because modifying A records into AAAA records breaks DNSSEC. My conclusion is that essentially you have to do 464XLAT if the network doe= s NAT64. That way you can have IPv4 literals and you can run unmodified DNS. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Jul 23 03:31:45 2015 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 5686E1A1BC2 for ; Thu, 23 Jul 2015 03:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 S8fmS7J4k_bb for ; Thu, 23 Jul 2015 03:31:42 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (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 CD8461A2182 for ; Thu, 23 Jul 2015 03:31:01 -0700 (PDT) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 82C2EDA0085; Thu, 23 Jul 2015 10:31:01 +0000 (UTC) Received: from [10.0.20.218] (71.233.41.235) by CAS-03.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.224.2; Thu, 23 Jul 2015 03:31:01 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_178A832B-439A-4452-8CC8-7EB8B3F3CF7F" MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ted Lemon In-Reply-To: <55B09AE5.4040609@gmail.com> Date: Thu, 23 Jul 2015 06:30:59 -0400 Message-ID: <2BBE839B-37FB-4EA2-982E-58028E7A13B6@nominum.com> References: <55B09AE5.4040609@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.2102) X-Originating-IP: [71.233.41.235] Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] NAT64/DNS64 and DNSSEC 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, 23 Jul 2015 10:31:43 -0000 --Apple-Mail=_178A832B-439A-4452-8CC8-7EB8B3F3CF7F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Jul 23, 2015, at 3:42 AM, Brian E Carpenter = wrote: > Read RFC 6147 - it covers this issue, and points out that > "The main drawback of this mode is its > deployability, since it requires changes in the end hosts." I think Mikael is asking for a stronger statement than =E2=80=9Cyou = could do this, but probably won=E2=80=99t.=E2=80=9D I think this would take the form of a document describing = recommendations for DNSSEC-aware stub resolvers, which I don=E2=80=99t = think currently exists, and hence could in theory be worked on. --Apple-Mail=_178A832B-439A-4452-8CC8-7EB8B3F3CF7F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" On Jul 23, 2015, at 3:42 AM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
Read RFC 6147 - it covers this issue, and points = out that
"The main drawback of this = mode is its
deployability, since it = requires changes in the end hosts."

I think Mikael is asking for a stronger = statement than =E2=80=9Cyou could do this, but probably = won=E2=80=99t.=E2=80=9D

I think this would take the form of a document describing = recommendations for DNSSEC-aware stub resolvers, which I don=E2=80=99t = think currently exists, and hence could in theory be worked = on.

= --Apple-Mail=_178A832B-439A-4452-8CC8-7EB8B3F3CF7F-- From nobody Thu Jul 23 04:10:03 2015 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 29D8C1A89FD for ; Thu, 23 Jul 2015 04:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E_MZdufTHo0j for ; Thu, 23 Jul 2015 04:09:57 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::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 F05E11A8729 for ; Thu, 23 Jul 2015 04:09:56 -0700 (PDT) Received: by ietj16 with SMTP id j16so189469288iet.0 for ; Thu, 23 Jul 2015 04:09:56 -0700 (PDT) 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:content-transfer-encoding; bh=dFIYyIlraPPFpar7P7IN3EZTwLg7Zeq4OW7M9WhiNiU=; b=x5ku5OlrWCIs3GWy2BF5q1ocKcUg8HRfAxmt85+TXIZO0ucKE8H3VT8k4uGJq0kpCZ q7v746Jp9ixpSaG3jhy2k8rUp1T72EbB7ObHOrkuwQOme16lp+PyyDQR47t25g0d9o70 LjcMloFprg8ap+g6s9JnXJfhNvsLJO814ZfQQ+InIB+9NMAGpeywFvEHLquZqptxUmFA nGr9YnBhcrxVbYksxt05Y3S1XQN9tqYXFTAnhN4y6FQ7i4298IIAvycCqnPnJRLW/wIO Z7DprdvwpO9P1EGqZtFKfQf6ZntN83tk8RUhjakgG/mRmgyMgf9i+sJ8xFn4isSakeuy K0lw== MIME-Version: 1.0 X-Received: by 10.107.128.214 with SMTP id k83mr13201365ioi.7.1437649796412; Thu, 23 Jul 2015 04:09:56 -0700 (PDT) Received: by 10.107.182.7 with HTTP; Thu, 23 Jul 2015 04:09:56 -0700 (PDT) In-Reply-To: <77D742C8-C295-4813-8392-DE272EAEA39E@delong.com> References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> <55AD3B64.5070400@acm.org> <77D742C8-C295-4813-8392-DE272EAEA39E@delong.com> Date: Thu, 23 Jul 2015 04:09:56 -0700 Message-ID: From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= To: Owen DeLong Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: v6ops list , "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 23 Jul 2015 11:10:02 -0000 On 7/22/15, Owen DeLong wrote: > >> On Jul 22, 2015, at 01:19 , Andrew =F0=9F=91=BD Yourtchenko >> wrote: >> >> My brain can not compile this pseudocode... >> >> reset_multicast_timer resets multicast_ra_time_remaining to what value ? > > To whatever value it would get reset to when a multicast_ra is transmitte= d > normally. > > Why is this difficult to comprehend? > >> In the large-scale WiFi networks I operate I send multicast RA once in >> 30 minutes, and an immediate unicast solicited RA upon RS. > > Seems reasonable. > >> >> If the "reset" is done to the MinRtrAdvInterval...MaxRtrAdvInterval, >> then this algorithm would optimize last 15 seconds of these 30 minutes >> ? > > Yep. > > If you think the 15s mark should be increased, I=E2=80=99ve got no proble= m with > that=E2=80=A6 > > If you think it should be configurable, I=E2=80=99m OK with that, too. > > If you think it should be computed as a fraction of some value related to > {Min,Max}RtrAdvInterval, > then propose something, I=E2=80=99m probably OK with that as well. > > The point is it seems to me if you=E2=80=99re reasonably close to transmi= tting a > multicast, then it makes > sense to answer the solicitation with a multicast and reset the multicast > timer. Otherwise, send > a unicast RA. > > If this seems like a good idea other than arguing about the value of > =E2=80=9Creasonably close=E2=80=9D, then I > think we=E2=80=99re in general agreement and I=E2=80=99m mostly willing t= o let others pick > the value or formula > for determining =E2=80=9Creasonably close=E2=80=9D. Upon more thinking, this algorithm is actually a harmful idea - regardless of the settings it does not save any packets while deceiving everyone involved (including yourself) that it does, and is of course more complex than a single knob. --a > > Owen > >> >> --a >> >> On 7/21/15, Owen DeLong wrote: >>> It seems to me that the following algorithm would be relatively easy to >>> implement >>> and provide reasonable network optimization=E2=80=A6 >>> >>> >>> On receipt of an RS: >>> >>> if(multicast_ra_time_remaining > 15 seconds) >>> { >>> Send_Unicast_ra >>> } >>> else >>> { >>> Send_Multicast_ra >>> reset_multicast_timer >>> } >>> >>> In this way, if the timing is reasonably close, you multicast a packet >>> you >>> were about to send >>> anyway, but if the timing isn=E2=80=99t close, you=E2=80=99re not wasti= ng multicast >>> bandwidth answering a single >>> node where nobody else cares. >>> >>> Overall, I=E2=80=99ve always thought that multicast response to RS was = kind of >>> silly. It=E2=80=99s probably most >>> harmful on WiFi. >>> >>> Owen >>> >>>> On Jul 21, 2015, at 02:33 , Andrew =F0=9F=91=BD Yourtchenko >>>> wrote: >>>> >>>> On 7/20/15, Erik Nordmark wrote: >>>>> On 7/17/15 9:34 AM, Fred Baker (fred) wrote: >>>>>>> So the next logical thing to do would be to have the router default >>>>>>> to >>>>>>> unicast Router Advertisements, measure the rate of received Router >>>>>>> Solicitations, and switch to multicast RA mode past a certain >>>>>>> threshold to cover this sort of situation. Once the number of RSes >>>>>>> falls, it switches back to unicast RA mode. >>>>>>> >>>>>>> That would get rid of the configuration knob proposed in this ID, >>>>>>> and >>>>>>> is behaviour that I think could be universal for all link types, >>>>>>> rather than just for the case of wireless ones with mobile devices. >>>>>> If it were me implementing it, I think I would go about this in a >>>>>> little >>>>>> different way, hopefully simpler. I would want to send at most one >>>>>> (e.g., >>>>>> either zero or one) RA per some interval (a second?). In the normal >>>>>> case, >>>>>> that is sent unicast. However, having sent a unicast RA at time t, i= f >>>>>> I >>>>>> now receive another RS before t+1, I send the next one (at time t+1) >>>>>> as >>>>>> a >>>>>> multicast. >>>>> >>>>> First of all I support this document as a WG document. >>>>> >>>>> But in terms of implementation, isn't it simpler to always(*) respond >>>>> to >>>>> a RS with a unicast RA? >>>> >>>> Yes. I did not respond on-list yet - but from operational perspective >>>> "always send solRA unicast" / "always send solRA multicast" definitely >>>> wins in my book, and I'd avoid premature optimizations (but maybe we >>>> can say the implementers are explicitly free to do their own >>>> optimizations if they see fit) >>>> >>>> That said, will be very interesting to hear data from folks who will >>>> run "all-unicast solRA", in real networks and then compare the effect >>>> of their proposal optimizations on their real-world scenarios. >>>> >>>>> As background, the text in RFC4861 comes from the old concern that al= l >>>>> devices might boot at the same time when the power is re-established >>>>> after a building power failure; that doesn't happen since most device= s >>>>> (laptops, smartphones, IoT devices) have batteries today. In that cas= e >>>>> it might have made sense to sending fewer RA messages by using >>>>> multicast. >>>>> >>>>> (*) the only case in RFC 4861 when I think a multicast response might >>>>> be >>>>> considered is when the source IPv6 address in the RS is the >>>>> unspecified >>>>> address. Further, an implementation which rate limits received RS >>>>> packets (e.g., CoPP in a router) might also want to detect when the >>>>> rate >>>>> limit might have dropped RS packets and multicast an RA in that case. >>>>> >>>>> >>>>> I do wonder why implementations haven't already changed to send >>>>> unicast >>>>> solicited RA, and whether it would make a difference if we have an >>>> >>>> TBH that's my concern as well. I think we should tweak the text in >>>> 4861 to encourage a bit more consideration on the implementer's side. >>>> >>>>> informational document asking them to do this. Alternatively we could >>>>> have a proposed standard which updates section 6.2.6 to change the >>>>> "MAY >>>>> unicast" to a "SHOULD unicast". >>>> >>>> Yeah, I actually have had the different text aimed for 6man, but >>>> Lorenzo's concern was 6man would say "there is no protocol update >>>> here, go away", so he rewrote it for v6ops. >>>> >>>> We should probably discuss this at the mic and get the opinion of the >>>> 6man chairs - if there is no outright "no" on this, a normative doc >>>> would be a better way to convince the implementers ? >>>> >>>>> >>>>> FWIW the draft incorrectly refers to section 6.2.4 instead of 6.2.6. >>>> >>>> Nice catch, thanks! >>>> >>>> --a >>>> >>>>> >>>>> Thanks, >>>>> Erik >>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 Jul 23 04:39:52 2015 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 E484A1AC41D; Thu, 23 Jul 2015 04:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZBZjbE3CGRt; Thu, 23 Jul 2015 04:39:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B47011A89B3; Thu, 23 Jul 2015 04:39:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.1.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150723113949.29435.87346.idtracker@ietfa.amsl.com> Date: Thu, 23 Jul 2015 04:39:49 -0700 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-reducing-ra-energy-consumption-00.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: Thu, 23 Jul 2015 11:39:51 -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 : Reducing energy consumption of Router Advertisements Authors : Andrew Yourtchenko Lorenzo Colitti Filename : draft-ietf-v6ops-reducing-ra-energy-consumption-00.txt Pages : 5 Date : 2015-07-23 Abstract: Frequent Router Advertisement messages can severely impact host power consumption. This document recommends operational practices to avoid such impact. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-reducing-ra-energy-consumption/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-v6ops-reducing-ra-energy-consumption-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 23 04:41:23 2015 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 0B1EF1A89B3 for ; Thu, 23 Jul 2015 04:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 MlwusE2o6nzs for ; Thu, 23 Jul 2015 04:41:20 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F8A21A854B for ; Thu, 23 Jul 2015 04:41:20 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 1627961CB; Thu, 23 Jul 2015 04:41:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=FwUbZPH+Vomc01ZoqKFC1SoCUII=; b= RSDwkAkICO0a5nuvK6A9lTJ5SKmRWMiGOHq6dv+SC7CbNVpBl2k8WDxpZx3V4JZG 85O7acgYNps1cdC8ckJ8lbnLhk39hKh35RugVvfZzgeLdAKAeM2dIoZaYjxriFdD SemegehX36tWdVuUGs1J7NIfMOVAFComCsB9DoWWmk0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=apq4kpf3oRrvCx8t3K9dK+tdof 3PRU8PEXy7MR/eLoDz7WU0TzjzVVIyMciGVwHnkT3y4Qoo/+nktLu5zUCheenXug fHlh6qcuklOLXvQRdasQn5q2Lc8FxxCMlBXNY+X/+TBtDtNyB5wXGD5HsQw00wAd LBCVKSCwozKYZGM0s= Received: from gomlefisk.localdomain (dhcp-a290.meeting.ietf.org [31.133.162.144]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 8DBDC61C9; Thu, 23 Jul 2015 04:41:18 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by gomlefisk.localdomain (Postfix) with ESMTP id 16B07498C400; Thu, 23 Jul 2015 04:33:11 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Content-Type: multipart/signed; boundary="Apple-Mail=_C48BE15C-F464-42C1-B01B-8F4A415623A8"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5 From: Ole Troan In-Reply-To: Date: Thu, 23 Jul 2015 04:33:10 -0700 Message-Id: <47B242F5-FFE7-4D68-8C22-968D044F532B@employees.org> References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> <55AD3B64.5070400@acm.org> <55B01B96.8090205@acm.org> To: Owen DeLong X-Mailer: Apple Mail (2.2102) Archived-At: Cc: v6ops list , "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 23 Jul 2015 11:41:22 -0000 --Apple-Mail=_C48BE15C-F464-42C1-B01B-8F4A415623A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Owen, >> Even on a flat wired L2 network I don't think it is harmful to = default to unicast solicited RAs. >>=20 >> If we take a worst case of 10000 hosts on the L2 network all = rebooting/initializing at the same time, we will see: >> - 10000 DAD probes for link-local address >> - 10000 MLD joins for the solicited node MC for their link-locals >=20 > As was pointed out earlier, we shouldn=E2=80=99t see MLD joins for LL = solicited nodes or any other LinkScoped group, unless I am badly = misunderstanding things. a quick wireshark on the IETF wireless shows lots of MLD for solicited = node multicast addresses as well as other link-scoped addresses. we put that in there under the assumption that we needed to, to deal = with MLD snooping switches. I=E2=80=99m not sure that assumption held = true. >> - 10000 RS messages(*) >> - 1/10000 RA messages >=20 > I think you mean 1 to 10000 because I don=E2=80=99t think fractional = messages are possible. >=20 >> - 10000 DAD probes for global addresses (N x 10000 if N prefixes = on-link) >> - N x 10000 mDNS etc type packets >>=20 >> (*) RFC 4861 suggests receiving an RA before an RS is sent, thus = under some timing conditions some RS messages might be avoided. >>=20 >> But at best we seem to be talking about saving 20% of the packet = during the boot of the 10000 hosts. >=20 > True=E2=80=A6 However, even if this is an actual concern, we could = consider a threshold in PPS where we send an RA Mcast response. >=20 > e.g. if more than 10 RS received in 1 second, send a multicast RA. >=20 > In fact, we could probably get away with delaying an RA response to RS = for 250ms. If another RS arrives during that delay, respond multicast, = else unicast. >=20 > That probably still eliminates most of the RA traffic, may eliminate = many of those 10000 RS messages, and could provide kind of the best of = both worlds. > I=E2=80=99m not sure how hard it would be to implement in silicon, = however. the issue isn=E2=80=99t necessarily link-utilisation. there are router control planes that would rate-limit 10000 RS messages = / second. I agree with Owen and I don=E2=80=99t think we can make a = blanket statement that RS replies should always be unicast. cheers, Ole --Apple-Mail=_C48BE15C-F464-42C1-B01B-8F4A415623A8 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 - https://gpgtools.org iQIcBAEBCgAGBQJVsND2AAoJEL7aWKiYQt92wjEQALHDs7a2lTx+mcizjD8VapzH 8QRs3mtuPN/sETfPiUF6Txn6R17rRmmmoO9RIrWvsMVzj+vFlWULT3eY5nArbp/W kGSXt6GjT3gG4o/iBIty+OG72MzlIPPdroE2DLgXI4gTvkhxqQweFOqvE+Z4YFK4 kELPp1WwRHYyO9CoI9jBviGwZgveShSk8ze8AzH3fPdt0EB62h3n4KpjkkniVU7T REJGpDymC/pz1IHbtMqmj/R6gcDbvLSIbDr6dm9zKAZ0/5BO1ttTTMHSXLyAD6cZ Mn2Fb8RrXWRK5nBoPp1EX5vvgt0IYHmted2syHiA0DrCqfTFN8GqndNIXpvPrdL4 3dBthzwbIECJcpfJq6HJYrijxP/yp+R+Te31ZXmGXEIPlpbfS/QyB63EmsSTD9y0 /zbM1NgzVy9GCn9+47RFeC4e8M2yHn4XpsJS4iKll76VHqtisdlRxIBViG3puJ+m amviMr9jyLxmhzAj9k+HFIErQjljpPE5pmrnHz+xNtWxz+FL0NXrpJuZbqxodHgh a2z+JA6hNkE2/WAUdhxSWSaAxdprSSge/vmlQonKilhnacbKWy2gnqSy4hlzz0MM dtwoae2QEybrW8eVNzl4NThQH1UGqGjrY2D9d7EWbdthIADI4aO7uw/w2P2J6vyr LmPIlng8qyg9CJAfe9HU =8KpN -----END PGP SIGNATURE----- --Apple-Mail=_C48BE15C-F464-42C1-B01B-8F4A415623A8-- From nobody Thu Jul 23 04:43:38 2015 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 BF7FC1AC438 for ; Thu, 23 Jul 2015 04:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5gEDHmGYXJR for ; Thu, 23 Jul 2015 04:43:34 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F23EA1AC43B for ; Thu, 23 Jul 2015 04:43:24 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6NBhKxf022422; Thu, 23 Jul 2015 13:43:20 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 480D82048EF; Thu, 23 Jul 2015 13:46:57 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 3E7B020279C; Thu, 23 Jul 2015 13:46:57 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.9]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6NBhJYq004685; Thu, 23 Jul 2015 13:43:20 +0200 To: Ole Troan References: <55AE42A4.8020908@gmail.com> <5CD05758-D7B7-476D-9936-E5A1D0614AF8@employees.org> From: Alexandru Petrescu Message-ID: <55B0D356.7070505@gmail.com> Date: Thu, 23 Jul 2015 13:43:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <5CD05758-D7B7-476D-9936-E5A1D0614AF8@employees.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ref Hosts dont MLD to join LL groups 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, 23 Jul 2015 11:43:36 -0000 Le 22/07/2015 14:27, Ole Troan a ĂŠcrit : >> Regarding the mic discussion about unicast RAs a SHOULD. >> >> I have been directed that the reference saying that Hosts dont MLD >> to join multicast groups is RFC3810: >> >> " The link-scope all-nodes multicast address, (FF02::1), is >> handled as a special case. On all nodes -- that is all hosts and >> routers, including multicast routers -- listening to packets >> destined to the all-nodes multicast address, from all sources, is >> permanently enabled on all interfaces on which multicast listening >> is supported. No MLD messages are ever sent regarding neither the >> link-scope all-nodes multicast address, nor any multicast address >> of scope 0 (reserved) or 1 (node-local).” > > I do wonder if we should expand that exception to all link-scope > multicast addresses. > I would beg to disagree. If we expand that to all link-scoped groups, may lead to dismantling IPv6 dependence on 33::1 - ff:ff:ff:ff:ff would be sufficient. My oppinion would rather be to modify the MLD RFC to mandate MLD joins for all scopes. Ethernet has primitives for joining the corresponding link-layer groups, and in some cases they are used. Maybe all should use them. > the bridge implementors I speak to tell me that they don’t have > enough state to do MLD snooping for link-local scoped multicast > addresses anyway... This may be dumb from my side, but why dont bridge implementers use link-layer multicast? They shouldnt implement MLD, and not snoop it. The Hosts should send the necessary link-layer multicast joins (triggered by themselves sending MLD REPORT for these groups) to the bridge addresses. Alex > cheers, Ole > From nobody Thu Jul 23 04:51:21 2015 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 268701A916F for ; Thu, 23 Jul 2015 04:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 8v9N4OCg_VfO for ; Thu, 23 Jul 2015 04:51:12 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99E6B1A9165 for ; Thu, 23 Jul 2015 04:51:12 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 6922F61CB; Thu, 23 Jul 2015 04:51:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=gIMcWm179c8BoD5bkxORQ1WmZE0=; b= gw4OGJ5u4j0J6fYgYDtlqjeWsgWhi14vMmH+KNTKJ9ZLMC1of/XRw30lAnNWklci w3YY/4DN0vNdyWoy1e8hY42MeEuZd0JBgnciNaOn1lFWQbo6KsODEC5TVhaDkGpW TD5hch7QBWXPHpUQLLTaAIMqYAOcLbSXSPakV9HSiLQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=i8LRMv39ESJWCs/v2ICduwscAY A1Kp5E9LJmCQwSN/fctb83+zfEAUpBoZ/zJbOvU/HymyBOFQQMkv4mxVU5MQcEad BUdJkxkRqhcbhTZEoZovKhPaCNzwDzQ6cJRgyyhqOYDoAFk5Rp9QGeM0JkGas1CR 4DwB0FxisJjQ2lhxc= Received: from gomlefisk.localdomain (dhcp-a290.meeting.ietf.org [31.133.162.144]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 2661761CA; Thu, 23 Jul 2015 04:51:11 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by gomlefisk.localdomain (Postfix) with ESMTP id D04CC498CBBF; Thu, 23 Jul 2015 04:51:34 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Content-Type: multipart/signed; boundary="Apple-Mail=_7A206960-3303-4B88-89CD-9C19D36808AC"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5 From: Ole Troan In-Reply-To: <55B0D356.7070505@gmail.com> Date: Thu, 23 Jul 2015 04:51:33 -0700 Message-Id: <6666FED5-227B-496F-B5F5-2883A12F9B96@employees.org> References: <55AE42A4.8020908@gmail.com> <5CD05758-D7B7-476D-9936-E5A1D0614AF8@employees.org> <55B0D356.7070505@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ref Hosts dont MLD to join LL groups 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, 23 Jul 2015 11:51:15 -0000 --Apple-Mail=_7A206960-3303-4B88-89CD-9C19D36808AC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Alexandru, I=E2=80=99m afraid I couldn=E2=80=99t interpret your message. would = someone else be able to translate? cheers, Ole >>=20 >> I do wonder if we should expand that exception to all link-scope >> multicast addresses. >>=20 >=20 > I would beg to disagree. >=20 > If we expand that to all link-scoped groups, may lead to dismantling = IPv6 dependence on 33::1 - ff:ff:ff:ff:ff would be sufficient. >=20 > My oppinion would rather be to modify the MLD RFC to mandate MLD joins = for all scopes. >=20 > Ethernet has primitives for joining the corresponding link-layer = groups, and in some cases they are used. Maybe all should use them. >=20 >> the bridge implementors I speak to tell me that they don=E2=80=99t = have >> enough state to do MLD snooping for link-local scoped multicast >> addresses anyway... >=20 > This may be dumb from my side, but why dont bridge implementers use = link-layer multicast? They shouldnt implement MLD, and not snoop it. = The Hosts should send the necessary link-layer multicast joins = (triggered by themselves sending MLD REPORT for these groups) to the = bridge addresses. >=20 > Alex >=20 >> cheers, Ole --Apple-Mail=_7A206960-3303-4B88-89CD-9C19D36808AC 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 - https://gpgtools.org iQIcBAEBCgAGBQJVsNVGAAoJEL7aWKiYQt925BQP/jubhibO3hZQCqp6ULFCfyfp QQBTWn/P96AGkWiyV5w557eyQ3qGLuT89DjPKBJjgVix8Y+rUASmd6ZEt4JpAJCd 8ATT+u5myAqM8JMhXy4FodCjjM40cngZDFMakMyB+JOg+dXGJkgdCYQgSxHc2qLD qZZ9Ya7ixVodVjO3RHkWwaYlDsoygO5xV84XJSHFy+3P0qbbo/1e8h79CT4whZWI GYHjOx9md1XErvEk4pG34cA95L+oJqejCnpUimskUWFAeeC8vb3+nVKJscdfqdjs LM65RJZZ3UdtA6bbi1WRCNaal6Rra5fmoUXexafFq9LgOhi6ay0kv45RsofDHv9K ONHco+DE4Mvkh5UCRHWbCRYIZtdIPWVxSEYwmZeCBauCrBHzuLNC/zU4+iXf3YEp CvQyHelAjkVikl0xQW0QjBaDbhARL4wP866e3lgAAHwL3ABAYvzlVujL02k5S5u8 1X5ytrvq0d3o8u8Mu8Oi17NNAcI1AEN3YDa19bmNgdGh22Kh2Q78vSUo0PkJdBVQ X0EgD49iQPX2LmDHeQ/l7d4eJjsyqwzrPWPLJR67XwhuG90dBzoB99DRAGn3FR30 upSYPfWncs1ymwP3yTsI2wIH7aM2DF1Zjo2wQZTS/Qjap/fhG7DIT+iS2ZFKfI/J O5eBKR7yWCpHniSTN32X =/2cL -----END PGP SIGNATURE----- --Apple-Mail=_7A206960-3303-4B88-89CD-9C19D36808AC-- From nobody Thu Jul 23 05:05:07 2015 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 C7C751A92E4 for ; Thu, 23 Jul 2015 05:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.475 X-Spam-Level: X-Spam-Status: No, score=-0.475 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 gvWImXdYIi36 for ; Thu, 23 Jul 2015 05:05:05 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF9E1A924B for ; Thu, 23 Jul 2015 05:05:04 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.15,530,1432612800"; d="scan'208";a="914726728" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 23 Jul 2015 07:58:15 -0400 Received: from PRVPEXVS10.corp.twcable.com ([10.136.163.41]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Thu, 23 Jul 2015 08:04:50 -0400 From: "George, Wes" To: IPv6 Ops WG Date: Thu, 23 Jul 2015 08:04:48 -0400 Thread-Topic: [sunset4] Meetecho recordings of SUNSET4 WG session Thread-Index: AdDFP8bzdQGqmCOmRY6CizvYzI3hjQ== Message-ID: References: <1612687302.5.1437583180864.JavaMail.tcastaldi@dell-tcastaldi> In-Reply-To: <1612687302.5.1437583180864.JavaMail.tcastaldi@dell-tcastaldi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.3.150624 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [v6ops] FW: [sunset4] Meetecho recordings of SUNSET4 WG session 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, 23 Jul 2015 12:05:07 -0000 U2luY2UgTWVldGVjaG8gdHJlYXRlZCB0aGUgZnVsbCBzZXNzaW9uIGFzIFN1bnNldDQsIHRoaXMg cmVjb3JkaW5nIGlzIGFsc28NCmZvciB2Nm9wcy4NCg0KVGhhbmtzLA0KDQpXZXMNCg0KDQoNCk9u IDcvMjIvMTUsIDEyOjM5IFBNLCAic3Vuc2V0NCBvbiBiZWhhbGYgb2YgTWVldGVjaG8gVGVhbSIN CjxzdW5zZXQ0LWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGlldGZAbWVldGVjaG8uY29t PiB3cm90ZToNCg0KPkRlYXIgYWxsLA0KPg0KPnRoZSBmdWxsIHJlY29yZGluZyAoc3luY2hyb25p emVkIHZpZGVvLCBhdWRpbywgc2xpZGVzIGFuZCBqYWJiZXIgcm9vbSkgb2YNCj50aGUNCj5TVU5T RVQ0IFdHIHNlc3Npb24gYXQgSUVURiA5MyBpcyBhdmFpbGFibGUgYXQgdGhlIGZvbGxvd2luZyBV Ukw6DQo+aHR0cDovL2lldGY5My5jb25mLm1lZXRlY2hvLmNvbS9pbmRleC5waHAvUmVjb3JkZWRf U2Vzc2lvbnMjU1VOU0VUNA0KPg0KPkluIGNhc2Ugb2YgcHJvYmxlbXMgd2l0aCB0aGUgcGxheW91 dCwganVzdCBkcm9wIGFuIGUtbWFpbCB0bw0KPmlldGYtc3VwcG9ydEBtZWV0ZWNoby5jb20uDQo+ DQo+Rm9yIHRoZSBjaGFpcihzKTogcGxlYXNlIGZlZWwgZnJlZSB0byBwdXQgdGhlIGxpbmsgdG8g dGhlIHJlY29yZGluZyBpbg0KPnRoZSBtaW51dGVzLA0KPmlmIHlvdSB0aGluayB0aGlzIG1pZ2h0 IGJlIHVzZWZ1bC4NCj4NCj5DaGVlcnMsDQo+dGhlIE1lZXRlY2hvIFRlYW0NCj4NCj4NCg0KDQpU aGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdh cm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwg Y29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvIGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBX YXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBv ZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5 b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJl IGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIGNv cHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5k IGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1h eSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3Is IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVs ZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueSBwcmlu dG91dC4NCg== From nobody Thu Jul 23 05:17:33 2015 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 A09CF1AC43C for ; Thu, 23 Jul 2015 05:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOR7ZiIy2bzg for ; Thu, 23 Jul 2015 05:17:30 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1557F1AC3B9 for ; Thu, 23 Jul 2015 05:16:48 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6NCGjO3026463; Thu, 23 Jul 2015 14:16:45 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E93772048C3; Thu, 23 Jul 2015 14:20:21 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id D1BCE201109; Thu, 23 Jul 2015 14:20:21 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.9]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6NCGhEJ013861; Thu, 23 Jul 2015 14:16:44 +0200 To: Ole Troan References: <55AE42A4.8020908@gmail.com> <5CD05758-D7B7-476D-9936-E5A1D0614AF8@employees.org> <55B0D356.7070505@gmail.com> <6666FED5-227B-496F-B5F5-2883A12F9B96@employees.org> From: Alexandru Petrescu Message-ID: <55B0DB2B.1030703@gmail.com> Date: Thu, 23 Jul 2015 14:16:43 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <6666FED5-227B-496F-B5F5-2883A12F9B96@employees.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] ref Hosts dont MLD to join LL groups 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, 23 Jul 2015 12:17:31 -0000 If one disallows all MLD joins for all link-scoped IP multicast addresses - why does one need IP multicast addresses with link scope? Why does one need the lino-layer 33::1 address? If one doesnt need 33::1 then why Ethernet provides it? I guess what I am trying to say is that it's useless to have multicast groups if one can't join them. Alex Le 23/07/2015 13:51, Ole Troan a ĂŠcrit : > Alexandru, > > I’m afraid I couldn’t interpret your message. would someone else be able to translate? > > cheers, > Ole > >>> >>> I do wonder if we should expand that exception to all link-scope >>> multicast addresses. >>> >> >> I would beg to disagree. >> >> If we expand that to all link-scoped groups, may lead to dismantling IPv6 dependence on 33::1 - ff:ff:ff:ff:ff would be sufficient. >> >> My oppinion would rather be to modify the MLD RFC to mandate MLD joins for all scopes. >> >> Ethernet has primitives for joining the corresponding link-layer groups, and in some cases they are used. Maybe all should use them. >> >>> the bridge implementors I speak to tell me that they don’t have >>> enough state to do MLD snooping for link-local scoped multicast >>> addresses anyway... >> >> This may be dumb from my side, but why dont bridge implementers use link-layer multicast? They shouldnt implement MLD, and not snoop it. The Hosts should send the necessary link-layer multicast joins (triggered by themselves sending MLD REPORT for these groups) to the bridge addresses. >> >> Alex >> >>> cheers, Ole > From nobody Thu Jul 23 05:27:15 2015 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 328231A1A98 for ; Thu, 23 Jul 2015 05:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 vOClAZXJYnhF for ; Thu, 23 Jul 2015 05:27:12 -0700 (PDT) Received: from mx1.ernw.net (mx1.ernw.net [62.159.96.78]) (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 E05931A0BE8 for ; Thu, 23 Jul 2015 05:27:11 -0700 (PDT) Received: from mh1.ernw.net (unknown [172.31.1.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mh1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx1.ernw.net (Postfix) with ESMTPS id DD5A215EC2E for ; Thu, 23 Jul 2015 14:29:22 +0200 (CEST) Received: from ws25.ernw.net (ws25.ernw.net [172.31.100.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "ws25.ernw.net", Issuer "ernw ca1" (verified OK)) by mh1.ernw.net (Postfix) with ESMTPS id 64F435D5 for ; Thu, 23 Jul 2015 14:27:10 +0200 (CEST) Received: by ws25.ernw.net (Postfix, from userid 1001) id 4AF43C4878; Thu, 23 Jul 2015 14:27:10 +0200 (CEST) Date: Thu, 23 Jul 2015 14:27:10 +0200 From: Enno Rey To: v6ops@ietf.org Message-ID: <20150723122710.GX57117@ernw.de> References: <55AE42A4.8020908@gmail.com> <5CD05758-D7B7-476D-9936-E5A1D0614AF8@employees.org> <55B0D356.7070505@gmail.com> <6666FED5-227B-496F-B5F5-2883A12F9B96@employees.org> <55B0DB2B.1030703@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55B0DB2B.1030703@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [v6ops] ref Hosts dont MLD to join LL groups 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, 23 Jul 2015 12:27:14 -0000 Hi, On Thu, Jul 23, 2015 at 02:16:43PM +0200, Alexandru Petrescu wrote: > If one disallows all MLD joins for all link-scoped IP multicast > addresses - why does one need IP multicast addresses with link scope? > > Why does one need the lino-layer 33::1 address? > > If one doesnt need 33::1 then why Ethernet provides it? > > I guess what I am trying to say is that it's useless to have multicast > groups if one can't join them. define "join a multicast group"... strictly speaking MLD as a whole is only needed for interdomain multicast anyway. on the local link you join a MC group by kind-of self declaration ("hey I consider myself part of that group so I'm interested in certain traffic and hence instruct my stack to listen to/process packets with certain addresses"). no need of MLD for that action. but "joining" on the local-link doesn't need MLD. best Enno > > Alex > > Le 23/07/2015 13:51, Ole Troan a ??crit : > > Alexandru, > > > > I???m afraid I couldn???t interpret your message. would someone else be able to translate? > > > > cheers, > > Ole > > > >>> > >>> I do wonder if we should expand that exception to all link-scope > >>> multicast addresses. > >>> > >> > >> I would beg to disagree. > >> > >> If we expand that to all link-scoped groups, may lead to dismantling IPv6 dependence on 33::1 - ff:ff:ff:ff:ff would be sufficient. > >> > >> My oppinion would rather be to modify the MLD RFC to mandate MLD joins for all scopes. > >> > >> Ethernet has primitives for joining the corresponding link-layer groups, and in some cases they are used. Maybe all should use them. > >> > >>> the bridge implementors I speak to tell me that they don???t have > >>> enough state to do MLD snooping for link-local scoped multicast > >>> addresses anyway... > >> > >> This may be dumb from my side, but why dont bridge implementers use link-layer multicast? They shouldnt implement MLD, and not snoop it. The Hosts should send the necessary link-layer multicast joins (triggered by themselves sending MLD REPORT for these groups) to the bridge addresses. > >> > >> Alex > >> > >>> cheers, Ole > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From nobody Thu Jul 23 05:49:27 2015 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 345EE1AC430 for ; Thu, 23 Jul 2015 05:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjf5Bs4Dphia for ; Thu, 23 Jul 2015 05:49:18 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A0221A0155 for ; Thu, 23 Jul 2015 05:49:12 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6NCnASh022149 for ; Thu, 23 Jul 2015 14:49:10 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 83E3C204B51 for ; Thu, 23 Jul 2015 14:52:47 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 7BF44204B4D for ; Thu, 23 Jul 2015 14:52:47 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.9]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6NCn9jK024772 for ; Thu, 23 Jul 2015 14:49:10 +0200 To: v6ops@ietf.org References: <55AE42A4.8020908@gmail.com> <5CD05758-D7B7-476D-9936-E5A1D0614AF8@employees.org> <55B0D356.7070505@gmail.com> <6666FED5-227B-496F-B5F5-2883A12F9B96@employees.org> <55B0DB2B.1030703@gmail.com> <20150723122710.GX57117@ernw.de> From: Alexandru Petrescu Message-ID: <55B0E2C5.2060309@gmail.com> Date: Thu, 23 Jul 2015 14:49:09 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150723122710.GX57117@ernw.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] ref Hosts dont MLD to join LL groups 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, 23 Jul 2015 12:49:24 -0000 Le 23/07/2015 14:27, Enno Rey a écrit : > Hi, > > On Thu, Jul 23, 2015 at 02:16:43PM +0200, Alexandru Petrescu wrote: >> If one disallows all MLD joins for all link-scoped IP multicast >> addresses - why does one need IP multicast addresses with link >> scope? >> >> Why does one need the lino-layer 33::1 address? >> >> If one doesnt need 33::1 then why Ethernet provides it? >> >> I guess what I am trying to say is that it's useless to have >> multicast groups if one can't join them. > > define "join a multicast group"... Inform the sender willingnes to be part of the group. If not part of group, then sender will not send it. Same concept at L2 and at L3. > strictly speaking MLD as a whole is only needed for interdomain > multicast anyway. Disagree - beyond just interdomain multicast, Ethernet has link-layer multicast builtin. There is no 'broadcast' address anymore in Ethernet since some time, replaced by 'multicast': supposedly better at saving battery and other advantages. > on the local link you join a MC group by kind-of self declaration > ("hey I consider myself part of that group That is an Ethernet message. Some cards send that message, others don't. All should. > so I'm interested in > certain traffic and hence instruct my stack to listen to/process > packets with certain addresses"). no need of MLD for that action. How does the Ethernet layer know this is a Router, and not a Host? Only by knowing that it can join the all-hosts or all-routers link-layer address. And only the IP stack knows whether it's a Host or a Router. So the IP stack should tell the Ethernet layer to make that link-layer join. Yours, Alex > but > "joining" on the local-link doesn't need MLD. > > best > > Enno > > > > > >> >> Alex >> >> Le 23/07/2015 13:51, Ole Troan a ??crit : >>> Alexandru, >>> >>> I???m afraid I couldn???t interpret your message. would someone >>> else be able to translate? >>> >>> cheers, Ole >>> >>>>> >>>>> I do wonder if we should expand that exception to all >>>>> link-scope multicast addresses. >>>>> >>>> >>>> I would beg to disagree. >>>> >>>> If we expand that to all link-scoped groups, may lead to >>>> dismantling IPv6 dependence on 33::1 - ff:ff:ff:ff:ff would be >>>> sufficient. >>>> >>>> My oppinion would rather be to modify the MLD RFC to mandate >>>> MLD joins for all scopes. >>>> >>>> Ethernet has primitives for joining the corresponding >>>> link-layer groups, and in some cases they are used. Maybe all >>>> should use them. >>>> >>>>> the bridge implementors I speak to tell me that they don???t >>>>> have enough state to do MLD snooping for link-local scoped >>>>> multicast addresses anyway... >>>> >>>> This may be dumb from my side, but why dont bridge >>>> implementers use link-layer multicast? They shouldnt implement >>>> MLD, and not snoop it. The Hosts should send the necessary >>>> link-layer multicast joins (triggered by themselves sending MLD >>>> REPORT for these groups) to the bridge addresses. >>>> >>>> Alex >>>> >>>>> cheers, Ole >>> >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Jul 23 06:01:57 2015 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 7964D1AC3CE for ; Thu, 23 Jul 2015 06:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 iW3EvyAw7RDQ for ; Thu, 23 Jul 2015 06:01:53 -0700 (PDT) Received: from mx1.ernw.net (mx1.ernw.net [62.159.96.78]) (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 9B05E1A0173 for ; Thu, 23 Jul 2015 06:01:53 -0700 (PDT) Received: from mh1.ernw.net (unknown [IPv6:fd00:2001:0:d001::10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mh1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx1.ernw.net (Postfix) with ESMTPS id A046A15EC2E for ; Thu, 23 Jul 2015 15:04:04 +0200 (CEST) Received: from ws25.ernw.net (ws25.ernw.net [172.31.100.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "ws25.ernw.net", Issuer "ernw ca1" (verified OK)) by mh1.ernw.net (Postfix) with ESMTPS id 305EF5F8 for ; Thu, 23 Jul 2015 15:01:52 +0200 (CEST) Received: by ws25.ernw.net (Postfix, from userid 1001) id 0D89BC4878; Thu, 23 Jul 2015 15:01:52 +0200 (CEST) Date: Thu, 23 Jul 2015 15:01:52 +0200 From: Enno Rey To: v6ops@ietf.org Message-ID: <20150723130151.GA57117@ernw.de> References: <55AE42A4.8020908@gmail.com> <5CD05758-D7B7-476D-9936-E5A1D0614AF8@employees.org> <55B0D356.7070505@gmail.com> <6666FED5-227B-496F-B5F5-2883A12F9B96@employees.org> <55B0DB2B.1030703@gmail.com> <20150723122710.GX57117@ernw.de> <55B0E2C5.2060309@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55B0E2C5.2060309@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [v6ops] ref Hosts dont MLD to join LL groups 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, 23 Jul 2015 13:01:56 -0000 Hi, > > Inform the sender willingnes to be part of the group. If not part of > group, then sender will not send it. Same concept at L2 and at L3. wrong. the sender of a MC message just sends it out, regardless if somebody listens or not. the router(s) helping to distribute this message (in case of interdomain MC) only have to know (= are interested) if there's at least one interested listener on an adjacent link. neither the sender nor the router(s) have any interest (or need to have that) in individual listeners. > > > > strictly speaking MLD as a whole is only needed for interdomain > > multicast anyway. > > Disagree - beyond just interdomain multicast, Ethernet has link-layer > multicast builtin. There is no 'broadcast' address anymore in Ethernet > since some time, replaced by 'multicast': supposedly better at saving > battery and other advantages. > > > on the local link you join a MC group by kind-of self declaration > > ("hey I consider myself part of that group > > That is an Ethernet message. no. that's a decision taken somewhere in the software/stack. no need for any packet here. > > Some cards send that message, others don't. All should. > > > so I'm interested in > > certain traffic and hence instruct my stack to listen to/process > > packets with certain addresses"). no need of MLD for that action. > > How does the Ethernet layer know this is a Router, and not a Host? Only > by knowing that it can join the all-hosts or all-routers link-layer > address. And only the IP stack knows whether it's a Host or a Router. > So the IP stack should tell the Ethernet layer to make that link-layer join. which it does, as a stack-internal decision. "once I'm a router get me everything sent to ff02::1/33:33:00:00:00:01. in addition - given I'm a node anyway - get me everything for ff02::2". no need to send any packet for all this. best Enno > > Yours, > > Alex > > > but > > "joining" on the local-link doesn't need MLD. > > > > best > > > > Enno > > > > > > > > > > > >> > >> Alex > >> > >> Le 23/07/2015 13:51, Ole Troan a ??crit : > >>> Alexandru, > >>> > >>> I???m afraid I couldn???t interpret your message. would someone > >>> else be able to translate? > >>> > >>> cheers, Ole > >>> > >>>>> > >>>>> I do wonder if we should expand that exception to all > >>>>> link-scope multicast addresses. > >>>>> > >>>> > >>>> I would beg to disagree. > >>>> > >>>> If we expand that to all link-scoped groups, may lead to > >>>> dismantling IPv6 dependence on 33::1 - ff:ff:ff:ff:ff would be > >>>> sufficient. > >>>> > >>>> My oppinion would rather be to modify the MLD RFC to mandate > >>>> MLD joins for all scopes. > >>>> > >>>> Ethernet has primitives for joining the corresponding > >>>> link-layer groups, and in some cases they are used. Maybe all > >>>> should use them. > >>>> > >>>>> the bridge implementors I speak to tell me that they don???t > >>>>> have enough state to do MLD snooping for link-local scoped > >>>>> multicast addresses anyway... > >>>> > >>>> This may be dumb from my side, but why dont bridge > >>>> implementers use link-layer multicast? They shouldnt implement > >>>> MLD, and not snoop it. The Hosts should send the necessary > >>>> link-layer multicast joins (triggered by themselves sending MLD > >>>> REPORT for these groups) to the bridge addresses. > >>>> > >>>> Alex > >>>> > >>>>> cheers, Ole > >>> > >> > >> _______________________________________________ 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 -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From nobody Thu Jul 23 06:10:38 2015 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 56B851A026E for ; Thu, 23 Jul 2015 06:10:37 -0700 (PDT) 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 CCs-2AFnvGbI for ; Thu, 23 Jul 2015 06:10:36 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAAA61A00EE for ; Thu, 23 Jul 2015 06:10:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1851; q=dns/txt; s=iport; t=1437657035; x=1438866635; h=from:to:subject:date:message-id:mime-version; bh=xGoFNvYEPAIUk19LAV1HfkbCMk7hwZufBuB9Vl3lTFw=; b=ahaSf1idK+jqQ9FjpD3z1w6RXLwT+YztXZGjdmjdufolRk7eqntUa+Qx M+KPnaffdslKPkVOxK2YtRg9ofuaMsYaRuUR2KCWzQHZm1gWiUJCsDMzu QBDVORpE4kEQKTFTgV/JRN3OqxS44BMJ4/VXd5zmxKvWLIyQrmqoeRU+d Y=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AiAwCE57BV/4oNJK1cgxVUb7teCYF3h0k4FAEBAQEBAQGBCoQqgQsBgQAnBCGIIA2lNaYBAQEBAQEBBAEBAQEBAQEBARUEk3GBFAWUYAGCNoFXaIdEAYFDhy2QKiaDfII2gQQBAQE X-IronPort-AV: E=Sophos;i="5.15,530,1432598400"; d="asc'?scan'208";a="14275047" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-6.cisco.com with ESMTP; 23 Jul 2015 13:10:13 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t6NDADDL003819 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 23 Jul 2015 13:10:13 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.49]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Thu, 23 Jul 2015 08:10:13 -0500 From: "Fred Baker (fred)" To: v6ops list Thread-Topic: As promised... Thread-Index: AQHQxUjo4qd1bH7KWEePbHjqAVDWAg== Date: Thu, 23 Jul 2015 13:10:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.61.91.41] Content-Type: multipart/signed; boundary="Apple-Mail=_3E7B8DFA-8F15-40E8-9E5C-39946CD72C4F"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: [v6ops] As promised... 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, 23 Jul 2015 13:10:37 -0000 --Apple-Mail=_3E7B8DFA-8F15-40E8-9E5C-39946CD72C4F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii h= ttps://tools.ietf.org/html/draft-ietf-v6ops-reducing-ra-energy-consumption= "Reducing energy consumption of Router Advertisements", Andrew Yourtchenko, Lorenzo Colitti, 2015-07-23, We had quite a bit of discussion Tuesday, especially considering the = length (or brevity) of this draft. I'd suggest you read it. Especially given the number of "+2" comments on = the list, I tend to think we can come to consensus relatively quickly on = it. If there are lingering issues, let's get them out of the way. --Apple-Mail=_3E7B8DFA-8F15-40E8-9E5C-39946CD72C4F 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 iQIVAwUBVbDns0ayAOS/EQ8MAQIvhxAAog4vnpDZBcTlXU0vBBgoeuWjZTgehsLY NHKp4hS5Zym8eCfv6PGtqME0lAul6gXiKr06MMAglY+NKLeuq+NORhRPrX9QsEU7 3Y2haU2ijznkVESnQG0rivOysx20bdltgbLcHIOVIr0f+F6q/AJ8DjtyPablKHfR o0788n2lHdw1kIT37Ch0onFlT3prmT4xQpcRUFg6eMkwUls3nGqLFgElW74aFcnk a0Vd1nhtBQJK6YuoMaaicb6t2tOdQXAzkQ3ZG+Hl403rGrpQKCbI8gMn5kt6MwqU A84lSAJ2tb1B9DIQJ1lJLQ4pZBIPv2W73aZF+Y12GJMg/jnnld10s3q6wqyQIAgc 4MLrg2CLq4gdzAqFXtcwNNdGEUJt0tvB4UOaU5+Azncb/jLmcwN12UZXbBNHSjLg 85FhznJV2w0FiC15GqyJZ/DgMrjzfwLIYR5INMTKgj6NK7zPrlocnSIicdgZO1Rv E9G2n4cMPQMI8KdRU58a5kGBF1ChkrFR+TVj+/IfRyOscgX7i7DXBnklP0ordi+S kxGvfhzoUpz4yjDOTq1OIiT6NxtS0DRfzaAVsks7rCQkOAtA4SFsOaUU/Ukyhlkg 1Ibfcw4Q4HeTqBBrpThRTNmAWD4H+g3WN90x9U3C2/fE4aK+vyEUa8NxnxwUtl+V +KP5FjQzkKI= =lUCT -----END PGP SIGNATURE----- --Apple-Mail=_3E7B8DFA-8F15-40E8-9E5C-39946CD72C4F-- From nobody Thu Jul 23 06:41:21 2015 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 0AC4B1ACD1C; Thu, 23 Jul 2015 06:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 CNzfuEtDh7vd; Thu, 23 Jul 2015 06:41:13 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 84A491A21A0; Thu, 23 Jul 2015 06:41:06 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id CBBAC18046F; Thu, 23 Jul 2015 06:37:08 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150723133708.CBBAC18046F@rfc-editor.org> Date: Thu, 23 Jul 2015 06:37:08 -0700 (PDT) Archived-At: Cc: v6ops@ietf.org, rfc-editor@rfc-editor.org Subject: [v6ops] BCP 198, RFC 7608 on IPv6 Prefix Length Recommendation for Forwarding 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, 23 Jul 2015 13:41:20 -0000 A new Request for Comments is now available in online RFC libraries. BCP 198 RFC 7608 Title: IPv6 Prefix Length Recommendation for Forwarding Author: M. Boucadair, A. Petrescu, F. Baker Status: Best Current Practice Stream: IETF Date: July 2015 Mailbox: mohamed.boucadair@orange.com, alexandre.petrescu@cea.fr, fred@cisco.com Pages: 6 Characters: 10818 See Also: BCP 198 I-D Tag: draft-ietf-v6ops-cidr-prefix-03.txt URL: https://www.rfc-editor.org/info/rfc7608 DOI: http://dx.doi.org/10.17487/RFC7608 IPv6 prefix length, as in IPv4, is a parameter conveyed and used in IPv6 routing and forwarding processes in accordance with the Classless Inter-domain Routing (CIDR) architecture. The length of an IPv6 prefix may be any number from zero to 128, although subnets using stateless address autoconfiguration (SLAAC) for address allocation conventionally use a /64 prefix. Hardware and software implementations of routing and forwarding should therefore impose no rules on prefix length, but implement longest-match-first on prefixes of any valid length. This document is a product of the IPv6 Operations Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. 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 Thu Jul 23 06:59:30 2015 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 08CBC1ACD9B for ; Thu, 23 Jul 2015 06:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdYLNwGAMZhe for ; Thu, 23 Jul 2015 06:59:27 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450: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 718891ACCF8 for ; Thu, 23 Jul 2015 06:59:27 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so209849934wib.0 for ; Thu, 23 Jul 2015 06:59:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=XPQaY2Q7sT+uVimmIfV4HAo4ZCvk04+0ZJRuHSvEWrY=; b=UjBe6icQYAhj9sG0auSgwPLR2wCTuiTE+Qkd8WsczaQ4VrVi7cHXxvgzgigF91n0xd RVImaaZiOeNFNLjQB7N5d01p5ke12giJATk8kNxRurBMdQ7G6rrLHKQ/7MWMbS/M4BYh eBovo4KUWO1ZaxImrYbiLFSwqNpiJ+vi6Qqy60+GpSAUKPvVRumDYoRmQnj1/TYJwXQV f+tR52BMVVC+Byda0Evk+zHMEuXAsBvieCmDRQfK0X5twyL9HXNqgx2cykRWQY9f35KK u1EhoTGjv9+p99mi5668atSjVXeYJ2d04iD+actWBT76lUO0ObGaJ4/RNSTizVgIRMQL OkzQ== X-Received: by 10.194.185.180 with SMTP id fd20mr15469621wjc.16.1437659966215; Thu, 23 Jul 2015 06:59:26 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:28cc:dc4c:9703:6781? ([2001:67c:370:176:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id ho10sm7667943wjb.39.2015.07.23.06.59.24 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Jul 2015 06:59:25 -0700 (PDT) Message-ID: <55B0F344.4090005@gmail.com> Date: Fri, 24 Jul 2015 01:59:32 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ted Lemon References: <55B09AE5.4040609@gmail.com> <2BBE839B-37FB-4EA2-982E-58028E7A13B6@nominum.com> In-Reply-To: <2BBE839B-37FB-4EA2-982E-58028E7A13B6@nominum.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] NAT64/DNS64 and DNSSEC 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, 23 Jul 2015 13:59:29 -0000 On 23/07/2015 22:30, Ted Lemon wrote: > On Jul 23, 2015, at 3:42 AM, Brian E Carpenter wrote: >> Read RFC 6147 - it covers this issue, and points out that >> "The main drawback of this mode is its >> deployability, since it requires changes in the end hosts." >=20 > I think Mikael is asking for a stronger statement than =E2=80=9Cyou cou= ld do this, but probably won=E2=80=99t.=E2=80=9D >=20 > I think this would take the form of a document describing recommendatio= ns for DNSSEC-aware stub resolvers, which I don=E2=80=99t think currently= exists, and hence could in theory be worked on. No, afaik it doesn't exist. I'm not certain that it needs to exist, thoug= h. Would it specify anything that isn't already specified? The code needs to exist. Brian From nobody Thu Jul 23 07:05:46 2015 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 EFCB31ACD4C for ; Thu, 23 Jul 2015 07:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 y8cdi40qWziq for ; Thu, 23 Jul 2015 07:05:43 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (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 ED9BB1A1A67 for ; Thu, 23 Jul 2015 07:05:42 -0700 (PDT) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id D7073DA007A; Thu, 23 Jul 2015 14:05:42 +0000 (UTC) Received: from [10.0.20.218] (71.233.41.235) by CAS-03.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.224.2; Thu, 23 Jul 2015 07:05:42 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_2EB44565-9442-47B9-A595-A5D4EBACBD9A" MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ted Lemon In-Reply-To: <55B0F344.4090005@gmail.com> Date: Thu, 23 Jul 2015 10:05:40 -0400 Message-ID: References: <55B09AE5.4040609@gmail.com> <2BBE839B-37FB-4EA2-982E-58028E7A13B6@nominum.com> <55B0F344.4090005@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.2102) X-Originating-IP: [71.233.41.235] Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] NAT64/DNS64 and DNSSEC 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, 23 Jul 2015 14:05:45 -0000 --Apple-Mail=_2EB44565-9442-47B9-A595-A5D4EBACBD9A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Jul 23, 2015, at 9:59 AM, Brian E Carpenter = wrote: > No, afaik it doesn't exist. I'm not certain that it needs to exist, = though. > Would it specify anything that isn't already specified? A document that says how to implement a DNSSEC stub resolver and talks = about all the cases you need to handle might be useful, but probably = ought to be written as part of an implementation exercise with testing = and a list of the applicable use cases (the types of networks you might = connect to) to inform it. > The code needs to exist. Yes. However, I am not convinced that it would be obvious to an = implementor who hasn=E2=80=99t been through the transition mechanism = wars what set of behaviors to implement in order to fully support it. --Apple-Mail=_2EB44565-9442-47B9-A595-A5D4EBACBD9A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" On Jul 23, 2015, at 9:59 AM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
No, afaik it doesn't exist. I'm not certain that = it needs to exist, though.
Would it specify anything = that isn't already specified?

A document that says how to implement a = DNSSEC stub resolver and talks about all the cases you need to handle = might be useful, but probably ought to be written as part of an = implementation exercise with testing and a list of the applicable use = cases (the types of networks you might connect to) to inform = it.

The code needs to exist.

Yes.   = However, I am not convinced that it would be obvious to an implementor = who hasn=E2=80=99t been through the transition mechanism wars what set = of behaviors to implement in order to fully support it.

= --Apple-Mail=_2EB44565-9442-47B9-A595-A5D4EBACBD9A-- From nobody Thu Jul 23 07:34:56 2015 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 C5A8F1ACE1B for ; Thu, 23 Jul 2015 07:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqcrT1JVGEJS for ; Thu, 23 Jul 2015 07:34:50 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BB1A1A8758 for ; Thu, 23 Jul 2015 07:34:47 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6NEYj5i016919 for ; Thu, 23 Jul 2015 16:34:45 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9032F204C51 for ; Thu, 23 Jul 2015 16:38:22 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 88789204C09 for ; Thu, 23 Jul 2015 16:38:22 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.59]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6NEYikf015821 for ; Thu, 23 Jul 2015 16:34:45 +0200 To: v6ops@ietf.org References: <55AE42A4.8020908@gmail.com> <5CD05758-D7B7-476D-9936-E5A1D0614AF8@employees.org> <55B0D356.7070505@gmail.com> <6666FED5-227B-496F-B5F5-2883A12F9B96@employees.org> <55B0DB2B.1030703@gmail.com> <20150723122710.GX57117@ernw.de> <55B0E2C5.2060309@gmail.com> <20150723130151.GA57117@ernw.de> From: Alexandru Petrescu Message-ID: <55B0FB82.9070809@gmail.com> Date: Thu, 23 Jul 2015 16:34:42 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150723130151.GA57117@ernw.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] ref Hosts dont MLD to join LL groups 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, 23 Jul 2015 14:34:54 -0000 Le 23/07/2015 15:01, Enno Rey a écrit : > Hi, > >> >> Inform the sender willingnes to be part of the group. If not part >> of group, then sender will not send it. Same concept at L2 and at >> L3. > > wrong. the sender of a MC message just sends it out, regardless if > somebody listens or not. I agree. > the router(s) helping to distribute this message (in case of > interdomain MC) only have to know (= are interested) if there's at > least one interested listener on an adjacent link. neither the > sender nor the router(s) have any interest (or need to have that) in > individual listeners. YEs, that's so for multicast across multiple subnets. But on the same link (same subnet) the Router sends these RAs, so it must be able to know which Host would like to receive its multicasted RAs. >>> strictly speaking MLD as a whole is only needed for interdomain >>> multicast anyway. >> >> Disagree - beyond just interdomain multicast, Ethernet has >> link-layer multicast builtin. There is no 'broadcast' address >> anymore in Ethernet since some time, replaced by 'multicast': >> supposedly better at saving battery and other advantages. >> >>> on the local link you join a MC group by kind-of self declaration >>> ("hey I consider myself part of that group >> >> That is an Ethernet message. > > no. that's a decision taken somewhere in the software/stack. no need > for any packet here. Well. I cant put my wireshark in monitor mode right now but if I could I would tell the name of the Ethernet message on WiFi (a management frame) which joins link-layer multicast. >> Some cards send that message, others don't. All should. >> >>> so I'm interested in certain traffic and hence instruct my stack >>> to listen to/process packets with certain addresses"). no need >>> of MLD for that action. >> >> How does the Ethernet layer know this is a Router, and not a Host? >> Only by knowing that it can join the all-hosts or all-routers >> link-layer address. And only the IP stack knows whether it's a >> Host or a Router. So the IP stack should tell the Ethernet layer >> to make that link-layer join. > > which it does, as a stack-internal decision. "once I'm a router get > me everything sent to ff02::1/33:33:00:00:00:01. in addition - given > I'm a node anyway - get me everything for ff02::2". no need to send > any packet for all this. In that same way, the Host must be able to tell everybody else whether or that Host is interested in receiving the multicasted RAs. Alex > > best > > Enno > > > > > >> >> Yours, >> >> Alex >> >>> but "joining" on the local-link doesn't need MLD. >>> >>> best >>> >>> Enno >>> >>> >>> >>> >>> >>>> >>>> Alex >>>> >>>> Le 23/07/2015 13:51, Ole Troan a ??crit : >>>>> Alexandru, >>>>> >>>>> I???m afraid I couldn???t interpret your message. would >>>>> someone else be able to translate? >>>>> >>>>> cheers, Ole >>>>> >>>>>>> >>>>>>> I do wonder if we should expand that exception to all >>>>>>> link-scope multicast addresses. >>>>>>> >>>>>> >>>>>> I would beg to disagree. >>>>>> >>>>>> If we expand that to all link-scoped groups, may lead to >>>>>> dismantling IPv6 dependence on 33::1 - ff:ff:ff:ff:ff >>>>>> would be sufficient. >>>>>> >>>>>> My oppinion would rather be to modify the MLD RFC to >>>>>> mandate MLD joins for all scopes. >>>>>> >>>>>> Ethernet has primitives for joining the corresponding >>>>>> link-layer groups, and in some cases they are used. Maybe >>>>>> all should use them. >>>>>> >>>>>>> the bridge implementors I speak to tell me that they >>>>>>> don???t have enough state to do MLD snooping for >>>>>>> link-local scoped multicast addresses anyway... >>>>>> >>>>>> This may be dumb from my side, but why dont bridge >>>>>> implementers use link-layer multicast? They shouldnt >>>>>> implement MLD, and not snoop it. The Hosts should send the >>>>>> necessary link-layer multicast joins (triggered by >>>>>> themselves sending MLD REPORT for these groups) to the >>>>>> bridge addresses. >>>>>> >>>>>> Alex >>>>>> >>>>>>> cheers, Ole >>>>> >>>> >>>> _______________________________________________ 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 Jul 23 08:16:29 2015 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 ADFE31A03AB for ; Thu, 23 Jul 2015 08:16:27 -0700 (PDT) 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 Xyn0G0sttUQN for ; Thu, 23 Jul 2015 08:16:26 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0642F1A1B74 for ; Thu, 23 Jul 2015 08:16:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVM83095; Thu, 23 Jul 2015 15:16:23 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 23 Jul 2015 16:16:23 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.154]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Thu, 23 Jul 2015 23:16:19 +0800 From: "Liubing (Leo)" To: Brian E Carpenter , Alexandru Petrescu , "v6ops@ietf.org" Thread-Topic: [v6ops] Discussion of draft-ietf-v6ops-ula-usage-recommendations Thread-Index: AQHQw73WnPgrOvjAyEyawMXgVWiTmp3lcsaAgAAJwYCAA7AQAA== Date: Thu, 23 Jul 2015 15:16:19 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2247D33@nkgeml506-mbx.china.huawei.com> References: <6153A91F-7E9A-4579-BA06-72964568D343@cisco.com> <55AE54D3.7070502@gmail.com> <55AE5D01.5090309@gmail.com> In-Reply-To: <55AE5D01.5090309@gmail.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.70.67] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] Discussion of draft-ietf-v6ops-ula-usage-recommendations 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, 23 Jul 2015 15:16:27 -0000 SGkgQnJpYW4sDQoNCj4gQW55d2F5IC0gSSdkIGxpa2UgdG8gc2VlIHRoZSBkcmFmdCBwcm9ncmVz cy4gSGFzIGl0IGFscmVhZHkgaGFkIGEgV0dMQz8gDQoNCk5vdCB5ZXQuIEhvcGUgaXQgY291bGQg YmUgbGF1bmNoZWQgbGF0ZXIuDQoNCkJlc3QgcmVnYXJkcywNCkJpbmcNCg== From nobody Thu Jul 23 09:26:10 2015 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 BEA8D1A00C3 for ; Thu, 23 Jul 2015 09:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 WQyQ2tWGkPau for ; Thu, 23 Jul 2015 09:25:54 -0700 (PDT) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (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 417811A0123 for ; Thu, 23 Jul 2015 09:25:54 -0700 (PDT) Received: from [31.133.179.67] (dhcp-b343.meeting.ietf.org [31.133.179.67]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t6NGPjsS019744 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 23 Jul 2015 09:25:47 -0700 To: Owen DeLong , Erik Nordmark References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> <55AD3B64.5070400@acm.org> <55B01B96.8090205@acm.org> From: Erik Nordmark Message-ID: <55B11589.8000200@acm.org> Date: Thu, 23 Jul 2015 18:25:45 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Sonic-CAuth: UmFuZG9tSVZKTtSziyu4Gcu/ic6PXEVWDYWWz6vXgL3ha15FV/aNx1zGzYgY7BwZ24ZydYey+PHVMkIdIAu3nd6Qkq135uF8 X-Sonic-ID: C;egyMeFcx5RGOUIwFrKU7pA== M;xiMyeVcx5RGOUIwFrKU7pA== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Archived-At: Cc: "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" , v6ops list Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 23 Jul 2015 16:26:00 -0000 On 7/23/15 1:14 AM, Owen DeLong wrote: > > Ole, > > Even on a flat wired L2 network I don't think it is harmful to default to unicast solicited RAs. > > If we take a worst case of 10000 hosts on the L2 network all rebooting/initializing at the same time, we will see: > - 10000 DAD probes for link-local address > - 10000 MLD joins for the solicited node MC for their link-locals > As was pointed out earlier, we shouldn’t see MLD joins for LL solicited nodes or any other LinkScoped group, unless I am badly misunderstanding things. Owen, The RFC says to send them for everything but ff02::1 (all-nodes). > >> - 10000 RS messages(*) >> - 1/10000 RA messages > I think you mean 1 to 10000 because I don’t think fractional messages are possible. Sorry for not explaining my notation. I meant 1 vs. 10000 depending on whether multicast or unicast RA is used. Point is that the saving isn't that large given the other required packets during host interface initialization. Erik > >> - 10000 DAD probes for global addresses (N x 10000 if N prefixes on-link) >> - N x 10000 mDNS etc type packets >> >> (*) RFC 4861 suggests receiving an RA before an RS is sent, thus under some timing conditions some RS messages might be avoided. >> >> But at best we seem to be talking about saving 20% of the packet during the boot of the 10000 hosts. > True… However, even if this is an actual concern, we could consider a threshold in PPS where we send an RA Mcast response. > > e.g. if more than 10 RS received in 1 second, send a multicast RA. > > In fact, we could probably get away with delaying an RA response to RS for 250ms. If another RS arrives during that delay, respond multicast, else unicast. > > That probably still eliminates most of the RA traffic, may eliminate many of those 10000 RS messages, and could provide kind of the best of both worlds. > I’m not sure how hard it would be to implement in silicon, however. > > Owen > > From nobody Thu Jul 23 09:26:32 2015 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 622E91A0364 for ; Thu, 23 Jul 2015 09:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 EhXenVhQcI0t for ; Thu, 23 Jul 2015 09:26:29 -0700 (PDT) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (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 39C491A0262 for ; Thu, 23 Jul 2015 09:26:24 -0700 (PDT) Received: from [31.133.179.67] (dhcp-b343.meeting.ietf.org [31.133.179.67]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t6NGQF6J030612 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 23 Jul 2015 09:26:16 -0700 To: Mark Smith , Erik Nordmark References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> <55B0177F.8050703@acm.org> From: Erik Nordmark Message-ID: <55B115A6.5040607@acm.org> Date: Thu, 23 Jul 2015 18:26:14 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVZ+t2z7ms+rp/m304iBz7GHgWNdC+wYoOHargfjt106hS6BhQ7sW1fyvOTmLJnz8XPuBGn/Y1/O+jZdQUwrrdoY X-Sonic-ID: C;ZOAHilcx5RG97oM848vClw== M;/Gy1ilcx5RG97oM848vClw== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Archived-At: Cc: v6ops list , "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 23 Jul 2015 16:26:30 -0000 On 7/23/15 2:37 AM, Mark Smith wrote: > Hi Erik, > > On 23 July 2015 at 08:21, Erik Nordmark wrote: >> On 7/21/15 1:25 PM, Mark Smith wrote: >>> >>> I thought that could be an option, however I encountered RSes without >>> the Source Link Layer Option, which means if RFC6085 is to be used, >>> the link-layer header has to be available to get the source link-layer >>> address from. >>> >>> After I wondered about the efficiency benefit of using multicasts for >>> solicited RAs, Fred asked me to do some testing/investigation. I wrote >>> up what I found here, the few unusual RS cases I saw the following, >>> which I put down some thoughts about handling via e.g., RFC6085. >>> >>> o RSes with a :: source address >>> >>> o RSes with a link-local source addresses, but no Source Link-Layer >>> Address Option >> >> Yes, both of those are important (I had forgotten about the second one). >> >> As you say, an implementation might be able to use the link-layer header and >> unicast back a packet. If the source was :: then that approach would rely on >> sending to the multicast ff02::1 while the link-layer destination is >> unicast. >> >> If not, then the implementation needs to multicast the RA. >> > I was wondering if instead the implementation could trigger an ND/NS > transaction for the RS source address at that point, and then unicast > the RA when that completes. That would only address the lack of SLLAO case; not the unspecified source address case. I don't know how common these cases are in existing implementations. The unspecified source would appear if the host is doing DAD in parallel with sending the RS. I don't know when a host would omit the SLLAO in the RS. > > RFC4861 seems to be a bit vague about being able to do that. It says > that if the SLLO is not present, the router still can unicast the RA. > As RFC4861 is pre RFC6085, then performing a ND/NS first would be the > only way to do that. The last sentence also seems to be permitting NC > entries to be created when there is no SLLO ("or not a Source > Link-Layer is provided" ... "Neighbor Cache entry" ... "(or is > created)"). > > "If there is no existing Neighbor Cache > entry and no Source Link-Layer Address option was present in the > solicitation, the router may respond with either a multicast or a > unicast router advertisement. Whether or not a Source Link-Layer > Address option is provided, if a Neighbor Cache entry for the > solicitation's sender exists (or is created) the entry's IsRouter > flag MUST be set to FALSE." I think the attempt at english as opposed to pseudo-code is hard to read. AFAIK the intent was if NCE set NCE IsRouter to FALSE Thus the NCE might have already existed, or have been created. I think there is text earlier to say to not create an NCE for 0::0 nor if there is no SLLAO (unless the link-layer has no addresses). Regards, Erik > > Performing an NS/ND to resolve the source address of the RS without a > SLLO would seem consistent with the corresponding RS SLLO handling - > to load the Neighbor Cache with entries for nodes that have sent RSes. > > > Regards, > Mark. > >> Erik >> >>> https://www.ietf.org/mail-archive/web/v6ops/current/msg22464.html >>> >>> >>> >>> >>> https://www.ietf.org/mail-archive/web/v6ops/current/msg22464.html >>> >>>> But I would not say it's sufficient, if only from an "explicit >>>> clarity" standpoint. I think explicit mention of RAs and the other >>>> discussion is helpful for implementors not inclined to dig to great >>>> depths or just seeking explicit confirmation. >>>> >>> >>> >>>> _______________________________________________ >>>> 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 Jul 23 09:58:30 2015 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 43DAE1AD1C3 for ; Thu, 23 Jul 2015 09:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g_ryqLnUf9DR for ; Thu, 23 Jul 2015 09:58:27 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F1A41AD374 for ; Thu, 23 Jul 2015 09:58:24 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6NGwMVi010968 for ; Thu, 23 Jul 2015 18:58:22 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 463B3204CC4 for ; Thu, 23 Jul 2015 19:01:59 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 3D3B1204B52 for ; Thu, 23 Jul 2015 19:01:59 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.59]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6NGwKg8013542 for ; Thu, 23 Jul 2015 18:58:21 +0200 To: v6ops@ietf.org References: <20150723113949.29435.87346.idtracker@ietfa.amsl.com> From: Alexandru Petrescu Message-ID: <55B11D2C.8040300@gmail.com> Date: Thu, 23 Jul 2015 18:58:20 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150723113949.29435.87346.idtracker@ietfa.amsl.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-reducing-ra-energy-consumption-00.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, 23 Jul 2015 16:58:29 -0000 I support. But, let me just say that after having measured, and we do have some publications and implementation about this, the only way one can reduce the energy consumption of an RA is to reduce its size or to send it on another link. Multicast is good to save energy. I also agree I may just have a problem in naming things. Alex Le 23/07/2015 13:39, internet-drafts@ietf.org a écrit : > > 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 : Reducing energy consumption of Router > Advertisements Authors : Andrew Yourtchenko Lorenzo Colitti > Filename : > draft-ietf-v6ops-reducing-ra-energy-consumption-00.txt Pages > : 5 Date : 2015-07-23 > > Abstract: Frequent Router Advertisement messages can severely impact > host power consumption. This document recommends operational > practices to avoid such impact. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-reducing-ra-energy-consumption/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-v6ops-reducing-ra-energy-consumption-00 > > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Jul 23 10:39:39 2015 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 08E621B29F1 for ; Thu, 23 Jul 2015 10:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 cc9GU6CMvdZc for ; Thu, 23 Jul 2015 10:39:37 -0700 (PDT) Received: from mail-vn0-f42.google.com (mail-vn0-f42.google.com [209.85.216.42]) (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 5F8561B29F3 for ; Thu, 23 Jul 2015 10:39:36 -0700 (PDT) Received: by vnaa140 with SMTP id a140so63313451vna.2 for ; Thu, 23 Jul 2015 10:39:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=QULViasKva7fUKdx3ZH7R7iD1JehYtZJymVcl/KQc/M=; b=KzjcMB3Dd4p6KhrsylcHiacPtkl6RpA0DFpnrDjCV4Sbxa29gF5523bSRw0UR3oI1p z6YLQfDIFWoZePHKgE8ndxtJYtjRSGB6D9+UkYAPucMvq/63MpDk4erMkbv/CBdEZjB/ C8aY81Ndyx4S6q4ZJqfRLZ04aHlmlDpG5CpdexdAv6T2tcLjhsaW+tbiYb1jWMZiKvV2 S7owugcGu+6vaHff0VTHhx5X6woIw7Ot+t8YgLYhbnAVa6TsxLUrS2Kv4SXP7XkOHx5v rI7jaJ4vMu38AmJ0Eh+wGIB/Io3+PZTJgUtX5tM9cycHknfsBSO153QHo6uWSWlhWH7O 19qg== X-Gm-Message-State: ALoCoQl3HOTWUsOm1BuJ8y3MD7xDIaJ1MBokpLDjOkjkI4KKOmtv9ezpyjFDeQ8ZTJbS7ynk2ZdG X-Received: by 10.52.92.110 with SMTP id cl14mr2674986vdb.35.1437673175578; Thu, 23 Jul 2015 10:39:35 -0700 (PDT) Received: from mail-vn0-f50.google.com (mail-vn0-f50.google.com. [209.85.216.50]) by smtp.gmail.com with ESMTPSA id ef1sm1164554vdb.5.2015.07.23.10.39.35 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Jul 2015 10:39:35 -0700 (PDT) Received: by vnk197 with SMTP id 197so63278115vnk.3 for ; Thu, 23 Jul 2015 10:39:35 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.52.17.2 with SMTP id k2mr10992840vdd.15.1437673175033; Thu, 23 Jul 2015 10:39:35 -0700 (PDT) Received: by 10.31.206.193 with HTTP; Thu, 23 Jul 2015 10:39:34 -0700 (PDT) In-Reply-To: References: Date: Thu, 23 Jul 2015 14:39:34 -0300 Message-ID: From: Francisco Paletta To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=001a11365fb0e6bf6d051b8e5ee2 Archived-At: Cc: v6ops list Subject: Re: [v6ops] As promised... 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, 23 Jul 2015 17:39:39 -0000 --001a11365fb0e6bf6d051b8e5ee2 Content-Type: text/plain; charset=UTF-8 Hello, I believe it's a good "best practice". I just have suggestions regarding the "3. Consequences" points 2 and 3. Despite the fact that frequent RA messages are causing those consequences, they should not be used as base to support this recommendation. In my opinion, the frequency or broadness of RA messages should not cause a device to disrupt it's communication. The device must deal with it another way. Obviously they can benefit from the changes in RA messages behaviors. But should not be the motivation. Nevertheless I agree that once the device receives an information and have to deal with it, it spends power on that process and we should control that to favor battery-powered devices. Regards, Francisco Paletta 2015-07-23 10:10 GMT-03:00 Fred Baker (fred) : > https://tools.ietf.org/html/draft-ietf-v6ops-reducing-ra-energy-consumption > "Reducing energy consumption of Router Advertisements", Andrew > Yourtchenko, Lorenzo Colitti, 2015-07-23, > > We had quite a bit of discussion Tuesday, especially considering the > length (or brevity) of this draft. > > I'd suggest you read it. Especially given the number of "+2" comments on > the list, I tend to think we can come to consensus relatively quickly on > it. If there are lingering issues, let's get them out of the way. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --001a11365fb0e6bf6d051b8e5ee2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

I believe it's a = good "best practice".

I just have sugges= tions regarding the "3. Consequences" points 2 and 3. Despite the= fact that frequent RA messages are causing those consequences, they should= not be used as base to support this recommendation.

In my opinion, the frequency or broadness of RA messages should not caus= e a device to disrupt it's communication. The device must deal with it = another way. Obviously they can benefit from the changes in RA messages beh= aviors. But should not be the motivation.

Neverthe= less I agree that once the device receives an information and have to deal = with it, it spends power on that process and we should control that to favo= r=C2=A0battery-powered devices.

Regards,

Francisco Paletta


2015-07-23 10:10 GMT-03:00 Fred Baker (fred) <fred@cisco.com>:
https://tools.ietf.org/html/draft-ietf-v6ops-reducing-ra-ene= rgy-consumption
=C2=A0 "Reducing energy consumption of Router Advertisements", An= drew
=C2=A0 Yourtchenko, Lorenzo Colitti, 2015-07-23,

We had quite a bit of discussion Tuesday, especially considering the length= (or brevity) of this draft.

I'd suggest you read it. Especially given the number of "+2" = comments on the list, I tend to think we can come to consensus relatively q= uickly on it. If there are lingering issues, let's get them out of the = way.

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


--001a11365fb0e6bf6d051b8e5ee2-- From nobody Thu Jul 23 10:54:35 2015 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 034061B2A1C for ; Thu, 23 Jul 2015 10:54:34 -0700 (PDT) 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 HHQ3uSHnZrro for ; Thu, 23 Jul 2015 10:54:32 -0700 (PDT) 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 0C1C21B2A11 for ; Thu, 23 Jul 2015 10:54:30 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id AADB262CA4 for ; Thu, 23 Jul 2015 19:54:28 +0200 (CEST) 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 6A4B360054 for ; Thu, 23 Jul 2015 19:54:28 +0200 (CEST) Received: (qmail 36692 invoked by uid 1007); 23 Jul 2015 19:54:28 +0200 Date: Thu, 23 Jul 2015 19:54:28 +0200 From: Gert Doering To: Alexandru Petrescu Message-ID: <20150723175428.GY90924@Space.Net> References: <20150723113949.29435.87346.idtracker@ietfa.amsl.com> <55B11D2C.8040300@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55B11D2C.8040300@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-reducing-ra-energy-consumption-00.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, 23 Jul 2015 17:54:34 -0000 Hi, On Thu, Jul 23, 2015 at 06:58:20PM +0200, Alexandru Petrescu wrote: > But, let me just say that after having measured, and we do have some > publications and implementation about this, the only way one can reduce > the energy consumption of an RA is to reduce its size or to send it on > another link. Multicast is good to save energy. That sounds like a brillant idea. Just send all the battery consuming packets on other links, and problem solved. Thanks for your insights! 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 Jul 23 14:50:19 2015 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 5553F1A87B9 for ; Thu, 23 Jul 2015 14:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, 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 C-znt-NLoSuj for ; Thu, 23 Jul 2015 14:50:15 -0700 (PDT) Received: from mail-oi0-f44.google.com (mail-oi0-f44.google.com [209.85.218.44]) (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 3A8F41AD0D0 for ; Thu, 23 Jul 2015 14:50:05 -0700 (PDT) Received: by oigd21 with SMTP id d21so5980038oig.1 for ; Thu, 23 Jul 2015 14:50:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=JvXsYbG/PVPsCefOWc+dQZjiwwakK5aOjixBYXo2MAo=; b=Xd9aluB2frpkld3WYZmu0XDvXSamVITkACboYLYfec/oarY2+rqdrfQyFUi8ShqIaA rAsqPRipvkPmB0SMLueaS2xqZS6PmrvCYU7CRWKy/Fv6JfiXD5nzLV+zF1YN6/AMHw6C MRDbK7y010z3p3PK0FbJ7C38SYVOg0Pd4C6/XXii02EW20rxp21mEH/rxivqNvj9hZDz jEsemJ23FUP3KjyFxlq5FKBH9Mc8wtiOibL1kW/5UOkDbI3zJ/2IqcZSVwk0OmINB/Hs mUQfw/9/3vwD8+aT6ok4IC60+mTd25ejXzGAZFZUdeBGJ9xauTUQC8SG5rbPIuy+cUoj HFJg== X-Gm-Message-State: ALoCoQkBUfLBEIbc/CNocvI8s25NrnonurX9rg+5SmPVnRakFTbnbFRO6LfhOQkGF7QbhPdUdzZE MIME-Version: 1.0 X-Received: by 10.202.78.72 with SMTP id c69mr10709226oib.130.1437688204676; Thu, 23 Jul 2015 14:50:04 -0700 (PDT) Received: by 10.202.239.86 with HTTP; Thu, 23 Jul 2015 14:50:04 -0700 (PDT) In-Reply-To: References: Date: Thu, 23 Jul 2015 14:50:04 -0700 Message-ID: From: Jason Fesler To: Francisco Paletta Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: v6ops list Subject: Re: [v6ops] As promised... 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, 23 Jul 2015 21:50:17 -0000 On Thu, Jul 23, 2015 at 10:39 AM, Francisco Paletta wrote: > I believe it's a good "best practice". +1. We use unicast responses at $dayjob, across a variety of devices, and see no harmful effects. It has helped keep multicast/broadcast volume over the radio down to manageable levels; and as a side effect, helped with keeping people's pocket phones from catching fire. From nobody Thu Jul 23 18:15:21 2015 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 1EEF61AD05D for ; Thu, 23 Jul 2015 18:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, 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 UN7e924T9RBm for ; Thu, 23 Jul 2015 18:15:15 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id ADC821A1A87 for ; Thu, 23 Jul 2015 18:15:14 -0700 (PDT) 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.2) with ESMTP id t6O1FBl6018824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Jul 2015 18:15:12 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_ABAC8489-9F8D-496D-9761-530018BCD0C6" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Owen DeLong In-Reply-To: <55B0E2C5.2060309@gmail.com> Date: Thu, 23 Jul 2015 18:15:11 -0700 Message-Id: <39785499-6DB4-4DA4-BA48-2E4A7FA8224F@delong.com> References: <55AE42A4.8020908@gmail.com> <5CD05758-D7B7-476D-9936-E5A1D0614AF8@employees.org> <55B0D356.7070505@gmail.com> <6666FED5-227B-496F-B5F5-2883A12F9B96@employees.org> <55B0DB2B.1030703@gmail.com> <20150723122710.GX57117@ernw.de> <55B0E2C5.2060309@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.2098) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] ref Hosts dont MLD to join LL groups 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, 24 Jul 2015 01:15:19 -0000 --Apple-Mail=_ABAC8489-9F8D-496D-9761-530018BCD0C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Jul 23, 2015, at 05:49 , Alexandru Petrescu = wrote: >=20 >=20 >=20 > Le 23/07/2015 14:27, Enno Rey a =E9crit : >> Hi, >>=20 >> On Thu, Jul 23, 2015 at 02:16:43PM +0200, Alexandru Petrescu wrote: >>> If one disallows all MLD joins for all link-scoped IP multicast >>> addresses - why does one need IP multicast addresses with link >>> scope? >>>=20 >>> Why does one need the lino-layer 33::1 address? >>>=20 >>> If one doesnt need 33::1 then why Ethernet provides it? >>>=20 >>> I guess what I am trying to say is that it's useless to have >>> multicast groups if one can't join them. >>=20 >> define "join a multicast group"... >=20 > Inform the sender willingnes to be part of the group. If not part of > group, then sender will not send it. Same concept at L2 and at L3. That=92s simply not true=85 Even if I turn off every SSDP listener on my network, I still have many = devices sending many SSDP packets in IPv4 _AND_ IPv6. And those packets are visible to _EVERY_ host on the link, not just the = ones that subscribed. MLD is used to tell routers that you want to join a group so that it = knows someone on link A wants to see the multicast packets for that group from Link B. >> strictly speaking MLD as a whole is only needed for interdomain >> multicast anyway. >=20 > Disagree - beyond just interdomain multicast, Ethernet has link-layer > multicast builtin. There is no 'broadcast' address anymore in = Ethernet > since some time, replaced by 'multicast': supposedly better at saving > battery and other advantages. Yes, but Ethernet Link Layer Multicast doesn=92t use MLD for delivery = decisions. =46rom Cisco=92s documentation on MLD snooping: MLD Snooping Overview=20 <>MLD snooping allows the switch to examine MLD packets and make = forwarding decisions based on their content.=20 <>You can configure the switch to use MLD snooping in subnets that = receive MLD queries from either MLD or the MLD snooping querier. MLD = snooping constrains IPv6 multicast traffic at Layer 2 by configuring = Layer 2 LAN ports dynamically to forward IPv6 multicast traffic only to = those ports that want to receive it.=20 <>MLD, which runs at Layer 3 on a multicast router, generates Layer 3 = MLD queries in subnets where the multicast traffic needs to be routed. = For information about MLD, see this publication:=20 = <>http://www.cisco.com/en/US/docs/ios-xml/ios/ipv6/configuration/12-2sx/ip= v6-12-2sx-book.html = <>You can configure the MLD snooping querier on the = switch to support MLD snooping in subnets that do not have any multicast = router interfaces. For more information about the MLD snooping querier, = see the "Enabling the MLD Snooping Querier" section = .=20 <>MLD (on a multicast router) or, locally, the MLD snooping querier, = sends out periodic general MLD queries that the switch forwards through = all ports in the VLAN, and to which hosts respond. MLD snooping monitors = the Layer 3 MLD traffic.=20 In other words, MLD is strictly a layer 3 function. Some Layer 2 devices = do interesting things with it (MLD Snooping), but counting on MLD to = discover a listener that is not trying to listen or subscribe beyond the = local link scope is not guaranteed to work. Unfortunately, there probably are many other misguided implementers like = Alexandru out there, so it is likely that turning off MLD for Link Local = would break things in a number of existing implementations even though = it shouldn=92t. Tough call whether that=92s overall a good thing (let=92s break it to = make the world better and fix the implementations that identify = themselves when it breaks) or a bad idea (generally breaking stuff is = bad unless you have a really good reason to do so.). I will say that ideally, we should pick a consistent decision=85 Either = require MLD for all multicast joins, including link local or prohibit = MLD for link-scoped multicast. The current =93You can MLD if you want to = and what happens when you don=92t is undefined for all but a select few = pre-defined groups is anybody=92s guess=94 probably isn=92t ideal no = matter what. >> on the local link you join a MC group by kind-of self declaration >> ("hey I consider myself part of that group >=20 > That is an Ethernet message. Nope=85 It=92s a matter of adding the applicable Mac address and IP = address to the =93interesting addresses=94 list on the interface. To the best of my knowledge, there=92s no Ethernet L2 message for = expressing interest or lack thereof in a multicast group. MAC addressing is handled by a reserved Mac range (01:00:5E:00:00:00/25) = for IPv4 multicast, where the low-order 23-bits of the multicast group = IP address are placed in the low order 23 bits of the MAC address. IPv6 multicast uses MAC addresses in the range 33:33:0:0:0:0/16 and maps = the low order 32 bits of the multicast group onto the low order 32 bits = of the MAC address. Nowhere in the ethernet L2 world is there anything special about = 33:33::/16. It=92s strictly a conventional reservation from an Ethernet = perspective. A bridge does not (necessarily) see it as different from = any other MAC address. The exception would be bridges that implement MLD snooping where you are = then counting on receiving L3 MLD messages to tell the bridge how to = behave, but said MLD messages may or may not exist. An MLD querier can = be configured on some bridges in order to solicit additional MLD joins, = but hosts are not required or necessarily expected to send said joins = for link local scoped groups unless solicited. Even then, it is a Layer = 3 function which the switch is using kind of a hack to take advantage of = to inform L2 forwarding. > Some cards send that message, others don't. All should. Source? Nothing in the standards I could find requires or even says = =93Should=94 in any of the IEEE documents I could find. >> so I'm interested in >> certain traffic and hence instruct my stack to listen to/process >> packets with certain addresses"). no need of MLD for that action. >=20 > How does the Ethernet layer know this is a Router, and not a Host? = Only by knowing that it can join the all-hosts or all-routers link-layer = address. And only the IP stack knows whether it's a Host or a Router. = So the IP stack should tell the Ethernet layer to make that link-layer = join. It cannot be a router and not a host. It can be a host and not a router. = All routers are by definition hosts. Not all hosts are routers. The IP stack tells the ethernet layer which addresses are interesting.=20= On Linux, you can find it here: owen.delong.com:owen /proc/16742/net (167) % cat /proc/net/dev_mcast 2 em1 1 0 333300000001 2 em1 1 0 01005e000001 2 em1 1 0 3333ff5abc51 2 em1 1 0 01005e0000fb 2 em1 1 0 3333ff000001 2 em1 1 0 3333ff000002 2 em1 1 0 3333ff000004 2 em1 1 0 3333ff000005 2 em1 1 0 3333ff000006 2 em1 1 0 3333ff000007 2 em1 1 0 3333ff000009 2 em1 1 0 3333ff00000a 2 em1 1 0 3333ff00000b 2 em1 1 0 3333ff00000c 2 em1 1 0 3333ff00000d 2 em1 1 0 3333ff00000e 2 em1 1 0 3333ff00000f 2 em1 1 0 3333ff000012 2 em1 1 0 3333ff000013 2 em1 1 0 3333ff000014 2 em1 1 0 3333ff000015 2 em1 1 0 3333ff000016 2 em1 1 0 3333ff000017 2 em1 1 0 3333ff000018 2 em1 1 0 3333ff000019 2 em1 1 0 3333ff00001a 2 em1 1 0 3333ffefcafe 2 em1 1 0 01005e7ffffa Again, to the ethernet card, it=92s just another MAC address it listens = for. It doesn=92t care multicast, unicast, broadcast. If the DST MAC = Address of an arriving packet is in the list of addresses to listen to = (which is the concatenation of the unicast MAC address(es), the = broadcast MAC address(es), and the multicast MAC address(es) configured = by the IP stack), it hands the packet up to the kernel. If not, it = discards the packet. Owen >=20 > Yours, >=20 > Alex >=20 >> but >> "joining" on the local-link doesn't need MLD. >>=20 >> best >>=20 >> Enno >>=20 >>=20 >>=20 >>=20 >>=20 >>>=20 >>> Alex >>>=20 >>> Le 23/07/2015 13:51, Ole Troan a ??crit : >>>> Alexandru, >>>>=20 >>>> I???m afraid I couldn???t interpret your message. would someone >>>> else be able to translate? >>>>=20 >>>> cheers, Ole >>>>=20 >>>>>>=20 >>>>>> I do wonder if we should expand that exception to all >>>>>> link-scope multicast addresses. >>>>>>=20 >>>>>=20 >>>>> I would beg to disagree. >>>>>=20 >>>>> If we expand that to all link-scoped groups, may lead to >>>>> dismantling IPv6 dependence on 33::1 - ff:ff:ff:ff:ff would be >>>>> sufficient. >>>>>=20 >>>>> My oppinion would rather be to modify the MLD RFC to mandate >>>>> MLD joins for all scopes. >>>>>=20 >>>>> Ethernet has primitives for joining the corresponding >>>>> link-layer groups, and in some cases they are used. Maybe all >>>>> should use them. >>>>>=20 >>>>>> the bridge implementors I speak to tell me that they don???t >>>>>> have enough state to do MLD snooping for link-local scoped >>>>>> multicast addresses anyway... >>>>>=20 >>>>> This may be dumb from my side, but why dont bridge >>>>> implementers use link-layer multicast? They shouldnt implement >>>>> MLD, and not snoop it. The Hosts should send the necessary >>>>> link-layer multicast joins (triggered by themselves sending MLD >>>>> REPORT for these groups) to the bridge addresses. >>>>>=20 >>>>> Alex >>>>>=20 >>>>>> cheers, Ole >>>>=20 >>>=20 >>> _______________________________________________ v6ops mailing list >>> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_ABAC8489-9F8D-496D-9761-530018BCD0C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Jul 23, 2015, at 05:49 , Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:



Le 23/07/2015 14:27, Enno Rey a =E9crit :
Hi,

On Thu, Jul 23, 2015 at 02:16:43PM +0200, Alexandru Petrescu = wrote:
If one = disallows all MLD joins for all link-scoped IP multicast
addresses - why does one need IP multicast addresses with = link
scope?

Why does one need = the lino-layer  33::1 address?

If one = doesnt need 33::1 then why Ethernet provides it?

I guess what I am trying to say is that it's useless to = have
multicast groups if one can't join them.

define "join a multicast = group"...

Inform the sender = willingnes to be part of the group.  If not part of
group, then sender will not send it.  Same concept at L2 = and at L3.

That=92s simply not true=85

Even if I turn off every SSDP listener on my = network, I still have many devices sending many SSDP
packets = in IPv4 _AND_ IPv6.

And those = packets are visible to _EVERY_ host on the link, not just the ones that = subscribed.

MLD is used to tell = routers that you want to join a group so that it knows someone on link = A
wants to see the multicast packets for that group from Link = B.

strictly = speaking MLD as a whole is only needed for interdomain
multicast anyway.

Disagree - beyond just interdomain multicast, Ethernet has = link-layer
multicast builtin.  There is no = 'broadcast' address anymore in Ethernet
since some time, = replaced by 'multicast': supposedly better at saving
battery= and other advantages.

Yes, but Ethernet Link Layer Multicast doesn=92t use = MLD for delivery decisions.

=46rom = Cisco=92s documentation on MLD snooping:

MLD Snooping Overview 

MLD snooping allows the switch to examine MLD = packets and make forwarding decisions based on their = content. 

You can configure the = switch to use MLD snooping in subnets that receive MLD queries from = either MLD or the MLD snooping querier. MLD snooping constrains IPv6 = multicast traffic at Layer 2 by configuring Layer 2 LAN ports = dynamically to forward IPv6 multicast traffic only to those ports that = want to receive it. 

MLD, which runs at Layer 3 = on a multicast router, generates Layer 3 MLD queries in subnets where = the multicast traffic needs to be routed. For information about MLD, see = this publication: 

http://www.cisco.com/en/US/docs/ios-xml/ios/ipv6/configuration/= 12-2sx/ipv6-12-2sx-book.html

You can configure = the MLD snooping querier on the switch to support MLD snooping in = subnets that do not have any multicast router interfaces. For more = information about the MLD snooping querier, see the "Enabling the MLD = Snooping Querier" section. 

MLD (on a multicast = router) or, locally, the MLD snooping querier, sends out periodic = general MLD queries that the switch forwards through all ports in the = VLAN, and to which hosts respond. MLD snooping monitors the Layer 3 MLD = traffic. 


In other words, MLD is strictly a = layer 3 function. Some Layer 2 devices do interesting things with it = (MLD Snooping), but counting on MLD to discover a listener that is not = trying to listen or subscribe beyond the local link scope is not = guaranteed to work.

Unfortunately, there probably are many other misguided = implementers like Alexandru out there, so it is likely that turning off = MLD for Link Local would break things in a number of existing = implementations even though it shouldn=92t.

Tough call whether that=92s overall a = good thing (let=92s break it to make the world better and fix the = implementations that identify themselves when it breaks) or a bad idea = (generally breaking stuff is bad unless you have a really good reason to = do so.).

I = will say that ideally, we should pick a consistent decision=85 Either = require MLD for all multicast joins, including link local or prohibit = MLD for link-scoped multicast. The current =93You can MLD if you want to = and what happens when you don=92t is undefined for all but a select few = pre-defined groups is anybody=92s guess=94 probably isn=92t ideal no = matter what.

on the local link you join a MC group by kind-of self = declaration
("hey I consider myself part of that group

That is an Ethernet message.

Nope=85 It=92s a = matter of adding the applicable Mac address and IP address to the = =93interesting addresses=94 list on the interface.

To the best of my knowledge, there=92s no Ethernet = L2 message for expressing interest or lack thereof in a multicast = group.

MAC addressing is handled by = a reserved Mac range (01:00:5E:00:00:00/25)  for IPv4 multicast, = where the low-order 23-bits of the multicast group IP address are placed = in the low order 23 bits of the MAC address.

IPv6 multicast uses MAC addresses in the range = 33:33:0:0:0:0/16 and maps the low order 32 bits of the multicast group = onto the low order 32 bits of the MAC address.

Nowhere in the ethernet L2 world is there anything = special about 33:33::/16. It=92s strictly a conventional reservation = from an Ethernet perspective. A bridge does not (necessarily)  see = it as different from any other MAC address.

The exception would be bridges that implement MLD = snooping where you are then counting on receiving L3 MLD messages to = tell the bridge how to behave, but said MLD messages may or may not = exist. An MLD querier can be configured on some bridges in order to = solicit additional MLD joins, but hosts are not required or necessarily = expected to send said joins for link local scoped groups unless = solicited. Even then, it is a Layer 3 function which the switch is using = kind of a hack to take advantage of to inform L2 = forwarding.

Some cards send that message, others don't. =  All should.

Source? Nothing in the standards I could find requires = or even says =93Should=94 in any of the IEEE documents I could = find.

so I'm interested in
certain traffic and hence instruct my stack to listen = to/process
packets with certain addresses"). no need of = MLD for that action.

How does = the Ethernet layer know this is a Router, and not a Host?  Only by = knowing that it can join the all-hosts or all-routers link-layer = address.  And only the IP stack knows whether it's a Host or a = Router. So the IP stack should tell the Ethernet layer to make that = link-layer join.

It cannot be a router and not a host. It can be a host = and not a router. All routers are by definition hosts. Not all hosts are = routers.

The IP stack tells the = ethernet layer which addresses are interesting. 

On Linux, you can find it here:

owen.delong.com:owen /proc/16742/net (167) % cat = /proc/net/dev_mcast
2    em1           =   1     0     333300000001
2  =   em1             1     0 =     01005e000001
2    em1         =     1     0     3333ff5abc51
2  =   em1             1     0 =     01005e0000fb
2    em1         =     1     0     3333ff000001
2  =   em1             1     0 =     3333ff000002
2    em1         =     1     0     3333ff000004
2  =   em1             1     0 =     3333ff000005
2    em1         =     1     0     3333ff000006
2  =   em1             1     0 =     3333ff000007
2    em1         =     1     0     3333ff000009
2  =   em1             1     0 =     3333ff00000a
2    em1         =     1     0     3333ff00000b
2  =   em1             1     0 =     3333ff00000c
2    em1         =     1     0     3333ff00000d
2  =   em1             1     0 =     3333ff00000e
2    em1         =     1     0     3333ff00000f
2  =   em1             1     0 =     3333ff000012
2    em1         =     1     0     3333ff000013
2  =   em1             1     0 =     3333ff000014
2    em1         =     1     0     3333ff000015
2  =   em1             1     0 =     3333ff000016
2    em1         =     1     0     3333ff000017
2  =   em1             1     0 =     3333ff000018
2    em1         =     1     0     3333ff000019
2  =   em1             1     0 =     3333ff00001a
2    em1         =     1     0     3333ffefcafe
2  =   em1             1     0 =     01005e7ffffa


Again, to the ethernet = card, it=92s just another MAC address it listens for. It doesn=92t care = multicast, unicast, broadcast. If the DST MAC Address of an arriving = packet is in the list of addresses to listen to (which is the = concatenation of the unicast MAC address(es), the broadcast MAC = address(es), and the multicast MAC address(es) configured by the IP = stack), it hands the packet up to the kernel. If not, it discards the = packet.

Owen


Yours,

Alex

but
"joining" on the local-link = doesn't need MLD.

best

Enno






Alex

Le = 23/07/2015 13:51, Ole Troan a ??crit :
Alexandru,

I???m = afraid I couldn???t interpret your message. would someone
else be able to translate?

cheers,= Ole


I do = wonder if we should expand that exception to all
link-scope = multicast addresses.


I would beg to disagree.

If we = expand that to all link-scoped groups, may lead to
dismantling IPv6 dependence on 33::1 - ff:ff:ff:ff:ff would = be
sufficient.

My oppinion = would rather be to modify the MLD RFC to mandate
MLD joins = for all scopes.

Ethernet has primitives for = joining the corresponding
link-layer groups, and in some = cases they are used. Maybe all
should use them.

the = bridge implementors I speak to tell me that they don???t
have enough state to do MLD snooping for link-local scoped
multicast addresses anyway...

This may be dumb from my side, but why dont bridge
implementers use link-layer multicast?  They shouldnt = implement
MLD, and not snoop it. The Hosts should send the = necessary
link-layer multicast joins (triggered by = themselves sending MLD
REPORT for these groups) to the = bridge addresses.

Alex

cheers, Ole


_______________________________________________ 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

= --Apple-Mail=_ABAC8489-9F8D-496D-9761-530018BCD0C6-- From nobody Thu Jul 23 18:28:15 2015 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 915351B2D61 for ; Thu, 23 Jul 2015 18:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, 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 y3gvBMdxXXCH for ; Thu, 23 Jul 2015 18:28:11 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 508851B2AE6 for ; Thu, 23 Jul 2015 18:28:11 -0700 (PDT) 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.2) with ESMTP id t6O1S8KT020448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Jul 2015 18:28:08 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_2DC693FC-0F05-4616-AB27-B8961DD4C359" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Owen DeLong In-Reply-To: <55B0FB82.9070809@gmail.com> Date: Thu, 23 Jul 2015 18:28:07 -0700 Message-Id: References: <55AE42A4.8020908@gmail.com> <5CD05758-D7B7-476D-9936-E5A1D0614AF8@employees.org> <55B0D356.7070505@gmail.com> <6666FED5-227B-496F-B5F5-2883A12F9B96@employees.org> <55B0DB2B.1030703@gmail.com> <20150723122710.GX57117@ernw.de> <55B0E2C5.2060309@gmail.com> <20150723130151.GA57117@ernw.de> <55B0FB82.9070809@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.2098) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] ref Hosts dont MLD to join LL groups 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, 24 Jul 2015 01:28:13 -0000 --Apple-Mail=_2DC693FC-0F05-4616-AB27-B8961DD4C359 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Jul 23, 2015, at 07:34 , Alexandru Petrescu = wrote: >=20 >=20 >=20 > Le 23/07/2015 15:01, Enno Rey a =E9crit : >> Hi, >>=20 >>>=20 >>> Inform the sender willingnes to be part of the group. If not part >>> of group, then sender will not send it. Same concept at L2 and at >>> L3. >>=20 >> wrong. the sender of a MC message just sends it out, regardless if >> somebody listens or not. >=20 > I agree. >=20 >> the router(s) helping to distribute this message (in case of >> interdomain MC) only have to know (=3D are interested) if there's at >> least one interested listener on an adjacent link. neither the >> sender nor the router(s) have any interest (or need to have that) in >> individual listeners. >=20 > YEs, that's so for multicast across multiple subnets. >=20 > But on the same link (same subnet) the Router sends these RAs, so it > must be able to know which Host would like to receive its multicasted = RAs. No=85 It sends them to the ALL_HOSTS multicast group which it assumes will reach every host on the link, since that=92s the whole point of the = ALL_HOSTS multicast group when paired with LINK scope. >=20 >>>> strictly speaking MLD as a whole is only needed for interdomain >>>> multicast anyway. >>>=20 >>> Disagree - beyond just interdomain multicast, Ethernet has >>> link-layer multicast builtin. There is no 'broadcast' address >>> anymore in Ethernet since some time, replaced by 'multicast': >>> supposedly better at saving battery and other advantages. >>>=20 >>>> on the local link you join a MC group by kind-of self declaration >>>> ("hey I consider myself part of that group >>>=20 >>> That is an Ethernet message. >>=20 >> no. that's a decision taken somewhere in the software/stack. no need >> for any packet here. >=20 > Well. I cant put my wireshark in monitor mode right now but if I = could > I would tell the name of the Ethernet message on WiFi (a management > frame) which joins link-layer multicast. WiFi !=3D Ethernet. 802.11 !=3D 802.1, 802.3, etc. Management Frames 802.11 management frames enable stations to establish and maintain = communications. The following are common 802.11 management frame = subtypes: Management frames are unique to WiFi. >=20 >>> Some cards send that message, others don't. All should. >>>=20 >>>> so I'm interested in certain traffic and hence instruct my stack >>>> to listen to/process packets with certain addresses"). no need >>>> of MLD for that action. >>>=20 >>> How does the Ethernet layer know this is a Router, and not a Host? >>> Only by knowing that it can join the all-hosts or all-routers >>> link-layer address. And only the IP stack knows whether it's a >>> Host or a Router. So the IP stack should tell the Ethernet layer >>> to make that link-layer join. >>=20 >> which it does, as a stack-internal decision. "once I'm a router get >> me everything sent to ff02::1/33:33:00:00:00:01. in addition - given >> I'm a node anyway - get me everything for ff02::2". no need to send >> any packet for all this. >=20 > In that same way, the Host must be able to tell everybody else whether > or that Host is interested in receiving the multicasted RAs. Nope=85 It either listens or it doesn=92t. According to IPv6, a host = must listen to all hosts and a router must listen to all routers and all hosts, but = that=92s merely by convention. Nothing in the hardware. No packets sent to say =93I=92m now listening for this.=94 It just = starts listening. It=92s like changing channels on your TV=85. You don=92t tell the old TV = station that you=92re tuning out and the new station that you=92re tuning in. = You just change which frequency your local tuner is listening to. Owen >=20 > Alex >=20 >>=20 >> best >>=20 >> Enno >>=20 >>=20 >>=20 >>=20 >>=20 >>>=20 >>> Yours, >>>=20 >>> Alex >>>=20 >>>> but "joining" on the local-link doesn't need MLD. >>>>=20 >>>> best >>>>=20 >>>> Enno >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> Alex >>>>>=20 >>>>> Le 23/07/2015 13:51, Ole Troan a ??crit : >>>>>> Alexandru, >>>>>>=20 >>>>>> I???m afraid I couldn???t interpret your message. would >>>>>> someone else be able to translate? >>>>>>=20 >>>>>> cheers, Ole >>>>>>=20 >>>>>>>>=20 >>>>>>>> I do wonder if we should expand that exception to all >>>>>>>> link-scope multicast addresses. >>>>>>>>=20 >>>>>>>=20 >>>>>>> I would beg to disagree. >>>>>>>=20 >>>>>>> If we expand that to all link-scoped groups, may lead to >>>>>>> dismantling IPv6 dependence on 33::1 - ff:ff:ff:ff:ff >>>>>>> would be sufficient. >>>>>>>=20 >>>>>>> My oppinion would rather be to modify the MLD RFC to >>>>>>> mandate MLD joins for all scopes. >>>>>>>=20 >>>>>>> Ethernet has primitives for joining the corresponding >>>>>>> link-layer groups, and in some cases they are used. Maybe >>>>>>> all should use them. >>>>>>>=20 >>>>>>>> the bridge implementors I speak to tell me that they >>>>>>>> don???t have enough state to do MLD snooping for >>>>>>>> link-local scoped multicast addresses anyway... >>>>>>>=20 >>>>>>> This may be dumb from my side, but why dont bridge >>>>>>> implementers use link-layer multicast? They shouldnt >>>>>>> implement MLD, and not snoop it. The Hosts should send the >>>>>>> necessary link-layer multicast joins (triggered by >>>>>>> themselves sending MLD REPORT for these groups) to the >>>>>>> bridge addresses. >>>>>>>=20 >>>>>>> Alex >>>>>>>=20 >>>>>>>> cheers, Ole >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ v6ops mailing >>>>> list v6ops@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>=20 >>>=20 >>> _______________________________________________ v6ops mailing list >>> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_2DC693FC-0F05-4616-AB27-B8961DD4C359 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Jul 23, 2015, at 07:34 , Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:



Le 23/07/2015 15:01, Enno Rey a =E9crit :
Hi,


Inform = the sender willingnes to be part of the group.  If not part
of group, then sender will not send it.  Same concept at = L2 and at
L3.

wrong. the sender of a MC message just sends it out, = regardless if
somebody listens or not.

I agree.

the router(s) helping to = distribute this message (in case of
interdomain MC) only = have to know (=3D are interested) if there's at
least one = interested listener on an adjacent link. neither the
sender = nor the router(s) have any interest (or need to have that) in
individual listeners.

YEs, that's so for multicast across multiple subnets.

But on the same link (same subnet) the Router = sends these RAs, so it
must be able to know which Host = would like to receive its multicasted RAs.

No=85 It sends = them to the ALL_HOSTS multicast group which it assumes
will = reach every host on the link, since that=92s the whole point of the = ALL_HOSTS
multicast group when paired with LINK = scope.



strictly = speaking MLD as a whole is only needed for interdomain
multicast anyway.

Disagree - beyond just interdomain multicast, Ethernet has
link-layer multicast builtin.  There is no 'broadcast' = address
anymore in Ethernet since some time, replaced by = 'multicast':
supposedly better at saving battery and other = advantages.

on the local link you join a MC group by kind-of self = declaration
("hey I consider myself part of that group

That is an Ethernet message.

no. that's a decision taken = somewhere in the software/stack. no need
for any packet = here.

Well.  I cant put = my wireshark in monitor mode right now but if I could
I = would tell the name of the Ethernet message on WiFi (a management
frame) which joins link-layer multicast.

WiFi !=3D = Ethernet.

802.11 !=3D 802.1, 802.3, = etc.

Management Frames

802.11 management frames = enable stations to establish and maintain communications. The following = are common 802.11 management frame subtypes:



Management frames are unique to = WiFi.



Some cards send that message, others don't.  All = should.

so I'm interested in certain traffic and hence instruct my = stack
to listen to/process packets with certain = addresses"). no need
of MLD for that action.

How does the Ethernet layer know = this is a Router, and not a Host?
Only by knowing that it = can join the all-hosts or all-routers
link-layer address. =  And only the IP stack knows whether it's a
Host or a = Router. So the IP stack should tell the Ethernet layer
to = make that link-layer join.

which= it does, as a stack-internal decision. "once I'm a router get
me everything sent to ff02::1/33:33:00:00:00:01. in addition = - given
I'm a node anyway - get me everything for = ff02::2". no need to send
any packet for all this.

In that same way, the Host must = be able to tell everybody else whether
or that Host is = interested in receiving the multicasted RAs.

Nope=85 It = either listens or it doesn=92t. According to IPv6, a host must = listen
to all hosts and a router must listen to all routers = and all hosts, but that=92s
merely by = convention.

Nothing in the = hardware.

No packets sent to say = =93I=92m now listening for this.=94 It just starts = listening.

It=92s like changing = channels on your TV=85. You don=92t tell the old TV = station
that you=92re tuning out and the new station that = you=92re tuning in. You just
change which frequency your local = tuner is listening to.

Owen


Alex


best

Enno






Yours,

Alex

but "joining" on the local-link doesn't need = MLD.

best

Enno






Alex

Le = 23/07/2015 13:51, Ole Troan a ??crit :
Alexandru,

I???m = afraid I couldn???t interpret your message. would
someone = else be able to translate?

cheers, Ole


I do wonder if we should expand = that exception to all
link-scope multicast addresses.


I would beg to = disagree.

If we expand that to all = link-scoped groups, may lead to
dismantling IPv6 = dependence on 33::1 - ff:ff:ff:ff:ff
would be = sufficient.

My oppinion would rather be to = modify the MLD RFC to
mandate MLD joins for all scopes.

Ethernet has primitives for joining the = corresponding
link-layer groups, and in some cases they = are used. Maybe
all should use them.

the bridge implementors = I speak to tell me that they
don???t have enough state to = do MLD snooping for
link-local scoped multicast addresses = anyway...

This may be dumb = from my side, but why dont bridge
implementers use = link-layer multicast?  They shouldnt
implement MLD, = and not snoop it. The Hosts should send the
necessary = link-layer multicast joins (triggered by
themselves = sending MLD REPORT for these groups) to the
bridge = addresses.

Alex

cheers, Ole


_______________________________________________ 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

= --Apple-Mail=_2DC693FC-0F05-4616-AB27-B8961DD4C359-- From nobody Thu Jul 23 19:26:34 2015 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 83BE61A8AF9 for ; Thu, 23 Jul 2015 19:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, 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 mbcjYSDl0Yt8 for ; Thu, 23 Jul 2015 19:26:32 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 14A491A8A7C for ; Thu, 23 Jul 2015 19:26:31 -0700 (PDT) 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.2) with ESMTP id t6O2QMNF029665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Jul 2015 19:26:24 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_E01AB074-ACF3-4DDA-B194-2E23496DD7B5" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Owen DeLong In-Reply-To: Date: Thu, 23 Jul 2015 19:26:22 -0700 Message-Id: References: To: Francisco Paletta X-Mailer: Apple Mail (2.2098) Archived-At: Cc: v6ops list Subject: Re: [v6ops] As promised... 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, 24 Jul 2015 02:26:33 -0000 --Apple-Mail=_E01AB074-ACF3-4DDA-B194-2E23496DD7B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 That=E2=80=99s sort of akin to saying =E2=80=9CDDoS must not disrupt a = device=E2=80=99s normal operation=E2=80=9D. If you flood a link with traffic, stuff=E2=80=99s going to break. There are scenarios where multicast traffic can get out of control, = including RA and related. Reducing the number of multicast RAs to those periodic ones necessary to = refresh timers of every host on the link just makes sense. As such, I think the consequences are perfectly valid justification in = addition to the other points raised. Owen > On Jul 23, 2015, at 10:39 , Francisco Paletta = wrote: >=20 > Hello, >=20 > I believe it's a good "best practice". >=20 > I just have suggestions regarding the "3. Consequences" points 2 and = 3. Despite the fact that frequent RA messages are causing those = consequences, they should not be used as base to support this = recommendation. >=20 > In my opinion, the frequency or broadness of RA messages should not = cause a device to disrupt it's communication. The device must deal with = it another way. Obviously they can benefit from the changes in RA = messages behaviors. But should not be the motivation. >=20 > Nevertheless I agree that once the device receives an information and = have to deal with it, it spends power on that process and we should = control that to favor battery-powered devices. >=20 > Regards, >=20 > Francisco Paletta >=20 >=20 > 2015-07-23 10:10 GMT-03:00 Fred Baker (fred) >: > = https://tools.ietf.org/html/draft-ietf-v6ops-reducing-ra-energy-consumptio= n = > "Reducing energy consumption of Router Advertisements", Andrew > Yourtchenko, Lorenzo Colitti, 2015-07-23, >=20 > We had quite a bit of discussion Tuesday, especially considering the = length (or brevity) of this draft. >=20 > I'd suggest you read it. Especially given the number of "+2" comments = on the list, I tend to think we can come to consensus relatively quickly = on it. If there are lingering issues, let's get them out of the way. >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops = >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_E01AB074-ACF3-4DDA-B194-2E23496DD7B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 That=E2=80=99s sort of akin to saying =E2=80=9CDDoS must not = disrupt a device=E2=80=99s normal operation=E2=80=9D.

If you flood a link with traffic, = stuff=E2=80=99s going to break.

There are scenarios where multicast = traffic can get out of control, including RA and related.

Reducing the number of = multicast RAs to those periodic ones necessary to refresh timers of = every host on the link just makes sense.

As such, I think the consequences are = perfectly valid justification in addition to the other points = raised.

Owen

On Jul 23, 2015, at 10:39 , = Francisco Paletta <francisco@assembler.com.br> wrote:

Hello,

I believe it's a good "best = practice".

I = just have suggestions regarding the "3. Consequences" points 2 and 3. = Despite the fact that frequent RA messages are causing those = consequences, they should not be used as base to support this = recommendation.

In my opinion, the frequency or broadness of RA messages = should not cause a device to disrupt it's communication. The device must = deal with it another way. Obviously they can benefit from the changes in = RA messages behaviors. But should not be the motivation.

Nevertheless I agree = that once the device receives an information and have to deal with it, = it spends power on that process and we should control that to = favor battery-powered devices.

Regards,

Francisco Paletta


2015-07-23 10:10 GMT-03:00 Fred Baker (fred) <fred@cisco.com>:
https://tools.ietf.org/html/draft-ietf-v6ops-reducing-ra-energy= -consumption
  "Reducing energy consumption of Router Advertisements", Andrew
  Yourtchenko, Lorenzo Colitti, 2015-07-23,

We had quite a bit of discussion Tuesday, especially considering the = length (or brevity) of this draft.

I'd suggest you read it. Especially given the number of "+2" comments on = the list, I tend to think we can come to consensus relatively quickly on = it. If there are lingering issues, let's get them out of the way.

_______________________________________________
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

= --Apple-Mail=_E01AB074-ACF3-4DDA-B194-2E23496DD7B5-- From nobody Thu Jul 23 20:05:58 2015 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 774931ACE3D for ; Thu, 23 Jul 2015 20:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 gacB2k1_icc8 for ; Thu, 23 Jul 2015 20:05:54 -0700 (PDT) Received: from mail-vn0-f50.google.com (mail-vn0-f50.google.com [209.85.216.50]) (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 8E6BE1ACD38 for ; Thu, 23 Jul 2015 20:05:53 -0700 (PDT) Received: by vnk197 with SMTP id 197so4341507vnk.3 for ; Thu, 23 Jul 2015 20:05:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tj/cz7uaBUREWZckaumRmzZaH//AAdk1q5dvyktySBg=; b=FxV7qqVTBBJfB/hJv+1/+Lb/mI8wVqKB9jMRVulhwSBXSBxEHU/vX7ZZR5qaQy6EGg xYo8yiuItv6IIOkmET79B5gAAXu5NItTcv05mVI1EeT2XtMWmYY4o7Kd9CnvGcIWG2S9 VqYs6HXiy0+jlfjz8rUkVR17OuYflRFCnBpYkcZOVWOsx522b0fCy/vQwCq0F+HseekB 6dj2pnCdRBkQZ9DO7huPoZHcfGciK0iiP5ht5VuKITYwHnf9mM+3+9VxI4p4V6E/C+h5 EqaABHn6y4RukP4S1d8938PBK1A12zRtggOVtRVlRdE788oKGgSC/SLK4L64GyIPY91Z e7cQ== X-Gm-Message-State: ALoCoQmPuqpD1aQPFmevmXEOaBgvpxGv1lKyW73jObUqwYwQPv9cmnBgoBJYDn9RZardLcXmwOhs X-Received: by 10.52.17.2 with SMTP id k2mr14154451vdd.15.1437707152813; Thu, 23 Jul 2015 20:05:52 -0700 (PDT) Received: from mail-vn0-f52.google.com (mail-vn0-f52.google.com. [209.85.216.52]) by smtp.gmail.com with ESMTPSA id b7sm1449023vda.28.2015.07.23.20.05.52 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Jul 2015 20:05:52 -0700 (PDT) Received: by vnaa140 with SMTP id a140so4348356vna.2 for ; Thu, 23 Jul 2015 20:05:52 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.52.181.6 with SMTP id ds6mr14073550vdc.60.1437707152070; Thu, 23 Jul 2015 20:05:52 -0700 (PDT) Received: by 10.31.206.193 with HTTP; Thu, 23 Jul 2015 20:05:52 -0700 (PDT) In-Reply-To: References: Date: Fri, 24 Jul 2015 00:05:52 -0300 Message-ID: From: Francisco Paletta To: Owen DeLong Content-Type: multipart/alternative; boundary=bcaec547cbb5173379051b96488e Archived-At: Cc: v6ops list Subject: Re: [v6ops] As promised... 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, 24 Jul 2015 03:05:57 -0000 --bcaec547cbb5173379051b96488e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm not saying I don't support the recommendation in this draft. I acknowledge all the benefits. I'm just saying that the motivation should not be the issues presented on the references [1] and [2] on the doc. We can change configurations on the routers and achieve best scenario for devices but we cannot guarantee that in all cases, and therefore the devices need to be able to handle heavy traffic and avoid situations like the ones referenced (normal scenarios). Using a metaphor to compare, this is like asking to reduce a speed limit on a road because drivers don't use safety belt. Of course there are many safety reasons to slow down traffic speed, but should not be because people don't want to buckle up... Francisco 2015-07-23 23:26 GMT-03:00 Owen DeLong : > That=E2=80=99s sort of akin to saying =E2=80=9CDDoS must not disrupt a de= vice=E2=80=99s normal > operation=E2=80=9D. > > If you flood a link with traffic, stuff=E2=80=99s going to break. > > There are scenarios where multicast traffic can get out of control, > including RA and related. > > Reducing the number of multicast RAs to those periodic ones necessary to > refresh timers of every host on the link just makes sense. > > As such, I think the consequences are perfectly valid justification in > addition to the other points raised. > > Owen > > On Jul 23, 2015, at 10:39 , Francisco Paletta > wrote: > > Hello, > > I believe it's a good "best practice". > > I just have suggestions regarding the "3. Consequences" points 2 and 3. > Despite the fact that frequent RA messages are causing those consequences= , > they should not be used as base to support this recommendation. > > In my opinion, the frequency or broadness of RA messages should not cause > a device to disrupt it's communication. The device must deal with it > another way. Obviously they can benefit from the changes in RA messages > behaviors. But should not be the motivation. > > Nevertheless I agree that once the device receives an information and hav= e > to deal with it, it spends power on that process and we should control th= at > to favor battery-powered devices. > > Regards, > > Francisco Paletta > > > 2015-07-23 10:10 GMT-03:00 Fred Baker (fred) : > >> >> https://tools.ietf.org/html/draft-ietf-v6ops-reducing-ra-energy-consumpt= ion >> "Reducing energy consumption of Router Advertisements", Andrew >> Yourtchenko, Lorenzo Colitti, 2015-07-23, >> >> We had quite a bit of discussion Tuesday, especially considering the >> length (or brevity) of this draft. >> >> I'd suggest you read it. Especially given the number of "+2" comments on >> the list, I tend to think we can come to consensus relatively quickly on >> it. If there are lingering issues, let's get them out of the way. >> >> _______________________________________________ >> 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 > > > --bcaec547cbb5173379051b96488e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I'm not saying I don't support= the recommendation in this draft. I acknowledge all the benefits.

<= /div>
I'm just saying that the motivation should not be the issues = presented on the references [1] and [2] on the doc. We can change configura= tions on the routers and achieve best scenario for devices but we cannot gu= arantee that in all cases, and therefore the devices need to be able to han= dle heavy traffic and avoid situations like the ones referenced (normal sce= narios).

Using a metaphor to compar= e, this is like asking to reduce a speed limit on a road because drivers do= n't use safety belt. Of course there are many safety reasons to slow do= wn traffic speed, but should not be because people don't want to buckle= up...

Francisco
<= /div>

2015-07-23 23:26 GMT-03:00 Owen DeLong <owen@= delong.com>:
That=E2=80=99s sort of akin to saying =E2=80=9CDDoS m= ust not disrupt a device=E2=80=99s normal operation=E2=80=9D.

If you flood a link with traffic, stuff=E2=80=99s going to break.

There are scenarios where multicast traffic can get o= ut of control, including RA and related.

Reducing = the number of multicast RAs to those periodic ones necessary to refresh tim= ers of every host on the link just makes sense.

As= such, I think the consequences are perfectly valid justification in additi= on to the other points raised.

Owen
=

On Jul 23, 2015, at 10:39 , Fr= ancisco Paletta <francisco@assembler.com.br> wrote:

Hello,

I believe it's a good &qu= ot;best practice".

I just have suggestions re= garding the "3. Consequences" points 2 and 3. Despite the fact th= at frequent RA messages are causing those consequences, they should not be = used as base to support this recommendation.

In my= opinion, the frequency or broadness of RA messages should not cause a devi= ce to disrupt it's communication. The device must deal with it another = way. Obviously they can benefit from the changes in RA messages behaviors. = But should not be the motivation.

Nevertheless I a= gree that once the device receives an information and have to deal with it,= it spends power on that process and we should control that to favor=C2=A0b= attery-powered devices.

Regards,

Francisco Paletta


2015-07-23 10:10 GMT-03:00 F= red Baker (fred) <fred@cisco.com>:
https://tools.ietf.= org/html/draft-ietf-v6ops-reducing-ra-energy-consumption
=C2=A0 "Reducing energy consumption of Router Advertisements", An= drew
=C2=A0 Yourtchenko, Lorenzo Colitti, 2015-07-23,

We had quite a bit of discussion Tuesday, especially considering the length= (or brevity) of this draft.

I'd suggest you read it. Especially given the number of "+2" = comments on the list, I tend to think we can come to consensus relatively q= uickly on it. If there are lingering issues, let's get them out of the = way.

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


_______________________________________________
v6ops mailing list
v6ops@ietf.org
http= s://www.ietf.org/mailman/listinfo/v6ops

--bcaec547cbb5173379051b96488e-- From nobody Thu Jul 23 22:04:59 2015 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 8A1501B2DE3 for ; Thu, 23 Jul 2015 22:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTSREX_D2DfP for ; Thu, 23 Jul 2015 22:04:56 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A86CB1B2DDC for ; Thu, 23 Jul 2015 22:04:55 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6O54o6t000781; Fri, 24 Jul 2015 07:04:50 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0F283200F18; Fri, 24 Jul 2015 07:08:28 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 01709200E05; Fri, 24 Jul 2015 07:08:28 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.8]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6O54mDa007019; Fri, 24 Jul 2015 07:04:50 +0200 To: Owen DeLong References: <55AE42A4.8020908@gmail.com> <5CD05758-D7B7-476D-9936-E5A1D0614AF8@employees.org> <55B0D356.7070505@gmail.com> <6666FED5-227B-496F-B5F5-2883A12F9B96@employees.org> <55B0DB2B.1030703@gmail.com> <20150723122710.GX57117@ernw.de> <55B0E2C5.2060309@gmail.com> <20150723130151.GA57117@ernw.de> <55B0FB82.9070809@gmail.com> From: Alexandru Petrescu Message-ID: <55B1C770.5080301@gmail.com> Date: Fri, 24 Jul 2015 07:04:48 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.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 Subject: Re: [v6ops] ref Hosts dont MLD to join LL groups 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, 24 Jul 2015 05:04:58 -0000 I agree unicast RA in response to RS makes sense. Ideally unicast RAs in responses to unicast RSs. Le 24/07/2015 03:28, Owen DeLong a écrit : > >> On Jul 23, 2015, at 07:34 , Alexandru Petrescu >> > > wrote: >> >> >> >> Le 23/07/2015 15:01, Enno Rey a écrit : >>> Hi, >>> >>>> >>>> Inform the sender willingnes to be part of the group. If not >>>> part of group, then sender will not send it. Same concept at >>>> L2 and at L3. >>> >>> wrong. the sender of a MC message just sends it out, regardless >>> if somebody listens or not. >> >> I agree. >> >>> the router(s) helping to distribute this message (in case of >>> interdomain MC) only have to know (= are interested) if there's >>> at least one interested listener on an adjacent link. neither >>> the sender nor the router(s) have any interest (or need to have >>> that) in individual listeners. >> >> YEs, that's so for multicast across multiple subnets. >> >> But on the same link (same subnet) the Router sends these RAs, so >> it must be able to know which Host would like to receive its >> multicasted RAs. > > No… It sends them to the ALL_HOSTS multicast group which it assumes > will reach every host on the link, since that’s the whole point of > the ALL_HOSTS multicast group when paired with LINK scope. YEs. But it's a matter of semantics. A Host may want to act as a Host sometimes (join all-hosts) and as a router other times (join the all-routers group only). For example, a smartphone would need to act as a Host when RS/RA but would need to be a router when doing 64share (stop its RSs, unsubscribe all-hosts, etc). To paraphrase, that's the whole point of that being a group a multicast and not using broadcast - not just a fancy word. Alex > > >> >>>>> strictly speaking MLD as a whole is only needed for >>>>> interdomain multicast anyway. >>>> >>>> Disagree - beyond just interdomain multicast, Ethernet has >>>> link-layer multicast builtin. There is no 'broadcast' address >>>> anymore in Ethernet since some time, replaced by 'multicast': >>>> supposedly better at saving battery and other advantages. >>>> >>>>> on the local link you join a MC group by kind-of self >>>>> declaration ("hey I consider myself part of that group >>>> >>>> That is an Ethernet message. >>> >>> no. that's a decision taken somewhere in the software/stack. no >>> need for any packet here. >> >> Well. I cant put my wireshark in monitor mode right now but if I >> could I would tell the name of the Ethernet message on WiFi (a >> management frame) which joins link-layer multicast. > > WiFi != Ethernet. > > 802.11 != 802.1, 802.3, etc. > > > Management Frames > > 802.11 management frames enable stations to establish and maintain > communications. The following are common 802.11 management frame > subtypes: > > > > Management frames are unique to WiFi. > > >> >>>> Some cards send that message, others don't. All should. >>>> >>>>> so I'm interested in certain traffic and hence instruct my >>>>> stack to listen to/process packets with certain addresses"). >>>>> no need of MLD for that action. >>>> >>>> How does the Ethernet layer know this is a Router, and not a >>>> Host? Only by knowing that it can join the all-hosts or >>>> all-routers link-layer address. And only the IP stack knows >>>> whether it's a Host or a Router. So the IP stack should tell >>>> the Ethernet layer to make that link-layer join. >>> >>> which it does, as a stack-internal decision. "once I'm a router >>> get me everything sent to ff02::1/33:33:00:00:00:01. in addition >>> - given I'm a node anyway - get me everything for ff02::2". no >>> need to send any packet for all this. >> >> In that same way, the Host must be able to tell everybody else >> whether or that Host is interested in receiving the multicasted >> RAs. > > Nope… It either listens or it doesn’t. According to IPv6, a host must > listen to all hosts and a router must listen to all routers and all > hosts, but that’s merely by convention. > > Nothing in the hardware. > > No packets sent to say “I’m now listening for this.” It just starts > listening. > > It’s like changing channels on your TV…. You don’t tell the old TV > station that you’re tuning out and the new station that you’re tuning > in. You just change which frequency your local tuner is listening > to. > > Owen > >> >> Alex >> >>> >>> best >>> >>> Enno >>> >>> >>> >>> >>> >>>> >>>> Yours, >>>> >>>> Alex >>>> >>>>> but "joining" on the local-link doesn't need MLD. >>>>> >>>>> best >>>>> >>>>> Enno >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> Alex >>>>>> >>>>>> Le 23/07/2015 13:51, Ole Troan a ??crit : >>>>>>> Alexandru, >>>>>>> >>>>>>> I???m afraid I couldn???t interpret your message. would >>>>>>> someone else be able to translate? >>>>>>> >>>>>>> cheers, Ole >>>>>>> >>>>>>>>> >>>>>>>>> I do wonder if we should expand that exception to >>>>>>>>> all link-scope multicast addresses. >>>>>>>>> >>>>>>>> >>>>>>>> I would beg to disagree. >>>>>>>> >>>>>>>> If we expand that to all link-scoped groups, may lead >>>>>>>> to dismantling IPv6 dependence on 33::1 - >>>>>>>> ff:ff:ff:ff:ff would be sufficient. >>>>>>>> >>>>>>>> My oppinion would rather be to modify the MLD RFC to >>>>>>>> mandate MLD joins for all scopes. >>>>>>>> >>>>>>>> Ethernet has primitives for joining the corresponding >>>>>>>> link-layer groups, and in some cases they are used. >>>>>>>> Maybe all should use them. >>>>>>>> >>>>>>>>> the bridge implementors I speak to tell me that they >>>>>>>>> don???t have enough state to do MLD snooping for >>>>>>>>> link-local scoped multicast addresses anyway... >>>>>>>> >>>>>>>> This may be dumb from my side, but why dont bridge >>>>>>>> implementers use link-layer multicast? They shouldnt >>>>>>>> implement MLD, and not snoop it. The Hosts should send >>>>>>>> the necessary link-layer multicast joins (triggered by >>>>>>>> themselves sending MLD REPORT for these groups) to the >>>>>>>> bridge addresses. >>>>>>>> >>>>>>>> Alex >>>>>>>> >>>>>>>>> cheers, Ole >>>>>>> >>>>>> >>>>>> _______________________________________________ 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 Jul 23 22:10:19 2015 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 0FBB71A1A30 for ; Thu, 23 Jul 2015 22:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, 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 vMC6MS58gxrj for ; Thu, 23 Jul 2015 22:10:16 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 118281AC3A7 for ; Thu, 23 Jul 2015 22:10:16 -0700 (PDT) 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.2) with ESMTP id t6O5ACTd015133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Jul 2015 22:10:12 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Owen DeLong In-Reply-To: <55B1C770.5080301@gmail.com> Date: Thu, 23 Jul 2015 22:10:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <16051608-C9FF-4BF1-A6AE-0E3AB50DEE68@delong.com> References: <55AE42A4.8020908@gmail.com> <5CD05758-D7B7-476D-9936-E5A1D0614AF8@employees.org> <55B0D356.7070505@gmail.com> <6666FED5-227B-496F-B5F5-2883A12F9B96@employees.org> <55B0DB2B.1030703@gmail.com> <20150723122710.GX57117@ernw.de> <55B0E2C5.2060309@gmail.com> <20150723130151.GA57117@ernw.de> <55B0FB82.9070809@gmail.com> <55B1C770.5080301@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.2098) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] ref Hosts dont MLD to join LL groups 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, 24 Jul 2015 05:10:18 -0000 > On Jul 23, 2015, at 22:04 , Alexandru Petrescu = wrote: >=20 > I agree unicast RA in response to RS makes sense. Ideally unicast RAs > in responses to unicast RSs. >=20 > Le 24/07/2015 03:28, Owen DeLong a =E9crit : >>=20 >>> On Jul 23, 2015, at 07:34 , Alexandru Petrescu >>> >> > wrote: >>>=20 >>>=20 >>>=20 >>> Le 23/07/2015 15:01, Enno Rey a =E9crit : >>>> Hi, >>>>=20 >>>>>=20 >>>>> Inform the sender willingnes to be part of the group. If not >>>>> part of group, then sender will not send it. Same concept at >>>>> L2 and at L3. >>>>=20 >>>> wrong. the sender of a MC message just sends it out, regardless >>>> if somebody listens or not. >>>=20 >>> I agree. >>>=20 >>>> the router(s) helping to distribute this message (in case of >>>> interdomain MC) only have to know (=3D are interested) if there's >>>> at least one interested listener on an adjacent link. neither >>>> the sender nor the router(s) have any interest (or need to have >>>> that) in individual listeners. >>>=20 >>> YEs, that's so for multicast across multiple subnets. >>>=20 >>> But on the same link (same subnet) the Router sends these RAs, so >>> it must be able to know which Host would like to receive its >>> multicasted RAs. >>=20 >> No=85 It sends them to the ALL_HOSTS multicast group which it assumes >> will reach every host on the link, since that=92s the whole point of >> the ALL_HOSTS multicast group when paired with LINK scope. >=20 > YEs. But it's a matter of semantics. A Host may want to act as a = Host sometimes (join all-hosts) and as a router other times (join the = all-routers group only). I do not believe that is allowed under the standards. A router _IS_ a = host and is supposed to be a member of the all-hosts group. > For example, a smartphone would need to act as a Host when RS/RA but = would need to be a router when doing 64share (stop its RSs, unsubscribe = all-hosts, etc). No. This is not true. A host is not required to RS. But a router should not unsubscribe from = all-hosts. It is not required to (and usually shouldn=92t) act on RAs = received on an interface for which it is an active router, but that does = not mean that it can unsubscribe from the all-hosts multicast group. > To paraphrase, that's the whole point of that being a group a = multicast and not using broadcast - not just a fancy word. Um=85 The fact of the matter is that all hosts with link scope is = morally equivalent to broadcast and is also very rarely used. Owen >=20 > Alex >=20 >=20 >>=20 >>=20 >>>=20 >>>>>> strictly speaking MLD as a whole is only needed for >>>>>> interdomain multicast anyway. >>>>>=20 >>>>> Disagree - beyond just interdomain multicast, Ethernet has >>>>> link-layer multicast builtin. There is no 'broadcast' address >>>>> anymore in Ethernet since some time, replaced by 'multicast': >>>>> supposedly better at saving battery and other advantages. >>>>>=20 >>>>>> on the local link you join a MC group by kind-of self >>>>>> declaration ("hey I consider myself part of that group >>>>>=20 >>>>> That is an Ethernet message. >>>>=20 >>>> no. that's a decision taken somewhere in the software/stack. no >>>> need for any packet here. >>>=20 >>> Well. I cant put my wireshark in monitor mode right now but if I >>> could I would tell the name of the Ethernet message on WiFi (a >>> management frame) which joins link-layer multicast. >>=20 >> WiFi !=3D Ethernet. >>=20 >> 802.11 !=3D 802.1, 802.3, etc. >>=20 >>=20 >> Management Frames >>=20 >> 802.11 management frames enable stations to establish and maintain >> communications. The following are common 802.11 management frame >> subtypes: >>=20 >>=20 >>=20 >> Management frames are unique to WiFi. >>=20 >>=20 >>>=20 >>>>> Some cards send that message, others don't. All should. >>>>>=20 >>>>>> so I'm interested in certain traffic and hence instruct my >>>>>> stack to listen to/process packets with certain addresses"). >>>>>> no need of MLD for that action. >>>>>=20 >>>>> How does the Ethernet layer know this is a Router, and not a >>>>> Host? Only by knowing that it can join the all-hosts or >>>>> all-routers link-layer address. And only the IP stack knows >>>>> whether it's a Host or a Router. So the IP stack should tell >>>>> the Ethernet layer to make that link-layer join. >>>>=20 >>>> which it does, as a stack-internal decision. "once I'm a router >>>> get me everything sent to ff02::1/33:33:00:00:00:01. in addition >>>> - given I'm a node anyway - get me everything for ff02::2". no >>>> need to send any packet for all this. >>>=20 >>> In that same way, the Host must be able to tell everybody else >>> whether or that Host is interested in receiving the multicasted >>> RAs. >>=20 >> Nope=85 It either listens or it doesn=92t. According to IPv6, a host = must >> listen to all hosts and a router must listen to all routers and all >> hosts, but that=92s merely by convention. >>=20 >> Nothing in the hardware. >>=20 >> No packets sent to say =93I=92m now listening for this.=94 It just = starts >> listening. >>=20 >> It=92s like changing channels on your TV=85. You don=92t tell the old = TV >> station that you=92re tuning out and the new station that you=92re = tuning >> in. You just change which frequency your local tuner is listening >> to. >>=20 >> Owen >>=20 >>>=20 >>> Alex >>>=20 >>>>=20 >>>> best >>>>=20 >>>> Enno >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> Yours, >>>>>=20 >>>>> Alex >>>>>=20 >>>>>> but "joining" on the local-link doesn't need MLD. >>>>>>=20 >>>>>> best >>>>>>=20 >>>>>> Enno >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> Alex >>>>>>>=20 >>>>>>> Le 23/07/2015 13:51, Ole Troan a ??crit : >>>>>>>> Alexandru, >>>>>>>>=20 >>>>>>>> I???m afraid I couldn???t interpret your message. would >>>>>>>> someone else be able to translate? >>>>>>>>=20 >>>>>>>> cheers, Ole >>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> I do wonder if we should expand that exception to >>>>>>>>>> all link-scope multicast addresses. >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> I would beg to disagree. >>>>>>>>>=20 >>>>>>>>> If we expand that to all link-scoped groups, may lead >>>>>>>>> to dismantling IPv6 dependence on 33::1 - >>>>>>>>> ff:ff:ff:ff:ff would be sufficient. >>>>>>>>>=20 >>>>>>>>> My oppinion would rather be to modify the MLD RFC to >>>>>>>>> mandate MLD joins for all scopes. >>>>>>>>>=20 >>>>>>>>> Ethernet has primitives for joining the corresponding >>>>>>>>> link-layer groups, and in some cases they are used. >>>>>>>>> Maybe all should use them. >>>>>>>>>=20 >>>>>>>>>> the bridge implementors I speak to tell me that they >>>>>>>>>> don???t have enough state to do MLD snooping for >>>>>>>>>> link-local scoped multicast addresses anyway... >>>>>>>>>=20 >>>>>>>>> This may be dumb from my side, but why dont bridge >>>>>>>>> implementers use link-layer multicast? They shouldnt >>>>>>>>> implement MLD, and not snoop it. The Hosts should send >>>>>>>>> the necessary link-layer multicast joins (triggered by >>>>>>>>> themselves sending MLD REPORT for these groups) to the >>>>>>>>> bridge addresses. >>>>>>>>>=20 >>>>>>>>> Alex >>>>>>>>>=20 >>>>>>>>>> cheers, Ole >>>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ v6ops >>>>>>> mailing list v6ops@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ v6ops mailing >>>>> list v6ops@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>=20 >>>=20 >>> _______________________________________________ v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>=20 From nobody Fri Jul 24 00:51:57 2015 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 49A741B3015 for ; Fri, 24 Jul 2015 00:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWdsFW1RW315 for ; Fri, 24 Jul 2015 00:51:55 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::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 B3A911B2FF4 for ; Fri, 24 Jul 2015 00:51:48 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so16154305wib.1 for ; Fri, 24 Jul 2015 00:51:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=QSskCA2t7iRvLZ5Z4TTEqQnPwHHQLMXlAveLX1jsMQM=; b=yk0sOGizJDtLjG18p+cq4iVDWzzoGOBtLZZbAK/XYgmIoxGEcXIUupFLD0UojrmVs2 YxyyzuN2cv5UqCjdorhT0eQf5/htoPrkM2hImVNhuUjp0LqyjvhLUaGYkGOaE2thSHnl 4kKFX1rs7tgLZ19bdR+cjJgU7Vfv1xMaZdSk6OZVW7XbLL8e9yjfC9ZJUZ7eLh9kJoEM 8DpkkUXmg1m81o4T/E0yzRNNOVgf9gx9gl/nN/N7rakrbOx+PdLrYo6bsvOqFU665MTB t2wu25vHpcke8WjFk3ZV8C0VY9+QGGarLz3R6c+BaXbSDUyTNJLAW4HvK4NzJBGuD+4s 5Bpg== X-Received: by 10.194.23.36 with SMTP id j4mr23988239wjf.105.1437724307539; Fri, 24 Jul 2015 00:51:47 -0700 (PDT) Received: from ?IPv6:2001:67c:370:168:28cc:dc4c:9703:6781? ([2001:67c:370:168:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id c3sm11259918wja.3.2015.07.24.00.51.46 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 24 Jul 2015 00:51:46 -0700 (PDT) Message-ID: <55B1ED14.6030501@gmail.com> Date: Fri, 24 Jul 2015 19:45:24 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: IPv6 Operations References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> In-Reply-To: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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: Fri, 24 Jul 2015 07:51:56 -0000 I like -01 even better than -00. As well as the reference [TARP], you might add draft-smith-enhance-vne-with-ipv6 as a use case for a /64 per host (specifically per NVE, network virtual edge). Regards Brian From nobody Fri Jul 24 01:25:14 2015 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 13C7D1A00BE for ; Fri, 24 Jul 2015 01:25:13 -0700 (PDT) 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, 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 W_2a4f4kbroJ for ; Fri, 24 Jul 2015 01:25:11 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5D401A00D8 for ; Fri, 24 Jul 2015 01:25:09 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 566f1b55.0.839773.00-2378.2383639.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 24 Jul 2015 08:25:09 +0000 (UTC) X-MXL-Hash: 55b1f6652cda08c8-54d50f5b8352cc90a60fd58d1aa90426bab00b9c Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t6O8P8Th015938 for ; Fri, 24 Jul 2015 04:25:08 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t6O8P3LE015927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 24 Jul 2015 04:25:03 -0400 Received: from GAALPA1MSGHUBAA.ITServices.sbc.com (GAALPA1MSGHUBAA.itservices.sbc.com [130.8.218.150]) by alpi133.aldc.att.com (RSA Interceptor) for ; Fri, 24 Jul 2015 08:24:59 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.24]) by GAALPA1MSGHUBAA.ITServices.sbc.com ([130.8.218.150]) with mapi id 14.03.0224.002; Fri, 24 Jul 2015 04:24:58 -0400 From: "STARK, BARBARA H" To: v6ops list Thread-Topic: use of Teredo addresses in Apple devices Thread-Index: AdDF6S3NgWeVgLgjSKOp7/BiIjWFpA== Date: Fri, 24 Jul 2015 08:24:58 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61132A90D2D@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.233.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=QrfpKyOd c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=ALLY0qxVpFoA:10 a=zOBTX] X-AnalysisOut: [jUuO1YA:10 a=7asZlWqdK6GnX_Y_fgcA:9 a=CjuIK1q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2015072401)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: Subject: [v6ops] use of Teredo addresses in Apple devices 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, 24 Jul 2015 08:25:13 -0000 Great presentation on what Apple is doing to drive apps to implement IPv6. In thinking about use of the Teredo address space to advertise a prefix to = tethered devices, I do have a concern. In many of my personal home networke= d devices, I've purposefully disabled Teredo and ISATAP and even put in som= e rules to prevent the devices from accepting such addresses. I think this would be a reasonable use of a ULA. A PI might be even better.= I hear PIs are pretty easy to come by. The PI would have the advantage of = being known to come from an Apple device for this NAT64 purpose. That could= help with trouble shooting. Barbara From nobody Fri Jul 24 01:26:13 2015 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 C16641A0091 for ; Fri, 24 Jul 2015 01:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 YV2f0xvYautW for ; Fri, 24 Jul 2015 01:26:08 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id B18CC1A00EF for ; Fri, 24 Jul 2015 01:26:07 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1ZIYIw-0000EuC; Fri, 24 Jul 2015 10:26:06 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <55B09AE5.4040609@gmail.com> <2BBE839B-37FB-4EA2-982E-58028E7A13B6@nominum.com> <55B0F344.4090005@gmail.com> In-reply-to: Your message of "Thu, 23 Jul 2015 10:05:40 -0400 ." Date: Fri, 24 Jul 2015 10:26:06 +0200 Archived-At: Subject: Re: [v6ops] NAT64/DNS64 and DNSSEC 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, 24 Jul 2015 08:26:10 -0000 Based on the discussion after Stuart's presenation about IPv6 at Apple. Assuming NAT64 without 464XLAT, assuming we want local DNSSEC validation. The way to make it work would be 'bump-in-the-api'. One way of doing that, the comes it mind is to have the DNS resolver bypass any DNS64 by setting the CD bit and then after validation, at the request of the application synthesize AAAA records from A records based on the NAT64 prefix. I guess this is easy enough to add to for example getdns (https://getdnsapi.net/). One question is how an application would find out that it is running in a DNS64 environment. Another option is for getdns to do the probing and enable this option automatically. From nobody Fri Jul 24 01:30:21 2015 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 3CE591A0A85 for ; Fri, 24 Jul 2015 01:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.383 X-Spam-Level: X-Spam-Status: No, score=-4.383 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, J_CHICKENPOX_31=0.6, 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 SuWKUlTPcmA6 for ; Fri, 24 Jul 2015 01:30:12 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F5AB1A0381 for ; Fri, 24 Jul 2015 01:30:10 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6O8U8NP018623 for ; Fri, 24 Jul 2015 10:30:08 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6A80A200E17 for ; Fri, 24 Jul 2015 10:33:46 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 57D66202F8B for ; Fri, 24 Jul 2015 10:33:46 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.195]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6O8U7Fb006714 for ; Fri, 24 Jul 2015 10:30:08 +0200 To: v6ops@ietf.org References: <2D09D61DDFA73D4C884805CC7865E61132A90D2D@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Alexandru Petrescu Message-ID: <55B1F78E.5030104@gmail.com> Date: Fri, 24 Jul 2015 10:30:06 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61132A90D2D@GAALPA1MSGUSRBF.ITServices.sbc.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] use of Teredo addresses in Apple devices 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, 24 Jul 2015 08:30:20 -0000 I like the idea of dictionary-based addresses (abb1e apple). And wonder whether ULAs are appropriate here. (a PI would be better in a sense, but would not give an abb1e unless the registry provides them a PI with abb1e in it (?)). Alex Le 24/07/2015 10:24, STARK, BARBARA H a écrit : > Great presentation on what Apple is doing to drive apps to implement > IPv6. In thinking about use of the Teredo address space to advertise > a prefix to tethered devices, I do have a concern. In many of my > personal home networked devices, I've purposefully disabled Teredo > and ISATAP and even put in some rules to prevent the devices from > accepting such addresses. > > I think this would be a reasonable use of a ULA. A PI might be even > better. I hear PIs are pretty easy to come by. The PI would have the > advantage of being known to come from an Apple device for this NAT64 > purpose. That could help with trouble shooting. Barbara > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Fri Jul 24 01:32:22 2015 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 0A0D11A1A52 for ; Fri, 24 Jul 2015 01:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 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, 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 lLflnx1e6h3K for ; Fri, 24 Jul 2015 01:32:12 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7441C1A0A85 for ; Fri, 24 Jul 2015 01:32:06 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 0E375A1; Fri, 24 Jul 2015 10:32:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1437726725; bh=WC4lmCRK9XQY9NsgKrazZZpWkoqfAiUvuprxMaIzF/Q=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=uqUYqCNmh+4i6nlCN3TSwo0MTYuBIEHIHgvLthyKqeFp2SPUur1DE9syonsTlKY9j tut7oVXjCJn2B91LkMHrq9bJvgyWRl7SZTPUSLFuePDweDdLo9BCWnH2HZztRICrMy 0FcwIWB170I5bieLVdqYN2dlxw4urhrL4Ke1BKTI= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 07E759F; Fri, 24 Jul 2015 10:32:05 +0200 (CEST) Date: Fri, 24 Jul 2015 10:32:05 +0200 (CEST) From: Mikael Abrahamsson To: "STARK, BARBARA H" In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61132A90D2D@GAALPA1MSGUSRBF.ITServices.sbc.com> Message-ID: References: <2D09D61DDFA73D4C884805CC7865E61132A90D2D@GAALPA1MSGUSRBF.ITServices.sbc.com> 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 list Subject: Re: [v6ops] use of Teredo addresses in Apple devices 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, 24 Jul 2015 08:32:17 -0000 On Fri, 24 Jul 2015, STARK, BARBARA H wrote: > I think this would be a reasonable use of a ULA. I would not use ULA, since this is "special" in RFC6724. I would like to get something that ends up under the ::/0 label according to RFC6724. > A PI might be even better. I hear PIs are pretty easy to come by. The PI > would have the advantage of being known to come from an Apple device for > this NAT64 purpose. That could help with trouble shooting. Yes, I agree that PI would be optimal, but I am not opposed to using some other prefix such as the one Stuart suggested. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Fri Jul 24 01:37:47 2015 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 12B6F1A015F for ; Fri, 24 Jul 2015 01:37:46 -0700 (PDT) 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 RodPCHWFVnn6 for ; Fri, 24 Jul 2015 01:37:44 -0700 (PDT) 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 A2E1F1A0130 for ; Fri, 24 Jul 2015 01:37:44 -0700 (PDT) Received: by ykdu72 with SMTP id u72so14418936ykd.2 for ; Fri, 24 Jul 2015 01:37:44 -0700 (PDT) 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=YfYg73Sj7/XPBF3UaGUswWUSRIpwsESbXWpyWTYZ4kA=; b=YybXotAwA5n8+UWUIfc34cjuD2X4gIfA2YU7HCbkS7NzVUSeuqrdQNx2z6cF9U02/W wfH2Y2cHFcQ6eGpBiKctBCe3aKbFN6d6vR/QJdJcDEfB/c2YzukmwJTYvrqneVbuJIaF rTv6jBHgN6Z4uWWbyJPt1rzlX0GOTXZmJ6dBAl4LIg/NFEE4AlSHykv3mj26n0tT94xq 3hPzrhf3TiCGXC8jMVo5eHj0aQSU9ucAMTmlXhiBktzzWG5dPdNbZ5uPgppWzKx0urVU /JLR6EMbV45ziOoJ6JP4F1QSznAvorBGErpuI/zLJDMNZDVNrI9dk/+YWWc24h3/SxzG aEjA== 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=YfYg73Sj7/XPBF3UaGUswWUSRIpwsESbXWpyWTYZ4kA=; b=SleSpV60aSgaJChxM2Xrb22KjvGdt112YFMnbyPRoZdiRBKNeJ7wZjjG8qfHUlGF5q qOUg9j2/NAUKTwD+70ji3lLgAVXVQXceylUe30kTsn+IA45fzcyWq0kMTun7AoZfdvei ZNYRS7QL5411YyUiRnSJVEGUE/9u39U35bKnHByxCaBZSgHzdUIqBAHFNOkxFyOwKpGk z6MV9dEuOLBXe5A27xcN8LLfat0dr8wry2J87qnpkeZFSxy294iT0qODRHPCi2CsHdL4 78X7iHs4gRNrwQ2Tbd6rsdZLN6xPgicCFK3NyHR9LYxJVApSbQWKltUQ+yvHMRW2VewC xWWg== X-Gm-Message-State: ALoCoQlQEf9rn3yEKmt1Z3zUccLzlTJcnUwxTr+mPYJrQ3OWgqHAf/LwrO7Sgol5VsQDROjbPMUg X-Received: by 10.129.75.214 with SMTP id y205mr14258981ywa.65.1437727064010; Fri, 24 Jul 2015 01:37:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.8.201 with HTTP; Fri, 24 Jul 2015 01:37:24 -0700 (PDT) In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61132A90D2D@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E61132A90D2D@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Lorenzo Colitti Date: Fri, 24 Jul 2015 10:37:24 +0200 Message-ID: To: "STARK, BARBARA H" Content-Type: multipart/alternative; boundary=001a113f3d0aef9352051b9aeaf6 Archived-At: Cc: v6ops list Subject: Re: [v6ops] use of Teredo addresses in Apple devices 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, 24 Jul 2015 08:37:46 -0000 --001a113f3d0aef9352051b9aeaf6 Content-Type: text/plain; charset=UTF-8 I'm not sure that using ULAs is a good idea. ULAs are not likely to be representative of real NAT64 deployments, which use global addresses. On Fri, Jul 24, 2015 at 10:24 AM, STARK, BARBARA H wrote: > Great presentation on what Apple is doing to drive apps to implement IPv6. > In thinking about use of the Teredo address space to advertise a prefix to > tethered devices, I do have a concern. In many of my personal home > networked devices, I've purposefully disabled Teredo and ISATAP and even > put in some rules to prevent the devices from accepting such addresses. > > I think this would be a reasonable use of a ULA. A PI might be even > better. I hear PIs are pretty easy to come by. The PI would have the > advantage of being known to come from an Apple device for this NAT64 > purpose. That could help with trouble shooting. > Barbara > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a113f3d0aef9352051b9aeaf6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm not sure that using ULAs is a good idea. ULAs are = not likely to be representative of real NAT64 deployments, which use global= addresses.

On Fri= , Jul 24, 2015 at 10:24 AM, STARK, BARBARA H <bs7652@att.com> = wrote:
Great presentation on what Apple i= s doing to drive apps to implement IPv6.
In thinking about use of the Teredo address space to advertise a prefix to = tethered devices, I do have a concern. In many of my personal home networke= d devices, I've purposefully disabled Teredo and ISATAP and even put in= some rules to prevent the devices from accepting such addresses.

I think this would be a reasonable use of a ULA. A PI might be even better.= I hear PIs are pretty easy to come by. The PI would have the advantage of = being known to come from an Apple device for this NAT64 purpose. That could= help with trouble shooting.
Barbara

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

--001a113f3d0aef9352051b9aeaf6-- From nobody Fri Jul 24 01:58:19 2015 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 B21171A21B2 for ; Fri, 24 Jul 2015 01:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.562 X-Spam-Level: X-Spam-Status: No, score=-1.562 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, SPF_HELO_PASS=-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 DcrNZxli3NTo for ; Fri, 24 Jul 2015 01:58:16 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 672081A1BCC for ; Fri, 24 Jul 2015 01:58:16 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id t6O8uUI3080964; Fri, 24 Jul 2015 10:56:30 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201507240856.t6O8uUI3080964@givry.fdupont.fr> From: Francis Dupont To: Mikael Abrahamsson In-reply-to: Your message of Fri, 24 Jul 2015 10:32:05 +0200. Date: Fri, 24 Jul 2015 10:56:30 +0200 Sender: Francis.Dupont@fdupont.fr Archived-At: Cc: v6ops list Subject: Re: [v6ops] use of Teredo addresses in Apple devices 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, 24 Jul 2015 08:58:18 -0000 In your previous mail you wrote: > Yes, I agree that PI would be optimal, but I am not opposed to using some > other prefix such as the one Stuart suggested. => these messages made me to look at the (nice) slides... I agree with this position (PI or Stuart's) (aka +1). Regards Francis.Dupont@fdupont.fr From nobody Fri Jul 24 02:15:46 2015 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 F212B1A87D2 for ; Fri, 24 Jul 2015 02:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 6rKhdIk8hHIt for ; Fri, 24 Jul 2015 02:15:44 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 730B41A870A for ; Fri, 24 Jul 2015 02:15:43 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1ZIZ4w-0000CbC; Fri, 24 Jul 2015 11:15:42 +0200 Message-Id: To: IPv6 Operations From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> <55B1ED14.6030501@gmail.com> In-reply-to: Your message of "Fri, 24 Jul 2015 19:45:24 +1200 ." <55B1ED14.6030501@gmail.com> Date: Fri, 24 Jul 2015 11:15:42 +0200 Archived-At: Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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: Fri, 24 Jul 2015 09:15:45 -0000 Random question: how you doing DHCP PD interact with Homenet's HNCP? From nobody Fri Jul 24 02:17:01 2015 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 5104E1A88A1 for ; Fri, 24 Jul 2015 02:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.299 X-Spam-Level: *** X-Spam-Status: No, score=3.299 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 HkM4rBDLQoZY for ; Fri, 24 Jul 2015 02:16:58 -0700 (PDT) Received: from mailrelay22.naist.jp (mailrelay22.naist.jp [IPv6:2001:200:16a:50::91]) by ietfa.amsl.com (Postfix) with ESMTP id 1F48E1A87E9 for ; Fri, 24 Jul 2015 02:16:58 -0700 (PDT) Received: from mailpost22.naist.jp (mailscan22.naist.jp [163.221.80.59]) by mailrelay22.naist.jp (Postfix) with ESMTP id AF562644 for ; Fri, 24 Jul 2015 18:16:56 +0900 (JST) Received: from naist.jp (webmail21-a.naist.jp [IPv6:2001:200:16a:50::53]) by mailpost22.naist.jp (Postfix) with ESMTP id 92F44643 for ; Fri, 24 Jul 2015 18:16:56 +0900 (JST) Received: from [127.0.0.1] (Forwarded-For: ::ffff:31.133.171.136) by webmail21-a.naist.jp (mshttpd); Fri, 24 Jul 2015 11:16:56 +0200 From: "GEORGESCU LIVIU MARIUS" To: v6ops@ietf.org Message-ID: <6bf0898ffbd5.55b21ea8@naist.jp> Date: Fri, 24 Jul 2015 11:16:56 +0200 X-Mailer: Oracle Communications Messenger Express 7.0.5.35.0 64bit (built Mar 31 2015) MIME-Version: 1.0 Content-Language: en X-Accept-Language: en Priority: normal In-Reply-To: <6bf0f7dbdadf.55b20280@naist.jp> References: <6b60e612c4f0.55b20091@naist.jp> <6c008406e2af.55b200cf@naist.jp> <6c00eec89ab8.55b2010d@naist.jp> <6bf095d99dae.55b2014a@naist.jp> <6b50ff96a9ad.55b20188@naist.jp> <6c50a92cde54.55b201c6@naist.jp> <6c50be138e83.55b20205@naist.jp> <6bf08db1e13f.55b20243@naist.jp> <6bf0f7dbdadf.55b20280@naist.jp> Content-Type: multipart/alternative; boundary="--4699173e7022183b22bb" X-TM-AS-MML: No X-TM-AS-Product-Ver: IMSS-7.1.0.1392-8.0.0.1202-21700.006 X-TM-AS-Result: No--4.658-5.0-31-10 X-imss-scan-details: No--4.658-5.0-31-10 X-TMASE-MatchedRID: 5U0T3tp5JdFITndh1lLRAco3MPo0IsVYnS9YM7PCHZgkot8DdjJV2w3b 6kSjpN75eWauQdTPp2TS0DwYk1xlF0ft3Vbicuzy2Hdvv/MGE3Ul3afZehJEWfk3SjZMcZFk8Fh GjTp5WPdXHM2WWOqIU/WHSLoU43ZYLuxf1xAEj4WeAiCmPx4NwGmRqNBHmBvevqq8s2MNhPDkrX 9qhSu30phaDPEx+n678BdxbGBwPnJ8DIZEofuvxvoLR4+zsDTtzV3c1I+kxWde/cMQFVhLTU/VT NM0U3NgTSgE8PJQjGHaTapoC/0tTU3nxe16T51y9lryzfFXymz1jGy5OuwblAycvT8ZiiBZ/ZpI Lily9DAj8W8AQXcxKn6Ak0rQzwin9+Nwaa5wEA4S/pJi8Zxj94rMgX5uKKZnK1/DP+H09AsK/J5 WC7c/nEw4zkHMb2LMAzUYu7AE55E= Archived-At: Subject: [v6ops] IANA assigned prefix for IPv6 benchmarking 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, 24 Jul 2015 09:17:00 -0000 This is a multi-part message in MIME format. ----4699173e7022183b22bb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit Hello v6ops, Related to the question that came up in Stuart Cheshire's presentation about the prefix used for benchmarking, RFC5180(with errata) "IPv6 Benchmarking Methodology for Network Interconnect Devices" (which might not apply here) states: "The IANA has assigned 2001:0002::/48 for IPv6 benchmarking, which is a 48-bit prefix from the RFC 4773 pool." I hope this helps. Best regards, Marius ----4699173e7022183b22bb Content-Type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello v6ops=2C=3Cdiv=3E=3Cbr /=3E=3C/div=3E=3Cdiv=3ERelated =A0to the qu= estion that came up in Stuart Cheshire=27s presentation about the prefix= used for benchmarking=2C RFC5180(with errata) =26quot=3B=3Cspan style=3D= =22font-size=3A 1em=3B line-height=3A 0pt=3B font-weight=3A bold=3B=22=3E= IPv6 Benchmarking Methodology for Network Interconnect Devices=3C/span=3E= =26quot=3B (which might not apply here) states=3A =26quot=3B=3Cspan styl= e=3D=22font-family=3A =27Courier New=27=2C Courier=2C =27Andale Mono=27=2C= Monaco=2C monospace=3B font-size=3A 16px=3B=22=3EThe IANA has assigned = 2001=3A0002=3A=3A/48 for IPv6 benchmarking=2C which is a 48-bit prefix f= rom the RFC 4773 pool=2E=3C/span=3E=26quot=3B =A0=3C/div=3E=3Cdiv=3EI ho= pe this helps=2E=3C/div=3E=3Cdiv=3E=3Cbr /=3E=3C/div=3E=3Cdiv=3EBest reg= ards=2C=3C/div=3E=3Cdiv=3EMarius=3C/div=3E ----4699173e7022183b22bb-- From nobody Fri Jul 24 02:17:08 2015 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 E01521A88B1 for ; Fri, 24 Jul 2015 02:17:02 -0700 (PDT) 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, FREEMAIL_FROM=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 HWnXMh5yIMy2 for ; Fri, 24 Jul 2015 02:17:00 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::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 48BEC1A888B for ; Fri, 24 Jul 2015 02:16:58 -0700 (PDT) Received: by lbbyj8 with SMTP id yj8so11293631lbb.0 for ; Fri, 24 Jul 2015 02:16:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=J8pMKV4Heb3AdeCu0QX1ELnLlZPuHwriMovmmlWUl4A=; b=VZJaBT4qlYCPrekqe9uJ8pZsROqu3GDmuGWhQEEI/G2timqhNw8ZqOG7k7wHMLr5Ot s7WoFlrt+9Dt4Knpmf0vKrs6tnyetNQpqh85Y7rWzNNqsWbwF1MC3e9qfBCjSSAy3nFy HYkDn20ddbB1SXckfNPUyDtcbnnwxI4xbrIJ+ZDdIoPLcKmU96RJJp/M6OQ4z5c+hiCs Ig6+qtSJQtqSMYG2rxHdgYH60mrD6AJN59K5SAI5zoRPaWaqSbsL4RWIs8EA0MoID1Cq v9p0Rq9eCyAg8KcBMTPJA/QJ2ApLEgW3eMFAypH1f8axHNgJny+iv8wHgtnZTpT4aa1K ktew== X-Received: by 10.152.22.99 with SMTP id c3mr12945588laf.32.1437729416775; Fri, 24 Jul 2015 02:16:56 -0700 (PDT) MIME-Version: 1.0 Sender: edwinsc@gmail.com Received: by 10.152.26.40 with HTTP; Fri, 24 Jul 2015 02:16:27 -0700 (PDT) In-Reply-To: References: <2D09D61DDFA73D4C884805CC7865E61132A90D2D@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Edwin Cordeiro Date: Fri, 24 Jul 2015 11:16:27 +0200 X-Google-Sender-Auth: hPmueh4i34B3eAhrrio0KdIeCVA Message-ID: To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=089e0158b6c02b8dd9051b9b771a Archived-At: Cc: v6ops list Subject: Re: [v6ops] use of Teredo addresses in Apple devices 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, 24 Jul 2015 09:17:03 -0000 --089e0158b6c02b8dd9051b9b771a Content-Type: text/plain; charset=UTF-8 Even if the address is used only inside the telephone, I don't think using the Teredo address is a good idea, as once it started being used in one product it may be extended in other products of the company with unexpected results. If any of the addresses already reserved at IANA fits your need ( http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml), suggest a new one to be reserved. In a previous discussion about extending the documentation reserved addresses, one important comment was that no words should be used to give additional meaning our proposed IPv6 reserved space, despite the temptation. Edwin Cordeiro On Fri, Jul 24, 2015 at 10:37 AM, Lorenzo Colitti wrote: > I'm not sure that using ULAs is a good idea. ULAs are not likely to be > representative of real NAT64 deployments, which use global addresses. > > On Fri, Jul 24, 2015 at 10:24 AM, STARK, BARBARA H wrote: > >> Great presentation on what Apple is doing to drive apps to implement IPv6. >> In thinking about use of the Teredo address space to advertise a prefix >> to tethered devices, I do have a concern. In many of my personal home >> networked devices, I've purposefully disabled Teredo and ISATAP and even >> put in some rules to prevent the devices from accepting such addresses. >> >> I think this would be a reasonable use of a ULA. A PI might be even >> better. I hear PIs are pretty easy to come by. The PI would have the >> advantage of being known to come from an Apple device for this NAT64 >> purpose. That could help with trouble shooting. >> Barbara >> >> _______________________________________________ >> 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 > > --089e0158b6c02b8dd9051b9b771a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Even if the address is used only inside the telephone, I d= on't think using the Teredo address is a good idea, as once it started = being used in one product it may be extended in other products of the compa= ny with unexpected results.

If any of the addresses alre= ady reserved at IANA fits your need (http://www.iana.org/assig= nments/ipv6-address-space/ipv6-address-space.xhtml), suggest a new one = to be reserved.

In a previous discussion about ext= ending the documentation reserved addresses, one important comment was that= no words should be used to give additional meaning our proposed IPv6 reser= ved space, despite the temptation.



Edwin Cordeiro

On Fri, Jul 24, 2015 at 10:37 AM, Lorenzo Co= litti <lorenzo@google.com> wrote:
I'm not sure that using ULAs is a good idea. = ULAs are not likely to be representative of real NAT64 deployments, which u= se global addresses.

On Fri, Jul 24, 2015 at 10:24 AM, STARK, BARBARA H <bs765= 2@att.com> wrote:
Great presentation on what Apple is doing to drive apps to i= mplement IPv6.
In thinking about use of the Teredo address space to advertise a prefix to = tethered devices, I do have a concern. In many of my personal home networke= d devices, I've purposefully disabled Teredo and ISATAP and even put in= some rules to prevent the devices from accepting such addresses.

I think this would be a reasonable use of a ULA. A PI might be even better.= I hear PIs are pretty easy to come by. The PI would have the advantage of = being known to come from an Apple device for this NAT64 purpose. That could= help with trouble shooting.
Barbara

_______________________________________________
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


--089e0158b6c02b8dd9051b9b771a-- From nobody Fri Jul 24 03:37:33 2015 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 8CAA01A1B8A for ; Fri, 24 Jul 2015 03:37:31 -0700 (PDT) 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 H79cyir-QbvG for ; Fri, 24 Jul 2015 03:37:26 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450: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 580AD1A0377 for ; Fri, 24 Jul 2015 03:37:26 -0700 (PDT) Received: by wibud3 with SMTP id ud3so59815345wib.1 for ; Fri, 24 Jul 2015 03:37:25 -0700 (PDT) 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=WDJ6yb98hmHYL/FvaskQlVcgylEArvE0iyYYnWLtB+c=; b=QzKuQS/DtIKzsLU1AFdXHvxx/lwoC7MWdYtzKpkfk2dC4Bpg3fhqoZnAJcQcsr6CM8 QOEMt4EClT3nOwNUxXLmmhJV/M1uZg8VZgbxIa0q66d0Utov3RtY0AxkIPNJUoB351f0 zhHmCBQmgmLmJ3P+h2nYaw2T6ZszCzmNswMvdmlrOMqtj0PKIE67XNthLe5/VGKdXgQA v9aPIGGt4Q6FJRcHe0JOKNzMoX6rHkqAXI6xKUd3BShKumwj4gyABmDJhHu0PIO0q02a gqJ0i2/G7VOMkVuHbA2NjmVXnzt/i264NpRBnvmHY/CFyfsaEBU0H5PzJBFuZMslB3TO XI0Q== 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=WDJ6yb98hmHYL/FvaskQlVcgylEArvE0iyYYnWLtB+c=; b=XXn2uMzHl8QnFl1dIZxObpsGftH2uf/ExiMZrlyC/Qb1z/KJkLGae64dxEFvI/d/LD 1/KXaTUWmyHFsgEfqhWB/DHkUwNGzpFq1bAiffYsHOwGCLfkWe+9VC5v5Mh6r4ooOUj4 n7kw0oJ3iV4UvRZG4ULu/An1119zOoWr3OApiOJ6FUfzydd2BFACWp+fpyEysgKzQLCy tZGjsoSKpKb5kHlB3xWaL5pelacO+3BNmAtNjIbdCViSYjH5T94jdFbpBUjXTY8k/a2q VDSZW2BdL8KbwJp1pCCZ6yj+2h86Rbxt2LG/TkTMcVpkN5rG2gyyHMzwWahsfkq7cuYF hdyQ== X-Gm-Message-State: ALoCoQn9KNtqRfKGdydGzgtnEank9m0Rh/bmIBXACCzRuyb0V06JzTIiyTsKd6NfWDYaaP9I5eY4 X-Received: by 10.180.90.83 with SMTP id bu19mr5906065wib.91.1437734245076; Fri, 24 Jul 2015 03:37:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.138.203 with HTTP; Fri, 24 Jul 2015 03:37:05 -0700 (PDT) In-Reply-To: References: <55B09AE5.4040609@gmail.com> <2BBE839B-37FB-4EA2-982E-58028E7A13B6@nominum.com> <55B0F344.4090005@gmail.com> From: Erik Kline Date: Fri, 24 Jul 2015 12:37:05 +0200 Message-ID: To: Philip Homburg Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] NAT64/DNS64 and DNSSEC 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, 24 Jul 2015 10:37:31 -0000 > I guess this is easy enough to add to for example getdns > (https://getdnsapi.net/). One question is how an application would find out > that it is running in a DNS64 environment. Another option is for getdns to > do the probing and enable this option automatically. One approach comes to ming: when a client resolver starts up, it checks ipv4only.arpa (https://tools.ietf.org/html/rfc7050#section-8.2), and after that can synthesize AAAAs as needed (DNS64 in done in the client) while getting validated answers for other things as desired. From nobody Fri Jul 24 04:07:59 2015 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 CB0D41A88CB for ; Fri, 24 Jul 2015 04:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.6 X-Spam-Level: X-Spam-Status: No, score=-4.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 KX5PNntBCSSs for ; Fri, 24 Jul 2015 04:07:56 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 19FA91A8F4E for ; Fri, 24 Jul 2015 04:07:56 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1ZIapX-0000CgC; Fri, 24 Jul 2015 13:07:55 +0200 Message-Id: To: "v6ops@ietf.org" From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <55B09AE5.4040609@gmail.com> <2BBE839B-37FB-4EA2-982E-58028E7A13B6@nominum.com> <55B0F344.4090005@gmail.com> In-reply-to: Your message of "Fri, 24 Jul 2015 12:37:05 +0200 ." Date: Fri, 24 Jul 2015 13:07:54 +0200 Archived-At: Subject: Re: [v6ops] NAT64/DNS64 and DNSSEC 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, 24 Jul 2015 11:07:58 -0000 In your letter dated Fri, 24 Jul 2015 12:37:05 +0200 you wrote: >> I guess this is easy enough to add to for example getdns >> (https://getdnsapi.net/). One question is how an application would find out >> that it is running in a DNS64 environment. Another option is for getdns to >> do the probing and enable this option automatically. > >One approach comes to ming: when a client resolver starts up, it >checks ipv4only.arpa >(https://tools.ietf.org/html/rfc7050#section-8.2), and after that can >synthesize AAAAs as needed (DNS64 in done in the client) while getting >validated answers for other things as desired. I was wondering whether this should be done by the application or be part of the library. If it is documented somewhere as a thing to do for local DNSSEC validating libraries then we can treat NAT64/DNS64 as completely transparent to the application. But there might be reasons why applications don't want this to happen. From nobody Fri Jul 24 04:47:12 2015 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 A93C01A87A7 for ; Fri, 24 Jul 2015 04:47:10 -0700 (PDT) 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 JUtzpMVNdXuM for ; Fri, 24 Jul 2015 04:47:04 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A69051A8A7F for ; Fri, 24 Jul 2015 04:47:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=147; q=dns/txt; s=iport; t=1437738424; x=1438948024; h=date:from:message-id:to:subject:cc; bh=nG/MRbCP8aSL2BlxUfpKqFgzao9jZruaTDtO68/7/ts=; b=HmPijTvDrUhfPuPRZHJKOdcv5IlsL51oVkuC9Dpo8sxEBlntVfvY1OI+ g62PaMB12lDD3w76M1IYTE5m4sy+l9U7ZsunoFmAmBoUptmP0XosBEZci zArX/oHhaozGTYqfbEsWfS8biL8OloGnG2sTa5qmCPwLT6Xqcu9zuLaqX 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DqBgAdJbJV/4kNJK1cgxVUrT4BjysJgXeFf4FFOBQBAQEBAQEBgQpBBYNgfTw0iQ4BDcpEAQEBAQEFAQEBAQEdi02FBx6EFQWNMocxhHaJC0aDV5NCJoQdgxoBAQE X-IronPort-AV: E=Sophos;i="5.15,538,1432598400"; d="scan'208";a="18394396" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-3.cisco.com with ESMTP; 24 Jul 2015 11:47:03 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t6OBl3DH021914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Jul 2015 11:47:03 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 t6OBl2fZ002272; Fri, 24 Jul 2015 04:47:02 -0700 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id t6OBl2kP002271; Fri, 24 Jul 2015 04:47:02 -0700 Date: Fri, 24 Jul 2015 04:47:02 -0700 From: fred@cisco.com Message-Id: <201507241147.t6OBl2kP002271@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Cc: draft-ietf-v6ops-reducing-ra-energy-consumption@tools.ietf.org Subject: [v6ops] new draft: draft-ietf-v6ops-reducing-ra-energy-consumption 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, 24 Jul 2015 11:47:10 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-reducing-ra-energy-consumption. Please take a look at it and comment. From nobody Fri Jul 24 09:42:06 2015 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 4EA2E1ACF19 for ; Fri, 24 Jul 2015 09:42:05 -0700 (PDT) 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 QRG9HteVWnmB for ; Fri, 24 Jul 2015 09:42:04 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA0B11A21B6 for ; Fri, 24 Jul 2015 09:42:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2288; q=dns/txt; s=iport; t=1437756123; x=1438965723; h=from:to:cc:subject:date:message-id:mime-version; bh=TVR054W6fsNL4PucZ3VAErbR1V93h5jTk7p4JVL/RQ4=; b=VNkwq1tfV7MB3AHRJX+H0/JI3MccY1QWTzYP66zdi3bp8qO+2XVML4fF dh4nl0uLFVovzRX1c/duKWmntcQTuXAolGfqWJp6I8Sy42QDL4/qmnqiI Znvaq4o0k2EaVDS1zENz3dIvTV8L9HUx94+qftohgzmBzDNStto8Sa4LU 0=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AiAwA6arJV/5NdJa1cgxWBQ7tCCYd2gUg4FAEBAQEBAQF/C4QmBHkSAYEAJwQOE4ggz1kBAQEBAQEBAQEBAQEBAQEBAQEBAQEXkFSDH4EUBZRjAYI2gVeILoFFhy+QMCaDfYI2gQQBAQE X-IronPort-AV: E=Sophos;i="5.15,539,1432598400"; d="asc'?scan'208";a="172209539" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Jul 2015 16:42:03 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t6OGg2th020249 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 Jul 2015 16:42:03 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.49]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Fri, 24 Jul 2015 11:42:02 -0500 From: "Fred Baker (fred)" To: "draft-ietf-v6ops-siit-dc@tools.ietf.org" Thread-Topic: Comment on siit-dc Thread-Index: AQHQxi+qCOZmvDDCG0uZ0CSshzgTag== Date: Fri, 24 Jul 2015 16:42:01 +0000 Message-ID: <03B11480-F2E2-4B66-B7A2-1E4824E63D06@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.61.168.157] Content-Type: multipart/signed; boundary="Apple-Mail=_E5AC6C71-DBA2-4F2C-B0D5-D01530B43727"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: v6ops list Subject: [v6ops] Comment on siit-dc 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, 24 Jul 2015 16:42:05 -0000 --Apple-Mail=_E5AC6C71-DBA2-4F2C-B0D5-D01530B43727 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The abstract reads: This document describes the use of the Stateless IP/ICMP Translation (SIIT) algorithm in an IPv6 Internet Data Centre (IDC). In this deployment model, traffic from legacy IPv4-only clients on the Internet is translated to IPv6 when reaches the IDC operator's network infrastructure. =46rom that point on, it is treated just as = if it was traffic from any other IPv6-capable end user. This facilitates a single-stack IPv6-only network infrastructure, as well as efficient utilisation of public IPv4 addresses. The primary audience is IDC operators who are deploying IPv6, running out of available IPv4 addresses, and/or feel that dual stack causes undesirable operational complexity. I see what you're saying, but can read it as specifying how an RFC 6052 = address might be used, when you're specifying the use of siit-eam. May I = suggest tweaking the abstract to clarify that? --Apple-Mail=_E5AC6C71-DBA2-4F2C-B0D5-D01530B43727 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 iQIVAwUBVbJq2UayAOS/EQ8MAQJ0FA/9EWlhAmZHzFW6ch5zNX8byJHQdr9JmvXe BYIB8ly0plu84M6lIwu104VsFpjnVMMAeO6eEZcInqZY8keFKpVesefj3/LDMrAn BGNkd6M3+tB8qF5D/7SjNA3QqaahNhX3JbeQL36D9P3/BhsZwCVAwa37fLzN1tEz GideFw069gnjIerV0yJ85Bd0BH4Q+K2pnss1QdGsiosJ8Dfh/nIkCbxGAsLTpMLQ S8aoQrItIaxdAppYvxh5D2Lehjl1/7Oo405UA2tp5snZBW686RimTcqYXjm40gXw 5dh9qNm6B3mn/IZi4rH1SowzcYSVbaDAa64wOeTHqU2eLNGxuzkZVBgRJVeO0Jx4 qMU2k8HKoLbXJSOjUBUWmTWo4TMQoQKtb3/lsQSxar0D5uWkpoFqMnrOoOCF8XsU h/tYqjhhUTVGfLcmT+U+6cFPC88mquoPNy1ua12YTe4dzkkmUMYN6TuQc989Devr BihseclQPFEdAM4Vf4O090l7Yp2UDjDywJJjh75m1xXRRS/z1i5MjA/UlfAzQK8V B/hEygATtDjcDWpnasqssjvJJOkgl+/qauB+w1YlpO3FIGxquomNbdgjIgb8Ffj/ Li3vcwymX7hVZ1f2VLH1wYGu4eXfavBEX7HnxZBjsStEYZJpzt4QEJz8GiPb8SaC agbueBZf9Vg= =yNR4 -----END PGP SIGNATURE----- --Apple-Mail=_E5AC6C71-DBA2-4F2C-B0D5-D01530B43727-- From nobody Fri Jul 24 09:58:20 2015 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 3906B1A0004 for ; Fri, 24 Jul 2015 09:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.536 X-Spam-Level: X-Spam-Status: No, score=-3.536 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, 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 eldye7gMwBsY for ; Fri, 24 Jul 2015 09:58:17 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.113]) (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 F081D1A0006 for ; Fri, 24 Jul 2015 09:58:16 -0700 (PDT) Received: from [194.106.220.35] by server-9.bemta-14.messagelabs.com id 41/BB-03371-7AE62B55; Fri, 24 Jul 2015 16:58:15 +0000 X-Env-Sender: nick.heatley@ee.co.uk X-Msg-Ref: server-14.tower-91.messagelabs.com!1437757094!23913354!1 X-Originating-IP: [149.254.241.76] X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22832 invoked from network); 24 Jul 2015 16:58:14 -0000 Received: from unknown (HELO smtpml01.ee.co.uk) (149.254.241.76) by server-14.tower-91.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 24 Jul 2015 16:58:14 -0000 Received: from EEUKWV0940.EEAD.EEINT.CO.UK (Not Verified[10.246.209.217]) by smtpml01.ee.co.uk with MailMarshal (v7, 2, 3, 6978) id ; Fri, 24 Jul 2015 17:58:00 +0100 Received: from UK31S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.27]) by EEUKWV0940.EEAD.EEINT.CO.UK with MailMarshal (v7, 2, 3, 6978) id ; Fri, 24 Jul 2015 17:58:14 +0100 Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK31S005EXS02.EEAD.EEINT.CO.UK ([2002:62c:2a56::62c:2a56]) with mapi id 14.03.0195.001; Fri, 24 Jul 2015 17:58:13 +0100 From: "Heatley, Nick" To: Erik Kline , Philip Homburg Thread-Topic: [v6ops] NAT64/DNS64 and DNSSEC Thread-Index: AQHQxRedzQPAv9hMVUOUvlQI6TNowp3om02AgAAvFICAADpFAIAAAbcAgAFEWaGAABO0gIAAeUyw Date: Fri, 24 Jul 2015 16:58:12 +0000 Message-ID: <6536E263028723489CCD5B6821D4B21303EEBEC2@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <55B09AE5.4040609@gmail.com> <2BBE839B-37FB-4EA2-982E-58028E7A13B6@nominum.com> <55B0F344.4090005@gmail.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.246.208.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] NAT64/DNS64 and DNSSEC 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, 24 Jul 2015 16:58:19 -0000 +1 A client that can't synthesize internally, MAY need DNS64 from the networ= k. So can we frame the problem as: lack of internal synthesis is incompat wi= th DNSSEC? -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Erik Kline Sent: 24 July 2015 11:37 To: Philip Homburg Cc: v6ops@ietf.org Subject: Re: [v6ops] NAT64/DNS64 and DNSSEC > I guess this is easy enough to add to for example getdns=20 > (https://getdnsapi.net/). One question is how an application would=20 > find out that it is running in a DNS64 environment. Another option is=20 > for getdns to do the probing and enable this option automatically. One approach comes to ming: when a client resolver starts up, it checks i= pv4only.arpa (https://tools.ietf.org/html/rfc7050#section-8.2), and after= =20that can synthesize AAAAs as needed (DNS64 in done in the client) whil= e getting validated answers for other things as desired. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops NOTICE AND DISCLAIMER This e-mail (including any attachments) is intended for the above-named p= erson(s). If you are not the intended recipient, notify the sender immed= iately, delete this email from your system and do not disclose or use for= =20any purpose. =20 =20 We may monitor all incoming and outgoing emails in line with current legi= slation. We have taken steps to ensure that this email and attachments ar= e free from any virus, but it remains your responsibility to ensure that = viruses do not adversely affect you.=20 EE Limited Registered in England and Wales Company Registered Number: 02382161 Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfor= dshire, AL10 9BW. From nobody Fri Jul 24 12:21:15 2015 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 F19331A1B4C for ; Fri, 24 Jul 2015 12:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-vr6nX4ChO5 for ; Fri, 24 Jul 2015 12:21:13 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 372151A1EFD for ; Fri, 24 Jul 2015 12:21:13 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6OJLBIp016960 for ; Fri, 24 Jul 2015 21:21:11 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id DDD23205805 for ; Fri, 24 Jul 2015 21:24:49 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id CC74E205619 for ; Fri, 24 Jul 2015 21:24:49 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.57]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6OJLAuX032193 for ; Fri, 24 Jul 2015 21:21:11 +0200 To: v6ops@ietf.org References: <6b60e612c4f0.55b20091@naist.jp> <6c008406e2af.55b200cf@naist.jp> <6c00eec89ab8.55b2010d@naist.jp> <6bf095d99dae.55b2014a@naist.jp> <6b50ff96a9ad.55b20188@naist.jp> <6c50a92cde54.55b201c6@naist.jp> <6c50be138e83.55b20205@naist.jp> <6bf08db1e13f.55b20243@naist.jp> <6bf0f7dbdadf.55b20280@naist.jp> <6bf0898ffbd5.55b21ea8@naist.jp> From: Alexandru Petrescu Message-ID: <55B29026.1070906@gmail.com> Date: Fri, 24 Jul 2015 21:21:10 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <6bf0898ffbd5.55b21ea8@naist.jp> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] IANA assigned prefix for IPv6 benchmarking 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, 24 Jul 2015 19:21:15 -0000 Le 24/07/2015 11:16, GEORGESCU LIVIU MARIUS a écrit : > Hello v6ops, > > Related to the question that came up in Stuart Cheshire's presentation > about the prefix used for benchmarking, RFC5180(with errata) "IPv6 > Benchmarking Methodology for Network Interconnect Devices" (which might > not apply here) states: "The IANA has assigned 2001:0002::/48 for IPv6 > benchmarking, which is a 48-bit prefix from the RFC 4773 pool." > I hope this helps. To me, this is an additional reason to think that it is good to use ULAs (not 2001:s or Teredos) behind any form of NATxy. But I heard there may be good reasons to avoid ULA in NAT64. Not sure which. Alex > > Best regards, > Marius > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Fri Jul 24 12:55:09 2015 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 73B7E1A00C7 for ; Fri, 24 Jul 2015 12:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4wIqIkHVbhe for ; Fri, 24 Jul 2015 12:55:06 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::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 2A3D31A1AAE for ; Fri, 24 Jul 2015 12:55:04 -0700 (PDT) Received: by lahh5 with SMTP id h5so20015170lah.2 for ; Fri, 24 Jul 2015 12:55:02 -0700 (PDT) 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:content-transfer-encoding; bh=/EPx4H+ElvxFeBzDwUWnAKIUYp6sO5tHUjhQgmLkOtk=; b=yi4jxmF+p8fjjJIt/HTimwwa0sBwnzx1argXigpAjCDaQlO6i9tQXMOonECEPHTsSG 9DCTOFPAL062tzda+iOyrHtocJ/mIsTUJngiYfisqJSEaXGSN95MI9SaY8UFzXM3PO1h 5kQXyOAKXUuL9XzJ2y7EuJscko6DhOQjggL5vVz9i3dvmGCxOF56CEOvWt4sPIU9LXuX RkUAj+CvTiNOW4zivicRvS43ZhmNNBfVZnWEY4LfmX2MfRqIay9VOMEBnmA7+IcyU8P3 v3sUYR1BFdtxyKh7LJCjtXWTdF9s0S1CdbtvaDurAfz548Fz7daBtIekANv4y2GJSwxJ VCgg== MIME-Version: 1.0 X-Received: by 10.152.28.105 with SMTP id a9mr15556571lah.9.1437767702521; Fri, 24 Jul 2015 12:55:02 -0700 (PDT) Received: by 10.112.26.82 with HTTP; Fri, 24 Jul 2015 12:55:02 -0700 (PDT) In-Reply-To: <559A5DB6.4090602@cernet.edu.cn> References: <201507041147.t64Bl2oR005661@irp-lnx1.cisco.com> <559A5DB6.4090602@cernet.edu.cn> Date: Fri, 24 Jul 2015 14:55:02 -0500 Message-ID: From: Alberto Leiva To: Xing Li Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: v6ops@ietf.org, draft-bao-v6ops-rfc6145bis@tools.ietf.org Subject: Re: [v6ops] new draft: draft-bao-v6ops-rfc6145bis 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, 24 Jul 2015 19:55:08 -0000 Hi > Destination Address: In the stateless mode, which is to say that if > the IPv4 destination address is within a range of configured IPv4 > stateless translation prefix, the IPv6 destination address is the > IPv4-translatable address derived from the IPv4 destination > address per [RFC6052], Section 2.3. A workflow example of > stateless translation is shown in Appendix A of this document. > Besides the default algorithm defined [RFC6052], other mechanisms > also exist, which are defined in Section 6 of this document (EAM) > and in [I-D.ietf-softwire-map-t]. > > In the stateful mode (which is to say that if the IPv4 destination > address is not within the range of any configured IPv4 stateless > translation prefix), the IPv6 destination address and > corresponding transport-layer destination port are derived from > the Binding Information Bases (BIBs) reflecting current session > state in the translator as described in [RFC6146]. I find this a little excessive. It also seems to mandate no other address translation mechanisms should exist (is this true?). I suggest something like this: Destination Address: The address translation algorithm is left open for other documents to define. At time of writing, implementations can choose (according to needs) among RFC6052, RFC6146, RFC 6219, RFC6791, EAM ([I-D.ietf-v6ops-siit-eam]) and/or MAP-T ([I-D.ietf-softwire-map-t]). Repeat (Or make an new section and point there) for IPv4-to-IPv6 source address, and the IPv6-to-IPv4 source and destination addresses. On Mon, Jul 6, 2015 at 5:51 AM, Xing Li wrote: > fred@cisco.com =E5=86=99=E9=81=93: > > A new draft has been posted, at > http://tools.ietf.org/html/draft-bao-v6ops-rfc6145bis. Please take a look= at > it and comment. > > > > We have submitted this draft to look for v6ops' comments. > > The changes compared with RFC6145 are: > > (1) From the erratum report > http://www.rfc-editor.org/errata_search.php?rfc=3D6145 > > (2) From 6man's document concerning "Deprecating the Generation of IPv6 > Atomic Fragments" > > https://datatracker.ietf.org/doc/draft-ietf-6man-deprecate-atomfrag-gener= ation/ > Ntote that RFC6145 already has this mechanism, but it is just an > option. The rfc6145bis makes this mechanism the default and the only one. > > (3) Refer to RFC6791 for "Stateless Source Address Mapping for ICMPv6 > Packets" > https://datatracker.ietf.org/doc/rfc6791/ > > (4) Include EAM address mapping algoritm which is the current work of > v6ops, "Explicit Address Mappings for Stateless IP/ICMP Translation" > https://datatracker.ietf.org/doc/draft-ietf-v6ops-siit-eam/ > There are some discussions concerning this issue, since EAM is an > address mapping algorithm (RFC6052's alternative), not a protocol mapping > algorithm. We include EAM in RFC6145bis because it is just a static > configuration and simple. If additional details, for example hairpinning, > needs to be included, I think those details should be in another document= . > > We are looking for the comments. > > xing > > > _______________________________________________ > 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 Jul 24 21:07:52 2015 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 ABB181AD49F for ; Fri, 24 Jul 2015 21:07:50 -0700 (PDT) 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, 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 fOnHfKNIrQaP for ; Fri, 24 Jul 2015 21:07:49 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001: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 71BDA1AD37B for ; Fri, 24 Jul 2015 21:07:49 -0700 (PDT) Received: by igbpg9 with SMTP id pg9so33172225igb.0 for ; Fri, 24 Jul 2015 21:07:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1/qHLoumPISEs6516i5HRjK/UjAcgGCVKclxU5RI178=; b=NZre8Ts6tgDWjqUcNRr20h+Ar3GUaNzSc/STvaL8Pn8KV6U2QJ4NzQXeiU2vCewYIa Hscci0G8kwcO+QCdubB0KtPx/I5Ye8n6Uh6M6a9aQ0DIXgJm261OITFYMHUUZ6VOQIcJ xAB/HcpC05XjMEXEuHLHuTdDvRmugdVfSW+LcdtX0ipFEGVVU4KjtX4ZQVw1mgyuVTK9 6w+9e0cmVeQjr1T+hSSxuNmmiRlm9HBTyDzrcoOKVN/Jqi7oX0BSgSiN15PSWiso/4/h dlF5fW0AMV2WYaIRBA2TqRMkUVRKCMdDiZQ7Mvlt9gerUQ8cCTW0QBGy6OsJG4qTyLQX ZzIw== X-Received: by 10.107.18.28 with SMTP id a28mr29962274ioj.106.1437797268931; Fri, 24 Jul 2015 21:07:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.169.143 with HTTP; Fri, 24 Jul 2015 21:07:19 -0700 (PDT) In-Reply-To: <55B1ED14.6030501@gmail.com> References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> <55B1ED14.6030501@gmail.com> From: Mark Smith Date: Sat, 25 Jul 2015 14:07:19 +1000 Message-ID: To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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: Sat, 25 Jul 2015 04:07:50 -0000 Hi, On 24 July 2015 at 17:45, Brian E Carpenter wrote: > I like -01 even better than -00. > So do I. > As well as the reference [TARP], you might add draft-smith-enhance-vne-with-ipv6 > as a use case for a /64 per host (specifically per NVE, network virtual edge). > I've never really thought of tunnel end-points (NVEs in that draft) as 'hosts', however I suppose they are if they're the final destination for the packet, as NVEs are for underlay network packets. I've been thinking a bit recently about how to describe/determine where the network "finishes" and the host/end "starts", partly in the context of things like Segment Routing and "service function chaining" or "network function virtualisation". I've thought the simple and fundamental rule is that the network ends and the host/end starts at the "payload don't care/care" boundary. If the receiving device doesn't care what the payload is (and therefore doesn't care if the payload is encrypted or not), then it is a device in the network. If receiving device cares about what the payload is, then it is performing host/end functions. By that definition, even though NVEs are only performing layer 2/layer 3 frame/packet processing, they're hosts/ends, because they look at and process the payload of the packet they receive that are directed specifically at them (i.e., packet dest addr is their own /64 prefix in that draft). Regards, Mark. > Regards > Brian > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Sat Jul 25 03:37:20 2015 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 221321A88F3 for ; Sat, 25 Jul 2015 03:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.599 X-Spam-Level: X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 sDm7Kv5OlIcQ for ; Sat, 25 Jul 2015 03:37:17 -0700 (PDT) Received: from mailrelay22.naist.jp (mailrelay22.naist.jp [IPv6:2001:200:16a:50::91]) by ietfa.amsl.com (Postfix) with ESMTP id 844661A0158 for ; Sat, 25 Jul 2015 03:37:17 -0700 (PDT) Received: from mailpost22.naist.jp (mailscan22.naist.jp [163.221.80.59]) by mailrelay22.naist.jp (Postfix) with ESMTP id 16F0361C; Sat, 25 Jul 2015 19:37:16 +0900 (JST) Received: from naist.jp (webmail21-a.naist.jp [163.221.80.53]) by mailpost22.naist.jp (Postfix) with ESMTP id F3E3861B; Sat, 25 Jul 2015 19:37:15 +0900 (JST) Received: from [127.0.0.1] (Forwarded-For: ::ffff:89.248.140.10) by webmail21-a.naist.jp (mshttpd); Sat, 25 Jul 2015 12:37:15 +0200 From: "GEORGESCU LIVIU MARIUS" To: Alexandru Petrescu ,v6ops@ietf.org Message-ID: <6bf0c04ef47e.55b382fb@naist.jp> Date: Sat, 25 Jul 2015 12:37:15 +0200 X-Mailer: Oracle Communications Messenger Express 7.0.5.35.0 64bit (built Mar 31 2015) MIME-Version: 1.0 Content-Language: en X-Accept-Language: en Priority: normal In-Reply-To: <6c50d867e570.55b366a4@naist.jp> References: <6b60e612c4f0.55b20091@naist.jp> <6c008406e2af.55b200cf@naist.jp> <6c00eec89ab8.55b2010d@naist.jp> <6bf095d99dae.55b2014a@naist.jp> <6b50ff96a9ad.55b20188@naist.jp> <6c50a92cde54.55b201c6@naist.jp> <6c50be138e83.55b20205@naist.jp> <6bf08db1e13f.55b20243@naist.jp> <6bf0f7dbdadf.55b20280@naist.jp> <6bf0898ffbd5.55b21ea8@naist.jp> <55B29026.1070906@gmail.com> <6b70d3cfd2f6.55b365ea@naist.jp> <6b70bfbf8107.55b36628@naist.jp> <6c30a2fefa4c.55b36666@naist.jp> <6c50d867e570.55b366a4@naist.jp> Content-Type: multipart/alternative; boundary="--7bf5644769e853851747" X-TM-AS-MML: No X-TM-AS-Product-Ver: IMSS-7.1.0.1392-8.0.0.1202-21702.006 X-TM-AS-Result: No--24.547-5.0-31-10 X-imss-scan-details: No--24.547-5.0-31-10 X-TMASE-MatchedRID: 2BgX6Efr+StjyIn1sobvhavnfoenSIXeRphO9iDI3+WJVA+ukO+5MeLd prnA5EQR+KgiyLtJrSD1yFIyxT4ny1YWwxB9tw0TMIZH9N34VaGdvX66iOkhuEIw4Xa9LAtM8eS mTJSmEv1+Mk6ACsw4JlyPhb2isyDdREKjiqASiUTcN9P0Iqci4L8elP/2IwgBYY3ozW+Engd2aF FWhkT3QJ20dShmm+V5FFn/3AEyEaytEaJoVjyWkJb/mTnkM/SIHDnwvr6B+jSPmsTSpXoLhIoLo ibgjVEXi/ymJ2FVg5SISI683skDCj28dBzwO9dQcQHFIHvz5Cu6H+0z6Sb8PLwRFHRPw4UGPluj dkswUwfKi5Jqc8KFNL9rZX4J6klH8R1CbhYofuni8zVgXoAltk77e4Y1xq/3tTBdP6jTSDcelJ9 TflOPDWWGEPQRVcN48BdxbGBwPnKxmoQAAdv2lEUYJ3RLQ0KyLQSRR+42XxMiYYwXiyivaTL/Sr uSxM2vyXhrwNW2QkNgO21BQaodlQ== Archived-At: Subject: Re: [v6ops] IANA assigned prefix for IPv6 benchmarking 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, 25 Jul 2015 10:37:19 -0000 This is a multi-part message in MIME format. ----7bf5644769e853851747 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable If respecting the recommendations of RFC5180 is desired I think the foll= owing note in RFC5180 is relevant=3A =22 Note=3A Similar to RFC 2544(https=3A//tools=2Eietf=2Eorg/html/rfc254= 4) avoiding the use of RFC 1918(https=3A//tools=2Eietf=2Eorg/html/rfc191= 8) address space for benchmarking tests=2C this document does not recommend the use of R= FC 4193(https=3A//tools=2Eietf=2Eorg/html/rfc4193) =5B4(https=3A//tools=2E= ietf=2Eorg/html/rfc5180=23ref-4)=5D (Unique Local Addresses) in order to= minimize the = possibility of conflicts with operational traffic=2E=22 which in my understanding does not recommend the use of ULA s=2E Best regards=2C Marius = On 07/24/15=2C Alexandru Petrescu =3Calexandru=2Epetrescu=40gmail=2Ecom= =3E wrote=3A =3E = =3E = =3E = =3E Le 24/07/2015 11=3A16=2C GEORGESCU LIVIU MARIUS a =E9crit =3A =3E =3EHello v6ops=2C =3E =3E =3E =3ERelated to the question that came up in Stuart Cheshire=27s prese= ntation =3E =3Eabout the prefix used for benchmarking=2C RFC5180(with errata) =22= IPv6 =3E =3EBenchmarking Methodology for Network Interconnect Devices=22 (whi= ch might =3E =3Enot apply here) states=3A =22The IANA has assigned 2001=3A0002=3A= =3A/48 for IPv6 =3E =3Ebenchmarking=2C which is a 48-bit prefix from the RFC 4773 pool=2E= =22 =3E =3EI hope this helps=2E =3E = =3E To me=2C this is an additional reason to think that it is good to us= e ULAs (not 2001=3As or Teredos) behind any form of NATxy=2E =3E = =3E But I heard there may be good reasons to avoid ULA in NAT64=2E Not s= ure which=2E =3E = =3E Alex =3E = =3E =3E =3E =3EBest regards=2C =3E =3EMarius =3E =3E =3E =3E =3E =3E=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F =3E =3Ev6ops mailing list =3E =3Ev6ops=40ietf=2Eorg =3E =3Ehttps=3A//www=2Eietf=2Eorg/mailman/listinfo/v6ops =3E =3E =3E = =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =3E v6ops mailing list =3E v6ops=40ietf=2Eorg =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/v6ops =3E ----7bf5644769e853851747 Content-Type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable If respecting the recommendations of RFC5180 is desired I think the foll= owing note in RFC5180 is relevant=3A=3Cdiv=3E=3Cbr /=3E=3C/div=3E=3Cdiv=3E= =26quot=3B=3Cspan style=3D=22font-size=3A 13=2E3333330154419px=3B=22=3E = Note=3A Similar to =3C/span=3E=3Ca href=3D=22https=3A//tools=2Eietf=2Eo= rg/html/rfc2544=22 style=3D=22font-size=3A 13=2E3333330154419px=3B=22=3E= RFC 2544=3C/a=3E=3Cspan style=3D=22font-size=3A 13=2E3333330154419px=3B=22= =3E avoiding the use of =3C/span=3E=3Ca href=3D=22https=3A//tools=2Eietf= =2Eorg/html/rfc1918=22 style=3D=22font-size=3A 13=2E3333330154419px=3B=22= =3ERFC 1918=3C/a=3E=3Cspan style=3D=22font-size=3A 13=2E3333330154419px=3B= =22=3E address space=3C/span=3E=3C/div=3E=3Cpre class=3D=22newpage=22 st= yle=3D=22font-size=3A 13=2E3333330154419px=3B margin-top=3A 0px=3B margi= n-bottom=3A 0px=3B page-break-before=3A always=3B=22=3E for benchmarki= ng tests=2C this document does not recommend the use of =3Ca href=3D=22https=3A//tools=2Eietf=2Eorg/html/rfc4193=22=3ERFC 419= 3=3C/a=3E =5B=3Ca href=3D=22https=3A//tools=2Eietf=2Eorg/html/rfc5180=23= ref-4=22 title=3D=22=26quot=3BUnique Local IPv6 Unicast Addresses=26quot= =3B=22=3E4=3C/a=3E=5D (Unique Local Addresses) in order to minimize the=A0= =3C/pre=3E=3Cdiv=3E=3Cspan style=3D=22font-size=3A 13=2E3333330154419px=3B= =22=3E=A0 =A0possibility of conflicts with operational traffic=2E=3C/spa= n=3E=26quot=3B=3C/div=3E=3Cdiv=3E=3Cbr /=3E=3C/div=3E=3Cdiv=3Ewhich in m= y understanding does not recommend the use of ULA s=2E=3C/div=3E=3Cdiv=3E= =3Cbr /=3E=3C/div=3E=3Cdiv=3EBest regards=2C=3C/div=3E=3Cdiv=3EMarius=A0= =3C/div=3E=3Cdiv=3E=3Cbr /=3E=3C/div=3E=3Cdiv=3E=3Cspan=3EOn 07/24/15=2C= =3Cb class=3D=22name=22=3EAlexandru Petrescu =3C/b=3E =26lt=3Balexandru= =2Epetrescu=40gmail=2Ecom=26gt=3B wrote=3A=3C/span=3E=3Cblockquote cite=3D= =22mid=3A55B29026=2E1070906=40gmail=2Ecom=22 class=3D=22iwcQuote=22 styl= e=3D=22border-left=3A 1px solid =2300F=3B padding-left=3A 13px=3B margin= -left=3A 0=3B=22 type=3D=22cite=22=3E=3Cdiv class=3D=22mimepart text pla= in=22=3E=3Cbr /=3E=3Cbr /=3ELe 24/07/2015 11=3A16=2C GEORGESCU LIVIU MAR= IUS a =E9crit =3A=3Cbr /=3E=26gt=3BHello v6ops=2C=3Cbr /=3E=26gt=3B=3Cbr= /=3E=26gt=3BRelated=A0 to the question that came up in Stuart Cheshire=27= s presentation=3Cbr /=3E=26gt=3Babout the prefix used for benchmarking=2C= RFC5180(with errata) =26quot=3BIPv6=3Cbr /=3E=26gt=3BBenchmarking Metho= dology for Network Interconnect Devices=26quot=3B (which might=3Cbr /=3E= =26gt=3Bnot apply here) states=3A =26quot=3BThe IANA has assigned 2001=3A= 0002=3A=3A/48 for IPv6=3Cbr /=3E=26gt=3Bbenchmarking=2C which is a 48-bi= t prefix from the RFC 4773 pool=2E=26quot=3B=3Cbr /=3E=26gt=3BI hope thi= s helps=2E=3Cbr /=3E=3Cbr /=3ETo me=2C this is an additional reason to t= hink that it is good to use ULAs (not 2001=3As or Teredos) behind any fo= rm of NATxy=2E=3Cbr /=3E=3Cbr /=3EBut I heard there may be good reasons = to avoid ULA in NAT64=2E=A0 Not sure which=2E=3Cbr /=3E=3Cbr /=3EAlex=3C= br /=3E=3Cbr /=3E=26gt=3B=3Cbr /=3E=26gt=3BBest regards=2C=3Cbr /=3E=26g= t=3BMarius=3Cbr /=3E=26gt=3B=3Cbr /=3E=26gt=3B=3Cbr /=3E=26gt=3B=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=3Cbr /=3E=26= gt=3Bv6ops mailing list=3Cbr /=3E=26gt=3Bv6ops=40ietf=2Eorg=3Cbr /=3E=26= gt=3B=3Ca href=3D=22https=3A//www=2Eietf=2Eorg/mailman/listinfo/v6ops=22= target=3D=22l=22=3Ehttps=3A//www=2Eietf=2Eorg/mailman/listinfo/v6ops=3C= /a=3E=3Cbr /=3E=26gt=3B=3Cbr /=3E=3Cbr /=3E=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=3Cbr /=3Ev6ops mailing list=3Cbr= /=3Ev6ops=40ietf=2Eorg=3Cbr /=3E=3Ca href=3D=22https=3A//www=2Eietf=2Eo= rg/mailman/listinfo/v6ops=22 target=3D=22l=22=3Ehttps=3A//www=2Eietf=2Eo= rg/mailman/listinfo/v6ops=3C/a=3E=3Cbr /=3E=3C/div=3E=3C/blockquote=3E=3C= /div=3E ----7bf5644769e853851747-- From nobody Sat Jul 25 04:00:41 2015 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 8A6EF1A1AA8 for ; Sat, 25 Jul 2015 04:00:39 -0700 (PDT) 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 WMb8QhQpRbqC for ; Sat, 25 Jul 2015 04:00:38 -0700 (PDT) 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 D9EB61A0094 for ; Sat, 25 Jul 2015 04:00:37 -0700 (PDT) Received: from [2a02:2121:84:39a0:0:37:df5b:3401] (port=41327 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1ZIxBw-0003PL-Ca; Sat, 25 Jul 2015 13:00:32 +0200 Date: Sat, 25 Jul 2015 13:00:29 +0200 From: Tore Anderson To: Alberto Leiva Message-ID: <20150725130029.41fedd80@envy.fud.no> In-Reply-To: References: <201507041147.t64Bl2oR005661@irp-lnx1.cisco.com> <559A5DB6.4090602@cernet.edu.cn> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; 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, draft-bao-v6ops-rfc6145bis@tools.ietf.org Subject: Re: [v6ops] new draft: draft-bao-v6ops-rfc6145bis 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, 25 Jul 2015 11:00:39 -0000 * Alberto Leiva > > Destination Address: In the stateless mode, which is to say that if > > the IPv4 destination address is within a range of configured IPv4 > > stateless translation prefix, the IPv6 destination address is the > > IPv4-translatable address derived from the IPv4 destination > > address per [RFC6052], Section 2.3. A workflow example of > > stateless translation is shown in Appendix A of this document. > > Besides the default algorithm defined [RFC6052], other mechanisms > > also exist, which are defined in Section 6 of this document (EAM) > > and in [I-D.ietf-softwire-map-t]. > > > > In the stateful mode (which is to say that if the IPv4 destination > > address is not within the range of any configured IPv4 stateless > > translation prefix), the IPv6 destination address and > > corresponding transport-layer destination port are derived from > > the Binding Information Bases (BIBs) reflecting current session > > state in the translator as described in [RFC6146]. > > I find this a little excessive. It also seems to mandate no other > address translation mechanisms should exist (is this true?). Hi Alberto, and thank you for your feedback! Fernando, Fred, Xing and I met on Friday morning to discuss 6145bis. This exact issue came up. Suffice it to say that new text that approaches the problem in much the same way you suggested is already in the works, so please wait for -01 and let us know if that addresses your concern in a satisfactory manner. Tore From nobody Sat Jul 25 18:21:16 2015 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 BC14D1ACD94 for ; Sat, 25 Jul 2015 18:21:06 -0700 (PDT) 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 uiSZTxryTCbl for ; Sat, 25 Jul 2015 18:21:05 -0700 (PDT) Received: from cdcipgw01.twcable.com (unknown [165.237.91.110]) by ietfa.amsl.com (Postfix) with ESMTP id 96E021ACD9C for ; Sat, 25 Jul 2015 18:21:04 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.15,544,1432612800"; d="scan'208";a="337351810" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdcipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 25 Jul 2015 21:17:53 -0400 Received: from PRVPEXVS10.corp.twcable.com ([10.136.163.41]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Sat, 25 Jul 2015 21:21:04 -0400 From: "George, Wes" To: Alexandru Petrescu , "v6ops@ietf.org" Date: Sat, 25 Jul 2015 21:21:03 -0400 Thread-Topic: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability Thread-Index: AdDHQVbQlv070Q+zTtWTeTckXzcR1Q== Message-ID: References: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> <9290D0D1-062A-4DE0-A437-9A5F5045ACAC@gmail.com> <39F63B55-977F-4B84-8B55-52E2F0B1A851@cisco.com> <55A6771E.30805@gmail.com> In-Reply-To: <55A6771E.30805@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.3.150624 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability 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, 26 Jul 2015 01:21:06 -0000 DQoNCk9uIDcvMTUvMTUsIDExOjA3IEFNLCAidjZvcHMgb24gYmVoYWxmIG9mIEFsZXhhbmRydSBQ ZXRyZXNjdSINCjx2Nm9wcy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBhbGV4YW5kcnUu cGV0cmVzY3VAZ21haWwuY29tPiB3cm90ZToNCg0KPk9uZSBwcm9ibGVtIEkgc2VlIGlzIHdoZW4g b3BlcmF0b3JzIGRlbGl2ZXIgYSBzaW5nbGUgZ2xvYmFsIC82NCBwcmVmaXgsDQo+YW5kIHRoYXQg LzY0IGlzIHVuZGVyc3Rvb2QgYXMgYSBzaW5nbGUgSVB2NiBnbG9iYWwgYWRkcmVzcy4NCj4NCj5G b3JtaW5nIG11bHRpcGxlIElQdjYgYWRkcmVzc2VzIG91dCBvZiBhIHNpbmdsZSAvNjQgaXMgcG9z c2libGUgZm9yDQo+bXVsdGlwbGUgYXBwcyBydW5uaW5nIG9uIHRoYXQgZGV2aWNlLCBzbyB0aGF0 IG1heSBub3QgYmUgYSBwcm9ibGVtLg0KPlRoZXJlIG1heSBiZSBzb21lIHByaXZhY3kgY29uY2Vy bnMgdGhvdWdoLCBpbiB0aGF0IGFuIGF0dGFja2VyIGNhbg0KPmlkZW50aWZ5IHRoZXJlIGlzIGEg c2luZ2xlIGRldmljZSB0aGVyZSAodGhlIC82NCBpcyB1bmlxdWUpLg0KDQpXR10gdGhhdCBpcyBu b3QgYSBwcml2YWN5IGNvbnNpZGVyYXRpb24gdGhhdCBpcyB1bmlxdWUgdG8gdGhpcyBkb2N1bWVu dCwNCmFuZCBhcyBzdWNoIEkgcmVjb21tZW5kIHRoYXQgd2Ugc3RheSBhd2F5IGZyb20gaXQsIGFz IGl0IGp1c3QgZGlzdHJhY3RzDQpmcm9tIHRoZSBtYWluIHBvaW50IGJ5IGVzc2VudGlhbGx5IGFz a2luZyBmb3Igcm9sbGluZyAvNjQgYXNzaWdubWVudHMgb3INCm11bHRpcGxlIC82NHMuIFdlIG5l ZWQgdG8ga2VlcCB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudCBmYWlybHkgdGlnaHQuDQoNCj4N Cj5CdXQgJ3NoYXJpbmcnIHRoZXNlIElQdjYgYWRkcmVzc2VzIHdpdGggc29tZSBvdGhlciBkZXZp Y2VzICg2NHNoYXJlKSBoYXMNCj5tb3JlIHNlcmlvdXMgZHJhd2JhY2tzLCB0eXBpY2FsbHkgaW4g dGhlIG51bWJlciBvZiBzdWJuZXRzIC0gb25seSBvbmUNCj5zdWJuZXQgaXMgcG9zc2libGUuDQoN CldHXSBJIGZ1bGx5IGV4cGVjdCBpbXBsZW1lbnRhdGlvbnMgb2YgdGhlIHR5cGUgdGhhdCB0aGlz IGRyYWZ0IGRpc2N1c3Nlcw0KdG8gZ2V0IGJ5IHdpdGggYnJpZGdpbmcgaWYgdGhleSBuZWVkIHRv IHNoYXJlIGEgLzY0IHN1Y2ggYXMgZm9yIG1vYmlsZQ0KZGV2aWNlIHRldGhlcmluZy4gSWYgdGhl eSB0cnVseSBuZWVkIG11bHRpcGxlIHN1Ym5ldHMsIHRoZXJlIGlzIG5vIHdheSB0bw0KZ2V0IGFy b3VuZCBzdXBwb3J0aW5nIERIQ1BfUEQgd2l0aCBzb21lIHNhbmUgY29uZmlndXJhdGlvbiBhcm91 bmQgc2VuZGluZw0KYW5kIGFjY2VwdGluZyBoaW50cyBmb3IgbGFyZ2VyIHByZWZpeGVzLCBiZWNh dXNlIHRoYXQgZG9lc24ndCB3b3JrIGZvcg0KU0xBQ0MgZWl0aGVyLiBUaGF0IHByb2JhYmx5IG5l ZWRzIHRvIGJlIGFub3RoZXIgZG9jdW1lbnQsIHdpdGggdGhvc2UNCnNwZWNpZmljIHVzZSBjYXNl cyBkb2N1bWVudGVkLCBiZWNhdXNlICJhbHdheXMgc3VwcG9ydCBtdWx0aXBsZSBzdWJuZXRzIg0K aXMgYSBtb3JlIHNpZ25pZmljYW50IHJlcXVlc3QgdGhhbiAiYWx3YXlzIHN1cHBvcnQgbXVsdGlw bGUgYWRkcmVzc2VzIg0KDQoNClRoYW5rcywNCg0KV2VzDQoNCg0KQW55dGhpbmcgYmVsb3cgdGhp cyBsaW5lIGhhcyBiZWVuIGFkZGVkIGJ5IG15IGNvbXBhbnnigJlzIG1haWwgc2VydmVyLCBJDQpo YXZlIG5vIGNvbnRyb2wgb3ZlciBpdC4NCi0tLS0tLS0tLS0tDQoNCg0KDQpUaGlzIEUtbWFpbCBh bmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBw cm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFs LCBvciBzdWJqZWN0IHRvIGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUu IFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZp ZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0 aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3Rp ZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFj dGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRz IHRvIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1 bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3Rp ZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmln aW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4NCg== From nobody Sat Jul 25 18:21:18 2015 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 512D01ACDA2 for ; Sat, 25 Jul 2015 18:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.424 X-Spam-Level: * X-Spam-Status: No, score=1.424 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 V-dfgh4XQj3x for ; Sat, 25 Jul 2015 18:21:06 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id CEFA41ACD9D for ; Sat, 25 Jul 2015 18:21:04 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.15,544,1432612800"; d="scan'208";a="916625576" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 25 Jul 2015 21:14:01 -0400 Received: from PRVPEXVS10.corp.twcable.com ([10.136.163.41]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Sat, 25 Jul 2015 21:21:03 -0400 From: "George, Wes" To: "fred@cisco.com" , "v6ops@ietf.org" Date: Sat, 25 Jul 2015 21:21:02 -0400 Thread-Topic: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability Thread-Index: AdDHQVYZ4noURFk6SE2mgaJ0/gjbLg== Message-ID: References: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> In-Reply-To: <201507061147.t66Bl1AE028312@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.3.150624 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-colitti-v6ops-host-addr-availability@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability 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, 26 Jul 2015 01:21:08 -0000 SSd2ZSByZWFkIC0wMS4gSSBzdXBwb3J0IHRoZSBwYXJ0IG9mIHRoZSBkcmFmdCB0aGF0IGV4cGxh aW5zIHdoeSBtdWx0aXBsZQ0KYWRkcmVzc2VzIGFyZSBuZWNlc3NhcnkuIFRoZSBkZXRhaWwgYXJv dW5kIG5vdCBoYXZpbmcgdG8gaGF2ZSBldmVyeQ0KYXBwbGljYXRpb24gb24gYSBkZXZpY2UgYm91 bmQgdG8gdGhlIHNhbWUgYWRkcmVzcyBpcyBxdWl0ZSBpbXBvcnRhbnQgYW5kDQpub3QgYXQgYWxs IGludHVpdGl2ZSB0byB0aG9zZSB1c2VkIHRvIHRoaW5raW5nIGFib3V0IElQdjQgaW1wbGVtZW50 YXRpb25zDQp3aXRoIG9ubHkgb25lIGFkZHJlc3MgYXZhaWxhYmxlLiBIb3dldmVyLCB0aGVyZSBh cmUgc29tZSBvdGhlciBzZWN0aW9ucyBvZg0KdGhpcyBkcmFmdCB0aGF0IG5lZWQgc29tZSByZWZp bmVtZW50IHRvIHByb3ZpZGUgYmV0dGVyIHN1cHBvcnRpbmcNCmFyZ3VtZW50cyBmb3IgdGhlIHJl Y29tbWVuZGF0aW9ucyBiZWluZyBnaXZlbi4NCg0KU2VjdGlvbiAzIC0NCjV0aCBidWxsZXQgIlRy YW5zbGF0aW9uLWJhc2VkLi4iIE5lZWQgYSByZWZlcmVuY2UgdG8gdGhlIDQ2NFhMYXQgZG9jIHVw DQpoZXJlIGluc3RlYWQgb2YgYmVsb3csIHNwZWNpZmljYWxseSBhIHBvaW50ZXIgdG8gdGhlIHNl Y3Rpb24gZGljdGF0aW5nIHRoZQ0KdXNlIG9mIGEgc2VwYXJhdGUgYWRkcmVzcw0KDQpTZWN0aW9u IDQtIFRoaXMgc2VjdGlvbiBpcyBwcmV0dHkgaGFuZHdhdmV5IHJpZ2h0IG5vdy4gVGhlcmUgYXJl IHBsZW50eSBvZg0KdGhpbmdzIGluIHRoZSBtb2JpbGUgc3BhY2UgdGhhdCBpbnZvbHZlIHdhaXRp bmcgZm9yIHNvbWV0aGluZyB0byBoYXBwZW4gaW4NCm5ldHdvcmsgcHJvdmlzaW9uaW5nLiBDb25u ZWN0aW5nIHRvIHRoZSBuZXR3b3JrIGlzbid0IGluc3RhbnRhbmVvdXMsIG5vcg0KaXMgZW5hYmxp bmcgdGV0aGVyaW5nLiBNYW55IHRpbWVzIGFwcGxpY2F0aW9uIGxhdW5jaGVzIG9yIGFjdGlvbnMg YXJlDQpkZWxheWVkIGJ5IHJhZGlvIHdha2UtdXAgb3IgbmV0d29yayBjb25nZXN0aW9uLCBldGMu IEkgYWdyZWUgdGhhdCB0aGVyZSBpcw0KYW4gbWF4aW11bSB3aW5kb3cgb2Ygd2hhdCBjb25zdGl0 dXRlcyBhIGdvb2QgdXNlciBleHBlcmllbmNlLCBidXQgaWYgSSBjYW4NCmhhdmUgYSBESENQdjYg c2VydmVyIGxpc3RlbmluZyBmb3Igc3Vic2VxdWVudCByZXF1ZXN0cyBmb3IgYWRkcmVzc2VzIGFu ZA0KaXQgZ2V0cyB0aGVtIGJhY2sgdG8geW91IHdpdGhpbiBhIHJlYXNvbmFibGUgd2luZG93IGZv ciBhIGdvb2QgdXNlcg0KZXhwZXJpZW5jZSwgeW91IG5lZWQgdG8gZXhwbGFpbiB3aHkgdGhhdCB3 b24ndCB3b3JrLiBZb3UgYWxzbyBuZWVkIHRvDQpleHBsYWluIHdoeSBpZiB5b3Uga25vdyB0aGF0 IGEgY2VydGFpbiBudW1iZXIgb2YgYWRkcmVzc2VzIGFyZSBuZWVkZWQsIHdoeQ0KYSBkZXZpY2Ug Y291bGRuJ3QgcmVxdWVzdCBtb3JlIHRoYW4gb25lIHdoZW4gY29ubmVjdGluZyB0byB0aGUgbmV0 d29yaw0KaW5pdGlhbGx5LiBJIHJlYWxpemUgbW9iaWxlIGlzbid0IHRoZSBvbmx5IGNhc2UgaGVy ZSwgc28gd2UgbmVlZCB0byBoYXZlDQp0aGUgc2FtZSBkaXNjdXNzaW9uIGZvciBvdGhlciB0eXBl cyBvZiBhcHBsaWNhdGlvbnMgLSBzaW5jZSBpbnN0YW50IGlzbid0DQphIHZhbGlkIGFuc3dlciwg YmVjYXVzZSBhbG1vc3Qgbm90aGluZyBpcyBpbnN0YW50IG9uIGZyb20gY29sZCwgd2hhdCdzIHRo ZQ0Kb3V0c2lkZSBlbnZlbG9wZSBmb3IgYSBnb29kIHVzZXIgZXhwZXJpZW5jZT8gVGhpbmsgaW4g dGVybXMgb2YgaW5pdGlhbA0KY29ubmVjdGlvbiB0byB0aGUgbmV0d29yayAod2hlcmUgeW91IG1p Z2h0IGFzayBmb3IgbXVsdGlwbGUgYWRkcmVzc2VzKSBhbmQNCnRoZW4gc3Vic2VxdWVudCB3YWtl dXAgd2hlcmUgeW91IGFscmVhZHkgaGF2ZSB0aGVtLg0KSWYgdGhlcmUncyBjb21wbGV4aXR5IGlu IGRlYWxpbmcgd2l0aCBmYWlsdXJlIGNhc2VzLCBvciB1bmNlcnRhaW50eSBvbg0Kd2hldGhlciBh IGZlYXR1cmUgaXMgYXZhaWxhYmxlLCBleHBsYWluIHRob3NlIGlzc3VlcyBpbiBtb3JlIGRlcHRo LiBBZ2FpbiwNCm1vYmlsZSBkZXZpY2VzIHRlbGwgdXNlcnMgYWxsIHRoZSB0aW1lICJzZXJ2aWNl IG5vdCBhdmFpbGFibGUiIG9yDQoicmVzdHJpY3RlZCBieSBjYXJyaWVyIiBvciB3aGF0ZXZlci4g SSdtIG5vdCBkZWZlbmRpbmcgdGhhdCBhcyBhIGdvb2QgdXNlcg0KZXhwZXJpZW5jZSwgYnV0IEkn bSBub3QgY2VydGFpbiB3ZSBjYW4gZGlzY291bnQgc29sdXRpb25zIGJhc2VkIG9uIHdoYXQgd2UN CmRvbid0IGxpa2UgYWJvdXQgaG93IGNhcnJpZXJzIGFuZCBkZXZpY2VzIG9wZXJhdGUgdG9kYXku IEluIG90aGVyIHdvcmRzLA0KZ2l2aW5nIGEgZGV2aWNlIGFzIG1hbnkgYWRkcmVzc2VzIGFzIGl0 IHdhbnRzIGlzbid0IGdvaW5nIHRvIGZpeCBhbGwgb2YNCnRob3NlIG90aGVyIHRoaW5ncyB0aGF0 IGNvbnRyaWJ1dGUgdG8gYSBiYWQgdXNlciBleHBlcmllbmNlIGJlY2F1c2UgdGhleQ0KYXJlIHJl c3RyaWN0ZWQgYnkgdGhlIGNhcnJpZXIgb3IgaW1wYWN0ZWQgYnkgdGhlIGJlaGF2aW9yIG9mIHRo ZSBuZXR3b3JrLA0Kc28gSSBkb24ndCBzZWUgc29sdmluZyB0aGF0IGlzc3VlIGhlcmUgYXMgYW4g aW1wZXJhdGl2ZS4gSSdtIG9wZW4gdG8gYmVpbmcNCmNvbnZpbmNlZCBvdGhlcndpc2UsIGJ1dCB0 aGF0J3Mgc29tZXRoaW5nIHRoYXQgdGhlIGRyYWZ0IG5lZWRzIHRvIGRpc2N1c3MuDQoNCkkgdGhp bmsgeW91IGFsc28gbmVlZCB0byBkaXN0aW5ndWlzaCBpbiB0aGUgZHJhZnQgYmV0d2VlbiBpbXBs ZW1lbnRhdGlvbnMNCm9yIHNpdHVhdGlvbnMgdGhhdCBSRVFVSVJFIG1vcmUgdGhhbiBvbmUgYWRk cmVzcyBvciBlbHNlIHRoZXkgc2ltcGx5IHdvbid0DQp3b3JrIChzdWNoIGFzIHRldGhlcmluZywg Vk1zLCBldGMpIHZzIGltcGxlbWVudGF0aW9ucyB3aGVyZSBpdCdzIHNpbXBseQ0KZWFzaWVyIHRv IHVzZSBtdWx0aXBsZSBhZGRyZXNzZXMgdGhhbiBiaW5kaW5nIHRoZSBzYW1lIGFkZHJlc3MgdG8g bXVsdGlwbGUNCmFwcGxpY2F0aW9uIHNvY2tldHMgc3VjaCBhcyB5b3Ugd291bGQgZG8gd2l0aCBh IHNpbmdsZSBJUHY0IGFkZHJlc3MuIElmDQp5b3UncmUgYWN0dWFsbHkgZG9pbmcgYW4gSVB2NCBO QVQgd2l0aGluIHRoZSBkZXZpY2UgdG9kYXkgdG8gYXZvaWQgaGF2aW5nDQp0byBoYXZlIG11bHRp cGxlIGFwcGxpY2F0aW9ucyB1c2luZyB0aGUgc2FtZSBhZGRyZXNzIGluIElQdjQsIHRoZW4gbWFr ZQ0KdGhhdCBjbGVhciBpbiB0aGUgZG9jdW1lbnQuDQoNClNlY3Rpb24gNSAtIEkgdGhpbmsgd2Ug bmVlZCB0byBjdXQgdGhpcyBzZWN0aW9uIGRvd24gdG8gYSBiYXJlIG1pbmltdW0gb3INCmVsaW1p bmF0ZSBpdC4gV2F2aW5nIHRoZSBOQVQgYm9vZ2V5bWFuIGlzbid0IHJlYWxseSB0aGUgYXJndW1l bnQgdG8gbGVhZA0Kd2l0aCwgdW5sZXNzIHRoZSBhdXRob3JzIG9yIG90aGVyIE9TIG1hbnVmYWN0 dXJlcnMgYWN0dWFsbHkgc2VlIHRoaXMgYXMgYQ0KY3JlZGlibGUgYWx0ZXJuYXRpdmUgYW5kIGFy ZSB3aWxsaW5nIHRvIGltcGxlbWVudCBpdCBpbnN0ZWFkIG9mIG90aGVyDQpvcHRpb25zLiBPdGhl cndpc2UgaXQncyBqdXN0IEZVRC4gSXQncyBtb3JlIGFjY3VyYXRlIGF0IHRoaXMgcG9pbnQgdG8g c2F5DQp0aGF0IE5BVCBkb2Vzbid0IGV4aXN0IGZvciBJUHY2LCBiZWNhdXNlIHRoZSBJRVRGIGRv Y3VtZW50IGlzIGV4cGVyaW1lbnRhbA0KKElJUkMsIEknbSB3cml0aW5nIHRoaXMgb24gYSBwbGFu ZSBhbmQgY2FuJ3QgY2hlY2spIGFuZCBubyBpbXBsZW1lbnRhdGlvbnMNCnJlYWxseSBleGlzdCBp biB0aGUgd2lsZCwgc28gYW5vdGhlciBzb2x1dGlvbiBpcyByZXF1aXJlZC4gV2UndmUgYWxyZWFk eQ0Kd3JpdHRlbiBwbGVudHkgYWJvdXQgd2h5IE5BVHMgYXJlIGJhZCBlbHNld2hlcmUuDQoNCjku MSBpcyBjb21iYXRpdmUsIGRpc21pc3NpdmUsIGFuZCBpbmNvbXBsZXRlLiBUaGUgcHJvYmxlbSBp cyBub3QgdGhhdA0Kb3BlcmF0b3JzIGhhdmUgbWFkZSB0aGUgYXJndW1lbnQgdGhhdCBESENQdjYg aXMgdGhlIG9ubHkgd2F5IHRvLi4uDQpXaGF0IHRoZXkndmUgc2FpZCBpcyB0aGF0IHRoZXkgcmVx dWlyZSBhIHdheSB0byB0cmFjayB3aGljaCBJUHY2IGFkZHJlc3Nlcw0KYXJlIGFzc2lnbmVkIHRv IHdoaWNoIGhvc3RzIGZvciBwb2xpY3kgYW5kIGxlZ2FsIHJlYXNvbnMsIGFuZCB0aGF0IGlzDQpk cml2aW5nIGEgc2V0IG9mIGRlcGxveW1lbnQgZGVjaXNpb25zLiBUaGF0J3Mgbm90IHVwIGZvciBk ZWJhdGUgb3INCm5lZ290aWF0aW9uLCBhbmQgaXMgcGFydCBvZiB0aGUgcmVhc29uIHdoeSBvdGhl ciBkaXNjdXNzaW9ucyBvZiB0aGlzIGlzc3VlDQpoYXZlIGJlZW4gc28uLi52aWdvcm91cy4gSUVU RiBuZWVkcyB0byBnZXQgb3V0IG9mIHRoZSBoYWJpdCBvZiB0ZWxsaW5nDQpvcGVyYXRvcnMgdGhh dCB0aGVpciBwcm9ibGVtIGlzbid0IGEgcHJvYmxlbSwgYW5kIGZvY3VzIG9uIGRpc2N1c3Npbmcg dGhlDQpwb3NzaWJsZSBzb2x1dGlvbnMsIGlkZW50aWZ5aW5nIHdoYXQgY29uc2Vuc3VzIHNheXMg aXMgdGhlIGJlc3Qgd2F5IHRvDQpzb2x2ZSB0aGUgcHJvYmxlbS4NClRoZXJlIGFyZSBzZXZlcmFs IHdheXMgdG8gc29sdmUgdGhlIHN0YXRlZCBwcm9ibGVtLiBPbmUgaXMgREhDUHY2LiBJdCBoYXMN CnByb3MgYW5kIGNvbnMsIHNvbWUgb2Ygd2hpY2ggYXJlIGRpc2N1c3NlZCBlbHNld2hlcmUgaW4g dGhlIGRvY3VtZW50LA0KbWFpbmx5IGluIHRoZSBmb3JtIG9mIHdoeSBESENQdjYgdG8gYXNzaWdu IGEgc2luZ2xlIGFkZHJlc3MgaXMgYSBwcm9ibGVtLg0KQW5vdGhlciB3YXkgaXMgd2hhdGV2ZXIg dGhlIGF1dGhvcnMgYXJlIGRvaW5nIG9uIHRoZWlyIG93biBuZXR3b3Jrcy4gSQ0KYXNzdW1lIHRo YXQgaXQgYWxzbyBoYXMgcHJvcyBhbmQgY29ucywgYnV0IHNpbmNlIGl0J3Mgbm90IGV2ZW4gZGlz Y3Vzc2VkLA0KcmlnaHQgbm93IHlvdSdyZSBiYXNpY2FsbHkgbWFraW5nIGFuIHVuc3VwcG9ydGVk IGFzc2VydGlvbiB0aGF0IGl0J3MgYW4NCmFsdGVybmF0aXZlLiBGdXJ0aGVyLCB5b3UgbWFrZSBu byBlZmZvcnQgdG8gZXhwbGFpbiBob3cgYSBkdWFsLXN0YWNrDQplbnRlcnByaXNlIG5ldHdvcmsg aXMgdGhlIHNhbWUgKGkuZS4gSXQgc2hhcmVzIHRoaXMgbmVlZCBmb3IgdHJhY2tpbmcpIGFzDQp0 aGUgbWVudGlvbmVkIGV4YW1wbGVzIG9mIGFjYWRlbWljIGFuZCBvdGhlciBuZXR3b3JrcyB0aGF0 IHByb3ZpZGUgdGhpcmQNCnBhcnR5IHNlcnZpY2VzLiBEaXNjdXNzIHRoZSBhbHRlcm5hdGl2ZXMg ZXF1YWxseSBpbnN0ZWFkIG9mIHRyeWluZyB0bw0KcHJlZGlzcG9zZSB0aGUgcmVhZGVyIHRvIGFn cmVlIHdpdGggeW91ciBwcmUtY29uY2VpdmVkIGJlbGllZiB0aGF0IERIQ1B2Ng0KaXNuJ3QgbmVj ZXNzYXJ5IG9yIG5vdCB0aGUgYmVzdCB3YXkgdG8gZG8gdGhpcyBiZWNhdXNlIGl0cyBjb25zIG91 dHdlaWdoDQppdHMgcHJvcy4gVGhpcyBpcyB3aGVyZSBFcmlrJ3Mgc3VnZ2VzdGlvbiBhYm91dCBv dGhlciBtZXRob2RzIG9mIGxvZ2dpbmcNCmJlbG9uZ3MgYXMgd2VsbC4NCg0KDQpUaGFua3MsDQoN Cldlcw0KDQoNCg0KT24gNy82LzE1LCA3OjQ3IEFNLCAidjZvcHMgb24gYmVoYWxmIG9mIGZyZWRA Y2lzY28uY29tIg0KPHY2b3BzLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGZyZWRAY2lz Y28uY29tPiB3cm90ZToNCg0KPkEgbmV3IGRyYWZ0IGhhcyBiZWVuIHBvc3RlZCwgYXQNCj5odHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jb2xpdHRpLXY2b3BzLWhvc3QtYWRkci1hdmFp bGFiaWxpdHkuDQo+UGxlYXNlIHRha2UgYSBsb29rIGF0IGl0IGFuZCBjb21tZW50Lg0KPg0KPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+djZvcHMgbWFp bGluZyBsaXN0DQo+djZvcHNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3Y2b3BzDQoNCg0KVGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVu dHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24s IHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdCB0byBjb3B5cmln aHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRl ZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNo IGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBv ZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5h dGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24g dG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJp Y3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRl bHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRo aXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuDQo= From nobody Sat Jul 25 20:26:03 2015 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 9A7DB1B2A2A for ; Sat, 25 Jul 2015 20:26:01 -0700 (PDT) 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, 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 TkMB8OdDH1qk for ; Sat, 25 Jul 2015 20:26:00 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::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 7968F1B2A29 for ; Sat, 25 Jul 2015 20:26:00 -0700 (PDT) Received: by iecri3 with SMTP id ri3so43388963iec.2 for ; Sat, 25 Jul 2015 20:26:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=v4xyx4+dDGAJzTz0A2V3iHw5jOQIMSe5foo830uvH0I=; b=t5Wkj4KZeewv1S9BWSGn978/6bu1WXA5tBFewT/aEDkKP6rXB4M1vWAqGGYf5oGxnf SW5GfMsqqeTTcpajsiQeltoEiFZ89o2sAT/DiW3Qy9Oi8dqXwDzC1+1dAAm78DILYpM4 hkaxzuHf43lXHOVbMLO+gQQp+gQ1m8ZtULuPqCBaP0R5Vcl7I2aIMDDJzOF0BNNrXC7/ xkJW4nbtVCcCVqiR8FiureypNGHxjwrReA3jC0rXkjFYFdJm+YTbcY+YNsGbRUgqkYTw PHGQC8SjnBcwmva+hymdGpGY7WIgtlHRgE4AQ87RUidYxSwqO3lHcbHV0UnLYesTEn5l 6umA== X-Received: by 10.50.30.65 with SMTP id q1mr7721783igh.28.1437881159995; Sat, 25 Jul 2015 20:25:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.169.143 with HTTP; Sat, 25 Jul 2015 20:25:30 -0700 (PDT) In-Reply-To: References: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> From: Mark Smith Date: Sun, 26 Jul 2015 13:25:30 +1000 Message-ID: To: "George, Wes" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" , "draft-colitti-v6ops-host-addr-availability@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability 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, 26 Jul 2015 03:26:01 -0000 On 26 July 2015 at 11:21, George, Wes wrote: > > 9.1 is combative, dismissive, and incomplete. The problem is not that > operators have made the argument that DHCPv6 is the only way to... > What they've said is that they require a way to track which IPv6 addresses > are assigned to which hosts for policy and legal reasons, and that is > driving a set of deployment decisions. That's not up for debate or > negotiation, and is part of the reason why other discussions of this issue > have been so...vigorous. IETF needs to get out of the habit of telling > operators that their problem isn't a problem, and focus on discussing the > possible solutions, identifying what consensus says is the best way to > solve the problem. So what I'd like to know more about then is the particular problem being trying to be solved, or more specifically the business problem or problems being solved. "Having a record of IP addresses assigned to devices" isn't a problem statement, it is a statement of what a mechanism such as DHCP is theoretically achieves. That record needs to be used for something, so what are those uses? I assume it is to satisfy a security need. But what are the specific security needs? Is there anything formal that requires it, e.g., PCI DSS? My view is that one of the security needs is to be able to have an audit log of devices attached to the network at particular times, so that if there is a security attack of some form, theoretically it is possible to identify who and/or who's device was used for the attack. Both DHCPv4 and DHCPv6 won't actually achieve that goal, because neither of them record static address assignments on hosts, and DHCPv6 doesn't record link-local addresses assigned or in use either. A competent attacker will certainly know the risks of using DHCP to acquire an address on a network they wish to minimise their footprint on. They'll configure valid static addresses or use link-local addresses if their target is on-link. The IETF can come up with a proper solution statement once a proper problem statement exists. Does a proper problem statement exist somewhere? Regards, Mark. From nobody Sat Jul 25 23:30:41 2015 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 C3CDD1A874A for ; Sat, 25 Jul 2015 23:30:40 -0700 (PDT) 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_40=-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 5nKSqWnNtiUZ for ; Sat, 25 Jul 2015 23:30:39 -0700 (PDT) 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 13B2C1A874C for ; Sat, 25 Jul 2015 23:30:38 -0700 (PDT) Received: from [2a02:fe0:c412:1fe0::2] (port=41426 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1ZJFS9-0006bY-61; Sun, 26 Jul 2015 08:30:29 +0200 Date: Sun, 26 Jul 2015 08:30:28 +0200 From: Tore Anderson To: "Fred Baker (fred)" Message-ID: <20150726083028.02d6038d@envy.fud.no> In-Reply-To: <03B11480-F2E2-4B66-B7A2-1E4824E63D06@cisco.com> References: <03B11480-F2E2-4B66-B7A2-1E4824E63D06@cisco.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-v6ops-siit-dc@tools.ietf.org" , v6ops list Subject: Re: [v6ops] Comment on siit-dc 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, 26 Jul 2015 06:30:40 -0000 * Fred Baker (fred) > The abstract reads: > > This document describes the use of the Stateless IP/ICMP Translation > (SIIT) algorithm in an IPv6 Internet Data Centre (IDC). In this > deployment model, traffic from legacy IPv4-only clients on the > Internet is translated to IPv6 when reaches the IDC operator's > network infrastructure. From that point on, it is treated just as if > it was traffic from any other IPv6-capable end user. This > facilitates a single-stack IPv6-only network infrastructure, as well > as efficient utilisation of public IPv4 addresses. > > The primary audience is IDC operators who are deploying IPv6, running > out of available IPv4 addresses, and/or feel that dual stack causes > undesirable operational complexity. > > I see what you're saying, but can read it as specifying how an RFC > 6052 address might be used, when you're specifying the use of > siit-eam. May I suggest tweaking the abstract to clarify that? Point taken. How about: This document describes the use of the Stateless IP/ICMP Translation (SIIT) algorithm in an IPv6 Internet Data Centre (IDC). In this deployment model, traffic from legacy IPv4-only clients on the Internet is translated to IPv6 when reaches the IDC operator's network infrastructure. From that point on, it is treated just as if it was traffic from any other IPv6-capable end user. The IPv6 endpoints may be numbered using arbitrary (non-IPv4-translatable) IPv6 addresses. This facilitates a single-stack IPv6-only network infrastructure, as well as efficient utilisation of public IPv4 addresses. The primary audience is IDC operators who are deploying IPv6, running out of available IPv4 addresses, and/or feel that dual stack causes undesirable operational complexity. ...? Tore From nobody Sat Jul 25 23:43:20 2015 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 C89F41A8794 for ; Sat, 25 Jul 2015 23:43:19 -0700 (PDT) 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 RI7Xc7gtU2a2 for ; Sat, 25 Jul 2015 23:43:18 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC5701A8793 for ; Sat, 25 Jul 2015 23:43:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3629; q=dns/txt; s=iport; t=1437892997; x=1439102597; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=8Hu+ZEH0fdWXv4g2lpwZCw7y4K7YHZoY//RyF5e5D/g=; b=Y0LiNeM4AyrhTo366eNpkY1mkmoIogjOyeecapdCEK6yXTpnyXiBgPnv mXwfcGpk9CqiNrOKcEe0cN8CzisDAdEQWQ2uNer5g9ZbpGoeamhetKvfr abjeyHufuSRmjZEc+VoBTUUd6GVe+pvBceklSJ8F4mTlOaNX7f7B37RXg E=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AtAwBjgLRV/5BdJa1bgxWBPQa8AgmHcAKBLzgUAQEBAQEBAYEKhCMBAQEDAXkFCwIBCBguMiUCBA4FDogYCM9VAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tOhQcHgxiBFAWUaQGCN4FXiDKBRYcvkDImg31vgUiBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,546,1432598400"; d="asc'?scan'208";a="172494001" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-4.cisco.com with ESMTP; 26 Jul 2015 06:43:17 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t6Q6hHNj024064 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 26 Jul 2015 06:43:17 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.49]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Sun, 26 Jul 2015 01:43:16 -0500 From: "Fred Baker (fred)" To: Tore Anderson Thread-Topic: [v6ops] Comment on siit-dc Thread-Index: AQHQx25Z5Ai8Q9akDUSjS/EtB/+s3w== Date: Sun, 26 Jul 2015 06:43:16 +0000 Message-ID: References: <03B11480-F2E2-4B66-B7A2-1E4824E63D06@cisco.com> <20150726083028.02d6038d@envy.fud.no> In-Reply-To: <20150726083028.02d6038d@envy.fud.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.61.213.227] Content-Type: multipart/signed; boundary="Apple-Mail=_C02DDC55-0ECF-4FCD-A167-33B4940E1DFF"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-v6ops-siit-dc@tools.ietf.org" , v6ops list Subject: Re: [v6ops] Comment on siit-dc 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, 26 Jul 2015 06:43:19 -0000 --Apple-Mail=_C02DDC55-0ECF-4FCD-A167-33B4940E1DFF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jul 26, 2015, at 8:30 AM, Tore Anderson wrote: >=20 > * Fred Baker (fred) >=20 >> The abstract reads: >>=20 >> This document describes the use of the Stateless IP/ICMP = Translation >> (SIIT) algorithm in an IPv6 Internet Data Centre (IDC). In this >> deployment model, traffic from legacy IPv4-only clients on the >> Internet is translated to IPv6 when reaches the IDC operator's >> network infrastructure. =46rom that point on, it is treated just = as if >> it was traffic from any other IPv6-capable end user. This >> facilitates a single-stack IPv6-only network infrastructure, as = well >> as efficient utilisation of public IPv4 addresses. >>=20 >> The primary audience is IDC operators who are deploying IPv6, = running >> out of available IPv4 addresses, and/or feel that dual stack causes >> undesirable operational complexity. >>=20 >> I see what you're saying, but can read it as specifying how an RFC >> 6052 address might be used, when you're specifying the use of >> siit-eam. May I suggest tweaking the abstract to clarify that? >=20 > Point taken. How about: >=20 > This document describes the use of the Stateless IP/ICMP = Translation > (SIIT) algorithm in an IPv6 Internet Data Centre (IDC). In this > deployment model, traffic from legacy IPv4-only clients on the > Internet is translated to IPv6 when reaches the IDC operator's "when it reaches", or "upon reaching" > network infrastructure. =46rom that point on, it is treated just = as if > it was traffic from any other IPv6-capable end user. The IPv6 Just a thought: s/is treated just as if it was/is indistinguishable = from/ > endpoints may be numbered using arbitrary (non-IPv4-translatable) > IPv6 addresses. This facilitates a single-stack IPv6-only network > infrastructure, as well as efficient utilisation of public IPv4 > addresses. >=20 > The primary audience is IDC operators who are deploying IPv6, > running out of available IPv4 addresses, and/or feel that dual > stack causes undesirable operational complexity. >=20 > ...? >=20 > Tore Works for me. The first suggestion is better English; the second is very = optional but is what I think you're trying to say. --Apple-Mail=_C02DDC55-0ECF-4FCD-A167-33B4940E1DFF 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 iQIVAwUBVbSBgUayAOS/EQ8MAQK8LxAAu/lO5PuBH/TuryB5kyBVF525j9TO0krl PegFgopNi3wTB4QDRvZsox6nnKTOtVhEzPi474jvJ9Wgkl16i/FXO21QLOaDModf 4Mf05xR9aOdWtvF9EeN87mes0hoo0oUQmj/X/D2MNTY9dNQAAeEefWBbwcEKRafN jXDgoXtDwf/LiHuH4+LbCNXpNFTVGfQrOUHr2Lc/aJwOZZKfD1yGkip35Lp1kdNl 67AnMTPlKRvQTuaVeX72Y+o0t6i/xsFPIBlWyjtPpVNDL+ifKXUNJ5npsJ5OVeJA Ys20N3bC0+IdJQm6BgBtsJSNH8iTOvg23s3tPhFasBmwNFlLohudznmMbr6BQ1cv 0PUXgi1xoFm8wL5Dkjy/3BU1TE5BF9NIJNuk9wa7wgO7qhyOMEMtgGaHRpgSnXFN D6scfmpwl0pqQPuk9mcqtECX2zeIpXvJCdIpfYwot3mSI9NvlzGJ/IjzzjEtzWCM gNNAW9abgJecqv3vcasrN0ekfD5dDRfM7KHnrpkR43DbxJZdPJ1/GxDXXlOzUAAH G0R/ZtrFA3qpkHsxA7BiJp0rndlGMsxQheh2dwOl/TP7XfDDioe74yeKgd/YXq2v 1yUhY8hwopau+zoY8EoyatoBWTT08xCuF3cTX+goH+mqOqqyh9MwTFNP/hNjNHTP y38GOYWRcQw= =6sbR -----END PGP SIGNATURE----- --Apple-Mail=_C02DDC55-0ECF-4FCD-A167-33B4940E1DFF-- From nobody Sat Jul 25 23:54:34 2015 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 CDF661A8939 for ; Sat, 25 Jul 2015 23:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aydY8KOIvfco for ; Sat, 25 Jul 2015 23:54:32 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::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 D30E01A8937 for ; Sat, 25 Jul 2015 23:54:31 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so73316906wib.0 for ; Sat, 25 Jul 2015 23:54:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=qMDEWyeM3+4fzkyPciLRFk2b4XGk84l1twDQ7ADi4os=; b=FNCFUzaDc7MyTlbja9IcPpALW67MFniDHm6AD9+IZ+Nn/QO39aM0TSt7Z9RL7lvPBF WnUTNYpaUHFCxWL9ArJEDIHl2lYg6OGSs1UTsGGWGhq4apwvp8XhjAZ7mTDsO84HHqvv jMRfMYNpj5sxdiapl2M1zswVXzGmX+XRImGvmaIwjnd7hTXqU/Ok9f9Gun5uuRVLn/bH xyAYHX6Yldx/flmxI5M888C/PkijJc4VVad8t+/mzflNpL3c3nx8fS1Wt+J9JrV+40Nr A9/qETZvgpI4bu8eJXRgRgXusaYRwIlb3ZJA4K0GjvhHXrEtU8JPV/fDcqUx9kOhV/BE VbCg== X-Received: by 10.180.19.36 with SMTP id b4mr11903906wie.33.1437893670368; Sat, 25 Jul 2015 23:54:30 -0700 (PDT) Received: from [192.168.0.4] (cpc11-brig18-2-0-cust561.3-3.cable.virginm.net. [81.100.118.50]) by smtp.gmail.com with ESMTPSA id k12sm14657596wjw.4.2015.07.25.23.54.29 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Jul 2015 23:54:29 -0700 (PDT) Message-ID: <55B48402.1040202@gmail.com> Date: Sun, 26 Jul 2015 18:53:54 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <6b60e612c4f0.55b20091@naist.jp> <6c008406e2af.55b200cf@naist.jp> <6c00eec89ab8.55b2010d@naist.jp> <6bf095d99dae.55b2014a@naist.jp> <6b50ff96a9ad.55b20188@naist.jp> <6c50a92cde54.55b201c6@naist.jp> <6c50be138e83.55b20205@naist.jp> <6bf08db1e13f.55b20243@naist.jp> <6bf0f7dbdadf.55b20280@naist.jp> <6bf0898ffbd5.55b21ea8@naist.jp> <55B29026.1070906@gmail.com> <6b70d3cfd2f6.55b365ea@naist.jp> <6b70bfbf8107.55b36628@naist.jp> <6c30a2fefa4c.55b36666@naist.jp> <6c50d867e570.55b366a4@naist.jp> <6bf0c04ef47e.55b382fb@naist.jp> In-Reply-To: <6bf0c04ef47e.55b382fb@naist.jp> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] IANA assigned prefix for IPv6 benchmarking 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, 26 Jul 2015 06:54:34 -0000 On 25/07/2015 22:37, GEORGESCU LIVIU MARIUS wrote: > If respecting the recommendations of RFC5180 is desired I think the fol= lowing note in RFC5180 is relevant: >=20 > " Note: Similar to RFC 2544(https://tools.ietf.org/html/rfc2544) avoidi= ng the use of RFC 1918(https://tools.ietf.org/html/rfc1918) address space= > for benchmarking tests, this document does not recommend the use of RF= C 4193(https://tools.ietf.org/html/rfc4193) [4(https://tools.ietf.org/htm= l/rfc5180#ref-4)] (Unique Local Addresses) in order to minimize the=20 > possibility of conflicts with operational traffic." >=20 > which in my understanding does not recommend the use of ULA s. No, but it's a strange argument precisely because ULAs are Unique with ve= ry high probability, so conflict with operational traffic is very improbable. Brian >=20 > Best regards, > Marius=20 >=20 > On 07/24/15, Alexandru Petrescu wrote: >> >> >> >> Le 24/07/2015 11:16, GEORGESCU LIVIU MARIUS a =C3=A9crit : >>> Hello v6ops, >>> >>> Related to the question that came up in Stuart Cheshire's presentatio= n >>> about the prefix used for benchmarking, RFC5180(with errata) "IPv6 >>> Benchmarking Methodology for Network Interconnect Devices" (which mig= ht >>> not apply here) states: "The IANA has assigned 2001:0002::/48 for IPv= 6 >>> benchmarking, which is a 48-bit prefix from the RFC 4773 pool." >>> I hope this helps. >> >> To me, this is an additional reason to think that it is good to use UL= As (not 2001:s or Teredos) behind any form of NATxy. >> >> But I heard there may be good reasons to avoid ULA in NAT64. Not sure = which. >> >> Alex >> >>> >>> Best regards, >>> Marius >>> >>> >>> _______________________________________________ >>> 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 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Sun Jul 26 00:20:02 2015 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 77A301A8AB8 for ; Sun, 26 Jul 2015 00:20:01 -0700 (PDT) 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 vVW-Gt9B8eKr for ; Sun, 26 Jul 2015 00:20:00 -0700 (PDT) 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 26F0A1ACD63 for ; Sun, 26 Jul 2015 00:20:00 -0700 (PDT) Received: from [2a02:fe0:c412:1fe0::2] (port=41688 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1ZJGDv-0007fO-TD; Sun, 26 Jul 2015 09:19:51 +0200 Date: Sun, 26 Jul 2015 09:19:51 +0200 From: Tore Anderson To: "Fred Baker (fred)" Message-ID: <20150726091951.5ddc8e0c@envy.fud.no> In-Reply-To: References: <03B11480-F2E2-4B66-B7A2-1E4824E63D06@cisco.com> <20150726083028.02d6038d@envy.fud.no> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "draft-ietf-v6ops-siit-dc@tools.ietf.org" , v6ops list Subject: Re: [v6ops] Comment on siit-dc 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, 26 Jul 2015 07:20:01 -0000 * Fred Baker (fred) > > On Jul 26, 2015, at 8:30 AM, Tore Anderson wrote: > >=20 > > This document describes the use of the Stateless IP/ICMP Translation > > (SIIT) algorithm in an IPv6 Internet Data Centre (IDC). In this > > deployment model, traffic from legacy IPv4-only clients on the > > Internet is translated to IPv6 when reaches the IDC operator's >=20 > "when it reaches", or "upon reaching" Ack > > network infrastructure. From that point on, it is treated just as if > > it was traffic from any other IPv6-capable end user. The IPv6 >=20 > Just a thought: s/is treated just as if it was/is indistinguishable from/ Hmm. You actually can distinguish between the two if you want to, because the IPv4 address space will be mapped into a specific prefix (such as 64:ff9b::/96). Being able to make this distinction is necessary in order to allow the IPv6 application to perform tasks like IPv4 geolocation. On the other hand, this makes me realise that the current "it is" is probably too absolute as well. So let me try to rewrite that sentence from scratch: =C2=ABFrom that point on, it may be treated the same as traffic from native IPv6 end users.=C2=BB How does that read to you? Any better suggestions? Tore From nobody Sun Jul 26 00:32:49 2015 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 2C33F1ACE43 for ; Sun, 26 Jul 2015 00:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.622 X-Spam-Level: X-Spam-Status: No, score=0.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, 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 dF6oT930iKHX for ; Sun, 26 Jul 2015 00:32:46 -0700 (PDT) Received: from mailrelay21.naist.jp (mailrelay21.naist.jp [163.221.80.71]) by ietfa.amsl.com (Postfix) with ESMTP id 85C941ACE3F for ; Sun, 26 Jul 2015 00:32:46 -0700 (PDT) Received: from mailpost21.naist.jp (mailscan21.naist.jp [163.221.80.58]) by mailrelay21.naist.jp (Postfix) with ESMTP id 5A7A2E87; Sun, 26 Jul 2015 16:32:45 +0900 (JST) Received: from [192.168.11.4] (dn158-103.naist.jp [163.221.158.103]) by mailpost21.naist.jp (Postfix) with ESMTP id 32C31E86; Sun, 26 Jul 2015 16:32:45 +0900 (JST) Date: Sun, 26 Jul 2015 16:31:39 +0900 From: "liviumarius-g@is.naist.jp" To: Brian E Carpenter , v6ops@ietf.org MIME-Version: 1.0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Message-Id: <20150726073245.32C31E86@mailpost21.naist.jp> X-TM-AS-MML: No X-TM-AS-Product-Ver: IMSS-7.1.0.1392-8.0.0.1202-21704.006 X-TM-AS-Result: No--13.575-5.0-31-10 X-imss-scan-details: No--13.575-5.0-31-10 X-TMASE-MatchedRID: hj0BWi2U9K6PvrMjLFD6eB5+URxv1WlBWDesRNOOJ5QhvFjBsLEZNBW6 RnOXKwYNpEYBIO560crrrT4Oq9+KU1AYTUvaG0RwNNHZMWDTEbeCp3onNpm5s247M5sxfdoIPXW oMDYf5eyNYj4eFZ0CMmvqBxyQ76hAzCK25xPd0Tvf8GJjBXCUiIyzstdwoG+PEd+K6O5Nt52htO hWlgAXQnJvSGHXGUHXqf0ePlFlHo39k2nJXxNdGsYwoG0ouPR1kPqe52Sp8B0wplGJ7NxS02vW3 ypDGkmJLE+O91REvP+qMu8szpbuD5O7ij3TaTVLqbg9uWhLYLdBldmDYjwlpoDNW+VSeNngImSk gxYdxsL3aCtTBCBhl3k48PxckV+kQv21zJNl0CyDGx/OQ1GV8mh075/uY7FHeeFAQHoVNZJvFzy vAB/ijgF/RiJ3CqY9WSaAsrH85CD7T6JXagWVcIYyY+DIa67oDThyqUdku00mIx22SpMzpQ== Archived-At: Subject: Re: [v6ops] IANA assigned prefix for IPv6 benchmarking 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, 26 Jul 2015 07:32:48 -0000 PGJyPlRoYXQgaXMgYSBmYWlyIHBvaW50LiBIb3dldmVyLCBJIGd1ZXNzIHRoZSBhdXRob3JzIG1h ZGUgdGhlIG5vdGUgdG8gYXZvaWQgdGhlIHBvc3NpYmlsaXR5IChob3dldmVyIGltcHJvYmFibGUp IG9mIGFueSBjb25mbGljdCB3aXRoIG9wZXJhdGlvbmFsIHRyYWZmaWMuIDxicj48YnI+TWFyaXVz PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2IGNsYXNzPSJxdW90ZSIgc3R5 bGU9ImxpbmUtaGVpZ2h0OiAxLjUiPjxicj48YnI+LS0tLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAt LS0tLS0tLTxicj5TdWJqZWN0OiBSZTogW3Y2b3BzXSBJQU5BIGFzc2lnbmVkIHByZWZpeCBmb3Ig SVB2NiBiZW5jaG1hcmtpbmc8YnI+RnJvbTogQnJpYW4gRSBDYXJwZW50ZXIgPGJyaWFuLmUuY2Fy cGVudGVyQGdtYWlsLmNvbT48YnI+VG86IHY2b3BzQGlldGYub3JnPGJyPkNDOiA8YnI+PGJyPjxi ciB0eXBlPSJhdHRyaWJ1dGlvbiI+PGJsb2NrcXVvdGUgY2xhc3M9InF1b3RlIiBzdHlsZT0ibWFy Z2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFl eCI+T24gMjUvMDcvMjAxNSAyMjozNywgR0VPUkdFU0NVIExJVklVIE1BUklVUyB3cm90ZTo8YnI+ Jmd0OyBJZiByZXNwZWN0aW5nIHRoZSByZWNvbW1lbmRhdGlvbnMgb2YgUkZDNTE4MCBpcyBkZXNp cmVkIEkgdGhpbmsgdGhlIGZvbGxvd2luZyBub3RlIGluIFJGQzUxODAgaXMgcmVsZXZhbnQ6PGJy PiZndDsgPGJyPiZndDsgIiBOb3RlOiBTaW1pbGFyIHRvIFJGQyAyNTQ0KGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmMyNTQ0KSBhdm9pZGluZyB0aGUgdXNlIG9mIFJGQyAxOTE4KGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMxOTE4KSBhZGRyZXNzIHNwYWNlPGJyPiZndDsgIGZv ciBiZW5jaG1hcmtpbmcgdGVzdHMsIHRoaXMgZG9jdW1lbnQgZG9lcyBub3QgcmVjb21tZW5kIHRo ZSB1c2Ugb2YgUkZDIDQxOTMoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQxOTMpIFs0 KGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1MTgwI3JlZi00KV0gKFVuaXF1ZSBMb2Nh bCBBZGRyZXNzZXMpIGluIG9yZGVyIHRvIG1pbmltaXplIHRoZSA8YnI+Jmd0OyAgcG9zc2liaWxp dHkgb2YgY29uZmxpY3RzIHdpdGggb3BlcmF0aW9uYWwgdHJhZmZpYy4iPGJyPiZndDsgPGJyPiZn dDsgd2hpY2ggaW4gbXkgdW5kZXJzdGFuZGluZyBkb2VzIG5vdCByZWNvbW1lbmQgdGhlIHVzZSBv ZiBVTEEgcy48YnI+PGJyPk5vLCBidXQgaXQncyBhIHN0cmFuZ2UgYXJndW1lbnQgcHJlY2lzZWx5 IGJlY2F1c2UgVUxBcyBhcmUgVW5pcXVlIHdpdGggdmVyeSBoaWdoPGJyPnByb2JhYmlsaXR5LCBz byBjb25mbGljdCB3aXRoIG9wZXJhdGlvbmFsIHRyYWZmaWMgaXMgdmVyeSBpbXByb2JhYmxlLjxi cj48YnI+ICAgIEJyaWFuPGJyPjxicj4mZ3Q7IDxicj4mZ3Q7IEJlc3QgcmVnYXJkcyw8YnI+Jmd0 OyBNYXJpdXMgPGJyPiZndDsgPGJyPiZndDsgT24gMDcvMjQvMTUsIEFsZXhhbmRydSBQZXRyZXNj dSAgPGFsZXhhbmRydS5wZXRyZXNjdUBnbWFpbC5jb20+IHdyb3RlOjxicj4mZ3Q7Jmd0Ozxicj4m Z3Q7Jmd0Ozxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBMZSAyNC8wNy8yMDE1IDExOjE2LCBHRU9S R0VTQ1UgTElWSVUgTUFSSVVTIGEgw6ljcml0IDo8YnI+Jmd0OyZndDsmZ3Q7IEhlbGxvIHY2b3Bz LDxicj4mZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7IFJlbGF0ZWQgdG8gdGhlIHF1ZXN0aW9u IHRoYXQgY2FtZSB1cCBpbiBTdHVhcnQgQ2hlc2hpcmUncyBwcmVzZW50YXRpb248YnI+Jmd0OyZn dDsmZ3Q7IGFib3V0IHRoZSBwcmVmaXggdXNlZCBmb3IgYmVuY2htYXJraW5nLCBSRkM1MTgwKHdp dGggZXJyYXRhKSAiSVB2Njxicj4mZ3Q7Jmd0OyZndDsgQmVuY2htYXJraW5nIE1ldGhvZG9sb2d5 IGZvciBOZXR3b3JrIEludGVyY29ubmVjdCBEZXZpY2VzIiAod2hpY2ggbWlnaHQ8YnI+Jmd0OyZn dDsmZ3Q7IG5vdCBhcHBseSBoZXJlKSBzdGF0ZXM6ICJUaGUgSUFOQSBoYXMgYXNzaWduZWQgMjAw MTowMDAyOjovNDggZm9yIElQdjY8YnI+Jmd0OyZndDsmZ3Q7IGJlbmNobWFya2luZywgd2hpY2gg aXMgYSA0OC1iaXQgcHJlZml4IGZyb20gdGhlIFJGQyA0NzczIHBvb2wuIjxicj4mZ3Q7Jmd0OyZn dDsgSSBob3BlIHRoaXMgaGVscHMuPGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7IFRvIG1lLCB0aGlz IGlzIGFuIGFkZGl0aW9uYWwgcmVhc29uIHRvIHRoaW5rIHRoYXQgaXQgaXMgZ29vZCB0byB1c2Ug VUxBcyAobm90IDIwMDE6cyBvciBUZXJlZG9zKSBiZWhpbmQgYW55IGZvcm0gb2YgTkFUeHkuPGJy PiZndDsmZ3Q7PGJyPiZndDsmZ3Q7IEJ1dCBJIGhlYXJkIHRoZXJlIG1heSBiZSBnb29kIHJlYXNv bnMgdG8gYXZvaWQgVUxBIGluIE5BVDY0LiBOb3Qgc3VyZSB3aGljaC48YnI+Jmd0OyZndDs8YnI+ Jmd0OyZndDsgQWxleDxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7 IEJlc3QgcmVnYXJkcyw8YnI+Jmd0OyZndDsmZ3Q7IE1hcml1czxicj4mZ3Q7Jmd0OyZndDs8YnI+ Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7Jmd0OyZndDsgdjZvcHMgbWFpbGluZyBsaXN0PGJy PiZndDsmZ3Q7Jmd0OyB2Nm9wc0BpZXRmLm9yZzxicj4mZ3Q7Jmd0OyZndDsgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wczxicj4mZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZn dDs8YnI+Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+Jmd0OyZndDsgdjZvcHMgbWFpbGluZyBsaXN0PGJyPiZndDsmZ3Q7IHY2b3BzQGll dGYub3JnPGJyPiZndDsmZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v djZvcHM8YnI+Jmd0OyZndDs8YnI+Jmd0OyA8YnI+Jmd0OyA8YnI+Jmd0OyA8YnI+Jmd0OyBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7IHY2b3Bz IG1haWxpbmcgbGlzdDxicj4mZ3Q7IHY2b3BzQGlldGYub3JnPGJyPiZndDsgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wczxicj4mZ3Q7IDxicj48YnI+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+djZvcHMgbWFpbGluZyBs aXN0PGJyPnY2b3BzQGlldGYub3JnPGJyPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdjZvcHM8YnI+PC9hbGV4YW5kcnUucGV0cmVzY3VAZ21haWwuY29tPjwvYmxvY2txdW90 ZT48L2JyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbT48L2Rpdj48L2JvZHk+PC9odG1sPg== From nobody Sun Jul 26 05:08:58 2015 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 E68CF1A0094 for ; Sun, 26 Jul 2015 05:08:55 -0700 (PDT) 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 uJ8DbpqC3vrb for ; Sun, 26 Jul 2015 05:08:55 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 419D11A0091 for ; Sun, 26 Jul 2015 05:08:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 9985247; Sun, 26 Jul 2015 14:08:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:content-transfer-encoding:date :date:in-reply-to:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=mail; t= 1437912531; bh=xJGSMelsSZuZx0REw3V/4KXf+Kywos3l0nhVCMpGclo=; b=e XvrNRUZCD4ewZ8J+pnR80XxVE1hQPMKh33SF5jLHebjopnSDB/u3FemmkWSggiCt L1UrHi83bQN5cOVSqlGUp/WWaQTdVzhMH47SgDiLGhTuOQM5IqYRlilrtSDNMy5b RDEm1bOKtWS775L5+MmD0Z0Q5cl3G2e9jFsTmM1IEk= 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 JcDCTmL2xxV5; Sun, 26 Jul 2015 14:08:51 +0200 (CEST) Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTPSA id D270740; Sun, 26 Jul 2015 14:08:50 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann In-Reply-To: <20150726091951.5ddc8e0c@envy.fud.no> Date: Sun, 26 Jul 2015 14:08:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9E6ECE3B-99F2-4BAE-9438-3167F97317DF@steffann.nl> References: <03B11480-F2E2-4B66-B7A2-1E4824E63D06@cisco.com> <20150726083028.02d6038d@envy.fud.no> <20150726091951.5ddc8e0c@envy.fud.no> To: Tore Anderson X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "draft-ietf-v6ops-siit-dc@tools.ietf.org" , v6ops list Subject: Re: [v6ops] Comment on siit-dc 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, 26 Jul 2015 12:08:56 -0000 Hi, > =C2=AB=46rom that point on, it may be treated the same as traffic from = native > IPv6 end users.=C2=BB >=20 > How does that read to you? Any better suggestions? That looks good. Sander From nobody Sun Jul 26 09:22:59 2015 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 126C81B2B97 for ; Sun, 26 Jul 2015 09:22:57 -0700 (PDT) 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 17jgeqJWKHNw for ; Sun, 26 Jul 2015 09:22:56 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450: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 A1CEA1B2B99 for ; Sun, 26 Jul 2015 09:22:55 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so82849595wib.0 for ; Sun, 26 Jul 2015 09:22:54 -0700 (PDT) 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=RLW6jvaYt6bEVx0LfES+WR0vEXx8RMxOD6ANHbKE2lM=; b=k3wKiTAPX/bcxEgshPnguvRfKxFQIB1YUTuWbMgTiRqY77SwXHt9kf7I8axzpFFVG0 vEfbnoI1E2EYGsdWZLXLVuLv9894Mm8wp3OmbM87wl/Uie/7Xb6IXz93elu0qJDZ5nVq 41aAnpjLuNJI/b0ymYjB8A3rF6K8nJV2J1mVaYU58h02FFRCdqjUcB505wf6AokR3ufX y9tCmRNpWIDGpGNxXZNoEYHLzjy/nRNwaPc5UY40PQhpsdYlfYtREh2pnDN2GSubSoak K9tNlwX59ELoVWOqHFpOnG0ylkYVcjUINRKRlsgm1CsAxH0c+VrfeLL7gNpFp01ohLXq 0f4g== 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=RLW6jvaYt6bEVx0LfES+WR0vEXx8RMxOD6ANHbKE2lM=; b=QW13qpBaxa8aM5c8dNPnrKWRaxOtDilV4BBXYzi32RO+UZ+gl2iI6f1stwRsDJj3PU Q6pNpKqRPj5JGGJdZs53BNAqxNIV/0nle4cT6A4xT4EtcEnXqCnDJh11WdhifdxrbSFM tJHpNRoyCHgr/Biu0V3eF2A41Vbk6JsLpazGRlLmloJpgRwKt84zRNgfqOKsqLi7DZsC QEnR3jvF/C7yo7c8hivi2wIlry5dYjmv4nxYiLtYOBirhfaZakxds2On3lY/DnlB6eD9 kZ8O2Sm53658/zips6kROytlpVvF5PS2tA3xL7TUu32arI67iYe7xZH3AECqb7n3uRZ6 lBPA== X-Gm-Message-State: ALoCoQnIbgqceBUQCZxaZ0Ac0/p6+jO0sUTk4Q9BPnf3tEMIHURyaAo9EAsOJ0pOa/T6didoYgn6 X-Received: by 10.194.78.210 with SMTP id d18mr45015441wjx.34.1437927774183; Sun, 26 Jul 2015 09:22:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.138.203 with HTTP; Sun, 26 Jul 2015 09:22:34 -0700 (PDT) In-Reply-To: <55B48402.1040202@gmail.com> References: <6b60e612c4f0.55b20091@naist.jp> <6c008406e2af.55b200cf@naist.jp> <6c00eec89ab8.55b2010d@naist.jp> <6bf095d99dae.55b2014a@naist.jp> <6b50ff96a9ad.55b20188@naist.jp> <6c50a92cde54.55b201c6@naist.jp> <6c50be138e83.55b20205@naist.jp> <6bf08db1e13f.55b20243@naist.jp> <6bf0f7dbdadf.55b20280@naist.jp> <6bf0898ffbd5.55b21ea8@naist.jp> <55B29026.1070906@gmail.com> <6b70d3cfd2f6.55b365ea@naist.jp> <6b70bfbf8107.55b36628@naist.jp> <6c30a2fefa4c.55b36666@naist.jp> <6c50d867e570.55b366a4@naist.jp> <6bf0c04ef47e.55b382fb@naist.jp> <55B48402.1040202@gmail.com> From: Erik Kline Date: Sun, 26 Jul 2015 18:22:34 +0200 Message-ID: To: Brian E Carpenter , Stuart Cheshire , David Schinazi Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] IANA assigned prefix for IPv6 benchmarking 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, 26 Jul 2015 16:22:57 -0000 On 26 July 2015 at 08:53, Brian E Carpenter wrote: > On 25/07/2015 22:37, GEORGESCU LIVIU MARIUS wrote: >> If respecting the recommendations of RFC5180 is desired I think the following note in RFC5180 is relevant: >> >> " Note: Similar to RFC 2544(https://tools.ietf.org/html/rfc2544) avoiding the use of RFC 1918(https://tools.ietf.org/html/rfc1918) address space >> for benchmarking tests, this document does not recommend the use of RFC 4193(https://tools.ietf.org/html/rfc4193) [4(https://tools.ietf.org/html/rfc5180#ref-4)] (Unique Local Addresses) in order to minimize the >> possibility of conflicts with operational traffic." >> >> which in my understanding does not recommend the use of ULA s. > > No, but it's a strange argument precisely because ULAs are Unique with very high > probability, so conflict with operational traffic is very improbable. Regardless of ULA or some other space, I think a useful property for the GUA(-like) prefix used by Apple's NAT64 test network would be randomness. If, for instance, *every time a NAT64 test network was started* a new random ULA was generated or, say, 2001:2:0:$RAND16::/64 were used, then developers would be less likely to accidentally make assumptions about the consistency of addresses. From nobody Sun Jul 26 11:00:08 2015 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 D424A1ACCEB for ; Sun, 26 Jul 2015 11:00:05 -0700 (PDT) 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 mCj0yNB6jeuT for ; Sun, 26 Jul 2015 11:00:04 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A1461ACCE9 for ; Sun, 26 Jul 2015 11:00:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=621; q=dns/txt; s=iport; t=1437933604; x=1439143204; h=date:from:message-id:to:subject:cc; bh=at5mvFdp1XWogylfruDmkJ2JVsklG9Xr7Ny2unTVSGQ=; b=MljJXAGYpfT4N/vq1Dl+3y3cT69ygYsu3v+Yn6X8DaKWAxLX4E1bnkUs /xNLLQ16JesT4ydGZtguugXnMAEHo8pv5EbSdU8IDFdB7OHPbG/botls3 Tg6iP3Wt1bwLFoMtC9MPR6V7jjSIoFv55979dAu7YvZJvsdc+9cpB71q1 A=; X-IronPort-AV: E=Sophos;i="5.15,547,1432598400"; d="scan'208";a="18887611" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-2.cisco.com with ESMTP; 26 Jul 2015 18:00:04 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t6QI0386012348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Jul 2015 18:00:03 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 t6QI0204030368; Sun, 26 Jul 2015 11:00:02 -0700 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id t6QI012w030367; Sun, 26 Jul 2015 11:00:01 -0700 Date: Sun, 26 Jul 2015 11:00:01 -0700 From: fred@cisco.com Message-Id: <201507261800.t6QI012w030367@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Subject: [v6ops] draft-ietf-v6ops-siit-dc WGLC 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, 26 Jul 2015 18:00:06 -0000 This is to initiate a two week working group last call of http://tools.ietf.org/html/draft-ietf-v6ops-siit-dc. Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list. We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make. From nobody Sun Jul 26 16:38:45 2015 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 493D71A873D for ; Sun, 26 Jul 2015 16:38:43 -0700 (PDT) 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 JESHNPcDik1C for ; Sun, 26 Jul 2015 16:38:41 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95D221A8737 for ; Sun, 26 Jul 2015 16:38:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3338; q=dns/txt; s=iport; t=1437953921; x=1439163521; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=JO+0qm5xveo+1FnTkoPerBKnMqu6LSgAYhD0xOHME6g=; b=GZ8qyKT6QF7FJqVctI0fdVa4AvyPrUEqqVFffysvo0R+Ev4r5IjCAeGt jAmm+kClfyU0KTwV0PI96vZtmj/M0+vHYqGqhgK2cre94zCCmMKT0/JZI A+81bgWOlomzEdRJ70d8SrRwBcFD9sSGiEWhFtPSVeJyPS8/G2CpDwdPl 0=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AcAwD3brVV/4ENJK1bgxWBPQa8AQmHcAKBMDgUAQEBAQEBAYEKhCMBAQEDAXkFCwIBCBguMiUCBA4FDogYCM8sAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tOhQcHgxiBFAWRbIJ9AYI3gVeIMoFFhy+QMiaDfW+BSIEEAQEB X-IronPort-AV: E=Sophos;i="5.15,549,1432598400"; d="asc'?scan'208";a="15185495" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-6.cisco.com with ESMTP; 26 Jul 2015 23:38:40 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t6QNcelO011450 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 26 Jul 2015 23:38:40 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.49]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Sun, 26 Jul 2015 18:38:40 -0500 From: "Fred Baker (fred)" To: Tore Anderson Thread-Topic: [v6ops] Comment on siit-dc Thread-Index: AQHQx/wyMsio78/kLUSjknlteMZmQQ== Date: Sun, 26 Jul 2015 23:38:39 +0000 Message-ID: <87CE0FBD-11C4-4C09-9899-21D96CDA7F3E@cisco.com> References: <03B11480-F2E2-4B66-B7A2-1E4824E63D06@cisco.com> <20150726083028.02d6038d@envy.fud.no> In-Reply-To: <20150726083028.02d6038d@envy.fud.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.24.138.48] Content-Type: multipart/signed; boundary="Apple-Mail=_8D8644A2-485A-403A-B15F-871BB37CCFD1"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-v6ops-siit-dc@tools.ietf.org" , v6ops list Subject: Re: [v6ops] Comment on siit-dc 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, 26 Jul 2015 23:38:43 -0000 --Apple-Mail=_8D8644A2-485A-403A-B15F-871BB37CCFD1 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii works for me. > On Jul 25, 2015, at 11:30 PM, Tore Anderson wrote: > > * Fred Baker (fred) > >> The abstract reads: >> >> This document describes the use of the Stateless IP/ICMP Translation >> (SIIT) algorithm in an IPv6 Internet Data Centre (IDC). In this >> deployment model, traffic from legacy IPv4-only clients on the >> Internet is translated to IPv6 when reaches the IDC operator's >> network infrastructure. From that point on, it is treated just as if >> it was traffic from any other IPv6-capable end user. This >> facilitates a single-stack IPv6-only network infrastructure, as well >> as efficient utilisation of public IPv4 addresses. >> >> The primary audience is IDC operators who are deploying IPv6, running >> out of available IPv4 addresses, and/or feel that dual stack causes >> undesirable operational complexity. >> >> I see what you're saying, but can read it as specifying how an RFC >> 6052 address might be used, when you're specifying the use of >> siit-eam. May I suggest tweaking the abstract to clarify that? > > Point taken. How about: > > This document describes the use of the Stateless IP/ICMP Translation > (SIIT) algorithm in an IPv6 Internet Data Centre (IDC). In this > deployment model, traffic from legacy IPv4-only clients on the > Internet is translated to IPv6 when reaches the IDC operator's > network infrastructure. From that point on, it is treated just as if > it was traffic from any other IPv6-capable end user. The IPv6 > endpoints may be numbered using arbitrary (non-IPv4-translatable) > IPv6 addresses. This facilitates a single-stack IPv6-only network > infrastructure, as well as efficient utilisation of public IPv4 > addresses. > > The primary audience is IDC operators who are deploying IPv6, > running out of available IPv4 addresses, and/or feel that dual > stack causes undesirable operational complexity. > > ...? > > Tore --Apple-Mail=_8D8644A2-485A-403A-B15F-871BB37CCFD1 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 iQIVAwUBVbVvf0ayAOS/EQ8MAQKX2w//cD9P6nuwdUyryGOIN+DOvp1naNzyoWfC eg5JCgG2fc5/jnKopqHorIPxmLbzN2mWplLi9YQde6r+ElsyHyNZWMDNMaZaclcI mtMjZ/yBcP/2zwihuqerh5hY0KrDHCeUeRlc0kVqEVdGWjodSPC+NnvRIua4dnHz jzcI8V98ytKyQ9TlCUuFIXWO3npQfz0CCipj1LlRbIJSFiNXh4ujUd1ItnrexqMn tTeZBWKSsDepc/OgDagvNcGTazegN70eHSx9pSBEBOS6ySDQUWO5coPdy3mB1sCP JXdF8aUopnnpdwARL7VwPA6KM+07OJVLu7uIonHhwSijXVpuRPv93jdTWuGmCRSk AGJpSHGrHaz0x8rR3s6HsmIM6xjVnLHtVRhCTLpgwWnn8hw17/7rgixUTUKbF8PE R+yPzt8QedhXGU4C02CP7ZfRjSKRChSe0yE7d4ps+vUaIQNoQaE1MOgHHiTfDTAp bLiICLostZInkFsp7LvqJSaGWPL4IFoECaYEo80/fHXODlkHkBsCvrBn3xY5nK2q iyZ/UMEprjIxb0z8R/HergC4tKcUSmpBzqSBXV+tSBVJQuu2xvAe1K0F9XnW76e3 pUdOkrBXje7zmzeR04ISPWAULdnYd6GJ4u78ueEGxlBdA6diqyvec0VLM0LSWZEd GrsoQn7wAXI= =RAbH -----END PGP SIGNATURE----- --Apple-Mail=_8D8644A2-485A-403A-B15F-871BB37CCFD1-- From nobody Sun Jul 26 19:11:47 2015 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 5EEA21A0158 for ; Sun, 26 Jul 2015 19:11:46 -0700 (PDT) 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 R-JZZlu2sBoe for ; Sun, 26 Jul 2015 19:11:45 -0700 (PDT) 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 1B31F1A010E for ; Sun, 26 Jul 2015 19:11:45 -0700 (PDT) Received: by ykax123 with SMTP id x123so58899493yka.1 for ; Sun, 26 Jul 2015 19:11:44 -0700 (PDT) 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=cD1Nyovubhd2hWGnEIc6sS0pvQVisBbmXdzVGaXcomQ=; b=F+qpqQPU6tVRBgm10TX7kOvn/+b7uWpE8MI9rviWZj0oF88WzoOzF672hjYprB5cwP 3WT3II4S2sKPtCoeDy6VAAU26HdiGj+crDFKbJd3LLREj915HDlbRq9r1eUyiJytvBRh VLZH880/sJj+z0Svlop53TS206bFIW9VYKRJ/DURWmNYonAQGitw4dGilw8TINZgJoT6 lXmVf5pp/Y9p2/P687J2qbKr5ljRyqYJDuKRxHI4bjycMpYU5fwIysu0Zuz6kq8B24Fe s1DYsj4Tcv+nLQWYh1s9dce804ve5QLXnSk3HBKiRlsPvKmcce/dEhdgsSt0IBCm0zck Cghg== 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=cD1Nyovubhd2hWGnEIc6sS0pvQVisBbmXdzVGaXcomQ=; b=KeJlSgBsdePYQPA793GoJAXuMrgYFcvqAlpkbFp8IPGX7NyH3uHJRTBy1kQQmyCGA8 zuNR9TaabHBiKjUkt4WgEb6uVRkco296RJrik+Lq/4sCwoR+ifUlgQscHd288MM2PPM/ LqxU450gQNLR6YeWlBAgA18+272z69OSNHWvjZxlkscZukhe9Xcaba7Vh09KeNGhcrPD ENE/eSoR4IB0WhBtXxjCjDcuzG2tV+ymms8ok0MYXclxkO9ws0hggaRl+aOFXeV9tG+1 9xI/D39G+7l1bvz5yDu4a3UiIhPsjjH+uce62eGvu+dckBQkJty0VMWeLcNrKDEG3bl/ Py8Q== X-Gm-Message-State: ALoCoQmeBsyfyE2BJ6Meoar8AjIqz+ImLPNQTb6FHPX5CzTIos/4/Cv/cccZSA+wJXpsHaVJ71j+ X-Received: by 10.170.91.3 with SMTP id i3mr27429508yka.25.1437963104321; Sun, 26 Jul 2015 19:11:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.8.201 with HTTP; Sun, 26 Jul 2015 19:11:24 -0700 (PDT) In-Reply-To: References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> <55B1ED14.6030501@gmail.com> From: Lorenzo Colitti Date: Mon, 27 Jul 2015 11:11:24 +0900 Message-ID: To: Philip Homburg Content-Type: multipart/alternative; boundary=001a113a05e80910ec051bd1e0a8 Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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: Mon, 27 Jul 2015 02:11:46 -0000 --001a113a05e80910ec051bd1e0a8 Content-Type: text/plain; charset=UTF-8 In practice, in a homenet network it will make sense to use SLAAC instead of DHCPv6 PD. The recommendation for PD is to use DHCPv6 PD if a network "requires explicit requests for address space", i.e., if SLAAC is not available. On Fri, Jul 24, 2015 at 6:15 PM, Philip Homburg wrote: > Random question: how you doing DHCP PD interact with Homenet's HNCP? > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a113a05e80910ec051bd1e0a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In practice, in a homenet network it will make sense to us= e SLAAC instead of DHCPv6 PD. The recommendation for PD is to use DHCPv6 PD= if a network "requires explicit requests for address space", i.e= ., if SLAAC is not available.

On Fri, Jul 24, 2015 at 6:15 PM, Philip Homburg <pch-= v6ops-3@u-1.phicoh.com> wrote:
Random question: how you doing DHCP PD interact with Homenet's HNCP= ?


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

--001a113a05e80910ec051bd1e0a8-- From nobody Sun Jul 26 22:14:10 2015 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 80E811A8969 for ; Sun, 26 Jul 2015 22:14:09 -0700 (PDT) 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, 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 EAxkZBu9I45E for ; Sun, 26 Jul 2015 22:14:06 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::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 F0F921A8963 for ; Sun, 26 Jul 2015 22:14:05 -0700 (PDT) Received: by iggf3 with SMTP id f3so62354203igg.1 for ; Sun, 26 Jul 2015 22:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=pj0+xqwpxGBkOykR4ZhMJufV36uY3AWjGj0DZIGpgYM=; b=rI873vB3gGl6u6OhoeW3AI/7M511fK5Poda62BuQYz0N5pNqd5CY2joNsoXU22BhEZ GolUHo5h0VEMBpjewd4cfkWSEKphnnP28ZqLrvM+YfxSnzNS5QFvjznf6EsKJjEcvpYC 79FLx7d29RBpgIgDtsXPLLwm+gIFgNUOnQwApodW8ZrqC26JXq5XCHU4RiL38TjNzZkr bSOkcfUsn90zMeV3cS+QTPRREqm+LkGQl9qn4z7CSk2oaD09U8PduS1UEDveVd2AYmhz u/LVfmyfsGwcQPdZ7FYdcOOSyIxaaeGJvf7dtx/1DEnZ9vLPTiLCQhicGOTqNE2gbjzX HrIQ== X-Received: by 10.50.72.102 with SMTP id c6mr13723712igv.31.1437974045450; Sun, 26 Jul 2015 22:14:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.169.143 with HTTP; Sun, 26 Jul 2015 22:13:35 -0700 (PDT) In-Reply-To: <55B115A6.5040607@acm.org> References: <201507071147.t67Bl13m009348@irp-lnx1.cisco.com> <85CADAA2-8DF2-4A6B-812B-7A77081936F5@cisco.com> <228248C6-94FE-4C9C-A875-F732EFDC6601@cisco.com> <55B0177F.8050703@acm.org> <55B115A6.5040607@acm.org> From: Mark Smith Date: Mon, 27 Jul 2015 15:13:35 +1000 Message-ID: To: Erik Nordmark Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: v6ops list , "draft-yc-v6ops-solicited-ra-unicast@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast 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, 27 Jul 2015 05:14:09 -0000 Hi Erik, On 24 July 2015 at 02:26, Erik Nordmark wrote: > On 7/23/15 2:37 AM, Mark Smith wrote: >> >>> If not, then the implementation needs to multicast the RA. >>> >> I was wondering if instead the implementation could trigger an ND/NS >> transaction for the RS source address at that point, and then unicast >> the RA when that completes. > > That would only address the lack of SLLAO case; not the unspecified source > address case. True. I think the only option to unicast responses for unspecified source address cases would be link-layer unicast option. > I don't know how common these cases are in existing implementations. > The unspecified source would appear if the host is doing DAD in parallel > with sending the RS. I did some capturing/research related to this draft, Windows XP was issuing unspecified source RSes at boot, then using link-local sourced RSes, although the later versions of Windows I looked at didn't. > I don't know when a host would omit the SLLAO in the RS. > I think it would be fairly common at the moment. The Linux user interface oriented Network Manager utility (https://wiki.gnome.org/Projects/NetworkManager), used by at least Fedora, is sending RSes without the SLLAO, as it uses the libndp.org library, which only seems to currently support building a minimal generic RS without the SLLAO option, and there doesn't seem to be an obvious library call to add an SLLAO to the generic RS. >> > > I think there is text earlier to say to not create an NCE for 0::0 nor if > there is no SLLAO (unless the link-layer has no addresses). > I've done some more searching of RFC4861, and haven't seemed to find anything that specifically prohibits creating an NCE via a ND/NS transaction for a RS without an SLLAO. Thinking about it more, triggering an ND/NS to resolve the source address of the RS if there is no SLLAO may not be all that beneficial, as it effectively substitutes a multicast ND for a multicast RA. There might be some other benefits from having router(s) having proactively resolve a host's link-local RS source address that make trading a multicast RA for a multicast ND worth while. Regards, Mark. > Regards, > Erik > >> >> Performing an NS/ND to resolve the source address of the RS without a >> SLLO would seem consistent with the corresponding RS SLLO handling - >> to load the Neighbor Cache with entries for nodes that have sent RSes. >> >> >> Regards, >> Mark. >> >>> Erik >>> >>>> https://www.ietf.org/mail-archive/web/v6ops/current/msg22464.html >>>> >>>> >>>> >>>> >>>> https://www.ietf.org/mail-archive/web/v6ops/current/msg22464.html >>>> >>>>> But I would not say it's sufficient, if only from an "explicit >>>>> clarity" standpoint. I think explicit mention of RAs and the other >>>>> discussion is helpful for implementors not inclined to dig to great >>>>> depths or just seeking explicit confirmation. >>>>> >>>> >>>> >>>>> _______________________________________________ >>>>> 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 Mon Jul 27 01:26:09 2015 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 7D3E91AD0B0 for ; Mon, 27 Jul 2015 01:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.6 X-Spam-Level: X-Spam-Status: No, score=-4.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 SG2I0wMr00JU for ; Mon, 27 Jul 2015 01:26:06 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 68C8F1ACEF0 for ; Mon, 27 Jul 2015 01:26:06 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1ZJdjZ-0000CcC; Mon, 27 Jul 2015 10:26:05 +0200 Message-Id: To: IPv6 Operations From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> <55B1ED14.6030501@gmail.com> In-reply-to: Your message of "Mon, 27 Jul 2015 11:11:24 +0900 ." Date: Mon, 27 Jul 2015 10:26:05 +0200 Archived-At: Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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: Mon, 27 Jul 2015 08:26:08 -0000 In your letter dated Mon, 27 Jul 2015 11:11:24 +0900 you wrote: >In practice, in a homenet network it will make sense to use SLAAC instead >of DHCPv6 PD. The recommendation for PD is to use DHCPv6 PD if a network >"requires explicit requests for address space", i.e., if SLAAC is not >available. I didn't keep track, did homenet explictly pick SLAAC over DHCPv6? From nobody Mon Jul 27 01:28:42 2015 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 EFEFB1AD0BB for ; Mon, 27 Jul 2015 01:28:40 -0700 (PDT) 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 bxZwW5GjNbhR for ; Mon, 27 Jul 2015 01:28:39 -0700 (PDT) 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 846521A9055 for ; Mon, 27 Jul 2015 01:28:39 -0700 (PDT) Received: by ykay190 with SMTP id y190so63337977yka.3 for ; Mon, 27 Jul 2015 01:28:39 -0700 (PDT) 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=TpShaq3/3BxqWNRd7/wRSHwjC2WF7XXptk/DRzqZSu8=; b=OyyMpkRZchnkFlvnEjqosPbXusR5F4Ep60O7757y252sMK1xTU10LZGFIxNKwx0o3y 1Yw9Jh9RcyF06RzhJ/E1QdNOyvh8eL3tOqSUcPLSc0nKu/x1cOiV6jWxyrf1tqXN4Fb0 VKEnwtU8Dioe2wIfYqoIhzzO5BhDE366vZrRStj/oJ74JqjKkqvc5go+BTHwJw48/xy4 +cWBFOKgEMhv7g4NTSw+jVzxAz7MqQtDmrdxRymWphtU1GE1tPLBysIWiXDcvt2T6Us3 7DnrbB4Rbr3qYRQL13uzD3EV3su8l09CEDtgfAEAWucWmNrunFhZy4PcD/zUGrzumuVZ nZrw== 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=TpShaq3/3BxqWNRd7/wRSHwjC2WF7XXptk/DRzqZSu8=; b=jMRXU8E2VvXNKVYnoNtNwHu2nmkDdM7MD62ocl1e/DVNv3du5Oo6DmkGfIfFUZFVMQ wTn6z8+QuiLpYKeitjTzXYWE1CWd+Syv24i+9PD9GbhchdRiM1WGhpr15l5l4nWWvKuN vDr3fiksHAPMqJ5nvlUAdTfu0HyC/Sbbyo6iVDOtCp+ugWccpUDFwavQeY7fpCFrwAYU k1AzO9CWoj5jICAA3iRl6PJOj5fEn33KVfSUsQBG3NN57RKWpMpokRCAP+Hj2n8ZbZwT JDH7OA35ApOTKDeYJsq/JSxVcr+xrJIjXEYh5cVIIbtGPr1usGnVURWAchI2+AkXP8e5 z12w== X-Gm-Message-State: ALoCoQldZ+5bhogZhk7dQd5kj7aSg5nQXgR6nKBmpULsQ78rZiffTRwEALdcCyGOcAVEiI9lxOQJ X-Received: by 10.129.77.213 with SMTP id a204mr29696314ywb.40.1437985718829; Mon, 27 Jul 2015 01:28:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.8.201 with HTTP; Mon, 27 Jul 2015 01:28:19 -0700 (PDT) In-Reply-To: References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> <55B1ED14.6030501@gmail.com> From: Lorenzo Colitti Date: Mon, 27 Jul 2015 17:28:19 +0900 Message-ID: To: Philip Homburg Content-Type: multipart/alternative; boundary=001a1140c552f6f0fc051bd723c2 Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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: Mon, 27 Jul 2015 08:28:41 -0000 --001a1140c552f6f0fc051bd723c2 Content-Type: text/plain; charset=UTF-8 On Mon, Jul 27, 2015 at 5:26 PM, Philip Homburg wrote: > >In practice, in a homenet network it will make sense to use SLAAC instead > >of DHCPv6 PD. The recommendation for PD is to use DHCPv6 PD if a network > >"requires explicit requests for address space", i.e., if SLAAC is not > >available. > > I didn't keep track, did homenet explictly pick SLAAC over DHCPv6? I don't think the architecture specifies anything. That said, because homenet is dynamic and many hosts don't support RECONFIGURE, using stateful DHCPv6 in the home is likely a bad idea because it will break things when renumbering. --001a1140c552f6f0fc051bd723c2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jul 27, 2015 at 5:26 PM, Philip Homburg <pch-v6ops-3@u-1.ph= icoh.com> wrote:
>In practice, in a homenet network it will make sense to use SL= AAC instead
>of DHCPv6 PD. The recommendation for PD is to use DHCPv6 PD if a networ= k
>"requires explicit requests for address space", i.e., if SLAA= C is not
>available.

I didn't keep track, did homenet explictly pick SLAAC over DHCPv= 6?

I don't think the architecture speci= fies anything. That said, because homenet is dynamic and many hosts don'= ;t support RECONFIGURE, using stateful DHCPv6 in the home is likely a bad i= dea because it will break things when renumbering.
--001a1140c552f6f0fc051bd723c2-- From nobody Mon Jul 27 02:12:48 2015 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 7262F1AD2F2 for ; Mon, 27 Jul 2015 02:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 BRnVpZN1gf7Y for ; Mon, 27 Jul 2015 02:12:45 -0700 (PDT) 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 72CBF1A3B9B for ; Mon, 27 Jul 2015 02:12:44 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 53DF360980 for ; Mon, 27 Jul 2015 11:12:42 +0200 (CEST) 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 02E2160678 for ; Mon, 27 Jul 2015 11:12:42 +0200 (CEST) Received: (qmail 76426 invoked by uid 1007); 27 Jul 2015 11:12:41 +0200 Date: Mon, 27 Jul 2015 11:12:41 +0200 From: Gert Doering To: Philip Homburg Message-ID: <20150727091241.GL84167@Space.Net> References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> <55B1ED14.6030501@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: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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: Mon, 27 Jul 2015 09:12:47 -0000 Hi, On Mon, Jul 27, 2015 at 10:26:05AM +0200, Philip Homburg wrote: > In your letter dated Mon, 27 Jul 2015 11:11:24 +0900 you wrote: > >In practice, in a homenet network it will make sense to use SLAAC instead > >of DHCPv6 PD. The recommendation for PD is to use DHCPv6 PD if a network > >"requires explicit requests for address space", i.e., if SLAAC is not > >available. > > I didn't keep track, did homenet explictly pick SLAAC over DHCPv6? DHCPv6 or DHCPv6-PD? You're mixing terms... For hosts, SLAAC is used, for non-homenet routers behind a homenet, DHCPv6-PD. Not sure about DHCPv6 for hosts, though. 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 Mon Jul 27 03:12:56 2015 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 5BFB81B2AC1 for ; Mon, 27 Jul 2015 03:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.6 X-Spam-Level: X-Spam-Status: No, score=-4.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 i8eQDkjZnGQd for ; Mon, 27 Jul 2015 03:12:50 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 373CE1B2AB8 for ; Mon, 27 Jul 2015 03:12:50 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1ZJfOr-0000CgC; Mon, 27 Jul 2015 12:12:49 +0200 Message-Id: To: IPv6 Operations From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> <55B1ED14.6030501@gmail.com> <20150727091241.GL84167@Space.Net> In-reply-to: Your message of "Mon, 27 Jul 2015 11:12:41 +0200 ." <20150727091241.GL84167@Space.Net> Date: Mon, 27 Jul 2015 12:12:48 +0200 Archived-At: Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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: Mon, 27 Jul 2015 10:12:52 -0000 In your letter dated Mon, 27 Jul 2015 11:12:41 +0200 you wrote: >> I didn't keep track, did homenet explictly pick SLAAC over DHCPv6? > >DHCPv6 or DHCPv6-PD? You're mixing terms... > >For hosts, SLAAC is used, for non-homenet routers behind a homenet, >DHCPv6-PD. Not sure about DHCPv6 for hosts, though. My reasoning is, you want DHCPv6-PD for hosts if hosts are doing DHCPv6 because otherwise they would have to obtain losts of DHCPv6 leases. Now if homenet has decided that there will never be DHCPv6 for hosts on homenet then this is a non-issue. If they didn't make such a decision, then we have to think how DHCPv6-PD for hosts would work in a homenet environment. From nobody Mon Jul 27 04:24:37 2015 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 91D821AD4A1 for ; Mon, 27 Jul 2015 04:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 IGh3VLTvoEUa for ; Mon, 27 Jul 2015 04:24:35 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (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 436C41A916C for ; Mon, 27 Jul 2015 04:24:35 -0700 (PDT) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 30ED3DA008A; Mon, 27 Jul 2015 11:24:35 +0000 (UTC) Received: from [10.0.20.218] (71.233.41.235) by CAS-03.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 27 Jul 2015 04:24:34 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_EB11ED2B-ADC9-462A-945D-7C04FBBB9535" MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ted Lemon In-Reply-To: Date: Mon, 27 Jul 2015 07:24:33 -0400 Message-ID: References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> <55B1ED14.6030501@gmail.com> <20150727091241.GL84167@Space.Net> To: Philip Homburg X-Mailer: Apple Mail (2.2102) X-Originating-IP: [71.233.41.235] Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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: Mon, 27 Jul 2015 11:24:36 -0000 --Apple-Mail=_EB11ED2B-ADC9-462A-945D-7C04FBBB9535 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Jul 27, 2015, at 6:12 AM, Philip Homburg = wrote: > My reasoning is, you want DHCPv6-PD for hosts if hosts are doing = DHCPv6 because > otherwise they would have to obtain losts of DHCPv6 leases. You don=E2=80=99t want them to obtain lots of DHCPv6 leases. Why would = that be a good idea? I would suggest ten as an upper limit, and = that=E2=80=99s easily addressed with IA_NA. IA_PD would be overkill, = and hosts don=E2=80=99t support it anyway. --Apple-Mail=_EB11ED2B-ADC9-462A-945D-7C04FBBB9535 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" On Jul 27, 2015, at 6:12 AM, Philip Homburg <pch-v6ops-3@u-1.phicoh.com> wrote:
My reasoning is, you want DHCPv6-PD for hosts if = hosts are doing DHCPv6 because
otherwise they would have to obtain losts of = DHCPv6 leases.

You don=E2=80=99t want them to obtain lots of DHCPv6 leases. =   Why would that be a good idea?   I would suggest ten as an = upper limit, and that=E2=80=99s easily addressed with IA_NA.   = IA_PD would be overkill, and hosts don=E2=80=99t support it = anyway.

= --Apple-Mail=_EB11ED2B-ADC9-462A-945D-7C04FBBB9535-- From nobody Mon Jul 27 05:28:23 2015 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 10F1E1B2C69 for ; Mon, 27 Jul 2015 05:28:22 -0700 (PDT) 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 b8hAsWwT3df2 for ; Mon, 27 Jul 2015 05:28:21 -0700 (PDT) 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 11C4A1B2C65 for ; Mon, 27 Jul 2015 05:28:21 -0700 (PDT) Received: by ykay190 with SMTP id y190so67239244yka.3 for ; Mon, 27 Jul 2015 05:28:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mtH/4aeXICm0z70r5dEOw65azBNWAxiA7gfEcesxQzI=; b=OtKySLkA3ykkxIZ0BnRrRQB907BZWgXPlhcN9xmk0p2FCwfnbCDG+QC7n1oWAInBK6 e6dYbfdC7It2HqhEQ0cUjao+zr/R50XBK7v4X0fyPx/kQaO/Efvdsn2lZnSGbIuNinvW jgyhcE1gU8Q/G2vOaQpqe1KJTi3b90m33FqQjz7eeQu6rvP4OtjuwzD+eVrXhBls5Zbk yFjIXi2EkyezKPQznQAbXzGLUyBCq7VtaaD3Y3VzoTX2wfjNa9nlEE9xT+1WyzgeIyHv yzLbk3LBx2R3Vib7xwxNQ15yG8sjP/2vu1oyj09+aaHnhIwtwZ1t7/0c0SaCSfeM7tLF nt4Q== 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=mtH/4aeXICm0z70r5dEOw65azBNWAxiA7gfEcesxQzI=; b=cCLYDtcdotSrUAVZ75wQ10mdmltWJq+9PVGPpf3VPsFhLkcRaYR8CvtGnQFIzOqguf 67T0PaRtm4SQUArPBQ4BzU5dVyFrCZxq5AkQNIE9dJDbqSvMSqYMalLEAdBvEQAu16Fk Wx16jS4SzVtCGv1MSJOn4cGbmIXdJ/rtqaWkaDtydVU83h4EqUpj/rFCu+CrmMmNxKbn Xj8aqal8XyKTypi2nQ9cvyHsI7NZmaonk4Euo/xA9uaVEOBgJoahg4zwW93AwzrPadGo uQzAGzQSeJhx1IoAhoMgdEyaa0/24VJz1YIiJWYK8oALIVDOOPRCYomz9rkyHEWdILV4 zYDg== X-Gm-Message-State: ALoCoQm56J/mwAWQVgFla4F7MDOKrh7FYPib72s3By/qFqn1EBRfsaSHHdoNMXEnDOs+GfAjC2cw MIME-Version: 1.0 X-Received: by 10.129.75.214 with SMTP id y205mr30978673ywa.65.1438000100380; Mon, 27 Jul 2015 05:28:20 -0700 (PDT) Received: by 10.37.8.201 with HTTP; Mon, 27 Jul 2015 05:28:20 -0700 (PDT) Received: by 10.37.8.201 with HTTP; Mon, 27 Jul 2015 05:28:20 -0700 (PDT) In-Reply-To: References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> <55B1ED14.6030501@gmail.com> <20150727091241.GL84167@Space.Net> Date: Mon, 27 Jul 2015 21:28:20 +0900 Message-ID: From: Lorenzo Colitti To: Ted Lemon Content-Type: multipart/alternative; boundary=001a113f3d0a2bfacb051bda7d53 Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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: Mon, 27 Jul 2015 12:28:22 -0000 --001a113f3d0a2bfacb051bda7d53 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Jul 27, 2015 20:24, "Ted Lemon" wrote: > > You don=E2=80=99t want them to obtain lots of DHCPv6 leases. Why would = that be a good idea? I would suggest ten as an upper limit, and that=E2=80=99s ea= sily addressed with IA_NA. IA_PD would be overkill, and hosts don=E2=80=99t su= pport it anyway. Ted, please read the draft :-) --001a113f3d0a2bfacb051bda7d53 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Jul 27, 2015 20:24, "Ted Lemon" <ted.lemon@nominum.com> wrote:
>
> You don=E2=80=99t want them to obtain lots of DHCPv6 leases. =C2=A0 Wh= y would that be a good idea? =C2=A0 I would suggest ten as an upper limit, = and that=E2=80=99s easily addressed with IA_NA. =C2=A0 IA_PD would be overk= ill, and hosts don=E2=80=99t support it anyway.

Ted, please read the draft :-)

--001a113f3d0a2bfacb051bda7d53-- From nobody Mon Jul 27 05:32:12 2015 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 0CB361A1AA8 for ; Mon, 27 Jul 2015 05:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 Y7rWYrO8_9sX for ; Mon, 27 Jul 2015 05:32:09 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (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 9994C1B2B81 for ; Mon, 27 Jul 2015 05:32:09 -0700 (PDT) Received: from webmail.nominum.com (cas-04.win.nominum.com [64.89.235.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 4682FDA008B; Mon, 27 Jul 2015 12:32:09 +0000 (UTC) Received: from [10.0.20.218] (71.233.41.235) by CAS-04.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 27 Jul 2015 05:32:08 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_2189E030-2831-41BD-A062-3BBF3B1B5D54" MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ted Lemon In-Reply-To: Date: Mon, 27 Jul 2015 08:32:07 -0400 Message-ID: <1E86B21D-23A8-4BC3-91CF-1F050B6BAC6F@nominum.com> References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> <55B1ED14.6030501@gmail.com> <20150727091241.GL84167@Space.Net> To: Lorenzo Colitti X-Mailer: Apple Mail (2.2102) X-Originating-IP: [71.233.41.235] Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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: Mon, 27 Jul 2015 12:32:11 -0000 --Apple-Mail=_2189E030-2831-41BD-A062-3BBF3B1B5D54 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" On Jul 27, 2015, at 8:28 AM, Lorenzo Colitti wrote: > Ted, please read the draft :-) Fair point. :) --Apple-Mail=_2189E030-2831-41BD-A062-3BBF3B1B5D54 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="us-ascii" On Jul 27, 2015, at 8:28 AM, Lorenzo Colitti <lorenzo@google.com> wrote:
Ted, please read the draft :-)

Fair point. :)

--Apple-Mail=_2189E030-2831-41BD-A062-3BBF3B1B5D54-- From nobody Mon Jul 27 06:25:29 2015 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 DF48A1B2D37 for ; Mon, 27 Jul 2015 06:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v_69IUMo0gCv for ; Mon, 27 Jul 2015 06:25:20 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001: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 3A9A11B2D36 for ; Mon, 27 Jul 2015 06:25:20 -0700 (PDT) Received: by igbpg9 with SMTP id pg9so91504139igb.0 for ; Mon, 27 Jul 2015 06:25:19 -0700 (PDT) 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:content-transfer-encoding; bh=GVo2Sz8dOkISbtw09TkRpCkn9QdTsy8Xis8v1bnudJ0=; b=ew5f+iD9H1/p2gYSHDs3QyjSiNffVyaQIVC+tgWF9S+qJ5UORWeXskmEqVB8BJXnPD UgZG0ZiT//iuQMqqqButE45Aw0kSySS5imyTnKVQZQj22fxP0HvLVEY/N0Oe5y3Ihd2E 4sm/xBhmq6QaHdCA0P5EWK469R7l4EQbVVHWXS6rKgcOpaCjkBOf2Dr77P+JWNNhp0bY yGsl3FwVfGUnzdyS+qdxAmJLLpAdW/w2K3AVemqgqnLCV3eUTIKBCdl7s/uCH5y1fRqt ZT/qO+6mg8JGIXJfF2NOiRmnIUcTF7J88FUgbhgTCJPZley0yCwhpLO+B3nWh0lFqPoB dlVQ== MIME-Version: 1.0 X-Received: by 10.107.137.154 with SMTP id t26mr42619758ioi.13.1438003519440; Mon, 27 Jul 2015 06:25:19 -0700 (PDT) Received: by 10.107.143.20 with HTTP; Mon, 27 Jul 2015 06:25:18 -0700 (PDT) In-Reply-To: References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> <55B1ED14.6030501@gmail.com> <20150727091241.GL84167@Space.Net> Date: Mon, 27 Jul 2015 15:25:18 +0200 Message-ID: From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= To: Ted Lemon Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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: Mon, 27 Jul 2015 13:25:23 -0000 On 7/27/15, Ted Lemon wrote: > On Jul 27, 2015, at 6:12 AM, Philip Homburg > wrote: >> My reasoning is, you want DHCPv6-PD for hosts if hosts are doing DHCPv6 >> because >> otherwise they would have to obtain losts of DHCPv6 leases. > > You don=E2=80=99t want them to obtain lots of DHCPv6 leases. Why would = that be a > good idea? I would suggest ten as an upper limit, and that=E2=80=99s ea= sily > addressed with IA_NA. > IA_PD would be overkill, and hosts don=E2=80=99t support it > anyway. > The disjoint nature of IA_NA means a corresponding number of TCAM entries is required on L3 switches. A prefix, on the other hand, requires just an entry for the link-local of the host + an entry for the prefix. Regardless of the prefix length. Thus: the scaling properties on the network hardware side are vastly differ= ent. Also, the draft talks about twenty addresses being needed. --a From nobody Mon Jul 27 06:57:50 2015 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 9F1011B2DD4 for ; Mon, 27 Jul 2015 06:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.925 X-Spam-Level: ** X-Spam-Status: No, score=2.925 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 uAEjOIYJb-xf for ; Mon, 27 Jul 2015 06:57:47 -0700 (PDT) Received: from cdcipgw02.twcable.com (cdcipgw02.twcable.com [165.237.91.111]) by ietfa.amsl.com (Postfix) with ESMTP id C621E1B2DD2 for ; Mon, 27 Jul 2015 06:57:46 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.15,554,1432612800"; d="scan'208";a="290719316" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdcipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 27 Jul 2015 09:36:06 -0400 Received: from PRVPEXVS10.corp.twcable.com ([10.136.163.41]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Mon, 27 Jul 2015 09:57:45 -0400 From: "George, Wes" To: Mark Smith Date: Mon, 27 Jul 2015 09:57:43 -0400 Thread-Topic: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability Thread-Index: AdDIdDZdq0uthLAMSeG10ygJ/vZ6/g== Message-ID: References: <201507061147.t66Bl1AE028312@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.3.150624 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" , "draft-colitti-v6ops-host-addr-availability@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability 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, 27 Jul 2015 13:57:48 -0000 T24gNy8yNS8xNSwgMTE6MjUgUE0sICJNYXJrIFNtaXRoIiA8bWFya3p6enNtaXRoQGdtYWlsLmNv bT4gd3JvdGU6DQoNCg0KPk9uIDI2IEp1bHkgMjAxNSBhdCAxMToyMSwgR2VvcmdlLCBXZXMgPHdl c2xleS5nZW9yZ2VAdHdjYWJsZS5jb20+IHdyb3RlOg0KPj5XaGF0IHRoZXkndmUgc2FpZCBpcyB0 aGF0IHRoZXkgcmVxdWlyZSBhIHdheSB0byB0cmFjayB3aGljaCBJUHY2DQo+PmFkZHJlc3Nlcw0K Pj4gYXJlIGFzc2lnbmVkIHRvIHdoaWNoIGhvc3RzIGZvciBwb2xpY3kgYW5kIGxlZ2FsIHJlYXNv bnMNCj4NCj5TbyB3aGF0IEknZCBsaWtlIHRvIGtub3cgbW9yZSBhYm91dCB0aGVuIGlzIHRoZSBw YXJ0aWN1bGFyIHByb2JsZW0NCj5iZWluZyB0cnlpbmcgdG8gYmUgc29sdmVkLCBvciBtb3JlIHNw ZWNpZmljYWxseSB0aGUgYnVzaW5lc3MgcHJvYmxlbQ0KPm9yIHByb2JsZW1zIGJlaW5nIHNvbHZl ZC4NCj4iSGF2aW5nIGEgcmVjb3JkIG9mIElQIGFkZHJlc3NlcyBhc3NpZ25lZCB0byBkZXZpY2Vz IiBpc24ndCBhIHByb2JsZW0NCj5zdGF0ZW1lbnQsIGl0IGlzIGEgc3RhdGVtZW50IG9mIHdoYXQg YSBtZWNoYW5pc20gc3VjaCBhcyBESENQIGlzDQo+dGhlb3JldGljYWxseSBhY2hpZXZlcy4gVGhh dCByZWNvcmQgbmVlZHMgdG8gYmUgdXNlZCBmb3Igc29tZXRoaW5nLCBzbw0KPndoYXQgYXJlIHRo b3NlIHVzZXM/DQpXR10gV2UgZGlzYWdyZWUgb24gd2hldGhlciBJRVRGIG5lZWRzIHRvIGtub3cg d2hhdCBhIGdpdmVuIGltcGxlbWVudGF0aW9uDQppbnRlbmRzIHRvIGRvIHdpdGggdGhlIGRhdGEg aW4gb3JkZXIgZm9yIHRoZSBwcm9ibGVtIHN0YXRlbWVudCB0byBiZQ0KY29tcGxldGUuDQoNCj4N Cj5JIGFzc3VtZSBpdCBpcyB0byBzYXRpc2Z5IGEgc2VjdXJpdHkgbmVlZC4gQnV0IHdoYXQgYXJl IHRoZSBzcGVjaWZpYw0KPnNlY3VyaXR5IG5lZWRzPyBJcyB0aGVyZSBhbnl0aGluZyBmb3JtYWwg dGhhdCByZXF1aXJlcyBpdCwgZS5nLiwgUENJDQo+RFNTPw0KV0ddIFdlbGwsIEkgdGhvdWdodCB0 aGF0IHRoZSBzZWNvbmQgcGFydCBvZiB0aGUgc3RhdGVtZW50IGFib3ZlIHdhcyBwcmV0dHkNCnNl bGYtZXhwbGFuYXRvcnksIGJ1dCBzaW5jZSB5b3UgYXNrZWQgZm9yIG1vcmUgZGV0YWlsLCBoZXJl IGFyZSBhIGZldw0KZXhhbXBsZXM6DQoNCkVuZm9yY2luZy9SZXNwb25kaW5nIHRvIHZpb2xhdGlv bnMgb2YgQVVQIChzcGFtLCBtYWx3YXJlLCBhdHRhY2tzLA0KcHJvaGliaXRlZCBjb250ZW50LCBl dGMpDQpDb21wbHlpbmcgd2l0aCBMRUEgcmVxdWVzdHMgKENBTEVBIG9yIGVxdWl2YWxlbnQsIExh d2Z1bCBJbnRlcmNlcHQsIGV0YyksDQpETUNBIG9yIGVxdWl2YWxlbnQgdGFrZWRvd24gcmVxdWVz dHMNClNhbmRib3hpbmcgZGV2aWNlcy91c2VycyB0aGF0IGRvIG5vdCBoYXZlIHBlcm1pc3Npb24g dG8gdXNlIHRoZSBuZXR3b3JrDQpkdWUgdG8gbm9ucGF5bWVudCBvciBvbmUgb2YgdGhlIGFib3Zl IHZpb2xhdGlvbnMNCkVuYWJsaW5nIGRpZmZlcmVudCB0aWVycyBvZiBzZXJ2aWNlIGJ5IGRldmlj ZSBvciBieSB1c2VyLCBkZWFsaW5nIHdpdGgNCmVudGl0bGVtZW50IHRvIGEgZ2l2ZW4gc2Vydmlj ZQ0KDQo+VGhlIElFVEYgY2FuIGNvbWUgdXAgd2l0aCBhIHByb3BlciBzb2x1dGlvbiBzdGF0ZW1l bnQgb25jZSBhIHByb3Blcg0KPnByb2JsZW0gc3RhdGVtZW50IGV4aXN0cy4gRG9lcyBhIHByb3Bl ciBwcm9ibGVtIHN0YXRlbWVudCBleGlzdA0KPnNvbWV3aGVyZT8NCldHXSB0aGUgcHJvYmxlbSB3 aXRoIHRoZSAicHJvcGVyIiBwcm9ibGVtIHN0YXRlbWVudCB5b3UncmUgYXNraW5nIGZvciBpcw0K dGhhdCBJIGRvbid0IHRoaW5rIHRoZSBJRVRGIHJlYWxseSB3YW50cyB0byBrbm93IHRoZSBhbnN3 ZXIgYmVjYXVzZSBvZiB0aGUNCnZlcnkgY29tcGxleCBpc3N1ZXMgaXQgd2lsbCByYWlzZS4gSWYg dGhlIGV4cGxhbmF0aW9uIGdldHMgbXVjaCBtb3JlDQpkZXRhaWxlZCB0aGFuICJJIGhhdmUgbXVs dGlwbGUgbGVnYWwgYW5kIHBvbGljeSBlbmZvcmNlbWVudCBtYW5kYXRlcyB0aGF0DQpyZXF1aXJl IG1lIHRvIGhhdmUgYSB3YXkgdG8gbWFwIGFuIElQIGFkZHJlc3MvZGV2aWNlIG9uIHRoZSBuZXR3 b3JrIHRvIHRoZQ0KdXNlciB0aGF0IGlzIHNlbmRpbmcvcmVjZWl2aW5nIG9uIGl0IiB5b3Ugc3Rh cnQgZ2V0dGluZyBpbnRvIGEgY29tYmluYXRpb24NCm9mIGxlZ2FsIGFuZCBwb2xpY3kgYXJlYXMg dGhhdCB0aGUgSUVURiB0eXBpY2FsbHkgc3RheXMgYXdheSBmcm9tLiBBcmUgd2UNCndpbGxpbmcg dG8gbWFrZSB0b29scyBhdmFpbGFibGUgZm9yIGdvdmVybm1lbnQgYWdlbmNpZXMgYW5kIGJ1c2lu ZXNzZXMgdG8NCmRvIHRoaW5ncyB0aGF0IHNvbWUgb2Ygb3VyIHBhcnRpY2lwYW50cyBhcmUgb3Bw b3NlZCB0bz8gSG93IGZhciBhcmUgd2UNCndpbGxpbmcgdG8gZ28gaW50byBpbXBsZW1lbnRhdGlv biBkZXRhaWxzIHRoYXQgaW52b2x2ZSBtdWx0aXBsZQ0KanVyaXNkaWN0aW9ucyBhbmQgcmVnaW9u cyB3aXRoIGNvbmZsaWN0aW5nIHZpZXdzIGFib3V0IHdoYXQgaXMgbGVnYWwsDQppbGxlZ2FsLCBh bmQgY29tcHVsc29yeT8gSXQgZ2V0cyBkaWZmaWN1bHQgdG8gb3B0aW1pemUgYSBzb2x1dGlvbiBh cm91bmQNCnRoYXQgcHJvYmxlbSBzcGFjZSwgZXNwZWNpYWxseSB0byBkbyBpdCBvYmplY3RpdmVs eSwgdW5sZXNzIHlvdSBhYnN0cmFjdA0KaXQgdG8gYSBmYWlybHkgaGlnaCBsZXZlbC4NClRoZSBk aXNjdXNzaW9uIGFsc28gdGVuZHMgdG8gZGV2b2x2ZSBxdWlja2x5IGludG8gYmxhbWluZyB0aGUg bWVzc2VuZ2VyLA0KaW4gd2hpY2ggcGVvcGxlIGdldCBhbmdyeSBvciBkaXNtaXNzaXZlIHRvIHRo ZSBvcGVyYXRvcnMgc2F5aW5nIHRoYXQgdGhleQ0KbmVlZCBjZXJ0YWluIGZ1bmN0aW9uYWxpdHks IGJlY2F1c2UgdGhleSBhcmUgYmVpbmcgcmVxdWlyZWQgYnkgdGhlaXIgbG9jYWwNCmdvdmVybm1l bnQgb3IgZW1wbG95ZXIgdG8gZG8gc29tZXRoaW5nIHNvbWUgY29uc2lkZXIgZGlzdGFzdGVmdWwg d2l0aCBpdCwNCmFuZCB0aGUgb3BlcmF0b3JzIHJlc3BvbmQgYnkgZ2V0dGluZyBhbmdyeSBhdCAi SUVURiIgZm9yIHRlbGxpbmcgdGhlbSB0aGF0DQp0aGUgdGhpbmcgdGhhdCB0aGV5J3JlIGxlZ2Fs bHkgcmVxdWlyZWQgdG8gZG8gaXNuJ3QgaW1wb3J0YW50IG9yIG5lY2Vzc2FyeQ0Kb3IgaXMgb3Ro ZXJ3aXNlICJ3cm9uZyIuIEknZCByYXRoZXIgc3RheSBhd2F5IGZyb20gdGhhdCBkZWJhdGUgaGVy ZSwgYnV0DQppZiB5b3Ugd291bGQgbGlrZSB0byBraWNrIHRoZSBob3JuZXRzJyBuZXN0IG9uIE5B Tk9HIGFnYWluIHRvIHNhdGlzZnkgeW91cg0Kb3duIGN1cmlvc2l0eSwgYmUgbXkgZ3Vlc3QuDQoN ClRoZSBvbmx5IHRoaW5nIEkgYWdyZWUgbWlnaHQgYmUgdW5jbGVhciBpbiBteSBnZW5lcmljIHBy b2JsZW0gc3RhdGVtZW50DQphYm92ZSBpcyB3aGF0IGxldmVsIG9mIGFjY3VyYWN5IG9yIGNvbmZp ZGVuY2UgaW4gdGhlIG1hcHBpbmcgYmV0d2VlbiBJUCwNCnVzZXIsIGFuZCBkZXZpY2UgaXMgbmVj ZXNzYXJ5LCBhbmQgYXQgd2hhdCB0aW1lIHJlc29sdXRpb24uIEluIHRoaXMgY2FzZSwNCkkgdGhp bmsgd2UgY2FuIHBvaW50IHRvIHRoZSBzeXN0ZW1zIGluIHBsYWNlIHRvZGF5IChlLmcuIERIQ1B2 NCkgYW5kIHNheQ0KdGhhdCBpdCdzIGxhcmdlbHkgYmVzdC1lZmZvcnQsIHdpdGggdGltZSBhY2N1 cmFjeSBvbiB0aGUgb3JkZXIgb2Ygc2Vjb25kcw0Kb3IgbWludXRlcywgYW5kIGlmIHNvbWV0aGlu ZyBiZXR0ZXIgdGhhbiB0aGF0IGlzIHJlcXVpcmVkLCBpdCBwcm9iYWJseQ0KcmVxdWlyZXMgaW1w bGVtZW50YXRpb24gb2YgYWRkaXRpb25hbCBzZWN1cml0eSBpbiBhZGRyZXNzIGFzc2lnbm1lbnQN CihTRU5ELCBldGMpLg0KDQpXZXMgR2VvcmdlDQoNCkFueXRoaW5nIGJlbG93IHRoaXMgbGluZSBo YXMgYmVlbiBhZGRlZCBieSBteSBjb21wYW554oCZcyBtYWlsIHNlcnZlciwgSQ0KaGF2ZSBubyBj b250cm9sIG92ZXIgaXQuDQotLS0tLS0tLS0tLQ0KDQoNClRoaXMgRS1tYWlsIGFuZCBhbnkgb2Yg aXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENhYmxlIHByb3ByaWV0YXJ5 IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1Ympl Y3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1h aWwgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVu dGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRl ZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQg YW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2Vu IGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBF LW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBh bnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0K From nobody Mon Jul 27 08:13:15 2015 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 DD8B71B2E6A for ; Mon, 27 Jul 2015 08:13:14 -0700 (PDT) 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 kC-gZe80njKY for ; Mon, 27 Jul 2015 08:13:13 -0700 (PDT) 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 792CA1B2E65 for ; Mon, 27 Jul 2015 08:13:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t6RFDE9i030512; Mon, 27 Jul 2015 08:13:14 -0700 Received: from XCH-PHX-211.sw.nos.boeing.com (xch-phx-211.sw.nos.boeing.com [130.247.25.140]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t6RFD9b2030430 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 27 Jul 2015 08:13:09 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.231]) by XCH-PHX-211.sw.nos.boeing.com ([169.254.11.215]) with mapi id 14.03.0235.001; Mon, 27 Jul 2015 08:13:07 -0700 From: "Templin, Fred L" To: "v6ops@ietf.org" Thread-Topic: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability Thread-Index: AdDIdDZdq0uthLAMSeG10ygJ/vZ6/gAButyA Date: Mon, 27 Jul 2015 15:13:06 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832ECECA5@XCH-BLV-504.nw.nos.boeing.com> References: <201507061147.t66Bl1AE028312@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: "draft-colitti-v6ops-host-addr-availability@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability 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, 27 Jul 2015 15:13:15 -0000 SGkgLSBmb3IgYSBsb25nIHRpbWUgbm93LCBBRVJPIGhhcyBiZWVuIGFkdm9jYXRpbmcgREhDUHY2 LVBEIGZvciBhc3NpZ25pbmcNCmEgLzY0IG9yIHNob3J0ZXIgdG8gYSBub2RlIHRoYXQgY2FuIGFj dCBhcyBlaXRoZXIgYSBob3N0IG9yIGEgcm91dGVyLiBJZiBhIHJvdXRlciwNCnRoZSBub2RlIGFz c2lnbnMgKHBvcnRpb25zIG9mKSB0aGUgZGVsZWdhdGVkIHByZWZpeCB0byBvbmUgb3IgbW9yZSBk b3duc3RyZWFtDQphdHRhY2hlZCBsaW5rcy4gSWYgYSBob3N0LCB0aGUgbm9kZSBhc3NpZ25zIChw b3J0aW9ucyBvZikgdGhlIGRlbGVnYXRlZCBwcmVmaXggdG8gYQ0KdmlydHVhbCBpbnRlcmZhY2Ug YW5kIGNvbmZpZ3VyZXMgYXMgbWFueSBhZGRyZXNzZXMgZnJvbSB0aGUgcHJlZml4IGFzIGl0IGxp a2VzIG9uDQp0aGUgdmlydHVhbCBpbnRlcmZhY2UuIFRoZSBub2RlIGNhbiB0aGVuIGVuYWJsZSBo b3N0IGFwcGxpY2F0aW9ucyB0aGF0IHVzZSB0aGUNCmFzc2lnbmVkIGFkZHJlc3NlcyBhY2NvcmRp bmcgdG8gdGhlIHdlYWsgZW5kIHN5c3RlbSBtb2RlbC4gSSBzdXBwb3NlIGl0IGlzDQphbHNvIHBv c3NpYmxlIGZvciB0aGUgbm9kZSB0byBhY3QgYXMgYm90aCBhIGhvc3QgYW5kIGEgcm91dGVyLCBp ZiBzdWNoIHdvdWxkDQpiZSByZXF1aXJlZCBhY2NvcmRpbmcgdG8gdGhlIHVzZSBjYXNlLg0KDQpJ IGFsc28gYWdyZWUgd2l0aCB3aGF0IEkgdGhpbmsgSSBoZWFyZCBMb3JlbnpvIHNheWluZyBhdCB0 aGUgbWlrZSwgd2hpY2ggaXMgdGhhdA0KYXNzaWduaW5nIGEgLzY0IG9yIHNob3J0ZXIgdG8gZWFj aCBub2RlIGlzIHNjYWxhYmxlIHNpbmNlIGV2ZW4gYSAvMzIgY2FuIHN1cHBvcnQNCnVwIHRvIDRC IHN1Y2ggbm9kZXMuIFRoYXQgaXMgYWxzbyBjb25zaXN0ZW50IHdpdGggd2hhdCBBRVJPIGV4cGVj dHMuDQoNCkhlcmUgaXMgYSBwb2ludGVyIHRvIHRoZSBBRVJPIGRyYWZ0Og0KDQpodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC10ZW1wbGluLWFlcm9saW5rLw0KDQpUaGFua3Mg aW4gYWR2YW5jZSBmb3IgYW55IGNvbW1lbnRzLg0KDQpGcmVkDQpmcmVkLmwudGVtcGxpbkBib2Vp bmcuY29tDQo= From nobody Mon Jul 27 11:20:40 2015 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 4F7AF1B3177 for ; Mon, 27 Jul 2015 11:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 59v_hfTGXtYV for ; Mon, 27 Jul 2015 11:20:37 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::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 17D8C1AC44E for ; Mon, 27 Jul 2015 11:20:37 -0700 (PDT) Received: by pdbnt7 with SMTP id nt7so55888056pdb.0 for ; Mon, 27 Jul 2015 11:20:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nestlabs.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=C8Cj+gzsBm534TJNfMCjkrmzdqVpQj8G3T8dGUe1gts=; b=cQF3RpvT3S7em+MjuF17bYrljlL8UhWYGwR5PTs+NER/d+BZ7M5e1Rh4TqkVRPwmZ+ 4GQhfw93XooMN3ODzu/eCClRl1MIcCD6AxoyR3zo+OIHJP4mROj9rkU00zfpnfvtFrQQ wUJRkspgyThB1I+GcYCLdF2UKL1BoBDLX3Bso= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=C8Cj+gzsBm534TJNfMCjkrmzdqVpQj8G3T8dGUe1gts=; b=I5CYy5bsMTCiY5H49Iae5DK6vsI6FRmI3I79RizkuaUoCXjh1wU/7t6zNIuS2vliTt F+4POTxn1eMKTSnLv+qeXWuKQib92CA0SmDFiXzq+jnfTqr7dumjDN4WhOBIzo6J6EYH BN48TnztBUE2plj8qOSszm+U5ZOroldDwKHK7rog5TJY1UxHkqXhPS991PFkc2qOsymA wW8PheBETFW2tM6cHNwUdxTtwDthBqhfKjetR72l/Dlw5WVWyIPJPSx6t+RP/ImrPgSl V9jgjhLWaUmJQ3GRzV1F9cw66brh2azvtIocdAeOxN70Y7/wmwkVmmVPIJZ1cb24ZeJM 6yZA== X-Gm-Message-State: ALoCoQnSN+QzDpvVRqSOw96D494f9zekGqztaDTLPPxfn8GO4YmNwwQXNhq5T+UXmRSxRrJHuYFZkdiVdf8HKLOVR3PFuOaTPdB4YeM/EC3UyaVw0Hi0+Rw0as9hvLcBxlPktvadWSCKpxRRuLB3oAL3WX6tehE0MksK1Ol36hTZTmucQZQzOCM= X-Received: by 10.70.1.102 with SMTP id 6mr70733732pdl.32.1438021236727; Mon, 27 Jul 2015 11:20:36 -0700 (PDT) Received: from ?IPv6:2620::10e7:4:8122:7821:9eb:985e? ([2620:0:10e7:4:8122:7821:9eb:985e]) by smtp.gmail.com with ESMTPSA id f4sm30681534pdc.95.2015.07.27.11.20.35 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Jul 2015 11:20:35 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: james woodyatt In-Reply-To: Date: Mon, 27 Jul 2015 20:20:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <122EB753-12C2-4F4C-B9F9-BFA154FE803A@nestlabs.com> References: <6b60e612c4f0.55b20091@naist.jp> <6c008406e2af.55b200cf@naist.jp> <6c00eec89ab8.55b2010d@naist.jp> <6bf095d99dae.55b2014a@naist.jp> <6b50ff96a9ad.55b20188@naist.jp> <6c50a92cde54.55b201c6@naist.jp> <6c50be138e83.55b20205@naist.jp> <6bf08db1e13f.55b20243@naist.jp> <6bf0f7dbdadf.55b20280@naist.jp> <6bf0898ffbd5.55b21ea8@naist.jp> <55B29026.1070906@gmail.com> <6b70d3cfd2f6.55b365ea@naist.jp> <6b70bfbf8107.55b36628@naist.jp> <6c30a2fefa4c.55b36666@naist.jp> <6c50d867e570.55b366a4@naist.jp> <6bf0c04ef47e.55b382fb@naist.jp> <55B48402.1040202@gmail.com> To: "v6ops@ietf.org" X-Mailer: Apple Mail (2.2102) Archived-At: Subject: Re: [v6ops] IANA assigned prefix for IPv6 benchmarking 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, 27 Jul 2015 18:20:38 -0000 On Jul 26, 2015, at 18:22, Erik Kline wrote: >=20 > [=E2=80=A6] > If, for instance, *every time a NAT64 test network was started* a new > random ULA was generated or, say, 2001:2:0:$RAND16::/64 were used, > then developers would be less likely to accidentally make assumptions > about the consistency of addresses. I think it would be better not to use a single constant network prefix = for the purpose Stuart described. The reason is that Stable and Opaque = IIDs with SLAAC [RFC 7217] will never change on such networks. For the = testing purpose Apple has in mind, I think it would be better to use a = /48 prefix with a subnet that can be chosen as a configuration option in = the Sharing preferences. =E2=80=94james= From nobody Mon Jul 27 11:59:09 2015 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 43C491B326E for ; Mon, 27 Jul 2015 11:59:08 -0700 (PDT) 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 ODwsf7Lxpyz3 for ; Mon, 27 Jul 2015 11:59:06 -0700 (PDT) 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 7EC8F1B326C for ; Mon, 27 Jul 2015 11:59:06 -0700 (PDT) Received: from [2a02:c0:2:1:1194:17:0:1029] (port=55397 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1ZJnc4-0006Y2-5t; Mon, 27 Jul 2015 20:59:00 +0200 Date: Mon, 27 Jul 2015 20:58:59 +0200 From: Tore Anderson To: Erik Kline Message-ID: <20150727205859.689a0df5@envy.fud.no> In-Reply-To: References: <6b60e612c4f0.55b20091@naist.jp> <6c008406e2af.55b200cf@naist.jp> <6c00eec89ab8.55b2010d@naist.jp> <6bf095d99dae.55b2014a@naist.jp> <6b50ff96a9ad.55b20188@naist.jp> <6c50a92cde54.55b201c6@naist.jp> <6c50be138e83.55b20205@naist.jp> <6bf08db1e13f.55b20243@naist.jp> <6bf0f7dbdadf.55b20280@naist.jp> <6bf0898ffbd5.55b21ea8@naist.jp> <55B29026.1070906@gmail.com> <6b70d3cfd2f6.55b365ea@naist.jp> <6b70bfbf8107.55b36628@naist.jp> <6c30a2fefa4c.55b36666@naist.jp> <6c50d867e570.55b366a4@naist.jp> <6bf0c04ef47e.55b382fb@naist.jp> <55B48402.1040202@gmail.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; 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] IANA assigned prefix for IPv6 benchmarking 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, 27 Jul 2015 18:59:08 -0000 * Erik Kline > Regardless of ULA or some other space, I think a useful property for > the GUA(-like) prefix used by Apple's NAT64 test network would be > randomness. >=20 > If, for instance, *every time a NAT64 test network was started* a new > random ULA was generated or, say, 2001:2:0:$RAND16::/64 were used, > then developers would be less likely to accidentally make assumptions > about the consistency of addresses. Same thing goes for NAT64/DNS64 translation prefix. This could be tempting for developers to hard-code as well - my gut feeling tells me that most NAT64 deployments in 3GPP networks out are using the WKP from RFC6052 (64:ff9b::/96) for their translation prefix. As I also mentioned in the WG session I think that Apple should simply obtain a GUA prefix through the registry system for this purpose (never to be advertised into the DFZ). That way they wouldn't have to squat on prefixes reserved for other purposes (like 2001:2::/48), and they would be able to document what the prefix is actually used for and link to further information in the prefix' whois entry, so people who accidentally find themselves connected to such a network has a chance to figure out what's going on. The cost would be negligible - a /48 PI costs only =E2=82=AC50/year here. Tore From nobody Tue Jul 28 04:59:50 2015 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 CF0081A89F6 for ; Tue, 28 Jul 2015 04:59:48 -0700 (PDT) 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 JWch1oXK9ADZ for ; Tue, 28 Jul 2015 04:59:46 -0700 (PDT) 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 876AF1A89F1 for ; Tue, 28 Jul 2015 04:59:46 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 6AEC560AB2 for ; Tue, 28 Jul 2015 13:59:44 +0200 (CEST) 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 2961560758 for ; Tue, 28 Jul 2015 13:59:44 +0200 (CEST) Received: (qmail 98826 invoked by uid 1007); 28 Jul 2015 13:59:44 +0200 Date: Tue, 28 Jul 2015 13:59:44 +0200 From: Gert Doering To: Andrew ???? Yourtchenko Message-ID: <20150728115944.GZ84167@Space.Net> References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> <55B1ED14.6030501@gmail.com> <20150727091241.GL84167@Space.Net> 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: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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, 28 Jul 2015 11:59:49 -0000 Hi, On Mon, Jul 27, 2015 at 03:25:18PM +0200, Andrew ???? Yourtchenko wrote: > The disjoint nature of IA_NA means a corresponding number of TCAM > entries is required on L3 switches. > > A prefix, on the other hand, requires just an entry for the link-local > of the host + an entry for the prefix. Regardless of the prefix > length. All true. But then you excercise pressure on the prefix allocation side - instead of having "one /64 for that LAN segment, which is big enough for arbitrary number of hosts" you end up with "a /52[-ish] per LAN segment to cover DHCP-PD delegation to thousands of hosts". (Say, 1000 hosts, all doing DHCP-PD and requesting a single /64, you'd need to provision at least a /54 per segment - which will increase your prefix usage enormously) Is that what you want? 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 Jul 28 05:05:31 2015 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 CE0EE1A8A0F for ; Tue, 28 Jul 2015 05:05:29 -0700 (PDT) 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 ClKHq2Q-zifX for ; Tue, 28 Jul 2015 05:05:25 -0700 (PDT) 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 8CB9D1A8A05 for ; Tue, 28 Jul 2015 05:05:25 -0700 (PDT) Received: by ykfw194 with SMTP id w194so93276965ykf.0 for ; Tue, 28 Jul 2015 05:05:24 -0700 (PDT) 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=JqGfPWBQRoCbBB3gz+hSY7SxACmDn15CwC8h+KyLRNg=; b=PV6ZRwx2m2AMiSMe3nGBDhKXF7N29vI9vvVm+mnaJWjE5KIK3bGVE4CF/AuqP+4Ot+ JDOvDdnCJhCs6/pYyBmNn7heKl1H3XY9l9gD95pSkCGByasaFfKeNnaahGYbmvkt1QWz SD/ynplRdyGgyRDLZE0SRrvyEZMA7OKtR8BLalqzQrPftiCoTgjiP5iYxbvxlY6kSew5 7Re5LiyCPOEL7oDzgkYAjjUKlSRaRxb6DMapJTc3Rq85V9PnZ7AYBLOSRHwql8GAG7Sc AoDD8Uz/UsoBDPNCebNNHU4+9XLsr2f4D/G4JFrIzPM5fJs2q7Q5TVdoGfAt06kFRDN9 IO9w== 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=JqGfPWBQRoCbBB3gz+hSY7SxACmDn15CwC8h+KyLRNg=; b=mvjfjSxTK9z/hnkOJ9yhgb41SHLq1nbETXwCgQivE6nAdcHewBk4mNG3HY1h2Oy1ha eSAdcku9BK+ozrhOTwJPCdUQOxvyTa/MVJhCzUmPr55qFaDEqlTDiX0qtDgSeeH6gTC1 Pk/ieTiA4vDoJX6jcOx1FIcFCH5wmAQk/XcTwyckXGwDHP2ZgpskKfgHf3KhI+rTsmFV GsI6Z4LIXAqAmG2PRhvKVupgXqayHY3VuyHdAmnlxcDbGKlObUL5QZ4cmKC7ZucSfxXE YWc5KMUd6JQO7Or+v4E1dhbd79cbf0mOFenDYswLJUladNaB3bVI9tdy6/2qu4WkYTX6 l+Xw== X-Gm-Message-State: ALoCoQk2jtpa7anliLc9EgpoqUKPeW4EQZnry3qCMz7PP3WBNsdScAylkY3sH6cH8THWMfyPyPH9 X-Received: by 10.170.119.85 with SMTP id l82mr36820241ykb.89.1438085124812; Tue, 28 Jul 2015 05:05:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.8.201 with HTTP; Tue, 28 Jul 2015 05:05:05 -0700 (PDT) In-Reply-To: <20150728115944.GZ84167@Space.Net> References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> <55B1ED14.6030501@gmail.com> <20150727091241.GL84167@Space.Net> <20150728115944.GZ84167@Space.Net> From: Lorenzo Colitti Date: Tue, 28 Jul 2015 21:05:05 +0900 Message-ID: To: Gert Doering Content-Type: multipart/alternative; boundary=001a113908ec05d029051bee4916 Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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, 28 Jul 2015 12:05:30 -0000 --001a113908ec05d029051bee4916 Content-Type: text/plain; charset=UTF-8 On Tue, Jul 28, 2015 at 8:59 PM, Gert Doering wrote: > (Say, 1000 hosts, all doing DHCP-PD and requesting a single /64, you'd > need to provision at least a /54 per segment - which will increase your > prefix usage enormously) > > Is that what you want? > It's almost exactly what we have today in IPv4 - see the section in the draft on address space management. That said - you don't have this problem if you use SLAAC. --001a113908ec05d029051bee4916 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 28, 2015 at 8:59 PM, Gert Doering <gert@space.net> wrot= e:
(Say, 1000 hosts, all doing DHCP-PD an= d requesting a single /64, you'd
need to provision at least a /54 per segment - which will increase your
prefix usage enormously)

Is that what you want?

It's almost = exactly what we have today in IPv4 - see the section in the draft on addres= s space management.

That said - you don't have= this problem if you use SLAAC.
--001a113908ec05d029051bee4916-- From nobody Tue Jul 28 05:11:10 2015 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 8C18D1A8A1C for ; Tue, 28 Jul 2015 05:11:09 -0700 (PDT) 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 xQoJXDn0rMOP for ; Tue, 28 Jul 2015 05:11:08 -0700 (PDT) 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 5C4421A8A17 for ; Tue, 28 Jul 2015 05:11:08 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 6C3BA609FD for ; Tue, 28 Jul 2015 14:11:06 +0200 (CEST) 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 30D3360730 for ; Tue, 28 Jul 2015 14:11:06 +0200 (CEST) Received: (qmail 99949 invoked by uid 1007); 28 Jul 2015 14:11:06 +0200 Date: Tue, 28 Jul 2015 14:11:06 +0200 From: Gert Doering To: Lorenzo Colitti Message-ID: <20150728121106.GA84167@Space.Net> References: <55B1ED14.6030501@gmail.com> <20150727091241.GL84167@Space.Net> <20150728115944.GZ84167@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2/Dpz40iF3jpiHxF" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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, 28 Jul 2015 12:11:09 -0000 --2/Dpz40iF3jpiHxF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Jul 28, 2015 at 09:05:05PM +0900, Lorenzo Colitti wrote: > On Tue, Jul 28, 2015 at 8:59 PM, Gert Doering wrote: >=20 > > (Say, 1000 hosts, all doing DHCP-PD and requesting a single /64, you'd > > need to provision at least a /54 per segment - which will increase your > > prefix usage enormously) > > > > Is that what you want? >=20 > It's almost exactly what we have today in IPv4 - see the section in the > draft on address space management. Yeah, but who wants to replicate IPv4? (Besides, it isn't :-) ) > That said - you don't have this problem if you use SLAAC. If you use SLAAC your devices do not need to store 20 ND associations? I understood Andrew that this was the reason why he thinks DHCPv6-PD scales better than getting 20 addresses by other means... 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 --2/Dpz40iF3jpiHxF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVbdxWd9WwGXkzn/FAQJWKhAAqaQpzd0+ey+122H+vEuJWo0Io7ppsL3P X1Ieu2UXqmHIIU1hIxm4yHay+OZHGNsx1F2vDXMK2mH7kVLCOrCg7ainZBdCWwwz Cyq4KRfg7kdIhsbJw6/otPlcUZ3VfLZSvMb87ZjLSMkIdtOjPyr/nLqfKK+ErJoy xD4jMuERjKxiL15eZ09NIS1rVnrAcfg15OmxtT6rUnFUl57iVq8Z6qvGPmx6LXYV jIBhXKQauAFwWn81xnptKndsZEIRBWr+a5LN5g/AgHG6d8OssPCs7AghXt3D9rrQ LosubX03QsPn+esAyEnumTe5ocKWgVOVOOhjQPorxSBdue78JKh31tq0Ir11JObC q0BnuR8aF8PbooFYl/ZvPUyGqvck2Q1n/R5kN9Xk5SaTLbRUZMzEEjMPMxuu+g/3 25VXiBPPWlO6RSFFa6640HmktXVH8M/MGohiFppyCfE5U8vXo0XiKwHjOJno0Q5b cKwVf7DqkPvzxTCuzGNj7SW/ZqEjYV1XPIkZwJBavWkT+XB9FZWhZKdYnk+XUFQr VSoY6d6OFtPWrWUpVS8n+QzszcBVed1v0W+JXpS2YA9nGuuUAjpVX8usycwD3yrs cctXzXEWbishjYSNZVKaaBwFuzFh3xIq8Hfg1ia7srLWP6ssQSQzgw8i4moAos2f qeDutYCL1yk= =XjBy -----END PGP SIGNATURE----- --2/Dpz40iF3jpiHxF-- From nobody Tue Jul 28 05:14:32 2015 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 B6EEC1A8A3E for ; Tue, 28 Jul 2015 05:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.6 X-Spam-Level: X-Spam-Status: No, score=-4.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 85whs3-JXcSW for ; Tue, 28 Jul 2015 05:14:28 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3511A8A28 for ; Tue, 28 Jul 2015 05:14:28 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1ZK3m7-0000CZC; Tue, 28 Jul 2015 14:14:27 +0200 Message-Id: To: IPv6 Operations From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> <55B1ED14.6030501@gmail.com> <20150727091241.GL84167@Space.Net> <20150728115944.GZ84167@Space.Net> In-reply-to: Your message of "Tue, 28 Jul 2015 13:59:44 +0200 ." <20150728115944.GZ84167@Space.Net> Date: Tue, 28 Jul 2015 14:14:26 +0200 Archived-At: Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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, 28 Jul 2015 12:14:30 -0000 In your letter dated Tue, 28 Jul 2015 13:59:44 +0200 you wrote: >All true. But then you excercise pressure on the prefix allocation side >- instead of having "one /64 for that LAN segment, which is big enough >for arbitrary number of hosts" you end up with "a /52[-ish] per LAN segment >to cover DHCP-PD delegation to thousands of hosts". > >(Say, 1000 hosts, all doing DHCP-PD and requesting a single /64, you'd >need to provision at least a /54 per segment - which will increase your >prefix usage enormously) > >Is that what you want? Say you can have at least 100 prefixes per /56. Then that should be enough for most home installations. Then RIRs support a /48 for end users. So it should be easy to reach 1000 devices. I assume most business ISPs can provide a /48. Maybe even PI. Beyond that, you are probably big enough to document the need for a bigger block if required. From nobody Tue Jul 28 05:15:05 2015 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 06B7A1A8A28 for ; Tue, 28 Jul 2015 05:15:03 -0700 (PDT) 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 lwbQce3PbHFM for ; Tue, 28 Jul 2015 05:15:02 -0700 (PDT) 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 1992A1A8A27 for ; Tue, 28 Jul 2015 05:14:58 -0700 (PDT) Received: by ykay190 with SMTP id y190so93227933yka.3 for ; Tue, 28 Jul 2015 05:14:57 -0700 (PDT) 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=CcOkpQuD0Ulhyhqzi7Uc5F9VE3saRjy62+g5PrQ9304=; b=lGcxQZUhPjiWuKESiHNfcWmGP362NS4NoY2s2ZuFYGmIZv8kDwDigiBdD7IBTg01XR x/6JXY4f2Ymbb3gNWHEfX+Nk+UCTBva9FisNuvtJ7ZHgpr36PCE5yHhsQIE2EkwoMFKp NIXY/GIPtMiuPyqMzNfEMfvUTwmf2UWAr7IJ9e+1mCbcJR/VySeqc22xuKzb5XdGBbzT cnvLfaEDx7iVD11bMY4hhFywDgRtGjLk7koTAMkV8IYvH0UPzDO+auB8ZevfdBj+2aRE gq7Vai+N1nPxYJy8zzSEdqBXAfSvyUJbq6Ab1mu2vBnDq8A6WIChXZKSberLA6Nuw4Dm XMIw== 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=CcOkpQuD0Ulhyhqzi7Uc5F9VE3saRjy62+g5PrQ9304=; b=jFlcj5niVbQ1gwcUAzQvqa9DLW44qGcgTtgT30tJDF3Qve8ioFtGsYcJ5FW3fkEyJ+ vOI+chv2x84phk0DK7XPpoZe9Hv+ht3ThbRaqFg/AYcwtMgHycZu79zMEEGvKgQWtQy9 mKsYH9S9tqmDMTuxf5aMbP3CYAkmmN90qcfp8ep/T2Z630Jnp8XyaJcGEqklpKZUOfZT M7Dbkz8EkypgPY1QvPJ1IQXEUZE0AdZW1ChPq7FVsSfi0judlK5PIVIGiiMTO46r35DT ohS0a09yRAZjqnlZUDswbmDtuANwQBMUhurI4n2O/2ly1B1ddivq3NXrngJymetUXXVc gz+A== X-Gm-Message-State: ALoCoQnwawYcFuOz0hzXi1oM2j7I/Ap2t3+Pl8w+YT3qsSHrvJEbv04jd9QOcIQDHJdskVbKa6l/ X-Received: by 10.13.255.2 with SMTP id p2mr35157919ywf.149.1438085697413; Tue, 28 Jul 2015 05:14:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.8.201 with HTTP; Tue, 28 Jul 2015 05:14:37 -0700 (PDT) In-Reply-To: <20150728121106.GA84167@Space.Net> References: <55B1ED14.6030501@gmail.com> <20150727091241.GL84167@Space.Net> <20150728115944.GZ84167@Space.Net> <20150728121106.GA84167@Space.Net> From: Lorenzo Colitti Date: Tue, 28 Jul 2015 21:14:37 +0900 Message-ID: To: Gert Doering Content-Type: multipart/alternative; boundary=94eb2c0888f626d0b6051bee6b8e Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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, 28 Jul 2015 12:15:03 -0000 --94eb2c0888f626d0b6051bee6b8e Content-Type: text/plain; charset=UTF-8 On Tue, Jul 28, 2015 at 9:11 PM, Gert Doering wrote: > > That said - you don't have this problem if you use SLAAC. > > If you use SLAAC your devices do not need to store 20 ND associations? > Your home CPE will likely have no problem at all storing 20 ND associations per device. > I understood Andrew that this was the reason why he thinks DHCPv6-PD > scales better than getting 20 addresses by other means... Oh, I see. Well, of course there's a tradeoff. Something does have to keep state. You can store that state in routing entries, ND cache entries, /64 prefixes, or NAT66 state tables. I would prefer not to store it in NAT66 state tables. --94eb2c0888f626d0b6051bee6b8e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 28, 2015 at 9:11 PM, Gert Doering <gert@space.net> wrot= e:
> That said - you don't h= ave this problem if you use SLAAC.

If you use SLAAC your devices do not need to store 20 ND association= s?

Your home CPE will likely have no pr= oblem at all storing 20 ND associations per device.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">I understood Andrew that this was the reason = why he thinks DHCPv6-PD
scales better than getting 20 addresses by other means...
=
Oh, I see. Well, of course there's a tradeoff. Something= does have to keep state. You can store that state in routing entries, ND c= ache entries, /64 prefixes, or NAT66 state tables. I would prefer not to st= ore it in NAT66 state tables.
--94eb2c0888f626d0b6051bee6b8e-- From nobody Tue Jul 28 05:21:55 2015 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 56FCF1A8A58 for ; Tue, 28 Jul 2015 05:21:52 -0700 (PDT) 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 i0y1KSU9oPlK for ; Tue, 28 Jul 2015 05:21:51 -0700 (PDT) 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 1164F1A8A47 for ; Tue, 28 Jul 2015 05:21:50 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 1A6DF62CA3 for ; Tue, 28 Jul 2015 14:21:49 +0200 (CEST) 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 D0E6360730 for ; Tue, 28 Jul 2015 14:21:48 +0200 (CEST) Received: (qmail 1025 invoked by uid 1007); 28 Jul 2015 14:21:48 +0200 Date: Tue, 28 Jul 2015 14:21:48 +0200 From: Gert Doering To: Lorenzo Colitti Message-ID: <20150728122148.GC84167@Space.Net> References: <20150727091241.GL84167@Space.Net> <20150728115944.GZ84167@Space.Net> <20150728121106.GA84167@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eNjIDde0W37E3OQP" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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, 28 Jul 2015 12:21:52 -0000 --eNjIDde0W37E3OQP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Jul 28, 2015 at 09:14:37PM +0900, Lorenzo Colitti wrote: > Oh, I see. Well, of course there's a tradeoff. Something does have to keep > state. You can store that state in routing entries, ND cache entries, /64 > prefixes, or NAT66 state tables. I would prefer not to store it in NAT66 > state tables. I think we're all in agreement regarding the NAT66 here. I was just wondering whether Andrew has fully thought through his suggestion and the consequences - especially when talking about "this helps scaling" and fixing that by moving the pressure elsewhere... Gert Doering -- partly speaking with my address policy hat --=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 --eNjIDde0W37E3OQP Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVbdz3N9WwGXkzn/FAQJstxAAoLyymYi3BexpzZvX8+fqWDtFNAl8g8Nm wuTO+4DPQfEMOsslCvDjzbHQL4LbY5VKWVFUWGFQF/huL0D4k5Q+5nAu94ay2Wkm 0DcDoaSOlfwk6RncrOZ2T1avF1/wIFy5AlaIML2kFe5ILR/zPHyCB0hXaPYFwkJE XoNx2JmPpozHR1vzDHt8WYykuU0fDqrFqAiZI+FtybgfIJUwJYVPAERsFrnGNnb2 E4hPt0dRO4AAViEVUaAFwDnIozUwkuO3HNwU2ObG4fuJZNDPyCxbk61X8goWDxqk Yov66Tm5NOZX6m8bmUFaPVbOlAmTCMOZbmCpttRj002nSQMndkIZzUc/nmNbMKTl 0mWk8LBkFKN23nMLVkTnQO7Txhe9NDlpZKpjU0sbPWje4E1+LmSzIY8/RpkRbXDN tnUV2YBeRENyTRLGXhq0NDCCJdlHGU/AScqeDPJMZ/jsLaQK3nBg5F/Hnoo+aYzZ UF4X2BrpFrg2wR+v7bbmR53SOsl/TKSIYZ2mTod63FS30+8Jn2h3tgeXOo6fysm5 bBY4lmsGdEG/jfT7z7e6WC5sofNRPxBd7DoVWJQEuIk/92ziwgcE8J434lQBgixs ywSUk1y7Aqv/DLka1VBlFyNwjYMgAQLnVKq6RdhKBzxYcymMCIDglFymUXLgn6t0 6xPTM45OvCA= =FrzK -----END PGP SIGNATURE----- --eNjIDde0W37E3OQP-- From nobody Tue Jul 28 05:22:34 2015 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 99FAB1A8A51 for ; Tue, 28 Jul 2015 05:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 eerd9hKnUf74 for ; Tue, 28 Jul 2015 05:22:32 -0700 (PDT) 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 582201A8A29 for ; Tue, 28 Jul 2015 05:22:32 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 09CD960758 for ; Tue, 28 Jul 2015 14:22:31 +0200 (CEST) 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 BA74460054 for ; Tue, 28 Jul 2015 14:22:30 +0200 (CEST) Received: (qmail 1374 invoked by uid 1007); 28 Jul 2015 14:22:30 +0200 Date: Tue, 28 Jul 2015 14:22:30 +0200 From: Gert Doering To: Philip Homburg Message-ID: <20150728122230.GD84167@Space.Net> References: <55B1ED14.6030501@gmail.com> <20150727091241.GL84167@Space.Net> <20150728115944.GZ84167@Space.Net> 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: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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, 28 Jul 2015 12:22:33 -0000 Hi, On Tue, Jul 28, 2015 at 02:14:26PM +0200, Philip Homburg wrote: > In your letter dated Tue, 28 Jul 2015 13:59:44 +0200 you wrote: > >All true. But then you excercise pressure on the prefix allocation side > >- instead of having "one /64 for that LAN segment, which is big enough > >for arbitrary number of hosts" you end up with "a /52[-ish] per LAN segment > >to cover DHCP-PD delegation to thousands of hosts". > > > >(Say, 1000 hosts, all doing DHCP-PD and requesting a single /64, you'd > >need to provision at least a /54 per segment - which will increase your > >prefix usage enormously) > > > >Is that what you want? > > Say you can have at least 100 prefixes per /56. Then that should be enough for > most home installations. Andrew wasn't talking about *home* installations, because homes do not have an issue with ND/CAM/... scaling. 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 Jul 28 05:48:13 2015 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 CBDAB1A8A4C for ; Tue, 28 Jul 2015 05:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.6 X-Spam-Level: X-Spam-Status: No, score=-4.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 Ji_7NC9t0MNo for ; Tue, 28 Jul 2015 05:48:10 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 8DAE51A8A9A for ; Tue, 28 Jul 2015 05:48:08 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1ZK4Ih-0000CdC; Tue, 28 Jul 2015 14:48:07 +0200 Message-Id: To: IPv6 Operations From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <55B1ED14.6030501@gmail.com> <20150727091241.GL84167@Space.Net> <20150728115944.GZ84167@Space.Net> <20150728122230.GD84167@Space.Net> In-reply-to: Your message of "Tue, 28 Jul 2015 14:22:30 +0200 ." <20150728122230.GD84167@Space.Net> Date: Tue, 28 Jul 2015 14:48:07 +0200 Archived-At: Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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, 28 Jul 2015 12:48:12 -0000 In your letter dated Tue, 28 Jul 2015 14:22:30 +0200 you wrote: >> Say you can have at least 100 prefixes per /56. Then that should be enough for >> most home installations. > >Andrew wasn't talking about *home* installations, because homes do not have >an issue with ND/CAM/... scaling. If you have more a 100 devices requesting DHCPv6-PD, then maybe it is time to get a /48? (no doubt in some markets, ISPs will make that as painful as possible). From nobody Tue Jul 28 05:50:10 2015 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 EF0771A8A9A for ; Tue, 28 Jul 2015 05:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 o6ASYss7FFdd for ; Tue, 28 Jul 2015 05:50:07 -0700 (PDT) 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 C00871A8A9D for ; Tue, 28 Jul 2015 05:50:06 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 34FBD60980 for ; Tue, 28 Jul 2015 14:50:05 +0200 (CEST) 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 F2BE760730 for ; Tue, 28 Jul 2015 14:50:04 +0200 (CEST) Received: (qmail 3793 invoked by uid 1007); 28 Jul 2015 14:50:04 +0200 Date: Tue, 28 Jul 2015 14:50:04 +0200 From: Gert Doering To: Philip Homburg Message-ID: <20150728125004.GF84167@Space.Net> References: <20150727091241.GL84167@Space.Net> <20150728115944.GZ84167@Space.Net> <20150728122230.GD84167@Space.Net> 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: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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, 28 Jul 2015 12:50:09 -0000 Hi, On Tue, Jul 28, 2015 at 02:48:07PM +0200, Philip Homburg wrote: > In your letter dated Tue, 28 Jul 2015 14:22:30 +0200 you wrote: > >> Say you can have at least 100 prefixes per /56. Then that should be enough for > >> most home installations. > > > >Andrew wasn't talking about *home* installations, because homes do not have > >an issue with ND/CAM/... scaling. > > If you have more a 100 devices requesting DHCPv6-PD, then maybe it is time to > get a /48? For each single L2 network in a large enterprise? Is that covered by RIR policies? Please do me the honour to actually *read* what I write. This is not about "home", because home does not have scaling issues of the sort Andrew was talking about. 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 Jul 28 06:44:49 2015 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 3498B1A907E for ; Tue, 28 Jul 2015 06:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.6 X-Spam-Level: X-Spam-Status: No, score=-4.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 p-6NhxfbLYIV for ; Tue, 28 Jul 2015 06:44:45 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2D41A908B for ; Tue, 28 Jul 2015 06:44:36 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1ZK5BL-0000CVC; Tue, 28 Jul 2015 15:44:35 +0200 Message-Id: To: IPv6 Operations From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <20150727091241.GL84167@Space.Net> <20150728115944.GZ84167@Space.Net> <20150728122230.GD84167@Space.Net> <20150728125004.GF84167@Space.Net> In-reply-to: Your message of "Tue, 28 Jul 2015 14:50:04 +0200 ." <20150728125004.GF84167@Space.Net> Date: Tue, 28 Jul 2015 15:44:34 +0200 Archived-At: Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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, 28 Jul 2015 13:44:48 -0000 In your letter dated Tue, 28 Jul 2015 14:50:04 +0200 you wrote: >On Tue, Jul 28, 2015 at 02:48:07PM +0200, Philip Homburg wrote: >> If you have more a 100 devices requesting DHCPv6-PD, then maybe it is time to >> get a /48? > >For each single L2 network in a large enterprise? Is that covered by RIR >policies? > >Please do me the honour to actually *read* what I write. This is not >about "home", because home does not have scaling issues of the sort Andrew >was talking about. I don't see the problem. You can get a /48 no questions asked. This is equivalent to a /16 for IPv4. You can easily reach 10000 devices without nat on IPv4 out of a /16. Why would it be different for /64s out of a /48? Of course, the more devices you want in a /48 the more careful you addressing plan has to be. But certainly for large flat structures it should be easy to achieve high density. I don't know if RIR policies allow for one /64 per device from PI. If not, then maybe somebody should submit a policy proposal. From nobody Tue Jul 28 06:58:07 2015 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 D04BD1A9168 for ; Tue, 28 Jul 2015 06:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzhakzZCTPpk for ; Tue, 28 Jul 2015 06:58:05 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001: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 CCBC51A9153 for ; Tue, 28 Jul 2015 06:58:04 -0700 (PDT) Received: by igk11 with SMTP id 11so107535819igk.1 for ; Tue, 28 Jul 2015 06:58:04 -0700 (PDT) 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=xEQWQshwJw1BEkL/DzczZnalfKpR2KyWgYQlds7nvC8=; b=GMvCkA2kKe3xgTfxs8jFBf/zryWVW29jq4fusdoHFD/uUndHlmcvCpyUzQgAFNGKlo gNz+gRmHXTvMPdEAxZ6pEXMeIbntR4ih4tlgjyC5s8Eazvi3WEzzKPALAsmaAVf5FhGb iah0MHQ3HgCLvSM5IRz9fD5xvcEsFa7+7l1I7fpscDP4LMtzwwd21v70IWS65Ep2b0ky p0zfCoIFmQg8JWkZi9EUSHqJzKnic0R1fDJmGQhNeahB2B0q0PZIfOO9FyFRSiU3v8fF 81Q/xKkO6yMnug9FU1sxXXkfVGRhMEughRTIOdfr+ec22KrHBYWltVzTNoKyVAEAai4N tRzA== MIME-Version: 1.0 X-Received: by 10.50.138.232 with SMTP id qt8mr7125231igb.21.1438091884326; Tue, 28 Jul 2015 06:58:04 -0700 (PDT) Received: by 10.107.143.20 with HTTP; Tue, 28 Jul 2015 06:58:04 -0700 (PDT) In-Reply-To: <20150728115944.GZ84167@Space.Net> References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> <55B1ED14.6030501@gmail.com> <20150727091241.GL84167@Space.Net> <20150728115944.GZ84167@Space.Net> Date: Tue, 28 Jul 2015 15:58:04 +0200 Message-ID: From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= To: Gert Doering Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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, 28 Jul 2015 13:58:06 -0000 On 7/28/15, Gert Doering wrote: > Hi, > > On Mon, Jul 27, 2015 at 03:25:18PM +0200, Andrew ???? Yourtchenko wrote: >> The disjoint nature of IA_NA means a corresponding number of TCAM >> entries is required on L3 switches. >> >> A prefix, on the other hand, requires just an entry for the link-local >> of the host + an entry for the prefix. Regardless of the prefix >> length. > > All true. But then you excercise pressure on the prefix allocation side > - instead of having "one /64 for that LAN segment, which is big enough > for arbitrary number of hosts" you end up with "a /52[-ish] per LAN segment > to cover DHCP-PD delegation to thousands of hosts". > > (Say, 1000 hosts, all doing DHCP-PD and requesting a single /64, you'd > need to provision at least a /54 per segment - which will increase your > prefix usage enormously) > > Is that what you want? I did not look at it as a problem given that every mobile phone on IPv6 will already get a /64 per host, and the number of mobile phones is dramatically bigger than the number of fixed installations. But I pulled that assumption more or less out of my thumb, based on observed anecdata, so would be happy to be proven wrong. If we say we want to absolutely avoid NAT, then something has to give, and I don't know which tradeoff is a better one, both can be argued for and against. I think we might need both. --a > > 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 Jul 28 07:27:27 2015 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 8A67F1ABB1A for ; Tue, 28 Jul 2015 07:27:25 -0700 (PDT) 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 6qzd1oIHhgtD for ; Tue, 28 Jul 2015 07:27:24 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (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 6397B1A6F30 for ; Tue, 28 Jul 2015 07:27:24 -0700 (PDT) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 33B8BDA008A for ; Tue, 28 Jul 2015 14:27:24 +0000 (UTC) Received: from [10.0.20.178] (71.233.41.235) by CAS-03.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 28 Jul 2015 07:27:23 -0700 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ted Lemon In-Reply-To: Date: Tue, 28 Jul 2015 10:27:22 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> <55B1ED14.6030501@gmail.com> <20150727091241.GL84167@Space.Net> <20150728115944.GZ84167@Space.Net> To: IPv6 Operations X-Mailer: Apple Mail (2.2102) X-Originating-IP: [71.233.41.235] Archived-At: Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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, 28 Jul 2015 14:27:25 -0000 Having read the document, it seems a bit pie in the sky. The idea that = subdividing a prefix will give users privacy is nonsensical: if it is = well known that ISP X provides a /48 to every home, then people will = assume that all hosts in any given /48 in that ISP=E2=80=99s allocation = will belong to the same person or same household. Given that, then if there is some performance reason for clustering = multiple address assignments to the same host, the way to do it is to = delegate a /120 to that host, and have a route to that /120 that points = to that host. If the host needs more than 256 addresses, delegate = something bigger, or delegate multiple /120s. This is really easy to do. It doesn=E2=80=99t give you a ton of = privacy, but I don=E2=80=99t think it gives you less privacy than = delegating a /64, and in some sense it gives you more because now you = can do multiple allocations and still get the efficiency of address = clustering, and the snooper doesn=E2=80=99t have as much information = about address allocation patterns. And if you don=E2=80=99t want to do DHCPv6-PD, then SLAAC is actually = ideal for this application, because you can in principle use a random = number generator to produce the host part of the address, and just = generate a bunch of random numbers with entropy so that a snooper = can=E2=80=99t predict which addresses will be held in common by the same = host. But I still really don=E2=80=99t see the point of this. From nobody Tue Jul 28 07:29:14 2015 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 A49C01A9080 for ; Tue, 28 Jul 2015 07:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 FWjJWDXoMjMP for ; Tue, 28 Jul 2015 07:29:10 -0700 (PDT) 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 4C2CE1A6F30 for ; Tue, 28 Jul 2015 07:29:10 -0700 (PDT) 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 t6SET98o063307; Tue, 28 Jul 2015 07:29:09 -0700 Received: from XCH-PHX-413.sw.nos.boeing.com (xch-phx-413.sw.nos.boeing.com [10.57.37.45]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t6SET87r063297 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 28 Jul 2015 07:29:09 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.231]) by XCH-PHX-413.sw.nos.boeing.com ([169.254.13.59]) with mapi id 14.03.0235.001; Tue, 28 Jul 2015 07:29:08 -0700 From: "Templin, Fred L" To: =?utf-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= , "Gert Doering" Thread-Topic: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-01.txt Thread-Index: AQHQyT11GTvNaKRRoESx6jY9+5U45Z3w8ACQ Date: Tue, 28 Jul 2015 14:29:07 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832ED0A83@XCH-BLV-504.nw.nos.boeing.com> References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> <55B1ED14.6030501@gmail.com> <20150727091241.GL84167@Space.Net> <20150728115944.GZ84167@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: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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, 28 Jul 2015 14:29:11 -0000 SGksDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogdjZvcHMgW21haWx0 bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQW5kcmV3ID8/IFlvdXJ0Y2hl bmtvDQo+IFNlbnQ6IFR1ZXNkYXksIEp1bHkgMjgsIDIwMTUgNjo1OCBBTQ0KPiBUbzogR2VydCBE b2VyaW5nDQo+IENjOiBJUHY2IE9wZXJhdGlvbnMNCj4gU3ViamVjdDogUmU6IFt2Nm9wc10gSS1E IEFjdGlvbjogZHJhZnQtY29saXR0aS12Nm9wcy1ob3N0LWFkZHItYXZhaWxhYmlsaXR5LTAxLnR4 dA0KPiANCj4gT24gNy8yOC8xNSwgR2VydCBEb2VyaW5nIDxnZXJ0QHNwYWNlLm5ldD4gd3JvdGU6 DQo+ID4gSGksDQo+ID4NCj4gPiBPbiBNb24sIEp1bCAyNywgMjAxNSBhdCAwMzoyNToxOFBNICsw MjAwLCBBbmRyZXcgPz8/PyAgWW91cnRjaGVua28gd3JvdGU6DQo+ID4+IFRoZSBkaXNqb2ludCBu YXR1cmUgb2YgSUFfTkEgbWVhbnMgYSBjb3JyZXNwb25kaW5nIG51bWJlciBvZiBUQ0FNDQo+ID4+ IGVudHJpZXMgaXMgcmVxdWlyZWQgb24gTDMgc3dpdGNoZXMuDQo+ID4+DQo+ID4+IEEgcHJlZml4 LCBvbiB0aGUgb3RoZXIgaGFuZCwgcmVxdWlyZXMganVzdCBhbiBlbnRyeSBmb3IgdGhlIGxpbmst bG9jYWwNCj4gPj4gb2YgdGhlIGhvc3QgKyBhbiBlbnRyeSBmb3IgdGhlIHByZWZpeC4gUmVnYXJk bGVzcyBvZiB0aGUgcHJlZml4DQo+ID4+IGxlbmd0aC4NCj4gPg0KPiA+IEFsbCB0cnVlLiAgQnV0 IHRoZW4geW91IGV4Y2VyY2lzZSBwcmVzc3VyZSBvbiB0aGUgcHJlZml4IGFsbG9jYXRpb24gc2lk ZQ0KPiA+IC0gaW5zdGVhZCBvZiBoYXZpbmcgIm9uZSAvNjQgZm9yIHRoYXQgTEFOIHNlZ21lbnQs IHdoaWNoIGlzIGJpZyBlbm91Z2gNCj4gPiBmb3IgYXJiaXRyYXJ5IG51bWJlciBvZiBob3N0cyIg eW91IGVuZCB1cCB3aXRoICJhIC81MlstaXNoXSBwZXIgTEFOIHNlZ21lbnQNCj4gPiB0byBjb3Zl ciBESENQLVBEIGRlbGVnYXRpb24gdG8gdGhvdXNhbmRzIG9mIGhvc3RzIi4NCj4gPg0KPiA+IChT YXksIDEwMDAgaG9zdHMsIGFsbCBkb2luZyBESENQLVBEIGFuZCByZXF1ZXN0aW5nIGEgc2luZ2xl IC82NCwgeW91J2QNCj4gPiBuZWVkIHRvIHByb3Zpc2lvbiBhdCBsZWFzdCBhIC81NCBwZXIgc2Vn bWVudCAtIHdoaWNoIHdpbGwgaW5jcmVhc2UgeW91cg0KPiA+IHByZWZpeCB1c2FnZSBlbm9ybW91 c2x5KQ0KPiA+DQo+ID4gSXMgdGhhdCB3aGF0IHlvdSB3YW50Pw0KPiANCj4gSSBkaWQgbm90IGxv b2sgYXQgaXQgYXMgYSBwcm9ibGVtIGdpdmVuIHRoYXQgZXZlcnkgbW9iaWxlIHBob25lIG9uDQo+ IElQdjYgd2lsbCBhbHJlYWR5IGdldCBhIC82NCBwZXIgaG9zdCwgYW5kIHRoZSBudW1iZXIgb2Yg bW9iaWxlIHBob25lcw0KPiBpcyBkcmFtYXRpY2FsbHkgYmlnZ2VyIHRoYW4gdGhlIG51bWJlciBv ZiBmaXhlZCBpbnN0YWxsYXRpb25zLg0KDQpUaGF0IGlzIGNvcnJlY3QgdGhhdCAvNjQgcGVyIGhv c3QgaXMgd2hhdCBpcyBiZWluZyBkb25lIGZvciBtb2JpbGUgcGhvbmVzLg0KDQpBbHNvLCBESENQ djYgUEQgaGFzIGFuIGFkdmFudGFnZSBvdmVyIFNMQUFDIC0gdGhlcmUgaXMgbm8gbmVlZCBmb3IN CkRBRCBvbiB0aGUgbGluayBvdmVyIHdoaWNoIHRoZSBwcmVmaXggaXMgZGVsZWdhdGVkLCBzaW5j ZSB0aGUgcHJlZml4IGlzDQpub3QgYXNzaWduZWQgdG8gdGhhdCBsaW5rLiBBbmQsIHRoZSBESENQ djYgc2VydmVyIHdpbGwgZW5zdXJlIHRoYXQNCnByZWZpeGVzIGFyZSB1bmlxdWVseSBhc3NpZ25l ZCBzbyB0aGF0IHRoZXJlIGlzIG5vIGR1cGxpY2F0aW9uLg0KDQpUaGFua3MgLSBGcmVkDQpmcmVk LmwudGVtcGxpbkBib2VpbmcuY29tDQoNCj4gQnV0IEkgcHVsbGVkIHRoYXQgYXNzdW1wdGlvbiBt b3JlIG9yIGxlc3Mgb3V0IG9mIG15IHRodW1iLCBiYXNlZCBvbg0KPiBvYnNlcnZlZCBhbmVjZGF0 YSwgc28gd291bGQgYmUgaGFwcHkgdG8gYmUgcHJvdmVuIHdyb25nLg0KPiANCj4gSWYgd2Ugc2F5 IHdlIHdhbnQgdG8gYWJzb2x1dGVseSBhdm9pZCBOQVQsIHRoZW4gc29tZXRoaW5nIGhhcyB0byBn aXZlLA0KPiBhbmQgSSBkb24ndCBrbm93IHdoaWNoIHRyYWRlb2ZmIGlzIGEgYmV0dGVyIG9uZSwg Ym90aCBjYW4gYmUgYXJndWVkDQo+IGZvciBhbmQgYWdhaW5zdC4gSSB0aGluayB3ZSBtaWdodCBu ZWVkIGJvdGguDQo+IA0KPiAtLWENCj4gDQo+IA0KPiA+DQo+ID4gR2VydCBEb2VyaW5nDQo+ID4g ICAgICAgICAtLSBOZXRNYXN0ZXINCj4gPiAtLQ0KPiA+IGhhdmUgeW91IGVuYWJsZWQgSVB2NiBv biBzb21ldGhpbmcgdG9kYXkuLi4/DQo+ID4NCj4gPiBTcGFjZU5ldCBBRyAgICAgICAgICAgICAg ICAgICAgICAgIFZvcnN0YW5kOiBTZWJhc3RpYW4gdi4gQm9taGFyZA0KPiA+IEpvc2VwaC1Eb2xs aW5nZXItQm9nZW4gMTQgICAgICAgICAgQXVmc2ljaHRzcmF0c3ZvcnMuOiBBLiBHcnVuZG5lci1D dWxlbWFubg0KPiA+IEQtODA4MDcgTXVlbmNoZW4gICAgICAgICAgICAgICAgICAgSFJCOiAxMzYw NTUgKEFHIE11ZW5jaGVuKQ0KPiA+IFRlbDogKzQ5ICgwKTg5LzMyMzU2LTQ0NCAgICAgICAgICAg VVN0LUlkTnIuOiBERTgxMzE4NTI3OQ0KPiA+DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gdjZvcHNA aWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0K From nobody Tue Jul 28 08:16:22 2015 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 35BF81AC42A for ; Tue, 28 Jul 2015 08:16:21 -0700 (PDT) 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 yB2ouTCoxc9o for ; Tue, 28 Jul 2015 08:16:19 -0700 (PDT) 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 0BA431AC446 for ; Tue, 28 Jul 2015 08:16:18 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id C8C8F60758 for ; Tue, 28 Jul 2015 17:16:16 +0200 (CEST) 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 8CFF660054 for ; Tue, 28 Jul 2015 17:16:16 +0200 (CEST) Received: (qmail 19738 invoked by uid 1007); 28 Jul 2015 17:16:16 +0200 Date: Tue, 28 Jul 2015 17:16:16 +0200 From: Gert Doering To: Andrew ???? Yourtchenko Message-ID: <20150728151616.GG84167@Space.Net> References: <55B1ED14.6030501@gmail.com> <20150727091241.GL84167@Space.Net> <20150728115944.GZ84167@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bOC9TN0n4iVUZoxs" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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, 28 Jul 2015 15:16:21 -0000 --bOC9TN0n4iVUZoxs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Jul 28, 2015 at 03:58:04PM +0200, Andrew ???? Yourtchenko wrote: > I did not look at it as a problem given that every mobile phone on > IPv6 will already get a /64 per host, and the number of mobile phones > is dramatically bigger than the number of fixed installations. Bigger than then number of L2 *segments*, undoubtly. But no way bigger than "the number of devices that could attach to a L2 link" - as all these mobile phone also has wifi, so you have way more devices that attach to "shared links". Network structure is also way different - in mobile, all devices attach to some sort of aggregation router (via 3G PDP tunnels etc) - while in "classic" networking, you have a multitude of independent segments that do not normally have aggregation infrastructure or provisioning available. Prefix mobility in a typical enterprise networks (where you'd have enough devices in a L2 segment to start think about scaling) isn't really there. > But I pulled that assumption more or less out of my thumb, based on > observed anecdata, so would be happy to be proven wrong. >=20 > If we say we want to absolutely avoid NAT, then something has to give, > and I don't know which tradeoff is a better one, both can be argued > for and against. I think we might need both. If you want my opinion, I think DHCPv6-PD to single hosts (=3D not something that does tethering) is not a reasonable approach. If something does tethering, you need to decide what you're talking about, "enterprise-ish", "mobile" or "homenet". In mobile, DHCPv6-PD, or just sharing the PDP /64. In homenet, HNCP or DHCPv6-PD. In the enterprise? = =20 No idea what can be implemented with the typical constraints on=20 trackability, security, etc. (like: if the device attaches to *this*=20 network, it's permitted to go *there* by IP ACLs - whether or not this=20 is a reasonable approach in itself anymore stands to be debated, but it=20 will be with us for a long time). 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 --bOC9TN0n4iVUZoxs Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVbecwN9WwGXkzn/FAQKKgQ/9HHt6Vg7aAKQ7dxme8Z1kr4AlavQYDiZm jV8SpUqfdiui9ML/HJfpPrdQsVo6aHmcEwgO6PwvZZG5CN4k+Clo2mr5nD4AdZCD eONx9gvdYAmCTGab7XIeAEpW0liuvcCUAurtb3SZmgOojKht/SrIvDHmqfmhm8Gx 77pgZ09MPMP54AjWS1+VpDOFezvAY+0Z9w2Z0NtIQ/9E9MLSCjE6swst/F0NSLMQ Oh04DjfwKbA4NZq6JmWdox0AVsVxwjKu4o3P1KNPMuu2F1eRJQ4M9YaV9X1eBVgo s9vzdgXN1tm5viQmdNrPNlR+rSXjQfHfCAgwUGUgpwSDSgU2rj627jGjzibDISrF /ZTh/PHS0gkPchCtOaEUkNGf0Z+cpjK4bL3DOBtIQuofpf1e/nP9ettT0Guda1Xk 01R0g+fFFB9YWs82yt5z6E1qx3g52mMSwLx/DtmKsWPcr6kpfxk3FVTeM/NJuOX8 Ux114KRQRVLLEtLbSdg1v6pGmxoMHUGTLHoNJJ5a5ysfzwzg6u9opsdoJIB/e7Nn FxMo0kXn12L4vJXq0BTZ3PQPcBAiT/4cbtl75SIOkfmrNxJxWvE65mvKUf3f6fAW sweeNXTWSqomC/R+fiqjGCSNHy0opb73RIIpYsuwM03O1lHuPhT5j8RbMljtYM7J HEFIAPU9kTY= =9gOj -----END PGP SIGNATURE----- --bOC9TN0n4iVUZoxs-- From nobody Tue Jul 28 08:58:19 2015 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 918BD1ACD5F for ; Tue, 28 Jul 2015 08:58:17 -0700 (PDT) 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 e7kqqmdSQ_18 for ; Tue, 28 Jul 2015 08:58:15 -0700 (PDT) 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 5854C1ACDA0 for ; Tue, 28 Jul 2015 08:57:18 -0700 (PDT) Received: by ykdu72 with SMTP id u72so99225274ykd.2 for ; Tue, 28 Jul 2015 08:57:17 -0700 (PDT) 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=YtG4J8Z7ytPmtTR371X8Yk6KphlgXYhCUNHo1CFvq4I=; b=mw0injXkqfcPBivxgXioSRuH7kMDx4pYb3COMs64YvXFaGvnVrjingxBizrBhooqhn VYjBjz6DKXiLkXxyxT/siI9dl1CJHvTBG2MwQu13LbiiuecWzOXZqwVNOsOEmwfiYsRK KArWWmWVmfrIXURK6o9t1a//pJv5jANCq7kjYvbJCQyd2jxIK45qjymzCiJgWFVib9sl Cd37xP3uqjEsL4mLiVK/EylVgiWAvtiphFZAV9RS5yWD0MASGeHSeiwdNr3lwsRFZ990 yFWX8NmlMlCu74llOUquzTQJZHxbUO0RCoCxjlpdgi+5vVPbKVxz8shByRb9gTN6f/a4 bBAw== 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=YtG4J8Z7ytPmtTR371X8Yk6KphlgXYhCUNHo1CFvq4I=; b=Z6aMKjbGq3pDz0nY/5JpiiMzLg26wDYh+xetjvqXMZgtFkbWQPsMlHPAcPBiDb21my WmJXxiQ69AZv9b4V6iniHNt2xVN5mB044vzA5c2MCFSDadnkiiOUYGrX0wN5X5nX+Lvs s9hzJoKKHuq3D9dK45bWk09LwIKqJ0Yx013X8Foiyv1QLU9KFR5V2pzl1I4tQYb1gVnE mG+5cH5MWBtR6FJcA238i3ioAFkL/aJ9w2Ntx/2sFZk3+doRYO00uqrFv2eXp4VGiUyD 0HqdVx8TlRM7HGHxSDb7HN4KfHD5v+8TefvBtDd3C7/yaKlNpoJH4u8fZLITpihMAXzh cE3A== X-Gm-Message-State: ALoCoQkAuj1eMlKmgX81+NThSyoUG6GUiFz0iVePWYBGmTuOTwuSacWIOoSfr4LYPuTS7py2v5iZ X-Received: by 10.129.75.214 with SMTP id y205mr38919837ywa.65.1438099037537; Tue, 28 Jul 2015 08:57:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.8.201 with HTTP; Tue, 28 Jul 2015 08:56:57 -0700 (PDT) In-Reply-To: References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> <55B1ED14.6030501@gmail.com> <20150727091241.GL84167@Space.Net> <20150728115944.GZ84167@Space.Net> From: Lorenzo Colitti Date: Wed, 29 Jul 2015 00:56:57 +0900 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=001a113f3d0a4925f0051bf18655 Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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, 28 Jul 2015 15:58:17 -0000 --001a113f3d0a4925f0051bf18655 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable SLAAC might be ideal for this, but there are many (mostly enterprise / university) network administrators who have stated they will never run SLAAC. One goal of this document is to ensure that even on networks don't run SLAAC, then we as an industry don't end up with substantial deployments of networks that provide too few addresses. That will over time pressure devices to implement NAT66, and that would be suboptimal for everybody. Privacy is only one of the many use cases in the draft. Another pretty clear example is running VMs in your laptop. What are you going to do if the network doesn't run SLAAC but provides you with exactly 1 IA_NA and you want to run a VM? (Other than NAT66, I mean...) On Tue, Jul 28, 2015 at 11:27 PM, Ted Lemon wrote: > Having read the document, it seems a bit pie in the sky. The idea that > subdividing a prefix will give users privacy is nonsensical: if it is wel= l > known that ISP X provides a /48 to every home, then people will assume th= at > all hosts in any given /48 in that ISP=E2=80=99s allocation will belong t= o the same > person or same household. > > Given that, then if there is some performance reason for clustering > multiple address assignments to the same host, the way to do it is to > delegate a /120 to that host, and have a route to that /120 that points t= o > that host. If the host needs more than 256 addresses, delegate somethin= g > bigger, or delegate multiple /120s. > > This is really easy to do. It doesn=E2=80=99t give you a ton of privacy= , but I > don=E2=80=99t think it gives you less privacy than delegating a /64, and = in some > sense it gives you more because now you can do multiple allocations and > still get the efficiency of address clustering, and the snooper doesn=E2= =80=99t > have as much information about address allocation patterns. > > And if you don=E2=80=99t want to do DHCPv6-PD, then SLAAC is actually ide= al for > this application, because you can in principle use a random number > generator to produce the host part of the address, and just generate a > bunch of random numbers with entropy so that a snooper can=E2=80=99t pred= ict which > addresses will be held in common by the same host. > > But I still really don=E2=80=99t see the point of this. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a113f3d0a4925f0051bf18655 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
SLAAC might be ideal for this, but there are many (mostly = enterprise / university) network administrators who have stated they will n= ever run SLAAC.

One goal of this document is to ensure t= hat even on networks don't run SLAAC, then we as an industry don't = end up with substantial deployments of networks that provide too few addres= ses. That will over time pressure devices to implement NAT66, and that woul= d be suboptimal for everybody.

Privacy is only one= of the many use cases in the draft. Another pretty clear example is runnin= g VMs in your laptop. What are you going to do if the network doesn't r= un SLAAC but provides you with exactly 1 IA_NA and you want to run a VM? (O= ther than NAT66, I mean...)

On Tue, Jul 28, 2015 at 11:27 PM, Ted Lemon <ted.lemo= n@nominum.com> wrote:
Havin= g read the document, it seems a bit pie in the sky.=C2=A0 =C2=A0The idea th= at subdividing a prefix will give users privacy is nonsensical: if it is we= ll known that ISP X provides a /48 to every home, then people will assume t= hat all hosts in any given /48 in that ISP=E2=80=99s allocation will belong= to the same person or same household.

Given that, then if there is some performance reason for clustering multipl= e address assignments to the same host, the way to do it is to delegate a /= 120 to that host, and have a route to that /120 that points to that host.= =C2=A0 =C2=A0If the host needs more than 256 addresses, delegate something = bigger, or delegate multiple /120s.

This is really easy to do.=C2=A0 =C2=A0It doesn=E2=80=99t give you a ton of= privacy, but I don=E2=80=99t think it gives you less privacy than delegati= ng a /64, and in some sense it gives you more because now you can do multip= le allocations and still get the efficiency of address clustering, and the = snooper doesn=E2=80=99t have as much information about address allocation p= atterns.

And if you don=E2=80=99t want to do DHCPv6-PD, then SLAAC is actually ideal= for this application, because you can in principle use a random number gen= erator to produce the host part of the address, and just generate a bunch o= f random numbers with entropy so that a snooper can=E2=80=99t predict which= addresses will be held in common by the same host.

But I still really don=E2=80=99t see the point of this.

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

--001a113f3d0a4925f0051bf18655-- From nobody Tue Jul 28 09:14:54 2015 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 875B21ACDAA for ; Tue, 28 Jul 2015 09:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 jJJglupN3Ew2 for ; Tue, 28 Jul 2015 09:14:50 -0700 (PDT) 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 AFE331ACDB1 for ; Tue, 28 Jul 2015 09:14:50 -0700 (PDT) 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 t6SGEolL065018; Tue, 28 Jul 2015 09:14:50 -0700 Received: from XCH-PHX-410.sw.nos.boeing.com (xch-phx-410.sw.nos.boeing.com [10.57.37.41]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t6SGEhSb064963 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 28 Jul 2015 09:14:43 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.231]) by XCH-PHX-410.sw.nos.boeing.com ([169.254.10.48]) with mapi id 14.03.0235.001; Tue, 28 Jul 2015 09:14:43 -0700 From: "Templin, Fred L" To: Gert Doering , Andrew ???? Yourtchenko Thread-Topic: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-01.txt Thread-Index: AQHQyUhYGTvNaKRRoESx6jY9+5U45Z3xC4+Q Date: Tue, 28 Jul 2015 16:14:42 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832ED0BAC@XCH-BLV-504.nw.nos.boeing.com> References: <55B1ED14.6030501@gmail.com> <20150727091241.GL84167@Space.Net> <20150728115944.GZ84167@Space.Net> <20150728151616.GG84167@Space.Net> In-Reply-To: <20150728151616.GG84167@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: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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, 28 Jul 2015 16:14:52 -0000 Hi, > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Gert Doering > Sent: Tuesday, July 28, 2015 8:16 AM > To: Andrew ???? Yourtchenko > Cc: IPv6 Operations > Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availabili= ty-01.txt >=20 > Hi, >=20 > On Tue, Jul 28, 2015 at 03:58:04PM +0200, Andrew ???? Yourtchenko wrote: > > I did not look at it as a problem given that every mobile phone on > > IPv6 will already get a /64 per host, and the number of mobile phones > > is dramatically bigger than the number of fixed installations. >=20 > Bigger than then number of L2 *segments*, undoubtly. >=20 > But no way bigger than "the number of devices that could attach to > a L2 link" - as all these mobile phone also has wifi, so you have way > more devices that attach to "shared links". >=20 > Network structure is also way different - in mobile, all devices attach > to some sort of aggregation router (via 3G PDP tunnels etc) - while > in "classic" networking, you have a multitude of independent segments > that do not normally have aggregation infrastructure or provisioning > available. Prefix mobility in a typical enterprise networks (where > you'd have enough devices in a L2 segment to start think about scaling) > isn't really there. >=20 > > But I pulled that assumption more or less out of my thumb, based on > > observed anecdata, so would be happy to be proven wrong. > > > > If we say we want to absolutely avoid NAT, then something has to give, > > and I don't know which tradeoff is a better one, both can be argued > > for and against. I think we might need both. >=20 > If you want my opinion, I think DHCPv6-PD to single hosts (=3D not someth= ing > that does tethering) is not a reasonable approach. >=20 > If something does tethering, you need to decide what you're talking about= , > "enterprise-ish", "mobile" or "homenet". In mobile, DHCPv6-PD, or just > sharing the PDP /64. In homenet, HNCP or DHCPv6-PD. In the enterprise? > No idea what can be implemented with the typical constraints on > trackability, security, etc. (like: if the device attaches to *this* > network, it's permitted to go *there* by IP ACLs - whether or not this > is a reasonable approach in itself anymore stands to be debated, but it > will be with us for a long time). In the enterprise, you can do AERO. Treat the enterprise as one gigantic link. Use DHCPv6 PD to delegate prefixes to mobile enterprise nodes on the link. Use IPv6 ND the same as on any other NBMA link. It scales to as many nodes as can be covered by the enterprise's IPv6 prefix allocations, and it uses route optimization to avoid tethering. It is a scalable and incrementally deployable solution for IPv6 deployment on enterprise mobile nodes. Give each one its own IPv6 prefix, and let it connect up an Internet of Things as it sees fit. Thanks - Fred fred.l.templin@boeing.com =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 Tue Jul 28 09:28:25 2015 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 87D011ACDD4 for ; Tue, 28 Jul 2015 09:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 VEIB8uRxPb8j for ; Tue, 28 Jul 2015 09:28:22 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (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 DCC141ACDD0 for ; Tue, 28 Jul 2015 09:28:22 -0700 (PDT) Received: from webmail.nominum.com (cas-04.win.nominum.com [64.89.235.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id C6801DA0072; Tue, 28 Jul 2015 16:28:22 +0000 (UTC) Received: from [10.0.20.178] (71.233.41.235) by CAS-04.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 28 Jul 2015 09:28:16 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_F19C56D1-9F1F-4A05-9BDC-7C28EEE7E55C" MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ted Lemon In-Reply-To: Date: Tue, 28 Jul 2015 12:28:14 -0400 Message-ID: <4AB2ED61-23CF-40D5-B2A6-F1F4064EC0C6@nominum.com> References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> <55B1ED14.6030501@gmail.com> <20150727091241.GL84167@Space.Net> <20150728115944.GZ84167@Space.Net> To: Lorenzo Colitti X-Mailer: Apple Mail (2.2102) X-Originating-IP: [71.233.41.235] Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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, 28 Jul 2015 16:28:24 -0000 --Apple-Mail=_F19C56D1-9F1F-4A05-9BDC-7C28EEE7E55C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Jul 28, 2015, at 11:56 AM, Lorenzo Colitti = wrote: > One goal of this document is to ensure that even on networks don't run = SLAAC, then we as an industry don't end up with substantial deployments = of networks that provide too few addresses. That will over time pressure = devices to implement NAT66, and that would be suboptimal for everybody. >=20 > Privacy is only one of the many use cases in the draft. Another pretty = clear example is running VMs in your laptop. What are you going to do if = the network doesn't run SLAAC but provides you with exactly 1 IA_NA and = you want to run a VM? (Other than NAT66, I mean...) Okay, that helps put it in context. I don=E2=80=99t think you should = tout privacy as an advantage of this proposal, because I don=E2=80=99t = think this proposal really helps with privacy, but I agree that it = addresses the use case you=E2=80=99re describing. I think getting vendors to implement this using PD might be challenging, = but there are good reasons to do it that way. However, I don=E2=80=99t = think you need to delegate a /64. Do you buy my theory about just = using a /120 to aggregate a bunch of addresses, or no? I realize of = course that you=E2=80=99d also like it if we delegated /48s instead of = /56s, and I don=E2=80=99t really disagree with that, but I think if you = advance this proposal it=E2=80=99s going to be a hard sell to require = the delegation of a /64 per host, and I don=E2=80=99t think it adds any = value other than creating upstream pressure to delegate narrower = prefixes. --Apple-Mail=_F19C56D1-9F1F-4A05-9BDC-7C28EEE7E55C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" On Jul 28, 2015, at 11:56 AM, Lorenzo Colitti <lorenzo@google.com> = wrote:
One goal of this = document is to ensure that even on networks don't run SLAAC, then we as = an industry don't end up with substantial deployments of networks that = provide too few addresses. That will over time pressure devices to = implement NAT66, and that would be suboptimal for everybody.

Privacy is only one of = the many use cases in the draft. Another pretty clear example is running = VMs in your laptop. What are you going to do if the network doesn't run = SLAAC but provides you with exactly 1 IA_NA and you want to run a VM? = (Other than NAT66, I mean...)

Okay, that helps put it in context.  I = don=E2=80=99t think you should tout privacy as an advantage of this = proposal, because I don=E2=80=99t think this proposal really helps with = privacy, but I agree that it addresses the use case you=E2=80=99re = describing.

I = think getting vendors to implement this using PD might be challenging, = but there are good reasons to do it that way.   However, I don=E2=80=99= t think you need to delegate a /64.   Do you buy my theory about = just using a /120 to aggregate a bunch of addresses, or no?   I = realize of course that you=E2=80=99d also like it if we delegated /48s = instead of /56s, and I don=E2=80=99t really disagree with that, but I = think if you advance this proposal it=E2=80=99s going to be a hard sell = to require the delegation of a /64 per host, and I don=E2=80=99t think = it adds any value other than creating upstream pressure to delegate = narrower prefixes.

= --Apple-Mail=_F19C56D1-9F1F-4A05-9BDC-7C28EEE7E55C-- From nobody Tue Jul 28 09:51:46 2015 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 E52081AD351 for ; Tue, 28 Jul 2015 09:51:45 -0700 (PDT) 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 6PYVZ9Dsfdtf for ; Tue, 28 Jul 2015 09:51:44 -0700 (PDT) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 894491B2A10 for ; Tue, 28 Jul 2015 09:51:38 -0700 (PDT) Received: by ykdu72 with SMTP id u72so100683522ykd.2 for ; Tue, 28 Jul 2015 09:51:38 -0700 (PDT) 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=v3A+pB3jRf2FDhQdvhnVdzMnYuKAau5gQ+MR8CLxGLk=; b=V6yMOnumLVA1sMuGlmHqlfAxPXMMatJ51uEPM8tpQjnCqM7hvmD+jFHFMkbDw1QcTE 7vZfwCgy6v5WSnOZghW/AF65cwiA86qQlYfaOupLPacRYcTWMkle6vHPsxYinBiMblPh 122FHr2waU3Jlt8sqwfIwypxzduuXu325pnVLR93sA1K4DiXbcwJjfMVY5YI0s5xoPq2 fHxljVs3c8lqhwkx752tULjiZfTCzbw2yHB1C+TJIpXqF7YbCb5bx6Z7ihwLWqZBAL7m c/CEvpe/Oa9PsLR17k+8kHIQ1CeOuP/vWfI7o4r0auZ85Z7IWsIWh75fwdt5IkkZ6/I1 K3rw== 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=v3A+pB3jRf2FDhQdvhnVdzMnYuKAau5gQ+MR8CLxGLk=; b=SCUtKbB+SNlJp7j7oEr9leruiYqF2sRxo02aRHUybYEDqnixcq7X6TuKwq8XkImmVx 99r7ySJLjKsCXmPBG9f06lA6/iSgZz5gmxB7IouMTS/ZTkW4zY2Ilo/HtQfJUL0IaJtD klgp2BY+/8axDIkLyqv5Hkh9JHLTMYSGbzi7DBgXrhdHk+eeaETKMDw8TUEhWhdpDC6/ hg3wNcn94aDP7CCfq8rPpvZXgV8UBo6JPQeOqRGXnfWy2rz5eRHHFUP1zMWJO5SFnwTL JbI2Lc7/ah5ELHDwOrm1ykxXnyRgI3j/8gmCmEyeWqgSkbpgke2EPv0aaSZFaqSg45YM BAmQ== X-Gm-Message-State: ALoCoQl5eFvtfg0p2LXYiPowgsjbdFSlGt0VtUM2GF5z0qBQO83h0jE7sXp0qIhVARqc8/Q88XlL X-Received: by 10.129.108.2 with SMTP id h2mr37949154ywc.161.1438102297835; Tue, 28 Jul 2015 09:51:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.8.201 with HTTP; Tue, 28 Jul 2015 09:51:18 -0700 (PDT) In-Reply-To: <4AB2ED61-23CF-40D5-B2A6-F1F4064EC0C6@nominum.com> References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> <55B1ED14.6030501@gmail.com> <20150727091241.GL84167@Space.Net> <20150728115944.GZ84167@Space.Net> <4AB2ED61-23CF-40D5-B2A6-F1F4064EC0C6@nominum.com> From: Lorenzo Colitti Date: Wed, 29 Jul 2015 01:51:18 +0900 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=001a114dae7a9d2690051bf24802 Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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, 28 Jul 2015 16:51:46 -0000 --001a114dae7a9d2690051bf24802 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 29, 2015 at 1:28 AM, Ted Lemon wrote: > Do you buy my theory about just using a /120 to aggregate a bunch of > addresses, or no? > Well but if if you give a laptop or a device a /120, what is it going to give its downstream devices / VMs when sharing its internet connection with them? Does it have to implement a stateful DHCPv6 server and force its downstream devices/VMs to use it? At that point, the network it offered would be violating recommendations made in the draft. A /64 is better because it allows connection sharing mechanisms such as ND proxying and /64 share which also do not pose hard limits to the number of addresses a downstream device may have. A /64 also isn't that much space: the space implications for enterprise networks are pretty much the same as what we do for IPv4 today (i.e., a large enterprise that needs all of 10/8 gets 16M endpoints) - except that the address space implications for the Internet are much better than IPv4 today because said large enterprise with 16M endpoints will only need a /40, and there are quite a lot of those. --001a114dae7a9d2690051bf24802 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 29, 2015 at 1:28 AM, Ted Lemon <ted.lemon@nominum.com><= /span> wrote:
Do you buy my theory about just using a /120 to aggregate a b= unch of addresses, or no?

Well = but if if you give a laptop or a device a /120, what is it going to give it= s downstream devices / VMs when sharing its internet connection with them? = Does it have to implement a stateful DHCPv6 server and force its downstream= devices/VMs to use it? At that point, the network it offered would be viol= ating recommendations made in the draft.

A /64 is = better because it allows connection sharing mechanisms such as ND proxying = and /64 share which also do not pose hard limits to the number of addresses= a downstream device may have.

A /64 also isn'= t that much space: the space implications for enterprise networks are prett= y much the same as what we do for IPv4 today (i.e., a large enterprise that= needs all of 10/8 gets 16M endpoints) - except that the address space impl= ications for the Internet are much better than IPv4 today because said larg= e enterprise with 16M endpoints will only need a /40, and there are quite a= lot of those.
--001a114dae7a9d2690051bf24802-- From nobody Tue Jul 28 10:03:00 2015 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 407471B2B9B for ; Tue, 28 Jul 2015 10:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Ljfsw4q3djF for ; Tue, 28 Jul 2015 10:02:58 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001: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 E18891B2B9A for ; Tue, 28 Jul 2015 10:02:57 -0700 (PDT) Received: by igbpg9 with SMTP id pg9so130358542igb.0 for ; Tue, 28 Jul 2015 10:02:57 -0700 (PDT) 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=AiBrslKyE4T9lJp5ayDVc9SdVcTwDwW7xT/gGJcfB7c=; b=pwJt0SwwTyBJO7fQ7UTqUhhOqkJ2xVq1eTXsAxD/Lf0kk+y/a946qXRMfcOFN6xogm WQPapL03l+tZxE49Tm5UdbynZcM4opPfrQ7RJYqS3Rd6MfOlbtR7cTGtylUhQxkHO4JI i71XAOspTTEnP3jH5nOlzB0VK5mySOmXMXBojB0qL0KgNG+4+P7iKRwvkgRC35OmfnQw 0sEPQtST/NQBva/OINukVXc56lNGZYzQyKKfFgTo6Mt3KvpaHEZH+4SjsgpASj3yhGHc 9b6CXQp81+w10HNQsiE4QqjrukCzn7bDS7Q0NxRKRFiDfJrmJXTtoUA8r/Ze8/MGOPhD P0jQ== MIME-Version: 1.0 X-Received: by 10.50.138.70 with SMTP id qo6mr8639905igb.15.1438102977401; Tue, 28 Jul 2015 10:02:57 -0700 (PDT) Received: by 10.107.143.20 with HTTP; Tue, 28 Jul 2015 10:02:56 -0700 (PDT) In-Reply-To: <20150728151616.GG84167@Space.Net> References: <55B1ED14.6030501@gmail.com> <20150727091241.GL84167@Space.Net> <20150728115944.GZ84167@Space.Net> <20150728151616.GG84167@Space.Net> Date: Tue, 28 Jul 2015 19:02:56 +0200 Message-ID: From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= To: Gert Doering Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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, 28 Jul 2015 17:02:59 -0000 On 7/28/15, Gert Doering wrote: > Hi, > > On Tue, Jul 28, 2015 at 03:58:04PM +0200, Andrew ???? Yourtchenko wrote: >> I did not look at it as a problem given that every mobile phone on >> IPv6 will already get a /64 per host, and the number of mobile phones >> is dramatically bigger than the number of fixed installations. > > Bigger than then number of L2 *segments*, undoubtly. > > But no way bigger than "the number of devices that could attach to > a L2 link" - as all these mobile phone also has wifi, so you have way > more devices that attach to "shared links". I agree on the principle, though in reality it's even more complicated since one device can attach to more than one link, etc. - so I think it's actually even worse. > > Network structure is also way different - in mobile, all devices attach > to some sort of aggregation router (via 3G PDP tunnels etc) - while > in "classic" networking, you have a multitude of independent segments > that do not normally have aggregation infrastructure or provisioning > available. Prefix mobility in a typical enterprise networks (where > you'd have enough devices in a L2 segment to start think about scaling) > isn't really there. > Agreed. >> But I pulled that assumption more or less out of my thumb, based on >> observed anecdata, so would be happy to be proven wrong. >> >> If we say we want to absolutely avoid NAT, then something has to give, >> and I don't know which tradeoff is a better one, both can be argued >> for and against. I think we might need both. > > If you want my opinion, I think DHCPv6-PD to single hosts (= not something > that does tethering) is not a reasonable approach. My line of logic was that DHCPv6-PD with a /128 prefix is not much different from IA_NA. >From there it is trivial to say "no, thou shalt not do /128, use something shorter", and have the luxury to not define what is the value of "shorter" is because it's just a prefix length, and we can change per-situation. Going from one IA_NA to 10 IA_NA to 30 IA_NA is much harder, so we will be forced to freeze on the "right" value. > > If something does tethering, you need to decide what you're talking about, > "enterprise-ish", "mobile" or "homenet". In mobile, DHCPv6-PD, or just > sharing the PDP /64. In homenet, HNCP or DHCPv6-PD. In the enterprise? > No idea what can be implemented with the typical constraints on > trackability, security, etc. (like: if the device attaches to *this* > network, it's permitted to go *there* by IP ACLs - whether or not this > is a reasonable approach in itself anymore stands to be debated, but it > will be with us for a long time). I think you pointed the crux of the issue here: the enterprise network. An enterprise does not want one uncontrolled device behind another uncontrolled device, so realistically it will run IA_NA. And because it will want the cheapest possible hardware to provide the function, it will try to minimize the number of IA_NAs per host. And unless the hosts will crash and burn if they can not get X IA_NAs upfront (they won't), this number will go down to a number providing the most important 90% of functionality. The remaining 10% will have to adapt. --a > > 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 Jul 28 10:17:40 2015 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 5C3EC1B2C64 for ; Tue, 28 Jul 2015 10:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 6ESUuk9qmDqq for ; Tue, 28 Jul 2015 10:17:37 -0700 (PDT) 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 7304F1B2C4A for ; Tue, 28 Jul 2015 10:17:30 -0700 (PDT) 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 t6SHHUb0051038; Tue, 28 Jul 2015 10:17:30 -0700 Received: from XCH-PHX-509.sw.nos.boeing.com (xch-phx-509.sw.nos.boeing.com [10.57.37.31]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t6SHHJcs050695 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 28 Jul 2015 10:17:19 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.231]) by XCH-PHX-509.sw.nos.boeing.com ([169.254.9.68]) with mapi id 14.03.0235.001; Tue, 28 Jul 2015 10:17:19 -0700 From: "Templin, Fred L" To: =?utf-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= , "Gert Doering" Thread-Topic: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-01.txt Thread-Index: AQHQyVc/GTvNaKRRoESx6jY9+5U45Z3xHvwQ Date: Tue, 28 Jul 2015 17:17:18 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832ED0C60@XCH-BLV-504.nw.nos.boeing.com> References: <55B1ED14.6030501@gmail.com> <20150727091241.GL84167@Space.Net> <20150728115944.GZ84167@Space.Net> <20150728151616.GG84167@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: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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, 28 Jul 2015 17:17:39 -0000 SGksDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogdjZvcHMgW21haWx0 bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQW5kcmV3ID8/IFlvdXJ0Y2hl bmtvDQo+IFNlbnQ6IFR1ZXNkYXksIEp1bHkgMjgsIDIwMTUgMTA6MDMgQU0NCj4gVG86IEdlcnQg RG9lcmluZw0KPiBDYzogSVB2NiBPcGVyYXRpb25zDQo+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIEkt RCBBY3Rpb246IGRyYWZ0LWNvbGl0dGktdjZvcHMtaG9zdC1hZGRyLWF2YWlsYWJpbGl0eS0wMS50 eHQNCj4gDQo+IE9uIDcvMjgvMTUsIEdlcnQgRG9lcmluZyA8Z2VydEBzcGFjZS5uZXQ+IHdyb3Rl Og0KPiA+IEhpLA0KPiA+DQo+ID4gT24gVHVlLCBKdWwgMjgsIDIwMTUgYXQgMDM6NTg6MDRQTSAr MDIwMCwgQW5kcmV3ID8/Pz8gIFlvdXJ0Y2hlbmtvIHdyb3RlOg0KPiA+PiBJIGRpZCBub3QgbG9v ayBhdCBpdCBhcyBhIHByb2JsZW0gZ2l2ZW4gdGhhdCBldmVyeSBtb2JpbGUgcGhvbmUgb24NCj4g Pj4gSVB2NiB3aWxsIGFscmVhZHkgZ2V0IGEgLzY0IHBlciBob3N0LCBhbmQgdGhlIG51bWJlciBv ZiBtb2JpbGUgcGhvbmVzDQo+ID4+IGlzIGRyYW1hdGljYWxseSBiaWdnZXIgdGhhbiB0aGUgbnVt YmVyIG9mIGZpeGVkIGluc3RhbGxhdGlvbnMuDQo+ID4NCj4gPiBCaWdnZXIgdGhhbiB0aGVuIG51 bWJlciBvZiBMMiAqc2VnbWVudHMqLCB1bmRvdWJ0bHkuDQo+ID4NCj4gPiBCdXQgbm8gd2F5IGJp Z2dlciB0aGFuICJ0aGUgbnVtYmVyIG9mIGRldmljZXMgdGhhdCBjb3VsZCBhdHRhY2ggdG8NCj4g PiBhIEwyIGxpbmsiIC0gYXMgYWxsIHRoZXNlIG1vYmlsZSBwaG9uZSBhbHNvIGhhcyB3aWZpLCBz byB5b3UgaGF2ZSB3YXkNCj4gPiBtb3JlIGRldmljZXMgdGhhdCBhdHRhY2ggdG8gInNoYXJlZCBs aW5rcyIuDQo+IA0KPiBJIGFncmVlIG9uIHRoZSBwcmluY2lwbGUsIHRob3VnaCBpbiByZWFsaXR5 IGl0J3MgZXZlbiBtb3JlIGNvbXBsaWNhdGVkDQo+IHNpbmNlIG9uZSBkZXZpY2UgY2FuIGF0dGFj aCB0byBtb3JlIHRoYW4gb25lIGxpbmssIGV0Yy4gLSAgc28gSSB0aGluaw0KPiBpdCdzIGFjdHVh bGx5IGV2ZW4gd29yc2UuDQo+IA0KPiA+DQo+ID4gTmV0d29yayBzdHJ1Y3R1cmUgaXMgYWxzbyB3 YXkgZGlmZmVyZW50IC0gaW4gbW9iaWxlLCBhbGwgZGV2aWNlcyBhdHRhY2gNCj4gPiB0byBzb21l IHNvcnQgb2YgYWdncmVnYXRpb24gcm91dGVyICh2aWEgM0cgUERQIHR1bm5lbHMgZXRjKSAtIHdo aWxlDQo+ID4gaW4gImNsYXNzaWMiIG5ldHdvcmtpbmcsIHlvdSBoYXZlIGEgbXVsdGl0dWRlIG9m IGluZGVwZW5kZW50IHNlZ21lbnRzDQo+ID4gdGhhdCBkbyBub3Qgbm9ybWFsbHkgaGF2ZSBhZ2dy ZWdhdGlvbiBpbmZyYXN0cnVjdHVyZSBvciBwcm92aXNpb25pbmcNCj4gPiBhdmFpbGFibGUuICBQ cmVmaXggbW9iaWxpdHkgaW4gYSB0eXBpY2FsIGVudGVycHJpc2UgbmV0d29ya3MgKHdoZXJlDQo+ ID4geW91J2QgaGF2ZSBlbm91Z2ggZGV2aWNlcyBpbiBhIEwyIHNlZ21lbnQgdG8gc3RhcnQgdGhp bmsgYWJvdXQgc2NhbGluZykNCj4gPiBpc24ndCByZWFsbHkgdGhlcmUuDQo+ID4NCj4gDQo+IEFn cmVlZC4NCj4gDQo+IA0KPiA+PiBCdXQgSSBwdWxsZWQgdGhhdCBhc3N1bXB0aW9uIG1vcmUgb3Ig bGVzcyBvdXQgb2YgbXkgdGh1bWIsIGJhc2VkIG9uDQo+ID4+IG9ic2VydmVkIGFuZWNkYXRhLCBz byB3b3VsZCBiZSBoYXBweSB0byBiZSBwcm92ZW4gd3JvbmcuDQo+ID4+DQo+ID4+IElmIHdlIHNh eSB3ZSB3YW50IHRvIGFic29sdXRlbHkgYXZvaWQgTkFULCB0aGVuIHNvbWV0aGluZyBoYXMgdG8g Z2l2ZSwNCj4gPj4gYW5kIEkgZG9uJ3Qga25vdyB3aGljaCB0cmFkZW9mZiBpcyBhIGJldHRlciBv bmUsIGJvdGggY2FuIGJlIGFyZ3VlZA0KPiA+PiBmb3IgYW5kIGFnYWluc3QuIEkgdGhpbmsgd2Ug bWlnaHQgbmVlZCBib3RoLg0KPiA+DQo+ID4gSWYgeW91IHdhbnQgbXkgb3BpbmlvbiwgSSB0aGlu ayBESENQdjYtUEQgdG8gc2luZ2xlIGhvc3RzICg9IG5vdCBzb21ldGhpbmcNCj4gPiB0aGF0IGRv ZXMgdGV0aGVyaW5nKSBpcyBub3QgYSByZWFzb25hYmxlIGFwcHJvYWNoLg0KPiANCj4gTXkgbGlu ZSBvZiBsb2dpYyB3YXMgdGhhdCBESENQdjYtUEQgd2l0aCBhIC8xMjggcHJlZml4IGlzIG5vdCBt dWNoDQo+IGRpZmZlcmVudCBmcm9tIElBX05BLg0KDQpJdCBpcyBkaWZmZXJlbnQsIGJlY2F1c2Ug dW5saWtlIElBX05BIGEgZGVsZWdhdGVkIHByZWZpeCAoZXZlbiBhIC8xMjgpIGlzIG5vdA0KdG8g YmUgYXNzaWduZWQgdG8gdGhlIGxpbmsgb24gd2hpY2ggdGhlIGRlbGVnYXRpb24gd2FzIGNvb3Jk aW5hdGVkLiBBbHNvLA0KdGhlIC8xMjggaXMgY2FycmllZCBpbiB0aGUgcm91dGluZyBzeXN0ZW0s IGFuZCBtYXkgbm90IG1hdGNoIGFueSBvbi1saW5rDQpwcmVmaXhlcyBhdCBhbGwuDQoNClRoYW5r cyAtIEZyZWQNCmZyZWQubC50ZW1wbGluQGJvZWluZy5jb20NCg0KPiA+RnJvbSB0aGVyZSBpdCBp cyB0cml2aWFsIHRvIHNheSAibm8sIHRob3Ugc2hhbHQgbm90IGRvIC8xMjgsIHVzZQ0KPiBzb21l dGhpbmcgc2hvcnRlciIsIGFuZCBoYXZlIHRoZSBsdXh1cnkgdG8gbm90IGRlZmluZSB3aGF0IGlz IHRoZQ0KPiB2YWx1ZSBvZiAic2hvcnRlciIgaXMgYmVjYXVzZSBpdCdzIGp1c3QgYSBwcmVmaXgg bGVuZ3RoLCBhbmQgd2UgY2FuDQo+IGNoYW5nZSBwZXItc2l0dWF0aW9uLg0KPiANCj4gR29pbmcg ZnJvbSBvbmUgSUFfTkEgdG8gMTAgSUFfTkEgdG8gMzAgSUFfTkEgaXMgbXVjaCBoYXJkZXIsIHNv IHdlDQo+IHdpbGwgYmUgZm9yY2VkIHRvIGZyZWV6ZSBvbiB0aGUgInJpZ2h0IiB2YWx1ZS4NCj4g DQo+ID4NCj4gPiBJZiBzb21ldGhpbmcgZG9lcyB0ZXRoZXJpbmcsIHlvdSBuZWVkIHRvIGRlY2lk ZSB3aGF0IHlvdSdyZSB0YWxraW5nIGFib3V0LA0KPiA+ICJlbnRlcnByaXNlLWlzaCIsICJtb2Jp bGUiIG9yICJob21lbmV0Ii4gIEluIG1vYmlsZSwgREhDUHY2LVBELCBvciBqdXN0DQo+ID4gc2hh cmluZyB0aGUgUERQIC82NC4gIEluIGhvbWVuZXQsIEhOQ1Agb3IgREhDUHY2LVBELiAgSW4gdGhl IGVudGVycHJpc2U/DQo+ID4gTm8gaWRlYSB3aGF0IGNhbiBiZSBpbXBsZW1lbnRlZCB3aXRoIHRo ZSB0eXBpY2FsIGNvbnN0cmFpbnRzIG9uDQo+ID4gdHJhY2thYmlsaXR5LCBzZWN1cml0eSwgZXRj LiAgKGxpa2U6IGlmIHRoZSBkZXZpY2UgYXR0YWNoZXMgdG8gKnRoaXMqDQo+ID4gbmV0d29yaywg aXQncyBwZXJtaXR0ZWQgdG8gZ28gKnRoZXJlKiBieSBJUCBBQ0xzIC0gd2hldGhlciBvciBub3Qg dGhpcw0KPiA+IGlzIGEgcmVhc29uYWJsZSBhcHByb2FjaCBpbiBpdHNlbGYgYW55bW9yZSBzdGFu ZHMgdG8gYmUgZGViYXRlZCwgYnV0IGl0DQo+ID4gd2lsbCBiZSB3aXRoIHVzIGZvciBhIGxvbmcg dGltZSkuDQo+IA0KPiBJIHRoaW5rIHlvdSBwb2ludGVkIHRoZSBjcnV4IG9mIHRoZSBpc3N1ZSBo ZXJlOiB0aGUgZW50ZXJwcmlzZSBuZXR3b3JrLg0KPiANCj4gQW4gZW50ZXJwcmlzZSBkb2VzIG5v dCB3YW50IG9uZSB1bmNvbnRyb2xsZWQgZGV2aWNlIGJlaGluZCBhbm90aGVyDQo+IHVuY29udHJv bGxlZCBkZXZpY2UsIHNvIHJlYWxpc3RpY2FsbHkgaXQgd2lsbCBydW4gSUFfTkEuIEFuZCBiZWNh dXNlDQo+IGl0IHdpbGwgd2FudCB0aGUgY2hlYXBlc3QgcG9zc2libGUgaGFyZHdhcmUgdG8gcHJv dmlkZSB0aGUgZnVuY3Rpb24sDQo+IGl0IHdpbGwgdHJ5IHRvIG1pbmltaXplIHRoZSBudW1iZXIg b2YgSUFfTkFzIHBlciBob3N0Lg0KPiANCj4gQW5kIHVubGVzcyB0aGUgaG9zdHMgd2lsbCBjcmFz aCBhbmQgYnVybiBpZiB0aGV5IGNhbiBub3QgZ2V0IFggSUFfTkFzDQo+IHVwZnJvbnQgKHRoZXkg d29uJ3QpLCB0aGlzIG51bWJlciB3aWxsIGdvIGRvd24gdG8gYSBudW1iZXIgcHJvdmlkaW5nDQo+ IHRoZSBtb3N0IGltcG9ydGFudCA5MCUgb2YgZnVuY3Rpb25hbGl0eS4NCj4gVGhlIHJlbWFpbmlu ZyAxMCUgd2lsbCBoYXZlIHRvIGFkYXB0Lg0KPiANCj4gLS1hDQo+IA0KPiANCj4gPg0KPiA+IEdl cnQgRG9lcmluZw0KPiA+ICAgICAgICAgLS0gTmV0TWFzdGVyDQo+ID4gLS0NCj4gPiBoYXZlIHlv dSBlbmFibGVkIElQdjYgb24gc29tZXRoaW5nIHRvZGF5Li4uPw0KPiA+DQo+ID4gU3BhY2VOZXQg QUcgICAgICAgICAgICAgICAgICAgICAgICBWb3JzdGFuZDogU2ViYXN0aWFuIHYuIEJvbWhhcmQN Cj4gPiBKb3NlcGgtRG9sbGluZ2VyLUJvZ2VuIDE0ICAgICAgICAgIEF1ZnNpY2h0c3JhdHN2b3Jz LjogQS4gR3J1bmRuZXItQ3VsZW1hbm4NCj4gPiBELTgwODA3IE11ZW5jaGVuICAgICAgICAgICAg ICAgICAgIEhSQjogMTM2MDU1IChBRyBNdWVuY2hlbikNCj4gPiBUZWw6ICs0OSAoMCk4OS8zMjM1 Ni00NDQgICAgICAgICAgIFVTdC1JZE5yLjogREU4MTMxODUyNzkNCj4gPg0KPiANCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gdjZvcHMgbWFpbGlu ZyBsaXN0DQo+IHY2b3BzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdjZvcHMNCg== From nobody Tue Jul 28 10:51:36 2015 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 76D471B2CAF for ; Tue, 28 Jul 2015 10:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 0SXNVPFLh4C2 for ; Tue, 28 Jul 2015 10:51:34 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (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 357E71B2CB5 for ; Tue, 28 Jul 2015 10:51:29 -0700 (PDT) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id D3F47DA008A; Tue, 28 Jul 2015 17:51:28 +0000 (UTC) Received: from [10.0.20.178] (71.233.41.235) by CAS-03.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 28 Jul 2015 10:51:28 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_06D8369B-FF67-43E5-B6E5-4BE28A67FD40" MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ted Lemon In-Reply-To: Date: Tue, 28 Jul 2015 13:51:26 -0400 Message-ID: <90E6B48E-B3FC-4AAD-B356-7D92A2777632@nominum.com> References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> <55B1ED14.6030501@gmail.com> <20150727091241.GL84167@Space.Net> <20150728115944.GZ84167@Space.Net> <4AB2ED61-23CF-40D5-B2A6-F1F4064EC0C6@nominum.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.2102) X-Originating-IP: [71.233.41.235] Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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, 28 Jul 2015 17:51:35 -0000 --Apple-Mail=_06D8369B-FF67-43E5-B6E5-4BE28A67FD40 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Jul 28, 2015, at 12:51 PM, Lorenzo Colitti = wrote: > Well but if if you give a laptop or a device a /120, what is it going = to give its downstream devices / VMs when sharing its internet = connection with them? Does it have to implement a stateful DHCPv6 server = and force its downstream devices/VMs to use it? At that point, the = network it offered would be violating recommendations made in the draft. So you want the device to be able to use DHCPv6-PD on the upstream, but = support SLAAC on the downstream. So this really isn=E2=80=99t a = general mechanism: it=E2=80=99s for the smartphone router use case = specifically. > A /64 is better because it allows connection sharing mechanisms such = as ND proxying and /64 share which also do not pose hard limits to the = number of addresses a downstream device may have. For the smartphone router case, I can see that. > A /64 also isn't that much space: the space implications for = enterprise networks are pretty much the same as what we do for IPv4 = today (i.e., a large enterprise that needs all of 10/8 gets 16M = endpoints) - except that the address space implications for the Internet = are much better than IPv4 today because said large enterprise with 16M = endpoints will only need a /40, and there are quite a lot of those. There are 256 times as many /40s as IPv4 addresses. That=E2=80=99s a = _really_ small number unless you see the Internet growth curve = flattening out, and your draft suggests that you don't. The IPv6 = address space looks big compared to IPv4, but it seems like everybody = wants to pull bits out of it, and when you=E2=80=99re pulling out bits = and not addresses, you can only pull out 128 of them before you=E2=80=99re= done. --Apple-Mail=_06D8369B-FF67-43E5-B6E5-4BE28A67FD40 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" On Jul 28, 2015, at 12:51 PM, Lorenzo Colitti <lorenzo@google.com> = wrote:
Well but if if you give = a laptop or a device a /120, what is it going to give its downstream = devices / VMs when sharing its internet connection with them? Does it = have to implement a stateful DHCPv6 server and force its downstream = devices/VMs to use it? At that point, the network it offered would be = violating recommendations made in the = draft.

So you want the = device to be able to use DHCPv6-PD on the upstream, but support SLAAC on = the downstream.   So this really isn=E2=80=99t a general mechanism: = it=E2=80=99s for the smartphone router use case = specifically.

A /64 is better because it allows connection sharing = mechanisms such as ND proxying and /64 share which also do not pose hard = limits to the number of addresses a downstream device may = have.

For the = smartphone router case, I can see that.

A /64 also isn't that = much space: the space implications for enterprise networks are pretty = much the same as what we do for IPv4 today (i.e., a large enterprise = that needs all of 10/8 gets 16M endpoints) - except that the address = space implications for the Internet are much better than IPv4 today = because said large enterprise with 16M endpoints will only need a /40, = and there are quite a lot of those.

There are 256 times as many /40s as IPv4 = addresses.   That=E2=80=99s a _really_ small number unless you see = the Internet growth curve flattening out, and your draft suggests that = you don't.   The IPv6 address space looks big compared to IPv4, but = it seems like everybody wants to pull bits out of it, and when you=E2=80=99= re pulling out bits and not addresses, you can only pull out 128 of them = before you=E2=80=99re done.

= --Apple-Mail=_06D8369B-FF67-43E5-B6E5-4BE28A67FD40-- From nobody Tue Jul 28 10:58:45 2015 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 5F3781B2CE1 for ; Tue, 28 Jul 2015 10:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 WapJgmv_SPqZ for ; Tue, 28 Jul 2015 10:58:37 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 8082C1B2CD8 for ; Tue, 28 Jul 2015 10:58:37 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1ZK99A-0000DCC; Tue, 28 Jul 2015 19:58:36 +0200 Message-Id: To: IPv6 Operations From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> <55B1ED14.6030501@gmail.com> <20150727091241.GL84167@Space.Net> <20150728115944.GZ84167@Space.Net> <4AB2ED61-23CF-40D5-B2A6-F1F4064EC0C6@nominum.com> <90E6B48E-B3FC-4AAD-B356-7D92A2777632@nominum.com> In-reply-to: Your message of "Tue, 28 Jul 2015 13:51:26 -0400 ." <90E6B48E-B3FC-4AAD-B356-7D92A2777632@nominum.com> Date: Tue, 28 Jul 2015 19:58:36 +0200 Archived-At: Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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, 28 Jul 2015 17:58:41 -0000 > There are 256 times as many /40s as IPv4 addresses. Thats a > _really_ small number unless you see the Internet growth curve > flattening out, and your draft suggests that you don't. The > IPv6 address space looks big compared to IPv4, but it seems like > everybody wants to pull bits out of it, and when youre pulling > out bits and not addresses, you can only pull out 128 of them > before youre done. Assuming 256 ethernet devices per /40, you run out of MAC addresses first. Assuming 32-bit ASNs, you need 256 /40s per ASN. And the routing table has exploded before that. Is is not like ISPs can just hand out /40s to everybody from their PA space. From nobody Tue Jul 28 11:01:05 2015 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 9FC351B2CB1 for ; Tue, 28 Jul 2015 11:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 TdPdKSyeWRB8 for ; Tue, 28 Jul 2015 11:00:53 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (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 4A49D1A8F48 for ; Tue, 28 Jul 2015 11:00:53 -0700 (PDT) Received: from webmail.nominum.com (cas-04.win.nominum.com [64.89.235.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 40729DA008A; Tue, 28 Jul 2015 18:00:53 +0000 (UTC) Received: from [10.0.20.178] (71.233.41.235) by CAS-04.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 28 Jul 2015 11:00:52 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_6112F680-3950-49B1-A556-28E33D2F8CB4" MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ted Lemon In-Reply-To: Date: Tue, 28 Jul 2015 14:00:51 -0400 Message-ID: <804F2F0B-B0EF-4054-99C5-C0CD8957C434@nominum.com> References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> <55B1ED14.6030501@gmail.com> <20150727091241.GL84167@Space.Net> <20150728115944.GZ84167@Space.Net> <4AB2ED61-23CF-40D5-B2A6-F1F4064EC0C6@nominum.com> <90E6B48E-B3FC-4AAD-B356-7D92A2777632@nominum.com> To: Philip Homburg X-Mailer: Apple Mail (2.2102) X-Originating-IP: [71.233.41.235] Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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, 28 Jul 2015 18:00:57 -0000 --Apple-Mail=_6112F680-3950-49B1-A556-28E33D2F8CB4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Jul 28, 2015, at 1:58 PM, Philip Homburg = wrote: > Is is not like ISPs can just hand out /40s to everybody from their PA = space. Yes, this is what I=E2=80=99m saying. --Apple-Mail=_6112F680-3950-49B1-A556-28E33D2F8CB4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" On Jul 28, 2015, at 1:58 PM, Philip Homburg <pch-v6ops-3@u-1.phicoh.com> wrote:
Is is not like ISPs can just hand out /40s to = everybody from their PA space.

Yes, this is what I=E2=80=99m = saying.

= --Apple-Mail=_6112F680-3950-49B1-A556-28E33D2F8CB4-- From nobody Tue Jul 28 11:36:46 2015 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 19B5C1B2D7C for ; Tue, 28 Jul 2015 11:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FINL-vyRAErz for ; Tue, 28 Jul 2015 11:36:43 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::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 B4FAA1B2D7F for ; Tue, 28 Jul 2015 11:36:41 -0700 (PDT) Received: by wibud3 with SMTP id ud3so171710030wib.0 for ; Tue, 28 Jul 2015 11:36:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=tdb4bupR6gcE5ceoJK3RQVXBQMZd2GXWXWS3EtGt4H0=; b=nNZXtCF8hrSEhlZAXbCP9lrEkd7C5LejJ5ViSdSx15t7NzEViozRQ2VRrIlxMs139y 2KTuriWOjFl1sLQHO57Y4bcnE2syW0KKkwO4DP9LBDrVNeitmEJUmesCJp5Mu9q/CX2b 1Yll3EAZ8ps6V02S4LMQ2jBodIL9m+udkjWuiMJB6K+KKsbCoC6RvzE4Tr678Uc254C6 S73S2VuNm6gUhcxoThOCAfxkE8uY37Z3m+lcC+a5puGH+Z2Gl9qaK2PhteWAQ6l/Oyaj ITRreKiwyj90bySzKoFWGCvxm9TlNQp9UAOWosdIfmcW6MqwXryh/970zMlYjiqrrVkZ tcFw== X-Received: by 10.194.172.8 with SMTP id ay8mr68028507wjc.106.1438108600453; Tue, 28 Jul 2015 11:36:40 -0700 (PDT) Received: from [192.168.0.4] (cpc11-brig18-2-0-cust561.3-3.cable.virginm.net. [81.100.118.50]) by smtp.gmail.com with ESMTPSA id gc4sm20297193wib.23.2015.07.28.11.36.38 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Jul 2015 11:36:39 -0700 (PDT) Message-ID: <55B7CBB9.2050107@gmail.com> Date: Wed, 29 Jul 2015 06:36:41 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> <55B1ED14.6030501@gmail.com> <20150727091241.GL84167@Space.Net> <20150728115944.GZ84167@Space.Net> <4AB2ED61-23CF-40D5-B2A6-F1F4064EC0C6@nominum.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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, 28 Jul 2015 18:36:45 -0000 On 29/07/2015 04:51, Lorenzo Colitti wrote: > On Wed, Jul 29, 2015 at 1:28 AM, Ted Lemon wrote: > >> Do you buy my theory about just using a /120 to aggregate a bunch of >> addresses, or no? >> > > Well but if if you give a laptop or a device a /120, what is it going to > give its downstream devices / VMs when sharing its internet connection with > them? Does it have to implement a stateful DHCPv6 server and force its > downstream devices/VMs to use it? At that point, the network it offered > would be violating recommendations made in the draft. Not to mention encountering the problems with /120 mentioned in RFC 7421, which include the problems of only having a /24 in IPv4. We should be past that. Brian > > A /64 is better because it allows connection sharing mechanisms such as ND > proxying and /64 share which also do not pose hard limits to the number of > addresses a downstream device may have. > > A /64 also isn't that much space: the space implications for enterprise > networks are pretty much the same as what we do for IPv4 today (i.e., a > large enterprise that needs all of 10/8 gets 16M endpoints) - except that > the address space implications for the Internet are much better than IPv4 > today because said large enterprise with 16M endpoints will only need a > /40, and there are quite a lot of those. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue Jul 28 11:48:27 2015 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 14FEC1B2D8E for ; Tue, 28 Jul 2015 11:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 tBSjsJpdVOg9 for ; Tue, 28 Jul 2015 11:48:26 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (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 17FBB1B2CA5 for ; Tue, 28 Jul 2015 11:48:26 -0700 (PDT) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id F2D83DA008B; Tue, 28 Jul 2015 18:48:25 +0000 (UTC) Received: from [10.0.20.178] (71.233.41.235) by CAS-03.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 28 Jul 2015 11:48:25 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_021BAB8E-C250-43DB-B1F5-5214E3CE3A80" MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ted Lemon In-Reply-To: <55B7CBB9.2050107@gmail.com> Date: Tue, 28 Jul 2015 14:48:24 -0400 Message-ID: <730AF1E1-F435-4EE2-877A-A46B8A90AA4D@nominum.com> References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> <55B1ED14.6030501@gmail.com> <20150727091241.GL84167@Space.Net> <20150728115944.GZ84167@Space.Net> <4AB2ED61-23CF-40D5-B2A6-F1F4064EC0C6@nominum.com> <55B7CBB9.2050107@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.2102) X-Originating-IP: [71.233.41.235] Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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, 28 Jul 2015 18:48:27 -0000 --Apple-Mail=_021BAB8E-C250-43DB-B1F5-5214E3CE3A80 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Jul 28, 2015, at 2:36 PM, Brian E Carpenter = wrote: > Not to mention encountering the problems with /120 mentioned > in RFC 7421, which include the problems of only having a /24 in > IPv4. We should be past that. To be clear, I wasn=E2=80=99t proposing /120 prefixes, but the = delegation of /120 prefixes as a way of delivering a chunk of contiguous = addresses smaller than a /64, which I continue to think is impractical = for Lorenzo=E2=80=99s use case. --Apple-Mail=_021BAB8E-C250-43DB-B1F5-5214E3CE3A80 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" On Jul 28, 2015, at 2:36 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
Not to mention encountering the problems with = /120 mentioned
in RFC 7421, which include = the problems of only having a /24 in
IPv4. We should be past = that.

To = be clear, I wasn=E2=80=99t proposing /120 prefixes, but the delegation = of /120 prefixes as a way of delivering a chunk of contiguous addresses = smaller than a /64, which I continue to think is impractical for = Lorenzo=E2=80=99s use case.

= --Apple-Mail=_021BAB8E-C250-43DB-B1F5-5214E3CE3A80-- From nobody Tue Jul 28 12:58:46 2015 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 C4F4C1B2EEC for ; Tue, 28 Jul 2015 12:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.961 X-Spam-Level: X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, 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 93xK8SEye7UO for ; Tue, 28 Jul 2015 12:58:41 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24CBB1B2EE9 for ; Tue, 28 Jul 2015 12:58:40 -0700 (PDT) Received: from q4de8psa169.blf.telekom.de ([10.151.13.200]) by tcmail41.telekom.de with ESMTP; 28 Jul 2015 21:58:38 +0200 X-IronPort-AV: E=Sophos;i="5.15,565,1432591200"; d="scan'208";a="880272130" Received: from he111510.emea1.cds.t-internal.com ([10.206.92.113]) by q4de8psazkj.blf.telekom.de with ESMTP/TLS/AES128-SHA; 28 Jul 2015 21:58:38 +0200 Received: from HE111507.emea1.cds.t-internal.com ([10.206.92.89]) by HE111510.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 28 Jul 2015 21:58:37 +0200 From: To: Date: Tue, 28 Jul 2015 21:58:12 +0200 Thread-Topic: [v6ops] NAT64/DNS64 and DNSSEC Thread-Index: AdDF/N027lqkhNkeSoGZ+Wb7WfAUyQDcdTAg Message-ID: <88CAA5385EB5404392BF93106C8C53F89636B43DE3@HE111507.emea1.cds.t-internal.com> References: <55B09AE5.4040609@gmail.com> <2BBE839B-37FB-4EA2-982E-58028E7A13B6@nominum.com> <55B0F344.4090005@gmail.com> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] NAT64/DNS64 and DNSSEC 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, 28 Jul 2015 19:58:43 -0000 Hello, but isn't there a gap that when performing the RFC7050 64pref detection by = querying ipv6only.arpa, an attacker can spoof this answer (DNSSEC won't wor= k here, for example, the attacker - when between the client and the DNS - c= an return for example 2001:db8::192.0.0.170 (where 2001:db8:: is a prefix o= wned by the attacker)) and then attract all IPv4 traffic from the victim? Nevertheless, an answer to the proliferation of DNSSEC and at the same time= increasing usage of DNS64/NAT has to be found, not to stop the success of = one or the other. --=20 Holger Metschulat=20 Deutsche Telekom Technik GmbH=20 Heinrich-Hertz-Strasse 3-7, 64295 Darmstadt=20 +49 6151 58 - 18671 (Tel.)=20 +49 160 901 35443 (Mobil)=20 E-Mail: holger.metschulat@telekom.de=20 http://www.telekom.de=20 Erleben, was verbindet.=A0=20 Die gesetzlichen Pflichtangaben finden Sie unter: www.telekom.de/pflichtang= aben-dttechnik Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und nicht jede= E-Mail drucken.=20 -----Urspr=FCngliche Nachricht----- Von: v6ops [mailto:v6ops-bounces@ietf.org] Im Auftrag von Erik Kline Gesendet: Freitag, 24. Juli 2015 12:37 An: Philip Homburg Cc: v6ops@ietf.org Betreff: Re: [v6ops] NAT64/DNS64 and DNSSEC > I guess this is easy enough to add to for example getdns=20 > (https://getdnsapi.net/). One question is how an application would=20 > find out that it is running in a DNS64 environment. Another option is=20 > for getdns to do the probing and enable this option automatically. One approach comes to ming: when a client resolver starts up, it checks ipv= 4only.arpa (https://tools.ietf.org/html/rfc7050#section-8.2), and after tha= t can synthesize AAAAs as needed (DNS64 in done in the client) while gettin= g validated answers for other things as desired. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Jul 28 14:44:57 2015 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 B95C51B31A1 for ; Tue, 28 Jul 2015 14:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.6 X-Spam-Level: X-Spam-Status: No, score=-4.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 0VEgjpDSeSr4 for ; Tue, 28 Jul 2015 14:44:54 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 560011B2AB8 for ; Tue, 28 Jul 2015 14:44:52 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1ZKCg7-0000CdC; Tue, 28 Jul 2015 23:44:51 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <55B09AE5.4040609@gmail.com> <2BBE839B-37FB-4EA2-982E-58028E7A13B6@nominum.com> <55B0F344.4090005@gmail.com> <88CAA5385EB5404392BF93106C8C53F89636B43DE3@HE111507.emea1.cds.t-internal.com> In-reply-to: Your message of "Tue, 28 Jul 2015 21:58:12 +0200 ." <88CAA5385EB5404392BF93106C8C53F89636B43DE3@HE111507.emea1.cds.t-internal.com> Date: Tue, 28 Jul 2015 23:44:51 +0200 Archived-At: Subject: Re: [v6ops] NAT64/DNS64 and DNSSEC 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, 28 Jul 2015 21:44:56 -0000 In your letter dated Tue, 28 Jul 2015 21:58:12 +0200 you wrote: > but isn't there a gap that when performing the RFC7050 64pref > detection by querying ipv6only.arpa, an attacker can spoof this > answer (DNSSEC won't work here, for example, the attacker - when > between the client and the DNS - can return for example > 2001:db8::192.0.0.170 (where 2001:db8:: is a prefix owned by the > attacker)) and then attract all IPv4 traffic from the victim? > > Nevertheless, an answer to the proliferation of DNSSEC and at the > same time increasing usage of DNS64/NAT has to be found, not to > stop the success of one or the other. Yes, that seems to be a very tricky problem. One option is perform local translation only for 64:ff9b::/96. This would force operators to use the well known prefix, but it has to advantage that the prefix can be filtered at the border of each network. And an attacker will be quite visible trying to get this traffic by manipulating routing protocols. A second approach is for the network to signal that there is no IPv4 present. For example, by not including a default route in DHCPv4 or otherwise signaling in DHCPv4 that there is no IPv4. In this case, if there is a valid IPv4 config, the library can refuse to perform the synthesis. This would leave all dual stack networks unaffected. Performing the AAAA lookup on ipv4only.arpa over tcp would require the attacker to be on the path to the resolver. An alternative to requiring 64:ff9b::/96, would be to insist that the NAT64 gateway and the DNS64 are in the same /48. That would require an attacker to spoof DNS resolvers in RAs or DHCPv6, in which case all bets are off. Ultimately, this only affects DNSSEC signed IPv4-only targets. The obvious solution is that if those sites care about security, they should add a AAAA. From nobody Tue Jul 28 14:49:52 2015 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 843AB1B3249 for ; Tue, 28 Jul 2015 14:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.749 X-Spam-Level: X-Spam-Status: No, score=-3.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, 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 ugn2TxexKbuX for ; Tue, 28 Jul 2015 14:49:49 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::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 3BA151B3248 for ; Tue, 28 Jul 2015 14:49:49 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so175455495wib.0 for ; Tue, 28 Jul 2015 14:49:48 -0700 (PDT) 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=/zwvDhvg6tCPh0XdQqx2y+rFPUmdRYeZsRDen3w+GOk=; b=eq/dkO9J8a9vxde+CqdGacJCAUSt1ZOCE407BXC7fSwWXfdWeobFWWN6PyQaFC8RmR F7GbIfF9riBP4QKlDN1GC9eQbS5sspDaKXdUEqDKEAxYCJH1Yz3FikMFeCUmdwLxDnoQ QfuADOqriu8FmsnA40YD1dS/A8S9x9HEikdOD1cZ37SXIQQNYUM6j9CfUH9XEteJMoir gCFPxSACIa9ilTPVfyBAe6wHZas1n3VhO5IOtcvBcJznp2rYr+YsezRfFWMhoL0vLgxt 2+pQdMcABdHMBP5nTjWctZSo4oA4p6Q+1Uo6sFK7hpc7P0MiJLjclg0xh+nknc8ZI6VD AfrQ== MIME-Version: 1.0 X-Received: by 10.180.109.136 with SMTP id hs8mr11020884wib.73.1438120188031; Tue, 28 Jul 2015 14:49:48 -0700 (PDT) Received: by 10.194.191.232 with HTTP; Tue, 28 Jul 2015 14:49:47 -0700 (PDT) In-Reply-To: References: <55B09AE5.4040609@gmail.com> <2BBE839B-37FB-4EA2-982E-58028E7A13B6@nominum.com> <55B0F344.4090005@gmail.com> <88CAA5385EB5404392BF93106C8C53F89636B43DE3@HE111507.emea1.cds.t-internal.com> Date: Tue, 28 Jul 2015 14:49:47 -0700 Message-ID: From: Ca By To: Philip Homburg Content-Type: multipart/alternative; boundary=e89a8f234557f3b86b051bf672bd Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] NAT64/DNS64 and DNSSEC 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, 28 Jul 2015 21:49:51 -0000 --e89a8f234557f3b86b051bf672bd Content-Type: text/plain; charset=UTF-8 On Tuesday, July 28, 2015, Philip Homburg wrote: > In your letter dated Tue, 28 Jul 2015 21:58:12 +0200 you wrote: > > but isn't there a gap that when performing the RFC7050 64pref > > detection by querying ipv6only.arpa, an attacker can spoof this > > answer (DNSSEC won't work here, for example, the attacker - when > > between the client and the DNS - can return for example > > 2001:db8::192.0.0.170 (where 2001:db8:: is a prefix owned by the > > attacker)) and then attract all IPv4 traffic from the victim? > > > > Nevertheless, an answer to the proliferation of DNSSEC and at the > > same time increasing usage of DNS64/NAT has to be found, not to > > stop the success of one or the other. > > Yes, that seems to be a very tricky problem. > > One option is perform local translation only for 64:ff9b::/96. This would > force operators to use the well known prefix, but it has to advantage that > the prefix can be filtered at the border of each network. And an attacker > will be quite visible trying to get this traffic by manipulating routing > protocols. > > A second approach is for the network to signal that there is no IPv4 > present. > For example, by not including a default route in DHCPv4 or otherwise > signaling > in DHCPv4 that there is no IPv4. > > In this case, if there is a valid IPv4 config, the library can refuse to > perform the synthesis. This would leave all dual stack networks unaffected. > > Performing the AAAA lookup on ipv4only.arpa over tcp would require > the attacker to be on the path to the resolver. > > An alternative to requiring 64:ff9b::/96, would be to insist that the > NAT64 gateway and the DNS64 are in the same /48. That would require an > attacker to spoof DNS resolvers in RAs or DHCPv6, in which case all bets > are off. > > Ultimately, this only affects DNSSEC signed IPv4-only targets. The obvious > solution is that if those sites care about security, they should add a > AAAA. > > +1 This is just another way that ipv4 is too broken to use and will not be fixed. BCP = use native ipv6 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --e89a8f234557f3b86b051bf672bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tuesday, July 28, 2015, Philip Homburg <pch-v6ops-3@u-1.phicoh.com> wrote:
In your letter dated Tue, 28 Jul 2015 21:58:12 +0= 200 you wrote:
> but isn't there a gap that when performing the RFC7050 64pref
> detection by querying ipv6only.arpa, an attacker can spoof this
> answer (DNSSEC won't work here, for example, the attacker - when > between the client and the DNS - can return for example
> 2001:db8::192.0.0.170 (where 2001:db8:: is a prefix owned by the
> attacker)) and then attract all IPv4 traffic from the victim?
>
> Nevertheless, an answer to the proliferation of DNSSEC and at the
> same time increasing usage of DNS64/NAT has to be found, not to
> stop the success of one or the other.

Yes, that seems to be a very tricky problem.

One option is perform local translation only for 64:ff9b::/96. This would force operators to use the well known prefix, but it has to advantage that<= br> the prefix can be filtered at the border of each network. And an attacker will be quite visible trying to get this traffic by manipulating routing protocols.

A second approach is for the network to signal that there is no IPv4 presen= t.
For example, by not including a default route in DHCPv4 or otherwise signal= ing
in DHCPv4 that there is no IPv4.

In this case, if there is a valid IPv4 config, the library can refuse to perform the synthesis. This would leave all dual stack networks unaffected.=

Performing the AAAA lookup on ipv4only.arpa over tcp would require
the attacker to be on the path to the resolver.

An alternative to requiring 64:ff9b::/96, would be to insist that the
NAT64 gateway and the DNS64 are in the same /48. That would require an
attacker to spoof DNS resolvers in RAs or DHCPv6, in which case all bets are off.

Ultimately, this only affects DNSSEC signed IPv4-only targets. The obvious<= br> solution is that if those sites care about security, they should add a AAAA= .


+1

This is ju= st another way that ipv4 is too broken to use and will not be fixed.=C2=A0<= /div>

BCP =3D use native ipv6
=C2=A0
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops
--e89a8f234557f3b86b051bf672bd-- From nobody Tue Jul 28 18:44:49 2015 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 B968A1B34B7 for ; Tue, 28 Jul 2015 18:44:39 -0700 (PDT) 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, 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 4gEN0jz3Ht1k for ; Tue, 28 Jul 2015 18:44:38 -0700 (PDT) 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 70A751B3364 for ; Tue, 28 Jul 2015 18:44:38 -0700 (PDT) Received: by ioii16 with SMTP id i16so6479451ioi.0 for ; Tue, 28 Jul 2015 18:44:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=021Up6XNaItYgo7dRg/r1n/YT12F1krY9707KGbnxMo=; b=gIYLmjLu5AFQ1BZMuCmihm+MLAYJH0pyjAq4E2JxpBJLkR2bpIkuJWghKn+7DVxUrC Npm1MF+U3+FVo78QpXARv4XzlDVEKf0R+2JVYznkrCHbFpuecCQmbK6eOp1kIe2hPxPt CEd0HSo6sz9xlQw1JA6e15N+5DHDUZQzZJKVVeS3JQ6BLAmFLsCnBP+qDzdfzIfDywty 0vnJF0SbSSQrGHSkYxwdajMAQ/rkLi7Dsr28oTdAAzmqNKMtHJyuq13nmLbUmRurKHzs RqC6UY1lVnzdDYgfMbyDtVvpn5x8V+J98eZF0lPrv24amFyUX/n5wi0H/p/QT9mImM0v 2dkQ== X-Received: by 10.107.18.28 with SMTP id a28mr64241368ioj.106.1438134277857; Tue, 28 Jul 2015 18:44:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.169.143 with HTTP; Tue, 28 Jul 2015 18:44:08 -0700 (PDT) In-Reply-To: References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> <55B1ED14.6030501@gmail.com> <20150727091241.GL84167@Space.Net> <20150728115944.GZ84167@Space.Net> From: Mark Smith Date: Wed, 29 Jul 2015 11:44:08 +1000 Message-ID: To: Ted Lemon Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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: Wed, 29 Jul 2015 01:44:39 -0000 Hi Ted, On 29 July 2015 at 00:27, Ted Lemon wrote: > Having read the document, it seems a bit pie in the sky. The idea that = subdividing a prefix will give users privacy is nonsensical: if it is well = known that ISP X provides a /48 to every home, then people will assume that= all hosts in any given /48 in that ISP=E2=80=99s allocation will belong to= the same person or same household. > > Given that, then if there is some performance reason for clustering multi= ple address assignments to the same host, the way to do it is to delegate a= /120 to that host, and have a route to that /120 that points to that host.= If the host needs more than 256 addresses, delegate something bigger, or= delegate multiple /120s. > > This is really easy to do. It doesn=E2=80=99t give you a ton of privacy= , but I don=E2=80=99t think it gives you less privacy than delegating a /64= , and in some sense it gives you more because now you can do multiple alloc= ations and still get the efficiency of address clustering, and the snooper = doesn=E2=80=99t have as much information about address allocation patterns. > > And if you don=E2=80=99t want to do DHCPv6-PD, then SLAAC is actually ide= al for this application, because you can in principle use a random number g= enerator to produce the host part of the address, and just generate a bunch= of random numbers with entropy so that a snooper can=E2=80=99t predict whi= ch addresses will be held in common by the same host. > > But I still really don=E2=80=99t see the point of this. > I think to avoid recommendations like this IPv6 setup for containers, e.g. specifying to use Neighbor Discovery Proxying and /80 prefix lengths. https://docs.docker.com/articles/networking/#ipv6 (As a side note, some discussion in the ID about whether containers should be treated as hosts, and whether containers should then be assigned /64s might be useful. I think an argument could be made that containers are hosts, however given how light weight they are, and therefore how many people might have, a /64 for each one might be excessive.) Regards, Mark. From nobody Tue Jul 28 19:01:36 2015 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 B5BBA1A1A12 for ; Tue, 28 Jul 2015 19:01:34 -0700 (PDT) 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 EIXdcj-4jT20 for ; Tue, 28 Jul 2015 19:01:33 -0700 (PDT) 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 98B641A0155 for ; Tue, 28 Jul 2015 19:01:33 -0700 (PDT) Received: by ykba194 with SMTP id a194so8817819ykb.0 for ; Tue, 28 Jul 2015 19:01:33 -0700 (PDT) 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=M7OyS/j5N1Xq+4WcTP43DV7pIx8DFAGEWOFWCfZ0goc=; b=d9Z1aK0P6cPjP0tJZh8/zqzzwJ2iSKXHmKaIaxDJvwyYn1UJJ2MNTJx7hNQAwjgZ0N P5fujjLG74Pl/gaj1MR7Pe7PHpqMrCF8cLe5EfysqkPEsstbIwxvH2JKmQspsmjruQM6 GtBX1gzzQKrWjV/j25JyCbEWh0YxDAUupKenXG39g0bzCWxK01xdwynTSA+cyt/WZXPm 3n2rPSh5QIMoSGJ9TWVrCc1RZtRXe20aiRmiuCbFD1q7yst7fDMIe/w+kFCdpyB160qE CbinU0+T4xbBiT695YF6aMKudBQHbD/eo/nLeqs2c03B4Zh9UrlFjbgninmZo++eD8Xf lOpg== 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=M7OyS/j5N1Xq+4WcTP43DV7pIx8DFAGEWOFWCfZ0goc=; b=XQMwFM54GPZIXF7qTbvxI6xGtdSGroGQNNxcC9TC/mUJdrCH4mylbR4WYPQwoxXvR1 e2yphOjC2Bc9kxoQKpSR3NOJ/I6wE+kpBp14RrzS+EyTjlomDdOxwf1iA1sM0xGAQaFE J0WCUSuMxVGAZioAZ6yzop607HDAyK4Xob0QZubX1woZPW1cbmpJXfHmrrgOf3Yz0Wnr jT7uybyMLhbjkTbYRxdM4eBmt/BIoLeEvExQRfExRp4foNarRfag+6CWpNVXI/MQOp01 4ZmY+8qIcaQgf1ZOwL9D5GI1u9eZW/vLYbpvNX2yS2eLH+QUwIyDG9HEV5560/1gZDou MyxA== X-Gm-Message-State: ALoCoQn225l7mzxOXaQ6xlnZD0o+nWsVU8+DZbCcZHMAU/iQ1z7Gr3KhYsSaX5hvqi6iSjmhzgUz X-Received: by 10.170.153.85 with SMTP id u82mr29589185ykc.53.1438135292837; Tue, 28 Jul 2015 19:01:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.8.201 with HTTP; Tue, 28 Jul 2015 19:01:13 -0700 (PDT) In-Reply-To: <90E6B48E-B3FC-4AAD-B356-7D92A2777632@nominum.com> References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> <55B1ED14.6030501@gmail.com> <20150727091241.GL84167@Space.Net> <20150728115944.GZ84167@Space.Net> <4AB2ED61-23CF-40D5-B2A6-F1F4064EC0C6@nominum.com> <90E6B48E-B3FC-4AAD-B356-7D92A2777632@nominum.com> From: Lorenzo Colitti Date: Wed, 29 Jul 2015 11:01:13 +0900 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=001a113b396e4540fa051bf9f760 Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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: Wed, 29 Jul 2015 02:01:34 -0000 --001a113b396e4540fa051bf9f760 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jul 29, 2015 at 2:51 AM, Ted Lemon wrote: > So you want the device to be able to use DHCPv6-PD on the upstream, but > support SLAAC on the downstream. So this really isn=E2=80=99t a general > mechanism: it=E2=80=99s for the smartphone router use case specifically. > Or for laptops that want to run VMs. Or for future protocols that need more space, or for applications that want per-application IP-addresses. Or anything else. What this gives you is that on a network that has tracking requirements that require the use of DHCPv6, then DHCPv6 can be used all the way to "where the buck stops", i.e., all the way to the end user of the network. The end user can then use other mechanisms, such as SLAAC or bridging, to extend the network. There are 256 times as many /40s as IPv4 addresses. That=E2=80=99s a _rea= lly_ > small number unless you see the Internet growth curve flattening out, and > your draft suggests that you don't. > The draft only recommends using DHCPv6 PD on if the network "requires explicit requests for address space". That rules out anything running SLAAC, which is supported by the vast majority of IPv6 deployments today. If you want the draft to recommend that networks should not require explicit requests for address space, then it can do that. --001a113b396e4540fa051bf9f760 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 29, 2015 at 2:51 AM, Ted Lemon <ted.lemon@nominum.com><= /span> wrote:
So you want the device to be able to use DHCPv6-PD on the ups= tream, but support SLAAC on the downstream. =C2=A0 So this really isn=E2=80= =99t a general mechanism: it=E2=80=99s for the smartphone router use case s= pecifically.

Or for laptops tha= t want to run VMs. Or for future protocols that need more space, or for app= lications that want per-application IP-addresses. Or anything else.

What this gives you is that on a network that has trackin= g requirements that require the use of DHCPv6, then DHCPv6 can be used all = the way to "where the buck stops", i.e., all the way to the end u= ser of the network. The end user can then use other mechanisms, such as SLA= AC or bridging, to extend the network.

There are 256 times= as many /40s as IPv4 addresses. =C2=A0 That=E2=80=99s a _really_ small num= ber unless you see the Internet growth curve flattening out, and your draft= suggests that you don't.

T= he draft only recommends using DHCPv6 PD on if the network "requires e= xplicit requests for address space". That rules out anything running S= LAAC, which is supported by the vast majority of IPv6 deployments today. If= you want the draft to recommend that networks should not require explicit = requests for address space, then it can do that.
--001a113b396e4540fa051bf9f760-- From nobody Tue Jul 28 19:07:58 2015 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 972C91A87C2 for ; Tue, 28 Jul 2015 19:07:57 -0700 (PDT) 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, 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 RA-o75sqeA1d for ; Tue, 28 Jul 2015 19:07:56 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::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 A71061AC44E for ; Tue, 28 Jul 2015 19:07:51 -0700 (PDT) Received: by ioeg141 with SMTP id g141so6962946ioe.3 for ; Tue, 28 Jul 2015 19:07:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=wjw0gDhkn+75GAZX5iDbR3eNb4P4QU5g5DzvWdmiARo=; b=BeaAmLSMSWlFwydkN5uW2Odhcgq4E8ALoqGQomZGy4F0KPLtrzMIQcW7vr/YruzEuv vG05WoTAv/JNks3rZP9k/YQM5VZEwbr3xiqv7EzEmba2wIhunSnvnDEmeHQunJqHxW9w ta/XbM90jV7snC5LwU0L2W+wYv7lk9syedIEF5eL52XUCuy2uJc6WuwGcu0iUrcq7KWQ 4tY/ACA1c0MrhZ3UiJRvaWAhWOc21D8Prz3aFmo8W2HssMehFxLwPBehm9LtWNKlaYtT LyrAa20KS78RPbS4A+mcRvZxqttu2p+LBtOJxrOicDUS++9PYsRXN2tPrIFiOqaNKove Q4yw== X-Received: by 10.107.29.209 with SMTP id d200mr60453688iod.94.1438135671055; Tue, 28 Jul 2015 19:07:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.169.143 with HTTP; Tue, 28 Jul 2015 19:07:21 -0700 (PDT) In-Reply-To: References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> <55B1ED14.6030501@gmail.com> <20150727091241.GL84167@Space.Net> <20150728115944.GZ84167@Space.Net> <4AB2ED61-23CF-40D5-B2A6-F1F4064EC0C6@nominum.com> From: Mark Smith Date: Wed, 29 Jul 2015 12:07:21 +1000 Message-ID: To: Lorenzo Colitti Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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: Wed, 29 Jul 2015 02:07:57 -0000 On 29 July 2015 at 02:51, Lorenzo Colitti wrote: > On Wed, Jul 29, 2015 at 1:28 AM, Ted Lemon wrote: >> >> Do you buy my theory about just using a /120 to aggregate a bunch of >> addresses, or no? > > > Well but if if you give a laptop or a device a /120, what is it going to > give its downstream devices / VMs when sharing its internet connection with > them? Does it have to implement a stateful DHCPv6 server and force its > downstream devices/VMs to use it? At that point, the network it offered > would be violating recommendations made in the draft. > For a laptop style scenario, i.e., numbers of VMs in likely low 1s or no more than 10 to 15, I'd think bridging them onto the existing ethernet network is easier because it is using existing and operating SLAAC, DHCP etc. That has been my experience on the few occasions I've run up a VM or two. It also has the advantage that it doesn't require anything special from the upstream network that you might not be an operator of. I think that means there is a threshold, below which bridging is most efficient, above which routing via a DHCPv6-PD delegated prefixes is most efficient. Regards, Mark. From nobody Tue Jul 28 19:36:35 2015 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 1584D1B2CA6 for ; Tue, 28 Jul 2015 19:36:34 -0700 (PDT) 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 8w-CDjTgP1lL for ; Tue, 28 Jul 2015 19:36:33 -0700 (PDT) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::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 BFF481A1B7B for ; Tue, 28 Jul 2015 19:36:32 -0700 (PDT) Received: by ykba194 with SMTP id a194so9333658ykb.0 for ; Tue, 28 Jul 2015 19:36:32 -0700 (PDT) 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=RJHKOGmVC4Cp3IpkR7EWMtunL0P/gJZ1/Z2LHWEKPYA=; b=WZFirrG8SU3xuKe0gjpMwanyBOalSpXRdjMBAz8VIY7mRYAA2KDmeCRanlsU7dzHHY tjp7fFUiw8C8XEC1xwpHO4W8tgrZH41Cgrt3B8be2vW593KWAINdhZxx4GPIvMRlV87h n0uClLtPPYhQosjPARnjvBQly+ciRokdjFczo5JpXVa5Icv5Ar1K1Ntd5gEjrrR5Cd+i cwVHf9p7/gPJ9iH9MJLXnLvVgDvnYNi2hlC/Tb0gkhOqtYuqfQZxQ2ZA8/stcori9ndr UXq9LmUcH4pmxPMok8cKFf4fLaF2mPqSBTyycRsHFN6UqN5bBqlo1nU5qKEm3CVW0Muj mGJA== 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=RJHKOGmVC4Cp3IpkR7EWMtunL0P/gJZ1/Z2LHWEKPYA=; b=a/3+WnxzKne4ZQL4KTBT5qNj7TQ6JZaEJLnhhGyNx+pId8gR7jpC3NXKk5KZlH2Zry zYmS744fu409pyDaxHyLMAX56NrhpDxIuoxf8jnZPwcbLKqXw2buyu6kjlptcD5+8D5V effD82bKw7i+cTvLmRh9b0sjz0uqRqJj2tRX+tB53jeNo7wVUgD+ZS0+qwZAXF9C+7YD DtB500Hy7tBgF788SnuCmghiopRTEQVSg59aiq5xEF2arTHN7gYA/X7cneEucXXbVuqC G7AS9R2mc1nmqZ2L7QHVZg5O8YTDTkRLNj+Qv4xhGOhRGcrAi4u+7JLd21XdVMpegmTo OrGQ== X-Gm-Message-State: ALoCoQlvl+NW3O/k6yW/JPnXryZ5e6tC14mJ3dtRXq3sQBTzcgxeKu/0+7/eU8bDEtd2ubAiOMJ5 X-Received: by 10.129.75.214 with SMTP id y205mr42552455ywa.65.1438137392024; Tue, 28 Jul 2015 19:36:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.8.201 with HTTP; Tue, 28 Jul 2015 19:36:12 -0700 (PDT) In-Reply-To: References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> <55B1ED14.6030501@gmail.com> <20150727091241.GL84167@Space.Net> <20150728115944.GZ84167@Space.Net> <4AB2ED61-23CF-40D5-B2A6-F1F4064EC0C6@nominum.com> From: Lorenzo Colitti Date: Wed, 29 Jul 2015 11:36:12 +0900 Message-ID: To: Mark Smith Content-Type: multipart/alternative; boundary=001a113f3d0a643c49051bfa7419 Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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: Wed, 29 Jul 2015 02:36:34 -0000 --001a113f3d0a643c49051bfa7419 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 29, 2015 at 11:07 AM, Mark Smith wrote: > For a laptop style scenario, i.e., numbers of VMs in likely low 1s or > no more than 10 to 15, I'd think bridging them onto the existing > ethernet network is easier because it is using existing and operating > SLAAC, DHCP etc. It is easier, but it will not work on a network that only supports DHCPv6 and assigns only one IPv6 address per MAC address or per wifi association. --001a113f3d0a643c49051bfa7419 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 29, 2015 at 11:07 AM, Mark Smith <markzzzsmith@gmail.com&= gt; wrote:
For a laptop style scen= ario, i.e., numbers of VMs in likely low 1s or
no more than 10 to 15, I'd think bridging them onto the existing
ethernet network is easier because it is using existing and operating
SLAAC, DHCP etc.

It is easier, but it will = not work on a network that only supports DHCPv6 and assigns only one IPv6 a= ddress per MAC address or per wifi association.
--001a113f3d0a643c49051bfa7419-- From nobody Tue Jul 28 20:00:06 2015 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 065BA1B353D for ; Tue, 28 Jul 2015 20:00:05 -0700 (PDT) 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 u83ByoyaqApF for ; Tue, 28 Jul 2015 20:00:03 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D76731B3535 for ; Tue, 28 Jul 2015 20:00:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1624; q=dns/txt; s=iport; t=1438138802; x=1439348402; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=/Vh/ogmh3oubzFivGgSReGtBJgLWWV8ZPHOxDWrjcOQ=; b=lO0C5BcadQFeRVrZZpCtcNeePygO+6VkjxkiwRgmOQkgnxBVon8K/NAi x9ss/cfFfgng2h3utj5afS/gcSCapyTD7Xc5h0egA5HqtPMuPtJ0+dVp8 JY5i1q5nABZ4DTyZPR6orlegesXu7R5vmkAfV+t4WvN8AAzbtLkRsvnlH w=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AgAwDbQLhV/5JdJa1bgxWBPQa8NQmHegKBTzgUAQEBAQEBAYEKhCMBAQEDAXkFCwIBCA4KLjIlAgQOBQ6IGAjPMgEBAQEBAQEBAQEBAQEBAQEBAQEBAReLToUHB4MYgRQBBJRoAYI3gViIMpMuhX0mZIMZb4FIgQQBAQE X-IronPort-AV: E=Sophos;i="5.15,568,1432598400"; d="asc'?scan'208";a="13943966" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-7.cisco.com with ESMTP; 29 Jul 2015 03:00:02 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t6T302Pj024667 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Jul 2015 03:00:02 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.49]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Tue, 28 Jul 2015 22:00:01 -0500 From: "Fred Baker (fred)" To: Mikael Abrahamsson Thread-Topic: [v6ops] NAT64/DNS64 and DNSSEC Thread-Index: AQHQyaqpV8aF2KHpOEG3XvnwKN9v8g== Date: Wed, 29 Jul 2015 03:00:01 +0000 Message-ID: <4797B33E-9851-427E-8710-84122AFD0FFA@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.24.116.172] Content-Type: multipart/signed; boundary="Apple-Mail=_9F69F2B5-1FF9-474D-BE07-28C3F925C684"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] NAT64/DNS64 and DNSSEC 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, 29 Jul 2015 03:00:05 -0000 --Apple-Mail=_9F69F2B5-1FF9-474D-BE07-28C3F925C684 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jul 23, 2015, at 12:13 AM, Mikael Abrahamsson = wrote: >=20 > I really care about DNSSEC and I don't want this to be broken for a = prolonged amount of time just because people are doing NAT64+DNS64. Between us girls, I don't think many of us really like NAT64... --Apple-Mail=_9F69F2B5-1FF9-474D-BE07-28C3F925C684 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 iQIVAwUBVbhBr0ayAOS/EQ8MAQLU6A/7BbPbmcjAg4YahxKcFygAWAsQmF+LiSsr RKhFzwe6civ43I/511d//cIZs2JA2usNEslS+bvLR1M5qlrxIXqiDpYOotXRbg1k 4xsGGXaTcV8eFNqZ7LArushWHJb3usKzl+5gQznOBlL22K4cJs6ZeyGspDa4SG9b Yc1oVwjBqF97Ts5YtIyE4yLDXxNGwDBjroz7WBGppjLlnVtPiruNn/sBb7Azj8Gl efgLw5ZTTTcN44Re6p9m4IsGJuTXBWlkRf/E5RHL1PP1FOs7TVt7nHWvtJkgRkRV oxNpr5KXnLreNn8L8p3d/wgU95DnmmuHAs+OyV+OlY6yLOayngQ/Mq2en7xzwWDl HLtBB55GMV5kAAPvLrNsAan+AMuz5RoYo5SF+azJt7J/U/c2zUiu6EJ1H9+gbj0G 3Une9OYtdqW7ySd3sMCvMB8antVQuk0xM10UtxIDfae3B1sFjzYu4yuE+49eP6lc KAPKfpXeSw54nlveydMcjwEobzKCdXTbrCbBLyCx+/pH0pEUWbI76Nnb+fW8wTUi RK9At9TnGsj2S7/O1+RHPoD69FVcJpGj0he4aXiN4DOwnT81UDOpgFKoIZ7Q9LF5 3BqNIK0C9OWXgXoB4QQxlMs8yiPyM3SzelOh6R0mAWzxBUdmPHCNhh0kQ5S8Nzua IoJBMJr1Dzc= =EoWo -----END PGP SIGNATURE----- --Apple-Mail=_9F69F2B5-1FF9-474D-BE07-28C3F925C684-- From nobody Tue Jul 28 20:12:15 2015 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 4F1111A6EE7 for ; Tue, 28 Jul 2015 20:12:13 -0700 (PDT) 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, 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 6jECT3uNtr5o for ; Tue, 28 Jul 2015 20:12:12 -0700 (PDT) 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 0F7EA1A6EE4 for ; Tue, 28 Jul 2015 20:12:12 -0700 (PDT) Received: by igk11 with SMTP id 11so128494635igk.1 for ; Tue, 28 Jul 2015 20:12:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=mwkIqq7g04kFsxoGp0GFOLYlVimnmCcy5PvPm84orKA=; b=ymxCKZ0Yk2uz4hbV5ZE2Bw3nS+GrD4tHpE2MxASbGom3Gh214SLblB+SKgj+jwZZjl 6UrfzwSLEqyvsh/dUXQ8Lwqo6am3aujPq0PG80G5mfZko0YIPd6Cw+ZPyBF4uL6PGfWv iOE6OiCyfSDEDtnhJxMrwmyOLLts4vmnuQDuZkJYu9RGfH9pSY76LwgKukXJNsBqj2Dt jnuxHdyy30hQFBRBk6RmVe2Ugub2dnQe6bqx8nXwPtQU3AWy1BCvy5PbLFKbHF7TFpaI XM3gFe+eQDCMNi3SeCwZdslpfxbJfTfmc1B+A+Qcg0QUQip+vZQQDFhnE9A7fWjW8E5/ HfSA== X-Received: by 10.50.36.106 with SMTP id p10mr1268459igj.31.1438139531523; Tue, 28 Jul 2015 20:12:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.169.143 with HTTP; Tue, 28 Jul 2015 20:11:41 -0700 (PDT) In-Reply-To: References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> <55B1ED14.6030501@gmail.com> <20150727091241.GL84167@Space.Net> <20150728115944.GZ84167@Space.Net> <4AB2ED61-23CF-40D5-B2A6-F1F4064EC0C6@nominum.com> From: Mark Smith Date: Wed, 29 Jul 2015 13:11:41 +1000 Message-ID: To: Lorenzo Colitti Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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: Wed, 29 Jul 2015 03:12:13 -0000 On 29 July 2015 at 12:36, Lorenzo Colitti wrote: > On Wed, Jul 29, 2015 at 11:07 AM, Mark Smith wrote: >> >> For a laptop style scenario, i.e., numbers of VMs in likely low 1s or >> no more than 10 to 15, I'd think bridging them onto the existing >> ethernet network is easier because it is using existing and operating >> SLAAC, DHCP etc. > > > It is easier, but it will not work on a network that only supports DHCPv6 > and assigns only one IPv6 address per MAC address or per wifi association. So while not quite as easy to configure as bridging pure bridging, Linux supports creating virtual ethernet interfaces ("macvlan" interfaces) that have different MAC addresses, so you could use those to get more than one address per host, but I get your point. btw, Fred Baker wrote up a draft a while back which might be useful to have a read of or reference. He pointed out that multi-homing doesn't require multiple physical interfaces, so in that sense, what is being described in this ID is making hosts multi-homed or "more multi-homed". "Happier Eyeballs" https://tools.ietf.org/html/draft-baker-happier-eyeballs-00 Regards, Mark. From nobody Tue Jul 28 21:54:57 2015 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 094D21A1B07 for ; Tue, 28 Jul 2015 21:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 HzD-eI8zYc6u for ; Tue, 28 Jul 2015 21:54:52 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (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 BC0341A000D for ; Tue, 28 Jul 2015 21:54:52 -0700 (PDT) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 44F71DA0089; Wed, 29 Jul 2015 04:54:52 +0000 (UTC) Received: from [10.0.20.178] (71.233.41.235) by CAS-03.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 28 Jul 2015 21:54:51 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_FC60FF6F-A1F0-4A41-8060-791104435BD2" MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ted Lemon In-Reply-To: Date: Wed, 29 Jul 2015 00:54:50 -0400 Message-ID: <66040967-4EB3-424D-B21D-9C0CC489A5D6@nominum.com> References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> <55B1ED14.6030501@gmail.com> <20150727091241.GL84167@Space.Net> <20150728115944.GZ84167@Space.Net> <4AB2ED61-23CF-40D5-B2A6-F1F4064EC0C6@nominum.com> <90E6B48E-B3FC-4AAD-B356-7D92A2777632@nominum.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.2102) X-Originating-IP: [71.233.41.235] Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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: Wed, 29 Jul 2015 04:54:55 -0000 --Apple-Mail=_FC60FF6F-A1F0-4A41-8060-791104435BD2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Jul 28, 2015, at 10:01 PM, Lorenzo Colitti = wrote: > Or for laptops that want to run VMs. Or for future protocols that need = more space, or for applications that want per-application IP-addresses. = Or anything else. Laptop VMs will have DHCP clients, so there=E2=80=99s no reason not to = use DHCP. Only Android doesn=E2=80=99t have a DHCP client. > What this gives you is that on a network that has tracking = requirements that require the use of DHCPv6, then DHCPv6 can be used all = the way to "where the buck stops", i.e., all the way to the end user of = the network. The end user can then use other mechanisms, such as SLAAC = or bridging, to extend the network. Sure. The mobile router use case. > There are 256 times as many /40s as IPv4 addresses. That=E2=80=99s a = _really_ small number unless you see the Internet growth curve = flattening out, and your draft suggests that you don't. >=20 > The draft only recommends using DHCPv6 PD on if the network "requires = explicit requests for address space". That rules out anything running = SLAAC, which is supported by the vast majority of IPv6 deployments = today. If you want the draft to recommend that networks should not = require explicit requests for address space, then it can do that. I do not see how your response connects to what I said. Either we can = afford for every host to have a /64, or we can=E2=80=99t. If we = can=E2=80=99t, then we shouldn=E2=80=99t be delegating /64s to hosts. = Also, if sharing addresses from the same /64 on multiple links works in = your SLAAC use case, it=E2=80=99s a bit of a stretch to claim that you = need to do something drastically different in the DHCP use case. --Apple-Mail=_FC60FF6F-A1F0-4A41-8060-791104435BD2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" On Jul 28, 2015, at 10:01 PM, Lorenzo Colitti <lorenzo@google.com> = wrote:
Or for laptops that = want to run VMs. Or for future protocols that need more space, or for = applications that want per-application IP-addresses. Or anything = else.

Laptop VMs will = have DHCP clients, so there=E2=80=99s no reason not to use DHCP.   = Only Android doesn=E2=80=99t have a DHCP client.

What this gives you is = that on a network that has tracking requirements that require the use of = DHCPv6, then DHCPv6 can be used all the way to "where the buck stops", = i.e., all the way to the end user of the network. The end user can then = use other mechanisms, such as SLAAC or bridging, to extend the = network.

Sure.   = The mobile router use case.

There are 256 times as many /40s = as IPv4 addresses.   That=E2=80=99s a _really_ small number unless = you see the Internet growth curve flattening out, and your draft = suggests that you don't.

The draft only = recommends using DHCPv6 PD on if the network "requires explicit requests = for address space". That rules out anything running SLAAC, which is = supported by the vast majority of IPv6 deployments today. If you want = the draft to recommend that networks should not require explicit = requests for address space, then it can do = that.

I do = not see how your response connects to what I said.   Either we can = afford for every host to have a /64, or we can=E2=80=99t.   If we = can=E2=80=99t, then we shouldn=E2=80=99t be delegating /64s to hosts. =   Also, if sharing addresses from the same /64 on multiple links = works in your SLAAC use case, it=E2=80=99s a bit of a stretch to claim = that you need to do something drastically different in the DHCP use = case.

= --Apple-Mail=_FC60FF6F-A1F0-4A41-8060-791104435BD2-- From nobody Tue Jul 28 22:26:22 2015 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 D7F051A1DBC for ; Tue, 28 Jul 2015 22:26:20 -0700 (PDT) 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 xJKCGAlcBuph for ; Tue, 28 Jul 2015 22:26:19 -0700 (PDT) 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 605471A1C06 for ; Tue, 28 Jul 2015 22:26:19 -0700 (PDT) Received: by ykdu72 with SMTP id u72so114387821ykd.2 for ; Tue, 28 Jul 2015 22:26:18 -0700 (PDT) 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=z5ewHbkEmD3D1BbAyKqAnMrujKuDv0pnNYnWVIivVuU=; b=g//9qz0d5M0Bn6aReRMfr4fn/tzR8mB+TdXDD60GHf7hxmMT27Rqul6GZ4s5vo7PtE zRs0f6F6PTLX5Upl2n7+fd25Z7EpiGB60p/XRpLZZq3GBlNtYOy8/rBeNXA40da7jX8Q AtcaeYPYDC5jxgSe4XlPz3JEFqZU/lGPKFQV/uD2kSAIeYUErTiSD/qCfFjxfY6fvAoL Q+DaKvxZ878T5GqFU89pGlq6Y1xLO9tWrd/jap1koaVmAhCjYrXl3wDuxujeWXsi45TN Ts8Knz+T53u+iPYrkkTr8toBAnmDheKBaeMgfd3dFvCtU/lR0w4OU36fFub0hNZKKcVU 7GQQ== 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=z5ewHbkEmD3D1BbAyKqAnMrujKuDv0pnNYnWVIivVuU=; b=BW11v6kDm49OAI+0O9Ir7yEFHv1SvLYY00gOGYwoeWS5dLJ5M046NChOhjy3PQCK4t 5fgiDkKE3RmTnUH5BydLclaszQWx9txqBqnbi+V6PN7p0i8ilIE9ZzsMKMF3793Eqvff N5y3B/dVlec8b0VWEqmrbWVqoYmXOIJI7Wurt4jc5P66mfTU5h2hb07V8DpHPqDtdL4F A0M0ubASkxzjNAfmLhCmSoG+S17IHr37VvN06D34amVx9bmFQ82v4dkUGcLJGStjreU+ lHjqIXkaR2ONV5X8MqVUUBwm1QGnE628he2huBYUzZBQ3FbrE463OtJ7vZmrbPmt923/ TPYg== X-Gm-Message-State: ALoCoQlQpd+K2Kz5HNiu7U1sIGiNG+7QWMiWuOIpQx8ZbEi1skTDJlayy+3ISuRc8LvJUw2kf5d9 X-Received: by 10.170.43.193 with SMTP id 184mr41935181ykl.119.1438147578469; Tue, 28 Jul 2015 22:26:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.8.201 with HTTP; Tue, 28 Jul 2015 22:25:58 -0700 (PDT) In-Reply-To: <66040967-4EB3-424D-B21D-9C0CC489A5D6@nominum.com> References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> <55B1ED14.6030501@gmail.com> <20150727091241.GL84167@Space.Net> <20150728115944.GZ84167@Space.Net> <4AB2ED61-23CF-40D5-B2A6-F1F4064EC0C6@nominum.com> <90E6B48E-B3FC-4AAD-B356-7D92A2777632@nominum.com> <66040967-4EB3-424D-B21D-9C0CC489A5D6@nominum.com> From: Lorenzo Colitti Date: Wed, 29 Jul 2015 14:25:58 +0900 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=001a11378f348d0c2d051bfcd30b Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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: Wed, 29 Jul 2015 05:26:21 -0000 --001a11378f348d0c2d051bfcd30b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jul 29, 2015 at 1:54 PM, Ted Lemon wrote: > Or for laptops that want to run VMs. Or for future protocols that need > more space, or for applications that want per-application IP-addresses. O= r > anything else. > > Laptop VMs will have DHCP clients, so there=E2=80=99s no reason not to us= e DHCP. > Only Android doesn=E2=80=99t have a DHCP client. > DHCPv6 is not the issue. The issue that we're recommending that networks provide enough addresses *at connection time*. If we recommend that networks should assign every device a /120 (256 addresses) *at connection time*, then a device getting the /120 cannot respect the recommendations with respect to any nodes behind it. > The draft only recommends using DHCPv6 PD on if the network "requires > explicit requests for address space". That rules out anything running > SLAAC, which is supported by the vast majority of IPv6 deployments today. > If you want the draft to recommend that networks should not require > explicit requests for address space, then it can do that. > > > I do not see how your response connects to what I said. Either we can > afford for every host to have a /64, or we can=E2=80=99t. If we can=E2= =80=99t, then we > shouldn=E2=80=99t be delegating /64s to hosts. > Your argument does not take into account the reality that RIR policies are different for different use cases. More specifically, it does not hold water due to the fact that current practices allow assigning 4096 times as much address space (/48) to a small/medium enterprise as ISPs often assign to a small residential user (/60). More in detail: 1. Given current RIR policies, we can afford to assign a /48 to every enterprise network that needs to support up to 64k general-purpose endpoints. We have plenty of /48s. 2. Given current RIR policies, we afford to assign a /64 per device to every enterprise network that needs to support more than 64k general-purpose endpoints (there aren't that many of these, and we have plenty of /40s). 3. Given current ISP assignments, we cannot afford to assign a /64 per device in a home network that only has a /60. So the only problem here is #3 - home networks. But because home networks use SLAAC, we don't need to assign a /64 to every host. --001a11378f348d0c2d051bfcd30b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 29, 2015 at 1:54 PM, Ted Lemon <ted.lemon@nominum.com><= /span> wrote:
Or for laptops that want to run VMs. Or for future protocols that need mor= e space, or for applications that want per-application IP-addresses. Or any= thing else.
Laptop VMs will have DHCP client= s, so there=E2=80=99s no reason not to use DHCP. =C2=A0 Only Android doesn= =E2=80=99t have a DHCP client.

= DHCPv6 is not the issue. The issue that we're recommending that network= s provide enough addresses *at connection time*. If we recommend that netwo= rks should assign every device a /120 (256 addresses) *at connection time*,= then a device getting the /120 cannot respect the recommendations with res= pect to any nodes behind it.
The draft only recommends using DHCPv6 PD on if the net= work "requires explicit requests for address space". That rules o= ut anything running SLAAC, which is supported by the vast majority of IPv6 = deployments today. If you want the draft to recommend that networks should = not require explicit requests for address space, then it can do that.
=

I do not see how your response con= nects to what I said. =C2=A0 Either we can afford for every host to have a = /64, or we can=E2=80=99t. =C2=A0 If we can=E2=80=99t, then we shouldn=E2=80= =99t be delegating /64s to hosts.

Your argument does not take into account the reality that RIR policies a= re different for different use cases. More specifically, it does not hold w= ater due to the fact that current practices allow assigning 4096 times as m= uch address space (/48) to a small/medium enterprise as ISPs often assign t= o a small residential user (/60).

More in detail:<= /div>
  1. Given current RIR policies, we can afford to assign a /48= to every enterprise network that needs to support up to 64k=C2=A0general-p= urpose=C2=A0endpoints. We have plenty of /48s.
  2. Given current RIR po= licies, we afford to assign a /64 per device to every enterprise network th= at needs to support more than 64k general-purpose endpoints (there aren'= ;t that many of these, and we have plenty of /40s).
  3. Given curre= nt ISP assignments, we cannot afford to assign a /64 per device in a home n= etwork that only has a /60.
So the only problem here is #3 - = home networks. But because home networks use SLAAC, we don't need to as= sign a /64 to every host.
--001a11378f348d0c2d051bfcd30b-- From nobody Tue Jul 28 22:44:58 2015 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 9772C1A21B5 for ; Tue, 28 Jul 2015 22:44:56 -0700 (PDT) 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 3HXSiUUN8w0q for ; Tue, 28 Jul 2015 22:44:54 -0700 (PDT) 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 D52F51A21B9 for ; Tue, 28 Jul 2015 22:44:53 -0700 (PDT) Received: from [2a02:fe0:c412:1fe0::2] (port=55963 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1ZKKAd-0005Ps-5c; Wed, 29 Jul 2015 07:44:51 +0200 Date: Wed, 29 Jul 2015 07:44:50 +0200 From: Tore Anderson To: Ted Lemon Message-ID: <20150729074450.6fe6adb8@envy.fud.no> In-Reply-To: <730AF1E1-F435-4EE2-877A-A46B8A90AA4D@nominum.com> References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> <55B1ED14.6030501@gmail.com> <20150727091241.GL84167@Space.Net> <20150728115944.GZ84167@Space.Net> <4AB2ED61-23CF-40D5-B2A6-F1F4064EC0C6@nominum.com> <55B7CBB9.2050107@gmail.com> <730AF1E1-F435-4EE2-877A-A46B8A90AA4D@nominum.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; 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] I-D Action: draft-colitti-v6ops-host-addr-availability-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: Wed, 29 Jul 2015 05:44:56 -0000 * Ted Lemon > On Jul 28, 2015, at 2:36 PM, Brian E Carpenter wrote: > > Not to mention encountering the problems with /120 mentioned > > in RFC 7421, which include the problems of only having a /24 in > > IPv4. We should be past that. >=20 > To be clear, I wasn=E2=80=99t proposing /120 prefixes, but the delegation > of /120 prefixes as a way of delivering a chunk of contiguous > addresses smaller than a /64, which I continue to think is > impractical for Lorenzo=E2=80=99s use case. I was thinking something along the same lines, and not agreeing the draft's statement that DHCPv6-PD cannot cater for =C2=AB"unlimited" endpoints=C2=BB. My view was that the problem could be solved, e.g., in this way: - Device 1 receives a delegated (<=3D) /64 from ISP/network (either 3GPP or DHCPv6-PD), which it then chops up in (for example) 2^16 /80s which may be handed out using DHCPv6-PD to downstream devices or local software functions (which would includes including its own loopback interface, local containers/VMs, etc.) - Any downstream device that receives an /80 from the above device chops it up in 2^16 /96s which in the same way may be handed out to downstream devices or local software functions. - Any downstream device that receives a /96 from a device at the above level can chop it up in 2^16 /112s and use it in the same way. This would facilitate "unlimited" endpoints, assuming all the endpoints support DHCPv6-PD. It would preclude the use of SLAAC, though, as any link prefixes would be >/64. (However, the use of global link prefixes would not really be necessary in the first place, as all links could be link-local only). Anyway, after having discussed this with Lorenzo at IETF93 I realised that this is not covered because it is considered an invalid configuration: RFC3633 section 12.1 says =C2=ABfor each IA_PD the requesting router assigns a subnet from each of the delegated prefixes to each of the links to which the associated interfaces are attached=C2=BB and RFC7421 section 1 describes how =C2=ABa subnet prefix longer than 64 bits is outside the current IPv6 specifications=C2=BB. Thus, assigning DHCPv6-PD for prefix= es longer than /64 is seen as an invalid network configuration, and thus not discussed in the draft as a potential solution. While I am not completely convinced of the validity of that argument (in particular, I am not entirely convinced that RFC3633 section 12.1 actually *prohibits* a requesting router from assigning a smaller than /64 chunk of addresses out of a delegated prefix to its loopback interface for use with local traffic), I suppose the position is fair enough and I do not intend to argue this point further. That said, given that the draft is targeted at operators, I think it would benefit from unequivocally stating that the use of prefixes (both delegated and link) with lengths >/64 are considered invalid and any solution involving them is therefore not being discussed - because when I read the draft while wearing my operator hat only, I see that as a solution that would actually work just fine from a technical point of view. RFC 7421 section 4.3.2 appears to confirm I am not alone in this, stating =C2=ABDHCPv6 is in widespread use without any dependency on the /64 boundary=C2=BB. Tore From nobody Wed Jul 29 00:12:27 2015 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 7DB5A1B3278 for ; Wed, 29 Jul 2015 00:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ViWYE0LquVP0 for ; Wed, 29 Jul 2015 00:12:24 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::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 BAF8F1B3258 for ; Wed, 29 Jul 2015 00:12:24 -0700 (PDT) Received: by wicgb10 with SMTP id gb10so186599430wic.1 for ; Wed, 29 Jul 2015 00:12:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ebhZptVydn1ZzEpwu1R2UyBh0oDLNns7Ioo4uuuj1Pk=; b=UiL0FRAkXP3YJoHujhWDR7mE6NGX9CToY/zEijTqdLckYspUFSwXdzZKDqMfwcgQH6 X7bCvdRByGsttjbKzOXKcBSqnUmaJFIYklPISmLGXkDRb6e8eLbjE+L/vMrIGiDzAmSz LgwwLSZaHS18gfVqILT2hMi4idSAhu0j0DFGH8b6COguwMGmXIO9XjhAut9aOQti4j8J vPM/Sx0O6i+RixKTtm67B5kCLrPHroNcVCTFDs+f0NkMFt8kdH3DOn7bSuyg2kQRE8rr V2/NgvwW83gc9hYbukw8XTGSrdME29G7Z78yX0wSCrZ+cjQPo6Jz2NJhr6FzqVMP4YR0 gkGQ== X-Received: by 10.194.104.98 with SMTP id gd2mr70375384wjb.35.1438153943302; Wed, 29 Jul 2015 00:12:23 -0700 (PDT) Received: from [192.168.0.4] (cpc11-brig18-2-0-cust561.3-3.cable.virginm.net. [81.100.118.50]) by smtp.gmail.com with ESMTPSA id bm9sm22747032wib.10.2015.07.29.00.12.21 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Jul 2015 00:12:22 -0700 (PDT) Message-ID: <55B87CDA.1000609@gmail.com> Date: Wed, 29 Jul 2015 19:12:26 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Tore Anderson , Ted Lemon References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> <55B1ED14.6030501@gmail.com> <20150727091241.GL84167@Space.Net> <20150728115944.GZ84167@Space.Net> <4AB2ED61-23CF-40D5-B2A6-F1F4064EC0C6@nominum.com> <55B7CBB9.2050107@gmail.com> <730AF1E1-F435-4EE2-877A-A46B8A90AA4D@nominum.com> <20150729074450.6fe6adb8@envy.fud.no> In-Reply-To: <20150729074450.6fe6adb8@envy.fud.no> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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: Wed, 29 Jul 2015 07:12:26 -0000 On 29/07/2015 17:44, Tore Anderson wrote: > * Ted Lemon >=20 >> On Jul 28, 2015, at 2:36 PM, Brian E Carpenter wrote: >>> Not to mention encountering the problems with /120 mentioned >>> in RFC 7421, which include the problems of only having a /24 in >>> IPv4. We should be past that. >> >> To be clear, I wasn=E2=80=99t proposing /120 prefixes, but the delegat= ion >> of /120 prefixes as a way of delivering a chunk of contiguous >> addresses smaller than a /64, which I continue to think is >> impractical for Lorenzo=E2=80=99s use case. > That said, given that the draft is targeted at operators, I think it > would benefit from unequivocally stating that the use of prefixes (both= > delegated and link) with lengths >/64 are considered invalid and any > solution involving them is therefore not being discussed - because when= > I read the draft while wearing my operator hat only, I see that as a > solution that would actually work just fine from a technical point of > view. RFC 7421 section 4.3.2 appears to confirm I am not alone in this,= > stating =C2=ABDHCPv6 is in widespread use without any dependency on the= /64 > boundary=C2=BB. I think we should also note that once we start delegating long prefixes out of a /64, the privacy properties of a "normal" IPv6 address are blown away. In fact the draft probably needs a Privacy Considerations section - presumably it's the /64 that would be of interest for geolocation, the NSA, RIPA, etc. Brian From nobody Wed Jul 29 01:38:51 2015 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 F20271B34D7 for ; Wed, 29 Jul 2015 01:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.6 X-Spam-Level: X-Spam-Status: No, score=-4.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 uQ1UHiiuvZ04 for ; Wed, 29 Jul 2015 01:38:48 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 481E31A702F for ; Wed, 29 Jul 2015 01:38:48 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1ZKMsw-0000CCC; Wed, 29 Jul 2015 10:38:46 +0200 Message-Id: To: "v6ops@ietf.org" From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <4797B33E-9851-427E-8710-84122AFD0FFA@cisco.com> In-reply-to: Your message of "Wed, 29 Jul 2015 03:00:01 +0000 ." <4797B33E-9851-427E-8710-84122AFD0FFA@cisco.com> Date: Wed, 29 Jul 2015 10:38:45 +0200 Archived-At: Subject: Re: [v6ops] NAT64/DNS64 and DNSSEC 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, 29 Jul 2015 08:38:50 -0000 In your letter dated Wed, 29 Jul 2015 03:00:01 +0000 you wrote: >Between us girls, I don't think many of us really like NAT64... I don't like it either. But there seems to be a vocal group of operators who like it. Not a lot of opposition and now Apple seems to like it as well. So the only way forward is to make it work. From nobody Wed Jul 29 03:06:21 2015 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 36F241A01FC for ; Wed, 29 Jul 2015 03:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 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_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, 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 zhhidEfvxYoz for ; Wed, 29 Jul 2015 03:06:17 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 284891A0162 for ; Wed, 29 Jul 2015 03:06:16 -0700 (PDT) Received: from [IPv6:2001:718:1:6::134:196] (oskarpc.cesnet.cz [IPv6:2001:718:1:6::134:196]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id F2961ED393E for ; Wed, 29 Jul 2015 12:06:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1438164374; bh=feETV24G+bkDpULWjqoGNfv4bffxNuucjYeu4NddR7s=; h=Subject:To:References:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type; b=rB21h7I8QEYR2j/vRZ9K2rMdtl4XjU6B4DtwvMX/vaqH4rXgpkzJ+9yG+2nzpb8/z l63IsaFacaprvJVB5F71Je6zH08RQW3850znUl0yf6zkWMZZJwodpcCul7eB9e/6Wd HNrNxuA/l3PmxwwRiZgxN2ZkjDF5r3O+yh7f6pZY= To: v6ops@ietf.org References: <55B09AE5.4040609@gmail.com> <2BBE839B-37FB-4EA2-982E-58028E7A13B6@nominum.com> <55B0F344.4090005@gmail.com> <88CAA5385EB5404392BF93106C8C53F89636B43DE3@HE111507.emea1.cds.t-internal.com> From: =?UTF-8?Q?Ond=c5=99ej_Caletka?= X-Enigmail-Draft-Status: N1110 Message-ID: <55B8A596.80600@cesnet.cz> Date: Wed, 29 Jul 2015 12:06:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <88CAA5385EB5404392BF93106C8C53F89636B43DE3@HE111507.emea1.cds.t-internal.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060702090601030909060509" Archived-At: Subject: Re: [v6ops] NAT64/DNS64 and DNSSEC 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, 29 Jul 2015 10:06:19 -0000 This is a cryptographically signed message in MIME format. --------------ms060702090601030909060509 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, Dne 28.7.2015 v 21:58 holger.metschulat@telekom.de napsal(a): > but isn't there a gap that when performing the RFC7050 64pref detection= by querying ipv6only.arpa, an attacker can spoof this answer (DNSSEC won= 't work here, for example, the attacker - when between the client and the= DNS - can return for example 2001:db8::192.0.0.170 (where 2001:db8:: is = a prefix owned by the attacker)) and then attract all IPv4 traffic from t= he victim? That is why there is a requirement in RFC7050 Section 3.1. to validate network-specific NAT64 prefix using reverse and forward DNSSEC secured queries. The only problem is that there is no way so far how to seed the list of trusted NSP domains. Instead of asking users "Do you want to trust the network prefix dns64.example.org?", there could probably be some matching with domain name received by other means like DHCP or DNSSL= =2E Of course, using the Well-known prefix is on the safe side, and should be IMO used wherever applicable. Cheers, Ond=C5=99ej Caletka --------------ms060702090601030909060509 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: Elektronicky podpis S/MIME MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC EoQwggRmMIIDTqADAgECAhBRJgqTHOJ/nMOlX3ngcq6CMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYD VQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRy dXN0LmNvbTEbMBkGA1UEAxMSVVROIC0gREFUQUNvcnAgU0dDMB4XDTA1MDYwNzA4MDkxMFoX DTE5MDYyNDE5MDYzMFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYw JAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1 c3QgRXh0ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3 GjPm8gAELTngTlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCw SXrbLpX9uMq/NzgtHj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzX mk6vBbOmcZSccbNQYArHE504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63u bUFfclpxCDezeWWkWaCUN/cALw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5 aWpYIxG3pzOPVnVZ9c0p10a3CitlttNCbxWyuHv77+ldU9U0WicCAwEAAaOB2DCB1TAfBgNV HSMEGDAWgBRTMtGzz3/64PGgXYVOktKeRR20TzAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO9 4CTLVBowDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wEQYJYIZIAYb4QgEBBAQD AgECMCAGA1UdJQQZMBcGCisGAQQBgjcKAwMGCWCGSAGG+EIEATA9BgNVHR8ENjA0MDKgMKAu hixodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLURBVEFDb3JwU0dDLmNybDANBgkqhkiG 9w0BAQUFAAOCAQEAxu5TF2gUslEiHpBYDZT9vfFw5YYtwzYxj1RIRuctCDe8bApg4Q6tUTTg EpPpvriruCa06ZY9KI+uZAf+4AHsxeOR6xig8XV+2wrmn5Hbr6513yORaN0XAFpL/2RscOsB GtCQ2cem1m32E+T/tcnSHirLsSVDJnjZMJtODR6+ae/f6v4ts8z5sN21FMqR1LK1pfsBGaNH eZ+djJWHNPgfOJLaNqYR+mvra+ncRXgVOQbXTUHkIcjcL4fRt79IYHWlYssk3jthoCkgpr7F bJzE6QppIu+ROvomr9FbQac64vg4B0KrwVv4zm26DwQ/MjSs3AQo13AwFCYGxOSbmNXPeDCC BJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2Ny bC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEB BCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QWuZGH kfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLRzIlf sXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7LmrmdlMa5 lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg7sJx ggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCCBK4w ggOWoAMCAQICEQD14uJ1ix304TINvpgkA2PFMA0GCSqGSIb3DQEBBQUAMDsxCzAJBgNVBAYT Ak5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25hbCBDQTAeFw0x NDEwMDYwMDAwMDBaFw0xNjEyMzEyMzU5NTlaME0xCzAJBgNVBAYTAkNaMQ8wDQYDVQQKEwZD RVNORVQxGDAWBgNVBAMMD09uZMWZZWogQ2FsZXRrYTETMBEGCSqGSIb3DQEJAhYEMzczODCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMaDJcHxCnrVmHrlZZxt6eSmh1KwEI0w 7m2qujxpbQoe1QLxDG1EZNWwh8y9tF8fGtbC21onCdAQ2eMsrmUqbLBZvJmz7Q9A6agyb78B XjJr1MUQ55V0b40QpBXLNhtiEN1b5k6Xiibcl+RckISCF25vyyI57+paTPePHhR+hag2eUlu amKhuWaY86rzv8deWtkGBuQ3nSdgFyS0WoK4wZKicXvUkBgdc4vL/89VirOmK2+poSXQHQaG Q47+zWN3Y5uMzY+gbpm+HyK7Pde0DATaRpKoag+YLQWWi+1+5Q+BFv7b9Ag79TggA2AE1Tcr BjxNMUu2gZLq+8VUcg9r03kCAwEAAaOCAZkwggGVMB8GA1UdIwQYMBaAFGNNQ1oZSD/ERsEC ur/uDuWCt2amMB0GA1UdDgQWBBTsn6r2dJoDEu59msxGUg+Kn4wbHzAOBgNVHQ8BAf8EBAMC BaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwGAYDVR0g BBEwDzANBgsrBgEEAbIxAQICHTA/BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLnRjcy50 ZXJlbmEub3JnL1RFUkVOQVBlcnNvbmFsQ0EuY3JsMHIGCCsGAQUFBwEBBGYwZDA6BggrBgEF BQcwAoYuaHR0cDovL2NydC50Y3MudGVyZW5hLm9yZy9URVJFTkFQZXJzb25hbENBLmNydDAm BggrBgEFBQcwAYYaaHR0cDovL29jc3AudGNzLnRlcmVuYS5vcmcwRwYDVR0RBEAwPoERY2Fs ZXRrYUBjZXNuZXQuY3qBD29za2FyQGNlc25ldC5jeoEYT25kcmVqLkNhbGV0a2FAY2VzbmV0 LmN6MA0GCSqGSIb3DQEBBQUAA4IBAQCAk2CmVQHSO78pHtvT1mWR/vYZZvykrgc2OD1xtSih 5clBmy0PMJ8ePLrzY+pSJqUjvcny2q+MDMOSkKoYb7Hr1xQi8L9gdNzgUYPb64NGpQD8yCRN QF/SP1Q7Punlb8ctntBPEFlhEvtWFD+I3o3UcDnxhP3FyLlgioNKSxn+Lg4okPjb0JHo1YVA xMejbeYNUpHUZATTRwtywDBKvZ3MRLklLBIDTWUBednk9XRNSGZ8tHqHwFL41QTJZQZ7NJrM +hQGx+zoKyICDzGxYfa0qCYzCp7HZTwyzJ9Y3N2EX6WG7+60PdQdUdxP8oH8rs6qHaievyg1 u57MB7O9dlTnMIIEwzCCA6ugAwIBAgIQc/5X+t+4xQiBe2a5a/At7zANBgkqhkiG9w0BAQUF ADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0 eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3 LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbDAeFw0wOTA1MTgwMDAwMDBaFw0yODEyMzEyMzU5NTlaMDsxCzAJ BgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25hbCBD QTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMgV2fUzaiOhkA3PuwVEw6sfSjWF GiGFoE/48EDiSkOb/luxsL+0V9x1gEFLZBr2209vj9AlRTX56stK+vva0+1FiBGUNuTMqA3v xT037RZ748KVnlgzfyL7+P/s5r7brgplJSKH2m+Ei0boQIYoP79WCOJK6YOi6SL7Lfq2KB+R wcNx+1PAK06kDKFunVXt7OEkhzoI4g0c5MRN0Msn+oRk5tGXnVYkW5O7KS5D4kFqPeJKZfya X1qGh7yHx3mAlplRxpAPZJGZfRDdrCwDKuF4ZP7OPU70K1ARS9FY1JsD8H/1O1OwU0P7xS/E BCkaOqzXVenRDpXROzF/eE+uKS0CAwEAAaOCAU0wggFJMB8GA1UdIwQYMBaAFImCZ33EnSZw AEu0UEh83j2uBG59MB0GA1UdDgQWBBRjTUNaGUg/xEbBArq/7g7lgrdmpjAOBgNVHQ8BAf8E BAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADAYBgNVHSAEETAPMA0GCysGAQQBsjEBAgIdMFgG A1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNFUkZpcnN0 LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMG8GCCsGAQUFBwEBBGMwYTA4Bggr BgEFBQcwAoYsaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFBQUNsaWVudF9DQS5jcnQw JQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQAD ggEBAAYrqVMvE9xcORbMhp9eTHty++yNVYpemgr/U0x29AY9UM9X8KLPr5mMqv6gGXY+mQMy +nWDOIq7a5qlDBOy1Bt25pQuZ5hZ45FsApCanMhgS1WryohajSvlaZUDB9HUDvwkIi5ZsWOk X+3ZI3LknM46XGwfT6kAyR3++n9FLbYuhN0PJ6BZGE7VdiVF9JkmedtvnyP3Q7srDwSjgSYs t3s1+T13X0Ah5n8dpZZavdDLFjpsu2GLiv0EOUQKyyzhy84uEJga2+CT7UlkZAggn7ejUPCi 3cq0xnwMPedeFdwnhuQ6O1JaF6upBlMrnQlzZBwBw/0w0ocDb+QVA3o5X2gxggMaMIIDFgIB ATBQMDsxCzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQ ZXJzb25hbCBDQQIRAPXi4nWLHfThMg2+mCQDY8UwDQYJYIZIAWUDBAIBBQCgggGbMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDcyOTEwMDYxNFowLwYJ KoZIhvcNAQkEMSIEIKiB0nVNlQflf9eg3V40n0AL135B7IZV296kzy/3ELQiMF8GCSsGAQQB gjcQBDFSMFAwOzELMAkGA1UEBhMCTkwxDzANBgNVBAoTBlRFUkVOQTEbMBkGA1UEAxMSVEVS RU5BIFBlcnNvbmFsIENBAhEA9eLidYsd9OEyDb6YJANjxTBhBgsqhkiG9w0BCRACCzFSoFAw OzELMAkGA1UEBhMCTkwxDzANBgNVBAoTBlRFUkVOQTEbMBkGA1UEAxMSVEVSRU5BIFBlcnNv bmFsIENBAhEA9eLidYsd9OEyDb6YJANjxTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIIBAE1qBzmHUjrG E3fHlTq7JKrBUsdb8dUnztja7Aw2Ne+o7+Ahbx/S3PNBgU4UEqJEgBOufl0BYZGG/t4Y8Ypj mrHxqf1HbdZ7BNWgsFWoaoP/RZfquqEhvAGdjgC90EKwhYDbW6AffcFdRtBdV1q2VcxbSv8i 8EtVKSA1au/xt2wqb5j9DVSYx4j65XLwsU58izeSW8jB1OnmOCUvz7xHTuh0g/XmMb6fkh7A EfDvOjYil6v8KZZFI4pVHUjL31WL0Yb7f8hxRGTeRR+yYhWRLm3cZEGagFx4fD+85JNxbHDU V9Gk658Qh7vfU5m9iH3pCc9CiaEAn7G7RS4tvZ2vOXYAAAAAAAA= --------------ms060702090601030909060509-- From nobody Wed Jul 29 03:26:52 2015 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 1671C1A1A33 for ; Wed, 29 Jul 2015 03:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.6 X-Spam-Level: X-Spam-Status: No, score=-4.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 YLIh_z4D1yUX for ; Wed, 29 Jul 2015 03:26:49 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id C53BD1A0211 for ; Wed, 29 Jul 2015 03:26:48 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1ZKOZT-0000CeC; Wed, 29 Jul 2015 12:26:47 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <55B09AE5.4040609@gmail.com> <2BBE839B-37FB-4EA2-982E-58028E7A13B6@nominum.com> <55B0F344.4090005@gmail.com> <88CAA5385EB5404392BF93106C8C53F89636B43DE3@HE111507.emea1.cds.t-internal.com> <55B8A596.80600@cesnet.cz> In-reply-to: Your message of "Wed, 29 Jul 2015 12:06:14 +0200 ." <55B8A596.80600@cesnet.cz> Date: Wed, 29 Jul 2015 12:26:47 +0200 Archived-At: Subject: Re: [v6ops] NAT64/DNS64 and DNSSEC 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, 29 Jul 2015 10:26:51 -0000 In your letter dated Wed, 29 Jul 2015 12:06:14 +0200 you wrote: >That is why there is a requirement in RFC7050 Section 3.1. to validate >network-specific NAT64 prefix using reverse and forward DNSSEC secured >queries. The only problem is that there is no way so far how to seed the >list of trusted NSP domains. Instead of asking users "Do you want to >trust the network prefix dns64.example.org?", there could probably be >some matching with domain name received by other means like DHCP or DNSSL= >=2E > >Of course, using the Well-known prefix is on the safe side, and should >be IMO used wherever applicable. It seems to me that Section 3.1 is very far from something can be implemented in a practical way in a consumer device. I.e. if a user with a mobile device connects to a random network that employs NAT64, there is essentially no way for an ordinary user to verify if the prefix is valid or not. Now if there would be DHCPv6 and RA options for the prefix, there would be no need to discover the prefix using the DNS64 resolver and the problem would reduce to whether to trust DHCPv6 or RA. Which is already part of the security model (i.e. RA guard can protect users from each other). From nobody Wed Jul 29 05:38:57 2015 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 D93581A8A44 for ; Wed, 29 Jul 2015 05:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmY-y0Cgh2iz for ; Wed, 29 Jul 2015 05:38:54 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 256BB1A8A3E for ; Wed, 29 Jul 2015 05:38:54 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 8ABC7374784; Wed, 29 Jul 2015 14:38:52 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.18]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 6DD70384116; Wed, 29 Jul 2015 14:38:52 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0248.002; Wed, 29 Jul 2015 14:38:52 +0200 From: To: Philip Homburg Thread-Topic: [v6ops] NAT64/DNS64 and DNSSEC Thread-Index: AQHQyekc+iplqWA6RkKlEMa3/B/mHZ3yYmyQ Date: Wed, 29 Jul 2015 12:38:51 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933005370CE6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <55B09AE5.4040609@gmail.com> <2BBE839B-37FB-4EA2-982E-58028E7A13B6@nominum.com> <55B0F344.4090005@gmail.com> <88CAA5385EB5404392BF93106C8C53F89636B43DE3@HE111507.emea1.cds.t-internal.com> <55B8A596.80600@cesnet.cz> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.7.29.120616 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] NAT64/DNS64 and DNSSEC 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, 29 Jul 2015 12:38:56 -0000 Dear Philip,=20 FWIW, another solution is defined here: https://tools.ietf.org/html/rfc7225= #section-3. Cheers, Med=20 > -----Message d'origine----- > De=A0: v6ops [mailto:v6ops-bounces@ietf.org] De la part de Philip Homburg > Envoy=E9=A0: mercredi 29 juillet 2015 12:27 > =C0=A0: v6ops@ietf.org > Objet=A0: Re: [v6ops] NAT64/DNS64 and DNSSEC >=20 > In your letter dated Wed, 29 Jul 2015 12:06:14 +0200 you wrote: > >That is why there is a requirement in RFC7050 Section 3.1. to validate > >network-specific NAT64 prefix using reverse and forward DNSSEC secured > >queries. The only problem is that there is no way so far how to seed the > >list of trusted NSP domains. Instead of asking users "Do you want to > >trust the network prefix dns64.example.org?", there could probably be > >some matching with domain name received by other means like DHCP or > DNSSL=3D > >=3D2E > > > >Of course, using the Well-known prefix is on the safe side, and should > >be IMO used wherever applicable. >=20 > It seems to me that Section 3.1 is very far from something can be > implemented > in a practical way in a consumer device. >=20 > I.e. if a user with a mobile device connects to a random network that > employs > NAT64, there is essentially no way for an ordinary user to verify if the > prefix is valid or not. >=20 > Now if there would be DHCPv6 and RA options for the prefix, there would b= e > no need to discover the prefix using the DNS64 resolver and the problem > would > reduce to whether to trust DHCPv6 or RA. Which is already part of the > security model (i.e. RA guard can protect users from each other). >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Jul 29 06:13:51 2015 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 5E8241AC3B1 for ; Wed, 29 Jul 2015 06:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.6 X-Spam-Level: X-Spam-Status: No, score=-4.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 3awEIJC6xbW0 for ; Wed, 29 Jul 2015 06:13:40 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 095591AC3B0 for ; Wed, 29 Jul 2015 06:13:35 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1ZKRAr-0000DAC; Wed, 29 Jul 2015 15:13:33 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <55B09AE5.4040609@gmail.com> <2BBE839B-37FB-4EA2-982E-58028E7A13B6@nominum.com> <55B0F344.4090005@gmail.com> <88CAA5385EB5404392BF93106C8C53F89636B43DE3@HE111507.emea1.cds.t-internal.com> <55B8A596.80600@cesnet.cz> <787AE7BB302AE849A7480A190F8B933005370CE6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933005370CFE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-reply-to: Your message of "Wed, 29 Jul 2015 12:43:17 +0000 ." <787AE7BB302AE849A7480A190F8B933005370CFE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Wed, 29 Jul 2015 15:13:32 +0200 Archived-At: Subject: Re: [v6ops] NAT64/DNS64 and DNSSEC 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, 29 Jul 2015 13:13:43 -0000 In your letter dated Wed, 29 Jul 2015 12:43:17 +0000 you wrote: >I forgot to mention that behave WG analyzed the use of DHCP and RA as candi= >date solutions. See the analysis available at:=20 > >* RA: https://tools.ietf.org/html/rfc7051#section-5.7=20 >* DHCPv6: https://tools.ietf.org/html/rfc7051#section-5.6=20 Seems like a really poor analysis from a security point of view. - DNSSEC is not taken into account - The existing need for RA security is ignored when introducing another way to attack the system. The idea to piggyback the NAT64 prefix in PCP is nice if PCP is widely deployed, but I'm not sure it is widely deployed enough to rely on it. Note that if a host takes the NAT64 from PCP then all networks have to protect PCP whether they use it or not. From nobody Wed Jul 29 06:52:00 2015 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 C2A731A1B72 for ; Wed, 29 Jul 2015 06:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 WMJLKtUfNvb0 for ; Wed, 29 Jul 2015 06:51:57 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (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 EF0DD1A1B62 for ; Wed, 29 Jul 2015 06:51:56 -0700 (PDT) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id AA5C2DA0089; Wed, 29 Jul 2015 13:51:56 +0000 (UTC) Received: from [10.0.20.178] (71.233.41.235) by CAS-03.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 29 Jul 2015 06:51:56 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_40E3BF3C-FC5C-4F3C-B45E-37631C4276C7" MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ted Lemon In-Reply-To: Date: Wed, 29 Jul 2015 09:51:54 -0400 Message-ID: <53007642-4C18-4AF5-B986-4704A7D99D0F@nominum.com> References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> <55B1ED14.6030501@gmail.com> <20150727091241.GL84167@Space.Net> <20150728115944.GZ84167@Space.Net> <4AB2ED61-23CF-40D5-B2A6-F1F4064EC0C6@nominum.com> <90E6B48E-B3FC-4AAD-B356-7D92A2777632@nominum.com> <66040967-4EB3-424D-B21D-9C0CC489A5D6@nominum.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.2102) X-Originating-IP: [71.233.41.235] Archived-At: Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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: Wed, 29 Jul 2015 13:51:58 -0000 --Apple-Mail=_40E3BF3C-FC5C-4F3C-B45E-37631C4276C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Jul 29, 2015, at 1:25 AM, Lorenzo Colitti wrote: > DHCPv6 is not the issue. The issue that we're recommending that = networks provide enough addresses *at connection time*. If we recommend = that networks should assign every device a /120 (256 addresses) *at = connection time*, then a device getting the /120 cannot respect the = recommendations with respect to any nodes behind it. I don=E2=80=99t think we are talking about the same thing. You are = proposing that if we use SLAAC, the host initially gets however many = addresses it acquires through SLAAC, typically 1 per prefix, but you = propose that it might want, say, 20 or 30. But if it uses DHCP, it = gets a /64. That=E2=80=99s 18 decimal orders of magnitude more = addresses in the DHCP case. Why the disparity? --Apple-Mail=_40E3BF3C-FC5C-4F3C-B45E-37631C4276C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" On Jul 29, 2015, at 1:25 AM, Lorenzo Colitti <lorenzo@google.com> = wrote:
DHCPv6 is not the = issue. The issue that we're recommending that networks provide enough = addresses *at connection time*. If we recommend that networks should = assign every device a /120 (256 addresses) *at connection time*, then a = device getting the /120 cannot respect the recommendations with respect = to any nodes behind it.

I don=E2=80=99t think we are talking about the = same thing.   You are proposing that if we use SLAAC, the host = initially gets however many addresses it acquires through SLAAC, = typically 1 per prefix, but you propose that it might want, say, 20 or = 30.   But if it uses DHCP, it gets a /64.   That=E2=80=99s 18 = decimal orders of magnitude more addresses in the DHCP case.   Why = the disparity?

= --Apple-Mail=_40E3BF3C-FC5C-4F3C-B45E-37631C4276C7-- From nobody Wed Jul 29 06:59:58 2015 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 A3B571A0095 for ; Wed, 29 Jul 2015 06:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 Fm1x4uAuluFP for ; Wed, 29 Jul 2015 06:59:54 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (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 B1F9E1A1B81 for ; Wed, 29 Jul 2015 06:59:54 -0700 (PDT) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 97BDCDA0089; Wed, 29 Jul 2015 13:59:54 +0000 (UTC) Received: from [10.0.20.178] (71.233.41.235) by CAS-03.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 29 Jul 2015 06:59:54 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_1DD50290-4DCC-494A-A0E7-E88F4B2823D3" MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ted Lemon In-Reply-To: <20150729074450.6fe6adb8@envy.fud.no> Date: Wed, 29 Jul 2015 09:59:52 -0400 Message-ID: <743C5E3B-7E2F-410A-8257-3865CFD34CDC@nominum.com> References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> <55B1ED14.6030501@gmail.com> <20150727091241.GL84167@Space.Net> <20150728115944.GZ84167@Space.Net> <4AB2ED61-23CF-40D5-B2A6-F1F4064EC0C6@nominum.com> <55B7CBB9.2050107@gmail.com> <730AF1E1-F435-4EE2-877A-A46B8A90AA4D@nominum.com> <20150729074450.6fe6adb8@envy.fud.no> To: Tore Anderson X-Mailer: Apple Mail (2.2102) X-Originating-IP: [71.233.41.235] Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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: Wed, 29 Jul 2015 13:59:56 -0000 --Apple-Mail=_1DD50290-4DCC-494A-A0E7-E88F4B2823D3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Jul 29, 2015, at 1:44 AM, Tore Anderson wrote: > - Device 1 receives a delegated (<=3D) /64 from ISP/network (either = 3GPP > or DHCPv6-PD), which it then chops up in (for example) 2^16 /80s > which may be handed out using DHCPv6-PD to downstream devices or > local software functions (which would includes including its own > loopback interface, local containers/VMs, etc.) > - Any downstream device that receives an /80 from the above device > chops it up in 2^16 /96s which in the same way may be handed out to > downstream devices or local software functions. > - Any downstream device that receives a /96 from a device at the above > level can chop it up in 2^16 /112s and use it in the same way. This implies that you are advertising prefixes wider than /64 on the = downstream side of these devices. That=E2=80=99s not what Lorenzo is = talking about in his draft, and if that=E2=80=99s not clear to your = reading of it, he should probably clarify. Lorenzo may indeed think = that I am proposing to do that, but I=E2=80=99m not. I=E2=80=99m just = proposing that if SLAAC only needs 30 addresses, and we want to allocate = 30 addresses on the advertised prefix using DHCP, DHCP PD would be one = way to deliver those addresses in such a way that they need only occupy = a single slot in the forwarding table for the on-link router(s). The = hierarchical allocation model you are talking about really doesn=E2=80=99t= make sense in this context: if some host several hops down the link is = sharing the prefix, then it can just get its own /120 (or whatever) = chunk of the prefix, rather than getting a chunk of the upstream = host=E2=80=99s chunk. But even going down this rabbit hole shows why this isn=E2=80=99t a = great idea: whether you are using SLAAC or DHCP-PD, what you really have = here is something akin to a homenet router, and if that=E2=80=99s the = case, then you should just own it and not try to pretend that it=E2=80=99s= just a host. --Apple-Mail=_1DD50290-4DCC-494A-A0E7-E88F4B2823D3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" On Jul 29, 2015, at 1:44 AM, Tore Anderson <tore@fud.no> = wrote:
- Device 1 receives a delegated (<=3D) /64 = from ISP/network (either 3GPP
 or DHCPv6-PD), which = it then chops up in (for example) 2^16 /80s
 which may be handed out using DHCPv6-PD to = downstream devices or
 local software = functions (which would includes including its own
 loopback interface, local containers/VMs, = etc.)
- Any downstream device = that receives an /80 from the above device
 chops it up in 2^16 /96s which in the same = way may be handed out to
 downstream devices = or local software functions.
- Any downstream device = that receives a /96 from a device at the above
 level can chop it up in 2^16 /112s and use = it in the same way.

This implies that you are advertising prefixes wider than /64 = on the downstream side of these devices.   That=E2=80=99s not what = Lorenzo is talking about in his draft, and if that=E2=80=99s not clear = to your reading of it, he should probably clarify.   Lorenzo may = indeed think that I am proposing to do that, but I=E2=80=99m not.   = I=E2=80=99m just proposing that if SLAAC only needs 30 addresses, and we = want to allocate 30 addresses on the advertised prefix using DHCP, DHCP = PD would be one way to deliver those addresses in such a way that they = need only occupy a single slot in the forwarding table for the on-link = router(s).   The hierarchical allocation model you are talking = about really doesn=E2=80=99t make sense in this context: if some host = several hops down the link is sharing the prefix, then it can just get = its own /120 (or whatever) chunk of the prefix, rather than getting a = chunk of the upstream host=E2=80=99s chunk.

But even going down this rabbit hole = shows why this isn=E2=80=99t a great idea: whether you are using SLAAC = or DHCP-PD, what you really have here is something akin to a homenet = router, and if that=E2=80=99s the case, then you should just own it and = not try to pretend that it=E2=80=99s just a host.
= --Apple-Mail=_1DD50290-4DCC-494A-A0E7-E88F4B2823D3-- From nobody Wed Jul 29 07:01:46 2015 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 070161A1B81 for ; Wed, 29 Jul 2015 07:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.309 X-Spam-Level: X-Spam-Status: No, score=-1.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, 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 ZmQmH3104aNm for ; Wed, 29 Jul 2015 07:01:43 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (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 458E61A0095 for ; Wed, 29 Jul 2015 07:01:43 -0700 (PDT) Received: from webmail.nominum.com (cas-04.win.nominum.com [64.89.235.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 3864ADA007A; Wed, 29 Jul 2015 14:01:43 +0000 (UTC) Received: from [10.0.20.178] (71.233.41.235) by CAS-04.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 29 Jul 2015 07:01:36 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_EEB1FD3C-BFAA-4F52-86EF-749D7ED69A4C" MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ted Lemon In-Reply-To: Date: Wed, 29 Jul 2015 10:01:35 -0400 Message-ID: References: <4797B33E-9851-427E-8710-84122AFD0FFA@cisco.com> To: Philip Homburg X-Mailer: Apple Mail (2.2102) X-Originating-IP: [71.233.41.235] Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] NAT64/DNS64 and DNSSEC 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, 29 Jul 2015 14:01:44 -0000 --Apple-Mail=_EEB1FD3C-BFAA-4F52-86EF-749D7ED69A4C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Jul 29, 2015, at 4:38 AM, Philip Homburg = wrote: > I don't like it either. But there seems to be a vocal group of = operators who > like it. Not a lot of opposition and now Apple seems to like it as = well. I don=E2=80=99t really know what all the hate is for NAT64. It does a = great job of letting me run a v6only network whilst still communicating = with v4 services on the Internet. Maybe it=E2=80=99s not everybody=E2=80=99= s cup of tea, but it=E2=80=99s a pretty nice solution, and I agree that = making it work with DNSSEC ought to be a priority. --Apple-Mail=_EEB1FD3C-BFAA-4F52-86EF-749D7ED69A4C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" On Jul 29, 2015, at 4:38 AM, Philip Homburg <pch-v6ops-3@u-1.phicoh.com> wrote:
I don't like it either. But there seems to be a = vocal group of operators who
like it. Not a lot of = opposition and now Apple seems to like it as well.

I = don=E2=80=99t really know what all the hate is for NAT64.   It does = a great job of letting me run a v6only network whilst still = communicating with v4 services on the Internet.  Maybe it=E2=80=99s = not everybody=E2=80=99s cup of tea, but it=E2=80=99s a pretty nice = solution, and I agree that making it work with DNSSEC ought to be a = priority.

= --Apple-Mail=_EEB1FD3C-BFAA-4F52-86EF-749D7ED69A4C-- From nobody Wed Jul 29 07:11:17 2015 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 341751A1B98 for ; Wed, 29 Jul 2015 07:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.636 X-Spam-Level: * X-Spam-Status: No, score=1.636 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 GT0C8domufWT for ; Wed, 29 Jul 2015 07:11:14 -0700 (PDT) Received: from mailin.tpsa.pl (mailout.tpsa.pl [212.160.172.10]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11E0C1A1B5E for ; Wed, 29 Jul 2015 07:11:13 -0700 (PDT) Received: from 10.236.62.137 (EHLO OPE10HT03.tp.gk.corp.tepenet) ([10.236.62.137]) by mailin.tpsa.pl (MOS 4.4.2a-FCS FastPath queued) with ESMTP id EHB24063; Wed, 29 Jul 2015 16:11:08 +0200 (CEST) From: =?utf-8?B?Q3plcndvbmthIE1pY2hhxYIgMSAtIEh1cnQ=?= To: Ted Lemon , Philip Homburg Thread-Topic: [v6ops] NAT64/DNS64 and DNSSEC Thread-Index: AQHQxRebhanHpTIC20amYveYP8eqwZ3xqZuAgACAPISAADibgIAAI9cQ Date: Wed, 29 Jul 2015 14:10:39 +0000 Message-ID: <2D29C51862222E49B991EF64EEB0B5B745FC37D9@OPE10MB05.tp.gk.corp.tepenet> References: <4797B33E-9851-427E-8710-84122AFD0FFA@cisco.com> In-Reply-To: Accept-Language: pl-PL, en-US Content-Language: pl-PL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [126.13.107.45] Content-Type: multipart/alternative; boundary="_000_2D29C51862222E49B991EF64EEB0B5B745FC37D9OPE10MB05tpgkco_" MIME-Version: 1.0 X-Junkmail-Premium-Raw: score=8/50, refid=2.7.2:2015.7.29.131818:17:8.129, ip=, rules=__HAS_FROM, FROM_NAME_PHRASE, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __IMS_MSGID, __HAS_MSGID, __SANE_MSGID, __REFERENCES, __IN_REP_TO, WEBMAIL_XOIP, __HAS_XOIP, __CT, __CTYPE_MULTIPART_ALT, __CTYPE_HAS_BOUNDARY, __CTYPE_MULTIPART, __MIME_VERSION, WEBMAIL_X_IP_HDR, __ANY_URI, __URI_NO_WWW, __URI_NO_PATH, __SUBJ_ALPHA_NEGATE, SUPERLONG_LINE, __URI_IN_BODY, __MULTIPLE_URI_IN_BODY, __HTML_FONT_BLUE, __HAS_HTML, BODYTEXTP_SIZE_3000_LESS, BODYTEXTH_SIZE_10000_LESS, __MIME_HTML, __TAG_EXISTS_HTML, __STYLE_RATWARE_NEG, __URI_NS, HTML_70_90, WEBMAIL_SOURCE, REFERENCES, NO_URI_HTTPS X-Junkmail-Status: score=10/50, host=mailin.tpsa.pl X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0C0204.55B8DEFC.0293, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32, mode=multiengine X-Junkmail-IWF: false X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0C0204.55B8DEFC.0293, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d6734786eeedf6031ca1d577d0998c30 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] NAT64/DNS64 and DNSSEC 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, 29 Jul 2015 14:11:16 -0000 --_000_2D29C51862222E49B991EF64EEB0B5B745FC37D9OPE10MB05tpgkco_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TkFUNjQgaXMgY29vbCwgYnV0IEROUzY0IG5vdC4NCg0KDQoNCkZyb206IHY2b3BzIFttYWlsdG86 djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRlZCBMZW1vbg0KU2VudDogV2Vk bmVzZGF5LCBKdWx5IDI5LCAyMDE1IDQ6MDIgUE0NClRvOiBQaGlsaXAgSG9tYnVyZw0KQ2M6IHY2 b3BzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBOQVQ2NC9ETlM2NCBhbmQgRE5TU0VD DQoNCk9uIEp1bCAyOSwgMjAxNSwgYXQgNDozOCBBTSwgUGhpbGlwIEhvbWJ1cmcgPHBjaC12Nm9w cy0zQHUtMS5waGljb2guY29tPG1haWx0bzpwY2gtdjZvcHMtM0B1LTEucGhpY29oLmNvbT4+IHdy b3RlOg0KSSBkb24ndCBsaWtlIGl0IGVpdGhlci4gQnV0IHRoZXJlIHNlZW1zIHRvIGJlIGEgdm9j YWwgZ3JvdXAgb2Ygb3BlcmF0b3JzIHdobw0KbGlrZSBpdC4gTm90IGEgbG90IG9mIG9wcG9zaXRp b24gYW5kIG5vdyBBcHBsZSBzZWVtcyB0byBsaWtlIGl0IGFzIHdlbGwuDQoNCkkgZG9u4oCZdCBy ZWFsbHkga25vdyB3aGF0IGFsbCB0aGUgaGF0ZSBpcyBmb3IgTkFUNjQuICAgSXQgZG9lcyBhIGdy ZWF0IGpvYiBvZiBsZXR0aW5nIG1lIHJ1biBhIHY2b25seSBuZXR3b3JrIHdoaWxzdCBzdGlsbCBj b21tdW5pY2F0aW5nIHdpdGggdjQgc2VydmljZXMgb24gdGhlIEludGVybmV0LiAgTWF5YmUgaXTi gJlzIG5vdCBldmVyeWJvZHnigJlzIGN1cCBvZiB0ZWEsIGJ1dCBpdOKAmXMgYSBwcmV0dHkgbmlj ZSBzb2x1dGlvbiwgYW5kIEkgYWdyZWUgdGhhdCBtYWtpbmcgaXQgd29yayB3aXRoIEROU1NFQyBv dWdodCB0byBiZSBhIHByaW9yaXR5Lg0KDQo= --_000_2D29C51862222E49B991EF64EEB0B5B745FC37D9OPE10MB05tpgkco_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRla3N0IGR5bWthIFpuYWsiOw0K CW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsN Cglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5TdHlsd2lhZG9tb2Np ZS1tYWlsMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uVGVrc3RkeW1r YVpuYWsNCgl7bXNvLXN0eWxlLW5hbWU6IlRla3N0IGR5bWthIFpuYWsiOw0KCW1zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiVGVrc3QgZHlta2EiOw0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQg NzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IlBMIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk5BVDY0IGlzIGNvb2ws IGJ1dCBETlM2NCBub3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJv dW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlRlZCBMZW1vbjxicj4NCjxiPlNl bnQ6PC9iPiBXZWRuZXNkYXksIEp1bHkgMjksIDIwMTUgNDowMiBQTTxicj4NCjxiPlRvOjwvYj4g UGhpbGlwIEhvbWJ1cmc8YnI+DQo8Yj5DYzo8L2I+IHY2b3BzQGlldGYub3JnPGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBbdjZvcHNdIE5BVDY0L0ROUzY0IGFuZCBETlNTRUM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBKdWwgMjksIDIwMTUsIGF0IDQ6 MzggQU0sIFBoaWxpcCBIb21idXJnICZsdDs8YSBocmVmPSJtYWlsdG86cGNoLXY2b3BzLTNAdS0x LnBoaWNvaC5jb20iPnBjaC12Nm9wcy0zQHUtMS5waGljb2guY29tPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SSBkb24ndCBsaWtlIGl0IGVpdGhlci4gQnV0IHRoZXJl IHNlZW1zIHRvIGJlIGEgdm9jYWwgZ3JvdXAgb2Ygb3BlcmF0b3JzIHdobzxicj4NCmxpa2UgaXQu IE5vdCBhIGxvdCBvZiBvcHBvc2l0aW9uIGFuZCBub3cgQXBwbGUgc2VlbXMgdG8gbGlrZSBpdCBh cyB3ZWxsLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvbuKAmXQgcmVhbGx5IGtub3cgd2hhdCBhbGwgdGhlIGhh dGUgaXMgZm9yIE5BVDY0LiAmbmJzcDsgSXQgZG9lcyBhIGdyZWF0IGpvYiBvZiBsZXR0aW5nIG1l IHJ1biBhIHY2b25seSBuZXR3b3JrIHdoaWxzdCBzdGlsbCBjb21tdW5pY2F0aW5nIHdpdGggdjQg c2VydmljZXMgb24gdGhlIEludGVybmV0LiAmbmJzcDtNYXliZSBpdOKAmXMgbm90IGV2ZXJ5Ym9k eeKAmXMgY3VwIG9mIHRlYSwgYnV0IGl04oCZcyBhIHByZXR0eSBuaWNlIHNvbHV0aW9uLA0KIGFu ZCBJIGFncmVlIHRoYXQgbWFraW5nIGl0IHdvcmsgd2l0aCBETlNTRUMgb3VnaHQgdG8gYmUgYSBw cmlvcml0eS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_2D29C51862222E49B991EF64EEB0B5B745FC37D9OPE10MB05tpgkco_-- From nobody Wed Jul 29 07:11:54 2015 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 1B7BD1A1BDD for ; Wed, 29 Jul 2015 07:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.789 X-Spam-Level: X-Spam-Status: No, score=-0.789 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, J_CHICKENPOX_14=0.6, 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 asxE4zYaS4L6 for ; Wed, 29 Jul 2015 07:11:52 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450: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 A57771A1EF3 for ; Wed, 29 Jul 2015 07:11:51 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so28399416wib.1 for ; Wed, 29 Jul 2015 07:11:50 -0700 (PDT) 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:content-transfer-encoding; bh=MSqa0Wk1OvO14PkVFCCeL6alXH+ev01e/VoByQDTe1c=; b=HI1l+roMyUHt9ZOkqyHL0m9XymhoLAg+xJMhRp/kZd75nh25ljZNDSs641+C2ibFZX 6nU6VTFYjhLrB9fdK8Doa03h2f7+X3K/U0xQ6ZFEzNrFWPiYkiGrUyR+TCRvBGxfAmg5 s1YZ3jxHsg80pmlv50o+ADigIgFe214L5MYlHJCjwZzFxnh+b+KRvwfapb1jlG2b1m68 ecI7n7gi4vcAPHoGtkSHnEIRRp6c/3bdPZR2XuwYyKc6ZOXV5kz9shHmey2JENh0s/fr eTNIUnLRmggj2U+6rCoPfJ6NtOtmW3jORYs9Gulv/iVVwMwMqHxPl88yG3pK5HkFy4H9 Ah8Q== 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:content-transfer-encoding; bh=MSqa0Wk1OvO14PkVFCCeL6alXH+ev01e/VoByQDTe1c=; b=lURL9DJ3MjNww7r4o3VNNnuXShbUpqcwgJ8C5nMbkbQbaz2Lly61cpLCWW5yrxreR1 5KXalzMkOolppAv+U/evrAKDrosg4UE/2EDBGttxSo+0lfEsRtdVruBZuCKpsu15rmdl hwz0WQkkBqkIG68qeGllPPWHOK8N2uDZxblH9ZxCNMIk3tloqX6okTuKxmdEqPMKT5R0 zmMA3C11RKfnVYVrk3CeA893xkzu88TGUdnze7xG/WkhywmSbrKCCMHMzNa/wdaVJFXT nb+gzf1c7exdbxWZ5+jQHWqzdRTbng7Fgz/40OaToSGGJUSiXm1TlApIY6gQedFOUYEt E69Q== X-Gm-Message-State: ALoCoQkHKBgLmsatWeFsDlTyMKMo2ffaH7UhAvr1wucHkqnarhFL53q2prLjoKRCNcJdrLr0NeKx X-Received: by 10.194.78.210 with SMTP id d18mr74961866wjx.34.1438179110357; Wed, 29 Jul 2015 07:11:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.138.203 with HTTP; Wed, 29 Jul 2015 07:11:30 -0700 (PDT) In-Reply-To: References: <4797B33E-9851-427E-8710-84122AFD0FFA@cisco.com> From: Erik Kline Date: Wed, 29 Jul 2015 23:11:30 +0900 Message-ID: To: Ted Lemon Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] NAT64/DNS64 and DNSSEC 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, 29 Jul 2015 14:11:53 -0000 On 29 July 2015 at 23:01, Ted Lemon wrote: > On Jul 29, 2015, at 4:38 AM, Philip Homburg > wrote: > > I don't like it either. But there seems to be a vocal group of operators = who > like it. Not a lot of opposition and now Apple seems to like it as well. > > > I don=E2=80=99t really know what all the hate is for NAT64. It does a g= reat job of > letting me run a v6only network whilst still communicating with v4 servic= es > on the Internet. Maybe it=E2=80=99s not everybody=E2=80=99s cup of tea, = but it=E2=80=99s a pretty > nice solution, and I agree that making it work with DNSSEC ought to be a > priority. The suckiness, such as it is, is a feature, not a bug (vis a vis Cameron's earlier comment). From nobody Wed Jul 29 07:12:45 2015 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 F2FF21A21BC for ; Wed, 29 Jul 2015 07:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.609 X-Spam-Level: X-Spam-Status: No, score=-1.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 OwxQBrZjyLdy for ; Wed, 29 Jul 2015 07:12:43 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (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 7D4A11A21AA for ; Wed, 29 Jul 2015 07:12:42 -0700 (PDT) Received: from webmail.nominum.com (cas-04.win.nominum.com [64.89.235.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 6CF98DA008B; Wed, 29 Jul 2015 14:12:42 +0000 (UTC) Received: from [10.0.20.178] (71.233.41.235) by CAS-04.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 29 Jul 2015 07:12:36 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_6AFC33A2-356C-4509-8AFA-033A10A340EB" MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ted Lemon In-Reply-To: <2D29C51862222E49B991EF64EEB0B5B745FC37D9@OPE10MB05.tp.gk.corp.tepenet> Date: Wed, 29 Jul 2015 10:12:34 -0400 Message-ID: <784A7EAE-EF81-4340-B9DC-2CE784E0C8D2@nominum.com> References: <4797B33E-9851-427E-8710-84122AFD0FFA@cisco.com> <2D29C51862222E49B991EF64EEB0B5B745FC37D9@OPE10MB05.tp.gk.corp.tepenet> To: =?utf-8?Q?Czerwonka_Micha=C5=82_1_-_Hurt?= X-Mailer: Apple Mail (2.2102) X-Originating-IP: [71.233.41.235] Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] NAT64/DNS64 and DNSSEC 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, 29 Jul 2015 14:12:44 -0000 --Apple-Mail=_6AFC33A2-356C-4509-8AFA-033A10A340EB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Jul 29, 2015, at 10:10 AM, Czerwonka Micha=C5=82 1 - Hurt = wrote: > NAT64 is cool, but DNS64 not. Not even DNS64 in the resolver? :) --Apple-Mail=_6AFC33A2-356C-4509-8AFA-033A10A340EB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" On Jul 29, 2015, at 10:10 AM, Czerwonka Micha=C5=82 1 - Hurt = <Michal.Czerwonka1@orange.com> wrote:
NAT64 is cool, = but DNS64 not.

Not even DNS64 in the resolver? :)

= --Apple-Mail=_6AFC33A2-356C-4509-8AFA-033A10A340EB-- From nobody Wed Jul 29 08:02:35 2015 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 AD4341A8A3A for ; Wed, 29 Jul 2015 08:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, J_CHICKENPOX_14=0.6, 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 1oj6yLt3kRtI for ; Wed, 29 Jul 2015 08:02:32 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBAD1A8AAA for ; Wed, 29 Jul 2015 07:52:49 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1ZKSiu-0000D6C; Wed, 29 Jul 2015 16:52:48 +0200 Message-Id: To: "v6ops@ietf.org" From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <4797B33E-9851-427E-8710-84122AFD0FFA@cisco.com> In-reply-to: Your message of "Wed, 29 Jul 2015 10:01:35 -0400 ." Date: Wed, 29 Jul 2015 16:52:48 +0200 Archived-At: Subject: Re: [v6ops] NAT64/DNS64 and DNSSEC 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, 29 Jul 2015 15:02:33 -0000 In your letter dated Wed, 29 Jul 2015 10:01:35 -0400 you wrote: > I dont really know what all the hate is for NAT64. It does a > great job of letting me run a v6only network whilst still > communicating with v4 services on the Internet. Maybe its not > everybodys cup of tea, but its a pretty nice solution, and I > agree that making it work with DNSSEC ought to be a priority. I guess it depends on your expectations. Right now, for me IPv4 is production traffic. The moment has not yet come to treat IPv4 as something that may or may not work. But there are an endless number of gotchas in IPv4. And at the moment those gotchas are neatly confined to the IPv4 specific processing. When IPv4 gets incorporated into IPv6 like NAT64 does, then all IPv6 processing suddenly also has to take tose gotchas into account, without even knowing whther the other end was IPv4 or IPv6. In that sense 464XLAT is better because it again makes the IPv4/IPv6 split. In any case, I can see why operators like NAT64 so it is better to make it work. From nobody Wed Jul 29 08:22:29 2015 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 985CB1A884F for ; Wed, 29 Jul 2015 08:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, J_CHICKENPOX_14=0.6, 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 A57VF8QWkWTg for ; Wed, 29 Jul 2015 08:22:24 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 30DF01A8AE5 for ; Wed, 29 Jul 2015 08:04:17 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1ZKSu0-0000DBC; Wed, 29 Jul 2015 17:04:16 +0200 Message-Id: To: "v6ops@ietf.org" From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <4797B33E-9851-427E-8710-84122AFD0FFA@cisco.com> In-reply-to: Your message of "Wed, 29 Jul 2015 10:01:35 -0400 ." Date: Wed, 29 Jul 2015 17:04:16 +0200 Archived-At: Subject: Re: [v6ops] NAT64/DNS64 and DNSSEC 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, 29 Jul 2015 15:22:27 -0000 In your letter dated Wed, 29 Jul 2015 10:01:35 -0400 you wrote: > I dont really know what all the hate is for NAT64. It does a > great job of letting me run a v6only network whilst still > communicating with v4 services on the Internet. Maybe its not > everybodys cup of tea, but its a pretty nice solution, and I > agree that making it work with DNSSEC ought to be a priority. I guess it depends on your expectations. Right now, for me IPv4 is production traffic. The moment has not yet come to treat IPv4 as something that may or may not work. But there are an endless number of gotchas in IPv4. And at the moment those gotchas are neatly confined to the IPv4 specific processing. When IPv4 gets incorporated into IPv6 like NAT64 does, then all IPv6 processing suddenly also has to take those gotchas into account, without even knowing whther the other end was IPv4 or IPv6. In that sense 464XLAT is better because it again makes the IPv4/IPv6 split. In any case, I can see why operators like NAT64 so it is better to make it work. From nobody Wed Jul 29 13:58:01 2015 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 1FE861B2B4C for ; Wed, 29 Jul 2015 13:58:01 -0700 (PDT) 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 zPSHcgiB-ZYO for ; Wed, 29 Jul 2015 13:57:59 -0700 (PDT) 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 46C461B2B1E for ; Wed, 29 Jul 2015 13:57:58 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 5CEA560613 for ; Wed, 29 Jul 2015 22:57:56 +0200 (CEST) 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 2915C600DF for ; Wed, 29 Jul 2015 22:57:56 +0200 (CEST) Received: (qmail 25285 invoked by uid 1007); 29 Jul 2015 22:57:56 +0200 Date: Wed, 29 Jul 2015 22:57:56 +0200 From: Gert Doering To: "Fred Baker \(fred\)" Message-ID: <20150729205756.GR84167@Space.Net> References: <4797B33E-9851-427E-8710-84122AFD0FFA@cisco.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="p8BcnzLwh3ipgLRM" Content-Disposition: inline In-Reply-To: <4797B33E-9851-427E-8710-84122AFD0FFA@cisco.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] NAT64/DNS64 and DNSSEC 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, 29 Jul 2015 20:58:01 -0000 --p8BcnzLwh3ipgLRM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Jul 29, 2015 at 03:00:01AM +0000, Fred Baker (fred) wrote: > Between us girls, I don't think many of us really like NAT64... I think it's the best thing that happened in quite a long time :-) So, yes, I like NAT64, when the alternative is "client network with dual-stack IPv6 + NAT444'ed IPv4". Dual-stack is an annoyance, dual-stack with NAT44(4) stinks. gert --=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 --p8BcnzLwh3ipgLRM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVbk+U99WwGXkzn/FAQJV0A//cTeCxQjWgYc4iUrxIPXKgbBGjh8paF6D N8dPww96vGuL37zi4rxeFf4CzeL3vT6fc2Sh11y4VqW9Sle4EEppEVAeSxKCxiow 7vyg6awhAO7gF+Pv9v9+NmoziugGiCEq6vYbnQOv8zOFz8ZNSuIa489iJakhtk/A AbY+CNlkBmr8RyvXm39kfg+/rC6xdotq1FF86+yE4WGn6jLWXgXIqDcZljWcH/fP tayTbOMBpUaAdido73XUQG0jG1h12CGU1vLTdcIwXoUKx/6WiTbhiAop5Wg8m31N /pmO/MKitSXQsJw784eboPC2H3Xrbm+vg8yCypv4zaDu8+qIw6sycdgb+fuGiiDV KLvIf2YY6qZtlfhA6AOMvXxECASCaoeUrl6GUFxewvTP8iaogD1x+uqI4CYdb09f lK6YFEfHddlTzOm1UuBPWejldfAp2auhL2pYIQ4k2atz3Awl9iw1Of1ReZt/TXAz xDj2YRagbQAfGpo4z13TOHZq44AcJ70017z4eF4OXMmQFcbKzQCJn5Io+fn2Gu+S +XsqzLtmF63V/U8RYfIZFhdWj+sEW5AekQfRcIKw12FsNy1J4L5kvCq2bXE0m/JG 0J8qnU7nuZax3HKuWI2UEcsHK9Fcj5ppKG888PSImpqr0KWZMxXAPZNlAcSXxjVO 8+yD9Y5C/vU= =4rJU -----END PGP SIGNATURE----- --p8BcnzLwh3ipgLRM-- From nobody Thu Jul 30 08:05:44 2015 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 943CE1B2CF9 for ; Tue, 28 Jul 2015 11:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.6 X-Spam-Level: X-Spam-Status: No, score=-4.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 s8QHS9J-vrNe for ; Tue, 28 Jul 2015 11:16:54 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 850C71B2D27 for ; Tue, 28 Jul 2015 11:16:53 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1ZK9Qp-0000CWC; Tue, 28 Jul 2015 20:16:51 +0200 Message-Id: To: IPv6 Operations From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> <55B1ED14.6030501@gmail.com> <20150727091241.GL84167@Space.Net> <20150728115944.GZ84167@Space.Net> <4AB2ED61-23CF-40D5-B2A6-F1F4064EC0C6@nominum.com> <90E6B48E-B3FC-4AAD-B356-7D92A2777632@nominum.com> <804F2F0B-B0EF-4054-99C5-C0CD8957C434@nominum.com> In-reply-to: Your message of "Tue, 28 Jul 2015 14:00:51 -0400 ." <804F2F0B-B0EF-4054-99C5-C0CD8957C434@nominum.com> Date: Tue, 28 Jul 2015 20:16:51 +0200 Archived-At: X-Mailman-Approved-At: Thu, 30 Jul 2015 08:05:42 -0700 Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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, 28 Jul 2015 18:16:55 -0000 In your letter dated Tue, 28 Jul 2015 14:00:51 -0400 you wrote: >On Jul 28, 2015, at 1:58 PM, Philip Homburg = >wrote: >> Is is not like ISPs can just hand out /40s to everybody from their PA = >space. > >Yes, this is what I=E2=80=99m saying. Looking a the RIPE region, you can easily get a /48 PI or an ISP can give a /48 to its customers. This is enough for all but the largest organisations to give every device /64. RIPE members can easiliy get a /32 or even a bit shorter. That is even for the largest organisations more than enough to give every device /64. From nobody Thu Jul 30 08:05:45 2015 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 125411A87A1 for ; Wed, 29 Jul 2015 07:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, J_CHICKENPOX_14=0.6, 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 t4iiHXnu_Cwc for ; Wed, 29 Jul 2015 07:35:54 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id C9DE61A87A7 for ; Wed, 29 Jul 2015 07:35:45 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1ZKSSO-0000DCC; Wed, 29 Jul 2015 16:35:44 +0200 Message-Id: To: "v6ops@ietf.org" From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <4797B33E-9851-427E-8710-84122AFD0FFA@cisco.com> In-reply-to: Your message of "Wed, 29 Jul 2015 10:01:35 -0400 ." Date: Wed, 29 Jul 2015 16:35:44 +0200 Archived-At: X-Mailman-Approved-At: Thu, 30 Jul 2015 08:05:42 -0700 Subject: Re: [v6ops] NAT64/DNS64 and DNSSEC 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, 29 Jul 2015 14:35:56 -0000 In your letter dated Wed, 29 Jul 2015 10:01:35 -0400 you wrote: > I dont really know what all the hate is for NAT64. It does a > great job of letting me run a v6only network whilst still > communicating with v4 services on the Internet. Maybe its not > everybodys cup of tea, but its a pretty nice solution, and I > agree that making it work with DNSSEC ought to be a priority. I guess it depends on your expectations. Right now, for me IPv4 is production traffic. The moment has not yet come to treat IPv4 as something that may or may not work. But there are an endless number of gotchas in IPv4. And at the moment those gotchas are neatly confined to the IPv4 specific processing. When IPv4 gets incorporated into IPv6 like NAT64 does, then all IPv6 processing suddenly also has to take tose gotchas into account, without even knowing whther the other end was IPv4 or IPv6. In that sense 464XLAT is better because it again makes the IPv4/IPv6 split. In any case, I can see why operators like NAT64 so it is better to make it work. From nobody Thu Jul 30 08:25:15 2015 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 D9DE01B29B3 for ; Thu, 30 Jul 2015 08:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.211 X-Spam-Level: X-Spam-Status: No, score=-6.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 NJOTdaG7clzZ for ; Thu, 30 Jul 2015 08:25:12 -0700 (PDT) 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 384BA1B2C30 for ; Thu, 30 Jul 2015 08:24:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t6UFOwqr007276; Thu, 30 Jul 2015 10:24:58 -0500 Received: from XCH-BLV-107.nw.nos.boeing.com (xch-blv-107.nw.nos.boeing.com [130.247.25.123]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t6UFOokj007199 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Thu, 30 Jul 2015 10:24:53 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.231]) by XCH-BLV-107.nw.nos.boeing.com ([169.254.7.113]) with mapi id 14.03.0235.001; Thu, 30 Jul 2015 08:24:49 -0700 From: "Templin, Fred L" To: Philip Homburg Thread-Topic: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-01.txt Thread-Index: AQHQyWGTGTvNaKRRoESx6jY9+5U45Z30IniA Date: Thu, 30 Jul 2015 15:24:49 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832ED29AC@XCH-BLV-504.nw.nos.boeing.com> References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> <55B1ED14.6030501@gmail.com> <20150727091241.GL84167@Space.Net> <20150728115944.GZ84167@Space.Net> <4AB2ED61-23CF-40D5-B2A6-F1F4064EC0C6@nominum.com> <90E6B48E-B3FC-4AAD-B356-7D92A2777632@nominum.com> <804F2F0B-B0EF-4054-99C5-C0CD8957C434@nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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: Thu, 30 Jul 2015 15:25:14 -0000 Hi Philip, > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Philip Homburg > Sent: Tuesday, July 28, 2015 11:17 AM > To: IPv6 Operations > Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availabili= ty-01.txt >=20 > In your letter dated Tue, 28 Jul 2015 14:00:51 -0400 you wrote: > >On Jul 28, 2015, at 1:58 PM, Philip Homburg = =3D > >wrote: > >> Is is not like ISPs can just hand out /40s to everybody from their PA = =3D > >space. > > > >Yes, this is what I=3DE2=3D80=3D99m saying. >=20 > Looking a the RIPE region, you can easily get a /48 PI or an ISP can give > a /48 to its customers. This is enough for all but the largest organisati= ons > to give every device /64. I agree. We also need to remember that each device that gets a /64 can connect countless billions of other devices using the available /64 prefix space. > RIPE members can easiliy get a /32 or even a bit shorter. That is even fo= r > the largest organisations more than enough to give every device /64. I agree that large organizations (like Boeing) can get more than enough prefix space to satisfy their enterprise device numbering requirements. A single /32 would yield 4B /32s and should satisfy all future scaling requirements for the organization. Also, again, each device that receives a /64 can connect countless billions of other devices. Thanks - Fred fred.l.templin@boeing.com > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Jul 30 08:38:06 2015 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 14A131A888B for ; Thu, 30 Jul 2015 08:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 wqOSubZRUnff for ; Thu, 30 Jul 2015 08:38:02 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 133511A7020 for ; Thu, 30 Jul 2015 08:38:02 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1ZKpuC-0000D4C; Thu, 30 Jul 2015 17:38:00 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> <55B1ED14.6030501@gmail.com> <20150727091241.GL84167@Space.Net> <20150728115944.GZ84167@Space.Net> <4AB2ED61-23CF-40D5-B2A6-F1F4064EC0C6@nominum.com> <90E6B48E-B3FC-4AAD-B356-7D92A2777632@nominum.com> <804F2F0B-B0EF-4054-99C5-C0CD8957C434@nominum.com> <2134F8430051B64F815C691A62D9831832ED2 9AC@XCH-BLV-504.nw.nos.boeing.com> In-reply-to: Your message of "Thu, 30 Jul 2015 15:24:49 +0000 ." <2134F8430051B64F815C691A62D9831832ED29AC@XCH-BLV-504.nw.nos.boeing.com> Date: Thu, 30 Jul 2015 17:37:59 +0200 Archived-At: Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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: Thu, 30 Jul 2015 15:38:04 -0000 >I agree. We also need to remember that each device that gets a /64 >can connect countless billions of other devices using the available >/64 prefix space. I'm not saying that we should give every device a /64 using DHCP-PD. SLAAC is probably a much better way to distribute addresses locally (at least as long as we don't mess up IIDs completely). But, the addressing architecture does allow for one /64 per device. So when needed, it is better to use that space than to add all kinds of complexity while trying to save a few bits. From nobody Thu Jul 30 08:49:25 2015 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 08C771AC3C8 for ; Thu, 30 Jul 2015 08:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 RLEzPsC4LEvN for ; Thu, 30 Jul 2015 08:49:22 -0700 (PDT) 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 DD39B1B2C4A for ; Thu, 30 Jul 2015 08:49:20 -0700 (PDT) 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 t6UFnK35014383; Thu, 30 Jul 2015 08:49:20 -0700 Received: from XCH-PHX-213.sw.nos.boeing.com (xch-phx-213.sw.nos.boeing.com [130.247.25.142]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t6UFnGvb014363 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 30 Jul 2015 08:49:17 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.231]) by XCH-PHX-213.sw.nos.boeing.com ([169.254.13.201]) with mapi id 14.03.0235.001; Thu, 30 Jul 2015 08:49:16 -0700 From: "Templin, Fred L" To: Philip Homburg , "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-01.txt Thread-Index: AQHQyt22GTvNaKRRoESx6jY9+5U45Z30J2yA Date: Thu, 30 Jul 2015 15:49:15 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832ED2A37@XCH-BLV-504.nw.nos.boeing.com> References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> <55B1ED14.6030501@gmail.com> <20150727091241.GL84167@Space.Net> <20150728115944.GZ84167@Space.Net> <4AB2ED61-23CF-40D5-B2A6-F1F4064EC0C6@nominum.com> <90E6B48E-B3FC-4AAD-B356-7D92A2777632@nominum.com> <804F2F0B-B0EF-4054-99C5-C0CD8957C434@nominum.com> <2134F8430051B64F815C691A62D9831832ED2 9AC@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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: Thu, 30 Jul 2015 15:49:24 -0000 Hi Philip, > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Philip Homburg > Sent: Thursday, July 30, 2015 8:38 AM > To: v6ops@ietf.org > Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availabili= ty-01.txt >=20 > >I agree. We also need to remember that each device that gets a /64 > >can connect countless billions of other devices using the available > >/64 prefix space. >=20 > I'm not saying that we should give every device a /64 using DHCP-PD. SLAA= C is > probably a much better way to distribute addresses locally (at least as l= ong > as we don't mess up IIDs completely). You can't give a device a /64 using SLAAC; SLAAC only allows for autoconfiguration of singleton addresses taken from an on-link /64 prefix. If you want to give a device a /64, the only choices I am aware of are administrative configuration or DHCPv6 PD. That said, once a device has received a /64, address delegation from the /64 could certainly use SLAAC. Thanks - Fred fred.l.templin@boeing.com > But, the addressing architecture does allow for one /64 per device. So wh= en > needed, it is better to use that space than to add all kinds of complexit= y > while trying to save a few bits. >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Jul 30 10:16:40 2015 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 754921ACCFF for ; Thu, 30 Jul 2015 10:16:40 -0700 (PDT) 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 fblEWfOu-iOg for ; Thu, 30 Jul 2015 10:16:39 -0700 (PDT) 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 43CF81ACCFE for ; Thu, 30 Jul 2015 10:16:39 -0700 (PDT) Received: from [2a02:c0:2:1:1194:17:0:1029] (port=44808 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1ZKrRW-0004LV-Fb; Thu, 30 Jul 2015 19:16:30 +0200 Date: Thu, 30 Jul 2015 19:16:29 +0200 From: Tore Anderson To: "Templin, Fred L" Message-ID: <20150730191629.1817894a@envy.fud.no> In-Reply-To: <2134F8430051B64F815C691A62D9831832ED2A37@XCH-BLV-504.nw.nos.boeing.com> References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> <20150727091241.GL84167@Space.Net> <20150728115944.GZ84167@Space.Net> <4AB2ED61-23CF-40D5-B2A6-F1F4064EC0C6@nominum.com> <90E6B48E-B3FC-4AAD-B356-7D92A2777632@nominum.com> <804F2F0B-B0EF-4054-99C5-C0CD8957C434@nominum.com> <2134F8430051B64F815C691A62D9831832ED2 9AC@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832ED2A37@XCH-BLV-504.nw.nos.boeing.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; 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" Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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: Thu, 30 Jul 2015 17:16:40 -0000 * Templin, Fred L > You can't give a device a /64 using SLAAC; SLAAC only allows for > autoconfiguration of singleton addresses taken from an on-link > /64 prefix. Hi Fred, Actually, SLAAC works equally well with off-link prefixes. There is no inherent requirement in SLAAC that prefixes from which the addresses are auto-configured must be on-link; the L and A bits in an RA's PIO are completely orthogonal. > If you want to give a device a /64, the only choices > I am aware of are administrative configuration or DHCPv6 PD. True, although 3GPP networks is an exception. There a /64 prefix advertised to the UE via standard RA/PIO with SLAAC can be treated as if it was a delegated prefix. RFC7278 depends on this. Tore From nobody Thu Jul 30 13:44:23 2015 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 B1B1F1A889F for ; Thu, 30 Jul 2015 13:44:21 -0700 (PDT) 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 fLzIC7cUaBXk for ; Thu, 30 Jul 2015 13:44:20 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF1031A8894 for ; Thu, 30 Jul 2015 13:44:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=136161; q=dns/txt; s=iport; t=1438289059; x=1439498659; h=from:to:subject:date:message-id:mime-version; bh=EQzKIXVGrv17PK/SoQ3yklX+iy3ZqP+DkykDiSrEN4U=; b=AkfiHeNBZXHJJmw30kuBlVA2QNq0WyOpz8dUFYZFG6xv5Dv5bEA39TOG o3md4y6S2SJkGhjz0aoeP7+PPAAzT5d75Rb7QC6YhnopLCKUCOhCP1TsY AlCJabz7Ri1RZEGUgtKl+2wdHB8TFn+sskHyINis4Su1LwivvUqW6F8af Y=; X-Files: v6ops-proposed-charter-v4.txt, Diff: v6ops-charter.txt - v6ops-proposed-charter-v4.txt.pdf, signature.asc : 2303, 96110, 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CBAwBxi7pV/4UNJK1SCoMagUO8GwmJPjgUAQEBAQEBAYEKhCYERUYBUBgYJwQhBgeIE59DpVoBAQEBAQUBAQEBAQEBARqPeIN8gRQFkWKDFQGCOIFZiDcBgUaEIIQDj08mg32CN4EEAQEB X-IronPort-AV: E=Sophos;i="5.15,578,1432598400"; d="asc'?pdf'?txt'?scan'208";a="14525614" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-8.cisco.com with ESMTP; 30 Jul 2015 20:44:18 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t6UKiIFB023862 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 30 Jul 2015 20:44:18 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.49]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Thu, 30 Jul 2015 15:44:18 -0500 From: "Fred Baker (fred)" To: v6ops list Thread-Topic: Charter discussion Thread-Index: AQHQywiADmYeScSbRk+poTZsQA0/ow== Date: Thu, 30 Jul 2015 20:44:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.117] Content-Type: multipart/signed; boundary="Apple-Mail=_69E2A66B-0AB5-4C03-957F-CD630E75FEEE"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: [v6ops] Charter discussion 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, 30 Jul 2015 20:44:21 -0000 --Apple-Mail=_69E2A66B-0AB5-4C03-957F-CD630E75FEEE Content-Type: multipart/mixed; boundary="Apple-Mail=_B875ED9D-FF16-4C45-B76C-49733D130623" --Apple-Mail=_B875ED9D-FF16-4C45-B76C-49733D130623 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii As we discussed last week in the f2f meeting, here is a proposed new = charter for v6ops. Comments please, with proposed text (e.g., old text = and new text) for any changes you'd like. --Apple-Mail=_B875ED9D-FF16-4C45-B76C-49733D130623 Content-Disposition: attachment; filename=v6ops-proposed-charter-v4.txt Content-Type: text/plain; x-unix-mode=0644; name="v6ops-proposed-charter-v4.txt" Content-Transfer-Encoding: 7bit Charter for Working Group The global deployment of IPv6 is underway, creating an Internet consisting of IPv4-only, IPv6-only and IPv4/IPv6 networks and nodes. This deployment must be properly handled to avoid the division of the Internet into separate IPv4 and IPv6 networks, ensuring addressing and connectivity for all IPv4 and IPv6 nodes. The IPv6 Operations Working Group (v6ops) develops guidelines for the operation of IPv6 networks, and provides operational guidance on how to deploy and operate IPv6 in new and existing networks. The main focus of the IPv6 Operations Working Group is to look at the deployment and operational issues in IPv6 networks. The goals of the v6ops working group are: 1. Solicit input from network operators and users to identify operational issues with the IPv6 Internet, and determine solutions or workarounds to those issues. 2. Solicit input from network operators and users to identify operational interaction issues with the IPv4 Internet, and determine solutions or workarounds to those issues. 3. Operational solutions for identified issues should be developed in v6ops and documented in informational or BCP drafts. These documents should document IPv6 operational experience, including interactions with IPv4, in dual stack networks, IPv6 networks with IPv4 delivered as an overlay or translation service, or IPv6-only networks. IPv6 operational and deployment issues with specific protocols or technologies (such as Applications, Transport Protocols, Routing Protocols, DNS or Sub-IP Protocols) are the primary responsibility of the groups or areas responsible for those protocols or technologies. However, the v6ops Working Group may provide input to those areas/groups, as needed, and cooperate with those areas/groups in reviewing solutions to IPv6 operational and deployment problems. Future work items within this scope will be adopted by the Working Group only if there is a substantial expression of interest from the community and if the work clearly does not fit elsewhere in the IETF. There must be a continuous expression of interest for the Working Group to work on a particular work item. If there is no longer sufficient interest in the Working Group in a work item, the item may be removed from the list of Working Group items. --Apple-Mail=_B875ED9D-FF16-4C45-B76C-49733D130623 Content-Disposition: inline; filename="Diff: v6ops-charter.txt - v6ops-proposed-charter-v4.txt.pdf" Content-Type: application/pdf; x-unix-mode=0600; name="Diff: v6ops-charter.txt - v6ops-proposed-charter-v4.txt.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvYmoKPDwgL0xlbmd0aCA1IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAHtvdtyZceRJfi+v+I8gmZF8NzPQc1TlaparTGbblWLYxqz UT+ASCQTI1xSQCYpzdfPcvdwXx77vpEgmWXTVWZU5soTHrH9Fh4eHhF/W/3H6m+r9ep0tV09rPbn q6P9+b78+dvj9nA8r+7xk/jjh/j9n1ePq8N+ddqdVw/N4XC+XK93V/rX+xX/elR4AyLyW/7tQ7Rd CaHvfveyWd28rDbNZrVZvdzwXw+H0+XVcX8Oyv5X0NodNkdSLn9zys3D6j1orS+P+9P6cD5j4EIX zU7nzRbkDpdX280VvlzGft6ud8Qw2sC2h8vj9nzVAIu2BUPf6C1QUnyv7dv97Na7y/15v2+i7/uV Y6sTaUrf1pYY+gk09dOwPdHd+nh53p9O+XuIkSbbFgzf+CGNiBTfAxWakHWMHXw7bC+3ByIid0NI j+3Yr/TRpQaetehJD3v0oGpl0hIpBEaK3pII+NWh9h7KcFhvoOZQBv9TE3+q1GO72VyqDNIgAkuD 2K43kOl5J2pYFKFJWFKPaC16ub682un/9f4p6SmJJT1NHYSebs5Xl5urzT4NZJUwDiRTTHoaNB+o AYElPU00XSObhCU9jdbywaFrCQ2dDOwe+lx0N9GMtglLehqtrZ+iWY7CDRRNcEQ4ZLqR6IVGJizp qbdVp9Kml1UkqYPraaLY6lftrUtN3Ja7wXAurtpJDVouQ1xYc9qcL68Op6wFhKgEdDemjaeijeIv y58b0cLwOew+pJG6J8buo6lB9q0Bkp59LaxQh7AXKwxhRBchREfUEZiziS7ZLKAkQm8Jh58ZrJrQ pH/s9y/uh4JyEVvF3A4t2FcIsLTM8iMx8MVmoA2+6XzYJvlBpIFlAQY98SY98lN3Fvy2X0N9e0SV oOiJkq9679IbFV+MscOtALzHYvkyw+QeOzLtkR5amNLTELMduB0mup3eZR4v80XQovCKCBA1VNKT oQODOwnxrREsrK8qJ4zgwzGKL1OcJ7/SWSVAw2AKlCA7owSJYQCUYFBsiVAMP7E9fhYMKki40fSF bFc6VbMnqqJVPnZssMjdmFzLzJhcsCZ150OqvtDlGAOnIFfRloKs6Lkgj1fQqN3pkOxwlTAKMlN8 j1hi0hB9qFmQjlGQTeosRJawLEhv7ZbR60r5lWIkYA3iNm8YgkwdhMgSRmeaqfUI0gnTHuvOijN1 0vTljoDt+MLWMOX7wp3GLynIEJDQoyDxrceDLhPcFR+vAkuCTBSTRWI9QqHmGTH9PKwvMAoSg/LO miRIx+Qz3SKj9agg+ZUhyGiYBBkdJEEGRkFmal1BBuEkyMCksxBkkDahQX0DCUFGy5Yg5ZebU3at 1hoYBdkcz4fLw/lKlqNUAmKVIINiEqQuBftCm+gsWWRgWZDsjCIrmHo5ovrx+kkt11oFN9FJEqSN PBkEO6UgiVWCTF/N+FFtqIjDmFwLzZgcGEkX60tsd0FmatkivW22SMcoyNXxBNe6yXJsCGUxeltR F9rgoD2Wn+cQJw2eNsruw/ACQvcBkt6oEDnKLsccMfqQKmWYuiRIWj22yH90u6tsIkQYlOves0sN vmRLLFLYbypLVGrAKgFC0/bbHKNCqIFRhJmiiHBqyRus905pkSSVLZKdUmzEsjBJ8b1mmDTHRMbz nyum2XfbNJS+0NthUOmrHS0KrnyEeXhrUXrjbS2p0od50kwxWqY+Agtq2QB9NDTAih7Yq2uM4xGe 9IR0V/akxCg/ShV6gthmvvzKkCk/kqL8mjyQkH01kED5ackyEsetQ671k2ScZyTMdsSyJy2d5bV+ 0MszoQ8KfAyZkmKrX5siXBuCQVl+3pbyW7VYZPKDsmMi3MssESFNwczKAyXFGS6U8shycxKU2+rI zmh3xGh3meKoE/VOhLtgzaH6bkWa1CnllzslSmpJWVqEVVU8fPEGWZAk7S2J4AvrYZqqBNv1l/tD 5UgdQx9hiEJku62SNceCmbr0UJwhyCIgHYDPe4V/wCpBcgBhahwUBZkpmgPtXWTknzmH0ncXnrED FxkGFwPJhuhtZZpqhTR1Vy7I0kAsIyySpGNIqbPAxKaUY9kiS1tRlj6hBbaHRz0gq5wtklj2qKQ4 T5BlqNki+UEULjuTgWri+kisEmRQHLFICoQWyW6dZ+zABbmqOnU0U+sTZIyoX2gu3NKdChdN4CQ4 AFqkDzOHNvxlFmSiF4LcQQ1O56tKkMSyIL1v6Semxt5Jslo1spkLj4PLllk6lY8NgVYDCZQUE2+d 9SQue3RtrjlCwmxHLFuk80y526InqtKSlfAxMFJs9Wu+rkMtG6K2rR1qgYxBNjHu8IHr3UaYFp6z YBhJll7Qm2GFzTF+TZlF7wmy3uWbQzhV7wVN9EZMcMVeK3ZpSqrwit+b5BajyHKLL0g60iJL8cUA K+kF3WgXCK0v9eMiALXyw2x8jmXxYU/gsLNcX4iPGMWXKc6QHzgZA+hIC7pCjJ1RgsQwgI5cfWaK 6bBKnqaOu0xzhB1QiAVTwyDKz+iTYnxjsriQkGMNtvSDyUWLiCQ5BrVshfLL7WmX4hqjJ1gWJFLo 58OhTp4SoyBXOhqjOCd5mn5eC80G4FhzZGcUGbEsSH7SiC3yK8VIwBrMPd5QbMQQdkCREaM1Zmo9 gnTCtMe6M3exhbQ4u84AKEhSy4L0YWWLTPSg5uZQka7fnHd18pRYFiQpLpoO2cyFt0rCS5gNRD42 bLAaCNGie26ZrZV+dBjToSOJj/HVSZCBUZAx1Gql6PSy/ByTPkJ+QTHkFx9J+XlLnXDDK/qnV/Ij vZAfEvGHzeYkbIu2BWtNiKSY5MfAhn+qtoWPbNaRFTogxk4pPw4uGyQpJtvoykG4W8yO361Ic2Rn bEeskl9pm8MZDsBlBX+S+nD5kaKPhEiSX+6hyMBGiCg9OdKVjlowU3G1vwN2oc67QxWOJoz2lylO yK/aFo5Oub4gqSS/1GnIL2FZfsIE+7TeTBv/OXOtfLdJNBF2+TUJy/IjNXi3og/EXH4Vb4v9ZYql ZdVHl1ryn/FL2l9Fz+3vgI2AzdEyfG5/CaP8Vonikkxbaha2Fhjlh8FxIO4pE5bkF637/af/s6ZP 1P4cEb11+UVnLj98X2BJft42+0/HxDbcVwaW/Gei2OpXo6bAigVV/tParqvt/MCy/SHnLsVd2X8e Clb7z2gt/UxuVhR56ACS3IRFwCg3THY2gOIUdF2fMMotUxwJZIoc7MuztLRb4xm2KaNTyo9YJb8y 5EpZgvX2j6oqxWkGm7IgSdpbEsEX1sM0VQlj8l/SENs8M0eKBP8Zlih8jLYFM3UJlBRnCJKdJQda 8c8qPleHNIAwQGIUZKY4lmmLTmIiDER4a6bJDlyQTRpIFmT+6namLQhniywNxDLCStlddwAUZO6q K4wsyEQvPCpy7pu9ZjFT28DQSwiytFaFmbRICoiCJEaLBP+iM86ExLIgffhuHLFGzLvAFAgF6Q2T IKNTFyQGFxgFmaml8KktjizI3JlbaSGtwi2alDrrUstTo7ZdH3NoY0NdH4VeCBI59/0RVdnAQmTE KkFK30oxWeRgXYZ3hgHQtfqgKEj06gNgXQaxXJeRKI661tKJ+rvENYycgoxOuRVcddoSL3jm2mNV 8W7YwZJkfQWTzlyQ7M6E1lSdhSCDWhakt80W6RgFqZX/p6tjHaNCzAXLgvTWg3NktbaIoWZBOoks SHZGiyyY+fZwuN7aedprkdQMWmRpmAyCnVJkxGiRmVrHIimObJE+yixIknahEQGLVS0ytSxI/2UW pGMUpBLZILMBqBikLpENymL0toNirJYYchREdAGKTHt0EpUYoYXWfcgLnxXdEwx6o9boXVCIjghf zT6NPqSaZMguE1jU2fWmskUnSxFWNhG2GB9T9w5+uwAxrtRRSwqbqi5DaGxwokCkFS4Vyfn9Hmd5 KEEcowmMIixyVYrJpeYKqZYIS2eVCA1T5nmQw85kUBatEsMAAvXhO0fDEqv8aXxlEiK/GzSgL+kL KbDSqZo/0XantRjjG+k+vYFojLnUJnXncqy+sAzKW8r3uSA5VFpiRS8EiSz66WQ51ZgbiVGQmeKc /GkMPguSw3f7bA7sjCIjlgXprTuCrIMc/qzLNUfYAUVGjC6VPPNOK0HmrnwedIyCXPk3Jp+eO/NB ectakPrL3b4Kcgom9ChIKNXazqhRkIFlQZJissjhIIc/d6GVD8KgslPFloENIAU5gVVBDimOulX/ SlqkNxTemkWygyRIHwg6Tago+m7fH+Q4YTrW/I1ukcCCtA0A6hsIWOyDsq4gsmyR/ktaZEWvCLI5 II2+315VlRoJqwRZ+pZ+epcddZDDASRBxvCJpQGEEy2Yerlkp2kAspQL15otkl+ZBGkNk0GwU4qM WCXIVqfJIimOSpDxjRQkSbvQiLggM7UsSP9lFqRj2SKRTz9hDZzmyOZALAvSWw8Ksp4jy8+rMMdJ ZItkZxQZMQygI14ZwIggvRMK0hFaZOkAoqUgc6dEva13mgS5Co2nICvLiFCHpF2QRFyQmRoFWYSB E59ZkNoaWCXIrWxSJTmuDsjSG0QxZnoD9liL0bvKM2TBlHse6kRflFdAWYik1xJiHejwZxXH7JuL Bwv6lJZB6gASKCquHLQuKxHmjnx2dEz0xcOc6CzGk5jrA0odMcgpLSk/yMDbCrMsIYcs/X5jWceY GYlRgCHVygyHJ8bona4zeifEnlx8zYFYJT8bupvDgDONXo1b+YsLr0idgiKWXWnQUunhS6V+yDnu o3FBBXsou1X6Em9XelJFcSz1Q+H5kCi9ipyLb4+NKRz8rxLjjsEks/hIcYb9UQrZ/pxEcqOpM5fg KmGUYKbYssB6PvROxLdZGOOIu9EmdRBCTFgWord1vamkWP4RUwXF6A2SHBPpMqSE4AvrYWoMFYK0 X+6rCDUw9EFBQqNQy5D9KJaQipm2uHVG68oQB9eM6edudoV/GFQlSA7AZz4fgGkSUdE5/aSxxHjq uOKadhtIdOqCxOACS4JM1LrONP1jCNIxMC9hQbo7gBCkt6wjVB+WKEuf0AJDWn13ZbnGEBmxZJGJ 4gyLhFWVwSeLDIyCbPbsjBZJjBaZKY5YJAUSFpm6dT6yAxck7i4JTlCQmVqfIOMb+4VWZkonrcJV J+GIqapZZAxTLIUWKcM6H6tzbtoamNALQSIhf9rgvhNgIUhiWZCkmAQ5ODV6Z9Avt0jjlQyKglzt ozOuGYnlNWOiOCLI6ET9Hblm3bogo1NGqFWntXiFZ32uNY2IgnQ2ZYtkdzaApurMB+Uta0F622yR jlGQoAil2lenbAhlMXrbQcdarRhjoFmMTqISY3QfHtRGZH6dYNE352d/iJO6de6UTpMxxBdTWgHR Fqlh3mWaHSmINDtG55UI4/uK2aWu2kJtCdBaVvILYmGHSMPvTpZhLXbY7IlVAnR6yQyHJ8YihEp8 3jsNkz3RmxLL3jTojdpgYQ59aXDLxRnUeRND9b0dmfZID6J1Xrj9ZTvwBWKi2+ldHEwt0Cw8EwFO Y+X1oZITjNa32oNtx6tDbX7EKL5McZb8hE82gFpawGAKxNgZJUgsS5AUWyKs1ojxlZShNxSzMMfK DiiugqnZE/W2vVLkP7oYV9E9bbDJTO4MgHIktTwf+lBphhW9sEMQXm81rcn5kBgFSZHjk3oPYsQx jWrJHx+RLdIHR4FicBxIOE9iWaDeuuItWe8CoSC9QRJkdJbaBZadKamBuxgPgvn0SZRf7sPjGQ4/ WlofNkd0qFXywy83V9WZDGWRYNkQkUHf4TIymSYinikYflfJLyjOMESThw0gGV0hQbmtUC2iAyiD 0l2phFFumWLLEKulYnxlkl90a3xsUgeUHwdSyS99dbv0xrvS0CkLrTA5HCpJuyCJ4AtdkNaVhk5d YdAQ2zzTlA0uf7s8ng51YFowU5eOeEX/e3PgtQH6UGmANf9Kzi0PIAyQg6IgOXzxBMOp0xASBelD oSGyAxdkkwaSBeltK6t31vMfaZEFE8sIQbI7b0mEgiS1bJHll6Is4T3ZOmFQA7mrMVsk9iEKhl5C kKQ4S5DeGQW5SrxyKwX/ojMZlFkksSxIUhyxSAqEgvSGSZDRqQsSgwuMgszUrNMUnvJ7pCu3yNxZ YEZahWtOOXfWFq7oTGJ7Hd7scmTT7JGi3+HiqUp8xCrxCZ1hyaX1HbqohCY9urxWuceQV9VjQUWy 2uOIzekv4vP1y4p3IkUXUP5WCkjEFr3UshE8icWom0QyLe+ePdK0Cm0Kw39Eq6pIhaUhi457hrTL sB9iWSykuChOYbM+yTjW7NkprYtYti5STIruzA+x6+RjKuwNaFUkzHbEstBKW5t8WiLPUst9uDGR oouuIDbxdKhlY/K2lN+qxSKb3nDhJy5VqG5V2BcMxpDlR4rDtqUuWDwb5ZENzElkK2NnSW42KBtA WJm39plmYMnOn7W4Jq5DeYbBRQdJfoFl+ZFaUpYWYVWVPqEFFqSjZSC0wdKVqQqNSX65rgNOHT4w fFAYIlLpu/W5OrS2L1grTvHWY04yBAmtiQEkYytYFmQaQBHZygdQCTJTHI1T2HHFNfvuovzs1AXZ VJ06WnWq+8qVC81dVUJbH6o4hd35kIgkQQbHskWWX4qy9AnNsR02mY5YaotwXQkSli2SFGdYJIWR LZLDD+GmzsIiE4YBdMQ7apEUiPg786jstiCpgxBZwmiRmVqPRTrh7FodE/MvwnXSjFMcMVVtDVO+ ryWMbXWMzVpvz0KPgoQa4FrMWpCBJUF6a53eY7neu5jPtyqkZi68VWDJMndX1mkZnAaejtWWGa1d oGokLYHIl2stJZbc0UB4q6JNhFO79NUJFUUHz5S73tqwHNBUfYT8gmKrX3xkGGK0bMmvtE2GmEZN +SEPjhvQq3sVdgUzttE8g+IMQ2yis2SIgWW5sbMwuXoAxRAzRbOJ/qkxOglDDMTl16QOKCkOhIYI 2aevbi/h/R/z1OiYGEQYIkm7IIkkQVpX9dQYQ82CZGsKEil7XLVYxai7gpm6hCC9tSjM9BI+DcAN sOZfWcJ7Z/Lh7jsTljxqojg2NaafdbnmCL/aBdlUnTq6StS6HjX9Y0do4lBCkOyuOwAKMjOYHlXb 7nZ5arSh7qobFrAxcXm1ry97Txh6CUGS4ixBlp/D7bggV2kAjoF/HAAFGVgWJCmOWGQRCL6SFukN 3SIxkOiAIiNGi8zUegTphKUrd6OOVYK07lS45tJzZ5VwdeB5avRfZossmNCLqRG58S32KcQgQmTE KkGWj68scnC3N3hVCTLxzy0yOmM2YBeYzCAd8coAhhf43rH6uzbXnGfsgIIkRkGGyNXfdVxrYjIF Gd9I4ZK0DaCpv7DMuKSWBeltsyAdoyCbHfh0uMKbG1mQxLIgvbUJsnOpYop2qhiHzdwKV+kziLFT F10eXBYoKSYj6QqEFlkaJINgZ2xHLAsyd9ZSA1UVN0T/HfgYMiVFb0kEH1Tk56MTvtKY9JfyRk0y OscovxUej7HnYCr5GYbvzfLz1gPyw3TpMq3kV5rhY1uywuByrJMGEqZHLMuPFHvlx3E6hxwR3ppp krDLD8oSnMjy87bKXW8tOm+8rWWln+TyyxS7/VJ+VQ/hDH00lF9FLxwpUuJ1GdvOkUp25dsq2SWL G5JdNEuyCzYR0y6Lf7fVRRpER5oyiPBpzn9qottd9b2F806WrRypZBbDhkVoS9IS6m5zzuNsc07P JeZ/d3llStne5Hf7Y3VYTSUhWLY35MwPp30ORZsdsSwzUpQIxm2r70/J3proNNubk8r2xk6hgLYZ UQ+koJlir9ycuMttFUOgvZXOoCKUHAeQZUdqLjvSy7Irv1Of7PIkRZceEZdfppbl5yNEH2FbbJ0w 6Bb25av5bhdYlh8pLpDfKmSQ5eekKvlFp0l+gWEgHalmu2OxS+qwy7VAgnCSn2E6SyS06Hf2l87H LD/Hsu0VPqpMzU9XnC0+wFtqD+Ev/ZeV/GKElB/S7NudZRCjLbFKfuWbpZ9YCg4HnhwA/aJjWW7R WQo8A6sCT2/tchtY05efpcDTG9L+2AElRSzbH6klY2+rQSXIUA06VpK2ls2OCA3Rh1kLUn65PVYX KWhrwehImx2S5eiwDjyJZUGSYhJkLlSrCg2js2yATiILkp3R1AqmNkHUW08Ikj9zfhckGQQ7pSCJ ZUGSWkeQJo7C5JgNvUG2SJL2IRFxQWZq2aP6L7NFOkZBrnZIvZ/PyCkCKxYJ4QaWBemtK4vMgqzq K1xDqsjTSVSCjM4osmoA4UlLa1A0ng5YpHciZmJ+zBHhbUGsU4g2CTIGkgXpbb3TvG/h35jSpZVl hHD5Pa0BgO0uSIii2JR0VQtDLgeuBImhlguDY7pEmn27rg0yIIrRhGv0BuyxJcbSVbZH+RyQUO75 ij76ohQDQvcUYtBrCbEqO1QVLF+dRFa+uSBBnzI0SB0AwTJccLBji6b/3pFHMt6AtogJO9jb7j0J MH2bCxAKZi0pv0zMxbfFttNhVz3BtkoYBZjoJfkNT4zRO+fF+JSAUk8uqSZhWX5BryW+qlgtfbNy K3+xsS9RD0ElLFtg3SO+VALuWghi6i68+LqAEt3SzhFVlA4tWh9FQOkRS250i2T8+YgUKt0ofmeY 2biHO961amMENkNulFJI9hckkhtNnbkEWwMoFpgpjokwOhHeqtMMxN0oSMUXJiEGloQYbfts0P9R Y6giRsdkXnLRpu5iSKmzwMySdJoIK9S2B7yRVwkSrQXLgkSGfHOun2DD04iKmbZQkKW1fNKkIE0Y NgA3O+OfDcCxlXdWBqXr+YQlU0yfNLZZkX4WHOJ3F9Hyq12QTdWpo/kzus606ioEaZ2JZYQg2Z0P iUi400QtW6QLIwuSrUX5tbJmi9z6YVM/wZaw5FD9Q1Vh+hb4xNJSn4LKlumDy5aZBuKzYD2QQP0z spFwqejjFBXuiM0RdkaRFUzVl2juzFsT65eVy5QUvSX7pfxILcvPf5nll+hRftAb1HGKHYTJIVle sCw/UkyGODgjBu+z3JxEJTfvjEvFbTWAkJu3drn1B6besbo586jeUGyjIN4pA9OqU8qvtFWtjXxe kCnKL6rSElrlUfk91rKpOutSqwSJoWKLv/KoQk8wetQG7yDihtFajgFVYgx6SYx5YqwWijpQ656+ k90Ti744Lxpk7pxCTN0PbzSlboM71lAdnAkxuqS0AsqTog/X9SaFNiaIwl6KkOwNLCj7eAJwS8y0 sgDLD7MhRlv6Ufxpf2VpVF8gbollAQa9AflVC4uiFlDfHlERYk8yIpsNiaH3QK33MIcBG4wxdrjl QFBPnjcwrNY6Mu2R3sqVnvaX7SBkR7qd3rkuJC0KrzER4Dm8LD0lZ0/kgS02DSLLrn/IbpQYxZcp zpKfd5YFWDCYQpIgBxCyqgZAVDRNP6kVmFZLw/zlxWn6UOhG2QHFVbDWNOhte6XIf6QbdUw6M9cK 1vEbfUiBuBWu0sApSKDllxRkRS8EiZQ7DmhXlwlviVGQmeKSSu80kD7hOdakTsGKYpLVQALlp6VY sSsQMRJznN6AgiRhtiOWrbG0VQfQpkczJHcov1X+pDKS0ofNEa3RiaowJvHRUH4VvZAfEuf701Gv o414pmCYLrP8SHHEELeno97FSHm4ISK9nj7I5CYYO/O2GfuwcjRTbBmiePD9DvGw1FVGJ5Sfj9zl 16RO2Y4D+dBLLSmLC9LFkQWZO/MYh6S9JREaIqllQeov8S5eFqRj+CAKEga7rp9d2yKZLpipSy1e pTgiSBqRd+aCxLEA458+1ucGCKFxAGFqxPCZREXnbACIh1u3sskNZFu58yE6oSB9KC7IqtPSDoOL gaDTHmo9gnTCWZAFA/Pco1bdFeurOnOM35cssvwSnqBXaCFIpNw3qDCtVhjEskWS4jxBFr5QkPmD XJDNlp1RZMQqQQbFHovcnddask6BJEGGiNwg2IG3W6WBwKP2UOsTZIyoX2hukaU7Fa45eQ4AX+iC DGrZIv2XWZCJXggSqrc/VKnvbUBZjKSXxDi8UOTPXWSZU8S8r7ROdEj8elgj6fUIcX/eXG7lRmsX hqhv4Y43pDUGfTYLCE61h1aPCJ2sdNQSV7VIDMo2nqZibmuIMjcyX9L3p5RDKZR2UrfRYiewHEQi I6+xv/lhWwYQI5MzxfTFjB30W7RDZ64jibnWGVQ2tYsB5JjD205+tS5dY15Yb/SBj2qmccy+UEP2 zfnqcoP3m7ODcqw103hrDU1C4YiSu46Ru43TlH68bcLI3dXWW0s/XZoPZcmEgsT4pTMRWKIZbRMm jC27Sd5agzkKgb278BwJ4SV60c4x5Vmg3gekAJ9T1NjpZZNwTPooZpIolpaOgIfgV4fa+9V/rP62 Wq9OuCj7AfaJAEr/fF/+/C1uQztK+LBe2R+Vjv/+z6tHXLq8wt13ojIiIzlILX+VMflfoV6Atd5p 3yA69L9hPN5WCOFVA6wN8bwT2l8ekZh5gMvZXB7i7/f+9+0WZ0u3sqfBNgXT4RENStLBd7972axu XvAp8v8w97+t0BHOxu1OisRfNvsdbktZIUCR+3g3zc3D6l+/h/dYr9eb1fc3Eq/g/+2/3z+svvv+ e4lhvn+/+r9XF6ufjk/f4G8XH/W/L9/efNA/XD9/un3+BudjVheXn/7+afXN6n+uvv/fV//+PQQw RwT4sFoEjYlsuQhWPSKAPguh3RGOEWuBYDlU4gpMwMHNgKAZAZHpbEnhwG669BYJYnfcI6RH328i CZPIs4sH8+uF/fnl9p3KqJLVtz/t5woKt72J3YSBpD9+gNReISiottjGoK3A3o/HE25gPm2htXLO Gsayx8JL7vgJDAZTsOa0OZhkhbC3JSam6Cgp9smq+dsKT5pdoY+tWkH8RT30FZZfpy2U6HC6WpnZ fKt2c9W1mwZ2sw27+f7DLWzi2+3q4sf7px+u78tf3t1+vH/6x8Pto1iM/OvT+/KHP/zxp2P5493L 6ptG/vHz47vb55+v//FP5R9unm+vP909/lj+ev2IP0ya3WxpbvfbywOenscXHy6PErBDCLjx6SQn GByDJIlhWgZnYMpsGhDWuT30kghQl3vU/4O3ujyDcfBgfU3YnQ+rOwQZVfQ2MYSJKaL5FdVeFoTn A26QDxUXjh/t2fjA5HMNy2rPtlntib5S7QsbxUctVvsL6PD+O1Hkb1bf/z+vmgsgyNrFRBjhCgil xE2Ylye8BB1KCQ0k5uJnWvnkEGj30UtKCVU87OT/9lBIVUlv0CweQOqrZwCZ3oRKTnniZmnUMuyJ wbTt5dVGfEA44t3VHlcsIQgKTNjtGLUvmhZIZRkg6VXsVqersUt4XglG4i/Gfp0FTB9L9DLohiV8 oRv+3QcNVIrDfP/0XP7056fnv6ojVT/7++enz5hNJ11pFUT+KhFMmsZQgIoLLMQnn7eXcNOYTxFO KgYPEdj6CvcjWMFomQKbE7FqYgyKiyTCiXGDKP28PyyTyB8eETg+3vr8d/P0+HL3EpNaU02I+2+f Hu9j9hPHokBMf+/Kn8LvlL+D/M8Q8Ms3zReKlLEOniWRkBHs50JgZF0wbGERmagzx4PocuWFO/iV xDWK0emvTjBJOUAOhaM6EKNIM8VXinR9whFiXGsyEevURnb96IJ4fHp3+3JZpPD9hwhkOmHPw+cX 14AfPFD6+Pz08fb5/h+l+QeQvb91yp+eSkx0/dPTXYAfbr/AajtzzatF3LSWfuH0XJrQGtjqWewy SZhYSJP+NyCdtIpTJr1F8qUTfZV8Z8Sy6kaHYlkNdOfEshLzun/4ym13jelRbi+B7e6uUAAlIbJj sF3HEDqXEDlMl1C2XG9rC9eepX3MiNX0SGe8xvSIs9zLLPfd3U93L3dPso6oFiOfZPWiMnVxlF/c PYoh6o9fbj9eP19/cusVH1z+hf5AXDbA/9l8UWqAXhiMPWgZPeY0rFHWWmeoc59UcARW5kPBjqj3 BV/kCLa3zRhWKT0UK+PqWaWUJuywTMp5ELIkkUl50SAyxRQUIp0xlMrqRCGJWb3+DOPiDMYF+ejy fIvL7Ta6PKeabs9Yk+DCfkiimIJ8sGHgsKt9NCUkPO/SA8+b2WpfhCY2Z2rfWZzLbgP+Pye1GBV6 fFD09ecPd/fjE4kmp+oc4mLGy/Rdcog5azjK+JhInMeYSGQXD69W49ON7yJQx8hkb0lE1j5lGiG1 StMb4disWHyI64XfyvXGUonkeivUq3MfY6Fec1F5FFtiFtm1RMkfWijSCg/wheOZ4UVSbcYywzMi QIgQIfgRO8MPKB3DLHLAvWaBwZwcO2KDAlWpepzW81oJ4zwSrUsCdLZBxTxyxMJue8QTzFUE2PRm iSna28eXz88pMfXu3fPty0sCIkKEEjze3nzCvPMJgZ5OMVyVXd97nmxsNpGZqiPd5lVJ5zFn+Vrp 0spCuAcsfqUmJcQjvsCxJEhvmqBstUZvqWgj+HudaC2K1xl/KopXaU5G8UqqFcUXY2Y4UuLJlvnC Pb3CfAvDemfD5JSzwQ455Ub8ZUgJk5xcnIUYcL/HroKctxV3qxgmi8AQBmioIlt05oGPBdIlSIDe dmEMSAGfT0hlb3yDZ2aKRGM9FUpvrKeSWBLrDW8DLZxF93vkmOTRmyMeqdniZith9GmPiwXWuyYw MLpgqyMK4TWBLcz3tsSwXx8oKf4Z2bNwk+3kX18DdudEOITmVUNIkZ58om9aQjneaiNmdsCx328u 13LeOBRZeA7vhaLKwGRggVG52ZaY8LxLMUUdGnOMRh0mA0j/WNS7nppaGzF11HHh4cE/Lc9IcyOg zki/0o+oqUdb4cAeZem6QZx4LW/4bo54OS8wzBSB0WuwbcXrHoqJ1xoRj/NaTWlzFbwuy0nd8zq2 WL1qB3grBNEyN+t/X/S/n/W/z/hvc3Gnf7Z//VH/vLrW/8FuJZrZf+WnqwsjZCTsv3XjrzGvV9w4 XADicrmGD5ZzRDXLHpXWgcFyAjthjWQr05gBCMW8n+ktkmWaFrBG2uCNhiqkmxImI+k6ZNOZQkM2 nRm+IGRjncBvvb5lbgYC0AvbJCVrAXmDVxH8EjfHVsdj2SoV6ywbzQlLAXm0xqSeZxq1xZG1FgPy Iyb1Ewo9tGijzOlT8TgzdiUDIzHzf0d2FdvHSLiXcKtnE6T8y18uUPbx8eUv33hgdvvT7T2A8tcf P9+9u72/e7x1APpgoVrz+gKQTiwOrfAFs6beweuyfp4TqlkBiMVblKEkYkssHpLJsTjlGjZJKNmk 68SrQ7WQaoNSnJmR2qRU1SJDqmqpurW1XKpKKaT6qq1chNZl4nzrADyZHI7fybV8D6sNtlgtAj8W DNVUgR3garGpma3VoDIrhwkHvUWuNhkrShlQcbTM1TIClw0QNdEiMcmov+Fct8H+wUaSpkccz5Iw GozbSiJVHn4JDImHwPBlutUozPS2BVPWESXFinXd7GlPk4YdOpmZg1Al61CEwg3E1Pj9spj6DZzQ BgW0so5pUATo6rrFlqxm8QKTD3Ys1NWbro4BfYAkuvQqnk/NLcqvzWYHkb9GXa+Lcr5gbz325yRh o6UfrX2DL1rBY1/NV/zygRE9cx6YuwXL7VshtMW0oGe8gvuwA6zmICTEai4lSCSwYL83bbJEHGTb hfOC6T9ixpZEZsbdFkZbZG1h9ArlDJjyLfBGVSD+/JP+1+Jo+1GOslf2I2tm/2ChuNH+VBo3IGS/ tN7sX+9fI+VffH3FGTzMDjt2l8i3igOMWYKYCzk2YbOMe6gtMjqG468yul9tjtgdd3bnUcwHWMds 4Cd2KGUODG40MM4RbJvnCKLu3FvW0c669DXw7uBEy9Q1cwg6Q/RRfP8VpYyhEvqoSajlA95uQQYL N91kVSXmqqolydY0IISpbXolAos819QMYfzCrqn7o2XLj7ToSAmY3lqcUp0qad2lUzOClzwRIB7h X2dubO5RD6HPHJLxsUDgdJ0XCMFlNg0Iya4eevAS8zc2Tc05Mxe+xzwwuq1Z0ikD84A7bp8HxJW/ eh6QCYXzADbodH7APAB8ZckdS/3k+SZPUzf6U0w0La0oxwAiCfolWvHaHZy0vsCWyxbpsIdmA7eD FwVFMgVDSBzYHvtzkufJCwxiOR1QWi81SPjT9Umq0Y8Y3HaLh6cX5QNkwX79eOO1GlHw8eHp5xLM RVmHbfJ4FFfqN4Zz+rpqn7DcdLRjg9U0LkzAZ8jCAtuMkmgpJeaBIfAihtT/Vs/llqYIvAJCLNyl V83KPcuPVgtIIvVWRjU6Agx+ZASg9zWtPcDnzfpwgDNzVcbnlgrzwORzHaPabkrb1ZEYON5DsWL5 1NxiIkOBtavyssVyqkC6/XuqHEXlGJYgpT5U0xdTUw93WsaczC+1BmE8GYJhJOrCwo5hRKwUQmna VHLpobdILIxPi4dZJpZZLqXl61+zmQuHIROqBihn1N+F00CUiqoUPdoVGPwSsbDZ1NYwzWQkNFxT xcDeKHVgCHBS4UlmDQEaKGEbQu8Wxa8zSnWVxStliFLlBEvyJcSSykZESqyKU43i0mnROCYLk1dN i9zjsMRbNxzJKrpw+3oqWzF7T3aH84nrjWyAuluArm/B99NmExh0mBh5zLbEwPceiknXZ+zJmlkh Gqr5HnHqaCHY6g8a/P1R/2vhKE4MSeTYCQcz/+XP8pkzDyfu5QATkr5hisI1LP9RcO+QMs2h8A9s GBAi+y61xDEeG0KArseGen7f7l1mnRhQdMWGyTkRDN/0iiDjl5rK9hsoKE4thDLCSe9xlcd6j1PH obT42sCojN62nswcZetWymAqyCgMg30sn80u7rCCGj2/tkAL38wL7Lc7O/QWDAWT92dklhFFOyYD CywxOdoSE5XuUkw6PcMLqPaifNGZ3F6tjnsBW6darvHnmfbvkRqTh4OHk6VuBMvpaq0hl+dsrpBr cA+wum8SRiNk28CklKVLsWJYO0Toa5C6ixAhYWH0qe3EECY8wQxWTSlp7LdCv+S3zK7I0racixJO sNiHU5WdcsE9Tq6kkKFj2erZtlLSKB8ixcRz9QNS0jJ4jlv5uJaUbz1VDe651ue4GSK0Vhu+urgc nbOWxgx+LUgsMbGziWrtPd5iyQtfx7A0Qzb0YJdkRVtiEE+gvmiFJ82FCN0Vcl8TduhkkP6IgbFD tiXWP4gBrf0tXCsUw24fkHy/nsfDETiUwaEa2xAMioicM5et0yrXE1jO9Ti1pK/TTlU5qJke1I9C tOP3DtTlbriv49pLMn6+jWLqwGTt/Kbq6rbPxGu1ITc7xN1gGYFT2jKTuARQpmGlU4qIBAKhBNiO GFIUHWqLJGB6vYfwawnMDG5/4WkNB0bt4vTsIuSQE2rMwD6fK5pNYLREtiUGdvVQrBjWdRF9Tdhh DGJFrHSocvQPmBrEgItYEAPE5DSgoDGVYVyjE9sGxzfFCVNBZc/3vDnKvKIqixxaQTCphTtgO2LC 8Ta1xO+Y0lZ/a+Dce64mMe6fEdzWCjo4pelxXaxM7EqfMnOVxO/d48snFPFZYdj4ZKaLsbIA+zWj CvpnBAP6LBlmRZzBw3aY8KBg8BAFa45b5OMta8y2xLKP9tb964vBqIJeeod8/Bov3VX5+G5xZR1V sJLr4frOT1++f7r57N47jtLavm+VOMMc8opTEJY4A49wDlmXDHL3yOmAjItkdK10yiDYV4LgUOSq DeFutAwMqkzU6VW63OM7Wi0wsNSdEkkjaHDyfdkIQG/AccDI5yYPphzH/JkNs9YaExn1FJ+LLQgr wyraJ14xMOqpzHjWlpg4D0d7dXc6wigiw2wxR3c7EYZWhhbn8effj4YT2WGUS0zwqYMrtimmh7eG fhxGr16D1eutReEcsMmzxXVSWufmbIPHLlh2GJtoWzE9UG+90GEUFYe/qpneG1R4ZX247JVto1op /MqKcWz7dWV7rvYX++9fbS2dC3fQRLZ7cXUb/msr7ulcG7g8YC4QYl2ZBWdrV4ofiwsBv3Fm8XCU +TG8SoLcpnE3a7R0DLQTag6hxe2uV/EW8BfeInXnXiVB0Zu3xEAD4wgSvQGvMswm/Eti01ve0iM3 g553lVNhrZprKPQ76teoy9G0QCrLAL1ti99T6TbjocjaZsNle0d3Dw+37+54lQDPGcK7vNnVAeIx 3uQCF26/RTSyOyMdn+WBjTuHyPrYoiOEXLyXqL+S9dy3exXvxyIR3UUdi0SgFrMjkY7P0PuP9ahT WOz+dJIXgLHyCp+RILfOJrV0THbP5D7lml4dibQv9iq/TxaeOnOPkaDoK/UUGPtP9L4ij7FD0g6J z8plyPXFJ9y2yNhEPL5jVFK2zT6D6Gs1VwUge1iv0txUZDbnZMvSQAXOuw5UUhXLskAlhy2y9JB8 adnolLOkeykwSoEKD6g4XyVf6odWKBVvm4MX5Kh7KFZmMOXKi8Jjt7GWymiggkR/uS52LFBh8XB/ oFKtciZ9y2gkGVlPn9Mt6l5bQBJWq7UowMBDLLVlCwu8jrbEcgqTFCu+ekiCay3LZZYkxCbeIbjb GcSqZxB5YP2DmOtjsC6Imy1TVPL6snp16GEJwguutbEQ1+enheteN+eYrHUcQ/An2WuQYtuCafBE 1FsvDEy4Tsde1QGFsgsjk5eXz7cv/1tZ7Tw8PXsF3fW7n6SeDheR6SSJFMqPcRju6f0X+JrONBkc nkphiermvZn2pWSyApFSMKheSAeuBxdSB4CI0QDKwFtBEU1WKhdH2XShXIodYA1ay2Wml8l1q3Zk gcug5uIfusx5SIsdy8nauqmvSnZAYK8qTt7ioNQJp3xp4lgMHXG0Z3NGaBBWX6Bs9GyZPQ9Rbwxe j+/g9DWJ/pwKhO2jYndsSQyLoZ5PGvA70N+BRaMqjgeM5i7Gb1ScnWPZYrfGDs0nzUYFqdVSFQwD kzpPw6jLbEtMPrhLMXn76RyLcUxCq6Lfo/nBTo7l0/M1rsWUs7rF9eCklf9pQFeN7Uv3G99qAyeW NpTADpHIDlXR4SMgAWLkdjQlFKuiaFuyl+UAwzT/uSp6Hf/j9m6uRZ3/epXRSKiyUAS7E64clmcC wjegrgPv/e5wcVz2F45lh8G22VqJuqm3HUZ7JTQyBA4Lhh3DYnfsjBjE10PxK3IYuyMWQ2e5rofq usftO5aUpcMgRt1kW2L44B6KixyGcQx1/a9zGHFwOG6av9PQpSht7DGkRRMLGN7whDFjXlGH7UlO GMt+6k7LWh1DCBiYZLIOiEpy4F0wjYX6KCbOovKuc4t8T5OGHS4chE5bHYpfV5W/h8kI0nCsUeoW wPUoYXAMXA8ME/r5ZE9yRfEDMW6QZYoV16eWkcoxLWNA4eT5gI2miQ2y+krh+6efb/2u7o/Pd0/P uC6Om5M4ufdW173hBROs96aeeelbwpcpyXm/OoJ/W3gQ2VG7kpPc4l8KBiUihoSfLzWD98TI+2hd kgWzT++R9ziOdtisT3XwMf/ykB+fru8HdiTlQpGyE6QrILlvm/f9/SgXqvuE+Xz7z6MxS94l+jW3 lSPwcCFJQaXf4+YYZr2CNcgtuuCiKaEUs3jboTXRwLY+Y5ZesXX3lOttfWZy54lNrwfJYmsuXi02 phY8y6C+e0m0n01sdB1Lg8PtmXjsSC+xwPSrTyweHZPVTcFwJRwqZpBVRq2nGxwxZI4DjdZDkuO7 BP23MB9weyZqQpb5uo1fmP6np/u7mzu/F/3u8eNn/Fmt6/3z00Mxp7p6w+b9p2e3UpYrfn65DbQc 7sMVXO/w8szdeyyQRwLYbI9dwdoy7pdIhtKoQq4HmNJGrr4PySBMcCzJ0Js6pNrnYLRdKNWwx/8l 1dfMj2XWCuM6SIAtr+xhfkTJ1F6uPgsM82NguNHuIMddmBTEg4+BJXON1gsFG/PjATcK7q/WC29G G421m4uf7z59KLbaU7wzmdbGZw/60A0q69Z4CRp8K/kJ8BKs2aCQhxh4GRhuv5RrZmAPbFswNWSi pFjFeZ3ouulrwg6dTM8g0CHbcmCoaOn5rIHVImgMpJd+uQkHN8Vcrq+wdZz0bYObztUxBSYf7Fho a8O2gWHCIUqbqLg+FV0bx3D88RUaPPFK06tynr1JakiEwTWPDFSTu86+6QDBBveKnq52mdU+jzeJ 1Y7h+8MxRFNC4HSXHhg9/z4GU2wcY3JGt4+4jF/IYAfdcvbZim/sah3DDbECnX/KpTv2z+U+n5zx tjx2pmS5btt7e9RSH/zrF07xEgaEDx/P1A7Gbkm81dXJIUqE3H6CNDCYeGCUpc/mLvFqio+2C2cC TvH/yWYCPVR8wiH6NBPI7TDtmYAYHS7b5pmAqLvwFi+x9qkeRvMGsMuYjNidYxBmDIvdeVuYlU1Q Ohk5mikungeUUiw83rLoKk7NJm2Tg4pHOVAWmHywY0l7/cRtrb6BvnIeMI5t6Z4WrDxkHsCx28GD jgvz2L1TAIThU8Ds3Ry5Agd3TYlqR8CIfIkV2zsmc0tgZDPbEkNNRA/FNN1O7yaYCh8xLRU30Z4F xg86LpkFpEAzZgEpmHj1LJBKPfEQGihZ0YVtlNrlPH6rm/zU/tV6Q53pyOTxWykGVxK4YRmrQMly +pkLSMYwKAYx3NKq15ZxJbFCJtKxvJIgxUWKkVYSyHJukO4ey3J2tvlenu4/5wt5nzzlKWmZa+TQ Ht/5wj7u5/n04ekFe4GaFrAcv6QPRsQ1tZxvnQqPIzvhmmX7GuGbHJwPzNIrhiHE0oMw9zxzdAhM ol0/iRSt2zNLJ4PvTbDwK/PD7EGk7voGkSl+RXML3g+zF0Jcj0W3sT2vZzsDE647Rj1m24JpaES0 V7d1hTF6F7zK4LSGH0adnuj2grkFBxGRjhQ91SxjtRf1850cTFT9/eErj1LJOZkBcNmIzADF91hg YxhlEVFqFkWA3ral/1OrvRSlvkYSE15FJVG8SpLW5XKnMlJi5jV14RhMvfdy4Wpgpt6CNQeUamxw 35oEEGwbGFw30eJ+Wkz1xEVPPV50OD4IDCw69O7ywPoHMdepjDBroihjYLWlVh9RmExjacJE+CQv +OKDvQbmgEJfxcD1wOBdkL7eSHQVmfKCaVxN1Fu3uD6lypwwUR2y2e+uljmVdzgiJ4+nx7XD3Nh+ xG3lD3qKUbbAValD8f/1d38snuh//Jffvfhr6vHPiYi9Tfvtvz1fv//0Ukzgje60LwrbHKT6UQ7r QhiSMdLVg2MQRmDg1ekKqYdsAsSofZliil5Gd8bHBiEh1OJBrBLFZAJIIFi+Ts4JwGXOvLsn1NhX D1ozDUaI/mgyemY+iQqLC3/3V6jKE65jDpU3hA6OyQcbhh4QH8qx3mwCxHLM6K1hArkcb74J4E4s PKrYOjo6vTsrr+rG5l3548uHp8/3/iwuNswfrp/v5CXdMs2WX+Elj3efb2g9P/hbu9n9o9QsLgzg dtKff49elRpeS7zBQbIviDgRE67zBlK4ctducVOwDAhFJV6sIGHwy4hGaRjYxXeIdsG2LSflUwMs pF2qLQom3UFvU3dhiAnz/kQj9da50SGAXrIKKOHrrQKkaAbVdQsDEwP4JGqbsqxuFbAATAJSoyef K5ElSkcCk4nBMVzJ4tNxTAzEaBWZYuWL5lsFBrfB+7nLJgbWR+LhwY/ypvgP9x59qhIXQ4hXp9/H PmusrK4fr+//8f96K+zdRPyKN+1A7qHMHM3FD7IxqyaoJRBfYAw6aUe2SubsWp1wOkbKSfBEg7wo ZCoGDJsNgeEWhf1eb0Zj24KZ5HsoVqLpmAPWSJVOzx9EMkloXAysskkxHKW42CC6zHKlXmoQ7dp4 NwhwGDknuSA+FfEEJlwvhT0HXOegk3iuKQhM7Q1slSdzo3XLCc03CNSf7A/rhQVUD9fu21HC4082 3zzZ3mXkD7y8WK8eYPnOy+cb38KUTMT4UmBpOih0C2f8TpLCLjPy7oCw37EyIwNDng8as8YVk3T3 Gcu65a1bM3JHwZOVsYmGANZhGRgHgYG9YhADCg41/qI4SBghFoo4aHZSlQqOQ2X6Dj24jhy9vnhx KJgEfoHhoFmZY8PhB0R/DysPesmpTKdU1cVIfeABx8w2a8xjizJnW6+Z+ePnH+7vXlxb/1CvAtRF R5ivqwCdB2QVUBz4pw/X7su9OKb8y8enT1IsEwW1L7c3eOP2E2tn3qIKsRgD9cvjDnjIpHMWdwiG 6tX9Fm4lGwMxGkOmmAQzvihwJe8ZhOiGxmRLBsFPqMKfr2dRgFJvjTLlgy3UAd8KJh/s4Q9KvWWO Fa7TGgLL5uCtWy5ovrfHeYX9Dlm3yhymFgXPdy9/dY2O1axVn3wruX0+K6X6H2e6h57wUcPxAnFf L3Mx4Mvwt3ybijGHqzOEgtn46rxHCtIxCCUwVImfkMqpTKFgGin0UZxtCt4hXuaODh2bOQgMjPYY n/C1rgTkhPFBXlLbHqD1OzxrrIeOAcnnOoTauxMm7coQiNEQGm/86qgHZeOQLsxgwQN5oefhtD8+ X+Ox8ZtyNrO5iGAfzxc+3D3yzomYJR5w7OpH4nllrFb2CyWFpDIf7yKII8JzCPLW+6FA4occwrts eqVp9v7EqG241NTpzdb4aMHuDFLXv3QEMfyv1PNLEam8hCcMt6cPwLOCCcfLcwgHFHj7fBuenxgV 3spSjeIr00Go+oZwW1uIU54/Pc8uoXqJXWyPRb34D76gfff02In7fUHAg4ad6kWZP/5UQp9CXTJE JRmEOeELVr/qIXX1C68oikqX7VotBY643FCu3sMayLU/sD32FnGdgjokj6USRotg65ZHGlsclA4x uOhw5iBwVi4G1jOIr3USkBtdpS5XVr84K7vGQ+A4nm+YrH4LJufifOp1q0gYraKJ1i2uz4+H5Kb5 3dJ5AKGPb6U/397f4qy+B/klu2lhkP8mn4JY2SkIT/7PePp0zpkVX/QiiLSddPgdlKjoybfA7hti 2PeWNyNloo22xJJKReuKw9j16myqk9DoINLASoeYANh2ahADi158iC565zBrblZHxoXfcitAFK8n zQljPGB2vfItl+0OIWVg8PbY7RAMpa/w9nJluBAu+ZuEUa/ZuuK6avXobdTKR1n27lFJBAG3kv/d Mz71vZE7X/b+i0f7/hjnx+tnxDmf769dp/Vez/Tkk7wkK778LxebeNaZEf1fLrZ/+cYDfaQ7f8Ji uHj797e37364vvGpJc6SwMZ+Ede/Fw2T46I2NWuyMDCbmg2T0l7k6pKJNHti2URIcW405B3CUcey 1zF0SIwd0kSI9QziK3X9OCUA1bcd4rLqdUg+1yGUNfh0GwZCjAYCU3J6Fctn+30cn4R0sfu5aAGQ jjf/+fdFf59vf7x+fqfJTTWAj0+wFD6CHmthLpcTlZePtzd37+9uqnfTLWekxG6ucc4K9XpftBuG bJldo1aFQKHLooKSdhanRdVKGKYUHBynk4YZOJQV0Nu2XNbYRFGaqBUsGgJGOjKEr9YGcPeZPONX JmekHuCnCybTBCZsxVASoaVveZogVllBUHylGaBMAsJdmPyPxSy3xe7v/norG8JYE6RVsKlvMZTu 6jnoeO6z/BL7yDe3z4+yH6ZWwHlEIqkvsAbN2wxYg+lT8cd4Fi2pmLpjhVBHoc8iYVsmwqbAcjrG 9XO2MYRRzR1Bipn6RpDoTYRMQ2cw3Wm8ZY07wx549XV5IT57f8XyjIB7iz1QjRmhYCrNPoqvtAU8 hYdrMrbLdoZ7F7Th4ZuLmCciNYQd5Kf7nzz8yQkg13uPwtLim1GSWkS1AP9lDEKU6ohNYVmcYnNK jgDuHZPDaI7BEI5XBzkCSJMoGOaMPEF46ymbaNnWgkGkSWq158D6B7HYLLrew1cDvl+miwMwQjgx VkY0uD+MPV97cUm4Xo77BSZcdwxJYwtOeeZ8H1jeH47WLa7Pj5RQRnTE6w/LzOKj7Zv1FdJVNXDF w8dMIFtn4/vB4/XmXRmFn5ZToChr0ORDKXjYOybJB8dQV7DDLZWVQhespdDeusXaTsSTFJpN2KFj PYOoFJoDywrtratEKD5yRgVQl1lvr9BQyrU8ICQpn1LcIIqqmHywYyhu8Jk1/HxglUJ76xbX5ys0 Ch52h/VmmULv3SmP7gircw5lrutCS3Aj0f0Mj13Oycadmn5oW1WwCmHmykwUGr8dTGdI+m2jUQ45 vN1LBSkO1SeZOdbsKR+2JSYnM7oU++bmwWcwio1s9JIUkVnZthy9xrF9q30+2vqoB2DzuSRcpoms hV3p2Lm6sZnxZCQEMqPcQo+nohIOd7EhTxR+B8Gen30JDNFPYPQ7bJvdAFG6gYrDHV+06mnSsEMn M3MQqo0dil/X+muLGpwz3pBtQoeF65JxgFsKTD7YMeqwt4UCun+CL3I0U6y4PuWLCse2odcLfNFF qSN8u6OVdv4DJTKhgjJ7wAvjP/jEMm2KmhuGUdsUCemzLTG5quhoxf/RGs46FzG3D/v2NWB33SHA 97xiCAMRHxzjDAu2DaQJZzu7YMrP7IT+CcvLTohjOi7HqH/RlBAvh/K2mG+TRk7XS5kADrvQyLpA pJU47pw0jHqpMsn1XjWk+4V9Vw3ZrKlFJNNXDY3OnUuLBd9KnJLG0Ts8Ev/l1c09bCh8jEzAgVF4 bEsMh4p7KC6SaDEf5DFKvDM2d3YEWl6EmTl3pvQk5nKPTmZEoNPRjD6qMWNJpSFi7+aMPFgre44N Inz5g75gi/+9XzmAoipZwgJhNoEY823eFPNbEoU6+9Gjjrow1l2ZPdZSJ+SW5ldfXeRDvIOH6fOi aMYWGC5aPcpdgvig4kYl64QaDBTmEMN+YWCYQ4/yuhGYFm2JfUgoKSYe9e0XkhCbsEPHJBfkAysd wo7YdmoQAz4fH6LqOYNZsefHZX3/sQix77EAG/59rY/ZuwZaqg+P24iRmpbK55Z6EaRlXS3ZktiH FVFX8QG1HLgQsDARDqpXLVs+v/NoFA7EFW9vlxizvjvSXyu9rSoqBm+eHh7iyum4aE69/+3jT3fP T49y+O7lS/Y7IIP69QFGFq5RMtPiHZjT8ZhUPWHUMrbNWkaUFJOqowS2dZOJN2DQMnMIUFJvi8fN wwIZX2WKE4r+a2Z5GaEU14v9bGxUSDE+9ZwQdToaFkilGeCElg9cnmgc1MjGnO+CWBvnzLu7Fnjl 9lbL/kSVVXlb589b97N9i/UlLGJfjOUP0hzK39by2KX7TadNiRr28kSSC+rBamxQKukIvJzU7AhC ybEdMQliampLJ04z1JOs/6uJ09b/U7VrneX8anA5/7pbyeQdYBycwuhiFpXjBlc4zU/LBLsKlm34 EG2zXRMlxdF1U18DdudEOIQmuRG2nRrCgGuBdf7q6ybkgC43G1yU4NqI04oYPhQtfItMwwFRG9mS GEK7Lr3ky6fXTcZEFFK1NLT/rdw6zL54dwtXgDJhFLrMiuySD2fcUk93Gmqe8dBQCFqSHVsEEpLE o6AThvW9HPUB1yJVjoMaun9R799461b020kxpXQ3m6QOYyJLWHTYGYTOAQktrb/SdDeOK2FXU4+B +/3Ae8csp6b3CKPm9xI1pzgGnvZvAqvS3d66xfWpFJNyTNcc8D4Q5sLrVdIRvTit/Yc/2TUHzcV/ u/0kO/Fx1cG/y5yGY+FxorX9g//z8QFpqx9jO8j//U1PeEws5nPqezROLwEHXHgIE9V7l1vcGxkQ IjOHKLaIVAhFZiZTSx5mevHI+GW5IKcWj6+a9naYi7WALtwJwlkwA2vrPL0UCE4nbDu1DAwM6qE3 Oun1NWBv4V04pugstQysfwBf0ZSHaAwhBU6HhfIJv3GRPLL2gclcHBjVj22J4YN7KCadnJ71jI84 p7MvOlknNForx3rWk5jaF47iRMbvIdOcYbmHDJm/t3uttcx10Fitx8KZC5yKk5BWqnPlijf7K85k 4X5wORHPKYhY3ofd+W2m8Y5CZ2JMNGb1Ws3JQ70i0zugrJ7jKGEDqH35JqIwYuxp7CqBhonQmItN xANOWMh6QTHhsGEN6uGwG2vHr2Pjl1hOvnnr/plwcBORMyHOPiJyrHJvLVXtJDn+cvFfnx5uv/vT w7XcKqba+N/fo2DzluXMrE773e39fSqR9knu8k1nuQjSkErG46paoOOv3aDC1jDsrBPDM8ISHmcV 3hjWiq28dYvBY3ocTfgCztJBYGDZjgrFr2sP0dUa6or0pzz2gHoGOb4mN5oEBq4HtkaAJyVAYi9g oFzVsCdGtc4Ukw+ejguo1psdBLw0wPs+3T/i5215L+dbnD0v4dgXv4CzkaUyDkgFn6EaGywsLFnt 8gDvAyOf2ZYY6hJ6KC7ivRnXCbnywvtqb2UyLwE+IyeES47wX7sX1e5LtbtTbc8FzkZ2Vd7mcrAN XKc8mNqEbUrqGaU3mgR1G5bcc2DhNLwtvjUwsLCHYsXCrtPwJiAUnit1aBg8UsKiw9Q2MA4iU0xz IfTkTXJpsqskU7FY3FhVX3sLaoMbhPW4TzgIcF2LvPeQBBXXsewg2LZS3B6KVag8tSo0Pm6wCVYr bklXTGku3nyJwtVYFuKEwvvPPjn++Bkne/wqryh5fbT1YplALaWKnd7RrdyFW1pMlFO7sPuK52dD 3RAiCwAjCB1KrQKTJZuXL5BWrdwlw49So83q5aa3QX/nGE10lLoxTKfjhIaZJKXGxDNDqZWS78PK 0GdvYumElZbK7VJVrnFjIpQSUzA5/DNIBETtjVU1IeE07ojJTVuhx5Q+G7Mkuf+qSTDOu3lo5xdZ xB2PefdVEvnc9CrXudxFTsNWKb06/Vt7IjwXjGp73MMWXgdahN1vOaKePZFj2ROxbRYcUfdjkFyu 8JmSnJoHtkNDcl/5FKqPk0pZcLgTyTxvLg9XJ0R27icwSxALQ/e22fixOYI9MS00jtYt5W/vI3oD dtczBJmoFg8hU0y+5jdXW+zTnlCZkdVW78/BYjKrrWOV2kbbSm0Dfa3amtCwI/WqCZS3Jdz+dHuP iXD8eoPfqpyJSxbcWaEvQj2scGBndzhIiqRg0DRikjApeRIudwLjcidaLy1Q43IH91js1ldycnP1 r9+vZm202BJ96R4L8yb1HssJVo/vEPPGG5wlpkMylBiCWInzFMMlD7s1VongFto1e/79gyJs1Tb/ zgn7qmMYJzvxwQx3DNuIgbQ6BqVk9PMCDHxOzRQLMECKYXJ/lUw7wGhHzQgm1nh8YQtHG7rnJ+ip PfKhdqoeHxZ65m0z9mHlaKZYhXNTc5XwfY0D/iBrureshCA/lRjlLx+fXsololpC8PP1P/zI/Yen n0s4EvGzFdgUdKi6BgeM75BYtXKav9+9fEJBTm80MlfCrZcbUmAaqo8Xe1AXJrkNaiCx0LiGbQOD 3Il667YJDFbSsAG7cwx7MzEsdsfOiHEIZVGg9vyFxvCW5yUjPqYt7HZ4/kduOA37kO91jLYQTQtU Fhcl3ia9RZZgTJR4+1WWEJVgfffafh0FMLvd+nIrV5AFex+aHebDHRwAMbA8sMTyaEsMKhaoT5wt LZ9yP6rNZ6kxqKe+r6MKBsdySpmz29/DaicHB/yv4JUcdKfVsQUxsKmHjutmc/PSU1bX00B7muy4 noT7Op7rAqCzcUKrbz6Eq102H6qVxmJdvn+HI1hXR6nVpc3uEMYej7U+OhSq17BlYOJ0e+g5n1fC 50l1NL7DAS33AReeapbAtycee9WGdLArs1rWQUsTdjtcCqJRbGL1HgVCEo8weEB2o2D4Q4QebEsM zO6huGiZjLvHLq90ifkq2/cnGyXTjPAh1emvWnX6C5ca8lidXlwXZi4ZhVjQlgABrCpYZf/RtrL/ QN1+4SZzRqG9HB4bAoylM4Rs9Ww7NYQBTwD1+tVr33ZXEmyhCD+rZ8niBCYDC4yqyLbEoJ49FJMv mFEIoEKTjZBaPeesylAIcDd5n7LuuL7Lz6XojWnYn2rpb04X0ycPu+fYRi0KgJXLBvU+V3sNbmKp FNgOF+4d5XQs/Iq3TVjewSTFxMvRm5FjchwfRJM6nDkITEBfkQYzryC703iFEcPboEp1vxWtLhg0 OLAdVFk3ucF1zyskLOcVSDFxfVqDU14BJcY7lNTMzytAg1Nhd9nkiKK42CD5GWUBZe12zT2Pr2qL FVun6zPEETKAXMAZK9l3zkIujiUZyLartk2YbM11KSa5TEcZZnhS4YQbGpNcZga9v9jEJ+/I6yky nziQhsG5PVwUvckTjGNwseE3vGmCwKguPfCJL0j37KN2W0Rv4UiQH/FRpe68swT1juArchmbAzZR 5UZ6V024DL+BIDC4jMCSGkbbhMn3dikm1Zx2GcZFuSGqVs2Zk97jred36m1RvVHx/t6uguu/AwWT 1IzNv4HcXGstAp4tDpCTD8YxhzPuxYWfKGUXmJwKlkoxdkiDluwn2xJL/jtat6K+qdVI+G9ZE+GN jdZDD1M72r1lMMVZx6NXJWx+A4/tdQxgFmINWdVBm1HZp1fhBgZtDgx3S+Kr9EmeUnKBRUVg4mhL aUe0bmUXehxIEBoZhJjU4kHA28VnJR/yW6ttFFMkJduiIPaAl7Wy2joGDofasi0x4Xop7UgUq8XK lNpGIcbr1PbxyS8cjh2lR3ufMOozqkoMbFuPrv7mRs+QpLjK3hW3RMZijTNLZOxGFFR6bpDISGzc 4t2vwxYJuMDEuTtGIeDYrDUtEBQWN3M46L6oZQxTYjGVx9E2F0vJ9I9eOIMakO/frxAMruwl7j9q YddP+l+8gF6W3m9WurxFwKxHzJKx6U6Q7L8FBqaBMWfF6C+8be1DHM1eKc2IfUsXb8IOy3ZUHoT4 kMWDyBS/Ih8i4ZReghdqKR8sW1AoqwtMPtiw7EPYluoLXe2huMiHmAy2x1DWeukyOvXh7NnH+6d/ yHlrHETtycTlQOPXv4vKNy+CsZJTtpxnQJJXVqhJ7joaZk4HOOUVBg7Kx66He4Wa0VM15EtijNV/ 4P97Uhswpbn5JksZ4inS8AWIGjd4ixIKF5jQC4z+gW2JSRZTkpA1xeQfcLlDe5+upwG78xihZwgY FjubGkLyDgijOoExj0gOZ4HmHhnDuGTOG7w7LfK8oZ3C8/Kmd2DywYZVKus54qTGKXMcrfunssFj D8ZHFCfNVdp0FXyk6Sddw5BWgmFvsh+CA5KySEgXu0imUe9xTIyRY0i7EzboAwOrAwtXgAW6tw0M wyQ65R8Grhgoqk1Wf4VRAx790gVHnuPlcT3NaYanEDV3jObnbaFKaeXhaKaYvEJ3w84bhBOSFWl0 V7yCWtrSIWSKySv81uuOPQ4cIRoWTxzLZXm2VMtbAhOeGwb+xrqDbYlBVXsoLooZTAYoAO/3CqMx g5zcywWympu//Tugu1tc2I3buu203uPN/We5EP8XOfYUKojwS04rXOE+9cAQfgWGu+X1UVuwF4sS fUIZLkIxdU5EXalbDra7cO5pgiuSXjkIzdJ0KEJlkwL3TWtzNjfUX4IU12Ovq8XynA2mK+Tr5dny EuXLNfWBlShfMVQE+i5J5OuJMd+TKVZOY2qFphyTc+0y5R43x4VX1/OwHsqlisLae+b+mrlc7xLP +cRb6Fxw31x//PT52duSyiPeMfESLq0S10IsJvuikrx98Qu+2J5n6EQwIerhMoOoagobgNTx1h5i vcouHGvcBqB+bEtbQeDhhx8SxUpCHux1Dj+kBt5dNk1i7M47y8PqH8JcqxhmVUQRy6zCnEWOQGI5 QaOQkmvcuiFutRgK3E5gxQBAKZpmmwjQ27Yc0ZRJGBOxb/k6k0j3Gbn+xqX2jW5w0bMXi3n3OV5A fPnEt3vaO2CpUtH/qdQnSgdfnJDSkgXjFf2o6hZO+cJRHbAy9r/CR+lfZYcXN6FUk4JhrUnBG7Zk MTYpRBO86bmo69ZUEHRW7798n9sV15X+i+9T3OFiyuMe1WjydCnSchrfOCZsdgxlt5rhlvgGbJMq 0R0xTgVQW6NYkotxfn5K7zkVnLA+3ePWlWrrdiqW+eGz51Cfr+HG/U4CHF+7eb6LtOrPH+7ksXJ1 5tcf8XTV9Q1OzhY7kPsLyh85sZQWVrngT6Nj/njTlz1bjlMV/rDdX57lZauk9QkL1fe2+F1gdLrF FSvFXr+PdGd96C26k6mnNQRYVcKiu/Eh8AOqaOi3Dufpp90C7A1bHKJFOFMw+V4ch5ODtUnbo2k2 gAC9rfoabv1O6T/9fq/+Iy2FKVrK+ey/3z+svvv++21kq1Ppwjs8V/vT7XMcZYvShWtccaeK/IR/ vr/2GCku8Pj0fP34YluW5YdyRBTXI/iUEb+UueDbp8f7N33f3NUIOltUC3lC1ELr1UqBYdoNDG+Q 4J5vufzV20JMgVVWEBTnWkE0YHdlWDLzLx4CzfPrtAI8HYVnQeRlB7kO5upwghQKhM81CMzd+v5l qDsh4bcVpEfTV9sAXu+BZFtX647awIUHJfDMExlwS3P9mhnFNGfCs0i9vy14MY+LZymYLXgFQ7Uv 5tsS28R8SyzPt966FdsUfzOYUeR8e8B8i/tcqul2KguegsFuFoGzJ/clikNJl2s2ep2sO5rydF75 K2bmT083T/c+NU9seC4sd51aOyy+9z0kaMu1Ml+YVHXO9DmEEgxTIZTsp1em07UsnENmyLRzkdOX ytSOPmEt8J9apjRV/Elv6hJTtVuc9ZyIYBAqMez8lVmIbYllUyXFNAtNi5WmikvBsHvedYslKNDQ oCPXT7c3Hx6f7p9+vItQ9y8XfVcC/svHj/f+eqVN+c3F9xITyCuYRah/dMv0mOB/PH2edTYNLJu7 5/X29knGH1AGs5EFjxz5KaIkRrHRPkO6yT5Jb5EgaZ//S5BSWTLb0YLfZc0Jd6kHunLqsmBilEiv 66ubKEe2w/x5vUosGyUpLpJlMkrsmJ6O4xNoxyg7dvRv/+1PxcQiyv7T5x++/YPd0rm6iAbyILMt YHvylpH91DgfjxN+xOO1dz/c3d99Yqyet6W/mmUYxeCpNg2CVNgQYqTfKMQwUULJREkPYn3NMgwx b69YR5dhISV3j+NibWqxqtD4DCvT0dNifZurpczzvuleg2wJrnEjIBYWKLBFYS820ByTdZtjWGdf bTfVFWs4veUYDRZaERSTwWq4O+/dDjmBicfUr5ad++55+vnH56fPHy1EbS7CaiG/WHGHAd77FgOv nMlvhX70WbWYdhDLc3d/FTEYO7TVAIf45cUSkl0duyMyrJBiOcD29lph4pjQMKxJQo2mWc4Betv+ dc3qb5PlPUXMyxY242JOt50Oill986SYLQ/jacp+Mb9BibKHUl98bx9nYFRiXKGEH04CWySXCKWw NVUw6AoxFG9iCyXPv47QmKMlqL3SmLGHjkrf1kGfqWzxf336GVe2PLuTpqPVo+yYh+Ns5Rfn7De4 m+Ysm607TGFwOztl3BlVsbgw3DFlnGPgqtQhKuZtiaFcuYdixbzutkanCbzGBlY3NAhY6dJBgOLA rt5vEflvcIeTvroeqilnG3DFJ0oHqHRytsExV062dAQc76FWcVzXcLg67m8DNUXGf1RG92prK9lS x4p4c3pmQis2mMPrg/O/UN3WBlsDuEgRu5Ru+jmh5RgTWvjy4g68JVSsIKLRXWoVf0sya4S/ost4 nc0ZvKxm60Hruq/1v+Xx0I/6F9TZbzG165+tBNyOouWX1Mrjao/6I2tmF4Daw6Qr+x+hgQdI7S/5 slC7PhSPRkhluQ1Bel1dGGSI/eg7xXENDCjZb/J9o9a1/RJVCSTHU4o58Pe44TfPnbmyIEBExnmn da0Fg/4Sc3WJAMGBFPSTVkt9YKAj5sl1+XL7RB3V/NmkWw68kP140h6PzuJsZ8wcVpoqxexNYFaa agXudORsSwy866FYFaF5hQhyTLZT2NNAKmGtuzLJYfJyLM8l7GxqCF/RXIJjxHY5WPJ1+w2K1a9w jb9jMskF5prJlo6A3z3UKmWdmkuMh3u43lcp65+xy83H3X4vS5gU7nQVNB8m+jW3TKQMF2fKJUay gBMOy5+qCgjRJc4z4/UqziZsR54TI62K51Pzi+kycjzO8/+E80uEtOMyLlEE9PmXXztyUYFYdCvP VUpaDyUneHUHrC6YpPUMa3a4NecgV5/mZQWxvLDw1v0LixnbYlt4WrmRf2JfLBXaYyqQusHbd76u 4EbYzZNtk3kaIGqyVhfMAzQXuqj8LuUV5FaNkhZ8vv3p7vZnmm6UIPaaL1YZQ2kBMG+ZaKELXnCU T03I2nL4DIVvBVMOXkoBWw3JOrZKko0JPgs2QG+rcn1NXm9IrqN5vSyYkK7vTvYIXZMAs4S+6hd6 CPXrTAJgCXo4yxspW1zIireuxVwVgnIRgm+WFW9lrcQqa3V6i9wyc/C4v/V83rauEZ3KAsSNjNM7 nyrPzm420nY/3N8+vHzlmbkiGdmc9s2vEBahIhiJud12s6wCDGqLRMUQu4hqWfZ10Pmpc2wuFohS M28jomyWTZQj3pRP5yGdc7ldn2R6wwkDFBaXv5cF8mqLe0Vw77HOa36+IWEf+ihV7O+mfNQ25O1A 76v0jds7bSxz+04nLuIrNDpHoDpV6r5govnyUlZoK3JqONXQcBvQMYkhytbgFrcQ6dXHKYZIWPZK pfXrk5PY3TigOKSOIabc0n/5nI4kpKLUu09wNSUYkPhBIgP1S/ij4y83iDPiN3FTURTAXr97+vgp KgN/QAmgmoMmQJXWn39foKq6ry9xkBcGc1JPHb2WWA8ykYujkq4nDMnPI17CgZzY1jAYHeREtFhP K9brGAXNKDqcOQiZwthdDKx/EANrV9AYqIDAJ/5CeTpG2LjlENGs3XBd7lreOSbWUbAtji1gJsXb 8HzLkphwPbbivXWL61NrKeWjnPnBE4wQ8Pa8bCa4e0+djQ3wov8IoMs/vnz+AWcZHj/dxdEGHG3D btzLXdzZHDs9emTi9sUrXN4/Pz2EYbktyWPnnx+HNtE9l9ZrEnCTQ7eKVhola11o4wEh9QY1rVsc oUSiR043OAa/hvkbmZ5KG4lV2lhat4TjJoFT3mdL59RqPT0IqEpnEHlg/YOYaxIjzGqffdBTxJMr EzUt3wUr152ACXJ+YYtznOcrOfvAcw6BCdfL2QfxSFs8riGOyJXfMUgimUS0bnF9vkngDoTNGc94 TCw669pvLjOzcRRLsAnE1iP3t9fP9+7z3z1FORjPw72/czO4vX+5/RkHKdwCYh3KueIP//79f1kc +oJjtUH0HfzZ4tTMAQdrIRqYAQpmxV04dp8xqLlczE/3jDOcgWVd9NYt0bhB4IBzxyBKE0z/SweB wY4NAhTnGkSLWSXiktjv7Ws1cNvL5QGJRXyvXYvnADheAJx4kDlZ+B2mQIymAI/gtKo4db4l4BTE GQekETo1gw9D+AOP8GR2Z8/3SWEfPr9gt6UK5r+OiBUzLJ7KQUlM8KjZINWBI+Tw+oVt2JkMiPxl S2IfVkSt8dJwtSj3GUobPJfHOGZezvhD2q0qG1hwPRXfIXWsFDCu16SkNrj894RrQ+kAHhq5UlTv cE9OIWFhe6ltYLKd26LY5ljXKXSawEhSh8VbQWplYNkLpbZjgwDFAaeAiWcgcNTpx5dhdAogxYRd dVh8dsWlPIq4lgdiXCPle3GHKE7hO4RhEaJCsiUx8LxLLzkGGKb8/8gWnTERGfiWks65pvHi5gmR 4OPnp8/YCp11NoQR25p7Hm8SonfjEbkbFS95YYILl6lX123IaYiZUHAVVuAtA0M0QjToJU4rn8c5 DRXeXuFJHuf0sr0O27b+uzoFbqLbdnZzYdvT9l/bSrctbNs9X9lf3tvudb711fbNjbZtytufjZL9 a7/XgS3M8DoqlmxIenecnAEPD4MoEYWm5xMO7wQGuRAz4wal1DYZfEIjuKkE0/E6TV+T1GF4nYRF h6ltDEyu1MMntD5rwOtA6Qa8TodZEV8PeJ28T1DtGrSvA/Ib/5Ip7BCF63ooZsZtQFT70rDZEuL9 gaRW8XvK5Riv9m076Pc4dSgiLwuOuJqFm/5T7J3t1Leodtro0idcg6wtt3jG272PqG9AZCZbEgOD u/QSh6eduuntXgyqJ/IYLYuSCxpzMY25g/kugG69Xo2kAHt72Np15WHucAFHbHfIBcaB3UPnAqP1 sW1g4BfRPheARXnnlbC+JqlDuoD2IFSQ8QETg5hwATOYNaWj4QIwrsoF6Po53QiGKi5bYtBqtyek CeUovEPQ0QJlg2fLSke79JKOpulwoJ7YBHCS8LPS0XE3gM1EW5FEPvUT5raeoPiV05NtpyC0Cz3E NIdwYI1REoMHJxazQGqb1CKhfbrZvQDMGyDUjQapu9DMhEV33hZDDUzKuOyl3kxxQjNToMY/pkDt l3i+y7VQOI6CtXrZRohK6FtnPjnp/BlguOJ+tRyoKDVe4ZoYV8tlKaOJPQZNF/keQ9khGNxjGNXr 32qq28sJfRQHhc+AtJDq1HL1IkCIgRClxZbEcFdbl16S1/RUp1ZAaZUdod6biOv6X5noqiX2KLt7 MtD4zMEpbo8szl4uLk82rDc76TLP7RoeW6ougOVlbWqbbDih4RUSo+hG4CG1nLCvgXfHYXEI2WV4 2zwsiKrno+a6EQhyKFn/VvnnPV4sWB9xIIB+JE63OYTP9QNv7jSwIcOWlWZ26VUMnwpzC7sYhC3z JNM7ilZwuFRtsfzIsoBgbLNZvo17FjJ94P0LzKISEZzO2ELXKUUwixIMw60gcjM5+Fr2XBA4OFRl iYNexcNuXOZ0ojvkkBYOAcHkyBBAb67SVozCXxKjVGlBaunCrB2VebYXloZNk+Npqxwvp+IDE447 hntBfKuKmeLAcqaYFCueT+mtSkD3EXFZyOZ4tVumt2ljPbYEfffw4/Xzp7ubz/fX/gJr+rHswl+W vZU/jOxFohbQr4u6f3r8UW6k0ln15fP793c3uGOznZwOwb0mXeGhU6gj5KMXyOGEDzGU9sg9i4q5 7vE116yOffQq6XSqwhm7hQmxMzfTvgFE2FfZgw/AXLuZ+Bfawy8SC1J58VolXsES/1MsRD62QDSG CPsKVMeC3rS1STVlCgwGX2UKWgReVFrKPsofy2YiiqvSrsodMm5vt4yZvWoUz53LTduJox38Dsrx E/eh/9jf3cnmYJZIYCESXHTkbQOD+yP6WqGYqWHVWgulN+ar00cS89nBn/6EBhz6DCcBnqWVkDw+ erXGoS2cLIwp8qGRO4j1Zt3AEBUH5k4iNQ0ILGrTw7jGnUS7gax+ozM6CcfSJM2+xgYAegNOQoL9 M24wZHiX/lizaUopZ6fbcCszdQ9fipBuje1VqmMTEDVPG/Gv4HJNpWJwOIaB5IVyDcVtoYN1JVor w+ZKaMkLXBHzg9fQjOQye1YcUDxnrrq3bkQCOS2NSNoWv9/uLnFMQMLWiEgOsrF3lTm8Cogs9ZbQ rhSPOJrp9fN6YEVuSnskr/9/uW8i53FwslhWlBEHHKRkWBW/QLKaK1BYszdMNo8gsYdaJZR2GNJp ILGv9+UjGuu+CkL6qA34F+j8Mv/yFkH5Gqt3LBRzUB713GEW8rVYZ8idR0nhD6VtxoTfXYoVv8Ph DBiBcgzhSDicBUH5hVTejXiapamkqK4rOoayFpwkO21xwSdDXYeQmy+XVoBf0ZJYXiQGPbCGJ1DG 1ojRgt2F4juEC3iXj2BAG3+L2c6XiBA9XMAVUpNgOCoGULuFXEfBMDBiePpSi7zA8VgiEuMSMVqD YtLG6aSbCtKWiHjWvn1JRGv266TdWnWhd9ijnhn5/pr7Jajewd2oksIj26vaIRUF64mgZsF2tiX2 QYrdOhQT29UFSAXB4Bk61WgkwjGkzPbRwDc2TL5oV69Ed9AyD0A6QbAWkuCBVwzOsi9yMQQqHuRi IofArQJlo2RLGmopJqrpVcxyt8CKW9KZM4LsmLxlHlXvCAbcQs8kRVVdFgTHfh5oppWZxnsRQAsj WPiT9LO8MkqdFY7DV8gRUNdPkGLbrJ9ESbFi+dQkVdgoJqP6uWCOwsosdvSiIhZLteIYvqbDevGq pTsGRBz65LPcmOwYpEeMTGZbYlA0LGBwlBqLbPfmlT8OxzB8TYda1VkIdB3D1LGY1c9aFmQlQnb9 xV+tUCjY78dUSknxa9bI+hyw7jWbcYJput2OSz/xB8/XEqIrYEti4BkYuKvpVbrq7oH1x+0WmPTY XWcE2RWw5dgIQG/APcDilsWwIDWwjJu9Ro73m12n5HNjv9/1jBv+4R5Uc6X+TYoxKi31F6ETxcTy 6ajB2HiQ6SBraf+GfzdqQH7YTwhrqbxun0rWuKTVHuTidQXjVNbz7QOuZH9XMsQWBs8MNYbyGcUE 5MPDHQ/IasCVg8ESgklpBoxACIn+H/bHKtTgwSF3xpBVHCaiXLxtDj9QENNDMclq2qMUyxCHll35 aKgR1eLtUKNieWw4vcaLdFj+2tONTBd7TI3T8zvcqHiofDgxcjyaEpISC7uh3W2jSHb2Kx0p09xj G6MuXNLIUPwl9bdjcdwO5/ihPrLS9Dhuhwqdqx2ORzmEDHyBsptky+wmiQa9ShM90+D71j2/9856 +s9RnLfMY4Jkut8z4KZhmG03/YtHcXguTG/9w6e5IoK3SB3LDRmBCb8dK1oHEbJtpYk9FCuGT0Vx xrBTuOllUVwc6Cu+OJ+hetOn7l5XNpCcLyZE4Ytc+yOPtiF3ERLYI9+pr2MEBtUIjNz2tvVE6Wim uEwCZlxigu4M5KzO65yv3FdWR3gNoKEIr+xxz/TN4cvl8+SBUL2d1L0Eghjc77eR25wcwpomIDoJ b1kbrqPRuBUUu+PAtGMFL63+4YLZWfE94/1nZ2IPnubvAb35joPhQ9/yT4aGz7dH4KtzJNMxQ1Hb /Rqz1XknKbdQW0nIntdSm+UYvjcwqq23rdXW0UxxkdoWgWGboFLb/vjO90QiaLiZOkTZXIwdouys VSY0eWwK7EQZo0dic0jugV0R0gHXt1kZmAsEgsdaDcd7mLqDS3IsB3FsS8GBfA/FPiEN5pCKSSQZ 8UhaK3HnIhpMIVVxHaaV6VsrBufTOjOM/WasqXFQz3Kc6imAYU1NDKqO+nqIUQxJHy7dYoEimPl4 opL9VYoVozoLxHSJgXc4cxAiQXYXA4O0iMYgFvsQfGKfDwGHlvqQ9lYfs8N4F0WvrJUPRrpI97Id E647JjXfeiw4XWIQmC5rwFY9COGtW057KvhQjmlmGS+tnLfb47Lo4/4urhuIawiYV5J7Pi7fMgjx YpoycaiS2ZJBUvOuRYjUdGmhWKhoaps0JqGhMbXath+R94dIozsUaJTuynyqluMYhjU8BLWcviF8 RU8scqXlOouVG4Jj2w0pmLDcMepnNCWUV27W9vUrt6KxdSnA+NKtnPSftXaj7xzMwdPfyFvZMslI 0ueIjWM5XOcYTtYEhuSwvqqUPRix7MG8dWXQfSdrZg4iDax0WPnyqUFMuNE5zJq7gpBx5RqpSN/4 LB+bbNCrzelgVbM4XiePkMnhGcUk1WZYI8ezNLIUwu4wiUkQ4ai3rrge6ZvhWV4mHnWjeG1jf8JN QBMXX9S3Lf5JXw37B+9EvH703Fp6UUFzbXxRQR40uvuk98BoQeYDnke6frx7ibuV4qADXjYqq8Nw 0nq/Um8MB3ucuRqJCEQcJr1YKC6qgvACn1blO4ZlXWDUOLYlJo7CTtGEIbU9RXtB0mkAfWF33SFA L8Ia2ZZYzxBAccAQoLTtZMb4mgSkBuKJHOCOGkL2r8UO9rgYdifXHrkdyLgCo85HU0LJNfdawXTC 2ZgoZ3nmWEEn49y+9KKdXfaqZp6CL7/glUhvGWwsW5XkhaQ4lHQSUAqq8EgUylvI1z0ezpIKjpAT QgFiO0whRxwnBVba4ohqYFgq91CsopapsM/MYoMMY5FUCftmpjyq4+0tLxI5itd4ETt1JmU3xVxl 5S6v9+rhNJowMZor2xIDq/RoW02xYlXbi3QaiKGODCF7EbYdHcLX5UX0RJfekEH1jOtsXWVlTsbZ KY1d0nTKttmPECXFxPNpR2J8lHsjXuVIWgUv+Q0bvwXqz72Heb5Id8Pm3a2/dq8kRSMIkaEsuKhs dzxtruBABLgPANcgYIFoS3C2IlZFNkbL5dDcvERYM7jPzdUh3iA6r3GLxFhY03HoEW3Yjsmy9AU0 bjDulqOmVjOrdobblcrVVucrxN2Olfu1gMFGsQiTTB14x7aB4e4hoqLlStFZtRJWefqC5S99TfQK ooFBYGDRobfNA+sfxEC4IVNDVQYO1f2lD/zhGKUk6bHSVjXk7VpFK/1uLeqft8AFIKGnH1aOBp2K 0VNTl7AOh6QQZBSdXJCxQM0L7nkbXP0tLMxsxYyqM5Lu22IlWGYFYHCcBcsKkNqGUuR403UY6xAc 94ltzfZklciE2qbuCsYhZH1LbSeGMKCDv23ICzXQmVnGLtc7FSW0/PseJ3ypchHsEsrBrlFapITG O4l0lyshSq/yQaW48TnO5uGhHr8r30PefJBPl4HxY1ysnw7ylYC4fZ5P14exHGyd52vFb7C/8bzy mGPu6lQ5voer8iv1lzNFwPRmIC2zRwYp1ntS5i2l95KIJeres7U0d5OI/ewgwwZ6gG9gCHqVUGsI eVj9Qxgwid/CLYd2Y5mHlZ88yR7n9RwCd/0IH14T0UzVPQ5MlhqKgJTfBfSmLXZPuWdaBtYomy1u yxsLGXzLI3aleKq0qHIVyzV4RWKpukIkfVNjI/beCdlGN56Glnhw0DxkR7btca/wWu7+xJxpgsGc HRh4rq/pQTJxbK9gMDAoXaDeeqkg1MTQey2HmSu8sSuJ3qA4dHeFveuNzJJl6rE1lj6yEJgsOXDQ QR5ekCus3EataYbArS69yp+7k/C96/J7uqSe/iGGpf1neslDvDKl1qudMioJy5FQyPoovx1+wwQX VB8lTxqaKJ9rqzmIILTTMfDWnQQ4622JCb8d9datQGXSTajApIC3qGe9shjN4kvtcvfxp/AX5Q8+ ddpMaTPgYEnjUqcybw50pZWM6gZ3EVZ6XKBmi+gQDz/BTXGqCyhPPqQ2oNqYAXHxJKmwwXD3q+Hu zQ3FbEpqSbMx18xI8yglDyu+yO+2d1Q5hSHrLyVcMh7ZxpZbaaHhislSyTHsZ9v+C2e/gPLs522X Ol1ll8SFqILbw1CXzX6zSmqLfrMmt3cTdthA3nxXttdPQZ8X+ynxBQfUFsAm4JPW2M2RUAbxiLzB HJjEMgXbyBksmBX2ekrTFSG5N7FLr7IdeqkzNjRxIfRJkfiLTEW4Nw2OU6p/YFk5TYqb0W4wn8h9 r/bf7x/kOnOpjrIr01b/jmBls7rAI5v4r9wJiv95v7rBq5n4w/XjNzDYC7yCif/evlzikEj6JwHL P8mtSfjbvbW/+St+2nFXX3BQoCO916atNlD5k6YHwKz9EY+Y4gET5O/OB6nxdQyicgzXqlzu5TwC Kh68bcJw5sBRb93eAZqSn7zHirD/ClqxxZ0WsS2nQdC2f5LZgdkmP3nGRuJNlU+/bEK0Isrnlf31 9v4WT5N0ZDSxrAIXPE79Bf0ljg7btSkuD3GYCNTVYTomDrNglAeulyhtiWmc2qW4yMZQ54yHt6AF LqNsY9t+G6OM8FTWiIxEKiIJ/E8xv+fVtf29iGq+mH7NHe4NNknxOiB4glWb1mTBESJtpo/KBiZL B8OaDYpq11da2ci2xOTIU5din5iwwy1h5FFyveLZ4i8bBHq7PS5l3OCagsMah1VsXaemdOoX0x78 9/vs5b4VEYP+98Onh3v707s7XJIM3P5rGKpngcSDwdpKJPkRh6XwP+YH332+0b/hvlRgOHIi//MD Hj3G/9hf7NdG2H5rnaGuMf1qo39GVhDt9vrfbUKMEjYmFbO/3dvIPt2q/7bPkv11EMDTyviv/di6 t3++szFLVgf/XrHCiP2ktOzPd6UDvMiWerUxZw7IOZzelHozIySDt5lR5AZHtHgSl2rsqzOyxKGn cDGopj/hbGkTGFxMwaBQobtsS0yWwl2KkRX93Z9UT/GLnfzffvWn32E7Q9L1p90OAaEoMSpi/a94 2vbquDsfVieo8Vp+gHcZDtBtXBS+X52vUDEiqv+wOmqMAbcU2P3qTziXF6lYoVw63dmF72ErleHI w89n3PoahpP9227AcKAmZjgfPn36+M/ffffp6ekeZ62gPKZQl7hT/NtNU1TtkynHpdzVjJ/82Pn5 d/YPtS0YPcPeq/59N6BQmA7kxhlJC8rUMHH7TJmkO3HFK3IrlqTB5b9HufVhI1VUMlGhavJY/GJg iCECk/UxDmfK+t2bGqQTK0HS63OFUCM83bverNd71aL4i7xsdDphM2lzlFUwjpWZK+zGgoeQ4//1 DbRlt7r4FlzXP/xegIM6C5z/wSVr8ne8hw6b179DYvZDOAUFkJHRBnAl9Q/+ufwD3IH+AJfVK6V/ IM6sWvoP1gWH09MGu/L3w4D4X+VPfLl3xMt9pjj4EzapJMqR/9bep7IqsyaEw/L/+J/NGbmNfZlv EpPLfiOZ/G/KMzBVrEM/TbT7rLOL/rXNqp+O+kOwHVw1doN7+AME8gJRaSOJ10MU9gcIR//JZQKh WaPnbxqpHl9dOG/9F3/3P7gQnLr/3Yei85v18hEX7dVDscFBjXwArWHjXwJ5iUEhxhGCjShf/iJ8 JJTL+nKCPsxo7P/gbX/a27c2vZ/I+UiMxwUo0SQ8bp8MkQCWUjjKMJjtI/H/jW93IX5Xvsb/99M3 2JsF640D+Lj4g7hO/Sd54FT/EAoS3+ndQGPwC36dEUksx6rMWOb9Ooes5eripvA71NACDlPDfgZB R3GtUAqoBuaFQwRUG+gNXP2TuW/7C0KZfvIHzHqY8lpd9C9/KIkTPhBdbK/sfzeHf9K/W19XkAL+ cb2WvzYX//J/5L7/4/8D/Dh1ZAplbmRzdHJlYW0KZW5kb2JqCjUgMCBvYmoKMjkxODIKZW5kb2Jq CjIgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAzIDAgUiAvUmVzb3VyY2VzIDYgMCBSIC9D b250ZW50cyA0IDAgUiAvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQo+PgplbmRvYmoKNiAwIG9iago8 PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9G b250IDw8IC9UVDEgOCAwIFIKL1RUNSAxMiAwIFIgL1RUMyAxMCAwIFIgL1RUNCAxMSAwIFIgL1RU MiA5IDAgUiA+PiA+PgplbmRvYmoKMTMgMCBvYmoKPDwgL0xlbmd0aCAxNCAwIFIgL04gMyAvQWx0 ZXJuYXRlIC9EZXZpY2VSR0IgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBnZZ3VFPZ FofPvTe90BIiICX0GnoJINI7SBUEUYlJgFAChoQmdkQFRhQRKVZkVMABR4ciY0UUC4OCYtcJ8hBQ xsFRREXl3YxrCe+tNfPemv3HWd/Z57fX2Wfvfde6AFD8ggTCdFgBgDShWBTu68FcEhPLxPcCGBAB DlgBwOFmZgRH+EQC1Py9PZmZqEjGs/buLoBku9ssv1Amc9b/f5EiN0MkBgAKRdU2PH4mF+UClFOz xRky/wTK9JUpMoYxMhahCaKsIuPEr2z2p+Yru8mYlybkoRpZzhm8NJ6Mu1DemiXho4wEoVyYJeBn o3wHZb1USZoA5fco09P4nEwAMBSZX8znJqFsiTJFFBnuifICAAiUxDm8cg6L+TlongB4pmfkigSJ SWKmEdeYaeXoyGb68bNT+WIxK5TDTeGIeEzP9LQMjjAXgK9vlkUBJVltmWiR7a0c7e1Z1uZo+b/Z 3x5+U/09yHr7VfEm7M+eQYyeWd9s7KwvvRYA9iRamx2zvpVVALRtBkDl4axP7yAA8gUAtN6c8x6G bF6SxOIMJwuL7OxscwGfay4r6Df7n4Jvyr+GOfeZy+77VjumFz+BI0kVM2VF5aanpktEzMwMDpfP ZP33EP/jwDlpzcnDLJyfwBfxhehVUeiUCYSJaLuFPIFYkC5kCoR/1eF/GDYnBxl+nWsUaHVfAH2F OVC4SQfIbz0AQyMDJG4/egJ961sQMQrIvrxorZGvc48yev7n+h8LXIpu4UxBIlPm9gyPZHIloiwZ o9+EbMECEpAHdKAKNIEuMAIsYA0cgDNwA94gAISASBADlgMuSAJpQASyQT7YAApBMdgBdoNqcADU gXrQBE6CNnAGXARXwA1wCwyAR0AKhsFLMAHegWkIgvAQFaJBqpAWpA+ZQtYQG1oIeUNBUDgUA8VD iZAQkkD50CaoGCqDqqFDUD30I3Qaughdg/qgB9AgNAb9AX2EEZgC02EN2AC2gNmwOxwIR8LL4ER4 FZwHF8Db4Uq4Fj4Ot8IX4RvwACyFX8KTCEDICAPRRlgIG/FEQpBYJAERIWuRIqQCqUWakA6kG7mN SJFx5AMGh6FhmBgWxhnjh1mM4WJWYdZiSjDVmGOYVkwX5jZmEDOB+YKlYtWxplgnrD92CTYRm40t xFZgj2BbsJexA9hh7DscDsfAGeIccH64GFwybjWuBLcP14y7gOvDDeEm8Xi8Kt4U74IPwXPwYnwh vgp/HH8e348fxr8nkAlaBGuCDyGWICRsJFQQGgjnCP2EEcI0UYGoT3QihhB5xFxiKbGO2EG8SRwm TpMUSYYkF1IkKZm0gVRJaiJdJj0mvSGTyTpkR3IYWUBeT64knyBfJQ+SP1CUKCYUT0ocRULZTjlK uUB5QHlDpVINqG7UWKqYup1aT71EfUp9L0eTM5fzl+PJrZOrkWuV65d7JU+U15d3l18unydfIX9K /qb8uAJRwUDBU4GjsFahRuG0wj2FSUWaopViiGKaYolig+I1xVElvJKBkrcST6lA6bDSJaUhGkLT pXnSuLRNtDraZdowHUc3pPvTk+nF9B/ovfQJZSVlW+Uo5RzlGuWzylIGwjBg+DNSGaWMk4y7jI/z NOa5z+PP2zavaV7/vCmV+SpuKnyVIpVmlQGVj6pMVW/VFNWdqm2qT9QwaiZqYWrZavvVLquNz6fP d57PnV80/+T8h+qwuol6uPpq9cPqPeqTGpoavhoZGlUalzTGNRmabprJmuWa5zTHtGhaC7UEWuVa 57VeMJWZ7sxUZiWzizmhra7tpy3RPqTdqz2tY6izWGejTrPOE12SLls3Qbdct1N3Qk9LL1gvX69R 76E+UZ+tn6S/R79bf8rA0CDaYItBm8GooYqhv2GeYaPhYyOqkavRKqNaozvGOGO2cYrxPuNbJrCJ nUmSSY3JTVPY1N5UYLrPtM8Ma+ZoJjSrNbvHorDcWVmsRtagOcM8yHyjeZv5Kws9i1iLnRbdFl8s 7SxTLessH1kpWQVYbbTqsPrD2sSaa11jfceGauNjs86m3ea1rakt33a/7X07ml2w3Ra7TrvP9g72 Ivsm+zEHPYd4h70O99h0dii7hH3VEevo4bjO8YzjByd7J7HTSaffnVnOKc4NzqMLDBfwF9QtGHLR ceG4HHKRLmQujF94cKHUVduV41rr+sxN143ndsRtxN3YPdn9uPsrD0sPkUeLx5Snk+cazwteiJev V5FXr7eS92Lvau+nPjo+iT6NPhO+dr6rfS/4Yf0C/Xb63fPX8Of61/tPBDgErAnoCqQERgRWBz4L MgkSBXUEw8EBwbuCHy/SXyRc1BYCQvxDdoU8CTUMXRX6cxguLDSsJux5uFV4fnh3BC1iRURDxLtI j8jSyEeLjRZLFndGyUfFRdVHTUV7RZdFS5dYLFmz5EaMWowgpj0WHxsVeyR2cqn30t1Lh+Ps4grj 7i4zXJaz7NpyteWpy8+ukF/BWXEqHhsfHd8Q/4kTwqnlTK70X7l35QTXk7uH+5LnxivnjfFd+GX8 kQSXhLKE0USXxF2JY0muSRVJ4wJPQbXgdbJf8oHkqZSQlKMpM6nRqc1phLT4tNNCJWGKsCtdMz0n vS/DNKMwQ7rKadXuVROiQNGRTChzWWa7mI7+TPVIjCSbJYNZC7Nqst5nR2WfylHMEeb05Jrkbssd yfPJ+341ZjV3dWe+dv6G/ME17msOrYXWrlzbuU53XcG64fW+649tIG1I2fDLRsuNZRvfbore1FGg UbC+YGiz7+bGQrlCUeG9Lc5bDmzFbBVs7d1ms61q25ciXtH1YsviiuJPJdyS699ZfVf53cz2hO29 pfal+3fgdgh33N3puvNYmWJZXtnQruBdreXM8qLyt7tX7L5WYVtxYA9pj2SPtDKosr1Kr2pH1afq pOqBGo+a5r3qe7ftndrH29e/321/0wGNA8UHPh4UHLx/yPdQa61BbcVh3OGsw8/rouq6v2d/X39E 7Ujxkc9HhUelx8KPddU71Nc3qDeUNsKNksax43HHb/3g9UN7E6vpUDOjufgEOCE58eLH+B/vngw8 2XmKfarpJ/2f9rbQWopaodbc1om2pDZpe0x73+mA050dzh0tP5v/fPSM9pmas8pnS8+RzhWcmzmf d37yQsaF8YuJF4c6V3Q+urTk0p2usK7ey4GXr17xuXKp2737/FWXq2euOV07fZ19ve2G/Y3WHrue ll/sfmnpte9tvelws/2W462OvgV95/pd+y/e9rp95Y7/nRsDiwb67i6+e/9e3D3pfd790QepD14/ zHo4/Wj9Y+zjoicKTyqeqj+t/dX412apvfTsoNdgz7OIZ4+GuEMv/5X5r0/DBc+pzytGtEbqR61H z4z5jN16sfTF8MuMl9Pjhb8p/rb3ldGrn353+71nYsnE8GvR65k/St6ovjn61vZt52To5NN3ae+m p4req74/9oH9oftj9MeR6exP+E+Vn40/d3wJ/PJ4Jm1m5t/3hPP7CmVuZHN0cmVhbQplbmRvYmoK MTQgMCBvYmoKMjYxMgplbmRvYmoKNyAwIG9iagpbIC9JQ0NCYXNlZCAxMyAwIFIgXQplbmRvYmoK MyAwIG9iago8PCAvVHlwZSAvUGFnZXMgL01lZGlhQm94IFswIDAgNjEyIDc5Ml0gL0NvdW50IDEg L0tpZHMgWyAyIDAgUiBdID4+CmVuZG9iagoxNSAwIG9iago8PCAvVHlwZSAvQ2F0YWxvZyAvUGFn ZXMgMyAwIFIgPj4KZW5kb2JqCjggMCBvYmoKPDwgL1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVU eXBlIC9CYXNlRm9udCAvT05RQk5CK0FyaWFsLUJvbGRNVCAvRm9udERlc2NyaXB0b3IKMTYgMCBS IC9FbmNvZGluZyAvTWFjUm9tYW5FbmNvZGluZyAvRmlyc3RDaGFyIDMyIC9MYXN0Q2hhciAxMjAg L1dpZHRocyBbIDI3OAowIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAzMzMgMjc4IDAgNTU2IDU1NiAw IDAgNTU2IDAgNTU2IDAgMCAwIDAgMCAwIDAgMCAwCjAgMCAwIDAgMCA2NjcgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNTU2IDYxMQo1NTYgNjEx IDU1NiAzMzMgNjExIDYxMSAwIDAgNTU2IDI3OCAwIDYxMSA2MTEgNjExIDAgMzg5IDU1NiAzMzMg MCA1NTYgMCA1NTYKXSA+PgplbmRvYmoKMTYgMCBvYmoKPDwgL1R5cGUgL0ZvbnREZXNjcmlwdG9y IC9Gb250TmFtZSAvT05RQk5CK0FyaWFsLUJvbGRNVCAvRmxhZ3MgMzIgL0ZvbnRCQm94ClstNjI4 IC0zNzYgMjAwMCAxMDE4XSAvSXRhbGljQW5nbGUgMCAvQXNjZW50IDkwNSAvRGVzY2VudCAtMjEy IC9DYXBIZWlnaHQKNzE2IC9TdGVtViAxNDUgL0xlYWRpbmcgMzMgL1hIZWlnaHQgNTE5IC9TdGVt SCAxMjEgL0F2Z1dpZHRoIDQ3OSAvTWF4V2lkdGgKMjAwMCAvRm9udEZpbGUyIDE3IDAgUiA+Pgpl bmRvYmoKMTcgMCBvYmoKPDwgL0xlbmd0aCAxOCAwIFIgL0xlbmd0aDEgMTYzNDggL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBnXsJfFRF1m9V3aX3Nb1n6e500glpYrYOIRDJDSQRiJAA AdNohrBKxoVEwF3BFQiOxAV3JTojMOoMnQ5CwjLGdZzFD1wHnXHkc3AUxzyZGUTHId3vX7cDLuP7 3u+9DnVPLedfy6lTp07Vvay5Yu1yYiTriUCUpZct7iLqL/B7kN8uvXJNIJ3OGE+IZuGKrosvS6d9 GwmR/nDxpdesSKeDhwnJ7lm5fPGydJqcBp2wEhnpNI2C5q28bM3V6XSgA/TSS1ctHSsPPoD0xMsW Xz3WPvkT0oHLF1+2HBS/2t14FHatWr1GTZLai0Dbuq5YPsZP2wixvbHwez9CwZVJ/kFqyBYiE0as pITMx0hq2AtEQpqXS5aLfjlrw8uLLDVfaL1atfon/lKTzSMvP7xk/tdfnx61Em0eeHUqPy8ATjMl OZtMs5Kvv/76WquawwvO/jL7W9fXmYRnyC4ENIxnAKEPAYIWnhnQmMqVQVC7Q6UJV6R8KDUsPJOY VKHmF99bvv6A8DRZRCqQ/XRiPs9+ekCp5+xPD1RMTtOSMpUmtOlijaPcX+cDrASBEctYrBl0C8I2 hOcQZHToafIBQgpBEHYKTyQa/aj4SVRkqXMIT2KICp6HEFIIAnr/JMbyJPl8LEdEr346oDPy5n+q ojKFnwJlwdOKsB5hF8IhBImswnMbQgpBQOwJlD1BmPCE8HjC6rfW6YXHyDoEJjxELJQSP2p/YMCq yubBAUtGuVJnFbaSFgRG4sIsMozAUO1dgN1FGNibEsVlqgibBvTmciv4N6PTm9GRzWiyD0+qphXE OP/mgQwX7/wtCYtNxV2XKI2mIwNWT3kLpHA1ocJy4XISIn7hRtAc0KWg2aBLhGXEpPZTGbBYy9ej vVqw1wpOMg7FdYKLlIPWCz5oIB/O2oQ53c7aRGFROUY8TfCoLBbBRKJg1QqaRLk/sF9QVOFvHNAZ eP82JqzO8oPCbYKGOMC1Hlxuv+WgoMcc69WRtA7oTOW9dUahFcNshVj86COFlPlTES5PoKI6m9Ag ZBEXyi4RsokTtFHIUekO4XHSiPSjA+Es//B+4R4VdTevFM1PSavWlAGTuXy4TidMQWlcuBMTcKfa eO9AeGI5qQsLhaQUgUHG6xBbh5hV6EGsB7PWg5nqwUz1oFM90D4ibELJJvCUCNeSLuEq0ouwDXGu Vs4EBMoXgzORV1g+JHgFDwRj3Q9RUuT6BnRm3jNPwp6hsnkGjOby2oPCatKMwDDkNQNuT/mq/UKR OpTxA55MDuhKQF0PCu701KAmF5+Sg0IWBMEFky3kJJz+eJ0faa7IfkLZb9lhLiT2JnubTzc7hDSn vxujr43R/0rT1DA7nF4U7A1Oj9ZlsY9Q2SL2PtmGGGP72YukFBW8xwb57LN32RCpBT2C9DLQIdAK 0H2J4Kv+QTY4AIK+P5wwufhg2YuJSMlYxJ8/FnFnjkXsrvK6fPYCe55koYo/gOaBPs+GSS7oc6Ae 0GG2hrwK+iyrJJNBd4/Rl9gBruJsL9tDJoIOJMy8C/GEhpNdCZmTXyZIOtVS4j/AfsmeJj6w/iIR 9qFw50A4z2/Zj/ooe5KtSWT77XV69jhtoyfB1EeOcErs7IlEFa+kN3Eg4B9ivaxX8VQp+Uqxsl0o zS8tLt0uBPIDxYGqwPZAnZXdCQOyjWH9ss14VpEAg/YgKAi9bFNCrIrXjWJMfFyMrMezT4114Nml xgieVjXGS0+osVp2G2lGYKjjRoR1COsRbiIintciXIdwPcINas4axNYiXAVr0gVEFxBdQHSpiC4g uoDoAqJLRfCWu4DoUhEdQHQA0QFEh4roAKIDiA4gOlQE728HEB0qogWIFiBagGhRES1AtADRAkSL imgBogWIFhWhAKEAoQChqAgFCAUIBQhFRShAKEAoKqIUiFIgSoEoVRGlQJQCUQpEqYooBaIUiFIV EQAiAEQAiICKCAARACIAREBFBIAIABFQEVYgrEBYgbCqCCsQViCsQFhVhBUIKxBWFXEUiKNAHAXi qIo4CsRRII4CcVRFHAXiKBBH2VX9wuG6lwE5DMhhQA6rkMOAHAbkMCCHVchhQA4Dcnhs6FwQXGGG gR0GdhjYYRU7DOwwsMPADqvYYXAOAzusYuNAxIGIAxFXEXEg4kDEgYiriDgQcSDiKqIPiD4g+oDo UxF9QPQB0QdEn4roA6IPiD4V0QtELxC9QPSqiF4geoHoBaJXRfQC0QtEr4r4f54adhNt02KvZevp OJWuI5+p9EZyRKU3kH6VXk+2q/Q6crNKryVVKr2KhFWKqVbpGuLX0oS/ylLnggloRliEsAphG8Iu hOcQNGrsEGIfIKRYpZIrWjTNmm2aXZrnNNIuzVENs8jN8jZ5l/ycLO2Sj8osUJfJTKodhWkhW4Cj ZB2enyNgE8GzVo3VsijajcLOVuIvyqKKbSTweRE9VESfK6K7iuiWIlqnY+dRUbV0AVLFIADaphjD U/xHEKrCBVNgme7c85nbnwhP8A/SA2kyTokg+RlCP8J2hJsRqhDKEYoR8hH8CFXhIsDalNyxKg+A FiAEEQIIVcTlgp9ot2mVIWai2wdeNhEdb6egELj9iYJSkMFEQTPI3kTBEn+dju4hBdwros9iUT0N uivhP4biX6TJMwn/fqR2JvxRkPZEwTkgFyYKXvPXmeh84hc5tHWMzsOE8/TchH8B2OYk/ONAIomC MOcuQkP5KB0Hj/oYKOIqOi/dUijhnwzu3IS/mnNrSQGfeCqTYrV7EuI8LQygQ58P0TaRKgb/iP8e /2fo798gWKjHu4FBEeRQ/iBdoOj9B4ofA3OdP1Gn5/zYH/rHaJzTZ/3b8zf5H0ZdNH+P/0H/Of47 iwe1yP4J+r1JbSLhvzkwyJ5WMvzr/aX+NcXH/Kv9M/2L/XP97fnIT/gv8h/g3SQx2sae3uNvQYUz MIr8hP+8fPQFXWz0X+NX/AX+6sABLl8ykTcNTS4+wCVAytOtj4d8i/LResI/v2qQ2pQizQlNr+ZC zVTNZE1Ik6vJ0WRrHFq71qo1a41avVarlbWilmmJ1jGYOqpE+DnBIavHBVnkCVGNWxmP44EnYVTL yEwSzxCaWNO8qbQpPryUNC0JxE/NCw1S/ZyFcSk0lcbtTaSpdWp8YqRpUJOaG6+KNMU1LRe29VN6 Zwy5cbZxkJLWtkGa4lm3Zcbt01BIbvtJ5hCh1HvbT2Ix4nFdWeuptU+xVTfW/8CjQ83sqI988/N8 O5odv69pXlv8qexYvJxHUtmxpvhN8wIXtQ0xCzM11A8xMyextiGxi1ka5vJ8sas+BrZjKhu02Qw2 UsAJ2LRTSYCzwZ5M5WyYozRfGHDwBTkBn95EwipfWG9S+UTK+fqPBBrq+wN4gCefkCMqz5F88i0e aAyw9f1hPMAVCtA2zkXbQgG1Y+PUivx+sBTjARYKf0+tyE/VxuIl37Dkj7FUnmWpVNsS0v1Rq+EP VOMoPMPjKATPN4L8/4stnxqhA2Vrb3yxYXmooSPUsByhI775ypWe+PolgUD/jWt5QSAuhDuWLF3J 6eLl8bWh5fXxG0P1gf4yFfe94hd5cVmovp+82NDa1v+isrw+UaaUNYQW18cGamva6r7T1qazbbXV /EBbNbyyNt5WrYr7Xlt1vLiWt1XH26rjbdUqtWpbDZ1c71va+rVkamwa5pXTAWbQQ4c7MoOxqS5r 1xSu0EOTg54bM/eJhO4khkgsbgxNjZsQeFFxXXEdL8I640VmZFvGijw3Tg5m7qM7x4qsyLaFppIz E0E4vileOacpHpy3sI2rSlyBCH5ozlbzn1rsIQ2d9fiH9Bo1rFm95kyNnBLO+Z+/NT/0W7t27eo1 eKyNrCakKV40ryk+YQ56otGgqY76GPLOOZMnCGpev07XMJgaRmEEnaBreHM8FqERSFDRE5loWJ/c p2H8FLFmwJddvuog/IZ1CDgOs6sSuErgRVcN5ObjtASWkso0xXGVpxO+YDlaGKgClNP8NFVsxYj0 5vcW91b15fcV91XJKN2zHZn+7XwrTZRsF8iayOozwkB0TQzCRrd4e48nsrLVhvt4JBKJRVZTVV5n +L+haj6S3wgWY1R/q9XqubxVCePJoxA6L8V8pFtfy1P8l46oWMhZBSEXXOmUmsUf3/yQwlXRPpKl hh0kSwzjjEVSx86EZGfqGC/jlH0KS44bJB7GfgnyDPkDLaQBMkC/Jm7yFfXSMjID2vklzhO7yCjZ iuN9K7mP2kkeTqPzyQwqgidC7qAPp65MHSfnkrvJE6m99ObUUyjfQl4hX6EHf8aOWUVmg38+WU6O Cx+RWOohoiUbiIFMJnOpiywm7+DvC/TjHnIv+RW9PvUVWnWQm1FfDakjdannU6dJEblD7JWO6J4l d5H9VE4tTXXCQ8olPSySeif1AQmTGPkpeQZ9itBhcToJkkvIbeQB6hVeQWwr+RlJUiNrF6ZJz6Gl GWQBuZxcRXrIU+S31E5bpCPSidR1qY+hhRmkEH3qJMdpJZ3FnhSNqSmp98iFZIi8ivHyv2HxQnGH dGGyNvVo6gWcvvdSPT1An5fKpTtHb0o9nvol7ivDpAwSmY12lpBbyPPkN+Tv5B9sXWodmU7moeWX aTYN0DAk/g7zshvZjcKb5ByMth29XUu2kThJkH1kPzkI2fyRHCUfUQfNpDPpEnoX/QczsmXskPCw sFt4S6TizyHvEMmHjNaQJ8ke8nvyGjlEJdRfSlvoj+kqej99lB5lcfYZ+1LUireI/xZHpXDyaPLf qdmpL3Dm9pHzybVkHWT7UzJAdpP/Im/jVvKf5BS10ol0JX2cxulR+hnTsVzWzLrYfTg9/0KYLdwl PC9WilPFS8TXxPek26XNmsWa5OntyXuSv0i+ntqbeh26Y0b9YVzgdJKboBVPkufIm6j9XfI++ZDr D+qfTBfSH6GV1XQjvZf+gr5MX6efYpTwOPCXyyazerS6il0BOd3M7mH3ovVD/KYDlxTvs7+xLwRJ yBUmCN3C40JcGBQOC38VrWJYPEcsE5vFhWIKM1MunSfNk3ZKT0svSCfkGnmZ3CV/orlZc6v296NF o39OkuTKZDw5AN3VQpOuhSQeI7gEhCz2k99Cov+FHh8lJzELPhqkBeh3NW2kTXQWvYBeRJfTm+kG ejd9gD5Mn6C/xAgwBqZB3yOsjs1ji9lydivbwH6Cu4zdbB/7DXsHFyoj6LlbCAkRoUyYISwULhQu xxjW4CrvVkj2LuEp4ZDwpvCx8IkwgllzizniWvFa8UFxh7hbfF06X7oMf09Iz0nD0uvSaem0zGSf nCWXyD+Wd8ofamTNBE2LZpPmLc0/tV00ixah5wHo/tkf82IN5rCnmENcR0eQnY1ThwUjj2Ae5mFV /JPUCknMi5mXo29O5hUzOFxWxDgcwTV0P6mkL5N1MhPgGIpHSYL+iR0VX2TnkrdpB/WKO4TLpd+y IHka1qiXHWD76VSym9WwBewRgdCPsCt+BH2/mtxLL6GrydN0hE6iN9Aquo68xVzCPHorqUk9wUSq ozPoCYIekJvEZeRHZ4fwgxFajdv548nHRJN4PezTILkPM/oM+YD+nHxNpdRnsG4CrNFiWJk7oO+3 EW712rHO1mE9emFBLpUPkd1Uxh16lTxFvJacIP8ix6V90KipsKYfJzvFx8S/pKpSxVhhWGVkJ9bd SnIeVsxH0JKDSPPURVjpetgSXD6SFrIQl2c3wOrdlYqnHkndkromtYr8Dtiv6Xj6Ne3DihgEogb3 Xq9ilbxLN2MdnveDw/u/ZiaXkWHyKfXQfFqO9TAiXSn1Sk9Ju6VfSa/JZZD2reRhaPSH0GY9RrCU vE4+JV9SLebGS8aTKPo7EX1vI5eymHCQTKM+0oU1Wwg7PnVsJKtRy82Q3iNYzwexNk7ATlxEfoX7 M0bdGNFStK9FPU2Q8yKymmzHDN5CB5CzDFa7iPwN4zbTibgeGE8U1HQfrNYw+vQn8ldIO6X2azzs Qj1dgLq+JBeQZWhhAmmh/ZiBPaQalrVe+D3knUetZCrNpT8DrgMr1IzL72rpL5SR8cnZqYmsUziI PSaF/D7sXpnkXNqNXlgwjlHipM2kMjkXfXiTCmKcvqH24kG2PLVBuCp5Kfkd+TnmRBGv1NQTotS1 KrVTzq2ZPKl6YlVltKK8rLTknOLxkaJxhQXh/LxQbjDgz8nOyvR5PW6X05Fht1ktZpPRoNdpNbIk CoyS8Q2hxo5APNwRF8Oh6dOLeTq0GBmLv5XREQ8gq/G7PPEAxy1G0Xc4FXCu+B6nkuZUznJSa6CG 1BSPDzSEAvHX6kOBQbpwDk4T8Z/Uh2KB+Igan6XGe9W4CfFgEIBAg2dlfSBOOwIN8cYrV/Y0dNQX j6f9Bv200LTl+uLxpF9vQNSAWNwd6uqn7ilUjTB3w6R+RrQmDDHuC9U3xL0hQFGNkN+weFm8ZU5b Q31mMBgrHh+n05aGlsQJ934jKguZpjYTl6fFNWozgU54t3GyOdA/frjnjkErWdIRMS4LLVt8UVtc WIw6GuK2CNqtj7uvPeb5JonK4Sdv+HZpptDT4OkMcOaeng2B+PCctm9hM4O8hlgMdQDL8hs7ehrR 9B2YqSZ+pIqz22JtcXobmsRhIV8dVXp86ZNMfsePA3FdaGpoZc+POzA1vp44mXtNMOHzKUOpo8TX EOhpbQsF47WZodji+qx+B+mZe82AVwl4v1tSPL7faksLtt9sGYsYTd+OLIfQ02VqTGXnsaa5ZyVL eR9DM+CPxwNLA+hJWwhjmsgfyyeSnqUTMQH4xShQ8WWYkc64blpHj3USz8cQaVzKt4YCPV8QaEBo 5LPv5iwey5HzrV8QXsj15KyqxeniM/F4JBIvKuIqopmGOUUfp6jpyuLxVw6yCaEuK+5GJuAgSFog 28WxSSUQfzDIJ3jzoEKWIBFfP6ctnQ6QJZkJopTgvMQ6eAkmMF3inM9L1p8pOQvvCEGTd/N7C+KM a8Nn/1msroyGlZPi1PU/FC9PlzfNCzXhdBNo6OkY09qm1u+k0uVcoJAbysZi8YxpbUImQx6PsUxB LYVSXrTwLAsSbca4mI9/Mu80VocApVQzaKAxbu2Ynn7G9MHg2JL5T8ygRvst0GDqBEep5BvY2Cji kyJj/Uz3Oj75O+nv9M7YIzS1wuKwptaFPT3675Q1wpb19DSGAo09HT2LB1Prl4QC1lDPENvBdvR0 NcAKpSd0MLVvc2a88Y4YhrKSToLaMjK1P0Q3zulX6EYcX4dwxRTY2NqWYJRN65ga689DWdtQACZX zWVnczlPgKdIE4WiJ5hWLcocUghZr/KKaoaaXorrJTUvzYQ8SpYOsnSeVeWLxWLFcPhxs1UNb+Yp shr0HnE1WYDwBEIY4QJpAdkKOkP8C9kAOh+0FbQO/B41/hdyN9KbVOxfyF3Im4uwGS8xOX8p+Pyg BgQjIWiMqyJBXCYHQAPwTdI5avb3HgyeChwrIqn58EhwOf0//dKfB/xPHD9cpoOnYkCfTNgnLfgK gf9sxI5nBk5iTlAXvCYPqBfBh8B/E/DXTq7HyaqW/p6tYC8Lvxdnip9IHfIK+a+at7St2k91Ad1W vUm/WT9q7DOVmt4zv4z7Q0AlPiQBo5m6m9GkrBlktUoGkcSkQPQaMUmJVytLSSYcoGGiw+HDQzwR 66ma0ZrZ1pM1s0ZrSC3i1tN4lJUGbUFbPh64rSSnA8LwaUUi/yYBcZhLu45uYJ2sD22VK8FSqsBB qULLViEglAqiUC9ZMQWlKPaKT17qicy2HmufZf1rOykZaS8rzUDNdawQrr03+TGv7R48nqFesOcp TjaR6FnYgutXXoOIGi6+ktdwsn3WKKmdNVJWWgH8PfzIyNGMLEh9LJqlYcg4QO5Rmq7Wb9TvoE9p ntLtMO/VvarTLrDFXDHfAv/FtpWulb6L/dpqVi1P0E0wzWAz5AZdo2mH7nfsN/JLupdM77I/ym/p 3jLZrJ6Ah3lwoaHk211Rz3atyW8psTCLgpRlO5GyjzTjhOjLdRwxeINvvqD2b9bIbOup7lkjpHYk 0s1DWSltJ+3ttNztslk1ciiX2KxVE9y5ska2WV2uivIJVRNs1nCYlb999Zbeq95+J/k1nhUtruxo c0WaSMMP7E4uSnbsuQ+u+nb62J77jte1XpbE73l4TpdC7Oz5OkjwCQg/DBnoyAJFdwm7Dq9MBSYO 0nEDiyQqDbIf7dXqJEqMOpzy2yAzytoVk0REvxgQ46IoevX76A74y2lB18ziOgFlqK052T5SXVZK 2oNBm6ypnJBXVSGEkx8/9PrllJUeE0O9Dam839zOZyGMBVWPHuih7R8o1caAqVpn9BojxnnGS4wf GuURE5VFl5gvFpqmmy407TDtNb1i0lFckhtlk0bSG0waYjSaTIP0l4pPEB0C1IgZRZNgYqKeaBTT sOkwEvtpIY6SjO7eQ0QRAIJXLrulLXqqH6RMsVvxOuk5jaDxWWrZOsaY17yPnk+nq+M61m091T7r ZLs6tFoo/Gh7DbXZq+3V1UQlG6RzIuIN1pcsFku/zKa1timGYuO5xlnG14zvGyXSHuMTihmNYFVU 0gpbhTNkozbKbhzdya7/bM+e5InkLlpwSvjp6R99mXyX5dAvkgZI5gLoZxEk48ZtwkFl8o8Na7Ub tPd7d0g7tD83P5UxZN5jO5gxbDuUYXJKE2z11mtdz7I3rIcdmv3kEOAi1Xjs1sxAJsvk+pgDDczc bjH5gyVBFuT6GNxeq6OK7rAupRPwQql5YBeldJAGlVy/WCIykfOI250SPUKuyjnSbKRGX77niN2b 9z29PQnNHY10n2w/1d49psFcPFw2WLRclakUDoegvhMqyu1OB1EVmlSUu6iDK3NllBeKluQJfeu0 2HXWzkfi/05+dejPyQ9p0f/a8cfRx2+cM3tlV+ucLnFeTmtL3+j1yZNv/XfyBI3RTfQeumz/6eOb tl67ectt66DPW6FNJ3CvZiC9yrlaSdRo82W7X6Kl0i6JSZJOEPOh+npdvoHgHNAksOmwtNTgC8Aa KlATUReg3HwwMsg2DxjL5p1RbG7qMMCaWSdrTqbNHTd5tuqS9m5+MUmk1HAiu1rCxpvwqaQ/oxrX gTEwCZK1BnYR1scJBVDDVrH29HF2dDQgVEj7vkru/zLZ/SXanJH6BLckUzDf5bRbWanxabOkbJdv Zub0rBn5f7R+YNNN8DZ6Lwiv8F4cvj18t/ce33bfUOavfa9mGmXZ5HTJXleBPM4Z817Fbmfb5Wfl V2Tjc9F3rSw7r7zMNt6Up0TOieYpuYV4eLOjq/JO57G8xmyuHqVmS/TcbEqyrdnx7H9li9nZ42kF UZDLLSoj84NKlq02qGRa8fD4okHc8D4raowm/XjAB1CmUhSrFBzjwaEoDkNOWVg7TldoivmN24zM b6QpaJJidkWNvuYojXZg1u4sheZVjAsuctMP3LTZvci9yi24vRWddWnxd18xa+Rk90g7n4JIu5o6 xu3MCCQMYzMKcrI9cszOZyOSXoKJkmzaHRtJJ4ZIXmp4b2Z2tDVvWR5rj8TagYB6CmbMDKaGdkNJ u2nBBCioy+UUHC53MFwQLpBhe8OV0Qmwtzhjci2lMoywk6stsiZU0uWpyBuHDgw2CZn5yU8NVo0w /WftPzu44OG7Xz6/ZVVTK/3RhE/zqtrqz2+osBrYh+c8dG9s097k4B23nZ9V5dU2NiY2LvxJU1Z+ IGtOw+TkG/ZyT0HN5AXl4aq85RD5BmjDvdBlC+5tHx0i9tRXSpmhuirzvExmXyAv0C9wLfDEsr7U yJXiZNPkjMrMBrHJ1JTRkHmv5kGd3miGkSc+fhEvaRx8LjIMBgvRu4NaX1cOzbGOY0LYAkuvGGkX WY/2vNm1aXl318waGa3562xr9ym+K9XUjuAPYiLd7bR9GqzbCnmFfoVrhaczS2qPwa7xjZWvbZsV aztc4MxwuL9Z2Nitb068kEyODl3Yr9ijM65pv+XWi5ffLu0bPXFv8uPkv2D93rsw9ggrerK5a9vT ex5/lO/s8zH2WqwEL/lvZU6bJWaPuVZaOu2drhs813jvZ/cbX7G+4vmD9R3Pcfm49njGcedXcsbE jInOmfaZrkZPzNhp1EyyV7mqPMJV0lWWDdLtlk3enfYdriH7HpfOzDXWkxnl9Fm7I2quMPEcb05U pRZb1LQPd296yMxuMxAFrEQBH6nohZ7uwytrEUUBt4byXBokJSYeMQWbzdTsy9QEHV5fW1qU6t7e PmskcnIkAit5sv0YNHb0ZCQCyrfHbqjemHVUtWpClcSVDhs+t49iWfJv5qXNnTesu6RlhZM6Iidf O578G3WNvPAR+6x8XutdTx185MJVJb96ATdlMPc0fwffUVshu8VjetOrFNtjckwfs6e15QGoxlc6 XVfO+hw2SYgaJzmj3plCvXGms977oE7H9SQhGbjWKGaDxmzBVOjd48ymMDaGcYrFQnxbuO4Etd7s tpqz3kv3qbTGqDs/1xY+NIwMumLqlDv1nfa0tsjtuMmoHBugvaLcDS/x26oiLk7+u65/4d7kv5Mv JG6m3lF7Sf21izfeevGyDY9cGMM1rxbXVN57mfV011PnX/7kz/Y+vg3jrcN4C6ArDpJFfzpErFgn jYbqB3UPme6z7pR26Pfr9psGfVqtg05n58mN+uacnaY98h7fr/WvGt/RHzF+pfnSZMqyZDkVWAin YrZFLc7nnIecgpNrhSWnVqVmNyj7iWK0mO0t5g4zM3vsFAx7vJlRWmEnnDc7EFVp7rg0jRSnqSdL pYoF5rQPIoVLz8giux1iHhANdg8Xd55BQ4K0xJlWopKcRTmrcrbliDmWoFYxWaIQ+Jg1jHCdwlYE k8hdRv62zuFRCh21HiXHggdMsIfbapi4SKx2VN2d7OgcOOy8k2BSKfg4TZxhPQnbyX8qgKAAWzgv d3MSH9Dpp6jJumCt+posdoxb0Ha1ebMCKZl5o2bevFmBsNRXabGSGhjnKyIROEwV3BfohrWgXMUD BeFKruNECKoebQb3EDSym31NPROO70r+7bZO6nhzhNrlUUW4efHUhQXC1QsuqqmhdG7JQ48/e9f7 0IVI8tfJgzdsnk4vvXbdtGl49Un5mYj9VXoT56NBpXyCSIvEgDVgi4nrPZJWfM7DnC4bc9hdNnMG zlXmDIpPyBw6rcVAFxlSBmbgE6GXqc3ioikXdfFkDv/k4gSqljMcel1FrbZZ26IVtIXWEtsiG7MN UlExmTPCzLGI9LmGXcwFme3RGaMur/vqIdaZ9owjMKn8dHS6HY6x9xjxwKi2d8OR7Mbu1d5dXQ7X 0TK2D2VU8B0Hi0PDNxynk3uLQVvI80j1g2uvXh2eNuXcyjfeSH78iBhuuf3WeXkvWavnNL1/eq8w Q137yTlih+pBlNDZypKrsjdkM7vR1FV2u2l9mRigIRYSSmkFqxAUOo1NEy60xByx/AXjFkRiJZdY vrJ9lWGfbKpwTS6sGN9kqnc1FdaPP2EcdevvxJ5tMJoMRUZTgdnldhabjG6X6MnjK+BZdQWoim+2 qUoyYDCmaWFRegGE8tO0LJpeCDpnprrxL8IRY03CbyngxKwv5gI3ODUer1w0zhD2ebjR0Xm9Pt+W MloGEzSIF9MVeUG7t/Ss9TmJ1cDtj3XEOnrszGY1ehI6x39n9n/o8wAWtqrBmBysjGMRarNDt6HE 1TxotNYzW1y3arcsnY7O/IvHrYh0lsBukXa35OK7mrrvV8JGjymwuzJoc5hZKABHIeNb/uw1tE6b Xbjg8qr8DNONw+/csITS515eTzVTuvZvSf7jw9O3dFx858aVy29pLJjozAm6ykI/eviZZ7e8TQ3U 94utp887sO/HNUN3mtktP3/08cee7HsUCng3fNsY7LqLJJSIhfrxygsTaZ1Kp9r+TP9FdRrJJeWx NttKm0Qpy3DY7BmCg1ELF2q2oNHp9Q6nHp+SGfRhrU4J5EV36WhKR3UQMxxAV25etNfT52FdnhMe 9rkHZ3xH2MVNn2IBb5+TnnBSp9ddmzb73VdE+MEflgixU2Mp1f7XWOEwQKZu1b3ScveKHwG4g5DD nFDlqHoYkHmUPr3x4OJHmrOTHwfmnNt4eUXyY7gFH22b3rVxy+hdrGzHwsr6TbePfoZBY/ybMP5F iBrIP4eIkHp/wGSrFXj/bvAWRzW4Q8iQC3Qr5F365/Sv6n6nf0+vnyd0CMyk8ega5Qu0V8rSHt0H 4oh4WvxClmZrZmtXyDeId4gPi49ID8kPaR7S6v2iXY6IEalILtIUaUtMTWKTpIfHp8NbA72k1wmy aJBEmV+ZGAxajV7Q6w3iILtM8Ukl2mq/hmqWm5ghTNcTio/BiddYe92YA8tl5cUp3wOjbYWEICku J/xBBzdocXjU1pzRVSH1akIXjJJI+twIm3kF/FXuY+FVJ/5pbJtwiTGDLkxupbclX09+cYu07/Qp emXy+tEf0fc3JZ9B0+rNCGQlkHnq2UQZZ9PXKlKLxNZLcbyhPCx9Lkl+qUNaJ/UhQ8KQcNUDj5Dy JaLognlRXKCMzbU60+rcqibqCrUvuEiR9n3diLbu4noJm+Mi2xSPJsOdsVC7UiviQ7moNmqt19Zb jlslWVVCm8Zsko0GA5wKRsMuoiohPtJHJf8nJdQbwkYzzEDCZDKe1UUjPQF79F1d5Ov/P9UxLeQz /gguI76lfEFnWiXFWPLjvDnVM9ZEkh9TafOb7Q81+1nOM8snttyaSPrF8CO7p6289TpuXefC03gI IzXBL71fmf4J/Vj7ZcaXTvHX7BOJ2b2SV8di1gUZC1wxz/3sAfkB7f3GQd3b7I/Sn3RvGz+WPpY/ MVl3aH/Hfi+/qH3FKK3VbpJv1Qo2bvz0BjcXkUPUOKo1vo7MLhzbzUHyHUcy7Y6n3SvuinM7peu0 roB31ekRaTuMFG3PiNoxLKIes/PC+d+ySHN7Rh/5O40mf/PZ3ckve2jgvssv37r18svvY7l3ULkn +evP/5588dbUzsd27ux7ZOdOPt7NyUvF+zFeK04gDynnTMyYnsHsUaHaVJ0RzawXZphmZNRn/itT x08jZzzMU5p/ZeLrSfnbJw+XwYC3b2dOHrZxZrMlbLWqLqXh+2ePWSM1mEjrsf84fahWhFtmfvr4 lkdJ2jMwk3zMY8cP7lS6zt4rbKZyxS9/PERZ8vRQ25ZmTLHrzhVLbr596cUbMbUty5J/To4mTyXf bZw/elwYGnj60YEdT2yDQm7AzViVOvadSuH9EtWZ6TxphbRWEkrsbeaV5i67qNdZjH4j22JMGVmt sdnIjIPsKmWcRgP9FpisLyQ6q65U16UTdb519m12tsi+zr7Lftgu2q0kTAW+uxkYPqfuw1HNa6sd ollpdwHewll1PtXunZV2GGBWYWyr8aaTi6IbH3W58VFXJf/QS18+EZMP9U5LIu06yDbaxzV62iX1 HbELzjt38twSMXz/JfWVX5xT91Ty7xhjKfTZijEWsReUYdkmh7QFbps79ID9Acf9BVuLdBpHo4PZ 95uGzL8OfhT6ynQqVx5nmm9abtpquN++I3fIqKkLKXn14Ytzl4U32Dc4bs+9JU9XFW6QGw0zTc2W xuDUXE1uXkG4ylgZrMytDFXmaWS9ZNMFPaYCY25ubkiTl6uMX2282nGN88pxa4s2Om8tesi5tWh3 7u6QaT3d4r7D82DRz4vi42V30KUEQ1GXkoVval30AzhnFdpgS/6WfJaveLKj+T5+7aC4YeVaxtPS 8bRkPB2fEyy1UmsFDaq+iUVXq1KwpG2czgQbF7l6kJvo0/AV1DuGsQ0tgvvYk9jVIiMkbZaVSplS mbpoOHdCsDHYSmPuZbTTfQrvxt1M9AVzWWGGycgKfYtwv9tYaGjxUV9jhgbeHf5xR+NMaO/GF7W5 qd8NwDcKDqZpLr72HcjJ4+mjA/68qJr28ksWfAWcicglJjohtzH3AdO9uS/lvpUrB3ONJlH08XFw 74tUcD9swF1cC6q66mo6Nz/KqZLtw/kDHx8p+PxI7KDr6QmKzz2sSHXg2MiRGS5wUqrMwq3hIvEE Lv8wBJeCql0VbgX1uhX4/26lsirq5ndIbiV/HB6o1+L2q9c1onu+T4ELYfHRFl/Kx8YG380vZtTf MZx727tP8usbnuanB3f12JFD3elwB9ONXzs/UvALm98oOoO91lKIR3Aw9dkeU7XRYazm0YSxGhL6 tN9QrR4y8JlfDFcTGfn8IIFLmShubqB08KJxhHarV4/8zgb+Kv8SAJ5buJT67Jcvvawq3+GckXzm whvf++i9twqTX9oWta0qDWSF6fOxtpOfvztKSyJz5xdmlQScDlvTlAUP9hy4c3PZlKl+VyjHmbVi ZtPtd78Rxyrypz5hd0mPYk94TRkXIHCy9eMsk8wzzTGLxuskHsHlJG57hoO67cxBPYJOo9cY4dpS xULcfe64W+gAGcaNFw4TCRzzsREMECd/C4NTuNGgK9GXEFJCF8FK8ONGoUcIu+3znbWObY5dDqHD sd7R6zjsOOGQiMPqCDhKHSIuIK7uO3N31hSvgp2YDDsxRByp4Ymx9FkEF9rWk+pZBJc7sLg4/x2D I2yrGDuLtFMcPByqTN1caLgQq7SFKisq823s2mFDQVbBTM+S68+/ttqgu+km6hPDR5OtN0eyMt8r qpjTULaVHjr65s+SmyAfA/yDhfjiyEAzFadU6CuJavhD5g8tf8CJOzIAKnJlDfgmRR8SqSwYtFq9 0QCfk9kFn86nzyXFhl8bcHGfOqG4cNLWE8ngIF4DPrQzRMkkwwaiSy/V3XpqMqp1GXTuKD541FEZ rxdqa2swPO71V1dnKnYD0Yv4GkTHGJUR11Xzux/Fk1UYNZj86m2waHK7fVZ9rb4Zjt4gK1UMIqs2 4FqqWRTEfawUjst6xWLE/y0JYGkJ1Gt8CTL38jdOEc+skXY4JO3e2Q3L6/+qplUHivt+9mqKLnDn rjsCQ44vbvkvSIMZbn7RmAEnb2+ylRa8Osktm62/pcEkpDf64bMNruJilvPv97gvjHeXOOdxmT6g bC7UvCqyBzRD9E/0bc0Jk6TV+ESPXChXkYna6bgmv56u1ejDNKKZQCdpGulMzQOGr+SvNLp8Mawp 0kfFSfpp4mz9i6L2fH2rGNMvEy/TX01v0N8r3qfZp39b/JP+tN4kiBq4wS689inSV4i1+kZR58Tb n0n62fpL9DvEveJv9KdEnQaTM2D38Jk8MuCE8LkBcxptUSriPSJev3CiJTqtgDk/umdccTQlYB8E k8WVFxXCTOdgTCfJBsNY8QlczvNiN4oNYSI58K5SliTsrlqdzkBwfLwsIVfouA9u0C5vNm0zHcUt vsCzWQWO85cpdn52hweTfim4/Js56sYcnRzxzsJdihojJWmXHDPEX+hEuiMbbnhpwzn4Lwxq7Mxp 0V2d1rJn9QE46XyAaWed2zBujtq7u6+Aa9Z9RQV89Qw+mUFBMNJ1ybvoBQdeoTOTD9BNyR1H3mMh JiT/RPOSutHX6YzkXoIf4w98UVVA/pCOfe+ZibSAsdjU98BuWJxCUk8a8DXnefhCbAb+G0gTvsRq JnPIXHzVOh9fu16A99kXAkXx9hhiwI9/UUuaZ8+ZOntqpO6KzsWXFk9ddemyWa0o+t9Rb1QZCmVu ZHN0cmVhbQplbmRvYmoKMTggMCBvYmoKMTE3MTcKZW5kb2JqCjkgMCBvYmoKPDwgL1R5cGUgL0Zv bnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvUU1KQkdJK0NvdXJpZXIgL0ZvbnREZXNj cmlwdG9yCjE5IDAgUiAvRW5jb2RpbmcgL01hY1JvbWFuRW5jb2RpbmcgL0ZpcnN0Q2hhciAzMiAv TGFzdENoYXIgMTIyIC9XaWR0aHMgWyA2MDAKMCAwIDAgMCAwIDAgMCA2MDAgNjAwIDAgMCA2MDAg NjAwIDYwMCA2MDAgMCA2MDAgNjAwIDYwMCA2MDAgMCA2MDAgMCAwIDAgNjAwCjYwMCAwIDAgMCAw IDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgMCAwIDAgMCA2MDAgNjAwIDYw MCAwIDYwMAo2MDAgNjAwIDYwMCAwIDYwMCAwIDAgMCAwIDAgMCAwIDAgMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCAwCjYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDAgNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgXSA+PgplbmRvYmoKMTkgMCBvYmoKPDwgL1R5 cGUgL0ZvbnREZXNjcmlwdG9yIC9Gb250TmFtZSAvUU1KQkdJK0NvdXJpZXIgL0ZsYWdzIDMyIC9G b250QkJveCBbLTY1NSAtNDA5IDc2NCAxMDg5XQovSXRhbGljQW5nbGUgMCAvQXNjZW50IDc1NCAv RGVzY2VudCAtMjQ2IC9DYXBIZWlnaHQgNTk1IC9TdGVtViA3NiAvWEhlaWdodAo0NjIgL1N0ZW1I IDY3IC9NYXhXaWR0aCA4MjMgL0ZvbnRGaWxlMiAyMCAwIFIgPj4KZW5kb2JqCjIwIDAgb2JqCjw8 IC9MZW5ndGggMjEgMCBSIC9MZW5ndGgxIDIwNzUyIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0 cmVhbQp4AdV8iWNU1b3/Offe2bLNPpPJ7OudLZkl+wIkEBYJICKyiFGWgCKioIBi6kMrqIARF0RA XKpAhVpFtjaoqDVofZWqP1AfrVZsU5c2pj6lYjGZ/D7nzARDXt8f8DJ8z37PPee7n+Wy4saVC0kh uZ2IZOrl85YtIvxv0rOESG0Lls5bls1rv0f8+wWrVniy+XzkhfsXLbt6aTZfdA/ijquvW517Xt9A SN1L1yyc15atJ32Iq65BQTZPKxAHrlm64pZsXluM+PR1NyzI1et+i/yNS+fdkns/+Qh5z/Xzli7M tp90L8svu+GmFdl8Cxvf5mU3Lsy1p7MIyXuMUJTW0AeIhtxKFEQgOtJI9ISovsj7GeZLeT3afOn8 KnOVtuGfVK/m3T19+7++Zom3XrB8dO71vheVLvWvkFXy9qwCzyjVGTRWbjn3+rnfKF3na1gt+6tp GhBup03ESETaSAoQjiQZhCN4WEdGIl1LXkRYw0uqebqKtKKkkmxBWMHLy3l5mrShJMlLSnkYpwHE ChrluQhZgvowqUQo83SIvzPIa1lLkfp5rx7qJj485+FlLC1SF2/rpA5yKWqcvB1Li9ROJiEs4Wkb f6KYWhEreChSC3mN50y8zsjfbyDj8Yye6sg5tNPzGpYWqZanC3iYz8M8qiFOtGKhSNXkW5KHnBp0 EqmK/D/0pEDcjJySt1fwUMq1k3hO5KHAMUpJGdoSNgMygPIiUJ3FrE0/uIA9X4QcS4vgSbQmP/D6 c+Rf5DbUn+M5lhbJ98SA8Cz5jmxGzVlec5a8SiSU/JPMQxmrERHejrJ/kjPoT8FrRPLPpgHwmoQy PideJ/K0SL4mZjz1D95fL/mK5OOpXp5jaZH0kM+IFWU9vOzv5G+8xd95jqVF8iVxIfyC7Eb4OalF +Bn5K1HjGfakyNMi6SbPM3wiZhj4Cw//zDiMfMrTp1Evkk94+k88/CMP/0BMKD9F/otj5BQvY2mR fMhrPuAl75ODpAm9v89zJ3l4IkszcoJTgNFPJO/xmnd5+A4pQcnveS/HefptXv478p+M1uR3PMfS InmL/BbtFIjZ6FlaJG+SN3gZC0VyjHE66WISQl4nv+E1r5Mgyw0wKv0mN39WI3JOFclR8jK5F70e 5b0e5dR8mbxEZqOM1YgIGTVfQq8hlLEaESGjJSsRyZHcvI+QNHKdHC+/5r39ioeH+bwOgf5Z/Bzi pYcG3kUPrEQkB8h+PoYDvOYAH8N+8gIfA6sRUc/G8ALZx8fAakTk2Bj25ebEakSeFulYEgbXN7OQ PMdp+kve87M8/AUP94I7RPIMT/+ch7t5uJM8zeSUhyJ5iskp+RlpQfgkeYLpA8QMvywtksf5M4+R HZwzWCiS7WQbShU8FMlW3uJhXrMZGrMONZt5fw8xLUMe5PUPkPs5T7NQJJuY7JL7SAeJoPV9XCpZ WgQuGO038nADD9eTe9BaQdbzN7C0SO7mNXdxzl7HeWItuRNlCh6K5Ke8/g6MRQReofHIGvIfZBzq 15C9yLG0SFbz52/h/d7Mn1hFVvLxr+I5lhbJcp6+nodLyXVEi16WknLUsLSIt7MRX0syoL9IFpNr oMsUiJmksbRIribVCBeRy7lsLmLajSzkb20j03nrNk6FBWQ+MKYgC3iPLC1C58yFrVYgLkWOpUVy JcbN5ISFIpmT63cOf4q9QwT3sDHNyvU+i2N2JnFzfTiT183g778s1+IyXsbGIoLq7NlppIrTaxrP XcJ7mMrTUzi3T+bPT+JhC6nBExN57UXMbpEJPD2e64RxXGeN5SVjuBYbnet7NLkFbZt4342gK9Nc jfz5UbncKN4DqxHJCB428H7qeVjHw1oe1gDHxXi+hmOyOvcGVibytEgqeF/lvHWahykeJvkTCRJH yzJewu0t8gwPMR5GeZsIUaEknOPxMJ+7zGUlxFo1bYEmYnYogLcy+gQ4r/p5Dz4eennILTGnhgh8 SLyti3OFE1gUiSNX5uCt7cB3GL3ZeY6lRWLLvcHGy9jbRFgBNl4LD7l1hidi4BaChSK8IB0wreCh CM4tgqVXIGbyz9IieCsrvYW8jwLQn0kUC0XgXoO+FTwU0R8rU+XaqzgO2LMiWmTno+AagKVF/Fhr yvmGcAtLafG6Dhr7P/xH/m+N3cldVOjqI9AWvyXHkdpN8gS7MIG0g48PIr+DPEuOCXl0C3mfjqK/ Jg/R9fQ12kbX89bH0YFJTIB7CuhrklrowRPPoWw9dPFx+hfpFPkjeLeD/FHcTlaLo1CzmjxHLxdH w89bLpl4fifavE+IVCvWky00j75ET9E/0o1kN32T4u3iLPIN+lsv7hAPY5TrJRv5RiwXBbxpC97x DO8D/aJ8qyjQp+jHtJccJla6iD5HC8gzwla882Z6Djp8C1lPS8kD5AE6CjpzvvQkyu6APmS/r/GW raSD/g7z7gC8Jk5C++cw2+PUjnEcJwfpctImqukd8Bcz9JxYJFpZX7CFd+P3ENkq3EnH0QcEJzwp hoEOhET6Tnoq+0PGDbz14p0dxCv1sp+iiKwU7BgJ2qC0Q2lSzqBvCqX01/RNYLpNsAoddCl8GkJs tI09Jeah3QPCFHEN6RDfE2zwSDowhztou/SUsFNYhFwBZrKJbhUux1NbhHro7HalScoD/vgPpR1s psIExXHFCIUTc94i7qCbxB3kKFUSG+J28ri4RbkOOLuZ7gX2bmP4J8uBtTbpSYz0BvyWA9rR1yzY uK9h0W4Q1bBAx9loMWorMJXHMIU+lgNTXtKuWA5f6ybhPXITDx8CtlbD7n6C0eBvzQDGtBUWOtmo UiokEJLEPbp9QvCitn2Nl8zy/Ha2tzQ+LOvRqTz7yNR9has9vx4YmDpLsitm71M49olB9T4p6P/0 f6v8tDTeMnWW59d0zNjmXLdj5zaj8NJZeAP+sWK8bmxzKUYmHSeLAIjpDsB2wFLkWfwU4s8RS4hZ +jBgP+B4to61G8ggPx0wBTAfMBpwBaA5lz+K2AuYCJgFqAdsArA2IwAC4G4Aaz8XwNqw8bwEWAdo A+wGXAM4knsfS18OYO9iY2VjYs9NAETQpgfxNEAt4E1MMbv+JeAcJXxQQjzwHrB4uuBPgK5mfxJ0 uRI6nkDba6D/85EqYBX4K4TF+PFPC62gh143QtubYSWs56uKYalKkLPDpjlh6yAZ5+t+THiIFz6a H/YyCB9XhoUjsFRR2N44vJ4y5BIkSVLwvsthxSthz6tzD/vwXBs85K+pgzbQ6+lvhGlCt3iX+I0U ln6qMCm2Kl3KDSqP6jn1FHW3Jq05mleQtyo/lP9FwTUFfyu8q8hQ1KVt1n6nu1/v0J82PGjMM35k qjBHzX+yxC2fWduKry3O2LaU+Eq67X2Op5xX4q0CWZTZIi1S7ASWVMTaqJGIkqoVgkQSb3/0doro Tr598u2kUe/VB7167yKJ9N0k2vv+mtmiKvr+mxuVETZwSndkbhBT0jHgxNuoFzXaN+0HXAXEeL+S KvVml+5kT2t3Gn31ddfWJqlJqVIKZpPF6qJmk9LvC8khobLCUD2SlqctYmqMvrk2mbLNNOrck9JL rp05u25+SGeUtpo3Rp7IfH/fnf+8dfQBs8XWNGEbndq5h5bff9VcGxvD9vNjKG/0aUT7m9oDLpvG JtqMNmtEExEjxohV/QQfkbGAYFANZ3paU62Do6qoqq4yVFaE5DJaWVGFkVgtBrNJUBVRjJBubzaM qUulS2aYdN4WjGr27JGtIZ0p87hpfeRJqum4/exPRh+wmGxN47dmnuvck3n7/vlXMEbBuJZmjoql dBI8nNLGkmKDPl8qyiO2IvG4jWXyJHgfKpvZBiRZaxmO3jbU1uqtwNNIWk/TFqBIRfkgEhRDa6DV 9Gt1ifuPWoMkZb5SFReJKvU4nU6gVp+xQKPQqfq7tAZBLFEZCvI1CkjDdkhzuZCAZ+RtRJkkSqr3 yLs6rVpFpHxRpzvZxd97phvvNPpCIyhm701bnKCT/5jJajWJI6wlLiNdarNca7RYjNcamPGl9KmB b8QYnQE5MjVqxJOaEwVKOynANDCJMz3JIEdilsD0qaUzZ1+3dNas63ZOaZs/der8+RjX5wObJEmx FVLmatSJhaZFZJFRMOZpiKRTmrKjAnFOdiUVfPYgSjVQAsJwjKyzyHZHVKkQltlCdldUobCnAxGn 2lygaKoIhh1qk4aNUSJEPKdQQx6bGgNeHTpXiIVH3fqu4jxPscGsIzaNW/IozTqnR6l1UIdPd7K1 62Rfl95grdWDDgZQJNGT7gOKklkisGEEs8PQZ8fi9/pCKK3HhtHNhYUKt+zz0Ei+Od9oeXJ2Mhzu 3xsOJ2fvllKC4HcWBzRTRdHv+uENZziAv7BTfA/jxKqViH+BTS0n6xoXBJSwbYWda0zU5IwEu5xH icvWXnCrol19l2+99IT6UcV2abt9i/sx207tTsNe5V7VXvVexV7pl7ZdwU71oeCLqheVL9pfkl5S OBLx8mRIJMqAQu0LqjxiniruCVrFCqD11ZNdPWyamGgtpCDR09ele6O1l826NsmnNIpWVRNIhN8H gVUxQWWTz5GAKrXUO0gOM5MSmldZ/qrTWU0vv3XeqJv8ysJgWcBVZGx8ecHuTzLPzixrp29Jstcb EtSiqzhW2nTA4aig4x5esq4irjaOiY8MeI0jL/pgR1fmxUvKVsVK4yFRK052+xmvkcMDn4jfAz8p 8kjjCuI0+zuTIRqKOzvN2s4C5fvxo+a0VGoqnRaYVjRHtyCwoGixbllgWVG7qd3VrtsMt2lzanPg wbLNigeKdpXtTO2kTxbtKnwysK/oADmY2k8Plu0LvKL2monNo0oYVMtEKs6NLIsIEZ3NYxNsGlda d6artav1ZGvPyR59LcOXrqvnTFePrjeHsyQdVGbAEfiiPF3FdAl+lRXVDGlZPGZxmOUbUVh5x/fH tn4Vc+vfv+Lmh6++3B6fPs1jnjJ31ZzpL1gcwdP37HhngbDPs+fW5z9ZOc4lL7rnutnteoWoaKrP E6WCayZedcs1AfuI1S9vWHwP0+P7wUO9igKkasi2xgUb6BEqUI/TUWI2qYLFca0uJuUHvaQrkZ/S dBUfFcPmGvMMYZGwSrhL2CzsFg4Jmli4Jp3wSXGPYCoQtUqnw6MRzaKSkEpaGQ8r3XnEqQ3TsDvp WaOl2loIy8mG7ta+hm7dG+lWxkxMdXHRGeSq3t70yYZMwxu5wmQr1WtoTl4qwWXQNkAPl2urxc2Q CKliCISQayFxMWrOSZlwJLOOapM+v7wiU2pzOBUi3V1k0Cq1krSoSF9uKdaaHIKoVtmd0/2NkDt6 XNjdf3mm3B0JeJ/xuMaG47Bqb9uKBEp1gt3Sr/a7LBqtOhIoecYdCgSYrhbIcfBZH/gsH7Z7XuNY j91XYNac0mKyH4qdZl+n/aj5/aDkN/mnW6YLS9RLpDahzdKubpdWCCssa0vWmtbqdvt1SpXLZyCe ApXBW+wI6s5093XrunsZ03T3gWW+a+01MO0CS5jjE0iYPChLfp+g1xEoYJCNGUq66aeL5ravaZu3 xlK1dsrjH3/w82Nf0Supe97IVVMSjx+j69offXDVrVsf3DpuXO9zh/9Ga6mCTqePOeRGgWpcmQE2 r6yuhuedD1/G06jTnBS1J80nxG+LDUp7ASmGLexh9rnnDIaXZAaAEwDcqh+S/lGLD2pz4XhOnWfk Qb0uwN69Jsp4VzFw2NQYHLR4waJ3RN9Jx7ficRSZs4ZPaTMHVG67Lag72Xeyh/EIZAvDAJY+y1lB 6Np/YwWhh4xDR/alptj5TqEeFjGjNhapNeJo0EyMYZzXXz971nVnvIYCjQjT+LmuCEt1pSFfyssX D09pW3DxxQvmE2EgA/fwQ+kpcECSbG5MtwhzBCEsduaRTvdf8roTXqeo7QpbkmJ+kZZQweX2eAvi JaU6IzWWBUtV8XhKd7K7+0xrN6YAg9HQY01nUQnHvMkG/DejX+wYIHYDXAAt37FgNfBOEXoAXgBr l1QpdD09PboeFYvUPbNJK/XC1nK5YbbZmjOD502P7FXlSMY1N4wR3Uq3fbjpwRGp2FzqrJZ19G59 VThUkfl6UizR1DovI82YNzoZuyjzr8ZotMEoEMHglSNup9yXcCF2R0Lu3l53iKVk5uZiVNOBo5uA IzV84zRZ1XhxRPO56jO7rtPXbSNdBikiBU0RUzAQnB1ZrFgcWSyuFlcrVkfuim0Qixw+m1Fyl6Tj hkhIl0dVfoOSFBaG3JaQVBi3aIi2JFGu6+tJd53s6dJ16Xrh/3ARYcqEGafedIb9q00Gs4o1RisH E8bBGetzypWLDkSQOZfcLj3wp5e2P9T5xXv3rf/Jiu/fyjT6/fFLvd7J8YCPnjj5p+Yx1y2+fFrq lus7rrr+hivbL79y9lU/9HLLvM4d8Qd3PXbxqpB873VztiQdcDNhi6YM/EWaJr0GSt3SOEsdV5cK c/RL9O36jfot9kf1Tyd32w8kXzQfCXxf+n28cIXjoEMgRk2BaDvmDhd8aewSvyg7ED6UgntpDllD 5hXFK0wbIztLD5ZqdBYlSfk0lsJYMgUPCvY5a5qhNZgGeYPZZkNta7J1+aAfZKlk/jOsTBmcVLjU BiBl0EDzufsIdAk4Q3wqL+ALuiRPZLRJJRnvn/fCB6f2191SZ7/S5I4lGqfvvfJs5igdd3b0eukO uyVQM39PfsJ7pUPbclWm/w9/yPR7vUVjIi5Xdbi6grZSHS2kbR6mL+cP9EkrwRMFWNnMbqzTWAs6 XWJX1Ey6XN2FdrVdiqljUr26XvqFb4/8ovpFKU/rKjZLFoOXKAsD5XZDhaeQaC3pUkb8dHf6TA8j e5bmPT3pkz26TMOxZNAFfmf2lHki+pwcwN/KErxeTBN9ltRw1G/2jHJ999fP+hMp8+OlwWCswaBr KA3Kscc//hcNX3ZJy4d7TFd1iOJHX/WeEkRGaNklrvOEg/7MK5l/rOueMWW8BBqPBq/XYl4jyL2N U8NliZg34DbrNOW1VXUqEuh1fx7rJQn6dYImepyaTtvfdd0pVVfV38gIg8Osy1NRSS2VeVJy2pEy E5l+LVM56dLWmisLJXVipK6vC1Pta+hqXa7rTeNf1mQy1ZeAvcwwaF3enekGvaEQGdX1LKxNludm fH7qdNBRZ5YU67Os88Fd9/9ZciQRCMYmNza2lAZDpWKdz88kvb+HKp0Bv90RCNgz5wQTk/yAd5D/ g/6I3FMRjk/elHm+sipaOvFISzQ51p8Z+9TkeKS2LxACrq4Arq4Armrgu7ZUJqrS4VDMUayP9YY+ T/eSKvp1Fa3qCeg7PX8v7i4iXSoVkYM2v6PYUKSWdPlw0SvlVJk/5ZBIGf26jJZVB7UOc76uVvdR V7qLYwkKgWOJswZDCnDBcHUhqgaRBBXBvIdB3SgM1QvgE6Dw36NKuFKOhgK+jNEXkBPeUaMmxQI+ caXP7/dFXf2fUrUj4HHafQFH5vsOb8AfDPqDHpGriIicyUCnMByVXJQORTPpUPoiZ2YscNM88Kn0 kPQ6dpK3NF4zMTknOceyxLIkeVuy3bIp+UTyicTTnhctRyoOVh3waL3psBwLGIr1RF+jpZ2j1FT9 j5qu4tiX6a7AF64DxYfqLRWWqlBFqGpF+YrqnU6VVqMrUAul3oRCIacUEaIt0FUW2pP1XHf0dXN7 yjDF/Q6mQXozrWA2zlEMhfBAWoOVF2jNGNXntKYnpzms3C/JctSFikbc+b3LWRKk+0ps3mhhgaH2 D8syZzKH6Zhzzesn5vkdCbcvWmFVK4IbZh/4oKerdvWzvR5vyOH1Bh2ZvxfbzXm+JJ1BYULpIre7 xFqz8J6U3GjMu3hGpv+jv2TOwOpQnB8R6Vrw1jiyunGCr3PsZ+UBj6jvjBV3j6nU4uC0QVVe2lAl VSTHjIgFpbBfqyk2SLoCTwlEUCKN4Zpmv7Y2WVHhlGq8RFthLqjQpcdjGyL9NpzWtK47nUF03mNl DkjOgvdaUcWCXmZyGD/FhMFlXk4IhWwxxdbI8JLcE1mDDUXlpTePqU9Gx/9xqEZ6b2qsqqWUftJc myqd9WZpIBitKtY1xKOT3rkkXnFRKuPt8AQj7h8VlDsS9mR20it8sMoo9fa1D9pn+iTD1VHgqgi4 8pHqRrdH12ll0qYsUlv1kjbfU6IkklOs9WpN+bVav+4jKKDu9Pn5Yonbk04Gc4KTm84QLTM4Ib24 ZXIsNrn/Z4lAKD75z39uKQuFSoWroFhKW/7c4QyzkWFNC7EI+gOBiLuPbbRibN6Br6X1GFs9bGZN yFvpXeRdXC+F6yq89R6FQ532GTqjjm4d6apW13nqvZYxhfJor5yoKFeMrpfLCyscek1Tg66voaG7 i/nSGQDjYJLoghJo6E1zGibhbb3Cnag6Us9cKvy8cKF0PbNTpDWYcyOH07E8CW+JuVTnDct5wnJl IVM6o3xiVVnsonMJTKneaJteX14bNl1ZFrTR7+XxVanomH8kA/5YbYE9lbLa+3tydGN4gGHxCuZY 33bR4ufEDHv69E5Lfpn4MPAikInQD3dCPzC/fERjvKBLNHRpDoiHigPGgDWmjxXWF1YYK6z1+o3q jdLavLVCgbaQNJsLlcliSPmZnvNriiTVEX/O2hOaxkaWAGMJj0C6M/PuV3/PvEPLer+iyf6/PPPa a8/seeU1YVqmN/MzOhebFibamnmyv4DSP/+Z0oHuP/MlA8aG+0dcr6uxf3ll4wjaSbDkLoZH3G3R dGlDvlBgjmqOuES1RGxXtYtqt82ik6xGrUYthDxKHPsW+gtkovWPdRitEabLu6HL4dkNCtmgV/dB K1YcbNHH7LvxAtU9yIDM5WUSiMEeffGxHY/tsKTi0fqM1Qc1fMe4WdDT9J1v+87983nJkEmuWHnT ir52byDsCUJ1ZzX0S7/61ZHMO5hTPea0H3yoJo3k540z2QSuaGBTWFS2qkxV2kDDDWWjNDHMdZRu lDCqhHR6uxNWTVeVripZHrZb9V7JZipriKmFUbUJdZjq8nyjpEJSrigMF9bAjQ27TLZEEzPwsFxQ uHwjyQBvdtDEY3EAboUzi2lzO5Zl2lqwa4I0ICzDL6Eq0vVgCcDYFu7WIHLErBT+O8OW3UqFz2s1 DooqcwvFMiyg6d3v3NuxYf37zXXJaF1mny8QLvPW1bXE/X66e9sjFWMmd/xHScT4lrcm6vctTyWU 4qv1k0etk+yZ6xa2LVzUd6MnyFAJY3efQ/b5nP7SzZfdtMujDTsyb7tD/uAEpUT9s9llOMj5poET Ujn2gceQ1xvvj9SNr19vu6v+ofptts26HanHYe92+X4xZndt55hD9UdsB336aNhXGiTKPLG+2FYn NblLv6zI/9IAH7mpoiv4hftA06Fmy6hJ6SvSC3VtrrbKttolxiXWFa4VlStq263txpW6dbqNxrUN a11rK01LUu2pjSlRSxx1xbZ6X0pZHY6YlQ5VxDxuZPU4laMZTIjtG5CEIZ6xYW0t3/+FaewZ1CmM UtxAwttqDea2XblXZWX71Vk25RuxfPmZtY7u7D52zjxC6rI7GVx90NGKgByNiIVwRUsK8v2PLL7j Zwuu2vzO0f6Xq2+dLDh8cZ9UFA5UOouKvD+5ePUjy1c8+dy+c+9NuM9f6k9Vf2FIhmfELOMm3XrV xXOLTM4nH9j2rtPttJSk3svzyxOj5nTVLfMmzdKZrD+/75nf+TgNmD+2HDyeIjc0jnLYSSpPX2g3 GzRKonQUi0lHZ2F3qasrJJcmop6Q019k0It2c2GeBvs89pR5gn+8k6SUE5za6PhEGstatpDtPnNe bgfRk/O/0m+k+VqtNqkqUhmzG7XJqkojvAYIrdVoyi5RwIpefU4B/8i/3q8Fd6nfL+QJgZC4MBSg +UIoFHYJeZlPt3NfrP8d7ottz3wqFrVEggG3jk4MwoHIHDZ4aMAfaaESE/VBZyzLgyMGPpE6MP80 ua1xcrO52TbdPN3WZm6zrTCtMN9o05To42mJWLsSUTtciE6fqjtxqDwaC8h+f8zncJcwtwruA3HX lMhyRaygRqeNSRVq0oQV6nn7M4gGFnN+wiYq295hS3++fE22God7BfzEg3HQ//AXOKdUHsZKBeb0 ODP/MXOx/7ZJm+6snFIZHf1xMhCM1xWd+sOxv0sGtlZhrkD/RzcsjI5ofvZVodod4XbX03/g22+/ /T2TQwE8cAw4qCMbG9Ov+Oj4kpklgs9Hw7WxYjGvM63vlkJOT1WiSLCVRGNUXUd8mrz8hLloorlq YqIeZD8JA2uFfEBhvcE9IaaomkxEAx2lgf4sIXlI2bLnYUixt0ZJHVIx/KJsB0OnxgaGgkVsA6MV ALbgttbOzlSYVA0qdpHt9OEgKJ9v+SEhDmtA257VWF2lTpvm9fmPlcUiNXSMxRcKFdwn6o3jrcWa U6+qLLYWE46JCmTZY6XN1ZFYaQcQMcOjN9j7d4t2jz/kkp0+b1+x22SwCfv6p9h0Rp/4mc/rCrlC fg9mIJC7Bz6X7hYPYj1bSe5snHmrYqMCu+3mh1W/UOxU7Qz+IrzXfCjvRfcRfWGJ01ZZmNKQgqgt Ip4+baGWPs05ned75+nQWd2J6A+pmL7OcMQgpmJllelC3MRx24gcmaoM+41VTBGd6Umz3SKwD9vf 6Onuy/nnUD5Z/QPOwm4pW9gzhcLYxpoVr6ziGb6fnDuM4FgUm6uvLt++/4YZa06pp7226OFffftR 3aqR16+Y8qrbGfr42X0HU+OxQfqYI6CkRwz6a2Y1z1o34Z2JU3ave/w5rU510/XTE8H6aQeez9S7 5EDA5wFemgd6pTtxKpGPXY9TTZdBvxfiXlUhblhYcO+uEGf5FtwJZPdtktgJCAJ/WqTZrR4H8Hoa p6hBHMvGUXYaNWeRP4HcAM5If0CLFpzMtoB/5iBm57e7sMO0C+dChxAfQqzGKWoEbZ14RoRT58Ap agBcyPpnd8rCOKsFJXDSaiCXoeWlaDMNLS4hKfj63d042egdxCpT+3xHqbc7g1XlYAXHdjDrhHCE i2zdQ8wmeFUhmTsfw9x/+IxmYUfHvgMbNr7wwi9rnrn2LVqQ+eqNxTvSRsuv5FBZs9nYjBXdVpd9 4/77Nh48cO+9B4U7xk3M/Pdvj2V6J7ZMtRczV1kiHhwEmcyY9VzwXil4L07aG69Y59ik3eZ/Qvto 0TbDzviL2iP+g/E8db6KElEvXZx/Vf4N+W2OFY41+U/kP5+/07HPleeyngvk609L0bOBE6XNhmbL dMN0y57QnvCR0JGwushEUl7VdFNYnsH2WnB0wdEAjdWFHbdMF9+91zOOu2ALgW8s5fgP+/TZfWEJ jmZlBd9WeigElz8UssuO5PrZO15/8aExq6uMnqagW868/8ypzCfU81+TtolzJa872XIkGHSnLrn0 1w8+/HIwWGCrlN0X76KWd9+lVnaIDH8T898OHguAhz5smgEe04KSWvCYAncc1eAzLfhMgRs/avCa FqED9NfjrL4MnCfifJ+AE07jFFsPXitG6WmUn0X+BHID4J4f0IL5Wc3glOmIpyPeC57eC+45gvgI 12xsly+GUbhwasjeYEDPrHcz2sXwNhnlM1FzGfg8jHsEMxiX9WCTvwsnqFl7kJVpCDU7IMqxHucw 7FWO4OeIOPBmCLQOmgLGTTkR9g89FhAfMusbDi5+eYDqfnf1zvrKmeUR+bjLXpqKhzx9+/av37D/ hY0dz5ld01oupYW/fYcaLxpP1+DIAyz1wzZvABtir23Y96uOjQcPcxwvAo4vx20kB6Tp5aYpuMOp IKsAuzlYyB7Mbw9ocRh5djeQSasXoRnY6yS3Q34pYBP6Os37w5Y26s6i1QlgrBlPTgfsxmpmD+R2 D6izB08cQv4I8keQP4J8Hr8/wb6XcAK7DmDdBUxqgOtZKGHSPIMEBrkUeMM/vtDp6cMZHEcp+JQ5 Y4Gss8vP6LMsCYnFOiHo5XqTmtQHHl2JU1RXOFrW9v5iSDz1fXmCWhLXaPsXChu1e9rXHaZP3f/Y bSGHM2lNVVDVqY+pYYAcrgndefMD7AMNjPYl2NJ6hRv+1KamclCf3Ya0Q995kTqNFDtZ78SotSij xEIFlA2A8wj4TYkyHdI4agcO8pBnN0ESyLF9fit6kxG7IPMySmTgKA83UdJsudTXdbJr6HqJ7Xdh AwfLB4grMALzMLheH66ZsiIMTEB3wXw42S4hy3n14vZILCL338jCvTsjpdHw47//bNmSsoBhfWr5 fDo/EouHMrs3BbB4DyAQFoSQaj70dLrSHS6+6vpamAO5/zGGF4GsyyyX1omPQ26qyVdN8yCvUdy6 9EBmo9gT9OA2sQc3pqLkJ4ifBTyN9EuIj4D3DiDN9oxjuPuSwB0a/v0G8QE/VZTdjmEYPg0+YHzG 7qeeRp2BMk1/FvuuEvYam4HrZnDpdMTTEW8A5+yFndgLqhxBfASxBr0ncaaewLs0eJcLGC7H2zYh /zxAAEwH/mXwcJDU4FC850wrW6bqc3YZxy/d2IPuBcYhxnzlytYF9LxJrgix2yxD7DLsdFbAuXsD AQctBjceqDDxzt277/zpz39Okw5fzX+uv3Fxud++zLn5JyM2z33xn31HJj/UYnc+Eg6nxxpE9VN3 rHn66TVrdvaX3rsyPnFyPOlOaO/ZtXr86H+98mp/bd0Es8nvD3sw+zbwZzv0Zi15q2kCeE0GxxVA OzJ/LACOYvMDHwOvaqTOofYsUgPAh4/fZmV8mga+Hcj7gR0z0sV4Lo5Shrla4Izdt60CDhnOFOjN DfvqB5WLoQmNaDWT01NG3aXIz0HbaWg1m9TB/kINYimc3c7OrrtyKywwMZxmLIitYGymJ7MIRnGy +gK9yEzxj+rx/HkPPw84rzWzxeW9xmaoyK1210WbJj/yy0Q6Hg5nvkt4I7X+axde/ai/IepNZL6T 5URzR9b0WoyZ+uaml3Zn6rHpHYBj7aRPrmzfsCgzl+2OMxPNeH03cDxVMRe8LpNbm6II/cAX+6ZH QxXEAdz6wZUlwM8PmL8JKQ+kOwBM4hYUaKIDDzP/xQOsXIl0I0oop5OMdh60C0Pmu/pwxYDdL2CY AeQQxDbnzuCuBg6Mh5x5GgeFOudJ5zDGXWohT24cGQ42NcqdtEkO+hN934fD0ShNvR6J4WQ8aHdL L11Xk5g1IxLqK/Rinw7C7hPuwIaJ32JkOu8azHcreKqBfNc0DlSNk7GAcfC7RoNvpiM9DfF21G/H ngrbIWL3uD3gBxNm24B6G+oJngyjt3zou0KK+7YkjNADTJnAf/XoLR/4qkAte6IET5SiFIdgeJL5 ATVIqcFLzCLLsB0FZARzndPdJ6EbGbewo9Z0mh0Xg3nYpaks0thKxULi+KqEaZhSxPX4NZAYKwE0 8BpckUTMVzDYJFTjpJUtWrBYSabYpguzI8MVK+PCYPZ+GMc+DuiLqJZy9mT6lbevpnSft6RTDicm JyMz0hH5FbuLer3ueJRqQ+F5xvzI/PQDtH1GLIiDg/+Oh2U58yFdkzkVTmYdQma9Lcb+8m+KfFaX y+dryBMERWV8TaaNbcO4vHa5AKssCg1HJHYL1k5mN7mBSRTBzgyc58Is36lRo0IV40kJPwKuY1w8 FXxHAazEAc3X1Zq99QQ0cqlkTAeGG7IM0w9jOMG/d14qItOJmF4d7EyiHxIDJjNLHdkpMAcky1p4 B+Vn7J/D97iYljRdiy9qasjDGNND/JsCAuthwkyUnNcuhuYvwqhHwLKUQx8xb06E5qoD9QgpB/80 In0W+j/KpBAtf8D6wY9nxoI/QV/4ZqMBDWQhYCVASUZhzhR1LfiWYwz4LAm+i4HL/IRJ3whYb/ZV Abv5oYQVI2i1AOEVaOvBtyp2lDMLdxVqq5G7As/PRI9MClgZW3lMxdW3M93dPThWgLrT9XZnBTin 7BhemTyzHadEA9d52AZkx1qDCz7wM0zLBUqNceAIqh88+cx6O4P7J4O7o3xFzVVkdjdqUCNy9hVP lY+cONMwIuLzr4m5m+tLW+zBhqgvCR0YTDSbDOPKw+FtXrMQubJ+3BxL9Prxd9ysGxkN+FeHQ0Jp x4Lbl2Xmsptq4dFOuntKy8zKiv5TTC/6g2GncIcn7Pdbg/HoiJGjGp55KbtcTGInMKs/1mAtU0/e aZoIjVAEPaAGhWOws+zLCeapn4NEc6sEeupBzThowb4qZPaoHHRl+jIA7DvgQ9nwbDmnWiH6YV9B 1mOFzr6ArIHHVJizStlV3xVoPRPtGYViqMtaJROsUg3oxTYqZxN2lvBvDRMj0SD8G9s0xDLhlMCZ O4cfsvbm5l5/IRGzB0fl38AyRROJuT+apkTDx42BaB0s06IdsEyBcYerIhFYJobZoNdibB40TLLX FZVdPxqmqIsRALO+HP78TeJ+cKeVjG2sIKe1ytPms9oTxc2q5vwWRQudrpqeP0cxh+7V7zXusu4q PKI/YjxkPVSoE8MFbZqwYUYx87OHnCMMXQNTtvrN+dXCou3H3ti27ViX8PPMR19+kfmIBr74ggZv ev2RR44de2Trb+jlH2S+proPPqDaDPvyWCCj4R/eCf8wDJz/qWkmfMAAQIYf6IQfGADI8AOdkJ4w fOIgpMqBWejAK4wDVCg7jdIE+MRNdGAZK/hERUXsJKhQchb0b8EarwU6YA7iOYh3wSffDb45hPgw YjX0Rhp96tGnGppOCzwxXch0Xhxv9SHFPB9mXXzQFybUsxXnJaSSnREyT5D7fYwlcvsGuh5sJ/Al SPZEmjELpPZ/l8wsj2BZglVzSL4Au21fh0LBRGZ8OFI+1mgcWx4JY7OgeddVb9GiAfLmtfsbaNXG /Qc2bNj3/ADBgZ8nAH9PKmJCZzLPGzcu8/XxY5mWccLzG+95Yd/6DfuY3C2FTbgBchcjdzYlMLMw Zu/gUge9z3AIjLI1MsMfw+cgrjcDYzsBBwHs6ymGM4YxEzCozeEsiycTMJWPsjjzV7qAIb7/mbux AVPM91qyQpQMXmAxfrywQX8UncE1ikqQ6CTmqfTfKIcjseea5yXlcLfdcdXvb559fbXXujQ25ZeL ce4+6Krgao7fbNp784oJtcHaETfcgrnvH/hSsmLujXRO08P4/jYNf0UPHZDGalKPbzXq8Y1GCcAO cOCLTCNZD629FnrlLrR5DPUPcXtkR+wgj6J+G+o3o34L6rdAk2wDj/0S7Z5Gu6fRz9Not4fzXSGw l8TaowxfjtWDq0sAdoADVjqK1WEpMJsC7n0AL2riWIvgLAoaKR99GzA+psmKOW/mgz41+L4kiK9U wpCjIG1E+9N4ohhUG4m6E2QZaAM+Rk0T/KMKvKEQHM/WlPnoV40+cX+f92sGNRfi21cvVjxeguNR tPFCdhIoJdC3TcyjOollNXM7ORl17LI+toV6WtnWxeCqhytFsHo1X1wOOQzJeUmQAKx9EF5wVYBt Hf14zZ+vk/Z7g5FiXWF054Jrb7/6tuq3P3jv5clPSvkjXT6vx++Ku02Vt1xy5U2rXn/31ZMHa++9 1p/W44xpfzxU49NXNc0YN77hvrvXPhiT0+mVlYlyvyEVu7RxVJWkuLvj7qfMNquV+Y4Ue0m90nzp CDDyZFMdVkiFZAVgLWAzYCdAAc1jBaZcgCLooAT0TRzPMg/gHGrcKOtESYjvdkB0qBqlJ0DFEGwS s01KtGZ7JH5QL4EUW8trUU4BuA/YCtcUEpLz5vnhQGsDnNfs6n3QyEB3DK7N+SZvVpFkV5TYfIPx z3pg9Uhy599JxZtTpdFoZsllV8/JuBxyqn7+Y2NXPiGb9HujoYrLlgfluE9s88GXz+zfec21Yac3 ZZUDLRP9c9vcdAqQ7zpeGYukZ/+O4WkCvqi5Cd9NpcgzTYwfcRaHGRmRz3pgLuChBCVs/R2C9iXg 5CLoDR8wYYSWLsGcS8HhQaRMwI8WvP2jH1WGcgJ8svU985GskEYD9pyi0LJM5wahadOwPziAgzkG hzEmY7oja4Nhf9naESgb3L1lLlJud+w8Xn5cGWa9pexifGg1XXrtTUsfXS/7Q9H3Q+6yFPY+sD6c u37Srl3m5rQcecRvp8v/Y8WGa+hjXn8o4G3sn+YJMh+8eWL18y/Q3zCN60hixJREBj6WngS+QuRn TTJ0ghbrnyBklO3+KHOc4eI2DH4M17dKYMsPbMl4PgRMeMBh7PsiFTAlAmdMR7OvgWX44PjHVzW5 cySgAcaFLWYMRIuligcdMDU+lnfj5mUhkGMsStE5P3JhV0bV2ZNjfMvBZDWrg2NUM9SXZ4sbvg8Z kneMTmFJWFwbSo8JUol6GyZXhWppZTicGm3IHLalErGETeRWxy3j1Gm1cDeuhLrZ3kO/XO311ODV dKAHeHkPeKkjJ5tGwV9TgcbMzyL4bhwmCXP0g2ccmC1bE9ZDY1G0ZbtibkA5CcBnw3cwwFgc05Lg Y0vAWT1asJMmO1qzc4Q6PJf9rqocElyA/GJI7dWQcoqUEakCws6ucHjFzlZwHodbduxA7g1Yb7BO FpV+IIyNJoC4HL8KYkeKeR8liNXsnQq+IMyGs9lqEOdTzHxfeCoFKY3hC8us623nB1g/IlyVe0SY e0deOBwI6/6qiQblEM2vCln0+lJP3bN35IflQER3267i2NhkoIIWuN2B9KeFshyIFtG+TBCnUmnh lFf2BdxysV9SSP3P0IM4w0pl5gqzsFHhwu6uR+g3siLGbNhxkfCtKRlDV2F9VQV8VYFlViK+Gfbg bsB6rIruBvetRRm7f/IwZr8HZQcRFwAjXngKBO28wOwYWE0v7l958ZXkGMisD19TjkEPY2AFx0Cm wwhZSx0oRUABHyiJb7JBwQgpBgWb0GcRSpgvxyithZZMocyDlqNRqgaN88HQS6E/lsCqLUXegdCM nIS4EfmpgLkAEZBPmiEerd1nunWfnfkst/gfvKU1SNwyTH4sSQN8eCEmhBSTl9F4uQ9xCj/8IcWu X/t4HXtiNIANLc2fZU95AHr+3GBdOZMv8AW2CXIBZxKey17UGHbx8LzEnd//s1YPWU4zEdTkHMec Da2nMt3oTNekKjM9rnBVvYk2Z35TVFdaPuF4Vaq6Qv3hcXNNVbKKSm45Xe3IfEqvzAtFky1vV6aT 0Zq+jqAv4Au7gj46iVa6+SLNFzhxwuuX/bIb91vfz+wNot4X8Ia+Y/xSC/+8A/ySIEeb0kCGB+tp D1kIWMSpyvZzkkAC8xE7QcEEqO3K0Rh+JWjMvPEkEMm+lkygFdNuXlA2Dr0WhDTGQcl8SBZLYT0G +mHnRpcl3vmzclzdykqmiZODIZ71xxQeIwTbDSacHG7kcDeS6BghONqxZ8MxP8z7Nmb3bf6H5svR QSXYYxdVYO+lPBGU5VNPZR7gGtBawzWglprksRWh2rMROV4zQOBnBjw4BaWjhHeYHeA68JQge8JM B0L+MDjg8k3IXgFwKVOhaQF2GQh8TxnWTob0mMhC5FcjXg0dtRoWcD3S65Fm/uc2pLchzXzNPUhn z00MwLgJYAQYkFIipUFvFsQ4R4bcGCFnMjBrBGXCCGW0YjtsncCeApSwgRYK4M4GGiANajEqKiDn hWhtAp2YRVKSANoXIEchGgHQzoxYB0kMg1o97LMQ7gHioh2+D4OTCOsMLfoKlyF0A5Iwt4cwVcms TpId9AeHXkMe3BPzZo8jBr8uRE5FO+g3wK+vYnT/0zV1tjKhIYObDYHAmAmCddz40tKOihnYndhd KpfF7ckyob58Zjoc3huRy9POi5iigt3lf5mHcIb17/6YbWIeMTuNzn7RO/g9rw0+mgvzHfw+d/Dr 3Ow3udkvcmugt5pBy3FYS0wgF+F/A2jBztAUcjH00iXQtpdixTgDNJ4FO3c51p9X4P8vYX8UFKM8 pWSyc8nkiaPHXxQbc8PKGxcvvDFXw6q/AJxBc1CGgnY0AMDuBPb2CJ0OaAOsAKwFbAbsBBwEdAFO AroBZ4AECWACBAAVgGbAdEAbYAVgLWAzYCfgIKALcBLQDTgDBEkAEyAAqAA0A6YD2gArAGsBmwE7 AQcBXYCTgG7AGfC9BDABAoAKQDNg+kDuj030fJqCJy/Msy+jh9azk+CheeaRD81jz/aCfNmwPNMV Q9tzdT/k/elh9eXD8hj/Bc8zKzq0v7pheeYzD61vGpZnlm5o/ZhheeDqgnruyg0Z77hh9eOH5ScM y180LD9lWP7iYfmpw/Ls1GboeJmfPjQ/fVj+smH5mcPy84bl5w/LLxiWbxuWZ5pz6PsXDctfPSyP c4sL2jPvc+jzS4blrxuWx/7JBe2vH5a/YVh+2bD8jcPyNw3LrxiWZ97Z0PFxPTaE/jcPq79lWH71 sPytLP//AYgq+QsKZW5kc3RyZWFtCmVuZG9iagoyMSAwIG9iagoxMzc0MwplbmRvYmoKMTAgMCBv YmoKPDwgL1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvVkVPQ1dIK0Fy aWFsLUJvbGRJdGFsaWNNVCAvRm9udERlc2NyaXB0b3IKMjIgMCBSIC9FbmNvZGluZyAvTWFjUm9t YW5FbmNvZGluZyAvRmlyc3RDaGFyIDMyIC9MYXN0Q2hhciAxMTYgL1dpZHRocyBbIDI3OAowIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNTU2IDAgMCA1NTYgMCAwIDAgNTU2IDAgMCAw IDAgMCAwIDAgMCAwCjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDU1NiAwIDU1NiA2MTEKNTU2IDAgNjExIDYxMSAyNzggMCAwIDI3OCAw IDYxMSA2MTEgMCAwIDM4OSA1NTYgMzMzIF0gPj4KZW5kb2JqCjIyIDAgb2JqCjw8IC9UeXBlIC9G b250RGVzY3JpcHRvciAvRm9udE5hbWUgL1ZFT0NXSCtBcmlhbC1Cb2xkSXRhbGljTVQgL0ZsYWdz IDk2IC9Gb250QkJveApbLTU2MCAtMzc2IDEzOTAgMTAxOF0gL0l0YWxpY0FuZ2xlIC02IC9Bc2Nl bnQgOTA1IC9EZXNjZW50IC0yMTIgL0NhcEhlaWdodAo3MTUgL1N0ZW1WIDk2IC9MZWFkaW5nIDMz IC9YSGVpZ2h0IDUxOSAvU3RlbUggODEgL0F2Z1dpZHRoIDQ3OSAvTWF4V2lkdGggMTMzMwovRm9u dEZpbGUyIDIzIDAgUiA+PgplbmRvYmoKMjMgMCBvYmoKPDwgL0xlbmd0aCAyNCAwIFIgL0xlbmd0 aDEgMTM2MDggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBrXp7fFTF9fjM3Oe+7z6y z4S9m02yYTcvEpIQiOTmySNCQkBIkJgEBImCkIAgSAWfYFRIq0VFW2gVH1BlkwguYCWttKCiUCsq YhVaUHykphbwq8Du98y9AfH76/f3x+/z290zZx5n5p45c86ZM3N3aedtc5ERrUEMUuYsbFuM1I/3 GUB/nLNsqayVTVGE+Oi8xTct1MqOVoS4CzctWDFPK/u6EfKkzZ/bdqNWRhcBF82HCq2MRwJOm79w 6e1a2TsL8PgFi+YMtfvmQzljYdvtQ89HH0NZvrVt4VyNfiQdL2vxoiVLh8ovAx6/uHPuED1uRMg4 Y+b/+CAMVDb0LSpFMxCHCJJQLroOOM8nLYiFMm3nLLPmbNkYb7GUnhM9ojr801P2FdHMn56cPf3C /RcvGfxiGshHp9LTBugnjI1PRpX6bRfu/6HB4EcBJNCGKx9bz7S8vcwUoFSYut6SAiXG1PVJSfmA 6/uMNoon9eUWqLh3LG2e1Fc9QSvWq8XemRqaW7CGNvp8Wh+bQ8MGU76lPImZhFYDfAPAoDJI6wA2 ACQAWGSBlLYT5to+nOpv/T1TC+VamLnCTOirrMxfvY+ZgDYDfAoAGgC1eSpTE/oKC+mDJvTljtBw KKTh1HR4sBHIywBWAxwGoN05tbvOnp9bHmAmQtNEeM4GSPcBHAb4FOAbAA74mohyAeoAWgE2A2i1 lIZyN7Fv+Gj6vIl92oQn9hmk/PpyiRkPA4+HDuOBXZpiGHY8DDte7Ta+Tyfl23Yn+snHvUp5vpYp KVUzn/SVlue/V+4hn0CnPPIxUgDqAVoBjgCcABgEgJWEtBtgC0AUhmKLu8tTyVvQr5scpGuq5hU1 n6fm89S8rOblIZqtCJOtaBn0eQZGegYR8oyS3nKCPyGQffw+gezgdwhkM79ZIHV8nUAsvGWozlLe zFSAgCpAQBUwywp1KStA4hWoBWAHQD9AAoBHuaQIrQYgyAKpH4DWlAHUAWwA2AywD0BEOyDFKt1l mhaoWQ2QAOCRRAqhVKiOVQjjFIJgCkHStA6rrWWQq6N1zET4VjAVpBi+RfAtJIUg90O9gZGquN+6 nHnzcuaNy5mDNBNL9Pct9Jaq+AtvIe2Dr++FDG1YNYSXDeHWIZyj4d7wyAIg6w0XaChfQyM0lKeh XA2FNTRcQ5kaCmjIpSGnhpI05NCQXUM2DZk0ZNSQgaK+8BAzIY2ZkMZMSGMmpDET0pgJacyENGZC GjMhjZmQxkxIYyakMRPSmAlpzIQ0ZkIaMyGNmZDGTEhjJjQkoQDFsApphf4YeUtDb2roDQ0dVAzQ uDCt1P8FJcLXK37AqwCWAbQC5ACEAUIAAYAYU9a7fjigsX1y0N9SrmOuQYsAVgNsAGCZkj454PeD PxoFajsKFHUUqO4oUNvNkO4A2AfAXGkjTOEuGHdDWSk837MLWPmOPgb3qRzi7RqarqHrNORTJgPN DwBfArwLsBzgVoAZANcCVAJcA1AIUIyR7QQexMS2GK/B3ZjBGOkwARNwucBJ26yispc4IacjD/S2 2+HZO3szb4IZ4JdRJouRH/fhFhVHUbuKt6MQTof6bYCnA/5tb/jX0G1zbzgf0K96wyAgPLc3MwXQ jb2ZMqA5vZl5gNp6M8sBXd8b+rW/XIdnoJBIHzAdhfEmwNf1hh+A5mkamtobroSSXxthWG/mI/5y A05B7WQ70PpQSMUeFCbbe/0/hGIs7vV/H4qR7bv834Xr/F+GYyLe5f8ivMJ/NDNGsGLxv5fztv/d wNv+1zNz/X9sB0rF4O9vf9v/GpD3pKkDbArH8HSofiI8yv/zMChDDlRDeTl0XRbe7l8MQ8HjFvlV 6lsDMbwJWheGHvHPDd/lbw1BeZe/JRz2z8iJ4fRefwM8Bvi6FkrTd/lr4eEThh48LhzxV8HDKymf vf7yTHVEBUbAis9/TeCUfwzwUJyz118YHuMfkXPKHwxX+1PbYaBX/NeZdCZdcXcMB5UioftvQnen 0H2d0D1S6M4VuiNCd4bQnS50DxO6UwSHaBMl0SwaRb0oirzIikREoiOWOKFk0f3bwUsU8SxNWTUv EZqHBFJEsEjQRGSL2plaUju1IjoqUhsTEg3R4khtVKy/vrEH4/VNtDbaPwfVzpaj56cGY1g/ZWaU C1bgqK0W1U6rcEfJuhhG0xpBy2mH+3xRW2XjboSx576HfUO4qamycQ/4aCfCS5qQc1mZu8w21lpS U/Ufkla1srUq8uPH/WM2EqmtX7Eb1OT5PsFfJEBxKhS7abGbFt0p0Y21Uxuj21Kaovk0k0hpqo0+ MFWe1bibuImzumo3cVHU1Lib7SPu6gZaz/ZVNTXVwhKrdEiG+qrdKI0ioDOLSKZ0SDaLKh3ZrtH5 iYvSZVIEdO6tyK/S+d1bVToWU7qedrm6qkeGBGiCCLWrNO1BdBXNbtyC0oAqDRJKtQW3UCrcEtxC qaIRdaBQCEhyIAESnIxC6kAhnKySFP5IEhgiablC0qKSPPQjSVgjYcDUtVGYbUBytZz/X/NzK6rb p1bg2vrGHhFVNFWCACh2SovHqpph8ozd6tuD3mW+QoZIU1QfrIgagrDxl7kjUinObYYOvasxbm5S c9/QHG+M8kAmAFDdGhNw3+nbwyL8vDqCEapNQ03Z5dnltAl0ng5uhmrLUJP7zjEB3x78/FCTBNVW eO5/muaSJUsjS65u+I9UVxP873nkrm6v0n40RwGGv02FpUuW0s+S6ir4LUW10fDU2uioKTMbewSh Oqq0VjVBXc7lOoZR63p0OsBtVU1Lhj6RpbctheeD3JQRCkQNCoQMSjgfYARAHkBugQIbuAK7twJb twL7tgKbtgI79pZyvRrPbVHjuc1qfjM5qBRgJRyGnsOBCjDs5krYBhggnAkYIBwASIEIOqQmgYKf CInydrVQmlAEZg01MOXbhoR7WwQvuVx9hXZpBHF7kE+FZ5GPzUA+hBKnL0P8lsRp2hZfkDhNPgc/ lqzB0KlkJXofh7AbncM2tAO2lDfRy+hDHEar0Nv4RuRELnSRpCEZcxAIutE0tA29iQXUhPoSX6Dn 4QT1NeyDP0cncBaajg5hM+zn16Ffock4KbEdfYVJ4gSMMBrVg8NxcMu4D/HdiMMMuS+Ri0zQ8x7k QGPRU+iveJVuZ+IoKka/Z69N/As9jt0kjMxoMfoMDQJ/2WQUaU4sRG1oNfoD5plK7pFEFroVXWTu TzwNnAhoKjy3Bd2JHoOnjsX9ZAd3I0pGZWg8OOxmtBA9i14k87hB1ZlnoAXA+wF0Br+IjzNnmO9Z kb2BfYhLj5fBM1NRARoFM2tBs9ES9BB6HL2GEfbjBvwEl3/pLpCJjDLQCKBZg+5GD6A+aDVjK07C 0/GvyJ3kMPkn+wL3YeIwUI1Ey4Cne9Af0J/QV+hbzOMcnIfvxrvxXwgmK8gPjJxAiVdRJhqHGtAs tBzdhbrRE6gXvQrS/AOZxFQyy5ko+xV7Ib4fTuQzgac7UB96Ax2FdbPhZJJBvmYCzH3M08wh5hzM xM7eA7QnYBZ5wOO18J0K81+CVqK1aD36DdqOdqE9wM8R9Bd0HJ0GrkfhW/Aq/Gu8F5/HP5AASSWl ZBH5JYmSPeTvjJOZwkxjOpiNzCbmz8xfWStbwdayv2J3sR/x2fwZoS2+Nf6PxOREY+KuxC8SexN/ TPw18U84FZuAgyDKQu0g6w6Y12qQ5EvoNfgeRB+gY+gjOM2fBq1D2Ih9uBBPxFPxdXgB7sTr8Qb8 KH4c/wm/Q/TESpJIHaknN5H7yUFymClhxjAxNpPNZ6vZmewt7FL2fi4fvpO4h7jnuW3cdm6Qu8jb +G2wsx+6FL70SXx+fFn8bwl9wpwYlshLtCfOwalyGKxeG7oJZPIkyOQZ0I7foX60Hx0CqbwH3H2M /oY+QZ8Ch/9GF7EDO7Ebvj6cBbo1Gd+Mb8d3wSo+jp/ET+NdOIZfxa/jt/ER/Bf8Lv4Qn8R/x1/i f+JBwhAP8ZMgiZAWMp+shu/95BHyBNlE3gQ9OUyOkPfJGTLASEwqAzEyfEuZcjhAdTHbmSNsEusC adext7ErQeLPsv3sH9i/sP/gECdxdi6Ny+JquQe5fu6AOmcz7+Yz+Fv5e/h7+a18TGAFp1Ak3C08 IDwp/EZ4T3SIQXGLuBdmkYk92Dtk/yrCjfjPEJFfi5vwWjwNm3AXbkIOEkG/YTvIRPYpsoFAaElJ +RI2SjHzAlrPYGJhu5mf40fRToikx6B78Vi0HP8CVvrPeDFoVxbaxOxj4qQGg1vAz+BR6DxzGPzS UZDWSDwCj0MTyUH2He7ArLUkjdyAj7E38Dr2z+gRspdtZQtZDLJdAXHXOuZhVIT+ySxhToFVLGS7 wSJXYRZdQ8ags4DfBx2ScDrJQWV4AuPB9cw87IV50r5HwUu0kx5ShvbjR8ktTCa+A+ejcyiO+rjX 0RNcA3s0MZndmZChZiWdGdoG48Ac8UNMKzs8MSP+HV7LuMkfmAxyDf6WbSPt8ZdwHR5JTjMj8BKy FF+AU0EmaNCbZBIpx14405tg/K9Bhy6if6Fe9hHm4cQnzPb4FPIqSuNmoXfBo/FoCtmD/43+Cv70 NdAKEXzui2wR2sncigaZVhIjl/B35Dv0a/QSeOEdJISPEwUN8C3sCXx6kRkPY+aBTyNoK3jl2cw/ UXniJER4SxOHE/uwD+xlD/ilf3Gvk0XoF+AvXgOPcif4sTbQ5gXIiFeABZjh2we6/y34BxcsDwc+ 9Faw003gL/eAvzgKXuMMtH+MzoPtPoGOE4zq+aeA80H0R5jfD1hEu1E+7BlmsKVTifPsuyC7l9ED DEavC3Z+LHs/+j23TxiLtiWKwa/fioajjWgX/oh9Hr2mVExTysZeUzpmdMmo4qLCkQX5I/Jyc7Kz IuHhmaGM9LRgakD2D0tJ9nk9bpczyWG3WSWL2WQ06HWiwHMsA8xkVQdrWuVoRmuUzQiOH59Ny8E2 qGi7qqI1KkNVzU9pojLt1wZNP6FUgHLe/6BUNErlCiWW5FJUmp0lVwfl6NtVQTmGZ05phPzDVcEm OTqg5iepeTZDLZigEAhAD7naPb9KjuJWuTpas2x+V3VrVXYW7jHoK4OVc/XZWahHb4CsAXJRV3Bx D3aNxWoGguXRPXBKNcEco95gVXXUE4SuMAyTXt12Y7R+SmN1lS8QaMrOiuLKOcHZUUSjuIhKgirV x0T5yqigPkZuh1goih6Ue7L6ux6KSWh2a8R4Y/DGtlmNUaYNxqiOWiPw3Kqoa+Up949FGBxCybVX t/qYrmp3u0yJu7rWytH+KY1X9fUF6AhNTTAG9CXpNa1dNfDoh2CpsDsXmKPs06lok5obrKY1rTfL UV2wIji/6+ZWWBBvVxQ1rAj0er3KboglvNVy17TGYCBa5gs2tVUl9zhQV8OKPo8ie37akp3VI1k1 afaYLUMZo+nqzFyQtNam5lRymqttuCJOTDkKToDAMirPkYGTxiBMZBRN5o5CXXNGgdTh04ShV/RG WIb2qK6ytUsaTetBlDjKpUtBuescgmUPDnz905q2oRo+XTqHaCNVjisKFsVtl/PRSCQaDlO9ECph IYHHsWq5MDtrWYxMDy6WZEAgPlTfCN2aRueCzAMBuqoPxhQ0GwrRNVMatbKMZvt6kZILwT5ppS2w alpL0nW0Zc3llivdW4Ogvi/TAzBKiooZV34WyWmvnj86ip3/l+a5Wnvt1GAthOlydVfrkKrWTvtJ SWunAgW5QdtQDmsdQeBRNj3Kp08IgsY1zGykFfDj0muC1e2t48HCgMeovbKR8RFqB5AjPkYdCtR2 1szL49FCo5GOxabzdIZgPwyorVqB5Zqo1DpeS5v0gcCQUf2ffWKCeFWnWGKQ9lLRj92GphwdHRma lDbF6JiflH/CnbGLqZ0GTonUTpvZ1aX/SVsNuLuurpqgXNPV2tUWS6yZHZSlYNduiBAruxZXg6PS Vj+W2POgL1rzUBNMZT4eDTpOUEVPEK+b0qPgdVNnNu6Giw153bTGXohAK1srmnrSoK1xt4yQotaS K7WURqYlVIvBKnqJqDb5disIrVFpWbVCLc+BOw21TiOCOozmxIhWJ6l0TU1N2bBhwX1KCULsErQK 4O4hmAX4DvYfaAXg5YAVgOlA1wBQT/MAq5gUVAHt2WQb7FMIBqI6CS95YFD67keGM4BWo1b/rwm9 zoEQZqgdjrf/Xz8cjMbDbkpfG+mQHhnU0Y2QmmDPpR8LvHOyqjkEZ40CiLf2k5uZLtbBvsi9w/9R uE/0i7foJune088x3GX8BVDCfgcvpeALXAuo9GWCX+GFGDmnuBHHvsIgvcC+gpFH5LlXCBPV7fsE rgbOl14qnSydLZ10qRSVQV66CMmIvIA1YE2HBG640EWZ6b+ocOgCktl+Ks9VsC4/5/ohlpiozBri 3gh82/kVDrzJjm25llwp2zXaVWepk+ocdUl1zhn2R+1P2/vse9w7/f36fkO//a/2Y+4T9tPO066z 9nPOcy6vxWqxWewWB5tnVsz95iNm1hzDNytWK5w3LbQuqtZyUHvDLslqbAFO9pBOlIKTe1lO2kM6 4O3EBsXkbd8gJASCBEkgMPvwrgBqlzHGMbKoT7Ji6x48GcmMo+cxOvvms80D0rnmjoGzp1DZpVPN IILmUqutBEsDzT08qZzWuNPIWh2sGUEl/JpG5OEOeoOyG5kSJ3ptJbZY4r96rSU6+k7BWqLXkEFD Rg2ZNGTWkB069BhLUARfPps3oWYYE6cXFRXkQxjDCzzLCwEmMJYUFxUXQeCTEUzlSUr889Tv9779 5fiGMfGzMzLxxaKL95nnPPqnR0M1I2dUVs1j/hU+dOyT7TN2tFZ9f31B/IcFrz+/d31kcmfOxFk3 gaTuTnzObuaeRQFMlEq7YihxANB1KrWMkSZZJkk3WGZKi8ynxPNJ551GGctsppTpkOVrpDJrmeMx 6XHrJscZ6z9sp73nkiyOpKQY3qE4JatDkiDoSjK6UT3sSovxCcziPfglxOPknX7TIgu2xMiGvhNG bIQQSJHcdtlR5qhz7HMcdnzq4B2wlH02K6uLwVW6b5ctRjp2IrtkJ/ZyI34MToYOcgwlwc2CBe7O reRheI10TDHgdgtMyJP6KqwgqG7HJFi8gUunYDFPnR2gStxcmnupGdby0vlmumbWkrXmnAj3M2k/ LF4zao5E7Ol8ksNZkD8kWyFkB3ELQ/InbDA1427swtdPmPfcDZNHtY/4+lNysijuqQxPG/78h4/F zz6y91/4GY9DP2/e67+bN39koY0MxH/4u93+99cejx/79bcQcVNpLwcLccPp/h2lebQ4Or1OvEVc Ia4TnxAfdXxLvhfPus8FjDqBSUoWksVMIcNVMmyao128ybpSfEDcJL4gHhOOJR1L/4z5QvhC/Mz9 RbrzTmEl3CyzWJQ9LUEcnLtYjy16rI8xSTvr4T0FAcH/BpqTe52m5BhOVoZLnKddE6c3U25XTPWm VlO3iTXdRc2hHYF/IcgTevXfqhibJw1QY5gMYpwEUhwou3S2+TwYRjMGEVLtVzUfNdvTnSA50Ewe xFQ4EhXkQ9iNAqkZmOqpMCTYoruxSawsmTCqIa/5pm0fY+8X73wUfzr+j+cOkqOzqqaVTplZXry4 DDc4p9eUTN1d+vnBE3hW/L0Eit926ZN9TMPShZPbezoXTtsJHM4CWVaxZaANI/BzysLbM+/33u27 L7krk7OxDC+jAsZgq/FW+SaE1nkfCO32vuE97j0eOp9hcHpwbsH7zJncM3knCi5GzuWeyxPTPKNt TbZ223zPHZ7d6BXvR+So+33PGe+Xoa8yzY0ePCItmRlmFqwYBRJpOC2GnYo3OS9ZSV6cfCT5RDKX HDBb9Ey2PZsMZuNssOi+fE+ZijMdGg7aVKwkD7OUZYcc4Nf9iFggicBd0SK4URkE3xxj0pThAQX6 BhToGFCgV0CBHpYATgRwIMwKQpV/GJaGycPIsBipVrzGBmsBAgKy2NJvgRe2kkW25FkSFg4srEzR F8hgE2kW1c9VK+5wlUspK2xx4TyX4jrs+tTFujz5FW9qK90RAZOBlZXONnd0nh242NEJC36puYM6 pFPNHWUDNAO41FrSnDvQAWtPdcDmAhVAzc1gQp0duIPei0pY0ZcgAKzoAAPQntSfXeXMkhyuQEaI 19QFHBo9ylGPhsHRXVGXYvx5/EzeN396e7+1IOyOf2Fly56Zeu/vfv/vt6ttEydMasLYG/mwInf8 mPIlJU7yvXv9lq3L8xZ89tq1VVNHj62pfXHd47vsVndpWs7YsvirAu/NT7smv7psTjsI5Q7Qn3tB f3xolzLK58NhYxNpYm6BU/4d5A5mJbc4ZZ1vB3qBbGN+533B14t3kles0RR7RD+KjCcM9iCzzYJi JFUxeEKswW/B+1SvlqqU2UIGAaXhMrwI7jjg7o8kMM6FYh3cTW3G++Aez1KFzJJZNjNmb4ozjW5J sjAIdy6nk4dPV7efIXsrgYXozKWrcKq5ExIQt2ZxIO5OzPHUJRWOtKXBBuHiMqj0huyMScWu6vi3 vW/9sxunvvjqCXP8G33T+Kndk2ZVV6/B3dl7/vjtey/ikT37t6Q0TVv13YIb5t0IcQJakfica4L7 Xgvcfr6rPJbuq2MqjXWOie6JybcnC2P0o92jfY1J9cPWDHsWbXMeQJ+jM+bv0L+Z7/XmsD4zablt 8TA2iQHdNBGMzSavgdg54jIxZviHgEU2Y4cZclhvD3EGLwjJbAExoAZwUliGTWINZrbgKCYC3JjJ cNNZjzk8TEpD8NpNFgfhhdvpFOwa/ja8ngJnNGAraQbp5A5EaIACfmmgrHQtlxMBdw5a6VJdE8hq rVkqpf69oxk8fCBQPKRv4J5c9gBWnb2md4QNxQfdkx9r2fo2lgfev2UJ9l8sXjJt8topq6bc+dsl teUnP07gp7aR9AvnO9fc8vHcJevjZ0Biy0GLFoMWuZCMP1R+vs7WBW+p/Nj2oG6d6V7zgI61i5LO qWeSRa/eb3BbPUl2v01uEsUuaa3/97pd5kO647p/iIJB0NskLBGJkVhpmOSv8lfL+ummeaaVwu22 2/0PCL+Un9ZtNb0q7BMPi8fEI/qPDF8I34g/CN+L3zouJJ/1OyPWdTYyw3+T/7d6Rhbd+2S8Abbr GPlGcSG44KrHpJ6KGWPelhKyC7pDInVT6ZkjKVaSPMNG1ou4Dt4jq+I+AgLnxBgZpxTY+JDRIK7S HUpxP+wmKXCXWYWcklN2Ms41qXLaPTAk7MTU7wxaWMvpwGUV7higy9TZQTffS2poxGt+kacPznaV qRjcnIrB01HcC86OOotIE3VC4HfKBqhH8aRQp5iiQK8U6hlTqGdMoZ5RIwaPBLoAW3xnKVa3pGZQ DvA3neCT1EdLEI7ptXBMX0JnfLmk00o6rc2slnrMmseibNDIAAc0syrmqPqgwpHFRQEakqVfDhTY WZfy8IoZG0DCtReeej9+dsVWnP/6Z/Ef8M1NTQ978B6r7ua7H408+SS2fPrRts/+dWz+LLt+2bL7 7wENUuJT2AugQeloJK5VHpSL8FrXPfBfmuBkU23q5DCb4crMGwFxPuuxZGAyznXAN1jEdOWuKXox 5/lctr5oeebionuHrc3kRueM89UMG5/V6OZCkcycUfZRnpIIl20fnk/cRoPBA29hjG5jtpvxGLw+ n2zwOKDSZxhu9nr4vHCSMDxk1ktIBpYgApDhrLCHSUMcLBXIm6M6YgZxc+GAxVCY6TFI3r0kFZyn h0xUZF85MuQaug2MxSAb+g0MY7BDpt6wxbDPMGgQDDH8J8VXBGqyPiMNWSWrbB20stbThQaXoVD/ UB616FLVqM8PSLDhdA6ckk6pVf1ll4b2HmrfYM9XYjbNyEuoP7xs47Dm8IEXBpDiDhfnGIpIioqH ghIbjaRdxQHGrDnOq+0f9pxKnDuscvT1xcO9kkf/y81PHVx3fs3N0RGZ2BTLHlu/8tm2k5/h6xY2 1D5cu7J+0l1heVRWTm4gLXls6J78VR+/txeP2rJ47qsXHzy6a8EEeVOfnbhXrO58d3ZH18rVs2G/ mQ6noz3gW714uPKGnIw9HN6h22b7WPeB8QPpQ+vXNsEBMRwRrW6j25KO043pljRvER5FisQiY5Gl yFsj1hhnsDOMM7wrjCst9+mfw8/rnjM+Z3nB+oLtOe9O/S7jLssBdAAfJG/oDpjesL5h+wB9aPzA dFz6yHrc9qX0pTWXhYt7Bi5DzVaD0aR3w9HPZJLNVnDLVjjQypg4MIbXDsgRFgQT9dV6q5lgydTQ bcay+bD5GzNjMeeay8wJMyubf2Ym5hjJV4yooQ6cwHqf2YVdMby7B+IJzUeDDcNiwkpK1ElDepWX Xpvjjpg1bw0ruH8/rOL+/QK4azhm0lgCjLcjEMABZij+FpiAXbM3Gh8I+Lb4SVyA/be2Pd9618bk u+Mn70uqKBlfMT3bM5zbc+n8tZWP3q7cf+kRsuKmlEIlv6K1cD/d4RogeRpWAU7CWFC6ZN14plu3 RXdEN6jj4T0NQyzEwhDYazg36+aeF3boDrIH+APCB/wAvGk5w5qCbJDL1RXxRcJ0bga/RreR3yhs 5bcKZxgTLB78pZOJkijTT/qZI+QI8w35hhEJuA3MQOiGCAevH1l4NM/LAnLQmm5mCxNlGIb6RJdn JBNj0hUzvNxELPQS9BAbwAn1sV6+AWKNxxSLAOFbt4DrgPv1ouCKkd09QxtiR+TUJWo0dDeEr3Q+ 0nHVhqgaSokA0qVAAzZ6tgRjASmDjAP0YInvxf6i+Mlh2P9J/CS3J36x+8JHCDS3HmT2G1Vmdyh2 xMlcN7eFO8KdgBdHQpTDqm+4prIwl5vBrOF2cAfQQXyA+RB/wJzB3zEGwjAywg4YCO4hGCRiiWmI ohMwc4TrYPT1LFKV5vI0QF+0OQzt5lQbcKSzowAHYBMrwMPi73B7fqgZsqi94Dk9+BblZb0A7xRE XhBEC2sTedlXLzIegl+SPhbgpCSxZ9AZy5cS86Z0wHnAfVxiXza+YjooHDCwzyb1irv0LxvYIlcN /6z+WROb7irWF5uKHGw6StNnmJgP9R8YjpmZbRb8O+EF3QtmZoVwh2WFxNTox5lm6Bnicrsh2DEa LTq9QUzCbtFgkI0WB1Rgt1v2IIfHgwxGo9ujt4U5Af4iZDEij2RooPcASvK4wm4j/saYMBLZeNhI LMZcY5mRkY2rjcSoWpe7oc6DPeu9RpdHXe9JV1sX7JFX7IsaF9jYkNz+o31RI1PtS3WVWkK3SW2T FBODvVKJJZb4EBDcWdAS3FIM9kgl6q3E0GZ4+UT8o0VSgwT9GYml5Hk9s+95LPCz+Mk7k8tHl23K kjOvj59kM7oaazeuGvXUpefI9Wu9xWU3zxi7L34t2OMqiJ/egjU0Ii96SRk5wXMk+YLney/7ludN LxlOQmKmLeQZZ5vgqU+ex97uWecZTDZINBaQaBgghRiwAS2qoFjJg0pXSGcwpfHwX4yRvDKukFeq C3fwh3nSwm/gd/AJ+IMWL/EyX88P8hwfgz3XCd442ZEmgUrBvjcISnraNxykDOEL3AJ1wGkXApEI PfxGIhRUjezssMPxNh8lQZqaoZ1yh6Lv4qJVeBK2fIXF+K74VxvPdDL5y29o7q5fdcOy+k54ex/C LfFLx+Px+LrbP8a18+5YcnxW5/1zN8DjK8A9U2lY0EmlOZ2k60fqDjDHjV8b+QYG1Js3uozpKMOU ay021QozDC3WRcJifi0+iA6YDlg+MH1uspkYJ3lSeMzMXidsFAghjMmMeaJjiQmbzbIFOSwQc1v0 uhh+SdGxVBkhdKOBl2K+prCexxIPVRJPeHq4tMoCbhXWwH3Z+h1wQ2amPmjiK3VwzlkvWVx7yG7s RFo0fmpAgluBTjglgqg0H3RVPF6iRuPUy4s0Fu/sUN073KxAFC6opxaqPTI2RjbuGDvu1lDWxCem h2uo2rzzuf8r8+K9b8X7QDrZoCs3g3SycO9uFIT/3ekgIHHLkKTT2zZdSRCQ8pChRMqRc/JylJz6 HE5vFocXGcYZlwePm46mnzGJQpBLdwbt6WnpNfrqoACy8R7JYeSckalF6dWp49KVnGZ0vXlaUr2z wTUjbVpGS1Z9zvLI/ZFN5m1JWyJbsqI5byW95eyP7M/63uvT3irKgdRgWnqGyRGGaxaX340tbr+7 xb0IdhB6oLfZksMOcOPgvVrxFtwPV2ExJlmx2Nhw2OCuynWVuepcDJj2rJ1i2pEQDtHVCBkKUUgK yaG8kBLiQutz/FUSTstFmF4WkHq0Ax1G3yBWPYAa6yRskY5IRIYTRAw/05ddoZ0i4RRPgymJBuIR uMtsvhKJs5rNsPAoGomrGEyH4l6IrLXzOqymdtf5Mgv/YiCouUmN4xVHMjXAZBqMJ1MrTKbBuNYF nqderamXAhhCcNhkOtWmy/dDhSNDGaG0EBxb1SAajq0hqgFwG+CkX7jnhDNtNnam39oye8zwJGdb /OLYthvuweTtd5Pj3yXlKjNn1mV61r077sb4559dwMOzGidkDYukuJzy9PzJd955/eqNa3JGp4RK Q5leKfOaMVNve+yTF0B3NiU+Z2RuI+wVh5R/1zEbmE8Z+GEXi38hPmo4zjJ3sPex94r3eeB/Axah iGVMzK+Zg8yf2WPMKZbPZFbDvyoYQgSWo/9lEngd73YSJ2flrYIkOa1nxBPSl55B3vqp7wQ+xZ7k 2U+FY+Kn1mMedj+/X/orfp9lXxH3WffjAyz7jLhV96z7GU8U7xX4NdY1vkfYjeJG3RaWb3Tfrlvh XsOvEdZIfKqnmh2na2QadU1JfKqYoZOlNGt2UoabB8/AyKzMBfgAcGIwsG6nk/EwTiSIrAEJHGsA m2ecGNpYs95slexMjIxXhrOsgWUMcHCDyJgRLAgnQDIhuHFBEh4E3QnZDdZDUapEcO4z8YcEiDQS Ao5CsLGXzIJgXwSnoDPgQ5uhX4GHuogkQ1q3M+rsdzLambDfedbJOfeQayHOTaKhCahex8Cps50Q 0a+U/gvU0Z179mwH3KoP0JskCPZL6S2sCIEgcufSC46SCE0s8FlLw0O6Y1GH++OH3jV1dEDgAmc7 e3FBcTpTIASZoROaQNUHdMu+KeuhIJ4waUdWtNkTLrZfmz1x8uNd6U3MlKPb/hzvPhqvXGENpAtH LbfNH9GDt9NDT+IsQAj+X/SfPjaoZFAS3NwmoypUA/+4ov8Nq4V/SNWhKRBVXgfx/Qy1I/xNHKRD PzzyIDS9uq5yxvhIeWd724LsikULbpywtG1B+5xJ09B/A+lD/PgKZW5kc3RyZWFtCmVuZG9iagoy NCAwIG9iago5OTczCmVuZG9iagoxMSAwIG9iago8PCAvVHlwZSAvRm9udCAvU3VidHlwZSAvVHJ1 ZVR5cGUgL0Jhc2VGb250IC9ZU1NZUFQrVmVyZGFuYS1JdGFsaWMgL0ZvbnREZXNjcmlwdG9yCjI1 IDAgUiAvRW5jb2RpbmcgL01hY1JvbWFuRW5jb2RpbmcgL0ZpcnN0Q2hhciAzMiAvTGFzdENoYXIg MTIxIC9XaWR0aHMgWyAzNTIKMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAzNjQgNDU0IDAgNjM2 IDYzNiAwIDYzNiAwIDAgMCAwIDAgNDU0IDAgMCAwIDAgMAowIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgNjE2IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDYwMSA2MjMKNTIx IDYyMyA1OTYgMzUyIDYyMiA2MzMgMjc0IDAgMCAyNzQgOTczIDYzMyA2MDcgNjIzIDAgNDI3IDUy MSAzOTQgNjMzIDU5MQo4MTggMCA1OTEgXSA+PgplbmRvYmoKMjUgMCBvYmoKPDwgL1R5cGUgL0Zv bnREZXNjcmlwdG9yIC9Gb250TmFtZSAvWVNTWVBUK1ZlcmRhbmEtSXRhbGljIC9GbGFncyA5NiAv Rm9udEJCb3gKWy00NTMgLTMwMyAxNDYxIDEwNTFdIC9JdGFsaWNBbmdsZSAtNiAvQXNjZW50IDEw MDUgL0Rlc2NlbnQgLTIxMCAvQ2FwSGVpZ2h0CjcyNyAvU3RlbVYgOTcgL1hIZWlnaHQgNTQ1IC9T dGVtSCA4MiAvQXZnV2lkdGggNTA4IC9NYXhXaWR0aCAxNTE5IC9Gb250RmlsZTIKMjYgMCBSID4+ CmVuZG9iagoyNiAwIG9iago8PCAvTGVuZ3RoIDI3IDAgUiAvTGVuZ3RoMSA5NTQwIC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Aa16CVxU173wOecuM3e2e2djgAHuHYZ9wAGGbRDlBhgS JQmogKCZOCgq4jZGMe6DGsGgJlHjkn3xa9K+1zRjmnxipAabPWlaTdL+UpPY5KvN0sYueU1+L43A +58Lbnnte/29913m7Ofcc/77/38ua27rWYhMqBcxSF2wvCOKtMf0ARQ/W7B2jTLeZu9BCH+yKLp4 +XibX4cQ94fFy9YvGm+bP0Mo4d2uhR2d4210EcqyLugYb+MSKDO6lq+BdfQx0Xnrlq1cMDFu/j60 py7vWDexP6L7Kys6li+EEp7MFMhyoitXr9GaKGMIykj0toUT83EbQkzZnO88CMOsNLQa6dBSxCGC JHQdakGIeHAU4MXaOMfJr8iv5M8Tq75Cbr32+qeGhlbQysuTQgsuRkb2G+P6LlgtQBp/4L164+hM gCMLxj8zxpEZ3nf1k6YKzZ99miR/8mmyPDg2rG5/1ZVU9v/+kCV/8Yd8Wfm1+mvS+LN5PyNvvmGT V76BH3nj6TfI6/v08qlnM+QH7y+XH7i/WL4P0v17i+XDBwvlQwdvkA9AOrivQL4X+vbvnSTv3Vcv y/v8+8i+vYrcuHfeXvLIXqx+9NFHRDqnnCPonHSu8Jx6rulc9ByvDgnGMnqOphMmqUx6HquDglSG jknHlGNM5Lnoc+S3v/PK53+nyOhC4YXIBabpl1h9t+nd6LvMl1ud8p+fLZb/BOmRZ/H7Z/Pls+97 5A8+nCR/eNJGgfvxOxZJe/nYOwap7O2TevkMDIin5dP+08wvTibJw5Be2Nwg/+SkLJ+MBeW7djfI e3Y1yLt35cgDu2rlOyHtil0vP7QjWd65Y5LcvyNP7tvRKd+xo0neDkndUTWlbAcsfHSbTd7W2yBv jTXIau91dWW9sRx5MzRiW0JydAtWt1xXW5bbObmzobO9M9K5ppOXRI+c4MyTdbxHTkrMk1nGI9tt eXJ+gZjns+TkilnZloxMMd1rUTximmxxp6SaE5OSzc4El9lmd5hFyWoymS0mwWA08Tq9iWE5E8LE JIm9IlH5Xp6oTC9DRFSNGpGaFUOsiPzQWIli6AX0CzSG9O7Jelms1MtMUC+jCr3cFMBxWwNqaK6J 2zGUs2riAV/DoB7NjBf7GuJC09y2oxjf1Q69cbJzEKPmOLtzkEBhq50zt20QJ9HhHW5o0omDuHfH nj3uy7X2dl9qvLNhVls8mtoeL6aVe1LbkQ+e1WtWr15NK3/vOSrQ3Ttn1hz9nA15Q10d8c+9dUd/ /zmtR+K/99bheKcS6qpbHd8S6opv8db5/uGrYKdLO9CKtilsvEY7AVq9xtdzaVgroePSsRDiHcgA uuUMki/lV4sVG6b9CI19fG0+2jn21dXz/jd1qgPG9cA//xZ8huReOxsvvrb9T7TOoFfQKfSsll5E Q+gY/P0IPYzOoFfRT6Cfpih6DX0fHYHeveiH6HH0EDqIntBad2CCXoRdnkagq6967gR99zHoQIRa 0XK0Bm1Fu9F+9Aisuh76+lARqkDrUTv8/QsahL2+Ro+iB9FOtA54uBf1o7vQfdDzHHoHfY7taATb cABXkRRSRx7BqcRP7mZWw3megZM8TeaBZn0cj8Cqe+Fsz6K18IbdTBxlw5keIHEyBqd+AN0Io0it aq4MVpSXlZYEiosK/ZMK8n15uTnZWZkZ3nSPIqelpriTkxJdCU6H3WaVRIvZZDQIeh3PsQzBKB/H E4H7k3Q+t8fjaS+YaCdf244zmdKXnjiyXTPJfe2koynfaad+p512uX1zHDni9d7aOvrio6j+kziy x7Ejjugu2H4T7DRxklBntze0JJ5U2xmJwIo6r6TE6//snziKduCjRkOtt3ahoSAfHTUYoWqEGsyN HsX1U7FWIfWhyqME6c0F+XEbKIPMEE3dcXVXBCreOgAdRuxXRkAZ7756CMGy8UkIpmk1HOdr4zpt X2VJXO2Io13K0fzhgd2DEpof8Zk6vZ0dt7TFmQ5A6lHEZIa6mqEFO0OKdClxFvbVMjf0gD5QBqBN p0Ug99bBqr/bD91CbVu/Z1hTW/2huNUXvx5WXr/hvJsZCCUuUWhzYKBfiT86o+3qUQ+d097enliQ rwxoyqiuID/UXQOYTvQX5FMU4Euo6Yx007N0d9BzhrqVgV0LtbPu1s6mTQ11AWE6/rtZAwOhTm+o s6OTbgNvr42rzVqBmudQdCghQF1d+0TXxAQYYbWRSF074JoerGFmWy2MhrwddcCDlE8v90QmeqAj dGlQoeecFlcjcWWBEkcz27ywuIJmCyvQwIIKysfwGlyQ39B0ZVWcy5S8ysBXKI4j3gtf0BNf6emY 6OEzpa8QHaz31kcGBuq9Sv1AZKBjcKx3vleRvANHGxoGoqEI7NrUFsfQ//wud7x+d3tcinThSsA9 5YD6mW3Vbo8V4BhvNl1qImApYCxgYQAHsAC/aRMF0AI1t3mU2jhqaWt3AyLbaL0Z6uMlZSRg3Aqg 8QTaKI4WUmBhI1qfqHo8lDt3DapoPtA93jujbbytoPnuZ5Dq9wE9InRk+NKIs4WO9F4aubw84gXi PKu5f864PuvyT5QS7KGuyjhO+C+GF46Px+21bYybUIaHGnEztGbwgaRXxV0+qOf4BoAsp71xyRfn 2obdVe2KZAUNQKk3y9swY06bEhq4zAXjPROQUj4AVvd2dA1MiFgEmB4rQGAlrtbe4PWjKniNQjvq 46q3xq+NdH6E4sxHMABKo+aoF++ccVTFO2fNaTsuIaTsbG57hmBSG6lpP5oBY23HFVDDWi+53Evn KLSFGiirPkP02pD7uIpQrzaX1Tq09gJwTrS+8UnQh9EC8FS0PkmbBzQtAGuKETkNduhztJF5fKye S0APQEqHVMg8jt5j/4ji7M9RNnsRVbA+NBvKFvYl1AZr6thvkJOTUAUpRpU06V5HFbTNvo/a2Ytj v2a6tTVWJhv1Qv8G9nn0DL8bnYIygBBsTGMAcNQRj05CqaA5Ez1a93/KiObHsxAtgCty1ajuqvo/ W/3HToQAPo4RzmRGFiRCVGLVXmlDduRATpQALRdKREkoGbkRjXxStXEZfJ8AugU9hX34XnyCcOQh xgne5ygbZT/g1nNf8kX8rTpJd4furL5d/4xwo/CKod5wj9Fu7Ib1YDURBEIAFAOF4xhPWEST/60P 39KyokKP1WPNhAzDrL/1cuhbWgJaYSFGGyH7EU6F1ZbnyK8wcwb7LyD/BVjltQfwsr/U/AUGER6r Hz3N2sCLY1CxKmLCMKcQdsAAxE5kcOwz1ShI5SiRZoj4A36fD1X7iwr7uUm+/s0vCdiLWdu3n/6Y TeAd/z6kq6M7PwBH/oz7FeBrqRoSGIY1GI17GNYBNXPQwCax7ewSdh3LsTW3M5gxW8yVMu7mIibG xGHMmRiFKWRUhmG4B3le4I3MAxj5R4qrA/4LhdgfdgX8fn/Yp5PC58O+/km+zdJLuF8aLsrF5R67 p7y4rDyAPcyLF99Lx8W/H30j9akXlAdHX8cle5m/bu1Y+bcT9ITpCLEnuT8Dne5Tp4kscaawNuck 1s9lWAuSJzPVbDUX0AVcU5Mb2UauVlfnakxewS7jIs6VyZu5mHmVJeqMJcaSU6MiFkXjfXYdSbkP p9LQyiKVp0CpugFhilgoqmJEjIpcqpiSKjJEf2csASfA+P8VjOUJCTL2WwGj4Qs2V5DC5NPgvBDw h4sKwwDPVFxeZistyfKm8zovtALF4F4RHc/qPKz9oujf8/Kuv76+a3n771YYchq/XvX62cFP7hz9 za2Mcmbx3pUvYuOW+Z211W9mBJ8+8Njoxy+s+mUtkBAVAuzPg79uAG7ep1r4RKNUbjIZzTm2hHLz 4NgfjwnWcjPP63SDYx+p1YJYzus4g17AZI/OyDKMyRI01SAmiylj6pnZzEpmM6NjLKKl0iAB4YB9 RI4XsPl+jmN0PIP81bag/0IwWAykA1jDAY1wPkqx4eERSNBtC/r6pQ99Pv1wEUiKl/ECGXGACXjs mD304fyfzh+pKGH2Pf/Oh6MdD45k4SdG5+AnfsvccHE5eWxkHkD0HoD1JkQaVE4yVAf+FeH4X3HM mSiGR3dmHoc5f5hilfJ/NUgAphIAidwJUjA6Chmj4tRvj4BAYBSHOOYlwI8OLVHrMSFbxzlX0hXq GrmIjtVxOk4fFFjM1tzNYMRIl3GxFjChF/SVDCPoG4WVQkxgMLuXZygWRgABYQyg+ikCVgHrBoCP w+P8W4Q9IEeecg/38MiF0V+8hotGLmSxf+Ry/vYel/MDgDB77GN2DrsOJKoU7Vbbkd/uz3dm+isd Jf5pzjp/c96ivLV5xhRkMpemlaal9RWVOIqKSsqCJTVFZeVllbm5CUXPl/PbE1RbUnkCOpyXEkip TWFSUgrsjbk4NzfzUIFUIhywJ6DqC/5qiil60DAVN98F6ROrdujzvn7LJB8H4tZvqariXnqpqBCF sQXrLNjpSAiA3EENft70rNIS2DUDGBZ4N3sS9FzFvryO8TLd9//p5hnN8xfP/cnMDHe4MLBl5o4n elavwtU/4/VZXm+4ouVsnSEz+MHC06cF/ukT5Cbe6/Gsar7hxhnBB6XJTpf8wOYdxyqDAT4lN6Gw ymYzl7uHxKxte9xT3CMGwFcF4OtJ0Gl25EXr1JZE0Sdm2adYKlNCpN7ZxnQzq/Em/Xoxal/r3CSL HOhw4tqOhjINQlqqxdxnMpoygMuzjKXGkLHV2GPkjBmZGZXG4xkmlHzAKhk9B/kJXFUXYumTcZ7u lyg/A0dLf70QLgLcgKhq6MjWeYGdNfHFGk4oQpg0EOcy9slFLe0f7Gh/YEpSHC8e6g0/s/zIU6Nv VlR03TbrmZv2q+ubu/4PuXhk9L0lK9b7s8t5x8i71816Y+TO2afX3r51ZsnI1vSsRcCzs8c+ZRvZ 2yFua1dtAkOEJMYh1LhnuOe7Y4zeQiXZBmIuSa5DJikjI/UQSsjIEKmespmlclHMbcydlxvLZZK3 8ydy6PGpWgrAvQjwAk1Fhb4wl05pWVpiA9KCInLpvJOwRlwyQX7QVgEAmKR0H5kyWZ0/ZzZG985/ qibX6KjKze1Uf/rV3r7qLflFzXZjzuyfJhWXlTy85CEsLe7sKct801boTEgdHfzDnsMZTleJ+a3s IFCxZexjLm+CijvUOdOSp6V3szF91LrJzdscXq+HIQjjPmJ3EGLPCNprskgpCZFW0gOmlhJMAhtK JLKSxEgvuYfwhACFkwWSul04kWFHroOiRJQDV5Pyaw308KoJimrWxSJV6auA5YGkYO7KJzjcNq6P XXZmnMEvSwGXN3p4yB17YO7DxztbWz7b1n7wuui9tVundR2pLA0uWdv89HTe8c0XPbOnvPbCY1he tnRzVhY+P9Lr9XTObjzXtWFrczHV0m1jn7Db2E1wh5mNFqjFrE2yOGyz3BF3zBS16YTDqgu7XAb+ sCR5PKmHDAn1QrOwRmA8HrtZcCUzO+yUuEbQ3nZ7bvJ2s0ZVStQL1mBQE+4J2oKcrwKNGL7CmDg9 o1RCHmpqeJ3nMliUtPBjhjm2Z+tdH2Rj/rPRf8d34LSTb1jtF1/nuR8+vOLzRmNucdPUqRHy/dSc xKXr4veMTD37Ntw/HPvJv6Zta02tSNzzWGvZm7Y0UZSAa8FZYL7g08Bz2q62ruUwrzea+uwWs9W8 MhmrQpMQFRhBMCNREhVRSSwUCxPvTtQlionJYjIWk4LWmixzqflGc9jcY+bMSclJlWawbYd4J3Zi o95y2CqaQfOC8akOjxT7qTKjToMvQLnbH6YaLiz1j1uhIlDOwM8gmCL26DxggrzlgQkKMy8bUiNZ GzfKAp6VMfrjsyfPxjJi+tw/DVUvyuUWGmybtmUdvBhkXj2Y+dJ7Jj3Qzjnazp4C2nnB+zukLssl ARKwTvdNL54dWMYvnBQlMV2PNZYY9WzyWRDu82YE7LZ0W0kwvSbLVmoL2Vpta22craS0pFKyYWST bCttMVuv7R4bb7OVxnRYpyvYbgBwSdKJkuyDsoTEwgMJer3pIJuCwND4wchVg+6WvtaMHrW6E/xM oaXwUuUEsuMBiS4PaHoIQK0GXa7p7kucXa77Dmezp35bM/rO6F9bn57mM1ScbJ63w5dXKroW3r/u yOC8llmf74gcqnBVqv2h+Y9Vlk9Zdvusf5nJhi/Ko+dHv0lOOJE0qSgvb2Vofl3tq8/txdbuxZvy vYWvezLbG6ef6Vq7tb4UOKJCo58DPOlDx8rt9fZWO5M4OHZWnSOYy5OcuY5c5xJLl3ODZZ0zmhhN Eji9vg+zDoxZUTQ7HAl2yS5JfVabw2q1sVYbfh7kBScHbTVZ1lJryNpq7bFy1mR3cqX1eLLpgEuy Ic6K/IFxbE1o8bD0df/wuFnW6UHwweglalYPkOYDLgGhAO64osYvq3b2kKD//tB+k3nWshuPzT41 BOp829ITC/YdYW5NnCmP+Mim0sbs5pbmyosnQY2/1dC0n8p5JWS3cO9rvkuTWoIeIizXR3gdrw/q arL4Uj7Et/I9PMdTx0IUVCHGxwSWZx4mKmhuQnQiDzxOBRv4e9wr9gGZR8CvulCEwWu0g2dBbil4 tyA6OjqECff+iy+Obvv2CLhLgG+6+62a7z9ZzQZWJAxhg8w1ehTc9EqRU7kYiXEsYeDIfrB5V7YC bqJBALkVtB7uoqoN3qdRUtcEMjAJnVH3oRwyyTYpK0MpKE8vzynNKy0IpYdyQgVt/Ox0i5SbkUty JXufQ/EkuMpcu10/dH3h4nhXlavPddD1hOus6xuXzuXCyhVyp6WleL2Z6XK6LPcpHoeieFjFg58v nFcYLST+oKcmSylVQkqr0qNwir/QX6kc95sO5EvuA1mSR+QcClCdkl0Tk/+O8DhRU5irKFaHw1RT fIcHQDF+lyV0mrV3abmuSRAoY4g3Lm2MzyYC/72h/Waps6Xq3o3AJWQodcmPF6za47rj7UX772UW eaZnabwyJ/vGmW2Tk9SkkVKyaWpj7tzaKTMunmTDm6bNjLREWvZdkhbAcRK6+xppmQnSkutYYtlg oVLCXUHb/1BKxP8vUjKOkv8kJQD/P5ASgJUKCUHt4M1RW2gFjRpUcwQdI81JaJa7Ezpl6g3ok3mn SBIPiZLnEJ/gpH5cGjXw0tcXwJUBO1cN7hhYuEvuGHVhNMJcsXmXrBy77Zbm2ecPv/qbua2z/nL3 qfOjPy8L9m3ouL+irLJvY+RB8vbB0S8Wdd/+29cOYql70YYPRnY3vd2z+57wjMZ3bxu49xZExn49 2sk+CWelnme/Ol1kkF1mJLvXPlkMkbr02/BGfdQctW9MWZNusVik5OREt2Awmw2GPqPJYYREj58R XGfCppp642zj7UZm3Pek9lyCoNLoAgfUJKaBB2p0I8rDlIkhLB8PiAHiCeUFHgvVX9c4ogxoq3E6 6MajynEvFNDBPrm4pfX81jmHpi4bwh1D7vCzy4/868uaF7rvurXNi79XFqwgF58Y/WDRkvW52aN5 3Dc94Iie1ZzQfm96Z1Pzz8c5kvkcVIsNrVCTk8xlxnpji5E16SBiMhpBWQsGhyAYbBSWXIDFZnNE HdgeNNRkCaVCSGgVegROsDvslcJxO5iCAxBciwIoHGrVrjjamnd6WUVbqq4YbyqHEwC6mJOGnFDR rcdbnj05djJrx/GWovw85pBBaKm6+Ckb/l74Bk4HJ7aO/Y41QmQVRDvVVMHJFSc7ncWlgdrAPGdT cSSwUeopMBLFJJXDh9OP1AKorHRhS4nLx6YijyfncKqkQCTIGg+jBMt2VCKVKCVMiW+7q8TFKJdI piiTxcny5OrJscksA7EVaGtbEKJiGpBq0RbNrHAHAGzqG3e0qVl2aZZ5PITSPO+ycba94nnz4HnD LPhRX82C8YHNL9fkGZy1Jf71oT2Pzrwpe3lFT7SuVn1lfeer1TkG6bpi3+qpmx+88eaipcVreqaF rn/DPTXjdVtRosvTtbA0aBMSRM/mOTfvDJbVFmcOm/Nd9pQlc4tr7SanKXXDLTftLwuqgLPesd8z W7iH4Uv9XeotJluKLd9WZb/Z3m5fZtelEZZNdSe6Ulm2z5XicLlS5KAvZW7KRgg3a1yyIlc2okYl At/FYgrcU5nNSpILOSSH4mAc0RScQtISD6e4RbNZOGSFEAvoXh0AD84fpjYnEADcgTsDvE7vfibC UamqSgeJMjp4bpdEWYtFJmJR6szZAwyzJX100zqDNL0zd5XD4K2IFQ2Azd4VS481DDWw4cMjI9kL 06Zdn6J/3GJbv12pziFth/F1oy9QS7kBdNB7wNlJ6El1gaiX9Xn6acw0/RZdTB+zr3UJZWgaWU+Y xMQEuAPhtLAkCcKSJNFi6TObHGazqd281EySTGYakdBApY60kBVkoxaZGAgZd1XMNSbqn5gEyjsm EBEBmUXivBSjBKik0yuU8z7KRuH+YXqDYKExOQduCpR6GqyAQFwTq5SVA/SXEWNn3wNXIHXp8cX3 PC7onxzaL0izl0x/YcYwG/72CJiXvbvS1Vzyy5E7sjtTW1tbK5gagP8ZEMcvAX4e7vQ8udjHTeMZ juX4fhjj2DsYBm6hK8l0MpcswBwaHPuN6oTTw4dZUY+Xkk3kTnI/YQlhBsc+Vg0wwiCOMCJ1JkAU KFDgjFPBAEVN42ipf0Q/jGm8xQTgFujLkcoTLwzvIRn0iOBT9jPrYd9TcOX7AziTCb2idmfjfH2W oZJMZkrZcv0UodbQys4Wmg2LcTfpZBaz8w0byAZ91LDW6OQgQHYyNkHRZwtRfVTQG+GfBfrghaxe dwe4WplQBSLqBfgXApLJY17Mg5CSED0jGBheAy4FommE4NorZiHVXCM3j9vCreY5jovCdGDUCWhA plF1uDoMZW1zm2qIMlhhokxUz4TD7dQmaXcGkOmHgXs1cMchBqD5H4x8E4+OBn5UP5yKX3toOV5D gWfmXXwMEPAoE6GJcmYALM6fAQs6iKJK4OjgwwFh8A18G7+OZ4BAoH01AungkhriXVKNgmQamYPm khhcAjJwz/cb1Qok0ekEUdCIBbBqhDJTQnE6wugZEVNjA3BcRStb8Aq1wsN6+KNRFKYUC2DyCxx6 49TDJOGt0U78IZty8RRTDbYcjf0bpBvha/Xfe9KgkwE7b9Pu1V1wP1sOUWII1cO37xvQNDQdNcDX 6EbUhGagmWgW/G9QK5qN2uBb+By4Z6cPxEuQ6MPDrQ5qnzWrvanZ17rwts6OFR0F09Z0LFuyAP0H x3XcjwplbmRzdHJlYW0KZW5kb2JqCjI3IDAgb2JqCjY5MzUKZW5kb2JqCjEyIDAgb2JqCjw8IC9U eXBlIC9Gb250IC9TdWJ0eXBlIC9UcnVlVHlwZSAvQmFzZUZvbnQgL1NOUU9BSitBcmlhbE1UIC9G b250RGVzY3JpcHRvcgoyOCAwIFIgL0VuY29kaW5nIC9NYWNSb21hbkVuY29kaW5nIC9GaXJzdENo YXIgMzIgL0xhc3RDaGFyIDEyMSAvV2lkdGhzIFsgMjc4CjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAy NzggMzMzIDI3OCAyNzggNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiAwIDU1NgoyNzgg MCAwIDAgMCAwIDAgNjY3IDAgMCA3MjIgMCAwIDc3OCAwIDAgMCAwIDAgODMzIDAgMCAwIDAgMCAw IDAgMCAwIDAgNjY3CjAgMCAwIDAgMCAwIDAgMCA1NTYgMCA1MDAgNTU2IDU1NiAyNzggNTU2IDU1 NiAyMjIgMCAwIDIyMiAwIDU1NiA1NTYgNTU2IDAKMzMzIDUwMCAyNzggMCA1MDAgMCA1MDAgNTAw IF0gPj4KZW5kb2JqCjI4IDAgb2JqCjw8IC9UeXBlIC9Gb250RGVzY3JpcHRvciAvRm9udE5hbWUg L1NOUU9BSitBcmlhbE1UIC9GbGFncyAzMiAvRm9udEJCb3ggWy02NjUgLTMyNSAyMDAwIDEwMDZd Ci9JdGFsaWNBbmdsZSAwIC9Bc2NlbnQgOTA1IC9EZXNjZW50IC0yMTIgL0NhcEhlaWdodCA3MTYg L1N0ZW1WIDk1IC9MZWFkaW5nCjMzIC9YSGVpZ2h0IDUxOSAvU3RlbUggODQgL0F2Z1dpZHRoIDQ0 MSAvTWF4V2lkdGggMjAwMCAvRm9udEZpbGUyIDI5IDAgUiA+PgplbmRvYmoKMjkgMCBvYmoKPDwg L0xlbmd0aCAzMCAwIFIgL0xlbmd0aDEgMjI0NjQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3Ry ZWFtCngBhbwJYBRF9j9eVd1z9Vw9R+ZOZiaTTEImEAgJIRBJAwmgyH2YIJFwyS03oqIEFUFERXdV PFbwxpMhCRhAl6wirigLu7ruesKuqKy7UdYvy6qQmf+nahLA/e739+9JVb2uru6uevXeq3dUZ8Wy lbOJhTQRiWgzF01fQsQRWI3ivZmrVkQy51YfIfqJ1y6Zsyhz7lqI8+vmLLzh2sx58JeEDHxs7uzp szLn5DzKfnNRkTmnZSjz5i5awZ+Lw/8psscWLp7ZdT1Yg/Oxi6av7no/4dcj101fNBsljqu2I4ss Wbx8BT/DeW9kS5Ysm93VntYRYv71lP84CEWrAvI9qSK/IgbCiEpKyGRC5JfkbKLDOb+us0/9xb7n +k+zV/3LGDSigpAnvygo4uVbj8646qednXNUYrTg1CTa8wu4zzAoNZoMVclPO3+6URU1/MKFo2Av mSgVtsR94WOvST3ICSQm9WhOZIf3SgVSdvPAsNYmxVqcWaX2wT2lCJ5YIvII8sVIO5EOIMlkmpSD qyrytUhNSDuRDiAdQ9ITgpxfjSAtRtqGdAJJL2VLoeZIWB1cIPlxrx/jtUte8h1SGkkiYeQlSGOQ piHdi7QNSS/a8ZrFSGuRDiCdRtITTfI2398Xffc23yWKlvkLS8Xp9Mzp1AZx2nJVfaYcNS5T1lye aTYg06xPWaa615BMWVCcKZ35pU14eItiLW0f7JE8GKQHHV+CnLKDxE4pCZPtUhZJIjEJXRU1muRs yYuXbjsgyYRKTKJkFgmn2yXabHWUDlZYmn1HnCTMvmUdmSuso8XmKN02+Ar2V7IT6QCSxP6K31/Y X8hadoLjHHk10jakA0hHkb5D0rMT+B3H73P2ObGzz0gJUjXSNKRtSAeQvkMysM+Qq+xTTjEi53A1 EmOfIlfZJxjWJ8jt7GNAH7OP0+3s/eaKytK9AkiUdAHh/C7AG+wCnJ7SNvaH5h97gKLimGlQ1H4p lwwifaXc5vw+4TbJ11w1L9zGvmiJJMLbB/dmH5AkEkNPPsCbPyARpLFIjUhLkPSAPgT0IWlC2oK0 HSmJBCpDriJF2GGk95A+JL2RNKSxSEZ2rBmvaWNHm+NDwoM97HfsbeIFxo+w34ryPXZIlO+yt0T5 DsocXD/MDjXnhMlgM64T3KOiVFGW4LqO/aYlzxlOD3awA8BgGHkJUjXSGKRpSPci6dkBlts8K+zE Q/aTw+DhMGsmfxPls+RJI9Hmh7X4UBBghGfxAZcBQrYtsi3OtPiDD+OUZ/F77gfEs/jtmwHxLH7j OkA8iy9cBYhn8VnzAfEsPmUaIJ7Fx0wEhKyNPf5qXkG4YswCGhlsZ9cDS9cDS9cDS9cTmV3Pf+RH mffx0eaiImDsES3RoyjctI82vUabxtOmJ2nTbNp0C21aR5uqaNM1tClBm0K0KYc2abRpP+0PVDRR rfVnp5WajzYdpk0v06bltClOm/JpUx5titAKrY1Fmy8H16GoFUXLYM50LNpy2SBIHzuLAqNR0HwU MuEA8qNIaXGmoVEkN9PYn8PL3Jai6sx5rwGliwePYG/ixjcxDW+S40gyJuhNkNGbeMibeJwdeTXS NKR2pO+Q0kh6tM7FOO4VuR15CVI10jSktUjfIelFd75DVxhZjJx3cafoWAnyaqQx/Iy9iV8uflEW 1bLVkJpQR0j3hqg9h47JSeewCuLxQDA7HUZHG7Xu+bf1h39biWmwid3D7iXZmIgtXeW9zT9mh9vo 1ub4/vDgLPoQyZFBdbSSxGk+yv5kuTgvJyEjry8jIfYiytLm0GTcZm+OF4f3URu/a0/4x9DJ8N9C bQzgqdD+8J8ibTJtDv8RNS/uCX8QujP8TkmbETWvxdsoin0R0XRvqH/45cOi6TpceKQ5fAsv9oRv Dg0PLwiJC7MzF65ZjjPNHh4fnxIegefVhGaEteV45p5wdeiacFWmVTm/Z0+4N7qQyIBF6GyPkHhp LEc8cFJFG52rFRseNNQZxhj6GUoNxYaoIWzINgQNbqPTqBptRotRMRqNeqNsZEZidLelT2gJvuq5 9WLx04OgKZEFrELCUC5mkBNGjYxcQZIuaSQbOWEIHZlsn0lGzogkz06ItVFl3JSkLjaEJp0jyciJ Q5L9EyPbDOnxyYrEyKRh7NV1uyi9px61SbaxjZKJdW00zavWB5POoXV7CaWO9XcHeVm4/u76euLz rKr2VTsHOSqH1fyXrFFUNtYkLh6+i2DCl8hOPjhyQl3yhez6ZCkH0tn1I5O/mBCZWreXfk9P19bs pf/kRX3dXmkQ/b52PK+XBtXU149so5NFOxKh/0Q7UAwKtDNiYebtSMSYk2n3SKZdPu5HuzxeoJ3J RPJFu3yTSbSTKW+3a3lebc2uPGRo442Q5aLNcm/k0jaH89EmHxnaeJrIYdHmsKeJt0kOEo8JhdAk Bxma0AAJiSYhGhBNRM93iSYlXU3uvNDkTvEmKdMb0YZneIz1RHcb6wm0uQSR/29w9pBEgrYMrJ85 tXZ2rLYxVjsbqTF516q5vmTTjEhk18x6fiGSlOKNM2bO5eX02cn62Oya5MxYTWTXQHHff1yeyi8P jNXsIlNrJ9btmqrNrmkeqA2sjU2vqW8ZPras4mfvuvPCu8rG/pd3jeUPK+PvGi7u+493VfDLw/m7 Kvi7Kvi7hmvDxbuIoPGxdbuMZEj9UMwfL1uYWQG9Ngaj9UM86pJBgngHRn23BPdBW9lBzIn6pCU2 JGlF4nTdc3DPwfwSeIpfsqHa3nXJd8vAaHAf3dF1SUW1IzaEJFasXL6S+Grn1WT+luNA1YqVfCoy eYLX/dcDTWqT2vQarluPTBZNGJmsHjelbpfBgNrGmnrUDeiuM5tr29LtmcpeqBzAG0rShYa8rorX mUxdDf83LYg+oRrY2QtFY38L1XLoCrK8XkrmjJzIIAomTgEapk6p2wddii8Sy+sxwOU0QZd3P42P Q8AkU0Mw7OXdacXKLqgLFyu6StF0eYIklnejpPtxCY4skQlcrUhAtOn2ET9SQPcc8ctxAvsn/TXS KV6m5qVP8eu8ZN9A0LV1JUJ2kJfpPPIyOUDeoKdx106yl7QSrgLVkMfIGvJLsgHL2hTU3EnG46dD /S+pP90Ky+QJLJhPkCNoexW5hewjHupL/42sJeul93HXemIluWQwGUsWk7vplemVZCo5Lt9GKsiV 5DqyhDal69L3pO9PP02eIXul36Y7iZkEyEz8jqS/1f05/SnpiTseIA+T4/R+026i4S1NaPkrsow8 IjXIND0n/RN6ECXXow8yGUWO0HaWwNNnk6+pj66RhuIpT6WT6YNoFSINZC55hOyj5XQ4i+qmpkel jxAP3rEaT32YNJM9+LWR18nH1KI7nX46fZr4STG5HONpJb+j7VKqc12qGnjTAUs9SCWuLCa/Jm+T YzRGf8MW6yy6Up2muzH9AXGTPmQSevsc7vyK/pvdgt9a6ZA8LD2E2ICX+zi2yVvkLzRAS+gYOpn1 YIvZ49IyYsQb++A3i8wDvrfi6Z+DjPYwCzsqPSW/KJ/TZ6dOpG2YkTh5lPyK/IZaMdIIXU5vpR/S L9hQNo09yv4q/VJ+Xv6DYTpGfQ1ZRO4mL5J/UyftT8fRq+lcuoZuoPfRh+kReoyeYoPZRLaAfSfN lZZKr8tD8JsgL5dv092hu0t/KlWXOpj6ferf6dL0HWQc6GEdev8AeRwj20uOko/wO07+SnXUTG34 RWiUTqI34XcLvZs+SXfQ52kr3nKM/pX+DUvSv+g5hpWW6VkQyg9XgWJsGTTMX7LH2FH8jrF/sB8l r5QrJaRyqUqqlxajVxukLfjtlv4iB+Sjchp4LtU9qNum26F7UfeG7rTeYrgVa/x755/qLOr8PEVS G1MPpppTrem/kCzMIVYPmGBV6P10/OZjvh8Exe0k71MLcBegRXQQvRKYmUbn06V0NTB5O32EPiP6 /gp9DVj6E/0OfbaykOhzL1bOhrAx+F3DZrOlUMbuZ63sQ/aTZJDMkl3Kkoqk4VKDNFtaId0gPSgl pfekz6S/Smel8/ilZUUOy7lyXE7Iw+Vp8kr5cflr+WvdVN27ui/1in6R/g59m/6f0GoGGcYaxhka DPca9hg+MDaCOt8ku8mroMALBz0hrZNqpd3kHtZX9sOE+R3oeRqZJY1ioFS2g25kN9NWlqdbrR/I BtLR5LQcB64PsW3sLBsojaIj6QQyn/XJPFDvll8AVCW/STrk1zC23+HJq/UWegv7Tm8hzdCRKqEj vSX1lhPSu+Rj6Tg1yE+QT2SFemkHe04aCyp4XR6kqyNR6THyirSU3kx2s1pClHPGzaDj0fQFyIWJ tJT+IKWhBo8GFVVIX5DbyAL2Z9IBPt5IHqKz5DnkHtKXriFfk2fBFT101+mL9Fn0HTZP3sRctJUw +XmMrpLmUUnnJrfTBukR/XfsI7KSHJUV8rn0Enp/lL0ijZJP68bTueCAm8kdZGl6HblBVyf/gc4h Ep1M8uUTkG5rpFI5inItpMpUyLQ94O59kAODpVGo8YFyrgRdTIKEeAS/rZATMihoHnj8Kkix35FW /UTWRubobBRSB56ad1PjyZT0s+Th9BxyXfp+0hPyYEN6DZ64g3xJ7iU76PrUTWQJTMmPwNtX6oax o7ph6Z5sE/uITWAP/nx+ge186iPf4PcKZmaQbj/ZJP+JTCDV6c3pP4K6CyFhHyYzoLCexCi/xRtG SO2kb2o025UeJi3BeI+Tcenn0mGqkLnphWQMeY08Y9CR6YYE5jhJ/4Dx3kRms/HpFdLs1Dzg4V5g QQO2VkL+3KkNnTRxsFY96LKqgQMq+1eUl/Ut7dO7pFfP4kRRj8KCeH5eLDcaCedkh4IBv8/ryXK7 nA7VbrNazIrJaNDrZIlRUlwbG9YYScYbk3I8NmJET34em46K6ZdUNCYjqBr28zbJCL9vOi79rKWG ltf+R0st01K70JKqkSpS1bM4UhuLJI/UxCJtdMq4OsB318TqI8kOAY8S8BYBWwFHo7ghUuubWxNJ 0sZIbXLYqrmbahtrehbTXWZlaGzobKVnMdmlmAGaASW9sSW7qHcQFQDz1g7YxYjRiiEmA7Ga2qQ/ hlvxGCm/dvqs5NhxdbU1wWi0vmdxkg6dGZuRJFxTSogmZKh4TVI/NGkQr4nMg46TJHdFdhW3b9rc ppIZjQnLrNis6VPrktJ0PKM26UjgvTVJ740nfRdP8XDoZBsuvRqUNtX65kV4402bNkSS28fVXXJv MMqfUF+PZ+Belj+scdMwvHozZmok18WTbH19XZKuxyuhWOaLUWXGl9F68xvnR5Km2JDY3E3zGzE1 gU1JMv6GaHMgoO1NnyCB2simiXWxaLI6GKufXhPa5Sabxt/Q4tci/p9f6Vm8S3VkELvLZu8CLNZL gdlAeuaagERzDo0cfwGzlPcxdjk0wWRkZgQ9qYthTP15Nrs/2TSzPyYARz3FXclZmJF5SdPQxk3q AF6PIdKkLl+NRTb9i4ACYh3/+HnN9K4afb76L8Ivcjq5QGpJOr0bTiYSyaIiTiKGoZhT9HGQOC/v WbyqjcViS1TYz9xoIGOB2+n1A0qA/miUT/BdbRqZgZNk07i6zHmEzAg2E60EujVr5Ffau69kTeJX mrqvXLi9MQZKbuX2LMlKGuMX/uyqx1U7d0CSev4fl2dnro+cEBsJ1ThSu6mxi2pHTvzZWeY6Ryjw hmtdUNI1tE4KMtRxiAUlcTWjIXc3gbpcZ0nK+fjTC6Ke1WYwgipFDY0MS6qNIzJ5vRKNdvHM/99N benT/C5RXLytaxjJAYmujma6nRz4s/Ofdc+ySRo5ESKHQbPftEn52TWQWqaXl3cVoHgY+tHI0CSZ BM7Mxx9Mjv481QeTGlCGKxPBRaK6Pth1+rOGwa6b6nFw6uxZPAwyc9OmYbHIsE2Nm6a3pZtmxCJq bNNe9gZ7Y9OSWki7DOG0pffdFUwO21wPjM2lA8AejAzZFaMbx+3S6MYJU+r2wsUR2TixrplRNrRx SP2uPFyr2xshRBO1jNfySt4kwk/ISIpBNjOjaB/cqxHSJK7KokKcz4R3Q9RlGqGOkpltLFOndrdj qJMzdZqo4+PjMmboxLquaREEwVkPNIQIDR7DdQykF9gLZDDKffxcXk4mIR1HqkKajBRA4nWjkKZz GO326ianO3Vvk8f1lWSR/gWyVTeZmHDtClifY1EOQxqJdi6UQ5A20LfJRqTbOIxUw0u8dz3aV6Nd HsoAkh0pSgg6xxmKIPqkh+ZPSAR2UaZGVP8sY7A5ZNgKesRxjIjEKLBuLLCICCwA+89aYoJwOETu FHkmc10CXwTdF8EuKAulBzaYT+i6QWi7/MhGgrsafeR9zyUxlHlI+bAc+JGF3ziygtxPDtMdzCMl ZJ/8W90z+i36r6BL9zJJpueUxRbZusn2P/Yj6nOOO5y9XYWun9wr3N9n/dGzx7vVF/R/F1gX3BJ6 Mvt38JrhkTr8MGoDXuiIOvKRwcNGzkek9vOajpwjEbmd4/CF1Of0NlhsChm9W0HzF/VtdKwWp1IV Y1ShVURBOESqIvr+hgFjoM0uhm62HY/ebn5iqy+hnmk4c1LtqFKrSDXP1Q61s4M6nJV9evct75vl 1hsK+vWr2HNk7FWllf2kI0eW3hUf5Z9+Nd47mLax+WwRelis+ZewJRIbRUfhlTHCArolaOCXl9zt S4xWTzaoX5GSUR19epOltMFVHs0azHrQtt27ee/3IduA3kskX/Mx3tmqTBd3Enk7rm+XRS/PNjR0 oIOZTu07cuQIvxeWOKvUvY97J+wlUvrzZncla0t/rkXclQ9JlEnbpJ0IBa0iFJNMgVKJKNIpwk7R Nvo8Xi633IjxV6lnOlQ8u6q6aoOuV6LhZvVgn960IZHIon0pfX5Lqs6v+8dPeAIjk9Jfyw5dO6KI 2XTSLnD6xDpNCeTIOneO1eo1taVPtdrtbBIHNL/VCshBLLyGeCwW5BZeR0rgdTiC7AjGw0cU3KX/ 3086gyfp+ZO+arVaBfCt5jebATmIymuIarHwnNddeOTFZ7bqI341BNENIWT+NdQGD5ITyQ7H7QxZ v4FtNG+0v2PTmQxmH6t1XZl1hX9ocKJratZU//jgAsMC80zXwqwF/sbgDex6/SrzjfYN+q2GB9V3 fB+zD/Ufmj+xBy4MfLlJi8bKepsoMakmZtoSdiwnENeaDbURKL+MbMl5+y6g+mxDogPZ0gSfSj50 2rAUboT+/KBI9fUu1dmvb6nH48xSmT6WWxB3qZ6+pf0cajyWa9BPWvD+9lXNK4bMf/+JD264b+/z a9Y8//wta65oYO9TmV720rSWVPrjVCr15stbX6W/Sj303WnY5vO/nXcHp5XjmMBzmDuF7NQikmZ1 lC2Q17J72cNGBIOpieh1TDLpqIXRw4rovcLHRGgE98LZ3aqqmLq29DeaQ0xoSEyoTUwosKz5+XR1 z4mYn4BFp1ntZbpuTPTW0Qj8GUznN++jVXQ9ybDG0gTw0uWHAmaqRnWCEau9ldQBDqQNpCERjTn0 ekM5uLAvO9c6+P2JD/21ZIV806A14VeGH57Gx1YFWjZgbDn07S5aMjlUq8/l0k+ytqXPtDocAvhW M6kqoBy3LoeTqJc3yMnhV3NCNlzJAYEib2P7NQtTvF7Ejh2MRcKQBiUfHOH5EVLSwTtbzfODMF6C XWzAX2hxOpl4oWayOwBl3nNCMztdbFKOm9fxZzfj0ZxVzGY2CcA/NIHF//Y2ziP8ffxt4mVav4G6 gfr9ugP6/Ya3je+EDJdb6i0TbQsss2w3Om903el8zfll4Mvg6YDlgPlVFwsiFJSt5qj6X8P5ZADx G1GaMFuBHEU16vWHQwF3KBQwhgKQFsZASLLmqG3s6ZYxDopAkW83HwER6LBTZlGWe98Htjmt0/1s HVYClfbXLI7d1XASLWZrmcz2sTyEg+7dlSF2yJWzCS5eIFw6q6o7OhtOOpx8ZpFtsPVK2CBqMpJW sADngP6kgTYsq6/Pz4rGKzDj/fqVl4H0hRAGX0Ac6w34kw3nK5g3/6lHvtvx8E23Pkb3un74/ftn Rzz3xpNTc15+eXDVzPZbDn557YJfPLbJdfSjb16ue+G1pzdO7wNKmZz+SvaAUhK0vmvizH6fxqnY FyKUk2rCghPaI6ZY7RZ7jqL0yMoJyTk9Qroe1pjV4vNT4oxA9LBJEUOczyJvHi/hAu1ICf8RZ2V1 NRaRDlBLxyH1kLNSPZgo5QnEohXqrB5rrfUOq1zruMqxKiiN9yxU57tneVZab3DfYd3kvjP4jFXR RSQeXzKbLVabbKB4L5aap1s0DGA/zPcexErLWy2WLNm3jz1N/GyuVoBe6tBNq3P5tMjiCIv4OCVH mgzL40I2xSmJq3GGHp95lV+Jb+npa6P9m/3v0320PxaSds18UVoVt9H7u+Yw0SFmkcusMwmxBGEe MY0YnCrmMzOdYFWIMHArXVrvqvBwmSUmzlBxAeyeQz6JBg9yEsuNT24NP7Bg7c4nb+57pdtpXt52 x/x5m92t0W9eWX14wbWzbt2SOvXhb9L0Nt/DG5K3rnnC/ThbffPMW2+/PbL77TnNs6Y91ivn9Xva U//6CiI2ABmg6vZBvllpXOvnrLPMtTxied7yjkV3pXSl9Zey5ASNE4teMugUs2QgFjD7YUl2S5Is WQmzWGWDtB/hcyOUj+2aQmQZTchhRW5j176q0yladrhM6ZaEAPjCxCYB+FasUEobrdCsBi03VmZo ipYbttixFAOrVncZYSo0YQnnJ8Q9AE7u4bPAdtva6GaB6X8kEg1CEJ7h4qVK/UoVclA9U3W2ylHJ kVxZuaFXQgbL2O12oFtED6xY852VkHEfaOa+lVJuz0pJzs6u4o+ox2Sgjea2aOZKS9PYSosWr7Tk hlD2rOQNEvVQqMppX0ffrJhDclD2YOft7Fe/OHSoNVVOpz0j7Tl/xTOpJ8DUD3QuAOHxtT+qexYy dnKGcxB1xPisHAk0ZFNysrJCTi45zXZZzglZbZQYfFgvhEYgAMFlfN3nXMLXPxBR50FwBmeMHk4h e+0iHxm4IXtT9oOu51xvWj60fBI0mlw+W1FAMvXW9TbvgxyTwB2qS8lyulyHbXa3zeW22a1gEc3F O6LZttuYzWbXsmhXp161y/R9zj6QalqEd88xTV2srlXvVWUVTOITTOKjxKf6GDqbYRLflojzNVqO HTYPgKj6N9t2/zdmQeD7Uma5yC4NXKMEj4iBNjgqSxogFk5uMPZK6DCLBDMquAZ8sxTa1s/YBrzi imZFJegCJMttgCYQn/R61sMLb219efNVmwufv4d91PnqmNvva6fGFXef+W0nbVI33XXwyUeax1R7 2D9fSq2amjr7+7fvaz7BtbZRmLksyLxsUkTHdEm9sJ2G4aCWaLAwR7NSqxVLYlCXm+O2KjmU5KtA QUaDU3O8Kl/wvULmeTE9gLs0uCMfHFHf6p7Jhg71YAOfyZ4L/LTGoGXV+GsiU5wTIwukWYZZxvnO WZEVxpWh9cY7Qh8aP/A4DBHOAQUZntBPigmBx6ui4oKBXyiIxCJRfsHBeznWytDPIH1/Gp9ICD1T d5+hz/bXnGR3/nJVTKSKrUvQVzCK069yLVHdUqxwMZdDKzVPtXead7F3rVf2QinVT/J6+Eu9bSyv JZFR0sCJHXzlEjIvo6llJF1JA1fZ+CrF2YdLu3pqiBcI1Uxv6IfJcvIFKpZLHGoFzjzUfVES6qVz Lb7iyxdMHjxpBhv82pzWzuuP3f6X1Mlf3Xnq5c86K8bcM3rZ00/edOML8gTb/N6jeg/69tOZjal/ /2FTxy1wqq+hz/9mxxvnP2t4ob7t8a07dwIB0yHvPIjNWckSzXbQSmX8MaNsgizjXNibUdlksS6X JMZRMkYs0RIL2I3LTX8nYzD305hUjWIxXQvl0Q9BJKh4NOyhpVWjznSMVs9ybYxbBnz1rnQIGYTx LxUWjJ5IekOsn9NZMV3avTnVMbKffa906//cKf/08uYHUs7UubZPXqbf0Lcf67Yb/Fw/AwW+ktHQ XjWHwW75DjDbWaHqc64TghTAaa2QT43PIaSBQ2j6Dp+jOGEuzLHbwrYxNslmc5OxlIol26pCg6Oc q0HAOkGQBxMNpRAvDR2lQnKCYDnNqpxiP3vrgtZ2SScuyimtSAgqh4Uv8v/HW3/+rv94Fd508UVa 2YDAlR4tdrXnqti10kLPosCc2I2Bm3M2B+7KecTzfOC1wDeeryJnI67LPI97XvZIA3rM0rMCLuNi oHtfNKKPFOaMsU3jAi3Eh0ffH5sh/1beCWy3qSRmUL/j5yJsSzHniVbOEo5uBTzi0BzMsaWLymGK cFHFiZzT+AU51U3ipAG2KgwSsZgPYuVlBZyyURIQNrzy3DyJU6GcZbn5Ir/kZc+a6RNuHtuP9tu/ aM95ajh0b8dNN/7zyZc+Zu8+s2J18/Nrbn6CTlBvvO7KtX9eYvFNXkCNfz5O1UdSX6S+T32dannl gFT26J6Dj20GeUNq7YWqeQfiztz+7w+ZDc+HwcT0VbJURfUyrGSsIYRFgIsnjF12/FJOq9C8xJRj vezT2wULXkLaC4NZqj9y5PxzMJwZIsNEVw9dwUBsdM4earPDtsGi/H1rF/CDIETUnNHqOSGaQAv6 STqRl6i91TnGuaZGdaO0RX1Hd0jfrp5WzUZdPcKuY9W55qT6P5b/sf6PzSTD2yHbJIQudLIMTc6o NxgsgI2IL8J2b0v/oNmFFRUxWNy4xCRofT9oWbxOisgWN+4y5eh0xhy9pG9jSzQTduH+TYPfje2j ZkKpWXNaImS2QRo/FmHM47K0RaYy9jVp5rGWdsNxi7TFQi38XLUbjhrYWkOTgRl+Yf/wT8LrsdQP TsefDxgL+FVQga+6KtBRfRIuEPxxX0AC69SGXtgi1KWoQwhUblAPHrQdPLhBlykhEEYmzdj1kAPX bqtsl4yGfTAySPoHLifr6TK+tvEjBm9CTIpKrqgUL9AbJNb396zusxc7H33iI/rPh4flhvrq9v00 jL6WqmFT6IN7r7/7Lk4Fj2OmpmCm7Fi9vtRKImE61BjKzgEOHGqOnRi98YiJhoUCb4pwE9WkCA8E 1F/hhzjD0YkJDISz1YiwZUUrIJ9LHWHRnhU6GWp+gkotav4NAMYsnwyFLw6kIWfgVG6+Z0bSAHHY BXOFmJs2SH16D71B6ycFDdgjpsMuMVnv9wV8TG9WLIpVkfRZHrfH5ZH0QckbpU4bMp8xFKUexRHF Hg6aSBThWEcb+jqipV6PFx4AN7OxWH60tMsKwjoTfZz++OKUW+pXLB99431H1qd20cr7nulTO+qh haNfTr2n25eVfeWM1NGDz6VSz08vfblfn9q/PfvVv4v47ulF6a91e+EpyqcuLRB0B7NYYwG9xuii Tikvj0SdXpZPgFUuKiJ88JTqvTk2KZqjN1EaL8jPi0gSrIqCRqHGnhS4ExzD8QzgY4E7wTFBfj9b 1lRAC7LjEYUqQnwr/vjMq7nFDytiVMcotUEgswELTGcVtya61YgEUIlz/HEu5ioS0Fojx4KhQMgf kvSWuJqfFQ/HjfkI/uX7rNlR4rG7omjsdkUMOMvV5UdpyAz8uh3IckzRKMmTkImdMsAzHF5CQRaT yTEOo6U836GXY7l5EG/OvL6lssdr6MVgdsLYzHI7ZUi3Cod0JVt0b+rY9j+ntrW20LGfbKP0/vjO 6Iw9i9e/cX20/wbK7rvl9CBW/RLtPLFs+V56zZ8/pMtb57T9sveSplHjbh+zcdvB1A9N0yuoA/Ox Fb5pO+haZSe7tWlj+qxm5hRotFnhKQAuYVgAgAPlW62QQxYnv6yzWyRsxGdGk9lGjCammPWc8M3w iiEHGe/hrcwq6Perbq/ND93Efj5D7Hwx5C447i+rbm9Xjx1r50Z5Aqo4MJQg3S65sCHC/Wt6kUsi l0WuE7kRMlOL8RbMwnNMD597G88zMlMRMhPKXEak4oYftDDnqThcTRHFWWYXmc4iEWozE6ORMmFR 8acJgD9K2c8mEydwNVmzEvEiIl7EOVRIakL5WM6UwHYSfkxQEB8M1FE+GnFk9kkFtbWE2Y1uFjTK qyx3WH4LVFout1xul3rI+dZiW510tbzKutq2wWo0M52x0trPNoaNlKDOGkdZh9iUrexh6UHDg8Yd 0nMGvZPZbbbeOubW6ZgRmkpvnRGg0TLePp5qENJGo0kxm61Wmw2fT5hYo7PJyZz72A7YEn2adRFj G+2jKRaTEtEsa83UvA+DtFEzrrA2iHaTnZKIfYlK4ZGZ/GpE16hr0km6NrajxTGw3pfwc791Q5UP okhIb8CBCycnGyDLq6u4N/vCLwAJz2X6hpuFSEcBd/RF0f06saTPwT/0IZbHD4XkHpm0QKwXQqzv Jdb0D7tsCpfnXWbnB3uilbbiqDA991RU2korBLi7J2q7zMtEPWQ/WQp/Tn09hBr1ePtV0Kgj5sD2 JsdW7LW4urfHD0uT6vanJu9M1en2nfv+vhFjH5XO/zRMfvdcuXziHF/dTVgBLgenuNhurUfcSf3U Y2Y9nD1c/WmF1N/Y39TfOsBW7qxwKU5XxBktc/LMBqOhBSUsY1HCjyxK0N8JbSEuyLyVxLPr6fVm Fpd7GArNRba4s588wDjAzJ84wjhRbjBONU+xTXTOobPl+cYF5nm22c6V8o3GG8w3Wq93Xu+6Q95k 2KQ8ILcZX3Uekt8x/kn+s/Ej24fOr+VTxlO2r5zFeuExtYB5VQ/PzUaeQ87+0MKBLm+l2QIrT/Up UGNxwynNxiFVjy1CxKgwJmga0hAkLVSboNagNxhNJso3REhmVXVhi4SVqqrVAYPYDJwxq1myuBQz 1avMZVJcrggxwYNvkmBBRSyS22KRFJMJtgFzWa3wchhLYCp7vYGIBY5PqAzTXo0oW5R2RYJXo233 NGzvYSDKNk3Rt2rqWPWoKqlopCkR4ndnvRFt3AEdYfSZgH9UZ4PvS39HQ0cDgNG1s2u+akDnORFm 8g26UZdSILeBcdjtG2xqVZXx4KUFPzl48GA9WFqIJS6mu5lZEKEZgQ6zv5Lm+ittvmClE4GP5mCl K1PIQOOeYKUxN1iJuW9vDnHybNfCoUqXFqqUkKw2j7fK5fR4LzOaAEmQ+ZdBen6u9cLSk+usNFuy o5dRkh2tMiscYhyyuLyoc3lRxyEGqLtPmfJCF3Faj91fDUsRQ+mboX1AMaylegM1sYqU5WuqTIj1 GUoL3u/sZInTqXvD0T5ZqS3sPPt1auPK6rFX0fWdo87/yMw9y8fmpKAwYht5+pQckgdhl04F66kV m6ymIr81UNTDWlQEUZVVERxQdHlRg7WhaL51XlFj703WO3o84nk08Lw1qzDjcBYGN2IzXLw+63+h cI9/f+FB/9HCP2R9Vmis8VC4xc9osHz0k5xYa7pV3nLONZP4edgb9iWKi8oq5criy+URxZON9Ylr jfMSqywb4Gj70fpjwlFRZqOyWpJX5i2Nun3TeizuwXqESmzVtntt22xpm26bbaftO9hvIi4EPv1G rFEAoKpx77xN2Hw2PY8nwOSRYJm/sMf3APzUBsj7M1qA94PUFiilIcncY7o6nej5wkfyo3nwpYuH cQCON9TmyXwtxPlJ4W0HcAaAntd8qoFxAIkX4fy8UPry2tjVmq1A497SSLx3fGdcVwnCabXZ4OVt S3+4RwB9eJ1mzUGApLK9km2vpJVw5J/RBvMnevN9uSV5B/RH9Sysr9YzvY0rmnrhOdH7eH/0WMMy OfgdnItc6Ej6Pv27dUw4H2CeJVSYZ1CUGuB77TqqOhNffsmVpZOICmQcseIK2i8FN3GGgozwQm9C 5ASH8C2RpfnceIuXl3GXOv/BnIsLt/ogxsNN2GoFI84bi8Oot7GMPYdGUtWsvfN3vjZ8+YjyBR/P oX1rN669ITvpu+7YnRtfGKuavLmvhbwzDi6eWrpo3twn49m3TRr24vrR60a7bdZAXr5yXc/L6pf6 lt41Upt+Ra/Vp8+tv6w//awwpBaOKhnRePWYy66HdB+bPiV1gKIDdEqXZ6rMttZO7WaqYZ/vElh/ sjNkNvhCMvaDZhmMHP0GgUqDsM8NiP+hhi//iSMfHBJaJPxQ8Lc3CH/7cJOFhkNDXUO9E1wTvI2u Ru+j7FHpEevT6tMBi9HqV+azedJ83UrLEmuT9VnLbtMeZbfF4oFq8AWTbLnT7Ivta+2SHe73F7Qb eiOWN5Y0oltbEEA+QRBLIXa7GY6Y7j6G0PU8m5FPqS03iPHlmRNhijA/N8pAdzDFQCF0BKdhGuDN 6OWhrLyjBho2VMM4s/FGBoU3MggGNPQJlh3sMj0wxRnyaFjWtdlBuGD713csO5PoWNatQcPRqDac xB8nAS6B6qmXzz5xlInYotcQ51OfmWSpalf2d698nPr3sr/d+fKn4Z3+tVM2vvD07fPvoeu9rx6l 2VR5ibJ1O58ILlj45vsfvnErl0LDMGfHsSI7eBRYe1phsjXfWmatserK3eWhq9hEZbx7QmgOm6Wb bZrpbgy1hz/Q/dH1mf9L15fu77x/93+ZfSKcDnvC4USgylMVGBlYEt4Shr6dZ+3lGcDKrSNZrXWY +/LQVcpk6xzrl/qvPT/RMzaVZkk2s2onQdCDgyhZYH9fX+5Csuer6jEHVeHeaHQ0OeQwUM0mZYxC h5PrxnCBQKxxNnToOQU5hHmI2u/RFBh32DjGcf6tEAIAftCG8NlxrHDmHYDtfNyQNsh8isYYJEOO IDnByQbEvTlBimkTgssg5JPBn1M2NmPtcMoEN4/q6BRQ16nYZlB1ks8ZAmPVcPGDc/mEgV/J0mg5 51awa2bCHH0d8CR2h1T0Uv/ZB9f+ceX8D25rfLCkpTPy0spVz+y4afUTdzy++dxT26i0adxgZvtp GHO+d/g3hz5+7yCfs5FYOXLAZ1mYswmaN0xCWXAyNOgaTJPMs6UFusWm2WZjFpeTYtgAtPEcyg7x vMD5ke4n99mA3Mc5wN8nNNg5KjA4NM6JSHlounNRYHpotX511ll21qdiy77d6vWO9TR6luDj1ZB9 i7odjlhVDoYUA/bevMCDBkJIC1sTXlooOuCOB1zgcK+GRfpTYaEAyIRVAHwjJkWs36aCorIk3NWB MARwS368jJfaYC6IwzTs6avmGbS8orLumYKRgtnJzBQGAjjDYAheg8GE45fPVMWlM5UY1XlytIqo NNyfOEZlnGOJRJcbv6pzaZVQwoT3HkoJ2tCly7pZTIV3jDjchqhw/NKo8A7rpWv2FX+792+p76j7 0z9iV/v5U0rz+pmbOz9m4yz9J9+55nk62ftUKzzyEraQF6Y+T/2oRnbum0sfuGPo3GchRbBzhzXB evdSq5bjNlG7v8Tf249NJ/5HLY9Zn7caA9ZCa9Lf7pf9HB+FgXBZttEqWewhhWaxhNsl4zthZZub utMuTfbmy9grfT/EEkdin/5lvNQSoXDZFkL9GmcTv2YFmxA3Zx5SKBwluZxxSLFYawXj8JWMuDnl 436+igvgK+HMRc1PwvNOnvL5X6P7SJScxY5haIndoX6OW+AO0WEoh/BAdUBRhMXCnSkdcDMJs98N v67JoDdiDVVNziBx6O1B7PpOFK1bRxPgk2V9HbHyvuVliBL3LYVY41Iti0ezmrdtcwVuW3Xl1GD/ 0vE1R49Kj2xeuqBs2FXOXynDGmdsPn8tOGJIapz0DTiC+6QXa41ms85dbM53X2mudetN2f7sYnPc XRyrNPdzX2Ee5p5sqDPPNf+k/CvL1itWXDAoNqjgyoItxduLDf2i/XpUFw8zD4vW9pgYndhjnmFm dGaPxuKm4o8LTkW/jX1X4PB69FltbFdrYchlECuJGiG9xTrSRNrJMbgh29jNWqkuFLIrtbkhi+LJ 6pvfV8n3+Y55qerVvI3eJq9cDO8Am1QsfF1eIdaEziHEmleINR7KEFsKvsmINd6Khza6xBqA89oV nJ+9K+w0n+SG8w7Yj9qP29N2OWyvto/BQic4xg4ZxibZc/nT7CE+w5mwHK8H7E8Ur4hy8QaVn09j RrzBmfwfEq7z5FkeAQPjCOfyyWr4yMSGl6Ve7uDiTpV+BRB03OnCJ7C8r0NET+KuS4TdtTvNpUNX 3LzRZ6Orkp+cvu73d79247OzP9n+628efvbmNTtevnH1jrrAuPzSWVMqknfRqs+2Urp5a9P5+T8c Xf2iVPT79gPvvXnoTbiS8Z0Akfg3S246fS82A7W3ZHnLRJRdKGD5cjm+e9hnlUXVAK+/zGt0WBxu SUeJPaQzuOHGyzdpffuVpU203UQ9wDCb5MFyDjdjocjdnEFgbPxDc3DEwf0LJJoCvB1q4dvhiDSB pZDzBQYKKiC4K8X5WXhtAIz2cF70lvUrS3pOe9gSz3ZP0pP2yB7mzhf8qqnow2mMh0RAOSewH447 LgWfAtC8gkvFq4mRv5rIXRz6k+YRW3QYfw8sS7ycjM4ajmm8oHPyiBcYkCudF/TNzPTyDUt8ncIy VUm7nHI2vc2Qb9NbgtRqBF9iS0UisY6AqWkCMWUHZhRBfpj7IkSgz3JsaL2lfdUrI1tXLhh7d5Vu X+f39zc8/VjnNPbEhpsm3HNz537w5EZMFC5B6zOQI9o1pn58BGNMW0zbTUlTu+m46bTJQExh0xJT k2lbV9UJU9qkhLH3Ct+OYAeTXrqFYi8TIgR6Q76OyNvk7XJSbpdPyPp2+bTMiByRj+FMlrnziOMN QBfe4G/HlMlw2iAXkg3XMpINQEosjQDOw2sDHMqjjf+JvWXAHhdj1ZkQBFfGOckvW5oQgQhgZWNr a6v896NHz2XJ8XMfc7q8DVmFGPMXe3RiwHzHVEtFf7FzqqWsPFP27pMpc/MzO6ryQb52XRgfLR3X yWOQndZJYd0SOInSOnyjzfc8ZgiGP0kI+CxIym2EtkNtZZdSTwYLnIy07EuoR2ChS74bu4R7BgVo mhZLMoAuXJDR8s9xAVJaBuku0CG4Hmf84JRxWyv39Hfz5FeQwR56s+bSSXoX26G2qV9IX7tOS2dd euD6tFZltpbdoNKt6jHfCV/aJ0eMbpvb4wRPUr3HqlhtFlueT/ChT/CkWXCjWXAj7PkubjSLqTXn 8qlF7ZkMN5oFN+L8xww3mgU34vwsIiuYYrNgeDNNwz03GnHJdi3AOdN32seW+Lb7kr52n+xDJCPL I3B9FhvNwHH/J0NmUHqRISG6OSsKhpQFQ/JXOP+TwUd7RZgug0DkwCoWTW4ZIl16ZDaxViEGdpFL PXqHSTEqBkQg1Di03yC1K84ubuXO76Xg2KV8D4jgV9iBgmPFUurY8OTKzxqfGKsqrUULRix/To4/ tLN2yajSmzuXszuuWzT4/vc6X+O6ZQ10ywLMopX46YI9WWLnEdwwpwS/2Lk/azkfnF9ccBoUv2W4 foRxsr7eOEc/z2gsUwc4B3jKfbXqSOdIT61vqm6qabza4GzwjPct0i0yzVIXORd5Zvmup1kmvc56 tTRRN1G52rJQmq2brSy0KN6QbHBglXLnBcXaGBRkAJdz11ZFg1D2uwxFUJRwAODyadE/AfB5EACf CgDtmisvv6w3onQG1RCByt/neJAGef3lXNUEbMsjFhuPHzmFQiRsUYJOoEaomESsKsQiGEfsMyAa HhnmMUvSJ8BVTr4btPvogMLZgC2+3eeJiztEuT3A9/GYJugmmGboZphkOFSFN9slNhnAcyisu0sX zZqn73zrE+q56e93HU917G3ecEdzy/oNzfjUreCeVam/dB75+600h1rfe/e937/17mF0aENqnhzF DDqxQ2KGdo9F7alepo5U5epIMsLCkR6WWHZpVmn2kOwlkS0R4wDvgOAV3iuC9carLVO9U4NwjFrm qYu8C4Ltkffdn/k+C7yfc9J9MudEJB3xxOSEmsgqlweow+Qr1Cnql+a/Z6dUs8MG4yAEV5jeE4Lf 3+bPO6ZQVdGURqVJkSNiCiNiOvlOK+wpAq4VMZE4zwTqLo0TZHYLo+aUFuNzqKygrr6srzOfkHZK t9DtNElPUzlMq/F1rATT43xG1lERNKFibwsVrgQqbDm0OIvFAeY5byoWTioiGRTzjVp/eHiFj4po VveUQeDxYBb2kl9Qg2Cw84C04Mcu6w6tyFIXZ7fM+ugWYfQCh3SJyrPh6QH3z914bP7K4zdNubeX 49lVq198bsXyXal5utc3jRu3Ob31qdS5u64c0HlOevrIwXf/+O7hP3FZuh6seAhz6CDvaANLXFSV aUwuk4fi49tr5RWy3uQwmowmq8thshLJSM0C+UQxFW4xUmNuxEVdLNfxf+sYF1aJHzTHJauEXpA8 kCSwBdF3pkvNyARohCeEjHYO7/ZhCGxBbFV1wkNxZhkMYIEdHlgWVhVR39lgE6GJhmU8FppBVEa3 RyzOsf7JQfOqr75m0JAhA69x58jxJ5aOGPBcwfDqxmWdH3AsVMM3sQtY6C15tZvkXHfuANMVppq8 ybmzc9eY7jHdnves68XiNySryRvweXuPLP7Qqwsi1sbUUqr4phqnmqYqU81TLVOt843zTfOV+eb5 lvnW1nhrgb0gnleQ16Nf3hSl3jwrPqtwRWxFXlPeL5THLPcXPlT8QO+nlectTxU8jf949VbcA3dr ZjNLbjeA/U2ZmrxuQLThxCracEC04YBow4Fs7pB25lROMRbkWxQ5EIlnyeZe2QHujsr1F3Pkh/3V /jH+af6d/qN+vd0f9i/2H/fLYf+9fuZ/HeIoC3QhrG4NGg3CEDw0peL7aUaoim8CINRa3J4yXmqq zVFGaa+p2QuzWXYoy4D1l7tLhYrEQ4nQeTgzuri4lEO9zOEADeT5NZevrJTfXiIsR18m52LRD8GH HBF3SP8Iv8sv/Jx+YXn74WptNuQV4dbdocpjRRTQV9Ar2CQAmQ8JBMDxAOCbPZzzigLiVVH4ARpL 20tZdWlTKSvlHoQ8IsRD18cBkQyWsUuXA7wDHMjsUo/k2QWr20X37BFh5nD1B12EwSOil10GT+5x QqvxkSsj/j5dbgK4crqUY74FXIWkXja6y02bSCyFv+Ci6ix8cmhU3bEUEW5uJi1LQDyIAroh/rpc tQhxawU9c2IwQeMO1am6VEmfa40EianQEKS6nshy3DiN2mJBkovtwMYeSpAWFpgUfUIOkrCazVf0 TGRbhLdFGKIosW4dFPLug/sCEZG7sDu3IF6AL8/LYIRllv5utyC3zbw5cALzZSVe3Wy/86Y1q8vz f3Ho4TGD+xfdN+Hm16c4kpbl89bM93hKgrcfeGjyvEM3H/2IXhZasGx2zWUxX37p5etGD7+hMJwY cdMc3/ip4ytioWyXktd38JqpU7Zd9RLn07z096xI9zC+MvrzXqKABmPxMh6o0QYDaMIma2qxKlQi HtWUsCtYJCSzXc0ludTqzLfQtMFYa6ptNCzBjpYtBplgjd5uSBraDccMeizf32LC4evhM89nFMD3 woEPgMeLRc0PgtJQw42nzOrPVxlAQnLhQkZ/Mexj84mP9tt17aWGEqZSfDQEY+nkGW7k8h0gDmxX cPTtq77DFd5EIt/L8Rcv5z4KR4XYZSu2AzI1cGXVjIXFt9/esnu3K1GY88Q2ddDsJ9nMzdSwMHX3 5s5fjCrGZmZKkEmnsANKod90+ca9OiNRjHqqV4jOZNRRpsvjA9SVJD7DvrYjeDmXp3ypCb5arqMk 11GpcAlidVSaoDKXGXmGjQXftKAEy4sSLf6smXKiZaQQGc5OaSZYGcSDDGcfa7cU9iojEWR2Sw9S aIorlaRcGUGGK5Ox46neWGe6ll7L5hnnmVYTBFPZDcbVpuuVDXQDu0O607DRuMn0K7LVdJ/yEnlS eZ28atilvEPeUj4mf1T+Qb5QzpEzSjGGo/iIRykkcaVCGUM0bJnSnJ4yHdTysu4vOjAePnSCPp3R 7FwYKPyDImjQwAWvE0szx4qoZTqdxQwWK/ksAdwgHUkcSZCS6mrU8W2qFYrBaMw3KW6TSYE7jGHp c8MlplMULIpGI77j0hsUE7Yl6EqwiyrXqGkarE5maqPB3RrMLKYDpJkiTKO55m/+wKkDgfhOBD4D vo6TDXgLyKHyQvTTUfnz4Hs9nL1d0ZluBkWks6E+Svu6eKTchWjhK6mFvz6Zj4jbP/amrpPjnbfP WTxxFduYsRvxzZ/0T1CHSj/too4sOzXrZWaCu8yKQdiFJLaXYEsEDgcPCQVftTupHQFTRJk/18b6 K6fYH5QfND5se8TermvXtxvetZvsmqcyILlMWdaAWk4HmNfRe8zGEudVcr2h3lxne4huVbaaX2Vt lt+aD9veUz+W/mj6vfUT9UvF6bwYzXY67D4r2CoTzeaQXUSzFYXp/3c0+1o9NuWLeLYe2+MQ0bbb VR7Qttut6oVotqro7cyuqIfIIRNT8y/Esw/BHZx/aUhbD50OIW1ljJM6L7feYslV7NP1pls0hLKD r2r6sfomsZ1uqGaLSLew3DHgtMsda4SC0nAmM4WYQfVLfLfyv6LX+Dyua/8E/0xOhK8RvBaB64OZ HIVBBLOrMMN8t0SrzZddCZMSweps7L/3Ype+V5w3RyuxQbldU7IQb45WmhCT7qaEemGWgTwa6nn4 GPK4X0UFDx9LBdROb089/JeneoWK81v+lLqP3vXZxwNSf2OFNPXj8N5D+p5LWTp/R6+oTzVgXFH4 OL8FjQTov7toJFtx2/FPRUJ+u1Nv1rs0Jzx+miXSRSv+kkTgs4DvCLYD8kIoZyKWGGyx47/J8UEs ClUWuifbdyr4hEzDhEQKe5epPMPWRqfH6nMWmAssBdZ+ln7WctvDDnOhs9A1wlPvrHfVZ81zznPN y7pBv8p6g+NG941Z662bHJudm113urcqO8yvqfsd+9zfKF+7/2XtVH90p0M53RTlcZlDQdleY78d Lkr/he5nlEdnZYNQHcHSdrtFdTid4Ge/2+XKdypunOAzHocl36xA/VFcPKxt1vPxk5AaYiWhAyGG /0hXvdsOXGjuNjZRM1c7NSeb5jyA3TptdMgeO80ltUGFXxLYwga53pYxFmmsJS32SgxpKUHUD89o DUbWYJUA8jr5vkoQEd9W6VPPnPTjE9ClHQGf2iEgbM7BgsEXai4TjHyTpQ67LPnnUJykunZBjEza sP/Gh/03+7E35xQxp09h73l9F1ntJe7059h5o+Ri9w1k9u6sSkdulqAgUA9ECfZdgnxcBR7hZ0XM 96Jg4Z9QxXLXugcWV43wOuI6c2rRG58lcsOJL1pTCwfn9V4zuSw153m1MC+4wJ4tF3Y+vHLdmlVs wbnf7hxSP4Fb/OJIF+D/3vy3owCV+MeH+ErUAYvSRdzQQS9+TxzCTs48/E/aIrjAB+J/Pw0jw8kI /O+jK8hI/KelMfiGeDz+H8kk/Jfaq0g9uRr/PYSvhU4kfujxtTOZMHrcmMFXJAYvmzd94aiJ/x9n U3nGCmVuZHN0cmVhbQplbmRvYmoKMzAgMCBvYmoKMTYwNzMKZW5kb2JqCjMxIDAgb2JqCihEaWZm OiB2Nm9wcy1jaGFydGVyLnR4dCAtIHY2b3BzLXByb3Bvc2VkLWNoYXJ0ZXItdjQudHh0KQplbmRv YmoKMzIgMCBvYmoKKE1hYyBPUyBYIDEwLjEwLjQgUXVhcnR6IFBERkNvbnRleHQpCmVuZG9iagoz MyAwIG9iagooRmlyZWZveCkKZW5kb2JqCjM0IDAgb2JqCihEOjIwMTUwNzI5MTYwMDAwWjAwJzAw JykKZW5kb2JqCjM1IDAgb2JqCigpCmVuZG9iagozNiAwIG9iagpbIF0KZW5kb2JqCjEgMCBvYmoK PDwgL1RpdGxlIDMxIDAgUiAvUHJvZHVjZXIgMzIgMCBSIC9DcmVhdG9yIDMzIDAgUiAvQ3JlYXRp b25EYXRlIDM0IDAgUiAvTW9kRGF0ZQozNCAwIFIgL0tleXdvcmRzIDM1IDAgUiAvQUFQTDpLZXl3 b3JkcyAzNiAwIFIgPj4KZW5kb2JqCnhyZWYKMCAzNwowMDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAw OTUwNjggMDAwMDAgbiAKMDAwMDAyOTI5OSAwMDAwMCBuIAowMDAwMDMyMzE5IDAwMDAwIG4gCjAw MDAwMDAwMjIgMDAwMDAgbiAKMDAwMDAyOTI3OCAwMDAwMCBuIAowMDAwMDI5NDAzIDAwMDAwIG4g CjAwMDAwMzIyODMgMDAwMDAgbiAKMDAwMDAzMjQ1MiAwMDAwMCBuIAowMDAwMDQ0OTUzIDAwMDAw IG4gCjAwMDAwNTk1MDIgMDAwMDAgbiAKMDAwMDA3MDI0NCAwMDAwMCBuIAowMDAwMDc3OTYyIDAw MDAwIG4gCjAwMDAwMjk1NDcgMDAwMDAgbiAKMDAwMDAzMjI2MiAwMDAwMCBuIAowMDAwMDMyNDAy IDAwMDAwIG4gCjAwMDAwMzI4NTYgMDAwMDAgbiAKMDAwMDAzMzEyMyAwMDAwMCBuIAowMDAwMDQ0 OTMxIDAwMDAwIG4gCjAwMDAwNDU0MTQgMDAwMDAgbiAKMDAwMDA0NTY0NiAwMDAwMCBuIAowMDAw MDU5NDgwIDAwMDAwIG4gCjAwMDAwNTk4ODcgMDAwMDAgbiAKMDAwMDA2MDE1OSAwMDAwMCBuIAow MDAwMDcwMjIzIDAwMDAwIG4gCjAwMDAwNzA2NTkgMDAwMDAgbiAKMDAwMDA3MDkxNiAwMDAwMCBu IAowMDAwMDc3OTQxIDAwMDAwIG4gCjAwMDAwNzgzODggMDAwMDAgbiAKMDAwMDA3ODY0OCAwMDAw MCBuIAowMDAwMDk0ODEyIDAwMDAwIG4gCjAwMDAwOTQ4MzQgMDAwMDAgbiAKMDAwMDA5NDkwOCAw MDAwMCBuIAowMDAwMDk0OTYxIDAwMDAwIG4gCjAwMDAwOTQ5ODcgMDAwMDAgbiAKMDAwMDA5NTAy OSAwMDAwMCBuIAowMDAwMDk1MDQ4IDAwMDAwIG4gCnRyYWlsZXIKPDwgL1NpemUgMzcgL1Jvb3Qg MTUgMCBSIC9JbmZvIDEgMCBSIC9JRCBbIDwxNmRlZTlmMDg2ZjU5NDAyZGE2NTFhMTM0ZmY2N2I1 YT4KPDE2ZGVlOWYwODZmNTk0MDJkYTY1MWExMzRmZjY3YjVhPiBdID4+CnN0YXJ0eHJlZgo5NTIx MgolJUVPRgo= --Apple-Mail=_B875ED9D-FF16-4C45-B76C-49733D130623-- --Apple-Mail=_69E2A66B-0AB5-4C03-957F-CD630E75FEEE 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 iQIVAwUBVbqMnkayAOS/EQ8MAQK4Hg//aGhQRv6i6jdutmHxTHCOHX1DS84BkT5k V8TNcVKmC5/AfcGkK1gimaSr1Q//qacdEVhW/B4gs59uDxFrwyLQcCa/KWD60We4 b3CVsCEvXFHdylr7qTGn1qkqn7ug3kIOsM2y/eLV31HVMfzu0EwZHsbU7fQ7hgUJ 8WHXAq1NGoXkJa1jfpIIHob+XrgBuOSTssH6BerHk9hG4cu7FypJ53/W9y2qwOk/ 4XXkjN1gVmauZS3TwzxHJz5HJ5wXy7P3NeBGzVq2tYjpM5/57zPov/kNokNnvmRE VMddAdXUnhdp4jmo7bwFWGeEZ6neO9F0Bep2xmVT8Q4bevXOpONtYVFJwI0xmCZH df++fS/BBuXQJbH9CkykvZ5mVY4UnWiZnmD8NfAbisT3lnKMf/CIlVmA3iBnj1JL QsLvDDas29IiUWd6ZWyTYi2hWTdoYFUmU1V8JO2gBTrOUbahtnpxEoaWDLWFfgDj 5P6WY6QaWlt6EjtEHVCJSAZBgnXpEoM0jEOAAI2HhHHB89g+ROK1xmxZrQWXjX7D VUynUKfQ08EKx+g+sjFkwyQ0z1IiwFGFi5i9bfPJXpUxMH2Gj/hzA2BrJZztod+e LPwMBAy25wFXU7PujLWPqFCPImLz/D47KpMig5CRkWuaY+0H3Puodr5JoDtgUSCP 3ngsXZ5SXn8= =IW6E -----END PGP SIGNATURE----- --Apple-Mail=_69E2A66B-0AB5-4C03-957F-CD630E75FEEE-- From nobody Thu Jul 30 13:58:10 2015 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 3EC761A904F; Thu, 30 Jul 2015 13:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.511 X-Spam-Level: X-Spam-Status: No, score=-13.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_BACKHAIR_37=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 P84tSwZrt2ZC; Thu, 30 Jul 2015 13:58:08 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FEB11A9046; Thu, 30 Jul 2015 13:58:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1478; q=dns/txt; s=iport; t=1438289889; x=1439499489; h=date:from:to:subject:message-id:mime-version; bh=HsrA8YTEcWcRTqWajoyXXGO6ukyWmKsZPE7ssL0u2DA=; b=HSAzor+Uz5qm8c5Ys1UlpJT/itlifIGrUtp95W70G6fICj39T3cp2mkG FzRtqmU6EJvJJeHESOAyBXAgafXp24GNZvhNYkZ3wLKLBJchjgoiHRSRb 99zYsFCCn1CK261z1DImsM8CAypX2W3yS3Ww/zneC7vwIq9/BCX4Yz/Wg g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CbBQBij7pV/4YNJK1cgxq9Z4k+OhIBAQEBAQEBgQqEURN7NAVKiEDFPAEBCAEBAQEBHZUIBY0/hziMRwKZOSaEHR6CfQEBAQ X-IronPort-AV: E=Sophos;i="5.15,578,1432598400"; d="scan'208";a="174050088" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-4.cisco.com with ESMTP; 30 Jul 2015 20:58:08 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t6UKw6bk027740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jul 2015 20:58:07 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t6UKw6tf019267; Thu, 30 Jul 2015 13:58:06 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t6UKw6x0019266; Thu, 30 Jul 2015 13:58:06 -0700 Date: Thu, 30 Jul 2015 13:58:06 -0700 From: Toerless Eckert To: v6ops@ietf.org, behave@ietf.org Message-ID: <20150730205806.GI1667@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Archived-At: Subject: [v6ops] protocols without need for ALG ? 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, 30 Jul 2015 20:58:09 -0000 For autonomic networking (ANIMA WG), we are planning to rely only on IPv6 for initial autonomic connectivity, and the question of connecting this (at least initially) to IPv4 only NOC equipment came up. Alas, IPv6 support in transport seems to be still weak on a range of commonly used NOC tools. If i understand the NAT RFCs and behave output correctly, we primaerily want ALGs to go the way of the dodo, so i was wondering if there might be any crucial protocols between typical NOC equipment and network devices that would require ALGs. And better of course:knowing which protocols would be fine without ALG. Are there any lists about this (eg: what requires ALG ?) Wrt to what seems to be important between NOC and network devices: FTP - NOK (requires ALG) - IMHO not a problem traceroute - ?? (initiated from v4 NOC) ?? telnet - OK ping - OK ? SSH/SCP - OK syslog - OK TFTP - OK ? radius - OK ? (i ran some tests, seemed to be fine) diameter/tacacs+ - OK ? NTP - OK ??? For the following, that have extensible data-models (MIBs/OIDs, XML schema etc.), i can see that some NOC tools relying on them might not support data-models with IPv6, but that would be "fine" (aka: can't manage everything from such tools, but transport stack works): netconf - OK ? SNMP - OK ? Whats the next most important NOC<->network management protocols... ? Thanks! Toerless From nobody Thu Jul 30 13:59:23 2015 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 3B0D51A9071 for ; Thu, 30 Jul 2015 13:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, 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 0-qRA9m2tHKr for ; Thu, 30 Jul 2015 13:59:20 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 41D9A1A906C for ; Thu, 30 Jul 2015 13:59:20 -0700 (PDT) Received: from delong-dhcp229.delong.com (delong-dhcp29 [192.159.10.229]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.2) with ESMTP id t6UKxGFK009665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 30 Jul 2015 13:59:16 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Owen DeLong In-Reply-To: Date: Thu, 30 Jul 2015 13:59:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1C136157-83E8-4581-A11D-DA999FB8D422@delong.com> References: To: "Fred Baker (fred)" X-Mailer: Apple Mail (2.2098) Archived-At: Cc: v6ops list Subject: Re: [v6ops] Charter discussion 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, 30 Jul 2015 20:59:21 -0000 second paragraph of =E2=80=9C4.=E2=80=9D =E2=80=A6on possible ways how to deploy=E2=80=A6 Suggest delete how leaving =E2=80=A6 on possible ways to deploy =E2=80=A6 Next (third) paragraph: =E2=80=A6and the primary intent is not capture = the=E2=80=A6 Suggest add the word =E2=80=9Cto=E2=80=9D =E2=80=A6 and the primary = intent is not to capture the=E2=80=A6 Otherwise, looks good to me. Owen > On Jul 30, 2015, at 13:44 , Fred Baker (fred) wrote: >=20 > As we discussed last week in the f2f meeting, here is a proposed new = charter for v6ops. Comments please, with proposed text (e.g., old text = and new text) for any changes you'd like. >=20 > ________________________________________= _______ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Jul 30 14:07:59 2015 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 573321A90A5; Thu, 30 Jul 2015 14:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, 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 37g7OXSTWeQt; Thu, 30 Jul 2015 14:07:56 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 02F5C1AC3BB; Thu, 30 Jul 2015 14:07:27 -0700 (PDT) Received: from delong-dhcp229.delong.com (delong-dhcp29 [192.159.10.229]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.2) with ESMTP id t6UL7N5I010514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 30 Jul 2015 14:07:23 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Owen DeLong In-Reply-To: <20150730205806.GI1667@cisco.com> Date: Thu, 30 Jul 2015 14:07:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <33A0B18B-5C9D-4DC3-9E0B-736D7ECA404F@delong.com> References: <20150730205806.GI1667@cisco.com> To: Toerless Eckert X-Mailer: Apple Mail (2.2098) Archived-At: Cc: v6ops@ietf.org, behave@ietf.org Subject: Re: [v6ops] protocols without need for ALG ? 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, 30 Jul 2015 21:07:57 -0000 > On Jul 30, 2015, at 13:58 , Toerless Eckert wrote: >=20 > For autonomic networking (ANIMA WG), we are planning to rely only on = IPv6 for initial > autonomic connectivity, and the question of connecting this (at least = initially) > to IPv4 only NOC equipment came up. Alas, IPv6 support in transport = seems to be still > weak on a range of commonly used NOC tools. >=20 > If i understand the NAT RFCs and behave output correctly, we = primaerily > want ALGs to go the way of the dodo, so i was wondering if there might = be > any crucial protocols between typical NOC equipment and network = devices that > would require ALGs. And better of course:knowing which protocols would = be fine > without ALG. >=20 > Are there any lists about this (eg: what requires ALG ?) >=20 > Wrt to what seems to be important between NOC and network devices: >=20 > FTP - NOK (requires ALG) - IMHO not a problem FTP should be long deprecated for the most part anyway, however, PASV mode FTP (if you must use FTP) should be OK without need of an ALG. > traceroute - ?? (initiated from v4 NOC) ?? > telnet - OK=20 > ping - OK ? Should generally be OK. Requests must come from translated side of the host pair. Responses can come from either side, but to be = meaningful, need to be responding from native side to translated side. > SSH/SCP - OK > syslog - OK > TFTP - OK ? Should be OK, depending on which side is client. (client has to be the private address/translated side of the connection). > radius - OK ? (i ran some tests, seemed to be fine) > diameter/tacacs+ - OK ? Should be OK, again, assuming favorable directionality. If RADIUS/TACACS server is on translated side and router is on native = side, then this will not work without an ALG or some other hackery. > NTP - OK ??? Same directionality considerations apply here. > For the following, that have extensible data-models (MIBs/OIDs, XML = schema etc.), > i can see that some NOC tools relying on them might not support = data-models > with IPv6, but that would be "fine" (aka: can't manage everything = from such tools, > but transport stack works): >=20 > netconf - OK ? > SNMP - OK ? Should be OK, assuming favorable directionality. HTTP HTTPs SMTP IMAP sFlow/cFlow/etc. Owen From nobody Thu Jul 30 14:25:55 2015 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 B38111ACD83; Thu, 30 Jul 2015 14:25:52 -0700 (PDT) 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 GqoqHQeQKH3a; Thu, 30 Jul 2015 14:25:51 -0700 (PDT) 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 97FAF1ACD36; Thu, 30 Jul 2015 14:25:51 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t6ULOUeR024306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 30 Jul 2015 14:24:31 -0700 (PDT) To: Owen DeLong , Toerless Eckert References: <20150730205806.GI1667@cisco.com> <33A0B18B-5C9D-4DC3-9E0B-736D7ECA404F@delong.com> From: Joe Touch X-Enigmail-Draft-Status: N1110 Message-ID: <55BA960E.7010700@isi.edu> Date: Thu, 30 Jul 2015 14:24:30 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <33A0B18B-5C9D-4DC3-9E0B-736D7ECA404F@delong.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: Cc: v6ops@ietf.org, behave@ietf.org Subject: Re: [v6ops] protocols without need for ALG ? 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, 30 Jul 2015 21:25:52 -0000 On 7/30/2015 2:07 PM, Owen DeLong wrote: > >> On Jul 30, 2015, at 13:58 , Toerless Eckert wrote: >> >> For autonomic networking (ANIMA WG), we are planning to rely only on IPv6 for initial >> autonomic connectivity, and the question of connecting this (at least initially) >> to IPv4 only NOC equipment came up. Alas, IPv6 support in transport seems to be still >> weak on a range of commonly used NOC tools. >> >> If i understand the NAT RFCs and behave output correctly, we primaerily >> want ALGs to go the way of the dodo, NATs too, if we're taking requests... ... >> Wrt to what seems to be important between NOC and network devices: >> >> FTP - NOK (requires ALG) - IMHO not a problem > > FTP should be long deprecated for the most part anyway, however, PASV > mode FTP (if you must use FTP) should be OK without need of an ALG. FTP has security problems but anonymous mode access to files is still used. As noted, PASV avoids the need for ALG in-band address translation. All the listed protocols should be OK if the client is behind the NAT (as noted) *or* if the NAT is configured to forward those services to a particular private-side host. Other ALG protocols not on your list: web: HTTP (mostly to hijack initial login screens, somtimes to insert tracking or ads) teleconferencing/media: Apple iChat H.323 MGCP (media gateway) RTSP (realtime streaming) SCCP (Cisco call signalling) SIP remote functions: RPC (Sun, Microsoft) SQL tunneling: PPTP --- From nobody Thu Jul 30 14:42:40 2015 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 2BBAF1ACE61 for ; Thu, 30 Jul 2015 14:42:39 -0700 (PDT) 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 MlJFGT94h0e4 for ; Thu, 30 Jul 2015 14:42:37 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 538FC1ACE5A for ; Thu, 30 Jul 2015 14:42:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2941; q=dns/txt; s=iport; t=1438292557; x=1439502157; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=bPvqKbQp4W3yHR5SFtnR7rrXkNX4j9BnX+SFqzy5iT8=; b=QS/kFWAwqqBLni/3xMbRAJMyQJa1jh/1Y6t7O54J0Ekr0HZZAxBQgmf0 fr1J9fCxnGut8mafyYz5MN05jJRPeMFCN70LCf3DCVw7Q/PRdt1bkECrC ucwrjTAWpPayWsFgD0JLHvx/iSmQm0ie0/R87/6fA2aqS9CL95Qm2mBVa E=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CaAwB/mbpV/4wNJK1cgxpUaQaDHbkBCYF5CoV5AoFAOBQBAQEBAQEBgQqEIwEBAQMBAQEBIEsLBQsCAQYCGCoCAicLJQIEDgUODYgLCA2SLp0ZlXkBAQEBAQEBAQEBAQEBAQEBAQEBAQETBItOhQcHgmkvgRQFlHcBgjiBWYg3gUeEIJNSJoN9b4FIgQQBAQE X-IronPort-AV: E=Sophos;i="5.15,579,1432598400"; d="asc'?scan'208";a="20179113" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Jul 2015 21:42:36 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t6ULgaSe001803 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Jul 2015 21:42:36 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.49]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Thu, 30 Jul 2015 16:42:35 -0500 From: "Fred Baker (fred)" To: Owen DeLong Thread-Topic: [v6ops] Charter discussion Thread-Index: AQHQyxCljgFeRyGRqUuZ0UjijE7vvw== Date: Thu, 30 Jul 2015 21:42:35 +0000 Message-ID: <490E55D8-E380-4F12-B344-A8642F0FD98B@cisco.com> References: <1C136157-83E8-4581-A11D-DA999FB8D422@delong.com> In-Reply-To: <1C136157-83E8-4581-A11D-DA999FB8D422@delong.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.117] Content-Type: multipart/signed; boundary="Apple-Mail=_69E2628E-9504-4DEA-ACA3-F93EF7EF3857"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: v6ops list Subject: Re: [v6ops] Charter discussion 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, 30 Jul 2015 21:42:39 -0000 --Apple-Mail=_69E2628E-9504-4DEA-ACA3-F93EF7EF3857 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 30, 2015, at 1:59 PM, Owen DeLong wrote: >=20 > second paragraph of =E2=80=9C4.=E2=80=9D > =E2=80=A6on possible ways how to deploy=E2=80=A6 >=20 > Suggest delete how leaving =E2=80=A6 on possible ways to deploy =E2=80=A6= >=20 > Next (third) paragraph: =E2=80=A6and the primary intent is not capture = the=E2=80=A6 > Suggest add the word =E2=80=9Cto=E2=80=9D =E2=80=A6 and the primary = intent is not to capture the=E2=80=A6 >=20 > Otherwise, looks good to me. >=20 > Owen >=20 >> On Jul 30, 2015, at 13:44 , Fred Baker (fred) wrote: >>=20 >> As we discussed last week in the f2f meeting, here is a proposed new = charter for v6ops. Comments please, with proposed text (e.g., old text = and new text) for any changes you'd like. >>=20 >> ________________________________________= _______ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops I wonder whether we are on the same page. If you're talking about the = two paragraphs > These documents should serve as useful guides to network operators > and users on possible ways how to deploy IPv6 within their existing > IPv4 networks, as well as in new network installations. >=20 > These documents should not be normative guides for IPv6 deployment, > and the primary intent is not capture the needs for new solutions, > but rather describe which approaches work and which do not. those are in the current charter, and not in the proposed one. --Apple-Mail=_69E2628E-9504-4DEA-ACA3-F93EF7EF3857 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 iQIVAwUBVbqaSkayAOS/EQ8MAQLLtg/+NE1h6q8qHcapQqesuz16ebRC0QiiDRhY HkFcp58nlz2OcTHOxDhHExTZDvHalju+B6X0zUcM1L+bwoYcaqJ+KRrAqAjlUCfB kUUOcQha31kuAN7RwqK/1a5mlKRwm02UzxpZTIfFPUjIlL86R9zEgDVDa7sRW6bb CgOV8xioN1M+iWIKQqLiKqveF4JTh1hpzP4zPjM+ZZBCAtwk/9Ldxs/E2Rler+h4 VsEIY7MHtqtQr3xQH/E+/sCVt5V6eBC4lcD4WiEa5c/m/0vMoKT5Nj1HR9+BbazR OO7thBzMJXkHRZsqS4luQn0J0c8jlwabcJxlikE2gxWLIBAZ9WB4mLkio4te/794 i9izGUPooVDOyArcUNn1NdJlRXByV43QT6XB38RNLVXky7Vcc8AM5fNVIgF7QfI8 snxE7X+gZxV3vlbk1VhMpofWOEyMM6uIhxuPdFHrnkLB9jXLKESvzpiIbfKJLlJ/ RPLXsYVQMz6TF4j+LPCu6hKegVsLMX8c47m/EDrcbHa9xmZ/Y5iWiziQRHYOgeGl tg4fahc9hCICMd1d63Be1OK8YjW/jRt3M5luus2lqZ9uiYuFsKiWUJuxTpGPbxTr uGkgpwHCzmdN8zcE+nWGyGwesERuJLxeeXalCPRmsi8zkSZ68wD4GwoxhryD5DgO qUyCRqVDt5Y= =OhSY -----END PGP SIGNATURE----- --Apple-Mail=_69E2628E-9504-4DEA-ACA3-F93EF7EF3857-- From nobody Thu Jul 30 14:43:54 2015 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 4EEE01ACE7A; Thu, 30 Jul 2015 14:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.511 X-Spam-Level: X-Spam-Status: No, score=-13.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_BACKHAIR_22=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 ywCvrZDZ6mco; Thu, 30 Jul 2015 14:43:50 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75E621ACE71; Thu, 30 Jul 2015 14:43:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1859; q=dns/txt; s=iport; t=1438292630; x=1439502230; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=YMvRodV82tkvq4Nl4Z4+SYTIr1BVpGlubw0pAP7njz8=; b=XPWZ5i7k9kDp1/nMCO3g/czNFTLkozbcwQKWIu0IgTcBYRDLidzmzo6o FGsCsG3H9qs6MBZCEctzpMPCH8cgRq4WNSH7YAyuDIHE4zRKmrfFfMFJE IyS6rrzVA91OcUBhRBoWPo+e+R3bL0yrdpLMdEg8xR5S7Myw4JC/JCIw5 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CRBQC9mbpV/5ldJa1cgxpUvRaHfAKBQDkTAQEBAQEBAYEKhCQBAQQnEz8QCxgJJQ8FSYhBxU0BAQEBAQEBAQEBAQEBAQEBAQEBAQEXi06EPEsHgxiBFAEEjT+HOIxHApk5JoQdHoJ9AQEB X-IronPort-AV: E=Sophos;i="5.15,579,1432598400"; d="scan'208";a="173575938" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-2.cisco.com with ESMTP; 30 Jul 2015 21:43:49 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t6ULhnjf018057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jul 2015 21:43:49 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t6ULhmXg026593; Thu, 30 Jul 2015 14:43:48 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t6ULhmd0026592; Thu, 30 Jul 2015 14:43:48 -0700 Date: Thu, 30 Jul 2015 14:43:48 -0700 From: Toerless Eckert To: Owen DeLong Message-ID: <20150730214348.GA23601@cisco.com> References: <20150730205806.GI1667@cisco.com> <33A0B18B-5C9D-4DC3-9E0B-736D7ECA404F@delong.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <33A0B18B-5C9D-4DC3-9E0B-736D7ECA404F@delong.com> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: v6ops@ietf.org, behave@ietf.org Subject: Re: [v6ops] protocols without need for ALG ? 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, 30 Jul 2015 21:43:52 -0000 Thanks, Owen Wrt directionality: I was just wondering about embedded addresses or other difficult stuff. I was assuming 1:1 stateless v4<->v6 NAT, aka: "directionality" should not be an issue... Right ? Thanks for the other protocol list. Cheers Toerless On Thu, Jul 30, 2015 at 02:07:23PM -0700, Owen DeLong wrote: > FTP should be long deprecated for the most part anyway, however, PASV > mode FTP (if you must use FTP) should be OK without need of an ALG. > > > traceroute - ?? (initiated from v4 NOC) ?? > > telnet - OK > > ping - OK ? > > Should generally be OK. Requests must come from translated side of > the host pair. Responses can come from either side, but to be meaningful, > need to be responding from native side to translated side. > > > SSH/SCP - OK > > syslog - OK > > TFTP - OK ? > > Should be OK, depending on which side is client. (client has to be the > private address/translated side of the connection). > > > radius - OK ? (i ran some tests, seemed to be fine) > > diameter/tacacs+ - OK ? > > Should be OK, again, assuming favorable directionality. > > If RADIUS/TACACS server is on translated side and router is on native side, > then this will not work without an ALG or some other hackery. > > > NTP - OK ??? > > Same directionality considerations apply here. > > > For the following, that have extensible data-models (MIBs/OIDs, XML schema etc.), > > i can see that some NOC tools relying on them might not support data-models > > with IPv6, but that would be "fine" (aka: can't manage everything from such tools, > > but transport stack works): > > > > netconf - OK ? > > SNMP - OK ? > > Should be OK, assuming favorable directionality. > > HTTP > HTTPs > SMTP > IMAP > > sFlow/cFlow/etc. > > Owen From nobody Thu Jul 30 22:11:20 2015 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 BBB0D1B30EA; Thu, 30 Jul 2015 22:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 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, 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 6QG4UCWv-zHB; Thu, 30 Jul 2015 22:11:17 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D59961B30E6; Thu, 30 Jul 2015 22:11:16 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id AF1B5A1; Fri, 31 Jul 2015 07:11:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1438319474; bh=kxHgYbmG2zuSoEQHDWzpmu/n2Vs/GeWjDM3rgXUCVjU=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=TqlkcY4yH2AuY4xSIs9N6G5qqHAlV7fsNoHjfhoCzbkVsjB62Yh8DDNT+702Nh9FM vx5J1NPu6Iy/HHGaPfAQptTNav243Uqkna1YzJTAtJLV6egkmUOZh9T4yMf/Kls5dX 6zhbqcT9sb/rwNtIMs0vDNRmXbFkR8us1y8lx4Go= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A64D89F; Fri, 31 Jul 2015 07:11:14 +0200 (CEST) Date: Fri, 31 Jul 2015 07:11:14 +0200 (CEST) From: Mikael Abrahamsson To: Owen DeLong In-Reply-To: <33A0B18B-5C9D-4DC3-9E0B-736D7ECA404F@delong.com> Message-ID: References: <20150730205806.GI1667@cisco.com> <33A0B18B-5C9D-4DC3-9E0B-736D7ECA404F@delong.com> 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: behave@ietf.org, v6ops@ietf.org Subject: Re: [v6ops] protocols without need for ALG ? 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, 31 Jul 2015 05:11:18 -0000 On Thu, 30 Jul 2015, Owen DeLong wrote: >> SSH/SCP - OK >> syslog - OK >> TFTP - OK ? > > Should be OK, depending on which side is client. (client has to be the > private address/translated side of the connection). There are ALGs for TFTP from multiple vendors, and I seem to remember I had problem performing TFTP download from behind a NAT, but I could be mistaken. This should be investigated further. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Jul 30 22:39:04 2015 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 E66A11B3109; Thu, 30 Jul 2015 22:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, 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 9Ats7XSVnR8W; Thu, 30 Jul 2015 22:39:02 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 49F501B30FF; Thu, 30 Jul 2015 22:39:02 -0700 (PDT) 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.2) with ESMTP id t6V5cvBe014853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 30 Jul 2015 22:38:57 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Owen DeLong In-Reply-To: Date: Thu, 30 Jul 2015 22:38:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <55A144E0-74BE-4A29-9A5F-782D7D660399@delong.com> References: <20150730205806.GI1667@cisco.com> <33A0B18B-5C9D-4DC3-9E0B-736D7ECA404F@delong.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.2098) Archived-At: Cc: behave@ietf.org, v6ops@ietf.org Subject: Re: [v6ops] protocols without need for ALG ? 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, 31 Jul 2015 05:39:03 -0000 > On Jul 30, 2015, at 22:11 , Mikael Abrahamsson = wrote: >=20 > On Thu, 30 Jul 2015, Owen DeLong wrote: >=20 >>> SSH/SCP - OK >>> syslog - OK >>> TFTP - OK ? >>=20 >> Should be OK, depending on which side is client. (client has to be = the >> private address/translated side of the connection). >=20 > There are ALGs for TFTP from multiple vendors, and I seem to remember = I had problem performing TFTP download from behind a NAT, but I could be = mistaken. This should be investigated further. You might need STUN or something like that, but you shouldn=E2=80=99t = need an ALG. Owen From nobody Thu Jul 30 22:40:28 2015 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 E208D1B3111; Thu, 30 Jul 2015 22:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.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, HK_RANDOM_FROM=1, 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 0aSi2uqzbCGG; Thu, 30 Jul 2015 22:40:25 -0700 (PDT) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::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 8E4851B3118; Thu, 30 Jul 2015 22:40:25 -0700 (PDT) Received: by igbpg9 with SMTP id pg9so25319171igb.0; Thu, 30 Jul 2015 22:40:25 -0700 (PDT) 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=WEvRNGV4XYFlnXfR3WZlJ4xbS4LuvdL7XJ9TOJjdugE=; b=FZp4ZKD08y/4HsTgcYyyP0Fo15c7PP9Re47+6jvrBSpI7DH+m79eR9gXoyhCLNVfqf ffFCXWBQ4MJpVWbeQYsBmss+iNug48KZ+tLgYpFPSG2kCO0QzyTJwoEWubDRQ2AyAcaR CTwoLIDX2BsvhjdFQ3Z6pnTWfv2JnEwJziX72EC5D+Mc3c5IV8CUmFNE3lf4Lm7RXQrW dNtCjjCDuhbx+kpQlWFOSBM2Zaj+ycox7OQMYGTAnd5Z+EYz0A5O80wy6r1vhgLNdZRl fmyBHhbxPi2pNallZaAFvJzlAQ8z7F6288E12QTGxWiUbDXZtaYOjtsF1JhJwJnLOmrB +j8A== MIME-Version: 1.0 X-Received: by 10.50.88.65 with SMTP id be1mr2474058igb.95.1438321225035; Thu, 30 Jul 2015 22:40:25 -0700 (PDT) Received: by 10.107.169.143 with HTTP; Thu, 30 Jul 2015 22:40:24 -0700 (PDT) Received: by 10.107.169.143 with HTTP; Thu, 30 Jul 2015 22:40:24 -0700 (PDT) In-Reply-To: References: <20150730205806.GI1667@cisco.com> <33A0B18B-5C9D-4DC3-9E0B-736D7ECA404F@delong.com> Date: Fri, 31 Jul 2015 15:40:24 +1000 Message-ID: From: Mark Smith To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=089e013d0dd6b0f475051c25414d Archived-At: Cc: v6ops list , behave@ietf.org Subject: Re: [v6ops] protocols without need for ALG ? 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, 31 Jul 2015 05:40:27 -0000 --089e013d0dd6b0f475051c25414d Content-Type: text/plain; charset=UTF-8 On 31 Jul 2015 3:11 pm, "Mikael Abrahamsson" wrote: > > On Thu, 30 Jul 2015, Owen DeLong wrote: > >>> SSH/SCP - OK >>> syslog - OK >>> TFTP - OK ? >> >> >> Should be OK, depending on which side is client. (client has to be the >> private address/translated side of the connection). > > > There are ALGs for TFTP from multiple vendors, and I seem to remember I had problem performing TFTP download from behind a NAT, but I could be mistaken. This should be investigated further. > I'm pretty sure you'd need an ALG for TFTP over NAT, as the file transfer itself takes place over unspecified and unpredictable ports. This caused me some grief in the past when trying to have a TFTP file transfer hold up a dial on demand link. Regards, Mark. > -- > Mikael Abrahamsson email: swmike@swm.pp.se > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --089e013d0dd6b0f475051c25414d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 31 Jul 2015 3:11 pm, "Mikael Abrahamsson" <swmike@swm.pp.se> wrote:
>
> On Thu, 30 Jul 2015, Owen DeLong wrote:
>
>>> =C2=A0 SSH/SCP - OK
>>> =C2=A0 syslog=C2=A0 - OK
>>> =C2=A0 TFTP=C2=A0 =C2=A0 - OK ?
>>
>>
>> Should be OK, depending on which side is client. (client has to be= the
>> private address/translated side of the connection).
>
>
> There are ALGs for TFTP from multiple vendors, and I seem to remember = I had problem performing TFTP download from behind a NAT, but I could be mi= staken. This should be investigated further.
>

I'm pretty sure you'd need an ALG for TFTP over NAT,= as the file transfer itself takes place over unspecified and unpredictable= ports. This caused me some grief in the past when trying to have a TFTP fi= le transfer hold up a dial on demand link.

Regards,
Mark.

> --
> Mikael Abrahamsson=C2=A0 =C2=A0 email: swmike@swm.pp.se
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--089e013d0dd6b0f475051c25414d-- From nobody Thu Jul 30 22:42:35 2015 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 7F6181B3108; Thu, 30 Jul 2015 22:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 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, 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 GV9U_U6w1g_B; Thu, 30 Jul 2015 22:42:33 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D0A31A0354; Thu, 30 Jul 2015 22:42:33 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id D6B1AA1; Fri, 31 Jul 2015 07:42:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1438321351; bh=N3VN8oOHYtep4435pX0j2Nz85ZNq9YZLIuVPRtbgMT4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=ogUIrf6MZtyH5F7uBg0fzqDEcKnpc1phwBrWOy97rTPZUVJNkPvHCc03OuNcnHIZ7 zJ3hhM1wLCx0aozhiyhQ4yp+c84ekX7g9gBJPzoWMO01ik3r2wv+kSt59dJG857lTJ 7EkcMIYhEJvFLnpTdgRshYq/B5NC8ZFBLmtwMEtk= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id CD8849F; Fri, 31 Jul 2015 07:42:31 +0200 (CEST) Date: Fri, 31 Jul 2015 07:42:31 +0200 (CEST) From: Mikael Abrahamsson To: Owen DeLong In-Reply-To: <55A144E0-74BE-4A29-9A5F-782D7D660399@delong.com> Message-ID: References: <20150730205806.GI1667@cisco.com> <33A0B18B-5C9D-4DC3-9E0B-736D7ECA404F@delong.com> <55A144E0-74BE-4A29-9A5F-782D7D660399@delong.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-2013288220-1438321351=:11810" Archived-At: Cc: behave@ietf.org, v6ops@ietf.org Subject: Re: [v6ops] protocols without need for ALG ? 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, 31 Jul 2015 05:42:34 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-2013288220-1438321351=:11810 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Thu, 30 Jul 2015, Owen DeLong wrote: > You might need STUN or something like that, but you shouldn’t need an > ALG. Well, if STUN is needed then this should be documented as well. It makes the TFTP client more complicated and it would break connectivity for legacy devices. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-2013288220-1438321351=:11810-- From nobody Fri Jul 31 00:23:14 2015 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 5E0AF1B32D2; Fri, 31 Jul 2015 00:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.637 X-Spam-Level: X-Spam-Status: No, score=-1.637 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, 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 vqMYohGJPllc; Fri, 31 Jul 2015 00:23:11 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.114]) (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 828B51A1ABC; Fri, 31 Jul 2015 00:23:10 -0700 (PDT) Received: from [194.106.220.35] by server-10.bemta-14.messagelabs.com id DD/AB-01143-C522BB55; Fri, 31 Jul 2015 07:23:08 +0000 X-Env-Sender: nick.heatley@ee.co.uk X-Msg-Ref: server-11.tower-91.messagelabs.com!1438327388!30948736!1 X-Originating-IP: [149.254.241.76] X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30039 invoked from network); 31 Jul 2015 07:23:08 -0000 Received: from unknown (HELO smtpml01.ee.co.uk) (149.254.241.76) by server-11.tower-91.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 31 Jul 2015 07:23:08 -0000 Received: from EEUKWV0940.EEAD.EEINT.CO.UK (Not Verified[10.246.209.217]) by smtpml01.ee.co.uk with MailMarshal (v7, 2, 3, 6978) id ; Fri, 31 Jul 2015 08:23:02 +0100 Received: from UK31S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.27]) by EEUKWV0940.EEAD.EEINT.CO.UK with MailMarshal (v7, 2, 3, 6978) id ; Fri, 31 Jul 2015 08:23:08 +0100 Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK31S005EXS02.EEAD.EEINT.CO.UK ([2002:62c:2a56::62c:2a56]) with mapi id 14.03.0195.001; Fri, 31 Jul 2015 08:23:07 +0100 From: "Heatley, Nick" To: Owen DeLong , Toerless Eckert Thread-Topic: [v6ops] protocols without need for ALG ? Thread-Index: AQHQywp6XZLyItFp5ECk8NAgQuQVk530cJyAgAC68MA= Date: Fri, 31 Jul 2015 07:23:07 +0000 Message-ID: <6536E263028723489CCD5B6821D4B21303EEFB7C@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <20150730205806.GI1667@cisco.com> <33A0B18B-5C9D-4DC3-9E0B-736D7ECA404F@delong.com> In-Reply-To: <33A0B18B-5C9D-4DC3-9E0B-736D7ECA404F@delong.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.246.208.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" , "behave@ietf.org" Subject: Re: [v6ops] protocols without need for ALG ? 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, 31 Jul 2015 07:23:12 -0000 =20>FTP should be long deprecated for the most part anyway, however, PASV= =20mode FTP (if you must use FTP) should be OK without need of an ALG. EPSV all the way. On a client on IPv4 side you need EPSV mode set to avoid ALG. On a server side on IPv4 it must be RFC2428 compliant i.e. to accept EPSV= . _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops NOTICE AND DISCLAIMER This e-mail (including any attachments) is intended for the above-named p= erson(s). If you are not the intended recipient, notify the sender immed= iately, delete this email from your system and do not disclose or use for= =20any purpose. =20 =20 We may monitor all incoming and outgoing emails in line with current legi= slation. We have taken steps to ensure that this email and attachments ar= e free from any virus, but it remains your responsibility to ensure that = viruses do not adversely affect you.=20 EE Limited Registered in England and Wales Company Registered Number: 02382161 Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfor= dshire, AL10 9BW. From nobody Fri Jul 31 00:23:15 2015 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 73A871A1ABC; Fri, 31 Jul 2015 00:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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 hLgqDliCBkW2; Fri, 31 Jul 2015 00:23:11 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.137]) (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 96F2A1B32D1; Fri, 31 Jul 2015 00:23:10 -0700 (PDT) Received: from [85.158.136.35] by server-1.bemta-5.messagelabs.com id A6/C0-32615-D522BB55; Fri, 31 Jul 2015 07:23:09 +0000 X-Env-Sender: nick.heatley@ee.co.uk X-Msg-Ref: server-16.tower-125.messagelabs.com!1438327388!44368142!1 X-Originating-IP: [149.254.241.76] X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18775 invoked from network); 31 Jul 2015 07:23:08 -0000 Received: from unknown (HELO smtpml01.ee.co.uk) (149.254.241.76) by server-16.tower-125.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 31 Jul 2015 07:23:08 -0000 Received: from EEUKWV0940.EEAD.EEINT.CO.UK (Not Verified[10.246.209.217]) by smtpml01.ee.co.uk with MailMarshal (v7, 2, 3, 6978) id ; Fri, 31 Jul 2015 08:23:02 +0100 Received: from UK30S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.14]) by EEUKWV0940.EEAD.EEINT.CO.UK with MailMarshal (v7, 2, 3, 6978) id ; Fri, 31 Jul 2015 08:23:08 +0100 Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK30S005EXS02.EEAD.EEINT.CO.UK ([2002:62c:2a4f::62c:2a4f]) with mapi id 14.03.0195.001; Fri, 31 Jul 2015 08:23:07 +0100 From: "Heatley, Nick" To: Mark Smith , Mikael Abrahamsson Thread-Topic: [v6ops] protocols without need for ALG ? Thread-Index: AQHQywp6XZLyItFp5ECk8NAgQuQVk530cJyAgACHMACAAAgmAIAAK13A Date: Fri, 31 Jul 2015 07:23:07 +0000 Message-ID: <6536E263028723489CCD5B6821D4B21303EEFB81@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <20150730205806.GI1667@cisco.com> <33A0B18B-5C9D-4DC3-9E0B-736D7ECA404F@delong.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.246.208.5] Content-Type: multipart/alternative; boundary="_000_6536E263028723489CCD5B6821D4B21303EEFB81UK30S005EXS06EE_" MIME-Version: 1.0 Archived-At: Cc: v6ops list , "behave@ietf.org" Subject: Re: [v6ops] protocols without need for ALG ? 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, 31 Jul 2015 07:23:12 -0000 --_000_6536E263028723489CCD5B6821D4B21303EEFB81UK30S005EXS06EE_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2FtZSBmb3IgbWUuDQoNCkZyb206IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIE1hcmsgU21pdGgNClNlbnQ6IDMxIEp1bHkgMjAxNSAwNjo0MA0KVG86 IE1pa2FlbCBBYnJhaGFtc3Nvbg0KQ2M6IHY2b3BzIGxpc3Q7IGJlaGF2ZUBpZXRmLm9yZw0KU3Vi amVjdDogUmU6IFt2Nm9wc10gcHJvdG9jb2xzIHdpdGhvdXQgbmVlZCBmb3IgQUxHID8NCg0KDQpP biAzMSBKdWwgMjAxNSAzOjExIHBtLCAiTWlrYWVsIEFicmFoYW1zc29uIiA8c3dtaWtlQHN3bS5w cC5zZTxtYWlsdG86c3dtaWtlQHN3bS5wcC5zZT4+IHdyb3RlOg0KPg0KPiBPbiBUaHUsIDMwIEp1 bCAyMDE1LCBPd2VuIERlTG9uZyB3cm90ZToNCj4NCj4+PiAgIFNTSC9TQ1AgLSBPSw0KPj4+ICAg c3lzbG9nICAtIE9LDQo+Pj4gICBURlRQICAgIC0gT0sgPw0KPj4NCj4+DQo+PiBTaG91bGQgYmUg T0ssIGRlcGVuZGluZyBvbiB3aGljaCBzaWRlIGlzIGNsaWVudC4gKGNsaWVudCBoYXMgdG8gYmUg dGhlDQo+PiBwcml2YXRlIGFkZHJlc3MvdHJhbnNsYXRlZCBzaWRlIG9mIHRoZSBjb25uZWN0aW9u KS4NCj4NCj4NCj4gVGhlcmUgYXJlIEFMR3MgZm9yIFRGVFAgZnJvbSBtdWx0aXBsZSB2ZW5kb3Jz LCBhbmQgSSBzZWVtIHRvIHJlbWVtYmVyIEkgaGFkIHByb2JsZW0gcGVyZm9ybWluZyBURlRQIGRv d25sb2FkIGZyb20gYmVoaW5kIGEgTkFULCBidXQgSSBjb3VsZCBiZSBtaXN0YWtlbi4gVGhpcyBz aG91bGQgYmUgaW52ZXN0aWdhdGVkIGZ1cnRoZXIuDQo+DQoNCkknbSBwcmV0dHkgc3VyZSB5b3Un ZCBuZWVkIGFuIEFMRyBmb3IgVEZUUCBvdmVyIE5BVCwgYXMgdGhlIGZpbGUgdHJhbnNmZXIgaXRz ZWxmIHRha2VzIHBsYWNlIG92ZXIgdW5zcGVjaWZpZWQgYW5kIHVucHJlZGljdGFibGUgcG9ydHMu IFRoaXMgY2F1c2VkIG1lIHNvbWUgZ3JpZWYgaW4gdGhlIHBhc3Qgd2hlbiB0cnlpbmcgdG8gaGF2 ZSBhIFRGVFAgZmlsZSB0cmFuc2ZlciBob2xkIHVwIGEgZGlhbCBvbiBkZW1hbmQgbGluay4NCg0K UmVnYXJkcywNCk1hcmsuDQoNCj4gLS0NCj4gTWlrYWVsIEFicmFoYW1zc29uICAgIGVtYWlsOiBz d21pa2VAc3dtLnBwLnNlPG1haWx0bzpzd21pa2VAc3dtLnBwLnNlPg0KPg0KPg0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB2Nm9wcyBtYWlsaW5n IGxpc3QNCj4gdjZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPg0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQoNCk5PVElDRSBBTkQgRElTQ0xB SU1FUg0KVGhpcyBlLW1haWwgKGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMpIGlzIGludGVuZGVk IGZvciB0aGUgYWJvdmUtbmFtZWQgcGVyc29uKHMpLiAgSWYgeW91IGFyZSBub3QgdGhlIGludGVu ZGVkIHJlY2lwaWVudCwgbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHksIGRlbGV0ZSB0aGlz IGVtYWlsIGZyb20geW91ciBzeXN0ZW0gYW5kIGRvIG5vdCBkaXNjbG9zZSBvciB1c2UgZm9yIGFu eSBwdXJwb3NlLiAgDQogDQpXZSBtYXkgbW9uaXRvciBhbGwgaW5jb21pbmcgYW5kIG91dGdvaW5n IGVtYWlscyBpbiBsaW5lIHdpdGggY3VycmVudCBsZWdpc2xhdGlvbi4gV2UgaGF2ZSB0YWtlbiBz dGVwcyB0byBlbnN1cmUgdGhhdCB0aGlzIGVtYWlsIGFuZCBhdHRhY2htZW50cyBhcmUgZnJlZSBm cm9tIGFueSB2aXJ1cywgYnV0IGl0IHJlbWFpbnMgeW91ciByZXNwb25zaWJpbGl0eSB0byBlbnN1 cmUgdGhhdCB2aXJ1c2VzIGRvIG5vdCBhZHZlcnNlbHkgYWZmZWN0IHlvdS4gDQoNCkVFIExpbWl0 ZWQNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCBhbmQgV2FsZXMNCkNvbXBhbnkgUmVnaXN0ZXJlZCBO dW1iZXI6IDAyMzgyMTYxDQpSZWdpc3RlcmVkIE9mZmljZSBBZGRyZXNzOiBUcmlkZW50IFBsYWNl LCBNb3NxdWl0byBXYXksIEhhdGZpZWxkLCBIZXJ0Zm9yZHNoaXJlLCBBTDEwIDlCVy4NCg== --_000_6536E263028723489CCD5B6821D4B21303EEFB81UK30S005EXS06EE_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3 Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNhbWUgZm9yIG1lLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy b206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiB2 Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9i Pk1hcmsgU21pdGg8YnI+DQo8Yj5TZW50OjwvYj4gMzEgSnVseSAyMDE1IDA2OjQwPGJyPg0KPGI+ VG86PC9iPiBNaWthZWwgQWJyYWhhbXNzb248YnI+DQo8Yj5DYzo8L2I+IHY2b3BzIGxpc3Q7IGJl aGF2ZUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3Y2b3BzXSBwcm90b2NvbHMg d2l0aG91dCBuZWVkIGZvciBBTEcgPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+PGJyPg0KT24gMzEgSnVsIDIwMTUg MzoxMSBwbSwgJnF1b3Q7TWlrYWVsIEFicmFoYW1zc29uJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWls dG86c3dtaWtlQHN3bS5wcC5zZSI+c3dtaWtlQHN3bS5wcC5zZTwvYT4mZ3Q7IHdyb3RlOjxicj4N CiZndDs8YnI+DQomZ3Q7IE9uIFRodSwgMzAgSnVsIDIwMTUsIE93ZW4gRGVMb25nIHdyb3RlOjxi cj4NCiZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgJm5ic3A7IFNTSC9TQ1AgLSBPSzxicj4NCiZndDsm Z3Q7Jmd0OyAmbmJzcDsgc3lzbG9nJm5ic3A7IC0gT0s8YnI+DQomZ3Q7Jmd0OyZndDsgJm5ic3A7 IFRGVFAmbmJzcDsgJm5ic3A7IC0gT0sgPzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyBTaG91bGQgYmUgT0ssIGRlcGVuZGluZyBvbiB3aGljaCBzaWRlIGlzIGNsaWVu dC4gKGNsaWVudCBoYXMgdG8gYmUgdGhlPGJyPg0KJmd0OyZndDsgcHJpdmF0ZSBhZGRyZXNzL3Ry YW5zbGF0ZWQgc2lkZSBvZiB0aGUgY29ubmVjdGlvbikuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+ DQomZ3Q7IFRoZXJlIGFyZSBBTEdzIGZvciBURlRQIGZyb20gbXVsdGlwbGUgdmVuZG9ycywgYW5k IEkgc2VlbSB0byByZW1lbWJlciBJIGhhZCBwcm9ibGVtIHBlcmZvcm1pbmcgVEZUUCBkb3dubG9h ZCBmcm9tIGJlaGluZCBhIE5BVCwgYnV0IEkgY291bGQgYmUgbWlzdGFrZW4uIFRoaXMgc2hvdWxk IGJlIGludmVzdGlnYXRlZCBmdXJ0aGVyLjxicj4NCiZndDs8bzpwPjwvbzpwPjwvcD4NCjxwPkkn bSBwcmV0dHkgc3VyZSB5b3UnZCBuZWVkIGFuIEFMRyBmb3IgVEZUUCBvdmVyIE5BVCwgYXMgdGhl IGZpbGUgdHJhbnNmZXIgaXRzZWxmIHRha2VzIHBsYWNlIG92ZXIgdW5zcGVjaWZpZWQgYW5kIHVu cHJlZGljdGFibGUgcG9ydHMuIFRoaXMgY2F1c2VkIG1lIHNvbWUgZ3JpZWYgaW4gdGhlIHBhc3Qg d2hlbiB0cnlpbmcgdG8gaGF2ZSBhIFRGVFAgZmlsZSB0cmFuc2ZlciBob2xkIHVwIGEgZGlhbCBv biBkZW1hbmQgbGluay48bzpwPjwvbzpwPjwvcD4NCjxwPlJlZ2FyZHMsPGJyPg0KTWFyay48bzpw PjwvbzpwPjwvcD4NCjxwPiZndDsgLS0gPGJyPg0KJmd0OyBNaWthZWwgQWJyYWhhbXNzb24mbmJz cDsgJm5ic3A7IGVtYWlsOiA8YSBocmVmPSJtYWlsdG86c3dtaWtlQHN3bS5wcC5zZSI+c3dtaWtl QHN3bS5wcC5zZTwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IHY2b3BzIG1haWxp bmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj52Nm9wc0Bp ZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdjZvcHMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v djZvcHM8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCg0KPFA+Tk9USUNFIEFORCBESVNDTEFJ TUVSPEJSPlRoaXMgZS1tYWlsIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBpcyBpbnRlbmRl ZCANCmZvciB0aGUgYWJvdmUtbmFtZWQgcGVyc29uKHMpLiZuYnNwOyBJZiB5b3UgYXJlIG5vdCB0 aGUgaW50ZW5kZWQgcmVjaXBpZW50LCANCm5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5LCBk ZWxldGUgdGhpcyBlbWFpbCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBkbyBub3QgDQpkaXNjbG9zZSBv ciB1c2UgZm9yIGFueSBwdXJwb3NlLiZuYnNwOyA8QlI+Jm5ic3A7PEJSPldlIG1heSBtb25pdG9y IGFsbCBpbmNvbWluZyANCmFuZCBvdXRnb2luZyBlbWFpbHMgaW4gbGluZSB3aXRoIGN1cnJlbnQg bGVnaXNsYXRpb24uIFdlIGhhdmUgdGFrZW4gc3RlcHMgdG8gDQplbnN1cmUgdGhhdCB0aGlzIGVt YWlsIGFuZCBhdHRhY2htZW50cyBhcmUgZnJlZSBmcm9tIGFueSB2aXJ1cywgYnV0IGl0IHJlbWFp bnMgDQp5b3VyIHJlc3BvbnNpYmlsaXR5IHRvIGVuc3VyZSB0aGF0IHZpcnVzZXMgZG8gbm90IGFk dmVyc2VseSBhZmZlY3QgeW91LiA8L1A+DQo8UD5FRSBMaW1pdGVkPEJSPlJlZ2lzdGVyZWQgaW4g RW5nbGFuZCBhbmQgV2FsZXM8QlI+Q29tcGFueSBSZWdpc3RlcmVkIE51bWJlcjogDQowMjM4MjE2 MTxCUj5SZWdpc3RlcmVkIE9mZmljZSBBZGRyZXNzOiBUcmlkZW50IFBsYWNlLCBNb3NxdWl0byBX YXksIEhhdGZpZWxkLCANCkhlcnRmb3Jkc2hpcmUsIEFMMTAgOUJXPC9QPg0KPFA+Jm5ic3A7PC9Q Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_6536E263028723489CCD5B6821D4B21303EEFB81UK30S005EXS06EE_-- From nobody Fri Jul 31 02:24:08 2015 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 271A91A003B for ; Fri, 31 Jul 2015 02:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMfaqlvM1jM6 for ; Fri, 31 Jul 2015 02:24:05 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 036AF1A0032 for ; Fri, 31 Jul 2015 02:24:04 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6V9O26l029046 for ; Fri, 31 Jul 2015 11:24:02 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 43A8A20399E for ; Fri, 31 Jul 2015 11:27:50 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 3ADCA203993 for ; Fri, 31 Jul 2015 11:27:50 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6V9O1gd012358 for ; Fri, 31 Jul 2015 11:24:02 +0200 To: v6ops@ietf.org References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> <20150727091241.GL84167@Space.Net> <20150728115944.GZ84167@Space.Net> <4AB2ED61-23CF-40D5-B2A6-F1F4064EC0C6@nominum.com> <90E6B48E-B3FC-4AAD-B356-7D92A2777632@nominum.com> <804F2F0B-B0EF-4054-99C5-C0CD8957C434@nominum.com> <2134F8430051B64F815C691A62D9831832ED2 9AC@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832ED2A37@XCH-BLV-504.nw.nos.boeing.com> From: Alexandru Petrescu Message-ID: <55BB3EB1.40909@gmail.com> Date: Fri, 31 Jul 2015 11:24:01 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <2134F8430051B64F815C691A62D9831832ED2A37@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-colitti-v6ops-host-addr-availability-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: Fri, 31 Jul 2015 09:24:07 -0000 Le 30/07/2015 17:49, Templin, Fred L a écrit : > Hi Philip, > >> -----Original Message----- From: v6ops >> [mailto:v6ops-bounces@ietf.org] On Behalf Of Philip Homburg Sent: >> Thursday, July 30, 2015 8:38 AM To: v6ops@ietf.org Subject: Re: >> [v6ops] I-D Action: >> draft-colitti-v6ops-host-addr-availability-01.txt >> >>> I agree. We also need to remember that each device that gets a >>> /64 can connect countless billions of other devices using the >>> available /64 prefix space. >> >> I'm not saying that we should give every device a /64 using >> DHCP-PD. SLAAC is probably a much better way to distribute >> addresses locally (at least as long as we don't mess up IIDs >> completely). > > You can't give a device a /64 using SLAAC; I agree. > SLAAC only allows for autoconfiguration of singleton addresses taken > from an on-link /64 prefix. Yes. > If you want to give a device a /64, the only choices I am aware of > are administrative configuration or DHCPv6 PD. I agree. In addition there may be something with EAP, IKE and OSPF. > That said, once a device has received a /64, address delegation from > the /64 could certainly use SLAAC. I disagree. If a device can't get a /64 by using SLAAC then it can't give a /64 using SLAAC either. Although yes, if a device gets a /64 with DHCP-PD then it can RA with that /64 on its other interface, only for the other devices on that other interface. Alex > > Thanks - Fred fred.l.templin@boeing.com > >> But, the addressing architecture does allow for one /64 per device. >> So when needed, it is better to use that space than to add all >> kinds of complexity while trying to save a few bits. >> >> >> _______________________________________________ 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 Jul 31 05:19:31 2015 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 DD1221A1A5F; Fri, 31 Jul 2015 05:19:29 -0700 (PDT) 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, 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 VkvdnM5RVmZA; Fri, 31 Jul 2015 05:19:29 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2E2D1A1A57; Fri, 31 Jul 2015 05:19:28 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.4-5) with ESMTP id 0d76bb55.2b9bd4c4d940.2190269.00-2461.6234745.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 31 Jul 2015 12:19:28 +0000 (UTC) X-MXL-Hash: 55bb67d010a9f991-70a57acb5dfee02961f8526b79da2fd264ff67be Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id ac76bb55.0.2190226.00-2146.6234630.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 31 Jul 2015 12:19:25 +0000 (UTC) X-MXL-Hash: 55bb67cd011d1b91-0065b5ded2378fdb1adbd1de065454db5b797db8 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t6VCJLx7021370; Fri, 31 Jul 2015 08:19:21 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t6VCJBoY021305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 31 Jul 2015 08:19:15 -0400 Received: from GAALPA1MSGHUBAA.ITServices.sbc.com (GAALPA1MSGHUBAA.itservices.sbc.com [130.8.218.150]) by alpi133.aldc.att.com (RSA Interceptor); Fri, 31 Jul 2015 12:19:07 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.63]) by GAALPA1MSGHUBAA.ITServices.sbc.com ([130.8.218.150]) with mapi id 14.03.0224.002; Fri, 31 Jul 2015 08:19:07 -0400 From: "STARK, BARBARA H" To: Toerless Eckert , "v6ops@ietf.org" , "behave@ietf.org" Thread-Topic: [v6ops] protocols without need for ALG ? Thread-Index: AQHQywp70rb1Fq++mESi4PQB2sD9p531f2EA Date: Fri, 31 Jul 2015 12:19:06 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61132AC5E09@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <20150730205806.GI1667@cisco.com> In-Reply-To: <20150730205806.GI1667@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.104.205] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=ONaQK1mB c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=BttOa0TPrj8A:10 a=zOBTX] X-AnalysisOut: [jUuO1YA:10 a=pUsKtR-7xbNaotJVKlgA:9 a=CjuIK1q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2015072901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: Subject: Re: [v6ops] protocols without need for ALG ? 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, 31 Jul 2015 12:19:30 -0000 > Wrt to what seems to be important between NOC and network devices: Is there ever a case where IPsec is used to establish a secure connection t= o the NOC equipment? I don't know -- I just know that IPsec is one of the m= ost common ALGs around. Barbara From nobody Fri Jul 31 06:10:03 2015 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 23AF71A6F87 for ; Fri, 31 Jul 2015 06:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECgtzY5dJz-I for ; Fri, 31 Jul 2015 06:09:55 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8C381A6F04 for ; Fri, 31 Jul 2015 06:09:54 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6VD9qUM015725 for ; Fri, 31 Jul 2015 15:09:52 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B6AB82039F1 for ; Fri, 31 Jul 2015 15:13:40 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id ADFE1200EA7 for ; Fri, 31 Jul 2015 15:13:40 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6VD9qjF029913 for ; Fri, 31 Jul 2015 15:09:52 +0200 To: v6ops@ietf.org References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> <20150728115944.GZ84167@Space.Net> <4AB2ED61-23CF-40D5-B2A6-F1F4064EC0C6@nominum.com> <90E6B48E-B3FC-4AAD-B356-7D92A2777632@nominum.com> <804F2F0B-B0EF-4054-99C5-C0CD8957C434@nominum.com> <2134F8430051B64F815C691A62D9831832ED2 9AC@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832ED2A37@XCH-BLV-504.nw.nos.boeing.com> <20150730191629.1817894a@envy.fud.no> From: Alexandru Petrescu Message-ID: <55BB73A0.4040105@gmail.com> Date: Fri, 31 Jul 2015 15:09:52 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150730191629.1817894a@envy.fud.no> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-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: Fri, 31 Jul 2015 13:10:02 -0000 Le 30/07/2015 19:16, Tore Anderson a écrit : > * Templin, Fred L > >> You can't give a device a /64 using SLAAC; SLAAC only allows for >> autoconfiguration of singleton addresses taken from an on-link /64 >> prefix. > > Hi Fred, > > Actually, SLAAC works equally well with off-link prefixes. There is > no inherent requirement in SLAAC that prefixes from which the > addresses are auto-configured must be on-link; the L and A bits in an > RA's PIO are completely orthogonal. I can agree. >> If you want to give a device a /64, the only choices I am aware of >> are administrative configuration or DHCPv6 PD. > > True, although 3GPP networks is an exception. There a /64 prefix > advertised to the UE via standard RA/PIO with SLAAC can be treated > as if it was a delegated prefix. RFC7278 depends on this. IMHO it is wrong to treat it as a delegated prefix. RFC7278 states clearly that the right way to get a delegated prefix is DHCPv6-PD. The treatment 'as if' is what makes operators think that one /64 in RA is enough space for enough devices behind the UE. A /64 on a cellular link can only accommodate one device. Something may make think that the /64 is a delegated prefix that _could_ accommodate more than one device: - the cellular link is a ptp link. As such the first-hop router in the cellular network has a specific routing table entry containing the IP address of the UE as next-hop (instead of a '*' if it were a shared link) for that /64. This makes that any address in that /64 is reachable through UE's IP address. However, cellular links continue to advance away from being ptp links and more be 'shared' links. Recently 4G ptp links have got 48bit MAC addresses. In the future there will be true Neighbor Discovery on these links, with '*' routes instead of next-hop routes. At that point, the assumption that a /64 can accommodate 2^64 devices will no longer hold, because the first-hop router will issue NSs for the dst address, instead of issuing RSs for the IP address of the UE. Alex > Tore > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Fri Jul 31 06:21:33 2015 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 D32671A87A1; Fri, 31 Jul 2015 06:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 7YZFAor6TCeD; Fri, 31 Jul 2015 06:21:27 -0700 (PDT) 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 B3FFC1A87A9; Fri, 31 Jul 2015 06:21:27 -0700 (PDT) Received: from [192.168.1.3] (pool-71-108-120-69.lsanca.dsl-w.verizon.net [71.108.120.69]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t6VDL3Wi006080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 31 Jul 2015 06:21:05 -0700 (PDT) References: <20150730205806.GI1667@cisco.com> <33A0B18B-5C9D-4DC3-9E0B-736D7ECA404F@delong.com> <6536E263028723489CCD5B6821D4B21303EEFB81@UK30S005EXS06.EEAD.EEINT.CO.UK> In-Reply-To: <6536E263028723489CCD5B6821D4B21303EEFB81@UK30S005EXS06.EEAD.EEINT.CO.UK> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-47C8F9D6-3F39-45B2-9176-A722B621781A Message-Id: X-Mailer: iPad Mail (12H143) From: Joe Touch Date: Fri, 31 Jul 2015 06:21:01 -0700 To: "Heatley, Nick" X-MailScanner-ID: t6VDL3Wi006080 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: v6ops list , "behave@ietf.org" Subject: Re: [v6ops] protocols without need for ALG ? 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, 31 Jul 2015 13:21:30 -0000 --Apple-Mail-47C8F9D6-3F39-45B2-9176-A722B621781A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable TFTP servers are typically reached at UDP port 69. It does not use ports or addresses in-band and thus should not need an ALG. Joe > On Jul 31, 2015, at 12:23 AM, Heatley, Nick wrote:= >=20 > Same for me. > =20 > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Mark Smith > Sent: 31 July 2015 06:40 > To: Mikael Abrahamsson > Cc: v6ops list; behave@ietf.org > Subject: Re: [v6ops] protocols without need for ALG ? > =20 >=20 > On 31 Jul 2015 3:11 pm, "Mikael Abrahamsson" wrote: > > > > On Thu, 30 Jul 2015, Owen DeLong wrote: > > > >>> SSH/SCP - OK > >>> syslog - OK > >>> TFTP - OK ? > >> > >> > >> Should be OK, depending on which side is client. (client has to be the > >> private address/translated side of the connection). > > > > > > There are ALGs for TFTP from multiple vendors, and I seem to remember I h= ad problem performing TFTP download from behind a NAT, but I could be mistak= en. This should be investigated further. > > >=20 > I'm pretty sure you'd need an ALG for TFTP over NAT, as the file transfer i= tself takes place over unspecified and unpredictable ports. This caused me s= ome grief in the past when trying to have a TFTP file transfer hold up a dia= l on demand link. >=20 > Regards, > Mark. >=20 > > --=20 > > Mikael Abrahamsson email: swmike@swm.pp.se > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops >=20 > NOTICE AND DISCLAIMER > This e-mail (including any attachments) is intended for the above-named pe= rson(s). If you are not the intended recipient, notify the sender immediate= ly, delete this email from your system and do not disclose or use for any pu= rpose. =20 > =20 > We may monitor all incoming and outgoing emails in line with current legis= lation. We have taken steps to ensure that this email and attachments are fr= ee from any virus, but it remains your responsibility to ensure that viruses= do not adversely affect you. >=20 > EE Limited > Registered in England and Wales > Company Registered Number: 02382161 > Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertford= shire, AL10 9BW >=20 > =20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-47C8F9D6-3F39-45B2-9176-A722B621781A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
TFTP servers are typically reached at UDP port 69.

It does not use ports or addresses in-band and thus should not need an ALG.

Joe

On Jul 31, 2015, at 12:23 AM, Heatley, Nick <nick.heatley@ee.co.uk> wrote:

Same for me.

 

From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Mark Smith
Sent: 31 July 2015 06:40
To: Mikael Abrahamsson
Cc: v6ops list; behave@ietf.org
Subject: Re: [v6ops] protocols without need for ALG ?

 


On 31 Jul 2015 3:11 pm, "Mikael Abrahamsson" <swmike@swm.pp.se> wrote:
>
> On Thu, 30 Jul 2015, Owen DeLong wrote:
>
>>>   SSH/SCP - OK
>>>   syslog  - OK
>>>   TFTP    - OK ?
>>
>>
>> Should be OK, depending on which side is client. (client has to be the
>> private address/translated side of the connection).
>
>
> There are ALGs for TFTP from multiple vendors, and I seem to remember I had problem performing TFTP download from behind a NAT, but I could be mistaken. This should be investigated further.
>

I'm pretty sure you'd need an ALG for TFTP over NAT, as the file transfer itself takes place over unspecified and unpredictable ports. This caused me some grief in the past when trying to have a TFTP file transfer hold up a dial on demand link.

Regards,
Mark.

> --
> Mikael Abrahamsson    email: swmike@swm.pp.se
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

NOTICE AND DISCLAIMER
This e-mail (including any attachments) is intended for the above-named person(s).  If you are not the intended recipient, notify the sender immediately, delete this email from your system and do not disclose or use for any purpose. 
 
We may monitor all incoming and outgoing emails in line with current legislation. We have taken steps to ensure that this email and attachments are free from any virus, but it remains your responsibility to ensure that viruses do not adversely affect you.

EE Limited
Registered in England and Wales
Company Registered Number: 02382161
Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9BW

 

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--Apple-Mail-47C8F9D6-3F39-45B2-9176-A722B621781A-- From nobody Fri Jul 31 06:37:39 2015 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 59DF11A883A; Fri, 31 Jul 2015 06:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.749 X-Spam-Level: X-Spam-Status: No, score=-0.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_BACKHAIR_37=1, 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 7UokycGj1bD4; Fri, 31 Jul 2015 06:37:30 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::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 23E2D1A8842; Fri, 31 Jul 2015 06:37:30 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so34330653wib.0; Fri, 31 Jul 2015 06:37:29 -0700 (PDT) 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=5CgpmDwpfMJAgjtnYjfg6iaEr0VRBq2przQ7Rswdz/s=; b=FpCTmR2C4wjIHQvwcV0yI4sV8VlTyZay+97jB/DSPWkdx+79f1zxmlJ/CsPxlYUbQM FVb+nK29S1OJ4ARQoPOxSFVxOXrpjRHxrMJcjTqlNoPhFJFsQzRjeVNbdy5KreTCCLVk lGPiT1A0YCAU2p0iyJNYq/nRwVWgQVR0TJ/PYb69zpneiVHYbqB26Rwq/NSOsqXI141C pEXzpj5rO/4LUpdYWhHyUEubINI/6vC5NNVpP1meQrbe8cTygNrSukDIZj3f2QlGIWjo K1wqyY4TZuh0+JaTFQTUlsffid6RG7/uJTJuyZa0aW2LRgjO0BqS3lgy6RlSlh/dX1dk saQg== MIME-Version: 1.0 X-Received: by 10.194.108.5 with SMTP id hg5mr6384991wjb.25.1438349848909; Fri, 31 Jul 2015 06:37:28 -0700 (PDT) Received: by 10.194.191.232 with HTTP; Fri, 31 Jul 2015 06:37:28 -0700 (PDT) In-Reply-To: <20150730205806.GI1667@cisco.com> References: <20150730205806.GI1667@cisco.com> Date: Fri, 31 Jul 2015 06:37:28 -0700 Message-ID: From: Ca By To: Toerless Eckert Content-Type: multipart/alternative; boundary=089e0103deface9f14051c2bebdd Archived-At: Cc: "v6ops@ietf.org" , "behave@ietf.org" Subject: Re: [v6ops] protocols without need for ALG ? 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, 31 Jul 2015 13:37:36 -0000 --089e0103deface9f14051c2bebdd Content-Type: text/plain; charset=UTF-8 On Thursday, July 30, 2015, Toerless Eckert wrote: > For autonomic networking (ANIMA WG), we are planning to rely only on IPv6 > for initial > autonomic connectivity, and the question of connecting this (at least > initially) > to IPv4 only NOC equipment came up. Alas, IPv6 support in transport seems > to be still > weak on a range of commonly used NOC tools. > > Ehhh. For something as forward looking as anima , it is unfortunate that you believe you will need to bring this technical debt with you. My suggeation is that you require ipv6 for this case. If you do not shed this requirement now, you will carry it with you forever. The iphone can require ipv6 apps, so can anima. CB > If i understand the NAT RFCs and behave output correctly, we primaerily > want ALGs to go the way of the dodo, so i was wondering if there might be > any crucial protocols between typical NOC equipment and network devices > that > would require ALGs. And better of course:knowing which protocols would be > fine > without ALG. > > Are there any lists about this (eg: what requires ALG ?) > > Wrt to what seems to be important between NOC and network devices: > > FTP - NOK (requires ALG) - IMHO not a problem > traceroute - ?? (initiated from v4 NOC) ?? > telnet - OK > ping - OK ? > SSH/SCP - OK > syslog - OK > TFTP - OK ? > radius - OK ? (i ran some tests, seemed to be fine) > diameter/tacacs+ - OK ? > NTP - OK ??? > > For the following, that have extensible data-models (MIBs/OIDs, XML > schema etc.), > i can see that some NOC tools relying on them might not support > data-models > with IPv6, but that would be "fine" (aka: can't manage everything from > such tools, > but transport stack works): > > netconf - OK ? > SNMP - OK ? > > Whats the next most important NOC<->network management protocols... ? > > Thanks! > Toerless > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --089e0103deface9f14051c2bebdd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thursday, July 30, 2015, Toerless Eckert <eckert@cisco.com> wrote:
For autonomic networking (ANIMA WG), we are planning to rely only o= n IPv6 for initial
autonomic connectivity, and the question of connecting this (at least initi= ally)
to IPv4 only NOC equipment came up. Alas, IPv6 support in transport seems t= o be still
weak on a range of commonly used NOC tools.


Ehhh. For something as forward looking= as anima , it is unfortunate that you believe you will need to bring this = technical debt with you.=C2=A0

My suggeation is th= at you require ipv6 for this case. If you do not shed this requirement now,= you will carry it with you forever.=C2=A0

The iph= one can require ipv6 apps, so can anima.=C2=A0

CB<= /div>
=C2=A0
If i understand the NAT RFCs and behave output correctly, we primaerily
want ALGs to go the way of the dodo, so i was wondering if there might be any crucial protocols between typical NOC equipment and network devices tha= t
would require ALGs. And better of course:knowing which protocols would be f= ine
without ALG.

Are there any lists about this (eg: what requires ALG ?)

Wrt to what seems to be important between NOC and network devices:

=C2=A0 =C2=A0FTP=C2=A0 =C2=A0 =C2=A0- NOK (requires ALG) - IMHO not a probl= em
=C2=A0 =C2=A0traceroute - ??=C2=A0 (initiated from v4 NOC) ??
=C2=A0 =C2=A0telnet=C2=A0 - OK
=C2=A0 =C2=A0ping=C2=A0 =C2=A0 - OK ?
=C2=A0 =C2=A0SSH/SCP - OK
=C2=A0 =C2=A0syslog=C2=A0 - OK
=C2=A0 =C2=A0TFTP=C2=A0 =C2=A0 - OK ?
=C2=A0 =C2=A0radius=C2=A0 - OK ? (i ran some tests, seemed to be fine)
=C2=A0 =C2=A0diameter/tacacs+ - OK ?
=C2=A0 =C2=A0NTP=C2=A0 =C2=A0 =C2=A0- OK ???

=C2=A0 =C2=A0For the following, that have extensible data-models (MIBs/OIDs= , XML schema etc.),
=C2=A0 =C2=A0i can see that some NOC tools relying on them might not suppor= t data-models
=C2=A0 =C2=A0with IPv6, but that would be "fine" (aka: can't = manage everything from such tools,
=C2=A0 =C2=A0but transport stack works):

=C2=A0 =C2=A0netconf - OK ?
=C2=A0 =C2=A0SNMP=C2=A0 =C2=A0 - OK ?

Whats the next most important NOC<->network management protocols... ?=

Thanks!
=C2=A0 =C2=A0 Toerless

_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops
--089e0103deface9f14051c2bebdd-- From nobody Fri Jul 31 09:52:12 2015 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 BFCE31A9148; Fri, 31 Jul 2015 09:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, J_BACKHAIR_37=1, 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 L2o8mUJOo7y3; Fri, 31 Jul 2015 09:52:09 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450: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 4C9C11A90C8; Fri, 31 Jul 2015 09:52:09 -0700 (PDT) Received: by wicmv11 with SMTP id mv11so65162648wic.0; Fri, 31 Jul 2015 09:52:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=EaDaZgnl3owJfA8PKTFrawQv3rIC38OPVPQWHnb+oi0=; b=Bt+h3YAWIldiKHD00A5jF4/N1s02P99uBMN3rcp9ljFtRNo7JYxg3O/1koLkygmoBE 88l/rZj8h8vUDpmti4meO38KqaeuF4oYu/4FV7aaI8ZMVv85SO5ZyW9kU9liWWkf1XZG jp6rUMGkh+OsljrHde8JX+qL85b3vkY4IBJpZ1Z8ZWJe8tXNrkz9uCSoRnppmbu8My9W 2RK/s6Z9mV050tB8VJlrdjZrbjJQ4HMdYbQY7ykdutyli57n8XCsUOFExOhHcoFqORvA B1Dnio47FVXsTQlUtUgzadUV75a5hC3g+QMyZVEhz4C7N9KtA85MEr+NuD6EMrfbHzBe wmuA== X-Received: by 10.194.123.4 with SMTP id lw4mr7494370wjb.94.1438361528128; Fri, 31 Jul 2015 09:52:08 -0700 (PDT) Received: from [192.168.0.4] (cpc11-brig18-2-0-cust561.3-3.cable.virginm.net. [81.100.118.50]) by smtp.gmail.com with ESMTPSA id fs8sm8045444wjb.7.2015.07.31.09.52.07 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Jul 2015 09:52:07 -0700 (PDT) Message-ID: <55BBA7C1.3000502@gmail.com> Date: Sat, 01 Aug 2015 04:52:17 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ca By , Toerless Eckert References: <20150730205806.GI1667@cisco.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" , "behave@ietf.org" Subject: Re: [v6ops] [BEHAVE] protocols without need for ALG ? 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, 31 Jul 2015 16:52:10 -0000 On 01/08/2015 01:37, Ca By wrote: > On Thursday, July 30, 2015, Toerless Eckert wrote: > >> For autonomic networking (ANIMA WG), we are planning to rely only on IPv6 >> for initial >> autonomic connectivity, and the question of connecting this (at least >> initially) >> to IPv4 only NOC equipment came up. Alas, IPv6 support in transport seems >> to be still >> weak on a range of commonly used NOC tools. >> >> > Ehhh. For something as forward looking as anima , it is unfortunate that > you believe you will need to bring this technical debt with you. Yes, but we assume that during the phasing-in of autonomic operations, we will be forced to interface to legacy NOCs. Personally I think I disagree with NAT46 and NAT64 as the way to handle this, but Toerless is asking the right questions in order to have this debate over on the Anima list. Brian > > My suggeation is that you require ipv6 for this case. If you do not shed > this requirement now, you will carry it with you forever. > > The iphone can require ipv6 apps, so can anima. > > CB > > >> If i understand the NAT RFCs and behave output correctly, we primaerily >> want ALGs to go the way of the dodo, so i was wondering if there might be >> any crucial protocols between typical NOC equipment and network devices >> that >> would require ALGs. And better of course:knowing which protocols would be >> fine >> without ALG. >> >> Are there any lists about this (eg: what requires ALG ?) >> >> Wrt to what seems to be important between NOC and network devices: >> >> FTP - NOK (requires ALG) - IMHO not a problem >> traceroute - ?? (initiated from v4 NOC) ?? >> telnet - OK >> ping - OK ? >> SSH/SCP - OK >> syslog - OK >> TFTP - OK ? >> radius - OK ? (i ran some tests, seemed to be fine) >> diameter/tacacs+ - OK ? >> NTP - OK ??? >> >> For the following, that have extensible data-models (MIBs/OIDs, XML >> schema etc.), >> i can see that some NOC tools relying on them might not support >> data-models >> with IPv6, but that would be "fine" (aka: can't manage everything from >> such tools, >> but transport stack works): >> >> netconf - OK ? >> SNMP - OK ? >> >> Whats the next most important NOC<->network management protocols... ? >> >> Thanks! >> Toerless >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From nobody Fri Jul 31 10:19:41 2015 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 7B4DB1B2EA2 for ; Fri, 31 Jul 2015 10:19:39 -0700 (PDT) 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 b_6rDkRj79W9 for ; Fri, 31 Jul 2015 10:19:38 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7A591AC39D for ; Fri, 31 Jul 2015 10:19:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2399; q=dns/txt; s=iport; t=1438363177; x=1439572777; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=t18WPF1U6FgnjbWTkh0RhkkLQ2E/jcrg96cEETK8svo=; b=azJBvIItA/i3n5WX9YTjKDNzDFcpXCqgkRXf+gY+x7YROWZFxsqWv7Ig OWNYIv1sr3+5IHf9QtL37iXYgh2qs4E4nKBfbU06OvROgB6qreByGH7N0 E76Iu+sbJWtTXUiNpKdgTb1tHHVxH/lfe3+1RFPhhSIerM2xFdPdPxHKz Y=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B2BQAwrbtV/4ENJK1bgxqBPQa8OId9AoExORMBAQEBAQEBgQqEIwEBAQMBfgsCAQgYLiERJQIEEw6ICwMKCMIzDYUvAQEBAQEBAQEBAQEBAQEBAQEBARmLToJOgkCDGIEUBZR4AYI4gVmGTIFrkg+HMCaDfW+BSIEEAQEB X-IronPort-AV: E=Sophos;i="5.15,585,1432598400"; d="asc'?scan'208";a="16700620" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-4.cisco.com with ESMTP; 31 Jul 2015 17:19:37 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t6VHJaPB016438 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 31 Jul 2015 17:19:37 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.49]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Fri, 31 Jul 2015 12:19:36 -0500 From: "Fred Baker (fred)" To: v6ops list Thread-Topic: [v6ops] IANA assigned prefix for IPv6 benchmarking Thread-Index: AQHQy7US02bMjzO8eUKzZzXqhfm9BQ== Date: Fri, 31 Jul 2015 17:19:36 +0000 Message-ID: References: <6b60e612c4f0.55b20091@naist.jp> <6c008406e2af.55b200cf@naist.jp> <6c00eec89ab8.55b2010d@naist.jp> <6bf095d99dae.55b2014a@naist.jp> <6b50ff96a9ad.55b20188@naist.jp> <6c50a92cde54.55b201c6@naist.jp> <6c50be138e83.55b20205@naist.jp> <6bf08db1e13f.55b20243@naist.jp> <6bf0f7dbdadf.55b20280@naist.jp> <6bf0898ffbd5.55b21ea8@naist.jp> <55B29026.1070906@gmail.com> In-Reply-To: <55B29026.1070906@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.117] Content-Type: multipart/signed; boundary="Apple-Mail=_F3D17B2E-A80C-45C6-8BE1-68EDDE1570EA"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] IANA assigned prefix for IPv6 benchmarking 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, 31 Jul 2015 17:19:39 -0000 --Apple-Mail=_F3D17B2E-A80C-45C6-8BE1-68EDDE1570EA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Jul 24, 2015, at 12:21 PM, Alexandru Petrescu = wrote: >=20 > But I heard there may be good reasons to avoid ULA in NAT64. Not sure = which. , speaking as someone who communicates on the list. I find the entire fixation on ULAs and GUAs bizarre. A ULA is a global = scope prefix that is not advertised in routing (which one might describe = as site-scope, except that we wouldn't want to confuse it with = site-local). If someone has a use for a prefix that they don't plan to = advertise in routing, that seems to be the poster child use case. If = someone plans to speak globally using a given prefix, it should be a = global prefix that *is* advertised in routing. What's with the angst? Is it that someone sees "ULA" and thinks "NAT"? = Yes, that would be one use case; if you don't like that use case, we = have a library full of RFCs that say why one might not recommend it = (RFCs 2993, 4864, and others). We also have other use cases. Do we REALLY need to wrings our hands one more time? --Apple-Mail=_F3D17B2E-A80C-45C6-8BE1-68EDDE1570EA 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 iQIVAwUBVbutmUayAOS/EQ8MAQKGBA/+NjNSglb2zdgXValwoNHAAVDkF3CD60d5 +AO8a4tENq0IrE3+vqzI69Yow78tyNEHUoccdx5wxsgBoY8Qm6vifzIDh3ZUsoqi lzACt/Gvq/q7vgW8rtqGNmnYBblPnMVw6w5zK/rApsHvpRnajV8RO4zXZGCpmsKW 0DFgayGqNbF6NGo8q85h/236GtMp9LstGL5FGVoCRzyNCVgKMV/NHL+hLDJL3UeY ryizZeR1PJ6SZ5qmGnAVkO9wYtCZFYNYliAcLzsnN+B/piwZkuYb0K9nDQJwihb7 UfO6Idwy2C/+vLH1p347++NcVAMG+6obkVP5HBSPPdjEdf7P6eaUay9YLt3I4nvv DhIuMXHwoiwZacmNmPnlR5ePLrwDpI6fdkH14LuHIqfN9jwmp7KWA06V9lscxcbF WD75Ce3t+gMfqX20ue5pikgWi5czVbB4OjwySNUiBBk7HmOf0UMQgJVDYHJDRU4u c8GltLEQp41QB/Cpqn3Tfo9z00EZ7VYuvw+pWP3ND8gPDLTpwGAtLuMAVgv2as8Y JENPh83aNfF3017Zw41bU/6VSqaDxnBkLrMIjxyhElRkkqiJ5MA1M04TODRd/+Tg guAamkVF7i9leoXI0+3if4BOpF56XLoSvnmb91EkFNQ5ey0bq/CsaR1trEvj6VOs KDorWoV8FDo= =3TDb -----END PGP SIGNATURE----- --Apple-Mail=_F3D17B2E-A80C-45C6-8BE1-68EDDE1570EA-- From nobody Fri Jul 31 10:44:26 2015 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 3C6871ABC0F; Fri, 31 Jul 2015 10:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.511 X-Spam-Level: X-Spam-Status: No, score=-13.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_BACKHAIR_37=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 mlTjdUHke0aY; Fri, 31 Jul 2015 10:44:23 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85BF01A89B5; Fri, 31 Jul 2015 10:44:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3154; q=dns/txt; s=iport; t=1438364663; x=1439574263; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=E6BOS8pbXJqyf4NZPVw19xH7s95wQevpjk41OzIkAWc=; b=QD4I8W+rPDnWCR1vWNjToF8fEBpR1eQPW0BzITiuz6HRvbdetMT+scOz 83y5dHVYoKTNw8RvfR7mjnhoSAF5VbHKlNkl+/6nLZgFPhZoqKW3fA7ib Ft58Mh2zIt9ZE1nLtKkaScb6mM3LkTKxxbcNfDvGrpV6wI/t68wu0EnqQ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BrAwAKs7tV/4wNJK1bgxpUabw1CYF6CoUvSgKBMjgUAQEBAQEBAYEKhCMBAQEDAQEBASQTNAsFCwsYCSUPBRM2ExuICwgNx2kBAQEBAQEBAQEBAQEBAQEBAQEBAQETBItOhQcHgxiBFAWNQIc4h12EagKZPyaEHR4xgkwBAQE X-IronPort-AV: E=Sophos;i="5.15,585,1432598400"; d="scan'208";a="16707908" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-4.cisco.com with ESMTP; 31 Jul 2015 17:44:23 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t6VHiMWP032708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Jul 2015 17:44:22 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t6VHiLwi011016; Fri, 31 Jul 2015 10:44:21 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t6VHiL9E011015; Fri, 31 Jul 2015 10:44:21 -0700 Date: Fri, 31 Jul 2015 10:44:21 -0700 From: Toerless Eckert To: Brian E Carpenter Message-ID: <20150731174421.GA9032@cisco.com> References: <20150730205806.GI1667@cisco.com> <55BBA7C1.3000502@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55BBA7C1.3000502@gmail.com> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: "behave@ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] [BEHAVE] protocols without need for ALG ? 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, 31 Jul 2015 17:44:25 -0000 On Sat, Aug 01, 2015 at 04:52:17AM +1200, Brian E Carpenter wrote: > > Ehhh. For something as forward looking as anima , it is unfortunate that > > you believe you will need to bring this technical debt with you. > > > Yes, but we assume that during the phasing-in of autonomic operations, > we will be forced to interface to legacy NOCs. Right. It's just like siit-dc, just the opposite: We want to enable the IPv6 only autonomic network (like they an IPv6 only DC) of course to also encourage the IPv6 centric/only NOC but to get started also provide a simple, isolated, and easily removed solution (hack ?) to connect to legacy IPv4 NOC in our case (in siit-dc some legacy IPv4 (network)). > Personally I think I > disagree with NAT46 and NAT64 as the way to handle this Actually i now think siit-eam is the easiest way - which i think is an extension of stateless NAT64, but i don't claim i am using all the terminology right. > but Toerless > is asking the right questions in order to have this debate over on the > Anima list. Right. once i'm back from PTO after next week... Cheers toerless > > Brian > > > > > My suggeation is that you require ipv6 for this case. If you do not shed > > this requirement now, you will carry it with you forever. > > > > The iphone can require ipv6 apps, so can anima. > > > > CB > > > > > >> If i understand the NAT RFCs and behave output correctly, we primaerily > >> want ALGs to go the way of the dodo, so i was wondering if there might be > >> any crucial protocols between typical NOC equipment and network devices > >> that > >> would require ALGs. And better of course:knowing which protocols would be > >> fine > >> without ALG. > >> > >> Are there any lists about this (eg: what requires ALG ?) > >> > >> Wrt to what seems to be important between NOC and network devices: > >> > >> FTP - NOK (requires ALG) - IMHO not a problem > >> traceroute - ?? (initiated from v4 NOC) ?? > >> telnet - OK > >> ping - OK ? > >> SSH/SCP - OK > >> syslog - OK > >> TFTP - OK ? > >> radius - OK ? (i ran some tests, seemed to be fine) > >> diameter/tacacs+ - OK ? > >> NTP - OK ??? > >> > >> For the following, that have extensible data-models (MIBs/OIDs, XML > >> schema etc.), > >> i can see that some NOC tools relying on them might not support > >> data-models > >> with IPv6, but that would be "fine" (aka: can't manage everything from > >> such tools, > >> but transport stack works): > >> > >> netconf - OK ? > >> SNMP - OK ? > >> > >> Whats the next most important NOC<->network management protocols... ? > >> > >> Thanks! > >> Toerless > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > >> > > > > > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > -- --- Toerless Eckert, eckert@cisco.com From nobody Fri Jul 31 10:56:20 2015 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 D2E831B2E9C for ; Fri, 31 Jul 2015 10:56:17 -0700 (PDT) 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 1P2VNWXW8poE for ; Fri, 31 Jul 2015 10:56:16 -0700 (PDT) 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 2DA451A89B5 for ; Fri, 31 Jul 2015 10:56:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t6VHuG3D010504; Fri, 31 Jul 2015 12:56:16 -0500 Received: from XCH-PHX-309.sw.nos.boeing.com (xch-phx-309.sw.nos.boeing.com [130.247.25.163]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t6VHuBMG010425 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 31 Jul 2015 12:56:11 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.231]) by XCH-PHX-309.sw.nos.boeing.com ([169.254.9.36]) with mapi id 14.03.0235.001; Fri, 31 Jul 2015 10:56:09 -0700 From: "Templin, Fred L" To: Alexandru Petrescu , "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-01.txt Thread-Index: AQHQyt22GTvNaKRRoESx6jY9+5U45Z30J2yAgAGddoCAABlpcA== Date: Fri, 31 Jul 2015 17:56:08 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832ED3E02@XCH-BLV-504.nw.nos.boeing.com> References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> <20150727091241.GL84167@Space.Net> <20150728115944.GZ84167@Space.Net> <4AB2ED61-23CF-40D5-B2A6-F1F4064EC0C6@nominum.com> <90E6B48E-B3FC-4AAD-B356-7D92A2777632@nominum.com> <804F2F0B-B0EF-4054-99C5-C0CD8957C434@nominum.com> <2134F8430051B64F815C691A62D9831832ED2 9AC@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832ED2A37@XCH-BLV-504.nw.nos.boeing.com> <55BB3EB1.40909@gmail.com> In-Reply-To: <55BB3EB1.40909@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-colitti-v6ops-host-addr-availability-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: Fri, 31 Jul 2015 17:56:18 -0000 Hi Alex, > Although yes, if a device gets a /64 > with DHCP-PD then it can RA with that /64 on its other interface, only > for the other devices on that other interface. Yes, that is what I am saying. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandru Petres= cu > Sent: Friday, July 31, 2015 2:24 AM > To: v6ops@ietf.org > Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availabili= ty-01.txt >=20 >=20 >=20 > Le 30/07/2015 17:49, Templin, Fred L a =E9crit : > > Hi Philip, > > > >> -----Original Message----- From: v6ops > >> [mailto:v6ops-bounces@ietf.org] On Behalf Of Philip Homburg Sent: > >> Thursday, July 30, 2015 8:38 AM To: v6ops@ietf.org Subject: Re: > >> [v6ops] I-D Action: > >> draft-colitti-v6ops-host-addr-availability-01.txt > >> > >>> I agree. We also need to remember that each device that gets a > >>> /64 can connect countless billions of other devices using the > >>> available /64 prefix space. > >> > >> I'm not saying that we should give every device a /64 using > >> DHCP-PD. SLAAC is probably a much better way to distribute > >> addresses locally (at least as long as we don't mess up IIDs > >> completely). > > > > You can't give a device a /64 using SLAAC; >=20 > I agree. >=20 > > SLAAC only allows for autoconfiguration of singleton addresses taken > > from an on-link /64 prefix. >=20 > Yes. >=20 > > If you want to give a device a /64, the only choices I am aware of > > are administrative configuration or DHCPv6 PD. >=20 > I agree. In addition there may be something with EAP, IKE and OSPF. >=20 > > That said, once a device has received a /64, address delegation from > > the /64 could certainly use SLAAC. >=20 > I disagree. If a device can't get a /64 by using SLAAC then it can't > give a /64 using SLAAC either. Although yes, if a device gets a /64 > with DHCP-PD then it can RA with that /64 on its other interface, only > for the other devices on that other interface. >=20 > Alex >=20 > > > > Thanks - Fred fred.l.templin@boeing.com > > > >> But, the addressing architecture does allow for one /64 per device. > >> So when needed, it is better to use that space than to add all > >> kinds of complexity while trying to save a few bits. > >> > >> > >> _______________________________________________ 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 Fri Jul 31 11:35:04 2015 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 8603F1B3447 for ; Fri, 31 Jul 2015 11:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_32=0.6, 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 pvuyVxQRtVhR for ; Fri, 31 Jul 2015 11:35:01 -0700 (PDT) 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 CAB341B3444 for ; Fri, 31 Jul 2015 11:35:01 -0700 (PDT) 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 t6VIZ1IT002196; Fri, 31 Jul 2015 11:35:01 -0700 Received: from XCH-PHX-312.sw.nos.boeing.com (xch-phx-312.sw.nos.boeing.com [130.247.25.173]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t6VIYsNu001676 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 31 Jul 2015 11:34:54 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.231]) by XCH-PHX-312.sw.nos.boeing.com ([169.254.12.68]) with mapi id 14.03.0235.001; Fri, 31 Jul 2015 11:34:53 -0700 From: "Templin, Fred L" To: Alexandru Petrescu , "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-01.txt Thread-Index: AQHQyt22GTvNaKRRoESx6jY9+5U45Z30J2yAgAFnWwKAAFhhMA== Date: Fri, 31 Jul 2015 18:34:53 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832ED3E70@XCH-BLV-504.nw.nos.boeing.com> References: <20150723130715.12113.47480.idtracker@ietfa.amsl.com> <20150728115944.GZ84167@Space.Net> <4AB2ED61-23CF-40D5-B2A6-F1F4064EC0C6@nominum.com> <90E6B48E-B3FC-4AAD-B356-7D92A2777632@nominum.com> <804F2F0B-B0EF-4054-99C5-C0CD8957C434@nominum.com> <2134F8430051B64F815C691A62D9831832ED2 9AC@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832ED2A37@XCH-BLV-504.nw.nos.boeing.com> <20150730191629.1817894a@envy.fud.no> <55BB73A0.4040105@gmail.com> In-Reply-To: <55BB73A0.4040105@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-colitti-v6ops-host-addr-availability-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: Fri, 31 Jul 2015 18:35:03 -0000 Hi, > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandru Petres= cu > Sent: Friday, July 31, 2015 6:10 AM > To: v6ops@ietf.org > Subject: Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availabili= ty-01.txt >=20 >=20 >=20 > Le 30/07/2015 19:16, Tore Anderson a =E9crit : > > * Templin, Fred L > > > >> You can't give a device a /64 using SLAAC; SLAAC only allows for > >> autoconfiguration of singleton addresses taken from an on-link /64 > >> prefix. > > > > Hi Fred, > > > > Actually, SLAAC works equally well with off-link prefixes. There is > > no inherent requirement in SLAAC that prefixes from which the > > addresses are auto-configured must be on-link; the L and A bits in an > > RA's PIO are completely orthogonal. RFC4861 says: "L 1-bit on-link flag. When set, indicates that this prefix can be used for on-link determination. When not set the advertisement makes no statement about on-link or off-link properties of the prefix. In other words, if the L flag is not set a host MUST NOT conclude that an address derived from the prefix is off-link. That is, it MUST NOT update a previous indication that the address is on-link." Meaning that "L=3D0" conveys no useful on/off link information about the IPv6 prefix in the PIO. The node receiving the PIO therefore has no way of knowing whether the prefix is on/off link and much less whether the prefix is being "delegated" to the node. At least that is per standard IPv6ND. > I can agree. >=20 > >> If you want to give a device a /64, the only choices I am aware of > >> are administrative configuration or DHCPv6 PD. > > > > True, although 3GPP networks is an exception. There a /64 prefix > > advertised to the UE via standard RA/PIO with SLAAC can be treated > > as if it was a delegated prefix. RFC7278 depends on this. >=20 > IMHO it is wrong to treat it as a delegated prefix. RFC7278 states > clearly that the right way to get a delegated prefix is DHCPv6-PD. Agree. > The treatment 'as if' is what makes operators think that one /64 in RA > is enough space for enough devices behind the UE. Prefix delegation for any length /64 or shorter should be possible, yes. Thanks - Fred fred.l.templin@boeing.com > A /64 on a cellular link can only accommodate one device. Something may > make think that the /64 is a delegated prefix that _could_ accommodate > more than one device: > - the cellular link is a ptp link. As such the first-hop router in the > cellular network has a specific routing table entry containing the IP > address of the UE as next-hop (instead of a '*' if it were a shared > link) for that /64. This makes that any address in that /64 is > reachable through UE's IP address. >=20 > However, cellular links continue to advance away from being ptp links > and more be 'shared' links. Recently 4G ptp links have got 48bit MAC > addresses. In the future there will be true Neighbor Discovery on these > links, with '*' routes instead of next-hop routes. At that point, the > assumption that a /64 can accommodate 2^64 devices will no longer hold, > because the first-hop router will issue NSs for the dst address, instead > of issuing RSs for the IP address of the UE. >=20 > Alex >=20 > > Tore > > > > _______________________________________________ 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 Fri Jul 31 11:41:49 2015 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 C98171B3476; Fri, 31 Jul 2015 11:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.21 X-Spam-Level: X-Spam-Status: No, score=-13.21 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, J_BACKHAIR_37=1, MIME_8BIT_HEADER=0.3, 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 uqYmTZNh6qtt; Fri, 31 Jul 2015 11:41:43 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3614B1B3472; Fri, 31 Jul 2015 11:41:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13157; q=dns/txt; s=iport; t=1438368103; x=1439577703; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=fusxcXN+BnkpsK6oNMqDohRb1ve9KbfWIIUgCWgPdL4=; b=WbUXdOMXL07R5tg+gMxWVFTCTqpRI3jkhRU622q6bn+AFej7uPp5MpCo U44VTa6zDawAWaFceaBqAcqIEZMGQQFn9RQcOjQEIFkfu+ZiTapUlcIoT h86MhTbX0NqNkp2N+NOoobQ7Z8BFo1XttuA5xEPrsvy4QkZ44/Gg6bkLV c=; X-IronPort-AV: E=Sophos; i="5.15,586,1432598400"; d="scan'208,217"; a="16718101" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-5.cisco.com with ESMTP; 31 Jul 2015 18:41:42 +0000 Received: from [10.24.84.19] ([10.24.84.19]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t6VIffMi005487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Jul 2015 18:41:42 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_B38AB86B-252E-4DDA-9ADB-7683EFF0B9D4" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= In-Reply-To: Date: Fri, 31 Jul 2015 11:41:40 -0700 Message-Id: <43CF0BAE-637D-4462-B067-3ED16E7A5D29@cisco.com> References: <20150730205806.GI1667@cisco.com> To: Ca By , Toerless Eckert X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "v6ops@ietf.org" , "behave@ietf.org" Subject: Re: [v6ops] [BEHAVE] protocols without need for ALG ? 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, 31 Jul 2015 18:41:45 -0000 --Apple-Mail=_B38AB86B-252E-4DDA-9ADB-7683EFF0B9D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 31-Jul-2015 06:37 am, Ca By wrote:=20 >=20 >=20 > On Thursday, July 30, 2015, Toerless Eckert > wrote: > For autonomic networking (ANIMA WG), we are planning to rely only on = IPv6 for initial > autonomic connectivity, and the question of connecting this (at least = initially) > to IPv4 only NOC equipment came up. Alas, IPv6 support in transport = seems to be still > weak on a range of commonly used NOC tools. >=20 >=20 > Ehhh. For something as forward looking as anima , it is unfortunate = that you believe you will need to bring this technical debt with you.=20 +1. Let's please kill ALGs. See below. > My suggeation is that you require ipv6 for this case. If you do not = shed this requirement now, you will carry it with you forever.=20 >=20 > The iphone can require ipv6 apps, so can anima.=20 >=20 > CB > =20 > If i understand the NAT RFCs and behave output correctly, we = primaerily > want ALGs to go the way of the dodo, so i was wondering if there might = be > any crucial protocols between typical NOC equipment and network = devices that > would require ALGs. And better of course:knowing which protocols would = be fine > without ALG. >=20 > Are there any lists about this (eg: what requires ALG ?) >=20 > Wrt to what seems to be important between NOC and network devices: >=20 > FTP - NOK (requires ALG) - IMHO not a problem FTP is a troublesome case. All modern FTP clients default to using PASV = -- IE 6 was the last holdout that didn't do PASV and thus broke with NAT = or required an FTP ALG. However, PASV doesn't work with IPv6 servers = which need EPSV. So certain NAT46 and NAT64 cases will break unless = there is an FTP ALG. Hence, BEHAVE wrote RFC6384 which explains NAT64 = case, but there isn't a document explaining the 464XLAT situation with = FTP. Better to just declare FTP dead. Passive (both PASV and EPSV) are = vulnerable to a connection theft (see http://cr.yp.to/ftp/security.html = ). For whatever it's worth, both = Chrome and Firefox have open bugs to remove FTP from both of those = browsers. Instead of FTP, profile that anima has to use HTTP or HTTPS. > traceroute - ?? (initiated from v4 NOC) ?? OK. > telnet - OK > ping - OK ? > SSH/SCP - OK > syslog - OK > TFTP - OK ? TFTP breaks if the NAT (or firewall) have Address and Port-Dependent = Filtering behavior (defined at https://tools.ietf.org/html/rfc4787 = #section-5). This is because TFTP = client sends a packet to the server's port 69, and the server's response = is sent from an ephemeral port (rather than from port 69). Some NATs = and some firewalls change their filtering behavior if the destination = port is 69, and because behavior changes based on the application (TFTP) = many people would consider that to be an "ALG", although the NAT is not = modifying the application payload, which is arguably the strict = definition of an ALG. Instead of FTP, profile that anima has to use HTTP or HTTPS. > radius - OK ? (i ran some tests, seemed to be fine) > diameter/tacacs+ - OK ? > NTP - OK ??? >=20 > For the following, that have extensible data-models (MIBs/OIDs, XML = schema etc.), > i can see that some NOC tools relying on them might not support = data-models > with IPv6, but that would be "fine" (aka: can't manage everything = from such tools, > but transport stack works): >=20 > netconf - OK ? > SNMP - OK ? SNMP often contains IP addresses (e.g., IP address of configured = interfaces) which can confuse a management system that isn't aware of = NAT. We certainly don't want an ALG to fiddle with SNMP, though, that = would be a nightmare. Polling SNMP across a firewall or NAT is = problematic or impossible (and ALG can't fix that). -d >=20 > Whats the next most important NOC<->network management protocols... ? >=20 > Thanks! > Toerless >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops = > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave --Apple-Mail=_B38AB86B-252E-4DDA-9ADB-7683EFF0B9D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 31-Jul-2015 06:37 am, Ca By <cb.list6@gmail.com> = wrote:


On Thursday, = July 30, 2015, Toerless Eckert <eckert@cisco.com> wrote:
For autonomic networking (ANIMA WG), we are = planning to rely only on IPv6 for initial
autonomic connectivity, and the question of connecting this (at least = initially)
to IPv4 only NOC equipment came up. Alas, IPv6 support in transport = seems to be still
weak on a range of commonly used NOC tools.


Ehhh. For something as forward looking as anima , it is = unfortunate that you believe you will need to bring this technical debt = with you. 

+1.=  Let's please kill ALGs.


See below.


My suggeation is that you require ipv6 for this case. If you = do not shed this requirement now, you will carry it with you = forever. 

The iphone can require ipv6 apps, so can = anima. 

CB
 
If i understand the NAT RFCs and behave output correctly, we = primaerily
want ALGs to go the way of the dodo, so i was wondering if there might = be
any crucial protocols between typical NOC equipment and network devices = that
would require ALGs. And better of course:knowing which protocols would = be fine
without ALG.

Are there any lists about this (eg: what requires ALG ?)

Wrt to what seems to be important between NOC and network devices:

   FTP     - NOK (requires ALG) - IMHO not a = problem

FTP is a troublesome case.  All modern FTP = clients default to using PASV -- IE 6 was the last holdout that didn't = do PASV and thus broke with NAT or required an FTP ALG.  However, =  PASV doesn't work with IPv6 servers which need EPSV.  So = certain NAT46 and NAT64 cases will break unless there is an FTP ALG. =  Hence, BEHAVE wrote RFC6384 which explains NAT64 case, but there = isn't a document explaining the 464XLAT situation with FTP.  Better = to just declare FTP dead.  Passive (both PASV and EPSV) are = vulnerable to a connection theft (see http://cr.yp.to/ftp/security.html).  For whatever = it's worth, both Chrome and Firefox have open bugs to remove FTP from = both of those browsers.

Instead = of FTP, profile that anima has to use HTTP or HTTPS.


   traceroute - ??  (initiated from v4 NOC) ??

OK.


   telnet  - OK
   ping    - OK ?
   SSH/SCP - OK
   syslog  - OK
   TFTP    - OK ?


TFTP breaks if the = NAT (or firewall) have Address and Port-Dependent Filtering behavior = (defined at https://tools.ietf.org/html/rfc4787#section-5). =  This is because TFTP client sends a packet to the server's port = 69, and the server's response is sent from an ephemeral port (rather = than from port 69).  Some NATs and some firewalls change their = filtering behavior if the destination port is 69, and because behavior = changes based on the application (TFTP) many people would consider that = to be an "ALG", although the NAT is not modifying the application = payload, which is arguably the strict definition of an = ALG.

Instead of FTP, profile = that anima has to use HTTP or HTTPS.


   radius  - OK ? (i ran some tests, seemed to be = fine)
   diameter/tacacs+ - OK ?
   NTP     - OK ???

   For the following, that have extensible data-models = (MIBs/OIDs, XML schema etc.),
   i can see that some NOC tools relying on them might not = support data-models
   with IPv6, but that would be "fine" (aka: can't manage = everything from such tools,
   but transport stack works):

   netconf - OK ?
   SNMP    - OK ?

SNMP often contains IP addresses (e.g., IP address = of configured interfaces) which can confuse a management system that = isn't aware of NAT.  We certainly don't want an ALG to fiddle with = SNMP, though, that would be a nightmare.  Polling SNMP across a = firewall or NAT is problematic or impossible (and ALG can't fix = that).

-d



Whats the next most important NOC<->network management = protocols... ?

Thanks!
    Toerless

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
Behave = mailing list
Behave@ietf.org
https://www.ietf.org/mailman/listinfo/behave


= --Apple-Mail=_B38AB86B-252E-4DDA-9ADB-7683EFF0B9D4-- From nobody Fri Jul 31 12:14:10 2015 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 C407A1B2DFF; Fri, 31 Jul 2015 12:14:07 -0700 (PDT) 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 8LUOyuwmTGZP; Fri, 31 Jul 2015 12:14:06 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AEC51B2D4F; Fri, 31 Jul 2015 12:14:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1978; q=dns/txt; s=iport; t=1438370046; x=1439579646; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Y9jQyGRety5YOHAZnjdNbzagx/cAIvESdk/pNmMUl1k=; b=Shx1QZ31mLhUNUOsW6tCxMy7sgfQqcCbftx62YL6eH8DMtlp8Iw43fsZ +MGLttwUZ4Xy8+ebxSmJT8M9vRO7ZqkNfAquMesSbvOefMxWKqyBMaHyb KPCAH9jnvVO+wlAWPb9KwJVjUDcB2PR+kOHnJ2eHUQJ4IJTCkY51vRWYd Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B9BQBEyLtV/4MNJK1bDoMMVGkGvjMKhS9KAoEyOxEBAQEBAQEBgQqEJAEBBAEBATc0CxACAQgYFgEHECcLJQIEAQ0FiC4Nx0YBAQEBAQEBAQEBAQEBAQEBAQEBAQETBItOhQcHEwGEGAWFZY8TAYoMgjyBR5QTg2Umgz8+b4EHBxcjgQQBAQE X-IronPort-AV: E=Sophos;i="5.15,586,1432598400"; d="scan'208";a="16722737" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-6.cisco.com with ESMTP; 31 Jul 2015 19:14:04 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t6VJE0bZ010123 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 Jul 2015 19:14:00 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.77]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Fri, 31 Jul 2015 14:14:00 -0500 From: "Senthil Sivakumar (ssenthil)" To: Joe Touch , Owen DeLong , "Toerless Eckert (eckert)" Thread-Topic: [BEHAVE] [v6ops] protocols without need for ALG ? Thread-Index: AQHQywp4WemgLTWIcUiyGhVGVVQ3qJ301TGAgAAEyQCAASrNgA== Date: Fri, 31 Jul 2015 19:13:59 +0000 Message-ID: References: <20150730205806.GI1667@cisco.com> <33A0B18B-5C9D-4DC3-9E0B-736D7ECA404F@delong.com> <55BA960E.7010700@isi.edu> In-Reply-To: <55BA960E.7010700@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.3.150624 x-originating-ip: [10.150.24.24] Content-Type: text/plain; charset="us-ascii" Content-ID: <1CDC18AAA2B2AA4B8A046C6C838CE992@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "v6ops@ietf.org" , "behave@ietf.org" Subject: Re: [v6ops] [BEHAVE] protocols without need for ALG ? 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, 31 Jul 2015 19:14:07 -0000 On 7/30/15, 5:24 PM, "Behave on behalf of Joe Touch" wrote: > > >On 7/30/2015 2:07 PM, Owen DeLong wrote: >>=20 >>> On Jul 30, 2015, at 13:58 , Toerless Eckert wrote: >>> >>> For autonomic networking (ANIMA WG), we are planning to rely only on >>>IPv6 for initial >>> autonomic connectivity, and the question of connecting this (at least >>>initially) >>> to IPv4 only NOC equipment came up. Alas, IPv6 support in transport >>>seems to be still >>> weak on a range of commonly used NOC tools. >>> >>> If i understand the NAT RFCs and behave output correctly, we primaerily >>> want ALGs to go the way of the dodo, > >NATs too, if we're taking requests... > >... >>> Wrt to what seems to be important between NOC and network devices: >>> >>> FTP - NOK (requires ALG) - IMHO not a problem >>=20 >> FTP should be long deprecated for the most part anyway, however, PASV >> mode FTP (if you must use FTP) should be OK without need of an ALG. > >FTP has security problems but anonymous mode access to files is still >used. As noted, PASV avoids the need for ALG in-band address translation. > >All the listed protocols should be OK if the client is behind the NAT >(as noted) *or* if the NAT is configured to forward those services to a >particular private-side host. > >Other ALG protocols not on your list: > > web: > HTTP (mostly to hijack initial login screens, > somtimes to insert tracking or ads) > > teleconferencing/media: > Apple iChat > H.323 > MGCP (media gateway) > RTSP (realtime streaming) > SCCP (Cisco call signalling) > SIP > > remote functions: > RPC (Sun, Microsoft) > SQL > > tunneling: > PPTP Also, include LDAP, DNS and Netbios ALGs to the list. Senthil > >--- > >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave From nobody Fri Jul 31 13:17:26 2015 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 383661ACD35; Fri, 31 Jul 2015 13:17:23 -0700 (PDT) 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 0ia0SYH5IMeG; Fri, 31 Jul 2015 13:17:22 -0700 (PDT) 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 EB22C1A88D0; Fri, 31 Jul 2015 13:17:21 -0700 (PDT) Received: from [2a02:fe0:c412:1fe0::2] (port=46204 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1ZLGk1-0000Gg-GC; Fri, 31 Jul 2015 22:17:17 +0200 Date: Fri, 31 Jul 2015 22:17:16 +0200 From: Tore Anderson To: Toerless Eckert Message-ID: <20150731221716.5729154a@envy.fud.no> In-Reply-To: <20150731174421.GA9032@cisco.com> References: <20150730205806.GI1667@cisco.com> <55BBA7C1.3000502@gmail.com> <20150731174421.GA9032@cisco.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; 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" , "behave@ietf.org" Subject: Re: [v6ops] [BEHAVE] protocols without need for ALG ? 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, 31 Jul 2015 20:17:23 -0000 * Toerless Eckert > On Sat, Aug 01, 2015 at 04:52:17AM +1200, Brian E Carpenter wrote: > > Yes, but we assume that during the phasing-in of autonomic > > operations, we will be forced to interface to legacy NOCs. > > Right. It's just like siit-dc, just the opposite: We want to enable > the IPv6 only autonomic network (like they an IPv6 only DC) of course > to also encourage the IPv6 centric/only NOC but to get started also > provide a simple, isolated, and easily removed solution (hack ?) to > connect to legacy IPv4 NOC in our case (in siit-dc some legacy IPv4 > (network)). Yep, but be aware that with SIIT you will need to identify all the IPv6 endpoints you want the IPv4-only NOC folks to be able to access. These endpoints need either to be provisioned with an IPv4-translatable IPv6 address (traditional SIIT), or get an IPv4 mapping provisioned on the protocol translator (SIIT-DC style deployment with EAMs). You could also use Stateful NAT64 (RFC6146) with statically configured BIB entries to accomplish pretty much the same thing as the SIIT-DC approach, but you do get a lot of superfluous baggage that way (all the stateful connection/session tracking stuff). Anyway if the IPv6-only autonomic network is very dynamic in nature and/or have a large number of managed endpoints that must be reachable from the IPv4-only NOC, that requirement could possibly be problematic. BTW you asked about traceroute, and I don't think anyone answered, so: ICMPv6 packets originated by IPv6 hops behind the translator (that are not provisioned with an IPv4-translatable IPv6 address) will appear as originating from a "random" IPv4 address (which could repeat multiple times in the path). That could possibly be confusing to NOC staff, so I'd suggest giving the RFC6791 addresses descriptive PTR records in DNS ("this-apparent-ipv4-hop-really-represents-an-ipv6-router-in-the-autonomic-network-see-rfc6791.example.com"). > Actually i now think siit-eam is the easiest way - which i think is > an extension of stateless NAT64, but i don't claim i am using all > the terminology right. Let me know if you want some help or pointers on how to set up a stateless translator for testing purposes. Or you could use one of mine, as it works just as well over the public internet too (as long as the IPv6 endpoints you want to manage are numbered with globally reachable addresses). I'd be happy to assist. Tore From nobody Fri Jul 31 13:31:50 2015 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 220FC1ACE93; Fri, 31 Jul 2015 13:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 jEga1Mp4SalP; Fri, 31 Jul 2015 13:31:46 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92F9A1ACE81; Fri, 31 Jul 2015 13:31:46 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 493DBE1BF; Fri, 31 Jul 2015 16:49:02 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id BE02563AEC; Fri, 31 Jul 2015 16:31:44 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A2A0463751; Fri, 31 Jul 2015 16:31:44 -0400 (EDT) From: Michael Richardson To: Toerless Eckert In-Reply-To: <20150730205806.GI1667@cisco.com> References: <20150730205806.GI1667@cisco.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Cc: v6ops@ietf.org, behave@ietf.org Subject: Re: [v6ops] [BEHAVE] protocols without need for ALG ? 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, 31 Jul 2015 20:31:48 -0000 --=-=-= Content-Type: text/plain Toerless Eckert wrote: > radius - OK ? Classic RADIUS has an MD5 based authenticator which depends upon the IP address. It can sometimes be made to work through NAPTs, but in general it doesn't. Newer mechanisms get rid of this, replacing it all with DTLS, which doesn't care, but the classic stuff is pretty widespread. On the other hand, it is easily proxied from IPv6 to IPv4 should the radius server be unable to speak IPv6. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVbvbMICLcPvd0N1lAQJkgwf9E/Evj9G9Sl9lSPXzRu+t5McKpIux9hZu hlWRetl7xlI0vxei5q7IWaCT4ELqk+KxbUHM0qZySH6DuFsx+ua95lqiYS6K3ZWT WOSs+IODVC7zonrZLOQHddHLX1PwrCBom4kX1la8fEU4vWH5Oh/kVi1eUISb869I rHGILT6bQO0MWf5xbIcI7jfbqbtTnELIyGEjKRudi1qbc//DQ4Smi1VEGhFlPx7w MpOnky7Mk2x3+9xifENdOsHMP7WX5T6535eEu8pYgIW3pOAaKzbkTNlMBMrKx+5v dPa9/Y69dyovHF87eiRbm837EIU5CrznxqkXdzdwtz81qiT6zoUVpg== =7AV2 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jul 31 13:37:18 2015 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 B62C31A894B; Fri, 31 Jul 2015 13:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bzsKkGSLs1D; Fri, 31 Jul 2015 13:37:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8461ACD6B; Fri, 31 Jul 2015 13:37:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.2.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150731203716.9847.57464.idtracker@ietfa.amsl.com> Date: Fri, 31 Jul 2015 13:37:16 -0700 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-00.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: Fri, 31 Jul 2015 20:37:17 -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-00.txt Pages : 12 Date : 2015-07-31 Abstract: This document recommends that networks provide general-purpose end hosts with multiple global 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-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 31 16:45:48 2015 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 4B1571ACCFB; Fri, 31 Jul 2015 16:45:45 -0700 (PDT) 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, 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 5TXbt0vgwu4N; Fri, 31 Jul 2015 16:45:43 -0700 (PDT) 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 A7FE81ACCF4; Fri, 31 Jul 2015 16:45:43 -0700 (PDT) Received: by iodd187 with SMTP id d187so99855310iod.2; Fri, 31 Jul 2015 16:45:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=WZATmvRdK9x4BzUljz3+Y/cS+x5yAutmbSzMqTIHHew=; b=RUCcxQ/mKN824quzhEAB1rfldNBEf/UmowzQ8mx+R72qFYr88I9WLqxgHsYbm0cdbM BNbus8ibUr+XBwb9ZtBD6QRTFvOx6/nDx4mgmPseIAeOHmwuwQdIJ/AqYE+MWOvLqbTF EgetUNtB1+B/8VDfSCptbnVhXUW61glus+MMzOJeBo1j6AQkQhHr6A4CAePxwLjZcQKy 4Oc6d+VBWJ6Lon+NREkyw2f/EMCkOME1JZqZKQFmEQX3a6PMJmhHNzmmIxSOnFCEp5ms WJP79SYw/H5t4xhWOk4s5kLvG+WfE6hz0VWhU0aooWYGyb796crqXBg4DaW9R5RSFpvC a9bg== X-Received: by 10.107.134.83 with SMTP id i80mr9209178iod.123.1438386343083; Fri, 31 Jul 2015 16:45:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.169.143 with HTTP; Fri, 31 Jul 2015 16:45:13 -0700 (PDT) In-Reply-To: References: <20150730205806.GI1667@cisco.com> <33A0B18B-5C9D-4DC3-9E0B-736D7ECA404F@delong.com> <6536E263028723489CCD5B6821D4B21303EEFB81@UK30S005EXS06.EEAD.EEINT.CO.UK> From: Mark Smith Date: Sat, 1 Aug 2015 09:45:13 +1000 Message-ID: To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "behave@ietf.org" , v6ops list Subject: Re: [v6ops] protocols without need for ALG ? 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, 31 Jul 2015 23:45:45 -0000 On 31 July 2015 at 23:21, Joe Touch wrote: > TFTP servers are typically reached at UDP port 69. > > It does not use ports or addresses in-band and thus should not need an ALG. Hmm, to my mind, an "ALG" is necessary if something about the protocol needs to be understood e.g., look for/change in-band ports or addresses, and possibly set up corresponding state or temporary access list/firewall permissions for related traffic. In the case of TFTP, it is the "TID"s: "The transfer identifiers (TID's) used by TFTP are passed to the Datagram layer to be used as ports; therefore they must be between 0 and 65,535. The initialization of TID's is discussed in the section on initial connection protocol." " A requesting host chooses its source TID as described above, and sends its initial request to the known TID 69 decimal (105 octal) on the serving host. The response to the request, under normal operation, uses a TID chosen by the server as its source TID and the TID chosen for the previous message by the requestor as its destination TID. The two chosen TID's are then used for the remainder of the transfer." I think a server could choose to continue to use 69 as its TID for the full transfer, however in my case it didn't. I still remember it today because I was only able to get around the unpredictable TID selection on both ends by using just host IP addresses, which had some risks because it was a very coarse way of selecting "interesting" dial-on-demand traffic to hold the link up. So if in Toerless's scenario it is stateless 1:1 translation between IPv4 and IPv6, then I don't think an ALG would be necessary for TFTP. However, if the translation is stateful because translation between IPv4 and IPv6 isn't 1:1, then I think an ALG is necessary to set up a mapping of some form. Regards, Mark. > > Joe > > On Jul 31, 2015, at 12:23 AM, Heatley, Nick wrote: > > Same for me. > > > > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Mark Smith > Sent: 31 July 2015 06:40 > To: Mikael Abrahamsson > Cc: v6ops list; behave@ietf.org > Subject: Re: [v6ops] protocols without need for ALG ? > > > > > On 31 Jul 2015 3:11 pm, "Mikael Abrahamsson" wrote: >> >> On Thu, 30 Jul 2015, Owen DeLong wrote: >> >>>> SSH/SCP - OK >>>> syslog - OK >>>> TFTP - OK ? >>> >>> >>> Should be OK, depending on which side is client. (client has to be the >>> private address/translated side of the connection). >> >> >> There are ALGs for TFTP from multiple vendors, and I seem to remember I >> had problem performing TFTP download from behind a NAT, but I could be >> mistaken. This should be investigated further. >> > > I'm pretty sure you'd need an ALG for TFTP over NAT, as the file transfer > itself takes place over unspecified and unpredictable ports. This caused me > some grief in the past when trying to have a TFTP file transfer hold up a > dial on demand link. > > Regards, > Mark. > >> -- >> Mikael Abrahamsson email: swmike@swm.pp.se >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > NOTICE AND DISCLAIMER > This e-mail (including any attachments) is intended for the above-named > person(s). If you are not the intended recipient, notify the sender > immediately, delete this email from your system and do not disclose or use > for any purpose. > > We may monitor all incoming and outgoing emails in line with current > legislation. We have taken steps to ensure that this email and attachments > are free from any virus, but it remains your responsibility to ensure that > viruses do not adversely affect you. > > EE Limited > Registered in England and Wales > Company Registered Number: 02382161 > Registered Office Address: Trident Place, Mosquito Way, Hatfield, > Hertfordshire, AL10 9BW > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Jul 31 17:47:10 2015 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 560B81ACE31; Fri, 31 Jul 2015 17:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_41=0.6, J_CHICKENPOX_51=0.6, 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 cPaI4KM_T-zf; Fri, 31 Jul 2015 17:47:07 -0700 (PDT) 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 4E8931ACE2F; Fri, 31 Jul 2015 17:47:07 -0700 (PDT) Received: from [128.9.184.71] ([128.9.184.71]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t710kaIk011548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 31 Jul 2015 17:46:37 -0700 (PDT) To: Mark Smith References: <20150730205806.GI1667@cisco.com> <33A0B18B-5C9D-4DC3-9E0B-736D7ECA404F@delong.com> <6536E263028723489CCD5B6821D4B21303EEFB81@UK30S005EXS06.EEAD.EEINT.CO.UK> From: Joe Touch X-Enigmail-Draft-Status: N1110 Message-ID: <55BC16EB.8060007@isi.edu> Date: Fri, 31 Jul 2015 17:46:35 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-MailScanner-ID: t710kaIk011548 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "behave@ietf.org" , v6ops list Subject: Re: [v6ops] protocols without need for ALG ? 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, 01 Aug 2015 00:47:08 -0000 Hi, Mark, On 7/31/2015 4:45 PM, Mark Smith wrote: > On 31 July 2015 at 23:21, Joe Touch wrote: >> TFTP servers are typically reached at UDP port 69. >> >> It does not use ports or addresses in-band and thus should not need an ALG. > > Hmm, to my mind, an "ALG" is necessary if something about the protocol > needs to be understood e.g., look for/change in-band ports or > addresses, and possibly set up corresponding state or temporary access > list/firewall permissions for related traffic. > > In the case of TFTP, it is the "TID"s: > > "The transfer identifiers (TID's) used by > TFTP are passed to the Datagram layer to be used as ports; therefore > they must be between 0 and 65,535. The initialization of TID's is > discussed in the section on initial connection protocol." > > " A > requesting host chooses its source TID as described above, and sends > its initial request to the known TID 69 decimal (105 octal) on the > serving host. The response to the request, under normal operation, > uses a TID chosen by the server as its source TID and the TID chosen > for the previous message by the requestor as its destination TID. > The two chosen TID's are then used for the remainder of the transfer." Ahh, right - I forgot that TFTP doesn't stick to the same UDP port pair. It works a bit like FTP in that it "hands off" the transfer to the server port indicated by the server-side TID after the initial request. > I think a server could choose to continue to use 69 as its TID for the > full transfer, however in my case it didn't. It never will. The first packet is supposed to have a destination TID of 69 but the rest of the session uses TIDs chosen by each end. client sends sTID=X, dTID=69 on UDP sPORT=X dPORT=69 server replies with sTID=Y, dTID=X on UDP sPORT=Y dPORT=X, which is where the rest of the transfer stays until a new TID is selected. > I still remember it today > because I was only able to get around the unpredictable TID selection > on both ends by using just host IP addresses, which had some risks > because it was a very coarse way of selecting "interesting" > dial-on-demand traffic to hold the link up. I'm not sure what you were doing; "using just host IP addresses" doesn't fix the issue because TFTP still wants to pick TIDs, and the UDP ports vary when the TIDs do. > So if in Toerless's scenario it is stateless 1:1 translation between > IPv4 and IPv6, then I don't think an ALG would be necessary for TFTP. > However, if the translation is stateful because translation between > IPv4 and IPv6 isn't 1:1, then I think an ALG is necessary to set up a > mapping of some form. So first let me backtrack - TFTP requires an ALG to work through a NAT even when the client is on the private side. The return traffic content needs to be inspected to be able to update the private:public translation entry. I.e., this won't work with stateless 1:1 *or* stateful 1:1 without an ALG. I can't imagine how to make sense of it safely in a non-1:1 case. Note that the whole point of TFTP is to be used on a LAN only. It has zero security, and it's easily possible that the translation entry could inadvertently affect some other UDP translation entry. Joe From nobody Fri Jul 31 18:10:50 2015 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 E95371A9075; Fri, 31 Jul 2015 18:10:48 -0700 (PDT) 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, 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 iJc6Olsan6O0; Fri, 31 Jul 2015 18:10:48 -0700 (PDT) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::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 E6CF61A9034; Fri, 31 Jul 2015 18:10:47 -0700 (PDT) Received: by iggf3 with SMTP id f3so27210553igg.1; Fri, 31 Jul 2015 18:10:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=QGwwnNITpnmLFeVZ/haNLBsjeeWEhX9VPzecUU3EeTQ=; b=cyXYLU0Toy8xJAWYyTdH0AS8A1LDrKfrNLcLdsCKVaNEZq4PxfRNLT9GxxrGGjx2En odXaQfQ4WRmwChH3tzz3Qz8KiRj8FApE/kAjO1MGWw7IxnjPb1Wd6oePTDvg5nlmn+S/ WvPEYMpigYQloGBWqxIGMxK5AAkCDlH4hMxVLmZQrYNg/GY4PHP0XS2FsPuynrv58AdM I5WiWGlsmOwdA53AbhpF93+oRhyvl10GKwEKenYpmwaaTRda6QFqrfT7hsjubjNHhbfL SlZOk8/BY87LRPje5NXTGppqwQ8UnB+6UaggrKyMnMaiAeXDQGF9tu/B08MWH/dMAqN5 HrVw== X-Received: by 10.50.64.147 with SMTP id o19mr10654331igs.15.1438391447509; Fri, 31 Jul 2015 18:10:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.169.143 with HTTP; Fri, 31 Jul 2015 18:10:18 -0700 (PDT) In-Reply-To: <20150731203716.9847.57464.idtracker@ietfa.amsl.com> References: <20150731203716.9847.57464.idtracker@ietfa.amsl.com> From: Mark Smith Date: Sat, 1 Aug 2015 11:10:18 +1000 Message-ID: To: internet-drafts@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: v6ops list , i-d-announce@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-00.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, 01 Aug 2015 01:10:49 -0000 Hi, I'm still concerned that this intended BCP is recommending Experimental status NDP and Informational status Sharing /64. NDP was proposed and then rejected for Sharing a /64 because it couldn't prevent possible loops forming. Regarding Sharing a /64, it is a work around, because it violates a number of IPv6 network routing/addressing models and expectations. This is why DHCPv6-PD is stated as the right solution when 3GPP supports it. One example is that the 3GPP GGSN/PDN-GW (i.e., router) considers all of the addresses in the "link's" /64 to be potentially present on the 3GPP User Equipment (i.e. host), so it universally forwards all traffic to addresses within the /64 to the UE (so it is really a host assigned /64, not a link assigned /64). I think this was done to avoid having to perform Neighbor Discovery. This is the sort of IPv6 forwarding routers do towards other routers, not when routers are forwarding across the final hop towards a host. I think this is only possible when there is a literal point-to-point link between a single router and a single host. I can't see how it could be supported on a multi-access link, with potentially multiple hosts, unless the multi-access link has a different /64 to those that are used by the one or more individual host /64s. Cutting to the chase, I'm now describing a scenario that is already satisfied by DHCPv6-PD. Regards, Mark. From nobody Fri Jul 31 19:50:45 2015 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 85C221AC416; Fri, 31 Jul 2015 19:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 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, HK_RANDOM_FROM=1, J_CHICKENPOX_41=0.6, J_CHICKENPOX_51=0.6, 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 lOwYrftr6ANc; Fri, 31 Jul 2015 19:50:43 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::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 173251AC400; Fri, 31 Jul 2015 19:50:43 -0700 (PDT) Received: by iodd187 with SMTP id d187so102048428iod.2; Fri, 31 Jul 2015 19:50:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=W46HeJg1MXGcktwkYChajwa/JGLTXl3ABLpd3s+jLA4=; b=pwkeAaKqSk9W1zIPS55RNCKhIcMsym3TWRgkvKlpeK7sBgdDVM5EfemexXeCgMRk37 0Z/Ah+uzMitjEaB3k+0gB7EhBSeZykkBRofjyuhqhQIBVVqtJdYPix1O9oNlvGIeiQvL pPRcY/4PRm6Z0PbNnFdJPlMmhEsU4w1jb4tfFI8CG9m7kVEOmKOznHBEm/6oA7NjEGaP cCky4a41CS4qQk3CBZOSvK7+LqPAtqCY9Gn2LyeyjuYtbF1Znh8Bf3x+ThhhhIXsNCex yRAqpNKHNuSm+DYwHOelmA6wYLeYp6m+4z/nwrKnp7+GK7kEXW2xcBqFc7/pACL2k7DM vJVw== X-Received: by 10.107.155.74 with SMTP id d71mr11110680ioe.41.1438397442585; Fri, 31 Jul 2015 19:50:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.169.143 with HTTP; Fri, 31 Jul 2015 19:50:13 -0700 (PDT) In-Reply-To: <55BC16EB.8060007@isi.edu> References: <20150730205806.GI1667@cisco.com> <33A0B18B-5C9D-4DC3-9E0B-736D7ECA404F@delong.com> <6536E263028723489CCD5B6821D4B21303EEFB81@UK30S005EXS06.EEAD.EEINT.CO.UK> <55BC16EB.8060007@isi.edu> From: Mark Smith Date: Sat, 1 Aug 2015 12:50:13 +1000 Message-ID: To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "behave@ietf.org" , v6ops list Subject: Re: [v6ops] protocols without need for ALG ? 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, 01 Aug 2015 02:50:44 -0000 Hi Joe, On 1 August 2015 at 10:46, Joe Touch wrote: > Hi, Mark, > > On 7/31/2015 4:45 PM, Mark Smith wrote: >> On 31 July 2015 at 23:21, Joe Touch wrote: >>> TFTP servers are typically reached at UDP port 69. >>> >>> It does not use ports or addresses in-band and thus should not need an ALG. >> >> Hmm, to my mind, an "ALG" is necessary if something about the protocol >> needs to be understood e.g., look for/change in-band ports or >> addresses, and possibly set up corresponding state or temporary access >> list/firewall permissions for related traffic. >> >> In the case of TFTP, it is the "TID"s: >> >> "The transfer identifiers (TID's) used by >> TFTP are passed to the Datagram layer to be used as ports; therefore >> they must be between 0 and 65,535. The initialization of TID's is >> discussed in the section on initial connection protocol." >> >> " A >> requesting host chooses its source TID as described above, and sends >> its initial request to the known TID 69 decimal (105 octal) on the >> serving host. The response to the request, under normal operation, >> uses a TID chosen by the server as its source TID and the TID chosen >> for the previous message by the requestor as its destination TID. >> The two chosen TID's are then used for the remainder of the transfer." > > Ahh, right - I forgot that TFTP doesn't stick to the same UDP port pair. > It works a bit like FTP in that it "hands off" the transfer to the > server port indicated by the server-side TID after the initial request. > If I recall correctly, FTP uses TCP port 20 on one of the ends of the file transfer, so that's the fixed port you can match on if you need to. >> I think a server could choose to continue to use 69 as its TID for the >> full transfer, however in my case it didn't. > > It never will. The first packet is supposed to have a destination TID of > 69 but the rest of the session uses TIDs chosen by each end. > > client sends sTID=X, dTID=69 on UDP sPORT=X dPORT=69 > > server replies with sTID=Y, dTID=X on UDP sPORT=Y dPORT=X, > which is where the rest of the transfer stays until a new TID > is selected. > I haven't thought much about it, however I was thinking that the combination of client address and TID would uniquely identify the file transfer, so the server could still use TID 69 if it chose to. However, I missed the bit in the RFC about both ends randomly choosing the TID when I skimmed through it earlier. >> I still remember it today >> because I was only able to get around the unpredictable TID selection >> on both ends by using just host IP addresses, which had some risks >> because it was a very coarse way of selecting "interesting" >> dial-on-demand traffic to hold the link up. > > I'm not sure what you were doing; "using just host IP addresses" doesn't > fix the issue because TFTP still wants to pick TIDs, and the UDP ports > vary when the TIDs do. > The issue was that only certain types of traffic were both allowed to trigger a dial on the dial-on-demand link and to hold it up. Matching on UDP port 69 would bring up the link at the start of the TFTP transfer, however the subsequent TFTP traffic wouldn't match on UDP port 69 of course, so the d-on-d link would be torn down fairly quickly (we had low value tear down timers to reduce cost and contention for dial (ISDN) ports). So the only way I could "identify" the TFTP traffic to keep the call up was to go down a layer, and match on the IP addresses of the known sources/destinations of the TFTP transfer. Of course, that isn't really selective at all, so any traffic to or from those TFTP source/dest addresses would bring up/hold up the d-on-d link. Fortunately the TFTP clients were routers, so traffic directly to them was more controlled and limited than if they had been general purpose hosts. >> So if in Toerless's scenario it is stateless 1:1 translation between >> IPv4 and IPv6, then I don't think an ALG would be necessary for TFTP. >> However, if the translation is stateful because translation between >> IPv4 and IPv6 isn't 1:1, then I think an ALG is necessary to set up a >> mapping of some form. > > So first let me backtrack - TFTP requires an ALG to work through a NAT > even when the client is on the private side. The return traffic content > needs to be inspected to be able to update the private:public > translation entry. > > I.e., this won't work with stateless 1:1 *or* stateful 1:1 without an > ALG. I can't imagine how to make sense of it safely in a non-1:1 case. > I was thinking that stateless 1:1 translation between IPv4 and IPv6 addresses in the IP headers would work without an TFTP ALG, as long as the UDP Ports/TIDs could be ignored, as there are no IP addresses in the TFTP packets that would need to be translated. 1:1 IPv4 to IPv6 addressing for an Anima network may not be possible to require however, so an ALG for TFTP might be unavoidable. > Note that the whole point of TFTP is to be used on a LAN only. It has > zero security, and it's easily possible that the translation entry could > inadvertently affect some other UDP translation entry. > For many years it was the only way to upload firmware and configuration into a certain vendor's routers, and usually they were remote! Regards, Mark.